[gstreamer-bugs] [Bug 328382] support single-image files

GStreamer (bugzilla.gnome.org) bugzilla-daemon at bugzilla.gnome.org
Tue Jan 24 06:50:44 PST 2006


Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=328382
 GStreamer | gstreamer (core) | Ver: 0.8.x





------- Comment #6 from Ronald Bultje  2006-01-24 14:50 UTC -------
I didn't say "should", it is just one of the many ways to implement it.

Doing this as a fakesink is problematic since we need a way to let the
application know the caps (size, video format) of the decoded image (RGB? YUV?
etc.). Therefore, letting the app figure it out, they already have decoders, is
as easy. Practically, this may come down to having the app setup another gst
pipeline to decode it, that's up to the app. Gdkpixbuf provides better
convenience functions, so let's just use that.

Reasons why I think we should do this at the demuxer level:
* it is not video. It is not. It's a single image. we should not give "users"
the impression that they can switch between the video and this image stream.
That is not possible.
* you could make a reasonable, though not perfect, point that this really is a
tag, especially in the case of id3, but the qtdemux single images aren't far
off from the id3 case.
* doing it this way provides a unified API for the same thing for a mp3 file
with id3 tags and a aac file in a quicktime container, which is very convenient
and eactly the goal of gst.

It's not perfect, but hey, nothing is. At least it works.


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.




More information about the Gstreamer-bugs mailing list