UMC: MPEG2 Decoder Crash

UMC: MPEG2 Decoder Crash

Hi,I've encountered a case where the MPEG2 decoder crashes. I havenumThreads set to 8 and there appears to be a problem correctly setting up the internal worker threads. One of theMPEG2VideoDecoderBase::ThreadWorkingRoutine instances will callDecodeSlices with null buffer pointers (IppVideoContext::bs_* values are all NULL or zero).This seems to happen whenm_nNumberOfThreads andcurr_thread do not match after the thread initialization loop inMPEG2VideoDecoderBase::DecodePicture.I can reproduce this with simple_player like this:simple_player.exeD:\\crash.m2v -vnul -t 8This only happens for certain MPEG2 bistreams. Has anyone else seen this issue? Any suggestions on how to work around it?Scott

26 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Hi Scott,

what version of IPP and sample do you use, what is your target cpu, OS? Is it possible to attach problem stream here to help us reproduce and investigate the problem?

Regards,
Vladimir

Hi,I'm using IPP 6.1 and samples 6.1.6.065. I reproduced this with Windows 7 running on two Xeon X5550processors. I'll have to check and see if I can share the stream in question.Thank you,Scott

Hi Vladimir,I've also found a couple of files that show bad visual errors in the decoded frames. Two other MPEG2 decoders do not show these errors and I am fairly confident that the file itself is good. Can I share this clip with you as well?Scott

yes, of course that will be useful

Thanks,
Vladimir

Hi Vladimir,Do you know when I might get some more info on the files I provided?Thank you,Scott

Hi Scott,

we are still looking at your issue.

Regards,
Vladimir

Hi Scott,Looks like we've the solution.Please make the following changes in the codec/mpeg2_dec/src/umc_mpeg2_dec_pic.cpp file :Ipp32s curr_thread;-----------> should be moved from line 925 to line 918Lines 981,982 should be written as : if (curr_thread < m_nNumberOfThreads) m_nNumberOfThreads = curr_thread;Regards,Alexander

Thank you very much, I'll apply thisimmediately. Do you have any more information on the other 'bad frame' issue I reported? I attached the 'bad-frames-intel.m2v' sample file in an earlier private response toVladimir.

What do you mean under "bad frames" - horizontal color bands on two or more frames ?Regards,Alexander

Hi Alexander,Yes, I'm talking about the horizontal color bands. Those are not present with other decoders.Thanks for looking into this.Scott

Hi Vladimir andAlexander,Is there any update on the horizontal color band issue?Scott

Hi Guys,Any update on this issue?Scott

Hi Scott,Thanks for the stream. We've reproduced the problem on IPP 7.0 too. The problem is under investigation now.We'll inform you about our progress.Regards,Alexander

Hi Alexander,Thanks for the update, please let me know if I can provide any more information.Scott

Hi Scott,

I've just found the problem case in MPEG2 decoder.

The solution is the following :

file umc_mpeg2_dec_blk.cpp line 212, column 45 0xab shall be written instead of 0xbb

After this change everything should be OK.

Regards,
Alexander

Thank you! I'll test it and get back to you.

Hi Alexander,I applied the fix, and it resolves the issue with the specific segment I sent you, however I see many more similar errors in the complete file. I will send another sample.Thank you,Scott

Hi Alexander,Happy new year. Any update on the latest visual errors?Thanks,Scott

Hi Scott,Happy new Year.I've just found the problem root case.Please add the following changes:File umc_mpeg2_dec_bstream.h
write#define SHOW_HI9BITS(video, CODE) \CODE = (((video##_curr_ptr[0] << 24) | (video##_curr_ptr[1] << 16) | (video##_curr_ptr[2] << 8)) << video##_bit_offset);#define SHOW_HI9BITS(video, CODE) \CODE = (((video##_curr_ptr[0] << 24) | (video##_curr_ptr[1] << 16) | (video##_curr_ptr[2] << 8)) << video##_bit_offset);instead of#define SHOW_HI9BITS(video, CODE) \CODE = (((video##_curr_ptr[0] << 24) | (video##_curr_ptr[1] << 16)) << video##_bit_offset);Thanks for testing.Regards,Alexander

Hi Alexander,Thanks for the reply.This fixdoesn'tmake a lot of sense to me. The cause of the problem seems to be not having enough bits loaded to property use the MPEG2_DCSIZE_TABtable. I'm not sure that every invocation of SHOW_HI9BITS should be loading an additional 8 bits.Wouldn'ta bettersolutionbe to modifyDECODE_DC() in umc_mpeg2_bstream.h to invokeEXPAND_17BITS() at thebeginningof the outer else branch before it needs the additional bits?Replace this:} else { \ tbl = pTab[32 + (UHBITS(code, 10) & 0x1f)]; \ dct_dc_size = tbl & 0xF; \ len = tbl >> 4; \ EXPAND_17BITS(BS, code); \ EXPAND_25BITS(BS, code); \ code <<= len; \ val = UHBITS(code, dct_dc_size) - UHBITS(SHBITS(~code, 1), dct_dc_size); \ SKIP_BITS(BS, len + dct_dc_size); \} \With this:} else { \ EXPAND_17BITS(BS, code); \ tbl = pTab[32 + (UHBITS(code, 10) & 0x1f)]; \ dct_dc_size = tbl & 0xF; \ len = tbl >> 4; \ EXPAND_25BITS(BS, code); \ code <<= len; \ val = UHBITS(code, dct_dc_size) - UHBITS(SHBITS(~code, 1), dct_dc_size); \ SKIP_BITS(BS, len + dct_dc_size); \} \Does that make sense? Is the behavior ofSHOW_HI9BITS really incorrect?Thank you,Scott

Hi Scott,You wrote "This fixdoesn'tmake a lot of sense to me". But I see no artifacts on streams provided by you.Do you have another streams with artifacts ?Please send it.PSThe behaviour ofSHOW_HI9BITS is incorrect for chrominance blocks with dct_dc_size=11. Additional bit required to get correct data from theMPEG2_DCSIZE_TAB.Regards,Alexander

Hi Alexander,Thank you for explaining the problem, and no I don't see anyadditionalproblems. Are there any cases other than chroma blocks with dct_dcsize=11 where SHOW_HI9BITS needs to load additional bits? I'm just trying to make sure I understand. :)Thanks for all your effort!Scott

Hi Scott,The SHOW_HI9BITS macro needs to load additional bit (only one) in very special case - when internal bit offset is 7 and the dct_dc_size for chroma block is 11 (and 10 to be honest). No such problem for limunance blocks because according to standard dct_sc_size sizes table for luminance uses maximum 9 bits per length and chroma dct_dc_size table uses maximum 10 bits. I've added simple and easy modification to SHOW_HI9BITS for all the cases for unity.This change doesn't affect performance and codec stability I think.Regards,AlexanderPSIf you find any problems you are always welcome.

Hi Alexander,Thanks for taking the time to explain. Iappreciateyour efforts inresolvingthis. So far our batch testing looks great.Scott

Hi Scott,

The fix suggested by Alexander is also included in the 7.0.2 release.

Regards,
Chao

Leave a Comment

Please sign in to add a comment. Not a member? Join today