<br><font size=2 face="sans-serif">Ross and Community,</font>
<br>
<br><font size=2 face="sans-serif">I am hoping to implement a bandwidth
limitation on trick mode streams only, such that the bitrate of the trick
mode stream would not exceed the average bitrate of the original stream.
For the particular 5 Mbps streams that I have, I cannot get
above 4x speed-up without significantly exceeding the 5 Mbps data rate.
(I have stopped the filter from repeating I-Frames because my client's
network buffers have no hope of handling these repetitions. Also,
I was told that the I-frames which were repeated had identical PCR if -
I remember correctly - and so the decoder buffer of my client would become
full before a new PCR was available in the buffer.)</font>
<br>
<br><font size=2 face="sans-serif">I have figured out a very crude way
to implement this for my specific system, but I am trying to figure out
a better way to do the math to determine which I-frames to discard to implement
a bitrate limitation. Initially, I think that if I add another count
to MPEG2TransportStreamTrickModeFilter such that each GOP would be divided
into 4 "time slots", and allow only 1 I-frame to be sent per
"time-slot", that my trick-mode bitrate limitation would work
most of the time. I think this was the suggestion here: http://lists.live555.com/pipermail/live-devel/2007-March/006317.html</font>
<br>
<br><font size=2 face="sans-serif">It would work something like this:</font>
<br><font size=2 face="sans-serif">Each GOP I can think of as being divided
into 15 time-slots, T0-T14. I must send "scale" number
of I-frames per GOP. If "scale" > 15, then some I-frames
will be discarded.</font>
<br><font size=2 face="sans-serif">I can figure out which I-frame, I</font><font size=3 face="sans-serif"><sub>N</sub></font><font size=2 face="sans-serif">,
from the original stream goes in any given slot with: </font>
<br>
<br><font size=2 face="sans-serif"> floor
function ( scale * slot-number / GOP-length) = N</font>
<br>
<br><font size=2 face="sans-serif">To limit the bitrate on top of this,
I would have to divide the GOP into 4 and allow only one I-frame to be
sent in each of T0-T3, T4-T7, T8-T11, T12-T14.</font>
<br>
<br><font size=2 face="sans-serif">You can see that this implementation
would not scale very well at all, and in fact might not even work for particular
streams in my system. I would most like to ensure that the trick
mode bitrate would not exceed the average bitrate of the original stream.
But if that is not possible, then I would like to figure out a way
to specify the maximum bitrate. Can you provide any suggestions on
how to implement either of these changes? I see here, you have a
different idea altogether: http://lists.live555.com/pipermail/live-devel/2007-April/006509.html</font>
<br>
<br><font size=2 face="sans-serif">Thank you!</font>
<br><font size=2 face="sans-serif">Xochitl Smith</font>