Ross,
I've been seriously poking at my (mostly) working MPEGTS FramedSource
and OnDemandMediaSubsession derivatives for my MPEGTS RTSP server. I
posted here
(http://lists.live555.com/pipermail/live-devel/2015-June/019441.html) a
few days ago from my gmail address (sorry about that). I quickly
realized I was confusing "frame" in an MPEGTS context with a "video
frame"... once I fed `fTo` packetized MPEGTS data, the server worked as
expected - as in, wireshark captures all RTP packets without ANY LOSS
(even over 802.11).
You mentioned previously that fDurationInMicroseconds in important for
the client to request data at a correct rate. I haven't found out
exactly if this should be relative to a video frame or relative to a
MPEGTS frame (ie - some integral number of 188 byte mpegts packets). I
put some print statements in MPEG2TransportStreamFramer so that openRTSP
prints out `fDurationInMicroseconds`. This yields a pretty good range
from 1500-5000 with 3200 being the average. I've made
`fDurationInMicroSeconds` a constant 3200 for each 1316 (or less) MPEGTS
payload for my FramedSource and I observe that the client (openRTSP)
falls behind at an almost-linear rate. I've also tried 1500 and openRTSP
drops RTP packets. I think the answer to this is just knowing what
fDurationInMicroseconds is relative to.
My FramedSource does:
1) mux a single h264 NAL into some amount of 1316 byte MPEGTS packets -
the muxer always spits out 1316 until the last packet, but always spits
out a multiple of 188.
2) gettimeofday(fPresentationTime) for each 1316 (or less...) packet.
3) hardcode fDurationInMicroseconds to some constants above.
4) move/copy a single 1316 byte (or less...) packet to `fTo`
5) FramedSource::aftergetting(this)
Any advice is much appreciated!
-ac
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
