[Live-devel] Get MPEG-TS timing from .tsx file?

[Warren Young]

On 9/19/2013 16:13, Ross Finlayson wrote:
> I took a look at this idea back in January 2011, and decided that it
> probably wouldn't be worth the trouble:
> http://lists.live555.com/pipermail/live-devel/2011-January/013083.html

Okay, let's go back through it point by point:

1a. Index file change.

Agreed, it's a problem.  Too bad there isn't a header record with a 
version number, so you could cope with file format changes.

You could add one, the same size as one of the existing records, but 
with magic bytes you could recognize.  Then you calculate number of 
records - 1 wherever you currently divide record size into file size.

1b. Index file size increase.

Can't you calculate "duration per transport packet" from the known 
locations of the frames and the frame rate?  If a given TS packet is one 
of 100 representing a P frame and the frame rate is 29.97 fps, then the 
duration for this transport packet is 1 / 29.97 / 100 seconds.

2. File I/O overhead.

Actually, this feature would *save* on disk I/O, because it saves you 
from having to null stuff VBR files out to CBR.  Taking my 164% null 
stuffing overhead example, the net savings in I/O is around 2.5x.

The only way it isn't a net savings is if you're trying to use this 
feature with a VBR file that's so close to CBR already that the index 
file is bigger than the required null stuffing, which probably isn't 
actually required to stream it smoothly in the first place.

Simple fix: make it default, but optional.  The only people needing to 
turn the feature off will be those who are within 10% of disk I/O 
saturation already.

3. Still requires fudge factors.

Isn't this the core of the streaming problem?  Isn't it why you have 
things like VBV in MPEG-2?

No solution solves the entirety of this problem by itself, short of 
giving up on real-time streaming.  (e.g. HLS, which isn't "streaming", 
to my way of thinking.  It's just a bunch of chained downloads.)

4. Increases network burstiness, hence may affect congestion.

Which contributes more to network congestion, a 3.7 Mbit/s CBR stream or 
a 1.4 Mbit/s VBR stream?

In any case, there's an existence proof countering this argument: 
YouTube, Hulu, Netflix...  They're all VBR.