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.t...@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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
