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

[burek]

[00:26:14 CET] <llogan> excellent. more users asking *-owner for help.
[01:02:18 CET] <cone-566> ffmpeg 03Rostislav Pehlivanov 07master:ac5a4deb3dd0: MAINTAINERS: add my name to the parts I'm maintaining
[01:19:34 CET] <JEEB> was anyone working on a mediacodec hwaccel/avcodec lately?
[01:42:21 CET] <michaelni> durandal_1707, "avfilter/dualinput: use pts provided by framesync" breaks fate-sub2video
[01:44:38 CET] <michaelni> durandal_17:  http://fate.ffmpeg.org/report.cgi?time=20160209134651&slot=x86_32-debian-kfreebsd-gcc-4.4-cpuflags-sse42
[01:56:26 CET] <michaelni> durandal_17, i guess it just needs a update to the reference
[02:12:56 CET] <cone-566> ffmpeg 03Michael Niedermayer 07master:8836b8c2a430: fate: Update fate-sub2video for 5486d7fa91f7233e6d9aa9ba8de7fe9287402637
[02:32:07 CET] <cone-566> ffmpeg 03Michael Niedermayer 07master:ac3a275d1e0d: avfilter/vf_nnedi: Simplify away some trivial mem*()
[07:15:48 CET] <tmm1> ubitux: finally got around to implementing charsets in the ccaption decoder
[10:35:50 CET] <wm4> av_assert0(av_buffer_get_ref_count(sl->ref_list[list][index].parent->f->buf[0]) > 0);
[10:35:52 CET] <wm4> wtf
[10:36:08 CET] <wm4> (this crashes for me... but possibly not as assert, but as segfault)
[10:38:39 CET] <nevcairiel> buf[0] is NULL?
[10:38:54 CET] <nevcairiel> one shall not forget to set the buf
[10:39:06 CET] <wm4> it happens when videotoolbox returns an error
[10:39:21 CET] <wm4> it plays weird tricks with buf, so maybe that's the cause
[10:39:31 CET] <wm4> I've looked at it before and concluded it's fucked
[10:40:36 CET] <nevcairiel> why would it do such things
[10:40:58 CET] <nevcairiel> let me guess, its because of this async crap?
[10:41:21 CET] <wm4> no
[10:41:30 CET] <wm4> because videotoolbox allocates a surface
[10:41:37 CET] <wm4> instead of the API user/get_buffer
[10:42:03 CET] <wm4> it sets a dummy buffer in ff_videotoolbox_alloc_frame
[10:42:17 CET] <wm4> and the proper one in ff_videotoolbox_buffer_create
[10:42:36 CET] <nevcairiel> sounds evil
[10:42:37 CET] <wm4> maybe it shouldn't free the dummy buffer on error and leave buf NULL
[10:42:49 CET] <wm4> I think videotoolbox shouldn't be a hwaccel at all
[10:48:09 CET] <wm4> maybe it was caused by 9747219958060d8c4f697df62e7f172c2a77e6c7, my previous attempt to deal with this crap
[10:49:15 CET] <nevcairiel> personally I would oppose any further h264*.c  hacks to  make it not crash on these hacky buffers
[10:49:31 CET] <jkqxz> What if you change _alloc_frame to make buf[0] be empty but sized for sizeof(vtctx->frame), then just copy the right thing into place in _buffer_create?
[10:49:52 CET] <nevcairiel> changing the buffer around later is high grade evil
[10:50:19 CET] <wm4> nevcairiel: is the crashing code correct in the first place?
[10:50:28 CET] <nevcairiel> sure
[10:50:51 CET] <nevcairiel> why wouldnt it be
[10:50:59 CET] <wm4> jkqxz: leaving the buf set on error will make it think the frame was decoded correctly, and return it to the user
[10:52:59 CET] <jkqxz> What error is going to cause trouble here?
[10:54:03 CET] <wm4> if hwaccel->end_frame returns failure
[10:54:25 CET] <nevcairiel> end_frame failure should result in the decoder bailing out, shouldnt it
[10:54:44 CET] <wm4> well it crashes the next time it enters the decoder
[10:54:56 CET] <nevcairiel> although due to re-ordering it will probably still have said broken frame somewhere in the DPB
[10:55:09 CET] <nevcairiel> this is why we have a central alloc function
[10:55:18 CET] <nevcairiel> that one can return a failure, and then the frame is not touched again
[10:55:26 CET] <nevcairiel> why vt doesnt use that is not something i want to understand
[10:55:40 CET] <nevcairiel> ie. i consider it broken by design and will never use it
[10:55:43 CET] <wm4> it does use it?
[10:55:53 CET] <nevcairiel> but not for the actual frame allocation
[10:55:54 CET] <wm4> it just returns a dummy
[10:55:57 CET] <nevcairiel> just forsome dummy that never fails
[10:56:15 CET] <nevcairiel> the actual allocation fails much much later, when avcodec assumes your frame is already allocated and all is fine
[10:56:54 CET] <nevcairiel> ie broken by design =p
[10:58:34 CET] <wm4> wtf the frame is returned by a callback
[10:58:41 CET] <wm4> even though it's asynchronous
[10:58:43 CET] <wm4> err
[10:58:45 CET] <wm4> even though it's synchronous
[10:58:52 CET] <jkqxz> Right, the actual allocation happens in end_frame from the asynchronous callback you're waiting for iff decoding succeeds.  So if you get an error there you're just screwed.
[10:59:19 CET] <wm4> indeed
[10:59:47 CET] <nevcairiel> interestingly our mac users have not yet really asked for hwaccel decoding, so i'm staying away from that subject
[10:59:54 CET] <jkqxz> end_frame could always make an empty frame to stop it crashing?
[11:00:17 CET] <nevcairiel> there is no 100% guarantee you can allocate an empty frame if other things failed
[11:00:19 CET] <wm4> jkqxz: an empty frame is invalid
[11:00:20 CET] <jkqxz> On error, that is.  (Also that needs to not be able to fail.)
[11:00:31 CET] <wm4> nevcairiel: you could preallocate it
[11:00:45 CET] <wm4> jkqxz: unless you mean a real frame... but you don't know the format
[11:01:01 CET] <jkqxz> What do you mean by "invalid"?  I was meaning a real frame with (possibly with zeroes in it).
[11:01:18 CET] <wm4> anyway, I feel like this should be a real decoder, not a hwaccel; I'm just not sure how to use it
[11:01:41 CET] <nevcairiel> definitely sounds like it doesnt really fit the hwaccel model
[11:02:09 CET] <wm4> nevcairiel: yet it can deal with slice input...
[11:02:27 CET] <nevcairiel> the real question is if it can also deal with full bitstream input without a lot of user magic
[11:02:39 CET] <nevcairiel> if yes then making it a decoder would probably be easy
[11:02:41 CET] <nevcairiel> if no, good luck
[11:02:55 CET] <BtbN> doesn't the hwaccel for vt reconstruct the full bitstream? I remember some crazy hack like that somewhere.
[11:03:28 CET] <wm4> it concatenates the data it gets from decode_slice
[11:03:47 CET] <nevcairiel> well most hwaccels do that really in some form or another
[11:13:13 CET] <jkqxz> Given that it takes NAL units rather than bytestream, what even happens if you only give it (slices forming) half a frame?
[11:14:07 CET] <wm4> it's quite eager to return decoding errors instead of frames on broken streams
[11:14:46 CET] <jkqxz> (I assume it can't return an error from the first submission, because that would entail reading the entire bitstream and defeats the point of asynchronicity, and it can't give you a callback yet because you might be giving it more NAL units later.)
[11:15:17 CET] <wm4> not sure how it works in the async case
[11:16:02 CET] <wm4> seems it's more like input is synchronous, while output is asynchronous
[11:16:50 CET] <mateo`> Hello guys, speaking of hw accel api, i'm still working on the mediacodec stuff; got something working for h264 and android >= 4 (in "production" at work). I still need to clean a lot of stuff related to jni~ mostly. I decided to support android 4 as there are still too many of that kind of devices in the wild, meaning there are jni crap involved (even if I've only supported android 5 and using the C
[11:16:52 CET] <mateo`> api, it would have involved some jni stuff as the C api lacks some features like having access to the decoder name which is mandatory to work around crappy implementations).
[11:17:22 CET] <wm4> heh, it's probably unavoidable
[11:21:43 CET] <jkqxz> ((H.264 slices would have been much more helpful for weird hardware cases if the header also included last_mb_in_slice or similar.  I've been annoyed by this in the past.))
[13:10:47 CET] <atomnuker> j-b: did you know that installing a single KDE application (e.g. Kate) on debian without any KDE stuff will also install VLC
[13:11:46 CET] <atomnuker> it's also mandatory so no amount of --no-install-recommends will save you from having VLC if you just wanted a nice text editor
[13:12:25 CET] <atomnuker> VLC is truly everywhere now
[13:12:51 CET] <nevcairiel> i would probably go troll debian about their silly dependency setup
[13:13:02 CET] <durandal21707> does VLC supports utvideo?
[13:15:19 CET] <atomnuker> nevcairiel: blame the KDE Phonon guys who insist on having libVLC as the "best" backend
[13:15:23 CET] <atomnuker> and all they ever do with it
[13:15:29 CET] <atomnuker> is play wav files
[13:15:35 CET] <nevcairiel> phonon is such a crapshow
[13:15:43 CET] <nevcairiel> its like gstreamer for kde
[13:15:43 CET] <nevcairiel> =p
[13:16:11 CET] <atomnuker> gstreamer is at least a more okayish dependency because many music players (e.g. quodlibet) depend on it
[13:16:49 CET] <atomnuker> but still phonon could basically be rewritten in 1 line: "paplay <file>"
[13:17:16 CET] <wm4> so --enable-memalign-hack is cargo-culting these days?
[13:17:38 CET] <nevcairiel> yes
[13:17:46 CET] <nevcairiel> configure should auto-enable it when needed
[13:17:50 CET] <nevcairiel> when it doesnt, file a bug
[13:18:11 CET] <wm4> not aware of such a situation (unless it can happen on windows)
[13:20:16 CET] <nevcairiel> the OS provided functions probably just do something similar to the hack
[13:20:22 CET] <nevcairiel> at least the mingw emulation of them does
[13:20:47 CET] <nevcairiel> didnt bother to look into MS libc
[13:29:17 CET] <J_Darnley> atomnuker: I would love to see how that dependancy chain works kate->???->vlc
[13:30:16 CET] <atomnuker> ??? = KDE libs
[13:30:34 CET] <wm4> kde depends on stuff just for the heck of it
[13:30:46 CET] <wm4> there's even some code that makes _all_ kde apps exit if there's no dbus running
[13:30:53 CET] <wm4> (comment it and you can run most stuff without dbus)
[13:32:03 CET] <atomnuker> Daemon404: output.flac - 49576; output.wv - 49292; highest compression level for both
[13:32:06 CET] <atomnuker> pretty decent
[13:34:37 CET] <atomnuker> though I still one day plan to write a lossless codec with so much prediction, vector quantization system and real entropy encoding
[13:35:00 CET] <atomnuker> just need to find <alien technology> to use to encode the per coefficient errors
[13:41:23 CET] <nevcairiel> if its as fast as the flac alien algorithm mode, then good luck =p
[13:42:09 CET] <atomnuker> the flac alien mode did result in worse compression actually
[13:42:41 CET] <nevcairiel> did you borrow a supercomputer or how did you find out? :)
[13:42:58 CET] <atomnuker> I let it run overnight to encode a 1 second file
[13:43:13 CET] <atomnuker> was disappointing to see it being like 60ish bytes larger
[13:43:51 CET] <nevcairiel> and people say vp9 is slow
[13:44:27 CET] <atomnuker> it really is slow, but they've mislabed the quality setting
[13:44:32 CET] <atomnuker> normal = normal but fast
[13:44:43 CET] <atomnuker> good = SUPER PLACEBO ULTRA SLOW MODE
[13:45:49 CET] <atomnuker> that's probably how they earn their ultra high PSNR score (but probably at the cost of visual quality)
[13:45:53 CET] <nevcairiel> its "good" and "best", but yes
[13:46:08 CET] <nevcairiel> everyone including the devs will generally recommend against using best
[13:46:35 CET] <nevcairiel> in other news, Microsoft made the format of their pdb debug information open source on GitHub
[13:46:43 CET] <nevcairiel> hopefully more tool support now
[13:50:04 CET] <wm4> nevcairiel: wasn't that a while ago
[13:50:55 CET] <nevcairiel> they started in october or something, but only recently did they push a whole lot of the missing info
[13:52:17 CET] <nevcairiel> would be awesome if clang and/or gcc could eventually generate pdb compatible debug info
[13:52:39 CET] <wm4> they did this for clang, didn't they
[13:52:43 CET] <nevcairiel> yes
[13:52:53 CET] <nevcairiel> so clang will likely be the first
[13:53:27 CET] <wm4> as long as the clang dev working on this doesn't kill himself (must be some quite terrible fiddling...)
[13:54:01 CET] <nevcairiel> microsoft seems to be quite willing to help, so its probably not too bad
[13:54:13 CET] <nevcairiel> getting rid of mingw would be a day to celebrate
[13:54:30 CET] <wm4> indeed
[13:55:26 CET] <nevcairiel> that reminds me that I wanted to investigate why msvc builds crash in hevc sometimes
[13:55:33 CET] <nevcairiel> oddly enough not on any fate samples
[14:14:23 CET] <wm4> wow, if you seek to the start of an avi file, the first packet timestamp you get is different from when you start an avi file without seek?
[14:14:26 CET] <wm4> how does this work
[14:17:25 CET] <nevcairiel> magic
[14:17:39 CET] <nevcairiel> avi has no timestamps, so possibly a bug
[14:17:57 CET] <wm4> it's an avi with h264 and b-frames
[14:18:04 CET] <wm4> so lots of crap could happen
[14:18:28 CET] <wm4> and why can't ffprobe seek
[14:20:29 CET] <wm4> actually it can
[14:20:58 CET] <wm4> and it confirms my findings
[14:21:14 CET] <wm4> a seek offsets it by 2 frames
[14:21:24 CET] <wm4> with is also the b-frame delay in this file
[14:22:11 CET] <wm4> encoder=MEncoder SVN-r23784
[14:26:28 CET] <wm4>  /* XXX: How to handle B-frames in AVI? */
[14:26:29 CET] <wm4> hmmm
[14:28:16 CET] <Daemon404> atomnuker, there are closed source lossless audio codecs which compress better than either
[14:28:25 CET] <Daemon404> nobody uses/re'd them really though
[14:31:03 CET] <Compn> wm4 : h264 in avi is invalid
[14:31:13 CET] <Compn> double invalid when made with mencoder...
[14:31:17 CET] <BBB> atomnuker: omg I cant believe you tried that
[14:32:03 CET] <Compn> wm4 : it only plays back correctly (e.g. b-frames are in correct order) because of ffmpeg magic.
[14:32:23 CET] <Compn> some hardware decoders will play it out of order and it jerks back and forth
[14:32:28 CET] <wm4> Compn: doens't matter, thanks to ffmpeg eating this crap (and doing it incorrectly), I'll have to deal with it anyway
[14:32:54 CET] <Compn> if h264 in avi > ret error "you suck"
[14:32:56 CET] <Compn> ehe
[14:33:25 CET] <Daemon404> there;s quite a bit of h264 in avi in the wild
[14:33:45 CET] <Daemon404> during the xvid->x264 transition, there was a very large following of x264's vfw codec
[14:33:56 CET] <Daemon404> i think it was even in x264's git at one point
[14:34:09 CET] <Compn> nothing wrong with a vfw x264 encoder
[14:34:28 CET] <Compn> mkv muxer can be added to dshow/vfw chain 
[14:34:32 CET] <Daemon404> "hitler did nothing wrong" - Compn, 2016
[14:35:00 CET] <Daemon404> [13:34] <@Compn> mkv muxer can be added to dshow/vfw chain <-- not vfw
[14:35:05 CET] <Daemon404> unless you cound the vfw compat in mkv
[14:35:11 CET] <Daemon404> which is basically an avi muxed into mkv
[14:35:17 CET] <Daemon404> count*
[14:35:39 CET] <wm4> the funniest thing is that vc-1 in mkv can be muxed only using vfw compat (i.e. it behaves like in avi)
[14:35:44 CET] <wm4> even though vc-1 has b-frames
[14:35:59 CET] <Compn> since x264 vfw is non standard, i'm counting ffdshow mkv output or modified vdub or other tool ,even avisynth or graphedit or mencoder
[14:36:01 CET] <Daemon404> i was pretty sure mkvtoolnix had a way to mux normal vc1
[14:36:03 CET] <Daemon404> from an elementary stream
[14:36:48 CET] <Daemon404> Compn, iirc modified vdub also output mkv with the vfw compat layer, graphedit doesnt do vfw, avisynth doesnt output anything directly, and ive never heard offdshow outputting directly
[14:37:02 CET] <wm4> well neither ffmpeg's nor mpv's demuxer have such vc-1 support
[14:37:21 CET] <Daemon404> wm4, chicken/egg im sure
[14:37:37 CET] <Daemon404> more like chicken corpse / smashed egg
[14:37:42 CET] <Daemon404> because vc1.
[14:39:25 CET] <Compn> graphedit does vfw, wtf are you on about ?
[14:39:32 CET] Action: Compn afk
[14:40:53 CET] <Daemon404> Compn, by way of dshow wrapper
[14:41:19 CET] <Daemon404> the vfw codec should still output the same (packed) packets
[14:42:22 CET] <Daemon404> (and im not even sure if that still exists in modern windows versions)
[14:47:47 CET] <rcombs> heh, AVERROR_GOFUCKYOURSELF
[14:48:58 CET] <Daemon404> if we wanted to screw with people we could have AVERROR_PATENTSREQUIRED
[14:49:35 CET] <Daemon404> based on timezone, like vlc did
[14:49:36 CET] Action: Daemon404 runs
[14:54:41 CET] <Daemon404> ... hevc hls?
[14:57:05 CET] <wm4> hm I declare avidec.c indecipherable, I guess I'll just tell the users to fuck off
[14:58:27 CET] <Daemon404> with those exact works? you're a nice guy, man.
[14:59:05 CET] <wm4> "exact works" wat
[14:59:52 CET] <Daemon404> words
[15:00:12 CET] <Daemon404> you need to work on your ESP
[15:11:27 CET] <durandal21707> Daemon404: going to REd MagicYUV?
[15:17:23 CET] <endle> Excuse me, I'm reading ffmpeg's code now, and faced a problem
[15:17:29 CET] <endle> The coverage page(http://coverage.ffmpeg.org/) shows that libswscale got 54.7% coverage, but I can't find the test code for it
[15:17:53 CET] <endle> So where is the test code for libswscale? The code in libswscale are tested indirectly?
[15:19:37 CET] <nevcairiel> swscale is tested indirectly through various other format conversion tests
[15:19:51 CET] <Daemon404> i thought there was some filter tests that used it
[15:19:54 CET] <Daemon404> kinda directly
[15:20:05 CET] <nevcairiel> i suppose
[15:20:10 CET] <nevcairiel> but those are through avfilter then
[15:20:14 CET] <nevcairiel> not explicit swscale tests as such
[15:20:37 CET] <endle> Thanks
[15:21:03 CET] <durandal21707> michaelni: when is new release planned? who can make new releases?
[15:24:16 CET] <endle> If I want to send my first patch to ffmpeg, is there any suggestion?
[15:24:33 CET] <durandal21707> there is docs to read written just for you
[15:24:57 CET] <endle> Let me have a check?
[15:25:05 CET] <durandal21707> http://ffmpeg.org/developer.html#toc-Contributing
[15:26:00 CET] <Daemon404> round v8 of mats replying to himself...
[15:26:03 CET] <Daemon404> holy crap.
[15:27:18 CET] <nevcairiel> he must never be bored, always someone to talk to 
[15:29:58 CET] <endle> I'm fixing a compile error in libswscale, and I'm afraid that I might break something without without direct test suite
[15:30:46 CET] <durandal21707> well post patch
[15:31:37 CET] <endle> not finished yet... Can I just send my patch to mail list, and claiming "Draft" in the title?
[15:32:03 CET] <Daemon404> what are you fixing?
[15:33:16 CET] <endle> libswscale/slice.c:178 and 184
[15:33:35 CET] <Daemon404> in english
[15:33:36 CET] <endle> there is a cast from const pointer to non-const pointer
[15:33:38 CET] <Daemon404> oh
[15:34:25 CET] <Daemon404> i dont see any cats on those lines in HEAD
[15:34:29 CET] <Daemon404> casts even
[15:34:36 CET] <Daemon404> https://github.com/FFmpeg/FFmpeg/blob/master/libswscale/slice.c#L178
[15:35:06 CET] <endle> const uint8_t *src_[4]
[15:35:27 CET] <Daemon404> implicit conversion then
[15:35:33 CET] <endle> and s->plane[i].line is  uint8_t *
[15:35:49 CET] <endle> Yeah. That's why the compiler throws a warning
[15:37:07 CET] <Daemon404> unrelated to your patch...
[15:37:08 CET] <Daemon404> https://github.com/FFmpeg/FFmpeg/blob/master/libswscale/slice.c#L161
[15:37:13 CET] <Daemon404> why are these all stride[0]
[15:37:29 CET] <Daemon404> that doesnt seem right at all, or just too 'clever' for me to get
[15:40:22 CET] <durandal21707> Daemon404: looks like bug to me
[15:40:22 CET] <Daemon404> the commit that added that seems to have never been reviewed on the ML either
[15:40:27 CET] <wm4> later in the code: src_[i] + j * stride[i];
[15:40:32 CET] <Daemon404> yeah
[15:40:35 CET] <Daemon404> it just seems wrong
[15:40:39 CET] <wm4> so whatever it does
[15:40:41 CET] <Daemon404> how could that ever work for subsampled chroma...?
[15:41:16 CET] <wm4> also, what if there are less than 4 planes
[15:41:19 CET] <Daemon404> https://github.com/FFmpeg/FFmpeg/commit/5bd62a1b3c3356b84818efca3fcaf52da27a32af
[15:41:22 CET] <Daemon404> the commit in question
[15:41:42 CET] <wm4> nice commit message
[15:42:55 CET] <durandal21707> you can make your own conlusions what it does :)
[15:43:18 CET] <Daemon404> michaelni, your knowledge is welcome here
[15:43:25 CET] <Daemon404> you probably know swscale best, but it looks liek a bug.
[15:50:07 CET] <endle> Thank you. Seems that libswscale is a little tricky for me to send my first patch
[15:51:45 CET] <endle> Leaving for bed now. Bye
[15:54:52 CET] <nevcairiel> Daemon404: slice-based scaling is practically unused and untested
[15:55:24 CET] <Daemon404> i heard mplayer uses it
[16:03:27 CET] <wm4> oh, that API
[16:03:44 CET] <wm4> mplayer actually rarely uses the slice path (which it has spread all over its video chain)
[16:03:53 CET] <wm4> because it doesn't work with modern things like h264 or threading
[16:09:15 CET] <Daemon404> lol really?
[16:09:39 CET] <Daemon404> or do you mean "work" like with sliced output
[16:09:44 CET] <Daemon404> in draw_horiz_band
[16:10:16 CET] <wm4> well in mplayer2 times I desperately tried to make it use the slice path (to test it), and couldn't trigger it
[16:10:25 CET] <wm4> but yes, it works with draw_horiz_band
[16:10:38 CET] <wm4> the idea is that decoding, filtering, and rendering works via slices
[16:10:42 CET] <wm4> which should be more efficient
[16:10:54 CET] <Daemon404> thats why utvideo uses slices
[16:11:03 CET] <Daemon404> of course we used frame threading, eliminating its usecase
[16:11:20 CET] <Daemon404> (i added sliced threads to ours once, and it was rejected due to being slower to decode linearly than frame threads)
[16:11:46 CET] <Daemon404> (for NLE latency / seeking)
[16:14:56 CET] <BBB> no response to my vp9/hwaccel/threading patch?
[16:14:59 CET] <BBB> so sad
[16:15:18 CET] <wm4> "it's awesome push it"
[16:15:27 CET] <wm4> (there was a patch?)
[16:16:19 CET] <BBB> ...
[16:16:35 CET] <wm4> must have missed it
[16:16:36 CET] <Daemon404> was it hidden in a giant thread
[16:16:52 CET] <BBB> yes
[16:17:01 CET] <Daemon404> thats why nobody commented
[16:17:29 CET] <wm4> and I still can't find it
[16:17:54 CET] <durandal21707> Daemon404: you added slice threads decoding to native utvideo?
[16:18:08 CET] <Daemon404> at one point
[16:18:14 CET] <Daemon404> the patch has since long been lost
[16:18:18 CET] <Daemon404> it wasnt very hard to add
[16:18:42 CET] <wm4> BBB: maybe resend it, and as a new thread
[16:18:50 CET] <durandal21707> Daemon404: where it is?
[16:19:08 CET] <Daemon404> i don't know, i don't keep track of patches i threw away 2 years ago
[16:19:25 CET] <Daemon404> im not sure if it even made it to the ML; just irc
[16:22:29 CET] <durandal21707> :(
[16:31:51 CET] <j-b> atomnuker: yes.
[16:33:20 CET] <JEEB> I might have the ut video slices patch... maybe. if my older laptop doesn't die when I touch it
[16:34:54 CET] <cone-967> ffmpeg 03Tobias Rapp 07master:8b99c5e8daf2: avfilter/f_metadata: avoid float rounding problems
[16:34:55 CET] <cone-967> ffmpeg 03Tobias Rapp 07master:202f97872891: avfilter/f_metadata: add support for file output
[16:34:56 CET] <cone-967> ffmpeg 03Tobias Rapp 07master:6889deba68fc: avfilter/f_metadata: add starts_with string function
[16:34:57 CET] <cone-967> ffmpeg 03Tobias Rapp 07master:730da5c20791: avfilter/f_metadata: whitespace clean-up
[16:34:58 CET] <cone-967> ffmpeg 03Tobias Rapp 07master:80026a8ac35b: avfilter/f_metadata: rename "string" into "same_str"
[16:34:59 CET] <cone-967> ffmpeg 03Paul B Mahol 07master:855d9d29ebf1: doc/filters: fix metadata example
[16:39:28 CET] <durandal21707> anybody against loop filter, you would be able to set when to start looping and for how much?
[16:40:32 CET] <wm4> seems like a kind of bad idea with the implied buffering, but it's not like anyone is going to be against it completely
[16:43:36 CET] <durandal21707> default value would be some smallish number of frames to cache
[16:44:05 CET] <wm4> doesn't it have to cache the loop duration?
[16:45:02 CET] <durandal21707> no, frames received during looping are dropped
[16:45:35 CET] <wm4> I mean the duration of the looped fragment
[16:46:06 CET] <durandal21707> yes, that is cached
[17:02:25 CET] <durandal21707> https://video.fosdem.org/2016/h2214/ :(
[17:03:02 CET] <nevcairiel> why is fosdem so incompetent with video
[17:03:47 CET] <Daemon404> nevcairiel, like i said before, theyre only giving us the FOSS UX
[17:03:50 CET] <J_Darnley> Because video is not very free what with them patent things and all
[17:04:11 CET] <Daemon404> they seem to have a single rpi transcoding everything
[17:04:17 CET] <Daemon404> i have no other way to explain
[17:04:18 CET] <JEEB> lol
[17:04:24 CET] <J_Darnley> hue
[17:04:26 CET] <JEEB> yeah, it does feel like that
[17:04:36 CET] <J_Darnley> I'll loan them mine
[17:04:41 CET] <J_Darnley> Twice the speed!
[17:21:47 CET] <kierank> durandal21707: they've lost a lot of the video
[17:21:49 CET] <kierank> that's why
[17:22:00 CET] <JEEB> wow
[17:22:32 CET] <Daemon404> kierank, ... how
[17:22:41 CET] <wm4> maybe they deleted it out of embarrassment?
[17:22:43 CET] <Daemon404> record to harddrive -> ??? -> profit
[17:25:11 CET] <J_Darnley> Perhaps their wooden boxes burst into flames.
[18:16:01 CET] <michaelni> durandal21707, release is planned ASAP, well i wanted to make it a week ago but too much random stuff kept me from workig on it
[18:18:10 CET] <michaelni> and anyone who has an account on the server really can make a release i think, shouldnt need any special permissions
[18:24:22 CET] <JEEB> mateo`: is your mediacodec stuff a decoder or hwaccel? (i think it supported both buffer and surface outputs)
[18:26:08 CET] <mateo`> JEEB: it is both
[18:26:19 CET] <JEEB> ok
[18:27:02 CET] <JEEB> mediacodec is kind of interesting since we got libmpv to work with NDK this week
[18:27:19 CET] <JEEB> so a nice opengl es video renderer
[18:27:53 CET] <rcombs> the C API for it?
[18:28:02 CET] <rcombs> mateo`: what did you do about the thread pool thing?
[18:29:19 CET] <mateo`> rcombs: what are you refering to ?
[18:29:50 CET] <mateo`> rcombs: i'm not using the C api in the end, i've done something kind of ~nasty
[18:30:06 CET] <mateo`> i took the C api, and implemented it in FFmpeg with a jni backend
[18:30:14 CET] <rcombs> yuck
[18:30:22 CET] <mateo`> so it will be easiest to port to the C APi later on
[18:30:31 CET] <mateo`> and it will work with all the android 4 devices
[18:30:37 CET] <mateo`> yeah i know ...
[18:30:57 CET] <rcombs> tl;dr android doesn't like that whole IPC model to work until the process has some thread pool running
[18:31:15 CET] <rcombs> so unless you're using JNI (which you are, but later&) you need to do something to start it
[18:31:24 CET] <rcombs> and apparently that thing is "call a private C++ API"
[18:31:47 CET] <rcombs> someone should yell at the android guys about making that public and available to C
[18:31:54 CET] <rcombs> or just doing it automatically
[18:32:04 CET] <rcombs> if you try to use the IPC while it's not already running
[18:33:47 CET] <mateo`> i did nothing about that ... i'm using all this stuff in the context of an application
[18:33:56 CET] <mateo`> i was not even aware about this limitation
[18:34:25 CET] <rcombs> yeah, the application already has it running; it comes from zygote
[18:34:51 CET] <rcombs> but if you tried to execve (e.g. running ffmpeg.c) you'd need it
[18:38:31 CET] <mateo`> What makes me decide to go with the jni stuff is that there is no API to access to codec name, and you still need it. In the first place I thought the MediaCodec implementations would have been improved with Android 5 but it's exactly the same thing when it output software buffers.
[18:38:41 CET] <mateo`> OMX.SEC.avc.dec still lie about its stride
[18:38:53 CET] <mateo`> and so forth...
[18:39:56 CET] <mateo`> if you are interested I can put my work somewhere before sending the patch to the ml, so you can try it and flame me :)
[18:46:46 CET] <JEEB> nice
[18:47:13 CET] <JEEB> also lol at the JNI stuff not having access to codec name
[18:55:20 CET] <mateo`> btw, awesome to hear that libmpv is running on the ndk :)
[19:00:26 CET] <JEEB> started off as a joke and then before you knew it opengl-cb and openal worked :)
[19:02:47 CET] <mateo`> rcombs: hello
[19:02:53 CET] <mateo`> oops
[20:52:31 CET] <furkan> in udp.c, could anybody explain the relationship between the buffer_size variable used to set SO_RECVBUF (UDP socket receive buffer), and the circular ("fifo"?) buffer?
[20:53:09 CET] <Mavrik> One is an actual socket buffer you communicate to the OS.
[20:53:21 CET] <Mavrik> It's where packets wait for the code in udp.c to read them an transfer them to the FIFO buffer.
[20:53:34 CET] <furkan> Mavrik: ah i see
[20:53:49 CET] <furkan> my kernel is dropping UDP packets so i'm trying to figure out how to increase the buffer size
[20:54:19 CET] <furkan> netstat -s is reporting RcvBufErrors
[20:54:30 CET] <Mavrik> that would be SO_RECVBUF then
[20:55:09 CET] <furkan> it looks like i can set that with buffer_size
[20:55:42 CET] <furkan> i think something like av_dict_set(&d, "buffer_size", x, 0);
[20:55:54 CET] <furkan> trying to find out what kind of structure "x" is supposed to be
[20:56:13 CET] <Mavrik> C string.
[20:56:20 CET] <Mavrik> There's also av_dict_set_int.
[20:56:37 CET] <furkan> great i'll give that a shot thanks
[20:57:44 CET] <furkan> so is the circular buffer used for reordering RTP packets that are received out of order or something?
[20:57:53 CET] <furkan> just trying to understand why the need for a second buffer
[21:00:19 CET] <furkan> beautiful, increasing the buffer_size to 10M appears to have fixed my problem
[21:03:54 CET] <nevcairiel> Daemon404: i dont suppose you know if clang/c2 is any smarter with stack alignment than gcc is? right now if I build a gcc build with -msse2 and call it from msvc it will just crash due to missing alignment, but building with -mstackrealign or -mincoming-stack-boundary=2 blows up in inline asm =p
[21:04:18 CET] <kierank> furkan: the second buffer is a hack
[21:04:21 CET] <nevcairiel> What I would really like would be an option to only apply the realignment to all publicly exported functions, but the compielr doesnt know which those are...
[21:04:38 CET] <kierank> furkan: because otherwise ffmpeg receives udp packets in the same thread as everything else
[21:04:46 CET] <J_Darnley> nevcairiel: there's a function attribute for that
[21:04:51 CET] <kierank> it's not an application designed for streaming (like say vlc)
[21:04:56 CET] <nevcairiel> J_Darnley: sure, but you want to flag every single public function?
[21:05:13 CET] <furkan> kierank: ah interesting, i noticed that the circular buffer was only enabled if PTHREADS was enabled
[21:05:19 CET] <J_Darnley> ah
[21:05:21 CET] <nevcairiel> with -msse2 and auto vectorization it starts to use sse2 in all sorts of places
[21:05:36 CET] <nevcairiel> kierank: that thread and buffer works quite nicely though
[21:06:04 CET] <kierank> still a hack, best way to do it is with nonblocking io
[21:06:07 CET] <J_Darnley> Wait.  Don't we already mark public API with something?
[21:06:10 CET] <kierank> and a separate thread
[21:06:20 CET] <J_Darnley> I know I've seen around, at least in other projects
[21:06:25 CET] <nevcairiel> J_Darnley: we dont
[21:06:58 CET] <wm4> I thought every public API function is marked for exactly this reason (stack alignment)
[21:07:17 CET] <wm4> attribute_align_arg
[21:07:17 CET] <nevcairiel> the stack alignment attribute is only on a few of them which call into yasm code
[21:07:25 CET] <nevcairiel> it doesnt account for auto-vectorization by the compiler
[21:09:14 CET] <J_Darnley> Perhaps we need to disable it on Windows until it gets "fixed"
[21:09:38 CET] <nevcairiel> it was an issue beofre the recent flag change already
[21:09:45 CET] <nevcairiel> i personally just never build with -msse2
[21:10:01 CET] <nevcairiel> never been an issue with -mmmx -msse
[21:10:25 CET] <J_Darnley> Well if it does it more often now then that just increases the need.
[21:10:43 CET] <nevcairiel> it crashed before, still crashes now, nothing changed =P
[21:11:06 CET] <nevcairiel> but i'm not sure everyone would be happy littering every single  entry point with such an attribute
[21:11:40 CET] <nevcairiel> its kinda sad the MS compiler never learned to produce 16 byte aligned stack, i'm not quite sure why not
[21:11:44 CET] <J_Darnley> Propose new function attribute: AV_RETARDED_MSVC_STACK
[21:12:00 CET] <nevcairiel> thats what attribute_align_arg already means :p
[21:12:08 CET] <J_Darnley> The answeris probably "backwards compatability"
[21:12:17 CET] <nevcairiel> well make it an option then!
[21:12:35 CET] <J_Darnley> It probably is.
[21:12:47 CET] <nevcairiel> i'm not aware of one
[21:12:48 CET] <J_Darnley> But that only controls code it generates
[21:12:55 CET] <nevcairiel> or I would just build with it and voila
[21:13:25 CET] <J_Darnley> I guess we're going round in circles so I'll be quiet.
[21:16:45 CET] <nevcairiel> in any case, the only really "complete" solution would be to add such an attribute to every public function that has more than 3 lines of code =p
[21:19:00 CET] <wm4> or littering everything with dllexport attributes?
[21:19:53 CET] <jkqxz> Flagging every public function with something is probably a good idea anyway for audit purposes (ignoring the effort of actually doing it).
[21:20:21 CET] <wm4> public functions are already easily recognizable
[21:20:26 CET] <wm4> they all have the av_ prefix
[21:28:38 CET] <nevcairiel> anyway, hence wondering if maybe clang doesn't just blindly assume that the stack is aligned for its purposes
[21:28:59 CET] <Daemon404> nevcairiel, i have no idea re: clang alignment
[21:29:49 CET] <Daemon404> i think it's a pretty damn bad bug if so though
[21:29:52 CET] <Daemon404> re: gcc
[21:30:04 CET] <nevcairiel> its a couple year old issue on their bugzilla
[21:30:08 CET] <nevcairiel> they decided not to care
[21:30:11 CET] <nevcairiel> since its not a linux issue
[21:30:16 CET] <nevcairiel> or OSS issue for that matter
[21:30:22 CET] <nevcairiel> build everythjing with gcc, and it magically works
[21:30:25 CET] <Daemon404> what about the mingw guys
[21:30:37 CET] <nevcairiel> they are not very smart, remember?
[21:30:38 CET] <nevcairiel> :)
[21:30:45 CET] <Daemon404> as for clang you may have better luck
[21:30:52 CET] <Daemon404> theyre specifically aimign for ABI compat with msvc
[21:31:01 CET] <nevcairiel> indeed
[21:31:07 CET] <nevcairiel> wonder what happens
[21:31:15 CET] <nevcairiel> one of these days I should give clang/c2 a try
[21:31:25 CET] <Daemon404> i had to hack configure to make it work
[21:31:30 CET] <Daemon404> and change config.h
[21:31:34 CET] <Daemon404> it misdetected some inline asm thing
[21:31:45 CET] <Daemon404> inline asm builds if i flipped one bit in config.h
[21:32:10 CET] Action: Daemon404 built with clang-cl and link.exe
[21:32:10 CET] <nevcairiel> once its a bit more stable and "proven" we can work on getting it integrated and detected properly
[21:32:17 CET] <Daemon404> right
[21:32:27 CET] <Daemon404> basically i changed some of teh case statenents
[21:32:36 CET] <Daemon404> the grep -q clang turned into 'if false' for me =p
[21:32:36 CET] <nevcairiel> MS had a post somewhere which defines and whatnot clang sets in that mode
[21:32:41 CET] <Daemon404> and cl changed to if true
[21:32:44 CET] <Daemon404> maximum lazines.
[22:09:20 CET] <Compn> Daemon404 : i dont think vfw/dshow exists in new windows versions. i have no idea what they are using now. i havent even seen new binary codecs besides dshow
[22:09:32 CET] <JEEB> oh don't worry
[22:09:35 CET] <JEEB> they still have that stuff around
[22:09:42 CET] <Compn> wm4 : rewrite avidec when?
[22:09:48 CET] <JEEB> actually the only thing you can rip out of a desktop windows is MF, funny enough
[22:09:54 CET] <JEEB> which is the newest thing on the block
[22:09:58 CET] <Compn> it was mediaframework yes
[22:10:21 CET] <Compn> but i havent even seen anything use mf yet... 
[22:10:25 CET] <Compn> i havent really been looking
[22:10:39 CET] <Compn> probably mf > vfw wrappers lol
[22:10:57 CET] <JEEB> I've seen a couple of things utilizing it, but not too many
[22:11:08 CET] <JEEB> firefox is probably the most popular MF thing around except for WMP
[22:11:37 CET] <JEEB> and as I noted, you can actually install windows without MF, which makes it lulz if you make your app depend on it
[22:16:10 CET] <wm4> apparently windows server comes without MF stuff?
[22:16:46 CET] <JEEB> yeah
[22:16:51 CET] <JEEB> Windows N ed too
[22:16:57 CET] <Compn> why did windows shoot itself in the foot wrt video/multimedia processing ?
[22:17:21 CET] <JEEB> I guess they actually made things somewhat separated and that's a side-effect
[22:17:33 CET] <Compn> windows n is so difficult to reinstall a removed thing. i think i tried installing wmp on that for 3 hours and gave up
[22:17:41 CET] <Compn> ah
[22:17:45 CET] <JEEB> nowadays that's a single installer
[22:17:45 CET] <Compn> more monopoly crap
[22:18:05 CET] <wm4> what's windows n?
[22:18:20 CET] <JEEB> "I don't want your media player" edition
[22:18:22 CET] <Compn> i thought windows n was only in activity for 3 years after the lawsuit
[22:18:28 CET] <Compn> then ms dropped it.
[22:18:42 CET] <JEEB> 8.1 at least had it IIRC
[22:18:44 CET] <JEEB> not sure if win10
[22:19:02 CET] <JEEB> https://support.microsoft.com/en-us/kb/3010081
[22:19:09 CET] <JEEB> exists since there's an installer for it
[23:41:27 CET] <cone-576> ffmpeg 03Michael Niedermayer 07master:03c1129b2064: avfilter/vaf_spectrumsynth: assert that variables are initialized by switch()
[23:41:28 CET] <cone-576> ffmpeg 03Michael Niedermayer 07master:62eb935bf932: avfilter/avf_avectorscope: assert that variables are initialized by switch()
[00:00:00 CET] --- Fri Feb 12 2016