[gstreamer-bugs] [Bug 641047] [mpegaudioparse] Multiple issues with new mpegaudioparse element from -bad, lower rank?

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=641047
  GStreamer | gst-plugins-bad | 0.10.21

--- Comment #3 from Hans de Goede <jwrdegoede at fedoraproject.org> 2011-01-31 18:18:06 UTC ---
(In reply to comment #1)
> For the seeking case there is actually an improvement in mpegaudioparse that
> makes it (baseparse) wait a (slight) while to come up with a reliable duration
> estimate.

Ok, but since the file in question is a fixed bitrate file (AFAIK), and the
filesize is known this should not be necessary, or am I missing something here?

  However, it happens that Totem queries for seekability during this
> short interval, and baseparse reports (cautiously) "not seekable" (since not
> knowing a duration yet).  After initial query, Totem does not query again, and
> so the clip is believed not seekable.
> 
> As such, it depends on the precise (undefined?) semantics of QUERY_SEEKING. 
> Should an application query multiple times, or is the first TRUE answer to hold
> for ever?  Anyway, possible patch to follow that will have baseparse return
> FALSE to the query as long as it does not have a duration and there might still
> be a chance it can handle seeking.  It is then to be hoped that "failing to
> handle the query" does not confuse other players/frameworks out there and is
> actually a valid response in such case.

Ok.

> 
> As the artwork, that is actually extracted by another element (id3demux), and
> still works fine (using gst-launch-0.10) when mpegaudioparse is used:
> ----
> Setting pipeline to PAUSED ...
> Pipeline is PREROLLING ...
> FOUND TAG      : found by element "id3demux0".
>            title: Glimmer (Album Version)
>           artist: Garmisch
>            album: Glimmer
>             date: 2010-01-01
>     track number: 1
>            genre: Electropop
> container format: ID3 tag
>         duration: 1537158784000000
>      ID3v2 frame: buffer of 30 bytes, type: application/x-gst-id3v2-tden-frame,
> version=(int)4
>                 : buffer of 30 bytes, type: application/x-gst-id3v2-tdtg-frame,
> version=(int)4
>      track count: 6
>        copyright: This work is licensed under a Creative Commons
> Attribution-Noncommercial-No Derivative Works 3.0 License
>            image: buffer of 913258 bytes, type: image/png,
> image-type=(GstTagImageType)GST_TAG_IMAGE_TYPE_UNDEFINED
> FOUND TAG      : found by element "apedemux0".
> replaygain track gain: 0.925000
> replaygain track peak: 0.630134
> replaygain album gain: -0.695000
> replaygain album peak: 0.649180
> container format: APE tag
> FOUND TAG      : found by element "mpegaudioparse0".
>          bitrate: 192000
> FOUND TAG      : found by element "mpegaudioparse0".
>      audio codec: MPEG 1 Audio, Layer 3 (MP3)
> FOUND TAG      : found by element "mpegaudioparse0".
>          has crc: FALSE
>     channel mode: joint-stereo
> FOUND TAG      : found by element "mad0".
>            layer: 3
>             mode: joint
>         emphasis: none
>          bitrate: 192000
> FOUND TAG      : found by element "mpegaudioparse0".
>  minimum bitrate: 4294967295
>          bitrate: 192000
>  maximum bitrate: 0
> FOUND TAG      : found by element "mpegaudioparse0".
>  minimum bitrate: 192018
>  maximum bitrate: 192018
> Pipeline is PREROLLED ...
> Setting pipeline to PLAYING ...
> New clock: GstAudioSinkClock
> FOUND TAG      : found by element "mpegaudioparse0".
>  minimum bitrate: 191712
> ---
> Tags thrown by mpegaudioparse are slightly different than those by mp3parse,
> but Totem should still pick up what id3demux reports (which it seems to fail
> with more than only album art afaics).

I'm not a gstreamer expert, but I do know that the image tag is found by
id3demux :) However mpegaudioparse is doing something which has the end result
of totem no longer showing the album art. It could very well be that the cause
lies outside of mpegaudioparse, but if you play the file in question with a
fully up2date gstreamer stack including libgstaudioparsersbad.so it does not
get
shown, remove libgstaudioparsersbad.so so that mp3parse gets used instead and
the problem goes away.

-- 
Configure bugmail: https://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.