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

Sun Jan 7 03:05:03 EET 2018

[02:10:08 CET] <cone-672> ffmpeg 03James Almer 07master:798dcf243299: avfilter: deprecate avfilter_link_get_channels()
[02:10:08 CET] <cone-672> ffmpeg 03James Almer 07master:01c21653eee5: tools/uncoded_frame: remove usage of avfilter_link_get_channels()
[02:10:08 CET] <cone-672> ffmpeg 03James Almer 07master:077fe9eb0679: doc/libav-merge: remove line about libavutil atomics API
[02:11:12 CET] <jamrial> right, i need a break
[02:11:37 CET] <BBB> poor guy
[02:13:05 CET] <jamrial> i'm sure both lavfi patches are fine and will be accepted, but meh, i'll revert them until they get a review
[02:15:04 CET] <cone-672> ffmpeg 03James Almer 07master:503164b54ba2: Revert "tools/uncoded_frame: remove usage of avfilter_link_get_channels()"
[02:15:05 CET] <cone-672> ffmpeg 03James Almer 07master:da5b05c8335d: Revert "avfilter: deprecate avfilter_link_get_channels()"
[03:16:40 CET] <cone-672> ffmpeg 03Michael Niedermayer 07master:fba00b7465b2: doc/fate: Document how to upload samples to the fate suite
[03:16:41 CET] <cone-672> ffmpeg 03Misty De Meo 07master:94e6b5ac3914: adpcm: consume remainder after consuming XA chunks
[03:16:42 CET] <cone-672> ffmpeg 03Misty De Meo 07master:bfe397e4313c: aiff: add explicit goto got_sound
[13:19:02 CET] <sfan5> why is the ffmpeg website still doing this? https://i.imgur.com/pww9FtN.png
[13:52:32 CET] <durandal_1707> sfan5: talk to web page maintainers
[13:52:52 CET] <sfan5> well aren't they in this channel too?
[13:55:05 CET] <atomnuker> michaelni is
[14:15:17 CET] <KGB> [13FFV1] 15dericed opened pull request #98: bump to version 01 (06master...06bump-to-version-01) 02https://git.io/vNTwA
[14:15:35 CET] <RiCON> just revert https://git.ffmpeg.org/gitweb/ffmpeg-web.git/commit/0078c64257cd3d0a93403185acdcab33fa3d90b1
[14:16:22 CET] <RiCON> and https://git.ffmpeg.org/gitweb/ffmpeg-web.git/commit/fa9af8d7c5c16b1a5d343a8c29a4cd2afed8d94a
[15:00:26 CET] <cone-864> ffmpeg 03Paul B Mahol 07master:50b3cd22dd70: avfilter/av_biquads: scale a0 too
[15:01:44 CET] <cone-864> ffmpeg 03James Almer 07master:b2c42fc6dc35: avfilter: deprecate avfilter_link_get_channels()
[15:11:55 CET] <cone-864> ffmpeg 03Nicolas George 07master:34dfe36971aa: tools/uncoded_frame: use buffersink accessors.
[15:11:56 CET] <cone-864> ffmpeg 03Nicolas George 07master:01735b4852c6: tools/uncoded_frame: remove use of AVStream.codec.
[15:18:46 CET] <wm4> so when will ffserver be removed
[15:19:42 CET] <atomnuker> after durandal_1707's yuvj patches are merged when the abi unstable period ends
[15:20:51 CET] <durandal_1707> no
[15:21:10 CET] <durandal_1707> after ffserver is removed
[15:21:50 CET] <durandal_1707> im not working on yuvj, i depleted all pain killers
[15:22:22 CET] <wm4> durandal_1707: you have no tolerance
[15:22:26 CET] <wm4> weak!
[15:22:35 CET] <atomnuker> durandal_1707: you said you fixed the issues, just resubmit the patches
[15:24:23 CET] <durandal_1707> no, missing docs changes
[15:38:50 CET] <atomnuker> durandal_1707: someone else other than you can write the doc changes, they can be added later, so that's really not an issue
[16:13:43 CET] <jamrial> does the yuvj need to be done during the abi unstable period?
[16:17:38 CET] <atomnuker> if we don't deprecate them for real before it ends, then they'll be removed not during the next abi unstable period but the one after
[16:18:45 CET] <wm4> also does anyone have any ideas what we should do about side data
[16:19:34 CET] <wm4> having a shared side data implementation between all the things would be worth it, but I don't know how to do it in a backwards compatible way
[16:19:49 CET] <wm4> mainly because API users are allowed to access and manipulate the data directly
[16:20:43 CET] <atomnuker> you could synchronize the new state with the old state on input/output of things, though I'm sure that won't be pretty
[16:22:42 CET] <wm4> the main problem is, which of the old and new state should be considered the updated one
[16:24:13 CET] <atomnuker> on input of a thing with side data you should update the new state with the old state, and on output the other way around
[16:24:42 CET] <atomnuker> its just a list of refcounted side data, isn't it
[16:27:49 CET] <jamrial> atomnuker: deprecated api is removed after about two years have past since the deprecation
[16:28:05 CET] <jamrial> it doesn't matter how many bumps took place in between
[16:28:28 CET] <jamrial> could have been one, could have been four. it's the amount of time what matters, since that's what dowstream projects need to migrate
[16:29:51 CET] <jamrial> the unstable abi period is not meant to deprecate api. that can happen at any time
[16:30:07 CET] <jamrial> it's to remove or move things around that would at any other time be considered an abi break
[16:31:32 CET] <atomnuker> I see, I thought removal only happened during abi unstable periods
[16:31:56 CET] <jamrial> removal of deprecated api does happen right after the bump, yes
[16:32:08 CET] <jamrial> but not making something deprecated
[16:32:17 CET] <wm4> atomnuker: that's not sufficient, because if you update the new state, you can't distinguish it from updates to the old state
[16:33:34 CET] <atomnuker> jamrial: right, my point still remains, if yuvj doesn't make it into this period the yuvj pixfmts will be removed in... 2022
[16:33:53 CET] <jamrial> no, it will be removed two years after it's deprecated
[16:34:13 CET] <atomnuker> but you just said removal of deprecated api happens after the bump
[16:34:24 CET] <atomnuker> or do you mean api that would've been deprecated during the bunmp
[16:34:27 CET] <atomnuker> *bump
[16:34:34 CET] <atomnuker> *removed
[16:35:07 CET] <jamrial> api is deprecated whenever, then removed at least two years after the fact, during a version bump
[16:35:14 CET] <jamrial> and a bump can take place at any time we want. it's arbitrary
[16:35:42 CET] <atomnuker> but if its scheduled to be removed during an abi bump period its delayed to the end of it?
[16:35:50 CET] <jamrial> no
[16:36:09 CET] <atomnuker> oh during a major version bump then?
[16:36:28 CET] <jamrial> it's the same thing
[16:36:29 CET] <atomnuker> I thought a major bump only happened every 2 years
[16:36:38 CET] <atomnuker> not whenever we want it
[16:38:50 CET] <jamrial> it happens whenever we feel like we should get rid of old api that has been deprecated long enough, and/or get rid accumulated crap like avpriv_ symbols that are no longer necessary
[16:40:07 CET] <jamrial> for the past several years we just went along with libav bump schedule for compatibility reasons, which has been once a year or a year and a half
[16:42:55 CET] <jamrial> so now that we got rid of the lavu atomics stuff, rebase your ffserver patch and run make fate, make check, make testprogs, make checkheaders, etc, on a linux box and push if nothing broke
[16:46:11 CET] <atomnuker> did you remove the atomics?
[16:46:16 CET] <atomnuker> *avpriv_atomic stuff
[16:46:45 CET] <wm4> if you ask me having ABI stability in git is not worth the trouble
[16:47:06 CET] <jamrial> atomnuker: yeah
[16:47:31 CET] <jamrial> wm4: ffmpeg 4 should be released at the end of this month or so anyway
[16:47:57 CET] <jamrial> if we go with the usual ~3 months period between releases
[16:48:01 CET] <jamrial> 3.4 was mid october
[16:49:02 CET] <wm4> I mean that doesn't have to do with releases... releases can still be ABI stable
[16:51:48 CET] <ubitux> you'll first have to deal with cehoyos recommending git/master for almost every user
[16:52:41 CET] <ubitux> not sure any of the listening users will rely on it for anything else than the tools though
[16:53:28 CET] <wm4> I recommend git master to mpv users too, but mpv by default rejects mismatching libs/headers with a runtime check
[17:01:20 CET] <atomnuker> jamrial: k will resent rebased ffserver removal patches tonight
[17:01:40 CET] <jamrial> no, just apply it
[17:01:50 CET] <atomnuker> oh, ok
[17:02:15 CET] <jamrial> you have sent it twice already, and the last time i replied saying it would be applied near the end of the abi unstable period
[17:03:23 CET] <jamrial> so afterwards, reply to it saying it's been applied, as per usual
[17:03:52 CET] <atomnuker> do you remember which api we had to remove at the same time
[17:04:16 CET] <atomnuker> was it something related to motion compensation in lavc?
[17:04:59 CET] <jamrial> i don't recall any api that would have to be removed alongside it
[17:05:29 CET] <atomnuker> back in october there was some removal of something in avctx which broken ffserver
[17:05:44 CET] <jamrial> oh, i already dealt with that
[17:05:56 CET] <atomnuker> ah, so that's why I couldn't find it
[17:19:53 CET] <wm4> so that would remove the ffm (de)muxers too?
[17:26:42 CET] <jamrial> wm4: yeah
[17:27:53 CET] <jamrial> wm4: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-October/218264.html
[17:28:40 CET] <jamrial> atomnuker split it in six patches, the second getting rid of ffm
[18:16:07 CET] <cone-529> ffmpeg 03LongChair 07master:c6f84106366c: avcodec/rkmpp : Fix broken build due to missing control operation
[18:16:07 CET] <cone-529> ffmpeg 03LongChair 07master:2ca65fc7b744: avcodec/rkmpp : remove stream start retries before first frame.
[19:38:49 CET] <cone-529> ffmpeg 03Rostislav Pehlivanov 07master:6b35a83214f1: Remove the ffserver program
[19:38:50 CET] <cone-529> ffmpeg 03Rostislav Pehlivanov 07master:c17f4761443b: libavformat: remove the ffmenc and ffmdec muxer and demuxers
[19:38:51 CET] <cone-529> ffmpeg 03Rostislav Pehlivanov 07master:9396ed0f2915: libavformat: unexpose the ff_inet_aton function
[19:38:52 CET] <cone-529> ffmpeg 03Rostislav Pehlivanov 07master:d41de90d440a: libavformat: remove the ff_rtp_get_local_rtcp_port function
[19:38:53 CET] <cone-529> ffmpeg 03Rostislav Pehlivanov 07master:8788e82c04fe: libavformat: unexpose private ff_ functions needed by ffserver
[19:38:54 CET] <cone-529> ffmpeg 03Rostislav Pehlivanov 07master:7c6125cbcc6e: libavformat/mpjpeg: use "ffmpeg" instead of "ffserver" as boundary tag
[19:40:26 CET] <atomnuker> took a good few seconds to be processed by the git server, 8600 lines gone
[19:41:03 CET] <BtbN> wow
[19:41:07 CET] <jamrial> atomnuker: send a reply to the october thread with this set saying it's been pushed
[19:41:19 CET] <BtbN> that only that only took how many years now?
[19:41:35 CET] <wm4> I'll believe it if it doesn't get reverted within a month
[19:41:55 CET] <Compn> forgot news entry about removing ffserverr? :P
[19:42:09 CET] <jamrial> Compn: the news was posted like two years ago
[19:42:38 CET] <atomnuker> done
[19:42:53 CET] <atomnuker> though we might as well post a new news item saying *its been removed*
[19:43:04 CET] <Compn> :P
[19:43:04 CET] <atomnuker> and plug klaxa's thing maybe :)
[19:43:20 CET] Action: Compn seeds the news entry from july 2016
[19:43:23 CET] <Compn> er -d
[19:43:29 CET] <jamrial> no, no need. the news stated it would be gone in an upcoming release
[19:43:37 CET] <atomnuker> yeah
[19:43:38 CET] <Compn> just put it in changelog then 
[19:43:46 CET] <atomnuker> already in
[19:43:48 CET] <Compn> good 
[19:43:54 CET] Action: Compn runs away
[19:44:10 CET] <jamrial> once ffmpeg 4.0 is out, the news entry for it will mention it's the first without it, since it will quote the changelog
[19:44:21 CET] <Compn> yes thats fine
[19:44:51 CET] <Compn> i had forgotten that the previous message stated removing from the next release
[19:44:55 CET] <klaxa> last time ffserver was to be removed i think people complained that their pipeline depends on it
[19:44:55 CET] <Compn> its been a while :)
[19:45:11 CET] <BtbN> They had two years to do something
[19:45:16 CET] <klaxa> true enough
[19:45:16 CET] <BtbN> and it's not like they use master anyway
[19:45:19 CET] <Compn> klaxa : i still think people use ffserver...
[19:45:25 CET] <BtbN> so they still have plents time with using 3.4
[19:45:27 CET] <Compn> people still use mencoder haha
[19:45:32 CET] <klaxa> wew
[19:45:34 CET] <Compn> large corporations...
[19:45:37 CET] <Compn> cough youtube
[19:45:45 CET] <jamrial> but mencoder has binary codecs
[19:46:08 CET] <jamrial> so it's more than just a "i used it all my life, i wont change now" situation
[19:46:32 CET] <Compn> maybe now someone will come to maintain it
[19:46:33 CET] <Compn> :P
[19:46:58 CET] <klaxa> afaik there was some effort the last time as well, but nothing became of it
[19:47:09 CET] <klaxa> or was this about mencoder and not ffserver?
[19:47:26 CET] <Compn> no one helps mencoder :D
[19:48:22 CET] <jamrial> atomnuker: if you sent an email, i don't think it went through
[19:48:40 CET] <jamrial> oh, there it is
[19:48:44 CET] <atomnuker> yep, I sent an email 5 minutes ago
[19:48:50 CET] <jamrial> nevermind
[19:48:54 CET] <jamrial> that took a while
[19:53:27 CET] <jamrial> atomnuker: did you try to compile and run fate and such after these patches?
[19:54:44 CET] <jamrial> because i'm getting https://pastebin.com/n9wz1426
[19:57:47 CET] <atomnuker> nope, have a fix, compiling now
[19:57:57 CET] <jkqxz> Anyone want to comment on opencl program/source filters?
[19:58:20 CET] <jamrial> atomnuker: did you seriously push such a patchset without compiling and testing first?
[19:58:53 CET] <atomnuker> it applied fine except 1 so I thought it was okay
[19:59:00 CET] <jamrial> I told you above to do that. I shouldn't even have to say it
[19:59:10 CET] <jamrial> it's basic, jesus christ
[19:59:41 CET] <jamrial> you didn't push a one liner. you pushed a set that stripped an entire program, demuxer, muxer and exposed api
[20:00:02 CET] <jamrial> how did you even think that was a good idea?
[20:00:16 CET] <wm4> mpv travis also failed
[20:00:40 CET] <wm4> I guess it's the same reason
[20:00:49 CET] <jamrial> of course it is
[20:01:08 CET] <jamrial> seriously, wtf
[20:01:21 CET] <cone-529> ffmpeg 03Rostislav Pehlivanov 07master:c693af1951a0: libavformat/network: fix function duplication
[20:01:22 CET] <wm4> on travis it's something about inet_aton??
[20:01:26 CET] <wm4> oh
[20:01:27 CET] <wm4> ok
[20:01:41 CET] <RiCON> yeah, same error
[20:02:20 CET] <jamrial> atomnuker: that patch is not ok, why did you remove inet_atom usage and left only the emulation?
[20:02:44 CET] <atomnuker> that emulation's only there if there's no inet_aton
[20:03:40 CET] <jamrial> right
[20:05:16 CET] <jamrial> make fate doesn't work, complains about CONFIG_FFM_MUXER not existing
[20:05:18 CET] <jamrial> god fucking dammit
[20:07:23 CET] <jamrial> because production is totally the place to blindly push untested stuff
[20:08:23 CET] <Compn> i think he realizes he made a mistake 
[20:08:26 CET] <Compn> it happens jamrial
[20:08:36 CET] <Compn> atomnuker needs to drink some cola for breaking build for sure
[20:09:13 CET] <klaxa> drinking cola is punishment?
[20:09:36 CET] <Compn> klaxa : it is when its a 10L(iter) punishment
[20:09:47 CET] <klaxa> oh
[20:10:11 CET] <Compn> not all at once of course
[20:11:36 CET] <Compn> i didnt come up with this punishment, i think it was some hungarians...
[20:11:44 CET] <jamrial> atomnuker: remove the line about ffm in test/fate/avformat.mak and the two in test/fate/seek.mak
[20:11:49 CET] <jamrial> or i can do it instead
[20:12:34 CET] <jamrial> fate passes after that
[20:13:24 CET] <Compn> and while breaking the build is bad and not testing patches is also bad... i dont think too many people are using git master as production either ehe
[20:15:25 CET] <durandal_1707> Compn: why? carl is using master
[20:15:30 CET] <cone-529> ffmpeg 03James Almer 07master:8bbd8c8d52db: fate: remove missing references to ffm
[20:15:37 CET] <jamrial> atomnuker: fixed it
[20:15:57 CET] <atomnuker> thanks, sorry
[20:16:44 CET] <durandal_1707> Compn: are you cola drinker?
[20:17:38 CET] <jamrial> ubitux: btw, your fate clients haven't run in two days
[20:20:03 CET] <jamrial> Compn: one problem with breaking build like this is that it makes bisecting harder
[20:30:22 CET] <ubitux> jamrial: forgot to re-start after a hasty reboot, should be fixed, thx
[20:30:32 CET] <jamrial> ah cool
[20:56:55 CET] <BBB> this is nice
[20:57:03 CET] <BBB> ffserver gone, swr vs. avr resolved
[20:57:08 CET] <BBB> lets fix prores
[20:58:04 CET] <durandal_1707> patch welcome
[20:58:36 CET] <durandal_1707> i want zp2tf converted to C
[21:01:18 CET] <jamrial> BBB: flip a coin, remove one decoder/encoder based on that :p
[21:01:21 CET] <atomnuker> durandal_1707: what do you need that for?
[21:01:40 CET] <BBB> I guess it should be done based on performance / feature-completeness, no?
[21:02:49 CET] <atomnuker> for such a codec, yes
[21:03:13 CET] <durandal_1707> atomnuker: for aiir filter, ultimately i want to split n-form to cascaded biquads
[22:08:51 CET] <atomnuker> klaxa: can't seem to debug your mkvserver
[22:09:16 CET] <atomnuker> it sometimes goes into a slow mode where its not printing much data and not able to serve anything but a header
[22:09:30 CET] <atomnuker> run it a few times and it works for a second and it crashes
[22:09:38 CET] <atomnuker> under gdb it always goes into that slow mode
[22:09:48 CET] <atomnuker> and under valgrind it works fine and doesn't crash
[22:10:09 CET] <atomnuker> slowly and outputs incorrect timestamps so I can't find out why it crashes
[22:10:37 CET] <atomnuker> doesn't seem related to which port gets used
[22:11:44 CET] <klaxa> hmm, i'll take a look later as well
[22:14:07 CET] <cone-529> ffmpeg 03Aman Gupta 07master:9d9835017f67: lavc/mediacodecdec: switch to new decoding API
[22:14:08 CET] <cone-529> ffmpeg 03Matthieu Bouron 07master:d19174c673b8: lavc/mediacodecdec: remove mediacodec_process_data() indirection
[22:14:09 CET] <cone-529> ffmpeg 03Matthieu Bouron 07master:e30b46b1aeea: lavc/mediacodec_wrapper: allocate MediaCodec.BufferInfo once
[00:00:00 CET] --- Sun Jan  7 2018