Bus: no binding for gst_bus_timed_pop_filtered()

There is currently no binding for gst_bus_timed_pop_filtered().

As I understand gstreamer/src/auto/bus.rs is generated. Is that a limitation of the generation tool? Could we consider implementing one manually?

The main reason for omitting that function is because I dislike it and it should IMHO be deprecated :)

GstMessageType once was a flags type but that changed in 1.4 (see GST_MESSAGE_EXTENDED). For all new message types this function simply does not work, and I don't intend exposing GstMessageType as a flags type in the Rust bindings (because it's none anymore). I'd be fine with exposing it as an enum though.

Together with that you could implement Bus::pop() and the like as an iterator if you wanted, and do something like:

for msg in bus.iter_timed(gst::CLOCK_TIME_NONE).filter(|msg| [gst::MessageType::Error, gst::MessageType::Eos].contains(msg.type_()) {
  match msg.view() {
    [...]
  }
}

Having iterators for pop and timed_pop seem useful in any case.

The function works just fine for extended types, just that you have to use GST_MESSAGE_EXTENDED in the flag mask rather than the specific type, and then you can switch/case/match on the specific type afterwards.

I don't think it's a good idea to expose this function in a different way in the bindings than it is in the C API, that's just confusing. Also, it's not useful with just a single enum and would inevitably lead to it being used wrongly.

The function works just fine for extended types, just that you have to use GST_MESSAGE_EXTENDED in the flag mask rather than the specific type, and then you can switch/case/match on the specific type afterwards.

Sure but that kind of defeats the point of filtering :)

I don't think it's a good idea to expose this function in a different way in the bindings than it is in the C API, that's just confusing.

That's also not what I'm proposing above. I wouldn't expose this function at all and let filtering (if wanted) be done with standard Rust tools: filtering an iterator (to be written) or a simple match statement.

Also, it's not useful with just a single enum and would inevitably lead to it being used wrongly.

What do you mean?

Sure but that kind of defeats the point of filtering :)

Not really, because the way you use this function is in simple tests or command line applications where you check for EOS | ERROR or ASYNC_DONE | ERROR or somesuch. Anything non-trivial you use a message handler and a main loop anyway.

What do you mean?

It would encourage people to use it to check for EOS instead of EOS | ERROR, for example.

Not really, because the way you use this function is in simple tests or command line applications where you check for EOS | ERROR or ASYNC_DONE | ERROR or somesuch. Anything non-trivial you use a message handler and a main loop anyway.

With an iterator you could do that via

let msg = bus
    .iter_timed(gst::CLOCK_TIME_NONE)
    .filter(|msg| [gst::MessageType::Error, gst::MessageType::Eos].contains(msg.type_())
    .next();

or one could add a filtered variant that instead works on an array of types.

The main problem really is that we don't have a proper flags type anymore.

It would encourage people to use it to check for EOS instead of EOS | ERROR, for example.

Yeah I wouldn't add a function that only takes a single enum value. But considering your above concern, anything working with an array of types makes it even less likely to do this wrong. EOS would be a single value, just like EOS | ERROR, but with an array you would have to provide [Eos, Error] and it would be more obvious here that you probably want (and that you actually can) provide multiple values.

See !194 (merged) for the iterators.

@gdesmott what exactly are you trying to use that function for, how do you want to use it?

I want to do exactly the error/EOS example you wrote above so this filter seems to be exactly what I need. Thanks!

added Enhancement label

Ok, I'll still leave this open in case someone wants to add some API that is closer to the corresponding C API.

mentioned in commit vivia/gstreamer-rs@73ca90dc

mentioned in merge request !257 (merged)

mentioned in commit vivia/gstreamer-rs@05d936fc

closed via merge request !257 (merged)

closed via commit 05d936fc