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

Tim Davies tim at opensystems.net.au
Tue Jan 18 23:16:35 EST 2005


Eric,

I think the ATSC code (hdtvrecorder.cpp) only outputs a TS right?  And 
dvbrecorder.cpp can record either a TS or a PS.

 From what I can see (when recording a TS), the LocalProcessData in 
dvbrecorder.cpp doesn't do much.  It just rights a PAT and PMT every now 
and then, and outputs the packet data.  It doesn't surprise me that it 
basically just works.  At least the recording side of things anyway.

When recordng a PS (where I have the problem), more processing is done; 
GOP stuff etc.

The more I look at it, the less I see in common with the ATSC code.

My instinct says something is I/O bound.  Anyway...


Eric Anderson wrote:

>
>
> 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
>
>------------------------------------------------------------------------
>
>_______________________________________________
>mythtv-dev mailing list
>mythtv-dev at mythtv.org
>http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-dev/attachments/20050119/c8e49de7/attachment-0001.html


More information about the mythtv-dev mailing list