I confirm @Kandid 's report, but I can’t find any clues in the Peertube logs of our instance.
I couldn’t either find any existing bug report in the Peertube issue tracker. It’d be great if someone else could try searching too. If no existing bug reports about this show up, I’ll be happy to file a bug report.
not even sure this makes sense but maybe it’d help if someone downloaded the original file by @Kandid (should be this link), check it and confirm this issue has nothing to do with the file itself (keyframes, etc)?
another useful attempt could be to upload this same video to another Peertube instance (best if managed by someone who’s open to look into this and discuss with us) and compare the results
I’ve been making more tests and looks like this same issue affects different videos on our instance and it seems that duration, size, ratio or audio don’t matter.
affected files seem to all be mp4 files, encoded in h264, yuv420p Pixel format, “High” Profile. they also all seem to have bitrate > 1-2 mbps.
but other videos on our instance (including this one with a 4 mbps bitrate) are encoded in the same way, and they seem to play fine.
let’s build a list of files affected by this problem.
please check the following videos and confirm whether they’re affected by the same issue, or if they play correctly for you.
thank you both for helping to troubleshoot this. the example videos are playing ok for me but i’m on my phone so it’s likely playing a lower quality rendition for me.
unfortunately things are too hectic for me to help troubleshoot from a computer right now, but i will try to look into this issue when i am able to (likely after i finish moving). one thing i have found helpful is to look at the javascript console in developer tools in the browser, sometimes peertube will spit out helpful information in there.
This is the Debug Console in Firefox 78.10.0esr (64-bit). On a Debian 10 system.
However, the “HLS.js error: mediaError - fatal: false - fragParsingError” is also listed in the console for videos that can be played from the beginning.
It is possible that the problem is not directly related to videos.scanlines.xyz. But with the connection of the browser on the local PC with the provider of the cloud storage.
As I understand it, the video stream is not loaded directly from videos.scanlines.xyz (134.122.124.248 / digitalocean?) but from Wasabi.
130.117.252.10 seems to be a server in Amsterdam Netherlands.
that’s right, the storage is wasabi, we don’t have nearly enough storage on the digitalocean droplet to host all the video content.
it does seem like there might be issues with the “handshake” between wasabi, the peertube client, and the user. the hls stream / peer to peer functionality seems to be pretty complex and tricky to debug -_-
i just ssh’d into the droplet and checked with ffmpeg -v :
ffmpeg version 3.4.8-0ubuntu0.2
so yeap this might be the problem - i can try updating the ffmpeg version now.
another thing we could do just to narrow down the problem is disable the wasabi static object storage for a moment and test uploading some videos directly to disk. and then see if the problem is still there ? if not then atleast we know the problem is in the static object storage somewhere
(replying here while we figure out what this is about)
Today I found out the first video below wasn’t playing. I guess this means it never played in the first place? I thought I had verified it was working when I first uploaded it. Anyway I just imported it again and that’s the second video. This is an import from the Internet Archive, and specifically from an h264 file generated by them. The two videos have the same specs except for the “Format/Encoder” version which turns out to be Lavf57.83.100 for the older/failing import, and Lavf58.45.100 for the second one.
for the second video, as I’m writing there’s still a “it’s being transcoded, it may not work properly” message but it’s playing correctly for me (reminder this is NSFW, sometimes in surprising ways)
Sorry to revive an old topic; I think I’ve narrowed down a source of PeerTube buffering issues.
I’ve always experienced stuttering playback on scanlines, where videos would buffer then stop, buffer then stop, etc. I’d always assumed this was due to VPS bandwidth, but I now think this is actually a WebTorrent vs HLS playback issue.
Peertube version on videos.scanlines.xyz is 3.0.1. Here’s one of my videos there:
Peertube version on diode.zone is 4.0.0. Here’s the same video hosted there:
I get the stuttering playback from scanlines but smooth playback from diode.zone.
PeerTube made HLS playback the default in version 3.2.0. They go into detail about the relative benefits of HLS for playback, bandwidth and storage in their docs.
I think that upgrading the latest Peertube and enabling HLS will make videos play a lot smoother.
i started trying to update peertube to v4 but as expected quite a few problems (something went wrong updating node causing a kernel panic and required recovery booting to sort out ) thats fixed now but theres many other things breaking, but iv done enough for the day will try sort it out tomorrow or atleast b4 the weekend
)
) thats fixed now but theres many other things breaking, but iv done enough for the day will try sort it out tomorrow or atleast b4 the weekend