On Thu, 15 Oct 2015, Bodecs Bela wrote:
[...]
My enhancement does not alter the current behaviour in any way.
Are you sure? What if somebody matched a semicolon, or a string which
contained a semicolon in a metadata value? E.g.: m:timecode:00:00:00:00
This question still stands. Will the m:timecode:00:00:00:00 specifier work
the same way as it did after your patch? I think it will not.
[...]
I do not understand this. My patch only gives an opportunity to use
multiple specifiers in the same expression, it is not mandatory to use
it. The patch does not affect any existing command line in any way.
I don't agree, I think your patch changes existing behaviour and the
proposed syntax limits future extensibility.
I also accept your concern about the future, but double semicilon always
will works for optional parameters. But may I ask: would it be better to
introduce a "special character" for separating specifiers in the same
expression?
IMHO yes. You also have to know from the start that you are dealing with a
complex specifier, in order not to break existing simple specifiers.
I accept it if you suggest one. I only need the functionality to be able
to give more criteria to select a stream as opposed to current
oppurtunities. I am not stuck to my suggestion.
Anyway, You may see my enhancement as you get many optional parameters
for the existing type, metadata and program_id specifiers. :)
It can be anything if it does not change existing behaviour, a complex
specifier can be split to basic specifiers without worrying about the
syntax of the basic specifier and if there is a well defined rule for
escaping special characters. Also if it is readable to the user, that is a
plus.
The exact solution can be a bit about personal taste as well, but maybe
something like
(specifier)(specifier)
or
+specifier+specifier
can work and is readable. Knowing that you are dealing with a complex
expression also means that the special characters separating the basic
specifiers needs escaping, I guess av_get_token can be used to get the
proper unescaped basic specifiers when parsing the complex one.
Regards,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
