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

[burek]

[00:00:27 CEST] <nevcairiel> sure
[00:00:59 CEST] <wm4> jkqxz: don't most hwaccels use sw_pix_fmt?
[00:01:36 CEST] <jkqxz> Only first thing on the primary context, which is where it got set.
[00:02:35 CEST] <nevcairiel> i still wonder where it broke
[00:02:36 CEST] <jkqxz> (In get_format and then hwaccel->init, and then donm't touch it after that so it doesn't matter than the other contexts don't have it set.)
[00:02:38 CEST] <nevcairiel> maybe i should bisect
[00:02:49 CEST] <nevcairiel> just need to find a good version
[00:09:34 CEST] <tmm1> jkqxz: do you know offhand if freebsd has an equivalent of /dev/dri for vaapi accel
[00:12:14 CEST] <nevcairiel> jkqxz: as expected it works on some old version .. off to the bisecting!
[00:12:43 CEST] <jkqxz> tmm1:  I believe it's meant to work on FreeBSD, but I've never used it.  So no idea, sorry.
[00:12:54 CEST] <jkqxz> (Do the DRI2 dance and it will tell you where the device is?)
[00:14:58 CEST] <tmm1> what dance is that?
[00:18:11 CEST] <jkqxz> For DRI2 initialisation.  The X server tells you what device you have to open and gives you a cookie to feed to it.
[00:24:19 CEST] <wm4> why use freebsd for multimedia
[00:25:03 CEST] <durandal_170> why not?
[00:25:17 CEST] <wm4> seems like an odd choice
[00:25:19 CEST] <jkqxz> Masochism?
[00:38:09 CEST] <tmm1> freenas is popular for multimedia storage
[00:38:41 CEST] <tmm1> well popular might be an overstatement
[00:38:44 CEST] <tmm1> some people use it
[00:50:16 CEST] <durandal_170> tmm1: iirc freebsd have /dev/dri thats all i know
[00:59:55 CEST] <tmm1> oh yea? ok then maybe i'm just missing some modules or something
[00:59:56 CEST] <tmm1> thanks
[01:02:24 CEST] <durandal_170> drivers for kernel, theres dri.ko but it is auto loaded when needed by other graphic modules
[01:08:17 CEST] <nevcairiel> jkqxz: bisecting blames d59641abfd25a1007bdf4723d952887b1e3619c6 which sounds like it means it just worked by accident before
[01:08:41 CEST] <nevcairiel> (and noone tested 10-bit with threads)
[01:23:32 CEST] <jkqxz> Does 10-bit VP9 work with DXVA2?  ffmpeg_dxva2.c suggests profile 0 only.
[01:24:00 CEST] <nevcairiel> its probably not implemented yet
[01:24:10 CEST] <nevcairiel> i was too lazy since i got the kaby laptop
[01:24:15 CEST] <nevcairiel> should maybe get to that sometime
[01:25:13 CEST] <jkqxz> I'll push the fix, then.
[01:26:06 CEST] <jkqxz> And libav will want it too to avoid future nastiness, I guess.
[01:26:26 CEST] <nevcairiel> yeah sw_pix_fmt should really be consistent everywhere
[01:27:24 CEST] <nevcairiel> they have been  porting vp9 things, maybe they also want hwaccel at some point
[01:44:27 CEST] <cone-056> ffmpeg 03Mark Thompson 07master:ebce1332285b: pthread_frame: Propagate sw_pix_fmt across threads
[09:44:01 CEST] <cone-892> ffmpeg 03Diego Biurrun 07master:0361e4dcb4d3: h264_qpel: x86: Move function with only one instance out of template macro
[09:44:02 CEST] <cone-892> ffmpeg 03Clément BSsch 07master:1ea0df14c367: Merge commit '0361e4dcb4d394c88c33364415a3b8fe315b67d1'
[09:48:59 CEST] <cone-892> ffmpeg 03Vittorio Giovara 07master:17dac56b8fdd: lavu: Rename ycgco color space appropriately
[09:49:00 CEST] <cone-892> ffmpeg 03Vittorio Giovara 07master:bed2c4b2652b: lavc: Add hevc main10 profile to avconv cli
[09:49:01 CEST] <cone-892> ffmpeg 03Clément BSsch 07master:82ad9cbd32c8: Merge commit '17dac56b8fdd80c594c39b76de3f27a7949afbde'
[09:49:02 CEST] <cone-892> ffmpeg 03Clément BSsch 07master:9a60735fa1b7: Merge commit 'bed2c4b2652b1412b584e5545d6dd2ef8c613be0'
[09:52:22 CEST] <cone-892> ffmpeg 03Vittorio Giovara 07master:5be21531119d: hevc: Move hevc_decode_extradata before frame decoding
[09:52:23 CEST] <cone-892> ffmpeg 03Clément BSsch 07master:8ee123ac9a7f: Merge commit '5be21531119d7a97ebc706800d1608272ee5a507'
[09:58:50 CEST] <cone-892> ffmpeg 03Vittorio Giovara 07master:2fe30b4743c0: hevc: Allow parsing external extradata buffers
[09:58:51 CEST] <cone-892> ffmpeg 03Clément BSsch 07master:4eb72961844c: Merge commit '2fe30b4743c0f4c3bdf37b91ae534cafa85e4036'
[10:01:31 CEST] <cone-892> ffmpeg 03Vittorio Giovara 07master:47a795727f54: hevc: Support extradata changes from multiple stsd
[10:01:32 CEST] <cone-892> ffmpeg 03Clément BSsch 07master:5ce02f4c555a: Merge commit '47a795727f5433f5238a8a244cf181f61ea5af2c'
[10:02:26 CEST] <cone-892> ffmpeg 03Vittorio Giovara 07master:de6e2ff3ddf5: mov: Read multiple stsd from DV
[10:02:27 CEST] <cone-892> ffmpeg 03Clément BSsch 07master:5273916700f2: Merge commit 'de6e2ff3ddf506d5b487c2f226cea73e095ad6d1'
[10:12:49 CEST] <cone-892> ffmpeg 03Diego Biurrun 07master:9498237049d1: checkasm: Add --test parameter to check only specific components
[10:12:50 CEST] <cone-892> ffmpeg 03Diego Biurrun 07master:4537647c0429: fate: checkasm: Split monolithic test into individual components
[10:12:51 CEST] <cone-892> ffmpeg 03Clément BSsch 07master:b589e83f435f: Merge commit '9498237049d15812cecb79df47b196c73013908b'
[10:12:52 CEST] <cone-892> ffmpeg 03Clément BSsch 07master:a5c29c608fb8: Merge commit '4537647c0429fe7c8ee655ac3fda856ba67f58a0'
[10:22:58 CEST] <durandal_1707> sorry state of swscale
[10:24:17 CEST] <cone-892> ffmpeg 03Diego Biurrun 07master:59d2b00d2019: configure: Add --quiet command line parameter to suppress informative output
[10:24:18 CEST] <cone-892> ffmpeg 03Clément BSsch 07master:b6c293d5e609: Merge commit '59d2b00d201935c16408a2917957d89a170fe58f'
[10:41:51 CEST] <cone-892> ffmpeg 03Diego Biurrun 07master:67deba8a416d: Use avpriv_report_missing_feature() where appropriate
[10:41:52 CEST] <cone-892> ffmpeg 03Clément BSsch 07master:e3287077ecff: Merge commit '67deba8a416d818f3d95aef0aa916589090396e2'
[10:44:31 CEST] <cone-892> ffmpeg 03Diego Biurrun 07master:a3483f79933e: avconv: Drop stray leftover debug output
[10:44:32 CEST] <cone-892> ffmpeg 03Clément BSsch 07master:adc489adc97f: Merge commit 'a3483f79933e8f1fd99d524e3218688e14c59150'
[11:00:34 CEST] <cone-892> ffmpeg 03Diego Biurrun 07master:576c9003aef0: configure: Improve output wording
[11:00:35 CEST] <cone-892> ffmpeg 03Clément BSsch 07master:6f957710461a: Merge commit '576c9003aef0fe18c0cf8da6e865211610552005'
[11:00:58 CEST] <ubitux> huh, we still have sdl1 support?
[11:01:05 CEST] <ubitux> i thought we didn't need that dep anymore?
[11:02:00 CEST] <ubitux> ah that's just a shorthand
[11:24:57 CEST] <cone-892> ffmpeg 03Diego Biurrun 07master:d1a91ebe4990: configure: Print list of enabled programs
[11:24:58 CEST] <cone-892> ffmpeg 03Clément BSsch 07master:d62606480f41: Merge commit 'd1a91ebe4990001e0800ee9ac54ed2207e4f56ff'
[11:29:09 CEST] <cone-892> ffmpeg 03Clément BSsch 07master:12bfed2fd9ed: configure: remove redundant info
[12:29:39 CEST] <cone-892> ffmpeg 03Michael Niedermayer 07master:c217027c1173: avcodec/mips: fix build
[12:29:40 CEST] <cone-892> ffmpeg 03Michael Niedermayer 07master:5036e214b0e1: avfilter/vf_zoompan: Free out frame on error
[12:29:41 CEST] <cone-892> ffmpeg 03Michael Niedermayer 07master:55d53cb59380: avfilter/avfiltergraph: Check for allocation failure in avfilter_graph_queue_command()
[13:06:39 CEST] <PaoloP> I was told to remove the tab character in doc/Makefile :  http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209460.html    but I see that this Makefile contains other tabs as well (I checked with cat doc/Makefile | grep -P '\t' ). In addition, the coding rules, in the ffmpeg website say: "The TAB character is forbidden outside of Makefiles" (so, I could use the tab for that Makefile). What should I do?
[13:20:17 CEST] <jkqxz> PaoloP:  The tab character is required by Makefile syntax as the first character on lines containing build commands as part of a rule.  All other uses are forbidden.
[13:24:07 CEST] <jkqxz> I guess it isn't actually clear, but the intent is "no tabs anywhere unless absolutely required".
[13:27:36 CEST] <cone-892> ffmpeg 03Michael Niedermayer 07master:1317a9f7aaab: doc/APIchanges: Update
[13:27:37 CEST] <cone-892> ffmpeg 03Michael Niedermayer 07master:fc332f3e29a0: Bump minor versions for staring release/3.3 branch
[13:27:38 CEST] <cone-892> ffmpeg 03Michael Niedermayer 07master:58b867a7cfea: Bump minor versions for master after release/3.3 branchpoint
[13:29:09 CEST] <wm4> michaelni: I don't agree with a release at this time
[13:30:13 CEST] <cone-892> ffmpeg 03Michael Niedermayer 07release/3.3:HEAD: Bump minor versions for master after release/3.3 branchpoint
[13:33:12 CEST] <michaelni> wm4, i just made a release branch, not 3.3 yet, i intend to wait with 3.3 so everyoe can push any fixes in it they want
[13:34:00 CEST] <wm4> we should consider reverting the mp4 edit list patch for the release
[13:35:36 CEST] <michaelni> didnt the author(s) fix the reported issues with that ?
[13:36:06 CEST] <wm4> there are apparently tons of issues he ignored as well
[13:36:26 CEST] <michaelni> please ping him about these
[13:36:44 CEST] <wm4> people did
[13:38:13 CEST] <michaelni> hmm, do you have a link or ticket ? i must have missed this
[13:39:23 CEST] <wm4> no
[13:39:33 CEST] <nevcairiel> many of the issues come from the fact that there are plenty mp4 files out there with semi-broken editlists that worked fine before, and also work fine in other demuxers as they may be smart enough to discard those
[13:39:54 CEST] <nevcairiel> the current code seems extremely strict and easily falls over on slight irregularities
[13:40:05 CEST] <michaelni> nevcairiel, please report this to the author of that code
[13:40:13 CEST] <nevcairiel> <wm4> people did
[13:40:21 CEST] <nevcairiel> he hasnt been active for a couple months now
[13:40:24 CEST] <nevcairiel> not on ffmpeg-devel anyway
[13:41:05 CEST] <wm4> ubitux also mentioned that he's annoyed by how the author treated requests to fix cases
[13:41:42 CEST] <michaelni> nevcairiel, do you have a link ? (we need a reason for a revert, we can revert if its better reverted, ignored regressions should be a reason if there are fewer regressions overall if reverted)
[13:41:57 CEST] <nevcairiel> personally I merged the commit that adds an AVOption to disable the new editlist parsing in my fork and just set that option at all times
[13:42:33 CEST] <michaelni> it wasnt merged in master ?
[13:42:38 CEST] <nevcairiel> dont think so
[13:42:52 CEST] <wm4> someone mentioned that the patch was "wrong", but I don't remember details
[13:43:19 CEST] <nevcairiel> does patchwork not have search
[13:43:29 CEST] <nevcairiel> oh found it
[13:43:38 CEST] <nevcairiel> https://patchwork.ffmpeg.org/patch/2144/
[13:43:39 CEST] <nevcairiel> that one
[13:44:46 CEST] <nevcairiel> it basically falls back to the pre-patch behavior if you set it to 0
[13:44:59 CEST] <nevcairiel> parsing the first entry to get A/V sync info for the basic cases
[13:45:50 CEST] <michaelni> ill run some tests and apply it unless you want me not to ?
[13:46:06 CEST] <nevcairiel> should be fine
[13:46:17 CEST] <nevcairiel> if the option is not touched it shouldnt change anything
[13:47:38 CEST] <nevcairiel> the name feels a bit awkward, but i'm bad at  naming things myself, so not like i have a suggestion
[13:47:47 CEST] <nevcairiel> (name of the option)
[13:49:21 CEST] <wm4> ignore_advanced_editlist? editlist_start_only? editlist_gapless_audio?
[13:52:27 CEST] <michaelni> advanced_editlist? (is shorter) or iam fine with editlist_start_only too if thats accurate what it does
[13:53:13 CEST] <wm4> (no idea what it actually does)
[13:53:40 CEST] <nevcairiel> right now the option is positive (ie. setting it to 1 enables the new code), flipping that around would be more effort, so advanced_editlist sounds fine to me
[13:53:57 CEST] <michaelni> ok
[14:02:26 CEST] <ubitux> i don't think we should release now
[14:02:42 CEST] <ubitux> btw, this is one of the mp4 edit list issue: https://ffmpeg.org/pipermail/ffmpeg-devel/2017-January/205906.html
[14:02:59 CEST] <ubitux> i think we need to merge all the libav stuff before the release
[14:03:14 CEST] <ubitux> otherwise we're going to have to deal with abi/api bumps for half of the stuff
[14:03:30 CEST] <wm4> yeah, just doing a snapshot in between all the merges will make finding/fixing regressions harder too
[14:03:51 CEST] <ubitux> so if people want a release (i do) they should help with the merge
[14:04:00 CEST] <ubitux> but we should not do it in this state
[14:04:03 CEST] <ubitux> IMO
[14:04:15 CEST] <ubitux> btw, jpeg needs fixing
[14:04:26 CEST] <ubitux> and ideally we should shrink the bottom of the doc/libav-merge.txt 
[14:04:54 CEST] <PaoloP> jkqxz: ok (I would suggest to add your explanation to the website too, it clarifies a lot). Then, given that tab is not allowed for this block:  http://paste.ubuntu.com/24287544/ , what do I have to use for indenting it? whitespaces?
[14:05:13 CEST] <ubitux> what do you see around?
[14:05:17 CEST] <ubitux> spaces or tabs?
[14:05:29 CEST] <PaoloP> I see spaces
[14:05:34 CEST] <ubitux> then do the same
[14:06:05 CEST] <PaoloP> ok (it appeared to me a bit strange to add so many spaces  in a Makefile)
[14:07:52 CEST] <iive> imho, it is never good idea to do a release shortly after big merges
[14:07:52 CEST] <ubitux> we do that everywhere
[14:08:12 CEST] <ubitux> and it's an even worse idea to do it in the middle of a merge wave
[14:08:47 CEST] <iive> +1
[14:11:48 CEST] <ubitux> i'm not going to merge anything for a few hours
[14:11:54 CEST] <ubitux> so anyone is welcome to take over
[14:12:06 CEST] <ubitux> ETA: 655
[14:13:11 CEST] <durandal_1707> this is pure bs
[14:15:10 CEST] <iive> 655 seconds? minutes? hours? days?
[14:15:33 CEST] <ubitux> 655 commits
[14:16:16 CEST] <BBB> ubitux: so what shall I do with skipheaders?
[14:16:23 CEST] <BBB> sebastien didnt get back to me
[14:16:43 CEST] <ubitux> i think your first patch actually fixing the compilation was the most correct
[14:16:52 CEST] <iive> oh, eta means estimate time of arrival, so I did assume time.
[14:19:14 CEST] <BBB> ubitux: I dont know if its correct&
[14:19:16 CEST] <cone-892> ffmpeg 03Sasi Inguva 07master:ef71dc794832: lavf/mov.c: Add -advanced_editlist option for mov format.
[14:19:48 CEST] <ubitux> BBB: i'm using linux, i can't help you :p
[14:19:59 CEST] <ubitux> i don't think you should think too much about it
[14:20:16 CEST] <ubitux> if it fixes it for you then you're good to go; it's an include issue
[14:20:25 CEST] <BBB> the problem is that if you compare the two files that use the file (vda.h and videotoolbox.h), their code is not identical in that respect
[14:20:29 CEST] <BBB> so I think the patch is wrogn
[14:20:34 CEST] <BBB> and the header is meant to be no more than a template
[14:21:03 CEST] <ubitux> btw i'm curious: checkheaders is not part of make fate?
[14:21:17 CEST] <BBB> probably isn't
[14:21:26 CEST] <ubitux> that's curious, but ok
[14:21:55 CEST] <ubitux> ah yeah you don't want vda stuff in vt
[14:22:13 CEST] <ubitux> because it will break in xcompile for ios
[14:22:34 CEST] <ubitux> what symbol do you need ?
[14:22:51 CEST] <ubitux> that's weird
[14:23:38 CEST] <ubitux> BBB: i'd rather split again the 2
[14:23:49 CEST] <ubitux> vda will die at some point anyway so it's better if it's split
[14:24:06 CEST] <BBB> I want whoever owns this to make that decision ;)
[14:24:22 CEST] <BBB> I dont want to be in charge of such decisions for stuff I dont (want to) understand
[14:24:29 CEST] <ubitux> drop the patch then
[14:24:53 CEST] <ubitux> leave it to someone else on OSX who cares about VT and VDA
[14:25:11 CEST] <BBB> lol
[14:25:15 CEST] <ubitux> are you going to push the tsan patches?
[14:25:33 CEST] <BBB> working on pushing the approved ones
[14:25:44 CEST] <michaelni> "<ubitux> i don't think we should release now" <- we are very much behind shedule and each merge adds bugs, and there are always new things to add. If we wait for 600 merges now then once they are done there are 300 more maybe 
[14:26:11 CEST] <ubitux> michaelni: the incoming merges contain a major bump
[14:26:18 CEST] <ubitux> are we going to bump again when we reach it?
[14:26:26 CEST] <michaelni> we should release before the bump
[14:26:45 CEST] <ubitux> right, but with all the features in it, not half of it being just merged and broken
[14:26:49 CEST] <cone-892> ffmpeg 03Ronald S. Bultje 07master:f800d6508d7e: dnxhd: initialize DNXHDContext::avctx to each thread's respective one.
[14:26:50 CEST] <cone-892> ffmpeg 03Ronald S. Bultje 07master:9e2050b698b2: codec_desc: mark fraps as an intra-only codec.
[14:26:51 CEST] <cone-892> ffmpeg 03Ronald S. Bultje 07master:73f863d751df: fic: set pict_type/key_frame after (instead of during) slice decoding.
[14:26:52 CEST] <cone-892> ffmpeg 03Ronald S. Bultje 07master:081c21ca55d7: lagarith: assign correct per-thread value to LagarithContext::avctx.
[14:26:53 CEST] <cone-892> ffmpeg 03Ronald S. Bultje 07master:b5300c8ad8c5: h264: don't write to source picture object in ff_h264_ref_picture().
[14:26:54 CEST] <cone-892> ffmpeg 03Ronald S. Bultje 07master:1ddc37051f11: h264: only assign H264Picture::mbaff for first slice.
[14:26:59 CEST] <ubitux> \o/
[14:27:00 CEST] <wm4> doing a release on a not very well-tested merge impacted master really doesn't sound like a good idea
[14:27:22 CEST] <BBB> I have the following unreviewed (I think):
[14:27:24 CEST] <BBB> f4dd2db codec_desc: mark flac/wavpack as intraonly codecs.
[14:27:25 CEST] <BBB> 3c6736e frame_thread_encoder: make task indexing deterministic.
[14:27:26 CEST] <BBB> db82f25 h264: don't sync pic_id between threads.
[14:27:28 CEST] <BBB> 670599c pthread_frame: call update_context_from_user() after acquiring lock.
[14:27:29 CEST] <BBB> ef29413 pthread_frame: allow per-field ThreadFrame owners.
[14:27:30 CEST] <BBB> 71cf3b9 hevc: only write to max_ra and pocTid0 in the first slice.
[14:27:31 CEST] <BBB> d966886 png: split header state and data state in two separate variables.
[14:27:56 CEST] <ubitux> i'm triggering a new gcc-tsan run 
[14:27:59 CEST] <BBB> actually the png one is reviewed and needs some minor revising based on michaelnis review
[14:28:06 CEST] <BBB> wait until the hevc one is in
[14:28:09 CEST] <BBB> that will make hevc clean
[14:28:09 CEST] <ubitux> ok
[14:28:12 CEST] <BBB> can someone review the hevc one?
[14:28:13 CEST] <BBB> its trivial
[14:28:18 CEST] <michaelni> ubitux, when will be the point reached when all features are in but prior the bump?
[14:28:53 CEST] <ubitux> i don't know, i haven't analyzed the 650+ commits
[14:28:54 CEST] <michaelni> i mean is it better to release 3.3 now and 3.4 then ?
[14:29:39 CEST] <michaelni> "now" as in a few days
[14:29:44 CEST] <ubitux> 3.3 will be broken if you release it "now"
[14:29:52 CEST] <ubitux> i know we just introduced a bunch of new things
[14:29:59 CEST] <michaelni> what will be broken ?
[14:30:16 CEST] <ubitux> maybe hwaccel or anything touched by the merges
[14:30:26 CEST] <ubitux> they will be at best incomplete
[14:32:07 CEST] <michaelni> master should not be broken IMO, i mean we shouldnt push commts that break it
[14:32:21 CEST] <ubitux> it's not like i'm pushing bugs on purpose
[14:32:26 CEST] <ubitux> i'm saying there is a risk
[14:33:23 CEST] <michaelni> well, the question is what should we do with the release, can we release 3.3 in a few days or is it actually broken and we need to wait?
[14:34:22 CEST] <ubitux> my take is: it's risky and it will be a "bad" release (incomplete state so hardly maintainable)
[14:34:33 CEST] <ubitux> i don't like the idea of doing a release for the sake of doing a release
[14:35:09 CEST] <michaelni> i expect that with 600 more merges we will be alot more broken than now
[14:35:11 CEST] <ubitux> i think the release will suck, and given we've haven't done one in a while will probably make this release integrated in various distro and will have to maintain that shit
[14:35:29 CEST] <ubitux> it will be more consistent
[14:35:35 CEST] <ubitux> because we're in the middle of a "run"
[14:36:07 CEST] <ubitux> that's my opinion, i'm not going to make that decision
[14:36:36 CEST] <wm4> <michaelni> i expect that with 600 more merges we will be alot more broken than now <- that's a bad attitude
[14:37:13 CEST] <ubitux> michaelni: the point is that in 650+ merge, the merge rate will slow down
[14:37:18 CEST] <ubitux> so it will have time to "stabilize"
[14:37:33 CEST] <ubitux> if you want to make a release, do it from the state before we started merging again
[14:37:59 CEST] <michaelni> ubitux, what hash would that be ?
[14:38:31 CEST] <ubitux> i don't know, around the h264 merges
[14:39:28 CEST] <ubitux> around 591be9e38443a01cea88db787be8a5c9a66c43a2 maybe
[14:40:21 CEST] <ubitux> you also have 0bab78f7e729a76ea7a8cbec7f1de033c52494e8 after that maybe
[14:40:34 CEST] <ubitux> but i don't know
[14:40:43 CEST] <ubitux> there are still a shit ton of stuff to backport
[14:41:07 CEST] <ubitux> anyway, now and for a few weeks is not a good time to release, that's my opinion
[14:41:20 CEST] <ubitux> i mean the tree state of now 
[14:42:52 CEST] <ubitux> maybe people do not agree with that
[14:42:55 CEST] <ubitux> i don't know
[14:42:57 CEST] <ubitux> ask them
[14:47:34 CEST] <michaelni> ubitux, so you think releasing 3.3 from 0bab78f7e729a76ea7a8cbec7f1de033c52494e8 with backports is ok ?
[14:47:58 CEST] <michaelni> does everyone agree to that ?
[14:49:24 CEST] <ubitux> i don't think it makes much sense but at least it's a more stable state
[14:51:36 CEST] <michaelni> ubitux, the question is will there be a better state in the next 1 - 1.5 months ? 
[14:51:56 CEST] <michaelni> if not then i think we should consider making 3.3 from 3 weeks ago if thats more stable
[14:52:29 CEST] <ubitux> if we are able to merge all the 650+ commits and leave it one or two weeks to stabilize, then we can make a new release
[14:52:42 CEST] <ubitux> i can't do that alone though
[14:52:47 CEST] <ubitux> it doesn't only depend on me
[14:53:04 CEST] <ubitux> it also depends on the commit rate of libav during that time
[14:53:09 CEST] <ubitux> and the difficulty of the merges
[14:54:34 CEST] <michaelni> ubitux, so what shall we do ? should i post a RFC mail to the ML about this ?
[14:55:08 CEST] <michaelni> previously we released from a more or less random commit independant of merges
[14:55:11 CEST] <durandal_1707> atomnuker: do you know whats wrong when first pixel of macroblock is darker than rest?
[14:55:42 CEST] <ubitux> michaelni: i don't know what to do. no release is fine with me. doing a release of the current state is not a good idea. doing a release of a previous state should be ok but i don't see the point.
[14:55:51 CEST] <atomnuker> durandal_1707: that is an odd problem
[14:55:54 CEST] <ubitux> michaelni: yes, sure, discuss it on the ml
[14:56:12 CEST] <ubitux> michaelni: yes but we weren't in a merge rush
[14:56:32 CEST] <ubitux> michaelni: being on par with libav meant a much constant commit rate, so more stable
[14:56:44 CEST] <ubitux> right now we're trying to keep up with the gap, so merging a lot, so it's unstable
[14:57:14 CEST] <ubitux> unstable as in "changing a lot" not necessarily crashing or with more bugs
[14:57:32 CEST] <ubitux> (even though the two are often correlated)
[14:59:18 CEST] <durandal_1707> major bump requires 4.0
[14:59:38 CEST] <ubitux> durandal_1707: what's your opinion on the release?
[15:05:03 CEST] <michaelni>  ubitux btw about crashes we have oss-fuzz, it doesnt cover everything of course like no hwaccel
[15:05:25 CEST] <michaelni> anyway, sending that RFC mail now
[15:41:53 CEST] <kkanungo17> about the psychoacoustic system in aac encoder
[15:42:52 CEST] <kkanungo17> to implement it in vorbis encoder I just need to copy the ff_psy_init() call?
[15:43:57 CEST] <atomnuker> kkanungo17: you need all of the calls
[15:44:12 CEST] <kkanungo17> okay
[15:50:59 CEST] <BBB> 7 patches outstanding to fix most tsan stuff (except mpeg4)
[15:51:47 CEST] <durandal_1707> ubitux: we already delayed release too much
[15:52:19 CEST] <ubitux> is release that important that it's better to make a bad one than none?
[15:52:50 CEST] <durandal_1707> live we ever had good release
[15:53:47 CEST] <BBB> michaelni: can you check the frame_thread_encoder patch?
[15:54:15 CEST] <durandal_1707> atomnuker: dnxhr just uses slightly different dct and i cant understand where is error
[15:54:46 CEST] <BBB> michaelni: you should also be able to review cc0e781 h264: don't sync pic_id between threads. since youre familiar with h264
[15:54:53 CEST] <BBB> (thats a one-liner afair)
[15:55:17 CEST] <BBB> atomnuker: how about you review 22eafe8 codec_desc: mark flac/wavpack as intraonly codecs. since its audio
[15:55:24 CEST] <BBB> </random victim search>
[15:55:44 CEST] <durandal_1707> bunch of audios are intra only
[15:56:03 CEST] <durandal_1707> but i thoought that flag is for video codecs
[15:56:39 CEST] <BBB> Im ok with a separate flag for audio, but it seemed fitting here
[15:56:56 CEST] <durandal_1707> all lossless, so also ape and alac
[15:56:58 CEST] <BBB> theres probably more, but these were reported by tsan which means they have frame threading enabled in their AVCodec
[15:57:07 CEST] <BBB> do ape/alac use frame-mt decoding?
[15:57:17 CEST] <durandal_1707> and tta
[15:57:22 CEST] <BBB> same question
[15:58:05 CEST] <durandal_1707> all except ape
[15:58:33 CEST] <BBB> tta doesn't
[15:58:42 CEST] <durandal_1707> whats tsan complain?
[15:59:24 CEST] <durandal_1707> BBB: tta decoding have frame mt
[15:59:51 CEST] <BBB> it does indeed
[15:59:58 CEST] <BBB> I was looking at libavformat/ape.c instead of libavcodec/
[15:59:59 CEST] <BBB> doh
[16:01:28 CEST] <BBB> tsan complains about fields like channels being copied while writing
[16:01:34 CEST] <BBB> (which is true, but the value is ignored)
[16:01:40 CEST] <BBB> so I fix that by not copying the value
[16:01:46 CEST] <BBB> which you do by marking them as intraonly
[16:02:07 CEST] <BBB> do we have an ape fate test?
[16:02:36 CEST] <nevcairiel> what if an "inter" audio codec would be frame-mt, wouldnt it somehow need a proper way to copy those values then
[16:03:41 CEST] <BBB> right, so thats why it only skips copying those values if the intraonly flag is set
[16:03:56 CEST] <BBB> so we need to set that flag for the audio codecs that are truly intra only
[16:04:06 CEST] <BBB> such as (apparently) alac, tta, ape, wavpack and flac
[16:05:44 CEST] <durandal_1707> and tak too
[16:08:27 CEST] <BBB> and ape is not intra only
[16:08:44 CEST] <atomnuker> durandal_1707: since its the top left corner check what happens after the transform or the DC, this can't be caused by the transform if the ACs look ok
[16:08:47 CEST] <BBB> fate doesnt pass with 2 threads and just the flag set
[16:08:49 CEST] <BBB> (the md5 changes)
[16:08:53 CEST] <michaelni> BBB, replied to the 2 mails, ill go afk a bit now
[16:08:57 CEST] <BBB> michaelni: ty
[16:09:01 CEST] <atomnuker> mlp/truehd also isn't intra only
[16:09:01 CEST] <michaelni> np
[16:09:11 CEST] <atomnuker> but yeah, flac and wavpack are
[16:10:25 CEST] <BBB> I added tta, tak, alac
[16:21:46 CEST] <BBB> durandal_1707: what does tsan complain, see e.g. acodec-flac in http://fate.ffmpeg.org/report.cgi?time=20170328161749&slot=x86_64-archlinux-gcc-tsan
[16:33:10 CEST] <cone-892> ffmpeg 03James Almer 07master:0505a1d9c4be: doc/libav-merge: remove line about AC3 fixed decoder speedup
[16:42:49 CEST] <BBB> ubitux: any improvements in tsan?
[16:43:12 CEST] <BBB> ubitux: sadly hevc/h264 will still show some errors so that will add some noise
[16:43:59 CEST] <ubitux> BBB: do i need to make a new run?
[16:44:13 CEST] <ubitux> i thought you wanted me to wait
[16:44:20 CEST] <BBB> yeah but review isnt ongoing
[16:44:24 CEST] <BBB> so I guess you can run it now
[16:44:34 CEST] <BBB> see where we stand
[16:45:22 CEST] <ubitux> actually there was a run already
[16:45:32 CEST] <ubitux> 3003 ’ 3025
[16:45:43 CEST] <ubitux> http://fate.ffmpeg.org/report.cgi?time=20170331091412&slot=x86_64-archlinux-gcc-tsan
[16:45:55 CEST] <ubitux> http://fate.ffmpeg.org/history.cgi?slot=x86_64-archlinux-gcc-tsan
[16:46:23 CEST] <ubitux> maybe i should try again just in case it's not the correct run
[16:46:48 CEST] <ubitux> yeah it's up-to-date
[16:47:23 CEST] <BBB> ok so we improved again, nice
[16:48:15 CEST] <BBB> fifo-muxer-h264 is as of yet unaddressed
[16:50:35 CEST] <BBB> yeah
[16:50:50 CEST] <BBB> I believe the two reports left after this is fifo-* and mpegvideo* (mpeg4, rv3/4, etc.)
[16:55:28 CEST] <RiCON> BBB: is there any difference in changing the order of LOSSLESS | INTRA?
[16:55:41 CEST] <BBB> did I change something?
[16:55:56 CEST] <BBB> I didnt mean to change anything - it obviously doesnt matter
[16:56:23 CEST] <RiCON> flac is INTRA | LOSSLESS, alac/tta/tak is reverse
[16:56:58 CEST] <RiCON> wavpack is INTRA | LOSSY | LOSSLESS
[16:57:19 CEST] <BBB> Ill make it INTRA | LOSSLESS
[16:58:41 CEST] <BBB> RiCON: new patch sent to fix t hat
[17:05:29 CEST] <RiCON> yeah, looks consistent now
[17:05:49 CEST] <RiCON> i didn't know if it mattered, so it was more of a question than ocd
[17:06:40 CEST] <nevcairiel> doesnt matter
[17:06:42 CEST] <nevcairiel> its just style
[17:07:33 CEST] <nevcairiel> ORing is like additions, order doesnt change the outcome
[17:08:25 CEST] <nevcairiel> whats that called .. commutative property?
[17:08:54 CEST] <BBB> ubitux: fifo-* tsan races are in the transcode_init_done variable
[17:09:00 CEST] <BBB> ubitux: it should probably be an atomic integer or so
[17:09:31 CEST] <BBB> (in ffmpeg.c)
[17:09:46 CEST] <BBB> I guess Im the victim to do that, am I not? ;)
[17:10:21 CEST] <ubitux> you look motivated
[17:10:24 CEST] <ubitux> i don't want to stop you
[17:10:31 CEST] <BBB> so troll'ish
[17:10:52 CEST] <ubitux> BBB: if you want you can do a bunch of merges
[17:11:08 CEST] <ubitux> and i do that threading one
[17:11:09 CEST] <BBB> can I just play mario galaxy 3d?
[17:11:18 CEST] <ubitux> but i think you'll prefer to do the races :p
[17:11:35 CEST] <ubitux> BBB: play after homework.
[17:15:20 CEST] <BBB> blegh
[17:15:21 CEST] <BBB> ok done
[17:15:33 CEST] <BBB> only mpegvideo (mpeg4/rv3/rv4) is outstanding now
[17:15:39 CEST] <BBB> and Im not sure I have the motivation to fix the
[17:15:40 CEST] <BBB> +m
[17:15:49 CEST] <BBB> lets set up a slice-threading station instead
[17:26:05 CEST] <ubitux> BBB: should we use x=ATOMIC_VAR_INIT(0)?
[17:26:31 CEST] <BBB> yes
[17:26:57 CEST] <ubitux> not sure it would make a difference with the store, except saving a line
[17:27:10 CEST] <ubitux> i don't know if any "init" could actually be something smart
[17:27:12 CEST] <BBB> its more like the original code
[17:27:24 CEST] <BBB> changed locally
[17:28:52 CEST] <wm4> <ubitux> BBB: should we use x=ATOMIC_VAR_INIT(0)? <- we don't do that consistently
[17:29:18 CEST] <ubitux> i don't think we use atomic_init() consistently either
[17:29:29 CEST] <ubitux> but in both case it seems to be a a=b all the time
[17:29:40 CEST] <ubitux> i guess it doesn't matter... yet.
[17:30:20 CEST] <BBB> lets get this in so we can bug someone (..) to fix mpeg4
[17:35:18 CEST] <jamrial> http://en.cppreference.com/w/c/atomic/ATOMIC_VAR_INIT
[17:35:22 CEST] <jamrial> "The initial value of atomic object of automatic storage duration that is not initialized using this macro is undefined. The default (zero) initialization of static and thread-local variables produces valid value however."
[17:38:29 CEST] <ubitux> OK so the "standard" says "use the special init if ` 0"
[17:39:11 CEST] <wm4> note that this doesn't mean it works for calloc()
[17:39:37 CEST] <wm4> or if you do struct foo={0}; on th stack and it contains atomic fields
[17:50:39 CEST] <nevcairiel> it only means it works for statics
[17:50:58 CEST] <nevcairiel> (or TLS, which we dont use)
[17:55:45 CEST] <wm4> yeah, and I wonder why they did this (it sucks)
[17:56:16 CEST] <nevcairiel> probably to match C init rules, as static variables are also default initialized
[17:56:49 CEST] <wm4> then they'd have written something about default init
[17:57:52 CEST] <nevcairiel> isnt that what jamrial quoted
[17:58:01 CEST] <nevcairiel> The default (zero) initialization of static and thread-local variables produces valid value however.
[18:13:49 CEST] <wm4> nevcairiel: I mean the standard specifically went out of its way to keep heap allocation or the default initializer (when used on Stack) undefined
[18:21:00 CEST] <cone-892> ffmpeg 03Carl Eugen Hoyos 07master:76dd87c92969: lavf/amr: Return AVERROR_EOF on EOF.
[18:31:15 CEST] <nevcairiel> wm4: well the way static initialization works is entirely different to those others - those are basically just assignments shoved on the same line
[18:32:56 CEST] <wm4> I don't see the difference
[18:32:58 CEST] <wm4> at all
[18:33:34 CEST] <wm4> even if the bit pattern is not repeated 0s, the default initializer ({...}) should just work
[18:33:38 CEST] <nevcairiel> the initial value of a static variable is placed in a special section in the binary
[18:33:47 CEST] <nevcairiel> so its just inherently different
[18:34:52 CEST] <wm4> how is that different from memcpy'ing the same data to the stack if the default initializer is used?
[19:09:28 CEST] <BBB> so whats the conclusion on the initializer?
[19:09:59 CEST] <jamrial> that there's supposedly no need to init it to 0 if it's static
[19:10:22 CEST] <jamrial> see the link above
[19:10:40 CEST] <BBB> but if I keep it, is it ok, even if its unnecessary?
[19:11:46 CEST] <jamrial> i guess it should be ok
[19:12:27 CEST] <BBB> lets review the other patches then, because Id like to get them in and make ubitux tsan instance happier
[19:13:08 CEST] <cone-892> ffmpeg 03James Almer 07master:9033e8723c86: avutil/spherical: add av_spherical_projection_name()
[19:13:09 CEST] <cone-892> ffmpeg 03James Almer 07master:2efb70c37992: avformat/dump: use av_spherical_projection_name() to print spherical projection names
[19:13:10 CEST] <cone-892> ffmpeg 03James Almer 07master:2a2854f57842: ffprobe: use av_spherical_projection_name() to print spherical projection names
[19:31:47 CEST] <cone-892> ffmpeg 03Diego Biurrun 07master:fe7bc1f16aba: configure: Do not unconditionally check for (and enable) xlib
[19:31:48 CEST] <cone-892> ffmpeg 03James Almer 07master:f0df60d392d6: Merge commit 'fe7bc1f16abaefe66d8a20f734ca3eb8a4ce4d43'
[19:34:00 CEST] <cone-892> ffmpeg 03Diego Biurrun 07master:831005b2302c: configure: Log correct test name and use correct filter when testing objective C flags
[19:34:01 CEST] <cone-892> ffmpeg 03James Almer 07master:e5177e8f8db0: Merge commit '831005b2302cbeb377e3f00fd18c78928bcec185'
[19:35:16 CEST] <cone-892> ffmpeg 03Diego Biurrun 07master:8a6e7a67cb29: configure: Use check_cpp in CPP flags tests
[19:35:17 CEST] <cone-892> ffmpeg 03James Almer 07master:3795899978cf: Merge commit '8a6e7a67cb2943f552569801539829a304971302'
[19:37:33 CEST] <cone-892> ffmpeg 03Diego Biurrun 07master:c78495d1cdac: configure: Log name and parameters of all helper functions where it makes sense
[19:37:34 CEST] <cone-892> ffmpeg 03James Almer 07master:8d50dd976d29: Merge commit 'c78495d1cdac6dd13786a7e5571b606604a360bd'
[19:41:40 CEST] <cone-892> ffmpeg 03Diego Biurrun 07master:2dd464868c64: configure: Move license checks directly after command line parsing
[19:41:41 CEST] <cone-892> ffmpeg 03James Almer 07master:0ad9aff0227a: Merge commit '2dd464868c64fa21a6e3bd63ad364ff12999c7d0'
[19:44:15 CEST] <cone-892> ffmpeg 03Diego Biurrun 07master:72a19f4013ec: mpegaudiodsp: aarch64: Adjust function prototype after 2caa93b813adc5dbb7771dfe615da826a2947d18
[19:44:16 CEST] <cone-892> ffmpeg 03James Almer 07master:5694427dc384: Merge commit '72a19f4013ec2c7f8581416f8ad4bf81df163fb6'
[19:48:00 CEST] <cone-892> ffmpeg 03Anton Khirnov 07master:84f225684cd3: pthread_frame: properly propagate the hw frame context across frame threads
[19:48:01 CEST] <cone-892> ffmpeg 03James Almer 07master:e2f6e1c4a825: Merge commit '84f225684cd389747907381122c073aa1c8b6bf1'
[20:12:05 CEST] <ubitux> jamrial: we don't have the next commit(s) already?
[20:12:39 CEST] <jamrial> the one i'm about to merge was done by me, but we don't need it right now
[20:13:23 CEST] <jamrial> we *should* need it, but the bsf on our end is violating the API so it works in a different way
[20:13:35 CEST] <jamrial> so until it's fixed...
[20:14:02 CEST] <jamrial> and to do that, someone needs to do the same for mov as this commit does for matroska
[20:15:12 CEST] <jamrial> the commit after this one (flac) is in our tree already, yeah
[20:15:47 CEST] <cone-892> ffmpeg 03James Almer 07master:f4bf236338f6: matroskaenc: fix muxing AAC streams when using aac_adtstoasc bsf
[20:15:48 CEST] <cone-892> ffmpeg 03James Almer 07master:13a211e6320d: Merge commit 'f4bf236338f6001736a4784b9c23de863057a583'
[20:17:55 CEST] <cone-892> ffmpeg 03James Almer 07master:98cae966c778: matroskaenc: write updated STREAMINFO metadata for FLAC streams if available
[20:17:56 CEST] <cone-892> ffmpeg 03James Almer 07master:51d95914e00c: Merge commit '98cae966c77875e26c5958206a6cfe7eba6269e8'
[20:21:17 CEST] <cone-892> ffmpeg 03Martin Storsjö 07master:a4cfcddcb0f7: vp9: Make the subpel filters non-static
[20:21:18 CEST] <cone-892> ffmpeg 03James Almer 07master:28bace5c0a75: Merge commit 'a4cfcddcb0f76e837d5abc06840c2b26c0e8aefc'
[20:23:13 CEST] <ubitux> jamrial: you may want to document that bsf thing in the libav merge doc
[20:25:06 CEST] <jamrial> sure
[20:25:28 CEST] <ubitux> ah we actually already document the bsf thing
[20:25:29 CEST] <jamrial> although ideally someone familiar with mov should fix it so we can also remove the awful related hack in ffmpeg.c
[20:25:37 CEST] <ubitux> but that commit hash should probably be added
[20:26:57 CEST] <cone-892> ffmpeg 03Martin Storsjö 07master:c44a8a3eabcd: aarch64: Add an offset parameter to the movrel macro
[20:26:58 CEST] <cone-892> ffmpeg 03James Almer 07master:afac31d2b2cf: Merge commit 'c44a8a3eabcd6acd2ba79f32ec8a432e6ebe552c'
[20:34:21 CEST] <cone-892> ffmpeg 03James Almer 07master:183635b9e96b: doc/libav-merge: mention aac_adtstoasc extradata update fix for matroska
[20:37:49 CEST] <cone-892> ffmpeg 03Martin Storsjö 07master:383d96aa2229: aarch64: vp9: Add NEON optimizations of VP9 MC functions
[20:37:50 CEST] <cone-892> ffmpeg 03James Almer 07master:2348eb171455: Merge commit '383d96aa2229f644d9bd77b821ed3a309da5e9fc'
[20:41:16 CEST] <cone-892> ffmpeg 03Martin Storsjö 07master:557c1675cf0e: arm: vp9mc: Minor adjustments from review of the aarch64 version
[20:41:17 CEST] <cone-892> ffmpeg 03James Almer 07master:8408c2efe4bf: Merge commit '557c1675cf0e803b2fee43b4c8b58433842c84d0'
[20:44:18 CEST] <cone-892> ffmpeg 03Martin Storsjö 07master:6a62795d4051: aarch64: h264idct: Use the offset parameter to movrel
[20:44:19 CEST] <cone-892> ffmpeg 03James Almer 07master:67eda469ab34: Merge commit '6a62795d4051f435a9a2c59395d96913693922f8'
[20:47:47 CEST] <cone-892> ffmpeg 03Diego Biurrun 07master:905cdcaa9d08: examples/decode_audio: Add missing header for av_free()
[20:47:48 CEST] <cone-892> ffmpeg 03James Almer 07master:ebe9808aaad6: Merge commit '905cdcaa9d081d3d945ce555b27b43a75c3af57b'
[20:49:32 CEST] <cone-892> ffmpeg 03Martin Storsjö 07master:824e8c284054: arm: Clear the gp register alias at the end of functions
[20:49:33 CEST] <cone-892> ffmpeg 03James Almer 07master:f6e37665a9dd: Merge commit '824e8c284054f323f854892d1b4739239ed1fdc7'
[20:51:22 CEST] <cone-892> ffmpeg 03Martin Storsjö 07master:11623217e3c9: arm: vp9mc: Use a different helper register for PIC loads
[20:51:23 CEST] <cone-892> ffmpeg 03James Almer 07master:bf624e993d6f: Merge commit '11623217e3c9b859daee544e31acdd0821b61039'
[20:53:45 CEST] <cone-892> ffmpeg 03Mark Thompson 07master:fd0fae60372c: pthread_frame: Unreference hw_frames_ctx on per-thread codec contexts
[20:53:47 CEST] <cone-892> ffmpeg 03James Almer 07master:a9134fa7135b: Merge commit 'fd0fae60372cddbe0bec8830d07e760195f80bad'
[20:54:15 CEST] <jamrial> noop fest
[20:56:08 CEST] <llogan> michaelni: do you recall if Herve Flores ever used any standard license, such as CC, for his logo? or just the statement he provided in "FFmpeg-LOGO.pdf"? A user on ffmpeg-user ML wants permission to use it to print a shirt for personal use. I was going to say "go ahead", but was curious about the license.
[20:58:40 CEST] <cone-892> ffmpeg 03Ronald S. Bultje 07master:0b37cd09a67c: checkasm: add vp9dsp.itxfm_add tests.
[20:58:41 CEST] <cone-892> ffmpeg 03James Almer 07master:5e7288480f02: Merge commit '0b37cd09a67c3ba4db044404b99c65a32b4ad932'
[20:59:05 CEST] <michaelni> personal use ? wtf has happened to the world that scared people enough to think theres a need to ask for personal use. 
[20:59:40 CEST] <llogan> he's not scared. the printing company demands it. i'm not worried. just wonding what the actual license is.
[21:00:03 CEST] <durandal_1707> we will sue him because of trademark we hold
[21:01:17 CEST] <cone-892> ffmpeg 03Martin Storsjö 07master:a67ae6708315: arm: vp9: Add NEON itxfm routines
[21:01:18 CEST] <cone-892> ffmpeg 03James Almer 07master:037522a75ade: Merge commit 'a67ae67083151f2f9595a1f2d17b601da19b939e'
[21:03:41 CEST] <durandal_1707> its serious business
[21:07:05 CEST] <cone-892> ffmpeg 03Diego Biurrun 07master:12db2832e41a: libxvid: Require availability of mkstemp()
[21:07:06 CEST] <cone-892> ffmpeg 03James Almer 07master:ef516efad445: Merge commit '12db2832e41aa71b5903ef7fa5c59c5473ded2c5'
[21:11:12 CEST] <cone-892> ffmpeg 03Diego Biurrun 07master:e5e8a26dcf6d: libxvid: Use proper context in av_log() calls
[21:11:13 CEST] <cone-892> ffmpeg 03James Almer 07master:804ae6e30fc7: Merge commit 'e5e8a26dcf6d572e841a7a191e4c96524367e3f9'
[21:17:01 CEST] <cone-892> ffmpeg 03Diego Biurrun 07master:f7d183f08472: libxvid: Check return value of write() call
[21:17:02 CEST] <cone-892> ffmpeg 03James Almer 07master:a1afcf8b8c30: Merge commit 'f7d183f08472e566a2e6b62a80e200a12670ed0e'
[21:18:36 CEST] <cone-892> ffmpeg 03Martin Storsjö 07master:dd299a2d6d4d: arm: vp9: Add NEON loop filters
[21:18:37 CEST] <cone-892> ffmpeg 03James Almer 07master:66e7b421fa04: Merge commit 'dd299a2d6d4d1af9528ed35a8131c35946be5973'
[21:21:38 CEST] <cone-892> ffmpeg 03Diego Biurrun 07master:3b50dbc51fb0: ratecontrol: Use correct function pointer casts instead of void*
[21:21:39 CEST] <cone-892> ffmpeg 03James Almer 07master:c4fd1e7b0116: Merge commit '3b50dbc51fb0978d09c1a5b83d4bf5a59d170e1e'
[21:26:27 CEST] <cone-892> ffmpeg 03Diego Biurrun 07master:fcbdd605b540: nut: Use correct function pointer casts instead of void*
[21:26:28 CEST] <cone-892> ffmpeg 03James Almer 07master:8e7497e774af: Merge commit 'fcbdd605b5409103c3f4bfa063ea270f2229b125'
[21:29:20 CEST] <cone-892> ffmpeg 03Diego Biurrun 07master:8ddfa5ae5ef6: vf_drawtext: Drop wrong void* cast
[21:29:21 CEST] <cone-892> ffmpeg 03James Almer 07master:a4ee9551138c: Merge commit '8ddfa5ae5ef64a25dd087d74954ebdb9081f0d67'
[21:31:46 CEST] <JEEB> &29
[21:34:32 CEST] <cone-892> ffmpeg 03Diego Biurrun 07master:d316f9cefcd8: aac: Drop pointless cast
[21:34:33 CEST] <cone-892> ffmpeg 03James Almer 07master:fc2a94219df7: Merge commit 'd316f9cefcd854071985c6f524a9a15348240264'
[21:39:59 CEST] <cone-892> ffmpeg 03Diego Biurrun 07master:800d91d348c8: Drop pointless void* casts
[21:40:00 CEST] <cone-892> ffmpeg 03James Almer 07master:b725b482c6af: Merge commit '800d91d348c89fc8ca3fbec7696ab1ec8787acc6'
[21:42:32 CEST] <ubitux> jamrial: you want to keep < > includes for the ff libs
[21:42:36 CEST] <ubitux> in the examples
[21:42:55 CEST] <ubitux> it's mainly motivated by the fact that users are going to reuse that code out of the tree
[21:44:04 CEST] <jamrial> ubitux: ah, sure
[21:47:39 CEST] <cone-892> ffmpeg 03Diego Biurrun 07master:01348e411f96: avconv_opt: Consistently iterate through hwaccels array in all cases
[21:47:40 CEST] <cone-892> ffmpeg 03James Almer 07master:10eb3259a65d: Merge commit '01348e411f962f5e4605d649fc9a47a54587ba8e'
[21:51:40 CEST] <cone-892> ffmpeg 03James Almer 07master:b27dd80255a0: doc/decode_audio: use <> to include libav* headers
[21:57:05 CEST] <cone-892> ffmpeg 03Martin Storsjö 07master:3c9546dfafcd: aarch64: vp9: Add NEON itxfm routines
[21:57:06 CEST] <cone-892> ffmpeg 03James Almer 07master:74927355fc7f: Merge commit '3c9546dfafcdfe8e7860aff9ebbf609318220f29'
[22:04:35 CEST] <cone-892> ffmpeg 03Martin Storsjö 07master:52d196fb30fb: arm: vp9itxfm: Simplify txfm string comparisons
[22:04:36 CEST] <cone-892> ffmpeg 03Martin Storsjö 07master:9d2afd1eb8c5: aarch64: vp9: Implement NEON loop filters
[22:04:37 CEST] <cone-892> ffmpeg 03Janne Grunau 07master:31756abe29eb: aarch64: vp9: loop_filter: fix typo in skip flatout8 check
[22:04:38 CEST] <cone-892> ffmpeg 03James Almer 07master:c6f06876e108: Merge commit '31756abe29eb039a11c59a42cb12e0cc2aef3b97'
[22:10:03 CEST] <cone-892> ffmpeg 03Mark Thompson 07master:3297577f3eac: mpegvideo: Return correct coded frame sizes from parser
[22:10:04 CEST] <cone-892> ffmpeg 03James Almer 07master:b00f44e513e9: Merge commit '3297577f3eac1c87d48dedd527942de2bd28e7a5'
[22:13:39 CEST] <cone-892> ffmpeg 03Mark Thompson 07master:cd1047f3911f: qsvdec: Pass the correct profile to libmfx
[22:13:40 CEST] <cone-892> ffmpeg 03Mark Thompson 07master:030d84fa2e35: qsvdec: Pass field order information to libmfx
[22:13:41 CEST] <cone-892> ffmpeg 03James Almer 07master:1fb2c697d5d1: Merge commit '030d84fa2e35af0e77516735de35bf1a52371c86'
[22:14:55 CEST] <jamrial> jkqxz: ok to merge 0940b748bdba36c4894fc8ea6be631d821fdf578?
[22:27:25 CEST] <cone-892> ffmpeg 03Mark Thompson 07master:0940b748bdba: qsvdec: Only warn about unconsumed data if it happens more than once
[22:27:26 CEST] <cone-892> ffmpeg 03Mark Thompson 07master:fea4dc05b41f: vc1: Return stream format information from parser
[22:27:27 CEST] <cone-892> ffmpeg 03James Almer 07master:4fe9d6964830: Merge commit '0940b748bdba36c4894fc8ea6be631d821fdf578'
[22:27:28 CEST] <cone-892> ffmpeg 03James Almer 07master:99fa2fc5db06: Merge commit 'fea4dc05b41f5465bedc786b67966f204ec6150c'
[22:28:22 CEST] <jamrial> jkqxz: it applied cleanly, so revert if it's not needed/desired
[22:50:13 CEST] <cone-892> ffmpeg 03Mark Thompson 07master:b6582b29277e: qsv: Add VC-1 decoder
[22:50:14 CEST] <cone-892> ffmpeg 03James Almer 07master:678ab33861d1: Merge commit 'b6582b29277e00e5d49f400e58beefa5a21d83b8'
[23:06:07 CEST] <jamrial> i'll leave the next commit to jkqxz or whoever wants to look at it (vp8: Return stream format information from parser) as it wont work as is
[23:06:40 CEST] <jamrial> apparently parsers can't return AVERROR codes
[23:12:11 CEST] <cone-892> ffmpeg 03Martin Vignali 07master:6426f74272c3: fate/exr : add test for uint32 data
[23:12:38 CEST] <Compn> >nero.com says they use ffmpeg in nero software now 
[23:12:39 CEST] <Compn> heh
[23:12:49 CEST] <Compn> probably for input
[23:13:35 CEST] <Compn> asked to download samples.ffmpeg
[23:13:44 CEST] <Compn> wonder if i should tell them a lot of the files are broken in some way...
[23:16:03 CEST] <JEEB> yes
[23:16:17 CEST] <JEEB> for everyone's sanity
[23:16:39 CEST] <Compn> i think i should update the 00-README file
[23:16:40 CEST] <Compn> :D
[23:16:49 CEST] <Compn> Please be aware that this samples collection contains a lot
[23:16:49 CEST] <Compn> of files that are very obscure, broken in various ways or
[23:16:49 CEST] <Compn> are just simply out of use. 
[23:16:53 CEST] <Compn> oh no, it says it right htere :)
[23:27:26 CEST] <Rathann> Compn: where do they say it?
[23:27:31 CEST] <Rathann> I mean nero.com
[23:28:19 CEST] <Rathann> ah found it
[23:28:52 CEST] <Rathann> https://www.nero.com/enu/corp-legal/end-user-agreement.php
[23:29:48 CEST] <Rathann> heh, but the download link to the sources is 404
[23:57:20 CEST] <Compn> athann : 
[23:57:29 CEST] <Compn> Rathann : it was in an email asking for samples actually :D
[23:57:33 CEST] <Compn> whenever he gets back
[00:00:00 CEST] --- Sat Apr  1 2017