[mythtv] Random blockiness that probably isn't CPU or PCI bus bandwidth-related

Eric Anderson rico99 at sbcglobal.net
Tue Jan 18 21:51:49 EST 2005


Tim -

Interesting data point. Thanks for your post.

Maybe the DVB people will wind up needing a ring buffer after all! =)

Seriously, I would be happy if I could find a simple bug fix in the PS 
filtering code
that would fix this. But I can't think of a place there where I would 
have packets
duplicated so far apart anywhere below the ProcessData() calls.

If you have a messed up recording, and have some time, please do try the
simple xsum188 program I sent on some sections. If you're only getting 
drop-outs
(without duplications), then that would indicate the TS extraction and 
GOP
marking code is falling behind. But if you are getting similar packet 
duplications
to what I've seen, that might indicate something broken that's common 
to the
ATSC and DVB code.

Regards.

-Eric

On Jan 18, 2005, at 6:19 PM, Tim Davies wrote:

>  I might be barking up the wrong tree here, but...
>
>  This may be the same problem I have seen with HD broadcasts on DVB.  
> If I record a PS, the 1080i streams get blocky and unwatchable.  This 
> happens whether I watch the (myth recorded) stream in myth or mplayer.
>
>  On the other hand, if I record the TS it doesn't happen (although I 
> get seeking problems - another story!).  So it's not a PCI or CPU 
> problem (unless the PS filtering code is really inefficient!).
>
>  This cursory examination would point me to dvbrecorder.cpp, but it 
> would only be relevant to you if you were using the DVB driver for 
> ATSC, or there is some common code for filtering the stream and 
> generating a PS in both.
>
>  I was going to have a look at this when I get a bit more time!
>
>  Cheers,
>
>  Tim.
>
>
>  Eric Anderson wrote:
>
>  Doug -
>
>  No. The "bad" recording is corrupt -- if you play it you get MPEG 
> playback errors, etc. Blockiness,
>  choppiness, whatever you want to call it. In most cases it makes it 
> pretty much un-watchable.
>  By comparison, a "good" recording plays back without errors, and does 
> not have duplicated
>  packets (other than PAT, PMAP kind of stuff).
>
>  The duplicated packets are anywhere from ~750 to ~1150 packets away 
> from each other.
>  (But remember, this is *after* filtering out only the program being 
> recorded, etc. If I were saving
>  *all* of the packets, maybe I would see a more regular separation. I 
> don't know.)
>
>  Also, the duplication is not centered around the GOP frames in any 
> way. It's just that the GOP
>  frames are the only *easy* way I have of determining what data should 
> be where. The other
>  packets do not have sequence numbers (that I know where to find at 
> least).
>
>  I see runs of duplicates anywhere from 6 packets to 130 packets in a 
> row. And by looking at
>  the GOP sequence numbers, I can "guess" that it's not just that 
> something was repeated,
>  something else got squashed (consistent with a ringbuffer problem).
>
>  Note: This could also be a cache coherency thing, or PCI thing, 
> CX8800 hw bug, etc, etc...
>
>  -Eric
>
>
>  On Jan 18, 2005, at 5:08 PM, Doug Larrick wrote:
>
>
>  Eric Anderson wrote:
>
>  So yesterday I wrote a small program to scan through the saved
>  transport stream to try to figure out *how* the data was corrupted.
>  What I found is sets of duplicate packets. Thus, I am starting to
>  think that this is a driver issue.
>
>
>  Just out of curiosity... do the duplicate packets also have duplicate 
> sequence numbers, and do they immediately follow one another?  If so, 
> it  *could* be your station broadcasting duplicates on purpose for 
> better error recovery.  If I were going to do so for video, I'd do it 
> on the GOP frames.
>
>  -Doug
>  _______________________________________________
>  mythtv-dev mailing list
>  mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
>
>
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
>
>  _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 4211 bytes
Desc: not available
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20050118/e7c9fbca/attachment.bin


More information about the mythtv-dev mailing list