[Live-devel] Trick Mode Data Rate

[Ross Finlayson]

Marc,

In my April 2007 posting, I misremembered what I had implemented.  A 
trick-play stream does, indeed, have a higher bitrate than the 
original stream, because (i) it consists only of I (i.e., key) 
frames, and (ii) has the same frame rate as the original source.  The 
reason for (ii) was that I was concerned that some set-top box 
receivers might not be able to handle a change in frame rate from the 
original stream.  However, assuming that that is in reality not a 
problem, then I plan to change the trick-play stream generation code 
so that it still contains only I-frames, but with each I-frame 
appearing at most once, and with I-frames appearing at the same rate 
as I-frames in the original stream.  Because of this, under the new 
algorithm, trick-play streams will have a lower bitrate than the 
original stream.

Suppose, for example, that the original Transport Stream contains the 
following video frames
	I1	n2	n3	n4	n5	n6	I7	n8	n9 ...
where each Ii is an I-frame, and each nj is a *non* I-frame.  In this 
example, each 6th frame is an I-frame.

Under the current algorithm, for 2x fast-forward, the following 
trick-play stream is produced:
	I1	I1	I1	I7	I7	I7	I13	I13	I13 ...
Under the new algorithm, for 2x fast-forward, the following 
trick-play stream will be produced:
	I1						I13 ...
i.e., Each I-frame will appear at most once, with I-frames appearing 
at the same rate as I-frames in the original stream.  In this 
example, the frame rate of trick-play streams will be 1/6 that of the 
original stream.

I have a policy of not answering "Are we there yet?" questions on 
this mailing list, so I'm not going to give an ETA for this.  But 
rest assured that it is a high-priority item.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/