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

[burek]

[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