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

[FFmpeg]

#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 cehoyos):

 Replying to [comment:23 clam]:
 > Yes MPEG2 allows progressive encoding but it's never used

 I thought progressive DVDs exist (and are not uncommon) but I don't think
 this matters:
 If you are right, then please send the (I suspect trivial) patch to the
 development mailing list that makes the default for the software scaler
 interlaced. If you are wrong, I don't think this issue can be fixed.

 > 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.

 Sorry for my ignorance: How can chroma be interlaced for progressive
 video?

 > 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).

 That is exactly my point.

 > 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.

 This is not how FFmpeg works: It will default to a progressive scale, the
 user will have to specify if he wants an interlaced scale.

 > 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.

 Yes (s/and do a progressive scale/and do an interlaced scale).

 > You can also use some advanced algorithm to autodetect that both fields
 match the same original frame.

 Such a filter exists within FFmpeg, I believe it works well for many
 samples.

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