[FFmpeg-devel] [PATCH] Stream specifier enhancement

[Marton Balint]

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

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.

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.

Regards,
Marton