Opened 13 years ago

Last modified 3 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

Description

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

Attachments (1)

Mesht0456_01_cut.MP4 (2.3 MB ) - added by Carl Eugen Hoyos 13 years ago.

Change History (12)

comment:1 by Carl Eugen Hoyos, 13 years ago

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

in reply to:  1 comment:2 by rmk, 13 years ago

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.

by Carl Eugen Hoyos, 13 years ago

Attachment: Mesht0456_01_cut.MP4 added

comment:3 by Carl Eugen Hoyos, 13 years ago

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 by rmk, 13 years ago

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

comment:5 by rmk, 12 years ago

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 by Baptiste Coudurier, 12 years ago

Resolution: invalid
Status: newclosed

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

comment:7 by rmk, 12 years ago

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 by Baptiste Coudurier, 12 years ago

Component: undeterminedavformat
Resolution: invalid
Status: closedreopened

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 by rmk, 12 years ago

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 by Michael Niedermayer, 12 years ago

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

comment:11 by Balling, 3 years ago

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 cutted frame in the end (previous to the last frame):

[mov,mp4,m4a,3gp,3g2,mj2 @ 00000209572fdf40] Packet corrupt (stream = 0, dts = 14014).
Last edited 3 years ago by Balling (previous) (diff)
Note: See TracTickets for help on using tickets.