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

[burek]

[00:21:43 CEST] <J_Darnley> Should I make some sort of note in the commit messages that I have sort of cherry-picked these commits?
[01:07:21 CEST] <J_Darnley> Ah.  I didn't intend for those to have CCs.  Oh well.
[01:34:20 CEST] <nevcairiel> git does that by default i think, can be a bit unexpected sometimes
[01:46:49 CEST] <J_Darnley> Yeah.  I forgot about them plus I have configed it so that I don't CC myself.
[13:26:52 CEST] <J_Darnley> Rats.  I should get my Laptop's ssh key added to the git server
[13:29:06 CEST] <cone-627> ffmpeg 03raymondzheng 07master:9f20cc5c8458: libavformat/http: return EIO when ffurl_read return 0, but s->off < target_end
[13:31:40 CEST] <atomnuker> J_Darnley: better yet use 1 ssh key
[13:33:07 CEST] <J_Darnley> Maybe, but putty doesn't support these "curve" algorithms
[13:34:04 CEST] <nevcairiel> then you should upgrade putty
[13:34:04 CEST] <nevcairiel> :)
[13:34:17 CEST] <RiCON> J_Darnley: it does
[13:34:22 CEST] <nevcairiel> 0.68 added support for elliptic curves
[13:38:17 CEST] <J_Darnley> Ha
[13:38:28 CEST] <J_Darnley> I really should
[13:50:45 CEST] <cone-627> ffmpeg 03Henrik Gramner 07master:406e0ddc0b9b: x86inc: Fix call with memory operands
[13:50:46 CEST] <cone-627> ffmpeg 03Henrik Gramner 07master:88dcdfad0964: x86inc: Make REP_RET identical to RET in SSSE3+ functions
[13:50:47 CEST] <cone-627> ffmpeg 03Henrik Gramner 07master:cd4ca8245963: x86inc: Prefer r14/r15 over r12/r13 on x86-64
[13:50:48 CEST] <cone-627> ffmpeg 03Anton Mitrofanov 07master:d991b3e8a87a: x86inc: Remove argument from WIN64_RESTORE_XMM
[13:53:05 CEST] <BBB> what happened to the 5th patch?
[14:00:05 CEST] <J_Darnley> I want to speak to x264dev first
[14:05:15 CEST] <BBB> ok
[14:05:24 CEST] <BBB> is the idct patch waiting for any input from me?
[14:09:30 CEST] <J_Darnley> Not presently
[14:09:57 CEST] <J_Darnley> I have not managed much work on it since your rounding contibution
[14:10:10 CEST] <J_Darnley> My nasm troubles have been in the way.
[14:10:14 CEST] <BBB> :(
[14:10:17 CEST] <BBB> sorry about that
[14:10:25 CEST] <BBB> so are we moving to nasm now?
[14:10:47 CEST] <J_Darnley> I am going to submit a patch that will require 2.11
[14:10:49 CEST] <BBB> the nasm on my system still cannot actually compile ffmpeg (the rodata in vp9 mc filters fails to work, I think)
[14:10:50 CEST] <JEEB> yasm's raison d'etre after all faded aways
[14:10:53 CEST] <RiCON> we should, isn't yasm abandonned?
[14:11:14 CEST] <JEEB> and yes, mostly abandoned since yasm-ng didn't go anywhere
[14:11:17 CEST] <JEEB> (yes, that was a thing)
[14:11:20 CEST] <J_Darnley> RiCON: Yes it seems to be
[14:11:45 CEST] <J_Darnley> I blame them for want to rewrite in c++ with boost
[14:11:58 CEST] <J_Darnley> (I think that was the plan)
[14:12:11 CEST] <wm4> wat
[14:13:31 CEST] <JEEB> yes, yasm-ng was a C++ rewrite
[14:13:34 CEST] <JEEB> because of course
[14:14:06 CEST] <RiCON> J_Darnley: i think with future libav merges nasm will be preferred too, iirc
[14:14:15 CEST] <wm4> even JS would have been a saner choice
[14:14:28 CEST] <RiCON> something to do with generating dependencies information(?)
[14:46:18 CEST] <iive> hate boost
[15:34:43 CEST] <BBB> J_Darnley: is there a downside to continuing support for yasm for devs that happen to have that installed?
[15:36:36 CEST] <J_Darnley> I guess not, it just requires more thought to be put into detection
[15:38:31 CEST] <J_Darnley> If you want to keep yasm support please send a reply stating that.
[16:17:48 CEST] <J_Darnley> Ah ha!  I might have cracked my idct problem
[16:18:23 CEST] <J_Darnley> I was setting the new functions for the wrong algorithm selection.
[16:46:49 CEST] <cone-627> ffmpeg 03Vittorio Giovara 07master:c12e8f5f0b41: vf_colorspace: Add a pixdesc API alias name for bt2020nc color space
[17:30:15 CEST] <J_Darnley> What the?  The idct block is supposed to be 16 byte aligned.
[17:31:29 CEST] Action: J_Darnley afk
[18:16:06 CEST] <BtbN> "Run a RTMP server using libavformat" that's a thing?
[18:18:17 CEST] <wm4> let's hope it's not
[18:19:36 CEST] <kierank> of course it is
[18:19:46 CEST] <kierank> because ffmpeg is everyone's toilet of crap
[18:21:21 CEST] <BtbN> you can run ffmpeg standalong as rtmp server? oO
[18:21:36 CEST] <wm4> we don't know yet
[18:21:44 CEST] <JEEB> no, but you can feed rtmp servers with lavf
[18:22:17 CEST] <BtbN> that guy seems to be running lavf as server though
[18:22:41 CEST] <JEEB> :D
[18:24:20 CEST] <cone-627> ffmpeg 03Sasi Inguva 07master:93db5e3fc41a: lavf/mov.c: offset index timestamps by the minimum pts to make first pts zero
[18:24:54 CEST] <wm4> so what's up with those email addresses anyway ("isasi-at-google.com at ffmpeg.org")
[18:25:56 CEST] <DHE> ffserver back from the dead? (joke)
[18:26:07 CEST] <JEEB> wm4: our server has no right to send email as google.com. modern anti-spam validation tech blocks it
[18:27:32 CEST] <BtbN> super stupid bullshit, breaks basic "Reply To" if you want to mail them directly
[18:27:50 CEST] <BtbN> They should introduce some special thing to handle mailing lists and the like
[18:28:12 CEST] <DHE> they did. it was supposed to be DKIM
[18:28:18 CEST] <DHE> but it still kinda sucks
[18:28:39 CEST] <wm4> ffserver isn't dead yet
[18:28:45 CEST] <BtbN> Something like making the mail-server sign the entire mail, and as long as that signature is intact, it can be sent as "from that domain"
[18:29:01 CEST] <BtbN> so re-distributing a valid mail is ok
[18:30:20 CEST] <DHE> BtbN: the intention of DKIM was that the original signature from the original sender could be forwarded by the mailing list and all would be well with the world. (in reality that still doesn't happen)
[20:14:51 CEST] <kierank> atomnuker: https://twitter.com/marcan42/status/873241816434221056
[20:15:22 CEST] <wm4> aw
[20:15:37 CEST] <BtbN> Probably tested ffmpeg 2.8 or something
[20:16:11 CEST] <wm4> yeah I'd hope some sort of misunderstanding/configuration
[20:16:28 CEST] <J_Darnley> Curses.  It looks like people on the ML are not as keen to drop yasm as IRC is.
[20:17:05 CEST] <MrZeus1> Parallelism in C++ using arrays and gcc: https://www.youtube.com/watch?v=Pc8DfEyAxzg
[20:18:06 CEST] <wm4> you should know by now that the ML never agrees to drop anything
[20:18:22 CEST] <J_Darnley> :)
[20:57:17 CEST] <atomnuker> kierank: given audiophile-level explanation like "notes sound less clean", "there's weird fuzziness", etc. I'm not willing to give it any credence
[20:57:56 CEST] <kierank> That guy is very capable
[20:58:02 CEST] <kierank> He reverse engineered the ps4
[20:58:31 CEST] <BtbN> Doesn't seem capable at blind listening tests though
[20:58:34 CEST] <atomnuker> he's also annoying, wrong and refuses to accept new technology on the basis of "I heard rumors/read it on the internet"
[21:00:48 CEST] <wm4> where is he rejecting new technology
[21:11:48 CEST] <iive> atomnuker: there did you see these explanations?
[21:13:15 CEST] <atomnuker> #mpv
[21:31:11 CEST] <iive> i guess there are no public logs of it...
[22:00:58 CEST] <kiroma> Passing -mavx2 flag implies all -msse flags, right?
[22:01:14 CEST] <thebombzen> I'm not sure what he's doing but like the new AAC encoder was a big deal and a nice accomplishment
[22:02:37 CEST] <thebombzen> so the fact that he just tries it and says "nope it definitely sucks" without coming on #ffmpeg and trying to figure out why rather than just blabber on twitter
[22:02:47 CEST] <thebombzen> kind of obnoxious
[22:03:04 CEST] <wm4> he merely pointed out a case where it failed
[22:03:09 CEST] <wm4> and atomnuker reacted aggressively
[22:03:32 CEST] <thebombzen> well rightfully so tbh, that was an obnoxious response "nope, all that testing and hard work, they're just lying"
[22:03:51 CEST] <thebombzen> the people here are pretty keen to admit when something isn't up to standard on something and needs work
[22:04:07 CEST] <thebombzen> "ffmpeg.c is not ideal for realtime streaming, here's a different tool" etc. etc.
[22:05:11 CEST] <kiroma> Who says that?
[22:05:55 CEST] <thebombzen> it's known that ffmpeg.c's buffers aren't highly configurable and it's difficult to get very-low-latency streaming with it. at least it was a few months ago
[22:22:34 CEST] <wm4> IMO latency on demuxing is mostly the fault of libavformat's automagic utils.c stuff
[22:22:42 CEST] <wm4> that tries to probe codec parameters etc.
[22:26:20 CEST] <BtbN> that only adds startup delay, not latency
[22:26:26 CEST] <BtbN> all the buffers everywhere add the latency
[22:31:33 CEST] <BtbN> coverity build failed because this sofa-lib already has a build dir... great.
[22:32:14 CEST] <BtbN> I wonder if the coverity build can be split up, and submited from multiple sources
[22:33:49 CEST] <JEEB> hmm
[22:34:14 CEST] <JEEB> seems like I'm having issues with h264_mediacodec with the latest FFmpeg
[22:34:39 CEST] <durandal_1707> mediacodec? who cares...
[22:34:48 CEST] <wm4> BtbN: well, if you discard all data once started up, it doesn't affect latency I guess
[22:34:58 CEST] <wm4> which is why there's a dumb flag that explicitly discards this data
[22:36:15 CEST] <wm4> durandal_1707: many
[22:37:03 CEST] <JEEB> http://up-cat.net/p/c9c0800b
[22:37:11 CEST] <durandal_1707> wm4: couple at most
[22:37:24 CEST] <JEEB> this file used to work earlier... :/
[22:38:04 CEST] <wm4> seems like it consumes all packets with no output
[22:38:19 CEST] <JEEB> yea, it's all black
[22:38:25 CEST] <JEEB> if I switch to sw decoding it works
[22:38:37 CEST] <JEEB> I'll try to reboot just in case
[22:41:34 CEST] <wm4> I could adjust the mpv fallback to fall back if it feeds more than 32 packets or so with no return
[22:42:24 CEST] <JEEB> ok, same after reboot
[22:42:35 CEST] <JEEB> when was mediacodec switched to the new style?
[22:45:01 CEST] <JEEB> ok, so since my last FFmpeg was from end of Feb pretty much all changes since the march stdatomic thing are new
[22:45:04 CEST] <mateo`> durandal_1707: I do care
[22:45:44 CEST] <durandal_1707> i dont care that somebody care for nonopensource solution
[22:46:30 CEST] <JEEB> well ASICs by their nature are not OSS
[22:46:52 CEST] <JEEB> and unfortunately ARM bullshit devices need hwdec
[22:47:28 CEST] <mateo`> durandal_1707: ok
[22:51:23 CEST] <JEEB> I guess I'll have to test the changes one by one
[22:52:02 CEST] <mateo`> JEEB: is it with a specific sample ?
[22:52:17 CEST] <JEEB> all of my 8bit AVC stuff seems to be affected
[22:53:26 CEST] <JEEB> and the one file with which I was testing hwdec->swdec fallback doesn't fall back
[22:54:35 CEST] Action: JEEB starts with 005da88c1ee231eddd9924ad8173aeeab6366165~1
[22:55:08 CEST] <mateo`> JEEB: let me know if I can help
[22:56:18 CEST] <JEEB> another guy's device seems to have it working with local files but not external URLs
[22:56:27 CEST] <JEEB> so it seems awfully device dependant
[23:00:23 CEST] <JEEB> -_-
[23:00:52 CEST] <wm4> is that maybe avc vs. annexb
[23:01:01 CEST] <wm4> *avcc
[23:02:25 CEST] <mateo`> the decoder inserts the h264_mp4toannexb bitstream filter
[23:02:29 CEST] <JEEB> doesn't seem so
[23:02:37 CEST] <JEEB> @ avcc | annex b
[23:02:52 CEST] <JEEB> also 005da88c1ee231eddd9924ad8173aeeab6366165~1 is also borked it seems so it's either mpv or something else
[23:06:47 CEST] <mateo`> JEEB: what is the issue exactly ? is it about draining the remaining frame ?
[23:07:03 CEST] <JEEB> I open stuff and I only get a black screen
[23:08:00 CEST] <mateo`> What is the output of the decoder ? CPU buffers or a surface ?
[23:08:14 CEST] <mateo`> Can you share the sample you are trying to play ?
[23:08:41 CEST] <JEEB> it happens on all of my samples, let me grab one of them
[23:10:49 CEST] <JEEB> https://kuroko.fushizen.eu/videos/HidamariHoneycombED.mp4
[23:10:51 CEST] <JEEB> one example
[23:14:07 CEST] <JEEB> I did switch NDK, though...
[23:14:24 CEST] <JEEB> let me wipe my prefix and re-build with an older NDK
[23:14:34 CEST] <JEEB> r13b => r15
[23:14:44 CEST] <JEEB> since older versions of FFmpeg/libmpv didn't seem to help
[23:14:57 CEST] <mateo`> i'll test on my end (on a nexus 5x)
[23:26:11 CEST] <JEEB> building older versions with older NDK to make sure
[23:28:10 CEST] <mateo`> It works on my side, ffmpeg master as of a32a6b4201dca46c54247194bd5249dfb7c64874, buffer and surface output works as expected
[23:28:44 CEST] <JEEB> which NDK?
[23:29:08 CEST] <mateo`> i'm using ndk r14b
[23:29:14 CEST] <JEEB> ok
[23:32:49 CEST] <JEEB> mateo`: are you using gcc or clang btw?
[23:33:12 CEST] <mateo`> clang
[23:33:17 CEST] <JEEB> ok, so same as me
[23:35:16 CEST] <J_Darnley> Oh my god!  Does NASM not give a proper warning if you use %9 in an 8 parameter macro?
[23:35:44 CEST] <J_Darnley> oh you POS!
[23:36:10 CEST] <JEEB> mateo`: HAH
[23:36:12 CEST] <JEEB> r13b works
[23:37:47 CEST] <mateo`> I will test with r15 but it will take some time as I'll have to rebuild the whole stack I use at work
[23:38:31 CEST] <jamrial> JEEB, mateo`: speaking of annexb bitstream filter, you could try porting mediacodec to use the new decoder level autobsf feature
[23:39:00 CEST] <jamrial> see 8fb4210ad8 for an example
[23:41:18 CEST] <JEEB> mateo`: r15 for some reason utilizes an SVN build of clang
[23:41:22 CEST] <JEEB> as in, not a release
[23:42:11 CEST] <JEEB> $ ~/ownapps/ndk-toolchain-r15/bin/clang++ --version
[23:42:12 CEST] <JEEB> Android clang version 5.0.300080  (based on LLVM 5.0.300080)
[23:42:27 CEST] <JEEB> trying to play apple I guess?
[23:42:34 CEST] <JEEB> who also seem to use random SVN revisions for their stuff
[23:45:01 CEST] <BtbN> wow, this libmysofa is horribly bad and broken
[23:45:16 CEST] <BtbN> It comes with a pre-populated ./build dir
[23:45:28 CEST] <BtbN> and if you don't "out-of-tree" build in there, the build fails.
[23:46:00 CEST] <mateo`> jamrial: I was thinking porting the code to it but that would prevent the future support of encrypted streams through MediaCrypto (a dev from kodi suggested it). We would need to disable the bitstream filtering according to an option of the hwaccel
[23:48:51 CEST] <wm4> lol
[23:48:58 CEST] <wm4> DRM garbage preventing nice code? check
[23:49:26 CEST] <wm4> whyx doesn't google just get their shit together and define avcc support for mediacodec anyway
[23:49:51 CEST] <wm4> not to mention that d3d11va can do DRM, despite being a hwaccel
[23:56:19 CEST] <mateo`> wm4: I'm personally against the DRM thing, but on the other hand I don't want to restrict users by me personal choice
[23:59:04 CEST] <wm4> I can understand that, but in this case there's surely something severely wrong
[23:59:34 CEST] <wm4> such as for example what the heck would the mediacodec wrapper code do anyway if the packet data is somehow encrypted enough that annexb repacking doesn't work
[00:00:00 CEST] --- Sat Jun 10 2017