[FFmpeg-devel] [PATCH] Stream specifier enhancement

[Bodecs Bela]

ping

2015.10.18. 14:06 keltezéssel, Bodecs Bela írta:
> 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 at ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> best regards,
>
> bb
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel