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:13 |
tsdgeos | yep | 11:15 |
tsdgeos | data seems correct | 11:16 |
tsdgeos | tom & Jerry is reported as 5,5 | 11:16 |
tsdgeos | which is cartoons/puppets | 11:16 |
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:19 |
Saviq | seems that's what is happening elsewhere in tsparse | 11:20 |
tsdgeos | brrr | 11:22 |
tsdgeos | seems a bad idea to me | 11:22 |
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:23 |
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:24 |
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:25 |
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:26 |
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:27 |
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:28 |
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:29 |
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:31 |
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:32 |
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:33 |
Saviq | yeah I know what you mean | 11:34 |
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:35 |
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:36 |
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:39 |
tsdgeos | attached | 11:43 |
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:44 |
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:45 |
tsdgeos | Saviq: give bbc a phone call? :D | 11:47 |
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 ;) | 11:48 |
Saviq | tsdgeos, http://www.dtg.org.uk/industry/dbook.html | 12:15 |
Saviq | "The D-Book is only available to members of the Digital TV Group." grr | 12:16 |
tsdgeos | :-/ | 12:17 |
Saviq | £5k for a membership | 12:18 |
Saviq | tsdgeos, but anyway: crid_type 50 is programme, 51 is series | 12:19 |
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:29 |
tsdgeos | Saviq: seems the stream you gave me has no content_identifier_descriptor | 12:40 |
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:41 |
Saviq | ;) | 12:42 |
tsdgeos | hmmm | 15:14 |
tsdgeos | implementing thsi without a stream with it is not trivial :-/ | 15:14 |
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:33 |
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:34 |
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:35 |
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:36 |
tsdgeos | since maybe we get the content identifier descriptor before the CIT table? | 16:37 |
Saviq | sure, that's possible | 16:37 |
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 | 16:38 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!