I need to fiddle with the text flag of a playbin, so as to ensure no
subtitles. In C I believe (I have no experience) the useful symbol is GST_PLAY_FLAGS_TEXT in the GstPlayFlags enum. In C++ (which I have used) there is Gst::PlayFlags::PLAY_FLAG_TEXT to select out the relevant bit. The question is what is the right way of doing things in Rust. There is a commented out bit in: GStreamer_Rs/examples/src/bin/playbin.rs but it looks mightily manual and complex. -- 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) Download Attachment |
On Thu, 2018-02-22 at 15:30 +0000, Russel Winder wrote:
> I need to fiddle with the text flag of a playbin, so as to ensure no > subtitles. In C I believe (I have no experience) the useful symbol is > GST_PLAY_FLAGS_TEXT in the GstPlayFlags enum. In C you would either set the enum by string in the gst_util_set_object_arg() function (e.g. "text+native-audio"), or by integer (check gst-inspect-1.0 for the integer values of the flags), or by defining your own version of the GstPlayFlags enum, or by using the GObject enum/flags API directly. Plugin headers are not installed and not usable by applications. > In C++ (which I have > used) there is Gst::PlayFlags::PLAY_FLAG_TEXT to select out the > relevant bit. It's IMHO a mistake that the gstreamermm bindings are providing bindings for plugin types directly inside the bindings. As their existence is not guaranteed, which leads to all kinds of funny problems. See also https://bugzilla.gnome.org/show_bug.cgi?id=755395 > The question is what is the right way of doing things in > Rust. There is a commented out bit in: > > GStreamer_Rs/examples/src/bin/playbin.rs > > but it looks mightily manual and complex. The following are your options right now: 1) The commented out code here https://github.com/sdroege/gstreamer-rs/blob/4117c01ff2c9ce9b46b8f63315af4dc284788e9b/examples/src/bin/playbin.rs#L27-L35 would be the safe way of doing it and being able to know that you actually did things correctly. It also allows you to use any flag values that were added after the bindings release, etc. Check the Flags API in glib-rs for more details and some variations. 2) Alternatively you can do something like playbin.set_property_from_str("flags", "text+native-audio") or similar. But that has the problem that you won't know if any of the flags you set don't exist or you did typos. Also it does not easily allow you to set/unset specific flags, you always set the whole thing. 3) Or if you feel adventurous you can define your own copy of that specific C enum via the bitflags crate and then implement direct translation from that to GValues (requires all the relevant traits to be implemented). Then you can directly use playbin.set_property("flags", YourFlagsType::TEXT | YourFlagsType::NATIVE_AUDIO) That's the equivalent of "copying the enum" in C. 4) Or you can just set it by integer with two lines of unsafe code. It could make sense for doing a separate crate that provides such flags/enum types and wrappers around well-known plugin element types (playbin etc), but it should not be part of the main bindings. Maybe you want to start such a crate? Most of it could also be completely autogenerated by doing basically the same gst-inspect-1.0 is doing and then outputting code based on that. -- Sebastian Dröge, Centricular Ltd · http://www.centricular.com _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel signature.asc (1019 bytes) Download Attachment |
On Thu, 2018-02-22 at 18:01 +0100, Sebastian Dröge wrote:
> […] > > It's IMHO a mistake that the gstreamermm bindings are providing > bindings for plugin types directly inside the bindings. As their > existence is not guaranteed, which leads to all kinds of funny > problems. Ah, good point. I was seduced by the presence of the enum in the library headers. Querying the plugin for the values is clearly the right way forward. > […] > 1) > The commented out code here > https://github.com/sdroege/gstreamer-rs/blob/4117c01ff2c9ce9b46b8f63315af4 > dc284788e9b/examples/src/bin/playbin.rs#L27-L35 > would be the safe way of doing it and being able to know that you > actually did things correctly. It also allows you to use any flag > values that were added after the bindings release, etc. > > Check the Flags API in glib-rs for more details and some variations. OK this gives me the confidence to go this route. Whilst a bit verbose it is the right thing to do. > 2) > Alternatively you can do something like > playbin.set_property_from_str("flags", "text+native-audio") > or similar. But that has the problem that you won't know if any of the > flags you set don't exist or you did typos. Also it does not easily > allow you to set/unset specific flags, you always set the whole thing. This is though a quite intriguing, and arguably more self-documenting way of doing it. > 3) > Or if you feel adventurous you can define your own copy of that > specific C enum via the bitflags crate and then implement direct > translation from that to GValues (requires all the relevant traits to > be implemented). Then you can directly use > playbin.set_property("flags", YourFlagsType::TEXT | > YourFlagsType::NATIVE_AUDIO) > > That's the equivalent of "copying the enum" in C. I am constraining my adventurousness just now. I still do not know Rust well enough to be within my comfort zone, especially as I do not have a Rust expert to give me feedback on my code. > 4) > Or you can just set it by integer with two lines of unsafe code. > > > It could make sense for doing a separate crate that provides such > flags/enum types and wrappers around well-known plugin element types > (playbin etc), but it should not be part of the main bindings. > Maybe you want to start such a crate? > > Most of it could also be completely autogenerated by doing basically > the same gst-inspect-1.0 is doing and then outputting code based on > that. Thanks for keeping me on the straight and narrow with this. Much appreciated. I will soon have to tackle the MPEGTS API in GStreamer_Rs but not just yet, I need to get the playbin working as required which means tinkering with source events given the C++ code that works. -- 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) Download Attachment |
In reply to this post by Sebastian Dröge-3
On Thu, 2018-02-22 at 18:01 +0100, Sebastian Dröge wrote:
> […] > Check the Flags API in glib-rs for more details and some variations. It's not clear to me from the documentation, the difference between a "name" and a "nick" for a flag. -- 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) Download Attachment |
Le 25 févr. 2018 08:14, "Russel Winder" <[hidden email]> a écrit :
Its a bit backward in GST, but name matches the enum C name (if that name is public), otherwise the name is used like a human readable form. The nick is used for the parser (like in gst-launch) and follow vaguely the naming rules for properties. Its backward, since for properties it's the opposite (nick is a human readable short form).
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
On Sun, 2018-02-25 at 09:42 -0500, Nicolas Dufresne wrote:
> > > It's not clear to me from the documentation, the difference between > > a "name" and a "nick" for a flag. > > Its a bit backward in GST, but name matches the enum C name (if that > name is public), otherwise the name is used like a human readable > form. The nick is used for the parser (like in gst-launch) and follow > vaguely the naming rules for properties. Its backward, since for > properties it's the opposite (nick is a human readable short form). > For extra confusion it also depends on whether the enum/flag is public API (exposed in an installed header) or 'internal element' API. For public API it's like Nicolas says, because g-i/bindings use the 'name' part. For internal enums/flags we abuse the name part as a description. Compare the "flags" property and the "video-multiview- flags" property in "gst-inspect-1.0 playbin3" for example. Cheers -Tim -- Tim Müller, Centricular Ltd - http://www.centricular.com _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Free forum by Nabble | Edit this page |