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

[burek]

[08:47:54 CET] <thardin> does avutil have a std::deque-type thing?
[08:49:53 CET] <JEEB> yea I was using something like that for AVPackets in movenc.c for one of those patches I'll hopefully post on the ML soon
[08:50:13 CET] <JEEB> (I just added addition back to the pop() point IIRC)
[08:50:26 CET] <JEEB> so the base functionality for put/pop should already be there
[08:51:01 CET] <thardin> what's it called?
[08:52:41 CET] <JEEB> ff_packet_list.*
[08:53:21 CET] <JEEB> AVPacketList apparently being the struct
[08:53:36 CET] <JEEB> there might be a void * thing as well
[08:54:11 CET] <thardin> I see it's lavf-specific
[08:54:28 CET] <thardin> wait a sec.. isn't there a std-like thing for C?
[08:54:28 CET] <JEEB> I think there was something in libavutil as well, but I don't remember that one
[08:54:37 CET] <JEEB> there could be, I'm not sure
[08:54:48 CET] <JEEB> also the logic seems rather generic in this thing 8)
[08:58:00 CET] <thardin> http://sglib.sourceforge.net/  
[08:58:24 CET] <thardin> http://savannah.gnu.org/projects/avl
[10:09:16 CET] <cone-352> ffmpeg 03Martin Storsjö 07master:06ec9c4746eb: configure: Check for the SetDllDirectory and GetModuleHandle functions
[10:14:06 CET] <f00lest> how can I get exact functionality that `ffmpeg -i video.webm thumb%04d.jpg` offers using just c code.
[10:14:32 CET] <JEEB> see the doc/examples/transcode or so example
[10:14:36 CET] <JEEB> ignore the audio reltaed stuff
[10:26:02 CET] <nevcairiel> the image generation is the "image2" muxer
[10:26:18 CET] <nevcairiel> encode to jpeg, mux with image2, and it can generate a list of image files
[10:27:21 CET] <f00lest> JEEB thanks
[10:27:52 CET] <f00lest> nevcairiel not clear on what you said, sorry I am just getting started with ffmpeg and c
[10:56:45 CET] <f00lest> nevcairiel was that message for me, may be I mistook it? was it for some one else?
[11:03:52 CET] <JEEB> f00lest: it was for you
[11:04:05 CET] <JEEB> so when opening a muxer, the one writing multiple images is called "image2"
[12:53:25 CET] <cone-352> ffmpeg 03Paul B Mahol 07master:824324db4102: avfilter/vf_datascope: add decimal output
[14:55:20 CET] <durandal_1707> michaelni_: libavutil/bswap.h:60:8: runtime error: implicit conversion from type 'int' of value 2101792 (32-bit, signed) to type 'uint16_t' (aka 'unsigned short') changed the value to 4640 (16-bit, unsigned)
[15:03:19 CET] <durandal_1707> michaelni_: Lynne : the 12bit idct simd code is incorrect - it differs from C variant
[15:04:51 CET] <durandal_1707> and create artifacts at borders
[15:10:31 CET] <cone-352> ffmpeg 03James Almer 07master:54d09eb8d052: fate/cbs: use the rawvideo muxer for AV1 tests
[15:45:16 CET] <cone-352> ffmpeg 03Guo, Yejun 07master:ed9fc2e3c576: avfilter/vf_dnn_processing: refine code for better naming
[15:45:17 CET] <cone-352> ffmpeg 03Guo, Yejun 07master:e52070e89c75: convert_from_tensorflow.py: add support when kernel size is 1*1 with one input/output channel (gray image)
[16:04:36 CET] <cone-352> ffmpeg 03Andreas Rheinhardt 07release/4.2:2f89f24eb952: avformat/matroskadec: Fix demuxing ProRes
[16:04:37 CET] <cone-352> ffmpeg 03Andreas Rheinhardt 07release/4.2:48ae2358482f: avformat/matroskadec: Fix use-after-free when demuxing ProRes
[16:30:43 CET] <BBB> jamrial: don't you think that by default filling in the correctly-implied values is valuable?
[16:30:55 CET] <BBB> for users of cbs that don't want to have to load ref explicitly
[16:32:45 CET] <jamrial> no, because you can't do it for all frames in a TU. whatever is stored in the cbs private context, it will be from the last parsed frame, in whatever order they were coded in the TU (usually the visible frame)
[16:34:02 CET] <jamrial> if you want values for one specific frame out of four in a TU, then you have no choice but to derive them from priv->ref[frame->ref_frame_idx[frame->primary_ref_frame]]
[16:35:18 CET] <jamrial> and you of course can't apply those derived values into the frame proper because then the writing process will think they are coded values rather than derived values
[16:41:37 CET] <jamrial> maybe this could just magically work if you write them into the frame proper without risking the writing code thinking they are coded because the *_update fields will be false
[16:42:09 CET] <jamrial> but i can't say if it's safe or ideal
[16:42:26 CET] <jamrial> would like to hear jkqxz's opinion before doing anything
[16:47:47 CET] <durandal_1707> help!
[17:15:17 CET] Action: BradleyS helps durandal_1707
[18:32:37 CET] <Illya> Anyone seen Diego recently?
[18:37:03 CET] <BBB> which one?
[18:48:11 CET] <Illya> BBB: Biurrun
[18:51:16 CET] <kierank> why would he be on this channel
[18:52:32 CET] <durandal_1707> pain
[18:53:42 CET] <Illya> I mean at all, not necessarily in this channel. It's fine I'll just email him
[19:17:11 CET] <durandal_1707> what can cause block 8x4 idct output? for other files it works fine, just for this single one it breaks
[19:17:21 CET] <durandal_1707> *blocky
[19:18:11 CET] <BBB> overflow?
[20:15:07 CET] <mkver> durandal_1707: MAINTAINERS says you are still on Google+.
[20:31:07 CET] <durandal_1707> mkver: please send patch :)
[20:31:16 CET] <mkver> Ok.
[20:59:31 CET] <durandal_1707> BBB: unlikely, i changed SUINT to int and build with -fsanitize=integer and do not get overflows
[21:00:08 CET] <BBB> it typically means you lost high frequency coefs
[21:00:09 CET] <BBB> so ...
[21:00:12 CET] <BBB> anything leading to that
[21:00:21 CET] <BBB> what's your scantable and post-init_scantable scantbale?
[21:09:22 CET] <durandal_1707> BBB: for 8x4 i have only one scantable, do need coefficients after first idct 8 transform?
[21:46:31 CET] <jamrial> michaelni_: are you going to apply "avcodec/cbs_av1_syntax_template: Check num_y_points"?
[21:47:56 CET] <michaelni_> jamrial, i can, i was just waiting as noone reviewed/approved it
[21:48:15 CET] <jamrial> michaelni_: i did
[21:52:55 CET] <jamrial> also made a suggestion in the same review email
[21:53:13 CET] <michaelni_> i see your mail on patchwork i dont see it in my local mailbox nor my spam folder 
[21:59:19 CET] <jamrial> weird
[21:59:37 CET] <durandal_1707> BBB: could be quantization queficients?
[21:59:46 CET] <BBB> possible, yes
[21:59:57 CET] <BBB> that's why I asked for the coef array (input to idct8x4)
[22:00:04 CET] <BBB> but ... let's see
[22:02:03 CET] <durandal_1707> quants too small or too big?
[22:03:23 CET] <BBB> probably too small
[22:03:57 CET] <BBB> but could also be too big
[22:04:03 CET] <BBB> it depends whether the dc is too big or the ac too small
[22:19:09 CET] <michaelni_> jamrial, i see a bounce in the logs around the time so its probably something on my mail servers side. if this becomes more frequent then i need to find something more reliable or setup my own. but till now it was more reliable than gmx.at
[22:19:48 CET] <jamrial> could have been a fluke
[22:27:56 CET] <linjie_fu> for idct, are you talking about c version implementation or asm?
[22:28:09 CET] <durandal_1707> C
[22:29:05 CET] <linjie_fu> em... happen to know an coeff overfow issue for asm
[22:29:22 CET] <linjie_fu> seems not related with C :D
[22:29:27 CET] <durandal_1707> what bitdepth?
[22:31:05 CET] <linjie_fu> https://patchwork.ffmpeg.org/patch/16722/
[22:31:41 CET] <linjie_fu> similar with this if you modify the test case in checkasm for h264 idct, asm goes wrong
[22:32:23 CET] <durandal_1707> simple_idct 12bit depth only here
[23:16:51 CET] <durandal_1707> i get overflow from pure white to black with idct
[23:16:54 CET] <durandal_1707> 8x8
[23:59:35 CET] <cone-383> ffmpeg 03Michael Niedermayer 07master:bbe27890ff7e: avcodec/cbs_av1_syntax_template: Check num_y_points
[00:00:00 CET] --- Sat Dec 14 2019