HD PVR 2 review / feedback

For discussion related to MythTV which doesn't belong in another forum.

Moderator: Forum Moderators

Post Reply
mythrec
Newcomer
Posts: 7
Joined: Thu Aug 17, 2017 10:52 am
Great Britain

HD PVR 2 review / feedback

Post by mythrec » Thu Dec 28, 2017 8:23 am

I know there is some occasional interest in the HD PVR 2. I've therefore written up some details about it so people can see what they might be in store for https://plasticwrap3d.wordpress.com/hau ... ux-mythtv/

I'm afraid it's a bit technical / wordy and I don't have the time to generate any sample images etc. I'm sure people will get the gist regardless.

User avatar
paulh
Developer
Posts: 337
Joined: Thu Feb 06, 2014 6:09 pm
Great Britain

Re: HD PVR 2 review / feedback

Post by paulh » Thu Dec 28, 2017 7:10 pm

Yeah I got a HD PVR2 sometime ago hoping Hauppauge would eventually produce a proper driver for it. I did try the test app and even tried to fix it but gave up and it's now consigned to the spare parts bin as an expensive mistake :(

I managed to get hold of a Magewell USB 3.0 HDMI capture device. It's very expensive and doesn't even have an encoder, you just get the raw audio and video frames from it, but so far it appears to work OK. It appears in Linux as a V4l2 video and audio device that you can read the raw data from. At Full HD resolution the amount of data produced is quite large but you can change the output resolution to suit what you need.

One advantage of this device over the other encoders is there is zero delay in the video output, Magewell say it's less than one frame, so if you hook it up to an STB you can see any interaction with menus, epg, channel changes etc right away. With the other encoders you get about a 2 second delay which makes it painful to use.

Gribnif
Junior
Posts: 44
Joined: Wed May 14, 2014 12:46 pm
United States of America

Re: HD PVR 2 review / feedback

Post by Gribnif » Thu Dec 28, 2017 7:58 pm

I recently broke down and bought a Blackmagic DeckLink Mini recorder. Like the Magewell mentioned previously, it is strictly a capture device. One difference is that it uses a PCIe slot. It is also fairly low-cost (about US $137). It is capable of capturing 1080i30 along with up to 16 channels of audio via HDMI.

Saving full 1080i30 video to disk is very space-intensive, to the tune of nearly 1Tb/hour. However, I have had pretty good luck so far using a custom-compiled version of ffmpeg to read data directly from the /dev/blackmagic device created by the card's Linux kernel driver with ffmpeg's "decklink" input device. Even on my fairly old AMD A8-7600 I can have ffmpeg read the data, encode it using H.264/AC-3, and send it to MythTV in a TS stream without taxing the CPU or sacrificing quality very much.

Of course, due to the encoding, there is some latency. I haven't yet measured it, but my sense is that it is still less than what it is with the HD-PVR.

In order to send the data to MythTV, I've had to modify the mythfilerecorder utility that comes with Myth. I plan to release this as a fork or perhaps a patch once I get some kinks worked out.

schaff
Newcomer
Posts: 2
Joined: Sun Jan 21, 2018 1:32 am
United States of America

Re: HD PVR 2 review / feedback

Post by schaff » Sun Jan 21, 2018 1:50 am

Gribnif wrote:
Thu Dec 28, 2017 7:58 pm
In order to send the data to MythTV, I've had to modify the mythfilerecorder utility that comes with Myth. I plan to release this as a fork or perhaps a patch once I get some kinks worked out.
Hi Gribnif. I'm curious how you managed to get your device working. I recently acquired a Magewell Pro Capture PCIe card which has V4L2 support via a Linux driver (I'm on Fedora 27, Myth 29). While the card works well with ffmpeg to capture and mux the alsa audio stream into mp4, I can't figure out how to configure MythTV to recognize this card -- and it may never work natively. A helpful IRC chat pointed me to consider hacking on "Import test recorder" capture device in mythtv-setup, but it sounds like you have an approach that may work for this card as well. Would you be willing to share a bit more about your custom ffmpeg and the mythfilerecorder code you've modified as well?

Thanks!

Gribnif
Junior
Posts: 44
Joined: Wed May 14, 2014 12:46 pm
United States of America

Re: HD PVR 2 review / feedback

Post by Gribnif » Mon Jan 22, 2018 2:44 pm

schaff wrote:
Sun Jan 21, 2018 1:50 am
Hi Gribnif. I'm curious how you managed to get your device working.
My code, such as it is, is pretty rough right now. I definitely intend to share what I've done with the world, but I'm still having a big problem that I haven't had time to figure out. I can record one program (or live TV channel) just fine, but if there is second program scheduled to record back-to-back, or if I tune a new channel in Live TV, things get confused and recording stops.

