[Ffmpeg-devel] mpeg transport streams
Mon May 30 10:40:51 CEST 2005
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
> > 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 ;-)
More information about the ffmpeg-devel