[Ffmpeg-devel-irc] ffmpeg-devel.log.20140903
burek
burek021 at gmail.com
Thu Sep 4 02:05:02 CEST 2014
[00:00] <michaelni> ffmpeg-devel ML is best for patches
[00:05] <mirabilos> ok
[00:05] <mirabilos> gn8
[00:06] <ubitux> llogan: no comment from me
[00:06] <ubitux> BBB: x32 is actually sexy in theory
[00:06] <BBB> a lot of useless things sound sexy
[00:07] <ubitux> and it was said to be faster
[00:07] <mirabilos> its better than systemd at least :D
[00:07] <BBB> oh wow, what a call to glory
[00:07] <mirabilos> yeah, its faster in pointer-intensive workloads, and for applications where LP64 does not make sense
[00:07] <mirabilos> e.g. mkshs internal data structures are fine-tuned for ILP32
[00:07] <mirabilos> theres just no point in building the shell for LP64 if you dont need to
[00:08] <mirabilos> it only gets bigger and slower (and slower due to being bigger, cache poisoning, too)
[00:08] <ubitux> mirabilos: would you be able to setup a FATE instance with x32?
[00:08] <mirabilos> its perfect for something like x32, which can do 64-bit registers if needed, and has more GPRs
[00:08] <mirabilos> whats FATE?
[00:08] <J_Darnley> our test suite
[00:08] <ubitux> FFmpeg Automated Test Environment
[00:08] <ubitux> http://fate.ffmpeg.org/
[00:09] <BBB> look
[00:09] <mirabilos> sorry, Im not involved in ffmpeg really, just trying to use my Debian (and hacking it& I got porter upload rights)
[00:09] <mirabilos> mh
[00:09] <BBB> Im gonna be brutally hard and honest here
[00:09] <ubitux> it's a farm from various dev & fans
[00:09] <mirabilos> good question
[00:09] <BBB> were not a shell, or some bash script, or shit
[00:09] <mirabilos> BBB, please do shut up
[00:09] <BBB> were a multimedia environment with massive amounts of hand-tuned assembly
[00:09] <BBB> I do actually know what Im talking about
[00:09] <mirabilos> sure. I like to do asm myself, you know.
[00:09] <BBB> I dont think it serves and purpose
[00:09] <BBB> other than academic
[00:10] <BBB> but sure, if you want ot do it, go for it, your time
[00:10] <BBB> Good Luck
[00:10] <kepstin-laptop> the main issue with x32 is that it just came too late, imo; people had already finished optimizing for lp64 before it was ready.
[00:10] <mirabilos> right
[00:10] <mirabilos> fun fact: most of that applies to x32 too&
[00:10] <ubitux> mirabilos: well first, checking if "make fate" actually passes after compilation will be a good start
[00:10] <mirabilos> just use long long instead of long, and be aware of shorter pointers
[00:10] <mirabilos> ok
[00:11] <ubitux> you'll need to make fate-rsync to grab the samples
[00:11] <mirabilos> Ill make a note. I cant promise it, but ok. Ive got a ton of other missing things to work out first.
[00:11] <dahat> Quick sanity question... when building ffmpeg under MinGW for Windows with the VS2013 compiler and using the --enable-libx264 argument when running configure... what is the filename of the .lib that the build process should go looking for? libx264.lib or x264.lib?
[00:11] <ubitux> anyway, see https://ffmpeg.org/fate.html for more info
[00:11] <ubitux> mirabilos: it will provide a good test coverage
[00:11] <ubitux> mirabilos: because IMO compilation is not the only thing that will break
[00:11] <J_Darnley> dahat: didn't you get an answer for that on #x264dev ?
[00:11] <mirabilos> ubitux: definitely
[00:12] <dahat> I did... but I want see if the ffmpeg folks have the same answer... as I still can't explain the disconnect in my build attempts
[00:14] <J_Darnley> ffmpeg not using pkg-config, probably.
[00:15] <dahat> when not installed, configure will warn you at the end that package detection may fail... however after installing it the warning goes away but but I was seeing the detection happen just as poorly
[00:15] <ubitux> mirabilos: if you want to test libpostproc coverage only, try make fate-filter-pp{,2,3,4,5,6}
[00:16] <ubitux> J_Darnley: carl asked for one more week for him to look into the issue
[00:17] <ubitux> i hope to get pkg-config detection in after that
[00:18] <dahat> unbitux: thanks for the update, do you know of a work around in the mean time?
[00:19] <mirabilos> ubitux: Debian has a tree in which just libpostproc is
[00:19] <mirabilos> I may eventually build ffmpeg itself from source
[00:19] <mirabilos> but at the moment I'm concentrating on basic Debian packages needed deep in the dependency chain
[00:19] <wm4> fuck I really just reviewed a 87KB patch
[00:19] <mirabilos> (that being said, I'm personally interested in getting mplayer with ffmpeg)
[00:19] <mirabilos> wow
[00:20] <ubitux> dahat: apply the pkg-config patch :p
[00:21] <ubitux> dahat:
[00:21] <ubitux> -enabled libx264 && require libx264 x264.h x264_encoder_encode -lx264 &&
[00:21] <ubitux> - { check_cpp_condition x264.h "X264_BUILD >= 118" ||
[00:21] <ubitux> - die "ERROR: libx264 must be installed and version must be >= 0.118."; }
[00:21] <ubitux> +enabled libx264 && require_pkg_config "x264 >= 0.118" "stdint.h x264.h" x264_encoder_encode
[00:21] <ubitux> feel free to try that
[00:26] <wm4> also, probetest prints failures for various formats I didn't touch
[00:32] <dahat> ubitux: thanks for the suggestion, I'll give it a try
[01:16] <llogan> J_Darnley: can you spot my dumb typo? http://pastebin.com/raw.php?i=XhpfRkwn
[01:34] <AGinsberg> In the LICENSE file it says libfaac and libaacplus are non-free but both of the source files says it's Free, is it or not?
[01:37] <Timothy_Gu> AGinsberg: both of them use reference code which is not free
[01:38] <Timothy_Gu> AGinsberg: libfaac and libaacplus's modifications to the reference code are free
[01:38] <J_Darnley> llogan: sorry, what am I looking for?
[01:38] <J_Darnley> It is probably that my code is still broken
[01:40] <AGinsberg> Timothy_Gu: Okay, thanks
[01:51] <Timothy_Gu> llogan: reviewed
[01:52] <Timothy_Gu> llogan: ahh get it now
[01:53] <Timothy_Gu> J_Darnley: Input #0, wav, from '/home/lou/jdanrley/jdarnley-ffmpeg/tests/data/asynth-44100-2.wav':
[01:54] <Timothy_Gu> (?i)root.?nexus lol
[02:13] <wm4> more unification talk *groan*
[02:15] Action: J_Darnley thanks his filter
[02:16] <kierank> good luck with that
[02:16] <kierank> it'll happen the same day as north and south korea
[02:16] <kierank> i won't pass judgement on which is which
[02:17] <j-b> kierank: one side will die.
[02:17] <kierank> i agree
[02:18] <wm4> north korea is an interesting comparison
[02:18] <kierank> wm4: protestant/catholic is a better one
[02:18] <wm4> I'm sure Libav would like it, along with calling mini "the leader"
[02:19] <kierank> but one project is becoming more isolated
[02:19] <j-b> yep
[02:19] <j-b> and the other one keeps the same crap tactics that lead to the fork
[02:19] <wm4> sad
[04:10] <cone-711> ffmpeg.git 03Pascal Massimino 07master:7a1d6ddd2c6b: xvid: Add C IDCT
[04:10] <cone-711> ffmpeg.git 03Michael Niedermayer 07master:5b58d79a9965: Merge commit '7a1d6ddd2c6b2d66fbc1afa584cf506930a26453'
[04:19] <cone-711> ffmpeg.git 03Gabriel Dume 07master:eda7571ea1a4: wmv2: K&R formatting cosmetics
[04:19] <cone-711> ffmpeg.git 03Michael Niedermayer 07master:feac9cbed060: Merge commit 'eda7571ea1a41c835e3a02fa9517e5bc67d7adce'
[06:08] <cone-711> ffmpeg.git 03Michael Niedermayer 07master:50841da14331: avcodec/mpeg4videodec: fix automatic use of the xvid idct on non x86
[06:08] <cone-711> ffmpeg.git 03Michael Niedermayer 07master:928cb84b32b6: avcodec/idctdsp: Initialize ff_put/add_pixels_clamped correctly so that the optimized functions are also used
[06:22] <Timothy_Gu> Zeranoe: How did you build decklink for Windows on Linux? I can only see a bunch of interface declarations in the tarball and I am not sure how to use them with MinGW.
[06:23] <Timothy_Gu> I also tried widl but didn't seem to work with my command line.
[06:29] <Zeranoe> Timothy_Gu: I didn't, to include it in FFmpeg you need only provide the header
[06:30] <Timothy_Gu> Zeranoe: I know. The question is how did you build the headers? In the tarball there are only ".idl" files in the Windows directory
[06:36] <Zeranoe> Timothy_Gu: http://software.blackmagicdesign.com/SDK/Blackmagic_DeckLink_SDK_10.1.4.zip "Blackmagic DeckLink SDK 10.1.4\Linux\include\DeckLinkAPI.h" and so on
[07:24] <Zeranoe> I think d9e2aceb7f1c712a52672129ca7971872b030e1e breaks compiling with modplug for me.
[07:28] <jamrial> Zeranoe: the fate slot using that lib seems unaffected
[07:29] <Zeranoe> jamrial: ill check
[07:32] <Zeranoe> leaning towards 36952786a5cca8784f582a071c0d73ab1e3252a1 now
[07:41] <ubitux> mmh is libav really thinking the shared ml was an hostile move from ffmpeg? (koda seems to say something like "what a coincidence" on debian-devel)
[07:42] <ubitux> Zeranoe: --pkg-config=--static maybe?
[07:42] <ubitux> i wonder if pkg-config hasn't an automatic static fallback...
[07:42] <Zeranoe> ubitux: Set already, it might be on my end
[07:43] <ubitux> but static linking might have some licensing concerns, so not sure..
[07:50] <Zeranoe> Can confirm, 36952786a5cca8784f582a071c0d73ab1e3252a1 breaks configure for Win* at modplug. Seems to be the extra 'long check_ModPlug_Load(void) { return (long) ModPlug_Load; }'
[07:50] <ubitux> Zeranoe: can you paste the config.log somewhere?
[07:51] <ubitux> (or just the relevant part at the end)
[07:53] <dahat> ubitux: thanks for your earlier suggestion as to my issues with building ffmpeg with x264 built under MinGW... it seems some part of my changes to make pkg-config work may have damged other things... now I see the following in config.log which suggests to me that it is now using the wrong arguments for the compiler/linker:
[07:53] <dahat> link -nologo -Ic:/MinGW1/msys/1.0/local/include -Lc:/MinGW1/msys/1.0/local/lib -out:./ffconf..BG81.500.3428.exe ./ffconf..BG81.500.3428.o x264.lib psapi.lib advapi32.lib shell32.lib
[07:53] <dahat> LINK : warning LNK4044: unrecognized option '/Ic:/MinGW1/msys/1.0/local/include'; ignored
[07:53] <dahat> LINK : warning LNK4044: unrecognized option '/Lc:/MinGW1/msys/1.0/local/lib'; ignored
[07:53] <dahat> LINK : fatal error LNK1181: cannot open input file 'x264.lib'
[07:53] <dahat> ERROR: x264 not found
[07:56] <Zeranoe> After 36952786a5cca8784f582a071c0d73ab1e3252a1: http://paste.debian.net/119073/ and before: http://paste.debian.net/119074/ (slightly edited.)
[07:56] <ubitux> dahat: pkg-config returns -I and -L paths which don't seem to be recognized by your setup; i never used mingw so i can't help you
[07:57] <Zeranoe> dahat: ever cross compile? much faster+less error prone+easier after initial setup
[08:00] <ubitux> Zeranoe: huuuh that's weird
[08:00] <ubitux> there was only 2 lines in the original test?
[08:01] <Zeranoe> looks like it
[08:01] <ubitux> and so the function wasn't actually tested?
[08:03] <ubitux> Zeranoe: pkg-config --static --libs --cflags libmodplug returns everything you need for the linkage?
[08:04] <Zeranoe> ubitux: Should be... -I/home/kyle/software/ffmpeg/pkgs/libmodplug/libmodplug-0.8.8.5-win32/include -L/home/kyle/software/ffmpeg/pkgs/libmodplug/libmodplug-0.8.8.5-win32/lib -lmodplug -lstdc++ -lm
[08:05] <ubitux> they also appear in the log unless i'm mistaken
[08:06] <Zeranoe> correct
[08:07] <ubitux> i don't see anything obviously wrong&
[08:07] <Zeranoe> in the new? post 36952786a5cca8784f582a071c0d73ab1e3252a1 that is?
[08:08] <dahat> ubitux: it is a shame that pkg-config doesn't handle properly providing input to the VS2013 compiler under MinGW
[08:09] <dahat> zeranoe: Nay, I've not attempted to cross compile ffmpeg & libx264... however that seems to be needed now given their failure to build together for me for basic x86... let alone my target of windows store (multi arch) and windows phone (arm)
[08:10] <Zeranoe> dahat: how would FFmpeg run in the store?
[08:10] <Zeranoe> Or do you just mean as backend
[08:11] <ubitux> Zeranoe: yes, in the post 36952786a5cca8784f582a071c0d73ab1e3252a1
[08:11] <ubitux> Zeranoe: i don't understand why it would fail
[08:12] <dahat> zeranoe: as an middle layer, decoding specified input from remote servers locally for UI presentation through a higher level locally
[08:12] <Zeranoe> dahat: I have a feeling MS will kill the store for desktops with 9... But i could be wrong
[08:13] <Zeranoe> dahat: imp is generally a dllexport thing. I'll dig into modplug tomorrow to see if it's doing naughty things
[08:13] <ubitux> ok, thank you!
[08:13] <Zeranoe> ubitux: ^
[08:15] <dahat> Zeranoe: I wouldn't be able to say either way... though native code is supported in 8.0 & 8.1 Windows (desktop) store apps... and in 8.1 phone apps... all provided it is compiled just right... so it is possible to compile ffmpeg for it... so long as external libs are able to be handled as well... but even this is beyond my focus right now as I can't even get ffmpeg to build against libx264 for native windows desktop uses
[08:17] <Zeranoe> dahat: MinGW-w64+Debian/Ubuntu and you'll be all set. I have a script on my site (zeranoe.com) that will build the compiler for you on a linux machine. Just install Debian or Ubuntu in VBox, run the toolchain script and cross-compile everything.
[08:20] <Zeranoe> Almost 2:30AM my time. I'll be back on later.
[08:23] <dahat> VBox? *gasp* I've been primarily a Windows user and later developer for multiple decades now! ... though I will attempt such things in Hyper-V tomorrow or Thursday
[08:24] <Zeranoe> dahat: Sometimes Windows just can't cut it.
[08:25] <jamrial> dahat: "link" is msvc's linker, and -L and -I are afaik gcc options for lib and include paths
[08:25] <jamrial> x264 must have created the pgk-config files for mingw, not msvc
[08:25] <Zeranoe> jamrial: I believe he was using Mingw... if not, theres your problem
[08:25] <dahat> Zeranoe: Sometimes true I fear, though for my target audiance, it is my only choice
[08:26] <dahat> jamrial: You are correct, hence my worry about the -L & -I arguments being specified to MSVC's link.exe
[08:27] <Zeranoe> Good luck, BBL
[08:29] <dahat> thanks, I will need it, the wife just asked when I was coming to bed for the evening so think I will be going now as well (11:28 pm PDT) when I have a few early (to a dev) morning meetings in... the morning
[09:23] <anshul_mahe> has anyone noticed that in ffmpeg.c input_thread function we are passing address of pkt on stack to other thread
[12:15] <ubitux> http://kojevnikov.com/faster-fast-fourier-transform.html
[12:15] <ubitux> "I am however surprised how fast the FFTW is compared to avfft (approximately 60% faster!)"
[12:15] <ubitux> we should do something about it
[12:21] <cone-814> ffmpeg.git 03Luca Barbato 07master:4912b634b517: x265: Use the encoder defaults
[12:21] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:eacf42dd5088: Merge commit '4912b634b517c8acfc476c5d47f10be83fe7e18b'
[12:33] <cone-814> ffmpeg.git 03Luca Barbato 07master:94f084324e64: texi2pod: Make it output a single encoding string
[12:33] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:4d13d440ee75: Merge commit '94f084324e648876508bed546d950762f10b875e'
[13:00] <cone-814> ffmpeg.git 03Luca Barbato 07master:7968059e5c3c: mpegts: Allow custom max resync size
[13:00] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:ee83f667afd2: Merge commit '7968059e5c3cd8f91407f379c11bbf71a1b84c74'
[13:00] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:e489e8346672: avformat/mpegts: Change order of structs to match 7968059e5c3cd8f91407f379c11bbf71a1b84c74
[13:29] <cone-814> ffmpeg.git 03Luca Barbato 07master:c19a49e565bd: ppc: Support little endian intreadwrite
[13:29] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:34e80af860d6: Merge commit 'c19a49e565bd06ea47947d50779ba236df9d4943'
[13:49] <cone-814> ffmpeg.git 03Luca Barbato 07master:bb3ead7e54fe: x11grab: Fallback to normal XImage if SHM is not supported
[13:49] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:33bf66af02fe: Merge commit 'bb3ead7e54fec205c595cfb8b1d8900d50d3d1cc'
[14:05] <cone-814> ffmpeg.git 03Luca Barbato 07master:65e78a2e4b11: x11grab: Refactor pixel format parsing
[14:05] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:7509a95656cd: Merge commit '65e78a2e4b111627c0ebdf2c9baec95e5e21560d'
[14:13] <ubitux> btw, can't we make it faster with out of place transform? (we can save the permutation, no?)
[14:46] <ubitux> http://pastie.org/pastes/9524067/text :))
[14:51] <cone-814> ffmpeg.git 03Luca Barbato 07master:ebef9f5a56d7: time: Use clock_gettime if the monotonic clock is available
[14:51] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:dc81c0a0dc7b: Merge commit 'ebef9f5a56d7df91e010a177a80cfc8dbe394305'
[15:04] <cone-814> ffmpeg.git 03Thomas Volkert 07master:95e177eeb21f: rtpdec: HEVC/H.265 support
[15:04] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:4bc4f6f17079: Merge commit '95e177eeb21f3e968aa9353bc69d1946966cc835'
[15:11] <cone-814> ffmpeg.git 03Mika Raento 07master:c487972ed0e1: ismindex: recover from completely empty streams
[15:11] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:d9a416fa1a7b: Merge commit 'c487972ed0e1eaebdbe4a13cdd191e119be0b19c'
[16:05] <BBB> wow, did koda just seriously say that michael is the only serious developer in ffmpeg?
[16:08] <av500> there are serious developers in ffmpeg?
[16:08] Action: av500 hides
[16:11] <TimNich> Some people take themsleves too seriously sometimes, and thats when grief happens..
[16:16] <ubitux> BBB: yes, ffmpeg is alive only because michael is sucking out all the code from libav
[16:16] <Daemon404> forkwars again?
[16:16] Action: Daemon404 clicks "mark folder as read"
[16:17] <nevcairiel> again? its been going on for weeks now
[16:17] <nevcairiel> so, still!
[16:17] <ubitux> years you mean
[16:17] <ubitux> :P
[16:17] <nevcairiel> well it kinda started up again fresh just recently
[16:17] <ubitux> yes, because i asked for some cooperation
[16:17] <ubitux> what a coincidence!
[16:17] <nevcairiel> i meant more the debian thing
[16:19] <ubitux> we're still stalled for $noreason
[16:20] <ubitux> ah btw, are we going to push the mona lisa?
[16:21] <BBB> Im so confused now
[16:23] <ubitux> mmh wait the tests are duplicated with the mona_lisa patch
[16:24] <Daemon404> ubitux, i honestly think that patch is fucking retarded
[16:24] <Daemon404> to appease some shitty debian person
[16:29] <ubitux> https://encrypted.google.com/search?tbm=isch&q=mandrill.bmp&tbs=imgo:1
[16:29] <ubitux> what is the license of this one?
[16:29] <ubitux> it's the same squared dimension as lena
[16:29] <ubitux> and is famous as well in image processing
[16:30] <av500> the monkey might own the right to that image
[16:30] <ubitux> :D
[16:31] <ubitux> http://www.telegraph.co.uk/technology/news/11015672/Wikipedia-refuses-to-delete-photo-as-monkey-owns-it.html
[16:31] <iive> it is great photo and great monkey :)
[16:32] <kierank> av500: we should ask lydia about that
[16:32] <av500> right
[16:33] <wm4> how do they know the monkey granted usage rights
[16:33] <kierank> the monkey is non-human and thus has no copyright
[16:34] <iive> wm4: it made the photo using the phone/camera
[16:34] <nevcairiel> the argument was that the monkey made the image, and since monkeys cant hold copyright, it reverts to public domain
[16:34] <nevcairiel> of course the photographer who owned the camera didnt agree
[16:48] <ubitux> heh i'm posting a feminist stupid article
[16:48] <ubitux> that won't help my argument
[16:48] <ubitux> oh well i'm out
[17:13] <Rodeo> hi guys, ffmpeg has threaded audio decoding, but not threaded encoding yet, correct?
[17:13] <Daemon404> i doubt the latter will ever happen
[17:13] <Daemon404> i cant imagine audio dec/enc benefits massively from it...
[17:18] <Rodeo> just wanted to get my facts straight, someone on a forum is recommending using -threads to speed up FLAC encoding&
[17:19] <Daemon404> lol.
[17:20] <ubitux> decode is threaded
[17:20] <ubitux> and it is automatically, so you don't need -threads
[17:21] <ubitux> Daemon404: it actually makes a difference :p
[17:21] <Daemon404> hearsay
[17:21] <ubitux> no, we tried the other day
[17:21] <Rodeo> well, thanks for the info
[17:22] <nevcairiel> can flac encoding even be really "slow"? how long would a file be to even wonder?
[17:27] <Rodeo> nevcairiel: libavcodec FLAC is only like, a million times faster than FDK-AAC, that's still pretty slow&
[17:28] <ubitux> on a 2h flac (let's say an audio movie), it takes 4.5s instead of 9s
[17:28] <ubitux> :X
[17:28] <nevcairiel> lol
[17:28] <nevcairiel> the savings
[17:28] <nevcairiel> sure, its twice as fast, but really caring, i do not
[17:28] <ubitux> it's sine audio, it will probably be slower with a more complex input :p
[17:44] <wm4> <ubitux> and it is automatically, so you don't need -threads <- really?
[17:44] <ubitux> yes
[17:45] <wm4> on the library level or is ffmpeg.c doing this?
[17:46] <ubitux> ffmpeg.c: av_dict_set(&ist->decoder_opts, "threads", "auto", 0);
[17:46] <ubitux> libavcodec/options_table.h:{"threads", NULL, OFFSET(thread_count), AV_OPT_TYPE_INT, {.i64 = 1 }, 0, INT_MAX, V|A|E|D, "threads"},
[17:46] <ubitux> i suppose it's ffmpeg.c
[17:46] <ubitux> on a *very* quick look
[17:50] <wm4> default is 1?
[17:50] <wm4> so ffmpeg.c does it?
[17:51] <ubitux> iirc 0 is auto, 1 is 1 process (no actual thread), ...
[17:51] <ubitux> and i'd say ffmpeg makes it auto automatically unless specified otherwise
[17:51] <ubitux> that's my understanding after a quick look
[17:53] <wm4> looking at some of the code, it seems so
[17:54] <wm4> why not enable it in the lib by default?
[17:54] <ubitux> michaelni: i'd like to review the idet patch, please don't apply immediately
[17:54] <wm4> though maybe not for audio
[17:54] <wm4> but video - why not
[17:54] <ubitux> no idea
[17:55] <wm4> I suppose some prefer low latency over speed
[17:55] <wm4> but most people probably get confused and don't know that they have to set an obscure option to make it fast
[18:20] <ubitux> stallman vs hitler
[18:20] <ubitux> what's worse?
[18:22] <nevcairiel> wm4: i thought threading was on by default for video decoding
[18:23] <nevcairiel> guess some people complained abouit problems
[18:43] <gnafu> ubitux: It depends on what you value, I guess. If you agreed with Hitler, then Stallman is worse. If you agree with Stallman, then Hitler is worse. If you agree with both of them, Heaven help you.
[18:43] <nevcairiel> ..and for neither?
[18:44] <J_Darnley> Rodeo: I made the flac encoder faster with some SIMD so make sure you're using the newest code.
[18:44] <gnafu> nevcairiel: Well, I figured that state had a clear definition already.
[18:44] <gnafu> You're "sane".
[18:44] <nevcairiel> gnafu: yeah but whats worse then?
[18:44] <gnafu> ("Sanity" being relative, hence the quotes.)
[18:45] <nevcairiel> my mental state not withstanding =p
[18:45] <J_Darnley> Rodeo: oh, you will also need a CPU with sse4
[18:45] <gnafu> nevcairiel: It's all a matter of perspective. Some people like to focus only on the good done, so they might admire Hitler for the good things he was credited with.
[18:46] <gnafu> Who has had, is having, and will have the greater impact on the world? And is their final impact more positive or more negative.
[18:46] <gnafu> I think it's safe to say Hitler was worse in that regard, but Stallman isn't finished yet ;-).
[18:48] <iive> gnafu: are there good things that hitler did that haven't been ruined because of the war?
[18:52] <gnafu> iive: Well, I've heard some credit him with the Autobahn and the Beetle, though I'm sure those could have come about just fine without him.
[18:53] <gnafu> I'm not saying I honestly believe he had any good that weighs measurably against the bad.
[18:53] <gnafu> But I've talked to people who had that perspective.
[18:54] <iive> well, he has done more good by been example of pure evil.
[18:54] <iive> also, I think Tesla uses linux, so stallman may have helped with it too :P
[18:55] <gnafu> Aah, but do they use *GNU/Linux*?
[18:55] <iive> i don't have enough money to checkout :)
[18:56] <gnafu> "What happens when your Tesla runs out of juice?" "You stall, man."
[18:56] <iive> just change the battery :D
[18:58] <gnafu> "What happens when the brakes go out on your Beetle while approaching Ler?" "You hit Ler."
[18:59] <iive> gnafu: or "you invade poland"
[18:59] <gnafu> XD!
[19:02] <gnafu> I was surprised to find there actually is a place called "Ler" in Norway, according to Wikipedia.
[19:25] <jnvsor> Once wayland is a more widely used system, how long do you think it will be before wcap is added as an ffmpeg device?
[19:27] <J_Darnley> Are people still banging on about lena?
[19:28] <J_Darnley> Change to use the image that monkey took of itself
[19:28] <J_Darnley> Didn't "the man" rule that it cannot be protected under copyright?
[19:28] <jnvsor> Yep
[19:29] <jnvsor> "Natural works are not works of art" or some such
[20:13] <cone-978> ffmpeg.git 03Jörg Krause 07master:02a2e171ad3c: libavutil/error: fix build with musl toolchain
[20:16] <iive> \o/ for musl
[20:40] <cone-978> ffmpeg.git 03Lou Logan 07master:efaa4a8dbf7f: doc/demuxers: document gif demuxer
[20:58] <ubitux> so, still no one to port eq/eq2? :(
[21:01] <J_Darnley> I might be able to do that.
[21:02] <J_Darnley> Can I ask what the difference between the two are?
[21:04] <ubitux> eq2 has more things but is slower in some cases apparently
[21:04] <ubitux> honestly you only care about eq2
[21:05] <ubitux> so, re: #3902
[21:05] <ubitux> it seems the packet re-ordering is affected by --disable-decoders --disable-hwaccels
[21:05] <ubitux> i have no idea why
[21:06] <nevcairiel> parser?
[21:06] <nevcairiel> hm not sure if disabling decoder would also hit its parser
[21:06] <nevcairiel> it shouldnt really
[21:06] <ubitux> http://b.pkh.me/packet-order.html
[21:07] <ubitux> left is by default, right is with --disable-decoders --disable-hwaccels
[21:07] <nevcairiel> that makes no sense at all, nothing is even really designed to re-order packets
[21:07] <J_Darnley> ubitux: I'll have an in depth look a little later.
[21:07] <nevcairiel> or wait, does it actually re-order packets?
[21:07] <nevcairiel> or does the interleaving just change?
[21:08] <ubitux> what's printed is what the muxer receive
[21:08] <nevcairiel> looks like stream 0 is delayed by one on the right
[21:08] <nevcairiel> what codec was this?
[21:09] <ubitux> Stream #0:0(eng): Video: mpeg2video (Main), yuv420p(tv), 720x576 [SAR 64:45 DAR 16:9], max. 7500 kb/s, 25 fps, 25 tbr, 1k tbn, 50 tbc (default)
[21:09] <ubitux> (in mkv)
[21:10] <nevcairiel> my theory is, without the decoder, the init code in avformat doesnt manage to prove some things, so stuff like has_b_frames is not set, messing with the timestamp code?
[21:10] <nevcairiel> s/prove/probe/
[21:10] <nevcairiel> thats all i got
[21:13] <ubitux> yeah, sounds about right
[21:13] <nevcairiel> that whole timestamp stuff is arcane magic
[21:14] <ubitux> a probe with both version is kind of different
[21:14] <ubitux> like, it's indeed lacking a lot of information without the decoders
[21:14] <ubitux> such as the codec timebase :p
[21:24] <cone-978> ffmpeg.git 03Reimar Döffinger 07master:672425411804: ffv1enc: reduce stack usage.
[21:24] <cone-978> ffmpeg.git 03Reimar Döffinger 07master:fcfc90ed65ef: svq1enc: remove pointless array element.
[21:24] <cone-978> ffmpeg.git 03Reimar Döffinger 07master:235d401bfa40: vorbisenc: avoid large stack allocation.
[22:23] <cone-978> ffmpeg.git 03Gabriel Dume 07master:d2a4e4b9cc9a: wma: K&R formatting cosmetics
[22:23] <cone-978> ffmpeg.git 03Michael Niedermayer 07master:75a9859ac67b: Merge commit 'd2a4e4b9cc9a0c2661e1c1d6f6b51babac2cec1b'
[22:56] <J_Darnley> When you blend two images using a "multiply" blend, exactly what operation would you expect it to do? "clip(a * b)" or "(a * b) / max_value"
[22:59] <J_Darnley> Oh wait, this does do a divide
[23:04] <ubitux> - bps = (float)avctx->bit_rate / (float)(avctx->channels * avctx->sample_rate);
[23:04] <ubitux> - s->byte_offset_bits = av_log2((int)(bps * s->frame_len / 8.0 + 0.5)) + 2;
[23:04] <ubitux> + bps = (float) avctx->bit_rate /
[23:04] <ubitux> + (float) (avctx->channels * avctx->sample_rate);
[23:04] <ubitux> + s->byte_offset_bits = av_log2((int) (bps * s->frame_len / 8.0 + 0.5)) + 2;
[23:04] <ubitux> T_T
[23:05] <ubitux> so they decided to put some spaces after casts?
[23:05] <ubitux> i thought they decided to keep the sane way
[23:06] <ubitux> ok well
[23:06] <wm4> you should discuss this with Diego
[23:06] <ubitux> this diff is one of the worse ever
[23:07] <ubitux> - a = s->coefs[0][i]*0.5;
[23:07] <ubitux> + a = s->coefs[0][i] * 0.5;
[23:07] <ubitux> in what world this can be considered sane
[23:08] <ubitux> the patch is full of this shit, in addition to { } drops
[23:08] <ubitux> and spaces after casts
[23:10] <llogan> libocd
[23:10] Action: llogan touches doorknob three times, adds twelve spaces, then claps twice
[23:19] <ubitux> ...and sometimes they actually revert the alignment
[23:19] <ubitux> wth :D
[23:19] <ubitux> - AVFrame *frame = data;
[23:19] <ubitux> + AVFrame *frame = data; const uint8_t *buf = avpkt->data;
[23:19] <ubitux> - int buf_size = avpkt->size;
[23:19] <ubitux> + int buf_size = avpkt->size;
[23:19] <jamrial> they just really, really hate git blame
[23:19] <ubitux> (const uint ... is at the next line)
[23:25] <Diogo> ubitux: no i already asked this problem before. i need to acurate cut ffmpeg.. to generate múltiple files ts in diferents commands...can ffprpbe give that information to cut?
[23:25] <ubitux> "no"?
[23:25] <Diogo> no = hi :)
[23:26] <ubitux> no idea why you ask about ffprobe but you're looking for the segment muxer
[23:27] <smarter_> jamrial: "git blame -w" helps a bit
[23:27] <Diogo> But the segmenter to many counts about pts and dts..
[23:27] <ubitux> smarter_: doesn't handle all the random line breaks and { } drops
[23:27] <smarter_> yeah, that's why I said "a bit" :)
[23:27] <ubitux> -w makes blame even slower btw
[23:28] <ubitux> Diogo: dunno
[23:29] <Diogo> ok Thank you...Can you tell me some nick that can help me with this question?
[23:31] <kierank> 10:06 PM <wm4> you should discuss this with Diego --> that'll go down well
[23:31] <wm4> :)
[23:32] <llogan> Diogo: you could try the ffmpeg-user mailing list.
[23:33] <llogan> and the segment docs has some info about making accurate splitting
[00:00] --- Thu Sep 4 2014
More information about the Ffmpeg-devel-irc
mailing list