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

[burek]

[01:49:11 CEST] <cone-348> ffmpeg 03Michael Niedermayer 07master:d65b59550b4d: avcodec/avcodec: Correct and make consistent AVERROR() in comments
[09:37:12 CEST] <cone-047> ffmpeg 03Kyle Swanson 07master:b12693facf99: libavcodec/opusenc: use correct format specifiers
[10:32:08 CEST] <ubitux> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80208
[10:33:44 CEST] <nevcairiel> is djgpp an actual gnu thing, sounded like somewhat of a modified gcc fork
[10:34:07 CEST] <ubitux> they have a djgpp file :p
[10:34:20 CEST] <ubitux> dunno exactly how djgpp fit within gcc 
[10:35:15 CEST] <ubitux> ok, now after that 4cc patchset, i can go back to fixing the djgpp warnings and then the merge
[10:35:17 CEST] <ubitux> what a ride.
[10:41:35 CEST] <ismail> djgpp port is more or less maintained.
[10:42:29 CEST] <ubitux> it works with a mainstream gcc at least
[11:08:45 CEST] <ubitux> btw, fun thing: the split of vp9 decoder is mandatory for djgpp support :3
[11:08:52 CEST] <JEEB> :D
[11:08:57 CEST] <JEEB> avx2 etc?
[11:09:06 CEST] <nevcairiel> is the file too big? :D
[11:09:12 CEST] <ubitux> file is too big yes :)
[11:09:21 CEST] <ubitux> /usr/lib/gcc/i686-pc-msdosdjgpp/6.1.0/../../../../i686-pc-msdosdjgpp/bin/as: libavcodec/vp9.o: /45: reloc overflow: 0x2096e > 0xffff
[11:09:36 CEST] <ubitux> so i hope BBB figures out something with elenril soon
[11:09:45 CEST] <ubitux> or i'll have to apply :)
[11:10:19 CEST] <JEEB> hah :D
[11:10:23 CEST] <ubitux> ok so i'm at 3+10+1 patch for djgpp support, one big remaining and we're good to go
[11:10:36 CEST] <ubitux> and merges can continue
[11:27:04 CEST] <mateo`> is it known that the mpeg2video encoder output has different outputs whether direct rendering is enabled or not ?
[12:27:15 CEST] <durandal_1707> ubitux: since when freedos support is mandatory?
[12:27:26 CEST] <ubitux> durandal_1707: git grep -i djgpp
[12:27:39 CEST] <ubitux> it was supported for a while, it isn't anymore
[12:28:01 CEST] <ubitux> it helps spotting warnings too
[12:28:48 CEST] <ubitux> BBB: ping
[12:52:17 CEST] <BBB> ubitux: pong
[12:52:39 CEST] <BBB> ubitux: I asked elenril btw, and he said we can hold off for a while (unless we actively want to sync towards their version) since the re-split of our vp9 is still in his queue
[12:52:40 CEST] <ubitux> BBB: i need to move on with the split, it prevents the compilation with djgpp
[12:52:45 CEST] <BBB> (queue being todo list)
[12:52:55 CEST] <ubitux> ah great
[12:53:08 CEST] <BBB> sorry I didnt say that earlier, I didnt want to hold you up :(
[12:53:19 CEST] <ubitux> /usr/lib/gcc/i686-pc-msdosdjgpp/6.1.0/../../../../i686-pc-msdosdjgpp/bin/as: libavcodec/vp9.o: /45: reloc overflow: 0x2096e > 0xffff
[12:53:24 CEST] <ubitux> this was the error if you're curious :)
[12:53:30 CEST] <ubitux> splitting the file fixes the compilation
[12:53:33 CEST] <BBB> &
[12:53:36 CEST] <ubitux> :D
[12:53:43 CEST] <BBB> workaround"
[12:53:49 CEST] <BBB> ok, so strange
[12:53:59 CEST] <ubitux> that's legit, it's large :)
[12:54:00 CEST] <BBB> is vp9.o the biggest file in our tree?
[12:54:46 CEST] <BBB> oh it is
[12:54:56 CEST] <BBB> it beats motion_est by a percent or so
[12:55:12 CEST] <BBB> also worrying, no. 4 is vp8.o :-o
[12:55:33 CEST] <ubitux> :)
[12:56:01 CEST] <BBB> Ill go stand in the non-developer-corner-of-shame for a while and think about what Ive done
[12:56:08 CEST] <ubitux> haha
[12:56:31 CEST] <ubitux> so anyway, i'll rework my vp9 branch with your comments from the other day and poke you again
[12:57:49 CEST] <wm4> still no review of this frame threading fix on libav-devel
[12:57:56 CEST] <wm4> I guess I'll push the ffmpeg one
[12:58:47 CEST] <ubitux> wm4: will that make tsan happy?
[12:59:07 CEST] <wm4> I don't know? but likely
[12:59:13 CEST] <ubitux> nice
[12:59:15 CEST] Action: ubitux impatient
[12:59:26 CEST] <ubitux> BBB: motion_est is small here
[12:59:27 CEST] <wm4> I'll also push my rotation patch
[13:00:07 CEST] <ubitux> BBB: this is my ranking: http://sprunge.us/SQfQ
[13:01:18 CEST] <BBB> ubitux: strange& must be a compiler debug difference
[13:01:31 CEST] <BBB> ubitux: I bet w/o debug symbols wed get more even results
[13:01:42 CEST] <BBB> anyway& thinking of vp9 split
[13:01:56 CEST] <BBB> if djgpp is a priority for you, I can poke elenril and we can work on the split in ffmpeg
[13:02:08 CEST] <BBB> (if were going to split anyway and in the same way, it doesnt matter in which tree the split originates)
[13:02:22 CEST] <BBB> then after that we can apply the oher patches on top of that
[13:02:53 CEST] <BBB> is that helpful?
[13:05:33 CEST] <durandal_1707> whats different with dnxhr 444 quantization versus dnxhd one?
[13:06:35 CEST] <ubitux> BBB: i'm fine with re-adjusting the split afterwards
[13:06:45 CEST] <ubitux> apply current split to match current libav
[13:06:47 CEST] <durandal_1707> it have smthing different when decoding, trying to guess similar with encoding
[13:06:53 CEST] <ubitux> then apply another split to match a potential new split
[13:07:22 CEST] <ubitux> BBB: if he didn't start anything, reducing the differences ourselves will help them
[13:22:32 CEST] <cone-883> ffmpeg 03wm4 07master:ddef3d902f0e: avformat, ffmpeg: deprecate old rotation API
[13:22:32 CEST] <cone-883> ffmpeg 03wm4 07master:9e703ae30f91: pthread_frame: do not attempt to unlock a mutex on the wrong thread
[13:22:32 CEST] <cone-883> ffmpeg 03wm4 07master:d7896e9b4228: pthread_frame: fix uninitialized variable read
[13:23:25 CEST] <ubitux> wm4: thanks :)
[13:23:56 CEST] <wm4> async_mutex is now a leaf lock, so I doubt it triggers tsan
[13:24:06 CEST] <ubitux> we'll see
[13:31:37 CEST] <uau> wm4: you applied the mutex commit without the commit message or broadcast->signal changes?
[13:32:03 CEST] <wm4> uau: oops, yes
[13:33:24 CEST] <wm4> uau: what do you mean "commit message"
[13:33:52 CEST] <uau> as for the "uninitialized variable" commit, i don't understand why you talk about "possibly due to 32a5b" - it was your merge commit that caused the problem (as already mentioned before)
[13:34:03 CEST] <uau> what i said about the commit message on libav-devel
[13:34:16 CEST] <wm4> uau: I see no mail from you
[13:34:45 CEST] <wm4> commit 32a5b didn't "cause" the problem, but it interacted badly with the merge
[13:34:57 CEST] <uau> i mean on irc (and you replied "ok about the commit msg")
[13:35:05 CEST] <wm4> well easy to forget
[13:35:14 CEST] <wm4> what did you say about the commit msg?
[13:35:28 CEST] <uau> <uau> wm4: about the commit message: "has is used", "It's not allowed" probably better as "That's not allowed" ("that" referring to a larger part of previous sentence), "a mutex and condition variable"->"a mutex and a condition variable"
[13:36:15 CEST] <uau> as for "interacted badly", it looked like it must have required manual conflict resolution, and that's where the error was introduced
[13:36:38 CEST] <wm4> sure, I'm not denying it
[13:38:45 CEST] <durandal_1707> anyone understands how dct works?
[13:41:19 CEST] <nevcairiel> yeah should probably change that to signal instead of broadcast, makes no sense to wake all threads just so all b ut one go to  sleep again
[13:44:35 CEST] <atomnuker> durandal_1707: page 496 of "The Scientist and Engineer's Guide to Digital Signal Processing"
[13:45:47 CEST] <durandal_1707> atomnuker: yeah, but for dnxhd versus dnxhr 444
[13:46:35 CEST] <durandal_1707> they use some other numbers slightly different
[13:46:51 CEST] <wm4> atomnuker: is there an online copy of this book
[13:46:52 CEST] <durandal_1707> so i get blocky video
[13:47:36 CEST] <BBB> ubitux: so, I think that if we split by their current split, they will not re-split
[13:47:51 CEST] <BBB> ubitux: in other words, we have to review their split as the proposed split if we go with that, assuming they will not re-split
[13:48:03 CEST] <ubitux> ooh
[13:48:32 CEST] <ubitux> well, then, we split to match libav, and then we add another potential split if needed
[13:48:36 CEST] <ubitux> it will be easier for them to import
[13:48:40 CEST] <ubitux> (and simpler for :D)
[13:49:05 CEST] <BBB> or we can bug the djgpp devs to fix their software
[13:49:21 CEST] <ubitux> i don't think it's a problem with djgpp
[13:49:30 CEST] <ubitux> but a limitation of the object format
[13:49:57 CEST] <ubitux> you don't like the split?
[13:50:17 CEST] <BBB> I dont know, I never reviewed it ;)
[13:50:29 CEST] <BBB> Ill look at the patch, you have a link?
[13:50:32 CEST] <durandal_1707> github.com/richardpl/FFmpeg/tree/dnxhd  -> latest work
[13:50:59 CEST] <BBB> I honestly think if we apply their split, well be stuck with it unless we make changes ourselves, elenril wont make additional changes if we integrate their split
[13:51:09 CEST] <ubitux> BBB: https://github.com/ubitux/FFmpeg/compare/vp9sync first commit
[13:51:11 CEST] <BBB> (which may be ok, but changes expectations)
[13:51:14 CEST] <BBB> okay, checking
[13:51:32 CEST] <ubitux> i'm fine with adjusting the split, but ideally on top of this
[13:51:47 CEST] <BBB> so vp9 -> vp9 + prob + mvs + block, right?
[13:51:59 CEST] <durandal_1707> atomnuker: try that one, it creates nice effect
[13:52:04 CEST] <ubitux> + dsp (except the header which ends up in vp9.h)
[13:52:27 CEST] <ubitux> and + data too (.c, not .h)
[13:52:54 CEST] <BBB> we already had dsp and data
[13:52:59 CEST] <BBB> they shouldnt change much
[13:53:13 CEST] <ubitux> it ends up in a .c instead of a .h
[13:53:14 CEST] <BBB> oh you split vp9data.h into vp9data.c?
[13:53:19 CEST] <BBB> oh right of course
[13:53:28 CEST] <ubitux> btw, i forgot "prob" in the commit message
[13:54:20 CEST] <atomnuker> wm4: its a free book actually (http://www.dspguide.com/pdfbook.htm) (http://ft-sipil.unila.ac.id/dbooks/The%20Scientist%20and%20Engineer%27s%20Guide%20to%20Digital%20Signal%20Process.pdf)
[13:55:07 CEST] <wm4> nice
[13:56:37 CEST] <BBB> so this commit merges vp9dsp.h into vp9.h
[13:56:44 CEST] <BBB> thats a pretty seriously bad idea design-wise
[13:57:17 CEST] <BBB> vp9dsp is a software only thing, vp9.h is the interface through which we share vp9 as a bitstream parser and a decoder interface between the software decoder and hwaccel implementations
[13:58:04 CEST] <BBB> so we would really need 2 or 3 header files, vp9.h as that interface, a separate one as the interface of the software-only decoder (which depends on vp9.h), and then optionally the third being the dsp-specific parts of this interface, which is whats currently in vp9dsp.h
[13:58:17 CEST] <BBB> and the second one would obviously depend on the first and (optionally) third
[13:58:53 CEST] <BBB> the advantage of splitting vp9dsp.h into its own interface is that the dsp implementation bits dont depend on the full software decoder interface header file, but only the dsp-specific parts of it
[13:59:13 CEST] <BBB> (and you could go one step further into h264 territory and split the dsp into bits; the asm is already split, so only the c needs splitting)
[13:59:34 CEST] <ubitux> BBB: yes, i don't like the merge into vp9dsp, but keeping the split was a real pain for the following unification
[13:59:41 CEST] <ubitux> into vp9.h*
[14:00:05 CEST] <durandal_1707> atomnuker: any ideas?
[14:00:08 CEST] <ubitux> we could split it out again at the end
[14:00:28 CEST] <BBB> if we just split ourselves, without their baseline
[14:00:35 CEST] <BBB> is that worse from your perspective as merger?
[14:01:05 CEST] <nevcairiel> if things are split differently then that'll make merging  annoying if they change anything in vp9 later on
[14:01:54 CEST] <ubitux> BBB: my main problems are the 8 commits that shuffle spaces, names and positions
[14:01:59 CEST] <ubitux> which comes after that split
[14:02:13 CEST] <ubitux> basically that split is a ground for diffing properly and reducing diffs
[14:02:15 CEST] <atomnuker> durandal_1707: do you have the specs (or can you request the specs)?
[14:02:18 CEST] <BBB> nevcairiel: theyve said theyll merge our version
[14:02:24 CEST] <ubitux> if i have to adjust it, everything crumble on top
[14:02:31 CEST] <nevcairiel> BBB: and you believed them? :)
[14:02:39 CEST] <ubitux> and i have to redo everything (which i'll be honest, won't do again)
[14:02:41 CEST] <BBB> nevcairiel: do I have an alternative?
[14:02:56 CEST] <BBB> ubitux: what if I do the stuff after that also?
[14:03:22 CEST] <BBB> ubitux: and then Ill see if I can get elenril to merge our version after that to re-unify it again
[14:03:30 CEST] <ubitux> BBB: oh well, sure, take tne branch and adjust everything you want in it :)
[14:03:45 CEST] <ubitux> but TBH it's a better approach to rework on top
[14:03:49 CEST] <ubitux> if we plan to move things
[14:04:13 CEST] <ubitux> it will also simplify merges from libav side, and will actually help being imported
[14:04:56 CEST] <ubitux> i'll undo the tree indent and various others you point out
[14:05:12 CEST] <ubitux> but i won't touch the "architectural" split of the first commit
[14:05:17 CEST] <ubitux> feel free too though
[14:05:30 CEST] <durandal_1707> atomnuker: there are only decoder specs
[14:05:35 CEST] <ubitux> (but beware you'll loose or have to redo all kind of the spaces shuffling)
[14:06:47 CEST] <durandal_1707> spaces saga yet again
[14:08:31 CEST] <durandal_1707> atomnuker: if i change decoder to use other dct stuff it works as expected, so just need to figure what to change in dct quantization
[14:09:44 CEST] <BBB> ubitux: understood, Im checking it
[14:09:58 CEST] <BBB> ubitux: I agree we dont want to re-do work for no reason
[14:11:11 CEST] <BBB> ubitux: in the vp9.c split, you said as far as you knew, there were no cosmetic changes in any part, right? did you verify that when importing the patch? or did you do the actual split yourself?
[14:11:30 CEST] <ubitux> i redid the split myself
[14:11:34 CEST] <BBB> (Im asking because decode_sb() isnt diffing correctly, and Im wondering if thats because of cosmetic changes or because githubdiff sucks)
[14:11:59 CEST] <ubitux> i looked where things were split and moved them the same way
[14:12:14 CEST] <ubitux> mmh, what kind of diff?
[14:12:21 CEST] <ubitux> are you sure it's not because of the following commits?
[14:12:50 CEST] <ubitux> it's probable that after the split i used vimdiff to correct a few spacing, but IIRC i did that in later commits
[14:13:08 CEST] <ubitux> but i'm sure i have not taken code from the libav state tree
[14:13:09 CEST] <BBB> Im looking at https://github.com/ubitux/FFmpeg/commit/f2723179b14d0e8df41974410f49973578fc7006#diff-73b2f06f81e7f6cdc34af712153ea2f2
[14:13:14 CEST] <atomnuker> durandal_1707: your dc looks fine, though your colors look off
[14:13:25 CEST] <BBB> and then click to load, and search for decode_sb
[14:13:28 CEST] <atomnuker> (why does the decoder output grbp10)?
[14:13:41 CEST] <BBB> I think they look identical before/after, but it doesnt diff correctly; I think githubdiff just sucks
[14:14:07 CEST] <ubitux> let me check
[14:14:14 CEST] <durandal_1707> atomnuker: use gbrp10 , i have to add flag to signal yuv
[14:14:42 CEST] <durandal_1707> in both header annd per block
[14:17:33 CEST] <ubitux> BBB: http://sprunge.us/BISP
[14:17:48 CEST] <durandal_1707> atomnuker: you see blocky artifacts?
[14:17:53 CEST] <BBB> ok so its githubdiff
[14:17:55 CEST] <BBB> thnx
[14:18:06 CEST] <ubitux> BBB: just reconstructed that manually
[14:18:11 CEST] <ubitux> and gave me that
[14:18:29 CEST] <ubitux> never trust github
[14:19:02 CEST] <BBB> so in terms of what makes things easier for you& do you want me to fix up the bugs that I see in each commit and hand you better patches? or do you want me to take the tree and work on top of it with new patches to fix up things I dont like?
[14:19:45 CEST] <BBB> things I plan to do are: split the dsp interface back into its own file (this should undo the vp9dsp.h -> vp9.h changes in most simd/dsp files)
[14:19:54 CEST] <ubitux> BBB: when do you want to do that? if you wait a few hours, i'll integrate the changes you wanted me to revert; then you can reconstruct the whole branch the way you see fit
[14:20:10 CEST] <BBB> I can wait, Im not in a hurry
[14:20:15 CEST] <BBB> Im trying to help :)
[14:20:26 CEST] <BBB> so Ill do it when its helpful
[14:21:07 CEST] <ubitux> i'd recommend splitting back the vp9dsp.h on top, it's really too sensible to changes that came later
[14:21:15 CEST] <ubitux> having it on top will help being imported in libav
[14:21:26 CEST] <ubitux> because we really want them to integrate it
[14:21:37 CEST] <ubitux> otherwise it will be a pain yet again to diffing the two projects
[14:21:53 CEST] <BBB> then the second thing Id like to do is that I notice in your tree that pre-split, vp9.o is 4MB, but post-split, block.o is only 1MB, and the other files are tiny (~100kb each), so vp9.o would still be 2.75MB or so& it may make sense to split more parts out of it, e.g. the header reading and the loopfilter bits
[14:22:16 CEST] <ubitux> yeah splitting the lpf could be nice
[14:22:21 CEST] <ubitux> again, i'd do that on top
[14:22:37 CEST] <ubitux> especially as it's not "incompatible" with the previous split afaict
[14:22:42 CEST] <BBB> correct
[14:22:55 CEST] <BBB> ok lets do it after then, why not
[14:23:27 CEST] <BBB> Ill probably need some help verifying I did all the bits correctly in the non-x86 simd files to fix the vp9.h->vp9dsp.h includes
[14:24:01 CEST] <BBB> (and also make sure I didnt break the hardware decoding interface)
[14:26:56 CEST] <BBB> you said youd fix the 32x32 zigzag scan and tree cosmetic changes right?
[14:28:15 CEST] <BBB> thats all major comments I have, the rest is all personal like/dislike
[14:29:36 CEST] <ubitux> BBB: yes i'll do that
[14:29:36 CEST] <mateo`> I will port the examples to codecpar and the new decoding,encoding API in the upcoming days
[14:29:58 CEST] <wm4> wasn't there someone who wanted to post completely new examples?
[14:30:43 CEST] <BBB> ubitux: ok, poke me when your tree is updated w/ that and Ill do the 2 things I pointed out (re-introduce vp9dsp.h as an interface/split hardware decoding interface from software decoding interface, and split out lpf/header reading also)
[14:31:46 CEST] <ubitux> i'll try to do that this afternoon, otherwise when i get home tonight
[14:31:56 CEST] <mateo`> wm4: I don't know
[14:32:49 CEST] <ubitux> it's probably additionnal examples
[14:32:49 CEST] <atomnuker> durandal_1707: I do, that's why I said your DCs look okay (but your ACs do not)
[14:33:26 CEST] <durandal_1707> ah, thanks
[14:33:50 CEST] <mateo`> ubitux: you sure ? :p
[14:34:06 CEST] <ubitux> ask him, "faLUCE"
[14:35:58 CEST] <mateo`> he's not on irc atm, i'll start porting the examples one by one (after i've confirmed the output of the mpeg2video encoder changes if "direct rendering" is enabled)
[14:39:04 CEST] <BtbN> I still think that guy is an elaborate troll.
[14:40:35 CEST] <wm4> well he's not here
[14:42:00 CEST] <BtbN> I'm not sure if I even want to see his C++ wrapper.
[15:12:22 CEST] <BBB> ubitux: about valgrind error: https://bugs.kde.org/show_bug.cgi?id=375839#c4 (--vex-guest-max-insns=25)
[15:12:44 CEST] <BBB> ubitux: the default value is 50, lower values make it slower but reduce the chance of that error
[15:13:10 CEST] <ubitux> oh, ok
[15:13:12 CEST] <ubitux> i'll try
[15:13:19 CEST] <ubitux> thanks
[15:13:35 CEST] <BBB> its a known bug, not yet fixed, that option is just a workaround
[15:13:56 CEST] <ubitux> yeah i understand :)
[15:14:03 CEST] <ubitux> wm4: 2469 ’ 2816 fate tests passing with tsan :)
[15:14:05 CEST] <ubitux> thanks
[15:14:15 CEST] <ubitux> http://fate.ffmpeg.org/report.cgi?time=20170327125234&slot=x86_64-archlinux-gcc-tsan
[15:15:16 CEST] <ubitux> and vp9 not present in the list
[15:15:22 CEST] <ubitux> h264 is though
[15:15:46 CEST] <ubitux> BBB: if you're interested in threading issues, the tsan reports looks accessible :)
[15:15:51 CEST] <ubitux> much much less noise
[15:15:59 CEST] <BBB> I can check
[15:16:04 CEST] <BBB> vp9 no longer there?
[15:16:26 CEST] <ubitux> yup :)
[15:16:58 CEST] <BBB> is libavfilter threading safe at the "core"?
[15:17:00 CEST] <ubitux> i wonder if we have an issue with the filters
[15:17:10 CEST] <BBB> hehe we thought the same issue ;)
[15:17:21 CEST] <ubitux> we probably should use atomics somewhere in
[15:17:35 CEST] <BBB> it also looks like size changes in various decoders cause issues
[15:17:37 CEST] <ubitux> it may fix a large amount of reports as well
[15:22:34 CEST] <BBB> the h264 ones seem to come from this code in output_frame():
[15:22:35 CEST] <BBB>     h->avctx->width   = dst->width;
[15:22:36 CEST] <BBB>     h->avctx->height  = dst->height;
[15:22:37 CEST] <BBB>     h->avctx->pix_fmt = dst->format;
[15:22:49 CEST] <BBB> that does honestly look very questionable, Im pretty sure that doesnt belong there, at least not w/ threading enabled
[15:23:05 CEST] <BBB> possibly you need it w/o threading or for hwaccel, but certainly not w/ threading
[15:23:19 CEST] <BBB> I can try removing it and see if that helps
[15:23:26 CEST] <BBB> (as in: doesnt break anything)
[15:31:15 CEST] <BBB> ubitux: https://pastebin.com/peba6whz
[15:31:21 CEST] <BBB> ubitux: that should fix a couple of the h264 ones
[15:31:40 CEST] <BBB> it works single-threaded and w/ frame-threads
[15:32:26 CEST] <BBB> Ill submit a patch
[15:34:58 CEST] <nevcairiel> i'm sure there is some reason for that code
[15:35:04 CEST] <nevcairiel> even if its crazy
[15:35:31 CEST] <BBB> oh crap
[15:35:31 CEST] <BBB> 1189af429211ac650aac730368a6cf5b23756605
[15:35:39 CEST] <BBB> who on earth OKed that patch?
[15:35:42 CEST] <BBB> that is fundamentally wrong
[15:35:58 CEST] <BBB> that patch has to be reverted for the tsan warnigns to go away
[15:37:40 CEST] <nevcairiel> see, there was some crazy reason
[15:37:41 CEST] <nevcairiel> :D
[15:46:08 CEST] <ubitux> :)
[15:46:28 CEST] <ubitux> BBB: i'm always happy to see threading issues getting killed so we can rely on these tools
[15:50:38 CEST] <BBB> the hevc one looks very strange
[15:51:57 CEST] <ubitux> the lavfi race looks related to the threads returns code
[15:52:33 CEST] <BBB> yeah I cant quite bring the hevc one down to something simple
[15:52:41 CEST] <BBB> it looks like a properly synced header variable to me
[15:53:02 CEST] <BBB> its probably a multi-slice thing
[15:53:10 CEST] <BBB> yeah its multi-slice
[15:54:11 CEST] <BBB> no_rasl_output_flag needs to be handled in the same way as nal_unit_type <> first_nal_type
[15:54:21 CEST] <BBB> I can try to cook up a patch for that
[15:56:57 CEST] <BBB> see ML
[15:57:15 CEST] <BBB> any other interesting codecs?
[15:58:30 CEST] <BBB> the dirac one looks relatively trivial
[15:58:39 CEST] <BBB> it just needs a pthread_once for global tables
[15:58:46 CEST] <BBB> whats our convention on pthread_once?
[16:00:09 CEST] <BBB> aha, avonce
[16:00:45 CEST] <wm4> is this about codec init? we mark confirmed "safe" codecs with a flag
[16:01:05 CEST] <wm4> so you should look at anything without that flag, and if it's trivially safe, send a patch that sets it
[16:09:10 CEST] <BBB> wm4: ok done
[16:10:25 CEST] <BBB> I dont see any other interesting codecs& maybe rv3/4 and mpeg4? but the mpeg4 ones seem specifically related to size changes
[16:10:35 CEST] <BBB> xvid is there too I guess& maybe michaelni wants to do those
[16:11:16 CEST] <wm4> I think mpegvideo code has multiple of such tables all over the place? dunno
[16:11:35 CEST] <BBB> oh rv3/4 is the same as mpeg4
[16:11:50 CEST] <BBB> theyre both writing to the qscale tables during regular frame decoding
[16:12:05 CEST] <BBB> why is that a race though?
[16:12:28 CEST] <wm4> (hm maybe we're talking about different things so I'll shut up)
[16:12:51 CEST] <BBB> wm4: the threadsafe table init was dirac, I already sent a patch for that
[16:12:55 CEST] <BBB> this is another race
[16:13:02 CEST] <BBB> (I still dont know if its a race or not)
[16:15:54 CEST] <BBB> yeah Im going to leave that to michaelni, this is mpegvideo internals and I really dont want to go there
[16:16:11 CEST] <BBB> (it has its own version of AVFrame which is not synchronized between frame threads)
[16:16:28 CEST] <BBB> (but it does share data)
[16:16:39 CEST] <BBB> (you can probably imagine how awesome that works with threading enabled)
[16:22:26 CEST] <BBB> dnxhd/r is intra-only right?
[16:23:27 CEST] <BBB> some of the intra-only errors come from the fact that we sync variables (for inter purposes) between threads, whereas intra just ignores that entirely and overwrites it outside any scope
[16:23:36 CEST] <BBB> maybe the syncing should be disabled for intra-only since it is useless anyway
[16:23:53 CEST] <BBB> (in pthread_frame.c:update_context_from_thread()
[16:24:07 CEST] <BBB> that would fix the dnxhr errors and possible other intra-only codecs also
[16:43:25 CEST] <BBB> nevcairiel: aha
[16:43:27 CEST] <BBB> nevcairiel: I see now
[16:43:33 CEST] <BBB> nevcairiel: you actually blocked that patch
[16:43:37 CEST] <BBB> nevcairiel: but it was applied anyway
[16:43:52 CEST] <BBB> nevcairiel: michaelni also had concerns
[16:43:59 CEST] <BBB> nevcairiel: so I have no idea how that got in
[16:44:15 CEST] <BBB> there is no explicit approval for that patch in the thread
[16:57:52 CEST] <ubitux> BBB: pthread functions are checked in lavu/thread.h with assert level > 1
[16:58:12 CEST] <BBB> I just copied avonce from h264dec.c
[16:58:25 CEST] <BBB> I can remove the check if its unwanted, but then we should probably fix h264dec also
[16:58:27 CEST] <ubitux> if they fail, you're going to have a bad time anyway (not sure there is any clean way of handling pthread errors)
[16:58:40 CEST] <wm4> some code checks ff_thread_once, some doesn't
[16:58:42 CEST] <BBB> pthread fail is like malloc fail
[16:58:49 CEST] <wm4> not really
[16:58:54 CEST] <wm4> malloc can reasonably fail
[16:59:00 CEST] <wm4> those pthread calls not
[16:59:40 CEST] <ubitux> i have the feeling trying to handle pthread errors is likely to end up in a deadlock 
[17:00:19 CEST] <ubitux> but i guess it depends on which errors
[17:00:31 CEST] <ubitux> which funcs*
[17:00:46 CEST] <wm4> I don't think trying to handle _lock/_unlock would result in meaningful or maintainable code
[17:00:54 CEST] <wm4> other than calling abort()
[17:07:38 CEST] <BBB> your call
[17:07:48 CEST] <BBB> if you want me to not check avonce failures, Ill remove it
[17:07:55 CEST] <BBB> if you dont care, I wont care either ;)
[17:10:49 CEST] <BBB> oh h264 has some more issues
[17:15:54 CEST] <wm4> it's up to you, I'm just saying that if you do it more often, you don't need to bother with an error path
[17:16:10 CEST] <BBB> sounds like youd prefer me to remove it&? :)
[17:16:39 CEST] <wm4> maybe not... I'm trying to reduce your potential workload, not make it larger (sorry)
[17:16:59 CEST] <BBB> Im ok, ubitux sounds like hes busy
[17:22:03 CEST] <BBB> so Im guessing h264 refs cant change between slices in the same frame right?
[17:22:15 CEST] <BBB> in terms of dropped refs etc.
[17:22:17 CEST] <BBB> that would be silly
[17:22:42 CEST] <ubitux> i was just pointed out the assert in pthread, i don't mind the check staying there :p
[17:22:47 CEST] <ubitux> pointing*
[17:34:34 CEST] <mateo`> if I want to preserve the frame rate of a stream while transcoding, is it OK to copy inv(input_stream->r_frame_rate) to encoder->time_base ?
[17:34:46 CEST] <mateo`> or avg_frame_rate ?
[17:36:20 CEST] <rcombs> FreeBSD's pthread_mutex_lock can fail with ENOMEM if the mutex is initialized with PTHREAD_MUTEX_INITIALIZER; I _think_ in other cases it's guaranteed to succeed (assuming you don't hit one of the actual error conditions)
[17:37:14 CEST] <rcombs> so, avoid PTHREAD_MUTEX_INITIALIZER, and check the return value of pthread_mutex_init (since that can also ENOMEM there)
[17:37:23 CEST] <rcombs> (why the fuck are their mutexes heap objects)
[17:44:21 CEST] <nevcairiel> BBB: i dont remember 2015 off-hand, sorry :)
[17:44:26 CEST] <nevcairiel> but sounds like something i might do
[17:48:16 CEST] <wm4> rcombs: only reason I can think of is isolating ABI
[17:48:26 CEST] <wm4> if those really are just mallocs
[17:52:58 CEST] <rcombs> technically it's calloc but yeah
[18:15:22 CEST] <durandal_1707> atomnuker: whats wrong with ac in my patch?
[18:16:18 CEST] <atomnuker> it looks like its 0, hence why its blocky
[18:20:58 CEST] <atomnuker> going to push the af_asyncts removal patch soon, forgot about it
[19:05:50 CEST] <durandal_1707> atomnuker: if i store multiplied qscale by 2 in bitstream it works great
[19:06:15 CEST] <durandal_1707> what should i do instead?
[19:06:24 CEST] <atomnuker> works great == works?
[19:07:01 CEST] <durandal_1707> yes, expect bottom pixels because of odd height
[19:07:52 CEST] <atomnuker> odd, so the coefficients end up being alot smaller due to the increased quantizer for 444?
[19:09:55 CEST] <durandal_1707> they are different, dnxhr: 444 and hqx uses different params from dnxhd
[19:10:50 CEST] <durandal_1707> see dnxhddec in decode dct block
[19:11:22 CEST] <atomnuker> okay, so you're doing 2x the hqx params or 2x the dnxhd params?
[19:11:46 CEST] <atomnuker> if its the latter then there's no problem and everything is as it should be
[19:12:04 CEST] <atomnuker> if 444 and hqx are meant to have the same params but don't then there's something wrong
[19:17:19 CEST] <durandal_1707> atomnuker: 444 and hqx are just dnxhr profiles
[19:17:42 CEST] <durandal_1707> they are extending dnxhd codec
[19:18:45 CEST] <durandal_1707> im trying to find where to multiply by 2
[19:19:49 CEST] <atomnuker> if it looks right and doesn't break anything then it probably is correct
[19:24:12 CEST] <durandal_1707> i dont like it, so i found another way
[19:30:52 CEST] <ubitux> BBB: i updated my branch
[19:30:56 CEST] <BBB> cool
[19:31:01 CEST] <ubitux> i restored the tree and the correct layout for the 32x32 scan
[19:31:10 CEST] <ubitux> i'll check the backlog from yesterday
[19:31:22 CEST] <ubitux> i think there was other thing you wanted me to correct
[19:31:28 CEST] <BBB> no that was it
[19:31:31 CEST] <BBB> I think
[19:31:46 CEST] <ubitux> i'll check anyway :)
[19:32:31 CEST] <cone-883> ffmpeg 03Rostislav Pehlivanov 07master:a8fe8d6b4a35: lavfi: remove af_asynts filter
[19:32:43 CEST] <ubitux> ok seems so
[19:32:43 CEST] <BBB> hm, the trees now have duplicate indenting?
[19:32:54 CEST] <BBB> I guess that makes sense given we use 4-space indenting
[19:32:57 CEST] <ubitux> duplicate indent? you mean 4-space?
[19:33:05 CEST] <BBB> yes
[19:33:12 CEST] <BBB> it used to be 2 (I dont know why)
[19:33:13 CEST] <ubitux> yeah we use already a 4-space indent in avoption when representing const values
[19:33:23 CEST] <ubitux> so i made it consistent with that
[19:33:27 CEST] <ubitux> is it a problem?
[19:34:31 CEST] <ubitux> (at least when we do, we use 4 spaces, be it before the '{' like here, or inside)
[19:35:08 CEST] <cone-883> ffmpeg 03Rostislav Pehlivanov 07master:487ca38e8bc4: Changelog: reorder last entry
[20:17:15 CEST] <ubitux> BBB: so what's the plan? do you want to work out that branch? should i push and you work on top? do you want a few days?
[20:17:35 CEST] <BBB> Ill work on the branch
[20:18:02 CEST] <BBB> whether you apply it now or later is up to you I guess, Im not the biggest fan but what can I do right?
[20:18:24 CEST] <ubitux> i can wait if you want to work on it
[20:18:45 CEST] <ubitux> but if you only plan to work on top of it, it's probably simpler to have it upstream
[20:18:59 CEST] <ubitux> now if you want to rework the history i'll leave the branch to you and move on to something else
[20:19:17 CEST] <ubitux> do you want me to try out a resplit of the dsp?
[20:19:20 CEST] <ubitux> (on top)
[20:19:43 CEST] <BBB> I can do that
[20:19:47 CEST] <BBB> you have enough work on your plate ;)
[20:19:57 CEST] <BBB> ok you can apply and Ill work on tip of tree instead of your branch
[20:20:17 CEST] <ubitux> don't want a few hours/days to make another review?
[20:21:24 CEST] <BBB> hm ...
[20:21:30 CEST] <BBB> I dont think itll change the fundamental opinion much
[20:21:37 CEST] <BBB> well probably find some things we dont like
[20:21:43 CEST] <BBB> but well decide to fix it on top of it regardless
[20:21:44 CEST] <BBB> right?
[20:21:47 CEST] <ubitux> ok ok
[20:21:54 CEST] <ubitux> i'll apply soon then
[20:21:57 CEST] <BBB> ok
[20:22:04 CEST] <BBB> nice work, elenril will be happy ;)
[20:22:19 CEST] <ubitux> durandal_1707: no opinion on pow2 in dynaudnorm?
[20:23:02 CEST] <durandal_1707> ubitux: dont care
[20:23:06 CEST] <ubitux> ok
[20:23:50 CEST] <ubitux> btw, as expected it appears gcc won't fix the error/warning for the max align, so i guess i'll try to FFMAX with DJGPP in DECLARE_ALIGN
[20:29:04 CEST] <ubitux> curl -F 'sprunge=<-' http://sprunge.us
[20:29:14 CEST] <ubitux> !@#$
[20:29:16 CEST] <ubitux> http://sprunge.us/PgJG
[20:29:21 CEST] <ubitux> i wonder if this would be acceptable
[20:37:44 CEST] <BBB> ubitux: nice hack ;)
[20:37:51 CEST] <ubitux> :D
[20:38:19 CEST] <ubitux> at least i don't need to patch gcc anymore
[20:41:26 CEST] <atomnuker> durandal_1707: patch reviewed
[20:58:10 CEST] <ubitux> av_log(s, AV_LOG_TRACE, "%X %X\n", st->codecpar->codec_tag, MKTAG('R', 'V', '2', '0'));
[20:58:12 CEST] <ubitux> huh.
[20:58:23 CEST] <ubitux> what's the point of this please?
[20:59:44 CEST] <nevcairiel> presumably so you can compare the tag to rv20? :p
[21:01:34 CEST] <ubitux> yeah well, whatever
[21:02:37 CEST] <nevcairiel> i'm sure we have all sorts of weird logs on rarely used levels
[21:03:51 CEST] <jamrial> that should be using ff_tlog()
[21:03:59 CEST] <jamrial> or alternatively not exist
[21:04:58 CEST] <ubitux> feel free to drop it anytime
[21:05:10 CEST] <ubitux> i'm almost done with fixing the warnings
[21:05:42 CEST] <ubitux> i'll just need av_4cc2str and the align hack and the whole thing is ready
[21:08:19 CEST] <jamrial> if you want to speed things up you could make the new fourcc functions avpriv and then promote them to public if nobody argues
[21:10:57 CEST] <ubitux> no it's ok, i'll wait patiently
[21:41:17 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:1c9f4b507888: lavc/vp9: split into vp9{block,data,mvs}
[21:41:18 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:12c44d637382: lavc/vp9: rename ctx to avctx
[21:41:19 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:f4d95e0949fb: lavc/vp9: rename {ref,unref,alloc}_frame to frame_{ref,unref,alloc}
[21:41:20 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:0f8ae9d7b29d: lavc/vp9: split a few assignment out of ifs
[21:41:21 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:ff8436ba7694: lavc/vp9: rename res to ret
[21:41:22 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:875f6955769b: lavc/vp9: misc cosmetics
[21:41:23 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:37814a21cb7d: lavc/vp9: consistent use of typedef instead of struct
[21:41:24 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:e6ffdc9582a2: lavc/vp9: shuffle header declaration
[21:41:25 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:5dd37c684736: lavc/vp9: clarify inv_recenter_nonneg
[21:48:56 CEST] <BBB> ubitux: oh I remember what you had to fix
[21:49:03 CEST] <BBB> ubitux: you had to add prob to the first commit message
[21:49:09 CEST] <BBB> (as files in which it was split)
[21:49:13 CEST] <BBB> ubitux: too late, ohwell
[21:51:55 CEST] <ubitux> damnit i thought i actually fixed it
[21:52:39 CEST] <ubitux> i wonder if i didn't try to adjust it in the rebase -i stash text like an idiot
[21:52:51 CEST] <BBB> ¯\_(Ä)_/¯
[21:53:06 CEST] <BBB> (I had to google that smiley)
[21:53:14 CEST] <ubitux> ;)
[21:53:29 CEST] <durandal_1707> what it means?
[21:53:34 CEST] <BBB> ohwell"
[21:54:46 CEST] <PaoloP> Hello. I received this message in the mailing list (http://ffmpeg.org/pipermail/libav-user/2017-March/010212.html). It says to send my file made with git format patch . What does it mean, pratically?
[21:56:50 CEST] <durandal_1707> PaoloP: to run: git format-patch on branch you have
[21:59:43 CEST] <PaoloP> durandal_1707: the file I have to send is new, I did not use git, I simply downloaded the stable version (3.2.4) and created a new file
[22:00:12 CEST] <PaoloP> durandal_1707: in this case, which branch I have to use?
[22:00:27 CEST] <ubitux> https://github.com/ubitux/FFmpeg/compare/djgpp alright, i'm done
[22:00:37 CEST] <ubitux> back to the merges.
[22:01:04 CEST] <durandal_1707> PaoloP: the one you gonna create
[22:01:26 CEST] <durandal_1707> ubitux: have you pushed it?
[22:01:31 CEST] <ubitux> nope
[22:01:39 CEST] <ubitux> i need reviews for the api changes
[22:01:44 CEST] <ubitux> and the djgpp align hack
[22:01:53 CEST] <jamrial> PaoloP: new code to be submitted should be written for master branch
[22:03:40 CEST] <PaoloP> jamrial: do I have to submit it with git format patch for master branch, then?
[22:04:01 CEST] <JEEB> yes
[22:06:09 CEST] <jamrial> yes. commit your code, export it a patch with format-patch then email the resulting file as an attachment
[22:06:43 CEST] <cone-883> ffmpeg 03Diego Biurrun 07master:c454dfcff90f: Use ISO C printf conversion specifiers where appropriate
[22:06:44 CEST] <cone-883> ffmpeg 03Diego Biurrun 07master:7a2b2b6a92c4: dxtory: Drop nonsense ISO C printf conversion specifiers for standard types
[22:06:45 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:53dac6c23bde: Merge commit 'c454dfcff90f0ed39c7b0d4e85664986a8b4476c'
[22:06:46 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:349a26f50901: Merge commit '7a2b2b6a92c4b528ecb640790eca0aa790d858f4'
[22:07:38 CEST] <PaoloP> given given that this code has to be put in the doc/examples folder, I should commit a change for the Makefile too, right? (so It is compiled with all the other files)
[22:08:27 CEST] <cone-883> ffmpeg 03Diego Biurrun 07master:3ec6f855d0f2: srt: Adjust signedness of sscanf format strings
[22:08:28 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:7970888b67eb: Merge commit '3ec6f855d0f21d90a0494fb798c4cf203fdb3db0'
[22:09:47 CEST] <cone-883> ffmpeg 03Diego Biurrun 07master:07cac07c0c03: dash: Use correct ISO C scanf conversion specifier
[22:09:48 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:9fec43902c99: Merge commit '07cac07c0c0360d67e73a7472214c79d6c520a4b'
[22:09:53 CEST] <atomnuker> ubitux: I think the VP9 split merge broke something because now mpv doesn't compile
[22:10:09 CEST] <ubitux> atomnuker: ah? damn, what's failing?
[22:10:27 CEST] <atomnuker> ../video/out/vo.h:270:23: error: unknown type name 'AVCodecContext'
[22:12:01 CEST] Action: ubitux confused
[22:12:32 CEST] <jamrial> PaoloP: yeah
[22:13:28 CEST] <ubitux> atomnuker: you'll need to elaborate because i have no idea how that could be because of vp9
[22:13:51 CEST] <atomnuker> me neither, I compiled just before that merge and it was fine
[22:14:06 CEST] <durandal_1707> ./waf configure?
[22:14:09 CEST] <jamrial> ubitux: nice, split source files for vp9 :D
[22:15:14 CEST] <atomnuker> durandal_1707: both reps cleaned up
[22:16:56 CEST] <BBB> atomnuker: thats the most amazing bug ever
[22:17:04 CEST] <BBB> well that does it then
[22:17:10 CEST] <BBB> ubitux: youll have to revert all of it ;)
[22:17:28 CEST] <atomnuker> not before I finish another cleanup and recompile
[22:17:39 CEST] <PaoloP> jamrial: ok, so, for the new file:   "git add myfile; git commit -m "some comment"; git format-patch -1 {commit-id}; "   the last command generates a file and I have to send this file to the mailing list?
[22:18:04 CEST] <ubitux> BBB: you don't like that split, don't you? :D
[22:18:46 CEST] <BBB> Im just teasing
[22:18:50 CEST] <cone-883> ffmpeg 03Diego Biurrun 07master:30015305f3b5: Use avpriv_request_sample() where appropriate
[22:18:51 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:fa85d8dbb43e: Merge commit '30015305f3b523ed7640f2c3c58b017140533c58'
[22:18:58 CEST] <BBB> lemme do some work on it now that its merged
[22:19:06 CEST] <jamrial> PaoloP: git format-patch -1 is enough to export the last commit, and you'll also have to git add the Makefile and any other existing file you modified
[22:20:03 CEST] <PaoloP> jamrial: yes, thanks. So, for the modified Makefile I have to do "add", and it will overwrite the old one??
[22:20:15 CEST] <atomnuker> ubitux: false alarm, turns out I was on my broken vulkan vo branch
[22:20:27 CEST] <jamrial> no, git will simply track the changes you did to it
[22:20:38 CEST] <wm4> eh and that uses AVCodecContext in vo.h?
[22:20:39 CEST] <cone-883> ffmpeg 03Luca Barbato 07master:801ac7156d3e: qsv: Be informative when reporting that no data has been consumed
[22:20:40 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:e59a4d1df75f: Merge commit '801ac7156d3efb8e088fb6024f568eb36a293887'
[22:20:52 CEST] <ubitux> atomnuker: cool :)
[22:21:23 CEST] <PaoloP> jamrial: then these changes will be analyzed by the ffmpeg's team and accepted/rejected ?
[22:21:40 CEST] <cone-883> ffmpeg 03Luca Barbato 07master:c541a44e029e: Revert "rtmpproto: Don't include a client version in the unencrypted C1 handshake"
[22:21:41 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:4e43c6df54e4: Merge commit 'c541a44e029e8a4f21db028c34fee3ad1c10a409'
[22:21:54 CEST] <atomnuker> wm4: unfinished direct rendering thing, obviously it'd all be in vd_lavc calling vulkan vo functions
[22:21:54 CEST] <jamrial> that's the idea
[22:22:04 CEST] <PaoloP> jamrial: ok
[22:23:38 CEST] <PaoloP> jamrial: after executing "git format-patch -1" where is the patch file (which I have to send to the ML)  written?
[22:23:55 CEST] <ubitux> any idea what dad7514f9ec8a8c5e44d70fcfbbcedeff16f7e13 is about? it doesn't apply cleanly
[22:24:12 CEST] <jamrial> in the folder you ran the command from
[22:24:21 CEST] <PaoloP> ok thanks again. let's try all
[22:24:52 CEST] <ubitux> so basically they added "shapes" which it seems we have already
[22:24:54 CEST] <ubitux> i guess i'll noop
[22:25:57 CEST] <jamrial> ubitux:  the code is there, but the order is different
[22:26:26 CEST] <ubitux> i'll noop, we probably have that fixed since 54170a33c2c97b0f50347f57e8f0f2ea681dca1d
[22:26:26 CEST] <jamrial> mmh, no, different flags
[22:26:31 CEST] <jamrial> yeah
[22:26:55 CEST] <cone-883> ffmpeg 03Luca Barbato 07master:dad7514f9ec8: xcb: Add all the libraries to the link line explicitly
[22:26:56 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:fb79adfdcecf: Merge commit 'dad7514f9ec8a8c5e44d70fcfbbcedeff16f7e13'
[22:29:53 CEST] <cone-883> ffmpeg 03Mark Thompson 07master:218ed7250c10: openssl: Allow newer TLS versions than TLSv1
[22:29:54 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:03c203875007: Merge commit '218ed7250c103a975e874fb16e8e5941f4cbe223'
[22:31:30 CEST] <cone-883> ffmpeg 03Vittorio Giovara 07master:7d308bf84bda: avprobe: Add -show_stream_entry to get a single stream property
[22:31:31 CEST] <cone-883> ffmpeg 03Clément BSsch 07master:c7a5b40dd97f: Merge commit '7d308bf84bda78d47c01439ff625bb06624991a7'
[22:37:52 CEST] <ubitux> i'll continue the merge tmr
[22:41:22 CEST] <ubitux> btw, the jpeg is not being fixed?
[22:43:49 CEST] <jamrial> atomnuker or the author of the commit that introduced the regression (Jerry Jiang) should ideallly look at it
[23:00:21 CEST] <BBB> ubitux: quickest attempt ever @ https://github.com/rbultje/ffmpeg/commits/vp9split
[23:00:37 CEST] <BBB> ubitux: with debug symbols, all object files are now well under 1MB
[23:00:47 CEST] <ubitux> 3 last commits i suppose?
[23:01:11 CEST] <BBB> yes
[23:04:29 CEST] <ubitux> you leave quite a bunch of things in the "format" vp9.h file
[23:04:52 CEST] <ubitux> i'm not sure i get the nuance between vp9dec.h and vp9.h
[23:05:08 CEST] <BBB> whatever is there now is the minimum that the hardware decoders need
[23:05:28 CEST] <BBB> so things like dxva2 only need that to interface witht he software decoder skeleton through the hwaccel interface
[23:06:12 CEST] <BBB> the rest is internal only to the software decoder (vp9(*notdsp).c)
[23:06:32 CEST] <ubitux> BBB: s/bwh_tab/ff_vp9_bwh_tab/ or place it only locally where it's used
[23:06:44 CEST] <BBB> its used in 2 files now
[23:06:47 CEST] <BBB> Ill add a prefix
[23:07:26 CEST] <BBB> pushed new version with prefix fixed
[23:07:30 CEST] <ubitux> BBB: why not have a vp9shared.h or vp9hwaccel.h?
[23:07:42 CEST] <ubitux> anyway, i like the split of lpf
[23:07:46 CEST] <ubitux> otherwise no other comment
[23:08:13 CEST] <BBB> I think the filename vp9.h is just historic
[23:08:28 CEST] <BBB> it used to be whatever was shared between vp9dsp.h and vp9.c
[23:08:45 CEST] <BBB> and then it turned into hwaccel interface also
[23:08:53 CEST] <BBB> I can split that into two things, it probably makes sense, yes
[23:09:09 CEST] <BBB> (vp9dsp.h should not depend on the hwaccel interface decoder thingies)
[23:22:17 CEST] <cone-883> ffmpeg 03Vittorio Giovara 07master:b90c8a3d08e3: fate: Add tests for mov display matrix
[23:22:18 CEST] <cone-883> ffmpeg 03James Almer 07master:ba4d0a37b98a: Merge commit 'b90c8a3d08e3f9ad4de1253376d2d1d93abb8b8c'
[23:25:51 CEST] <cone-883> ffmpeg 03Vittorio Giovara 07master:ecd2ec69ce10: mov: Evaluate the movie display matrix
[23:25:52 CEST] <cone-883> ffmpeg 03James Almer 07master:cef2ba3603af: Merge commit 'ecd2ec69ce10e13f6ede353d2def7ce9f45c1a7d'
[23:26:00 CEST] <ubitux> jamrial: nice, exactly how i was expecting it to be merged :)
[23:26:22 CEST] <jamrial> of course i wasn't going to add two new tests for sar and dar :p
[23:26:35 CEST] <ubitux> you could have just ignored the sar/dar :)
[23:26:47 CEST] <ubitux> i like that you took care of it :p
[23:26:54 CEST] <jamrial> yeah
[23:34:05 CEST] <BBB> ubitux: I split out vp9.h in 2 files (one to be shared between vp9dsp/vp9dec, and the other to share between hardware/software decoding)
[23:34:13 CEST] <BBB> ubitux: anything else that you think should be done?
[23:34:38 CEST] <BBB> object file sizes:
[23:34:41 CEST] <BBB> -rw-r--r--  1 ronaldbultje  staff  814212 Mar 27 17:31 libavcodec/vp9block.o
[23:34:41 CEST] <BBB> -rw-r--r--  1 ronaldbultje  staff  604616 Mar 27 17:31 libavcodec/vp9recon.o
[23:34:42 CEST] <BBB> -rw-r--r--  1 ronaldbultje  staff  374280 Mar 27 17:31 libavcodec/vp9dsp_8bpp.o
[23:34:47 CEST] <BBB> thats not too terribly I think
[23:35:00 CEST] <ubitux> djgpp will be happy
[23:35:04 CEST] <ubitux> but yeah, no other comment
[23:35:10 CEST] <BBB> ok Ill send it to the list
[23:35:31 CEST] <atomnuker> ubitux: why the sudden interest in dos compilers?
[23:36:27 CEST] <ubitux> i had to merge c454dfcff90f0ed39c7b0d4e85664986a8b4476c
[23:36:42 CEST] <ubitux> but to do it properly, i needed to see these warnings
[23:36:58 CEST] <ubitux> and these warnings were raised by gcc/djgpp
[23:37:41 CEST] <ubitux> so i need to make that toolchain work, and patch gcc in various areas, and after starting to fix the warnings i realized it was quite helpful to introduce that av_4cc2str helper
[23:38:12 CEST] <ubitux> it also caused the vp9 issue (which i initially assumed it was because of the file size but couldn't confirm it so in doubt split it all and it indeed fixed the problem)
[23:38:18 CEST] <ubitux> so anyway
[23:38:27 CEST] <ubitux> all this shit for stupid cosmetics
[23:38:29 CEST] <ubitux> @_@
[23:38:59 CEST] <ubitux> (s/patch gcc in various areas/patch ffmpeg in various areas/)
[23:52:09 CEST] <cone-883> ffmpeg 03James Almer 07master:064f19f39e2f: avconv: support parsing bitstream filter options
[23:52:10 CEST] <cone-883> ffmpeg 03James Almer 07master:47c2ce2f75cd: Merge commit '064f19f39e2f17927278c6ad8fe884a5b92310d6'
[00:00:00 CEST] --- Tue Mar 28 2017