[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