[vlc-devel] [PATCH 5a/5] stream_ReadLine: control maximum length with object variable

[Rémi Denis-Courmont]

Le maanantaina 7. syyskuuta 2020, 19.32.30 EEST Pierre Ynard via vlc-devel a 
écrit :
> > It is not irrelevant. Could we read a 16 MiB line at once? Yes. But
> > unlike say the stream buffer or the picture pools, there can be many
> > read lines concurrently.
> 
> I'm not sure what you mean. As far as I understand, the input thread can
> read only one line at a time; so it's the same principle as the stream
> buffer or picture pools. Unless you're talking about several inputs at
> the same time, but then that doesn't change the point.

And the caller can retain many line buffers around, e.g. the subtitle filter.

Again, it's about what is reasonable for a line-based format, not what is 
maybe realistic to hold in RAM (though depending on the number of lines, that 
might be even less).

(...)
> It does use peek(), but only at the beginning of the loop iteration.

If so, you're welcome to fix it. That's the code that hasn't seen revectoring 
in the longest of the entire stream.c file.

You will note that this makes the function ever more certainly quadratic in 
complexity, and imposes on memory allocation within the generic stream (non-
line-based) code, so you will have to the line size even lower than it already 
is...

-- 
レミ・デニ-クールモン
http://www.remlab.net/