[FFmpeg-devel] [PATCH] Set CODEC_CAP_SUBFRAMES for adpcm decoders

Michael Niedermayer michaelni
Fri Jan 22 19:21:56 CET 2010


On Fri, Jan 22, 2010 at 04:13:03PM +0000, M?ns Rullg?rd wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> 
> > On Thu, Jan 21, 2010 at 04:42:27PM +0000, M?ns Rullg?rd wrote:
> >> Michael Niedermayer <michaelni at gmx.at> writes:
> >> 
> >> > On Thu, Jan 21, 2010 at 02:12:26PM +0000, M?ns Rullg?rd wrote:
> >> >> Benjamin Larsson <banan at ludd.ltu.se> writes:
> >> >> 
> >> >> > M?ns Rullg?rd wrote:
> >> >> >> I thought adpcm was one of those non-byte-aligned codecs, at least
> >> >> >> some variants.
> >> >> >
> >> >> > It is.
> >> >> 
> >> >> Which means frame-splitting is not generally possible.
> >> >
> >> > ADPCM in general comes in frames with a header of an initial sample
> >> > and a series of adaptive delta coded fixed length (generally
> >> > 4 bit) symbols
> >> > but there are exceptions. The general case though certainly can be split
> >> 
> >> General in this context means something that is always true.  If there
> >> exist adpcm streams with non-byte-aligned frames, they cannot be split
> >> in the general case, which includes these streams.
> >> 
> >> It may be that in the _majority_ of streams can be split, but unless
> >> there's an easy way to determine this without actually trying it, I
> >> don't think we should be requiring it.
> >
> > We have 27 adpcm decoders, some of them can be split into frames, some
> > do not know a concept of frames != packets some maybe cannot be split.
> > They all use an AVCodec struct build out of a macro to which you added
> > the flag, thus effectively adding it to 27 different codecs, some of
> > which are not even capable of returning subframes no matter what is in
> > the bitstream.
> 
> If someone tells me which of decoders need the flag I will fix it.

id guess none, all that allow multiple frames likely can be split trivially

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I hate to see young programmers poisoned by the kind of thinking
Ulrich Drepper puts forward since it is simply too narrow -- Roman Shaposhnik
-------------- 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-devel/attachments/20100122/b96b383d/attachment.pgp>



More information about the ffmpeg-devel mailing list