[FFmpeg-cvslog] r22288 - trunk/libavcodec/avcodec.h

[Michael Niedermayer]

On Tue, Mar 09, 2010 at 09:41:14PM +0100, Reimar D?ffinger wrote:
> On Tue, Mar 09, 2010 at 06:47:22PM +0000, M?ns Rullg?rd wrote:
> > Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> > > On Tue, Mar 09, 2010 at 06:29:06PM +0000, M?ns Rullg?rd wrote:
> > >> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> > >> > On Tue, Mar 09, 2010 at 11:21:46AM +0100, Michael Niedermayer wrote:
> > >> >> 3. add a field to AVCodec that specifies the required padding
> > >> >> for each decoder
> > >> >
> > >> > That's not very nice, it means and application needs a reverse data
> > >> > path from decoder to demuxer to tell it what value it needs.
> > >> 
> > >> 1. open demux
> > >> 2. open codecs
> > >> 3. pass padding from codecs back to demux
> > >> 4. profit
> > >> 
> > >> Doesn't seem that complicated to me.
> > >
> > > Sure, as long as you don't try anything unusual.  Like try to decode
> > > with decoder A and then switch to decoder B if that failed.
> > 
> > The use the maximum value.  Or update the demuxer when you decide to
> > switch.
> 
> Yes, and I am exactly asking for FFmpeg to provide that maximum value.
> 
> > >> > At least it should be done in a way that an application at least
> > >> > also has the choice of querying a padding value sufficient for all
> > >> > codecs.
> > >> 
> > >> That would encourage people to use that value rather than go the
> > >> slightly longer, but more efficient, route.
> > >
> > > So? Not all applications have to care about 64 bytes per packet.
> > 
> > 64 bytes isn't the issue.  We're talking about kilobytes for some
> > decoders.  That's not an issue for _them_ since they typically have
> > packet sizes much larger than that anyway.
> 
> In what kind of codec would it not be efficient enough to check for overruns
> at least every few hundred bytes?
> Unless of course this whole thing is meant as an excuse to be able to write
> decoders sloppily...

i suggest you tell us how to check for overreads in h264

the h264 spec mandates some size limit on MBs i think something around 400
byte for 8bit 4:2:0 but thats just for valid streams, a crafted stream
can go far beyond that size for a macro block.
Now you could check more often, like per block but besides that this
will cause more speed penalty you still likely have to deal with overreads
at that level in crafted streams counted in kb, that is with 8x8 blocks
and a codec like AMR has frame sizes between 5 and 31 byte

If you want overreads handled most efficiently, intercepting sigsegv
is the way to go, you only have to check that the access was a read
access after the bitstream buffer, then optionally reset the bitstream index
and continue
I dont know how to do this in C/POSIX but it can surely be done at asm
level
the other efficeint way is a longjmp

beyond that there is codec specific kbs of padding
or
dosable
or
killing small packet audio codecs.
or
1%+ speed loss due to buffer checks in the inner loops

or an intermediate mix of them


other suggestions welcome

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"    - "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20100310/acc6cdec/attachment.pgp>