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)"
Nonetheless, I suggest that you debug your code by first doing:
MPEG1or2VideoRTPSource -->
MPEG2TransportStreamFromESSource -->
FileSink
Then, verify (by trying to play the resulting file with a media player (like
VLC)) that the resulting file is a proper Transport Strea
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
> I think I figured the cause - many of the incoming RTP frames "get" the same
> presentation time (via 'receptionStatsDB().noteIncomingPacket(...)'.
No, this is a 'wild goose chase'. The presentation times that get set for the
outgoing Transport Stream packets are determined *entirely* by the
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
> My problem is that the "Framer" reports most of the frames' duration as
> "0.0", and as a result 'uSecondsToGo' in the RTPSink is always 0, and the
> frames are sent out too fast.
That's strange. The "MPEG2TransportStreamFramer" class should be scanning the
"PTS" (timestamps) in the incoming
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
