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

[burek]

[00:53:33 CEST] <tmm1> JEEB: ok sent a new patch with the AVProgram change flag you wanted
[01:23:03 CEST] <JEEB> tmm1: holy carp. will have to check after I have my sleep finally
[01:23:16 CEST] Action: JEEB was giving a few minutes to the ARIB stuff he was poking at
[02:06:02 CEST] <klaxa> ok this far i'm done with reading a lua config and parsing it into C structs, i'm almost done with running servers according to the configuration, still buggy, but in general sending data and not crashing a lot
[02:08:23 CEST] <klaxa> or so i thought...
[03:35:53 CEST] <tmm1> jkqxz: whats the state of that userdata/metadata cbs patchset?
[03:40:54 CEST] <cone-188> ffmpeg 03Rostislav Pehlivanov 07master:ce943dd6acbf: configure: error out on unsupported MSVC versions
[03:40:54 CEST] <cone-188> ffmpeg 03Rostislav Pehlivanov 07master:62a7a70484f7: doc/developer: update style guidelines to include for loops with declarations
[03:40:54 CEST] <cone-188> ffmpeg 03Rostislav Pehlivanov 07master:8e7b13b971be: opusenc: use for loops with declarations
[03:42:02 CEST] <atomnuker> its now a modern C99 project
[03:47:51 CEST] <tmm1> maybe in another 19 years we can allow mixed code and declarations
[03:49:06 CEST] <klaxa> there's apparently good reasons to forbid that like poor variable visibility
[04:00:06 CEST] <atomnuker> yeah, mostly, though in some places it helps
[13:21:27 CEST] <cone-471> ffmpeg 03Paul B Mahol 07master:e9dd5b4f5eed: avfilter/vf_waveform: add slice threading
[14:04:23 CEST] <gagandeep> kierank: i am almost done with interlacing with the samples on tracker
[14:04:36 CEST] <gagandeep> the error was in codebook
[14:05:24 CEST] <gagandeep> there are 3 codebooks in cineform and on using a flag in tag, decompanding was not to be used
[14:05:24 CEST] <kierank> oh really
[14:05:29 CEST] <kierank> ah
[14:05:45 CEST] <gagandeep> just that peak table implementation is left
[14:06:41 CEST] <gagandeep> codebook 17(flag = 1) is same as codebook 18(flag = 2) but with flag 2 no decompand 
[14:07:12 CEST] <gagandeep> i might need some help with reading the bitstream for constructing the peak table
[14:07:27 CEST] <gagandeep> two samples out of 3 are giving correct results now
[14:08:49 CEST] <gagandeep> i dont know why they made same codesets with different name and used different flags for refferencing
[14:09:17 CEST] <kierank> good work
[14:10:19 CEST] <gagandeep> thanks
[14:39:21 CEST] <durandal_1707> gagandeep: where are patches?
[14:39:53 CEST] <JEEB> he's working on it, you know
[15:43:44 CEST] <cone-471> ffmpeg 03Tobias Rapp 07master:eb28b5ec8a21: avfilter/vsrc_testsrc: add pal75bars and pal100bars video filter sources
[19:16:40 CEST] <cone-471> ffmpeg 03Clément BSsch 07master:2940af9389e5: tests/checkasm/nlmeans: fix invalid read/write on ii buffer
[20:58:27 CEST] <BtbN> Does the null format not discard frames?
[21:02:33 CEST] <nevcairiel> it just does nothing with them, not sure what you mean?
[21:03:33 CEST] <BtbN> If I do -hwaccel nvdec -hwaccel_output_format cuda -i something_hevc.mp4 -f null - the decoder runs out of output surfaces
[21:03:40 CEST] <BtbN> doing a transcode with nvenc works fine
[21:03:58 CEST] <jkqxz> BtbN:  -an
[21:04:28 CEST] <jkqxz> You end up with funny effects from it trying to synchronise audio and video into the null muxer, for reasons I've never cared to pursue.
[21:04:45 CEST] <BtbN> it works fine for a h264 video for some reason
[21:04:48 CEST] <nevcairiel> it uses wrapper avframe, which is a huge ugly hack that should never exist, so maybe that messes up with hw frames, not sure i ever used that combination
[21:05:05 CEST] <BtbN> Just wanted to know raw hwdec speed
[21:05:09 CEST] <BtbN> so it seemed like the obvious choice
[21:05:20 CEST] <jkqxz> You definitely want -an then :P
[21:05:33 CEST] <BtbN> Yeah, -an -sn fixed it
[21:05:35 CEST] <BtbN> weird
[21:06:36 CEST] <cone-471> ffmpeg 03Aman Gupta 07master:e24d768a76b1: avformat/mpegts: add skip_unknown_pmt option
[21:11:26 CEST] <tmm1> is AVFrame.hw_frames_ctx used for anything internally in lavc, or just there for the API user?
[21:14:24 CEST] <wm4> in videotoolbox it's pretty much only to make the API happy
[21:14:49 CEST] <wm4> though it could be used to negotiate the sw_pix_fmt I guess
[21:15:09 CEST] <wm4> in general, it keeps the hardware frame pool alive
[21:15:15 CEST] <wm4> for normal hwaccels
[21:15:58 CEST] <BtbN> nvenc uses it to get the actual frame dimensions with padding and stuff
[21:16:08 CEST] <BtbN> cause AVCodecContext does not carry that
[21:16:38 CEST] <tmm1> ok cool, i'm going to commit http://ffmpeg.org/pipermail/ffmpeg-devel/2018-May/230224.html then
[21:16:39 CEST] <BtbN> And it's also the only documented way to pass in the sw_pix_fmt
[21:18:01 CEST] <BtbN> That sounds more like something else is really really broken, and this just masks it
[21:18:20 CEST] <nevcairiel> its probably caused by the madness that is vt
[21:18:38 CEST] <BtbN> Probably just a missing av_buffer_ref somewhere when taking the hw_frames_ctx
[21:21:35 CEST] <nevcairiel> the problem is likely that the hwaccel tries to manage the hw_frames_ctx instead of letting generic code handle it like its done for proper hwaccels
[21:24:56 CEST] <tmm1> where is the generic code that would set the hw_frames_ctx on a frame?
[21:25:45 CEST] <BtbN> the hw_frames_ctx code itself set it, when allocating the frame.
[21:26:03 CEST] <nevcairiel> yeah in default_get_buffer2 -> av_hwframe_get_buffer
[21:26:15 CEST] <nevcairiel> that way every frame has that always set
[21:28:21 CEST] <nevcairiel> to get a similar result you should probably do it in ff_videotoolbox_alloc_frame
[21:28:30 CEST] <nevcairiel> since thats called about at the same time
[21:29:57 CEST] <nevcairiel> but apparently thats incompatible with the design of the vt decoder
[21:30:01 CEST] <nevcairiel> ie. you're fucked :p
[21:30:03 CEST] <tmm1> yea ugh
[21:30:23 CEST] <tmm1> i don't think that would solve the issue anyway, because somehow the value is disappearing after its been set
[21:30:38 CEST] <nevcairiel> its not disappearing, its probably just ad ifferent frame that never had it set
[21:30:49 CEST] <nevcairiel> because the main frame allocation function does not set it in your case
[21:31:12 CEST] <nevcairiel> my guess is that it moves the frame data into another frame somewhere
[21:36:31 CEST] <tmm1> yea i think that's what is happening
[21:38:03 CEST] <tmm1> so since i don't have the hw_frames_ctx until the vt decoder gives me back the frame, storing it separately and attaching to the AVFrame later seems like an okay workaround?
[21:38:18 CEST] <tmm1> considering how hacked up this is in the first place
[21:55:24 CEST] <cone-471> ffmpeg 03Aman Gupta 07master:8f146b526ff8: avcodec/videotoolbox: fix decoding of some HEVC videos
[21:56:00 CEST] <tmm1> rewrote the commit message to more accurately describe whats happening
[22:04:20 CEST] <JEEB> anyone on mac to check if they get this https://pastebin.com/mLrBTS2Q ?
[22:04:35 CEST] <JEEB> (yes, memcpy, macro)
[22:05:03 CEST] <wm4> seems to be OSX' fault
[22:05:10 CEST] <wm4> from a first look
[22:05:22 CEST] <JEEB> too bad they renamed it, so now you call it "macos" again
[22:05:25 CEST] <JEEB> (´4@)
[22:05:32 CEST] <JEEB> *are supposed to call it
[22:09:30 CEST] <tmm1> JEEB: i've been building master on macos and haven't seen that
[22:31:15 CEST] <klaxa> hmmm wtf, i can define multiple servers no problem, but multiple streams per server still giving me trouble...
[22:43:41 CEST] <cone-471> ffmpeg 03James Almer 07master:79126ce80e21: avfilter/vsrc_testsrc: fix a preprocessor check
[22:58:58 CEST] <tmm1> jkqxz: are you still working on the a53 cbs patchset?
[23:28:08 CEST] <klaxa> ok figured it out, race conditions are hard to track :/
[00:00:00 CEST] --- Sat May 19 2018