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

[burek]

[00:05:33 CEST] <gh0st__> Huh, is that serious, the korean missile launch?
[00:06:41 CEST] <nevcairiel> serious as in it happened? yes, apparently. serious as in will it have consequences? We shall see.
[00:08:21 CEST] <gh0st__> nevcairiel: I am a little terrified now.
[00:09:05 CEST] <nevcairiel> i'm just somewhat happy to live outside of their range
[00:09:37 CEST] <kierank> i am happy we have an independent nuclear deterrent
[00:10:14 CEST] <gh0st__> I live in siberia and I am not sure if that is outside of their range, probably not.
[00:10:30 CEST] <kierank> wow siberia
[00:10:33 CEST] <nevcairiel> as if deterrents stop people like NK
[00:10:48 CEST] <gh0st__> yep
[00:13:38 CEST] <gh0st__> Well, our television is not broadcasting about the north korean missile launches.
[00:16:46 CEST] <gh0st__> I am thinking that if north korea launched nuclear missiles, consequences shall see all of the world.
[00:17:32 CEST] <nevcairiel> it was probably another test without a warhead
[00:17:49 CEST] <nevcairiel> but still quite taunting to have it fly over japan
[00:21:37 CEST] <BBB> as for swr vs. avr, swr is faster (I wrote the assembly for the pieces that I know to be faster)
[00:22:17 CEST] <BBB> I agree that the lack of public review for large components like that is troubling, and a mere manifestation of a much bigger problem
[00:24:56 CEST] <atomnuker> all patches to swr I've seen in my time have been on the ML
[00:25:18 CEST] <jamrial_> he's talking about how it landed
[00:25:35 CEST] <jamrial_> every api change after the first commit made it to the ml
[00:25:48 CEST] <jamrial_> it's old history anyway
[00:25:53 CEST] <BBB> thats true
[00:26:25 CEST] <BBB> anyway, I dont care about swr, it works for stuff I need it to do, I wrote some simd for it, I believe its significantly faster than avr for the same tasks
[00:26:29 CEST] <BBB> so & next?
[00:26:48 CEST] <BBB> I would mind more if it were video-related, where I have actual opinions about how it should work because I know something about it :-p
[00:27:14 CEST] <nevcairiel> you should write us a new sws!
[00:27:34 CEST] <kierank> I still need to get my field caption patch in
[00:27:39 CEST] <kierank> maybe we can discuss at vdd
[00:28:03 CEST] <gh0st__> What's sws?
[00:28:16 CEST] <nevcairiel> swscale
[00:29:14 CEST] <gh0st__> thanks!
[00:33:42 CEST] <gh0st__> Also, vdd is a conference where all the guru of multimedia technologies gather to discuss the vector of the development of new technologies in multimedia?
[00:34:22 CEST] <kierank> videolan.org/videolan/events/vdd17/
[00:37:03 CEST] <Compn> gh0st__ : open source multimedia projects gather to discuss
[00:37:37 CEST] <atomnuker> still no schedule, wiki page for it was deleted 3 weeks ago :/
[00:37:48 CEST] <gh0st__> Wow, this is interesting.
[00:38:35 CEST] <kierank> atomnuker: it's august in frane
[00:38:42 CEST] <kierank> france
[00:39:50 CEST] <atomnuker> yeah, they should enjoy it
[00:40:09 CEST] <gh0st__> What do usually open source multimedia projects discuss?
[00:40:28 CEST] <atomnuker> codecs
[00:40:46 CEST] <atomnuker> though its mostly containers and streams outside of vdd
[00:41:37 CEST] <gh0st__> What about "ground-breaking" stuff?
[00:43:23 CEST] <atomnuker> those would be codecs
[00:45:23 CEST] <gh0st__> Woah, I'd like to hear where codecs strive to.
[00:48:36 CEST] <kierank> gh0st__: you should register
[00:49:39 CEST] <atomnuker> its 4 days after the deadline to get sponsored though :/
[00:53:54 CEST] <gh0st__> Kierank: heh, I really have consider to attend this kind of conference, since it's going to be really fun =)
[00:55:16 CEST] <atomnuker> I think you need a visa to visit the EU, right?
[00:55:40 CEST] <gh0st__> atomnuker: yes, you are right. 
[00:56:03 CEST] <kierank> seems so
[00:57:03 CEST] <gh0st__> That's a sad thing, not sure if I will get when the conference starts.
[00:57:58 CEST] <gh0st__> Too much bureaucracy.
[00:59:57 CEST] <durandal_1707> vdd is for old folks waiting death
[01:02:39 CEST] <gh0st__> durandal_1707: new blood is always needed to drive this codec world somewhere, right?
[01:03:28 CEST] <BBB> nevcairiel: believe it or not, I had a design for a new sws (I called it avs :-p these were very old times) a long time ago
[01:03:34 CEST] <BBB> nevcairiel: I may still have it somewhere on my hd
[01:03:56 CEST] <BBB> nevcairiel: but in the end I decided I didnt care enough, after all I use gl for scaling to display, who needs a software scaler anyway
[01:04:29 CEST] <BBB> gh0st__: yes, were were all new blood at some point ;)
[01:04:38 CEST] <BBB> gh0st__: and I agree, you should try to join
[01:04:55 CEST] <durandal_1707> gh0st__: vdd is not relevant, multimedia is not relevant anymore
[01:05:08 CEST] <BBB> so doomsday, dudio
[01:05:13 CEST] <BBB> lighten up
[01:05:43 CEST] <gh0st__> durandal_1707: why so?
[01:06:20 CEST] <BBB> hes just trolling, ignore it
[01:06:21 CEST] <atomnuker> gh0st__: all development happens on the internet mostly nowadays
[01:06:30 CEST] <atomnuker> this is just for presenting
[01:07:13 CEST] <durandal_1707> why vdd must be in france?
[01:07:55 CEST] <atomnuker> 2015's venue was nice and they had nice breakfast and they served pizzas on the last day and there were pizzas leftover for everyone
[01:08:27 CEST] <gh0st__> durandal_1707: I am not qualified enough to answer this, but why not?
[01:09:09 CEST] <durandal_1707> gh0st__: multimedia is dead mostly because nothing big new comes around
[01:09:14 CEST] <kierank> durandal_1707: you're in eu, what's the issuse
[01:09:26 CEST] <kierank> durandal_1707: what big do you want
[01:09:37 CEST] <durandal_1707> vdd is vlc folks and some lost souls
[01:10:22 CEST] <durandal_1707> kierank: i dont like travel
[01:10:30 CEST] <atomnuker> take the train then
[01:10:38 CEST] <atomnuker> everyone likes train travel
[01:11:04 CEST] <atomnuker> if you can get a train to switzerland somewhere you could take a tgv to paris
[01:11:47 CEST] <durandal_1707> my mommy doesnt allow me to be outside after 22h
[01:12:40 CEST] <durandal_1707> so i prefer teleportation
[01:12:44 CEST] <atomnuker> you can go out at 0:00 and take a sleeper train
[01:12:50 CEST] <atomnuker> 0:00 > 22:00 so you win
[01:12:58 CEST] <durandal_1707> until then
[01:13:07 CEST] <gh0st__> durandal_1707: I think there are left some BIG ideas around multimedia, that's what I am interested in.
[01:13:09 CEST] <atomnuker> erm 22:00 < 0:00 so its before
[01:13:53 CEST] <atomnuker> gh0st__: sure, av1 has big ideas (and daala is still the future imo)
[01:14:04 CEST] <durandal_1707> gh0st__: yea like fractals in video coding
[01:14:47 CEST] <durandal_1707> i need to finish clearvideo decoder
[01:14:49 CEST] <TD-Linux> I'll be talking about the worst AV1 encoder ever (and no it's not libaom)
[01:14:56 CEST] <durandal_1707> and atrac9
[01:15:09 CEST] <atomnuker> if you can think of a forward and reverse 2d transforms to get into a fractal domain you can use fractals
[01:15:28 CEST] <atomnuker> (don't tell this to google)
[01:16:02 CEST] <gh0st__> durandal_1707: I am rookie in multimedia world, but I think there a lot of great ideas unexplored.
[01:16:14 CEST] <BBB> durandal_1707: if you need your mommys permission to go to stuff, then maybe you shouldnt attend indeed...
[01:16:28 CEST] <BBB> anyway
[01:16:35 CEST] <BBB> TD-Linux: wait, theres more than one AV1 encoder?
[01:16:41 CEST] <TD-Linux> on an entirely serious note: fractal compression is dead http://www.geoffdavis.net/papers/ieee.pdf
[01:17:59 CEST] <TD-Linux> BBB, there is one on my hard drive. my goal is to beat prores by VDD :^)
[01:18:11 CEST] <BBB> can you guys start merging experiments in libaom so I know whats in and out?
[01:18:21 CEST] <BBB> right now I cant write a serious encoder because everything is an experimental flag
[01:18:31 CEST] <TD-Linux> yes, said encoder only hits a git snapshot
[01:18:39 CEST] <BBB> thats ok
[01:18:52 CEST] <BBB> but I need to know what features to approximately target for the final version
[01:19:00 CEST] <BBB> but even features very likely to get in are experiments
[01:19:03 CEST] <BBB> and so are things already rejected
[01:19:10 CEST] <BBB> that list seriously needs some cleaning up (or documenting)
[01:19:17 CEST] <TD-Linux> the default configuration is your best bet right now, but yes it does
[01:19:18 CEST] <BBB> too many experiments"
[01:20:03 CEST] <BBB> and may I also recommend someone not a daily dev doing some sort of bitstream analysis to find problems like the duplicate delta q coding etc?
[01:20:10 CEST] <BBB> I really dont think thats very professional
[01:20:54 CEST] <atomnuker> the secondary delta-q coding is even more useless now
[01:21:00 CEST] <atomnuker> because 128x128 superblocks
[01:21:02 CEST] <TD-Linux> well at least that problem is known
[01:21:18 CEST] <BBB> o o 128x128 SBs? finally
[01:21:28 CEST] <BBB> thats nice, I was hoping you guys would add that
[01:21:32 CEST] <BBB> are there 128x128 transforms?
[01:21:36 CEST] <atomnuker> nope
[01:21:41 CEST] <BBB> probably for the better
[01:21:44 CEST] <TD-Linux> only 32x32 enabled right now
[01:21:48 CEST] <atomnuker> not even 64x64 yet
[01:21:52 CEST] <BBB> 64x64 would be nice
[01:21:56 CEST] <atomnuker> (and I really want 64x64)
[01:22:05 CEST] <TD-Linux> we would like 64x64, but they will likely have coefficients dropped (like daala does)
[01:22:14 CEST] <durandal_1707> no groundbreaking news
[01:22:56 CEST] <atomnuker> TD-Linux: the new coefficient coding schemes might make full 64x64 transforms work better
[01:23:19 CEST] <atomnuker> so there might not be a need to drop coeffs
[01:23:34 CEST] <BBB> why drop coeffs?
[01:23:46 CEST] <TD-Linux> well the reason to drop coeffs is mostly to drop a portion of the transform
[01:23:59 CEST] <BBB> I understand what it does
[01:24:01 CEST] <BBB> but why do that?
[01:24:05 CEST] <BBB> for hw?
[01:24:10 CEST] <TD-Linux> it makes software faster too.
[01:24:29 CEST] <gh0st__> durandal_1707: I'd love to speak about groundbreaking stuff
[01:24:30 CEST] <BBB> only in theory; in practice most coefficients beyond the first few are zero (quantized) anyway
[01:24:30 CEST] <TD-Linux> atomnuker, a different coding scheme probably doesn't too much. coding an EOB sooner isn't very expensive
[01:24:54 CEST] <BBB> what scenario are you worried about
[01:24:55 CEST] <durandal_1707> gh0st__: first invent some
[01:25:00 CEST] <TD-Linux> BBB, right, I guess on the decoder I guess you could pick between transform impls based on coeff values.
[01:25:10 CEST] <BBB> you worry about the 6000th coefficient being 1 after quantization?
[01:25:19 CEST] <BBB> right
[01:25:23 CEST] <BBB> the decoder really isnt an issue here
[01:25:31 CEST] <BBB> I think youre worried about lines of code in the fwd transform
[01:25:34 CEST] <BBB> which is a fair transform
[01:25:36 CEST] <atomnuker> TD-Linux: well if its optional (e.g. EOB) then it'll be great, lets encoders pick what they'd like to do in case they think its better
[01:25:50 CEST] <TD-Linux> BBB, conversely, if it's not going to happen, why support it? :)
[01:25:50 CEST] <BBB> but I thought you guys had transforms that were modeled after each other (i.e. the bigger calls the smaller)
[01:26:10 CEST] <BBB> TD-Linux: its _unlikely_ to happen; it may, though
[01:26:12 CEST] <atomnuker> yes, they're now an experiment
[01:26:15 CEST] <atomnuker> and they're awesome
[01:26:23 CEST] <BBB> and I love _love_ ___LOVE___ writing simd for these kind of things
[01:26:34 CEST] <BBB> takes forever, but thats where you get actual speed gains
[01:26:51 CEST] <BBB> (dont forget ffvp9 is 30% faster in practice, not in theory, and this is part of why)
[01:27:10 CEST] <atomnuker> transform simd is the best
[01:27:16 CEST] <BBB> Im willing to bet a bottle of wine that ffaom can be made faster then libaom also
[01:27:20 CEST] <durandal_1707> then do same to ffhevc
[01:27:23 CEST] <gh0st__> durandal_1707: What would one recommend to learn/study to better understand codecs? My guesses are: linear algebra, mathematics in general.
[01:27:37 CEST] <BBB> durandal_1707: why you just said its dead :-p
[01:27:48 CEST] <atomnuker> gh0st__: practice, and read a few code bases, math doesn't help you much at all
[01:27:48 CEST] <BBB> durandal_1707: Im not contributing to dead technology
[01:28:18 CEST] <TD-Linux> BBB, you'd be hard pressed to find someone to make that bet with :)
[01:28:25 CEST] <durandal_1707> gh0st__: math is abstraction of ideas
[01:29:09 CEST] <BBB> hm ok
[01:29:47 CEST] <BBB> has the bit coder been decided?
[01:29:54 CEST] <BBB> (the arithmetic coding)
[01:30:02 CEST] <TD-Linux> yes, it's the one in the tree
[01:30:09 CEST] <BBB> and that won change anymore?
[01:30:10 CEST] <durandal_1707> why is ffhevc dead? folks still use it for whatever reason
[01:30:23 CEST] <TD-Linux> BBB, nope
[01:30:53 CEST] <BBB> TD-Linux: is it rANS? or something else?
[01:31:00 CEST] <TD-Linux> BBB, it's daala's range coder
[01:31:22 CEST] <BBB> how does adaptivity work?
[01:31:36 CEST] <BBB> is it integrated like cabac or is it external? and if external, how often and based on what?
[01:31:41 CEST] <TD-Linux> it adapts per symbol as well as propagating probs per frame
[01:31:54 CEST] <BBB> fw update?
[01:32:00 CEST] <durandal_1707> why not take that coder and make faster than ffv1 codec at same compression ratio?
[01:32:13 CEST] <TD-Linux> no compressed header
[01:32:23 CEST] <BBB> right, thats fw
[01:32:30 CEST] <TD-Linux> yeah I forget which is which
[01:32:30 CEST] <BBB> bw is replaced by per-symbol update
[01:32:39 CEST] <BBB> and thats maintained between frames right?
[01:32:42 CEST] <TD-Linux> yes
[01:32:46 CEST] <BBB> good, good
[01:32:49 CEST] <BBB> ok, I can start with that
[01:32:51 CEST] <BBB> cool
[01:32:51 CEST] <TD-Linux> all tile CDFs are merged at the end of the frame
[01:32:56 CEST] <TD-Linux> for the bw update
[01:33:18 CEST] <BBB> average?
[01:34:23 CEST] <BBB> and so base block size is 128x128& thats easy also. and I guess from there on its just recursive partitioning except the partition choices are larger than in vp9
[01:35:11 CEST] <cone-927> ffmpeg 03Carl Eugen Hoyos 07master:d4fbe99dabe7: lavf/dump: Remove superfluous cast.
[01:35:13 CEST] <gh0st__> atomnuker: durandal_1707: Hm, I thought in writing any serious codec math is in first place(most likely linear algebra(transformations and etc.)) for analysis, design, etc.
[01:36:07 CEST] <durandal_1707> gh0st__: it is for deep understanding
[01:36:12 CEST] <TD-Linux> BBB, yes
[01:36:31 CEST] <TD-Linux> see aom_cdf_adapt_q15 for the per symbol
[01:36:50 CEST] <TD-Linux> we don't have a SIMD implementation for that but you should be able to make something nice
[01:37:52 CEST] <durandal_1707> on CPU it takes ages to encode video with those modern codecs
[01:38:57 CEST] <durandal_1707> gh0st__: start with lossless intra only and than upgrade with more stuff
[01:41:21 CEST] <BBB> TD-Linux: hehe, dont worry, I like figuring simd things out myself ;)
[01:42:54 CEST] <durandal_1707> modern codecs should be simdable a lot and also use all cores power
[01:50:48 CEST] <gh0st__> durandal_1707: I agree, because that's about where the progress seems to gravitate to: more cores, bigger SIMD registers.
[02:29:02 CEST] <cone-927> ffmpeg 03James Almer 07master:95a6de5674ab: avcodec/snowenc: fix setting motion_est option
[03:18:28 CEST] <atomnuker> kierank: its no wonder all of france goes on holiday to the riviera, have you seen tgv prices?
[03:18:41 CEST] <atomnuker> 150 euros for a return trip from paris to nice
[03:18:52 CEST] <atomnuker> 175 in total if you make one of the trips first class
[03:19:33 CEST] <atomnuker> this is obscene, eurostar trains aren't that cheap
[03:22:44 CEST] <atomnuker> eurostar for today and return in 5 days is 250 pounds
[03:23:50 CEST] <atomnuker> granted, the pound isn't very strong compared to the euro (barely 1.08 atm) but still
[03:25:17 CEST] <atomnuker> goes to show the value of state ownership
[04:32:24 CEST] <peloverde> Where is late arriving out of band extradata supposed to be forwarded to the codec with the codecpar API?
[04:33:17 CEST] <atomnuker> peloverde: btw feel free to push the aac 960 patch, you're still the maintainer of the code
[04:33:22 CEST] <atomnuker> just put me as an author too
[04:33:49 CEST] <atomnuker> I wrote some code, gave it to durandal_1707, he wrote some code and then gave it to you :)
[04:38:26 CEST] <peloverde> I pushed both patches with the author update
[04:39:40 CEST] <atomnuker> huh, I guess I didn't pay attention then
[04:42:45 CEST] <jamrial_> peloverde: as packet side data type "new extradata" i think
[04:48:14 CEST] <rcombs> ^ this
[04:51:01 CEST] <peloverde> jamrial_: That happens for subsequent extradata, but the first extradata gets written straight to codecpar (at least for FLV)
[04:52:15 CEST] <jamrial_> you said late arriving, which means long after the header is read, right? so for that you just append it as side data in the packet you send to the decoder
[04:53:17 CEST] <peloverde> That's not what this demuxer is doing, maybe that's what ti should be doing? In this case the extradata occurs during the find_stream_info window
[04:56:32 CEST] <peloverde> In this particular case the extradata occurs directly after the 1st frame
[05:04:03 CEST] <jamrial_> mmh, flvdec.c is probably doing things wrong. codecpar->extradata is supposed to be filled during read_header(), and anything that shows up in a packet must be propagated as side data
[05:05:47 CEST] <jamrial_> is this h264 in flv? h264dec seems to work fine if extradata is not set during init(). it will use any extradata sent as side data afterwards
[05:07:47 CEST] <peloverde> aac in flv
[05:08:10 CEST] <peloverde> some ticket about a regression
[05:08:22 CEST] <peloverde> gotta go, i'll finish this later
[05:11:33 CEST] <jamrial_> peloverde: apparently should also be good
[05:11:35 CEST] <jamrial_> flvdec needs to be updated to just send everything as side data if it can't be set during read_header()
[05:52:54 CEST] <stevenliu> Not only flvdec   hls.c need also when DISCONTINUITY
[06:52:24 CEST] <jamrial_> peloverde: actually, the code that reads new extradata in aacdec is disabled for some reason, so it's never looking at it
[06:54:08 CEST] <jamrial_> after enabling it and making flvdec send every extradata as side data the file decodes (with some errors at the beginning, maybe a first frame before extradata is propagated)
[08:42:46 CEST] <nevcairiel> maybe some smart code would be useful that actually updates codecpar if during find_stream_info there is a new extradata message and extradata is otherwise empty
[11:05:26 CEST] <Compn> hmm
[11:05:29 CEST] <Compn> alibaba security team
[11:05:31 CEST] <Compn> thats neat
[11:05:41 CEST] <Compn> gotta secure incoming video
[11:06:12 CEST] <Compn> since they are fixing dos, i wonder if that means google video has a better way to abort DoS fuzzes
[11:06:44 CEST] <nevcairiel> if such a dos affects you, then your whole setup aint very good
[11:06:54 CEST] <Compn> right
[11:07:14 CEST] <nevcairiel> sandbox the thing and just kill it if it doesnt finish
[11:07:37 CEST] Action: Compn should buy some BABA stock
[11:07:50 CEST] <Compn> amazon needs to get video in its products page
[11:13:16 CEST] <Compn> still its nice that alibaba sends patches
[11:13:22 CEST] <Compn> :)
[11:59:32 CEST] <jkqxz> wm4:  V4L2 hwcontext is made somewhat tricky by the userptr stuff.  The ability to point to random places in host-virtual-memory is probably wanted (though I do wonder whether drivers will just copy it anyway), and doesn't fit in how it currently works.
[12:00:01 CEST] <jkqxz> If it was only V4L2_MEMORY_DMABUF (i.e. DRM fds) then it would be easy.
[12:00:34 CEST] <wm4> *shrug*
[12:05:26 CEST] <jkqxz> I think it's still possible with slightly more mapping than perhaps hoped.  E.g. an encoder taking an mmap context as input has to make a userptr context and map to it rather than being able to use the mmap one directly.
[12:06:14 CEST] <jkqxz> But I'm not sure I want to argue for it.
[12:06:28 CEST] <jkqxz> Do we know if there is any other hardware this works on beyond the qualcomm things?
[12:06:51 CEST] <rcombs> people keep telling me it's the future, but I dunno who else is working on implementing it either
[12:08:44 CEST] <jkqxz> Maybe I can just buy one of the dragonboards.
[12:08:53 CEST] <wbs> jkqxz: samsung has got v4l2 m2m drivers for some of their exynos chips
[12:09:02 CEST] <wbs> but they've got tiled pixelformats and other crazy things
[12:09:20 CEST] <wbs> (the same patchset was proposed a few years ago, including adding libavutil pixformats for the samsung tiled format)
[12:10:36 CEST] <jkqxz> Tiling is fine in hwcontext land, because it hides that sort of thing unless you really want to map it.  (Another argument for it...)
[12:20:00 CEST] <jkqxz> Anyone have an Odroid XU4?  That seems to be the obvious way to get a Exynos.
[12:20:40 CEST] <jkqxz> The Qualcomm stuff isn't obviously sold in this country at all.
[12:22:34 CEST] <wbs> jkqxz: I've got one of the dragonboards, and I ordered it from arrow. it was a bit of a hassle back then (it wasn't really ready for shipping when I ordered it), but hopefully it goes smoother now
[12:28:56 CEST] <RiCON> BtbN: can you confirm that nppi.lib is missing from cuda sdk 9 RC?
[13:08:03 CEST] <BtbN> RiCON, it very much looks like it so far
[13:08:41 CEST] <RiCON> no mention of it being deprecated/obsolete in the release notes
[13:09:00 CEST] <BtbN> it's just renamed/split or something
[13:09:05 CEST] <BtbN> there's nppif and nppif now
[13:09:11 CEST] <BtbN> nppig
[16:30:18 CEST] <wm4> kierank: lol that MXF thing
[16:34:21 CEST] <kierank> wm4: it's argument you won't win
[16:35:16 CEST] <kierank> it's an argument I had years ago about ts, I was called names and then I went and did my own thing
[16:35:16 CEST] <rcombs> what, 6518?
[16:44:01 CEST] <thardin> oh yeah, mxf. I tried to suggest switching to libmxf for sanity
[16:45:34 CEST] <thardin> no dice
[16:46:03 CEST] <thardin> or that other library. bmx or whatever
[17:00:36 CEST] <JEEB> sounds like a sound alternative since those projects most likely care about those formata
[17:03:40 CEST] <cone-851> ffmpeg 03Nicolas George 07master:6bde475cf2f9: lavfi/f_streamselect: convert to framesync2.
[17:03:41 CEST] <cone-851> ffmpeg 03Nicolas George 07master:0ae8df4109da: lavfi/framesync2: add dualinput helper functions.
[17:03:42 CEST] <cone-851> ffmpeg 03Nicolas George 07master:19804024d5b2: lavfi/vf_overlay: move to framesync2.
[17:03:43 CEST] <cone-851> ffmpeg 03Nicolas George 07master:f8d7b5febba0: lavfi: add a preinit callback to filters.
[17:03:44 CEST] <cone-851> ffmpeg 03Nicolas George 07master:dfa3aaa22a2b: lavfi: search options on child objects.
[17:03:45 CEST] <cone-851> ffmpeg 03Nicolas George 07master:05a23b256584: lavfi/framesync2: add common options.
[17:03:45 CEST] <cone-851> ffmpeg 03Nicolas George 07master:878fd0545a93: lavfi/vf_overlay: use framesync2 options.
[17:03:47 CEST] <cone-851> ffmpeg 03Nicolas George 07master:c1d8d33a51e3: lavfi/vf_blend: convert to framesync2.
[17:03:48 CEST] <cone-851> ffmpeg 03Nicolas George 07master:a8ab52fae728: lavfi/vf_libvmaf: convert to framesync2.
[17:03:49 CEST] <cone-851> ffmpeg 03Nicolas George 07master:eacb3ec96103: lavfi/vf_lut3d: convert to framesync2.
[17:03:50 CEST] <cone-851> ffmpeg 03Nicolas George 07master:23000c3de594: lavfi/vf_paletteuse: convert to framesync2.
[17:03:51 CEST] <cone-851> ffmpeg 03Nicolas George 07master:3bd11df45986: lavfi/vf_psnr: convert to framesync2.
[17:03:52 CEST] <cone-851> ffmpeg 03Nicolas George 07master:ef2176473d3d: vf_ssim: convert to framesync2.
[17:03:53 CEST] <cone-851> ffmpeg 03Nicolas George 07master:607900c905c4: lavfi: remove dualinput.
[17:03:54 CEST] <cone-851> ffmpeg 03Nicolas George 07master:844bc0d89e1d: doc/filters: document framesync options.
[17:03:55 CEST] <cone-851> ffmpeg 03Nicolas George 07master:7302d5e32597: lavfi: bump minor version after change in options.
[17:04:07 CEST] <durandal_1707> no commrnts for my despill filter?
[17:05:28 CEST] <BtbN> I just wonder if it'd make sense to combine it with the other keying filters
[17:05:54 CEST] <BtbN> but I guess it can be useful on its own. Just seems slightly less efficient, as it means iterating all pixels again
[17:58:37 CEST] <tdjones> atomnuker: Have you had a chance to look at my patches? Are there any changes that need to be made in order to merge?
[19:06:30 CEST] <peloverde> nevcairiel: jamrial If the stream uses a codec that supports extract_extradata then find_stream_info side data is promoted to primary extradata if none is present. It seems like this behavior should be extended to non extract_extradata codecs.
[19:09:34 CEST] <jamrial> peloverde: yeah, tried that and it seems to work
[19:10:41 CEST] <jamrial> peloverde: something like https://pastebin.com/euRdmErk
[19:17:40 CEST] <peloverde> I think that approach means we will eat a non-find-stream-info late extradata
[19:18:36 CEST] <jamrial> what do you mean? that's inside find_stream_info
[19:18:59 CEST] <peloverde> yes, but the demuxer is still setting the first extradata straight to codecpar
[19:19:20 CEST] <peloverde> the demuxer should always create a side data for non header extradata was my understanding from last night
[19:19:40 CEST] <peloverde> then the side data extradata should be promoted, not the codecpar extradata
[19:23:17 CEST] <jamrial> flvdec seems to set AVFMTCTX_NOHEADER, which means no header is present and streams are added dinamically as probe packets are read. that i assume, would include the first extradata into codecpar
[19:25:07 CEST] <jamrial> the extradata doesn't show up until like the fifth packet it seems, at which point find_stream_info already copied stuff into st->internal->avctx from codecpar. new stuff added to codecpar after that point even by AVFMTCTX_NOHEADER demuxers is apparently ignored
[19:25:19 CEST] <peloverde> So what is supposed to happen for late first extradata past the end of find_stream_info? Is it a case of if you've mad it this far you probably are okay without it?
[19:26:04 CEST] <jamrial> if it's outside of the find_stream_info probe window then the stream will not be readable and it will ask you to increase probe size, i guess
[19:26:18 CEST] <jamrial> or just fail like it's doing right now
[19:27:11 CEST] <peloverde> There are some codecs that take optional extradata. 
[19:27:38 CEST] <jamrial> yeah, aac is supposedly one of them
[19:27:59 CEST] <peloverde> If the decoder inits successfully with the default config, then you get new extradata later it kind of seems like it should be forwarded and not eaten
[19:28:02 CEST] <jamrial> but the code to read extradata in packet side data is disabled for some reason
[19:29:47 CEST] <peloverde> Is there any documentation of the expectations of when demuxers can and can't fill codecpar?
[19:30:13 CEST] <jamrial> avcodec.h, if at all
[19:30:42 CEST] <wm4> for some self-contained codecs you can decode with basically an empty codecpar
[19:30:43 CEST] <jamrial> but afaics, codecpar is filled in read_header() only, unless AVFMTCTX_NOHEADER is set
[19:31:15 CEST] <wm4> find_stream_info is more a separate feature that enables ffprobe and some bad software to know redundant codec parameters before decoding
[19:31:45 CEST] <jamrial> within packets, if you need new extradata you use packet side data type "new extrada", and if you need to change stream parameters you use packet side data type "Data param change"
[19:31:59 CEST] <jamrial> but you don't modify codecpar
[19:32:08 CEST] <jamrial> since that will not be propagated to the decoder
[19:32:18 CEST] <peloverde> Right now I only care about AVFMTCTX_NOHEADER formats
[19:32:35 CEST] <jamrial> in that case, you should probably be able to change codecpar fields
[19:32:40 CEST] <jamrial> flvdec seems to do it after all
[19:32:57 CEST] <jamrial> but find_stream_info might not be handling things right
[19:33:47 CEST] <peloverde> jamrial: "you should probably be able to change codecpar fields" Up until what point? The end of the stream
[19:33:58 CEST] <peloverde> I feel like we're going around in circles here
[19:34:49 CEST] <nevcairiel> you cant change codecpar after it has been created and returned to the caller once
[19:35:06 CEST] <nevcairiel> there is a few exceptions to that, but lets stick with that =p
[19:35:17 CEST] <peloverde> nevcairiel: okay, that makes sense to me
[19:37:28 CEST] <jamrial> peloverde: that's why i said find_stream_info might not be handling things right. it copies the contents of codecpar to the internal avctx struct in AVStream once then never again, even for AVFMTCTX_NOHEADER formats that are supposed to dig deeper for new streams and stream info
[19:38:16 CEST] <nevcairiel> there is a flag things can set if they update the codecpar for whatever reason
[19:38:20 CEST] <nevcairiel> mpegts uses it
[19:38:31 CEST] <nevcairiel> but most things s hould just create the stream only when they know the info
[19:42:48 CEST] <jamrial> nevcairiel: need_context_update?
[19:46:27 CEST] <peloverde> hah, it works
[19:49:04 CEST] <jamrial> what does?
[19:49:18 CEST] <peloverde> Setting need_context_update
[19:51:11 CEST] <jamrial> nice. pastebin?
[19:52:08 CEST] <peloverde> https://pastebin.com/yJz2FyPw
[19:53:44 CEST] <jamrial> this would also affect h264 streams. do we have any such sample?
[19:55:16 CEST] <peloverde> It seems like it should. The use of IDR frames make things a little weirder.
[19:55:34 CEST] <peloverde> You probably could create a synthetic stream by moving the extradata after the first frame. 
[19:56:26 CEST] <jamrial> mmh, the file is reported as mono with this approach
[19:56:49 CEST] <peloverde> It is mono
[19:57:00 CEST] <peloverde> Or does it use PS?
[19:58:04 CEST] <peloverde> you're right, it has stereo
[20:27:24 CEST] <peloverde> it looks like AV_CODEC_CAP_CHANNEL_CONF uses codec_info_nb_frames which doesn't get reset when the context update occurs
[20:50:26 CEST] <peloverde> jamrial: I sent patches for both issues to the list
[21:18:38 CEST] <cone-548> ffmpeg 03Michael Niedermayer 07master:429f3266c14a: avformat/mxfenc: Check that the video codec in D-10 is MPEG-2
[21:18:38 CEST] <cone-548> ffmpeg 03Michael Niedermayer 07master:6def8b8d924a: avcodec/h264idct_template: Fix integer overflow in ff_h264_idct8_add()
[21:18:38 CEST] <cone-548> ffmpeg 03Michael Niedermayer 07master:2a83866c9f95: avcodec/hevc_ps: Fix undefined shift in pcm code
[21:18:38 CEST] <cone-548> ffmpeg 03Michael Niedermayer 07master:732f97645615: avcodec/snowdec: Fix integer overflow in decode_subband_slice_buffered()
[00:00:00 CEST] --- Wed Aug 30 2017