Problem with big array
Hi EEUG, I have a problem...
My right 2 left code was working with vector at the size of [256*6 Bytes] in sms ver 1.7
Now in SMS 2.rev4 I get linking errors.
If I add this one line to SMS_SubtitleContext.c,
static unsigned char r2l_support_vector [256*6];
I will get many linking errors like those:
obj/SMS_IPU.o(.text+0x155c): In function `IPU_InitContext':
src/SMS_IPU.c: relocation truncated to fit: R_MIPS_GPREL16 g_pSPRTop
obj/SMS_IPU.o(.text+0x1574):src/SMS_IPU.c: relocation truncated to fit: R_MIPS_G
obj/SMS_IPU.o(.text+0x1614):src/SMS_IPU.c: relocation truncated to fit: R_MIPS_G
But smaller vector size will still link without errors (for example [256*2]).
Hope You have a solution for me, RamRam.
...just declare your data with "section( ".data" ) attribute ;)...
Can you add 2 more fields to SMS_CodecContext? Smth. like:
...if it's codec related you can alocate whatever you want in SMS_CodecContext.m_pCtx->m_pCtx. If it's container related you can use SMS_Container.m_pCtx for that purpose. Otherwise feel free to add whatever you want, since I'm not sure where this resource should be deallocated/destroyed. I'll commit latest SMS sources to the SVN this week/weekend (need to put license information to the files etc.)...
> if it's codec related you can alocate whatever you want in SMS_CodecContext.m_pCtx->m_pCtx. If it's container related you can use SMS_Container.m_pCtx for that purpose
Yes, I know, but it seems that almost all codecs need some extra configuration info and most containers provide it, so I think that it's better to have some common place for that. And I really don't want to add smth. Argon specific in that area.
Edit: But, in fact, I don't have a slightest idea when any additional decoders/demuxers will be finished, so it's more like - wouldn't you mind implementing any required changes?
@user112: ...I think 'm_lExtraDataSize' is not required as we can put everything behind that 'm_pExtraData' (C++ object :D). I'll put that pointer there, no probs...
P.S. I don't know what I'm going to do next (btw., there's no 'Seek' in your .mov container ;)), so, I'll take some timeout (well, .ogg will have some progress). There's also an issue due to DOS encoding of filenames in SMB protocol and I'll try to put some efforts there (together with R3ALIST, who made already some workouts about it)...
wow eugg thnks fixing the problem. works great.
im imagining if there like 10 people on this project, this would program will compete to xbmc for xbox and sms for ps2. i really wanted to help but my knowledge of programming still not that good. just started to get to the programming course, hope i can help someday if itsnt too late. nice work eugg love your work.
I've stumbled upon that library http://sourceforge.net/projects/melo and thought that I would give it a try, got it working with the Windows version, but not with the RingBuffer version.
What's wrong with that stuff, and what about these channels? Anything else I should put into the lpOutBuf?
static int32_t AAC_Decode(SMS_CodecContext* apCtx, SMS_RingBuffer* apOutput, SMS_RingBuffer* apInput)
SMS_AVPacket* lpPkt = (SMS_AVPacket*) apInput->m_pOut;
uint8_t* lpInputBuf = lpPkt->m_pData;
unsigned long lInputBufSize = lpPkt->m_Size;
unsigned long lOutputBufSize;
int retVal = 0;
MLO_Decoder* pDecoder = (MLO_Decoder*) apCtx->m_pCodec->m_pCtx;
pDecoder->Decode(lpInputBuf, lInputBufSize, &pTempBuffer, &lOutputBufSize);
short* lpOutBuf = (short*) SMS_RingBufferAlloc(apOutput, lOutputBufSize + 68);
lpOutBuf += 32;
//anChannels += 7;
//retVal = 6 << (anChannels + 1);
//*(int*)lpOutBuf = retVal;
lpOutBuf += 2;
memcpy(lpOutBuf, pTempBuffer, lOutputBufSize);
retVal = lOutputBufSize;
It receives the same frame several times (lInputBufSize is same) and then just freezes. If I remove SMS_RingBufferAlloc() and just return 0 it works fine (with no sound of course).
...first thing is that first word (4 bytes) in the output buffer should contain amount of sound samples (raw PCM data in bytes) decoded (that commented *(int*)lpOutBuf = retVal thing and I'm not sure what what 6 << (anChannels + 1) means). 1 sound sample is 'short' (2 bytes) and it must follow little endian scheme. Amount of channels supported is 1 or 2 (mono or stereo). For stereo decoded data should be interleaved, i.e. 1 sample for left channel, then 1 sample for right channel etc. Second thing is that 'apOutput -> UserCB ( apOutput ) should be called just before return (if you didn't change player stuff). That callback is set in the player and it is used to set audio PTS and kick audio data to the consumer (renderer). I hope that this information will help :)...
Whoa, wonderful library unlike these bloated unportable ffmpeg, faad, etc., I wish there were such libraries for other formats. Adding AAC support took about 15 minutes (well, not counting messing with the ringbuffer).
The only problem right now is that that half-assed QT/MP4 demuxer doesn't recognize mono streams, so it ends up outputting static from one channel.
Btw., where it's better to abort codec initialization - at Init or Open?
I'll upload that shortly.
And btw., just courious, do you remember how much speedup you gained from optimizing MPEG-4 decoder?