[FFmpeg-trac] #4168(undetermined:new): defect : mpeg2 interlaced yuv420 chroma incorrectly decoded

FFmpeg trac at avcodec.org
Thu Dec 11 16:03:12 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 said that VLC had the same issue to point that this problem impacts
 other project as well.
 Yes as a video player you might expect that the user enables
 deinterlacing. But if there is a chroma scaling error, the deinterlace
 filter might end with an incorrect result (in this case, mixing chroma
 between frames).
 And it was also to point out that it might use libswscale because the
 issue is exactly the same. In the past I reported various bugs to the VLC
 team, mostly all closed with "it's a bug in libav" -_-

 In all those years what I learnt is that interlaced video is often not or
 badly supported in FLOSS projects. It's just unfortunate since it's part
 of the basics of video :/

 As I said it's just as if the codecs were not able to send back the
 information that the chroma is interlaced. I misunderstood the meaning of
 yuv420p but the question I wanted to ask there is : why using the same
 pixel format if it can be interpreted in two (or more) different ways ?
 Isn't there something missing here ?

 Now don't misunderstand me, I know ffmpeg is a huge project. I'm even sad
 I don't have enough time to bring my own fixes.

Ticket URL: <https://trac.ffmpeg.org/ticket/4168#comment:17>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker

More information about the FFmpeg-trac mailing list