If you'd like to pm me your email address I can send you the source for the modified version of mythfilerecorder I've been working on. Since you have ffmpeg working with your card already, you should be able to use this to capture into Myth--with the limitations listed above.

schaff
Newcomer
Posts: 2
Joined: Sun Jan 21, 2018 1:32 am
United States of America

Re: HD PVR 2 review / feedback

Post by schaff » Wed Jan 24, 2018 2:09 am

Thanks. I'll PM you but apparently my post count is still too low...maybe this post will help and I can try.

I made a bit of progress myself using Import recorder approach starting from the sample script here: www<dot>mythtv<dot>org/wiki/Import_recorder, but have hit some issues myself. The scheduler sometimes doesn't seem to be behaving properly as many of my scheduled recording didn't happen and I see the same issue as you with back-to-back recordings. In addition, the actual recordings are quite choppy and the audio requires an ffmpeg flag (-itsoffset) to sync with the video. I'm not sure if this is the ffmpeg settings I'm using or this machine is just too old to keep up.

I'll be trying some other hardware this weekend. Maybe we can exchange some ideas.

User avatar
jpoet
Developer
Posts: 9
Joined: Fri Feb 07, 2014 4:32 pm
United States of America

Re: HD PVR 2 review / feedback

Post by jpoet » Thu Mar 01, 2018 12:23 am

mythrec wrote:
Thu Dec 28, 2017 8:23 am
I know there is some occasional interest in the HD PVR 2. I've therefore written up some details about it so people can see what they might be in store for https://plasticwrap3d.wordpress.com/hau ... ux-mythtv/

I'm afraid it's a bit technical / wordy and I don't have the time to generate any sample images etc. I'm sure people will get the gist regardless.
If you would like to help improve https://github.com/jpoet/HauppaugeUSB, please let me know.

John

mythrec
Newcomer
Posts: 7
Joined: Thu Aug 17, 2017 10:52 am
Great Britain

Re: HD PVR 2 review / feedback

Post by mythrec » Sat Mar 10, 2018 6:33 pm

jpoet wrote:
Thu Mar 01, 2018 12:23 am
If you would like to help improve https://github.com/jpoet/HauppaugeUSB, please let me know.

John
Well done on the release. I'm not sure if I have time to contribute directly at the moment but I can give a few pointers which should prove helpful. I take it you found the import recorder fix that I contributed which does improve support for HDMI capture devices. The fix is not complete although I have listed most of the issues that are still to be solved. This is mainly live tv, channel changer script and correct handling of HDPVR2 I frame detection (tripped up by the HDPVR I frame detection code). I think that back to back recordings may also be affected although I haven't personally tested this as I use sequential dual tuner import which is something entirely different.

The good news is most of the basic stuff is quite easy to fix and all the time is in identifying the problems so you get the expensive bit for free 8-)

Initialisation sequence

This issue actually turned out to be difficult to identify, not because it is complex but because it was related to unexpected behaviour of the STB and therefore getting mixed in with the setting adjustments. It may not affect all STBs but it affects mine so maybe others too. When the HDPVR2 is first powered on it behaves differently towards the STB than after it is initialised. I suspect this is because the EDID block is not loaded and hence the STB uses more compatible settings which is ironic because my STB ignores almost all of the EDID, even basic stuff like what modes are actually supported. Somewhere down the line this leads to a sub optimal colour space conversion which can mostly be seen with darker gradients as it introduces a colour cast to some of the macro blocks. As mentioned in my review gradients can already tend to be blocky but this makes them appear much noisier than they otherwise would be.

There are 2 basic solutions that I can suggest.
  • Init option to purely load firmware and EDID and then terminate the app. You could put this in the bootup script but would need to ensure you only plug in the STB after the HDPVR2 initialisation is complete. This also affects the way the LEDs are lit on the USB device so you can normally see when it is complete.
  • Use a set of script hooks to be completed by the end user. Firstly to power on the HDPVR2 and then to power on the connected device only after the EDID is available. Finally to power both devices off again after capture is complete.
EDID excerpt

Code: Select all

  Video data block
    VIC 16 1920x1080@60Hz (native)
    VIC 34 1920x1080@30Hz 
    VIC 32 1920x1080@24Hz 
    VIC 05 1920x1080i@60Hz 
    VIC 04 1280x720@60Hz 
    VIC 20 1920x1080i@50Hz 
    VIC 19 1280x720@50Hz 
    VIC 03 720x480@60Hz 
    VIC 18 720x576@50Hz 
    VIC 02 720x480@60Hz 
    VIC 17 720x576@50Hz 
    VIC 07 1440x480i@60Hz 
    VIC 22 1440x576i@50Hz 
    VIC 06 1440x480i@60Hz 
    VIC 21 1440x576i@50Hz 
    VIC 01 640x480@60Hz 
