GNOME Bugzilla – Bug 760477
playbin: caps intersection autoplugs too early and stream stops
Last modified: 2016-01-20 14:31:21 UTC
Created attachment 318761 [details] gst-launch-debug-log Since gst-plugins-base commit : http://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?id=844aa3e6a954e76b68f0f0e6e5d829047b2d9f68 Some streams starts playing and stop after a while. example stream : http://wildhitz.rr.kpnstreaming.nl/b2b/vod/wildhitz/mp4s/Tech_N9ne_-_Strangeulation_Cypher/index.ism/index.m3u This on stb linux with openpli-50 or 40. included gst-launch log.
The debug log is not very useful, you need to enable more debug categories. As this is a general stream error you have to enable everything related to data flow and pads, and as this is related to playbin somehow additionally enable playbin:6,decodebin:6,uridecodebin:6.
Created attachment 318764 [details] Just before the commit it rins fine log Just before the commit or better with gst-plugins-base commit : http://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?id=c119715e252a0ad85878fa438a7e2c81706dd2d8 It runned fine.
Created attachment 318766 [details] reply needinfo here log with more debug untill freeze --gst-debug=dvbaudiosink:4,dvbvideosink:4,playbin:6,decodebin:6,uridecodebin:6,hls:5
You forgot all the data flow related things: GST_PADS:6,GST_SCHEDULING:6 at least.
Also having *:3 first would be useful to see where the error happens.
Created attachment 318768 [details] Stream stops debug *3 With debug 3
I meant all of those together: *:3,GST_PADS:6,GST_SCHEDULING:6,playbin:6,decodebin:6,uridecodebin:6
Created attachment 318787 [details] Extra log general *3 some 6 like asked I compressed the file it was to big as txt
That's maybe https://bugzilla.gnome.org/show_bug.cgi?id=758212 but I can't know for sure without more debug output. Please try the patches there
Created attachment 318811 [details] Here a full log stream ok before commit Here I just rebuild the full gstreamer all on head except the gst-plugins-base on last working commit : http://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?id=c119715e252a0ad85878fa438a7e2c81706dd2d8 Ok the stb suffers a bit from the to heavy debug. Trace is really to cpu intensif for a stb. But it worked a bit. What a well can tell is that with that media (and this goes up for half media which needs top be streamed) We first start with a lower resolution up to receiving an updated cap for resolution. It's when the new resolution or right resolution is applied it stops. after last good working commit. Ok I can try with the bug You mentioned above but now You also have a full log to compare.
I need a full debug log not when it was ok but with the bug you observe :)
Created attachment 318827 [details] Stream stops debug Here again the full log gstreamer is full up to date gst-plugins-base at commit 2f7cd8608ac9b680aae4f5312c9cd003aafe805e stream stopped playing after a couple off seconds. log made with : --gst-debug=*:3,GST_PADS:6,GST_SCHEDULING:6,playbin:6,decodebin:6,uridecodebin:6
Created attachment 318839 [details] Dvbmediasink with ok playback.so This to see what happens with caps. Here can be seen the caps sended with the right resolution. It is accepted and applied all runs fine.
Did you also try the patches I was mentioning before. Maybe we can stop wasting both our times here if it's indeed the same bug and things just work after applying the patches.
Created attachment 318840 [details] dvbmediasink playback.so not ok Here can clearly be seen that the cap is not accepted and instead off a caps event an error is issued. Result media stops. the same thing happens also with : uri=http://live.rpctv.com/rpctv/tm.smil/playlist.m3u8
Is that with the patches I mentioned?
Created attachment 318842 [details] dvbmediasink log playback.so still not ok Here the one with patches You mentionned. Caps are still not accepted The patches applied are Revert "playbin: only add the template caps when the result Subject: [PATCH] playbin: Only append non-raw and sysmem pad template caps to
Perhaps adding something just opposed like now. If video caps raw then query and it will be fine for totem and all pc's devices using video-raw. For all other case just like before accept-cap. All devices who are working with own codecs will run fine also.
Thanks, I'll take a look at the log later :)
Those 2 last logs only contain GST_DEBUG=3 which is rarely enough to debug something. Please provide at least "-gst-debug=*:3,GST_PADS:6,GST_SCHEDULING:6,playbin:6,decodebin:6,uridecodebin:6"
Maybe this is a gst_caps_can_intersect vs gst_caps_is_subset thing? A log containing also GST_CAPS:6 could make it a bit easier to see what is happening
2 last two logs are complementary to the First complete ones. 1) before the regression commit:(full debug) 2) after regression commit.(full debug) 3 complementary to one 4 complementary to 2. The seconds two are to show exactly what happens and that simple the caps are not accepted. And I'm so what shure You may not launch a caps-query there. And that's cause we are using own codecs. This problem You will have for those streams for all devices using own codecs. What is done in http://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?id=844aa3e6a954e76b68f0f0e6e5d829047b2d9f68 Is only applicable for devices using audio/video raw obtained by gstreamer codecs convertion. I now just wil also make a full log with the patches You told to apply and which do not work just same error always. Then post it when made.
Just adding some context to this change: accept-caps query are shallow checks, they only verify that the next element in the pipeline branch accepts that caps. So if you have some other element further downstream it will be ignored by accept-caps queries. Using a caps query makes sure that it will consider the whole pipeline branch. For example, if you have: capsfilter caps=ANY ! videosink an accept-caps query in capsfilter's sink pad will always accept any type of caps. In this case what we really want is to know what videosink actually can support so a caps query is needed.
Created attachment 318873 [details] Full debug log with patches Here the full debug with the proposed patches. Does not work.
No we are working with own codecs then You may not query all the elements, there are no further elements in our case. So the query may only be done when incase you are using gstreamers decoding elements. The logs just prove's that. Before it worked perfect and the cap is in this case only and only for the videosink (customed sink required by dvbapi) . And has nothing to do further. That's why You must accept. The patch is only valid for devices who are using gstreamer codecs and convertions . We can't to that anyway for video even if they would implement (which is not aloowed by stb dvbapi ??? they tell) the cpu power would not be enough to do the convertions of HD video.
Created attachment 318877 [details] [review] playbin: use subset check instead of intersect Can you check whether this patch improves the situation?
It's now building. But to mention we are not using audiosink or videosink but a customized own sink. dvbaudiosink and dvbvideosink.
actually just a question. since we do not use the videosink or audiosink , could we trie to call out sinks videsink or audiosink ? gues not.
Created attachment 318883 [details] Log ok after patch from application and relevant dvbmedisinks With the last patch it does work back ok. I included a log from run with application. There You see only our happenings into the customized sink's and the application standard debug. If You wish I can also make a full debug with gst-launch.
I mean it works ok with the last patch off Thiago. https://bugzilla.gnome.org/attachment.cgi?id=318877&action=diff
(In reply to christophe vr from comment #28) > actually just a question. since we do not use the videosink or audiosink , > could we trie to call out sinks videsink or audiosink ? gues not. I don't understand what you mean by "try to call out" Anyway. playbin is made to work with custom sinks as well and it has been used for that already.
I met call them , but indeed normally that should not be the problem since like You said playbin is used by us.
Hello I think You can push the patch : https://bugzilla.gnome.org/attachment.cgi?id=318877&action=diff It work really back great. Thanks :) Can I mark bug as solved if its commited ?
Thanks for verifying it, we will mark it as resolved once the patch is merged. For now, we need to wait a bit to see if other people agree to this change.
Comment on attachment 318877 [details] [review] playbin: use subset check instead of intersect I think the patch makes sense, yes.
Comment on attachment 318877 [details] [review] playbin: use subset check instead of intersect OTOH this patch will break things if autoplug-continue is called with unfixed caps. IIRC there are code paths that do that (you can't call is_subsect() with unfixed caps as first argument).
(In reply to Sebastian Dröge (slomo) from comment #36) > Comment on attachment 318877 [details] [review] [review] > playbin: use subset check instead of intersect > > OTOH this patch will break things if autoplug-continue is called with > unfixed caps. IIRC there are code paths that do that (you can't call > is_subsect() with unfixed caps as first argument). Not disagreeing to this but accept-caps queries also require fixed caps.
Ah right, I think I changed the code at some point to only ask for fixed caps. Let's try to go with this then for now. It's also required for all elements that use the INTERSECT flag for the accept-caps query.
Maybe we should add some kind of recursive accept-caps query ;)
I'm not an expert but in our situation for the videosink we are limited to fixed caps only. The audiosink not.
Hello it's not that I want to rush up , but I have to do it. We are currently in application development using gstreamer. The current base image of stb is still using the very old gstreamer-0.1.xx And we come to a point now with a full new image named pli50. It does have the so what last lib's and projects avbl. Does use gcc-5.xx quit up to date by use off libc and... The linux kernel is depended on the stb manufacturers since it also included the closed source drivers and acces to the protected codecs. One off our major problems is gstreamer. It's anyway needed for our customized dvbmediasink . But the change over from 0.1xx to 1.xx did caused in first place severe regression into media support. Ok we came to gst-1.4.5 that was the first version without severe regression and even a couple off nice benefits for us. All our code (especially the costumed mediasink's ) was adapted to that. Then came 1.5.1 in general better but some new regressions in media support. After 1.5.1 perhaps some new extra support was there , but in general stability and support it was a regression this up to and including 1.7.0 . Then with 1.7.1 It's a extreme high improvement again. and all versions above the tagged 1.7.1 where each time a serious improvement until the commit: http://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?id=844aa3e6a954e76b68f0f0e6e5d829047b2d9f68 It's like we jumped again into darkness the result in media support is dropped again to even below the one using very old gst-0.1xx (which is modified with ton's off patches). Ok it's not easy and very tricky the caps issue but why commit for a improvement in totem and brake all other users by it ?
Don't forget that people here are helping you for free in their spare time, comments like this are not going to make it more likely that someone is going to care about your problems. If you want your priorities to be handled faster, you can always throw money at them or try to contribute yourself instead of complaining. Obviously nobody did the change you mention above to break all other software than totem. Thanks for reporting that it broke something (we were not aware of that before) but calm down and try to be constructive. Also that commit is not only fixing totem but also many other very common scenarios, the solution to this here is not going to be to randomly patch things but to try to understand why it fails and find a solution that solves all known cases instead of breaking other cases again and making your software work.
commit 81c52aaa1695cd1d0ca9004aa668b9ed85db2da9 Author: Thiago Santos <thiagoss@osg.samsung.com> Date: Tue Jan 12 11:31:50 2016 -0300 playbin: use subset check instead of intersect Elements usually require that all fields on their caps are present on the fixed caps they receive. Using intersection won't verify it, resort to using is_subset() checks. https://bugzilla.gnome.org/show_bug.cgi?id=760477
at Sebastian, First I'm one the persons which are helping for free and only work for free. I really dislike all the persons who take profit from others work to make money of it. at Thiago , Thanks for the solution :-)
Hi, Thanks for your time investigating and fixing this issue. AFAIK, it correct totem behavior in Rawhide. As it stands rawhide gstreamer1-plugins-base makes totem basically useless. Kinda sad for the workstation product. Is a point release containing the subset check work planned before f24 release, for packagers' sake? Should they backport the patch in the mean time> Thanks for your involvement !
Alexandre, yes, bugs like this are always unfortunate. 1.7.1 was a very early development release, and my understanding of rawhide is that its purpose is exactly to catch these kind of issues. 1.7.2 is planned for the near future, and we expect a stable 1.8 will be out long before F24. You'll have to take patching things up with the rawhide packagers.