Welcome back Andy. On Sat, Nov 1, 2008 at 8:54 AM, Andy Walls <[EMAIL PROTECTED]> wrote:
> On Fri, 2008-10-31 at 15:46 -0400, Jeff Campbell wrote: > > Hi Andy, > > > > My apologies for not getting back with the pci details, I've been away > > from the hardware that has the problem for a few weeks (and using my > > other box). I'm now getting back at it. > > > > I wanted to followup on your suggestion that I use mplayer with a 16MB > > buffer to play the stream if reading directly off /dev/video0. > > > > While that works, I was curious if there are any plans, or if it is > > even possible, to do some buffering on the driver side so that the > > resulting native TS is more stable. > > First what do you mean by native TS? Analog captures default to an MPEG > PS, but supposedly the chip can also be set to do a TS for analog > capture (I haven't tested it yet). Digital captures are just a > pass-through of the TS from another chip. > Let me give an update here. By setting the stream_type=1, you can get native TS from the card/driver. This is something Hans added support for a few months ago. This does in fact work and I have successfully multicasted it and played it back. It was generally watchable for test purposes but did suffer from the jitter problem. Ultimately I ended up experiencing significant audio/video sync issues (over time) with the audio falling multiple seconds behind the video. The actual video frame rate seemed fine (my input source was a DVD player) and the audio, as I recall, was good but suffered occasional dropouts. I am looking in to a way to pre-buffer this before transmitting it to try and smooth it out. I have had some success adjusting buffer sizes on the client side that is joining the multicast, but nothing conclusive yet due to various other factors. I am doing more testing tonight and will report any material findings. So far I've had no audio and audio sync issues, but there are a lot of variables in my test setup so I don't want to say its the card or driver just yet. I am going to build the latest version of the driver as well as a 2.6.27.4kernel later tonight to test against. > > Well, I have some plans for buffers changes, but buffering up 8 or 16 MB > in kernel space wasn't one of them. The problem is one of non-uniform > rate of delivery of audio and video buffers, I think. > Your description of non-uniform rate of deliver sounds correct and seems to match the errors that I see in the messages window in the vlc client while playing back a stream. > > I don't know how to get the chip to transfer 1 video buffer per frame, > so the solution is to use smaller transfer buffers to get the chip to > hand them over sooner. The problem is the driver is simply written to > stay with in the buffer count limit of 63 buffers usable by the firmware > at any one time. Making the buffers smaller to smooth out transfers > while staying under 63 buffers makes for a very small overall buffer. > > I plan to change the driver to manage more than 63 buffers per stream > and let the user control buffer sizes to meet their latency needs. But > right now I investigating some interrupt and mailbox problems to try to > resolve problems with simultaneous analog and digital capture. > Hopefully that will make things better too. > We all appreciate your efforts. I'll try and do some more structured testing and report back on what I find. Great news about the pending improvements on simultaneous analog and digital capture. > > > > > VLC really chokes on it if you try and play it directly, due to late > > picture and late sound. > > OK. I never tested VLC. I've been using 0.8.6 under linux but also install 0.9.4 under Vista today, so I'll report anything that seems material. -Jeff
_______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
