UMC H264 decoder crashes on decoding Arecont H264 P-frames.

[hete]

Hi,

I am using the UMC H264 decoder for the decoding of Arecont H264.
However the decoder crashes (h264_exception) in DecodeMacroblock_I_CAVLC with exception
h264_exception(UMC_ERR_INVALID_STREAM).
This only happens when decoding P-slices, I-slices are decoded correctly.

Also I get random garbage at the bottom of frames when playing with simple_player.

This matter was also brought up earlier,please check:
http://software.intel.com/en-us/forums/showthread.php?t=65761

However that thread ended without any data on addressing the matter and a solution (update/workaround).

Attached a file with Arecont H264 bitstream.

Any solution/workaround?

Any help would really be appreciated as I am getting into a squeeze here.

Many thanks!

Henk

[Vladimir_Dudnik]

Hello,

the conclusion made atthethread you pointed out wasthat UMC H.264 decoder may have throubles working with corrupted streams. In fact, reference decoder also report about errors in bistream. The way to handle bitstream errors might be implementation dependant. Your report was propagated to engineering team and you will be notified when/if solution will be ready.

Regards,
Vladimir

[hete]

Quoting - Vladimir Dudnik (Intel)

Hello,

the conclusion made atthethread you pointed out wasthat UMC H.264 decoder may have throubles working with corrupted streams. In fact, reference decoder also report about errors in bistream. The way to handle bitstream errors might be implementation dependant. Your report was propagated to engineering team and you will be notified when/if solution will be ready.

Regards,
Vladimir

Hi Vladimir,

Thank you for your quick response and your reporting the matter to your engineering team.
I agree, bitstream errors in reference decoder open the possiblity of irregularities in the implementation at camera side.

I also did a test with the Videolan VLC 1.0.1 media player which played the H264 flawlessly, no error messages at all at highest verbosity level (2), and also no random garbage at the bottom of the displayed frames.

As I understand it a solution in the form of an update is not to be expected on (very) short notice.

And as the matter has already been brought up a few months ago, is there a possibility some sort of workaround has been found in the mean time? Or possibly some modified UMC source files? I might be able to use them in my
IPP build.

Thanks for your help.

Henk


PS: We use Intel IPP version 6.0.2.074 and ipp samples version 6.0.0.130 for Windows (XP/Vista).

[Vladimir_Dudnik]

I would suggest you to try the latest release which is IPP 6.1 update 1 to see if this work better in your conditions. Regarding players which may show corrupted video without visible artifacts: in case of corrupted data there is no any magic way to restore missed information, I think it just skip frames with errors. This is not what we though theright way to handle such situations, because in case of many errors in successive frames you will not see any video at all whereas in our case you at least will be able to recognize something. Again, I do not talk that one approach is better than other, just matter of design goals.
Anyway, I'm waiting for response from engineering team if there is some workaround.

Regards,
Vladimir

[hete]

Quoting - Vladimir Dudnik (Intel)

I would suggest you to try the latest release which is IPP 6.1 update 1 to see if this work better in your conditions. Regarding players which may show corrupted video without visible artifacts: in case of corrupted data there is no any magic way to restore missed information, I think it just skip frames with errors. This is not what we though theright way to handle such situations, because in case of many errors in successive frames you will not see any video at all whereas in our case you at least will be able to recognize something. Again, I do not talk that one approach is better than other, just matter of design goals.
Anyway, I'm waiting for response from engineering team if there is some workaround.

Regards,
Vladimir

Thanks Vladimir,

I can see the point you are making regarding the IPP design goals.

I also was in comm with Arecont who sent me a new HARDWARE update (received firmware updates did not change the existing situation in any way) whichsolved the matter.

So this settles the matter for me. Thank you very much for your help and assistance.

Henk

[Hugo_J_]

Quoting - Vladimir Dudnik (Intel)

I would suggest you to try the latest release which is IPP 6.1 update 1 to see if this work better in your conditions. Regarding players which may show corrupted video without visible artifacts: in case of corrupted data there is no any magic way to restore missed information, I think it just skip frames with errors. This is not what we though theright way to handle such situations, because in case of many errors in successive frames you will not see any video at all whereas in our case you at least will be able to recognize something. Again, I do not talk that one approach is better than other, just matter of design goals.
Anyway, I'm waiting for response from engineering team if there is some workaround.

