Yes. Every call to prep... transfers 720*576 Y & 720*576/2 UV data. I guess it could be made to work. Cutting this down to half of that could well work. The code in there that sets up the SG array's for transfer is going to start getting messier :)
Currently it also transfers 720*height every time but it can easily transfer less if we are playing back smaller sized video. >From what you have seen we might also be able to get the card to do some scaling if we set it up properly. Let me know if you need any help. John --- Matthew Hodgson <[EMAIL PROTECTED]> wrote: > John Harvey wrote: > > > --- Matthew Hodgson <[EMAIL PROTECTED]> wrote: > > > >> > >>Using my painfully-simple vo_ivtvyuv for MPlayer > >>(uses > >>IVTV_IOC_PREP_FRAME_YUV with VFCAP_TIMER; see > >>previous thread), the > >>following problems still present: > >> > >>a) Roughly 1 in 30 fields(?) are dropped, > resulting > >>in the field order > >>inverting for a bunch of consecutive frames - > >>causing horizontal motion to > >>judder spectacularly. (At least I assume it's a > >>per-field rather than a > >>per-frame problem, as the juddering is actually > >>'sawtooth' in shape rather > >>than just a skipped frame). There is a small > chance > >>that this is due to a > >>screw-up in vo_ivtvyuv causing MPlayer to intefere > >>with the timings. > > > > I'm surprised it's a per field thing but it is > > possible. I haven't really worked out what we > should > > be doing here. There are 2 sets of pointers and i > > assume they can be set to point at different > fields. > > Does that mean that both buffers get DMA'd over to > the card for every call > to ivtv_yuv_prep_frame? > > Presumably this is the mysterious > > /* Reprogram Decoder YUV Buffers for YUV */ > ivtv_write_reg((yuv_offset[0] >> 4), itv->reg_mem + > 0x82c); > ivtv_write_reg(((yuv_offset[0] + > IVTV_YUV_BUFFER_UV_OFFSET) >> 4), > itv->reg_mem + 0x830); > > ivtv_write_reg((yuv_offset[0] >> 4), itv->reg_mem + > 0x834); > ivtv_write_reg(((yuv_offset[0] + > IVTV_YUV_BUFFER_UV_OFFSET) >> 4), > itv->reg_mem + 0x838); > > code... I wonder if one can do interlaced YUV > playback by separating a > single frame into even & odd fields (but ignoring > every other line in both > fields) - and whether this might also fix the > tearing... Currently I have > to initialise the ITVC with some progressive-encoded > MPEG2 footage to get it > to display both the odd & even fields of subsequent > YUV, which is nonideal - > and it looks as if this could fix it. I'll have a > play. > > > We have them both set to point at the same lump of > > memory so both fields should be being displayed > from > > the same frame. However the vsync interrupt i > believe > > fires on a field basis so it's possible we swap > the > > memory on the wrong one sometimes. I'll have a > think > > about this at some point later in the week. > > > > > >>b) The chrominance component still tears about > 1/3rd > >>of the way down the > >>screen - whilst the luminance component is > correctly > >>synced with the top of > >>the screen > >> > > > > Odd but entirely possible.I think we will have to > move > > some work into the interrupt handler to improve > this. > > From memory i believe you posted some code & mpeg > file > > before? Are these still valid to use? > > Sure: the simple vo_ivtvyuv libvo plugin is at > http://opensource.mxtelecom.com/ivtv/ together with > a very simple > progressive 25p MPEG2 which demonstrates the chroma > tearing problem under > PAL (a horizontally scrolling black/red vertical > transition). > > If you view it by catting into /dev/video16 all's > fine - but if you then > compare it with > > mplayer -vo ivtvyuv -vop scale=720:576 -fs > chromalag-25p.mpg -loop 0 > > the problems are painfully apparent. Likewise for > skipping-50i.mpg for the > field(/frame?) skipping problem. > > I'm not developing under X, so I haven't tried your > xv driver - but I assume > that it demonstrates the same behaviour...? > > > > >>c) Switching from YUV to MPEG decoding stops > >>subsequent YUV decoding from > >>displaying anything. > >> > > > > This makes me understand a problem someone else > was > > seeing that didn't make sense to me. I'll take a > look > > later this week. > > woo - I had a look, but was completely stumped as to > how to which component > fails to reinitialise for YUV properly... > > -- > ______________________________________________________________ > Matthew Hodgson [EMAIL PROTECTED] Tel: +44 > 845 6667778 > Systems Analyst, MX Telecom Ltd. > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space > Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click > _______________________________________________ > ivtv-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/ivtv-devel > ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click _______________________________________________ ivtv-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ivtv-devel
