When i use flutter normal video player in my project when video playing high data consumption and data using speed above internet speed indicator show above 3 to 5 MB speed ,
how decease data consumption and how limit data speed
you can use a lower resolution video: Lower resolution videos will have a smaller file size, which will result in less data being used.
se a video streaming service: Instead of downloading the entire video, a streaming service will only download the parts of the video that are currently being watched, which can decrease data usage.
also you can use Limit data speed: You can limit the data speed in your app by using a package like "data_usage" or you can use "flutter_speedometer" package to show the internet speed in your app.
Related
I'm using a youtube video player in my app and I cannot adjust the quality of the video, it automatically adjusts to the internet speed. I don't want to my app to consume mobile data, so want to limit the app's bandwidth based on the video quality the user chooses.
How can I do this?
How streaming apps like Youtube, Hotstar or any other video player app, programmatically detects if network is getting slow over run-time and based on that they change video quality based on changes in network speed?
Many streaming services nowadays use HTTP-based streaming protocols. But there are exceptions; especially with low-latency streaming; e.g. WebRTC or Websocket-based solutions.
Assuming that you're using a HTTP-based protocol like HLS or MPEG-DASH, the "stream" is a long chain of video segments that are downloaded one after another. A video segment is a file in "TS" or "MP4" format (in some MP4 cases, video and audio are splitted into separate files); typically a segment has 2 or 6 or 10 seconds of audio and/or video.
Based on the playlist or manifest (or sometimes simply from decoding the segment), the player knows how many seconds of a single segment contains. It also knows how long it took to download that segment. You can measure the available bandwidth by diving the (average) size of a video segment file by the (average) time it took to download.
At the moment that it takes more time to download a segment than to play it, you know that the player will stall as soon as the buffer is empty; stalling is generally referred to as "buffering". Adaptive Bitrate (aka. ABR) is a technique that tries to prevent buffering; see https://en.wikipedia.org/wiki/Adaptive_bitrate_streaming (or Google for the expression) - when the player notices that the available bandwidth is lower than the bit rate of the video stream, it can switch to another version of the same stream that has a lower bit rate (typically achieved by higher compression and/or lower resolution - which results in less quality, but that's better than buffering)
PS #1: WebRTC and Websocket-based streaming solutions cannot use this measuring trick and must implement other solutions
PS #2: New/upcoming variants of HLS (eg. LL-HLS and LHLS) and MPEG-DASH use other HTTP technologies (like chunked-transfer or HTTP PUSH) to achieve lower latency - these typically do not work well with the mentioned measuring technique and use different techniques which I consider outside scope here.
You have to use a streaming server in order to do that. Wowza server is one of them (not free). The client and server will exchange information about the connexion and distribute chuncks of the video, depending on the network speed.
I'm planning to build a Android app that records a video feed and performs operations on each captured frame from the video. The current app structure follows:
Start recording video
Capture frame
Operate on frame
save frame to a single video file in external storage
Repeat
After recording a 45 second video, the video file in external storage would be sent over a network connection to a server. The video would be recorded at 1080p, 30 FPS.
I'm wondering if there would be a significant performance cost to streaming each frame to an external server instead of creating a video file on device for storage. I'm interested in whether or not streaming each frame would have a greater performance cost than saving each frame. If so, why is this the case? Thanks in advance!
On one hand you will have overhead in terms of data size as my expectation is that compressed video will be ~100x times less than thousands of source frames.
On the other hand building up a video from frames will have a very high CPU footprint therefore will drain the battery.
You can use Android Profiler to check which of the approaches will work faster and have minimal impact on the mobile device itself.
From mobile device perspective (saving CPU and bandwidth) the best option is saving the video stream directly from camera onto your backend server and perform processing there. However in this case you will need to carefully measure performance of your server in order to ensure that it is capable of supporting anticipated amount of mobile users simultaneously uploading video files. See Load Testing Mobile Apps Made Easy article to get the overall idea regarding mobile devices backend performance testing.
You should save it locally first, and then stream it. If the network connection fails (very likely on a mobile device going in/out of wifi/cell reception) during a stream then you'll lose all the data. If you have it saved to a temporary file first then you can upload it and check the the upload succeeded before deleting the temp file.
Using Picasso I was able to download and display my images very quickly in my Android app. Now i want to stream my videos from my S3 server and play them through my app faster than my code here:
try {
MediaController VideoController = new MediaController(VideoPlayerActivity.this);//Creates a media controller to this activity.
VideoController.setAnchorView(AdVideoView);//Adds the media controller to the video view.
Uri video = Uri.parse(VideoURL);//Creates a Uri to hold the URL of the video.
AdVideoView.setMediaController(VideoController);//Add the media controller to the video view.
AdVideoView.setVideoURI(video);//Make the video view play from the Uri.
} catch(Exception e) {
Log.e("Video Stream Error", e.getMessage());//Sets the message for the log.
e.printStackTrace();//Displays the error in the stack trace.
e.notify();
}
Is there a faster way to display videos through a GitHub or better code?
Thanks in advance!
The things that usually slow down streamed video playback are server and network related rather than client side - unless you have a very slow or very busy device it is unlikely it won't be able to play the video back at the rate it is received over the network.
Taking this and assuming you are are seeing delays in your streamed videos, there are a couple of common things to look for.
First, mp4 videos in normal format have the metadata at the end of the video file which is not good for streaming. There is a technique called quickstart, which moves the metadata to the start which you definitely want to use. More info here:
http://multimedia.cx/eggs/improving-qt-faststart/
Secondly, network connections can obviously vary and slow networks make streaming high quality video files a problem. A technique called adaptive bit rate streaming (ABR) allows the client request lower quality video 'chunks' if the network quality is bad and then change to higher quality when it improves.
ABR also helps startup time as it allows you quickly start the video stream by using a lower quality level, and hence smaller size chunk, and then increase the quality as the video progresses. You can see this effect when you start up most online video services, such as Netflix, today (July 2016).
One thing to note is that video hosting and streaming is a specialist area so it is generally easier to leverage existing streaming technologies and services rather than to build them your self. Some good places to look to get a feel for open source solutions:
https://gstreamer.freedesktop.org
http://www.videolan.org/vlc/streaming.html
Does anybody have any luck streaming a high quality video (over 1000kbps) to Android through RTSP?
We currently have low quality video streams (around 200kbps) that work wonderfully over 3G. Now we are trying to serve a high-quality stream for when the user has a faster connection. The high quality videos play smoothly in VLC, but the Android playback seems to drop frames and get blocky, even on a 4 megabit connection.
It seems like the YouTube app uses a plain HTTP download for their high quality videos. This works well and plays smoothly, but will not work for streaming live videos. Has anybody had luck streaming high quality videos to Android through RTSP?
The videos are encoded using H.264, 1500kbps, 24fps, and a 720x480 resolution. In the app, we are using a VideoView to play the videos. We are using Darwin Streaming Server, but we are open to other options if necessary.
Update 6/23/2011
Looking through Darwin some more today. So far, I am just logging the request and session information in a Darwin module.
The original Droid tries to use these settings: 3GPP-Adaptation:...size=131072;target-time=4000. Although that means it wants 4 seconds of buffer, 131Kb only holds about a second of playback at 1200kbps. I understand that 1200kbps is large, but it is necessary for a high quality video (minimal compression on 720x480).
I am trying to force the client to buffer more, but I haven't figured out how to do that yet. I'm just looking through the Darwin Streaming Server source and trying to figure out how they do things. Any Darwin experts out there?
Update 6/24/2011
As it turns out, using plain old HTTP for viewing videos on demand works well with no loss of quality. When we get to live streaming, we will have to look more into RTSP.
Well even if the network is able to transmit at that rate, you still need to decode it. What are you using for decoding? You will probably need to use a NEON accelerated video decoder so you can have a proper framerate, and a decent size buffer... the graphics processor is only as good as the bus that it is in... Also what are your encoding settings and resolution?
Edit: You are encoding those at much to high bitrate, half of that will do fine. Also you need to make sure where the issue lies. Is the mediaPlayer getting the data and failing to stream at a decent framerate, in that case you have to replace the MediaPlayer code with your own player. Is it's network issue then only solution is to lower the bitrate, 600Kbps would be just fine (or 500Kbps video, 128Kbps audio), it's 3x your 200k stream and on a screen this small, the difference is not noticeable.