[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