I'm having a similar (or related) issue.
I'm not using 'live555ProxyServer', since it does not fit my needs. I have
implemented my own proxy, and am seeing breaks in the video as well.
The breaks disappear when I substitute the 'input' to be a file, instead of
an RTP network stream (I have an inter
Ok, 10x Ross.
My initial implementation was a little simpler:
MPEG1or2VideoRTPSource -->
MPEG2TransportStreamFromESSource -->
SimpleRTPSink
This produced valid TS video, but some of the frames were sent a
little late (causing "frame may be too late to be displayed (0.0)"
This looks correct. Note that - as I noted earlier - it's the
"MPEG2TransportStreamFramer" that computes the 'presentation times' of the
outgoing packets. It does this by inspecting the PCR timestamps in the
Transport Stream packets that are fed to it.
Ok, I got that.
Assuming that the input Tr
That's strange. The "MPEG2TransportStreamFramer" class should be scanning
the "PTS" (timestamps) in the incoming MPEG Transport Stream packets, and
using this to compute an estimated 'duration' for each. So I don't know
why this is not working for you.
I think I figured the cause - many of the i
I've written some code using the live555 library that receives an RTP MPEG2
stream, converts it to TS and transmits it using RTP to another address.
The incoming RTP stream is a live feed coming from a camera.
In order not to be vulnerable to networking delays, I've implemented a
FramedFilter that
