GNOME Bugzilla – Bug 590667
caps parsing regressions.
Last modified: 2009-08-04 13:47:43 UTC
The following pipeline used to work fine but is broken in git: gst-launch udpsrc caps="application/x-rtp, sprop-parameter-sets=(string)\"Z01AFZJUCg/YCIAAAAMAgAAAHkeLF1A\\=\\,aO48gA\\=\\=\"" ! fakesink The problem seems to be that due to (likely?) more escaping, the = character is not considered to be an ASCII character in gst_string_unwrap() and then it fails to parse.
Created attachment 139806 [details] [review] possible patch An ugly ad-hoc patch
Not sure what to do with this one. On the one hand, the patch seems acceptable in the interests of backwards-compatibility. On the other hand, serialising that caps 'correctly' (or calling gst_caps_to_string) would produce "application/x-rtp, sprop-parameter-sets=(string)"Z01AFZJUCg/YCIAAAAMAgAAAHkeLF1A\=\,aO48gA\=\=" with the = signs escaped as well... I think we should put the patch in...
I think it used to escape all inside the first string (and second string) and then when parsing the second string, if would correctly escape the = because it was escaped twice. With current git it somehow manages to escape too much. I think the rules would be something like this: foo= -> "foo\=" a b"foo\="= -> "a\ b\"foo\=\"\=", don't escape inside string, count open/close quotes and back: "a\ b\"foo\=\"\=" -> unescape, don't go inside nested string, ie, count open and close "
strangely, this works: gst-launch udpsrc caps='application/x-rtp, sprop-parameter-sets=(string)\"Z01AFZJUCg/YCIAAAAMAgAAAHkeLF1A\\=\\,aO48gA\\=\\=\"' ! fakesink It seems that the terminal is escaping some more.
after bisect: 7bf3554228f52e06e465fc02d31ac4b1b267ff7d structure: Change NULL and empty string handling changed behaviour.
It's because the " of the string are kept as long as possible to detect NULL and "NULL" this causes extra unwrap which then fails because the shell unescaped the strings. I would say this is not a bug then, one has to use the ' on the shell.
OK, let's close it then