On 01/22/2013 09:51 PM, Ross Finlayson wrote:
Yes, I agree. In the next version of the software, this piece of code -
in "FileSink::afterGettingFrame()" - will become:
if (fOutFid == NULL || fflush(fOutFid) == EOF) {
// The output file has closed. Handle this the same way as if
the inp
> I'm building and iOS application, where I'm using a RTSP Client (based on
> testRTSPClient) to receive a MPEG2 stream
Because you refer to "PAT" and "PMT" information, I assume you're referring to
a MPEG-2 *Transport* stream. (There are other kinds of MPEG-2 streams as well.)
> and then I'm
> Can you please provide some insight as to the frames generated by
> MPEG4GenericRTPSource so that we can have an idea of how to restream the AAC
> audio.
The frames are simply AAC audio frames, delivered one at a time.
However, to decode (or restream) these frames, you also need extra
'confi
We are building a server to transcode live JPEG video and AAC audio streams to
clients from IP cameras. We have used the testRTSPClient program as a guide to
get the JPEG and AAC audio from the cameras and copied the MediaSink buffer
into our own shared buffer in the attempt to encode the JPEG
> I have few options for this:
> 0 implies that the encoder will add the start codes
>1, 2, 4: length prefixed NAL units of size 1, 2, or 4 bytes
>
> If I set up the parameter to 0 the Discreteframer complains with the
> following message ‘H264VideoStreamDiscreteFramer er
>No, this is wrong! You should not be creating/using a "H264VideoStreamFramer"
>at all. That class should be used *only* when the input is a >byte stream
>(e.g., from a file). If - as in your case - the input is a discrete sequence
>of NAL units (i.e., one NAL unit at a time), then you shou
> I'm not sure if the assumption "if the back-end server fails, it will do so
> by closing the TCP connection" is strong enough. What i'm actually seeing is
> that sometimes the liveness is sent but no response is received, and the
> backend connection seems to be still alive because the proxy d
Hello Ross:
Once the 'back-end' connection to the proxied stream has been
established (as a result of a successful "DESCRIBE" command), the
proxy server periodically (at an interval randomly chosen between 30
and 60 seconds (usually)) sends a command to the 'back-end' server, to
test whether
Hi,
I'm building and iOS application, where I'm using a RTSP Client (based on
testRTSPClient) to receive a MPEG2 stream and then I'm trying to decode the
frames with help of FFMPEG. My question is: Is it possible to obtain the PAT
and PMT information before I pass the frames to FFMPEG with he