[00:04:33 CEST] <ubitux> what's the status of qsv? is it going to be applied? [00:23:25 CEST] <nevcairiel> still issues w ith current patch [02:11:43 CEST] <cone-567> ffmpeg 03Tobias Rapp 07master:03a6feb2137d: fate: Add MXF D10/DNXHD/DV25 probe tests [02:29:04 CEST] <cone-567> ffmpeg 03Suman- 07master:a81494b60337: lavf/flvdec: init AVPacket::pos to FLVTAG offset [03:25:49 CEST] <cone-567> ffmpeg 03Michael Niedermayer 07master:20182e79f9c2: doc/APIchanges: Fill in some missing things [05:16:07 CEST] <rcombs> https://patchwork.ffmpeg.org/patch/1176/ where's durandal_1707 anyway [08:26:15 CEST] <durandal_1707> michaelni: how many opw applicants do we have right now? [11:57:41 CEST] <michaelni> durandal_1707, 3, you can see them at https://outreachy.gnome.org/?q=manage_projects&prg=7&o=96 [13:22:48 CEST] <durandal_1707> michaelni: so we have money to fund only one student? [13:25:31 CEST] <michaelni> durandal_1707, yes, but outreachy might fund a 2nd one if we have 2 we want to accept. [13:33:18 CEST] <durandal_1707> michaelni: all they have their qualification task? [13:36:15 CEST] <durandal_1707> durandal_1707: i had been contacted by one of student, interested in working on xpm encoder [13:37:04 CEST] <durandal_1707> so how it develops, i may give student more work to do, like xpm decoder [13:37:19 CEST] <durandal_1707> michaelni: ^ [13:46:51 CEST] <michaelni> durandal_1707, 2 are doing qualification tasks according to: https://trac.ffmpeg.org/wiki/SponsoringPrograms/Outreachy/2016-12-Qualis [13:47:07 CEST] <wm4> shouldn't a xpm encoder be like 10 lines of code (not including boilerplate) [13:50:39 CEST] <michaelni> durandal_1707, yes you tell a student what (s)he should do and then decide if (s)he is qualified or not / if you want to mentor her/him .. [13:52:35 CEST] <durandal_1707> wm4: its more than that, its about picking all available colors in image efficiencly [13:53:26 CEST] <durandal_1707> its about understanding how things works [13:53:29 CEST] <wm4> wouldn't it just accept pal8 [13:53:50 CEST] <durandal_1707> wm4: pal8 is dumb stupid, this is about more [13:53:54 CEST] <wm4> ? [13:54:24 CEST] <michaelni> s/student/applicant/ [14:04:11 CEST] <michaelni> durandal_1707, also if we want to ask outreachy for funding a 2nd student that should be marked in the web interface by 27th (aka tomorrow) [14:05:21 CEST] <michaelni> durandal_1707, the choice for who to accept of the 3 applicants must be done by 3rd nov at the latest [14:07:44 CEST] <durandal_1707> michaelni: and end time for qualification task to be accepted? [14:09:41 CEST] <michaelni> durandal_1707, your choice but the deadline we have to make a choice is 3rd nov. outreachy tends to be much more tolerant than google though ith deadlines so theres a chance but not certain that we might still be able to adjust it a day later or so [14:10:56 CEST] <durandal_1707> well i guess, I will just wait what applicant will contribute [18:56:41 CEST] <cone-568> ffmpeg 03Michael Niedermayer 07master:25ab1a65f3ac: avcodec/dvdsubdec: Fix buf_size check [19:27:48 CEST] <cone-568> ffmpeg 03Michael Niedermayer 07master:ded5c885281a: configure: Remove --enable-incompatible-libav-abi from the help output [19:27:49 CEST] <cone-568> ffmpeg 03Vodyannikov Aleksandr 07master:9445e7e6d562: swresample/rematrix: Fix float part of swr_set_matrix() [19:40:32 CEST] <cone-568> ffmpeg 03Michael Behrisch 07master:c5ac86256bd9: lavu: remove comma at final enumeration items to fix pedantic warnings [19:48:24 CEST] <cone-568> ffmpeg 03Michael Niedermayer 07master:4045a8d73e81: doc/patchwork: Document the patchwork states [19:48:25 CEST] <cone-568> ffmpeg 03Michael Niedermayer 07master:d88a6bedb9bc: avformat/isom: Fix old API regression with exporting max bitrate [19:48:26 CEST] <cone-568> ffmpeg 03Michael Niedermayer 07master:e936c8d176ef: avformat/utils: Discard huge timestamps which would cause overflows if used in basic computations [20:12:21 CEST] <wm4> michaelni: you can't push such changes without review [20:12:40 CEST] <wm4> who would even dare to push this without reviews [20:12:58 CEST] <wm4> well I guess technically it's ok [20:13:03 CEST] <wm4> you waited 3 days or so [20:13:10 CEST] <michaelni> wm4, which commit ? [20:13:14 CEST] <wm4> actually a month [20:13:19 CEST] <wm4> "avformat/utils: Discard huge timestamps which would cause overflows if used in basic computations" [20:13:40 CEST] <JEEB> at least it's int64 min [20:13:52 CEST] <JEEB> I first read that one as uint [20:13:57 CEST] <JEEB> and raised my eyebrows [20:13:58 CEST] <wm4> if I understand this right, this suddenly adds an undocumented allowed range to timestampos [20:14:04 CEST] <wm4> which is applied only at this point [20:14:09 CEST] <wm4> and which also is arbitrary [20:14:50 CEST] <wm4> not really what you'd expect - I probably assumed that this ignores the timestamps only for the purpose of utils.c calculations or something [20:15:09 CEST] <wm4> and just because a patch is ignored it's not ok [20:15:49 CEST] <wm4> ok back to not caring [20:20:12 CEST] <michaelni> wm4, a patch ignored for a week is ok, litterally so, its written that way in the developer policy. "1 week for big patches" and its not even big and i waited a month [20:21:18 CEST] <michaelni> that said i can revert if people want me to revert, is no problem for me [20:24:20 CEST] <wm4> which is why I said "technically ok" [20:24:42 CEST] <wm4> so what happens if I don't use libavformat for demuxing and e.g. feed libavfilter with huge timestamps? [20:26:31 CEST] <michaelni> the patch was only intended to cut the timstamps for libavformat down from the a little less than 64bit may before to half that instead of lots of checks everywhere, i didnt intend to assume anything outside libavformat [20:27:18 CEST] <michaelni> libavfilter certainly has issues with larger timestamps too but that patch was not intended to fix that [20:28:42 CEST] <michaelni> if people dislike that patch ill revert or if theres a actual file needing timestamps in the range ill revert too, is there anything using such large timestamps ? [20:29:29 CEST] <wm4> it's hard to argue for reverting a patch that fixes "some" (unspecified number) of overflow issues, I'm just asking for cleaner practices [20:29:49 CEST] <wm4> instead of implicitly suddenly constraining the range of valid timestamps [20:30:49 CEST] <michaelni> ok, ill revert, lets restar this cleanly after 3.2 [20:32:51 CEST] <wm4> I'm not forcing you [20:35:29 CEST] <BtbN> Seems like a ok solution to me. [20:35:39 CEST] <BtbN> Losing essentialy one bit isn't that horrible [20:35:50 CEST] <BtbN> you'd still need one hell of a long video to get there [20:35:59 CEST] <cone-568> ffmpeg 03Michael Niedermayer 07master:c92f55847a3d: avcodec/dvdsubdec: Fix off by 1 error [20:36:00 CEST] <cone-568> ffmpeg 03Michael Niedermayer 07master:38e5a4f3bbe9: Revert "avformat/utils: Discard huge timestamps which would cause overflows if used in basic computations" [20:37:30 CEST] <wm4> BtbN: video length isn't really an argument [20:37:38 CEST] <wm4> timestamps could for example reflect some sort of clock time [20:37:48 CEST] <wm4> or just start at an arbitrary offset [20:38:16 CEST] <nevcairiel> mpegts broadcast recordings start at arbitrary high offsets, but of course mpegts is limited to 33 bits so it wont get that high [20:38:19 CEST] <wm4> either handling overflows explicitly or documenting the allowed timestamp range in general would probably be better [20:38:35 CEST] <BtbN> Timestamps larger than 4611686018427387904? [20:38:45 CEST] <nevcairiel> there is no reason not to [20:38:47 CEST] <nevcairiel> its arbitrary [20:39:00 CEST] <BtbN> well, it will eventually run into the limits of 64bit [21:10:01 CEST] <cone-568> ffmpeg 03Michael Niedermayer 07master:3f3025205ff3: Bump minor versions for 3.2 [21:10:02 CEST] <cone-568> ffmpeg 03Michael Niedermayer 07master:36ecf30cbc20: doc/APIchanges: add 3.2 Cut marker [21:10:03 CEST] <cone-568> ffmpeg 03Michael Niedermayer 07master:e84d58761348: Changelog: Add 3.2 [21:10:04 CEST] <cone-568> ffmpeg 03Michael Niedermayer 07master:1609935b6cbe: Bump minor versions after 3.2 branchpoint to seperate release [21:10:05 CEST] <cone-568> ffmpeg 03Michael Niedermayer 07master:efa89a841941: Changelog: Add back next marker [21:10:06 CEST] <cone-568> ffmpeg 03Michael Niedermayer 07master:e1b30c8a0109: RELEASE: Update for past 3.2 branch [21:11:54 CEST] <jamrial> michaelni: do you mind if i apply my matroska crc32 fix for 3.2? it didn't get a review yet but i'd like it to be in the release since it's a muxer regression [21:17:37 CEST] <michaelni> jamrial, feel free to apply any patch you like, ill make the release branch in a moment and people can then still backport to it before the release [21:18:42 CEST] <nevcairiel> regressions are generally fine to be fixed in re lease branches [21:19:15 CEST] <cone-568> ffmpeg 03Michael Niedermayer 07release/3.2:HEAD: RELEASE: Update for past 3.2 branch [21:23:24 CEST] <jamrial> michaelni: ok, thanks. will do [21:24:45 CEST] <jamrial> michaelni: are you sure you branched it at the right commit? both version bump commits are now in 3.2 [21:25:03 CEST] <michaelni> jamrial, no iam off by 1 i just noticed too [21:25:14 CEST] <jamrial> ah ok [21:25:22 CEST] <michaelni> ill revert that one in a moment [21:25:45 CEST] <jamrial> ok, will wait for that before pushing my fix [21:27:51 CEST] <cone-568> ffmpeg 03Michael Niedermayer 07release/3.2:660229d64774: Revert "Bump minor versions after 3.2 branchpoint to seperate release" [21:29:39 CEST] <philipl> What's the appropriate version bump for moving a decoder from the old API to the new API (and dropping support for the old API)? [21:31:28 CEST] <jamrial> philipl: minor i guess [21:32:36 CEST] <wm4> "old" API users suddenly won't be able to use the decoder anymore, so it's a breaking change [21:32:51 CEST] <philipl> Except it's crystalhd so no-one cares :-P [21:32:52 CEST] <wm4> though not sure if this counts because the old API is deprecated [21:33:25 CEST] <philipl> yeah, it's technically a breaking change, but I don't think it's what we mean for a major bump to be used for. [21:33:40 CEST] <wm4> (and there's a history of APIs intentionally stopping working even if they're only deprecated...) [21:34:02 CEST] <jamrial> major bump would remove the old api from the tree altogether, not just from a decoder [21:34:24 CEST] <philipl> Ok. minor it is. [21:34:28 CEST] <jamrial> you said cristalhd doesn't work with the old api, right? it's not like you're breaking anything then :p [21:35:13 CEST] <philipl> Well, I did technically get it to where it mostly worked most of the time. [21:35:41 CEST] <philipl> but we can ignore that. [21:53:00 CEST] <jkqxz> RiCON: Another iteration for you: your MPEG-2 stream now works, and H.265 should be in a better state. More testing welcome :) [22:06:19 CEST] <cone-568> ffmpeg 03James Almer 07master:eabbc64728c2: avformat/matroskaenc: fix cue relative position values when CRC32 is enabled [22:06:20 CEST] <cone-568> ffmpeg 03James Almer 07release/3.2:e6f35a9cd849: avformat/matroskaenc: fix cue relative position values when CRC32 is enabled [22:40:11 CEST] <jamrial> Helmut is right, ffserver was scheduled to be removed with this release, and not once we do a 4.0 or a major bump happens [22:42:59 CEST] <cone-568> ffmpeg 03James Almer 07master:7400f6421111: configure: remove missing incompatible_libav_abi references [22:43:00 CEST] <cone-568> ffmpeg 03James Almer 07master:bf709098c9ee: avcodec: remove missing incompatible_libav_abi references [22:43:01 CEST] <cone-568> ffmpeg 03James Almer 07release/3.2:e554c667bd78: configure: remove missing incompatible_libav_abi references [22:43:02 CEST] <cone-568> ffmpeg 03James Almer 07release/3.2:548242d1a1ec: avcodec: remove missing incompatible_libav_abi references [22:44:20 CEST] <atomnuker> jamrial: so is it too late to post a patch to the ML? [22:47:23 CEST] <jamrial> atomnuker: probably not. the release wont be tagged until tomorrow [22:47:38 CEST] <BBB> is the VP9 AMD workaround in the 3.2 branch? [22:48:20 CEST] <BBB> (yes it is) [00:00:00 CEST] --- Thu Oct 27 2016