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

[burek]

[00:09:43 CEST] <rcombs> eventually you run out of xmms
[00:09:50 CEST] <rcombs> but you'd need a lot of args :P
[00:18:28 CEST] <Gramner> floats in assembly are mainly annoying due to microsoft complicating everything for no reason other than to be obnoxius and make platform-independent code harder to write. on win64 float args affects how integer args are passed which makes no sense whatsoever but that's how it is
[00:19:49 CEST] <Gramner> the win64 abi is just a clusterfuck. there are plenty of smart engineers at msft so I have no idea how they managed to come up with something that bad
[00:21:05 CEST] <Gramner> especially since the system V abi (which is much better) was widely used at that point so they can't even blame mistakes on being early adoptors
[00:26:27 CEST] <nevcairiel> maybe it felt simpler to always pass 4 arguments with a fixed index->reg mapping, even if it limits you to passing less things
[00:27:26 CEST] <alevinsn> system V ABI also has something called the red zone for simple functions
[00:27:43 CEST] <iive> i'm sure they thought that they are doing something smarter.
[00:27:48 CEST] <nevcairiel> win64 has shadow space, although its smaller then the red zone
[00:28:15 CEST] <Gramner> yes, system V has the red zone. win64 has the shadow space, which just feels like a worse implementation of the same concept
[00:28:51 CEST] <Gramner> also who thought it was a good idea to make the majority of vector regs (which are mostly used in leaf functions) callee-saved?
[00:38:26 CEST] <Gramner> early version of the win64 abi actually disallowed the use of mmx and x87 registers which was interesting but they backtracked on that. I think it would've been better in the long run if they'd stuck with that
[00:39:09 CEST] <nevcairiel> that would've been interesting
[00:39:16 CEST] <nevcairiel> although painful at first i'm sure
[00:44:36 CEST] <rcombs> what is the red zone/shadow space anyway
[00:45:39 CEST] <nevcairiel> pre-allocated stack space guaranteed by the ABI you can just use for local variables without worrying about making your own space
[01:09:55 CEST] <nevcairiel> (in debug builds some compilers also use the shadow space to park function arguments that are otherwise passed as regs so debuggers can read those more easily, not sure if unix-y compilers also use the red zone for that)
[01:11:35 CEST] <Chloe> How far behind are the merges? 
[01:15:18 CEST] <jamrial> Chloe: ~400 commits or so i think
[01:22:30 CEST] <alevinsn> nevcairiel:  Regarding the Coverity issue
[01:22:46 CEST] <alevinsn> this doesn't have anything to do with MSVC as this particular Coverity build used gcc
[01:22:49 CEST] <alevinsn> and presumably on Linux
[01:23:04 CEST] <alevinsn> anyone know if the latest code builds on Linux/gcc/g++?
[01:23:31 CEST] <alevinsn> I can switch over to Linux
[01:23:39 CEST] <alevinsn> I mean, with a normal build, not a Coverity build
[01:23:56 CEST] <BtbN> you can use the coverity docker container, and do a normal build in it
[01:24:18 CEST] <BtbN> But in general, the coverity build is a normal build, just with all the deps being enabled at once, which is pretty rare
[01:24:33 CEST] <alevinsn> ok, then there is a good chance that the normal build fails as well
[01:25:12 CEST] <BtbN> It's on Ubuntu 16.10
[01:25:24 CEST] <alevinsn> yeah, that's what I have on the Linux partition
[01:25:30 CEST] <alevinsn> on my Linux partition
[01:25:56 CEST] <BtbN> see https://github.com/FFmpeg/FFmpeg-Coverity for the exact environment
[01:29:58 CEST] <jamrial> alevinsn: you need to configure with --assert_level=2 to trigger the failing code
[01:31:16 CEST] <alevinsn> ah
[01:33:00 CEST] <jamrial> no wait, --assert-level=2 according to the help output
[01:33:16 CEST] <alevinsn> my examination of the code in thread.h
[01:33:25 CEST] <alevinsn> would tend to indicate that the assert level isn't relevant here
[01:33:39 CEST] <alevinsn> oops
[01:33:41 CEST] <alevinsn> wrong
[01:33:43 CEST] <jamrial> assert level needs to be > 1 to get the "strict" functions
[01:33:53 CEST] <alevinsn> ok, I see that in thread.h
[01:34:22 CEST] <alevinsn> so, it doesn't appear that this patch "broke" the build per se
[01:35:33 CEST] <jamrial> well, it broke decklink on builds using assert level 2 :p
[01:35:54 CEST] <alevinsn> on gcc at a minimum
[01:36:09 CEST] <alevinsn> but, I wonder how much is going to be broken with assert level set to 2 on MSVC....
[01:36:21 CEST] <alevinsn> I would suspect that that isn't tested so much, if at all
[01:36:22 CEST] <jamrial> anyway, both command line options work. help only mentions one, though
[01:37:07 CEST] <BtbN> well, there's a coverity build with those settings every other day
[01:37:12 CEST] <jamrial> and it shouldn't. assert level 1 and 2 just enable more calls to assert() on speed critical code afaik
[01:43:15 CEST] <alevinsn> only relevant if have pthreads
[01:43:16 CEST] <alevinsn> duh
[01:43:38 CEST] <alevinsn> in thread.h
[01:45:39 CEST] <alevinsn> but, if I put the relevant code in the w32pthreads section of thread.h
[01:45:42 CEST] <alevinsn> I get a similar error
[01:46:09 CEST] <alevinsn> a parenthesized type followed by an initializer list is a non-standard explicit type conversion syntax
[09:15:14 CEST] <ubitux> that next merge commit is actually more broken that i initially though
[09:23:39 CEST] <nevcairiel> still the alsa thing?
[09:24:29 CEST] <nevcairiel> it looks so simple :)
[09:27:10 CEST] <ubitux> alsa/sndio/jack
[09:33:41 CEST] <cone-389> ffmpeg 03Diego Biurrun 07master:1818a640cfdc: build: Fix dependencies for alsa/jack/sndio support
[09:33:41 CEST] <cone-389> ffmpeg 03Clément BSsch 07master:9ae1ffe64126: Merge commit '1818a640cfdccd52e97edf13564f45bc3d0d93eb'
[09:39:17 CEST] <cone-389> ffmpeg 03Diego Biurrun 07master:a7101eb40e69: configure: Simplify some library checks via check_lib()
[09:39:18 CEST] <cone-389> ffmpeg 03Clément BSsch 07master:3675f545e720: Merge commit 'a7101eb40e69ada3872ec5aebe9c5c165745fb3a'
[09:41:32 CEST] <cone-389> ffmpeg 03Diego Biurrun 07master:0507cd5b9f3c: build: Rename host_libs/HOSTLIBS variables to host_extralibs/HOSTEXTRALIBS
[09:41:33 CEST] <cone-389> ffmpeg 03Clément BSsch 07master:0a0517bbf511: Merge commit '0507cd5b9f3c3769645bc6e9177eaf760f490d1c'
[10:04:58 CEST] <cone-389> ffmpeg 03Clément BSsch 07master:0ba67a8eb1ca: build: remove special freetype check
[10:09:49 CEST] <ubitux> that next merge looks semantically wrong&
[10:10:15 CEST] <ubitux> pkg-config --libs doesn't raise "extra" libs of the given pkg, it gives them libs
[10:10:32 CEST] <ubitux> are these build commits really reviewed?
[10:10:37 CEST] <nevcairiel> no
[10:10:43 CEST] <nevcairiel> they broke all sorts of shit that gets fixed later
[10:10:58 CEST] <ubitux> that's so annoying
[10:11:02 CEST] <nevcairiel> (or not, still regressions to this day)
[10:11:50 CEST] <ubitux> i won't merge most of the next commit, it's incorrect
[10:12:37 CEST] <nevcairiel> isnt that just a rename
[10:13:29 CEST] <ubitux> yes but it's semantically incorrect
[10:14:05 CEST] <ubitux> sdl_libs are not the extra libs of sdl, it's the libs of sdl
[10:14:25 CEST] <nevcairiel> its extralibs for av/ffplay
[10:14:31 CEST] <nevcairiel> just depends on your point of view, i guess
[10:14:39 CEST] <ubitux> for this one it's correct
[10:14:44 CEST] <ubitux> that's the only thing i planed to merge
[10:14:57 CEST] <nevcairiel> i wouldnt get upset about names of things
[10:15:05 CEST] <nevcairiel> maybe having it consistent is a good thing
[10:15:06 CEST] <ubitux> but look, it's changing openssl_libs (we don't have this one but we do have gcrypt_libs typically)
[10:15:38 CEST] <ubitux> so should i merge anyway?
[10:16:51 CEST] <ubitux> gcrypt_libs or sdl_libs make much more sense than gcrypt_extralibs or sdl_extralibs
[10:17:06 CEST] <ubitux> or am i just bikeshedding for nothing?
[10:17:16 CEST] <nevcairiel> its up to you, but I would, not merging something  and potentially m aking it harder later  based on some phylosophical naming debate seems not worth it
[10:18:29 CEST] <ubitux> ok, i'll rename everything then
[10:18:32 CEST] <ubitux> but fuck it anyway :(
[10:26:29 CEST] <cone-389> ffmpeg 03Diego Biurrun 07master:be2d555c9802: build: Use _extralibs variable names instead of _libs everywhere
[10:26:30 CEST] <cone-389> ffmpeg 03Clément BSsch 07master:9bf3d8408937: Merge commit 'be2d555c980220e65d0ca5c3d78e6cc1e24451a5'
[10:27:11 CEST] <cone-389> ffmpeg 03Diego Biurrun 07master:39fbcf8f76ff: configure: Fix _libs vs. _extralibs oversight
[10:27:12 CEST] <cone-389> ffmpeg 03Clément BSsch 07master:806f5b0b0ba0: Merge commit '39fbcf8f76ff2e7cd8d09307e6aacc70ce8f5fed'
[10:27:51 CEST] <cone-389> ffmpeg 03Diego Biurrun 07master:f8a1ead0ae44: build: Add -D_XOPEN_SOURCE=600 to CPPFLAGS on Cygwin
[10:27:52 CEST] <cone-389> ffmpeg 03Clément BSsch 07master:15bca8c67dfe: Merge commit 'f8a1ead0ae4402df0503c83f213f57b785a5f20f'
[10:28:33 CEST] <cone-389> ffmpeg 03Mark Thompson 07master:ade370a4d7ea: lavfi: Add VAAPI deinterlacer
[10:28:34 CEST] <cone-389> ffmpeg 03Clément BSsch 07master:9142b04bba45: Merge commit 'ade370a4d7eab1866b6023c91c135d27c77ca465'
[10:29:14 CEST] <cone-389> ffmpeg 03Mark Thompson 07master:7d81698b8917: vaapi_h265: Fix CFR mode with framerate set in AVCodecContext
[10:29:15 CEST] <cone-389> ffmpeg 03Clément BSsch 07master:cc8cafae8775: Merge commit '7d81698b89172d2dcf1b78d4b42ba86262360559'
[10:34:24 CEST] <cone-389> ffmpeg 03Diego Biurrun 07master:ac648bb835ed: dxva2: Simplify some ifdefs
[10:34:25 CEST] <cone-389> ffmpeg 03Clément BSsch 07master:bb71eb944c7a: Merge commit 'ac648bb835edd3f67bda2267d0e72e5e582eb5a1'
[10:35:20 CEST] <ubitux> should i merge a6901b9c6bd51396c1159f1a07f9f5042328cda6?
[11:29:14 CEST] <ubitux> https://lists.libav.org/pipermail/libav-devel/2016-December/081043.html
[11:29:28 CEST] <ubitux> so this is what actually motivated the drop
[11:29:37 CEST] <ubitux> "extralibs" thing in the build system
[11:29:43 CEST] <nevcairiel> diego motivations are all like that
[11:29:50 CEST] <nevcairiel> this feature is making things hard, lets drop it
[11:30:43 CEST] <ubitux> should i noop?
[11:31:12 CEST] <nevcairiel> no opinion, i dont encode mpeg4 nor do i use libxvid
[11:31:22 CEST] <nevcairiel> i dont know if it has an actual value
[11:31:50 CEST] <JEEB> so it's xvid RC for internal mpeg-4 part 2 encoder?
[11:42:00 CEST] <ubitux> JEEB: something like that yes
[11:42:18 CEST] <ubitux> i'm not sure i understand how it's really impacting his build system
[11:43:08 CEST] <JEEB> aye, it seemed to be just a single line and you'd still be checking for xvid, right?
[11:43:32 CEST] <JEEB> of course it most likely is a barely used thing unless it gets used by default if you have xvid linked in
[11:44:32 CEST] <ubitux> it's not by default but it's available if compiled with libxvid
[11:44:41 CEST] <ubitux> -rc_method xvid or something
[11:44:48 CEST] <JEEB> right
[11:45:00 CEST] <JEEB> but yeah, it didn't seem to affect the /build/ system too much with a quick glance
[11:45:32 CEST] <ubitux> yeah and i don't see anything further
[11:56:39 CEST] <ubitux> so again, should i drop or not?
[11:56:58 CEST] <ubitux> is there any people here who would be angry that i keep that code?
[12:01:05 CEST] <JEEB> looking at the amount of google results and looking at the 2009 D_S benchmark including the mpeg-4 part 2 encoder not using that mode I would be surprised if anyone cared one way or another :)
[12:02:13 CEST] <ubitux> ok
[12:03:29 CEST] <ubitux> michaelni: you wrote that code, what's your opinion?
[12:03:46 CEST] <ubitux> i'm assuming it's "don't drop if it doesn't cause any problem", but asking just in case
[12:47:06 CEST] <michaelni> ubitux, id say noop / dont drop, i dont think there was any issue with it
[12:55:22 CEST] <cone-389> ffmpeg 03Diego Biurrun 07master:a6901b9c6bd5: Drop libxvid rate control support for mpegvideo encoding
[12:55:23 CEST] <cone-389> ffmpeg 03Clément BSsch 07master:99b35a51ccbe: Merge commit 'a6901b9c6bd51396c1159f1a07f9f5042328cda6'
[13:15:07 CEST] <BtbN> Does configure define some convenient macro, to check if the arch is 64bit?
[13:23:54 CEST] <BtbN> will have to do: #if ARCH_X86_64 || ARCH_PPC64 || ARCH_AARCH64
[13:34:05 CEST] <ubitux> BtbN: what kind of code are you trying to put under such ifdefery?
[13:34:26 CEST] <BtbN> CUDA assembly
[13:34:34 CEST] <BtbN> you need different ones on 32 vs. 64 bit
[13:34:44 CEST] <ubitux> cuda is available on PPC64 and AARCH64?
[13:34:56 CEST] <BtbN> yes
[13:35:41 CEST] <BtbN> But I'll workaround this all together anyway I think
[13:35:49 CEST] <ubitux> maybe HAVE_FAST_64BIT
[13:37:17 CEST] <ubitux> fast_64bit_if_any="aarch64 alpha ia64 mips64 parisc64 ppc64 sparc64 x86_64"
[13:44:03 CEST] <cone-389> ffmpeg 03Diego Biurrun 07master:f1248fae90b4: configure: Handle dxva2 optional components in the standard way
[13:44:04 CEST] <cone-389> ffmpeg 03Clément BSsch 07master:d1c8b9660848: Merge commit 'f1248fae90b45501af4e8743d373e79191470331'
[13:46:37 CEST] <cone-389> ffmpeg 03Diego Biurrun 07master:fc368497f2ff: configure: Add missing dxva2 dependency for dxva2_lib
[13:46:38 CEST] <cone-389> ffmpeg 03Clément BSsch 07master:17f848ca0748: Merge commit 'fc368497f2fff54ddf5316224c573c9d1939fb25'
[13:55:46 CEST] <cone-389> ffmpeg 03Alexandra Hajkova 07master:b0e6b3f47779: hevc: ppc: Add HEVC 4x4 IDCT for PowerPC
[13:55:47 CEST] <cone-389> ffmpeg 03Clément BSsch 07master:f6e8d54fcc17: Merge commit 'b0e6b3f4777910d61083976aa9fc78a1e0731aae'
[13:56:17 CEST] <cone-389> ffmpeg 03Diego Biurrun 07master:6aa4ba7131b6: dxva2: Keep code shared between dxva2 and d3d11va under the correct #if
[13:56:18 CEST] <cone-389> ffmpeg 03Clément BSsch 07master:5eba94a8c392: Merge commit '6aa4ba7131b6e8668e33430e18101a051fe492eb'
[14:00:00 CEST] <cone-389> ffmpeg 03Anton Khirnov 07master:0309ddcfb25f: lavc: handle MP3 in get_audio_frame_duration()
[14:00:01 CEST] <cone-389> ffmpeg 03Clément BSsch 07master:b5a42c7f098a: Merge commit '0309ddcfb25fd44883bfcdb07509eb4907576b97'
[14:07:04 CEST] <cone-389> ffmpeg 03Anton Khirnov 07master:47e547b32133: lavc: add a null bitstream filter
[14:07:05 CEST] <cone-389> ffmpeg 03Clément BSsch 07master:e22d495538c1: Merge commit '47e547b321338c73c21fa623789f1efbd80a297a'
[14:08:35 CEST] <ubitux> wm4: any comment on 549d0bdca53af7a6e0c612ab4b03baecf3a5878f?
[14:08:54 CEST] <ubitux> and actually the next one
[14:09:04 CEST] <ubitux> would you mind merging those?
[14:09:21 CEST] <ubitux> (as you're obviously more comfortable than i am with this api)
[14:10:36 CEST] <ubitux> the next commits actually look pretty sensible
[14:12:27 CEST] <BtbN> hm, is set -e really bash?
[14:17:33 CEST] <BtbN> ugh... this nvcc thing on windows needs cl.exe
[14:30:03 CEST] <BtbN> I'm beginning to think that Having a script the developer runs once on his machine and then checking the generated artifacts isn't so bad...
[16:34:45 CEST] <J_Darnley> Gramner: is your comment about "using strip -x for local labels" an objection to my patch?
[17:08:42 CEST] <michaelni> ubitux,  bb71eb944c7abe4eccb6b21d4771751feca22980 breks build, "src/libavcodec/dxva2_internal.h:41:18: fatal error: dxva.h: No such file or directory"
[17:09:58 CEST] <ubitux> michaelni: it was fixed later afaik
[17:10:23 CEST] <ubitux> michaelni: see 5eba94a8c392be44a868183cdacff9a38fe55448
[17:10:34 CEST] <ubitux> doesn't it fix it?
[17:10:44 CEST] <ubitux> i'm sorry i can't really test the dxva things
[17:11:50 CEST] <michaelni> didnt had 5eba94a8c392be44a868183cdacff9a38fe55448 locally yet when i tested
[19:10:13 CEST] <durandal_1707> no comments for mscc and srgc?
[20:01:43 CEST] <cone-159> ffmpeg 03Vignesh Venkatasubramanian 07master:62c27fdba43d: webm_dash_manifest: Add option to specify bandwidth
[20:01:43 CEST] <cone-159> ffmpeg 03James Zern 07master:20aeee4fc99f: matroskadec,cosmetics: fix a couple typos
[21:00:22 CEST] <thebombzen> I have a question - if you try to encode opus or vorbis with -c opus or -c vorbis, it'll select the experimental encoders with those exact names. This means if you try to do something like "ffmpeg -f lavfi -i anullsrc -c opus out.opus" ffmpeg.c will complain that opus is experimental and you should use -strict -2
[21:00:46 CEST] <thebombzen> and alternatively, use the non-experimental encoder libopus
[21:01:30 CEST] <thebombzen> however, if you just allow it to automatically choose the codec from the format without using -c (either via the file extension or -f opus) then it'll default to libopus, treating "libopus" as the default opus encoder
[21:01:59 CEST] <gnafu> thebombzen: I understand where you're coming from, but it makes sense to me.
[21:02:04 CEST] <thebombzen> (I'm not done)
[21:02:09 CEST] <gnafu> After all, the experimental codec's name /is/ "opus".
[21:02:14 CEST] <gnafu> Aah, sorry :-).
[21:03:01 CEST] <thebombzen> This is true even if you have -strict -2 set. Using: ffmpeg -f lavfi -i anullsrc -strict -2 -f opus out.opus, this will still default to libopus as teh default opus encoder, even though both "opus" and "libopus" are valid
[21:03:30 CEST] <BBB> this is basically avcodec_find_encoder_by_name() vs. avcodec_find_encoder()
[21:03:45 CEST] <thebombzen> so this behavior makes sense because -c specifies a name
[21:04:19 CEST] <thebombzen> but I noticed that -c can also autochoose when missing
[21:04:49 CEST] <thebombzen> as in, if you use ffmpeg -f lavfi -i testsrc -c h264 -f null -, it will automatically choose an h.264 encoder (in this case, libx264 for my build. I also have h264_nvenc as another option)
[21:05:22 CEST] <BBB> youre suggesting to change -c:v N from avcodec_find_encoder_by_name(N) to avcodec_find_encoder(avcodec_descriptor_get_by_name(N)->id);
[21:05:59 CEST] <thebombzen> Not necessarily
[21:06:03 CEST] <jamrial> avcodec_find_encoder() will chose the best encoder by default, and that means whichever is first in the list that's not marked as experimental
[21:06:36 CEST] <thebombzen> because with -strict -2, avcodec_find_encoder will still pick libopus over opus
[21:06:54 CEST] <jamrial> yes, that's imo the best default behavior
[21:06:59 CEST] <thebombzen> I agree
[21:07:02 CEST] <thebombzen> here's my suggestion:
[21:07:16 CEST] <thebombzen> suppose you use avcodec_find_encoder_by_name, and the codec returned is experiemental, but experimental encoding is turned off
[21:07:35 CEST] <thebombzen> instead of a fatal error, instead, output an error, and then retry with avcodec_find_encoder
[21:07:47 CEST] <thebombzen> if the resulting codec is not experimental, use that.
[21:08:14 CEST] <thebombzen> The end result is basically that if someoen uses -c opus or -c vorbis without -strict experimental, it'll replace it with libopus or libvorbis as an ease-of-use thing
[21:08:21 CEST] <BBB> that solves the default-fail, but not the default-poor-quality
[21:08:35 CEST] <thebombzen> what default-poor-quality
[21:08:47 CEST] <BBB> i.e. if someone says -strict experimental, itll take the worse-quality encoder by default :)
[21:09:11 CEST] <BBB> or to say it differently, -strict experimental would change the meanign of -c:a/v without explicit user consent
[21:09:27 CEST] <thebombzen> Ah no my proposition won't affect anything if -strict experimental is turned on
[21:09:48 CEST] <BBB> it does, in a very unexpected way
[21:09:56 CEST] <thebombzen> well then I phrased it poorly
[21:10:04 CEST] <BBB> -c:a opus -strict experimental vs. -c:a opus will change the encoder
[21:10:07 CEST] <BBB> thats very unexpected
[21:10:24 CEST] <gnafu> thebombzen: So what you're suggesting is simply that it will try libopus after failing with opus (due to not having -strict -2)?
[21:10:24 CEST] <BBB> I know its intentional for you, but is that the intention of a user?
[21:10:26 CEST] <thebombzen> well those still behave very differetnly
[21:10:32 CEST] <thebombzen> one fatal errors
[21:10:33 CEST] <thebombzen> and one doens't
[21:10:36 CEST] <BBB> what if the experimental was intended for a new video codec?
[21:10:48 CEST] <thebombzen> Here's my logic
[21:11:00 CEST] <thebombzen> most people who specify -c:a opus do so by mistake
[21:11:06 CEST] <thebombzen> and instead want -c:a libopus
[21:11:19 CEST] <thebombzen> if they didn't have -strict -2, what happens is ffmpeg fails with a fatal error
[21:11:39 CEST] <thebombzen> and you go "oh yea" and change it to -c:a libopus
[21:11:54 CEST] <BBB> does the error message mention -c:a libopus?
[21:12:08 CEST] <thebombzen> Yes
[21:12:17 CEST] <thebombzen> this is entirely an "ease of use" thing
[21:12:36 CEST] <thebombzen> basically in the event that you explicitly specify an experimental encoder without experimental encoding turned on
[21:12:43 CEST] <thebombzen> instead of printing a fatal error and exiting
[21:13:00 CEST] <thebombzen> instead, print the same error (or similar) as nonfatal, and then default to the nonexperimental encoder.
[21:13:12 CEST] <gnafu> With a command line tool as powerful as ffmpeg, it would seem to me best to expect the user to be explicit about their intentions when multiple options exist.  Current behavior understands that there could be two completely different intentions for specifying "-c:a opus".
[21:13:30 CEST] <thebombzen> Ah, no it doesn't.
[21:13:42 CEST] <thebombzen> Currently behavior always assumes -c:a opus means "opus"
[21:13:45 CEST] <thebombzen> and never libopus
[21:14:03 CEST] <KGB> [13FFV1] 15michaelni closed pull request #52: move Michael's copyright statement from spec to pdf backmatter (06master...06move-copyright) 02https://git.io/vD7wy
[21:14:06 CEST] <BBB> I would inform the user that there is a non-experimental encoder called "libopus"
[21:14:13 CEST] <gnafu> One person might specify it not knowing, while another might specify it forgetting to also specify "-strict -2".  The former would get a nice result, but the latter would have to restart only after realizing their mistake and encoding audio to "libopus" instead.
[21:14:22 CEST] <BBB> and allow the user to explicitly select that by re-invoking the cmmandline
[21:14:27 CEST] <BBB> that way things remain unambiguous
[21:14:39 CEST] <thebombzen> But either way, it'd still be unambiguous
[21:15:13 CEST] <thebombzen> because nobody wants to use -c:a opus unless you know you actually want to use that one and not libopus. People who want to use opus over libopus know who they are, and should specify -strict -2
[21:15:34 CEST] <BBB> youre 100% sure that the users intention with -c:a opus was to use libopus (forgot lib prefix), not the opus encoder (forgot -strict -2)?
[21:15:36 CEST] <gnafu> If I meant to use "opus" but forgot the experimental flag, I'd be upset when the "libopus" encode completed.
[21:16:03 CEST] <gnafu> I have, several times, meant to use the experimental "aac" codec while forgetting to set "-strict -2".
[21:16:08 CEST] <BBB> thebombzen: as frustrating as this may be, ffmpeg.c really is a power user tool, and its good to make things explicit
[21:16:14 CEST] <BBB> imagine that rm invoked -fr by default
[21:16:16 CEST] <gnafu> And I would have been upset if ffmpeg had instead failed over to some other AAC encoder.
[21:16:20 CEST] <thebombzen> If that's true, why do you autoselect codecs
[21:16:37 CEST] <BBB> autoselect means I dont care, IMO
[21:16:42 CEST] <thebombzen> If it's a power user tool and things have to be explicit, why do you automatically select H.264 for matroska
[21:16:44 CEST] <BBB> but good question :)
[21:16:55 CEST] <thebombzen> matroska can hold anything, so it should whine that it doesn't know what to pick
[21:17:05 CEST] <thebombzen> and force you to pick something explicitly
[21:17:23 CEST] <thebombzen> same with nut
[21:17:44 CEST] <gnafu> That one I agree with, but it's also a bit different than a user specifying one codec and getting another (even if that's what they really wanted, it's not what they asked for).
[21:17:59 CEST] <thebombzen> yes, but I keep in mind that you already do this
[21:18:05 CEST] <gnafu> As far as container defaults, the user isn't getting something different from what they asked: they simply never asked.
[21:18:13 CEST] <thebombzen> if the user specifies -c h264, ffmpeg should whine that it doesn't know which encoder that is
[21:18:20 CEST] <thebombzen> rather than pick libx264
[21:18:38 CEST] <atomnuker> not if there's only 1 h264 encoder
[21:18:41 CEST] <gnafu> Aah, I suppose I didn't know about that behavior.  I've never tried specifying "h264" for the video codec.
[21:18:59 CEST] <atomnuker> I like the current behaviour better
[21:19:12 CEST] <atomnuker> most users are smart enough to always use libvorbis
[21:19:33 CEST] <gnafu> I am actually surprised "h264" would be an alias to anything.  I would've expected it to either fail saying there was no codec with that name, or for there to actually be a built-in H.264 encoder.
[21:19:37 CEST] <atomnuker> (and most copy'n'pasteable command lines use libvorbis)
[21:19:51 CEST] <gnafu> So that's news to me :-).
[21:20:15 CEST] <thebombzen> atomnuker: I have several
[21:20:30 CEST] <thebombzen> I have more than one h.264 encoder, and it will still pick libx264 if I use -c h264
[21:20:51 CEST] <thebombzen> I have three actually
[21:20:55 CEST] <atomnuker> that's okay, it should very well be the first choice for anything
[21:20:57 CEST] <thebombzen> libx264, h264_nvenc, and h264_vaapi
[21:21:13 CEST] <thebombzen> yes, but what I'm saying is that you already make choices for the user if the user specifies something vague
[21:21:25 CEST] <thebombzen> I don't understand the trepidation about opus when you aready do that for h264
[21:21:39 CEST] <atomnuker> you don't for h264
[21:21:40 CEST] <thebombzen> instead of saying "halp what do I do I don't know what to pick" with h264, it just picks one
[21:21:45 CEST] <thebombzen> and yes you do
[21:21:45 CEST] <atomnuker> there's no built in encoder for that
[21:22:06 CEST] <thebombzen> yes but if you use -c opus without -strict -2, the built-in encoder isn't valid
[21:22:33 CEST] <atomnuker> yes, and an error message saying "add -strict -2 or use libopus (if available)" is printed
[21:22:42 CEST] <atomnuker> which is okay
[21:23:09 CEST] <atomnuker> it informs users "opus" is an encoder name, says its experimental and suggests a better alternative if its compiled in
[21:23:09 CEST] <thebombzen> hm, the default behavior makes sense, I guess I"m just suggesting an ease-of-use change
[21:23:18 CEST] <thebombzen> if the devs think it's a bad idea, then whatever
[21:23:43 CEST] <thebombzen> I just don't want you guys to be like "it's a bad idea" unless I'm sure you know where I'm coming from
[21:44:57 CEST] <gnafu> If I were to suggest any change, I'd say "-c:v h264" should fail with a helpful message ;-).
[21:45:10 CEST] <gnafu> But it doesn't really matter to me :-P.
[21:48:04 CEST] <nevcairiel> I agree with what the others have said, if you specify an encoder by name you should get exactly that encoder and none else, and "opus" just happens to be the name of the internal encoder (our internal encoders and decoders all get the nice and simple names), and if you want to use libopus, you should be asked to specify that, being explicit is often a good thing. Cases where we don't have any internal encoders are a bit iffy, but
[21:48:04 CEST] <nevcairiel>  all commandlines i see typically directly specify libx264 anyhow
[21:49:18 CEST] <gnafu> And the other two options they mentioned would require having certain compatible hardware installed and configured, so libx264 is really the only safe H.264 encoder to choose.
[21:51:09 CEST] <nevcairiel> Otherwise, we should just encourage atomnuker to make ffopus great and stop all these discussion =p
[21:54:34 CEST] <gnafu> MFFOGA!
[21:55:39 CEST] <gnafu> What are the specific goals of ffopus, aside from just to do it?  For something like AAC, it always made sense to me to have a usable built-in because the others choices were such a mess.  With Opus, it would seem libopus is great and as Free as you can get.
[21:55:52 CEST] <gnafu> Not that it's a bad thing if the only reason is just to do it ;-).
[21:56:45 CEST] <gnafu> Similar to how x264 is so good that I would be surprised if someone invested a lot of time making an independent built-in H.264 encoder.
[22:01:53 CEST] <durandal_1707> just to make you ask such questions
[22:03:55 CEST] <gnafu> :-D
[22:25:09 CEST] <atomnuker> the goal is to get something better than libopus by doing things completely differently
[22:26:08 CEST] <atomnuker> a good motivation for doing that is you have to fight against the codec to do so, which is the best part of writing encoders
[22:28:43 CEST] <gnafu> Cool :-).
[22:29:16 CEST] <gnafu> Opus is very impressive, so creating an encoder that's even better than reference will be really nice.
[22:29:43 CEST] <atomnuker> the fixed black box bit allocation function is both opus's best point (you can't write a bad encoder) and worst (its difficult to do better)
[22:30:32 CEST] <atomnuker> bit allocation becomes a solved problem, and with that you can't do conventional rate distortion analysis (rate is constant)
[22:32:24 CEST] <atomnuker> though its different if your encoder works in terms of pseudo quantization indices which behind the scenes modify bit allocation parameters and frame size in bytes
[22:33:31 CEST] <atomnuker> so you get approxmate rate change to do actual RDO
[22:40:38 CEST] <gnafu> I don't really understand what those things mean, but I'm glad you do and that you're having fun with it ;-).
[00:00:00 CEST] --- Tue Apr 18 2017