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.
Related
I am trying to play multiple videos together in synchronisation (they are all the same length) on iOS. To make this efficient over internet I have transcoded these videos to HLS, however when I try and synchronise them using AVPlayer it turns out that I cannot control the source clock they use (this only works on local files) and I cannot control the rate (so I can't do minor corrections to bring these videos in sync).
To solve this I have currently downloaded the flat mpg files and then play them in sync using the source clock, however this is very bandwidth intensive. Does anyone know some ways I can achieve better network efficiency while managing to keep these files in sync?
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.
I'm using a Raspberry Pi 2 to route wifi-eth connections. So from the eth side I have a computer that will connect to internet using the Pi wifi connection. On the Raspberry I started htop to monitor the CPUs load, then on the computer I started chrome and played a 20-minute 1080 video. The load on the CPU didn't seem to go beyond 5% anyhow. After that I closed youtube tab and started a download of a binary file of 5GB from the first row here (https://testdebit.info/). Well, I noticed that CPU load was much more higher, around 10%!
Any explanation of such a difference?
It has to do with compression and how video is encoded. A normal file can be compressed, but nothing like that of a video stream.
A video stream can achieve very high compressions due to the predictable characteristics of video, e.g. video from one frame to another doesn't change much. As such, video will send a whole frame (I-frame) and then update it with just the changes (P-frame). It's even possible to do backward prediction (B-frame). Here's a wikipedia reference.
Yes, I hear your next unspoken question: Doesn't more compression mean more CPU time to uncompress? That's true for a lot of types of compression, such as that used by zip files. But since raw video is not very information dense over time, you have compression techniques that in essence reduce the amount of data you send with very little CPU usage.
I hope this helps.
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 would like to know if it's still necessary to throttle the bandwidth when transferring multiples large files (PDF) over the cellular network.
There is no information about this in the guidelines but some old threads points out this was necessary.
http://forums.macrumors.com/archive/index.php/t-1130677.html
iPhone app rejected for "transferring excessive volumes of data"
Thanks in advance.
I believe this only applies for streaming like mp3 data.
If you have a large single file which you need to download, throttling the bandwidth is an especially bad idea. The opposite would be recommend: download as fast as possible in order to safe battery and increase reliability of the connection (the shorter the duration the less the probability that it gets interrupted).
You should however check whether the connection uses the cellular network and notify the User and ask whether your app should defer the download when Wifi is available, possibly automatically in the background without starting the app. This approach is feasible (utilizing NSURLSession).