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

[burek]

[00:31:52 CEST] <jamrial> iive: could you test the xvmc stuff? looking at it, flipping FF_API_XVMC to 0 cleanly disables everything related to the old decoders and pixfmts but doesn't affect the hwaccels at all
[00:32:19 CEST] <jamrial> so maybe it doesn't need any further changes to make sure the hwaccels work post bump
[00:32:23 CEST] <iive> jamrial: i can't test at the moment, due to hardware problems
[00:32:48 CEST] <jamrial> i see
[00:32:50 CEST] <iive> i'll try to do it soon-ish
[00:32:56 CEST] <jamrial> alright
[01:03:21 CEST] <cone-588> ffmpeg 03James Almer 07master:c9a1cd08eafe: avcodec/hevc_ps: improve check for missing default display window bitstream
[01:53:06 CEST] <cone-588> ffmpeg 03Michael Niedermayer 07master:380659604f26: avcodec/shorten: Move buffer allocation and offset init to end of read_header()
[01:53:07 CEST] <cone-588> ffmpeg 03Michael Niedermayer 07master:abf3f9fa2324: avcodec/hevc_ps: Fix c?_qp_offset_list size
[01:53:08 CEST] <cone-588> ffmpeg 03Michael Niedermayer 07master:e952d4b7ace6: avcodec/hevc_ps: Fix limit of chroma_qp_offset_list_len_minus1
[02:49:17 CEST] <cone-588> ffmpeg 03Michael Niedermayer 07release/3.3:0c5eb03aac6f: avcodec/shorten: Move buffer allocation and offset init to end of read_header()
[02:49:18 CEST] <cone-588> ffmpeg 03Michael Niedermayer 07release/3.3:de260c7b34de: avcodec/hevc_ps: Fix c?_qp_offset_list size
[02:49:19 CEST] <cone-588> ffmpeg 03Michael Niedermayer 07release/3.3:41479c83aea0: Changelog: update
[03:29:10 CEST] <cone-588> ffmpeg 03James Almer 07release/3.3:e3a1c0491fa2: avcodec/hevc_ps: improve check for missing default display window bitstream
[03:42:33 CEST] <cone-588> ffmpeg 03Michael Niedermayer 07n3.3.4:HEAD: avcodec/hevc_ps: Fix limit of chroma_qp_offset_list_len_minus1
[03:53:12 CEST] <jamrial> michaelni: ah, sorry, didn't know you were in the middle of tagging the release and backported something
[04:06:02 CEST] <michaelni> jamrial, no problem, that was a rare coincidence 
[07:51:58 CEST] <ubitux> damn, asan is stalled again
[07:52:44 CEST] <ubitux> seems it's stalled in fate-filter-dcshift
[11:08:25 CEST] <cone-209> ffmpeg 03Nicolas George 07master:76613618d978: lavfi: add helper functions and macros for activate.
[11:08:26 CEST] <cone-209> ffmpeg 03Nicolas George 07master:567d318b1cc1: lavfi/af_agate: use helper macros.
[11:08:27 CEST] <cone-209> ffmpeg 03Nicolas George 07master:61b0b03f3fdc: lavfi/af_sidechaincompress: use helper macros.
[11:08:28 CEST] <cone-209> ffmpeg 03Nicolas George 07master:1b8e061cc574: lavfi: remove framesync.
[11:08:29 CEST] <cone-209> ffmpeg 03Nicolas George 07master:5f5dcf44e3c4: lavfi: rename framesync2 to framesync.
[11:08:30 CEST] <cone-209> ffmpeg 03Nicolas George 07master:064c9d45ff10: doc: update filter_design.txt.
[12:30:07 CEST] <cone-209> ffmpeg 03Nicolas George 07master:9bad5e531910: lavfi/framesync: reword repeatlast option help.
[12:37:14 CEST] <cone-209> ffmpeg 03Nicolas George 07master:549ef6ef9a81: lavfi/framesync: remove dead code.
[14:22:07 CEST] <cone-209> ffmpeg 03Ronald S. Bultje 07master:183216b21870: frame_thread_encoder: make 'exit' member atomic.
[14:26:50 CEST] <brash> I am getting an error of "Invalid data found when processing input". Specifically this error is happening at avformat_write_header(). I am wanting to mux a video stream (h264) into a matroska container. It seems that this error is happening when avformat_write_header() is calling init_pts() and not init_muxer(). This is with libavformat version 56.40. I know it's old, but upgrading requires a lot of hoops working around dependencies. Any 
[14:35:17 CEST] <brash> If it means anything, I am following the example at http://www.ffmpeg.org/doxygen/2.8/muxing_8c_source.html
[16:10:43 CEST] <brash> Anyone know where to begin debugging an "Invalid data found when processing input" error when trying to mux an h264 stream encoded with libx264 into an mkv container?
[16:10:57 CEST] <brash> I am getting the error at avformat_write_header().
[16:28:50 CEST] <jkqxz> brash:  Step through avformat_write_header() (and callees) with a debugger to find where the error is generated?
[16:46:01 CEST] <brash> jkqxz: I've been trying that, but I think since I don't have ffmpeg compiled with debugging flags it won't show any symbols.
[16:47:03 CEST] <brash> jkqxz: It's a new library for me, and I think that I just need to keep working with it until I figure out what is going. I am still figuring out the difference between AVCodec and AVCodecContext structs, ect.
[16:48:12 CEST] <brash> Of course all frustration is on my part for thinking that writing a 'simple' program with ffmpeg would be anything but.
[17:04:41 CEST] <jkqxz> --enable-debug
[17:07:18 CEST] <brash> For anyone wondering what I did wrong, I had a pointer that I was not pointing back to the codec in my AVStream.
[19:13:37 CEST] <ubitux> i have to disable the asan fate instance
[19:13:48 CEST] <ubitux> as it stalls ffmpeg
[19:17:20 CEST] <jamrial> ubitux: could it be an asan bug? seeing you updated gcc
[19:17:37 CEST] <ubitux> i updated after it was already stalled
[19:17:39 CEST] <ubitux> so dunno
[19:17:46 CEST] <jamrial> does it happen with an specific test, or all?
[19:18:20 CEST] <jamrial> maybe it was a recent ffmpeg commit
[19:25:25 CEST] <cone-209> ffmpeg 03Michael Niedermayer 07master:4c88087f934b: avformat/mxfenc: Replace more literal magic numbers by enum values.
[19:25:26 CEST] <cone-209> ffmpeg 03Michael Niedermayer 07master:4c33ec004fd8: avformat/mxfenc: Comment edit rate write code like the surrounding code
[19:25:27 CEST] <cone-209> ffmpeg 03Michael Niedermayer 07master:de03eb622d30: avformat/mxfenc: Correct the Sample rate for PCM outside D10
[19:25:51 CEST] <michaelni> ubitux, what do you mean by "stalled" ?
[19:26:51 CEST] <ubitux> infinite loop, no cpu usage
[19:27:17 CEST] <ubitux> jamrial: previous one was fate-filter-dcshift, didn't check that last one
[19:28:02 CEST] <michaelni> ubitux, random guess, is this threads related ? does it also happen with threads disabled?
[19:28:31 CEST] <ubitux> i didn't enable threads on asan
[19:28:56 CEST] <jamrial> ubitux: maybe eea69a9f25
[19:29:32 CEST] <jamrial> first change in two years, and it more or less matches the point when your fate clients stalled
[19:29:52 CEST] <ubitux> i'll do some checks around this then
[19:29:58 CEST] <ubitux> but not today, maybe tmr
[19:32:42 CEST] <jamrial> yep, sep 6 was the last time asan had a successful run, using a snapshot before the above commit
[19:47:50 CEST] <jamrial> durandal_1707: commit eea69a9f25 seems to make fate-filter-dcshift stall when run under gcc asan
[19:54:48 CEST] <durandal_1707> jamrial: i see nothing wrong with that commit
[19:56:34 CEST] <jamrial> can reproduce the stall if you compile using the asan configure toolchain?
[19:58:55 CEST] <jamrial> s/can/can you/
[20:12:28 CEST] <ubitux> the fate test should include a perms filter :p
[20:12:32 CEST] <jamrial> ubitux, durandal_1707: https://pastebin.com/Jk5HFexh
[20:12:50 CEST] <ubitux> try to insert an aperms filter :p
[20:12:56 CEST] <ubitux> afk bbl
[20:13:15 CEST] <jamrial> ubitux: doesnt' change the fact asan shouldn't segv :p
[20:14:33 CEST] <jamrial> reverting the above commit "fixes" it
[20:20:37 CEST] <durandal_1707> i see nothing wrong with commit
[20:24:21 CEST] <durandal_1707> found it
[20:29:36 CEST] <cone-209> ffmpeg 03Paul B Mahol 07master:04b9010f7f54: avfilter/af_dcshift: do not leak out frame
[20:31:05 CEST] <jamrial> durandal_1707: confirmed working, thanks
[20:31:07 CEST] <jamrial> ubitux: ^
[20:41:53 CEST] <ubitux> durandal_1707: jamrial: cool, thanks :)
[20:41:55 CEST] <ubitux> will re-enable
[20:49:40 CEST] <BBB> ah crap tsan doesnt like vp9 tile threading
[20:49:41 CEST] <BBB> now what
[20:49:49 CEST] <BBB> also the webinterface is slow?
[20:49:52 CEST] <BBB> whats going on...
[20:49:56 CEST] <BBB> takes like a minute to load the page
[20:52:47 CEST] <jamrial> BBB: tsan's logs can be massive, and the more tests fail the slower it will be to load
[20:54:12 CEST] <BBB> hm, I see
[20:54:13 CEST] <BBB> ok...
[20:54:21 CEST] <BBB> so it looks like tsan doesnt like atomic integers
[20:54:32 CEST] <BBB> do we have an atomic integer expert who can fix that for us?
[20:55:01 CEST] <BBB> Ive never understood the exact access models for atomic integers, and it all seems theoretical since in practice (on x86) the test doesnt actually fail in terms of md5
[20:58:25 CEST] <ubitux> the vp9 tiling is pushed?
[20:59:09 CEST] <ubitux> ah, seems so
[20:59:41 CEST] <BBB> yes
[20:59:44 CEST] <BBB> sorry, I broke tsan
[20:59:57 CEST] <BBB> ubitux: can you test a patch for me on the tsan-slice station?
[21:00:27 CEST] <ubitux> i can test locally, i'd like to make a full run of the fate instances that has been on hold for a while
[21:00:28 CEST] <BBB> (it doesnt really seem to be very consistent here locally&)
[21:00:35 CEST] <BBB> sure, no rush or anything
[21:00:41 CEST] <ubitux> branch?
[21:00:57 CEST] <BBB> just master+patch
[21:01:01 CEST] <BBB> oh you want a github branch?
[21:01:03 CEST] <BBB> sec
[21:02:16 CEST] <ubitux> you can send me a patch too, that's fine
[21:03:44 CEST] <ubitux> BBB: btw, i don't really care about tsan slices for now, i'm still obsessed with tsan turning green (but i know i didn't do much about the threading issues)
[21:04:01 CEST] <ubitux> tsan as in "tsan frames"
[21:06:22 CEST] <BBB> https://pastebin.com/3TnjqvA8
[21:06:27 CEST] <BBB> yes, tsan-frame would be nice to fix entirely
[21:07:00 CEST] <BBB> I *believe* the frame_thread_encoder should be green. at some point I may dive into making mpeg4 happy also (thats the only remaining issue) but Im not exactly excited to start on that :-p
[21:08:07 CEST] <ubitux> didn't michael submit a prototype for this?
[21:08:16 CEST] <ubitux> like, ranges of stuff to copy or whatnot
[21:08:26 CEST] <BBB> he did
[21:08:44 CEST] <BBB> it seems brittle to me, isnt it easier to copy individual members? we made the same transition for h264
[21:08:54 CEST] <ubitux> probably.
[21:08:56 CEST] <BBB> (we used to do ranges, and stepped away because it sucked)
[21:09:10 CEST] <ubitux> it would be much better to individually copy yes
[21:10:14 CEST] <BBB> ok so we can wait for him to update that patch then, and theres no other issues afaict
[21:10:25 CEST] <BBB> tsan-slice is & hrm& all over the place
[21:13:51 CEST] <ubitux> BBB: your patch works for me
[21:14:11 CEST] <ubitux> (tested before -failing-, and after -working with several runs-)
[21:14:19 CEST] <BBB> ok
[21:14:20 CEST] <BBB> tnx
[21:14:21 CEST] <ubitux> tested different number of threads too
[21:14:24 CEST] <BBB> very interesting
[21:15:49 CEST] <ubitux> BBB: so& mmh, should we have a tsan frame+slices? is it supported with vp9?
[21:15:59 CEST] <ubitux> (both frame threading and tile threading simultaneously)
[21:16:04 CEST] <BBB> no
[21:16:07 CEST] <ubitux> ok
[21:16:17 CEST] <BBB> the libavcodec api does not support it
[21:16:22 CEST] <ubitux> ok
[21:16:57 CEST] <ubitux> the point of tile threading is latency, or that's actually faster than frame threading with some encodes?
[21:17:11 CEST] <jamrial> BBB: really? why does fate run with both enabled at the same time by default then? is one automatically disabled if you do that?
[21:17:26 CEST] <BBB> jamrial: yes
[21:17:31 CEST] <ubitux> frame takes over i guess
[21:17:36 CEST] <BBB> both means use frame if supported, else use tile if supported
[21:17:36 CEST] <jamrial> i see
[21:17:44 CEST] <BBB> frame means use frame if supported, else nothing"
[21:17:51 CEST] <BBB> tile means use tile if supported, else nothing"
[21:18:13 CEST] <BBB> I agree this isnt very properly documented
[21:18:35 CEST] <BBB> some codecs would probably support both at the same time, vp9 being one of them
[21:19:09 CEST] <BBB> I dont think it would work for h264 since slices arent horizontally contiguous and vertically linearly ordered (which is a requirement for frame to be useful)
[21:23:33 CEST] <BBB> for hevc, wpp+frame or wpp+tile might work
[21:23:42 CEST] <BBB> I believe slice/tile are mutually exclusive
[21:23:45 CEST] <BBB> I dont remember
[21:23:59 CEST] <BBB> wpp+frame+tile-col may work, but frame+tile-row will not work
[21:24:12 CEST] <ubitux> h264 slices are pretty crazy afaik
[21:24:13 CEST] <BBB> so that could be interesting (wpp+frame+tile-col = 3 methods combined)
[21:24:16 CEST] <BBB> yeah they are
[21:24:34 CEST] <ubitux> no wonder there is so much tsan "warnings"
[21:26:33 CEST] <cone-209> ffmpeg 03Ronald S. Bultje 07master:1db03e952b4e: vp9: fix explicit memory order for report_progress.
[21:27:09 CEST] <BBB> Im not sure the tsan warnings are all bad, they could indicate some actual issues
[21:27:38 CEST] <jamrial> ubitux: btw, your build system changes broke darwin on arm (ios?)
[21:27:41 CEST] <jamrial> "src/libavfilter/vf_coreimage.m:27:9: fatal error: 'AppKit/AppKit.h' file not found"
[21:27:55 CEST] <jamrial> i guess an extra header check in configure would solve it
[21:29:19 CEST] <ubitux> ah, oops
[21:29:48 CEST] <ubitux> i'll fix that thursday, i can't test til then
[21:53:47 CEST] <ubitux> michaelni: some fields are still failing with your mpeg patch btw
[21:54:05 CEST] <ubitux> http://sprunge.us/ZWCK
[21:54:12 CEST] <ubitux> on fate-vsynth1-mpeg4
[23:53:08 CEST] <cone-209> ffmpeg 03Mark Thompson 07master:6eb102a61636: h264_sei: Add namespace prefix to all SEI values
[00:00:00 CEST] --- Wed Sep 13 2017