With this change you no longer have to define/configure a CDM to load. This is something that isn't necessary for a lot of services.
Note: It's also now less hand-holdy in terms of correct config formatting/values. I.e. if you define a cdm by profile for a service slightly incorrectly, say a typo on the service or profile name, it will no longer warn you.
We cannot merge all the encrypted AES-128-CBC (ClearKey) segments and then decrypt them in one go because each segment should be padded to a 16-byte boundary in CBC mode.
Since it uses PKCS#5 or #7 style (cant remember which) then the merged file has a 15 in 16 chance to fail the boundary check. And in the 1 in 16 odds that it passes the boundary check, it will not decrypt properly as each segment's padding will be treated as actual data, and not padding.
This is seemingly unnecessary and simply incorrect at least for two sources (VGTV, and TRUTV).
Without this change it is not possible to correctly merge all segments without at least some problem in the resulting file.
Since it removed the data before the found box's index(-4), all loops would only find the same box at the same index again, but this time the box index would be 4 since all previous data was removed in the prior loop. Since the index-=4 code is only run if the index > 4, this never run on the second loop, and since this data now does not have the box length, Box.parse failed with an IOError.
This corrects looping through boxes and correctly obtains and parses each box.
Since range(start, stop) is start-inclusive but stop-exclusive, and DASH startNumber of SegmentTemplate typically will be 1 or not specified (defaulting to 1) it effectively worked by coincidence.
However, if startNumber was anything other than 1 than we will have a problem.
This is so both internal code and service code can save data to sub-keys without the parent keys needing to exist.
A doc-string is now set to the data property denoting some keys as reserved as well as their typing and meaning.
This also fixes a bug introduced in v3.3.3 where it will fail to download tracks without the "hls" key in the data property. This can happen when manually making Audio tracks using the HLS descriptor, and not putting any of the hls data the HLS class sets in to_tracks().
We can remove explicit dependency on language-data and marisa-trie because langcodes v3.3.0 now depends on language-data 1.2.0 and language-data 1.2.0 now depends on marisa-trie 1.1.0.
This applies the X-TIMESTAMP-MAP data to timestamps as it reads through a concatenated (merged) WebVTT file to correct timestamps on segmented WebVTT streams. It then removes the X-TIMESTAMP-MAP header.
The timescale and segment duration information is saved in the Subtitle's data dictionary under the hls/dash key: timescale (dash-only) and segment_durations. Note that this information will only be available post-download.
This is done regardless if you are converting to another subtitle or not, since the downloader automatically and forcefully concatenated the segmented subtitle data. We do not support the use of segmented Subtitles for downloading or otherwise, nor do we plan to.
Now it will no longer print the full traceback for errors caused by a missing binary file. Other errors still include it and now explicitly label them as unexpected. CalledProcessError handling is now merged with all non-environment related errors and explicitly mentions that a binary call failed.
The function now located at core/binaries should only be used by services to find a specific binary not listed in there already, or if the name of the binary needed by your service differs.
This simplifies and centralizes all definitions on where these binaries can be found to a singular reference, making it easier to modify, edit, and improve.
We simply check the type near the top of the constructor, and later in the code it casts to int and handles failures there too (e.g., if the str is not a number, it will be handled).
Some HLS playlists can have extremely limited information so to accommodate this we need to make the Subtitle track support having almost no information. This isn't ideal but it's really the only solution.
Some HLS playlists can have extremely limited information so to accommodate this we need to make the Audio track support having almost no information. This isn't ideal but it's really the only solution.
Dreamer269
retouching
rlaphoenix
rlaphoenix
Adam
pandamoon21
Shivelight