I'm looking into streaming .wav files from a server. I'm wondering if the devices will stream/play the music without any compression applied. I need to ensure that no compression is made. Is it possible?
Im not seeing here http://developer.android.com/guide/topics/media/mediaplayer.html anything about compression, i think it doesn't compress the audio
Related
I have a service which uses azure media service v3 sdk to upload(and transform)video files. At the moment I am working with some solution for video virus scanning.
Have a question
As they are re-encoding video files to host on their streaming service does it negate the requirement to scan these files?
Thanks
Reencoding video pulls apart the source video by decoding the original audio and video 'in the clear' and then reencoding it. This would limit the attack vectors since the MP4 header would be rewritten, the video and audio are not the original, and a limited amount of metadata gets copied from the old header.
For a virus attack it is less common to hide something in an actual video file and instead just disguise the video as something executable with no video in the file. For example, a .exe file made to appear as a video would not survive the reencoding process since it is not an actual video file. This does not mitigate all risk, but it does mitigate a lot of it.
I have a content creation site I am building and im confused on audio and video.
If I have a content creators audio or video stored in s3 and then I want to display their file will the html video player or audio player stream the media or will it download it fully then play it?
I ask because what if the video or audio is significantly long. like 2 hours for example. I need to know how to solve the use case.
Lastly what file type is most acceptable for viewing on webpages? It seems like MPEG-4 is the best bet. Is that true?
Most video player clients and browsers will attempt to stream the video if they can.
For an mp4 video file hosted on a server, so long as the header is at the start and the server accepts range requests, this will mean the player downloads the video in chunks and starts playing as soon as it has enough to decide the first frames.
For more professional streaming services, they will generally use an adaptive bit rate streaming protocol like DASH or HLS (see this answer: https://stackoverflow.com/a/42365034/334402) and again the video will be streamed in chunks, or segments, and will start playing while it is streaming.
To answer your last question you need to be aware that the raw video is encoded (e.g. h.264, VP9 etc) and the video, audio, subtitle etc tracks stored in a video container (e.g. mp4, Web etc).
The most common format is probaly h.264 encoded and mp4 containers at this time.
The particular profile for h.264 can matter also depending on the device - baseline is probably the most supported profile at this time. You can find examples of media support for different devices online, e.g. for Android: https://developer.android.com/guide/topics/media/media-formats
#Mick's answer is spot on. I'll just add that mp4 (with h264 encoding) will work in just about every browser out there.
The issue with mp4 files (especially with a 2 hour long movie) isn't so much the seeking & streaming. If your creator creates a 4K video - thats what you'll deliver to everyone (even mobile phones). HLS streaming on the other hand has adaptive bitrates - where the video adapts to both the screen & the available network speeds. You'll get better playback results with less buffering (and if you're using AWS - a LOT LESS data egress) with video streaming.
(there are a bunch of APIs and services that can help you do this - including api.video (where I work), Mux and others).
I have a common use case scenario where I want to do the following
Upload an audio file. (wav/mp3)
Transcodes to 128k or 192k mp3.
Stores the audio asset.
Allows the audio asset to be streamed.
Supports streaming actions such as play pause and seek.
The documentation for azure media services seems like it might be able to support this but I am not too sure, seems like they focus on video content. Anyone have experience with this?
You can manage audio and encode audio only assets with azure media services.
WAV is supported input format/conatiner as a input asset. To see full list of supported formats check following link:
https://azure.microsoft.com/en-us/documentation/articles/media-services-media-encoder-standard-formats/
Check https://github.com/Azure/azure-content/blob/master/articles/media-services/media-services-custom-mes-presets-with-dotnet.md#audio_only to see audio only preset options which you will use to encode an audio only preset.
Approx we all know about gaana.com, and saavn.com, that website stream audio mp3 files to client side but does't allow to users to grab the audio files, actually we want to know what technology he used to stream the audio mp3 files.
is he using streaming server or or something else ?
Can you describe the technology he is using in steaming the audio files.
Actually we are also creating a web app where audio files will be streammed in client side and we also don't want to allow users to download our mp3 files like gaana.com or saavn.com.
and we are also curious about if we want to stream our audio mp3 files in three different quality the what should i do. Should we convert all the mp3 files in all the three different quality and upload to the server or is any another solution exist for this purpose.
If you want to code your own streaming server then you can use this link
https://pypi.python.org/pypi/DeeFuzzer/ it's a python based streaming server, or you can also use ffmpeg or even VLC
Am trying to create an application which will take data as raw audio wav format and output as FLAC.
Now, I need to stream the input and the output at the same time through node.
Can someone guide me on how can I work this out?
Thanks
As far as I know there is no possibility to do so "live" via the Internet. You can't do so with FLAC format. Only AAC, MP3 an WAV are supported for live-streaming.
You can download the file on the client side and then the client using his or het apps is able to play it.