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

[burek]

[00:55] <alsu> how do I print the Lavf version ffmpeg is using?
[05:21] <kidx> I have a question how do i get the latest FFMPEG and also why does it say outdated on my Lubutu based distro and one last thing how can i screen cast and broadcast?
[05:24] <nownot> question on avconv, how would I convert flac to alac (mp4) ? I keep getting errors like "utomatic encoder selection failed for output stream #0:0. Default encoder for format ipod is probably disabled. Please choose an encoder manually."
[05:25] <kidx> I love ffmpeg just dont know why my distro has it outdated when a version was release this year?
[05:26] <kidx> I cant make youtube videos or broadcast with ffmpeg not working with oput bugs?
[05:26] <sacarasc> kidx: Get one of them ^
[05:27] <kidx> how do i install latest one
[05:27] <kidx> i want latest ffmpeg
[05:27] <sacarasc> Just get a static build and you won't need to build/install.
[05:27] <kidx> what is that a deb
[05:27] <sacarasc> nownot: avconv is not part of ffmpeg. Try #libav.
[05:27] <kidx> where i get that from
[05:28] <kidx> can i get a 2.0 static build?
[05:28] <nownot> sacarasc: oh, sorry. well, do you know the command I would use for ffmpeg? I'm pretty impartial as long as the job gets done
[05:29] <sacarasc> kidx: The second link is newer than 2.0...
[05:30] <kidx> how do i install this i am new here and love this but new?
[05:31] <kidx> I just wnat that stupid thing to goaway where it says please use libav I dont want to
[05:31] <sacarasc> Just unarchive it, then use ./ffmpeg in the directory you put the binary in.
[05:32] <kidx> oh
[05:33] <kidx> thanks you gusy are very helpfull unlike libav they have attitudes not supporting bash scripts and stuff question do you guys know how to capture the screen or broadcast or have a fourm i ca look for the topics in?
[05:34] <sacarasc> !forum
[05:34] <sacarasc> Bah.
[05:34] <sacarasc> The link is in the topic, anyway.
[05:36] <kidx> thansk alot guys my dad has used this all the time and now my turn hehe well thansk for every thing one thing before i go is .ffmpeg in the home folder or no casue i dont see it?
[05:37] <sacarasc> I don't think ffmpeg makes one.
[05:37] <kidx> so where is the directory of ffmpeg go once install i am on lubuntu
[05:38] <sacarasc> The static build shouldn't install.
[05:38] <sacarasc> It's just a binary you run when you want to.
[05:38] <kidx> oh ok
[05:38] <kidx> well this is confusing now casue i have ffmpeg installed on here and its saying please use avconv
[05:39] <kidx> and all i wanted to do was update that to latest
[05:39] <sacarasc> In the directory where you put the ffmpeg binary, run ./ffmpeg to run it.
[05:39] <kidx> let me try
[05:39] <sacarasc> If you want to install it, add that directory to your path BEFORE where ffmpeg is installed.
[05:40] <kidx> i am new here all i wanna do is make youtube videos with out lag.
[05:40] <sacarasc> And then it should find the static build before the avconv thing.
[05:40] <kidx> what you are saying is unarchive the latest to the place its inatalled on my HD
[05:41] <kidx> overright the existing one and voila
[05:42] <sacarasc> That would probably work, but could cause problems with your package manager. Put it somewhere like ~/bin/, then add $HOME/bin to the $PATH BEFORE the rest of it... (So it would looke like PATH=$HOME/bin:$PATH or similar.)
[05:43] <kidx> make a bin folder in my home folder and extract it there correct and cd to the driver and use./ffmpeg
[05:43] <kidx> sounds simple
[05:44] <nickeest> I can't seem to convert an mkv file to an avi.   It's an h264 and ac3 audio.  I get error: [mp2 @ 0x8331a90]encoding 6 channel(s) is not allowed in mp2
[05:45] <kidx> also i hope ffmpeg stays forever
[05:46] <sacarasc> nickeest: -ac 2
[05:46] <nickeest> sacarasc, can you give me the full command please, I am not so literate
[05:46] <sacarasc> nickeest: What command do you have so far?
[05:46] <kidx> nickeest add -ac 2 to your command you have i believe
[05:47] <nickeest> sacarasc, yep its working now
[05:47] <nickeest> kidx, thx
[05:47] <kidx> np
[05:47] <nickeest> sacarasc, thx
[05:47] <kidx> i am here to help as well as get help
[05:47] <kidx> this is why i love ffmpeg
[05:53] <kidx> question how do I do fullscreen broadcast with our the game going black?
[05:56] <kidx> also it is not grabing my screen
[05:56] <kidx> giving me errors and this avconv thing is ticking me off i am gona uninstall ffmpege
[06:04] <kidx> Unknown input format: 'x11grab'
[06:04] <kidx> thats the error i am getting on linux
[06:08] <nickeest> How do I estimate completion time? I see: frame=22601 fps=18 size=     84343kb time=958.34 bitrate=721.0kbits/s
[06:08] <sacarasc> I'm not sure the static builds are built with X stuff.
[06:09] <nickeest> oh oh, now it printing that line I mentioed on new lines and scrolling the page.
[06:10] <sacarasc> Make your terminal larger.
[06:10] <kidx> nickeest you jut tryign to screen cap
[06:10] <nickeest> sacarasc, it is, but when it would keep updating the same line, now it is printing new lines
[06:10] <kidx> want a full code for that
[06:11] <kidx> also this updates in lines
[06:11] <nickeest> kidx, what do you mean?  I have an mkv video, but my computer is slow, so I am converting it to avi so maybe it will play smooth
[06:11] <kidx> thats why you dedicate a terminal to it
[06:11] <kidx> why
[06:11] <nickeest> oh wait, it went back to just one line again
[06:12] <kidx> mkv opens with VLS
[06:12] <kidx> VLC
[06:12] <kidx> and is not slow
[06:12] <nickeest> kidx, I can open it and play it, but its slow, I have a really old computer
[06:12] <kidx> it depends on your sets
[06:12] <nickeest> its only 2ghz
[06:12] <kidx> me to
[06:12] <kidx> thats why i run LXLE
[06:12] <nickeest> and you can play it.  I have debian
[06:12] <nickeest> I am using xfce
[06:12] <kidx> only uing 2 cpu
[06:13] <kidx> 27/30 max on recording
[06:13] <nickeest> and you can play mkv 720p video?
[06:13] <kidx> nw lets try playing a game hehe
[06:13] <kidx> yup
[06:13] <nickeest> I am surprised
[06:13] <kidx> i use terminal
[06:13] <kidx> casue i am on LXLE
[06:13] <kidx> what distro you on
[06:13] <nickeest> ok, I can play it from terminal and try then
[06:13] <nickeest> debian
[06:13] <kidx> yuck
[06:14] <nickeest> kidx, and yourself?
[06:14] <kidx> its good but not that good if you want small and less pc usage use LXLE
[06:14] <kidx> by the way i have 2 2.0ghz
[06:14] <kidx> i have a server pc
[06:14] <nickeest> lxle or lxde?
[06:15] <nickeest> but the video is still on gonna play in one of the two cpu's
[06:15] <kidx> Lubuntu Xtended Life Edition
[06:15] <nickeest> I trust debian guys more than anyone else
[06:15] <kidx> runs greate for me here
[06:15] <kidx> i dont trust them casue lthey lack updates
[06:15] <kidx> I only trust them for a base
[06:16] <nickeest> they are slow, no doubt about that
[06:16] <kidx> as for my main os I would not reconmend them
[06:17] <nickeest> I am running old stable, but I gonna have to upgrade to stable if I want to use google chrome with flash, cause youtube videos are playing really slow in firefox 3.5
[06:17] <nickeest> Once I get youtube vids going fine, I am set, thats all I need, everything else is fine for me
[06:18] <kidx> back to the x11 grab thing
[06:18] <kidx> whay is x11 grab an error
[06:18] <nickeest> How long will it take me to convert this mkv video you'd guess that is 1gig in size to avi
[06:18] <kidx> a while
[06:18] <nickeest> hour?
[06:18] <kidx> almost not worth recording in mkv if your gona jsut convert
[06:19] <kidx> just record in avi
[06:19] <nickeest> its at 130mb now, since I started when you recall I asked for the -ac 2 command
[06:19] <nickeest> I downloaded the vid
[06:19] <kidx> ply it in VLC
[06:19] <nickeest> the avi will be larger or smaller than the original
[06:19] <kidx> no need to convert and openshot can open it as well as kdenlive
[06:19] <nickeest> kidx, I tried that first, it isn't smooth play, it isn't watchable
[06:20] <kidx> casue you prolly lagged when recording it
[06:20] <kidx> witch that is not gona fix your issue but wast time
[06:20] <nickeest> kidx, I downloaded it, I didn't record it myself
[06:20] <kidx> then the vid is junk
[06:20] <kidx> not your pc
[06:21] <kidx> if it plays like junk then its prolly junk
[06:21] <nickeest> but on my old computer which was much faster, these same vids played well
[06:21] <kidx> link me to thsi vid
[06:21] <kidx> i wanna test it
[06:21] <nickeest> kids criten network, elitewarez
[06:21] <kidx> oh
[06:22] <kidx> i dont bother with them
[06:22] <kidx> all i can say is run it on somthing else
[06:22] <kidx> or upgrade
[06:23] <nickeest> yeah, I am gonna wait, and in the meantime find a cheaper version
[06:23] <nickeest> I am also gonna upgrade to wheezy, but I'd they didn't include compiz on wheezy.  Do you use compiz?
[06:24] <kidx> no
[06:24] <kidx> i just game
[06:24] <kidx> and make youtube vids
[06:24] <kidx> but seems like all the distros are junk except LXLE
[06:26] <nickeest> you play games on lxle, I though you need windows for games, I thought linux wasn't good for gaming
[06:27] <kidx> it is
[06:27] <kidx> people lie
[06:27] <kidx> steam on linux naitive
[06:27] <kidx> no need for windows
[06:27] <nickeest> steam?
[06:29] <kidx> yes
[06:29] <kidx> i am getting alot of errors
[06:29] <kidx> wow
[06:30] <kidx> ffmpeg -f x11grab -r 25 -s 1280x1024 -i :0.0+100,200 -f alsa -ac 2 -i pulse -vcodec libx264 -crf 0 -preset fast -acodec pcm_s16le output.mkv
[06:30] <kidx> thats my code but no cast is working
[06:30] <kidx> cant grab x11
[06:31] <kidx> also shared memory found x error failed request?
[06:34] <kidx> could it be this --enable-indev=x11_grab_device and if show how do i enable that so i can use x11grab
[06:41] <kidx> well i am outthanks for everything guys
[08:32] <dedeeer_> http://paste.ubuntu.com/5924298/
[08:33] <dedeeer_> whats wrong
[08:38] <JEEB> I can see a report for an older ffmpeg version and GCC 4.8.1
[08:39] <johnny22> whats the best way to syncronize audio and video from a live audio source and from a live video source with the ffmpeg libs ?
[08:39] <JEEB> https://trac.ffmpeg.org/ticket/2756
[08:39] <JEEB> that was fixed by updating ffmpeg
[08:40] <dedeeer_> to me ?
[08:40] <JEEB> yes
[08:41] <dedeeer_> I just complie the xbmc android  builds its refer to ffmpeg builds
[08:42] <JEEB> yes, xbmc internally contains some random version of ffmpeg :)
[08:42] <JEEB> I tried looking through dca-related commits but I couldn't really notice anything that would clearly fix your problem http://git.videolan.org/?p=ffmpeg.git&a=search&h=HEAD&st=commit&s=dca
[08:43] <JEEB> one way or another that problem has been already fixed, but I have no idea which commit did it :P
[08:43] <dedeeer_> you mean i should to update the ffmpeg modules for xbmc builds
[08:43] <dedeeer_> ou mean i should  update the ffmpeg modules for xbmc builds 
[08:51] <dedeeer_> does ffmpeg is optimized x264 on NEON ?
[09:05] <JEEB> dedeeer_, I mean that one way or another the ffmpeg you're building should be updated, or you downgrade your toolchain :D I just checked http://git.videolan.org/?p=ffmpeg.git;a=shortlog;h=refs/heads/release/1.2 and I don't see any related fixes in there after the 1.2.0 release. so welp
[09:05] <JEEB> that is, if you are using the 1.2 release branch :P
[09:06] <JEEB> (which is what that error was reported with)
[10:20] <nlight> I want to build ffmpeg for windows using visual studio 2013
[10:20] <nlight> any tips?
[10:20] <JEEB> expect breakage? :D
[10:21] <JEEB> anyways, I don't think all of those features noted at BUILD are yet in, so you will most probably have to wait until RTM for "pure" compilation
[10:21] <JEEB> so I guess follow the usual steps?
[10:21] <nlight> ok, scratch that then
[10:22] <nlight> I'll build it with mingw
[10:22] <JEEB> :)
[10:22] <JEEB> yes, c99wrap is not exactly fast
[10:22] <JEEB> anyways, this is the usual way http://ffmpeg.org/platform.html#Microsoft-Visual-C_002b_002b-or-Intel-C_002b_002b-Compiler-for-Windows
[10:23] <JEEB> this way you can get MSVC debug symbols and all, but unfortunately c99wrap is needed
[10:23] <nlight> is it worth to do this if I can use mingw?
[10:24] <JEEB> if mingw isn't any worse for you use case (see: debug symbols not needed to be usable from MSVS), then mingw-w64 generally is less of a hassle
[10:25] <nlight> is this guide up to date - https://trac.ffmpeg.org/wiki/MingwCompilationGuide ?
[10:25] <xlinkz0> why would you compile it yourself for windows?
[10:26] <JEEB> lol, that compilation guide really tries to add everything, and only notes mingw (the original project), while nowadays mingw-w64 is definitely the better choice
[10:26] <JEEB> xlinkz0, why would you not?
[10:27] <xlinkz0> because zeranoe
[10:27] <JEEB> because zeranoe only gives GPLv3 compiles?
[10:27] <JEEB> there are plenty of reasons for various people to compile their own thing
[10:27] <JEEB> and nothing bad or weird in that
[10:27] <xlinkz0> just asking
[10:28] <JEEB> also I guess fdk-aac is one of the main reasons to build yourself otherwise
[10:28] <JEEB> since it can't be distro'd
[10:28] <JEEB> (in binary form)
[10:28] <xlinkz0> didn't say it was bad, i genuinely was curious why would someone do that :)
[10:28] <JEEB> or a limited build for a specific purpose? there's plenty of reasons
[11:07] <Pet0r> Is there any way to force ffmpeg to obey a maximum bitrate even when -crf is set?
[11:08] <Pet0r> For x264 I am using crf 18 which is proving great for 99% of videos, but on some videos with a high input bitrate (10MBit/s+) it's overshooting on bitrate hugely and I would prefer it to cap out at the bitrate rather than try to maintain crf 18
[11:08] <JEEB> If you mean the equivalent of -b:v, no. You can limit bandwidth within a buffer with -bufsize and -maxrate, though.
[11:10] <Pet0r> I currently have -b:v 3M and -maxrate 3M, and it overshoots to ~7.5MBit/s bitrate
[11:10] <Pet0r> on average
[11:10] <JEEB> 1) you didn't set bufsize 2) -b:v is over the whole clip
[11:11] <JEEB> also if you want one-pass encoding -crf + VBV (bufsize + maxrate) is IMHO better than setting a bit rate and VBV
[11:12] <Pet0r> am I right in thinking bufsize is what it buffers in order to make a better decision about the upcoming video?
[11:12] <Pet0r> or am I totally wrong there
[11:13] <Pet0r> not sure what it does
[11:13] <JEEB> bufsize is the amount of buffer within which the maxrate is calculated
[11:13] <JEEB> in theory if you are not streaming over limited bandwidth and just want to limit the overall file size you could set this rather large
[11:13] <Pet0r> I need to assume bandwidth is limited
[11:13] <JEEB> well then you should always be using VBV :P
[11:13] <Pet0r> The overall file size cannot exceed duration * 3mbps
[11:13] <JEEB> pronto
[11:14] <JEEB> eh
[11:14] Action: JEEB sighs
[11:15] <JEEB> anyways, it's the amount of buffer within which the maxrate is calculated and kept within limits (and if x264 cannot do that it will scream at you loudly, although that really doesn't happen much nowadays with all the emergency modes etc. in place)
[11:15] <JEEB> aka the amount which the player has to buffer when starting the playback to make sure that it never has to buffer again as long as it has maxrate amount of bandwidth
[11:15] <Pet0r> So is there a good way to calculate a decent value for that?
[11:15] <Pet0r> ah
[11:15] <JEEB> a decent value is something you decide, and then match up on the encoder and the player :P
[11:16] <Pet0r> So is that value in bit/s or byte/s?
[11:16] <JEEB> ffmpeg's is bits/s
[11:16] <JEEB> and bits
[11:16] <Pet0r> oh
[11:16] <Pet0r> *ok
[11:17] <JEEB> it will then divide by eight when passing it to the x264 API
[11:17] <JEEB> ah, no
[11:17] <JEEB> it will divide by 1000
[11:17] <JEEB> because x264 takes kilobits
[11:17] <Pet0r> thing is, will this negatively affect other videos which do not require the whole bitrate?
[11:17] <Pet0r> because right now
[11:17] <Pet0r> if I encode a video way under 3mbps with these settings
[11:18] <Pet0r> the bitrate will come out below 3mbps
[11:18] <Pet0r> which is what I want
[11:18] <JEEB> it will affect all videos that you encode, to make sure that nothing goes over maxrate calculated over a bufsize buffer
[11:18] <JEEB> it will not make anything use more bits
[11:19] <JEEB> also if you have encoded without maxrate + bufsize before you have pretty much failed as a VOD provider unless you expected your users to buffer a lot :P
[11:19] <Pet0r> So I guess my question is then, what is the point of bufsize? If I set a max bitrate, why isn't that just obeyed over the whole video? and if I do set a bufsize, why does that make any difference since isn't it always limited to that?
[11:20] <Pet0r> I feel like I am fundamentally misunderstanding bufsize and I do want to understand it :P
[11:20] <JEEB> normal rate control controls the bit rate over the whole clip, bufsize controls rate control within a constantly moving buffer so that at all points if you have buffered bufsize amount of video and have at least maxrate amount of bandwidth, you will never have to buffer again
[11:21] <Pet0r> okay, I see
[11:21] <Pet0r> so what you're saying is, in the video player, you tell it to download a certain amount of the video (bufsize), as opposed to a duration of the video, before it starts playing
[11:21] <Pet0r> at which point as long as the bandwidth remains available, the video should always play
[11:22] <JEEB> I don't understand the "as opposed to a duration of the video" part, but yes -- it will make sure that if those parameters are true, then the viewer will have a smooth playback experience
[11:23] <JEEB> you just match up the player with the encoder with regards to how much bufsize you used, and encode accordingly
[11:24] <JEEB> in theory if you encoded with just bit rate rate control, if the beginning of a clip is very very bandwidth needing, you could end up exhausting all of your bits there (esp. if the stuff after that needs only nominal bit rate)
[11:24] <JEEB> thus if you are giving out video over a limited bandwidth, you *need* VBV
[11:25] <JEEB> the beginning in that case will look worse, but it will be within the VBV limits
[11:25] <Pet0r> I see, so would setting bufsize quite low force the video to always obey maxrate as well?
[11:25] <Pet0r> like I don't know, if you set it to something stupidly low like 100k
[11:25] <JEEB> huh?
[11:25] <Pet0r> what would happen?
[11:25] <JEEB> it would just make it very hard for the encoder to fluctuate anything
[11:26] <JEEB> it would be a very small buffer in that case
[11:26] <JEEB> usually such are only used in low-latency things where you can't buffer much
[11:27] <JEEB> in your case I would at the very least recommend having a maxrate amount of bufsize, possibly more
[11:27] <Pet0r> well, the problem for me is not just the buffering, the reason I was asking originally about the maxrate etc. is that I have a file size constraint
[11:27] <Pet0r> now I know 2 pass is usually best for that
[11:27] <JEEB> well, maxrate + bufsize is even more limiting than that :P
[11:28] <Pet0r> but the problem with 2 pass is that it seems to do the opposite of what it does now, it perfectly makes this 10mbps video 3mbps for the duration
[11:28] <Pet0r> but it then upscales smaller videos to a higher bitrate than necessary
[11:28] <Pet0r> well, I use "upscales" wrongly, it doesn't upscale
[11:28] <Pet0r> but you know what I mean
[11:28] <JEEB> yes, because you've asked for X, you got X
[11:28] <Pet0r> yeah, is there a way to say, like
[11:28] <Pet0r> don't exceed the input bitrate
[11:29] <Pet0r> short of looking that up in advance and passing it in
[11:29] <JEEB> the input bit rate is irrelevant as soon as you start re-encoding
[11:29] <JEEB> forget about the input bit rate, basically
[11:29] <JEEB> if you have a limitation on the output, that is a limitation on the output
[11:30] <Pet0r> a lot of the videos we get are passed in containers which have crappy codecs, like FLV
[11:30] <Pet0r> so we can usually rely on being able to produce a smaller output with comparable quality
[11:30] <JEEB> anyways, maxrate + bufsize will keep the average bitrate under something because it even has a smaller buffer within which it limits the clip :P
[11:30] <Pet0r> so input bitrate is sometimes useful
[11:30] <Pet0r> ok
[11:30] <Pet0r> so a maxrate of 3M with a buffer size of say... 1M?
[11:30] <JEEB> ugh
[11:31] <JEEB> use AT LEAST maxrate amount of bufsize
[11:31] <JEEB> I mean, you would be OK with a bufsize of the whole damn clip, if you were using -b:v without VBV before, which is of course completely incorrect for any kind of limited bandwidth video provision
[11:32] <Pet0r> well, I didn't write any of the previous stuff, I am trying to improve it
[11:33] <JEEB> I would say even 2-3 "seconds" worth of buffer would be usable
[11:33] <JEEB> if not even more
[11:33] <JEEB> maxrate * 2 or 3 that is
[11:33] <JEEB> then set the player to buffer the same amount, and enjoy
[11:35] <Pet0r> what about -bt, does that have any effect as well?
[11:35] <Pet0r> or not worth using?
[11:35] <JEEB> what is bt in ffmpeg again? I'm more knowledge'able in x264 settings than ffmpeg's
[11:35] <Pet0r> bitrate threshold, apparently
[11:35] <JEEB> keep away from all that stuff
[11:35] <JEEB> x264's defaults are GOOD
[11:36] <JEEB> all you should in general be touching are: preset (defaults, speed vs compression), some kind of rate control mode (bitrate or CRF), VBV (maxrate and bufsize)
[11:37] <Pet0r> okay so with a bufsize set, the output video bitrate (average) is much lower
[11:37] <Pet0r> but it's actually way under 3mbps even
[11:37] <Pet0r> (I set bufsize = maxrate = 3M)
[11:38] <Pet0r> average bitrate with those settings is 1600kbps
[11:38] <JEEB> if the crf is so that it always ends up using the maximum amount of buffer then it will be pretty much 3M in the end, otherwise it will just be smaller
[11:38] <JEEB> because VBV only limits
[11:39] <JEEB> and the larger the bufsize the more playing ground the encoder will have
[11:39] <Pet0r> one sec
[11:40] <Pet0r> so with identical settings (crf 18, b:v 3M, maxrate 3M)... bufsize: 3M = 1600kbps avg, no bufsize = 3750kbps
[11:41] <JEEB> because maxrate does nothing without a bufsize
[11:41] <JEEB> maxrate is only applied with a bufsize
[11:42] <Pet0r> but why is bufsize 3M producing such a low bitrate encode? surely if you can buffer 3M the average bitrate could be much higher than 1600K
[11:43] <JEEB> basically some part would have taken more bit rate, but it was limited, and CRF didn't need as much rate in other places so it kept the average down
[11:44] <JEEB> and if you keep making bufsize bigger the encoder will be able to fluctuate more
[11:44] <JEEB> thus getting closer and closer to that unlimited result
[11:45] <Pet0r> presumably it's not a good idea to have a static bufsize for every input video though?
[11:45] <JEEB> why not?
[11:45] <Pet0r> ok
[11:46] <JEEB> you have the certain maximum bit rate, and a bufsize for it
[11:46] <Pet0r> well, I guess, yeah, it would be alright
[11:46] <Pet0r> I was thinking if you had a really low quality input video that ended up with a low bitrate output, it would have to buffer a lot more of the video
[11:46] <Pet0r> and of course, it would
[11:46] <Pet0r> but it would take the same time to do so
[11:46] <JEEB> that's why I kept telling you that at the very least you should use at least a 1sec bufsize
[11:46] <Pet0r> in the player, I mean
[11:47] <JEEB> not related to your last lines
[11:47] <JEEB> but you basically have a case where you can have the user wait a couple of seconds at the beginning
[11:47] <JEEB> and then just keep to the maxrate under that buffer
[11:50] <Pet0r> okay
[11:51] <Pet0r> that's been very helpful, thanks
[11:51] <Pet0r> I now understand what those settings mean and how they work
[11:51] <JEEB> I'm still surprised that people who actually get paid know less of this than I do :P
[11:51] <Pet0r> I didn't get hired specifically to do this :P
[11:52] <Pet0r> I'm a software engineer
[11:52] <Pet0r> lol
[11:53] <JEEB> and I'm a random coder
[11:54] <JEEB> also, just so that there are no misunderstandings, <JEEB> and then just keep to the maxrate under that buffer <- this doesn't mean that the maxrate always has to be under the bufsize (that is needed in low-latency cases over limited bandwidth), it was written as "within the buffer"
[11:54] <JEEB> *that
[11:56] <Pet0r> I see
[11:59] <Keshl> Before I make a dumb mistake while we're on the topic of bufsize.. I have a video that has a lot of repeating frames over the course of 5-10 seconds, and it's running at 120 FPS. If I increase the bufsize to some rediciously large amount will it actually pick up those repeating frames and offer better compression than it does now, oÉo?
[12:00] <JEEB> bufsize is not that kind of buffer
[12:00] <JEEB> that's a job for rc-lookahead and amount of refs/bframes
[12:00] <Keshl> Okay, good thing I asked first ^É^; What should I be doing them, oÉo?
[12:00] <Keshl> But rc-lookahead is limited to 250.
[12:00] <JEEB> yes
[12:00] <Keshl> At 120 frames per second, 250's.. Very inadiquite. XD
[12:01] <JEEB> well, it should capture enough pictures being the same, just keep keyframe interval long
[12:01] <Keshl> How do I do that exactly, oÉo? I'm not terribly familier with ffmpeg's magical commands. xwx
[12:02] <JEEB> -g?
[12:03] <Keshl> I have this feeling that I won't get it right. o_o Does -g 1200 sound reasonable if I want it to have around 10 seconds of lookahead/behind?
[12:04] <JEEB> that will mean that the maximum interval between keyframes that also cut the pictures future pictures can reference off of will be 1200
[12:04] <JEEB> for 120fps content that would be 10 seconds, yes
[12:04] <Keshl> Awesome, oÉo.
[12:07] <Keshl> oÉo Is -g all I need?
[12:08] <JEEB> and naturally a preset that lets you use enough refs/bframes
[12:08] <Keshl> Like medium? Or OH.
[12:08] <Keshl> ... -Facedesk-
[12:08] <Keshl> Kay, yeah, now I see my mistake, thanks.
[12:10] <Pet0r> ok yeah that seems to be working well, even with a bufrate = maxrate, the average bitrate is half maxrate, but I see it spiking as high as 133% of the maxrate during actual playback
[12:15] <Keshl> JEEB: How do I do -no-scenecut of -keyint? http://mewiki.project357.com/wiki/X264_Settings seems outdated, and the video in question has no scenecuts.
[12:16] <Keshl> *or
[12:16] <JEEB> -g = keyint
[12:16] <Keshl> Ohhhh.. oÉo..
[12:17] <Keshl> .... And how do I set -bframes and -b-adapt? x.x
[12:24] <microchip_> Keshl: https://sites.google.com/site/linuxencoding/x264-ffmpeg-mapping
[12:25] <Keshl> Dankye, oÉo
[12:30] <Keshl> ... Motion estimation depends on color, doesn't it? So if I only have two colors, black (the background) and orange (And I don't mean different shades, I mean two colors, /period/), motion estimation becomes next to impossible and results in inordinately large files? xwx
[12:35] <ubitux> BBB: i really don't know what is the timeline and workload required for each thing; as long as i learn about video codecs i'm happy with anything
[12:49] <saste> ubitux, wrong ML
[12:49] <saste> bah wrong channel...
[12:50] <ubitux> oups
[12:51] <ubitux> thx
[13:01] <nlight> I'm trying to compile using mingw and I get the following error during compilation "libavutil/atomic.c:101:2: error: #error "Threading is enabled, but there is no implementation of atomic operations available"
[13:02] <nlight> any ideas?
[13:02] <nlight> I have explicitly passed --enable-w32threads
[13:03] <nlight> here is my whole configure statement $ ./configure --prefix=/mingw --enable-gpl --enable-nonfree --enable-postproc --enable-avfilter --enable-w32threads --enable-runtime-cpudetect --enable-memali
[13:03] <nlight> gn-hack --enable-zlib --enable-libx264 --enable-libxvid --enable-static --disab
[13:03] <nlight> le-shared --disable-debug
[13:03] <nlight> sorry for the spam :|
[13:04] <spaam> nlight: :(
[13:05] <Pet0r> http://trac.ffmpeg.org/ticket/2363
[13:05] <Pet0r> did you try that?
[13:05] <nlight> I could do that, but I wanted native threads, well..
[13:06] <Pet0r> you can have native threads
[13:06] <Pet0r> if you specify a --cpu val
[13:07] <nlight> it compiles with --enable-pthreads, that's ok for now I guess
[13:07] <nlight> thanks
[13:07] <Pet0r> look at comment 3
[13:07] <Pet0r> if you want native threads
[13:08] <JEEB> uhh
[13:08] <JEEB> native threads should work out-of-box
[13:09] <nlight> I guess I should switch to mingw64
[13:09] <JEEB> also disable-shared is the default
[13:09] <JEEB> yes, yes you should
[13:09] <JEEB> http://files.1f0.de/mingw/
[13:09] <JEEB> grab one of those and switch your /mingw
[13:09] <nlight> will do, thanks
[13:11] <JEEB> also runtime-cpudetect is default now too
[13:11] <JEEB> memalign hack is only needed for mingw32
[13:11] <JEEB> not mingw-w64
[13:12] <JEEB> zlib is enabled by default if found
[13:12] <JEEB> (is visible in configure's output)
[13:12] <JEEB> also you haven't enabled anything nonfree
[13:13] <JEEB> generally I'd say you only need possibly prefix, enable-gpl, enable-libx264, enable libxvid
[13:13] <nlight> ok
[13:13] <JEEB> also as a hint for msys
[13:13] <nlight> it's the first time I'm building ffmpeg so any tips are super welcome
[13:13] <JEEB> you can switch between mingws with etc/fstab
[13:13] <JEEB> first tip: start with pure ./configure first
[13:13] <JEEB> then look if it passes
[13:14] <JEEB> after that enable those external things you need, and possibly some internal ones
[13:14] <JEEB> enable-gpl is pretty much the only thing that enables something inside ffmpeg itself
[13:14] <JEEB> everything else is just for third party libraries
[13:15] <nlight> aha, so --enable-nonfree does nothing by itself?
[13:15] <JEEB> yes
[13:18] <JEEB> also, funny enough pretty much the only thing that prefers pthreads to native threads for whatever reason in its configure is x264
[13:18] <JEEB> and I think that one is a mistake
[13:18] <Fjorgynn> I am
[13:19] <JEEB> basically x264's configure first tries native threads, and then if it finds pthreads and they are usable it will switch to that
[13:19] <JEEB> so there you will have to specify the native threads
[13:19] <JEEB> ffmpeg and friends default to native threads
[13:22] <nlight> isn't there some python script that automatically downloads and builds everything?
[13:22] <nlight> like ffmpeg + xvid + x264 + aac + lame
[13:22] <nlight> or something
[13:22] <JEEB> you could create one rather easily, or a shell script
[13:22] <nlight> that's what I'm currently doing
[13:23] <nlight> I wish one was already available but meh
[13:27] <Pet0r> there are windows builds released very often @ zeranoe.com
[13:27] <nlight> do they include xvid + x264?
[13:27] <Pet0r> yes
[13:27] <Pet0r> http://ffmpeg.zeranoe.com/builds/
[13:28] <nlight> oh, figures
[13:28] <nlight> I should just use those then
[13:28] <nlight> thanks
[13:30] <Fjorgynn> :)
[13:32] <nlight> I'm still setting up my own ffmpeg build but these will do the trick for testing
[13:33] <Pet0r> fair enough :P
[13:33] <nlight> is there a 'static library' version?
[13:34] <nlight> i'm not sure if it's good practice to link ffmpeg statically
[13:36] <JEEB> if you are following the license there's no real problem with static linking. it's a bit funky with mingw-w64 tho :)
[13:37] <elkng> I use command: "ffmpeg ../1.avi -c:v png "%3d.png""  to make video into set of png images, but they are too dark, when I watch video I can increase bringtness with some key, but how to make those images brighter while converting using that command ?
[13:37] <JEEB> (although it's only funky when you are linking the static lib from MSVC, if you are using mingw64 all-around then there's no problem)
[13:38] <nlight> JEEB, funky in what way?
[13:38] <nlight> as in "don't do this unless you're damn sure you need it"?
[13:39] <JEEB> when you link a static mingw-w64 lib from MSVC there are some functions that aren't found, and thus you need to define that one or those two somewhere as a workaround in your MSVS code
[13:39] <elkng>  should I use "-vf mp=eq2=1.0:2:0.5" ?
[13:39] <Pet0r> why not give it a try?
[13:39] <Pet0r> :P
[13:39] <JEEB> officially it's not really supposed to be used, but it's found to be rather usable because people have been doing it for years :P
[13:39] <Pet0r> just limit your video to a time when you know it's dark
[13:39] <JEEB> dll is preferable of course
[13:39] <Pet0r> and see how they come out
[13:40] <JEEB> since dll is less :effort:
[13:47] <elkng> Pet0r: I mean there is also lutrgb='r=1.1*val:g=1.1*val:b=1.1*val' or lutyuv=y=val*1.1
[13:47] <Pet0r> there are multiple ways to do it with different filters
[13:47] <Pet0r> give it a try and just use a slice of your video where you know it's dark
[13:47] <Pet0r> like if you know it's dark in 30-35 seconds then use -ss 00:30:35 -t 00:00:05
[13:47] <Pet0r> so just cut that section of video
[13:48] <Pet0r> and see if they come out dark or not
[13:48] <Pet0r> * -ss 00:00:30
[13:48] <Pet0r> lol
[17:07] <hackeron> hey, any ideas what is wrong with this command? < "ffmpeg -rtsp_transport tcp -i 'rtsp://192.168.55.3/media/video1' -analyzeduration 0 -map 0 -dn -codec:v copy -f alsa -ac 2 -i hw:0,0 -codec:a libfdk_aac -flags +qscale -global_quality 1 -afterburner 1 -reset_timestamps 1 -ar 44100 -y video.mkv" -- I'm getting Option map (set input stream mapping) cannot be applied to input file hw:0,0
[17:09] <hackeron> durandal_1707: http://pastie.org/8186961
[17:10] <sacarasc> hackeron: You have input and output options mixed up.
[17:11] <hackeron> sacarasc: do I move the -f alsa -i hw:0,0 straight after the -i 'rtsp://..."?
[17:11] <sacarasc> Yes.
[17:12] <hackeron> sacarasc: then I get this: http://pastie.org/8186968 - no audio in output file :(
[17:23] <Fjorgynn> I disagree
[19:56] <t4nk795> hi, I have been trying to find the correct command to overlay two png images and keep the alpha channel, but the second image always loses it and has a black background instead, can anyone help me? This is the command line I've been using ffmpeg.exe -f image2 -i image000.png -vf "[in] scale=iw:ih, pad=2*iw:ih [left]; movie=image000.png, scale=iw:ih [right]; [left][right] overlay=main_w/2:0 [out]" -vcodec png  Output.png
[20:03] <relaxed> t4nk795: first make sure you're using a recent version of ffmpeg, then look at -filter_complex
[20:08] <t4nk795> thanks!
[21:50] <griddy> Hi guys, i get the following error when sending a video stream fom ffmpeg to ffserver: "av_interleaved_write_frame(): Connection reset by peer". Any tips?
[21:51] <griddy> *from
[21:52] <Fjorgynn> Sit Now :)
[21:52] <griddy> ok sitting:P
[21:55] <griddy> Hi guys, i get the following error when sending a video stream from ffmpeg to ffserver: "av_interleaved_write_frame(): Connection reset by peer". Any tips?
[23:42] <alexschomb> hello there :)
[23:43] <alexschomb> I'm trying to compile FFMPEG via cross-compiling for Raspbian following the wiki entry: http://trac.ffmpeg.org/wiki/How%20to%20compile%20FFmpeg%20for%20Raspberry%20Pi%20(Raspbian)
[23:44] <alexschomb> In the last step FFMPEG is not being compiled because "libx264 not found". I suppose this happens because there is no libx264.so created in /my/path/were/i/keep/built/arm/stuff/lib/
[23:45] <alexschomb> (I change the path to my own one of course)
[23:46] <alexschomb> I'd love some advice, already tried building with --enable-static, not helping.
[23:50] <llogan> alexschomb: try adding --extra-libs=-ldl to ffmpeg configure
[23:50] <llogan> those non CamelCase urls are annoying
[23:51] <alexschomb> llogan: thanks that helped! :)
[23:51] <llogan> i'll update that page then
[23:52] <alexschomb> it configured although i got an potential error about pkg-config not found
[23:53] <alexschomb> thank you very much :)
[23:54] <llogan> alexschomb: what's the exact error? (if it is long use pastebin.com)
[23:54] <alexschomb> i guess i found another small error. you'd need to make && make install in the step "Compiling ALSA library" too
[23:55] <llogan> ok, thanks.
[23:56] <alexschomb> llogan: http://pastebin.com/HdjzWV8w/
[23:59] <llogan> ah, i see it already mentions PKG_CONFIG_PATH, but it could probably be moved.
[00:00] --- Tue Jul 30 2013