After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 763553 - baseparse: Not pushing tags before PREROLL
baseparse: Not pushing tags before PREROLL
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
unspecified
Other Linux
: Normal blocker
: 1.7.91
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-03-12 23:11 UTC by thomas_d_j
Modified: 2016-03-15 07:42 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
baseparse: Recheck after pre_push_frame() if there are tags pending (1.29 KB, patch)
2016-03-13 08:37 UTC, Sebastian Dröge (slomo)
committed Details | Review
Revert "flacparse: push tags in pre_push_frame" (1.25 KB, patch)
2016-03-13 08:37 UTC, Sebastian Dröge (slomo)
committed Details | Review

Description thomas_d_j 2016-03-12 23:11:06 UTC
I think this may be a similar bug to https://bugzilla.gnome.org/show_bug.cgi?id=762660 but affecting other codec's.  For example:
aac: https://github.com/mopidy/mopidy/issues/935
mp3: https://github.com/mopidy/mopidy/issues/1474

It seems likely that <codec>_parse_pre_push_frame() may need a similar patch for all audioparsers in https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/audioparsers.
Comment 1 Sebastian Dröge (slomo) 2016-03-13 07:58:21 UTC
Yes:

gst-launch-1.0 filesrc location=/path/to/mp3 ! id3demux ! mpegaudioparse ! fakesink silent=false -v | grep -e "tag" -e "PREROLLED"

> Pipeline is PREROLLED ...
> /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = event   ******* (fakesink0:sink) E (type: tag (20510), GstTagList-stream, taglist=(taglist)"taglist\,\ title\=....

Without mpegaudioparse the tags are before "Pipeline is PREROLLED".
Comment 2 Sebastian Dröge (slomo) 2016-03-13 08:37:13 UTC
Created attachment 323780 [details] [review]
baseparse: Recheck after pre_push_frame() if there are tags pending

Many parsers are storing tags only in pre_push_frame(), if we wouldn't check
afterwards we would push buffers before those tags and a lot of code assumes that
tags are available before preroll.
Comment 3 Sebastian Dröge (slomo) 2016-03-13 08:37:20 UTC
Created attachment 323781 [details] [review]
Revert "flacparse: push tags in pre_push_frame"

This reverts commit 4065fcb80a49924b70f0c8fc159dec0ff47943a1.

flacparse should not push tags by itself, the base class is going to do that
while properly merging in upstream tags. It just didn't because of a bug in
the base class, which was hidden by this commit.
Comment 4 Sebastian Dröge (slomo) 2016-03-13 08:40:00 UTC
(In reply to Sebastian Dröge (slomo) from comment #2)
> Created attachment 323780 [details] [review] [review]
> baseparse: Recheck after pre_push_frame() if there are tags pending
> 
> Many parsers are storing tags only in pre_push_frame(), if we wouldn't check
> afterwards we would push buffers before those tags and a lot of code assumes
> that tags are available before preroll.

The main problem with this is now that we might push taglists twice. Once a non-complete one before pre_push_frame(), then a complete one after pre_push_frame(). I don't see a way to solve this as pre_push_frame() on its own might already push a buffer via gst_pad_push() and we have no way to intercept that.
Comment 5 Tim-Philipp Müller 2016-03-13 10:39:45 UTC
Maybe we need a way to 'queue' frames to push out in baseparse. That way you could queue header buffers to be pushed, and when you reach then end of the flac headers they can all be pushed in one go (after any events; and the tag events could be de-duplicated).
Comment 6 Tim-Philipp Müller 2016-03-13 10:45:58 UTC
> Maybe we need a way to 'queue' frames to push out in baseparse.

Actually we already seem to have that via GST_BASE_PARSE_FRAME_FLAG_QUEUE.
Comment 7 thomas_d_j 2016-03-13 10:55:22 UTC
While not ideal, I guess multiple pushes are preferable to no pushes.  Downstream apps can cope if they are aware of this possibility.  For example mopidy (if I'm reading its code correctly) already accumulates pushed taglists:
https://github.com/mopidy/mopidy/blob/af43612630892fc3cc8be9b0f13109b1a89b1198/mopidy/audio/scan.py#L212-L218

But if GST_BASE_PARSE_FRAME_FLAG_QUEUE can provide a neater solution then so much the better.
Comment 8 Sebastian Dröge (slomo) 2016-03-13 11:03:27 UTC
GST_BASE_PARSE_FRAME_FLAG_QUEUE does not help here, at least I don't see how they could be used in h264parse/h265parse (only parsers I see currently that directly push buffers, and vc1parse but ...).
Comment 9 Jan Schmidt 2016-03-14 10:48:16 UTC
In general, I think these patches make things better and should go in.

We can fix parsers that are pushing buffers themselves by giving them a way to do it via baseparse as a further improvement later
Comment 10 Sebastian Dröge (slomo) 2016-03-14 11:10:49 UTC
Let's go with that then for now.

commit 66e9e4c20291b91038a4dc2a112ca04fd6533192
Author: Sebastian Dröge <sebastian@centricular.com>
Date:   Sun Mar 13 10:33:13 2016 +0200

    Revert "flacparse: push tags in pre_push_frame"
    
    This reverts commit 4065fcb80a49924b70f0c8fc159dec0ff47943a1.
    
    flacparse should not push tags by itself, the base class is going to do that
    while properly merging in upstream tags. It just didn't because of a bug in
    the base class, which was hidden by this commit.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=763553


commit 87c0513569b92a34ca325ff1af61f9cbe3b29886
Author: Sebastian Dröge <sebastian@centricular.com>
Date:   Sun Mar 13 10:33:53 2016 +0200

    baseparse: Recheck after pre_push_frame() if there are tags pending
    
    Many parsers are storing tags only in pre_push_frame(), if we wouldn't check
    afterwards we would push buffers before those tags and a lot of code assumes that
    tags are available before preroll.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=763553
Comment 11 thomas_d_j 2016-03-15 02:49:02 UTC
Thanks all.

Should the same also be applied to the 1.6 branch?
Comment 12 Sebastian Dröge (slomo) 2016-03-15 07:42:07 UTC
Done :) Thanks for reporting & testing