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

[burek]

[00:02:18 CET] <cone-233> ffmpeg 03Alexandra Hájková 07master:118dd4a321a2: hevc: 16x16 NEON idct: Use the right element size for loads/stores
[00:02:19 CET] <cone-233> ffmpeg 03Alexandra Hájková 07master:ce080f47b8b5: hevc: Add NEON 32x32 IDCT
[00:02:20 CET] <cone-233> ffmpeg 03James Almer 07master:e9e7e1cc6b8a: Merge commit '118dd4a321a2d67f67c21b076abd0b4d939ab642'
[00:02:21 CET] <cone-233> ffmpeg 03James Almer 07master:62d86c41b72c: Merge commit 'ce080f47b8b55ab3d41eb00487b138d9906d114d'
[00:05:42 CET] <cone-233> ffmpeg 03Martin Storsjö 07master:59cee42d7d22: arm: Check for the .arch directive in configure
[00:05:43 CET] <cone-233> ffmpeg 03James Almer 07master:71bf534dd682: Merge commit '59cee42d7d22530e66a155305389e29679b11f78'
[00:09:51 CET] <cone-233> ffmpeg 03James Almer 07master:648a0b450387: hevcdec: remove HEVCContext usage from hevc_sei
[00:09:52 CET] <cone-233> ffmpeg 03James Almer 07master:cfd25488bf35: hevcdec: move SEI message parsing into a separate header
[00:09:53 CET] <cone-233> ffmpeg 03James Almer 07master:0b30cb8dae5e: Merge commit 'cfd25488bf35123bdd38ecbe1107a21df2e03c2f'
[00:10:25 CET] <kierank> this is an awful bug
[00:29:27 CET] <iive> kierank: valgrind --leak-check=<no|summary|yes|full> [default: summary]  When enabled, search for memory leaks when the client program finishes. If set to summary, it says how many leaks occurred. If set to full or yes, it also gives details of each individual leak.
[00:30:30 CET] <alevinsn> jamrial:  here by chance?
[00:32:36 CET] <jamrial> alevinsn: yes
[00:33:10 CET] <alevinsn> jamrial:  I think I might have figured it out based on a review of some of your patches since you merged in the change earlier in the month
[00:33:18 CET] <alevinsn> to eliminate the use of add_extralibs() in most cases
[00:33:38 CET] <alevinsn> haven't built from the latest code in a couple of months
[00:34:08 CET] <alevinsn> looks like this change broke libmfx enablement on Windows, at least if pkg-config isn't used
[00:34:27 CET] <alevinsn> but I see an example of how you addressed for libxavs after you did the merge
[00:37:36 CET] <jamrial> broke it how? missing some library during the check?
[00:38:00 CET] <alevinsn> yeah, it used to get things like shell32.lib, advapi32.lib automatically
[00:38:14 CET] <alevinsn> since those check_lib commands are invoked first
[00:38:35 CET] <alevinsn> but now, they are added to things like shell32_lib, wincrypt_lib, etc
[00:39:06 CET] <alevinsn> technically, I need to link to the Win32 Registry APIs
[00:39:10 CET] <alevinsn> which are found in advapi32
[00:39:24 CET] <alevinsn> and wincrypt_lib is currently the only thing associated with advapi32
[00:41:25 CET] <alevinsn> Maybe the best way is to add checklib winreg "windows.h" RegCloseKey -ladvapi32 or something like that
[00:41:33 CET] <alevinsn> check_lib, I mean
[00:42:29 CET] <jamrial> there's already a check for advapi32, for wincrypt
[00:42:37 CET] <alevinsn> right, but it is a bit odd
[00:42:45 CET] <alevinsn> libmfx doesn't need CryptGenRandom
[00:42:57 CET] <alevinsn> it needs RegCloseKey, etc
[00:43:23 CET] <alevinsn> It was getting -ladvapi32 for the wrong reasons previously
[00:43:24 CET] <jamrial> it doesn't matter, if that's the only lib the libmfx check needs, then wincrypt_extralibs could be added to it
[00:43:39 CET] <alevinsn> right, that would work, but it might be confusing to someone if they looked into it
[00:44:14 CET] <alevinsn> since wincrypt, in theory, should be listed as a dependency for something that needs the Crypt API functionality
[00:44:23 CET] <alevinsn> based on the naming
[00:44:34 CET] <alevinsn> "wincrypt"
[00:44:43 CET] <alevinsn> ole32 and shell32 are named appropriately
[00:44:54 CET] <alevinsn> and match the -l<library name>
[00:44:58 CET] <alevinsn> but wincrypt is the odd one out
[00:45:04 CET] <alevinsn> same with psapi--that one is named appropriately
[00:45:21 CET] <alevinsn> perhaps change wincrypt to be advapi32?
[00:47:14 CET] <jamrial> i guess that's an option. it's not currently exported to config.h
[00:52:01 CET] <alevinsn> thanks, I'll submit patches for this
[00:54:12 CET] <cone-233> ffmpeg 03Sean McGovern 07master:cb167f2947f1: h264_refs: validate the SPS pointer in ff_h264_execute_ref_pic_marking()
[00:54:13 CET] <cone-233> ffmpeg 03James Almer 07master:0e5a47693c4b: Merge commit 'cb167f2947f1a2c446bd8db196d0e64ef4a6d06b'
[00:59:20 CET] <cone-233> ffmpeg 03Martin Storsjö 07master:6ccf76aec73b: mpjpeg: Use proper CR/LF in multipart headers
[00:59:21 CET] <cone-233> ffmpeg 03James Almer 07master:7131139b4370: Merge commit '6ccf76aec73b2cd598bb1e65d126d8a12540c411'
[01:03:18 CET] <cone-233> ffmpeg 03Martin Storsjö 07master:d7320ca3ed10: arm: Avoid using .dn register aliases
[01:03:19 CET] <cone-233> ffmpeg 03James Almer 07master:921993503b80: Merge commit 'd7320ca3ed10f0d35b3740fa03341161e74275ea'
[01:04:37 CET] <cone-233> ffmpeg 03Martin Storsjö 07master:d05c9cde0e87: checkasm: aarch64: Specify alignment for the register_init const array
[01:04:38 CET] <cone-233> ffmpeg 03James Almer 07master:122a749dfcaa: Merge commit 'd05c9cde0e87c23ca42957646bea483dfc09d6bf'
[01:07:21 CET] <cone-233> ffmpeg 03Martin Storsjö 07master:c380a0d7f7a2: movenc: Add an option for enabling negative CTS offsets
[01:07:22 CET] <cone-233> ffmpeg 03James Almer 07master:17feb9e61da3: Merge commit 'c380a0d7f7a2c7411aae60463e25d916541f0388'
[01:10:36 CET] <cone-233> ffmpeg 03Martin Storsjö 07master:c415c8104c46: movenc: Don't write any edit list if the start offset is zero
[01:10:37 CET] <cone-233> ffmpeg 03Martin Storsjö 07master:7c35bee0251e: movenc-test: Add tests for negative cts offsets
[01:10:38 CET] <cone-233> ffmpeg 03James Almer 07master:ed15851fd890: Merge commit '7c35bee0251efc271c8f7900ce816fcb8ec25d19'
[01:12:54 CET] <jamrial> jkqxz: ping
[01:14:47 CET] <cone-233> ffmpeg 03Mark Thompson 07master:66aa9b94dae2: doc: Document hwupload, hwdownload and hwmap filters
[01:14:48 CET] <cone-233> ffmpeg 03James Almer 07master:f7038c3629e7: Merge commit '66aa9b94dae217a0fc5acfb704490707629d95ed'
[01:30:53 CET] <jkqxz> jamrial:  Pong.
[01:35:58 CET] <jamrial> jkqxz: does 4d56f7ab8f (libav commit) apply to us?
[01:36:46 CET] <jamrial> and any reason you didn't apply it? i see you did commit the non streamcopy one
[01:37:24 CET] <jkqxz> Hmm, I don't remember.
[01:37:53 CET] <jkqxz> Easy to test, though.
[01:39:13 CET] <jamrial> fate seems to fail if i apply it :/
[01:39:21 CET] <jkqxz> What fails?
[01:41:37 CET] <jamrial> fate-fifo-muxer-h264
[01:42:04 CET] <jkqxz> Hmm, auto-insertion of superframe messes with my VP9 raw-reorder test-case.
[01:42:56 CET] <kierank> michaelni: ping
[01:42:58 CET] <jamrial> also fate-filter-mergeplanes, sigsev
[01:44:18 CET] <jamrial> eleven tests in total fail with that applied
[01:45:11 CET] <jkqxz> Yeah, it's needed.  The stream will lose delayed packets without it.
[01:45:15 CET] <jamrial> all of them seem to seg fault
[01:46:01 CET] <michaelni> kierank, pong
[01:46:19 CET] <kierank> michaelni: see #6789
[01:48:08 CET] <jkqxz> Hmm, test case still doesn't work with it applied.
[01:48:29 CET] <liyou> how to test
[01:48:48 CET] <jkqxz> In my three-packet test, only the first packet even gets given to the BSF at all.
[01:51:27 CET] <jkqxz> The segfault is because process_input_packet() looks inside the packet when it might be NULL as a flush packet.
[01:53:16 CET] <jamrial> jkqxz: i'm running fate with that line changed to "else if (pkt && pkt->duration)", to see if that's enough
[01:53:32 CET] <jkqxz> Yeah, I did that and it seems to fix it for me.
[01:53:49 CET] <jkqxz> Not entirely sure what the dts stuff is doing there, though.
[01:55:10 CET] <jkqxz> And streamcopy still isn't flushing properly, anyway.
[01:56:17 CET] <kierank> michaelni: can I revert that commit
[01:57:44 CET] <kierank> michaelni: let me know if you want a simple way to reproduce
[01:58:55 CET] <jkqxz> Oops, needed copyinkf to get it not to throw away all my packets.
[01:59:04 CET] <jkqxz> Seems to be correct now.
[02:02:03 CET] <jkqxz> Hmm, no.  It's still dropping the last packet.
[02:08:42 CET] <michaelni> kierank, a simple way to reproduce would be useful
[02:08:52 CET] <michaelni> doesnt this reproduce with a simple .h264 file ?
[02:09:03 CET] <kierank> not sure
[02:09:25 CET] <kierank> probably not
[02:09:36 CET] <kierank> because you can't see the leak unless you loop
[02:10:52 CET] <kierank> michaelni: sent pm
[02:29:54 CET] <jamrial> jkqxz: should i merge it or you want me to wait?
[02:46:17 CET] <jkqxz> Probably just merge it with that extra fixup?  Do skip it if there are any other problems, though, and I'll maybe look at it later.
[02:48:20 CET] <kierank> michaelni: that google patch might be a good fix
[02:48:56 CET] <kierank> works for me at least
[02:50:15 CET] <michaelni> kierank, thx for confirming, i do have some troubble reproducing. It does die here but it takes a really long time
[02:50:25 CET] <kierank> takes a few seconds for me
[02:50:35 CET] <michaelni> takes many minutes for me
[02:50:38 CET] <kierank> few seconds to use 5GB of ram
[02:50:43 CET] <kierank> many minutes to OOM sure
[02:51:17 CET] <kierank> michaelni: do you have an objection to the google change?
[02:51:24 CET] <kierank> https://ffmpeg.org/pipermail/ffmpeg-devel/2017-October/218212.html
[02:51:49 CET] <michaelni> i know the patch i was looking at it already
[02:52:03 CET] <michaelni> the annoying thing is it slows the code down
[02:52:20 CET] <kierank> I and that user have OOM in the real world because of it
[03:06:54 CET] <jamrial> jkqxz: fate passes, so i'll push it
[03:15:27 CET] <cone-233> ffmpeg 03Mark Thompson 07master:4d56f7ab8f62: avconv: Flush output BSFs when stream copy reaches EOF
[03:15:28 CET] <cone-233> ffmpeg 03James Almer 07master:a7da13474286: Merge commit '4d56f7ab8f627aa140c1ede1bb61305f01cefcdd'
[03:20:03 CET] <cone-233> ffmpeg 03Mark Thompson 07master:6ea220cbeec8: h264_sei: Add namespace prefix to all SEI values
[03:20:04 CET] <cone-233> ffmpeg 03Mark Thompson 07master:3daaa4417317: hevc: Add names for reserved NAL unit types
[03:20:05 CET] <cone-233> ffmpeg 03James Almer 07master:a33490ca2874: Merge commit '3daaa4417317ca732fb00476fdb3308d784f87e4'
[03:25:44 CET] <cone-233> ffmpeg 03Anton Khirnov 07master:126bc2c33b79: vp9_superframe_bsf: convert to the new bitstream reader
[03:25:45 CET] <cone-233> ffmpeg 03James Almer 07master:86c446ec61ca: Merge commit '126bc2c33b79c36bc23f43719d20f55b9b6771e9'
[09:49:16 CET] <cone-923> ffmpeg 03Nicolas George 07master:a8305b0ea3cc: lavfi/testsrc2: fix hang with very small sizes.
[11:22:35 CET] <ramiro> hi
[11:22:57 CET] <JEEB> ohai
[11:26:43 CET] <ramiro> what's the best way to save a decoder's context to attempt decoding of different frames from the same point in the stream?
[11:27:31 CET] <JEEB> as in, you have some data but you're not sure if it's for frame X or Y?
[11:27:43 CET] <JEEB> and you want to try one, if it fails reset the decoder state and try the other one?
[11:27:56 CET] <ramiro> for example, I decode IPPP, then I want to try decoding multiple manually edited P frames
[11:28:16 CET] <ramiro> JEEB: yes, that sounds like it.
[11:28:27 CET] <JEEB> that sounds like normal feeding to me? and not what I said
[11:28:37 CET] <JEEB> as in, you feed the normal stuff first and then the P frames that come after
[11:28:47 CET] <JEEB> unless your secondary explanation was off or I misread it :)
[11:28:47 CET] <ramiro> yes, the IPPP is normal feeding
[11:28:54 CET] <ramiro> it's probably off
[11:29:08 CET] <JEEB> so it's IPPP and then two branches I guess?
[11:29:20 CET] <JEEB> where you poke another P frame after the IPPP
[11:29:20 CET] <ramiro> but I take frame after IPPP, tweak it a little, and try decoding. then tweak it again, and try decoding again
[11:29:29 CET] <ramiro> yes, that's the word I was looking for, branching :)
[11:29:42 CET] <JEEB> yea, not sure how easily you can "freeze" the AVCodecContext
[11:29:49 CET] <JEEB> and go to that snapshot
[11:30:05 CET] <ramiro> my current idea is to just fork off the process multiple times :D
[11:30:25 CET] <JEEB> that sounds workable, I guess?
[11:30:32 CET] <JEEB> personally I would have just taken the performance hit
[11:30:47 CET] <JEEB> and made a function that generates a new one, and goes through the IPPP all the time
[11:31:09 CET] <ramiro> the thing is that I want real-time editing of values with instant feedback :/
[11:31:50 CET] <ramiro> so I have one frame displayed with all motion vectors, I can click and drag the motion vector, the frame gets decoded again (with the new mv injected into the bitstream) and the output is drawn to the screen
[11:33:14 CET] <ramiro> I'm currently targetting MPEG2
[11:33:42 CET] <JEEB> in that case I guess the worst thing wouldn't even be that bad since the GOP would be short and possible to re-decode from the get-go
[11:33:53 CET] <JEEB> and MPEG-2 Video decoding is pretty fast
[11:35:10 CET] <ramiro> hm, the GOP is set to be very long in this case (we don't want I frames to 'clean up' the image, the idea is to glitch the image)
[11:35:47 CET] <ramiro> at first I'll just keep going with re-decoding, since mpeg2 is indeed fast
[11:37:07 CET] <ramiro> if I were to go down the route of implementing context saving, what should I look out for? copying the struct, updating any pointers to inside the struct, copying image references (probably a deep copy)...
[14:15:42 CET] <kierank> michaelni: ping
[14:39:36 CET] <kierank> michaelni: anyway we found the root problem
[14:39:58 CET] <JEEB> cool
[14:42:07 CET] <J_Darnley> It certainly seems like it.  We didn't use the fuzzing script and crossed into Libav once
[14:42:40 CET] <J_Darnley> but the commit above is bad and previous is good (so far)
[14:42:53 CET] <J_Darnley> In a few minutes I am going to try the script.
[14:53:13 CET] <michaelni> kierank, yes, the first commit didnt look like it would be te root cause
[14:53:34 CET] <kierank> there are two separate issues here
[14:53:43 CET] <kierank> the google patch improves it but doesn't fix
[14:54:36 CET] <kierank> can we stop merging broken crap please
[14:54:37 CET] <kierank> kthx
[15:03:19 CET] <kierank> michaelni: so how can J_Darnley and I fix this?
[15:17:05 CET] <jamrial> BBB: ping
[15:17:17 CET] <BBB> jamrial: pong
[15:17:46 CET] <jamrial> BBB: what do you think of 3fb6b98b5e? (libav commit changing vp9 superframe merging filter)
[15:18:10 CET] <BBB> got a webgit link?
[15:18:20 CET] <jamrial> https://git.libav.org/?p=libav.git;a=commitdiff;h=3fb6b98b5e247434456916c35ba7e08efa03e85d
[15:18:40 CET] <jamrial> it seems to go on top of the code we skipped last time as well (https://pastebin.com/NjxYqKxV)
[15:19:30 CET] <BBB> looks good
[15:19:47 CET] <BBB> I like it
[15:19:52 CET] <jamrial> do i merge it including the skipped portion from the previous merge then?
[15:20:04 CET] <jamrial> don't know if it will apply otherwise...
[15:20:17 CET] <BBB> oh I see, there may be conflicts
[15:20:20 CET] <BBB> hm...
[15:20:40 CET] <BBB> difficult to say, I mean, its probably not hard to hand-apply it but you probably dont want that
[15:21:14 CET] <BBB> and hence I present again my utter frustration with the libav/ffmpeg split - were forced into doing stupid work twice
[15:21:30 CET] <BBB> if they had an expert reviewing their patches, we wouldnt be here
[15:21:39 CET] <BBB> but nobody there knows anything about vp9
[15:23:15 CET] <kierank> BBB: 
[15:23:16 CET] <kierank> 1:54:36 PM <"kierank> can we stop merging broken crap please
[15:23:16 CET] <kierank> 1:54:38 PM <"kierank> kthx
[15:23:16 CET] <kierank> :)
[15:24:10 CET] <BBB> ikr
[15:24:13 CET] <BBB> brb, phone call
[15:32:47 CET] <jamrial> BBB: the full merge would look like this https://github.com/jamrial/FFmpeg/commit/720ae081c2eaaca0e743658f113c6ca4ba73bb6f
[15:33:58 CET] <jamrial> (i like how github shows the actual effective changes rather than that weird three way diff with merges)
[15:46:36 CET] <BBB> jamrial: lgtm :) tnx
[16:12:39 CET] <cone-260> ffmpeg 03Anton Khirnov 07master:3fb6b98b5e24: vp9_superframe_bsf: cache input packets directly
[16:12:39 CET] <cone-260> ffmpeg 03James Almer 07master:e1bc3f4396ad: Merge commit '3fb6b98b5e247434456916c35ba7e08efa03e85d'
[16:14:38 CET] <cone-260> ffmpeg 03James Almer 07master:d7dcd825dea3: extract_extradata_bsf: make sure all needed parameter set NALUs were found
[16:14:39 CET] <cone-260> ffmpeg 03James Almer 07master:baf14a996bd4: Merge commit 'd7dcd825dea3681c69a35b3147a3b42f1bf078dd'
[16:17:53 CET] <jamrial> sigh, i was too noop happy that i forgot to merge some cosmetics yesterday
[16:18:26 CET] <jamrial> i disappointed ubitux
[16:18:48 CET] <ubitux> :(
[16:24:29 CET] <kierank> gotta merge cosmetics
[16:24:32 CET] <kierank> most important part of libav
[16:40:00 CET] <BBB> kierank: :D so trolly
[16:40:20 CET] <kierank> I am fed up of libav today
[16:40:35 CET] <kierank> having spent all last night and all morning trying to find their merge bug
[16:48:24 CET] <BBB> encourage the merge
[16:48:34 CET] <BBB> all I see is people trolling and hating and complaining
[16:48:42 CET] <BBB> but nobody ever says hey, this stinks, lets merge"
[16:48:52 CET] <BBB> isnt it the obvious fix?
[16:49:14 CET] <jamrial> the more it breaks the more fun to merge :p
[16:49:31 CET] <jamrial> (not really, that configure merge a few weeks ago was stressing)
[16:50:27 CET] <BBB> :(
[16:50:28 CET] <jamrial> it revealed so many pkg-config files are made without static builds in mind
[16:52:08 CET] <jamrial> i was able to fix one in its respective project, and reported it to another two. one of them fixed it, the other asked me to do it
[16:52:37 CET] <durandal_1707> Compn: do you have tivo ty files?
[16:57:09 CET] <cone-260> ffmpeg 03Anton Khirnov 07master:c3f0357bdf7d: hevcdec: move the MD5 context out of HEVCSEIPictureHash back into HEVCContext
[16:57:10 CET] <cone-260> ffmpeg 03James Almer 07master:bd8f1fa10007: avcodec/hevc_sei: rename HEVCSEIContext to HEVCSEI
[16:57:11 CET] <cone-260> ffmpeg 03James Almer 07master:9e2b0f32e905: avcodec/hevc_sei: reorder some parameters in static functions
[16:57:12 CET] <cone-260> ffmpeg 03James Almer 07master:b1ab02895b12: Merge commit 'c3f0357bdf7d3c542aad2c58b94184b9f56edc41'
[16:57:39 CET] <kierank> BBB: honestly they are not interested in merging
[16:57:45 CET] <kierank> i have come to terms with that
[16:59:08 CET] <BBB> they aren't
[16:59:10 CET] <BBB> but we should be
[16:59:17 CET] <BBB> why arent we?
[17:00:37 CET] <jkqxz> I am.  Am I us or them?
[17:00:42 CET] <jamrial> we aren't? short of one or two people i doubt anyone here would be against a merge of projects
[17:01:29 CET] <jamrial> but afaik those who tried didn't succeed
[17:05:27 CET] <atomnuker> we aren't, and its a majority. and in these days there isn't much we lack anyway and libav's one foot in the grave
[17:06:00 CET] <jamrial> why a majority?
[17:10:50 CET] <jkqxz> Does anyone here have any thoughts on the in-tree external-headers thing?  Should I take silence as general agreement with the position I suggested and call for a vote?
[17:12:14 CET] <mypopydev> @jkqxz
[17:12:28 CET] <jkqxz> Hi.
[17:12:33 CET] <mypopydev> Hi
[17:13:49 CET] <mypopydev> If HDR buffer size < Max Bit Rate in VBR mode ,is it have overflow risk ?
[17:15:42 CET] <cone-260> ffmpeg 03Anton Khirnov 07master:8652a2c24836: decode: fix the code reducing cropping to preserve alignment
[17:15:43 CET] <cone-260> ffmpeg 03Aaron Levinson 07master:3d040513a1de: avutil/hwcontext_dxva2: Don't improperly free IDirect3DSurface9 objects
[17:15:44 CET] <cone-260> ffmpeg 03Luca Barbato 07master:6a7e928555d0: configure: Do not check for the __builtin_vec_vsx_ld
[17:15:45 CET] <cone-260> ffmpeg 03James Almer 07master:51e091e2dcf1: Merge commit '3d040513a1de4797a4f81dde4984395f51db76b7'
[17:15:46 CET] <cone-260> ffmpeg 03James Almer 07master:092951f4a862: Merge commit '6a7e928555d081ff86c867867ebce74fdc4c87d6'
[17:15:50 CET] <jamrial> jkqxz: poke BtbN and philipl, since they are the ones maintaining the in-tree cuda/nvenc header
[17:16:14 CET] <BtbN> I'm on vacation.
[17:16:29 CET] <jamrial> BtbN: enjoy :p
[17:16:41 CET] <BtbN> But I don't have a problem with there being nvidia and/or AMD headers in the tree.
[17:16:55 CET] <jamrial> personally, i think having the headers in tree is nice as long as they are compact enough and maintained. these SDKs are many times hard to get and a pain to install
[17:17:15 CET] <BtbN> And removing the nvidia headers would mean loss of some features and would cause a mess in general, as they are nowhere to be acquired in that version, as they are hand-patched to behave.
[17:17:46 CET] <BtbN> Would end up with "to build ffmpeg with nvend, register with nvidia, apply those patches to what you download from them, and then extract those headers"
[17:17:58 CET] <BtbN> *nvenc/cuvid
[17:18:38 CET] <jkqxz> mypopydev:  Why would it be?  Overflow would only be a problem if the encoder doesn't actually follow the parameters given to it.
[17:19:12 CET] <BtbN> The AMD header really does not look bad to me, I'm fine with adding it.
[17:19:48 CET] <jkqxz> BtbN:  Why would the headers have to come from Nvidia directly?  They can be maintained in some separate repository for use by all open-source projects, including ffmpeg.
[17:20:02 CET] <BtbN> They could, but they aren't.
[17:20:06 CET] <jkqxz> Then you can make one.
[17:20:10 CET] <mypopydev> jkqxz: I know iHD driver will use the HDR buffer size internal :)
[17:20:20 CET] <jkqxz> If you think that people shouldn't get them from Nvidia.
[17:20:46 CET] <BtbN> The ones from nvidia just don't integrate niceley, so I modified them to work with ffmpeg and the dynamic loading it does.
[17:21:11 CET] <nevcairiel> I wouldn't consider an unofficial source to be really be a good idea for obtaining headers
[17:21:16 CET] <jkqxz> (Cf. Luca's mfx_dispatch stuff, to change the Intel headers into a form usable by other projects.)
[17:22:48 CET] <BtbN> If nvidia would put them on github themselves in a usable format, sure. But me putting them on github on my private repository, which would still be ffmpeg-specific, seems way way more messy.
[17:23:02 CET] <nevcairiel> lucas mfx_dispatch only adds autotools ontop of the intel stuff, its hardly an advantage in my book =p
[17:23:54 CET] <jkqxz> mypopydev:  So it's fine, then?
[17:24:18 CET] <BtbN> It's not a lot of code, it does not cause any issues to my knowledge, and makes the nvidia features a lot more accessible.
[17:25:14 CET] <BtbN> The nvenc/cuvid headers have been on the ml multiple times, with extended times for discussion, and every time it was concluded they were fine. I don't get why they suddenly aren't anymore.
[17:25:20 CET] <jkqxz> Can you reply to my mail proposing specific criteria for what headers should be kept in-tree then, please?
[17:25:49 CET] <mypopydev> jkqxz:  VBR mode with old HDR buffer size setting will lead the bit rate control fail in small  resolution in iHD driver
[17:25:53 CET] <jkqxz> I was always weakly against it, but never really care because I don't use Nvidia.
[17:27:07 CET] <jkqxz> The reason I'm raising this now is that including the AMD headers seems ridiculous (because they are trivially available upstream), but rejecting them is somehow facilitating Nvidias hostile anti-open behaviour.
[17:27:56 CET] <jkqxz> So really I want clarity over the rules.
[17:29:34 CET] <jkqxz> If the answer is that the Nvidia headers should stay, then fine.  But please codify exactly why that is happening so that we can apply it consistently to other projects.
[17:33:25 CET] <jkqxz> (And if that is "companies with hostile anti-open behaviour are given extra assistance by ffmpeg to make money" then please say so explicitly, so that contributors can see that that is official policy.)
[17:35:08 CET] <jkqxz> mypopydev:  That sounds like a driver bug.  How does it fail?
[17:36:08 CET] <jkqxz> (Though tbh I would prefer if we could just not specify the HRD parameters at all in this case, but IIRC some drivers require it to not explode.)
[17:37:13 CET] <cone-260> ffmpeg 03Elviss Strazdins 07master:2017ffc18fe4: vaapi: Add ABGR map only if VA_FOURCC_ABGR is defined
[17:37:14 CET] <cone-260> ffmpeg 03James Almer 07master:c2e3cfd060a3: Merge commit '2017ffc18fe4d33b954dd8a50b086f310f17a329'
[17:37:18 CET] <BtbN> jkqxz, is that header he submited really easily available, or would you have to condense it ouf of all the stuff that's in the SDK?
[17:37:41 CET] <BtbN> And if you can avoid downloading and installing a usually massive vendor SDK, that seems like a nice reason to add a single header to ffmpeg.
[17:38:29 CET] <jkqxz> For AMD?  It's all at <https://github.com/GPUOpen-LibrariesAndSDKs/AMF>.
[17:39:03 CET] <BtbN> That's _a lot_ more stuff than just one header
[17:39:07 CET] <BtbN> and included a fork of ffmpeg
[17:39:08 CET] <jkqxz> I think he's combined various different headers in a way which is kindof confusing, though.
[17:39:09 CET] <BtbN> *s
[17:39:44 CET] <jkqxz> <https://github.com/GPUOpen-LibrariesAndSDKs/AMF/tree/master/amf/public/include>, then.
[17:39:46 CET] <BtbN> That's what was originally proposed
[17:40:51 CET] <jkqxz> I don't see combining headers as a good idea.  It means that you can only use the internal one, even you have an external one of a different version which you'd really like to use.
[17:43:11 CET] <BtbN> Yeah, those AMD headers looks easily packageable. But them having a full copy of ffmpeg seems weird and could complicate that.
[17:44:44 CET] <mypopydev> the encoded video bit rate will much larger than target bit rate when encode some small resolution images in VBR mode
[17:50:37 CET] <jkqxz> If the encoded bitrate is much larger than the target bitrate then the driver is just broken, isn't it?
[17:51:02 CET] <jkqxz> (Unless you really have asked it to do something impossible, like encode at 1bps or whatever.)
[18:01:43 CET] <cone-260> ffmpeg 03Martin Storsjö 07master:427f7a1f9ec1: configure: Fix the msvcrt version check for mingw32
[18:01:44 CET] <cone-260> ffmpeg 03Luca Barbato 07master:91622f6446b4: avconv: Always initialize the opkt struct on streamcopy
[18:01:45 CET] <cone-260> ffmpeg 03James Almer 07master:dbde588917c3: Merge commit '427f7a1f9ec1977bcb57cb4d6e6f7228dc1e858b'
[18:01:46 CET] <cone-260> ffmpeg 03James Almer 07master:88c7aa13dd30: Merge commit '91622f6446b463abe6507ad2cd5d1fbf7e49c424'
[18:13:34 CET] <Compn> j-b tried to merge the projects 
[18:13:52 CET] <j-b> and get money to pay everyone :)
[18:13:58 CET] <Compn> :)
[18:14:06 CET] <Compn> i think last i heard j-b abandoned that idea 
[18:14:21 CET] <j-b> I never abandon ideas
[18:14:30 CET] <Compn> oh ok :)
[18:14:51 CET] <kierank> I envy your optimism
[18:15:50 CET] <j-b> I like food also
[19:13:02 CET] <BBB> jamrial: Im not talking about people threatening to blow themselves up if we merge
[19:13:11 CET] <BBB> jamrial: Im talking about people that are just generally not excited about it
[19:13:19 CET] <BBB> jamrial: we have too many people like that
[19:13:22 CET] <jamrial> :/
[19:13:24 CET] <BBB> jamrial: and thats fine, its their right
[19:13:29 CET] <BBB> Im not against free choice or anything
[19:13:42 CET] <BBB> but as long as many people are not excited about it or would rather see it not happen, its not going to happen
[19:13:59 CET] <BBB> Im ok if they merge into us is not excited
[19:14:36 CET] <BBB> when I talked to j-b about it, I explained that merging is painful for both sides, it means giving up some autonomy for both sides, it probably means giving up parts of the codebase to them and their way - itll seriously hurt some feelings
[19:14:42 CET] <BBB> and I dont think most of us are ready for that
[19:15:02 CET] <BBB> we are ready to win but not to move on
[19:15:10 CET] <BBB> and nobody will win, because it means the other side "loses"
[19:15:20 CET] <BBB> i.e. not gonna happen
[19:15:24 CET] <BBB> (why would they?)
[19:15:35 CET] <BBB> regardless of whether they is ffmpeg or libav
[19:15:56 CET] <atomnuker> we "won" quite some time ago
[19:16:09 CET] <jamrial> atomnuker: not the point
[19:16:16 CET] <BBB> jkqxz: if youre excited about a merge, I applaud your enthusiasm and I hope we can keep that alive; please remain excited about it, maybe some day itll happen
[19:16:27 CET] <BBB> Im pro-merge
[19:16:42 CET] <BBB> but I know and accept that most people are not
[19:17:21 CET] <jkqxz> I am very pro-merge, but I have no idea how to go about it which people would accept.
[19:17:22 CET] <jamrial> BBB: you know they are not pro-merge, or just not excited while not being against it, as you said above?
[19:18:56 CET] <jamrial> i'm pro-merge, obviously. it would mean a lot of duplicate work gone plus less headaches for downstreams
[19:18:57 CET] <BBB> they are not ready to suffer for it
[19:19:12 CET] <alevinsn> here's my take on a libav/ffmpeg merge:  libav already gets the benefits of a merge without having to do anything
[19:19:14 CET] <BBB> if youre not ready to suffer from it (or youre ok with them joining our project), then youre not pro-merge
[19:19:14 CET] <jamrial> also i'm very interested in the thing j-b said about money :p
[19:19:22 CET] <alevinsn> since many libav changes are eventually merged into ffmpeg
[19:19:45 CET] <alevinsn> so, they know that if a distribution only uses ffmpeg, their changes will eventually benefit users of either ffmpeg or libav
[19:19:56 CET] <BBB> and btw Im not claiming that ffmpeg devs are terrible and libav people are brilliant; I think many of them have issues with the concept also
[19:20:02 CET] <BBB> but that just means were not ready to merge
[19:20:37 CET] <alevinsn> and they might say that ffmpeg is taking their contributions and not giving them any credit, etc, etc, but if the frequency libav merges into ffmpeg didn't occur
[19:21:20 CET] <alevinsn> then, I wonder if there would be much of a future for libav--at the same time, I wonder if the reason distributions switched to ffmpeg because they know changes in libav will make it into ffmpeg
[19:21:45 CET] <alevinsn> switched back to ffmpeg, I mean
[19:22:16 CET] <BBB> alevinsn: I think thats certainly part of it; but itd be easier for us if there was no fork, look at the crap jamrial has to deal with for every merge commit
[19:22:18 CET] <nevcairiel> some of the popular distributions only ever "switched" to libav because their package maintainer was on their side, its not like it was an  independent decision
[19:22:19 CET] <BBB> poor guy :(
[19:22:42 CET] <jamrial> and they switched back mainly because of the big amount of bug fixes in our tree not present in libav in the long run
[19:23:00 CET] <alevinsn> yeah, I think they said security bug fixes being the main reason to switch back
[19:23:04 CET] <BBB> at the end of the day, atomnuker has a point that ffmpeg is generally considered more featureful and providing a better end user experience ATM (including bug fixes, e.g. michaels fuzz-fix stuff)
[19:23:12 CET] <alevinsn> in articles that I've read on the topic
[19:23:13 CET] <BBB> but the merges suck and will continue to suck
[19:23:30 CET] <nevcairiel> personally, i couldnt use libav for my projects, there is too much stuff in ffmpeg that I rely on
[19:23:56 CET] <alevinsn> a few months ago, back when I was a little more active in ffmpeg-devel, I had considered writing an e-mail suggesting to stop doing the merges and let ffmpeg chart its own path
[19:24:35 CET] <jamrial> BBB: speaking of merges sucking, that vp9_superframe one apparently wasn't good :(
[19:24:40 CET] <BBB> :(
[19:24:43 CET] <alevinsn> I was going to say something about how patches linger in ffmpeg-devel for weeks if not months, and the time and energy spent doing merges perhaps could be better spent focusing on ffmpeg itself
[19:24:45 CET] <BBB> it broke the fate test?
[19:25:25 CET] <jamrial> fate-matroska-remux, different md5 value each run
[19:25:35 CET] <BBB> yes, thats why that tests exists
[19:25:36 CET] <BBB> :)
[19:25:44 CET] <BBB> good to see it caught it
[19:28:53 CET] <BBB> not sure why, the test looks ok
[19:28:55 CET] <BBB> sorry
[19:28:58 CET] <BBB> the patch looks ok
[19:29:37 CET] <ubitux> jamrial: valgrind is complaining
[19:30:05 CET] <ubitux> http://fate.ffmpeg.org/report.cgi?time=20171031182548&slot=x86_64-archlinux-gcc-valgrind-no-undef
[19:30:43 CET] <jamrial> yeah, that's the test we're talking abotu :p
[19:30:47 CET] <BBB> s->cache[s->n_cache++] = in;
[19:30:52 CET] <BBB> I think you need to ref it?
[19:31:07 CET] <BBB> av_packet_ref(&s->cache[s->n_cache++], in);
[19:31:08 CET] <BBB> or so
[19:31:09 CET] <BBB> dunno
[19:31:38 CET] <jamrial> tried doing move_ref but it segfaulted
[19:38:45 CET] <jamrial> BBB: https://pastebin.com/5Ms7B6vN seems to work
[19:39:05 CET] <michaelni> jamrial, e1bc3f4396ade6033787717d3650fb62663eae87 breaks fate-matroska-remux
[19:39:22 CET] <jamrial> michaelni: yes, we're talking about that :p
[19:39:23 CET] <BBB> can you prevent the repeated alloc/free pairs by just doing alloc at the beginning of the filter (or once) and once at the end?
[19:39:35 CET] <michaelni> jamrial, ahh ok
[19:39:37 CET] <BBB> i.e. do alloc only if its null
[19:39:47 CET] <BBB> and then after alloc only do ref/unref as you do now
[19:39:52 CET] <BBB> and free at the end (which you already do)
[19:39:54 CET] <BBB> is that possible?
[19:40:04 CET] <BBB> (overhead of alloc is probably minor, but hey, why not)
[19:49:10 CET] <jamrial> BBB: alternatively, i could just put all the packets in VP9BSFContext instead of an array of pointers
[19:50:39 CET] <BBB> is the AVPacket size part of the ABI?
[19:51:12 CET] <jamrial> yeah
[19:51:21 CET] <BBB> oh I thought it wasn't
[19:51:25 CET] <BBB> ok, if it is, then thats fine, yes
[19:51:29 CET] <BBB> sorry I didnt know that
[20:03:43 CET] <jamrial> BBB: https://pastebin.com/82qDyHpF
[20:03:58 CET] <jamrial> i kept it as pointers. the diff would be bigger otherwise
[20:04:09 CET] <BBB> ok
[20:04:10 CET] <BBB> lgtm
[20:04:11 CET] <BBB> tnx
[20:07:04 CET] <lotharkript> QQ regarding has_b_frames. In the case sps does not have bitstream_restriction_flag )for H264), and the file is a MP4, we will not set the has_b_Frames during avformat_find_stream_info.  But if later we do have B frames, we are dropping them and get the message: Increasing reorder buffer to 1. Can we not use the CTTS table of the MP4 to detect is the stream has b frames?
[20:07:43 CET] <BBB> isnt that a broken file then?
[20:07:55 CET] <BBB> or do they occur in the wild?
[20:08:21 CET] <lotharkript> it is not a broken file. It is a valid file where the bitstream_restriction_flag is not set and the first N frames are only P frames, then we start to get B frames.
[20:09:06 CET] <lotharkript> we are using sps->num_reorder_frames for has_b_frames for h264
[20:10:28 CET] <lotharkript> and in case of Mp4, we may just parse the first video frame and the check for has_codec_parameters return true, so we do not parse more video frames.
[20:10:43 CET] <lotharkript> Even if we were to parse more video frames, we will stop after X frames.
[20:11:09 CET] <lotharkript> this is why i was asking if we could use the CTTS from the MP4 to detect B frames and set the video_delay within the demuxer
[20:12:03 CET] <BBB> hm I see& sounds reasonable to m
[20:12:04 CET] <BBB> e
[20:12:45 CET] <lotharkript> michaelni what do you think? can we trust the CTTS to detect B frames?
[20:14:01 CET] <kierank> michaelni: so the problem is basically the nal cache is too big
[20:14:21 CET] <kierank> so 524 NALs @ 6MB each ends up using 3GB
[20:14:58 CET] <kierank> per thread i think
[20:29:57 CET] <cone-260> ffmpeg 03James Almer 07master:37f4a093f7f9: avcodec/vp9_superframe_bsf: allocate cache of packets during init
[20:37:45 CET] <cone-260> ffmpeg 03Paul B Mahol 07master:e6055af025c1: avfilter: pass correct argument to helper function
[20:37:46 CET] <cone-260> ffmpeg 03Paul B Mahol 07master:d0920da029c5: avfilter/af_join: switch to activate
[20:38:33 CET] <michaelni> jamrial, a7da13474286774cf378c3ea606c19a7c1a0eba3 breaks  ./ffmpeg -i ~/tickets/679/subtitles.ts -filter_complex '[0:v][0:s:0]overlay[vid]' -map  '[vid]' -t 3 test.av
[20:39:02 CET] <michaelni> test.avi
[20:41:13 CET] <kierank> michaelni: so yes I think you are right, it's all the nal cache exploding in mem usage
[20:42:08 CET] <jamrial> michaelni: huh, SIGFPE
[20:48:40 CET] <michaelni> lotharkript, this sounds like Ticket6487 a bit, if so i just posted a patch for this. It doesnt need CTTS nor is it mov dependant. 
[20:50:20 CET] <lotharkript> michealni this may not work if you get the first gop of only P frames...
[20:50:35 CET] <kierank> michaelni: your suggestion doesn't stop the nal cache from ballooning
[20:51:02 CET] <lotharkript> michaelni should we not then in the h264 set the has_b_frames to MaxDpbFrames if bitstream_restriction_flag is not set?
[20:51:28 CET] <lotharkript> michaelni of course, set it for all the non INTRA mode of h264
[20:55:32 CET] <jamrial> jkqxz: can you look at the failure michaelni posted above? ist->dec_ctx in process_input_packet() seems to not be filled after the stream copy eof change
[20:57:42 CET] <michaelni> lotharkript, i think using the max allowed could introduce significnat decoder delay which some users would find unacceptable
[20:58:40 CET] <michaelni> lotharkript, iam not against also using CTTS if it helps some real world files
[21:00:11 CET] <michaelni> rather, if it helps more files than it harms
[21:00:35 CET] <lotharkript> michaelni if the max delay is too much, then should they not make sure to set the bitstream_restriction_flag?
[21:08:38 CET] <michaelni> lotharkript, doesnt work. For example if we start using the max delay .existing files and streams and encoder parameters wont change wich is where the flag is
[21:19:59 CET] <BBB> lots of police here :-/
[21:23:27 CET] <kierank> hmmm i am meant to be going to new york on holiday in a few weeks
[21:38:19 CET] <durandal_1707> kierank: not visiting me?
[21:44:16 CET] <kierank> No
[21:44:35 CET] <durandal_1707> :(
[21:49:01 CET] <iive> BBB: is "here" in New York? 
[21:49:35 CET] <BBB> yes
[21:50:01 CET] <iive> There is news for a truck plowing into cyclists, killing 6.
[21:51:44 CET] <BBB> I read about it, its right around the corner here, and yes it explains the sudden police
[21:52:45 CET] <BBB> gonna get a drink&
[21:53:03 CET] <BBB> pretty insane
[22:01:01 CET] <iive> about the merges. Somebody had told me, that more people were sending patches to both libav and ffmpeg, during the time when ffmpeg stopped merging for a while.
[22:02:03 CET] <Compn> durandal_1707 : i do not personally have such files, iirc there are some on the trac and in allsamples.txt , ask carl he may have more 
[22:02:21 CET] <Compn> iive : why are you watching american news? :P
[22:03:00 CET] <Compn> durandal_1707 : did tivo retire that format or does it continue ?
[22:03:28 CET] <iive> Compn: to see what's up with the pumpkin ;)
[22:03:32 CET] <jamrial> iive: other devs cherry picked libav commits themselves during that time, yes
[22:03:47 CET] <Compn> iive : today is pumpkin holiday too :P
[22:04:16 CET] <jamrial> i wouldn't call that "sent more patches" since the end result is them wanting something merged
[22:20:16 CET] <alevinsn> not sure if anyone is here, but does anyone know why, in qsvdec.h, after calling av_hwdevice_ctx_create(), it uses av_hwframe_ctx_alloc(), but
[22:20:22 CET] <alevinsn> in hw_decode.c
[22:20:31 CET] <alevinsn> it does the equivalent with just av_buffer_ref?
[22:20:46 CET] <alevinsn> under doc/examples
[22:20:48 CET] <durandal_1707> nobody is home
[22:20:59 CET] <alevinsn> yeah, I know, late where most are based
[22:25:53 CET] <alevinsn> whoops, looks I misread the code--one is setting hw_device_ctx, while the other is setting hw_frames_ctx
[22:39:16 CET] <jkqxz> jamrial: michaelni:  The "Stream #0:2[0x250](eng): Audio: mp3 ([4][0][0][0] / 0x0004), 0 channels (visual impaired)" doesn't seem to be mp3.
[22:39:44 CET] <jkqxz> So the dec_ctx doesn't contain anything useful.
[22:41:20 CET] <jkqxz> I don't see why it's doing anything with that stream at all.  Presumably that's my fault somehow...
[22:42:25 CET] <jamrial> BBB: does fate-matroska-remux work for you?
[22:42:43 CET] <jamrial> it's working for me on windows, but a lot of linux boxes in fate are still complaining
[22:43:07 CET] <jamrial> i don't know wtf is going on
[22:45:57 CET] <BBB> jamrial: I havent tested
[22:46:06 CET] <BBB> are they on pre-patch or post-patch?
[22:47:37 CET] <jkqxz> It's during flushing.  Previously process_input_packet() wasn't called at all because ist->decoding_needed wasn't set.
[22:47:38 CET] <BBB> most of fate is not realtime
[22:49:03 CET] <jkqxz> But now we do because it wants to flush bitstream filters on that stream.
[22:52:25 CET] <jkqxz> Since the flush packets have no useful information and we don't want to use it in the output anyway, I'm tempted by <http://sprunge.us/KULN>?
[22:52:36 CET] <jkqxz> *useful timing information
[22:53:03 CET] <jkqxz> (I.e. adjust the change which was made at the merge.)
[22:53:07 CET] <BBB> jamrial: will test, but rebasing my tree tends to take a while so dont hold your breath quite yet
[22:54:08 CET] <jkqxz> I think that makes sense, because no input has been consumed when a flush packet is being sent there, so input stream timestamps should not advance.
[22:56:50 CET] <jamrial> BBB: post patch. latest commit, even
[22:57:44 CET] <jamrial> and thanks
[22:58:17 CET] <BBB> it fails here, yes
[22:58:48 CET] <jamrial> jkqxz: that seems to work, but i'll leave the real testing to michaelni
[22:59:19 CET] <BBB> heap-use-after-free
[22:59:23 CET] <jamrial> we need to add new tests for each of these weird failures, really
[22:59:26 CET] <BBB>     #0 0x1085363e6 in wrap_free (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x593e6)
[22:59:27 CET] <BBB>     #1 0x10735fa9c in av_buffer_unref (ffmpeg:x86_64+0x100d11a9c)
[22:59:41 CET] <jkqxz> michaelni:  <http://sprunge.us/KULN>, for the ticket 679 subtitles one.
[23:02:53 CET] <BBB> backtrace not terribly helpful, will need to recompile with -fsanitize=address and -O0
[23:02:55 CET] <BBB> :(
[23:07:53 CET] <BBB>     #1 0x107dceb68 in merge_superframe vp9_superframe_bsf.c:66
[23:07:57 CET] <BBB> and then memcpy
[23:08:11 CET] <BBB> the read is already free()'ed
[23:12:01 CET] <michaelni> is fate-matroska-remux supposed to give different results on each run ?
[23:12:33 CET] <jamrial> michaelni: no, the fix i committed wasn't complete
[23:12:48 CET] <jamrial> it works on windows, but for some reason not on linux
[23:23:27 CET] <BBB> hm...
[23:23:28 CET] <BBB> so...
[23:23:29 CET] <BBB> jamrial
[23:23:31 CET] <BBB> if you do: av_packet_move_ref(s->cache[s->n_cache++], in);
[23:23:39 CET] <BBB> and then av_packet_free(&in);
[23:23:43 CET] <BBB> doesnt that double-free in?
[23:23:53 CET] <BBB> also, why free? why not just unref?
[23:24:02 CET] <jamrial> move_ref doesn't free the packet
[23:24:04 CET] <nevcairiel> move_ref only unrefs the packet, free deallocates it
[23:24:11 CET] <jamrial> it moves the buffer reference, and then inits it to defaults
[23:26:04 CET] <jamrial> the the free(&in) line was there pre merge. every bsf does it for that matter, since the bsf api wont
[23:27:03 CET] <BBB> hm& so where is the free happening then?
[23:27:07 CET] <BBB> something is fishy
[23:28:03 CET] <nevcairiel> the content should probably be free'ed whenever it takes something out of the cache and uses it
[23:28:24 CET] <jamrial> merge_superframe() is called once even packet is buffered, and once that's done the packets are unref'd
[23:29:11 CET] <jamrial> s/even/every
[23:31:22 CET] <BBB> $ make clean
[23:31:22 CET] <BBB> rm: libavcodec/~: is a directory
[23:31:23 CET] <BBB> ?
[23:32:51 CET] <jamrial> i don't get that :/
[23:41:57 CET] <beastd> BBB: Do you have by chance a directory named '~' under libavcodec which "make clean" is trying to delete because it does rm *~ or similar?
[23:59:17 CET] <jamrial> BBB: seems that ffmpeg.c is freeing the packet, somehow
[23:59:41 CET] <jamrial> chaging the move_ref to a normal ref seems to fix it
[00:00:00 CET] --- Wed Nov  1 2017