On Fri, 2 Nov 2018 21:04:14 +1300, you wrote: >On 1/11/18 9:58 PM, Stephen Worthington wrote:
>> > "100baseTX high-speed network"
>> So it only has 100 Mbit/s Ethernet. So with four tuners, each recording multiple HD channels at once, you would be using a significant percentage of the 100 Mbit/s bandwidth.So I would want
>> to have each Quatro on its own Ethernet card, if I was directly connecting them to a card.
>I can't find NZ data, but here's some overseas info
>Ofcom plans to put 4x HD 720p channels on mux B. The total bandwidth is
>27.2 Mbit/s which gives us 6.8 Mbit/s per channel. Ofcom say that this
>is mitigated by a 15% stat mux gain which gives us 7.82 Mbit/s per channel.
>24 Mbit/s used to carry actual content.
>seems to be UK again
>For HD programmes, the BBC use H.264 coding, with an average bitrate of
>3.2Mbps and 192 kbps audio.
>HD programmes use about 1.5 gigabytes per hour of video.
Those HD programme figures are quite low. In NZ, we used to have HD
recordings from TV3 taking over 5 Gbytes per hour. Since they
reorganised things to have more channels, that has reduced a bit, but
they are still nearly double that. Examples:
TV3 NCIS: Los Angeles 4/4/2018 68 mins = 4.39 Gbytes
TV3 NCIS: Los Angeles 30/10/2018 68 mins = 3.03 Gbytes
Duke Live PD: Police Patrol 2/11/2018 35 mins = 1.66 Gbytes
TVNZ1 1 News At 6pm 2/11/2018 65 mins = 3.34 Gbytes
TVNZ1 20/20 30/10/2018 65 mins = 3.37 Gbytes
So from the worst of those current recordings, 20/20 is averaging 6.91
Mbits/s of data, plus some overheads for the protocol. It is easy
enough to find cases where I have been recording TVNZ1, TVNZ2 and Duke
at around that bit rate at the same time, so that is 20 Mbits/s from
one tuner. It is actually usually a little better than that, as the
software that runs a mux transmitter will dynamically adapt the bit
rate of all the channels so that it never exceeds the available
bandwidth of the mux. So when one channel wants more bandwidth for a
fast movement scene, if another channel is only using lower bandwidth,
the fast movement can be given lots of extra bandwidth temporarily.
The older NCIS: Los Angeles is averaging 8.61 Mbit/s - they could only
do that when they were not broadcasting ThreeLife as well. >To summarise, each channel is using under 10 Mbit of data all the time.
>So a 100 Mbit link should handle 10 channels at once. Your points about
>gigabit being 10x 100 Mbit are fine and valid and I concur.
Worst case is when you are scanning for channels on a mux. Then the
entire bandwidth of the mux has to be sent to the PC. I think in NZ
that is somewhere in the 20-25 Mbit/s region, but I can not find any
actual figures for it at the moment. If you ever wanted to do a scan
on all the four tuners at once, then you are getting pretty close to
the 100 Mbit/s Ethernet bandwidth limit.
And if your Ofcom figures above are right for us too (does the UK use
8 MHz bandwidth for its DVB-T and DVB-T2 channels like we do?), then
each mux can and mostly will produce 27.2 Mbit/s, and all four tuners
scanning at once will simply not work as it is more than 100 Mbit/s
Ethernet can possibly send.
In Australia it would probably work as their muxes are only allowed 7
MHz of bandwidth each.
I regularly record more than 10 channels at the same time. When you
have overlap between the start of one recording and the end of another
on the same channel, you get lots more recordings happening at once. I
think the highest I have seen is 14 recordings at once, but it may
well have gone higher as I normally am not looking at what my MythTV
box is doing at its peak recording times around 19:30. In my case,
some of those recordings were from DVB-S and DVB-S2 (Sky), so it is
spread over more tuners, and the Sky recordings are all lower
bandwidth (as yet - I hope they will be fixing that). Occasionally, I
do record from all 5 DVB-T muxes at once, but I do have an 8 tuner
DVB-T2 card now, so that works. >> And they could use a better protocol that had error recovery.
>Why? You're not moving precious bits, you're moving live streaming TV.
>Its not supposed to be perfect, its supposed to be on-time.
>If your local LAN is losing enough frames to cause issues, then changing
>to an error recovery protocol will make it even more delayed in local
>transmission. This would be worse than losing the odd bit.
But if you are recording, then you want perfect, not real time. It is
very rare for me to be watching in real time. If I want to do that, I
will normally use my TV and its tuners anyway. And in MythTV, the
LiveTV is not real time anyway - it is recorded and played back from
the recording and gets delayed by at least 2 seconds by doing that.
Two seconds is plenty of time for some error recovery if it is only
So I think network tuners should have both a real time protocol, and
one with full error correction for when you are recording. And they
should have the option to set the DSCP bits in the IP headers to allow
real time frames to be given priority over the rest of your network
>> The other major problem to watch out for is that their wall-wart power supplies always fail with age, and they also cause strange problems as
>> they start failing, so it can take ages to work out what the problem is. If I was ever to buy a SiliconDust device, I would consider
>> replacing the power supply immediately with a known good one.
>This is reasonable. It would be perfectly okay to run a 12V line from a
>molex plug out the back of the case, then into an adapter and into your
Several people on the main MythTV mailing list have done that and say
it works well. But it will only work if the tuners are next to the PC
- one of the great advantages of networked tuners is that they can be
where the aerial is, rather than where the MythTV box is.
mythtvnz mailing list