Ticket #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
Change History
comment:1 Changed 9 months 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: ↓ 3 Changed 9 months 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 9 months 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 9 months 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 9 months ago by cehoyos
Please use git bisect to find the version introducing the problem.
comment:6 Changed 9 months 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 9 months 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
comment:8 Changed 9 months ago by 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
comment:9 Changed 9 months ago by cehoyos
- Keywords h264 regression added
- Priority changed from normal to important
- Version changed from unspecified to git-master
- Status changed from new to open
comment:10 Changed 9 months ago by michael
- Status changed from open to closed
- Resolution set to worksforme
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 9 months ago by DonMoir
Yeah, works now. Thanks



