StreamFab for Windows Why is high-quality 4K YouTube video being RE-ENCODED by Streamfab??

[DSperber]

(1) I am comparing the downloaded file results, as well as "performance" (i.e. total time to complete the download) from using three different YouTube downloader products to download a very high quality 12 minute video from YouTube (which IS available in resolutions up to 4K):

https://www.youtube.com/watch?v=zE5WdeWyuj4

(2) The three products I'm comparing are:

(a) Streamfab x64 6.2.4.6 -> took about 13 minutes to produce MP4 using VP9 codec, framerate variable 23.976 FPS, file size 657 MB

(b) 4K Video Downloader+ 25.2.0.210 x64 -> took about 2 minutes to produce MKV using VP9 codec, framerate constant 24.000 FPS, file size 655 MB

(c) YouTube Downloader HD (high-speed version) 5.9.8.5 -> took about 35 minutes to produce MP4 using AVC codec, framerate constant 23.976 FPS, file size 838 MB


(3) In particular, I know that the original 4K video was in fact uploaded at a high-quality CONSTANT framerate of 24.000 (shot with professional cameras). And it is clearly possible to retrieve that same identical high-quality original CONSTANT 24.000 FPS in the downloaded file because 4K Video Downloader+ does it!!

Furthermore, 4K Video Downloader+ completes the entire download in just 2 minutes, essentially how long it takes to physically complete the download itself of the 655MB video file, with my high-speed internet connection. There was almost no additional post-download time for any additional processing to handle audio, and the whole thing was done and dusted in 2 minutes.

In contrast, Streamfab took about 13 minutes to complete first the physical download of whatever was requested from YouTube, and then apparently a very CPU-intensive complete re-encoding of the entire video. The original was Constant 24.000 FPS and the MP4 output from Streamfab is Variable 23.976 FPS!!!

I certainly do not want this, not to mention all the extra time it took to complete its creation because of this unnecessary and unwanted re-encoding of the entire video. I expected to get the "pristine" original video quality untouched, and certainly not completely re-encoded resulting in a reduction in quality no matter how good VP9 is.


(4) While 4K Video Downloader+ produces an VP9 MKV result for its own untouched directly-downloaded "original quality" video from YouTube (retaining Constant 24.000 FPS) in just 2 minutes, it's easily seen that YouTube Downloader HD is a real dog here. Not only is it also clearly performing a complete re-encode from VP9 into "inefficient" AVC with Constant 23.976 FPS, but it clearly takes a VERY long time to do that. Took 35 minutes to complete the full re-encoded.

At least Streamfab only took 13 minutes to do its own full re-encode, perhaps due to keeping VP9 even though the framerate was changed from Constant 24.000 to Variable 23.976, But really, why is this being done at all???


(5) So that's my question. Is there any way to PREVENT this unwanted and unnecessary complete re-encoding of the original high-quality video retrieved from YouTube?

Clearly it is possible to get that VP9 Constant 24.000 version of the 4K video file, because 4K Video Downloader+ does it!! That is the true video that is being retrieved and downloaded. And at least this product has the proper design to LEAVE IT ALONE, LEAVE IT EXACTLY AS-IS!! No need to re-encode which immediately degrades video quality.

