[Live-devel] Sysclock sanity check causes slow-motion MPEG-2 TS playback from live555MediaServer

[Warren Young]

On 12/31/2010 3:17 AM, Ross Finlayson wrote:
>
> If you're really seeing a problem with this new version,
> then you're going to have to identify specifically what is causing it.

I thought I had.  I got it down to just one variable, the OS I ran the 
live555MediaServer binary on.  I believe I controlled for all other 
variables.  If you think I missed one, I'm open to hearing it.

"The OS" is a big variable, I'll grant, but since the binary was 
statically linked to liblivemedia, that means the only other code that 
varies are things like libc, libstdc++, and the kernel, all of which I'd 
need a lot of evidence to blame.

I think it's also significant that the problem is in the older OS, 
rather than the newer.  It wouldn't be the first time that new code was 
tested and released, only to find that it breaks when run on an older 
platform that was once considered mainstream, but is no longer due 
purely to its age.

>> Was this patch just "looks like a good idea" sort of patch, or does it
>> fix something else, and reverting it breaks that?
>
> The latter. See
> http://lists.live555.com/pipermail/live-devel/2010-November/012840.html

I don't see a reply from the OP saying the change fixed his problem. 
And if it did, are you certain it doesn't just work around a problem 
with his media source?

Are negative time values always bad?  If it's small, gets added to a 
future time value that's greater than the difference between the packet 
scheduler's notion of "now" and the negative delta, the result is still 
a future time.

If that's not it, then maybe timeNow isn't always a "sane" value here. 
Maybe your check for negative times is correct, but there's a better 
value to force when that happens.

> Does this happen with all of your MPEG-2 TS video files, or only with
> some of them?

We have not yet found a file for which it does not happen.

There are too many files to test them all.  (Tens of thousands.)

Even if we could isolate an encoding problem, we have little to no 
control over that.

We've tried remuxing the files being tested with multiple remuxers, to 
no avail.  No reprocessing more resource-intensive than remuxing will be 
practical, due to the number of files involved.

> My current suspicion is that something strange about your TS file(s)
> is (somehow) causing the duration estimate computation in
> "MPEG2TransportStreamFramer" to go negative.

Why blame the TS file when the only variable that changed is the OS? 
Same server binary, same source file.

> It might be useful to see an example of a TS file that illustrates
> the problem.

I'll send you some URLs off-list.