Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#1646 closed defect (worksforme)

bad first_dts in h264 file

Reported by: DonMoir Owned by:
Priority: important Component: undetermined
Version: git-master Keywords: h264 regression
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

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.

Attachments (1)

bad_first_dts_h264_cut.mp4 (488.3 KB) - added by DonMoir 4 years ago.

Download all attachments as: .zip

Change History (12)

Changed 4 years ago by DonMoir

comment:1 Changed 4 years ago by 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.

comment:2 follow-up: Changed 4 years ago by DonMoir

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

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

comment:3 in reply to: ↑ 2 Changed 4 years ago by cehoyos

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...

comment:4 Changed 4 years ago by 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.

comment:5 Changed 4 years ago by cehoyos

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

comment:6 Changed 4 years ago by 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.

comment:7 Changed 4 years ago by 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

Last edited 4 years ago by DonMoir (previous) (diff)

comment:9 Changed 4 years ago by cehoyos

  • Keywords h264 regression added
  • Priority changed from normal to important
  • Status changed from new to open
  • Version changed from unspecified to git-master

comment:10 Changed 4 years ago by michael

  • Resolution set to worksforme
  • Status changed from open to closed

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

comment:11 Changed 4 years ago by DonMoir

Yeah, works now. Thanks

Note: See TracTickets for help on using tickets.