• Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 292 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Integrating WMADEC 1.20

Sameer Naik9143
Prodigy 90 points


Hello,

I am using gstreamer and have written  a plugin that handles the decoding of wma streams using the "wmadec" DSP codec.

In gstreamer the "asfdemux" plugin is used to demultiplex the asf stream, which will give a packetized stream to my plugin. Header information is provided using other mechanisms. I am using the header information to generate the RCA header and am also encapsulating the wma payload in the RCA payload pcaket as required by the wmadec algorithm.

I have been able to confirm the validity of this process by comparing it against the stream generated using the "tidemux_asf" plugin that can be found in the package available here http://www.z3technology.com/DaVinci_GStreamer/.

Now when i provide the input data to the decoder, only a very little chunk of it gets consumed by the decoder at each call. As a result of this over a very short period of time the input buffer to the decoder gets maxed out and i have to exit from the application.

As a test case, i have a stream whose audio payload length is 5945 bytes, after adding the RCA payload header this becomes 5950 bytes. Below is the dump of the decoders data consumption.

The first call has 6070 bytes in the input buffer, which has 70 bytes RCA header + 5950 bytes of RCA payload.

consumed: 000070 of 00006020 bytes
consumed: 000133 of 00011900 bytes
consumed: 000000 of 00017717 bytes
consumed: 000000 of 00023667 bytes
consumed: 000256 of 00029617 bytes
consumed: 000256 of 00035311 bytes
consumed: 000896 of 00041005 bytes
consumed: 001152 of 00046059 bytes
consumed: 000896 of 00050857 bytes
...

...

As you can see here, the data that is being consumed is very little compared to what is written to the input buffer. Ideally i would expect it to consume the entire input as at each call exactly one RCA payload packet is made available (this is how the aac decoder handles input data).

I would like to know whether it is possible to configure the decoder to consume the entire input data. If yes, then please help me in the same.

Regards

~Sameer

  • TI__Mastermind 30480 points

    Hi Sameer,

    WMA bitstreams follow packets hirarchy and a packet contains variable number of frames(max 16 frames).                                                                                                                   5950 bytes in your case is the size of payload for packet 1.  Number of frrames in the packet and size of compressed frame is not known to application hence decoder expects full payload in the input buffer to decode a frame. Last frame in a packet can straddle into next packet also. It will not be possible to decode that frame if we don't have second payload also in the input buffer. So we recommned to have two payloads in the input buffer. (5950 + 5950 bytes).

    As AAC follows frame hirarchy,  decoder will consume entire framedata.

     

    Ramprasad

     

  • in reply to Ramprasad
    Prodigy 90 points

    Hello Ramprasad,

    As suggested i changed the input code a bit to write two consecutive frames into the decoders input buffer before calling the process call. However the consumption pattern did not change.

    Following is the data consumption pattern for the same stream with the changes as suggested.

    consumed: 70 of 11970
    consumed: 133 of 17850
    consumed: 0 of 23667
    consumed: 0 of 29617
    consumed: 256 of 35567
    consumed: 256 of 41261
    consumed: 896 of 46955
    consumed: 1152 of 52009
    consumed: 896 of 56807
    ...


    As you can see, the amount of data consumed is exactly the same as it was when only one RCA payload data was being made available at each call.

    Please suggest.

     

    Thanks and Regards

    ~Sameer