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

[burek]

[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-digital-watermarking/
[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