[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