Is there any good solution of iOS AVPlayer to let user choose specified HLS video resolution / bandwidth?
So the question will be separated in to two
Get the resolution / bandwidth list in m3u8:
Specify the stream resolution and bandwidth
For 1. A workaround solution is to get indicatedBitrate of
AVPlayerItemAccessLogEvent
(Get bandwidth of stream from m3u stream)
The other possible solution is to download and parse m3u8, apart from the AVPlayer interface.
For 2. A workaround solution to change the default adaptive behavior of AVPlayer is to use preferredPeakBitRate or preferredMaximumResolution. But video quality might still get lower if network gets slower. (Change HLS bandwidth manually?)
Thank you.
Related
I'm looking for a way to reduce a java based media player network bandwidth usage. During my research I found out that quality can be traded for lower datarates on streams with the transcode options. In my case the audio source is in a samba network share (file based - only wav type), and I'm not sure if the transcode setting apply for it.
The source of my problem is that our customer's work site has only a 50Mbit connection to their datacenter, and many clients (~10) has to be able to play back these audio files simultaneously. There is no QoS i guess, and the network is used for other purposes too. Caching is not an option (it's a long story, that i can't tell).
I would be really grateful if someone can clarify it for me. Can I lower the bandwidth requirements in this scenario by lowering the quality with transcode?
I'm open for other suggestions too, if you have an idea.
We are hosting mp3 files on AWS s3. We have built a web app (in React) that will play back the mp3s. However, it sometimes becomes distorted when played in Safari on iOS. The strange thing is that this does not happen all the time.
Here is the original file (sometimes distorted): https://sayyit-prod-static-assets.s3.amazonaws.com/static/audio/Darrin+M.+McMahon.original.mp3
Here is the file sounds when distorted: https://sayyit-prod-static-assets.s3.amazonaws.com/static/audio/WhatsApp+Video+2019-09-26+at+11.06.49+AM.mp4
Now, this distortion only happens when playing it through our app. When we provide a direct link to s3 (like I did above), it works. The distortion also happens when linking directly to s3 in our app.
Here are some ideas:
The mp3 file is broken
When going directly to the S3 link, it downloads entirely, which seems to allow the mp3 file to play perfectly
Any help would be greatly appreciated.
The sample rate on this MP3 file is 16 kHz. That's very low (not abnormal for voice), but also uncharacteristically low for a 128k MP3. I suspect that there's a bug with the resampler (as the iPhone hardware is locked to 48 kHz anyway), or that you're hitting an edge case bug with the decoder.
I'd recommend that you stop using MP3 and solve a few things at once. While MP3 is of acceptable quality, it's quality for a given bitrate isn't as good as alternatives. These days, you should consider using Opus. It's supported on iOS if muxed into a CAF file, and is extremely efficient. You could drop the bitrate down to 48k for voice and still have excellent quality. And, you'll bypass whatever resampling or decoding issue you're having now all in one go.
What’s the difference between streaming and downloading a video, and how does it impact the limits my ISP imposes?
I just want to clear my idea is streaming and downloading of video consume equal bandwidth?
Streaming and downloading depends upon website or online player?
streaming:Internet browser download your video to the cache folder.
downloading:Internet browser download your video to the folder you want.
So, streaming&downloading use the same bandwidth.
I need some advice from people experienced with streaming video.
I have a task to put together a system that allows video coming from RS-170 (composite) video cameras and have them displayed on an iPad. The catch is that no wireless (no Wi-Fi, no bluetooth) is allowed. Only a wired interface.
The physical I/O options on an iPad are apparently extremely limited, but I did manage to come across a company named Redpark that makes an RS232-to-Lightning cable. So my proposed solution is to have the video feeds go into a box with software that digitizes and encodes the video, and then sends it over RS232 to the iPad using that cable. The catch here is that the maximum bandwidth on that cable is 115kbps.
My preliminary testing of this setup on a prototype system have been less than stellar so far. I set up two PCs, each with serial ports, and hooked them together with a null modem. I then set the baud rates of the ports to 115kpbs and then attempted to stream a web cam video feed over the serial connection in real-time using ffmpeg. The results weren't very encouraging, but I at least did manage to get some sort of image to show up.
I guess I need to play around with the ffmpeg encoding options some more. But I need to ask: am I wasting my time with this idea, or should what I am asking here be possible?
For SDA LQ standard ("low quality") we encode H.264 mp4 (using x264) with a 128 kbps video track. The hardware decoding on the iPad can play it. It is maximum 320x240 30 fps video. The quality depends heavily on the material. For mostly nonmoving material, it is watchable. If there is a lot of movement or lighting changes, you may not be able to make out much. You can check out some examples at the link. Video game video, but some may be comparable to your application.
Without knowing more about your requirements (resolution, framerate, type of material), it is difficult to say more. However, given the right material, it is definitely possible to do it and have it be watchable (for some definitions of watchable).
I am currently working with the MPMoviePlayerController and am analysing metrics for video playback. Specifically, analysing adaptive bitrates.
As part of testing I load a particular rendition of the video at a fixed bitrate (995kbps), however when reading from the observedBitrate property of my MPMovieAccessLogEvent, this value is much more inflated - to the tune of around 15mbps.
Is there any known reason why this bitrate being returned is considerably higher than that of the playback? I have double checked all values, and all playback, and it is definitely the observedBitrate that is inflated.
According to the documentation, this value is:
The empirical throughput across all media downloaded for the movie
player, in bits per second.
Update
I posted this question on the developer forums and have received an answer, which is still just conjecture but thought it might aid the question anyway and maybe provoke a better answer.
https://devforums.apple.com/thread/216659?tstart=0
It would be worth checking your HLS video with mediastreamvalidator
which will download and measure your segment bit rates.
There is a simple answer to this - the indicatedBitrate of a MPMovieAccessLogEvent (or AVPlayerItemAccessLogEvent for AVPlayer) is the bitrate from the current playlist, so is an average bitrate required to play the stream.
However, the observedBitrate is NOT averaged - it is the instantaneous bitrate (or download speed) which the player achieved while downloading a particular chunk of video.
Example: Playing a playlist with a 1000 Kb/s stream, in chunks of 10 seconds each. The device can achieve over 10MB/s download over WiFi, so it takes less than 1 second to download each chunk. Therefore, the player is downloading at over 10,000 Kb/s during each chunk.
I'd expect the player to return (approximately) these values:
indicatedBitrate: 1000 Kb/s
observedBitrate: 10,000 Kb/s
I'd been mystified by these large values myself, but I think this explains it.
This is just for illustration - these values are not very meaningful since we don't really know how long it takes to download a chunk, or indeed how big each chunk is. All the observedBitrate really tells you is how well the player is managing to keep up with the bitrate needed to play the stream. If the former is 10x bigger than the latter, then it is only using 10% of the available time to download each chunk. This ratio may be used as a quality-of-service indicator.
For example, if the observedBitrate is less than the indicatedBitrate then it is very likely that the player will stall due to buffering, but as long as it is greater, then all is well and the stream is likely to play smoothly.