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

[burek]

[00:17:11 CEST] <atomnuker> bofh_: ping
[05:02:58 CEST] <rcombs> anybody have the key for this 256-bit-encrypted ML post http://ffmpeg.org/pipermail/ffmpeg-devel/2018-August/233610.html
[06:46:43 CEST] <cone-900> ffmpeg 03Gyan Doshi 07master:d0b48a960448: avdevice/decklink_enc: print preroll and buffer size
[09:44:52 CEST] <JEEB> 741
[10:10:12 CEST] <kurosu___> durandal_1707: in your ut videodec patch, maybe define the macro to HAVE_FAST_64BITS
[10:11:17 CEST] <kurosu___> I don't remember the impact of an the cached reader optimized for 32b, 
[10:12:16 CEST] <kurosu___> all the more since on utvideodec, it was on top of the dual vlc tables ported from huffyuvdec 
[10:15:28 CEST] <kurosu___> Regarding ffv2, I find the naming confusing: I wouldn't expect a lossy, spatial-transform based encoder, when the original ffv1 was like a lossless png on steroid
[10:16:10 CEST] <kurosu___> And the very first ffv2 was trying to increase throughput by using multisymbol codewords iirc
[10:16:59 CEST] <durandal_1707> kurosu___: when is fast_64 enabled?
[10:17:49 CEST] <kurosu___> x86_64, but the issue is when a 32b arch actually splits 64b ops in 32b ones
[10:18:54 CEST] <kurosu___> I don't know if arm64/v8/whatever it's called is both faster with the cached version and really uses 64b ops there
[10:18:57 CEST] <durandal_1707> Carl tried patch with other popular arches and only x86_32 is worse
[10:19:16 CEST] <kurosu___> libav probably did some test on arm64
[10:19:18 CEST] <kurosu___> Ok
[10:19:52 CEST] <kurosu___> Anyway, this can be handled on a case by case, as the cached reader needs to be selectively enabled
[10:21:14 CEST] <kurosu___> You could then maybe use !ARCH_X86_32 but that looks hackish
[10:21:41 CEST] <kurosu___> (I mean, more than fast 64b, which is kind of a rationale by itself)
[10:25:26 CEST] <kurosu___> Anyway I could put on some kind of pastebin some results for different things (optimized libav reader for 32b, dual vlc for various lossless decoders)
[10:26:01 CEST] <kurosu___> Probably 2yo codebase not having the latest security fixes (like invalid vlcs etc)
[10:36:54 CEST] <durandal_1707> libav doesn't use unchecked bit reader, so that should be looked into
[10:40:04 CEST] <durandal_1707> what about this qp_table thing, - its deprecated and there is no alternative?
[10:55:55 CEST] <kurosu___> Regarding bitstream reader, anyway, I recommend you read https://fgiesen.wordpress.com/2018/02/19/reading-bits-in-far-too-many-ways-part-1/ and followings
[10:56:16 CEST] <kurosu___> You may recognize some of the 'tricks' in ffmpeg
[10:59:26 CEST] <j-b> kierank: do you have DPCM samples?
[10:59:46 CEST] <durandal_1707> kurosu___: using 25 (why 25 and not 23) bit reader is one of tricks?
[10:59:58 CEST] <kierank> j-b: kind of
[11:00:13 CEST] <nevcairiel> because 7 bits is the remaining room for one spill over byte
[11:03:13 CEST] <kierank> j-b: there is one mxf sample that apparently has dpcm blocks but I can't see them. Then there is reference samples which I can decode one frame now but the rest doesn't decode because of impossible to understand moeg4video code
[11:06:35 CEST] <durandal_1707> mpeg4video P frames code is trivial - piece of cake
[11:10:43 CEST] <kierank> durandal_1707: for 10-bit?
[11:10:59 CEST] <kierank> all the slice padding stuff doesn't work
[11:11:04 CEST] <kierank> it just drops frames
[11:11:10 CEST] <kierank> all sorts of insane mpegvideo.c magic in there
[11:15:16 CEST] <durandal_1707> kierank: you already wrote some basic 10bit P parsing?
[11:15:24 CEST] <kierank> no
[11:15:34 CEST] <kierank> I am not working on theoretical code
[11:16:10 CEST] <durandal_1707> wait, that DPCM stuidio files are I always?
[11:16:23 CEST] <kierank> dunno, never looked at pframes
[11:16:33 CEST] <kierank> I don't think they exist in reality
[11:16:59 CEST] <durandal_1707> so samples you have are all I?
[11:18:37 CEST] <kierank> real samples
[11:18:38 CEST] <kierank> yes
[11:19:40 CEST] <durandal_1707> kierank: link to files?
[11:19:56 CEST] <kierank> https://trac.ffmpeg.org/ticket/4447
[11:21:07 CEST] <durandal_1707> kierank: those 3 files, I have already i think, where is calendar sample?
[11:21:10 CEST] <kierank> also reference samples https://mpeg.chiariglione.org/standards/mpeg-4/conformance-testing
[11:21:16 CEST] <kierank> can't remember which one
[11:22:13 CEST] <BtbN> I'm really surprised carl didn't immediately close that one.
[11:35:31 CEST] <durandal_1707> kierank: cant find it there
[11:36:00 CEST] <kierank> standards.iso.org\ittf\PubliclyAvailableStandards\ISO_IEC_14496-4_2004_Conformance_Testing\video_conformance\studio
[11:36:04 CEST] <kierank> there
[11:36:09 CEST] <kierank> I think calendar one is 11
[11:53:39 CEST] <durandal_1707> 11, calendar ones decodes all frames just fine here
[11:54:24 CEST] <kierank> durandal_1707: without patch?
[11:54:41 CEST] <durandal_1707> kierank: with your patch obviously
[11:54:49 CEST] <kierank> ffmpeg drops lots of frames for me
[11:54:53 CEST] <kierank> it's a piece of crap
[11:54:57 CEST] <kierank> so I dunno
[11:54:59 CEST] <kierank> don't care
[11:55:10 CEST] <kierank> not gonna spend time fixing mpeg4video monstrosiy
[11:55:39 CEST] <durandal_1707> kierank: ffmpeg demuxes 6 frames only, is there more frames actually?
[11:57:04 CEST] <kierank> proably
[11:57:06 CEST] <kierank> I dunno
[12:06:37 CEST] <BtbN> This guy...
[12:09:21 CEST] <durandal_1707> BtbN: give him free support
[12:09:36 CEST] <BtbN> I even told him what was wrong with his code.
[12:10:28 CEST] <BtbN> hm, our trac is kinda in need of an update
[12:11:56 CEST] <BradleyS> s/trac/honeypot/
[12:28:06 CEST] <durandal_1707> kierank: do you have specs for studio?
[12:28:52 CEST] <durandal_1707> some files have P frames, but they came later and even first I frame somehow fails to decode for 6 sample
[12:30:36 CEST] <durandal_1707> ^6th file
[12:40:48 CEST] <kierank> durandal_1707: sent
[12:59:39 CEST] <durandal_1707> kierank: vcon-stp6L1.bits first frame is fully DCT and it decodes noise
[13:00:56 CEST] <cone-720> ffmpeg 03Carl Eugen Hoyos 07master:c2be3826200c: lavf/Makefile: Fix standalone compilation of the matroska and webm muxers.
[13:01:29 CEST] <JEEB> ah, I was thinking of sending that patch (if that adds av1.o to the deps)
[13:01:41 CEST] <JEEB> but great if someone was quicker
[13:04:57 CEST] <kierank> durandal_1707: dunno, might use some features not seen before
[13:13:04 CEST] <durandal_1707> kierank: macroblock_type vlc stuff is missing
[13:36:12 CEST] <kierank> durandal_1707: really
[13:37:23 CEST] <durandal_1707> for intra, one needs to check if remaining bit is 1
[13:48:46 CEST] <durandal_1707> if video height is not multiple of 16, how is it handled for DCT decoders? do i need to align height to 16?
[13:49:38 CEST] <kierank> durandal_1707: so if it's not 1 then what do I do?
[13:50:30 CEST] <durandal_1707> invalid for intra
[13:51:28 CEST] <kierank> does that fix sample 6?
[14:07:51 CEST] <durandal_1707> kierank: nope
[16:49:17 CEST] <durandal_1707> i just RE another screen capture codec gem, it took me litteraly 15 minutes, and all algo is in my head
[16:50:59 CEST] <atomnuker> hail to you, champion
[16:52:11 CEST] <durandal_1707> zlib + rle on planar rgb vertically flipped
[17:59:50 CEST] <MoSal> In libavcodec/utils.c line 2133
[18:00:05 CEST] <MoSal>      av_freep(&codec->extradata);
[18:00:44 CEST] <MoSal> what if codec->extradata is NULL?
[18:00:55 CEST] <BtbN> nothing to free then?
[18:01:23 CEST] <BtbN> freeing a NULL pointer is perfectly valid
[18:04:47 CEST] <MoSal> BtbN: the NULL being codec->extradata not &codec->extradata, right?
[18:05:02 CEST] <BtbN> &codec->extradata cannot be NULL.
[18:05:31 CEST] <BtbN> The only problem would be if codec was
[18:06:05 CEST] <JEEB> as long as the lavc helpers were used for the codec
[18:07:49 CEST] <MoSal> BtbN: I traced the crash I mentioned here https://ffmpeg.org/pipermail/ffmpeg-devel/2018-August/233584.html to this
[18:08:21 CEST] <JEEB> how does Firefox make that thing?
[18:09:07 CEST] <MoSal> JEEB: don't know. 
[18:09:13 CEST] <MoSal> #0  0x0000000000406599 in  ()
[18:09:15 CEST] <MoSal> #1  0x00007fc5b0dcdc76 in avcodec_parameters_to_context (codec=codec at entry=0x7fc5b226c800, par=0x7fc5b22997c0)
[18:09:17 CEST] <MoSal>     at libavcodec/utils.c:2133
[18:09:19 CEST] <MoSal> #2  0x00007fc5b095ceda in ff_decode_bsfs_init (avctx=avctx at entry=0x7fc5b226c800) at libavcodec/decode.c:284
[18:09:21 CEST] <MoSal>         avci = 0x7fc5b224f100
[18:09:23 CEST] <MoSal>         s = 0x7fc5b224f138
[18:09:25 CEST] <MoSal>         bsfs_str = 0x7fc5b110d364 ""
[18:09:25 CEST] <JEEB> (use a pastebin)
[18:09:27 CEST] <MoSal>         ret = <optimized out>
[18:09:29 CEST] <MoSal> #3  0x00007fc5b0dcccf1 in avcodec_open2 (avctx=0x7fc5b226c800, codec=0x7fc5b1416880 <ff_aac_decoder>, options=0x0)
[18:09:31 CEST] <MoSal>     at libavcodec/utils.c:731
[18:09:31 CEST] <JEEB> or 0x0.st
[18:09:33 CEST] <MoSal>         ret = 0
[18:09:35 CEST] <MoSal>         tmp = 0x0
[18:09:37 CEST] <MoSal>         pixdesc = <optimized out>yTY
[18:10:02 CEST] <MoSal> JEEB: figured it's short enough. won't do it again.
[18:10:14 CEST] <nevcairiel> anything more then 3 lines isnt short :)
[18:10:26 CEST] <JEEB> also that's a mess to read on my terminal IRC client
[18:10:46 CEST] <BtbN> Line 2133 in utils.c in what commit?
[18:11:07 CEST] <BtbN> That av_freep line is absolutely fine.
[18:11:07 CEST] <MoSal> BtbN: c2be382620
[18:11:39 CEST] <nevcairiel> unless they manually allocate it with another allocation function
[18:11:44 CEST] <nevcairiel> which would probably be bad API use
[18:12:35 CEST] <JEEB> yea
[18:12:41 CEST] <JEEB> that's what I meant.
[18:12:51 CEST] <JEEB> or if nullptr gets through somewhere from the API client
[18:17:43 CEST] <BtbN> The backtrace showing nothing is also very suspicious. It should jump into av_freep at the very least
[18:17:54 CEST] <BtbN> Or is that just a macro?
[18:22:48 CEST] <cone-094> ffmpeg 03James Almer 07master:3d2cf50ebbe2: avcodec/libopusenc: support encoding packets of sizes bigger than 60ms
[18:22:49 CEST] <cone-094> ffmpeg 03James Almer 07master:7890181d7e76: avformat/movenc: support Opus packets with more than 60ms of audio when writing the Sample Group Description
[18:22:50 CEST] <cone-094> ffmpeg 03James Almer 07master:701aca55fd11: avformat/flvdec: don't propagate empty extradata
[18:23:55 CEST] <JEEB> can someone run FATE on https://patchwork.ffmpeg.org/patch/9836/ before I push it just in case? I don't have the full FATE set around
[18:24:07 CEST] <JEEB> I should have changed all of the tests relevant to ismv/movenc
[18:28:23 CEST] <jamrial> JEEB: sure
[18:29:01 CEST] <JEEB> cheers
[18:36:57 CEST] <atomnuker> durandal_1707: had some comments about the prosumer decoder
[19:26:58 CEST] <MoSal> https://hg.mozilla.org/mozilla-central/file/tip/dom/media/platforms/ffmpeg/FFmpegDataDecoder.cpp#l85
[19:27:53 CEST] <MoSal> mExtraData is a ref-counted vector-like type.
[19:28:23 CEST] <BtbN> So they clearly are putting something into that pointer that's not supposed to be there.
[19:29:26 CEST] <MoSal> BtbN: Is it made clear that libavcodec own than data?
[19:30:22 CEST] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/avcodec.h;h=31e50d5a947df2237a293c2db83e2d345ae5c623;hb=HEAD#l1619
[19:30:25 CEST] <BtbN> that depends
[19:30:51 CEST] <BtbN> For decoding, which this clearly is, ffmpeg freeing it is a bug.
[19:31:44 CEST] <MoSal> BtbN: this is indeed AAC decoding context.
[19:35:51 CEST] <BtbN> I think I see what's going on. It's a copy & paste error.
[19:36:08 CEST] <BtbN> All lines around line 2133 reference par->extradata
[19:37:02 CEST] <BtbN> hm, no, that's not it
[19:37:11 CEST] <BtbN> it overwrite the codec one
[19:37:15 CEST] <BtbN> so it does right in freeing it
[19:41:21 CEST] <MoSal> So, should I send a reply to the mailing list, or open an issue, or you got it from here?
[19:42:30 CEST] <nevcairiel> i dont think its the only place where its assumed that extradata is allocated from av_malloc
[19:42:51 CEST] <nevcairiel> for API safety firefox should change its code
[19:43:20 CEST] <BtbN> https://bpaste.net/show/c7c10cc6e79e this should be the right approach
[19:43:32 CEST] <nevcairiel> doubtful
[19:43:34 CEST] <BtbN> as the doc clearly states that ffmpeg never touches it for decoders
[19:43:36 CEST] <nevcairiel> bsfs dont run in front of encoders
[19:44:01 CEST] <BtbN> But avcodec_parameters_to_context does?
[19:44:31 CEST] <nevcairiel> if you call that function, it will modify the avctx
[19:44:35 CEST] <nevcairiel> no matter what you do
[19:44:56 CEST] <nevcairiel> thats its express purpose
[19:45:14 CEST] <BtbN> Yes, but it's only documented to touch the extradata for encoders
[19:45:18 CEST] <nevcairiel> no its not
[19:45:30 CEST] <nevcairiel> that function is entirely independent of what the avctx contains
[19:45:44 CEST] <BtbN> "- decoding: Set/allocated/freed by user."
[19:45:45 CEST] <nevcairiel> it copies the entire continents of codecpar to avctx
[19:45:51 CEST] <nevcairiel> contents*
[19:45:57 CEST] <nevcairiel> no exceptions
[19:46:16 CEST] <BtbN> Well, but it can't reasonably copy something it has no knowledge about how it was allocated
[19:46:47 CEST] <nevcairiel> if you c hange that function as proposed, half of avcodec/ffmpeg  will cease to function
[19:46:55 CEST] <nevcairiel> and plenty user apps as well
[19:47:15 CEST] <BtbN> hm, so only putting the free behind that is?
[19:47:24 CEST] <BtbN> Is there a way to test if a pointer was allocated by us?
[19:47:56 CEST] <BtbN> The immediate fix would be to not have extradata in codecpar
[19:47:59 CEST] <nevcairiel> should just document that extradata should be allocated with av_malloc like many other fields in various structs
[19:48:11 CEST] <nevcairiel> and where would that be then?
[19:48:13 CEST] <nevcairiel> thats no fix
[19:48:16 CEST] <nevcairiel> its a mandatory field
[19:48:21 CEST] <nevcairiel> it needs to be there
[19:49:26 CEST] <BtbN> Well, that mozilla code is setting it right on the context
[19:49:50 CEST] <BtbN> Which is why it explodes in the first place, because it's about to be overwritten with whatever was set in codecpar
[19:53:37 CEST] <BtbN> But yeah, the only safe and version-compatible way to fix this is Mozilla allocating the memory with av_malloc
[19:53:40 CEST] <nevcairiel> the only future-proof solution is to j ust documented the requirement, because in reality it has practically been required in a wide number of cases already
[19:55:44 CEST] <jamrial> JEEB: fate passes
[19:56:05 CEST] <jamrial> sorry for the delay, i forgot i left it running
[19:57:01 CEST] <JEEB> no problemos
[19:57:17 CEST] <JEEB> I will push it then because it fixes an issue we've had with this thing for ages with regards to f.ex. B-frames
[19:57:46 CEST] <JEEB> since it has no concept of edit lists + implementations always add the initial CTS offset to the fragment timestamp
[19:58:01 CEST] <durandal_1707> atomnuker: i will not use for (int ...) hack
[19:58:05 CEST] <JEEB> so you got delicious double b-frame A/V sync delay
[20:02:21 CEST] <cone-094> ffmpeg 03Jan Ekström 07master:1931761f18cd: avformat/movenc: implicitly enable negative CTS offsets for ismv
[20:02:30 CEST] <JEEB> there
[20:02:44 CEST] <atomnuker> durandal_1707: not a hack, its valid c and saves lines
[20:02:56 CEST] <atomnuker> and looks better
[20:04:19 CEST] <durandal_1707> atomnuker: its a hack
[20:06:55 CEST] <kierank> durandal_1707: what is
[20:07:02 CEST] <kierank> I shall be the judge jury and executioner
[20:07:37 CEST] <kierank> oh
[20:07:39 CEST] <kierank> that's not a hack
[20:07:40 CEST] <kierank> it's nie
[20:07:43 CEST] <kierank> nice
[20:07:48 CEST] <kierank> it keeps i in the right scope
[20:25:20 CEST] <baptiste> JEEB, how is ctts version 1 support nowadays ?
[20:26:34 CEST] <JEEB> baptiste: pretty much everything supports them since DASH IF etc recommend their usage
[20:26:44 CEST] <JEEB> because everyone seems to hate edit lists
[20:27:02 CEST] <JEEB> so if you can have CTS == DTS for initial sample, everyone seems to love that
[20:27:29 CEST] <JEEB> in other words, anything that does web streaming with MPEG-DASH/fmp4 HLS better support it
[20:28:51 CEST] <baptiste> yeah edit lists are not the best
[20:29:08 CEST] <baptiste> but negative ctts, make pts < dns which is an abberation
[20:29:45 CEST] <JEEB> yea, it's esp. fun when something takes in your negative cts offsets and muxes them straight into mpeg-ts
[20:29:50 CEST] <JEEB> like apple seemingly did
[20:30:00 CEST] <JEEB> https://kuroko.fushizen.eu/screenshots/apple_mpegts/nice_timestamps_there.png
[20:30:12 CEST] <JEEB> I complained to a vendor and they linked me this Apple HLS sample
[20:30:36 CEST] <JEEB> "apple is doing this too so it's OK to do DTS > PTS in MPEG-TS
[20:31:27 CEST] <JEEB> at which point I kind of wanted to laugh and cry, and decided that I'll get back to them later
[20:31:28 CEST] <baptiste> humm that's weird
[20:31:57 CEST] <baptiste> that's in clear violations of the specs
[20:32:01 CEST] <JEEB> yes, yes it is
[20:32:14 CEST] <JEEB> but it seems like various vendors that take in ISOBMFF with negative cts offsets (and recommend it, even) do this
[20:32:27 CEST] <JEEB> when they re-multiplex to HLS
[20:32:47 CEST] <baptiste> that's an oversight not supporting ctts version 1 and not offsetting dts/pts
[20:32:52 CEST] <baptiste> and/or
[20:33:01 CEST] <baptiste> Im sure apple can fix that
[20:33:07 CEST] <baptiste> if asked nicely
[20:33:22 CEST] <JEEB> basically people saw apple fucking it up around iOS 5
[20:33:27 CEST] <JEEB> in their samples
[20:33:34 CEST] <JEEB> and decided that this was a-OK and kosher
[20:34:31 CEST] <JEEB> but yea, lesson of the story is that you can't use the CTS/DTS values as-is from negative cts offset stuff
[20:34:37 CEST] <baptiste> qq, do you remember where DASH-IF recommends ctts version 1 ? I might point to it in the future :)
[20:34:42 CEST] <JEEB> sec
[20:36:44 CEST] <JEEB> wbs also wrote it in the docs so it clearly was in there
[20:37:21 CEST] <MoSal> https://bugzilla.mozilla.org/show_bug.cgi?id=1486080
[20:38:27 CEST] <JEEB> baptiste: at least 6.2.5.2 mentions > This requires the use of negative composition offsets
[20:39:04 CEST] <JEEB> > It is strongly recommended that the presentation time offset at the start of each period coincide with the first frame of a segment
[20:39:29 CEST] <JEEB> although I remember it being mentioned elsewhere as well
[20:40:03 CEST] <baptiste> nice
[20:44:38 CEST] <JEEB> MoSal: you can still own it and the user is allocating it, even if you have to utilize the lavc functionality to allocate it
[20:48:31 CEST] <MoSal> JEEB: I will add a comment. Is this accurate:
[20:48:33 CEST] <MoSal> To clarify, the user is still responsible for the data. But allocation/deallocation must be done using av_* functions.
[21:23:58 CEST] <cone-094> ffmpeg 03Paul B Mahol 07master:aba720dce236: avcodec: add Brooktree ProSumer Video decoder
[21:30:54 CEST] <atomnuker> durandal_1707: you put too many spaces on line 152 of prosumer.c, also you left a bunch of unsigned stuff, no shame in making a commit to fix that, it happens
[21:40:33 CEST] <cone-094> ffmpeg 03Paul B Mahol 07master:4d87cd2882c0: avcodec/prosumer: fix some minor issues
[22:09:08 CEST] <kurosu> durandal_1707, https://pastebin.com/JwXF4RaN
[22:09:24 CEST] <kurosu> first column = codec, first row = implementation
[22:09:34 CEST] <kurosu> m = master (of the time I did the test)
[22:09:41 CEST] <kurosu> g = libav bitstream reader
[22:10:07 CEST] <kurosu> f = g + 32bits cache and reader adaptation
[22:10:44 CEST] <kurosu> prores needed more fixes at the time because of a function bent on reading 32 bits, which required more adaptation
[22:12:00 CEST] <kurosu> got magicyuv down to ~3.3s using ffvhuff dual vlc tables
[22:13:42 CEST] <durandal_1707> you can now fork
[22:14:30 CEST] <durandal_1707> why dual vlc tables gives so big gain?
[22:16:08 CEST] <kurosu> lots of small codewords, so you spend lots of time iterating bitstream reading
[22:16:30 CEST] <kurosu> using dual tables, you can output 2 symbols at a time (or more...)
[22:17:02 CEST] <kurosu> of course, if your source is very noisy and the shortest vlcs are very large, that doesn't work
[22:17:55 CEST] <kurosu> also work in utvideo
[22:18:15 CEST] <atomnuker> what does reader adaptation mean?
[22:20:12 CEST] <kurosu> cache being 32bits, you need to refill it slightly differently
[22:20:56 CEST] <kurosu> and there's benefit in having intermediate reader sizes if you know the max size of your codewords
[22:21:08 CEST] <durandal_1707> so for x32 it is 32 and for x64 remain 64 bits?
[22:21:16 CEST] <kurosu> with 64b cache and arithmetics, this is almost free
[22:21:23 CEST] <kurosu> yeah
[22:21:56 CEST] <kurosu> the issue of the cache reader with x32 is that it requires 64b arithmetics, which is split by the compiler in several 32b operations
[22:22:11 CEST] <nevcairiel> one of the problems with the libav  reader was that they also changed the API and re-defined it so that the short read could read more then a 32-bit cache driven API could really provide
[22:22:13 CEST] <kurosu> and when you are already under reg pressure such as on x86_32...
[22:22:25 CEST] <nevcairiel> but pauls version just changed the internals, so that was avoided
[22:23:19 CEST] <kurosu> I don't remember if I was ricing or not concerning those 32b adaptations
[22:23:46 CEST] <kurosu> I'm pretty sure some golomb reading function was not working with 32b cache
[22:25:10 CEST] <kurosu> for prores, I moved to VLCs, but then atomnuker moved such code to byte-based reading in vc2 iirc
[22:25:29 CEST] <kurosu> never tried to adapt this to prores, which iirc also use EG codes
[22:26:51 CEST] <atomnuker> right, for dirac golomb reading you couldn't use the standard VLC reader so I nih'd a lut-based one
[22:26:52 CEST] <kurosu> sad thing is that even 1GB of data takes only a few seconds to decode on 1 thread, once the data is in memory
[22:27:57 CEST] <kurosu> (well it's good, but that means you are very sensitive to measure error and at some point this is the HD that limits decoding speed)
[22:27:59 CEST] <atomnuker> the reason why you couldn't was because there are far too many codes, and they may be arbitrarily long, 64 bits+
[22:28:21 CEST] <kurosu> I think in prores the cases are far less frequent
[22:28:33 CEST] <kurosu> iirc max of 29b
[22:28:48 CEST] <kurosu> not guaranteed, but never encountered anything else
[22:29:48 CEST] <kurosu> dct => max 12b coeffs (or 14?), and the golomb orders are fixed, so the theorical limit is probably close, but I never computed it
[22:29:56 CEST] <kurosu> or I did, but I'm not sure
[22:30:54 CEST] <kurosu> yeah, prores ac coeffs only need in 6 VLCs for the useful orders
[22:31:26 CEST] <kurosu> probably some are indeed unusable, but those are very rare, so switching between VLC and current code is still a win
[22:34:21 CEST] <atomnuker> nevcairiel: short read?
[22:34:37 CEST] <kurosu> nevcairiel, yeah, I was more interested in proof of concept
[22:34:42 CEST] <kurosu> atomnuker, <25 bits iirc
[22:34:56 CEST] <nevcairiel> well thats not a problem this time around anyway
[22:35:01 CEST] <nevcairiel> since we kept our API
[22:35:24 CEST] <kurosu> (or 27)
[22:35:46 CEST] <nevcairiel> its <= 25 right now iirc, and the libav version extended it to full 32
[22:36:15 CEST] <nevcairiel> but since we didnt go with that, only a historical comment
[22:36:25 CEST] <kurosu> I think current solution is nice, as you can enable it on a case-by-case basis, which can include !ARCH_X86_32
[22:36:44 CEST] <kurosu> current=durandal_1707's
[22:37:06 CEST] <nevcairiel> we always lobbyed for keeping the current ABI and just changing the internals, potentially macro controlled
[22:37:11 CEST] <nevcairiel> but they didnt like that for reasons
[22:37:14 CEST] <nevcairiel> API*
[22:37:45 CEST] <atomnuker> I'd rather switch over fully to using the cached reader with the changes needed to make it fast on 32bits
[22:38:45 CEST] <kurosu> I may have my share of bad communication on this topic, but I really felt down when I saw the topic change into "us vs them"
[22:39:44 CEST] <kurosu> (or at least some people seemed to have behaved as if this was their perception of the discussion)
[22:41:07 CEST] <atomnuker> I don't mind gradually enabling it on a case by case basis though, since it would be a lot of work to verify all codecs work
[22:42:53 CEST] <durandal_1707> some codecs, like ffvhuff cant use it because it use pesky macros of old reader
[22:43:45 CEST] <kurosu> yeah, I had extracted and converted its dual vlc table reading as a module for use by other codecs for that very reason
[22:44:47 CEST] <durandal_1707> may I ask, how much do you ask for your troubles?
[22:46:44 CEST] <kurosu> I did it knowing I couldn't publish them
[22:47:14 CEST] <kurosu> trying to fix that, but that may take time or even never done
[22:47:57 CEST] <kurosu> so here, I'm not selling anything, just discussing on a topic I personally like
[22:48:31 CEST] <durandal_1707> you should sell, people sell even much less useful stuff
[22:55:17 CEST] <atomnuker> but the most useful stuff they give away for free
[22:56:15 CEST] <durandal_1707> like boring company flamethrowers
[00:00:00 CEST] --- Sat Aug 25 2018