So can I prevent Streamfab from re-encoding? I'm perfectly fine with MKV, don't need re-wrapped into MP4 (which isn't necessarily the cause of the re-encoding, as you can easily "re-wrap" MKV into MP4 as a "fast copy"). But MP4 is fine too, as long as the underlying contained video output itself does not get re-encoded from the original video input.

[Germania]

If I dl with current yt-dlp (m4a 140 + mp4 625) in one minute ..
.. it shows 24fps - but the result is VP90 3840x2160 23.976fps 7487kbps (654mb)

SF uses yt-dlp (aka: YoutubeToMP3Process) so the result is the same
variable bit rate (only slower dl) and is not re-encoded !

If I dl webm_dash with current yt-dlp (webm 251 + webm 313)
I get also VP90 3840x2160 23.976fps - so result is never 24fps

[DSperber]

First, I don't know the internal programming techniques used by the 4K Video Downloader+ product. But when setting things up for a requested download it offers two different container formats: either MKV or MP4. The MP4 format only supports a max of 1080p while the MKV format supports up to 2160p. I don't know if it might also support up to 4320p if the video is available at that resolution.

Also, when using MKV you are forced into VP9 for 2K and 4K resolutions, but you have your choice of either VP9 or AVC for video codec at each of the lower optional resolutions 1080p and below. WIth MP4 you only can get AVC and 1080p is the max resolution available. Different from Streamfab's design.

So it might be the limitations implied by AVC which govern any other choices or settings when MP4 format is used. It might be that MKV format is a more more robust wrapper, allowing retaining the original Constant 24.000 framerate within VP9.






Second, for reference I have now downloaded BOTH formats, MP4 (1080p) and MKV (2160p). And I have run MediaInfo on both files, exporting the "text" output for both. I am attaching the exported MediaInfo output to this post for you to look at.

I have also run MediaInfo on the MP4 output form Streamfab. And again, I have exported the "text" output and attached that as well to this post for you to look at.

NOTE: Looking at the two MediaInfo reports out of 4K Video Downloader+ it is very interesting to see that they are internally different:

(a) 2160p MKV - video codec VP9, Constant 24.000 FPS framerate
(b) 1080p MP4 - video codec AVC, Variable 23.976 FPS framerate

And for comparison, the MediaInfo report out of Streamfab shows:

(c) 2160p MP4 - video codec VP9, Variable 23.976 FPS framerate


Finally, how can we explain that the MKV output from 4K Video Downloader absolutely is Constant 24.000 FPS framerate, per MediaInfo? You say you don't see that in any of your downloads, However I do believe that actually IS the nature of the actual theatrical release camera-produced video as shot. It was not created at 23.976.

[DSperber]

Somehow the MediaInfo exported output attachments didn't make it into the prior post. Here they are.

[Germania]

You can't download mkv file because YouTube doesn't offer mkv files.

And if the 4k Downloader offers this, it's not just a download ..
.. so constant 24 fps frame rate is not unchanged either.

And if your selection images display 25 fps ..
.. but you don't get 25 fps, then that obviously can't be a reference !

[DSperber]

Lots of good observations and questions. I will contact 4K Video Downloader+ support to see if they can explain the curious (or seemingly inappropriate items, like the 25fps shown on the settings UI).

In the meantime, I have now just downloaded the video again, this time using JDownloader which was recommended to me. I'm not very familiar with its options yet, but I believe by default it downloads at the highest possible quality. And that seems to be the 4K version that we've been discussing here.

Note that it, too, creates a target download file in MKV (rather than MP4) wrapper format, perhaps for maximum flexibility as to what can be placed in it). But I think we should rather be focused on the framerate of the downloaded video.

Note also that JDownloader DID NOT DO ANY RE-ENCODING, so it took maybe 1 minute to complete its MKV. Very high speed download, and essentially nothing else. This is in contrast to Streamfab which took about 15 minutes to complete its MP4 because of its re-encoding for variable framerate..

And surprisingly (to me, anyway), for its MKV/MediaInfo output JDownloader produces yet another different picture of things:

File size : 655 MiB
Overall bit rate : 7 619 kb/s
Frame rate : 23.976 FPS
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS

This is in contrast to the MKV/MediaInfo output 4K+ Video Downloader produces:

File size : 655 MiB
Overall bit rate : 7 621 kb/s
Frame rate : 24.000 FPS
Frame rate mode : Constant
Frame rate : 24.000 FPS

And in contrast to the MP4/MediaInfo output Streamfab produces:

File size : 657 MiB
Overall bit rate : 7 645 kb/s
Frame rate : 23.976 FPS
Frame rate mode : Variable
Frame rate : 23.976 FPS
Minimum frame rate : 23.256 FPS
Maximum frame rate : 24.390 FPS

[simchris]

Probably unrelated but a heck of a lot of stuff we get here in the U.S. pulls down via various streaming systems on NTSC at 23.976fps -- the standard for broadcast and digital distribution regardless of how it was "shot."

[DSperber]

Sure. And its quite common to casually describe video that is truly 23.976 as "24fps", even though it is not 24.000. Both are described as "film-like", reflecting theatrical analog film projector frame rates. Certainly this does distinguish it from "live" video framerate of "60fps", which itself can theoretically actually be either 59.94 or 60.00. Fractional or integer, it's still casually described as "60fps".

But that's still not the reason for my question.

