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

[burek]

[11:39:23 CEST] <jdarnley> For the draw_horiz_band callback, is there some pointer somewhere in ffmpeg's man structs I can put my state in?
[11:39:29 CEST] <jdarnley> I will need to have a way to do something with the data in the callback.
[11:41:50 CEST] <jdarnley> What's the term usually used for this thing?  "opaque"?
[11:46:29 CEST] <jdarnley> I think I want to use AVCodecContext.opaque for that
[11:47:41 CEST] <nevcairiel> dont you have a codec context for that
[11:48:20 CEST] <nevcairiel> opaque is not interpreted by avcodec ever
[11:48:29 CEST] <nevcairiel> unless thats what you want and i misunderstood
[11:55:46 CEST] <jdarnley> Ah, maybe you do.  I don't mean for the decoder, I mean for the user of the library.
[11:56:19 CEST] <nevcairiel> thats indeed what opaque is for
[11:56:21 CEST] <jdarnley> But then I wasn't very clear.
[11:57:02 CEST] <jdarnley> Anyway it turns out that we already use opaque for exactly what I wanted to use it for.
[13:43:47 CEST] <cone-010> ffmpeg 03Marton Balint 07master:b181cd359b87: ffmpeg: factorize input thread creation and destruction
[13:43:48 CEST] <cone-010> ffmpeg 03Marton Balint 07master:da36bcbeb78c: ffmpeg: fix -stream_loop with multiple inputs
[13:43:49 CEST] <cone-010> ffmpeg 03Marton Balint 07master:06a8d7ff00f5: avformat/apngdec: set pts to AV_NOPTS_VALUE
[13:54:26 CEST] <atomnuker> wow, an apng decoder commit
[13:56:19 CEST] <atomnuker> *demuxer
[14:06:29 CEST] <cone-010> ffmpeg 03Michael Niedermayer 07master:d24c9e55f64e: avcodec/dvdsubdec: Check for fully transparent rectangles earlier
[15:41:05 CEST] <BtbN> Is trac down?
[15:42:09 CEST] <nevcairiel> apparently
[18:46:39 CEST] <cone-630> ffmpeg 03Sergey Lavrushkin 07master:575b7189908e: Adds ESPCN super resolution filter merged with SRCNN filter.
[18:46:40 CEST] <cone-630> ffmpeg 03Pedro Arthur 07master:54b425a7fad3: libavfilter: vf_sr.c remove warnings
[18:56:29 CEST] <j-b>  libavfilter/dnn_espcn.h          | 12637 +++++++++++++++++++++++++++++++++++++
[18:56:33 CEST] <j-b> Where is the source?
[18:56:50 CEST] <JEEB> I think that was brought up at least once :D
[18:57:34 CEST] <j-b> by me
[18:57:36 CEST] <j-b> of course
[18:57:52 CEST] <j-b> This is a huge blob of an array, that we don't know how it was generated.
[18:58:02 CEST] <JEEB> yup
[18:58:23 CEST] <j-b> If it was a trained NN, where is the training data?
[18:58:26 CEST] <j-b> How do we reproduce?
[18:58:45 CEST] <nevcairiel> ask the  author, not us =p
[18:59:26 CEST] <j-b> well, it shouldn't be merged.
[18:59:51 CEST] <nevcairiel> maybe that information is readily available and you just didnt see it
[19:03:42 CEST] <j-b> sure. But I kind of doubt it.
[19:06:12 CEST] <j-b> Seriously, I don't think tensorflow code should be inside libavfilter.
[19:06:25 CEST] <j-b> but that's just my opinion.
[19:39:51 CEST] <atomnuker> neural network libs are usually a huge pain to get going, and they usually only work on proprietary crap
[19:46:48 CEST] <jamrial> jkqxz: ping
[19:51:42 CEST] <j-b> and of course, apache2
[19:55:53 CEST] <jamrial> j-b: does this mean the filter should be gpl3? lgpl3?
[19:56:03 CEST] <j-b> jamrial: well, LGPLv3 is a minimum
[19:56:16 CEST] <j-b> but sorry, this filter should not be in FFmpeg at all.
[19:56:31 CEST] <j-b> It is based on some research papers and codes that are not open source at all.
[19:56:56 CEST] <j-b> It is based on NN where the data and training models are not available/documented
[19:57:14 CEST] <j-b> Sure, NN are fun, but come on.
[19:57:48 CEST] <thardin> there may also be patent treachery sfoot
[19:57:52 CEST] <thardin> afoot
[19:58:22 CEST] <j-b> Especially for filters that are easy to add externally.
[19:58:47 CEST] <atomnuker> welp, we do have support for nnedi, though its weights need to be specified as an external file
[20:02:18 CEST] <j-b> I mean, there are 1million cool filters out there. Do all deserve to be 1st party?
[20:47:38 CEST] <jkqxz> jamrial:  Pong.
[21:05:58 CEST] <jamrial> jkqxz: https://github.com/jamrial/FFmpeg/commits/av1_parse
[21:06:04 CEST] <jamrial> it's fine if you'd rather keep everything contained within your cbs code instead of using that split code (afaik cbs_av1 should have zero copy for read usage)
[21:06:27 CEST] <jamrial> but i figured you'd find the extract_extradata implementation useful
[21:12:30 CEST] <atomnuker> btw here's a horrifying thought TD-Linux told me of: if av1 hadn't gone for its custom OBUs but for H264 style NALS h2645 parse would have had to be modified to support av1
[21:12:47 CEST] <atomnuker> h26451?
[21:13:18 CEST] <kierank> nal_parse
[21:14:16 CEST] <jamrial> i essentially used h2645_parse to write that av1_parse code
[21:18:19 CEST] <atomnuker> y-yeah, it was a struggle getting it to be different
[21:29:52 CEST] <atomnuker> (btw you can blame TD-Linux for having them being called OBUs)
[21:30:08 CEST] <atomnuker> or thank him, whichever
[21:41:56 CEST] <jkqxz> Yeah, I think I'd prefer to keep that code in cbs-land so that it's all safe and traceable.
[21:42:18 CEST] <jkqxz> I should get back to that stuff at some point.  And write av1_metadata.
[21:43:13 CEST] <jamrial> jkqxz: extract_extradata will need to be written using cbs_av1 then
[21:43:31 CEST] <jamrial> for containers like ivf and annex-b
[21:59:50 CEST] <jamrial> we'll probably have to adapt the libaom wrapper somehow until a native decoder lands, since mp4/matroska may not have sequence header or temporal delimiter obus within packets
[22:14:38 CEST] <durandal_1707> j-b: well you do not use lavfi, so why should you care at all?
[22:15:06 CEST] <j-b> durandal_1707: why do I care about the license?
[22:16:23 CEST] <durandal_1707> set of numbers have license now?
[22:16:53 CEST] <j-b> random numbers taken out of nowhere are usually considered as non-open-source, yes
[22:17:01 CEST] <j-b> remove from most linux distributions
[22:17:19 CEST] <j-b> especially if they are not random
[22:19:10 CEST] <durandal_1707> please then remove all my code from FFmpeg!
[22:20:15 CEST] <j-b> That escalated quickly.
[22:36:47 CEST] <TD-Linux> I originally suggested not calling them NALs because I thought it would be confusing if we had something called NALs that were incompatible with h264 NALs
[22:41:44 CEST] <gnafu> j-b: I'm not even sure you could say that escalated :-P.
[22:43:28 CEST] <BradleyS> clearly a neural network should determine the probability and extent of escalation
[22:46:13 CEST] <atomnuker> that article about using neural networks to do nanosecond time precision synchronization was ridiculous
[22:46:15 CEST] <January> BradleyS: but where would you get weights under an acceptable license if weights cant be licensed?
[22:46:50 CEST] <January> atomnuker: imagine not using hardware to do nanosecond synchronisation
[22:49:04 CEST] <BradleyS> 27276399 9592726 93874810 63990 626728281
[22:49:20 CEST] <BradleyS> libre
[22:49:52 CEST] <j-b> gnafu: sorry, I did not think that would be controversial to ask for the source of such a big array of numbers
[22:50:31 CEST] <JEEB> it really isn't
[22:50:46 CEST] <BradleyS> 73728 16638 294937 <- pay up for those ones though
[22:51:04 CEST] <j-b> reductio ad absurdi.
[22:51:04 CEST] <BradleyS> (it isn't)
[22:51:05 CEST] <JEEB> and we already have one example where the weights were not put into lavfi, nnedi3
[22:51:12 CEST] <jamrial> durandal_1707 was just being himself
[22:51:16 CEST] <JEEB> yes
[22:51:26 CEST] <j-b> for nnedi, this was done on purpose
[22:51:39 CEST] <JEEB> yes, of course
[22:51:40 CEST] <j-b> (IIRC)
[22:51:47 CEST] Action: BradleyS removes cone hat
[22:51:56 CEST] <BradleyS> does that satisfy? :D
[22:51:59 CEST] <j-b> lol
[22:52:24 CEST] <j-b> BradleyS: don't shoot the messenger
[22:52:35 CEST] <j-b> I know what distributions et al. will say
[22:54:32 CEST] <gnafu> j-b: I'm with you.  I was saying I felt like their reaction was so sudden that it didn't really escalate.  It just spontaneously combusted.
[22:57:10 CEST] <j-b> JEEB: I feel that this will come more and more often for NN-data.
[22:57:39 CEST] <gnafu> It seems like a wild new frontier, sorta lawless and untamed.
[22:57:55 CEST] <gnafu> Which I suppose just means it needs to be trained with more data ;-).
[22:58:05 CEST] <BradleyS> i assume the nnedi3 data is large
[22:58:16 CEST] <j-b> atomnuker: any way of following your FFv2 progress?
[22:58:30 CEST] <BradleyS> hence the externalization, but perhaps that is a good practice in general
[22:59:07 CEST] <j-b> well, I'd prefer a simple way to retrain with different data-set
[23:00:13 CEST] <BradleyS> yes, the proof is better than the product
[23:00:40 CEST] <BradleyS> at least where the former cannot be gleaned from the latter easily
[23:01:20 CEST] <gnafu> Reproducibility seems like a good thing to want.
[23:01:41 CEST] <JEEB> yup
[23:02:12 CEST] <j-b> We had the same issue, in the past, in VLC, where a lot of artwork was bitmaps, without the "true" source
[23:02:34 CEST] <j-b> and of course, as soon as the guy who did the bitmaps went away, they are un-modifiable.
[23:02:49 CEST] <j-b> So now, we mandate SVG
[23:03:28 CEST] <j-b> Which are the vector model used in the editing soft
[23:03:32 CEST] <s55> That sounds like a familiar problem  the HandBrake logo is still a single layer PSD :(
[23:03:34 CEST] <BradleyS> handbrake's current icon/logo is only available as high res bitmap due to the original contributor not providing and then losing the vector
[23:03:38 CEST] <BradleyS> jinx
[23:04:33 CEST] <atomnuker> j-b: well I got a gh repo branch https://github.com/atomnuker/FFmpeg/tree/exp_ffv2_daala but I tweet if I've done something I think is interesting
[23:42:31 CEST] <j-b> cool.
[00:00:00 CEST] --- Tue Jul  3 2018