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/
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
