[FFmpeg-devel] H264 video and AVPacket::duration
Ronald S. Bultje
rsbultje at gmail.com
Wed Dec 4 21:49:34 CET 2013
Hi,
On Wed, Dec 4, 2013 at 3:31 PM, Michael Doilnitsyn <mdoilnitsyn at gmail.com>wrote:
> 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: 9FF2128B147EF6730BADF133611EC7
>>> 87040B0FAB
>>> />/ > >
>>> />/ > > 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: 9FF2128B147EF6730BADF133611EC7
>>> 87040B0FAB
>>> />/
>>> />/ 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.
In engineering circles, such an approach would be called "a dirty hack".
Ronald
More information about the ffmpeg-devel
mailing list