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

[burek]

[00:28:19 CET] <J_Darnley> ugh
[00:28:49 CET] <J_Darnley> I wonder whether speding time removing a factor of 2 from all my memory args will help me see this bug
[01:24:59 CET] <atomnuker> darkapex: sure
[01:43:23 CET] <funman> atomnuker: just found 5edd1f62ca1
[01:58:24 CET] <funman> http://paste.ubuntu.com/15202492/ - my laptop doesn't do vdpau though so i can't test it now
[02:53:21 CET] <jamrial> ubitux, Timothy_Gu: regarding tsan failing, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67308
[02:55:20 CET] <Timothy_Gu> jamrial: seen that bug; not very applicable
[02:55:37 CET] <jamrial> removing -pie solves the failures here
[02:57:00 CET] <jamrial> the configure failures, that is
[02:57:31 CET] <jamrial> which is basically gcc not being able to compile a simple "int main() return 0;" program and making configure bail out
[02:58:13 CET] <Timothy_Gu> oh that
[02:58:32 CET] <Timothy_Gu> never mind, i confused it with helgrind
[03:02:06 CET] <Shiz> huh
[03:02:08 CET] <Shiz> how does that work
[06:17:06 CET] <cone-825> ffmpeg 03Lou Logan 07master:0eb0f29a404e: MAINTAINERS: remove myself as a server maintainer
[07:18:44 CET] <darkapex> atomnuker: Cool, I've edited the wiki. We need to add a backup mentor I guess.
[09:27:18 CET] <cone-565> ffmpeg 03Matthieu Bouron 07master:885a6d83247b: configure: only check dispatch header on darwin
[09:56:28 CET] <cone-565> ffmpeg 03Carl Eugen Hoyos 07master:07eec5e721cc: lavf/img2dec: Skip SOF size when probing jpeg.
[10:21:36 CET] <cone-565> ffmpeg 03Stefano Sabatini 07master:dedcb3c5a5e6: lavf/mux: do not fail in case of non strictly monotonically increasing DTS values for data packets
[11:42:09 CET] <cone-565> ffmpeg 03Paul B Mahol 07master:2a7f056d8807: avfilter/af_astats: do not clear previous sample value
[13:17:50 CET] <cone-565> ffmpeg 03Rostislav Pehlivanov 07master:35346c7b0f7c: vc2enc: mark as FF_CODEC_CAP_INIT_THREADSAFE and align AVCodec entries
[13:25:21 CET] <cone-565> ffmpeg 03Rostislav Pehlivanov 07master:3ef10406e196: vc2enc: correctly zero out coefficient array padding
[13:56:21 CET] <cone-565> ffmpeg 03Rostislav Pehlivanov 07master:7db2e757c594: vc2enc: use FFABS() instead of abs()
[14:46:14 CET] <Daemon404> ... so carl's strategy is to simply never respond to my reply and let the patch die?
[14:46:17 CET] <Daemon404> sigh.
[14:47:57 CET] <RiCON> Daemon404: try sending 20 slightly different versions of it
[14:48:08 CET] <Daemon404> lol
[14:48:11 CET] <Daemon404> close
[14:48:17 CET] <Daemon404> he is at 27 i think
[14:51:23 CET] <wm4> Daemon404: carl probably thinks the problem is solved because he fixed yet another jpg probing failure
[14:51:59 CET] <Daemon404> i still do not understand his objection
[14:52:07 CET] <Daemon404> mimetype should be more accurate that extension full stop
[14:54:44 CET] <wm4> agreed
[15:04:31 CET] <Daemon404> https://www.dropbox.com/s/dtucxsj8wbov3yd/srsly.png?dl=0
[15:04:34 CET] <Daemon404> this is ridiculous
[15:05:53 CET] <Mavrik> :/
[15:10:00 CET] <Daemon404> 17% of all mails in feb are from him replying to himself.
[15:10:48 CET] <Daemon404> almost 300.
[15:15:23 CET] <durandal_1707> lol
[15:22:53 CET] <ubitux> http://ubitux.fr/pub/pics/arm-instruction-explanations.png
[15:23:10 CET] <ubitux> "signed integer saturating doubling multiply accumulate long" should be enough as an explanation
[15:24:34 CET] <ubitux> jamrial: yes i saw the issues
[15:24:37 CET] <ubitux> -s
[15:25:55 CET] <jamrial> ubitux: not sure how to fix the configure check to not add -pie. $gcc_basever isn't set until several lines after the toolchain checks
[15:26:15 CET] <durandal_1707> michaelni: for some reason if filter accepts only le 9bit be format will be converted to 16bit one instead of just swaping bytes
[15:26:29 CET] <ubitux> jamrial: no idea either... version check?
[15:26:41 CET] <ubitux> oh, base version later, meh
[15:26:54 CET] <jamrial> yes, the errors with -pie seem to be with gcc >= 5.2
[15:27:15 CET] <ubitux> well after version gcc basever is defined, you add flags if toolchain
[15:27:19 CET] <jamrial> maybe we could add another case $toolchain later to add -pie
[15:27:23 CET] <jamrial> yeah
[15:27:36 CET] <Daemon404> is there ever a release of gcc that doesnt break something new?
[15:33:45 CET] <Compn> i think there was a prerelease release that we tested on and it worked, but then the final release broke something :P
[15:34:03 CET] <nevcairiel> breaking something in 5.2 is odd though, considering thats a point release
[15:34:09 CET] <nevcairiel> usually only the first release is entirely broken =p
[15:36:09 CET] <Timothy_Gu> durandal_1707: is there a filter to remove background noise in audio?
[15:39:06 CET] <durandal_1707> Timothy_Gu: 2pass in sox and spectral one in audacity
[15:40:11 CET] <durandal_1707> Timothy_Gu: I assume its spread accross multiple frequencies
[15:41:20 CET] <michaelni> durandal_1707, do you have a testcase/cmdline for the 9bit issue  ?
[15:43:44 CET] <durandal_1707> michaelni: see datascope filter, add/use format filter before it
[15:44:09 CET] <Timothy_Gu> durandal_1707: yes, uniformly
[15:44:11 CET] <Timothy_Gu> thanks
[15:51:53 CET] <cone-565> ffmpeg 03Rostislav Pehlivanov 07master:2b811e4605eb: vc2enc: halve allocated table size, refactor and optimize quantization
[16:08:14 CET] <michaelni> durandal_1707, ./ffplay -v 99 matrixbench_mpeg2.mpg -vf format=yuv420p9le,datascope -an
[16:08:22 CET] <michaelni> works fine, uses 9le format
[16:09:04 CET] Action: michaelni rereads what durandal_1707 wrote and realizes tat this isnt what was meant
[16:11:03 CET] <michaelni> durandal_1707,  "-vf format=yuv420p9le,format=yuv420p9be,datascope" still no 16bit
[16:11:38 CET] <michaelni> it would save me alot of time if you would share testcases and i wouldnt have to guess and construct them
[16:29:23 CET] <jya> looks like avfilter_graph_parse2 doesn't handle float parameters depending on the locale. it chokes on a 1.77 aspect ratio as a treat the . as a ,
[16:30:15 CET] <Daemon404> jya, i dont blame it
[16:30:28 CET] <Daemon404> c locales are crap
[16:30:41 CET] <Daemon404> i bet most libraries don't handle it right
[16:30:51 CET] <jya> Qt does :)
[16:30:59 CET] <Daemon404> qt rolls its own.... literally everything
[16:31:04 CET] <Daemon404> the rest of the world uses atoi and pals
[16:31:23 CET] <jya> at first the %f was printing my 1.77 as 1,77 ; which I figure could be worked around
[16:31:42 CET] <Daemon404> i disaree
[16:31:48 CET] <Daemon404> libraries should not be messing with locales
[16:31:54 CET] <jya> but then I get a failure when the buffer filter gets initialised, and that one I can't get around... will have to calculate the ratio myself :(
[16:32:00 CET] <Daemon404> it will affect user applications using said library
[16:32:05 CET] <Daemon404> if we screw around with setting a locale
[16:32:43 CET] <jya> at I guess I would say it's the routine calculating the ratio from the float
[16:32:51 CET] <jya> surely that shouldn't consider the locale
[16:33:06 CET] <Daemon404> it does
[16:33:11 CET] <Daemon404> because it's a filter string.
[16:33:18 CET] <Daemon404> it has to parse the string into a float
[16:33:20 CET] <Daemon404> and radix matters.
[16:33:24 CET] <jya> right.... 
[16:33:53 CET] <Daemon404> why dont you use raptionals btw?
[16:33:56 CET] <Daemon404> rationals*
[16:34:24 CET] <Daemon404> (there's also a new api that doesnt use strings at all, but it's likely too new for you)
[16:35:41 CET] <jya> because the aspect ratio in our MythFrame is a float
[16:36:04 CET] <jya> i'm not working on firefox tonight, porting mythtv to the new ffmpeg 3.0
[16:36:20 CET] <jya> and the removal of avpicture_deinterlace has given me heaps of grief
[16:36:38 CET] <Daemon404> ... why you ever use that at all is a mystery
[16:36:45 CET] <Daemon404> its been deprecated for like 5+ years
[16:37:00 CET] <jya> sure, but to generate a preview picture it's great
[16:37:23 CET] <Daemon404> [15:35] < jya> because the aspect ratio in our MythFrame is a float <-- well, MythFrame sucks then, but you can use av_d2q to convert it to a rational
[16:37:35 CET] <jya> it takes a single AVFrame, deinterlace it well enough and hop you go
[16:37:46 CET] <jya> av_d2q won't choke because of the locale?
[16:37:57 CET] <Daemon404> strings arent involved
[16:37:57 CET] <BtbN> how is there a locale involved in a double?
[16:38:03 CET] <Daemon404> double2rational
[16:38:38 CET] <jya> Daemon404: thanks for that.
[16:38:58 CET] <wm4> BtbN: conversion to/from strings
[16:39:11 CET] <wm4> I find it hilarious that Qt indeed fucks up C string processing by default
[16:39:27 CET] <Daemon404> ?
[16:39:31 CET] <jya> I've spent my entire evening wondering what was going on on why that particular user saw stuff like '77778' unknown filter in his log
[16:39:36 CET] <wm4> Qt sets the locale on start
[16:39:52 CET] <Daemon404> wouldnt that screw with apps usign qt
[16:40:00 CET] <jya> wm4: not at all, for QString, the conversion is define to use the US locale
[16:40:04 CET] <flux> maybe C string processing deserves to be fucked up if setting up locale breaks it ;-)
[16:40:11 CET] <wm4> jya: that's C++
[16:40:12 CET] <jya> if you want to use another locale you use SetNum
[16:40:19 CET] <Daemon404> flux, locales in c is the single biggest mistake in C
[16:40:34 CET] <wm4> counting down to when someone will suggest to convert ffmpeg to C++ because of this
[16:40:58 CET] <flux> seems like most of the time locales in programming languages is the mistake.
[16:41:03 CET] <Daemon404> yep.
[16:41:11 CET] <flux> but I suppose the world seems different form the eyes of a developer..
[16:41:26 CET] <cone-565> ffmpeg 03Rostislav Pehlivanov 07master:bc7beb657499: vc2enc: calculate the minimum slice size only once
[16:46:51 CET] <jamrial> at what point do we declare that mats peterson is spamming the list?
[16:49:53 CET] <Timothy_Gu> jamrial: he admitted it himself
[16:50:26 CET] <jamrial> that's nice. next milestone would be telling him to slow down
[16:51:02 CET] <wm4> we did that before
[16:51:08 CET] <wm4> and he promised to do that before
[16:51:15 CET] <Timothy_Gu> jeez 13 replies...
[16:51:15 CET] <wm4> but the outcome is pretty much the same
[16:59:04 CET] <durandal_1707> michaelni: only single format to be
[17:13:43 CET] <BBB> jya: I put up some example code somewhere to use as drop-in replacement for avpicture_deinterlace using lavfi
[17:13:58 CET] <BBB> jya: if helpful, let me know ill dig it up
[17:15:11 CET] <durandal_1707> tell mats to come here, he would always ask/answer something
[17:16:25 CET] <wm4> the most painless way is just copying the old deinterlace function
[17:16:34 CET] <wm4> others did the same with the lavc resampler
[17:24:33 CET] <Daemon404> wm4, how well do you know mp3dec.c in lavf
[17:25:57 CET] <wm4> relatively well
[17:26:27 CET] <Daemon404> ffmpeg -loglevel debug -f mp3 -i http://chromashift.org/skyfire.ico
[17:26:41 CET] <Daemon404> it just keeps seeking past EOF
[17:26:49 CET] <Daemon404> i dont know if it's infinite or just a really huge amount of seeks
[17:26:59 CET] <Daemon404> if i try the file local, i see:
[17:26:59 CET] <Daemon404> [AVIOContext @ 0x2c54e00] Statistics: 6580 bytes read, 116298 seeks
[17:27:04 CET] <Daemon404> so... could be either.
[17:27:29 CET] <wm4> it scans the start of the file byte by byte
[17:27:38 CET] <Daemon404> it's 6kb.
[17:27:45 CET] <Daemon404> Range: bytes=7953-
[17:27:49 CET] <Daemon404> stuff like that shouldnt happen
[17:28:05 CET] <wm4> it doesn't check for that though
[17:28:13 CET] <Daemon404> why
[17:28:20 CET] <wm4> maybe the return value for ffio_ensure_seekback should really be checked
[17:28:29 CET] <Daemon404> i added checks for that an avio_seek
[17:28:30 CET] <Daemon404> didnt help
[17:28:32 CET] <Daemon404> and*
[17:28:43 CET] <wm4> so where does it "hang"?
[17:28:46 CET] <Daemon404> 416s on every request and it just continues
[17:28:55 CET] <Daemon404> where in the code do you mena?
[17:29:02 CET] <wm4> yeah
[17:29:38 CET] <Daemon404> #17 mp3_read_header (s=0x1ef9280) at libavformat/mp3dec.c:376
[17:29:41 CET] <Daemon404> somewhere in this loop
[17:29:43 CET] <Daemon404> which blames you
[17:29:55 CET] <wm4> I know
[17:30:12 CET] <wm4> but strange that the avio functions return success?
[17:30:22 CET] <Daemon404> hmmm i didnt add it in check()
[17:30:24 CET] <Daemon404> maybe thats it
[17:31:00 CET] <wm4> yeah, I bet it's it
[17:31:09 CET] <Daemon404> wheres that defined
[17:31:15 CET] <Daemon404> such a generic name.. but its not local
[17:32:07 CET] <wm4> lol
[17:32:37 CET] <Daemon404> oh it is
[17:33:26 CET] <Daemon404> it does check avio_seek
[17:33:28 CET] <wm4> so the function must now distinguish invalid headers, and not being able to read data
[17:33:45 CET] <wm4> also, the API it uses can't even signal read failure
[17:33:49 CET] <wm4> avio_rb32()
[17:34:01 CET] <Daemon404> it shouldnt get to rb32
[17:34:08 CET] <Daemon404> because it shouldnt be able to seek that far
[17:34:14 CET] <Daemon404> unless http is special
[17:34:14 CET] <wm4> ok, god
[17:34:17 CET] <wm4> good
[17:36:34 CET] <Daemon404> wm4, i have an idea
[17:36:35 CET] <Daemon404> 1 sec
[17:40:01 CET] <Daemon404> nevermind, didnt work.
[17:40:12 CET] <Daemon404> i think
[17:44:43 CET] <wm4> I can take a closer look later
[17:44:46 CET] <Daemon404> http://sprunge.us/XEHf
[17:44:48 CET] <Daemon404> was not enough
[17:44:52 CET] <Daemon404> same issu
[17:45:20 CET] <wm4> check() is allowed to fail, because it returns whether the mp3 header is valid
[17:45:31 CET] <wm4> so skipping N bytes will have check() fail N times
[17:45:43 CET] <Daemon404> im not sure what to do then
[17:45:48 CET] <wm4> so it needs to distinguish wrong header and failed seek
[17:46:04 CET] <wm4> I wonder if check() returning 0 can happen currently
[17:46:42 CET] <Daemon404> ugh
[18:02:02 CET] <Daemon404> wm4, fixed i think
[18:02:10 CET] <ubitux> so i just stopped being an idiot, dropped half of the asm, and made the code twice faster
[18:03:49 CET] <kurosu> "How I learned to stop worrying and love the Bomb^W^W swscale"
[18:04:54 CET] <wm4> but removing asm must make it slower!
[18:05:05 CET] <wm4> what heresy
[18:05:22 CET] <ubitux> for yuv420p, nv12 and nv21, i was factoring the chroma premultiplying
[18:05:37 CET] <ubitux> so we wouldn't need to read twice the chroma, and do all the mul 
[18:05:42 CET] <ubitux> twice
[18:06:08 CET] <ethe> michaelni: What does the list() notation mean here? http://guru.multimedia.cx/small-tasks-for-ffmpeg/ (assuming you are the michael that posted this)
[18:06:13 CET] <ubitux> but apparently, the cpu didn't like at all reading 2 lines of chroma, and writing 2 lines of rgba in parallel 
[18:06:27 CET] <ubitux> and re-doing all the mult, add, and reading made the code twice faster
[18:06:30 CET] <ubitux> ...and twice simpler
[18:06:37 CET] <ubitux> we should probably do that to the armv7
[18:06:51 CET] <ubitux> and with all the extra reg available, we can probably avoid some bubbling
[18:08:49 CET] <Daemon404> wm4, ill send a patch
[18:29:35 CET] <michaelni> ethe, thats from 2007, thats a long time ago, but theres an example
[18:30:01 CET] <hawken> uuu ubitux :D gcc always beats asm these days
[18:30:41 CET] <michaelni> ethe, the example should explain the list
[18:31:28 CET] <hawken> ubitux: are there things you simply cannot do in C? In my experience gcc always seems to find the best way, but I haven't exactly written video encoders either
[18:36:50 CET] <Daemon404> hawken, any sort of nontrivial SIMD
[18:36:57 CET] <Daemon404> or even just SIMD which is not broken.
[18:37:36 CET] <Shiz> lidt/lgdt is hard in C
[18:37:45 CET] <Shiz> or even cli/sti
[18:41:41 CET] <ethe> michaelni: "thats from 2007" it doesnt look like the huffman table generation has changed since 2001 though, so it's still an improvement that could be made. "the example should explain the list" should. Maybe I'll just come back to it later. I want to help, but I just.. cant :/
[18:42:39 CET] <TD-Linux> bsr, but maybe gcc can infer it nowadays
[18:44:50 CET] <michaelni> ethe, with 2007 i meant i dont remember exactly 
[18:46:10 CET] <michaelni> ethe, theres also a wikipedia article linked but wikipedia had the tendency to be "not so good" for algorithm descriptions often imho
[18:51:26 CET] <Mavrik> Daemon404, is SIMD so bad even with GCC 5.x / Clang 3.6 ?
[18:52:11 CET] <JEEB> no compiler can know from the C code all of the optimizations it can take in a specific case
[18:52:24 CET] <JEEB> all the assumptions etc
[18:52:51 CET] <JEEB> otherwise people wouldn't be writing hand-written asm
[18:53:07 CET] <Mavrik> Mhm, I had no idea about current state of that.
[18:53:14 CET] <Mavrik> Are intrisics also still a horrible idea?
[18:54:10 CET] <JEEB> intrinsics aren't horrible per se, just that they aren't as good as actual asm functions where you handle the regs and all. that said, you can get the big part of the speed-up with just intrinsics
[18:54:32 CET] <JEEB> that's why people usually don't bother writing actual asm if they have already written optimizations with intrinsics
[18:54:36 CET] <JEEB> see: openhevc
[18:54:42 CET] <Mavrik> Mhm, I was looking at them to try to make the pain of supporting both NEON and SSE a bit smaller.
[18:56:06 CET] <michaelni> ethe, the lists are lists of symbol piles if you want to call them that way, each pile has a integer representing occurance, but i dont really remember the algortithm/why this works
[18:56:39 CET] <michaelni> id have to think about it but have no time atm
[19:04:01 CET] <ethe> I know why, and how visually--I'd just have to spend a bit of time to work out the code for it. I'm also a little confused about what the ff_mjpeg_build_huffman_codes() function does if it doesnt build optimal huffman codes. Again, I'll probably have to read up on the spec to understand what exactly to do
[19:04:16 CET] <JEEB> mateo`: I will try your new patch set today :) it seems like v2 works nicely - the biggest issue right now seems to be catching decoding failures
[19:08:44 CET] <wm4> isn't continue at the end of a for/while loop always a NOP, or did my brain fully decay now
[19:12:39 CET] <michaelni> ethe, ff_mjpeg_build_huffman_codes() takes a list of symbol lengths and assigns them binary codes of that length
[19:12:56 CET] <michaelni> ethe, feel free to send a patch to document it
[20:20:13 CET] <cone-565> ffmpeg 03Michael Niedermayer 07master:410f717ff644: avcodec/utils: Merge identical if conditions
[20:20:14 CET] <cone-565> ffmpeg 03Michael Niedermayer 07master:7a8ab57cf1fc: fate: Add test for packed mp3 in mp4 demuxing
[20:26:13 CET] <ubitux> hawken: well, 60ms is still better than 500
[20:26:26 CET] <ubitux> simd isn't "just asm"
[20:26:54 CET] <ubitux> and there is no way gcc is going to generate better code than this here, it has not enough information about the constraints
[20:29:27 CET] <durandal_1707> anybody against pushing datascope?
[20:31:50 CET] <J_Darnley> What did I miss regarding asm/simd?
[20:32:32 CET] <J_Darnley> oh is someone trying to sell us on intrisics?
[20:32:42 CET] <J_Darnley> *intrinsics
[20:33:25 CET] <JEEB> lol
[20:39:36 CET] <TD-Linux> Mavrik, intrinsics are instruction set specific, you still have to write one set for NEON and one for SSE
[20:40:30 CET] <JEEB> they are pretty much SIMD functions, and then the compiler tries to map them within the C/C++
[20:40:35 CET] <wbs> TD-Linux: actually, intel have written an arm_neon.h which is implemented with sse intrinsics, so you can build neon intrinsics code for x86
[20:40:38 CET] <JEEB> (register etc. wise)
[20:40:53 CET] <JEEB> oh, that case :D
[20:40:55 CET] <wbs> they claim that it actually still gives you some sort of speedup, but it depends a lot on how the code is designed. when I tried it, it made things slower than C
[20:41:00 CET] <TD-Linux> wbs, sounds awful :)
[20:41:07 CET] <JEEB> hah
[20:41:13 CET] <wm4> nice try Intel
[20:41:31 CET] Action: TD-Linux is a bit surprised that they didn't write it the other way around
[20:41:47 CET] <wbs> I guess the main target is to get better opts for android apps for x86
[20:41:57 CET] <wm4> TD-Linux: they want people to write intel code
[20:42:01 CET] <wbs> which primarily are designed for arm, but to be able to bring some of those simd opts over to x86
[20:42:26 CET] <Mavrik> wbs, oh I actually tried those
[20:42:38 CET] <Mavrik> Intel built that for Android so people would actually port .so stuff to x86
[20:42:38 CET] <TD-Linux> wm4, right, which is why I suggested the other way around
[20:42:42 CET] <Mavrik> It's slow as arse.
[20:42:44 CET] <Mavrik> :)
[20:42:53 CET] <TD-Linux> the thor video codec has a "instrinsics abstraction layer" that is similar
[20:43:50 CET] <TD-Linux> it works quite a bit better, but it has to have rather high level abstractions for e.g. SAD and it's still intrinsics
[21:45:09 CET] <BBB> hm right so the google guy didnt test his patches
[21:45:11 CET] <BBB> that kind of sucks
[21:45:57 CET] <Daemon404> BBB, do you know why he puts everything in |these|
[21:46:09 CET] <BBB> probably a java'ism?
[21:46:17 CET] <Daemon404> ive never seen such a thing in java
[21:46:25 CET] <Daemon404> but my experience is limited
[21:47:35 CET] <BBB> it looks vaguely familiar
[21:47:38 CET] <BBB> but I dont know from what
[21:53:16 CET] <Shiz> ruby-ism?
[21:53:18 CET] <peloverde> It's a chromism
[21:53:27 CET] <jkqxz> I assume those patches are mainly going for the "data races are undefined behaviour, so we must remove them whatever the cost because the compiler might be able to optimise it to make demons fly out of our noses", ignoring the fact that it could only cause a problem with DS9K levels of malice involved.
[21:55:11 CET] <rcombs> compilers _do_ get pretty malicious about data races, though
[21:56:48 CET] <jkqxz> The die one, for example, pretty much requires the compiler to use the undefined behaviour to deduce that there can't be any other threads and therefore eliminate most of the code.
[21:59:10 CET] <BBB> the die one is the least malicious one, since it doesnt introduce new lock/unlock pairs
[21:59:20 CET] <BBB> I dont have major issues with that one, only half-major'ish
[21:59:32 CET] <BBB> the other two, particular the one I responded two twice, I have more serious issues with
[22:01:43 CET] <jkqxz> The die one is correctly fixed by making die relaxed atomic (which is how the compiler is already treating it if it isn't absurdly malicious).  The locking and extra variables are not doing anything useful.
[22:01:53 CET] <cone-565> ffmpeg 03Clément BSsch 07master:805685fffd31: Kill timed SSA
[22:01:54 CET] <cone-565> ffmpeg 03Clément BSsch 07master:294128212410: lavc: allow subtitle text format to be ASS without timing
[22:01:55 CET] <cone-565> ffmpeg 03Clément BSsch 07master:30e76853608f: lavc/options: add ass_ro_flush_noop to flags2
[22:01:56 CET] <cone-565> ffmpeg 03Clément BSsch 07master:6433618dc01c: ffmpeg: set sub_text_format to ass (without timing) by default
[22:01:57 CET] <cone-565> ffmpeg 03Clément BSsch 07master:fa2df3a40124: lavfi/ass: use ass_process_chunk() instead of ass_process_data()
[22:01:58 CET] <cone-565> ffmpeg 03Clément BSsch 07master:22ebbda63725: lavc: deprecate decoded ass subtitles with timings
[22:02:54 CET] <wm4> whoop
[22:03:43 CET] <Daemon404> doesnt it use soon-to-be-deprecated APIs =p
[22:03:55 CET] <wm4> which does?
[22:04:08 CET] <Daemon404> avctx->time_base iirc
[22:04:25 CET] <wm4> isn't it more about _not_ using it
[22:04:40 CET] <Daemon404> i must have misunderstood ubitux then
[22:05:13 CET] <ubitux> Daemon404: so decoders were using it to rescale the timing
[22:05:26 CET] <ubitux> now most of them do not do it anymore
[22:05:41 CET] <ubitux> and it's now done in lavc/utils in the factorized code
[22:05:53 CET] <ubitux> which will be deleted at next bump
[22:06:02 CET] <Daemon404> ic
[22:06:06 CET] <ubitux> some decoders still actually do use it: ccaption and zvbi
[22:06:46 CET] <ubitux> anyway, any comment on doc/APIChanges is welcome, I didn't ask for a review of this (sorry!)
[22:07:03 CET] <ubitux> (last 2 entries)
[22:10:37 CET] <ubitux> i feel like i just removed a cancer from my ass
[22:10:40 CET] <ubitux> this shit was really insane
[22:11:04 CET] <ubitux> we can now work on moving subtitles to lavu
[22:11:14 CET] <ubitux> and integrates them in lavfi
[22:14:22 CET] <BBB> jkqxz: Ive had conversations with these tsan people in the past, I really want them to move away from tsan and implement something akin to MS chess, but they refuse and tell me Im delusional, obsctructive, uninformed and stupid
[22:14:32 CET] <BBB> (in nice words, of course)
[22:15:40 CET] <wm4> how nice
[22:15:57 CET] <cone-565> ffmpeg 03Clément BSsch 07master:b5451d88cf8b: lavc: reindent a few decoders after previous commits
[22:16:01 CET] <wm4> ubitux: that means AVSubtitle must be moved to AVFrame
[22:16:03 CET] <wm4> somehow
[22:16:19 CET] <ubitux> wm4: so you really think we should do that?
[22:16:29 CET] <wm4> how else would you do it
[22:16:32 CET] <ubitux> like, using extended_data as AVSubtitlesRect or sth?
[22:16:37 CET] <wm4> lavfi is pretty much hardcoded to use AVFrame for everything
[22:17:00 CET] <ubitux> right, well
[22:17:02 CET] <ubitux> api is private
[22:17:13 CET] <ubitux> for the most part
[22:17:23 CET] <ubitux> so it could technically be adjusted to AVSubtitles
[22:17:35 CET] <ubitux> now i'm not against AVFrame as holder
[22:17:44 CET] <ubitux> i have a few concerns though
[22:17:46 CET] <ubitux> but well
[22:17:51 CET] <ubitux> why not really
[22:18:06 CET] <wm4> in its simplest form AVFrame.data[0] could point to a AVSubtitle
[22:18:37 CET] <ubitux> i'd go for AVFrame.extended_data[] being all the rects
[22:18:50 CET] <ubitux> and AVFrame holding all the info we currently have in AVSubtitle
[22:19:17 CET] <wm4> I don't know, maybe
[22:19:36 CET] <ubitux> i need a little break from subtitles for a while though :D
[22:21:47 CET] <BBB> michaelni: you want it split so one patch introduces the bhaviour change (drop packet after BSF if size==0/num_side_data_elements==0), and one to introduce the new vp9 BSF?
[22:22:19 CET] <cone-565> ffmpeg 03Paul B Mahol 07master:42c5e1cc2ad9: avfilter: add datascope filter
[22:23:10 CET] <ubitux> it's very nice to see someone working on threading!
[22:23:31 CET] <wm4> where
[22:23:55 CET] <ubitux> Wan-Teh Chang, ml
[22:24:05 CET] <ubitux> someone at google apparently
[22:24:13 CET] <michaelni> BBB, yes, or lavc/lavf/ffmpeg, also some version bumps are likely needed
[22:24:14 CET] <ubitux> trying to calm down the tsan furry
[22:24:16 CET] <wm4> yeah, magnitudes of slowdown for minor correctness changes
[22:24:21 CET] <BBB> hehehe
[22:24:30 CET] <BBB> now now now, he didnt test his changes
[22:24:31 CET] <ubitux> probably a lock design mistake
[22:24:43 CET] <wm4> ubitux: I think this code should use proper atomics
[22:24:51 CET] <BBB> he probably didnt know that youre supposed to test changes or that some people use threading to speed complicated things up rather than just for aesthetics
[22:24:53 CET] <wm4> instead of x86 maybe-it-works-atomics
[22:24:54 CET] <ubitux> i think so too
[22:25:19 CET] <wm4> BBB: maybe he did test it, just not for performance impact
[22:25:19 CET] <BBB> and his complaint about atomics is right, on arm atomics may not always be as speed-optimal as on x86
[22:25:54 CET] <BBB> michaelni: hm& minor or micro?
[22:26:52 CET] <michaelni> strictly it probably needs minor
[22:27:07 CET] <BBB> okiedokie
[22:32:00 CET] <jkqxz> It's only a possible performance issue because the atomics libavutil offers are sequentially consistent (i.e. barrier ALL the memories!).  Sequential consistency is totally overkill for almost everything.
[22:32:35 CET] <wm4> true
[22:32:57 CET] <wm4> too bad we can't require C11 atomics
[22:33:00 CET] <jkqxz> C11 required to build ffmpeg, anyone?
[22:33:10 CET] <jkqxz> Yeah :)
[22:36:12 CET] <ubitux> we have atomic_{gcc,suncc,win32}.h
[22:36:16 CET] <ubitux> we can add atomic_c11.h
[22:36:27 CET] <ubitux> or is it abi incompatible?
[22:36:37 CET] <BBB> why not just add the atomic calls you guys think we need?
[22:36:43 CET] <wm4> no, the problem is about exposing all the different barrier modes
[22:36:51 CET] <BBB> yes
[22:36:53 CET] <BBB> so
[22:36:58 CET] <BBB> why not add the appropriate ones?
[22:37:13 CET] <kierank> michaelni: so how come you didn't write a rgb_to_a function for GBRAP12?
[22:37:21 CET] <BBB> Ive looked at c11 and chrome also has an amazing assortment of different calls doing the same thing approximately with different barriers
[22:45:58 CET] <michaelni> kierank, i did write planar_rgb##nbits##endian_name##_to_a
[22:46:06 CET] <kierank> oh right
[22:46:10 CET] <jkqxz> Examining things and changing them to relaxed atomics to remove data race complaints is a lot of effort to go to to make no difference whatsoever (since exactly the same code would be generated unless the compiler was going to huge effort to screw you over).
[22:49:04 CET] <BBB> you dont have to do it
[22:49:08 CET] <BBB> this google guy can do it for you!
[22:50:47 CET] <jkqxz> Come to think of it, it does sound like an ideal project to pad out the GSoC long tail of things that noone would ever pick...
[22:51:28 CET] <ubitux> i think we need someone really competent on this issue
[22:51:38 CET] <ubitux> it's a bit too sensible imo
[22:51:53 CET] <ubitux> (and complex)
[22:55:43 CET] <wm4> there _are_ talented students
[22:55:55 CET] <wm4> they just don't seem to look at ffmpeg too often
[22:56:25 CET] <J_Darnley> Because its written in C and not ${FLAVOUR_OF_THE_MONTH}
[22:57:26 CET] <J_Darnley> Or because it deals with boring bitmaps and not text strings someone enters into a webpage
[22:58:35 CET] Action: J_Darnley is perhaps too cynical
[22:59:38 CET] <jamrial> so i'm writing resample simd for the missing fmt, s32, and just noticed it needs to shift an int64_t by 30. problem is that there's only a logical quadword right shift sse2 instruction
[23:00:01 CET] <jamrial> since after shifting i only need the lower dword, it should be functionally the same, right?
[23:00:48 CET] <J_Darnley> if you immediately truncate it sounds fine
[23:01:19 CET] <proxima> hi kierank, have you received my submission regarding video fuzzing?
[23:01:20 CET] <jamrial> yeah, pminsd+pmaxsd right after shifting
[23:02:01 CET] <kierank> proxima: no, what is your email name and address
[23:02:51 CET] <proxima> kierank, its swetarani3007 at gmail.com (signed as Sweta Rani)
[23:03:35 CET] <kierank> Ah I mixed you up with someone else
[23:03:41 CET] <kierank> yes I got that
[23:03:50 CET] <kierank> you should file bug reports on trac.ffmpeg.org with the crashes you found
[23:04:18 CET] <kierank> but make sure they are crashes and not just that you don't have memory
[23:04:25 CET] <kierank> so segfaults
[23:04:48 CET] <proxima> okay 
[23:05:59 CET] <proxima> thanks, will do it and report you soon 
[23:06:29 CET] <wm4> ubitux: I'm disappointed, my code still works
[23:06:48 CET] <ubitux> wrt sub/ass?
[23:06:55 CET] <ubitux> the default isn't changed
[23:06:59 CET] <ubitux> you need to force the option
[23:07:39 CET] <wm4> I know
[23:07:49 CET] <ubitux> but it still works anyway?
[23:07:58 CET] <wm4> well that was mostly ironic
[23:08:04 CET] <wm4> as in, nothing broke
[23:08:12 CET] <proxima> kierank: were the steps adopted by me correct? 
[23:08:16 CET] <kierank> yes
[23:08:27 CET] <kierank> I think fuzzing h264 will be hard to find crashes though
[23:08:35 CET] <kierank> I would find a more obscure codec on samples.ffmpeg.org
[23:08:44 CET] <ubitux> wm4: well, glad to hear it :)
[23:08:56 CET] <proxima> yeah i got seg faults for images but could not get for video
[23:09:16 CET] <proxima> okay , i will search for better one
[23:09:19 CET] <kierank> proxima: images is fine
[23:09:43 CET] <kierank> proxima: do you understand the goal of the outreachy project?
[23:11:38 CET] <proxima> yes, as I read we need to find out bugs caused due to fuzzing(by tools like zzuf and afl-fuzz). Next we need to build a platform so that anyone can test their projects in similar fashion. Is this right?
[23:12:27 CET] <kierank> not quite
[23:12:38 CET] <wm4> ubitux: wait, it still can output multiple ASS lines per decode?
[23:12:54 CET] <kierank> proxima: the platform is there to test whether individual commits broke files with fuzzin
[23:12:58 CET] <kierank> -g
[23:13:09 CET] <kierank> at the moment we just fuzz random files
[23:13:42 CET] <kierank> we need to do this more systematically
[23:14:01 CET] <wm4> ubitux: and the duration is always in MS??
[23:14:19 CET] <proxima> we need to channelize it such that all the commits gets tested excluding unchanged files.
[23:14:34 CET] <kierank> proxima: basically we need to make sure that only the correct files are fuzzed per commit
[23:14:42 CET] <kierank> so a commit to jpeg wouldn't fuzz png for example
[23:15:13 CET] <proxima> what do you mean by correct files? 
[23:15:47 CET] <kierank> well in the set of files (known as a corpus) we have all sorts of files: images, video etc
[23:16:02 CET] <kierank> but we would only want to fuzz jpeg files if jpeg was changed
[23:16:04 CET] <kierank> not the whole thing
[23:16:54 CET] <kierank> the whole corpus
[23:17:13 CET] <proxima> okay, and one thing more that it will be fully automatic to detect that which files have changed and then fuzz those particular ones?
[23:17:58 CET] <kierank> yes we could do this by parsing the commit message or by looking at which files have changed
[23:19:02 CET] <proxima> any thing more i need to know?
[23:19:51 CET] <kierank> you should look at fffuzz
[23:20:18 CET] <kierank> problem is that when you fuzz using ffmpeg the application you're basically just fuzzing probing
[23:20:38 CET] <kierank> but if you are finding crashes already you are doing well
[23:21:18 CET] <ubitux> wm4: i don't know if any decoder does, but i would say it could (they would be at the same time though)
[23:21:23 CET] <rcombs> valid header, then fuzz after that
[23:21:26 CET] <kurosu> kierank, how would you achieve the restricting of tests? dependency tracking? current build system?
[23:21:26 CET] <proxima> this https://github.com/OpenBroadcastSystems/fffuzz
[23:21:28 CET] <ubitux> wm4: i didn't change that api (ms)
[23:21:49 CET] <kierank> kurosu: do that in the corpus
[23:21:57 CET] <kierank> so h264 just fuzzes h264
[23:22:04 CET] <wm4> ubitux: that seems strange, so the start time stamp is in the timebase, while the duration is in ms?
[23:22:17 CET] <ubitux> yeah, i don't know why it's done like that
[23:22:25 CET] <ubitux> i kept the structure as is
[23:22:26 CET] <kurosu> kierank, yes, but how do you map a source file to a subsystem/codec/... ?
[23:22:36 CET] <kierank> kurosu: plan was to use the commit message
[23:22:36 CET] <ubitux> wm4: and yeah it's stupid IMO
[23:22:44 CET] <wm4> ubitux: maybe this is something that could be fixed when going to AVFrame
[23:22:46 CET] <kierank> kurosu: and ignore utils etc
[23:23:03 CET] <kierank> not ideal but on average the crashes are in the codec or demuxer
[23:23:19 CET] <kurosu> kierank, ok, sounds somewhat fragile, but as fragile as a Makefile solution
[23:23:21 CET] <ubitux> wm4: so for libass, i'm doing this:
[23:23:22 CET] <ubitux> const int64_t start_time = av_rescale_q(sub.pts, AV_TIME_BASE_Q, av_make_q(1, 1000));
[23:23:24 CET] <ubitux> const int64_t duration   = sub.end_display_time;
[23:23:37 CET] <kierank> kurosu: the worst that could happen is that the wrong files are fuzzed
[23:23:40 CET] <kierank> no harm in that really
[23:24:10 CET] <ubitux> gtg
[23:54:28 CET] <kierank> durandal_1707: is it possible in libavfilter to get volume loudness overlaid onto video
[23:55:45 CET] <durandal_1707> overlay+showvolume?
[23:57:00 CET] <durandal_1707> define what you want exactly
[23:59:55 CET] <Compn> maybe he wants volume bar like mplayer has ?
[00:00:00 CET] --- Sat Feb 27 2016