> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of softworkz .
> Sent: Freitag, 16. Mai 2025 06:16
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [FFmpeg-cvslog] fftools/graphprint: Now, make it a
> Killer-Feature!
> 
> 
> 
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of Romain
> > Beauxis
> > Sent: Freitag, 16. Mai 2025 05:40
> > To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [FFmpeg-cvslog] fftools/graphprint: Now, make it
> a
> > Killer-Feature!
> >
> > Le jeu. 15 mai 2025 à 19:54, Michael Niedermayer <mich...@niedermayer.cc> a
> > écrit :
> > >
> > > Hi
> > >
> > > On Fri, May 16, 2025 at 12:17:14AM +0000, softworkz . wrote:
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of
> > Marton
> > > > > Balint
> > > > > Sent: Freitag, 16. Mai 2025 02:00
> > > > > To: FFmpeg development discussions and patches <
> > ffmpeg-devel@ffmpeg.org>
> > > > > Subject: Re: [FFmpeg-devel] [FFmpeg-cvslog] fftools/graphprint: Now,
> > make it a
> > > > > Killer-Feature!
> > > > >
> > > > >
> > > > >
> > > > > On Thu, 15 May 2025, softworkz . wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > >> -----Original Message-----
> > > > > >> From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of
> > Ramiro
> > > > > Polla
> > > > > >> Sent: Donnerstag, 15. Mai 2025 23:50
> > > > > >> To: ffmpeg-devel@ffmpeg.org
> > > > > >> Subject: Re: [FFmpeg-devel] [FFmpeg-cvslog] fftools/graphprint:
> > Now, make
> > > > > it a
> > > > > >> Killer-Feature!
> > > > > >>


[...]


> > > Not speaking as a TC member here but IMHO
> > >
> > > 1. lets all calm down, so far we have a civil and productive discussion
> > >    maybe we can simply find a solution everyone is happy with!
> > >
> > > 2. all security issues must be fixed if there are some
> > >
> > > 3. there should be a configure flag to enable/disable the browser opening
> > feature
> > >    if it remains
> > >
> > > 4. can system() be replaced by fork()+exec*() ? is that something people
> > would
> > >    prefer ?
> >
> > Forked processes inherit opened file descriptors unless explicitly marked
> > as cloexec, this is another big can of worms..
> >
> > > 5. this is a cool feature, i would use this if its available, that said
> > >    if i had to manually open a browser with a given URL that would work
> > >    for me too.
> >
> > At the very least there should be a prompt asking the user to confirm
> > what's about to happen.
> 
> I think that's a very good and agreeable point in general, independent
> from everything else. I assume you mean at first-time use? Or first time
> per day/month maybe?
> 
> 
> 
> >
> > A user-friend way and also secure way could be to output something that is
> > readily usage, for instance:
> > bash -c `ffmpeg <options>`
> 
> I'm not sure I understand the idea. ffmpeg should output another ffmpeg
> command?
> 
> 
> 
> Generally, I think something with a kind of "first-time setup" pattern would
> be great like:
> 
> 
> - ffmpeg -sg
>   - if "first-time use" (=detect whether the "setup" has been made)
>     => don't execute actual cmd but show message explaining what -sg does, and
>                   offer to set it up for the user (in whichever way is needed
> on the platform)  or tell
>                   the user what's needed to be done if very simple
>                   if user chooses "no", it prints a message asking to remove
> the -sg param and exits
>     - otherwise use the existing "setup" to auto-launch the browser
> 
> On the technical side, I don't have a specific way in mind yet, but I think
> that opens up more ways
> how the auto-launch could happen. It would be very explicit for once and also
> more secure
> because it doesn't work out-of-the box without "setup". When FFmpeg can
> perform the setup upon
> user confirmation, then it would still be very convenient.


A possible alternative on the code-side might be SDL_OpenURL(), but I haven't 
tried 
yet. It would be dependent on SDL2 then, but afaik, that's typically included 
in builds (please correct me if wrong). 
Whether one would find that better, equal or worse, probably depends on 
everybody's
real motivations and there appear to be different ones, so I'm just mentioning
it to see what people think.

Thanks
sw




_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Reply via email to