HDMI handshaking

The original HDPVR2 app seems to have a botched approach to determining whether or not a stable HDMI signal is available. Although you can read several related timing registers from the ADV7482 none that I tried were especially helpful (there must be something useful available in there). The easiest approach therefore appears to be to inspect the returned vertical frequency. Obviously if you don't initialise the Magnum DXT with the correct timing details you will either get a bad encoding or crash the app. Also as mentioned in the review the HDPVR2 app does not monitor the HDMI frontend for any changes so you have to ensure a stable HDMI signal throughout the capture.

I gave this a bit of thought and the easiest solution is probably just to poll the reported vertical frequency until it is stable for a certain time period. I think that the STB may do a resync (if it is on) after the HDPVR2 is initialised, mine however always appears to keep the original EDID information from when it was first connected i.e. even if it was supposedly in standby mode (hence the above recommendation).

The basic loop would be something like...

Code: Select all

receiverHDMIParams_t vp;
do{
	rxDev.getHDMIParams(&vp);
	/* do check */
	wrapSleep_ms(recheck_ms);
	last_vf=vp.vFreq;
}while(retry<max_retry);
/* check valid etc.*/
AC3 pass through via HDMI

AC3 support via HDMI seems to be a bug bear. It's actually very easy to add support although detecting whether the HDMI data stream contains AC3 may not be trivial as the related info packets didn't contain anything useful which may also be the norm. I would therefore recommend a source setting (HDMI / SPDIF) and an on/off setting such as force on / force off / HD only (SD channels don't typically contain AC3 although no reason why they can't). The last option is obviously only useful if your STB is set to match the source resolution.

The basic code should be...

Code: Select all

hapi->set_param(&_Param, "AudioCapSource", 3); // 0: LR, 1:SPDIF, 2:SDI, 3: HDMI
hapi->set_param(&_Param, "AudioPassthru", 1);
hapi->set_param(&_Param, "AudioCodecOutputFormat", 2); /* AC3 */
hapi->set_param(&_Param, "AudioStreamID", 189);        /* AC3/DTS */
There is also a further SPDIF related setting I haven't used myself

Code: Select all

hapi->set_param(&_Param, "AudioCapSPDIFInput", 0);         // 0:COAX, 1: 19977, 2: AES_EBU, 3: opTICAL
I frame handling

The default settings for the HDPVR2 app produce mixed IDR / non IDR keyframes. I think a solution to this may be as easy as counting the number of IDR keyframes in the first n frames but falling back to the original code if the amount is below a certain threshold.

The code that needs to be adjusted is in mythcommflagplayer.cpp

Code: Select all

        // H.264 recordings from an HD-PVR contain IDR keyframes,
        // which are the only valid cut points for lossless cuts.
        // However, DVB-S h.264 recordings may lack IDR keyframes, in
        // which case we need to allow non-IDR I-frames.  If we get
        // far enough into the rebuild without having created any
        // seektable entries, we can assume it is because of the IDR
        // keyframe setting, and so we rewind and allow h.264 non-IDR
        // I-frames to be treated as keyframes.
        uint64_t frames = decoder->GetFramesRead();
        if (!usingIframes &&
            (GetEof() != kEofStateNone || (frames > 1000 && frames < 1100)) &&
            !decoder->HasPositionMap())
        {
            cout << "No I-frames found, rewinding..." << endl;
            decoder->DoRewind(0);
            decoder->Reset(true, true, true);
            pmap_first = pmap_last = myFramesPlayed = 0;
            decoder->SetIdrOnlyKeyframes(false);
            usingIframes = true;
        }
As an alternative workaround I believe you can force IDR I frames using

Code: Select all

hapi->set_param(&_Param, "bIasIDR", 1);
There is likely to be a trade off between encoder efficiency and seek performance here so also supporting the default settings is probably best.

Recording profiles

I would recommend users setup some dummy recording profiles e.g. Default / HQ / LQ etc. These can then be used to pass on settings such as bitrate to the app. I got the impression you fixed up support for the settings file in which case this could be used to specify the name / location of the file. I believe the original settings file already had separate HD/SD... settings. If not IMHO that is a useful feature, as is having some command line overrides for some settings so you don't end up with too many settings files.

Anyway it's been a while since I looked at this in any detail but I think some of the above should be useful.

Post Reply