Social Feed

Not aware of the h.264 profiles being backwards compatible for legacy DVBS receivers. Would be interested in more discussion as an option for our broadcaster partners. Did you happen to record the transport stream? I believe that you were viewing a mux built using multiple encoders, one DVBS and one S2 encoding the same source. The reason that most DTH broadcasters are not transmitting two streams is the encoder cost, the additional bandwidth and the majority are still acquiring and producing in standard definition.

The real basis behind a transition to higher PQ is distribution requirements and viewer demands. On a technical level, what comes first, the horse or the cart?

The first step for a broadcaster is to upgrade acquisition and migrate production and post production to produce content in HD. If their distribution model includes terrestrial or subscription distribution the transition has or is now occurring. If the main audience is DTH using FTA on KU-band, the transition will be gradual as the majority of FTA DTH viewers do not have equipment capable of receiving programming produced or distributed in any format other than DVBS MPEG2 main profile. The current broadcasters are meeting the needs of their primary DTH market and this market is not vocal regarding a better quality image. I could see the transition being speed up if a compelling service were to launch using DVBS2 MPEG4 to a market. Since DVBS2 MPEG4 receivers are backwards compatible the broadcaster would still need to see a demand or requirement to provide higher quality PQ.

Good point because it was indeed H.264 as per Azbox. They were all HD 1080i as well as per the CS 8100. Brian I did not record any stream at all, my bad!. I did not even thought of it!, too much was going on and I tuned them too late and wanted to try many receivers , see it in the SA and also wanted to confirm first it was backwards compatible mode.

It was not acctually a mux per se , they were all SCPC , all 4 different feeds. the first 2 were typical DVB-S (QPSK obviously) but the other 2 were scanned in with the AZbox as DVB-S2 8PSK but they also locked if I selected DVB-S which has never happened before. I always try with every S2 feed to lock it as DVB-S because I have always wanted to find a backwards compatible one. As a matter of fact the AZbox reported FEC 1/2 on those 2 8PSK and since the CS 8100 has no 1/2 FEC option when using DVB-S2 I could only lock them in QPSK 3/4 with the CS 8100.

I do not really see the usefullness of Univision doing this since as you said they were all H.264 (although DVB-S sat receivers H.264 capable do exist , this chinese nextar semms to be an example, MPEG-4 H. 264 DVB-S HD Internet Sharing Receiver Cccam MGCamd - China Hd Internet Reveiver,Mpeg-4 H. 264,Cccam Recever in Radio & TV Broadcasting) but it could be the case that they also had some affiliate (keep in mind this is a spanish show with high penetration in South America and possibly this red carpet feeds were intended also for south american tv stations) that even though they had HD and H.264 capable recivers they were not DVB-S2 capable yet. As a matter of fact the AZAmerica is a very popular consumer grade satbox in South America that is only DVB-S capable but does H.264 it is also chinese made, for more info see Azamerica S2 S900 DVB-S Receivers - TV STB Receivers - Product Catalog - Fujian Tianyu International Development Co.,Ltd

In any case from a broadcaster point of view I do not think you need to buy 2 encoders since more likely the DVB-S2 encoder is capable of doing (but it could cost more since it has 2 encoders inside but maybe they all do now for the same price although this is an optional mode so like cars some has A/C some dont) this by just flipping the backwards compatible mode switch on but will have to gather more info on available comercial equipment to support this statement.

The following is taken from an EBU document named DVB-S2: Ready for Lift Off (I saw it posted here over 1 year ago) at http://www.hellas-sat.net/files/file/EBU_DVB_S2.pdf

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 themigration 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 [2].
Backwards compatibility can be implemented by hierarchical modulation [4], where the two HP and
LP Transport Streams are synchronously combined at modulation symbol level on a non-uniform
8PSK constellation. The LP DVB-S2-compliant signal is BCH and LDPC encoded, with LDPC code rates 1/4, 1/3, 1/2 or 3/5. Then the hierarchical mapper generates the non-uniform 8PSK constellation: the two HP DVB-S bits define a QPSK constellation point, while the single bit from the DVB-S2 LDPC encoder sets an additional rotation​

​

​

​

********************** now my post continues ********************

which is consistent with what I saw , since they say that the LP stream (DVB-S2) is encoded with low code rates like 1/2 among them and that is what the Azbox blind scanned in and that is why the CS8100 did not lock it in DVB-S2 (it lacks 1/2 in its S2 options).

there is another document I read last night that claims that the HP stream (DVB-S) becomes more noisier and it could also be consistent with the fact that my Azbox locked them with higher Quality on S2 but lower Q if DVB-S was selected. In any case I have no means to contact the Univision broadcast department and ask them if indeed that was the case but since DVB-S2 penetration in South America might have been an issue it could be the case they decided to use this BC mode for the transmition. Will pay more attention and record it on future Univision major events feeds, lets hope they reuse this technology again.

Brian thanks for replying BTW.

Thank you for this additional information.

I will read up more on this transition solution and am interested if you observe this transmission occur again. I will PM you my telephone number if you could contact me next time you detect this mode. I would like to snoop the transport streams and perform some testing with legacy DVBS decoders.

Have some sit-down time with several uplinkers next week at the NRB convention in Nashville, TN and again next month at the NAB in Las Vegas, NV. Will see if they can provide additional insight on this and I will share gleaned info.

You are Welcome. Of course I will, no problem, will also continue on the look out for this signals. I will also PM you the details and post it here for future reference if I spot another one and next time will record it as well, just in case.

I have not being able to catch another transmition like this and in terms of DVB-S2 modulators most I have seen on the net do not mention BC mode but this does mention is able to do backwards compatible mode.
http://www.datacast.com/media/mediamanager/datasheet/56-dm-3100-modulator.pdf

Whether they are more expensive or not, no idea. Another good pdf about the benefits of using this is located here: http://www.scopus.ru/files/Maximizing_Satellite_Transmission_Efficiency_With_DVB-S2.pdf

BTW last week I found several latin american TV stations over at 55.5W mostly, that had programms only about that Red Carpet from that night so I guess some of this TV stations although they had h.264 HD reception equipment they did not have DVB-S2 capable ones therefore the need to run those feeds in this BC mode for them.