[FFmpeg-trac] #4644(avdevice:new): Corrupt H264 when streaming H264 from v4l2 device
FFmpeg
trac at avcodec.org
Tue Jun 23 22:27:35 CEST 2015
#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
More information about the FFmpeg-trac
mailing list