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

[burek]

[00:00:08 CEST] <mateo`> av_buffersink_get_format :)
[00:00:50 CEST] <jkqxz> Yep!
[00:06:02 CEST] <cone-796> ffmpeg 03Mark Thompson 07master:e3fb74f7f9a8: lavfi: Always propagate hw_frames_ctx through links
[00:06:03 CEST] <cone-796> ffmpeg 03Matthieu Bouron 07master:b5e1ec566069: Merge commit 'e3fb74f7f9a8f1895381355f40c92cac3c1023d9'
[00:07:01 CEST] <mateo`> jkqxz: thanks for your help
[00:08:09 CEST] <mateo`> hwmap is not too far away :), anyway i'll probably continue the merges tomorrow if ubitux does not
[00:36:23 CEST] <PaoloP> git send-email -1 --to=ffmpeg-devel at ffmpeg.org --in-reply-to= ....   how can I obtain the string of the message to which I have to reply ?  for example, in replay to this msg:  http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209324.html
[00:38:39 CEST] <JEEB> PaoloP: look at the link that you get when you right-click the e-mail address of clement
[00:38:40 CEST] <jkqxz> Look at the mailto link at the top (see the In-Reply-To argument).
[00:41:00 CEST] <PaoloP> t
[00:42:28 CEST] <PaoloP> thnks jkqxz JEEB: I obtain In-Reply-To=%3C20170329074335.GD14584%40golem.pkh.me%3E"  <---but I see weird characters as well
[00:42:59 CEST] <PaoloP> %3E, %40....
[00:46:14 CEST] <PaoloP> solved, nm, used the ascii chart
[00:46:16 CEST] <RiCON> that's url encoding
[00:46:19 CEST] <JEEB> ^
[00:47:00 CEST] <RiCON> %3C = <, %40 = @ and %3E = >, i'd guess
[00:47:08 CEST] <PaoloP> RiCON: yes, thnks
[00:47:24 CEST] <JEEB> you can use python or so to decode it easily
[00:48:22 CEST] <JEEB> https://docs.python.org/3/library/urllib.parse.html
[01:02:31 CEST] <PaoloP> JEEB: nm, it only gives me the three chars that RiCON listed
[01:06:26 CEST] <J_Darnley> I wonder whether git or email clients would thread properly if you gave the URL-encoded string on the command line.
[01:07:14 CEST] <RiCON> thunderbird can probably take the whole mailto:
[01:07:32 CEST] <RiCON> not sure on git
[01:42:23 CEST] <cone-796> ffmpeg 03Carl Eugen Hoyos 07release/3.2:582c3d514a7b: lavf/flacdec: Return maximum score if the streaminfo header is valid.
[02:20:53 CEST] <cone-796> ffmpeg 03James Almer 07master:c14b3ea93c4f: ffprobe: fix printing packet side data information
[02:28:43 CEST] <michaelni> jamrial, btw ive succeeded to install gcc 5.2.0 on solaris and fate passes except fate-source (some non posix tool i suspect)) 
[02:31:20 CEST] <michaelni> btw i see on the x86-32 solaris fate client "can't create libavcodec/x86/hpeldsp_vp3_init.o: Disc quota exceeded"
[02:31:40 CEST] <michaelni> could be unrelated though
[02:42:36 CEST] <jamrial> michaelni: no idea then, maybe some difference in their environments
[02:43:09 CEST] <jamrial> oddly enough their four slots (x86_32, x86_64, sparc, sparc64) fail the same way
[02:43:33 CEST] <michaelni> yes, its a bit odd
[02:44:01 CEST] <michaelni> also no valgrind on solaris it seems at least no package in the main repo with that name or i am silly
[02:45:31 CEST] <michaelni> wtf doesnt even patch work on solaris
[03:12:52 CEST] <cone-796> ffmpeg 03Michael Niedermayer 07master:5f019909c0e2: avfilter: Add AV_OPT_FLAG_FILTERING_PARAM where it is missing
[03:12:53 CEST] <cone-796> ffmpeg 03Michael Niedermayer 07master:ad7aff035517: tests/fate/source-check: Use git grep in place of grep
[03:17:06 CEST] <thebombzen> what repo is docs/nut4cc.txt in?
[03:17:16 CEST] <thebombzen> it's not in ffmpeg.git
[03:19:20 CEST] <michaelni> thebombzen, svn://svn.mplayerhq.hu/nut
[03:19:37 CEST] <thebombzen> time to learn svn again lol
[03:20:18 CEST] <michaelni> thebombzen, https://git.ffmpeg.org/gitweb/nut.git
[03:20:42 CEST] <thebombzen> oh okay, thanks
[03:22:44 CEST] <thebombzen> now, it says the spec is frozen
[03:22:52 CEST] <thebombzen> does that not count adding extra 4ccs?
[03:27:16 CEST] <michaelni> any change not breaking existing files could be considered
[03:35:55 CEST] <thebombzen> michaelni: alright, I sent the patch
[09:34:52 CEST] <cone-056> ffmpeg 03Martin Storsjö 07master:2e55e26b40e2: vp9: Flip the order of arguments in MC functions
[09:34:52 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:4503d678cb04: Merge commit '2e55e26b40e269816bba54da7d0e03955731b8fe'
[09:40:35 CEST] <ubitux> wbs: how much in sync are {libav,ffmpeg}/libavcodec/arm/vp9mc_neon.S?
[09:41:02 CEST] <ubitux> based on libav/master it looks like there are differences, are they justified or one is missing a few changes from the others?
[09:41:37 CEST] <wbs> ubitux: they are supposed to be identical, mostly. on the libav side, some things were fixed in later commits - all the commit hashes should have been mentioned in the commits on the ffmpeg side
[09:41:51 CEST] <wbs> ubitux: the latest libav version should be identical (as far as possible) to the ffmpeg version
[09:42:08 CEST] <ubitux> there are a few differences
[09:42:16 CEST] <wbs> ubitux: for itxfm and lpf, there's really no other changes than ffmpeg having 10/12 bit support, and the license header. for mc there's a tiny detail
[09:43:02 CEST] <ubitux> http://b.pkh.me/ffavmcvp9neon.html
[09:43:13 CEST] <wbs> in libav, ff_vp9_subpel_filters is int8_t and lacks the first (offset 0) filter coefficients
[09:43:17 CEST] <ubitux> ah sorry not up-to-date this one
[09:43:28 CEST] <wbs> in ffmpeg, they're int16_t and have got the first row present
[09:43:49 CEST] <ubitux> (now it is)
[09:44:00 CEST] <ubitux> wbs: ah, ok :)
[09:44:02 CEST] <wbs> so the offsets and shifts for loading the filter coefficients are different, and on the libav side, there's a vmovl to widen to 16 bit
[09:44:58 CEST] <ubitux> alright, perfect then
[09:45:00 CEST] <ubitux> thanks
[09:45:19 CEST] <wbs> yup, those differences are to be expected. if you look at ff_vp9_subpel_filters in libavcodec/vp9dsp.c in the two projects you'll see the difference
[09:45:51 CEST] <wbs> for itxfm and lpf there shouldn't be any difference except for license headers, and 10/12 bit
[09:46:24 CEST] <cone-056> ffmpeg 03Martin Storsjö 07master:ffbd1d2b0002: arm: vp9: Add NEON optimizations of VP9 MC functions
[09:46:25 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:d4bb093ad35a: Merge commit 'ffbd1d2b0002576ef0d976a41ff959c635373fdc'
[09:46:36 CEST] <wbs> especially as long as the commit hash is mentioned in one of my cherrypicks, you should be able to no-op the merge
[09:50:16 CEST] <ubitux> yep i didn't notice you took care of referencing the hash :)
[09:50:37 CEST] <wbs> that commit message is .. rather large, yeah :P
[09:56:45 CEST] <cone-056> ffmpeg 03Martin Storsjö 07master:1a469a5e423b: options_table: Remove a now unnecessary include of config.h
[09:56:46 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:a48c0c41c4de: Merge commit '1a469a5e423bdad779b8534247dea8cc86169b88'
[09:57:27 CEST] Action: ubitux can't test windows ce/phone/rt/..
[10:00:29 CEST] <mateo`> come on, put some effort, it's the next step after freedos :D
[10:01:00 CEST] <wbs> TBH, I've never actually run tests for the wince or symbian builds, only tested building
[10:01:22 CEST] <wbs> I did actually use builds for wince at some point many years ago though, so at least some codecs did work in the build back then
[10:02:55 CEST] <cone-056> ffmpeg 03Diego Biurrun 07master:ee59f0540875: intrax8: Have function signature match across declaration and definition
[10:02:56 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:b76dd6a67832: Merge commit 'ee59f0540875ab42496af2aacddd942757707683'
[10:04:35 CEST] <cone-056> ffmpeg 03Diego Biurrun 07master:13fcdfb97603: svq3: Drop unused function dctcoef_get()
[10:04:35 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:a5745897e4c5: Merge commit '13fcdfb976038f63b9f753e2ebcc8e04d7c7abc2'
[10:06:26 CEST] <cone-056> ffmpeg 03Mark Thompson 07master:67c65e461cb0: vf_hwupload_cuda: Fix build error
[10:06:27 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:4f96c11ed743: Merge commit '67c65e461cb073d61ffbc78845d4a3d8f14bf481'
[10:07:45 CEST] <ubitux> "warning C4028"  are these MSVCC stuff?
[10:08:47 CEST] <ubitux> (the number looks close to the warnings id disabled in the configure)
[10:09:33 CEST] <nevcairiel> yes
[10:10:10 CEST] <nevcairiel> "The type of the formal parameter does not agree with the corresponding parameter in the declaration. The type in the original declaration is used."
[10:11:11 CEST] <cone-056> ffmpeg 03Diego Biurrun 07master:99ddeddc7fc9: ituh263dec: Have function signature match across declaration and definition
[10:11:12 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:c223784ea7f3: Merge commit '99ddeddc7fc996c0c1e842112928490e78542bd5'
[10:15:24 CEST] <cone-056> ffmpeg 03Diego Biurrun 07master:c778eb15b89d: pixblockdsp: Have function pointer prototype match implementation
[10:15:25 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:7b8901571504: Merge commit 'c778eb15b89d875cb246b18f65b3b4321cb1e7d6'
[10:17:45 CEST] <ubitux> these commits are weird
[10:19:35 CEST] <ubitux> because they do not touch the declared prototypes for asm&
[10:19:37 CEST] <ubitux> but anyway.
[10:20:28 CEST] <cone-056> ffmpeg 03Diego Biurrun 07master:6354957a9502: dnxhdenc: Have function pointer prototype match implementation
[10:20:29 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:77248d121812: Merge commit '6354957a95022864746180525680cca872ab0e0a'
[10:27:32 CEST] <mateo`> wm4: hello, regarding the port of the examples to the new api, can you confirm it is ok to assume that the first call to send_packet will *always* succeed (unless an error happens or the codec is flushed), then I can loop on receive_frame until EAGAIN and then goes back to reading the next packet and continue (still assuming send_packet won't return EAGAIN because receive_frame previously returned
[10:27:34 CEST] <mateo`> EAGAIN) ?
[10:28:22 CEST] <cone-056> ffmpeg 03Diego Biurrun 07master:99434f4df81b: float_dsp: Have implementation match function pointer prototype
[10:28:23 CEST] <cone-056> ffmpeg 03Diego Biurrun 07master:67351924fa91: Drop unreachable break and return statements
[10:28:24 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:f291a9a1adab: Merge commit '99434f4df81b6801b2b535d5b9143305595784f6'
[10:28:25 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:03f5e80bdbbf: Merge commit '67351924fa91dea4339109100a4c0689f006581f'
[10:29:32 CEST] <ubitux> jkqxz: we're at the hwmap commit
[10:29:39 CEST] <ubitux> do you want to merge it?
[10:32:22 CEST] <mateo`> wm4: it seems to be the case, but I've been traumatized by the MediaCodec api that does not provide such guarantees
[10:32:54 CEST] <ubitux> jkqxz: looks like it applies mostly cleanly so i'll probably apply blindly
[10:36:34 CEST] <ubitux> how can i test that hwmap filter?
[10:36:57 CEST] <ubitux> there is no doc/test :(
[10:39:01 CEST] <cone-056> ffmpeg 03Mark Thompson 07master:d06aa24ba583: hwcontext: Hardware frame mapping
[10:39:02 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:4cda23f1f146: Merge commit 'd06aa24ba583ad08025da9e1b29afcd8218ff9b0'
[10:49:34 CEST] <wm4> mateo`: yes, ffmpeg.c relies on it
[10:49:50 CEST] <mateo`> wm4: ok, thanks
[10:53:11 CEST] <cone-056> ffmpeg 03Mark Thompson 07master:124e26971e69: lavfi: Hardware map filter
[10:53:12 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:6234fd2fa012: Merge commit '124e26971e69bb25f38c6c7cb3fa20c77cf10966'
[10:56:57 CEST] <cone-056> ffmpeg 03Mark Thompson 07master:8ad9f9d675ea: hwcontext_vaapi: Frame mapping support
[10:56:58 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:71c22fb7aec9: Merge commit '8ad9f9d675eab139aa2208722009eeed981460dd'
[10:57:36 CEST] <cone-056> ffmpeg 03Martin Storsjö 07master:392caa65df3e: arm: vp9mc: Insert a literal pool at the middle of the file
[10:57:36 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:aa7976fd1550: Merge commit '392caa65df3efa8b2d48a80f08a6af4892c61c08'
[11:03:37 CEST] <cone-056> ffmpeg 03Martin Storsjö 07master:d1ef1b9eaa45: configure: Silence lld-link when getting the version number
[11:03:38 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:8524b0162f01: Merge commit 'd1ef1b9eaa45043ea5df5a004fb37243e05da61d'
[11:05:49 CEST] <cone-056> ffmpeg 03Diego Biurrun 07master:3cba09e5228c: x86: Drop stray semicolons after function definitions
[11:05:50 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:80f91c8d5a6f: Merge commit '3cba09e5228c889d63814dc43bc68f15c9dbac77'
[11:08:46 CEST] <cone-056> ffmpeg 03Derek Buitenhuis 07master:db0b3dccb384: libx265: Add option to force IDR frames
[11:08:47 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:03f22c288aff: Merge commit 'db0b3dccb3842de134721e8d5c275f56d384340d'
[11:11:35 CEST] <cone-056> ffmpeg 03Hendrik Leppkes 07master:fabfbfe57100: dxva2: fix surface selection when compiled with both d3d11va and dxva2
[11:11:36 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:46998d037f8b: Merge commit 'fabfbfe5710050812147f93a351a53fdda56ff8c'
[11:12:34 CEST] <ubitux> i need someone to merge the next commits
[11:12:43 CEST] <ubitux> nevcairiel: can you do those? dxva2 etc
[11:14:13 CEST] <nevcairiel> they should just apply as-is i would think
[11:14:21 CEST] <nevcairiel> but i can otherwise  do them a bit later
[11:16:20 CEST] <ubitux> no the files are different
[11:16:37 CEST] <ubitux> well, actually, it applies cleanly
[11:17:01 CEST] <ubitux> but files are quite different
[11:17:14 CEST] <ubitux> the second one clashes
[11:17:34 CEST] <ubitux> i'm not confident in blindly merging this
[11:17:42 CEST] <nevcairiel> we're probably in some odd state where we backported half their things
[11:18:24 CEST] <ubitux> (ETA: 682)
[11:30:54 CEST] <nevcairiel> wm4: threaded hwaccel decoding of vp9 is still broken for me, wasnt this supposed to work now
[11:32:12 CEST] <BtbN> threaded hwaccel decoding sounds weird to begin with
[11:32:28 CEST] <BtbN> Do the hwaccel APIs support that?
[11:32:38 CEST] <BtbN> Or does it just automatically limit itself to one thread?
[11:32:42 CEST] <wm4> nevcairiel: I think so
[11:32:53 CEST] <wm4> BtbN: yes
[11:33:17 CEST] <nevcairiel> I get a lot of "Operation not permitted" spam and 90% of the frames have the same hash (using framemd5)
[11:33:28 CEST] <nevcairiel> threads 1 and it works
[11:39:22 CEST] <cone-056> ffmpeg 03Anton Khirnov 07master:910973765417: hwcontext_dxva2: frame mapping support
[11:39:23 CEST] <cone-056> ffmpeg 03Anton Khirnov 07master:10065d9324c2: hwcontext_dxva2: add support for the P8 format
[11:39:24 CEST] <cone-056> ffmpeg 03Hendrik Leppkes 07master:9ca5d2de5d14: Merge commit '910973765417f06a4a9ccbd006e4df74c32ecb01'
[11:39:25 CEST] <cone-056> ffmpeg 03Hendrik Leppkes 07master:14764b93e282: Merge commit '10065d9324c2e35ce7040b6a2b9ebf6079bcbf42'
[11:39:38 CEST] <nevcairiel> ubitux: done
[11:48:09 CEST] <wm4> nevcairiel: how to reproduce? does it work with h264?
[11:55:24 CEST] <nevcairiel> h264 seems fine
[11:56:31 CEST] <ubitux> nevcairiel: thx :)
[11:56:46 CEST] <nevcairiel> I tested with this clip https://files.1f0.de/encodes/tos3k-vp9-b5000.webm and an ordinary ffmpeg -hwaccel dxva2 -i  <> -f framemd5 -
[11:57:31 CEST] <ubitux> if you want to do the qsv ones too btw...
[11:57:42 CEST] <ubitux> i can't test them either
[12:09:03 CEST] <nevcairiel> i dont have an intel gpu really setup either
[12:09:46 CEST] <BtbN> I'd guess my Laptop has that. But no idea how to utilize it.
[12:10:22 CEST] <BtbN> Those libmfx wrappers are confusing
[12:25:12 CEST] <wm4> durandal_1707: don't you like to add fringe formats? OSX icns files are apparently not supported by ffmpeg
[12:25:24 CEST] <wm4> it's Apple's .ico I guess
[12:25:37 CEST] <wm4> appears to contain PNGs
[12:25:56 CEST] <durandal_1707> awesome
[12:26:12 CEST] <durandal_1707> format of fotmats
[12:26:40 CEST] <PaoloP> wm4, ubitux and others: I made the changes you told me to the API usage snippet. It should be ok: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209385.html . Hope you can accept it so I can add other examples
[13:26:26 CEST] <cone-056> ffmpeg 03Leo Izen 07master:744916908167: avformat/nut: Add HEVC and Opus support
[13:51:28 CEST] <ubitux> BBB: are you going to add AVCOL_PRI_JEDEC_P22 to colorspace?
[13:51:45 CEST] <BBB> probably? although adding crazy new stuff is more kodas thing
[13:52:36 CEST] <BBB> did we merge a patch changing the hevcpred interface?
[13:52:40 CEST] <BBB> (re: that mips patch)
[13:52:56 CEST] <ubitux> yeah i may have broke it
[13:53:06 CEST] <ubitux> i need to check
[13:53:08 CEST] <ubitux> PaoloP: you're missing the build of the example through the build system (needs update in configure and doc/Makefile)
[13:53:22 CEST] <ubitux> PaoloP: you should rebase on upstream, some changes in the examples recently went it
[13:53:31 CEST] <ubitux> also update the .gitignore of the examples
[13:53:43 CEST] <ubitux> replace ++x with x++, you're not doing c++
[13:53:59 CEST] <ubitux> you should wrap a little the long lines too
[13:54:47 CEST] <BBB> I think theyre including the wrong header
[13:54:49 CEST] <BBB> ohwell
[14:00:35 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:b22c4d822b33: doc/codecs: add jedec-p22
[14:06:07 CEST] <ubitux> BBB: btw i think your initial patch fixing the checkheader was more correct
[14:06:25 CEST] <ubitux> i assumed you were supposed to skip the header, but if you have vda, you shouldn't
[14:06:25 CEST] <BBB> I didnt push anything yet did I?
[14:06:43 CEST] <BBB> ubitux: I dont know the intention, I wish the vda people would respond ;)
[14:07:05 CEST] <BBB> (Sebastian Zwickert)
[14:11:09 CEST] <BBB> I thought he was on IRC at some point
[14:11:14 CEST] <BBB> does anyone remember his nickname?
[14:32:02 CEST] <wm4> atomnuker: didn't you say you had remarks about the new bitstream API to Libav? they say they aren't aware of any
[14:32:50 CEST] <wm4> <atomnuker> BBB: they ignored my small tiny request as well
[14:34:07 CEST] <BBB> I asked for a bunch of things
[14:34:18 CEST] <BBB> its always easiest to say youre not aware of it, because then you can just commit it
[14:34:39 CEST] <BBB> ;)
[14:34:42 CEST] <wbs> BBB: trolling aside, this last comment also is just dismissive
[14:34:43 CEST] <wbs> fwiw
[14:34:54 CEST] <BBB> wbs: it is, but Im getting kind of tired
[14:35:01 CEST] <wbs> BBB: sure
[14:35:06 CEST] <BBB> wbs: Ive tried for a while to be helpful towards bringing the projects together
[14:35:13 CEST] <BBB> Im tired of it
[14:35:18 CEST] <wbs> sure
[14:35:35 CEST] <BBB> so yes, Ive gotten dismissive. I hope someone else can still do it, its the right thing to do - but it wont be me
[14:35:50 CEST] <j-b> I know most of you don't care, but everyone here could make a lot of money, instead of fighting...
[14:35:59 CEST] Action: BBB hugs j-b
[14:36:08 CEST] <wbs> BBB: I just try to keep the dismissing factual instead of emotional :P
[14:36:10 CEST] <j-b> and, by a lot, I mean a lot.
[14:36:18 CEST] <ubitux> what if we already make a lot of money? :s
[14:36:27 CEST] <BBB> wbs: I did ask for things, thats not emotional
[14:36:28 CEST] <j-b> well, I know your boss, and you don't.
[14:36:51 CEST] <j-b> BBB: do you have the list of things somewhere?
[14:37:16 CEST] <wm4> <DonDiego> ronald had some comments in the beginning, then he disappeared
[14:37:25 CEST] <wbs> BBB: yes, that's true. what wm4 said before was people actually searching to find which particular request that was ignored in his case
[14:37:34 CEST] <wbs> BBB: (for atomnuker's request)
[14:37:56 CEST] <BBB> I dont know what atomnukers request was& lets wait for him to respond
[14:38:11 CEST] <wbs> BBB: exactly. then don't pretend that "they know it, they just ignored it on purpose"
[14:38:30 CEST] <BBB> ok
[14:39:00 CEST] <wm4> <DonDiego> i don't remember any changes he requested that were not implemented (do not remember != do not exist)
[14:39:30 CEST] <wm4> so from my perspective it looks like at _worst_ stuff was forgotten/overlooked (with no ill intent)
[14:44:10 CEST] <mateo`> wm4: the filtering_{audio,video} examples do not take care of flushing the decoders (as well as the filter graph), is the patch still ok for you ?
[14:44:31 CEST] <mateo`> and we should add the flushing code in a separate commit
[14:44:43 CEST] <wm4> mateo`: yeah... that's bad for an example, so that should be done (or at least a warning against it)
[14:46:51 CEST] <mateo`> are you ok if we do that in a separate patch ?
[14:47:11 CEST] <wm4> yes
[14:47:27 CEST] <wm4> absolutely... just because it updates the API use, it doesn't need to make the example perfect
[14:48:04 CEST] <atomnuker> BBB: I asked luca if all functions may be clearly labeled whether they read or write
[14:48:09 CEST] <atomnuker> most were, but some were not
[14:48:43 CEST] <wm4> so was it like that before, or he honored your request, but incompletely?
[14:48:56 CEST] <atomnuker> no, it was like that before
[14:49:25 CEST] <atomnuker> also the function names are too long
[14:49:46 CEST] <atomnuker> bitstream is 9 chars
[14:50:06 CEST] <ubitux> should use "bs"
[14:50:10 CEST] <BtbN> building with mingw sureis slow
[14:50:14 CEST] <atomnuker> or better yet "get_bits"
[14:50:26 CEST] <ubitux> BS is better
[14:50:33 CEST] <j-b> BtbN: and WSL
[14:50:36 CEST] <wm4> atomnuker: they don't hear/read that
[14:51:10 CEST] <BtbN> j-b, hm? I'm comparing to cygwin gcc. And it takes several magnitudes longer.
[14:51:11 CEST] <nevcairiel> configure with mingw is slow, the build after that is fine
[14:51:26 CEST] <BBB> I agree that bitstream_*() is stupidly long
[14:51:33 CEST] <mateo`> ubitux: i like bs :D
[14:51:36 CEST] <ubitux> ;)
[14:51:54 CEST] <BtbN> nevcairiel, what I mean is, mingw gcc is even slower than cygwin gcc.
[14:51:59 CEST] <ubitux> no one wants to merge the qsv commits?
[14:52:03 CEST] <ubitux> should i blind them?
[14:52:18 CEST] <BtbN> I should be able to at least test them soon
[14:52:22 CEST] <BtbN> once this build finishes
[14:52:32 CEST] <nevcairiel> if you target building for windows, isnt that basically the same compiler then
[14:52:40 CEST] <nevcairiel> cygwin uses mingw afterall to make windows binaries
[14:52:48 CEST] <BtbN> targeting mingw from cygwin is a cross-compile for configure.
[14:54:05 CEST] <j-b> BtbN: WSL is fast, for me.
[14:54:12 CEST] <BtbN> What even is WSL?
[14:54:26 CEST] <j-b> Windows Subsystem for Linux
[14:54:31 CEST] <j-b> aka Linux on Windows.
[14:54:38 CEST] <wm4> you'd have to cross-compile in that
[14:54:46 CEST] <BtbN> oh, that. Doesn't integrate the same way Cygwin does.
[14:54:55 CEST] <BtbN> You can't access the Host-OS from it.
[14:55:03 CEST] <nevcairiel> define "access"
[14:55:07 CEST] <nevcairiel> you can access the file system
[14:55:12 CEST] <nevcairiel> and its kinda the same OS
[14:55:17 CEST] <j-b> and you can call both Linux and Win32 exe
[14:55:17 CEST] <nevcairiel> its not like its a VM
[14:55:25 CEST] <nevcairiel> calling win32 exe is new though
[14:55:31 CEST] <nevcairiel> j-b must be on insider builds
[14:55:38 CEST] <j-b> nevcairiel: RS2 is RTM.
[14:55:47 CEST] <j-b> release is in 12 days.
[14:55:53 CEST] <j-b> not really insider, tbh.
[14:55:55 CEST] <nevcairiel> RTM perhaps, but until it releases the build will still change a bit
[14:56:06 CEST] <j-b> I doubt it.
[14:56:13 CEST] <nevcairiel> they have never released a RTM as-is
[14:56:19 CEST] <BtbN> Can I build a WSL-ffmpeg and call it from normal windows processes?
[14:56:21 CEST] <j-b> the nightly builds have moved to RS3 already
[14:56:21 CEST] <nevcairiel> always a couple update rollups on top
[14:56:23 CEST] <j-b> BtbN: yes.
[14:56:47 CEST] <BtbN> So you can actually call ELF binaries from Windows now?
[14:56:51 CEST] <j-b> BtbN: either by calling gcc.exe or by cross-compiling with mingw-w64
[14:57:00 CEST] <j-b> BtbN: inside the bash shell, yes.
[14:57:08 CEST] <nevcairiel> not exactly, you can run bash.exe which can then execute ELF binaries
[14:57:14 CEST] <j-b> a Windows.exe cannot call an ELF binary.
[14:57:16 CEST] <BtbN> hm, that's still not too useful then
[14:57:21 CEST] <nevcairiel> why not
[14:57:27 CEST] <nevcairiel> just script everything inside the bash.exe
[14:57:31 CEST] <wm4> lol MS
[14:57:32 CEST] <nevcairiel> it can call both ELF and win32
[14:57:33 CEST] <BtbN> Because it's not transparent for normal applications
[14:57:38 CEST] <j-b> normal applications?
[14:57:47 CEST] <j-b> just build a ffmpeg.exe in the bash
[14:57:48 CEST] <nevcairiel> its a developer tool either way
[14:57:55 CEST] <nevcairiel> not something for applications to use
[14:57:58 CEST] <j-b> once built, it's a normal application
[14:58:13 CEST] <wm4> nevcairiel: hwaccel threading with dxva2 works for me
[14:58:16 CEST] <BtbN> I'm using cygwin was my system shell. Not as a build tool
[14:58:20 CEST] <nevcairiel> wm4: with my sample on vp9?
[14:58:26 CEST] <wm4> framemd5 output is the same for threads=1 and =32
[14:58:35 CEST] <wm4> I tried some random vp9 sample
[14:59:04 CEST] <PaoloP> ubitux: ok. I'm going to make the changes you said.
[14:59:20 CEST] <j-b> BtbN: so what? WSL can call normal applications and ELF ones
[14:59:28 CEST] <wm4> PaoloP: I think your code would still profit from moving some things to functions
[14:59:36 CEST] <wm4> PaoloP: also dropping the custom I/O
[14:59:52 CEST] <BtbN> j-b, but I have also a lot of applications calling into cygwin binaries which
[14:59:56 CEST] <wm4> PaoloP: also not sure why you use the resampler
[15:00:14 CEST] <BtbN> +wouldn't work if they weren't normal .exe files they can blindly execute
[15:00:21 CEST] <wm4> nevcairiel: did you probably try before the async_mutex fix
[15:00:22 CEST] <j-b> cygwin binaries? what is that?
[15:00:28 CEST] <nevcairiel> wm4: todays git master
[15:00:28 CEST] <j-b> it's either win32 or not.
[15:00:36 CEST] <BtbN> binaries linked against cygwin.dll
[15:00:38 CEST] <nevcairiel> when i was merging the dxva changes above
[15:00:57 CEST] <BtbN> built with cygwin gcc
[15:00:59 CEST] <wm4> nevcairiel: I tried with current git master
[15:01:10 CEST] <wm4> b22c4d822b3315449ebb975a691f36933c14a00b
[15:01:28 CEST] <nevcairiel> can you try my clip? it shouldnt be in any way special, i encoded it with vpx a couple years ago myself
[15:01:31 CEST] <wm4> (uh what exactly is the P8 format needed for?)
[15:01:38 CEST] <wm4> nevcairiel: I think I didn't get a link...
[15:01:47 CEST] <nevcairiel> https://files.1f0.de/encodes/tos3k-vp9-b5000.webm
[15:01:58 CEST] <nevcairiel> i linked it earlier, but hey =p
[15:02:08 CEST] <nevcairiel> ffmpeg -hwaccel dxva2 -i  <> -f framemd5 -
[15:02:11 CEST] <nevcairiel> just fails
[15:02:13 CEST] <wm4> oh indeed, I just didn't see it
[15:02:15 CEST] <nevcairiel> adding -threads 1 works
[15:02:40 CEST] <nevcairiel> working with a 1080 GTX, not like that should matter
[15:02:58 CEST] <nevcairiel> vp9 8-bit is present in all the 1000 series
[15:03:07 CEST] <wm4> I only have Intel here... wait does this shit even support vp9
[15:03:23 CEST] <nevcairiel> depends how new it is
[15:03:25 CEST] <PaoloP> wm4: about the resampler, I'm using it because frames are read from a raw file, so they are necessarily not planar, and the format required by the aac encoder is planar. 
[15:03:27 CEST] <wm4> no it doesn't
[15:03:31 CEST] <wm4> nevcairiel: well that explains it
[15:03:47 CEST] <wm4> PaoloP: so why read it from a file, instead of generating it?
[15:03:49 CEST] <nevcairiel> i can try to look into it later, might be a bug in the vp9 code
[15:04:00 CEST] <nevcairiel> i know this sample worked once upon a time
[15:04:05 CEST] <nevcairiel> so i can bisect, i guess
[15:04:05 CEST] <wm4> just to be sure I'll retry the test with h264
[15:04:18 CEST] <nevcairiel> (its my fallback vp9 generic test)
[15:04:56 CEST] <nevcairiel> maybe the recent vp9 cahnges did break it instead of the threading things
[15:05:06 CEST] <BtbN> Which sample are you trying? I might be able to test it with qsv
[15:05:22 CEST] <PaoloP> wm4: because it's much better for the user, so they can adapt the code to a custom source of frames, and it's very useful if the source is a live one (I have a program which grabs frames from a microphone with alsa, and the snippet can be used for encoding that frames)
[15:05:46 CEST] <nevcairiel> it requires an actual hwaccel to test
[15:05:50 CEST] <nevcairiel> so frame threading is used
[15:05:52 CEST] <nevcairiel> qsv doesnt do that
[15:06:13 CEST] <BtbN> Doesn't qsv integrate with the normal h264 hwaccel?
[15:06:22 CEST] <wm4> no
[15:06:49 CEST] <wm4> although you can feed the qsv encoder dxva2 frames etc.
[15:06:56 CEST] <wm4> which jkqxz's work achives AFAIK
[15:07:16 CEST] <PaoloP> wm4: same thing about the custom I/O: I used it for sending the muxed frames to a http streamer made with other libs (libevent, in my case)
[15:07:35 CEST] <wm4> PaoloP: custom I/O should probably be a separate, simpler example
[15:07:52 CEST] <nevcairiel> thats really the best  rule for any examples
[15:08:04 CEST] <nevcairiel> one mega-example that showcases all the features at once is often not very helpful
[15:08:21 CEST] <nevcairiel> rather have small individual examples and the user can then cherry-pick the code they want into their project
[15:08:32 CEST] <PaoloP> wm4: there's already one. In my case, i created an examnple which exposes all the containers to the user: input frame, resampled frame, encoded packet and muxed data
[15:09:22 CEST] <nevcairiel> BtbN: qsv is implemented like cuvid, an actual separate decoder
[15:10:05 CEST] <BtbN> strange, it doesn't show up as decoder for me, but only as hwaccel
[15:10:09 CEST] <PaoloP> nevcairiel: I see, but consider that the snippet I provided includes reading from a custom source + resampling + encoding + muxing with custom I/O all put only in 270 lines
[15:10:28 CEST] <nevcairiel> short isnt necessarily a good property of examples either =p
[15:11:28 CEST] <nevcairiel> they should showcase how to use the API
[15:11:42 CEST] <nevcairiel> a bit more verbose if it helps to understand
[15:11:51 CEST] <PaoloP> nevcairiel: I see, but all these tasks are covered and they can be easily separated/adapted to other codecs/muxer. I decided to use the adts because it covers all these tasks
[15:11:52 CEST] <wm4> BtbN: where?
[15:11:59 CEST] <wm4> nevcairiel: all fine for h264
[15:12:08 CEST] <BtbN> in configure output
[15:12:10 CEST] <wm4> I don't know if ffmpeg.c used hw decoding for that though
[15:12:11 CEST] <nevcairiel> wm4: yeah h264 worked for me as well
[15:12:15 CEST] <wm4> because it doesn't say
[15:12:21 CEST] <PaoloP> and they are strictly sequential
[15:12:23 CEST] <nevcairiel> check if the output format is nv12
[15:12:29 CEST] <BtbN> The ffmpeg.exe it built refuses to print any textual output though
[15:12:30 CEST] <wm4> BtbN: the qsv decoders still need to expose AVHWAccels
[15:12:41 CEST] <wm4> BtbN: but that's only because of I don't know why
[15:12:52 CEST] <BtbN> same reason as cuvid I'd assume
[15:13:33 CEST] <wm4> yeah, ff_get_format
[15:13:38 CEST] <wm4> (but that part could be removed)
[15:14:00 CEST] <PaoloP> nevcairiel: it showcases of to use the api in all the main tasks.
[15:18:51 CEST] <nevcairiel> peloverde: I got a LATM AAC sample with PCEs, which apparently wasnt handled much in the decoder before, does this look extremely terrible? https://pastebin.com/gAkgv7k5 (sample https://files.1f0.de/samples/arte_HD_Test.ts, from german DVB-T2)
[15:20:23 CEST] <jkqxz> ubitux:  I can do QSV merge later today, if you can wait.
[15:20:59 CEST] <ubitux> please do :)
[15:21:01 CEST] <ubitux> thanks :)
[15:21:24 CEST] <mateo`> jkqxz: can I push a patch ? (or you have already started the merge process)
[15:22:21 CEST] <jkqxz> Go ahead, I'm not doing anything yet.
[15:22:41 CEST] <cone-056> ffmpeg 03Matthieu Bouron 07master:afd257b43feb: doc/examples/filtering_video: switch to new decoding API
[15:22:42 CEST] <cone-056> ffmpeg 03Matthieu Bouron 07master:03372d0a90c0: doc/examples/filtering_audio: switch to new decoding API
[15:27:12 CEST] <jkqxz> nevcairiel:  Errors like that sound more like collision of the decoder using reference frames with the readback, rather than inside the codec?  (Some dxva2 drivers having problems with multiple readers at once.)
[15:27:38 CEST] <nevcairiel> the hw calls would fail then, and those log specific messages
[15:27:41 CEST] <nevcairiel> didnt see any of that
[15:28:25 CEST] <jkqxz> I did try VP9 threaded hwaccel for <http://git.videolan.org/?p=ffmpeg.git;a=commit;h=9560766a6164ed362e7f274242a024fe7b71d154>, and it was fine there.
[15:28:42 CEST] <jkqxz> I'll test your sample later, though.
[15:28:55 CEST] <nevcairiel> i can try to bisect
[15:29:03 CEST] <nevcairiel> i think vp9dec was refactored a bit last week
[15:29:07 CEST] <nevcairiel> maybe something broke
[15:29:29 CEST] <wm4> jkqxz: on windows or vaapi?
[15:29:33 CEST] <jkqxz> Right, that's also possible.
[15:29:43 CEST] <nevcairiel> anyway this w hole async safe business was supposed to avoid the multipler readers problem
[15:29:46 CEST] <jkqxz> That was VAAPI.  I don't have any Windows VP9 hardware.
[15:30:04 CEST] <j-b> jkqxz: do you want one?
[15:30:14 CEST] <wm4> nevcairiel: yes the approach is making any access exclusive to one thread
[15:30:55 CEST] <jkqxz> Wasn't it only doing that in the decoder?  What people do with the surfaces after that is not something we can restrict.
[15:31:27 CEST] <wm4> jkqxz: no, globally (that's why it used async_mutex as "inverse" lock)
[15:31:34 CEST] <nevcairiel> as long as they dont multi-thread, it should be fine
[15:31:47 CEST] <nevcairiel> (ie. only use it on the same thread they call the decode  API on)
[15:32:23 CEST] <jkqxz> Right, yes, sorry.  It only accesses the reference frames while inside the lavc calls.
[15:35:26 CEST] <jkqxz> j-b:  One what?  (I could put Windows on existing stuff I have, it's just rather inconvenient.)
[15:36:47 CEST] <jkqxz> Wrt comment above about qsvdec, one of my aims with the device/mapping stuff is to kill the qsv decoder entirely and replace it with platform hwaccel + mapping.
[15:37:08 CEST] <jkqxz> (Not sure who that comment is aimed at, but wm4 mentioned it...)
[15:40:17 CEST] <stevenliu> Hello wm4  can i move the strreplace into the libavutil if the original author agreed
[15:40:28 CEST] <wm4> stevenliu: sure
[15:40:33 CEST] <ubitux> jkqxz: speaking of hwmap, please confirm that it works when you have time, i couldn't test it
[15:40:54 CEST] <stevenliu> or must under apache ,mit license?
[15:42:16 CEST] <stevenliu> ok , thanks :)
[15:44:15 CEST] <wm4> stevenliu: whatever the author agreed to
[15:44:23 CEST] <wm4> I think apache would be incompatible though
[15:44:51 CEST] <wm4> (and moving to libavutil is just my opinion - it's probably not absolutely required)
[15:45:53 CEST] <stevenliu> Your think is maybe good, that function maybe a universal.
[16:04:24 CEST] <rcombs> wm4: stevenliu: iirc the original is public domain, so it can be relicensed under LGPL just fine
[16:04:45 CEST] <rcombs> original author's permission never hurts, though (particularly since public domain doesn't exist in all countries)
[16:05:32 CEST] <wm4> if there was such a statement on the website I found I missed it
[16:06:02 CEST] <stevenliu> yes , there is
[16:06:22 CEST] <stevenliu> Author:	Me (Laird Shaw). Licence:	Public domain. Attribution:	Optional. If you choose to indicate attribution when using this function, feel free to link to this page.
[16:08:35 CEST] <rcombs> should it be av_ or avpriv_?
[16:08:54 CEST] <rcombs> the API is reasonably simple, so av_strreplace seems reasonable
[16:09:11 CEST] <nevcairiel> dont create new avpriv stuff
[16:09:23 CEST] <nevcairiel> if something is  deemed useful, make it public
[16:09:26 CEST] <nevcairiel> otherwise its not useful =p
[16:09:45 CEST] <rcombs> reasonable enough
[16:09:59 CEST] <stevenliu> OK, av_strreplace
[16:10:29 CEST] <stevenliu> move it to libavutil/avstring.c, ok?
[16:10:35 CEST] <rcombs> sounds good
[16:40:14 CEST] <cone-056> ffmpeg 03Michael Niedermayer 07master:8779ec91b223: avformat/mux: Check return code of av_packet_split_side_data()
[16:40:15 CEST] <cone-056> ffmpeg 03Michael Niedermayer 07master:004f27f0fb6e: ffmpeg: Fix avframe memleak
[16:40:15 CEST] <stevenliu> done
[16:40:16 CEST] <cone-056> ffmpeg 03Michael Niedermayer 07master:59b8c2a4e668: doc/examples/encode_audio: Favor a sample rate close to 44khz instead of the maximum sample rate
[16:46:51 CEST] <jkqxz> ubitux:  Simple cases of hwmap work (drawtext on mapped hardware frames, hardware decode and map for encode).  I'll look at it more carefully later when doing qsv.
[16:52:39 CEST] <ubitux> jkqxz: it would be nice to have some doc for the filter btw :)
[16:59:13 CEST] <rcombs> hmm, I guess vf_overlay on hwmapped frames for bitmap subs would probably be faster or slower than doing download->overlay->upload
[17:03:47 CEST] <wm4> rcombs: wouldn't it have to upload only a small part of the frame
[17:03:55 CEST] <jkqxz> Depends how much you do.  On Intel mapping gives you uncached memory so reading (for alpha blend, say) is a disaster.  If you only write, or only work with a little bit of the frame, then it's good.
[17:04:14 CEST] <rcombs> yeah, it's alpha-blend
[17:04:24 CEST] <wm4> I thought we didn't need uncached memcpy on intel?
[17:05:09 CEST] <serhii> Hello! I got error message "Your FFProbe version is too old and does not support `-help` option, please upgrade." How can I upgrade it? In linux apt update shows this is latest version
[17:05:53 CEST] <wm4> serhii: install a better idstro
[17:05:56 CEST] <wm4> *distro
[17:06:30 CEST] <jkqxz> wm4:  That was because it uses the GPU-driven copy there.  That's also doable here, but it's a whole-frame download/upload anyway.
[17:09:21 CEST] <serhii> what is distro?
[17:09:49 CEST] <rcombs> it's generally all the same physical RAM, right?
[17:10:23 CEST] <rcombs> I don't really have a great understanding of how the memory handling works here, e.g. why we can't map that same region as normally-cached
[17:12:21 CEST] <wm4> serhii: something that doesn't ship a ffmpeg which is probably a decade old
[17:13:37 CEST] <PaoloP> in case 1) I send a patch 2) some_user replies suggesting modifications 3) I do the modifications and I have to send both the new patch + a text (in the mail) which replies to some_user's observations,  should I send two emails (one with the patch and one with my answer) or only one email?
[17:50:18 CEST] <ubitux> this time_base thing needs to be fixed before any release
[17:50:32 CEST] <ubitux> it's undocumented and probably conflicting with lavc settings
[17:51:05 CEST] <wm4> which time_base thing (weren't there several issues)
[17:51:21 CEST] <ubitux> the thing i just ping'ed on ffmpeg-devel
[17:51:23 CEST] <ubitux> about 3ac46a0a62386a52e38c066379ff36b5038dd4d0
[17:51:34 CEST] <ubitux> conflicting with at least lavc
[17:53:16 CEST] <wm4> hm don't see any mail
[17:54:06 CEST] <ubitux> i only see the reply from michael
[17:54:10 CEST] <ubitux> (ni)
[17:54:29 CEST] <ubitux> oh you're refering to mine
[17:54:41 CEST] <ubitux> http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209426.html
[17:55:07 CEST] <wm4> ah my mail reader just fetched it
[17:57:49 CEST] <ubitux> also, should we revert the jpeg thing?
[17:58:06 CEST] <ubitux> it's at least crashing openbsd
[17:59:11 CEST] <wm4> (don't know what this refers to either)
[18:00:43 CEST] <ubitux> wm4: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209103.html
[18:01:18 CEST] <wm4> can the author be asked to fix it?
[18:02:05 CEST] <ubitux> atomnuker: can you contact that guy?
[18:04:48 CEST] <durandal_1707> can you fix it?
[18:06:02 CEST] <BBB> ubitux: is that the patch that also had valgrind/asan warnings?
[18:06:44 CEST] <wm4> if the author doesn't react and nobody can/wants to fix it, reverting would be reasonable
[18:07:22 CEST] <kierank> wm4: far too much common sense
[18:07:41 CEST] <kierank> michaelni: do you know how long clusterfuzz takes to react
[18:07:48 CEST] <kierank> these h264 changes make me nervous
[18:07:50 CEST] <kierank> esp with sliced threads
[18:08:10 CEST] <ubitux> BBB: yes
[18:08:28 CEST] <ubitux> valgrind/asan errors + openbsd crashes
[18:08:36 CEST] <BBB> kierank: I can do more testing with slice threads if you want
[18:08:48 CEST] <ubitux> (it's been 2 weeks now)
[18:08:49 CEST] <kierank> I will fire up some fuzz machines at work tonight
[18:08:52 CEST] <BBB> kierank: Im trying to make it more secure, not less
[18:09:04 CEST] <kierank> I mean the merge itself is the problem
[18:09:05 CEST] <BBB> ubitux: then revert, IMO
[18:09:07 CEST] <kierank> the libav stuff
[18:09:10 CEST] <BBB> oooo sorry
[18:09:11 CEST] <kierank> not the fixes
[18:09:14 CEST] <BBB> I thought you meant my stuff
[18:09:16 CEST] <BBB> yes, agreed
[18:10:55 CEST] <atomnuker> ubitux: he still hasn't responded, I'll try to fix it tonight
[18:11:01 CEST] <michaelni> kierank, i saw it react within 24h i think to fixes being pushed
[18:11:20 CEST] <kierank> ok, then frame threads should be tested, i will do slice threads
[18:31:14 CEST] <michaelni> gcc: Internal error: Killed (program cc1)
[18:31:15 CEST] <michaelni> common.mak:60: recipe for target 'libavcodec/h264qpel.o' failed
[18:32:08 CEST] <michaelni> doesnt reproduce of course
[18:32:37 CEST] <BBB> I believe after the vp9 split, h264qpel.o is the largest object file in libavcodec/
[18:32:48 CEST] <BBB> maybe its related to that?
[18:32:54 CEST] <michaelni> yes, that makes sense
[18:32:57 CEST] <BBB> (full HD, or whatever)
[18:33:02 CEST] <BBB> (or OOM)
[18:33:08 CEST] <michaelni> that was on a openbsd VM, with limited memory
[18:33:16 CEST] <BBB> probably OOM then
[18:33:19 CEST] <michaelni> yes
[18:46:26 CEST] <michaelni> ubitux, btw vsynth1-ljpeg doesnt segfault if i run it manually on openbsd
[19:17:32 CEST] <BBB> michaelni: is |= a good way to retain specific AVERROR(errno) values?
[19:17:42 CEST] <BBB> michaelni: maybe its better to just store the first negative and then return?
[19:17:53 CEST] <BBB> michaelni: (re:clearvideo)
[19:18:36 CEST] <michaelni> if we return after the first iam not sure if that leaves uninitialized blocks
[19:24:41 CEST] <BBB> Im no clearvideo expert and probably shouldnt be ;-)
[19:24:51 CEST] <BBB> maybe the loop can continue but we dont or the return of _mb
[19:25:23 CEST] <BBB> if one mb returns -3 and the other -4, the frame function returns -1
[19:25:26 CEST] <BBB> I dont think thats wanted
[19:26:22 CEST] <michaelni> no, the |= is ugly but it was there before
[19:26:44 CEST] <michaelni> ill fix that
[19:28:07 CEST] <BBB> tnx :)
[19:45:42 CEST] <thebombzen> the ffv1 spec at: https://www.ffmpeg.org/~michael/ffv1.html appears to be missing mathjax
[19:47:10 CEST] <thebombzen> is this intentional
[19:48:13 CEST] <thebombzen> it looks like it uses MathHTML but that doesn't seem to be as effective as MathJax (which is what Wikipedia and StackExchange use, afaik)
[19:48:37 CEST] <thebombzen> also it lists the email as michaelni at gmx dot at
[19:49:03 CEST] <nevcairiel> thats likely intentional to avoid spam =p
[19:52:15 CEST] <thebombzen> no I mean
[19:52:18 CEST] <thebombzen> it listes the actual email
[19:52:23 CEST] <thebombzen> but that's not michael's email
[19:52:37 CEST] <thebombzen> it might have used to have been
[19:53:04 CEST] <thebombzen> but yea, it appears the LaTeX code doesn't render at all in Chromium but does render in Firefox, but incorrectly
[19:53:05 CEST] <thebombzen> https://i.imgur.com/RqJMiOk.png
[19:53:28 CEST] <thebombzen> this is not really a surprise, because the code at the top mentions Gecko
[19:54:06 CEST] <michaelni> thebombzen, about math markup, dave rice was working related stuff in the ffv1 text, you likely want to talk with him
[19:54:26 CEST] <thebombzen> okay
[19:54:45 CEST] <michaelni> also i need to update that file, formating was changed recently
[19:56:51 CEST] <thebombzen> ah yes, it appears that way from "make ffv1.html"
[19:58:03 CEST] <michaelni> file updated from git
[20:04:22 CEST] <thebombzen> michaelni: you probably also have to push style.css
[20:04:37 CEST] <thebombzen> which currently is not there and referenced by ffv1.html
[20:06:45 CEST] <atomnuker> thebombzen: mathjax is the worst choice you can make
[20:06:57 CEST] <thebombzen> why
[20:06:59 CEST] <atomnuker> its javascript outputting svg
[20:07:14 CEST] <thebombzen> well it works, and what's currently happening doesn't
[20:07:15 CEST] <atomnuker> you should just compile it on your machine, it spits out svg and you embed that in
[20:07:34 CEST] <thebombzen> the whole point of mathjax is you don't have to do that
[20:07:36 CEST] <atomnuker> mathml is the best choice the problem is the bastards working on chrome hate it
[20:07:59 CEST] <thebombzen> MathML not only doesn't work but it's XML
[20:08:05 CEST] <atomnuker> they'd rather have an entire javascript infrastructure you have to download over and over again
[20:08:15 CEST] <thebombzen> MathML doesn't work
[20:08:19 CEST] <atomnuker> works on firefox
[20:08:20 CEST] <thebombzen> you keep saying it's better
[20:08:28 CEST] <thebombzen> "works on firefox" is not working
[20:08:31 CEST] <atomnuker> the best is obviously svg
[20:08:37 CEST] <thebombzen> that's a browser-specific extension
[20:08:40 CEST] <atomnuker> and mathml is better on paper
[20:08:44 CEST] <thebombzen> MathML is XML
[20:08:45 CEST] <atomnuker> its not, its svg
[20:08:55 CEST] <thebombzen> MathML requires you to code in XML
[20:09:01 CEST] <atomnuker> yes, and if it was standardized it is the best
[20:09:10 CEST] <thebombzen> It is not the best
[20:09:12 CEST] <atomnuker> you can compile from latex to that
[20:09:13 CEST] <thebombzen> because it requires you to code in XML
[20:09:27 CEST] <thebombzen> and "if it were standardized" is a bit pushing it
[20:09:34 CEST] <atomnuker> you always write in latex so you always have machines doing the work
[20:09:37 CEST] <thebombzen> it also doesn't render correctly even in firefox
[20:09:48 CEST] <atomnuker> thebombzen: it would be if chrome people didn't hate it
[20:10:01 CEST] <atomnuker> thebombzen: it does, I wrote something just a month ago and it works
[20:10:02 CEST] <thebombzen> perhaps people hate it because it's not cross-browser and requires XML?
[20:10:29 CEST] <atomnuker> its not cross browser because 1 browser doesn't like it and it being xml doesn't matter as I explained 3 times earlier
[20:11:17 CEST] <atomnuker> what matters is bandwidth per view, and you don't get better than mathml
[20:11:25 CEST] <atomnuker> you get close or better with just pure svg
[20:11:30 CEST] <atomnuker> you get shit with mathjax
[20:12:06 CEST] <atomnuker> so straight up svg is the best unless you're one of those people
[20:12:06 CEST] <thebombzen> atomnuker: this is not correct https://i.imgur.com/XInnr5B.png
[20:12:22 CEST] <thebombzen> the problem with MathML is that it *doesn't work*
[20:12:38 CEST] <thebombzen> it doesn't actually matter how good it is in its environment and bandwidth
[20:12:42 CEST] <thebombzen> because it doesn't render correctly
[20:12:48 CEST] <atomnuker> that same file renders correctly here
[20:13:39 CEST] <atomnuker> if you don't like it then yeah, submit a patch
[20:14:02 CEST] <thebombzen> well if I were to submit a patch I'd change --mathml to --mathjax
[20:14:05 CEST] <thebombzen> because MathJax actually works
[20:14:24 CEST] <atomnuker> don't expect a javascript framework to be merged just for a pure html page
[20:14:30 CEST] <atomnuker> use straight up svg
[20:15:02 CEST] <thebombzen> "to be merged"
[20:15:02 CEST] <thebombzen> what
[20:15:07 CEST] <thebombzen> what are you talking about
[20:15:11 CEST] <atomnuker> into the spec's repository
[20:15:13 CEST] <thebombzen> this is what it should look like: https://i.imgur.com/i7LqRwM.png
[20:15:20 CEST] <thebombzen> atomnuker: why would you merge it
[20:15:23 CEST] <llogan> durandal_1707: any thoughts on http://www.ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209031.html ?
[20:15:29 CEST] <thebombzen> when they literally provide  CDN so you don't have to
[20:15:32 CEST] <atomnuker> thebombzen: the specs are in a repository
[20:15:43 CEST] <atomnuker> and if it goes down or you don't have internet?
[20:15:55 CEST] <thebombzen> then use git submodules
[20:16:06 CEST] <atomnuker> then you have to merge it obviously
[20:16:08 CEST] <thebombzen> you don't have to commit the file
[20:16:11 CEST] <atomnuker> into a repository
[20:16:12 CEST] <durandal_1707> llogan: ok
[20:16:24 CEST] <thebombzen> but either way atomnuker that doesn't change the fact that MathML renders it incorrectly
[20:16:32 CEST] <thebombzen> none of what your'e saying matters if MathML doesn't work and MathJax does
[20:16:33 CEST] <atomnuker> thebombzen: on your bloody system
[20:16:41 CEST] <llogan> durandal_1707: thanks. i'll push it.
[20:16:57 CEST] <thebombzen> my bloody system is using latest firefox with no extensions
[20:16:59 CEST] <thebombzen> what do you want
[20:17:28 CEST] <atomnuker> thebombzen: and you can't seem to get it through your thick bloody scull embedding svgs is better and more feasible than a fucking javascript monstrosity
[20:18:19 CEST] <thebombzen> Monstrosity?
[20:18:20 CEST] <thebombzen> 63k?
[20:18:27 CEST] <thebombzen> hardley a monstrosity
[20:18:29 CEST] <atomnuker> and how much for the entire spec html, huh?
[20:18:52 CEST] <thebombzen> 90k
[20:18:56 CEST] <atomnuker> exactly
[20:19:32 CEST] <thebombzen> atomnuker: what you're failing to get through that thick bloody skull of yours
[20:19:41 CEST] <thebombzen> is that overhead doesn't matter, if MathML doesn't work
[20:20:07 CEST] <RiCON> thebombzen: https://chrome.google.com/webstore/detail/math-anywhere/gebhifiddmaaeecbaiemfpejghjdjmhc/related
[20:20:10 CEST] <RiCON> there, fixed
[20:20:12 CEST] <atomnuker> hey, don't steal my way of swearing!
[20:21:43 CEST] <thebombzen> it's interesting that RiCON's suggested fix is to use MathJax
[20:22:16 CEST] <thebombzen> should I be pointing out that MathJax is the solution to a problem caused by MathML?
[20:22:28 CEST] <RiCON> for a browser missing mathml parsing, sure
[20:22:31 CEST] <RiCON> firefox can render it fine
[20:22:41 CEST] <thebombzen> no it can't
[20:23:02 CEST] <thebombzen> this is not "fine": https://i.imgur.com/XInnr5B.png
[20:24:26 CEST] <RiCON> what version is this?
[20:25:39 CEST] <RiCON> https://i.fsbn.eu/CSK2.png
[20:32:11 CEST] <cone-056> ffmpeg 03Gyan Doshi 07master:2104e3383fd1: avfilter/avf_abitscope: Correct range for framerate
[20:46:31 CEST] <thebombzen> RiCON: 50.1.0 Release
[20:58:31 CEST] <peloverde> Do you have the mathml fonts?
[20:58:58 CEST] <peloverde> https://developer.mozilla.org/en-US/docs/Mozilla/MathML_Project/Fonts
[20:59:58 CEST] <thebombzen> why should I have to download them
[21:00:01 CEST] <thebombzen> and no that's no the issue
[21:00:08 CEST] <thebombzen> the issue is the spacing doesn't work
[21:00:36 CEST] <thebombzen> (and yes I do, I have Texlive installed)
[21:13:10 CEST] <RiCON> oh, didn't think of that
[21:13:19 CEST] <RiCON> yeah, i'm using Cambria Math, which comes with Windows
[22:13:59 CEST] <cone-056> ffmpeg 03Michael Niedermayer 07master:e976e68fc551: avcodec/atrac3: Check init_get_bits8() for failure
[22:15:19 CEST] <BBB> michaelni: ty for the clearvideo change
[22:15:32 CEST] <michaelni> np
[22:16:23 CEST] <cone-056> ffmpeg 03Anton Khirnov 07master:b115a35ea62b: hwcontext_qsv: add support for the P8 format
[22:16:24 CEST] <cone-056> ffmpeg 03Mark Thompson 07master:59b1942aae47: Merge commit 'b115a35ea62b8f479b48d99a601f0e157517301e'
[22:16:47 CEST] <ubitux> yey
[22:17:33 CEST] <cone-056> ffmpeg 03Anton Khirnov 07master:b91ce4860054: hwcontext_qsv: do not fail when download/upload VPP session creation fails
[22:17:34 CEST] <cone-056> ffmpeg 03Mark Thompson 07master:7cb082ac2ff0: Merge commit 'b91ce4860054430d3712deb0d9487cac2fcb7d68'
[22:45:59 CEST] <cone-056> ffmpeg 03Anton Khirnov 07master:8ea15afbf2c1: hwcontext_qsv: transfer data through the child context when VPP fails
[22:46:00 CEST] <cone-056> ffmpeg 03Mark Thompson 07master:546524056d7c: Merge commit '8ea15afbf2c1ec89b5d4bac1f0b8345e4b906a5d'
[22:47:13 CEST] <cone-056> ffmpeg 03Michael Niedermayer 07master:4064f3f0dfe7: avfilter/af_sofalizer: Fix bad shift
[22:47:14 CEST] <cone-056> ffmpeg 03Michael Niedermayer 07master:4798237f01cf: avfilter/deshake_opencl: Remove redundant return
[22:47:15 CEST] <cone-056> ffmpeg 03Michael Niedermayer 07master:855305fac239: avfilter/vf_minterpolate: Use dx and dy
[22:47:54 CEST] <jkqxz> ^ only works for DXVA2, which I don't think was intended.  AFAIK it can't be invoked for VAAPI, though, so I'm ignoring it for now.
[22:54:38 CEST] <jkqxz> Hmph.  Same issue with the next one.  That's more obvious, but I'll fix it separately.  (I seem to already have fixed it without noticing when adding more mapping cases, so I'll drag that in somehow.)
[22:55:09 CEST] <cone-056> ffmpeg 03Anton Khirnov 07master:e8bbacbf5290: hwcontext_qsv: support frame mapping
[22:55:10 CEST] <cone-056> ffmpeg 03Mark Thompson 07master:e3f9c5826ace: Merge commit 'e8bbacbf529049c401bfeea70d5e0b5d2c8b6de6'
[23:02:29 CEST] <cone-056> ffmpeg 03Anton Khirnov 07master:404e51478eca: qsv{dec,enc}: always use an internal mfxFrameSurface1
[23:02:30 CEST] <cone-056> ffmpeg 03Mark Thompson 07master:2f18e452f88f: Merge commit '404e51478ecad060249d5b9bee6ab39a8a9d8c1c'
[23:06:11 CEST] <cone-056> ffmpeg 03Anton Khirnov 07master:00aeedd84105: qsv{dec,enc}: use a struct as a memory id with internal memory allocator
[23:06:12 CEST] <cone-056> ffmpeg 03Mark Thompson 07master:c0f2a8eac172: Merge commit '00aeedd84105a17f414185bd33ecadebeddb3a27'
[23:15:25 CEST] <cone-056> ffmpeg 03Anton Khirnov 07master:4ab61cd983b5: qsv{enc,dec}: extend the internal frame allocator
[23:15:26 CEST] <cone-056> ffmpeg 03Mark Thompson 07master:ff821fdfced0: Merge commit '4ab61cd983b539749bd621ea271624ddb5196a8e'
[23:16:58 CEST] <jkqxz> ubitux:  (End of that qsv stretch.)
[23:17:28 CEST] <ubitux> jkqxz: awesome! thanks a lot
[23:19:47 CEST] <cone-056> ffmpeg 03Luca Barbato 07master:7471352f1915: pixfmt: Add GRAY12
[23:19:48 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:719f1a923f2f: Merge commit '7471352f1915813cda725ce624607d84b5a3a61c'
[23:21:58 CEST] <cone-056> ffmpeg 03Luca Barbato 07master:ab839054e662: swscale: Add GRAY12
[23:21:59 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:62e46fac2646: Merge commit 'ab839054e662d3227e1f795ba1dfd01fe1cf305c'
[23:22:41 CEST] <cone-056> ffmpeg 03Andreas Cadhalpun 07master:43de8b328b62: lzf: update pointer p after realloc
[23:22:42 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:9813df118984: Merge commit '43de8b328b62cf21ec176c3989065168da471a5f'
[23:23:27 CEST] <cone-056> ffmpeg 03Diego Biurrun 07master:943533d64c7f: avconv: Correct function pointer assignments in options array
[23:23:28 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:aac40dd6154d: Merge commit '943533d64c7fa7a1b2fc9559e67652c349d21d51'
[23:24:26 CEST] <cone-056> ffmpeg 03Diego Biurrun 07master:88f0cf8cd30c: avplay: Correct function pointer assignments in options array
[23:24:27 CEST] <cone-056> ffmpeg 03Clément BSsch 07master:2a68d3b1a508: Merge commit '88f0cf8cd30c8ea283430e6710a7bd98bb9c0301'
[23:25:47 CEST] <jkqxz> nevcairiel:  Trying your VP9 test, immediate segfault with VAAPI.  avctx->sw_pix_fmt is no longer set.
[23:26:12 CEST] <jkqxz> Having fixed that, it works fine with threads - run several times and the checksums are always the same.
[23:26:15 CEST] <ubitux> time to sleep for me
[23:26:17 CEST] Action: ubitux &
[23:27:12 CEST] <durandal_170> ubitux: please make nlmeans faster and better
[23:29:20 CEST] <nevcairiel> jkqxz: any particular place you set it?
[23:30:13 CEST] <jkqxz> It's NONE at <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/vaapi_vp9.c;h=d8ece75df4fe99a4d21f80e89a6a064534a3e6b3;hb=HEAD#l44>, and previously it was not.
[23:30:53 CEST] <nevcairiel> i assume that problem also affected running without threads?
[23:31:05 CEST] <jkqxz> Yes, that's entirely fatal to it working at all.
[23:31:12 CEST] <nevcairiel> odd then
[23:32:00 CEST] <jkqxz> It will break dxva2 for 10-bit as well, since it will allocate 8-bit surfaces.
[23:36:07 CEST] <cone-056> ffmpeg 03Michael Niedermayer 07master:fe46d92c15ca: avcodec/clearvideo: Do not lose the return code of decode_mb()
[23:36:08 CEST] <cone-056> ffmpeg 03Michael Niedermayer 07master:477ba8f9391f: avfilter/af_chorus & aecho: Handle NULL return from av_strtok()
[23:36:09 CEST] <cone-056> ffmpeg 03Michael Niedermayer 07master:bd8201566d75: avformat/libopenmpt: Check for avio_size() failure
[23:36:10 CEST] <cone-056> ffmpeg 03Michael Niedermayer 07master:77a3c288bd57: avformat/mov: Init ref_sc / ref_st to NULL
[23:36:11 CEST] <cone-056> ffmpeg 03Michael Niedermayer 07master:afebf470ca73: avutil/tests/dict: Check return of av_dict_parse_string()
[23:38:03 CEST] <nevcairiel> this is the kind of output it get: https://pastebin.com/hZwB3PBH .. it somehows forgets any non-I frames and decodes to some weird hash
[23:38:44 CEST] <nevcairiel> (that is one green image, so zero surface?
[23:38:49 CEST] <nevcairiel> -?+)
[23:39:22 CEST] <jkqxz> Where does the EPERM come from?
[23:39:31 CEST] <nevcairiel> thats just w hat -1 translates t o
[23:39:47 CEST] <nevcairiel> my spacebar really needs better manners
[23:44:00 CEST] <iive> nevcairiel: yes, green is UV={0;0}
[23:44:11 CEST] <nevcairiel> the question was by accident
[23:44:13 CEST] <nevcairiel> but yes
[23:45:05 CEST] <iive> ffmpeg usually allocates empty image buffers with 0x80, so they look gray.
[23:45:22 CEST] <nevcairiel> not for hardware
[23:45:26 CEST] <nevcairiel> although it could, i guess
[23:45:54 CEST] <durandal_170> it shouldnt memset at all
[23:47:34 CEST] <BBB> I dont believe it does; it used to, years ago
[23:48:15 CEST] <nevcairiel> it only memsets frames if it generates missing references
[23:48:20 CEST] <nevcairiel> for h264 anyway
[23:48:26 CEST] <durandal_170> it does, we merged libav , and it was elenril idea iiirc
[23:48:30 CEST] <nevcairiel> so it has an "empty" one to use as a reference frame
[23:50:59 CEST] <jkqxz> nevcairiel:  Haha, I think your problem is actually exactly the same as mine.  Is your -1 coming from <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/dxva2_vp9.c;h=fd7bd98afd312f0b1838d48f3bff72e9ef567138;hb=HEAD#l54>?  (So it isn't actually decoding at all, hence a blank frame.)
[23:51:21 CEST] <nevcairiel> but it works with threads 1 for me
[23:51:33 CEST] <nevcairiel> how did you fix yours?
[23:52:01 CEST] <jkqxz> Um, by hard-coding AV_PIX_FMT_YUV420P.  Still looking for the actual fix.
[23:52:10 CEST] <nevcairiel> ah
[23:52:52 CEST] <jkqxz> Huh, it works with -threads 1 for me as well.  I wonder what I tried when I said that it didn't above?
[23:53:00 CEST] <nevcairiel> that fixes it
[23:53:25 CEST] <jkqxz> I suspect this is going to be because there are actually 9001 AVCodecContexts lying around and we only set sw_pix_fmt on some of them.
[23:53:35 CEST] <jkqxz> When you have threads.
[23:53:46 CEST] <nevcairiel> it worked once upon a time
[23:54:35 CEST] <jkqxz> Are you sure?  I went back to before (some of?) wm4's threading stuff and it was the same.
[23:56:49 CEST] <nevcairiel> yes
[23:57:05 CEST] <nevcairiel> BBB and myself  worked some on it to make vp9.c handle that properly
[23:57:11 CEST] <jkqxz> <http://sprunge.us/ZiFA>
[23:57:19 CEST] <jkqxz> Nothing to do with VP9.
[23:57:30 CEST] <jkqxz> (None of the other hwaccels look at sw_pix_fmt.)
[23:58:01 CEST] <BBB> aha
[23:58:04 CEST] <BBB> nice
[23:58:17 CEST] <jkqxz> Does that work for you?
[23:59:07 CEST] <nevcairiel> yes
[23:59:48 CEST] <jkqxz> I'll send it to the ML?
[00:00:00 CEST] --- Fri Mar 31 2017