[FFmpeg-user] Is there something about inputting raw frames

[pdr0]

Mark Filipak (ffmpeg) wrote
> On 02/12/2021 10:34 AM, pdr0 wrote:
>> Mark Filipak (ffmpeg) wrote
> 
> -snip-
> 
>> "72fps" or "144fps" equivalent in a cinema is not the same thing - the
>> analogy would be the cinema is repeating frames, vs interpolating new
>> in-between frames on a motion flow TV. ...
> 
> To some transcodes, repeating frames does apply. To interpolation, some
> other considerations apply. 
> Also, I contend that, due to its real-time schedule, a motion flow TV
> can't faithfully reproduce 24 
> pictures per second converted to 60 pictures per second via motion vector
> interperpolation.

Motion flow in TV's is the hardware (realtime) implementation of software
optical flow. There are different trade names by different manufacturers,
but they all use motion interpolation and optical flow.  For a 24pN native
source, it's a real time conversion to 120fps, then evenly divided by 2 for
60fps. Each frame is "evenly spaced in time".   It produces similar results
to mvtools2, interframe, twixtor, svpflow, kronos, DAIN, all the ones I
mentioned in your other thread . The TV version of optical flow even produce
similar artifacts. This has been around for many years, probably 10-15
years,  and those TV optical flow sets almost as long. It might be new to
you , but this is all old news.



If you're still interested, I tested the avs script and produces the proper
results you want for the checkerblend with InterleaveEvery . The short
version is it's probably not worth it if you're using libx265. Minterpolate
was your bottleneck; interframe or any interplolation script is unlikely to
be a bottleneck unless you use very slow settings




Observations . This was tested on a 5 year old laptop. 

If we take Interframe @ 60000/1001 ( Preset="medium", Tuning="smooth",
InputType="2D", NewNum=60000, NewDen=1001, GPU=True) I used cores=8 prefetch
8 for the "baseline" avs version

Interframe @60000/1001 ffmpeg pipe speed 38-39fps
Interframe @48000/1001 ffmpeg pipe speed 46-47fps
Interleaveevery checker ffmpeg pipe speed  49-50fps (interesting that this
was faster than the Interframe 48000/1001 run alone)

Actual encoding speeds
interframe @60000/1001 libx265 8-8.5fps
interleaveevery checker libx265 7-7.5fps (interesting that the pipe speed
was faster, but the actual encoding speed slower than just using interframe)
interframe @60000/1001 libx264 21-22fps
interleaveevery checker libx264 22-23fps




You can measure pipe speed vs actual encoding speeds to help determine where
some bottlenecks are

ffmpeg -i input.avs -an -f null NUL

or

vspipe --y4m input.vpy - | ffmpeg -f yuv4mpegpipe -i - -an -f null NUL

There are other tools like vsedit, avspmod, avsmeter that can help you
optimize scripts by benchmarking speeds, so you can adjust settings, preview
results. If you're not using these, they are helpful tools that complement
ffmpeg workflows



When you were using minterpolate - that was probably the bottleneck. So any
filter chain speed optimization will make a significant difference in
realized encoding speed when using minterpolate , and could be worth
pursuing if speed optimization vs. quality was your goal. 

But interframe pipe speed into ffmpeg is much faster, and generally not the
bottleneck. (You could use faster interframe settings if you needed to). 
It's better to address bottlenecks (more "bang for you buck") . On this
hardware, when using the checker blend approach, there was marginal speed
improvement with additional artifacts and jerkiness , and it actually was
slower than just interframe when using libx265 - that latter observation was
unexpected because the pipe speed was faster than Interframe @60000/1001 .
Might be some threading issues with the avs version, or some LUTs not
optimized eg. mt_lutspa for the checker mask


On my setup, libx265 (using your same settings) - is the bottleneck. So
adusting the script or filters will make little differnece (but  faster
script means more resources for libx265 to use, it'll be marginally faster)
. YMMV between hardware. In all cases , the input pipe speed is
significantly faster than the actual libx265 encoding speed. Just switching
to libx264 or using faster libx265 settings more than doubled the speed for
me

Check your bottlenecks; if you need more info on scripts or procedure or
samples let me know. I don't think I can easily translate it to vapoursynth,
my python is weak. The InterleaveEvery function and frame based nature of
avisynth is what makes it easy to do




--
Sent from: http://ffmpeg-users.933282.n4.nabble.com/