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

[burek]

[00:21:40 CEST] <iive> i really don't understand why they want to get rid of mpegenccontext so badly...
[00:22:33 CEST] <iive> all it does is waste cycles and memory
[00:22:52 CEST] <wm4> are you saying you like this absolute insane mess
[00:23:00 CEST] <wm4> +ly
[00:23:29 CEST] <iive> yes
[00:24:57 CEST] <wm4> lol
[00:26:38 CEST] <iive> calling names is no argument. You can call even the perfectly designed structure "insane mess" if you don't understand it.
[00:28:56 CEST] <wm4> I've seen this insane mess myself, so
[00:30:39 CEST] <iive> and that is more name calling.
[00:31:06 CEST] <nevcairiel> its code, its not a person, its a description =p
[00:31:43 CEST] <nevcairiel> and this part of the code is definitely rather a big mess
[00:31:47 CEST] <iive> things have names too, e.g. boaty mcboatface
[00:32:41 CEST] <wm4> iive: mpegenccontext is not how software should be written
[00:32:46 CEST] <iive> well, some people go ape shit crazy if there is even a little bit code duplication...
[00:34:13 CEST] <iive> but it is perfectly ok to replicate same structure over and over again for every single codec.
[00:35:03 CEST] <wm4> iive: would you mpegenccontext have provide linear search? because that must have been duplicated a 1000 times in ffmpeg
[00:35:17 CEST] <iive> wm4: your statements still contain 0 bits of useful information.
[00:35:40 CEST] <iive> linear search?
[00:35:58 CEST] <durandal_1707> iive, why you care?
[00:36:05 CEST] <wm4> I guess I'll go back to doing nothing, which is way more productive than this
[00:36:18 CEST] <iive> durandal_1707: i've written codec or two.
[00:37:08 CEST] <iive> wm4: no, really. I would like to explain to me, why mpegenccontex is insane mess and how these changes improve anything.
[00:37:44 CEST] <iive> objectively, not just stating preferences.
[00:37:57 CEST] <durandal_1707> Maintainbility
[00:38:00 CEST] <wm4> iive: everything depends on everything if mpegenccontext is involved
[00:38:24 CEST] <iive> durandal_1707: that's been abused a lot... be more specific.
[00:40:45 CEST] <iive> aka, maintainability means that the developers would understand it easier, and thus be able to work with it. However this again leads to personal preferences. That's why i mentioned that everything you don't understand is "insane mess".
[00:41:44 CEST] <nevcairiel> there is a difference between not understanding, and code being extra convoluted to make understanding hard, if many developers have issues figuring out some code, you  could already assume something is wrong with it
[00:43:24 CEST] <iive> nevcairiel: and how these modifications change that?
[00:44:22 CEST] <nevcairiel> separating individual modules out of the spaghetti code clearly makes things simpler to follow
[00:46:35 CEST] <iive> we are talking about structures, not code, but
[00:46:38 CEST] <nevcairiel> in a perfect world, you would have small individual components with a clearly documented interface to access them - mpegenccontext is none of that, its a huge piece of code with barely any developer knowing the full interaction with all of its fields, many of which are specific to a single codec. so by stripping out some of those single codecs that dont even use the bulk of this context, these codecs get simpler, and the context 
[00:46:38 CEST] <nevcairiel> itself slowly gets as well
[00:47:05 CEST] <iive> separating spaghetti code means code duplication...
[00:47:14 CEST] <nevcairiel> so?
[00:47:52 CEST] <nevcairiel> also not necessarily, or maybe only very small parts of it
[00:48:11 CEST] <iive> it increases maintenance burden, because you have to check and fix same thing on a lot of more places. 
[00:48:38 CEST] <nevcairiel> or some specific components can be taken out and made to stand on their own, so it can still be shared but with a cleaner interface between them
[00:49:58 CEST] <nevcairiel> throwing everything into one component results in something thats not easily understandable, so splitting it into smaller slices it becomes manageable, and can still be shared where appropriate
[00:50:02 CEST] <wm4> iive: as these cleanups get done, the truth seems to be more like that barely any code was truly shared
[00:50:18 CEST] <wm4> iive: or where it's shared, it can be continued to be shared in a cleaner way
[00:50:22 CEST] <nevcairiel> and that, many things ended up in mpegenccontext that still were only used by one codec
[00:50:46 CEST] <nevcairiel> i dont think there was much actual duplication of complex functionality
[00:51:14 CEST] <nevcairiel> instead it was refactored to have a clean interface, and that shared between components
[00:51:31 CEST] <iive> give me example
[01:00:52 CEST] <nevcairiel> i had one in mind from quite recently but i didnt find it just now, but i'm tired and its late, so i'll go sleep
[01:01:22 CEST] <iive> no hurry, i'm always around.
[01:04:19 CEST] <iive> durandal_1707: so you've noticed this 42 byte buffer bug, long before libav committed it to their repo?
[01:15:39 CEST] <BBB> iive: mpegenccontext is bad because it suggests theres some functional relationship between mpeg and h264 that somehow relates to mpeg
[01:16:00 CEST] <iive> i thought h264 doesn't use it
[01:16:01 CEST] <BBB> iive: there is no such relationship, none at all, not even remotely, and any suggestion to the contrary is evidence that youd ignorant about video coding
[01:16:09 CEST] <BBB> thats why stuff shouldnt use it
[01:16:17 CEST] <BBB> but thats how it was designed
[01:16:36 CEST] <BBB> and so it became this piece of crap that has by definition to be useless, otherwise it cant be functionally be shared between codecs
[01:16:50 CEST] <BBB> lowest common denominator"
[01:17:14 CEST] <BBB> it has to die, it is the only solution
[01:17:25 CEST] <BBB> its not the name, the name is fine, but a struct by that name should have to do with mpeg encoding
[01:18:24 CEST] <BBB> ../libavcodec/wmv2.h:int ff_wmv2_decode_mb(MpegEncContext *s, int16_t block[6][64]); <- please explain to me how that is proper design
[01:18:56 CEST] <BBB> ../libavcodec/h263.h:int ff_h263_decode_mba(MpegEncContext *s); <- and this
[01:19:00 CEST] <BBB> (this is so easy)
[01:19:58 CEST] <BBB> iive: Im going to assume you have a background in general software engineering, if not, go learn about object oriented programming and suffer java for a bit
[01:20:06 CEST] <BBB> iive: its a wonderful lesson in the good, bad and ugly
[01:20:12 CEST] <BBB> theres lots of bad and ugly there
[01:20:17 CEST] <BBB> but, some of it is genuinely good
[01:20:51 CEST] <iive> BBB: you are not the only who have written codecs for ffmpeg, you know.
[01:24:11 CEST] <iive> BBB: for your answer, wmv2 shares a lot of similarities with msmpeg4v12 and v34 , that's why ff_wmv2_decode_mb is called by s->decode_mb
[01:24:54 CEST] <iive> what do you consider proper design, having every msmpeg4 variant his own context and duplicating all the common code?
[01:36:41 CEST] <BBB> why duplicate?
[01:37:00 CEST] <BBB> call it mpegcommoncontext if you believe its common to mpeg-like codecs
[01:37:05 CEST] <BBB> of which h264 is not one
[01:37:12 CEST] <BBB> but dont call it mpegenccontext
[01:37:19 CEST] <iive> why are you involving h264 here?
[01:37:40 CEST] <iive> it is mpeg common context... 
[01:37:45 CEST] <BBB> because it used it at some point, and it indicates the ridiculousness of the thing
[01:37:51 CEST] <BBB> it was a h264 decoder, by the way, not an encoder
[01:37:56 CEST] <BBB> using mpegEnccontext
[01:38:25 CEST] <iive> are you sure?
[01:38:35 CEST] <BBB> oh am I sure
[01:38:49 CEST] <BBB> I worked fair bits on ffh264, yknow - and still do
[01:38:54 CEST] <BBB> why dont you git log it
[01:39:29 CEST] <iive> ok, I'll take your word on it.
[01:39:55 CEST] <iive> but I do remember that h264 split quite early on its development stage.
[01:40:06 CEST] <JEEB> uuh
[01:40:36 CEST] <BBB> hahahahahahahahha
[01:40:52 CEST] <BBB> iive: this is why people ask me, not you, questions about h264 race conditions
[01:41:02 CEST] <BBB> $ git log --author rsbultje at gmail.com --oneline -- ../libavcodec/h264*  | wc -l
[01:41:03 CEST] <BBB>       86
[01:41:04 CEST] <BBB> FYI
[01:41:56 CEST] <JEEB> h264: deMpegEncContextize
[01:42:04 CEST] <JEEB> Sat Feb 16 21:14:00 2013 +0100
[01:42:16 CEST] <JEEB> so yeah, totally early in its development :)
[01:42:43 CEST] <JEEB> (that's the date of the merge into FFmpeg)
[01:47:48 CEST] <iive> from the look of it, mpegenccontext has been used mostly for stuff like frame allocation, and callback functions. probably some tables and hwaccel.
[01:49:50 CEST] <iive> what i'm saying is that h264 have never been forced to fit into mpegenccontext. like somebody above said, every codec could add its own bits in there.
[01:50:17 CEST] <iive> and that was not the case with h264.
[01:55:20 CEST] <iive>  
[01:56:13 CEST] <iive> as for the buffer overlow. Libav prise themselves for reviewing every patch before it been committed. But they don't actually do it.
[01:57:17 CEST] <iive> the patch that have been submitted for review doesn't contain this comment
[01:58:24 CEST] <iive> the reviewer requested better/serious comment...
[01:58:58 CEST] <iive> but probably never reviewed the final version, as the discrepancy would have been obvious.
[02:04:51 CEST] <BBB> libav review being sucky does not negate mpegenccontext being just as sucky
[02:05:31 CEST] <BBB> if its just a bnch of frame allocations (which beg the question, why not just call it av_frame_alloc? or does it do some more that most users dont actually use, like motion vector allocation and mode decoding?), why not just call it commoncontext?
[02:06:06 CEST] <BBB> but thats the thing, it does do more, the logic being that we can add block mode tracking to all codecs, except it doesnt go that way
[02:06:27 CEST] <BBB> the result is that lavfi depends on lavc for things like how do you translate a quantizer to a common unit
[02:06:34 CEST] <BBB> (muhahahahahahahaha)
[02:06:46 CEST] <BBB> which is just utterly ridiculous so Im going to leave it at that
[02:15:21 CEST] <iive> from the commit message: 1) extracting a simplified version of the frame management code from mpegvideo.c. We don't need last/next_picture anymore, since h264 uses its own more complex system already and those were set only to appease the mpegvideo parts.
[02:15:45 CEST] <iive> so, i guess it does do that now.
[02:16:14 CEST] <iive> as for the libav review... this is separate topic, that's why i put an empty line, to separate it.
[02:18:56 CEST] <iive> the connection is that, this bug have been introduced by splitting x8 into its own context.
[02:19:28 CEST] <iive> so I was wondering what is the logic of doing that... 
[02:19:48 CEST] <iive> i am NOT arguing about h264 here.
[02:28:32 CEST] <BBB> iive: I agree 100% that doing away with mpegenccontext and trying to re-figure out what common part are between codecs that use mpegenccontext, is the right thing to do
[02:28:51 CEST] <BBB> iive: and I say that with all my experience as a codec developer and a professional software engineer
[02:30:29 CEST] <iive> and where do you draw the line?
[02:30:56 CEST] <iive> aka, you say 100% that there shell be no shared structure and code among codecs?
[02:43:23 CEST] <iive> i'll be leaving for now. I'll just tell you this. saying that because mpegenccontext is bad for h264, then it is bad for everything is logical fallacy. I'm also not somebody who accepts appeal to authority. and using strong language and been aggressive won't help you either. have fun.
[03:53:03 CEST] <DHE> I noticed something about HLS players. Most players download whole files into a distinct buffers so per-file downloads are quick, but ffmpeg just slowly feeds the file into a single buffer leaving the TCP Receive buffer mostly full.
[03:53:12 CEST] <DHE> Does that sound like something worth changing?
[04:19:30 CEST] <Compn> DHE : do you have  an example of a stream url that downloads quickly with another player?
[04:19:34 CEST] <Compn> so we can test this with ffmpeg. ..
[04:19:59 CEST] <Compn> there might be a realtime option somewhere that may do what you want . but not sure it will work with hls
[04:22:02 CEST] <DHE> Compn: any stream really, whether live or VOD. ffmpeg seems to read data out of the TCP buffer at exactly the playback rate producing a smooth playback graph, but every other (ie. commercial) app will download the .ts files as quickly as possible resulting in a very spiky graph
[04:22:34 CEST] <DHE> I've been playing with an Over-the-air receiver that produces the MPEG-TS right out of the frequency
[04:24:00 CEST] <DHE> the only time I've really had problems was when I paused playback of a video. the remote HTTP server timed me out since ffmpeg just sat on a TCP connection
[04:26:24 CEST] <Compn> ffmpeg -fflags nobuffer
[04:27:12 CEST] <Compn> theres also -re
[04:27:23 CEST] <Compn> not sure it solves your pro b lem though
[04:28:25 CEST] <cone-291> ffmpeg 03Michael Niedermayer 07master:9ac154d1facd: avcodec/ac3dec: Reset SPX when switching from EAC3 to AC3
[04:28:44 CEST] <DHE> it's not related
[04:29:25 CEST] <DHE> basically what I'm suggesting would be to implement a supplemental buffer in the hls demuxer such that HTTP downloads are fully downloaded/buffered by the demuxer first
[04:29:28 CEST] <Compn> are we talking about ffmpeg or ffplay ?
[04:29:51 CEST] <DHE> well, mainly ffplay. I use mpv as a main video player but ffplay as a reference for ffmpeg behaviour
[04:29:56 CEST] <Compn> ok...
[04:30:01 CEST] <Compn> ffplay is different
[04:30:26 CEST] <Compn> and probably that feature is not something that would be implemented by devs
[04:30:35 CEST] <DHE> the 2 reasons for this buffer are 1) eliminate the pause issue I mentioned above   and 2) it seems to be the behaviour of every other HLS-compatible player I've tried so far, including hardware/set top boxes
[04:30:43 CEST] <Compn> yeah , no i get what you are saying
[04:30:49 CEST] <DHE> neither is particularly strong I admit
[04:31:23 CEST] <Compn> patches welcome i suppose :)
[04:31:48 CEST] <DHE> oh? that above ticket sounds like it might be related to a ticket of my own..
[04:31:53 CEST] <Compn> ffplay and ffmpeg have different things
[04:31:58 CEST] <DHE> sorry, distracted by the shiny thing
[04:32:12 CEST] <Compn> ffplay -probesize 32 -sync ext INPUT
[04:32:12 CEST] <Compn>  (the sync part tells it to try and stay realtime).
[04:32:16 CEST] <Compn>  ^^ did you try that ?
[04:32:24 CEST] <Compn> https://trac.ffmpeg.org/wiki/StreamingGuide
[04:32:33 CEST] <Compn> if you said ffplay before i would have pasted it earlier :P
[04:33:30 CEST] <Compn> still wont buffer though, but latency might be reduced :P
[04:33:55 CEST] <DHE> I don't think this is something command-line options can fix. This sounds like something specific to chunk-based HTTP-based streaming formats
[04:35:37 CEST] <DHE> well, it's late. gotta go.
[10:59:46 CEST] <ismail> c
[10:59:50 CEST] <ismail> whoops sorry
[11:02:41 CEST] <wm4> it can't be forgiven
[12:43:16 CEST] <wm4> ubitux: the srt decoder does not handle this well: http://sprunge.us/MRTR 
[12:43:41 CEST] <ubitux> lol
[12:43:58 CEST] <ubitux> yeah well, add it to the stack of tickets
[12:44:21 CEST] <ubitux> i'm working on nlmeans these days, i'll go back to subtitles after that
[12:46:47 CEST] <wm4> created a ticket
[13:49:34 CEST] <BBB> nevcairiel: i never said msvc was broken, its a product of incompetent leadership
[13:49:48 CEST] <BBB> but not broken - I mean, its a c89 compiler (or it was, until recently)
[13:49:57 CEST] <nevcairiel> I just dont consider DCE in debug to be something that a compiler needs to do
[13:50:01 CEST] <BBB> so for it to not support c99 (at that time) is perfectly understandable
[13:50:14 CEST] <BBB> I dont consider c99 something that a compiler needs to do :)
[13:50:23 CEST] <BBB> I just need+want it myself
[13:50:47 CEST] <BBB> so Im pointing out their idiocy publicly so that they get embarassed into having to implement it anyway even if theyd rather watch youtube videos first
[13:50:51 CEST] <nevcairiel> DCE is clearly an optimization, it optimizes dead function calls out
[13:50:52 CEST] <BBB> (or read facebook, or ...)
[13:51:25 CEST] <BBB> I still see it as a purely technical concern
[13:51:30 CEST] <BBB> the compiler clearly supports DCE
[13:51:39 CEST] <BBB> let me give ana analogy
[13:51:50 CEST] <BBB> in x264, I can use preset=veryslow or preset=placebo, right?
[13:51:52 CEST] Action: Daemon404 always thought relying on dce was silly fwiw
[13:52:04 CEST] <BBB> you probably know that preset=placebo uses a exhaustive me (me=tesa, I believe)
[13:52:09 CEST] <Daemon404> breaks random compilers every month or two
[13:52:13 CEST] <Daemon404> not just msvc
[13:52:14 CEST] <BBB> whereas preset=veryslow uses --me=umh
[13:52:29 CEST] <BBB> so & what if I want to use mostly placebo presets, but without the exhaustive search?
[13:52:37 CEST] <BBB> I can use preset=placebo me=umh, right?
[13:52:40 CEST] <BBB> ok, on to libvpx
[13:52:55 CEST] <BBB> vpxenc best uses exhaustive me, and vpxenc  good cpu-used=0 is the veryslow analogue
[13:52:56 CEST] <nevcairiel> this isnt going to end up being a very good analogy
[13:53:06 CEST] <BBB> how do I use exhaustive r/d search without exhaustive me?
[13:53:09 CEST] <BBB> I can't
[13:53:13 CEST] <BBB> libvpx = microsoft
[13:54:00 CEST] <BBB> not well possible to tune specific options in the software because I dont feel like using five minutes of my precious time on making it user-configurable which most clients dont need while Id rather play on [s]google+[/s] facebook"
[13:54:03 CEST] <nevcairiel> switching the me algorithm around sounds like a rather simple thing and just a lack of options in the vpx case, while performing dce could rely on the full optimizer to run, which in this case isnt wanted
[13:54:31 CEST] <nevcairiel> ie. it may not be as simple as addin an option
[13:54:42 CEST] <BBB> hard to say without access to the source code
[13:54:59 CEST] <BBB> but still a purely technical limitation, i.e. easy to solve if someone stops facebooking for a few hours and actually gets to work
[13:55:21 CEST] <BBB> but facebooking is much more interesting than getting actual work done, esp. if you work for microsoft
[13:55:27 CEST] <BBB> ...
[13:55:43 CEST] <nevcairiel> you could argue the same about us, we could fix it in a couple hours and be done with it =p
[13:56:05 CEST] <BBB> were not the only software using DCE
[13:56:10 CEST] <BBB> its a typical 1-to-N problem
[13:56:21 CEST] <BBB> to optimize solving the problem, do you solve O(N) or O(1) problems?
[13:56:23 CEST] <nevcairiel> i have not seen any other that fails to build without optimizations
[13:56:34 CEST] <nevcairiel> its a silly design to rely on that
[13:56:41 CEST] <BBB> theres N pieces of software and 1 compiler ;)
[13:56:52 CEST] <BBB> well, Im not in love with DCE or anything
[13:56:58 CEST] <BBB> Im just giving you one method to solve it
[13:57:02 CEST] <BBB> if people object to it, I wont do it
[13:57:05 CEST] <wm4> some code rather trickily relies on DCE
[13:57:08 CEST] <BBB> its super-trivial, thats all I say
[13:57:09 CEST] <wm4> like allcodecs.c
[13:59:11 CEST] <wm4> (meaning you wouldn't get too far by just making the simplest changes)
[14:00:50 CEST] <BBB> its not trivial is usually only an objection for microsoft-employees
[14:00:58 CEST] <BBB> Ill get it working ;)
[14:01:03 CEST] <BBB> but only if people want it...
[14:02:08 CEST] <nevcairiel> i dont care, lto is shit anyway and debugging works fine for me with a bit of manual trickery
[14:02:23 CEST] <wm4> BBB: well I suggested a tricky macro, that might work for this purpose
[14:06:12 CEST] <BBB> wm4: if someone can confirm it works, that would be nice (itd be nice if all*.c and *dsp_init.c dont turn into a massive mess)
[14:06:24 CEST] <BBB> wm4: even better if libav agrees on the approach so it doesnt complicate merging...
[14:07:24 CEST] <wm4> (I had that macro from something someone suggested on #libav-devel)
[14:07:42 CEST] <wm4> the original was probably more elegant and simpler, but I don't remember the details
[14:10:24 CEST] <BBB> so if majority opinion wants to get rid of DCE and your macro does not complicate the code, I think we have general consensus on the way forward?
[14:10:30 CEST] <BBB> (not complicating code is my only concern)
[14:10:37 CEST] <BBB> (or uglifying, if you wish)
[14:10:47 CEST] <wm4> I think it'd need a view example patches to ensure consent
[14:12:19 CEST] <atomnuker> why would we want to eliminate DCE? so msvc can compile ffmpeg without optimizations for debugging?
[14:12:51 CEST] <wm4> it doesn't just affect msvc
[14:12:57 CEST] <wm4> it even affects debugging with gcc
[14:15:28 CEST] <atomnuker> I wouldn't mind as long as it's not that ugly
[14:27:20 CEST] <iive> yes, i've also hit gcc dead code elimination, when using -O0 and some of the functions in the eliminated block are not defined/existing.
[14:33:42 CEST] <rcombs> while we're on things that break with -O0, there are a few ARM ASM functions that break when not inlined
[14:33:58 CEST] <wm4> inline asm strikes back
[14:35:06 CEST] <BBB> rcombs: av_always_inline should inline even in -O0, no?
[14:35:08 CEST] <rcombs> I didn't know there was an inline asm empire
[14:35:14 CEST] <rcombs> BBB: not in my experience
[14:35:19 CEST] <BBB> strange...
[14:35:24 CEST] <BBB> well life sucks :-p
[14:37:31 CEST] <rcombs> but if()ing around the ASM call with __builtin_constant_p works
[14:38:19 CEST] <rcombs> so I guess eliminating blocks gated by compile-time constants isn't considered an "optimization" by gcc
[14:59:10 CEST] <iive> the problem is with the yasm assembly. the functions are #ifdef-ed totally and the compiler still looks for them.
[14:59:10 CEST] <iive> but hey, it is opensource gcc, you can fix it, if it is not fixed already.
[15:13:41 CEST] <iive> if consider binutils and gcc separate, then so be it.
[15:15:42 CEST] <Daemon404> nevcairiel, do you have time this week to help out with some parser merges?
[15:18:38 CEST] <nevcairiel> i guess so 
[15:19:05 CEST] <Daemon404> its only a few (like 3) right now, and then a ton of svq3 things i can do on my own
[15:19:20 CEST] <Daemon404> im just not entirely familiar with our hevc parser code, which differs 
[15:19:59 CEST] <nevcairiel> there is a simple rule when dealing with such commits that move code and rename it - dont try to merge the move, instead move our copy of the code so nothing gets lost
[15:20:27 CEST] <nevcairiel> although these first 4 commits or so seem rather innocent
[15:20:27 CEST] <Daemon404> no i know that
[15:20:31 CEST] <nevcairiel> the big work comes after svq3
[15:20:31 CEST] <Daemon404> but ours takes a hevc context
[15:20:38 CEST] <Daemon404> which may be problematic
[15:20:50 CEST] <Daemon404> since teh plan, afaict, is to merge teh two parsers
[15:21:05 CEST] <nevcairiel> dont mix up h264_parse with h264_parser
[15:21:11 CEST] <nevcairiel> its an unfortunate naming for sure
[15:21:29 CEST] <nevcairiel> parse is just the generic bitstream parser used by the decoder
[15:21:34 CEST] <Daemon404> well it seems wrong to have a function nam,e h2645_parse that takes a HEVCContext, no?
[15:21:34 CEST] <nevcairiel> not what we consider the "parser"
[15:22:50 CEST] <Daemon404> anyway, you can look at that rename commit
[15:22:55 CEST] <Daemon404> and tell me if im off base or what
[15:23:09 CEST] <Daemon404> i'd rather not do it myself, given im not confident in my analysis.
[15:23:30 CEST] <nevcairiel> you mean things like ff_hevc_extract_rbsp taking hevccontext?
[15:23:40 CEST] <Daemon404> yes
[15:23:49 CEST] <nevcairiel> did you notice how it doesnt use it for shit
[15:23:55 CEST] <nevcairiel> except checking if its set for some arcane reason?
[15:24:00 CEST] Action: nevcairiel goes to blame around in it
[15:24:03 CEST] <Daemon404> it sets a member too
[15:24:10 CEST] <Daemon404> right under the check
[15:24:20 CEST] <Daemon404> unless i got lost in my blame digging
[15:24:31 CEST] <nevcairiel> i dont see it
[15:24:37 CEST] <Daemon404> oh it was moved to the nal context
[15:24:42 CEST] <Daemon404> it USED to be part of hevccontext
[15:24:52 CEST] <Daemon404> i suppose thats why the check was there
[15:24:57 CEST] <Daemon404> which, btw, was added in a merge commit
[15:24:59 CEST] <Daemon404> with no explanation
[15:25:21 CEST] <nevcairiel> the rename is otherwise rather innocent, just strip the hevccontext out of that particular function then
[15:25:26 CEST] <Daemon404> let me remove the whole hevccontext thing and send a patch to the ML for review
[15:25:34 CEST] <Daemon404> just so there is a "paper trail"
[15:25:53 CEST] <Daemon404> i dont want to break soem arcane voodoo.
[15:26:15 CEST] <nevcairiel> ff_hevc_split_packet also nonly uses the hevccontext so it can pass it to _extract_rbsp
[15:26:19 CEST] <nevcairiel> so its unnedded
[15:26:21 CEST] <Daemon404> yes i know
[15:26:23 CEST] <nevcairiel> needed*
[15:26:40 CEST] <Daemon404> ill send a patch regardless for michael to sign off on.
[15:27:00 CEST] <nevcairiel> there is a later patch that makes h264 use this new stuff
[15:27:05 CEST] <Daemon404> otherwise maybe something like concating ogg files that have hevc and remuxing to nut may break
[15:27:09 CEST] <Daemon404> given the levels of voodoo i see often
[15:27:15 CEST] <nevcairiel> which will need more thorough looking since h264 has a bunch of extra magic in there
[15:27:22 CEST] <Daemon404> yes
[15:27:34 CEST] <nevcairiel> but thats after svq3
[15:27:44 CEST] <Daemon404> theres a lot of stuff before teh really painful bit
[15:27:47 CEST] <Daemon404> which was pushed yesterday
[15:28:16 CEST] <nevcairiel> https://git.libav.org/?p=libav.git;a=commitdiff;h=8d0cc8ca97678f4ca87948ebabcbaab5a4f4c1f6 .. thats the one we need to really look out for, was in yesterdays batch i think
[15:30:01 CEST] <Daemon404> yes
[15:32:54 CEST] <Daemon404> i wish git was able to show betters diffs for whitespace changes
[15:33:01 CEST] <Daemon404> but i guess thats not a reasonable expectation
[15:33:06 CEST] <Daemon404> (removing an if and reindenting)
[15:33:52 CEST] <wm4> huh, git can ignore whitespace when making diffs, is that not enough?
[15:34:17 CEST] <Daemon404> it can? maybe im just dumb
[15:35:54 CEST] <wm4> git diff -w or so
[15:49:38 CEST] <wm4>  [FFmpeg-devel] [PATCH] libavcodec/qsvdec_h2645.c Bug fixed: wrong ticks_per_frame.
[15:49:40 CEST] <wm4> what
[15:51:06 CEST] <Daemon404> his mail client is REALLY weird
[15:51:13 CEST] <Daemon404> all his replies have the oddest quote style ive ever seen
[15:52:17 CEST] <ubitux> the single letter thing?
[15:52:34 CEST] <Daemon404> ubitux, like for multiple quote levels
[15:52:37 CEST] <Daemon404> instead of >>
[15:52:39 CEST] <Daemon404> ir does 2>
[15:52:40 CEST] <Daemon404> and 3>
[15:52:41 CEST] <Daemon404> and such
[15:52:47 CEST] <ubitux> :D
[15:52:52 CEST] <Daemon404> and really odd spacing and linebreaks
[15:52:54 CEST] <Daemon404> its hard to read
[15:53:05 CEST] <ubitux> i vaguely remember yeah
[17:54:54 CEST] <JEEB> michaelni: I recommend for http://git.videolan.org/?p=ffmpeg.git;a=commit;h=9779b6262471d553c1ed811ff7312564e39d8adf to be backported
[17:55:01 CEST] <JEEB> into any actively maintained branches
[17:55:12 CEST] <JEEB> should cause some happy customers
[17:55:32 CEST] <Daemon404> nobody is happen when they have to use subtitles
[17:55:35 CEST] <Daemon404> happy*
[17:55:37 CEST] <Daemon404> just ask ubitux 
[17:55:40 CEST] <JEEB> :D
[17:56:20 CEST] <JEEB> difference is result is basically https://i.fsbn.eu/pgs.png
[17:56:46 CEST] <JEEB> *in result
[17:56:52 CEST] Action: ubitux only see a mismatching background image
[17:57:01 CEST] <JEEB> ssshh
[17:57:08 CEST] <JEEB> also not taken by me but aanyways
[17:57:45 CEST] <ubitux> so what else is there to see?
[17:58:01 CEST] <ubitux> stronger contrast below?
[17:58:34 CEST] <JEEB> the range is properly widened
[17:58:48 CEST] <JEEB> and if there was more color it'd have BT.709 colorimetry instead of BT.601
[18:18:58 CEST] <Angus> Hmm, I'm running into a segfault in av_read_frame
[18:20:10 CEST] <Angus> does this make any sense?  print *s $33 = {av_class = 0x7ffff2ffe920 <av_format_context_class>, iformat = 0x7ffff3000460 <ff_h264_demuxer>, oformat = 0x0, priv_data = 0x6470e0, pb = 0x646fe0, ctx_flags = 0,    nb_streams = 1, streams = 0x645b40, filename = '\000' <repeats 1023 times>, start_time = -9223372036854775808, duration = -9223372036854775808,
[18:31:19 CEST] <cone-034> ffmpeg 03Derek Buitenhuis 07master:4791a910c0dc: lavc/hevc_parse: Don't take a HEVCContext
[19:14:23 CEST] <jamrial> durandal_1707: can you check "libavcodec/exr : Fix slice threading"?
[19:14:48 CEST] <durandal_1707> apply it.. 
[19:15:33 CEST] <jamrial> alright
[19:19:54 CEST] <cone-034> ffmpeg 03Martin Vignali 07master:3ce19882c504: libavcodec/exr: move xsize and ysize to thread data
[20:59:35 CEST] <atomnuker> Daemon404: neither clang nor gold supports LTO last time I checked
[21:00:14 CEST] <Daemon404> gold supports lto via plugin
[21:00:15 CEST] <sfan5> clang doesn't do LTO?
[21:00:20 CEST] <Daemon404> which is provided by clang.
[21:01:59 CEST] <atomnuker> huh, interesting
[21:02:19 CEST] <atomnuker> I wonder how it compares to the incredlibly slow gcc lto
[21:02:44 CEST] <atomnuker> (not that I've seen any benefit from using LTO, but oh well)
[21:03:11 CEST] <nevcairiel> Daemon404: did you see the error report on the ML about the hevc parse change?
[21:03:14 CEST] <atomnuker> I think it did reduce the final size of the libraries though, without symbols
[21:03:53 CEST] <rcombs> clang supports LTO
[21:04:20 CEST] <rcombs> by having the compiler write LLVM bitcode and the linker work with that
[21:05:12 CEST] <Daemon404> nevcairiel, yes i have a patch sending now
[21:05:25 CEST] <Daemon404> rcombs, yes via plugin to gold
[21:05:56 CEST] <rcombs> Daemon404: or the llvm linker, right?
[21:06:07 CEST] <Daemon404> yes, but i dont think youd realistically want to use that.
[21:06:14 CEST] <Daemon404> also, i gotta say, the 50 different hwaccels are pretty dang annoying
[21:06:21 CEST] <Daemon404> they break easily and are a big pita to test
[21:06:24 CEST] <Daemon404> if you even can.
[21:06:42 CEST] <Daemon404> do we have a fate box that tests them
[21:06:44 CEST] <Daemon404> even just to build
[21:07:40 CEST] <nevcairiel> the base hwaccels like vaapi, vdpau dxva2 etc do get build tested, external libraries likely not
[21:08:07 CEST] <Daemon404> well qsv is the one ve broken twice
[21:08:49 CEST] <Daemon404> it took two weeks for someone to even notice
[21:09:02 CEST] <Daemon404> libnut had a faster turn around time.
[21:19:22 CEST] <jamrial> why do we have qsv decoders when there are already hwaccels?
[21:19:59 CEST] <rcombs> because you can't use hwaccels via the decoder API (e.g. ffmpeg.c)
[21:20:37 CEST] <nevcairiel> thats a cheap excuse and you know it :)
[21:21:14 CEST] <rcombs> a better question for an API like QSV might be "why do we have hwaccels when there are decoders"
[21:26:11 CEST] <rcombs> the qsv hwaccel structs don't actually list any functions, which IIUC means they end up just being wrappers around the decoders
[21:28:02 CEST] <nevcairiel> they only exist to allow selecting their pixfmt
[21:33:55 CEST] <wm4> yeah, thats annoying
[23:37:06 CEST] <rkern> Is there an AWS account I can use to test the videotoolbox encoder on their device farm?
[00:00:00 CEST] --- Tue Apr 26 2016