Timeline for Private interfaces within a package
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 29, 2012 at 6:40 | vote | accept | rwong | ||
| Jan 17, 2012 at 10:23 | comment | added | Dipan Mehta | @rwong if you are referring to actual MPEG class codecs transcoding interface (which provides partial decode/encode) should be a super set of encoding/decoding sides not replacement. It should be Public API rather than Private API. The real trouble with transcoding API is heterogeneity of the symbols across variety of formats and acceptable intermediate symbols. It's possible, but it is not quite there in public domain, because there is no money in doing this! | |
| Jan 17, 2012 at 8:12 | comment | added | rwong | In my actual work, the encoders and decoders expose a vendor ID, which can be queried and compared. It is assumed that if the encoders and decoders are from the same "vendor", they could then start talking to each other using their proprietary interfaces. However, a third-party implementer who only implement one side (only one of decoder/encoder) would not be able to talk efficiently with any vendor's optimized interface. Likewise, a third-party implementer who didn't implement any proprietary optimized interface also won't get any automatic benefit. Which leads to a "fall-back" behavior. | |
| Jan 17, 2012 at 7:19 | history | edited | Dipan Mehta | CC BY-SA 3.0 | Added the example case.; added 253 characters in body |
| Jan 17, 2012 at 7:06 | history | answered | Dipan Mehta | CC BY-SA 3.0 |