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 )

Is there *anything* ffmpeg can do to help me here, or do I need to compile a custom kernel ripping out the problematic commit[4]?

Thanks!


[1] http://sourceforge.net/p/linux-uvc/mailman/message/33564420/
[2] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/media/video/uvc/uvc_video.c?id=66847ef0#n524
[3] https://vimeo.com/114550042
[4] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=66847ef
_______________________________________________
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Reply via email to