[FFmpeg-devel] [PATCH] fix crash in realmedia demuxer

Jai Menon jmenon86
Fri Dec 26 07:38:55 CET 2008


Hi,

On Wed, Dec 24, 2008 at 7:14 PM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
> Hi Jai,
>
> On Wed, Dec 24, 2008 at 1:26 AM, Jai Menon <jmenon86 at gmail.com> wrote:
>> I don't know if I understood you correctly but I didn't remove any
>> checks. The sample
>> crashes with rmdec.c from svn head. I didn't explore further so don't
>> know why that
>> that check has no effect. From a brief glance, it seems that validity
>> of sub_packet_size
>> is not checked when the desc field is "dnet", that is AC3 streams.
>
> All indeed correct, sorry for not noticing the dnet slip.
>
>> So sub_packet_size is zero
>> when parsing this packet and when the demuxer comes across a cook
>> audio packet it blows up.
>> Anyway, you might want to come up with a better analysis :-)
>
> Just the obvious question, since I'm too lazy to test: does it work?
> Might be worth testing cook-samples with a zero sub_packet_size and
> see if these work. If so, you could remove the cook-check that I cited
> above also. One of the .rm samples on mphq has a zero sub_packet_size.

First off, very sorry for the late reply, because of the holiday season :-)
Well, the patch doesn't really allow playback and that was expected.
It was just a temporary fix for the crash.
I'm sure something could be hacked up, but that won't really solve anything.
So until we understand how to work with samples with zero
sub_packet_size, why not add the same sanity check
for ac3 streams. Attached patch demonstrates this.

> Ronald

-- 
Regards,

Jai
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_rmdec_crash.diff
Type: application/octet-stream
Size: 1015 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081226/c2d9084d/attachment.obj>



More information about the ffmpeg-devel mailing list