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

[burek]

[00:46:29 CEST] <cone-366> ffmpeg 03Marton Balint 07master:cbcb8f5a22e8: fate: add fate test for ticket #6603
[00:46:30 CEST] <cone-366> ffmpeg 03Marton Balint 07master:61e25ab0bf9f: fate: add fate test for ticket #6375
[02:30:33 CEST] <cone-366> ffmpeg 03Steven Liu 07master:171adca696ee: Revert "flvdec: Check the avio_seek return value after reading a  metadata packet"
[02:30:34 CEST] <cone-366> ffmpeg 03Martin Storsjö 07master:15537c904ec9: flvdec: Check the avio_seek return value after reading a  metadata packet
[02:50:42 CEST] <cone-366> ffmpeg 03Marton Balint 07master:273f11969d1d: fate: fix ffmpeg-attached_pics test dependencies
[05:15:51 CEST] <rcombs> jya: somewhat, what's up?
[05:35:45 CEST] <cone-366> ffmpeg 03James Almer 07master:5834cba05efb: MAINTAINERS: add my GPG fingerprint
[09:57:54 CEST] <jya> rcombs: remind me which of my questions it was about? One of the parser? 
[09:58:13 CEST] <rcombs> yeah, AAC parser
[09:58:52 CEST] <jya> I got my answer there already :) the parser expects adts and I was feeding it raw aac
[11:42:31 CEST] <fx159159> Hey, is there an internal ffmpeg function to convert three separate YUV420 buffers to one YUV420P buffer?
[11:43:39 CEST] <BtbN> What do you mean? yuv420p always is 3 seperate planes
[11:44:46 CEST] <nevcairiel> he probably wants it in a continous memory buffer for some third party consumption
[11:45:15 CEST] <fx159159> I'm developing and indev for the android ndk camera 2 api, currently I'm getting an image from the apis that gives me three separate buffers for Y, U and V, now I want to put these buffers into one AVPacket
[11:45:23 CEST] <fx159159> Yeah
[11:45:49 CEST] <nevcairiel> you could use wrapped_avframe and just pass them on as-is
[11:46:52 CEST] <nevcairiel> otherwise you can allocate a buffer and use av_image_fill_pointers to automatically get the proper pointers, and use av_image_copy afterwards to copy it into that
[11:47:14 CEST] <nevcairiel> or av_image_fill_arrays, might be better
[11:47:35 CEST] <nevcairiel> or perhaps even av_image_copy_to_buffer, which should do that mostly in one step, you just need to allocate it still
[11:48:56 CEST] <fx159159> Ok, av_image_copy_to_buffer looks right
[11:49:28 CEST] <fx159159> So I pass the pointers to the three buffers to av_image_copy_to_buffer and the function copies them into one buffer?
[11:49:42 CEST] <nevcairiel> pretty much
[11:50:10 CEST] <nevcairiel> you can use av_image_get_buffer_size to figure out the size of the buffer you need to allocate as well
[11:50:18 CEST] <fx159159> Cool, thanks, will try that
[11:50:42 CEST] <fx159159> I already know how big the buffer should be, the android api tells me the size for each buffer
[11:52:49 CEST] <fx159159> Would calling av_new_packet with the buffer size and then calling av_image_copy_to_buffer with dst set to pkt->data work?
[11:57:47 CEST] <fx159159> nevcairiel: What should align be for av_image_copy_to_buffer?
[12:40:20 CEST] <nevcairiel> probably 1 if you're trying to make something compatible with RAWVIDEO
[15:11:19 CEST] <fx159159> nevcairiel: Ok got to try it, but that does not seem to work... av_image_copy_to_buffer wants the source pixel format, it is YUV420 unpacked, but ffmpeg does not know unpacked YUV420?
[15:12:11 CEST] <nevcairiel> YUV420P should be fine as a pixel format
[15:12:39 CEST] <fx159159> Running the app results in greenish video frames
[15:13:25 CEST] <fx159159> The camera continously delivers frame, I can see things moving, but the frames are greenish and distorted
[15:17:38 CEST] <fx159159> nevcairiel: https://abload.de/img/distorted2ejxb.jpg see here
[15:19:35 CEST] <jkqxz> Your pitch is wrong.  Possibly by exactly 1/5 the width of the frame.
[15:21:37 CEST] <nevcairiel> yeah that looks like wrong pitch/linesize
[15:25:03 CEST] <fx159159> Excuse me... but whats is pitch?
[15:25:39 CEST] <atomnuker> stride
[15:26:14 CEST] <fx159159> Swapping height and width (linesize calculation?) it looks like this https://abload.de/img/distorted2uqjsv.jpg
[15:26:42 CEST] <atomnuker> #bytes per line != width*sample_size
[15:29:43 CEST] <fx159159> ah wait... android calls it YUV420_888, so 24 bpp? not 12 like YUV420P?
[15:31:22 CEST] <JEEB> that's probably the bit depth for each sample, which is 8 in 8bit 4:2:0, the chroma subsampling probably isn't taken into account in that :P
[15:33:14 CEST] <fx159159> it is described here: https://developer.android.com/ndk/reference/group___media.html#gga9c3dace30485a0f28163a882a5d65a19aea9797f9b5db5d26a2055a43d8491890
[15:42:51 CEST] <Mavrik> Hmm, it's not really 24 bits per pixel is it? :)
[15:43:05 CEST] <Mavrik> Since it's 4:2:0 subsampled - second two planes will be half of size
[15:44:11 CEST] <fx159159> So it could be something like AV_PIX_FMT_YUV420P16LE ?
[15:45:40 CEST] <Mavrik> No, it actually sounds very much like AV_PIX_FMT_YUV420P
[15:45:55 CEST] <Mavrik> But your artifacts look like you missed stride/height/width
[15:50:26 CEST] <fx159159> Android gives me 368512, 122688, 122688 as sizes for the lines? Does that sound correct? I would assume I'd need a buffer of the size 613888 then, but av_image_fill_linesizes suggests 460800?
[15:50:28 CEST] <fx159159> Is that bytesß
[15:50:30 CEST] <fx159159> ?
[15:50:59 CEST] <fx159159> Ah, not av_image_fill_linesizes, I meant av_image_get_buffer_size
[15:52:53 CEST] <Mavrik> Is that width or stride?
[15:53:30 CEST] <Mavrik> Note that especially in hardware buffers, there might be an important difference between those two :)
[15:54:26 CEST] <fx159159> I'm not quite sure, I'm using a function getPlaneData, it's documentation says "dataLength the valid length of data will be filled here if the method call succeeeds"
[15:55:15 CEST] <fx159159> getPlanePixelStride / getPlaneRowStride are also available, could they be of any help?
[16:04:01 CEST] <iive> linesize is byte offset 
[16:04:04 CEST] <Mavrik> You should almost certanly use those to fill up AVFrame properly ;)
[16:12:19 CEST] <fx159159> So there could be some kind of padding by android? I'm new to these terms... trying to understand it
[16:23:23 CEST] <jamrial> can someone help me come up with a idea/solution for 50a1c66cf6? (libav commit)
[16:23:30 CEST] <jamrial> we're also calling avpriv_ac3_parse_header() in movenc, and looking at a lot more fields than the ac3 demuxer
[16:25:30 CEST] <jamrial> making it pretty much impossible to not keep AC3HeaderInfo as part of the abi
[16:28:49 CEST] <jamrial> that in itself wouldn't be a problem since it's more or less a fixed struct, but then movenc also uses the GetBitContext past the point avpriv_ac3_parse_header() leaves it at, making it also hard to remove its usage...
[16:38:48 CEST] <fx159159> Android tells me row strides are 768, 512, 512, that means 512 * 480 should be 245760 but I'm getting only the half 122880? For 768 * 640 it's correct? 368512
[16:40:13 CEST] <jkqxz> The chroma planes are subsampled by a factor of two in both directions - they have half as many lines as well.
[16:40:56 CEST] <fx159159> 768 * 640 is 368640, android says 368512, that is also off by 128
[16:41:20 CEST] <Mavrik> fx159159: the reason why you need to pass stride into APIs 
[16:41:37 CEST] <Mavrik> is because what you're seeing right now - lines may have padding between them
[16:41:45 CEST] <Mavrik> this is why you're seeing difference between width and stride
[16:42:15 CEST] <Mavrik> that's especially common in hardware decoders which tend need lines to be aligned to some certain size 
[16:42:17 CEST] <fx159159> then the chroma plane sizes are off by 192
[16:42:50 CEST] <fx159159> Yeah I understood that, a 640 pixel wide line gets rounded up to 768
[16:42:56 CEST] <Mavrik> This is why you need BOTH width and stride - width for actual size of picture data and stride for width + whatever buffer padding there is
[16:43:49 CEST] <fx159159> So... how do I tell av_image_copy_to_buffer to respect the strides?
[16:44:36 CEST] <fx159159> Is it linesizes ... ?
[16:45:28 CEST] <JEEB> point in buffer + stride should always get you to the same point on the next line
[16:45:40 CEST] <nevcairiel> linesizes is the stride, yes
[16:47:15 CEST] <fx159159> awesome
[16:48:20 CEST] <fx159159> https://abload.de/img/stridesntjqs.jpg
[16:48:23 CEST] <fx159159> :)))
[16:49:09 CEST] <fx159159> thank you
[18:27:38 CEST] <durandal_1707> michaelni: congratulations for new fork, excelent work, keep going
[18:29:34 CEST] <jamrial> durandal_1707: sounds more like the EOF thing in avio is the reason
[18:29:53 CEST] <jamrial> nicolas' patch should be pushed already
[18:30:13 CEST] <jamrial> it is an api break and has been in the tree for a few weeks now
[18:30:56 CEST] <JEEB> it was a mix of things according to the discussions I've seen
[18:31:02 CEST] <JEEB> since the same push contained the hwaccel thing
[18:31:03 CEST] <jamrial> i don't get how it hasn't yet been pushed, or at least the change reverted until it was fixed
[18:31:18 CEST] <jamrial> no, the hwaccel is unrelated to the avio EOF thing
[18:31:23 CEST] <JEEB> yea it is
[18:31:49 CEST] <JEEB> just that it was the thing that was unconditionally added to the code base IIRC when the switch was done to a custom repo
[18:31:50 CEST] <jamrial> it is something wm4 and thilo need commited, but michaelni is blocking
[18:32:06 CEST] <jamrial> a vote should be called or more devs should chime in already and tip the scales
[18:32:22 CEST] <jamrial> it's stupid how long something like this can last without a solution
[18:32:51 CEST] <JEEB> meh, sfan5 didn't test nicholas's patches
[18:33:06 CEST] <JEEB> I will have to re-poke him I guess
[18:33:46 CEST] <jamrial> nobody else here uses mpv to test it?
[18:34:38 CEST] <JEEB> I'll while try to understand the change
[18:34:46 CEST] <jamrial> maybe wm4, but i guess he's in a "fuck ffmpeg" mood atm
[18:35:50 CEST] <JEEB> I can re-test it as well but I'll try to check the code first
[18:36:39 CEST] <JEEB> huh
[18:36:51 CEST] <JEEB> I think I don't understand what is meant with "stream protocols"
[18:37:07 CEST] <JEEB> is giving your own AVIO a "stream protocol"?
[18:38:29 CEST] <JEEB> trying to think what !s->max_packet_size has to do with it all
[18:39:13 CEST] <JEEB> https://patchwork.ffmpeg.org/patch/5686/
[18:39:22 CEST] <JEEB> maybe I'm just stupid
[18:41:04 CEST] <jamrial> just test it and reply yo the thread if it works
[18:41:12 CEST] <jamrial> this crap should have been fixed or reverted long ago
[18:58:37 CEST] <michaelni> jamrial, about hwaccel, i agree more people should chime in and especially people wth calm mood. There are 2 obvious options, using the opaque_ref field with wraping (iam against this), using a new field marton called it priv_ref (wm4 is against this)
[18:58:52 CEST] <michaelni> its deadlocked atm
[18:59:22 CEST] <JEEB> anyways, builing nicholas's patch on mingw-w64 right now
[18:59:27 CEST] <JEEB> and will then test
[18:59:46 CEST] <JEEB> although I still don't understand the if (!ret && !s->max_packet_size) => zero is EOF
[18:59:49 CEST] <JEEB> part
[19:01:47 CEST] <JEEB> lol
[19:01:56 CEST] <JEEB> had already forgotten how long configure took on windowse
[19:04:18 CEST] <iive> michaelni: i don't see what is the point of the wrapping, after all, what it does is move one variable to another. and then move it back..
[19:08:07 CEST] <JEEB> well you could say the same about side data
[19:08:25 CEST] <JEEB> it's IIRC given to you as an opaque buffer stuck to a frame or a packet
[19:08:55 CEST] <JEEB> or is it due to possibly the API client doing the sticking and pulling?
[19:09:03 CEST] <JEEB> IIRC it was supposed to be lavc-internal?
[19:12:08 CEST] <michaelni> side data has a type so any access will get the correct type or nothing. with opaque_ref the existing opaque data is put in a struct in a AVBufferRef and lavc internal data and the whole becomes the new opaque for AVFrame. And this then needs to be unwraped wheever the frame is passed back to the user
[19:12:48 CEST] <JEEB> yes, the side data has a type variable next to it so you know how to "unwrap" the voidptr
[19:14:37 CEST] <JEEB> aand configure finally finished
[19:15:27 CEST] <jamrial> JEEB: what version of windows are you using? also, msys2 or something else?
[19:15:51 CEST] <JEEB> msys2 with nev's known-to-work mingw-w64 toolchain
[19:15:53 CEST] <JEEB> win10
[19:15:58 CEST] <jamrial> i noticed msys2's sh became much slower since i upgraded to the fall's creator win10 build
[19:16:11 CEST] <JEEB> right, that's what I am on
[19:16:19 CEST] <jamrial> figures
[19:16:41 CEST] <JEEB> still thought this would be simpler to play video on than the development Fedora VM I have on this thing :)
[19:17:18 CEST] <jamrial> you could try the ubuntu-in-windows thing win10 features since the creator's build
[19:17:38 CEST] <jamrial> Gramner tried it, i think. i should give it a try as well
[19:18:24 CEST] <JEEB> yea I know the windows subsystem for linux :)
[19:18:56 CEST] <JEEB> but that IIRC isn't better than running a VM, since the only problem with the VM I have is the video playback part - which might even work nicely. I just haven't tested :)
[19:19:04 CEST] <JEEB> just do development/android builds there
[19:19:10 CEST] <Gramner> WSL is good enough for compiling stuff
[19:19:13 CEST] <JEEB> yea
[19:19:26 CEST] <Gramner> can even use msvc through it since some time ago
[19:19:43 CEST] <JEEB> yea you can access windows files
[19:20:08 CEST] <Gramner> need some configure/makefile modifications though since it requires you to use .exe suffixes when calling native windows binaries
[19:20:15 CEST] <Gramner> e.g. cl.exe instead of cl
[19:20:18 CEST] <JEEB> yup
[19:20:58 CEST] <iive> JEEB: side data has been used to send things that are not accessible otherwise. for example, demuxer would send rgb palette as side data. If the aplications wants to use that data, it doesn't have other options.
[19:21:15 CEST] <JEEB> yes
[19:22:03 CEST] <iive> JEEB: there was also a hack, that wrapped sidedata into packets, in order to allow transparent passing from libavformat to libavcodec, for applications that doesn't handle side data
[19:23:02 CEST] <iive> JEEB: and that was removed
[19:23:26 CEST] <JEEB> yes, I recollect some things alright even if my brains aren't functioning properly :)
[19:24:03 CEST] <jamrial> michaelni: does the updated patchset wm4 sent (the one i replied to just now) also have the issues with opaque_ref you dislike?
[19:24:22 CEST] <BtbN> Gramner, any idea how I can load the msvc env in WSL? The bat script for it clearly doesn't work.
[19:24:41 CEST] <JEEB> I think it was about adding the toolchain into PATH
[19:24:50 CEST] <BtbN> It does more magic than that
[19:24:58 CEST] <BtbN> A lot, its like a 1000+ line bat script
[19:25:09 CEST] <Gramner> you need to uncomment some line in the msys2_shell.cmd batch script
[19:25:19 CEST] <Gramner> it's documented near the top of the file
[19:25:26 CEST] <Gramner> to make it keep PATH
[19:25:26 CEST] <BtbN> Where is that file?
[19:25:32 CEST] <Gramner> msys2 root dir
[19:25:38 CEST] <BtbN> I don't have msys anywhere
[19:25:39 CEST] <Gramner> oh wait, sorry
[19:25:42 CEST] <Gramner> i misread
[19:26:21 CEST] <BtbN> I have some magic for it in cygwin, but that method won't work for wsl
[19:27:11 CEST] <Gramner> just run the msvc command prompt and launch bash.exe from there
[19:27:25 CEST] <Gramner> should maintain PATH
[19:35:04 CEST] <michaelni> jamrial, the one from 2017-10-13 looks like it contains the same opaque_ref wraping code 
[19:35:26 CEST] <jamrial> ok
[19:37:42 CEST] <BtbN> Oh hey, AMD realized that we don't want an entire copy if ffmpeg in compat/
[19:37:53 CEST] <BtbN> This patch actually looks decent on a very first quick scroll-through
[19:40:30 CEST] <durandal_1707> with 1k of compat nonsense?
[19:42:26 CEST] <BtbN> we have 5k lines of nvidia stuff there
[19:42:49 CEST] <durandal_1707> what?
[19:43:00 CEST] <durandal_1707> who commited that?
[19:43:18 CEST] <BtbN> granted, it's not only an encoder, so it makes sense it's more
[19:44:13 CEST] <durandal_1707> rush, remove 5k of corporate code
[19:44:35 CEST] <BtbN> Because everything coming from a company is bad, right
[19:44:48 CEST] <durandal_1707> look at it 
[19:47:40 CEST] <BtbN> I did, it really does not look that bad.
[19:50:19 CEST] <sfan5> ./libavutil/internal.h:122:5: warning: "HAVE_LOCAL_ALIGNED" is not defined, evaluates to 0 [-Wundef]
[19:50:27 CEST] <nevcairiel> re-run configure
[19:50:28 CEST] <sfan5> hmm this warning is new (maybe someone cares enough to fix it)
[19:50:29 CEST] <sfan5> oh
[19:52:26 CEST] <sfan5> works, thanks
[19:53:09 CEST] <michaelni> BBB, can i push "avcodec/version: Postpone FF_API_DEBUG_MV" or do you want me to wait? you seemed to have objections to it
[19:53:34 CEST] <BBB> Id prefer if you dealt with the objection first, yes
[19:53:51 CEST] <BBB> IMO the objection is reasonable and is easily addressed
[19:54:01 CEST] <BBB> what Im asking for is a plan and a commitment by someone to abide by that plan
[19:54:23 CEST] <BBB> no plan? then it wont be fixed anyway, ffserver all over, so just get rid of it now, lets not be silly about this
[19:54:44 CEST] <BBB> plan? make the plan, set a date; if the plan holds up, great, if not, well then ffserver all over anywya and we remove it, but at least we tried?
[19:54:50 CEST] <jamrial> BtbN: it's a reduced version of the sdk headers, so what nevcairiel mentioned is probably still relevant: is this reduced header actually available and supported somewhere, or just made for this patch?
[19:55:21 CEST] <BBB> the plan is based on a similar idea from jamrial
[19:55:32 CEST] <BBB> the firs tpart is mine, the second part is his
[19:55:37 CEST] <jamrial> what did i do now D:
[19:55:40 CEST] <BBB> nothing
[19:55:44 CEST] <BBB> you made a suggestion
[19:55:53 CEST] <BBB> Im not blaming, just attributing
[19:56:00 CEST] <jamrial> i know, just joking :p
[19:56:05 CEST] <michaelni> BBB, then lets remove the code that i use for maintaining mpegvideo
[19:56:12 CEST] <michaelni> if thats what you want
[19:56:15 CEST] <BBB> ok
[19:58:40 CEST] <nevcairiel> why is being deprecated such an absolute thing? we have plenty things that someone thought was a good idea to deprecate on a whim without having any plans for a replacement. Instead of blindly following some decision from 2 years ago, which we don't know the real thought-process of anymore (and perhaps wasnt even done in this project), maybe we should just judge it as it is today?
[19:59:06 CEST] <sfan5> jamrial: patches 5685-5687 do fix the seeking issue mpv experiences; "[ffmpeg] av_log callback called with bad parameters (NULL AVClass)." appears though, that should be fixed
[19:59:39 CEST] <michaelni> BBB, if you really want a plan, my plan would be to keep the code until someone moves it to a filter
[19:59:41 CEST] <JEEB> yea, I noted that on the ML if it's an API client's issue or in that patch
[19:59:51 CEST] <JEEB> sfan5: thanks for testing, so we now have two results which match :)
[19:59:53 CEST] <nevcairiel> and as the thigns are today, I haven't heard a single person actually mention a real technical reason to remove it, the code seems relatively innocent enough
[20:00:16 CEST] <nevcairiel> and since its actually in use..
[20:00:29 CEST] <jamrial> michaelni: the problem is that "until someone" tends to mean "never"
[20:01:31 CEST] <BBB> so&
[20:01:33 CEST] <BBB> attribute_deprecated uint32_t * 	mb_type
[20:01:45 CEST] <BBB> thats not a big deal?
[20:02:03 CEST] <BBB> I mean, I look at AVFrame and Im just dumbfounded
[20:02:12 CEST] <BBB> Im sure every little hack in there has a particular reason why it exists
[20:02:21 CEST] <BBB> but seriously, thats our expected quality?
[20:02:29 CEST] <nevcairiel> you work in multimedia, if such things dumbfoundle you, maybe you should switch =p
[20:02:51 CEST] <BBB> now now now thats not nice
[20:03:21 CEST] <michaelni> BBB, i want quality but this isnt exactly a quality issue. decoder vissualization code fits very well into the decoder
[20:03:39 CEST] <nevcairiel> in any case, removing code without replacement thats actually in use by our own developers is not something that should ever happen without good technical reasons beyond getting rid of one field in some struct
[20:04:04 CEST] <BBB> and I guess thats where I disagree :-/
[20:04:19 CEST] <nevcairiel> you know how to get rid of it, though
[20:04:28 CEST] <BBB> yeah, do nothing, bump major
[20:04:28 CEST] <nevcairiel> codecview is waiting for a patch!
[20:04:29 CEST] <nevcairiel> :D
[20:04:30 CEST] <BBB> and its gone
[20:04:35 CEST] <BBB> \o/
[20:05:01 CEST] <jamrial> well, technically that already happened, lol
[20:05:27 CEST] <nevcairiel> thats not really how it works anyway, half of the deprecation macros are assigned random numbers and on a bump they all need to be re-evaluated
[20:06:05 CEST] <BBB> ok, so lets not go crazy
[20:06:08 CEST] <BBB> where do we go from here
[20:06:15 CEST] <BBB> you know my pov, I know yours
[20:06:17 CEST] <jamrial> yes, the number is meaningless. what matters is how long have things been deprecated
[20:06:18 CEST] <BBB> whats next
[20:07:04 CEST] <BBB> from what youre saying, I can basically extrapolate that youd prefer to just get rid of the deprecation of that feature and its related symbols altogether
[20:07:05 CEST] <BBB> right?
[20:07:21 CEST] <BBB> I mean, you say bump but theres no condition attached to it, so we can (and will) do it again next time
[20:07:23 CEST] <BtbN> Deprecating something that's in active use, doesn't seem to have any serious issues and isn't in the way of anything seems a bit weird
[20:07:28 CEST] <BBB> so effectively thats an undeprecation
[20:07:32 CEST] <BBB> so you want to undeprecate?
[20:07:41 CEST] <BBB> BtbN: the active us is an overstatement
[20:07:45 CEST] <BtbN> I guess the deprecation was just merged from libav?
[20:07:50 CEST] <jamrial> maybe durandal_1707 can write the filter to replace this feature
[20:08:18 CEST] <BBB> BtbN: michaelni says he uses it once every blue moon to debug issues in mpegvideo; how often does that happen? can he do that in a release branch? or a personal branch? does it need to be upstream? etc
[20:08:28 CEST] <BBB> nobody else seems to use it
[20:08:39 CEST] <BBB> I understand and appreciate that linux is linus personal computer backup
[20:08:46 CEST] <BBB> is ffmpeg michaels personal computer backup?
[20:09:28 CEST] <BBB> thats not meant to be offensive, its just a question. what are the rules for undeprecating stuff? and deprecating stuff? if nobody uses a feature, can it go? what if only one person uses it but refuses to maintain it? what does maintain mean? etc.
[20:09:37 CEST] <BBB> if he submitted the code as-is now, would we permit it to go in?
[20:09:39 CEST] <BBB> etc.
[20:09:46 CEST] <jamrial> i agree with BBB that if it's rarely used and it's so cleanly separate from the main codebase (as the preprocessor wrappers show), it can be applied as needed in a local branch for debugging purposes
[20:12:51 CEST] <michaelni> The code is usefull to anyone debuging / analyzing mpegvideo videos, its really not my personal backup that is silly
[20:13:34 CEST] <michaelni> but ultimatly sure you can remove everything i use or wrote, not sure this will help the project
[20:13:57 CEST] <BBB> dont be dramatic
[20:14:14 CEST] <michaelni> it was not intended to be
[20:14:16 CEST] <BBB> ok
[20:14:24 CEST] <BBB> so do you want to undeprecate it?
[20:14:30 CEST] <BBB> that is a serious question
[20:14:39 CEST] <michaelni> yes id like to keep it 
[20:15:04 CEST] <ubitux> i think it's better to have it in a filter though
[20:15:35 CEST] <ubitux> in codecview filter to be more specific
[20:15:49 CEST] <michaelni> ubitux, i am happy if its moved to a filter, i would even do the work but i have kind of too much to do atm
[20:16:49 CEST] <ubitux> delaying the deprecation and setting up a reasonable removal deadline sounds sane to me
[20:16:49 CEST] <jamrial> can the public symbols be removed at least? keep the debug code in mpegvideo.c but removing all the defines from avcodec.h and options_table.h?
[20:17:27 CEST] <jamrial> maybe adding a private option to mpegvideo for this, until the filter is written
[20:18:57 CEST] <ubitux> makes sense to me
[20:19:26 CEST] <durandal_1707> wouldnt filter work demand new side data introduction? 
[20:19:33 CEST] <ubitux> yes
[20:21:33 CEST] <atomnuker> for the daala decoder I used the text inserting function from that IBM PC codec, I wouldn't mind if that was a filter and you could pipe codec side data from decoder/encoders to it
[20:21:54 CEST] <atomnuker> but an analyzer is more useful
[20:27:24 CEST] <durandal_1707> this is literally 15 min of work
[20:29:51 CEST] <atomnuker> for an analyzer? more than that
[20:35:38 CEST] <durandal_1707> for vis mb type
[20:36:13 CEST] <durandal_1707> and its already removed/disabled
[20:36:49 CEST] <nevcairiel> in a perfect world it would be made more flexible then assuming 16x16 mbs, so it can support varying mb sizes for modern codecs, but thats probably outside of the scope for a simple port
[20:37:31 CEST] <jamrial> durandal_1707: if you can write the port into a filter then by all means please do it, so the mpegvideo code doesn't need to be re-enabled
[20:38:10 CEST] <BBB> my opinion here is that a permanent undeprecation is just not in the best interest of the project; either we get rid of it now, or itll be around forever& thats probably all I should say at this moment, I think weve discussed this ad nauseam and each side knows the others position &
[20:39:38 CEST] <jamrial> BBB: yes, nobody is in favor of permanent undeprecation. at most postponing the non public parts (the public bits can remain removed)
[20:39:53 CEST] <BBB> michaelni just said hes in favour of permanent undeprecation
[20:40:10 CEST] <BBB> <BBB> so do you want to undeprecate it?
[20:40:10 CEST] <BBB> <BBB> that is a serious question
[20:40:11 CEST] <BBB> <michaelni> yes id like to keep it
[20:40:12 CEST] <nevcairiel> he wants to keep the feature
[20:40:23 CEST] <nevcairiel> he also said he would be happy with a proper replacement
[20:40:28 CEST] <BBB> I didnt ask to keep, I asked to undeprecate; he said "yes"
[20:40:46 CEST] <jamrial> and i was essentially talking about others in the discussion. you, me, ubitux, etc
[20:40:52 CEST] <nevcairiel> lets not try to split hairs over an imprecise communication medium
[20:40:59 CEST] <BBB> right but were now in the ad nauseam position that everyone likes a replacement but nobody wants to write one
[20:41:12 CEST] <BBB> well, anyway, you know my position ;)
[20:42:46 CEST] <JEEB> jamrial: ok, nicolas explained the things and it all makes sense (in addition to seemingly working \o/)
[20:57:49 CEST] <durandal_1707> i will write this, but who will pay me my time?
[21:00:31 CEST] <iive> what's the problem with keeping it, as it is?
[21:02:22 CEST] <durandal_1707> its easy to say fuck off
[21:02:45 CEST] <jamrial> symbols, no reusability, the like
[21:02:59 CEST] <jamrial> plus it's a testament of how things are never done if there's no set goal
[21:04:00 CEST] <JEEB> jamrial: feel to do the honors to the EOF fixup if it looks good to you, it seems to work according to a sample set of 2 and it seems to kind of follow precedent logic. I will be finally taking some food >_>
[21:04:05 CEST] <JEEB> *feel free
[21:04:18 CEST] <JEEB> (I LGTM'd the patch set since it WorksForMe)
[21:05:06 CEST] <jamrial> JEEB: i can't test it, so if it works and you lgtm'd it then nicolas, you or anyone else can push it
[21:05:23 CEST] <JEEB> ok
[21:05:36 CEST] <JEEB> anyways, if it isn't pushed after I finish my meal I can do it :)
[21:09:14 CEST] <jamrial> thanks
[22:30:16 CEST] <BBB> durandal_1707: the mb_type is obviously part of the problem, maybe we can declare that part of the side-data api interface unstable so it can be developed further?
[22:30:46 CEST] <BBB> (because as much as you dont export the macros like is8x8 into the header, the meaning becomes an implied part of the abi)
[22:31:01 CEST] <BBB> we can also say its codec specific in which case it can be anything
[22:32:40 CEST] <durandal_1707> this stuff is for mpeg2video only iirc
[22:33:37 CEST] <BBB> how do we signal that the mbtype format in the side-data is mpeg2?
[22:33:39 CEST] <BBB> do we want to?
[22:33:42 CEST] <BBB> do we allow others?
[22:33:46 CEST] <BBB> am I being a prick?
[22:35:05 CEST] <durandal_1707> yes, its awfull
[22:37:08 CEST] <adityabm77> Hey guys! I'm new here. I would like to contribute to ffmpeg. I'm good at C and C++. How should I start?
[22:38:31 CEST] <durandal_1707> adityabm77: start by picking something you know about and work on it, just explore code
[22:38:40 CEST] <JEEB> build FFmpeg with the basic configuration, then see some fault of it (lack of feature or a bug) and start hacking on it :)
[22:39:18 CEST] <JEEB> maybe see how the API works with some basic app if you are interested in seeing how the external APIs work
[22:41:19 CEST] <BBB> durandal_1707: do you agree its probably a good idea to make it explicit in the api of the side-data for block types that the interpretation of block type is codec-agnostic and will change over time?
[22:42:52 CEST] <durandal_1707> is it agnostic?
[22:44:45 CEST] <durandal_1707> it may be in future, but currently its mpeg2video
[23:16:34 CEST] <cone-137> ffmpeg 03Anton Khirnov 07master:50a1c66cf6ab: ac3_parser: add a public function for parsing the data required by the demuxer
[23:16:34 CEST] <cone-137> ffmpeg 03James Almer 07master:e0250cf3651e: Merge commit '50a1c66cf6ab7eb683daaa9e2da3869fa3a54609'
[23:17:00 CEST] <jamrial> ^an acceptable compromise, i guess
[23:17:08 CEST] <jamrial> still open to suggestions about AC3HeaderInfo usage in movenc
[23:25:27 CEST] <cone-137> ffmpeg 03Alexandra Hájková 07master:89d9869d2491: hevc: Add NEON 16x16 IDCT
[23:25:28 CEST] <cone-137> ffmpeg 03James Almer 07master:9840ca70e75d: Merge commit '89d9869d2491d4209d707a8e7f29c58227ae5a4e'
[23:27:46 CEST] <JEEB> jamrial: will be pushing the EOF stuff since I see no NACK's for it
[23:28:16 CEST] <jamrial> JEEB: maybe give nicolas a bit. it's his patchset after all
[23:28:23 CEST] <JEEB> sure
[23:29:39 CEST] <JEEB> then I will probably next look at these things towards end of Sunday, have to do a trip to the family in a less networked place tomorrow :)
[00:00:00 CEST] --- Sat Oct 28 2017