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

[burek]

[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