PDA

View Full Version : ESPN going out of sync?


Tyrus
June 2nd, 2011, 08:42 PM
Preface: I am probably the only tennis player/enthusiast in the entire audio world (then again there are a lot of Europeans on this board). but thats okay cause im probably in better shape than all of you :Coolio: j/k

A couple days ago i was watching ESPN's coverage of Roger Federer's 4th round match against Monfils, and the audio went terribly out of sync, about a half second.

I know its very internet of me to go up and bash on ESPN for screwing up. But that ruined my viewing experience and a match involving Federer is no joke.

/endrant

Bob Olhsson
June 3rd, 2011, 04:18 AM
Welcome to "HD" digital TV. That happens every time they switch a local commercial into a live feed.

ivmike
June 3rd, 2011, 02:57 PM
Isn't that related issues with the satellite feed?

Bob Olhsson
June 3rd, 2011, 04:02 PM
No, it's the data compression method which only transmits changes in the picture and not real time video. A friend of mine who was on the HD TV committee calls it the first time the FCC has ever mandated vaporware. The manufacturers swore on a stack of Bibles that they'd have this problem solved by the time analog TV went away...

Micro$oft and Comca$t turned what could have been a higher quality television standard into a compatible format for 1998 computers and digital SD TV which reduced over the air quality to that of cable. The NAB went down kicking and screaming as free over the air television was effectively sentenced to death in ten years. Live sports is the only thing generally broadcast in real HD.

ivmike
June 3rd, 2011, 09:38 PM
No, it's the data compression method which only transmits changes in the picture and not real time video. A friend of mine who was on the HD TV committee calls it the first time the FCC has ever mandated vaporware. The manufacturers swore on a stack of Bibles that they'd have this problem solved by the time analog TV went away...

Micro$oft and Comca$t turned what could have been a higher quality television standard into a compatible format for 1998 computers and digital SD TV which reduced over the air quality to that of cable. The NAB went down kicking and screaming as free over the air television was effectively sentenced to death in ten years. Live sports is the only thing generally broadcast in real HD.


Thanks Bob; I didn't know what caused the sync issues. :Thumbsup:

and you get one of these, too! :vuvu:

Pimp-X
June 4th, 2011, 09:19 PM
You are watching, regardless of it being an HD or SD feed, a MPEG transport stream.

The MPEG transport stream contains some useful little things. It contains a Program Clock Reference at 27MHz and 90 kHz. The 27 meg clock is used for locking your set top box's System Clock to the encoder or multiplexer that generated the transport stream. The 90k clock is used for frame presentation.

Audio frames and video frames and stamped with a think called a Presentation Time Stamp and a Decoding Time Stamp. The DTS indicates when your set top box should start reassembling the frame for presentation, and the PTS indicates when the frame should be played out of your set top box.

The concept of DTS and PTS is designed to keep buffer lengths managable and also present audio and video in perfect synchronization.

It is perfectly fine to switch between streams in broadcast, be it live to advert insertion and so forth, if it's done right. You can change frame size, frame rate, bit rate, without issues - so long as you keep your PCR and PTS/DTS right and therein lies the trick.

What I'm saying is basically this - Don't go blaming MPEG, the cable company or the satellite. Blame people who didn't spend coin on the hardware that works properly and bought something that's fractionally compliant.

Believe me, there's tons of fractionally compliant kit out there sold as high-end broadcast gear. It amazes me. I've just been dealing with a HD encoder that stamps it's I-Frames with an illegal ID value. Most set top boxes play it but others freak out.

Also, MPEG does transmit full frames, usually every 12 to 15 or so. These are called I frames. They are the only place you can cleanly splice between MPEG clips because all the other frames between them are P or B frames, which are forward or backward predicted frames. They are calculated difference frames.

How do I know all this? I recently authored an IP based nVOD broadcast playout system for a cable company, complete with realtime splicing.

It can be done right. If your A/V is out of sync, someone is doing it wrong.

Bob Olhsson
June 5th, 2011, 04:15 AM
I forget what the exact lame brained glitch in the U.S. standard was.

Tim Halligan
June 5th, 2011, 05:06 AM
Also, MPEG does transmit full frames, usually every 12 to 15 or so. These are called I frames. They are the only place you can cleanly splice between MPEG clips because all the other frames between them are P or B frames, which are forward or backward predicted frames. They are calculated difference frames.



hehe

Reminds me of Betacam SX...a format that Sony introduced that was primarily pitched at news gathering applications.

It had a 4 frame cycle...which colloquially was described thus:

The real frame,
the skipped frame,
the blurred frame,
and the guessed frame.


Sony abandoned it mid-flight a few years back. I think SX was their shortest-lived professional format ever.

Cheers,
Tim

Spock
June 5th, 2011, 03:24 PM
Glad to see Pimp and Tim H chime in.

Things get even more fun when you look at the over the air encoding of the MPEG stream in the US. First take out a bunch of sync data, then wrap the packets with an error correcting code, then scramble the packets a bit, to insure even bit density, then move parts of each packet around, mixing about 4msec of data. Then trellis encode and pump back in the sync data you stripped out, then 8VSB modulate with a small pilot carrier.

Got all that?

Good, undo it all the set top and get back the stream Pimp was talking about.

It's all done to fit the stream into the existing 6MHz bandwidth of the old NTSC signal, using every bit little bit of the bandwidth by making the signal as close to random noise, and the swap of data around to make sure that an unwanted noise burst doesn't wipe out a whole packet, just parts of several, then the error correcting code can fix those backup.

Any wonder some folks didn't implement the standards correctly?

Bob Olhsson
June 5th, 2011, 03:56 PM
My friend told me it was a complete train wreck because of corporate politics taking complete precedence over a workable practical standard.

Soon after that he quit television in utter disgust and went to work designing video display technology for NASA. I thought that was cool because years earlier he had actually designed the displays that were used on the Star Trek set and later those for Star Wars.

What a career!

Spock
June 5th, 2011, 06:03 PM
And a debate still goes on about using 8VSB instead of COFDM like the EU and other places. The big problem is dealing with multipath, what would be ghosting in analog. 8VSB doesn't use the phase information, so that helps in that regard. COFDM has time guard bands between symbols to do the same thing and works better in dynamic multipath situations, such as the receiver being on the move. Ratio of peak to avg power for the transmitter is different for the two. 8VSB works better for longer distance, worse in cities with more reflections. Blah blah blah.

When you take the COFDM standard and reduce it to from 8MHz to 6 required for the US, just flip a coin. That doesn't stop people from screaming that X company got in bed with the FCC.

Cable on the other hand does 64QAM since they don't have to contend with multipath. They pump more data in the same channel than over the air.