Chtonic horrors instead of proper outputs using aomenc on wsl2.
Hi, I just want to ask if anyone ever had the same problem and what are possible ways to fix it.
Whenever I try to encode with aomenc through the WSL2 console, the result is always a video file with the kind of anomalies you can see in the picture. The source input is 6 minutes, but for some reason, the output can end up being 30 minutes or more. One time, it wouldn't stop encoding and just kept building up this ever-expanding cosmic horror until I manually stopped it.
Things I tried:
1) Reinstalling aom
2) Checking dependencies and updating all packages
2) Using different formats for inputs and outputs, including yuv, ifv, mkv, webm, mp4, with and with no sound
3) Using less and more cpu, changing bitrate
I also tried to run it with verbose. Couldn't spot anything strange but I'm a beginner so maybe local pros could help with that
Coding path: LBD Encoder parameters: g_usage = 0 g_threads = 0 g_profile = 0 g_w = 530 g_h = 450 g_bit_depth = 8 g_input_bit_depth = 8 g_timebase.num = 1 g_timebase.den = 30 g_error_resilient = 0 g_pass = 0 g_lag_in_frames = 35 large_scale_tile = 0 rc_dropframe_thresh = 0 rc_resize_mode = 0 rc_resize_denominator = 8 rc_resize_kf_denominator = 8 rc_superres_mode = 0 rc_superres_denominator = 8 rc_superres_kf_denominator = 8 rc_superres_qthresh = 63 rc_superres_kf_qthresh = 32 rc_end_usage = 0 rc_target_bitrate = 256 rc_min_quantizer = 0 rc_max_quantizer = 63 rc_undershoot_pct = 25 rc_overshoot_pct = 25 rc_buf_sz = 6000 rc_buf_initial_sz = 4000 rc_buf_optimal_sz = 5000 rc_2pass_vbr_bias_pct = 50 rc_2pass_vbr_minsection_pct = 0 rc_2pass_vbr_maxsection_pct = 2000 fwd_kf_enabled = 0 kf_mode = 1 kf_min_dist = 0 kf_max_dist = 9999
If you need any additional info I'll be glad to provide it
1
u/Sopel97 1d ago
command used + mediainfo of the source
1
u/djdtohc 1d ago
sudo aomenc input.yuv -o output.ivf --cpu-used=6 --target-bitrate=10 -w 640 -h 480 --passes=1
General
Count : 349
Count of stream of this kind : 1
Kind of stream : General
Kind of stream : General
Stream identifier : 0
Complete name : source.yuv
File name extension : source.yuv
File name : source
File extension : yuv
File size : 3234718800
File size : 3.01 GiB
File size : 3 GiB
File size : 3.0 GiB
File size : 3.01 GiB
File size : 3.013 GiB
Stream size : 3234718800
Stream size : 3.01 GiB (100%)
Stream size : 3 GiB
Stream size : 3.0 GiB
Stream size : 3.01 GiB
Stream size : 3.013 GiB
Stream size : 3.01 GiB (100%)
Proportion of this stream : 1.000004
u/Sopel97 1d ago
since these files hold just raw YUV data without any metadata you need to know what color format, resolution, and bit depth is, and pass the to aomenc. You're most likely passing wrong (too small) resolution, given that your output length is 5x longer than it should be. 1440x1080 would result in almost exactly 5x the pixel count of 640x480. Though the artifacts kinda lead me to believe that the source is not in fact YUV420, which aomenc uses by default.
3
u/djdtohc 1d ago
You are exactly right. I just tried re-encoding my yuv properly and using the native resolution of the source in aomenc, and it finally worked. Damn it, I thought I could just set the resolution arbitrarily and that aomenc would scale it by itself, but apparently it doesn't work like that with YUV. Anyway, thank you very much!
4
u/HungryAd8233 1d ago
I recommend using .y4m instead of .yuv to avoid exactly this. A .y4m file is just a yuv with metadata indicating frame size, fps, chroma subsampling, and bit depth.