Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#8308 closed defect (invalid)

First Frame POS is incorrect

Reported by: occvtech Owned by:
Priority: normal Component: undetermined
Version: git-master Keywords: h264
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Summary of the bug:

The attached file has an annex b h.264 bitstream that starts at offset (in bytes) 847. The stream is only 1 frame long (an I frame). The problem is that there are a large number of 0x 00 bytes that come before the bitstream at the beginning of the file.

If a basic command to rewrap the sequence into an MP4 container is used, the resulting file does not play back in standard players like VLC because the 0x 00 bytes are included into the container. I.E. the command I am using is:

ffmpeg -i FILE -c copy -f mp4 OUTPUT.mp4

One of the attempted solutions was to calculate the POS for the beginning of the frame and then use -skip_initial_bytes to get there, but ffprobe is misreporting where this position is. For example, if we run:

ffprobe -i FILE -show_frames

then the output reports the frame is at pkt_pos 0 -- which we know that it isn't actually.

This issue is not limited to this file. Every annex b file that we have tested reports a pkt_pos of 0 for the first frame even if we know it isn't.

Attachments (1)

incorrect POS.264 (9.3 KB ) - added by occvtech 2 years ago.
A file with a single I frame where the bit stream starts at a position that is non-0

Download all attachments as: .zip

Change History (4)

by occvtech, 2 years ago

Attachment: incorrect POS.264 added

A file with a single I frame where the bit stream starts at a position that is non-0

comment:1 by Carl Eugen Hoyos, 2 years ago

Keywords: h264 added; Inaccurate POS removed
Priority: importantnormal

comment:2 by mkver, 2 years ago

Resolution: fixed
Status: newclosed
  1. The very first byte_stream_nal_unit (verbiage from annex b of the H.264 standard) can contain an arbitrary amount of leading_zero_8bits, so the position is actually correct.
  2. Your ticket is missing the necessary information described here.
  3. I cannot reproduce your findings: The leading zero bytes are stripped when muxing into mp4 and the resulting file plays fine in VLC.

So I'm closing this as invalid.

comment:3 by mkver, 2 years ago

Resolution: fixedinvalid
Note: See TracTickets for help on using tickets.