[Gstreamer-bugs] [Bug 120032] New - Last mimetype enhancements

[bugzilla-daemon at widget.gnome.org]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=120032

Changed by rbultje at ronald.bitfreak.net.

--- shadow/120032	Sat Aug 16 15:41:43 2003
+++ shadow/120032.tmp.20310	Sat Aug 16 15:41:43 2003
@@ -0,0 +1,52 @@
+Bug#: 120032
+Product: GStreamer
+Version: HEAD CVS
+OS: All
+OS Details: RH73
+Status: NEW   
+Resolution: 
+Severity: enhancement
+Priority: Normal
+Component: gst-plugins
+AssignedTo: rbultje at ronald.bitfreak.net                            
+ReportedBy: rbultje at ronald.bitfreak.net               
+QAContact: gstreamer-maint at bugzilla.gnome.org
+TargetMilestone: HEAD
+URL: 
+Summary: Last mimetype enhancements
+
+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. ;).