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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 [email protected] >> > To unsubscribe from this group, send email to >> > [email protected] >> > 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 [email protected] > To unsubscribe from this group, send email to > [email protected] > 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
