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

[burek]

[00:25] <wm4> can ffprobe output frame type? B/I/P etc.
[00:35] <rcombs> https://trac.ffmpeg.org/ticket/3824 <-- can I bother someone to fix this real quick? It's a one-line change :D
[00:36] <jamrial> wm4: -show_frames does
[00:37] <rcombs> hah, I forgot I get my own color due to an fflogger bug
[00:38] <wm4> jamrial: oh indeed it does, I just missed that somehow
[00:39] <wm4> rcombs: you should really write a patch, instead of writing "insert blabla here in the code" in english
[00:39] <rcombs> wm4: but then they'd tell me to go to the mailing list :3
[00:39] <wm4> mailing list interaction is unavoidable for interacting with this project
[00:58] <cone-789> ffmpeg.git 03Michael Niedermayer 07master:cfdb30d2f124: avcodec/dvdsub_parser: never return 0 when the input isnt 0
[01:00] <Daemon404> most people would think signing up for a ML for a one line change is retarded.
[01:08] <hotwings> ffmpeg git down?
[01:10] <hotwings> i see, its going insanely slow
[01:26] <cone-789> ffmpeg.git 03Michael Niedermayer 07master:81c1657a593b: avcodec/dvdsub_parser: Check buf_size before reading 32bit packet size
[01:27] <cone-789> ffmpeg.git 03Michael Niedermayer 07master:bcc898dd2643: avcodec/dvdsub_parser: print message if packet is smaller than the packet size field
[01:44] <Compn> wm4 : no, mailing list is not unavoidable for this project
[01:44] <Compn> just have to make friends (or commit directly and make enemies)
[01:45] <wm4> Compn: yeah, I don't get why you have direct push access
[01:45] <wm4> it makes literally no sense
[01:45] <Compn> rcombs : if you tell me what file and what line number ...
[01:45] <Compn> wm4 : everyone in the project has direct push access
[01:45] <Compn> including you iirc
[01:46] <wm4> but you ignore going through reviews and such
[01:46] <Compn> of course, no one calls me on it :D
[01:46] <wm4> I doubt that
[01:46] <Compn> send michael your key and you're in...
[01:46] <rcombs> Compn: http.c around 231
[01:46] <Compn> oh yeah i broke my git environment somehow
[01:46] <Compn> >windows
[01:48] <rcombs> wm4: to push one-line fixes like this, perhaps?
[01:49] <Compn> ssshsshh dont give him any ideas :P
[01:49] <Compn> rcombs : any chance you have a public http that shows this problem ?
[01:49] <Compn> url i mean
[01:50] <wm4> rcombs: no, _all_ changes must go through review, that's how it's handled around here (except when it's not, which is often)
[01:50] <rcombs> Compn: I'm not sure if this is IP-keyed or something (it's definitely time-keyed), but: https://video.internetvideoarchive.net/video.mp4?cmd=6&publishedid=247434&customerid=112548&fmt=4&videokbrate=2500&e=1406937022&h=dbd4db4a743a1f9bbad9745476f3bd65
[01:51] <rcombs> (I didn't include a URL in the ticket because the only ones I have laying around are expiring)
[01:51] <wm4> tls: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
[01:51] <rcombs> ^ yup
[01:51] <wm4> what an intuitive error message
[01:51] <rcombs> on OpenSSL, anyway
[01:52] <wm4> yeah
[01:52] <rcombs> wm4: it's what happens when you try to open an SSL connection to an HTTP server on port 80
[01:52] <rcombs> GNUTLS gives: [tls @ 0x7fe0085000c0] An unexpected TLS packet was received.
[01:53] <rcombs> I'd say that's slightly more user-friendly, but I wouldn't call either out as particularly bad for this case
[01:59] <Compn> i'd hate to commit something thats actively maintained
[01:59] <Compn> without talking to maintainer
[01:59] <Compn> :P
[02:00] <BBB> why is split_cu_flag an array in hevc?
[02:01] <BBB> its nver used out of order
[02:05] <Compn> git blame
[02:05] <Compn> :P
[02:05] Action: Compn runs
[02:08] <Compn> wm4 : example of being useful : https://ffmpeg.org/pipermail/ffmpeg-cvslog/2014-March/074732.html
[02:08] <Compn> :P
[02:11] Action: Compn repairing git environment
[02:15] <Compn> rcombs : like zis ? http://pastebin.com/S66EzYcx
[02:22] <Compn> or probably before the goto fail ?
[02:23] <Compn> wm4 : also i rarely change actual code. mostly docs, web, some typos...
[02:24] <rcombs> Compn: no, in the section with all the 300 codes
[02:24] <rcombs> Compn: alternately, just move the initialization to after the retry: label
[02:24] <wm4> Compn: well, your behavior is in stark contrast to the usual review pedantry
[02:25] <rcombs> erm, `redo:`
[02:25] <Compn> rcombs : yes, be more confusing about this :)
[02:25] <rcombs> Compn: but of course!
[02:25] <Compn> >insert random nsa backdoor
[02:26] <Compn> line 255 maybe ?
[02:26] <rcombs> https://gist.github.com/a9f413560a4a3c0cb493
[02:27] <Compn> yeah theres what i thoughts
[02:27] <rcombs> see why that'd break that?
[02:28] <Compn> yes 
[02:28] <Compn> but
[02:28] <Compn> would it break any other urls, is the real question
[02:28] <Compn> by lowering tcp protocol, i assume so it tries tls instead
[02:29] <rcombs> can't see how it would, as that string is always either "tcp" or "tls", and it's be reset to "tls" if the redirect URL was https://
[02:29] <rcombs> the added line resets the string to what it was the first go-round
[02:30] <Compn> and you get a redirect ?
[02:30] <Compn> i mean in the url
[02:30] <Compn> hmmm
[02:30] <rcombs> and it'd get set back to https by the `if (!strcmp(proto, "https")) {` block if it was meant to
[02:30] <Compn> your efforts to teach me c programming language are futile!
[02:31] <rcombs> :|
[02:31] <Compn> not because you arent doing it right, but because i am dumb
[02:32] <rcombs> (and yes, that patch fixes the issue for me)
[02:32] <rcombs> https://video.internetvideoarchive.net/video.mp4?cmd=6&publishedid=247434&customerid=112548&fmt=4&videokbrate=2500&e=1406939541&h=ada8eb724e2cb25889f6aef45a396489 here, have a new test URL
[02:32] <Compn> oh it is a 302 found
[02:32] Action: Compn wgets
[02:33] <Compn> ok then
[02:34] <Compn> answered that question
[02:34] <Compn> now to see who maintains http
[02:35] <Compn> probably michael
[02:35] <Compn> i just send patch to the list for this one ;)
[02:35] <rcombs> oh boy
[02:35] <Compn> if i dont i think wm4 will try to burn me alive
[02:36] <wm4> I don't really care
[02:36] <michaelni> send patch please
[02:37] <Compn> done
[02:37] <rcombs> *michael will try to burn you alive
[02:39] <Compn> i try to avoid confrontations when possible. its a balance of force commits and let someone else handle it :P
[02:39] <Compn> thanks for the new url rcombs
[02:40] <Compn> sometimes maintainer likes to fix it in different way than patch author fixes it...
[02:40] <rcombs> https://video.internetvideoarchive.net/video.mp4?cmd=6&publishedid=247434&customerid=112548&fmt=4&videokbrate=2500&e=1406940015&h=c6f4e62d7de74df8d325d7ad5df55fca here's another
[02:40] <rcombs> (they expire rather quickly)
[02:40] <Compn> you downloading movie trailers or somethin?
[02:41] <Compn> or make like a trailer display program?
[02:41] <rcombs> Plex just launched support for trailers
[02:41] <Compn> or just avoiding flash player
[02:41] <Compn> ah
[02:43] Action: Compn afk
[03:41] <cone-789> ffmpeg.git 03Michael Niedermayer 07master:956f4087c6eb: ffmpeg_opt: Use av_guess_codec() instead of AVOutputFormat->*codec
[03:41] <cone-789> ffmpeg.git 03Michael Niedermayer 07master:26ffa8eaee2d: avformat/format: use av_match_name() in av_guess_codec()
[04:30] <cone-789> ffmpeg.git 03Michael Niedermayer 07master:98e42a249e78: avformat/format: Check for av_guess_format() failure
[04:46] <cone-789> ffmpeg.git 03Luca Barbato 07master:87efaa97ceb0: af_join: Set the output frame format
[04:46] <cone-789> ffmpeg.git 03Michael Niedermayer 07master:dcd984e24d0a: Merge commit '87efaa97ceb0ad5820870855d6df3e569e6eac7e'
[05:05] <cone-789> ffmpeg.git 03Luca Barbato 07master:f0e959481968: af_channelmap: Set the frame channel layout
[05:06] <cone-789> ffmpeg.git 03Michael Niedermayer 07master:e85bc9df87a1: Merge commit 'f0e959481968b6d906931127237ed981b6414f6e'
[05:27] <cone-789> ffmpeg.git 03Michael Niedermayer 07master:92be540636e1: avcodec/h264_parser: remove redundant assignment
[05:27] <cone-789> ffmpeg.git 03Michael Niedermayer 07master:3fa9692ae232: avcodec/hevc: move HEVCLocalContext declaration into loop
[05:35] <michaelni> ubitux, line 133 (pos = avio_tell(s->pb);) of libavformat/subviewerdec.c seems to have no effect according to CSA
[07:03] <jamrial> so they renamed gcc 4.10 into gcc 5.0
[07:04] <Daemon404> version #s are meaningless anyway
[07:04] <Daemon404> unless 5.0 is extra broken
[07:48] <rcombs> ffmpeg version numbers are useful if you're too lazy to update after ABI changes :3
[09:15] <ubitux> michaelni: i'll  look into this later
[11:06] <ubitux> mmh am i missing something or the sum_abs_dctelem(diff_pixels(x)) in lavfi/mp_decimate is simply... a common sad?
[11:07] <ubitux> a really standard one even, 8x8 block, 8-bit
[11:13] <ubitux> it looks like an unaligned version though
[12:32] <michaelni> smarter, BBB, any oppinion about "0728 19:17 Christophe Gisq (1.3K) [FFmpeg-devel] [PATCH 0/4] Exploit compile-time constant" ?
[12:34] <michaelni> note, the mail says "Premature optimization and overall not that useful." 
[12:52] <ubitux> michaelni: i'll have the asm ported for x86 but not ppc, will that be fine?
[12:52] <ubitux> we only need sad btw, for the filters
[12:53] <ubitux> btw, i'll loose internet in a few hours, but i'll be back soon
[12:53] <michaelni> whats the problem with porting ppc ?
[12:54] <ubitux> testing
[12:54] <michaelni> ask someone who has a ppc
[12:54] <michaelni> also can be ported seperatly and later of course
[12:55] <ubitux> that was the suggestion
[12:55] <ubitux> i'll submit tonight if i get back internet, i'm almost done
[13:04] <michaelni> great, ok
[13:12] <BBB> michaelni: I believe x264 does that too
[13:12] <BBB> michaelni: I havent looked at the patch itself, but if it helps, maybe its useful
[13:12] <BBB> did anyone see my message yesterday?
[13:13] <BBB> Im looking at the array split_cu_flag[], and I feel its unused outside its linear context in a single local function
[13:14] <BBB> so I think it should be modified to just be a local variable in that function, rather than a member of HEVCContext
[13:15] <Compn> rcombs : hows this alternate patch look ? http://pastebin.com/8XaLpCkM
[13:15] <Compn> maintainer always wants to solve it differently :P
[13:15] <Compn> i thought there was already a port > 0 port=80 check...
[13:18] <rcombs> Compn: that leaves a redundant initialization of lower_proto, but it wouldn't cause any issues
[13:18] <rcombs> LGTM
[13:18] <michaelni> BBB, i think a cherry pick from mraulet removed that array already 255086a7e06417d98417cea192053b8a8531eb24
[13:21] <ubitux> Compn: https://en.wikipedia.org/wiki/POWER8 ?
[13:22] <Compn> ubitux : i just havent seen ppc since imac days 2004 1ghz :P
[13:23] <Compn> wow 5ghz 12 core chip
[13:23] <Compn> nice
[13:25] <Compn> now to convince ibm to send me a few boxes...
[13:29] <Compn> also dont remember any new ppc optimizations . most commits to libavcodec/ppc are splitting up files or compilation fixes
[13:35] <Compn> rcombs : ehe, http.c reformat incoming.
[13:36] <ubitux> there is no trick with yasm/x86/x264inc to %rep without incrementing the pointer in the last loop?
[13:54] <BBB> michaelni: ah I see, ok, I probably have a slightly older checkout then
[14:33] <BBB> in luma_intra_pred_mode(), why is the candidate[] array sorted for intra mode decoding?
[14:33] <BBB> were never depending on its ordering in any of the following code
[14:34] <BBB> maybe I should keep a notebook of all these things, then they dont get lost
[14:43] <BBB> Im also massivel confused by this spec thing: intra_pred_mode prediction does not cross vertical CTB boundaries <- that seems ineffective
[15:05] <Compn> BBB : are you hevc devel?  someone on list is wondering about ppc hevc simd 
[15:09] <cone-932> ffmpeg.git 03Matthew Oliver 07master:66627075d960: msvc: fix implicitly declared read/close.
[15:14] <BBB> Compn: what defines hevc devel? if I wrote openhevc, no
[15:14] <BBB> Im basically with mcihael on that one
[15:14] <BBB> if people want to write and maintain them, great
[15:14] <BBB> I wont do it myself - waste of time
[15:39] <Compn> BBB : ok i just forgot whos who around here
[15:41] <BBB> Im the dude that used to work on webm in google and now is just generally interested in video codecs
[15:49] <ubitux> gcc translates this: http://pastie.org/9439162 into this: http://pastie.org/9439163
[15:49] <ubitux> anything better to suggest?
[15:49] <ubitux> (it's at the end of the SAD)
[15:53] <michaelni> ubitux, theres a int16 somehwree why ?
[15:53] <michaelni> also never put 1 asm opcode per asm() i assume this is just for demonstration ?
[15:54] <michaelni> whole inner loop must be in asm()
[15:54] <michaelni> or use yasm
[15:54] <ubitux> it's the current code, i'm doing the yasmification
[15:54] <ubitux> see https://github.com/ubitux/FFmpeg/compare/avpixelutils
[15:55] <ubitux> that sum_mmxext is from libavcodec/x86/me_cmp_init.c
[15:56] <ubitux> i'm trying to understand how the m6 is converted into the return value :p
[15:56] <ubitux> (current yasm code is incorrect, still debugging)
[15:56] <michaelni> current code is crap then
[15:57] <ubitux> maybe yes
[15:57] <michaelni> i mean the sum_mmxext you posted
[15:57] <ubitux> it's doing that for the m6 and m7 init as well
[15:57] <ubitux> basically the sad code are split into 3 separate inline asm assuming it's only one
[15:57] <michaelni> its less risky for these as they declare no in or out so gcc has no reason to salt it with load/stores
[15:57] <ubitux> (and gcc spit crap with it btw)
[15:58] <ubitux> yeah i know
[15:58] <ubitux> that won't happen with the yasm, but i'm trying to understand how the sum is returned properly anyway
[15:59] <michaelni> in eax i assume, ive no idea where ax is comming from
[16:01] <ubitux> yeah i have that part but i'm a bit confused at the psrlq
[16:01] <ubitux> i mean yeah it's adding every part
[16:02] <ubitux> i was wondering if there isn't a better way of doing that
[16:02] <ubitux> the mmx2 code is kind of saner hehe
[16:04] <michaelni> ubitux, waste of time, there are no mmx only cpus in realworld use
[16:04] <michaelni> also its probably not that far off from what is best for mmx
[16:04] <michaelni> it was written at a time closer to when mmx was around and important
[16:05] <ubitux> ok so i port only mmxext and sse?
[16:06] <michaelni> i suggest you port mmx too but dont worry if the instructions you copy to yasm are the best sequence
[16:06] <ubitux> (i looked at the generated code from gcc with the c and it doesn't look automatically sim'ed, even without the -fno-vectorize option we have)
[16:06] <ubitux> michaelni: ok
[16:19] Action: ubitux really hates when termcaps are fucked up when playing with gdb & ffmpeg
[16:36] <BBB> is elem_offset[INTRA_CHROMA_PRED_MODE] + 1 unused?
[16:36] <BBB> I dont see it being used for chroma prediction
[16:44] <Timothy_Gu> michaelni: is SWAMP another Coverity?
[16:44] <ubitux> stupid question: how do i print the mm0..7 registers with gdb?
[16:44] <michaelni> Timothy_Gu, somesthing like that yes
[16:45] <Timothy_Gu> ubitux: info all-register?
[16:46] <ubitux> i don't see them, or at least i don't know the aliased names
[16:46] <ubitux> maybe stX?
[16:46] <Timothy_Gu> $xmm?
[16:47] <Timothy_Gu> never mind. it's stX
[16:48] <Timothy_Gu> It's the same as the same as the floating point regs with the upper few bits all 1 or all 0 (i forgot)
[16:50] <BBB> right
[16:50] <wm4> what is SWAMP?
[16:50] <BBB> whenever I need to debug mmx I tend to just write them to memory and then print that
[16:50] <BBB> I always get confused by stX
[16:50] <BBB> xmm is so much easier
[16:51] <ubitux> it's strange, they don't seem to change when i assign stuff to them
[16:51] <ubitux> always 0x8000000000000000
[16:53] <ubitux> actually, moving data into it or pxor-ing them transform them from 0x0 to 0x8000000000000000
[16:53] <ubitux> i guess that's the good registers anyway
[16:53] <Timothy_Gu> michaelni: what the hell? "Email addresses from "gmail.com" are not allowed."
[16:53] <ubitux> ahah
[16:55] <michaelni> swamp doesnt accept gmail, well thats lame
[16:57] <michaelni> also if anyone wants access to ffmpeg swamp and got no invite, ping me, but remember it seems not to allow gmail and maybe also not similar free mail services
[16:58] Action: michaelni wonders why it didnt say a word about gmail when sending invites
[17:02] <BBB> they dont want to lose customers at the finding phase
[17:02] <BBB> they want gmail to lose customers at the binding phase
[17:05] <wm4> any good alternatives to gmail?
[17:05] <wm4> I think I actually don't mind if they lose me
[17:12] <BBB> right
[17:12] <BBB> I wonder why they dont want gmail
[17:12] <BBB> but obviously no gmail means no go
[17:14] <wm4> yeah
[17:15] <BBB> the transform-tree stuff in hevc is actually sweet, its slightly more dynamic than vp9s
[17:16] <BBB> like, if you have a 16x16 block (cb), you can actually subdivide it in a quadtree, just like prediction structures, thats really sweet
[17:16] <BBB> like topleft 8x8, topright 4x4, bottomleft 8x8, bottomright 8x8
[17:16] <BBB> vp9 can just say all 16x16, all 8x8, or all 4x4
[17:17] <BBB> I wonder how uch that helps
[17:27] <ubitux> ok great, gdb is just actually broken
[17:28] <ubitux> http://pastie.org/pastes/9439311/text
[17:28] <ubitux> "display" doesn't get updated for the stX regs...
[17:33] <ubitux> i guess it doesn't like the /x
[17:34] <anshul_mahe> michaelni, I am matching that patch(Fix 8bit non_mod case) with dvbsubdec spec, thanks for reminding, I really didnt noticed that mail
[17:35] <anshul_mahe> i dont haven't seen any sample using that code, but I will test code coverage with all samples of dvbsub that I have
[17:35] <kierank> michaelni: doesn't seem as good as they make it out to be
[17:35] <kierank> that mir-swamp thing
[17:35] <michaelni> anshul_mahe, thanks
[17:38] <michaelni> kierank, yes, maybe it gets improved, but that gmail thing really kind of kills it, most invites i did sent are to gmail users 
[17:40] <Timothy_Gu> michaelni: BTW I tried my other email address and I still don't receive the confirmation email. I think I'm done with it.
[17:41] <cone-932> ffmpeg.git 03Michael Niedermayer 07master:dd551dc7ff51: avformat/dtsdec: count LE and BE separately in dts_probe()
[17:41] <cone-932> ffmpeg.git 03Michael Niedermayer 07master:e6fabd6e9bfd: avformat/dtsdec: fix signedness in reference pcm highpass in dts_probe()
[17:41] <cone-932> ffmpeg.git 03Michael Niedermayer 07master:2b501b553f63: avformat/dtsdec: skip the first 4k in dts_probe()
[17:42] <michaelni> Timothy_Gu, i can send a separete invite to the other address if you want
[17:45] <JEEB> BBB, yeah - the transform tree stuff in HEVC is nice
[17:46] <Timothy_Gu> michaelni: nah. thanks anyway
[18:31] <cone-932> ffmpeg.git 03Michael Niedermayer 07master:e706fe764049: avcodec/wavpackenc: Fix log2sample() result value
[18:35] <ubitux> michaelni: https://github.com/ubitux/FFmpeg/compare/avpixelutils
[18:35] <ubitux> mmx is still broken for some reason
[18:35] <ubitux> but the rest seems to be working
[18:35] <ubitux> it shouldn't be hard to add an unaligned version of sad
[18:36] <ubitux> (just need to replace the mova into movu)
[18:36] <ubitux> sad_16x16 i mean
[18:38] <cone-932> ffmpeg.git 03Michael Niedermayer 07master:1d8d21b90ab9: ffserver: initialize pbuffer in prepare_sdp_description()
[18:39] <ubitux> ah and btw, i'm unable to make it pick the mmx at runtime
[18:39] <ubitux> CPUFLAGS=mmx or CPUFLAGS=-mmxext still picks the mmxext version
[18:45] <michaelni> what do av_get_cpu_flags() and av_force_cpu_flags() do wrong ?
[18:46] <ubitux> ah, just fixed the mmx, great.
[18:46] <ubitux> michaelni: no idea..
[19:18] <ubitux> ffs deshake should die in fire
[19:19] <wm4> there are other things in lavfi that should go into the fire before that
[19:20] <ubitux> not really
[19:29] <jamrial> libmpcodecs
[19:29] <ubitux> this one is still useful
[19:29] <ubitux> and at least it seems to work
[19:29] <wm4> yeeeah.
[19:30] <wm4> these hordes of users who use libavfilter for pp7
[19:30] <wm4> that nobody is porting them is kind of proof that nobody really cares, at least not devs
[19:31] <Compn> it works , why port it ? ;p
[19:31] <Compn> deshake, that was one of the features in the libav vs ffmpeg list :D
[19:31] <Compn> guys you think we should do a survey of ffmpeg users, find out what features they use and dont use ?
[19:32] <jamrial> you mean cli users?
[19:33] <Compn> all users
[19:33] <Compn> we will send survey to downstreams too
[19:33] <Compn> and other projects that only use libs
[19:33] <wm4> simple, just make ffmpeg phone home
[19:38] <ubitux> all the users aren't on ffmpeg-user
[19:41] <Compn> right , i never said to put the survey there
[19:41] <Compn> put it on phoronix , doom9 , slashdot, reddit etc
[19:41] <Compn> hackernews
[19:41] <Compn> 4chan tech board
[19:42] <wm4> why not a place where there are actually intelligent people?
[19:42] <wm4> anyway, I predict the number of users of pp7 will be 1
[19:42] <Compn> sure, wheres that wm4 ? 
[19:42] <wm4> that's a good question
[19:42] <Compn> always looking for new communication mediums
[19:42] <Compn> facebook or google group circle ? :P
[19:43] <Compn> er google plus circle
[19:43] <Compn> whatever the hell they call it this week
[19:50] <anshul_mahe> why not put in on ffmpeg.org, list of feature and one like click, or better on trac there if only registered user are allowed
[19:51] <anshul_mahe> we already have upvote things for each bug, we can have for each feature.
[19:52] <cone-932> ffmpeg.git 03Diego Biurrun 07master:ffa4d4ef0bd6: ppc: fft: Build AltiVec optimizations in the standard way
[19:52] <cone-932> ffmpeg.git 03Michael Niedermayer 07master:146e498c9eb1: Merge commit 'ffa4d4ef0bd66c4e8bde7357b69bdedc78123ea8'
[19:52] <anshul_mahe> Compn, you have to take care for maintaing that ;)
[20:20] <cone-932> ffmpeg.git 03Michael Niedermayer 07master:17fef17f67c5: avfilter/lavfutils: remove redundant variable init
[20:20] <cone-932> ffmpeg.git 03Michael Niedermayer 07master:08b6591cf6d3: avcodec/avuienc: move pointer declaration to where its used
[20:29] <ubitux> michaelni: i think you should add the get_pixels helper to the AVDCT context
[20:29] <ubitux> since it's main usage seems to be the extraction+unpack for DCT
[20:29] <ubitux> its*
[20:30] <ubitux> and with that and the pixelutils api i think we covered all the issues you originally proposed to fixed with the AVDSP patchset
[20:30] <ubitux> fix*
[20:31] <ubitux> BBB: pixelutils aren't enabled unless one of the filters is selected, so it should be a no-op for chrome
[20:33] <jamrial> ubitux: you made the sad functions sse instead of sse2
[20:34] <ubitux> it's not sse?
[20:34] <BBB> yay
[20:34] <BBB> nice
[20:34] <jamrial> integer xmm started with sse2
[20:37] <michaelni> ubitux, your struct layot depends on the NB of enums (posted to ml too but saying here too so you dont miss it)
[20:37] <ubitux> ah, true
[20:42] <ubitux> michaelni: should i declare up to 64x64 and mark it as definitive?
[20:42] <ubitux> or should i make a dynamic alloc and a special free function?
[20:48] <michaelni> that or add a few reserved entries for future extension or use a function instead of struct to obtain function pointers, no real preferrance to which from me, also there surely are other options
[20:49] <michaelni> i think though declaring squares from2x2 to 64x64 as the strict limit is a bit 64k is enough for everyoe smelling
[20:52] <michaelni> something like fptr = av_getutildsp(AVUTIL_DSP_SAD, 8, 8, AVUTIL_DSP_SRC_ALIGNED) maybe
[20:52] <ubitux> parse error around `is a bit 64k'
[20:53] <michaelni> with better names of course, they are just examples
[20:53] <ubitux> yeah i could make getters, that's actually how i use it in the filters
[20:53] <ubitux> i guess i'll do that
[20:54] <michaelni> ok, and ill get that get_pixels into avdct
[20:55] <michaelni> about 64k i was just comparing the of 2x2-64x64 limit to a quote that "64k (main memory) will be enough for everyone"
[20:58] <ubitux> ok :)
[21:03] <ubitux> michaelni: would it make sense to just have a getter to simplify the interface?
[21:04] <ubitux> the getter would initialize the functions every time, but since it should be done just a few times once for every needed function it should be a problem
[21:11] <michaelni> yes, also it can cache the functions in the future using a static struct thats initialized by memcpy() it just needs to be done carefully so theres no race
[21:12] <michaelni> but for now just calling the dsp* init each time should be ok
[21:37] <ubitux> i'll send a new patchset in a moment
[21:51] <ubitux> michaelni: https://github.com/ubitux/FFmpeg/compare/avpixelutils#diff-2274161fb2ffa57c3b31b46697751fb0R26
[21:51] <ubitux> the diff is much smaller that way
[21:51] <ubitux> i'll honor jamrial comments and resubmit a v2 that way
[21:52] <ubitux> basically, you just have 1 function to call
[22:00] <cone-932> ffmpeg.git 03Michael Niedermayer 07master:d73371b58c3d: avcodec/mmvideo: remove unused return value and assignment
[22:23] <michaelni> ubitux, lgtm from a quick look
[22:23] <ubitux> i'm adding the tests
[22:23] <ubitux> i should be done in about an hour
[22:24] <cone-932> ffmpeg.git 03Michael Niedermayer 07master:459996325dab: avcodec/error_resilience: comment out unused  assignment
[22:24] <cone-932> ffmpeg.git 03Michael Niedermayer 07master:c103c4852528: avcodec/error_resilience: make error an local variable where possible
[22:35] <ubitux> mmh i wrote the test tool
[22:36] <ubitux> how do i make the test relevant for fate?
[22:36] <ubitux> like, can i make a diff of the output?
[22:36] <ubitux> all the libavutil/*-test seem to CMP against nothing
[22:38] <ubitux> should i simply assert into it?
[22:39] <michaelni> they use the return code IIRC
[22:40] <ubitux> oh ok
[22:40] <ubitux> perfect then
[22:44] <ubitux> michaelni: doesn't seem to help
[22:47] <ubitux> ah, maybe i'm doing something wrong
[22:50] <michaelni> Timothy_Gu, it seems accoridng to carl the new fate page isnt useable on iphone, and iam seeing that the right side of the table is cut off on android
[22:55] <ubitux> jamrial: are you sure i can use HADDW macro in mmx code?
[23:01] <jamrial> yeah, i added support for mmx to it a couple weeks ago
[23:03] <jamrial> it however uses different instructions than the ones you used, though
[23:03] <jamrial> no idea what would be faster
[23:07] <ubitux> error: undefined symbol `pw_1' (first use)
[23:07] <ubitux> heh
[23:07] <ubitux> kind of contraining
[23:07] <ubitux> i'll keep my version for now
[23:11] <cone-932> ffmpeg.git 03Michael Niedermayer 07master:17c656518623: avcodec/mpeg12dec: Document Ticket3809 fix
[00:00] --- Sun Aug  3 2014