spaam/svtplay-dl

Request

Opened this issue · 7 comments

Lunarwalker60 commented

Does anybody have any ideas about capturing live-streams from SVT?
My goal is to fix my Windows timed recorder app which has stopped working since SVT changed live-streaming to DASH/MPD.

/S

pythonuser3856 commented

Please see #1398
My work-around is manual handling; capturing video still works using the switch --live and I capture audio using Audacity from playing the web live-stream in a web browser. It can be rather time consuming to get video and audio in sync afterwards.

Lunarwalker60 commented
pythonuser3856 commented

Thank's for the tip !
I've used your information to create an automated script solution for time based recordings (replicating VCR-recorder). This is, however, just a temporary fix; there are pieces of information missing so it's not as good as an an intrinsic feature of svtplay-dl could be.

pythonuser3856 commented

I have used "svtplay-dl --get-url" to get a valid m3u8-reference and have previously got the very links
"https://svt1-c.akamaized.net/se/svt1/..:" and
"https://svt-live-c.secure.footprint.net/se/svt2/..."
that you refer to here above.

However, when I now use "svtplay-dl --get-url" I instead get the links
"https://svt-secure-c.akamaized.net/secure/svt1/..." respectively
"https://svt-secure-c.akamaized.net/secure/svt2/..."

Using either of the links that I now get from svtplay-dl does not work with ffmpeg.
The good thing is that your original links still works with ffmpeg !

spaam commented

man im getting a bit tired of this the whole scraping video stuff. maybe its time to shut it down? 🤔 fix one issue get another issue. i dont want to start processing all the data to see if they are valid then download it again to get files people like.

you can try to revert this commit 94eb854 . its related to #1510 it had bad files in it.

pythonuser3856 commented

I added the comment since it's necessary to be aware of at using FFmpeg to capture live SVT channels (as a workaround while waiting for svtplay-dl to provide live support).
If it should boil down to a choice; in my view it's more important to have support for live capturing compared to #1510 "deal with incorrect information about available audio variants" since that can be detected and handled.
Sorry if I stirred things up.

pythonuser3856 commented

Reverting the commit 94eb854 does not make any difference when I try.

Based on that I'll stick with my current solution,
a script-based substitution of the first part of the m3u8-link with what @Lunarwalker60 refers to, and then feed it as one of the parameters to FFmpeg.
That works for now.