Here are some initial comments:
Since mlt_tractor_pass_properties only operates on frames, maybe it should be a
member of mlt_frame?
mlt_tractor_pass_properties should probably have a more descriptive name. Which
properties specifically does it pass?
Could we convert the function to a single call to mlt_properties_pass_list()?
Might be easier to read.
https://github.com/mltframework/mlt/blob/master/src/framework/mlt_properties.h#L63
I think it would be good to submit a PR and continue the discussion there.
~Brian
On Friday, July 21, 2023 at 02:20:50 AM CDT, Jean-Baptiste Mardelle
<j...@kdenlive.org> wrote:
On Freitag, 21. Juli 2023 04:16:05 CEST you wrote:
> The cairoblend transition has an optimization that if the b frame is
> opaque, it will never request the a frame
> imagehttps://github.com/mltframework/mlt/blob/master/src/modules/frei0r/tra
> nsition_frei0r.c#L61 When this optimization is triggered, get_frame is never
> called on the a frame. As a result, the field order filter never has a
> chance to set the top_field_first flag on the a
> frame.https://github.com/mltframework/mlt/blob/master/src/modules/core/filt
> er_fieldorder.c#L115
>
> As a test, you can defeat the optimization in a couple of ways:* Set
> invert=1 on the transition* Set the color to be slightly transparent*
> Comment out the optimization in the code What should be done in this
> optimization case? I am not sure. Maybe copy the key image properties from
> the b frame to the a frame. There are many others that could be included.
> This might be a pretty good list here:
> https://github.com/mltframework/mlt/blob/master/src/framework/mlt_tractor.c
> #L379
Thanks a lot for the help and analysis, that helped. I was able to fix the
problem by moving the mlt_tractor 's frame properties stuff (as linked above)
to a new function called mlt_tractor_pass_properties, and then call this
function in the cairoblend and qtblend optimisation.
Attached is my patch. If that approach seems ok for you, I can create a pull
request.
Best regards,
Jean-Baptiste
> Or maybe there could be a different trick like all the contents of the
> a_frame and b_frame could be swapped when performing this optimization.
> ~Brian
>
>
> On Thursday, July 20, 2023 at 02:42:47 AM CDT, Jean-Baptiste Mardelle
> <j...@kdenlive.org> wrote:
>
> Hi all,
>
> I was recently made aware of an issue in interlaced rendering that seems
> like a bug but I am not exactly sure where the problem lies.
>
> The problem is that in some cases, MLT renders an interlaced video with
> bottom field first, even when asked for a top field first result. I tracked
> down the issue to some transitions. For example with a simple 2 track color
> sample :
>
> melt color:red out=20 -track color:blue out=20 -consumer avformat:test.mp4
> f=mxf progressive=0 real_time=-1 threads=0 top_field_first=1
> vcodec=mpeg2video
>
> Produces a correct top field first video. Now if you add a transition but
> keep the exact same rendering parameters:
>
> melt color:red out=20 -track color:blue out=20 -transition frei0r.cairoblend
> a_track=0 b_track=1 out=20 -consumer avformat:test.mp4 f=mxf progressive=0
> real_time=-1 threads=0 top_field_first=1 vcodec=mpeg2video
>
> You get an interlaced video with bottom field first!
> Not all transition seem to have this problem, but at least frei0r.cairoblend
> and qtblend do break the field order.
>
> FYI, I used mediainfo to detect the field order of the rendered videos.
>
> Do you have any hint on where / how to fix this ?
> Thanks a lot,
>
> Jean-Baptiste_______________________________________________
> Mlt-devel mailing list
> Mlt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mlt-devel
_______________________________________________
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel
