[FFmpeg-devel] PATCH: allow load_input_picture, load_input_picture to be architecture dependent

[Michael Niedermayer]

Hi

On Thu, Jul 19, 2007 at 07:35:55AM -0400, Marc Hoffman wrote:
> On 7/19/07, Michael Niedermayer <michaelni at gmx.at> wrote:
> > Hi
> >
> > On Wed, Jul 18, 2007 at 10:37:08PM -0400, Marc Hoffman wrote:
> > > On 7/18/07, Michael Niedermayer <michaelni at gmx.at> wrote:
> > > > Hi
> > > >
> > > > On Wed, Jul 18, 2007 at 09:22:57PM -0400, Marc Hoffman wrote:
> > > > > On 7/4/07, Michael Niedermayer <michaelni at gmx.at> wrote:
> > > > > >
> > > > > > Hi
> > > > > >
> > > > > > On Tue, Jun 26, 2007 at 03:49:11PM -0400, mmh wrote:
> > > > > > Content-Description: message body text
> > > > > > >
> > > > > > > This patch lays the ground work for pipelined data movement for the
> > > > > > > load_input_picture function.
> > > > > > >
> > > > > > > If this load is pipelined my embedded system will save around 33MIPS
> > > > > > > for QVGA video encode, multiply by 4 for SD.
> > > > > > >
> > > > > > > This functionality includes 2 functions, get_frame, and frame_ready
> > > > > > > which can be defined by a specific architecture.
> > > > > >
> > > > > > just ensure that the linesize is correct and that
> > > > > > CODEC_FLAG_INPUT_PRESERVED
> > > > > > is set then the image wont be copied
> > > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > Where do you propose I make this change, I guess I'm not 100% clear on this
> > > > > idea.
> > > >
> > > > in the code which uses libavcodec (that is likely ffmpeg.c) but it might be
> > > > better to wait until after libavfilter ...
> > > >
> > >
> > > We need this now (real soon),
> >
> > who is we?
> >
> >
> > > how long before libavfilter?
> >
> > months
> 
> We would be me ++ folks using Blackfin in real systems that are
> waiting for better system performance.

well, if you want to rewrite ffmpeg.c buffer management just to have it
thrown away in a few month i wont stop you ...
also i think you will be very sad when you see how little performace you
gain from it
geting rid of the memcpy that way means you have more buffers internally
and thus the caches will be less efficient

doing the copy in the background like you originally did requires
a few more modifications than you did, that is you would have to add checks
to several points so that we dont read the buffer before the specfic part
has been copied, this sounds quite hackish and iam not happy about it

is mpeg4 encoding speed on blackfin really that important?
cant you just optimize memcpy() in a compatible non background way?

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070719/e7d3a5a0/attachment.pgp>