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 <[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
