[00:43:40 CEST] <kierank> tl [00:59:12 CEST] <BtbN> Oh, new Video decode SDK [00:59:22 CEST] <BtbN> "Added support for CUStream in NVENCODE API to facilitate parallel execution of pre-/post-processing of video on CUDA and encoder tasks." that sounds useful [01:00:19 CEST] <BtbN> rcombs, btw. nvenc does nowhere claim to support anything but "x64 and ppc64le" [01:01:28 CEST] <BtbN> hm, SDK is nowhere to be found yet [02:33:06 CEST] <rcombs> BtbN: "stream-based API" frightens me though [02:40:19 CEST] <philipl> rcombs: It's not that scary. For us it mostly means explicitly propagating streams through the hwcontexts, decoder, encoder, filters. [02:40:49 CEST] <philipl> We just use the default stream; stream management is a client's responsibility. [02:51:20 CEST] <rcombs> philipl: I've seen people try to cram stream-based APIs (that don't expose frames to the user) in ffmpeg and it's always ended in horrible horrible hacks [03:18:38 CEST] <philipl> rcombs: this isn't that. Streams are acuda synchronisation mechanism [03:18:49 CEST] <rcombs> ah, alrighty then [03:23:05 CEST] <cone-786> ffmpeg 03Jun Zhao 07master:7ce15b1d4394: avutil/file: always set *size to zero if *bufptr is NULL [03:23:05 CEST] <cone-786> ffmpeg 03Jun Zhao 07master:95780f4dcbf8: avutil/file: add more check befor destory the buffer [08:23:30 CEST] <thardin> michaelni_: I've been poking at a thorough check for cinepak validness. validating all length fields, requiring that strips cover the entire frame, checking that each strip is at least as required for their specified mode [08:23:59 CEST] <thardin> at least as large* [08:33:18 CEST] <thardin> proper recognition is a good way to reduce computing power greed [09:15:12 CEST] <michaelni_> thardin, yes, if it doesnt break any files out in the wild, more throughout checking is "always" good [09:30:40 CEST] <thardin> it's impossible to know if it breaks any files in the wild [09:31:02 CEST] <thardin> but it can be made as strict as the win3.1 decoder [09:32:06 CEST] <thardin> any broken files need to be in FATE so refactoring can be done with confidence [09:43:19 CEST] Action: JEEB likes how track_duration in movenc gets updated for a track without any entries in a fragment before seemingly write_packet gets called, and thus various timestamp validation checks fail because they think I'm trying to go backwards in time \o/ [09:45:02 CEST] <JEEB> because it unconditionally checks the next packet and updates in mov_flush_fragment :) [09:59:23 CEST] <JEEB> ok, but skipping that leads to fragment timestamps not being written right, so I will just adjust the sanity check in check_pkt [10:03:23 CEST] <JEEB> that seems to have done it \o/ [10:07:09 CEST] <thardin> noice [10:13:36 CEST] <JEEB> so basically for each flushed fragment the track_duration gets updated to the next upcoming packet in the lavf context's buffer. then when you come to write your next packet check_pkt will not let you write a packet starting before that. except in my case I have to squash packets with the contents of the packet containing timestapms. so if the DTS/PTS of the packet gets adjusted to the start of the [10:13:42 CEST] <JEEB> fragment at the end, that of course skews it completely xD so I start it at the previous fragment's end if such is available. and that was catching up in fire now :) [10:14:47 CEST] <JEEB> but basically using the previous fragment's end as the minimum dts in the case of such track (I have a flag for it already) made it pass and everything went OK [10:15:30 CEST] Action: JEEB checks that this stuff works for non-fragmented too although the frag_start variable seems to get updated with each packet write [10:22:47 CEST] <JEEB> seems to work :) [11:20:49 CEST] <J_Darnley> Have any other samplie test programs or examples been converted to refcounted packets and frames recently? [11:20:57 CEST] <J_Darnley> *simple [11:45:13 CEST] <cone-279> ffmpeg 03Eugene Lyapustin 07master:20a12448aaf1: avfilter/vf_v360: add facebook's format [12:54:08 CEST] <JEEB> ugh... now I'm rnadomly getting CTS offsets most likely due to somehow end_pts not matching start_dts + duration [13:35:53 CEST] <JEEB> I /think/ I found it [13:35:55 CEST] <JEEB> > trk->cluster[trk->entry].dts = trk->start_dts + trk->track_duration; [13:36:10 CEST] <JEEB> track_duration was already picked up from an *upcoming* packet instead of an already written one [13:36:55 CEST] <JEEB> and then pkt->pts gets adjusted for that [16:03:10 CEST] <Lynne_> jkqxz: can you post a vulkaninfo dump from an amd with new-ish drivers? [16:03:26 CEST] <Lynne_> I'm still not sure one image per plane is the best idea [16:04:01 CEST] <Lynne_> mainly because the decode API that's coming up will 100% decode to such images... that you allocate and give it [16:04:36 CEST] <Lynne_> having 2 different incompatible types of vulkan frames is not good [16:08:56 CEST] <Lynne_> since you allocate the images to decode into, you'd obviously want to use optimal tiling, and you can't split apart optimally tiled non-disjoint multiplane images [16:09:17 CEST] <jamrial> durandal_1707: that wcmv sample doesn't have duplicate frames, so not really useful in the end [16:10:25 CEST] <durandal_1707> ah will send another one [16:47:21 CEST] <cone-216> ffmpeg 03Guo, Yejun 07master:09a455a24649: dnn: introduce dnn operand (in c code) to hold operand infos within network [16:47:22 CEST] <cone-216> ffmpeg 03Guo, Yejun 07master:2d5e39c13e50: dnn: change .model file format to put layer number at the end of file [16:47:23 CEST] <cone-216> ffmpeg 03Guo, Yejun 07master:83e0b71f66f2: dnn: export operand info in python script and load in c code [18:48:26 CEST] <kierank> durandal_1707: do you know how ER code works [18:48:34 CEST] <kierank> why i get er errors when output is bitexact [18:54:12 CEST] <durandal_1707> dunno, im not author of that code [19:03:23 CEST] <kierank> durandal_1707: i made twit [19:32:11 CEST] <durandal_1707> kierank: great, write more, but only I read your twits :p [19:41:02 CEST] <kepstin> there we go. two years late, but i finally got around to posting the trivial fixes to my patch so the concat filter doesn't break if videos have different framerates :/ [20:41:55 CEST] <kierank> J_Darnley: ok so the race condition is here [20:42:00 CEST] <kierank> avctx->execute(avctx, decode_slice, h->slice_ctx, [20:42:01 CEST] <kierank> NULL, context_count, sizeof(h->slice_ctx[0])); [20:42:08 CEST] <kierank> if I make that serial the errors go away [20:42:50 CEST] <kierank> could still be a testcase problem [20:42:51 CEST] <kierank> not sure [20:43:43 CEST] <kierank> let's see what happens if I put a lock in the testcase [20:52:03 CEST] <kierank> what is "job_size" in avctx->execute [21:06:40 CEST] <jamrial> durandal_1707: did you find a sample? [21:08:17 CEST] <durandal_1707> jamrial: see ml [21:08:43 CEST] <jamrial> huh, missed it somehow [21:08:45 CEST] <jamrial> thanks [21:09:04 CEST] <durandal_1707> can encode with wine and virtualdub2 [21:09:14 CEST] <durandal_1707> just need to install codec [21:10:39 CEST] <jamrial> i'm not going to install weird binary codecs, so thanks for generating the sample :p [21:11:07 CEST] <kierank> we could have a windows vm for devs [21:11:38 CEST] <JEEB> thankfully windows 10 works without activation for some time [21:12:04 CEST] <jamrial> durandal_1707: so zero sized packets when it's meant to duplicate frames? [21:12:06 CEST] <JEEB> although a shared one might lower the entry barrier. that said it would have to be reset for each user etc [21:17:16 CEST] <durandal_1707> jamrial: yes [21:17:41 CEST] <durandal_1707> wine is fine, suffer now [21:19:54 CEST] <jamrial> durandal_1707: the decoder never sees them, it seems. even if i revert 976dae8b32 [21:20:03 CEST] <jamrial> they are evidently dropped earlier in the process [21:20:30 CEST] <jamrial> so for this sample, that commit didn't change anything [21:21:00 CEST] <durandal_1707> argh, that kind of sucks [21:33:02 CEST] <cone-593> ffmpeg 03Michael Niedermayer 07master:9b57b90c4c27: avcodec/vaapi_encode: Simplify code with av_clip_int8() [22:05:36 CEST] <tmm1> jkqxz: what do you think of something like this to be able to use -init_hw_device for dummy drm when /dev/dri does not exist (i.e. rpi3 when trying to use v4l2 dec/enc): https://github.com/Kwiboo/FFmpeg/commit/0c4c87e72463da1a4bf45032e4db3c2c86d6... [22:33:47 CEST] <kierank> michaelni_: where does this calculation come from? [22:33:48 CEST] <kierank> https://github.com/FFmpeg/FFmpeg/blob/8788dd67b851ec652bdd83bb5d5afb12101b7c... [22:34:00 CEST] <kierank> it seems broken with chunks+sliced_threads+draw_horiz_band [22:34:21 CEST] <kierank> and deblock_mode=2 [22:34:54 CEST] <kierank> you can have slice 1 be decoded before slice 0 but this code tells the reader to read from slice 0 [22:45:36 CEST] <cone-593> ffmpeg 03Paul B Mahol 07master:62459d6584ad: avfilter/vf_stereo3d: improve dubois anaglyphs [22:59:43 CEST] <michaelni_> kierank, yes looks broken and seems to come from the initial code adding multithreading [22:59:59 CEST] <kierank> michaelni_: the 4 I guess is from the 4 pixel deblock offset but I don't know where the +16 comes from [23:57:25 CEST] <cone-593> ffmpeg 03Michael Niedermayer 07master:07b948fe6078: avcodec/vorbisdec: Check get_vlc2() failure [00:00:00 CEST] --- Sat Aug 31 2019