how do I dynamically change the video bitrate of a stream after its been setup

[declan]

Hi Guys

I have the following use case. I need to dynamically change the video
bitrate of a flash video (h264/AAC) which I am encoding on the fly.
The input flash video is received on a HTTP stream. I decode and then
re-encode this content on the fly using a specific set of rate
controls values. After a period of time I decide that I need to
change the bitrate that the video is encoded after say NN seconds.

So I tried this out and it doesnt work as I had hoped. I changed the
video bitrate via the Xuggler API call (setBitRate) for the Coder
after 10 seconds but the video is still being encoded with the old
bitrate.

So my question is two fold here.

1 Does ffmpeg allow for this type of dynamic behaviour in relation to
rate controls.
2. How would we acheive such functionality using Xuggle API. Using
the API directly after NN seconds doesnt work. Would I need to setup
additional streams when creating the output container and then switch
streams? How is this done and how would the client react to it?

Im sure this is something that has been tried by other Xuggle users.
Do you guys have any idea how I could acheive this? Is there a
preferred method to doing this using Xuggle.

Thanks
Declan

[Art Clarke]

1) No, but...
2) It can be done, but then don't use the Xuggler IContainer type -- instead write your own muxer (for FLV pretty damn easy) and then close the IStreamCoder at the higher bit-rate and open a new one at the lower bit-rate.  Then (for H264) make sure you write the new NAL parameter sets (available via IStreamCoder.getExtraData in Xuggler 3.3).

This is not easy in Xuggler 3.3 today, but is possible. 

- Art

--
http://www.xuggle.com/
xu‧ggle (zŭ' gl) v. To freely encode, decode, and experience audio and video.

Use Xuggle to get the power of FFmpeg in Java.

[Siva kiran]

With H264, I think this might not be so trivial. But should be possible.

[Art Clarke]

Sorry, didn't mean to imply trivial, but it should be possible.

- Art

[declan]

Hi Art

Could you provide me with some more detail as to why I need a new
custom FLV muxer? Can this be done in Java and Xuggle or do i need to
rewrite the ffmpeg source code to get this working? Im not sure what
this FLV muxer must do diiferent to the current FLV muxer. Is it due
to the fact that it will have more than one video stream?

For H264 NAL parameters is this some meta data used by the player?

I havent written a muxer before so apoligises if these questions are
very basic.

What about adding more than one video stream associated with the
current FLV muxer and swapping them in and out?

Declan

On Oct 22, 7:05 pm, Art Clarke <acla...@xuggle.com> wrote:
> Sorry, didn't mean to imply trivial, but it should be possible.
>
> - Art
>
>
>
> On Thu, Oct 22, 2009 at 10:48 AM, Siva kiran <siva.ki...@gmail.com> wrote:
> >  With H264, I think this might not be so trivial. But should be possible.
>

> > *From:* xuggle...@googlegroups.com [mailto:
> > xuggle...@googlegroups.com] *On Behalf Of *Art Clarke
> > *Sent:* Thursday, October 22, 2009 9:57 AM
> > *To:* xuggle...@googlegroups.com
> > *Subject:* [xuggler-users] Re: how do I dynamically change the video

> > bitrate of a stream after its been setup
>
> > 1) No, but...
> > 2) It can be done, but then don't use the Xuggler IContainer type --
> > instead write your own muxer (for FLV pretty damn easy) and then close the
> > IStreamCoder at the higher bit-rate and open a new one at the lower
> > bit-rate.  Then (for H264) make sure you write the new NAL parameter sets
> > (available via IStreamCoder.getExtraData in Xuggler 3.3).
>
> > This is not easy in Xuggler 3.3 today, but is possible.
>
> > - Art
>

> > On Thu, Oct 22, 2009 at 9:46 AM, declan <harrison.dec...@googlemail.com>

> --http://www.xuggle.com/

[Art Clarke]

For FLV non H264 you're fine just opening a new streamcoder -- the FLV container format header doesn't actually contain anything about bit-rate.

For H264 you'll need to do more, and frankly I'm not the best expert at the currently.

- Art

[declan]

Hi Art

