Re: File_Vorbis Latest... [FOLLOWUP]

On 13 Aug 2003 at 9:08, David Grant wrote: > On 2003.08.13 01:02, Stefan Neufeind wrote: > > Does your class take multiple "streams" in consideration yet? (If > > yes, I didn't say anything *g*) > > Nope, not yet. It is (currently) based on the concept of a single > stream. > > > 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. > > 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). Also there might be a function getSupportedStreamtypes for BC to future releases. And maybe isStreamtypeSupported ("vorbis") or something. 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. > 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. > > This way you could as well support multiple audio/video-streams. > > This is a far better way of looking at Ogg (and provides far more work > :P), so thanks again for your proposals! Well, if you lack work just ask :-))) Stefan