Which Lossless Codecs does YouTube Support?

[jmac698]

I've tried looking this up several times now, but nowhere does it list the full list of codecs supported by youtube.
I'm not interested in webm, h264, wmv, mpg or 3gpp.
I've been testing for a while now, and so far I can confirm that FFV1 UT don't work (they didn't have audio though).
I saw some reports of h.264 lossless not working.
It's going to take a long time to test this myself, I've got about 10 lossless codecs, and then I got to try all the framerates etc.
I also saw someone use ProRes 422 to upload 4k video, but I don't have a ProRes encoder, and last I looked ffmpeg hasn't reverse engineering it yet.
I also want to know what type of deinterlacing is done either in the youtube back-end encoding or the player. If a video is interlaced, does it show as progressive? Can you see combing? Is it a bob, blend, or weave deinterlacer?
How does it treat 24fps? Does the player literally show that framerate?
Will YouTube convert to 10bit video if I upload 10bit? The 4k experiment I saw used 10bit ProRes but it wasn't clear if the resulting Youtube encoding came out as 10bit.
What if I need to show 24p clips and 30p clips in the same video?

Thanks.

ps seems that ProRes is not lossless.
QuickTime Animation format looks lossless, but I don't know if I can encode to it for free.

[jagabo]

Huffyuv, UT Video codec, Lagarith

That's not from personal experience, just from google searches.

[poisondeathray]

1) Why would you want to upload lossless format to youtube ? It's going to butcher it anyway. You'll often get worse results uploading a lossless encode because they retain all the detail and noise which makes it harder for youtube's encoder

I also saw someone use ProRes 422 to upload 4k video, but I don't have a ProRes encoder, and last I looked ffmpeg hasn't reverse engineering it yet.

it does work in ffmpeg now (encoding & decoding) , but as you pointed out it's not lossless

I also want to know what type of deinterlacing is done either in the youtube back-end encoding or the player. If a video is interlaced, does it show as progressive? Can you see combing? Is it a bob, blend, or weave deinterlacer?

I think it's bob plus discard (single rate) . I don't know what determines it, but some videos are automatically deinterlaced by youtube before encoding, and others are not (you're left with combing) . Other's are wrongfully deinterlaced with loss of resolution (e.g. 30p in 60i AVCHD camcorder videos)

How does it treat 24fps? Does the player literally show that framerate?

Yes, it's supported . It plays at that framerate, and you get the normal 3:2 cadence on a 60Hz display

Will YouTube convert to 10bit video if I upload 10bit? The 4k experiment I saw used 10bit ProRes but it wasn't clear if the resulting Youtube encoding came out as 10bit.

No - 10bit it's not supported for decode or encode for youtube. I don't think prores is suppoted either, unless something changed recently

However Adobe flash platform (beta) does support 10bit AVC (e.g. your own website) - there are some tests on Doom9. There was a bug with a magenta line on the right border, but I think it's been fixed in the newest flash beta

What if I need to show 24p clips and 30p clips in the same video?

Flash supports VFR, but I don't know if youtube will re-encode with VFR if you upload a VFR video . Should be simple enough to test

QuickTime Animation format looks lossless, but I don't know if I can encode to it for free.

Lossless RGB (not YCbCr), in ffmpeg it's -vcodec qtrle

[jmac698]

Thanks! That was extremely helpful.

You can see that using a lossless codec compared to a high bitrate lossy encode makes a big difference, and someone has done objective testing here
http://www.reduser.net/forum/showthread.php?70894-YouTube-Video-Codecs-Resolutions-amp-Data-Rates

Personally, I find these tests to be very interesting. And surprising. Normally, we export a video from our NLE to H.264 and then upload that to YouTube only for it to get recompressed again by YouTube's encoder. That means that the video is being compressed (and destroyed) twice. Whereas, if you export from your NLE to a codec like ProRes or DNxHD, you can reduce the loss of quality by ensuring the you're delivering a high quality file to YouTube. YouTube will then take that high quality file and compress it down to H.264, but at least you're doing everything you can on your end to receive the highest quality image possible from your YouTube videos.

The codecs they listed,
lossy:
x.264, photo-jpeg, DNxHD 220 8-bit, DNxHD 145 8-bit, ProRes 422

lossless:
Apple Animation/rle, QuickTime uncompressed 8/10bit 4:2:2

So there is at least one lossless 10bit support.

So for 8-bit, YUV 422 lossless and compressed formats,
my best filesize and least upload time would be lagarith

For 10-bit, least upload time
Apple Animation/RLE
Though it probably won't compress very much.

Another question, is true 60fps playback supported?

Still doesn't explain why my UT upload failed, but I'll add audio and try it again. I've grabbed huffyuv and lagarith. I'm aware of there being many versions of huffyuv, is there a speed optimized build? Compression time will be a factor as well, even if upload time is reduced. I wonder what the best balance between upload time and compression time would be, in terms of total workflow time.

I want to use an intermediate that's directly web-compatible, I mean why not, I need the intermediate anyway.

[poisondeathray]

Thanks! That was extremely helpful.

You can see that using a lossless codec compared to a high bitrate lossy encode makes a big difference, and someone has done objective testing here
http://www.reduser.net/forum/showthread.php?70894-YouTube-Video-Codecs-Resolutions-amp-Data-Rates

But this is a CGI source direct from the pipe - it's going to be very clean to begin with.

Also Mainconcept AVC no doubt buchers the video before even uploading , with banding and compression artifacts - you probably need a higher bitrate 10Mb/s for 1080p isn't a whole lot when there is animation (that's before youtube buchers it even more)

