[Ffmpeg-devel] Re: [PATCH] Second Try: Set bit_rate for asf format

[Zuxy Meng]

Hi,

2007/3/30, Zuxy Meng <zuxy.meng at gmail.com>:
> Hi,
>
> 2007/3/30, Michael Niedermayer <michaelni at gmx.at>:
> > Hi
> >
> > On Fri, Mar 30, 2007 at 09:37:57AM +0800, Zuxy Meng wrote:
> > > Hi,
> > >
> > > 2007/3/29, Michael Niedermayer <michaelni at gmx.at>:
> > > >Hi
> > > >
> > > >On Thu, Mar 29, 2007 at 10:51:59AM +0800, Zuxy Meng wrote:
> > > >> Hi
> > > >>
> > > >>
> > > >> Sure. And I've confirmed that the attached patch doesn't break fulltest.
> > > >
> > > >setting bitrate just for video seems like a dirty hack, why did it break
> > > >audio? some check in wma.c maybe? why are you sure the video case wont
> > > >break anything? wmv has (silly) bitrate based checks too IIRC
> > > >
> > >
> > > For wmv, bit_rate as set by lavf is used for encoding only; while for
> > > wma it's used in ff_wma_init() which is shared between encoder and
> > > decoder.
> >
> > still i have a bad feeling with setting it just for video knowing it
> > breakes audio if it would be set there too ...
>
> Me too. I'll dig into wma.c this weekend.
>
> > somehow this isnt a clean solution at all

The reason is that for audio streams, there will be a wave header
defined at the asf container level, and get_wav_header will set
bit_rate as 8*nAvgBytesPerSec. So unlike video streams, we don't need
to look for the optional extended stream property object for bitrate.

And something more about the fulltest: asf files used/generated in
fulltest don't contain extended stream property objects so bitrate[i]
== 0, and the subsequent assignment will effectively overwrite what
has been found in get_wav_header. This is absolutely my fault; I
forgot that such objects are optional, not mandatory.
-- 
Zuxy
Beauty is truth,
While truth is beauty.
PGP KeyID: E8555ED6