Tjoppen
Tjoppen
Worth noting is that the current behavior violates the contract of sws_scale(): ```C /** * Scale the image slice in srcSlice and put the resulting scaled * slice in the...
>I understand sws_scale_frame handles interlace now even for scaling Actually looking at vf_scale.c it appears it doesn't. But it's not overly difficult to make the necessary preparations.
The filtergraph approach looks like it has potential for our use case. But the output looks very very wrong. I suspect pixel format conversion may be applied twice: ```bash melt...
That doesn't sound right. As it is currently in master it's a miracle it doesn't crash. Surely if the filtergraph produces a pixel format that mlt supports then that should...
See PR #865
What I would suggest is keeping the contexts around, not repeatedly getting and freeing them. Basically do the same thing as libavfilter/vf_scale.c. It's also possible to do the same thing...
Digging more into this the scaling becomes far less bad when using 1024x429 which is possible with 4:2:2. convert_image() also becomes needlessly expensive due to conversion from BT.709 to BT.601....
If the yuv422p -> yuv422p can be avoided then there's potential to shave off another second: 12.160s, meaning 16% faster
I pushed a patch for the initFilter() slowness to FFmpeg just now as a678b0c252
Yeah I may actually have meant whatever the corresponding nonplanar format in libavcodec is called.