On 07/25/2015 12:54 PM, Henk D. Schoneveld wrote:
On 25 Jul 2015, at 01:50, Peter Rabbitson <rabbit+l...@rabbit.us> wrote:
Hello!
I have a Logitech C920 affected by a know-yet-wontfix kernel uvc-video bug[1].
Given That I need a relatively recent kernel and it looks like the problematic
patch in 3.17+ will not be reverted, I am hoping that ffmpeg can somehow help
me with a workaround.
The problem in short is that while the hardware h264 encoder in the camera
provides correct PTS values, the kernel driver then throws them away and
recalculates them incorrectly based on the usb clock or something [2]. I am
wondering if there is a way to force ffmpeg to discard the (now incorrect) PTS
again, and assign its own base on the machine clock.
I (blindly at this point) tried various permutations of formats (muxed or raw)
and the various ffmpeg options of:
-fflags genpts
-copyts
-copytb [0/1]
-map <source>,<timing source>
All to no avail. Either the stream stutters[3] (when muxing into matroska or
mp4) or the stream runs smoothly but about 2x times faster than realtime (when
using -f h264 )
You need, afaik, slowmotion on a ‘bad’h264 to get a to be expected resulting.ext
I think you’ll need something like -vf “setpts=(1/<speed>)*PTS”
What is <speed> in this case...? The camera returns a variable frame
rate afaik...
_______________________________________________
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
