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

[burek]

[00:34:41 CEST] <BtbN> The one in AVFrame is also an ABI break. hw_frames_ctx was added in the middle of non-private fields.
[00:34:50 CEST] <BtbN> So that needs to be fixed for 3.1.1 as well.
[00:34:52 CEST] <Illya> how can I continue fate so that I can see all the tests which fails and not just the one which does
[00:34:56 CEST] <nevcairiel> all fields below it are documented as no direct access BtbN
[00:35:03 CEST] <nevcairiel> ie. you are supposed to use getters
[00:35:11 CEST] <nevcairiel> Illya: make -k or make -i
[00:35:17 CEST] <nevcairiel> (keep going, or ignore errors)
[00:35:30 CEST] <Illya> thanks :)
[00:35:41 CEST] <BtbN> Ah. Well, that makes fixing it easier at least. Or is the position of hw_frames_ctx fixed ABI now?
[00:35:58 CEST] <nevcairiel> imho there is nothing to fix
[00:36:02 CEST] <nevcairiel> see ML, there is a thread about it
[00:37:08 CEST] <jamrial> BtbN: hw_frames_ctx is public/fixed, yes. it was added right above the first private field, so no breakage
[00:37:42 CEST] <BtbN> Well, as while we're at it, might as well move it to prevent too much of a mess here.
[00:37:55 CEST] <BtbN> And then work on a way to prevent easy access to private fields.
[00:38:26 CEST] <nevcairiel> breaking ABI of public fields between 3.1 and 3.1.1 to fix usage in "broken" client apps seems less then ideal to me
[00:39:10 CEST] <jamrial> BtbN: what nevcairiel said, moving it would /be/ an abi break
[00:40:24 CEST] <BtbN> 3.1 is kind of "burned" for now, so we can as well pretent it never happend and go straight to 3.1.1
[00:42:17 CEST] <nevcairiel> we have done such changes before, very often, and it was never a huge drama topic
[00:42:25 CEST] <nevcairiel> i still dont get whats with everyone this time
[00:42:39 CEST] <nevcairiel> one guy that complains on trac and suddenly everyone is going crazy? :)
[00:43:31 CEST] <nevcairiel> two versions back when we still kept libav compat, it was the *only* way to add fields in between public and (semi-)private to keep compat with libav, and that never caused these discussions
[00:44:00 CEST] <BtbN> Well, it breaks a lot of stuff, and is easy to avoid.
[00:44:11 CEST] <nevcairiel> any fixes are rather ugly
[00:44:19 CEST] <nevcairiel> but that doesnt answer the question
[00:44:24 CEST] <nevcairiel> why is this a topic now?
[00:45:01 CEST] <BtbN> Primarily because of the one actual public ABI break, that didn't realy matter for anything.
[00:50:01 CEST] <iive> ffmpeg broke its own ABI without bumping major version.
[00:50:09 CEST] <iive> that's the problem.
[00:50:22 CEST] <nevcairiel> the documented public ABI is not broken
[00:50:27 CEST] <nevcairiel> apps just use private parts of it
[00:50:42 CEST] <jamrial> nobody used the avfilter field, the only abi breakage
[00:50:54 CEST] <jamrial> the rest is library users not bothering to read the field's doxy
[00:51:16 CEST] <iive> any field that is in installed header is public, despite what the comment says.
[00:51:31 CEST] <iive> unfortunately.
[00:51:34 CEST] <jamrial> nope :)
[00:51:42 CEST] <nevcairiel> and if you use it, then its your breakage, not ours
[00:51:53 CEST] <nevcairiel> its not like thats a new concept
[00:51:56 CEST] <nevcairiel> we've had that for years
[00:52:13 CEST] <nevcairiel> and that private part of the ABI has also changed often
[00:52:32 CEST] <BtbN> I still prefer breaking less things if possible, even if they misuse the API. And then making sure misuse becomes harder/impossible in the future.
[00:52:35 CEST] <nevcairiel> but we're looking to get rid of it now so we dont have to discuss about this ever again
[00:53:09 CEST] <BtbN> The fixup should be done during a major bump, even if it technically wouldn't break public ABI.
[00:53:24 CEST] <iive> well, if you ask me, all structs should be private and fields should be accessed with AVOptions
[00:53:32 CEST] <jamrial> yes, we're getting rid of all the private crap in the next major bump
[00:55:41 CEST] <Illya> what's the procedure for deprecating a demuxer?
[00:55:58 CEST] <nevcairiel> there isnt one
[00:56:18 CEST] <nevcairiel> you can make it output a log message or something
[01:56:03 CEST] <Illya> michaelni: just a note on the your commit for the web regarding 3.0->3.1, it's 'recommendation' not 'recommandition' :)
[05:02:15 CEST] <cone-934> ffmpeg 03Timo Rothenpieler 07release/3.0:bffe1c42220f: ffplay: Fix usage of private lavfi API
[09:45:09 CEST] <cone-113> ffmpeg 03Benoit Fouet 07master:3e8cda1eb1a8: h264_ps: change decode_scaling_matrices so that it takes const {s,p}ps
[09:45:10 CEST] <cone-113> ffmpeg 03Benoit Fouet 07master:4cc1ce4a9178: h264: straighten dimensions check ff_h264_decode_seq_parameter_set
[09:45:11 CEST] <cone-113> ffmpeg 03Benoit Fouet 07master:879330c561f4: h264: make H264ParamSets sps const
[10:12:15 CEST] <ubitux> michaelni: do you have samples for c40f51e15?
[10:22:18 CEST] <ubitux> i'm pushing a merge commit affecting this; Anton is reworking the mmco stuff, so i'm sticking to his code
[10:26:32 CEST] <cone-113> ffmpeg 03Anton Khirnov 07master:2d410ebbaa1e: h264: decode the MMCOs into per-slice contexts
[10:26:33 CEST] <cone-113> ffmpeg 03Anton Khirnov 07master:bec993381cfe: h264: postpone generating the implicit MMCOs
[10:26:34 CEST] <cone-113> ffmpeg 03Clément BSsch 07master:d407e76c42d5: Merge commit '2d410ebbaa1e760d6837cb434a6d1d4c3c6f0d85'
[10:26:35 CEST] <cone-113> ffmpeg 03Clément BSsch 07master:f48aea66ddfe: Merge commit 'bec993381cfec72051b0d9f12ac9d9bb9c750983'
[11:38:05 CEST] <cone-113> ffmpeg 03Michael Niedermayer 07release/3.1:3e730278f5a8: avformat/mov: Check sample size
[12:35:04 CEST] <atomnuker> what does the -mp suffix do in yasm (e.g. as in r5mp)?
[12:36:14 CEST] <nevcairiel> its a pointer to the original location of that parameter, on stack if applicable
[12:36:31 CEST] <atomnuker> handy
[12:36:40 CEST] <nevcairiel> so you can reference parameters without loading them in regs
[12:36:48 CEST] <nevcairiel> or loading them manually later
[12:37:14 CEST] <ubitux> the latest merge is causing me trouble :(
[12:37:16 CEST] <ubitux> (https://github.com/ubitux/FFmpeg/compare/merge-libav)
[15:09:03 CEST] <ubitux> heh we already have an AVStreamInternal
[15:09:15 CEST] <ubitux> but many private fields aren't in
[15:34:53 CEST] <fritsch> nevcairiel: https://github.com/xbmc/xbmc/pull/10043 <- as you asked on the ML, this is all we found for now
[15:36:39 CEST] <BBB_> ubitux: reminds me of https://www.mail-archive.com/ffmpeg-cvslog@ffmpeg.org/msg17337.html
[15:37:51 CEST] <cone-113> ffmpeg 03Vadim Kalinsky 07master:e370aad67ddb: avformat/mov: Skip non-key frames if AVDISCARD_NONKEY is set.
[15:37:52 CEST] <cone-113> ffmpeg 03Dan Parrot 07master:1df908f33f65: PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.
[15:37:53 CEST] <cone-113> ffmpeg 03Martin Vignali 07master:d9e1e0813323: libavcodec/exr : fix decoding piz float file.
[15:38:57 CEST] <ubitux> what am i reading
[15:40:43 CEST] <michaelni> ffserver really badly uses internal APIs, worse its probably not even that hard to fix if someone did sit down and had the will to fix the API use
[15:41:25 CEST] <michaelni> but then i dont know the code well enugh and might be wrong
[15:43:20 CEST] <ubitux> we gave a warning to drop ffserver
[15:43:28 CEST] <ubitux> the timebomb is on
[15:43:43 CEST] <ubitux> like, next time we bump major or so
[15:43:50 CEST] <ubitux> if ffserver is not fixed by then, we drop it
[15:43:57 CEST] <ubitux> i don't remember the mail about that
[15:45:23 CEST] <ubitux> maybe we should remind the maintainer about that
[15:46:38 CEST] <michaelni> did we announce the intent of droping ffserver on twitter/facebook ?
[15:46:59 CEST] <michaelni> might wake someone up who cares to fix it properly
[15:52:39 CEST] <ubitux> if the message hasn't been received, maybe it's time yes
[15:52:54 CEST] <mateo`> maybe also announce it on the front page, if it's not the case ?
[16:02:01 CEST] <BtbN> I think we should push something to master immediately that disables ffserver unless it's explicitly enabled.
[16:02:18 CEST] <BtbN> Like, enabled ffsever || disable ffserver
[16:04:28 CEST] <ubitux> and print a warning at configure and runtime "this tool is not maintained, if you care about it, come maintain it"
[16:04:44 CEST] <ubitux> or maybe just a warning at runtime should be enough
[16:06:10 CEST] <atomnuker> yeah, I'd agree with that, disable by default and print a warning saying it'll be dropped unless it's fixed
[16:07:07 CEST] <michaelni> i think this is a good idea as well
[16:09:35 CEST] <ubitux> damn it seems we have like 40 fields that belongs in the internal field
[16:10:01 CEST] <ubitux> maybe the "options" fields should be considered public though?
[16:10:21 CEST] <ubitux> (if any)
[16:21:17 CEST] <BBB_> michaelni: so & regarding the 3.1 update
[16:21:28 CEST] <BBB_> michaelni: a slightly more extreme position could be that we should unrelease 3.1
[16:21:44 CEST] <BBB_> if you really believe that 3.1 broke ABI, then we should revoke the release
[16:22:36 CEST] <michaelni> that seems a bit extreem as an alteranative to move 2 fields in s struct
[16:23:06 CEST] <BBB> at least its deterministic
[16:23:13 CEST] <jamrial> moving those two fields are an actual ABI break
[16:23:36 CEST] <BBB> if you want to move the newly added libav-specific field down to the end of the struct&
[16:23:49 CEST] <BBB> then revoking 3.1 and re-releasing with that fix as 3.1.1 or 3.2 seems appropriate
[16:24:01 CEST] <BBB> (and then marking the whole struct as public except for AVStreamInternal)
[16:24:16 CEST] <michaelni> what exactly do you mean by revoking ?
[16:24:29 CEST] <BBB> deleting it, telling users to revert to 3.0 if they updated, etc.
[16:24:36 CEST] <michaelni> and i dont think we want to mark the whole struct as ublic
[16:24:43 CEST] <jamrial> discouraging the usage of 3.1 and such in favor of 3.1.1
[16:25:01 CEST] <michaelni> " discouraging the usage of 3.1 and such in favor of 3.1.1" <-- yes of course
[16:25:09 CEST] <BBB> the struct is essentially public
[16:25:26 CEST] <BBB> if you say 3.1 broke 3.0 abi
[16:25:34 CEST] <BBB> then by definition, the fields were part of the abi
[16:25:41 CEST] <BBB> so they are already public
[16:25:43 CEST] <BtbN> We should make sure even the private ABI matches in 3.1.1 then, so, applying the other two patches. That's the only way to make sure stuff doesn't explode, even though it is technically all private.
[16:25:44 CEST] <BBB> the documentation is just broken
[16:25:59 CEST] <BBB> you can remove their public status by moving them to AVStreamInternal in the next major bump
[16:26:08 CEST] <jamrial> BBB: no, people simply misused it
[16:26:20 CEST] <BtbN> yes, in the next major bumps those fields should all vanish from public headers.
[16:26:22 CEST] <BBB> but were suggesting to keep the misused code working
[16:26:33 CEST] <BtbN> But for now preventing a stuff from exploding seems more important to me.
[16:26:34 CEST] <BBB> so that means that in practice, they are part of public abi in this major series
[16:27:00 CEST] <BBB> so documentating them as public, treating them as such, and then marking their public status as deprecated by moving them to internal in next major bump seems appropriate?
[16:27:14 CEST] <BtbN> yes, seems fine to me
[16:27:21 CEST] <BBB> that at least formalizes the path forward and allows the compiler to give warnings now and errors in the future
[16:27:30 CEST] <BBB> the document-as-private-in-public-header is not practical
[16:27:47 CEST] <BtbN> I completely agree with that, which is why I'm very much for keeping stuff working.
[16:27:49 CEST] <michaelni> i dont want to cause our user pain, if we tell them "this is public" just to remove it next that would cause pain
[16:27:59 CEST] <jamrial> but it's been done for years. and people seemed to use them properly
[16:28:08 CEST] <BtbN> Well, "this is public and deprecated, do something" seems ok for me.
[16:28:10 CEST] <jamrial> until now when we realize they didn't, at least with avframe
[16:28:59 CEST] <BtbN> Would need some macro, so it doesn't throw deprecation warning all across libav* code, but that should be doable
[16:29:33 CEST] <BBB> btw I bought a new laptop and I believe I finally have a machine supporting avx2 now
[16:29:38 CEST] <BBB> so I can start writing avx2 assembly
[16:29:44 CEST] <jamrial> nice!
[16:29:54 CEST] <BBB> Im only 4 years late to the party
[16:30:07 CEST] <BBB> maybe Ill start the 16x16 vp9 idct or so
[16:30:47 CEST] <BBB> loopfilter would be fun also
[16:30:56 CEST] <BBB> although & complicated :)
[16:31:03 CEST] <BtbN> It also seems bad to me that updating ffmpeg breaks a lot of stuff. The blame will come to ffmpeg, not the applications.
[16:31:50 CEST] <BBB> so & it seems the agreement is that:
[16:32:09 CEST] <michaelni> BBB, about marking the fields public, i think fields not used by anyone and marked private should stay marked as private
[16:32:13 CEST] <BBB> 1) we should (As michaelni suggested) not recommend people to update to 3.1, and in addition recommend that people do _not_ upgrade to 3.1 in anticipation of 3.1.1 or 3.2
[16:32:34 CEST] <BBB> 2) mark these fields as deprecated and move them to AVStreamInternal on next major bump
[16:33:06 CEST] <BBB> (or move them to the public portion on next major bump)
[16:33:17 CEST] <BBB> (whichever applies depending on whether they should be public or not)
[16:33:44 CEST] <jamrial> which fields as deprecated?
[16:33:45 CEST] <BBB> 3) move libav-added field to bottom of struct so 3.0 abi applies to private portion of structs in a to-be-made 3.1.1 or 3.2 release
[16:33:49 CEST] <BBB> is that right?
[16:33:58 CEST] <BtbN> Yes
[16:34:00 CEST] <BBB> jamrial: the private ones that are used in ffplay
[16:34:07 CEST] <BBB> and mpv and kodi and chromium and ...
[16:34:24 CEST] <jamrial> but they are private, there's nothing to deprecate. they are meant to come and go without warning...
[16:34:40 CEST] <BBB> right, but to enforce that in the compiler, we move them to AVStreamInternal
[16:34:54 CEST] <BBB> and then the entry in the private portion of the public struct becomes deprecated
[16:35:04 CEST] <BBB> so that apps get a compiler warning telling them to stop using that field
[16:35:26 CEST] <jamrial> fritsch: look at that last ticket comment
[16:35:38 CEST] <jamrial> seems that kodi also accessed a private avstream field somewhere
[16:35:49 CEST] <jamrial> not just the avframe ones
[16:35:52 CEST] <michaelni> BBB 1/2/3 sounds ok
[16:36:47 CEST] <BBB> so & for 2) should the fields be public or moved to AVStreamInternal in next major bump?
[16:37:11 CEST] <jamrial> with avframe at least, next major bump should make every currently "do not access directly" private field public, and not shove them into an internal struct. or at least most of them
[16:37:14 CEST] <BBB> (since they are used in many apps but marked as private, so I find it hard to say which way it should go)
[16:37:28 CEST] <jamrial> mpv as we know accesses avframe->channels directly and they don't plan to change that
[16:37:41 CEST] <BBB> it would be ridiculous to tell people to use accessors
[16:37:42 CEST] <BBB> (imo)
[16:37:48 CEST] <BBB> were C, not python
[16:37:58 CEST] <jamrial> exactly
[16:38:07 CEST] <BBB> ok, so avframe all should be public
[16:38:12 CEST] <BBB> what about the AVStream field kodi uses?
[16:38:23 CEST] <BtbN> Since the libav compat stopped, there's not realy a reason not do just make them public.
[16:38:30 CEST] <jamrial> we don't know which one it is, but we can find out
[16:38:57 CEST] <BBB> ffplay uses AVStream->avg_frame_rate, right?
[16:40:08 CEST] <jamrial> in any case the priority here is choosing what to do with 3.1.1. do we apply those two patches that break avstream and avframe 3.1 abi so the private fields have the same offset as 3.0 to make distros happy
[16:40:15 CEST] <jamrial> or do we keep the abi intact and tell distros to recompile the api-misusing packages?
[16:40:40 CEST] <jamrial> 3.2/4.0 will solve all this making things public or shoving private stuff into internal structs, but that comes later
[16:42:18 CEST] <BtbN> I think they should be applied for 3.1.1.
[16:44:42 CEST] <jamrial> then apply them. 3.1 will already be incompatible with 3.1.1 anyway and i'm tired of this
[16:44:54 CEST] <BBB> so 3.1.1 will be compatible with 3.0?
[16:44:55 CEST] <jamrial> seriously, how hard was for all these projects to read a field's doxy?
[16:44:55 CEST] <BBB> ok
[16:45:02 CEST] <BBB> jamrial: I dont think people read
[16:45:11 CEST] <BBB> jamrial: I think they just copy ffplay or ffmpeg.c source code
[16:45:19 CEST] <BBB> or inspired by"
[16:45:19 CEST] <BtbN> It is easy to miss and not too obvious, which will change now.
[16:45:27 CEST] <jamrial> well, that would explain api misuse
[16:45:40 CEST] <BBB> but yes, if 4.0 fixes it through compiler enforcement, this all gets much easier
[16:46:03 CEST] <BtbN> And also, yes, most people probably practice a copy&paste style programming.
[16:46:16 CEST] <jamrial> nevcairiel: are you against it?
[16:47:27 CEST] <jamrial> 3.1 is already fucked and incompatible with 3.1.1 no matter what
[16:51:55 CEST] <jamrial> and the 3.1.1 should have a comment somewhere telling people to rtfm
[16:53:11 CEST] <Illya> ubitux: all issues with the libopenmpt demuxer are fixed, it now fully passes fate, I've sent an updated patch to the ML. You're gonna need libopenmpt 0.2.6557 or later, you can get that from here: https://buildbot.openmpt.org/builds/auto/src/
[16:54:02 CEST] <ubitux> Illya: yeah i saw it; didn't have time to test it yet
[16:54:13 CEST] <ubitux> you could use av_clipd() btw
[16:54:20 CEST] <Illya> for what?
[16:54:46 CEST] <ubitux> for the proba thing
[16:55:02 CEST] <ubitux> that's not exactly what you do though
[16:55:11 CEST] <ubitux> what's the reason for nullifying <0.25?
[16:55:52 CEST] <Illya> Then it's not a high enough match, but if you think that shouldn't be there, feel free to take it out
[16:56:10 CEST] <ubitux> not really
[16:56:29 CEST] <ubitux> btw, maybe you should try tools/probetest
[16:56:52 CEST] <ubitux> (make tools/probetest && ./probetest)
[16:57:29 CEST] <ubitux> hopefully the openmpt probing doesn't slow down the ffmpeg one too much
[17:01:51 CEST] <nevcairiel> jamrial: at this point all I really care about is fixing this in master for good later on, so whichever everyone else agrees ob
[17:01:56 CEST] <nevcairiel> on*
[17:10:36 CEST] <nevcairiel> For the earlier discussion, we'll have to see on a field by field basis if they should be made public or become really private without replacement 
[17:11:11 CEST] <nevcairiel> There is a few that make sense to keep, and some which are entirely for avformat internals 
[17:17:09 CEST] <DSM_> ubitux: what probe test is for?
[17:17:28 CEST] <ubitux> all of them if not specified
[17:18:06 CEST] <DSM_> what does it do?
[17:20:11 CEST] <jamrial> nevcairiel: agree
[17:23:02 CEST] <jamrial> michaelni: the two patches for 3.1.1 can go in
[17:23:46 CEST] <jamrial> no point wasting more time with it. lets instead focus on cleaning things in master for 3.2/4.0 with the upcoming major bump
[17:32:23 CEST] <fritsch> jamrial: yes - I think I found it
[17:33:40 CEST] <fritsch> jamrial: https://github.com/xbmc/xbmc/blob/master/xbmc/cores/VideoPlayer/DVDDemuxers/DVDDemuxFFmpeg.cpp#L1231 <- might be that one?
[17:33:53 CEST] <nevcairiel> thats probably one yes
[17:34:26 CEST] <jamrial> fritsch: yes
[17:34:49 CEST] <nevcairiel> codec_info_nb_frames  is one of those fields i would preferably just recycle out of the API entirely, since its values depend on the internal probing process, which may not even take place if the container provides enough data
[17:35:28 CEST] <fritsch> jamrial: how to replace it? You know out of head?
[17:35:41 CEST] <nevcairiel> its a private field, there is no replacement
[17:36:02 CEST] <fritsch> how to get the information of this private field?
[17:36:07 CEST] <fritsch> as it is needed in our code?
[17:36:09 CEST] <nevcairiel> its private, you dont. :)
[17:36:43 CEST] <nevcairiel> like i said above, the meaning of this field is not very well defined and the values depend on a lot of factors that no user knows without reading the code
[17:37:25 CEST] <fritsch> perhaps the user (we) read the code
[17:37:44 CEST] <nevcairiel> that doesnt make it any better public API though
[17:38:33 CEST] <jamrial> fritsch: regarding the avframe ones, since fernet scheduled the patches for release 18 you may not even need to apply them at all. depending on how far away that release is, we may have already released 3.2/4.0 making those fields public
[17:38:34 CEST] <nevcairiel> avformat decodes frames until it has all the info it needs
[17:38:53 CEST] <nevcairiel> if it finds the info after 1 frame, then it will be happy and quit decoding
[17:39:03 CEST] <nevcairiel> does that mean the stream info is unreliable? certainly not
[17:39:41 CEST] <fritsch> jamrial: yeah - I want it fixed. Though being blamed for having code like that for > 10 years :-) does not feel so well
[17:39:54 CEST] <fritsch> looking again I think we don't need that field there at all
[17:40:10 CEST] <nevcairiel> if we release 3.2 or 4.0 with a fresh new ABI you probably dont even need to fix anything
[17:40:14 CEST] <fritsch> fernet says: "it is stoneold dvd crap" :-)
[17:40:19 CEST] <fritsch> translated from german
[17:40:39 CEST] <nevcairiel> as everything in AVFrame will be public, it has no reason to have any internal fields
[17:40:54 CEST] <fritsch> we will remove it for v18
[17:41:11 CEST] <fritsch> reason: that part of the code (demuxer) is so fugly wrong - that from three times wrong it gets right at the end
[17:41:14 CEST] <fritsch> :-)
[17:41:18 CEST] <fritsch> very regression happy that part
[17:41:19 CEST] <nevcairiel> in any case, there is a bunch of fields in AVStream just like this one where we have to decide and figure out what to do with them
[17:41:33 CEST] <nevcairiel> which is our task until the next major
[17:42:15 CEST] <jamrial> avframe is simple, everyhting there is made public and the accessors deprecated
[17:42:16 CEST] <fritsch> yeah - as said - we are happy to become API conform, though our software has grown for ages and is very fragile at certain positions
[17:42:37 CEST] <jamrial> avstream not so much. all the private fields are truly private, with no accessors. plenty of them also exist in libav, even
[17:43:34 CEST] <fritsch> nevcairiel: when do you push that dvd menu patch to 3.1?
[17:43:50 CEST] <nevcairiel> michaelni will probably do it in a bit
[17:43:54 CEST] <fritsch> thx, much
[17:44:16 CEST] <nevcairiel> i'm only on a phone right now, home internet is flaky
[17:45:15 CEST] <fritsch> i looked for ages for a phone with a real keyboard - but could not find one since that old nokia n900
[17:45:26 CEST] <fritsch> sorry, that was offtopic - just thought loudly
[17:45:56 CEST] <cone-113> ffmpeg 03Michael Niedermayer 07master:042fb69deb53: avutil/frame: Move new field to the end of AVFrame
[17:45:57 CEST] <cone-113> ffmpeg 03Hendrik Leppkes 07master:c2e13d2ecd38: avformat/utils: update deprecated AVStream->codec when the context is updated
[17:45:58 CEST] <cone-113> ffmpeg 03Michael Niedermayer 07master:c1c7e0abb0c5: avformat/avformat: Move new field to the end of AVStream
[17:45:59 CEST] <nevcairiel> yeah those are extremely rare
[17:46:05 CEST] <fritsch> michaelni: thx much!
[17:52:59 CEST] <jamrial> fritsch: motorola droid 4? it's kinda old by now but maybe there's a more recent model
[17:53:10 CEST] <fritsch> there isn't
[17:53:13 CEST] <fritsch> :-)
[17:53:19 CEST] <fritsch> i checked exactly out of that reason
[17:53:27 CEST] <fritsch> there are the new android blackberrys
[17:53:34 CEST] <fritsch> but they are kind of "wrong form factor"
[17:53:52 CEST] <fritsch> 9:16 with the keyboard going out on the wrong side
[18:04:01 CEST] <cone-113> ffmpeg 03Martin Vignali 07release/3.1:37c83b53730a: libavcodec/exr : fix decoding piz float file.
[18:04:02 CEST] <cone-113> ffmpeg 03Michael Niedermayer 07release/3.1:77473002898f: avutil/frame: Move new field to the end of AVFrame
[18:04:03 CEST] <cone-113> ffmpeg 03Hendrik Leppkes 07release/3.1:79af094b9304: avformat/utils: update deprecated AVStream->codec when the context is updated
[18:04:04 CEST] <cone-113> ffmpeg 03Michael Niedermayer 07release/3.1:f617b94c233f: avformat/avformat: Move new field to the end of AVStream
[18:04:45 CEST] <fritsch> we access much more in our demuxer
[18:04:54 CEST] <fritsch> including stream's metadata to find the rotation
[18:08:59 CEST] <nevcairiel> metadata should be public
[18:13:25 CEST] <fritsch> nevcairiel: it's "below" that fields
[18:14:22 CEST] <nevcairiel> Hm. Well we'll clean that up soon 
[18:15:01 CEST] <fritsch> fine mis looked it
[18:15:08 CEST] <fritsch> good it's public
[18:19:08 CEST] <BBB> jamrial: can I ask avx2 n00b questions?
[18:19:21 CEST] <jamrial> yes, i can try to answer them :p
[18:19:35 CEST] <BBB> is there a movhps to move the upper half of a ymm register to memory?
[18:20:05 CEST] <jamrial> vextracti128
[18:20:11 CEST] <jamrial> http://www.felixcloutier.com/x86/VEXTRACTI128.html
[18:20:14 CEST] <BBB> vextracti128 [mem], ymm0?
[18:20:28 CEST] <BBB> okiedokie
[18:20:38 CEST] <jamrial> vextracti128 [mem], ymm0, 1
[18:21:30 CEST] <jamrial> 0 would extract the low 128bits, but in that case you should use movdqa with xmm reg anyway
[18:24:28 CEST] <jamrial> afaik reading an xmm reg using vex encoded instructions doesn't zero the upper 128 bits, only if you write it
[18:24:32 CEST] <jamrial> so vmovdqa [mem], xmm0 should keep the upper contents intact much like vextracti128 [mem], ymm0, 0
[18:25:45 CEST] <BBB> does movh expand to vmovdqa in avx2 mode?
[18:31:28 CEST] <jamrial> BBB: no
[20:05:24 CEST] <BBB> jamrial: and (in the cases where I have to) how do I transfer data between low/high halves of ymm again?
[20:05:33 CEST] <BBB> jamrial: I recall I have to limit it, but in some cases I have to
[20:05:44 CEST] <BBB> jamrial: e.g. a transpose
[20:07:12 CEST] <jamrial> BBB: vinserti128 http://www.felixcloutier.com/x86/VINSERTI128.html or vpermi128 http://www.felixcloutier.com/x86/VPERM2I128.html
[20:07:38 CEST] <jamrial> *vperm2i128
[20:08:57 CEST] <jamrial> BBB: x264 for example updated the SBUTTERFLY macro to use these when mmsize > 16
[20:14:47 CEST] <rcombs> REAL programmers use SBUTTERFLY
[20:24:47 CEST] <BBB> jamrial: only for dqqq?
[20:25:00 CEST] <BBB> jamrial: I mean, I assume you dont want to do that for all uses, right?
[23:03:22 CEST] <BBB> jamrial: btw mova [mem], xm0 does indeed clear the upper half of xm0
[23:04:39 CEST] <BBB> oh wait no its something else
[23:04:44 CEST] <BBB> just kick me Im stupid
[23:06:08 CEST] <BBB> I totally hate avx2 now
[23:06:17 CEST] <BBB> what on earth were they thinking stupid idiots
[23:06:20 CEST] <jamrial> haha, what happened?
[23:06:37 CEST] <BBB> well I handle 16x16 coefs in my idct16x16 right?
[23:06:45 CEST] <BBB> so Im really careful to not ever cross lanes etc.
[23:07:00 CEST] <BBB> but in the end you need to write out 16 byte pixels by adding 16 words
[23:07:15 CEST] <BBB> so I mova xm%d, [mem to 16 bytes]
[23:07:17 CEST] <BBB> and then punpcklbw
[23:07:22 CEST] <BBB> which obviously doesnt work
[23:07:26 CEST] <jamrial> to zero extend?
[23:07:55 CEST] <BBB> yes, but it will only zero extend the first 8 bytes, the other 8 are shifted out of the second quarter of the reg, the third quarter is zero being zero-extended
[23:07:57 CEST] <BBB> [etc]
[23:08:01 CEST] <jamrial> you're in luck, because sse4's pmovzx is probably the only instruction intel didn't fuck up regarding lanes
[23:08:08 CEST] <jamrial> as it zero extends across lanes
[23:08:08 CEST] <BBB> so if you have 16 contiguous pixels&
[23:08:13 CEST] <BBB> hm....
[23:08:18 CEST] <BBB> so strange
[23:08:41 CEST] <jamrial> http://www.felixcloutier.com/x86/PMOVZX.html
[23:08:47 CEST] <jamrial> look at VPMOVZXBW (VEX.256 encoded version)
[23:09:21 CEST] <jamrial> and yes, i also wondered why only this one and pmovsx
[23:09:37 CEST] <BBB> oh because it takes xmm as input
[23:09:41 CEST] <BBB> it actually makes sense then
[23:09:43 CEST] <BBB> still stupid
[23:11:23 CEST] <jamrial> for pack functions you're screwed, though
[23:11:33 CEST] <jamrial> you'll have to shuffle stuff around
[23:11:58 CEST] <jamrial> avx512 is the set that adds pack functions that cross lanes i think
[23:12:50 CEST] <BBB> I so hate this
[23:12:55 CEST] <BBB> what on earth were they thinking
[23:13:02 CEST] <jamrial> *instructions
[23:13:05 CEST] <BBB> oh lets just invent our own geometry, maybe we can patent it"?
[23:15:00 CEST] <jamrial> since moving data across lanes costs extra cycles maybe there were some design issues
[23:15:13 CEST] <jamrial> maybe Gramner knows
[23:15:34 CEST] <BBB> how do I extract 8 bytes?
[23:15:42 CEST] <BBB> vextracti64 doesnt seem to exist
[23:16:02 CEST] <jamrial> eight bytes from where?
[23:16:15 CEST] <jamrial> first eight bytes from upper half?
[23:17:10 CEST] <jamrial> i think you'll have to use vpermq for that
[23:17:45 CEST] <Gramner> you can't extract less than 16 bytes from the upper half
[23:17:49 CEST] <Gramner> because reasons
[23:18:00 CEST] <Gramner> nor insert
[23:18:22 CEST] <BBB> because reasons is what I tell my kids when I just want them to shut up
[23:18:31 CEST] <Gramner> they didn't extend the insertion/extraction instructions to avx2 for some reason. I tried asking intel but they ignored me
[23:18:45 CEST] <BBB> vpermq works but yes that takes an extra instruction which I was trying to prevent
[23:19:01 CEST] <BBB> I mean basically this means that ymm is just a very odd way of doing two xmm instructions at once
[23:19:09 CEST] <jamrial> Gramner: probably because the vperm[qd] instructions covers it
[23:19:23 CEST] <jamrial> although vpermd sucks for something as simple as extracting a word because it takes a reg as index
[23:19:25 CEST] <BBB> as soon as there are contiguity requirements across the register, it stops working
[23:20:01 CEST] <BBB> well I suppose intel would ignore me also
[23:20:19 CEST] <BBB> at leas tthe dc only works now
[23:20:22 CEST] <BBB> thats kind of nice
[23:20:33 CEST] <BBB> (yay, dc only 16x16 vp9 idct!)
[23:20:56 CEST] <Gramner> jamrial: permutes aren't really equivalent to extracts. if I want to extract dword #6 from an ymm register to memory you can't do it in a single instruction. you could before avx2
[23:21:02 CEST] <jamrial> BBB: great. but is it faster after all the lane bullshit? :P
[23:21:11 CEST] <BBB> Im scared to test
[23:21:15 CEST] <jamrial> Gramner: ah, true. i was thinking about reg to reg
[23:21:19 CEST] <BBB> because I give it 50% that the answer is no
[23:21:48 CEST] <nevcairiel> thats still 50% yes!
[23:22:27 CEST] <Gramner> I believe the main reason for the lane stuff is to be able to easily power-gate off the upper half
[23:23:18 CEST] <Gramner> you'd need more transistors to duplicate some functionality otherwise
[23:32:14 CEST] <BBB> really& so anyone implementing things that switch between words and bytes and operates on contiguous 16 pixel blocks needs a vpermq per 16px?
[23:32:22 CEST] <BBB> I just cant believe this, this is ridiculous
[23:32:45 CEST] <BBB> no wonder people are excited about ppc64
[23:32:50 CEST] <BBB> this is like corporate suicide
[23:33:42 CEST] <Gramner> intel instruction sets are mainly aimed at HPC applications nowadays
[23:43:39 CEST] <BBB> at least in the dc-only the vpermq can be removed by doing some other weird things, but for the full idct a vpermq will be required
[23:43:40 CEST] <BBB> :(
[23:43:45 CEST] <BBB> ohwell
[23:43:49 CEST] <ubitux> BBB: try out aarch64, it's clean to write
[23:43:51 CEST] <BBB> hpc doesnt require speed anyway
[23:44:02 CEST] <BBB> if your application is slow, just buy twice as many servers
[23:44:04 CEST] <BBB> now its fast again
[23:44:10 CEST] <BBB> Intel Inside [TM]
[23:44:26 CEST] <ubitux> sounds legit
[23:44:29 CEST] <nevcairiel> those people also like efficiency
[23:44:36 CEST] <Gramner> nah, then you need twice as much space and twice as much cooling
[23:44:45 CEST] <atomnuker> BBB: why not use pshufb?
[23:44:49 CEST] <BBB> dont you know how many jobs that creates?
[23:45:02 CEST] <BBB> dude, the number of jobs created - just think construction, etc.
[23:45:05 CEST] <nevcairiel> why would they want to pay more people? =p
[23:45:08 CEST] <BBB> donald trump would be proud of you
[23:45:14 CEST] <BBB> because Intel Loves Everyone! [TM]
[23:48:29 CEST] <kierank> 0:44 PM <"nevcairiel> those people also like efficiency --> no they don't
[23:48:34 CEST] <kierank> it's grad students code that doesn't work
[23:49:25 CEST] <nevcairiel> well they still like to claim to have high density high performance hardware instead of a warehouse full of slow things
[23:49:27 CEST] <BBB> atomnuker: pshufb is still a shuffle - Im trying to do things shuffle-less"
[23:49:31 CEST] <nevcairiel> no matter how bad their code is
[23:49:49 CEST] <BBB> fast vs. slow code is a very perceptual thing
[23:49:58 CEST] <BBB> you can easily hire a bunch of marketeers and say that its fast
[23:50:01 CEST] <BBB> hevc is fast
[23:50:06 CEST] <BBB> and now everyone believes you
[23:50:17 CEST] <BBB> as long as you jazz it up with some nice jingles and some splashy glitter
[23:52:30 CEST] <BBB> ok time to make the full idct work
[23:52:34 CEST] <BBB> this is so painful :D
[00:00:00 CEST] --- Fri Jul  1 2016