Minor Rusty blockage
Locked
Minor Rusty blockage
 
|
Following the examples from GStreamer_Rs/examples, I added the
following in my playbin creation code: bus.add_watch(move |_, msg| { match msg.view() { gst::MessageView::Eos(..) => { println!("Got an EOS signal in GStreamer engine."); application.quit(); }, gst::MessageView::Error(err) => { println!( "Error from {:?}: {} ({:?})", err.get_src().map(|s| s.get_path_string()), err.get_error(), err.get_debug() ); application.quit(); }, _ => (), }; glib::Continue(true) } ); Sadly though this fails to compile, there seems to be some problem with the gst::MessageView::Error(err) bit – CLion/Rust doesn't recognise the Error, it does the Eos, and the compiler reports: error[E0599]: no method named `get_src` found for type `gst::message::Error<'_>` in the current scope --> src/gstreamer_engine.rs:52:33 | 52 | err.get_src().map(|s| s.get_path_string()), | ^^^^^^^ I'll wager I am just missing something obvious. Can anyone spot it? -- Russel. ========================================== Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
signature.asc (849 bytes)
Re: Minor Rusty blockage
|
|
Re: Minor Rusty blockage
|
|
On Thu, 2018-03-01 at 22:48 +0100, Mathieu Duponchelle wrote:
> That is surprising, this exact snippet of code should work, is it > possible that you don't > > actually use the latest version of gstreamer-rs? This function was > added > in July 2017, so > > quite some time ago, but worth making sure. I tend to use "*" as the version number and update frequently so I should always be on the latest version. Cargo.lock currently reports gstreamer at version 0.10.2, which seems about as up-to-date as it is possible to get using crates.io. I guess I could use the Git repository to be really up to date. :-) > > It would also make sense to share the entire source code if that is > possible, to > > make it easier to reproduce and spot the problem :) > The source code is at https://github.com/Me-TV/Me-TV_Rust Comment out the bus.add_watch call completely everything build fine. Comment out just the gst::MessageView::Error(err) => { … }, and the errors are all about thread safety, which is a bit irritating, but somewhat comprehensible. Uncomment the above and back to the original incomprehensible fail. :-( -- Russel. ========================================== Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Minor Rusty blockage
|
|
Hi Russel,
On Fri, 2018-03-02 at 12:33 +0000, Russel Winder wrote: > On Thu, 2018-03-01 at 22:48 +0100, Mathieu Duponchelle wrote: > > That is surprising, this exact snippet of code should work, is it > > possible that you don't > > > > actually use the latest version of gstreamer-rs? This function was > > added > > in July 2017, so > > > > quite some time ago, but worth making sure. > > I tend to use "*" as the version number and update frequently so I > should always be on the latest version. Cargo.lock currently reports > gstreamer at version 0.10.2, which seems about as up-to-date as it is > possible to get using crates.io. I guess I could use the Git > repository to be really up to date. :-) It might make sense (for applications!) to have the Cargo.lock in GIT and you update that manually whenever there are known-good versions. > > It would also make sense to share the entire source code if that is > > possible, to > > > > make it easier to reproduce and spot the problem :) > > > > The source code is at https://github.com/Me-TV/Me-TV_Rust > > Comment out the bus.add_watch call completely everything build fine. > Comment out just the > > gst::MessageView::Error(err) => { > … > }, > > and the errors are all about thread safety, which is a bit > irritating, but somewhat comprehensible. Uncomment the above and back > to the original incomprehensible fail. :-( https://github.com/sdroege/gstreamer-rs/blob/e6265341d56eeeda2f987a29c741f51ba5fb55d1/examples/src/bin/gtksink.rs#L71-L91 Problem is that GApplication is not thread-safe but the bus watch is going to be triggered from whatever thread the mainloop runs on. Which might in theory not be the same one where the GApplication was created. The compiler can't statically prove that. It would be unsafe to use a GApplication in another thread than the one where it was created. However in your application both are guaranteed to be the same. With SendCell you can move the thread-safety checks to runtime instead of compile-time. Similar to how RefCell does it with borrowing. For the other problem: you're using gstreamer-rs 0.10 but copied the message handler from GIT master. The API slightly changed for simplification. For 0.10 you need to do the following: https://github.com/sdroege/gstreamer-rs/blob/c7f5b541cc0923a71ccc89bf54954e3a03328994/examples/src/bin/gtksink.rs#L89-L95 That is, in 0.10 you have to get the source from the message itself while in GIT master (0.11+) you can also use all the message API from the different message views. -- Sebastian Dröge, Centricular Ltd · https://www.centricular.com _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Minor Rusty blockage
|
|
On Fri, 2018-03-02 at 16:21 +0200, Sebastian Dröge wrote:
> Hi Russel, > > On Fri, 2018-03-02 at 12:33 +0000, Russel Winder wrote: > > […] > > I tend to use "*" as the version number and update frequently so I > > should always be on the latest version. Cargo.lock currently > > reports > > gstreamer at version 0.10.2, which seems about as up-to-date as it > > is > > possible to get using crates.io. I guess I could use the Git > > repository to be really up to date. :-) > > Not the worst idea if you're prepared to keep up with API changes :) That is the idea. I'm all for latest good stuff, and I'm not tied to backward compatibility. > It might make sense (for applications!) to have the Cargo.lock in GIT > and you update that manually whenever there are known-good versions. I've never really understood this, if the idea is to fix a version shouldn't the version be fixed in the Cargo.toml? > > > […] > > Here is the solution for the thread-safety issue: > https://github.com/sdroege/gstreamer-rs/blob/e6265341d56eeeda2f987a29 > c741f51ba5fb55d1/examples/src/bin/gtksink.rs#L71-L91 > > Problem is that GApplication is not thread-safe but the bus watch is > going to be triggered from whatever thread the mainloop runs on. > Which > might in theory not be the same one where the GApplication was > created. > The compiler can't statically prove that. It would be unsafe to use a > GApplication in another thread than the one where it was created. your solution. > However in your application both are guaranteed to be the same. With > SendCell you can move the thread-safety checks to runtime instead of > compile-time. Similar to how RefCell does it with borrowing. > > > For the other problem: you're using gstreamer-rs 0.10 but copied the > message handler from GIT master. The API slightly changed for > simplification. For 0.10 you need to do the following: > https://github.com/sdroege/gstreamer-rs/blob/c7f5b541cc0923a71ccc89 > bf54954e3a03328994/examples/src/bin/gtksink.rs#L89-L95 > > That is, in 0.10 you have to get the source from the message itself > while in GIT master (0.11+) you can also use all the message API from > the different message views. Everything now in place and code compiling. Now on to dealing with the various source events of the playbin to get the gtksink overlaid and not creating a new window – assuming the strategy in C++ is still the right strategy of course :-) Thanks for the commentary, it makes the code meaningful – I wasn't really comprehensing some of the code till your comments. -- Russel. ========================================== Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Minor Rusty blockage
|
|
On Fri, 2018-03-02 at 17:34 +0000, Russel Winder wrote:
> > Now on to dealing with the various source events of the playbin to > get the gtksink overlaid and not creating a new window – assuming the > strategy in C++ is still the right strategy of course :-) If you use gtk(gl)sink, you don't need to do anything other than what the code I linked is doing. No events, no nothing, just setting some properties. It also will never open its own window. If you want to go the other way like you probably did in C++ with using the GstVideoOverlay interface, see https://github.com/sdroege/gstreamer-rs/blob/0.10/examples/src/bin/gtkvideooverlay.rs > Thanks for the commentary, it makes the code meaningful – I wasn't > really comprehensing some of the code till your comments. Feel free to send patches / PRs for the examples (to add comments) or improve the documentation :) -- Sebastian Dröge, Centricular Ltd · https://www.centricular.com _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Minor Rusty blockage
|
|
On Fri, 2018-03-02 at 20:53 +0200, Sebastian Dröge wrote:
> On Fri, 2018-03-02 at 17:34 +0000, Russel Winder wrote: > > > > Now on to dealing with the various source events of the playbin to > > get the gtksink overlaid and not creating a new window – assuming > > the > > strategy in C++ is still the right strategy of course :-) > > If you use gtk(gl)sink, you don't need to do anything other than what > the code I linked is doing. No events, no nothing, just setting some > properties. It also will never open its own window. thoughts in my head. Sorry. Setting the playbin video-sink should suffice, and then force-aspect-ratio, however… … in order to change the MRL being played (aka change channel of the DVB-T2) I have to connect to source-setup and thence to tuning-start, tuning-fail, and tuning-done. > If you want to go the other way like you probably did in C++ with > using > the GstVideoOverlay interface, see > https://github.com/sdroege/gstreamer-rs/blob/0.10/examples/src/bin/ > gtkvideooverlay.rs I ran away from all that X11 stuff, I am assuming Wayland and use of the widgets as above. > > Thanks for the commentary, it makes the code meaningful – I wasn't > > really comprehensing some of the code till your comments. > > Feel free to send patches / PRs for the examples (to add comments) or > improve the documentation :) Wilco. But first getting something playing again… -- Russel. ========================================== Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
| Free forum by Nabble | Edit this page |