GNOME Bugzilla – Bug 120032
[docs/mime] Last mimetype enhancements
Last modified: 2012-08-13 18:10:53 UTC
I've worked on mimetypes before and I'm almost happy with it. I'll propose some more enhancements here. 1) the framerate property is marked as optional, we need to make it work as such. E.g., xvideosink doesn't need framerate. Neither does asfmux (being worked on ;) ). Asfdemux cannot *give* a framerate (simply because ASF doesn't have any such info in its headers) and currently gives out 0, which is plain wrong. We then also need an element that can standardize framerate and/or calculate it based on input timestamps/buffers, so that outputs that require a framerate (e.g. avimux) will still work. 2) elements need to passthrough optional elements. Think of pixel_width/pixel_height and framerate. Elements that don't require it, still need to pass it through if they detect it on the input caps and if it applies to the output, too. 3) YUV raw-video caps needs to be based on something else than fourccs. This is kind of weird, but just like with RGB, it's too limiting, and doesn't describe it all. We might want to describe planar/packed YUV separately. For exact descriptions, look at LCS (it uses this, already). Think about bpp, hor/ver chroma downsampling etc. as properties to descibe a YUV stream 4) RGB raw-video needs to be described using pixel bpc/offset in integers, not using masks. Masks can be calculated using (((1<<bpc)-1)<<offset). This is more generic, and doesn't require switching to something bigger than 32-bit integers if you want to describe, say, 10-bit RGB. 5) maybe we want a bitrate property for (CBR?) encoded streams, such as mp3? So, that's all, I think. The raw/video stuff will kick against some other people's ideas, I guess, so please make comments! And yes, when we've agreed on some of these finetuning things, I'll implement it. ;).
I think this is mostly obsolete these days, let's close it :)