I've done a bunch of tests too - you get better results optimizing the video before uploading. Lossless isn't very useful or the benfits over a high quality x264 encoded with sufficient bitrate is neglible . For live action footage , its more important than encoding lossless

lossless:
Apple Animation/rle, QuickTime uncompressed 8/10bit 4:2:2

So there is at least one lossless 10bit support.

Yes, I guess prores is supported . You can use your own website and stream real 10-bit videos

Blip.tv will do it for free if you wrap in FLV

Flash also supports full range flags , so combined with 10bit AVC with user specified bitrates - no banding

Another question, is true 60fps playback supported?

Definitely not, and even if it did, playback is extremely choppy in flash (you can test it on your own website or non re-encoding websites)

Still doesn't explain why my UT upload failed, but I'll add audio and try it again. I've grabbed huffyuv and lagarith. I'm aware of there being many versions of huffyuv, is there a speed optimized build? Compression time will be a factor as well, even if upload time is reduced. I wonder what the best balance between upload time and compression time would be, in terms of total workflow time.

Not sure , UT was added to ffmpeg a while back, so I would assume youtbe will eventually get it as well (I guess that's why prores is decoded ok for youtube as well)

I want to use an intermediate that's directly web-compatible, I mean why not, I need the intermediate anyway.

Use something like blip.tv instead of youtube . It doesn't re-encode if you wrap in FLV. Way better quality and bitrates (you choose) . 10bit AVC works ok now (no magenta border) - just tested it

[jmac698]

I've never worked with VFR; how I would I test? I'm used to producing my sources with Avisynth. I have need of putting 24p and 30p into a clip and it would be excellent if I could do that, even if it's not lossless or whatever. Let's say I have 2 or more clips separated by 24p/30p, ready to join together exactly. How do I put them into one VFR file?

And of course you have a good point about the source material, and that noise will kill any compression, but for the project I'm doing right now, this is production footage from a professionally produced US Network show, made with HD digital cameras. It's for portfolio purposes, so I just want it to be shown in the best light. It's well-lit and there's hardly any noise.

I'm not part of the production team, just a lowly web person.

I'll mention blip.tv as an option, but this is not that kind of situation; there isn't a specific website for it. It will be submitted to professional agencies and there was also a request to put on YouTube specifically.

Is your optimizing strategy basically just denoising?

You're a wealth of information!

[poisondeathray]

I've never worked with VFR; how I would I test? I'm used to producing my sources with Avisynth. I have need of putting 24p and 30p into a clip and it would be excellent if I could do that, even if it's not lossless or whatever.

You can use avisynth (CFR only), just encode it VFR with timecodes as you normally would (e..g mux in timecodes or use --tcfilein for x264)

e.g. You can use tivtc.dll using 2 passes to generate VFR video timecodes
http://avisynth.org/mediawiki/VFR#encoding_to_vfr_.28mkv.29

To test it , you upload a VFR video and download it from youtube to see if the converted it to CFR or retained VFR .

Is your optimizing strategy basically just denoising?

It depends on the video, but that's usually the most important point. Your footage is well shot & lit so you don't need to stabilize or fix levels, and you probably don't have to clean it up much either

CGI is absolutely noise free, live action - no matter what camera, uncompressed recording - will have 100x more noise . Youtube uses long gop encoding (difference between frames are stored), so motion , noise will kill compression. Even a light denoise can improve results, but the tradeoff is gradient banding (youtube doesn't use high enough bitrates to hold dither or noise eitherway) .

I'll mention blip.tv as an option, but this is not that kind of situation; there isn't a specific website for it. It will be submitted to professional agencies and there was also a request to put on YouTube specifically.

Then maybe you should submit multiple versions? The reason why people jump through hoops for youtube, is their re-encoding policies. But if your original footage is pristine, you shouldn't have to do to much to it.

The bottom line is it won't make much of a difference quality wise if you uploaded a well encoded x264 file (you don't need to use slow settings) vs. a lossless file . It will probably be many times smaller and not much longer to encode.

[jmac698]

Looks like UT requires audio. If all goes well, you'll be able to see it at http://youtu.be/XaINxx7Vrvg
It's a test to show how deinterlacing is done, you might find it interesting.
Also was wondering about if the color was 422 or 420

[poisondeathray]

It's not live yet, but is that 24p with 3:2 pulldown? Why is it called pulldown demo? If so, it's definitely not supported by Youtube

If you want best results, you should do the IVTC if 24p,; or deinterlacing if it's an interlaced source . Do all the processing on your end and leave the least amount of work to do for youtube. They even recommend that on their website. Don't rely on Youtube for any processing

Youtube re-encodes everything to 8bit 4:2:0 . All flags are ignored (e.g. BT.709 vs. BT.601, full range vs. limited range)

[jmac698]

>BT.709 vs. BT.601
Yikes! I'm glad you mentioned that. The wrong colorspace makes green especially look weird. What colorspace does it decode to?

It failed. I'll try huffuv in a few minutes.
I know, I didn't expect it to play well, what I mean is, it will let me determine what deinterlacing is being done automatically. But you have a point, it's a pointless test since I shouldn't be using it anyhow.

I *did* want to put up a video like that however, as an educational video to demonstrate how pulldown works. For that I suppose I will have to slow down the animation. This is a topic I've had to explain to people in forums before. There's probably someone else who has done this already as a YouTube video.

You can see my video below, with 26,000,000:1 compression, the worlds best

colorbars(width=720,height=480,pixel_type="YUY2").assumefps("ntsc_film").converttomono.convertaudioto16bit.trim(0,16*10-1)
animation
labelframes
pulldown32
LabelVideoWithCounts
ShowSMPTE
subtitle("This is an educational example of how film (23.976fps) is converted to NTSC Video (29.97fps)",y=180,x=-1,text_color=$ffffff,size=24)

function pulldown32(clip in) {
  #Expects and returns a frame based clip
  in
  AssumeFrameBased.AssumeTFF
  SeparateFields
  #8 progressive frames turn into 10 fields
  SelectEvery(8, 0,1,0, 3,2, 5,4,5, 6,7)# this is 3:2 pulldown unlike the example under SelectEvery which is 2:3
  #this order is most accurate in time order; i.e. 3/60<2/24, though other orders may be preferred for other reasons
  Weave
}

function simpleivtc(clip in) {
  #IVTC for a fixed 3:2 pulldown pattern, non-adaptive, returns 4/5 framerate clip (i.e. 24fps from 30fps)
  in.swapfields.doubleweave
  pulldown(0,3)
}

function LabelVideoWithCounts(clip v) {
  #Add framecount and field counts to a video
  v
  #add frame numbering
  assumetff
  separatefields
  top=last.selecteven
  bot=last.selectodd
  #all this is to remove color shadows; where the text overlays, color is desaturated, due to YV12
  tu=top.utoy
  tv=top.vtoy
  bu=bot.utoy
  bv=bot.vtoy
  top1=top.ScriptClip("""subtitle("video field = " + string(current_frame*2),x=-1,y=60,size=20,text_color=$00FFFFFF,font_width=17)""")
  bot1=bot.ScriptClip("""subtitle("video field = " + string(current_frame*2+1),x=-1,y=80,size=20,text_color=$00FFFFFF,font_width=17)""")
  top=ytouv(tu,tv,top1)
  bot=ytouv(bu,bv,bot1)
  interleave(top,bot)
  weave
  assumefps("ntsc_video")
}

function labelframes(clip v) {
      #add frame numbering
      v
      assumetff
      separatefields
      top=last.selecteven
      bot=last.selectodd
      #all this is to remove color shadows; where the text overlays, color is desaturated, due to YV12
      tu=top.utoy
      tv=top.vtoy
      bu=bot.utoy
      bv=bot.vtoy
      top1=top.ScriptClip("""subtitle("film frame on top field = " + string(current_frame),x=-1,y=20,size=20,text_color=$00FFFFFF,font_width=17)""")
      bot1=bot.ScriptClip("""subtitle("film frame on bot field = " + string(current_frame),x=-1,y=40,size=20,text_color=$00FFFFFF,font_width=17)""")
      top=ytouv(tu,tv,top1)
      bot=ytouv(bu,bv,bot1)
      interleave(top,bot)
      weave
}

function animation {
  #Create a red square that moves
  red_yuv=$4164D4#in REC 601
  #Make a moving red square
  #unfortunately I have to make one of these global to work with scriptclip unless GRunT is installed
  global square=blankclip(length=1,width=50,height=50,pixel_type="YUY2",fps=24000, fps_denominator=1001, color_yuv=red_yuv,sixteen_bit=true)
  background=colorbars(width=720,height=480,pixel_type="YUY2").assumefps("ntsc_film").converttomono.convertaudioto16bit.trim(0,16*10-1)
    ScriptClip(background,"""
    overlay(square,x=103-25+current_frame*8,y=240-25)
  """)
 }

[poisondeathray]

>BT.709 vs. BT.601
Yikes! I'm glad you mentioned that. The wrong colorspace makes green especially look weird. What colorspace does it decode to?

To be fair, this one isn't entirely youtube's fault, it's Adobe Flash's fault and it's independent of resolution (unlike many software palyers)

HW acceleration ON: YCbCr=>RGB for display using BT.601

HW acceleration OFF: YCbCr=>RGB for display using specified matrix flags ; if no matrix specified BT.709 is used

[jmac698]

Wow, you've really tested this stuff!
I'll have to aim for rec601

Latest attempt here; I'm just trying to get something working for now! This will be my very first YouTube video and it's failed 3 times so far.

http://youtu.be/YuJtc7G0Qrc

For a 6 second, 29.97, 720x480 video;
ffv1 6,302kb
lag 12,403kb
ut 26,003kb
huf 64,699kb

That's sure all over the map.

Ok, my first test
input
container: avi
video: hufy rgb
720x480 ntsc
78.6 Mbps

output
container: flash, flv
video: avc, main@l3, cabac,
720x480 ntsc 4:2:0 progressive
314 Kbps

[poisondeathray]

ffv1 (YV12) though ffdshow works for youtube , not sure if the other colorspaces or variants work (e.g. ffmpeg's implementation)

It doesn't make sense to upload other chroma sampling or colorpaces to youtube other than YV12, it might make the wrong conversion (e.g. not do proper matrix conversion). You want to control everything possible and leave youtube the least amount of decisions to make

video: hufy rgb

e.g. why would you upload an RGB test? Not only is data rate much higher, you run risk of youtube screwing up RGB=>YV12 conversion for the actual encode (not talking about the display or flags) . e.g. it might use BT709 for the actual encode (before the it gets converted back to RGB for display)

I'll have to aim for rec601

But you can't control this with youtube, nor can you control if end user has HW acceleration on or off . At least with your own website, you can use flags so the people that don't have HW enabled will see whatever you flag

EDIT: yes ffmpeg's ffv1 works as well for -pix_fmt yuv420p (i.e. yv12) shows up fine on youtube

[jmac698]

I didn't mean to use RGB at all; it seems VirtualDub doesn't support YUV encoding, and I only found out when it was done. I'd use WinFF but I'd have to make a whole bunch of profiles and figure out command lines. What do you use for encoding?

>HW acceleration OFF: YCbCr=>RGB for display using specified matrix flags
From that I'd guessed that I could control colorspace; by using rec601 flags it would be decoded as rec601 in the hw on or off cases.

I'm certainly with you in having control, just tell me how to encode it through lagarith.

I also found out that upload time is dominating; that 64MB file took too long.

Btw, now I can tell you that RGB in encoded as rec601.

[poisondeathray]

In older versions of vdub, if you didn't use video=>fast recompress mode , you would incur conversion to RGB . It is done using rec601. interlaced YV12=>RGB are not done properly in vdub (chroma upsampling issue, because "interlaced yv12" supposedly doesn't exist according to fourcc, so it's upsampled as progressive)

Newer versions have color depth options. Either way if you use fast recompress mode it won't change the colorspace

From that I'd guessed that I could control colorspace; by using rec601 flags it would be decoded as rec601 in the hw on or off cases.

That's true for flash in general e.g. blip or your own website , not youtube.

Remember youtube discards flags (it re-encodes YCbCr video as YCbCr and the flags are removed). So for youtube, 709 for HW off because essentially the re-encoded video has no flags

It doesn't look like Youtube accepts lagarith (yet... it was put into ffmpeg a while back, so it should be supported in youtube soon I would think)

I also found out that upload time is dominating; that 64MB file took too long.

Well it's going to depend on your upload bandwidth, but that's exactly the point. You'd get negligible visual quality difference and 5-20x smaller filesize using proper x264 encode

The thread you linked to is not really a valid comparison. It says something about Mainconcept AVC using lowish bitrates, not a proper encode. I don't know how familiar you are with AVC codecs, but it's notoriously bad for shadow detail and gradients. x264's AQ deals with that nicely. If you're interested do a search, there are many comparisons (I've posted a bunch as well). I will bet money that the encode was botched before even uploading to youtube.

[jmac698]

Ah, I would agree with you about x264, however such encodes usually take hours on my pathetic computer. I'll have to see if encoding + uploading time is any quicker than uploading time.

Another question; what res to fill the 16:9 play window? It should be 854 but Avisynth forces me to use %4 widths. I'm trying an 852 now.

It failed. lagarith yv12 23.976

ffv1 yv12 23.976fps failed

[poisondeathray]

Ah, I would agree with you about x264, however such encodes usually take hours on my pathetic computer. I'll have to see if encoding + uploading time is any quicker than uploading time.

Use faster settings; it will be less compressed but you don't need to squeeze every little bit out

It sounds like you have an older computer , but on a decent quad core, it encodes faster than xvid using superfast and veryfast settings

Another question; what res to fill the 16:9 play window? It should be 854 but Avisynth forces me to use %4 widths. I'm trying an 852 now.



ffv1 yv12 23.976fps failed

Must be something in your script, because YV12 only requires mod2

I used 848 for mod16 and it worked for ffv1 in the couple of tests I just did (854 failed in the ffmpeg encode) . I noticed that non mod16 resolutions sometimes can be problematic with some lossless codecs in YV12

But 854 fills up the window completely for youtube, 854 works fine for other codecs like x264 encoded videos (internally they are padded to mod16 anyway). I think 848 has slight letterbox on youtube



Since you're dealing with SD, consider upscaling. It's one of the very few instances in the video world that helps (because of the way youtube re-encodes video and allocates bitrate). Not only is video better, audio gets higher bitrate as well

[jmac698]

Yes; I'd already had that idea about upscaling, and that's what I planned to do.
There's really a lot of factors to consider in all this; resulting bitrate, framerate, colorspace, resolution... whew.
http://youtu.be/q3FHYopphQU

I actually still have no idea how the timecodes thing works, I'll be searching for a guide unless you can point me to one.

Apparently my video is shaky and has bad lighting That's hilarious, considering it's a static image.

I can't seem to select 480p.

[manono]

Apparently my video is shaky and has bad lighting.

Yeah, I get that sometimes, too. Very strange.

"Would you like us to fix it for you?"

"No thanks. You've done enough damage already."

[jmac698]

lol

[odar733-3]

use ffmpeg to compress in x264 audio AAC to incapsulation in flv
ffmpeg different version on codec AAC use libfacc or libvo_aacenc

for %%i in ("*.avi") do ("%~dp0ffmpeg.exe" -y -i "%~dp0%%i" -vcodec libx264 -acodec libfaac -ar 44100 -b:a 112k -coder 1 -cmp +chroma -partitions p8x8,b8x8,i4x4,i8x8 -me_method hex -crf 26.0 -subq 6 -me_range 16 -g 250 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -b_strategy 1 -qcomp 0.6 -qmin 0 -qmax 69 -qdiff 4 -bf 3 -refs 8 -direct-pred 3 -trellis 2 -wpredp 2 -rc_lookahead 60 -threads 0 -ab 112k "%%~ni.mp4" & "%~dp0ffmpeg.exe" -y -i "%~dp0%%~ni.mp4" -vcodec copy -acodec copy "%~dp0%%~ni.flv" )

or

for %%i in ("*.avi") do ("%~dp0ffmpeg.exe" -y -i "%~dp0%%i" -vcodec libx264 -acodec libvo_aacenc -ar 44100 -b:a 112k -coder 1 -cmp +chroma -partitions p8x8,b8x8,i4x4,i8x8 -me_method hex -crf 26.0 -subq 6 -me_range 16 -g 250 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -b_strategy 1 -qcomp 0.6 -qmin 0 -qmax 69 -qdiff 4 -bf 3 -refs 8 -direct-pred 3 -trellis 2 -wpredp 2 -rc_lookahead 60 -threads 0 -ab 112k "%%~ni.mp4" & "%~dp0ffmpeg.exe" -y -i "%~dp0%%~ni.mp4" -vcodec copy -acodec copy "%~dp0%%~ni.flv" )

to compress only video with x264.exe original only audio whith ffmpeg in aac
video + audio with ffmpeg
mp4 to incapsulate in flv with ffmpeg

for %%i in ("*.avi") do ("x264.exe" --ref 3 --bframes 3 --partitions p8x8,b8x8,i4x4,i8x8 --me umh --trellis 1 --subme 7 --merange 16 --keyint 250 --min-keyint 25 --b-adapt 1 --direct auto --analyse all --weightb --mixed-refs --b-pyramid none --8x8dct --no-fast-pskip --level 3.1 --crf 26.0 --qp 26 --sar 1:1 --threads auto --output "%%~ni.mp4" "%%i" & "%~dp0ffmpeg.exe" -i "%%i" -vn -ar 44100 -b:a 112k "%~dp0%%~ni.m4a"& "%~dp0ffmpeg.exe" -i "%~dp0%%~ni.m4a" -i "%~dp0%%~ni.mp4" -acodec copy -vcodec copy "%~dp0%%~ni_x264_m4a.mp4" & "%~dp0ffmpeg.exe" -i "%~dp0%%~ni_x264_m4a.mp4" -vcodec copy -acodec copy "%~dp0%%~ni_x264_m4a.flv" & del "%~dp0%%~ni.m4a" & del "%~dp0%%~ni.mp4" )

[jmac698]

I think I know how to do that VFR test now (a test of whether YouTube can accept and properly display variable framerate videos).

In Avisynth, with the FFMS2 source plugin, there's an option to write a timecodes file. I would then open my various clips, join them together, and play through once, linearly.

I suppose I have to do that in one pass, then in another pass send the actual video to mkvtoolnix? together with the timecodes.txt.

Update:
It's easiest to do it with a timecode v1 file manually. The video can be any frame rate, just join the two clips with different framerates. Then the timecodes.txt file lists two lines which specify which framerange belows to the first and then the 2nd clip, plus their proper framerates. Then use mkvmerge. Finally I can feed this mkv file to YouTube and see how it plays.

[NJRoadfan]

YouTube uses FFMpeg for its backend video work. They support HuffYUV, but they won't deinterlace the 480p version, only the 360p and 240p. Overall YT's handling of interlaced content is poor. When it works, its usually a simple blend deinterlace, so its best to do it yourself before uploading. It looks like they finally got deinterlacing working for HDV content, but it looks like crap.