[00:30] <cone-851> ffmpeg.git 03Timothy Gu 07master:b9bedb0b287d: avcodec/dnxhdenc: return meaningful return codes [00:44] <kierank> is there any way of dumping intra prediction mode? [00:54] <kierank> first analyser I download is a GPL violation... [01:00] <Compn> intra prediction [01:00] <Compn> humm [01:00] <Compn> no idea [01:12] <BBB> kierank: add printfs to ffmpeg decoder (it's what I typically do) [01:12] <BBB> unless I'm debugging ffmpeg mismatches, then I'm adding printfs to the reference decoder [01:13] <kierank> BBB: The analyser I reported for being a violation did it [01:14] <BBB> I like codecvisa, nice product [01:14] <BBB> supports vp8/9 also, useful [05:04] <cone-465> ffmpeg.git 03Michael Niedermayer 07master:8893f31e2063: avcodec/mjpegdec: update cur_scan also for non-LS jpeg [05:04] <cone-465> ffmpeg.git 03Michael Niedermayer 07master:361e27a3d809: avcodec/mjpegdec: only run EOI emulation code when there was a scan [05:04] <cone-465> ffmpeg.git 03Michael Niedermayer 07master:31e703e899be: avcodec/mjpegdec: Dont treat the lack of a startcode differently from end of the bitstream [06:41] <cone-465> ffmpeg.git 03Michael Niedermayer 07master:676a395ab903: avcodec/aacdec: Dont fail if channels arent known yet [10:38] <ubitux> https://commons.wikimedia.org/wiki/Commons:Requests_for_comment/MP4_Video [10:40] <nevcairiel> I always feel sad when people assert MP4 == AVC [10:41] <ubitux> :) [10:42] <nevcairiel> MPEG4pt2 is also part of the whole MPEG4 pool of things! [12:21] <cone-673> ffmpeg.git 03Stefano Sabatini 07master:3dc494f8b94b: lavfi/vidstabtransform: apply various documentation/option minor fixes [12:21] <cone-673> ffmpeg.git 03Stefano Sabatini 07master:529573591a48: doc/muxers/segment: fix formula for computing the segment_time_delta value [12:40] <j-b> 'morning [13:30] <ubitux> http://jeremykun.com/2013/12/30/the-two-dimensional-fourier-transform-and-di... [13:42] <cone-673> ffmpeg.git 03Timothy Gu 07master:093439b4818d: doc/encoders: add libx264rgb doc and supported pixfmts for libx264(rgb) [13:42] <cone-673> ffmpeg.git 03Timothy Gu 07master:560724215593: doc/muxers: add "Options", "Examples", "Syntax", etc. subsections [14:02] Action: BBB pets j-b [14:43] <Compn> ubitux : is that a fft speedup ? [14:43] <Compn> i dont see benchmarks :P [14:44] <Compn> if it is a speedup, someone should forward it to fabrice [15:00] <cone-673> ffmpeg.git 03Michael Niedermayer 07release/1.1:3ae81880e1ea: avcodec/mjpegdec: update cur_scan also for non-LS jpeg [15:00] <cone-673> ffmpeg.git 03Michael Niedermayer 07release/1.1:55a4228ac2ee: avcodec/mjpegdec: only run EOI emulation code when there was a scan [15:00] <cone-673> ffmpeg.git 03Michael Niedermayer 07release/1.1:bb26a88193d9: avcodec/mjpegdec: Dont treat the lack of a startcode differently from end of the bitstream [15:00] <cone-673> ffmpeg.git 03Michael Niedermayer 07release/1.1:6fa97413578e: avcodec/aacdec: Dont fail if channels arent known yet [15:00] <cone-673> ffmpeg.git 03Michael Niedermayer 07release/1.2:67d20495f592: avcodec/mjpegdec: update cur_scan also for non-LS jpeg [15:00] <cone-673> ffmpeg.git 03Michael Niedermayer 07release/1.2:d81ccf1fb229: avcodec/mjpegdec: only run EOI emulation code when there was a scan [15:00] <cone-673> ffmpeg.git 03Michael Niedermayer 07release/1.2:bd29764c6177: avcodec/aacdec: Dont fail if channels arent known yet [15:00] <cone-673> ffmpeg.git 03Michael Niedermayer 07release/1.2:f0fabcc6ed0d: avcodec/mjpegdec: Dont treat the lack of a startcode differently from end of the bitstream [15:00] <cone-673> ffmpeg.git 03Carl Eugen Hoyos 07release/2.1:f4e051680ec3: Fix libxvid crash on failing initialisation. [15:00] <cone-673> ffmpeg.git 03Michael Niedermayer 07release/2.1:2c5c6affb1c3: avcodec/mjpegdec: update cur_scan also for non-LS jpeg [15:00] <cone-673> ffmpeg.git 03Michael Niedermayer 07release/2.1:83dc8f044d66: avcodec/mjpegdec: only run EOI emulation code when there was a scan [15:00] <cone-673> ffmpeg.git 03Michael Niedermayer 07release/2.1:756cd1a305d2: avcodec/mjpegdec: Dont treat the lack of a startcode differently from end of the bitstream [15:00] <cone-673> ffmpeg.git 03Michael Niedermayer 07release/2.1:9d83cff1f117: avcodec/aacdec: Dont fail if channels arent known yet [17:35] <cone-673> ffmpeg.git 03Michael Niedermayer 07master:ad8d063f230c: avcodec/mjpegdec: Dont skip picture allocation if theres no picture allocated [17:57] <cone-673> ffmpeg.git 03Nicolas George 07master:3532dd52c51f: lavu/rational: add syntactic sugar. [17:57] <cone-673> ffmpeg.git 03Nicolas George 07master:bf9908c62746: lavfi/af_amerge: use av_make_q. [17:57] <cone-673> ffmpeg.git 03Nicolas George 07master:c4b7ad324b04: lavfi/avf_concat: use av_make_q. [17:57] <cone-673> ffmpeg.git 03Nicolas George 07master:77b8d4e52130: lavfi/vf_tile: use av_make_q. [17:57] <cone-673> ffmpeg.git 03Nicolas George 07master:2dc5980d6149: lavfi/dualinput: fix shortest option. [17:57] <cone-673> ffmpeg.git 03Michael Niedermayer 07master:0500623d5840: Merge remote-tracking branch 'cigaes/master' [18:19] <ubitux> 17:19:34 <+smarter> ubitux: I think you had a branch with all the changes made in libav but not in ffmpeg? [18:19] <ubitux> 17:19:43 <+smarter> (for vp9) [18:19] <ubitux> yes but we merged all the relevant stuff [18:19] <ubitux> we didn't merge the cosmetics though [18:20] <ubitux> smarter: btw, we are faster than libvpx [18:20] <smarter> ubitux: yes, but the version in libav doesn't have all the new asm :/ [18:21] <ubitux> it lacks quite a bunch of fixes too [18:21] <ubitux> and there is not only the new asm [18:21] <smarter> yes, that's what I was complaining about in the #libav-devel [18:21] <ubitux> they also introduced specific bugs btw but well... [18:21] <smarter> yes, I found one [18:22] <smarter> that's what I was wondering if you still had that branch so that I could find others [18:22] <smarter> *why [18:22] <ubitux> ah, no, sorry i deleted it [18:22] <ubitux> since it was not relevant anymore...... [18:23] <ubitux> oups key repeat [18:24] <smarter> :/ [18:29] <wm4> smarter: the cheapest way seems to be copying all vp9 related source files to libav and making a patch out of that [18:31] <ubitux> wm4: you can't really do that [18:31] <smarter> libav splitted vp9.c into a bunch of files [18:31] <smarter> so now you can't cherry-pick anything [18:31] <ubitux> they split the files, really added cosmetics all over the place [18:31] <ubitux> it took me about 3 days to extract all the changes [18:31] <wm4> ugh [18:32] <ubitux> they renamed variables randomly too [18:32] <wm4> "let's do cosmetic on code that we didn't write, and then be stuck with not being able to merge back changes from the original author" [18:33] <ubitux> they renamed a function wrongly btw, that was funny :x [18:34] <ubitux> wm4: maybe they thought we'd merge their irrelevant changes, which we actually didn't for once [18:36] <ubitux> smarter: maybe they still have the history of their changes hidden somewhere, ask them [18:36] <smarter> probably got squashed away [18:40] <ubitux> of av_make_q [18:40] <ubitux> that is cool. [18:42] <ubitux> s/of/oh/ [18:47] <BBB> I asked for their history [18:47] <BBB> I got an answer from one of their developers in private who gave me specific patches contributed by him alone, and the others wouldn't talk to me [18:48] <BBB> so there was good, there was bad [18:48] <BBB> nothing new [18:48] <BBB> smarter: how's ffhevc performance faring btw? [18:48] <BBB> smarter: haven't exactly followed it, but I was intending to look at that at some point in the future, given that hevc will probably become relevant at some point in the future [18:49] <smarter> some people are working on MC asm: https://github.com/organizations/OpenHEVC [18:49] <BBB> oh cool [18:50] <smarter> I'm currently reviewing the deblocking asm someone wrote, and once that's done I'll probably try to write asm for the other loop filter (Sampled Adaptive Offset) [18:50] <BBB> which branch and which tree? [18:50] <smarter> https://github.com/OpenHEVC/openHEVC/tree/hevc [18:50] <smarter> it's confusing because they also have intrinsics (that they're planning to convert to asm) [18:51] <smarter> I think no one is working on transform asm [18:51] <BBB> oh god intrinsics [18:51] <BBB> ah there actual asm [18:52] <smarter> ask plepere about all that stuff :) [18:52] <BBB> he wrote the intrinsics, or the asm? [18:52] <BBB> I mean the asm looks kinda weird [18:53] <smarter> both [18:54] <BBB> I guess it combines 8bit and 10bit asm which is kinda weird [19:12] <BBB> anyway [19:12] <ubitux> smarter: about Anton's comment, fate coverage is different in FFmpeg btw [19:13] <BBB> any speed numbers on their vs. our asm performance? [19:13] <smarter> ubitux: you have more samples? [19:13] <ubitux> yes [19:13] <BBB> oh that bug was still there? [19:13] <BBB> I pointed it out specifically to them [19:13] <BBB> weird [19:14] Action: BBB goes back to doing useful stuff [19:14] <smarter> BBB: you mean, hevc vs vp9 speed? [19:15] <BBB> yeah [19:16] <BBB> I know it's a little far-fetched as a simple question, but wouldn't that be an amazing question to try and answer at various levels? [19:16] <smarter> vp9 is probably much faster [19:16] <BBB> consider that we have full control over both codebases and we can probably share some code here and there [19:16] <smarter> I see, yes :) [19:16] <BBB> so this should be good for both [19:17] <smarter> ubitux: it seems there's the same number of files when I do ls tests/ref/fate/vp9-* for ffmpeg and libav [19:19] <ubitux> smarter: try a diff between the two vpx.mak [19:28] <smarter> got it, thanks [19:29] <BBB> poor smarter, backporting fixes? [19:29] <nevcairiel> its funnier then that, fixing issues they introduced in their "style" cleanup :p [19:30] <smarter> I backported a few things, we'll see if this piss me off enough to do more [19:30] <ubitux> smarter: i have a lot of more funny tasks to suggest if you're bored ;) [19:30] <smarter> I do work on other stuff too :) [19:31] <smarter> ubitux: what do you have in mind? [19:31] <cone-673> ffmpeg.git 03Michael Niedermayer 07master:5800b08572ef: avformat/matroskadec: support SVQ3 as generated by mkvtoolnix-6.6.0 [19:31] <cone-673> ffmpeg.git 03Michael Niedermayer 07master:48218580e1ec: avformat/matroskadec: support QDM2 as generated by mkvtoolnix-6.7.0 [19:38] <ubitux> smarter: filters! [19:39] <ubitux> subtitles! [19:39] <ubitux> ah, no [19:39] <ubitux> that one is not fun [19:39] <ubitux> a lot of filters could get some asm and various optims [19:40] <ubitux> ...also, a bunch of useful filters could be written [19:41] <smarter> like what? [19:41] Action: smarter never even used libavfilter [19:42] <ubitux> a real fps filter [19:42] <ubitux> wit frame interpolation so we can have slowmo [19:42] <ubitux> with* [19:42] <smarter> fun [19:42] <ubitux> about optimizations in current filters... fieldmatch, dctdnoiz, ... [19:43] <ubitux> maybe add gpu support in lut3d filter [19:43] <smarter> I wonder if motion vectors would help for interpolating frames [19:44] <ubitux> if you plan to reuse codecs mv, they're mostly designed for codecs efficiency, i doubt it will be useful in filters [19:44] <ubitux> contrary to codecs, a bunch of filters could benefit from the gpu [19:45] <ubitux> anyway, lots of fun in that area [19:45] <smarter> are there existing filters which use the gpu? [19:45] <ubitux> opencl is integrated with a few ones [19:45] <ubitux> but they're mostly useless [19:45] <JEEB> it's unfortunately not simple to make a useful GPU-using thingamajig [19:46] <smarter> doesn't stop people from trying :p [19:46] <JEEB> indeed [19:47] <JEEB> and thus lots of papers are written [19:47] <smarter> in the video you linked the other day, the x265 guy mentioned using GPUs [19:47] <wm4> michaelni: would it be possible to export ff_codec_movvideo_tags and ff_codec_movaudio_tags? [19:47] <smarter> probably just a buzzword [19:48] <wm4> michaelni: would it be possible to export ff_codec_movvideo_tags and ff_codec_movaudio_tags? [19:48] <wm4> oops [19:51] <michaelni> wm4, yes it would be possible [19:51] <michaelni> do you want to send a patch ? [19:52] <wm4> yes [19:54] <michaelni> see avformat_get_riff_video_tags() / avformat_get_riff_audio_tags() but you probably already know/found them [19:55] <wm4> yes [19:55] <BBB> smarter: yes it's a buzzword, it's been talked about for 10 years now [19:56] <BBB> smarter: but yes it'd be much more fun and useful if you wrote new stuff rather than port existing stuff from a to b [19:57] <BBB> smarter: like, you could help get ffhevc in a state where it's mega-fast and the obvious counterpart of whatever the default encoder will be for 265 (likely x265?) [19:57] <BBB> smarter: maybe help get daala moving into a useful direction [19:57] <BBB> smarter: help write vp9 simd if you want [19:57] <BBB> (write, not port) [19:57] <nevcairiel> JEEB: did you see AMDs claim to build a h265 decoder based on their HSA infrastructure? [19:58] <ubitux> on a side note, i saw a guy working on a hw implem of daala [19:58] <BBB> yeah I saw that [19:58] <ubitux> that's pretty nice to see that at such early stage [20:02] <smarter> BBB: yes, I have things I want to do for hevc, vp9 and daala :] [20:02] <smarter> and I don't plan to spend too much time porting stuff, that'd be boring :p [20:02] <BBB> yay [20:02] <BBB> ok good then [20:03] <BBB> as long as it's fun [20:03] <BBB> I'd like to try daala at some point, I'm still thinking of what to do after ffvp9 is ""done"", daala or hevc? [20:03] <ubitux> daala is probably more interesting [20:03] <ubitux> from a learning experience PoV [20:08] <BBB> I'm more thinking about impact [20:08] <BBB> how_much_impact_can_I_have_on_the_project * how_big_will_project_impact_the_world = my_impact_on_the_world [20:08] <BBB> (both in a [0.0, 1.0] range) [20:09] <ubitux> i guess i'm way too egocentric to have such perspective ;) [20:09] <BBB> that's fair, we all have different ideals and ideas [20:12] <JEEB> nevcairiel, no I didn't. But I wouldn't be surprised if it just ends up being an ASIC via Yet Another API :D [20:12] <nevcairiel> hevc is quite likely to be the next h264, so from impact... [20:12] <nevcairiel> JEEB: nah AMD sucks at building decoding ASICs [20:12] <JEEB> oh I know that [20:13] <JEEB> anyways, so far AMD has touted their heterogenous stuff with everything that uses GPGPU [20:13] <JEEB> ...or the stuff on the GPU in general [20:14] <Mavrik> while we're at it... does nVidia have an API for their HW encoders? [20:14] <nevcairiel> sure [20:14] <JEEB> yup [20:14] <JEEB> I remember us having a laugh at the low-latency API looking like the x264 one :) [20:14] <smarter> btw, any news on http://www.amd.com/us/products/technologies/mantle/pages/mantle.aspx ? [20:15] <JEEB> @ #x264dev [20:15] <JEEB> smarter, nothing actually worthwhile [20:15] <JEEB> marketing talk mostly [20:15] <smarter> the description on that page is fantastic :p [20:15] <smarter> it says nothing with a lot of words [20:15] <JEEB> yes [20:16] <Mavrik> yep :D [20:19] <{V}> BBB, I think the daala project had a planning session recently, if you're interested https://daala.etherpad.mozilla.org/daala-plan-2014 [20:21] <cone-673> ffmpeg.git 03Michael Niedermayer 07master:9d13432a9097: avformat/matroskadec: identify SMI as SVQ3 [20:34] <Compn> nvidia and amd should have built bitcoin mining hardware :P [20:34] <Compn> ehe [20:34] <BBB> {V}: ty [20:35] <Daemon404> daala is doing interesting things [20:36] <Daemon404> i am still skeptical if lapped dct and frequency-domain prediction will work out [20:36] <Daemon404> with their special OBMC etc [21:36] <cone-673> ffmpeg.git 03Tim Walker 07master:1f604f96ea70: ac3: set default matrix encoding modes in parse_frame_header. [21:36] <cone-673> ffmpeg.git 03Michael Niedermayer 07master:c3d121568394: Merge commit '1f604f96ea70503caa642f68a85be6074a5b3f46' [21:46] <cone-673> ffmpeg.git 03Tim Walker 07master:c229f571fd3c: (e)ac3: parse and store the Lt/Rt and LFE mix levels. [21:46] <cone-673> ffmpeg.git 03Michael Niedermayer 07master:3a5a039adee3: Merge commit 'c229f571fd3c7d7b567c27c87b2bbcdaee1b0e9f' [21:53] <cone-673> ffmpeg.git 03Tim Walker 07master:ade75fb81150: (e)ac3: clip surround mix level indexes. [21:53] <cone-673> ffmpeg.git 03Michael Niedermayer 07master:10f1ee2f923a: Merge commit 'ade75fb811500f3e3f284737f123938d83be728f' [21:58] <cone-673> ffmpeg.git 03Tim Walker 07master:0d43b114ccba: eac3: cosmetics, re-indent. [21:58] <cone-673> ffmpeg.git 03Michael Niedermayer 07master:fde2afd9fb6e: Merge remote-tracking branch 'qatar/master' [22:26] <cone-673> ffmpeg.git 03wm4 07master:1a193c438c9b: lavf: add avformat_get_mov_video_tags() and avformat_get_mov_audio_tags() [22:27] <nevcairiel> wm4: another function you cant really use without shooting some distros in the foot? :p [22:27] <wm4> yes [22:27] <wm4> and I'll conveniently put the blame on Libav [22:28] <wm4> what I really should do is getting rid of my matroska demuxer, and make libavformat export the ordered chapter data structures, but that sounds like such a pain [22:29] <Compn> do it [22:29] Last message repeated 1 time(s). [22:29] <nevcairiel> I considered that [22:29] <nevcairiel> instead, i wrote a new demuxer [22:29] <Compn> psh [22:29] <nevcairiel> take away from that what you want [22:29] <nevcairiel> :D [22:29] <wm4> oops [22:29] <Compn> you guys always write your own wheels [22:29] <wm4> a new new demuxer, or that haali thing? [22:29] <JEEB> haali-based [22:29] <JEEB> put into avformat [22:29] <nevcairiel> more like hacked into avformat [22:30] <wm4> yeah, and last I heard it can't be easily merged into upstream libavformat [22:30] <nevcairiel> i would've kept it outside and just registered it with avformat, but somehow all the options to register external components disappeared over time [22:30] <wm4> a bit unfortunate [22:30] <wm4> heh [22:30] <ubitux> mkv improvements would be so much welcome :P [22:31] <nevcairiel> the nice thing about using a demuxer library inside a demuxer is, you can easily create multiple instances of the library-demuxer inside your demuxer to handle multiple files :d [22:32] <nevcairiel> in any case i dont plan to implement these weird mkv features again in a "native" demuxer, its just too much pain [22:32] <nevcairiel> (and for me it works quite nicely at the moment!) [22:33] <cone-673> ffmpeg.git 03Peter Ross 07master:f29cdbe1b59a: vp8: remove redundant "equals 1" test [00:00] --- Mon Jan 20 2014