Youtube re-encode scramble, anyone know?

Does anyone know why youtube ruins video like this?
Sometimes ffmpeg/shotcut will do something similar, but the source video here did not have the scramble.
(source is purposely dithered here, so ignore that effect)

side-question, if my PC supports both h264_vaapi and hevc_vaapi, which is “better” for youtube as the target?

I assume that youtube re-encoded your video as avc1 instead of vp09, right? Right click on the youtube player and click on “Stats for nerds” to check.

Unless I’m missing something, H.265 and HEVC are two names for the same thing. You can call that codec by either name.

1 Like

vp09

& i mistyped, 264

2020-09-15_18-50

2020-09-15_18-53

Interesting. vp09 is the highest quality codec at youtube. See if that’s something you can report to google about.

Okay. Well, vp9 which is from google competes with HEVC which is from MPEG. Did you encode that video you uploaded with H.264 or HEVC hardware encoding?

I wonder if google re-encodes a video any differently if it’s fed as vp9 from the start.

1 Like

source (Shotcut output) was hardware h264, which is what iv’e always done, but willing to modify for best end-results. i dont mind youtube re-encoding, but corrupting the image ruins the art.

i will certainly try hevc h265 now. (<1 hour render)

2020-09-15_19-02

I’m curious did you use the “YouTube” export or just the h264 export?

I would be curious to know if the scramble appeared a second time if you uploaded a second copy of the video to YouTube. That scramble looks suspiciously like a fixity error.

Youtube, then modded stuff & saved as preset:
preset=fast
f=mp4
acodec=aac
channels=2
ar=48000
ab=128k
vcodec=h264_vaapi
crf=18
vq=18
g=15
bf=2
width=2560
height=1440
aspect=1.77778
progressive=1
top_field_first=2
deinterlace_method=yadif
rescale=hyper
frame_rate_num=30000000
frame_rate_den=1000000
threads=0

i just re-upped orig h264 again and new h265, youtube processing slow :confused: so i will report again in hours. FWIW, Airvuz.com did the same (on h264), just not same spots. it’s a re-encode fail for sure.

edit:
h264 upload to AV: https://www.airvuz.com/video/🐝-Dithery-Do--Aggressive-7-Multi-Rotor-Cruising?id=5f614004afc1f02e29dca458
h264 first upload to YT: https://youtu.be/wNLr0BL8-mk
h264 re-upload to YT: https://youtu.be/eUqHvsgnGEM same problem
:partying_face: h265 GOP=5 upload to YT: https://youtu.be/J_vg_vFYfVY no scramble!! (but my desktop cannot hardware export hvec_vaapi, my laptop can…) A good step forward!! :slight_smile:

hevc_vaapi (h265) seems to be the fix. reduce GOP for “fast motion” video, but i have zero clue if is a part of the fix.

Not using VAAPI(hardware encoding) may also be a solution, that’s the AMD GPU hardware encoder just using cpu based H264 may be better(if memory serves it results in smaller files as well)

1 Like

what kind of GPU do you have?
Makes sense to use NVENC if you have a Nvidia card.

none, CPU based Intel HD. :laughing:

if your video codec is vaapi you’re using the gpu not cpu encoding(it might work through the intel gpu as well since amd utilizes openCL more than nvidia which will be a cuda encoder)

Here is makes sense to Use Software encoding only.
Hardware encoding on Intel has been unreliable so far in my Experience with i3 and i5 hardware.

1 Like