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

[burek]

[00:48:54 CEST] <cone-199> ffmpeg 03James Almer 07master:7d8e19a5c4d2: avutil: make crypto testprogs include headers only
[03:50:30 CEST] <cone-303> ffmpeg 03Michael Niedermayer 07master:65ffc0b1ed04: avutil/float_dsp-test: Add include config.h for HAVE_*
[03:50:30 CEST] <cone-303> ffmpeg 03James Almer 07master:cd244fae9847: avutil/cpu-test: Fix includes (needed for HAVE_*)
[09:08:56 CEST] <cone-646> ffmpeg 03Carl Eugen Hoyos 07master:d1cacbbea946: lavc/libutvideoenc: Cast an unsigned constant to int.
[09:10:51 CEST] <esdwdftty> http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=110383
[09:11:02 CEST] <esdwdftty> https://aomedia.googlesource.com/aom/
[09:11:32 CEST] <esdwdftty> !!!!!!!!!!!!!!!!!!!!!!!!!!
[09:18:16 CEST] <esdwdftty> 3421
[09:48:45 CEST] <fritsch> wm4: ping
[09:49:02 CEST] <fritsch> wm4: http://forum.kodi.tv/showthread.php?tid=231955&pid=2332729#pid2332729 <- did you ever check how exact vaapi's hw decoder works?
[09:50:13 CEST] <fritsch> there is a guy on our forum that used an hdmi capture card and it seems that vaapi supresses some details in its output. sw decoding is fine. Currently let him try with mpv to see if it has the same issue. The intel people most likely want to have it reproduced with gstreamer, but just wanted to ask if you have seen something like that before?
[09:50:18 CEST] <fritsch> BtbN: ^^
[09:50:45 CEST] <fritsch> on the supplied images you can see that directly when comparing the green grass
[09:50:51 CEST] <nevcairiel> you can run fate with vaapi if you want, that'll show you if its bitexact
[09:50:54 CEST] <nevcairiel> which afaik it is
[09:51:29 CEST] <nevcairiel> possibly your vaapi output  chain isnt quite as good, if you use direct rendering to some degree
[09:53:42 CEST] <fritsch> NV12 zero copy and then yvu2rgb shader
[09:54:08 CEST] <fritsch> and disabling vaapi, using sw decoding and same yuv2rgb shader -> all details are there
[09:54:38 CEST] <nevcairiel> just saying that you can test the decoder with copyback just by running "make fate-h264 HWACCEL=vaapi"
[09:54:50 CEST] <nevcairiel> (some always fail, but that should be a minor subset, 1-3 or so)
[09:55:06 CEST] <nevcairiel> if that passes, then something in how you use vaapi is to blame
[09:55:15 CEST] <fritsch> okay, thx much - I will test that first
[09:55:36 CEST] <nevcairiel> maybe its copy-back things are not quite as nice =p
[09:55:41 CEST] <nevcairiel> eh, copy-less things
[09:59:51 CEST] <jkqxz> The default settings there don't quite work.  I use $(make HWACCEL='vaapi -vaapi_device /dev/dri/renderD128 -hwaccel_output_format yuv420p -hwaccel_lax_profile_check' fate-h264), which does.
[10:00:14 CEST] <fritsch> what are the defaults?
[10:00:14 CEST] <jkqxz> (Someone forgot to escape something properly, but it helps here...)
[10:00:57 CEST] <fritsch> and what's the lax_profile_check?
[10:01:25 CEST] <fritsch> and is yuv420p produced with ffmpeg or by vaapi - and how is the data fetched?
[10:01:32 CEST] <nevcairiel> sounds like someone should fix the vaapi module to not suck
[10:01:39 CEST] <fritsch> hehe
[10:02:01 CEST] <jkqxz> It gives you the hardware format (probably NV12) and doesn't auto-convert for some reason I didn't pursue; it refuses to decode the all the baseline profile streams because they technically aren't supported.
[10:02:07 CEST] <jkqxz> Yeah, probably :)
[10:02:25 CEST] <fritsch> until some months ago vaapi had no way to get the NV12 data directly
[10:02:26 CEST] <nevcairiel> giving you NV12 is fine, that still passes fate
[10:02:34 CEST] <nevcairiel> dxva2 does that too
[10:04:40 CEST] <ubitux> lol d1cacbbea
[10:04:58 CEST] <jkqxz> s/convert /convert correctly /, perhaps?  The yuv420p which comes out of vaapi is bit-exact, though, so I just use that and haven't investigated further.  I guess I probably should now that other people can use it and will ask why its wrong...
[10:08:11 CEST] <fritsch> Test h264-conformance-aud_mw_e failed. Look at tests/data/fate/h264-conformance-aud_mw_e.err for details.
[10:08:17 CEST] <jkqxz> "and is yuv420p produced with ffmpeg or by vaapi - and how is the data fetched?" - on Intel the decoded surfaces are nv12, it gets downloaded by vaGetImage (i.e. VPP) to yuv420p, then maps the yuv420p buffer and copies to an AVFrame output.  ffmpeg doesn't convert anything there.
[10:11:46 CEST] <fritsch> jkqxz: okay - that we used too with sse4 intrinsics before we got this mesa / egl sharing
[10:14:36 CEST] <fritsch> only fate-h264-conformance-cvfc1_sony_c seems to fail
[10:14:43 CEST] <fritsch> jkqxz: same for you?
[10:15:02 CEST] <wm4> nevcairiel: I didn't but that seems quite a specific issue
[10:15:39 CEST] <wm4> err
[10:15:46 CEST] <wm4> fritsch not nevcairiel 
[10:16:09 CEST] <fritsch> wm4: i let him test with mpv later on :-)
[10:16:36 CEST] <fritsch> btw. howto skip a fate test to run the other tests?
[10:16:46 CEST] <wm4> apt-get will usually install an ancient version btw.
[10:16:58 CEST] <fritsch> if it works -> fine
[10:17:01 CEST] <jkqxz> Sounds good.  fate-h264-lossless always fails for me, and h264-conformance-frext-hpcvmolq_brcm_b / h264-conformance-frext-hpcamolq_brcm_b (the greyscale ones) do in some cases.
[10:17:13 CEST] <nevcairiel> also the sony one
[10:17:32 CEST] <fritsch> it seems for me it stops after the sony file
[10:17:39 CEST] <jkqxz> Yeah, that one always fails.
[10:17:41 CEST] <jkqxz> make -k ?
[10:17:52 CEST] <fritsch> let me try - first time fade
[10:17:52 CEST] <wm4> is the sony one cropping?
[10:18:03 CEST] <jkqxz> Yes.  Top/left cropping.
[10:18:30 CEST] <fritsch> h264-lossless fails
[10:18:31 CEST] <fritsch> yes
[10:19:21 CEST] <fritsch> [vaapi @ 0x3f53e20] No VAAPI support for codec h264 profile 244: trying instead with profile 100. [vaapi @ 0x3f53e20] This may fail or give incorrect results, depending on your hardware.
[10:19:27 CEST] <fritsch> yeah, seems that's planned to fail
[10:19:44 CEST] <fritsch> as input is 4:4:4
[10:20:00 CEST] <nevcairiel> that seems unlikely, it would not use the hwaccel at all for 444
[10:20:38 CEST] <nevcairiel> lossless isnt necessarily 444
[10:20:47 CEST] <nevcairiel> that test in particular is 420 i think
[10:21:14 CEST] <fritsch> Stream #0:0: Video: h264 (High 4:4:4 Predictive), yuv420p, 640x480, 25 fps, 60 tbr, 1200k tbn
[10:21:52 CEST] <nevcairiel> thats just the profile name, the actual stream property is yuv420p
[10:21:58 CEST] <nevcairiel> hence 4:2:0
[10:22:18 CEST] <nevcairiel> you can use any higher profile and only encode lower things in it
[10:22:26 CEST] <nevcairiel> could use 10-bit profile and encode 8-bit content
[10:22:30 CEST] <nevcairiel> just that noone does that
[10:22:36 CEST] <nevcairiel> but there is no other lossless profile ;)
[10:23:22 CEST] <BtbN> btw., we will be merging the libav and ffmpeg nvenc encoders, so both are the same.
[10:25:16 CEST] <jkqxz> It's the -hwaccel_lax_profile_check option which is allowing it to even try there.  Without it the hwaccel will reject the stream and use software - correctly, in this case.
[11:34:29 CEST] <fritsch> okay, we do something wrong
[11:34:34 CEST] <fritsch> in our sse copy path all fine
[11:34:42 CEST] <fritsch> in our zero copy egl path -> issue
[11:34:44 CEST] <fritsch> decoder is fine
[11:34:54 CEST] <BtbN> My guess would be limited vs. full range rgb/yuv.
[11:34:57 CEST] <fritsch> nope
[11:35:03 CEST] <fritsch> that was already tested
[11:35:11 CEST] <fritsch> same issue with limited / full
[11:35:17 CEST] <fritsch> we get the data in limited
[11:35:29 CEST] <BtbN> colorspace?
[11:35:31 CEST] <fritsch> and depending on the output settings, it is scaled with dithering or not touched
[11:35:35 CEST] <fritsch> both NV12
[11:35:45 CEST] <BtbN> That's not the colorspace though
[11:35:52 CEST] <fritsch> and the yuv2rgb shader is the same for sse copy path and sw path
[11:36:07 CEST] <fritsch> so the last render step is the same for all
[11:36:10 CEST] <BtbN> Wouldn't be surprised if the EGL stuff in VAAPI messes with it
[11:36:26 CEST] <fritsch> as it is "zero" copy i wonder
[11:36:39 CEST] <BtbN> It's "don't pull it to system ram"
[11:36:40 CEST] <fritsch> but that's what we will investigate next
[11:36:56 CEST] <fritsch> i don't think it's the zero copy
[11:37:06 CEST] <fritsch> as both times we use the same source
[11:37:24 CEST] <fritsch> once copy with sse, otherwise use that mesa egl extension via the untouched buffer
[11:37:43 CEST] <BtbN> do you have two sample images? One how it's supposed to look, and one how it ends up with EGL?
[11:37:48 CEST] <fritsch> yes
[11:38:11 CEST] <fritsch> http://pasteboard.co/PaVDs5i.bmp <- VAAPI with EGL
[11:38:23 CEST] <fritsch> http://pasteboard.co/PbqgpjL.bmp <- some mediacodec whatever
[11:38:32 CEST] <fritsch> see the face of the guy in the white shirt or the grass
[11:38:56 CEST] <fritsch> vaapi with sse4 copy is fine - so it must be a step in the render which is in EGL but not in SW -> GL
[11:49:41 CEST] <fritsch> that egl path looks correct
[11:49:49 CEST] <fritsch> so it must be special part in LinuxRender
[11:49:52 CEST] <fritsch> that happens only for this format
[11:53:21 CEST] <wm4> good old bmp
[11:54:30 CEST] <wm4> fritsch: could be something related to rendering?
[11:54:36 CEST] <wm4> what exactly is the error description anyway
[11:54:59 CEST] <fritsch> just look at the grass
[11:55:04 CEST] <fritsch> error description enough :-)
[11:55:09 CEST] <fritsch> or the face of the guy
[11:56:03 CEST] <wm4> slightly more blurry, possibly different colors?
[11:56:12 CEST] <fritsch> https://github.com/xbmc/xbmc/blob/master/xbmc/cores/VideoPlayer/DVDCodecs/Video/VAAPI.cpp#L2575 wondering
[11:56:46 CEST] <wm4> is vpp even involved at all?
[11:56:51 CEST] <fritsch> no
[11:56:56 CEST] <fritsch> not in that path
[11:58:07 CEST] <fritsch> i wonder if we setup the surfaces in wrong format
[11:58:13 CEST] <fritsch> and vaapi does an additional conversion
[11:59:12 CEST] <fritsch> i linked the wrong part of the code
[11:59:33 CEST] <fritsch> https://github.com/xbmc/xbmc/blob/master/xbmc/cores/VideoPlayer/DVDCodecs/Video/VAAPI.cpp#L1255 <- that one is only happening
[12:00:23 CEST] <wm4> yeah, that's quite straight-forward
[12:00:32 CEST] <fritsch> yes
[12:01:11 CEST] <fritsch> i need to check our LinuxRenderer code, cause that's the only position something is done before outputting
[12:04:39 CEST] <fritsch> https://github.com/xbmc/xbmc/blob/master/xbmc/cores/VideoPlayer/VideoRenderers/HwDecRender/RendererVAAPI.cpp#L189
[12:49:46 CEST] <fritsch> i think the dimensions do not match and the UV values degenerate when put on the surface
[12:49:52 CEST] <fritsch> will prove it when at home
[12:51:16 CEST] <wm4> cropping issue?
[12:51:49 CEST] <wm4> I set EGL_WIDTH etc. of each plane to cropped values, and somewhat surprisingly that seems to work
[14:34:30 CEST] <Daemon404> nevcairiel, i am sad such h264 streams exist
[14:39:41 CEST] <Daemon404> how even runs fflogger btw?
[14:39:43 CEST] <Daemon404> who*
[14:42:18 CEST] <nevcairiel> Sounds like he did make clean, maybe some of the new objects are not being cleaned?
[14:42:54 CEST] <Daemon404> read his latets comment
[14:43:01 CEST] <Daemon404> he does not mention clean between builds
[14:43:04 CEST] <Daemon404> only before the first of the two
[14:43:26 CEST] <Daemon404> and object may not be rebuilt if it thinks it is targeting the same os and arch
[14:43:29 CEST] <Daemon404> which he doesnt set
[14:45:00 CEST] <wbs> Daemon404: it doesn't matter if configure thinks it's a different target; if the file itself doesn't include config.h (which not all object files do), they won't be rebuilt if configure updates config.h
[14:45:23 CEST] <nevcairiel> He does mention make clean in the second step
[14:51:43 CEST] <Daemon404> wbs, ah
[14:51:49 CEST] <Daemon404> well then that explains it
[14:52:24 CEST] <wbs> yeah, that's the telltale sign of forgetting to clean, if you get that error for some obscure table in lavc or obscure parts of lavu
[14:52:44 CEST] <Daemon404> ive hit it enough that i now only build out of tree
[14:52:47 CEST] <Daemon404> to save me pain
[14:52:55 CEST] <Daemon404> in a dir per arch
[14:53:09 CEST] <nevcairiel> Or clean lacking some entries because that's got refractories yesterday 
[14:53:17 CEST] <nevcairiel> tests*
[14:53:29 CEST] <nevcairiel> Phone keyboard no fun 
[14:53:30 CEST] <Daemon404> i doubt that caused it
[14:54:18 CEST] <Daemon404> hmm he make cleans after configure
[14:54:23 CEST] <Daemon404> i guess that should still work
[14:54:40 CEST] <Daemon404> i dont see how clean would have been affected by yesterdays tests tho
[14:56:47 CEST] <Daemon404> daemon404 at bbvm:~/dev/f/ffmpeg$ ls libavutil/*.o
[14:56:47 CEST] <Daemon404> libavutil/adler32.o
[14:56:47 CEST] <Daemon404> daemon404 at bbvm:~/dev/f/ffmpeg$ make clean
[14:56:47 CEST] <Daemon404> daemon404 at bbvm:~/dev/f/ffmpeg$ ls libavutil/*.o
[14:56:47 CEST] <Daemon404> ls: cannot access 'libavutil/*.o': No such file or directory
[14:56:49 CEST] <Daemon404> daemon404 at bbvm:~/dev/f/ffmpeg$
[14:56:52 CEST] <Daemon404> works fine here.
[15:01:05 CEST] Action: nevcairiel tests the exact commands
[15:01:17 CEST] <Daemon404> i dont have msvc installed atm
[15:13:10 CEST] <Daemon404> :)
[15:16:38 CEST] <cone-646> ffmpeg 03Anton Khirnov 07master:06edef3d5e07: Generate the lists of enabled protocols/bsfs from configure.
[15:16:39 CEST] <cone-646> ffmpeg 03Derek Buitenhuis 07master:9f8a942d6ac9: Merge commit '06edef3d5e072ef3c4face9ce946d2d9c36cc477'
[15:18:16 CEST] <cone-646> ffmpeg 03Thomas Guillem 07master:785bfb1d7bb8: pixfmt: fix wrong comment
[15:18:17 CEST] <cone-646> ffmpeg 03Derek Buitenhuis 07master:eae2ebded3b8: libxvid: Create extradata in init using a dummy frame
[15:18:18 CEST] <cone-646> ffmpeg 03Derek Buitenhuis 07master:92d934106cb2: Merge commit '785bfb1d7bb8de567c3aac1d9cc369b55ac9fb7b'
[15:18:19 CEST] <cone-646> ffmpeg 03Derek Buitenhuis 07master:f8a4b8bc4059: Merge commit 'eae2ebded3b801ed55d32746b98db88ffe196f4f'
[15:21:24 CEST] <cone-646> ffmpeg 03Luca Barbato 07master:6b2ad3ca48a6: indeo3: Avoid undefined behaviour
[15:21:25 CEST] <cone-646> ffmpeg 03Luca Barbato 07master:f3fdef108eb0: ape: Avoid undefined behaviour
[15:21:26 CEST] <cone-646> ffmpeg 03Derek Buitenhuis 07master:3fd5f09845e5: Merge commit '6b2ad3ca48a6638cb0226ed5aab41d435d8c83a5'
[15:21:27 CEST] <cone-646> ffmpeg 03Derek Buitenhuis 07master:22900770c56d: Merge commit 'f3fdef108eb06b1e71b29152bf6822519e787efe'
[15:28:38 CEST] <cone-646> ffmpeg 03Luca Barbato 07master:79fdbfdb3e50: img2enc: Refactor the atomic renaming code
[15:28:39 CEST] <cone-646> ffmpeg 03Martin Storsjö 07master:0abb07bad702: movenc: Update a comment to reflect how the code actually behaves
[15:28:40 CEST] <cone-646> ffmpeg 03Martin Storsjö 07master:74383def8f46: movenc: Handle pts == NOPTS when autoflushing
[15:28:41 CEST] <cone-646> ffmpeg 03Martin Storsjö 07master:75b90ef722b7: libavformat: Update the comment about AVOutputFormat flags
[15:28:42 CEST] <cone-646> ffmpeg 03Diego Biurrun 07master:a08b5d7b5725: build: Silence the lcov-reset target
[15:28:43 CEST] <cone-646> ffmpeg 03Derek Buitenhuis 07master:a2906846da10: Merge commit '79fdbfdb3e50f3f906903e027714ee04c1a00e89'
[15:28:44 CEST] <cone-646> ffmpeg 03Derek Buitenhuis 07master:a022c1fe76f3: Merge commit '0abb07bad7026a945a31ba4047e6583c8b3fa3da'
[15:28:45 CEST] <cone-646> ffmpeg 03Derek Buitenhuis 07master:ee96b7b1c656: Merge commit '74383def8f46805faf3391c98516b248108a9a6b'
[15:28:47 CEST] <cone-646> ffmpeg 03Derek Buitenhuis 07master:1549ca42672f: Merge commit '75b90ef722b7cdfc70118ab987e298d087aae693'
[15:28:47 CEST] <cone-646> ffmpeg 03Derek Buitenhuis 07master:d4acf9f2dd2a: Merge commit 'a08b5d7b5725932f4ad39e95c5d6589392dee2c6'
[15:29:45 CEST] <cone-646> ffmpeg 03Vittorio Giovara 07master:9e2af0e9071a: libx264: Allow Stereo3D monoscopic value
[15:29:45 CEST] <cone-646> ffmpeg 03Vittorio Giovara 07master:5fca95c8e515: libx264: Forbid inverted Stereo3D mode
[15:29:46 CEST] <cone-646> ffmpeg 03Derek Buitenhuis 07master:e3cfd1b27515: Merge commit '9e2af0e9071a1229cfe21efff394691d91f979b2'
[15:29:48 CEST] <cone-646> ffmpeg 03Derek Buitenhuis 07master:5b9a4476e312: Merge commit '5fca95c8e515a5ae542d9626ec088bdfc658450e'
[15:30:13 CEST] <Daemon404> just reached the Giant H264 Set
[15:30:14 CEST] <Daemon404> :V
[15:31:01 CEST] <Daemon404> oh goddammit 
[15:31:04 CEST] <Daemon404> https://git.libav.org/?p=libav.git;a=commit;h=4012fe1ee819edc7689e182189e66c5401fb4b41
[15:32:06 CEST] <nevcairiel> just skip that shit, its one of those cases were simply porting the solution we had was not good enough, even though it was directly shoved into their faces =p
[15:32:25 CEST] <nevcairiel> they even had to do the same mistake :)
[15:32:39 CEST] <cone-646> ffmpeg 03Luca Barbato 07master:dd4fb2339f76: ape: Unbreak adaptcoeffs computation
[15:33:01 CEST] <Daemon404> nevcairiel, too late now
[15:33:03 CEST] <Daemon404> so i picked the fix
[15:36:50 CEST] <cone-646> ffmpeg 03Anton Khirnov 07master:f3ed484953b8: h264_mp4toannexb_bsf: do not fail on annex B extradata
[15:36:52 CEST] <cone-646> ffmpeg 03Derek Buitenhuis 07master:97946b20b6d8: Merge commit 'f3ed484953b81856e40239d2410058a96188b2be'
[15:37:15 CEST] <Daemon404> nevcairiel, should i hold off on the rest until you push your other patches to h2645
[15:38:07 CEST] <nevcairiel> dont think those touch h2645
[15:38:24 CEST] <Daemon404> sure but
[15:38:34 CEST] <Daemon404> h264_parser: switch to h2645_parse for NAL unescaping
[15:39:32 CEST] <nevcairiel> all i know is that i need to update a bunch of patches in my lav fork aftrer all this shit
[15:40:31 CEST] <Daemon404> i dont think youll find much sympathy for that =p
[15:41:17 CEST] <BtbN> At least future nvenc merges should be trivial, or rather non-existent.
[15:42:12 CEST] <nevcairiel> you say that now, but syncing up once doesnt guarantee staying in sync for ever :D
[15:42:48 CEST] <BtbN> That's what we're planning though, keeping them in sync.
[15:43:18 CEST] <BtbN> We are currently merging the ffmpeg and libav one, using the libav encoder as base, because we found it to look nicer.
[15:44:06 CEST] <wm4> lol
[15:45:14 CEST] <nevcairiel> "look" nicer, but ours has like 100 more features
[15:45:27 CEST] <nevcairiel> looks are more important then, i see
[15:45:49 CEST] <BtbN> I won't accept the merge if the result is a step back for anything.
[15:45:57 CEST] <wm4> you seem quite disenchanted with Libav recently
[15:46:21 CEST] <BtbN> So no lost features, no changes in how it's invoked.
[15:47:32 CEST] <BtbN> There are numerous things on both sides that would have been needed to merge to the other.
[15:57:31 CEST] <Daemon404> nevcairiel, urg
[15:57:42 CEST] <Daemon404> merging that commit seems to break every single h264 file in fate
[15:57:46 CEST] <Daemon404> i must have screwed up...
[15:58:00 CEST] <Daemon404> oh not every single one
[15:58:02 CEST] <Daemon404> just a bunch
[15:58:03 CEST] <Daemon404> but still.
[15:58:53 CEST] <nevcairiel> did I mention that i'll be mostly out this weekend
[15:59:16 CEST] <Daemon404> lol.
[15:59:27 CEST] <Daemon404> thats fine. no merges till next week then
[15:59:28 CEST] Action: Daemon404 runs
[15:59:48 CEST] <nevcairiel> the commit looks rather simple though
[16:00:27 CEST] <Daemon404> maybe our code had some special case?
[16:05:33 CEST] <nevcairiel> ours supports mp4-style, theirs doesnt, so might need some adjustments
[16:08:02 CEST] <Daemon404> why would that affect the conformance tests in fate
[16:08:06 CEST] <Daemon404> arent they all annexb
[16:08:13 CEST] <nevcairiel> dunno
[16:08:16 CEST] <nevcairiel> maybe you broke some more
[16:08:17 CEST] <nevcairiel> :)
[16:08:35 CEST] Action: Daemon404 pawns off responsibility to nevcairiel next week and does work-work instead
[16:09:10 CEST] <nevcairiel> i can maybe look at it sunday
[16:09:28 CEST] <nevcairiel> but today is thursday, so that means cinema, and tomorrow i'm already leaving early
[16:10:11 CEST] <Daemon404> enjoy
[16:10:48 CEST] <Daemon404> and now unrelated
[16:11:01 CEST] Action: Daemon404 should really unfollow all these EBU and broadcaster people on twitter 
[16:11:21 CEST] <Daemon404> all they ever post is stuff from circlejerk conferences that pat their own backs
[16:12:17 CEST] <nevcairiel> well then do so
[16:12:20 CEST] <nevcairiel> its not like thats a lot of work
[16:12:46 CEST] <Daemon404> you underestimate my laziness
[16:15:13 CEST] <nevcairiel> if its anything like my own...
[16:19:12 CEST] <Daemon404> nevcairiel, fyi applying your patch doesnt fix anything
[16:20:16 CEST] <Daemon404> http://chromashift.org/merge.txt
[16:20:17 CEST] <Daemon404> ^ how i merged
[18:26:28 CEST] <pfelt> afternoon all.  i've got a question on commits again.  so i submitted a patch and didn't get anythign back on the -devel list.  turns out it was committed the next day and i just didn't know it.  apologies for bumping it on the list.  the question is, what's the right way to be notified of it?  only way i can think of is to watch ffmpeg-commits  (which i'll do if that's the right way)
[18:28:43 CEST] <wm4> pfelt: normally whoever applied it will reply to your mail (on the list) when it's pushed
[18:28:49 CEST] <wm4> maybe it was just forgotten this time
[18:30:59 CEST] <jkqxz> It looks like michaelni applied your patch but replied to <http://ffmpeg.org/pipermail/ffmpeg-devel/2016-May/194126.html> instead?
[18:32:32 CEST] <jkqxz> Unclear which way around that was confused, though.  (Was it actually meant to be the other patch which was applied, or was the response in the wrong thread?)
[18:37:27 CEST] <pfelt> wm4: ok :)  totally not a problem.  just wanted to make sure i was doing things the right way 
[18:38:48 CEST] <wm4> you could of course also watch the git master branch
[18:46:49 CEST] <pfelt> ok. another noob question.  i just local committed and generated a new patch for submission and i found i left DISABLE_DEPRECATION_WARNINGS in two places where those shold not be committed.  do i need to unstage and restage or can i just remove those two hunks from the patch?
[18:50:43 CEST] <wm4> the easiest way I found to "edit" commits in a fine grained unannoying way so far is using git-cola
[18:50:58 CEST] <wm4> and then just click amend and unstage the unwanted lines
[18:53:47 CEST] <pfelt> :(  ok
[18:53:49 CEST] <BtbN> undo those changes, then commit --amend, and then checkout the file from the overwritten commit(note the ID before overwriting it)
[18:54:25 CEST] <pfelt> i saved the patch out before i committed so i just branched a new local branch, re-applied the patch and i'm restaging it int he new branch
[18:55:06 CEST] <wm4> using git-cola has the advantage that you don't actually need to remove the changes or reset the commit
[18:56:54 CEST] <pfelt> i only cursorily looked at it, but it's a gui so i assumed i needed x installed. i don't currently
[18:58:19 CEST] <jkqxz> I use rebase -i / commit --amend.  Works nicely when the edits are small enough that you can make them live, but annoying once you want to make larger changes to a commit series (use stash in that case).
[19:00:57 CEST] <Shiz> ^same
[19:02:20 CEST] <pfelt> in this case it was removing two complete hunks (4 added lines in each) both in the same file
[20:54:36 CEST] <Daemon404> this guys results arent making any sense
[21:56:04 CEST] <BBB> I think his results make perfect sense
[21:57:45 CEST] <Daemon404> BBB, i was thrown off my adler32.o
[21:57:54 CEST] <Daemon404> i see it now with his latest comment
[21:58:15 CEST] <BBB> I think it complains about the first non-compat file, which happens to be adler32.o
[21:58:38 CEST] <BBB> it probably links in this order: compat/*.o (all bad arch) [rest] with adler32 being first in [res]
[21:58:44 CEST] <Daemon404> yeah exactly
[21:58:45 CEST] <BBB> and then complains that adler32 is broken
[21:58:50 CEST] <BBB> because its not the same as compat/*.o
[21:58:54 CEST] <BBB> anyway
[21:59:01 CEST] <BBB> easy for me to talk after he figured out the issue :-p
[21:59:16 CEST] <Daemon404> i only figured it out when he listed the files in the latest one
[21:59:23 CEST] <BBB> I should invent a time travel machine and show you guys how clever I am ten minutes ago
[21:59:28 CEST] <Daemon404> lul
[22:00:19 CEST] <BBB> hey kierank, are you asleep?
[22:01:16 CEST] <Daemon404> at 9pm?
[22:01:32 CEST] <BBB> you never know, he might be a leicester city fan
[22:01:55 CEST] <kierank> In the pub actually
[22:02:07 CEST] <Daemon404> are you ever not in a pub after 7pm
[22:02:40 CEST] <BBB> didnt he mention he was working an office job, effectively?
[22:02:46 CEST] <BBB> so pub at 7 is actually very reasonable
[22:02:47 CEST] <Daemon404> mind you i'd probably get a drink at the local after work if my local wasnt a 20 minute walk away
[22:02:51 CEST] <BBB> better than pub at 4:30
[22:03:08 CEST] <Daemon404> BBB, i have a lunch beer instead of a beer after work actually
[22:05:01 CEST] <kierank> BBB: yes?
[22:05:22 CEST] <BBB> do you mind a privmsg chat? or are you typing on your phone? :-p
[22:05:30 CEST] <kierank> On phone
[22:06:14 CEST] <kierank> I'll stop being antisocial
[22:06:50 CEST] <BBB> haha, well talk later then
[22:08:10 CEST] <Daemon404> actually im a hypocrite
[22:08:18 CEST] Action: Daemon404 didnt even realize he was drinking beer at this moment
[22:08:44 CEST] <BBB> I should get a beer
[22:10:48 CEST] <BBB> but I think Im having sake pairing tonight
[22:10:51 CEST] <BBB> so Ill go with that
[22:10:53 CEST] <BBB> yummy
[22:12:25 CEST] <Daemon404> http://www.beerritz.co.uk/buy/wild-beer-co-the-blend-summer-2015-75cl_2260.htm <-- my drink
[22:23:09 CEST] <fritsch> "wild beer"
[22:25:15 CEST] <wm4> fritsch: so what was that vaapi problem?
[22:25:56 CEST] <fritsch> cropping
[22:26:03 CEST] <fritsch> but need to fix it first :-)
[22:26:07 CEST] <Shiz> fritsch: better name than america
[22:26:33 CEST] <fritsch> wm4: only happens with 1920x1088 files
[22:26:52 CEST] <fritsch> we mix some Y - UV correspondences
[22:27:16 CEST] <fritsch> but evenen is nearly over, cannot even remember how I wasted that time
[22:27:39 CEST] <fritsch> Shiz: yeah - seen that ... not sure what they thought about doing that name change
[22:27:56 CEST] <fritsch> but when reading "wild beer" I always think if people know how one makes beer ...
[22:28:14 CEST] <fritsch> and there is nothing "wild" left ... when it's brewed
[22:28:24 CEST] <Shiz> artisan hand-plucked beer
[22:28:29 CEST] <Shiz> from the finest beer trees
[22:28:47 CEST] <fritsch> that's how it sounds :-)
[22:29:43 CEST] <Daemon404> fritsch, their name comes from the "wild ale" style of beer
[22:30:10 CEST] <Daemon404> i think.
[22:30:39 CEST] <fritsch> https://en.wikipedia.org/wiki/Reinheitsgebot
[22:30:48 CEST] <fritsch> ^^ my comment to such jokes
[22:30:49 CEST] <fritsch> :p
[22:30:56 CEST] <Daemon404> yes i know
[22:31:04 CEST] <Daemon404> i make fun of that law all the time
[22:31:13 CEST] <Daemon404> theres so many offensive jokes to make.
[22:31:36 CEST] <fritsch> i just found out there is a "Simple English"
[22:31:39 CEST] <fritsch> wikipedia language
[22:32:24 CEST] <fritsch> how nice of them ... https://simple.wikipedia.org/wiki/Simple_English_Wikipedia
[22:32:34 CEST] <fritsch> small sentences, simpler words and grammar
[22:32:47 CEST] <fritsch> let's see if they translated some math stuff to that language
[22:35:44 CEST] <Daemon404> https://simple.wikipedia.org/wiki/Fourier_transform
[22:35:53 CEST] <Daemon404> i dont think it is a accompishing its goal
[22:36:46 CEST] <fritsch> hehehe, in deed
[22:55:04 CEST] <Shiz> lol
[23:59:41 CEST] <pfelt> if anyone is on reviewing my updated patch to decklink, hold off.  i just learned a valuable lesson in that i see another issue that i *should* have caught before submitting another rev
[00:00:00 CEST] --- Fri May 13 2016