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

[Mark Filipak (ffmpeg)]

On 02/12/2021 02:28 AM, pdr0 wrote:
> Mark Filipak (ffmpeg) wrote
>> On 02/12/2021 01:27 AM, pdr0 wrote:
>>> Mark Filipak (ffmpeg) wrote
>>>> Is there something about inputting raw frames that I don't know?
>>>>
>>>> I'm using 'vspipe' to pipe raw frames to 'ffmpeg -i pipe:'.
>>>> The vapoursynth script, 'Mark's.vpy', is known good.
>>>> The output of vapoursynth is known good.
>>>> I've tried to be careful to retain valid PTSs, but apparently have
>>>> failed.
>>>> The output should be around 1200 frames, but 364 frames are dropped.
>>>> I've frame stepped through the target, 'Mark's_script_6.mkv', and the
>>>> frames that are there are in
>>>> the correct order.
>>>> The only thing I can guess is that ffmpeg handles 48/1.001fps raw video
>>>> frames in such a way that
>>>> PTS is not valid or can't be changed with 'setpts=fps=60000/1001'.
>>>> Can anyone see an error. Or, lacking an error, does anyone know of a
>>>> workaround?
>>>>
>>>> Thanks.
>>>>
>>>> Mark's_script_6.cmd
>>>> =====
>>>> ECHO from vapoursynth import core>Mark's.vpy
>>>> ECHO video = core.ffms2.Source(source='Mark\'s_source.mkv')>>Mark's.vpy
>>>> ECHO import havsfunc as havsfunc>>Mark's.vpy
>>>> ECHO video = havsfunc.InterFrame(video, Preset="medium",
>>>> Tuning="smooth",
>>>> InputType="2D",
>>>> NewNum=48000, NewDen=1001, GPU=True)>>Mark's.vpy
>>>> ECHO video.set_output()>>Mark's.vpy
>>>> vspipe --y4m Mark's.vpy - | ffmpeg -thread_queue_size 2048 -i pipe:
>>>> -filter_complex
>>>> "setpts=N*1001/60000/TB, split[1][2], [1]shuffleframes=0 1 2 3 3,
>>>> select=not(eq(mod(n\,5)\,4))[3],
>>>> [2]tblend=all_expr='if(eq(mod(X,2),mod(Y,2)),TOP,BOTTOM)',
>>>> shuffleframes=0
>>>> 1 2 2 3,
>>>> select=eq(mod(n\,5)\,4)[4], [3][4]interleave" -i Mark's_source.mkv -map
>>>> 0:v -map 1:a -codec:v
>>>> libx265 -x265-params "crf=16:qcomp=0.60" -codec:a copy -codec:s copy
>>>> Mark's_script_6.mkv -y
>>>
>>>
>>> Are you trying to keep the same frames from vapoursynth output node, but
>>> assign 60000/1001 fps and timestamps instead of 48000/1001 ? (effectively
>>> making it a speed up)
>>>
>>> If so, the workaround is : add after the Interframe line
>>>
>>> video = core.std.AssumeFPS(video, fpsnum=60000, fpsden=1001)
>>
>> After your suggested addition to the python script, Mark's.vpy,
>> With '-filter_complex "setpts=N*1001/60000/TB, split[1][2]...' there are
>> 335 drops.
>> With '-filter_complex "split[1][2]...' there are 190 drops.
> 
> The workaround is correct for the PTS
> 
>   AssumeFPS is used to change the frame rate (and timestamps) without
> changing the frame count. It just assigns a framerate (and their PTS). So
> you would use that instead of setpts
> 
> There are no frame drops or additions from vapoursynth. The framecount,
> framerate and PTS are correct at that point. You can verify this by encoding
> the vpy script directly without other filters.
> 
> So this implies the some drops are from setpts, and some other drops are
> from some of your other filters

Well, I previously removed the 'setpts' directives with no change. Also, I previously tested with no 
ffmpeg filters at all and got the expected sped up video. I honestly can't see anything else to 
discover. But I'll start stripping filters one by one and hack a solution (or make a discovery). Of 
course, the 'shuffleframes' directives are most suspect, but I've used 'shuffleframes' in the past 
and succeeded.

Thanks for your help. It was instrumental. The rest is up to me.

-- 
The U.S. Senate and House should follow the ancient Roman model.
Their Princeps Senatus and Tribunus Plebis had their own armies.