[11:13] <tsdgeos> Saviq: do we have a bug for the content descriptor stuff like we had for the extended descriptor one?
[11:13] <Saviq> tsdgeos, not yet
[11:13] <Saviq> tsdgeos, doing
[11:13] <tsdgeos> goodie
[11:13] <Saviq> already fixed? ;)
[11:15] <tsdgeos> yep
[11:16] <tsdgeos> data seems correct
[11:16] <tsdgeos> tom & Jerry is reported as 5,5
[11:16] <tsdgeos> which is cartoons/puppets
[11:19] <Saviq> puppets: D
[11:19] <Saviq> cool
[11:19] <Saviq> I wonder, though, if we should interpret it in gstreamer
[11:19] <Saviq> and push a text value down the line
[11:20] <Saviq> seems that's what is happening elsewhere in tsparse
[11:22] <tsdgeos> brrr
[11:22] <tsdgeos> seems a bad idea to me
[11:23] <tsdgeos> don't see gstreamer supporting localization
[11:23] <Saviq> nah, without localization
[11:23] <Saviq> https://bugzilla.gnome.org/show_bug.cgi?id=672538 btw
[11:23] <tsdgeos> right
[11:23] <tsdgeos> but then the upper layer has quick a problem to support localization
[11:24] <tsdgeos> since has to magically guess all possible values coming from gstreamer
[11:24] <tsdgeos> to support their localization
[11:24] <Saviq> well there's no guessing if you can look at the code
[11:24] <Saviq> tbh gstreamer should probably even provide translations to those strings
[11:25] <tsdgeos> looking at the code is a poor way of documentation :D
[11:25] <Saviq> in a domain somewhere
[11:25] <tsdgeos> and the moment new strings or strings are changed
[11:25] <Saviq> tsdgeos, well, spec, then
[11:25] <tsdgeos> you are left in the cold
[11:25] <Saviq> you'd have to look at the spec anyway to implement translation from "5,5" into "cartoons/puppets"
[11:26] <tsdgeos> sure
[11:26] <tsdgeos> the thing is
[11:26] <tsdgeos> i don't see us giving strings is "better"
[11:26] <tsdgeos> i just see it creating more work for the library user
[11:26] <tsdgeos> unless of course he doesn't care about localization
[11:27] <tsdgeos> but those people don't exist ;-)
[11:27] <Saviq> more work? why? otherwise he'd just have to implement it himself
[11:27] <Saviq> the whole mapping _and_ localization part
[11:28] <Saviq> let's ask #gstreamer then :
[11:28] <Saviq> IMO the best way would be to send strings down _and_ supply translations in a domain somewhere
[11:29] <tsdgeos> more work because instead of simply switching integers you have to "switch" strings
[11:29] <tsdgeos> that is not that easy in C :D
[11:29] <Saviq> and then "switch" strings, too
[11:29] <tsdgeos> Saviq: sure, that'd be the best
[11:29] <tsdgeos> Saviq: en then switch strings? no, then you just return myi18nfunction("cartoons/puppets)
[11:31] <Saviq> yes, so if you get "cartoons/puppets" from gstreamer, you'd just do the same ;)
[11:31] <Saviq> let's see what #gstreamer has to say
[11:31] <tsdgeos> no, you wouldn't do the same
[11:32] <tsdgeos> since you'd do myi18nfunction(whatever_variable_we_return_from_gst)
[11:32] <tsdgeos> but since the text of whatever_variable_we_return_from_gst is not in your app
[11:32] <tsdgeos> it wouldn't get extracted
[11:32] <tsdgeos> and translators wouldn't have any chance to translate it
[11:33] <tsdgeos> which means he would have to "fake" the strings somewhere just to appear in the translation catalog
[11:33] <tsdgeos> done that a few times
[11:33] <tsdgeos> is a bit cumbersome from the app programer pov
[11:34] <Saviq> yeah I know what you mean
[11:35] <Saviq> but otoh each and every app will have to implement the whole thing itself
[11:35] <Saviq> and there are, after all, things like _NOOP for exactly that reason
[11:36] <Saviq> so that you can put a list in a file somewhere (that you'd have to do anyway to implement the mapping yourself)
[11:36] <Saviq> only not "in a file somewhere", just straight in code
[11:36] <tsdgeos> sure
[11:39] <Saviq> tsdgeos, attach the patch to https://bugzilla.gnome.org/show_bug.cgi?id=672538
[11:39] <Saviq> tsdgeos, and let's move the discussion there
[11:39] <tsdgeos> yep
[11:39] <tsdgeos> makes sense
[11:43] <tsdgeos> attached
[11:44] <Saviq> I wonder where the "user defined" can be derived from ;)
[11:44] <Saviq> like for example crid for bbc looks like so
[11:44] <Saviq>             DVB-DescriptorTag: 118 (0x76)  [= content_identifier_descriptor]
[11:44] <Saviq>             descriptor_length: 9 (0x09)
[11:44] <Saviq>             crid_type: 49 (0x31)  [= user defined]
[11:44] <Saviq>             crid_location: 0 (0x00)  [= Carried explicitly within descriptor]
[11:44] <Saviq>             crid_len: 7 (0x07)
[11:44] <Saviq>             crid_bytes:
[11:44] <Saviq>                  0000:  2f 41 42 4c 49 47 42                               /ABLIGB
[11:44] <Saviq>             DVB-DescriptorTag: 118 (0x76)  [= content_identifier_descriptor]
[11:45] <Saviq>             descriptor_length: 9 (0x09)
[11:45] <Saviq>             crid_type: 50 (0x32)  [= user defined]
[11:45] <Saviq>             crid_location: 0 (0x00)  [= Carried explicitly within descriptor]
[11:45] <Saviq>             crid_len: 7 (0x07)
[11:45] <Saviq>             crid_bytes:
[11:45] <Saviq>                  0000:  2f 4c 30 36 32 35 4f                               /L0625O
[11:45] <Saviq> so the "ABLIGB" and "L06250" are the actual CRIDs
[11:45] <Saviq> that, I believe, are sent as related content ids in RCT
[11:45] <Saviq> but one is type 45, the other type 50 - both user defined
[11:45] <Saviq> *49
[11:47] <tsdgeos> Saviq: give bbc a phone call? :D
[11:48] <Saviq> tsdgeos, you know what the funniest thing is?
[11:48] <Saviq> in the case of BBC it might actually work and they'd tell you ;)
[12:15] <Saviq> tsdgeos, http://www.dtg.org.uk/industry/dbook.html
[12:16] <Saviq> "The D-Book is only available to members of the Digital TV Group." grr
[12:17] <tsdgeos> :-/
[12:18] <Saviq> £5k for a membership
[12:19] <Saviq> tsdgeos, but anyway: crid_type 50 is programme, 51 is series
[12:29] <Saviq> tsdgeos, to follow up on content descriptor... we can always send both :)
[12:29] <Saviq> or maybe we should, even
[12:29] <tsdgeos> that's the other possibilty yes
[12:29] <Saviq> so that apps can react to stuff like 0
[12:29] <Saviq> and not care about what the text says
[12:40] <tsdgeos> Saviq: seems the stream you gave me has no content_identifier_descriptor
[12:41] <Saviq> tsdgeos, yes, that does not
[12:41] <Saviq> tsdgeos, we'll have to get some from UK
[12:41] <Saviq> maybe someone around has a DVB-T device in the UK?
[12:41] <Saviq> ping all ;
[12:42] <Saviq> ;)
[15:14] <tsdgeos> hmmm
[15:14] <tsdgeos> implementing thsi without a stream with it is not trivial :-/
[16:33] <tsdgeos> Saviq: about the crid thing, it can be either internal (location 0) or external (location 1)
[16:33] <tsdgeos> and if it's external
[16:33] <Saviq> tsdgeos, yes I learned that, too
[16:33] <Saviq> we need to parse CIT, too
[16:33] <tsdgeos> right
[16:33] <tsdgeos> the question is
[16:33] <tsdgeos> if we want to "cook" that info at the gstreamer level
[16:33] <tsdgeos> probably not?
[16:34] <tsdgeos> with "cook" i mean
[16:34] <Saviq> yes I get it
[16:34] <tsdgeos> ok :D
[16:34] <Saviq> how do you map data from the descriptor to the CIT?
[16:35] <Saviq> that's something I failed to grasp from the spec
[16:35] <tsdgeos> the descriptor gives you an index
[16:35] <tsdgeos> crid_ref
[16:36] <tsdgeos> and then the CIT table
[16:36] <tsdgeos> has a list of crid_refs
[16:36] <tsdgeos> not sure we can "cook" the data though
[16:37] <tsdgeos> since maybe we get the content identifier descriptor before the CIT table?
[16:37] <Saviq> sure, that's possible
[16:38] <tsdgeos> the upper layer should want to be able of deciding what to do in that case
[16:38] <tsdgeos> i.e. discarding the info
[16:38] <tsdgeos> waiting for the cit table to appear
[16:38] <tsdgeos> busy loop
[16:38] <tsdgeos> crash
[16:38] <Saviq> tsdgeos, yeah, we need to deliver CIT separately
[16:38] <tsdgeos> :D