Open NSQY opened 1 year ago
Definitely possible to extend the current design to support this case as well, but I'm worried about the inconsistency in API.
for int/float frame properties, it's fair to limit x.Prop
to accessing only first element of the respective property, even if it's an array, as more often than not those are scalar anyway (e.g. x._Combed
or x.PlaneStatsAverage
).
However, for frame props of the bytes type, usually they are strings (and have more than 1 bytes), so I'm worried that just reading the 1st byte is too limited and counter intuitive.
Of course, this dilemma could be solved by introducing x.prop[1]
syntax, but so far I'm unable to come up with a performant implementation that supports dynamic indexing of frame property arrays.
@NSQY I'm curious, what's the use case for accessing _PictType
in Select
?
@AkarinVS Simple problems such as files with heavily damaged frame types (often IDR frames) where the encoder has failed.
I was also hoping to replace the eval here: https://gist.github.com/NSQY/247319b6081240b431030cee8ca3b835
Example of a function with frametype support: https://github.com/OpusGang/adptvgrnMod/blob/e5a4cb619503eb1ea6380993cff7305b22940513/adptvgrnMod.py#L129-L139
Replacing FrameEval
that creates new filter instances will definitely be out of scope for the plugin. However, I suggest that you use a previewer that can display user defined frame property in the status area so that you don't need to overlay the frame type property onto the video frames.
The frmtpgrn
example could indeed be easily replaced as long as the three functions funcB
, funcP
and funcI
are static and can be called beforehand then use Select
to select from one of them using _PictType
as key.
Will consider extending Select
to read the first byte of bytes frame properties.
Is it possible to handle _PictType ('I', 'P', 'B') within the expression?