[HELP] why encode over more than 100% progress

[ssdde]

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

[Selur]

Nothing to go on, no details, sticky not read or ignored.
Can't help.

[Werve]

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?

[Selur]

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

2pass 2nd 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-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:

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

[Werve]

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)

[Selur]

Okay, this isn't really a bug in Hybrid.
Hybrid takes the frame count from MediaInfo and that reports:

Frame count                              : 5052

Good news is that it's not a but in the hardware decoder since even when it's turned offx264 still reports:

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

[Werve]

Okay, this isn't really a bug in Hybrid.
Hybrid takes the frame count from MediaInfo and that reports:

Frame count                              : 5052

Good news is that it's not a but in the hardware decoder since even when it's turned offx264 still reports:

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?)

[Selur]

If it's small enough you can send it by email, or send me a link via PM.

Cu Selur

[Werve]

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.

[Selur]

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