yt-dlp: All downloads from SBS broken

I’m getting mis-matches on SBS 720 ‘manifest size’ vs ‘download size’ Manifest ( yt-dlp.exe --list-formats…) for https://www.sbs.com.au/ondemand/watch/2213041219665 says 720 file should be " ~674.07MiB". Requesting it gives “377 MB” in total, with the video-stream rate lower than manifest and not so good quality.

This was discussed in March: https://github.com/yt-dlp/yt-dlp/issues/6543#issuecomment-1475604815 SBS’s switch to variable bit rate could yield subjectively better quality for fast moving scenes, even though the average is lower and file-size smaller. The manifest(s) seem to include the maximum possible bit-rate (i.e. they’re using “Constrained VBR”) and the delivered stream may rarely, if ever, reach that rate. It’s not a result of the fixes for this issue; the file size estimating is done by other yt-dlp code not specific to SBS. Projecting the file-size from rate and duration is trivial when the old 1.6MB/s rate is used, and some shows/movies published before SBS made this change are still streamed at this old fixed rate. For pre-encoded material (e.g. not live streaming), VBR is considered preferable.

Best not to use closed issues to report new problems. If you have further problems with SBS, please open a new report.

I honestly don’t like it, but am also not totally against it.

Thanks. If this road is taken, could guard it with an option specific to subs (in case a difference policy is desired for the media file vs. the sidecar), and certainly some logging to flag whether the fix is attempted. However it sounds like there’s not a big push for this fix. Would leave it unless an issue is opened.

How do media players show the dfxp? If mpv/vlc etc adds it, we can do the same. Otherwise this is out of scope for us to fix.

Just checked with VLC. The two ‘lines’ are presented concatentated on one line, with no additional space, so I guess that’s a no on scope. Whatever target SBS uses .dfxp to support, it must grok the significance of the separate <span>...</span> elements and present them more kindly.

Re: SBS subtitles. It’s all over the place. The latest episode of Alone Au (e06) has complete .srt subtitles in the manifest. And they come down just fine.

The .srt subs from SBS themselves should be fine and complete as long as they contain only simple ASCII characters. A show originating in AU with only english language is likely to meet this constraint. It’s the presence of actual unicode that causes SBS’s own conversion routines to fail and leave their .srt subs incomplete.

A Þ in their side, as it were…

Fixing the downloaded .dxfp encoding when not converting to .srt would be a nice enhancement (arguably not a bug; it’s an issue at SBS’s end, see comment here), so maybe open another enhancement report issue request? I’m not sure where in the download processing logic a post-processing step for downloaded subtitles would fit.

I honestly don’t like it, but am also not totally against it. It would have to be written as a FixupPP and handled like other --fixups, but at before_dl stage instead of post_process

and adding extra newlines may not be correct in all cases.

How do media players show the dfxp? If mpv/vlc etc adds it, we can do the same. Otherwise this is out of scope for us to fix.

PR #6839 now in review, vastly improved due to @bashonly, particularly for geo bypass handling, and with some extra improvements to metadata handling for episode and is_live, as well as plenty of coding style tweaks. Has been tested here, but not as much as the earlier PR from @dirkf got. Big thanks to the reviewers for putting up with the python and yt-dlp noobity on my end!

Just to add to what @bnw42 said above, this may help. I’m not a developer but do dabble in PowerShell etc:

# url = original one, eg  $url = "https://www.sbs.com.au/ondemand/watch/2172633667829"
# grab the ID
$url -match "/(\d+)$" > $null
$id = $Matches[1]
# build new url and use that
$newurl = "https://www.sbs.com.au/api/v3/video_smil?id=" + $id
yt-dlp  $newurl

Works in .ps1 script too

NicGeoLaw, Please read the above posts. The issue has been identified and a fix will hopefully be appearing in a future update. Until then use the recommended workaround, substituting the video ID into the following (replacing xxxxxxxx). The video ID is the number at the end of the webpage url for the show you want.

yt-dlp https://www.sbs.com.au/api/v3/video_smil?id=xxxxxxxxx

As of monday evening this was still working.

Leaving out context=tv I still get the highest available quality by default and no adverts. There was a discussion elsewhere last year relating Australia’s other non-commercial streaming TV service that was introducing login requirements and from the PR material they released, their software would query the viewer’s platform to determine which browser and os you were using. If it could not get an answer (which would be the case for TVs or youtube-dl & it’s forks) then the requirement for login creds would be bypassed. Since leaving out context=tv works, I assume something similar may be the case here as well. SBS does require you to login to watch in a browser.

an open question about metadata handling for episodes, and

Ask away - oh, I see you did.

a call to self._sort_formats(formats) that’s deprecated on yt-dlp.

But necessary in yt-dl ATM. Feel free to delete it for yt-dlp.

I’m marking this as patch-available, since Dirkf has PRed ytdl-org/youtube-dl#31880 in youtube-dl. I hope I am using the patch-available label correctly

Yes, and solved-upstream once it’s merged signifying I can close the issue during the periodic upstream merge

I’m marking this as patch-available, since Dirkf has PRed https://github.com/ytdl-org/youtube-dl/pull/31880 in youtube-dl. I hope I am using the patch-available label correctly

And for those of us not up to python coding and compiling? 😃

Lucky for all of you, me and Dirkf discovered that running yt-dlp "https://www.sbs.com.au/api/v3/video_smil?context=tv&id=VIDEOID" works (replace VIDEOID with the number at the end of the sbs url)

Ok, I worked it out. Followed the official steps to regenerate the .exe from the source tree (after changing the sbs.py code) Worked! Thanks for the patch

By the way, you didn’t need to, you can just open command prompt inside the repo and run yt-dlp.cmd URL (the .cmd isn’t strictly necessary, I don’t think)

And for those of us not up to python coding and compiling? 😃

Thanks for the “Workaround: use the android HLS” patch (above). I am relatively new to Python (Windows 10 and Ubuntu 22 via WSL). Is there a guide as to how I can implement this patch? I can use Git on both of my platforms. Thanks

Ok, it worked it out. Followed the official steps to regenerate the .exe from the source tree (after changing the sbs.py code) Worked! Thanks for the patch

For devs out of region, note that the API used by the extractor isn’t geo-blocked, and so the various media links tested in the patch code can easily be inspected.

player_params['relatedItemsURL']

This wouldn’t be a useful substitute to judge from the one I checked: just a JSON playlist of similar shows.

Check the penultimate line of the patch code above to see where the contraband fragment comes from.

This mechanism is used to pass options with a URL from a user-facing extractor (eg SBS) to a video host extractor (eg ThePlatform) through a url or url_transparent extractor result.