> We assume there *is* some bad consequence, since the code probably wasn't
> written for no reason. Which client does this hack break?
The intention of the code is to make sure that the server's state
(specifically, its record of where in the stream it is) is accurate, so that a
subsequent RT
>> Yes. Now, the SPS and PPS NAL units are assumed to be in the input NAL unit
>> stream (and are extracted from there).
>
> Is that a safe assumption, isn't optional to include the SPS and PPS NAL
> units in the stream? or at the very least make the very infrequent?
Yes, it's uncommon for a su
If you use live555MediaServer to stream MPEG-2 in a TS to an Enseo
HD2000 STB, pause and resume works fine as long as you haven't used the
indexer to build .tsx files, or you disable trick play handling in
MPEG2TransportFileServerMediaSubsession::pauseStream():
void MPEG2TransportFileServerMe
On Wednesday, August 03, 2011 6:14:13 AM, Ross Finlayson wrote:
On Aug 2, 2011, at 6:45 PM, Matt Schuckmannn wrote:
I'm working on up grading our use of Live555 RTSP server code to the
latest version of the library, our old version was at least a couple
of years old.
Good heavens; there have
On Aug 2, 2011, at 6:45 PM, Matt Schuckmannn wrote:
> I'm working on up grading our use of Live555 RTSP server code to the latest
> version of the library, our old version was at least a couple of years old.
Good heavens; there have been *many* improvements and bug fixes since then!
> In the
