4 ms·

I would also be interested in that. What differnce would you expect from the catalog size? I would guess that aside from maybe the handshake, decoupling stora

I would also be interested in that. What differnce would you expect from the catalog size? I would guess that aside from maybe the handshake, decoupling storage and encryption would not be worth it in all cases where the storage medium is slower than AES-NI and this would apply even more to youtube than to netflix, exactly because of the bigger catalog.

bluedino 10y ago
>> What differnce would you expect from the catalog size? The Netflix OpenConnect applicances were maxing out the local SSD storage - YouTube isn't keeping as high of a percentage of active content on the servers so I imagine the CPU's aren't being kept as busy, or there's less CPU in their web-facing boxes. NetFlix is using 28-core CPU's in some of their latest machines.
drewg123 10y ago
With a small catalog, you can pre-encode everything. That means that in the unencrypted case, media files can be sent directly from the kernel's page cache, as unmapped I/O. Eg, the data is not even touched by the CPU. But in the encrypted case, you're suddenly touching every byte with the CPU, thereby doubling your memory bandwidth requirements. With a large catalog like YouTube's, I would expect that most of the titles are saved in some master format, and are encoded on the fly. That means that the data is already being touched by the CPU to re-encode it on the fly for whatever format is needed by a particular client. My expectation is that if YouTube was re-encoding on the fly due to the catalog size, they would suffer less of a CPU hit than Netflix did, so SSL would be "easier" for them to implement.
- deleted 10y ago
  [deleted]
- rasz_pl 10y ago
  > encoded on the fly no, and often their encoders will go bad and produce invalid output (blocky/purple) in one of the resolutions/formats. There is ZERO options for fixing that other than deleting your video and reuploading (losing all the comments/upvotes). Even if you have 200K subs there is no way of contacting YT for help, mmaybe they will speak with you at 1mil subs :/

bluedino 10y ago

>> What differnce would you expect from the catalog size? The Netflix OpenConnect applicances were maxing out the local SSD storage - YouTube isn't keeping as high of a percentage of active content on the servers so I imagine the CPU's aren't being kept as busy, or there's less CPU in their web-facing boxes. NetFlix is using 28-core CPU's in some of their latest machines.

drewg123 10y ago

With a small catalog, you can pre-encode everything. That means that in the unencrypted case, media files can be sent directly from the kernel's page cache, as unmapped I/O. Eg, the data is not even touched by the CPU. But in the encrypted case, you're suddenly touching every byte with the CPU, thereby doubling your memory bandwidth requirements. With a large catalog like YouTube's, I would expect that most of the titles are saved in some master format, and are encoded on the fly. That means that the data is already being touched by the CPU to re-encode it on the fly for whatever format is needed by a particular client. My expectation is that if YouTube was re-encoding on the fly due to the catalog size, they would suffer less of a CPU hit than Netflix did, so SSL would be "easier" for them to implement.

deleted 10y ago
[deleted]
rasz_pl 10y ago
> encoded on the fly no, and often their encoders will go bad and produce invalid output (blocky/purple) in one of the resolutions/formats. There is ZERO options for fixing that other than deleting your video and reuploading (losing all the comments/upvotes). Even if you have 200K subs there is no way of contacting YT for help, mmaybe they will speak with you at 1mil subs :/