[00:10:20 CEST] <cone-797> ffmpeg 03James Almer 07master:98d7ad085e20: avcodec/exrdsp: improve the ExrDSPContext->reorder_pixels prototype [00:10:21 CEST] <cone-797> ffmpeg 03James Almer 07master:7323c896b2cb: checkasm: add an exrdsp test [03:26:17 CEST] <cone-550> ffmpeg 03Carl Eugen Hoyos 07master:3118e81f8606: lavc/frame_thread_encoder: Do not mix variable declaration and code. [05:19:50 CEST] <cone-550> ffmpeg 03Thomas Mundt 07master:4492237e333c: fate: add tinterlace lowpass filtering tests [05:19:51 CEST] <cone-550> ffmpeg 03James Almer 07master:3af1060319b4: avfilter/tinterlace: Simplify checks for lowpass filtering flags [09:26:39 CEST] <cone-896> ffmpeg 03Tobias Rapp 07master:35d6be199a55: avformat/mxfenc: fix aspect ratio when writing 16:9 DV frames [09:26:40 CEST] <cone-896> ffmpeg 03Tobias Rapp 07master:147bface1a56: fate: add mxf_dv25/dvcpro50 regression tests [09:26:41 CEST] <cone-896> ffmpeg 03Tobias Rapp 07master:3ffd3b7f5f13: avformat/mxfenc: cosmetic changes [17:48:30 CEST] <BBB> jya: re that bug report, can you point me again at the file where the ffvpx decoders are accessed in the webgit of mozillas source tree? [17:48:38 CEST] <BBB> jya: that last comment might be helpful [18:25:53 CEST] <kurosu> jamrial / Gramner: regarding ST{ART,OP}_TIMER vs checkasm, does checkasm try to bypass cache when writing the data to be read? [18:26:26 CEST] <Gramner> no, pretty much all of checkasm is L1 [18:26:38 CEST] <kurosu> the former causes I guess register pressure, while the later doesn't have the actual memory access of a real decoder [18:26:53 CEST] <Gramner> real world scenarios will be memory bottlenecked in many cases [18:27:09 CEST] <kurosu> I know you and a lot of people prefer using checkasm though [18:27:17 CEST] <kurosu> (for convenience maybe) [18:28:24 CEST] <kurosu> does arm have data cache? and a way to bypass it? Not sure using some form of movnt* is worth the hassle anyway [18:28:41 CEST] <kurosu> for x86 [18:28:49 CEST] <Gramner> (START|STOP)_TIMER isn't really an accurate measurement either due to out-of-order execution [18:29:14 CEST] <kurosu> isn't rdtsc imply a fence ? [18:29:17 CEST] <kurosu> *doesn't [18:29:57 CEST] <Gramner> rdtsc;lfence is. but by adding it it's no longer a real scenario [18:30:43 CEST] <Gramner> it's like quantum physics. by measuring you change the outcome [18:31:10 CEST] <kurosu> yeah, each have its drawback [18:31:14 CEST] <kurosu> *has [18:31:43 CEST] <kurosu> I've just discovered rdtscp [18:31:56 CEST] <kurosu> anyway, same issue [18:31:58 CEST] <Gramner> rdtscp is basically the same as rdtsc;lfence [18:32:04 CEST] <Gramner> (on most cpus) [18:33:09 CEST] <iive> STOP_TIMER executes a fence [18:33:34 CEST] <iive> so you need to do a null function in order to know the specific OOE depth [18:34:04 CEST] <iive> tht is start and then stop timer without anything between them. [19:23:22 CEST] <jya> BBB: I'm not sure I understand [19:23:44 CEST] <BBB> the code that calls avcodec_decode_video2(), where is it located? [19:30:53 CEST] <jya> Dom/ [19:31:15 CEST] <jya> Sorry I'm driving :) [19:32:49 CEST] <jya> BBB: https://dxr.mozilla.org/mozilla-central/source/dom/media/platforms/ffmpeg/FF... [19:33:03 CEST] <BBB> omg this is not urgent please dont type while driving [19:33:05 CEST] <BBB> this can wait [19:33:53 CEST] <jya> Google keyboard sucks at spelling path :) [00:00:00 CEST] --- Tue Sep 19 2017