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

[Henk D. Schoneveld]

On 25 Jul 2015, at 01:50, Peter Rabbitson <rabbit+list at 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”
> 
> 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 at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user