First Frame POS is incorrect

[occvtech]

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.

[occvtech]

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

[mkver]

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.