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

[burek]

[00:39:01 CEST] <cone-729> ffmpeg 03James Almer 07master:8cd8c8331730: avcodec/aacenc_ltp: fix use of uninitialized values
[01:39:12 CEST] <michaelni> does anyone want to push or fix anything in release/3.3 still ? if not ill make 3.3 soon
[01:51:49 CEST] <jamrial> michaelni: yes, one sec
[01:52:45 CEST] <kierank> is there any easy way to see what commits are in 3.3
[01:53:28 CEST] <kierank> git.videolan.org doesn't work for me
[01:54:50 CEST] <cone-729> ffmpeg 03James Almer 07release/3.3:1830b0a6c7dc: avformat/movenc: auto insert vp9_superframe bsf when needed
[01:55:34 CEST] <jamrial> kierank: https://github.com/FFmpeg/FFmpeg
[01:56:07 CEST] <michaelni> https://github.com/FFmpeg/FFmpeg/commits/release/3.3
[01:56:11 CEST] <jamrial> or use gitk, or git log release/3.3
[01:56:48 CEST] <michaelni> note github may be a few minutes behind
[01:56:52 CEST] <jamrial> michaelni: i'm done
[01:59:46 CEST] <kierank> fatal: ambiguous argument 'release/3.3': unknown revision or path not in the working tree.
[02:00:48 CEST] <kierank> ok works when i checkout
[02:01:07 CEST] <kierank> michaelni: are ronald's thread fixes not worth backporting?
[02:01:21 CEST] <kierank> or maybe all are in
[02:01:42 CEST] <kierank> michaelni: 2e664b9c1e73c80aab91070c1eb7676f04bdd12d?
[02:01:49 CEST] <kierank> 7f05c5cea04112471d8147487aa3b44141922d09
[02:03:13 CEST] <michaelni> 2e664b9c1e73c80aab91070c1eb7676f04bdd12d? doesnt apply cleanly
[02:06:02 CEST] <kierank> depends on other h264 changes?
[02:07:33 CEST] <jamrial> kierank: there were other changes by him to pthread_frame, so it probably depends on them
[02:15:53 CEST] <michaelni> kierank, i can backport all of ronalds fixes including 2e664b9c1e73c80aab91070c1eb7676f04bdd12d (needs 083300bea935d125b83f60d7030f78a7ffb0f3df)
[02:16:05 CEST] <kierank> would be appreciated, thanks
[02:16:12 CEST] <michaelni> ok
[02:32:20 CEST] <cone-729> ffmpeg 03Ronald S. Bultje 07release/3.3:414d11fff645: h264: don't re-call ff_h264_direct_ref_list_init() w/ frame-mt.
[02:32:21 CEST] <cone-729> ffmpeg 03Ronald S. Bultje 07release/3.3:e9fc7a90ba21: h264: don't sync pic_id between threads.
[02:32:22 CEST] <cone-729> ffmpeg 03Ronald S. Bultje 07release/3.3:f5f0b2f44ce9: ffmpeg: make transcode_init_done atomic.
[02:32:23 CEST] <cone-729> ffmpeg 03Ronald S. Bultje 07release/3.3:b51217381dd7: pthread_frame: call update_context_from_user() after acquiring lock.
[02:32:24 CEST] <cone-729> ffmpeg 03Ronald S. Bultje 07release/3.3:d1cae50a0467: hevc: only write to max_ra and pocTid0 in the first slice.
[02:32:25 CEST] <cone-729> ffmpeg 03Ronald S. Bultje 07release/3.3:51ca6fda0500: png: split header state and data state in two separate variables.
[02:32:26 CEST] <cone-729> ffmpeg 03Ronald S. Bultje 07release/3.3:e90de50195d4: png: set AVFrame flags/fields before calling setup_finished().
[02:32:27 CEST] <cone-729> ffmpeg 03Ronald S. Bultje 07release/3.3:5e84c94f6962: huffyuv: assign correct per-thread avctx pointer to HYuvContext::avctx.
[02:32:28 CEST] <cone-729> ffmpeg 03Ronald S. Bultje 07release/3.3:9d742f774a85: vp8: make wait/thread_mb_pos atomic.
[02:32:29 CEST] <cone-729> ffmpeg 03Ronald S. Bultje 07release/3.3:6557ea8e2bd7: vp8: make mv_min/max thread-local if using partition threading.
[02:32:30 CEST] <cone-729> ffmpeg 03Ronald S. Bultje 07release/3.3:f4f3bf3c94a9: pthread_frame: allow per-field ThreadFrame owners.
[02:32:31 CEST] <cone-729> ffmpeg 03Ronald S. Bultje 07release/3.3:1968a1eef1ca: pthread_frame: make accesses to debug field be protected by owner lock.
[08:20:57 CEST] <cone-945> ffmpeg 03Carl Eugen Hoyos 07master:a45951c0a491: tests: Fix gray10 and gray12 references after c1616b45.
[10:17:17 CEST] <BtbN> "libavfilter/cuda/build.bat" ...
[10:19:17 CEST] <nevcairiel> strupid cuda shit requiring offline compilation
[10:44:02 CEST] <ubitux> huh, threads are not set to auto by default?? o_o
[10:44:19 CEST] <nevcairiel> i thought they are
[10:44:22 CEST] <nevcairiel> not for fate though
[10:45:15 CEST] <ubitux> {"threads", "set the number of threads", OFFSET(thread_count), AV_OPT_TYPE_INT, {.i64 = 1 }, 0, INT_MAX, V|A|E|D, "threads"},
[10:45:22 CEST] <ubitux> i mean in the api
[10:45:28 CEST] <ubitux> ffmpeg.c sets it to "auto"
[10:45:38 CEST] <JEEB> funky
[10:45:46 CEST] <nevcairiel> i somehow remmeber having to override that
[10:46:01 CEST] <JEEB> yea, I remember you doing limiting on threads
[10:46:06 CEST] <JEEB> for specific stuff
[10:46:12 CEST] <ubitux> damnit, i've been using a monothread decoding in my apps for years
[10:46:17 CEST] <ubitux> i'm an idiot
[10:47:47 CEST] <nevcairiel> http://git.1f0.de/gitweb?p=ffmpeg.git;a=commit;h=2473a45c85dce6872617b33fce396dbbd6347e8e
[10:48:03 CEST] <nevcairiel> (oh, linked my own mirror, i use that because it has blame on)
[10:49:21 CEST] <nevcairiel> i was pretty sure it was set to auto too, though
[10:52:24 CEST] <ubitux> so we can re-enable it?
[10:53:09 CEST] <nevcairiel> i have no opinion on that
[10:53:22 CEST] <nevcairiel> i prefer to control s uch properties at all times
[11:01:06 CEST] <nevcairiel> speaking about opinions, since noone really expressed anything meaningful, I'll just noop the avisynth change, since merging it could break configure lines and the "advantage" it supposedly offers is just not visible to me (renaming a few #ifs to another varible is hardly a simplification to me)
[11:03:47 CEST] <ubitux> nevcairiel: thanks :)
[11:04:44 CEST] <nevcairiel> I assume he meant the simplification in configure, but we dont even have that code since we s hip  their headers
[11:08:12 CEST] <cone-945> ffmpeg 03Diego Biurrun 07master:9265364bec0a: build: Separate avisynth and avxsynth support
[11:08:13 CEST] <cone-945> ffmpeg 03Hendrik Leppkes 07master:1849d0caa52f: Merge commit '9265364bec0af2e8b7c3a6de7bfc8291a0b70bca'
[11:49:17 CEST] <alevinsn> Maybe someone can help me with this basic git question
[11:49:43 CEST] <alevinsn> when I use git reset HEAD~, that resets back to the last check-in but leaves the changes that had previously been checked in in the modified state
[11:49:52 CEST] <alevinsn> so, it is basically like undoing a commit
[11:50:03 CEST] <alevinsn> getting back to the state just prior to committing the changes
[11:50:31 CEST] <alevinsn> is there an equivalent for an older commit?  When I use git revert, it doesn't just "uncommit" the changes
[11:50:34 CEST] <nevcairiel> basically, yes. although if you didnt do any commit, it would do the same for whatever commit was on the top of the tree otherwise
[11:50:36 CEST] <alevinsn> they are lost entirely
[11:50:55 CEST] <alevinsn> so, I want to undo a commit 3 commits ago, let's say
[11:51:03 CEST] <alevinsn> and only that change
[11:51:08 CEST] <alevinsn> not the 2 that happened after the commit
[11:51:23 CEST] <alevinsn> If I use git revert, I have to reapply the changes
[11:51:30 CEST] <nevcairiel> its possible but rather tricky
[11:51:44 CEST] <alevinsn> nevcairiel:  BTW, thanks for reviewing the various patches :-)
[11:52:11 CEST] <alevinsn> maybe git reset in interactive mode?
[11:52:53 CEST] <nevcairiel> assuming the later changes dont depend on the commit you want to change, you can use interactive rebase to go back in and modify it, or re-order to be on top
[11:53:27 CEST] <nevcairiel> interactive rebase is quite powerful
[11:54:36 CEST] <nevcairiel> "git rebase -i HEAD~3" lets you interactively modify the top 3 commits, so you can choose to either modify the commit you want to modify (by using the edit mode), or just re-order its line to the bottom so its on top and you can use your old ways to change it
[11:55:54 CEST] <rcombs> yeah, interactive rebase is your friend here
[11:56:25 CEST] <rcombs> if you want to just outright remove a commit, you just remove (or comment out) its line in the TODO file (that is, the file that's opened in your $EDITOR when you run git rebase -i)
[11:56:35 CEST] <alevinsn> sweet
[11:56:56 CEST] <Gramner> yes, git rebase -i is the way to go for rewriting your local history. removing, reordering, or squashing stuff together
[11:57:32 CEST] <rcombs> if you want to "un-commit" it, but leave the changes in your local working copy, you should probably move it to the end of the list (it's ordered from oldest to newest) and then reset
[11:57:52 CEST] <alevinsn> I used it--thanks for the help--never really used git until I started working on ffmpeg.
[11:57:58 CEST] <nevcairiel> If i need to modify a commit in my local history I often just make a fixup commit and then go into interactive rebase and squash it into
[11:58:09 CEST] <nevcairiel> ..the original one
[11:58:28 CEST] <rcombs> but you should only ever do this on purely-local branches, or remote branches that you have "ownership" over
[11:58:48 CEST] <alevinsn> what do you mean by making a fixup commit and then squashing it into the original one?
[11:58:55 CEST] <rcombs> rewriting history on shared branches without everyone involved knowing that you're doing it ahead of time can be very confusing
[11:59:26 CEST] <rcombs> alevinsn: like, make the change, commit it, and then combine the new commit into the original in rebase -i
[12:00:06 CEST] <nevcairiel> i wonder if any of the Git GUIs make using interactive rebase somehow more intuitive for git beginners
[12:00:06 CEST] <nevcairiel> (i dont use any git gui)
[12:00:24 CEST] <alevinsn> I get it
[12:00:26 CEST] <rcombs> (same)
[12:00:37 CEST] <alevinsn> I have one of the git documents up on rewriting history
[12:00:49 CEST] <alevinsn> so, I understand now what you mean by "squashing"
[12:00:51 CEST] <rcombs> ah, good
[12:01:06 CEST] <nevcairiel> take two, apply pressure, out comes one
[12:01:07 CEST] <nevcairiel> :)
[12:01:15 CEST] <alevinsn> or three, or four....
[12:23:14 CEST] <alevinsn> nevcairel:  for the Made minor changes to get the decklink avdevice code to build using Visual C++ patch I submitted
[12:23:30 CEST] <alevinsn> how does this look for addressing the issues you brought up in configure:
[12:24:20 CEST] <alevinsn> I eliminated both the mingw and win32/64 sets if decklink_outdev/indev_extralibs
[12:24:42 CEST] <alevinsn> and added the following after the enabled sdl2 && enable sdl... line near the end of the file
[12:24:53 CEST] <alevinsn> if enabled decklink; then
[12:24:54 CEST] <alevinsn>     case $target_os in
[12:24:54 CEST] <alevinsn>         mingw32*|mingw64*)
[12:24:54 CEST] <alevinsn>             decklink_outdev_extralibs="$decklink_outdev_extralibs -lole32 -loleaut32"
[12:24:54 CEST] <alevinsn>             decklink_indev_extralibs="$decklink_indev_extralibs -lole32 -loleaut32"
[12:24:54 CEST] <alevinsn>             ;;
[12:24:56 CEST] <alevinsn>         win32|win64)
[12:24:58 CEST] <alevinsn>             decklink_outdev_extralibs="-lole32 -loleaut32"
[12:25:00 CEST] <alevinsn>             decklink_indev_extralibs="-lole32 -loleaut32"
[12:25:02 CEST] <alevinsn>             ;;
[12:25:04 CEST] <alevinsn>     esac
[12:25:08 CEST] <alevinsn> fi
[12:35:21 CEST] <alevinsn> well, I guess away right now, I think I got it right, so I'm submitting a new version on the e-mail list
[12:40:43 CEST] <alevinsn> OK, I think that's it for me.  Almost 4 AM here
[12:40:56 CEST] <alevinsn> thanks for all the assistance
[12:53:17 CEST] <nevcairiel> alevinsn: whats in extralibs before that msvc wants to clear out?
[12:53:31 CEST] <nevcairiel> maybe that should just be set conditionally and unify the entire thing
[13:16:50 CEST] <ubitux> BBB: hey.
[13:17:07 CEST] <ubitux> BBB: h264 and hevc still fails with tsan sometimes
[13:17:21 CEST] <ubitux> BBB: http://fate.ffmpeg.org/report.cgi?time=20170413094928&slot=x86_64-archlinux-gcc-tsan
[13:18:27 CEST] <BBB> I noticed
[13:18:31 CEST] <BBB> very rarely, right?
[13:18:31 CEST] <ubitux> and here for some hevc ones: http://fate.ffmpeg.org/report.cgi?time=20170413031155&slot=x86_64-archlinux-gcc-tsan
[13:18:33 CEST] <ubitux> yes
[13:19:17 CEST] <BBB> Ill have to see whats special about these files, Im guessing its interlacing but Im not 100% sure
[13:19:44 CEST] <BBB> basically these files will have 2 producer threads and we may not be locking both of them, or so
[13:19:47 CEST] <BBB> I dont remember 100%
[13:32:17 CEST] <BtbN> I'm not sure what to do with that CUDA scale filter. It's a mess, and I don't like it at all.
[13:32:36 CEST] <BtbN> Also, as cuvid can now scale on its own, it adds very little new functionality.
[13:34:19 CEST] <BtbN> It's also very strange that they decided to use a .bat file to call nvcc, which then calls sh to call a shell script to do some more magic.
[13:36:23 CEST] <BtbN> Could probably teach the build system to call nvcc. Question is, do we even want that.
[13:43:28 CEST] <jkqxz> What does that compiler actually do?  Is the result the same for all possible target GPUs (so it's some sort of intermediate)?
[13:45:17 CEST] <BtbN> The result is indeed the same
[13:47:47 CEST] <BtbN> you just specify the target generation, kind of
[13:47:53 CEST] <BtbN> like, their commands target sm30
[13:50:46 CEST] <jkqxz> And that runs on all cards supporting some CUDA version or newer?
[13:51:40 CEST] <BtbN> All Shader Model 3.0 nvidia cards
[13:51:53 CEST] <BtbN> and higher, of course
[13:52:16 CEST] <nevcairiel> the result depends on the driver/compiler version though, and can even warry between 32-bit/64-bit OS
[13:52:20 CEST] <nevcairiel> vary*
[13:52:27 CEST] <nevcairiel> so shipping pre-compiled is a bit annoying
[13:52:36 CEST] <nevcairiel> cant this stuff be compiled at runtime
[13:53:23 CEST] <BtbN> they are doing the closes mode to runtime compilation that's possible
[13:53:37 CEST] <BtbN> they only instruct nvcc to generate the ptx code, which is basically GPU-Assembly
[13:54:13 CEST] <nevcairiel> so actual full runtime compilation is not possible?
[13:54:19 CEST] <nevcairiel> who designed this shit? =p
[13:54:22 CEST] <BtbN> Not that I'm aware of, no
[13:54:33 CEST] <BtbN> Well, it saves them from shipping a full llvm toolchain with their driver
[13:55:19 CEST] <cone-945> ffmpeg 03Hendrik Leppkes 07n3.3:HEAD: Merge commit '9265364bec0af2e8b7c3a6de7bfc8291a0b70bca'
[13:56:00 CEST] <jkqxz> If there is a clear baseline for any given filter (requires version X to work at all, compile for version X or newer) then the precompiled intermediate seems reasonable.
[13:56:05 CEST] <nevcairiel> jkqxz: didnt you have some plans for cuda as well?
[13:56:22 CEST] <jkqxz> If it doesn't actually work on all cards which could be supported then it would be an immense pain, though.
[13:56:43 CEST] <jkqxz> No, I never looked at nvidia at all.  My OpenCL stuff does do something similar to this, though.
[13:56:45 CEST] <BtbN> jkqxz, the problem I have is with their approach. They basically put a .bat file next to the filter, and ask you to run it prior to compiling ffmpeg
[13:56:48 CEST] <BtbN> that's not acceptable
[13:56:55 CEST] <nevcairiel> definitely
[13:56:57 CEST] <jkqxz> That all compiles at runtime.
[13:57:22 CEST] <BtbN> Yes, OpenCL can just compile the C-Kernels at runtime
[13:57:24 CEST] <jkqxz> But if it can target all supported GPUs then why do you have to run it?
[13:57:25 CEST] <BtbN> CUDA can't
[13:57:46 CEST] <BtbN> Yeah, you can just commit the pre-compiled .ptx files from how I understand it
[13:57:53 CEST] <BtbN> which they even do, so I don't get the point of the bat file
[13:58:10 CEST] <jkqxz> They have to provide it for licence reasons for the full human-readable source code.
[13:58:22 CEST] <BtbN> the bat file?
[13:58:24 CEST] <jkqxz> Yes.
[13:58:46 CEST] <BtbN> They put a MIT license on it
[13:58:57 CEST] <nevcairiel> (gpu asm is human readable too :p)
[13:59:19 CEST] <jkqxz> The licence of everything else would force the source to be included, though.
[13:59:20 CEST] <BtbN> I'm tempted to take their scale-kernel, and give the nvcc subsystem my own shot
[13:59:38 CEST] <BtbN> Teaching configure/Makefiles about it
[13:59:42 CEST] <BtbN> shouldn't be terribly hard
[13:59:50 CEST] <nevcairiel> probably not
[14:00:20 CEST] <BtbN> And would also actually add a subsystem for more future CUDA filters
[14:00:40 CEST] <BtbN> I don't even understand their patch though. Most of the files they add are not referenced anywhere
[14:01:10 CEST] <jkqxz> Yeah, my OpenCL stuff is doing the same thing.  The source is in CL files, they get compiled to C files containing strings, then included in other stuff to compile at runtime.
[14:01:40 CEST] <jkqxz> The nvcc step would just make the the CUDA -> C conversion step a bit more sophisticated.
[14:02:56 CEST] <BtbN> nvcc converts .cu to .ptx
[14:03:07 CEST] <BtbN> and then they have another shell script, which converts that ptx to C
[14:03:44 CEST] <BtbN> Which would be fine with me. Configure is a shell script as well
[14:17:05 CEST] <BtbN> http://docs.nvidia.com/cuda/nvrtc/ is also a thing
[14:17:41 CEST] <BtbN> But that library is not part of the nvidia driver, and would need to be shipped with ffmpeg...
[16:05:32 CEST] <ubitux> http://sprunge.us/WWKi 
[16:05:34 CEST] <ubitux> the hell is this??
[16:05:50 CEST] <ubitux> (install --enable-shared with mingw32-w64)
[16:06:40 CEST] <wm4> what is was
[16:06:45 CEST] <wm4> *what
[16:07:09 CEST] <wm4> if you mean the .dll.a files, import libs
[16:07:18 CEST] <durandal_1707> big size
[16:09:51 CEST] <ubitux> .dll.a is normal?
[16:12:38 CEST] <wm4> I guess
[16:23:21 CEST] <nevcairiel> its "normal" for weird linux emulation on windows
[16:23:54 CEST] <nevcairiel> but yeah, windows needs import libraries for dynamic linking
[16:24:09 CEST] <nevcairiel> while on linux you would just reference the .so directly, on windows you need a separate library
[16:25:01 CEST] <nevcairiel> (on windows those files would be called .lib, not .dll.a)
[16:26:04 CEST] <wm4> then what would windows call actual static libs
[16:26:10 CEST] <nevcairiel> the same
[16:26:17 CEST] <wm4> uh.
[16:26:19 CEST] <nevcairiel> or put -static in the name or whatever
[16:27:30 CEST] <nevcairiel> the linker doesnt really control if you link static or dynamic like on linux
[16:27:35 CEST] <nevcairiel> you just point it at the .lib file you want
[16:27:37 CEST] <nevcairiel> by filename
[16:27:47 CEST] <nevcairiel> which can either be a dynamic or a static lib
[16:28:56 CEST] <nevcairiel> libraries will often give you different folders which you just reference as needed
[16:29:03 CEST] <nevcairiel> one containing dynamic, one static
[16:29:59 CEST] <jamrial> with mingw, if you don't specify -static during linking and you have both a .dll.a and an .a in the libpath, it will use the former
[16:30:28 CEST] <nevcairiel> well yeah but thats gcc/binutils, they use this layout they created for themself :)
[16:31:34 CEST] <nevcairiel> its probably as good layout as any to differentiate these
[16:39:17 CEST] <J_Darnley> Has the new Git server fingerprint been published somewhere?
[16:40:08 CEST] <nevcairiel> https://mailman.videolan.org/pipermail/vlc-devel/2017-April/112787.html
[16:40:21 CEST] <J_Darnley> tyvm
[18:13:33 CEST] <BtbN> hm, that CUDA script is actually a one-time-run
[18:13:40 CEST] <BtbN> you only need to run it when the .cu file changes
[18:13:49 CEST] <BtbN> Not at every build.
[18:14:24 CEST] <BtbN> Still leaves me wondering why it's a .bat script that then calls a .sh script.
[18:17:58 CEST] <philipl> BtbN: which cuda script? I was offline
[18:18:17 CEST] <RiCON> philipl: http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-April/210109.html
[18:19:38 CEST] <philipl> ah
[18:19:50 CEST] <philipl> BtbN: He's using windows 10 and WSL?
[18:19:51 CEST] <philipl> :-)
[18:20:51 CEST] <RiCON> or just msys sh
[18:22:29 CEST] <philipl> BtbN: so presumably you don't want to check in generated files, and so you want to rebuild from the .cu every time
[18:36:55 CEST] <BtbN> I'm pretty sure you want to check them in
[18:37:14 CEST] <BtbN> Otherwise you'd need to run that bat script on every .cu file every time you build
[19:24:51 CEST] <durandal_170> write news entry about 3.3
[19:37:06 CEST] <atomnuker> I'm writing the changelog
[19:42:43 CEST] <durandal_170> there is already one, just copy paste it
[19:49:57 CEST] <atomnuker> michaelni: what release name did we agree to use (did we?)
[19:52:20 CEST] <jamrial> atomnuker: it's in the download page
[19:54:55 CEST] <michaelni> atomnuker, "Hilbert" see:07e7ebf52de9257fef1398c1dc5edb847b78ab21
[20:00:28 CEST] <atomnuker> k thanks, patch sent
[21:05:22 CEST] <durandal_1707> i cant force myself to work on atrac9
[21:05:40 CEST] <atomnuker> durandal_1707: why not?
[21:05:54 CEST] <atomnuker> is it no fun at all?
[21:06:30 CEST] <ubitux> atomnuker: if you're advertising libav features in the changelog (i don't know if it's the case) please credit them
[21:06:32 CEST] <durandal_1707> its daunting at start but should become fun at end
[21:14:25 CEST] <jamrial> ubitux: i don't agree. they don't credit features they ported from ffmpeg either
[21:14:30 CEST] <jamrial> and the news entry simply states "this are the highlights of the release", not "this is what we developed for this release" or similar
[21:14:54 CEST] <atomnuker> ubitux: advertising? this is a 1:1 copy from the Changelog file, just reordered
[21:15:15 CEST] <ubitux> jamrial: well, their bad behaviour should not justify ours. and it implies that we are developping all of these
[21:15:21 CEST] <jamrial> credit has always been in the git history, and the download page where it mentions "this release has all changes to master up to" line
[21:15:22 CEST] <ubitux> i'm in favor of not escalating the tensions
[21:15:34 CEST] <ubitux> if you don't want to credit them, drop the entries
[21:16:03 CEST] <ubitux> but i don't think we should "steal" the work
[21:16:43 CEST] <ubitux> note: that's just my opinion, not a blocker, i'm leaving the decision in your hands
[21:17:03 CEST] <jamrial> i'm sorry, but i don't agree with what you're saying. credit is clear in the merge commits and even the cherry pick commits. also in the download page entry for each release
[21:17:49 CEST] <jamrial> based on what you said, the same should be done for the Changelog file
[21:18:00 CEST] <jamrial> since this news entry is just a carbon copy of it
[21:18:10 CEST] <ubitux> actually, i think so yes
[21:18:58 CEST] <wm4> I think explicit crediting would be good
[21:20:58 CEST] <jamrial> make the suggestion in the ml then. I don't agree but others might
[21:27:25 CEST] <durandal_1707> atomnuker: why was float pcm codecs removed?
[21:28:13 CEST] <durandal_1707> also could mention dnxhr 444 and hqx support in encoding and fixes in decoding
[21:38:25 CEST] <atomnuker> durandal_1707: highlights, but I guess 64 bit float is a big enough thing
[21:38:44 CEST] <atomnuker> I'll add the dnxhd stuff
[21:43:04 CEST] <jamrial> atomnuker: remove the ones merged from libav as ubitux requested. at least until there's some consensus about it
[21:43:18 CEST] <atomnuker> ok
[21:44:01 CEST] <atomnuker> which ones were merged? vp8 vaapi encoding?
[21:45:30 CEST] <ubitux> weren't those submitted by the author himself to ffmpeg?
[21:46:03 CEST] <ubitux> the point is that some libav developers do not want to be associated with the ffmpeg project
[21:46:19 CEST] <ubitux> since we're taking their work, it's the least we can do to honor that implicit request
[21:46:35 CEST] <atomnuker> I've removed the xcb entry since I do know that was merged
[21:47:04 CEST] <ubitux> basically afaik i think work from Luca, Diego and Anton should probably stay out of the changelog, but you may want to ask them 
[21:47:20 CEST] <jamrial> the thing about the legacy X11 screen grabber was merged from libav
[21:47:41 CEST] <atomnuker> yep, removed that
[21:48:12 CEST] <atomnuker> durandal_1707: "DNxHR decoder fixes for high resolution videos" <- sounds good (for the decoder section)?
[21:48:14 CEST] <jamrial> and probably the Intel QSV video scaling and deinterlacing filters, but like the vaapi stuff that might have also been submitted to ffmpeg by the author
[21:48:29 CEST] <durandal_1707> atomnuker: yes
[21:48:45 CEST] <durandal_1707> and fix for 10bit hqx profile
[21:50:17 CEST] <atomnuker> jamrial: those were all submitted by jkqxz, so I don't think they count
[21:51:37 CEST] <atomnuker> durandal_1707: "DNxHR decoder fixes for HQX and high resolution videos" <- that ok?
[21:54:58 CEST] <durandal_1707> atomnuker: yes, 10 bit hqx was buggy, but 12bit hqx is ok
[21:55:29 CEST] <durandal_1707> i need to add dnxhr 420 and alpha support
[21:56:13 CEST] <jamrial> there, patchset sent to finally get that filter to stop violating the api
[22:05:01 CEST] <cone-875> ffmpeg 03Diego Biurrun 07master:404cb7479328: configure: Pass CFLAGS_HEADERS through the right CFLAGS filter
[22:05:01 CEST] <cone-875> ffmpeg 03Wan-Teh Chang 07master:f22da2cdf90d: configure: add -fPIE instead of -pie to C flags for ThreadSanitizer
[22:05:01 CEST] <cone-875> ffmpeg 03James Almer 07master:41b8b2ca286f: Merge commit '404cb74793284aa03e2e1a7e911c980c4cba0e9e'
[22:05:01 CEST] <cone-875> ffmpeg 03James Almer 07master:a5a56bd3dfa3: Merge commit 'f22da2cdf90dc892d483e2d4003cffc0500816f6'
[22:07:02 CEST] <cone-875> ffmpeg 03Diego Biurrun 07master:4104cc56225f: build: Warn that reconfiguration is necessary if version.h files changed
[22:07:03 CEST] <cone-875> ffmpeg 03James Almer 07master:7f933718dc55: Merge commit '4104cc56225f29ce1cded8b2876f8748460232a6'
[22:09:33 CEST] <BtbN> seriously?
[22:14:23 CEST] <Compn> i guess his email client isnt stripping the ending >
[22:14:38 CEST] <Compn> if he clicks it ? maybe ?
[22:14:52 CEST] <Compn> could be bad copy paste but i'm at a loss here
[22:19:04 CEST] <cone-875> ffmpeg 03Diego Biurrun 07master:3e105d088481: build: Move entries related to building TOOLS to a subdirectory Makefile
[22:19:05 CEST] <cone-875> ffmpeg 03James Almer 07master:5dba808064e7: Merge commit '3e105d08848162b90d886bde59c010d4b0362a4b'
[22:20:14 CEST] <BtbN> both his reports are... questionable at best
[22:21:46 CEST] <cone-875> ffmpeg 03Diego Biurrun 07master:6bd9590b3374: build: Have old H.264/HEVC nvenc encoders select their new counterparts
[22:21:47 CEST] <cone-875> ffmpeg 03James Almer 07master:8c71d1b06028: Merge commit '6bd9590b33742f1cceecc0c0d81b3caf3d8a4e1a'
[22:22:58 CEST] <Compn> maybe he/she will learn
[22:23:05 CEST] <Compn> must nuture bug reporters, not hate them
[22:23:28 CEST] <BtbN> Well, the other one is probably not an ffmpeg bug to begin with, but obs misusing the API
[22:23:43 CEST] <durandal_1707> hate hate hate
[22:24:02 CEST] <BtbN> Impossible to tell with that report though, could be bad RAM as well
[22:24:55 CEST] <cone-875> ffmpeg 03Diego Biurrun 07master:c833c2034f4e: build: Ensure that the "all" target appears before all Makefile includes
[22:24:56 CEST] <cone-875> ffmpeg 03James Almer 07master:27324825defa: Merge commit 'c833c2034f4ee77fe2ee3470f3f5f84415673b3b'
[22:25:00 CEST] <Compn> obs bug then ?
[22:25:15 CEST] <BtbN> Who knows?
[22:25:23 CEST] <Compn> mark invalid and move along ?
[22:25:48 CEST] <BtbN> could ask for a backtrace
[22:25:52 CEST] <Compn> or that
[22:28:21 CEST] <Fenrirthviti> BtbN: Sorry about that, I did not ask them to report the bug.
[22:28:36 CEST] <Fenrirthviti> We did a trace of OBS, and the fault was in swscale so he just went on a warpath to "report the bug"
[22:29:20 CEST] <nevcairiel> more often then not its caused by bad usage
[22:29:40 CEST] <cone-875> ffmpeg 03Diego Biurrun 07master:624aa8ab221c: build: Add missing Makefile entries and ifdefs for QSV hwaccels
[22:29:41 CEST] <cone-875> ffmpeg 03James Almer 07master:7d3bb052c8b9: Merge commit '624aa8ab221cf34693f9a8c5ab67219cf560f2bb'
[22:29:42 CEST] <Fenrirthviti> That's what we suspect, I verified the lossless preset (which is what he's trying to use) in OBS works just fine with UTvideo on several linux systems.
[22:30:29 CEST] <Fenrirthviti> He wasn't really listening to any attempts to try and figure out the bug, and when we tracked it to something in swscale he just kinda vanished and decided he needed to "report the bug"
[22:30:35 CEST] <Fenrirthviti> Sorry for the trouble.
[22:30:53 CEST] <Fenrirthviti> figure out the issue, that is, not necessarily a bug
[22:32:59 CEST] <cone-875> ffmpeg 03Vittorio Giovara 07master:075acbb6ff57: lavu: Add a video section to Doxygen documentation
[22:33:00 CEST] <cone-875> ffmpeg 03James Almer 07master:7adfa7cdc6dd: Merge commit '075acbb6ff5740b2eea1bb7dd3afbc8e66e2ebf8'
[22:34:42 CEST] <BtbN> Fenrirthviti, do you still have the trace?
[22:35:08 CEST] <Fenrirthviti> I do
[22:35:24 CEST] <Fenrirthviti> https://paste.ubuntu.com/24375821/ doubt it's much use
[22:35:29 CEST] <BtbN> I can very well be a bug in swscale, it's just unlikely.
[22:36:05 CEST] <BtbN> That's not a backtrace though
[22:36:36 CEST] <Fenrirthviti> Yeah, that's as far as we got before he stopped listening to me and kept asking "how do I report the bug to ffmpeg"
[22:36:49 CEST] <BtbN> it doesn't even mention swscale there
[22:37:01 CEST] <Fenrirthviti> oh, whoops wrong paste, I apologize.
[22:37:14 CEST] <Fenrirthviti> https://paste.ubuntu.com/24375835/ that one
[22:37:55 CEST] <BtbN> hm, yeah
[22:38:10 CEST] <BtbN> that can be really anything
[22:38:49 CEST] <BtbN> also doesn't really make sense that lossless mode would trigger it. The part where swscale is involved shouldn't care
[22:39:56 CEST] <Fenrirthviti> myself and several other folks verified lossless worked just fine in our environments, so I'm guessing there's a missing piece and this kid just didn't want to help.
[22:40:12 CEST] <BtbN> Just gonna close that as invalid
[22:40:14 CEST] <Fenrirthviti> He also waited like 5 minutes in #ffmpeg before reporting, I'm really annoyed about that too.
[22:40:32 CEST] <Fenrirthviti> Seeing as he called it out in his report "nobody helped him"
[22:40:55 CEST] <Fenrirthviti> That's fine, if he comes back we'll try and get more info out of him. Sorry again for the trouble.
[22:42:35 CEST] <BtbN> Not really trouble, just weird
[22:51:24 CEST] <cone-875> ffmpeg 03Vittorio Giovara 07master:c70add61d155: lavu: Add AVSphericalMapping type and frame side data
[22:51:25 CEST] <cone-875> ffmpeg 03Vittorio Giovara 07master:2fb6acd9c289: lavc: Add spherical packet side data API
[22:51:26 CEST] <cone-875> ffmpeg 03Vittorio Giovara 07master:e90137c04572: mov: Export spherical information
[22:51:27 CEST] <cone-875> ffmpeg 03James Almer 07master:b2798267c550: Merge commit 'e90137c045721a1635cc241eb1e1be1126389c38'
[22:55:04 CEST] <cone-875> ffmpeg 03Vittorio Giovara 07master:68f8db610871: avprobe: Allow specifying multiple stream entries to be shown
[22:55:04 CEST] <cone-875> ffmpeg 03Vittorio Giovara 07master:cf1cae58b015: fate: Add spherical and stereo3d mov tests
[22:55:05 CEST] <cone-875> ffmpeg 03Diego Biurrun 07master:f912fd767e55: Add missing #includes for standalone spherical-information-related headers
[22:55:06 CEST] <cone-875> ffmpeg 03James Almer 07master:0050449a0744: Merge commit 'f912fd767e55bbb5a1554bd99bacab007659609c'
[22:58:18 CEST] <cone-875> ffmpeg 03Diego Biurrun 07master:fbec58daa235: build: Add an internal component for hevc_ps code
[22:58:19 CEST] <cone-875> ffmpeg 03James Almer 07master:14bc8d6755aa: Merge commit 'fbec58daa2351cbe9fc758d8735c23ff03313db4'
[23:01:44 CEST] <alevinsn> nevcairiel:  you there?
[23:01:50 CEST] <nevcairiel> yes
[23:02:39 CEST] <alevinsn> ok, so regarding the one patch that went through a bunch of reviews and seems to have been blessed by you and wm4
[23:02:52 CEST] <alevinsn> this one:  "Made appropriate changes to be able to successfully build C++ files using a Visual C++ build on Windows"
[23:03:22 CEST] <alevinsn> is it appropriate to commit it to the remote repository or wait a few days to allow others to comment?
[23:04:06 CEST] <nevcairiel> it could probably use a better commit message, but otherwise it seems fine
[23:04:10 CEST] <nevcairiel> do you have push access?
[23:04:35 CEST] <alevinsn> I doubt it
[23:04:54 CEST] <Compn> i think hes asking if you can push it :)
[23:05:18 CEST] <alevinsn> well, I wouldn't mind being able to push it
[23:05:35 CEST] <Compn> alevinsn : do you subscribe to the -devel list and review patches? 
[23:05:38 CEST] <alevinsn> I have 3 other patches awaiting full review
[23:05:41 CEST] <Compn> or work on ffmpeg...
[23:05:53 CEST] <alevinsn> um, I have been working on ffmpeg recently
[23:06:09 CEST] <nevcairiel> i'll push the patch with a slightly revised commit message soon then
[23:06:20 CEST] <alevinsn> I've submitted 4 patches in total so far
[23:06:33 CEST] <alevinsn> I haven't really been reviewing other peoples' patches though
[23:06:39 CEST] <Compn> i'm not 100% exactly sure on commit rights , but i think the unwritten rule was something like 1-2 months developer time 
[23:06:50 CEST] <Compn> or if you maintain something specific
[23:07:01 CEST] <Compn> and will in the future.
[23:07:05 CEST] <alevinsn> I've been working on ffmpeg for at least 1 month I'd say, off and on
[23:07:05 CEST] <nevcairiel> if you only have a few patches here and there it makes no sense really anyway, we can just push them for you
[23:07:16 CEST] <alevinsn> well, there are likely to be more
[23:07:22 CEST] <alevinsn> I have 2 more patches that I want to submit when they are ready
[23:07:27 CEST] <Compn> alevinsn : i'm not trying to discourage you , just letting you know our kind of rules :)
[23:07:30 CEST] <alevinsn> and I need to do something to fix issues with Quicksync after that
[23:07:35 CEST] <Compn> i encourage you to stick around :)))
[23:08:05 CEST] <Compn> tl;dr "if your patches are good , commit access will be given"
[23:08:29 CEST] <alevinsn> ok, I'll work to make them better :-P
[23:08:45 CEST] <wm4> we shouldn't give push access to every occasional contributor
[23:08:57 CEST] <Compn> and if you abide by the developer rules in the docs
[23:09:07 CEST] <wm4> which rules, there are none
[23:09:17 CEST] <Compn> and all of the unwritten rules , gleaned by reading ml and irc :P
[23:09:29 CEST] <alevinsn> yes, like this DCE one....
[23:09:35 CEST] <nevcairiel> alevinsn: regarding the patch in question, thematically you could probably put the -lstdc++ fix I  suggested on the ML for your other issue into this one, it would fit the topic of improving msvc c++ building
[23:09:47 CEST] <alevinsn> I've already just done
[23:09:51 CEST] <alevinsn> and confirmed that it works
[23:10:03 CEST] <alevinsn> oh
[23:10:17 CEST] <alevinsn> well, I separated it because one applies more to decklink
[23:10:22 CEST] <alevinsn> and one to general msvc c++
[23:10:34 CEST] <alevinsn> and that's what someone requested in a response to the original patch
[23:10:38 CEST] <alevinsn> from Kyle Schwarz
[23:10:42 CEST] <nevcairiel> technically yes, but generally every c++ module would likely need it
[23:11:23 CEST] <alevinsn> although Kyle Schwarz didn't do anything with libstdc++ and may not have been building with msvc
[23:12:25 CEST] <alevinsn> ok, so you want me to submit a new version of the "Made appropriate changes to be able to successfully build C++ files using a Visual C++ build on Windows" patch with the -lstdc++ replacement for msvc? :-)
[23:12:39 CEST] <nevcairiel> nah i can just add it
[23:12:49 CEST] <alevinsn> ok
[23:12:53 CEST] <alevinsn> here's what I did
[23:12:58 CEST] <alevinsn> added it after -lx264)
[23:13:04 CEST] <alevinsn> it must go before -l*
[23:13:08 CEST] <alevinsn> but you probably already knew that
[23:13:16 CEST] <alevinsn> -lstdc++)           ;;
[23:16:42 CEST] <cone-875> ffmpeg 03Diego Biurrun 07master:f55c0a64ae40: build: Drop stray golomb dependencies
[23:16:43 CEST] <cone-875> ffmpeg 03James Almer 07master:40f3f0298a01: Merge commit 'f55c0a64ae40dc8e0a131a590e123cd14d0c0f7a'
[23:16:44 CEST] <cone-875> ffmpeg 03James Almer 07master:0dd277730966: configure: add missing golomb dependency to hevcparse
[23:17:42 CEST] <nevcairiel> alevinsn: just running a last round of tests to ensure nothing unexpected happens, but should be fine
[23:18:09 CEST] <cone-875> ffmpeg 03Diego Biurrun 07master:892acc70105d: configure: Fail if cuda was enabled and is not available
[23:18:10 CEST] <cone-875> ffmpeg 03James Almer 07master:64472bf0bc41: Merge commit '892acc70105df9e6f7773bdde85b3e9541098525'
[23:19:49 CEST] <cone-875> ffmpeg 03Diego Biurrun 07master:d5759701a829: libkvazaar: Add missing header #includes
[23:19:50 CEST] <cone-875> ffmpeg 03James Almer 07master:f416a8d66ac3: Merge commit 'd5759701a82926059ae3e2530805e900041a5419'
[23:26:57 CEST] <cone-875> ffmpeg 03Wan-Teh Chang 07master:2170017a1cd0: avutil: fix data race in av_get_cpu_flags()
[23:26:58 CEST] <cone-875> ffmpeg 03James Almer 07master:657c07203614: Merge commit '2170017a1cd033b6f28e16476921022712a522d8'
[23:28:19 CEST] <cone-875> ffmpeg 03Wan-Teh Chang 07master:6a93b596c5c3: compat/atomics: add typecasts in atomic_compare_exchange_strong()
[23:28:20 CEST] <cone-875> ffmpeg 03James Almer 07master:eab5d29810d5: Merge commit '6a93b596c5c3af31b843d63013a7985ffeea354d'
[23:30:57 CEST] <cone-875> ffmpeg 03Timothy Gu 07master:d32bdadda86b: qsvdec: Fix memory leak on error
[23:30:58 CEST] <cone-875> ffmpeg 03James Almer 07master:1d94a6c48f81: Merge commit 'd32bdadda86b35c2960e4de877cf081b9d2dadb3'
[23:32:46 CEST] <cone-875> ffmpeg 03Timothy Gu 07master:d3da8a003573: omx: Fix allocation check
[23:32:47 CEST] <cone-875> ffmpeg 03James Almer 07master:e688ca102ed3: Merge commit 'd3da8a0035734529c4e26696c9a0c6cb56633838'
[23:33:48 CEST] <alevinsn> On a separate note, I see a bunch of commits on IRC that were clearly not reviewed in patch form on ffmpeg-devel
[23:33:58 CEST] <alevinsn> is a different approach being utilized in some cases?
[23:34:16 CEST] <nevcairiel> the merges are special
[23:34:34 CEST] <alevinsn> what do you mean?
[23:34:43 CEST] <BtbN> most of them got review on libav. Hopefully
[23:35:45 CEST] <alevinsn> k
[23:35:48 CEST] <nevcairiel> they were already reviewed once on another ML (more or less), and the person doing the merge also reviews them during merging
[23:36:06 CEST] <nevcairiel> so any immediate issues can be resolved right there
[23:37:02 CEST] <nevcairiel> its a bit of a trade-off to be able to actually merge these changes, if every single commit would go through the ML again this would never be done - if there are larger changes, we do tend to pause the merging there and get more people on them though
[23:37:25 CEST] <nevcairiel> speaking of merging, jamrial let me know when i can push something
[23:37:51 CEST] <alevinsn> you are not talking about libav-user, right?  there is a separate libav e-mail list?
[23:38:52 CEST] <BtbN> libav is a separate project.
[23:40:09 CEST] <BtbN> Regarding the merges and rebases. Why exactly doesn't "git rebase --preserve-merges" just work?
[23:40:30 CEST] <nevcairiel> because it doesnt "preserve" the merges, but re-does them
[23:40:34 CEST] <nevcairiel> including new conflict resolution
[23:40:58 CEST] <nevcairiel> i have no idea why it doesnt just rebase the merge like any other commit, i'm sure there is some technical reason for that
[23:41:20 CEST] <BtbN> Probably because it has more than one parent, and it has no idea which one to rebase?
[23:42:34 CEST] <alevinsn> ok, just to make sure I understand regarding libav, libav was forked from ffmpeg in 2011, but there are still enough similarities between the code bases that some patches to libav are appropriate for ffmpeg?
[23:42:51 CEST] <BtbN> all patches
[23:43:08 CEST] <BtbN> every single commit to libav master gets merged
[23:43:15 CEST] <BtbN> some of them are no-op'ed
[23:43:21 CEST] <BtbN> But generally things are kept in sync
[23:43:31 CEST] <alevinsn> does the reverse occur?
[23:43:39 CEST] <BtbN> sometimes, if they feel like it
[23:43:57 CEST] <nevcairiel> well yeah, all commits are "merged", but many of them are just merged for their metadata, and their changes are not used, for various reasons: we already have that change, or another change in similar form, or it just doesnt a pply to our code
[23:45:12 CEST] <nevcairiel> but a bunch of changes are still worth using
[23:45:16 CEST] <alevinsn> so, let's say a set of changes were merged from libav, such as the ones that have to do with QuickSync (QSV), and they end up causing things to not work properly in some cases with ffmpeg
[23:45:27 CEST] <alevinsn> someone could post on ffmpeg-devel about the issues
[23:45:43 CEST] <alevinsn> but the person responsible might not be paying attention there, and only be paying attention to libav-devel, right?
[23:46:17 CEST] <alevinsn> I guess the benefits outweigh the disadvantages
[23:46:39 CEST] <nevcairiel> perhaps, although many of us talk to both sides, so its often not a problem
[23:46:54 CEST] <nevcairiel> so even if someone unaware of this posts a report we can still inquire
[23:48:16 CEST] <BtbN> not like normal patches don't sometimes have unintended side effects
[23:57:21 CEST] <jamrial> nevcairiel: go ahead
[23:58:27 CEST] <cone-875> ffmpeg 03Aaron Levinson 07master:bceb3d0f8621: Support building C++ files with MSVC
[00:00:00 CEST] --- Fri Apr 14 2017