You're right, Christoph. I actually saw that method but I what I really meant in my previous mail is that I was missing a way of retrieve the video and audio streams separately. Thanks for pointing me to TrackSupport, and sorry for not explaining clearly the first time :S
Nothing to complain on the track with multiple video streams. I still find it hard to picture, but we don't need to limit ourselves. However, I still believe that if TrackImpl has a method to return the video tracks or the audio tracks separately, there should exist the same function in the interface (in fact, it should be the other way round --how is it that the implementation offers such a crucial method and the interface doesn't?--). I mean, it's nice there are filters and all that (and I could even go and filter them myself), but I think that functionality belongs in the interface. To me, it makes no sense to have an external filter in an external class when we can simply add that (basic) methods to the interface directly. Rubén Pérez TELTEK Video Research www.teltek.es 2012/10/1 Christoph Drießen <[email protected]> > 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] > _______________________________________________ >
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
