I am doing a mpeg4 stream project on embedded Linux system, the
MPEG4 data come from a circular buffer or ping-pong buffer in my
embedded device, It seems I can start from
testOnDemandRTSCServer.cpp, but my problem is how I can make the
memory buffer as a file in Linux system
The easiest way
>Using strace (it's difficult to debug liveMedia with a debugger when
>it's running and sending packets), I found that the library seems to
>block for several seconds on a select(), waiting for three fd,
>corresponding to sockets and then timeout on the select.
This is all a Red Herring. Our base
Hi all,
I am doing a mpeg4 stream project on embedded Linux system, the MPEG4
data come from a circular buffer or ping-pong buffer in my embedded
device, It seems I can start from testOnDemandRTSCServer.cpp, but my
problem is how I can make the memory buffer as a file in Linux system or
do I need
> > I suggest that you first get your server to stream from a file
>> (containing pre-encoded H.263 video data). Only once you have that
>> working properly, should you move to the more difficult step of
>> streaming from a live encoder.
>
>Did it right now: server sends the prerecorded H263 r
I developed a testing application using LiveMedia to multicast a
live Audio and Video feed. Video is compressed to an Mpeg elementary
stream and Audio is PCM 2 channels 16 bits sampled at 48000 Hz. I am
using VLC and SMPlayer as a client that receive the streams. When
audio or video is streamed
Using strace (it's difficult to debug liveMedia with a debugger when
it's running and sending packets), I found that the library seems to
block for several seconds on a select(), waiting for three fd,
corresponding to sockets and then timeout on the select.
(opens the sockets)
17718 socket(PF_I
Hello,
I developed a testing application using LiveMedia to multicast a live Audio
and Video feed. Video is compressed to an Mpeg elementary stream and Audio
is PCM 2 channels 16 bits sampled at 48000 Hz. I am using VLC and SMPlayer
as a client that receive the streams. When audio or video is s
>he good news is that because you set "reuseFirstSource" to True,
>this 'close+reopen' will happen only once, regardless of the number
>of ciients that you have. However, it's unavoidable (and not a bug),
>so you're going to have to find a way to live with it.
Ok.
> I suggest that you first g
Cristiano Belloni skrev:
I realize H263plusVideoFileServerMediaSubsession is meant to send H263+
streams, which it does, but I thought H263+ was backwards compatible
with H263.
I'm sorry i cannot answer your full mail, but the H263 and H263+
uses different
format when it is sent over RTP
N
>As I explained in the previous emails, I'm trying to set up an rtsp
>server that streams h263 video, taken from a process that writes the
>stream on a unix named pipe.
I suggest that you first get your server to stream from a file
(containing pre-encoded H.263 video data). Only once you have th
Cristiano Belloni skrev:
I realize H263plusVideoFileServerMediaSubsession is meant to send H263+
streams, which it does, but I thought H263+ was backwards compatible
with H263.
I'm sorry i cannot answer your full mail, but the H263 and H263+ uses
different
format when it is sent over R
Greetings to all,
As I explained in the previous emails, I'm trying to set up an rtsp
server that streams h263 video, taken from a process that writes the
stream on a unix named pipe.
The "encoder" process sets up ffmpeg libraries, takes video frames from
an analog camera and encodes them in h
Hi!
I think we had similar problem but on the receiving side of the software. We
had a goal to create Java application to receive and display several MJPEG
streams from Live server. The available Java soft was unable to receive Live
stream, so we decided to link modified Live openRTSP code to Ja
13 matches
Mail list logo
