Re: [FFmpeg-devel] [PATCH] Stream specifier enhancement

2015-10-28 Thread 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@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


best regards,

bb

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Stream specifier enhancement

2015-10-28 Thread Michael Niedermayer 
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


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Stream specifier enhancement

2015-10-28 Thread Marton Balint 


On Sun, 18 Oct 2015, Bodecs Bela wrote:

[...]

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


Yes, exactly.



+specifier+specifier

I think () is more readible and rarely used in specifiers.  If it is ok 
for you and others I would implement it.


Ok, it's fine by me.

Thanks,
Marton




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@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


best regards,

bb

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Stream specifier enhancement

2015-10-18 Thread Bodecs Bela 

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@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


best regards,

bb

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Stream specifier enhancement

2015-10-17 Thread Marton Balint 


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




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.


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)

or

+specifier+specifier

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@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Stream specifier enhancement

2015-10-15 Thread Bodecs Bela 

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

Re: [FFmpeg-devel] [PATCH] Stream specifier enhancement

2015-10-13 Thread Bodecs Bela 

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.
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



Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

best regards,

Bela Bodecs
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Stream specifier enhancement

2015-10-13 Thread 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
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Stream specifier enhancement

2015-10-12 Thread Bodecs Bela 

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.

best regards,

Bela Bodecs

>From cc1d8139a6341c386b776afea9d7b132abb5906f Mon Sep 17 00:00:00 2001
From: Bela Bodecs 
Date: Mon, 12 Oct 2015 22:27:40 +0200
Subject: [PATCH 1/1] Stream specifier enhancement

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 with 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

Signed-off-by: Bela Bodecs 
---
 doc/fftools-common-opts.texi |  24 +++-
 doc/formats.texi |  30 +++-
 libavformat/utils.c  | 317 ++-
 3 files changed, 268 insertions(+), 103 deletions(-)

diff --git a/doc/fftools-common-opts.texi b/doc/fftools-common-opts.texi
index 509c8bc..411b092 100644
--- a/doc/fftools-common-opts.texi
+++ b/doc/fftools-common-opts.texi
@@ -45,14 +45,17 @@ streams of this type.
 @item p:@var{program_id}[:@var{stream_index}]
 If @var{stream_index} is given, then it matches the stream with number @var{stream_index}
 in the program with the id @var{program_id}. Otherwise, it matches all streams in the
-program.
+program. @var{program_id} may be decimal number, hexadecimal number with 0x prefix and octal number with 0 prefix.
+
 @item #@var{stream_id} or i:@var{stream_id}
-Match the stream by stream id (e.g. PID in MPEG-TS container).
-@item m:@var{key}[:@var{value}]
+Match the stream by stream id (e.g. PID in MPEG-TS container). @var{stream_id} may be decimal number, hexadecimal number with 0x prefix and octal number with 0 prefix.
+
+@item m:@var{key}[:@var{value}[:@var{stream_index}]]
 Matches streams with the metadata tag @var{key} having the specified value. If
-@var{value} is not given, matches streams that contain the given tag with any
-value.
-@item u
+@var{value} is not given or empty, matches streams that contain the given tag with any
+value. 
+
+@item u[:@var{stream_index}]
 Matches streams with usable configuration, the codec must be defined and the
 essential information such as video dimension or audio sample rate must be present.
 
@@ -60,6 +63,15 @@ Note that in @command{ffmpeg}, matching by metadata will only work properly for
 input files.
 @end table
 
+You may arbitrarily combine program_id, metadata, stream type and usable configuration specifier inside a specifier expression and they evaluate as logical AND. For example, 
+@code{-map 0:p:601:a} would match all audio streams of program with PID value 601 (e.g. in a MPEG-TS container). But
+@code{-map 0:p:601:a:1} would match only the 2nd audio stream of the same program. 
+@code{-map 0:p:0x123:a:m:language:hun} would match all audio streams of program with PID 291 (0x123) but only those ones that have language metadata tag with hun value.
+To make sure you will get only one audio stream even in those cases when there are two audio stream in the program and both have hun metadat atag, you may use
+@code{-map 0:p:0x123:a:m:language:hun:0} to match only the very first one. The order of sub-specifiers are arbitrary when you combine them, so in the latter case you may write 
+ @code{-map

Re: [FFmpeg-devel] [PATCH] Stream specifier enhancement

2015-10-12 Thread Marton Balint 


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'?


Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel