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

[burek]

[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/FFmpegVideoDecoder.cpp
[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