Re: File_Vorbis Latest... [FOLLOWUP]

On 13 Aug 2003 at 10:06, David Grant wrote: > >> > 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. Using OGG_STREAM_VORBIS etc. internally is a good point. Maybe for decision if that stream is audio or video you could simply make up an array as a property in the class? Like $streamtypes=array( 'audio' => array(OGG_STREAM_VORBIS, OGG_STREAM_SPEEX), 'video' => array(OGG_STREAM_THEORA) ); Using lowercase internally is really the best solution. I'd suggest to also avoid using spaces (substitute by an underscore) or any other "special characters" (like slashes etc.). Maybe you could make up an additional lookup-table which uses your constants as keys for lookup of the actual names (with upper-lower-class and also maybe with chars like spaces, slashes etc.) if a programmer wants to get the "correct names" for display on his webpages. > > 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? An error in an array? Hmm ... you could probably return an object of type PEAR_Error, okay - but scanning through an ogg container and finding one (of many) streams that is unknown doesn't necessarily mean that a real "error" occured, does it? > b) The capture patterns for the public Ogg streams are quite well > known, so I don't anticipate this being a problem. Expected that :-) > >> 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. :) Excellent. This way you're on the safe side for all future extensions and always maintain complete BC. Good luck! Stefan