Re: [android-developers] MediaRecorder - buffered encoding of video
Thanks for the answer. I also think I don't get your point :D I try to explain my understand of your point with a little graphic. Timeline: sec 0---1--2--3-4--5-6- Sender: StartRecord0(); StopRecord0();StartSend0();StartRecord1(); FinishSend0();StopRecord1();StartSend1();StartRecord2(); FinishSend1();StopRecord2();StartSend2();StartRecord3(); Receiver:StartReceive0(); FinishReceive0();StartPlay0();StartReceive1(); StopPlay0():FinishReceive1(); StartPlay1();StartReceive2(); In my opinion that's the way you mean. But as you see, the recorded video from second 0 to 2 will be played on the receiver side from second 4 to 6. Maybe it can be optimized to play the received video-stream directly after the StartReceive, but so the video is played from second 2 to 4. That means there is a delay of at least 2 seconds. Am I right? On Saturday, March 17, 2012 8:20:18 AM UTC+1, Daniel Drozdzewski wrote: On Friday, 16 March 2012, paul paulelsne...@googlemail.com wrote: Thank you for than answer, but that isn't a solution for the problem. Doing it that way, leads to a delay depending on the recording time to that file. Also there would be an interruption of the video stream. I don't think you got the idea... Recording would be happening to fileB while previously recorded fileA would be sent through the socket at the same time. The only interuption in the video stream would be due to stopping of the recording, passing the recorded file to the sender, reseting of the recorder and setting it up with the new file. All that should take under a second. HTH I want to use the captured and encoded video for videoconferencing, so any kind of delay is not acceptable. ..do you mean storing it in the buffer and creating a delay/jitter? It seem to me that the video encoder works in that way. I don't want a delay. Am Freitag, 16. März 2012 17:54:29 UTC+1 schrieb Daniel Drozdzewski: On 16 March 2012 15:22, paul paulelsne...@googlemail.com wrote: Then it would write out the data when the stop function is called. ..do you mean storing it in the buffer and creating a delay/jitter? You will have to look at double buffering using 2 files ... while one is being recorded to, the other will be sent through the socket. Once writing is finished, you stop the recorder, point it at new file and restart it, while taking just finished file and sending it. Sent files can be discarded or left for the sake of having a local copy. -- Daniel Drozdzewski -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Daniel Drozdzewski -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] MediaRecorder - buffered encoding of video
Paul, Yes, you got it spot on (and well done for your ASCII art skills). Now as you can imagine, the video will be transmitted in chunks. The size of the all chunks will more-less depend on the size of the initial chunk. So in your timeline the delay on the receiver side is really 4 chunks not 4 seconds. What if your first chunk was 0.5s long? Then the delay is going to be 4 x 0.5s (not counting transmission delays). What if you could get away with chunks 0.25sec long? 1 to 2 sec delay is not bad I think. You will struggle to lower it any further, as you are talking about establishing of the connection (could be done before the transmission) , buffering and shifting that buffer to the receiver. Network latency is quite big in mobile data networks. Poor connection (and the data rate dropping down to GPRS rates) will affect this too. However this solution is adaptive and better bandwidth will make the double buffering perform the swaps quicker (which I think is a very nice feature). Now to achieve the first chunk to have 0.5s or 0.25s, have a look at MediaRecorder.setMaxDuration() and MediaRecorder.OnInfoListener. You will have to set it only for the first chunk... but possibly there is more logic that could be done around it to optimise the whole thing. Daniel On 19 March 2012 09:52, paul paulelsne...@googlemail.com wrote: Thanks for the answer. I also think I don't get your point :D I try to explain my understand of your point with a little graphic. Timeline: sec 0---1--2--3-4--5-6- Sender: StartRecord0(); StopRecord0();StartSend0();StartRecord1(); FinishSend0();StopRecord1();StartSend1();StartRecord2(); FinishSend1();StopRecord2();StartSend2();StartRecord3(); Receiver: StartReceive0(); FinishReceive0();StartPlay0();StartReceive1(); StopPlay0():FinishReceive1(); StartPlay1();StartReceive2(); In my opinion that's the way you mean. But as you see, the recorded video from second 0 to 2 will be played on the receiver side from second 4 to 6. Maybe it can be optimized to play the received video-stream directly after the StartReceive, but so the video is played from second 2 to 4. That means there is a delay of at least 2 seconds. Am I right? On Saturday, March 17, 2012 8:20:18 AM UTC+1, Daniel Drozdzewski wrote: On Friday, 16 March 2012, paul paulelsne...@googlemail.com wrote: Thank you for than answer, but that isn't a solution for the problem. Doing it that way, leads to a delay depending on the recording time to that file. Also there would be an interruption of the video stream. I don't think you got the idea... Recording would be happening to fileB while previously recorded fileA would be sent through the socket at the same time. The only interuption in the video stream would be due to stopping of the recording, passing the recorded file to the sender, reseting of the recorder and setting it up with the new file. All that should take under a second. HTH I want to use the captured and encoded video for videoconferencing, so any kind of delay is not acceptable. ..do you mean storing it in the buffer and creating a delay/jitter? It seem to me that the video encoder works in that way. I don't want a delay. Am Freitag, 16. März 2012 17:54:29 UTC+1 schrieb Daniel Drozdzewski: On 16 March 2012 15:22, paul paulelsne...@googlemail.com wrote: Then it would write out the data when the stop function is called. ..do you mean storing it in the buffer and creating a delay/jitter? You will have to look at double buffering using 2 files ... while one is being recorded to, the other will be sent through the socket. Once writing is finished, you stop the recorder, point it at new file and restart it, while taking just finished file and sending it. Sent files can be discarded or left for the sake of having a local copy. -- Daniel Drozdzewski -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Daniel Drozdzewski -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Daniel Drozdzewski -- You received this
Re: [android-developers] MediaRecorder - buffered encoding of video
Ok, I agree with you that this would be a working solution, but it is a very hacky one. There are some points in that solution that are not acceptable for the usage in a video-conferencing system: 1. delay: more than 1 sec is too much. Think of a phone call, if you have to wait 4sec to get an reaction from your callee. That would not work. 2. gaps: when I stop, reset, reconfigure and start the MediaRecoder again, there is a gap of at least 1 sec. Result: 1sec video = 1sec still-image = and so on 3. low compression rate: video coding means, reduce temporal redundancies between the images and transmit only the changes. At the beginning of a sequence (in our case every second), all the image is changed and I have to generate a key-frame (large amount of data) 4. low quality: because of 3. I must reduce the video quality to fit the available data rate from my connection As a result, it would be better to use JPEG or other still image compression methods. So I get a constant low frame rate and not a jerky one. Or use a software h264 encoder like ffmpeg. I'm very disappointed with that conclusion. There is a hardware h.264 encoder at my device an it is useless. On Monday, March 19, 2012 11:16:25 AM UTC+1, Daniel Drozdzewski wrote: Paul, Yes, you got it spot on (and well done for your ASCII art skills). Now as you can imagine, the video will be transmitted in chunks. The size of the all chunks will more-less depend on the size of the initial chunk. So in your timeline the delay on the receiver side is really 4 chunks not 4 seconds. What if your first chunk was 0.5s long? Then the delay is going to be 4 x 0.5s (not counting transmission delays). What if you could get away with chunks 0.25sec long? 1 to 2 sec delay is not bad I think. You will struggle to lower it any further, as you are talking about establishing of the connection (could be done before the transmission) , buffering and shifting that buffer to the receiver. Network latency is quite big in mobile data networks. Poor connection (and the data rate dropping down to GPRS rates) will affect this too. However this solution is adaptive and better bandwidth will make the double buffering perform the swaps quicker (which I think is a very nice feature). Now to achieve the first chunk to have 0.5s or 0.25s, have a look at MediaRecorder.setMaxDuration() and MediaRecorder.OnInfoListener. You will have to set it only for the first chunk... but possibly there is more logic that could be done around it to optimise the whole thing. Daniel On 19 March 2012 09:52, paul paulelsne...@googlemail.com wrote: Thanks for the answer. I also think I don't get your point :D I try to explain my understand of your point with a little graphic. Timeline: sec 0---1--2--3-4--5-6- Sender: StartRecord0(); StopRecord0();StartSend0();StartRecord1(); FinishSend0();StopRecord1();StartSend1();StartRecord2(); FinishSend1();StopRecord2();StartSend2();StartRecord3(); Receiver:StartReceive0(); FinishReceive0();StartPlay0();StartReceive1(); StopPlay0():FinishReceive1(); StartPlay1();StartReceive2(); In my opinion that's the way you mean. But as you see, the recorded video from second 0 to 2 will be played on the receiver side from second 4 to 6. Maybe it can be optimized to play the received video-stream directly after the StartReceive, but so the video is played from second 2 to 4. That means there is a delay of at least 2 seconds. Am I right? On Saturday, March 17, 2012 8:20:18 AM UTC+1, Daniel Drozdzewski wrote: On Friday, 16 March 2012, paul paulelsne...@googlemail.com wrote: Thank you for than answer, but that isn't a solution for the problem. Doing it that way, leads to a delay depending on the recording time to that file. Also there would be an interruption of the video stream. I don't think you got the idea... Recording would be happening to fileB while previously recorded fileA would be sent through the socket at the same time. The only interuption in the video stream would be due to stopping of the recording, passing the recorded file to the sender, reseting of the recorder and setting it up with the new file. All that should take under a second. HTH I want to use the captured and encoded video for videoconferencing, so any kind of delay is not acceptable. ..do you mean storing it in the buffer and creating a delay/jitter? It seem to me that the video encoder works in that way. I don't want a delay. Am Freitag, 16. März 2012 17:54:29 UTC+1 schrieb Daniel Drozdzewski: On 16 March 2012 15:22, paul paulelsne...@googlemail.com wrote:
Re: [android-developers] MediaRecorder - buffered encoding of video
On Friday, 16 March 2012, paul paulelsne...@googlemail.com wrote: Thank you for than answer, but that isn't a solution for the problem. Doing it that way, leads to a delay depending on the recording time to that file. Also there would be an interruption of the video stream. I don't think you got the idea... Recording would be happening to fileB while previously recorded fileA would be sent through the socket at the same time. The only interuption in the video stream would be due to stopping of the recording, passing the recorded file to the sender, reseting of the recorder and setting it up with the new file. All that should take under a second. HTH I want to use the captured and encoded video for videoconferencing, so any kind of delay is not acceptable. ..do you mean storing it in the buffer and creating a delay/jitter? It seem to me that the video encoder works in that way. I don't want a delay. Am Freitag, 16. März 2012 17:54:29 UTC+1 schrieb Daniel Drozdzewski: On 16 March 2012 15:22, paul paulelsne...@googlemail.com wrote: Then it would write out the data when the stop function is called. ..do you mean storing it in the buffer and creating a delay/jitter? You will have to look at double buffering using 2 files ... while one is being recorded to, the other will be sent through the socket. Once writing is finished, you stop the recorder, point it at new file and restart it, while taking just finished file and sending it. Sent files can be discarded or left for the sake of having a local copy. -- Daniel Drozdzewski -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Daniel Drozdzewski -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] MediaRecorder - buffered encoding of video
Hi. I try to capture video from the camera, encoding it with the MediaRecorder and write the output to a LocalSocket. All works fine, but the encoder seems to write the data into an internal buffer. The data only gets written to the socket when the buffer is full or the encoding process is stopped. Depending on the set up data-rate, the delay between start recording an begin writing to the socket is up to 20sec. This delay is not acceptable, because I try to develop a live stream application. Does any body know a way to avoid this buffering? Is that issue known? Maybe it depends on my device? Atrix with Tegra2 = hardware encoder I hope to hear from you soon. Regards, Paul -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
