[FFmpeg-devel] [PATCH] Stream specifier enhancement

Michael Niedermayer michael at niedermayer.cc
Wed Oct 28 17:32:55 CET 2015


On Sun, Oct 18, 2015 at 02:06:12PM +0200, Bodecs Bela wrote:
> 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.

i dont know which syntax is best but i agree with marton that the
initial patch was not optimal.
Also it seems the original patch changed the code quite deeply
it would be better independant of syntax to have a more minimal
change, that is if you intend to reimplement it anyway


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20151028/05fa95e6/attachment.sig>


More information about the ffmpeg-devel mailing list