On Sun, Mar 01, 2015 at 09:12:49PM +1300, Ross Finlayson wrote:
> >> Please look at H264or5VideoRTPSink, and see
> >> what happens when two calls to doGetNextFrame are separated by a
> >> pause with the second call sending buffered data without calling the
> >> source getNextFrame.
>
> FYI, I have
On Sun, Mar 01, 2015 at 09:12:49PM +1300, Ross Finlayson wrote:
> >> Please look at H264or5VideoRTPSink, and see
> >> what happens when two calls to doGetNextFrame are separated by a
> >> pause with the second call sending buffered data without calling the
> >> source getNextFrame.
>
> FYI, I have
>> Please look at H264or5VideoRTPSink, and see
>> what happens when two calls to doGetNextFrame are separated by a
>> pause with the second call sending buffered data without calling the
>> source getNextFrame.
FYI, I have just installed a new version - 2015.03.01 - of the “LIVE555
Streaming Medi
> Please look at H264or5VideoRTPSink, and see
> what happens when two calls to doGetNextFrame are separated by a
> pause with the second call sending buffered data without calling the
> source getNextFrame.
Yes, there is a problem here. The solution will probably be to implement
“doStopGettingF
On Tue, Feb 24, 2015 at 09:03:48PM +1300, Ross Finlayson wrote:
> >>> (I *do*, however, plan to fix the problem (that you noted) with
> >>> old data being sent (after resuming from a “PAUSE”) because of
> >>> it having been stored in ‘overflow data’ - once I’ve verified
> >>> this.)
> >
> > The p
>>> (I *do*, however, plan to fix the problem (that you noted) with
>>> old data being sent (after resuming from a “PAUSE”) because of
>>> it having been stored in ‘overflow data’ - once I’ve verified
>>> this.)
>
> The problem is not only with overflow data. It is a problem with any
> framer or
On Tue, Feb 24, 2015 at 08:07:15AM +0100, Gilles Chanteperdrix wrote:
> On Tue, Feb 24, 2015 at 07:37:59PM +1300, Ross Finlayson wrote:
> >
> > > On Feb 24, 2015, at 7:27 PM, Gilles Chanteperdrix
> > > wrote:
> > >
> > > On Mon, Feb 23, 2015 at 11:03:24AM +0100, Gilles Chanteperdrix wrote:
> >
On Tue, Feb 24, 2015 at 07:37:59PM +1300, Ross Finlayson wrote:
>
> > On Feb 24, 2015, at 7:27 PM, Gilles Chanteperdrix
> > wrote:
> >
> > On Mon, Feb 23, 2015 at 11:03:24AM +0100, Gilles Chanteperdrix wrote:
> >> in the following
> >> sequence of OnDemandServerMediaSubsession.cpp:
> >>
> >>
> On Feb 24, 2015, at 7:27 PM, Gilles Chanteperdrix
> wrote:
>
> On Mon, Feb 23, 2015 at 11:03:24AM +0100, Gilles Chanteperdrix wrote:
>> in the following
>> sequence of OnDemandServerMediaSubsession.cpp:
>>
>>
>> if (streamState != NULL) {
>>streamState->startPlaying(destinations,
>>
On Mon, Feb 23, 2015 at 11:03:24AM +0100, Gilles Chanteperdrix wrote:
> Another source of bad RTP timestamps (but which does not seem to
> cause any issue in live555) is when MultiFramedRTPSink starts
> sending packets immediately with (a correct presentation time or
> not) as a consequence of Stre
On Mon, Feb 23, 2015 at 09:42:04PM +1300, Ross Finlayson wrote:
> No, I don???t want to make any change that???s just going to
> ???paper over??? the real problem;
That is fine by me, but it seems to me you will have a hard time
doing that (unless using the play time as presentation time along
the
No, I don’t want to make any change that’s just going to ‘paper over’ the real
problem; the existing code is correct, and works just fine for its intended
purpose.
It’ll be better to definitively identify exactly if/when/how old data (with old
presentation times) is being transmitted when we re
Hi Ross,
I think I got to the bottom of my issues using RTSP pause with a
server using live555 issue, and I believe there might be an issue
with live555.
The source of the problem is that when resuming from a pause, a few
packets are sent with a date in the past. If you take
MultiFramedRTPSink fo
13 matches
Mail list logo
