I didn’t intend to write about CoreAVC anymore, since VDPAU from NVIDIA is doing its job more than excellently for me. Major parts of this Blog are actually about it. Nevertheless I’ve read through the changelog of the release of 1.9.5. And what must I see? They’ve fixed the Canon HF100 seeking issues. This is their changelog like they’ve posted in their forum.
- Add: NVIDIA CUDA accelerated decoding for interlaced streams (MBAFF and PAFF)
- Add: Input stream colorspace override options
- Fix: CUDA matrix handling and DPB management improvements
- Fix: SEI messages were sometimes discarded
- Fix: Seeking problems with Canon HF100 streams
- Fix: Use faster asynchronous memory transfers between CPU<->GPU for CUDA
The added support for PAFF encoded content, such as H.264 mpeg stransport stream being send over satellite, or profane recordings coming from most of AVCHD camcorders, like the Canon HF10 / HF100 are supported now in version 1.9.5.
Moreover they released also a list of restrictions, regarding hardware accelerated support (through CUDA):
- CUDA does not support lossless AVC
- There is a 16 ref frames limit that is caused by CUDA relying on direct3d. Technically our implementation supports higher ref’s so if NVIDIA fixed that in their driver, those streams would start working.
- The next driver release from NVIDIA will address a CUDA cropping issue (content with a height of 368 and 1088 is automatically clipped to 360 and 1080).
I don’t know if the first point isn’t an academic one, since I don’t know if lossless AVC is used in consumer camcorders at all, but the second point is truly a drawback, since a lot of x264 (Matroska aka mkv )contents seams to use more than 16 reverence frames. In the past one had to patch mplayer sources (Linux) in order to play back some Matroska clips at all.
I personally didn’t replaced the CoreAVCDecoder.dll and tested the latest 1.9.5. version of CoreAVC anymore on Linux. If it should work for Linux again, then here’s a little howto for version 1.9.0.