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
expression?
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@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
best regards,
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel