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

[burek]

[00:00:14 CEST] <Plorkyeran_> lossless formats may also differ, but less often
[00:08:32 CEST] <kepstin> the encoded lossless stream might vary, but it'll be the same once you decode it again ;)
[00:28:27 CEST] <justinmrkva> Quick question. I have a large amount of 8K video in ProRes 422 and I need to convert it to H.264 in FFmpeg. Unfortunately, it doesn't work. It does not play in QuickTime (it says it's damaged), and in VLC, it drops to below 1 fps and shows severe corruption.
[00:29:43 CEST] <justinmrkva> The command I'm using is 'ffmpeg -i in.mov -c:v libx264 -c:a aac out.mp4'
[00:48:58 CEST] <justinmrkva> Here's the command and output: http://pastie.org/10868502
[01:09:25 CEST] <greenbagels> Is there any (experimental) support for libvpx's experimental vp10 encoder/decoders?
[01:13:40 CEST] <greenbagels> i saw in some cross-compile script that --enable-vp10 --enable-vp10-encoder --enable-vp10-decoder might be some possible configuration args?
[01:16:08 CEST] <greenbagels> no, that didn't work, heh
[01:16:11 CEST] <jnorthrup> wouldnt google just stick it in ffmpeg?
[01:16:32 CEST] <TD-Linux> greenbagels, it's now moved to its own repository, it's AV1 now
[01:16:46 CEST] <TD-Linux> and I have a bunch of API breaks queued so it wouldn't make sense for ffmpeg to support it yet
[01:17:16 CEST] <greenbagels> TD-Linux: av1 eh?
[01:17:49 CEST] <TD-Linux> alliance video 1. kind of a dumb name but not really worse than vp :)
[01:18:43 CEST] <greenbagels> TD-Linux: could you point me to a link for it? and do you mean google made it its own repository separate from libvpx?
[01:19:31 CEST] <greenbagels> oh i see
[01:19:42 CEST] <greenbagels> google combined with a bunch of partners to make an open source media container
[01:19:52 CEST] <greenbagels> and much of vp10's development went into this new codec, av1
[01:23:48 CEST] <utack> greenbagels https://aomedia.googlesource.com/aom
[01:23:57 CEST] <utack> and they are hanging out in #aomedia
[01:24:05 CEST] <greenbagels> utack: yeah, after some digging, i found it just now too, heh
[01:24:07 CEST] <greenbagels> thanks
[01:26:30 CEST] <TD-Linux> yup, and bugtracker is here where I've listed some planned API changes https://bugs.chromium.org/p/aomedia/issues/list
[01:30:25 CEST] <greenbagels> TD-Linux: much obliged, i'll play around with it in a bit :)
[02:17:48 CEST] <Demon_Fox> TD-Linux, What did you mean by queued?
[02:18:07 CEST] <Demon_Fox> When I asked about an updated x264 version
[02:24:31 CEST] <TD-Linux> Demon_Fox, it ran now. you can click it and compare to the old version. it's in "experimental runs"
[02:31:47 CEST] <Demon_Fox> TD-Linux, What's it listed as?
[02:32:20 CEST] <TD-Linux> x264-2016-06-06-ntt-short-1
[02:33:02 CEST] <Demon_Fox> Thanks
[02:33:47 CEST] <Demon_Fox> It does a narrow margin better than it did before
[02:34:11 CEST] <Demon_Fox> Oddly, it makes x265 look quite pathetic
[02:34:21 CEST] <Demon_Fox> x264 in general that is
[02:35:26 CEST] <Demon_Fox> TD-Linux, The latest master for Daala makes the graph disappear
[02:45:01 CEST] <TD-Linux> it was probably not complete yet
[02:45:19 CEST] <TD-Linux> Demon_Fox, the default metric is FastSSIM. I think PSNR-HVS gives a better comparison between x264 and x265
[02:47:01 CEST] <TD-Linux> (it really depends on content though, no metric is perfect)
[02:50:21 CEST] <Demon_Fox> FastSSIM is pretty good
[02:51:15 CEST] <Demon_Fox> Thank for adding the new version
[09:28:58 CEST] <yagiza> Hello!
[09:29:38 CEST] <yagiza> Keep fighting with RTP streaming/playing...
[09:30:58 CEST] <yagiza> I have some success: can successfuly cast and play RTP stream. But not with every codec.
[09:32:26 CEST] <yagiza> Some codecs (like iLBC) just crash my streaming app on attempt to encode frame.
[09:32:53 CEST] <yagiza> Others (some PCMs) jut fail to play.
[09:58:51 CEST] <nifwji2> puu.sh/pkXtf/a46687c872.html
[09:58:58 CEST] <nifwji2> APNG vs GIF
[11:03:17 CEST] <f00bar80> just a question please , the following script http://vpaste.net/MIXgl should keep on trying to start ffmpeg till successful right ?
[11:41:19 CEST] <termos> ffmpeg -i <input> -f dash <codec options> Manifest.mpd, is this the correct way to create live dash streams using FFmpeg?
[11:41:33 CEST] <termos> it seems like the -f dash is not documented anywhere, but it's there
[11:55:07 CEST] <theeboat> I am having issues when i try and transcode pcm audio into a m2ts/ts container using ffmpeg. Once the file has finished ffprobe shows an audio channel with the aac codec, if i try and open the file in VLC the audio track does not show. Does anybody have any ideas why this may be happening?
[12:47:53 CEST] <Sokolio> <theeboat> I assume you're explicitly encoding as AAC?
[14:17:04 CEST] <carli> Hi, have one question if someone have an idea. I stream mp4 with no transcoding to RTMP Ustream (-re -c copy -f flv). I check ffmpeg log and file is streamed ok, but Live video drops before the end?
[14:25:12 CEST] <BtbN> mp4 is not streamable.
[14:25:29 CEST] <BtbN> But that looks like you are streaming flv?
[14:26:41 CEST] <JEEB> BtbN: it is. movie fragments
[14:27:14 CEST] <BtbN> No it's not. The header is written once the file is finished. So you can't stream it before that.
[14:27:24 CEST] <BtbN> Making a lot of 2 second files is not streaming it.
[14:27:43 CEST] <JEEB> it's not whole files, it's a part of the container called a fragment
[14:27:50 CEST] <JEEB> of course it's not MPEG-TS streamable
[14:28:04 CEST] <JEEB> MPEG-TS is specifically made only for A-B transmission
[14:28:28 CEST] <BtbN> well, it works, to some degree, with basically every container, except for mp4.
[14:28:40 CEST] <JEEB> ...
[14:28:59 CEST] <JEEB> you have a very fucking skewed view at things if you think what other containers do is OK but then movie fragments is not OK
[14:29:15 CEST] <JEEB> it's the same as whatever it is called in matroska for example
[14:29:20 CEST] <BtbN> you can't easily stream your "movie fragments" to some streaming server.
[14:29:27 CEST] <BtbN> It's a hack to make mp4 useable at all.
[14:29:37 CEST] <JEEB> yes, you can. and streaming servers take in fragmented ISOBMFF
[14:29:43 CEST] <JEEB> for example I deal with some of such
[14:30:01 CEST] <JEEB> the fact that public facing things tend to use RTMP is a whole different discussion
[14:30:17 CEST] <JEEB> and then very low-latency and in-UDP broadcast is MPEG-TS anyways
[14:32:24 CEST] <JEEB> also funny enough, the damn streaming servers don't usually seem to take in MPEG-TS, but rather RTMP or some sort of fragmented ISOBMFF. I have no idea why. I think I would have quite a few less issues if they did ;)
[14:32:48 CEST] <JEEB> (for OTT streaming servers that is)
[14:33:10 CEST] <carli> Uf, that force flv works just fine!
[14:33:21 CEST] <BtbN> Well, rtmp essentialy is flv.
[14:33:28 CEST] <JEEB> yeah
[14:33:36 CEST] <JEEB> it's a container made for the protocol and protocol made for it pretty much
[14:34:12 CEST] <BtbN> carli, make sure that -re is in front of your -i
[14:34:20 CEST] <carli> it is
[14:34:41 CEST] <carli> It's strange that sometime stream is ok, sometime is cuted
[14:34:55 CEST] <carli> No line drops or anything ..
[14:35:05 CEST] <BtbN> I'd guess that's the streaming server stopping the output the moment the input ends, even if there is still some data to send.
[14:35:35 CEST] <carli> streaming server doesn't know when it's end of the input
[14:35:43 CEST] <carli> or there are some signals ?
[14:35:55 CEST] <BtbN> Well, the stream ends there, so of course it knows?
[14:36:37 CEST] <carli> Well there is 10 to 12 seconds delay
[14:37:16 CEST] <carli> any buffer solution or something like that ..
[14:37:34 CEST] <BtbN> So if the input ends, and it cuts the output immediately, that delay is lost.
[14:40:10 CEST] <carli> No it's some random stuff, I can't find out. Ustream records all streams, and if check that dropped stream, video is OK. Sometime video is cutted in front.
[14:49:37 CEST] <BtbN> I'd blame ustream for that.
[14:49:44 CEST] <BtbN> Add some emptyness at the beginning/end.
[15:28:42 CEST] <theeboat> sokolio: my source is aac but i was transcoding the audio to be pcm audio.
[15:40:49 CEST] <Sokolio> <theeboat> Are you sure mpeg2TS can carry PCM audio? As far as I remember it was either mpeg audio, aac or ac3
[15:46:41 CEST] <Sokolio> M2TS stream type of 0x83 says LPCM Audio, it's worth checking in PMT whether there is an audio stream with StreamType=0x83
[16:04:35 CEST] <theeboat> yeah thats what i read that it supports LPCM audio.
[16:05:08 CEST] <theeboat> ive just opened the file with tsreader and there doesnt see to be any audio streams
[16:05:28 CEST] <theeboat> which is strange considering it shows audio when i use ffprobe
[16:45:34 CEST] <Sokolio> @theeboat could you pastebin some output of ffprobe?
[16:57:29 CEST] <TiTE> hello all
[16:59:28 CEST] <vade> Hi - Dev question: -Im attempting to use the loudnorm filter via the AVFIlter API. I have a normal filter chain set up with a buffer source, sink, and a filter or two in between. When I add the loudnorm filter (along with a log callback to fetch the output) - I see the filter set up, but my buffer source always gets EAGAIN - removing the loudnorm filter works perfectly and samples are passed through. Since loudnorm is a analysis filter
[16:59:29 CEST] <vade> there a slightly different than standard programatic filter set up for it unlike a transcode pipeline?
[17:02:11 CEST] <durandal_1707> That means it needs more data
[17:03:34 CEST] <ATField> Trying to re-encode a particular file returns "element type mismatch 3 != 0", which AFAI found out has to do with incorrectly encoded AAC stream. How can this issue be circumvented if -ar 48k (as suggested here https://trac.ffmpeg.org/ticket/5163) didnt change anything?
[17:04:26 CEST] <ATField> Converting that 6ch a-stream through Audacity first and using the result as the second input (-map 0:0 -map 1) didnt work either.
[17:08:05 CEST] <vade> durandal_1707: im aware of the error, however, I feed it the entire file until I get EOF
[17:08:17 CEST] <vade> and it never outputs any samples from my buffer sink -
[17:08:32 CEST] <vade> also, removing loudnorm - and my other filters work correclty
[17:09:05 CEST] <vade> in other words, I might get a few EAGAINs if I dont use loudnorm filter in my chain
[17:09:12 CEST] <vade> but after a packet or two it works.
[17:09:15 CEST] <vade> doh :(
[17:09:43 CEST] <vade> but after a packet or two it works (cc @durandal_1707 ) - however, adding loudnorm in I get a continuous stream of eagain's
[17:09:53 CEST] <durandal_1707> vade: even dynaudnorm?
[17:10:06 CEST] <vade> I havent tried that filter
[17:10:12 CEST] <vade> i need to use EBUr128 spec however
[17:10:49 CEST] <vade> unaware of dynaudionorm does that
[17:11:00 CEST] <durandal_1707> if same its bug in your code
[17:11:09 CEST] <vade> ah I see your point
[17:11:15 CEST] <vade> ok. Ill try dynnorm to see if I can re-create
[17:11:20 CEST] <vade> thank you durandal_1707  :)
[17:26:43 CEST] <vade> durandal_1707: dynaudionorm seems to work :X
[17:27:15 CEST] <durandal_1707> hmm
[17:28:24 CEST] <vade> im a liar. Sorry. I looked at the wrong log
[17:28:48 CEST] <vade> Hrm. Ok. So dynaudio is not working, but other filters do. Clearly im implementing how I handle EAGAIN then
[17:29:10 CEST] <vade> clearly im wrong in EAGAIN wrong rather. man my brain is fried
[17:29:15 CEST] <vade> ;lkajf;aklsdfj holy shit.
[17:29:23 CEST] Action: vade needs a break and its only 11:30
[18:21:29 CEST] <P4Titan> Hi all
[18:21:56 CEST] <P4Titan> Should I use 1 avio context for both the input and output contexts are should I use separate io conexts for each?
[18:29:40 CEST] <vade> you should use seperate contexts
[18:36:14 CEST] <vade> durandal_1707: I cant find this error. To be clear - I have a buffer source as the first source on my filter chain. I have a sink on the output. Inside is a dynaudio or a loudnorm filter. Im calling av_buffersrc_add_frame_flags with AV_BUFFERSRC_FLAG_PUSH, shoving an audio frame in. I call av_buffersink_get_frame_flags with AV_BUFFERSINK_FLAG_NO_REQUEST. I also , just to debug, manually call avfilter_graph_request_oldest.
[18:36:14 CEST] <vade> Everytime I get a EAGAIN error, I add another frame. What circumstances would the av_buffersink_get_frame_flags continuously return EAGAIN?
[19:39:24 CEST] <durandal_1707> vade: but do you check if there is something to take?
[19:39:51 CEST] <durandal_1707> sink should not be empty
[19:41:00 CEST] <ATField> (repost) Trying to re-encode a particular file returns "element type mismatch 3 != 0", which AFAI found out has to do with incorrectly encoded AAC stream. How can this issue be circumvented if -ar 48k (as suggested here https://trac.ffmpeg.org/ticket/5163) didnt change anything?
[19:41:06 CEST] <ATField> Converting that 6ch a-stream through Audacity first and using the result as the second input (-map 0:0 -map 1) didnt work either.
[19:54:43 CEST] <atomnuker> ignore the warning, it'll be removed in git master soon
[19:55:09 CEST] <atomnuker> it happens on he-aac with an lfe channel and is expected, it's not an error
[20:06:30 CEST] <VarunAgw> Hi, I am new to ffmpeg. I need to generate instant thumbnail of short FLV video by duration. I am getting ~250ms processing time with my current approach. Is there any way I can optimize it further.
[20:06:46 CEST] <VarunAgw> time ./ffmpeg -ss 00:04:14.435 -i "1.flv" -filter scale=50:50 -vframes 1 -f image2pipe - 2>/dev/null >/dev/null
[20:06:56 CEST] <BtbN> sounds like a perfect result to me?
[20:07:19 CEST] <VarunAgw> But it not instant. I want that if possible
[20:07:59 CEST] <VarunAgw> I want to avoid processing thumbnails in advance
[20:08:35 CEST] <c_14> video files don't (really) support random access
[20:08:40 CEST] <c_14> So you're not going to get instant
[20:08:51 CEST] <c_14> and you're also scaling the image
[20:08:54 CEST] <c_14> Which also won't be instant
[20:09:03 CEST] <BtbN> I'm actually surprised it's that fast.
[20:09:28 CEST] <VarunAgw> haha! Me too BtbN. I didn't expected that
[20:09:57 CEST] <VarunAgw> c_14: For some unknown reason, it tool less time for me with scaling
[20:10:10 CEST] <BtbN> you can probably speed it up by making sure you decode an I-Frame, but that's about it.
[20:10:43 CEST] <VarunAgw> Does it compress image by default. Maybe I can disable that? Or use a different file format (e.g. png) for output if it is faster
[20:11:30 CEST] <kepstin> png is kinda slow to compress. if your app can handle it, raw image in some form would be fastest.
[20:11:48 CEST] <Chocola1> go bmp
[20:12:53 CEST] <c_14> the fastest would be to select an I-frame in the input and then throw out that single frame with -c copy
[20:13:09 CEST] <BtbN> I wouldn't call that a thumbnail.
[20:13:33 CEST] <c_14> But it would be the fastest solution
[20:18:48 CEST] <jbmcg> hey there - I'm trying to append to an HLS playlist (m3u8), adding .ts segments on the fly. The problem I'm running into is that the timestamps or something don't line up when I append and the audio keeps going while the video stalls
[20:20:06 CEST] <VarunAgw> I don't know what I-frame is. I am planning of creating a working demo of my approach to decide if it is fast enough for me or not. By the way anybody have clue how to output it in bmp format?
[20:20:47 CEST] <kepstin> VarunAgw: '-c:v bmp'
[20:21:13 CEST] <jbmcg> I've tried concatting with the previous .ts file and trimming of the end with -copyts selected. It worked for 1 (though i couldn't get it to trim at the right spot) but everything after that keeps stalling still. I'm trying to avoid needing all the .ts files to update the playlist
[20:22:12 CEST] <jbmcg> I tried using -setpts to try and offset the timestamps of the .ts file I'm trying to append, but that doesn't seem to be affecting output files frames at all (just looking at the PTS info of each frame with ffprobe)
[20:23:25 CEST] <jbmcg> The dream is to have the playlist hosted on Amazon S3 and just be able to add .ts files to it on the fly to build a massive playlist
[20:25:06 CEST] <jbmcg> is there a way to force the starting timestamp of a video?
[20:26:49 CEST] <VarunAgw> ok thanks kepstin
[20:29:22 CEST] <kepstin> jbmcg: you can maybe just use the EXT-X-DISCONTINUITY flag in the playlist file to signal to the player that the timestamps reset.
[20:32:41 CEST] <jbmcg> cool - I'll give that a try
[20:35:17 CEST] <wallbroken> the reencoding of the input audio source is the same as the input? or there is a default one?
[20:36:22 CEST] <ATField> atomnuker: (sorry for replying late) Id ignore it if all it did was give the warnings and proceed with the rest normally, but an [-ss -to] encoding that shouldve taken at most a minute or so keeps being processed for 10+ minutes without a result.
[20:36:39 CEST] <c_14> wallbroken: default for each audio container
[20:37:16 CEST] <c_14> s/audio //
[20:38:25 CEST] <wallbroken> so, if the source is 320, the output will be 320?
[20:38:35 CEST] <c_14> no
[20:38:47 CEST] <c_14> There's a default audio codec for each output format and a default bitrate/quality level for each audio codec.
[20:38:50 CEST] <wallbroken> which bitrate is by default for mp3?
[20:38:57 CEST] <c_14> 128k I think
[20:39:01 CEST] <wallbroken> ok
[20:39:11 CEST] <c_14> If you want something specific, specify it.
[20:39:37 CEST] <wallbroken> i don't know in re-encoding lossless wich output quality could be the best tradeoff
[20:39:42 CEST] <wallbroken> can you suggest me something?
[20:39:48 CEST] <wallbroken> *lossy
[20:39:51 CEST] <wallbroken> not lossless
[20:40:16 CEST] <c_14> assuming the input and output codecs are the same, just use the same bitrate
[20:40:31 CEST] <wallbroken> ok
[20:40:55 CEST] <kepstin> with lossy input - just use -c:a copy if you can get away with it...
[20:41:04 CEST] <wallbroken> and which quantity of information will be loss?
[20:41:05 CEST] <wallbroken> 50% ?
[20:41:29 CEST] <kepstin> wallbroken: hard to say. depends on codec, which encoder was used on original, etc.
[20:41:58 CEST] <wallbroken> -c:a copy  can't be used because in my case i need to use -atempo
[20:43:01 CEST] <kepstin> ah. well, then it's just up to you to figure out an output bitrate that provides sufficient quality :/
[20:44:55 CEST] <vade> hi @durandal_1707 - sorry stepped out for a moment. how do I check if there is something to take? use av_buffersink_get_frame_flags + AV_BUFFERSINK_FLAG_PEEK ?
[20:52:13 CEST] <durandal_1707> just usual way to take anything available
[20:54:15 CEST] <jbmcg> kepstin: couldn't get that work btw, doesn't seem to be supported in a lot of players
[21:04:13 CEST] <vade> yea @durandal_1707 I do try to take anything available :X
[21:05:08 CEST] <durandal_1707> but in same loop where you receive eagain
[21:08:09 CEST] <vade> No - basically. I do something like pseudo code : read packet -> deduce stream -> send packet -> receive frame -> av_buffersrc_add_frame_flags -> av_buffersink_get_frame_flags
[21:08:29 CEST] <vade> if I cant av_buffersrc_add_frame_flags I bail and read another packet
[21:08:39 CEST] <vade> if I cant av_buffersink_get_frame_flags I bail and read another packet
[21:09:05 CEST] <vade> I also manually fire avfilter_graph_request_oldest
[21:09:35 CEST] <vade> but, it looks like FFMPEG.c reads the output of the filter chain first, then feeds it? Am correct it pulls from sinks prior to feeding them?
[22:20:43 CEST] <feliwir> is there a way to compile ffmpeg on windows (with msvc) without pretending a linux system like msys2/cygwin etc.
[22:21:16 CEST] <feliwir> maybe a msvc makefile or something?
[22:29:29 CEST] <BtbN> "Pretending to be a linux"? configure is a bash script, so you need bash and various standard tools.
[22:29:38 CEST] <BtbN> so msys/cygwin is the best way to get those.
[22:49:21 CEST] <feliwir> BtbN, yeah but maybe there is a buildsystem more native to windows?
[22:52:10 CEST] <JEEB> I'm really sorry but the most that MSVS's project files do are glorified makefiles
[22:52:25 CEST] <JEEB> you throw right into the trash bin the whole configuration part
[22:52:40 CEST] <JEEB> people usually just do scripts with that, and you know what... shell scripts are script files!
[22:52:48 CEST] <JEEB> so no, no banana for MSVS project files
[22:53:47 CEST] <JEEB> just get a shell and GNU Make, make sure MSVC's link and cl tools are around and build FFmpeg with MSVC like everyone else
[23:11:43 CEST] <feliwir> JEEB, well i can get a shell and all that stuff but it's really a slow way to compile on windows^^
[23:12:07 CEST] <BtbN> why should make on windows be slower than anywhere else?
[23:12:18 CEST] <feliwir> starting msvc prompt->running msys promt from there to have msvc compiler in PATH->configure & make
[23:12:34 CEST] <BtbN> make yourself a shortcut
[23:12:34 CEST] <feliwir> BtbN, it isn't slower but it takes many steps to get into bash
[23:13:10 CEST] <feliwir> BtbN, there is no portable shortcut because Visual Studio Install directory & msys install directory may vary on different systems
[23:13:24 CEST] <BtbN> That's why you make it yourself
[23:16:00 CEST] <JEEB> MSVC tools are always under a specific env var
[23:16:36 CEST] <JEEB> call "%VS140COMNTOOLS%vsvars32.bat"
[23:16:49 CEST] <feliwir> BtbN, i want a script for building on every windows system lol
[23:17:03 CEST] <JEEB> calling that bat basically sets the MSVC env vars
[23:17:11 CEST] <BtbN> You want a script to open a bash shell with the MSVC vars set.
[23:17:27 CEST] <feliwir> JEEB, oh that is nice
[23:17:44 CEST] <JEEB> the 140 is different per MSVC version of course
[23:17:53 CEST] <JEEB> I think that's either 2015 or 2013
[23:17:58 CEST] <JEEB> probably 2015 :P
[23:18:08 CEST] <feliwir> its 2015 yup :)
[23:18:12 CEST] <JEEB> but you can check if variables are defined etc
[23:18:17 CEST] <JEEB> if you want to support multiple :P
[23:20:58 CEST] <BtbN> I just made myself an alias in cygwin bashrc, so i open cygwin, enter vc64 or vc32, and have all the vars set.
[23:21:39 CEST] <wallbroken> default mp3 encoding of ffmpeg is cbr or vbr?
[23:23:25 CEST] <vade> man I have no idea wtf im doing wrong to not feed dynaudnorm filter correctly
[23:24:19 CEST] <kepstin> wallbroken: looks like 128kbit abr.
[23:24:39 CEST] <wallbroken> abr ?
[23:24:41 CEST] <wallbroken> what is it?
[23:24:50 CEST] <kepstin> "average bitrate"
[23:25:19 CEST] <kepstin> so it makes the file average 128kbit, but allows a little variation locally
[23:26:34 CEST] <kepstin> if you're using libmp3lame encoder, you can set it to an actual vbr mode with -q:a, e.g. '-q:a 4' (maps to the same values as the -V option on the standalone lame encoder)
[23:27:26 CEST] <wallbroken> i want to keep the input mp3 settings
[23:27:52 CEST] <kepstin> that doesn't really make sense, particularly if you're doing audio processing.
[23:28:11 CEST] <kepstin> just pick a set of output settings that are sufficient quality for your needs.
[23:28:49 CEST] <drv> if you're re-encoding mp3, it's gonna sound bad no matter what you do
[23:29:58 CEST] <kepstin> well, you can always just throw lots of bits at the output, and then it won't sound noticably worse than the input
[23:32:20 CEST] <kepstin> if you actually need to use mp3, i'd just use '-q:a 4'; that's the default of the standalone lame and gives usually around 150-160kbit on music. Should sound decent, and be small enough for most streaming media.
[23:35:20 CEST] <wallbroken> it's the audio of a film
[23:39:11 CEST] <feliwir> i believe that someday ffmpeg will get cmake scripts
[23:39:16 CEST] <feliwir> and then i'll die happy
[23:40:19 CEST] <c_14> I rather doubt that
[23:40:55 CEST] <feliwir> don't take all my hope please
[23:41:07 CEST] Action: c_14 takes your hopes
[23:41:08 CEST] <c_14> and your dreams
[23:41:15 CEST] Action: feliwir is sad
[23:41:51 CEST] Action: feliwir doesn't know who has time to wait 5 minutes for configure to finish
[23:42:09 CEST] <c_14> And you think cmake is faster?
[23:42:39 CEST] <feliwir> c_14, i never needed longer than 10s for any configuring in cmake
[23:42:44 CEST] <wallbroken> if i want 128 CBR ?
[23:42:45 CEST] <feliwir> with projects comparable in size
[23:43:25 CEST] <BtbN> Try not running it on an RPi
[23:43:49 CEST] <feliwir> ^^ i5-4670k
[23:43:54 CEST] <feliwir> it slow as fuck
[23:44:00 CEST] <BtbN> Also, it's not slower than cmake because it's bash. It's slow because it does a lot of test-compiles.
[23:44:06 CEST] <feliwir> and there isn't even console output for a while
[23:44:13 CEST] <BtbN> doing those in cmake would take about the same time.
[23:45:16 CEST] <feliwir> BtbN, and why it would do those test compiles? you can do that in your test suite
[23:45:22 CEST] <feliwir> fate or however it's called :D
[23:45:35 CEST] <BtbN> no.
[23:46:04 CEST] <BtbN> If you want to check if some API works like you expect it to work, you compile (and run) a small test code.
[23:46:43 CEST] <feliwir> an option to disable those checks in configure available?
[23:47:24 CEST] <BtbN> --disable-all i guess...
[23:48:52 CEST] <feliwir> well thats a useful option
[23:49:12 CEST] <BtbN> Not really.
[23:50:34 CEST] <JEEB> that doesn't disable most of the checks
[23:50:46 CEST] <JEEB> also the configure script feels slow on windows because it does a lot of fork()
[23:51:13 CEST] <JEEB> it just literally  disables everything in FFmpeg and your compiled binary is completely and utterly useless
[23:51:16 CEST] <JEEB> also
[23:51:27 CEST] <BtbN> I think it primarily feels slow because it has no output before it's done.
[23:51:49 CEST] <JEEB> your cmake using projects most probably did not do as many checks or have as many things available for possible compilation based on 3rd party libraries
[23:52:07 CEST] <JEEB> but yes, cmake outputs while the thing runs and probably does less fork()
[23:52:17 CEST] <JEEB> which is emulated in really slow manner on windows in many cases
[23:52:59 CEST] <BtbN> That might change soon though.
[23:53:26 CEST] <JEEB> well Windows already has it in an undocumented sense and latest cygwin I think uses that feature
[23:53:39 CEST] <JEEB> the linux subsystem is completely separate from windows user space
[23:53:48 CEST] <BtbN> No it doesn't.
[23:53:52 CEST] <JEEB> uhh
[23:53:55 CEST] <BtbN> It's too incomplete.
[23:54:05 CEST] <BtbN> Stuff breaks if you use it.
[23:54:22 CEST] <drv> configure takes ~16 seconds here on a i5-3570K on Linux... if it really takes 5 minutes on Windows, something is broken
[23:54:23 CEST] <JEEB> probably true indeed, it just always gets mentioned in various places
[23:54:38 CEST] <JEEB> not 5 minutes here even with MSVC
[23:54:45 CEST] <feliwir> i was wondering if i should use WSL to just cross-compile ffmpeg
[23:54:46 CEST] <BtbN> But with the new reverse-wine, they must have implemented a true fork.
[23:54:47 CEST] <JEEB> but yes, closer to a minute or so for configure
[23:54:57 CEST] <feliwir> problem is that i can't link the produced binary with msvc
[23:55:06 CEST] <BtbN> of course you can?
[23:55:17 CEST] <BtbN> But, just don't use MSVC.
[23:55:19 CEST] <BtbN> at all
[23:55:27 CEST] <BtbN> cross-compiling is way more convenient.
[23:55:29 CEST] <feliwir> BtbN, normally i can't link binaries not compiled with msvc to msvc^^
[23:55:35 CEST] <JEEB> feliwir: static libs with mingw-w64 is kind of wonky, but shared libs work JustFine
[23:55:50 CEST] <Plorkyeran_> I would say that configure "feels slow" because it takes longer to run than the build itself on windows
[23:55:57 CEST] <JEEB> yes
[23:56:01 CEST] <Plorkyeran_> the lack of progress updates while it's running is rather secondary to that
[23:56:28 CEST] <JEEB> the whole fork()'ing thing makes it slooow, also sometimes the gratuitious usage of temp files, maybe?
[23:56:43 CEST] <JEEB> someone should profile it for the laughs
[23:56:49 CEST] <Plorkyeran_> also just that it's single-threaded
[23:56:57 CEST] <Plorkyeran_> while the build itself is embarrasinly parallel
[23:57:15 CEST] <JEEB> BtbN: I think this was the pretty good article on WSL https://blogs.msdn.microsoft.com/wsl/2016/04/22/windows-subsystem-for-linux-overview/
[23:58:12 CEST] <JEEB> Plorkyeran_: yeah you can just make -j and weeee it goes
[23:58:17 CEST] <JEEB> even on windows
[23:58:24 CEST] <BtbN> they claim to do cow stuff, so I hope it's fast.
[23:58:24 CEST] <JEEB> the configure step is just what it is
[00:00:00 CEST] --- Thu Jun  9 2016