[FFmpeg-devel] fix a bug for mmsh because the packet len is too large

Ronald S. Bultje rsbultje
Sun Aug 29 02:00:21 CEST 2010


Hi,

On Wed, Aug 25, 2010 at 11:52 AM, zhentan feng <spyfeng at gmail.com> wrote:
> Hi
>
> On Tue, Aug 24, 2010 at 11:55 PM, Ronald S. Bultje <rsbultje at gmail.com>wrote:
>
>> Hi,
>>
>> On Tue, Aug 24, 2010 at 11:44 AM, zhentan feng <spyfeng at gmail.com> wrote:
>> > the patch fix a bug because the link below is failed (reported by Tamas
>> > Selmeci)
>> > mmsh://
>> >
>> a1635.v24937.c2493.g.vm.akamaistream.net/7/1635/2493/v0001/premrad.download.akamai.com/2493/premiere_rock_report/Country_Report.wma
>> >
>> > according to the spec, the largest packet length is 65535.
>> > so we change the receive buffer size.
>> [..]
>> > --- libavformat/mmsh.c ? ? ? ?(revision 24901)
>> > +++ libavformat/mmsh.c ? ? ? ?(working copy)
>> > @@ -214,7 +214,7 @@
>> > ?{
>> > ? ? ?int i, port, err;
>> > ? ? ?char httpname[256], path[256], host[128], location[1024];
>> > - ? ?char *stream_selection;
>> > + ? ?char *stream_selection = NULL;
>> > ? ? ?char headers[1024];
>> > ? ? ?MMSHContext *mmsh;
>>
>> Unrelated and unecessary (not used before being allocated just below).
>>
>>
> see the new patch 1 and 2.
> I think this is more safe.
> fix the segment fault error with the test link in last mail.

I apologize, I misread the original patch, it's OK so I've applied it.
Sorry for messing up.

>> --- libavformat/mms.h (revision 24901)
>> > +++ libavformat/mms.h (working copy)
>> > @@ -39,7 +39,7 @@
>> >
>> > ? ? ?/** Buffer for incoming packets. */
>> > ? ? ?/*@{*/
>> > - ? ?uint8_t in_buffer[8192]; ? ? ? ? ? ? ///< Buffer for incoming
>> packets.
>> > + ? ?uint8_t in_buffer[65535]; ? ? ? ? ? ?///< Buffer for incoming
>> packets.
>>
>> Big... Can we keep the original size and get the packet contents in
>> multiple chunks from the TCP layer?
>
> could you explain this further?

So right now, what you do is that every time an ASF packet comes in,
you url_read() it in full from the HTTP layer, and then transmit that
to the demuxer.

It'd be nice if, for these huge packets, you'd only read a small
portion from the HTTP buffer (e.g. the first 8k), and then transmit
that to the demuxer. Then, on the next call to mmsh_read, read the
next 8k, and so on, so that we don't end up with multiple huge buffers
in different layers (kernel->tcp->http->mmsh->asf), but rather forward
data as soon as we read it. This would decrease memory usage in the
mmsh-protocol by 64k-8x=56k, which is quite a lot...

Ronald



More information about the ffmpeg-devel mailing list