New update with a small fix for Linux (Error compiling) Jorge Fuentes
2016-08-07 1:04 GMT+02:00 Llorx <[email protected]>: > Hi Ronald, > > Well, this is a PoC. There are a lot of ways to implement this under a > security context, so that's not a problem. For example, using ZeroMQ as > Bodecs Bela says in the other thread, feature already implemented in ffmpeg > as you can see here: https://www.ffmpeg.org/ffmpeg-all.html#zmq_002c-azmq > > As I said, this is just an undocumented-bad-written PoC, to get the point > and argue about the feature, not argue about the bad implemented code. How > to implement the feature is something we can discuss about later. > > Also, I doubt that every user build needs 99% of the filters, but they are > there, just in case someone needs it. Why this quantity of filters, > formats, codecs, etc? Because ffmpeg is a video processor software, it > needs the maximum number of features, just in case. > > This feature is something some people already asked for (I found some of > them when I googled about this some time ago) and I implemented it about 2 > years ago because I needed it too. Now I just want to release the code to > the community as I had people contacting me to get a copy. The people that > do not need it just don't enable it, as I don't enable channelsplit in my > streams, for example. > > I think that this feature belongs to ffmpeg as a good % of users use > ffmpeg as a live streaming software, including major videomixing software > companies, using it as their main live video publisher software (See vMix). > We have to understand that currently ffmpeg is not only a video converting > software, but a live stream solution for most users, so it needs to have > live streaming features, like other propietary video streaming software has > (See Adobe Media Encoder. Altough I don't like how they implemented it). > > I use this feature a lot since I created it about 2 years ago, and now I > just want to share it, as I know that some people will benefit from this > because there is not any solution (and best of all, opensource solution) > for these situations. > > Thank you for your point of view. I hope I made myself clear. > > Jorge Fuentes > > 2016-08-07 0:02 GMT+02:00 Ronald S. Bultje <[email protected]>: > >> Hi, >> >> On Sat, Aug 6, 2016 at 9:00 AM, Llorx <[email protected]> wrote: >> >> > Hi, >> > >> > Some days ago I started a thread here: >> > http://ffmpeg.org/pipermail/ffmpeg-devel/2016-August/197306.html >> > >> > Starting a new thread now because I lost my main thread mail and don't >> know >> > how to "reply" without having it in my inbox :-( >> > >> > ffmpeg has almost on-the-fly bitrate change control already built-in, >> > checking rc_buffer_size and rc_max_rate changes, so I only needed to >> change >> > those values while ffmpeg was running. >> > >> > I attach my Proof of Concept. >> > >> > PoC limitations: >> > - Not configurable via command line. >> > - The build will start listening on localhost (127.0.0.1) UDP port >> 32000 >> > always. >> >> >> This is a pretty significant feature from a security PoV. I'm honestly not >> even sure it belongs in upstream ffmpeg... Don't get me wrong, I >> understand >> what you're doing and why you're doing it this way and maybe this is the >> best (or at least quickest) way to do it. I might have done it the same >> way >> if I was trying to do what you're doing, I'm not sure. >> >> But, having said that, I doubt that every user's build of ffmpeg >> necessarily needs this feature. >> >> Ronald >> _______________________________________________ >> ffmpeg-devel mailing list >> [email protected] >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> > >
0001-Change-bitrate-on-the-fly-PoC.patch
Description: Binary data
_______________________________________________ ffmpeg-devel mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
