Hi again,

we found this the other day when using a stream ID containing "%2F",
expecting this to be resolved to "/". While "%2F" could obviously be sent
decoded, "&" (decoded) would currently end the value and not be used, "+"
(decoded) would be overwritten with " ", and "=" (decoded) could cause
entirely unexpected outcomes (albeit all these characters being allowed by
SRT for various string inputs).

As for changing `av_strndup` to `ff_urldecode` (which removes a length
check); I don't think that this particular length check added any
protection (`av_find_info_tag` adds a trailing `\0` if found). This
thinking is also evident at the two other places where `ff_urldecode`
replaced `av_strdup`.

It would be amazing if we could get this merged upstream :)

Best
Armin