[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