+- Selur's Little Message Board (https://forum.selur.net)
+-- Forum: Hybrid - Support (https://forum.selur.net/forum-1.html)
+--- Forum: Problems & Questions (https://forum.selur.net/forum-3.html)
+--- Thread: [BUG] >100% completion and still going endlessly (/thread-274.html)
>100% completion and still going endlessly - Ghees - 31.01.2018
Hi again. I think I have found a bug.
If you set Cut from 00:02:00.000 to 00:03:00.000 and start encoding, then you'll get an infinite process. Completion will go endlessly (mine was >1000% (one thousand) and i stopped it)
If I set any other Cuts with the same encode settings - everything will be ok.
Note! This bug arises when using x264 or x265 encoders (tested only those two and XviD). XviD has no such a bug.
I tried different sources (vob, mp4, mkv), I tried different encode presets - the bug is still there
I use 32bit 2017.12.23.1 version.
Emailed you a Debug file, if need too...
RE: >100% completion and still going endlessly - Selur - 31.01.2018
Will look at the debug output later, current guess ist that for some reason the cut doesn't make it into the Commander Line call of the decoder.
This an other issued ist why cutting ing s experimental.
Thanks for reporting.
Cu Selur
RE: >100% completion and still going endlessly - Selur - 31.01.2018
Can't reproduce this here, but I remember that I rewrote some of the cutting code not too long ago, so I probably fixed that when I rewrote parts of the code.
Cu Selur
RE: >100% completion and still going endlessly - Ghees - 31.01.2018
(31.01.2018, 16:49)Selur Wrote: current guess ist that for some reason the cut doesn't make it into the Commander Line call of the decoder.You mean it starts to convert the whole file instead of selected part? Seems like it.
If I try to convert from 2min to 3min, as stated in my bug report, the expected file duration is 1min. But audio encoding takes too much time like it encodes something big (the whole file)
If I try to convert from 4:30 to 5:30 (for example), the duration is the same - 1min, but audio is encoded fast as it should
(31.01.2018, 18:44)Selur Wrote: Can't reproduce this here, but I remember that I rewrote some of the cutting code not too long ago, so I probably fixed that when I rewrote parts of the code.I see... )