#ubuntu-tv 2012-03-21
<tsdgeos> Saviq: do we have a bug for the content descriptor stuff like we had for the extended descriptor one?
<Saviq> tsdgeos, not yet
<Saviq> tsdgeos, doing
<tsdgeos> goodie
<Saviq> already fixed? ;)
<tsdgeos> yep
<tsdgeos> data seems correct
<tsdgeos> tom & Jerry is reported as 5,5
<tsdgeos> which is cartoons/puppets
<Saviq> puppets: D
<Saviq> cool
<Saviq> I wonder, though, if we should interpret it in gstreamer
<Saviq> and push a text value down the line
<Saviq> seems that's what is happening elsewhere in tsparse
<tsdgeos> brrr
<tsdgeos> seems a bad idea to me
<tsdgeos> don't see gstreamer supporting localization
<Saviq> nah, without localization
<Saviq> https://bugzilla.gnome.org/show_bug.cgi?id=672538 btw
<tsdgeos> right
<tsdgeos> but then the upper layer has quick a problem to support localization
<tsdgeos> since has to magically guess all possible values coming from gstreamer
<tsdgeos> to support their localization
<Saviq> well there's no guessing if you can look at the code
<Saviq> tbh gstreamer should probably even provide translations to those strings
<tsdgeos> looking at the code is a poor way of documentation :D
<Saviq> in a domain somewhere
<tsdgeos> and the moment new strings or strings are changed
<Saviq> tsdgeos, well, spec, then
<tsdgeos> you are left in the cold
<Saviq> you'd have to look at the spec anyway to implement translation from "5,5" into "cartoons/puppets"
<tsdgeos> sure
<tsdgeos> the thing is
<tsdgeos> i don't see us giving strings is "better"
<tsdgeos> i just see it creating more work for the library user
<tsdgeos> unless of course he doesn't care about localization
<tsdgeos> but those people don't exist ;-)
<Saviq> more work? why? otherwise he'd just have to implement it himself
<Saviq> the whole mapping _and_ localization part
<Saviq> let's ask #gstreamer then :
<Saviq> IMO the best way would be to send strings down _and_ supply translations in a domain somewhere
<tsdgeos> more work because instead of simply switching integers you have to "switch" strings
<tsdgeos> that is not that easy in C :D
<Saviq> and then "switch" strings, too
<tsdgeos> Saviq: sure, that'd be the best
<tsdgeos> Saviq: en then switch strings? no, then you just return myi18nfunction("cartoons/puppets)
<Saviq> yes, so if you get "cartoons/puppets" from gstreamer, you'd just do the same ;)
<Saviq> let's see what #gstreamer has to say
<tsdgeos> no, you wouldn't do the same
<tsdgeos> since you'd do myi18nfunction(whatever_variable_we_return_from_gst)
<tsdgeos> but since the text of whatever_variable_we_return_from_gst is not in your app
<tsdgeos> it wouldn't get extracted
<tsdgeos> and translators wouldn't have any chance to translate it
<tsdgeos> which means he would have to "fake" the strings somewhere just to appear in the translation catalog
<tsdgeos> done that a few times
<tsdgeos> is a bit cumbersome from the app programer pov
<Saviq> yeah I know what you mean
<Saviq> but otoh each and every app will have to implement the whole thing itself
<Saviq> and there are, after all, things like _NOOP for exactly that reason
<Saviq> so that you can put a list in a file somewhere (that you'd have to do anyway to implement the mapping yourself)
<Saviq> only not "in a file somewhere", just straight in code
<tsdgeos> sure
<Saviq> tsdgeos, attach the patch to https://bugzilla.gnome.org/show_bug.cgi?id=672538
<Saviq> tsdgeos, and let's move the discussion there
<tsdgeos> yep
<tsdgeos> makes sense
<tsdgeos> attached
<Saviq> I wonder where the "user defined" can be derived from ;)
<Saviq> like for example crid for bbc looks like so
<Saviq>             DVB-DescriptorTag: 118 (0x76)  [= content_identifier_descriptor]
<Saviq>             descriptor_length: 9 (0x09)
<Saviq>             crid_type: 49 (0x31)  [= user defined]
<Saviq>             crid_location: 0 (0x00)  [= Carried explicitly within descriptor]
<Saviq>             crid_len: 7 (0x07)
<Saviq>             crid_bytes:
<Saviq>                  0000:  2f 41 42 4c 49 47 42                               /ABLIGB
<Saviq>             DVB-DescriptorTag: 118 (0x76)  [= content_identifier_descriptor]
<Saviq>             descriptor_length: 9 (0x09)
<Saviq>             crid_type: 50 (0x32)  [= user defined]
<Saviq>             crid_location: 0 (0x00)  [= Carried explicitly within descriptor]
<Saviq>             crid_len: 7 (0x07)
<Saviq>             crid_bytes:
<Saviq>                  0000:  2f 4c 30 36 32 35 4f                               /L0625O
<Saviq> so the "ABLIGB" and "L06250" are the actual CRIDs
<Saviq> that, I believe, are sent as related content ids in RCT
<Saviq> but one is type 45, the other type 50 - both user defined
<Saviq> *49
<tsdgeos> Saviq: give bbc a phone call? :D
<Saviq> tsdgeos, you know what the funniest thing is?
<Saviq> in the case of BBC it might actually work and they'd tell you ;)
<Saviq> tsdgeos, http://www.dtg.org.uk/industry/dbook.html
<Saviq> "The D-Book is only available to members of the Digital TV Group." grr
<tsdgeos> :-/
<Saviq> Â£5k for a membership
<Saviq> tsdgeos, but anyway: crid_type 50 is programme, 51 is series
<Saviq> tsdgeos, to follow up on content descriptor... we can always send both :)
<Saviq> or maybe we should, even
<tsdgeos> that's the other possibilty yes
<Saviq> so that apps can react to stuff like 0
<Saviq> and not care about what the text says
<tsdgeos> Saviq: seems the stream you gave me has no content_identifier_descriptor
<Saviq> tsdgeos, yes, that does not
<Saviq> tsdgeos, we'll have to get some from UK
<Saviq> maybe someone around has a DVB-T device in the UK?
<Saviq> ping all ;
<Saviq> ;)
<tsdgeos> hmmm
<tsdgeos> implementing thsi without a stream with it is not trivial :-/
<tsdgeos> Saviq: about the crid thing, it can be either internal (location 0) or external (location 1)
<tsdgeos> and if it's external
<Saviq> tsdgeos, yes I learned that, too
<Saviq> we need to parse CIT, too
<tsdgeos> right
<tsdgeos> the question is
<tsdgeos> if we want to "cook" that info at the gstreamer level
<tsdgeos> probably not?
<tsdgeos> with "cook" i mean
<Saviq> yes I get it
<tsdgeos> ok :D
<Saviq> how do you map data from the descriptor to the CIT?
<Saviq> that's something I failed to grasp from the spec
<tsdgeos> the descriptor gives you an index
<tsdgeos> crid_ref
<tsdgeos> and then the CIT table
<tsdgeos> has a list of crid_refs
<tsdgeos> not sure we can "cook" the data though
<tsdgeos> since maybe we get the content identifier descriptor before the CIT table?
<Saviq> sure, that's possible
<tsdgeos> the upper layer should want to be able of deciding what to do in that case
<tsdgeos> i.e. discarding the info
<tsdgeos> waiting for the cit table to appear
<tsdgeos> busy loop
<tsdgeos> crash
<Saviq> tsdgeos, yeah, we need to deliver CIT separately
<tsdgeos> :D
#ubuntu-tv 2012-03-22
 * tsdgeos realizes he wrong ((desc[2] & 0xF0) >> 4) in a patch where the & part is kind of useless
