-
Notifications
You must be signed in to change notification settings - Fork 325
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Color shift after first frame of output when using two composite transitions #623
Comments
If it's helpful at all, here's a shorter version of input.xml where I stripped out the pieces that didn't seem to be relevant. It should still reproduce the issue.
|
I wonder if this problem still exists in MLT master? I do not reproduce the problem, but I also do not have your source file pets000.mov One possible explanation is if your source file might be incorrectly identifying the colorspace. It says it is 709, but maybe it is actually 601. If this is the case, then the first time it require conversion it will experience a subtle color shift. It is not uncommon for a transition to trigger a colorspace conversion since it operates in 4:2:2 while the source file is 4:2:0. |
Hm, I just pulled and recompiled (SHA 817e4d8), but the output seems the same for me. The source file pets000.mov can be downloaded here if you decide to look any further: https://embed-ssl.wistia.com/deliveries/d2e5245e04b6bcdce7981a5bb550b602/pets000.mov?disposition=attachment. To your point, relevant pieces of ffprobe on pets000.mov:
And from mediainfo:
Still, if MLT is converting the output to a different colorspace, and the transition applies to the entire duration of the file, why wouldn't it be converted on the first frame, too? Then again, if it's not showing up for you when testing with the same input file, maybe there's something else entirely going on with my setup. |
A workaround for your problem is to replace the composite transitions with affine instead. It is as easy as changing:
Perhaps there is a bug in the composite transition. I did not investigate inside the composite transition because it has so many other deficiencies relative to the affine transition that I typically recommend people use the affine transition in all cases. The only drawback is that the affine transition is slightly slower. |
Hi there! I'm diving into MLT to composite two videos next to each other at specific sizes and orientations. They may animate between different orientations, but for this issue, I kept it to just one to demonstrate the problem. The problem is that I often see a noticeable color shift right after the video starts. If there's no transition, I don't see a color shift in the output. (The color is slightly different from the original, but maybe close enough to get by. But what I mean is, it doesn't noticeably change from the first frame to the second.)
I can get rid of the shift if I switch the profile colorspace from 709 to 601, though I'm not sure if that means all but the first frame is output in 601 or if the smaller colorspace is just masking the color shift. The output does seem slightly darker than the original, at least in this example.
I was initially having this issue using the mlt library via swig, but I was also able to reproduce it with
melt
. The input XML in my example was created using the XML consumer from a ruby script, hence quite a bit of unnecessary attributes. But I included it all for completeness.Ideally my output would be in the 709 colorspace and be as true to the original colors as possible while also having no discernible color shift in the output. Am I doing that correctly or is there a better way? What am I missing?
The input file: https://embed-ssl.wistia.com/deliveries/d2e5245e04b6bcdce7981a5bb550b602/pets000.mov?disposition=attachment
The output file (you can see the color shift here): https://embed-ssl.wistia.com/deliveries/0fa094f2a99c63b1253f01d7675082ef/output.mov?disposition=attachment
The command I'm using:
input.xml:
I compiled mlt from commit 0e756b6--I upgraded from 16.6.0 where I had the same issue--with this configuration:
And I'm on Mac OS Catalina 10.15.7.
The text was updated successfully, but these errors were encountered: