I am developing an iOS app that synchronises with GoPro cameras.
One of the feature requires downloading MP4 from the GoPro (potentially huge).
I basically have a url like: http://10.9.9.5/whatever/video.mp4.
However, I only need parts of the video, let's say between 1:00 and 1:05.
I am thinking on downloading just parts of the MP4, using HTTP "Range" header. I believe that it's possible and I will get a bunch of bytes.
However, is it a valid file? Will I be able to create a MP4 ? Do I need the MP4 header with meta information? Do any of you faced this kind of challenge?
I am using Objective C but I believe that this is a general question.
The MP4 file is a container for video that is structured around something called boxes. Probably you'll have h.264 video in that MP4 file, knowing that, you'll need to know the structure of the file you are trying to chunk.
Depending on the way it is encoded you'll have to look for a box with metadata that'll allow you to search for the correct part of the file either at the beginning or at the end, but you'll have to reconstruct a valid MP4 with the data you get from the original file.
You can see a reference of the file format here http://xhelmboyx.tripod.com/formats/mp4-layout.txt.
Related
I'm writing a fairly involved application for working with Sony cameras.
I can list the contents of the camera and copy image files no problem at all, but I can't seem to figure out the size of the files before I start to download them.
I'm receiving the file list using the standard getContentList API, and finding the files using the originals array in the response. That response seems to have no file size information in it.
Is this possible? Knowing the file size before downloading is important for a good user experience, and all the other camera APIs support it.
I do get the size when I start to download in the HTTP Content-Length header, but performing HEAD requests to hundreds of URLs in a row seems very inefficient!
Unfortunately the API does not support getting the file size.
What is required to use SMIL file to utilize adaptive streaming in a videojs player. I have created the SMIL file in my wowza application and it is creating my 4 separate streams and making them available. However I cannot get my webpage, that uses videojs, to correctly play the SMIL file. Hints on that coding or where to go to find the correct documentation would be greatly appreciated.
There aren't many implementations of SMIL players. I'm sure I've seen wowza URLs that suggest it will output the SMIL as other formats, something like whatever.smil/manifest.m3u8. That's HLS which could be played on mobile and Safari natively and with videojs-contrib-hls elsewhere.
I know the question is old, but I've been struggling with this recently, so I want to share my experience in case anyone is interested. My scenario is very similar: want to deliver adaptive bitrate streaming from Wowza to clients using videojs.
There is a master link that explains how to setup and run Wowza Transcoder for live streaming, and how to set up your Adaptive Bitrate Streams using an SMIL file. Following the video in there you can achieve to have a stream that uses ABS, but the SMIL file is attached to the stream name, so it is not a solution if you have streams that come to Wowza from another Media Server origin and that need to be transcoded before being served to the clients. In the article there are a few key things mentioned (like the Stream Name Groups), but somehow things doesn't seem pretty clear, at least to me. So here is some clarification from what I understood from all articles I read and what I did to achieve ABS:
You can achieve ABS in Wowza either with SMIL files or with Stream Name Groups (NGRP). NGRP refres to a block of streams that is defined in the Transcoder template that can be played back using multi-bitrate streaming (dynamically) (<- this is what I used). And SMIL files are used to create a "static" list of streams for multi-bitrate VOD streaming. If you are using Wowza Origin-Edge Delivery you'll need the .smil file, because NGRP do not get forwarded to the edge. (Source for all this information: here).
In case you need the SMIL file, you probably need to generate a new one for every stream, and probably you want to do that in an automated way, so best way would be through an HTTP request (in the link above it is explained how to achieve this).
In case you can live with NGRP, things are a bit easier:
You need to enable Wowza Transcoder (this is pretty easy and steps are in the video I mention above).
You should create your own Transcoder Template with the different stream presets you want to deliver, as an example you can check the default ones that are already there. The more presets you add, the more work Wowza will need to do whenever a stream comes, since it will need to generate a new stream for every preset that you have defined.
Now is when we generate the NGRPs. In your Transcoder Template, you can generate as many NGRPs as you want (to clarify: these are like groups of streams, that you will be able to set in your clients video player. Each NGRP contains the streams that the video will be able to use when doing the adaptive bitrate streaming). For instance, these are the default NGRPs:
If you play the ngrp "_mobile" in the clients video player, the ABS algorithm in the player will be able to adapt itself to play either the 240p or the 160p streams based on the client capabilities.
So imagine you have these two NGRP. In order to play them in videoJS, you will need to set the source to:
http://[wowza-ip-address]:1935/<name-of-your-application>/ngrp:myStream_all/playlist.m3u8
or
http://[wowza-ip-address]:1935/<name-of-your-application>/ngrp:myStream_mobile/playlist.m3u8
... based on how many options you want to provide to the client player to use for the ABS. (For instance: if your targets are old mobile devices, you probably just want to offer a couple of low bitrate streams).
(This would be in case you're delivering an HLS stream. If other format, the extension would change, for instance if you are delivering a DASH stream you would have "/manifest.mpd" instead of "playlist.m3u8").
That is all, there is also a very helpful link in video.js documentation explaining how it does the bitrate switching: here.
I hope it helps someone! At least clarifying things! :)
Since i cant play an audio file from a DB blob, i have to write it as a file, before i can play it.
Looking at the documentation, my choices are:
Ti.Filesystem.applicationDataDirectory
Ti.Filesystem.tempDirectory
Ti.Filesystem.externalStorageDirectory
Ti.Filesystem.applicationCacheDirectory
Considering that i want my file to be secret, so no other app can see that file, what is my best option?
EDIT: So the issue is more with Android, i'm afraid that any file browser will be able to find the file.
I'm assuming you're building for android, because ios data are sandboxed and not readily accessible by default (until ios8). Rather than hiding them, just encode them using base64encode(). And then you can decode when accessing the file with base64decode().
With that said, I've never had to use it. So, I don't have an example. But you can read about it in the api doc.
Hope that helps.
You haven't mentioned if you are building an app for iOS or Android. For example Ti.Filesystem.externalStorageDirectory is available only for Android (SD card).
Anyway if you want to save an audio file, you should save it in <Application_Home>/Documents ,so you should use Ti.Filesystem.applicationDataDirectory. Don't forgot to set up a remoteBackup flag see http://docs.appcelerator.com/titanium/3.0/#!/api/Titanium.Filesystem.File-property-remoteBackup
Also have a look at iOS Data Storage Guidelines for more details
https://developer.apple.com/icloud/documentation/data-storage/index.html
*If you want to save an audio file only because you need to play it ,but you don't need to store it in a fileSystem then is better to use Ti.Filesystem.tempDirectory
Looking first for links to good documentation that correctly explains pseudostreaming, byte range requests and mp4 fragmenting. Note, I will be using only the mp4 container (h264 codec) and HTML5 video (no flash).
My understanding of pseudostreaming is that the client can send off a start parameter that the server "seeks" to in it's response. MOOV data must be upfront and it implicitly implies that buffering of the original source stops in favor of the new response starting at the "start"/seek position. How is the client forced to make pseudo calls? Does the MP4 have to formatted in a special way?
Byte range requests are different send rather than just a start parameter a range is sent. Sounds more like progressive downloading. How would "seeking" work? Does it with byte range? Can the segment size be pre-determined with movie box information?
How does MP4 fragmentation fit in? Looking like a construct originally designed by microsoft for silverlight. But is it applicable to other browser html5 video implementations?
Finding it difficult to sort out information on the web. Looking to both live feed and take historical segments of h264 files produced from rtp camera streams. Got a bunch of files time-ordered in a MongoDB. Created my own h264 decoder in JavaScript and can construct mpeg-dash boxes on the fly off a range query. Using Chrome's support for MSE to append segments. Works great but not a universal solution. Want to fall back on other techniques other than flash but with the html5 video.
I want to develop small mac (not iphone) application for self-educational purpose.
What application should do: just open video file and show information about video codec.
Main problem is that i never work with media files and i don`t now from which point i can start.
May be somebody can advice some articles or may be even examples?
I strongly recommend using something like FFmpeg to get codec information.
Simply run the following command through NSTask:
ffmpeg -i video.mpg
Project page:
http://www.ffmpeg.org/
Extracting this information yourself is a LOT of work.
Every video format stores things different.
Not to mention error-handling and corrupted files.
The codec data is usually held in container formats. To start you should pick one container format and parse that, a popular one would be the MPEG4 container format. Follow the links from this page to get you started.
http://en.wikipedia.org/wiki/MPEG-4_Part_14