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

[burek]

[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