[FFmpeg-trac] #4644(avdevice:new): Corrupt H264 when streaming H264 from v4l2 device

[FFmpeg]

#4644: Corrupt H264 when streaming H264 from v4l2 device
------------------------------------+------------------------------------
             Reporter:  noah        |                    Owner:
                 Type:  defect      |                   Status:  new
             Priority:  normal      |                Component:  avdevice
              Version:  git-master  |               Resolution:
             Keywords:  v4l2 h264   |               Blocked By:
             Blocking:              |  Reproduced by developer:  0
Analyzed by developer:  0           |
------------------------------------+------------------------------------

Comment (by noah):

 Replying to [comment:1 cehoyos]:
 > Replying to [ticket:4644 noah]:
 > > Changing AVSTREAM_PARSE_HEADERS to AVSTREAM_PARSE_FULL in
 libavdevice/v4l2.c:v4l2_read_header() fixes the problem for me, though I'm
 not sure it's the correct solution.
 >
 > Could you send a patch made with {{{git format-patch}}} to the
 development mailing list?

 Thanks for commenting, Carl Eugen.  I will consider your suggestion.

 I found some interesting comments in `libavformat/avformat.h`:
 {{{
 enum AVStreamParseType {
     AVSTREAM_PARSE_NONE,
     AVSTREAM_PARSE_FULL,       /**< full parsing and repack */
     AVSTREAM_PARSE_HEADERS,    /**< Only parse headers, do not repack. */
     AVSTREAM_PARSE_TIMESTAMPS, /**< full parsing and interpolation of
 timestamps for frames not starting on a packet boundary */
     AVSTREAM_PARSE_FULL_ONCE,  /**< full parsing and repack of the first
 frame only, only implemented for H.264 currently */
     AVSTREAM_PARSE_FULL_RAW=MKTAG(0,'R','A','W'),       /**< full parsing
 and repack with timestamp and position generation by parser for raw
                                                              this assumes
 that each packet in the file contains no demuxer level headers and
                                                              just codec
 level data, otherwise position generation would fail */
 };
 }}}

 Of those, all but `AVSTREAM_PARSE_NONE` and `AVSTREAM_PARSE_HEADERS`
 appear to produce video that can be played back in VLC (3.0.0-git).
 Judging from the notes about repacking, I assume
 `AVSTREAM_PARSE_FULL_ONCE` should be the most efficient option of them,
 no?

 I still have problems with non-monotonically increasing DTS and that `-t
 10 -i /dev/video0` doesn't stop reading after 10 seconds (regardless of
 which full parsing option I use), but I guess I'll have to ask the
 Raspberry Pi folks why DTS is wrong in the camera output stream.  Example
 warning messages from the h264 muxer:
 {{{
 [h264 @ 0x148aef0] Application provided invalid, non monotonically
 increasing dts to muxer in stream 0: 5792923 >= 5716981
 [h264 @ 0x148aef0] Application provided invalid, non monotonically
 increasing dts to muxer in stream 0: 5792923 >= 5756960
 [h264 @ 0x148aef0] Application provided invalid, non monotonically
 increasing dts to muxer
 n stream 0: 10590120 >= 9594933
 [h264 @ 0x148aef0] Application provided invalid, non monotonically
 increasing dts to muxer in stream 0: 10590120 >= 9634912
 [h264 @ 0x148aef0] Application provided invalid, non monotonically
 increasing dts to muxer in stream 0: 10590120 >= 9674891
 }}}

 For the sake of completeness, I'm attaching two new reports where I use
 `AVSTREAM_PARSE_FULL_ONCE`:
 {{{
 v4l2-ctl -c video_bitrate=10000000  -c h264_i_frame_period=120  -c
 repeat_sequence_header=0 -v width=1280,height=720,pixelformat=h264
 ./ffmpeg-full-once -report -f v4l2 -input_format h264 -framerate 25 -t 10
 -i /dev/video0 -c copy -an -loglevel debug  -f h264  -y a-full-once-
 rsh-0.h264
 }}}
 and:
 {{{
 v4l2-ctl -c video_bitrate=10000000  -c h264_i_frame_period=120  -c
 repeat_sequence_header=1 -v width=1280,height=720,pixelformat=h264
 ./ffmpeg-full-once -report -f v4l2 -input_format h264 -framerate 25 -t 10
 -i /dev/video0 -c copy -an -loglevel debug  -f h264  -y a-full-once-
 rsh-1.h264
 }}}

--
Ticket URL: <https://trac.ffmpeg.org/ticket/4644#comment:2>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker