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

[burek]

[00:00:09 CEST] <wallbroken> thank you
[00:00:11 CEST] <iive> however if you don't have keyframes every second, the start might be a little off
[00:00:52 CEST] <iive> depending on the duration of the keyframe interval.
[00:01:40 CEST] <iive> if you want exact cut, you'd have to re encode.
[00:02:16 CEST] <iive> aka, instead of -c copy, it would be -c:a copy -c:v libx264
[00:41:03 CEST] <wallbroken> [00:02] <iive> aka, instead of -c copy, it would be -c:a copy -c:v libx264
[00:41:04 CEST] <wallbroken> why?
[00:43:00 CEST] <DHE> because 'copy' can only start from a keyframe. if you want to start from a non-keyframe you need to re-encode
[00:43:50 CEST] <wallbroken> but if i'm lucky, the keyframe is near the cut point, right?
[00:45:52 CEST] <DHE> no harm in trying. see how it turns out
[02:08:03 CEST] <wallbroken> 32bit or 64bit?
[02:09:17 CEST] <furq> the n64 is more powerful but the playstation has better games
[02:09:36 CEST] <wallbroken> very fun
[02:09:45 CEST] <furq> yes, they are very fun
[02:31:03 CEST] <klaxa> n64 has smash bros. though
[02:31:26 CEST] <klaxa> probably my favorite fighting game
[02:41:20 CEST] <wallbroken> klaxa, sometime ago you told me a thing that it's not clear
[02:41:55 CEST] <klaxa> if you can repeat what i said and tell what you didn't understand we can probably clear that up
[02:42:15 CEST] <wallbroken> <klaxa> 32 bit will probably be unsupported earlier than 64 bit (just a guess)
[02:42:21 CEST] <wallbroken> this is what you said
[02:42:28 CEST] <wallbroken> and the question is: which would that mean?
[02:42:52 CEST] <klaxa> i'm guessing that maybe 10 years from now everybody will be on 64-bit
[02:43:20 CEST] <klaxa> but with all the guesses in computer science and technology in general i'm probably way off
[02:43:58 CEST] <wallbroken> and so? where is the incompatibility?
[02:44:22 CEST] <klaxa> non-existent, you will also be running 64-bit then :)
[02:44:33 CEST] <wallbroken> are you talking about the compatibility of the executable or about the output file?
[02:44:39 CEST] <klaxa> the executable
[02:44:50 CEST] <klaxa> the file will still be compatible
[02:45:38 CEST] <klaxa> there is not really a reason not to use 64-bit operating systems
[02:46:17 CEST] <klaxa> i think there are some slight performance differences
[02:46:28 CEST] <wallbroken> yes i know but there is no compatibility problem about the output file if it's produced with 32bit or 64
[02:46:42 CEST] <klaxa> usually negligible
[02:46:48 CEST] <klaxa> no
[02:47:09 CEST] <klaxa> video files are independent of the software that produced them
[02:47:46 CEST] <klaxa> you can watch youtube on a 32-bit system just as well as on a 64-bit system, right?
[02:47:53 CEST] <klaxa> they use the same files
[02:48:29 CEST] <wallbroken> yes, but i do not know anything about performances on reproducing 64bit output or 32
[02:49:24 CEST] <klaxa> it's really nothing to worry about
[02:49:33 CEST] <furq> how many times do we have to tell you it makes no difference before you stop asking
[02:50:17 CEST] <klaxa> oh color me surprised
[02:50:18 CEST] <klaxa> http://forum.doom9.org/showthread.php?t=147686
[02:50:27 CEST] <klaxa> seems like it *does* make a difference for x264
[02:50:35 CEST] <klaxa> this is from 2009 though
[02:51:26 CEST] <klaxa> if you really want to be sure run some benchmarks yourself
[02:53:37 CEST] <wallbroken> furq, when there is no difference, there is the problem: i do not know which one to use
[02:54:28 CEST] <klaxa> <klaxa> there is not really a reason not to use 64-bit operating systems
[04:24:17 CEST] <ytan> Hi there
[04:24:51 CEST] <ytan> I'm trying to see how to use rtsp streaming
[04:25:54 CEST] <ytan> One one console, I have: ffmpeg -rtbufsize 100M -re -f dshow -s 320x240 -i video="BisonCam, NB Pro" -r 10 -an -f rtsp -rtsp_transport tcp rtsp://127.0.0.1:8554/demo
[04:26:23 CEST] <ytan> and on another, I have
[04:26:24 CEST] <ytan> ffplay rtp://127.0.0.1:8554/demo
[04:27:53 CEST] <ytan> sorry, I have this: ffplay -rtsp_flags listen -i rtsp://127.0.0.1:8554/demo
[04:29:04 CEST] <ytan> I can see the connection established, and my webcam LED is turned on
[04:29:11 CEST] <ytan> but I get this message: real-time buffer [BisonCam, NB Pro] [video input] too full or near too full (97% of size: 100000000 [rtbufsize parameter])! frame dropped!
[04:30:11 CEST] <ytan> and I get a crash
[05:05:26 CEST] <ytan> hello...
[05:05:34 CEST] <ytan> anybody... here?
[05:10:32 CEST] Action: ytan drops a pin
[05:14:05 CEST] <VamoMenem> yea
[05:17:29 CEST] <VamoMenem> ytan try using rtbufsize 1M or less
[05:18:09 CEST] <VamoMenem> Note also that using dshow's "rtbufsize" has the unfortunate side effect of sometimes allowing frames to "buffer" while it is waiting on encoding of previous frames, or waiting for them to be sent over the wire. This means that if you use a higher value at all, it can cause/introduce added latency if it ever gets used (but if used, can be helpful for other aspects, like transmitting more frames
[05:18:09 CEST] <VamoMenem> overall consistently etc. so YMMV). Almost certainly if you set a very large value for this, and then see the "buffer XX% full! dropping!" message, you are introducing latency.
[05:18:09 CEST] <VamoMenem> There is also apparently an option -fflags nobuffer which might possibly help, usually for receiving streams reduce latency.
[05:19:19 CEST] <VamoMenem> and try to without -re option
[05:24:03 CEST] <VamoMenem> ls
[05:47:32 CEST] <ytan> thanks for the tip VamoMenem
[05:47:57 CEST] <ytan> tried this
[05:47:57 CEST] <ytan> ffmpeg -rtbufsize 10M -re -f dshow -s 320x240 -i video="BisonCam, NB Pro" -r 10 -an -f rtsp -rtsp_transport tcp rtsp://127.0.0.1:8554/demo
[05:48:04 CEST] <ytan> but it just crashes
[06:09:54 CEST] <VamoMenem> ffmpeg -rtbufsize 1M -f dshow -s 320x240 -i video="BisonCam, NB Pro" -r 10 -an -f rtsp -rtsp_transport tcp rtsp://127.0.0.1:8554/demo
[06:10:15 CEST] <VamoMenem> pastebin the crash ytan
[06:32:08 CEST] <MrDave20161> has anyone else noticed a problem with the pkg-config file libavutil.pc ?  It does not seem to be updated for the new lib requirements of version 3.1 from what I have seen.
[06:32:59 CEST] <mrelcee_> i had some joy with libavutil on my system after manually compiling ffmpeg.    couldn't conmpile the vlc port..
[06:33:16 CEST] <mrelcee_> library too new it said
[06:34:44 CEST] <MrDave20161> hmm...I needed to change the libs it used to get my app to compile.  Had to add  -lX11 -lvdpau -lva-drm -lva-x11 -lva
[06:36:12 CEST] <MrDave20161> just wondering if this is a common problem with 3.1 that others are seeing
[06:38:02 CEST] <mrelcee_> i am probably on a different platform than you - but i haven't heard of anything like that till you.
[06:47:25 CEST] <MrDave20161> Ok.  This was a 16.04 Xubuntu fresh install.  Completed the published instructions for Ubuntu and ffmpeg compiled fine.  When I then compiled my app using the pkg-config it failed (worked fine for version 3).  Looks like HW acceleration was added in 3.1 which needs these libs and they were not part of the pc file.
[06:47:58 CEST] <MrDave20161> thanks for the response.
[06:56:36 CEST] <mrelcee_> you are using the hw accelleration?
[07:11:49 CEST] <MrDave20161> I'm testing on all different platforms/versions and this is a VM machine so I'm not sure.  The app needs it to work whether it is enabled or disabled.
[07:20:16 CEST] <mrelcee_> if it's a VM i doubt hw acceleration is making it thru
[07:20:28 CEST] <mrelcee_> yeah it does.
[07:21:25 CEST] <mrelcee_> i can't keep track of all the forks of ubuntu any more
[07:23:30 CEST] <mrelcee_> I use ubuntu to refresh old laptops and desktop machines that shipped with XP to make usable web/email platforms for people wiho don't ahve a lot of money.     Sometimes I just donate them, especially if I get a referral from the women's shelter..    lotta people need basic computers so they can get jobs or communicate with family..
[12:21:56 CEST] <msk> Hello! I've just tried to compile ffmpeg on OS X 10.11.6 with no luck. ./configure does not find libmp3lame library version >= 3.98.3 (though, libmp3lame 3.99.5 is installed, like every other dependency, via homebew).
[12:22:05 CEST] <msk> What should I do?
[12:32:19 CEST] <msk> Found solution to my probem over here: https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=94
[12:32:22 CEST] <msk> Bye.
[15:10:59 CEST] <t4nk674> I am getting error in av_calloc
[15:11:16 CEST] <t4nk674> how to debug it? does it mean there is some memory leakage
[15:11:26 CEST] <t4nk674> segfault
[15:18:11 CEST] <t4nk674> can anyone please help, how to debug?
[15:20:55 CEST] <c_14> You're getting a segfault in av_calloc?
[15:21:14 CEST] <c_14> Is this the ffmpeg binary or your program?
[15:26:27 CEST] <fritsch> provide a backtrace from gdb
[15:26:28 CEST] <t4nk674> ffmpeg binary and I have added my custom decoder
[15:27:47 CEST] <t4nk674> sharing the gdb backtrace
[15:27:52 CEST] <t4nk674> 2 min
[15:28:19 CEST] <c_14> make sure you run gdb on ffmpeg_g otherwise you won't have any symbols
[15:31:27 CEST] <t4nk674> i dont have ffmpeg_g but added -g in makefile
[15:31:59 CEST] <t4nk674> I mean -g is there, so I should be getting debug symbols there and gdb
[15:32:05 CEST] <t4nk674> trace, is it correct
[15:32:06 CEST] <c_14> the important thing is --disable-stripping
[15:32:47 CEST] <t4nk674> yes
[15:41:38 CEST] <t4nk674> Err logs: http://paste.ubuntu.com/23097632/
[15:41:43 CEST] <t4nk674> please check
[15:44:12 CEST] <t4nk674> @fritsc @c_14 please check
[15:44:24 CEST] <fritsch> nothing to check there
[15:44:31 CEST] <fritsch> the issue is not in
[15:44:47 CEST] <fritsch> stack is broken before
[15:44:52 CEST] <fritsch> how do you use ffmpeg?
[15:46:28 CEST] <t4nk674> command line
[15:46:43 CEST] <fritsch> this is all what you do?
[15:46:47 CEST] <fritsch> with the above command line?
[15:46:57 CEST] <t4nk674> yes, providing you
[15:47:25 CEST] <t4nk674> ffmpeg -y -f mp4 -i ip_file.mp4 -vsync 0 out.yuv
[15:47:37 CEST] <fritsch> `ffmpeg -y -f mp4 -i bbb_sunflower_1080p_30fps_normal.mp4 -vsync 0 -f null /dev/' <- this i saw
[15:47:42 CEST] <fritsch> and could not make any sense of it
[15:47:56 CEST] <fritsch> no idea
[15:48:42 CEST] <t4nk674> -f null /dev/null is used to calculate performance of decoder
[15:49:22 CEST] <t4nk674> But this error is same as when used "ffmpeg -y -f mp4 -i ip_file.mp4 -vsync 0 out.yuv"
[15:49:57 CEST] <t4nk674> its failing on av_calloc ? Is this due to heap overflow !
[15:51:26 CEST] <fritsch> "heap overflow"?
[15:55:25 CEST] <t4nk674> means no memory available to alloc
[15:55:33 CEST] <t4nk674> is that so?
[16:05:14 CEST] <Spring> why does h.264 require heights divisible by two?
[16:06:44 CEST] <fritsch> cause the standard demands it :-)
[16:08:09 CEST] <fritsch> to why, see the answer by Adisak, that makes sense: http://stackoverflow.com/questions/20847674/ffmpeg-libx264-height-not-divisible-by-2
[16:08:55 CEST] <Spring> fritsch, interesting. Anything else I need to look out for?
[16:09:15 CEST] <Spring> if it weren't for accidentally coming across the error I wouldn't have known
[16:09:16 CEST] <fritsch> no idea, if you want to learn x264, check the standard more in detail
[16:10:16 CEST] <fritsch> ffmpeg's wiki is a good start
[16:10:21 CEST] <fritsch> talking about quality
[16:10:37 CEST] <fritsch> next step then is containers
[16:10:54 CEST] <fritsch> profiles before that of course - level 4.1 at high most player can play nowadays
[16:10:57 CEST] <fritsch> if not level 3.0
[16:13:10 CEST] <Spring> I wonder how many will think AV1 is AVI
[16:13:47 CEST] <fritsch> hehe
[16:13:55 CEST] <fritsch> how many will know what "avi" is :-)
[16:14:04 CEST] <fritsch> the windozers without file extensions have no idea
[16:16:07 CEST] <Spring> You could be right. There'll be a whole generation that wouldn't have even heard of it, as well.
[16:16:36 CEST] <fritsch> the next generation won't even know what "interlaced content" is
[16:23:29 CEST] <Mavrik> Thank all the gods for that :P
[16:58:50 CEST] <jazzy> New to ffmpeg so excuse if the question looks fairly basic. I am trying to extract ID3 tags from an AAC file using ffmpeg. The steps are to convert AAC to PCM and then to extract the ID3 tags. Any help on this would be highly appreciated.
[17:08:07 CEST] <Spring> anyone know what the source quality of PS4/Xbox native captures are? I know the PS4 has a native capture, assuming Xbox One does, too.
[17:09:00 CEST] <c_14> jazzy: ffprobe file -show_entries format_tags ?
[17:10:28 CEST] <jazzy> c_14: I get no output when I run that.
[17:11:19 CEST] <c_14> Then the file probably doesn't have any ID3 tags
[17:19:18 CEST] <jazzy> c_14: Thanks. How would I convert thta to a PCM file?
[17:20:11 CEST] <c_14> ffmpeg -i file out.pcm
[17:20:19 CEST] <c_14> eh
[17:20:23 CEST] <c_14> ffmpeg -i file -f s16le out.pcm
[17:26:44 CEST] <jazzy> c_14: Im getting this output. http://pastebin.com/jyAiyvTL
[17:30:12 CEST] <c_14> ffmpeg -i aac/Test1.acc -f s16le out.pcm
[17:34:39 CEST] <jazzy> c_14: still getting the same output as pasted in pastebin earlier.
[17:35:09 CEST] <c_14> It should look at least a bit different now though
[17:35:13 CEST] <c_14> Can you pastebin the output again?
[17:35:26 CEST] <jazzy> Sorry. Got a different output. Pasting it.
[17:38:53 CEST] <jazzy> c_14: This is the output. It did create a pcm file. http://pastebin.com/1YF9Sibm
[17:39:45 CEST] <jazzy> But there are quite a few errors while executing.
[17:40:00 CEST] <c_14> yeah, it really doesn't like the input aac file
[18:03:40 CEST] <Conder> hello, i have audio stream in .AC3, its from 25 fps DVD. i want convert it to 23.976 fps. can i do it in ffmpeg?
[18:04:12 CEST] <JEEB> yes
[18:04:19 CEST] <c_14> Under the assumption that you're slowing down the video or under the assumption that you're dropping frames?
[18:04:20 CEST] <JEEB> see the list of audio filters
[18:05:36 CEST] <Conder> JEEB: u mean this? https://ffmpeg.org/ffmpeg-filters.html
[18:05:41 CEST] <Conder> there isnt anything about AC3
[18:05:55 CEST] <JEEB> of course not because you have to decode the audio :P
[18:06:10 CEST] <JEEB> and thus it's a standard audio filter
[18:13:12 CEST] <Conder> JEEB: u mean decode to WAV, then run it through ffmpeg with --fps 25 and then encode to AC3 again?
[18:14:32 CEST] <JEEB> well since audio doesn't have a frame rate you just use the filter that switches the audio rate (since I will guess that the 25fps thing was made from speeding up the 24/1.001 fps one), and then if you for whatever reason want to have the output in AC3, then yes
[18:15:53 CEST] <JEEB> ffmpeg -i hurr.ac3 -af filter=parameters out.file
[18:16:20 CEST] <JEEB> I don't do such editing myself so I don't know which audio filter is best suited for this, but atempo seems like one thing :P
[18:16:36 CEST] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#Examples-46
[18:17:10 CEST] <c_14> If you want to preserve pitch use atempo, otherwise asetrate
[18:19:36 CEST] <Conder> okay im going try it. thx
[18:27:03 CEST] <markg1> I can't make ffmpeg go faster, I have 20 input files trying to convert to h264 but it has taken more than 1 day, the sad part is, I do have a greate cpu and ram but it doesnt use more than %23 of my cpu, I enabled thread -4 and I also ran 4 instance of the ffmpeg stilll is not using more than %23 of my cpu. any idea?
[18:27:29 CEST] <JEEB> depends on which decoders and encoders you're using :P
[18:27:36 CEST] <JEEB> and other things such as settings
[18:27:41 CEST] <markg1> -c:v libx264  -preset superfast -crf 25 -c:a aac  -threads 4
[18:28:02 CEST] <markg1> what other settings would u add to that ?
[18:28:04 CEST] <JEEB> post full command line and terminal output on a pastebin, then link here
[18:31:24 CEST] <markg1> @JEEB http://pastebin.com/1zwTGW83
[18:34:22 CEST] <markg1> so I am converting from mjpeg to h264
[18:34:45 CEST] <JEEB> I'd prefer an uncut thing of what I requested. but first of all,try doing `ffmpeg -i /input/your_thing.avi -f null -`
[18:34:50 CEST] <JEEB> see how quickly that goes
[18:36:45 CEST] <JEEB> also you don't need to set threads for encoding with libx264 - it picks according to the amount of your virtual cores automagically
[18:37:08 CEST] <JEEB> so the only function of setting threads is to *limit* them for libx264
[18:37:43 CEST] <markg1> @JEBB I only set threads when I saw it wasnt using cpu before having it
[18:38:09 CEST] <JEEB> well now I told you that setting threads after -i with libx264 makes no difference unless you want to *limit* it :P
[18:38:27 CEST] <JEEB> (after -i meaning for encoding, the placement of settings matters in that sense in ffmpeg cli)
[18:38:45 CEST] <JEEB> so yes, just try how quickly you can decode that thing in general with your thingg
[18:38:53 CEST] <JEEB> I gave you a sample of how to check that
[18:40:47 CEST] <markg1> @JEBB allright the null thing is 9X
[18:41:03 CEST] <markg1> without null other wise its is 0.4X upt to 1X
[18:41:12 CEST] <markg1> and cpu usage is sitll less than 17%
[18:41:31 CEST] <markg1> so with null the speed goes up. cpu usage no.
[18:41:46 CEST] <JEEB> basically the -f null one is how fast you can "just decode" the tracks :P
[18:41:58 CEST] <markg1> gotcha
[18:42:30 CEST] <markg1> so is there anything I can do to make ffmpeg use my cpu ? I even tried to move my files to my SSD I though the HDD was the bottleneck
[18:42:51 CEST] <JEEB> if you mean faster for a single file than with -f null, then no
[18:43:27 CEST] <JEEB> -f null one is pretty much the maximum, and then after that it goes through any sort of possible filters and through to the encoder/muxer
[18:44:50 CEST] <markg1> no I didnt meant that. when I dont do null, and I do the actual file ouptput it is max 1 X
[18:44:56 CEST] <markg1> but mostly 0.2X
[18:45:06 CEST] <markg1> with null it is 9X
[18:45:09 CEST] <JEEB> how fast does `ffmpeg -i /input/file.avi -an -c:v libx264 -preset superfast -f null -` go?
[18:45:17 CEST] <markg1> can I make my actual thing to be faster than 1 ?
[18:45:45 CEST] <JEEB> that encodes the video and skips the audio track
[18:45:49 CEST] <JEEB> and skips muxing
[18:46:14 CEST] <markg1> ok will try thanks
[18:47:11 CEST] <markg1> what does -an do ?
[18:47:26 CEST] <JEEB> "audio none" (ignores input audio)
[18:47:39 CEST] <JEEB> thus you're only encoding video
[18:48:42 CEST] <markg1> gotcha. but still makes me sad that ffmpeg doesnt use all my cpu, when I had a shitty laptop everyone said just go get a nice cpu, I got extreme core i7 and a 32 GB RAM
[18:48:47 CEST] <markg1> and still encoding slow
[18:49:10 CEST] <markg1> I wish ffmpeg would have used all my cpu
[18:49:39 CEST] <JEEB> x264 is not perfect but unless it's blocked by something else it's utilizing modern CPUs pretty darn well :P
[18:52:00 CEST] <JEEB> markg1: so how is just video encoding without writing or audio? :P
[18:52:39 CEST] <markg1> will that that in a minute
[18:53:37 CEST] <markg1> it is still pretty low  speed=0.884x
[18:53:42 CEST] <markg1> depressing...
[18:54:21 CEST] <JEEB> post full command line and terminal output on a pastebin
[18:54:24 CEST] <Spring> what are you encoding?
[18:54:39 CEST] <JEEB> Spring: 1440x1080 MJPEG
[18:54:44 CEST] <JEEB> at 30fps
[18:55:39 CEST] <iive> check if the heat sinc haven't detached. the cpu may overheat and throttle down.
[18:56:30 CEST] <JEEB> yeah, I would make sure it's actually keeping the CPU speed up even when under load
[18:56:35 CEST] <iive> `sensors` should be able to show cpu temperature.
[18:57:04 CEST] <iive> and powertop shuold be able to show the clock speeds and idle times.
[18:57:45 CEST] <markg1> iive are you talking to me ?
[18:57:56 CEST] <markg1> I checked the cpu usage using top, it is like 18%
[18:57:58 CEST] <Spring> 0.8 is bad? I'd say it's pretty good
[18:58:12 CEST] <markg1> Spring thats same as when I had a shitty laptop
[18:58:16 CEST] <markg1> now I have a full blown imac
[18:58:19 CEST] <markg1> with core i7
[18:58:42 CEST] <markg1> obviosuly encoding is taking a lot of computations but ffmpeg is not using all my cpu to do the computations
[18:58:53 CEST] <markg1> I think ffmpeg can do a better job using parallel algorirthms
[18:59:01 CEST] <JEEB> but yeah, make sure you're not getting downclocked :P
[18:59:06 CEST] <JEEB> under load
[18:59:28 CEST] <markg1> I dont think iMac core i7 ships with downclocked
[18:59:32 CEST] <Spring> I have an i5-4670K 3.4Ghz, 8GB memory, 970 GPU and get speeds lower than that for 1440p content
[18:59:42 CEST] <markg1> I even moved the files to SSD to make sure it is not harddisk stopping cpu
[18:59:47 CEST] <JEEB> Spring: it's not 1440p
[18:59:52 CEST] <JEEB> it's 4:3 1080p
[18:59:56 CEST] <JEEB> so even less than 1920x1080
[19:00:01 CEST] <Spring> oh right
[19:00:15 CEST] <Spring> misread the 1440 resolution
[19:00:35 CEST] <JEEB> markg1: not about shipping with downclock but actually downclocking due to the cooler or whatever not keeping up :P just make sure your CPUs are still at full speed and that the core temps are good
[19:01:59 CEST] <Spring> encoding an Apple trailer at 1440px wide it's about 1.3x on average
[19:04:22 CEST] <JEEB> that really depends on your configuration and how fast the input decoder is
[19:04:26 CEST] <JEEB> and some other things
[19:04:40 CEST] <Spring> just btw markg1 this is from the command line directly or via a front end with command line option input?
[19:04:54 CEST] <markg1> my cpu temp is normal CPU temp: 47.875°C
[19:05:06 CEST] <markg1> yeah it is commandline
[19:05:11 CEST] <markg1> through a for loop in a bash script
[19:05:18 CEST] <JEEB> markg1: check your cpu core speeds and what CPU you have
[19:06:09 CEST] <markg1> I stopped the scripts I willl check in a few minutes
[19:06:16 CEST] <Spring> I had this strange issue with a Windows ffmpeg front end that accepted CLI options and it was limiting the encoding speed dramatically. It wasn't until I began using my own script that I realized the difference.
[19:06:27 CEST] <JEEB> uhh, you were running stuff in the background?
[19:06:33 CEST] <JEEB> while testing speeds?
[19:06:53 CEST] <markg1> what do you mean running stuff in background
[19:07:00 CEST] <markg1> I only had chrome open chatting with you
[19:07:05 CEST] <JEEB> ok
[19:07:07 CEST] <markg1> but now I killed all the scripts
[19:07:12 CEST] <JEEB> wait what
[19:07:12 CEST] <markg1> not encoding at the moment
[19:07:26 CEST] <JEEB> so were you actually encoding in the background when testing the commands I noted?
[19:07:37 CEST] <markg1> no
[19:07:40 CEST] <JEEB> ok
[19:07:44 CEST] <markg1> but one thign I tried was
[19:07:52 CEST] <markg1> I dvided my files into 4 folders
[19:07:55 CEST] <markg1> and I ran 4 instances of ffmpeg
[19:08:06 CEST] <markg1> to see if they will eventually be faster in paralell
[19:09:32 CEST] <JEEB> anyways, find out your CPU type and speed and if it keeps speed while under load (x264)
[19:12:41 CEST] <markg1> I am pretty sure it is not my cpu, after buying a whole new computer just because ppl told me it is my cpu
[19:12:55 CEST] <markg1> and it is not a laptop that heats up it isa desktop
[19:13:12 CEST] <markg1> anyways In my previous notes I had one option -b:a 192k
[19:13:15 CEST] <markg1> what does -b:a 192k  do ?
[19:13:23 CEST] <markg1> should I add that back to my script maybe that makes it fater?
[19:13:24 CEST] <Spring> sets the audio bitrate
[19:13:25 CEST] <markg1> faster*
[19:13:44 CEST] <JEEB> it just sets the audio bit rate but since you say it's slow with just the video encoding then that has nothing to do with it :P
[19:14:15 CEST] <JEEB> also stop being so self-confident, make sure you're OK and know exactly what sort of hardware you have before going forward
[19:15:05 CEST] <iive> markg1: can we see your full command line ?
[19:15:27 CEST] <JEEB> the MJPEG decoding speed is not quick (if you say 9x speed at 30fps it's 270fps)
[19:15:34 CEST] <Spring> oh I forgot, I also set my script to slower, hence why my speeds are slower (obvs)
[19:15:42 CEST] <JEEB> yeah, this was with superfast
[19:15:58 CEST] <JEEB> I mean his under-realtime results
[19:15:59 CEST] <markg1> ffmpeg -i /input/$f -c:v libx264  -preset superfast -crf 25 -c:a aac /output/$f.mp4
[19:16:21 CEST] <JEEB> iive: he's posted information on the results of decoding-only and video encoding-only tests here, too :P
[19:17:38 CEST] <JEEB> markg1: anyways I don't think there's any reason to continue this discussion until you provide some information so we can gauge expectations and other things
[19:18:36 CEST] <JEEB> anyways, going for a run - brb
[19:19:56 CEST] <markg1> allright. let me know what other information you guys need
[19:20:06 CEST] <markg1> I will check the cpu core speed later when I re-run the script
[19:20:09 CEST] <JEEB> I think I've noted it a few times already :P
[19:20:16 CEST] <iive> you said it is imac, is it desktop or laptop?
[19:20:22 CEST] <markg1> iMac
[19:20:28 CEST] <JEEB> what hardware, what speed is it running at during load
[19:20:32 CEST] <markg1> iMac is techincally a desktop because it doesnt have battery
[19:20:42 CEST] <JEEB> as in CPU type, CPU speeds under load
[19:20:43 CEST] <markg1> core i7
[19:20:53 CEST] <JEEB> yeah, sure
[19:20:57 CEST] <JEEB> mine is i7 as well
[19:21:02 CEST] <JEEB> but mine has the marking 4790K
[19:21:09 CEST] <JEEB> which is quite different from many other i7s
[19:21:19 CEST] <markg1> Intel(R) Core(TM) i7@ 3.40GHz
[19:21:32 CEST] <JEEB> yeah, that misses the main part :P
[19:21:38 CEST] <JEEB> aka the model
[19:21:46 CEST] <markg1> Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
[19:21:47 CEST] <Spring> IIRC there's an extended system info in the About item of the Apple menu
[19:22:04 CEST] <markg1> check out the benchmark for Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz on cpu benchmarks
[19:22:11 CEST] <markg1> it is one of the highest
[19:22:20 CEST] <markg1> except it uses more power than new i7s
[19:22:46 CEST] <JEEB> is that really the CPU you have or are you just throwing things around again?
[19:22:46 CEST] <markg1> anyway, we cant say it is because of my cpu, if it is not even using more than 26% of my cpu
[19:22:52 CEST] <JEEB> jesus christ...
[19:23:01 CEST] <markg1> when did I ever throw things arround ?
[19:23:05 CEST] <markg1> why would I lie to you?
[19:23:15 CEST] <markg1> jesus christ...
[19:23:15 CEST] <markg1> $ sysctl -n machdep.cpu.brand_string Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
[19:23:18 CEST] <JEEB> because you think you know things, because you assume things
[19:23:22 CEST] <JEEB> thank you
[19:23:33 CEST] <markg1> what makes you think I Assume things ?
[19:24:08 CEST] <JEEB> like the way you are saying that it can't be your CPU even though you haven't checked basic things yet (does the CPU keep its speed under load etc)
[19:24:11 CEST] <markg1> what makes you think, I only think I know things...
[19:24:26 CEST] <Spring> interestingly my i5 performs better
[19:24:28 CEST] <JEEB> because this is clearly not your familiar thing
[19:24:34 CEST] <JEEB> s/thing/setting/
[19:24:53 CEST] <markg1> you are being condesesnign and not helpful
[19:24:56 CEST] <JEEB> ok, so it's a quad core at 3.4GHz. thank you very much for providing that information
[19:24:56 CEST] <markg1> I am leaving this chat.
[19:25:01 CEST] <Spring> perhaps the Mac is limiting the CPU power
[19:25:12 CEST] <JEEB> Spring: that's one possibility, or it's just not getting cooled properly
[19:25:22 CEST] <JEEB> or the build is built without threading somehow
[19:25:28 CEST] <markg1> I posted the cpu temprature
[19:25:29 CEST] <Spring> not sure how large those inbuilt fans are
[19:25:30 CEST] <markg1> it is 47
[19:25:34 CEST] <markg1> it is bellow average
[19:25:39 CEST] <JEEB> markg1: yeah but that doesn't say what your CPU is doing to keep it there
[19:25:54 CEST] <Mavrik> Note that when macs start overheating you see a "kernel_task" using a lot of CPU
[19:25:55 CEST] <JEEB> that's the point. something in your system can tell you at which speed your CPU is running and show it on screen
[19:26:10 CEST] <Mavrik> (It's how thermal throttling shows up in OSX)
[19:26:19 CEST] <Spring> fwiw my CPU is idling at around 33c
[19:26:27 CEST] <JEEB> and you just make sure that even when running the video encode test (-c:v libx264 -f null -an one) it's keeping on that speed
[19:26:30 CEST] <Spring> but I'm guessing that is load
[19:26:36 CEST] <markg1> anywas, I just wanted to note here that ffmpeg does a horrible job being parallel. I dont wanna continue this discussion. bye
[19:26:42 CEST] <JEEB> hah
[19:26:50 CEST] <JEEB> there goes my wasted time
[19:27:07 CEST] <JEEB> some people really don't understand they're being helped
[19:27:11 CEST] <Spring> APPLE USERS AMIRITE
[19:27:22 CEST] <JEEB> the OS really doesn't matter
[19:27:28 CEST] <JEEB> idiots are everywhere idiots
[19:27:33 CEST] <Mavrik> Indeed, ffmpeg works wonderfully on OSX :P
[19:27:46 CEST] <Mavrik> Or timOS or whatever they renamed it now to make people feel better.
[19:28:29 CEST] <Spring> did they buy the iMac /just/ for the encoding?
[19:28:42 CEST] <JEEB> a '11 CPU bearing iMac at that
[19:28:50 CEST] <JEEB> so he didn't use too much money on that :P
[19:29:13 CEST] <JEEB> funny enough if he wanted used he could have just taken one of those 2x E5 2670 setups
[19:29:15 CEST] <Mavrik> Could be worse, could be C2D :P
[19:29:22 CEST] <JEEB> and get 2x 20MiB sandy-es
[19:29:30 CEST] <JEEB> probably not for much more money even
[19:45:27 CEST] <JEEB> Mavrik: I actually did encoding with a C2D from '08 to '13
[19:45:43 CEST] <JEEB> before that it was a dual core Turion64
[19:47:53 CEST] <Mavrik> Well that was a current CPU at that time
[20:00:05 CEST] <mrelcee_> dont' take it all out on apple users.  a few of us have clues  :)
[20:00:25 CEST] <Mavrik> <-- apple user
[20:00:59 CEST] <dave`> I'm intending to use ffmpeg to stream content from a well-known website which uses webm (vp9) encoding. How do I tell ffmpeg to digest this encoding?
[20:02:06 CEST] <Mavrik> ffmpeg will recognise the format and decode it
[20:02:10 CEST] <Mavrik> What's the actual problem?
[20:02:34 CEST] <JEEB> vp9 decoder is included in default configuration, and the matroska demuxer as well (in which VP9 usually is)
[20:02:36 CEST] <dave`> I wasn't sure if I could speed things up by specifying the exact encoding.
[20:02:48 CEST] <JEEB> in an API using thing, maybe
[20:02:54 CEST] <JEEB> with ffmpeg not likely
[20:03:04 CEST] <JEEB> I guess this is about ffmpeg probing for a while
[20:03:39 CEST] <dave`> I consider my question answered; thanks.
[20:07:50 CEST] <iive> JEEB: markg1 problem is indeed very strange, since ffmpeg/x264 doesn't seem to be using threading. I do suspect that it is some kind of OS problem, or something missing at compilation.
[20:08:15 CEST] <JEEB> probably the binary was weird
[20:08:28 CEST] <JEEB> I was trying to see if threading or asm was disabled, but it didn't seem to be
[20:08:42 CEST] <JEEB> since he posted a single pastebin at least with some terminal output
[20:09:15 CEST] <JEEB> it was really weird because it looked like an ubuntu build (had 16.04 or whatever noted as well)
[20:09:20 CEST] <iive> threading might not be disabled in configure, but simply not detected...
[20:09:41 CEST] <JEEB> I would think that would be a "please make sure you're OK with this" level of stuff :P
[20:09:46 CEST] <JEEB> like asm on x86
[20:09:48 CEST] <iive> heh...
[20:09:59 CEST] <JEEB> you have to really set --disable-asm for it to configure
[20:17:37 CEST] <DHE> or not have yasm (?) installed
[20:18:01 CEST] <DHE> that's an error, right?
[20:27:10 CEST] <mrelcee_> i would be shocked if he built it himself on osx.  probably downloaded it..
[20:27:31 CEST] <JEEB> DHE: that's what I noted :)
[20:27:50 CEST] <JEEB> not having yasm or nasm will make x264 and FFmpeg configure derp and ask if you are really sure
[22:51:30 CEST] <kyleogrg> I've downloaded a bunch of YouTube videos having vp9 codec, sorted by various resolutions.  I have used the plotframes script to get these OVERALL bitrate statistics.
[22:52:29 CEST] <MINIMAN10000> Alright so what did I actually run? "ffmpeg -i in.mp4 -ss 00:15:55 -t 00:16:20 -async 1 cut.mp4"
[22:52:31 CEST] <kyleogrg> http://pastebin.com/hEbFMph4
[22:52:43 CEST] <kyleogrg> Please have a look if you're interested.
[22:52:43 CEST] <MINIMAN10000> I wanted to start at 15 minutes 55 seconds and end at 16 minutes 20 seconds
[22:52:49 CEST] <ChocolateArmpits> kyleogrg: Youtube does some neural analysis to determine best bitrate for each paralelyzed segment
[22:52:59 CEST] <MINIMAN10000> Is that what I did... or... did I start at 15:55 and run for 16 minutes?
[22:53:18 CEST] <dl2s40> MINIMAN10000, -t is duration afaik
[22:53:24 CEST] <MINIMAN10000> FFFFF
[22:53:27 CEST] <ChocolateArmpits> MINIMAN10000: use -to instead of -t
[22:53:37 CEST] <ChocolateArmpits> then it'll work as you expect
[22:53:37 CEST] <kyleogrg> ChocolateArmpits: I'm trying to approximate the youtube bitrates for my own much smaller-scale project
[22:54:34 CEST] <ChocolateArmpits> kyleogrg: hmm the lower bitrates really use vp9?
[22:55:00 CEST] <kyleogrg> ChocolateArmpits: yeah!  at least i was able to get 'em with youtube-dl
[22:55:17 CEST] <MINIMAN10000> neat
[22:55:29 CEST] <MINIMAN10000> I only remember hearing the 4k videos using 4k
[22:55:35 CEST] <MINIMAN10000> er use vp9
[22:56:08 CEST] <kyleogrg> So, the question now is how do I translate this into a command for libvpx-vp9
[22:56:15 CEST] <MINIMAN10000> I wonder why it stalls for like 15 seconds before it begins encoding
[22:56:29 CEST] <kyleogrg> I probably want to use Constrained Quality for this (http://wiki.webmproject.org/ffmpeg/vp9-encoding-guide)
[22:56:57 CEST] <MINIMAN10000> I've always just been a fan of using max bitrate but that's mainly cause it's transmitted over the internet
[22:57:19 CEST] <MINIMAN10000> and quality is of little concearn
[22:57:33 CEST] <MINIMAN10000> at least I don't feel the need to constrain it.
[22:57:39 CEST] <kyleogrg> MINIMAN10000: i hear ya
[22:57:54 CEST] <MINIMAN10000> Usually 1500 kbps as an average is "good enough" in my use case.
[22:57:55 CEST] <kyleogrg> but i'm just trying to copy youtube here, just kind of experimentally
[22:58:17 CEST] <kyleogrg> 480p for instance
[22:58:20 CEST] <MINIMAN10000> I was experimenting to have a low latency stream
[22:58:22 CEST] <MINIMAN10000> I failed miserably.
[22:58:29 CEST] <MINIMAN10000> the latency was not low enough
[22:58:59 CEST] <kyleogrg> for 480p the very max bitrate i found (across hundreds of videos) was 3660.
[22:59:02 CEST] <kyleogrg> kbps
[22:59:19 CEST] <kyleogrg> does that mean i should set vp9 to have a max of 3660?  then what about crf?
[22:59:28 CEST] <MINIMAN10000> wat
[22:59:30 CEST] <MINIMAN10000> holy crap
[22:59:43 CEST] <BtbN> I wouldn't be surprised if they have their own private encoder.
[22:59:47 CEST] <MINIMAN10000> is that normal for 480p?
[22:59:47 CEST] <dl2s40> some videos just need more bitrate
[22:59:58 CEST] <MINIMAN10000> for 480p I use like... 800 kbps?
[23:00:02 CEST] <kyleogrg> BtbN: yeah... but then, vp9 is theirs to begin with
[23:00:18 CEST] <ChocolateArmpits> MINIMAN10000: peak bitrate may mean just a short burst at the start of a video
[23:00:27 CEST] <MINIMAN10000> oh right constrained
[23:00:34 CEST] <kyleogrg> MINIMAN10000: what codec? cuz vp9 uses less than x264 for instance
[23:00:40 CEST] <MINIMAN10000> I dono I usually just stick with 1080 1500kbps vp9
[23:01:06 CEST] <MINIMAN10000> but this video i'm working on now I just used whatever the defaults it gave me were for a quick and easy encode.
[23:01:13 CEST] <kyleogrg> And here's another thing, the avg bitrate across all 480p vids is 207 kbps.
[23:01:17 CEST] <ChocolateArmpits> kyleogrg: start out with simple -b:v 200k without setting any other ratecontrol
[23:02:06 CEST] <ChocolateArmpits> youtube encodes per content, so more motion will have more assigned more bits on their system
[23:02:08 CEST] <furq> this makes me wonder where youtube-dl pulls its bitrate info from
[23:02:20 CEST] <furq> it looks to be way off
[23:02:33 CEST] <kyleogrg> ChocolateArmpits: if it's per content, isn't that like crf?
[23:03:23 CEST] <dl2s40> 1080p at 1500 kbps?? well i dont no much about vp9 but i would say for x246 1500 kbps sounds about right for SD content
[23:03:58 CEST] <kyleogrg> furq: well, i just used youtube-dl to download vids based on codec and resolution.  later i used ffprobe and plotframes to look at bitrate.
[23:04:54 CEST] <MINIMAN10000> I'm quite happy I learned that -to is a command. now I can save that to a file and go back to playing games.
[23:05:24 CEST] <ChocolateArmpits> kyleogrg: well it sort would be closer to dynamic crf with maxrate
[23:05:38 CEST] <ChocolateArmpits> like crf getting set for each segment separately
[23:05:40 CEST] <kyleogrg> the vp9 guide recommends two-pass for best quality, but i wonder why.  i only use two-pass with x264 using crf
[23:05:59 CEST] <ChocolateArmpits> well that's because you will get the most out of your encode
[23:06:20 CEST] <kyleogrg> how does that work, because it's just using a bitrate setting, not crf
[23:06:24 CEST] <kyleogrg> why not just one pass
[23:07:46 CEST] <ChocolateArmpits> it assigns bits according to the whole video rather than the current time mark
[23:07:52 CEST] <dl2s40> is two pass really better?
[23:07:54 CEST] <kyleogrg> ahh
[23:08:26 CEST] <kyleogrg> even with their best quality setting, they have a speedy first pass.  you think it would be much better with a slow first pass?
[23:10:13 CEST] <ChocolateArmpits> kyleogrg: the 2nd pass only need specific data, rest of that is dropped so might as well turn off feature on the 1st pass
[23:11:00 CEST] <kyleogrg> ok
[23:11:26 CEST] <kyleogrg> with libopus, should i use vbr or b:v for streaming?
[23:11:31 CEST] <furq> http://vpaste.net/2JqGa
[23:11:37 CEST] <furq> i have no idea where it's getting 1603k from
[23:11:48 CEST] <furq> i wonder if that's the max bitrate or something
[23:16:24 CEST] <kyleogrg> i wonder why the avg bitrate for both 480p and 360p was about 200k
[23:16:43 CEST] <kyleogrg> whereas 240p was 70k and 144p was 60k
[23:59:36 CEST] <viric> furq: I wanted to share my HT results... HT helps in x264 encoding (+8% faster than without the extra cpu thread), and it helps even more in less simd-optimized tasks (pigz, +21% faster). But it introduces latencies, because for two threads to run 120% compared to one, both have to run at 60%.
[00:00:00 CEST] --- Sun Aug 28 2016