I have reached out to the originator of that video to say what was the framerate of the video that he uploaded. Actually I suspect he himself reduced the actual very high resolution video-output bitrate of what his camera produced to reduce the physical size of these files uploaded to YouTube (he's actually going to post 9 chapters). This one is 12 minutes at about 7600 kb/s and is about 650MB. I think he's planning on producing a super-high-bitrate super-high-quality UHD BluRay from the original camera output, which would be an enormous amount of data.

So whatever he uploaded, you'd like to know. Then we at least can say that what all of these YouTube downloader products deliver is either the "original" framerate, or it is not. And if it is not, did YouTube change it for downloading, or did the downloader program receive a video in original framerate and then re-encode it.

It is certainly clear that Streamfab is absolutely re-encoding what was initially "Constant framerate" of either 24.000 or 23.976, into "Variable framerate 23.976". That is undeniable, given that it takes about 13 minutes to perform the "post-download analysis and processing" before the actual MP4 file is available.

And it is equally clear that both (a) 4K Video Downloader+ and (b) JDownloader ARE NOT RE-ENCODING what they receive from YouTube (and I might add they both produce MKV files, not MP4, when you are retrieving 4K videos). This is undeniable, given that it takes both products no more than 1-2 minutes to download the 650MB file and be finished. The MKV file is essentially created as quickly as it is downloaded. And in fact JDownloader also creates a second M4A file of just the audio-only, in addition to the MKV file for audio+video. All in just 1 minute.

The mystery is then what is YouTube actually giving to Streamfab and 4KVD+ and JDownloader to produce their output, because while BOTH clearly are not re-encoding, they nevertheless show different video characteristics that one would think is impossible. Are there "request parameters" that the downloader program gives to YouTube to define the specific request in terms of what YouTube then delivers (thus doing its own conversions, while giving the video to the downloader)? Or do they all receive the same 4K video from YouTube, and then they themselves produce the output they produce perhaps applying their own local conversions?

(a) 4KVD+ -> MKV with Constant 24.000 FPS (2 minutes, download-only)
(b) JDownloader -> MKV with Constant 23.976 (1 minute, download-only
(c) Streamfab -> MP4 with Variable 23.976 (15 minutes, download plus re-encode)

I've written to the 4KVD+ people, to ask if it is possible they simply created the metadata inside the non-re-encoded MKV file with an incorrect 24.000 value even though it is 23.976, given that the JDownloader MKV file shows 23.976 and also did not go through any re-encoding. I think the "visible difference" between 24.000 and 23.976 is something like 1 frame absent or present every 41 seconds or so. Maybe nobody ever noticed or complained during playback, even if the number is incorrect, unless you happened to see that 1-frame anomaly onscreen every 41 seconds.

Lots of interesting clues.

[DSperber]

Today I received a formal response from StreamFab tech support, on the official support ticket I'd opened a few days ago.

Their first recommendation was for me to upgrade from 6.2.4.6 to the latest version 6.2.4.7 which was just release today, and to see if there was any change.

Well yes, turns out there WAS a change. Surprisingly the download ran MUCH FASTER than it had originally, completing in under 2 minutes. That was actually unexpected because the file size of the downloaded MP4 was SIGNIFICANTLY LARGER than the original downloaded MP4 out of 6.2.4.6, due to a SIGNIFICANTLY HIGHER BITRATE in the latest file, presumably which will produce improved video quality.

The original MP4 was: File size : 657 MiB, Overall bit rate : 7,645 kb/s.

The new MP4 is: File size : 1,001 MiB, Overall bit rate : 11,700 k/b/s.


However there is no change from the re-encoding from Constant framerate into Variable framerate that must still be happening (although I don't understand how it didn't take hardly any time at all unless this is actually being done by YouTube itself), because the framerate of the MP4 still shows exactly as it did before:

Frame rate mode : Variable
Frame rate : 23.976 FPS
Minimum frame rate : 23.256 FPS
Maximum frame rate : 24.390 FPS


I'm still awaiting word from the photographer, letting me know what the uploaded video characteristics were.

[october262]

Today I received a formal response from StreamFab tech support, on the official support ticket I'd opened a few days ago.

Their first recommendation was for me to upgrade from 6.2.4.6 to the latest version 6.2.4.7 which was just release today, and to see if there was any change.

Well yes, turns out there WAS a change. Surprisingly the download ran MUCH FASTER than it had originally, completing in under 2 minutes. That was actually unexpected because the file size of the downloaded MP4 was SIGNIFICANTLY LARGER than the original downloaded MP4 out of 6.2.4.6, due to a SIGNIFICANTLY HIGHER BITRATE in the latest file, presumably which will produce improved video quality.

The original MP4 was: File size : 657 MiB, Overall bit rate : 7,645 kb/s.

The new MP4 is: File size : 1,001 MiB, Overall bit rate : 11,700 k/b/s.


However there is no change from the re-encoding from Constant framerate into Variable framerate that must still be happening (although I don't understand how it didn't take hardly any time at all unless this is actually being done by YouTube itself), because the framerate of the MP4 still shows exactly as it did before:

Frame rate mode : Variable
Frame rate : 23.976 FPS
Minimum frame rate : 23.256 FPS
Maximum frame rate : 24.390 FPS


I'm still awaiting word from the photographer, letting me know what the uploaded video characteristics were.

also read - Compress Video for YouTube

YouTube automatically compresses uploaded videos to ensure smooth streaming and compatibility across different devices and internet connections. This compression process can affect video quality, especially if the original file does not meet YouTube's recommended encoding settings. For example, YouTube typically compresses 1080p videos at a bitrate of around 8 Mbps, while 4K videos are compressed at a bitrate of 35-45 Mbps.

If you upload a video that does not match YouTube's standard settings, the platform will re-encode it, which may result in a noticeable quality drop. To minimize quality loss, it is advisable to compress your video before uploading it, ensuring it meets YouTube's recommended specifications. This can also speed up the upload process and help maintain the desired quality.

YouTube re-encodes all uploaded videos, which means both the video and audio streams are compressed and re-encoded. The platform generally re-encodes audio to m4a and aac formats in various bitrates, as well as some low-quality ogg files.

To compress videos for YouTube, you can use tools like HandBrake, VLC Media Player, Adobe Premiere Pro, or online compressors like Clipchamp, YouCompress, and VEED.IO. These tools allow you to adjust resolution, bitrate, frame rate, and other parameters to achieve the best balance between file size and quality.

If you want to avoid unnecessary compression, you can upload a file that already matches YouTube's recommended encoding settings, which will reduce the need for further conversion. However, even if you do not compress your video beforehand, YouTube's compression standards are generally good enough for most viewers.

[DSperber]

Thank you for those insights. I'm actually not the uploader of that video, and as I said I'm actually waiting to hear back from him as to what were the details of his upload in the first place. What were the characteristics of his original camera output (presumably high-quality high-bitrate native 4K with expensive camera), and did he reduce and re-compress it before, in order to better/best conform to the standards and expectations of YouTube in order to preserve best possible quality.

But really, the more interesting question is no matter what actually resides right now on YouTube, however it got there into that state, why is it that three different downloaders capable of retrieving 4K videos into MKV files each produce different framerates? Constant 24.000, Constant 23.976, and Variable 23.976.

And also, StreamFab itself now produces two different bitrates and resulting vastly different MKV file sizes going from 6.2.4.6 to the latest 6.2.4.7, although it still shows as "Variable 23.976 FPS". Bitrate 7645 kb/s and Bitrate 11,700 kb/s. I suppose I'm appreciative of the presumably newly superior video quality, but what's going on?

[Stan001]

Then use whatever program suits you. Jdownloader2 (https://jdownloader.org/jdownloader2) works very well even when most other YouTube downloaders stop working. It even gets the SRTs.

Streamfab does use a version of yt-dlp, which most people just use yt-dlp to get from YouTube. Whether streamfab encodes or reencodes, who knows.

Find yt-dlp here>GitHub - yt-dlp/yt-dlp: A feature-rich command-line audio/video downloader

[DSperber]

If I dl with current yt-dlp (m4a 140 + mp4 625) in one minute ..
.. it shows 24fps - but the result is VP90 3840x2160 23.976fps 7487kbps (654mb)

Isn't this the very gist of my question?

Doesn't this indicate a "mistake", where the metadata claims "Constant 24.000" but you say the actual data is "Constant 23.976"?

And if I may ask you, how did you determine that the actual data was 23.976?

Since this is what 4K Video Downloader+ produced, your observation confirms my suspicion that this product has "mistakenly" produced a mis-described file. It claims with MediaInfo to be 24.000 but probably is really 23.976... same as you say you got with your own yt-dlp test.

Yes?

SF uses yt-dlp (aka: YoutubeToMP3Process) so the result is the same
variable bit rate (only slower dl) and is not re-encoded !

Please educate me.

Is the downloaded data sent by YouTube already "Variable 23.976"? How else could SF not have to re-encode to produce this and yet end up with "Variable 23.976" if the actual download from YT is "Constant 23.976"?

So what is the file truly retrieved from YT: Variable 23.976 or Constant 23.976?

What do you conclude?

If I dl webm_dash with current yt-dlp (webm 251 + webm 313)I get also VP90 3840x2160 23.976fps - so result is never 24fps

So this is what you conclude, that the actual download should be correctly marked as "Constant 23.976". And that there truly is not a 24.000 video on YouTube do get downloaded.

So it has to be a mistake to mark it as "Constant 24.000", if in fact the data is actually "Constant 23.976. And yet, 4KVD+ as well as your first yt-dlp test DID produce that incorrectly marked "Constant 24.000". So both 4KVD+ made a mistake, and your first yt-dlp inexplicably produced a mis-marked retult.

Finally, to me perhaps out of my ignorance, I don't see how the SF download can end up with "Variable 23.976" and also NOT be doing any actual re-encoding of its own unless YouTube itself is actually delivery already encoded "Variable 23.976". So is this what SF is doing? Why not just "Constant 23.976", as it turns out the file size difference appears to be almost zero?

[DSperber]

Total newbie to yt-dlp. Trying to learn what I need to do to use it myself, and have run into one problem. I cannot get the downloaded file name built properly.

Can you please tell me what I'm doing wrong, or also need to do, in order to get it right.

(1) So that I can see exactly what I'm doing, I haven't built a config file to provide any runtime parameters. Instead I've just built a bat command with each parameter explicitly stated. That way I can struggle and experiment, and retry without much effort.

I want the downloaded video to be an MKV, with a file name exactly the same as the YouTube video and an extension of MKV, placed in F:\YTDLP-Videos. So my DOWNLOAD.BAT command is:

yt-dlp -f bestvideo+bestaudio/best -P f:\YTDLP-Videos -o "%(title)s.%(ext)s" --remux-video mkv "https://www.youtube.com/watch?v=zE5WdeWyuj4"

(2) And I've built a C:\YTDL folder containing just what is required to run yt-dlp.exe:



(3) Running in Win10, I then open a command prompt window, navigate to C:\YTDL, and execute the DOWNLOAD command. It runs perfectly, except that the file name of the output downloaded file is not being built correctly. For some reason (obviously a mistake in my syntax) it is not being built as I expect from my coding of the "-o" parameter.

Based on a sample template example I thought was appropriate I had coded -o "%(title)s.%(ext)s" to be the output file name. But for some reason it is not working as I expected.

Note that I've also tried the -o operand without the quotation marks (") delimiting the symbolic content within, and it made no difference. Same apparent ignoring of the first "%(title)s," part, as if it weren't there for some reason. And same exact result n the file name, seemingly treating the "(ext)s" string as if that were what I was requesting for the file name. No substitution happening with the actual YouTube video file name. And I suspect the MKV extension is coming from the --remux operand, so that is another consideration.




(4) The output file is truly correct, being an MKV of file size 999 MiB, with a framerate of "Constant 23.976 (24000/1001) FPS", and a high quality overall bit rate of 11.6 Mb/s. Yes, not 24.000, and I'm pretty much a believer now.

But the file name is obviously not being constructed correctly.




So what have I not coded correctly in my DOWNLOAD.BAT command syntax for the -o operand. Or is it something else which is needed?

Thanks very much for any help and instructions.

[jpp72]

Inside a batch file, you need to use double %

For example, this is my filename string:

"%%(id)s.%%(title)s.%%(height)sp WEB-DL.%%(ext)s"

Which would result in the file being named: zE5WdeWyuj4.OVER ICELAND - - CH 2 of 9 THORSMORK.2160p WEB-DL.webm

You may want to use --compat-options filename-sanitization to make sure the files don't contain special characters.

Here is my full yt-dlp command when downloading best quality youtube videos:

yt-dlp.exe -U -i --compat-options filename-sanitization --write-sub --add-metadata --extractor-retries 10 -o "%%(id)s.%%(title)s.%%(height)sp WEB-DL.%%(ext)s" --concurrent-fragments 10 --sub-format "ass/srt/best" --sub-langs "en.*,fr.*,ro.*,rum.*" --ignore-config --no-geo-bypass --cookies "C:/Utils/Cookies/%COMPUTERNAME%.txt" "%url%"