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

[burek]

[00:25:40 CEST] <kevmark> How not to do testing? https://github.com/rg3/youtube-dl/pull/13449#issuecomment-313878863
[00:42:47 CEST] <Compn> ydl, a vastly underrated project :)
[00:45:20 CEST] <kevmark> I use it all the time, it's terrific. But their extractor testing is in dire need of an overhaul
[00:47:09 CEST] <kevmark> If only because your version of ffmpeg decides whether some tests pass or not
[10:09:27 CEST] <hanna> I wonder if you would be willing to accept a change to make base64.c/h use a fixed `int in_size` (alongside the `int out_size`) instead of relying on the input being NULL-terminated
[10:09:38 CEST] <hanna> Seems like that would be strictly more compatible (you could still use strlen() if you have nul-terminated strings)
[10:53:57 CEST] <durandal_1707> anybody knows how huffman lenghts can be up to 15
[10:58:43 CEST] <durandal_1707> with huffman function from ffmpeg i get bigger lengths
[11:20:41 CEST] <durandal_1707> michaelni: ^
[11:26:21 CEST] <michaelni> nb_bits passed to *init_vlc multiplied by the depth used in the vlc decode macro have to be larger of equal to the longest code
[11:26:37 CEST] <michaelni> that can be lnger than 15
[11:27:36 CEST] <michaelni> but maybe i misunderstood what set of vlc functions you meant ...
[11:30:45 CEST] <durandal_1707> michaelni: this is for encoding
[11:33:47 CEST] <durandal_1707> basically doing reverse process for magicyuv
[11:47:59 CEST] <michaelni> if you want to create a vlc set with length of <=16, the mjpeg encoder also needs vlcs below a maximum length, the code from  libavcodec/mjpegenc_huffman.c can likely be shared  
[12:42:19 CEST] <durandal_1707> michaelni: issue is mjpeg one unused symbols sets to 0
[12:42:37 CEST] <durandal_1707> while magicyuv doesnt
[13:39:28 CEST] <durandal_1707> michaelni: how to handle cases when frequency/count is 0?
[13:49:58 CEST] <michaelni> if a symbol doesnt occur it doesnt need a vlc unless required by some syntax constraint
[13:53:33 CEST] <ubitux> michaelni: do you want me to look up for some <<><<<>< patterns in the db?
[13:53:42 CEST] <ubitux> do you have a grep pattern to suggest?
[13:54:06 CEST] <ubitux> i'm expecting stuff like "<<<<<<<<<<" and ">>>>>>>>>" used for "styling" but that's all
[14:17:47 CEST] <ubitux> michaelni: ./6/6/6/4/1cb707c078d833eb988ec424d80b0431:<b><<< ÓÍÀÊÑ ÒÈÉÌ < 2015 > UNACS TEAM >>></b>
[14:17:54 CEST] <ubitux> yeah, that kind of stuff&
[14:22:06 CEST] <michaelni> ubitux, yes, testcases with stuff like this should be usefull for fate
[14:26:19 CEST] <ubitux> heh, some ppl use << and >> for « and »
[14:31:16 CEST] <ubitux> oh i guess it was the ocr they used
[14:32:07 CEST] <RiCON> and keyboards that don't have «», maybe
[17:07:06 CEST] <atomnuker> iive: the avx2 version should've been dropped too, it was slower than sse42 iirc
[17:29:40 CEST] <iive> atomnuker: yes, indeed.
[17:30:35 CEST] <atomnuker> and the avx version was no faster too IIRC
[17:30:56 CEST] <iive> on older intel cpu and ryzen avx is fastest
[17:32:01 CEST] <atomnuker> huh, ok
[17:33:47 CEST] <iive> btw, you can try 128bit avx2, the only difference should be the broadcastv instructions
[17:36:24 CEST] <atomnuker> how?
[17:36:56 CEST] <iive> the int last 2 lines of the assembly, change the INIT_YMM to INIT_XMM :D
[17:37:21 CEST] <iive> the int/in the
[18:02:49 CEST] <jamrial> avx2 using xmm only gets you reg -> reg broadcast intructions, double word pblend, and variable bit shift intructions
[18:03:59 CEST] <BtbN> wonder how avx2 used that way works on Ryzen, as it's only kind of emulating the 256bit
[18:06:19 CEST] <atomnuker> it helps apparently because there's less overhead to decode instructions
[18:08:22 CEST] <kierank> BBB: is ff_h264_update_thread_context allowed to edit the source context 
[18:34:21 CEST] <nevcairiel> kierank: its const, so no
[18:34:47 CEST] <kierank> hmm didn't notice that
[18:34:48 CEST] <kierank> hmmm
[18:34:59 CEST] <kierank> leads to insane side data race conditions
[18:43:54 CEST] <kierank> BBB: so my problem is caption data is stored in field 1 (thread 2), update_thread_context needs to pass it to field 2 (thread 2) and then zero the pointer in thread 1, is there a proper way of doing that?
[18:46:44 CEST] <kierank> or maybe michaelni knows?
[19:07:03 CEST] <iive> BtbN: btw, would you test v4 too? I want to know if the x64_reg define still makes thing faster/slower.
[19:07:13 CEST] <iive> it's not urgent.
[19:12:01 CEST] <michaelni> kierank, maybe a AVBufferRef can be used to create a new ref to the data in the new thread, and the old would be freed at the end of the old thread and not be set to NULL. But maybe i misunderstand 
[19:12:26 CEST] <kierank> yes, I was thinking the same
[19:12:39 CEST] <kierank> thanks
[19:13:35 CEST] <kierank> maybe i need to make a caption buffer for field 1 and field 2
[19:38:51 CEST] <tmm1> is a decoder allowed to change avctx->framerate at any time?
[19:39:30 CEST] <atomnuker> yes, and timebase, and resolution and format and pretty much everything
[19:39:34 CEST] <DHE> shouldn't that be more of a demuxer's job?
[19:51:51 CEST] <cone-295> ffmpeg 03Marton Balint 07master:b406f387c809: avcodec/noise_bsf: add support for dropping packets
[19:53:17 CEST] <BBB> kierank: no, source is const
[19:53:34 CEST] <tmm1> i'm seeing that on some platforms, the mediacodec mpeg2 decoder deinterlaces as well and outputs at double the framerate
[19:54:10 CEST] <BBB> kierank: this isnt so much a convention but a necessity, because the previous thread expects the contents not to change under its feet while the current frame is decoding concurrently with the next frame
[19:54:13 CEST] <nevcairiel> you can change the framerate, but you cant really convince the caller to update its timebase so you're probably screwed
[19:54:25 CEST] <kierank> BBB: yeah, seems bufferrefs are the only way to do what I want
[19:54:25 CEST] <BBB> kierank: so allowing to update the source context would open 10 new cans of worms, IMO
[19:54:55 CEST] <BBB> why do you need to zero the pointer in thread 1?
[19:55:03 CEST] <BBB> I mean, I probably understand the problem oorly
[19:55:14 CEST] <BBB> but it soudns like you have a way forward so Id just go try it out ;)
[19:55:31 CEST] <BBB> oh right michaelni had a good idea
[19:55:40 CEST] <BBB> I think hes right
[20:07:26 CEST] <mateo`> tmm1: wouldn't it be better to just rescale the frame pts (if you have the correct framerate in the first place) ?
[20:11:53 CEST] <tmm1> looks like framerate and time_base are both set to {0,1} in mediacodecdec
[20:11:59 CEST] <tmm1> so the only thing being used is pkt_timebase?
[20:15:33 CEST] <mateo`> yes
[20:20:57 CEST] <tmm1> what i'm seeing is if i input two frames with ts=1 and ts=3, on the output side i get four frames with ts=1 2 3 4
[20:22:08 CEST] <tmm1> seems like that would just work since we rescale the pts back to the pkt_timebase no?
[20:22:44 CEST] <kierank> 6:54 PM <"BBB> why do you need to zero the pointer in thread 1? --> i've noticed that it still stays around during non mod 2 thread counts otherwise
[20:24:23 CEST] <mateo`> tmm1: that should work
[20:30:06 CEST] <ubitux> michaelni: since almost every remaining tsan issue seems to come from mpeg(4?), are you going to look into this?
[20:30:33 CEST] <ubitux> (since you're likely the maintainer of this code, and you like tools who raise C errors ;))
[20:30:56 CEST] <ubitux> it would be nice to have a clean tsan for the frame threading
[20:32:57 CEST] <ubitux> http://fate.ffmpeg.org/report.cgi?time=20170709010307&slot=x86_64-archlinux-gcc-tsan
[20:33:55 CEST] <ubitux> slice threading is still a bit more racy, but if at least we could have the frame threading instance green
[20:34:02 CEST] <ubitux> that would help detecting new races
[21:06:24 CEST] <michaelni> ubitux, need to install gcc7 first, my gcc 6 tsan seems to have stoped working after a recent update
[21:07:04 CEST] <iive> michaelni: there is bug that nasm and tsan doesn't play well, something with debug info
[21:07:57 CEST] <michaelni> hmm, that could be it too
[21:10:31 CEST] <ubitux> michaelni: yeah, you just need to --x86asmexe=yasm
[21:10:47 CEST] <ubitux> assuming you're refering to the lack of symbols
[21:10:57 CEST] <ubitux> see https://trac.ffmpeg.org/ticket/6516
[21:14:48 CEST] <atomnuker> --as=nasm still works
[21:14:53 CEST] <atomnuker> *yasm
[21:16:21 CEST] <nevcairiel> --as controls something else, doesnt it
[21:17:54 CEST] <jamrial> atomnuker: --as is not for nasm/yasm
[21:20:02 CEST] <atomnuker> huh, I guess I've been doing it wrong then
[21:28:03 CEST] <kierank> surely with av_buffer_realloc an a non writeable frame the original needs to be unrefd?
[21:28:06 CEST] <kierank> this makes no sense at all
[21:32:38 CEST] <kierank>  * @note the buffer is actually reallocated with av_realloc() only if it was
[21:32:38 CEST] <kierank>  * initially allocated through av_buffer_realloc(NULL) and there is only one
[21:32:38 CEST] <kierank>  * reference to it (i.e. the one passed to this function). In all other cases
[21:32:38 CEST] <kierank>  * a new buffer is allocated and the data is copied.
[21:32:46 CEST] <kierank> a new buffer is allocated and what happens to the old one?
[21:33:00 CEST] <kierank> the caller can't unref because the caller doesn't know if copying has happened?
[21:45:01 CEST] <BBB> ubitux: michaelni: re mpeg4, I believe all you need to do is change the memcpy(Dst, src, sizeof(MpegEncContext)); in mpv_update_thread_context (or whatever) to only copy the fields that are needed in the next thread
[23:52:07 CEST] <michaelni> BBB, at least padding_bug_score wont work so well as its updated at the end of slices, also this looks like very boring work
[00:00:00 CEST] --- Mon Jul 10 2017