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

Tim Davies tim at opensystems.net.au
Tue Jan 18 21:19:41 EST 2005


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
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-dev/attachments/20050119/baec3fac/attachment.htm


More information about the mythtv-dev mailing list