We are still experiencing DRM issues with some of the StreamFab download modules. If you can only download videos at lower resolutions than you could before January 25th 2024, please be patient as the developers are still working on fixing the issues.
Other symptoms that you are dealing with a DRM problem could be "Failure to access video" errors or endless analysis.
Please refrain from posting about these specific errors as we are of course well aware and working on them. Feel free to post an issue you think might not be related to the DRM problem but bear in mind that they will be treated with a very low priority until the DRM issues are resolved.
The following modules should be fully back to normal (state before January 25th 2024):
AbemaTVApple TV+CrunchyrollDisney+HuluITVX
JoynLeminoNHK+OnlyFansParamount+
RTL+ShahidTubiU-Next
These modules are back to normal for content added prior to January 25th 2024 and lower resolutions for newer content:
AmazonMax
* Netflix content added after January 25th 2024 cannot be downloaded at all. It is back to normal for everything else.
Regarding Peacock , the content that cannot be downloaded is anything posted after February 22nd 2024. Anything Prior can still be downloaded as usual.
This is 100% not true
The video and audio are still downloaded separately
The video is then re-encoded to add the audio back in
This is why things do, in fact, appear jittery in many cases (including Hulu, Amazon, etc), and why Amazon takes a good bit of time post processing (3-5 minutes, which is admittedly better than it originally was).
Lossless would mean that the video is downloaded straight from the website, nothing is done to it at all. This is not the case here. It is re-encoded
Also the download is effectively lossless from the provider, this is not to say that the provider did not do any kind of re-encoding to make what they offer smaller that the original from the studio.
remuxing (mixing the audio and video together in this case) is not re-encoding, and is a lossless operation (assuming it is /just/ remuxing)
Just because someone doesn't want to admit it is, doesn't mean it is. It is not lossless, and it is absolutely re-encoding the video.
If this was downloaded properly, to begin with, it would be 100% lossless
The video and audio are still downloaded separately
Because of that the video and audio are stored separately on the server of streaming services, and they are encrypted (this is why StreamFab need take 3~5 mins to process the video and then remux the video).
I have no idea if you think that to remux the video and audio with FFMPEG is the re-encode.
And it's easy to identify that the download tool is re-encode or download if check the CPU/GPU usage when downloading the video.
Thanks!
Wilson
Please post your logs the default location is:
For DVDFab 13: C:\Users\User Name\My Documents\DVDFab\DVDFab13\Log
For StreamFab: C:\Users\User Name\My Documents\DVDFab\StreamFab\log
Please use attachment button and attach your most recent, Internal log and post right here.
If it's the burning issue, please also attach burn log.
That's what I was going to type. If a video is being re-encoded at all, CPU and perhaps GPU spikes will happen. It's an easy process to spot. For example, if you use MKVToolNix to remux a movie container, the CPU usage won't go high, but Hard Drive access will. So far the Hulu videos I've downloaded have not been re-encoded. They either fail to download or download. FFMPEG is a slower but consistent tool to use to join stuff together...with a verification check.
All remux does is interleave the existing encoded audio/video packets so that they're close to each other for the same time block, instead of having all the audio at the beginning or ending of the file (for instance).
Decrypting is a different operation too, it's generally much faster than encoding but not as fast as remuxing.
Encoding is the part that always loses quality, (even if increasing the bitrate) if you're using a lossy codec (such has h264/h265)
This is 100% not true
The video and audio are still downloaded separately
The video is then re-encoded to add the audio back in
This is why things do, in fact, appear jittery in many cases (including Hulu, Amazon, etc), and why Amazon takes a good bit of time post processing (3-5 minutes, which is admittedly better than it originally was).
Lossless would mean that the video is downloaded straight from the website, nothing is done to it at all. This is not the case here. It is re-encoded
It is not reencoded, You heard Mona tell you so, you are just plain wrong and will not admit it. I have to be careful here, you might be a child so I really dont want you to cry, but just admit your wrong and be done with it. Why are you here anyway if you don't like the program.
Programmer in Python,Java,JavaScript,Swift,PHP,SQL,C#,C++,Go,R
Please post your logs the default location is:
For DVDFab 13: C:\Users\User Name\My Documents\DVDFab\DVDFab13\Log
For StreamFab: C:\Users\User Name\My Documents\DVDFab\StreamFab\log
Please use attachment button and attach your most recent, Internal log and post right here.
If it's the burning issue, please also attach burn log.
Comment