After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 120032 - [docs/mime] Last mimetype enhancements
[docs/mime] Last mimetype enhancements
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins
git master
Other All
: Normal enhancement
: NONE
Assigned To: Ronald Bultje
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2003-08-16 19:41 UTC by Ronald Bultje
Modified: 2012-08-13 18:10 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ronald Bultje 2003-08-16 19:41:42 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. ;).
Comment 1 Tim-Philipp Müller 2012-08-13 18:10:53 UTC
I think this is mostly obsolete these days, let's close it :)