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

[burek]

[00:28:30 CEST] <cone-894> ffmpeg 03Andreas Cadhalpun 07master:83a04f8cc16f: mov: reject zero bytes_per_frame with non-zero samples_per_frame
[00:44:20 CEST] <cone-894> ffmpeg 03Carl Eugen Hoyos 07master:5193407cf68e: lavf/dnxhd: Autodetect more files that can be decoded.
[01:33:12 CEST] <jamrial> this d3d11 patch seems to have broken recent mingw-w64
[01:33:55 CEST] <jamrial> yes, it totally did http://fate.ffmpeg.org/report.cgi?time=20150525221258&slot=x86_64-mingw-w64-windows-native
[01:34:01 CEST] <jamrial> the configure checks are not sufficient
[01:36:38 CEST] <jamrial> or rather, the one check that actually makes sure things work, d3d11_cobj, is not used anywhere. As things are right now, it's basically only checking for the presence of the d3d11 header and assuming it's valid
[01:42:05 CEST] <michaelni> jamrial, does this fix it? "[FFmpeg-devel] [PATCH] configure: Check if ID3D11VideoDecoder exists, not just the header to enable d3d11va"
[01:42:51 CEST] <michaelni> or you just refer to the fate box and have no local testcase ?
[01:43:51 CEST] <jamrial> oh, didn't see that patch in the ml
[01:44:08 CEST] <jamrial> and no, it broke mingw on my end as wel
[01:44:18 CEST] <jamrial> i'll try it, give me one minute
[01:50:52 CEST] <jamrial> michaelni: yes, it works, thanks
[01:51:03 CEST] <cone-894> ffmpeg 03Michael Niedermayer 07master:5bc2c395273e: avfilter/x86/vf_fspp: Fix invalid combination of opcode and operands
[02:02:22 CEST] <cone-894> ffmpeg 03Michael Niedermayer 07master:a838b22bd9f7: configure: Check if ID3D11VideoDecoder exists, not just the header to enable d3d11va
[04:13:18 CEST] <jamrial> the d3d11 stuff apparently also broke h264/hevc decoding on msvc x86_32
[04:47:29 CEST] <philipl> jamrial: There's an obvious bug at least in the hevc.c stuff where it's not allocating enough space for the hwaccel pix formats.
[04:48:26 CEST] <cone-894> ffmpeg 03Michael Niedermayer 07master:7ed5d78d619e: avcodec/dxva2: Fix "may be used uninitialized" warnings
[04:48:29 CEST] <philipl> I can't build windows but it looks like it's going to fail if both dxva and d3d11 are enabled, which seems likely.
[04:50:24 CEST] Action: michaelni doesnt have a msvc setup nor win8
[04:50:55 CEST] <cone-894> ffmpeg 03Philip Langdale 07master:9ae766d1c698: avcodec/vdpau: Re-factor pre-hwaccel helper functions into separate header
[04:53:24 CEST] <philipl> It'll actually fail regardless of whether dxva2 is enabled. Oh well.
[05:01:12 CEST] <jamrial> the fate tests don't use any hwaccel afaik. and why only x86_32?
[05:01:40 CEST] <jamrial> in any case, i raised the issue to the patch's author
[05:03:26 CEST] <jamrial> i'm surprised libav applied this at all. they usually try big change patches on "oracle" (fate for uncommited stuff)
[05:11:34 CEST] <philipl> surprises me too. I dont' see how it could work at runtime.
[05:24:24 CEST] <cone-894> ffmpeg 03Michael Niedermayer 07master:5cddfc53570f: avcodec/dxva2_h264: Fix "may be used uninitialized" warnings
[05:24:25 CEST] <cone-894> ffmpeg 03Michael Niedermayer 07master:688147cfe2d1: avcodec/hevc: Fix HWACCEL_MAX for D3D11
[05:24:26 CEST] <cone-894> ffmpeg 03Michael Niedermayer 07master:1b236541a6b5: avcodec/h264: Fix HWACCEL_MAX for D3D11
[06:59:30 CEST] <jamrial> philipl: you were right, it was that
[12:19:51 CEST] <cone-663> ffmpeg 03Michael Niedermayer 07master:db07fc20200d: avformat/mpegts: Avoid float in bitrate calculation
[13:52:27 CEST] <cone-663> ffmpeg 03Michael Niedermayer 07master:f902b0b2cbdc: avformat/asfdec: Avoid float usage in duration calculation
[15:03:35 CEST] <BBB> Timothy_Gu: can you follow discussion of your patch on #x264dev?
[15:03:46 CEST] <BBB> Timothy_Gu: (since I consider them the upstream for x86inc.asm)
[15:04:04 CEST] <BBB> Timothy_Gu: I dont think theyre bringing up any issues, but they may have a question about it that youre best capable of answering
[16:09:38 CEST] <cone-663> ffmpeg 03Michael Niedermayer 07master:894d8cf418aa: avformat/movenc: Avoid floats & float rounding in tmcd nb_frames calculation
[16:51:23 CEST] <Compn> michaelni : what do you think about letting the mips guys just commit , seems like they arent handling all of the reviews :P
[16:51:54 CEST] <Compn> or maybe i am misreading the situation
[16:53:43 CEST] <Compn> >in before bunch of complaints that code should be perfect before committing 
[16:53:44 CEST] Action: Compn runs
[16:55:24 CEST] <kierank> I do wonder what Imagination/MIPS are up to
[16:55:26 CEST] <kierank> av500?
[16:55:29 CEST] <kierank> any thoughts?
[16:55:36 CEST] <av500> desperation?
[16:56:11 CEST] <av500> img tec realizes that anybody can grop them for an different GPU easily
[16:56:15 CEST] <av500> drop*
[16:56:35 CEST] <av500> so now they are trying to climb up the ladder
[16:56:43 CEST] <av500> offer the whole solution
[16:56:55 CEST] <av500> but today that includes the radios
[16:57:06 CEST] <av500> just mips + gpu aint gonna cut it
[16:58:07 CEST] <kierank> I mean up to in FFmpeg
[16:58:19 CEST] <av500> ah ok, they have radios: http://www.imgtec.com/ensigma/explorer-rpu.asp
[16:58:26 CEST] <av500> kierank: dunno
[16:58:44 CEST] <kierank> used to be MIPS eastern europe
[16:58:47 CEST] <av500> like anybody else, use it for the odd codecs you dont have hw for
[16:58:47 CEST] <kierank> now it's MIPS india
[17:03:13 CEST] <Daemon404> mips also used to be uk
[17:23:45 CEST] <Compn> kierank : are you suggesting we make "ffmpeg certified" stamp of approval for hardware devices/chips that vendors can purchase from us ?
[17:24:20 CEST] <kierank> not sure how you came up with that...
[17:24:21 CEST] <kierank> :)
[17:25:07 CEST] <Compn> i played out a few conversations in my head :)
[17:37:21 CEST] <Daemon404> we'd probably make mroe money if we sold licenses to *not* say they used ffmpeg
[17:37:25 CEST] <Daemon404> to broadcasters
[17:37:26 CEST] Action: Daemon404 runs
[18:33:39 CEST] <cone-663> ffmpeg 03Michael Niedermayer 07master:1fb9b2a28324: avutil: Add av_q2intfloat()
[19:34:33 CEST] <wm4> rcombs: do you want me to port over your secure transport patch?
[19:49:21 CEST] <Daemon404> i am planning to revive NSS once tls is in
[19:49:25 CEST] <Daemon404> thats why i kept asking ;)
[19:49:33 CEST] <Daemon404> (nss is good for license reasons)
[19:50:49 CEST] <JEEBsv> yeah
[20:06:08 CEST] <cone-663> ffmpeg 03Michael Niedermayer 07master:8aa985309340: avformat/ircamenc: Avoid floats
[20:30:11 CEST] <michaelni> wm4, can you port the tls stuff to ffmpeg ?
[20:33:08 CEST] <wm4> michaelni: I do not wish to do that
[20:34:50 CEST] <michaelni> neither do i
[20:36:04 CEST] <Daemon404> surely tls.c cant differ as much
[20:36:08 CEST] <Daemon404> that*
[20:49:08 CEST] <cone-663> ffmpeg 03Michael Niedermayer 07master:cf86fd0069ee: avformat/matroskaenc: Avoid floats in default duration calculation
[20:49:39 CEST] <wm4> not that much http://sprunge.us/ajOM
[20:57:30 CEST] <cone-663> ffmpeg 03Sebastian Ramacher 07master:cf1f3d837e12: doc: Fix spelling of 'Transmission'
[20:57:31 CEST] <cone-663> ffmpeg 03Michael Niedermayer 07master:4ae090f2240b: Merge commit 'cf1f3d837e1266034a487de5b575bd76426c6b10'
[21:21:34 CEST] <rcombs> wm4: go for it if you want; I was waiting for all the changes on the libav ML to land here
[21:23:55 CEST] <rcombs> also, I think it should be possible to support the RTMP crypto stuff with nettle/gcrypt/GMP without actually linking GNUTLS
[21:25:43 CEST] <rcombs> wm4: one note: I was planning on switching the private API call (SecIdentityCreate) to use dlsym(RTLD_SELF, "SecIdentityCreate");
[21:26:40 CEST] <wm4> hm
[21:27:40 CEST] <rcombs> it's probably unnecessary; I doubt they'll remove that without a fair bit of warning, since WebKit uses it at least
[21:29:16 CEST] <Daemon404> rcombs, i assume that will only be for OSX?
[21:29:22 CEST] <rcombs> Daemon404: right
[21:29:22 CEST] <wm4> public webkit sources use it?
[21:29:29 CEST] <Daemon404> rcombs, ok
[21:29:50 CEST] <rcombs> wm4: https://github.com/WebKit/webkit/blob/master/Source/WebKit2/Shared/cf/ArgumentCodersCF.cpp#L43
[21:30:05 CEST] <wm4> lol apple
[21:30:29 CEST] <rcombs> I dunno why it's not just public API
[21:30:50 CEST] <wm4> this adds it https://github.com/WebKit/webkit/commit/3eff7c1f00c0fbf90eedbddd50d57a3b82647b70
[21:30:53 CEST] <rcombs> the function's like 5 lines long
[21:30:59 CEST] <wm4> (what kind of way is that to make a commit)
[21:31:16 CEST] <wm4> (right, svn, lol)
[21:31:31 CEST] <rcombs> http://www.opensource.apple.com/source/Security/Security-55179.13/sec/Security/SecIdentity.c fine, 10 lines
[21:37:15 CEST] <jesseg> Where is CONFIG_ALSA_INDEV supposed to be defined and is it always defined?
[21:37:49 CEST] <wm4> I think it's always defined
[21:37:51 CEST] <wm4> to 0 or 1
[21:37:57 CEST] <jesseg> Hmm... Where?
[21:38:04 CEST] <wm4> and obviously configure generates config.h, where it is defined
[21:38:10 CEST] <wm4> are you hacking ffmpeg?
[21:39:10 CEST] <jesseg> Just trying to compile kdenlive.. and ffmpeg bombs, complaining that CONFIG_ALSA_INDEV is not defined. So I grep the source tree for it 
[21:39:42 CEST] <wm4> ffmpeg bombs? I thought you're compiling kdenlive
[21:39:59 CEST] <wm4> or is this another terrible program which embeds ffmpeg sources? (instead of using it properly)
[21:40:06 CEST] <jesseg> I'm using the compile script for kdenlive which fetches a whole boatload of dependencies and compiles them
[21:40:27 CEST] <jesseg> Okay now I am trying to compile ffmpeg from git right fresh from the source
[21:40:35 CEST] <wm4> CONFIG_ALSA_INDEV is an internal symbol, which doesn't appear outside of ffmpeg
[21:41:14 CEST] <jesseg> Where should I find it defined?
[21:42:32 CEST] <wm4> config.h
[21:42:44 CEST] <jesseg> Now I'm trying to compile ffmpeg right from the git and it also errors out because CONFIG_ALSA_INDEV and a buncha others undeclared
[21:42:50 CEST] <jesseg> lemme look there
[21:42:56 CEST] <Daemon404> your env sounds broken...
[21:43:29 CEST] <iive> you need to run configure first, it generates config.h
[21:43:49 CEST] <iive> and config.mak, and some others.
[21:43:54 CEST] <jesseg> Oh, okay, so my configure is not putting the defnes into config.h
[21:43:57 CEST] <jesseg> hmmm
[21:43:58 CEST] <Daemon404> wut
[21:44:14 CEST] <jesseg> I grepped config.h, no "INDEV" there
[21:44:21 CEST] <wm4> paste your config.h
[21:44:26 CEST] <Daemon404> on paxtebin!
[21:44:28 CEST] <Daemon404> not irc.
[21:44:34 CEST] <jesseg> yeah yeah :P 
[21:44:39 CEST] <wm4> and miss all the spam?
[21:44:42 CEST] <iive> config.log might be more insteresting.
[21:45:37 CEST] <iive> if configure dies, it doesn't produce partial config.h, does it?
[21:45:51 CEST] <wm4> it could in theory
[21:46:57 CEST] <jesseg> hahahahaha yes even though configure was terminating without printed response and with a valid return value (i.e. ./configure && make ran make), the last line of the config.h has a bunch of nulls or junk
[21:47:09 CEST] <jesseg> soo configure is dying, leaving a partial config.h...
[21:47:15 CEST] <Compn> lol
[21:47:25 CEST] <Compn> wow thats rare i'd say
[21:47:30 CEST] <jesseg> http://pastebin.com/y8wjcTpQ
[21:47:54 CEST] <jesseg> actually I had that same thing happen few years ago... and I think it was on ffmpeg :P but they fixed it a few days after I submitted a bug
[21:48:15 CEST] <jesseg> so that's my config.h, to the degree that it got finished. The nulls didn't paste to the bin I guess
[21:48:31 CEST] <iive> i don't even know how to fill file with zeroes, using only bash scripts...
[21:48:40 CEST] <iive> are you sure you didn't had some system failure?
[21:48:59 CEST] <iive> running configure, then hard-reset?
[21:49:39 CEST] <jesseg> iive, hmmm. Nothing out of the ordinary in dmesg. I've been using slackware for 10 years so I've seen the more common modes of failure. I'm not aware of any failure here.
[21:50:17 CEST] <rcombs> yeah, post config.log
[21:50:19 CEST] <jesseg> Well, I may have tried to install google earth and not succeeded.
[21:50:31 CEST] <jesseg> K
[21:50:55 CEST] <jesseg> yeah it ends in an error
[21:51:58 CEST] <rcombs> &elaborate?
[21:52:22 CEST] <jesseg> cc1: error: unrecognized command line option "-Wmaybe-uninitialized"
[21:52:22 CEST] <iive> i'm also running slackware, it is rock-solid.
[21:52:31 CEST] <jesseg> maybe my gcc is too old?
[21:52:43 CEST] <jesseg> gcc version 4.5.2 (GCC)
[21:52:48 CEST] <iive> they should detect the options.
[21:53:06 CEST] <jesseg> yeah, at least they oughta check the compiler version:P
[21:53:23 CEST] <iive> better, try them on the gcc.
[21:53:25 CEST] <jesseg> yeah slackware is great. If you can get something to compile, then it's generally rock solid :P
[21:53:47 CEST] <iive> there is slckpkg 
[21:53:51 CEST] <iive> ops
[21:54:38 CEST] <iive> slpkg
[21:55:14 CEST] <iive> i'm running current, it have gcc 4.9.2
[21:55:38 CEST] <iive> are you running btrfs as working filesystem?
[21:56:39 CEST] <jesseg> config.log fwiw: http://pastebin.com/V0m1k2Si
[21:56:57 CEST] <jesseg> ext4
[21:58:16 CEST] <jesseg> yeah my gcc does not recognize the command line command line option "-Wmaybe-uninitialized"
[21:58:18 CEST] <jesseg> Does yours?
[21:59:43 CEST] <rcombs> looks like it died in the middle of checking which gcc options are accepted
[21:59:57 CEST] <Daemon404> check dmesg
[22:00:00 CEST] <Daemon404> this sounds like a system issue
[22:00:51 CEST] <jesseg> Nothing new in dmesg. Just stuff about when I had a USB disk device plugged in earlier today, it showed up as sdb and sdd
[22:00:54 CEST] <wm4> actually my config.log also checks this at the end
[22:00:57 CEST] <jesseg> err not a stick but reader
[22:02:42 CEST] <jesseg> I agree though, it does sound like a system issue :D
[22:06:07 CEST] <jesseg> Strange.. "Wmaybe-uninitialized" does not appear anywhere in the source tree until it gets put in config.log and the gcc error log. However, configure does contain -Wno-maybe-uninitialized which is a valid gcc argument..
[22:06:28 CEST] <jesseg> I cannot figure out where the "no-" is getting stripped out..
[22:07:49 CEST] <Daemon404> i do not think that is related to the broken config.h
[22:07:56 CEST] <Daemon404> youre not out of disk or something are you
[22:08:35 CEST] <jesseg> Hmmm, df says I have 13 gigs free on that partition
[22:08:58 CEST] <Daemon404> the only otehr obvious hting would be if multiple processes were trying to write to config.h
[22:09:04 CEST] <wm4> if it's brtfs, it could lie (ok, you said you're using ext4)
[22:10:10 CEST] <jesseg> I can try creating a file from /dev/urandom if you like with dd
[22:10:55 CEST] <jesseg> Hmm, just created a 10mb file no problem.
[22:11:43 CEST] <jesseg> https://ffmpeg.org/pipermail/ffmpeg-user/2012-May/006846.html
[22:12:56 CEST] <Daemon404> are you using a stock kernel
[22:13:40 CEST] <jesseg> hmmmmmm I think I had to replace some custom copy function with cat before, years ago.. That sounds so familiar
[22:13:46 CEST] <jesseg> hmmm lemme check on kernel
[22:13:50 CEST] <Daemon404> its not custom
[22:13:55 CEST] <Daemon404> https://github.com/ffmpeg/ffmpeg/blob/master/configure#L1307
[22:13:59 CEST] <Daemon404> it's literally cmp and cp
[22:14:19 CEST] <jesseg> yeah I saw that
[22:14:44 CEST] <Daemon404> i also recommend doign make distclean if you havent been between attempts
[22:15:18 CEST] <jesseg> Daemon404, I'm using kernel 3.8.6 which it looks like I may have compiled from source.. Was long enough ago I don't remember exactly :P
[22:16:38 CEST] <Daemon404> this sure doesnt seem like an ffmpeg configure problem as much as a "my system is a hacked together mess thats never updated" problem that is endemic to certain distribs.
[22:16:51 CEST] <jesseg> haha yeah
[22:17:33 CEST] <Compn> jesseg : what other tools versions are you using?
[22:17:41 CEST] <Compn> bash --ver , awk --ver , sed --ver ... etc
[22:17:47 CEST] <Compn> make --ver
[22:17:59 CEST] Action: Compn bets on old make
[22:18:07 CEST] <Daemon404> make is 100% unrelated
[22:18:25 CEST] <jesseg> GNU Make 3.82
[22:18:29 CEST] <Compn> ooo old make
[22:18:35 CEST] <Daemon404> Compn, *unrelated*
[22:18:35 CEST] <Compn> :P
[22:19:13 CEST] <Compn> oh
[22:19:16 CEST] <jesseg> GNU bash, version 4.1.10(2)-release (okay give me flack.)
[22:19:33 CEST] <Compn> you can make configure go thru the script line by line, to see whats failing
[22:19:40 CEST] <Compn> i forgot how to make it do that though
[22:19:42 CEST] <jesseg> GNU Awk 3.1.8
[22:19:43 CEST] <Daemon404> it's obviously failing at cp
[22:19:57 CEST] <Daemon404> unless the tmp file it copies form is also broken
[22:20:07 CEST] <Daemon404> i think it is a waste of time to dig into it
[22:20:09 CEST] <jesseg> yeah exactly how could I break my system so that cp failed, but just there? :P
[22:20:11 CEST] <Daemon404> the solution is "get a working system"
[22:20:26 CEST] <Daemon404> i know updating slackware is frowned upon, but...
[22:20:40 CEST] <Daemon404> maybe you can clsoe some CVE holes in your system while at it
[22:20:41 CEST] Action: Daemon404 runs
[22:20:43 CEST] <jesseg> well anyway you've gotten me much closer and helped me remember last time I had this problem. Obviously others out there have had it too
[22:20:44 CEST] <Compn> this is the same Daemon404 who said support does not belong in this channel ?
[22:20:54 CEST] <Daemon404> Compn, i refrained fro msaying that
[22:21:01 CEST] <Daemon404> because the problem was at least fairly insane
[22:21:06 CEST] <Compn> bufffffffff
[22:21:13 CEST] <jesseg> Thanks everyone!
[22:21:22 CEST] <Daemon404> Compn, butts
[22:21:31 CEST] <Compn> BUFFERING
[22:21:44 CEST] <Compn> (insults for media nerds)
[22:23:56 CEST] <jesseg> hahahaha I changed that one call of cp_if_changed to cat $TMPH > config.h  and now config.h is longer and includes a bunch more defines.. including the one I was missing.
[22:26:04 CEST] <Daemon404> that sounds like a broken kernel jesseg 
[22:26:34 CEST] <jesseg> Daemon404, you mean as in my cp is broken? I kind of use it all the time. It's never failed me before that I've noticed it and I sure think I would notice it...
[22:26:58 CEST] <Compn> Daemon404 try explaining the difference of a kernel and the cp tool like the user is 5, that may help :P
[22:27:20 CEST] <Daemon404> jesseg, its nto about cp being broken
[22:27:28 CEST] <Compn> jesseg : something is screwed on your system, not our fault, not our bug. good luck. if you are looking for a new distro i recommend Arch.
[22:27:29 CEST] <Daemon404> its about configure tripping a certain set of conditions to make it broken
[22:27:32 CEST] <Daemon404> perhaps a syscall sequence
[22:27:34 CEST] <Daemon404> i dont know.
[22:27:38 CEST] <Daemon404> all i can say is: try
[22:27:57 CEST] <nevcairiel> jesseg: if a simple cp command produces a broken output file, then something in your system is seriously wonky .. and since cp is a  old and proven tool, it likely points to some deeper system issue: ie. kernel
[22:27:59 CEST] <Compn> (well it still could be our bug, but blah :P)
[22:29:01 CEST] <Compn> bash version 4 huh
[22:29:14 CEST] <jesseg> nevcairiel, I would agree with you, but cp has never failed me before... except on ffmpeg, a few years ago. I copy too many gigabytes of data that would get corrupted if my file io drivers in my kernel were borked.. It can't just be coincidence that it happens ONLY on ffmpeg, and ONLY on config.h hahaha :)
[22:29:29 CEST] <Daemon404> [21:27] <@Daemon404> its about configure tripping a certain set of conditions to make it broken
[22:29:32 CEST] <Daemon404> [21:27] <@Daemon404> perhaps a syscall sequence
[22:29:39 CEST] <jesseg> and it's happened to other people too -- on ffmpeg's config.h.
[22:29:57 CEST] <Daemon404> e.g. we used to trip a bug in make with our makefile, and only because it filled a specific set of conditions
[22:30:03 CEST] <Daemon404> but it was make's bug.
[22:30:25 CEST] <jesseg> anyway, ffmpeg seems to be compiling. So I'm happy. Thanks guys :)
[22:31:51 CEST] <nevcairiel> Daemon404: make still crashes occasionally <.<
[22:32:24 CEST] <Daemon404> nevcairiel, sure but now it can handle line endings!
[22:32:31 CEST] <Daemon404> and sometimes it hangs for me
[22:32:33 CEST] <Daemon404> if i do parallel
[22:33:20 CEST] <nevcairiel> i should upgrade to msys2 some day, but i cba to adapt all my scripts because those idiots went with a brain-dead idea of requiring a special script to run instead of just making sh.exe work <.<
[22:33:30 CEST] <nevcairiel> old msys has old make :P
[22:36:08 CEST] <Compn> you can upgrade msys to have 3.81 , which compiles ffmpeg fine :P
[22:36:18 CEST] <rcombs> https://trac.ffmpeg.org/ticket/2686#comment:379 probability of this estimate being correct approaches 0
[22:36:39 CEST] <nevcairiel> it was a third party estimate using the word "hope"
[22:37:19 CEST] <rcombs> I was naively optimistic :3
[22:38:08 CEST] <nevcairiel> i would rather go kill the GPL and its convoluted rules, and let me actually use a open-source encoder that produces good audio, which i just cannot use because the GPL-folks like to destroy all pleasure in this world
[22:38:44 CEST] <llogan> maybe if you ate toe jam you'd understand
[22:39:09 CEST] <nevcairiel> I could write a separate encoder module for  my software that doesn't go through ffmpeg to access it, then i could actually ship it without troubles
[22:39:23 CEST] <nevcairiel> but thats serious effort, since currently i managed to make all encoding run through ffmpeg =P
[22:39:49 CEST] <Compn> nevcairiel : why not just write your own gpl audio encoder huh?
[22:39:54 CEST] <Compn> huh huh huhuh huhuhuhuuuuuuuuuuuuuh ?
[22:39:57 CEST] Action: Compn runs
[22:40:02 CEST] <nevcairiel> because i wouldn't use gpl for such things
[22:43:03 CEST] <nevcairiel> its just silly that some stupid license reason is blocking it .. and its not even the condition itself thats the problem, its just that the GPL doesn't like it
[23:05:08 CEST] <rcombs> nevcairiel: the best part being that the condition is effectively legally useless
[23:05:20 CEST] <rcombs> assuming you mean the FDK one
[23:05:25 CEST] <nevcairiel> of course
[23:07:02 CEST] <nevcairiel> i should just hack the non-free condition out of configure and bundle it, not like anyone does anything about it anyway
[23:08:58 CEST] <jamrial> nevcairiel: what about the changes from the epic aacenc trac ticket? does it produce good enough audio its the current state?
[23:09:10 CEST] <Daemon404> it ties till lame last i checked
[23:09:12 CEST] <Daemon404> so... no
[23:09:28 CEST] <nevcairiel> i'm currently using the aacenc from master and its mostly fine to my bad ears, so what do i care
[23:10:06 CEST] <nevcairiel> and tieing lame isnt that bad, lame is considered decent
[23:10:39 CEST] <nevcairiel> of course we could save some bits with a higher quality encoder and reducing audio bandwidth =p
[23:11:05 CEST] <jamrial> does it need to be aac? because there's always libvorbis and libopus
[23:11:28 CEST] <nevcairiel> well, mostly yes
[23:11:32 CEST] <nevcairiel> streaming to android phones
[23:11:35 CEST] <nevcairiel> format limiations etc
[23:11:53 CEST] <nevcairiel> although i recently switched to exoplayer, i could make it more flexible in the future
[23:13:29 CEST] <nevcairiel> i wonder, has anyone ever put vorbis in ts? =P
[23:14:05 CEST] <nevcairiel> although i could probably stream fMP4 instead, but that probably doesnt do vorbis either
[23:14:07 CEST] Action: Daemon404 aims at nevcairiel's head...
[23:14:23 CEST] <nevcairiel> name me a streaming format thats not horrible
[23:15:22 CEST] <Daemon404> well ts is extract horrible
[23:15:35 CEST] <nevcairiel> for h264/aac it seems to be working fine now :)
[23:15:49 CEST] <Daemon404> but xiph formats are all sorts of extra pain
[23:15:55 CEST] <Daemon404> cause they were designed for ogg
[23:15:58 CEST] <Daemon404> just ask kierank.
[23:17:56 CEST] <nevcairiel> for streaming of real-time encoded things to mobile android devices, there just isnt a good answer
[23:18:11 CEST] <nevcairiel> h264/aac in ts is the least evil format that i can easily do
[23:18:19 CEST] <Daemon404> i hope you dont mean hls
[23:18:22 CEST] <Daemon404> cause android hls is lulz
[23:18:48 CEST] <nevcairiel> we used to use hls, but hls support is terrible, but we switched to plain ts streaming now since exoplayer allows us to do that
[23:19:05 CEST] <Daemon404> right
[23:19:16 CEST] <nevcairiel> ..didnt want to ship a full ffmpeg-based media stack <.<
[23:19:25 CEST] <Daemon404> im guessing fragmented mp4 support isnt widespread enough yet?
[23:19:43 CEST] <nevcairiel> would also work, similar format restrictions though
[23:19:45 CEST] <jamrial> wasn't Opus going to be supported in ts at some point?
[23:19:51 CEST] <Daemon404> it is
[23:19:55 CEST] <Daemon404> and its beign used
[23:19:56 CEST] <nevcairiel> only h264 video (which is fine), aac, ac3 audio
[23:20:08 CEST] <Daemon404> nevcairiel, true.
[23:20:26 CEST] <Daemon404> nevcairiel, no mp3?
[23:20:42 CEST] <nevcairiel> should poke kierank into making ts muxer support opus writing, then i can submit a patch to exoplayer to read opus in ts .. somehow :d
[23:20:53 CEST] <Daemon404> i thought he sent a patch
[23:20:56 CEST] <Daemon404> or was that only demux
[23:20:59 CEST] <nevcairiel> did he?
[23:21:02 CEST] <nevcairiel> i thought only demux
[23:21:02 CEST] <Daemon404> yes...
[23:21:09 CEST] Action: nevcairiel checks
[23:21:31 CEST] <Daemon404> hmm looks like demux
[23:21:32 CEST] <Daemon404> from google
[23:21:54 CEST] <Daemon404> he likely uses his own lib to mux.
[23:23:00 CEST] <jamrial> kierank sent a patch for opus in ts demuxing and it was applied, yeah
[23:23:07 CEST] <jamrial> nothing for the muxer, though
[23:23:42 CEST] <kierank> Yes because people are implementing it broken
[23:23:50 CEST] <kierank> And outputting broken files
[23:24:22 CEST] <kierank> Because they are remixing weird ogg files
[23:24:55 CEST] <kierank> Because FFmpeg does not operate in an adult fashion the mux will have to be merged within seconds and so more broken files will be made
[23:25:24 CEST] <jamrial> weird ogg files made by ffmpeg?
[23:25:24 CEST] <Daemon404> lol
[23:25:28 CEST] <Daemon404> jamrial, no
[23:25:35 CEST] <Daemon404> ogg is weird, ffmpeg doesnt fully support it
[23:25:39 CEST] <jamrial> ah
[23:26:00 CEST] <nevcairiel> i still dont understand how someone could think up such a crazy container format
[23:26:08 CEST] <nevcairiel> why do you go out of your way to make it so complex
[23:26:23 CEST] <nevcairiel> its not even being super efficient or anything
[23:26:28 CEST] <nevcairiel> its just crazy for no reason
[23:26:58 CEST] <Daemon404> i dunno it was 1992
[23:31:49 CEST] <jamrial> i would resurrect my pcm-in-ogg demuxing patch (because why not?), but there's apparently no other library or application out there that can create or even read them
[23:31:51 CEST] <jamrial> there's a spec on xiph.org, and that's it
[23:31:59 CEST] <jesseg> Does configure have a backgrounded cleanup routine that deletes the temp files on exit?
[23:32:28 CEST] <nevcairiel> it does not leave behind any temp files here
[23:33:03 CEST] <nevcairiel> not sure if it has hooks to make sure they get removed if you interrupt the script, but maybe it does
[23:33:05 CEST] <jesseg> I know. Not here either. And even if I put in an 'exit' at a point where the temp file does exist, the temp file is gone when my "exit" is hit
[23:33:20 CEST] <jesseg> or after my exit is hit :)
[23:33:51 CEST] <Daemon404> do you have any crap that cleans up /tmp too aggressively
[23:34:30 CEST] <jesseg> LOL nope. There is 1.8G of junk in there going back to 2013
[23:43:41 CEST] <jesseg> Thanks guys!
[23:55:46 CEST] <Compn> is this worth fixing? https://trac.ffmpeg.org/ticket/4508
[23:55:52 CEST] <Compn> nvenc possible typo
[23:56:20 CEST] <cone-663> ffmpeg 03Michael Niedermayer 07master:4fe38441b0fc: ffmpeg: do not print misleading recommanditions on 1pass vpx encoding
[23:59:55 CEST] <llogan> Compn: maybe ask BtbN or philipl
[00:00:00 CEST] --- Wed May 27 2015