[Live-devel] Demux live MPEGTS multicast stream and feed it to RTSP server

[Thorson, Joshua C]

Thank you for the quick response and the steps for me to proceed with.

I have documented the outcome of each step below:

> Josh,
>
> I think you’re on the right track.  Try the following to be sure:
>
> > I have setup the onDemandRtspServer example with the MPEG2TransportUDPServerMediaSubsession and it is working flawlessly with VLC, ffmpeg, and the openRTSP clients.
>
> Good.  Now run “openRTSP” for a while, to receive a Transport Stream file from your input source, and rename the resulting output file “test.ts”.  Make sure that this file “test.ts” can be played OK by VLC.
>
> Then run:
>         testMPEG2TransportStreamSplitter < test.ts
>
> Check that this produces a non-empty video file (named “VIDEO-<something>”)?
>
> (Note that you could have combined the above two steps by running:
>         openRTSP -v rtsp://URL | testMPEG2TransportSplitter
>  (replace "rtsp://URL” with your URL) to get your video file, without generating an intermediate file “test.ts".)
>
> Your video file should be a H.264 video file.  To be sure, try renaming it to “test.h264”, and try playing that file with VLC.  This might not work (because of a bug in recent versions of VLC); if not, then run the following:
>         ffmpeg -i test.h264 -c copy test.mp4
> and then try playing “test.mp4” with VLC instead.
>
> If you don’t get this far, then let us know, and don’t proceed any further.  Otherwise, continue…

I ran openRTSP for a while and was able to play the resulting Transport Stream file in VLC. I then piped it into testMPEG2TransportStreamSplitter and received the split ES files. Like you mentioned, I was unable to play the .h264 file directly in VLC, but after running transmuxing it to MP4 it played fine.


> > I am now looking into how to demux the live incoming MPEGTS stream and pull out the h264 data and pack that into RTP packets and send it to clients. I have investigated the testMPEG2TrabsportStreamSplitter, however, I haven't been able to get it to work with the BasicUDPSource. Here is the flow I currently have set up:
> >
> > MPEGTS Multicast Stream -----> BasicUDPSource ----> MPEG2TransportStreamFramer -----> MPEG2TransportStreamDemux
>
> You don’t need a “MPEG2TransportStreamFramer”; that’s used only to generate presentation times for the resulting Transport Stream (188-byte) frames, but the “MPEG2TransportStreamDemux” doesn’t need those presentation times.  Instead, try:
>         MPEGTS Multicast Stream -----> BasicUDPSource ----> MPEG2TransportStreamDemux

I removed the MPEG2TransportStreamFramer and was getting the same results as with the MPEG2TransportStreamFramer; a .h264 file with about 100kb of data.

> If that doesn’t work (i.e., you end up with an empty output file), then the problem might be that the UDP source is generating chunks of Transport Stream data that’s too small for “MPEG2TransportStreamDemux” to properly handle.  Try the following instead:
>         MPEGTS Multicast Stream -----> BasicUDPSource ----> MPEG2TransportStreamAccumulator ----> MPEG2TransportStreamDemux
> (You may need to add
>         #include “MPEG2TransportStreamAccumulator.hh”
>  to the start of your code to get the definition of the “MPEG2TransportStreamAccumulator” class.)

I added in the MPEG2TransportStreamAccumulator with the default max packet size of 1456, however that seemed to produce the same as above; a .h264 file with about 100kb of data. I built liveMedia with the DEBUG_CONTENTS flag to see if anything stood out while parsing the Transport Stream and it looks like it eventually just stops parsing and the BasicUDPSource receive buffer gets filled up causing the socket read to throw an error. Maybe the buffer filled up first causing the BasicUDPSource to not notify its downstream client?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20210318/366a4fd9/attachment.htm>