Re: File_Vorbis Latest... [FOLLOWUP]

Hi Stefan, >> > Maybe it would be wise to also implement functions in the ogg-class >> > to "read streaminfos from file XXX". This way File_Ogg might >> > recognize e.g. an audio-stream (to be more specific: vorbis in your >> > case - in contrast to speex) and get information from that stream >> > using File_Ogg_Vorbis. >> >> So File_Ogg would (by default) read ALL data streams in the Ogg >> container (by passing down to implementing classes), whereas >> File_Ogg_Vorbis (when called directly) would read only Vorbis streams >> when called from anywhere else? Naturally, if more than one specific >> type of stream exists, the user should be given the option of which >> one they would like to retrieve. > > Yep. So I doubt whether calling File_Ogg_Vorbis directly is > necessarily possible. Hmm - a way would be that it parses the ogg- > container like File_Ogg but only (!) returns information for all > vorbis-streams. This way you don't need to parse Theora-streams or > whatever if you don't care about their information. > But generally yes, File_Ogg would read ALL streams in the container > and pass scanning of each stream separately to a sub-class. Excellent. We are agreed. Now only the implementation to carry out. :) >> > Maybe if you use File_Ogg the return could be something like >> > >> > Array( >> > filename, >> > filesize >> > streams=Array( >> > [0]=Array( >> > type="audio" >> > encoding="vorbis" >> > ... >> > ) >> > ) >> > ) >> >> I assume that File_Ogg_Vorbis would return the same, but with only >> type="audio" and encoding="vorbis" elements, right? I think the user >> should be given the option to examine the Ogg container, and extract >> only what they want, e.g. listStreams() might return: >> >> Array ( >> [0] = "vorbis" >> [1] = "tarkin" >> [2] = "vorbis" >> ... >> ) > > Yes, nice idea. Then you can issue a > > getStreamInfo(mixed streamid) > > whereas streamid might be a number (e.g. 0) or an array (e.g. 0,2). Absolutely. That's pretty much what I envisioned. > Also there might be a function > > getSupportedStreamtypes > > for BC to future releases. And maybe > > isStreamtypeSupported ("vorbis") > > or something. There is the possibility here of reusing the stream capture strings as constants here, for example: isStreamTypeSupported(OGG_STREAM_VORBIS) would equate to "vorbis", and OGG_STREAM_FLAC would equal "fLaC", etc.. Obviously, this runs into problems when a user browses the getSupportedStreamTypes() array, as they may be confused by the switching of cases. I think this may require further consideration, or simply returning a trimed lowercase version instead. > While designing File_Ogg: > a) be sure to implement some return for "stream-type unknown" > b) maybe tell the type of a stream (e.g. theora, speex, ...) even > though you haven't implemented them. This would allow full scanning > an ogg container without actually being able to retrieve streaminfo > for every stream. a) Shouldn't this throw an error? b) The capture patterns for the public Ogg streams are quite well known, so I don't anticipate this being a problem. >> I'm not sure if it is necessary to include the medium, as each >> encoding type only supports either audio or video. > > Well okay. I just thought it might be possible this way to check for > audio-streams and don't care if vorbis, speex or some other upcoming > codec is used. Maybe this would bring some kind of future > compatibility. Maybe getSupportedStreamtypes could also return the > name together with audio/video. > But this is open for discussion - it's my personal view. That's an interesting point. I think I'd better take a long[er] look at multiple stream types in Ogg. :) Regards, David