On Tue, Aug 20, 2019 at 05:09:51PM +0100, Kieran Kunhya wrote: > On Tue, 20 Aug 2019 at 14:16, Carl Eugen Hoyos <ceffm...@gmail.com> wrote: > > > Am Di., 20. Aug. 2019 um 14:48 Uhr schrieb Paul B Mahol <one...@gmail.com > > >: > > > > > I kindly ask that following commit: > > d702769213487923c0fb0abe4b61f4d9ebddb88b > > > > I still believe what the patch does is a very good idea and a revert would > > hurt FFmpeg. > > > > We should not turn CFR streams into VFR. This would not be acceptable for > H264 not should it be acceptable for any other codec.
All MPEG & ITU codecs i remember follow this too as far as possible,
including H264
You can look at mpeg12dec.c:
/* first check if we must repeat the frame */
s->current_picture_ptr->f->repeat_pict = 0;
if (s->repeat_first_field) {
if (s->progressive_sequence) {
if (s->top_field_first)
s->current_picture_ptr->f->repeat_pict = 4;
else
s->current_picture_ptr->f->repeat_pict = 2;
} else if (s->progressive_frame) {
s->current_picture_ptr->f->repeat_pict = 1;
}
}
This exports the number of times to repeat the frame, it does not
output CFR with duplicated frames
But lets look at mpeg4:
/* vop coded */
if (get_bits1(gb) != 1) {
if (s->avctx->debug & FF_DEBUG_PICT_INFO)
av_log(s->avctx, AV_LOG_ERROR, "vop not coded\n");
return FRAME_SKIPPED;
}
now lets look at the spec what vop_coded is:
vop_coded: This is a 1-bit flag which when set to '0' indicates that no
subsequent data exists for the VOP. In this
case, the following decoding rules apply: If binary shape or alpha plane does
exist for the VOP (i.e.
video_object_layer_shape != "rectangular"), it shall be completely transparent.
If binary shape or alpha plane does
not exist for the VOP (i.e. video_object_layer_shape == "rectangular"), the
luminance and chrominance planes of
the reconstructed VOP shall be filled with the forward reference VOP as defined
in subclause 7.6.7.
This clearly wants us to duplicate the frame, yet we do not
But you asked for h264:
here is H264:
case H264_SEI_PIC_STRUCT_FRAME_DOUBLING:
cur->f->repeat_pict = 2;
break;
case H264_SEI_PIC_STRUCT_FRAME_TRIPLING:
cur->f->repeat_pict = 4;
break;
}
again, we return metadata we do not return the same frame
same is true for msmpeg4 and every other codec which uses metadata at AVI level
that is skiped frames. The codecs are CFR at AVI level but we do not output CFR
But what is more bizare (to me at least) is that this was not a controversy
at the time CFR was the standard and all these codecs where "new".
Please correct me if iam wrong but the "CFR must be CFR" seems to originate
from some professional broadcast people (like you).
But then it seems the codecs which broadcast people use
the fact they dont preserve CFR in this way isnt a problem and not even noticed
while for codecs that broadcast has noting to do with like SCPR its a big issue.
This makes no sense to me.
Thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Take away the freedom of one citizen and you will be jailed, take away
the freedom of all citizens and you will be congratulated by your peers
in Parliament.
signature.asc
Description: PGP signature
_______________________________________________ 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".
