<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
> > I removed the MPEG2TransportStreamFramer and was getting the same results as with the MPEG2TransportStreamFramer; a .h264 file with about 100kb of data.
<div>> </div>
<div>> I assume that this is bad - i.e., you expected to see more data than this.</div>
<div><br>
</div>
<div>Correct, its a live feed so I epxect the video data to be consistently written to the file.</div>
<div><br>
</div>
<div>> If you haven’t done so already, then - as a sanity check - try doing</div>
<div>> MPEGTS Multicast Stream -----> BasicUDPSource ----> FileSink</div>
<div>> i.e., without any demultiplexing of the Transport Stream, to see if you then get all of the data that you expect.</div>
<div><br>
</div>
<div>I tried this and everything worked as expected - I was able to play the resulting TS file.
</div>
<div><br>
</div>
<div>> > 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.</div>
<div>> </div>
<div>> Try again with a larger “maxPacketSize” parameter in the call to "MPEG2TransportStreamAccumulator::createNew()” - e.g., 10000.</div>
<div><br>
</div>
<div>Tried it with a larger packet size but it was still producing the same output.
</div>
<div><br>
</div>
<div><br>
</div>
<div>> > 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?</div>
<div>> </div>
<div>> LIVE555 data chains work using the ‘pull’ model: The downstream object that requests data from the upstream object. So, in this case, the “MPEG2TransportStreamDemux” is (when it needs data) requesting data from the “MPEG2TransportStreamAccumulator”,
which in turn is requesting data from the “BasicUDPSource”.</div>
<div>></div>
<div>> The reason why I suggested adding in a “MPEG2TransportStreamAccumulator” is that I suspected that the problem might be that - in this case - the “MPEG2TransportStreamDemux” is not being fed by a byte stream. But if that’s not working for you, then I’m
not sure what to suggest, unfortunately...</div>
<div><br>
</div>
<div><br>
</div>
<div>I've done some more testing and have seen some promising results:</div>
<div><br>
</div>
<div>I used the suggested pipline:</div>
<div> MPEGTS Multicast Stream -----> BasicUDPSource ----> FileSink</div>
<div>but I have it write to stdout instead of a file. I then pipe this into testMPEG2TransportSplitter like:</div>
<div><br>
</div>
<div> basicUDPtostdout | testMPEG2TransportSplitter</div>
<div><br>
</div>
<div>This works just as I would expect it to, dumping out the live h264 video stream into its own file. So now the question is why doesn't using the BasicUDPSource as a FramedSource work with the MPEG2TransportStreamDemux. The only thing I can think of is that
it has to do with the buffer of the UDP source getting filled up.</div>
<div><br>
</div>
<div>Any ideas?</div>
<div><br>
</div>
<div><br>
</div>
<div>Thank you,</div>
<div><br>
</div>
<div>Josh</div>
<br>
</div>
</body>
</html>