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. .Geoff _______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
