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

[burek]

[00:41] <mark4o> kirbir: overlay a png that is black with a transparent circle in the middle where you want to see the video
[00:43] <kirbir> mark4o: Thank you very much!
[01:14] <DeadSix27> when you're skipping and it doesnt skip to exactly the position you actually wanted it to go to
[01:14] <DeadSix27> thats done by keyframes right?
[02:31] <DeadSix27> does that mean, what i believe it means: x264 [error]: malloc of size 30690048 failed
[02:37] <DeadSix27> (apparently it does mean what i thought it means, kinda still used 32bit ffmpeg. 64bit one works fine now.)
[12:14] <DeadSix27> what the heck is this: https://code.google.com/p/x265/downloads/detail?name=ffmpeg-patched.rar&can=2&q=
[12:20] <spaam> ffmpeg-patched.rar
[12:21] <spaam> everyone want to use x26N name!
[12:21] <DeadSix27> 4khd is a pain for my setup
[12:22] <DeadSix27> encoding wise
[12:22] <DeadSix27> 1,7fps
[12:23] <DeadSix27> look at the time (30s of 5m) gives me headache
[12:23] <DeadSix27> looking*
[12:29] <JEEBsv_> DeadSix27: that's a project started by a guy who had a couple of commits in 2004 in x264, and he seems to be working for MCW now
[12:29] <JEEBsv_> at MCW they have the 'real' x265 project
[12:29] <JEEBsv_> https://bitbucket.org/multicoreware/x265/wiki/Home
[12:30] <JEEBsv_> also if you look at the part "compatible with HM X.x" you should see that you should not use any time with that thing ;)
[12:30] <JEEBsv_> because only since HM 10.1 the streams that would be output would be compliant to the final specification :)
[12:31] <JEEBsv_> thanks to smarter there also is a decoder for HEVC/H.265 in libavcodec already
[12:41] <DeadSix27> ah
[12:41] <DeadSix27> thanks for the info
[12:42] <JEEBsv_> also x265 doesn't really have much to do with x264 :)
[12:42] <JEEBsv_> it's basically HM's encoder and MCW got the rights to the name and the right to use the double-licensed code from x264
[12:42] <DeadSix27> ye just wondered
[12:43] <DeadSix27> i googled info about x265 and ffmpeg
[12:43] <DeadSix27> and that came up
[12:43] <DeadSix27> main reason was, that ffmpeg has no 8k hd support
[12:43] <DeadSix27> i mean x264*
[12:43] <JEEBsv_> why not?
[12:44] <DeadSix27> i tried, gave me errors
[12:44] <JEEBsv_> the only thing you might hit is the 32bit memory limit with the defaults methinks?
[12:44] <DeadSix27> nope got 64
[12:44] <JEEBsv_> can you post what exactly you got?
[12:44] <DeadSix27> sec.
[12:44] <JEEBsv_> because x264 at least should not have a problem
[12:44] <JEEBsv_> pastebin, please :)
[12:44] <JEEBsv_> not onto the channel itself, since logs tend to be longer :)
[12:44] <DeadSix27> yep i know
[12:47] <dannyzb> I convert videos for online streaming , and I want to create high-quality while using reasonable CPU .. my current conversion is :
[12:47] <dannyzb>  /usr/bin/ffmpeg -i $source_path -x264opts bitrate=1280:vbv-maxrate=1280:vbv-bufsize=640 -s 1280x720 -refs 4 -vcodec x264 -acodec libfdk_aac -ab 164k
[12:48] <dannyzb> what would be the equivalent in crf value ?
[12:48] <dannyzb> btw I use the veryfast preset
[12:48] <JEEBsv_> there's no 'equivalent', basically the idea with crf is that you select the highest value that still looks good for you. Start with 23
[12:49] <JEEBsv_> and then go higher if it looks good
[12:49] <JEEBsv_> lower if it looks bad
[12:49] <JEEBsv_> also are you sure of those vbv values?
[12:49] <JEEBsv_> you have 0.5 seconds of buffering there
[12:49] <dannyzb> should i increase it? I don't even know what it means
[12:49] <DeadSix27> JEEBsv_: can't reproduce what i did last night
[12:49] <JEEBsv_> dannyzb: ugh
[12:49] <DeadSix27> JEEBsv_: gives me malloc erros today
[12:50] <DeadSix27> JEEBsv_: in which unit does x264 show those errors?
[12:50] <dannyzb> I want to reach a similar bitrate , but a bit higher for action and lower for animation , which i thing crf would do
[12:50] <dannyzb> JEEBsv_ : it works and it works well , it's well tested for conversion
[12:50] <dannyzb> just uses too high quality for animation and it's not good enough for high-pace action
[12:51] <JEEBsv_> dannyzb: basically -- you set maxrate for the minimum transfer speed that you want to support, and bufsize is then how much the player-side should buffer
[12:51] <JEEBsv_> if you want to think of the buffering in seconds, you set bufsize to maxrate times seconds
[12:51] <JEEBsv_> what you've set right now is *very* limiting
[12:51] <dannyzb> limiting in what sense?
[12:51] <DeadSix27> JEEBsv_: thats close to what i did yesterday: http://pastie.org/private/xlqiqaiicijpw3rtylglq
[12:52] <dannyzb> anyway , i would rather use CRF instead of bitrate/maxrate .. due to the problems i noted
[12:52] <JEEBsv_> ...
[12:52] <JEEBsv_> you should _always_ use VBV if you are operating through a limited pipe
[12:52] <JEEBsv_> ALWAYS
[12:52] <JEEBsv_> you're just limiting it bad
[12:53] <JEEBsv_> and yes, VBV can be used together with CRF
[12:53] <dannyzb> man don't be rude .. i'm asking a question
[12:53] <dannyzb> if I knew I wouldn't need help
[12:53] <JEEBsv_> I'm not being rude, I'm trying to teach you :)
[12:54] <relaxed> dannyzb: write a bash script to create a series of samples using a crf range and see what works best:  for -i in {16..22}; do ffmpeg -i input -t 20 -crf "$i" output_crf_"$i".mkv; done
[12:54] <relaxed> of course, add your other libx264 options
[12:54] <dannyzb> "Depends on the profile level of the video being encoded. Set only if you're encoding for a hardware device." thats the documentation for vbv-bufsize
[12:55] <JEEBsv_> ffmpeg -i hurrdurr.input -crf 23 -maxrate <minimum transfer rate you want to support>k -bufsize <maxrate * seconds of buffer>k -vf scale=1280:720 -c:v libx264 -c:a libfdk_aac -b:a 192k out.file
[12:55] <relaxed> listen to the JEEBsv_
[12:55] <relaxed> er, the should be "for i", not "for -i"
[12:56] <JEEBsv_> dannyzb: basically what it means is that you use it when you have something bandwidth-limited in the mix. One thing is strict pieces of hardware, the other is... network, for example!
[12:56] <dannyzb_> what did you say ? I had a disconnect -_-
[12:56] <JEEBsv_> 13:55 < JEEBsv_> ffmpeg -i hurrdurr.input -crf 23 -maxrate <minimum transfer rate you want to support>k -bufsize <maxrate * seconds of buffer>k  -vf scale=1280:720 -c:v libx264 -c:a libfdk_aac -b:a 192k out.file
[12:57] <JEEBsv_> 13:56 < JEEBsv_> dannyzb: basically what it means is that you use it when you have something bandwidth-limited in the mix. One thing is strict  pieces of hardware, the other is... network, for example!
[12:57] <sgfgdf> hello, guys! i'm trying to change the language of audio/video streams. i'm using this -- `ffmpeg -i in.mp4 -c:a copy -c:v copy -metadata:s:0 language=eng -metadata:s:1 language=eng out.mp4' which works, but i'm curious if i can do it without making separate file. is it possible?
[12:57] <JEEBsv_> basically it means that if the user has at least maxrate amount of bandwidth, and buffer bufsize amount of data, the user will never have to buffer again
[12:57] <dannyzb> isn't bufsize client-size in streaming ? what effect does it have on encoding format ?
[12:57] <JEEBsv_> so you _need_ it for network streaming
[12:58] <JEEBsv_> dannyzb: it limits the encoder so that you _know_ that's all you need to buffer
[12:58] <relaxed> sgfgdf: I don't think so
[12:58] <JEEBsv_> if you just put crf for example, it will never be limited
[12:58] <JEEBsv_> crf + vbv is basically limited CRF, if the rate goes over your set VBV limits
[12:58] <dannyzb> ah ok so it limits the size
[12:59] <dannyzb> I think i may actually want to give freedom to CRF without maxrate
[12:59] <JEEBsv_> you are doing "online streaming"
[12:59] <JEEBsv_> I don't think so
[12:59] <dannyzb> if a video is too high quality i would rather the bitrate rises
[12:59] <relaxed> so bump maxrate up a little
[12:59] <dannyzb> I do HTTP pseudo-streaming , not true streaming .. it's reasonable to have slower loads on super-high-quality
[12:59] <relaxed> you still need it
[13:00] <JEEBsv_> without VBV (maxrate/bufsize) you cannot say anywhere that you only need a connection X and Y amount of buffering
[13:00] <dannyzb> so you're saying just to set it really high
[13:00] <dannyzb> if i get you right
[13:00] <JEEBsv_> no, you set it to the levels you want to support from the users' connection wise
[13:00] <dannyzb> and lower-quality videos would have low bitrates anyway bcs of crf
[13:00] <sgfgdf> relaxed, ah, okay thank you!
[13:01] <dannyzb> if a user doesn't have a fast enough connection for HD video , he can just wait
[13:01] <dannyzb> doesn't concern me
[13:01] <dannyzb> basically I want the bitrate to be relative to video complexity
[13:01] <JEEBsv_> yes, that's what CRF more or less does
[13:02] <JEEBsv_> well, you can just set the VBV in a way that needs a higher speed then, it's still recommended to have a known limit that should enable the person to play the video with specific amount of buffering once
[13:02] <JEEBsv_> of course if you're not really streaming you aren't as limited :P
[13:02] <dannyzb> I still don't get the vbv-bufsize thing .. what buffer is it exactly? what difference does it make to encoding ? (different movie atom ? )
[13:03] <dannyzb> or is it just a recommendation to the video player running the video
[13:03] <JEEBsv_> don't consider maxrate and bufsize separately
[13:04] <JEEBsv_> in simple terms it means that the stream is encoded so that if the user buffers bufsize amount of bits, and has at least a transfer speed of maxrate, the user will never have to buffer again
[13:04] <JEEBsv_> the information generally isn't encoded into the stream so the player side has to be just set accordingly
[13:04] <JEEBsv_> when they both match, all works beautifully
[13:05] <dannyzb> oh so basically it changes to bitrate
[13:05] <dannyzb> maxrate is the maximum bitrate at every frame
[13:05] <JEEBsv_> no
[13:05] <JEEBsv_> maxrate is the maximum rate _over_ bufsize
[13:05] <dannyzb> ooohhhhh
[13:05] <dannyzb> ok
[13:06] <JEEBsv_> basically average rate over bufsize will never go over maxrate
[13:06] <dannyzb> so higher is much better fitting for action movies
[13:06] <dannyzb> where you suddenly have 2-3 seconds of high-speed action
[13:06] <dannyzb> spread over 20 seconds makes more sense
[13:06] <iive> how does max-rate relate with the bitrate of the communication channel?
[13:07] <JEEBsv_> iive: it just makes sure that maximum data rate of the video stream doesn't go over set maxrate over a set bufsize
[13:07] <dannyzb> wouldn't a really high vbv-bufsize increase encoding time ? ( since it needs to reencode previous frames sometimes to fit the block )
[13:07] <JEEBsv_> so you can make some decisions
[13:07] <JEEBsv_> regarding what kind of connections you want to support
[13:08] <JEEBsv_> dannyzb: no -- x264 actually pretty much never has to re-encode the frame to fit into vbv
[13:08] <Jellicent> Hey guys, I've been struggling with these little problems for a while now... I'm trying to stream to twitch but the volume is very low. Not the volume of me talking, I'm not recording my voice. But for instance, the ingame sounds or the music I'm listening to. Also, sometimes some frames are skipped. But the main problem is the sound.. I'm using ALSA on Arch Linux, I tried boosting all values to max, no
[13:08] <Jellicent> changes..
[13:08] <JEEBsv_> it already during the encode of a frame tries to make it fit the left bits in VBV
[13:08] <Jellicent> Damn it! :p
[13:08] <dannyzb> ok so using a low value is stupid i guess , makes action scenes blocky
[13:08] <dannyzb> thanks
[13:09] <dannyzb> btw does crf 21 sound reasonable to you ?
[13:09] <JEEBsv_> yes, but do make sure you actually found a value that is the highest that still looks good for you
[13:09] <JEEBsv_> and then just decide on the connections you support with minimum buffering :D
[13:09] <JEEBsv_> and set maxrate and bufsize accordingly
[13:10] <JEEBsv_> (and possibly modify your players in a similar way)
[13:10] <dannyzb> yea .. I'll do that
[13:10] <dannyzb> btw whats the lowest quality-loss thing i can do to reduce encoding time?
[13:11] <JEEBsv_> and yeah, ffmpeg itself can set -crf and -maxrate and -bufsize just fine, so you don't have to use -x264opts :)
[13:11] <JEEBsv_> (you just need to add k at the end because ffmpeg uses bits while x264 uses kilobits)
[13:12] <JEEBsv_> the lowest thing is to just match up the preset :P the presets should be a nice area between speed and quality
[13:13] <dannyzb> I use veryfast .. superfast destroys quality for action scenes completely ( all blocky )
[13:13] <dannyzb> but it's super processor intensive
[13:14] <JEEBsv_> DeadSix27: yeah -- it just seems to fail at allocating memory. Try ultrafast so it uses minimum features within x264 and thus uses the least memory?
[13:14] <iive> Jellicent:  in alsamixer you get recording volumes if you press <tab> once, pressing it second time would show all. You have seprate control for playback (to headphones) and recording (to capture device).
[13:14] <JEEBsv_> -preset ultrafast that is
[13:14] <iive> Jellicent: make sure you don't have pulse audio routing.
[13:14] <JEEBsv_> dannyzb: yes -- x264 will try to go as fast as it can
[13:14] <DeadSix27> JEEBsv_: in what unit does x264 show that?
[13:14] <DeadSix27> if its kilobytes, that would be 200gb of memory allocation, bytes would be not even /4 of a gif
[13:14] <JEEBsv_> DeadSix27: the malloc fail? That's in bytes I think
[13:15] <DeadSix27> gig*
[13:15] <DeadSix27> then why cant it allocate such a low size
[13:15] <dannyzb> well i guess I can't push speed up anymore at this quality
[13:15] <dannyzb> good enough .. time for a new super-server :D
[13:15] <dannyzb> btw whats more cost effective ffmpeg-wise : intel or AMD ?
[13:16] <JEEBsv_> DeadSix27: dunno, might just be a smaller allocation after a bigger one
[13:16] <JEEBsv_> and the smaller one later just happens to be the one to fail
[13:16] <iive> JEEBsv_: i'm afraid i don't fully understand your answer. If the communication channel is CBR (as are most channels) and is e.g. 1Mbps. should I set maxbitrate to 1Mbps.
[13:16] <DeadSix27> JEEBsv_: it used ~5gb ram at the time
[13:16] <DeadSix27> of 16gb available
[13:16] <JEEBsv_> dannyzb: intel definitely if you're going to use x264
[13:16] <Jellicent> iive: I don't even have pulseaudio installed, so that won't be the problem. I'll have a quick look into what you said.
[13:16] <JEEBsv_> AMD hasn't been giving good cost-performance for a long-long time
[13:17] <iive> VBV is like the math taks with pools filling and draining water. the only difference is that they do that with variable rate on one side.
[13:17] <dannyzb> ok thanks
[13:17] <dannyzb> and one last thing
[13:17] <dannyzb> do I have any use for "refs" ?
[13:18] <JEEBsv_> only if you use slower presets and want to limit reference frames to a specific H.264 level
[13:18] <JEEBsv_> because you can set -level in ffmpeg, but that will only set the libx264 flag
[13:18] <JEEBsv_> not limit the reference frames to fit that level
[13:18] <DeadSix27> now that we're on questioning time, yesterday i asked sommin about keyframes, and if they're doing the "skipping gabs" in playback
[13:18] <dannyzb> ah right .. I heard "no" :)
[13:18] <DeadSix27> how can i make skipping to specific times in a video (in player) more precise?
[13:19] <DeadSix27> sometimes i can only skip to every 5s or so, which is kinda annoying
[13:19] <JEEBsv_> iive: you should set it to the minimum bandwidth you support. If you want to use the whole speed of the communication channel then you use its speed - (possible audio overhead + possible container overhead) for maxrate, and then bufsize is set by how much you want to buffer (and how much freedom you want to give to the encoder)
[13:21] <JEEBsv_> DeadSix27: -g sets the (maximum) GOP size, which is the maximum amount of pictures between two IRAPs
[13:21] <JEEBsv_> (IRAP is a HEVC/H.264 wording but man do I love it more than IDR or 'keyframe' <3 )
[13:21] <JEEBsv_> uhh, HEVC/H.265
[13:21] <DeadSix27> and using the fps rate i can then calculate the seconds i want to have between right?
[13:22] <iive> yes
[13:22] <DeadSix27> like @ 25fps output i could use -g 25, to have a 1s precise skipping?
[13:22] <JEEBsv_> no
[13:22] <DeadSix27> mh
[13:22] <JEEBsv_> you will get smaller or by max 25 frame GOPs
[13:22] <JEEBsv_> basically the maximum length of a GOP is 25 frames
[13:23] <DeadSix27> so 0-1s precising skipping
[13:23] <JEEBsv_> yes
[13:23] <DeadSix27> would setting 0,5s as minimum and 1,2s be better?
[13:23] <DeadSix27> is doesnt it matter having it just set to -g 25
[13:24] <DeadSix27> or*
[13:24] <DeadSix27> (what i mean is, would that impact quality/size or encoding speed much)
[13:25] <JEEBsv_> not sure how x264 limited minimum keyint, but I would guess at that length most GOPs would be close to the full 1s
[13:25] <JEEBsv_> but yes, you could try limiting the minimum keyint to at least half a second
[13:25] <iive> it won't affect speed, but it would affect bitrate/quality
[13:25] <DeadSix27> its -keyint_max right?
[13:26] <JEEBsv_> no idea about the x264 setting
[13:26] <JEEBsv_> uhh
[13:26] <JEEBsv_> ffmpeg I mean
[13:26] <JEEBsv_> I only know the x264 one
[13:26] <DeadSix27> i had a page for that sec.
[13:26] <JEEBsv_> I only know the equivalent of --keyint for ffmpeg
[13:26] <JEEBsv_> which is -g
[13:26] <JEEBsv_> I have no idea about the minimum keyint equivalent in ffmpeg :)
[13:26] <DeadSix27> --min-keyint <integer> (x264) -keyint_min <integer> (FFmpeg)
[13:26] <DeadSix27> accordign to that page
[13:27] <JEEBsv_> possible, feel free to try if that works :D
[13:27] <DeadSix27> should, i tried it yesterday
[13:27] <DeadSix27> just didnt know how to handle keyint stuff
[13:28] <DeadSix27> JEEBsv_: btw i successfully compiled ffmpeg, but cross from linux, didnt gwt it to work on windows
[13:28] <DeadSix27> took like 2hrs and 5gb of my hdd space (crazy)
[13:29] <JEEBsv_> dunno, I've compiled both from msys with a mingw-w64 toolchain by nev, as well as from lunix the same way I noted to you
[13:29] <JEEBsv_> of course it's really easy to set up the msys/mingw(-w64) thing crappily, but I really don't consider that being a problem specific to ffmpeg in any way
[13:30] <DeadSix27> i used that build script
[13:30] <DeadSix27> i tried myself, but didnt get the librarys working for idk what reason
[13:31] <DeadSix27> anyway, like you said, libdk_aac has way better quality
[13:31] <DeadSix27> +f
[13:31] <JEEBsv_> yeah, too bad it was released under a license that doesn't permit one to distro binaries of it coupled with ffmpeg+libx264 :<
[13:36] <DeadSix27> ye
[13:37] <DeadSix27> only together right?
[13:37] <DeadSix27> wouldnt a second tool without x264 solve it funnily-workarround-ly
[13:37] <JEEBsv_> well, you can't really distro fdk-aac binaries either unless you have taken the steps noted in the license
[13:37] <JEEBsv_> and no, it needs enable-nonfree with LGPL setup as well
[13:38] <JEEBsv_> so removing x264 really doesn't help either
[13:38] <DeadSix27> k
[13:38] <JEEBsv_> faac became nonfree a few years ago when it was found that it contained source code that was not GPL-compatible (while faac tried to imply it was GPL)
[13:39] <JEEBsv_> so yeah, right now we're in the funny situation where the best aac encoder you can distro is the internal libavcodec one :D
[13:39] <DeadSix27> and theres no way to write own stuff replacing that code?
[13:40] <JEEBsv_> there is, but no-one cares about faac to be honest. Most people just build the best thing at that point on the machine (fdk-aac at the moment), and the rest are more interested in developing the internal one
[13:40] <DeadSix27> ah
[13:40] <JEEBsv_> there's a huge thread on the trac issue tracker about improving the internal one
[13:40] <DeadSix27> internal = aac (the experimental one) right?
[13:40] <JEEBsv_> yes, which I have no idea why it's still experimental
[13:41] <JEEBsv_> because it's better than the two vo-aacenc library one for example
[13:41] <DeadSix27> im not that exprienced with it that much
[13:41] <JEEBsv_> which isn't set as "experimental"
[13:41] <DeadSix27> but for some reason experi. aac kinda gave me bad quality
[13:41] <DeadSix27> at the same settings as libvo_aacenc and libfdk
[13:41] <DeadSix27> and those were better in qualtiy
[13:41] <JEEBsv_> it should be worse than vo-aacenc in general
[13:41] <JEEBsv_> fdk beats it
[13:42] <DeadSix27> what i meant is libfdk > libvo > aac
[13:42] <JEEBsv_> it's not a good encoder, but on the other hand neither is vo-aacenc :)
[13:42] <JEEBsv_> yeah
[13:42] <JEEBsv_> I just don't agree with that in general :)
[13:42] <JEEBsv_> also vo-aacenc is limited to stereo
[13:42] <DeadSix27> could be stupid encoding parameters and lack of knowledge i guess.
[13:42] <JEEBsv_> also you could try the newest patch on that huge'o'licious thread
[13:42] <JEEBsv_> lol
[13:43] <JEEBsv_> that should improve the internal one nicely
[13:43] <DeadSix27> how to get it?
[13:43] <DeadSix27> im currently just using source of git
[13:43] <JEEBsv_> https://trac.ffmpeg.org/ticket/2686 scroll to the bottom and start looking at the newest patch like that :D
[13:43] <JEEBsv_> it's a long thread
[13:44] <DeadSix27> my brain cant allocate that memory
[13:44] <JEEBsv_> seems like three weeks ago he was 'close to releasing version 8' of the patch
[13:44] <JEEBsv_> anyways, pretty cool that someone cares :)
[13:45] <DeadSix27> someone with knowledge on how to improve it*
[13:45] <DeadSix27> afterall i care as well
[14:36] <DelphiWorld> hi guys
[14:36] <DelphiWorld> stupid QUESTION:P
[14:36] <DelphiWorld> anyone know how to make any mp3 file to be flac?
[14:36] <DelphiWorld> all files not only one, including subdirs
[15:20] <Jellicent> iive: Thank you for your tip a few hours(?) ago. I found something I could have tweaked earlier, but I didn't think of it. So when I tabbed I found it.. duh. Thank you! <3
[15:20] <iive> glad I had somehow helped :)
[15:35] <dannyzb> frame= 2905 fps= 88 q=29.0 size=   21806kB time=00:02:01.45 bitrate=1470.8kbits/s
[15:35] <dannyzb> does this bitrate include audio or not?
[15:36] <dannyzb> i used crf=21:bitrate=1280:vbv-maxrate=1280:vbv-bufsize=12800 and that bitrate is obviously above that
[15:39] <relaxed> dannyzb: you can't set both crf and bitrate, choose one rate control method
[15:40] <dannyzb> relaxed : people already told me i can use both here .. i think you're confused
[15:40] <relaxed> that's news to me
[15:41] <dannyzb> well we're going to need someone neutral to clear this up
[15:44] <relaxed> http://mewiki.project357.com/wiki/X264_Settings#Ratecontrol  "This option is mutually exclusive with qp and bitrate."
[15:44] <relaxed> look look under "crf"
[15:46] <dannyzb> good to know !
[15:46] <relaxed> add -map 0:v after the input to only encode the video if you want to monitor the bitrate.
[15:47] <dannyzb> woah crf encodes 20% faster for me
[15:47] <dannyzb> excellent !
[15:49] <dannyzb> thanks man
[15:49] <relaxed> you're welcome
[17:36] <dannyzb> should i use main or baseline for mobile devices ?
[17:39] <dannyzb> j
[17:40] <klaxa> depends on how old your target devices are
[17:40] <klaxa> most devices support high profile
[17:40] <klaxa> *most recent devices
[17:44] <dannyzb> ok cool
[17:44] <dannyzb> so I'll do main for SD and high for HD
[17:44] <dannyzb> another thing - i see all my encodings drop in framerate as they progress .. what causes that?
[18:28] <PowerCC> recently installed ffmpeg on my debian squeeze and it's forcing me to use avconv
[18:28] <PowerCC> that's not ffmpeg, new fork?
[18:29] <PowerCC> it's very close but -x264opts aren't working the same
[18:29] <JEEB> a) it's not forcing you as far as I know b) yes, it's recommending the usage of avconv because libav left that binary to wither after rewriting parts of ffmpeg (and renamed the rewritten thing to avconv)
[18:30] <JEEB> PowerCC, depends on the version you have, but in general I think libav chose the way of actually having settings for x264's things instead of x264opts
[18:30] <JEEB> and I think by now those work in ffmpeg as well, since most if not everything from libav gets merged into ffmpeg
[18:30] <JEEB> PowerCC, so feel free to say what settings you're setting
[18:30] <JEEB> and I'll try to note what you should be using
[18:30] <PowerCC> i tend to modify as follows: -x264opts rc_lookahead=24:scenecut=0:chroma_me=1:analyse=1:ipratio=1.25
[18:31] <Jellicent> When streaming to twitch (gaming) I get a constant delay of 2-3 seconds constantly in the game. Is there a way to reduce it?
[18:31] <PowerCC> avconv rejects it
[18:31] <JEEB> PowerCC, yes the name of the option to specifically set x264 api settings is different @ libav
[18:31] <JEEB> that said
[18:31] <JEEB> why do you specifically need to set those settings o_O
[18:31] <JEEB> presets not good enough
[18:31] <JEEB> ?
[18:32] <PowerCC> it actually speeds up the encode abit
[18:32] <JEEB> uhh
[18:32] <JEEB> if you want to speed up encoding you set a faster preset
[18:32] <PowerCC> i believe the lookahead is defaulted to 40 or 50
[18:32] <JEEB> yes, presets handle that
[18:32] <PowerCC> i like the quality produced.
[18:32] <JEEB> there should be a similar preset http://mewiki.project357.com/wiki/X264_Settings#preset
[18:32] <JEEB> just test them out
[18:32] <PowerCC> thanks
[18:32] <JEEB> you should not have to poke those settings by yourself
[18:32] <esing> Hi, I'd like to convert a video (e.g. mp4) to only audio (.aif). I tried ffmpeg -i video.mp4 -vn -b:a 128k output.aif , but the output.aif will be too big ( http://sprunge.us/iCcg ). This is the input file: http://sprunge.us/CjgR (which has just 4,77 MiB of an audio stream, but the .aif results in +30MB?!)
[18:32] <JEEB> everything but ultrafast or placebo should be usable
[18:33] <JEEB> PowerCC, the option to set those in ffmpeg and avconv is -preset
[18:33] <PowerCC> got it
[18:33] <PowerCC> the defaults are not bad either... i may just dumped my preset from here on out.
[18:34] <JEEB> default is preset medium
[18:34] <PowerCC> yup
[18:34] <PowerCC> loseless i rarely use
[18:34] <JEEB> Jellicent, there are various things you can do on the encoder's side as well as if you are in control of the player software used for playback of the stream
[18:34] <JEEB> Jellicent, although I have no idea how you take your input and how low latency ffmpeg has there
[18:35] <JEEB> basically I know that if you really, really want to, you can get sub-100ms latency with (lib)x264
[18:35] <Jellicent> JEEB: I guess I can only do something on my side, since I'm streaming to twitch.
[18:35] <Jellicent> Let me pastebin it, sec.
[18:35] <PowerCC> your a developer jeeb?
[18:36] <JEEB> PowerCC, I have some code in ffmpeg/libav/x264, but I can't really call myself anything special :P
[18:36] <PowerCC> last i did anything with ffmpeg use back with MEnocder project
[18:36] <PowerCC> remember -vo dxr2? ;)
[18:36] <PowerCC> those were the days!
[18:37] <JEEB> ugh, I really would rather not to remember mencoder :D
[18:37] <Jellicent> JEEB: http://sprunge.us/NUSJ I'm open for any suggestions. Thing is I took the script from a site, so I'm not familiar with all the settings.
[18:37] <JEEB> PowerCC, also that specific settings thing in libav/avconv seems to be -x264-params
[18:37] <JEEB> but you really shouldn't need it :)
[18:38] <JEEB> most things have their own setting in avconv (and by now most probably in ffmpeg as well)
[18:38] <PowerCC> can i paste my entire cli here, it's not too long
[18:39] <JEEB> Jellicent, you don't need to resample audio btw. FLV can handle !44.1kHz just fine :)
[18:39] <Jellicent> Alright, JEEB.
[18:39] <JEEB> also holy crap
[18:39] <JEEB> 512kbps audio o_O
[18:40] <Jellicent> Guess I could take THAT out...
[18:40] <JEEB> 192kbps should be enough
[18:40] <Jellicent> Yeah.. like a lot.
[18:40] <JEEB> and AAC should be better
[18:40] <Jellicent> Instead of lame I guess+
[18:40] <Jellicent> *?
[18:41] <JEEB> if you are using someone else's binary, you can use -c:a aac -strict experimental, and if you have built it yourself with fdk-aac you can use -c:a libfdk_aac
[18:41] <JEEB> anyways, I'm not sure how much ffmpeg buffers over at the input side
[18:41] <Jellicent> Hmm okay.
[18:42] <JEEB> you can get the latency minimized on the x264's side with -tune zerolatency
[18:42] <JEEB> but do note that this will make encoding slower (it will thread within a single picture instead of multiple at once), and quality will suffer
[18:42] <Jellicent> I see. Thank you.
[18:42] <JEEB> also i don't see -maxrate or -bufsize
[18:43] <JEEB> this is _needed_ for streaming
[18:43] <Jellicent> I'll have a look into those, thank you. :)
[18:43] <Jellicent> Guess the person writing this had a monster as a machine....
[18:43] <Jellicent> And the best internet in the world.. :p
[18:43] <JEEB> look at twitch for the maxrate and buffering rules
[18:43] <Jellicent> Will do, thank you.
[18:43] <JEEB> basically usually they say the maximum rate, and then how many seconds the buffering is
[18:44] <JEEB> you calculate how much you are giving to the audio, and then take that and a couple dozen kilobits off of the maxrate
[18:44] <JEEB> and set it to -maxrate
[18:44] <JEEB> and then set maxrate * seconds of buffer as bufsize
[18:44] <JEEB> for example two seconds of buffering would be 2*maxrate
[18:45] <Jellicent> I see. :)
[18:45] <JEEB> this makes sure that you have a set bandwidth usage set
[18:45] <Jellicent> Great, I guess that's what's missing for me.
[18:46] <JEEB> so that a user with at least maxrate or so bandwidth and who has buffered bufsize of data can watch the stream without having to buffer again
[18:46] <JEEB> this is called VBV
[18:46] <JEEB> (maxrate + bufsize)
[18:47] <Jellicent> Cool, I didn't know of that! :D
[18:47] <JEEB> unfortunately even people who want to do streaming on the web often don't :P
[18:47] <JEEB> as in, for money
[18:49] <Jellicent> That makes a lot of sense.
[18:49] <JEEB> anyways, try with vbv and AAC first, after that try with -tune zerolatency
[18:50] <Jellicent> Will do that. :)
[18:58] <PowerCC> -threads 4 -c:a ac3 -b:a 448k -ar 48000 -ac 6 -c:v libx264 -coder ac -level 41 -vb 5000k -bf 0 -refs 2 -flags +loop -weightp 2 -trellis 1 -mixed-refs 1 -weightb 0 -8x8dct 1 -fast-pskip 0 -mbtree 1 -me_method umh -subq 6 -me_range 16 -sc_threshold 0 -qmin 10 -qmax 50 -qdiff 3 -qcomp .5 -g 24 -keyint_min 2 -subq 6 -psy 1 -x264opts rc_lookahead=24:scenecut=0:chroma_me=1:analyse=1:ipratio=1.25 -sn -copyts output.mp4
[18:59] <PowerCC> that's usually what i do JEEB
[18:59] <JEEB> let me guess
[18:59] <JEEB> you just copied that off of some random mediainfo log
[19:00] <JEEB> the x264 stuff that is :P
[19:05] <PowerCC> no
[19:05] <JEEB> well it very much seems so :P
[19:05] <JEEB> because you're, among others, setting some old x264 defaults
[19:05] <JEEB> like qmin and qmax
[19:05] <PowerCC> why would i do anything that does not speed up my process
[19:05] <PowerCC> remember i have used that for the last 4 years
[19:06] <JEEB> well, that's what it is :P some of those settings have no effect on speed but instead just show that you're copy-pasting stuff from somewhere
[19:06] <PowerCC> given the above syntax how would you apply it?
[19:06] <PowerCC> i don't claim to be an expert.
[19:07] <PowerCC> just pieced together a formula that has worked for me
[19:07] <PowerCC> i use the output video to playback on my tivos.
[19:07] <JEEB> qmin/qmax is just the default for QP range until 2011 or so? After that the lower part was set to zero or so because there was no longer any worry that the encoder would unneededly use lower QPs
[19:07] <JEEB> http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=04256645537d17b66f2a46bd8605859e91e0cf8a
[19:07] <JEEB> ok, it was 2010
[19:08] <PowerCC> and OpenCL for libx264 is used by default if gpu/cpu supports it?
[19:08] <JEEB> no
[19:08] <PowerCC> so that's why i used lookahead
[19:08] <PowerCC> to my understanding.
[19:08] <JEEB> nope
[19:08] <PowerCC> that's why i am here ;)
[19:08] <JEEB> anyways, you can just rip out most of it
[19:08] <PowerCC> thanks
[19:09] <JEEB> and use -preset -level and then just match up -refs to the level maximum limit
[19:09] <PowerCC> that would free up lots of real estate on my terminal
[19:09] <PowerCC> as you wrote earlier, I am probably just fine with defaults (medium)
[19:09] <JEEB> because -level only sets the flag in the stream, unlike x264cli that also matches up the reference frame count to the maximum to the given resolution + level combo
[19:09] <PowerCC> i c
[19:09] <JEEB> have been thinking about adding that code to libx264.c
[19:09] <JEEB> but never got to it :D
[19:10] <JEEB> basically there's a limit to macroblocks on every level, and the resolution thus decides how many reference frames you can use for a given level :)
[19:12] <PowerCC> i am not encoding from pure source anyhow... most of what i do is transcode
[19:12] <PowerCC> but if i did pure blu-rays i'd be more concern.
[19:13] <JEEB> nah, if you're encoding for hardware players you generally want to create streams that comply to a level :)
[19:13] <PowerCC> is it true OpenCL only speeds up process by using lookahead
[19:13] <PowerCC> or can the gpu be more useful to do other encoding
[19:13] <JEEB> yes, it's just an implementation of ME lookahead, not even the main lookahead
[19:13] <PowerCC> pretty useless
[19:14] <JEEB> it wouldn't be useless if GPUs were actually useful for a lot of that stuff
[19:14] <JEEB> right now it gives little speed-up if any, and the fastest presets don't have either lookahead
[19:14] <JEEB> because it's too slow for those
[19:15] <PowerCC> well lookahead helps keep my file size down
[19:15] <JEEB> GPU encoding in general is just marketing kool-aid
[19:15] <PowerCC> hee
[19:15] <JEEB> yes, lookahead is a useful feature, I'm just talking about the GPU implementation of ME lookahead being generally useless :P
[19:15] <JEEB> it's a nice experiment and the first at least somewhat "useful" piece of code with the GPU
[19:15] <JEEB> for others to look at
[19:15] <PowerCC> i am pretty amazed my remote box which is just atom 1.8ghz with 4 threads can get around 11-15fps ;)
[19:16] <JEEB> but really, there's a reason why most makers have quickly and silently switched to ASICs
[19:16] <JEEB> :)
[19:16] <JEEB> instead of GPU-based solutions
[19:16] <PowerCC> yes, it works on my Mac mini with Intel HD3000 even though apple reads open cl 1.0 n/a
[19:17] <PowerCC> i have a Mac mini mid-2011
[19:17] <PowerCC> but now i am trying to encode on my kimsufi mostly since it just sits there.
[19:18] <PowerCC> you do much with -vf subtitles?
[19:19] <JEEB> anyways, what I'm saying is that OpenCL will not get used by default in libx264 and it really is useless so you shouldn't use it :)
[19:19] <PowerCC> i tend to burn them in
[19:19] <JEEB> nah, I don't use that :)
[19:19] <PowerCC> it's a pain at times, relies on font_config
[19:19] <PowerCC> and everything must be utf8
[19:20] <PowerCC> i can say one thing, libx264 produces amazing results.
[19:20] <JEEB> yes, x264 itself is quite awesomesauce
[19:20] <PowerCC> by far better than any other commercial (junk ware) made out there.
[19:20] <JEEB> it only loses by a bit to the reference encoder
[19:21] <PowerCC> which by the way also use ffmpeg
[19:21] <JEEB> while being quite a few times faster
[19:21] <PowerCC> i thought it won by a hair last couple of years.
[19:21] <PowerCC> that was 2005 ;)
[19:22] <JEEB> I'd be surprised if it actually won the reference, because the reference encoder is slow as hell but pretty much brute forcing the best possible results
[19:22] <PowerCC> passed Ateme by a hair
[19:22] <JEEB> Ateme is not the reference :)
[19:22] <JEEB> JM is
[19:22] <PowerCC> expansive!!!
[19:22] <JEEB> http://iphome.hhi.de/suehring/tml/
[19:23] <PowerCC> never heard of them
[19:23] <JEEB> yeah, end users don't
[19:23] <JEEB> it's the stuff used to decide if a feature should enter a standard or not
[19:23] <PowerCC> thought you were referring to real cinema
[19:23] <JEEB> JM for AVC/H.264
[19:23] <JEEB> HM for HEVC/H.265
[19:23] <PowerCC> $?
[19:24] <JEEB> they're both open source for ObviousReasons
[19:24] <PowerCC> i'll stick to what i know.
[19:24] <PowerCC> or somewhat know
[19:24] <JEEB> yes, and I'm not in any way saying that you should use JM or HM
[19:24] <JEEB> reference software is reference software :)
[19:25] <JEEB> (they are both open source because...) after all you can't do proper development and research on what should enter a standard without having access to a common platform :)
[19:25] <JEEB> and basically getting to JM's level while being quite a bit faster is actually pretty awesome ;)
[19:25] <JEEB> that's what I was trying to say
[19:27] <PowerCC> what is JM using?
[19:27] <PowerCC> what code, completely their own
[19:27] <PowerCC> ?
[19:28] <PowerCC> them .de always been up to snuff with codec
[19:28] <JEEB> yeah, it's what was made during the research and development phase of AVC/H.264
[19:28] <PowerCC> i see... sony is on board right?
[19:28] <JEEB> basically all kinds of companies and other research parties coming up with ideas, and they were then implemented
[19:28] <PowerCC> yup
[19:28] <JEEB> and then tested etc.
[19:29] <JEEB> http://hevc.kw.bbc.co.uk/git/w/jctvc-hm.git
[19:29] <JEEB> HM
[19:29] <JEEB> (the HEVC/H.265 one)
[19:29] <PowerCC> i just recently bought the latest tivo box (Roamio, forgive the silly name).
[19:29] <PowerCC> it's got the brand new broadcom decoder it pretty much decodes anything i throw at it... the tivo premiere not as forgiven.
[19:30] <PowerCC> it has an encoder built-in aka tivo stream... it's pretty amazing quality given it only does hw encoding (mpeg2 -> h.264)
[19:30] <PowerCC> however frame rate wise it STINKS!
[19:30] <PowerCC> not very noticeable on iPhone but on the iPad very much so.
[19:31] <JEEB> I think the best hardware ASIC for encoding I've seen so far for end users is what Intel has on the Haswell platform
[19:31] <PowerCC> I am considering sling box latest
[19:31] <PowerCC> it does 60fps
[19:31] <PowerCC> i would of never guessed intel to be a front runner.
[19:32] <PowerCC> thought nvidia was ahead
[19:32] <PowerCC> in hw encoding
[19:32] <PowerCC> but quality wise no one is coming close to software encoding
[19:32] <JEEB> nvidia's ASIC that they put from the 600+ series forwards wasn't too bad, but intel's thing is still the most fabulous one with haswell
[19:32] <JEEB> also it's getting somewhat close to software encoding with its lookahead etc. modes that came with the latest iteration
[19:33] <PowerCC> mmmmm
[19:33] <JEEB> of course still not really too close to x264
[19:33] <JEEB> but it most definitely is getting somewhere
[19:33] <JEEB> and the speeds are pretty good
[19:33] <JEEB> ~200 frames
[19:33] <JEEB> per second
[19:33] <PowerCC> and even if it was, libx264 can use my Toaster's cpu to encode.
[19:34] <JEEB> yup
[19:34] <PowerCC> I am able to use an old has to serve up libx264, yes it's 1 frame per 3 seconds but heck what else is it doing
[19:34] <PowerCC> has/nas
[19:34] <PowerCC> python is also my friend runs on anything
[19:35] <PowerCC> heard of pyTivo project?
[19:36] <PowerCC> now that's a great use of ffmpeg project
[19:38] <Jellicent> JEEB It seems that streaming just doesn't work out. I tried all the options and it's either me lagging, the stream skipping like 80% of the whole recording.. or both.
[19:38] <JEEB> o_O
[19:38] <Jellicent> Outrageous.
[19:38] <JEEB> huh
[19:38] <Jellicent> I don't know why. It worked fine under Windows, last time I tried at least.
[19:38] <JEEB> does the encoder show that it's not being able to encode stuff fast enough or anything?
[19:39] <JEEB> also I have no idea about screen capture on *nix :D
[19:39] <PowerCC> drop frames?
[19:39] <Jellicent> Yes, thanks. It drops frames. Like they are fucking hot.
[19:39] <PowerCC> perhaps -r fps
[19:39] <PowerCC> ha
[19:39] <JEEB> Jellicent, try switching to a faster preset
[19:39] <PowerCC> try matching
[19:39] <Jellicent> They are set to 30, shouldn't be a problem.
[19:40] <JEEB> http://mewiki.project357.com/wiki/X264_Settings#preset
[19:40] <PowerCC> slap it in there just in case.
[19:40] <PowerCC> -r 30
[19:40] <JEEB> > slap it in there just in case
[19:40] <Jellicent> It's not only dropping them, but before dropping them it stops showing what happens on the screen, then fast forwards through all it missed and drops half of it.
[19:40] <JEEB> > implying that is a good idea
[19:40] <Jellicent> Will have a look at that.
[19:40] <JEEB> Jellicent, anyways it's either the capture or the encoder not being fast enough
[19:40] <Jellicent> Yup.
[19:41] <JEEB> check presets and what you're setting with -preset
[19:41] <JEEB> and if that doesn't help...
[19:41] <JEEB> :s
[19:41] <Jellicent> MY preset is faster right now. B( Should maybe try something lower.
[19:41] <PowerCC> i have lots of issues with source being 23.81
[19:41] <PowerCC> force it to -r 24
[19:41] <PowerCC> makes the output in sync and smooth
[19:41] <Jellicent> Worst thing is the delay though.. can't play an RTS with 5s delay, haha.
[19:42] <Jellicent> I'll try 24.
[19:42] <JEEB> PowerCC, use settings where they make sense... don't plaster them around randomly
[19:42] <PowerCC> oh i have tried
[19:42] <PowerCC> -r 24 was the only fix
[19:42] <PowerCC> with 23.81
[19:42] <PowerCC> 23.976 didn't help
[19:42] <PowerCC> i don't know why -r 24 fixes my output but it did.
[19:42] <JEEB> that is 24000/1001 :| but in any case, my comment was just towards trying to push random settings to people
[19:43] <PowerCC> most of what i do as you can tell is lots of guess-work.
[19:43] <JEEB> also ffmpeg's architecture really doesn't care about frame rates but the timestamps of all pictures, and copies them over
[19:43] <JEEB> yes, and I really want to stick a spork up to your eyeball for trying to recommend random stuff to random folk :P
[19:43] <PowerCC> oh, sorry
[19:43] <PowerCC> just thought it was helpful.
[19:44] <PowerCC> i am just speaking out of my own experiance.
[19:44] <JEEB> trying to be useful is a good thing. Just that you really should try to understand things instead of Cargo Culting
[19:44] <PowerCC> so just so i understand why -r 24 did fix my problem?
[19:44] <PowerCC> agreed
[19:45] <JEEB> probably broken timestamps somewhere? or the hardware player not liking timestamps that don't confine to a certain area
[19:45] <JEEB> I can't possibly know
[19:45] <PowerCC> the other odd issue that makes no sense to me
[19:45] <PowerCC> my tivo plays back 25 (pal) no dropped frames
[19:46] <PowerCC> of course it won't do 1080p/24 but i'll take it over skipping frames.
[19:47] <PowerCC> JEEB: is codec your hobby or also your profession?
[19:47] <JEEB> mostly a hobby, I've not done it work-wise other than random projects
[19:47] <PowerCC> I'm a network engineer so arp/netstat all day long...
[19:48] <PowerCC> it does not stop to amaze me, ever since the days of divx
[19:48] <PowerCC> my friend went on to really try and make it big with 3ivx
[19:48] <PowerCC> he is in australia
[19:48] <PowerCC> but i can't begin to understand half of how encoding works other than it's ALOT of number crunching.
[19:49] <JEEB> you can watch xiph's monty's intro video for a nice introduction
[19:50] <JEEB> http://www.xiph.org/video/vid1.shtml
[19:50] <PowerCC> thx
[19:50] <PowerCC> i do get excited enough if all my libs and ffmpeg just compile perfectly on my platform of choice ;)
[19:50] <PowerCC> Jellicent: how is it going?
[19:52] <PowerCC> if you ever need help with network jeeb i am your guy.
[19:52] <PowerCC> cisco switch/telephone/modem you name it.
[19:54] <PowerCC> this is out-dated: http://ffmpeg.gusari.org/viewtopic.php?f=8&t=874
[19:55] <PowerCC> thanks jeeb, i'll see you here next time... happy xmas!
[20:12] <Jellicent> Haha.. man. The way my output came out on twitch.. priceless.
[20:29] <Ulfr_> Hello all. I'm trying to install ffmpeg on a ubunutu 10.04 server to convert videos to flash. I was able to get the conversion to work, but couldn't get sound, so I followed a tutorial, realized it wasn't a system installation, and would genuinely appreciate some assistance
[20:31] <Ulfr_> I'm not trying to get someone to do this for me, I'm just trying to migrate a server and ffmpeg isn't terribly understanding about that
[20:31] <JEEB> anything on the 10.04 would be quite old so you most probably want to build it yourself :s
[20:31] <JEEB> https://trac.ffmpeg.org/wiki/UbuntuCompilationGuide
[20:32] <JEEB> only build those libraries that you need
[20:32] <JEEB> x264 for H.264 encoding and fdk-aac for AAC encoding, for example
[20:33] <Ulfr_> That's the tutorial I followed~
[20:33] <Ulfr_> worked great!
[20:33] <Ulfr_> until www-data tried to use it
[20:34] <Ulfr_> Tried to unfutz that situation and wound up with -formats missing the bottom half of it's results
[20:34] <Ulfr_> JEEB: ^
[20:34] <JEEB> you have to use either the full path to the binary, or modify the PATH
[20:34] <JEEB> to make it use the same ffmpeg binary
[20:35] <Ulfr_> JEEB: I've done so, the binary executes fine, but when I run ffmpeg -formats it doesn't list codecs
[20:35] <JEEB> of course not, -codecs is for "codecs" :P
[20:36] <JEEB> also those listings don't just change
[20:37] <JEEB> you are running a different binary, and thus you have to make sure that you are running the same one :P
[20:37] <Ulfr_> JEEB: One moment. I'm basking in how profoundly stupid I feel at the moment.
[20:39] <Ulfr_> Okay, all better. Yeah, I checked the timestamp to make sure it was the correct version. Codecs looks like it's supposed to, and I ran ./conifgure with --enable-libfaac, but it's not in the list. Is that normal?
[20:40] <JEEB> yes
[20:40] <JEEB> also don't build with faac
[20:40] <JEEB> but fdk-aac
[20:40] <JEEB> they both need --enable-nonfree
[20:40] <JEEB> but fdk-aac is better
[20:41] <Ulfr_> JEEB: I absolutely agree with you, but I am *so* not delving into this warren of confusion and hate that is this website to change things around
[20:42] Action: JEEB shrugs
[20:42] <JEEB> suit yourself
[20:42] <Ulfr_> JEEB: For reference, videos conversions aren't triggered by upload events, it's done by a crontab. The dark wizard that built this also decided he didn't need a config file, he needed a database table for holding config settings
[20:44] <Ulfr_> JEEB: Thank you very much though!
[21:11] <Ulfr_> Am I losing my mind or is it supposed to take multiple executions of the program to convert a video
[21:12] <JEEB> 2pass encoding (average bit rate rate control's best mode) needs two passes, yes
[21:12] <JEEB> CRF and one-pass average bit rate rate control only needs one pass of course
[21:12] <JEEB> (of which I definitely prefer CRF :D )
[21:13] <Jellicent> JEEB I think the problem is my upload rate. I give up for now... haha.
[21:13] <Jellicent> I know I'll try again tomorrow.
[21:14] <Ulfr_> Jellicent: I know that feel.
[21:14] <Jellicent> Ulfr_: I've tried for 6 hours straight now. :p Need something else.
[21:14] <Ulfr_> Jellicent: DEFINITELY know that feel.
[21:14] <Jellicent> I think food and watching a show is good.
[21:15] <Ulfr_> Jellicent: Consider a video game that teenagers play. Making them rage always makes me feel better
[21:15] <Jellicent> I already do that.
[21:15] <Jellicent> :D
[21:15] <Ulfr_> JEEB: does this sound correct at all? It looks like the program runs 3 times. It graps a jpg image from the video, the second and third actually make the flv happen
[21:15] <Jellicent> Ulfr_: I'll probably do that later, happily. ^_^
[21:16] <Ulfr_> Jellicent: It's my go-to for days like that
[21:16] <Jellicent> Hehehe. :D
[21:16] <Ulfr_> You know it's time to stop when some kid is sufficiently angry his voice sqeaks
[21:16] <Jellicent> Ahahaha. :d
[21:19] <JEEB> Ulfr_, yes -- although you could do the first pass of the 2pass encoding, and the jpg output together
[21:20] <Ulfr_> JEEB: I'm beginning to think I might have to do that. This is becoming a nightmare.
[21:40] <cassidy> hi there! I'm trying to dump the content of a rtsp stream (no transcoding) and get a lot of "Non-monotonous DTS in output stream 0:1" warnings. Is there something I can do to "fix" the file in a way I'll be able to properly transcode it later? Here is the full output with ffmpeg master: http://pastebin.com/88BVBrPD
[21:42] <Ulfr_> cassidy: I'm not very fluent in ffmpeg, but as far as I knew warnings didn't mean anything as far as impeding anything working right
[21:46] <cassidy> Ulfr_, ah ok. I was having some issues when transcoding to .webm afterwards and was assuming it was the reason
[21:46] <Ulfr_> JEEB: Okay. I give up. I'm just going to rewrite this ffmpeg call. Any chance you could direct me to an example of a fancy pants one pass run that also does that jpeg thing?
[21:47] <Ulfr_> cassidy: Hey, I have no idea to be perfectly honest. I've just never let warnings from something written for linux get me out of sorts. Those things are always warning me about stuff
[21:48] <cassidy> Ulfr_, as a developer myself, if I add a warning somewhere it's generally that things are going pretty wrong :)
[21:48] <Ulfr_> cassidy: you should've seen my box compile ffmpeg just recently then. there were hundreds of pages
[21:50] <cassidy> gcc warnings are differents from runtime ones
[00:00] --- Fri Dec 27 2013