Hello, I could not find any information regarding this subject, so I am asking (I used the search and google but I did not find the informations).
I found ou that UTvideo is faster than Cineform to decode. Utvideo offers all the subsampling available. What is the color format I should use in shotcut to avoid all conversions ?
I remember some time ago I read it use 422 native subsampling, but what happen when I give it a 444 file ? Do I loose informations ? (sorry I am trying to understand)
Intenal processing is it 8bit 16bit or Float ?
I am looking for the fastest way to decode and process (I mean no conversion or the lowest amount of conversion) for shotcut.
Thank you and sorry if it was asked before I could not find it.
This is impossible if you use various filters, track blending, and transitions. Internally, it currently uses 8-bit YUV 4:2:2 and RGB(A). If you simply want to edit single clip, playlist, or single track with no filters or select filters you know can operate in YUV, you can use YUV 4:2:2.
Thank you very much.
If I use a 10bit YUV444, is it converted/processed at 8bit 422 by the timeline (no filter) ?
If I use 16bit images, are they also processed at 8bit. If I export them back to 16bit from shotcut, is it ok to assume I now have an 8bit file in a 16bit “wrapper” ?
EDIT : I found this post if you are interested.
CPU filters operates at 8bit per pixel
GPU filters operates at 16bit per pixel
You can export at 10bit in the Export Other tab:
mlt_image_format=rgb24
pix_fmt=yuv422p10le
This always depends on the input and how perfectionistic the output must be. Technically, a yuv420p input converted to yuv444p output is only lossless if chroma scaling is done with nearest neighbor. Similarly, if the input is RGB, then the output must also be RGB to avoid YUV conversion loss. There are nuances like this to every input/output pair. It’s more than just Shotcut settings to consider, and it’s never set-once-and-forget-it if total perfection is the goal.
Yes. Can the human eye detect the loss? Usually no.
That will probably always be true, but have you tried the latest FFmpeg Git master? It has faster Cineform decoding as well as a new Cineform encoder. Your wish was granted. Maybe it will be fast enough now. See:
What is the goal? “No conversion” sounds like the goal is to retain highest quality, but “fastest decode” sounds like another goal is to edit directly on this high-quality file and performance needs to be better. Would you be better served by using the original files (no transcode loss, highest quality, high compression, slow decode) as the source and then do editing on proxies? This workflow is built into Shotcut.
Yes. If there are no filters involved, then command-line ffmpeg makes more sense and will provide greater control.
Essentially. It will be 8-bit values that have been expanded (multiplied) up to 16-bit space. Mathematically, there would be gaps between values that would cause banding if processed further.
Caveat: GPU filters are almost never used. Even if they are, only the processing happens in 16-bit space. The timeline output is still an 8-bit choke point. Exporting as yuv422p10le is still 8-bit expanded to 10-bit, not a native 10-bit pipeline all the way back to the source.
Ok I understand now.
Thank you Austin. I will try Cineform again, but I am in love with UTvideo now !
I really discovered a lot of hidden gems since I am now full open-source workflow.
Not exactly because with GPU Effects enabled the track blending and transition processor are also using GPU with 16-bit float. That is why it is labeled “GPU Effects” and not “GPU Filters.”
But is GPU output delivered to ffmpeg for encoding at 16-bit? I’ve actually not had clarification on that part. If so, then yuv422p12le could be a viable output format and meet cinema standards after conversion to XYZ. This is an unsung selling point. If not, then frame delivery to the encoder (which is what I meant by timeline output) is choking the pipeline to 8-bit.
I have a hard time understanding this too shotcut Leader.
So processed at 16-bit float, then rendered at 8-bit on the timeline or at export “interpolated” to fit in any bit depth export format ?
Any plan on making the program/mlt to 16-bit native ? It will be futur proof and ease everything to transision perfectly all at 16bit float GPU/timeline/Rendering.
Is it on your mind or it may need too much ressources/team work.
I really wish you the best guys, and you have a winner product.
No, but technically that reduction occurs outside of the transitions and track blending.
Yes, but first Brian and I have made plans to run some experiments to decide on a direction for greater than 8-bit and linear color that also addresses performance (hopefully better than today’s 8-bit but not worse). We expect to start these experiments by the end of the year.