Conversation
msabiniok
force-pushed
the
RDI-3112
branch
8 times, most recently
from
767774e to
66d4526
Compare
fluster/decoders/gstreamer.py
Outdated
| decoder_params = "" | ||
| if optional_params: | ||
| for key, value in optional_params.items(): | ||
| decoder_params += f" {key}={value} " |
There was a problem hiding this comment.
Optional parameter names and values can't be translated 1-to-1 to an implementation's property name and value.
If a test vector requires a parameter to be configured, there is no guarantee that the ffmpeg and gstreamer decoders for that codec will use the same property name. The mapping from the optional parameter key name to the property name must be done in the decoder's implementation.
Let's imagine there is a test vector for AV1 that requires enabling a feature named cool_feature. The test vector will define cool_feature = true. The ffmpeg av1 decoder will map this into enable_cool_feature = 1 and the GStreamer AV1 decoder will map this into cool_feature_enabled = True.
The mapping from optional_params into a decoder property must be done in the decoder implementation, not in a generic way in the base class.
There was a problem hiding this comment.
Thanks @ylatuya . I was seeing this as a default behaviour implementation. If there is a bigger difference in values, someone may want to provide a separate test suite JSON for those cases or overwrite either decode() or gen_pipeline() functions, as is done in some cases, to achieve the desired behaviour.
If we do not want the defualt behaviour implementation, I can remove that part from decode functions so the optional_paras are available for the user for the purpose of overwriting base class functions.
There was a problem hiding this comment.
We should be able to define a test case once and let the encoder implementation configure itself to respect the parametrizations defined in the test case. I don't think they are useful as default values, because property names can vary between implementations, and there is no guarantee they are the same across implementations. This might end up hiding errors when properties are not set or raising runtime errors when properties don't exist, depending on the implementation.
Adding the capability to include an optional decoder parameters set for a specific test vector in the test suite definition. Optional parameters are utilized in the Decoder class decode function abstraction It's Decoder child class responsibility to handle the optional parameters.
2 participants
adding the capability to include an optional decoder parameters set for a specfic test vector in the test suite definition. optional parameters are part of Decoder class decode function abstraction and are applied in Gstreamer(Decoder) and Ffmpeg(Decoder) classes implementations. It's child class responsibility to handle the optional parameters.