After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 708772 - caps: caps in structure are converted by serialization / deserialization to simple structure with more fields
caps: caps in structure are converted by serialization / deserialization to s...
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
unspecified
Other Linux
: Normal normal
: 1.3.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-09-25 17:16 UTC by Mathieu Duponchelle
Modified: 2014-05-04 10:25 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Simple python script to examplify, second field number should be 1 (525 bytes, text/x-python)
2013-09-25 17:16 UTC, Mathieu Duponchelle
  Details
value: fix caps serialization when there are caps inside caps (2.24 KB, patch)
2013-09-25 22:12 UTC, Thiago Sousa Santos
committed Details | Review

Description Mathieu Duponchelle 2013-09-25 17:16:15 UTC
Created attachment 255708 [details]
Simple python script to examplify, second field number should be 1

Or, worded otherwise, the fields of the caps become the fields of the structure.
Comment 1 Thiago Sousa Santos 2013-09-25 22:12:06 UTC
Created attachment 255726 [details] [review]
value: fix caps serialization when there are caps inside caps

This fixes this scenario, but how deep do we want to go with this? If we
have caps inside caps inside caps, the pair of "" of level 2 will clash with
the ones from level 3 and it will break. Also if there is any string containing
*"* it will break the parsing.

Do we want to care about those scenarios? Doesn't seem common for our current use
cases.
Comment 2 Mathieu Duponchelle 2013-09-26 16:44:28 UTC
Yes of course, having a single token for opening and closing doesn't lend itself very well to recursion :)

A solution would be to use <video/x-raw, format=blabla> but that introduces a new set of reserved tokens.

My favorite solution, but I'm not sure it could be merged, would be to go from a C-type cast syntax to a functionnal cast syntax for the type of the field, like so:

instead of having (GstCaps) video/x-raw, format=blabla ,

you would have GstCaps(video/x-raw, format=blabla).

Would be super nice but not sure we could change the syntax like that :)

Anyway we worked around it so that's not critical to us, would just be nice if it could be done :)
Comment 3 Tim-Philipp Müller 2013-09-26 16:52:49 UTC
I don't think we care about caps-in-caps (structure-in-structure: maybe, but not caps-in-caps imho)
Comment 4 Thiago Sousa Santos 2013-09-26 17:01:45 UTC
Dash/smoothstreaming demuxers use caps in caps, but just one level.
Comment 5 Tim-Philipp Müller 2013-09-26 17:10:29 UTC
Oh, I thought that was discussed and we wanted to fix that :-/ It should still be fixed really if possible at all
Comment 6 Sebastian Dröge (slomo) 2013-09-28 11:11:21 UTC
I think the attached patch is fine, let's keep it that way and put something in the documentation to warn about the limitations.
Comment 7 Sebastian Dröge (slomo) 2013-09-28 11:12:02 UTC
Comment on attachment 255726 [details] [review]
value: fix caps serialization when there are caps inside caps

Please push after adding something to the docs that warns about the limitations
Comment 8 Thiago Sousa Santos 2013-09-30 19:25:04 UTC
commit 007c0e5fe155abbc3fc0d801c47ba7388cda3f48
Author: Thiago Santos <ts.santos@partner.samsung.com>
Date:   Wed Sep 25 19:06:55 2013 -0300

    value: fix caps serialization when there are caps inside caps
    
    Wrap caps strings so that it can handle serialization and deserialization
    of caps inside caps. Otherwise the values from the internal caps are parsed
    as if they were from the upper one
    
    https://bugzilla.gnome.org/show_bug.cgi?id=708772