I have found a solution to this problem which has involved making some
very minor changes to the captive source code in the libx264 and
ffmpeg source tree.

After seeking some advice on the libx264 users list I found that we
needed to re-init the encoder and ensure that the parameter
"b_repeat_headers" is always set. So re-initting the encoder
inherently starts the stream at an IDR frame,
which will involve sending new SPS/PPS as long as b_repeat_headers is
set.

So creating and opening a new IStreamCoder ensures that we re-init the
the encoder but I needed to be sure to set the b_repeat_headers. So l
made a few minor changes to libx264.c to ensure that it is always set
under ffmpeg source tree and common.c under libx264 source tree to
also ensure its always set. Re-built xuggler and tested it and it
worked well.

So my problem now is how best to incorporate this change into Xuggler/
ffmpeg going forward so that I can do this and keep up to date with
any xuggler changes. Also it would be good to have the ability to
turn this off and on as required.

libx264 does provide an option called "repeat-headers" that does just
this, however this option isnt exposed by ffmpeg and therefore isnt
exposed in Xuggler.

Could we get ffmpeg to expose this option just like they expose other
libx264 option e.g. "crf"? Or would you recommend another approach to
allow this to happen. I think other users would find this ability
very useful.

thanks for your patience

Declan

On Oct 22, 8:14 pm, Art Clarke <acla...@xuggle.com> wrote:
> For FLV non H264 you're fine just opening a new streamcoder -- the FLV
> container format header doesn't actually contain anything about bit-rate.
>
> For H264 you'll need to do more, and frankly I'm not the best expert at the
> currently.
>
> - Art
>

[declan]

On Oct 22, 8:14 pm, Art Clarke <acla...@xuggle.com> wrote:
> For FLV non H264 you're fine just opening a new streamcoder -- the FLV
> container format header doesn't actually contain anything about bit-rate.
>
> For H264 you'll need to do more, and frankly I'm not the best expert at the
> currently.
>
> - Art
>

[Art Clarke]

Turns out Xuggler has a provision for exactly this case; in the captive ffmpeg build we have the ability to provide custom patches (see captive/ffmpeg/patches).  Patches are applied in alphabetical order.  In this way we are not 100% dependent upon the ffmpeg-gods deciding our patches are worth of inclusion (for example, our ffmpeg distro has speex encoding support, while mainline ffmpeg still argues about the right way).

My suggestion is to create a patch that you think makes sense, and submit it to the ffmpeg team (ffmpeg-devel) for review.  The particular patch you suggest seems generally useful to ffmpeg.  If they accept it, it will be rolled into ffmpeg and we'll automatically pick it up.  If they reject it, we may accept it anyway (but I prefer the patch be made upstream first) depending on the change. 

Finally if we don't accept the change into Xuggler mainline, you can just maintain the patch yourself in your own Xuggler captive area as a patch file.

Hope that helps,

- Art

[declan]

Hi Art

Thanks for the advice I will try ffmpeg-users and then the xuggle-
users and see what you guys think.

Thanks
Declan

On Oct 31, 4:28 pm, Art Clarke <acla...@xuggle.com> wrote:
> Turns out Xuggler has a provision for exactly this case; in the captive
> ffmpeg build we have the ability to provide custom patches (see
> captive/ffmpeg/patches).  Patches are applied in alphabetical order.  In
> this way we are not 100% dependent upon the ffmpeg-gods deciding our patches
> are worth of inclusion (for example, our ffmpeg distro has speex encoding
> support, while mainline ffmpeg still argues about the right way).
>
> My suggestion is to create a patch that you think makes sense, and submit it
> to the ffmpeg team (ffmpeg-devel) for review.  The particular patch you
> suggest seems generally useful to ffmpeg.  If they accept it, it will be
> rolled into ffmpeg and we'll automatically pick it up.  If they reject it,
> we may accept it anyway (but I prefer the patch be made upstream first)
> depending on the change.
>
> Finally if we don't accept the change into Xuggler mainline, you can just
> maintain the patch yourself in your own Xuggler captive area as a patch
> file.
>
> Hope that helps,
>
> - Art
>