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

[burek]

[01:55:03 CET] <Chloe> michaelni: are you sure that frei0r_src is in filter_list.c?
[01:55:43 CET] <michaelni> Chloe, maybe its not but it works before the patch and not after it
[01:56:52 CET] <Chloe> michaelni: ok, let me install frei0r and check if it works
[02:09:06 CET] <Chloe> michaelni: seems like frei0r_src isnt ending up in filter_list for some reason
[02:09:29 CET] <michaelni> that explains why it didnt work
[02:09:59 CET] <Chloe> michaelni: ah, I see why. Do you think think a patch to rename frei0r_src to frei0rsrc (like literally every other filter) would be accepted
[02:10:22 CET] <Chloe> actually dont worry
[02:10:43 CET] <Chloe> I'll just fix the grep, looks like there are other cases (it was a silly suggestion anywya)
[02:12:02 CET] <cone-476> ffmpeg 03James Almer 07master:f5ceb15bb692: ffmpeg: remove dead call to av_parser_change()
[02:12:02 CET] <cone-476> ffmpeg 03James Almer 07master:231a73308f18: ffmpeg: pass reference counted packet on codec copy when possible
[02:12:02 CET] <cone-476> ffmpeg 03James Almer 07master:ed1f08bfb550: avcodec/bsf: make sure the AVBSFInternal stored packet is reference counted
[02:25:24 CET] <Chloe> michaelni: '[Parsed_frei0r_src_0 @ 0x7fddd2c00540] Could not find module 'partik0l'.' perfect, I'll send an updated patch
[02:29:28 CET] <cone-476> ffmpeg 03James Almer 07master:dc99ee6b08e5: avcodec/noise_bsf: move the reference in the bsf internal buffer
[02:31:00 CET] <Chloe> michaelni: it was actually that the grep didnt search for '_' so any filter with an underscore wasnt built. frei0r_src just happens to be the only src filter with an underscore
[03:13:07 CET] <cone-476> ffmpeg 03Sasi Inguva 07master:829aebf95d44: lavf/utils.c: Don't compute start_time from DISCARD packets for video.
[03:13:08 CET] <cone-476> ffmpeg 03Jacob Trimble 07master:db2a7c947ec2: avcodec/avcodec.h: Add encryption info side data.
[13:39:57 CET] <wm4> is FF_SUB_CHARENC_MODE_AUTOMATIC a public symbol or not
[13:40:00 CET] <wm4> I can't fucking tell
[13:41:22 CET] <nevcairiel> its in a public header right there as the definition of a public field, so clearly yes?
[13:44:16 CET] <wm4> FF_ is for private symbols (although a lot of macros are "exceptions"), and the field that's used with it says "decoding: set by libavcodec" which might indicate you're supposed to use AVOption instead (???)
[13:45:12 CET] <nevcairiel> it being set by avcodec doesnt really change anything for the constants, as you may still want to read it
[13:46:09 CET] <wm4> you could probably argue this way, though things still don't make a lot of sense
[13:46:32 CET] <nevcairiel> it is only set by avcodec itself though, dont think you ever need to touch it as a user
[13:46:48 CET] <wm4> I plan to set it as user
[13:46:51 CET] <wm4> fuck the police
[13:47:27 CET] <nevcairiel> you shoulds et sub_charenc to indicate the encoding, the mode is always pre_decoder anyway because nothing ever overrides that (although it could)
[13:47:57 CET] <nevcairiel> if you just dont set sub_charenc at all, the mode is ignored, so not sure why you would ever set that mode field to anything
[13:48:10 CET] <wm4> I think the plan was to add post-decoding conversion for formats which are binary
[13:48:29 CET] <nevcairiel> that clearly didnt happen, or at least that field is not involved
[13:48:32 CET] <wm4> see my patch I just sent
[13:48:37 CET] <wm4> no it didn't happen
[13:49:11 CET] <wm4> now I have a sample for which movtext outpuits invalid utf-8, so the decode.c code drops it
[13:49:21 CET] <wm4> probably a movtext bug
[13:49:27 CET] <wm4> but still very irritating
[13:56:27 CET] <omerjerk> Can anyone explain to me how we write multithreaded codecs?
[13:56:53 CET] <omerjerk> I know it's slightly vague but I have no idea how else to ask this. 
[13:57:12 CET] <omerjerk> What data exactly do we keep in the threadlocal data structure? 
[14:00:01 CET] <wm4> well with the frame threading infrastructure, normally each worker thread will decode a frame separately
[14:00:27 CET] <wm4> so for an intra-only decoder it'd probably be trivial
[14:00:47 CET] <wm4> while other types of codecs need some more synchronization and state updates around it
[14:00:56 CET] <omerjerk> okay.
[14:14:53 CET] <kierank> gagandeep_: do you have a clean patch for the chroma plane stuff
[14:21:39 CET] <sidharth_arya> Hi, i use ffmpeg for basic file conversions. and i am interested in working with ffmpeg via gsoc. Can someone please guide me through requirements for getting started?
[14:23:52 CET] <omerjerk> sidharth_arya: Did you go through this link? - http://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2018
[14:25:33 CET] <sidharth_arya> Yes i did. I can code in C. But the question is which library in C? I am not familiar with any audio related libraries in C currently
[14:26:02 CET] <Chloe> sidharth_arya: all the libraries are in c
[14:26:42 CET] <sidharth_arya> Okay. So should i be studying something more before actually crafting a proposal?
[14:27:17 CET] <sidharth_arya> because i don't know where to begin...
[14:27:23 CET] <Chloe> study what? If none of the projects on the page interest you then just think of something else
[14:28:23 CET] <sidharth_arya> Okkay thanks Chloe
[14:37:01 CET] <omerjerk> Don't draft a proposal without showing that you can actually work on FFmpeg. Proposal will just get rejected.
[14:55:13 CET] <Chloe> sidharth_arya: yes youll need to be able to show that you are able to do your proposal too
[14:57:03 CET] <sidharth_arya> Hey thanks. By the way to show that i ll be able to do my proposals
[14:57:30 CET] <sidharth_arya> do i have to attach initial source codes or the method i would take?
[14:58:33 CET] <Chloe> Something like a proof of concept/prototype, or a finished component of your proposal. You would send it as a patch to the mailing list
[14:59:27 CET] <sidharth_arya> Okkay got it.
[14:59:33 CET] <Chloe> sidharth_arya: you may find it more beneficial to talk about what youre thinking about doing here before you even start though
[14:59:47 CET] <Chloe> Since some things will likely just get rejected outright
[15:00:12 CET] <Chloe> Better to only draft up a full proposal if you know it has somewhat of a chance
[15:03:05 CET] <sidharth_arya> Okkay so is it possible to convert web based content in ffmpeg?
[15:04:21 CET] <Chloe> sidharth_arya: what do you mean by this?
[15:06:30 CET] <sidharth_arya> i mean like converting svg animations to mp4?
[15:07:14 CET] <sidharth_arya> it may be possible if we specify a particular size
[15:07:26 CET] <sidharth_arya> i believe. what do you think?
[15:09:52 CET] <Chloe> sidharth_arya: see the  librsvg demuxer
[15:11:06 CET] <sidharth_arya> but librsvg is for rastor images 
[15:11:28 CET] <sidharth_arya> i am not aware if it parses dynamic svgs
[15:14:58 CET] <sidharth_arya> Thank this seems helpful
[15:15:16 CET] <sidharth_arya> *thanks
[15:19:19 CET] <cone-750> ffmpeg 03James Almer 07master:823362782c4b: Revert "avcodec/vp9_superframe_bsf: cache packets by creating new references rather than moving them"
[15:40:31 CET] <atomnuker> those require javascript and that won't fly here
[15:50:58 CET] <kierank> atomnuker: ffjs
[15:50:59 CET] <kierank> duh
[15:51:29 CET] <RiCON> kierank: after ffxml
[15:51:38 CET] <wm4> where's ffxml anyway
[15:52:24 CET] <durandal_1707> where is ffav1 ?
[15:52:44 CET] <jamrial> wm4: libxml2 is already used in some muxer or such
[15:54:01 CET] <RiCON> dashdec*
[15:54:17 CET] <wm4> yes
[15:55:25 CET] <JEEB> I just got e-mailed yesterday about adding dashdec FATE tests
[15:55:31 CET] <JEEB> poor guy seems to be completely out there
[15:56:59 CET] <sidharth_arya> atomnuker ... what if i pass it into webkit?
[15:57:40 CET] <sidharth_arya> javascript events won't work , like click hover etc. but plain and simple animations might...
[15:57:57 CET] <Chloe> sidharth_arya: absolutely no way webkit is linked with ffmpeg in any way
[15:58:20 CET] <wm4> I had this idea for april 1st to make a httml demuxer
[15:58:23 CET] <wm4> *html
[15:58:35 CET] <wm4> it'd use webkit to render the page to an AVFrame
[15:58:45 CET] <sidharth_arya> yup exactly
[15:58:57 CET] <Chloe> except I dont think sidharth_arya is joking
[15:59:12 CET] <wm4> and it's not much more weird than using libsvg
[15:59:24 CET] <wm4> well librsvg
[15:59:33 CET] <wm4> webkit is just a bit bigger
[15:59:59 CET] <Chloe> *a bit*
[16:01:38 CET] <sidharth_arya> Something will be required to get css and js parsed right?
[16:02:13 CET] <wm4> maybe we should just turn ffmpeg into an electron app (we could use emscripten to convert the legacy C code)
[16:02:34 CET] <wm4> JS is also more secure than C, so this has only advantages
[16:03:07 CET] <Chloe> we could also make use of the superior object-orientation features in JS
[16:03:15 CET] <JEEB> sidharth_arya: CSS was added to VLC
[16:03:15 CET] <JEEB> lol
[16:04:04 CET] <wm4> oh if they did that, some light CSS support for webvtt would be realistic
[16:04:35 CET] <JEEB> CSSLexer.c
[16:04:43 CET] <JEEB> so yes, they aded CSS parsing for shits and giggles :P
[16:06:04 CET] <wm4> so that means j-b can't bully us anymore for it if we add css support to ffmpeg
[16:06:29 CET] <JEEB> and they even generate that C file with a lexer :P
[16:06:34 CET] <Chloe> atomnuker: meson status?
[16:07:05 CET] <wm4> JEEB: from what?
[16:07:41 CET] <JEEB> I don't remember what, I just remember the wrapper for that tool defaulting to the yes binary or something so even when you were missing the tool it would only error out when something tried to compile that .c file
[16:07:45 CET] <JEEB> lol
[16:07:48 CET] <JEEB> someone just hit that on #videolan last night
[16:12:59 CET] <Chloe> sidharth_arya: anyway, I don't recommend you submit that as a serious proposal
[16:18:29 CET] <sidharth_arya> I figured, given the response :P
[16:18:56 CET] <atomnuker> durandal_1707: actually I'm writing it
[16:19:12 CET] <atomnuker> well, I'm starting it
[16:19:47 CET] <atomnuker> Chloe: same as it ever was, need to write a script to make meson output config.asm
[16:20:02 CET] <Chloe> ah right
[16:22:10 CET] <atomnuker> wm4: librsvg isn't _that_ bad, the only difference between it and a proper codec is that its bitstream is fucked up utf8 for some odd reason
[16:25:00 CET] <wm4> I see atomnuker learned ABSTRACTION
[16:27:13 CET] <JEEB> atomnuker: do you have a list or dict of the defines btw? I would guess one could make a python function to dump that into a file
[16:55:01 CET] <atomnuker> yes, config.h
[16:55:17 CET] <atomnuker> but I'd rather have it done properly and have it be generated from meson.build
[16:55:29 CET] <atomnuker> where each define is KEY=VALUE stor'd
[16:55:38 CET] <JEEB> yeh
[16:55:44 CET] <JEEB> can't you extend that with a function?
[16:56:07 CET] <atomnuker> I think so, I'd have to ask meson, but if you're willing to do it go ahead
[16:56:24 CET] <atomnuker> either that or NIH part of the config output writer
[16:57:36 CET] <JEEB> well I just didn't know in the context of meson. it just seemed like python so "it's just a thing you could do in a function" sounded doable
[16:57:50 CET] <JEEB> of course we're probably not the only project that wants .asm key=VALUE defines
[17:46:39 CET] <wm4> anyone can ok the subcharenc patch? maybe ubitux 
[17:47:00 CET] <durandal_1707> ubitux is very busy iirc
[17:53:20 CET] <atomnuker> haven't seen him around in a while
[17:59:47 CET] <wm4> true
[18:01:41 CET] <Chloe> atomnuker: I think we can just add the functionality for custom config formats to meson itself
[18:06:19 CET] <atomnuker> cool
[20:05:08 CET] <atomnuker> "Hello sir,"
[20:05:24 CET] <atomnuker> I've missed this tbh
[20:12:45 CET] <kierank> atomnuker: send me the codes?
[20:12:57 CET] <durandal_1707> of what?
[20:13:53 CET] <atomnuker> what codes?
[20:17:36 CET] <kierank> atomnuker: i was making a joke about "Hello Sir"
[20:17:39 CET] <kierank> please send me the codes
[20:19:34 CET] <JEEB> please do the needful
[20:22:06 CET] <atomnuker> never had that follow "hello sir"
[20:25:10 CET] <cone-158> ffmpeg 03Martin Vignali 07master:923a324174c2: swscale/rgb : add X86 SIMD (SSSE3) for shuffle_bytes_2103 and shuffle_bytes_0321
[20:25:10 CET] <cone-158> ffmpeg 03Martin Vignali 07master:d4f6640855fa: swscale/rgb : move shuffle func shuffle_bytes_1230, shuffle_bytes_3012, shuffle_bytes_3210 in order to add SIMD
[20:25:10 CET] <cone-158> ffmpeg 03Martin Vignali 07master:1ba5ca2d721e: swscale/rgb : add X86 SIMD (SSSE3), for shuffle_bytes_1230, shuffle_bytes_3012, shuffle_bytes_3210
[20:25:10 CET] <cone-158> ffmpeg 03Martin Vignali 07master:a9a7ed4f27d0: checkasm/swscale : add test for rgb shuffle_bytes func
[20:25:10 CET] <cone-158> ffmpeg 03Martin Vignali 07master:5f6126ea7f31: swscale/rgb2rgb : cosmetic, move shuffle_bytes func declaration
[21:33:49 CET] <atomnuker> jkqxz: is scale_vaapi a noop if all parameters are the same as the source?
[21:36:15 CET] <Chloe> michaelni: do the other programs loop infinitely too?
[21:37:22 CET] <michaelni> Chloe, I think not but iam not 100% i tried 
[21:37:50 CET] <Chloe> michaelni: weird that you'd only find it in ffplay but I will look into it
[21:47:29 CET] <Chloe> michaelni: ah so it's an issue with filter_list.c, it's getting put in twice. It's a ./configure script issue
[21:50:51 CET] <Chloe> this is actually kinda difficult, as there are multiple filters with the same 'name' but different types
[21:51:19 CET] <Chloe> i.e. ff_asrc_abuffer and ff_asink_abuffer are regarded as the same filter because configure drops the 'type'
[21:53:11 CET] <jamrial> wm4: re packet reference counting api, any name you want for the function?
[21:55:18 CET] <Chloe> So a way around this would be to make the 'always built' filters in allfilters.c just not match the regex and then hardcode them in configure (pretty much what was happening before
[22:05:22 CET] <cone-158> ffmpeg 03Marton Balint 07master:87455b78cc51: avdevice/decklink: fix leak when listing devices and there is no memory
[22:25:47 CET] <atomnuker> now that I've seen the libshaderc API I completely understand why we use CamelCase for structs
[22:26:20 CET] <atomnuker> https://github.com/google/shaderc/blob/master/libshaderc/include/shaderc/shaderc.h
[22:26:53 CET] <atomnuker> look at this thing, super long names for everything and you don't know what's an enum, a function or a struct
[22:27:24 CET] <nevcairiel> its not like the second thing is a thing for us, at least not for structs or enums
[22:33:57 CET] <atomnuker> well no, our enums are all caps
[22:34:08 CET] <atomnuker> so you can definitely tell the 3 apart
[22:40:21 CET] <Chloe> apparently writing grep is super hard, but shoudl all be fixed now
[22:40:22 CET] <wm4> jamrial: which one?
[22:40:56 CET] <jamrial> the one to make a packet ref counted if it's not already you mentioned
[22:41:14 CET] <jamrial> a direct and saner replacement for av_dup_packet
[22:45:40 CET] <wm4> so just the name? maybe just av_packet_ensure_refcounted? seems a bit long though
[22:46:25 CET] <jamrial> yeah, too long
[22:47:13 CET] <Chloe> wm4: just drop the _ensure?
[22:47:38 CET] <jamrial> Chloe: too close to av_packet_ref() and will confuse people
[22:48:00 CET] <Chloe> I guess av_packet_ensure_ref() is also too long
[22:49:53 CET] <jamrial> wm4: and yes, name mostly, but if you have implementation suggestions, like returning 0 if !pkt->data as av_dup_packet() does or EINVAL as av_packet_make_writable() does, that's also welcome
[22:50:32 CET] <jamrial> not sure which is saner. probably the latter
[22:53:52 CET] <wm4> av_packet_ref also returns an error code
[22:53:56 CET] <wm4> so probably that
[00:00:00 CET] --- Sun Mar 25 2018