Carl Eugen Hoyos ag.or.at> writes:
> +av_log(fc, AV_LOG_ERROR,
> + "Absolute path %s not tried for security reasons, "
> + "pass -use_absolute_path 1 to force using absolute paths\n",
> + ref->path);
A variant was merged by Michael, wording
improvements welcome
On date Tuesday 2015-05-12 13:16:14 +, Carl Eugen Hoyos encoded:
> Stefano Sabatini gmail.com> writes:
>
> > > + "pass -use_absolute_path 1 to force using absolute paths\n",
>
> > set the use_absolute_path libavformat muxer
> > option to 1 to force using absolute paths.
>
> Ok with
On Tue, 12 May 2015 13:16:14 + (UTC)
Carl Eugen Hoyos wrote:
> Stefano Sabatini gmail.com> writes:
>
> > > + "pass -use_absolute_path 1 to force using absolute paths\n",
>
> > set the use_absolute_path libavformat muxer
> > option to 1 to force using absolute paths.
>
> Ok with "us
Stefano Sabatini gmail.com> writes:
> > + "pass -use_absolute_path 1 to force using absolute paths\n",
> set the use_absolute_path libavformat muxer
> option to 1 to force using absolute paths.
Ok with "use_absolute_path demuxer option"?
Carl Eugen
_
On date Friday 2015-05-08 13:25:17 +0200, Carl Eugen Hoyos encoded:
> Hi!
>
> Attached patch intends to make it more obvious what the user has
> to do to decode reference mov files.
>
> Please comment, Carl Eugen
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 54930a4..eaeb0d0 1006
wm4 googlemail.com> writes:
> > Carl Eugen:
> > > > > > > + "Absolute path %s not tried for security reasons, "
> > > > > > > + "pass -use_absolute_path 1 to force using absolute paths\n",
> --demuxer-lavf-o=use_absolute_path=1
Please make this a whole sentence like above to
I can commit it.
On Sat, 9 May 2015 21:30:33 +0200
Nicolas George wrote:
> Le decadi 20 floréal, an CCXXIII, wm4 a écrit :
> > Uh, I replied with what exactly you asked for.
>
> Carl Eugen asked for alternate wordings, and instead of trying honestly to
> propose something that would be acceptable, you propose so
Le decadi 20 floréal, an CCXXIII, wm4 a écrit :
> Uh, I replied with what exactly you asked for.
Carl Eugen asked for alternate wordings, and instead of trying honestly to
propose something that would be acceptable, you propose something that is
deliberately unacceptable.
In other words, you are
On Sat, 9 May 2015 21:15:14 +0200
Nicolas George wrote:
> Le decadi 20 floréal, an CCXXIII, wm4 a écrit :
> > --demuxer-lavf-o=use_absolute_path=1
>
> So basically, you whine about a dash but you can not be bothered to compose
> a message that does not have sixteen app-specific characters.
Uh,
Le decadi 20 floréal, an CCXXIII, wm4 a écrit :
> --demuxer-lavf-o=use_absolute_path=1
So basically, you whine about a dash but you can not be bothered to compose
a message that does not have sixteen app-specific characters.
Regards,
--
Nicolas George
signature.asc
Description: Digital sign
On Sat, 9 May 2015 20:49:23 +0200
Nicolas George wrote:
> Carl Eugen:
> > > > > > + "Absolute path %s not tried for security reasons, "
> > > > > > + "pass -use_absolute_path 1 to force using absolute paths\n",
>
> "Enable the use_absolute_path option to allow using absolute paths"
>
Carl Eugen:
> > > > > + "Absolute path %s not tried for security reasons, "
> > > > > + "pass -use_absolute_path 1 to force using absolute paths\n",
"Enable the use_absolute_path option to allow using absolute paths"
wm4:
> I suspect you would reject the wording needed for my own app
On Sat, 9 May 2015 18:35:44 + (UTC)
Carl Eugen Hoyos wrote:
> Carl Eugen Hoyos ag.or.at> writes:
>
> > > > + "Absolute path %s not tried for security reasons, "
> > > > + "pass -use_absolute_path 1 to force using absolute paths\n",
>
> > Please suggest a wording that is also ac
Carl Eugen Hoyos ag.or.at> writes:
> > > + "Absolute path %s not tried for security reasons, "
> > > + "pass -use_absolute_path 1 to force using absolute paths\n",
> Please suggest a wording that is also acceptable for
> library users (they can't guess "use_absolute_path"
> either
wm4 googlemail.com> writes:
> What I'm suggesting would fix all of this.
But how is your suggestion related to the patch in question?
Please suggest a wording that is less ffmpeg-related, I will
happily use it.
Carl Eugen
___
ffmpeg-devel mailing li
On Sat, 9 May 2015 10:19:40 +0200
Nicolas George wrote:
> Le nonidi 19 floréal, an CCXXIII, wm4 a écrit :
> > The problem is that this code was written with ffmpeg.c in mind, so you
> > assumed that it was fine to open new files inside of libavformat, and
> > you had to add an option to let ffmpe
Le nonidi 19 floréal, an CCXXIII, wm4 a écrit :
> The problem is that this code was written with ffmpeg.c in mind, so you
> assumed that it was fine to open new files inside of libavformat, and
> you had to add an option to let ffmpeg.c "fix" the hardcoded policy if
> needed.
Not at all. "use_abso
wm4 googlemail.com> writes:
> The correct way is adding a callback for opening
> new files, and let the API user decide. ffmpeg.c
> can then implement its own use_absolute_path
> option.
How is this related to the existing implementation?
Don't you have to set use_absolute_path to open a
ref
On Fri, 8 May 2015 12:37:48 + (UTC)
Carl Eugen Hoyos wrote:
> wm4 googlemail.com> writes:
>
> > > + "Absolute path %s not tried for security reasons, "
> > > + "pass -use_absolute_path 1 to force using absolute paths\n",
>
> > ffmpeg.c options/conventions have no place in the l
wm4 googlemail.com> writes:
> > + "Absolute path %s not tried for security reasons, "
> > + "pass -use_absolute_path 1 to force using absolute paths\n",
> ffmpeg.c options/conventions have no place in the libraries.
How is this libavformat option related to ffmpeg.c?
Please suggest
On Fri, 8 May 2015 13:25:17 +0200
Carl Eugen Hoyos wrote:
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 54930a4..eaeb0d0 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -2648,6 +2648,11 @@ static int mov_open_dref(AVIOContext **pb, const char
> *src, MOVDref *ref,
21 matches
Mail list logo
