> > In [[File:RtspDesignArchitecture.png]], my concern is MediaDecoderRTSP. > > Suppose media decoder should recieve data from media resource and has > > no idea on channel protocol at all. > > From the diagram, the only reason tha we need this subclass, > > MediaDecoderRTSP, is media control function, such as seeking/ > > rewind. We may move media control into another class, such as > > MediaController, which provide time base or bit base seeking function > > according to Channel type. > > > > 1. Channel don't tell you what kind of seeking had been supported. > No, it does not. But we may add this function into Channel, and I think it make sense to do it. > 2. MediaDecoder also parse container, if you want feed a RTSP stream to > an existing MediaDecoder, you need a mux to put tracks of an RTSP stream > into a container. demultiplexer(container parser which use to seperate AV track) should be plugin-able. We may add a new filter for demultiplexer and append demultiplexer ahead MediaDecoder, so that MediaDecoder put focus on decode only.
> 3. Since MediaDecoder is already providing control functions, we just > need to another MediaDecoder. MediaController will be a duplication of > MediaDecoder. Do we really need a subclass of MediaDecoder just because of different control function? MediaDecoder -- byte base seeking RTSPMediaDecoder(inherit from MediaDecoder) - time base seeking. But since RTSPMediaDecoder inherits from MediaDecoder, it is capable to do "byte base" seeking. Unless this is what we really want, using inherit here may not a good choice. > > > -- > > Sinker > > -- > > 嚙諸梧蕭嚙箠嚙踝蕭嚙窮嚙踝蕭嚙篇 _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
