On Sat, 2008-11-01 at 18:36 -0400, Jeff Campbell wrote: > 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:
> 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. Ah, thanks for the details. I knew he had, but I never tested. > 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. Oh, I know the driver contributes. Audio can come up to a few seconds ahead of the video. See below... > I am going to build the latest version of the driver as well as a > 2.6.27.4 kernel later tonight to test against. > Here is a patch I submitted but was rejected by the v4l-dvb maintainer: http://linuxtv.org/hg/~awalls/v4l-dvb/rev/a81c3fdf53e8 It changes the buffer handling and some of the module parameter semantics/units (which is why it was rejected) to allow a user to specify arbitrary buffer sizes. Using individual MPEG buffer sizes around 8k smoothed out the PS rather well. Occasional frames with very small payload still jittered, but overall watchable without buffering. > 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. > As I recall from watching mplayer's status line, the problem is the audio gets ahead of the video. Watch the seconds of audio decoded (A:) seconds of video decoded (V:) and the difference (A-V:) on the mplayer line. You'll see that A-V: can get several seconds into the positive. > Great news about the pending improvements on simultaneous analog and > digital capture. Many of the outstanding problems and my VBI problems seem to be related to interrupts and the mailboxes. I'm hoping a few things get resolved at once. Regards, Andy _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
