[00:01:19 CEST] <ubitux> mmh [00:01:41 CEST] <BBB> new patch sent [00:01:43 CEST] <ubitux> you shouldn't listen to me at this hour i think [00:01:46 CEST] <BBB> now it passes again [00:02:08 CEST] <ubitux> yeah, it ignores the problem [00:02:10 CEST] <ubitux> :)) [00:02:20 CEST] <BBB> I think thats OK [00:02:20 CEST] <ubitux> anyway, yeah i dunno [00:02:31 CEST] <BBB> the header is clearly not intended to be self-standing [00:02:32 CEST] <ubitux> http://ubitux.fr/pub/pics/2017-03-29-000007_640x400_scrot.png this is my current battle [00:02:44 CEST] <ubitux> my brain is not ready for some ffmpeg build system madness [00:02:49 CEST] <BBB> is that dosemu? [00:02:57 CEST] <ubitux> dosbox [00:03:10 CEST] <BBB> -enotsupported? [00:03:34 CEST] <ubitux> my first guess is #define HAVE_AVX2 1 [00:04:01 CEST] <ubitux> but dunno [00:04:06 CEST] <ubitux> so many things could be wrong [00:05:06 CEST] <BBB> no kidding [00:05:22 CEST] <BBB> so shall I push the h264/hevc/vp9/pthread_frame patches? [00:05:31 CEST] <BBB> it passes make fate with THREADS=3 and without threading on my system [00:05:39 CEST] <BBB> then you can poke the tsan instance [00:06:41 CEST] <ubitux> anytime [00:07:12 CEST] <BBB> Ill keep the skipheaders one local for now [00:07:20 CEST] <BBB> since I dont know if its correct [00:07:28 CEST] <jamrial> ubitux: try things like --disable-avx or --disable-inline-asm [00:07:43 CEST] <ubitux> jamrial: i'm rebuilding with --disable-asm currently [00:08:04 CEST] <ubitux> (does it imply --disable-inline-asm?) [00:08:13 CEST] <cone-560> ffmpeg 03Ronald S. Bultje 07master:f8c019944d45: vp9: re-split the decoder/format/dsp interface header files. [00:08:14 CEST] <cone-560> ffmpeg 03Ronald S. Bultje 07master:b823bbc10cc7: vp9: split out loopfilter functions in their own source file. [00:08:15 CEST] <cone-560> ffmpeg 03Ronald S. Bultje 07master:6d0d1c4a43f5: vp9: split out reconstruction functions in their own source file. [00:08:16 CEST] <cone-560> ffmpeg 03Ronald S. Bultje 07master:0c466417846f: vp9: split out generic decoding skeleton interface API from VP9 types. [00:08:17 CEST] <cone-560> ffmpeg 03Ronald S. Bultje 07master:8c2aa45d4a99: h264: revert 1189af429211ac650aac730368a6cf5b23756605. [00:08:18 CEST] <cone-560> ffmpeg 03Ronald S. Bultje 07master:bddabfaab658: hevc: initialize no_rasl_output_flag in hevc_frame_start(). [00:08:19 CEST] <cone-560> ffmpeg 03Ronald S. Bultje 07master:027ee9b3ed69: pthread_frame: don't sync items between threads for intra-only codecs. [00:08:24 CEST] <ubitux> nice [00:08:54 CEST] <BBB> youll still see some h264 failures related to def_build_list(), I have an idea on fixing it which Ill explore next [00:09:01 CEST] <BBB> hevc may be clean [00:09:08 CEST] <BBB> intra codecs should be clean [00:09:23 CEST] <BBB> gonna go home, poke me tomorrow with results ;) [00:09:31 CEST] <ubitux> it's running [00:09:35 CEST] <ubitux> sure, will do [00:12:19 CEST] <ubitux> jamrial: yeah well, none of it helps [00:13:15 CEST] <jamrial> then fuck freedos :p [00:13:31 CEST] <ubitux> :( [00:14:12 CEST] <jamrial> how about --disable-optimizations? [00:14:31 CEST] <jamrial> maybe gcc with -O3 is doing something wrong [00:14:31 CEST] <drv> what instruction is it hitting? djgpp has a working gdb port, I think [00:18:27 CEST] <ubitux> drv: no gdb here but i may be able to found out with the xcompiled objdump [00:19:22 CEST] <drv> plus I think dosbox only emulates original Pentium at best, so no MMX or anything fancier [00:19:29 CEST] <drv> probably not cmov etc. either [00:19:43 CEST] <ubitux> mmh [00:20:15 CEST] <ubitux> maybe i'll try again dosemu with their full cpu emulation [00:20:24 CEST] <ubitux> now that i have that dpmi thing [00:20:32 CEST] <ubitux> i have no idea what am i'm doing [00:23:28 CEST] <drv> I also have this thing set in my .dosemurc, don't know if it's still relevant: $_ignore_djgpp_null_derefs = (1) [00:26:22 CEST] <ubitux> so i have an invalid opcode @ eip=45909a [00:26:29 CEST] <ubitux> 45909a: 0f 4d 45 d8 cmovge eax,DWORD PTR [ebp-0x28] [00:26:32 CEST] <ubitux> would that be this? [00:26:42 CEST] <drv> in dosbox? that is probably due to not emulating cmov [00:26:49 CEST] <ubitux> yes in dosbox [00:27:27 CEST] <drv> cmov is P6 or newer, way too fancy for 90s DOS games :) [00:27:50 CEST] <ubitux> mmh ok, so i will actually need dosemu [00:28:07 CEST] <ubitux> which is much more of a pita to use than dosbox :( [00:29:37 CEST] <BBB> I think you just want to compile the binary without cmov [00:29:39 CEST] <jamrial> --disable-inline-asm --cpu=pentium should in theory prevent any cmov instruction being assembled [00:29:48 CEST] <BBB> right [00:30:08 CEST] <BBB> Im still going to wonder why on earth you want to run ffmpeg on dos, but Ill just shut up now ;) [00:32:09 CEST] <ubitux> jamrial: omg yes [00:32:23 CEST] <Compn> dos pople r weird [00:32:33 CEST] <ubitux> http://ubitux.fr/pub/pics/2017-03-29-003228_640x400_scrot.png [00:32:35 CEST] <ubitux> alright [00:32:35 CEST] <jamrial> \o/ [00:32:39 CEST] <ubitux> now i need to run FATE [00:33:15 CEST] <kierank> haha SET BLASTER [00:33:32 CEST] <ubitux> blast from the past yeah [00:33:33 CEST] <kierank> that's a blast from the past (no pun intended) [00:33:37 CEST] <ubitux> ;) [00:34:00 CEST] <jamrial> try to remove --disable-optimizations first, see if a build with -O3 also runs [00:34:10 CEST] <atomnuker> see I'm not crazy for using dosbox to emulate windows 98, ubitux's probably decoding vp9+opus from youtube [00:34:17 CEST] <jamrial> -O1 or whatever is used without it is super slow [00:35:13 CEST] <ubitux> i think i'll need to make dosemu work though [00:35:16 CEST] <jamrial> wonder why it didn't output the "Hyper fast Audio and Video encoder" line or the usage line, though [00:36:18 CEST] <drv> in theory, just --cpu=pentium should be enough, right? (assuming we protect all inline asm with the right feature macros) [00:36:20 CEST] <BBB> jamrial: because on dos, its not fast ;) [00:36:26 CEST] <jamrial> lol [00:37:19 CEST] <jamrial> drv: yeah, inline asm using cmov should be at least under a HAVE_I686 check [00:37:40 CEST] <ubitux> BBB: http://fate.ffmpeg.org/report.cgi?time=20170328223136&slot=x86_64-archlinux-gcc-tsan [00:37:42 CEST] <ubitux> :) [00:37:57 CEST] <jamrial> or well, HAVE_FAST_CMOV [00:38:46 CEST] <ubitux> we went from 2828/3347 to 3015/3347 on tsan [00:38:59 CEST] <BBB> not bad [00:39:07 CEST] <BBB> crap dnxhr still fails [00:39:18 CEST] <jamrial> it used to be 2470 two days ago [00:39:29 CEST] <BBB> and all h264 ones are the multi-slice ones [00:39:34 CEST] <BBB> are there h264 tests that pass? [00:39:42 CEST] <BBB> all single-slice ones should pass now [00:40:28 CEST] <ubitux> the filter test failing seems to be due to lavc races [00:41:31 CEST] <ubitux> jamrial: works without --disable-optimization yeah, which is cool [00:42:36 CEST] <jamrial> ok, next step is removing --disable-inline-asm so it may use the pre-i686 inline stuff from mathops and cabac :p [00:42:47 CEST] <ubitux> well, we need to have the proper output of ffmpeg.exe first [00:43:08 CEST] <ubitux> because yeah, you noticed the Hyper fast thing is not present [00:43:19 CEST] <ubitux> it probably fails one way or another [00:43:39 CEST] <ubitux> any command ends up with that output [00:43:39 CEST] <jamrial> i suppose exit_program() was called somewhere without an av_log call [00:43:59 CEST] <ubitux> maybe at the first pthread thing [00:44:01 CEST] <ubitux> :p [00:44:25 CEST] <ubitux> they're disabled though [00:44:36 CEST] <ubitux> oh well, i'll see that later [00:44:40 CEST] <ubitux> enough BS for now [00:44:58 CEST] <jamrial> maybe some alloc() failure [00:45:08 CEST] <jamrial> those almost never get a log message and just bail out [00:45:40 CEST] <ubitux> ah, yeah :) [00:53:07 CEST] <ubitux> so, for most of the remaining tsan issues, it always happen in that update_context_from_thread() for random fields [00:53:20 CEST] <ubitux> is it a single issue or multiple ones? [00:55:42 CEST] <jamrial> michaelni: your ffprobe -show_log patch broke some ffprobe tests on SunOS [00:56:51 CEST] <jamrial> with gcc, since suncc hasn't worked in forever [00:59:29 CEST] <ubitux> lol [00:59:39 CEST] <ubitux> i was looking at the fic failure which was different that the others [00:59:43 CEST] <ubitux> then looked at the code [00:59:45 CEST] <ubitux> and saw: [00:59:53 CEST] <ubitux> * Set the frametype to I initially. It will be set to P if the frame [00:59:55 CEST] <ubitux> * has any dependencies (skip blocks). There will be a race condition [00:59:57 CEST] <ubitux> * inside the slice decode function to set these, but we do not care. [01:00:06 CEST] <ubitux> we don't need tsan [01:00:11 CEST] <ubitux> git grep 'race cond' is enoug [01:00:15 CEST] <ubitux> enough [01:01:17 CEST] <ubitux> the use of atomics could solve that case i suppose [01:02:55 CEST] <ubitux> the fifo-muxer-h264 one is funky [01:04:46 CEST] <michaelni> jamrial, do you have gdb output / backtrace ? [01:05:30 CEST] <jamrial> michaelni: no, i looked at the fate slot in question, sorry [01:05:42 CEST] <jamrial> Owner seems to be "opencsw_buildbot", so no idea who manages it [01:11:02 CEST] <BBB> how do I disable stirpping in my build again? [01:11:15 CEST] <BBB> (e.g. dont strip ffmpeg/ffplay) [01:11:39 CEST] <atomnuker> BBB: --disable-stripping [01:11:55 CEST] <BBB> is there some setting in my config.mak that corresponds to that option? [01:12:11 CEST] <BBB> (e.g. if I dont want to re-run configure) [01:12:32 CEST] <atomnuker> I don't think so [01:13:46 CEST] <BBB> ah I can just add echo to STRIP= [01:14:00 CEST] <iive> ffmpeg_g should remain unstripped at all times, i think [01:14:07 CEST] <jamrial> that's what --disable-stripping does [01:14:25 CEST] <jamrial> makes STRIP an echo command [01:16:09 CEST] <jamrial> iive: yeah, but make fate calls the non _g binaries [01:39:16 CEST] <BBB> hey guess what - tsan found an actual race condition this time [02:02:51 CEST] <BBB> I believe with these patches, the only codecs reporting race conditions are hevc and h264& both because of some multi-slice crap [02:03:00 CEST] <BBB> (video codecs) [02:03:03 CEST] <BBB> oh and lagarith [02:58:43 CEST] <tmm1> well i think the answer to my question is no, you cannot reliably detect interlacing _just_ with SPS. you need to look at the slices to see [03:02:32 CEST] <thebombzen> out of curiosity, what is the usual amount of time it takes to review a patch? [03:03:39 CEST] <kierank> couple of days [03:04:30 CEST] <thebombzen> thx [03:28:52 CEST] <michaelni> jamrial, cannot reproduce a issue with solaris (that is with gcc 4.8.3, ill try a closer version) [03:42:16 CEST] <michaelni> and installing gcc-5 succeeds but no gcc-5 seems to have been installed. If someone knows how to install gcc-5 on solaris ping me [04:03:06 CEST] <cone-874> ffmpeg 03James Almer 07master:c31cbeef584f: aarch64/vp9dsp: add missing header includes [04:09:57 CEST] <cone-874> ffmpeg 03James Almer 07master:53f1d6a8ee36: fate: add tests for ac3_fixed 5.1 downmix [04:09:58 CEST] <cone-874> ffmpeg 03James Almer 07master:91ccd38c0bef: avcodec/ac3dsp: add special-case handling for the C downmix_fixed function [04:27:20 CEST] <tmm1> ugh, apparently h264_analyze has a bug where it shows the wrong value for frame_mbs_only_flag [09:39:32 CEST] <ubitux> i'm in the process of renaming av_4cc2str() to av_fourcc2str() [09:39:45 CEST] <ubitux> as it seems people prefer that name [09:40:16 CEST] <ubitux> if you have a different opinion, now is the time [09:40:46 CEST] <ubitux> btw, any help deciphering what Carl Eugen just tried to ask me is welcome too [09:53:55 CEST] <mateo`_> michaelni: I'm investigating the ts/duration differences you reported [09:56:30 CEST] <durandal_170> ubitux: carl is asking again same thing [09:57:19 CEST] <ubitux> i'm not sure if he's trying to delay the patch or actually geniully don't understand what the macro does [09:57:31 CEST] <thebombzen> what is going on beweheen carl eugen and wm4 :O [09:58:29 CEST] <ubitux> damn, BBB fixed a ton of threading issue this night [09:58:49 CEST] <thebombzen> have they been committed? [09:58:55 CEST] <ubitux> no, patches on the ml [09:59:14 CEST] <thebombzen> ah okay [10:15:43 CEST] <mateo`_> michaelni: I can't reproduce the differences you reported, using the following method (based on what you mentionned in your email) http://sprunge.us/DWAJ [10:25:48 CEST] <ubitux> mateo`_: he's remuxing to mp4, not mpg [10:26:18 CEST] <mateo`_> oh, thanks [12:18:45 CEST] <cone-796> ffmpeg 03wm4 07master:4cf1f68903ce: pthread_frame: minor simplification to error handling [12:59:50 CEST] <ubitux> BBB: thanks for your threading patches :) [13:05:42 CEST] <mateo`_> I'm going to port the examples to the new decoding,encoding api [13:15:19 CEST] <ubitux> merge time for me [13:29:50 CEST] <cone-796> ffmpeg 03Anton Khirnov 07master:40aaa8dadfd1: examples/avcodec: split audio encoding into a separate example [13:29:51 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:b785af48687f: Merge commit '40aaa8dadfd1c69ff4460d04750e1403b5535a6d' [13:30:46 CEST] <cone-796> ffmpeg 03Anton Khirnov 07master:c00a11ab383f: examples/encode_audio: constify AVCodec instances [13:30:47 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:f38e7566c69b: Merge commit 'c00a11ab383ff276a2ab2fdba577945e48d465be' [13:31:12 CEST] <PaoloP> Hello wm4, thanks for the feedback. about "better to allocate the packet with the appropriate functions" ---> should I use av_packet_alloc() ? [13:31:20 CEST] <wm4> yes [13:32:38 CEST] <cone-796> ffmpeg 03Anton Khirnov 07master:f76698e759a0: examples/encode_audio: use the AVFrame API for allocating the data [13:32:39 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:780cc080d856: Merge commit 'f76698e759a08e8d3b629c06edb0439f474e7fee' [13:34:42 CEST] <PaoloP> wm4: ok. 2) "Some encoders (probably not all) signal what rates and formats they support in the AVCodec struct" <-- I already added a comment ("You can use any other sample rate provided by the input file on condition that it is supported by the codec (use AVCodec::supported_samplerates for listing supported sample rates"). would it be better if I use the get_default_format() function + get_first_sample_rate_in_the_codec_list() function? (I don't [13:34:44 CEST] <PaoloP> remember their names, but you understand) [13:37:34 CEST] <BBB> ubitux: youre welcome ;) [13:37:54 CEST] <BBB> ubitux: of all video decoders, only h264 and the ones based on mpegvideo have outstanding issues [13:38:34 CEST] <BBB> ubitux: frame-mt encoding has an issue (see utvideoenc) which I suppose is identical to the decoder one, mpegvideo has some pretty significant issues that I dont want to look at right now, and h264 has multi-slice issues [13:38:45 CEST] <BBB> ubitux: other than that its just filters, audio or other unrelated things [13:39:00 CEST] <ubitux> it's pretty cool to cleanup all the noise so we can focus on the real problems :) [13:39:06 CEST] <BBB> Im looking at h264 ATM [13:39:08 CEST] <BBB> yeah agreed [13:39:19 CEST] <BBB> the two avctx assignments are actual, real bugs [13:39:24 CEST] <ubitux> yep [13:39:26 CEST] <BBB> theyre not severe or anything, but they are bugs [13:39:39 CEST] <ubitux> i suppose they could cause logging errors? [13:39:53 CEST] <BBB> if you read profile and it changes, it would not be picked up by the user thread [13:40:09 CEST] <BBB> so the user thread would only ever read profile from once every N frames (where N = n_threads) [13:40:17 CEST] <BBB> (effectively) [13:40:20 CEST] <ubitux> ok [13:40:27 CEST] <BBB> thats a bug [13:40:35 CEST] <BBB> is it severe? probably not [13:40:54 CEST] <BBB> Im currently looking at a very, very weird h264 one and Im not quite sure whats going on there& [13:42:25 CEST] <BBB> hm& [13:42:34 CEST] <BBB> do mpegvideo and h264 have the avctx assignment issue also? [13:42:41 CEST] <BBB> now that would be incredibly interesting [13:43:24 CEST] <BBB> h264 doesn't [13:44:30 CEST] <cone-796> ffmpeg 03Anton Khirnov 07master:f5df897c4b61: examples/avcodec: split audio decoding into a separate example [13:44:31 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:878070cc5606: Merge commit 'f5df897c4b61985e3afc89ba1290649712ff438e' [13:45:35 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:9bed10afb8b2: doc/examples/encode_audio: add missing return [13:46:01 CEST] <BBB> I think mpeg4 does... [13:46:03 CEST] <BBB> hmm...... [13:46:24 CEST] <cone-796> ffmpeg 03Anton Khirnov 07master:90265814f993: examples/decode_audio: constify the AVCodec instance [13:46:25 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:dcdd52101f31: Merge commit '90265814f993098d79b0a0f40745ecdb403fbf56' [14:13:53 CEST] <cone-796> ffmpeg 03Anton Khirnov 07master:7b1f03477f1a: examples/avcodec: split the remaining two examples into separate files [14:13:54 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:925ce244d873: Merge commit '7b1f03477f1a43d2261fbd83e50a4ad90c7f806d' [14:15:34 CEST] <cone-796> ffmpeg 03Anton Khirnov 07master:e02524025bce: examples/encode_video: constify the AVCodec instance [14:15:35 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:e9bd45746511: Merge commit 'e02524025bce2c8bf8b5bffd96479785c75a70d4' [14:16:29 CEST] <BBB> hm, right, so I see the problem, I think& Im not 100% sure how to solve it [14:16:48 CEST] <BBB> so in h264, a call to avcodec_decode_video2() can decode just a single field [14:16:53 CEST] <BBB> then the next call decodes the other field [14:17:04 CEST] <cone-796> ffmpeg 03Anton Khirnov 07master:d0a603a534a0: examples/encode_video: set the framerate [14:17:05 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:4726bbb47156: Merge commit 'd0a603a534a0ee4b255e5e72742428a7f7f42b83' [14:17:12 CEST] <BBB> we dont reset ThreadFrame->owner between these two events [14:17:34 CEST] <BBB> and so all references to ->owner touch the one of the first fields AVCodecContext, not the "current" [14:17:47 CEST] <BBB> (I guess we should reset owner for the start of each field?) [14:18:26 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:944e5ce3ec7d: doc/examples/{de,en}code_audio: fix includes [14:22:24 CEST] <cone-796> ffmpeg 03Anton Khirnov 07master:5b4d7ac7ae5d: examples/encode_video: use the AVFrame API for allocating the frame [14:22:25 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:58f24adc05b0: Merge commit '5b4d7ac7ae5d821cfa6ab89f8eab4d31851ef32c' [14:22:58 CEST] <BBB> or maybe owner should be an array of two members, one for each field [14:23:02 CEST] <BBB> sooooo hacky [14:23:06 CEST] <cone-796> ffmpeg 03Anton Khirnov 07master:8191f960a669: examples/decode_video: constify the AVCodec instance [14:23:07 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:fdbc29ca70a6: Merge commit '8191f960a669819db4de33a2439ded1630b8a73e' [14:23:32 CEST] <BBB> I tihnk that may actually be the right solution [14:23:33 CEST] <BBB> hmm.... [14:23:47 CEST] <BBB> any objections? michaelni? [14:24:35 CEST] <cone-796> ffmpeg 03Anton Khirnov 07master:636515c324fa: examples/decode_video: remove a stray unrelated comment [14:24:36 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:63c41c53f355: Merge commit '636515c324facaa14ccd8ab0732740a240a31ba9' [14:27:49 CEST] <cone-796> ffmpeg 03Diego Biurrun 07master:85baef4ff151: vf_drawtext: Move static keyword to beginning of variable declaration [14:27:50 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:ca6f0f85bb78: Merge commit '85baef4ff1512bcc2544928bfa5f42072903a691' [14:28:33 CEST] <michaelni> BBB, no objection if that works [14:28:48 CEST] <BBB> do you have better ideas? [14:29:07 CEST] <BBB> Im not sure its the right solution [14:36:51 CEST] <cone-796> ffmpeg 03Diego Biurrun 07master:39cea6570c11: aactab: Move extern keyword to the front of array declarations [14:36:54 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:35494441b532: Merge commit '39cea6570c11a49b64b2ec8d71e218db03b4c742' [14:40:59 CEST] <ubitux> ok i'm going to push that fourcc/djgpp patchset in a few minutes [14:41:03 CEST] <ubitux> last time to object [14:41:52 CEST] <durandal_170> caaaarl [14:43:24 CEST] <ubitux> i don't think he objected [14:43:33 CEST] <ubitux> he was trying to figure out what the macro was for [14:44:40 CEST] <PaoloP> wm4 (but the question is for other people too): also, you wrote: "Also, if you put the receive call (avcodec_receive_packet() ) in a loop, it'd actually follow the proper send/receive data flow.". It's already put in a loop (while(1)) .. what do you mean exactly? http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209333.html [14:51:55 CEST] <michaelni> BBB, if you want to keep track of the owner of each field and they can be 2 seperate contexts then 2 are needed, If you want to keep track of no owners then the field can possibly be droped completely [14:52:06 CEST] <michaelni> anyway, didnt really think much about it [14:55:08 CEST] <cone-796> ffmpeg 03Diego Biurrun 07master:4cf2ffb7c458: idct: Have function pointer prototype match implementation [14:55:09 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:c1d822c554ac: Merge commit '4cf2ffb7c45840b09bc49e34da88d4053dd442cb' [14:55:10 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:bfdcdd6d829c: lavu: add av_fourcc_make_string() and av_fourcc2str() [14:55:11 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:f156d35321bb: lavc: deprecate av_get_codec_tag_string() [14:55:12 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:67e370ee527e: lavc: fix usages of av_get_codec_tag_string() [14:55:13 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:cd4d6cba122b: lavf: fix usages of av_get_codec_tag_string() [14:55:14 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:337c68d07142: tools/fourcc2pixfmt: fix usages of av_get_codec_tag_string() [14:55:15 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:fa0a8faaa451: ffprobe: fix usage of av_get_codec_tag_string() [14:55:16 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:656823220cde: ffmpeg_videotoolbox: fix usage of av_get_codec_tag_string() [14:55:17 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:d3cedc54cc87: lavf/ape: remove unused magic field [14:55:18 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:bec96a7286bc: lavf: use av_fourcc2str() where appropriate [14:55:19 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:2d12b910f710: lavc: use av_fourcc2str() where appropriate [14:55:20 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:8f9edf89d5d4: lavfi/dynaudnorm: rename pow2 to pow_2 [14:55:21 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:4ea8f57548f3: lavfi/psnr: rename pow2 to pow_2 [14:55:22 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:46068070314d: lavfi/xbr: undef PI if defined [14:55:23 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:1473afac5d11: lavu/mem: clamp alignment to 16 for DJGPP [14:55:24 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:549045254c46: Fix all -Wformat warnings raised by DJGPP [14:55:25 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:eaa67bb9c059: lavc/pthread_slice: remove pointless condition [15:00:43 CEST] <BBB> oh wow that fixed that tsan error [15:06:17 CEST] <JEEB> \o/ [15:07:49 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:d467740f45eb: lavc/idctdsp: use prefix restrict with av_ [15:10:06 CEST] <cone-796> ffmpeg 03Diego Biurrun 07master:baab87c4f30e: bink: Have function pointer prototype match implementation [15:10:07 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:a51867ee6bc7: Merge commit 'baab87c4f30e75ea309294b06adcd01ce678bdc5' [15:19:07 CEST] <cone-796> ffmpeg 03Diego Biurrun 07master:f4ca8ea92a8b: rtmpproto: Restructure zlib code to avoid unreachable code warning [15:19:08 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:72dbfe42efcb: Merge commit 'f4ca8ea92a8b36fe723412aefafc1b2fa89f8dc6' [15:22:52 CEST] <BBB> michaelni: if a slice uses mbaff, does that guarantee that the other slices in the frame use mbaff also? [15:23:04 CEST] <BBB> it does, right? [15:23:07 CEST] <cone-796> ffmpeg 03Diego Biurrun 07master:2025d3787158: doc: Turn off noisy deprecation warnings in the option printer [15:23:08 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:a1b3ded90236: Merge commit '2025d3787158ba272a1b8fbc0493fa20dd7a8484' [15:23:33 CEST] <ubitux> jkqxz: what to do about the 3 next commits? [15:23:40 CEST] <ubitux> (to merge from libav) [15:24:16 CEST] <michaelni> BBB, i would think so [15:25:32 CEST] <jkqxz> ubitux: Do they apply cleanly? [15:26:22 CEST] <ubitux> probably not [15:26:26 CEST] <ubitux> we have a frame pool system [15:26:30 CEST] <jkqxz> They are wanted, without them frame mapping doesn't work usefully. [15:27:34 CEST] <ubitux> i can't really test them [15:27:42 CEST] <ubitux> would you mind doing these merges? [15:28:00 CEST] <ubitux> (ETA: 704) [15:29:12 CEST] <jkqxz> Hardware frames already have a frame pool, so it should just be ignored. [15:30:37 CEST] <jkqxz> That is, just put the hw_frames_ctx change in front of the frame pool stuff. [15:32:25 CEST] <BBB> omg fate-h264 passes w/o tsan warnings here [15:32:29 CEST] <BBB> ubitux: ^^ [15:32:57 CEST] <ubitux> jkqxz: i can blind it but if i can't test... [15:32:59 CEST] <ubitux> BBB: yey ~ [15:33:11 CEST] <ubitux> btw, should we have a tsan isntance with THREAD_TYPE=slice? [15:33:19 CEST] <ubitux> i think they're covering more? [15:36:25 CEST] <jkqxz> I can't do it now. Blind merge should be fine (though note build failure fix for cuda a few commits further on, which you will probably see because ffmpeg enables cuda everywhere). [15:36:32 CEST] <atomnuker> I think so, I've heard of people complaining about slice threading bugs [15:36:40 CEST] <BBB> ubitux: yes we should [15:36:50 CEST] <jkqxz> If you prefer, I should be able to do it later today. [15:37:19 CEST] <ubitux> ok i'm going to do it [15:37:29 CEST] <BBB> ubitux: https://github.com/rbultje/ffmpeg/commits/tsan [15:37:41 CEST] <BBB> all video decoders are tsan-clear now afaics [15:37:45 CEST] <ubitux> BBB: i'll add such instance when that one is in the green [15:37:48 CEST] <BBB> theres still some encoder, filter, audio bugs etc. [15:38:02 CEST] <ubitux> i might increase the number of threads too btw, to something like 3 or 5 [15:38:09 CEST] <ubitux> (i like odd numbers) [15:38:09 CEST] <BBB> sure why not [15:38:11 CEST] <BBB> or make it random [15:38:23 CEST] <BBB> one of the things I like about checkasm is that it has some randomness to it [15:38:52 CEST] <BBB> oh wait mpeg4 is still buggy of course, and all mpeg-derived video decoders [15:39:05 CEST] <BBB> michaelni: do you have any interest in mpegvideo tsan cleaning? [15:41:02 CEST] <michaelni> BBB, ive quite a few things i want to look into, regressions, coverity, reinstalling some fate clients with bigger virtual disks maybe, ... i dont think i should add to my todo [15:41:09 CEST] <BBB> ok [15:50:35 CEST] <mateo`_> I'm looking at the next merge commits [16:01:52 CEST] <BBB> ubitux: utvideoenc fixes on my github also [16:02:06 CEST] <BBB> Ill send to ML in a little bit [16:05:19 CEST] <BBB> ubitux: maybe I can nudge myself to look into mpegvideo-related tsan reports later, but I think Im sort of ready to do something fun again ;) [16:05:44 CEST] <nevcairiel> something fun like making an av1 decoder? [16:05:45 CEST] Action: nevcairiel hides [16:05:49 CEST] <ubitux> i'm sure the next fate run will motivate you again after you push the patchset [16:05:51 CEST] <ubitux> :D [16:07:58 CEST] <wm4> when do we kill mpegvideo? [16:08:14 CEST] <wm4> I mean, it was already separated from h264, which was the most complex codec [16:08:29 CEST] <nevcairiel> it also didnt use all that much from it [16:08:42 CEST] <nevcairiel> but the actual mpeg codecs probably use quite a lot of it [16:08:44 CEST] <nevcairiel> mpeg124 [16:10:03 CEST] <BBB> also rv3/4 [16:10:06 CEST] <cone-796> ffmpeg 03Clément BSsch 07master:247d0339ca5d: lavfi/signature: fix -Wformat warnings raised by DJGPP [16:10:11 CEST] <BBB> I believe vc1/wmv12 also use it [16:10:49 CEST] <nevcairiel> whatever happened to mpeg3 between 2 and 4 [16:12:43 CEST] <nevcairiel> (and noone say mp3 audio) [16:14:43 CEST] <BBB> anyone interested in tsan w/ audio decoders? [16:22:03 CEST] <BBB> ah I see [16:22:06 CEST] <BBB> the audio one is trivial [16:22:13 CEST] <BBB> are all audio codecs intra-only? [16:22:43 CEST] <BBB> I dont think so right? e.g. from what I recall, wmavoice uses overlapping postfilters [16:23:00 CEST] <BBB> so then it makes sense to mark intra-only audio codecs as such [16:23:33 CEST] <nevcairiel> i think all threaded audio decoders are intra only? [16:24:01 CEST] <nevcairiel> but yeah some use some data from previous frames [16:24:04 CEST] <nevcairiel> ie. dca does that too [16:24:16 CEST] <iive> doesn't mdct need some overlap from previous frame? [16:26:17 CEST] <atomnuker> BBB: mlp and truehd aren't [16:27:57 CEST] <BBB> hm& theres a jpeg2k issue in there [16:31:18 CEST] <BBB> or maybe thats pre-my patches [16:33:48 CEST] <wm4> BBB: uh, so with interlacing, there are really two threads which can write different fields to the same AVFrame? [16:33:59 CEST] <BBB> yes [16:34:16 CEST] <wm4> wtf... sounds like another case for outputting fields instead of weaved frames [16:34:37 CEST] <nevcairiel> really makes no difference if they write interleaved lines or interleaved memory buffers [16:35:04 CEST] <BBB> wm4: I dont know, I think the two issues are orthogonal [16:35:29 CEST] <nevcairiel> except that plenty APIs want weaved frames, so doing it right away is probably better for performance [16:36:30 CEST] <BBB> my logic is its what we do now and I dont see a strict problem with it, so Ill just bother with other things" [16:36:48 CEST] <BBB> anyway, my current patchset makes fate pretty clean as far as I can see [16:36:59 CEST] <BBB> theres a bunch of mpeg4 issues and perhaps some filtering stuff [16:37:54 CEST] <BBB> at least ffmpeg-filter_colorkey seems avfilter-related [16:44:36 CEST] <ubitux> i don't see colorkey in the last report [16:44:40 CEST] <mateo`_> here are the next merge commits https://github.com/mbouron/FFmpeg/commits/lavfi-merges, if someone wants to take a look / test [16:44:42 CEST] <BBB> oh cool [16:44:53 CEST] <BBB> I was probably looking at an older one [16:44:56 CEST] <BBB> Im fixing them one-by-one [16:45:09 CEST] <ubitux> maybe it happens sometimes though [16:45:32 CEST] <wm4> mateo`_: any notable problems/issues? [16:45:46 CEST] <mateo`_> i will split the content of ff_default_get_video_buffer later on [16:45:55 CEST] <ubitux> mateo`_: did you include 67c65e461cb073d61ffbc78845d4a3d8f14bf481? [16:46:20 CEST] <mateo`_> wm4: i blinded the merge, so i have no idea if it works [16:46:57 CEST] <mateo`_> ubitux: nope [16:47:07 CEST] <ubitux> you probably should [16:50:36 CEST] <mateo`_> ubitux: it's a separate merge commit, isn't it ? [16:51:02 CEST] <ubitux> it comes later in the history [16:51:13 CEST] <ubitux> but it's a fixup for one of the commit you're merging [16:54:02 CEST] <mateo`_> right [16:56:23 CEST] <mateo`_> branch updated [16:56:35 CEST] <ubitux> maybe ping jkqxz for testing [16:56:57 CEST] <ubitux> but you shouldn't wait too much, because as soon as someone pushes something you have to redo all the 3 merges [16:57:41 CEST] <mateo`_> jkqxz: would you kindly test the next lavfi merge batch (https://github.com/mbouron/FFmpeg/commits/lavfi-merges) ? [16:57:47 CEST] <ubitux> (and my rebase script won't help you in this situation) [16:57:57 CEST] <mateo`_> and i'll soon be afk [16:58:48 CEST] <wm4> for these situations rerere seems like a good iea [16:58:50 CEST] <mateo`_> the merge is trivial, there are only minor conflicts, i don't mind doing it again later [16:58:50 CEST] <wm4> *idea [16:59:31 CEST] <mateo`_> rerere ? [17:03:58 CEST] <ubitux> git rerere [17:06:03 CEST] <wm4> basically it re-applies conflict resolutions whenever possible [17:39:03 CEST] Action: mateo`_ afk [18:01:48 CEST] <ubitux> wm4: https://trac.ffmpeg.org/ticket/6275 [18:01:59 CEST] <ubitux> in case you didn't see it [18:03:46 CEST] <wm4> I'm looking forward to cehoyos' analysis [18:04:57 CEST] <ubitux> i know the conclusion of the analysis& :3 [19:23:25 CEST] <jamrial> so, how ugly would it be to remove a month old public enum value that's not part of any release? [19:25:32 CEST] <atomnuker> jamrial: I think its alright, its not part of any release [19:57:13 CEST] <Bitterblue> Hi. I have a vector of AVPackets which were previously decoded into one correct AVSubtitle. This happened during 100% linear access from the beginning of a PGS stream to the end. However, when I try to decode them again, starting just from the first AVPacket in the vector, things don't go so well. Either the resulting AVSubtitle contains a 0x0 AVSubtitleRect, or the image is "slightly" wrong. Is random [19:57:15 CEST] <Bitterblue> access in PGS just not possible? [19:59:00 CEST] <JEEB> Bitterblue: sounds like the initialization data for something is missing [19:59:16 CEST] <JEEB> I remember PGS containing different packets, such as palette etc [20:09:26 CEST] <Bitterblue> Hmm. [20:13:35 CEST] <wm4> Bitterblue: normally when I seek in something that has PGS I don't get artifacts [20:13:41 CEST] <wm4> so, should be possible [20:27:34 CEST] <Bitterblue> Decoding the previous ten subtitles seems to help, but that's not a very nice solution. [20:28:53 CEST] <nevcairiel> iirc AVPackets don't contain singular subtitles for PGS, but you get one AVPacket for every PGS packet, and one subtitle consists of a couple of those [20:29:14 CEST] <nevcairiel> typically a palette, windowing information, object information, etc [20:32:43 CEST] <wm4> I wonder if PGS packets typically have a useful keyframe flag set [20:32:53 CEST] <nevcairiel> where from? [20:33:01 CEST] <nevcairiel> mpegts, its only commercial source, dont carry such flags [20:33:32 CEST] <wm4> parser [20:33:53 CEST] <nevcairiel> has none [20:37:01 CEST] <Compn> Bitterblue [20:37:06 CEST] <Compn> nm [20:37:46 CEST] <wm4> sounds like a place for improvement [21:04:23 CEST] <jkqxz> mateo`: Tested with what's currently there, works fine (wants hwmap to do anything meaningful, though). [21:04:33 CEST] <jkqxz> mateo`: Two nits: in the first patch, you needn't bother with the else and the extra braces around the existing code; the hwupload_cuda fix wants to be in the second patch, not the third. [21:05:01 CEST] <jkqxz> mateo`: LGTM otherwise. [21:18:46 CEST] <BtbN> mateo`, the hwupload_cuda one also looks like it won't compile. As it uses outlink, but there is no outlink in the function where it uses it. [21:25:39 CEST] <Cheech> anyway to stream live MPEGTS with alpha channel please?? [21:27:05 CEST] <BtbN> Find a format it supports that can carry one [23:07:15 CEST] <mateo`> jkqxz, BtbN thanks for testing [23:08:43 CEST] <mateo`> I'll redo the first patch withtout the else {} and applied it immediately [23:20:10 CEST] <cone-796> ffmpeg 03Mark Thompson 07master:7433feb82f75: lavfi: Make default get_video_buffer work with hardware frames [23:20:11 CEST] <cone-796> ffmpeg 03Matthieu Bouron 07master:b265e5ba50b8: Merge commit '7433feb82f75827884d909de34d341a1c4401d4a' [23:22:52 CEST] <durandal_1707> ok to push sonething? [23:26:06 CEST] <durandal_1707> mateo`: ^ [23:26:54 CEST] <mateo`> durandal_1707: yes go ahead, thanks for taking care :) [23:29:56 CEST] <cone-796> ffmpeg 03Martin Vignali 07master:b4016ef31a6e: avcodec/exr: add support for uint32 [23:32:54 CEST] <PaoloP> I have to add a check for the sample rate of a chosen codec in my snippet. codec->supported_samplerates for AAC returns {16000, 12000, 11025, 8000, 7350} . Do I have to add 44100 to this list (as muxing.c and decoding_encoding.c do) ? [23:35:24 CEST] <nevcairiel> the list returned by AAC is far longer and already includes 44100 [23:35:46 CEST] <nevcairiel> in general, modifying the returned list is just wrong, it te lls you whats supported and thats that, you cant just add a format [23:36:39 CEST] <cone-796> ffmpeg 03Mark Thompson 07master:7e2561fa8313: lavfi: Use ff_get_video_buffer in all filters using hwframes [23:36:40 CEST] <cone-796> ffmpeg 03Matthieu Bouron 07master:78e871ebbcc6: Merge commit '7e2561fa8313982aa21f7657953eedeeb33b210d' [23:38:13 CEST] <PaoloP> nevcairiel: yes, I did not want to modify the list, I thought it was a sort of common default value. I don't understand why in decoding_encoding.c there's this line: if (!codec->supported_samplerates) return 44100; [23:38:43 CEST] <nevcairiel> its for when there is no list at all, which basically means anything is supported, so it picks some default [23:39:50 CEST] <PaoloP> I see, a comment for that should be added to the doxy, IMHO [23:40:31 CEST] <nevcairiel> it kind of says that [23:40:41 CEST] <nevcairiel> 44100 is a generally accepted default value [23:40:57 CEST] <PaoloP> nevcairiel: you are right, it says: "or NULL if UNKNOWN" [23:41:08 CEST] <PaoloP> sorry. [23:55:38 CEST] <mateo`> jkqxz, BtbN: are you ok with the following change on the next merge commit http://sprunge.us/WJZf ? [23:59:25 CEST] <jkqxz> Is anything similar necessary for the format it gets compared to? [23:59:34 CEST] <jkqxz> Also yes. [00:00:00 CEST] --- Thu Mar 30 2017