[XviD-devel] crash in get_intra_block()

Michael Militzer michael at xvid.org
Thu May 17 18:54:54 CEST 2007


Hi Rob,

I suppose you may suffer from an access violation. When your input data
is damaged, the decoder may read VL codes from the bitstream that are
not valid. Once a table look-up is performed to decode them, the look-up
might access an address outside the table memory -> crash.

I'd expect the problem could be in get_coeff() actually (which is inlined
and used in get_intra_blocks() e.g.). To make the decoder more robust to
errorness streams, you should try to add checks before each table lookup
in get_coeff to make sure that you really access a legal address.

Since Xvid is mainly targeted towards archiving purpose where stream errors
are seldom and is aimed at good decoder speed, the safety checks in the
decoder are admittedly a bit sparse...

Cheers,
Michael


Quoting Rob Prowel <tempest766 at yahoo.com>:

> hi.
>
> I am designing a wirelessly operated system that uses
> low bitrate 352x240 MPEG4 to tele-operate an unmanned
> vehicle.  My system MUST use 4096 byte fragmented UDP
> to communicate with the robot.  I add some header
> information and reassemble the complete frame upon
> receipt.  I set 30fps and key frames inserted every
> 16th frame, with no B frames.  I am using a PC104
> MPEG4 hardware encoder that I know generates bad
> macroblocks on occasion: IME6400 firmware error that
> the vendor won't fix.  Of course my embedded OS is
> Linux 2.6.17.  Anyway, fixing the firmware is not an
> option.  Also, I must consider that because of UDP
> tranport some of the packets may arrive with pieces
> missing or not at all.
>
> I analyzed a core dump of my operator console
> application and noted that the get_intra_blocks()
> method occasionally causes a segfault.
>
> Anyone care to enlighten me as to how I might fix
> this?  It is possible and probable that I could send
> the decoder occasional bad frame data and it is
> extremely important that the decoder consume the
> correct number of input stream bytes and not crash.
> One characteristic of my use case is that I dont
> typically send a true bitstream to the decoder, but
> only a discrete frames worth of data, with the
> exception being that each key frame is always
> preceeded by a 27 byte VOL header frame.  The hardware
> encoder does it that way.
>
> I noted some DEBUG macros in the get_intra_blocks()
> method so I'm guessing someone might be familiar with
> why my problem exists.
>
> Any help will be appreciated.
>
> -Rob Prowel
>
>
> I told my pap and mam I was coming to the mountains to trap and be a  
>  mountain man. Acted like they was gut-shot. Says, "son, make your   
> life go here. Here's where the peoples is. Them mountains is for   
> animals and savages." I said, "Mother Gue, the Rocky Mountains is   
> the marrow of the world." And by God I was right. -- Dell Gue   
> "Jeramiah Johnston, (1972)"
>
>
>
> ____________________________________________________________________________________Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it   
> out.
> http://answers.yahoo.com/dir/?link=list&sid=396545469
> _______________________________________________
> XviD-devel mailing list
> XviD-devel at xvid.org
> http://list.xvid.org/mailman/listinfo/xvid-devel
>
>


More information about the XviD-devel mailing list