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

[burek]

[05:12:44 CET] <cone-268> ffmpeg 03Steven Liu 07master:1c1031003b05: avformat/hlsenc: fix too many open files bug
[10:44:15 CET] <cone-073> ffmpeg 03Timo Rothenpieler 07master:5403d90f3265: avcodec/nvenc: make gpu indices independend of supported capabilities
[10:44:15 CET] <cone-073> ffmpeg 03Timo Rothenpieler 07master:6b0a3ee6f809: avcodec/nvenc: add logging for more error cases
[10:58:59 CET] <wm4> is it just me or is qsv support in ffmpeg.c really fucked up
[10:59:43 CET] <nevcairiel_> qsv is generally fucked up to various degrees
[11:03:03 CET] <mateo`> wm4: we updated the next libav merge on https://github.com/ubitux/FFmpeg/tree/merge-libav, would you be ok to test the hwaccel part (we already did some basic tests with vaapi though) ?
[11:03:20 CET] <mateo`> michaelni: would you be ok to take a look at the branch too ?
[11:04:23 CET] <cone-073> ffmpeg 03Daniil Cherednik 07master:9a619bef5492: dcaenc: Use Huffman codes for Bit Allocation Index
[11:05:04 CET] <nevcairiel> should've taken the chance to purge that crappy old vdpau stuff out of there =p
[11:05:22 CET] <mateo`> it will be removed with the next major bump
[11:06:26 CET] <wm4> mateo`: I can check vdpau later (only new API of course, nobody would even notice if the old API accidentally broke)
[11:07:07 CET] <mateo`> wm4: that would be very helpful
[11:07:12 CET] <wm4> I'd actually take the chance to subtly break the old API
[11:07:21 CET] <ubitux> note: it's important to test with slice decoding
[11:07:25 CET] <wm4> just to annoy the unpleasant people who want it
[11:07:37 CET] <nevcairiel> whats "slice decoding"
[11:07:44 CET] <ubitux> -thread_type slice
[11:07:49 CET] <nevcairiel> hwaccels dont thread
[11:07:50 CET] <wm4> ...for hwaccels?
[11:08:09 CET] <ubitux> yes they don't, but make sure they actually don't
[11:08:14 CET] <ubitux> especially with slice based encodes :p
[11:08:18 CET] <mateo`> i told ubitux to remove it, but he wants to keep it apparently :p
[11:08:24 CET] <ubitux> lol
[11:08:27 CET] <mateo`> don't lol
[11:08:31 CET] <ubitux> :(
[11:08:32 CET] <nevcairiel> i would never call hwaccels with anything but -threads 1, but guess so? =P
[11:09:21 CET] <nevcairiel> wonder if i can punish my laptop and make it build ffmpeg and test dxva
[11:09:27 CET] <nevcairiel> but then i dont have any buildenv setup here either
[11:11:25 CET] <wm4> same here, I force threads=1
[11:11:38 CET] <wm4> nevcairiel: well if you don't I can do that too, later
[11:12:37 CET] <nevcairiel> well its like 9pm here, about to eat and pass out after, and renting a boat tomorrow morning.. so probably not going to happen
[11:12:41 CET] <nevcairiel> need to vacation on vacation
[11:13:43 CET] <wm4> indeed
[11:35:10 CET] <jkqxz> wm4:  The qsv stuff in ffmpeg.c is all a disaster.  I just hacked it enough to continue working and hoped that merges would get the fixed initialisation ordering and then it could be sane.
[11:37:54 CET] <wm4> meh
[11:38:41 CET] <jkqxz> s/sane/at least slightly saner than it is now/
[11:57:00 CET] <ubitux> i thought the qsv code was supposed to be replaced entirely?
[11:57:04 CET] <ubitux> didn't happen?
[12:00:49 CET] <jkqxz> The qsv code was replaced.  These are hacks to ffmpeg.c (the qsv_transcode_init() function) to make it continue to kindof work without merging avconv changes.
[12:02:07 CET] <jkqxz> For that lavf / hw_frames_ctx thing, presumably there is some deranged reason why lavf doesn't just call avcodec_free_context()?
[12:02:37 CET] <wm4> well, lavf can reopen codecs
[12:02:53 CET] <wm4> although close_codec or whatever should handle this as well
[12:03:14 CET] <wm4> there's a reason we wanted to get rid of AVStream.codec - it's too hacky
[12:06:30 CET] <wm4> what I actually don't get is why lavf would open the hw decoder in the first place
[12:09:41 CET] <ubitux> jkqxz: right, so it's just because we're far behind in the merge effort?
[12:09:52 CET] <wm4> the change was already skipped
[12:10:22 CET] <ubitux> as soon as i can push the h264 merge commit i'm going to work on merging a few batches
[12:10:41 CET] <ubitux> these 2 blockers were annoying
[12:11:41 CET] <michaelni> ubitux, mateo` the branch breaks "./ffmpeg -threads 1 -i ~/tickets/1069/green-block-artifacts-from-canon-100-hs.MOV  -vframes 30 test30.avi"
[12:12:27 CET] <wm4> ok I'm getting to testing this now: https://github.com/ubitux/FFmpeg/tree/merge-libav
[12:12:31 CET] <wm4> what should I test?
[12:12:42 CET] <wm4> just normal vdpau decoding?
[12:12:52 CET] <ubitux> wm4: for example yes
[12:12:58 CET] <ubitux> michaelni: will look, thanks
[12:13:32 CET] <michaelni> ubitux, should i upload the sample ? (iam not sure where it is, it was on ftp IIUC)
[12:13:41 CET] <ubitux> it's fine, i have it
[12:13:54 CET] <michaelni> k
[12:14:19 CET] <ubitux> could we have such sample in fate?
[12:16:31 CET] <ubitux> would be nice to have it for the chinese crazy sample as well btw
[12:16:46 CET] <ubitux> but that last one is not predictible (and never was)
[12:17:26 CET] <wm4> hm vdpau with mpv works fine... what was the way to run FATE with hwaccel again? (also is there a way to skip unrelated tests)
[12:17:55 CET] <ubitux> HWACCEL=...
[12:18:14 CET] <ubitux> i tried it but it failed some tests even before the merge
[12:18:28 CET] <wm4> it should fail on a cropping sample
[12:18:56 CET] <michaelni> ubitux, i can add any sample to fate that you want me to add, this one is 8mb though so its a bit bigger than i like
[12:19:10 CET] <wm4> Test h264-conformance-cvfc1_sony_c failed.
[12:19:13 CET] <wm4> I think that is the one
[12:20:10 CET] <wm4> hm nope fails on too many
[12:22:12 CET] <ubitux> can you confirm it fails with master as well?
[12:22:58 CET] <wm4> without HWACCEL it succeeds
[12:23:50 CET] <wm4> rebuilding etc.
[12:23:56 CET] <jkqxz> What are the others which fail?  I think the two greyscale ones are also expected not to work.
[12:24:31 CET] <wm4> a whole bunch
[12:25:04 CET] <wm4> aha
[12:25:07 CET] <wm4> I might be stupid
[12:25:11 CET] <wm4> those are actually hevc samples
[12:26:08 CET] <wm4> but also e.g. fate-vsynth1-mpeg4-nr
[12:26:25 CET] <wm4> mpeg1 and mpeg2 ones too
[12:26:38 CET] <wm4> (and I'm on master right now)
[12:28:51 CET] <wm4> and now it almost killed my computer, duh
[12:28:59 CET] <ubitux> michaelni: thanks for the samples, i'll look at this in the next hours
[12:29:08 CET] <ubitux> wm4: sounds promising
[12:29:54 CET] <wm4> fate-h264-conformance-frext-hpcamolq_brcm_b failed
[12:30:04 CET] <wm4> h264-conformance-frext-pph10i1_panasonic_a
[12:30:09 CET] <wm4> h264-conformance-mr6_bt_b
[12:30:15 CET] <wm4> h264-conformance-mr8_bt_b
[12:30:23 CET] <wm4> h264-reinit-large_420_8-to-small_420_8
[12:30:37 CET] <wm4> h264-extradata-reload
[12:30:45 CET] <wm4> h264-brokensps-2580
[12:30:51 CET] <wm4> h264-attachment-631
[12:31:03 CET] <wm4> this is on e5ac554ba7d6c0298a2504f9dc2411a81e1a6d96
[12:33:02 CET] <wm4> I think these things have been broken for a long time
[12:33:58 CET] <jkqxz> I typically only run fate-h264 / fate-hevc / etc. with HWACCEL=x.  Running all of fate isn't so healthy.
[12:34:50 CET] <wm4> ubitux: for windows do you want a fate run? I don't have fate there (and also little disk space), so I'd like to avoid that
[12:35:51 CET] <ubitux> it should be fine
[12:36:19 CET] <ubitux> if you say vdpau still works that's enough for me
[12:36:38 CET] <ubitux> i also have 2 breaking samples from michael so there is still stuff to fix anyway
[12:37:59 CET] <ubitux> thanks for your testing
[12:44:38 CET] <durandal_1707> i think michaelni have millions of samples and time machine
[12:55:49 CET] <cone-073> ffmpeg 03bnnm 07master:cab0f3abc53e: avcodec/atrac3: allow 6 channels (non-joint stereo)
[12:58:23 CET] <wm4> ubitux: briefly tested dxva2 and d3d11va decoding, appears to work (again, didn't attempt to set threads or slice threads)
[12:59:10 CET] <ubitux> yup, thanks a lot :)
[14:00:13 CET] <cone-073> ffmpeg 03Paul B Mahol 07master:96fe4432f55b: avcodec/wmaprodec: unbreak XMA mono decoding
[14:00:14 CET] <cone-073> ffmpeg 03Paul B Mahol 07master:5d2609929d48: avcodec: add XMA2 parser
[14:00:15 CET] <cone-073> ffmpeg 03Paul B Mahol 07master:18cfcc64581f: avcodec/wmaprodec: add xma_flush for seeking in XMA2
[14:00:16 CET] <cone-073> ffmpeg 03Paul B Mahol 07master:8869f5efecb6: avformat/wavdec: enable seeking with XMA2
[14:37:32 CET] <ubitux> michaelni: do we have a list or ranges of H264Context fields that are protected in frame threading? 
[14:37:54 CET] <ubitux> the setup_finished comment refers to "some context properties"
[14:38:11 CET] <ubitux> we'd like to identify them
[14:51:16 CET] <BBB> ubitux: omg that would be amazing
[14:57:05 CET] <cbsrobot> BBB: a faster j2k decoder would be highly appreciated
[14:57:19 CET] <BBB> yeah indeed
[14:57:41 CET] <cbsrobot> there is a nonfree lib called kakadu that can decode j2k in realtime
[14:57:51 CET] <cbsrobot> at least they say so
[14:57:56 CET] <BBB> Ive heard about it
[14:58:01 CET] <BBB> its an interesting business model
[14:59:26 CET] <ubitux> BBB: i'm assuming no one ever known?
[14:59:31 CET] <cbsrobot> well - nobody wants to work on j2k, I guess that's why their business model works
[14:59:39 CET] <ubitux> i mean... we're doing threading but have no idea what fields are supposed to be protected?
[14:59:41 CET] <BBB> maybe nobody cares about j2k
[14:59:56 CET] <BBB> ubitux: its not that bad
[15:00:01 CET] <BBB> ubitux: think more organic
[15:00:16 CET] <BBB> ubitux: we sort of fumbled the code until it worked?
[15:00:26 CET] <ubitux> :))
[15:00:36 CET] <ubitux> apparently it doesn't work that well
[15:00:36 CET] <mateo`> BBB: ubitux is already 99% organic 
[15:00:44 CET] <mateo`> not sure about the 1% left
[15:00:49 CET] <BBB> ubitux: wait, why?
[15:00:55 CET] <BBB> ubitux: you mean theres bugs? or its unclear?
[15:01:04 CET] <BBB> (they hve profoundly different implications)
[15:01:06 CET] <ubitux> BBB: i see random h264 failures on THREADS=auto on fate
[15:01:15 CET] <BBB> what is THREADS=auto?
[15:01:35 CET] <ubitux> just like THREADS=8 with 8 cores
[15:01:37 CET] <BBB> so, Ive done a _ton_ of testing with threading back in the days
[15:01:37 CET] <ubitux> i guess
[15:01:49 CET] <BBB> back then, Im pretty pretty sure that I found all the bugs and fixed them all
[15:01:52 CET] <ubitux> maybe we broke it recently
[15:02:00 CET] <BBB> we had fate stations back then that continuously tested threading
[15:02:13 CET] <BBB> I went over them weekly to make sure it never had even a single breakage
[15:02:30 CET] <BBB> and I continuously ran fate on my computer with random thread counts from 2 to 32 for a day or so
[15:02:37 CET] <BBB> (frame threading only)
[15:02:41 CET] <BBB> Im pretty sure back then it was ok
[15:02:41 CET] <ubitux> http://fate.ffmpeg.org/report.cgi?time=20170120013654&slot=x86_64-archlinux-gcc-threads
[15:02:52 CET] <BBB> if it is broken now, its because of a recent merge
[15:03:07 CET] <ubitux> might be yes
[15:03:19 CET] <ubitux> but how come we don'
[15:03:26 CET] <ubitux> don't have a comment above protected fields
[15:03:28 CET] <ubitux> at least?
[15:03:42 CET] <ubitux> i mean, it's going to break often if we don't do that
[15:04:06 CET] <BBB> because the few people that know half-assedly how it works dont feel like putting in the time to do that :-p
[15:04:31 CET] <BBB> does that test fail under libav?
[15:04:34 CET] <BBB> (occasionally)
[15:04:39 CET] <BBB> or just in ffmpeg?
[15:05:32 CET] <ubitux> i don't know
[15:10:28 CET] <BBB> how reproduceable is the fate failure?
[15:10:32 CET] <BBB> is it once every 1000 times?
[15:10:35 CET] <BBB> once ever 2 times?
[15:10:39 CET] <BBB> once every 1M times?
[15:17:18 CET] <xzcvczx> when you run ./configure should it be silent to the console and only write once to config.log then just sit there appearing to do nothing?
[15:18:04 CET] <BBB> xzcvczx: I believe so, yes
[15:18:31 CET] <xzcvczx> ah, any hints as to how long the configure process can take on a crap i5?
[15:18:42 CET] <BBB> xzcvczx: although after writing config.log, it will print some stuff to stdout about the config (selected codecs/formats/filters, ext libraries, etc.)
[15:18:53 CET] <BBB> xzcvczx: depends on your host systems fork() speed
[15:19:06 CET] <xzcvczx> lol probably crap
[15:19:09 CET] <BBB> xzcvczx: on mac/linux, its pretty fast, a few seconds; on windows, it can take a good couple of hours
[15:19:18 CET] <xzcvczx> hmmm i am on mac
[15:19:30 CET] <xzcvczx> and i left it last time for at least 20mins without it completing :S
[15:19:32 CET] <BBB> that should be pretty fast, Im on a mac and it takes a few seconds at best
[15:19:37 CET] <BBB> thats not good
[15:19:53 CET] <BBB> how many cores? and what year mac?
[15:20:09 CET] <xzcvczx> 2ish years old, cheap-ass mac mini and 2 real cores
[15:20:47 CET] <BBB> I would abort it (ctrl-c) and check config.log about where it got stuck
[15:20:59 CET] <BBB> help with compiling ffmpeg should probably be in #ffmpeg though
[15:21:10 CET] <xzcvczx> mktemp -u XXXXXX \n RjvPoS
[15:21:13 CET] <BBB> but assuming its stuck, its not unreasonable to open a bug report
[15:21:18 CET] <xzcvczx> oh sorry
[15:21:29 CET] <xzcvczx> i wasn't sure whether it was considered dev or not
[15:22:36 CET] <BBB> dev is mostly for developing ffmpeg, i.e. new codecs/filters, patch discussion, that sort of stuff
[15:22:53 CET] <xzcvczx> ok will go back to #ffmpeg, thanks
[15:22:55 CET] <BBB> np
[15:53:31 CET] <ubitux> i love how get_last_needed_nal() uses "first_slice" with the following semantic: first_slice=0 ’ it is the first slice, first_slice=1 ’ it's not the first slice
[17:08:52 CET] <ubitux> michaelni: any idea what's the symptom of the green thing?
[17:09:22 CET] <ubitux> it's apparently related to the last_pic_for_ec, so error correction
[17:09:41 CET] <ubitux> but in master, it doesn't seem to be doing any particular error correction on the first frame
[17:09:50 CET] <ubitux> where the green appears after the merge
[17:13:32 CET] <ubitux> BBB: make fate-h264-attachment-631 THREADS=8 is failing almost all the time currently for me
[17:14:01 CET] <ubitux> crc mismatches every run somehow
[17:15:30 CET] <ubitux> and indeed it looks related to a fuckedup in bdbbb8f11edbf10add874508c5125c174d8939be
[17:16:51 CET] <BBB> oh wonderful, yes lets rewrite everything
[17:17:22 CET] <ubitux> merges are hard :(
[17:17:34 CET] <ubitux> this is where the kind of comment about thread safety would actually help
[17:17:37 CET] <BBB> why are we calling av_image_copy()?
[17:17:47 CET] <BBB> are we literally copying images when we output them to the user?
[17:17:50 CET] <BBB> what happened to refcounting
[17:18:15 CET] <ubitux> this is to reconstruct a stream which lacks half the fields
[17:18:20 CET] <ubitux> a weird chinese sample
[17:18:36 CET] <ubitux> it's a very special case usually not triggered 
[17:18:49 CET] <BBB> and is is_extra added but never called in that patch?
[17:19:06 CET] <ubitux> you're looking at a merge commit
[17:19:09 CET] <BBB> hm...
[17:19:27 CET] <ubitux> what you're quoting is "context diff"
[17:19:38 CET] <ubitux> code that was already present but not in libav
[17:20:08 CET] <BBB> ok
[17:21:36 CET] <BBB> I wish I could help but I have no idea what all of this means& this whole merge and context diff arent things I understand, I get patch and stuff
[17:21:55 CET] <BBB> if theres a commit 1 which works and a commit 2 which doesnt and theres a minimal patch between 1 and 2, I can probably help
[17:22:01 CET] <BBB> maybe git is too complicated for me :(
[17:22:13 CET] <mateo`> BBB: if you want to real diff, git checkout faulty-commit then git diff HEAD^
[17:22:19 CET] <mateo`> to->the
[17:22:30 CET] <ubitux> mateo` found out the problem
[17:23:03 CET] <ubitux> http://sprunge.us/RdHI
[17:23:15 CET] <ubitux> this is something we actually did in the incoming merge for another issue
[17:23:53 CET] <BBB> your debugging skills are amazing
[17:24:10 CET] <BBB> I also agree that that code is getting increasingly incomprehensible for any mortal human being
[17:24:17 CET] <BBB> Im not sure I know whether thats a fixable issue
[17:24:27 CET] <BBB> youll also reindent right?
[17:25:50 CET] <ubitux> in the next commit yes
[17:26:25 CET] <ubitux> BBB: we're on that merge commit since 2 weeks so...
[17:26:27 CET] <ubitux> :D
[17:26:40 CET] <ubitux> it's quite a learning experience about the decoder
[17:26:47 CET] <BBB> yes
[17:26:54 CET] <BBB> so uhm
[17:27:16 CET] <BBB> Id again like to raise the issue that there is a real, genuine benefit to us in moving towards a reunification with libav, or alternatively to stop merging their commits
[17:27:25 CET] <BBB> but Ill shut up again
[17:28:52 CET] <ubitux> these commits are useful/important
[17:29:05 CET] <ubitux> at least the incoming one is bringing improvement\
[17:29:13 CET] <BBB> I think a lot of the libav commits are useful
[17:29:20 CET] <BBB> so maybe they should be done in a unified tree
[17:29:26 CET] <BBB> so we dont need to waste time merging them :/
[17:29:43 CET] <ubitux> and unfortunately the ones knowing the h264 dec are not available or working on the merges
[17:29:46 CET] <ubitux> so it takes a lot of time
[17:29:47 CET] <BBB> not to mention that the webview of git is utterly useless because it shows only merge commits
[17:29:47 CET] <cone-073> ffmpeg 03Matthieu Bouron 07master:639e26297147: lavc/h264dec: make sure a slice is decoded before finishing setup
[17:29:48 CET] <cone-073> ffmpeg 03Matthieu Bouron 07master:cf3affabb449: lavc/h264dec: re-indent after previous commit
[17:29:56 CET] <ubitux> and we need to do it
[17:30:03 CET] <ubitux> because we're now 800+ commits remaining
[17:30:10 CET] <ubitux> which will takes months to merge
[17:30:16 CET] <ubitux> so.
[17:30:29 CET] <ubitux> yes of course we need to work on reunification, we were never opposed to this
[17:30:37 CET] <ubitux> and you know very well the issue like most of us
[17:30:44 CET] <ubitux> they do NOT want to, so what can we do?
[17:32:56 CET] <ubitux> mmh maybe the "fix" was a lucky one
[17:33:05 CET] <mateo`> :(
[17:34:23 CET] <j-b> it's funny when both sides say that "the other side does NOT want to reunite".
[17:36:05 CET] <ubitux> j-b: libav openly says they do not want to merge
[17:36:35 CET] <j-b> That's not true.
[17:36:57 CET] <atomnuker> its a free project, if they want to contribute to us (and some do) there's nothing stopping them
[17:37:08 CET] <BBB> atomnuker: thats insane
[17:37:12 CET] <wm4> interest in reunification and readiness to talk is significantly lower in Libav than FFmpeg
[17:37:35 CET] <j-b> wm4: that is totally not true.
[17:37:42 CET] <BBB> Donald Trump: if democrats want to work on making America Great Again with us republicans, theyre free to do so, were a free country and an open party
[17:37:48 CET] <j-b> wm4: I'd argue the opposite
[17:38:18 CET] <BBB> atomnuker: to allow two parties to work together, we need a place where both want to be together
[17:39:49 CET] <wm4> j-b: how often does the topic of reunification even come up on this channel vs. theirs?
[17:40:18 CET] <wm4> on libav there's only apathy
[17:41:02 CET] <j-b> maybe because you are not on the right channels
[17:42:07 CET] <j-b> but libav people are always open to discussion, and discussed that at VDD and several times IRL, and accepted a lot of hard things and are ready to do a lot of steps
[17:43:01 CET] <j-b> Anyway, I've very happy to hear that people here want reunification. It means we'll have a solution soon.
[17:43:53 CET] <ubitux> ...everyone who did a merge at least once wants a reunification here you know
[17:43:55 CET] <ubitux> it's a not a news
[17:44:03 CET] <mateo`> What does prevent the reunification ?
[17:44:08 CET] <mateo`> IRL meetings ?
[17:44:12 CET] <ubitux> no, it happened
[17:44:28 CET] <ubitux> 2016-04-24 12:48:45     +wm4    also btw., at this point, all blame for reunification not happening can be put on Libav
[17:44:31 CET] <ubitux> sorry wm4 :3
[17:44:39 CET] <ubitux> (i don't know what was the context at this point)
[17:44:51 CET] <ubitux> i don't remember if it was before or after vdd
[17:51:30 CET] <wm4> vdd is normally at end of summer or something
[17:51:41 CET] <wm4> my thoughts about this haven't changed btw.
[17:51:51 CET] <ubitux> ok so i'm not imaginating thing
[17:51:55 CET] <wm4> maybe it's because I wasn't in any of j-b's mysterious IRL meetings
[17:51:55 CET] <mateo`> so fate-h264-attachment-631 THREADS=8 in still broken on master (despite the two commits I just pushed), sorry about this, we are working on a fix
[17:52:24 CET] <j-b> wm4: I believe I offered to come and meet you in person.
[17:52:29 CET] <j-b> wm4: I will offer the same again.
[17:53:44 CET] <wm4> you said something like this and never came back on it again
[18:12:28 CET] <michaelni> ubitux, no idea about the green
[18:14:13 CET] <BBB> ubitux: as for which fields are safe, maybe create a temporary wiki page where we can start analyzing each field and provide evidence to demonstrate what is the correct classification?
[18:14:47 CET] Action: BBB trusts that j-b will Make Multimedia Great Again
[18:15:06 CET] <j-b> BBB: is he sworn in yet?
[18:15:12 CET] <j-b> BBB: the new world president ?
[18:15:23 CET] <BBB> i have no idea what youre talking about
[18:15:42 CET] <BBB> I live in a bubble that is devoid of any form of reality
[18:15:48 CET] <BBB> it allows me to actually do stuff
[18:16:13 CET] <BBB> although Im listening to Aerodynamic by Daft Punk, which has a very appropriate opening
[18:16:32 CET] <BBB> (its church bells ringing, very dramatic)
[18:18:18 CET] <kierank> j-b: yes
[18:18:34 CET] <BBB> ubitux: if you create a wiki page and tell me what types of classifications youre looking for, I can try to help fill it in (to the best of my knowledge)
[18:20:51 CET] <michaelni> i can help too but my knowldge might be not entirely upto date with the code.
[18:21:31 CET] <BBB> michaelni: I think that goes for all of us
[18:21:31 CET] <ubitux> BBB:
[18:21:33 CET] <ubitux>     /* for frame threading, this is set to 1
[18:21:35 CET] <ubitux>      * after finish_setup() has been called, so we cannot modify
[18:21:37 CET] <ubitux>      * some context properties (which are supposed to stay constant between
[18:21:39 CET] <ubitux>      * slices) anymore */
[18:21:41 CET] <ubitux>     int setup_finished;
[18:21:52 CET] <ubitux> the classification i need: what is "some context properties" here
[18:21:54 CET] <ubitux> that's all
[18:22:32 CET] <BBB> ubitux: I dont think I can give a five-minute answer, itll take several hours or days to define exactly
[18:23:13 CET] <ubitux> that's fine with me
[18:23:14 CET] <ubitux> :)
[18:23:28 CET] <ubitux> 6 months is better than never
[18:23:40 CET] <BBB> so you want to know: which context properties cannot be modified after setup_finished is called
[18:23:50 CET] <ubitux> yes
[18:24:07 CET] <BBB> (& because the next frame already copied them at that point, which is what setup_finished() does)
[18:29:41 CET] <michaelni> ff_h264_update_thread_context() does the copy, looking at it should ... in theory provide a list of fields 
[18:30:32 CET] <BBB> yeah thats probably easiest
[18:31:17 CET] <BBB> basically all of h->ps, all the pictures and refs, mmco, poc, and sizes
[18:31:24 CET] <BBB> I think thats roughly it
[18:47:27 CET] <ubitux> if i look at ff_h264_update_thread_context(), it looks like almost every field is getting involved
[18:47:43 CET] <ubitux> like, if you follow every write in h264_slice_header_init() etc
[18:47:55 CET] <ubitux> maybe the question should become: what fields can be modified
[18:47:58 CET] <ubitux> +?
[18:48:40 CET] <ubitux> also, some fields in avctx gets updated
[18:59:26 CET] <BtbN> hm, I wonder if one can do multiple coverity runs into the same cov-int dir, and then send that in as one build.
[19:00:19 CET] <BtbN> actually, nevermind. We're already at 40 minutes for the travis builds. No way another build will fit in there.
[19:07:23 CET] <BBB> ubitux: slice_header_init() is called on h, not h1, so I think thats fine and not relevant
[20:11:36 CET] <kierank> atomnuker: are you happy trump is president?
[21:16:47 CET] <Compn> funny enough
[21:17:18 CET] <Compn> j-b and wm4 are both correct
[21:19:32 CET] <Compn> wonder if there is still trade embargo on IRL meetings...
[21:19:34 CET] <Compn> probably yes
[21:19:43 CET] <Compn> vlc has the best walls
[21:20:35 CET] <Chloe> The issue with ffmpeg is no one wants to drop useless features 
[21:20:49 CET] <Chloe> Or, not enough people
[21:21:15 CET] <Compn> never enough people :)
[21:58:57 CET] <durandal_1707> Chloe: there are useless features?
[21:59:44 CET] <wm4> he means harmful antifeatures
[22:00:02 CET] <wm4> which make things worse instead of better
[22:13:45 CET] <Compn> probably just talking about lowres
[22:13:54 CET] <Compn> does that one commercial cutting project still use lowres ?
[22:35:32 CET] <iive> hasn't lowres been removed from most codecs?
[22:49:08 CET] <Compn> sshhh no
[00:00:00 CET] --- Sat Jan 21 2017