Le lundi 20 juillet 2020 à 10:31 +0200, Philipp Zabel a écrit : > > Considering how buggy and inconcistent this is going to be in decoder drivers, > > I'm tempted to just drop that restriction in GStreamer v4l2 decoders (was added > > by Philippe Normand from Igalia). Specially the bitrate limits, since it is > > quite clear from testing that this limits is only related to real-time > > performance, and that offline decoding should still be possible. Meanwhile, the > > driver should still advertise 4.1 and 4.2 decoding. But we should check the > > decoding/encoding levels are actually not the same, that I haven't checked, the > > code is a bit ... kindly said ... hairy. > > > I think negotiation is important for sources that can provide multiple > levels, to choose the right level for the decoder. If there is a given > stream with a fixed level, it might indeed be better to not fail > negotiation (maybe have a warning instead) and just hope for the best, > as for some streams it might just work. Yes, agreed, but I didn't want to use the linux-media list to discuss GStreamer designs. I have a soltion for that, I'll send a MR and will CC you. For the general idea, I'll try and keep the levels as "preferred" capabilities while allowing any levels. Same mechanism used to proposed an unscaled display resolution, even though scaling might be supported. Nicolas
Attachment:
signature.asc
Description: This is a digitally signed message part
