format of MMAPI capture video

[skibol]

Hi I use MMAPI to capture the video I record it but when I write to file on SD card the file is huge. about 3 sec of video almost 2MB !! I create player like createPlayer("capture://video"); and than take control over it. Is there any possibility to compress the video in fly or set some settings to do this automaticly ??
Do u have any suggestions ??

Best regards,
Gregor.

[honest_success]

Hi I use MMAPI to capture the video I record it but when I write to file on SD card the file is huge. about 3 sec of video almost 2MB !! I create player like createPlayer("capture://video"); and than take control over it. Is there any possibility to compress the video in fly or set some settings to do this automaticly ??
Do u have any suggestions ??

Best regards,
Gregor.

YOu can do image processing but if you are using any old model then it will effect on its performance.

[skibol]

Hm could u please write more about this method ?

[honest_success]

Hm could u please write more about this method ?

You can convert image to byte array. After that you can cover it to string also. So by accessing it you can implement some encryption algoritham to make its size law then you decript it at the other side but it will increase the processing. That is the big issue.

[skibol]

Hm i understand but u know what I receive is actually byte[] i pass to recorder ByteArrayOutputStream. If i write my own ByteArrayOutputStream i can get in fly data read from camera. So data arean't divided into Images. I don't know which part of data is single fram or am I mistaken ?

Thanks for your reply.
Gregor

[skibol]

So i checked I capture the video Manager.createPlayer("capture://video?encoding=video/3gpp"); and save to sd card. the sie of the file is 2MB of 7 sec film. When I use recorder as a telephone application 7 sec video has less than 50kB. My telephone supports 3gpp encoding. So it looks like it doesn't work for MMAPI ?? I don't understand. Please help understand it.

Best regards Gregor.

[skibol]

Oki I solved this problem, Manager.createPlayer("capture://video?encoding=video/3gpp"); so I forced recorde to use 3gpp encoding.

[skjolber]

Which device are you using, and are you able to receieve the movie byte[] data continously during the recording using a custom OutputStream?

Best regards, Thomas

[skibol]

Hi yes I receive byte [] data in my custom OutputStream and use Nokia 3110.

[skjolber]

Thanks! And do you receieve all the bytes when the recoding ends or do you get multiple byte[] writes during record, and if so, how often does the recorder flush to stream?

[skibol]

Sorry I now know that I can not take data from video recorder in fly it writes into byte[] after stop recording. Is there any other possibilty to get data during recording of course instead of taking snapshot ?

[skjolber]

Thanks for your reply!

I am waiting for someone to release a phone which flushes the data during record in JME. I guess the data must be flushed to disk somewhere, but as far as I know, it is out of reach.

Does anyone know any phones this is possible (so that live streaming of video actually works)? It can be done in Symbian, at least..

[encodedbytes]

I am doing live streaming audio/video by following trick.
Keep a Listener with player, which at RECORD_STOP event, commits the output stream, and restarts recording. This will be 1 3gp chunk. Keep on doing this so that your stream will become series of chunks.
On reading side, you have to again break it into parts before playing.

Reason why Implementation does not commit continuously is, it has to write a header which contains size of next video "mdat" and "moov" boxes, which is doesnot know in advance. It commits when 1) Record size reached. 2) EndOfMedia 3) Buffer is full.

[skibol]

I agree with you that is some kind of solution, but the problem is when u join film to amount of chunks there is a delay between all chunks. U stop recording for a moment so when u play film on server side there will be some holes during playing ?
Second problem - is it really real video stream if the chunk is really big time needed for capture this short chunk of media even single frame, than send so for sure it is visible that between camera and displaying picture is delay am I right ??

Best regards,
skibol.

[encodedbytes]

There will be a short jerk(about half second) rather than delay between each chunk, since the player gets restarted.

AFAI understood your 2nd question: Time needed to capture chunk depends on recordLength. It does not matter anyway since you can parallelly send old chunk data while recording.