[FFmpeg-devel] [PATCH] Stream specifier enhancement

Bodecs Bela bodecsb at vivanet.hu
Thu Oct 15 10:50:07 CEST 2015

Dear Marton Balint,

thank you for your feedback. See my comments below.

2015.10.14. 1:20 keltezéssel, Marton Balint írta:
> On Tue, 13 Oct 2015, Bodecs Bela wrote:
>> Dear Marton Balint,
>> 2015.10.12. 23:07 keltezéssel, Marton Balint írta:
>>> On Mon, 12 Oct 2015, Bodecs Bela wrote:
>>>> Dear All,
>>>> currently stream specifiers may contain stream index, stream type,
>>>> stream id, program id, metadata key/value es usable config settings.
>>>> But you can not combine them. In some case, mainly working with
>>>> multiprogram mpeg-ts containers as input, this feature would be handy.
>>>> This patch makes it possible to combine them.
>>>> Examples: p:601:a  will select all audio streams of program 601,
>>>> a:m:language:hun will select all audio streams marked by its metadata
>>>> as hun language,
>>>> p:604:v:0  will select first video stream of program 604,
>>>> a:m:language:hun:0 will select 1st audio streams with hun language.
>>>> p:403:s:0 will select the first avaiable sub_title tream of program 
>>>> 403,
>>>> and p:403:s:m:language:hun:0  will select the first hungarian language
>>>> sub_title stream of program 403.  To select first hungarian language
>>>> audio stream a:m:language:hun:0
>>>> The order of sub-specifiers (program/type/metadata/usable_config) is
>>>> arbitrary. So, you may also write v:p:604:0 to select first video 
>>>> stream
>>>> of program 604
>>>> Please consider to put this enhancement into the official ffmpeg code.
>>> I like the idea, but are you sure just concating the specifiers is a 
>>> good approach?
>>> For example, what will the following mean?
>>> m:language:u
>>> All usable streams with language metadata or streams where the 
>>> language metadata is 'm'?
>> Thank you for you like my idea.
>> The current stream specifier syntax is very robust, easy to parse and 
>> easy to use. I would not introduce any new
>> syntax for applying multiple criteria in the stream specifier 
>> expressions. On the other hand, there are only few people,
>> who really needs this multiple criteria feature. 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
>> So most of the users will not notice anything. But those who really 
>> need it, they will appreciate it.
>> So, I think, by making possible to concatenate  specifiers inside 
>> stream specifier expressions is a natural way to
>> extend the current syntax.
>> Regarding your example: m:language:u
>> This expression is right in the current applicable syntax, without 
>> any enhancement. It means "all streams where the language metadata is u"
>> To select "streams where the language metadata is 'm'? " you should 
>> write  m:language:m
>> With my enhancement you can achive to select "All usable streams with 
>> language metadata" as you wrote:
>> (more precisely I think you mean: all usable stream where there 
>> exists language metadata independently its value)
>> u:m:language  or m:language::u
> Sorry, I wasn't clear because I mistyped my question, I wanted to ask 
> for a stream with language metadata 'u'.
> I was referring to the problematic nature of the optional parameters 
> that can/may be interpreted as a different specifier.
> How do you specify a usable stream with language metadata?
> m:language:u or m:language::u
You may use "u:m:language"   (because the order of specifiers is 
arbitrary) And the user need not to specify the optional parameter.
> Apparently in this case the user has to specify the optional parameter 
> as well for the metadata (double semicolon) because otherwise it will 
> not work. So the parameter is not so optional anymore.

But I think you misundestand  the situation. The string "m:language:u" 
will work as now, nothing has changed in this field.
> This will also bite you if you want to extend an existing specifier 
> with an optional parameter later, the specifier which used to work 
> suddenly 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 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 
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. :)

In my first version I added this feature to program_id specifier only, 
but then I concluded that it can be used universaly.
If you want, I can restrict the usage of this new opportunitiy only for 
those cases, where additional specifiers are used after program_id 
specifier. So, it will be optional extra specifiers of program_id 
speficiers, only.

> Regards,
> Marton
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

best regards,

More information about the ffmpeg-devel mailing list