(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.

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 samevariable 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

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 framerateAnd for comparison, the MediaInfo report out of Streamfab shows:(c) 2160p MP4 - video codec VP9, Variable 23.976 FPS framerateFinally, 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.

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

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 !

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 MiBOverall bit rate : 7 619 kb/sFrame rate : 23.976 FPSFrame rate mode : ConstantFrame rate : 23.976 (24000/1001) FPSThis is in contrast to the MKV/MediaInfo output 4K+ Video Downloader produces:File size : 655 MiBOverall bit rate : 7 621 kb/sFrame rate : 24.000 FPSFrame rate mode : ConstantFrame rate : 24.000 FPSAnd in contrast to the MP4/MediaInfo output Streamfab produces:File size : 657 MiBOverall bit rate : 7 645 kb/sFrame rate : 23.976 FPSFrame rate mode : VariableFrame rate : 23.976 FPSMinimum frame rate : 23.256 FPSMaximum frame rate : 24.390 FPS

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."

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.

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 : VariableFrame rate : 23.976 FPSMinimum frame rate : 23.256 FPSMaximum frame rate : 24.390 FPSI'm still awaiting word from the photographer, letting me know what the uploaded video characteristics were.

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 : VariableFrame rate : 23.976 FPSMinimum frame rate : 23.256 FPSMaximum frame rate : 24.390 FPSI'm still awaiting word from the photographer, letting me know what the uploaded video characteristics were.DSperberalso read - Compress Video for YouTubeYouTube 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.

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?

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

DSperber

I gave a similar 4K demo of one of the "Blue Planet II" UHD discs to my brother, on my calibrated 55" LG OLED C7, which because of its slightly smaller size actually presents a more stunningly sharp and crisp and bright and colorful rendition than the 65" (at least from our viewing distance). There's an underwater sequence about what I call a 'sand worm" popping up to devour a fish that is absolutely horrifying and unbelievable.

My brother returned home and purchased his own LG OLED set!! A convert.

Anyway, I've now reconsidered and applied one more of your command operand recommendations: --compat-options filename-sanitization

It wasn't present before, and there are two characters in the video file name that are non-standard. And this same name is propagated into the exported TXT file name produced by MediaInfo.

This didn't cause me any problems for any tool I used to point to that file, until I tried to attach the MediaInfo TXT file to an email (using my email client program app, Forte Agent, which is not browser-based but a local POP3-type product like Thunderbird, the old Outlook Express, etc.). And it complained about being unable to attach it.

So I added the --compat operand to cleanse the file name, and recreated the MKV, and then recreated the MediaInfo export TXT file. And after this "cleansing" it with the --compat operand sure enough there was no problem attaching it to the email with Agent.

So for reference, my new command is now:

yt-dlp --ignore-config -f bestvideo+bestaudio/best --embed-metadata --concurrent-fragments 10 --compat-options filename-sanitization -P f:\YTDLP-Videos -o "%%(title)s.%%(height)sp WEB-DL" --remux-video mkv "https://www.youtube.com/watch?v=zE5WdeWyuj4"

Still haven't updated that last URL parameter for "production".

DSperber

And, finally coming back to the original reason I started this thread in the first place, asking why StreamFab produces a downloaded file which claims to be "Variable 23.976 FPS", I still haven't gotten any real answer from StreamFab Support on my ticket. They asked me to try upgrading to 6.2.4.7, and also for some additional details (although my original ticket provided everything needed to show what I was complaining about), As I mentioned earlier, I did update with no change in results. And I gave them further comparisons and insights, but no response yet from my latest update to the ticket.

Anyway, I've noticed from the most recent downloads that the author appears to have replaced the original video with a new one that has a higher video bitrate than it originally did last week. Looks like there's a new date of 7/27 on it, which could explain why all of all my recent downloads (including the one using StreamFab 6.2.4.7) are noticeably larger in file size.

But MediaInfo still shows the same details about framerate for this newly replaced video with the higher bitrate::

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

File size : 1 001 MiB
Overall bit rate : 11.7 Mb/s
Frame rate : 23.976 FPS

So that's why I perhaps mistakenly am asking why StreamFab is doing "re-encoding", even though it doesn't actually take any processing time once downloading finishes. So it couldn't actually be doing any real re-encoding which would take 10-15 minutes.

So I'm thinking that maybe, like with 4K Video Downloader+ and its also seemingly incorrect MediaInfo, perhaps StreamFab is just mistakenly creating this "Variable 23.976 FPS" metadata?

So I'm back to asking for an explanation here. How/why can this FPS info be wrong be, given that obviously no actual re-encoding is occurring? (I can't seem to get any answer from StreamFab tech support)

