[FFmpeg-devel] [PATCH] mpeg2_metadata: support inverse (soft) telecine

Andreas Rheinhardt andreas.rheinhardt at gmail.com
Wed Dec 30 23:28:08 EET 2020


Tom Yan:
> Hi Andreas,
> 
> (Somehow I didn't receive your reply and only found it on the mailing
> list archive)
> 
> Can you be more specific about the "smaller scope" on the use of
> `MPEG2RawPictureCodingExtension`? Not sure what you mean.
> 

The actual scope of pce is the "if (ctx->ivtc) { }" block.

> The feature I'm trying to add mainly targets those soft telecined
> streams from NTSC "film" DVD which are actually entirely progressive
> (every single frame with progressive_frame and frame_pred_frame_dct
> being 1). In other words, what I'm targeting is supposed to be
> "progressive_sequence ready", but only faked as non-progressive
> sequence and have soft telecine applied (repeat_first_field and
> top_field_order).
> 
> On Wed, 30 Dec 2020 at 11:49, Tom Yan <tom.ty89 at gmail.com> wrote:
>> +                    if (!pce->frame_pred_frame_dct) {
>> +                        if (pce->progressive_frame) {
>> +                            pce->frame_pred_frame_dct = 1;
> 
> I have it this way because I'm trying to be paranoid and lenient at
> the same time. From what I could see on the H.262 spec,
> progressive_sequence requires frame_pred_frame_dct. However, it
> doesn't exactly state so for progressive_frames. (From what I
> interpreted, progressive_frames "doesn't really matter" if
> progressive_sequence == 1.)
> 

The description of progressive sequence actually says that
progressive_frame needs to be 1 if progressive_sequence is 1:
"progressive_sequence – When set to '1' the coded video sequence
contains only progressive frame-pictures".

> What it states is, if progressive_frames == 1 and progressive_sequence
> == 1, frame_pred_frame_dct shall be 1. That's why I try to make use of
> progressive_frame as a "proof" to determine whether I can "fix"
> frame_pred_frame_dct, in case it somehow isn't 1.
> 

If frame_pred_frame_dct is zero, your input is not progressive sequence
ready (ok, there is a very slim chance that it is: If every frame only
uses frame prediction, you can patch the frames; but you need to parse
and patch the whole slices, not only the frame header, see the version I
referred to earlier [1]; I have not once found a DVD whose frames had
frame_pred_frame_dct unset that is progressive sequence ready, as there
were always frames with macroblocks that use interlaced prediction; but
there often are frames that only are compatible with
frame_pred_frame_dct despite it being unset and in this case one saves a
few bytes).
The reason that frame_pred_frame_dct can be zero even when
progressive_frame is set is that the standard allows bitstreams with a
mix of progressive and interlaced material. In this case one frame can
be progressive while its references are interlaced and so one can not
use progressive prediction (i.e. frame_pred_frame_dct is a "more global"
property).

> With that said I'm totally okay with removing this. I'm not sure
> what's the good way to bail out though. I mean, I cannot confirm the
> sequence is "progressive_sequence ready" until every frame is checked,
> and I cannot leave repeat_first_field and top_field_order untouched
> before I confirm so without looping twice. Yet how those two flags are
> interpreted depends heavily on progressive sequence. So I think the
> best thing I could do is, "blindly" set progressive_sequence and clear
> repeat_first_field and top_field_order, warn once (and maybe quit?) if
> any frame has frame_pred_frame_dct or progressive_frames == 0.
> 

Warning is not enough; you need to error out.

> The feature I'm adding isn't for making a bitstream progressive when
> it's not, but instead, for "unfaking" an entirely progressive
> bitstream, so I don't think the "modifying" bitstream / code height is
> relevant here.
> 
The coded height is one of the criteria for when a bitstream is actually
progressive. Notice that both 480 and 576 are divisible by 32, so this
is no problem for DVDs.

- Andreas

[1]:
https://github.com/mkver/FFmpeg/blob/4b5a477610962af29d155223d4044e8e55fd81b4/libavcodec/mpeg2_metadata_bsf.c


More information about the ffmpeg-devel mailing list