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

[burek]

[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/0c4c87e72463da1a4bf45032e4db3c2c86d6d8d8
[22:33:47 CEST] <kierank> michaelni_: where does this calculation come from?
[22:33:48 CEST] <kierank> https://github.com/FFmpeg/FFmpeg/blob/8788dd67b851ec652bdd83bb5d5afb12101b7c6f/libavcodec/h264_slice.c#L2535
[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