[FFmpeg-devel] [PATCH] Parse MDPR for audio/x-ralf-mpeg4

Kostya kostya.shishkov
Mon Dec 28 15:20:07 CET 2009


On Mon, Dec 28, 2009 at 07:42:20PM +0530, Jai Menon wrote:
> On Thu, Dec 24, 2009 at 10:51:20AM -0500, Ronald S. Bultje wrote:
> > Hi,
> > 
> > On Thu, Dec 24, 2009 at 10:01 AM, Jai Menon <jmenon86 at gmail.com> wrote:
> > > As in subject.
> > 
> > +            if (!st->codec->channels || st->codec->channels > 2) {
> > +                av_log(s, AV_LOG_ERROR, "Only mono and stereo RALF
> > streams are supported.\n");
> > +                return -1;
> > +            }
> > [..]
> > +            if (st->codec->bits_per_coded_sample != 16) {
> > +                av_log(s, AV_LOG_ERROR, "Invalid sample depth.\n");
> > +                return -1;
> > +            }
> > [..]
> > +            if (st->codec->sample_rate < 8000 ||
> > st->codec->sample_rate > 96000) {
> > +                av_log(s, AV_LOG_ERROR, "Invalid sampling rate.\n");
> > +                return -1;
> > +            }
> > 
> > These really do not belong in a demuxer. Maybe in libavformat/codec or
> > in the decoder, but not in rmdec.c.
> 
> Okay, moved these to the decoder.
> 
> > 
> > +            get_be32(pb);  // Max. audio frame size (in bytes)
> > 
> > s->audio_framesize = ..
> > 
> > +            get_be32(pb);  // unused
> > 
> > Don't we just skip all unparsed data in the end, so at least that last
> > line is not necessary? Maybe you can store the max. audio frame size.
> 
> Let me clarify, the the field stores the max. possible decoded audio
> frame size, which we already calculate. Its not very useful right now
> so maybe we can export it later if the decoder requires it. I have
> retained the get_be32 and the comment, however, as a documentation of
> sorts.

In principle it look ok and can be applied when there is a decoder for
it. IIRC, not even MPlayer can handle it with binary decoder for now.
 
> As a sidenote, there are some more issues to iron out before the
> demuxing is proper.  Right now, rmdec detects a bunch of invalid
> streams which probably should be fixed separately.

Are you sure they are invalid? It may be just retarded developers who
used special streams (MIME-type "logical-fileinfo") for different crap
like metadata, encoder info, assembly rules and such. One day somebody
can add handling for them though.

> -- 
> Jai Menon



More information about the ffmpeg-devel mailing list