Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: What's the difference between YouTube streams 140 and 234? (Read 1926 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

What's the difference between YouTube streams 140 and 234?

About 2 weeks ago, while experimenting with Yt-dlp, for several YouTube videos I suddenly noticed a new stream ID number which I never came across before, namely 234.
After extracting the audio with FFMpeg, I found out that it was apparently AAC LC at about 128 kbps. This was a bit surprising to me because for many years there has already been the ID 140 which offers AAC LC again at about 128 kbps.
To test whether there are any differences between the streams numbered 140 and 234, I made a succession of two long sine sweeps, one in mono and the other in "inverse mono". For reasons I may possibly explain later, I deliberately changed the instantaneous amplitude proportionally to sqrt(freq).
In both cases the artifacts caused by the compression sounded pretty similar to me. And in both cases the sound was apparently strongly lowpass-filtered from about 15 kHz upwards.
Now this stream 234 seems to be a fairly new addition to the list of audio-only options. Since the audio itself is so similar for both 140 and 234 after decoding, I'm not exactly sure what differences there are between the two, or actually what the new 234 option offers that the old 140 does not.
Anyway, in case people here want to test the specific sine sweep I used, here's the link:
https://www.youtube.com/watch?v=xw6QZaEp9zo


Re: What's the difference between YouTube streams 140 and 234?

Reply #1
To test whether there are any differences between the streams numbered 140 and 234,
They are the same data, they null to -inf. The only difference is the protocol:
Code: [Select]
ID  EXT   ... │   FILESIZE  TBR PROTO │ ... ACODEC      ABR ASR MORE INFO
234 mp4   ... │                 m3u8  │ ... unknown             Default
140 m4a   ... │    1.72MiB 130k https │ ... mp4a.40.2  130k 44k medium, m4a_dash
So 234 is downloaded as fragments on a m3u8 playlist. I don't know what advantage one has over the other.

Also 140 is in m4a and 234 is in mp4 but I don't know if technically there is a difference there.

Re: What's the difference between YouTube streams 140 and 234?

Reply #2
> I don't know what advantage one has over the other

could be just a backup option in case one of them is down because of some bug/incident somewhere
a fan of AutoEq + Meier Crossfeed

Re: What's the difference between YouTube streams 140 and 234?

Reply #3
Compatibility stream?
Vital papers will demonstrate their vitality by spontaneously moving from where you left them to where you can't find them.

Re: What's the difference between YouTube streams 140 and 234?

Reply #4
Also 140 is in m4a and 234 is in mp4 but I don't know if technically there is a difference there.

140 is DASH-fragmented MP4. 234 is ADTS.

So for partial playback, you can byte-seek in 234, or just use slice:// in mpv (a stream type that was implemented by yours truly). While with 140, you need an initialization segment and maybe knowing segment byte offsets too.

Grabbing the whole thing practically works all the same of course.


 

Re: What's the difference between YouTube streams 140 and 234?

Reply #6
This page is helpful for interpreting format IDs:

https://gist.github.com/AgentOak/34d47c65b1d28829bb17c24c04a0096f

It is a bit outdated but is still useful. There is some fork that is constantly updated:  https://gist.github.com/MartinEesmaa/2f4b261cb90a47e9c41ba115a011a4aa

Anyway, I would like to see the bitrate of different Video formats (as we can see the approximate bitrate of Audio formats). I know it is VBR and even more variable than audio, but it would be a great addition to have a reference range of bitrates (it is too much work view every time the bitrate/filesize in YT-DLP for each video)