[vlc-devel] [PATCH] access: dvb: Realloc block to actually used size.

[Julian Scheel]

Am 20.09.2013 18:58, schrieb Denis Charmet:
> Le vendredi 20 septembre 2013 à 02:42:08, Julian Scheel a écrit :
>> I just had a look at block_Chain. As this seems to be a linked list
>> of blocks it wouldn't solve the issue in first place. One might
>> reduce the buffer size in first place and then chain the smaller
>> buffers, but I don't see much advantage over just using smaller
>> buffers then.
> Less unused memory by packet, udp usually use the MTU so it could easily
> be reduced to 7 TS packets.
>
>> If a majority would reject the realloc
>> solution, which in fact is used in several access modules as of now,
>> I might give a try on dynamic adaptation.
>>
> For the record, I wasn't rejecting the realloc, just stating that it's a
> debatable stance. Everyone has an opinion on it, I'm also interested in
> other point of view about that.
>
>> Regarding the mem vs perf discussion: I understand that you won't
>> care about 200MB wasted RAM on a 16GB RAM machine, but seeing VLC
>> being used on embedded and mobile devices 200MB wasted RAM are a
>> major issue.
>
> I'm afraid of your streams if you can lose 200 MB of data in buffering
> (especially with low bandwidth ones) and I can't really picture the dtv
> access as an major access used on embedded application. But fair enough,
> just beware of the memory fragmentation.

I just did some further investigation of the current behaviour. Watching 
a common SDTV channel with 8MBit/s I have roughly 4 TS packets per read. 
With the Radio channels, which initially triggered my issue it's 1 
packet per read, in rare cases 2 packets per read.
Even taking into account that HDTV streams might have 12MBit/s 
allocating for 20 packets seems a bit too much. Except for the case 
where one wants to capture a whole transportstream. I don't know how 
common that case is.

So actually as of now there will be a realloc in almost every read 
procedure, which indeed sounds a bit costly. Still a shrinking realloc, 
assuming that the realloc implementation is a good one, would only free 
the left-over memory, which again is not too costly.

So what would you guys say? Reduce the BUFSIZE to something like 5 
packets and never Realloc, which will still waste some memory, but less? 
Make BUFSIZE dynamically changing to previous read-size + 1? Or some 
more sophisticated shaping algorithm?
Or just take the reallocs and assume that the implementations will 
perform well?

Julian