Opened 13 years ago

Closed 13 years ago

Last modified 10 years ago

#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)

00372.MTS (1.5 MB ) - added by rmk 13 years ago.
Panasonic Lumix GH2 720p50

Download all attachments as: .zip

Change History (14)

by rmk, 13 years ago

Attachment: 00372.MTS added

Panasonic Lumix GH2 720p50

comment:1 by Carl Eugen Hoyos, 13 years ago

Status: newopen

If you believe this is a regression, please find the version introducing the problem using git bisect.

comment:2 by rmk, 13 years ago

it appears that after commit 512f973eac9a8c38ca33f089b6f3bb433ffc6a2e the timestamps were broken.

comment:3 by rmk, 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:6 by rmk, 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 rmk, 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 reimar, 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:10 by reimar, 13 years ago

Resolution: fixed
Status: openclosed

Change pushed, please confirm it fixes all issues you were seeing.

comment:11 by rmk, 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 Carl Eugen Hoyos, 13 years ago

Keywords: H264 TS added

comment:13 by Carl Eugen Hoyos, 10 years ago

Keywords: mpegts added; TS removed
Note: See TracTickets for help on using tickets.