Pidgin crashes when trying to initiate a video call due to missing `encode` compatibility in libtheora. log: (21:04:05) mediamanager: gst pipeline error: Could not encode stream. (21:04:05) mediamanager: Debug details: theoraenc.c(1007): theora_enc_chain (): /GstPipeline:pipeline0/GstBin:conf_0x2d43b90/FsRtpConference:fsrtpconference0/GstBin:discover_1_96/GstTheoraEnc:theoraenc0: libtheora has been compiled with the encoder disabled (21:04:05) mediamanager: gst pipeline error: Internal data flow error. (21:04:05) mediamanager: Debug details: gstbasesrc.c(2378): gst_base_src_loop (): /GstPipeline:pipeline0/GstBin:pidgindefaultvideosrc/GstBin:pidgindefaultvideosrc/GstGConfVideoSrc:gconfvideosrc0/GstBin:bin3/GstV4l2Src:v4l2src0: streaming task paused, reason error (-5) (21:04:05) GLib: gmem.c:136: failed to allocate 3382854549 bytes Fixed by recompiling libtheora with `encode` USE flag.
I could also name this bug: Having a "shoot yourself in foot" use flag is libtheora is stupid...
(In reply to comment #1) > I could also name this bug: Having a "shoot yourself in foot" use flag is > libtheora is stupid... > or simply depend on libtheora[encode]
I guess I could do that in gst-plugins-theora, but then there is no point in having that use flag anyway, since most desktop users will end up having gst-p-theora anyway. I still maintain that its a stupid use flag.
(In reply to comment #3) > I still maintain that its a stupid use flag. I don't need to encode theora on some boxes while I like to play the files; for me it is even more stupid to depend on it in gst-p-theora. The useflag won't change as long as upstream will support it, therefore if you want this to change: go and rant upstream.
Arg, and we can't do use deps in gst plugins because the eclass is moronic wasn't eapi2 compliant last I checked.. ARRG... Obviously, the theoraenc element shouldn't show up if theora wasnt build with encoding support.. But that stuff sadly doesn't exist in gst yet...
Can't you still do EAPI=2 and add empty src_configure() { :; } to the ebuild and the USE dep even without the eclass being compatible?
that sounds evil to me...
(In reply to comment #1) > I could also name this bug: Having a "shoot yourself in foot" use flag is > libtheora is stupid... > Then will it make more sense to add USE=gstreamer flag to pidgin if this will keep crashing without USE=encode in media-libs/libtheora? if you think the fault is in gstreamer to handle such errors, i would suggest recompiling libtheora with encode once the user compiles pidgin with vv support until the issue on the other side will be reserved.
There is a USE=gstreamer flag on pidgin already
(In reply to comment #9) > There is a USE=gstreamer flag on pidgin already > of course i know it's there, but will it make more sense having that flag when pidgin will keep crashing as long as libtheora wasn't re-compiled with `encode' flag?
Created attachment 207698 [details, diff] EAPI 0, 1, 2 compability to gst-plugins-base.eclass
(In reply to comment #7) > that sounds evil to me... > It is. Ported gst-plugins-base eclass to EAPI="2", works also with "0" and "1". See attachment.
Created attachment 207699 [details, diff] eapi0, 1, 2 compat Forgot to remove one line, otherwise same.
Gnome also maintains gstreamer. Could you guys review change in eclass?
Imho, there shouldnt be a src_unpack for EAPI >= 2, since all it does it to call unpack ${A} Also, the ||die removed after the econf, did econf already die in older EABIs ?
(In reply to comment #15) > Imho, there shouldnt be a src_unpack for EAPI >= 2, since all it does it to > call unpack ${A} true, it is possible to export src_unpack only for EAPI=0,1, but IIRC at least gnome team prefers to see define it explicitly. > Also, the ||die removed after the econf, did econf already die in older EABIs ? It does so in all EAPIs so no need to add || die after econf.
Technically, gnome doesn't maintain gstreamer at all we just share some members with gstreamer team. OTOH, haven't tested the patch but it looks OK to me :)
gst-plugins-base.eclass.patch was commited as this is a good thing anyway. Now, I'm unsure what to do with initial problem. We need to depend on libtheora[encode] only in case gst-plugins-theora was built with theora USE flag. As a workaround it's possible to add check in pkg_setup. Is there better alternative?
(In reply to comment #18) > gst-plugins-base.eclass.patch was commited as this is a good thing anyway. Sorry, when did you join the gstreamer herd?
(In reply to comment #19) > (In reply to comment #18) > > gst-plugins-base.eclass.patch was commited as this is a good thing anyway. > > Sorry, when did you join the gstreamer herd? Bug was opened for more then one month with patch attached for review. No objections were raised and gnome herd member (that is mentioned in eclass too) approved this patch. Any problems with this patch?
And forgot to note that eclass with this patch lied in my overlay long enough (since 2009-12-17) to be considered workable.
It was stated that "Technically, gnome doesn't maintain gstreamer at all we just share some members with gstreamer team.". The problem is that this is a completely unrelated bug. It is not about making eclass EAPI-2 compatible, it's about theora stuff, and gstreamer is in CC, not assignee. I don't methodically scourge through all gstreamer bugs where we are merely in CC, so with no activity on this in my e-mail account from no comments for 8 months and the first activity after 8 months being already a report of committing it - obviously it wasn't in the radar of gstreamer herd members anymore. The main problem is that the action is incomplete - it is not a good idea to just have it applied like that to gst-plugins-base.eclass. We have at least three more eclasses that must be similarly in sync. Additionally this change claims it supports EAPI-3, which it does NOT.
Anyway, lets better get productive. I'll review and tweak the change and apply something to the other eclasses as well soon. So as I understand it, the perfect solution might be if the upstreamer plugin wouldn't advertise theoraenc element at all if the underlying libtheora is built without support? Alternatively, maybe a USE=encode on gst-plugins-theora, but I sort of like the automatic working of it right now... How does pidgin create the pipeline? Can't it react to the failure and not use theora encoding then, instead of crashing?
Mart, for eclasses I've opened new bug 332619. For pidgin, I'll check the code and come back later.
Any news from the pidgin pipeline side?
Olivier, did I understood your intentions correctly that you want to add encode USE flag into gst-plugins-theora and then pidgin depend on gst-plugins-theora[encode]?
Weren't you going to check into why pidgin crashes on it instead of cleanly getting gstreamer core to post missing-plugins bus message and not using theora for video then, etc? (not that gentoo can do with missing-plugins message anything yet, but at least wouldn't crash, but in the future we'll eventually get that support)
Moved gst-plugins-theora to EAPI2 and added a dep on libtheora[encode] I still want to maintain that the encode use flag in libtheora is moronic.
Mart, I've opened upstream ticket http://developer.pidgin.im/ticket/13504
Dani, could you gather full backtrace for latest version of pidgin, so I could reopen upstream bug report? TIA
Hello all, I installed pidgin 2.7.11 and recompiled libtheora 1.1.1 without encode. Now that pidgin didn't crash this time, but I got some message in the IM window: (14:44:15) A non-recoverable Farsight2 error has occurred. (14:44:15) The call has been terminated. and in Debug window this: (14:25:55) jingle: Creating hash table for sessions (14:25:55) jingle: inserting session with key: purple244750b8 into table (14:25:55) jabber: setting param stun-ip for stream using Google auto-config: 91.121.109.155 (14:25:55) jabber: setting param stun-port for stream using Google auto-config: 3478 (14:25:55) mediamanager: Couldn't read fs-element.conf: No such file or directory (14:25:55) backend-fs2: Couldn't read fs-codec.conf: No such file or directory (14:25:55) backend-fs2: Creating hash table for sessions (14:25:55) backend-fs2: connecting pad: success (14:25:55) backend-fs2: Creating hash table for participants (14:25:55) media: Creating hash table for sessions (14:25:55) gtkmedia: state: 0 sid: audio-session name: (null) (14:25:55) jingle-rtp: state-changed: state 0 id: audio-session name: (null) (14:25:55) gtkmedia: state: 0 sid: (null) name: NONAME@gmail.com/E4B568A6 (14:25:55) jingle-rtp: state-changed: state 0 id: (null) name: NONAME@gmail.com/E4B568A6 (14:25:55) gtkmedia: state: 0 sid: audio-session name: NONAME@gmail.com/E4B568A6 (14:25:55) jingle-rtp: state-changed: state 0 id: audio-session name: NONAME@gmail.com/E4B568A6 (14:25:55) jabber: setting param stun-ip for stream using Google auto-config: 91.121.109.155 (14:25:55) jabber: setting param stun-port for stream using Google auto-config: 3478 (14:25:55) backend-fs2: Couldn't read fs-codec.conf: No such file or directory (14:25:55) backend-fs2: connecting pad: success (14:25:55) gtkmedia: state: 0 sid: video-session name: (null) (14:25:55) jingle-rtp: state-changed: state 0 id: video-session name: (null) (14:25:55) gtkmedia: state: 0 sid: video-session name: NONAME@gmail.com/E4B568A6 (14:25:55) jingle-rtp: state-changed: state 0 id: video-session name: NONAME@gmail.com/E4B568A6 (14:25:55) backend-fs2: got new local candidate: 1 (14:25:55) backend-fs2: got new local candidate: 1 (14:25:55) backend-fs2: farsight-component-state-changed: component: 1 state: GATHERING (14:25:55) backend-fs2: farsight-component-state-changed: component: 2 state: GATHERING (14:25:55) backend-fs2: got new local candidate: 2 (14:25:55) backend-fs2: got new local candidate: 2 (14:25:55) jingle-rtp: jingle_rtp_candidates_prepared_cb (14:25:55) jingle: jingle_iceudp_finalize (14:25:55) jingle: jingle_transport_finalize (14:25:55) backend-fs2: got new local candidate: 3 (14:25:55) backend-fs2: got new local candidate: 3 (14:25:55) backend-fs2: farsight-component-state-changed: component: 1 state: GATHERING (14:25:55) backend-fs2: farsight-component-state-changed: component: 2 state: GATHERING (14:25:55) backend-fs2: got new local candidate: 4 (14:25:55) backend-fs2: got new local candidate: 4 (14:25:55) jingle-rtp: jingle_rtp_candidates_prepared_cb (14:25:55) jingle: jingle_iceudp_finalize (14:25:55) jingle: jingle_transport_finalize (14:25:56) backend-fs2: farsight-error: 1: Error while discovering codec data, discovery cancelled (14:25:56) media: A non-recoverable Farsight2 error has occurred. (14:25:56) gtkmedia: state: 2 sid: audio-session name: NONAME@gmail.com/E4B568A6 (14:25:56) jingle-rtp: state-changed: state 2 id: audio-session name: NONAME@gmail.com/E4B568A6 (14:25:56) gtkmedia: state: 2 sid: video-session name: NONAME@gmail.com/E4B568A6 (14:25:56) jingle-rtp: state-changed: state 2 id: video-session name: NONAME@gmail.com/E4B568A6 (14:25:56) gtkmedia: state: 2 sid: video-session name: (null) (14:25:56) jingle-rtp: state-changed: state 2 id: video-session name: (null) (14:25:56) gtkmedia: state: 2 sid: audio-session name: (null) (14:25:56) jingle-rtp: state-changed: state 2 id: audio-session name: (null) (14:25:56) gtkmedia: state: 2 sid: (null) name: NONAME@gmail.com/E4B568A6 (14:25:56) jingle-rtp: state-changed: state 2 id: (null) name: NONAME@gmail.com/E4B568A6 (14:25:56) gtkmedia: state: 2 sid: (null) name: (null) (14:25:56) gtkmedia: pidgin_media_dispose (14:25:56) gtkmedia: pidgin_media_dispose (14:25:56) gtkmedia: pidgin_media_finalize (14:25:56) jingle-rtp: state-changed: state 2 id: (null) name: (null) (14:25:56) media: purple_media_dispose (14:25:56) backend-fs2: purple_media_backend_fs2_dispose (14:25:56) backend-fs2: purple_media_backend_fs2_finalize (14:25:56) media: purple_media_finalize dns[6524]: nobody needs me... =(
re-emerge gst-plugins-theora.. and you see it wont work becauase it needs the encode use flag... Seriously.. This use flag is moronic, it shouldnt even exist.
Yeah, true, emerging gst-plugins-theora requires libtheora to be built with the encode flag, but at least this time pidgin doesn't crash..
