[FFmpeg-trac] #4168(undetermined:new): defect : mpeg2 interlaced yuv420 chroma incorrectly decoded
FFmpeg
trac at avcodec.org
Fri Dec 12 00:36:23 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):
Yes MPEG2 allows progressive encoding but it's never used (you can
generate progressive MPEG2 though). This was actually the big advantage of
MPEG2 when it was released, than there was - at least - a widely released
format that handled interlacing.
The fact that the original content is progressive (for example 25p
material broadcast as 50i) is not relevant for chroma decoding and chroma
upscale. What's important is to know that the chroma is interlaced or not,
and yes for MPEG2 it's mostly interlaced since DVD authoring software
always generates interlaced TFF videos.
It's the same for broadcast, the live encoder will not switch back and
forth between progressive and interlaced. Not that it wouldn't be
possible, it's just that it would mean that the encoder is aware of the
content (it's not) and that the receivers would be able to decode
switching MPEG-TS streams (they're usually not).
You're actually talking about scaling the entire picture (like HD upscale
/ SD downscale). Indeed, if the original content is progressive and
encoded as interlaced, it's a pity since a regular picture scaler will
need to do an interlaced scale (deinterlace/scale/reinterlace) instead of
just do a regular scaling. Unfortunately, it's the way it works, even in
the broadcast world. The only way to avoid this is to visually inspect the
stream and manually apply a progressive scale. You can also use some
advanced algorithm to autodetect that both fields match the same original
frame.
Note that this issue is not really new, in the PAL world it's been here
for at least 30 years, even with Betacam/Digibeta/HDCAM tapes. In the NTSC
world the issue also exists with pulldown sequences (especially 'broken'
ones).
But it's not what we're talking here. The issue we're talking about is
only about chroma coding :)
--
Ticket URL: <https://trac.ffmpeg.org/ticket/4168#comment:23>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list