Writefilestart string length too short

[tin3tin]

I wonder if it would be possible in the next version of avisynth to make the maximum sting length of Writefilestart much longer?

It would be very useful. :)

[Gavino]

Do you mean the size of the expression string passed into WriteFileStart, or the size of the resulting string that gets written?

[tin3tin]

Actually I don't know if there is a maximum length which cuts the string or if it is writefilestart which cuts it.

[Gavino]

From a quick look at the code, it seems both the expression strings and the result strings are limited to 254 characters.

If you are trying to write out a long string literal, the simple workaround is to split it into smaller parts and pass each part as a separate argument (still in a single call to WriteFileStart). Or you could use this function:
function WriteString(clip c, string file, string s, bool append) {
len = StrLen(s)
c.WriteFileStart(file, "s.LeftStr(min(len, 254))", append)
len > 254 ? WriteString(file, s.RightStr(len-254), true): last
}
Note that here the string s is the actual string to be printed, not an expression.

[tin3tin]

From a quick look at the code, it seems both the expression strings and the result strings are limited to 254 characters.
Is that the max length of any string? Or just strings handled by writefilestart?

Do you think there is a speciffic reason for this limitation?

He he, really clever and useful workaround function. Thanks.

[Gavino]

Is that the max length of any string? Or just strings handled by writefilestart?
Just strings handled by the WriteFile family. I believe Avisynth strings in general are limited only by available memory.
Do you think there is a speciffic reason for this limitation?

I see no specific reason for the limit to be 254 rather than some bigger number, but the code simply allocates fixed size arrays (a total of 32 such strings for expressions and results), so I suppose 254 is a reasonable compromise to avoid unnecessary memory use. Most strings will be smaller than that and longer ones can usually be split by hand when writing your script. It only becomes a problem when the string is generated dynamically within the script, or (as I suspect in your case) is generated by an external program.
He he, really clever and useful workaround function. Thanks.
Glad you liked it. :) BTW I've just spotted and corrected a missing parenthesis.

[Guest]

the code simply allocates fixed size arrays (a total of 32 such strings for expressions and results), so I suppose 254 is a reasonable compromise to avoid unnecessary memory use That's hardly reasonable! Suppose we gave 1K to each (which would satisfy the vast majority of cases although 2K would be better). We'd have a massive 32K out of our typical 4GB. :)

Clearly it's a bug that needs fixing.

[Gavino]

I think that the best fix would be to store the strings as AVSValues rather than character arrays. That way, the limit would be effectively removed entirely (and in most cases using less memory than now).

[tin3tin]

Thanks guys. That would be a huge (speed?) improvement, not to have the script slowed down with a lot of writefilestart instances instead of just one. :)

[Gavino]

Thanks guys.
Well, ultimately it will be up to IanB to decide if, when and how the problem will be resolved, but this discussion has at least laid the groundwork.