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

[burek]

[00:00:17 CET] <kierank> I've started extracting the VLCs
[00:00:26 CET] <kierank> there are a lot of them
[00:23:26 CET] <durandal_1707> cbsrobot_: I found some 468 meter but couldn't get it work, so I dunno is the thing coded which is posted on ml, the right thing
[00:27:21 CET] <cehoyos> durandal_1707: Either the license of the new filter is incorrect or a configure hunk is missing.
[00:32:41 CET] <durandal_1707> its rfc and wip
[01:33:30 CET] <cone-469> ffmpeg 03Anshul Maheshwari 07master:162754c1e0df: Remove Redundant Entry of MPEG2 Video Desc
[01:33:31 CET] <cone-469> ffmpeg 03Muhammad Faiz 07master:54ed3ebbe491: avfilter/showcqt: BASEFREQ and ENDFREQ cast to double
[02:13:21 CET] <kierank> durandal_170: ah figured it out
[02:36:32 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/2.5:ffe40ef9b494: Update Changelog
[02:36:33 CET] <cone-469> ffmpeg 03Andreas Cadhalpun 07release/2.5:d52b5f85f283: mjpegdec: consider chroma subsampling in size check
[02:54:08 CET] <cone-469> ffmpeg 03Muhammad Faiz 07n2.5.9:HEAD: avfilter/showcqt: BASEFREQ and ENDFREQ cast to double
[05:51:37 CET] <cone-469> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:21fbc41214b8: cmdutils: use version accessor macros
[09:23:01 CET] <rcombs> ubitux: https://ffmpeg.org/pipermail/ffmpeg-devel/2015-December/184438.html <-- I think this patch isn't quite right
[09:23:50 CET] <rcombs> should probably keep the av_rescale_q on ts_end and just add the sub->end_display_time bit
[09:23:51 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:cd1b7e2bd758: vp9: fix pixel format changes with threading
[09:51:22 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:585083dd1fc3: vp9: add hwaccel hooks
[09:51:23 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:1e6cf7272fa8: avcodec: implement vp9 dxva2 hwaccel
[09:51:24 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:5068fb1e2417: ffmpeg_dxva2: support vp9 hwaccel
[09:54:44 CET] <BtbN> nice
[10:11:38 CET] <nevcairiel> this guy is still here? calls everyone an asshole and still expects help? =p
[10:17:14 CET] <ubitux> incompetent* assholes
[10:17:27 CET] <ubitux> rcombs: yeah i didn't have a look yet
[10:17:41 CET] <ubitux> rcombs: feel free to comment, i'll have a look later today probably
[11:18:27 CET] <cone-284> ffmpeg 03Simon Thelen 07master:6596c6fca7e8: fate: add limited_input_seek tests
[11:44:46 CET] <cone-284> ffmpeg 03Clément BSsch 07master:f98abe0ee778: avutil/threadmessage: add av_thread_message_flush()
[11:44:47 CET] <cone-284> ffmpeg 03Clément BSsch 07master:a26e4215b91a: fate/api: test threadmessage
[11:44:48 CET] <cone-284> ffmpeg 03Clément BSsch 07master:bd5c860fdbc3: avutil/threadmessage: split the pthread condition in two
[11:44:57 CET] <ubitux> aaah mails are much faster :)
[11:45:47 CET] <cbsrobot_> durandal_1707: thanks a lot. I had a look but I wonder shouldn't the weighting be done in the frequency domain ?
[11:47:54 CET] <cbsrobot_> in the showcqt filter I found the [a,b,c]_weighting functions that could be reused
[11:48:11 CET] <cone-284> ffmpeg 03Paul B Mahol 07master:e6690ce02f4a: avfilter/af_biquads: pass filter ctx to av_log calls
[12:15:28 CET] <ubitux> so i just tried http://ubitux.fr/pub/pics/_vp9-support-in-firefox.png
[12:15:45 CET] <nevcairiel> that looks ... broken
[12:16:24 CET] <ubitux> really? :D
[12:16:48 CET] <nevcairiel> i dont know, maybe the original was like that!
[12:16:57 CET] <ubitux> ffmpeg -f lavfi -i testsrc -c:v vp9 -t 10 out.webm
[12:17:04 CET] <ubitux> just tried this
[12:17:16 CET] <ubitux> chromium plays it fine
[12:22:54 CET] <nevcairiel> If I were a mean person, I would say its because of firefox's binary distribution and their evil hackery to support a wide range of ffmepg versions without re-compiling =p
[12:24:01 CET] <ubitux> that was my immediate though as well
[12:29:41 CET] <cone-284> ffmpeg 03Paul B Mahol 07master:b6d029c2efea: doc/filters: add more compand examples
[12:35:06 CET] <durandal_1707> cbsrobot_: that needs fft
[13:12:28 CET] <TD-Linux> ubitux, is that file 4:4:4? that was broken in firefox for a while, but should work on nightly
[14:02:50 CET] <thilo> Can I add file-specific cflags in configure? Using check/add_cflags adds compilation of every file...
[14:04:08 CET] <nevcairiel> thats rather hard
[14:04:23 CET] <nevcairiel> but i think you can put them in the makefile directly
[14:05:51 CET] <thilo> any other files exist that are doing it this way?
[14:06:40 CET] <ubitux> TD-Linux: yep, ok
[14:07:16 CET] <nevcairiel> thilo: swscale/x86/Makefile has one of the samples, $(SUBDIR)x86/swscale_mmx.o: CFLAGS += $(NOREDZONE_FLAGS)
[14:07:54 CET] <thilo> nevcairiel: ok i will have a closer look at it, thanks!
[14:18:35 CET] <cone-284> ffmpeg 03Alexandre Lision 07master:4f979418c723: avfoundation: Simple capture
[14:18:36 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:14b583475607: Merge commit '4f979418c723652ad4e43115118c57a44bd46b52'
[14:18:51 CET] <cone-284> ffmpeg 03Luca Barbato 07master:b0e8651a2a84: doc: Amend the MSYS2 Documentation
[14:18:52 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:4e01566941b5: Merge commit 'b0e8651a2a84553d08fbb2f7cb9697bd64fb1b55'
[14:20:38 CET] <cone-284> ffmpeg 03Petri Hintukainen 07master:7139489c452e: pgssubdec: fix API compability layer
[14:20:39 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:4a2058bf4e75: Merge commit '7139489c452ef8af6a745ec4e62056ee4ea4d6a8'
[14:26:35 CET] <nevcairiel> evil ubitux broke my fate :(
[14:26:59 CET] <ubitux> ow
[14:27:11 CET] <ubitux> the test i added doesn't work for you?
[14:27:35 CET] <nevcairiel> make: *** No rule to make target 'tests/api/api-threadmessage-test.exe', needed by 'fate-api-threadmessage'
[14:28:01 CET] <ubitux> wait fuck it seems i might have messed up sth else
[14:29:41 CET] <nevcairiel> hm where do these tests hook into the fate target anyway
[14:29:46 CET] <ubitux> nevcairiel: will fix this in asec
[14:31:23 CET] <cone-284> ffmpeg 03Clément BSsch 07master:d4b1b33e698b: avutil/threadmessage: fix build without HAVE_THREADS
[14:31:47 CET] <nevcairiel> ah i see
[14:31:52 CET] <ubitux> this is the first one
[14:32:07 CET] <ubitux> nevcairiel: is this the only fate api failing for you?
[14:32:14 CET] <nevcairiel> yes
[14:32:27 CET] <nevcairiel> because its protected by HAVE_PTHREADS, and i dont have pthreads
[14:32:34 CET] <nevcairiel> should probably be HAVE_THREADS
[14:33:00 CET] <nevcairiel> on top of that, tests\fate\api.mak should use the same condition when building
[14:33:14 CET] <ubitux> ok, got it
[14:33:30 CET] <ubitux> just curious, what's the output of make fate-list|grep fate-api?
[14:34:22 CET] <nevcairiel> all of them
[14:34:45 CET] <nevcairiel> all 7
[14:35:27 CET] <ubitux> ok
[14:35:34 CET] <ubitux> give me a sec
[14:36:25 CET] <nevcairiel> can you even turn off avutil
[14:36:29 CET] <nevcairiel> that seems unlikely
[14:36:44 CET] <ubitux> probably not
[14:36:46 CET] <nevcairiel> nothing would be build without it :D
[14:37:00 CET] <ubitux> you have HAVE_PTHREADS=no?
[14:37:08 CET] <nevcairiel> yes, because i have w32threads
[14:37:33 CET] <nevcairiel> the makefile building those tests checks for that, the makefile running the tests does not
[14:38:39 CET] <ubitux> so, the test fate-api-threadmessage depends on the binary $(APITESTSDIR)/api-threadmessage-test$(EXESUF)
[14:39:03 CET] <ubitux> and this prog should be built on this condition: APITESTPROGS-$(HAVE_PTHREADS) += api-threadmessage
[14:39:17 CET] <nevcairiel> yes, so the test also needs the same condition
[14:39:26 CET] <ubitux> why?
[14:39:34 CET] <ubitux> the test depends on the binary
[14:39:36 CET] <nevcairiel> because it otherwise doesnt find its prog and fails? :)
[14:39:42 CET] <nevcairiel> like now
[14:39:45 CET] <ubitux> if the binary doesn't exist/can't be built, it should fail
[14:39:58 CET] <ubitux> i mean not meet the requirement
[14:40:00 CET] <ubitux> mmh
[14:40:02 CET] <nevcairiel> so you are saying I should not be able to run fate until i get pthreads? =p
[14:40:22 CET] <ubitux> no no
[14:40:36 CET] <ubitux> i'm saying the test should not be added if the binary can't be built
[14:40:37 CET] <nevcairiel> just change FATE_API-$(CONFIG_AVUTIL) += fate-api-threadmessage to HAVE_PTHREADS, since avutil is likely to always be there anyway
[14:42:09 CET] <ubitux> ok ok.
[14:42:52 CET] <nevcairiel> or if you really want to check for avutil, do what the other tests did
[14:42:59 CET] <nevcairiel> move it inot the name and check later
[14:43:42 CET] <cone-284> ffmpeg 03Clément BSsch 07master:b98305f0ab01: fate/api: fix fate-api-threadmessage dependency
[14:43:51 CET] <ubitux> yeah the avutil thing doesn't matter
[14:44:08 CET] <ubitux> i'm more uncomfortable about the need for having twice the same dep
[14:44:16 CET] <ubitux> it looks fishy but ok
[14:44:32 CET] <ubitux> anyway, should be fixed, sorry :)
[14:46:24 CET] <nevcairiel> for more test coverage, may want to use the thread compat headers in that test at some point
[14:47:41 CET] <ubitux> yep, would be nice
[14:48:22 CET] <ubitux> nevcairiel: i can write a patch but won't be able to test
[14:48:32 CET] <ubitux> can i ask you to do the test when i'm done?
[14:48:34 CET] <nevcairiel> can api tests use config.h and everything?
[14:48:51 CET] <ubitux> no idea :)
[14:48:59 CET] <nevcairiel> or rather not since they are supposed to test from a users point of view?
[14:49:05 CET] <ubitux> that's one of the reason i was reluctant to do the getopt thing
[14:49:22 CET] <ubitux> yeah dunno, it's half assed between examples and actual api tests
[14:49:43 CET] <nevcairiel> if you can use internal api, just need to include libavutil/thread.h and hope for the best
[14:49:50 CET] <nevcairiel> but if not thats going to be annoying
[14:49:52 CET] <ubitux> but looking at the includes, it looks like integrated properly within the ff build
[14:51:12 CET] <cone-284> ffmpeg 03Luca Barbato 07master:f7986239f4db: dvenc: Validate the frame size before copying it
[14:51:13 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:255f8966b2b5: Merge commit 'f7986239f4dbec91c743c4c5eb0a2339bd325bf6'
[14:51:29 CET] <ubitux> we probably need an include-wrapper instead of this 11 lines conditional include everytime
[14:51:54 CET] <nevcairiel> for threading? thats avutil/thread.h :)
[14:53:00 CET] <nevcairiel> but it of course needs config.h, which the api tests seem to try to avoid
[14:54:02 CET] <ubitux> nevcairiel: http://b.pkh.me/0001-fate-api-add-w32-os2-support-for-fate-api-threadmess.patch
[14:54:21 CET] <ubitux> oh
[14:54:34 CET] <ubitux> why isn't this thread.h included in other areas?
[14:54:51 CET] <nevcairiel> its from libav i think, you know how adoption of those things goes
[14:55:38 CET] <ubitux> patch updated
[14:55:42 CET] <cone-284> ffmpeg 03Luca Barbato 07master:a0fa6d06b848: matroska: Warn when metadata references a non-existent element
[14:55:43 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:0ecec7449c58: Merge commit 'a0fa6d06b848f26b16ba12f0a9a4a85b93ab8022'
[14:55:51 CET] <ubitux> does this work for you?
[14:57:08 CET] <nevcairiel> builds and passes
[14:57:23 CET] <ubitux> ok pushing then
[14:58:57 CET] <ubitux> http://b.pkh.me/0001-avcodec-avutil-remove-pointless-manual-thread-includ.patch
[14:59:00 CET] <ubitux> need to test this as well
[14:59:37 CET] <cone-284> ffmpeg 03Michael Niedermayer 07master:b74b88f30da2: g723_1: Handle values at the ends of the table in lsp2lpc()
[14:59:38 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:2730a2013daa: Merge commit 'b74b88f30da2389f333a31815d8326d5576d3331'
[15:00:07 CET] <cone-284> ffmpeg 03Clément BSsch 07master:dc97ff8380c2: fate/api: add w32+os2 support for fate-api-threadmessage
[15:00:25 CET] <nevcairiel> ubitux: that one fails
[15:00:35 CET] <ubitux> yeah didn't test yet
[15:05:21 CET] <cone-284> ffmpeg 03Vittorio Giovara 07master:aac996cc0104: g723_1: Rename files to better reflect their purpose
[15:05:22 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:9cf74191eda3: Merge commit 'aac996cc01042194bf621d845bbe684549b5882e'
[15:05:51 CET] <durandal_1707> anyone on windows willing to test maskedmerge filter?
[15:21:39 CET] <j-b> seriously, forking a header inside the repo?
[15:22:43 CET] <BtbN> That's the question.
[15:23:03 CET] <BtbN> It shouldn't be a problem now, at least license-wise.
[15:26:48 CET] <ubitux> BtbN: 3k lines though :(
[15:27:10 CET] <ubitux> i can't deny that it simplifies the build a lot
[15:27:53 CET] <BtbN> I don't realy see another way to make it non-non-free, too. Other than artificialy limiting it to the SDK 6 header.
[15:27:54 CET] <cone-284> ffmpeg 03Vittorio Giovara 07master:165cc6fb9def: g723_1: Move sharable functions to a separate file
[15:27:55 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:6c9cc21bcca9: Merge commit '165cc6fb9defcd79fd71c08167f3e8df26b058ff'
[15:29:01 CET] <j-b> it blocks any further update
[15:29:24 CET] <BtbN> What update?
[15:52:49 CET] <cone-284> ffmpeg 03Mohamed Naufal 07master:f023d57d355f: lavc: G.723.1 encoder
[15:52:50 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:90c93fb12948: Merge commit 'f023d57d355ff3b917f1aad9b03db5c293ec4244'
[15:55:24 CET] <cone-284> ffmpeg 03Mohamed Naufal 07master:ca5f386e75c5: lavf: G.723.1 muxer
[15:55:25 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:d1256272b16a: Merge commit 'ca5f386e75c592ce25b8184516fd0d580ccb31bb'
[15:56:05 CET] <cone-284> ffmpeg 03Vittorio Giovara 07master:7f57ea143c55: vsrc_color: Drop unneeded variable
[15:56:06 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:ee367fadf5c1: Merge commit '7f57ea143c55ce5732ef7e31e4b75ae6c307af13'
[16:00:31 CET] <cone-284> ffmpeg 03Luca Barbato 07master:d017ed878a45: avi: Use the correct data type
[16:00:32 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:e92aa34d7ba5: Merge commit 'd017ed878a45171f2f6c69fb9d76401c3c494110'
[16:01:02 CET] <cone-284> ffmpeg 03Michael Niedermayer 07master:0fc61c6ab691: avi: Validate the stream-id for DV as well
[16:01:03 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:8cfa7beffc5c: Merge commit '0fc61c6ab6912a2f0c40fdd3f3c591bc2a33efd4'
[16:01:53 CET] <cone-284> ffmpeg 03Luca Barbato 07master:cb49bb10ca7f: build: Move -Wcast-qual to the extra_warnings
[16:01:54 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:357c62657a3d: Merge commit 'cb49bb10ca7fcff2e382d9d989232b1a7f28e7da'
[16:11:40 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:312c83e05711: avcodec/g723_1: fix license header
[16:42:34 CET] <cone-284> ffmpeg 03Clément BSsch 07master:5e0c47d41c1d: avutil/threadmessage: fix build without HAVE_THREADS, new attempt
[16:56:47 CET] <mateo`> hello o/, is there any documentation regarding how libavfilter works internally ? init/negotiation/possible re-negotiation/deinit ?
[16:58:20 CET] <Daemon404> there is some txt file ubitux wrote
[16:58:27 CET] <Daemon404> i think its udner doc/
[16:59:06 CET] <ubitux> doc/writing_filters.txt doesn't really talks about the negotiation though
[16:59:13 CET] <Daemon404> ok
[16:59:22 CET] <mateo`> filter_design.txt seems good
[16:59:24 CET] <ubitux> doc/filter_design.txt from Nicolas might
[16:59:30 CET] <ubitux> but i'm not sure how up to date it is
[16:59:41 CET] <ubitux> i think it's actually pretty outdated
[16:59:45 CET] <mateo`> it's better than nothing
[17:00:40 CET] <mateo`> i'm looking at bringing back buffer pools to avfilter
[17:01:57 CET] <mateo`> but first, I need to figure out how the negotiation is happening
[17:02:25 CET] <ubitux> > foo86 <foobaz86 at gmail.com>
[17:02:28 CET] <ubitux> a new mission for j-b 
[17:03:01 CET] <ubitux> heh, actually some commits from him are already in the history
[17:03:10 CET] <JEEB> :D
[17:13:06 CET] <cone-284> ffmpeg 03James Almer 07master:a0050d9bf9b6: configure: fix vp9_d3d11va_hwaccel deps
[17:14:05 CET] <durandal_1707> mateo`: buffer pools, why?
[17:14:20 CET] <nevcairiel> did that ever break in reality anywhere? DXVA_PicParams_VP9 is even rarer than d3d11va headers =p
[17:15:06 CET] <mateo`> durandal_1707: because frames are being allocated / deallocated every time
[17:15:41 CET] <durandal_1707> no, they are not
[17:16:15 CET] <ubitux> if you do a simple vf scale they are
[17:16:20 CET] <mateo`> looking at libavfilter/video.c, they are
[17:19:39 CET] <mateo`> a buffer pool uses to be there (39f66edbeae5ccabefe38b2fcb25d6c242d868c0) but it has been removed with the api redesign
[17:22:27 CET] <ubitux> on a side note, the huge writing performance hit we get with the nv2rgb neon convert in sws is because of this 
[17:24:31 CET] <nevcairiel> ..its slower because the buffer is "new"?
[17:24:37 CET] <nevcairiel> how does that make sense
[17:24:48 CET] <durandal_1707> what are numbers?
[17:25:49 CET] <ubitux> nevcairiel: yes; not in cache maybe
[17:25:59 CET] <ubitux> nevcairiel: more than half of the time is spent in the writing itself
[17:26:21 CET] <ubitux> this is easily reproducible by doing a memcpy on a new buffer vs the same buffer
[17:26:22 CET] <nevcairiel> frames are too large to be cached anyway
[17:26:29 CET] <ubitux> you get something like 21ms vs 5ms
[17:26:40 CET] <nevcairiel> arm is just weird
[17:36:17 CET] <mateo`> this is what it looks like on a beagle board black: http://pastie.org/10616395
[17:37:07 CET] <nevcairiel> clearly that is invalid because you actually alloc within the loop and measure that as well
[17:37:25 CET] <nevcairiel> oh wait, i mixed up lines
[17:38:01 CET] <nevcairiel> did you try clearing the memory before reading it, maybe it just doesnt like uninit memory
[17:39:01 CET] <nevcairiel> and your test is sligthly wrong, it says "new only dest", but its actually the source thats being created all the time
[17:42:27 CET] <mateo`> nevcairiel: yeah, i've put this "label" in a hurry
[17:45:15 CET] <cone-284> ffmpeg 03Clément BSsch 07master:a8bb81a05c51: lavc, lavu: use avutil/thread.h instead of redundant conditional includes
[19:40:18 CET] <Timothy_Gu> why is carl so interested in the version generation?
[19:44:03 CET] <cone-284> ffmpeg 03Timothy Gu 07master:006d3e97fc8f: cosmetics: Fix weird indentations
[20:08:01 CET] <llogan> Timothy_Gu: so he can bisect. (not particularly that ticket)
[20:08:26 CET] <llogan> i believe that weird version number is a result of using a shallow repo, but i didn't test
[20:10:30 CET] <llogan> or i should say using a shallow repo may also cause that
[20:14:29 CET] <Daemon404> unrelated to the bug at hand
[20:26:05 CET] <RiCON> ubitux: it seems you took one #if too many or forgot to remove #endif in http://git.videolan.org/?p=ffmpeg.git;a=commit;h=a8bb81a05c519dd3f36cc341e5fb448f6d17fa73
[20:26:12 CET] <RiCON> in libavutil/opencl.c
[20:26:45 CET] <nevcairiel> oh yeah the HAVE_THREADS probably should've remained
[20:27:05 CET] <ubitux> fixing in a second..
[20:28:34 CET] <RiCON> same in libavutil/threadmessage.c probably
[20:28:55 CET] <RiCON> or not, the two #endifs were removed too
[20:29:12 CET] <cone-284> ffmpeg 03Clément BSsch 07master:dd1d9b80c99e: lavu/opencl: restore #if HAVE_THREADS
[21:39:50 CET] <wm4> does anyone know what standard specifies RGB-in-h264 with bit depth greater than 8?
[21:40:17 CET] <wm4> because I have no idea how this is supposed to be mapped to a normalized range
[21:40:42 CET] <nevcairiel> ?
[21:40:47 CET] <fritsch> what is a normalized range in that regard?
[21:40:52 CET] <nevcairiel> increased bitdepth just moves the points accordingly
[21:41:22 CET] <wm4> what are the minimum and maximum values in N bit RGB? the 16 bit case confuses me, but maybe I'm just too stupid
[21:41:29 CET] <ubitux> rcombs: what happened to the ass fixes?
[21:41:41 CET] <ubitux> rcombs: not only your recent ones but also the parser bugs etc
[21:41:45 CET] <fritsch> wm4: 2^N -1?
[21:41:53 CET] <fritsch> again depending on limited or not?
[21:42:04 CET] <fritsch> not sure if that exists in rgb 888
[21:42:45 CET] <nevcairiel> you can just take the 8-bit scale and multiply it accordingly
[21:43:03 CET] <nevcairiel> for limited, 16-235 * 4 -> 64-940 for 10-bit
[21:43:17 CET] <wm4> I mean for ycbcr, the ranges are apparently 16*2^(N-8) and 235*2^(N-8)
[21:43:31 CET] <nevcairiel> yeah
[21:43:48 CET] <nevcairiel> *4
[21:43:48 CET] <wm4> would that imply that for RGB the range is 2^(N-8) and 255*2^(N-8)?
[21:43:51 CET] <nevcairiel> woops
[21:44:14 CET] <nevcairiel> full rgb always starts at 0
[21:44:27 CET] <nevcairiel> so simplified, 0 to 2^N - 1
[21:44:37 CET] <wm4> right, even for 8 bit
[21:45:06 CET] <wm4> ok, I guess the strict requirement for shifting in the yuv case just confused me, and there's no such thing for RGB?
[21:45:18 CET] <nevcairiel> some people handle limited range rgb
[21:45:22 CET] <nevcairiel> but its just a weird format
[21:45:24 CET] <wm4> (somehow I thought these would be handled the same way, apart from the color matrix)
[23:39:24 CET] <kierank> wm4: some people do this weird shifting thing for rgb
[23:39:26 CET] <kierank> swscale for example
[23:40:13 CET] <wm4> uh and what about 16 bit? or do they treat packed 16 bit and planar 16 bit differently?
[23:40:29 CET] <wm4> (there are 10 bit RGB formats in the sane world too, but I don't think swscale supports them)
[23:49:00 CET] <kierank> people shift from 8 to 16-bit with (foo << 8) | foo & 0xff;
[23:49:02 CET] <kierank> maintains full range
[23:49:25 CET] <wm4> yes but you don't do this with yuv
[23:49:41 CET] <kierank> correct
[23:50:43 CET] <wm4> so shifting for 10 bit gbrp (instead of just using the full 10 bit range) is inconsistent?
[23:52:20 CET] <kierank> depends if you are a full-range tard I guess
[23:52:44 CET] <kierank> as a limited range tard I would shift
[23:52:49 CET] <nevcairiel> the reason for that isnt too bad, wanting 255 become 1023
[23:52:53 CET] <nevcairiel> while limited range works out well
[23:53:04 CET] <nevcairiel> 235 << 2 == 940, perfect
[23:53:11 CET] <wm4> I don't care (who the fuck uses planar 10 bit RGB), I just like concistency and also a bit of correctness
[23:53:45 CET] <Daemon404> vapoursynth!
[23:53:47 CET] Action: Daemon404 runs
[23:53:57 CET] <nevcairiel> Daemon404: its vapourware
[23:54:11 CET] <Daemon404> no?
[23:54:12 CET] <wm4> vapoursynth is very much released
[23:54:36 CET] <nevcairiel> noone likes my bad puns :(
[23:54:41 CET] <Daemon404> :P
[23:54:57 CET] <wm4> to be fair, it remained true to its name for quite a while
[00:00:00 CET] --- Tue Dec  8 2015