I've recently switched my employers self-hosted video player from Flash to HTML5 Video. Since the switch, we have had increasing numbers of users report that they are unable to play our videos.
Through a series of error-reporting functions, and further tests with users I can say conclusively that the issue is with the video files themselves. The users are capable of playing the file type, and having compared with the likes of YouTube, Vimeo etc, I cannot see any clear reason why the way our videos are enconded would cause a failure. The issue largely affects users on older of lower-end devices, but not exclusively.
I have included screen grabs of a typical videos settings for review in case anyone is able to spot an obvious problem.
Image 1: https://i.stack.imgur.com/A3zOS.png
Image 2: https://i.stack.imgur.com/Hdu6I.png
Edit:
The users cannot initiate playback at all. We have provided them with direct links to the video files, so their browsers can play them in their natural optimised state - and still nothing works.
The error reporting we have implement shows us a range of data from connection speed, device info, browser info, location and tracking various possible points of error throughout our full player. There doesn't appear to be any notable correlation between users other than almost all Chromebook users have issues. But many others do also.
Related
I'm not entirely sure if Stack Overflow is the correct website to ask this question, but I have been thinking about it ever since a friend mentioned it to me a week ago. I know on a baseline level what hardware acceleration does: offloads certain workloads to other components in your computer (i.e. your GPU or sound card) to improve performance in various applications. I just would like to know what exactly is happening when hardware acceleration is on v/s off when streaming a Google Chrome window and why it makes a difference in a completely different application.
If you're unfamiliar with what I'm referencing in the title, here's a simple example of what I mean: Let's say you want to watch a Netflix show or sporting event with your friends on Discord, so you all hop in a call together on the app to watch you stream the video in a Chrome tab. However, when your friends join the stream, they can hear the audio of what you're streaming but the video feed is blacked out for those watching. Interestingly enough, one of the solutions people have found to this issue is disabling hardware acceleration in Google Chrome's settings which allows the video and audio to be streamed no problem.
It makes sense why this occurs: to prevent potential piracy and illegal redistribution of copywrited material, but why does disabling hardware acceleration re-enable this functionality? Does hardware acceleration allow data to be shared between apps? Does Discord set a flag saying a particular window/screen is being streamed and Chrome can only "see" that flag while hardware acceleration is enabled?
I guess the underlying question is: how does having hardware acceleration enabled allow Netflix, a TV provider or any other website for that matter to know their content is being streamed?
feel free to recommend other tags for this post, didn't want to include discord because it's not referencing their API
edit: also, please let me know if this is off-topic so I can delete it and repost on another website
The hardware acceleration allows the HDCP content to remain encrypted all the way to the display. By disabling it, the video is decrypted in software usually at a reduced resolution and/or frame rate.
I use Google chrome as my browser, and when I'm outside of my home, I often tether my laptop to my phone for internet.
I sometimes listen to music or watch videos on youtube in the aforementioned circumstance, often repeating the same videos.
Is it possible to configure the browser to store the data from the videos /forever/ (or at least longer) because I've even left my computer on for a couple days, and as soon as I go offline the video will bug at some point.
It seems senseless to be continually reloading streamed videos and in so doing, eat up all of my limited data.
If the browser can temporarily store the video (which it must do) is there some way to extend the lifetime of that data?
I have successful get the video streaming of local camera by use getUserMedia() in HTML5.But only one camera.I have two cameras,how to get their video streaming at the same time.
Unfortunately this does not appear to be possible, yet. See here and the comments below this article here. Basically the user decides via their browser settings which camera is primary, and no option for secondary, etc, camera exists as of yet.
I am trying to develop a test taking website for students. In this website, students should be able to answer the questions(displayed in text format) by using webcam in one go. Currently I have implemented this feature using Flash, it captures the frames and simultaneously sends it to the server. The problem with this technique is that the quality(FPS) of my video is restricted and is dependent on the bandwidth of the internet connection. Also I am not in favor of using flash.
I want that as soon as student clicks on the start button, a timer should start to record the video. The video should get saved on the client's machine (without asking the client to mention the path) and on completion of video, it should automatically get uploaded on the server and when uploading gets completed, the video should be automatically deleted from the client's machine.
In short can anyone give me a starting point, so as to I can proceed with the work. Any helo will be highly appreciated.Thanks!
Here is a good example how to get webcam working on html5:
http://blog.teamtreehouse.com/accessing-the-device-camera-with-getusermedia
It doesnt tell how to upload the video to the server.
Currently I have implemented this feature using Flash, it captures the frames and simultaneously sends it to the server. The problem with this technique is that the quality(FPS) of my video is restricted and is dependent on the bandwidth of the internet connection.
That is actually incorrect.
The fps you're getting depends 100% on:
the webcam quality
the light available in the room (the more light the better)
The resolution you're recording at (lower res results in higher fps even with low quality webcams in low light)
The video should get saved on the client's machine (without asking the client to mention the path) and on completion of video, it should automatically get uploaded on the server and when uploading gets completed, the video should be automatically deleted from the client's machine.
Flash records by streaming (through rtmp) the audio/video data to a media server (Red5, AMS, Wowza). After the recording is stopped you could move the file to a web server and trigger a http download.
In what regards HTML the Media Recording API has been implemented by Firefox and Chrome 49 and it allows you to record to local RAM and download the file as .webm (the audio video codecs might differ btwn browsers).
Disclaimer: I work at Pipe which handles video recording.
I'm looking for a way to securely deliver video to mobile devices. There are two options:
HLS in tag. This works very nicely for iOS and supports adaptive bitrate, perfect for mobile. However, is seems to only work well on iOS. There seems to be only fragmented support for it on Android. I've read that Android has officially supported it since 3.0, but on all the android devices I've tested (>3.0), HLS hasn't played back on the browser.
Progressive download in tag. This will work on iOS and Android devices fine, but the concern is that since it's just a progressive download of the video, that the user find a way to just grab that video once the browser has finished downloading it. This may be more difficult on iOS, but I'm sure it's not that hard to figure out where the browser stored the video download in a tmp folder somewhere.
Either method I'd say can be protected from deeplinking by using an expiring token approach, where the token is generated serverside with a secret key that only the content server knows about. The video request would only be valid for 5 or 10 minutes, would would kill of deeplinking.
Is anyone aware of any way around these issues? Even if I was able to prevent deeplinking, the user could still get the video itself and re-distribute. Perhaps it's just not possible?
Thanks
Rule #1 of the internet:
If you don't want someone stealing it, don't put it online.
Welcome to the circumvention arms race. Brought to you by DownloadHelper.
There's nothing you can do to stop someone who really wants to pirate your video. There are various measures, like those you mention, that make it more difficult, but someone who really wants to copy it could find a way to capture it from memory, or even just point a camera at the screen and record the playback of the video.
It's the same way you protect your car. You install a steering lock, an alarm and an engine immobiliser, and then someone comes alongs and pulls the car onto a flat-bed truck and drives away with it.
Bottom line - you can't stop a determined thief, but you can make theft more difficult so that you're not the most attractive target.
As I was reading the above I could easily get pass all these techniques pretty quickly.
For a project I can't describe too much because of nda, we created our own protocol based on a well known encryption method can't mention that either , military grade) , encoded packets on the server to the protocol, and decoded on the device.
unfortunately this isn't perfect either because a lot of mobile apps can be re-versed engineered and once you get the key game over, very easy on android, of course you could periodically recycle the key, in which case even if they decompiled the android app and got the key it wouldn't work very long.
This is a lot of work and can't be implemented with html5 or hLS or event rtsp.
It also requires a custom server application that takes the video stream re-transmits it with the custom protocol.
On the other hand the protocol was transport agnostic, which meant we could use a variety of transports, tcp, IAP and bluetooth. Also would work on all mobile / desktop platforms.
The other little requirement, is couldn't use a browser, have to be a custom app.