webm (vp9/opus) stuttering on mobile

[machenotizia]

Hi from Italy;
i'm making several tests with vp9. I want to understand if i can use vp9 istead of h.264 to improve quality/bitrate of my videos online.
i have some problems.
Firefox and Chrome (desktop windows) can playback without problems WebM(vp9/opus) videos.
Chrome on Nexus 4 , Samsung Galaxy S3, Nexus7, with Kitkat or Lollipop, has stuttering problems. There is not a bandwith problem because videos are server by local web server.
I tried with several encoders and several parameters (changing profile from 0 to 3) but nothing changes.
so, with youtube-dl i downloaded some youtube videos, and those videos works well, but has no audio track (?).
i tried to understand what are differences about my videos and youtube videos by mediainfo, but i'm not able to understand what change.


this is a sample use of encvpx.exe script called by "Hybrid" encoder gui. Hybrid is the name of the software.

vpxenc --codec=vp9 --passes=1 --pass=1 --target-bitrate=1500 --end-usage=vbr --good --cpu-used=3 --undershoot-pct=0 --buf-sz=6 --buf-initial-sz=4 --buf-optimal-sz=5 --drop-frame=0 --resize-allowed=0 --kf-min-dist=0 --kf-max-dist=250 --auto-alt-ref=0 --noise-sensitivity=0 --sharpness=0 --static-thresh=0 --tile-columns=2 --tile-rows=2 --threads=8 --width=1280 --height=720 --yv12 -o "C:\Juassikvp9.vp9" -

i tried also with mediaCoder, but nothing changed.

any suggestions to avoid stuttering problem? How youtube encode vp9 avoiding stuttering problems?

thanks.

[xooyoozoo]

Turn on frame-parallel. Also, tile-rows is for lower latency, not parallelism.

[Nintendo Maniac 64]

Be aware that most GPUs and mobile devices don't have hardware decoding of VP9 yet, so it has to be done in software. Because modern PCs have much faster CPUs than mobile devices, a typical modern PC will be able to decode VP9 video just fine while a mobile device will likely choke and turn into a stutter fest (this can also happens on older and lower-end PCs as well).

When it comes to YouTube on mobile, I believe the YouTube app currently defaults to h.264 (I'm not 100% sure on this, so I'm going to check in a bit...)

If you really want to get VP9 playing on mobile, you'll probably have to use a lower resolution like 480p or 360p.

[machenotizia]

Originally Posted by Nintendo Maniac 64

Be aware that most GPUs and mobile devices don't have hardware decoding of VP9 yet, so it has to be done in software. Because modern PCs have much faster CPUs than mobile devices, a typical modern PC will be able to decode VP9 video just fine while a mobile device will likely choke and turn into a stutter fest (this can also happens on older and lower-end PCs as well).

When it comes to YouTube on mobile, I believe the YouTube app currently defaults to h.264 (I'm not 100% sure on this, so I'm going to check in a bit...)

If you really want to get VP9 playing on mobile, you'll probably have to use a lower resolution like 480p or 360p.

mmh no, i downloaded a youtube video with youtube-dl and this video works fine, but it doesn't have audio tracks

[MoSal]

Originally Posted by machenotizia

mmh no, i downloaded a youtube video with youtube-dl and this video works fine, but it doesn't have audio tracks

DASH streams only contain audio or video. So you'd have to also grab the audio stream and mux A/V streams into one file yourself.

Not a lot of videos on youtube have Opus streams, though. And I don't know if browsers support VP9/Vorbis. AAC was never a part of webm's supported container codecs AFAIK.

Personally, I don't care about codec combinations as I don't use browsers for playback. And Matroska supports all combinations.

[Nintendo Maniac 64]

Originally Posted by machenotizia

mmh no, i downloaded a youtube video with youtube-dl and this video works fine

Dedicated media players are likely to have better optimized decoder performance compared to web browsers. Case in point, MPC-HC v1.7.8 uses much less CPU for decoding VP9 than any web browser.

[machenotizia]

@MoSal thanks, now i have understand.

i did not give an important information : i work on website and i want to use vp9 to give higher quality at the same bitrate instead of h.264.

My first target is android because android does not support apple streaming very good so i must to use progressive download.

Youtube webm content works good on my nexus4.

i will try to understand @xooyoozoo indications and so i can publish an example page, if you are interested.

thanks to all, really.

[vivan]

Have you actually confirmed that with vp9 you're getting better quality than with x264 (--preset veryslow, 1-pass crf with vbv)?

Otherwise you're loosing h/w support that every device has, waste server storage and greatly increase encoding time for no reason whatsoever.

[machenotizia]

Originally Posted by vivan

Have you actually confirmed that with vp9 you're getting better quality than with x264 (--preset veryslow, 1-pass crf with vbv)?