Regards,
Vladimir

Vladimir,

I experience the same issue as Henk. Tried it with the latest and greates ipp library (6.1.1.042) and the latest of IPP sampes 6.1.1.050. I still have the same problem. Unfortunately, because I need to cope with Arecont hardware that is already in the field, hardware upgrade is not an option for me.

All that to say that I am well interested in bug fix/work around for that matter.

Regards,
Hugo

[j_miles]

Quoting - Hugo Jacques

Vladimir,

I experience the same issue as Henk. Tried it with the latest and greates ipp library (6.1.1.042) and the latest of IPP sampes 6.1.1.050. I still have the same problem. Unfortunately, because I need to cope with Arecont hardware that is already in the field, hardware upgrade is not an option for me.

All that to say that I am well interested in bug fix/work around for that matter.

Regards,
Hugo

Well, I doubt that there is a suitable work-around let alone a bug-fix for this situation. If the so-called Arecont hardware produces a buggy (non-compliant) stream, there is not, as Vladimir put it, "any magic" that a decoder can do to make it right. I believe that the Intel H.264 sample decoder is to a large degree (?) compliant with the H.264 specification, and thus there is not any bug in the decoder. The reference decoder has revealed that the stream from the Arecont was the problem. Then there is nothing to do on the decoder side except deliver the "best possible" decoding effort (if you want to keep things compliant - and I strongly urge you and anyone else to do so)!

Now for a small rant: I'm starting to get tired of hearing that "VLC decodes it without problems, ergo there is no problem with the stream". VLC is not a reference decoder! It has a great decoder (built upon x264, I think?), no doubt, and a nice piece of open-source software achievement. But it is not a reference decoder. Certainly, I am not even sure that it is compliant to the spec. in all the tinyest of details. For the handling of erroneous streams, VLC has chosen one way of handling it, and Intel another, and other decoders may use something entirely different. I just wish implementors of the H.264 specification (on both the encoding and the decoding side) would be more precise and quality-minded in adhering strictly to the standard. Sorry - I had to vent.
(Note: This was not meant as a poke to anyone here, as I can appreciate the reasons for using a broad set of tools. I do the same...).


- Jay

[Hugo_J_]

Quoting - j_miles

Well, I doubt that there is a suitable work-around let alone a bug-fix for this situation. If the so-called Arecont hardware produces a buggy (non-compliant) stream, there is not, as Vladimir put it, "any magic" that a decoder can do to make it right. I believe that the Intel H.264 sample decoder is to a large degree (?) compliant with the H.264 specification, and thus there is not any bug in the decoder. The reference decoder has revealed that the stream from the Arecont was the problem. Then there is nothing to do on the decoder side except deliver the "best possible" decoding effort (if you want to keep things compliant - and I strongly urge you and anyone else to do so)!

Now for a small rant: I'm starting to get tired of hearing that "VLC decodes it without problems, ergo there is no problem with the stream". VLC is not a reference decoder! It has a great decoder (built upon x264, I think?), no doubt, and a nice piece of open-source software achievement. But it is not a reference decoder. Certainly, I am not even sure that it is compliant to the spec. in all the tinyest of details. For the handling of erroneous streams, VLC has chosen one way of handling it, and Intel another, and other decoders may use something entirely different. I just wish implementors of the H.264 specification (on both the encoding and the decoding side) would be more precise and quality-minded in adhering strictly to the standard. Sorry - I had to vent.
(Note: This was not meant as a poke to anyone here, as I can appreciate the reasons for using a broad set of tools. I do the same...).


- Jay

Jay and Vladimir,

I totally understand that if the H.264 bitstream is corrupted/non-compliant stream, there will likely be garbagee displayed when the decoded video is rendered. I am not disputing that at all. Garbage in, garbage out.

From my point of view, what is unexpected is that the application crashes. This happens under Windows (as Henk explained) and Linux (segmentation fault) on my system.

I understand that it can be very difficult to obtain this level of robustness and it could potentially add quite a bit of overhead to perform parano checking at many places in the code.

I would just like to know if you will attempt not to have the app crashing with a corrupted bit stream.

