On Wednesday, September 2, 2015 7:50 AM, Carl Eugen Hoyos <ceho...@ag.or.at> wrote: >Hi! > >As Clément always pointed out correctly, the issues users see with >fieldmatch and mixed telecined and progressive content have nothing >to do with decimate (and of course not fieldmatch) but with the >specifics of our fps filter (see my ignored mail for details). > >Attached patch should help, please comment. > >Carl Eugen
As the author of dejudder it does not produce exactly evenly paced frames. It basically does a rolling average of the last n (default of 4 for pullup 30->24 fps) frames for the PTS of the next frame. If the judder is just noise, and you are using it as denoiser on the PTS's of the input frames, it should work for that. However, it would work better with a larger n. If the PTS's are just randomly noised, then the standard deviation should scale as 1/n. If the judder is periodic, then you want to fit your n to that judder, if you don't know just pick a large n. The default n is 4 which is for the judder of dropping every fifth frame (as pullup does on telecined 23 material) Do you have a sample where dejudder used like this helps? If so does it work better with larger n? Your suggestion is for material that is a mix of 30 fps progressive and 24->30 telecined? I don't know that you would want to decimate that. It will produce judder from the dropped frames. That might be a usecase for the new framerate filter. Or are you offering a suggestion for mixed 24fps progressive and 24->30 telecined? In that case it seems like this should work. You are using dejudder & fps to produce a stream of frames lies ABCDDEFGHH... then decimate drops the dups. Seems brutal. Is there a reason why this filter chain is preferable to pullup,dejudder? (perhaps with fps) or is this just another option? Nick _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
