Here ya go, C-band S-2 screenshot. I'll bet these are the masters.i would bet that the c-band feeds are the masters
to anyone capable of c-band and s2, whats these channels picture like?
Here ya go, C-band S-2 screenshot. I'll bet these are the masters.i would bet that the c-band feeds are the masters
to anyone capable of c-band and s2, whats these channels picture like?
i would bet that the c-band feeds are the masters
to anyone capable of c-band and s2, whats these channels picture like?
That's awesome FTA power! :up..... Now they have an outreach for imigrants to come over and see programs in their native tounges, then they get to say something about JESUS!
That would be great, but the bandwidth couldn't support three streams without severe issues.It's on the old RTN West spot(I didn't bother rescanning) Any Titan tv codes for Eastern time? The Tuff Tv website only lists movie but doesn't say what movie it is.
Ideally it would be great to have all RTN-E&W + Tuff for timeshifting but can't knock a new channel
That would be great, but the bandwidth couldn't support three streams without severe issues.
if they upped the symbol rate they'd have some bandwidth thenThat would be great, but the bandwidth couldn't support three streams without severe issues.
If going to 3 channels reduces the picture quality too much, can we expect a switch to DVB-S2? Hopefully not as that would eliminate a lot of viewers. (even though the feeds are not really for us)
They are very close now to having enough for a third stream.
...
The only problem with cramming all that video/audio into that mux would end up giving us lots of pixelation and blocking. Their current data rate is 6.143176 and they're in a 6 meg slot. If they bought another 3 megs increasing their bandwidth to 9 megs, it would at least give them a bit more to play with. I'll look at their carrier tomorrow and report the numbers I see. Just an FYI - the nominal symbol rate most news SNG trucks use (ABC, CBS, FOX, CNN) is 3.978723 with a data rate of 5.5. NBC also uses those parameters, but also uses 4.232 with an FEC of 5/6. And that's usually for talking head stuff.I think they already have enough bandwidth for a 3rd stream. Looking at the streams right now, the two video streams are running 1.73 mbps for video, and 0.188 mbps for audio, both fixed bitrate, for a total of 1.92 for each channel. They now have a null stream going at 2.22 mbps, which I think means that they could put in a third channel with 0.3 mbps to spare, all without affecting the quality of either existing channel.
One thing that's confusing me though, is that the 1.73 mbps actual bitrate seems to be bigger than what TSREADER is indicating as the target bitrate, which is 1.646. but the way I understand it, those targets don't really mean much.
The only problem with cramming all that video/audio into that mux would end up giving us lots of pixelation and blocking. . ....
....
That would be great, but the bandwidth couldn't support three streams without severe issues.
I think its a smart move on RTV's part to drop the west coast feed. None of their programming is time sensitive and is generic enough to play in all dayparts. I will miss being able to watch Adam 12/Dragnet at 1700 pacific though.
Mathematically, yes the numbers work. The only problem is the actual encoding of the signals. Since each of the streams are fixed and not stat mux'd, the would be no ability for the encoder to "accelerate" when fast motion occurs in the picture. Usually static or very still motion are replicated in the encoder. However, when something fast happens (a helicopter flying across the sky, a car chase, etc) the encoder has no way of knowing and that's when you'll see pixilation and blocking. Also, null packets are just that....null....also referred to as stuffing. The object is to keep the null packets down to a minimum.I don't see why this should be the case. They are already sending all the data they need for the extra channel, it's just that they are sending that data as NULL bytes. The 2 channels aready there are fixed bitrate. Turning those NULL bytes into actual data shouldn't cause any problems with the other data already there, unless it was such a tight fit that the size of the blocks of data made it difficult to schedule the timing of when the various packets would be sent. But with 0.3 mbps to spare I really don't think this would be a problem. I've seen examples where they have crammed channels in leaving virtually NO overhead of NULL bytes, so I would think that 0.3 mbps should be plenty of overhead.
The only other reason I could see that there might be a problem is that perhaps the NULL bytes give the receiver a bit of a rest, allowing them not to have issues relative to receiving data and processing it at the same time, however this is such a low bitrate transponder, that I don't think receivers should have a problem with this. If it were a 30,000 SR transponder, then maybe.
Anyway, other than scheduling blocks, I don't see that it is any different sending NULL bytes vs real data, but if this is wrong, I'd be interested in learning why.
The object is to keep the null packets down to a minimum.
I agree. I was watching Adam 12 this afternoon and there was a tremendous amount of blocking. With a data rate of 1.9 something, I would expect this. As for them using over 2 for stuffing (null packets). They could reoptomize their encoders to fatten up their existing streams. If they plan on adding a third stream (which will really make everything look crappy), then they could revert back to their original link budget.RTV's quality has suffered since this change. It's looking like the foreign stuff on G19.