[FFmpeg-devel] [PATCH] SHOUTcast HTTP Support
Micah Galizia
micahgalizia
Fri Mar 5 17:00:43 CET 2010
On Fri, Mar 5, 2010 at 10:54 AM, Michael Niedermayer <michaelni at gmx.at>wrote:
> On Fri, Mar 05, 2010 at 09:36:54AM -0500, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Thu, Mar 4, 2010 at 7:16 PM, Micah F. Galizia <micahgalizia at gmail.com>
> wrote:
> > >> So why don't you strip this off as well in the second probe?
> > >
> > > To recap, on Michael's recommendation, I'm putting the probe loop from
> > > utils.c in its own method so the shoutcast demuxer can use it too.
> >
> > ... with the output of the icy demuxer, not its input.
> >
> > You're not trying to probe the data of the icy demuxer input. That is
> > icy. We know that. You already are the demuxer for it. In fact, if the
> > icy-internal-probe finds that the data is mp3, I would say that you
> > just found a bug in your icy demuxer probing code.
> >
> > You want to feed it (somehow, e.g. by providing a new URLProtocol on
> > top of the icy demuxer) the OUTPUT of the icy demuxer. That should be
> > valid, framed and good mp3, requiring none of this patch.
> >
> > At least I thought that was what you were going to do.
>
> the way i understood it, is that the stream in there is actually
> not good mp3 but rather good mp3 cut at random unknown to us byte
> offset
>
That is correct, AFAIK. Following that good mp3 cut at random unknown to us
byte offset there will be icy metadata. However, we know how much mp3 data
there is before that occurs, and that will be the limit of what we pass to
the probe (the probe does not see icy metadata).
--
"The mark of an immature man is that he wants to die nobly for a cause,
while the mark of the mature man is that he wants to live humbly for one."
--W. Stekel
More information about the ffmpeg-devel
mailing list