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 majordomo@xxxxxxxxxxxxxxx > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
