[FFmpeg-devel] H264 video and AVPacket::duration
Alex Sukhanov
alx.sukhanov at gmail.com
Fri Dec 6 08:41:16 CET 2013
On Wed, Dec 4, 2013 at 3:33 PM, Michael Niedermayer <michaelni at gmx.at>wrote:
> On Thu, Dec 05, 2013 at 12:31:06AM +0400, Michael Doilnitsyn 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:
> 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.
>
> is the problem specific to h264 in flv ?
> are these irregular streams allowed in flv ? (i would be interrested in a
> sample if so)
> if they are not allowed, maybe the flv demuxer could set the duration
>
> Or
> Is the duration from the parser correct ?
> if it is correct why isnt the parser enabled if the duration is
> needed ?
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> DNS cache poisoning attacks, popular search engine, Google internet
> authority
> dont be evil, please
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
My understanding is that this problem is specific to all codecs which may
have fields inside, and this problem happens only for containers which
operate with timestamps (not duration like MP4).
Interesting thing is that I ran ffprobe for FLV, MKV and M2TS containers
(all of them store timestamps), and only FLV and MKV currently have this
problem. M2TS Container works just fine and m2ts demuxer sets AVPacket
duration for all video packets.
Michael D: Can you please check why m2ts Demuxer sets all packets in
contrast to FLV demuxer? I suspect answer on this question may give you an
idea how to fix this problem.
More information about the ffmpeg-devel
mailing list