DSperber

I've come back for possible help on one more small issue with my development of my own basic and simple script with no interaction for anything other than the URL, similar to yours, for downloading using yt-dlp.

And I also decided that the target location for the downloaded file should go into a properly named sub-folder (within parent F:\YTDLP-Videos) for that video file, having the same name as the downloaded video file which will be placed in it. So the script reflects that objective, making use of yt-dlp to pre-obtain the "video file title" before actually starting the download command. And the retrieved title is then used by the script to fully express the correct -P operand for yt-dlp.

Everything is working fine, except that the detail about the "--compat-options filename-sanitization" operand for yt-dlp in the download command itself. This works as expected, and the file name is "cleansed" of the special characters.

However there does not seem to be a similar functional equivalent when specifically obtaining the video title through a "yt-dlp --get-title" command. I tried additionally adding the --compat operand which certainly cleanses the file name of the retrieved file, but it has no effect on retrieving the title by itself via --get-title.

This isn't terribly critical, but if possible I'd like to have the sub-folder name match the actual name of the stored video file inside. So if the video file name is "cleansed" ideally I'd like to have its host sub-folder name be the same.

==> Is it possible to apply the same cleansing of special characters action done by --compat for the download file name, to the video title returned from --get-title?

(apology that this is really a question about yt-dlp rather than StreamFab, but we have kind of wandered OT and you have MUCH EXPERIENCE in script writing specifically related to yt-dlp)

thanks.

jpp72


-P f:\YTDLP-Videos -o "%%(title)s\%%(title)s.%%(height)sp WEB-DL"

jpp72

Also, if you don't want to bother the nice people who read the StreamFab forum, feel free to request to follow me. I'll approve it and then you can DM me

DSperber

EXCELLENT! Thank you for that technique. I didn't realize that I could trick the combined syntax of both -P and -o operands to effectively specify the low-level subfolder name that way (with %%(title)s\ at the start), which both (a) creates the sub-folder, and also (b) brings it inside of the domain of the -o operand and the then applicable --compat operand. Very clever.

So sure enough, it now creates the properly named sub-folder with the cleansed special characters. Thanks again.

Here's the BAT file. Very simple, just prompts for the URL. (Note that the ECHO output of the title is NOT cleansed, although the sub-folder name itself is. Hardly important.)

@echo off
setlocal enabledelayedexpansion

set /p "video_url=Enter the video URL: "
echo Getting title for: %video_url%

rem set video_url=https://www.youtube.com/watch?v=zE5WdeWyuj4
rem echo Manual Video URL: %video_url%

for /f "delims=" %%i in ('yt-dlp --get-title "%video_url%"') do set "video_title=%%i"
echo Video Title: %video_title%

set video_folder=f:\YTDLP-Videos\%video_title%
echo Target folder: %video_folder%

yt-dlp --ignore-config -f bestvideo+bestaudio/best --embed-metadata --concurrent-fragments 10 --compat-options filename-sanitization -P f:\YTDLP-Videos -o "%%(title)s\%%(title)s.%%(height)sp WEB-DL" --remux-video mkv "%video_url%"

:end

« Previous Page