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” > > 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 _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
