Hi,
On 08/26/2011 05:48 AM, Vladimir Pantelic wrote:
> John Stebbins wrote:
>> On 08/25/2011 07:45 PM, John Stebbins wrote:
>>> As we discussed on IRC this morning, this makes the value of repeat_pict
>>> returned
>>> by the parsers the same as the value returned by the decoders.
>>>
>>> The parser was returning a value for repeat_pict that was the
>>> actual number of repeats + 1.
>>>
>>> Passes fate with the exception of 1 pre-existing failure
>>> (fate-h264-conformance-mr3_tandberg_b).
>>
>> Heh, fate passed, but some samples I have that use pulldown didn't play
>> smoothly with avplay. One line fix in compute_frame_duration.
>>
>>
>
> @@ -1589,7 +1589,7 @@ static int output_packet(InputStream *ist, int
> ist_index,
> }
> ist->next_pts = ist->pts =
> guess_correct_pts(&ist->pts_ctx, picture.pkt_pts, picture.pkt_dts);
> if (ist->st->codec->time_base.num != 0) {
> - int ticks= ist->st->parser ?
> ist->st->parser->repeat_pict+1 : ist->st->codec->ticks_per_frame;
> + int ticks= ist->st->parser ?
> ist->st->parser->repeat_pict+ist->st->codec->ticks_per_frame :
> + ist->st->codec->ticks_per_frame;
>
> int ticks = st->st->codec->ticks_per_frame + (ist->st->parser ?
> ist->st->parser->repeat_pict : 0);
> Well, after all that, I did some more code reading and spelunking of mailing list archives and discovered the reason that the code is the way it is. The decoders define repeat_pict == 0 to mean one frame time because a decoder always returns frames. The parser defines repeat_pict == 0 to mean one field time because the parser can return after parsing only a field. So when the parser sees a frame, it must add 1 to repeat pict so that the caller can distinguish field from frame. I think this is rather obtuse, but it is what it is. Is anybody in favor of adding a field to AVCodecParserContext to explicitly flag field vs. frame? This option was discussed and rejected in the original mailing list discussion. This was all discussed in the context of this thread back in feb 2009. http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/84007/focus=84344 On a related note, the timebase for h.264 isn't limited to framerate and framerate/2. When the vui fixed_frame_rate flag is not set (VFR content), timebase can be anything that evenly divides the framerate. Thus ticks_per_frame should be framerate / timebase. And timebase shouldn't really be multiplied by 2 unconditionally. FYI, handbrake generates such files by default.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
