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

[burek]

[00:01:43 CEST] <durandal_170> atomnuker: some kind of multiply blend
[00:03:30 CEST] <atomnuker> oh
[00:03:45 CEST] <atomnuker> something to do with complex -> real maybe?
[00:19:13 CEST] <durandal_170> atomnuker: i now know how to get each quadrant intact
[00:21:48 CEST] <atomnuker> cool, so you got it working?
[00:22:30 CEST] <durandal_170> atomnuker: no, i wonder why i cant get them in one go
[00:51:01 CEST] <durandal_1707> i think i could put other half of frame into im,  what that will do?
[00:59:27 CEST] <thardin> https://www.youtube.com/watch?v=Sx4BVGPkdzk
[00:59:53 CEST] <thardin> derp, wrong channel
[00:59:57 CEST] <thardin> well, still relevant of course
[01:01:31 CEST] <thardin> for there may lurk centrists everywhere that need their political radar calibrated for these times
[01:02:21 CEST] <durandal_1707> hard times
[01:02:36 CEST] <thardin> hard, like bepis
[01:15:38 CEST] <atomnuker> rcombs: so what's left to do with the flac pic embedding patch?
[01:15:54 CEST] <rcombs> uhhh
[01:16:01 CEST] <rcombs> there might've been an error handling thing
[01:16:48 CEST] <atomnuker> I know someone who would know
[01:16:52 CEST] Action: atomnuker summons jamrial
[01:25:33 CEST] <jamrial> i replied to the latest version mentioning what was left to do
[01:31:50 CEST] <iive> thardin: I like that video. I've picked up most of these things, but it is nice to see them all in one place. 
[02:07:19 CEST] <thardin> yes
[02:15:15 CEST] <thardin> yikes, it's late
[02:32:10 CEST] <cone-223> ffmpeg 03Michael Niedermayer 07release/2.8:498e07daa18c: avformat/hls: Fix DoS due to infinite loop
[02:32:10 CEST] <cone-223> ffmpeg 03Yi and  *®() 07release/2.8:6904464301bb: avformat/asfdec: Fix DoS due to lack of eof check
[02:32:10 CEST] <cone-223> ffmpeg 03Yi and  *®() 07release/2.8:c70fdd994808: avformat/cinedec: Fix DoS due to lack of eof check
[02:32:10 CEST] <cone-223> ffmpeg 03Yi and  *®() 07release/2.8:1720050ae6eb: avformat/rl2: Fix DoS due to lack of eof check
[02:32:10 CEST] <cone-223> ffmpeg 03Michael Niedermayer 07release/2.8:6b004e23d7fc: avformat/mvdec: Fix DoS due to lack of eof check
[02:32:11 CEST] <cone-223> ffmpeg 03Michael Niedermayer 07release/2.8:2ff2402c65dc: avcodec/sbrdsp_fixed: Fix undefined overflows in autocorrelate()
[02:32:11 CEST] <cone-223> ffmpeg 03Michael Niedermayer 07release/2.8:1a5b9b3b8eb5: avcodec/hevc_ps: Fix undefined shift in pcm code
[02:32:12 CEST] <cone-223> ffmpeg 03Michael Niedermayer 07release/2.8:74429912dcd7: avcodec/snowdec: Fix integer overflow in decode_subband_slice_buffered()
[02:32:12 CEST] <cone-223> ffmpeg 03Yi(SÑ) 07release/2.8:5b3986023bbf: avformat/nsvdec: Fix DoS due to lack of eof check in nsvs_file_offset loop.
[02:32:13 CEST] <cone-223> ffmpeg 03Yi(SÑ) 07release/2.8:accf7d34a882: avformat/mxfdec: Fix DoS issues in mxf_read_index_entry_array()
[02:32:14 CEST] <cone-223> ffmpeg 03Yi(SÑ) 07release/2.8:d68602650766: avformat/mxfdec: Fix Sign error in mxf_read_primer_pack()
[02:32:15 CEST] <cone-223> ffmpeg 03Michael Niedermayer 07release/2.8:7f0359f05e32: Changelog: Update
[02:57:52 CEST] <cone-223> ffmpeg 03James Almer 07n2.8.13:HEAD: avcodec/internal: move FF_QSCALE_TYPE defines from avcodec.h
[03:12:50 CEST] <rpw> how can I retrieve the SwsFilter src and dst vars used to init an SwsContent?
[11:34:56 CEST] <durandal_170> atomnuker: got it working with NxN images, broken with MxN images
[13:21:43 CEST] <durandal_170> atomnuker: dunno with what to pad edges of NxM matrix when doing 2d fft
[13:28:07 CEST] <BtbN> Is there some easy way to hand-edit h264 bitstream?
[13:29:19 CEST] <durandal_170> yes, hex editor
[13:30:45 CEST] <BtbN> How would I possibly fine a few single bit values with a plain hex editor?
[13:30:49 CEST] <BtbN> *find
[13:32:14 CEST] <durandal_170> there are editors with search funcionality afaik
[13:36:27 CEST] <BtbN> The only one I found was 300¬
[13:40:26 CEST] <Blubberbub> hexdump + grep?
[13:41:06 CEST] <durandal_170> do you really neeed searching by bits and not by hex?
[13:41:19 CEST] <BtbN> The SPS is a bitstream
[13:41:26 CEST] <BtbN> I definitely need to find the right bits
[13:41:34 CEST] <durandal_170> how many of them?
[13:41:35 CEST] <BtbN> and their position changes, depending on how some other bits are set or not set
[13:41:47 CEST] <BtbN> I want to edit the timing_info in the VUI
[13:42:11 CEST] <durandal_170> write bitstream filter :)
[13:42:13 CEST] <BtbN> which is two 32bit unsigned values
[13:42:27 CEST] <jkqxz> Already exists.  h264_metadata, tick_rate option: <https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-August/215070.html>.
[13:48:04 CEST] <BtbN> git am does not like that at all, weird
[13:48:46 CEST] <BtbN> oh, it needs WAY more patches
[13:59:34 CEST] <durandal_170> atomnuker: see this line: https://github.com/richardpl/FFmpeg/blob/8815496c60d52a5af4bfd12eadc1a9cd1da2d16d/libavfilter/vf_convolve.c#L170
[13:59:54 CEST] <durandal_170> with what to fill that, its only active for MxN case
[14:02:29 CEST] <durandal_170> hm, i got idea
[14:06:56 CEST] <ubitux> any objection to the autodetect patchset?
[14:07:10 CEST] <ubitux> it's been 3days (+previous version of the patchset)
[14:26:00 CEST] <wm4> just push it
[14:30:34 CEST] <JEEB> the change seems pretty good, I just haven't been able to build with the patch
[14:30:52 CEST] <JEEB> which I think I'm going to fix now :3
[14:31:02 CEST] <ubitux> i'm not sure how to interpret that 2nd part of your sentence
[14:31:28 CEST] <ubitux> "i still didn't manage to get your patch working, LGTM"
[14:31:41 CEST] <nevcairiel> sounds more like "i just didnt test it"
[14:31:48 CEST] <JEEB> no, more like "I didn't have the time to get the patch and build with it"
[14:31:56 CEST] <JEEB> which is something I'm going to fix now :P
[14:32:01 CEST] <ubitux> :)
[14:32:17 CEST] <JEEB> btw, since it's a patch set - do you have a remote I can pull them from :D
[14:32:30 CEST] <JEEB> or do I just curl them from patchwork
[14:32:31 CEST] <JEEB> :3
[14:32:43 CEST] <JEEB> (if you have a remote I can fetch them from with git that'd be simpler)
[14:33:10 CEST] <ubitux> git remote add ubitux git at github.com:ubitux/FFmpeg
[14:33:15 CEST] <ubitux> git fetch ubitux
[14:33:19 CEST] <JEEB> merci
[14:33:19 CEST] <ubitux> git checkout autodetect
[14:34:51 CEST] <JEEB> merged to current master (only thing conflicting was Changelog and that was simple)
[14:35:57 CEST] <nevcairiel> i really like the --disable-autodetect option, so thanks for that :)
[14:36:00 CEST] <JEEB> yea
[14:36:19 CEST] <JEEB> the iconv is the thing nicholas commented about wrt stdlib I guess?
[14:36:34 CEST] <ubitux> nevcairiel: np
[14:36:41 CEST] <ubitux> JEEB: yep, see the comment on the patchset
[14:36:46 CEST] <ubitux> s/comment/first mail/
[14:36:49 CEST] <JEEB> yea
[14:37:28 CEST] <ubitux> just updated the tree rebased on master
[14:37:58 CEST] <JEEB> also darn it, you had mentioned the github tree in the quoted part of your mail :)
[14:38:03 CEST] Action: JEEB is blind
[14:38:10 CEST] <ubitux> :)
[14:44:37 CEST] <BtbN> discovery of the day: Setting a nonsensical framerate for testing to nvenc, when in interlaced encoding mode, crashes the driver
[14:44:52 CEST] <BtbN> It really does not like 65k fps it seems
[14:57:46 CEST] <JEEB> ubitux: added my useless +1 to the thread ;)
[14:58:09 CEST] <ubitux> great, thanks
[14:58:23 CEST] <ubitux> i'll give it maybe half an hour to 1h and push 
[15:28:56 CEST] <kurosu> jkqxz, btw, what's the status of your (cbs) patchset ?
[15:29:52 CEST] <kurosu> (waiting reviews I guess)
[15:32:04 CEST] <jkqxz> Michael made some useful comments; there are some new changes on the libav list, once they go through I'll merge and send a new set.
[15:48:09 CEST] <BtbN> Any h264 expert here? How essential is the picture timing SEI for interlaced content. It seems to contain the information about the field order, so it seems important to me?
[15:48:35 CEST] <nevcairiel> field order can also be derived through other means
[15:48:52 CEST] <nevcairiel> at least in PAFF
[15:49:05 CEST] <nevcairiel> (ie. field coded)
[15:51:42 CEST] <BtbN> Yeah, that's what nvenc does. One Picture-Slice per field. So it encodes them as seperate "frames" I guess
[15:51:54 CEST] <BtbN> If you ask it to do MBAFF, it fails to initialize
[15:52:00 CEST] <jkqxz> It is required if pic_struct_present_flag is 1 (see D.2.3).
[15:52:19 CEST] <BtbN> It does set that to 0 if the timing SEI is disabled
[15:52:21 CEST] <nevcairiel> in paff you can derive the field order from the POC i believe
[15:52:21 CEST] <BtbN> and to 1 if you enable it
[15:52:33 CEST] <nevcairiel> but its probably better to just emit the SEI if it can do that
[15:52:40 CEST] <jkqxz> If you set pic_struct_present_flag to 0 then there are some fixed rules for how the pic_struct is worked out.
[15:53:18 CEST] <BtbN> https://github.com/BtbN/FFmpeg/commit/0d49f7df3104085075316cce18e9fcc4a299ddf5 the patch is rather trivial
[15:53:27 CEST] <BtbN> I guess it won't hurt to just enable it
[15:53:38 CEST] <nevcairiel> i would just make it output that all the time
[15:54:15 CEST] <BtbN> for some weird reason strict CBR is tied to it
[15:54:37 CEST] <BtbN> Like, if you enable that SEI, it will emit filler data to reach the target bitrate in CBR mode
[15:54:41 CEST] <BtbN> without that SEI, it won't
[15:58:12 CEST] <jkqxz> The HRD conformance definition depends on the SEI timing messages.
[15:58:20 CEST] <jkqxz> So it's probably a consequence of that.
[15:59:59 CEST] <BtbN> hm, I suppose it can safely be emited though. It's enabled for CBR anyway.
[16:00:53 CEST] <jkqxz> Yeah, most things just ignore them.  The one painful case is RTP transport, when they end up increasing the packet rate.
[16:01:05 CEST] <jkqxz> Because of how the packetisation works.
[16:03:09 CEST] <BtbN> Currently trying to figure out why interlaced output with nvenc is subtly broken in some player.
[16:03:12 CEST] <BtbN> Namely in WMP
[16:04:01 CEST] <nevcairiel> define subtly
[16:04:22 CEST] <nevcairiel> the MS h264 decoder is usually not bad as long as you stay within its supported profiles
[16:05:12 CEST] <BtbN> It looks like it's stuttering.
[16:05:18 CEST] <BtbN> Like, 30 FPS instead of 60
[16:05:42 CEST] <BtbN> If I encode with libx264, everything is fine. Encoding with nvenc produces that stuttering
[16:06:13 CEST] <BtbN> The biggest difference is that the libx264 and the original sample use MBAFF. And nvenc uses seperate fields
[16:06:28 CEST] <BtbN> And that nvenc wasn't outputting timing SEIs. Which it is now
[16:06:33 CEST] <BtbN> but still unsmooth
[16:07:09 CEST] <nevcairiel> are the timestamps proper then for the separate fields?
[16:07:41 CEST] <BtbN> That's a good question. Are there even timestamps in the h264 bitstream?
[16:08:45 CEST] <nevcairiel> kind of, but thats not what I was referring to, its still the encoders job to make proper encoded timestamps, especially if you handle field-coded interlaced, since you have twice as many output "fields" then you had input frames
[16:09:20 CEST] <cone-811> ffmpeg 03Timo Rothenpieler 07master:4e6638abb4fc: avcodec/nvenc: always output picture timing SEI
[16:09:33 CEST] <ubitux> fits tests are broken or that's me?
[16:09:44 CEST] <nevcairiel> its broken
[16:10:12 CEST] <ubitux> ok
[16:10:25 CEST] <jkqxz> The pic_timing SEI contains relative timestamps, if it looks at them.  The container timestamps are more likely to be relevant, though.
[16:10:51 CEST] <BtbN> nevcairiel, I have actually no idea how nvenc returns those two seperate fields. There is no logic to double timestamps in interlaced encoding mode.
[16:11:02 CEST] <BtbN> So I guess it returns two of them at a time, and they only get one timestamp?
[16:11:25 CEST] <nevcairiel> avcodecs problem is that with the "old" internal API you can't output two packets for one input frame,  but the new API at least can do that now
[16:11:38 CEST] <BtbN> nvenc is using the old API
[16:11:39 CEST] <BtbN> and it works
[16:11:49 CEST] <BtbN> So it must be outputting the two slices as one frame at once
[16:11:51 CEST] <nevcairiel> well probably because it just throws both fields into one packet
[16:12:03 CEST] <nevcairiel> so they get one timestamp
[16:12:08 CEST] <nevcairiel> which might throw the decoder off
[16:12:13 CEST] <BtbN> I have no idea how I could possibly fix that
[16:12:21 CEST] <nevcairiel> a proper field-coded h264 stream has distinct timestamps for the fields
[16:15:07 CEST] <BtbN> the nvenc API can only output exactly one packet per input frame
[16:15:20 CEST] <BtbN> So I guess it has to put the two seperate fields into a single packet
[16:16:48 CEST] <cone-811> ffmpeg 03Clément BSsch 07master:e70e2a7abdd4: build: group z libs with other autodetected libraries
[16:16:49 CEST] <cone-811> ffmpeg 03Clément BSsch 07master:55fdfc88b844: build: treat crystalhd like other hwaccels
[16:16:50 CEST] <cone-811> ffmpeg 03Clément BSsch 07master:c9075d2c652b: build: treat iconv like other autodetected libraries
[16:16:51 CEST] <cone-811> ffmpeg 03Clément BSsch 07master:1c08ff08adc4: build: treat libxcb like other autodetected libraries
[16:16:52 CEST] <cone-811> ffmpeg 03Clément BSsch 07master:72655616d9d1: build: treat securetransport and schannel like other autodetected libraries
[16:16:53 CEST] <cone-811> ffmpeg 03Clément BSsch 07master:778fa6350e24: build: isolate sdl-to-sdl2 aliasing
[16:16:54 CEST] <cone-811> ffmpeg 03Clément BSsch 07master:b802971d6db5: build: treat sdl2 like other autodetected libraries
[16:16:55 CEST] <cone-811> ffmpeg 03Clément BSsch 07master:353c2e384c70: build: replace use of HAVE_SDL2 with existing CONFIG_SDL2
[16:16:56 CEST] <cone-811> ffmpeg 03Clément BSsch 07master:7e98c3cbb372: build: remove vda_framework from enable_weak
[16:16:57 CEST] <cone-811> ffmpeg 03Clément BSsch 07master:9ef5a2f5f30b: build: simplify weak-enabling of autodetected libraries
[16:16:58 CEST] <cone-811> ffmpeg 03Clément BSsch 07master:e3c1219c7c74: build: add --disable-autodetect switch
[16:16:59 CEST] <cone-811> ffmpeg 03Clément BSsch 07master:fe9c85e4e265: build: make sure a disabled autodetect still pick the libc's iconv
[16:17:00 CEST] <cone-811> ffmpeg 03Clément BSsch 07master:b447629093d7: build: make alsa part of the autodetected libraries
[16:17:01 CEST] <cone-811> ffmpeg 03Clément BSsch 07master:b7fbb3516a99: build: make jack part of the autodetected libraries
[16:17:02 CEST] <cone-811> ffmpeg 03Clément BSsch 07master:e090e750bac8: build: make sndio part of the autodetected libraries
[16:17:03 CEST] <cone-811> ffmpeg 03Clément BSsch 07master:69e6877de8ad: build: drop unused sndio_h and asoundlib_h
[16:17:11 CEST] <BtbN> nice
[16:17:22 CEST] <JEEB> \o/
[16:20:37 CEST] <BBB> ubitux: sweet!
[16:20:47 CEST] <durandal_170> HURRAY!!
[16:21:02 CEST] <BBB> (Ive been compilig binaries with combinations of disable-abcdefghijklmnop for years now, this makes it so much easier)
[16:21:08 CEST] <ubitux> it would be nice to have the pthread thing handled correctly though
[16:21:29 CEST] <BBB> you said lets get this in and make the pthread portion perfect later, and I think you got that exactly right
[16:21:37 CEST] <BBB> or something like that
[16:21:50 CEST] <ubitux> yeah
[16:22:26 CEST] <BBB> "libpthread" vs "pthread" is still not handled, but that's not blocking
[16:22:27 CEST] <BBB> for this patchset. Actually, I'd rather have it pushed before messing
[16:22:28 CEST] <BBB> around with something sensible like pthread.  ubitux, 8/30/17
[16:22:36 CEST] <BBB> just to make sure I got that quote right :-p
[16:22:42 CEST] <ubitux> :)
[16:22:49 CEST] <BBB> again, thank you, I love this patchset
[16:22:56 CEST] <BBB> purely selfish, but still
[16:22:59 CEST] <ubitux> np, glad it helps
[16:23:28 CEST] <nevcairiel> indeed, can probably rip out a bunch of nonsense from various build scripts, and worry less in the future
[16:23:33 CEST] <BBB> does anyone have major objections to the execute3 patch to have a main function in the slice threading for avcodec?
[16:23:50 CEST] <nevcairiel> what exactly does that do? execute a follow up function after the threads finish?
[16:24:00 CEST] <BBB> alongside
[16:24:09 CEST] <BtbN> nevcairiel, I wonder if nvenc expects to get seperate fields as input in the first place?
[16:24:14 CEST] <BBB> in vp9, the tile (~~ slice) threads work on separate units
[16:24:21 CEST] <BBB> but the loopfilter works in the main function
[16:24:33 CEST] <nevcairiel> BtbN: that would be weird, barely anthing ever handles lonely fields in raw
[16:24:34 CEST] <BBB> you can either do that after-the-fact, or (this is better for caching) alongside the tile threads
[16:24:49 CEST] <BBB> so thats 1 main function (since lpf crosses tile boundaries)
[16:25:01 CEST] <BBB> its very strange, I admit
[16:25:24 CEST] <BtbN> nevcairiel, hm, specially as it has a flag on the frames, which reads NV_ENC_PIC_STRUCT_FIELD_TOP_BOTTOM ot BOTTOM_TOP
[16:25:25 CEST] <BtbN> not TOP or BOTTOM
[16:26:25 CEST] <ubitux> BBB: i think so cleanups are still required for the videotoolbox and avfoundation stuff
[16:26:29 CEST] <ubitux> you may want to have a look
[16:26:41 CEST] <nevcairiel> BBB: so it executes them tile by tile as the tiles finish, instead of in one go afterwards?
[16:26:52 CEST] <BBB> nevcairiel: row-by-row
[16:27:00 CEST] <BBB> nevcairiel: lpf has no tile awareness, it crosses tile boundaries
[16:27:09 CEST] <BBB> nevcairiel: imagine you have 4 tile columns, 4 threads
[16:27:10 CEST] <BtbN> nevcairiel, if I output to raw h264, and then re-mux that with ffmpeg. It should "fix" it, right?
[16:27:10 CEST] <nevcairiel> oh well, same thing, just more granularity
[16:27:16 CEST] <BBB> as each finishes row1, the loopfilter for row1 can execute
[16:27:19 CEST] <BBB> yes
[16:27:32 CEST] <nevcairiel> what thread does it run on? does it make its own? take one from the pool?
[16:27:46 CEST] <ubitux> typically, videotoolbox is *not* part of auto lib list (but is marked as autodetect), but there is that videotoolbox_hwaccel thing 
[16:27:54 CEST] <ubitux> which is inconsistent with all other hwaccel
[16:27:58 CEST] <nevcairiel> BtbN: not sure if its smart enough to make new timestamps
[16:28:06 CEST] <BBB> -threads N creates N-1 threads without this, and the last thread runs in the main function (since execute() blocks anyway)
[16:28:08 CEST] <ubitux> (it's also in a weird place)
[16:28:12 CEST] <BtbN> nevcairiel, there are no timestamps in raw h264 though?
[16:28:16 CEST] <BtbN> so it has to
[16:28:22 CEST] <nevcairiel> well not hard to try
[16:28:23 CEST] <BBB> so with this, -threads N creates N threads and the main function (which is supposed to block) calls this extra function
[16:28:39 CEST] <BtbN> nevcairiel, it does indeed fix it
[16:28:42 CEST] <BBB> so it sort of creates an extra thread, I guess
[16:28:53 CEST] <nevcairiel> BBB: i see
[16:29:01 CEST] <BBB> ubitux: I believe vtb is autodetected
[16:29:10 CEST] <BBB> ubitux: at least for me it always is compiled in I think?
[16:29:18 CEST] <BBB> (on a mac)
[16:29:21 CEST] <ubitux> maybe, but it's inconsistent
[16:29:33 CEST] <ubitux> as a result it may not be disabled by --disable-autodetect
[16:29:37 CEST] <ubitux> you may want to check
[16:29:48 CEST] <BBB> ah I see what you mean
[16:29:51 CEST] <BBB> okiedokie I shall check
[16:30:11 CEST] <nevcairiel> BBB: i havent looked at the code but if it helps to boost performance, it should be fine
[16:30:18 CEST] <ubitux> pretty sure you want to drop videotoolbox from EXTERNAL_LIBRARY_LIST, and rename videotoolbox_hwaccel to videotoolbox in HWACCEL_AUTODETECT_LIBRARY_LIST
[16:30:28 CEST] <ubitux> (and fix the rest of the configure)
[16:30:37 CEST] <BBB> you know configure is black magic for me, right?
[16:30:45 CEST] <BBB> I know just enough python to do a 3-line script
[16:30:46 CEST] <ubitux> compare with other hwaccel
[16:30:51 CEST] <BBB> my shell scripting is worse :-p
[16:31:02 CEST] <BBB> hm Ill look
[16:31:04 CEST] <ubitux> i'm guessing audiotoolbox is a good reference point
[16:31:10 CEST] <BBB> Ill ask many stupid questions
[16:31:12 CEST] <BBB> just so you know
[16:31:15 CEST] <ubitux> sure
[16:32:13 CEST] <BBB> so disable-autodetect should disable everything like x, vda, vtb, etc., right?
[16:32:19 CEST] <BBB> so only c, m and pthreads are left
[16:32:22 CEST] <BBB> and ld
[16:32:33 CEST] <ubitux> ideally yes
[16:33:05 CEST] <ubitux> i have tested on mac so a bunch of other stuff may still be in (such as VT as i mentioned)
[16:33:13 CEST] <ubitux> have not*
[16:34:45 CEST] <BBB> Enabled indevs:
[16:34:45 CEST] <BBB> avfoundation		  lavfi
[16:34:49 CEST] <BBB> I guess that is the problem?
[16:35:01 CEST] <ubitux> lavfi is fine, avfoundation isn't
[16:35:05 CEST] <BtbN> hm, I cannot think of a way to fix this. Without moving nvenc to the new API
[16:35:08 CEST] <ubitux> avfoundation is another thing than videotoolbox btw
[16:35:13 CEST] <ubitux> it's even higher level
[16:35:31 CEST] <nevcairiel> avfoundation is probably not handled the same way as anything else, i remember it having special dealys everywhere because of its ObjC mess
[16:35:43 CEST] <ubitux> yeah 
[16:35:52 CEST] <ubitux> it's in the "external library" things
[16:35:55 CEST] <ubitux> for some reason
[16:36:00 CEST] <BBB> vtb is properly disabled
[16:36:16 CEST] <BBB> and the vtb hwaccel is also
[16:37:39 CEST] <BBB> its called avfoundation_index
[16:37:48 CEST] <BBB> do I need to add it to some list to get autodetect-disable to work?
[16:38:21 CEST] <ubitux> i think it needs to be split avfoundation + avfoundation_indev 
[16:38:30 CEST] <ubitux> avfoundation_indev with a deps on avfoundation
[16:38:37 CEST] <ubitux> and avfoundation in the autodetect list with the others
[16:39:01 CEST] <ubitux> and the weird avfoundation_indev checks move earlier with the other autodetect stuff
[16:40:07 CEST] <ubitux> that stuff is weirdly done ;)
[16:40:57 CEST] <BBB> let me see if I understand this...
[16:41:02 CEST] <BBB> Im testing random stuff
[16:41:04 CEST] <BBB> no idea what Im doing
[16:41:17 CEST] <ubitux> i'm sure you're having a lot of fun
[16:44:08 CEST] <BBB> thats a pretty broad definition of fun :-p
[16:48:18 CEST] <BBB> ok, so
[16:48:21 CEST] <BBB> it works partially
[16:48:25 CEST] <bove> I am creating a decoder for a raw-ish format, and am trying to understand what's the absolute minimum for a decode function. Am I correct that the input comes from avpkt->data and the output is set to data->data?
[16:48:39 CEST] <BBB> vda is disabled
[16:48:43 CEST] <BBB> vtb is disabled
[16:48:45 CEST] <BBB> avf is disabled
[16:48:46 CEST] <BBB> but
[16:48:54 CEST] <BBB> -framework QuartzCore is still part of EXTRALIBS
[16:48:56 CEST] <BBB> why?!?
[16:50:25 CEST] <BBB> qtkit is also disabled btw
[16:50:42 CEST] <atomnuker> bove: yes, the data argument in the decode function you need to cast to an AVFrame and then write to its data fields
[16:50:52 CEST] <BBB> ah, coreimage
[16:50:54 CEST] <BBB> what is coreimage?
[16:50:59 CEST] <atomnuker> you also need to set *got_frame = 1 to indicate you have something to output
[16:51:28 CEST] <atomnuker> (and you also need to call ff_get_buffer to allocate the data fields in the avframe before you start decoding to them)
[16:51:45 CEST] <BBB> let me try again with coreimage added to that list also
[16:54:17 CEST] <BBB> crap, almost
[16:54:26 CEST] <BBB> left with CoreGraphics and CoreServices
[16:55:41 CEST] <BBB> huh
[16:55:42 CEST] <BBB> check_lib coreservices "CoreServices/CoreServices.h" UTGetOSTypeFromString "-framework CoreServices"
[16:55:46 CEST] <BBB> thats just there unconditionally
[16:55:49 CEST] <BBB> does anyone know why?
[16:57:16 CEST] <BBB> seems part of videotoolbox
[16:58:26 CEST] <BBB> more hackyhack
[16:58:38 CEST] <ubitux> this is just to define HAVE_UTGETOSTYPEFROMSTRING
[16:59:32 CEST] <ubitux> (and actually link to that stuff if available)
[17:01:10 CEST] <BBB> yes
[17:01:11 CEST] <BBB> so
[17:01:12 CEST] <BBB> -framework CoreGraphics
[17:01:16 CEST] <BBB> I still have that
[17:01:21 CEST] <BBB> I dont understand where it comes from
[17:01:32 CEST] <bove> atomnuker: Thanks!!! seems ff_get_buffer() was the missing bit
[17:01:36 CEST] <BBB> Im linking to x264, libvpx and vmaf, but none of them seem to require that
[17:02:24 CEST] <ubitux> what's your diff?
[17:02:44 CEST] <ubitux> coregraphics is triggered by avoundation_indev
[17:03:34 CEST] <BBB> avfoundation is disabled though
[17:03:58 CEST] <BBB> https://pastebin.com/MiXhcbnf
[17:04:46 CEST] <ubitux> you have no check for avfoundation, so it's assumed to be enabled by default
[17:04:55 CEST] <ubitux> so avfoundation_indev deps are satisfied
[17:05:00 CEST] <ubitux> so it checks for coregraphics
[17:05:02 CEST] <ubitux> (wild guess)
[17:05:16 CEST] <BBB> hm...
[17:05:50 CEST] <BBB> isnt avfoundation_indev_deps="pthreads avfoundation" enough?
[17:06:00 CEST] <BBB> so that if avfoundation is disabled, it disabled avfoundation_indev also?
[17:06:30 CEST] <ubitux> i wonder if you shouldn't add `check_header_objcc AVFoundation/AVFoundation.h` to the existing list of all header checks
[17:06:42 CEST] <ubitux> and then avfoundation_indev_deps="pthreads AVFoundation_AVFoundation_h"
[17:07:01 CEST] <BBB> Im not sure I follow :-p
[17:07:10 CEST] <BBB> if avfoundation_indev_deps includes avfoundation
[17:07:18 CEST] <BBB> and avfoundation is in autodetect-list and so disabled
[17:07:24 CEST] <BBB> doesnt that disable the indev?
[17:07:34 CEST] <ubitux> mmh my idea isn't great actually
[17:08:06 CEST] <ubitux> BBB: enabled avfoundation && check_header_objcc AVFoundation/AVFoundation.h || disable avfoundation
[17:08:09 CEST] <ubitux> i guess?
[17:09:04 CEST] <kurosu> I would be interested academically to see a high level representation of what the vp9 frame+tile threading looks like
[17:09:17 CEST] <kurosu> I expect no new threading api ?
[17:09:51 CEST] <kurosu> openhevc's wpp+frame threading introduced a new -thread_type frameslice for that
[17:12:14 CEST] <BBB> kurosu: is not interesting for decoders, honestly
[17:12:30 CEST] <BBB> kurosu: for vp9, for 4k content, frame threading or tile threading only, I can easily get to a few 100 frames/sec
[17:12:36 CEST] <BBB> kurosu: do we really need 10k fps?
[17:12:56 CEST] <BBB> kurosu: for encoders its different
[17:13:11 CEST] <BBB> kurosu: but I feel were solving a problem that isnt really one, for decoders at least
[17:13:35 CEST] <kurosu> isn't it the decoder this threading/patchset applies to ?
[17:13:52 CEST] <BBB> ubitux: still there
[17:14:02 CEST] <BBB> kurosu: yes, but its either slice or frame, not both
[17:14:09 CEST] <kurosu> iirc, slice+frame was done to cope with very low latency and intra frame causing extra delays
[17:14:11 CEST] <BBB> which one you choose depends on latency requirements
[17:14:31 CEST] <ubitux> BBB: you need to figure out the actual dep tree
[17:14:36 CEST] <BBB> ok
[17:14:59 CEST] <ubitux> i'm pretty sure these -framework things should be added automatically if the check_lib so i wonder why they are explicited in the extralibs
[17:15:05 CEST] <kurosu> for hevc and the 40+ Mb/s cabac streams, slice+frame would make more sense
[17:15:24 CEST] <kurosu> (eg uhd bluray, 4K 10bits)
[17:15:32 CEST] <BBB> kurosu: yes, probably
[17:15:33 CEST] <ubitux> nevertheless, the "indev" is a core component, and it depends on various libs/frameworks which should be autodetected
[17:15:44 CEST] <BBB> kurosu: but vp9 doesnt really seem to be going there& plus, theres av1 already :-p
[17:15:53 CEST] <ubitux> so basically avfoundation_indev_deps should point to its actual core deps
[17:16:05 CEST] <BBB> I added avfoundation to avfoundation_indev
[17:16:09 CEST] <ubitux> and the core deps should be tested with enabled <thedep> &&& check <thedep>
[17:16:10 CEST] <BBB> but I think Im screwing something up
[17:16:35 CEST] <ubitux> (...so that they are disabled if unmet)
[17:16:38 CEST] <kurosu> I'm thinking of attending vdd mostly for the av1 panels
[17:16:56 CEST] <ubitux> (and make sure they are disable, because some checks do not automatically disable it, typically when the actual check doesn't match the lib)
[17:16:59 CEST] <ubitux> (such as a header check)
[17:17:19 CEST] <BBB> kurosu: cool, you should :)
[17:17:42 CEST] <BBB> kurosu: please help me push the av1 people to make the panels not just a this is what we added yesterday, but an actual full proposed bitstream overview
[17:17:48 CEST] <kurosu> I'm unsure about the realtime decoding of all that stuff on s/w though
[17:17:57 CEST] <BBB> kurosu: otherwise people that missed yesterdays meeting wont get anything out of it
[17:18:11 CEST] <BBB> Im more concerned about encoding speed at this point
[17:18:16 CEST] <kurosu> BBB, I'm stuck between a rock and a hard place there
[17:18:30 CEST] <BBB> ?
[17:18:52 CEST] <kurosu> conflicting opinions and decisions I must comply to
[17:19:06 CEST] <kurosu> eg, can't push one way or another the mess
[17:19:19 CEST] <kurosu> people still rely on s/w decoding for some applications
[17:19:44 CEST] <BBB> true
[17:19:49 CEST] <BBB> I dont disagree with your concern
[17:19:57 CEST] <BBB> its a good concern, and Im happy people are concerned about it
[17:20:08 CEST] <BBB> but Im less itnerested in decoding only at this point, I have significant itnerest in encoding speed
[17:20:19 CEST] <kurosu> yeah, that's what can be sold
[17:20:23 CEST] <BBB> ubitux: yeah, the dep tree isnt being propagated
[17:20:28 CEST] <BBB> enabled avfoundation_indev returns true
[17:20:37 CEST] <BBB> enabled avfoundation is false
[17:20:44 CEST] <BBB> and avfoudation_indev_deps contains avfoundation
[17:20:46 CEST] <BBB> Im so confused
[17:20:55 CEST] <BBB> kurosu: right :-p
[17:21:13 CEST] <kurosu> I'm afraid this is a lost fight, though
[17:21:32 CEST] <kurosu> sure you can avoid bad tradeoffs, but the whole thing is now a bad tradeoff
[17:21:58 CEST] <BBB> huh?
[17:22:02 CEST] <BBB> what is a bad tradeoff?
[17:22:08 CEST] <kurosu> most of the gains are now coming from "let's try those upteen way of coding the same block of data"
[17:22:35 CEST] <kurosu> in a particular tool, say you increase encoder complexity by N% and have gain of M%
[17:23:00 CEST] <BBB> right
[17:23:02 CEST] <kurosu> if for hevc/vp9, that was some value, in av1&others, that'll be likely 4-5 times
[17:23:14 CEST] <BBB> theres new stuff in av1
[17:23:20 CEST] <BBB> like per-symbol adaptivity
[17:23:22 CEST] <BBB> thats a good thing
[17:23:23 CEST] <kurosu> you have to test a hell of a lot of stuff to get just 1%
[17:23:43 CEST] <BBB> but yes, I dont like that type of complexity much
[17:23:43 CEST] <BBB> anyway
[17:23:48 CEST] <BBB> not my choice
[17:23:50 CEST] <kurosu> that'll be 4% most often, maybe 10% for lowbitrate ?
[17:23:58 CEST] <BBB> I dont work there :-p
[17:24:10 CEST] <kurosu> and then, what about decoding complexity, that's like cabac
[17:24:19 CEST] <kurosu> I don't either ;-)
[17:24:30 CEST] <BBB> decoding complexity is up by a lot
[17:24:40 CEST] <BBB> but encoding complexity is only up by the same amount, not exponentially
[17:24:43 CEST] <BBB> so thats good for me ;)
[17:25:02 CEST] <kurosu> for reference s/w, h266 inter is 10x h265
[17:25:25 CEST] <kurosu> intra is 30x, but there's a lot of "less than ideal stuff" in there
[17:25:54 CEST] <JEEB> hmm, I only quickly talked with some NHK people about the new MPEG format
[17:25:59 CEST] <BBB> before we talk h266, can we first get some serious user for h265? :-p
[17:25:59 CEST] <JEEB> didn't look into it more
[17:26:11 CEST] <BBB> nobody wants h265, so I dont see why anyone would want h266
[17:26:16 CEST] <BBB> brb
[17:26:41 CEST] <kurosu> BBB: you mean like broadcast in EU/US/JPN, UHD alliance and netflix ? ;)
[17:27:19 CEST] <BBB> like I said, not much ;)
[17:27:23 CEST] <BBB> anyway
[17:27:33 CEST] <BBB> the issue for h265 is licensing, not tech
[17:27:37 CEST] <BBB> so let them fix the licensing
[17:27:42 CEST] <BBB> gonna take kids to zoo
[17:27:43 CEST] <BBB> bbl
[17:27:49 CEST] <atomnuker> kurosu: those pyrrhic proposals mostly come from google who have ran out of ideas on how to fix scalar quantization
[17:27:52 CEST] <atomnuker> (you can't)
[17:27:55 CEST] <BBB> ubitux: if you have more ideas, let me know, I dont understand, but the dep tree doesnt work for me :(
[17:28:07 CEST] <nevcairiel> as long as people want to make money, the companies that hold those patents arent going to want to make less money =p
[17:28:15 CEST] <atomnuker> if only we kept working on pvq
[17:29:21 CEST] <atomnuker> some people seem to want to make av1 a franchise like vp9 rather than a hit like h264 was
[17:29:31 CEST] <atomnuker> or at least it seeems that way
[17:29:39 CEST] <ubitux> BBB: yeah i don't know, especially since i can't really test it
[17:30:41 CEST] <kurosu> the termination clause of aom is another licensing issue for av1
[17:31:12 CEST] <jamrial> kurosu: i thought netflix was vp9 for desktop (using BBB's encoder at that), and h264 for mobile/smarttv/assorted devices
[17:31:18 CEST] <kurosu> in the end, it's bigco against bigco - the way they compete can take a lot of shapes
[17:31:31 CEST] <kurosu> jamrial, iirc, no, for 4K and HDR
[17:31:54 CEST] <kurosu> vp9 is afaik only the lowrate lowres downloadable option - but BBB might correct this :)
[17:32:49 CEST] <kurosu> cf. their requirement for av1: 20% better than hevc (not vp9)
[17:32:53 CEST] <atomnuker> kurosu: its definitely not bigco vs bigco
[17:33:10 CEST] <atomnuker> oh that, no, its not like that either
[17:33:21 CEST] <atomnuker> its against vp9, not h264
[17:33:25 CEST] <atomnuker> or hevc
[17:33:43 CEST] <kurosu> ok, that's the only information that's kind of public as of a target
[17:34:17 CEST] <atomnuker> sadly vp9 was very heavily psnr optimized
[17:34:34 CEST] <kurosu> av1 was Q1 2017 at first, and that set off some decision planning in some places
[17:34:37 CEST] <nevcairiel> psnr makes for good scientific papers :p
[17:34:48 CEST] <nevcairiel> just not for good videos
[17:35:59 CEST] <kurosu> anyway, like BBB said, it's not about tech at this point (they are comparable)
[17:36:15 CEST] <atomnuker> wut? its all about tech
[17:36:19 CEST] <atomnuker> and reasearch
[17:36:47 CEST] <kurosu> I'm talking about vp9 vs hevc, in the scope of comparing to av1 and set a target
[17:37:06 CEST] <kurosu> whatever the basis, it must be 20-30% to make sense and care
[17:38:33 CEST] <atomnuker> no, aiming for something higher that than
[17:39:11 CEST] <atomnuker> and you know what, we reached 30% gain compared to then-current av1 at one point with pvq on psnr-hvs
[17:39:24 CEST] <atomnuker> 20% regression on psnr too :/
[17:39:38 CEST] <kurosu> and there are expectations for 2017? or will av1 be delayed ?
[17:39:59 CEST] <kurosu> pvq won't be in av1, right ?
[17:41:01 CEST] <atomnuker> very sadly and disappointingly no, you can't stick slides in people's faces and scream: "THIS IS BETTER, STOP THINKING OF PSNR"
[17:41:35 CEST] <atomnuker> it could have tbh, but some people didn't want to risk
[17:44:04 CEST] <atomnuker> safe choices suck and when pvq makes it in some codec and its awesome I'll not be keeping quiet about how I was right
[17:46:16 CEST] <kierank> atomnuker: SAD!
[17:46:28 CEST] <kurosu> I came recently across the Chinese SVAC video+audio standard: iirc, vp9 inter coding/loop filtering/entropy coding and hevc intra coding/SAO
[17:46:58 CEST] <kurosu> if unholy frankenstein creature had an implementation in video coding, that'd be it
[17:47:51 CEST] <JEEB> sounds like a nice smörgåsbord of features
[18:23:13 CEST] <BtbN> An encoder only implementing the new api would break users of the old API?
[18:23:22 CEST] <BtbN> So I need to emulate the old API as well
[18:23:55 CEST] <nevcairiel> or you just say screw it =p
[18:24:01 CEST] <nevcairiel> (or them)
[18:24:17 CEST] <atomnuker> BtbN: I still don't know how an encoder may break any of the either old or new api
[18:24:24 CEST] <atomnuker> nothing has changed internally
[18:24:49 CEST] <BtbN> There is a wrapper that translate from new to old API. But not the other way around
[18:24:50 CEST] <atomnuker> you still always get frames and you still sometimes give packets
[18:25:08 CEST] <BtbN> you don't always get frames
[18:25:20 CEST] <atomnuker> well, except when you flush at the end
[18:25:37 CEST] <BtbN> It can return EAGAIN at any time, to tell you to give it more input before it can output a new frame
[18:25:54 CEST] <atomnuker> you mean a packet?
[18:26:04 CEST] <nevcairiel> atomnuker: the "breakage" would be if you want to output multiple packets from one input frame, which the old API cannot do
[18:26:22 CEST] <atomnuker> why would you want to do that? how could you even do that?
[18:26:25 CEST] <nevcairiel> ie. two packets with one field each for interlaced
[18:26:41 CEST] <nevcairiel> h264 paff works like that
[18:27:43 CEST] <atomnuker> you get a single pointer to an avpkt in the function arguments and a single *got_packet pointer to signal you've got output
[18:27:50 CEST] <nevcairiel> thats the old api
[18:27:52 CEST] <BtbN> That's the old api
[18:27:59 CEST] <jamrial> BtbN: you could try to do with encoders what 061a0c14bb5 did to decoders
[18:28:42 CEST] <BtbN> jamrial, that commit still confuses me
[18:28:50 CEST] <BtbN> the previous state seemes more intuitive to me
[18:28:53 CEST] <nevcairiel> you can't fix the fundamental conflict that m:n output is not possible with the old public api though
[18:29:24 CEST] <atomnuker> nevcairiel: there's one encode2 entry in the avcodec struct
[18:29:30 CEST] <jamrial> it turned the old public api into a wrapper for the new one, rather than the other way around
[18:29:39 CEST] <atomnuker> there's no new avcodec api
[18:29:51 CEST] <nevcairiel> atomnuker: of course there is, its send_frame and receive_packet
[18:29:54 CEST] <BtbN> nevcairiel, yeah, interlaced encoding just would not work with the old API. I'm fine with that.
[18:29:55 CEST] <jamrial> you don't need to change the internal api for encoders like that commit did
[18:31:21 CEST] <jamrial> just turn the old public api into a wrapper for the new. that way you can write new encoders using the new api without breaking users of the old, supposedly
[18:33:36 CEST] <atomnuker> meh, I guess you could use the new api to accept variable frame sizes in audio encoders and do a fifo internally
[18:35:20 CEST] <nevcairiel> with its m:n nature, certainly
[18:35:34 CEST] <BtbN> jamrial, that actually sounds like a good idea
[18:36:01 CEST] <BtbN> The change of the internal API that commit did seemed extremely weird to me, and I still haven't understood the argument behind it
[18:36:42 CEST] <BtbN> the decoder actively pulling in packets is just unusual
[18:36:48 CEST] <BtbN> when being asked for output
[19:06:09 CEST] <BtbN> Converting nvenc to the new API is actually straight forward. Split the encode function in the middle, and you have the two functions almost done already.
[19:48:54 CEST] <BtbN> So, can I use C99 (namely, dynamic array on stack) now?
[19:49:17 CEST] <philipl> msvc doesn't and will never support it
[19:49:31 CEST] <philipl> It was downgraded to an optional part of the standard in c11 (was it 11?)
[19:51:54 CEST] <jamrial> BtbN: vla? no, that's disabled with a compiler option, even
[19:53:27 CEST] <BtbN> Basically just uint32_t array[some_variable];
[19:54:25 CEST] <jamrial> yeah, you can't do that :p
[19:54:36 CEST] <jamrial> use av_malloc/realloc
[19:56:37 CEST] <BtbN> "Array size must be equal to size of frame in MBs." what do they even mean by that?
[19:56:49 CEST] <BtbN> width * height / (8 * 8)?
[20:12:43 CEST] <BtbN> Well that is handy. nvenc can tell you the offset to each of the two slices
[20:12:57 CEST] <BtbN> That makes this a whole lot less insane
[20:29:57 CEST] <BtbN> Great. The API for reporting slice offsets seems broken
[20:30:10 CEST] <BtbN> All offsets are 0. Even though it reports the slice count to be 2
[20:32:55 CEST] <BtbN> It works if I artificially split stuff into multiple slices. But only for the first 4.
[20:33:19 CEST] <BtbN> Like, it reports 8 slices. But only the first 4 offset fields are populated.
[20:46:44 CEST] <atomnuker> ubitux: neat, would be interesting to see the overhead the perf api has on x86
[20:48:46 CEST] <atomnuker> ubitux: though I think you should be using PERF_COUNT_HW_REF_CPU_CYCLES
[20:49:00 CEST] <atomnuker> that one isn't affected by frequency scaling according to the docs
[21:02:13 CEST] <BtbN> Just e-mailed all the nvidia dudes about what I think is a driver bug.
[21:02:24 CEST] <BtbN> no idea who of them is responsible.
[21:39:01 CEST] <philipl> BtbN: What are you trying to do with nvenc?
[21:39:13 CEST] <BtbN> interlaced encoding
[21:39:23 CEST] <philipl> I thought it mostly worked already
[21:39:33 CEST] <BtbN> It works great, but nvenc does field mode encoding
[21:39:42 CEST] <BtbN> so for each input frame, it outputs two pictures, so 2 slices
[21:40:28 CEST] <BtbN> And each picture needs to go into its own package with its own proper timestamp. Or most players will play it at half framerate, as the two field pictures have the identical timestamp
[21:40:52 CEST] <philipl> ah. hence, why you were looking at using m:n api for encoding
[21:41:13 CEST] <BtbN> In theory there even is an API in nvenc to get the offset to the second slice
[21:41:15 CEST] <BtbN> but it's broken
[21:41:18 CEST] <philipl> Hmm.
[21:41:20 CEST] <BtbN> seems like nobody used it before
[21:41:31 CEST] <philipl> And so that trac ticket 6633 showing up right now is completely a coincidence?
[21:41:57 CEST] <BtbN> No, he just decided to open it. We have been trying to figure out what's broken for the last couple days
[21:41:57 CEST] <philipl> Considering how bad their documentation is, I suspect most of their features have never been used before.
[21:42:08 CEST] <BtbN> The documentation on this is pretty good and clear
[21:42:12 CEST] <BtbN> It just doesn't work
[21:42:16 CEST] <philipl> heh
[21:42:21 CEST] <BtbN> the Lock Bitstream Parameters can report the slice count and can fill an array with the slice offsets
[21:42:33 CEST] <BtbN> It correctly reports 2 instead of 1 slices when doing interlaced encoding
[21:42:39 CEST] <BtbN> but does not actually put anything into the array
[21:43:00 CEST] <nevcairiel> maybe you need to allocate it for it to fill? some apis are like that
[21:43:12 CEST] <BtbN> yes, the array needs to be allocated by ffmpeg
[21:43:18 CEST] <BtbN> It is decently sized
[21:47:27 CEST] <durandal_170> atomnuker: i resolved doing bigger array size so i do not need fftshift, dunno how to do MxN otherwise
[21:47:57 CEST] <nevcairiel> even if it never works, h264 bitstream is pretty easy to split into seaprate NALs yourself
[21:48:01 CEST] <nevcairiel> we even have code for that
[21:49:12 CEST] <BtbN> As in, code I'd need to copy, or an API somewhere?
[21:49:19 CEST] <nevcairiel> an api
[21:49:28 CEST] <BtbN> I suppose I only need to search for the startcode
[21:49:33 CEST] <BtbN> Which is pretty easy
[21:49:37 CEST] <jya> BBB: can a VP8 have alpha channels?
[21:49:53 CEST] <JEEB> VPx had some weird separate alpha thing
[21:49:54 CEST] <BtbN> And then look at the byte right after it, to figure out if it's a slice
[21:50:28 CEST] <nevcairiel> jya: not as part of the video stream, its kept separately
[21:50:57 CEST] <jya> this video has an alpha element 0x53c0 http://rebbephoto.com/test/ffwebm/3.5.01763.webm
[21:50:58 CEST] <BtbN> nevcairiel, which API is it? And where is it?
[21:51:01 CEST] <jya> it's vp8 codec
[21:51:07 CEST] <jya> libvpx chokes on it
[21:51:30 CEST] <nevcairiel> BtbN: h2645_parse.h, it can split it into separate NALs and you can then re-assemble them into two packets
[21:51:41 CEST] <jya> nevcairiel: yes, I know you decode the two stream separately...
[21:52:05 CEST] <BtbN> nevcairiel, ah, neat. It reads like it can do it for both avc and hevc
[21:52:14 CEST] <nevcairiel> yeah that syntax is pretty much the same in both
[21:52:17 CEST] <nevcairiel> hence its shared code
[21:52:31 CEST] <nevcairiel> jya: that sounds like a webm feature more so then vp8
[21:52:54 CEST] <BtbN> I guess I just have to find all Slice-NALs, and then split right after the last one of the first half
[21:53:02 CEST] <nevcairiel> there is like a handful of different ways to store alpha in webm, sadly
[21:53:40 CEST] <jya> nevcairiel: currently, we look for a 0x53c0 element. 
[21:54:45 CEST] <nevcairiel> thats the AlphaMode property in mkv syntax
[22:08:51 CEST] <wm4> AFAIK that works for both vp8 and vp9
[22:09:03 CEST] <wm4> libavcodec supports it only with the libvpx wrappers
[22:09:08 CEST] <wm4> we discussed this before
[22:13:41 CEST] <jamrial> vp8/9 alpha decoding with the native decoders is a listed gsoc 2017 project, but no idea if anyone took it
[22:26:18 CEST] <jamrial> jya: the libvpx wrapper looks at the matroska blockaditionals passed as packet side data, which contain the alpha channel. it doesn't care about the stream metadata entry created by the presence of a 0x53c0 element
[22:27:08 CEST] <jamrial> if you're not using libavformat's matroska demuxer, you might want to make sure your demuxer handles those
[22:29:40 CEST] <BtbN> nevcairiel, can I somehow just get an offset into the buffer for the NAL? I suppose I can just do "nal.raw_data - 4 - original_buffer"?
[22:29:51 CEST] <BtbN> Or is it not always 4 bytes?
[22:30:18 CEST] <JEEB> it can be 3 bytes
[22:30:29 CEST] <JEEB> under specific circuimstances
[22:30:41 CEST] <BtbN> I guess it's safe to assume that nvenc will always output 4
[22:31:44 CEST] <jamrial> BtbN: you could expand H2645NAL to also store the offset, i guess
[22:32:06 CEST] <BtbN> raw_data is just an incremented input pointer
[22:33:15 CEST] <nevcairiel> its a bit wasteful to use these functions honestly because it'll also unescape the buffers for you, but its easier then re-implementing startcode searches, i guess
[22:38:08 CEST] <BtbN> I'd prefer if nvidia just fixes their driver
[22:38:21 CEST] <BtbN> Will wait for a replay for a few days
[22:38:54 CEST] <BtbN> Or I'll just write a generic get-offset function. Which can either be trivially filled with the official offset, or do the parsing.
[22:41:21 CEST] <jamrial> BtbN: instead of keeping the old encode2() implementation of nvenc, remove it so downstream users are forced to migrate to the new api in their code :p
[22:41:38 CEST] <BtbN> that would break API
[22:42:16 CEST] <jamrial> it would make nvenc stop working with avcodec_encode_video2(), yeah, that's the idea :p
[22:42:37 CEST] <BtbN> That needs the normal deprecation period
[22:42:50 CEST] <jya> jamrial: there's alpha data there, one with non zero side.
[22:43:07 CEST] <atomnuker> could we handle encoders/decoders which do not support the old api in utils.c?
[22:43:18 CEST] <BtbN> for decoders we already do
[22:43:20 CEST] <jamrial> BtbN: technically speaking, the deprecation period is ongoing ever since avcodec_encode_video2 was deprecated
[22:43:38 CEST] <jamrial> but i guess yeah, making nvenc stop working with it is kinda a dick move
[22:43:41 CEST] <jya> We only found the stuff found in the meta data to determine e which decoder to use, as currently we've only made the alpha stuff work with the libvpx decoder, not ffvp9/8
[22:43:49 CEST] <philipl> Drop the old api as part of the next break. :-)
[22:44:11 CEST] <jamrial> philipl: once it's two years old and every decoder/encoder has been migrated, sure
[22:44:41 CEST] <jamrial> bah, i guess there's no need to migrate anything out of encode2 since that's internal
[22:44:54 CEST] <philipl> We have two decoders and no encoders migrated right now, right?
[22:44:55 CEST] <BtbN> Making up the timestamps for those two fields will also be fun
[22:45:51 CEST] <BtbN> I guess just setting the second field to NOPTS won't work
[22:46:11 CEST] <BtbN> Also, the timebase might not allow intermediate frames
[22:53:54 CEST] <ubitux> atomnuker: i sometimes observe something like a 400 decicyles overhead
[22:54:00 CEST] <ubitux> seems a bit random
[22:54:15 CEST] <ubitux> (that is, difference with what we have, which may be innacurate/broken for various reasons)
[22:54:22 CEST] <ubitux> i didn't test PERF_COUNT_HW_REF_CPU_CYCLES
[22:54:28 CEST] <ubitux> feel free to try my github branch
[22:54:30 CEST] <ubitux> (named perf)
[23:53:37 CEST] <cone-035> ffmpeg 03Michael Niedermayer 07master:2a0823ae966b: avcodec/diracdec: Fix integer overflow in INTRA_DC_PRED()
[23:53:37 CEST] <cone-035> ffmpeg 03Michael Niedermayer 07master:f71cd44147e7: avcodec/dirac_dwt: Fix multiple overflows in 9/7 lifting
[23:53:37 CEST] <cone-035> ffmpeg 03Michael Niedermayer 07master:c595139f1fdb: avcodec/dirac_vlc: Fix invalid shift in ff_dirac_golomb_read_32bit()
[00:00:00 CEST] --- Sun Sep  3 2017