Dear Ross, all,
did somebody wrote the StreamDuplication class you proposed below already?
Do you have a hint how the getNextFrame functions could be synchronized?
Thank you very much,
Bernhard
- Original Message -
From: "Ross Finlayson" <[EMAIL PROTECTED]>
To: "LIVE555 Streaming
I have re-written my framer based off the H263plusVideoFramer instead of
trying to subclass the MPEGVideoStreamParser. Now I can see that my
framer is parsing through the NAL units and that the H264RTPSink is
actually sending some packets out. The problem is that the file is
getting parsed too q
thanks Jerry!
that's some great info that will probably come in handy once I get my
framer all ironed out!
On Tue, 2008-06-24 at 13:06 -0700, Jerry Johns wrote:
> Since there seems to be quite a few ppl writing H.264 frame
> subclasses, I think i'll give a gist of what I learned when i was
> crea
Update: getting closer!!!
I have re-written my framer based off the H263plusVideoFramer instead of
trying to subclass the MPEGVideoStreamParser. Now I can see that my
framer is parsing through the NAL units and that the H264RTPSink is
actually sending some packets out. The problem is that the fi
This is incorrect. The information in incoming RTCP "SR" packets is
used to generate presentation times from incoming RTP packets'
timestamps. These presentation times - like the RTP timestamps
themselves - are (necessarily) based on the sender's clock (because
that was the only clock availab
After looking at this again, I retract my earlier statement. There
was, indeed, a bug in our RTSP client implementation of
"GET_PARAMETER" (and "SET_PARAMETER"). Thanks for noticing this.
A new version (2008.06.25) of the "LIVE555 Streaming Media" code -
fixing ths bug - has now been install
Thanks a lot for your suggestion. Can you suggest me about the RTP
payload header parse code for RFC 2250 in RTP source?
If you use RTSP - which you should - then you don't have to worry
about this. The RTP payload format code will be in the stream's SDP
descripition, which the RTSP client w
> This is incorrect. The information in incoming RTCP "SR" packets is used
> to generate presentation times from incoming RTP packets' timestamps. These
> presentation times - like the RTP timestamps themselves - are (necessarily)
> based on the sender's clock (because that was the only clock ava
Hi Ross,
Thanks a lot for your suggestion. Can you suggest me about the RTP
payload header parse code for RFC 2250 in RTP source?
Thanks in advance,
Jayakara N
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ross Finlayson
Sent: Wednesday, June 25, 2008
I have two network interfaces (I1 and I2)which will be both used, if you use
INADDR_ANY. So I decided to bind my socket connections to interface I1. I
overwrote the the two variables "ReceivingInterfaceAddr" and
"SendingInterfaceAddr" (e.g ReceivingInterfaceAddr = I1) in order to receive
rtp pa
I am working on a client application that receive the MPEG-TS stream
from the VLC server. I am able to receive the data from the server using
testMPEG1or2VideoReceiver test application.
Wrong. That application is for receiving MPEG-1 or 2 *Elementary
Stream* video, not MPEG Transport Streams.
Dear All,
I am working on a client application that receive the MPEG-TS stream
from the VLC server. I am able to receive the data from the server using
testMPEG1or2VideoReceiver test application. After that I need to parse
the RTP payload data according RFC 2250 (MPEG-TS over RTP). What API do
I
12 matches
Mail list logo
