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

[burek]

[00:23:10 CEST] <cone-894> ffmpeg 03Timothy Gu 07master:2b388e6ddec8: Revert "Move struc FFTContext below SECTION_RODATA"
[00:23:11 CEST] <cone-894> ffmpeg 03Timothy Gu 07master:204b228a1d88: x86inc: Clear __SECT__
[01:08:57 CEST] <cone-894> ffmpeg 03Michael Niedermayer 07master:cf52e6d012d0: avcodec/ffv1dec: Fix skip_alpha
[01:59:08 CEST] <jamrial> michaelni: some of your arm fate clients are ran out of space
[02:00:55 CEST] <jamrial> *running
[03:00:03 CEST] <michaelni> jamrial, should be fixed 
[03:12:35 CEST] <cone-894> ffmpeg 03Timothy Gu 07master:7206b94fb893: network: Move variable declaration under an #if
[06:45:07 CEST] <philipl> nevcairiel: Did you test your scaling list logic in the dxva2 hevc code? I duplicated it but I get glitched results in vdpau
[07:08:11 CEST] <philipl> Mind you, it might be a problem with my short term ref handling. Hold that thought.
[09:13:01 CEST] <rcombs> wm4: all the TLS variants should probably handle AVERROR_EXIT
[09:13:08 CEST] <rcombs> and pass it up to the higher level
[09:13:34 CEST] <rcombs> right now it gets converted to EOF, which http.c whines about
[09:21:28 CEST] <wm4> rcombs: what's the difference?
[09:22:35 CEST] <rcombs> complaints from higher-level protocols/demuxers/consumers, mostly
[09:25:03 CEST] <rcombs> though oddly enough, nothing complains with secure transport (but http.c does with OpenSSL)
[09:25:30 CEST] <rcombs> and I'm not sure what those two are doing differently
[09:25:53 CEST] <rcombs> well, either way, I'll make my last few tweaks to this and get the patch submitted tomorrow
[09:31:09 CEST] <nevcairiel> philipl: yes it was broken at first, and then i rewrote it to be fixed
[11:54:45 CEST] <cone-741> ffmpeg 03Shivraj Patil 07master:02a49912301f: avutil/mips: Restructure of generic macros
[12:09:56 CEST] <cone-741> ffmpeg 03Shivraj Patil 07master:bcd7bf7eeb09: avcodec/mips: Restructure as per avutil/mips/generic_macros_msa.h
[13:30:08 CEST] <wm4> ubitux: sometimes when seeking, it seems to happen that the vobsub decoder gets stuck in this state: "dvdsub: Attempt to reconstruct too large SPU packets aborted."
[13:30:42 CEST] <wm4> with the vobsub demuxer
[13:31:10 CEST] <ubitux> sounds nasty
[13:32:05 CEST] <ubitux> can you reproduce with ffmpeg -ss ... -i bla.idx -f null - or something?
[13:32:13 CEST] <wm4> oh, the decoder has no flush function
[13:32:52 CEST] <ubitux> ah, might be relevant to add one&
[13:33:11 CEST] <wm4> "Output file #0 does not contain any stream"
[13:33:32 CEST] <ubitux> try with -f matroska -y /dev/null maybe
[13:33:47 CEST] <wm4> same
[13:34:32 CEST] <wm4> I guess I'll add a flush function
[13:34:49 CEST] <wm4> (of course that doesn't fix it)
[13:51:46 CEST] <cone-741> ffmpeg 03Michael Niedermayer 07master:5a3d2541bd59: avformat/mxfenc: Support storing signal standard for D10 muxing
[14:16:57 CEST] <wm4> ubitux: the patches I just sent fix it fully
[14:39:26 CEST] <cone-741> ffmpeg 03Carl Eugen Hoyos 07master:57eecd9e4f8d: lavf: Use av_codec_get_tag2() in avformat_query_codec().
[14:39:27 CEST] <cone-741> ffmpeg 03Carl Eugen Hoyos 07master:4792fb94098c: lavc/x264: Support bgr0 as input pix_fmt.
[14:39:28 CEST] <cone-741> ffmpeg 03Michael Niedermayer 07master:b06e82e73897: Merge remote-tracking branch 'cehoyos/master'
[14:41:15 CEST] <wm4> I basically NACK'ed this patch
[14:55:27 CEST] <wm4> rcombs: as far as I can see, nothing actually acts on AVERROR_EXIT, so what's it important for?
[15:39:35 CEST] <gr1sha> where should I ask about problems I'm having with sw_scale ?
[15:49:27 CEST] <BBB> gr1sha: you can ask here
[15:50:43 CEST] <gr1sha> Alright so I was learning about ffmpeg from Dranger's manual (I actually used Illuusio's code as most of Dranger's is deprecated) and I wanted to add some RGB effects like turning off everything but Red, Green or Blue.
[15:51:22 CEST] <gr1sha> I decided to have a new thread that will take the frame, convert it to RGB, manipulate the values and turn it back to YUV
[15:51:51 CEST] <gr1sha> but when I activate the effect and the thread is starting off I get
[15:51:52 CEST] <gr1sha> # filter_thread: before convert to RGB.
[15:51:52 CEST] <gr1sha> [swscaler @ 0x7fffe00656a0] bad src image pointers
[15:51:52 CEST] <gr1sha> # filter_thread: after convert to RGB.
[15:53:28 CEST] <wm4> <gr1sha> Alright so I was learning about ffmpeg from Dranger's manual (I actually used Illuusio's code as most of Dranger's is deprecated)  <- actually the tutorial was updated
[15:53:43 CEST] <wm4> and now this Illuusio thing probably should be considered deprecated
[15:54:06 CEST] <wm4> (at least all code derived from the old tutorial I've seen was broken)
[15:54:38 CEST] <wm4> gr1sha: and that message means your plane pointers are wrong somewhere
[15:55:00 CEST] <gr1sha> wm4, is there a way to debug this message?
[15:57:10 CEST] <wm4> just make sure you pass in correct data
[15:58:25 CEST] <gr1sha> most of the frames are moving perfectly fine, only once in a while I get the message
[15:58:40 CEST] <gr1sha> I'm trying to understand what causes it, it might be the reason the when I apply the color effect it looks like this:
[15:59:25 CEST] <gr1sha> http://i.imgur.com/UDfMHxk.png
[16:00:00 CEST] <gr1sha> I convert it to RGV -> turn off unwanted colors --> back to YUV
[16:00:05 CEST] <gr1sha> and it looks like this O_O
[16:02:50 CEST] <wm4> probably an AVFrame management error
[16:03:03 CEST] <wm4> not using refcounted AVFrames, using them incorrectly, or something like this
[16:03:43 CEST] <gr1sha> I see
[16:03:54 CEST] <gr1sha> what are refcounted AVFrames?
[16:04:03 CEST] <gr1sha> (where can I read about it?)
[16:05:09 CEST] <gr1sha> might it also cause the audio and video to get out of sync?
[16:05:16 CEST] <gr1sha> the use of refcounted AVFrames?
[16:06:28 CEST] <wm4> you enable them by setting avctx->refcounted_frames = 1;
[16:06:32 CEST] <wm4> (before opening the codec)
[16:07:04 CEST] <wm4> then you also need to allocate the AVFrame data with av_frame_get_buffer (only if you want to allocate frame data yourself; the decoder still does it automatically)
[16:07:36 CEST] <gr1sha> mm alright I'll try this out
[16:07:38 CEST] <gr1sha> thanks a lot!
[16:10:09 CEST] <cone-741> ffmpeg 03wm4 07master:0ad04bf6a29e: dvdsubdec: reset buffer size on invalid over-large packets
[16:10:50 CEST] <wm4> michaelni: the flush patch is also needed to make seeking work (in case there was the impression that the 3rd patch fixes it)
[16:19:55 CEST] <cone-741> ffmpeg 03wm4 07master:6f2c64fd03a1: dvdsubdec: implement flushing
[16:20:50 CEST] <michaelni> wm4, applied, thx
[16:51:52 CEST] <kierank> wm4: yeah that pixfmt is my fault
[16:56:42 CEST] <wm4> kierank: I didn't look too closely whether there are older pixfmts which violate the rule
[17:19:36 CEST] <philipl> nevcairiel: which sample did you test with, the conformance SLIST one?
[17:19:46 CEST] <philipl> (for scaling lists)
[17:25:38 CEST] <nevcairiel> nah some sample i got from someone
[17:26:27 CEST] <philipl> Could I get access to that?
[17:27:55 CEST] <nevcairiel> whats wrong with the conformance sample?
[17:31:22 CEST] <nevcairiel> hm apparently the SLIST samples dont look correct with dxva2 either, odd that the other sample was fine then
[17:31:24 CEST] Action: nevcairiel investigates
[17:33:18 CEST] <cone-741> ffmpeg 03Shivraj Patil 07master:10b77fbf0d1b: avcodec/mips: Split uni mc optimizations to new file
[17:48:08 CEST] <nevcairiel> odd though ,reading the hevc spec, dxva2 hevc spec, and the hevc parsing code, it seems right :(
[17:57:08 CEST] <nevcairiel> i found it, ha!
[18:01:46 CEST] <Daemon404> 'g 42
[18:03:05 CEST] <BtbN> Isn't 1.2 EOL?
[18:22:16 CEST] <nevcairiel> philipl: patch on the ML that fixes the SLIST conformance samples with dxva2, i imagine you can use that fix too
[18:24:19 CEST] <wm4> does someone have a h264 sample with dimensions not aligned to 2?
[18:24:41 CEST] <nevcairiel> if yes, destroy it
[18:27:45 CEST] <philipl> nevcairiel: yay!
[18:28:59 CEST] <nevcairiel> for some reason the parsing code shuffles stuff around a bit <.<
[18:30:15 CEST] <JEEBsv> wm4: poke mirko for some non-mod2 4:4:4
[18:30:53 CEST] <nevcairiel> the other patch on the ML fixes the crash with your crazy-pants sample JEEBsv, although it wont decode properly of course
[18:31:00 CEST] <wm4> JEEBsv: I want 4:2:0
[18:31:20 CEST] <JEEBsv> oh
[18:31:42 CEST] <JEEBsv> hopefully that isn't around like it is with vpx:p
[18:32:12 CEST] <wm4> x264 refuses to encode such a sample... or can I set cropping flags separately somehow?
[18:32:33 CEST] <JEEBsv> i think koda did shit around them
[18:32:45 CEST] <BtbN> you could hex-edit them
[18:34:58 CEST] <philipl> nevcairiel: Do all the RPS samples pass ffor you? My code handles normal stuff fine - that is to say anything x265 or nvenc can produce but many of the RPS samples are glitchy. My logic looks morally equivalent to yours although the data structures are quite different in vdpau.
[18:35:09 CEST] <philipl> just trying to find a working baseline.
[18:38:44 CEST] <nevcairiel> philipl: all hevc-conformance-RPS* samples pass
[18:40:03 CEST] <nevcairiel> a few others dont pass, mostly related to cropping (CONFWIN) or the PICSIZE ones .. i dont know whats the deal with those
[18:40:24 CEST] <philipl> ok.good to know. Now i just have to spot what's making some of them work and not others. Which document describes what each sample covers? I found an mpegh part 8 doc that credits each sample but doesnt say what they cover. is it only in the paid specs?
[18:40:24 CEST] <nevcairiel> ah PICSIZE is just giant
[18:40:59 CEST] <philipl> bigger than hw limits?
[18:41:29 CEST] <nevcairiel> 1056x8440
[18:41:30 CEST] <nevcairiel> :D
[18:41:35 CEST] <philipl> hah
[19:15:38 CEST] <jamrial> wm4: http://fate.ffmpeg.org/log.cgi?time=20150528090504&log=compile&slot=x86_64-archlinux-gcc-random
[19:16:15 CEST] <nevcairiel> i wonder what kind of crazyness that random config enabled
[19:16:42 CEST] <wm4> some weird forgotten include file?
[19:17:01 CEST] <wm4> or since it says redefinition, one weird include too many?
[19:18:42 CEST] <jamrial> nevcairiel: tls_openssl. afaik, this is the only fate client using it instead of tls_gnutls
[19:19:44 CEST] <jamrial> wm4: this is probably some missing ifdef after you moved stuff from network.c to tls*
[19:21:48 CEST] <wm4> I doubt it
[19:21:58 CEST] <wm4> this struct is only defined if HAVE_STRUCT_SOCKADDR_STORAGE is unset
[19:22:19 CEST] <wm4> which is only set if this struct is not found in the system headers (using the standard include file for this struct)
[19:24:00 CEST] <jamrial> http://fate.ffmpeg.org/log.cgi?time=20150528090504&log=configure&slot=x86_64-archlinux-gcc-random "network support        no"
[19:24:15 CEST] <jamrial> the check for sockaddr_storage is only done if network is enabled
[19:25:10 CEST] <nevcairiel> no network, yes tls seems like a odd combination for sure :D
[19:25:35 CEST] <jamrial> heh
[19:28:52 CEST] <wm4> and why did this happen now?
[19:28:59 CEST] <wm4> and why is network disabled at all?
[19:29:27 CEST] <jamrial> random disabled it
[19:29:27 CEST] <nevcairiel> because it uses --enable-random
[19:29:37 CEST] <jamrial> and no idea why now
[19:29:39 CEST] <nevcairiel> or what ever the option is called
[19:31:02 CEST] <wm4> ah so it happened by chance
[19:33:31 CEST] <jamrial> the idea of --enable-random is to try different configure options to find breakages like this
[19:34:49 CEST] <jamrial> admitedly "--disable-network --enable-gnutls --enable-openssl --enable-protocol=tls_openssl --disable-protocol=tls_gnutls" is not something anyone would normally do, but it nonetheless should not break
[19:40:46 CEST] <rcombs> did the details of actually using multiple TLS implementations ever get worked out?
[19:43:32 CEST] <wm4> rcombs: no... they could be compiled at the same time, but we'd need something to "redirect" the tls protocol
[19:43:49 CEST] <wm4> which could probably be done with some funky proxy protocol thing
[19:43:58 CEST] <wm4> if you're lucky, 20 lines of code or so?
[19:44:07 CEST] <wm4> or let's say 70
[19:44:48 CEST] <rcombs> wm4: could just provide a "tls_<name>" protocol in each one along with the regular "tls" (which is first-registered-first-served)
[19:48:06 CEST] <wm4> rcombs: and how?
[19:48:17 CEST] <wm4> without duplicatinh anything
[19:48:39 CEST] <rcombs> you'd need to duplicate the URLProtocol, which isn't great
[19:51:05 CEST] <wm4> we could also just remove all uses of tls://, and have a function that returns the tls protocol to use dynamically
[19:51:14 CEST] <wm4> so the function would e.g. return tls_gnutls://
[19:51:30 CEST] <wm4> except the API user might expect being able to use tls://
[19:52:07 CEST] Action: Daemon404 shudders reading this conversation
[19:52:48 CEST] <wm4> to be fair, I don't know what it'd be useful for either
[19:52:52 CEST] <wm4> except easier debugging
[20:13:42 CEST] <Compn> wouldnt it just be easier to steal the code from polarssl or gnutls and remove the need for external lib
[20:13:45 CEST] Action: Compn runs like the wind
[20:13:58 CEST] <Compn> or use curl instead
[20:14:01 CEST] Action: Compn runs harder
[20:15:34 CEST] <Daemon404> im sure people would love tripling the amount of CVEs
[20:16:16 CEST] <wm4> I'm pretty sure Compn is paid by the NSA
[20:16:30 CEST] <wm4> encouraging bad practices and all that
[20:18:43 CEST] <Rodeo> National Aupertroll Agency?
[20:18:53 CEST] <Rodeo> National Supertroll Agency even
[20:21:59 CEST] <Compn> if i wanted to troll, i'd hook up some cloud to fuzz against libav and then systematically fix every bug in ffmpeg until there were 5000 bugs that only affected libav. then submit that info to every distro as proof that ffmpeg was better.
[20:22:28 CEST] <Daemon404> google already did that
[20:22:56 CEST] <Compn> google didnt file the reports on each distro bugtracker iirc
[20:30:38 CEST] <wm4> don't give cehoyos ideas
[20:32:58 CEST] <BBB> so what does libav do nowadays, like, whats their specialty or raison d'etre?
[20:42:08 CEST] <jamrial> i think they were planning on doing more big changes. luca suggested splitting libavuitl a few weeks ago, but it wasn't well received
[20:43:17 CEST] <wm4> he did?
[20:46:49 CEST] <jamrial> yeah
[20:47:36 CEST] <jamrial> https://www.mail-archive.com/libav-devel@libav.org/msg67729.html
[20:49:04 CEST] <cone-741> ffmpeg 03Shivraj Patil 07master:7b45790771c0: avcodec/mips/hevcdsp_msa: Restructure as per avutil/mips/generic_macros_msa.h
[20:59:24 CEST] <kierank> smells like libavcore
[20:59:34 CEST] <kierank> BBB: rearranging the deckchairs on the titanic
[20:59:37 CEST] <kierank> =p
[21:00:10 CEST] <BBB> I think Ive mentioned repeatedly that the biggest feature for me would be to be able to make custom builds with parts of avutil disabled
[21:00:21 CEST] <BBB> I dont care about the default build enabling all and avutil being big by default - thats fine
[21:00:24 CEST] <BBB> gtk is big by default
[21:00:49 CEST] <BBB> but for custom use cases, Id like to be able to disable components, just like I Can disable swscale or avformat or whatever
[21:01:00 CEST] <BBB> I just never had time to do it myself
[21:01:07 CEST] <Compn> BBB : sounds like a good feature.
[21:01:24 CEST] <BBB> I think its fairly easy, lots of people could do it, but I dont expect big interest in it :(
[21:01:32 CEST] <BBB> (i.e. not many developers willing to spend time on it)
[21:01:33 CEST] <Compn> i'm curious why you'd want smaller binaries (and by smaller i'm talking about 100k probably?)
[21:01:35 CEST] <Daemon404> because it's not useful to most
[21:01:50 CEST] <Daemon404> just a very very tiny subset of people
[21:02:07 CEST] <Compn> how many people disable certain codecs? very very tiny subset...
[21:02:10 CEST] <Compn> or parsers :P
[21:02:21 CEST] <Daemon404> thats generally for patent reasons.
[21:02:30 CEST] <Daemon404> and the whole of avutil is a few more kilobytes.
[21:02:46 CEST] <BBB> lets sya I want to build an application that I want to ship on mobile, which just does something crazy to vp9
[21:02:51 CEST] <BBB> mobile, so file size matters
[21:02:54 CEST] <j-b> libavutil is 327KB here
[21:02:56 CEST] <BBB> I dont want swscale obviously
[21:03:06 CEST] <BBB> I dont want avfilter
[21:03:14 CEST] <BBB> likewise, I dont want md5 or 90% of avutil
[21:03:15 CEST] <Daemon404> BBB, the people who care about a few kb in avutil is still very tiny
[21:03:19 CEST] <BBB> I know
[21:03:27 CEST] <BBB> Im not saying you should do it
[21:03:27 CEST] <j-b> BBB: link statically and strip.
[21:03:32 CEST] <BBB> but I personally have an interest in it
[21:03:33 CEST] <Daemon404> "size on mobile matters" lol
[21:03:35 CEST] <Daemon404> chrome is like 200 mb
[21:03:43 CEST] <j-b> Facebook app is above 90MB
[21:03:46 CEST] <BBB> I dont want to be like chrome
[21:03:49 CEST] <BBB> anyway
[21:03:53 CEST] <BBB> I dont expect lots of itnerest
[21:03:59 CEST] <Daemon404> it's essentially ricing here
[21:04:00 CEST] <j-b> Why not strip it?
[21:04:01 CEST] <BBB> but I personally would find it interesting and exciting and useful
[21:04:21 CEST] <Daemon404> noone else does
[21:04:24 CEST] <Daemon404> hence noone else cares to do it.
[21:04:26 CEST] <BBB> even if I strip it, crap is still there
[21:04:34 CEST] <j-b> really ?
[21:04:35 CEST] <BBB> the crap may be smaller, but its still crap
[21:04:45 CEST] <j-b> with lto and gto?
[21:04:57 CEST] <BBB> static may not be possible if my app isnt opensource
[21:05:00 CEST] <BBB> (btw)
[21:05:14 CEST] <j-b> static with libavcodec
[21:05:25 CEST] <Daemon404> generally people make libffmpeg.so or w/e 
[21:05:27 CEST] <Daemon404> on mobile
[21:05:39 CEST] <BBB> libffmpeg.so still has md5 in it
[21:05:41 CEST] <Daemon404> (which could be LTO'd)
[21:05:50 CEST] <Daemon404> yes HOLKY SHIT 2 KB FOR MD5
[21:05:56 CEST] <BBB> :)
[21:05:56 CEST] <j-b> because libffmpeg.so has a lot of things that need md5
[21:06:10 CEST] <Daemon404> LTO is pretty good at DCE
[21:06:19 CEST] <Daemon404> the only reason it sucks at avcodec is the codec registry stuff
[21:06:21 CEST] <j-b> if you link libavcodec.so with libavutil statically in, and you activate only vp9, md5 is still there?
[21:08:15 CEST] <jamrial> the problem with making libavutil customizable at configure time like the other libraries is the fact each module has a public header
[21:08:21 CEST] <jamrial> do we install all the headers (and have the alloc/init functions fail if the functionality is not there), or not install the headers at all?
[21:08:54 CEST] <jamrial> what will piss off users the least, basically
[21:09:02 CEST] <Daemon404> i dont see why it should be split at all
[21:09:06 CEST] <Daemon404> this is what linkers are for
[21:09:16 CEST] <BBB> j-b: yes
[21:09:30 CEST] <j-b> BBB: with lto and gto and such?
[21:09:32 CEST] Action: Daemon404 somehow doubts BBB actually went and tested that
[21:09:48 CEST] <BBB> its public api; my app can use it, and the linker doesnt know that since its a .so
[21:09:51 CEST] <BBB> of course its still there
[21:10:07 CEST] <Daemon404> it is NOT public api in libavcodec
[21:10:25 CEST] <Daemon404> though i am not sure what is exposed in the .ver
[21:10:37 CEST] <BBB> libavutil/md5.h is not public?
[21:10:39 CEST] <Daemon404> regardless, as i said, most people use something like libffmpeg.so (google does this)
[21:10:43 CEST] <Daemon404> which uses their own symbol table
[21:10:48 CEST] <Daemon404> BBB, linker only cares about what is exported.
[21:10:52 CEST] <Daemon404> header is irrelevant
[21:12:31 CEST] <j-b> yeah
[21:16:04 CEST] <BBB> LIBAVUTIL_54 {
[21:16:04 CEST] <BBB>         global: av*;
[21:16:21 CEST] <Daemon404> i checked
[21:16:25 CEST] <BBB> struct AVMD5 *av_md5_alloc(void);
[21:16:26 CEST] <Daemon404> it doesnt export stuff from included .a
[21:16:29 CEST] <Daemon404> only .o
[21:16:38 CEST] <BBB> its not .a
[21:16:42 CEST] <BBB> its .so
[21:16:50 CEST] <Daemon404> when you link libavcodec.so
[21:16:59 CEST] <Daemon404> you have -lavutil, which points to libavutil.a
[21:17:08 CEST] <Daemon404> and it does bot pull in those symbosl from avutil.
[21:17:11 CEST] <Daemon404> and it does nto export them.
[21:17:21 CEST] <BBB> there is no .a
[21:17:32 CEST] <Daemon404> what?
[21:17:38 CEST] <Daemon404> that was teh entire point here
[21:17:41 CEST] <Daemon404> static libavutil
[21:18:05 CEST] <j-b> 21:06 <@j-b> if you link libavcodec.so with libavutil statically in, and you activate only vp9, md5 is still  there?
[21:18:13 CEST] <Daemon404> yes.
[21:18:13 CEST] <j-b> this was my question, of course.
[21:18:18 CEST] <BBB> there is a libavutil.so, libavcodec.so and my app links against these two
[21:18:21 CEST] <BBB> I use symbols from both
[21:18:21 CEST] <Daemon404> it solves the same problem as disabling bits of avutil.
[21:18:49 CEST] <Daemon404> this is what linkers DO
[21:19:22 CEST] <BBB> if you have a .a, which I dont, right
[21:19:36 CEST] <Daemon404> so make one?
[21:20:47 CEST] <cone-741> ffmpeg 03Timothy Gu 07master:dd4d709be705: x86inc: Clear __SECT__
[21:20:48 CEST] <cone-741> ffmpeg 03Michael Niedermayer 07master:5c4160809698: Merge commit 'dd4d709be705edaec0bc35c426bf8434e942b7df'
[21:21:52 CEST] <BBB> Im happy with my .so honestly
[21:22:51 CEST] <BBB> (Id also be slightly shocked if you were actually able to build an application that uses _only_ avcodec symbols without ever using avutil symbols in the application itself; my app certainly isnt one of those)
[21:27:52 CEST] <nevcairiel> since the frame api is now in avutil, that is not possible
[21:28:13 CEST] <cone-741> ffmpeg 03Martin Storsjö 07master:d4d90504a687: tls_gnutls: Add missing includes for the gcrypt thread safety callbacks
[21:28:14 CEST] <cone-741> ffmpeg 03Michael Niedermayer 07master:f0b99112e357: Merge commit 'd4d90504a687d2c0ef77ccf11d831f24dcff9cf1'
[21:29:05 CEST] <BBB> so there goes that idea
[21:34:33 CEST] <cone-741> ffmpeg 03Vittorio Giovara 07master:419e3404d07a: mpegvideo: Drop exchange_uv() function and use its code directly
[21:34:34 CEST] <cone-741> ffmpeg 03Michael Niedermayer 07master:9b736f74fc24: Merge commit '419e3404d07acaac019e8f363c281e17c3a3d622'
[21:47:18 CEST] <cone-741> ffmpeg 03Anton Khirnov 07master:fa1923f18205: mpegvideo: Move ff_*_rl functions to a separate file
[21:47:19 CEST] <cone-741> ffmpeg 03Michael Niedermayer 07master:68cce0101df0: Merge commit 'fa1923f18205410a3b0aa6c0e77cb31443ef340d'
[21:55:25 CEST] <cone-741> ffmpeg 03Anton Khirnov 07master:6f57375d707d: rl: Rename ff_*_rl() to ff_rl_*()
[21:55:26 CEST] <cone-741> ffmpeg 03Michael Niedermayer 07master:75647622b530: Merge commit '6f57375d707de40dcec28d3cef886c364e032c21'
[21:59:18 CEST] <cehoyos> [19:29] <jamrial> random disabled it <- unfortunately not: We can either test --disable-network with random or --enable-network with random, both catch different issues;-(
[22:02:21 CEST] <cone-741> ffmpeg 03Anton Khirnov 07master:324e50ee9592: rl: Add a function for freeing dynamically allocated tables.
[22:02:22 CEST] <cone-741> ffmpeg 03Michael Niedermayer 07master:c508fef3c737: Merge commit '324e50ee95929a9491b855c5e15451145bd5d1ec'
[22:10:22 CEST] <cone-741> ffmpeg 03Anton Khirnov 07master:1b1bb2c4efc1: rl: Add error checking to ff_rl_init().
[22:10:23 CEST] <cone-741> ffmpeg 03Michael Niedermayer 07master:7026d8accdb2: Merge commit '1b1bb2c4efc126d74d44d8c421860c85f932ecb1'
[22:21:19 CEST] <cone-741> ffmpeg 03Michael Niedermayer 07master:e4610300de68: x86: cavs: Remove an unneeded scratch buffer
[22:21:20 CEST] <cone-741> ffmpeg 03Michael Niedermayer 07master:b666e81c1329: Merge commit 'e4610300de6869bd6b3b00e76cfeabb6d7653dcd'
[22:34:36 CEST] <cone-741> ffmpeg 03wm4 07master:a64a5773ea5f: pixfmt: remove misleading and broken documentation
[22:34:37 CEST] <cone-741> ffmpeg 03Michael Niedermayer 07master:e2f3ea1cbb64: Merge commit 'a64a5773ea5f7337cd1d87cfdf511914d317fe81'
[00:00:00 CEST] --- Fri May 29 2015