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

[totem (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=641047
  totem | GStreamer backend | unspecified

Mark Nauwelaerts <mnauw> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|gst-plugins-bad             |GStreamer backend
            Version|0.10.21                     |unspecified
         AssignedTo|gstreamer-bugs at lists.source |totem-gstreamer-maint at gnome
                   |forge.net                   |.bugs
            Product|GStreamer                   |totem
   Target Milestone|HEAD                        |---
          QAContact|gstreamer-bugs at lists.source |totem-gstreamer-maint at gnome
                   |forge.net                   |.bugs

--- Comment #4 from Mark Nauwelaerts <mnauw at users.sourceforge.net> 2011-02-01 16:38:15 UTC ---
(In reply to comment #3)
> (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?

mpegaudioparse (or anything) has no way to detect (constant) bitrate
instantaneously (though we may know that it is).  Neither does mp3parse, it
just happens to jump quicker to a conclusion (the downside of that being that
it may be less reliable in some cases, though the examination period might be
tweaked slightly in mpegaudioparse also).

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

Yes, it seems mpegaudioparse affects the "mood" here, but little that it can do
or fix about that (afaik), so assigning to Totem to figure out what is
happening with tags (and the seeking part can tag along for now ...).

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