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

[GStreamer (bugzilla.gnome.org)]

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


Edward Hervey changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bilboed at bilboed.com




------- Comment #5 from Edward Hervey  2006-01-24 14:12 UTC -------
Ronald, as you mention in your latest comment, single-image streams and video
streams should be handled differently... "at a playbin level".

It is slightly problematic to do that separation at the demuxer level, since:
 * the image is not stricly metadata (take the case of jpeg in quicktime, which
is a completely normal way of distributing images (the data)).
 * if somebody wants to use that image in a gstreamer pipeline (eventually with
or without the other contained streams) he no longer can use that data in a
pipeline (unless doing some complicated/uncommon pipeline that takes the
GstBuffer from the Tag and injects it into another pipeline).

It is another case for playbin. Here you could figure out that a decodebin pad
with video/x-raw-yuv or video/x-raw-yuv with a framerate of 0 (or without a
framerate), is a single picture. Connect a fakesink with 'handoff', and playbin
actually emits that GST_TAG_IMAGE.

Like that all playback applications using playbin (totem, rhythmbox, etc...)
would see the image as a tag, and at the same time not stopping other
applications from being able to use that image stream.

I just commited a couple of fixes to qtdemux 0.10 that makes it create that
extra pad with framerate=(GstFraction)0/1.

The idea of GST_TAG_IMAGE is really good though, something tells me Jan is
going to implement it in 0.10 core/id3demux :)


-- 
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.