These are chat archives for Opendigitalradio/mmbTools

24th
Mar 2016
coinchon
@coinchon
Mar 24 2016 08:54
hello world
Gabriel
@vvombat
Mar 24 2016 10:59
@mpbraendli Thanks for the work and references! I will have to push this back and focus on this later in my Bachelor thesis then. If there is something to implement to get "hijacking" working it's possible I will try to do it as part of my thesis. If I get it working in the end I'll let you know. Thanks for your time!
Nick Piggott
@nickpiggott
Mar 24 2016 15:12
OK, let me have a go. I may have to resort to ASCII art
A service can have multiple components. A component has a subchannel. So the nesting is service -> component(s) -> subchannel(s)
In the way the current config works, a component is used to bring together a service and a subchannel. So you can't specify multiple services in a single component definition (or can you?).
Specifically - I can define an EPG Component, which refers to a packet mode subchannel. I can then add that EPG Component to every service on the multiplex that is carried in that EPG. So:
SERVICE 1 = Component 1 (audio on subchannel 1), Component 3 (EPG on packet mode subchannel)
SERVICE 2 = Component 2 (audio on subchannel 2), Component 3 (EPG on packet mode subchannel)
I'm sure this was possible on the command line parser, as we (Global) configured a trial mux in exactly this way. When we migrated to the new config file, it wasn't possible any more.
I guess in the current config file context ,that would look like
component3 {
service 1
service 2
subchannel epg_packet
}
Nick Piggott
@nickpiggott
Mar 24 2016 15:18
Which makes it look like you're trying to declare multiple services in a component, but what you're actually trying to do is associate a component to multiple services
Matthias P. Braendli
@mpbraendli
Mar 24 2016 18:39
I understand what you wrote, but I don't understand how to signal this in the FIGs. And I don't understand how this was possible in the past. If you still have an archive of an exact command line that achieved this, I could analyse it.
Nick Piggott
@nickpiggott
Mar 24 2016 19:51
OK, I'll have a go.
FIG 0/2 - is a list of Service IDs, and the components of that service. Figure 24 in EN 300 401 is the helpful one. So, let me try and remember how we did Heart on the trial.
P/D = 0, SID = 0xc460, Local flag = 0, CAId = 0, Number of Service Components = 2 ==>
Nick Piggott
@nickpiggott
Mar 24 2016 19:57
(Service component 1) - TMId = 0, ASCTy = 0, SubChId = 1, P/S = 1, CA flag = 0
(Service Component 2) - TMId = 11, SCId = 1, P/S =1, CA flag = 0
FIG 0 /13 - Data Application definition stuff.
SCId = 1; Rfa = 0, CA Org = 0, DG Flag = 0, Rfu = 0, DSCTy = 60 (MOT), SubChId = 2, Packet Address = 1, CA Org = 0
(SORRY FIG0/3 not fig 0/13!)
Nick Piggott
@nickpiggott
Mar 24 2016 20:04
FIG 0/13 - User Application definition
Nick Piggott
@nickpiggott
Mar 24 2016 20:13
SID = 0xc460, SCIdS = 0, No of User Apps = 1, User App 1 = 0x07 (EPG)
On the London I mux, which Global Radio manages directly (http://wohnort.org/dab/uknat.html#London), the EPG channel is also signalled as a primary service, mainly to deal with some legacy receivers that expect to see a Service with a primary component as EPG, so there's an additional entry in FIG0/2
P/D = 1, SID = 0xe1c00098, Local flag = 0, CAId = 0, Number of Service Components = 1 ==>
(Service Component 1) - TMId = 11, SCId = 1, P/S =1, CA flag = 0
Matthias P. Braendli
@mpbraendli
Mar 24 2016 20:16
Yes, FIG0/2, Figure 24. For each service, it lists the components. Where do you say that a given component is shared among several services?
Nick Piggott
@nickpiggott
Mar 24 2016 20:17
So there's no reason why a component entry - for instance my reference to SCId = 1, can't appear in multiple services
So on Capital, on the same multiplex, I'd have a FIG0/2 of: P/D = 0, SID = 0xc479, Local flag = 0, CAId = 0, Number of Service Components = 2 ==>
(Service component 1) - TMId = 0, ASCTy = 0, SubChId = 3, P/S = 1, CA flag = 0
(Service Component 2) - TMId = 11, SCId = 1, P/S =1, CA flag = 0
Matthias P. Braendli
@mpbraendli
Mar 24 2016 20:19
Absolutely. So you would have
service 1, component 1 pointing to subchannel A
service 1, component 2 pointing to subchannel B
service 2, component 1 pointing to subchannel C
service 2, component 2 pointing to subchannel B
And B would be shared among both services
Nick Piggott
@nickpiggott
Mar 24 2016 20:19
Yes, correct
Matthias P. Braendli
@mpbraendli
Mar 24 2016 20:19
Okay, so you put four components in the config file, and there you go :-D
Nick Piggott
@nickpiggott
Mar 24 2016 20:19
Hang on ,let me work out what you've just said...
so
Matthias P. Braendli
@mpbraendli
Mar 24 2016 20:19
you could call them 1A, 1B, 2C, and 2B
Nick Piggott
@nickpiggott
Mar 24 2016 20:20
so they would look like this?
Matthias P. Braendli
@mpbraendli
Mar 24 2016 20:20
The components themselves don't have a unique id, do they?
maybe in FIG0/8
the one I didn't understand yet.
Nick Piggott
@nickpiggott
Mar 24 2016 20:21
comp 1a {service 1, subchannel A}
comp 1b {service 1, subchannel B}
comp 2a {service 2, subchannel C}
comp 2b {service 2, subchannel B}
? Is that right ?
Matthias P. Braendli
@mpbraendli
Mar 24 2016 20:21
comp 2c would be more logical, but in the end it doesn't matter how you call them.
and I'm not sure names are allowed to start with a number, but that's also not relevant to the issue
But fundamentally, yes.
I expect this to create the same layout as with the command line in the past.
Nick Piggott
@nickpiggott
Mar 24 2016 20:22
ok, so I'll give that go. I had been organising it in my head the way the services are organised, so more
service 1a {component 1, component 2}
service 2a {component 3, component 2}
component 1 = subchannel 1, component 2 = subchannel 2, component 3 = subchannel 3
But let me try it the way you've suggested.
FIG0/8 is only relevant if you want to create a create a GUID for a service
Matthias P. Braendli
@mpbraendli
Mar 24 2016 20:25
We could actually do
services {
  srv-A {
    comp-A { subchannel sub_S1 }
    comp-B { subchannel sub_S2 }
  }
  srv-B {
    comp-A { subchannel sub_S3 }
    comp-B { subchannel sub_S2 }
  }
}
subchannels {
  sub_S1 { blablastuff }
  sub_S2 { foo bar }
}
I always understood that components pull together one service and one subchannel, that's why I set it up like this. But it's maybe a bit different than in the spec.
Nick Piggott
@nickpiggott
Mar 24 2016 20:26
Yeah, that would mimic the Figure 21 in EN 300 401 more closely
blob
Matthias P. Braendli
@mpbraendli
Mar 24 2016 20:29
The difference if there is one component shared by two services, or two components that point to the same subchannels is actually only visible in this graph. In the FIC both are identical.
I'll think about the change in the configuration format, but I have to check if I can easily do it in a backward-compatible way.
Nick Piggott
@nickpiggott
Mar 24 2016 20:29
FIG0/8 is rarely used. You only need it if you want to create GUID style id for a service
Matthias P. Braendli
@mpbraendli
Mar 24 2016 20:30
Thanks for the discussion, and tell me if creating these components creates what you expect!
I have to leave the chat now.
Nick Piggott
@nickpiggott
Mar 24 2016 20:30
Yeah, the way the FIG is used to compile the database is horribly recusrive
Froehe Ostern!