30.12.2020, 17:44
(30.12.2020, 15:12)Selur Wrote: Please, check the version from the pm and let me know if everything it fixed.
Cu Selur
The good news is the conversion now runs to completion without an error, so thamk you for the remarkable turnround on fixing the bug
The processed video still looks pretty terrible, but that is my problem to try to work out the appropriate filter settings to try to make the best of the poor quality source.
One odd thing, so far when using Hybrid I have generally seen the audio processing and file swapping etc tends to be either single threaded or IO-bound, so the CPU is running at 25-50% utilisation in those phases, but the video encoding passes (with the default "0 threads" setting to use the default threading) are entirely CPU bound, so the CPU sits nailed at 100% for 1-2 hours for a full feature film.
Running the pipeline for this DVD rip, with more filters involved, the CPU only seemed to reach about 50% utilisation. Obviously with more filtering you'd expect a longer processing time, but I wondered whether there were also some changes I should be making to the threading configuration to get the best throughput?
I think I am going to be running a lot of tests on this one DVD to try to get a decent output. Cropping and rescaling back to 720x576 removed the flickering in the top lines, but either this or the deShake causes bad tearing and juddering movement in the output, plus new artifacts on the left and right hand sides of the frame (where the original video seems to be letterboxed with back borders to transfer a 5x4 aspect ratio source (presumably from DV tape) onto a 720x576 digital version.
There's a vast amount I don't know about processing poor quaity source material. Many of the options in Hybrid are less than obvuous in their effect. If there are any good guides to the options available that would be good to know.
However, on the original bug report, that appears to be fixed, so a positive outcome