[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





------- Comment #7 from Edward Hervey  2006-01-24 15:28 UTC -------
(In reply to comment #6)
> 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.

  The caps are buffer properties in 0.10, so that's one problem solved. As for
getting a 'useable' buffer, you could also do 'ffmpegcolorspace !
video/x-raw-rgb,... ! fakesink' to get a buffer that would be more convenient
to convert to a GdkPixbuf.
  MyPixbuf = g_object_new (GDK_TYPE_PIXBUF, "height", bufferheight, "width",
bufferwidth, "pixels", GST_BUFFER_DATA(buffer), ...);

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

  Images aren't video. But the only difference is one has only one frame, and
the other more than one. The problem is of course for end users, which is why
we shouldn't impede developers who know the difference between the two and who
should decide what to do with it, by doing the fix in playbin.

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

  I completely agree for id3. An image in id3 is a metadata.

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

  Convenience is *the* goal of gst ? Or is it the goal of playbin ? I thought
being versatile was the goal of a multimedia framework, and it was up to
convenience elements to simplify life of developers *IF* they want too.

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

  I don't think we'd be hacking on anything if everything was perfect in gst :)
Once I have time I'll implement that behaviour in decodebin 0.10 and see how
far it can go.


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