BTW, we just migrated from IPP 5.3 (not libs an samples) to 6.1 and the 5.3 lib+apps combo was not crashing with the Arecont non-compliant bitstream. Of course, decoding performance were not the same.
You guys did a fantastic job at improving the H.264 decoder performance.


That said, Jay, I understand your frustration and your need to vent. That happens to me from time to time too ;)

On another topic, I found a few bugs in the ipp-samples (race conditions, uninitilized variables being tested, memory leaks). Where could I post the (my) fixes?

Hugo

[Vladimir_Dudnik]

Hi Hugo,

Of course UMC codecs should not cause application crash.In case it happens weconsider such as an error and are committed to provide fix in the future versions. So when you meet the problems please feel free to submitbugs against corresponding component. You can report on issues here or if you hold a valid IPP license you may submit issues to Intel Premier Support.

Thanks for your interest to IPP media codecs.

Regards,
Vladimir

[j_miles]

Hi Hugo,

Well, it seems it was a bit late in the night, because I seemed to have missed the "crash fact". Obviously that should be fixed. But what may have made me ignore it is the fact that the original reporter talks about a C++ exception and not a system esception (e.g. access violation). As some of the design choices behind the UMC framework is unknown to us, it is not clear but I would think that the C++ exception should not "escape" the decoder and there are suitable "catches" in the code to avoid that - but there might be missing some. Even then a suitable catch on outside of the decoder can solve it.

As Vladimir puts it, I think the normal way and the moste ffective way of reporting errors is through the Premier support. But I guess there are others that could benefit from you also reporting them here...


- Jay

[Hugo_J_]

Quoting - j_miles

Hi Hugo,

Well, it seems it was a bit late in the night, because I seemed to have missed the "crash fact". Obviously that should be fixed. But what may have made me ignore it is the fact that the original reporter talks about a C++ exception and not a system esception (e.g. access violation). As some of the design choices behind the UMC framework is unknown to us, it is not clear but I would think that the C++ exception should not "escape" the decoder and there are suitable "catches" in the code to avoid that - but there might be missing some. Even then a suitable catch on outside of the decoder can solve it.

As Vladimir puts it, I think the normal way and the moste ffective way of reporting errors is through the Premier support. But I guess there are others that could benefit from you also reporting them here...


- Jay

Jay, Vladimir,

I submitted an issue to Intel Premier Support (#560785). Also for the benefit of others, I am replicating the info I submitted there.

Hugo

*****
I get the umc_h264_dec_con to segmentation faults on some h.264 files.

Setup:
OS: Linux CentOS 5 2.6.18-53.el5
IPP: l_ipp_ia32_p_6.1.1.042.tar.gz
IPP-samples: l_ipp-samples_p_6.1.1.050.tgz

Repro steps:
Building audio-video-codecs
Running umc_h264_dec_con on the attached Street_20_08_09_crash.h264 file (produced with an Arecont camera),
[ ./umc_h264_dec_con -i Street_20_08_09_crash.h264 -o output.yuv ]

Result:
umc_h264_dec_con crashes (Segmentation fault)

Notes: The bitsream in the Street_20_08_09_crash.h264 file might be non-conformant to the h.264 standard.
Reference to this issue can be found at: http://software.intel.com/en-us/forums/showthread.php?t=67761

[Hugo_J_]

Quoting - Hugo Jacques

Jay, Vladimir,

I submitted an issue to Intel Premier Support (#560785). Also for the benefit of others, I am replicating the info I submitted there.

Hugo

*****
I get the umc_h264_dec_con to segmentation faults on some h.264 files.

Setup:
OS: Linux CentOS 5 2.6.18-53.el5
IPP: l_ipp_ia32_p_6.1.1.042.tar.gz
IPP-samples: l_ipp-samples_p_6.1.1.050.tgz

Repro steps:
Building audio-video-codecs
Running umc_h264_dec_con on the attached Street_20_08_09_crash.h264 file (produced with an Arecont camera),
[ ./umc_h264_dec_con -i Street_20_08_09_crash.h264 -o output.yuv ]

Result:
umc_h264_dec_con crashes (Segmentation fault)

Notes: The bitsream in the Street_20_08_09_crash.h264 file might be non-conformant to the h.264 standard.
Reference to this issue can be found at: http://software.intel.com/en-us/forums/showthread.php?t=67761

Guys,

This crash problem is only present with IPP 6.1.1.042 and it was not in the 6.0.2.076. So we are now using a slightly older version of IPP under Linux and it solved our issue.

Hugo

[j_miles]

Quoting - Hugo Jacques

Guys,

This crash problem is only present with IPP 6.1.1.042 and it was not in the 6.0.2.076. So we are now using a slightly older version of IPP under Linux and it solved our issue.

Hugo

Hi Hugo,

Interesting - so what you are experiencing is not merely a C++ exception but a system exception. Have you tried different processor optimization levels - and what about the "non-optimized" version (PX/MX)?


- Jay

[Hugo_J_]

Quoting - j_miles

Hi Hugo,

Interesting - so what you are experiencing is not merely a C++ exception but a system exception. Have you tried different processor optimization levels - and what about the "non-optimized" version (PX/MX)?


- Jay

Jay,

That's right, it is a system exception. No I have not tried various optimization levels. Unfortunately, I spent more time than expected on this issue so I won't have time to experiment with various optimizations scenarios. I leave it to you as an exercise ;)

Hugo

[j_miles]

Quoting - Hugo Jacques

Jay,

That's right, it is a system exception. No I have not tried various optimization levels. Unfortunately, I spent more time than expected on this issue so I won't have time to experiment with various optimizations scenarios. I leave it to you as an exercise ;)

