I wanted a Linux compatible HDMI capture device and whilst there appear to be a number of potential devices the details are often a bit sketchy. It’s generally unclear how well they work and whether or not they are truly Linux compatible. For example do they drop frames, are there A/V sync issues, do they handle interlaced material correctly, can they encode AC3 sound properly etc. With any device that does not include an H.264 encoder there are additional questions about what spec of machine would be required and whether or not available software and drivers correctly support the full feature set of the device (and if it all works reliably over the course of several hours of continuous use). Conversely for devices that do include an H.264 encoder the question is how well does the encoder work and how configurable is it. Some devices use encoders designed for security cameras and it’s not clear how well these work with other types of film / video material etc.
All in all there are a lot of questions that can mostly only be answered by buying a device and testing it. I have used Hauppauge devices under Linux in the past and noted that there is now some source code for a sample app to run the HDPVR 2 devices under Linux. Anything like this will always be a gamble as it’s hard to tell how well the overall solution will work, but there is also potential for fixing issues when there is some source code available. Some of the HD PVR 2 devices are quite cheap and I ultimately decided that a cheap device with the opportunity to fix things might be better than an expensive one that nearly did everything but lacked any possibility of improvement. I ended up with an HDPVR2 GE (Gaming edition), the non GE version appears to be difficult to get especially at a reasonable price.
Well I guess you are wondering after all that if it was any good. Initially I would have to say no! There are quite a number of issues, many of which are fixable or can be worked round but this could get quite involved for a typical end user.
Summary of some of the issues
General reliability and completeness of the software. The app is built under a ‘TestApp’ folder and it is quite apparent that it is not really a fully featured piece of software. Error handling appears some what limited and the ability to change the settings is mostly absent (there is a mostly unused settings file). The initial HDMI handshaking doesn’t appear to be handled properly and the app often seems to bomb out on start-up. These issues are mostly fixable but require manual modification of the source code. There is no handling for changes in the stream once you start encoding, you’d have to manually stop and start again every time there was a change. I think the ADV7482 should be able to detect changes but you’d have to write a background monitor and restart the encoder with new settings each time (perhaps you can change some encoder settings on the fly but without documentation this would all be trial and error). There is also no built in time out function to end a recording, it’s fairly easy to add one but again something that is not provided as standard. Perhaps the ‘timeout’ command would work I haven’t tested it myself.
Interlacing is broken. The interlaced output is mostly unusable as the odd and even lines are swapped. The video players I tried couldn’t correct this using the readily available settings (should be possible with the correct filter – presumably ffplay should be able to & maybe VLC too). The problem is that the field order setting will not work as that is a temporal setting rather than a spatial one. This is definitely not compatible with MythTV and even if a filter was available (hardware acceleration also implies different filters) it would then mess up correctly encoded content. FFmpeg can correct the faulty interlacing from the HDPVR 2 using a filter but with some disadvantages e.g. additional time to transcode, transcoding usually implies some loss of quality and there was also some slight additional coarseness in the chroma channel (possibly due to chroma sub sampling). I believe transcoding is also more likely to reveal banding (even with tune film or grain settings) at least during my testing with ffmpeg (x264). I think that any additional banding revealed by transcoding may depend on the source material as I suspect temporal and spatial dithering may be handled differently. Technically speaking Hauppauge have messed up the settings here relating to the hardware timing between the ADV7482 and the Magnum DXT H.264 encoder. I can confirm this is specifically an issue caused by the Hauppauge software rather than some limitation or problem with the HW.
Discolouration at the edges of high contrast objects. This is visible at all resolutions but worse at lower resolutions as it is then much more apparent. According to Hauppauge support this is a known problem effectively baked into all the units. I’m not sure why they’d want to sell units with a known defect such as this. Again as above I can confirm this is an issue with the Hauppauge software despite what Hauppauge claim.
AC3 only available via S/PDIF input. Perhaps that is because the HD PVR 2 units that have an S/PDIF input are several times more expensive than one’s without. For the record the hardware does support AC3 via HDMI even if the app doesn’t. Again as above this is a limitation of the Hauppauge software.
Corruption of the encoded video stream. There are some occasional artifacts present in the output from the device which are not present in the source material. My gut feeling after many hours of testing it that this is likely a problem with the device itself. I could just have got a bad one but given the raft of other issues I can’t help thinking there is more to it than that. It could for example be down to the DRAM & system timing but that is non trivial to adjust. Some errors can be detected via FFmpeg as stream corruption but occasionally the errors are baked into the video stream. If you look carefully at a device you will note that the PCB has been mounted upside down with the heatsink pointing downwards towards the ventilation holes on the bottom of the device. I have therefore turned mine upside down and put a fan on top, this effectively gets the ventilation holes on top with the heatsink pointing upwards. At least Hauppauge did seem to put some thought into that. I honestly don’t think the device was overheating anyway and doing that didn’t help. I also changed the USB cable for a short high quality cable, again no change. The HDPVR2 PSU was also changed for an LM2596 buck converter slaved to the server’s PSU (power is now controlled via an Arduino & relay combo). Output was set and checked on my scope, again no improvement. I suppose there is a slim chance of problems relating to the USB chipset, kernel or libusb but I think there would be evidence of other issues or some error messages present. The fact that sometimes the errors are baked into the video stream also suggests a problem with the device. There are also quite a number of comments against the DRAM and system timing in the code suggesting some uncertainty as to the correct settings. A further possibility has now come up which is that the HDMI output could contain some inconsistencies. Without doing a lot of work I couldn’t say what these are, perhaps a response to a damaged transport stream. So to add to the confusion it now appears some errors in the output (i.e. those not visible in the source) seem to come up in the same place every time (during a replay and re-encode of the same material) whereas others appear to be random. Yet another issue I have noted is that the HDPVR 2 application will log corrupted packets occasionally, which is mostly an unrecoverable error (could be worked around with the appropriate changes in the software). I personally believe this to be another symptom of the basic corruption issue above i.e. it can occasionally affect the packet headers rather than the encoded video stream itself.
Seeking issues. I believe that the default settings produce a mixture of IDR and non IDR keyframes. MythTV by default however only seems to pick-up the IDR keyframes and these may have an interval of minutes between them. This means seeking will most likely not work correctly on most machines as the time taken to find each frame after a seek may be too high. For example if the estimated seek time is too high the code will skip to the nearest indexed keyframe which as mentioned can be minutes apart. There is a setting in the code that will force IDR keyframe generation, presumably this is at the cost of encoder efficiency. MythTV has a workaround for the original HD PVR but this does not work for the HD PVR 2 because there is now a mixture of IDR and non IDR keyframes it uses the wrong method. A solution would be to look at the distance between the IDR keyframes and if it is above a certain threshold revert to the original code which I can confirm will work correctly with the default settings.
No HDMI Out. The HDPVR2 app does not support this and it is not clear about the amount of work required to add support.
Single device only. The HDPVR 2 app appears limited to one device, presumably this is the first device that can be found by libusb. I’m sure support could be added provided you can adequately tell each device apart and pass these details on to the HD PVR 2 app via the command line.
Conclusion
If you fix / workaround all the above then it is possible to get decent quality captures. It is probable you will require additional bitrate to get the best quality. The quality of the source material may well also have an impact on the final results. For example it seems that low quality SD material is more prone to blocking artifacts in the background. Any dithering present in the source (possibly as post processing from the STB) that tends to make this look acceptable is not always captured unless a high bitrate is chosen and even then not always (varies with the complexity of the scene of course). Afaik most H.264 encoders will not want to waste bits encoding anything considered to be background noise which is one reason they can be more efficient. It’s possible that if your source does its own post processing and uses dithering to deblock background artifacts that this in turn can not be efficiently captured by the encoder (similar to trying to encode the output from gradfun / deband – which afaik is not recommended, it may work but may require the use of excessive bitrate, in this case perhaps more than is sensible to use for SD capture). Filters like gradfun and deband should however help during playback but these are not currently available in MythTV. As with any post processing they may also introduce some artifacts of their own. Banding in H.264 encoded content appears to be a source of contention, some people claim not to be able to see it whilst others claim it’s very noticeable. I am personally only stating it is a problem as I have been distracted during normal non critical viewing. If you are watching on a desktop monitor you may not be able to see these problems clearly or even at all if the monitor is bad enough. This is typically due to poor contrast ratios and viewing angles (where you can’t see the maximum contrast ratio over the entire screen area). Screen brightness and ambient light falling on the screen also make a big difference. The eye is more sensitive to these issues in darker areas of a scene and this also tends to be where some displays get washed out hence why the issue may not always be visible.
There are 2 variable rate encoding modes, capped and average. The average mode should be avoided as it seems likely that in order to maintain the selected rate it must reduce the bitrate at some point after increasing it i.e. it can not maintain an increased rate for more than a fixed short amount of time (results didn’t seem that good during testing). The capped rate is helpful but you would need to select the appropriate minimum and maximum rates otherwise it may not work correctly at all. With some animated material blocking could be seen regardless as the encoder just doesn’t seem capable of keeping up. Setting a high minimum bitrate is likely to provide the best results although it may not completely resolve the issue if the scene is changing too quickly. From what I can tell the Gaming edition appears to have a more limited set of encoding rates so perhaps some of the other versions can produce better results. At the moment this all needs to be adjusted in the code as there are no command line options and the settings file is ignored for most options including bitrates.
The Magnum DXT H.264 encoder is very much a black box device AFAIK everything including the spec is protected via an NDA. The relevant firmware is obviously just a BLOB and this means only the settings exposed via the API are adjustable. There are all the basic settings such as bitrate, framerate, resolution etc. and a few advanced settings e.g. deblocking on/off, GOP and I frame settings. There is nothing like the sophistication or tunability of x264 so if you can not get the desired results with the available settings you are most likely out of luck.
Unfortunately there seems to be a different version of the app for each version of the HDPVR2, 7 versions when I last checked! At the moment my fixes are specific against one version of the device and the expected video settings etc. This makes providing a general purpose version of the app with all required fixes and settings a lot of work. There is also no licensing file which means it is unclear that a revised version of the app can even be published. I think the best compromise with the existing app is to set your output to 720p as this seems to minimize most of the visual problems. Anyway hopefully the above gives some idea of what issues you could be looking at with the HDPVR 2.
Wrapped in plastic 