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

[burek]

[00:49:50 CEST] <Zeranoe> If I remember correctly, FFmpeg supports OpenJPEG 2.x ?
[00:51:56 CEST] <cone-619> ffmpeg 03Christophe Gisquet 07master:e3242c021980: dnxhddata: deduplicate table
[00:58:07 CEST] <Compn> Zeranoe : i remember reading something about openjpeg support, but i cannot confirm
[00:58:33 CEST] <Compn> Zeranoe : https://trac.ffmpeg.org/ticket/2016
[00:59:10 CEST] <Compn> https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=1847
[00:59:46 CEST] <Zeranoe> Huh, seems like this Zeranoe person should know ;)
[01:01:01 CEST] <Compn> yeah, if only we could find that person
[01:01:46 CEST] <Zeranoe> I'll update on the Windows builds. Working on 2.8 builds now
[02:39:55 CEST] <RiCON> Zeranoe: openjpeg 2.0 supports needs a different openjpeg.h than the one that gets installed 
[02:41:27 CEST] <RiCON> the one that gets installed is src/lib/openjp2/openjpeg.h and ffmpeg needs src/lib/openmj2/openjpeg.h, iirc
[05:07:18 CEST] <cone-619> ffmpeg 03Shawn Singh 07master:733475160a0a: libavformat/mov.c: Add parsing for DDTS atom for DTS audio
[06:25:01 CEST] <cone-619> ffmpeg 03Matt Oliver 07master:ae58abeabbfc: compat/w32pthreads: Add return values to match the simulated pthread functions.
[06:25:02 CEST] <cone-619> ffmpeg 03Matt Oliver 07master:3b03bde46e33: avformat/async: Allow compilation with native threads.
[08:02:31 CEST] <cone-619> ffmpeg 03James Almer 07master:3178931a14f5: x86/hevc_sao: move 10/12bit functions into a separate file
[08:44:21 CEST] <ubitux> http://i.imgur.com/HkrJr70.png  some old hacks in ffmpeg
[09:10:39 CEST] <durandal_1707> old hacks?
[09:11:39 CEST] <durandal_1707> what hacks?
[09:12:51 CEST] <ubitux> it's a joke :(
[09:27:51 CEST] <thardin_> cargo culting
[10:08:55 CEST] <roxlu> hey, I asked this in #ffmpeg too, but I'm not sure if that's the right place. I heard that ffmpeg has support for VideoToolbox on Mac, but do I need to pass any special flags to ffmpeg when I want to decode a h264 stream ? 
[10:09:43 CEST] <nevcairiel> -hwaccel videotoolbox
[10:09:52 CEST] <nevcairiel> and you should stay in #ffmpeg with usage questions
[10:27:48 CEST] <roxlu> There seems to be an issue with the decoder configuration record that is passed into the VT decoder. It fails to create the decoder instance. When I use the CMVideoFormatDescriptionCreateFromH264ParameterSets function it does create the decoder w/o error.
[13:03:40 CEST] <cone-547> ffmpeg 03Paul B Mahol 07master:6ce02126cec5: avfilter/af_rubberband: flush only if there is something available
[15:06:02 CEST] <BBB> Gramner: do you want to review my assembly? :D
[15:06:56 CEST] <BBB> Gramner: its only 3 of them (loopfilter, dc/tm/h/v intrapred asm, and filtered directional intrapred asm), all for 10/12bpp vp9
[15:08:07 CEST] <BBB> kierank: can I take obe2ng for a few minutes to test my patch on something with actual avx?
[15:08:43 CEST] <kierank> yes, killed the fuzzing
[15:09:03 CEST] <BBB> kierank: ty! I wont be long
[15:09:06 CEST] <BBB> are the fate samples somewhere?
[15:10:39 CEST] <kierank> no
[15:11:16 CEST] <kierank> rsync them and I'll move them to /usr/share/fate/
[15:11:25 CEST] <kierank> bbiab
[15:11:40 CEST] <BBB> ty
[15:18:55 CEST] <BBB> kierank: I cant seem to build 32bit binaries, is there something missing for that?
[15:31:56 CEST] <kierank> BBB: fixing
[15:32:01 CEST] <BBB> ty!
[15:53:49 CEST] <kierank> BBB: i think ok now
[15:55:17 CEST] <BBB> how do I build using it? Im using extra-cflags=-m32 extra-libs=-m32 and that doesnt work :(
[15:56:09 CEST] <Daemon404> that should be extra-ldflags
[15:56:49 CEST] <BBB> nope, same problem
[15:56:57 CEST] <BBB> I think libc-dev for 32bit is still missing, or so
[15:58:05 CEST] <cone-547> ffmpeg 03wm4 07master:cb1da9fb8d71: avcodec/mp3: fix skipping zeros
[15:58:32 CEST] <kierank> BBB: installing
[15:58:40 CEST] <kierank> I thought ia32-libs was enough
[15:58:41 CEST] <kierank> apparently not
[15:58:50 CEST] <BBB> thanks
[15:58:55 CEST] <BBB> rry to be a pain
[15:59:03 CEST] <BBB> +so
[16:32:50 CEST] <Gramner> BBB: I'll try to look at your patches if I have time
[16:34:59 CEST] <BBB> ty
[16:51:13 CEST] <durandal_1707> nevcairiel: do you have link/sample for that assert?
[17:18:23 CEST] <nevcairiel> durandal_1707: like i said, it happens with API usage in a live tv scenario, i cannot really produce a test case
[17:21:42 CEST] <nevcairiel> and I honestly don't care to argue. The check for the chroma_format is quite new and introduced a regression which triggers an abort, which is the worst kind of thing that can happen when using an API. Don't want to fix it, fine
[17:22:34 CEST] <durandal_1707> nevcairiel: what live tv? What API?
[17:22:43 CEST] <nevcairiel> avcodec API, duh
[17:23:41 CEST] <durandal_1707> I want it fixed, but what code that use lavc api?
[17:39:20 CEST] <ubitux> what's the state of image3?
[17:40:10 CEST] <durandal_1707> what?
[17:40:55 CEST] <ubitux> my bad, we have the probers now
[17:41:01 CEST] <nevcairiel> didnt someone shoehorn the format detection onto image2 so image3 was unnecessary
[17:41:16 CEST] <ubitux> yeah, we're just actually missing a jpeg prober it seems
[17:42:00 CEST] <nevcairiel> seems to exist here
[17:42:10 CEST] <nevcairiel> jpeg_probe in img2dec.c
[17:42:27 CEST] <nevcairiel> but its somewhat weird code, so maybe its not really that reliable
[17:42:38 CEST] <ubitux> meh. why isn't it called then mmh
[17:44:15 CEST] <ubitux> oh, ok, i get it
[17:44:22 CEST] <ubitux> i need the _pipe demuxers.
[17:45:57 CEST] <nevcairiel> the name is a bit confusing, but yeah
[17:46:41 CEST] <nevcairiel> the non-pipe variant would open its own files and stuff, which you dont w ant if you're probing an existing file
[17:48:54 CEST] <ubitux> yeah indeed, thanks and sorry for the noise :)
[17:50:52 CEST] <Gramner> BBB: doing good asm patch review is really hard though. I usually just end up looking at local parts individually which might miss "overall design issues", but doing it thoroughly takes likes 10x the time and that would just result in nothing getting reviewed instead
[18:47:43 CEST] <wm4> so I'm looking at videotoolbox failing on .ts
[18:48:04 CEST] <wm4> seems like videotoolbox (the API) wants mp4-style data
[18:48:34 CEST] <wm4> so if you have annex b, you need to parse the packets and extract pps/sps etc. and reconstruct mp4 extradata
[18:48:55 CEST] <wm4> it appears libavformat has code for this in ff_isom_write_avcc
[18:49:18 CEST] <nevcairiel> you need actually mp4 extradata?
[18:49:26 CEST] <nevcairiel> well apple apis
[18:49:29 CEST] <wm4> all signs point to it
[18:49:30 CEST] <nevcairiel> different for the sake
[18:49:55 CEST] <wm4> I'm not really sure how to get the packet data... or would it be better to reconstruct the extradata from the already parsed data?
[18:50:08 CEST] <wm4> (probably not)
[18:51:07 CEST] <rcombs> does it actually need extradata, or can you just pass pps/sps in the mp4-formatted bitstream?
[18:51:49 CEST] <wm4> I think it wants a avcc mp4 atom on decoder creation
[18:52:34 CEST] <wm4> or the contents of that atom, so pretty much the extradata
[18:57:40 CEST] <BBB> Gramner: Im well aware of it ;)
[18:57:49 CEST] <BBB> Gramner: guess why nobodys reviewing these largish patches :)
[19:04:01 CEST] <wm4> what's with libavformat/utils.c's attempt to extract sps/pps to extradata? that looks weird
[19:09:38 CEST] <BBB> wm4: I bet you it fixes a sample!
[19:09:48 CEST] <BBB> isnt that our fifth sps/pps parser in the codebase?
[19:09:50 CEST] <BBB> how embarassing
[19:09:56 CEST] <wm4> thinking of using it (it should have all what's needed)
[19:38:27 CEST] <jamrial> BBB: there's a new intel sde version out. works on Win10 and kernel 4.x
[19:38:34 CEST] <jamrial> it of course wont work for benchmarking but it's enough to check for correctness
[19:38:40 CEST] <BBB> I dont want intel sdk, I want a new machine :-p
[19:39:03 CEST] <jamrial> so do i, but it's a start :p
[19:41:36 CEST] <Gramner> using the sde to write asm is horrible, you have no idea if your code is actually useful or not without running it on a real machine
[19:42:20 CEST] <Gramner> and you kinda want to develop it on a real machine so you can try different stuff as you go to see how it affects performance
[19:43:42 CEST] <jamrial> of course, but for simple changes (where you're not using cross-lane instructions and are simply taking advantage of the wider regs), it at least lets you know if it works
[19:45:52 CEST] <Gramner> there are few truly simple changes though, there's usually at least optional shuffling possible that may or may not improve performance
[19:53:05 CEST] <Gramner> when writing code for unreleased µarchs there's also the added bonus of not having any documentation available so you don't even know if a particular instruction has good latency and/or thorughput
[19:53:29 CEST] <Gramner> but that might not be relevant here i guess
[20:00:19 CEST] <BBB> jamrial: if we keep being ok with just writing it for a sdk, intel will never give us a new machine for free
[20:00:48 CEST] <BBB> jamrial: the correct answer is intel wants ffmpeg to have avx2 so they can sell new machines to google/whatever; thus, intel should give us new machines for free"
[20:01:04 CEST] <fritsch> hehe
[20:01:08 CEST] <Gramner> did you ask them?
[20:01:12 CEST] <jamrial> never said i was ok with it. i said it's enough to check correctness
[20:02:03 CEST] <fritsch> scalability and performance comparison needs to be done on real hardware :-)
[20:02:07 CEST] <JEEB> <@BBB> if we keep being ok with just writing it for a sdk, intel will never give us a new machine for free <@BBB> the correct answer is intel wants ffmpeg to have avx2 so they can sell new machines to google/whatever; thus, intel should give us new machines for free"
[20:02:20 CEST] <durandal_1707> is it ok to have anaglyphs for yuv?
[20:02:25 CEST] <JEEB> welp
[20:02:33 CEST] <JEEB> that is one copypasta fail
[20:02:48 CEST] <BBB> probably :-p
[20:02:57 CEST] <JEEB> yes, do excuse me
[20:03:01 CEST] <BBB> Gramner: not yet, Im waiting for the new macbook pro to come out with skylake
[20:03:25 CEST] <rcombs> BBB: ditto
[20:04:49 CEST] <BBB> rcombs: another maccie here?
[20:04:56 CEST] <BBB> \o/ I M NOT ALONE!!!
[20:05:17 CEST] <rcombs> \o/
[20:06:09 CEST] <durandal_1707> huh, when it become possible to get free hw?
[20:06:53 CEST] <rcombs> hey, Apple TV devkits are $1
[20:07:46 CEST] <durandal_1707> I don't need those
[20:08:39 CEST] <rcombs> well it's _somebody_ giving out _almost_-free hardware
[20:09:35 CEST] <durandal_1707> that's not expensive hw
[20:09:44 CEST] <rcombs> true
[20:15:33 CEST] <Gramner> it's cost efficient for a large hw manufactoring company to give away hardware in exchange for software being optimized for their hardware. if that optimization results in some benchmark getting a higher score in a review that can increase sales, and even a tiny tiny increase in sales will make it a worthwhile investment
[20:26:09 CEST] <rcombs> specifically, if they sell at least <units given away> * <mfg cost> / <wholesale price> additional
[20:28:34 CEST] <wm4> hm, after going through miserable hacks, it seems to work now
[20:28:55 CEST] <wm4> the problem is that the libavformat code uses a memory AVIOContext to get an appendable buffer
[20:29:06 CEST] <wm4> and also libavformat symbols can't be used from libavcodec
[20:29:07 CEST] <wm4> sigh
[20:34:22 CEST] <durandal_1707> should I write voice decoder nobody use?
[20:40:18 CEST] <Vgubbala> Anyone help me to build FFMpeg 2.8 for android?
[20:44:49 CEST] <wm4> Vgubbala: no
[20:45:05 CEST] <wm4> this is offtopic here
[20:45:13 CEST] <wm4> go to #ffmpeg
[20:45:56 CEST] <Vgubbala> wm4: ok 
[21:01:54 CEST] <BBB> durandal_1707: dont we already have 10 voice decoders nobody uses? :-p
[21:02:02 CEST] <BBB> I think wrote one
[21:02:05 CEST] <BBB> *I
[21:02:27 CEST] <BBB> Gramner: ok Ill unpair it, I always thought itd make it better on some cpus (maybe thats 10yrs ago wisdom)
[21:02:33 CEST] <BBB> Gramner: and thnx for review
[21:04:21 CEST] <Gramner> any x86 without ooe is going to be way to slow to deal with vp9 content in any reasonable framerate and/or resolution anyway, so it's not really much of an issue
[21:04:57 CEST] <Gramner> and such cpus might only have one vector execution unit anyway (don't quote me on that though)
[21:06:34 CEST] <BBB> kierank: can I also get gdb or lldb?
[21:16:33 CEST] <DHE> I've covered all the suggestions for my a53 closed captions patch, is there anything else I need to do with it?
[21:16:56 CEST] <wm4> did you sent it again?
[21:17:00 CEST] <wm4> *send
[21:22:41 CEST] <jamrial> he did
[21:23:51 CEST] <wm4> hm, personally I'd say the muxer code should remove the CC data if it should not be written
[21:24:13 CEST] <wm4> so "a53cc" would be a ffmpeg.c option
[21:24:33 CEST] <wm4> (but I don't insist on it or anything)
[21:25:02 CEST] <wm4> DHE: just wait until one of the devs say ok and merge it
[21:34:19 CEST] <durandal_1707> I have idea for process_command replacement
[21:35:40 CEST] <wm4> let's hear it
[21:45:58 CEST] <durandal_1707> add flag to opts that option can be set during runtime
[21:47:41 CEST] <durandal_1707> BBB: so you will help me writting simd for maskedmerge if I write boilerplate code?
[21:48:07 CEST] <BBB> help, yes, but not write it for you
[21:48:16 CEST] <BBB> you will do the writing, I will help you figure out which instruction to use for what
[21:49:36 CEST] <wm4> durandal_1707: sounds like a good start
[21:51:29 CEST] <DHE> wm4: the data goes into the video codec itself. it must be part of libx264. it's not a distinct stream
[21:52:09 CEST] <wm4> DHE: I know, but ffmpeg.c could remove the side data if CCs are unwanted
[21:53:00 CEST] <BBB> awh crap win64 exsits also
[21:53:21 CEST] <DHE> as for merging it, I don't have commit access. and I don't see myself making enough patches to warrant receiving it. this is my first
[21:56:04 CEST] <jamrial> DHE: whoever oks it (anshul proably, he already kinda did after all) will do it
[21:56:30 CEST] <DHE> yeah we've spoken in IRC briefly
[21:57:07 CEST] <durandal_1707> BBB: is it ok to have AVFrames as args in yasm?
[21:57:27 CEST] <BBB> well, theoretically its possible, I wouldnt recommend it
[21:57:31 CEST] <wm4> DHE: usually those who reviewed the patch will apply it
[21:57:44 CEST] <BBB> yasm is easiest with plain c types, e.g. pointers, ptrdiff_t/int, etc.
[21:58:52 CEST] <kurosu> it's generally easier to the struct handling in the C code than try to do it in asm
[21:59:56 CEST] <kurosu> *to do the
[22:12:34 CEST] <J_Darnley> If you know how C is supposed to arrange a struct then it shouldn't be too hard to do in assembly (just offsets from the pointer)...
[22:13:00 CEST] <BBB> J_Darnley: right, we do that in various places (e.g. fft)
[22:13:01 CEST] <J_Darnley> but I was underthe impression that it was almost arbitrary
[22:13:06 CEST] <BBB> J_Darnley: its just a pretty big maintenance burden
[22:13:20 CEST] <BBB> J_Darnley: so we prefer to keep asm struct-free where it doesnt have a relevant performance impact
[22:13:26 CEST] <BBB> which is pretty much always
[22:14:13 CEST] Action: J_Darnley nods.
[22:14:43 CEST] <nevcairiel> structs like that in ASM are usually extremely annoying
[22:14:53 CEST] <nevcairiel> because any ABI change breaks your ASM usually
[22:15:23 CEST] <J_Darnley> I haven't actually seen where it is used but where ever I have used assembly there has been a clear need for some C code to do various things before my "DSP" function.
[22:15:39 CEST] <cone-724> ffmpeg 03Michael Niedermayer 07master:9b4dd0f87696: avcodec/mpeg12dec: Initialize chroma_format to 1
[22:17:34 CEST] <kurosu> that and if you happen to have elements whose size changes or that are affected by struct padding between your arrays, then it's actually an x86 ABI nightmare too
[22:18:35 CEST] <J_Darnley> If there are compiler flags that can control that padding I'm sure some power user will use them.
[22:19:08 CEST] <kurosu> an example is some asm you worked on (some audio lossless codec iirc)
[22:19:22 CEST] <Gramner> it's generally a good idea to only offload SIMD stuff to asm and do as much scalar stuff as possible in c since the latter is hard to gain any meaningful performance improvement from in asm (exceptions exists of course, but in general)
[22:19:25 CEST] <J_Darnley> Oh, yes, flac
[22:19:45 CEST] <kurosu> it works by treating it as an array, but if the array size changes or something, it may causes unaligned access with mova (iirc)
[22:20:06 CEST] <kurosu> maybe the code has changed since then though
[22:28:32 CEST] <cone-724> ffmpeg 03Paul B Mahol 07master:1da1574002e3: avfilter/vf_maskedmerge: rewrite and remove some duplicated code
[22:34:56 CEST] <kierank> BBB: fixed
[22:35:04 CEST] <BBB> ty!
[22:37:56 CEST] <cone-724> ffmpeg 03Paul B Mahol 07master:30ce6fd1069e: avfilter/vf_maskedmerge: get rid of MaskedMergeContext from functions that do actual work
[23:03:33 CEST] <jamrial> Gramner: just pull from his github repo. it's much faster than trying to apply the ml patches :p
[23:05:51 CEST] <Gramner> I guess that works too
[23:32:24 CEST] <durandal_1707> BBB: I pushed code to github.com/richardpl/ffmpeg mm branch
[23:33:07 CEST] <BBB> richardpl?
[23:33:12 CEST] Action: BBB confused
[23:33:59 CEST] <BBB> so, the dsp context is the only thing that should be in the header
[23:34:13 CEST] <BBB> you dont need the whole MaskedMergeContext there, just the function pointer entry
[23:34:56 CEST] <BBB> it can be useful to have a separate dsp_init (not x86, platform independent) so you can test the dsp code independently in e.g. checkasm, or reuse it elsewhere (maybe unlikely)
[23:35:31 CEST] <BBB> rest looks ok so far, I guess its asm time now?
[23:35:54 CEST] <durandal_1707> yes
[23:37:00 CEST] <BBB> btw holy crap thats a lot of arguments
[23:37:05 CEST] <BBB> you know this wont work on x86-32 right?
[23:37:13 CEST] <BBB> (thats probably not an issue, just pointing it out)
[23:38:42 CEST] <durandal_1707> am on x64
[23:38:46 CEST] <BBB> also I dont think max/shift/half need to be function arguments
[23:38:51 CEST] <BBB> since youre writing an 8bit version
[23:38:58 CEST] <BBB> and theyre fixed (256, 128, 8)
[23:39:42 CEST] <durandal_1707> so just remove them but keep 13
[23:40:06 CEST] <BBB> up to you how many regs you want
[23:40:10 CEST] <BBB> I dont think you need that many
[23:40:18 CEST] <BBB> but well see later
[23:40:19 CEST] <BBB> ok
[23:40:28 CEST] <BBB> ok, did you read the link I gave you?
[23:42:10 CEST] <durandal_1707> something
[23:42:35 CEST] <BBB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/x86/vp8dsp.asm;h=538b3f4a9b6725f5d25b3ab5dfb888ed5c299706;hb=HEAD#l666
[23:42:38 CEST] <jamrial> pointers should be the first few arguments, and all the linesize/width/height stuff after those. that way the latter can be accessed from stack in x86_32 (unless they are needed for lea)
[23:43:08 CEST] <BBB> theres a description of the bilinear filters in vp8, itll show you how to load basic data and do multiplies and shifts
[23:43:30 CEST] <BBB> durandal_1707: try to read that bilinear vp8 dsp code and understand what it does (referring to the c code)
[23:43:46 CEST] <BBB> durandal_1707: and then lets see if we can munge that into something thats useful for your code (itll end up looking similar)
[23:45:10 CEST] <BBB> also note people typcially write a*b+(256-a)*c+128>>8 as c+(a*(b-c)+128>>8)
[23:45:18 CEST] <BBB> since its one multiply instead of 2
[23:45:23 CEST] <BBB> but it wont make much of a difference
[23:53:53 CEST] <BBB> durandal_1707: C code is here: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/vp8dsp.c;h=07bea69c78c4e12bc1dc183ea0fc9ac78784c61d;hb=HEAD#l583
[23:57:23 CEST] <durandal_1707> so all instructions I will need are already in that asm func?
[00:00:00 CEST] --- Thu Oct  1 2015