[FFmpeg-devel] [PATCH][0/4]: MMS base and MMSH implementation
Michael Niedermayer
michaelni
Fri Mar 7 19:37:09 CET 2008
On Fri, Mar 07, 2008 at 01:48:08PM +0100, Bj?rn Axelsson wrote:
> On Thu, 2008-03-06 at 22:44 +0100, Michael Niedermayer wrote:
> > On Thu, Mar 06, 2008 at 03:53:09PM +0100, Bj?rn Axelsson wrote:
> > [...]
>
> Thanks for your speedy response. I'd like to ask for a few
> clarifications before I start on the next version of the patch.
>
> > > +/** Private MMS data. */
> > > +typedef struct {
> >
> > > + const AVClass *av_class; ///< Context for logging.
> >
> > this does belong in URLWhatever not in your private context
>
> That would require an API change and a major version bump. Is that
> acceptable and wanted?
no, :(
but a AVClass under #ifdef VERSION >= next major could be added
>
> > > + MMSProtocol *protocol; ///< Function pointers for the subprotocol.
> > > + void *priv_data; ///< Private data for subprotocol.
>
> [...]
>
> > Iam also somewhat opposed to MMSProtocol *protocol. But that is rater minor.
>
> With only one subprotocol, it doesn't make much sense. But with mmsh,
> mmst and possibly even mmsu I believe
>
> mms->protocol->foo(mms)
>
> is a cleaner solution than sprinkling the shared code with a bunch of
>
> if(mms->protocol == MMS_HTTP)
> mms_http_foo(mms)
> else if(mms->protocol == MMS_TCP)
> mms_tcp_foo(mms)
well, you still have
if(mms->protocol == MMS_HTTP)
mms->protocol->foo= mms_http_foo;
else if(mms->protocol == MMS_TCP)
mms->protocol->foo= mms_tcp_foo;
The reason why i dont like these pointers is that it adds another layer
of indirection a reader has to go through (where is that pointer set and to
what before he can look up the code of the function)
>
> Although I'm open for other suggestions.
>
> > > +
> > > + /** @name ASF Header
> > > + * Internal handling of the ASF header. The ASF header is stored by the
> > > + * protocol to facilitate seeking into it. The protocol also parses the
> > > + * header to get the packet size and elementary stream information.
> > > + */
> >
> > why would we want to seek into the header?
>
> That is surely up to the calling application. IIRC mplayer does this for
> some reason.
If mms itself doesnt support it then i dont see why we should emulate this.
just fail or return zero bytes (unless this really doesnt work ...)
>
> > > + /*@{*/
> > > + uint8_t *asf_header; ///< ASF header buffer.
> > > + int asf_header_size; ///< Size of stored ASF header.
> > > + int asf_header_read_pos; ///< Header read offset. See read_packet().
> > > + int header_parsed; ///< Flag: header has been fully parsed.
> > > + AVFormatContext private_av_format_ctx; ///< Private header data (generic).
> > > + ByteIOContext private_av_format_pb; ///< Private header data (IO buf).
> > > + ASFContext asf_context; ///< Private header data (ASF).
> >
> > private of what? we have an asf demuxer (which you shouldnt touch) a
> > subprotocol (mmsh), this mms stuff, an underlaying protocol (tcp/http)..
> > is tha asf stuff here the one actually demuxing things or some private
> > seperate thing unrelated to the demuxer used to help avoid code duplication.
> > All this should be clearly documented.
>
> The protocol needs to parse the streamed ASF header to get info about
> the available elementary streams. Is it ok (but still ugly) to call the
> ASF demuxer for this?
> The alternatives I can think of is to either reimplement a ASF header
> parser (very bad idea) or to directly call the private functions of the
> ASF demuxer.
Its ok to open a asf demuxer, parse the header, extract what you need and
close it again.
Its not ok to keep the AVFormatContext around to confuse me :)
[...]
>
> > [...]
> > > +
> > > +extern AVInputFormat asf_demuxer;
> >
> > This is ugly besides that it should be #include not such copy and
> > paste hacks of what you need from the header.
>
> Which header would that be? "AVInputFormat asf_demuxer" is never
> declared in any header, and is only used once in allformats.c (with an
> extern declaration).
Once upon a time there was allformats.h ... well it seems somone killed it :(
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
-------------- 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/20080307/d0b6ca0a/attachment.pgp>
More information about the ffmpeg-devel
mailing list