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
_______________________________________________
ffmpeg-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
