<    June 2018     >
Su Mo Tu We Th Fr Sa  
                1  2  
 3  4  5  6  7  8  9  
10 11 12 13 14 15 16  
17 18 19 20 21 22 _2_3  
24 25 26 27 28 29 30
02:25 chewey joined
02:34 ghoti joined
03:09 ircuser-1 joined
05:35 ivanich joined
07:35 kelnoky joined
08:00 HarryS joined
10:55 debianuser joined
11:54 iive joined
12:38 psychicist__ joined
12:38 amarsh04 joined
13:32 MindSpark joined
13:33 <MindSpark> hello, I have a very weak CPU and a HQ video which I would like to play. Is there a way to rescale the video to 10th the size before actual playing it?
13:33 <MindSpark> so I can at least watch it in lower res?
13:34 <MindSpark> I tried -lavdopts lowres=1 but this doesn't give me any video output at all
13:45 <iive> first, try using more cores, -lavdopts threads=4
13:45 <iive> if you have 4 virtual cores.
13:47 <iive> then you might want to try skipping some frames, like B-frames -lavdopts threads=4,skipframe=nonref
13:49 <iive> and the thing that would give least speedup is skiplookfilter=all , it could create some artifacts, but it's rare on real life footage. gopro encoder might not even use loopfilter.
13:49 <iive> also, even old computers and cards might support fully hardware decoding, see if you have vdpau support.
13:50 <iive> `vdpauinfo` for the system and `mplayer -vo help` for mplayer. if you have it, then `mplayer -vo vdpau, -vc ffh264vdpau, ` might do the trick.
13:51 <iive> mesa3d supports it on most radeons from the last 10 years, nvidia binary drivers support it on their hardware.
13:53 <iive> lowres has been practically deprecated. it makes the decoders a lot more complicated, while providing minor speed-up. These days it is used only for jpeg2k and wavelet formats that naturally upscale the frames.
13:59 hfb joined
14:03 MindSpark joined
14:19 ivanich joined
14:26 iive joined
14:28 <iive> did i miss something?
14:33 <MindSpark> nope. How do I find out if I have vdpau?
14:33 <MindSpark> My processor is a 1.6Gh Atom. I mean a really old/weak one
15:23 <* debianuser> played 720p H.264 video on 1.6GHz Intel Atom laptop in software rendering. That required a custom CPU-optimized mplayer build however.
15:24 <debianuser> (That laptop actually had hardware decoding chip, I managed to make it working via vaapi, but it was rather limited and failed to decode many H.264 High-profile videos.)
15:27 ntd joined
15:28 <debianuser> MindSpark: Still, try building mplayer yourself there, it includes many CPU optimizations by default, then run it right from the build dir i.e. ./mplayer yourvideo.mp4 and see if it's fast enough.
15:29 <ntd> I'm trying to both display and record video from v4l2 sources (bt878/bttv, /dev/video*). the recording software *can* do this and generate an mjpeg stream for each at localhost for me to display
15:30 <ntd> problem is, it's channel switching and deinterlacing leaves much to be desired
15:31 <ntd> if i mkfifo /tmp/pipe* and have mplayer play /dev/video* to each fifo the image is better, so is the framerate
15:32 <debianuser> ntd: Ah, forgot to tell you yesterday, you can use `tee` to duplicate same output to multiple pipes, e.g. `cat ... | tee /tmp/pipe1 /tmp/pipe2 > /tmp/pipe3`
15:32 <ntd> mplayer -vo yuv4mpeg:file=/tmp/pipe0 -tv driver=v4l2:input=0:width=720:height=576:outfmt=i420:device=/dev/video0 tv://
15:33 <ntd> problem is, each /dev/video* has two channels (:input=X) and once mplayer starts playing channel 0 the device is locked and i can't pull channel 1(2)
15:35 <ntd> was looking into v4l2loopback, won't solve the channel issue and also doesn't compile on kernel 4.15 :)
15:36 <ntd> the recording software has no problem recording from the fifo, problem is multichannel
15:38 <ntd> debianuser, i can't tee the inputs/sources, first line software will have to tell the driver/hw which res and palette to use
15:41 <debianuser> ntd: Hm... I don't know if it's possible to capture multiple inputs at all... I mean I've just tried to start `m -tv input=0 tv://` in one terminal (it started fine), then in the other one I started `m -tv input=1 tv://` and it exited instantly... BUT... the input switched from 0 to 1 in the first mplayer.
15:41 <debianuser> (`alias m=mplayer`)
15:42 <debianuser> I mean it looks like "input" is a sort of current driver option, you tell the driver which input you want to capture, and it provides you that. I don't know if you can ask the driver to provide multiple inputs at once...
15:43 <debianuser> The best thing you can do is to switch inputs around, capturing one frame from each input, but I guess you'll have ~4 fps with that approach.
15:45 <ntd> yeah, i'm gonna try the fifo approach at a site with multiple capture cards, each input has it's own chip/videodev there
15:45 <ntd> still, 4fps with proper deinterlace would be a step up, how do you suppose i should attempt to do this?
15:47 <debianuser> I mean start capturing in one mplayer, and in another terminal run something like `while true; do for i in 0 1 2 3; do mplayer -tv input=$i tv://; sleep .25; done; done`
15:47 <debianuser> ntd: By the way, you can try asking in #v4l or #linuxtv if it's possible to capture multiple v4l2 inputs at the same time...
15:50 <debianuser> in case there's some trick in modern drivers to do that...
15:56 <debianuser> (probably using something like v4l2-ctl to switch inputs would be better: `while true; do for i in 0 1 2 3; do v4l2-ctl --set-input=$i; sleep .25; done; done`)
16:06 <debianuser> ntd: another hack (for each input make mplayer capture just 1 frame and exit): while true; do for i in 0 1 2 3; do mplayer -vo yuv4mpeg:file=/tmp/pipe0 -tv input=$i tv:// -frames 1; done; done
16:13 <ntd> #v4l is idling harder than #beos
16:16 <debianuser> maybe they all switched to #v4l2? ;)
16:20 <bencoh> :]
16:24 <bencoh> hmm, funnily enough, mplayer -vo vdpau takes 2x more cpu than -vo gl
16:24 <bencoh> "something somewhere went wrong"
16:25 <bencoh> ah, right ... forgot the -vc
16:25 <bencoh> much better :)
16:27 <bencoh> that basically means that one should set vo/vc according to video format in .config file ...
16:28 krabador joined
17:46 ntd joined
17:47 <ntd> debianuser, gonna look into it, thanks
17:48 <ntd> i was just hoping there was a obscenely clever move to be done her, have mplayer/mencoder both encode the v4l inputs as x264 fifo/sinks/loopback devices and play them through vdpau
17:49 <ntd> would save me a lot of cpu
17:49 <ntd> but now we're moving into rube goldberg territory :)
18:12 hfb joined
20:00 dv_ joined
20:38 ntd joined
20:55 ivanich joined
22:02 hfb joined
23:05 ntd joined
23:31 <gnarface> ntd: i'm pretty sure it's something those devices are physically incapable of but if you hear otherwise i'd be curious to find out about it
23:32 <gnarface> the single-input-selection is most likely some constraint of the hardware itself
23:32 <ntd> yeah, the recording software is supposed to have pretty solid v4l capabilities (just doesn't deinterlace very well) and 4fps is max on dual channel inputs
23:33 <gnarface> -vo vdpau:deint=4,hqscaling:9
23:33 <gnarface> i use this for my "-vo"
23:34 <gnarface> the default for vdpau is actually not to deinterlace at all
23:34 <gnarface> at least in mplayer
23:34 <ntd> that's for mplayer though. using the fifo option i've found that mplayer quits once the fifo is no longer being pulled by other sw
23:34 <gnarface> so that may have been negatively impacting the performance of your tests
23:34 <gnarface> you can play to mplayer from stdin though, ... you shouldn't need the fifo
23:35 <ntd> i'm trying to use mplayer to pull the video and deinterlace it, then make it avail to other sw as a fifo device
23:35 <ntd> because bttv will only let one process access the input at a time
23:36 <ntd> ofc, if mplayer can both create the fifo *and* display it through vdpau at the same time i'll save some cpu