[Ffmpeg-devel-irc] ffmpeg.log.20140322

[burek]

[01:16] <Sander> Hi can someone help me with a mapping problem
[01:22] <relaxed> Sander: I can try
[01:23] <relaxed> pastebin "ffmpeg -i input" and tell me what you're after.
[01:23] <Sander> i do it in combination with ffserver but i will past
[01:23] <relaxed> you lost me at ffserver
[01:24] <llogan> relaxed: let's go shopping.
[01:24] <Sander> aw :(
[01:24] <relaxed> llogan: shopping for what? is there a pub nearby?
[01:25] <llogan> i could use a pub about now...
[01:25] Action: llogan gets back to video editing, slowly, distractingly, and inefficently
[01:26] <relaxed> are you working in OS X?
[01:26] <relaxed> Sander: just pastebin it
[01:27] <Sander> oke moment
[01:27] <llogan> relaxed: no. a (excuse me as I sipt), a Wi-wi-wi...I can't say it. a work computer that I rarely use.
[01:28] <llogan> *spit
[01:29] <relaxed> premiere?
[01:30] <llogan> yes
[01:31] <relaxed> Sander: which streams do you want out of that?
[01:32] <Sander> Stream #0:0  and   Stream #0:7
[01:33] <relaxed> Sander: launch ffmpeg -i udp://@address -map 0:0 -map 0:7 ...
[03:09] <Guest19387> hello
[03:10] <Guest19387> in uotput i have about 800kb/s stream http://pastebin.com/khEtMXkq . how can i increase badwith up ti 1200kbps ?
[03:10] <Guest19387> sorry 1200 kbps
[03:11] <Jack64> /root/bin/ffmpeg -f flv -i rtmp://173.199.120.59:1935/CAREWORLDTVL/CAREWORLDTVL.stream-sd -acodec ac3 -vcodec -b:v 1200k
[03:11] <Jack64> ?
[03:12] <Jack64> after -vcodec libx264 sorry
[03:13] <Guest19387> Jack64, thank you
[03:14] <Jack64> you're welcome :)
[03:14] <llogan> Guest19387: use -maxrate and -bufsize
[03:15] <llogan> https://trac.ffmpeg.org/wiki/EncodingForStreamingSites
[03:16] <Jack64> llogan: wow didn't realize that, thanks llogan
[03:16] <llogan> that is for justin.tv, etc but it will describe VBV, which you should be using for cases with network speed is a limitation
[03:17] <Jack64> yes, it's very clear and a propos.
[03:39] <mjsmith> anyone used a windows named pipe as ffmpeg input? I keep getting pipe:pipename: Not enough space.
[03:49] <Guest19387> guys what command i shuld use for  setting jitter 100 ?
[03:55] <Guest19387> ?
[03:55] <Guest19387> what command i shuld use for  setting jitter 100 ?
[04:13] <mjsmith> relaxed, too bad he never told you the solution =\ http://mplayerhq.hu/pipermail/ffmpeg-devel-irc/2013-September/001636.html
[04:19] <relaxed> mjsmith: what was the question again?
[04:19] <mjsmith> anyone used a windows named pipe as ffmpeg input? I keep getting pipe:pipename: Not enough space.
[04:19] <mjsmith> apparently the CreateNamedPipe() syntax is wrong or something
[04:24] <relaxed> mjsmith: pastebin what you're trying. I'm at work and have access to some Windows 7 machines.
[04:33] <mjsmith> its alright relaxed i think im going to call it a day on this
[04:38] <Jaypan> Hello, I have just installed FFMPEG according to this page: https://trac.ffmpeg.org/wiki/CentosCompilationGuide
[04:38] <Jaypan> I installed it as my root user,
[04:39] <Jaypan> and FFMPEG is now available to my root
[04:39] <Jaypan> But I need it to be available for all users, including cron
[04:39] <Jaypan> The guide did not show how to do that
[04:39] <Jaypan> can someone provide some assistance?
[05:15] <Jaypan> I guess not. Thanks anyways!
[08:18] <Keshl> Is there some magical set of parameters that'll cause ffmpeg to output a video with a steadily increasing bitrate that can be used to test when a device hits its limit, somehow?
[08:25] <jbermudes> Keshl: using -t to set a max time you could loop through ever increasing bitrates
[08:26] <jbermudes> Record for 5 seconds at rate X, then start recording again at a higher rate
[08:26] <Keshl> I didn't follow half that. o_o
[08:26] <Keshl> ...That post was not helpful to anybody. Uh, lemme reword that.
[08:27] <Keshl> Are you saying that I should try recording on the device in question?
[08:31] <jbermudes> Like, you could do it manually, recording for a few seconds at a certain bitrate, then try again at a higher one, or you could try to automate it with a script
[08:31] <Keshl> Got'cha, oÉo.
[08:31] Action: Keshl snugs on and such -É-
[11:29] <voip> hello, guys
[11:31] <voip> di you have any chart or someting like for aproximatly calculate how many streams can conver for example 1 xeon CPU ?
[11:31] <voip> do
[11:31] <relaxed> one per thread
[11:32] <relaxed> what do you mean by streams?
[11:33] <voip> relaxed, you mean if i need convert 1- streams a ineed 6 cores cpu with 12 threads?
[11:33] <voip> for 10 streams
[11:34] <relaxed> it's possible to encode 12 files at one time, each using their own thread.
[11:35] <relaxed> "stream" is ambiguous when it comes to ffmpeg/encoding
[11:36] <relaxed> did that answer your question?
[11:37] <voip> i mean videostream converting
[11:37] <voip> transcoding
[11:37] <relaxed> yes, i answer that above ^^
[11:37] <relaxed> answered*
[11:38] <voip> relaxed, intresting i have xeon cpu with 4 threats, but when i transcoding ip videostream all my 4 cpu "kernels" loads for 98%
[11:39] <relaxed> You can tell ffmpeg to encode using only one thread, but by default it uses them all to transcode as quickly as possible.
[11:39] <relaxed> ffmpeg -i input -threads 1 .... output
[11:40] <voip> oooo, ok
[11:40] <relaxed> libx264 uses all threads by default. I assume that's what you're seeing.
[11:40] <voip> ok i see
[11:40] <voip> one more question
[11:41] <voip> can i use GPUs for acsleration
[11:41] <relaxed> no
[11:41] <voip> ok, tahnk you
[11:42] <relaxed> you're welcome
[13:04] <obiwahn> hi
[13:04] <obiwahn> do you know why ffmpeg is not in debian sid?
[13:05] <JEEB> obiwahn, because debian currently uses libav, which has the binary called avconv
[13:06] <obiwahn> what a shame ... the world seems to use ffmpeg:)
[13:10] <obiwahn> ok but avconv is quite useable as well:P
[13:11] <sacarasc> The avconv channel, though, is #libav.
[13:12] <JEEB> the main problem is that libav has had slow release cycles, and then debian and friends have had to migrate all their apps to the new APIs :P The latter of course counts for FFmpeg-using distros as well.
[13:12] <JEEB> so the sad joke is that up to ubuntu 13.10 you've basically had a libav version from 2012 come with your distro :|
[13:13] <obiwahn> Why did they switch?
[13:13] <JEEB> because the maintainer was one of the people forking out
[13:16] <JEEB> of course, old FFmpeg (up to 2010 or so? before the fork) was rather problematic, and I can see why some people would have seen libav as something better at the time. Of course current FFmpeg has been changed by the forking as well, and most of the problems of the old aren't really there :P (of course it has new problems, but so does Libav)
[13:17] <obiwahn> http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2011-December/022898.html
[13:18] <JEEB> yes, the release schedule over at FFmpeg was rather quicker, although I'm not sure if it really manifested itself that much at that point, as the fork was done in early 2011
[13:20] <JEEB> ok, Libav wasn't /that/ bad at releasing at that point yet
[13:20] <JEEB> because 0.7 was in June 2011 and 0.8 was in Jan 2012
[13:21] <JEEB> the real breeze then came with the <space> between 0.8 and 9
[13:22] <JEEB> which was a bit less than a year
[13:25] <JEEB> and the joke kind of goes on since Libav 10 has been in preparing-for-release mode since december and still isn't out :P
[13:26] <JEEB> (went to "beta" in february)
[14:40] <ValdikSS> Hello everyone! Can somebody tell me why ffmpeg changes subtitle .ass file even if -c copy is set?
[15:00] <Actium> hey there, i have a minor issue with the current ffmpeg git version. ./configure --enable-libopus results in "ERROR: opus not found"., although opus (including development files) is installed. i dug a little deeper and and found out that the problem can be solved by installing pkg-config. unfortunately the error message does not tell you just that.
[15:37] <Actium> well ... i just took a look (or rather a couple of looks :) at the configure script and apparently it is supposed to warn about a missing pkg-config, but doesn't
[15:38] <ValdikSS> Please test this: http://yadi.sk/d/NM69ZxZQKzNn7 and http://yadi.sk/d/qDFmsDPQKzNoQ
[15:39] <ValdikSS> Is there any difference in subtitle effects for you? Please tell me the OS and the player on which you were testing
[15:40] <Actium> no need to test anything as long as the ./configure fails
[15:40] <ValdikSS> https://lists.ffmpeg.org/pipermail/ffmpeg-user/2014-March/020583.html
[15:41] <Actium> sorry, thought you were refering to my issue ;)
[15:41] <ValdikSS> no sorry
[15:42] <klaxa> mpv 0.3.6 arch linux, ffmpeg remuxed subtitles seem broken
[15:42] <klaxa> i wonder why though
[15:43] <ValdikSS> cmplayer and vlc at archlinux seems broken too
[15:43] <ValdikSS> but if i extract the subtitles to .ass file with ffmpeg and include it with -i subtitle.ass, it works as expected
[15:43] <klaxa> maybe libass doesn't produce libass compatible subs :x
[15:43] <ValdikSS> I though on mkv tags or something, but no
[15:44] <klaxa> i think there was a similar issue like one and a half years ago
[15:44] <klaxa> let me find the logs
[15:44] <ValdikSS> Another strange thing that mplayer(1) plays fine
[15:45] <ValdikSS> klaxa: that's not only this file or this subtitles issue, it happens to me on a lot of files
[15:48] <klaxa> ValdikSS: https://gist.github.com/klaxa/197efb68e549d01193b8
[15:48] <klaxa> maybe there's a bugreport for that
[15:48] <klaxa> what version of ffmpeg are you using?
[15:48] <klaxa> note that this conversation dates back to november 2012
[15:49] <ValdikSS> I tried the latest git, it's the same
[15:49] <ValdikSS> That file was muxed using 2.1.4
[15:51] <ValdikSS> klaxa: I'm downloading libav static build right now, would test with it
[15:52] <ValdikSS> >
[15:52] <ValdikSS> Nov 10 00:59:03 <klaxa> if you extract the subs from the encoded file and use the .ass file directly it gets rendered properly
[15:52] <ValdikSS> Nov 10 00:59:25 <klaxa> if you use the embedded subtitles it doesn't work
[15:52] <ValdikSS> The same for me
[15:53] <klaxa> like i said, the same issue, just like a year and a half ago
[15:53] <ValdikSS> Even with ffmpeg-muxed subtitles with changed lines
[15:53] <klaxa> maybe CalimeroTeknik didn't open a ticket
[15:54] <ValdikSS> klaxa: >Nov 10 01:17:29 <klaxa>	if i use the .ass i get with mkvmerge and mux it with ffmpeg it doesn't work
[15:54] <ValdikSS> it works for me btw
[15:56] <klaxa> with codec copying or "re-converting" ass to ass?
[15:56] <ValdikSS> both
[15:56] <ValdikSS> tried with latest libav git, the same issue
[16:17] <ValdikSS> klaxa: if there is no default-flag for subtitles written, subtitles won't appear at all
[16:18] <klaxa> you will have to enable them in that case
[16:18] <klaxa> because they are not enabled by default
[16:18] <klaxa> afaik
[16:18] <ValdikSS> klaxa: if i set default-flag to everything, it's set to "default" (not to yes or no), but subtitles would appear correctly
[17:14] <teamen> I'm playing a playlist (m3u) file with vlc & ffmpeg (cvlc --demux ffmpeg --codec cedar --vout cedarfb --no-osd list.m3u). However, the format of the input file can't be detected ("avformat demux debug: couldn't guess format"). How can I make this work?
[17:16] <teamen> The content of the M3U file is a list of video streams, when forcing the video format (--ffmpeg-format mpegts), I receive "avformat demux error: Could not open list.m3u: Operation not permitted"
[17:27] <ValdikSS> teamen: you can't use playlists in vlc with forced demuxer afaik
[17:27] <ValdikSS> OR you can try to "unblacklist" ffmpeg m3u demuxer
[17:29] <teamen> ValdikSS: how can I do this?
[17:34] <ValdikSS> teamen: i can't remember
[17:34] <ValdikSS> why do you want to use demux globally anyway?
[17:38] <teamen> I'm running this on particular hardware that require these arguments: http://linux-sunxi.org/VLC
[17:40] <ValdikSS> teamen: well, since I don't remember unblacklisting parameter, you can try --demux playlist,ffmpeg
[17:41] <ValdikSS> teamen: you'd better ask in vlc channel
[17:42] <teamen> ValdikSS: that seems to work, very nice, thanks very much!
[17:56] <ValdikSS> klaxa: mxplayer on android plays ffmpeg remux without issues
[18:06] <Hfuy> Hello.
[18:06] <Hfuy> Can anyone suggest some options I could use with the aim of creating an mp4 that's easy to replay? I need 1080p25 on a Turion 64 x2.
[18:06] <Hfuy> Or, I suppose, another codec. Video in question is 30 seconds long and would need to play from an SD Card.
[18:07] <Actium> have you tried x264 with fastdecode tune?
[18:08] <Hfuy> I don't have x264 to hand, just ffmpeg.
[18:08] <Hfuy> Actually to be accurate I need 1200p25 decode on a turion 64. These are 1920x1200 monitors :/
[18:09] <Actium> what codecs does your ffmpeg support?
[18:09] <Actium> i assume/hope x264 is linked in :)
[18:09] <Hfuy> It's a windows 64 bit build. It presumably does.
[18:10] <Actium> when you took one of the pseudo official static builds it should
[18:10] <Hfuy> Actually it looks a bit like -lavdopts threads=2 is enough to fix it.
[18:10] <Hfuy> (when playing with mplayer)
[18:10] <Hfuy> It's not -perfect-, but...
[18:11] <Actium> have you tried mplayer -benchmark? it should tell you where the bottleneck is
[18:11] <Hfuy> Didn't even know it existed.
[18:11] Action: Hfuy tries it
[18:12] <Hfuy> Hmm. Not sure what these results are trying to tell me.
[18:13] <Hfuy> VC 13.6 VO 19.3 A 0.00 Sys 0.753s = 33.7s
[18:13] <Hfuy> then another one
[18:13] <Hfuy> VC 40.5 VO 57.6 A 0.00 Sys: 2.312 = 100%
[18:13] <Hfuy> If my interpretation is right, it isn't bottlenecking at all. It's doing it right. No?
[18:15] <Actium> how long is your video exactely?
[18:16] <Actium> this is what a 10s clip's benchmark looks like when played back on my machine:
[18:16] <Hfuy> 00:00:29:22 @ 25p
[18:16] <Actium> BENCHMARKs: VC:   0.042s VO:   0.078s A:   0.035s Sys:   9.837s =    9.992s
[18:16] <Actium> BENCHMARK%: VC:  0.4185% VO:  0.7765% A:  0.3474% Sys: 98.4576% = 100.0000%
[18:17] <Actium> your first line tells you that mplayer spends a lot of time on video output
[18:17] <Hfuy> On the basis that it totalled more than the theoretical duration, it's presumably bumming it up somewhere.
[18:17] <Actium> yep
[18:17] <Hfuy> This is an XP box.
[18:17] <Hfuy> (well, the target machine is)
[18:17] <Actium> in my case most time is spend on Sys (i.e. idling/sleeping)
[18:17] <Hfuy> I assumed it would default to directshow output.
[18:18] <Actium> try a different output first, if you found the optimal one you can try to tune the time spent on decoding
[18:18] <Hfuy> Right now I'm simply trying to get this damn laptop to drive a 1920x1200 display correctly - at all.
[18:18] <Hfuy> Bleagh.
[18:19] <Hfuy> Ancient laptop lacks DVI. Monitor fails to understand concept of widescreen analogue.
[18:20] <Actium> i didnt even know vga supported 1920x1200 :)
[18:20] <Hfuy> I fear it doesn't. It's doing that strange sliding-around thing.
[18:21] <Hfuy> I have an HTA (remember those?!) which draws alternating columns of red and blue to encourage monitors to phase detect widescreen VGA properly. It's got a nearly 100% success rate. Wish me luck...
[18:22] <ValdikSS> klaxa: http://yadi.sk/d/5l7wnAECKzrnj another example
[18:22] Action: Actium keeps his fingers crossed
[18:22] <Hfuy> ...bugger
[18:24] <Hfuy> Nnnnn...no.
[18:24] Action: Hfuy rants
[18:26] <cody_> i want to decode and display a h264 bitstream in realtime
[18:26] <cody_> how could i do that
[18:26] <cody_> no buffering, no audio
[18:26] <cody_> http://ffmpeg.org/doxygen/trunk/h264_8h.html
[18:26] <cody_> is that the right place to look at?
[18:31] <Aiena> can ffmpeg be used to take a screenshot and encode it as png or jpg ? what would be the command for that ?
[18:31] <Aiena> screenshot not video
[18:31] Action: Hfuy pokes display settings w/big stick and succeeds in the end
[18:32] <Hfuy> Is there a switch to make mplayer go fullscreen on an alternate display? It's insisting on using the laptop's built-in.
[18:33] <Actium> --fs for fullscreen, but i dont know about the alternate display
[18:34] <Hfuy> I'm just getting green overlay key.
[18:41] <llogan> Aiena: linux or windows?
[18:42] <Aiena> linux
[18:42] <Aiena> llogan sorry I forgot to mention the platform
[18:42] <llogan> Hfuy: ffmpeg has the -tune fastdecode option as mentioned by Actium
[18:43] <llogan> when using the encoder libx264
[18:43] <Aiena> llogan I am using ffmpeg 2.1.4 on Suse 13.1
[18:43] <llogan> http://ffmpeg.org/ffmpeg-devices.html#x11grab
[18:43] <llogan> ffmpeg -f x11grab -framerate 25 -video_size 1680x1050 -i :0.0 -vframes 1 output.png
[18:44] <Hfuy> llogan: I'll get back onto that in a moment.
[18:44] <llogan> ffmpeg -f x11grab -framerate 25 -video_size 1680x1050 -i :0.0 -vframes 1 -q:v 2 output.jpg
[18:44] <Hfuy> Right now I'm distracted by trying to make mplayer work.
[18:44] <Aiena> llogan that will get just one image ?
[18:44] <llogan> yes
[18:44] <Aiena> Great thank you :)
[18:44] <llogan> -vframes 1 makes one image
[18:45] <Aiena> ok llogan ok just a moment my script is a lttle different I make make an error in converting that line
[18:45] <Aiena> let me pastebin it and you suggest How I should tailor the line
[18:45] <llogan> we don't really support scripts here. just try it manually, and if it works then you can mess with the script.
[18:54] <Aiena> thanks
[18:55] <Aiena> llogan -s and -video_size is the same right ?
[18:56] <llogan> Aiena: i guess so
[18:56] <llogan> although -r and -framerate have different behaviors, IIRC
[18:56] <llogan> not that frame rate really matters much for your case
[18:56] <Aiena> Ok
[18:58] <Aiena> llogan and the -i can accept an offset too right like "-i :0.0+5,5" ?
[18:58] <Aiena> -i is same as in encoding for videos ?
[18:58] <llogan> yes for the offset. the link i provided has examples.
[18:58] <llogan> sorry, i don't understand the -i question
[18:59] <Aiena> ok no problem I will test
[18:59] <Aiena> if it does not work then I will elaborate and ask
[18:59] <Actium> this might be of help, too: https://trac.ffmpeg.org/wiki/How%20to%20grab%20the%20desktop%20%28screen%29%20with%20FFmpeg
[18:59] <Aiena> thank you so much llogan
[18:59] <llogan> you can install xwininfo to get window coordinates
[18:59] <llogan> then run it and click the window you want and it will barf out the infos
[19:00] <Aiena> llogan that is what my script is already doing
[19:00] <Aiena> then it calculates and offset to remove the window decorations
[19:00] <Aiena> and that data is fed into ffmpeg -i option
[19:00] <Aiena> I was just wonderig if -i works the same in this case (a still) as it does for encoding a video
[19:01] <Aiena> as explained https://trac.ffmpeg.org/wiki/How%20to%20grab%20the%20desktop%20%28screen%29%20with%20FFmpeg
[19:03] <Aiena> llogan yes it does
[19:03] <Aiena> works great
[19:03] <Aiena> thank you so much for your help llogan
[19:03] <Aiena> I am very grateful.
[19:03] <llogan> no problem. i have to go pack now for a 3 mile hike to a cabin in the woods by the ocean.
[19:05] <Aiena> Alright. Travel safe and enjoy
[19:05] <mjsmith> is there a way to make ffmpeg pad an audio input in order to make it in sync with a video captured separately?
[19:06] <mjsmith> the input being from a pipe
[19:06] <Aiena> yes mjsmith I had found a guide on google for it.
[19:06] <Aiena> googling should help :)
[19:06] <Aiena> let me look
[19:06] <mjsmith> do you remember what you googled? :D
[19:06] <mjsmith> i was trying to pad this manually by fwriting zeros but im having no luck
[19:08] <Aiena> mjsmith but this may be more useful http://stackoverflow.com/questions/7426179/add-audio-with-an-offset-to-video-with-ffmpeg
[19:08] <Aiena> apad is there too but that is for padding at the end
[19:08] <mjsmith> unfortunately its not a simple offset shift
[19:09] <mjsmith> https://lists.ffmpeg.org/pipermail/ffmpeg-user/2013-December/018796.html more in line with what this guy was doing
[19:27] Action: Hfuy punches the air
[19:27] <Hfuy> Yyyyyyessss!
[19:27] <Hfuy> Finally got it working!
[19:38] <Hfuy> Right, back to the encoding issue. Can anyone recommend a reasonably up-to-date site with h.264 encoding examples?
[19:38] <Hfuy> I've tried just ffmpeg -i foo -b:v whatever out.mp4 but the quality is awful
[19:42] <Mavrik> well
[19:42] <Mavrik> telling ffmpeg what quality you want actually helps
[19:45] <Hfuy> any suggestions
[19:46] <Hfuy> I've found "-crf" used variously and it seems to help but I have no idea what it means or whether 22 is a sane value.
[19:47] <Mavrik> https://trac.ffmpeg.org/wiki/x264EncodingGuide
[19:47] <Mavrik> this. :)
[19:47] <Actium> dammit, mere 10 seconds too late :)
[19:48] <Actium> but the wiki is great
[19:48] <Hfuy> Yes, that's where I got it.
[19:49] <Actium> 23 is the default value and is quite alright. depending on your demands you could decrease it a little.
[19:49] <Actium> i tend to use 21 for my ... ehm ... bluray backups :)
[19:50] <JEEB> basically there is no perfect value
[19:50] <JEEB> use your eyes and ~5000 frames of your source, preferably from various points
[19:50] <Actium> yep
[19:50] <JEEB> and the highest value that still looks good to your eyes is the thing for that source
[19:50] <JEEB> you probably will have to poke the value a bit depending on the source, but similar sources can be encoded with the same value
[19:51] <Actium> this is a good description (link from previously mentioned wiki page): http://slhck.info/articles/crf
[19:52] <mjsmith> so anyone have an idea how to do this? Basically ffmpeg reading audio from stdin. If nothing is coming from stdin then write padding
[19:53] <Hfuy> 21 certainly is not the default value.
[19:53] <Hfuy> 21 looks OK.
[19:53] <Hfuy> Omitting -crf produces unwatchable results.
[19:53] <mjsmith> i think crf 23 or 24 is the default
[19:54] <Hfuy> Whatever the default is, it doesn't produce useful results.
[19:54] <Mavrik> hmm, is your ffmpeg old? :)
[19:55] <Hfuy> Ten minutes is old for ffmpeg
[19:55] <Hfuy> ffmpeg version N-57245-gf6b56b1 Copyright (c) 2000-2013 the FFmpeg developers
[19:55] <Mavrik> hmm
[19:56] <Mavrik> that's probably not a sane default then
[19:56] <sacarasc> October, eh?
[20:01] <Hfuy> Not a clue.
[20:01] <Hfuy> Sounds reasonable.
[20:01] <Hfuy> Most people just include a date, you know.
[20:01] <sacarasc> Not reasonable...
[20:01] <sacarasc> 	Fri, 18 Oct 2013 21:38:54 +0000 (23:38 +0200)
[20:01] <sacarasc> commit	f6b56b1f26a1e40a47d85d24b42cd5475cd3b04f
[20:02] <sacarasc> Exact.
[20:02] <sacarasc> It's too old, update. \o/
[20:02] <Actium> that's not very old by distribution standards :)
[20:05] <Hfuy> I think this behaviour has been reasonably normal for some time
[20:06] <Hfuy> Does anyone know if mplayer supports the whole nvidia ion mp4 acceleration thing, and if so how to use it?
[20:07] <Actium> sorry, no clue about that windows stuff
[20:08] <Hfuy> It's just that my netbook is capable of playing 1080p24 h.264 in realtime under windows, but it has ubuntu at the moment.
[20:08] <Actium> vdpau
[20:08] <Mavrik> you need to make vdpau work
[20:09] <Hfuy> I just installed mplayer on it, and it did mention vdpau.
[20:09] <Hfuy> Perhaps there are other problems.
[20:10] <Mavrik> make sure you have nvidia drivers (not the noveau stuff) and vdpau libraries installed
[20:10] <sacarasc> Try mplayer -vc ffvdpauh264 -vo vdpau blah.mkv
[20:10] <Mavrik> then see if mplayer uses vdpau to play
[20:10] <sacarasc> If that doesn't work, then you can't. \o/
[20:11] <Hfuy> it's actually a lot better if I encode it as pix_fmt yuv420p
[20:12] <Mavrik> using anything else than YUV 4:2:0 won't be compatible with most HW decoders
[20:12] <Hfuy> that may be the difference, then
[20:13] <Hfuy> sacarasc's suggestion just gets me "cannot find codec matching selected -vo..."
[20:13] <Hfuy> Still a bit marginal, though
[20:14] <Actium> what's the benchmark say? VO still the bottleneck?
[20:15] <Hfuy> I'm running a benchmark right now, wait one.
[20:15] <Hfuy> This is a different laptop, y'understand.
[20:15] <Actium> now i do :)
[20:15] <Hfuy> this one's under ubuntu
[20:15] <Hfuy> which is probably a bit ambitious for a little atom netbook
[20:15] <Hfuy> ubuntu's showy GL UI may not be helping
[20:16] <Hfuy> 84% of time in VC. It's presumably the codec.
[20:16] <Actium> which is?
[20:17] <Hfuy> ffmpeg -i foo.avi -c:v libx264 -crf 22 -pix_fmt yuv420p bar.mp4
[20:17] <Hfuy> oh, and "-tune fastdecode"
[20:17] <Actium> what profile? baseline/main/high?
[20:17] <Hfuy> No idea.
[20:17] <Hfuy> Can I tell?
[20:18] <Actium> ffprobe
[20:18] Action: Hfuy sudo apt-get install libav-tools
[20:18] <Actium> wrong channel :P
[20:19] <Mavrik> yeah, not using ffmpeg will hurt our chances of helping :P
[20:19] Action: Actium gives Mavrik a high five
[20:20] <Hfuy> Video: h264 (High)
[20:21] Action: Hfuy adds -profile baseline
[20:21] <Mavrik> ugh
[20:21] <Mavrik> do main if you have 1080p content PLEASE :P
[20:21] <Actium> try -profile:v main
[20:22] <Mavrik> baseline downright murders any quality at a given bitrate :)
[20:22] <Hfuy> well, I've done baseline now
[20:22] <Hfuy> let's see how revolting it is
[20:22] <sacarasc> If you're reencoding anyway, why not resize?
[20:22] <Hfuy> I'm not reencoding, I'm encoding for the first time. Source is uncompressed AVI.
[20:23] <Hfuy> Looks OK to me.
[20:23] <Hfuy> OK problem solved moving on
[20:30] <Hfuy> Now the next problem is something you probably can't help me with. I'm driving three displays on the set of a movie.
[20:30] <Hfuy> And I've run out of laptops :)
[20:31] <Hfuy> Do you think people will still be using laptops in 2090?
[20:31] <Actium> i probably won't care due to being 6 feet under by then :)
[20:31] <Hfuy> Well that's a defeatist attitude!
[20:34] <Actium> even I'll have reached triple digit age by then
[20:35] <Actium> but 75 years is a long time for post-post-post-tablets to wipe out notebooks
[20:35] <Hfuy> Yeah
[20:36] <Hfuy> I just need a way of getting more video displays into this movie set.
[20:36] <Hfuy> I have two identical 24" TFTs. Could have got a third, but don't have another lappy to drive it with.
[20:37] <Hfuy> Annoying.
[23:38] <curfont> what decodes faster, a series of gzipped BMPs, or PNGs
[23:39] <curfont> or any alternative for lossless monochrome video?
[23:40] <sacarasc> Time for a test!
[23:40] Action: sacarasc goes off to not do it.
[23:43] <curfont> on another note.. h264 decoding is so slow :(
[23:44] <curfont> I can only decode my CCTV footage at 100FPS, so to analyse the footage for 24 hours it takes me 8 hours
[23:44] <sacarasc> Get a bigger, beefier CPU!
[23:45] <curfont> I have an i7, one of the latest ones
[23:45] <curfont> Does ffmpeg use the GPU?
[23:46] <curfont> Its strange because the decoding isnt using much cpu (13%)
[23:46] <sacarasc> What resolution is this video?
[23:48] <curfont> 1080p
[23:48] <curfont> Main at L4.1
[23:49] <sacarasc> You should be able to decode at >100FPS with a recent i7... Are you using all the threads?
[23:50] <curfont> Maybe not, I am not too sure on the parameters. Ideally I would like to use it in an app (as a library) instead of as an executable
[23:50] <curfont> But it wouldnt work multithreaded in that case right?
[23:58] <sacarasc> You should be able to do it multithreaded... 4 threads to decode the video, 4 to do whatever else you need...
[00:00] --- Sun Mar 23 2014