[FFmpeg-user] Help needed to work around incorrect DTS when capturing H264 from a Logitech C920

[Peter Rabbitson]

On 12/15/2014 06:49 PM, Carl Eugen Hoyos wrote:
> Peter Rabbitson <rabbit+list <at> rabbit.us> writes:
>
>> ffmpeg -r 30 -f v4l2 -s 1920x1080 -vcodec h264
>
> I believe -r 30 does not do what you think it does
> and it may be the reason for the issues you see.
> Is there a problem if you remove it?
>
>> -i /dev/v4l/by-id/*HD_Pro_Webcam_C920* \
>>     -c:v copy -f matroska -
>

No difference at all if I do the above. Here is the attempted 
command/output [1] and the verbatim result [2]

> Since matroska is really the wrong format for this
> task: Does it make a difference if you write a raw
> stream? The advantage is that if the issue is still
> reproducible, you can use "-r 30" in a second run
> to smooth the timestamps.
>

It makes a difference - things are bad in a different way. The resulting 
raw h264 stream behaves erratically. The live playback from the command 
in [3] has occasional "slip-ups" (2 seconds pass very close to each 
other), and a playback of the stream via `ffplay -i stdin.h264` seems to 
run faster. Since there is no way to upload this raw data to vimeo - you 
can get the result of [3] via:

wget -qO- 
https://gist.github.com/ribasushi/fab13b785c3c6e1b70a3/download | \
tar --wildcards -zxOf - '*/stdin.h264' > stdin.h264
(SHA1:9337ca9b5c868ff9347249827050247781e3e3a8)

At this point I am starting to wonder whether I simply have a bad 
camera, although I never noticed anything wrong on windows (though I 
never tried to capture a high-speed timer either...)

If anyone has more ideas - I am all ears

[1] 
https://gist.github.com/ribasushi/fab13b785c3c6e1b70a3#file-capture_without_rate
[2] https://vimeo.com/114641914 11Mb 
SHA1:a581bd95070cf146dc9e03681cec7262048169d8
[3] 
https://gist.github.com/ribasushi/fab13b785c3c6e1b70a3#file-capture_in_264