[Live-devel] FW: Trick Mode Data Rate

[Moody, Marc D]

Ross and community, 

I'm attempting to implement the first part of Ross's Trick Mode data
rate solution by skipping duplicate I-frames.  Attached is my modified
TrickModeFilter class.  I am keeping track of the TS packet number for
each I frame and allowing getNextFrame() to return with a frame size of
zero when a duplicate I-frame is detected.  I have verified that the
duplicate I-frame packets aren't being moved to the 'fTo' buffer in the
attemptDeliveryToClient() function.

I was hoping these code changes alone would be sufficient to skip
duplicate I-frames but for some reason, the resulting data rate is
unchanged.  Something else in the software is "filling" the gaps
somehow.  My guess is that a parent class (the scheduler perhaps) keeps
grabbing I-frames until it fills up a sufficient time-slice/GOP -
regardless of my skipping duplicate I-frames in the Trick Mode filter.  

Any help in identifying where to look next is appreciated.

Best regards,

Marc Moody
The Boeing Company

-----Original Message-----
From: Moody, Marc D 
Sent: Tuesday, November 18, 2008 6:49 AM
To: live-devel at lists.live555.com
Subject: RE: [Live-devel] Trick Mode Data Rate

Ross,

Thank you for the great description of the problem.  I was considering
the removal of duplicate I-frames myself within the TrickModeFilter
class.  

Generalizing your recommended solution, if we let N represent scale,
then every Nth frame would be posted once and only once at its scaled
presentation time.

Best regards,

Marc Moody
The Boeing Company

-----Original Message-----
From: Ross Finlayson [mailto:finlayson at live555.com]
Sent: Monday, November 17, 2008 10:50 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Trick Mode Data Rate

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 at lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MPEG2TransportStreamTrickModeFilter.hh
Type: application/octet-stream
Size: 3724 bytes
Desc: MPEG2TransportStreamTrickModeFilter.hh
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081119/b64090f4/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MPEG2TransportStreamTrickModeFilter.cpp
Type: application/octet-stream
Size: 11168 bytes
Desc: MPEG2TransportStreamTrickModeFilter.cpp
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081119/b64090f4/attachment-0003.obj>