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

Eric Anderson rico99 at sbcglobal.net
Tue Jan 18 23:29:30 EST 2005


Tim -

Oh, I see. I haven't looked much at the DVB recorder code.

Yes, the hdtvrecorder only outputs a TS. But I should point out -- the 
hdtvrecorder does look for
where GOP's fall in the TS. And it updates the database to keep track 
of the file position of each
GOP. This allows for quick seeking on GOP boundaries. On the downside, 
it also means steady
database activity while recording.

-Eric


On Jan 18, 2005, at 8:16 PM, Tim Davies wrote:

>  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
>
>
>  _______________________________________________
> 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: 5896 bytes
Desc: not available
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20050118/9a1f6847/attachment.bin


More information about the mythtv-dev mailing list