We have commissioned a project to leverage the Universal Framework library for iOS on GitHub to build a ffmpeg framework for easy integration into iOS apps.
Once released, we will place the source code and example iOS rtsp player on our github repository at:
for use on the ArduMotion WiFi R/C Toy, Rover, UAV, and Robot controller board from ezRover at:
This will be used to stream video from the Submarine and Quadcopter projects to your iPhones and iPads…
he guys,
about an ffmpegwrapper framework that bridges avfoundation and ffmpeg, you might want to take a look at this
sorry forgot the link
https://github.com/mooncatventures-group/RtspFrames-test
Hi
What happened to the commissioned project ? the github link seems to be broken.
Have looked at mooncat ventures code, to be fair it does work just about, but its not a framework, it seems to be work in progress and does some suspicious things with main entry point to app and tbh looks a bit hack, but big issue it has some performance issues. (i.e 3-4 seconds lag), where other published apps like Buzz Player also uses ffmmpeg but has a lag of under a second. A published framework might be way to go, have even asked authors of buzzplayer if they want to licence their code
Thanks
neil
The team in India was unable to deliver a solid product so we cancelled it. I wish someone could write this framework as it will be a very valuable addition to github!
rebuttal: fair it does work just about, but its not a framework
Depends what you consider a framework
true the framework is not a end user framework, its a developer’s framework, somewhat like live 555 but we think easier to use.
We chose to break it into parts.
ffmpegdecoder.framework, just a wrapper lets you use ffmpeg in your apps without the pain of building the libs.
the other frameworks are
frames – as the name implies, its a frame grabber, based on and much like iframeextractor, thats all it does.
rtspplay – this is a framework wrapped around ffplay, a great little linux video player but very hard to build on ios.
realtime is sacrified of quality, this player uses very big buffer to achieve reliable a/v sync, you can get smaller delays with smaller buffers, we have achieved this for some of our clients but we have not decided yet about making that code public.
some suspicious things
hmm… what could you be referring to, if you mean the main.h in rtspplay, we had to do quite a bit to get sdl and iOS to co-exist in an acceptable way.
The code is though, but unlike production ready players you have to do a bit of work to get optimal performance. Take a look at aVOptions on avformatContext, if your using rtsp over http you probably don’t need packet-reording so set max-delay to 0, this should reduce real-time to camera delay.