Dear Marton Balint,
see may comments below.
2015.10.18. 1:10 keltezéssel, Marton Balint írta:
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
yes, indeed.
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.
ok.
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)
I like this version. So, there would be the original case: specifier,
and if you want to use more specifier, you should put each of them into
parenthesis (round brackets): (specifier)(specifier)
I think it really won't break any current code
or
+specifier+specifier
I think () is more readible and rarely used in specifiers. If it is ok
for you and others I would implement it.
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
best regards,
bb
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
