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
