![]() |
|
[HELP] why encode over more than 100% progress - Printable Version +- 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: [HELP] why encode over more than 100% progress (/thread-1380.html) Pages:
1
2
|
why encode over more than 100% progress - ssdde - 23.05.2020 a mkv file can't encode properly, i exact it mpg file to encode, but it has not done when encode more than 100%, why? how to solve ![]() update: still can't stop , help
RE: why encode over more than 100% progress - Selur - 23.05.2020 Nothing to go on, no details, sticky not read or ignored. Can't help. RE: why encode over more than 100% progress - Werve - 30.11.2020 (23.05.2020, 09:50)Selur Wrote: Nothing to go on, no details, sticky not read or ignored. Maybe I can help because I have the same behavior (in my case I selected mkv and x265 but I tried with x264 mp4 too and happen the same). I also tried different x265 settings but the encoding bar always exceeds 100% (also using the 2 passes encoding with target 22 MB, the output file is always 40.7 MB maybe it is related to the wrong prediction of the remaining time?). Log is attached. Edit: The maximum percentage always seems to be 200% maybe double counted? RE: why encode over more than 100% progress - Selur - 30.11.2020 Looking at the debug output, The encoding calls: 2pass 1st pass: "C:\Program Files\Hybrid\64bit\ffmpeg.exe" -y -loglevel fatal -noautorotate -nostdin -hwaccel auto -threads 1 -i "D:\Videos\test.mp4" -an -sn -vf zscale=rangein=tv:range=tv -pix_fmt yuv420p10le -strict -1 -vsync 0 -f yuv4mpegpipe - | "C:\Program Files\Hybrid\64bit\x265.exe" --input - --output-depth 10 --y4m --profile main10 --limit-modes --no-open-gop --opt-ref-list-length-pps --pass 1 --no-slow-firstpass --bitrate 749 --opt-qp-pps --cbqpoffs -2 --crqpoffs -2 --limit-refs 0 --ssim-rd --psy-rd 2.50 --rdoq-level 2 --psy-rdoq 10.00 --aq-mode 0 --deblock=-1:-1 --limit-sao --no-repeat-headers --ssim --range limited --colormatrix unknown --stats "C:\Users\Antonio\AppData\Local\Temp\test-hybrid_generated_2020-11-30@00_13_54_0310_03.stats" --multi-pass-opt-analysis --multi-pass-opt-distortion --analysis-reuse-file "C:\Users\Antonio\AppData\Local\Temp\test-hybrid_generated_2020-11-30@00_13_54_0310_03.analysis" --output NUL"C:\Program Files\Hybrid\64bit\ffmpeg.exe" -y -loglevel fatal -noautorotate -nostdin -hwaccel auto -threads 1 -i "D:\Videos\test.mp4" -an -sn -vf zscale=rangein=tv:range=tv -pix_fmt yuv420p10le -strict -1 -vsync 0 -f yuv4mpegpipe - | "C:\Program Files\Hybrid\64bit\x265.exe" --input - --output-depth 10 --y4m --profile main10 --limit-modes --no-early-skip --no-open-gop --opt-ref-list-length-pps --pass 2 --bitrate 746 --opt-qp-pps --cbqpoffs -2 --crqpoffs -2 --limit-refs 0 --ssim-rd --psy-rd 2.50 --rdoq-level 2 --psy-rdoq 10.00 --aq-mode 0 --deblock=-1:-1 --limit-sao --no-repeat-headers --ssim --range limited --colormatrix unknown --stats "C:\Users\Antonio\AppData\Local\Temp\test-hybrid_generated_2020-11-30@00_13_54_0310_03.stats" --multi-pass-opt-analysis --multi-pass-opt-distortion --analysis-reuse-file "C:\Users\Antonio\AppData\Local\Temp\test-hybrid_generated_2020-11-30@00_13_54_0310_03.analysis" --output "C:\Users\Antonio\AppData\Local\Temp\2020-11-30@00_13_54_0310_04.265"x265 reports: y4m [info]: 640x480 fps 24/1 i420p10 sar 1:1 unknown frame countThis explains: a. the 200% progress indication b. the double sized output (since the bit rate calculation uses double of the bitrate it should) -> I'll need a debug output which contains: a. the loading&analysis of the source b. the job creation c. the job processing to know what is going wrong. Also from the looks of ti you enabled 'Config->Input->Use gpu for decoding' try whether disabling this option before creating and processing the jobs helps. (to try whether it's an issue with the decoding) Cu Selur RE: why encode over more than 100% progress - Werve - 01.12.2020 Ok, is attached the log from loading the file (without gpu decoding). I am also trying several files, maybe there is a correlation with this behavior. EDIT: It seems to happen only on files with "Writing application : mp4creator 1.6.1d" (but I have only a couple of this type so it is not a significant sample to be sure) RE: why encode over more than 100% progress - Selur - 01.12.2020 Okay, this isn't really a bug in Hybrid. Hybrid takes the frame count from MediaInfo and that reports: Frame count : 5052encoded 10104 framesmp4creator 1.6.1d seems to be from 2008 and doesn't seem to be too active, so there are probably not that much files out there using it. What I found is: http://trac.ffmpeg.org/ticket/8456 -> Does the created file contain the video stream twice? In case it does I could automatically add '-ignore_editlist' whenever a file created by 'mp4creator' is handled and that might fix the issue. ![]() -> Do you have a small file which shows the double percentage issue in Hybrid that you could share with me? (through google drive or similar?) Cu Selur RE: why encode over more than 100% progress - Werve - 01.12.2020 (01.12.2020, 08:31)Selur Wrote: Okay, this isn't really a bug in Hybrid. I am trying to search online for files created with that program to test. The videos that I tried were downloaded from youtube (video clips so I don't know if there are copyright problems, in case I don't find other similar files can I send it by email?) RE: why encode over more than 100% progress - Selur - 01.12.2020 If it's small enough you can send it by email, or send me a link via PM. Cu Selur RE: why encode over more than 100% progress - Werve - 01.12.2020 It seems that with other videos found online that have used mp4creator there is no problem. So (considering the reduced sample mentioned) it could be a strange coincidence that the files I tried before have this behavior. RE: why encode over more than 100% progress - Selur - 01.12.2020 Think I found the issue. ![]() It's like the file mentioned in the ffmpeg bug tracker, for some reason someone added an edit list which tells ffmpeg to play the file twice. -> dev version I'm packing atm. should also fix this and you other issue Cu Selur |