On Mon, Jun 29, 2020 at 4:52 AM Alexander Strasser wrote:
>
> On 2020-06-28 22:23 +0200, Marton Balint wrote:
> >
> >
> > On Sun, 28 Jun 2020, Michael Niedermayer wrote:
> >
> > > On Sun, Jun 28, 2020 at 01:22:58PM +0100, Derek Buitenhuis wrote:
> > > > On 26/06/2020 14:49, Nicolas George wrote:
>
On 2020-06-28 22:23 +0200, Marton Balint wrote:
>
>
> On Sun, 28 Jun 2020, Michael Niedermayer wrote:
>
> > On Sun, Jun 28, 2020 at 01:22:58PM +0100, Derek Buitenhuis wrote:
> > > On 26/06/2020 14:49, Nicolas George wrote:
> > > > Probably a good idea, but these explanation should probably go in
>
On 28/06/2020 21:23, Marton Balint wrote:
> I try to keep track of most ffprobe changes, so fine by me if people
> agree.
No argument from me.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-deve
On Sun, 28 Jun 2020, Michael Niedermayer wrote:
On Sun, Jun 28, 2020 at 01:22:58PM +0100, Derek Buitenhuis wrote:
On 26/06/2020 14:49, Nicolas George wrote:
Probably a good idea, but these explanation should probably go in
doc/ffprobe.texi.
Good point. Will add that during when I send v2.
Derek Buitenhuis (12020-06-28):
> I have not seen Stefano active in a long time. Do you suggest I CC him on the
> v2 patch?
I was just emphasizing that my comment did not have the weight of
maintainership.
Stefano does not seem very interested, probably not very useful to Cc
him.
Regards,
--
On Sun, Jun 28, 2020 at 01:22:58PM +0100, Derek Buitenhuis wrote:
> On 26/06/2020 14:49, Nicolas George wrote:
> > Probably a good idea, but these explanation should probably go in
> > doc/ffprobe.texi.
>
> Good point. Will add that during when I send v2.
>
> > And I do not maintain ffprobe.
>
>
On 26/06/2020 14:49, Nicolas George wrote:
> Probably a good idea, but these explanation should probably go in
> doc/ffprobe.texi.
Good point. Will add that during when I send v2.
> And I do not maintain ffprobe.
I have not seen Stefano active in a long time. Do you suggest I CC him on the
v2 p
On 27/06/2020 09:27, Michael Niedermayer wrote:
> You explain why allow_unknown_format_opts = 1 is needed
>
> does allow_unknown_format_opts = 0 have a use case too ?
> because if not, this can be simplified
I thought so too, but I thought a change in the behavior like that
might break peoples' s
On Fri, Jun 26, 2020 at 02:15:00PM +0100, Derek Buitenhuis wrote:
> This useful, because by ffprobe's very nature, you use it to probe
> a file and find out what it is. Requiring every format private option
> to be known to the demuxer forces one to run ffprobe twice, if one
> wants to use ffprobe
Derek Buitenhuis (12020-06-26):
> This useful, because by ffprobe's very nature, you use it to probe
> a file and find out what it is. Requiring every format private option
> to be known to the demuxer forces one to run ffprobe twice, if one
> wants to use ffprobe in a generic way.
>
> For example
This useful, because by ffprobe's very nature, you use it to probe
a file and find out what it is. Requiring every format private option
to be known to the demuxer forces one to run ffprobe twice, if one
wants to use ffprobe in a generic way.
For example, say one wants to probe all user-uploaded f
11 matches
Mail list logo