<tsdgeos> oh well
<tsdgeos> doing this crid and CIT table without a stream to check is haaaaaaaaaard :D
<tsdgeos> prepend_string_index: This field gives the index of the relevant prepend_string in the list of prepend_strings carried in
<tsdgeos> this section. If this field is set to 0xFF then there is no prepend_string and the unique_string shall hold the complete
<tsdgeos> CRID string. The complete CRID string need not contain the first 7 characters common to every CRID (i.e. "CRID://"),
<tsdgeos> if this is the case then their presence is implied.
<tsdgeos> Interpretation question: the last "if this is the case" refers to "not contain the first 7 characters common to every CRID" or refers to "If this field is set to 0xFF" ?
#ubuntu-tv 2012-03-23
<tsdgeos> Saviq: any chance you might have a stream with RST information?
<Saviq> tsdgeos, nope :/
<Saviq> tsdgeos, my dvb-t is... new
<Saviq> young
<tsdgeos> feed it so it grows :)
<Saviq> I could try with DVB-S... actually let me dvbsnoop it
 * tsdgeos wonders when he'll get his dvb-t caputre stuff
<tsdgeos> ebay said it was sent a few days ago
<tsdgeos> but...
<Saviq> tsdgeos, I'll scan some of the suspects on HotBird, maybe someone does send nice stuff
<tsdgeos> cool
<tsdgeos> oh man
<tsdgeos> the RCT is biiiig :D
<Saviq> tsdgeos, I (think I) scanned all transponders on S13E... not one has anything on pid 0x13 (RST)
<tsdgeos> :/
<Saviq> trying Astra now
<Saviq> gonna be difficult to grab RCT
<Saviq> I'm not even sure where to expect it...
<Saviq> ah ok, so PMT will hold info _whether_ RCT is being sent at all
<Saviq> and then tell us where to expect it
<Saviq> (it seems)
<tsdgeos> i'm still a bit lost regarding RCT
<tsdgeos> there's a few descriptor() mentions
<tsdgeos> and i'm not sure which descriptor can appear there
<Saviq> indeed
<Saviq> tsdgeos, btw here's some more info http://www.ebu.ch/metadata/cs/tva/HowRelatedCS.xml
<Saviq> the urn:metadata:cs... seem to reference those
<tsdgeos> i see
<Saviq> there's a "metadata pointer descriptor" mentioned
<tsdgeos> leaving for the weekend now, will have a more through look on monday
<tsdgeos> enjoy!
<Saviq> oh! found a RST
#ubuntu-tv 2013-03-18
<vishpp> someone mentioned need for c++ people on g+
#ubuntu-tv 2013-03-21
<tgm4883> I feel like I should write a blog post about all these people whining about not being included in the decisions about Ubuntu and not being able to help out anymore
<tgm4883> I mean, if you are going to whine about that, at least show some interest when someone requests your input
#ubuntu-tv 2013-03-22
<JStalin> so, what's the status of ubuntu tv?
<JStalin> I recently started to think about buying a tv set, now i wonder when can I expect an ubuntu tv to be available on the market?
