mandarinka
11th May 2011, 15:27
Support for decoding x264 encodes with 9/10 bitdepth has finally been merged into both libav and ffmpeg, which means the format is ready for practical use.
There's one problem with it however: older/other decoders that don't support high bitdpeth will happily accept these streams and produce an output with higher or lower degree of picture corruption. As far as I know, this is the case with CoreAVC 2.0 (both cuda and software mode) and libavcodec, with other decoders unlikely to behaving differently. While we can probably count on Corecodec adding support to the software decoder sometimes in the future (and hopefuly to patch the present decoders with profile checks that would prevent them from loading), I think it is more than reasonable to not expect every decoder vendor to make the necessary countermeassures.
(Take for example the many people that prefer to use gpu-based decoders. This unlucky bunch would need to disable their accelerated decoders every time they wanted to watch a high-bitdepth video, which would make the gpu decoder practicaly unusable if such content was encountered less than rarely.)
For that reason, I would like to request a discussion about possible ways to sort out this mess and make sure that only supporting AVC decoders will be used for playback in directshow players, VLC, MPlayer and others (with non-directshow players, libavcodec is almost universaly used, but the problem appears when there is vdpau/dxva decoding available). Ideally, it should be possible for supporting and unsupporting decoders to coexist on a system, with the supporting decoder being used for high bitdepth video even when the unsupporting decoder is the one with priority.
I’m not sure if there are other ways to do this, but for directshow environment, this could probably be realised by using a different mediatype for h264 streams above high profile (4:4:4 / 4:2:2 sampling comes to mind in addition to higher bitdepths). Demuxers would need to be changed to signal the new mediatype, similarly to how Haali splitter uses a custom mediatype to bypass MS’s MF decoders.
Downside of this hack is that it won't affect older installations. A solution that would work with current software present in the wild would be preferable, of course.
Please comment, or suggest alternatives.
If you are an author/vendor of a demuxer (matroska probably being the most important here with mp4 second), I’d like to humbly ask you to consider some scheme to this goal...
There's one problem with it however: older/other decoders that don't support high bitdpeth will happily accept these streams and produce an output with higher or lower degree of picture corruption. As far as I know, this is the case with CoreAVC 2.0 (both cuda and software mode) and libavcodec, with other decoders unlikely to behaving differently. While we can probably count on Corecodec adding support to the software decoder sometimes in the future (and hopefuly to patch the present decoders with profile checks that would prevent them from loading), I think it is more than reasonable to not expect every decoder vendor to make the necessary countermeassures.
(Take for example the many people that prefer to use gpu-based decoders. This unlucky bunch would need to disable their accelerated decoders every time they wanted to watch a high-bitdepth video, which would make the gpu decoder practicaly unusable if such content was encountered less than rarely.)
For that reason, I would like to request a discussion about possible ways to sort out this mess and make sure that only supporting AVC decoders will be used for playback in directshow players, VLC, MPlayer and others (with non-directshow players, libavcodec is almost universaly used, but the problem appears when there is vdpau/dxva decoding available). Ideally, it should be possible for supporting and unsupporting decoders to coexist on a system, with the supporting decoder being used for high bitdepth video even when the unsupporting decoder is the one with priority.
I’m not sure if there are other ways to do this, but for directshow environment, this could probably be realised by using a different mediatype for h264 streams above high profile (4:4:4 / 4:2:2 sampling comes to mind in addition to higher bitdepths). Demuxers would need to be changed to signal the new mediatype, similarly to how Haali splitter uses a custom mediatype to bypass MS’s MF decoders.
Downside of this hack is that it won't affect older installations. A solution that would work with current software present in the wild would be preferable, of course.
Please comment, or suggest alternatives.
If you are an author/vendor of a demuxer (matroska probably being the most important here with mp4 second), I’d like to humbly ask you to consider some scheme to this goal...