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

[burek]

[01:27] <jamrial> not sure if i want to try it, to be honest. this function as you said is not that heavy in the decoding, so a potentially more efficient approach will probably not matter enough to be worth figuring it out
[01:28] <jamrial> and i'm more interested in trying to port sao_edge_filter
[02:06] <cone-65> ffmpeg.git 03Michael Niedermayer 07master:be2ebc723d1f: avcodec/ratecontrol: replace asserts by av_asserts
[02:46] <cone-65> ffmpeg.git 03Michael Niedermayer 07master:f5722ba276e5: libavcodec/h264: replace assert() by av_assert0()
[05:13] <cone-65> ffmpeg.git 03Michael Niedermayer 07master:9f73b88c624a: avcodec/h261enc: fix dquant encoding
[10:34] <cone-104> ffmpeg.git 03Paul B Mahol 07master:335c150ba1d2: avcodec/svq1dec: remove unneeded #include, there are no assert()
[10:34] <cone-104> ffmpeg.git 03Paul B Mahol 07master:bc74f946bc94: avcodec/vc1: remove unneeded #includes, there are no assert() only av_assert*
[10:34] <cone-104> ffmpeg.git 03Paul B Mahol 07master:43630c82f1b0: avformat/utils: remove unneeded #include, there are no assert() only av_assert*
[10:35] <cone-104> ffmpeg.git 03Paul B Mahol 07master:ca8617a04d32: avformat/mpeg: remove unneeded #include, there are no assert() only av_assert*
[10:35] <cone-104> ffmpeg.git 03Paul B Mahol 07master:12c5addebc66: avformat/asfenc: remove unneeded #include, there are no assert() only av_assert*
[10:35] <cone-104> ffmpeg.git 03Paul B Mahol 07master:41456c7d159d: avformat/mux: remove unneeded #include, there are no assert() only av_assert*
[10:35] <cone-104> ffmpeg.git 03Paul B Mahol 07master:cc1357a17313: avformat/mov: remove unneeded #include, there are no assert()
[10:35] <cone-104> ffmpeg.git 03Paul B Mahol 07master:f705b1287bbd: avformat/movenc: remove unneeded #include, there are no assert() only av_assert*
[11:36] <cone-104> ffmpeg.git 03Stefano Sabatini 07master:fbccbd68325a: lavd/libcdio: apply minor fixes to options documentation
[11:37] <cone-104> ffmpeg.git 03Stefano Sabatini 07master:c8bec255eff3: lavd/libcdio: add more paranoia mode constants
[11:37] <cone-104> ffmpeg.git 03Stefano Sabatini 07master:f422f474dfa7: doc/indevs/libcdio: apply minor spell fixes, extend documentation
[13:26] <cone-104> ffmpeg.git 03Paul B Mahol 07master:e7e0005cc6c7: remove libmpcodecs
[13:29] <wm4> this calls for a celebration!
[13:45] <cone-104> ffmpeg.git 03Paul B Mahol 07master:a34f4e2fd2e0: avfilter: remove vf_mp.c
[13:52] <cone-104> ffmpeg.git 03Michael Niedermayer 07master:b288f67434db: avfilter/avfilter: Remove CONFIG_MP_FILTER case
[13:56] <ubitux> durandal_1707: configure:enabled mp_filter           && prepend avfilter_deps "avcodec"
[13:59] <cone-104> ffmpeg.git 03Paul B Mahol 07master:b47ab04c40ab: configure: remove mp_filter leftover
[14:04] <ubitux> thx
[14:35] <cone-104> ffmpeg.git 03Carl Eugen Hoyos 07master:4faea46bd906: lavc/aarch64: Do not use the neon horizontal chroma loop filter for H.264 4:2:2.
[14:35] <cone-104> ffmpeg.git 03Carl Eugen Hoyos 07master:f9f9ae1b77e4: lavc/arm: Use the neon vertical chroma loop filter also for H.264 4:2:2.
[14:35] <cone-104> ffmpeg.git 03Michael Niedermayer 07master:958836f8c519: Merge remote-tracking branch 'cehoyos/master'
[16:13] <ubitux> TIL tweaking just a bit the palette can change everything http://b.pkh.me/out-dither-sierra2-old.gif http://b.pkh.me/out-dither-sierra2-new.gif
[17:05] <durandal_1707> so how many dithering modes there will be?
[17:29] <ubitux> durandal_1707: for now just 6
[17:29] <ubitux> 1 deterministic (bayer) and 5 misc. error diffusal 
[17:30] <ubitux> bayer scale being customizable
[17:30] <ubitux> i'd like to add another deterministic one
[17:30] <nevcairiel> how large of a matrix for bayer do you use?
[17:30] <ubitux> maybe by implementing a void & cluster algorith to make a table of the size of the image itself (assuming that's indeed what it's about)
[17:30] <ubitux> 8x8
[17:31] <ubitux> also there are the other dither which was mentioned by the guy on the mailing-list, which i looked at for a while but haven't in details
[17:32] <ubitux> which might be worth looking at
[17:32] <nevcairiel> there were some good results in the still images on that website at least
[17:32] <nevcairiel> i looked over it some time ago
[17:33] <ubitux> for still image it's really not important, because error diffusal is always better anyway
[17:33] <ubitux> but for animation, your really need a deterministic dithering, otherwise you're doomed (with gif that is)
[17:34] <nevcairiel> well, even for error diffusal there is multiple ways to go about it .. just spread the error perfectly mathematically, or account for visual attributes, gamme weighted color comparisons etc
[17:35] <ubitux> yeah i need to look deeper at what he did
[17:35] <ubitux> right now i'm back to trying to improve the palette
[17:35] <ubitux> because the implementation i use has many flaws/limitations
[17:36] <ubitux> it's interesting, i'm looking at a paper which is basically presenting itself like an improvement of the original algorithm i implemented
[17:36] <ubitux> so the original algorithm is saying "we need to make an histogram of the 24-bit rgb colors"
[17:36] <ubitux> "but it's too much so we're going to make a 5:5:5 histograms (16-bits)"
[17:36] <ubitux> and so the new paper comes with a brillant idea
[17:36] <ubitux> "hey let's use 6:6:6, it's really way better"
[17:37] <ubitux> "well it takes a lot more memory but hey, who cares"
[17:37] <ubitux> "also 18-bit is not easy to deal with so we'll actually store them on 16-bit memory and make them overlap"
[17:38] <ubitux> i wonder why the hell they didn't just suggest a simple hash table to use as histograms
[17:38] <ubitux> (which i'm currently trying to implement)
[17:39] <iive> 18 bits is just 262144 combinations, so with 32bit int it would take 1MB ram
[17:40] <ubitux> how do you make a 18-bit values histogram without having to use a 32-bit type?
[17:41] <iive> you use the r6g6b6 as index in a simple array
[17:41] <iive> the array would contain how many times the color is used.
[17:41] <ubitux> ah yeah my bad, misread
[17:41] <iive> that's histogram, isn't it?
[17:42] <ubitux> they were talking about the counter
[17:42] <iive> yeh, mybad
[17:42] <ubitux> so int16_t hist[1<<18]
[17:42] <ubitux> crossing fingers that it will be enough
[17:44] <ubitux> anyway, so basically the revolutionary idea of the paper is to do int32_t hist[1<<15] ’ int16_t hist[1<<18];
[17:44] <iive> you may want to try giving one more bit to the green. or doing something in other colorspace... e.g. histogram for luma...
[17:44] <iive> ^_^
[17:45] <ubitux> yes i thought about that
[17:45] <ubitux> doing a 565
[17:45] <ubitux> but... it's starting to be slightly annoying for the algorithm to have mismatching scales
[17:45] <iive> rgb24 is 16M combinations, so it would take an array of 64MB. it's not much memory for modern computer, even a pocket one.
[17:46] <ubitux> i don't like the idea of allocating that much memory
[17:46] <ubitux> for... gif generation? really? :P
[17:46] <ubitux> anyway, the hash table with full resolution and less memory will do
[17:47] <iive> well, some people take their gifs very seriously! ;)
[17:47] <iive> but i'm more afraid that 64MB may slow down the algorithm.
[17:47] <wm4> <ubitux> i don't like the idea of allocating that much memory <- merely loading ffmpeg into the address space allocates that much dirty pages
[17:47] <wm4> at least if you enable all deps
[17:47] <wm4> fucking bloat everywhere
[17:48] <wm4> so don't waste braincell on mircooptimizing memory usage for gif generation
[17:48] <wm4> it's just absurd
[17:48] <BtbN> Shouldn't it delay load the unused ones?
[17:48] <wm4> BtbN: C++ constructors, dude
[17:48] <wm4> at least that's my bet
[17:48] <wm4> you can have lib ctors in C too, but these are obscure enough that libs normally avoid them
[17:49] <BtbN> Yes, those run when the library is loaded, which shouldn't happen before the first function call into them. At least i think so.
[17:49] <wm4> doesn't stop shitlibs like gnutls (or whatever it waS) of course
[17:49] <wm4> BtbN: I don't think so
[17:49] <ubitux> wm4: except that... the histogram is for several frame, so i might want to go up to int64_t for the histogram count
[17:49] <ubitux> and then i need a second index of all the colors
[17:50] <ubitux> if they're all different, i need a 1<<24 tabs again, and not 64 bits again
[17:50] <ubitux> so well, it's starting to be a lot
[17:50] <ubitux> the hash table model really isn't complicated for this case
[17:50] <ubitux> i just use a downsampled color as the hash key, then have a simple list
[17:51] <ubitux> that doesn't require much code
[18:48] <compn> mpcodecs is gone? can we merge ffmpeg and libav back together again? :P
[18:51] Action: funman approves
[18:52] <jamrial> there's still the swr and avr deathmatch :p
[18:52] <ubitux> then let's do the same as libmpcodecs
[18:52] <ubitux> let's drop avr
[18:54] <jamrial> that means ffmpeg will not work as a drop in replacement for libav anymore
[18:54] <jamrial> and distros that ship both projects will hate us
[18:55] <ubitux> :)
[18:55] <compn> is it not possible to make some kind of interoperability wrapper ?
[18:55] <compn> to have both api at once
[18:55] <compn> nevermind i think we have that already
[18:55] Action: compn stops caring about this
[18:56] <iive> jamrial: you can have ffmpeg and libav installed at the same time...
[18:57] <ubitux> iive: not easily
[18:57] <iive> i even proposed a patch to allow moving include files too.
[18:57] <jamrial> the distros i remember checking don't do that. they install one or the other, using the same library names
[18:57] <BtbN> The new debian approach allows to install both at the same time.
[18:57] <iive> well, we do that for debian.
[18:58] <BtbN> But only the runtime files. Only one -dev package can be installed at a time.
[18:58] <BtbN> It does that by simply renaming the libraries.
[19:05] <cone-73> ffmpeg.git 03Zhang Rui 07master:ca2e3e47fc6f: avformat/cache: pass options to the underlying protocol via the url_open2
[19:15] <wm4> <jamrial> that means ffmpeg will not work as a drop in replacement for libav anymore
[19:15] <wm4> jamrial: as a big FUCK YOU from the ffmpeg developers to the user, lavr is already not built by default
[19:16] <wm4> so if you want to write code that works out of the box, you need to support both lavr and lswr
[19:18] <iive> wm4: why the strong language? just an hour ago you were complaining about all the bloat in ffmpeg... a duplicate library built by default...
[19:19] <wm4> iive: I always use strong language, don't read too much into it
[20:00] <cone-73> ffmpeg.git 03Michael Niedermayer 07master:b9c3f041e029: avcodec/h261enc: Avoid casts, Simplify code
[20:00] <cone-73> ffmpeg.git 03Michael Niedermayer 07master:3aefa1eb69c4: avcodec/h261enc: More specific return code
[21:27] <ubitux> ok, moving to full resolution histograms definitely helped getting better palettes
[21:27] <ubitux> damn, it's almost looking good now
[21:27] <ubitux> let's improve even more..
[21:30] <cone-73> ffmpeg.git 03Michael Niedermayer 07master:b80106169ab1: avcodec/motion_est: Set subcmp consistently for H261
[21:31] <iive> ubitux: ENHANCE!
[21:31] <ubitux> ;)
[21:31] <iive> :)
[22:05] <cone-73> ffmpeg.git 03Andreas Cadhalpun 07master:2a3b7a55b511: examples/demuxing_decoding: set stream_idx in open_codec_context only if no error occured
[22:28] <wm4> can lavf/lavc encode video with parameter changes yet?
[22:29] <nevcairiel> some encoders can
[22:30] <nevcairiel> x264 can to some degree afaik
[22:32] <wm4> so there's an API for this?
[22:35] <nevcairiel> you just change what you want to change, and send the next frame, although the things it can change on the fly seems limited to aspect ratio, bitrate/crf/..., interlaced flags, everythign else you need to re-open the encoder apparently
[22:36] <nevcairiel> not sure if those were just added because someone wanted them, or because the others are not supported
[22:37] <nevcairiel> but only re-opening the encoder isnt that much trouble either really, as long as you output into a format that likes inline sps/pps changes..
[22:39] <wm4> hm
[00:00] --- Sun Feb  1 2015