A friend contacted me last night to say that Torosay HD was out of lip
sync.
Which channels ?
On 30/01/2022 14:12, Mark Carver wrote:
Which channels ?
All HD as far as I can tell.
Well yes, everything except I think Shopping Quarter is in HD.
Torosay is in the same coding group as Black Hill and Darvel, so if the problem is within the coding of the transport stream, they will be
affected too
On 30/01/2022 18:59, MB wrote:
On 30/01/2022 15:30, Mark Carver wrote:The video and audio packets are married together at the code and mux
Well yes, everything except I think Shopping Quarter is in HD.
Torosay is in the same coding group as Black Hill and Darvel, so if the
problem is within the coding of the transport stream, they will be
affected too
Not sure of the terminology with this funny digitty stuff but last
time it was the modulator / drive / whatever they call it at Torosay.
Arquiva did a changeover whilst I watched at homeand then they locked
it onto the good side until someone could get over and change the unit.
But it did not seem to be picked up by the monitoring, I thought they
might have improved the monitoring since then.
stage (hundreds of miles away in the SE of England)
There's nothing modulating that mux transport stream at COFDM level at
the transmitter that could affect that, and cause the video and audio packets to lose sync.
It's either going wrong in the receiver (changing channel away, and back often cures (or makes matters worse)) or, as I say way upstream nowhere
near Torosay.
The transmitters these days are largely dumb terminals. Swapping the Tx drives over gives the receiver a similar kick to you changing channel etc
The video and audio packets are married together at the code and mux
stage (hundreds of miles away in the SE of England)
There's nothing modulating that mux transport stream at COFDM level at
the transmitter that could affect that, and cause the video and audio packets to lose sync.
It's either going wrong in the receiver (changing channel away, and back often cures (or makes matters worse)) or, as I say way upstream nowhere
near Torosay.
The transmitters these days are largely dumb terminals. Swapping the Tx drives over gives the receiver a similar kick to you changing channel etc
On 30/01/2022 15:30, Mark Carver wrote:
Well yes, everything except I think Shopping Quarter is in HD.
Torosay is in the same coding group as Black Hill and Darvel, so if the
problem is within the coding of the transport stream, they will be
affected too
Not sure of the terminology with this funny digitty stuff but last
time it was the modulator / drive / whatever they call it at Torosay.
Arquiva did a changeover whilst I watched at homeand then they locked
it onto the good side until someone could get over and change the unit.
But it did not seem to be picked up by the monitoring, I thought they
might have improved the monitoring since then.
On 30/01/2022 19:36, Mark Carver wrote:
The video and audio packets are married together at the code and mux
stage (hundreds of miles away in the SE of England)
There's nothing modulating that mux transport stream at COFDM level at
the transmitter that could affect that, and cause the video and audio
packets to lose sync.
It's either going wrong in the receiver (changing channel away, and back
often cures (or makes matters worse)) or, as I say way upstream nowhere
near Torosay.
The transmitters these days are largely dumb terminals. Swapping the Tx
drives over gives the receiver a similar kick to you changing channel
etc
The previous time the effect was the same as the present fault. Emley
Moor did a changeove at Torosay and the fault cleared. They locked it
onto the good side, I am sure they changed back and the fault reappeared.
But a few days later the fault reappeared and they put it back on he
good side which cleared the fault. So something was happening at the transmitter site.
It was the same on all my receivers and those of several other people
who I checked with.
On 30/01/2022 20:11, MB wrote:
On 30/01/2022 19:36, Mark Carver wrote:
The video and audio packets are married together at the code and mux
stage (hundreds of miles away in the SE of England)
There's nothing modulating that mux transport stream at COFDM level at
the transmitter that could affect that, and cause the video and audio
packets to lose sync.
It's either going wrong in the receiver (changing channel away, and back >>> often cures (or makes matters worse)) or, as I say way upstream nowhere
near Torosay.
The transmitters these days are largely dumb terminals. Swapping the Tx
drives over gives the receiver a similar kick to you changing channel
etc
The previous time the effect was the same as the present fault. Emley
Moor did a changeove at Torosay and the fault cleared. They locked it
onto the good side, I am sure they changed back and the fault reappeared.
But a few days later the fault reappeared and they put it back on he
good side which cleared the fault. So something was happening at the
transmitter site.
It was the same on all my receivers and those of several other people
who I checked with.
I'm sure it is, but as I say, the marrying of audio and video packets is
not at the COFDM modulation stage, it's at the H.264 coding stage, so I
can't see how the transmitter and its drives could have any effect ?
On Mon 31/01/2022 09:54, Mark Carver wrote:
On 30/01/2022 20:11, MB wrote:
On 30/01/2022 19:36, Mark Carver wrote:
The video and audio packets are married together at the code and mux
stage (hundreds of miles away in the SE of England)
There's nothing modulating that mux transport stream at COFDM level at >>>> the transmitter that could affect that, and cause the video and audio >>>> packets to lose sync.
It's either going wrong in the receiver (changing channel away, and
back
often cures (or makes matters worse)) or, as I say way upstream
nowhere
near Torosay.
The transmitters these days are largely dumb terminals. Swapping
the Tx
drives over gives the receiver a similar kick to you changing
channel etc
The previous time the effect was the same as the present fault.
Emley Moor did a changeove at Torosay and the fault cleared. They
locked it onto the good side, I am sure they changed back and the
fault reappeared.
But a few days later the fault reappeared and they put it back on he
good side which cleared the fault. So something was happening at
the transmitter site.
It was the same on all my receivers and those of several other
people who I checked with.
I'm sure it is, but as I say, the marrying of audio and video packets
is not at the COFDM modulation stage, it's at the H.264 coding stage,
so I can't see how the transmitter and its drives could have any
effect ?
IME loss of lip-sync is the fault of the TV receiver - with mux
changing often clearing as mentioned earlier.
Had a reply from the BBC to the report I submitted on their form.
Usual case of "if in doubt tell the viewer to reset everything" even
when same fault on several devices.
Do remember, that, unlike 30+ years ago, you are not contacting engineers.
On 02/02/2022 16:41, charles wrote:
Do remember, that, unlike 30+ years ago, you are not contacting engineers.
I wonder sometimes if we even contacting human beings.
It's not as simple as that. Were all the HD channels in the mux affected
BTW ? It's where they are encoded into H.264 where the problem lies (i.e
no where near Torosay, or even in Scotland), and each channel will have discrete effects. There is nothing within the COFDM modulation process
or path that can affect lip-sync. That is baked in way upstream at the
H.264 stage.
Might be coincidence but HD lip sync seems OK now.
Around the same time my BT YouView box stopped receiving HD but the
Panasonic TV and Panasonic PVR just had the lip sync problem.
I am wondering if either a faulty unit has been replaced or at least a changeover has been done and whether the fault condition could have
affected the YouView box differently from the other two HD receivers
because YouView HD is working again.
On 04/02/2022 09:37, Mark Carver wrote:
It's not as simple as that. Were all the HD channels in the mux affected
BTW ? It's where they are encoded into H.264 where the problem lies (i.e
no where near Torosay, or even in Scotland), and each channel will have
discrete effects. There is nothing within the COFDM modulation process
or path that can affect lip-sync. That is baked in way upstream at the
H.264 stage.
All channels on the MUX were affected the same.
So why was the previous problem a few years ago only on one side and
cleared when switched to the other side (and returned when switched
back)?
The previous occasion, I got nowhere reporting to the BBC and it was
only fixed when I reported to STV and they must have prompted Arquiva
to investigate.
Were you on the phone to Emley when they switched the drives over, and watching. If so which channel ?
Presumably the carrier dropped for a split second ? How long before they switched it back. Again did you check all the channels.
Well, I gather the Tx exciters do have the ability to modify the
transport steam packets (notably when there is SFN working required) so
it's apparently not impossible the fault is being triggered at Torosay.
On 04/02/2022 10:30, Mark Carver wrote:
Were you on the phone to Emley when they switched the drives over, and
watching. If so which channel ?
Presumably the carrier dropped for a split second ? How long before they
switched it back. Again did you check all the channels.
It is some time ago now but I am sure I watched listened as they
switched because they had no way of knowing whether the fault was on.
Sure I would have checked at least a few channels./
They locked it on one side but a few days later it was either switched
again or changed over itself and I think I had to ring them up.
On 07/02/2022 08:24, Mark Carver wrote:
Well, I gather the Tx exciters do have the ability to modify the
transport steam packets (notably when there is SFN working required) so
it's apparently not impossible the fault is being triggered at Torosay.
I thought it was just the klystrons that were steam powered! :-)
On 07/02/2022 08:50, MB wrote:
On 07/02/2022 08:24, Mark Carver wrote:A friend of mine used to work for the studio/OB truck side of Pye TVT.
Well, I gather the Tx exciters do have the ability to modify the
transport steam packets (notably when there is SFN working required) so
it's apparently not impossible the fault is being triggered at Torosay.
I thought it was just the klystrons that were steam powered! :-)
He'd often rib his colleagues in the transmitter side of the company,
that their products would totally screw up the output of his stuff by
the time the video signals had emerged out of the klystrons !
Anyone here remember Bilko Burton, Freddie Shelton and George
Hickson?...
On 11/02/2022 11:52, tony sayer wrote:
Anyone here remember Bilko Burton, Freddie Shelton and George
Hickson?...
At the end of last year, the Pension Visitor told me about Davd
Sandbrook having died so I did a quick search and came across the Obits
on www.bbceng.info. I mentioned this to an ex-colleague, he replied
that he was surprised at all the familiar names there that he had not realised they had died.
Dave's death was mentioned in the recent Prospero. That link doesn't seem
to work
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 126:19:15 |
| Calls: | 6,663 |
| Calls today: | 1 |
| Files: | 12,212 |
| Messages: | 5,334,955 |