Open MahatmaX opened 10 years ago
VM crash
yes I have this too
also Xuggler Video Decoder have CPU time load problem
without video ~ 6-16% with video decoder ~ 27% CPU time with video + my business logic 47% CPU
also, BufferedImages it's a good one way. Must to be. But also need get raw video stream and compress + resend as stream (example like VP9 codec - good for movement) (in my business logic)
I had a look at several other decoding frameworks:
jcodec: does not support streams jvlc: requires vlc player to be natively installed h264j: does not support streams java media framework: does not support mp4
Moreover, none of the frameworks is actively developed anymore. Probably the best solution is to optimize the Xuggler implementation to be able to decode, record and play mpeg4 as well as h264. Support for raw image data should be no problem.
Other suggestions are welcome !
Sorry, I updated my comment above. It actually meant jcodec (not jdecoder).
about CPU overload https://github.com/felixge/node-ar-drone/tree/master/lib/video have no CPU overload on the server side
I had a look on jjmpeg. It does not support streams (only files). We're stuck with Xuggler. But I cannot reproduce CPU overload. CPU load is 7% on my computer. The node-ar-drone project by the way is Javascript.
The node-ar-drone project by the way is Javascript.
I know, I mean about methodology like in node-ar-drone
The methodology - as far as I could see - is to cut out the drone's proprietary PaVE header and call ffmpeg in order to convert the rest. This project seems to rely on an installation of ffmpeg, which makes programming very easy, but puts a burden on users (as these have to install ffmpeg seperately). In this respect YADrone and node-ar-drone share a common problem, only that YADrone ships with all required libraries and does not need ffmpeg to be pre-installed.
But cutting out the PaVE header could indeed be an enhancement and ease life also for Xuggler. I once experimented with that option on the Android platform, but due to my bad implementation performance degraded quite heavily. I will push the code into the git repository, maybe someone with optimazation skills can have a look on that.
Thanks for the comment, halton ! As far as I could see, the mp4parser is no 'decoder'. It is a library for working with mp4 on a low level and not able to construct individual images out of an mp4 stream (please correct me if I am wrong). One might be able to use the library to write the drone's mp4 stream to a file, but as the stream has no defined "end of stream", I do not know if that is possible. Moreover, we would not be able to see the live video feed.
Work on the Xuggler Video decoder has been stopped. Last version is from 2012. It's time to look for a new one, which is actively developed and probably runs on Android as well (and is nevertheless PaVE header tolerant).
Current Xuggler version still does what is shall do. But recording video sometimes results in VM crash and playing video is too fast.