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

[burek]

[00:01] <kurosu> what's the specified max bitsize for a macroblock in MPEG2? 4000bits or something?
[00:02] <kurosu> err 2400
[00:06] <kurosu> actually 4608 for 4:2:0, twice that for 4:4:4
[00:07] <michaelni> from quick approximation  > 18kbit
[00:07] <michaelni> for 4:4:4
[00:07] <kurosu> I've looked at the specs, it was clearly listed as the values I mention
[00:08] <michaelni> its bad spec then
[00:08] <kurosu> though I haven't checked how up-to-date they are
[00:08] <kurosu> oh
[00:08] <kurosu> mpeg-1
[00:09] <michaelni> coefficients can be stored as escape and that takes 6bit vlc 6bit run 12bit level * 2x2 blocks 8x8 per block x3 for yuv
[00:09] <kurosu> actually not, it is mpeg-2
[00:09] <michaelni> this maxium is possibly not allowed though in valid bitstreams
[00:10] <kurosu> table 8-6, ISO/IEC 13818-2: 1995
[00:12] <kurosu> https://www.itu.int/rec/T-REC-H.262/recommendation.asp?lang=en&parent=T-REC-H.262-200002-S <- this too
[00:12] <michaelni> "8     Profiles and levels" <--- this lists whats allowed which isnt what could be stored in the bitstream
[00:13] <kurosu> agreed
[00:13] <michaelni> and i suspect many simple encoders do not check that they stay below this limit
[00:14] <kurosu> anyway, 4:2:2 mentions unconstained, which is what you describe
[00:15] <kurosu> anyway2, this is an example of probably how soon you may need to switch to cautious parsing with a granuality of a MB
[00:19] <michaelni> yes
[00:22] <kierank> iirc 4:4:4 is not defined fully
[00:55] <cone-113> ffmpeg.git 03Christophe Gisquet 07master:508e7a5c16c9: x86: huffyuv: fix {add,diff}_int16
[01:02] <llogan> ffplay -f x11grab -video_size $(xwininfo -root | awk '/geometry/ {print $2}' | cut -d "+" -f 1) -fs -i :0.0
[01:02] Action: llogan convulses
[01:05] <llogan> even better w/o -fs
[01:08] <ubitux> llogan: http://trac.ffmpeg.org/ticket/2563
[01:09] <wm4> llogan: what am I looking at
[01:10] <wm4> does it multiply the conversion errors?
[01:11] <llogan> just weirdness. for me at least. flickering and duplicating rendered windows
[01:11] <llogan> hundreds of mouse arrows
[01:13] <ubitux> oh i didn't realize
[01:13] <ubitux> ahah awesome
[01:14] <llogan> ubitux: https://github.com/lolilolicon/FFcast2/blob/master/xrectsel.c
[01:14] <ubitux> i don't know what the hell is going on but it's awesome
[01:14] <wm4> llogan: well I see blue and orange goo emerging
[01:14] <wm4> llogan: and conquering the screen and travelling left
[01:14] <llogan> goo? also weird.
[01:15] <ubitux> llogan: so why isn't this an option in the x11grab code?
[01:15] <ubitux> i don't understand people :(
[01:15] <llogan> not sure if it is useful or clean, but allows user to draw a box on screen or select a window to select area to record.
[01:15] <llogan> IIRC+AFAIK
[01:16] <ubitux> yeah right
[01:16] <ubitux> but it could be in the lib.
[01:16] <ubitux> as a simple option
[01:16] <llogan> yes, that would be nice
[01:21] <wm4> so, how does ffplay actually set options?
[01:21] <wm4> I find this pretty confusing
[01:21] <cone-113> ffmpeg.git 03Luca Barbato 07master:2f4170312f60: libx264: Support bitrate reconfiguration
[01:21] <cone-113> ffmpeg.git 03Michael Niedermayer 07master:8159fe255cca: Merge commit '2f4170312f605c1f02a14c01347e94cf46726dbd'
[01:21] <cone-113> ffmpeg.git 03Michael Niedermayer 07master:3a1c8951bc88: avcodec/libx264: fix "bitrate reconfiguration"
[01:21] <wm4> with ffplay -video_format just works, but API-wise it's not clear what to use...
[01:22] <wm4> seems like av_opt_set doesn't work, but putting it into the AVDictionary passed to lavf works
[01:25] <BtbN> Anyone familiar with using vdpau with libavcodec? I got it somewhat working, but the resulting image is jumping around like it's not propperly ordered by pts, and the quality is extremely bad, i have extreme movement artefacts which aren't present when decoding in sw mode.
[01:25] <wm4> BtbN: new or old api?
[01:25] <BtbN> uhm
[01:26] <BtbN> i looked at the XBMC code to learn how to do it
[01:26] <wm4> sounds like a bad idea
[01:26] <wm4> xbmc love hacks
[01:26] <BtbN> well, i couldn't find any documented examples, so looking at existing code was the only way i found to learn about it
[01:27] <BtbN> i believe XBMC uses the new api. It uses get_format to select the VDPAU pixel format
[01:27] <wm4> here is the "example": https://git.videolan.org/?p=ffmpeg.git;a=blob;f=ffmpeg_vdpau.c
[01:27] <wm4> yes that sounds like new api
[01:27] <wm4> and they also don't set the slice callback?
[01:28] <BtbN> it sets a AVVDPAUContext in the AVCodecContext and set render2 there
[01:28] <wm4> render2? sounds wrong
[01:29] <wm4> although it should also work
[01:29] <BtbN> From looking at the ffmpeg vdpau code render2 is just the same as setting render + decoder, just that you can do some more stuff on render.
[01:29] <BtbN> XBMC creates the decoder there, i believe to react to format changes
[01:29] <wm4> yeah
[01:30] <wm4> no
[01:30] <wm4> that shouldn't be needed
[01:30] <wm4> fromat changes call get_format, so you can do it there
[01:30] <wm4> although render2 might be useful for some things, it's probably better not to use it
[01:30] <wm4> and libav doesn't have this callback at all
[01:30] <BtbN> ah, ok. That makes the code a little easier
[01:31] <wm4> pts is handled like with the software decoder
[01:31] <wm4> and the decoder of course returns the frames in display order
[01:32] <BtbN> I completely ignored PTS in sw decoding mode, and just displays the images in the order decode2 returned them
[01:33] <BtbN> https://gist.github.com/BtbN/040907be634ac3595433 that's what i got so far
[01:37] <wm4> there's an avcodec function somewhere to map the codec profiles
[01:38] <wm4> assigning reorderd_opaque shouldn't be needed anymore
[01:39] <wm4> setting the thread count in get_format is probably not sane
[01:39] <wm4> setting slice_flags should be unneeded and is probably harmful too
[01:40] <wm4> in general I'd set all these fields right from the start
[01:40] <BtbN> that part is basicaly straight from XBMC code
[01:40] <wm4> instead of trying to forcing them in get_buffer
[01:40] <wm4> that doesn't mean it's a good idea
[01:40] <Daemon404> get_buffer is deprecated
[01:40] Action: Daemon404 runs
[01:40] <wm4> err I mean get_format
[01:41] <BtbN> I kind of feel like avcodec is doing its job fine, and it's something in my rendering code that chokes
[01:41] <wm4> it's setting SLICE_FLAG_CODED_ORDER
[01:41] <wm4> what
[01:42] <wm4>         p->extradata = std::vector<uint8_t>(p->vstream->codec->extradata, p->vstream->codec->extradata + p->vstream->codec->extradata_size);
[01:42] <wm4>         p->lavcCtx->extradata = p->extradata.data();
[01:42] <wm4>         p->lavcCtx->extradata_size = (int)p->extradata.size();
[01:42] <wm4> broken
[01:42] <wm4> extradata needs input padding
[01:43] <wm4> it also sets a bunch of wtf fields
[01:43] <wm4> debug_mv - what
[01:43] <wm4> so yeah I'd rather copy&paste the ffmpeg_vdpau.c code, if you must
[01:44] <BtbN> I'm not in a rush, it was more like me beeing "meh, they're propably setting that for a reason"
[01:45] <Daemon404> wm4, btw xmbc is the only other project besides mplayer which has hacks inside ffmpeg
[01:45] <wm4> the xbmc style of development seems to be to hack on stuff as hard as they can until it somehow works
[01:45] <Daemon404> there was some // for xmbc
[01:45] <Daemon404> and stuff
[01:45] <wm4> lol
[01:45] <BtbN> The XBMC render code is extremely wtf, yes
[01:45] <Daemon404> some people hered a derp when i removed a private symbol that was being exported with a //hack for xmbc comment
[01:45] <BtbN> but it works somehow
[01:45] <Daemon404> herped*
[01:45] <wm4> well if it wouldn't work they'd obviously hack it some more until it does
[01:45] <BtbN> xbmc also has its private fork of ffmpeg which they keep patching
[01:46] <wm4> yeah, stuff like that
[01:46] <Daemon404> reminds me of ffdshow
[01:46] <BtbN> mainly to overcom the libav situation, but as it's already there, they can as well patch it
[01:46] <Daemon404> //ffdshow custom code
[01:46] <Daemon404> all over the place
[01:50] <BtbN> https://btbn.de/files/screen.png that's what the rendered video looks like. The artifacts is where the thing has moved along
[01:52] <wm4> BtbN: remove hacks first
[01:53] <BtbN> removed most of them, didn't change a thing. I don't realy think its a problem in libavcodecs side of things
[01:53] <wm4> next make sure you manage frames correctly
[01:53] <wm4> e.g. you don't reuse a frame when you shouldn't
[01:54] <BtbN> I'll update the gist, wait a second
[01:55] <BtbN> https://gist.github.com/BtbN/040907be634ac3595433 i forgot about the extradata, could that alone be the source of my issues? I'm doing the same for swdecoding and it seems to work
[01:56] <wm4> forgot what?
[01:56] <BtbN> to fix the extradata padding size adjustment
[01:56] <wm4> well extradata needs alignment and padding
[01:57] <wm4> so it's best to alloc it with av_mallocz
[01:57] <wm4> and not C++ stuff
[01:57] <wm4> but I don't know if it actually can lead to issues or if it's more a theoretical thing
[01:57] <BtbN> av_mallocz automaticaly gives aligned memory?
[01:57] <wm4> yes
[01:57] <BtbN> ok, i'll just use that then.
[01:58] <Daemon404> ... is an std::vectors's data even guaranteed to be contiguous?
[01:58] <BtbN> yes
[01:59] <Daemon404> right ok
[02:03] <BtbN> https://gist.github.com/BtbN/040907be634ac3595433#file-decoder-cpp-L405 that should be ok?
[02:04] <wm4> yeah
[02:06] <BtbN> For the output frame management i'm using a class which has two state variables. One for "is in use by ffmpeg", i set it to 1 when the frame is got in GetBuffer2, and reset it to 0 after i got the frame from avcodec_decode_video2(). Maybe that is part of the problem, should i keep it occupied and not re-use it until ReleaseBuffer is called?
[02:06] <Daemon404> man is there anything qt *doesnt* (re)implement...
[02:07] <BtbN> Daemon404, well, Qt supports some exotic compilers and runtimes, and it had that stuff well before it got a C++ standard
[02:07] <Daemon404> that doesnt mean qt5 needs it
[02:07] <BtbN> they still do support stuff like msvc2008
[02:08] <wm4> BtbN: wrong
[02:08] <BtbN> oh, they dropped 2008?
[02:08] <wm4> BtbN: just because a frame is returned by the decoder it doesn't mean the frame is not needed anymore
[02:08] <wm4> BtbN: you have to release the frame when the avbuffer for it is released
[02:08] <wm4> BtbN: the avbuffer controls the lifetime of the frame
[02:08] <Daemon404> should it automatically do that for you if you set the callback properly
[02:09] <Daemon404> shouldnt*
[02:09] <BtbN> ok, so that might already be part of the problem then. Is it ok to imediately use it for rendering?
[02:09] <BtbN> Daemon404, currently i set the ffState to 0 after i got the frame from decode2, and not at all in the release callback
[02:09] <BtbN> which i just realized seems wrong while writing up what i'm doing
[02:10] <wm4> Daemon404: no, because lavc doesn't actually access vdpau
[02:10] <BtbN> yep, that was it
[02:10] <BtbN> image is de-broken now
[02:10] <wm4> except for the render callback (which is very strange and why a mplayer dev added render2)
[02:11] <BtbN> lol, i'm nearly completely using up my poor gt gpu with that.
[02:11] <BtbN> 5 1080p videos at 120 fps is aparently a little much
[02:12] <BtbN> The OpenGL vdpau interop seems to be fine with my massive multithreading. I suspected that to be the problem and was kind of afraid i have to completely redesign for hw acceleration
[02:13] <BtbN> Now i just have to merge the sw decoding part back in
[02:14] <nevcairiel> that reminds me that i need to write a opengl video renderer, i'm not looking forward to that
[02:14] <Daemon404> nevcairiel, for work
[02:14] <Daemon404> ?
[02:14] <nevcairiel> yeah
[02:15] <Daemon404> lul
[02:15] <Daemon404> wm4 wrote a gl3 one iirc
[02:15] <BtbN> nevcairiel, that was the easiest part. For vdpau as well as for swdecoding.
[02:15] <nevcairiel> expanding to mac and linux
[02:15] <BtbN> It's not even a lot of code
[02:15] <BtbN> and it works on every platform
[02:15] <wm4> BtbN: yeah vdpau is generally fine with threading
[02:15] <nevcairiel> its probably not all that hard, but my last opengl was like 10 years ago
[02:15] <BtbN> well, it's not a normal video render. More like a "render 5 videos and apply a magic shader to it" renderer
[02:16] <wm4> how painful using opengl is depends mostly where it has to run
[02:16] <BtbN> with all 5 videos beeing 1080p and 120 fps
[02:16] <nevcairiel> does "not windows" help?
[02:16] <BtbN> I'm using OpenGL 3.2 Core, it should work on a reasonable ammount of machines
[02:17] <wm4> nevcairiel: also the driver... e.g. binary AMD drivers on linux are the worst shit ever
[02:17] <wm4> mobile GLES drivers are often low quality etc.
[02:18] <nevcairiel> for now only x86 desktop things are in focus, but that doesnt exclude amd shit sadly
[02:18] <wm4> also Intel drivers
[02:18] <wm4> there's one popular intel gpu that doesn't support any non-ancient opengl stuff
[02:19] <BtbN> I was pretty surprised when using OSX in a VM lately
[02:19] <BtbN> their OpenGL software renderer has full support for OpenGL up to 4.0 or 4.1
[02:19] <wm4> hm so opengl does work with osx in a vm?
[02:19] <nevcairiel> one interesting tidbit is that i'll have to make it work flawlessly on a baytrail atom and its gpu, since we also have hardware devices that use that :p
[02:19] <BtbN> wm4, yep
[02:20] <BtbN> it's not fast, because software rendering, but it has full support
[02:20] <wm4> soudns useful
[02:20] <wm4> what vm?
[02:20] <BtbN> HW acceleration isn't supported for OSX guests in vmware
[02:20] <BtbN> i'm using VMWare workstation
[02:20] <nevcairiel> oh well, i just started with the playback pipeline today, wont get to the renderer until a few more days
[02:20] <BtbN> It's fine with running OSX as FreeBSD aparently
[02:21] <BtbN> It even detected it's OSX and emulated an EFI
[02:21] <BtbN> so i could install from my normal disk
[02:21] <nevcairiel> i'm mostly worried about properly syncing audio and video up, but maybe it just manages to fall into place
[02:22] <BtbN> yeah, timing stuff allways is extremely annoying
[02:25] <BBB> ubitux: got more details?
[02:27] <BBB> oh trac, I see
[02:34] <BtbN> It seems to have issues with rewinding. It's jumping between old and new frames there
[02:34] <BtbN> But apart from that it's seems to be running perfectly now.
[02:37] <wm4> do you flush the decoder?
[02:37] <BtbN> yeah
[02:38] <BtbN> It's also not perfectly in sync between the 5 decoders. Sometimes one of them seems to be ahead for a frame or two, however that is even possible.
[02:39] <wm4> why wouldn't it
[02:40] <BtbN> because they are all decoding videos which have the exact same number of frames. So i'd kind of expect to get the matching frames if i call decode2 the same ammount of time on each decoder
[02:40] <wm4> not at all
[02:41] <wm4> scheduling etc. can introduce difference, so if you don't explicitly synchronize them, it's not surprising they desync
[02:41] <BtbN> I am synchronizing the rendering if you mean that. I render the next frame only if i got a new frame from all 5 decoders
[02:41] <BtbN> in sw decoding mode that works perfectly.
[02:42] <wm4> yeah sounds like that should work
[02:47] <BtbN> It's realy strange, like it's jumping ahead one frame, and then gives up on it. I have an idea where that's coming from though, the vdpau decoder might be too fast, so it's exhausting the texture pool and start over writing it from the beginning.
[02:48] <wm4> you might have to wait for a vdpau surface before displaying it, not sure
[02:52] <BtbN> yeah, i'm rendering it again into an OutputSurface, and then bind that to an OpenGL texture, which is then rendered.
[02:52] <BtbN> maybe it just needs a glFinish call somewhere
[02:53] <BtbN> but thank you very much, would have propably taken me ages to find that problem otherwise
[02:57] <wm4> in my code I don't need glFinish
[03:10] <Timothy_Gu> [10:07] <@Daemon404> why the fuck do people reply with "fails build because no default" <--- mind your language
[03:10] <BBB> ubitux: fixed
[03:11] <Timothy_Gu> Daemon404: i didnt see your "that was dumb of me" email
[03:12] <Timothy_Gu> sorry about that
[04:16] <cone-113> ffmpeg.git 03Ronald S. Bultje 07master:385a3420d1da: vp9/x86: fix overwrite in ipred_vl_4x4_ssse3.
[04:24] <jamrial> wow, the cinepak encoder is absurdly slow
[04:28] <BBB> lol cinepak encoder
[04:49] <jamrial> bah, the whole split lanes in AVX sucks
[04:49] <jamrial> it's all fine and dandy when you do stuff vertically, but as soon as you need to do stuff horizonally most of the benefits of having wider regs go down the drain
[04:50] <jamrial> pshufb, psrl*, all with lane constrains
[04:50] <fionag> yup ^^;
[04:53] <jamrial> i'm looking at porting the rest of the intra pred vp9 functions, but they all need shifting and the split lanes ruin everything
[04:53] <jamrial> they are probably going to need some palignr fest
[04:58] <BBB> hehe
[04:58] <BBB> jamrial: yeah thats a known issue :/
[06:52] <BtbN> wm4, yes, it actualy was just a glFinish it needed
[06:53] <BtbN> i have 5+5+1 threads. 5 threads with the ffmpeg decoders, 5 OpenGL upload threads(which are quite pointless for VDPAU but present for swdecode compat) and the main render thread. Calling glFinish in the upload threads after mapping the VDPAU surfaces made it work perfectly.
[08:04] <ubitux> BBB: thx :)
[08:54] <cone-614> ffmpeg.git 03Ronald S. Bultje 07release/2.2:98f33430a2a7: vp9/x86: fix overwrite in ipred_vl_4x4_ssse3.
[10:09] <durandal_1707> ubitux: are you going to apply showcqt fullhd option patch?
[10:10] <ubitux> ah, i missed it
[10:11] <ubitux> i guess i'll rebase it and resubmit it, since i fixed the style in between
[10:12] <ubitux> durandal_1707: why do you ask, interested in this?
[10:12] <durandal_1707> i expected it gonna be applied
[10:14] <durandal_1707> changes looks fine to me (a tried it yesterday)
[10:15] <ubitux> ok
[10:16] <ubitux> well if you're motivated, go ahead
[10:16] <ubitux> i'll try to do it in a day or two
[11:16] <cone-614> ffmpeg.git 03Muhammad Faiz 07master:0a64fb7fb0bb: avfilter/avf_showcqt: add option for lower resolution
[13:24] <BBB> ubitux: np
[13:25] <cone-614> ffmpeg.git 03Anton Khirnov 07master:48e509213379: avconv: make -shortest work with streamcopy
[13:25] <cone-614> ffmpeg.git 03Michael Niedermayer 07master:52ce6be86b6a: Merge commit '48e50921337984ba4ec2c1cafe45d43787f84498'
[13:42] <BBB> michaelni: any more comments on the swr patch?
[13:44] <BBB> michaelni: exposing ResampleContext is probably a bad idea, so Im not sure whats the right way yet - I suppose a function that returns -(c->index>>c->phase_shift) would be OK, any better ideas
[13:44] <BBB> (unless you think this isnt ugly, in which case I suppose its fine)
[14:03] <BBB> plepere: hm, why start over? whats so bad about the current asm that it needed a restart?
[14:04] <plepere> I think it's better if things look the same for the same function
[14:04] <BBB> then you should look at vp9 :-p
[14:04] <BBB> its much more tuned for the big transforms
[14:04] <plepere> and I guess that the x264 guys are better than be. :)
[14:05] <plepere> D: I don't know what to believe now !
[14:05] <BBB> you should honestly do whatever you want
[14:06] <plepere> where is your idct ?
[14:06] <BBB> the problem of the h264/vp8 approach is that youll have two versions of functions, one for dc_add and one for regular idct
[14:06] <BBB> for big transforms, thats very not-ideal
[14:06] <BBB> the vp9 approach is more granular
[14:06] <plepere> BBB : that's how it's done in openHEVC
[14:06] <plepere> I think it's done for better ARM compatibility
[14:06] <BBB> ffh264 has this nice trick where we do multiple 4x4s per call, vp9 doesnt do that yet (its on my TODO list, not sure Ill ever get to it)
[14:07] <BBB> I call it the chicken-way out approach
[14:07] <BBB> as in, you get 50% of the speed benefit, and thats enough for lazy people who can claim 50% of the credit
[14:07] <BBB> I believe vp9s approach is much better, but its also harder for the dude writing the asm (ask ubitux)
[14:07] <BBB> not much harder, but still a bit
[14:08] <plepere> you'll have to convince mraulet.
[14:08] <BBB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/x86/vp9itxfm.asm;h=8087c2e336209b1e35f33565c0c047a6bd16eea2;hb=HEAD#l444
[14:09] <BBB> it splits it in 4 function-parts, one for the dc only, one for the topleft 2x2, one for the topleft 4x4, and one for the full 8x8
[14:09] <BBB> and thats just for the 8x8
[14:10] <BBB> the 16x16/32x32 dont do all subsizes, because that was too much code and actually slowed it down (code cache)
[14:10] <plepere> is it the same granularity for the 32x32 ?
[14:10] <BBB> 32x32 does dc-only, topleft-8x8, topleft-16x16 and full 32x32
[14:11] <BBB> 16x16 does only topleft-8x8, full 16x16 or dc-only
[14:12] <plepere> bah, I don't have much to say about how things are done in OpenHEVC. Maybe once I'm unemployed from here I'll take liberties. :p
[14:12] <BBB> your decision structure is obscure, youre not a corportaion
[14:13] <plepere> but for the moment I need to do the transform non-dc in asm
[14:13] <BBB> mraulet isnt here btw
[14:13] <plepere> yeah
[14:13] <BBB> ...
[14:14] <plepere> but basically, I'm going with the flow, He wants things done in a certain way and with results, so I just get it done.
[14:14] <BBB> ok
[14:14] <BBB> I dont mind the earlier patch you posted, but anyway, Ill await the h264 way of doing things
[14:15] <BBB> how do you guys plan to manage people submitting code directly to ffmpeg?
[14:15] <BBB> what if I send a patch to ffmpeg to add new/better asm?
[14:16] <plepere> I think it's integrated back in openHEVC. The chanes are quite minimal for now  (like ASM opts)
[14:17] <plepere> if you change how transforms are done, it might be more tricky
[14:18] <plepere> BTW, I might disconnect, some electric testing being done.
[14:18] <BBB> ok
[14:18] <plepere> openHEVC is open source
[14:20] <BBB> ffmpeg and libav are both opensource, yet people rarely send patches to both
[14:20] <j-b> which is why we need to do a 3rd fork :)
[14:21] <ubitux> not enough ppl, there are only 2 dev split between 2 projects
[14:21] <plepere> the horror
[14:22] <plepere> anyways, once I'll be out of here, (and found another job) I'll try to keep working on FFmpeg's HEVC.
[14:23] <plepere> I really want to do AVX2 functions
[14:27] <Daemon404> [13:20] <@BBB> ffmpeg and libav are both opensource, yet people rarely send patches to both <-- basically only me
[14:28] <BBB> ////////////
[14:28] <BBB> '
[14:28] <Daemon404> wat
[14:28] <BBB>  ;/ mm./.;/
[14:28] <BBB> ?
[14:29] <Daemon404> you typed a bunch of gibberish
[14:29] <j-b> plepere: when do you chage job?
[14:30] <plepere> j-b : my contract ends at the end of october.
[14:30] <plepere> but I can leave mid september.
[14:31] <plepere> I'm trying to find an opportunity outside of France if possible, but its complicated.
[14:31] Action: Daemon404 notes most good engineers seem to be fleeing France for jobs elsewhere
[14:32] <j-b> plepere: why complicated?
[14:33] <plepere> Daemon404, I must admit that France is much like a sinking ship. I hope that after a couple of years abroad, I'll be able to come back with a good enough background to have a nice job back in France
[14:33] <plepere> j-b : lots of people want to go abroad and companies prefer getting local engineers rather than going through the hassle of sponsoring a visa and all that.
[14:34] <plepere> got an interview for a 2 year contract in Singapore, though, which is like... the best thing ever for me. :D
[14:35] <plepere> ok, turning things off. brb
[14:37] <Daemon404> michaelni / ubitux  -- any comments on the sws filter size patch besides configure stuff?
[14:38] Action: ubitux will only comment on the configure part
[14:38] <ubitux> Daemon404: configure is annoying?
[14:38] <BBB> Daemon404: that was my kid
[14:38] <Daemon404> BBB, oh ok
[14:38] <BBB> :)
[14:38] <Daemon404> i thought maybe a cat
[14:38] <Daemon404> a child makes sense too.
[14:38] <BBB> close
[14:39] Action: Daemon404 fiddles with lcms2
[14:39] <Daemon404> icc profiles can go to hell
[14:54] <Daemon404> ubitux, i see
[14:54] <Daemon404> so should i send a v3... or await more comments
[15:01] <plepere> back !
[15:18] <ubitux> Daemon404: btw, no sanity check like pow of 2 required?
[15:18] <Daemon404> ask michaelni 
[15:19] <ubitux> anyway no more comment from me i guess
[17:44] <cone-335> ffmpeg.git 03Derek Buitenhuis 07master:4e9b46b05681: libx265: Actually use X265_API_IMPORTS
[17:44] <cone-335> ffmpeg.git 03Derek Buitenhuis 07master:6ee95af8a118: libx265: Add 4:2:2 support
[17:44] <cone-335> ffmpeg.git 03Derek Buitenhuis 07master:7ed89addb7f6: libx265: Remove unneeded bit depth check
[19:19] <llogan> user is told to use something newer than 0.6. user "upgrades" to SVN-r15261
[19:19] <nevcairiel> is that actually newer
[19:20] <llogan> idk
[19:20] <llogan> still, a laugh track played out of thin air
[19:20] <llogan> or Yackety Sax
[21:12] <cone-714> ffmpeg.git 03Diego Biurrun 07master:dca7ba4bffe3: Remove some unnecessary CONFIG_FOO_COMPONENT ifdefs
[21:12] <cone-714> ffmpeg.git 03Michael Niedermayer 07master:c600c8e96699: Merge commit 'dca7ba4bffe3e4aeb620cb62955256a0d87561f4'
[21:27] <cone-714> ffmpeg.git 03Derek Buitenhuis 07master:180e6b48060f: libx265: Actually use X265_API_IMPORTS
[21:27] <cone-714> ffmpeg.git 03Michael Niedermayer 07master:ff0631ab058b: Merge commit '180e6b48060f97fdd8497320395b61dc85664ecd'
[21:30] <cone-714> ffmpeg.git 03Derek Buitenhuis 07master:61a344916d32: libx265: Add 4:2:2 support
[21:30] <cone-714> ffmpeg.git 03Michael Niedermayer 07master:451469fd1aa1: Merge commit '61a344916d324c8ca52064964478f46c877f02e2'
[21:31] <cone-714> ffmpeg.git 03Derek Buitenhuis 07master:ceada893bec1: libx265: Remove unneeded bit depth check
[21:31] <cone-714> ffmpeg.git 03Michael Niedermayer 07master:6286bb5c07dd: Merge commit 'ceada893bec1e29e457bd2b81d8a0b6fcba5f1f7'
[21:43] <J_Darnley> Well...
[21:43] <J_Darnley> I am sucessfully drawing frames with my skeleton of a filter
[21:43] <J_Darnley> Just not as many as needed.
[22:43] <cone-714> ffmpeg.git 03sfan5 07master:ffe6ecc418ad: lavd/avfoundation: Support user selected pixel formats and pixel format autoselection.
[00:00] --- Fri Jun 13 2014