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

[burek]

[00:15] <cone-239> ffmpeg.git 03Michael Niedermayer 07master:62533eab6fb1: ffv1enc: use 64bit in maxsize calculation
[00:15] <cone-239> ffmpeg.git 03Michael Niedermayer 07master:9c0fe487c755: avcodec/h264_parser: fix order of operations
[01:15] <cone-239> ffmpeg.git 03Michael Niedermayer 07master:4c67ed870503: avcodec/hevc: fix EOB/EOS check
[01:15] <cone-239> ffmpeg.git 03Mickaël Raulet 07master:92a97d1168cc: hevc: inline cabac in residual coding(cherry picked from commit 17d7a880445b72feb36d684ae1f0597195811e97)
[01:15] <cone-239> ffmpeg.git 03Mickaël Raulet 07master:b5d197a38b64: hevc: inline cabac in hls_mvd_coding(cherry picked from commit ad387195ad04e8a005a1bfd509e9e4f827e68fa9)
[01:15] <cone-239> ffmpeg.git 03Michael Niedermayer 07master:acecd6b4d7fd: avcodec/hevc_cabac: trivial simplifications
[01:15] <cone-239> ffmpeg.git 03Michael Niedermayer 07master:f2eca8d06060: avcodec/hevc: do not dereference pointer before null check in verify_md5()
[01:15] <cone-239> ffmpeg.git 03Michael Niedermayer 07master:23d69b158af4: avcodec/hevc_refs: fix h/vshift calculation in ff_hevc_output_frame()
[01:54] <michaelni> BBB / ubitux coverity also found things in vp9 (didt check if they are real or false positives)
[01:55] <BBB> ffvp9?
[01:55] <BBB> feel free to send to me
[01:55] <BBB> I have no time to check coverity
[01:55] <BBB> (or anything)
[02:02] <michaelni> ffvp9, yes, not sure how i could send something from coverity
[02:06] <michaelni> for example: "cond_const: Checking "i < 10" implies that the value of "i" is 10 on the false branch" and then it thinks "3315    s->f = s->fb[i];" can overread
[02:06] <BBB> is there a link to some web report?
[02:10] <michaelni> AFAIK yu need to have an account, i just send you an invite through the web interface to @gmail.com
[02:10] <michaelni> theres a good chance it will end in your spam folder
[02:13] <BBB> hm...
[02:13] <BBB> if you feel there's anything real, feel free to file a bug or so, or copypaste it to my email
[02:13] <BBB> else there's a lot chance I'll look at it
[02:13] <BBB> as for the overread, it can't overread, vp8 has an assert there
[02:13] <BBB> I remved the assert for vp9 because it's obvious
[02:14] <michaelni> ok ill mark that overread as false positive
[02:17] <michaelni> BBB, when you click on the left side on FILES/with outstanding issues and then vp9... from the list then you can see exactly the ones about vp9
[02:17] <michaelni> i see 1 in vp9 and 6 in vp9dsp only
[02:19] <michaelni> the 6 all look related
[02:21] <iive> the 3315 one does look fishy.
[02:22] <michaelni> either way, ill look at the vp9 onces eventually in case you have no time
[02:23] <michaelni> but there are a few others left that fall closer into my responsibility which ill look at first
[02:43] <cone-239> ffmpeg.git 03Michael Niedermayer 07master:6338f1b3c095: avcodec/tiff: remove byte based bpp special case
[02:43] <cone-239> ffmpeg.git 03Michael Niedermayer 07master:2e9b79fc003f: avcodec/wavpackenc: fix uninitialized ret
[09:32] <mraulet> michaelni: I have fixed the latest sequence
[11:25] <cone-729> ffmpeg.git 03Mickaël Raulet 07master:c841d02c056f: hevc: fix PPS_A_qualcomm_7(cherry picked from commit 2af177a8761c88eb477a658eebcf4264068aa773)
[11:25] <cone-729> ffmpeg.git 03Mickaël Raulet 07master:1b5a52f425d9: hevc: pretty print(cherry picked from commit 64a4b623b7d66dfc0f3883e5f1d9125c00c3b18c)
[12:17] <cone-729> ffmpeg.git 03Reimar Döffinger 07master:c9a22d69afc7: hevc: Initialize sample aspect to valid value.
[12:20] <ubitux> BBB: iiuc, with pmaddwd, i will need to mix things inputs and vp9 cos constants together; is it appropriate to use the punpck* instr for such purpose?
[12:22] <ubitux> well i guess so.
[13:26] <BBB> ubitux: sure
[13:26] <BBB> ubitux: anything is fine if it's faster :)
[13:46] <BBB> michaelni: both in vp9 are false
[13:46] <BBB> michaelni: the ones in vp9dsp are from ubitux' code, I think, he should probably look at them
[13:47] <BBB> michaelni: the vp9.c ones can be "solved" with a simple assert (assert(pred < 8); and assert(i < 10);)
[13:49] <ubitux> i'll have a look
[14:07] <burek> hi all :)
[14:07] <burek> can anyone help me how to answer this question (about v 0.5.x) http://ffmpeg.gusari.org/viewtopic.php?f=16&t=1114
[14:09] <michaelni> marked the vp9.c one as false positive
[14:21] <BBB> ubitux: I think line 775 and 777 should be size - j - 1 in the memcpy, instead of size - j
[14:21] <BBB> ubitux: memset overrides the size - j - 1 position
[14:21] <BBB> ubitux: that should fix them
[14:21] <BBB> the rest seems clean
[14:22] <ubitux> i didn't look yet, i'm still in the asm
[14:22] <BBB> ok
[14:22] <BBB> michaelni: you then
[14:22] <ubitux> i'll look, no worry :)
[14:22] <BBB> michaelni: and feel free to apply the asserts tothe codebase, it's somewhat clean to document
[14:22] <BBB> ubitux: and 32x32 asm is steadily progressing, it's just a lot of it, as you'd know, you wrote the c
[14:22] <BBB> :)
[14:22] <michaelni> BBB ok, will do
[14:23] <ubitux> BBB: yeah i can guess so :p
[14:26] <BBB> michaelni: ty - poke me if there's any new issues
[14:26] <BBB> the asm one is a nice catch
[14:26] <BBB> er... dsp
[14:33] Action: Daemon404 logs nto coverity for the first time ever
[14:37] <Compn> took me 10 minutes thinking how to crop an mpeg2 video
[14:37] <Compn> which program supports copying audio and video without messing anything up
[14:37] <Compn> finally just dd'd it :D
[14:47] <cone-729> ffmpeg.git 03Michael Niedermayer 07master:f198efb179cb: avcodec/vp9: Add asserts to help source code analyzers
[14:47] <cone-729> ffmpeg.git 03Michael Niedermayer 07master:78e6f83ce027: avformat/au: add assert to help source code analyzers
[15:46] <ubitux> gdb not unrolling macros ’ sadness.
[16:54] <cone-729> ffmpeg.git 03Michael Niedermayer 07master:baab248c499a: avformat/network: check for fcntl() failure in ff_socket()
[16:54] <cone-729> ffmpeg.git 03Michael Niedermayer 07master:b294a4beec24: avformat/oggparsecelt/celt_header: fix memleak
[17:03] <cone-729> ffmpeg.git 03Michael Niedermayer 07master:2c1e075308e1: avformat/oggparseflac: check ff_alloc_extradata() return code
[17:03] <cone-729> ffmpeg.git 03Michael Niedermayer 07master:eb5cc8febc6c: avformat/oggparsespeex: Check for extradata allocation failure
[17:42] <BBB> ubitux: michaelni: did you guys fix the vp9dsp one or do you need a patch?
[17:42] <ubitux> i didn't look yet, will do later today probably
[17:43] <ubitux> i might be done with the first dim for idct soon
[17:43] <ubitux> ...but it looks like i've already some rounding problem :(
[17:44] <BBB> easy to fix
[17:44] <BBB> goodluck debugging asm :)
[17:45] <BBB> michaelni: and yeah the asserts look good thanks
[17:56] <j-b> BBB: I ffvp9 is higher priority. But some free distributions do not wnat libavcodec, but they would welcome libvpx
[17:57] <Compn> 'free distributions' ?
[17:57] <j-b> yeah fedora
[17:58] <Compn> lol
[17:58] Action: Compn afk
[17:58] <j-b> Compn: yeah :)
[18:00] <wm4> so vlc compiles without libav*?
[18:01] <kierank> probably without libavcodec
[18:02] <j-b> wm4: yep
[18:02] <j-b> wm4: the biggest issue is swscale, you know :)
[18:03] <wm4> fascinating
[18:03] <wm4> the result can't be awfully useful, or do you hook into gstreamer?
[18:04] <j-b> what would be the use of that?
[18:04] <BBB> i bet it can decode webm and ogg/theora
[18:04] <BBB> and wav
[18:05] <wm4> gstreamer has licensed h264 decoders (provided by external companies)
[18:05] <BBB> the dream of freedom lovers
[18:05] <kierank> wm4: why can't they licence libavcodec
[18:05] <BBB> wm4: no, those companies have licensed h264 decoders
[18:05] <BBB> gstreamer doesn't own or distribute them
[18:05] <wm4> right, wrong wording
[18:06] <BBB> happens... useful thing to have
[18:06] <BBB> chrome has such a license also
[18:06] <BBB> they happen to use it to ship libavcodec's implementation
[18:07] <BBB> I'm happier that way, since at least it's free software
[18:07] <BBB> it's better than licensing crap along with close source software
[18:07] <Compn> is it still faster than the other closed options ?
[18:07] <BBB> libavcodec's? unlikely, it's probably about as fast, within a few % error margin
[18:07] <BBB> but I never measured
[18:08] <beastd> probably faster to fix if needed :)
[18:09] <j-b> wm4: licensed? lol.
[18:09] <j-b> wm4: we have a gstreamer module, never merged.
[18:09] <j-b> wm4: no, it's more to play the "free" stack, aka Ogg/Vorbis/Theora/FLAC/Opus+Webm1/2
[18:10] <Compn> luckily there are no multimedia patents that cover those codecs :)
[18:11] <j-b> right :)
[18:11] <wm4> anyway, they could just ship a crippled libavcodec...
[18:12] <j-b> of course, that would be what makes sense...
[18:12] <j-b> but sense is not really shared with some of our colleagues
[18:16] <ubitux> BBB: i want to go from dw A,B,A,B to -B,A,-B,A; should i transform the first (assuming stored in a reg) into the second, or just load it?
[18:16] <ubitux> basically; pw_X: dw A,B,A,B; pw_Y: -B,A,-B,A vs loading only pw_X and transform it into pm_Y when necessary
[18:18] <ubitux> i might be able not to do the shuffling though, and find a way negating all both A and V
[18:18] <ubitux> s/V/B/
[18:45] <michaelni> hi saste, do you have time to look at some ffprobe coverity issue(s?)
[18:45] <saste> michaelni, yes nail me if you see no patch from me in a few days
[18:46] <cone-729> ffmpeg.git 03Michael Niedermayer 07master:88d4ff4b5f4c: avformat/utils: Check av_packet_new_side_data() return before using it
[18:46] <cone-729> ffmpeg.git 03Michael Niedermayer 07master:ad28fe35c55b: avutil/file_open: Print debug message if setting close on exec fails
[18:46] <cone-729> ffmpeg.git 03Michael Niedermayer 07master:2d8ccf0adcae: avutil/opt: initialize ret
[19:22] <cone-729> ffmpeg.git 03Lukasz Marek 07master:d1f383341fda: lavd/pulse_audio_enc: add support for flushing
[19:24] <cone-729> ffmpeg.git 03Lukasz Marek 07master:36d0b15b4e57: MAINTAINERS: add lavd/fbdev_enc entry
[20:44] <BBB> ubitux: whichever is easier. transforming might suck because it means extra instructions, but whichever is faster and simpler and smaller code
[20:44] <BBB> (in that order of relevance)
[20:44] <ubitux> yes but transforming a register might be faster than loading from memory
[20:45] <ubitux> basically, 1 load + transform vs 2 load
[20:45] <ubitux> i was wondering about the cost of such transform
[20:45] <ubitux> but well, i'd better get something working first anyway
[20:45] <ubitux> i'm still derping with various random issues right now
[20:45] <BBB> good question, not sure
[20:46] <BBB> what you're saying makes sense but I'm not sure
[20:46] <BBB> I tend to just multiply straight from memory
[20:46] <BBB> i.e. pmaddwd mX, [pw_...]
[20:46] <BBB> as opposed to mova mY, [pw_...]; pmaddwd mX, mY
[20:46] <BBB> but for 4x4 your version may be faster because you have enough registers
[20:46] <ubitux> i don't have enough registers actually :(
[20:47] <BBB> oh
[20:47] <BBB> then multiply from memory
[20:47] <ubitux> i'm limiting myself to 8 reg though
[20:47] <ubitux> also, i'm doing the add mul in 2 steps
[20:48] <ubitux> so i exhaust the register a bit faster
[20:49] <BBB> you have to do 8 reg, it's mmx
[20:49] <BBB> not xmm
[20:49] <BBB> 16 regs is xmm only
[20:49] <BBB> what is add-mul in 2 steps?
[20:49] <BBB> you're just doing punpcklwd; pmaddwd; padddx2; psradx2; packssdw, right?
[20:50] <BBB> actually punpckl/hwd, (pmaddwd, paddd, psrad)x2, packssdw
[20:50] <BBB> anyway
[20:50] <ubitux> yes, that ^
[20:50] <BBB> yeah that's fine
[20:50] <ubitux> on the 8 reg, i have 2 already used to store t0 and t1
[20:51] <ubitux> so i have 6 reg remaining, and i'm trying to avoid reloading from memory the coef and various other saves
[20:51] <ubitux> anyway, i still need some time :p
[20:52] <BBB> ok
[20:52] <BBB> I'm not there yet either
[20:52] <BBB> just make sure you submit a patch to fix that coverity issue
[20:54] <ubitux> yeah, i'll look at this in about 10m
[21:04] <ubitux> 14:21:06 <@BBB> ubitux: I think line 775 and 777 should be size - j - 1 in the memcpy, instead of size - j
[21:04] <ubitux> 14:21:42 <@BBB> ubitux: memset overrides the size - j - 1 position
[21:04] <ubitux> confirmed
[21:04] <BBB> ty
[21:16] <cone-729> ffmpeg.git 03Marton Balint 07master:b2d9790c2ba7: lavc: make avcodec_decode_subtitle2 more robust
[21:17] <cone-729> ffmpeg.git 03Ronald S. Bultje 07master:fed483f188b3: avcodec/vp9dsp: fix overwrite by 1 in vert_left pred.
[21:17] <ubitux> BBB: thx ^
[21:17] <BBB> back to simd now
[21:17] <BBB> I still hope to have a full 32x32 in a few weeks
[21:17] <BBB> that would be a good 10-20% speedup
[21:17] <ubitux> yeah well, now that i'm in coverity i'll fix one more elsewhere
[21:18] <ubitux> michaelni: i don't remember, do i need to mark them as fixed in coverity or they will disappear by themselves?
[21:19] <BBB> anything vp8-related there?
[21:19] <BBB> I didn't check very closely
[21:20] <ubitux> i don't see anything
[21:21] <ubitux> there are not that much issues remaining
[21:29] <cone-729> ffmpeg.git 03Clément BSsch 07master:4189fe11ffcb: avformat/vobsub: fix invalid sub queue access while seeking.
[21:30] <ubitux> ok, now back to simd
[21:48] <michaelni> ubitux, i think they will disappear on their own but if you mark them as fix submited or something then others know before that already that they dont need to look at that one anymore
[21:48] <ubitux> ok
[21:52] <Compn> ZMK4 ? another xvid fourcc ? hmm
[00:00] --- Mon Oct 21 2013