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

[burek]

[00:34:11 CEST] <kurosu> re configure script, it runs in 1m20s now, so ~3.2x faster
[00:34:22 CEST] <kurosu> (Win7 x64)
[06:02:22 CEST] <atomnuker> decoders can attach arbitrary private avbuffers to frames, right?
[10:37:51 CEST] <cone-102> ffmpeg 03Jacek Jendrzej 07master:3cff2311ab9d: avformat/dashdec: Fix calc_cur_seg_no if availability_start_time not
[10:37:51 CEST] <cone-102> ffmpeg 03Colin NG 07master:b205635fbc08: avformat/dashdec: Add a re-entrance check point after an interrupt operation
[14:24:29 CEST] <durandal_1707> another -200 lines diff reduced with scpr 3rd version
[15:24:50 CEST] <atomnuker> how much + was it when you started?
[16:25:27 CEST] <durandal_1707> atomnuker: too much, >3000
[16:55:17 CEST] <durandal_1707> atomnuker: you gonna RE binka?
[17:32:52 CEST] <atomnuker> durandal_1707: not if you do it first
[17:53:47 CEST] <durandal_1707> snowman plugin successfully decompiles that binka function
[18:17:55 CEST] <atomnuker> couldn't find a recent cracked version of ida, russians have 6.5 uncracked for linux only
[18:49:07 CEST] <kierank> atomnuker: surely mozilla can get you that
[18:55:20 CEST] <atomnuker> of course not, its for personal use, and its too expensive for anyone anyway
[20:19:05 CEST] <durandal_1707> kierank: use wine, 6.8 works very good, 7.0 is crap
[20:19:27 CEST] <durandal_1707> atomnuker: ^
[20:20:04 CEST] <kurosu> durandal_1707, none of the fate magicyuv samples are >8 bits ?
[20:21:06 CEST] <durandal_1707> kurosu: yes, only 8bit
[20:23:14 CEST] <kurosu> so does your encoder
[20:23:35 CEST] <durandal_1707> kurosu: why you need 10bit?
[20:24:03 CEST] <kurosu> would have been nice to test the roundtrip, e.g. vsynth tests
[20:24:31 CEST] <kurosu> durandal_1707, I like running fate to see if a change breaks some stuff
[20:24:35 CEST] <durandal_1707> there is also 12bit, and unsupported 14bit
[20:24:53 CEST] <kurosu> yeah, I can see that from the code
[20:25:43 CEST] <durandal_1707> kurosu: do you need >8bit samples or you gonna extend encoder?
[20:26:19 CEST] <kurosu> encoder is too much work
[20:26:36 CEST] <kurosu> A 10bit sample for a start would have been nice
[20:27:18 CEST] <kurosu> It would be nice if trac tickets had a feature to declare samples as free to redistribute (eg fate)
[20:28:44 CEST] <durandal_1707> kurosu: what kind of input source for 10bit?
[20:29:34 CEST] <kurosu> durandal_1707, err... I just want to check whether the decoder produces the same output after a change
[20:30:32 CEST] <durandal_1707> so i can use: ffmpeg -f lavfi -i yuvtestsrc as source?
[20:31:55 CEST] <kurosu> I suspect, yes
[20:32:15 CEST] <kurosu> the vsynth tests are kind of similar, except legacy
[20:32:49 CEST] <kurosu> I don't remember the invoking chain, but I remember adding vsynth3 to catch corner cases with weird or small dimensions 
[20:34:03 CEST] <durandal_1707> vsynth3 is for cases when there is encoder
[20:37:03 CEST] <kurosu> yes, I thought we were discussing the roundtrip fate thing
[20:42:34 CEST] <durandal_1707> kurosu: http://0x0.st/stSl.avi ?
[20:44:20 CEST] <kurosu> ok so you fed that to a 10bit capable encoder
[20:44:43 CEST] <kurosu> ok, I recognize the yuvtestsrc pattern, and thus the intent of your question
[20:49:38 CEST] <durandal_1707> that is magicyuv 10bit 422
[20:50:06 CEST] <kurosu> yeah, I saw that from the pixfmt
[20:51:06 CEST] <kurosu> anyway, I picked the wrong branch to rebase, so I can't check everything I wanted
[20:51:32 CEST] <kurosu> https://pastebin.com/H6Lwpuic <- various bitstream reading commits to magicyuv decoder
[20:51:38 CEST] <kurosu> master = current ffmpeg master
[20:51:46 CEST] <kurosu> prepa: just before the actual changes
[20:52:10 CEST] <kurosu> lav: libav bitstream reader (their API, this is very old code)
[20:52:26 CEST] <kurosu> dual: code from huffyuvdec
[20:52:56 CEST] <kurosu> funny that the x86_32 (2nd column) is faster than x86_64 (3rd) at the start
[20:53:06 CEST] <kurosu> (gcc 7.3)
[20:53:24 CEST] <kurosu> can't test in particular the x86_32 tweaks
[20:53:58 CEST] <kurosu> and well, I intended to see about the >8 bits paths, but using the wrong branch broke my motivation for further tests
[20:57:09 CEST] <kurosu> anyway, summary of all this: you should commit your cached bitstream reader
[20:57:22 CEST] <kurosu> that is too good for continuing passing on it for another year
[20:57:28 CEST] <kurosu> even if few people care
[21:00:41 CEST] <durandal_1707> michaelni: do you have comments for bitstream patchset?
[21:43:38 CEST] <michaelni> durandal_1707, ive looked very briefly at the  3 cached bitstream reader patches when yu posted a few days ago. and didnt spot anything beyond what others have mentioned, quite possibly of course that i missed something
[21:50:02 CEST] <atomnuker> durandal_1707: what's wrong with 7.0?
[22:03:24 CEST] <durandal_1707> atomnuker: debuger crashes under wine, and your changes are not fully reflected in decompiler output
[23:15:53 CEST] <cone-066> ffmpeg 03Paul B Mahol 07master:d71dfc087bce: avcodec/scpr: error out if run length is <= 0
[00:00:00 CEST] --- Thu Aug 30 2018