burek021 at gmail.com
Wed May 14 02:05:02 CEST 2014
[00:22] <BBB> plepere_: you made the change on both sides of that macro right, i.e. in both "mov [%1+4], r8" as well as "mov r8,[%1+4]"
[01:06] <cone-717> ffmpeg.git 03Aaron Graham 07master:72dcd48c19a6: avformat/asfenc: honor the maximum of 63 payloads
[03:57] <compn> is it possible to have binary identical frame multithreading ? i think people would be happy to have that available even if it causes a small performance hit. as an option anyways
[04:11] <BBB> Compn: what does that even mean?
[04:11] <BBB> Compn: decoding of most media formats is by definition binary identical
[04:11] <BBB> Compn: and yes, all ffmpeg frame-mt is binary identical to single-threaded decoding
[04:14] <BBB> Compn: or do you mean encoding?
[04:15] <compn> encoding
[04:17] <BBB> ah, yes, that can be done for academic purposes, I wouldn't be surprised if x264 already does it
[04:17] <Skyler_> that's probably not possible, at least not without some severe constraints
[04:17] <BBB> oh
[04:17] <BBB> well ignore me for that then
[04:17] <Skyler_> most of which would consist of "apply the multithreaded constraints to singlethreaded mode"
[04:17] <Skyler_> along with I guess "no ratecontrol"
[04:18] <Skyler_> (you can always cheat by making singlethreaded do the multithreaded thing, then they're the same ;-) )
[04:24] <compn> Skyler_ : what about doing chunks of video in paralell until hit a keyframe ?
[04:25] <compn> i guess it would require a larger readahead / buffer or precise seeking
[04:25] <compn> wouldnt work on streamed content either
[04:26] <Skyler_> gop threading is possible, but that -definitely- couildn't be bit identical if you had any form of scenecut detection (unless that ran separately ahead of everything) or ratecontrol
[04:28] <compn> sure no ratecontrol then, cbr only ?
[04:34] <Skyler_> CBR is ratecontrol
[04:34] <Skyler_> so, CRF/QP only
[04:35] <Skyler_> well, really, CQP only, since macroblock tree would break too unless you did it all in a single lookahead.
[09:07] <plepere_> BBB : of course. :p
[11:41] <Voicu> can I make the read functions used by avio contexts blocking?
[11:42] <Voicu> or what should I do if the read callback is requested a larger data piece than currently available?
[11:44] <nevcairiel> there is no reason it can't block
[11:44] <nevcairiel> or you can return a smaller piece
[11:44] <nevcairiel> whatever fits your design better
[11:54] <Voicu> nevcairiel, ok thank you
[12:38] <BBB> plepere_: ok - and still the same functions that break?
[12:42] <BBB> plepere_: I also see other lines like "add r3, 4" and same for r2
[12:43] <BBB> plepere_: so I guess maybe the 4 is intentional
[12:43] <BBB> plepere_: if that's the case, just do mov dword [%1], r7 and mov sword [%1+4], r8 in SHIFT_LEFT_PARAM
[12:43] <BBB> r7d also then
[12:44] <BBB> or change it to %if gprsize == 8 mov r7, qword [%1] shl r7, 2 mov qword [%1], r7 %else current code %endif
[12:45] <BBB> plepere_: I think the fundamental problem is that the second mov at the end of SHIFT_LEFT_PARAM overwrites stack that is owned by the calling function
[12:46] <BBB> plepere_: and am just trying to figure out what the intention of that code is, I don't have the c code in front of me so I don't really know
[12:47] <BBB> plepere_: HTH ;)
[12:56] <BBB> plepere_: (I guess I'm starting to see the comments that r2 is betas and r3 is tcs, which are arrays of type uint8_t and size , not pointer-to-pointer which is what I thought it was)
[13:54] <Daemon404> i wonder if all these ER and mpegdec patches lately from michaelni have anything to do with spacex
[13:54] <Daemon404> /conspiracytheory
[14:01] <nevcairiel> they do
[14:01] <nevcairiel> iirc, someone asked
[14:01] <Daemon404> nevcairiel, is tehre anywhere i can peek at progress?
[14:01] <Daemon404> or rather, how will michael publish his results
[14:01] <Daemon404> ive never seen him on reddit :P
[14:07] <ubitux> Daemon404: i had to add support for \r in subtitles recently generated
[14:07] <Daemon404> yeah ive seen that in the wild
[14:07] <Daemon404> iirc some formats even mandate it
[14:07] <Daemon404> (ancient formats)
[14:09] <michaelni> Daemon404, http://spacexlanding.wikispaces.com/, http://forum.nasaspaceflight.com/index.php?topic=34597.0
[14:10] <Daemon404> are you in that thread/
[14:10] Action: Daemon404 sees 40 pages
[14:11] <Daemon404> ah i see some references to you
[14:11] <Daemon404> nice mini introduction to video coding lol.
[14:23] <BBB> someone is working on ER?
[14:23] <BBB> omg that is like ancient
[14:24] <BBB> good thing I guess
[14:24] <BBB> how about hevc-er and vp8/9-er?
[14:24] <smarter> that would be nice
[14:33] <mraulet> BBB: we have one implementation in hevc decoder that replaces the current frame with the previous one (it is already in ffmpeg)
[14:33] <Daemon404> thats "ER"
[14:35] <mraulet> if ER means what I think :)
[14:35] <cone-70> ffmpeg.git 03Mickaël Raulet 07master:053fdacde76a: hevc: a much faster implementation of intra prediction (up to 1s on haswell 2.6GHz on basket ball drive all intra qp 27)(cherry picked from commit 5de9739176f0eb4c205e80a91628a0196c9924b2)
[14:35] <cone-70> ffmpeg.git 03Mickaël Raulet 07master:38df49a068c8: hevc/intrapred: fix indent(cherry picked from commit ab167f3158cf37bd679bda28566170e2c3691686)
[14:35] <cone-70> ffmpeg.git 03Mickaël Raulet 07master:bb9e5116fe5b: hevc: fixing code indenting in hevcpred(cherry picked from commit 28a5916845928de2951013b5398465573b181925)
[14:36] <iive> michaelni: one quick question. mpeg ts packets have a bit in the ts header that says if the packet is damaged. is that bit set for any of these packets?
[14:37] <plepere_> BBB : thanks for your insight
[14:37] <michaelni> iive every bit is probably set in one of the xx thousand packets
[14:38] <iive> michaelni: well, if there have been FEC correction, then broken packets should have been marked.
[14:38] <plepere_> BBB : I'm trying to use the x86util.asm transpose code instead of the one defined in hevc_deblock.asm
[14:38] <iive> if the data have been written in flash memory, then it wouldn't matter.
[14:59] <ubitux> nevcairiel: so MS is not gonna fix the ebur128 vectorization bug in 2012?
[14:59] <nevcairiel> 2012 is dead to them
[15:00] <Daemon404> next april 1st maybe ill try and add visual studio 6 support
[15:01] <ubitux> i'd love to see you submitting a VB6 binding instead
[15:01] <Daemon404> maybe i can compile ffmpeg as an ocx
[15:02] <ubitux> can you try to make a build < 64k so it sticks in a .com?
[15:02] <Daemon404> 16bit ffmpeg?
[15:59] <cone-70> ffmpeg.git 03Olivier Langlois 07master:f1c167496e41: Support broadcast destination for udp protocol
[16:09] <cone-70> ffmpeg.git 03Matt Oliver 07master:cef99e12bc49: Use rac_get_prob branchy version when used within a conditional branch.
[20:30] <ubitux> i can do some testing on mine if necessary btw
[20:30] <ubitux> ah and well i guess i could let it up somewhere and provide ssh accesses if someone wants one
[20:34] <jamrial> that'd be great, yes
[20:34] <ubitux> ok, let me think how i'm gonna do that
[20:36] <nevcairiel> i could also provide ssh access to avx2
[20:36] <nevcairiel> or even rdp access to a windows box if someone ever needs to :p
[20:37] <Skyler_> the intel SDE can at least be used for testing/FATE
[20:40] <jamrial> i've been using that to check asm i write is valid, but it can't be used to benchmark it
[20:40] <jamrial> also, it's too slow. fate runs could take hours with it
[20:40] <Skyler_> yeah
[20:40] <Skyler_> true
[20:40] <cone-70> ffmpeg.git 03Janne Grunau 07master:9aa4592076d4: aarch64: assembler in clang-3.4 ignores the division by two
[20:41] <cone-70> ffmpeg.git 03Michael Niedermayer 07master:76581ab83387: Merge commit '9aa4592076d4dbb29d1198b0e258f9f85c0c00b5'
[20:45] <kierank> I have a lot of AVX2 machines on my desk
[20:45] <kierank> but no permanent internet connection
[20:49] <ubitux> jamrial: do you have a pub key somewhere?
[20:50] <jamrial> One sec
[20:54] <cone-70> ffmpeg.git 03Reimar Döffinger 07master:d90ba411aba2: dpx: use intfloat.h instead of deprecated intfloat_readwrite.h.
[22:40] <jamrial> 439 decicycles in dc, 131070 runs, 2 skips
[22:40] <jamrial> 1219 decicycles in dc, 131070 runs, 2 skips
[22:40] <jamrial> This being dc_32x32
[22:41] <jamrial> first is avx2, of course
[22:42] <ubitux> :)
[22:44] <Skyler_> nice!
[22:52] <cone-70> ffmpeg.git 03Janne Grunau 07master:449511740f06: build: handle library dependencies in configure
[22:52] <cone-70> ffmpeg.git 03Michael Niedermayer 07master:3d7218d93292: Merge commit '449511740f06a4675b0066730fa45cdb764ffafc'
[22:52] <cone-70> ffmpeg.git 03Michael Niedermayer 07master:efa959683174: common.mak: fix (not)building disabled libs
[22:52] <cone-70> ffmpeg.git 03Michael Niedermayer 07master:f0ae467e6c80: configure: swresample depends on avutil
[22:54] <michaelni> ubitux, can you move EBUR128LIBS dependancy thing be moved to configure ?
[22:55] <michaelni> move THE .... s/ be moved//
[22:57] <ubitux> something like "enabled ebur128_filter && enabled swresample && prepend avfilter_deps swresample"?
[22:59] <ubitux> i don't remember how i'm supposed to test that
[23:00] <jamrial> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902 finally backported to gcc-4.9 branch
[23:01] <ubitux> jamrial: the gcc 4.9 you have access to should have that patch anyway
[23:02] <michaelni> ubitux, yes i think so, should be quite trivial
[23:02] <jamrial> cool
[23:03] <ubitux> michaelni: i've the patch locally but dunno how to test
[23:05] <michaelni> does en/disabling the filter & swresample work or is that not possibly ?
[23:12] <ubitux> ok seems good
[23:15] <cone-70> ffmpeg.git 03Clément BSsch 07master:c683e6aa2c69: build: move ebur128 swr dep to configure.
[23:31] <michaelni> ubitux, thx
[23:42] <Zeranoe> Ignore the caps, but this seems odd: http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=5&t=1971 How are dates determined
[23:45] <J_Darnley> Zeranoe: it uses the __DATE__ and __TIME__
[23:49] <Zeranoe> J_Darnley: What defines that
[23:49] <iive> gcc
[23:50] <J_Darnley> (or any other compile you mat use)
[23:50] <Zeranoe> So any ideas whats happening here
[23:50] <J_Darnley> (or any other compiler you may use)
[23:51] <J_Darnley> 1 - it looks like you are not pulling new code since the copyright date is from last year and the revision number is ~10k less
[23:52] <J_Darnley> 2 - The clock on the computer is wrong
[23:52] <J_Darnley> 3 - Tie travelling VMs
[23:52] <J_Darnley> *time
[23:53] <J_Darnley> For the first I would suggest the fix-all solution: pulling from git into a clean directory
[23:54] <Zeranoe> date reports: Tue May 13 17:54:23 EDT 2014
[23:54] <Zeranoe> cloning now
[23:57] <iive> time traveling might be related to timezone
[00:00] --- Wed May 14 2014
More information about the Ffmpeg-devel-irc