[Ffmpeg-devel] mpeg transport streams

[Erik Slagter]

On Sat, 2005-05-28 at 11:58 +0200, M?ns Rullg?rd wrote:

> > What I meant is that manufacturers tend to make incomplete
> > implementations in hardware (money, incompetence, ..., ?), so they make
> > a binary-only "driver" (windows of course) that masks the omissions, and

> That doesn't explain why some software bails out totally if the PCR is
> a little out of spec.  The worst thing is when it does so with the
> message "bitrate is less than 64kbps".

For example (with your example) there is a bug in the PCR handling, but
they won't fix it because a) that costs $ and b) it may break other
things (which of course also is fixable and costs more $). As long as
the customers buy, manufacturers tend to not fix bugs.

> > make the documentation NDA, so you cannot find out (easily) that you've
> > been fooled. See promise raid controllers and e.g. the Philips saa7134
> > video grabber (end rant ;-))

> Which part of the saa7134 isn't?  In my experience, it works quite
> well with Linux and open drivers.

If you have a signal with poor sync, the saa7134 will be screwed up
sooner or later (mostly sooner), requiring a hard reset (== power cycle
computer). The probable workarounds from the manual (nda!) (like "VCR"
mode, "regenerate sync" mode, etc.) simply don't work. I am sure there
are more such "bugs" but I didn't run into them yet. NDA docs make me
very suspicious.

> > Volunteers? ;-) I am not using TS much, only for reading from the STB,
> > so I don't have much motivation as well ;-)
> 
> Well, then perhaps you're motivated to improve the demuxer.  For
> starters, I think we should drop that useless SDT parsing to speed
> things up a little.

I don't even know what a SDT is ;-) ;-)

I'll keep it in mind for when I'll have lots of spare time ;-)