wvitm
wvitm copied to clipboard
Bad Compatibility Across Players, Playback Freezes, Stutters, Loops, and such
This happens only on services that actually use the intercepting trick (/shaka base route injection) e.g., Channel4 and RTE. It's always a minute or two into playback, it's not usually anything more than 2 minutes or so. I've done so much debugging, I tried reducing the time per call, messing with HTTP return codes, error checking, and more. All without any idea as to why it happens. I've sometimes thought I figured it out as it lasts to 2 minutes, then begins to happen again.
I cannot find any patterns as to why it happens, and nothing I try and print to monitor is highlighting any errors on wvitm, but it definitely happens. I'm using MPV and this definitely happens on Channel4 and RTE, as well as ITV which is currently not pushed to the repo. This has been happening since day one of this project and even before this repo was made, where it was originally a gist repo with one big flask python file.
DASH-IF reference player (no issues)
This issue never happened to me on the DASH-IF reference player made in JavaScript. I was hoping it would due to its extreme amount of debugging potential, but sadly it does not.
However, it only works if I do not do the remove init data code (the out = out[moov_start + moov_length:]), otherwise, it infinitely loads (everything seemingly fine, but it never actually buffers or downloads data, but it does make requests, strange).
ffplay (some issues)
Playing using effectively ffmpeg works similarly to the DASH-IF reference player, but I do notice some flickering and whenever I can tell it would have started to happen, it always kicks in and fixes itself almost immediately. Today when testing I started ffplay and it actually happened and didn't recover until about 20s in.
MPV (freeze loops)
https://user-images.githubusercontent.com/17136956/179160484-ad5d603e-2e0d-4223-b537-a0c923bac0b2.mp4
As you can see in the video above, if I click in a bit on the seek bar, it will eventually fix itself for only a short amount of time. What I will say is it never before took me a couple tries of seeking in to have it fix itself, normally the first re-seek will fix it. The fixes also lasted only a second here where usually it lasted maybe 10+ seconds.
I've found one thing that does seem strange and somewhat reproducible. For channel4 (e4) specifically, it's often the 9th segment per representation on my end that ends up being looped.
I've looked very carefully at the mp4 boxes as the only reasonable difference between all previous and next segments, is a discrepancy in the sidx "earliest_presentation_time" between segment 9 (the one that loops) and segment 10.
There's a small discrepancy of usually about 0.0024576~ seconds worth of missing samples. The missing samples are either missing from the end of Segment 9 (most likely) or the start of Segment 10 (unlikely). If we take a close look and count the duration of each moof box, we end up with 8.0000 seconds worth of data on every segment (1-10). This means we should expect timestamps to increase by exactly 8 seconds on every segment.
However, if we take the sidx "earliest_presentation_time" of segment 10 (658489343) and subtract it by the value from segment 9 (578464767) and divide it that by the same 10000000 timescale, we end up with a value of 8.0024576. Yet the entries.n of the sidx all add up to a duration of 8s for both segment 9 and 10. Quite strange.
VLC (doesn't play)
It never loads at all, it has never loaded for me, ever.

Hi, did you try on Streamlink ?
Or did you have try to change tempfolder to "/tmp" or "/var/tmp" because tmp or /var/tmp is under tmpfs , maybe can give better i/o rate @rlaphoenix ?
Hi, did you try on Streamlink ?
It works quite well with streamlink running through mpv or vlc. Possibly more stable than ffplay surprisingly. Not entirely sure why either.
Or did you have try to change tempfolder to "/tmp" or "/var/tmp" because tmp or /var/tmp is under tmpfs , maybe can give better i/o rate @rlaphoenix ?
I'm actually on Windows, but I don't think this is the issue regardless.