Changes between Initial Version and Version 1 of Ticket #424, comment 6


Ignore:
Timestamp:
Oct 20, 2011, 5:03:05 PM (5 years ago)
Author:
mjs973
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #424, comment 6

    initial v1  
    331. The video stream was re-muxed at the the wrong frame rate. The original h264 elementary stream is 60.0 frames per second, but the .ts container was created using 30.0 frames per second. 
    44 
    5 2. This h264 elementary stream contains "buffering period SEI" and "pic timing SEI". The value in the pic timing dpb_output_delay field is completely wrong. It is typically a small interger value like "2", but in this sample it is 15628 (and it increments by 2 for each frame.) I'd guess this is a firmware error in the camcorder that created the compressed video stream. 
     52. This h264 elementary stream contains "buffering period SEI" and "pic timing SEI". The value in the pic timing dpb_output_delay field is completely wrong. It is typically a small integer value like "2", but in this sample it is 15628 (and it increments by 2 for each frame.) I'd guess this is a firmware error in the camcorder that created the compressed video stream. 
    66 
    77These SEI are optional in h264, and they are not needed for this stream. So, a workaround for this camcorder bug would be to re-mux the stream and tell the re-muxer to remove all the pic timing SEI NALs. 
    88 
    9 I don't see an easy way for the h264 decoder to work around this bug. The way I read the h.264 spec, such a large value for dpb_output_buffer is legal, but it is very, very unusual. 
     9I don't see an easy way for the h264 decoder to work around this bug. The way I read the h.264 spec, such a large value for dpb_output_delay is legal, but it is very, very unusual.