Piped
Piped copied to clipboard
TeamPiped
Far more buffering than plain youtube
Constant buffering / videos not loading at all seems to be a consistent issue, that I face only while using Piped as opposed to vanilla Youtube
You could try setting a default quality and increasing the default quality, this should help significantly.
The US server is also significantly slower, for some odd reason, it has now been temporarily disabled.
You could try setting a default quality and increasing the default quality, this should help significantly.
The US server is also significantly slower, for some odd reason, it has now been temporarily disabled.
I have a default quality set
Do you still have this problem?
yes, i've had it the entire time i've had a default quality set
Could you send a screenshot of your timings/waterfall graph in the network tab of your browser's web tools?
Example screenshot:
Well actually, I switched to 720p and I haven't had any issues. Which is strange because I don't have any buffering issues with 1080p on youtube
Could you send a screenshot of your timings/waterfall graph in the network tab of your browser's web tools?
Example screenshot:
This is with 1080p default quality:
Since you're using Firefox, could you try disabling network.http.http3.enabled in about:config temporarily and test again?
Firefox had a slow implementation of http3 the last time I checked it.
Since you're using Firefox, could you try disabling
network.http.http3.enabledinabout:configtemporarily and test again?Firefox had a slow implementation of http3 the last time I checked it.
it's actually already off, maybe because i'm using LibreWolf. I'm having considerably less issues with 720p set as my default quality, so I might just stick with this tbh
I had mentioned that I have this issue as well in issue #224 (in a slightly different context), and I don't think that you do not have an issue with 720p, but rather that the bandwidth needed for 720p is much smaller.
And @FireMasterK, while I could very well be wrong, I do not think that this has to do with Firefox's HTTP3 implementation, as my tests showed the same results on both Firefox and Edge, on both Windows and Linux, with HTTP3 support enabled and disabled.
I had mentioned that I have this issue as well in issue #224 (in a slightly different context), and I don't think that you do not have an issue with 720p, but rather that the bandwidth needed for 720p is much smaller.
And @FireMasterK, while I could very well be wrong, I do not think that this has to do with Firefox's HTTP3 implementation, as my tests showed the same results on both Firefox and Edge, on both Windows and Linux, with HTTP3 support enabled and disabled.
Yeah you're right, but it seems to be even worse now, at 720p I'm getting constant buffering. It's making Piped nearly unusable sometimes.
A major change has been made, could you tell if it is better?
With these changes, even with a VPN to NL, I'm able to watch 1080p content at a good speed.
In terms of buffering, I'm either getting the same or slightly better (still testing to make sure that this is not placebo), however Firefox isn't offloading anything to the GPU, for some odd reason (will be posting an issue at the Solus Phabricator (Solus's code hub)), and interestingly, Piped seems to require more CPU time than Invidious or CloudTube (other system resources are perfectly fine, and just as always).
In terms of buffering, I'm either getting the same or slightly better (still testing to make sure that this is not placebo), however Firefox isn't offloading anything to the GPU, for some odd reason (will be posting an issue at the Solus Phabricator (Solus's code hub)), and interestingly, Piped seems to require more CPU time than Invidious or CloudTube (other system resources are perfectly fine, and just as always).
Do note that piped is using VP8 by default, but Invidious is using mpeg4 instead. VP8 requires more CPU power, but the file weight less than a file in mpeg4.
Also about the offloading to the GPU, I'm not entirely sure but mpeg4 is more well known than VP8 so GPU are capable of decoding the mpeg4 codec but VP8 not yet.
On Firefox, with the VA API, I couldn't get it to work for WEBM videos on Linux, even with these flags:
media.hardware-video-decoding.force-enabled
media.ffmpeg.vaapi.enabled
gfx.webrender.all
To make sure it's not only Piped/VP9, I also tested Invidious which was stuttering/stalling completely on 4k videos.
I do however remember that hardware acceleration with VP9 worked excellently with Firefox back when I used Windows, I used to play 4k videos with ease, both on Chromium and Firefox.
I did try playing 4k with MPV, and it worked effortlessly when using hardware acceleration!
@unixfox That would certainly explain it, since some of the hardware I am using does not support VP8 or VP9 (my laptop does, though not completely (Skylake iGPU).
Regarding buffering, it was placebo.
I am getting slightly better results by setting the buffer Target to 25, however.
And don't you mean H.264, which is a newer standard based on MPEG-4?
@FireMasterK Could you give an option, where applicable (most videos up to 1080p,I believe), for the stream to be a h.264 stream instead? That would immensely help, not only Firefox users on Linux, but also users of older hardware (like my sister's BayTrail laptop)?
I've added support for enabling/disabling codecs in c6f096d8be1a0d2b71c5ac5579e28cebadd17a6e. Let me know if that helps.
Thanks, I won't have time to check it in the next 24 hours, however, so I'll test it as soon as I can (I just turned off my laptop, and am about to turn off the Android device I am currently typing this from).
I just tested, and am getting... weird results.
For reference, all tests in this post were done on a Lenovo IdeaPad 300-15ISK, with an i5-6200U and a Radeon R5 M330 (Lenovo's stock base clock is 750Mhz instead of 955Mhz) (18W TGP) and 8GB (4+4) of 1600Mhz DDR3L RAM and a 7200RPM SATA HDD.
OS: Solus (Linux) Browser: Firefox stable (from Solus's repos)
I disabled SponsorBlock, set the light theme, disabled autoplay (which keeps on reenabling itself whenever some of the other some are changed, will be a separate issue once I have the time to reproduce the details), set default resolution to 720p and kept the buffering goal at 10 seconds. I made sure these settings were set for each test.
Only CPU load was tested, not any other external variable.
Video tested was https://piped.kavin.rocks/watch?v=5_LOB-_WhJI
720p AVC: ~%40-60 (mostly ~%44-50) VP9: ~%43-71 (mostly ~%44-54) AV1: ~%41-77 (mostly ~%57-69) All selected: ~%44-68 (mostly ~%52-68)
1080p AVC: ~%48-71 (mostly ~%48-64) VP9: ~%32-74 (mostly ~%44-65) AV1: ~%43-84 (mostly ~%49-67) All selected: ~%43-80 (mostly ~%44-70)
720p AVC: ~%40-60 (mostly ~%44-50) VP9: ~%43-71 (mostly ~%44-54) AV1: ~%41-77 (mostly ~%57-69) All selected: ~%44-68 (mostly ~%52-68)
1080p AVC: ~%48-71 (mostly ~%48-64) VP9: ~%32-74 (mostly ~%44-65) AV1: ~%43-84 (mostly ~%49-67) All selected: ~%43-80 (mostly ~%44-70)
Something doesn't add up here.
Enabling only AV1 or All selected will default to VP9 since it's the lowest bandwidth.
If this is the CPU usage from just one core/thread, it's normal.
@FireMasterK I agree, especially since these are very rough averages since it was wildly inconsistent (I also had a few disconnected cases where I had CPU utilization in the 20s, only for it to jump up to the 80s, regardless of the resolution and codec).
And no, this is multicore (2C4T), as shown by the process manager GUI (gnome-system-monitor).
The only thing that was consistent, was CPU utilization rising by about 10% whenever the video controls were present.