[FFmpeg-devel] H264 video and AVPacket::duration
Alex Sukhanov
alx.sukhanov at gmail.com
Thu Dec 12 02:54:21 CET 2013
On Fri, Dec 6, 2013 at 1:27 PM, Michael Niedermayer <michaelni at gmx.at>wrote:
> On Thu, Dec 05, 2013 at 11:41:16PM -0800, Alex Sukhanov wrote:
> > 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.
>
> m2ts has durations because it enables the parser, thats also why i
> asked:
> "
> > > Is the duration from the parser correct ?
> > > if it is correct why isnt the parser enabled if the duration is
> > > needed ?
> "
>
> you can enable the parser by setting need_parsing appropriately
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Avoid a single point of failure, be that a person or equipment.
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
Michael,
Thanks for hint. I checked it and it works. I've sent patch which enables
parser for H264 codec in FLV container:
http://ffmpeg.org/pipermail/ffmpeg-devel/2013-December/151896.html
Thanks for your help. I appreciate that!
More information about the ffmpeg-devel
mailing list