[Live-devel] Transport Streams

[Walter Van Hooff]

*Ross,*

*    Thank you very much for your response. I was able to get this to work
with UDP multicast by  changing the video sink to BasicUDPSink in the
transport stream test. VLC has no problem decoding the transport stream
now. This actually is what we are interested in anyway since our customers
use almost exclusively UDP multicast.*


*I have two questions that I would very much appreciate if you could
answer.*


*1. I have not been able to find the place in the code where the delay
between packets is determined. Clearly packets have to be sent at a rate
such that video frames are sent to prevent underflow and overflow at the
decoder. To accomplish this the code must parse the stream to find the
video frame rate, or determine the bit rate. I have not been able to find
this in the code. Of course no muxing/demuxing  done in the streamer, and
the stream is packed in "as is". But the timing of packet output must be
determined from the stream. I have not been able to find the code that
determines this timing, and how it gets the required information from the
stream. If you could point out where this is done in the code it would be
immensely helpful.*


*2. Just curious why vlc could not tell if it is a transport stream since
the rtp header "payload type" should indicate this. What am I mssing?*


*Again, your help is very much appreciated.*

*thanks,*

*gordon shank (gordon at qoesystems.com <gordon at qoesystems.com>)*



On Tue, Mar 7, 2017 at 12:45 PM, Ross Finlayson <finlayson at live555.com>
wrote:

> > I have downloaded and built your system. I tried the
> "testMPEG2TransportStreamer" test program. I have a file named "test.mpg".
> This is a file with a 10 second transport stream compressed with h.264.
> This file can be played with vlc from the file. I can also stream it to a
> rtp, udp, multicast ip stream from vlc and it works fine.
> >
> > When I run the test program mentioned above it does send rtp packets.
> However, vlc displays garbage. I have looked at the packets emitted with
> wireshark. Wireshark decodes them as transport stream packets but claims
> the video is scrambled, which of course is not the case.
> >
> > I looked at the source code. From what I can tell the event loop
> continually calls functions that simply read the file and stuffs the bytes
> in the rtp packets without regard to the video format, compression type. It
> does not appear to parse the file data to get any of this information. I
> must be missing something.
> >
> > My question is :
> >     Has this test program been tested, or am I doing something stupid?
>
> The “testMPEG2TransportStreamer” application is working properly (assuming
> that your Transport Stream file is named “test.ts”).  The RTP payload
> format for MPEG Transport Streams (as defined in RFC 2250) calls for (an
> integral number of) 188-byte Transport Stream ‘packets’ to be packed into
> each RTP packet.  When sent over RTP, Transport Stream data is not
> demultiplexed at all; it is sent ‘as is’.
>
> Your problem is that - when you are trying to play the incoming RTP stream
> using VLC - VLC is not recognizing the stream as being
> Transport-Stream-data-over-RTP, because it is not being told this.
>
> The easiest way to fix this is to use the RTSP protocol to access the
> stream.  Uncomment the line
>         #define IMPLEMENT_RTSP_SERVER 1
> in “testMPEG2TransportStreamer.cpp”, line 34, and recompile.  Then, when
> you run “testMPEG2TransportStreamer”, it will output a “rtsp://“ URL for
> the stream.  Enter this “rtsp://“ URL into VLC, and VLC should be able to
> play the stream OK.
>
>
> Note also that the “testMPEG2TransportStreamer” streams via IP multicast,
> which means that the stream will probably not go beyond a single LAN.  If,
> instead, you want to stream via IP unicast (one stream per client), then
> you can instead use the “LIVE555 Media Server”
>         http://www.live555.com/mediaServer
> or else use the “testOnDemandRTSPServer” demo application.
>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>



-- 
*Walter van Hooff*  |  President
QoE Systems, Inc.  |  www.qoesystems.com   |  650-314-0112
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20170308/e6a97f05/attachment-0001.html>