Manu Abraham schrieb:
> Andrew de Quincey wrote:
>> On Monday 22 May 2006 20:34, Manu Abraham wrote:
>>> we have 2 modes.
>>>
>>> (1) Normative Broadcast Mode (NBC-BS)
>>> (2) Backward Compatible Mode
>>>
>>> Only in Normative Broadcast Mode, we do have a S2 satellite delivery
>>> system descriptor.
>>>
>>> In the backwards compatible mode it is just DVB-S alone. There is
only 1
>>> stream in this case
>>>
>>
>> Would such a stream be decodable by a DVB-S demod? If so, the Sky
>> streams _cannot_ be decoded by a DVB-S demod - already tried it :)
>>
>> [snip]
>>
>>
>
> Probably not Backward Compatible then.
>
>
> The specs say like this ..
>
> Backwards-compatible modes
>
> The large number of DVB-S receivers already installed makes it very
> difficult for many established broadcasters to think of an abrupt change
> of technology in favour of DVB-S2 – especially where there is a receiver
> subsidy and for free-to-air public services. In such scenarios,
> backwards-compatibility may be required in the migration period,
> allowing legacy DVB-S receivers to continue operating, while providing
> additional capacity and services to new, advanced receivers. At the end
> of the migration process, when the complete receiver population has
> migrated to DVB-S2, the transmitted signal could be modified to the
> non-backward compatible mode, thus exploiting the full potential of
> DVB-S2. Optional backwards-compatible (BC) modes have therefore been
> defined in DVB-S2, intended to send two Transport Streams on a single
> satellite channel. The first (High Priority, HP) stream is compatible
> with DVB-S receivers (according to EN 300 421 [3]) as well as with
> DVB-S2 receivers, while the second (Low Priority, LP) stream is
> compatible with DVB-S2 receivers only.
Hello together,
after going through most of this discussion now I finally decided to
join it at this point.
First of all I'd like to address Johannes complaints about only Manu
participating at this discussion. I actually stayed in the background
until now, because my knowledge of the linuxtv-development of the past
is pretty vague, as I actually joined this whole thing not too long ago.
Actually I thought (and still think) Manu would do a better job
explaining the API, than I could do.
Now to come to the technical terms.
First there is a need for this API change. As Andrew said Sky is
starting to widely use DVB-S2 now, as well as ProSieben and Sat1 are
doing already on Astra. Premiere, as you said, is also broadcasting with
DVB-S2. BBC is currently doing tests with DVB-S/H264, but confirmed me a
few days ago that they'll switch over to DVB-S2 during the testing-period.
Another channel on Asta is AnixeHD, which is only available through
DVB-S2. There are even (founded) romours about ZDF (german public
television) starting DVB-S2 broadcasts in september of this year.
And I'm quite sure many more will follow soon.
According the question of backwards-compatibility I am not aware of a
programme that would work in backward-compatible mode. Actually we have
two cases of usage for DVB-S2 now:
(a) A HD-simulcast of a conventional TV-programme, being broadcasted
through DVB-S and MPEG2 on another transponder. Examples: ProSiebenHD,
Sat.1 HD
(b) A channel only doing HDTV like Premiere HD or Anixe HD. These are
most likely using DVB-S2 because it'll be cheaper in the end, because of
the less bandwidth they need. This advantage would be gone, when
broadcasted in a backward compatible way. At least this is how I got it.
So neither in case a, nor in case b it would be sensible to use
backward-compatible mode.
Actually an even more interesting point are the concerns of Johannes of
adding too many details to the API. Actually my impression is that, as
said by others too, in the past every possible detail went into the API,
why should this be wrong now?
I can basically follow your concerns of having to remove parts of the
API later, but in this case we don't talk about "wrong" additions, but
about additions that might not be used in the end, because no
broadcaster uses them. Actually this wouldn't be a problem, as it only
would make sure that we would be aware of all possibilities and wouldn't
come into a situation where someone starts using a part of the spec
which we previously declared as not important. In the worst case it
could become a big problem adding those parts later on, because they
would break binary compatibility in a non-EXPERIMENTAL state.
Well so far for now.
I really hope we can come to terms soon, as many people are waiting for
this!
Cheers,
Julian
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
