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

[burek]

[00:00] <llogan> WebUrine
[00:00] <wm4> that's what it is
[00:03] <Youka> Ok, as far as i see there's no nanosleep in MinGW. There were attempts in past, but at the end, Sleep & usleep remained.
[00:06] <Youka> So detecting mingw and consider in configure to avoid HAVE_NANOSLEEP would be needed (in my case, i change it in config.h for now).
[00:07] <wm4> uh the configure script already checks whether nanosleep exists
[00:08] <Youka> But the missing struct timespec while compilation tells another thing :/
[00:13] <jamrial> HAVE_NANOSLEEP should not be true in your configuration. something went wrong
[00:13] <Youka> I think too, but not on my side ^^"
[00:14] <cone-460> ffmpeg.git 03Michael Niedermayer 07master:f31fd067130f: vf_sab: use av_malloc_array()
[00:14] <cone-460> ffmpeg.git 03Michael Niedermayer 07master:eb0fc73dcc85: avfilter/vf_spp: Use av_malloc_array()
[00:19] <jamrial> it is on your side. configure checked for nanosleep and the test succeeded, which can't happen with mingw
[00:19] <jamrial> since for starters it's missing librt
[00:25] <Youka> Looking at the test, it uses nanosleep with an extern reference and without struct timespec, so the missing of both in headers is right, but the function is in a linked library it seems.
[00:26] <Youka> So the test could succeed, but the compilation fails.
[00:30] <Youka> Officially nanosleep is not part of mingw, but broken experiments are left in binaries.
[00:31] <wm4> too bad
[00:32] <wm4> time to paste your config.log?
[00:32] <Youka> y
[00:32] <Youka> mom
[00:33] <Youka> `http://pastebin.com/gZjzZrJm
[00:34] <Youka> With HAVE_NANOSLEEP=0 the build completed now
[00:35] <wm4> seems like a pretty bad idea what the configure script is doing
[00:35] <wm4> _especially_ if by default implicit function declarations are an error
[00:36] <Youka> ############################
[00:36] <Youka>     1 extern int nanosleep();
[00:36] <Youka>     2 int main(void){ nanosleep(); }
[00:36] <Youka> ############################
[00:36] <Youka>     struct timespec ts = { usec / 1000000, usec % 1000000 * 1000 };
[00:36] <Youka>     while (nanosleep(&ts, &ts) < 0 && errno == EINTR);
[00:36] <Youka> ############################
[00:36] <Youka> First is configure, second the part in libavutil/time.c
[00:37] <wm4> you know what, this is a dev channel
[00:37] <wm4> for user questions go to #ffmpeg
[00:39] <Youka> It's not about using ffmpeg or developing with libav, it's a build error, so isn't it right here?
[00:42] <Daemon404> winpthreads has nanosleep
[00:42] <wm4> so why does ffmpeg configure check for the symbol only
[01:14] <nevcairiel> because thats enough for 99.9% of things, and makes it much easier to abstract
[01:15] <nevcairiel> never had the problem myself with mingw
[01:16] <nevcairiel> of course its been years since i used mingw32, but admittedly its been more years since mingw32 was updated :p
[01:17] <Youka> My old ffmpeg didn't throw this error, so this problem came with newer versions.
[01:18] <Youka> Same compiler, new ffmpeg.
[01:19] <nevcairiel> personally i would call mingw32 unsupported already and push people to upgrade their old environments
[01:38] <cone-460> ffmpeg.git 03Tristan Matthews 07master:49106844929b: tiffenc: fix packet size calculation
[01:38] <cone-460> ffmpeg.git 03Michael Niedermayer 07master:9f028b3f3af5: Merge commit '49106844929b7b71ac719064d640f8aa56c89b1f'
[01:51] <Timothy_Gu> Youka nevcairiel: I've never encountered any problems with mingwrt 3.20 and w32api 3.17
[01:51] <Timothy_Gu> Youka: what is your MinGW (not gcc) version?
[01:51] <cone-460> ffmpeg.git 03Josh Allmann 07master:74bc9458057f: flvenc: Don't over-count metadata.
[01:51] <cone-460> ffmpeg.git 03Michael Niedermayer 07master:3f2f87cd5a84: Merge commit '74bc9458057f07c0820c3d3264396c4c64442e47'
[02:01] <cone-460> ffmpeg.git 03Rafaël Carré 07master:9affa784a074: vp9 encoder: use a decent default speed setting
[02:01] <cone-460> ffmpeg.git 03Michael Niedermayer 07master:cb037b5db49f: Merge commit '9affa784a0743b95bde135b5acfce2183afc35d8'
[02:06] <llogan> Timothy_Gu: He's dead, Jim.
[02:14] <Timothy_Gu> llogan: yeah he is. didnt see that earlier
[02:16] <cone-460> ffmpeg.git 03Lou Logan 07master:d9a61ae31e8c: presets: remove moldering iPod presets
[02:17] <michaelni> matrixbench_mpeg2.mpg -vf scale=320:240,format=monow,spp=6:63,hqx=4
[02:17] <Timothy_Gu> ubitux: i wrote a patch fixing the underline mess on FATE
[02:18] <Timothy_Gu> you can see if that meets you expectations at http://goo.gl/yCqilT
[02:19] <Timothy_Gu> * http://goo.gl/yCqiIT
[03:21] <cone-460> ffmpeg.git 03Michael Niedermayer 07master:28bf11150346: avcodec/wavpack: fix () in macros
[03:21] <cone-460> ffmpeg.git 03Michael Niedermayer 07master:aab23f5ddd3d: avcodec/vp9: fix () in macros
[03:21] <cone-460> ffmpeg.git 03Michael Niedermayer 07master:c89be82c986f: avcodec/vp8: fix () in macros
[03:21] <cone-460> ffmpeg.git 03Michael Niedermayer 07master:0608bc65025a: swresample/audioconvert: fix () in FMT_PAIR_FUNC()
[04:11] <BBB> yay I managed to write resample_common_float_sse in yasm
[04:11] <nevcairiel> and is it 200% faster?
[04:22] <BBB> didnt measure yet
[04:22] <BBB> probably not, I didnt optimize anything yet, just basic stuff which is probably similarish to disassembly
[04:22] <BBB> the optimizations would come after that
[04:26] <Compn> always wondered if a machine translation from c > asm would be faster
[04:26] <Compn> i've heard it would be :P
[04:26] <Compn> 'asm is always faster'
[04:56] <cone-460> ffmpeg.git 03Michael Niedermayer 07master:c932f12806d2: avcodec/cavsdec: simplify % 512 operations
[04:56] <cone-460> ffmpeg.git 03Michael Niedermayer 07master:7f5296005c39: swscale/swscale: replace potentially slow % by &
[05:07] <nevcairiel> Compn: if its a machine translation, why didnt the compiler do it
[05:12] <Compn> nevcairiel : well. 'why didnt gcc optimize this?' 
[05:12] <Compn> because its gcc.
[05:47] <Timothy_Gu> llogan: thanks for the reminder. I will send a patch in probably 2-3 days
[07:32] <ubitux> Timothy_Gu: LGTM, thx
[07:35] <ubitux> < michaelni> matrixbench_mpeg2.mpg -vf scale=320:240,format=monow,spp=6:63,hqx=4 // hehe pretty nice
[07:42] <llogan> about how big is the fate suite now?
[08:03] <ubitux> fate-samples is 854M here
[08:06] <llogan> ubitux: thanks. i was just curious because my innernet is slow.
[12:36] <BBB> well this uses clang, but anyway
[12:36] <BBB> (mac doesnt use gcc anymore)
[12:59] <cone-261> ffmpeg.git 03Roman Savchenko 07master:44671b57866a: AVFrame: factor out freeing the side data
[12:59] <cone-261> ffmpeg.git 03Michael Niedermayer 07master:40c9d4308689: Merge commit '44671b57866aab8dd36715ff010e985e25baaf19'
[13:47] <cone-261> ffmpeg.git 03Niels Möller 07master:f2ce63246f5c: dcadec: replace ldexpf with a multiplication by a constant
[13:47] <cone-261> ffmpeg.git 03Michael Niedermayer 07master:118d84b7e937: Merge commit 'f2ce63246f5c934429f9cb857a794e07624d7912'
[13:47] <cone-261> ffmpeg.git 03Michael Niedermayer 07master:a740cae4a080: avcodec/dcadec: remove unsignedness from constant
[14:09] <cone-261> ffmpeg.git 03Carl Eugen Hoyos 07master:076ab9f7e3b1: Fix all VDPAU decoders.
[14:22] <cone-261> ffmpeg.git 03Ronald S. Bultje 07master:cbf21628a5e5: swr: remove div/mod from DSP functions.
[14:32] <cone-261> ffmpeg.git 03Carl Eugen Hoyos 07master:99a8a3de8c65: Revert "Fix compilation on ppc64 and ppc with pic if gas-preprocessor is installed."
[15:32] <ubitux> I suggest we replace the "largely broken" changelog entry about ffserver in the Changelog by a call for maintainer in the introduction (assuming we go with the new layout i'm suggesting)
[15:34] <iive> ubitux: do it.
[15:36] <ubitux> iive: well sure, but my changelog patchset is not oked
[15:36] <ubitux> and the av/ffserver drop is not merged yet
[15:36] <ubitux> (it was just pushed a few minutes ago)
[17:04] <cone-261> ffmpeg.git 03Michael Niedermayer 07master:5439959ef013: avcodec/huffyuvdec: do not leave alpha values uninitialized
[17:19] <cone-261> ffmpeg.git 03Anton Khirnov 07master:894682a9739e: Remove avserver.
[17:19] <cone-261> ffmpeg.git 03Michael Niedermayer 07master:daa7bccad227: Merge commit '894682a9739eb8d4bfc024b0d4e5757fcfe47378'
[17:27] <cone-261> ffmpeg.git 03Anton Khirnov 07master:cfbdd7ffbd9f: rtpenc: base max_frames_per_packet on avg_frame_rate, not codec timebase
[17:27] <cone-261> ffmpeg.git 03Michael Niedermayer 07master:bd148ce07de0: Merge commit 'cfbdd7ffbd9fe14d110fd1bb89bf52f0f7bde016'
[17:31] <nevcairiel> you know, carl will never let that pkg-config patch go through anyway, no matter how many people agree
[17:32] <Daemon404> fuck carl
[17:32] <Daemon404> he is literally the only one.
[17:32] <ubitux> i sent my latest mail on this issue
[17:33] <nevcairiel> should just commit it and see what happens
[17:33] <ubitux> no
[17:34] <ubitux> not really in the mood for a commit/revert war, that won't really help
[17:34] <nevcairiel> he doesn't listen to logical arguments, you're just giving into his insanity?
[17:34] <cone-261> ffmpeg.git 03Anton Khirnov 07master:f792d3cbb8e8: lavf: add the notimestamps flag to the muxers missing it
[17:34] <cone-261> ffmpeg.git 03Michael Niedermayer 07master:95398aa9499b: Merge commit 'f792d3cbb8e8e35c54a9358a55dd596b7a40f228'
[17:34] <Daemon404> ubitux, at what point do you reach a logic consensus
[17:34] <Daemon404> 100 people vs 1
[17:34] <ubitux> well i just want to make sure there is no misunderstanding first
[17:35] <ubitux> and that everyone is pretty aware of the problem
[17:35] <Daemon404> i am not sure carl is capabale of understanding some concepts
[17:35] <Daemon404> given the years of his emails ive read
[17:35] <wm4> so uh can't you just overrule him
[17:35] <ubitux> i don't want that
[17:36] <wm4> time to fork?
[17:36] <ubitux> we're just not agreeing on a technical issue
[17:36] <ubitux> it's not a that simple issue
[17:36] <Daemon404> a lot of carl's agrument is "it will break build scripts"
[17:36] <Daemon404> which is bollocks
[17:37] <ubitux> that's the only one
[17:37] <ubitux> and it's true somehow
[17:37] <Daemon404> i know
[17:37] <Daemon404> but pkg-config > setting cflags/ldflags
[17:37] <Daemon404> i welcome it
[17:37] <ubitux> but that's why i proposed the documentation
[17:37] <ubitux> and all the changelog stuff
[17:38] <ubitux> given all the advantages pkg-config provides, i think that's what we should
[17:38] <ubitux> oh well
[17:38] <nevcairiel> an argument of "it breaks peoples old obscure setups" can be made for many many changes, that doesn't mean we should never do them
[17:38] <wm4> it's a ridiculous argument compared to all the API changes
[17:38] <Daemon404> yes it is
[17:38] <j-b> lol
[17:38] <Daemon404> but how often does carl deal with API issues on bug tracker?
[17:38] <Daemon404> hardly ever
[17:38] <j-b> still fighting on pkg-config?
[17:38] <Daemon404> compared to "im retarded and configure isnt working"
[17:38] <wm4> j-b: yes
[17:38] <Daemon404> which seem to be like 40% of bugs filed
[17:39] <j-b> wm4: it's a joke, right?
[17:39] <Daemon404> his perspective is skewed
[17:39] <wm4> j-b: no, it's cehoyos
[17:39] <ubitux> j-b: hey i mentioned vlc, i hope you're happy ;)
[17:39] <j-b> ubitux: did you
[17:39] <j-b> ?
[17:39] <ubitux> of course
[17:39] <j-b> I skipped over some emails, in the middle, maybe
[17:39] <Daemon404> "vlc usus pkg-config, email j-b for more information"
[17:39] Action: Daemon404 runs
[17:39] <ubitux> http://ffmpeg.org/pipermail/ffmpeg-devel/2014-June/159001.html
[17:39] <j-b> I thought it was a joke
[17:40] <ubitux> or well, it was in my shell path
[17:40] <Daemon404> j-b, dont underestimate aspergers patients
[17:41] <j-b> I hate pkg-config as much as anyone, but there are no solutions.
[17:41] <ubitux> what's the problem with pkg-config, aside the glib dep?
[17:41] <j-b> it's ugly :)
[17:41] <j-b> it's not well documented
[17:42] <Daemon404> the --static business is a design oversight
[17:42] <Daemon404> thats my main issues
[17:42] <Daemon404> -s
[17:42] <j-b> PKG_CONFIG_PATH PKG_CONFIG_LIBDIR is a mess
[17:42] <ubitux> ah?
[17:42] <Daemon404> j-b, rule of thumb: PKG_CONFIG_PATH is pretty much never the right env var to set
[17:42] <j-b> ${triplet}-pkg-config is not standard and a mess
[17:42] <Daemon404> despite what google says
[17:42] <j-b> and glib
[17:42] <ubitux> seems it works pretty fine for me
[17:42] <Daemon404> circular glib dep ftw
[17:42] <j-b> oh, yes --static
[17:43] <j-b> but, besides that, it's better than the rest
[17:43] <ubitux> seems you guys agree with cehoyos then
[17:43] <ubitux> you should reply in that thread
[17:43] <ubitux> ;)
[17:43] <Daemon404> nah
[17:43] <j-b> nah
[17:43] <Daemon404> its still less bad than what you have now
[17:43] <j-b> 17:43 < j-b> but, besides that, it's better than the rest
[17:43] <j-b> it's bad, but the other options are 10x worse
[17:44] <ubitux> ok so
[17:44] <ubitux> who's going to update our lib probing with pkg-config?
[17:44] <j-b> michael
[17:44] <ubitux> i mean it's been months that we try to have pkg-config for libx264
[17:44] <ubitux> i wonder how long it will take for the other libs
[17:45] <nevcairiel> i'm fascinated the x265 patch was actually applied :p
[17:45] <ubitux> i really don't mind updating the other libs supporting .pc
[17:45] <ubitux> i just don't want to fight for years to get the patch applied
[17:45] <ubitux> nevcairiel: cehoyos doesn't use it probably
[17:45] <ubitux> it's also pretty recent so it can be changed without the historical background we have for libx264
[17:45] <j-b> what I love is configure scripts that hardcode -lpthread
[17:46] <ubitux> :)
[17:47] <nevcairiel> pthread is a mess tho, the section for supporting pthreads in ffmpeg configure is like 20 lines
[17:47] <j-b> yep
[17:47] <nevcairiel> because of 20 different alternatives on different systems
[17:47] <j-b> pthreadGC2 <3
[17:48] <ubitux> btw, downstreams opinions on the Changelog patch welcome 
[17:48] <nevcairiel> why would downstream care about the changelog
[17:48] <nevcairiel> i never read the thing
[17:48] <nevcairiel> :D
[17:49] <ubitux> well, developers don't, downstreams probably do
[17:49] <ubitux> if they don't then... that's probably because the current one sucks
[17:49] <ubitux> i mean, if we document behaviour changes, have the library versions, and some release notes in it alongside the features
[17:49] <ubitux> maybe people will have a quick look to it after a release?
[17:49] <nevcairiel> i follow git more or less on a daily basis to get my change info, but then i'm probably not the most usual downstream
[17:50] <j-b> But, but, who is the true downstream?
[17:50] <ubitux> you are j-b!
[17:50] <ubitux> you are the one this time!
[17:50] <nevcairiel> so does vlc read the changelog?!? :)
[17:50] <ubitux> we'll soon know
[17:54] <cone-261> ffmpeg.git 03Anton Khirnov 07master:d754ed41727b: riffenc: take an AVStream instead of an AVCodecContext
[17:54] <cone-261> ffmpeg.git 03Michael Niedermayer 07master:2d7028225483: Merge commit 'd754ed41727b1fcbab335b510248a9758a73320c'
[18:04] <ubitux> ooh i finally see why he wants this hack
[18:06] <wm4> ooh?
[18:06] <ubitux> If I need FFmpeg with a particular x264 build, I
[18:06] <ubitux> compile x264 and prefer not to run "make install".
[18:06] <ubitux> basically he doesn't want to --prefix=/tmp/x264build
[18:06] <Daemon404> ... thats a stupid reason
[18:06] <ubitux> but actually he doesn't
[18:06] <ubitux> PKG_CONFIG_PATH focusing on the source directly might actually works
[18:06] <ubitux> since the .pc is here
[18:07] <ubitux> not sure though
[18:07] <wm4> ubitux: yes
[18:07] <wm4> mpv-build for example installs everything into a sub dir, and points PKG_CONFIG_PATH there
[18:08] <ubitux> yeah that's obviously the right way of doing this
[18:08] <ubitux> do you see another method?
[18:08] <ubitux> CE insists on having the old way still available
[18:08] <wm4> the configure script could have a generic way to force a lib
[18:08] <nevcairiel> i usually use make install into a custom prefix dir and point everything else at that as well, but of course thats still make install, never tried without
[18:10] <ubitux> should we somehow ignore the probing when --extra-{c,ld}flags are set?
[18:10] <ubitux> sounds like a bad heuristic to me
[18:10] <nevcairiel> thats terrible
[18:10] <ubitux> yes
[18:10] <nevcairiel> i set extra cflags for totally unrelated things
[18:11] <nevcairiel> or you know, the one or two libs that dont use pkg-config
[18:11] <nevcairiel> most old encoders, apparently
[18:11] <wm4> obviously it would need a new per-package flag
[18:11] <wm4> autoconfig might have an existing convention here
[18:13] <ubitux> yes they do, i mentioned it in the previous thread
[18:13] <ubitux> ^thread^mail
[18:16] <nevcairiel> ew he wants his hack to be applied to all other libs as well
[18:22] <Compn> Anton Khirnov master:894682a9739e: Remove avserver.
[18:22] <Compn> whats up with that
[18:22] <Compn> ubitux / wm4 / Daemon404 / nevcairiel : carl said all he wants is a failback if pkg-config fails
[18:23] <Compn> thats not that unreasonable is it ?
[18:23] <nevcairiel> its a ugly hack, so kinda is
[18:23] <ubitux> we do that to avoid a configure hell
[18:23] <ubitux> i think it's almost worth than keeping current hack
[18:25] <Compn> nevcairiel : how many lines of ugly is it ? :P
[18:26] <ubitux> twice as currently
[18:26] <cone-261> ffmpeg.git 03Clément BSsch 07master:5039aadf68de: avcodec/ass: explicit PlayRes[XY]
[18:26] <ubitux> wm4: ^
[18:26] <jamrial> michaelni: seems that your recent changes to libavcodec/bitstream.c are triggering some compiler bug in gcc 4.2.x
[18:27] <jamrial> other versions are unaffected
[18:27] <michaelni> jamrial, any idea why ?
[18:29] <michaelni> also 4.2 is kinda old does this affect something still maintained (aka should this be reported to gcc or is it just us using old compilers? )
[18:29] <jamrial> no, just noticed it on fate. every gcc 4.2.x slot is triggering it, regardless of arch
[18:30] <jamrial> and i doubt gcc is maintaining it
[18:31] <wm4> ubitux: thanks
[18:31] <jamrial> no, seems that 4.7 is the oldest they are maintaining
[18:31] <wm4> ubitux: you could have moved down the PlayRes headers, though (like I suggested)
[18:32] <michaelni> jamrial, ok so we just need to workaround it
[18:36] <ubitux> wm4: ah sorry, you mean below ScriptType?
[18:40] <wm4> yes
[18:40] <ubitux> wm4: will fix in a moment
[18:41] <ubitux> wm4: could you check if some stuff is badly supported in srt decoder in comparison to the mp* one?
[18:44] <wm4> uh, dunno
[18:45] <ubitux> well you said that the mp* code could be better than the ff one for some reasons
[18:46] <ubitux> since i originally wrote the one in mplayer i feel honored, but i'd love to see a better code maintained in ffmpeg nowadays :)
[18:46] <cone-261> ffmpeg.git 03Clément BSsch 07master:88514378bac9: avcodec/ass: move playres parameters below scripttype
[18:46] <ubitux> wm4: ^ fixed
[18:47] <wm4> thanks... it probably doesn't really matter, but good
[18:47] <wm4> the worse issue is that lavc still generates non-standard ASS
[18:48] <ubitux> ah, yeah that one
[18:48] <ubitux> grumbl
[18:48] <ubitux> i suddenly feel extremely tired
[18:48] <wm4> is it that hard to fix?
[18:49] <wm4> I think I even looked at it once, but don't remember
[18:49] <ubitux> yes you did
[18:49] <ubitux> and you realized it was a hell to fix
[18:49] <ubitux> so you looked at utf-16
[18:49] <ubitux> and abandonned too
[18:50] <ubitux> :(
[18:50] <wm4> heh
[18:50] <wm4> with utf-16 it's kind of annoying that it's all a hack
[18:50] <wm4> maybe it would actually be better to read the whole file into memory and convert that...
[18:51] <wm4> what formats did we say need utf-16 support?
[18:51] <ubitux> srt, sami and ass
[18:51] <ubitux> iirc
[18:52] <Compn> working on utf16 now ?
[18:52] <ubitux> wm4 wrote a cool patch already a while ago
[18:53] <ubitux> but it wasn't exactly completely good for applying
[18:53] <Compn> jamrial / michaelni : should we have a txt like apichanges but for known gcc versioned bugs ?
[18:53] <wm4> seems like everyone has his list of gcc versions that break his project
[18:53] Action: Compn looks at mplayer list :D
[18:53] <Compn> ehehe
[18:53] <Compn> anything gcc .0 breaks
[18:56] <Compn> i think they do it on purpose. maybe to see if they still have to fix whatever mplayer keeps breaking
[18:57] <wm4> I  think it's more like mplayer breaks gcc
[18:58] <Compn> 4.4.0 and maybe 4.6.0 had problems 
[18:59] <Compn> which is why i still think we should hack tcc up to compile ffmpeg and include it in the tree :P
[19:00] <Compn> me and my crazy ideas
[19:00] <ubitux> you mean "stupid" ideas, right? :)
[19:06] <gerion> ehm, short question, when writing a video filter; it is possible, that the resolution changes in the middle of the video stream? (can I use init() to change things that depends on the resolution or do I have to use filterframe etc.)
[19:07] <wm4> AFAIK not for filters
[19:07] <wm4> filters must be reinitialized for that
[19:09] <gerion> does the filter reinitializes itself or is this an extra method? :)
[19:13] <wm4> I assume the external code calls config...
[19:15] <gerion> hmm ok thx
[19:56] <cone-261> ffmpeg.git 03Anton Khirnov 07master:194be1f43ea3: lavf: switch to AVStream.time_base as the hint for the muxer timebase
[19:56] <cone-261> ffmpeg.git 03Michael Niedermayer 07master:ac293b66851f: Merge commit '194be1f43ea391eb986732707435176e579265aa'
[19:56] <cone-261> ffmpeg.git 03Michael Niedermayer 07master:75511c293add: dump_stream_format: fix division by 0
[20:16] <cone-261> ffmpeg.git 03Michael Niedermayer 07master:1d54f5108477: avformat/mux: simplify ff_choose_timebase()
[21:49] <J_Darnley> Does C not let you assign values to a variable like this?  point = { x, y };
[21:49] <J_Darnley> Assuming that the type of point is appropriate.
[21:51] <nevcairiel> i believe you need to shove a cast to the matching struct type in front
[21:51] <J_Darnley> oh yes, thank you
[22:07] <Daemon404> and that is c99-only
[22:20] <nevcairiel> well, i assumed its for ffmpeg, where its fine to be used
[22:26] <ubitux> so who is going to add a way of handling CE use case in the configure?
[22:26] <wm4> CE
[22:27] <Daemon404> thats a good one
[22:28] <ubitux> i don't think he plans to do it
[22:28] <wm4> then he'll have to deal with that
[22:35] <ubitux> well since he opposes to the patch unless a hack is available..
[22:47] <nevcairiel> ask him to provide it
[22:47] <nevcairiel> ball in his court etc
[22:47] <cone-261> ffmpeg.git 03Michael Niedermayer 07master:eec55e622a73: ffmpeg_opt: Dont exit on avformat_find_stream_info() failure if there are streams
[22:48] <ubitux> yeah well when i'll get some motivation back
[22:49] <ubitux> i've really better to do
[23:00] <cone-261> ffmpeg.git 03Lou Logan 07master:eba453e03ffe: doc/bitstream_filters: document imxdump
[23:05] Action: llogan trivial_patch_man
[23:22] <cone-261> ffmpeg.git 03Luca Barbato 07master:49a242687cf4: doc: Document segment_list_type
[23:22] <cone-261> ffmpeg.git 03Michael Niedermayer 07master:1ebc77bc7d68: Merge commit '49a242687cf44f86570b706db3c5912ff06bc6c2'
[23:26] <cone-261> ffmpeg.git 03Luca Barbato 07master:c9c1e00f9535: rtsp: Factor out fmtp parsing
[23:26] <cone-261> ffmpeg.git 03Michael Niedermayer 07master:be94f5c171d9: Merge commit 'c9c1e00f95350e7a36b0d05a03939c7f6438e371'
[23:32] <cone-261> ffmpeg.git 03Joshua Kordani 07master:c385313d2590: rtsp: Support misordered fmtp rtpmap
[23:33] <cone-261> ffmpeg.git 03Michael Niedermayer 07master:dacc4cb11513: Merge commit 'c385313d2590fd26e26bb9bdacddef78162ab490'
[23:37] <cone-261> ffmpeg.git 03Luca Barbato 07master:869fc416f7c7: hevc: Mark num_bins_in_se as unused
[23:37] <cone-261> ffmpeg.git 03Michael Niedermayer 07master:8e2ade43f1d0: Merge commit '869fc416f7c78ed4e397e0208acd1545771c0502'
[00:00] --- Thu Jun 19 2014