[FFmpeg-user] Copy-capturing h264 input while force-rewriting the PTS

Peter Rabbitson rabbit+list at rabbit.us
Sat Jul 25 01:50:44 CEST 2015


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


More information about the ffmpeg-user mailing list