Opened 6 years ago

Last modified 6 years ago

#479 reopened defect

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

Reported by: rmk Owned by:
Priority: normal Component: avformat
Version: unspecified Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


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

Attachments (1)

Mesht0456_01_cut.MP4 (2.3 MB) - added by cehoyos 6 years ago.

Change History (11)

comment:1 follow-up: Changed 6 years ago by cehoyos

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

comment:2 in reply to: ↑ 1 Changed 6 years ago by 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.

Changed 6 years ago by cehoyos

comment:3 Changed 6 years ago by cehoyos

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

comment:4 Changed 6 years ago by rmk


./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':


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

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

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

At least one output file must be specified

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

comment:6 Changed 6 years ago by bcoudurier

  • Resolution set to invalid
  • Status changed from new to closed

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

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

comment:8 Changed 6 years ago by bcoudurier

  • Component changed from undetermined to avformat
  • Resolution invalid deleted
  • Status changed from closed to reopened

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.

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

comment:10 Changed 6 years ago by michael

  • Summary changed from AVStream.start_time incorrect for Sony XDCAM-EX files to AVStream.start_time incorrect by 2 frames for Sony XDCAM-EX files
Note: See TracTickets for help on using tickets.