[FFmpeg-devel] [PATCH] Parse DEFINESOUND tags in swf (fix ticket 1638)

Michael Bradshaw mbradshaw at sorensonmedia.com
Fri Oct 12 09:22:29 CEST 2012


On Oct 12, 2012 12:04 AM, "Clément Bœsch" <ubitux at gmail.com> wrote:
>
> On Thu, Oct 11, 2012 at 07:51:36PM -0600, Michael Bradshaw wrote:
> > On Tue, Oct 9, 2012 at 8:32 PM, Michael Niedermayer <michaelni at gmx.at>
wrote:
> > > On Tue, Oct 09, 2012 at 07:24:01PM -0600, Michael Bradshaw wrote:
> > >> On Tue, Oct 9, 2012 at 1:57 PM, Michael Niedermayer <michaelni at gmx.at
>wrote:
> > >>
> > >> > On Tue, Oct 09, 2012 at 10:34:34AM -0600, Michael Bradshaw wrote:
> > >> > > +            ast->time_base.num = 1;
> > >> > > +            ast->time_base.den = ast->codec->sample_rate;
> > >> >
> > >> > these 2 should be redundant
> > >> >
> > >>  Ah, thanks, I'll send an updated patch in a bit.
> > >>
> > >> > +            ast->duration = avio_rl32(pb); // number of samples
> > >> > > +            if (((v>>4) & 15) == 2) { // MP3 sound data record
> > >> > > +                ast->skip_samples = avio_rl16(pb);
> > >> > > +                len -= 2;
> > >> > > +            }
> > >> > > +            len -= 7;
> > >> >
> > >> > > +            if ((res = av_get_packet(pb, pkt, len)) < 0)
> > >> > > +                return res;
> > >> >
> > >> > can this chunk be big ? i mean 100mb or so ?
> > >> > if this happens in realworld files its probably better to split in
> > >> > some fixed size packets to reduce memory need and latency until its
> > >> > fully loaded
> > >> >
> > >>  Technically, yeah, it could be big. The entire sound file is stored
as a
> > >> single chunk. This was my main worry. In practice, they aren't that
big,
> > >> seeing as they're typically shorter audio clips loaded onto the
stage, but
> > >> it's possible someone could do that. I saw your comment on the
ticket and
> > >> wanted to put together a working patch, at least, because adding that
> > >> (which I think is a good idea in the end) would require some logic
changes
> > >> to the demuxer I believe, and I don't have a lot of time to figure
out how
> > >> to nicely fit it all together.
> > >
> > > agree its better to support it this way than not at all but please add
> > > a FIXME comment or something that ideally this should be split into
> > > multiple packets
> >
> > Ok, I've attached an updated patch. It might conflict a bit with
> > Clément's patch that adds the TAG_DEFINESOUND macro too.
> >
>
> I can wait for your patch to go in, so no worry (and the macro names are
> the same so it should be fine).
>
> Anyway, your patch (current and previous) is fixing a playback issue with
> one of my sample (pcm 16), so thanks.
>
> I'm curious about your first FIXME though; I may be able to find a pcm u8
> sample in the wild if you need one.

Thanks, that would be helpful, though I can make one if needed. The problem
is that the current code detects PCM correctly (at least the little endian
case... It assumes the native endian case is little endian, which seems
wrong for big endian systems) but ignores the 8/16-bit flag. It'll take
some refactoring and I don't know if/when I'll get around to it.


More information about the ffmpeg-devel mailing list