[Live-devel] Re-architecturing MPEG4 ES Framer

[Jerry Johns]

Hello,

         I'm currently trying to get MPEG4 ES Streaming from a real-time
encoder implemented on an embedded ARM platform - did some analysis on
the current MPEG4VideoStreamFramer and its associated parsers - although
it's a very well designed (and robust) implementation, it slightly
inefficient for our needs;

 

1)       There are two levels of memory copying - one from the
ByteStreamFileSource (or whatever source you have) to the StreamParser's
double banks, and then from there to the actual fTo location where
MultiFramedSink will pick it up and pack/send it. This is unacceptable
since I'll already be doing another memory copying from the encoder
output memory location to a circular buffer from which LiveMedia picks
up its data; this amounts to wasteful memory bandwidth

2)       The output of our encoder gives us discrete VOP packets (after
the initial VOSS, and VOL headers) that we know the size to - this
allows for efficient DMA and to a lesser extent, memcopies. The
MPEG4VideoStreamParser goes through byte by byte in its traversal for
the start codes, which is not required in our application

 

Knowing these two things, what do you suggest as a course of action? I
was thinking of making my own MPEG4VideoStreamFramer class (named
differently) that instantiates perhaps a BufferStreamParser? (The data
input is resident in a FIFO buffer). Ultimately, I would like to copy
from the circular buffer directly to the final fTo location, and to do
that without going through the stream byte by byte (not needed, since
VOP packets can be transferred wholely to the fTo buffer)

 

Any help will be appreciated,

 

Thanks

 

Jerry Johns

Design Engineer

Nuvation Research Corp - Canada

Tel: (519) 746-2304 ext. 225

www.nuvation.com <http://www.nuvation.com> 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20080808/5d91aa31/attachment.html>