|
|
| ale5000 |
| Posted: Dec 22 2010, 10:30 PM |
 |
|
Advanced Member
Group: Members
Posts: 1114
Member No.: 22180
Joined: 30-September 07
|
It would be nice if input plugins are able to "register" decoders (usable without it's "splitter like" functions) so that a different input plugin can ask VirtualDub to choose aumatically the best decoder (with an option in VirtualDub that allow to select if prefer internal or external) for the specific video track between:
- vfw
- internal virtualdub video decoders
- video decoders registered by input plugins.
Same for audio track:
- acm
- internal virtualdub audio decoders
- audio decoders registered by input plugins.
Example use:
The mpeg2 input plugin can register it's internal mpeg2 decoder.
Then a user open an .mkv file with mpeg2 video and the matroska input plugin ask to virtualdub to choose the best decoder (and virtualdub can choose to use the mpeg2 decoder previously register by the mpeg2 input plugin).
--------------------
New VirtualDub forum
VirtualDub AIO (All-in-One installer for VirtualDub and plugins)
Codec Toolbox RS (A tool to read/change merit of codecs and many other things)
Input plugins for VirtualDub / ACM codecs / VFW codecs |
|
| phaeron |
| Posted: Dec 24 2010, 12:15 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
I'm not sure how viable it would be to register decoders that could work across the various formats. The existing decoder API uses an API that's modeled after VFW, which is a relatively straightforward format + one frame in, one frame out system. Once you start mixing in the newer formats, you start getting into more complex issues like B frames. Probably the biggest issue, though, is the mismatch between a stream-based decoder and a frame-based decoder. MPEG-based decoders, and also those written for DirectShow, tend to be written as stream decoders rather than frame decoders. This is fine for playback, but harder to deal with when you want precise random access. For instance, in practice I haven't seen an audio decoding API that could be used for precise seeking in an MPEG audio stream without close coupling between the decoder and the parser.
What this really comes down to is whether an API that I could provide for this would be better than what you'd get just linking in helper libs directly into the plugin. Currently, I don't think that's the case, particularly with my inexperience with MPEG-4 and H.264 decoders.
|
|
| ale5000 |
| Posted: Dec 24 2010, 01:32 AM |
|
|
Advanced Member
Group: Members
Posts: 1114
Member No.: 22180
Joined: 30-September 07
|
About video:
Maybe, to make it simpler, can be put inside input plugins the selection from two types of decoding:
- internal virtualdub video decoders / video decoders registered by other input plugins
- vfw
If the first option can be used, then the input plugin can support B frames and other additional things since this doesn't require the vfw and so you can extend it as much as you want (since it is only talking from virtualdub to the input plugin directly)
if there isn't a decoder of the first type then it will use the "limited" vfw.
--------------------
New VirtualDub forum
VirtualDub AIO (All-in-One installer for VirtualDub and plugins)
Codec Toolbox RS (A tool to read/change merit of codecs and many other things)
Input plugins for VirtualDub / ACM codecs / VFW codecs |
|
| phaeron |
| Posted: Dec 24 2010, 10:25 PM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
That doesn't solve the complexity issue, really.
VirtualDub has two generic APIs for decoding. One of them, which is internal only, only supports simple codecs like Huffyuv. The other one, which is exposed via the plugin API, does allow for B frame capable formats like MPEG-1, but the problem is that it's not a full API -- you have to request the decoder from the video stream, because the initialization data has to be passed via a private channel. In other words, it's not suitable for an environment where the decoder and the client are completely separate plugins. It's also unfortunately a bit of a PITA to implement due to the decoder / decoder model split.
Coming up with a decoder API is probably something I wouldn't try to do on my own. I'd have to draw on requirements from people who'd actually be using and implementing it to get an idea of what'd be required.
|
|
