[FFmpeg-trac] #4168(undetermined:new): defect : mpeg2 interlaced yuv420 chroma incorrectly decoded
FFmpeg
trac at avcodec.org
Tue Dec 9 11:35:57 CET 2014
#4168: defect : mpeg2 interlaced yuv420 chroma incorrectly decoded
-------------------------------------+-------------------------------------
Reporter: clam | Owner:
Type: defect | Status: new
Priority: normal | Component:
Version: git-master | undetermined
Keywords: | Resolution:
Blocking: | Blocked By:
Analyzed by developer: 0 | Reproduced by developer: 0
-------------------------------------+-------------------------------------
Comment (by clam):
I did a quick check this morning, the issue is the same for interlaced DV
content. I wanted to make sure that it was not an issue with the mpeg
decoder only.
IMO the real definitive answer to this would be to implement a mandatory
conversion to a 4:2:2 pixel format (with correct upscale) while or just
after decoding if the original pixel format is using interlaced 4:2:0
chroma.
That's actually how professionnal/broadcast conversion and editing tools
works, except the chroma upscale is directly implemented into the various
codecs. It's the best solution but it also means the upscale quality
depends of the codec's builtin scale (hence the real quality difference
between DV decoders like Microsoft, Apple, Mainconcept, Avid...).
Implementing the upscale into the codec also mean you might break
compatibility with software expecting a 4:2:0 output, and of course that
kind of defeat the purpose of lbswscale.
Another way of doing this would be to detect if the destination format
accepts chroma formats > 4:2:0 (like 4:2:2, 4:4:4, RGB) and then
automatically upscale the chroma. If not, revert to the current behavior
and log a warning that the chroma is going to be incorreclty handled.
For the record, AviSynth had the exact same kind of issue with pixel
format conversion that was fixed very late.
http://avisynth.nl/index.php/Interlaced_fieldbased
http://avisynth.nl/index.php/Sampling
The source of this issue is that ffmpeg doesn't have an internal 4:2:0
interlaced pixel_format support (tagged incompatible with progressive
4:2:0). Which is not that surprising since it doesn't come from the
broadcast world.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/4168#comment:12>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list