VideoPlayer URL mode cannot play with the correct format with http:// protocol

Hi!

We are aware of this problem, which is filed as bug #86119. This will addressed it in an upcoming beta. Sorry for the inconvenience!

Thanks for testing out the VideoPlayer. If you're in a position to test with the OSX version of the editor, the bug doesn't appear on this platform.

Dominique

 

Just so you know: not all streamed videos exhibit this problem. This URL for instance is reported as working by other users: http://www.quirksmode.org/html5/videos/big_buck_bunny.mp4

Please let us know if this is also working (or not) for you!

Dominique

 

Hey everyone!

I had time today to look at the http:// streaming situation on Windows and found a couple of issues that explain what you are observing. I've fixed them and I'm in the process of integrating this into out mainline. Not sure yet what beta this will end up going into, but you can stop wasting time on this. The bug id is 861191.

Sorry for the trouble and thanks for the reports.

Dominique

 

Hardware acceleration is always enabled when available. It isn't always possible for us to know exactly how much hardware acceleration is happening because the native APIs in use don't reveal it. For instance, we use the Android native API to decode videos, but it may very well provide a software implementation without telling anyone if for some reason the decoded video doesn't fit the definition of what is supported for the given hardware/OS combination at hand.

One place where we consistently get hardware acceleration is for the YUV to RGB conversion. Movie files typically have their video tracks stored using YUV color space, and we systematically perform this conversion on the graphics hardware.

At this point, you can stream from http:// and https:// URLs, provided the full URL ends with the container name (e.g.: http://some/path/to/stream.mp4). We use the extension to decide what decoding back-end gets used. Right now, the URL cannot have a query-string (e.g.: http://some/path/to/stream.mp4?quality=medium) but this will get fixed in an upcoming beta. The one scenario we don't yet have a solution for is for URLs that don't reveal the container type at all (e.g.: http://path/to/stream). Not sure yet how/if we'll address this for 5.6.

Other types of URLs may be supported on certain backends (e.g. rtsp:// or rtmp://); we may have time to run some tests and enable these if they do work.

I'm assuming you are asking for Windows, using H.264 video (let me know if I'm wrong). On this platform, the most important variable is the Windows version. The native API is the same regardless of version, but has different limits depending on the Windows version. So the closer you are to Windows 10, the higher the resolution that can be accommodated by the hardware acceleration.

Note that the VP8 codec (done in software everywhere except on WebGL and Android) is not subject to these limitations, so for this one only the CPU speed is the limiting factor.

We'll provide adequate guidelines with the user documentation, but feel free to ask for details in the mean time; it'll help tuning the doc.

Hope this helps!

Dominique