Hugo

Hugo,

All right, I can appreciate that. But it might help Intel support (and anyone up for the "exercize" - my time won't allow) to know which processor and thus which optimization dispatch level you are running at.

Good luck with the project.


- Jay

[Hugo_J_]

Quoting - j_miles

Hugo,

All right, I can appreciate that. But it might help Intel support (and anyone up for the "exercize" - my time won't allow) to know which processor and thus which optimization dispatch level you are running at.

Good luck with the project.


- Jay

Jay,

below is the cpuinfo.

- Hugo

# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel Core2 Duo CPU T7250 @ 2.00GHz
stepping : 8
cpu MHz : 1993.800
cache size : 2048 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss nx constant_tsc pni ds_cpl
bogomips : 3954.94

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel Core2 Duo CPU T7250 @ 2.00GHz
stepping : 8
cpu MHz : 1993.800
cache size : 2048 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss nx constant_tsc pni ds_cpl
bogomips : 4038.43

[Emmanuel_W_]

Quoting - j_miles

Hi Hugo,

Well, it seems it was a bit late in the night, because I seemed to have missed the "crash fact". Obviously that should be fixed. But what may have made me ignore it is the fact that the original reporter talks about a C++ exception and not a system esception (e.g. access violation). As some of the design choices behind the UMC framework is unknown to us, it is not clear but I would think that the C++ exception should not "escape" the decoder and there are suitable "catches" in the code to avoid that - but there might be missing some. Even then a suitable catch on outside of the decoder can solve it.

As Vladimir puts it, I think the normal way and the moste ffective way of reporting errors is through the Premier support. But I guess there are others that could benefit from you also reporting them here...


- Jay

I am not sure it is directly related to this thread but I have noticed that most of thecrash that happen in the decoder are related to referencing a non existing reference frame (due to corrupted stream or missing data). One easy way to solve these is to valdiate the reference frame idx ofMBs between decoding and reconstruction and make sure they fall within the number of active reference frames. If not the index can be adjusted to the closest temporal reference.
This has greatly improved the stability and visual quality overall of the decoder in case of corrupted stream for me.

Emmanuel

[Hugo_J_]

Quoting - eweber

I am not sure it is directly related to this thread but I have noticed that most of thecrash that happen in the decoder are related to referencing a non existing reference frame (due to corrupted stream or missing data). One easy way to solve these is to valdiate the reference frame idx ofMBs between decoding and reconstruction and make sure they fall within the number of active reference frames. If not the index can be adjusted to the closest temporal reference.
This has greatly improved the stability and visual quality overall of the decoder in case of corrupted stream for me.

Emmanuel

Emmanuel,

Unfortunately, I am currently not familiar enough with H.264 decoding to code this myself ;)

Could yoy post the modifications you made to the code to get such improvements. I am sure this coudl benefit to many people.

Hugo