#360 closed defect (fixed)
Video packet timestamps broken for Panasonic Lumix GH2 AVCHD files
Reported by: | rmk | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | avformat |
Version: | unspecified | Keywords: | H264 mpegts |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
The attached AVCHD file is from a Panasonic Lumix GH2 in 720p50 mode. These files used to be decodable by old ffmpeg versions (the last I checked was SVN-r26108, roughly from the beginning of this year).
With current git the video packets' timestamps are completely broken (we noticed when we upgraded our libraries for an application that uses libavformat/libavcodec) and also ffprobe displays N/A for the video packets' PTS values.
Attachments (1)
Change History (14)
by , 13 years ago
comment:1 by , 13 years ago
Status: | new → open |
---|
If you believe this is a regression, please find the version introducing the problem using git bisect.
comment:2 by , 13 years ago
it appears that after commit 512f973eac9a8c38ca33f089b6f3bb433ffc6a2e the timestamps were broken.
comment:3 by , 13 years ago
I don't know if that is of interest but it's broken in current libav as well. In ffmbc it's not.
comment:4 by , 13 years ago
Could you make a sample similar to this one?
http://samples.mplayerhq.hu/V-codecs/h264/sony-hdr-cx6-avchd-interlaced-decoding-problem/
and upload it to http://www.datafilehost.com/
comment:6 by , 13 years ago
I would like to offer a bounty of 500 Euro for fixing this. The individual doing the fixing can decide whether this is supposed to be paid to an organization (ffmpeg foundation?) or to the individual personally. Condition is that the timestamps are decoded in such a way that audio/video sync is OK for material from this camera and the fix is accepted into the git master tree. If more samples are required, let me know and I will provide them.
comment:7 by , 13 years ago
The place where the timestamps essentially get erased (before that they are correct AFAICS) is this block in libavformat/utils.c in compute_pkt_fields:
some mpeg2 in mpeg-ps lack dts (issue171 / input_file.mpg)
we take the conservative approach and discard both
Note, if this is misbehaving for a H.264 file then possibly presentation_delayed is not set correctly.
if(delay==1 && pkt->dts == pkt->pts && pkt->dts != AV_NOPTS_VALUE && presentation_delayed){
av_log(s, AV_LOG_DEBUG, "invalid dts/pts combination\n");
pkt->dts= pkt->pts= AV_NOPTS_VALUE;
}
If I remove this, the file is decoded as I would expect it. As the comment suggests, it is indeed the case that presentation_delayed is set to 1 because st->codec->has_b_frames is 1, which I don't understand since the h.264 stream only contains I- and P-slices as far as I could see by adding debug output in h264.c. I hope this helps in finding a proper fix. Until it has been fixed a workaround for GH1/GH2 owners is to restrict this check to non-H.264 codecs.
comment:8 by , 13 years ago
I have been looking into a different strangeness, maybe that is even the deeper cause.
The estimate_timings_from_pts function parses through the file a bit, then seeks back again to start reading again.
The strange thing is, that the first pass through all the video packets get the right time stamps, they don't on the second. So obviously some state gets stuck in a bad state (possibly caused by this rather non-proper seeking).
So possibly this bad state is actually the B-frames detection...
comment:9 by , 13 years ago
It was a bit more convoluted, see http://ffmpeg.org/pipermail/ffmpeg-devel/2011-August/114017.html
comment:10 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | open → closed |
Change pushed, please confirm it fixes all issues you were seeing.
comment:11 by , 13 years ago
Confirmed fixed. Sorry for the late response. Somehow I didn't get a notification email about the closing of this ticket.
comment:12 by , 13 years ago
Keywords: | H264 TS added |
---|
comment:13 by , 10 years ago
Keywords: | mpegts added; TS removed |
---|
Panasonic Lumix GH2 720p50