blackjack4494
commented
3 years ago It turns out that google will keep data of livestreams (at least of a consistent one running 24/7) for about ~7d. There is a chance that there is slightly more data but only a few hours at most and this is not even consistent.
So I suggest a maximum offset of 300000 sequences or maybe even less (oldest_seqnum = head_seqnum - offset_seqnum).
However there should be no problem at all if you have a livestream that is just running for a few hours.
Current implementation will download video and audio separate (if using dash which is needed to get earlier data).
Also it takes quite some time to download all parts (2hrs video ~30min download) when the integrated downloader is used - no clue about external like aria2c. But no clue whether there will be 429 if downloaded too quick.
So for future reference it is useful to divide longer livestreams into blocks (e.g. 2hrs maximum or less). Furthermore smaller blocks of 10-20 minutes would be preferred to avoid issues when running into potential 429 responses.
Maybe write a special routine for livestream downloading using dash so that audio and video is downloaded at the same time (spawning two threads one for audio and the other for video).
Also I may offload the custom mpd generation to an external server.
There were quite a few interested in this. I gave it a quick try and noticed that I could get video+audio of livestreams that are running for days. I used Rocket Beans for my testing. As of writing there are about
800.0001.600.000 seconds (translating to almost1020 days) of data bundled it in 800.000 sequences (every sequence is 2 sec)All that is needed is a proper parser and generator. End result should be simply fed to ffmpeg to concatenate those 2s segments.