(delurks) I'm trying to get my Buz device to play nicely with mplayer/mencoder. The eventual idea is to integrate it fully with freevo without having to do a lot of additional hacks onto freevo to have it understand the lav tools.
My results are mixed and somewhat frustrating, and I'm approaching the list for ideas and pointers on what to try next. Any thoughts would be welcome (I'm not expecting miracle cures, but I can dream). I'm using: - NTSC and S-Video (correct mplayer options) linux kernel: 2.6.12 (stock debian kernel) - module params: pass_through=0 lock_norm=0 video_nr=0 default_norm=1 default_input=1 v4l_bufsize=1024 v4l_nbufs=16 - a boot param reserving the 16M of v4l memory (i.e. mem=496 ) - outfmt:yuy2 with mplayer. It seems to be the only pixelformat that mplayer and BUZ have suitably in common (either that, or there's some other bug lurking. I don't think it makes a *huge* difference.) The three directions I've been exploring: (1) mplayer -tv driver=v4l2:... Not a workable idea. Mplayer depends on "select()". From an earlier thread ( at http://sourceforge.net/mailarchive/forum.php?forum_id=3248&max_rows=25&style=nested&viewmonth=200308 , search for "select" ) it seems that the zoran drivers don't do what's expected. Maybe I should convince someone to hack on that for a while. I can bribe with pizza! :) Of course, it'll probably just run into one of the following scenarios even so. (2) mplayer -tv driver=v4l:... This actually mostly works! To a point. Whether it works or not depends heavily on the width and height you specify. The maximum I've been able to use is width=336 and height=480. Anything with a wider width (height appears irrelevant) causes mplayer to freeze, eventually reporting: ioctl mcapture failed: Device or resource busy and the driver (with debug=3): kernel: Buz[0]: VIDIOCSPICT - bri=53738, hue=32767, col=32767, con=27249, ... kernel: Buz[0]: VIDIOCMCAPTURE - frame=0, geom=640x480, fmt=7 kernel: Buz[0]: set_vfe() - width = 640, height = 480 kernel: Buz[0]: VIDIOCMCAPTURE - frame=1, geom=640x480, fmt=7 ...and more up to frame=15 kernel: Buz[0]: VIDIOCSYNC - frame=0 kernel: Buz[0]: VIDIOCMCAPTURE - frame=0, geom=640x480, fmt=7 kernel: Buz[0]: VIDIOCSYNC - frame=1 kernel: Buz[0]: v4l_sync() - no grab active for this session kernel: Buz[0]: VIDIOCMCAPTURE - frame=1, geom=640x480, fmt=7 kernel: Buz[0]: v4l_queue_frame() - another session is already capturing ... and repeats of the last four lines for each frame requested by mplayer until it's killed. Any insights why this might be are welcome (I can provide any additional information required). (3) mplayer -tv driver=v4l:mjpeg:... This one actually *almost* works as well! In fact, in one way, it's the best of the three. It has the full resolution of the ntsc frame (with decimation=1). The problem is that the MJPEG that comes back cannot all be handled by the libavcodec used to transform it. Specifically, no differential or differential-sequential encoding is handled. I certainly don't have enough JPEG or libavcodec knowledge to even begin hacking at this. I expect I'd have to go ask the ffmpeg/mplayer/libavcodec people to work on this, unless there's a way to tell Buz not to produce JPEGs libavcodec-mjpeg can handle. Like I said, I'm looking for ideas at this point, and I'm willing to poke and tinker more. With a little direction on what to look at next. Shawn ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
