[00:00] <ubitux> ok [00:00] <ubitux> this all sounds overcomplicated for no good reason though [00:00] <rcombs> indeed! [00:03] <rcombs> and unfortunately, I think Pango is probably too high-level for libass [00:04] <J_Darnley> ubitux: there is still only the log2_chroma_[wh] values rather than a value per component. This means that you need to do "tricky" things for >3 planes or if you want a loop that includes the luma plane. [00:05] <ubitux> >3 planes? alpha channel? [00:05] <J_Darnley> yes. [00:06] <J_Darnley> I don't recall anything with a 5th plane yet [00:07] <ubitux> let's add a plane for subtitles [00:08] <J_Darnley> z-data, to support a 3d volume! [00:09] <rcombs> one plane for each cone type in a mantis shrimp's retina! [00:09] <rcombs> (we're going to need a bigger Bayer filter) [00:17] <J_Darnley> okay, that looks like it is working. [00:30] <thardin> I did those very low bitrate video tests btw [00:31] <thardin> x265 is looking very promising :) [00:32] <thardin> and version string does indeed mess up rate control at these low rates [00:43] <J_Darnley> ubitux: I'm going to send a WIP to the list so you, and everyone else, can see it. [00:43] <J_Darnley> It works but is missing a few things. [00:43] <J_Darnley> like some documentation. [01:27] <Timothy__Gu> J_Darnley: CMYKA has 5 planes [01:29] <Timothy__Gu> Interesting English: "Why to crash, if don't crash it's better? :)" in #3950 [01:46] <cone-583> ffmpeg.git 03Michael Niedermayer 07master:6beea6f017f5: avcodec/tiff: fix odd dimensioned yuv [03:13] <cone-583> ffmpeg.git 03James Almer 07master:91459bd320b4: avcodec: remove obsolete FF_API_DSPUTIL cruft [05:32] <molikto_> hi, i know this is offtopic... but can anyone help me configure a minimal build for some specific input/output/command??? I am helpless and the only thing in my mind is to try divide and conquer.... [05:35] <molikto_> anyone here? [06:20] <molikto_> anyone can help me?? [06:25] <jamrial> molikto_: this channel is for development of ffmpeg. for user support you should ask in #ffmpeg [06:26] <molikto_> the question is not exactly a user-level question... although it is also not dev-related... nevermind... i will figure out myself [07:21] <ubitux> ff [07:21] <ubitux> oups [08:30] <sorinv> Hey guys .. quick question: do you know where this kind of error comes from? I am struggling to build Blender with ffmepg support in it getting this link error [08:30] <sorinv> /opt/lib/ffmpeg/lib/libavcodec.a(libtheoraenc.o): In function `submit_stats': [08:30] <sorinv> /root/src/blender-deps/ffmpeg-2.1.5/libavcodec/libtheoraenc.c:142: undefined reference to `th_encode_ctl' [11:15] <wm4> ubitux: still working on that subtitle thing? [11:16] <ubitux> yes, but today i'm at work :p [11:16] <wm4> in mpv I have some kind of subtitle "filter chain" [11:16] <wm4> but it's not very good and has some design issues [11:16] <ubitux> wm4: WIP @ https://github.com/ubitux/FFmpeg/compare/subtitles-ng [11:17] <ubitux> WIP commit is basically a draft i started yesterday as an attempt to create a text sub structure for the decoded form, with ass markup, as muxed in mkv [11:18] <wm4> hm [11:19] <ubitux> tell me more about your subtitle filter chain [11:19] <wm4> it passes the mpv equivalent of AVPacket from filter to filter [11:19] <wm4> and filters at the end of the chain have a function for retrieving bitmaps [11:20] <wm4> subtitle converts (like lavc "decoders") are filters in the middle of the chain [11:20] <wm4> renderers are at the end [11:20] <wm4> one renderer is libass, and the other is lavc (for vobsub and pgs) [11:21] <wm4> but things like charset conversion or timing adjustments (avoiding small gaps/overlaps) are unfortunately not part of the chain [11:22] <wm4> but it would be nice if a new ffmpeg subtitle api could handle these things [11:27] <ubitux> hum [11:28] <ubitux> the charset convert model is so broken in ffmpeg you can't use it? [11:29] <ubitux> what's this timing adjustment? for post seeking? [11:29] <wm4> ffmpeg just wraps iconv a little, it's utterly unusable [11:30] <wm4> the timing adjustment is just to avoid little gaps of no subs, or subs overlapping for a moment [11:30] <wm4> because of timing inaccuracies [11:30] <wm4> it's not used for ASS [11:36] <ubitux> i'm not sure what to propose for charsets.. [11:36] <ubitux> grr we really need that timeline thing for mov/mp4 [11:37] <wm4> isn't that similar to mkv ordered chapters? [11:39] <ubitux> dunno [11:48] <ubitux> wm4: btw, hb can be built without glib in the upstream [11:49] <wm4> I know [11:49] <wm4> but distros use glib anyway [13:47] <cone-169> ffmpeg.git 03Michael Niedermayer 07master:8c1dc1f6ed11: avformat/network: add union for avoiding strict aliassing violations with sockaddr* [13:47] <cone-169> ffmpeg.git 03Michael Niedermayer 07master:e587a428d75d: avformat/rtpproto: fix strict aliasing violations with sockaddr [14:07] <ubitux> anyone has a link to the previously rejected mov edit list patch from google? [14:16] <ubitux> michaelni: n2.5-dev LGTM [14:17] <iive> 2.4 have been release? [14:17] <iive> d [14:18] <ubitux> yes [14:21] <iive> nice :) [14:30] <wm4> seriously how did this ever happen: vf_eq and vf_eq2 [14:30] <wm4> they use the same asm [14:30] <wm4> at least almost [14:31] <wm4> or actually it's exactly the same [14:31] <J_Darnley> You are probably right with your "politics" comment. [14:31] <ubitux> :D [14:34] <iive> wm4: there are eq and eq2 native ffmpeg filters? [14:34] <wm4> no, libmpcodecs [14:35] <iive> oh, ok. [14:43] <iive> wm4: what is the trouble with vdpau and preemption, and what kind of preemption is at play there? [14:45] <wm4> iive: vdpau preemption can lose the vdpau state at any time (typically VT switching) [14:47] <iive> so you have to restart decoding from scratch? [14:49] <wm4> basically; you have to reinitialize everything again [14:51] <iive> major headache... [14:51] <iive> does this apply to the mesa3d gallium vdpau driver too? [14:53] <wm4> no [14:53] <wm4> apparently not [14:53] <wm4> just nvidia [15:28] <nevcairiel> you know its fasctinating how just days after a change lands in ffmpeg, the same change lands on the libav ML, but they didnt bother to keep authorship. Granted, its just a trivial one line change, but still, and don't even try to claim coincendence [15:28] <nevcairiel> -n [15:29] <wm4> don't let them hear that [15:49] <ubitux> nevcairiel: what are you thinking about? [17:01] <J_Darnley> I'm now wondering why contrast seems to have a different meaning and default in eq2. The default has moved from 0 to 1.0 and it seems to lack an add when it is used (in the mmx function). [17:01] <J_Darnley> (I'll read any replies later, I need to make dinner) [17:10] <iive> J_Darnley: hum? brightness and contrast form liner function where output=brightness+contrast*input. [18:10] <cone-192> ffmpeg.git 03James Almer 07master:4ae6bcc025e7: RELEASE: update to 2.4.git [20:15] <J_Darnley> Dammit! Why are you giving me a grey image? [20:16] <nevcairiel> grey ios the new black? [20:16] <J_Darnley> :) [20:24] <J_Darnley> dammit gdb! why can't you give ffmpeg a filename with spaces? [20:24] <ubitux> gdb --args ? [20:25] <wm4> gdb --args ./ffmpeg "fi le.mkv" [20:25] <J_Darnley> Doesn't work. gdb still seems to split at the space despite there being a backslash [20:26] <ubitux> shell issue? [20:26] <wm4> are you on windows? [20:26] <J_Darnley> Cygwin and bash [20:26] <wm4> windows treats the command line as a single string, instead of a list of arguments [20:26] <wm4> so you'll get random fuckups there [20:28] <J_Darnley> gdb is probably doing something special here [20:28] <J_Darnley> rather than what every other program does [20:38] <wm4> well, gdb has to pass the arguments to the child process [21:01] <cone-192> ffmpeg.git 03James Almer 07master:af7d2606261e: avutil: remove obsolete FF_API_LLS1 cruft [21:01] <cone-192> ffmpeg.git 03James Almer 07master:95a064f53034: avutil: remove obsolete FF_API_OLD_OPENCL cruft [21:01] <cone-192> ffmpeg.git 03James Almer 07master:ad1dadac86d4: avfilter: remove obsolete FF_API_BUFFERSRC_BUFFER cruft [21:02] <J_Darnley> Is the AVOption system supposed to initialize unspecified options as the default values? [21:04] <nevcairiel> yes [21:04] <nevcairiel> if something called the set-defaults function on your context [21:05] <J_Darnley> maybe I'm missing that. [21:05] <nevcairiel> usually you wouldnt need to do that yourself, unless you invented some kind of new context [21:13] <J_Darnley> oh nevermind, i'm just an utter idiot [21:30] <J_Darnley> There we go. eq and eq2 are now in one file. [21:33] <wm4> yay [21:42] <ubitux> in vf_hue.c ? [22:01] <J_Darnley> no. [22:31] <cone-192> ffmpeg.git 03Mika Raento 07master:f685f7d7a838: hlsenc: single_file, support HLS ver 4 byteranges [22:40] <cone-192> ffmpeg.git 03Mika Raento 07master:00431bf874e1: ismindex: handle time discontinuities and nonzero start time [22:40] <cone-192> ffmpeg.git 03Michael Niedermayer 07master:21561610560f: Merge commit '00431bf874e1044b01e09a2266ef85d4ff8d44cc' [23:26] <iive> "[h264 @ 0xb5204440] non-existing SPS 32 referenced in buffering period" what does this message mean? [23:26] <nevcairiel> it tries to use a SPS which it doesn't have yet [23:26] <iive> it's spamming my console when i play dvb-t stream. [23:26] <nevcairiel> if the message occurs during opening of the file, it can usually be safely ignored [23:27] <nevcairiel> how does playback look? [23:27] <iive> perfect. [23:27] <nevcairiel> and it keeps spamming the message during playback? [23:27] <iive> yes [23:27] <nevcairiel> thats weird [23:28] <nevcairiel> but as long as playback works! [23:29] <iive> it's horrible [23:29] <wm4> oh, libav having a flame about their review policy [23:29] Action: wm4 gets popcorn [23:30] <nevcairiel> and not even one of us that started it [23:31] <iive> funny thing, when ffplay reaches the end of the playback, the messages start to get grouped 200-300 together. [23:32] <iive> wm4: irc or maillist? [23:32] <wm4> irc [23:32] <nevcairiel> irc [23:33] <ubitux> i thought i was the only one to notice an hour ago [23:34] <ubitux> seems i'm not the only evil stalker [23:34] <nevcairiel> i mostly ignored it [23:34] <nevcairiel> its nothing but all the same [23:36] <ubitux> wm4: u evil [23:40] <ubitux> haha he's trolling hard [23:40] <wm4> courmisch threatening to fork [23:40] <ubitux> for the third time [23:40] <iive> wm4: remi? the one with the vdpau patches i asked about? [23:40] <ubitux> yes [23:40] <iive> what a coincidence... [23:41] <baptiste> courmisch in libav ? [23:42] <j-b> yeah [23:42] <nevcairiel> its not like he would run a full fork, more like my fork, application specific patches on top of upstream [23:42] <nevcairiel> many downstreams have such things [23:43] <nevcairiel> just not those trying to be d istributed on linux [23:43] <ubitux> it's probably a way to get it merged in ffmpeg without being explicit sending it to ffmpeg-devel [23:44] <j-b> And not a bad tactics [23:45] <ubitux> i'm not exactly sure what would be the point of doing so, except :ego: [23:45] <ubitux> but sure, if it works, whatever :) [23:45] <baptiste> j-b, why not sending to both ? [23:45] <wm4> or just fork and relicense as GPL3 [23:46] <j-b> baptiste: no clue. [23:46] <j-b> baptiste: probably because it's eaiser to send to one? [23:48] <nevcairiel> well if you want to rely on some new API, you kinda need to send it to libav, or it wont be available on a bunch of systems, and since ffmpeg merges anyway.. [23:48] <baptiste> yeah I guess adding another cc is more complicated ;) [23:49] <wm4> btw. did the debian ffmpeg package make it yet? [23:49] <nevcairiel> the dude said in a mail earlier today it might get in soon [23:49] <wm4> soon? ok, I'll ask again in 6 months [23:49] <nevcairiel> baptiste: if the api needs changing d ue to feedback, its better not to have it merged in one project already, but wait until its actually finished [23:49] <ubitux> it can, because it's in the top 5 pending packages [23:50] <ubitux> (if you count the 4+ months in queue before version bump) [23:51] <iive> is the queue visible somewhere? [23:51] <ubitux> https://ftp-master.debian.org/new.html [23:51] <iive> i kind of get the feeling it is more like a blackbox... [23:51] <ubitux> 2.2.1 waited 4+ months, 2.3.1 waited 1+ month, 2.4 was submitted... an hour ago [23:51] <ubitux> actually, 3 [23:52] <baptiste> nevcairiel, in my experience, getting any feedback as early as possible is better, but it's true that I haven't sent a patch since quite some time :) [23:55] <cone-192> ffmpeg.git 03Clément BSsch 07master:864d124bb7aa: build: simplify libwebp check [23:58] <iive> baptiste: it is nice to see you around. [00:00] --- Tue Sep 16 2014