Hi Ruben, > I have been taking a look at the Mediapackage API, and specifically to the > Track and Stream API. > > The first surprising thing is that the API does include methods for checking > if the track contains any video stream or any audio stream (hasVideo and > hasAudio respectively), but does not include a method to retrieve such > streams (audio or video). I would say that methods are required in the API, > too.
You must have overseen Track#getStreams ;) This gets you the streams. Use a filter to grep the streams you need. In fact there exists already one in TrackSupport. If you need further convenience feel free to implement it as functions there. > The other surprising thing is the fact that TrackImpl does have getVideo and > getAudio methods, but such methods return a List containing the audio/video > streams. Now I can imagine Tracks with more than one audio stream (stereo > Tracks), but I cannot imagine a single track with different video streams. If > we are assuming (which I am) that Track represents an (audio)visual file, > then it makes no sense for it to have more than one video stream, or does it? > Could someone provide an example? The track interface has been designed to be most flexible. Multistream tracks are in fact rare but do exist nevertheless, e.g. multi-angle recordings. I'd vote for keeping the API as is. This gives a maximum of flexibility without changing a core API. Convenience methods/functions can be implemented elsewhere, e.g. in TrackSupport. Regards, Christoph > Anyway, I did a "grep" throughout all the codebase and there's no place (in > the trunk, at least) where such methods are used, so their signature could be > changed easily without breaking other service. My (informal) proposal would > be allowing just one video stream per track, and several audio streams, > unless somebody thinks differently about the video streams. > > The other (informal) proposal is including the methods getAudio and getVideo > into the Track interface, and rename them to getAudioStreams and > getVideoStream(s). I would have those services return an array, rather than a > List, but that would be secondary. > > I'm willing to make those proposals official if no one has anything against. > > Best regards > > Rubén Pérez > TELTEK Video Research > www.teltek.es > > > _______________________________________________ > Matterhorn mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn > > > To unsubscribe please email > [email protected] > _______________________________________________
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
