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

[burek]

[00:53:17 CEST] <cone-344> ffmpeg 03Michael Niedermayer 07master:09f0429b9961: avcodec/mjpegdec: simplify rgb index remaping
[00:53:18 CEST] <cone-344> ffmpeg 03Michael Niedermayer 07master:74af6ae02100: avcodec/vp8: Check bitstream input in vp7_fade_frame() before time consuming operation
[00:53:19 CEST] <cone-344> ffmpeg 03Michael Niedermayer 07master:4356e03fd651: libavcodec/pnm_parser: do not lose skipped parts in reporting of how much was consumed
[02:59:47 CEST] <atomnuker> jkqxz: are you planning to push the huge vaapi patchset anytime soon?
[06:11:02 CEST] <cone-716> ffmpeg 03Steven Liu 07master:1e20ed4382b0: lavf: add raw AVS2 demuxer
[06:15:08 CEST] <cone-716> ffmpeg 03Steven Liu 07master:2e5860799bea: Revert "lavf: add raw AVS2 demuxer"
[06:15:09 CEST] <cone-716> ffmpeg 03hwren 07master:0caa33c60b69: lavf: add raw AVS2 demuxer
[14:41:56 CEST] <BtbN> What happened to coveralls?
[14:53:01 CEST] <durandal_1707> can we use signbit() ?
[14:53:51 CEST] <nevcairiel> use FF_SIGNBIT
[15:13:32 CEST] <nevcairiel> hrm is libaom that unfinished that it would just crash when using a gcc build on windows, or did my build somehow screw up
[15:13:58 CEST] <nevcairiel> "Access violation reading location 0xFFFFFFFF" usually indicates an alignment problem though
[15:16:58 CEST] <nevcairiel> where is that native decoder so i dont have to bother with this?! :)
[15:17:47 CEST] <JEEB> :)
[15:20:02 CEST] <onecamper> negative image dimensions? Of course ffmpeg won't find the pixels belonging to it :p
[15:25:01 CEST] <nevcairiel> at least rebuilding is now much faster
[15:25:06 CEST] <J_Darnley> a bottom-to-top image should clearly have a negative stride
[15:25:32 CEST] <J_Darnley> or just hold the camera upside-down then everything should work perfectly
[15:26:06 CEST] <nevcairiel> some tools do indeed use negative height to  indicate the orientation
[15:27:02 CEST] <nevcairiel> although i#ve not seen it coded into files which dont specifically document that to be possible
[15:27:29 CEST] <nevcairiel> i fixed my libaom crashing, -mstackrealign to the rescue
[16:32:11 CEST] <jamrial> nevcairiel: you didn't get any ffmpeg build failure after compiling libaom with the decoder only?
[16:32:17 CEST] <nevcairiel> nah
[16:32:27 CEST] <nevcairiel> that just worked
[16:32:28 CEST] <jamrial> the configure check doesn't make sure that either the decoder and encoder API are present in libaom
[16:32:35 CEST] <nevcairiel> todays git master of both ffmpeg and aom
[16:32:47 CEST] <nevcairiel> oh but I do  have --disable-encoders
[16:32:57 CEST] <jamrial> ah, that'd explain it
[16:33:12 CEST] <jamrial> i need to tidy up the configure check in any case
[16:35:57 CEST] <nevcairiel> i hear the encoder build is currently broken anyway because they removed some enum/define
[16:36:27 CEST] <nevcairiel> some feature that was never m eant to be available beyond vp8 anyway
[16:36:28 CEST] <jamrial> that our wrapper uses?
[16:36:46 CEST] <nevcairiel> apparently
[16:37:14 CEST] <jamrial> oh, the partition stuff
[16:37:21 CEST] <nevcairiel> yeah thats the one
[16:37:27 CEST] <jamrial> i'll fix it
[16:37:39 CEST] <jamrial> it's just an avoption
[16:45:50 CEST] <cone-797> ffmpeg 03James Almer 07master:b69ea742ab23: avcodec/libaomenc: remove AVOption related to frame partitions
[16:57:52 CEST] <durandal_1707> av1 does not support RGB?
[16:59:48 CEST] <atomnuker> it does
[17:01:07 CEST] <atomnuker> but you'd better spend 2 more bits and use ycgco which should compress better
[17:13:33 CEST] <RiCON> jamrial: you can close http://trac.ffmpeg.org/ticket/7433
[17:14:53 CEST] <jamrial> RiCON: done
[17:15:20 CEST] <nevcairiel> trac is too slow, now i also did at the same time :d
[17:16:27 CEST] <nevcairiel> apparently it doesnt error if two things change the status to closed at the same time too
[17:16:52 CEST] <jamrial> weird
[17:17:32 CEST] <jamrial> five seconds difference should have been enough for it to at least warn there was another change in the meantime :p
[17:55:04 CEST] <atomnuker> firefox 62.0 seems to crash if it tries to link to 4.0
[17:55:47 CEST] <atomnuker> though its ridiculous how many websites init a decoder without actually having any media in them
[17:56:41 CEST] <jamrial> atomnuker: Arch links firefox with 4.0, but afaik the official builds use 3.4 or so
[17:57:25 CEST] <atomnuker> yeah, I went as far as to install ffmpeg to my home dir, as well as mpv and always invoke mpv with LD_LIBRARY_PATH but that doesn't help
[17:57:46 CEST] <atomnuker> firefox randomly links to whatever it finds on a per-page basis and randomly crashes
[17:58:27 CEST] <nevcairiel> there was a problem with some bsf changes, although i thought that might've been after 4.0
[17:59:18 CEST] <jamrial> i saw that thread and asked for more info, but i don't think they replied after that
[17:59:26 CEST] <jamrial> and yeah, that's not in 4.0 afaik
[18:03:12 CEST] <atomnuker> I wish there were non webkit or gecko browsers, even servo got scrapped
[18:03:48 CEST] <atomnuker> last time someone went to the trouble of making a web browser entirely from scratch (e.g. without an already written engine) was netrunner, a failed /g/ project
[18:04:13 CEST] <atomnuker> and that hasn't had commits in 7 months
[18:07:29 CEST] <BtbN> Edge
[18:07:47 CEST] <atomnuker> wasn't that based on trident?
[18:16:29 CEST] <BtbN> It's a Fork that ended up as pretty much a full rewrite
[18:33:48 CEST] <nevcairiel> the core engine in Edge seems pretty solid, but they likely wont bother to make a cross platform browser
[18:35:59 CEST] <nevcairiel> Blink is diverging from WebKit every day, how long until you dont consider it equal anymore? :d
[18:36:29 CEST] <JEEB> I think effectively there's enough changes already that they're not the same
[18:37:27 CEST] <JEEB> GOOG has blink, APPL has webkit, Edge has EdgeHTML
[18:37:49 CEST] <nevcairiel> Gecko is the outsider without a huge company behind it
[18:52:27 CEST] <atomnuker> yep, firefox also crashes on debian
[18:53:29 CEST] <atomnuker> and we did the bump in february
[18:56:23 CEST] <atomnuker> and for some reason libfreetype6 now depends on libjs-jquery and javascript-common on debian
[18:56:34 CEST] <atomnuker> this day keeps giving on
[18:56:42 CEST] <JEEB> o_O
[18:57:07 CEST] <BtbN> Well, fonts can contain JavaScript
[19:00:06 CEST] <atomnuker> seems like the libfreetype6-dev package needs it (because it ships freetype6-docs which apparently now needs it?), but that's still a very common dep if you want to compile something that has to do with text
[19:00:51 CEST] <atomnuker> --no-install-recommends fixes that, all the more reason not to install recommended packages by default
[19:09:10 CEST] <jkqxz> Yeah, putting 'APT::Install-Recommends "0";' in the apt config is pretty much the first thing I do on any new Debian install.
[19:13:11 CEST] <jamrial> atomnuker: there are no bug reports of firefox crashes on Arch
[19:13:16 CEST] <jamrial> how is it crashing?
[19:18:08 CEST] <atomnuker> MediaPD~oder #3[993] general protection ip:7fc5aa7ef899 sp:7fc5a217c240 error:0 in libavutil.so.56.18.102[7fc5aa7e8000+3f000]
[19:19:44 CEST] <jamrial> some hwcontext problem maybe?
[19:20:47 CEST] <jamrial> also, that lavu version is post 4.0
[19:22:53 CEST] <atomnuker> wasn't that the problem?
[19:24:09 CEST] <atomnuker> I don't think anything crashed until I updated to 62.0
[19:24:44 CEST] <JEEB> I think Firefox didn't malloc some things through av_*
[19:25:06 CEST] <JEEB> let me see if I can find the recently poked bug report @ mozilla for that
[19:25:29 CEST] <JEEB> https://bugzilla.mozilla.org/show_bug.cgi?id=1486080
[19:25:40 CEST] <JEEB> If this is not a sec:{high,crit} bug, please state case for ESR consideration:
[19:25:43 CEST] <JEEB> User impact if declined: firefox will crash when playing AAC audio when using ffmepg 4.0
[19:28:04 CEST] <JEEB> seemingly mozilla read "- decoding: Set/allocated/freed by user." as "user can allocate it as wishes"
[19:32:17 CEST] <jamrial> yeah, the doxy was updated recently by Timo to clarify that using the av_malloc family is a must
[19:38:53 CEST] <atomnuker> ah, so its that bug
[19:41:41 CEST] <BtbN> I still don't understand _why_ using it is a must.
[19:42:17 CEST] <JEEB> I think it gets read by something with an optimized bit stream parser or whatever
[19:42:34 CEST] <JEEB> something got added after 3.4 that specifically made that to be expected
[19:42:37 CEST] <BtbN> But why would something just reading it care about who allocated it, as long as the padding is there?
[19:42:56 CEST] <JEEB> I would bet the lack of padding was the problem
[19:43:04 CEST] <JEEB> but not like I've seen the segfaults
[19:43:08 CEST] <BtbN> Looking at mozillas patch for it, the padding was there.
[19:43:20 CEST] <BtbN> The segfault was leading into av_free
[19:43:34 CEST] <jamrial> BtbN: https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=f631c328e680a3dd491936b92f69970c20cdcfc7
[19:43:36 CEST] <BtbN> So something in ffmpeg is freeing the pointer that is documented as "user supplied"
[19:43:36 CEST] <JEEB> was the alignment OK?
[19:43:42 CEST] <jamrial> that commit replaces the extradata
[19:45:36 CEST] <BtbN> That seems like something it shouldn't be doing
[19:46:08 CEST] <BtbN> What if the user is using that pointer elsewhere? It's not documented to be taken ownership by ffmpeg, so it should not be freed
[19:46:27 CEST] <jamrial> you're probably right
[19:46:34 CEST] <JEEB> yea
[19:48:29 CEST] <jamrial> reverting that commit will limit the potential usability of the auto inserted bsfs in decoders, though
[19:49:00 CEST] <jamrial> but if it means an api break then i guess we don't really have a choice
[19:49:08 CEST] <BtbN> https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/utils.c;h=285bfdbc63cb4311806850166081194ae8b2fa4c;hb=HEAD#l2132 this needs to do something differently for a decoder
[19:49:26 CEST] <BtbN> Like, not copying it, just passing the pointer
[19:49:53 CEST] <BtbN> But that will probably break a bunch of stuff otherwise that assumes this behaviour
[19:49:59 CEST] <BtbN> *elsewhere
[19:50:32 CEST] <BtbN> Or just plain not freeing codec->extradata in case of a decoder?
[19:51:00 CEST] <BtbN> Where is that other extradata even coming from? The user is specifying it in AVCodecContext, not codecpar
[19:52:08 CEST] <jamrial> BtbN: it's internal code https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/decode.c;h=4607e9f318a59b8bb146e5ee9e6b85e584a8610e;hb=HEAD#l185
[19:52:30 CEST] <jamrial> autoinserted bsfs for decoders
[19:52:51 CEST] <BtbN> That's just incompatible with the currently user-owned extradata on decode contexts
[19:53:13 CEST] <BtbN> Needs a new field or something
[19:53:16 CEST] <jamrial> bsfs can change extradata. the commit that introduced this issue makes sure the filtered extradata makes it back to the context
[19:53:29 CEST] <jamrial> yeah, it evidently is not ok as is
[19:53:58 CEST] <BtbN> The natural thing to do is to just take ownership. But that's an API break
[19:55:48 CEST] <jamrial> this commit is not in any release. i'm surprised mozilla went and worked around it in a rush
[19:56:17 CEST] <jamrial> also, the guy that reported it to bugzilla is the same one that reported it to our ml, but then didn't reply when i asked for more info :/
[19:56:23 CEST] <BtbN> Well, the code they fixed it in won't reach users until a year or so
[19:56:32 CEST] <BtbN> So it makes sense
[19:56:56 CEST] <jamrial> i'll send a revert patch to the ml, to see what others think
[19:57:06 CEST] <jamrial> but i don't think we have many options here
[19:57:32 CEST] <BtbN> extradata_internal field. If present, it takes precedence over the normal extradata.
[19:57:42 CEST] <BtbN> Super ugly, but something like that is needed to keep the functionality.
[19:58:15 CEST] <jamrial> ugly and probably not trivial. maybe in the future...
[19:59:04 CEST] <BtbN> Would basically mean replacing every instance of avctx->extradata with something like avcodec_get_extradata(avctx)
[19:59:40 CEST] <BtbN> And it's calling for accidental misuse
[20:41:35 CEST] <durandal_1707> please, someone please, rewrite swscale
[20:42:30 CEST] <atomnuker> we have a trac page and a plan
[20:44:16 CEST] <durandal_1707> if Dav1d uses cached bitstream reader i request %5 of money
[20:53:03 CEST] <nevcairiel> highly optimzed entropy coders usually use their own thing
[20:53:12 CEST] <nevcairiel> like cabac, it doesnt use either
[20:58:01 CEST] <durandal_1707> sure it doesnt use bytestream api
[21:37:03 CEST] <atomnuker> one annoying thing about the opus range coder was that although you always wrote/read bytes you had to use a bitstream reader
[21:37:52 CEST] <atomnuker> since the start was 9 bits, 1 bit had to be carried each time you read/wrote a byte
[21:58:26 CEST] <BBB> dav1d doesnt use any ffmpeg code
[21:58:30 CEST] <BBB> dav1d is not part of ffmpeg
[22:00:30 CEST] <nevcairiel> if we dont get ffav1 that i can put hwaccel hooks into, that would really suck =p
[22:00:36 CEST] <BBB> sorry
[22:00:45 CEST] <nevcairiel> so basically, you screwed us all ov er
[22:00:46 CEST] <nevcairiel> :)
[22:01:46 CEST] <durandal_1707> what? I'm so sad now :(
[22:02:05 CEST] <BBB> hey j-b, theres some people here that have questions for you
[22:02:08 CEST] <rcombs> guess that means av1_videotoolbox is a decoder instead of a hwaccel
[22:02:08 CEST] Action: BBB goes back to coding
[22:02:35 CEST] <rcombs> (wonder when to expect that; next year? year after?)
[22:04:54 CEST] <nevcairiel> seriously though, the hwaccel infra in ffmpeg m akes such things super easy, if we have to invent some crazy magic to do that just because someone wanted to make an external library instead, thats really terrible
[22:05:14 CEST] <nevcairiel> and hwaccel for new mainstream codecs is important
[22:05:38 CEST] <BBB> that may well be the case
[22:06:09 CEST] <BBB> but that was not taken into consideration when deciding to place dav1d in or out of ffmpeg
[22:06:30 CEST] <nevcairiel> should've asked!
[22:07:13 CEST] <jamrial> are you serious? you're not writting it as a lavc decoder?
[22:08:16 CEST] <JEEB> having such a thing be !LGPL becomes quite a bit harder
[22:08:35 CEST] <JEEB> so something being a library does make sense, although it sucks for other use cases
[22:09:45 CEST] <rcombs> the library could expose hwaccel hooks ¯\_(Ä)_/¯
[22:21:03 CEST] <durandal_1707> screw you guys i gonna write my own decoder, for 0$
[22:39:35 CEST] <jamrial> BBB: so what do i do with the split bsf you asked me to write? i don't understand
[22:40:40 CEST] <BBB> we still will need it, I think
[23:03:55 CEST] <durandal_1707> atomnuker: you deleted your AV1 decoder code right?
[00:00:00 CEST] --- Thu Sep 13 2018