Hi all,
Yes I agree about the RTSP client applications(only a few number of
request through the prompt ) but it is possible to find an other software
how can bombard the server and run a big number of request to the server to
judge his performance ??
Thanks and regards
___
Interesting, thank you for the response. I actually discard all but 7, 8 and 5
frames that occur before the initial 'priming' is complete, they are just
logged for completeness. So my first buffer passed is of the form [7 8 5],
after which I pass all frames willy-nilly, even the timing NAL [ 6
Hi,
We use a similar set up for our software (LIVE555 -> FFMPEG decode) and it
is working well. The first obvious difference I can see is that normally
the SPS and PPS precede the IDR frame (type 5) rather than the non-IDR frame
(type 1), so we have 7, 8, 5, 1, 1, 1 ., 7, 8, 5, 1, 1, 1, .. Fo
Hello,
I apologize if this is noise - my question may well have nothing to do with
Live555, but I thought I'd post here in case anyone can help me rule it
out. It appears I'm successfully consuming H.264 via RTSP and acquiring
frames in my mediasink.
Next, I set up ffmpeg's decoder with the SPS
> In this context we are in RTSPClient.cpp around 1555 :
>
> // If we saw a "Content-Length:" header, then make sure that we have
> the amount of data that it specified:
> unsigned bodyOffset = nextLineStart - headerDataCopy;
> bodyStart = &fResponseBuffer[bodyOffset];
>
Hi Ross,
Using RTSPClient that have a task sending a periodic GET_PARAMETER, sometimes a
crash occurs with the following backtrace :
Thread 1 (Thread 24732):
#0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:31
#1 0x008291b2 in RTSPClient::handleGET_PARAMET
