AVStream.start_time incorrect by 2 frames for Sony XDCAM-EX files

[rmk]

All samples of Sony XDCAM-EX files start with two B-frames (presentation order) and then an I-frame. The two B-frames decode fine. The pictures look good in all cases. However, AVStream.start_time for these streams is always returned as the PTS of the first I-frame. Since the field is documented as the PTS of the first frame I thought this behavior is an error since I assume that "first" is meant as in presentation order as I thought the start_time field was used for things like seek offset calculations but I might be wrong here. Otherwise it would be good to make the documentation more specific here.

I uploaded a sample (66MB) to

​http://www.datafilehost.com/download-abdaeffe.html

[Carl Eugen Hoyos]

Is a 2.5MB sample not sufficient to show the problem?

[rmk]

Replying to cehoyos:

Is a 2.5MB sample not sufficient to show the problem?

yes, of course it would have been but I do not own that camera and I am very happy that someone was nice enough to take the time to produce a few short (10-14 seconds) samples that allow to unambiguously identify the first few frames to visually check what is being decoded, and allow me to use them for filing ffmpeg bug reports. At the bit rate of the camera 2.5 MB is hardly doable and anyway, all short samples I have are in that order of magnitude, so I hope it's OK as it is.

[Carl Eugen Hoyos]

Is the attached sample sufficient to reproduce the problem?
If yes, please add compete uncut output of "ffmpeg -v 9 -loglevel 99 -i Mesht0456_01_cut.MP4" (latest git head).

[rmk]

Yes.

./ffmpeg -v 9 -loglevel 99 -i ~/tmp/Mesht0456_01_cut.MP4
ffmpeg version N-32659-gbfadca1, Copyright (c) 2000-2011 the FFmpeg developers

built on Sep 17 2011 09:56:59 with gcc 4.2.1 (Apple Inc. build 5664)
configuration: --enable-gpl
libavutil 51. 16. 0 / 51. 16. 0
libavcodec 53. 15. 0 / 53. 15. 0
libavformat 53. 12. 0 / 53. 12. 0
libavdevice 53. 3. 3 / 53. 3. 3
libavfilter 2. 43. 0 / 2. 43. 0
libswscale 2. 1. 0 / 2. 1. 0
libpostproc 51. 2. 0 / 51. 2. 0

[mov,mp4,m4a,3gp,3g2,mj2 @ 0x10100ec00] Format mov,mp4,m4a,3gp,3g2,mj2 probed with size=2048 and score=100
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x10100ec00] ISO: File Type Major Brand: mp42
[mpeg2video @ 0x101009800] Unsupported bit depth: 0
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x10100ec00] All info found
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/Users/krueger/tmp/Mesht0456_01_cut.MP4':

Metadata:

major_brand : mp42
minor_version : 0
compatible_brands: mp42
creation_time : 2011-07-27 16:00:00

Duration: 00:00:14.71, start: 0.000000, bitrate: 1336 kb/s

Stream #0.0(eng), 1, 1/30000: Video: mpeg2video (Main) (mp4v / 0x7634706D), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 1001/60000, 35000 kb/s, 29.97 fps, 29.97 tbr, 30k tbn, 59.94 tbc
Metadata:

creation_time : 2011-07-27 16:00:00

Stream #0.1(eng), 24, 1/48000: Audio: pcm_s16be (twos / 0x736F7774), 48000 Hz, 2 channels, s16, 1536 kb/s
Metadata:

creation_time : 2011-07-27 16:00:00

At least one output file must be specified

[rmk]

The initial GOP header has closed_gop=1 and broken_link=0 (spec section 6.3.8, debug output: GOP ( 0:00:00.[00]) closed_gop=1 broken_link=0). Together with the fact that the initial B-frames decode fine, I tend to believe that the stream is valid and ffmpeg treats the case incorrectly assuming I do not misunderstand the semantics of AVStream.start_time. If that is correct the warning
[mpeg2video @ 0x10106f400] warning: first frame is no keyframe
probably should not be triggered in this case either.

[Baptiste Coudurier]

It's in presentation order so it's correct.
And the warning is bogus.

[rmk]

if it is in presentation order then it's incorrect because the pts of the first frame in presentation order (which is a B-frame) for the sample and all other XDCAM-EX camera samples I have checked is 0 but the field is set to the non-zero PTS of the first I-frame which is the third frame in presentation order.

[Baptiste Coudurier]

Oh, you mean the field in the AVStream, then yes in that case, it's incorrect.
There is a patch on the ML about this I think.
I'm reopening bug.

[rmk]

Thanks. I must have missed the patch on the ML then. If you happen to have the link it would be nice to attach it to the issue.

[Balling]

This looks like is fixed?

I used ffprobe -show_frames -select_streams v

and first two B-frames have pkt_pts_time=0.000000 and pkt_pts_time=0.033367...

The warning is for the broken by cutting frame in the end (previous to the last frame):

[mov,mp4,m4a,3gp,3g2,mj2 @ 00000209572fdf40] Packet corrupt (stream = 0, dts = 14014).