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

[burek]

[01:36:13 CEST] <cone-892> ffmpeg 03James Almer 07master:b62a87591ebe: doc/libav-merge: link to the relevant ml thread in the extract_extradata line
[01:50:38 CEST] <cone-892> ffmpeg 03James Almer 07master:6171f178e70e: x86/hevc_add_res: merge last remaining changes from 3d6535983282bea542dac2e568ae50da5796be34
[04:56:26 CEST] <cone-019> ffmpeg 03Steven Liu 07master:99e5d81ef997: avutil/avstring: add av_strreplace API into avstring
[10:03:48 CEST] <ubitux> what's the politic wrt parser code return in case of error?
[10:04:02 CEST] <ubitux> in what situation do we prefer to consume the whole packet vs consume nothing?
[10:08:09 CEST] <nevcairiel> we cant indicate errors from parsers, can we? if we consume nothing, could this result in an infinite loop?
[10:11:41 CEST] <ubitux> maybe
[10:11:51 CEST] <ubitux> but yeah we can't raise errors
[10:12:06 CEST] <ubitux> but if i look at the vp9 parser for instance
[10:12:21 CEST] <ubitux> in one case we return 0 and in other the full size
[10:12:30 CEST] <ubitux> i guess that return 0 case is pretty special
[10:12:39 CEST] <ubitux> because we don't actually have anything better to return
[10:13:12 CEST] <ubitux> i guess i'll return buf_size everywhere
[10:13:29 CEST] <ubitux> jkqxz: opinion on this? (related to 182cf170a544bce069c8690c90b49381150a1f10)
[10:13:40 CEST] <ubitux> the parser is not supposed to raise error code
[10:13:49 CEST] <ubitux> TBH, we should allow this
[10:13:51 CEST] <ubitux> print the error
[10:13:57 CEST] <ubitux> and consume the whole packet
[10:14:04 CEST] <nevcairiel> the parser API is up for a redesign
[10:14:37 CEST] <ubitux> ah actually you could return a negative index in the parser
[10:14:45 CEST] <nevcairiel> but yeah just consume the entire packet
[10:17:50 CEST] <ubitux> alright
[10:19:39 CEST] <cone-163> ffmpeg 03Mark Thompson 07master:182cf170a544: vp8: Return stream format information from parser
[10:19:39 CEST] <cone-163> ffmpeg 03Clément BSsch 07master:f56a5fee374c: Merge commit '182cf170a544bce069c8690c90b49381150a1f10'
[10:25:54 CEST] <ubitux> arg, we need the vp8 commits from jkqxz now
[10:25:56 CEST] <ubitux> :(
[10:27:20 CEST] <ubitux> maybe we can do without though
[10:46:48 CEST] <jkqxz> Um, right.  Sounds like someone wrote a parser without understanding what they were doing.
[10:48:36 CEST] <stevenliu> Hi Nicolas George,I'm interesting use AVBPrint
[10:48:57 CEST] <stevenliu> But is saw it need fill buf and size into the struct
[10:49:04 CEST] <nevcairiel> he isnt here
[10:59:33 CEST] <jkqxz> I'd be inclined to just skip vp8_qsv if there is any difficulty - it got added because it happened to just work with little effort for simple cases when I tried.
[11:00:20 CEST] <jkqxz> It has weird issues like the hardware surface output not working on Linux (seems to be an Intel bug, but confuses here).
[11:06:42 CEST] <cone-163> ffmpeg 03Carl Eugen Hoyos 07master:fa0a6ce34d00: configure: Fix GPL dependency for avisynth / avxsynth.
[11:06:49 CEST] <ubitux> jkqxz: my main problem is again that i can't test it, and i don't really know how it interact with what was previously commited in the vp8 hwaccel batch
[11:07:02 CEST] <ubitux> maybe it's completely decorelated but dunno
[11:07:08 CEST] <ubitux> you're the author so& :P
[11:07:25 CEST] <jkqxz> It's completely unrelated.
[11:08:08 CEST] <ubitux> so it doesn't involve vp8 hwaccel hooks?
[11:08:17 CEST] <jkqxz> No.
[11:08:24 CEST] <ubitux> it's a standalone decoder?
[11:08:26 CEST] <ubitux> ok
[11:08:31 CEST] <jkqxz> It's not a hwaccel, just another way into the standalone qsv decoder.
[11:08:42 CEST] <BtbN> qsv works like cuvid I guess
[11:08:53 CEST] <BtbN> it has its own parser and everything
[11:09:36 CEST] <jkqxz> Which sucks, so we use the lavc parsers instead.
[11:12:47 CEST] <ubitux> jkqxz: ok so i'll blind it
[11:12:56 CEST] <ubitux> jkqxz: btw, you may want to fix your return code in libav
[11:13:15 CEST] <ubitux> (of the vp8 parser)
[11:13:34 CEST] <jkqxz> Sure.
[11:23:04 CEST] <cone-163> ffmpeg 03Mark Thompson 07master:e0b164576f74: qsv: Add VP8 decoder
[11:23:05 CEST] <cone-163> ffmpeg 03Clément BSsch 07master:e06b8b07d599: Merge commit 'e0b164576f7467b7b1127c18175e215dc1df011f'
[11:30:30 CEST] <cone-163> ffmpeg 03Diego Biurrun 07master:fbd1f7639d01: af_asyncts: Use llabs instead of labs for 64-bit variable
[11:30:31 CEST] <cone-163> ffmpeg 03Diego Biurrun 07master:f7407f56cbf8: golomb: Replace __PRETTY_FUNCTION__ with __func__ for tracing
[11:30:32 CEST] <cone-163> ffmpeg 03Diego Biurrun 07master:ffe89e1edb02: configure: Move mjpeg_vaapi_decoder dependency declarations to the right place
[11:30:33 CEST] <cone-163> ffmpeg 03Clément BSsch 07master:6516c62ec0e4: Merge commit 'fbd1f7639d0142c391bec85d1d840c835210843f'
[11:30:34 CEST] <cone-163> ffmpeg 03Clément BSsch 07master:52e6fb9c597f: Merge commit 'f7407f56cbf820a147bd77d728ac9a72c587cc56'
[11:30:35 CEST] <cone-163> ffmpeg 03Clément BSsch 07master:ab04d9bf6383: Merge commit 'ffe89e1edb0281ff65d1bda88253784e9283b717'
[11:32:32 CEST] <cone-163> ffmpeg 03Gianluigi Tiesi 07master:e17567a831de: libilbc: support for latest git of libilbc
[11:32:33 CEST] <cone-163> ffmpeg 03Clément BSsch 07master:c1476219cad0: Merge commit 'e17567a831dede1f24e3a1a4c305a93012d7a8ce'
[11:34:23 CEST] <cone-163> ffmpeg 03Janne Grunau 07master:d7595de0b25e: aarch64: vp9: use alternative returns in the core loop filter function
[11:34:24 CEST] <cone-163> ffmpeg 03Clément BSsch 07master:33b80adaab0f: Merge commit 'd7595de0b25e7064fd9e06dea5d0425536cef6dc'
[11:37:36 CEST] <cone-163> ffmpeg 03Janne Grunau 07master:e7ae8f7a7158: aarch64: vp9: loop filter: replace 'orr; cbn?z' with 'adds; b.{eq,ne};
[11:37:37 CEST] <cone-163> ffmpeg 03Clément BSsch 07master:cdcdb7d32dd2: Merge commit 'e7ae8f7a715843a5089d18e033afb3ee19ab3057'
[11:54:58 CEST] <cone-163> ffmpeg 03Martin Storsjö 07master:81d7f0bbca83: checkasm: vp9dsp: Benchmark the dc-only version of idct_idct separately
[11:54:59 CEST] <cone-163> ffmpeg 03Clément BSsch 07master:edfa7ac8ec4a: Merge commit '81d7f0bbca837afda1f7e60d3ae52ab1360ab44b'
[12:00:08 CEST] <cone-163> ffmpeg 03Vittorio Giovara 07master:d5d62ce6d643: mov: Fix identity matrix boolean logic
[12:00:09 CEST] <cone-163> ffmpeg 03Clément BSsch 07master:1ef8da77a5ab: Merge commit 'd5d62ce6d643de704e7bd62a2375e6391c0ffb9a'
[12:08:40 CEST] <cone-163> ffmpeg 03Vittorio Giovara 07master:481ff3cf0188: fate: Add h264 and hevc extradata reload tests
[12:08:41 CEST] <cone-163> ffmpeg 03Clément BSsch 07master:e83a1c5b7ce0: Merge commit '481ff3cf018811ba3235f1c236e970f32a6300b9'
[12:10:03 CEST] <cone-163> ffmpeg 03Marton Balint 07master:bcefafa226dc: avisynth: Fix setting stream timebase
[12:10:04 CEST] <cone-163> ffmpeg 03Clément BSsch 07master:fb1a2cbae10a: Merge commit 'bcefafa226dcda23d4d9af9601d19389cb918a5b'
[12:12:10 CEST] <cone-163> ffmpeg 03Stephen Hutchinson 07master:aaae59700f7f: avisynth: Simplify the pix_fmt check for the newer AviSynth API
[12:12:11 CEST] <cone-163> ffmpeg 03Clément BSsch 07master:2738b4cee01c: Merge commit 'aaae59700f7fc10fd80cb93b38c5d109900872d9'
[12:17:07 CEST] <cone-163> ffmpeg 03Stephen Hutchinson 07master:3cc3463f306f: avisynth: Support pix_fmts added to AviSynth+
[12:17:08 CEST] <cone-163> ffmpeg 03Clément BSsch 07master:f047da4ebe41: Merge commit '3cc3463f306f425f76bd962755df1132eeac6dfa'
[12:18:49 CEST] <ubitux> what is this bf8646274b3ea2d9a193edfdbd70a3bb5c6dd74f about?
[12:19:04 CEST] <ubitux> is it true for ffmpeg as well?
[12:19:07 CEST] <PaoloP> Any review for the API usage example I posted? http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209494.html   I modified it according to what ubitux and michaelni told me and added more comments on the top of the code, which explain better how the snippet can be useful (In response to wm4 's observations about custom I/O)
[12:29:27 CEST] <durandal_1707> ubitux: i would say: yes
[12:33:30 CEST] <ubitux> ok
[12:42:45 CEST] <cone-163> ffmpeg 03Stephen Hutchinson 07master:bf8646274b3e: doc: Add note about recent regression in AviSynth+
[12:42:46 CEST] <cone-163> ffmpeg 03Clément BSsch 07master:2b1a6b1ae31a: Merge commit 'bf8646274b3ea2d9a193edfdbd70a3bb5c6dd74f'
[12:43:42 CEST] <cone-163> ffmpeg 03Diego Biurrun 07master:bfe92dfe60f6: Ignore all generated example binaries
[12:43:43 CEST] <cone-163> ffmpeg 03Clément BSsch 07master:147c5ff11ce8: Merge commit 'bfe92dfe60f601b3f20a918ffcc0acdf40a5955c'
[12:45:50 CEST] <cone-163> ffmpeg 03Clément BSsch 07master:e181e2909b21: doc/examples/transcode_aac: replace local get_error_text with av_err2str
[12:46:35 CEST] <cone-163> ffmpeg 03Diego Biurrun 07master:bb265b764a05: examples/transcode_aac: Drop pointless return value const qualifier
[12:46:36 CEST] <cone-163> ffmpeg 03Clément BSsch 07master:6200bf89a807: Merge commit 'bb265b764a055f2dc576b9aec62460d9580868f4'
[12:46:51 CEST] <ubitux> afk for a while, anyone can take over the merge
[12:47:01 CEST] <ubitux> (ETA: 601)
[12:51:25 CEST] <cone-163> ffmpeg 03Takayuki 'January June' Suwa 07master:e3d8963c3cb5: avcodec/dsddec: correct for DSD silence bit-ordering
[13:07:52 CEST] <durandal_1707> im happy with dnxhr patch, anyone tried it yet?
[15:14:57 CEST] <cone-163> ffmpeg 03Diego Biurrun 07master:715b82434608: qsv: Drop some unused variables
[15:14:58 CEST] <cone-163> ffmpeg 03Clément BSsch 07master:a032c5224d40: Merge commit '715b8243460836fb7dd15bf7e41668e773beb276'
[15:15:49 CEST] <cone-163> ffmpeg 03Diego Biurrun 07master:76167140a91c: qsvdec: Drop stray extra braces around initializer
[15:15:50 CEST] <cone-163> ffmpeg 03Clément BSsch 07master:c7173e50980c: Merge commit '76167140a91c081a0cf9d0abcaa4da18d1bacadb'
[15:19:24 CEST] <ubitux> what's up with kodi.tv?
[15:19:27 CEST] <ubitux> bad 1st april?
[15:19:45 CEST] <wm4> yes
[15:20:17 CEST] <wm4> mpv's was unfortunately accidentally deleted https://0x0.st/aw8.mov
[15:22:05 CEST] <JEEB> huh, you find FFmpeg patches in the weirdest places http://forum.samygo.tv/viewtopic.php?f=75&t=11679
[15:25:01 CEST] <ubitux> probably quality code
[15:25:41 CEST] <JEEB> also I like how the patch is unavailable to guests
[15:26:00 CEST] <wm4> that's "standard" in forum software
[15:26:10 CEST] <JEEB> yeh
[15:47:25 CEST] <cone-163> ffmpeg 03Christian Suloway 07master:d860a3cc0a12: crypto: Add encryption support
[15:47:26 CEST] <cone-163> ffmpeg 03Clément BSsch 07master:e66563aedeec: Merge commit 'd860a3cc0a12360a92b9ffd179a0c34413beaf88'
[16:32:58 CEST] <kkanungo17> the psychoacoustic system would have to be implemented in vorbis.c or vorbisenc.c?
[16:33:37 CEST] <atomnuker> vorbisenc.c
[16:38:14 CEST] <cone-163> ffmpeg 03Mark Thompson 07master:75afad774b2b: vf_deinterlace_vaapi: Mark as hwframe-aware
[16:38:57 CEST] <jkqxz> ^ unusable after the second merge without that (always hit an assert).
[17:19:29 CEST] <durandal_1707> utvideo guy added gradient prediction
[17:40:26 CEST] <ubitux> the next commit sounds like a pita to merge
[17:41:49 CEST] <nevcairiel> we already have hlsenc encryption support, so skip it?
[17:42:51 CEST] <nevcairiel> can always ask the hlsenc maintainer if he wants to add support for their avoption syntax
[17:42:56 CEST] <ubitux> yes, that commit seems based on 907ac20aa29341e49a4f89ff3d4240d92f9a0cb9
[17:43:03 CEST] <ubitux> but we don't have these options
[17:43:22 CEST] <ubitux> and it's using gcrypt/openssl for some reason
[17:43:29 CEST] <ubitux> which we don't use
[17:44:14 CEST] <ubitux> they use it for key random generation
[17:45:11 CEST] <ubitux> option is also not documented in our side
[17:45:30 CEST] <ubitux> ah my bad it actually is
[17:46:14 CEST] <ubitux> so you're saying i should skip that one anyway?
[17:46:33 CEST] <nevcairiel> if you want to somehow merge it to provide the avoptions, go ahead
[17:46:56 CEST] <nevcairiel> personally I would skip it and inform the hlsenc maintainer,  maybe he wants to add those options
[17:47:03 CEST] <ubitux> i'm honestly not interested at all with hls itself
[17:47:05 CEST] <ubitux> ok
[17:50:24 CEST] <durandal_1707> dnxhr hqx patch is working and i gonna apply it soon
[17:51:20 CEST] <durandal_1707> also gonna apply another exr patch, anybody against?
[17:52:02 CEST] <atomnuker> I looked at the dnxhr patch, it looks good
[17:52:10 CEST] <ubitux> nevcairiel: "The email address you entered couldn't be found."
[17:52:30 CEST] <ubitux> 2nd time it happens when i try to contact a developer
[17:52:32 CEST] <nevcairiel> so no hlsenc maintainer? :D
[17:52:32 CEST] <ubitux> :(
[17:52:50 CEST] <nevcairiel> that guy was on irc just yesterday
[17:53:07 CEST] <nevcairiel> wait, it was today
[17:53:55 CEST] <nevcairiel> the ML has two emails for him, some @chinaffmpeg thing and one gmail
[17:54:19 CEST] <ubitux> ah?
[17:54:37 CEST] <ubitux> what nickname was he using here?
[17:54:42 CEST] <nevcairiel> stevenliu
[17:54:48 CEST] <ubitux> huh
[17:54:55 CEST] <ubitux> Christian Suloway is Steven Liu?
[17:55:11 CEST] <nevcairiel> no
[17:55:19 CEST] <nevcairiel> but steven liu is the guy doing all the hls changes
[17:55:28 CEST] <ubitux> except that one (http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=907ac20aa29341e49a4f89ff3d4240d92f9a0cb9)
[17:55:42 CEST] <nevcairiel> i know, but that doesnt make him the maintainer exactly
[17:55:48 CEST] <ubitux> right
[17:55:59 CEST] <ubitux> well then, i'll poke the maintainer
[17:56:10 CEST] <nevcairiel> the entire domain of that suloway guy vanished
[17:56:16 CEST] <ubitux> yep
[18:07:58 CEST] <cone-163> ffmpeg 03Dzung Hoang 07master:68e3c9a3b680: avcodec/exr: add support for scanline file where offsets are set to zero
[18:20:53 CEST] <cone-163> ffmpeg 03Luca Barbato 07master:0a4b9d0ccd10: hlsenc: Add encryption support
[18:20:54 CEST] <cone-163> ffmpeg 03Clément BSsch 07master:edc43c571d66: Merge commit '0a4b9d0ccd10b3c39105f99bd320f696f69a75a2'
[18:21:53 CEST] <cone-163> ffmpeg 03Clément BSsch 07master:a3fc5f535adc: doc/libav-merge: document hlsenc encryption state
[18:25:37 CEST] <cone-163> ffmpeg 03Luca Barbato 07master:adb0e941c329: avpacket: Mark src pointer as constant
[18:25:38 CEST] <cone-163> ffmpeg 03Clément BSsch 07master:507a85b93c93: Merge commit 'adb0e941c329a4778ade6dd0a326274472992f54'
[18:26:27 CEST] <ubitux> nevcairiel: do you mind merging the next 4 dxva2 commits?
[18:26:33 CEST] <ubitux> then we reach the bitstream one.
[18:31:47 CEST] <wm4> did we decide yet what to do with the bitstream ones
[18:42:44 CEST] <durandal_1707> just merge api but not funcionality
[18:43:35 CEST] <jamrial> ubitux: what's your opinion about my suggestion wrt the 3.3 release?
[18:45:10 CEST] <wm4> if 3.3 is based on an old commit, I'll just make the next mpv release not build with any ffmpeg release
[18:46:06 CEST] <jamrial> the options are making the release after branching out from a pre merge rush point + backports (what michaelni suggested), branch right before the bitstream reader batch (four commit merges away), or wait until we reach the last commit before the major bump
[18:47:13 CEST] <cone-163> ffmpeg 03Paul B Mahol 07master:f078bc4c5e66: avcodec/dnxhdenc: DNxHR 444 and HQX support
[18:51:17 CEST] <nevcairiel> ubitux: sure
[18:51:52 CEST] <jamrial> waiting until the major bump could be only a few weeks away. the bitstream reader batch is huge (more than 50 commits) and there's also the post bump batch (30 or so commits), so the backlog is not as bad as it looks
[18:52:37 CEST] <cone-163> ffmpeg 03Paul B Mahol 07master:358d4524cc8f: avcodec/dnxhdenc: fix indentation issue
[18:53:19 CEST] <ubitux> jamrial: your suggestion to make a release from now? (that is, just pre-bitstream)
[18:53:47 CEST] <ubitux> might be ok, but dunno
[18:54:22 CEST] <ubitux> nevcairiel: thanks :)
[18:54:34 CEST] <ubitux> durandal_1707: about nlmeans, i have no plan to work on it anytime soon
[18:54:52 CEST] <ubitux> if you want to make it faster, you can try to simd the integral function (the code is ready)
[18:55:06 CEST] <ubitux> but it's said not to have much influence on the performanc
[18:55:11 CEST] <durandal_1707> :(
[18:55:27 CEST] <ubitux> you should try though
[18:55:34 CEST] <ubitux> the asm is not much code to write afaict
[18:55:52 CEST] <ubitux> see compute_safe_ssd_integral_image_c
[18:56:12 CEST] <ubitux> you can should do that in a 2-pass mode in simd though
[18:56:29 CEST] <ubitux> but really, it's not much code
[18:58:12 CEST] <durandal_1707> users say that it is too aggressive
[18:58:57 CEST] <cone-163> ffmpeg 03Anton Khirnov 07master:0d3176e32f35: hwcontext_dxva2: do not assume the destination format during mapping is always the right one
[18:58:58 CEST] <cone-163> ffmpeg 03Anton Khirnov 07master:9d7026574bbb: hwcontext_dxva2: fix handling of the mapping flags
[18:58:59 CEST] <cone-163> ffmpeg 03Anton Khirnov 07master:5a1d605ceae4: hwcontext_dxva2: split transfer_data() into upload/download functions
[18:59:00 CEST] <cone-163> ffmpeg 03Anton Khirnov 07master:e18ba2dfd2d1: hwcontext_dxva2: make sure the sw frame format is the right one during transfer
[18:59:01 CEST] <cone-163> ffmpeg 03Hendrik Leppkes 07master:d91e7aac122f: Merge commit '0d3176e32f351d18d6174d8b05796829a75a4c6b'
[18:59:02 CEST] <cone-163> ffmpeg 03Hendrik Leppkes 07master:fbfa72916c89: Merge commit '9d7026574bbbe67d004a1c32911da75375692967'
[18:59:03 CEST] <cone-163> ffmpeg 03Hendrik Leppkes 07master:0f9ce9c5fcdb: Merge commit '5a1d605ceae448b476a525f7368ec452000d1f26'
[18:59:04 CEST] <cone-163> ffmpeg 03Hendrik Leppkes 07master:5c612c5ff8c4: Merge commit 'e18ba2dfd2d19aedc8afccf011d5fd0833352423'
[18:59:09 CEST] <ubitux> nevcairiel: thanks :)
[18:59:17 CEST] <nevcairiel> all pretty straight forward
[18:59:20 CEST] <jamrial> ubitux: it's a good stopping point, and probably better than using a three weeks old point
[18:59:31 CEST] <jamrial> so we're here, time to choose :p
[18:59:32 CEST] <ubitux> jamrial: sure
[18:59:48 CEST] <ubitux> i don't really mind, but still uncomfortable
[18:59:59 CEST] <nevcairiel> hwcontext_dxva2 is now up to date to the libav git master version, minus one cosmetic difference (which is wrong in their tree, so i didnt feel like making ours uglier), and our safe dlopen wrappers
[19:00:00 CEST] <ubitux> durandal_1707: ah, that; yeah well, you may want to have chroma settings typically
[19:00:13 CEST] <ubitux> cool
[19:00:27 CEST] <ubitux> durandal_1707: anyway, patches welcome
[19:01:38 CEST] <ubitux> alright, so who wants to work on the bitstream thingy?
[19:02:18 CEST] <jamrial> we're merging it then instead of nooping it?
[19:02:48 CEST] <nevcairiel> ignoring them all would cause severe differences, not sure thats a good plan for the long-run
[19:02:58 CEST] <jamrial> true i guess
[19:03:02 CEST] <ubitux> yeah
[19:03:11 CEST] <nevcairiel> so at least we need the API
[19:03:13 CEST] <ubitux> so we want to write a wrapper around get_bits instead?
[19:03:15 CEST] <jamrial> i can help, it should be a search and replace, assuming the api is the same
[19:03:20 CEST] <nevcairiel> what do to about the implementaiton is a different topic
[19:03:39 CEST] <ubitux> jamrial: it's not exactly the same
[19:03:48 CEST] <nevcairiel> its not a 1:1 replacement since the new one can read up to 63 bits iirc
[19:03:55 CEST] <nevcairiel> and our old optimized one only reads 23 bits
[19:04:01 CEST] <nevcairiel> unless you use the long form, which is slower
[19:04:11 CEST] <jamrial> ah right, the bitstream reader long macro thing to get 32 bits
[19:05:16 CEST] <atomnuker> nevcairiel: the differences would be minimal, they don't touch codecs often or at all
[19:07:15 CEST] <iive> if they don't touch codecs often, then we may get away with not merging it
[19:07:24 CEST] <ubitux> no
[19:08:29 CEST] <ubitux> there are a lot of differences in usage, we want to match the api
[19:08:46 CEST] <iive> do we?
[19:09:57 CEST] <ubitux> yes, otherwise next merges will be a nightmare
[19:09:58 CEST] <jamrial> for the sake of making merges simple, yes
[19:10:15 CEST] <iive> i haven't checked their final version
[19:10:32 CEST] <iive> but their proposal had really ugly API
[19:10:53 CEST] <iive> and somebody here notes their writing and reading API is different.
[19:11:22 CEST] <iive> and it is known that their bitstream is slower on 32 bit.
[19:11:52 CEST] <ubitux> sometimes
[19:12:36 CEST] <michaelni> why are decissions like replacing the bitstream reader not discussed on the ML ?
[19:13:23 CEST] <iive> ^_^
[19:18:07 CEST] <jamrial> because merge discussion always happens here. also most if not all libavcodec developers are already here i guess
[19:20:33 CEST] <iive> maybe we could delay the bitstream merge, until there are enough codec changes that we want to merge?
[19:21:21 CEST] <wm4> michaelni: because all involved people are here?
[19:21:35 CEST] <wm4> I'd say being on IRC is a requirement for being ffmpeg developer
[19:22:24 CEST] <iive> wm4: there is reason it is not.
[19:22:46 CEST] <wm4> well then those not on IRC obviously miss out
[19:22:54 CEST] <wm4> not our fault (it's not like this place is secret)
[19:23:37 CEST] <michaelni> i dont want to be pulled into this discussion but at least continuing the merges should wait until we have decided if we want to make a release from this point because we need 2 minor bumps here if we release
[19:23:51 CEST] <ubitux> iive: no it's too large, we have to deal with it asap
[19:25:24 CEST] <jamrial> what michaelni said, do we branch 3.3 here, or wait until the pre major bump point?
[19:25:27 CEST] <jamrial> if the latter, then lets waste no more time and start merging the bitstream reader asap
[19:25:49 CEST] <atomnuker> how about we don't deal with it, the API change is pointless and we'll have to reindent practically everything so we'll diverge again
[19:26:18 CEST] <atomnuker> this isn't something minor, this is a huge change affecting most of the files in libavcodec
[19:26:55 CEST] <atomnuker> as well as changes to the way people have been used to writing decoders
[19:27:27 CEST] <atomnuker> people have given lectures on how to do that
[19:27:37 CEST] <jamrial> that's not a good argument. codecpar was a huge change in how people write de/muxers and it was just fine
[19:27:58 CEST] <iive> it wasn't just fine
[19:28:06 CEST] <durandal_1707> carl would disagree
[19:28:07 CEST] <atomnuker> and now we want to merge something to which most of us have had objections to just because its easier?
[19:28:16 CEST] <iive> it took months to iron out all small regressions
[19:28:16 CEST] <atomnuker> easier how?
[19:28:54 CEST] <atomnuker> jamrial: that did something which wasn't a rename
[19:29:18 CEST] <atomnuker> this is a pointless rename to which I wouldn't object to had it been thought out better
[19:29:41 CEST] <nevcairiel> if a decoder writer cant figure out a renamed API, he maybe shouldnt be writing decoders
[19:30:08 CEST] <durandal_1707> ugh
[19:30:12 CEST] <iive> nevcairiel: we have a lot of decoders
[19:31:08 CEST] <atomnuker> a non-siginficant majority of which either are completely different or just don't exist on their side
[19:31:31 CEST] <wm4> what if we just rename their macro/function names to something shorter
[19:32:01 CEST] <ubitux> wm4: no, that won't help for the next merges
[19:32:06 CEST] <atomnuker> also I don't think some maintainers which don't really post unless their decoders are broken would be happy to see everything changed if they have to do something
[19:32:14 CEST] <jamrial> wm4: that still makes merges a pain
[19:32:22 CEST] <nevcairiel> "everything", please, its just a rename
[19:32:27 CEST] <nevcairiel> hyperbole makes your argument weak
[19:32:32 CEST] <iive> nevcairiel: it is not
[19:33:28 CEST] <iive> there are changes in the API itself.
[19:33:53 CEST] <iive> going from ours to theirs is possible, even if it is not optimal 
[19:35:13 CEST] <nevcairiel> that is an argument for merging it =p
[19:35:46 CEST] <iive> making stuff non-optimal is argument against it.
[19:36:28 CEST] <nevcairiel> no, the argument is that going the other way is not always 1:1, and therefor makes future merges exponetially harder
[19:36:49 CEST] <iive> well, you know I'm not fan of merges.
[19:37:03 CEST] <nevcairiel> too bad, they are here
[19:37:17 CEST] <jamrial> we're talking about an internal API, i don't see why it's such a problem
[19:37:33 CEST] <iive> that's kind of circular logic.
[19:38:11 CEST] <jamrial> there have been massive changes to public API which people (devs and downstrea users) had to adapt to which were applied through the years, and now an internal API, used only by devs, is a big issue?
[19:38:13 CEST] <iive> the problem is that their bitstream reader/writer is not polished enough
[19:38:36 CEST] <BBB> jamrial: whats the issue?
[19:38:41 CEST] <nevcairiel> just mere minutes ago you admitted to not even looking at the final version iive
[19:38:41 CEST] <iive> it makes things slower and this has always been big NO-NO in ffmpeg
[19:38:54 CEST] <nevcairiel> and now you try to judge its code?
[19:39:02 CEST] <jamrial> BBB: atomnuker and iive are against merging the new bitstream reader
[19:39:09 CEST] <iive> nevcairiel: i trust others that have done benchmarks.
[19:39:18 CEST] <BBB> hm...
[19:39:18 CEST] <jamrial> arguing people already code decoders wiht get_bits, and learning the new slightly different API is a problem
[19:39:52 CEST] <BBB> thats the general problem with merging, we have to go by calls made by other people
[19:39:53 CEST] <durandal_1707> we are not gonna merge internal implementation
[19:40:00 CEST] <BBB> so Im just going to stay out of this discussion ;)
[19:40:17 CEST] <BBB> do whatever you feel is right
[19:40:28 CEST] <BBB> most decoders I care for are not impacted in overall performance by this thing, so ...
[19:40:30 CEST] <jamrial> we could skip it, but then merges will potentially become a pain
[19:40:42 CEST] <nevcairiel> durandal_1707: merging their API but emulating it with our get_bits implementation would end up even slower
[19:40:55 CEST] <ubitux> we need to write a wrapper with the same api
[19:40:56 CEST] <BBB> Im not advocating to skip it ;) Im telling you to make a decision that you feel is best given all information at your and ubitux hand
[19:40:59 CEST] <BBB> you guys merge, you decide
[19:41:38 CEST] <ubitux> i don't really care about impl, but i want a common api
[19:42:00 CEST] <jamrial> I'd just merge the whole thing, which will keep merges simple. then, if it really fucks up with performance on important codecs, we can see about reverting it for those
[19:42:11 CEST] <jamrial> this is an internal API, in a header
[19:42:16 CEST] <nevcairiel> i dont think they even converted any "important" codecs yet
[19:42:18 CEST] <jamrial> it's easy to undone
[19:42:21 CEST] <jamrial> *undo
[19:42:27 CEST] <iive> jamrial: this would create even bigger mess
[19:42:28 CEST] <ubitux> or we can look at speeding it up too
[19:42:37 CEST] <jamrial> or that
[19:42:53 CEST] <jamrial> iive: not really, it's not like libav has yet removed get_bits either
[19:43:06 CEST] <durandal_1707> it can use get bits just fine, make it always inline
[19:43:14 CEST] <nevcairiel> no it can't
[19:43:24 CEST] <nevcairiel> bitstream_read can read 32 bits, get_bits can only read 23
[19:43:36 CEST] <ubitux> the initial decoders are fringe ones, it's not a problem to merge them
[19:43:45 CEST] <nevcairiel> using get_bits_long would work, but then its definitely slower
[19:43:52 CEST] <atomnuker> we already agreed we aren't merging the reader itsef, this is api discussions only
[19:44:02 CEST] <nevcairiel> noone agreed
[19:44:20 CEST] <iive> the problem is that get_bits() and get_bits_long() are both coverted to bistream_read() , going back is a guess game
[19:44:25 CEST] <durandal_1707> lets vote
[19:44:35 CEST] <iive> guess wrong and you get either slow or buggy code
[19:44:36 CEST] <jamrial> iive: going back is git revert
[19:44:36 CEST] <nevcairiel> its not "guessing", you just need to choose based on the number of bits
[19:44:53 CEST] <iive> jamrial: after few merges, it is not.
[19:44:53 CEST] <nevcairiel> if you guess, you shouldnt be working on the code
[19:45:15 CEST] <atomnuker> iive: you can make the function itself a macro which inlines either long or normal if the bit count is 31 or above
[19:45:25 CEST] <jamrial> iive: how so? each decoder change is on its own commit
[19:45:32 CEST] <jamrial> we'd do the same for those decoders we convert
[19:45:34 CEST] <iive> nevcairiel: that's why I pointed out that there are a lot of codecs in ffmpeg.
[19:45:53 CEST] <iive> atomnuker: condition would kill performance
[19:45:56 CEST] <nevcairiel> atomnuker: only if its a constant, otherwise overhead, and if its a constant its easy to choose manually
[19:46:02 CEST] <atomnuker> iive: macros don't
[19:46:08 CEST] <atomnuker> oh
[19:46:21 CEST] <ubitux> iive: it's often a const n, isn't it ?
[19:46:28 CEST] <atomnuker> nope
[19:46:29 CEST] <iive> atomnuker: it's not always a constant. that's the problem.
[19:46:35 CEST] <atomnuker> yeah, I realized that
[19:47:10 CEST] <atomnuker> that makes merging it even more problematic for our code
[19:47:25 CEST] <iive> I must say, I am totaly for mergin their bitstream reader and making it use the old api.
[19:47:42 CEST] <jamrial> there's av_builtin_constant_p() to check this at compile time
[19:47:43 CEST] <nevcairiel> like i said, you cant really do that without making it even slower
[19:47:56 CEST] <durandal_1707> just rename get_bits to bitstream
[19:49:14 CEST] <durandal_1707> i would just add 63 bit variant for cases when its faster
[19:50:50 CEST] <jamrial> before we start with any this, we need to decide if we branch 3.3 here or wait some weeks until we get to the major bump
[19:50:55 CEST] <atomnuker> durandal_1707: s/get_bits/bitstream is the worst idea possible because the API still changes and its not compatible with either
[19:51:06 CEST] <jamrial> waiting will mean getting the bitstream reader, in whatever form we merge it, into that release
[19:51:56 CEST] <atomnuker> moreover, "bitstream" is very long and incorrect - its not always a bitstream
[19:52:22 CEST] <jamrial> it's internal, who cares about signature
[19:52:30 CEST] <durandal_1707> yes, dont merge
[19:52:31 CEST] <atomnuker> well we care because we have to deal with it
[19:52:50 CEST] <nevcairiel> you make that sound like writing a few more chars will end your world
[19:52:55 CEST] <nevcairiel> get an editor with autocomplete and move on
[19:53:06 CEST] <durandal_1707> no way
[19:53:22 CEST] <iive> nevcairiel: you want to start vim vs emacs holly war?!
[19:53:23 CEST] <durandal_1707> i will fork ffmpeg with sexy name
[19:53:48 CEST] <nevcairiel> iive: both of those suck
[19:53:49 CEST] <nevcairiel> :)
[19:53:54 CEST] <iive> ;)
[19:53:59 CEST] <kierank> I think the name change is stupid as well but imo that's orthogonal to whether it should be merged
[19:54:53 CEST] <iive> ok, how about not mergin it verbatim
[19:55:27 CEST] <iive> that is we do a rename, where get_bits -> bistream_read ; get_bits_long - > bitstream_read_long
[19:55:28 CEST] <jamrial> the name can't be changed because that's the entire thing about keeping merges pain free
[19:55:51 CEST] <iive> so the old and new API is 1:1
[19:55:52 CEST] <kierank> I agre
[19:55:54 CEST] <durandal_1707> write merge script
[19:55:54 CEST] <kierank> e
[19:56:23 CEST] <nevcairiel> iive: that would change the semantics between ffmpeg and libav, making the worst possible solution for merges, since stuff silently looks right but may be wrong
[19:57:54 CEST] <iive> nevcairiel: well... i'd use your argument above... we should just know what we are merging.
[19:58:44 CEST] <nevcairiel> there is a difference between knowing and making stuff intentionally slightly different and therefor error prone
[19:58:56 CEST] <atomnuker> its so simple - just don't merge anything from the bitstream reader since it'll take a significantly less amount of work to change their stuff to ours than the reverse
[19:59:14 CEST] <iive> \o/
[19:59:50 CEST] <nevcairiel> we'll enlist you to do all this work then, once it comes up, and you are obligated to do it within a specified timeframe, ok? :)
[20:00:08 CEST] <jamrial> atomnuker: it's not limited to actual bitstream related commits. it's about every future commit that adds or removes calls to those functions for whatever reason, including new decoders they write that we would merge
[20:01:06 CEST] <atomnuker> I don't expect there to be too many future commits touching decoders and even if there are then it'll still be less work than having our additional stuff ported
[20:01:22 CEST] <atomnuker> and think about it for a second: most codecs nowadays use entropy coding and entirely skip rawbits
[20:01:54 CEST] <nevcairiel> we had this discussion just recently, and the  conclusion was that many modern codecs still use rawbits for headers, even if you think thats stupid =p
[20:02:14 CEST] <atomnuker> opus and daala don't
[20:02:32 CEST] <nevcairiel> so, exactly one organization doesnt
[20:02:33 CEST] <nevcairiel> great
[20:02:34 CEST] <nevcairiel> :D
[20:03:09 CEST] <jamrial> daala is now part of av1, and that's pretty much vp10. what does vp9 do?
[20:03:39 CEST] <nevcairiel> vp9 has a rawbits header and a entropy header
[20:03:43 CEST] <iive> For me the biggest problem is that their new bitstream reader is not faster in all cases.
[20:04:05 CEST] <jamrial> as ubitux said, it's something we can work on
[20:04:09 CEST] <iive> it would have been no brainer if it as.
[20:04:15 CEST] <iive> was.
[20:04:24 CEST] <michaelni> ffv1 and snow use range coding in headers
[20:06:26 CEST] <atomnuker> nevcairiel: I'll be happy to merge those and anything which conflicts and can't be solved in non-obvious ways (e.g. s/bitstream/get_bits won't do)
[20:06:31 CEST] <jamrial> guys, really, 3.3, what do? now before this whole thing, or weeks from now after/during this whole thing?
[20:07:17 CEST] <jamrial> wm4 already said he doesn't like the idea of branching on a three weeks old commit + backported stuff, so that's i guess not an option
[20:07:37 CEST] <BtbN> Just pretend it was branched before all the merges resumed, and backport fixes from in between, seems like a natural thing
[20:08:10 CEST] <nevcairiel> its a bit iffy to make such an old release, but in reality you could just pretend someone branched already back then and we just had a long backport window
[20:08:51 CEST] <jamrial> BtbN: that's what michaelni suggested, but wm4 didn't like. It also makes the alledged point at which was branched off innacurate
[20:09:32 CEST] <wm4> well my opinion in this doesn't need to be a blocker of course
[20:09:50 CEST] <wm4> anyway I find it silly trying to rush a release now
[20:10:04 CEST] <BtbN> Yeah, no need to rush anything there.
[20:10:05 CEST] <jamrial> technically speaking, we're two months behind schedule :p
[20:10:37 CEST] <jamrial> also, as i said, releasing right before the major bump will mean we'll be in the middle of this bitstream thing
[20:10:56 CEST] <nevcairiel> this bitstream thing isnt going to end anytime soon
[20:11:17 CEST] <nevcairiel> libav is still trying to figure out why some codecs get signficantly s lower
[20:11:32 CEST] <nevcairiel> so anything ported so far are fringe codecs
[20:11:53 CEST] <ubitux> do you think the proposed api allow to perform as good as the old one?
[20:12:00 CEST] <jamrial> chances are it may end up at least in a 32 bits buffer variant
[20:12:24 CEST] <nevcairiel> which is a bit of a problem if you try to read 32-bits at once, which their api contract allows
[20:12:25 CEST] <ubitux> i mean, can we expect to be able to actually fix the implementation to catch up with the speed given the current api?
[20:12:32 CEST] <nevcairiel> there is a reason ours can only read 23 bits with a 32-bit buffer
[20:13:06 CEST] <michaelni> our API supported multiple implementations some of which could do 32bit choosable per codec
[20:13:18 CEST] <nevcairiel> yeah but the 32-bit variant is slower
[20:13:40 CEST] <durandal_1707> proof?
[20:13:57 CEST] <nevcairiel> why do you think it exists separately if it would be the s ame speed or even faster? =p
[20:14:13 CEST] <michaelni> if theres a faster implementation now somewhere , can it be put in place of the old 32bt variant ?
[20:14:29 CEST] <durandal_1707> $$$
[20:15:50 CEST] <nevcairiel> basically get_bits_long (the one that can read 32 bits at once) uses the optimized get_bits reader twice to read 16+16 bits and shift+or them together, a new reader that has a bigger cache to allow reading 32-bits like that would be faster then that
[20:16:02 CEST] <nevcairiel> but - a 64-bit cache may not end up really faster on a 32-bit CPU
[20:16:38 CEST] <nevcairiel> (and even if people want to ignore 32-bit x86 like they usually like to do, there is still ARM)
[20:17:58 CEST] <nevcairiel> (also I was wrong e arlier, get_bits can read 25 not 23, not sure how I arrived at 23)
[20:18:37 CEST] <michaelni> with LONG_BITSTREAM_READER MIN_CACHE_BITS was 32 and get_bits_long() was doing a single call
[20:19:06 CEST] <michaelni> that code was removed
[20:19:20 CEST] <nevcairiel> seems to still have some remnants in the code
[20:19:37 CEST] <durandal_1707> who removed it?
[20:19:40 CEST] <iive> if libav haven't get rid of all get_bits() and if they do try to make 32 bit case faster
[20:19:53 CEST] <iive> it could only mean that they will need to change thair API again.
[20:20:52 CEST] <iive> durandal_1707: I think it was Mans, but I am not 100% sure.
[20:22:28 CEST] <jamrial> looks like fate-hevc-extradata-reload isn't working on all targets
[20:23:30 CEST] <durandal_1707> revert that change then
[20:24:19 CEST] <jamrial> durandal_1707: it's a new test added i think today. if anything, find why it isn't working as intended
[20:24:49 CEST] <durandal_1707> jamrial: i meant get bits long
[20:25:08 CEST] <jamrial> ah, my bad
[20:25:56 CEST] <nevcairiel> whats wrong with the valgrind station
[20:26:07 CEST] <nevcairiel> does it not like avx2?
[20:27:15 CEST] <rcombs> anyone know why SWS_FULL_CHR_H_INT isn't on by default
[20:27:35 CEST] <nevcairiel> jamrial: odd with the hevc test, also fails on msvc .. which is why I thought maybe to look at valgrind, msvc crt does memory init a bit differently
[20:28:35 CEST] <jamrial> nevcairiel: yeah, valgrind is choking on some avx2 functions. there's a workaround command line option, but otherwise valgrind needs to fix it
[20:29:08 CEST] <michaelni> btw there wasnt just LONG_BITSTREAM_READER (64bit based) there was also A32_BITSTREAM_READER which used a 32bit cache
[20:29:58 CEST] <nevcairiel> jamrial: you know whats itneresting, the hashes in libav are those the "failing" stations produce
[20:30:05 CEST] <nevcairiel> the ones in the commit are new ones
[20:30:13 CEST] <nevcairiel> (in the merge, i mean)
[20:37:25 CEST] <michaelni> fate-hevc-extradata-reload fails on arm and mips qemu
[20:46:32 CEST] <jamrial> nevcairiel: so maybe msvc is right for once :D
[21:15:46 CEST] <BBB> michaelni: arent those the systems that have their own (optimized) nalcode parser?
[21:24:44 CEST] <nevcairiel> at this point it fails on more systems then it succeeds on, and the failing ones produce the s ame hash that libav has, so it seems those "passing" ones may be the wrong ones
[21:25:18 CEST] <jamrial> adding -sws_flags bitexact makes mingw output the hashes msvc and arm get
[21:25:28 CEST] <nevcairiel> interesting
[21:25:40 CEST] <nevcairiel> dont most tests use those flags anyway?
[21:25:47 CEST] <nevcairiel> should just go with that then =p
[21:26:23 CEST] <jamrial> fate-hevc-paramchange uses -sws_flags area+accurate_rnd+bitexact, but if i add that to this test, the hashes are different
[21:26:27 CEST] <jamrial> so, bitexact only i guess :p
[21:26:39 CEST] <nevcairiel> weird
[21:26:45 CEST] <nevcairiel> also why area
[21:27:08 CEST] <jamrial> no idea, i didn't write that old test
[21:27:27 CEST] <nevcairiel> but yeah changing the scaling algo would change the results
[21:27:50 CEST] <jamrial> -sws_scale accurate_rnd+bitexact also works
[21:28:16 CEST] <nevcairiel> bitexact aloen should be fine
[21:28:47 CEST] <durandal_1707> does anyone have yuv420p dnxhr files?
[21:31:47 CEST] <jamrial> nevcairiel: i bet it's some non bitexact x86 inline asm
[21:32:01 CEST] <nevcairiel> scaling uses all sorts of varying optimizations
[21:32:09 CEST] <jamrial> it would explain why msvc fails only for x86
[21:41:16 CEST] <cone-163> ffmpeg 03James Almer 07master:5f23d8b405fa: fate: add bitexact sws_flags to hevc-extradata-reload
[22:12:40 CEST] <michaelni> BBB, maybe but it seems jamrial / nevcairiel have found the issue already
[22:12:51 CEST] <BBB> cool
[22:13:04 CEST] <michaelni> or at least i think, havnt tested yet
[22:14:50 CEST] <jamrial> michaelni: it should. adding the bitexact flag to sws_flags made x86 mingw and x86 linux output the same hashes as arm/aarch/sparc and x86 msvc, which makes me think the "problem" was some non bitexact sws x86 inline asm
[22:55:45 CEST] <cone-163> ffmpeg 03Michael Niedermayer 07master:679a315424e6: avformat/oggparsedaala: Check duration for AV_NOPTS_VALUE
[22:55:46 CEST] <cone-163> ffmpeg 03Michael Niedermayer 07master:23ae3cc82291: avformat/oggparsedaala: Do not leave an invalid value in gpshift
[23:33:41 CEST] <durandal_1707> is this mediafoundation patch serious?
[23:34:15 CEST] <nevcairiel> do you think someone would implement a 3000 lines of code as a joke? :)
[23:34:40 CEST] <durandal_1707> yes
[23:47:56 CEST] <BBB> what does that patch do anyway, if its not hardware acceleration?
[23:48:08 CEST] <BBB> is it just a way to link arm-optimized codecs into ffmpeg?
[23:49:03 CEST] <wm4> do you mean mediafoundation?
[00:00:00 CEST] --- Sun Apr  2 2017