[mythtv] [mythtv-commits] mythtv commit: r8606 by ghaushe

Geoffrey Hausheer mythtv0368 at phracturedblue.com
Sat Jan 14 18:33:22 UTC 2006

On 1/14/06, Daniel Kristjansson wrote:
> This is probably a safe change, but why is it needed? Shouldn't whatever
> function moved us past the 0 position bring us back (probably the stream
> type detection)? What if we were reading from a device handle or
> streaming from a remote backend, how would this seek be handled?
Well this is the read_header funtion.  I'm not sure where it gets
called, but it seems to be during the av_open_file step.  The seek
doesn't actually set the postion to '0', it sets it to whatever the
position was before the get_buffers call (which sucks in 1024 bytes
and is used to determine the TS packet size).

> This whole function is completely unsafe anyway because it assumes that
> the PAT and PMT are never change. If a you have a PMT at pos 0 and a new
> PAT at pos 2000, this function will use the PMT at pos 0 rather than a
> PMT following the PAT so that the initial stream info will be completely
> bogus (because of that seek after the PAT scan). With MythTV this is
> mostly not a problem because the recorders clean up the raw streams, but
> this is still a problem with the Firewire and DBOX2 recorders.
I really don't understand enough about it to say.  In my case, I have
streams captured by myth 3 months ago that have the 1st PAT correct,
and all additional PATs seem to have a bunch more PIDs in them (almost
like the filter didn't work properly). I've never been able to watch
them through myth, though they work fine through mpayer.  Recordings
made more recently (or longer ago) don't have this issue.  I have no
idea what causes it, but the seek I added is in the original ffmpeg,
and it doesn't appear to be related to the SDT stuff.


More information about the mythtv-dev mailing list