Re: [FFmpeg-devel] Change bitrate on-the-fly PoC (Patch)

[Llorx]

New update with a small fix for Linux (Error compiling)

Jorge Fuentes

2016-08-07 1:04 GMT+02:00 Llorx <dall...@gmail.com>:

> 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 <rsbul...@gmail.com>:
>
>> Hi,
>>
>> On Sat, Aug 6, 2016 at 9:00 AM, Llorx <dall...@gmail.com> 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
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
>


0001-Change-bitrate-on-the-fly-PoC.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Change bitrate on-the-fly PoC (Patch)

[Llorx]

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 :

> Hi,
>
> On Sat, Aug 6, 2016 at 9:00 AM, Llorx  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
> 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

[FFmpeg-devel] Change bitrate on-the-fly PoC (Patch)

[Llorx]

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.
 - Does not sanitize input.
 - Only work with x264 and such.
 - Only works 100% if you run ffmpeg with explicit -b:v and -maxrate
parameters.

This code is undocummented, with tabs and such, so do not follow ffmpeg
coding rules. Just posting this to see if someone finally likes it. If
someone likes this, I'll continue developing this small patch listening to
the community suggestions.

Looking forward to return a bit to this great software that saved my ass
uncountable times xD

PD: Attaching link just in case Gmail attachment gets discarded:
https://gist.github.com/Llorx/8fde9b6b5e2bf1a51cc20a94540c0950

Jorge Fuentes


0001-Bitrate-on-the-fly-PoC.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Change bitrate on-the-fly

[Bodecs Bela]

2016.08.01. 19:46 keltezéssel, Aman Gupta írta:

I would find your patch useful and am looking forward to reviewing
it. Using a socket isn't a bad way to do it IMHO- it's portable and allows
easy integration from any language.

Another option would be to extend the existing ffmpeg interactive mode to
handle your new command. Currently ffmpeg allows sending commands to
filters, but tbh it's pretty confusing to use and not well documented.

I'd love to see a generic control interface for ffmpeg that was easy to use
programatically, and could handle simple commands like "pause", "resume",
"seek ", etc.

Aman

On Sun, Jul 31, 2016 at 9:32 AM, Llorx  wrote:


Hi,

About 1 or 2 years ago I had written an addition for ffmpeg to change the
video bitrate while ffmpeg is running. The way I've done it is by listening
to a UDP socket for an int32, and each time a 4 byte packet enters, changes
the bitrate, taking effect instantly. Works like a charm, and the UDP way
fits my needings without problems. I needed it because currently I have a
business that requires streaming video in some difficult and
bandwith-changing environments, so I have a thrid party program than
launchs ffmpeg and analyzes the packets sent to detect bandwidth
alterations, changing the bitrate accordingly.

Now I would like to share it with the community, as I had some messages
from some users telling me to release it (As I posted a question about this
on Stack Overflow).

I know that the UDP thing is a bit hackish, so I would like to ask you,
ffmpeg masters, how do you consider that this can be applied in a more
"professional" way. I thought that instead of listening to a UDP socket
(configurable at launch time with a parameter), I can use named pipes,
memory mapped files or simply process signaling. The last method is only
available on Unix with SA_SIGINFO. Windows can't handle such signal
behaviour.

What do you think is the best option?
___
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

Hi,

for filters there is zmq. It works well. Quite few filters support it 
via commands. Would not zmq be good for this purpose, also?


best,

Bela

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

Re: [FFmpeg-devel] Change bitrate on-the-fly

[Aman Gupta]

I would find your patch useful and am looking forward to reviewing
it. Using a socket isn't a bad way to do it IMHO- it's portable and allows
easy integration from any language.

Another option would be to extend the existing ffmpeg interactive mode to
handle your new command. Currently ffmpeg allows sending commands to
filters, but tbh it's pretty confusing to use and not well documented.

I'd love to see a generic control interface for ffmpeg that was easy to use
programatically, and could handle simple commands like "pause", "resume",
"seek ", etc.

Aman

On Sun, Jul 31, 2016 at 9:32 AM, Llorx  wrote:

> Hi,
>
> About 1 or 2 years ago I had written an addition for ffmpeg to change the
> video bitrate while ffmpeg is running. The way I've done it is by listening
> to a UDP socket for an int32, and each time a 4 byte packet enters, changes
> the bitrate, taking effect instantly. Works like a charm, and the UDP way
> fits my needings without problems. I needed it because currently I have a
> business that requires streaming video in some difficult and
> bandwith-changing environments, so I have a thrid party program than
> launchs ffmpeg and analyzes the packets sent to detect bandwidth
> alterations, changing the bitrate accordingly.
>
> Now I would like to share it with the community, as I had some messages
> from some users telling me to release it (As I posted a question about this
> on Stack Overflow).
>
> I know that the UDP thing is a bit hackish, so I would like to ask you,
> ffmpeg masters, how do you consider that this can be applied in a more
> "professional" way. I thought that instead of listening to a UDP socket
> (configurable at launch time with a parameter), I can use named pipes,
> memory mapped files or simply process signaling. The last method is only
> available on Unix with SA_SIGINFO. Windows can't handle such signal
> behaviour.
>
> What do you think is the best option?
> ___
> 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

[FFmpeg-devel] Change bitrate on-the-fly

[Llorx]

Hi,

About 1 or 2 years ago I had written an addition for ffmpeg to change the
video bitrate while ffmpeg is running. The way I've done it is by listening
to a UDP socket for an int32, and each time a 4 byte packet enters, changes
the bitrate, taking effect instantly. Works like a charm, and the UDP way
fits my needings without problems. I needed it because currently I have a
business that requires streaming video in some difficult and
bandwith-changing environments, so I have a thrid party program than
launchs ffmpeg and analyzes the packets sent to detect bandwidth
alterations, changing the bitrate accordingly.

Now I would like to share it with the community, as I had some messages
from some users telling me to release it (As I posted a question about this
on Stack Overflow).

I know that the UDP thing is a bit hackish, so I would like to ask you,
ffmpeg masters, how do you consider that this can be applied in a more
"professional" way. I thought that instead of listening to a UDP socket
(configurable at launch time with a parameter), I can use named pipes,
memory mapped files or simply process signaling. The last method is only
available on Unix with SA_SIGINFO. Windows can't handle such signal
behaviour.

What do you think is the best option?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel