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 726221 - typefind: no longer sends CAPS event? (regression?)
typefind: no longer sends CAPS event? (regression?)
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
1.2.3
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-03-13 07:58 UTC by zmafox
Modified: 2014-03-14 09:43 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
details of aiurdemux plugin (4.10 KB, text/plain)
2014-03-13 07:58 UTC, zmafox
Details
log without caps event in qtdemux (1.24 MB, text/plain)
2014-03-13 10:48 UTC, zmafox
Details
log file when revert the commit. (1.25 MB, text/plain)
2014-03-13 10:54 UTC, zmafox
Details

Description zmafox 2014-03-13 07:58:37 UTC
Created attachment 271689 [details]
details of aiurdemux plugin

I am porting gstreamer plugins from 1.0.9 to 1.2.3 and find out that demux could not receive caps event which was send from typefind element.
I uses a universal demux(aiurdemux) and many caps are available for demux's sink pad. Caps event should be send to the demux's sink pad to tell the file type so that i can load the library according to the type of file.

I checked the source code and find that there is a commit to remove the caps event and I want to know the reason because it breaks the rules of caps negotiation. If demux would not handle the caps event, they should drop the event themselves in event handler of sink pad.

attachment is the details of aiurdemux.

Steps to Reproduce:
gst-launch-1.0 playbin uri=file:///xxx.mp4

related commit:
gstreamer/gstreamer.git
commit 922815996f166f42a1ff148a5ef2561c97a5d973
Author: Sebastian Dröge <sebastian.droege@collabora.co.uk>
Date:   Mon Apr 29 12:39:20 2013 +0200

    typefind: Remove code that would cause caps to be sent twice

    Whenever we set typefind->caps we will also send a caps event downstream.
Comment 1 Nicolas Dufresne (ndufresne) 2014-03-13 09:26:56 UTC
(In reply to comment #0) 
> I am porting gstreamer plugins from 1.0.9 to 1.2.3 and find out that demux
> could not receive caps event which was send from typefind element.
> I uses a universal demux(aiurdemux) and many caps are available for demux's
> sink pad. Caps event should be send to the demux's sink pad to tell the file
> type so that i can load the library according to the type of file.

Note that while it works for most cases, aiurdemux is not as good as the GStreamer built-in demuxers. Specially on seeks. Also, it does not provide significant performance gain. My 2 cents, but I usually recommend not using it in GStreamer.
Comment 2 Nicolas Dufresne (ndufresne) 2014-03-13 09:30:33 UTC
(In reply to comment #0)

> I checked the source code and find that there is a commit to remove the caps
> event and I want to know the reason because it breaks the rules of caps
> negotiation. If demux would not handle the caps event, they should drop the
> event themselves in event handler of sink pad.

It removes duplicates, but should still send the caps event. If it was not sending it at all, nothing would work in GStreamer/playbin. This seems to be something on your side. Can you provide more details ?
Comment 3 zmafox 2014-03-13 10:05:41 UTC
I set the debug level to 6 for qtdemux and tried to find the log of "handling %s event", however, no event was found at all.
Qtdemux can only parses the file as mp4 format and it does not need to detect the streaming format, files can also be played with it.
Comment 4 Nicolas Dufresne (ndufresne) 2014-03-13 10:29:46 UTC
(In reply to comment #3)
> I set the debug level to 6 for qtdemux and tried to find the log of "handling
> %s event", however, no event was found at all.
> Qtdemux can only parses the file as mp4 format and it does not need to detect
> the streaming format, files can also be played with it.

Goog point, can you attach the logs please.
Comment 5 Nicolas Dufresne (ndufresne) 2014-03-13 10:30:38 UTC
Note, the pad should complain imho if caps event is missing.
Comment 6 zmafox 2014-03-13 10:48:14 UTC
Created attachment 271698 [details]
log without caps event in qtdemux
Comment 7 zmafox 2014-03-13 10:54:53 UTC
Created attachment 271699 [details]
log file when revert the commit.
Comment 8 Sebastian Dröge (slomo) 2014-03-13 23:08:50 UTC
FWIW, if typefind never sent the CAPS event decodebin would be completely broken. Will try to reproduce this tomorrow.
Comment 9 Sebastian Dröge (slomo) 2014-03-14 07:42:44 UTC
Actually this is correct behaviour. qtdemux will activate in pull mode, so typefind should not send any events at all to it. There was a bug previously that made it send events but that's not how it is supposed to be.

So what happens is
1) typefind activates itself in pull mode
2) typefind detects the type, sends a caps event on its srcpad and emits the type-found signal
3) decodebin catches the type-found signal, plugs qtdemux after typefind
4) qtdemux activates in pull mode, which deactivates typefind from pull mode and makes the caps event never arrive in qtdemux

If qtdemux wants to know the caps in pull mode, it must either detect them itself or do a caps query upstream.


What exactly is the problem here? :)
Comment 10 zmafox 2014-03-14 09:43:17 UTC
Thanks for your explanation.
I tried to query caps from peer pad in pull mode and it works.
Now, demux only need to receive caps event in push mode.