Hi,
I need some help trying to figure out how to configure the H.264 decoder according to section 6.1 of the User Guide. I'm working with an 8060 processor and am not on the Android platform so I don't have access to the Android iOMX context. (tears) But I am using the sample code to understand the process and I believe I have the input / output port configurations working correctly.
My understanding is that I have to implement section 6.1.1 or 6.1.2 to configure the decoder before sending input buffers for decoding. I'd like to do 6.1.2 (setting NAL size and sending SPS + PPS) since I don't have easy access to an avcC atom. Despite trying a variety of things, I can't seem to figure out exactly what format I need to send the data.
For the sake of an example, here is a hex dump of the first few rows of the sample video file "sample.320x240.h264":
0000 0100 4267 16c0 688d 1f14 0090 0000 6801 06ce 00f2 0000 6501 00b8 fe04 fc48 9598 4f54 3480 b0e8 3202 7810 5996 2bb2
Evident in that is: start code followed by SPS, then SC followed by PPS, then SC followed by what I assume is just picture frame data (65 b8 00 04 fe... etc.).
Section 6.1.2 indicates that "the client sets the NAL length initially using iOMX->setConfig (with OMX_IndexConfigVideoNalSize) before sending SPS + PPS through OMX_EmptyThisBuffer." In this example, what exactly would the NAL length be? Is it the size of SC + SPS + SC + PPS (21 bytes) or just the size of SPS + PPS (13 bytes)? And when I send the SPS + PPS to the decoder through OMX_EmptyThisBuffer, should the buffer be SC + SPS + SC + PPS or just SC + SPS + PPS or SPS + PPS or ... ?
If I set the NAL size, I always get this error (value: 80001009) after the SPS and PPS are sent to the decoder:
Error In Parsing NAL size, Return Error
Pushing input Buffer Failed
ERROR: Sending OMX_EventError to Client
Also, is it really necessary to do the SetConfig as in 6.1.1 and 6.1.2? The sample code doesn't appear to be doing that. The readBufferFromH264InputFile() function returns each chunk of data starting with the 4-byte SC. Then this data is sent via OMX_EmptyThisBuffer(). I have attempted this also, and while it doesn't generate any errors, and it does initiate EmptyBufferDone events, I never get an OMX_EventPortSettingsChanged event or any FillBufferDone events.
If anyone could help me understand exactly what needs to be sent through OMX_EmptyThisBuffer(), I would really appreciate it. I've been banging my head on this for a couple weeks so I figured it'd be better to just ask at this point. :)
Thanks,
John
I'm a moron.
Setting the NAL length to 2 bytes -- just like the user guide says -- makes it much happier.
I confused NAL length with SPS / PPS size because I'm a moron.
I still think my buffers are wacked though, if anyone wants to offer some insight there.
Ok so as of yet I am still unable to trigger an OMX_EventPortSettingsChanged event, which from my understanding is absolutely necessary before any decoding can be done.
What exactly needs to happen to cause this event?
I have tried the following configuration cases:
- OMX_SetConfig w/ AVCC atom
- OMX_SetConfig w/ NAL unit size (4 bytes), then the following variety of input buffers:
1) SC + SPS --> buffer 1
SC + PPS --> buffer 2
SC + frame data --> buffer 3, etc...
(I tried both 3-byte and 4-byte SCs.)
2) SC + SPS + SC + PPS --> buffer 1
SC + frame data --> buffer 2, etc...
3) 4-byte NAL unit size + SPS --> buffer 1
4-byte NAL unit size + PPS --> buffer 2
4-byte NAL unit size + frame data --> buffer 3, etc...
All of these end the same way... OMX_EmptyThisBuffer returns without error and an EmptyBufferDone event is thrown thereafter. But there is never any port settings changed event, so I never reconfigure the output ports... and so I can never make a successful call to OMX_FillThisBuffer.
What am I missing here?
Thanks,
John
One way to get this event is to do the following:
1. Initialize the decoder and set the dimensions to a setting of say 176x144
2. Feed the decoder an h.264 stream of 320x240.
The port settings changed event should automatically be called so that you can reconfigure the port to the new dimensions. The sample code should be able to handle this if you want to see it in working fashion before you start coding for it yourself.