Em 08-07-2010 19:10, Ivan escreveu:
> On 07/08/2010 05:49 PM, Devin Heitmueller wrote:
>> That card does have an onboard scaler, although it's not clear to me
>> why it isn't working. Exactly what command line did you use?
>
> At first, I was always using
>
> mplayer tv:// -tv device=/dev/video1:input=1:norm=NTSC
>
> which defaults to a resolution of 640x480. This output looked correct (except
> for vertical stripes) in kernel 2.6.32-23-generic, but was horizontally
> shifted after I updated to the current mercurial sources.
I never saw the em28xx scaler generating such vertical stripes. This could be a
mplayer or a video adapter driver problem.
Are you using a proprietary video driver? You may try to use ffmeg or mencoder
to generate a mpeg file at 640x480 and then
try to play it on another player (preferably on another machine), to see if
this problem disappears.
>
> Then I noticed that
>
> mplayer tv:// -tv device=/dev/video1:input=1:norm=NTSC:width=720
>
> gives a correct picture with current hg source.
>
>>> v4l2: 1199 frames successfully processed, -3 frames dropped.
This is not a V4L issue.
A negative number of dropping frames makes no sense. It is probably a mplayer
bug.
I would try to get a newer version of mplayer and double check.
If your video adapter is not fast enough, or if some post-processing logic at
mplayer
are enabled and you don't have enough processing speed at both CPU and GPU,
mplayer may
complain about frames dropped. It may also be related to audio driver, if
you're enabling
alsa at .mplayer/config.
When you have frames dropped, it may help to replace the video and audio output
(-vo and -ao)
to use one of the several different mplayer output drivers. On my own tests, I
generally use
sdl, gl or gl2 drivers for output, instead of x11, as they provide a better
performance with
the video adapters I have here.
To get a list of available drivers, you may use:
$ mplayer -vo help
>>> ...
>>
>> Yeah, I don't know. You would have to ask the mplayer/mencoder people.
>
> Ah, so those statistics are generated by mplayer, then, not by v4l.
>
>>> It would also seem that V4L doesn't actually discard any frames...
>>> ...blah blah blah about mencoder...
>>
>> Again, this would be an mplayer/mencoder thing.
>
> I guess I'm just trying to confirm that v4l doesn't try to enforce a strict
> NTSC framerate, but just passes all frames on even if they appear at a
> slightly different framerate.
V4L doesn't enforce a framerate. It will just send frames to userspace as
they're being available
by the hardware and provided that the application is fast enough to get frames
at the hardware speed.
em28xx hardware outputs NTSC frames at about 30 fps.
>
> Ivan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
