[mythtv-users] A/V delay when recording HD
atomik_kat at yahoo.com
Wed Oct 8 03:41:30 UTC 2008
With respect to the DR compression: if Comcast is doing DR compression, they
have to re-sync the compressed stream before the signal is broadcast. Should
their equipment not be set up properly, there will be issues. But, the
source originator could have also have equipment problems too. I was just
making the comment since I have several movies that I have recorded from the
TiVo which are "unaltered" AC3 streams that I can compare to the DVD that I
also own. The Fifth Element was a good example from last month on TNT-HD.
There is quite a noticeable difference in quality between what was captured
via TNT-HD and the DVD's AC3 soundtrack. Comcast gets money from it's
advertisers, and I don't think it is a very far stretch to say that they
compress the programs audio so that at the same volume that commercials are
louder. But, that's my opinion.
As for the time-sync issues in general, please google "Toxic channels" for
TiVo. Essentially, they are program streams that are not to MPEG-2 spec, and
are broken in some fundamental way, like a bitrate that is too low or high,
or an audio stream that is not synced, or data breaks. The HD/Series 3
TiVo's are especially sensitive to these artifacts, and will crash
frequently when encountered.
When I noticed this occurring on TNT-HD (and also Universal HD), I decided
to put one of the streams through some programs on my Mac to see if the
problems was the TiVo, or the stream. Without a single case, every one of
the streams had problems: bad sync, dropped data rate, data breaks, bad PTS
offsets. This was verified by VLC's logging, and also MPEG StreamClip's
error detection. Once I ran the clip through StreamClip's re-encoder, it
cleaned up the mess and the errors were gone.
Now, to prove that this wasn't just the TiVo or the cable-card making a mess
of an otherwise good stream, I also used MythBackend to capture data via
Firewire right from my DCT-6200. And the results were the same. So, based on
that, I can take the TiVo out of the list of potential problems.
I guess that I can't determine if the problem is the cable head-end, or the
feed they are getting, but what I can say is that some streams that you get
a broken, and rely on sloppy (or forgiving) hardware to handle it for you.
If you take a Mythbox or HDHR or Sling or any other receiver, they might not
be as tolerant of the errors.
But, I can not speculate on problems in other Comcast markets, or other
providers. I just know what I have experienced first-hand.
On 10/7/08 5:21 PM, "Brad Fuller" <bradallenfuller at gmail.com> wrote:
> On Tue, Oct 7, 2008 at 5:06 PM, Geoffrey Schwartzreich
> <atomik_kat at yahoo.com> wrote:
>> I do think Comcast applies Dynamic-range compression on the audio of most
>> channels, or the feeds have it already.
> Really? Is Comcast really compressing the AC3 stream before it goes out?
> And, how does this compression screw up sync?
> Florin: can you do some experiments on other channels? Especially on
> the 4 major networks. That could give some more clues. The major
> networks' primetime programs will most likely include metadata (like
> dialnorm) that providers like Comcast should pay attention to. I've
> heard that not every mixer (a human mixer) doesn't always add
> dialnorm. I hear it's a problem, but, I'm not a broadcast engineer ..
> so take my comments with a ton of salt.
>> TNTHD is awful about timecode problems. Sometimes it crashes my TiVo, and
>> files that I move from the TiVo and play back have numerous stream errors
>> and break VLC sometimes.
>> So, I think it's safe to say that Comcast or the upstream provider is
>> mucking around with the audio track or the timecoding is just overall
>> inaccurate on some feeds.
> I really don't think you can make that claim w/o some data to back it
> up. There are so many other things that can effect sync. Heck, it
> could be HDHR hw or the drivers that act strange in a particular
>> On 10/7/08 4:52 PM, "Florin Andrei" <florin at andrei.myip.org> wrote:
>>> Brad Fuller wrote:
>>>> AFA your captured stream: I assume you captured a QAM256 stream from
>>>> the coax since you are using HDHR.
>>> Well, forget the OP, explain my situation. :-)
>>> So yeah, it's a QAM256 (I *think* it's 256), recorded by MythTV from an
>>> HDHR tuner, from a regular Comcast cable feed. MPEG2 1080i. Upon
>>> analysis, the A and V tracks in the .mpg file turned out to be not
>>> aligned, there's an A/V timing difference slightly bigger than 1000ms.
>>> MythTV and pretty much any player is aware of the difference and the
>>> file is played in sync. So it looks like the timing diff is done on
>>> purpose by some component of the recording chain, and the whole thing is
>>> done properly.
>>> My question was - why are not A and V muxed in sync? Why there's a time
>>> delta at all? For some reason, I expected a file dumped from a broadcast
>>> feed to have A and V in sync, with a 0 ms difference in between.
>> mythtv-users mailing list
>> mythtv-users at mythtv.org
More information about the mythtv-users