GNOME Bugzilla – Bug 789842
replace the delimiter for "x-dimensions" or other caps in rtpjpegpay
Last modified: 2017-11-06 02:09:04 UTC
since the main delimiter for caps is <,> it is not a good option to use it again as internal delimiter for specific cap like x-dimensions. x-dimensions value needs to be escaped by double quote which by itself needs to be escaped with a backslash. i have faced issues when parsing a value like x-dimensions=(string)\"640\,480\" to gst_parse_launch. it is not been recognized throwing an error like: Failed to parse field, r=x-dimensions=(string)\"640\,480\" i would suggest to replace the delimiter <,> to <-> for x-dimensions and similar caps. it makes things a bit more clean.
This seems more like a bug in parse_launch or insufficient escaping *somewhere* :) Not sure what your chances are to get this fixed, realistically. I can serialize + deserialize caps again just fine: caps = gst_caps_new_simple ("foo", "x-dim", G_TYPE_STRING, "640, 480", NULL); to_str = gst_caps_to_string (caps); GST_ERROR ("string: %s", to_str); caps2 = gst_caps_from_string (to_str); GST_ERROR ("caps2: %" GST_PTR_FORMAT, caps2); which will print this: foo, x-dim=(string)"640\,\ 480" The delimiter is probably not something we made up but from some spec (although I can't find it right now, but other apps/libs use a comma too here), so I don't think we can change it just to work around string escaping issues :)
thank Tim, the correct escaping was the one that you put: x-dim=(string)"640\,\ 480" I'm not sure what does this mean but it seems to me that I'm escaping the space which is not needed in all cases. I tried to simulate the same by inserting backslash before and after the <,> with a space and it works. strange to me. before that i tried many combination without luck: x-dimensions=(string)\"640\,480\" x-dimensions=(string)\"640,480\" x-dimensions=(string)"640,480" x-dimensions=\"640,480\" x-dimensions=\"640\,480\" x-dimensions=(string)640\,480 much appreciated. it solves my problem. (In reply to Tim-Philipp Müller from comment #1) > This seems more like a bug in parse_launch or insufficient escaping > *somewhere* :) Not sure what your chances are to get this fixed, > realistically. > > I can serialize + deserialize caps again just fine: > > caps = gst_caps_new_simple ("foo", "x-dim", G_TYPE_STRING, "640, 480", > NULL); > to_str = gst_caps_to_string (caps); > GST_ERROR ("string: %s", to_str); > caps2 = gst_caps_from_string (to_str); > GST_ERROR ("caps2: %" GST_PTR_FORMAT, caps2); > > which will print this: > > foo, x-dim=(string)"640\,\ 480" > > > The delimiter is probably not something we made up but from some spec > (although I can't find it right now, but other apps/libs use a comma too > here), so I don't think we can change it just to work around string escaping > issues :)
Oh, the space I just made up for some reason. Are you saying it only works if you have a space in there? Can this be closed then?
yes, it can be closed. backslash with space after the comma solved this for me ! the code is tested on android. for testing, i tried this: x-dimensions=(string)"3280\,\2464" and it gives me: Trying to set string on structure field 'x-dimensions', but string is not valid UTF-8. Please file a bug so the only one that works for me is: x-dimensions=(string)"3280\,\ 2464" thanks
The backslash before the 2464 makes no sense to me. Have you tried just removing that? Anyway, good to hear it works now. (Also, in some contexts interpreters or compilers may interpret strings containing "\2464" as make-a-character-from-this-octal/decimal-number fwiw, which may well result in invalid UTF-8 warnings then.)
(In reply to Tim-Philipp Müller from comment #5) > The backslash before the 2464 makes no sense to me. Have you tried just > removing that? yes of course, but it didn't work.