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
![[Image: Xd6eBIzDsNGayrA.jpg]](https://i.loli.net/2020/05/23/Xd6eBIzDsNGayrA.jpg)
update: still can't stop , help
![[Image: vgmr6XilO3A1NcI.jpg]](https://i.loli.net/2020/05/23/vgmr6XilO3A1NcI.jpg)
Nothing to go on, no details, sticky not read or ignored.
Can't help.
(23.05.2020, 09:50)Selur Wrote: [ -> ]Nothing to go on, no details, sticky not read or ignored.
Can't help.
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?
Looking at the debug output,
The encoding calls:
2pass 1st pass:
Code:
"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
2pass 2nd pass:
Code:
"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"
both look fine.
x265 reports:
Code:
y4m [info]: 640x480 fps 24/1 i420p10 sar 1:1 unknown frame count
raw [info]: output file: C:\Users\Antonio\AppData\Local\Temp\2020-11-30@00_13_54_0310_04.265
x265 [info]: HEVC encoder version 3.4+26-ga82c6c7a7
x265 [info]: build info [Windows][GCC 10.2.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [warning]: --ssim used with psy on: results will be invalid!
x265 [warning]: --tune ssim should be used if attempting to benchmark ssim!
x265 [info]: Main 10 profile, Level-3 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 3 / wpp(8 rows)
x265 [warning]: Source height < 720p; disabling lookahead-slices
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 3
x265 [info]: Keyframe min / max / scenecut / bias : 24 / 250 / 40 / 5.00
x265 [info]: Cb/Cr QP Offset : -2 / -2
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 3 / off / off
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 0.0 / 32 / 1
x265 [info]: Rate Control / qCompress : ABR-746 kbps / 0.60
x265 [info]: tools: limit-modes rd=3 ssim-rd psy-rd=2.50 rdoq=2 psy-rdoq=10.00
x265 [info]: tools: rskip mode=1 signhide tmvp b-intra strong-intra-smoothing
x265 [info]: tools: deblock(tC=-1:B=-1) sao stats-read
x265 [info]: frame I: 255, Avg QP:28.78 kb/s: 2135.39 SSIM Mean: 0.964687 (14.521dB)
x265 [info]: frame P: 7383, Avg QP:32.46 kb/s: 805.11 SSIM Mean: 0.943734 (12.498dB)
x265 [info]: frame B: 2466, Avg QP:37.19 kb/s: 426.89 SSIM Mean: 0.934865 (11.862dB)
x265 [info]: Weighted P-Frames: Y:0.2% UV:0.2%
x265 [info]: consecutive B-frames: 85.5% 3.3% 5.9% 4.1% 1.2%
encoded 10104 frames in 549.99s (18.37 fps), 746.37 kb/s, Avg QP:33.52, SSIM Mean Y: 0.9420979 (12.373 dB)
Hybrid assumed the input to be 5052 frames so, yes the problem seems to be related to Hybrid assuming there are half the frame count.
This 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
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)
Okay, this isn't really a bug in Hybrid.
Hybrid takes the frame count from MediaInfo and that reports:
Good news is that it's not a but in the hardware decoder since even when it's turned offx264 still reports:
Code:
encoded 10104 frames
mp4creator 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
(01.12.2020, 08:31)Selur Wrote: [ -> ]Okay, this isn't really a bug in Hybrid.
Hybrid takes the frame count from MediaInfo and that reports:
Good news is that it's not a but in the hardware decoder since even when it's turned offx264 still reports:
Code:
encoded 10104 frames
mp4creator 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
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?)
If it's small enough you can send it by email, or send me a link via PM.
Cu Selur
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.
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