[02:19] <cone-186> ffmpeg.git 03Michael Niedermayer 07master:9e8ab36f5419: avformat/mxfenc: dont warn about d10_channelcount being ignored if its not set [02:29] <Timothy_Gu> I just noticed that DonDiego never wrote a single en/decoder/(de)muxer. I wonder why he is the person with the second highest number of commits in FFmpeg. [02:30] <Timothy_Gu> Even koda wow one [02:30] <Timothy_Gu> *wrote [02:30] <Timothy_Gu> Damn Android keyboard [02:34] <kierank> Timothy_Gu: cosmetics of course [02:34] <Timothy_Gu> Well I know that [02:34] <Timothy_Gu> And splitting things [02:35] <Timothy_Gu> And fixing the build system although it was a while back [02:35] <Timothy_Gu> But nothing so significant for the features of FFmpeg [02:53] <wm4> splitting crap was probably pretty significant [02:55] <wm4> for what's it worth, I think he did mostly cosmetic commits in mplayer too [02:55] <wm4> and build system things [02:55] <Compn> he split up a lot of dec/enc so that makes ffmpeg faster, sometimes [02:55] <Compn> also writes docs . webpage [02:59] <Timothy_Gu> Compn: I don't recall seeing him writing documentation on libav-devel [03:00] <Timothy_Gu> Compn: how does splitting things make it faster? [03:00] <Compn> well if you load ffmpeg binary that was compiled without encoders... [03:00] <Compn> :P [03:00] <Compn> technically loading a 40mb binary vs 100mb binary :P [03:00] <Timothy_Gu> lol [03:00] <kierank> Compn: you could do that already [03:01] <kierank> load an enc without a dec [03:10] <Timothy_Gu> michaelni: WARNING: Big Xvid C IDCT merge conflict incoming: https://lists.libav.org/pipermail/libav-devel/2014-August/062691.html [06:42] <jamrial> config.h is not an installed header, right? [06:45] <nevcairiel> Right [06:46] <jamrial> great, because lavu/opencl.h, an installed header, includes it [06:46] <jamrial> unless i'm missing something, that shouldn't happen [06:46] <nevcairiel> The whole opencl stuff is majorly screwed up [06:48] <jamrial> yeah [06:50] <jamrial> this basically means that nothing/nobody outside of lavfi really got to use the api at all [07:22] <ubitux> Timothy_Gu: well, he just picked 298b3b6c1f8f66b9bc6de53a7b51d3de745d946b, reindented, and dropped signed-off [07:23] <ubitux> ah, and merged it in another file [07:24] <Timothy_Gu> That's the catch [09:19] <spky_> hi ,guys, i set a timeout for socket, and if av_read_frame return timeout, i want to reconnect it. Q1. when timeout happens, av_read_frame return eof, no flag specify the timeout happens, this will be fine, whatever, i reconnect it Q2. then i call avio_close(format_ctx->pb), avio_open(&format_ctx->pb, filename ,AVIO_FLAG_READ), if open success, then i call av_read_frame, but it just dump the metadata of rtmp, then the function s [09:21] <spky_> any other cleanup or resetup functions should i call for the reconnect? [09:23] <spky_> it just behaves like : myffplay "rtmp://xxxx timeout=3" , and add the reconnect function [10:27] <__gb__> hi nevcairiel, why is this an issue wrt. linking against libva? that's a totally independent library from x11 or wayland backends [10:27] <__gb__> actually, I would like to just move more work into libavcodec, instead of having applications or libraries handle all the same stuff [10:28] <__gb__> i.e. we should normally just need to provide a VADisplay to libavcodec, and the rest (surfaces management, etc.) handled implicitly [11:05] <wm4> __gb__: libva breaks so many abstractions, you can't have libavcocec handle surfaces :D [11:06] <wm4> anyway, that kind of stuff is what lu_zero on Libav wants to do [11:07] <__gb__> please elaborate, I didn't catch everything :) [11:07] <__gb__> e.g. what breaks, what does luca wants to do? [11:08] <wm4> luca wants to move more parts of hwaccel to lavc (for all hwaccel backends) [11:08] <wm4> and the issue with libva at least I see is that all surfaces need to be preallocated [11:08] <__gb__> yes, that's the correct thing to do, along others (like handling fallbacks to SW decently) [11:08] <wm4> if the application keeps a surface longer than expected, things can go wrong [11:10] <__gb__> unfortunately, some pretty ancient HW/driver relies on that behaviour (pre-allocate surfaces within a context) [11:10] <__gb__> though, I personally don [11:10] <wm4> luca's idea has some other practical issues, like the fact that you don't know from the start which hwaccel API you want to use [11:10] <__gb__> 't care :) [11:11] <wm4> hm, so you can just skip the preallocation? [11:12] <__gb__> on intel hd graphics driver, we don't mind. though, I'd say that nowadays with MVC support, that comes to be necessary. I think I can arrange for that [11:13] <__gb__> wm4, for the selection of the hwacell API to use, I had proposed in the v2 an hwaccel_id, which could be quite straightforward [11:13] <__gb__> + a hook similar to get_pix_fmts() -> get_hwaccel_ids() [11:14] <wm4> the thing is, you somehow need to ask the application to create a hw context (like VADisplay) [11:14] <__gb__> though, did not have the time to update that since the past 3 years /o\ [11:14] <__gb__> yes [11:16] <__gb__> for vaapi, at least for any driver depending on libdrm, I foresee ways to not care about that. i.e. have VA display internally allocated + adequate buf sharing interfaces for rendering [11:16] <__gb__> it depends on how much of legacy we want to maintain, for sure, we can do better things [11:17] <wm4> that would be nice (and VDA kind of works this way), but of course the other APIs like vdpau or dxva should also be supported [11:17] <wm4> and the user also must have control over what's created [11:18] <__gb__> yes, that doesn't solve issues for other apis for sure, I was just pointing out that this is technically possible, if needed :) [11:18] <wm4> what if the system has 2 GPUs from different vendors, running on different X servers [11:18] <wm4> would buffer sharing be possible between them? [11:19] <__gb__> if there is kernel support for it, yes [11:19] <__gb__> however, performance wise, this would all depends on other requirements [11:20] <__gb__> (e.g. implicit conversions/copies needed if different tiling, cache invalidation for sync'ing things?) [11:21] <__gb__> I believe, there has been experiments with nvidia gpus (+nouveau), though I don't know the outcome of it [11:21] <wm4> interesting stuff [11:22] <wm4> it would be nice if there were some way of sharing buffers, independent of specific graphics APIs (vaapi, opengl, etc.) [11:22] <__gb__> on linux, that's dma_buf (PRIME fd) [11:22] <wm4> speaking of, is there a way to do opengl interop with vaapi yet? other than going over X11 [11:23] <__gb__> yes, I have to write/clean a sample app for it, support code for libva, driver and mesa (yuv) is available already though [11:23] <wm4> just some documentation would be great already [11:24] <wm4> we've also tried to make vaapi work on wayland, but nothing really worked well [11:25] <wm4> well, I'm off again [11:25] <__gb__> for any new VA-API, I wanted proper Doxygen documentation nowadays. please let me know if the following is not good enough: [11:25] <__gb__> http://cgit.freedesktop.org/vaapi/libva/commit/?h=staging&id=544d31d2fc096a838c21f4684cec05746cfdd7b6 [11:27] <__gb__> thanks wm4 for your comments, I am finalizing a few deinterlacing fixes & tests, and I should be able to get back to the EGL/vaapi interop stuff + MT issue along the way [11:50] <nevcairiel> __gb__: my problem with linking is that its an extra dependency, since i distribute binaries. If it were like dlopen'ed at runtime, then I could simply test if its available, instead of forcing everyone to have it [12:00] <__gb__> nevcairiel, I don't think it was in lavc (ffmpeg/libav) policy to dlopen shared libs, but your suggestion makes sense too -- better ask/propose a patch to the -dev lists then? [12:00] <__gb__> I personally don't mind either way, as long as the vaapi code still works :) [12:01] <__gb__> (and that we still make efforts in keeping a unique SONAME, which is the case) [12:37] <cone-711> ffmpeg.git 03Anton Khirnov 07master:75bbaf2493a7: mpegenc: limit the maximum muxrate [12:37] <cone-711> ffmpeg.git 03Michael Niedermayer 07master:127aee4ccb5e: Merge commit '75bbaf2493a71ee66eaabe3c21fadd84d07888de' [12:53] <cone-711> ffmpeg.git 03Anton Khirnov 07master:1688eef25385: avconv: fix the muxrate values for -target [12:53] <cone-711> ffmpeg.git 03Michael Niedermayer 07master:ad207f1119d9: Merge commit '1688eef25385089026aba55da1885f70a57815ab' [13:11] <cone-711> ffmpeg.git 03Anton Khirnov 07master:f5245a9c6206: avconv: fix parsing the AVOptions for -target [13:11] <cone-711> ffmpeg.git 03Michael Niedermayer 07master:2082c00ea2ed: Merge commit 'f5245a9c6206878b892adf3ccbccc9311c202af5' [13:14] <ubitux> BBB: can you try http://ffmpeg.org/pipermail/ffmpeg-devel/2014-August/161917.html and see if it's enough to reproduce & fix the regression? [13:39] <ubitux> so what's the plan for lena.pnm? [13:55] <Compn> ubitux : draw on it and call it a parody (fair use copyright) ? :P [13:55] <ubitux> it's already fair use [13:55] <ubitux> the issue is that it's not free and so debian can't distribute it [13:56] <ubitux> s/can't/don't want to/ [13:56] <Compn> ah [13:57] <ubitux> we should just add a lena source filter [13:57] <ubitux> and hide that shit here [13:59] <Compn> -vf lenalives [13:59] <Compn> was that the official debian rejection reason? [14:01] <ubitux> no [14:01] <ubitux> but our packager worries about it [14:01] <ubitux> and i believed that's because he's tired of waiting, so he's looking for issues where there isn't :p [14:29] <cone-711> ffmpeg.git 03Michael Niedermayer 07master:7a67ab5cba8e: ffmpeg_opt: reduce diff to libav in opt_target() by 16 lines [14:36] <pross-au> i'm tired of waiting too [14:54] <nevcairiel> They are intentionally delaying anyway, and at this point its extremely unlikely to get into Jessie, so they have another 2 years to talk about it [15:02] <cone-711> ffmpeg.git 03Jean-Francois Thibert 07master:12df9b9a1510: Improved AC3 decoder level support (heavy drc, dialnorm) [15:28] <Daemon404> kierank, i cannot believe how bad yodel are... [15:41] <kierank> forgot if i posted tihs here: http://www.obe.tv/about-us/obe-blog/item/14-using-opus-audio-in-broadcasting [15:44] <cbsrobot> kierank: a picture showing a opus live stream - seems legit [15:46] <ubitux> kierank: nice [15:46] <kierank> http://www.scei.co.jp/ps4-license/sf_ffmpeg.ZIP [15:46] <kierank> ffmpeg from ps4 [15:46] <ubitux> is that smptehdbars with drawtext? [15:47] <kierank> yes [15:47] <ubitux> \o/ [15:47] <kierank> (my main reason for moving to ffmpeg) [15:48] <ubitux> durandal_1707 will be glad to hear that [15:50] <thardin> nice [15:51] <kierank> in an alternative universe that blog post would be a BS filled white paper [15:51] <kierank> but i couldn't bring myself to do that [15:52] <Timothy_Gu> kierank: nice house [15:52] <kierank> it's a nice place but the owner said she is going to sell it next year [15:52] <ubitux> is that a zotac? [15:53] <kierank> no [15:53] <Timothy_Gu> Hmm, the house is not your own? [15:53] <kierank> i rent it [15:53] <kierank> it's a flat [15:54] <Daemon404> kierank, my landlady recently fell ill and theyre selling the house [15:54] <Daemon404> i have 2-3 months to find a place [15:54] <Daemon404> sucks [15:56] <Timothy_Gu> Our landlady is a ~60-year-old Indian woman whose husband teaches C++ and whose son's startup was bought be Amazon [15:57] <Timothy_Gu> And of course our rent rises each year [15:59] <J_Darnley> That's how money works! [16:00] <J_Darnley> You charge more and more for the same stuff [16:00] <Timothy_Gu> Damn [16:01] <Timothy_Gu> *Damn 'šÀ [16:05] <Timothy_Gu> (I still don't know how to say that word in English) [16:06] <ubitux> https://translate.google.com/#auto/en/%E9%80%9A%E8%B4%A7%E8%86%A8%E8%83%80 ? [16:06] <kierank> inflation [16:11] <Timothy_Gu> Thx [16:12] <Timothy_Gu> There you go [16:12] <Timothy_Gu> It literally means "everything is inflated" [16:12] <Timothy_Gu> ubitux: are you still learning Japanese? [16:13] <ubitux> i stopped a while ago [16:13] <ubitux> will restart soon"®© [16:14] <Timothy_Gu> Kanji too hard? [16:14] <Timothy_Gu> Or too many? [16:15] <ubitux> i don't think that's particularly hard, but it needs a lot of engagement in it (time wise) [16:15] <ubitux> i'm a slow learner, especially when there is no direct usage [16:16] <ubitux> tools like anki are really cool because it makes me realize how stupid i can be [16:16] <ubitux> like, asking 10 times what kanji it is in 5 times and failing everytime i'm asked which it is :p [16:17] <ubitux> in 5 minutes* [16:18] <ubitux> anyway, i need to re-allocate between 2 and 4 hours a day to it [16:19] <ubitux> it might be possible, but i need to schedule it properly [16:19] <ubitux> </mylife> [16:21] Action: Timothy_Gu fails to visualize how ubitux pronounces Kapanese [16:21] <Timothy_Gu> *Japanese [16:22] <ubitux> what? :) [16:22] <ubitux> Japanese is easy to pronounce in French [16:22] <ubitux> (every vocal is available in french) [16:22] <ubitux> there is no tones like in Chinese [16:23] <Timothy_Gu> Tones are easy [16:23] <ubitux> the pronunciation & oral understanding aren't really an issue [16:23] <Timothy_Gu> http://people.wku.edu/shizhen.gao/Chinese101/gift/tone/tones.gif [16:24] <Timothy_Gu> Anyways gotta go to school now [16:24] <ubitux> cya [16:24] <Timothy_Gu> BTW I'm taking Spanish but seems like nobody speaks Spanish here [16:25] <Timothy_Gu> I know reynaldo does and probably DonDiego although he lives in Germany or something [17:01] <Daemon404> kierank, i found a sort-of close hash that it could have been forked from [17:02] <Daemon404> but it's almost like they updated everything independently... [17:05] <kierank> no surprise [17:05] <Diogo> hi i have a mpegts file and i want to cut a specific chunk for hls... [17:05] <Diogo> how can i cut this chunk ? [17:08] <Compn> Timothy_Gu , ubitux : i gave up learning japanese. i dont have the ability to discern all of the syllables. [17:09] <Compn> spanish seems a little slower , maybe easier :) [17:09] <Compn> also i never got started on the kanji, too many characters. [17:14] <Compn> and also there are emphasis on different syllables in japanese, so oba-san vs oBAsan vs OHba-san can meant aunt or grandmother :\ [17:17] <Compn> knew i was in trouble when i couldnt even subtitle a raw anime episode. which i think was the first time i looked for mplayer. because it was the only player that supported rm files and could slow down playback. [17:19] <Compn> so yeah probably no one say that [17:19] <Compn> saw* [17:19] <Compn> derp [18:29] Action: durandal_1707 should license smptehdbars AGPL3 [18:35] <kierank> lol [19:01] <cone-843> ffmpeg.git 03James Almer 07master:d3e9bee6f7e5: lavf/mp3enc: don't abort if audio packets can't be buffered [19:25] <cone-843> ffmpeg.git 03Timothy Gu 07master:25cb697d0c86: bktr: Fix Fabrice's name [20:07] <cone-843> ffmpeg.git 03Michael Niedermayer 07master:7c51f5bd3903: swr: aarch64 audio_convert and neon clobber test [20:41] <cone-843> ffmpeg.git 03James Almer 07master:7997d7864379: lavc/libwebpenc: use WebPMemoryWriterClear() [20:51] <cone-843> ffmpeg.git 03Luca Barbato 07master:ff771f79b55a: vc1: Initialize start_code_found to 0 [20:51] <cone-843> ffmpeg.git 03Michael Niedermayer 07master:a59d922d2488: Merge commit 'ff771f79b55a346b4163d814b58ee4c98114745e' [21:02] <cone-843> ffmpeg.git 03Luca Barbato 07master:404731bd20e1: pulse: Set the wallclock option as default [21:02] <cone-843> ffmpeg.git 03Michael Niedermayer 07master:42196083fe63: Merge commit '404731bd20e1df5880e6fe381e975ba48afc75b2' [21:07] <cone-843> ffmpeg.git 03Diego Biurrun 07master:1f156af4274d: x86: xvid_idct: Drop unused definitions [21:07] <cone-843> ffmpeg.git 03Michael Niedermayer 07master:3ff5ca89fc87: Merge commit '1f156af4274dc72d588620f6bedb4e9e66023c92' [21:16] <cone-843> ffmpeg.git 03Diego Biurrun 07master:dcb7c868ec7a: cosmetics: Make naming scheme of Xvid IDCT consistent with other IDCTs [21:16] <cone-843> ffmpeg.git 03Michael Niedermayer 07master:b3b05a11d31d: Merge commit 'dcb7c868ec7af7d3a138b3254ef2e08f074d8ec5' [21:33] <J_Darnley> If I want to submit a patch which makes some minor language corrections to comments in libavutil/frame.h, what should I prepend to the commit message? Would "lavu/frame.h" be okay? [21:34] <nevcairiel> Drop the .h IMHO [21:34] <J_Darnley> Although I did think that specifying the filename would be a little redundant [21:34] <Compn> either way sounds fine to me :P [21:49] <llogan> J_Darnley: similar typos in libavcodec/msvideo1enc.c and libavcodec/mpeg12enc.c [22:12] <J_Darnley> Stupid find! Why would I want to do different -execute options at the same time? [22:25] <cone-843> ffmpeg.git 03Diego Biurrun 07master:8d27bf1cff35: x86: xvid: K&R formatting cosmetics [22:25] <cone-843> ffmpeg.git 03Michael Niedermayer 07master:5403a288a7fa: Merge commit '8d27bf1cff35be406b0fd89d832e1852d4c573bc' [22:25] <J_Darnley> llogan: I think there is also one in doc/fftools-common-opts.texi [22:38] <J_Darnley> I hope this will be correct useage of --annotate [22:52] <cone-843> ffmpeg.git 03Michael Niedermayer 07master:7a2c380e93f8: avformat/aviobuf: remove uses of deprecated url_feof() [22:54] <jamrial> ^ wonder how i missed those two [23:13] <jamrial> michaelni: is "[PATCH] Adds support for setting aq_mode in libvpx encoder" ok to apply? James Zern hasn't commented yet [23:18] <michaelni> jamrial, if you are sure they are ok sure apply, otherwise ask james zern [00:00] --- Thu Aug 28 2014