bad first_dts in h264 file

[DonMoir]

The file bad_first_dts_h264_cut.mp4 has a first_dts of 7 in the video stream. I think it should be zero. The first video packet has a dts of zero and the first index entry has a timestamp of zero.

Not sure I can show you a command line that will reproduce the problem.

[DonMoir]

Outside of a short term problem with RELATIVE_TS_BASE in some ogg files, this is the first time I am aware of file with a bad first_dts.

[DonMoir]

This appears to be a regression. I found another h264 file with same problem.

Last known good to me is: N-40301-gc1fe2db

[Carl Eugen Hoyos]

Replying to DonMoir:

This appears to be a regression. I found another h264 file with same problem.

Last known good to me is: N-40301-gc1fe2db

Does that mean this is a regression since 68b9ed8 ?
That is very hard to believe...

[DonMoir]

Not sure when the real last good was. I don't have an infinite number of past versions and with the version stated it worked. I don't update often because of problems like these. Generally when I download a new ffmpeg version, I spend a lot of time checking it out before I hand it out.

[Carl Eugen Hoyos]

Please use git bisect to find the version introducing the problem.

[DonMoir]

I think it would be probably less time consuming for someone to just take a look at the code for h264. I already worked around it and have to move forward with other work.

[DonMoir]

commit 2107009 (8-3-2012) breaks first_dts for the above file and others.

Reference: Niedermayer - compute_pkt_fields: do not attempt to calculate dts when the delay hasnt been estimated.

commit 3e1cf49 (8-3-2012) is ok and is the commit just previous to 2107009

[DonMoir]

Hell, forget the commit numbers above :)

Offending commit: ​http://git.videolan.org/?p=ffmpeg.git;a=commit;h=3e1cf49676fb2df6445000c30dc6377b808b96da

Immediately previous and ok: ​http://git.videolan.org/?p=ffmpeg.git;a=commit;h=2107009e7d351ff83a87fda161cc5269d2752428

[Michael Niedermayer]

the first streams first dts is 0:

ff_read_packet stream=0, pts=0, dts=0, size=1021, duration=1, flags=1
read_frame_internal stream=0, pts=0, dts=0, size=1021, duration=1, flags=1
demuxer -> ist_index:0 type:video next_dts:NOPTS next_dts_time:NOPTS next_pts:NOPTS next_pts_time:NOPTS pkt_pts:0 pkt_pts_time:0 pkt_dts:0 pkt_dts_time:0 off:0

first_dts printed after av_read_frame() is also 0

[DonMoir]

Yeah, works now. Thanks