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