Otherwise you're loosing h/w support that every device has, waste server storage and greatly increase encoding time for no reason whatsoever.

Really? I thought it was understood that VP9 will ever give better quality that x264.

no?

[benwaggoner]

Originally Posted by machenotizia

Really? I thought it was understood that VP9 will ever give better quality that x264.

no?

It is claimed, but I've not seen any real-world demonstration of properly-tuned x264 encoding looking worse with the same content and bitrate of a properly-tuned VP9 encoding. Particularly if you normalize by using equivalent encoding time.

If someone does have such a demo, I'd love to see it.

[jethro]

VP9 is better than x264 at very low bitrates. The lower you go the better vp9 looks in comparison.

[SeeMoreDigital]

Originally Posted by jethro

VP9 is better than x264 at very low bitrates. The lower you go the better vp9 looks in comparison.

Really...

Like Ben, I would be most interested to see some comparisons.

[machenotizia]

Originally Posted by SeeMoreDigital

Really...

Like Ben, I would be most interested to see some comparisons.

there is a way to compare with a matematical score of difference from encoded video with the original one?

i don't want to compare it subjectively.

Talking about slower conversion of x264 i tried to keep Constant Quality (CF 20) and try slower to faster conversion. Slower makes smallest file.

thanks.

So, i tried also with H.265, but i obtained same size of x264 ...

Your advices is very good for me, thanks,

but i don't want to go off topic about vp9 stuttering problems on mobile, if possible.

[benwaggoner]

Originally Posted by machenotizia

there is a way to compare with a matematical score of difference from encoded video with the original one?

i don't want to compare it subjectively.

This is huge and religious topic, but big picture is that the mathematical scores that can be calculated don't highly correlate with subjective video quality. The VPx series has historically been highly tuned for the PNSR metric, which is one of the easiest to calculate, but which has one of the lowest correlations to subjective quality ratings. SSIM is another common one which is better, but still not great.

All the standard metrics that get cited are also single-frame only, which means they don't account for how images change between frames. Since that's a critical component of moving video, codecs heavily optimized for SSIM and PSNR will tend to introduce temporal artifacts.

x264 and x265 are primarily optimized towards subjective quality. There is the internal metric of "rate factor," but it's not designed to provide objective comparisons between difference pieces of content or different settings, and isn't available in any other codecs.

but i don't want to go off topic about vp9 stuttering problems on mobile, if possible.

Without a hardware decoder, the primary limitation of a software decoder is pixel fill rate (height * width * fps), with some factor from bitrate. The design of VP9 forces a highly serialized decoder design, and lacks b-frame to drop. This means if a single frame is dropped in decode, the rest of the GOP is unplayable.

I'd expect that the limitation of VP9 would be based on single-core performance. Reducing frame size is the easiest way to improve performance, followed by reducing bitrate, and lastly reducing frame rate. Since frame rate needs to be divided by an integer, it's a particularly painful way to reduce CPU load, and is very rarely worth it unless you're already below 320x240.

There have been improvements in VP9 decoder performance, so making sure that a recent one is being used would also help. Although enforcing that for customers would be challenging.

[xooyoozoo]

Originally Posted by benwaggoner

I'd expect that the limitation of VP9 would be based on single-core performance. Reducing frame size is the easiest way to improve performance,

VP9's column-wise parallelism is effectively splitting a frame into several small frames. It's similar to and is about halfway between HEVC's tiles and slices. Like tiles, there's no signaling/encapsulation overhead for each element, but like slices, the long rectangular elements (as opposed to square'ish ones) result in more dependency breaks and decreased efficiency.

The weird thing, though, is that Google's (and therefore Chrome's, Opera's, Firefox's) VP9 decoder needs the encoder to operate in `frame-parallel` mode, which additionally worsens entropy coding because that also disables the backward context update tool.

[machenotizia]

thanks for your knownledge sharing.

it's fantastic learn those high technical level informations.

[benwaggoner]

Originally Posted by xooyoozoo

VP9's column-wise parallelism is effectively splitting a frame into several small frames. It's similar to and is about halfway between HEVC's tiles and slices. Like tiles, there's no signaling/encapsulation overhead for each element, but like slices, the long rectangular elements (as opposed to square'ish ones) result in more dependency breaks and decreased efficiency.

Column parallelism is very strange, since there's a lot more correlation along the horizontal axis than the vertical. Plus motion vectors tend to be much more horizontal than vertical.

The weird thing, though, is that Google's (and therefore Chrome's, Opera's, Firefox's) VP9 decoder needs the encoder to operate in `frame-parallel` mode, which additionally worsens entropy coding because that also disables the backward context update tool.

Well, I guess it doesn't matter, then .

It's troubling if there are legal VP9 features that don't work in current decoders. There should be some sort of profile/level way to signal and constrain features for device compatibility. Doing it feature by feature is quite fraught.