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

[burek]

[00:08:15 CET] <cone-715> ffmpeg 03James Almer 07master:28d5a3a74aee: lavu: rename and move ff_parity to av_parity
[00:12:05 CET] <cone-715> ffmpeg 03James Almer 07master:08339cdb6c8f: configure: remove unused bulitin check
[00:14:12 CET] <ubitux> jamrial: thx, i can sleep peacefully now
[00:14:18 CET] <jamrial> haha, you're welcome :p
[00:14:45 CET] <jamrial> in any case i doubt it broke anything as is. the two files using ff_parity probably included common.h first
[00:40:51 CET] <rcombs> so, apparently MOV has a mechanism to include chapter thumbnails as a video stream
[00:41:01 CET] <rcombs> similarly to how chapter names can be a subtitle stream
[00:42:27 CET] <rcombs> I was planning on just marking chapter name streams as opaque data (https://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/186748.html) but that's a little bit awkward with the images, since it could actually be useful to export those
[00:42:35 CET] <rcombs> so maybe I really do need to add a new disposition
[00:42:51 CET] <rcombs> (I also need a mechanism to identify whether or not a file has such a stream, since it breaks some players)
[01:04:47 CET] <rcombs> nevcairiel: ^ see above MOV stuff; would it be crazy for chapter thumbnail streams to be both AV_DISPOSITION_ATTACHED_PIC and (a new) AV_DISPOSITION_TIMED_THUMBNAIL, or something like that?
[01:05:39 CET] <nevcairiel> i have had people report issues with those chapter thumbnail streams,  if we can somehow  identify them that would be nice
[01:05:53 CET] <nevcairiel> dont really care how you do it
[01:07:09 CET] <rcombs> it's easy to identify them; `tref/chap` just contains an array of uint32_t stream IDs 
[01:07:39 CET] <rcombs> I'm trying to work out how best to export which are chapter streams and differentiate them from regular attached pics
[01:08:04 CET] <rcombs> setting AV_DISPOSITION_ATTACHED_PIC would be nice for compatibility, since at least some software knows to ignore those if it doesn't want to handle them explicitly
[01:08:25 CET] <nevcairiel> would be nice if you can also fill the attached pic struct with the first image
[01:08:27 CET] <rcombs> and then pair that with an additional disposition saying "this is attached images, but they're timed"
[01:09:06 CET] <rcombs> alternately, I could export the stream as opaque binary data and cram the images in the AVChapter dict
[01:09:23 CET] <rcombs> though, uh, that probably wouldn't work since those are null-terminated
[01:09:45 CET] <rcombs> and there's really no guarantee that the chapter-name stream and the chapter-image stream will line up
[01:09:58 CET] <rcombs> but filling the attached pic struct with the first image should be easy
[01:14:38 CET] <rcombs> nevcairiel: relatedly: does https://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/186748.html look sane (considering only chapter-name streams)?
[01:26:40 CET] <nevcairiel> rcombs: not sure, seems slightly odd
[01:27:09 CET] <rcombs> MOV chapters are slightly odd
[02:23:50 CET] <cone-715> ffmpeg 03Ganesh Ajjanagadde 07master:2fbdc4faf1bc: lavfi/avf_showspectrum: replace pow(x, 0.25) by sqrt(sqrt(x))
[02:23:51 CET] <cone-715> ffmpeg 03Ganesh Ajjanagadde 07master:7ab37cae34b3: ffmpeg: check fclose return values
[04:00:30 CET] <BBB> whats a local static array?
[04:58:16 CET] <tmm1> ubitux: let me know if you want me to re-roll any of these patchsets or if theres anything else i can do to help get all the ccaption changes merged
[07:47:02 CET] <ubitux> tmm1: yes, as i said, squash the whitespace/cosmetics commits, and change "libavcodec" to "lavc" in the subject message
[07:47:10 CET] <ubitux> (and if you can rebase too..)
[08:08:04 CET] <jamrial> "In Firefox, we've finally moved to use ffvp9 and ffvp8 in place of libvpx for video decoding"
[08:08:09 CET] <jamrial> \o/
[08:25:09 CET] <ubitux> @_@
[08:39:21 CET] <tmm1> ubitux: ah i missed that, was that on irc earlier?
[08:39:53 CET] <ubitux> yeah
[08:46:24 CET] <tmm1> found the logs. i'll rebase the branch and squash/reword
[08:46:50 CET] <ubitux> thx
[08:47:42 CET] <tmm1> any thoughts on renaming calculate_duration to something else
[08:49:27 CET] <ubitux> "compute_duration"?
[08:50:29 CET] <ubitux> btw, i'll submit a patchset probably today so the duration doesn't end up in the payload
[08:50:45 CET] <ubitux> so duration will be kept to -1
[08:50:51 CET] <ubitux> (or you can just decide to ignore it)
[08:51:11 CET] <ubitux> but the problem isn't really about the duration, it's about the buffering..
[08:51:25 CET] <ubitux> real_time?
[08:54:56 CET] <tmm1> yea i think real_time is best
[08:56:42 CET] <rcombs> anyone else find their terminal screwy after a parallel `make fate`?
[08:57:18 CET] <rcombs> I end up with input invisible and not advancing the cursor, and have to `reset` to get things back to normal
[09:00:15 CET] <ubitux> no but i heard complains about ffmpeg messing the term on interupt recently, even with -nostdin -nostats
[09:01:07 CET] <ubitux> which makes me wonder if we shouldn't disable term_init() when -nostdin and -nostats are passed
[09:15:23 CET] <tmm1> ubitux: here you go: https://github.com/tmm1/ffmpeg/compare/master...upstream-cc-cleanups.patch
[09:51:24 CET] <ubitux> tmm1: i'm going to comment on github, fine with that?
[09:54:09 CET] <ubitux> or you can just resend the patchset on the ml
[09:57:16 CET] <kierank> Hmm global thread pool...
[09:57:24 CET] <kierank> He should hañdle that in his app
[10:02:47 CET] <ubitux> kierank: given that firefox will probably end up (or is actually already?) using multiple processes (for isolation between tabs etc), he will have to anyway
[10:02:50 CET] <ubitux> unless i'm mistaken
[10:11:50 CET] <wm4> nevcairiel: what's the HEVC HDR mastering SEI useful for?
[10:12:51 CET] <wm4> (saw it in your private ffmpeg repo)
[10:13:01 CET] <rcombs> I haven't the foggiest actual idea but I'm going to say "marketing" like everything else with "HDR" in the name regarding video
[10:13:01 CET] <wm4> I'm also going to fish out and try that hevc main 10 dxva patch
[10:16:40 CET] <wm4> I think the idea is 1. standardizing brightness, and 2. going outside of the brightness range usually used today (note: brightness is a naive term, but I'm no damn color scientist)
[10:18:45 CET] <rcombs> I thought it was just marketing-speak for 10bit BT2020
[10:23:39 CET] <kierank> No thats wcg
[10:24:00 CET] <kierank> It's all bs anywau
[10:24:05 CET] <kierank> Nobody will buy it
[10:24:14 CET] <wm4> "One of the issues we've faced was with our reftest tests , with pages
[10:24:14 CET] <wm4> creating hundreds of small video elements "
[10:24:14 CET] <kierank> Other than nerds
[10:24:18 CET] <wm4> I hate the web so fucking much
[10:26:57 CET] <rcombs> wm4: &why would someone do that
[10:27:15 CET] <wm4> actually it looks like they're doing that only for their tests
[10:27:34 CET] <wm4> 1. write shitty tests, 2. force everyone else to change their software so that the tests run
[10:37:43 CET] <ubitux> wm4: well, having webpages full of gif/webm is not that exotic
[10:38:32 CET] <ubitux> http://giphy.com/  "imagine all these shit animated at the same time
[10:39:04 CET] <ubitux> i think some tumblr pages actually do this
[10:39:38 CET] <ubitux> https://www.tumblr.com/tagged/animated-gif
[10:39:40 CET] <ubitux> here you go
[10:41:13 CET] <wm4> give me an argument why browsers should optimize for being able to do the same with videos (or alternatively, why such small "videos" should use threaded decoding)
[10:42:37 CET] <ubitux> enabling threading only for large video would make sense yes
[11:05:29 CET] <wm4> kierank: what about SMPTE-ST-2084? (or is it related to the hevc hdr thing)
[11:10:41 CET] <kierank> That's an HDR spec iirc
[11:10:46 CET] <kierank> Dolby related
[11:20:53 CET] <nevcairiel> wm4: the metadata specifies what brightness and gamut the mastering display had, so you can use that to convert the stream to the users display 
[11:21:31 CET] <wm4> yeah, but what uses it?
[11:24:56 CET] <kierank> The tv
[11:37:05 CET] <nevcairiel> We'll see if HDR sees adoption, HDR screens showing HDR content sure look nice though
[11:40:23 CET] <kierank> it's a gimmick
[11:40:28 CET] <kierank> most people won't notice or care
[11:42:06 CET] <wm4> like 3D is a gimmick?
[11:43:51 CET] <nevcairiel> 3D is just annoying because it needs f'ing glasses, if it worked well without glasses it might be more popular
[11:44:22 CET] <nevcairiel> I won't pretend to know what the most people will notice or care about, but personally I find HDR to be a nice boost in quality on a good screen
[11:45:27 CET] <nevcairiel> (also that there is barely any movies actually filmed in 3D making proper use of the tech, those movies converted to 3D afterwards just look bad)
[11:46:38 CET] <kierank> I went to an HDR demo in a simulated living room and some geeks couldn't tell the difference
[11:46:44 CET] <kierank> how the hell joe public is I don't know
[11:46:53 CET] <kierank> the benefits of HDR are so minimal in the real world
[11:46:55 CET] <kierank> same as 3D
[11:47:42 CET] <wm4> I just wonder how "calibration" would work here
[11:56:01 CET] <cone-686> ffmpeg 03Paul B Mahol 07master:08aec7c1bda4: avfilter/avf_showspectrum: add option to draw legend
[12:03:12 CET] <cone-686> ffmpeg 03Hendrik Leppkes 07master:53ada3af62d5: x86/vf_w3fdif: 32-bit compatibility for w3fdif_simple_high
[13:53:18 CET] <kierank> wm4: you're being a bit harsh on this guy
[13:53:42 CET] <wm4> come on, hundreds of video elements
[13:54:08 CET] <wm4> and the cause for action is that it fails on Windows XP?
[13:54:31 CET] <wm4> but ok I'll try to be slightly less of a dumb asshole
[13:54:51 CET] <kierank> thread pools are a good idea
[13:55:07 CET] <wm4> even if they're global?
[13:55:10 CET] <kierank> no
[13:55:14 CET] <kierank> I said that's bad
[13:56:24 CET] <wm4> that's why I suggested exposing thread pools as API object
[13:58:41 CET] <J_Darnley> OMFG!  You need 1 video element on a page because you should be showing 1 video at a time.  (Fucking webdevs).
[13:59:14 CET] <wm4> J_Darnley: I think the intention is that it replaces gif elements
[13:59:36 CET] <wm4> which is why I ridiculed it with some geocities comment
[13:59:46 CET] <J_Darnley> :)
[14:00:16 CET] <wm4> (but even if they did that, they should make invisible elements inactive anyway)
[14:00:50 CET] <J_Darnley> But then how would advertisers blast you with hidden audio ads?
[14:02:36 CET] <wm4> there's the <audio> element for that? I think...
[14:03:14 CET] <J_Darnley> But you want to show video when the user scrolls into position or changes tab.
[14:11:52 CET] <kierank> wm4: web devs are morons
[14:12:01 CET] <kierank> worse than broadcast people
[14:15:26 CET] <nevcairiel> thats mostly because web dev is cool and everyone thinks they can do it
[14:16:06 CET] <J_Darnley> CPU power and memory are infinite, unused resources after all.
[14:16:16 CET] <qeed> the infinity machine?
[14:16:24 CET] <wm4> meanwhile firefox is the process that uses most memory on my machine
[14:17:12 CET] <nevcairiel> browsers are hard to count these days, they split themself into many processes all taking up memory :D
[14:17:30 CET] <J_Darnley> (good browsers don't)
[14:17:36 CET] <qeed> what are good browsers
[14:17:41 CET] <J_Darnley> Pale Moon
[14:18:08 CET] <nevcairiel> the whole concept of doing that is a good idea tbh, it allows proper security sandboxing, the web is a bad place
[14:18:23 CET] <nevcairiel> and all these firefox off-shoots are just silly
[14:18:48 CET] <J_Darnley> No Firefox is silly for Australis and now dropping Extensions
[14:19:28 CET] <wm4> dropping extensions?
[14:19:52 CET] <Compn> yes firefox dropping extensions
[14:19:53 CET] <nevcairiel> i think firefox wants to go towards chrome-style extensions and dropping their own extension thing
[14:20:00 CET] <Compn> probably because of pressure against ad blockers haha
[14:20:59 CET] <J_Darnley> That means their olive branch of the "old UI extension" will probably also not work.
[14:21:24 CET] <wm4> uh
[14:21:34 CET] <wm4> I'm still using tons of extensions to undo their UI changes
[14:21:52 CET] <wm4> (not all of them, it's not like I reject them blindly)
[14:23:52 CET] <J_Darnley> Their plan hasn't made it into the main releases yet (I don't even know if its in their nightlies)
[14:25:11 CET] <wm4> by the way, why does Intel broadwell appear to support HEVC 10 bit decode on DXVA? (probably hybrid)
[14:25:42 CET] <nevcairiel> yeah its hybrid
[14:25:52 CET] <nevcairiel> just like skylake
[14:26:33 CET] <wm4> eh
[14:26:54 CET] <wm4> so, 8 bit on skylake is native, on broadwell it's hybrid?
[14:26:58 CET] Action: Daemon404 wonders if it may be a good idea to put a big fat warning on the wiki about it being user-created
[14:27:02 CET] <Daemon404> and not official documentation
[14:27:10 CET] <Daemon404> (because its full of wtf / wrong stuff)
[14:27:18 CET] <nevcairiel> skylake definitely has native 8-bit, but i dont know if broadwell also had that
[14:27:31 CET] <nevcairiel> so many different generations to remember
[14:27:32 CET] <wm4> is there a way to find out?
[14:27:38 CET] <nevcairiel> run it, check cpu usage =p
[14:29:11 CET] <wm4> enabling dxva on broadwell with 8 bit seems to half CPU usage (from ~17% to ~9%)
[14:29:54 CET] <nevcairiel> broadwell should be hybrid 8-bit from what I can find
[14:30:20 CET] <nevcairiel> probably still faster than cpu decoding considering how slow avcodec is
[14:30:29 CET] <wm4> seems so
[14:30:53 CET] <wm4> regarding your dxva patch: you're worried that the API user now needs a profile check for HEVC
[14:31:11 CET] <wm4> but h264 needs a profile check anyway, so at least the API users has to be aware of the potential problem?
[14:32:28 CET] <nevcairiel> even for h264 the need for a profile check is rare, the only type of content that would need it is lossless 420 8-bit, which is rare enough as it is
[14:32:38 CET] <nevcairiel> so some dumb app could be doing fine without it
[14:33:34 CET] <wm4> then I'd suggest adding a private option
[14:34:28 CET] <Daemon404> can someone give me a quick gist of that big threadpool ML thread
[14:34:45 CET] <Daemon404> i dont think it's a terrible idea
[14:34:52 CET] <Daemon404> i have hit thread limits, on linux, due to the same problem
[14:34:56 CET] <Daemon404> albeit on large transcoding servers.
[14:35:16 CET] <Daemon404> especially considering each thread, by default, uses 2-4mb stack space.
[14:35:43 CET] <nevcairiel> its probably hard to properly setup though, since we wouldnt want global state, and we dont have a "master" context concept right now to shove something like this in
[14:35:54 CET] <Daemon404> yes of course
[14:36:09 CET] <Daemon404> im sayign the idea is OK
[14:36:13 CET] <Daemon404> if they do the work properly
[14:36:14 CET] <Daemon404> etc
[14:36:43 CET] <Daemon404> a cursory glance of the thread seems like the usual drive to make new cntributers go away
[14:37:01 CET] <wm4> now this guy compares pthread with firefox-internal thread pool APIs
[14:44:04 CET] <kierank> Daemon404: only the global part is contentious
[14:44:34 CET] <Daemon404> kierank, keyword: properly
[14:44:40 CET] <Daemon404> it doesnt need to be some global state
[14:45:28 CET] <Daemon404> although the easiest way may just be to use/allow some trheading library
[14:45:39 CET] <Daemon404> similar to how we allow user-provided alloc libs
[14:46:07 CET] <kierank> yeah and make w32threads use that api
[14:46:31 CET] <Daemon404> eh w32threads is unrelated
[14:46:39 CET] <Daemon404> it could just override everything
[14:46:42 CET] <Daemon404> itst he user's problem
[14:46:46 CET] <Daemon404> if they provide a lib
[14:46:53 CET] <kierank> ok
[14:54:13 CET] <cone-686> ffmpeg 03Mats Peterson 07master:13d02d3dc81a: lavf/mov: Audio and fourcc 0x00000000
[14:54:14 CET] <cone-686> ffmpeg 03Mats Peterson 07master:6f1466dc5272: lavf/matroskadec: A_QUICKTIME and fourcc 0x00000000
[14:54:15 CET] <cone-686> ffmpeg 03Michael Niedermayer 07master:47cd85e1e5b1: avformat/mov: Simplify format checking code
[14:59:43 CET] <cone-686> ffmpeg 03Paul B Mahol 07master:b7b4d99a1837: avfilter/avf_showfreqs: fix possible null pointer dereference
[15:02:29 CET] <durandal_1707> clang crashed by libpostproc, lib that nobody touch
[15:02:57 CET] <Daemon404> clang HEAD?
[15:05:17 CET] <durandal_1707> 3.7.0
[15:05:39 CET] <wm4> fix clang then, and be grateful to postproc for being a good test case
[15:06:00 CET] <Daemon404> i tried to get 3.7 to self-host on my pandaboard
[15:06:17 CET] <Daemon404> but it cant build its own tablegen properly
[15:06:20 CET] <Daemon404> gets SIGBUS'd
[15:07:03 CET] <durandal_1707> libpostproc should be moved/replaced by lavfi
[15:07:16 CET] <Daemon404> good luck with that
[15:07:44 CET] <Daemon404> my personal opinion is that postproc actually has no value in 2016
[15:08:46 CET] <wm4> durandal_1707: isn't there a lavfi wrapper
[15:12:08 CET] <durandal_1707> yes, but I mean functionality like lgpl deblocking and deringing
[15:12:35 CET] <Daemon404> there are a lot of avs/vs deblock/dereing filters on doom9
[15:12:41 CET] <Daemon404> but they don't use MB-level info
[15:34:56 CET] <tmm1> ubitux: github comments are fine
[15:44:47 CET] Action: J_Darnley must not troll on the dev mailing list
[16:23:30 CET] <ubitux> fmt_ctx->max_analyze_duration = -1;
[16:23:33 CET] <ubitux> best hack ever
[16:23:55 CET] <ubitux> (sets a negative value outside allowed range, so it doesn't actually do expensive probing)
[16:24:17 CET] <wm4> wut
[16:24:31 CET] <ubitux> i have an issue here, on embedded devices
[16:25:00 CET] <ubitux> i'm basically using the ffmpeg to probe and demux, and sends the pkt to an accel
[16:25:21 CET] <ubitux> but the find_stream_info on an mp4/h264 file will actually start decode the h264 stream
[16:25:34 CET] <ubitux> which will cause a peak of 15-20M of heap alloc
[16:25:48 CET] <ubitux> and will slow down the startup significantly because of the ffh264 decoding
[16:26:01 CET] <Daemon404> do you know the file is always h264?
[16:26:10 CET] <Daemon404> just skip the find_stream_info entirely if so
[16:26:12 CET] <ubitux> i don't, but issue is the same anyway
[16:26:15 CET] <ubitux> no i can't 
[16:26:17 CET] <Daemon404> ah.
[16:26:20 CET] <ubitux> i need some timebase stuff
[16:26:28 CET] <ubitux> context is half broken if i don't call it
[16:26:53 CET] <Daemon404> i manually decode 1 frame of audio and video to fill stuff in
[16:26:55 CET] <ubitux> anyway, unfortunately, max_analyze_duration is in [0;+inf], so i can't use avoption (0 is default and means sth like 5 seconds for video)
[16:26:56 CET] <Daemon404> and keep my own frame queue
[16:26:59 CET] <wm4> Daemon404: you can't do that in the general case, even if your API usage can handles it in theory
[16:27:15 CET] <Daemon404> wm4, general case being unknown format?
[16:27:17 CET] <Daemon404> of cours.e
[16:27:18 CET] <ubitux> but fmt_ctx->max_analyze_duration = -1 works really well :]
[16:27:22 CET] <wm4> yeah
[16:27:32 CET] <Daemon404> wm4, i do it our DASH and HLS packager
[16:27:35 CET] <Daemon404> which always gets h264/aac
[16:27:45 CET] <wm4> then you're in luck
[16:27:45 CET] <Daemon404> and must run on-the-fly
[16:27:48 CET] <Daemon404> it's a big speedup.
[16:28:17 CET] <ubitux> http://b.pkh.me/guess-where-is-the-probing.png
[16:29:28 CET] <ubitux> then with the hack: http://b.pkh.me/negative-max-analyze-duration.png
[16:29:30 CET] <ubitux> \o/
[16:29:42 CET] <ubitux> (not the same scale)
[16:30:08 CET] <ubitux> we should probably have -1 being the default
[16:30:13 CET] <ubitux> and allow 0
[16:30:37 CET] <Daemon404> changing the analyze duration default will piss of unlimited numbers of people
[16:30:41 CET] <Daemon404> it's a massive behavior change
[16:31:02 CET] <ubitux> it won't change anything
[16:31:24 CET] <Daemon404> i cant see how it wouldnt
[16:31:51 CET] <ubitux> default value should be -1 instead of 0, and -1 would mean the same fallback (5s video 30s sub ...) as 0 is currently
[16:31:56 CET] <ubitux> except that 0 will be allowed too
[16:32:21 CET] <ubitux> so unless you force 0 (which would make no sense since it's the default currently), it won't change for you
[16:33:26 CET] <Daemon404> perhaos i misunderstand
[16:33:30 CET] <Daemon404> [15:23] <@ubitux> (sets a negative value outside allowed range, so it doesn't actually do expensive probing)
[16:33:39 CET] <Daemon404> that differs from what you just said.
[16:34:18 CET] <ubitux> i was describing the hack
[16:34:41 CET] <Daemon404> you were descri bing teh behavior of setting -1
[16:34:43 CET] <Daemon404> afaict?
[16:34:52 CET] <Daemon404> why would it act differently if it is default
[16:35:05 CET] <Daemon404> first you sya it wont probe
[16:35:10 CET] <Daemon404> then you say itll have 5s
[16:35:27 CET] <ubitux> Daemon404: http://b.pkh.me/0001-lavf-allow-null-max_analyze_duration.patch
[16:35:55 CET] <ubitux> then i could do av_opt_set_int(fmt_ctx, "analyzeduration", 0, 0); instead of my hack
[16:36:06 CET] <ubitux> and that won't change anything for anyone
[16:36:40 CET] <Daemon404> ah. i hadnt understood that you inded to change your own code to not use -1 after.
[16:37:08 CET] <Daemon404> although that patch needs to have the -1 default added then
[16:37:45 CET] <ubitux> -1 default added? that's in the patch
[16:38:16 CET] <Daemon404> ubitux, isnt it also a context member
[16:38:19 CET] <jamrial> "if (!max_analyze_duration < 0)" that's clearly not right :p
[16:38:38 CET] <ubitux> jamrial: heh yeah, that's a prototype ;)
[16:38:53 CET] <ubitux> (fixed)
[16:39:25 CET] <ubitux> Daemon404: i dont understand
[16:39:26 CET] <Daemon404> ubitux, does that properly set max_analyze_duration/max_analyze_duration2 in the afctx?
[16:39:32 CET] <Daemon404> by changing just teh opt table
[16:39:47 CET] <ubitux> {.i64 = -1 }
[16:39:50 CET] <ubitux> this is the default value
[16:39:54 CET] <ubitux> i supposed these are populated
[16:40:26 CET] <Daemon404> the offset is for max_analyze_duration
[16:40:30 CET] <Daemon404> i'd confirm max_analyze_duration2 is also set
[16:40:31 CET] <Daemon404> im sure it is
[16:40:44 CET] <ubitux> max_analyze_duration2 doesn't exist
[16:40:56 CET] <ubitux> (anymore)
[16:41:15 CET] <Daemon404> wait what the fuck
[16:41:25 CET] <Daemon404> it used to exist, and max_analyze_duration was deprecatwed
[16:41:27 CET] <ubitux> it was probably renamed in a major bump or some shit
[16:41:36 CET] <Daemon404> ... you should NEVER reuse names
[16:41:39 CET] <Daemon404> even if you bump
[16:41:54 CET] <ubitux> yes, but i'm not the responsible :X
[16:41:56 CET] <Daemon404> seems thats what happened
[16:41:58 CET] <Daemon404> that's awful.
[16:42:05 CET] <Daemon404> api compatible and will silently break
[16:42:07 CET] <ubitux> max_analyze_duration is int64 so that's probably what happened yes
[16:42:18 CET] <Daemon404> yes i just checked
[16:42:26 CET] <nevcairiel> see it this way: it wasnt re-used, the size was just changed
[16:42:34 CET] <nevcairiel> we have changed types of variables often enough in a bump
[16:42:37 CET] <nevcairiel> this is no different
[16:43:00 CET] <ubitux> you should use avoption to set/get it anyway :-°
[16:43:17 CET] <Daemon404> nevcairiel, no the unit changed
[16:43:22 CET] <Daemon404> behavior has changed
[16:43:25 CET] <Daemon404> nto just type
[16:43:39 CET] <nevcairiel> only the type changed afaik
[16:44:17 CET] <nevcairiel> to allow for bigger values
[16:44:23 CET] <Daemon404> hmm confusing
[16:44:29 CET] <Daemon404> becauses max_analyze_duration2 mentioned timebase units
[16:44:32 CET] <Daemon404> max_analyze_duration mentiones no units
[16:44:36 CET] <Daemon404> seems i got confused
[16:44:38 CET] <Daemon404> due to lack of any doc
[17:48:48 CET] <durandal_1707> ubitux: nlmeans status?
[17:50:58 CET] <ubitux> no progress since last time, maybe this week end
[17:51:33 CET] <ubitux> going to submit some subtitles stuff tonight, and will go back to it
[18:03:35 CET] <cone-686> ffmpeg 03Paul B Mahol 07master:a69cf50dca51: avfilter/avf_showspectrum: add cool color map
[18:22:02 CET] <ubitux> durandal_1707: where are you getting all these color maps?
[18:23:31 CET] <durandal_1707> from other software
[18:24:11 CET] <durandal_1707> fruit is inspired by default one in sonic visualizer
[18:24:37 CET] <durandal_1707> fire from nugen 
[18:24:55 CET] <durandal_1707> Rainbow from speek
[18:25:32 CET] <durandal_1707> cool is based on parula, used in matlab IIRC
[18:26:16 CET] <ubitux> ok :)
[18:26:37 CET] <durandal_1707> fiery from other spectrogram soft
[18:28:03 CET] <durandal_1707> there is also web page with over millions palletes, mostly useless for filter
[18:28:21 CET] <ubitux> durandal_1707: why is overlap=[0;1) going faster but overlap=1 slow again?
[18:29:27 CET] <durandal_1707> overlap 1 doesn't make sense so it picks one recommended by win function
[18:29:34 CET] <ubitux> ok
[18:30:49 CET] <durandal_1707> using big overlap makes sense only if fps is low, with big fft window
[18:45:43 CET] <Compn> why add new hacks to playback old broken ffmpeg mov/mkv when we can just make user use old ffmpeg? :P
[18:46:47 CET] <iive> Compn: please, use the proper sarcasm tag.
[19:27:59 CET] <kurosu> Is anyone able to use gdb with msys2 64bits? I either get "Cannot access memory at address" or the breakpoint doesn't actually trigger
[19:34:23 CET] <tmm1> morning
[19:35:53 CET] <tmm1> ubitux: i can resubmit to the list too if you prefer
[19:59:53 CET] <ubitux> tmm1: i'm finally free, i'm going to look at github, no woryr
[20:03:41 CET] <ubitux> tmm1: "avc/ccaption_dec: reap_screen() is responsible for clearing output buffer and signaling screen_changed
[20:03:46 CET] <ubitux> what does this commit do?
[20:06:50 CET] <cone-686> ffmpeg 03Aman Gupta 07master:b261749f7071: lavc/ccaption_dec: clean up whitespace
[20:07:23 CET] <cone-686> ffmpeg 03Aman Gupta 07master:5695c8533294: lavc/ccaption_dec: remove unused return value from internal functions
[20:10:53 CET] <tmm1> ubitux: just moves the screen_changed bit and the bprint_clear into the reap_screen so its centralized in one place
[20:11:14 CET] <ubitux> can you rework the commit message to say that?
[20:11:19 CET] <ubitux> it's not obvious reading it
[20:11:41 CET] <ubitux> you can then push force and i'll continue the merging
[20:12:46 CET] <tmm1> sure
[20:14:26 CET] <tmm1> pushed
[20:15:58 CET] <cone-686> ffmpeg 03James Almer 07master:7f520524f67a: x86/float_dsp: remove len check from ff_butterflies_float_sse
[20:16:00 CET] <cone-686> ffmpeg 03James Almer 07master:4ee38ed7f903: x86/float_dsp: zero extend len from ff_butterflies_float_sse implicitly
[20:16:01 CET] <cone-686> ffmpeg 03James Almer 07master:dc79824deb6a: x86/float_dsp: zero extend offset from ff_scalarproduct_float_sse
[20:22:09 CET] <J_Darnley> That is explicit not implicit.
[20:24:43 CET] <nevcairiel> explicit was using an extra instruction for it, now its implicit by acting on a dword sized reg =p
[20:26:28 CET] <J_Darnley> Sorry
[20:26:40 CET] <J_Darnley> I did read those + and - backwards
[20:26:52 CET] <cone-686> ffmpeg 03Aman Gupta 07master:53ee84f811c3: lavc/ccaption_dec: reap_screen() is responsible for clearing output buffer and signaling screen_changed
[20:26:54 CET] <cone-686> ffmpeg 03Aman Gupta 07master:26abdd61a397: lavc/ccaption_dec: implement "erase non displayed memory"
[20:27:45 CET] <ubitux> tmm1: any idea why screen reaping was done on erase?
[20:31:18 CET] <tmm1> ubitux: not sure, but it's definitely not correct
[20:31:36 CET] <tmm1> in all the samples i tried the stream will send explicit EDM when it wants you to erase, and EOC when it wants you to display
[20:32:04 CET] <tmm1> the previous code called EDM from EOC which seemed to work but wasn't technically right
[20:32:24 CET] <tmm1> i think that was because "erase non-displayed memory" wasn't implemented before, so that extra erase was required
[20:38:31 CET] <cone-686> ffmpeg 03Ricardo Constantino 07master:e990d746d051: configure: Use libgcrypt-config if available
[20:40:00 CET] <ubitux> tmm1: ok
[20:40:43 CET] <ubitux> tmm1: do you have samples with tab offset?
[20:41:16 CET] <ubitux> can it be implemented easily with injecting some ass positionning?
[20:41:41 CET] <cone-686> ffmpeg 03Aman Gupta 07master:fe225b113b05: lavc/ccaption_dec: reap_screen is not necessary when clearing screen or buffer
[20:42:44 CET] <ubitux> if you want to ignore them for now, can you at least set a specific debug info printing the settings or something?
[20:44:10 CET] <tmm1> i put that in there to quelch the debug output, because it was generating a lot of noise
[20:44:18 CET] <tmm1> one of the samples i put up did tab offset commands
[20:44:38 CET] <ubitux> one you uploaded? remember the name?
[20:44:47 CET] <tmm1> i'm not sure how easy it is to implement, because the screen buffer is just characters and doesn't let you record any other information that would later be required to translate into ass positioning
[20:45:16 CET] <ubitux> so the sample was repositionning after every character?
[20:45:21 CET] <tmm1> if you want to skip that commit that's fine by me, its only noisy if you have debug loglevel enabled
[20:45:32 CET] <ubitux> it's ok, i was just curious
[20:45:54 CET] <tmm1> not after every character, maybe after every EDM. i can check which one it was
[20:47:18 CET] <ubitux> 80df4b0 breaks fate
[20:47:27 CET] <ubitux> can you make fate-sub-cc GEN=1 and check if the diff is correct?
[20:47:46 CET] <ubitux> if it is, include the chunk in the commit and push force again please
[20:50:13 CET] <tmm1> sure
[20:51:42 CET] <tmm1> music.ts has the tab offset commands
[20:53:24 CET] <ubitux> noted, thx
[20:53:25 CET] <tmm1> also has "0x11 0x37" which is supposed to render a musical note glyph, but i wasn't sure how to put that in the char* buffer either
[20:54:19 CET] <ubitux> print the utf-8 code?
[20:54:30 CET] <ubitux> ass is supposed to support unicode
[20:55:38 CET] <tmm1> yea but Screen uses a uint8_t *characters
[20:56:31 CET] <ubitux> aren't you supposed to write them in the av buffer thing?
[20:57:03 CET] <tmm1> chars are written into the screen, and then reap_screen pulls them into the buffer
[20:57:16 CET] <tmm1> because all the commands are row/column based so the screen is a representation of that
[20:57:24 CET] <ubitux> so if you print sth like "\xe2\x99\xac" will it work?
[20:57:24 CET] <tmm1> 15x32
[20:57:25 CET] <J_Darnley> Up with j.  Down with #.
[20:58:49 CET] <tmm1> there's three optional character tables defined on the wikipedia page, so ideally we'd implement all of them and probably add another table to Screen that holds the character encoding for each row/column
[20:59:07 CET] <tmm1> then in reap_screen it can emit the equivalent utf-8 into the buffer
[20:59:20 CET] <tmm1> anyway, they're optional so its ok for now. i can do some follow up patches
[20:59:35 CET] <ubitux> sure
[21:00:09 CET] <tmm1> looking at this fate thign, do you have the failure handy?
[21:01:58 CET] <ubitux> make fate-sub-cc
[21:02:01 CET] <ubitux> it will fail
[21:02:08 CET] <ubitux> (you need to have samples etc)
[21:02:26 CET] <ubitux> see https://ffmpeg.org/fate.html
[21:02:52 CET] <ubitux> (just need to read point 2)
[21:08:35 CET] <cone-686> ffmpeg 03James Almer 07release/2.4:030fed62f4cf: x86/float_dsp: zero extend offset from ff_scalarproduct_float_sse
[21:08:36 CET] <cone-686> ffmpeg 03James Almer 07release/2.5:4bcbeaa337ea: x86/float_dsp: zero extend offset from ff_scalarproduct_float_sse
[21:08:37 CET] <cone-686> ffmpeg 03James Almer 07release/2.6:b90796ab8627: x86/float_dsp: zero extend offset from ff_scalarproduct_float_sse
[21:08:38 CET] <cone-686> ffmpeg 03James Almer 07release/2.7:34c5f6685a86: x86/float_dsp: zero extend offset from ff_scalarproduct_float_sse
[21:08:39 CET] <cone-686> ffmpeg 03James Almer 07release/2.8:3e3aa25afa10: x86/float_dsp: zero extend offset from ff_scalarproduct_float_sse
[21:10:19 CET] <tmm1> found an old fate-samples dir, updating now
[21:24:07 CET] <tmm1> ubitux:  what sample file corresponds to sub-cc
[21:24:27 CET] <ubitux> tmm1: try make fate-sub-cc V=1 
[21:24:35 CET] <ubitux> you'll see what command is run
[21:24:39 CET] <tmm1> gotcha thanks
[21:29:06 CET] <philipl> BtbN: it sounded like you were doing vaapi-vp8. Actually true? My skylake nuc just arrived so I'll look at it if you're not.
[21:35:20 CET] <tmm1> ubitux: force pushed
[21:35:28 CET] <tmm1> added another fate test for the new realtime mode as well
[21:39:15 CET] <ubitux> why did one dialog disappear?
[21:41:21 CET] <ubitux> tmm1 ^
[21:42:05 CET] <tmm1> ubitux: because the sample dosen't have the second NEWLINE command, so its buffered but never emitted
[21:42:20 CET] <ubitux> what about emiting in flush?
[21:43:56 CET] <tmm1> not sure that would work correctly when seeking then..
[21:44:20 CET] <ubitux> ok ok
[21:44:20 CET] <tmm1> is flush called on both seek and eof?
[21:44:30 CET] <ubitux> i think so
[21:44:39 CET] <ubitux> can you add a comment in the commit to explain the fate change?
[21:44:52 CET] <tmm1> yes
[21:47:31 CET] <tmm1> done
[21:50:07 CET] <ubitux> cool, thx, i continue the merge then
[21:50:20 CET] <ubitux> how long are you going to be available?
[21:52:07 CET] <ubitux> mmh
[21:53:42 CET] <tmm1> i'm here for a few hours
[21:54:38 CET] <ubitux> ok cool
[21:54:52 CET] <ubitux> i'm a bit confused at this bprintf you added in the commit
[21:54:57 CET] <ubitux> which wasn't present before
[21:56:01 CET] <ubitux> also, 2 small comments on "ctx->prev_string = av_strdup(ctx->buffer.str);": 1. unchecked malloc 2. you should check if av_bprint_is_complete()
[21:56:38 CET] <tmm1> the bprintf is part of ff_ass_add_rect_bprint
[21:57:13 CET] <tmm1> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/ass.c#L183
[21:57:30 CET] <tmm1> i switched to ff_ass_add_rect() so i need to do the \r\n 
[21:58:28 CET] <ubitux> ah, missed that
[21:58:35 CET] <ubitux> mmh
[21:58:36 CET] <ubitux> ok
[21:59:59 CET] <tmm1> i'll add a av_bprint_is_complete() check
[22:00:28 CET] <tmm1> i think prev_string can perhaps be ignored? because the next time around the loop it will see its null and not do anything
[22:00:40 CET] <tmm1> or should i just ENOMEM as well
[22:03:24 CET] <ubitux> git grep -A1 av_bprint_is_complete confirms ENOMEM is relevant
[22:03:44 CET] <BtbN> philipl, I started, but didn't have time over christmas/new year, and didn't finish it yet.
[22:03:45 CET] <ubitux> is it ok to print \r\n when it doesn't enter the prev_string check?
[22:04:23 CET] <BtbN> philipl, https://github.com/BtbN/ffmpeg/tree/vaapi_vp8 if you want to pick it up. It's nearly done, there are some variable mapping from the ffmpeg vp8 structs to the VAAPI ones missing.
[22:04:38 CET] <BtbN> The biggest problem are the weird data offset values VAAPI wants
[22:04:42 CET] <tmm1> ubitux: no, because the other branch still uses ff_ass_add_rect_bprint() which would cause double \r\n
[22:04:44 CET] <BtbN> ffmpeg has nothing that's even close to them.
[22:05:05 CET] <tmm1> i could do it before and switch to use the non-_bprint in both cases
[22:05:05 CET] <BtbN> Because it parses the bitstream fundamentaly diffrent from gst, which vaapi is designed around
[22:05:33 CET] <tmm1> but then the third real time branch gets confusing 
[22:06:03 CET] <ubitux> tmm1: sorry i'm still after the same commit, so there is only one
[22:06:35 CET] <BtbN> philipl, but I'm not sure if VP8 hwaccel is worth it anymore. From testing with gst, the ffmpeg software decoder uses less CPU than VAAPI "accelerated" decoding.
[22:06:51 CET] <tmm1> originally i was trying to use a prev_buffer, but i didn't see an easy way to copy ctx->buffer to prev_buffer
[22:07:00 CET] <tmm1> so i ended up with the char* and strdup
[22:07:47 CET] <ubitux> ok
[22:08:00 CET] <ubitux> i'm starting to get confused but ok, i'll probably recheck everything at the end
[22:08:19 CET] <tmm1> i can fixup the commit with ENOMEM
[22:08:23 CET] <philipl> BtbN: Maybe you'd see a benefit for 4k streams :-P
[22:08:25 CET] <ubitux> i have my pending branch where i rework that shit, it would be more convenient to have only ff_ass_add_rect_bprint() though :D
[22:08:28 CET] <philipl> I'll take a look over the weekend
[22:08:28 CET] <ubitux> but whatever :)
[22:08:32 CET] <ubitux> tmm1: please do :)
[22:08:39 CET] <philipl> It's also possible that gst lameness is burning cpu. That happens.
[22:09:48 CET] <BtbN> The hwaccell hooks are done, at least I think so.
[22:09:55 CET] <tmm1> ubitux: pushed
[22:09:59 CET] <BtbN> Not 100% sure where the hook calls should be placed, but it should work
[22:10:14 CET] <philipl> BtbN: Matches what I came up with before. So I believe it :-)
[22:12:13 CET] <ubitux> tmm1: libavcodec/ccaption_dec.c:527:40: error: buf undeclared (first use in this function)
[22:12:50 CET] <ubitux> tmm1: can you also squash "rename calculate_duration to real_time" into the "add calculate_duration option" one?
[22:14:56 CET] <tmm1> oof, that's embarassing
[22:14:57 CET] <ubitux> tmm1: also, "Do not buffer closed captions to calculate durations. Emits subtitle events in real-time for display."  please make one sentence, with no capitalize nor period, for consistency
[22:17:38 CET] <tmm1> how about "emit subtitle events as they are decoded for real-time display"
[22:18:17 CET] <tmm1> i guess it should mention missing duration too
[22:19:16 CET] <tmm1> "emit subtitle events in real-time without calculating durations"
[22:20:39 CET] <ubitux> tmm1: i like 2nd one
[22:21:38 CET] <tmm1> ok let me do this rebase, i'll have to ammend a bunch of the follow up commits that refer to the old option
[22:21:59 CET] <ubitux> sorry :)
[22:22:30 CET] <ubitux> the fate test is frightening btw
[22:23:05 CET] <ubitux> like, the subtitle really is supposed to appear character by character every 1.5s?
[22:24:31 CET] <ubitux> the duplicated last event is curious too
[22:24:39 CET] <tmm1> yea in rollup mode
[22:24:53 CET] <tmm1> in painton its buffered off screen and shows up as the person starts speaking
[22:25:06 CET] <tmm1> rollup is more common for sports and news where its being live transcribed
[22:25:29 CET] <ubitux> so that's actually live timed with a keyboard?
[22:25:49 CET] <ubitux> or it's a karaoke-of-the-poor?
[22:25:56 CET] <tmm1> i'm not sure how they do it, there's specialized equipment for it supposedly
[22:26:00 CET] <ubitux> in which case, maybe a \k ass event would be appropriate?
[22:26:50 CET] <tmm1> yea that could be better, but then you're still buffering and by the time you emit the event it's too late
[22:27:03 CET] <ubitux> yep, i see
[22:27:12 CET] <ubitux> and with the buffering mode, would it make sense?
[22:27:49 CET] <tmm1> it might look better but the end result is the same
[22:28:09 CET] <tmm1> it essentially appears like a popon caption, where the text all shows up when the person begins speaking
[22:28:23 CET] <tmm1> which is totally fine if you're converting caps to webvtt or something and playing after the fact
[22:31:14 CET] <ubitux> tmm1: btw, here is a present for you: http://hackipedia.org/ATSC/EIA-608%20samples/EIA-608%20character%20set%20test/
[22:34:39 CET] <ubitux> but in your realtime example, the text appears progressively, right?
[22:35:34 CET] <ubitux> that's going to be slightly weird at playback
[22:37:47 CET] <tmm1> nice
[22:38:43 CET] <ubitux> if we support the raw, it might be relevant to add it to fate
[22:38:48 CET] <ubitux> since it's small
[22:39:42 CET] <tmm1> phew, rebase done
[22:39:46 CET] <tmm1> i moved the simpler commits to the top
[22:42:27 CET] <ubitux> tmm1: don't you leak prev_string somehow?
[22:42:47 CET] <ubitux> like, the last one
[22:42:56 CET] <tmm1> yes, good catch
[22:44:10 CET] <tmm1> ubitux: fixed
[22:46:43 CET] <ubitux> i feel like the flush is incomplete
[22:46:57 CET] <ubitux> like maybe missing a free of prev_line, resetting prev_cmd too
[22:47:08 CET] <ubitux> and maybe some more
[22:49:34 CET] <ubitux> also, sorry to go back to that timestamp fix one
[22:49:54 CET] <tmm1> i can move flush further down the patchset and include those
[22:50:03 CET] <ubitux> but the timing of the dialogue changed from 0:00:12.36 ’ 0:00:40.83 to 0:00:40.83 ’ 0:00:59.07
[22:50:07 CET] <ubitux> is it really correct?
[22:50:22 CET] <tmm1> ubitux: that sample has no audio so i can't tell
[22:50:34 CET] <tmm1> but in all the samples i've tested, the new timestamps are correct
[22:50:47 CET] <ubitux> they were completely broken previously?
[22:50:49 CET] <tmm1> you can try it with movie.ts for instance, that one is very apparent
[22:51:30 CET] <ubitux> why wasn't it detected before?
[22:51:48 CET] <ubitux> i mean... 30s is kind of a large gap :p
[22:51:52 CET] <ubitux> anyway ok..
[22:52:33 CET] <tmm1> i asked the same question, then spent two weeks rewriting this decoder =)
[22:52:40 CET] <ubitux> :D
[22:53:03 CET] <tmm1> i wish that sample did have audio
[22:53:21 CET] <ubitux> i think there was a larger sample
[22:53:25 CET] <ubitux> and it was cut down several time
[22:53:30 CET] <ubitux> i can dig up the ml 
[22:55:47 CET] <ubitux> one is here, but might not be this one http://samples.ffmpeg.org/MPEG2/subcc/ClosedCaptions/subccItalic.mpg
[22:56:17 CET] <ubitux> more here:
[22:56:19 CET] <ubitux> http://samples.ffmpeg.org/MPEG2/subcc/ClosedCaptions/Starship_Troopers.vob
[22:56:20 CET] <ubitux> http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket1482/NCIS.wtv
[22:56:21 CET] <tmm1> looks different, has separate subtitle track
[22:57:04 CET] <tmm1> dvd_subtitle tracks on the second as well
[22:59:55 CET] <tmm1> ubitux: also that sample in fate is only 4s so i dunno how we're pulling 60s of subs out of it
[23:00:27 CET] <ubitux> tmm1: http://gsocdev.ccextractor.org/~anshul/test_video/
[23:00:29 CET] <ubitux> here it is
[23:00:44 CET] <ubitux> Closedcaption_atsc_rollup.ts probably
[23:01:29 CET] <ubitux> tmm1: ok ok
[23:02:04 CET] <tmm1> yep that's it
[23:02:12 CET] <tmm1> watching now, the word "Safety" starts at 40s in
[23:02:38 CET] <tmm1> seems to match the realtime output, S shows up at :43
[23:03:18 CET] <ubitux> but doesn't match the buffered one at all
[23:03:25 CET] <ubitux> unless i'm missing something
[23:03:41 CET] <tmm1> oh i used Closedcaption_rollup.ts
[23:04:25 CET] <tmm1> ugh yea the non-buffered looks wrong
[23:05:12 CET] <tmm1> it must be a difference between popon and rollup then
[23:06:50 CET] <tmm1> if i run my ffmpeg on both those ts files, even in buffered mode, the output is correct
[23:06:55 CET] <tmm1> there's something different about the fate version
[23:07:13 CET] <ubitux> yeah iirc it's truncated more or less savagely
[23:07:25 CET] <ubitux> so you might be missing essential events
[23:07:41 CET] <ubitux> we'll probably need a better test
[23:07:53 CET] <ubitux> (the raw i pasted might be good if we can feed it to the decoder)
[23:09:31 CET] <tmm1> http://pastie.org/10678449
[23:10:29 CET] <ubitux> can you paste a diff -u?
[23:10:48 CET] <ubitux> no diff with Closedcaption_rollup.ts ?
[23:11:02 CET] <tmm1> the timestamps are different on each line
[23:11:12 CET] <tmm1> they're shifted down by one
[23:11:30 CET] <tmm1> it seems plausible my patch is incorrect for rollup
[23:12:07 CET] <tmm1> i was testing primarily with movie.ts, which is popon and was definitely off-by-one in the current decoder
[23:13:02 CET] <tmm1> so for POPON, when EOC comes in that's when the cc is first shown, hence the sub->pts should match the pts of the EOC
[23:13:28 CET] <tmm1> but in ROLLON, since the cc is being shown progressively, the sub->pts is actually the pts of the *previous* NEWLINE
[23:16:20 CET] <ubitux> so i still wait for merging this commit?
[23:16:34 CET] <tmm1> yes i need to redo it
[23:17:14 CET] <ubitux> ok, i'm going back to my stuff then
[23:17:15 CET] <tmm1> thanks for finding that sample
[23:17:18 CET] <ubitux> poke me anytime
[23:17:23 CET] <tmm1> cheers
[23:17:27 CET] <ubitux> i might go to sleep soon though
[23:19:58 CET] <ubitux> anyone getting that "http: No trailing CRLF found in HTTP header." with twitch streams?
[23:20:07 CET] <ubitux> like, every 1-3s
[23:20:17 CET] <ubitux> is this warning really geniune?
[23:21:13 CET] <BtbN> Sounds like something Twitch would do.
[23:22:12 CET] <BtbN> They also broke their IRC, so that you could not connect without giving a PASS line. Even when you didn't want to login, you had to send an empty line instead, because their parser was bad...
[23:23:27 CET] <nevcairiel> ubitux: if your ffmpeg is slightly old, it may have been a bug that was fixed
[23:23:31 CET] <nevcairiel> or maybe the fix was never pushed
[23:23:32 CET] <nevcairiel> idk
[23:24:25 CET] <ubitux> it's probably using ff 2.8.4 from my system (mpv)
[23:26:18 CET] <nevcairiel> fix might be nwer than that
[23:26:21 CET] <nevcairiel> i dont remember exactly
[23:26:35 CET] <ubitux> ok ok, didn't notice a fix
[23:28:08 CET] <c_14> Should be this one https://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=f00ec7eb1b94b31ffdb11a54adda339f08ace245
[23:28:30 CET] <ubitux> ah great
[23:28:31 CET] <ubitux> thx
[23:33:26 CET] <Compn> you can get in twitch chat via irc ?
[23:33:33 CET] <nevcairiel> barely
[23:33:38 CET] <nevcairiel> their IRC emulation sucks terribly
[23:33:40 CET] <Compn> for each channel ?
[23:33:48 CET] <Compn> or whatever they call it
[23:35:35 CET] <cone-686> ffmpeg 03Michael Niedermayer 07master:5c8467a07c65: avformat/ivfenc: fix division by zero
[23:35:49 CET] <BtbN> It's not IRC emulation
[23:35:58 CET] <BtbN> It actualy is IRC, their official client also uses it that way
[23:36:15 CET] <nevcairiel> if anything its "IRC"
[23:36:17 CET] <BtbN> You can even see it complaining about now knowing a bunch of IRC commands if you open the debug console
[23:36:29 CET] <nevcairiel> its like a homebrew version of IRC that happens to work with some clients
[23:36:47 CET] <BtbN> Except for their Whisper-System it's fully IRC compliant.
[23:36:56 CET] <BtbN> They even support a bunch of IRCv3 stuff
[23:37:08 CET] <nevcairiel> except you need to do some trickery to even login
[23:37:17 CET] <Compn> oh theres a twitch irc guide
[23:37:18 CET] <Compn> thx 
[23:37:25 CET] <BtbN> It doesn't behave like your usual IRC server, but it does fully comply with the IRC protocol.
[23:37:39 CET] <nevcairiel> the protocol also defines behavior =p
[23:37:55 CET] <BtbN> You just connect to irc.twitch.tv with your username and an oauth token.
[23:37:58 CET] <BtbN> as PASS
[23:38:11 CET] <BtbN> It's unencrypted, so they don't want you to use your normal password
[23:53:40 CET] <Compn> chinese smiley faces in vp9 huh
[23:53:50 CET] <Compn> and using ffmpeg to display these in mozilla firefox?
[23:54:00 CET] <Compn> sounds like a disaster waiting to happen (libstagefrieght anyone?)
[23:55:38 CET] <Compn> wm4 : good try , trying to get web developers to not be stupid. i fully agree with the theory, just not the reality :(
[23:55:59 CET] <atomnuker> I like the idea of caching frames for looping videos
[23:56:16 CET] <atomnuker> but I doubt anyone would like browsers to consume any more memory than they already eat
[23:57:17 CET] <TD-Linux> I would be happy with actually seamless looping in firefox for starters :)
[00:00:00 CET] --- Sat Jan  9 2016