[FFmpeg-devel] H264 video and AVPacket::duration
Michael Doilnitsyn
mdoilnitsyn at gmail.com
Wed Dec 4 21:31:06 CET 2013
04.12.2013 8:14, Michael Niedermayer ?????:
> On Tue, Dec 03, 2013 at 11:39:49PM +0400, Michael Doilnitsyn wrote:
>> On Wed, Nov 20, 2013 at 2:35 PM, Michael Niedermayer <michaelni at gmx.at <http://ffmpeg.org/mailman/listinfo/ffmpeg-devel>>wrote:
>>
>>> / On Wed, Nov 20, 2013 at 11:02:10AM -0800, Alex Sukhanov wrote:
>> />/ > On Tue, Nov 19, 2013 at 5:58 PM, Michael Niedermayer <michaelni at gmx.at <http://ffmpeg.org/mailman/listinfo/ffmpeg-devel>
>> />/ >wrote:
>> />/ >
>> />/ > > On Tue, Nov 19, 2013 at 02:27:55PM -0800, Alex Sukhanov wrote:
>> />/ > > > Hi Michael and ffmpeg-devel,
>> />/ > > >
>> />/ > > > I recently found that for H264 video ffmpeg demuxers and ffprobe
>> />/ doesn't
>> />/ > > > set AVPacket::duration field.
>> />/ > > > This is typical ffprobe output for H264 video packed into FLV
>> />/ container:
>> />/ > > >
>> />/ > > >
>> />/ > >
>> />/ packet|codec_type=audio|stream_index=1|pts=0|pts_time=0.000000|dts=0|dts_time=0.000000|duration=23|duration_time=0.023000|convergence_duration=N/A|convergence_duration_time=N/A|size=9|pos=103|flags=K_
>> />/ > > >
>> />/ > >
>> />/ *packet|codec_type=video|stream_index=0|pts=0|pts_time=0.000000|dts=0|dts_time=0.000000|duration=N/A|duration_time=N/A|convergence_duration=N/A|convergence_duration_time=N/A|size=4188|pos=132|flags=K_*
>> />/ > > >
>> />/ > >
>> />/ packet|codec_type=audio|stream_index=1|pts=23|pts_time=0.023000|dts=23|dts_time=0.023000|duration=23|duration_time=0.023000|convergence_duration=N/A|convergence_duration_time=N/A|size=9|pos=4337|flags=K_
>> />/ > > >
>> />/ > >
>> />/ *packet|codec_type=video|stream_index=0|pts=37|pts_time=0.037000|dts=37|dts_time=0.037000|duration=N/A|duration_time=N/A|convergence_duration=N/A|convergence_duration_time=N/A|size=43|pos=4366|flags=__*
>> />/ > > >
>> />/ > >
>> />/ packet|codec_type=audio|stream_index=1|pts=46|pts_time=0.046000|dts=46|dts_time=0.046000|duration=23|duration_time=0.023000|convergence_duration=N/A|convergence_duration_time=N/A|size=9|pos=4426|flags=K_
>> />/ > > >
>> />/ > >
>> />/ packet|codec_type=audio|stream_index=1|pts=70|pts_time=0.070000|dts=70|dts_time=0.070000|duration=23|duration_time=0.023000|convergence_duration=N/A|convergence_duration_time=N/A|size=56|pos=4452|flags=K_
>> />/ > > >
>> />/ > >
>> />/ *packet|codec_type=video|stream_index=0|pts=73|pts_time=0.073000|dts=73|dts_time=0.073000|duration=N/A|duration_time=N/A|convergence_duration=N/A|convergence_duration_time=N/A|size=26|pos=4528|flags=__*
>> />/ > > >
>> />/ > >
>> />/ packet|codec_type=audio|stream_index=1|pts=93|pts_time=0.093000|dts=93|dts_time=0.093000|duration=23|duration_time=0.023000|convergence_duration=N/A|convergence_duration_time=N/A|size=607|pos=4571|flags=K_
>> />/ > > >
>> />/ > >
>> />/ *packet|codec_type=video|stream_index=0|pts=110|pts_time=0.110000|dts=110|dts_time=0.110000|duration=N/A|duration_time=N/A|convergence_duration=N/A|convergence_duration_time=N/A|size=31|pos=5198|flags=__*
>> />/ > > >
>> />/ > >
>> />/ packet|codec_type=audio|stream_index=1|pts=116|pts_time=0.116000|dts=116|dts_time=0.116000|duration=23|duration_time=0.023000|convergence_duration=N/A|convergence_duration_time=N/A|size=599|pos=5246|flags=K_
>> />/ > > >
>> />/ > >
>> />/ packet|codec_type=audio|stream_index=1|pts=139|pts_time=0.139000|dts=139|dts_time=0.139000|duration=23|duration_time=0.023000|convergence_duration=N/A|convergence_duration_time=N/A|size=611|pos=5862|flags=K_
>> />/ > > >
>> />/ > > >
>> />/ > > > I found following patch, which may be related:
>> />/ > > >
>> />/ > >
>> />/ http://git.videolan.org/?p=ffmpeg.git;a=commit;h=497431a5b645ffc39cf3acbd333c9ff0f3031adb
>> />/ > > > I understand the problem with interlaced video which you fixed in
>> />/ this
>> />/ > > > patch, but I wanted to ask you If it's possible to move back
>> />/ calculation
>> />/ > > of
>> />/ > > > AVPacket::duration for codecs which support Interlace?
>> />/ > > >
>> />/ > > > I would like to solve my problem and rollback aforementioned patch,
>> />/ but
>> />/ > > > before that I wanted to check with you and probably encourage some
>> />/ > > > discussion.
>> />/ > > > What do you think? Should I elaborate a fix in different way?
>> />/ > >
>> />/ > > if you have a file with mixed interlaced and progressive packets
>> />/ > > does reverting the commit produce correct durations?
>> />/ > > what if a parser is initialized ?
>> />/ > >
>> />/ > > also can you share the/a file that is affected (its always useful
>> />/ > > if everyone can look at the same data insteda of everyone using a
>> />/ > > different file)
>> />/ > >
>> />/ > > [...]
>> />/ > > --
>> />/ > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>> />/ > >
>> />/ > > it is not once nor twice but times without number that the same ideas
>> />/ make
>> />/ > > their appearance in the world. -- Aristotle
>> />/ > >
>> />/ > > _______________________________________________
>> />/ > > ffmpeg-devel mailing list
>> />/ > >ffmpeg-devel at ffmpeg.org <http://ffmpeg.org/mailman/listinfo/ffmpeg-devel>
>> />/ > >http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> />/ > >
>> />/ > > Hi,
>> />/ >
>> />/ > I was told that I can share file only with Michael. File sent directly to
>> />/ > him. Sorry that I can not share it with everyone.
>> />/ > I had some time yesterday to study FFmpeg version which we use currently
>> />/ > (It's a few years old), and I found that we modified our FFmpeg and moved
>> />/ > AVPacket::duration computation back. Now we are updating FFmpeg and we
>> />/ > faced with this problem again. As long as we computed AVPacket::duration
>> />/ > all the time, looks like it's safe to rollback
>> />/ >
>> />/ http://git.videolan.org/?p=ffmpeg.git;a=commit;h=497431a5b645ffc39cf3acbd333c9ff0f3031adb
>> />/
>> />/ what about PAFF
>> />/ PAFF means mixed fields and frames
>> />/ the code sets duration to a constant, how is a constant going to
>> />/ equal 2 different durations ?
>> />/ also a packet can contain a frame that is supposed to be displayed
>> />/ for 3 fields time
>> />/ i must be missing something, as to me it looks like this works just
>> />/ because such cases are rare
>> />/
>> />/
>> />/ [...]
>> />/ --
>> />/ Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>> />/
>> />/ When the tyrant has disposed of foreign enemies by conquest or treaty, and
>> />/ there is nothing more to fear from them, then he is always stirring up
>> />/ some war or other, in order that the people may require a leader. -- Plato
>> />/
>> />/ _______________________________________________
>> />/ ffmpeg-devel mailing list
>> />/ ffmpeg-devel at ffmpeg.org <http://ffmpeg.org/mailman/listinfo/ffmpeg-devel>
>> />/ http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> />/
>> />/
>> /
>> / /Thu Nov 21 01:07:36 CET 2013/ /
>> /*Alex Sukhanov* alx.sukhanov at gmail.com <mailto:ffmpeg-devel%40ffmpeg.org?Subject=Re%3A%20%5BFFmpeg-devel%5D%20H264%20video%20and%20AVPacket%3A%3Aduration&In-Reply-To=%3CCAHufB%2BVi61XqK%3Di_FuNNVFrQL3MZUa2opDWZW2Z7jua9aOVmWw%40mail.gmail.com%3E>/ wrote:
>>> / /Michael,
>>> / /I think you are right: our old FFmpeg works just because it's a rare case.
>>> / /In worst scenario I can copy duration computation from old ffmpeg to new
>>> / /one in our private repository, but as I said, I would be happy to elaborate
>>> / /some universal solution here in public repository, which would fix issue
>>> / /1756 and set duration for each frame packet at the same time.
>>> / /What if FFmpeg could distinguish fields and frames and reset packet
>>> / /duration only if it's a field? That would work for me, because I don't deal
>>> / /with fields at all. What do you think?
>>> / /I'm not familiar with Ffmpeg yet, so I also would like to ask if it's
>>> / /possible and how better to do that?
>> Hi Michael,
>>
>> Alex Sukhanov kindly asked me to help with this issue cause I have essential video experience (participating in
>> Vanguard H.264 codec development).
>>
>> Since we are talking about ff_compute_frame_duration() function, I think it is safe to suppose we should
>> calculate exactly/frame/ duration (not/field/ or/slice/ or something else).
> ff_compute_frame_duration() is used to set AVPacket.duration
> if the AVPacket doesnt contain a frame then setting it to the frame
> duration will not be correct
>
> maybe ff_compute_frame_duration() should be renamed
>
> [...]
>
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Michael,
Roughly we can divide all interlace-supported streams into two major groups:
#############################################_____ ~ 90% (streams with
regular structure and where packet is equal to frame)
_____________________________________________##### ~ 10% (streams with
irregular structure or with non-frame packets)
Existing approach leaves all 100% of such streams with incorrect zero
packet duration.
Proposed approach allows 90% of streams to have correct duration, other
10% will still have incorrect duration.
Actually this behavior could be reflected in documentation saying, for
example, that in case of missing PTS and DTS, packet duration would be
set to default frame duration based on elementary stream properties.
Best Regards,
Mike
More information about the ffmpeg-devel
mailing list