[FFmpeg-devel] Add waveformat extensible support in wav muxer (SoC qualification task)

Michael Niedermayer michaelni
Sun Mar 29 17:47:35 CEST 2009


On Sun, Mar 29, 2009 at 11:51:57AM +0800, zhentan feng wrote:
> Hi
> 
> 2009/3/28 Michael Niedermayer <michaelni at gmx.at>
> 
> > On Sat, Mar 28, 2009 at 06:47:25PM +0800, zhentan feng wrote:
> > > Hi
> > >
> > > 2009/3/28 Benjamin Larsson <banan at ludd.ltu.se>
> > >
> > > > zhentan feng wrote:
> > > >
> > > >> Hi
> > > >>
> > > >> 2009/3/27 Benjamin Larsson <banan at ludd.ltu.se>
> > > >>
> > > >>
> > > >>
> > > >>> zhentan feng wrote:
> > > >>>
> > > >>>
> > > >>>> Hi
> > > >>>>
> > > >>>> 2009/3/26 Benjamin Larsson <banan at ludd.ltu.se>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>> zhentan feng wrote:
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>> Hi
> > > >>>>>>
> > > >>>>>> 2009/3/26 Michael Niedermayer <michaelni at gmx.at>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>> On Thu, Mar 26, 2009 at 01:19:00AM +0800, zhentan feng wrote:
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>> Hi,
> > > >>>>>>>>
> > > >>>>>>>> Here is patch for the small task of qualification tasks NO.30.
> > > >>>>>>>> Based on the work of Benjamin Larsson, I generated the pathc as
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>> below.
> > > >>>
> > > >>>
> > > >>>>      I think it must need further modifies.
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>> yes, iam not sure if this or benjamins patch was better
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>> I downloaded the 6-channel wav file from:
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>
> > http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/Samples/Microsoft/6_Channel_ID.wav
> > > >>>
> > > >>>
> > > >>>>  ( and other typr wav files can acess here :
> > > >>>>>>
> > http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/Samples.html
> > > >>>>>> )
> > > >>>>>>
> > > >>>>>> 1) then I run ./ffmpeg_g -i 6_Channel_ID.wav channel4.wav
> > > >>>>>>
> > > >>>>>> I get the error:
> > > >>>>>> Resampling with input channels greater than 2 unsupported.
> > > >>>>>>
> > > >>>>>> so I run another command:
> > > >>>>>> 2) ./output_example test.wav
> > > >>>>>> ./ffmpeg_g -i test.wav -ac 4 ch4.wav
> > > >>>>>>
> > > >>>>>> and enc->channels is 4, however enc->channel_layout is 0.
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> Finally, I have 2 questions:
> > > >>>>>>
> > > >>>>>> 1) how to test the muxer works correctly?
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>> When the muxer works correctly it should be possible to transcode a
> > wav
> > > >>>>> file that contains the wavformatextensible header.
> > > >>>>>
> > > >>>>>  2) where to specify the enc->channel_layout?
> > > >>>>>        It should be filled in by ffmpeg.c.
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>> I debug the commandline:
> > > >>>> ./ffmpeg_g -i test.wav -ac 4 4ch.wav
> > > >>>>
> > > >>>> and found that the enc->channel_layout value is assigned from the
> > input
> > > >>>>
> > > >>>>
> > > >>> file
> > > >>>
> > > >>>
> > > >>>> channel_layout. In this case, it is 0.
> > > >>>> and it seems that "-channel_layout" option doesn't work.
> > > >>>>
> > > >>>> 1) is it need to refresh the channel_layout value according to the
> > > >>>>
> > > >>>>
> > > >>> channels
> > > >>>
> > > >>>
> > > >>>> in ffmpeg.c or in put_wav_header()?
> > > >>>> 2) any tools to examine the output file is correct?
> > > >>>>
> > > >>>> zhentan feng
> > > >>>>
> > > >>>>
> > > >>> Hi, this is the latest version of my patch. This adds the maybe
> > correct
> > > >>> GUID values. To really test this you need to find a wav file with a
> > > >>> corrrect dwChannelMask. And then make sure that the muxer puts the
> > same
> > > >>> mask to the transcoded file. The output file should also be playable
> > in
> > > >>> windows.
> > > >>>
> > > >>> [...]
> > > >>>
> > > >>>
> > > >>
> > > >>
> > > >> 1) I download the 6 channels sample wav file form the follow link:
> > > >>
> > > >>
> > http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/Samples/Microsoft/6_Channel_ID.wav
> > > >>
> > > >> then acoording to the new patch, I run the command:
> > > >> ./ffmpeg -i 6_Channel_ID.wav output_ch6.wav
> > > >>
> > > >> the program run normaly, here is the output result.
> > > >>
> > > >> Input #0, wav, from '6_Channel_ID.wav':
> > > >>  Duration: 00:00:05.83, bitrate: 4233 kb/s
> > > >>    Stream #0.0: Audio: pcm_s16le, 44100 Hz, 6 channels
> > > >> (FL|FR|FC|LFE|BL|BR), s16, 4233 kb/s
> > > >> Output #0, wav, to 'output_ch6.wav':
> > > >>    Stream #0.0: Audio: pcm_s16le, 44100 Hz, 6 channels
> > > >> (FL|FR|FC|LFE|BL|BR), s16, 4233 kb/s
> > > >> Stream mapping:
> > > >>  Stream #0.0 -> #0.0
> > > >> Press [q] to stop encoding
> > > >> size=    3017kB time=5.84 bitrate=4233.7kbits/s
> > > >> video:0kB audio:3017kB global headers:0kB muxing overhead 0.002201%
> > > >>
> > > >> 2) The file 6_Channel_ID.wav can be palyed by windows mediaplayer, but
> > the
> > > >> output_ch6.wav can't.
> > > >>
> > > >> I compared the two wav files and found that 6_Channel_ID.wav has 60
> > more
> > > >> bytes than output_ch6.wav
> > > >> the 60 bytes are after WAVEFORMATEXTENSIBLE sturct,followed by the
> > data.
> > > >> Except for the 60 bytes, the two files are all the same.
> > > >>
> > > >> However, I noticed that the sample website says about 6_Channel_ID.wav
> > > >> that
> > > >> :"This file has a "cue " chunk with a count of zero cue points,
> > followed
> > > >> by
> > > >> two empty cue point structures."
> > > >>
> > > >> my question is:
> > > >> are the 60 bytes cue chunk? and how to handle this?
> > > >>
> > > >> zhentan feng
> > > >> thanks
> > > >>
> > > >>
> > > >
> > > > Locate and look at the GUID in the original and the ffmpeg muxed file.
> > They
> > > > most likely differ.
> > > >
> > > > [..]
> > > >
> > >
> > > yes. it's the GUID problem.
> > > thanks.
> > > here is the new patch.
> > [...]
> > > @@ -351,10 +357,21 @@
> > >          put_le16(pb, 2); /* wav_extra_size */
> > >          hdrsize += 2;
> > >          put_le16(pb, enc->frame_size); /* wSamplesPerBlock */
> > > -    } else if(enc->extradata_size){
> > > -        put_le16(pb, enc->extradata_size);
> > > +    } else if(enc->extradata_size || waveformatextensible){
> > > +        if (waveformatextensible) {                     /* write
> > WAVEFORMATEXTENSIBLE extensions */
> > > +            put_le16(pb, enc->extradata_size+22);       /* 22 is the
> > size of WAVEFORMATEXTENSIBLE-WAVEFORMATEX */
> > > +            put_le16(pb, enc->bits_per_coded_sample);   /*
> > ValidBitsPerSample || SamplesPerBlock || Reserved */
> > > +            put_le32(pb, enc->channel_layout);          /* dwChannelMask
> > */
> > > +            put_le32(pb, enc->codec_tag);               /* GUID + next 3
> > */
> > > +            put_le32(pb, 0x00100000);
> > > +            put_le32(pb, 0xAA000080);
> > > +            put_le32(pb, 0x719B3800);
> > > +            hdrsize += enc->extradata_size+22;
> > > +        } else {
> > > +            put_le16(pb, enc->extradata_size);
> > > +            hdrsize += enc->extradata_size;
> > > +        }
> >
> > what happens when waveformatextensible is 1 but one of the previous
> > (else) if is true?
> > does that fail or can that not happen at all?
> >
> 
> here is new patch.
> if(waveformatextensible)  is split from the if else chain.
> 
> 
> >
> > >          put_buffer(pb, enc->extradata, enc->extradata_size);
> > > -        hdrsize += enc->extradata_size;
> > >          if(hdrsize&1){
> >
> > id leave that and just add 22 in the if()
> 
> 
> fixed.
> 
> 
> -- 
> Best wishes~

> Index: libavformat/riff.c
> ===================================================================
> --- libavformat/riff.c	(revision 18184)
> +++ libavformat/riff.c	(working copy)
> @@ -282,12 +282,19 @@
>  int put_wav_header(ByteIOContext *pb, AVCodecContext *enc)
>  {
>      int bps, blkalign, bytespersec;
> +    int waveformatextensible = 0;
>      int hdrsize = 18;
> +    int flg = 0;
>  
>      if(!enc->codec_tag || enc->codec_tag > 0xffff)
>          return -1;
>  
> -    put_le16(pb, enc->codec_tag);
> +    if (enc->channels > 2 && enc->channel_layout) {
> +        put_le16(pb, 0xfffe);
> +        waveformatextensible = 1;
> +    } else
> +        put_le16(pb, enc->codec_tag);
> +

waveformatextensible = enc->channels > 2 && enc->channel_layout;
if(waveformatextensible) put_le16(pb, 0xfffe);
else                     put_le16(pb, enc->codec_tag);


>      put_le16(pb, enc->channels);
>      put_le32(pb, enc->sample_rate);
>      if (enc->codec_id == CODEC_ID_MP2 || enc->codec_id == CODEC_ID_MP3 || enc->codec_id == CODEC_ID_GSM_MS) {
> @@ -351,17 +358,32 @@
>          put_le16(pb, 2); /* wav_extra_size */
>          hdrsize += 2;
>          put_le16(pb, enc->frame_size); /* wSamplesPerBlock */
> -    } else if(enc->extradata_size){
> -        put_le16(pb, enc->extradata_size);
> -        put_buffer(pb, enc->extradata, enc->extradata_size);
> -        hdrsize += enc->extradata_size;
> -        if(hdrsize&1){
> -            hdrsize++;
> -            put_byte(pb, 0);
> +    } else
> +        flg = 1;
> +
> +    if (waveformatextensible) {                     /* write WAVEFORMATEXTENSIBLE extensions */
> +        put_le16(pb, enc->extradata_size+22);       /* 22 is the size of WAVEFORMATEXTENSIBLE-WAVEFORMATEX */
> +        put_le16(pb, enc->bits_per_coded_sample);   /* ValidBitsPerSample || SamplesPerBlock || Reserved */
> +        put_le32(pb, enc->channel_layout);          /* dwChannelMask */
> +        put_le32(pb, enc->codec_tag);               /* GUID + next 3 */
> +        put_le32(pb, 0x00100000);
> +        put_le32(pb, 0xAA000080);
> +        put_le32(pb, 0x719B3800);
> +        hdrsize += 22;
> +    }
> +    if (flg == 1) {
> +        if (enc->extradata_size){
> +            put_le16(pb, enc->extradata_size);
> +            hdrsize += enc->extradata_size;
> +            put_buffer(pb, enc->extradata, enc->extradata_size);
> +            if(hdrsize&1){
> +                hdrsize++;
> +                put_byte(pb, 0);
> +            }
> +        } else {
> +            hdrsize -= 2;
>          }
> -    } else {
> -        hdrsize -= 2;
> -    }
> +   }
>  
>      return hdrsize;
>  }

looks broken when extradata_size is not 0

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090329/5eb30373/attachment.pgp>



More information about the ffmpeg-devel mailing list