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

Tue Nov 19 02:05:02 CET 2013

[01:32] <cone-904> ffmpeg.git 03Vallimar 07master:6f8a27dd3ba3: avcodec/old_codec_ids: fix missing FF_API_XVMC check
[01:32] <cone-904> ffmpeg.git 03Vallimar 07master:6f5c36832dfc: avfilter/vf_mp: fix missing FF_API_XVMC check
[02:43] <BBB> STRIP	libavfilter/x86/vf_gradfun.o
[02:43] <BBB> strip: unrecognized option: -wN
[02:43] <BBB> Usage: strip [-AnuSXx] [-] [-d filename] [-s filename] [-R filename] [-o output] file [...] 
[02:43] <BBB> make: [libavfilter/x86/vf_gradfun.o] Error 1 (ignored)
[02:43] <BBB> ?
[02:43] <BBB> what is that?
[02:43] <BBB> I see that a lot
[02:49] <{V}> BBB, http://linux.die.net/man/1/strip wildcard and stripping a specific symbolname apparently
[02:50] <{V}> https://trac.ffmpeg.org/ticket/3037
[02:52] <BBB> I don't have a trac account, but if it hits a developer, I'd say it's major?
[02:57] <iive> what distro are you running? Debian?
[03:13] <cone-904> ffmpeg.git 03Michael Niedermayer 07master:a8dec360c5db: avformat/utils: dont count attached pics toward the probesize
[05:35] <Zeranoe> I believe this commit: http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=b18c7c8d3ddfbf171fe0aba1c201a002920af7f7 introduced "libxavs.c:161:5: error: 'avctx' undeclared (first use in this function)". I will submit a bug report tonight if this doesn't get a quick fix on here.
[07:46] Last message repeated 1 time(s).
[07:46] <ubitux> Zeranoe: http://pastie.org/8488946
[07:47] <ubitux> can you try this?
[07:53] <cone-27> ffmpeg.git 03Clément BSsch 07master:71cd83e34cf7: avcodec/libxavs: attempt to fix compilation after b18c7c8d.
[07:53] <ubitux> Zeranoe: well, just pushed, tell me if that fixes it for you
[07:54] <Zeranoe> ubitux: Oh, alright, was working on testing locally. I'll just pull then
[08:04] <Zeranoe> ubitux: I appreciate the quick support. The error is now: libxavs.c:116:23: error: 'ctx' undeclared (first use in this function)
[08:07] <ubitux> ah& ofc...
[08:09] <cone-27> ffmpeg.git 03Clément BSsch 07master:260fc0d95b02: avcodec/libxavs: 2nd attempt to fix compilation after b18c7c8d.
[08:09] <ubitux> Zeranoe: ^
[08:16] <Zeranoe> ubitux: Fixed, thanks again
[09:32] <ubitux> thx BBB for the patch
[09:32] <ubitux> will review today
[10:12] <plepere> f.....
[10:13] <plepere> I got my assembly working correctly !
[10:13] <ubitux> :)
[10:13] <plepere> it was because dststride didn't account the fact that dst was 16bit
[10:13] <plepere> so I had to do 2 times the increment
[10:14] <cone-27> ffmpeg.git 03Michael Niedermayer 07master:cda3c0047554: avcodec/h261enc: remove unused variables
[10:22] <plepere> I have a question :
[10:22] <plepere> currently, I work with functions with blocks with a width ranging from 2 to 32.
[10:24] <plepere> In my intrinsics optimized functions, I do some tests to check what level of optimization I must do. 16 by 16, 8 by 8, 4 by 4, or 2 by 2
[10:24] <plepere> should I do the same in assembly ?
[10:26] <kierank> you can write macros to do that
[10:27] <plepere> well I think I'll do the tests to point to the right macro depending on the parallelism level I can do.
[10:28] <ubitux> plepere: you're supposed to have one function for each level
[10:28] <ubitux> which you generate with macro if you can
[10:29] <plepere> so I need to do the test before calling the function ?
[10:29] <ubitux> aren't you supposed to have a callback for each size?
[10:30] <plepere> I have the width size as function parameter
[10:30] <ubitux> what function is that?
[10:30] <plepere> all of the qpel for instance
[10:31] <ubitux> ah, the depth thing
[10:31] <plepere> no
[10:31] <plepere> wait, I'll do a pastebin showing what I mean
[10:32] <plepere> http://pastebin.com/hrsiqV96
[10:33] <plepere> there's a lot of code, but the thing I'm asking about is : I'm doin if(!(width&15)) do 16 times parallelism. if 8, do 8 times parallelism
[10:33] <ubitux> the alignements check?
[10:34] <ubitux> ok
[10:34] <plepere> not always
[10:34] <plepere> and when using CAL, it never is aligned
[10:34] <ubitux> why not always 16, and do a slow path for the padding?
[10:35] <plepere> ubitux : so you're proposing 16 * 16 till we reach width - 15, and then do 2 by 2 ?
[10:36] <ubitux> if (width & 15), you make a slow path (which could be a resegmentation with width & 7, width & 3, ...) of size width & ~15
[10:37] <ubitux> and you do all the rest on 16
[10:37] <ubitux> not sure i'm clear enough
[10:38] <plepere> hmm. So I keep the test in the function, but I do a fast 16 times parallelism, and the rest is 8 times parallelism that finishes 2 by 2 if necessary
[10:40] <ubitux> plepere: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavfilter/x86/vf_gradfun_init.c;h=c638a05e87575566dbef8d75651eed5c65e324be;hb=HEAD#l43
[10:40] <ubitux> see this
[10:41] <ubitux> the function filters the line in a "slow mode" (c function) for the padding, and use a fast code for the remaining pel
[10:41] <ubitux> you would do the same, except that you would have nested small sub-slow mode if necessary
[10:42] <ubitux> (if you really want to be fast for the little padding area)
[10:42] <nevcairiel> which width values can really occur? if its really only a slow number of values, one function per value might be better
[10:43] <plepere> ubitux, I'll loo at the code
[10:43] <plepere> nevcairiel, it can be 2, 4, 8, 12, 16, 24, 32
[10:43] <plepere> but I'll have to test again if you want to be sure
[10:43] <ubitux> width can't be odd but can go down to mod 2, like h264>
[10:43] <ubitux> ?
[10:44] <plepere> I think so
[10:44] <ubitux> ok
[10:45] <ubitux> anyway the slow path will be for at most 15 px per line
[10:45] <ubitux> so you can hardcode in a few instructions those
[10:46] <nevcairiel> if the width is always only between 2 and 32, doing slow mode for at least 15 of those seems inefficient
[10:46] <ubitux> at least?
[10:46] <ubitux> at most you mean
[10:46] <plepere> ok, I printed the width on a short video, and the width can take 4, 8, 12, 16, 32 and 64.
[10:46] <plepere> but a majority is 8
[10:46] <ubitux> [16][16][16][...][16][<16 slow path]
[10:47] <ubitux> always this ^
[10:47] <ubitux> and you can specialize the < 16 part
[10:47] <nevcairiel> but if the maximum size is 64
[10:47] <nevcairiel> and 8 is rather common
[10:47] <nevcairiel> an optimized 8 might be good
[10:47] <ubitux> oh wait sorry it's not the full size of the video
[10:48] <nevcairiel> its block size, isnt it
[10:48] <ubitux> ah in that case&
[10:48] <nevcairiel> up to 64
[10:48] <nevcairiel> personally i might even go with optimized functions for each block size
[10:48] <nevcairiel> not sure if worth it though
[10:48] <ubitux> indeed
[10:48] <ubitux> you make a 16-bit macro to reuse with 16, 32 and 64
[10:49] <ubitux> and you make special functions for 4, 8 and 12
[10:49] <nevcairiel> and 24
[10:49] <ubitux> i didn't see it in the list :)
[10:49] <plepere> the width really varies with the video. tried on HD, and the 32 and 16 are much more present. and 24 seems to be a valid width size
[10:49] <nevcairiel> it was in the earlier list, no idea :)
[10:50] <ubitux> plepere: well, you can start by making if just like your intrinsics, but you should have a callback per size IMO
[10:50] <ubitux> plepere: i had a full video width in mind at first, so forget what i said :)
[10:51] <plepere> I might as well change things now, and do the testing before calling the function and have different functions through macros
[10:52] <nevcairiel> first step would be finding out which sizes can really occur, probably need to consult the calling code or the spec, then restructer the dsp function pointers to store them per-width
[10:52] <nevcairiel> restructure*
[10:52] <nevcairiel> but this indeed sounds more efficient in the long run
[10:54] <plepere> however, the width testing should be done before calling the functions.
[10:54] <ubitux> you wouldn't "test"
[10:54] <nevcairiel> just use the width as an index into the table, i guess
[10:54] <ubitux> you would use a width id as a cb index 
[10:55] <plepere> ok
[10:55] <ubitux> meh
[10:55] <plepere> so                 	c->put_hevc_epel[0][1] = ff_hevc_put_hevc_epel_h_8_sse;
[10:55] <plepere>  becomes                 	c->put_hevc_epel[0][1][8] = ff_hevc_put_hevc_epel_h_8_8_sse;
[10:56] <plepere> for a 8 by 8 function
[10:56] <nevcairiel> wonder how other things do it, if its more efficient to store it not by the width itself but some number derived from the width (so the array isn't as big)
[10:57] <ubitux> you probably have a 0 ’ N values to identify each width
[10:57] <ubitux> i doubt the codec has "64" stored as such
[10:57] <nevcairiel> comes back to checking the calling code :)
[10:57] <tachyean>  i'm trying to capture jpeg images from an rtmp stream and save them to disk, i've managed to do it but when i run the ffmpeg command i must wait between 1 and 2 minutes for the capture to start, there is any way i can make it start sooner than 1 minute?
[10:58] <tachyean> this is the command i'm running: http://pastebin.com/wKBwTPB6
[10:58] <ubitux> tachyean: ask #ffmpeg
[10:58] <tachyean> i've asked 
[10:58] <ubitux> you won't have more help here, this is for development on ffmpeg
[10:58] <tachyean> ok
[10:58] <plepere> good luck, though
[10:58] <tachyean> i'm sorry for bothering ^^!
[10:59] <tachyean> thank you!
[10:59] <plepere> I'll ask around how the width is handled in the codec
[11:01] <ubitux> based on log2_cb_size i'd say
[11:01] <ubitux> which is strange if you said 12 and 24 as width
[11:02] <ubitux> probably the 3/4 partition then
[11:03] <ubitux> you might have to either generate a block width id, or use log2_cb_size and the partition mode
[11:07] <ubitux> BBB: oh wait, SWAP can take N arguments? :o
[11:07] <plepere> yes, I'll check that
[11:08] <plepere> thanks a bunch.
[11:15] <plepere> the dsp function pointing file will be completely unreadable ! I'll have almost 100 functions !
[11:15] <nevcairiel> thats usually where macros come in
[11:15] <plepere> yeh
[11:15] <plepere> I'll see as I advance
[11:17] <plepere> mraulet also told me that it would be interesting to fuse the (un)weighted prediction functions with the qpel ones.
[11:18] <plepere> since they are used together on the same blocks
[11:20] <wm4> j-b: what security bugs does mpv have?
[11:20] <j-b> the same as libav/ffmpeg
[11:21] <nevcairiel> the same as vlc then? :D
[11:22] <j-b> yep
[11:22] <j-b> but we don't advise users to build libav/ffmpeg statically like JEEB does.
[11:22] <j-b> or whatever mpv-builds does
[11:22] <wm4> oh so it's about static linking
[11:22] <plepere> http://pastebin.com/iz9XvgYV <-- is there another way of doing this ? it seems awfully repetitive.
[11:22] <JEEB> I don't recommend that either unless the user seems to need a newer libav*
[11:23] <JEEB> <JEEB> if a user needs a newer libav* on *nix and your distro does not provide, i don't see a real alternative to using contrib-like solutions
[11:23] <JEEB> <JEEB> I really hope I am not correct about this, but to be frank I just don't see it
[11:23] <wm4> anyway, mpv-build is not _required_
[11:23] <JEEB> yes, definitely not required
[11:23] <JEEB> it's just the simpler way to get a solution to the problem I noted
[11:23] <wm4> it's merely a way to build mpv with a local copy of ffmpeg (easier due to distro madness etc.), so static linking is kind of required here
[11:24] <ubitux> building mpv with ffmpeg is easier than building vlc with ffmpeg at least
[11:24] <ubitux> :)
[11:24] <j-b> ubitux: right.
[11:24] <ubitux> even without static
[11:24] <j-b> ubitux: I really should take sides then, I guess
[11:25] <j-b> ubitux: please go fuck yourself
[11:25] <ubitux> hahaha
[11:25] <ubitux> wtf :')
[11:25] <wm4> wat
[11:25] <JEEB> ^^;
[11:25] <wm4> why is he so angry
[11:25] <ubitux> :D
[11:25] <ubitux> dunno
[11:27] <wm4> vlc is a nice project, but due to its size it's rather obvious that building it will be harder
[11:28] <plepere> is there a way to simplify function pointers ? such as hevcdsp->put_hevc_qpel[0][0][*] = FUNC(put_hevc_qpel_pixels, depth); if all values point to the same C function ?
[11:29] <nevcairiel> could always loop
[11:29] <plepere> ok
[11:30] <nevcairiel> not sure if thats something usually done
[11:30] <plepere> http://pastebin.com/iz9XvgYV is what I'd have for one function.
[11:30] <plepere> I have to do this for 15 others at least
[11:31] <nevcairiel> well you could macro that so that you only end up calling one macro for every of those
[11:31] <ubitux> a innefficient to have such as huge table though
[11:32] <plepere> macros in a macro. inception much ?
[11:32] <nevcairiel> I dunno how it looks in the end, but usually you can greatly factor out the repetetive things in DSP init
[11:39] <ubitux> and now j-b trolling ffmpeg on libav channel
[11:39] <ubitux> did i make him that upset?
[11:41] Action: wm4 gets popcorn
[11:41] <JEEB> he probably had a bad morning?
[11:41] <JEEB> I did really seemingly walk on a land mine with him
[11:41] <JEEB> noting to a user that it's most probably simpler to build mpv-build than VLC's contribs to get a player with a newer libav* inside
[11:42] <JEEB> (that user seemingly needed a newer libav* than his distro gives)
[11:43] <ubitux> where was that? :)
[11:44] <JEEB> #videolan
[11:45] <{V}> trac's down?
[11:46] <ubitux> JEEB: oh i see
[11:46] <ubitux> he thought i was teasing him about that because i'm on the chan
[11:46] <ubitux> heh i guess i should try to tell that to him
[11:54] <ubitux> trac down
[12:28] <michaelni> trac is up again, ping me if you see problems
[12:28] <michaelni> that is ping me and beastd if he is here
[12:56] <smarter> plepere: I tried fusing the (un)weighted prediction with the qpel stuff but gave up
[13:11] <smarter> can't remember why exactly, hmm
[13:12] <BBB> ubitux: yes
[13:18] <smarter> I think what annoyed me was that depending on whether you use fused mc+(put_un)weighted_pred, the result is an uint8_t buffer, buf if you do two mcs (so that you can do a weighted average afterwards), you end up with an uint16_t temporary buffer
[13:25] <smarter> ah right, I remember I just wanted to avoid the temporary buffer by writing the interpolation result in the frame, but you can't do that when the interpolation result is 16 bits
[13:26] <smarter> so you need two set of MC functions, which annoyed me too much to do :)
[13:30] <smarter> plepere: also don't write put_hevc_qpel[0][0][4] = , put_hevc_qpel[0][0][8] =, ... or you'll be wasting space with empty members in the array, instead use put_hevc_qpel[0][0][0] =, put_hevc_qpel[0][0][1] =, etc
[13:32] <smarter> (and use a macro or a for loop to avoid repeating yourself)
[14:20] <cone-903> ffmpeg.git 03Paul B Mahol 07master:74906d3727ec: avcodec/libopusenc: change default frame duration to 20 ms
[14:24] <wm4> durandal_1707: did you have a look at the mp3 that failed probing yet?
[14:26] <durandal_1707> wm4: no, and i do not plan to
[14:29] <plepere> thank you for the tips, smarter.
[15:19] <cone-903> ffmpeg.git 03Clément BSsch 07release/1.0:0227ecc21f1a: build: avoid stdin stall with GNU AS probing.
[15:19] <cone-903> ffmpeg.git 03Michael Niedermayer 07release/1.0:cebad79898a4: avformat/utils: dont count attached pics toward the probesize
[15:19] <cone-903> ffmpeg.git 03Clément BSsch 07release/1.1:7f174cec8bd5: build: avoid stdin stall with GNU AS probing.
[15:19] <cone-903> ffmpeg.git 03Michael Niedermayer 07release/1.1:f401e600638b: avformat/utils: dont count attached pics toward the probesize
[15:19] <cone-903> ffmpeg.git 03Michael Niedermayer 07release/1.2:25c67b216534: avformat/utils: dont count attached pics toward the probesize
[15:19] <cone-903> ffmpeg.git 03Clément BSsch 07release/1.2:d04e78805aa4: build: avoid stdin stall with GNU AS probing.
[15:19] <cone-903> ffmpeg.git 03Michael Niedermayer 07release/2.0:9a22d6dd6326: avformat/utils: dont count attached pics toward the probesize
[15:19] <cone-903> ffmpeg.git 03Clément BSsch 07release/2.0:ff4c53e8b306: build: avoid stdin stall with GNU AS probing.
[15:19] <cone-903> ffmpeg.git 03Clément BSsch 07release/2.0:93716f7bea11: avformat/image2: allow muxing gif files.
[15:19] <cone-903> ffmpeg.git 03Lou Logan 07release/2.1:5c8845a55478: Fix example in pullup documentation.
[15:19] <cone-903> ffmpeg.git 03Michael Niedermayer 07release/2.1:3193b85be333: avcodec/tiff_common: allow count = 0 in ff_tadd_bytes_metadata()
[15:19] <cone-903> ffmpeg.git 03Clément BSsch 07release/2.1:7ce0f4ea3b20: avformat/image2: allow muxing gif files.
[15:19] <cone-903> ffmpeg.git 03Clément BSsch 07release/2.1:c38af02626fb: build: avoid stdin stall with GNU AS probing.
[15:19] <cone-903> ffmpeg.git 03Michael Niedermayer 07release/2.1:842def7d7813: avformat/utils: dont count attached pics toward the probesize
[16:07] <plepere> san someone tell me if what I'm doing is good practice or if I should re-organize how I'm writing my asm ? : http://pastebin.com/74AAHyCR
[16:09] <plepere> *can
[16:09] <plepere> thanks in advance
[16:12] <cone-903> ffmpeg.git 03Valeriy Argunov 07master:cc20fbcd39c7: rtmphttp: Check for both 0 and AVERROR_EOF
[16:12] <cone-903> ffmpeg.git 03Michael Niedermayer 07master:cbefb3d9098b: Merge remote-tracking branch 'qatar/master'
[16:14] <ubitux> use m0..mN names instead of explicit xmmN probably
[16:14] <ubitux> weird alignment btw
[16:14] <ubitux> you can also name the registers from teh prototypes
[16:15] <plepere> I tried that, but it returned errors. 
[16:15] <plepere> it's cglobal put_hevc_mc_pixels_2_8, 9, 12, 0 , dst, dststride, srd, srcstride,width,height
[16:15] <plepere> that I should do ?
[16:16] <ubitux> yes, then don't forget the suffix when using
[16:16] <ubitux> such as dstq, widthd, etc
[16:16] <plepere> how do I know the suffix ?
[16:17] <ubitux> it's the size
[16:17] <ubitux> q 64 d 32 ..
[16:17] <plepere> so dst should be w and src should be b N
[16:17] <plepere> ?
[16:18] <plepere> using dstq gives me an ugly image. :p
[16:18] <ubitux> dstq srcq ?
[16:19] <plepere> never mind. I'm terrible at programming. works like a charm now
[16:21] <smarter> plepere: nitpick: you're supposed to align everything on ',' and leave a space after it
[16:21] <plepere> ok smarter.
[16:22] <plepere> easy way to do this on eclispe ?
[16:22] <smarter> I only know how to do it with emacs :P
[16:22] <plepere> so all , should be one above the other. right ?
[16:22] <ubitux> in eclipse, iirc it's: click on the top right cross to close it and open a text editor
[16:22] <smarter> haha
[16:22] <plepere> haha, nice one
[16:23] <smarter> plepere: look at vp*asm for good examples :)
[16:23] Action: JEEB golfclaps
[16:24] <plepere> ok, I got this
[16:25] <smarter> also the other day I reformated hevc_deblock.asm (but I haven't reviewed it yet): https://github.com/smarter/libav/blob/hevc_dbl_asm/libavcodec/x86/hevc_deblock.asm
[16:43] <plepere> see you all tomorrow
[16:44] <plepere> thanks for all the fish.
[16:46] <cone-903> ffmpeg.git 03Michael Niedermayer 07master:7d0e927a31ed: avformat/mpegts: fix resync seek
[17:49] <cone-903> ffmpeg.git 03Carl Eugen Hoyos 07master:d4a6133ab8ca: Add decoder dependency to the HEVC parser.
[17:52] <cone-903> ffmpeg.git 03Carl Eugen Hoyos 07master:3f2ce316cda3: Add a Makefile rule for the little-endian G.726 decoder.
[17:52] <nevcairiel> curious why someone would care so much for h261 encoding o.o
[17:53] <smarter> nevcairiel: it has been proposed as a fallback codec for WebRTC
[17:53] <smarter> https://www.ietf.org/mail-archive/web/rtcweb/current/
[17:53] <nevcairiel> seriously, they didnt find any older codecs
[17:53] <smarter> H.120
[17:55] <cone-903> ffmpeg.git 03Michael Niedermayer 07release/2.1:a289b0b91a79: avformat/mpegts: fix resync seek
[18:08] <ubitux> trac down?
[18:08] <ubitux> (michaelni? ^)
[18:12] <ubitux> seems re-up
[18:13] <cone-903> ffmpeg.git 03Carl Eugen Hoyos 07master:2974050cf578: Add a lavc Makefile dependency for the elbg filter.
[18:13] <michaelni> ubitux, yes, dont ask me what it was i just read that its down and checked and it already was up 
[18:16] <michaelni> maybe beastd was making a backup or something
[21:06] <cone-903> ffmpeg.git 03Michael Niedermayer 07master:5db49fc38d91: avcodec/pcm-dvd: fix 20bit 2 channels
[21:06] <cone-903> ffmpeg.git 03Michael Niedermayer 07master:ab184b298d4a: avcodec/pcm-dvd: fix 20/24bit 1 channel
[21:06] <cone-903> ffmpeg.git 03Michael Niedermayer 07master:4adf1fe34f17: avcodec/pcm-dvd: fix incorrectly printed warning about changed block sizes
[21:06] <cone-903> ffmpeg.git 03Michael Niedermayer 07master:918cab1a9f68: avcodec/pcm-dvd: print actual block size values in block size changed warning
[22:39] <michaelni> mraulet, anything new i should cherrypick / merge ? also, not sure you already saw https://trac.ffmpeg.org/ticket/3115 (hevc crash)
[22:40] <mraulet> i will merge in the master everything you can cherry pick
[22:41] <mraulet> our hevc branch contains an shvc decoder that is not standard yet :-)
[22:41] <mraulet> but I need to merge tiles and wpp related stuff, it works well in combination with frame-based now
[22:42] <mraulet> I need to check your file
[22:42] <mraulet> file/ticket
[22:43] <michaelni> ok, thanks
[23:22] <baptiste> hevc ? nice 
[23:24] <ubitux> BBB: sorry i'm delaying the review to tomorrow
[23:29] <cone-903> ffmpeg.git 03Michael Niedermayer 07master:f0f04fd84294: avcodec/asvenc: remove code allocating dummy coded_frame
[00:00] --- Tue Nov 19 2013