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

[burek]

[00:47] <cone-220> ffmpeg.git 03Carl Eugen Hoyos 07master:3a1feb01da61: Fix standalone compilation of image2_alias_pix and image2_brender_pix demuxers.
[01:33] <cone-220> ffmpeg.git 03Michael Niedermayer 07master:a47cc877a072: avfilter/vf_rotate: increase fixed point precision
[01:33] <cone-220> ffmpeg.git 03Michael Niedermayer 07master:4ebfb2c5ec7d: avfilter/vf_rotate: fix location of update operation
[01:33] <cone-220> ffmpeg.git 03Michael Niedermayer 07master:c9aab1ee7f33: avfilter/vf_rotate: fix several of by 1 errors
[01:33] <cone-220> ffmpeg.git 03Michael Niedermayer 07master:d340dabb7635: avfilter/vf_rotate: make int*90° rotates suck less speedwise
[03:47] <cone-220> ffmpeg.git 03James Almer 07master:d8f40ca25148: fate: add DTS-ES test
[04:23] <cone-220> ffmpeg.git 03csheng 07master:549bbdfb4ba4: avformat/wavdec: enlarge probe_packets for wav
[04:33] <cone-220> ffmpeg.git 03Peter Ross 07master:c94305ae2331: ff_id3v2_free_extra_meta: set the pointer pointing to extra_meta to NULL
[04:33] <cone-220> ffmpeg.git 03Peter Ross 07master:5331773cc33b: ff_id3v2_read: add option to limit ID3 magic number search
[06:26] <cone-220> ffmpeg.git 03Peter Ross 07master:ab683efb2b93: Magic Lantern Video (MLV) demuxer
[06:26] <cone-220> ffmpeg.git 03Peter Ross 07master:f45a840907c2: avformat/mlv: add fate sample
[07:45] <Zeranoe> Is it intentional that the print_options.c are compiled with a native compiler and not the specified cross compiler?
[07:51] <jamrial> Yes, it's for texi generation
[09:50] <ubitux> michaelni: so should we use rotate filter inconditionally?
[10:47] <linkmauve1> ubitux, I found another more specialised dol file: http://linkmauve.fr/files/h4m.dol
[10:47] <linkmauve1> But no debug informations.
[10:47] <ubitux> and so you can't get an assembly dump out of it?
[10:49] <linkmauve1> I found some disassembly resources, Im going to try.
[10:54] <linkmauve1> There is a dol plugin for IDA, but it seems to be a paid disassembler. :( http://blog.delroth.net/2012/03/gcwii-dol-plugin-built-for-ida-6-1/
[10:56] <ubitux> yeah IDA is far from free
[10:59] <ubitux> linkmauve1: can't you get something out of a simple ppc disassembler?
[11:00] <linkmauve1> Probably.
[11:01] <linkmauve1> Also audio is an ADPCM format, and there is a program to extract it (but it doesnt work on my sample files): http://hcs64.com/files/h4m_audio_decode03.zip
[11:01] <linkmauve1> IMA ADPCM
[11:03] <ubitux> linkmauve1: https://github.com/dolphin-emu/dolphin/blob/master/Externals/Bochs_disasm/PowerPCDisasm.cpp
[11:03] <ubitux> i see some instruction printing, so that's probably possible to get something out of the emulator
[11:03] <linkmauve1> This is a runtime disassembler, AFAIK.
[11:04] <linkmauve1> But yeah, it should be possible to use.
[11:04] <linkmauve1> Im going to try to convert the dol file into an elf and then use objdump.
[12:32] <linkmauve1> ubitux, alright, http://linkmauve.fr/files/h4m.elf.txt
[12:33] <linkmauve1> I had to compile devkitppc, it was slow.
[12:39] <michaelni> ubitux, id say use rotate after checking its not slower
[12:39] <michaelni> some cases need a oh=iw:ow=ih though
[12:40] <michaelni> thats maybe something that could be simplified further
[12:52] <linkmauve1> I really dont know what to do with that PPC code. :(
[13:41] <cone-325> ffmpeg.git 03Peter Ross 07release/1.2:5219e20d58e1: ff_id3v2_free_extra_meta: set the pointer pointing to extra_meta to NULL
[13:41] <cone-325> ffmpeg.git 03Peter Ross 07release/1.2:7f8aa37bc366: ff_id3v2_read: add option to limit ID3 magic number search
[13:41] <cone-325> ffmpeg.git 03Peter Ross 07release/2.1:caeed48982a1: ff_id3v2_free_extra_meta: set the pointer pointing to extra_meta to NULL
[13:41] <cone-325> ffmpeg.git 03Peter Ross 07release/2.1:7269ab10c517: ff_id3v2_read: add option to limit ID3 magic number search
[13:41] <cone-325> ffmpeg.git 03Peter Ross 07release/2.2:b45cd17d291d: ff_id3v2_free_extra_meta: set the pointer pointing to extra_meta to NULL
[13:41] <cone-325> ffmpeg.git 03Peter Ross 07release/2.2:30cf47c6f016: ff_id3v2_read: add option to limit ID3 magic number search
[13:47] <cone-325> ffmpeg.git 03Martin Storsjö 07master:4936ef6492f6: configure: Handle armcc 5.0
[13:47] <cone-325> ffmpeg.git 03Michael Niedermayer 07master:e8fc91e22a60: Merge commit '4936ef6492f640e1606c6507f2c4e495164d3974'
[14:19] <cone-325> ffmpeg.git 03Carl Eugen Hoyos 07master:72c93abaad70: Use MANGLE in cavsdsp.c to save two registers using gcc.
[14:19] <cone-325> ffmpeg.git 03Carl Eugen Hoyos 07master:b38910c97902: Fix compilation with !HAVE_6REGS.
[14:19] <cone-325> ffmpeg.git 03Michael Niedermayer 07master:c91a798a2c36: Merge remote-tracking branch 'cehoyos/master'
[14:32] <cone-325> ffmpeg.git 03James Almer 07master:3b06208a57b4: x86/float_dsp: remove duplicated code from vector_dmul_scalar
[14:56] <Rodeo> michaelni: you around?
[15:02] <wm4> ubitux: what happened to divtc? what replaces it?
[15:04] <ubitux> wm4: paul removed it
[15:04] <ubitux> i wonder if divtc ever worked with the wrapper
[15:05] <wm4> no patch on the mailing list...
[15:06] <wm4> f0a149e53827f158fc0449707940d837c4b1c4af lavfi: remove bad inverse telecine filters
[15:06] <ubitux> http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2013-April/142453.html
[15:07] <ubitux> wm4: you have a need for that filter?
[15:07] <wm4> I don't know
[15:08] <wm4> I also need a replacement for vf_eq2
[15:10] <ubitux> i think pullup and fieldmatch/decimate are meant to be the replacement of any other ivtc filter
[15:13] <Rodeo> has pullup been ported to libavfilter yet?
[15:13] <wm4> Rodeo: yes
[15:14] <Rodeo> cool
[15:20] <ubitux> linkmauve1: you should isolate the code that does the decode, and ideally... you want to be able to trace it at runtime
[15:20] <ubitux> that's probably why you would need to interface with your emulator
[15:21] <linkmauve1> Ok.
[15:37] <BBB> I'm looking at these rules for edge "availability" for hevc intra pred and my eyes just hurt
[15:38] <BBB> it's like "what the ... were these dudes smoking"
[15:38] <BBB> it must've been some really good stuff
[15:38] <smarter> haha
[15:39] <wm4> VP10 will have something better?
[15:39] <BBB> dunno, I'm not involved in vp10 development
[15:40] <smarter> if you ignore the constrained intra pred stuff (which was also part of h264 I think) it's not too bad
[15:40] <BBB> yeah I was planning on doing that, at least for now
[15:41] <BBB> so can we put this in english?
[15:42] <BBB> so my understanding is left is available if we're not the first block in this slice/tile/line
[15:42] <BBB> top is available if we're not the top block row in this image/tile/slice
[15:42] <BBB> top left is top&&left
[15:43] <BBB> topright/bottomleft=???
[15:44] <smarter> the top pixels are the pixels on top of the current block, the topright pixels are the one which are just after the top pixels
[15:45] <smarter> so they're available if this is not the first row of the image/tile/slice or if the block on the top right has already been coded(which is possible since coding is done in Z-order)
[15:46] <smarter> bottom left is similar
[15:46] <smarter> well not exactly
[15:46] <smarter> left pixels are the one which are to the left of the current block, bottomleft pixels are the one below the left pixels
[15:48] <smarter> I think the spec has some pictures to explain that
[15:48] <smarter> and then there are some rules to replace the unavailable pixels
[15:49] <smarter> left[0] to left[X] is available but not left[X+1] to left[N], then left[X+1] to left[N] get assigned the value of left[X]
[15:50] <smarter> something similar happens for top
[15:51] <BBB> hmm, so I remember drawing this out for vp9 once when we faced that question of "which pixels are available when"
[15:51] <BBB> and then we simplified it into something that isn't really quite optimal but at least can be put in 2 lines of code
[15:51] <smarter> and _then_ there is the filtering process which tries to make the samples used for predicting smoother
[15:51] <BBB> I guess this is what happens when stuff gets fuzzy
[15:51] <BBB> the filtering is just 3tap 1:2:1 right?
[15:52] <BBB> vp8/9 do that too, but have it embedded in the directional prediction itself
[15:52] <smarter> I think so(see hevcpred_template.c, grep for "Filtering process")
[15:52] <BBB> I see that here it's more complicated than that, where the directional is actually a second filter in and by itself
[15:52] <BBB> I don't have a spec btw
[15:52] <BBB> is it freely available somewhere?
[15:52] <smarter> yeah
[15:52] <smarter> ITU
[15:53] <smarter> http://www.itu.int/rec/T-REC-H.265-201304-I
[15:53] <smarter> there's also the strong intra smoothing mode which can be optionally enabled for 32x32 blocks
[15:56] <BBB> oh I saw that yes
[15:56] <BBB> that's really weird stuff
[15:57] <BBB> but hey, we're a hevc standard so everything is patentable and standards are like printer ink - it's pure gold
[16:05] <JEEB> lörs lärä
[16:25] <ubitux> gdb daily wtf: http://pastie.org/pastes/9093446/text
[16:26] <ubitux> ("int 3" = new feature? -- why the pshufb xmm reg loose their 'x'?)
[16:41] <Guest25204> hi think i should have joined this instead of ffmpeg. pasting...
[16:41] <Guest25204> hello i have a question. im piping a bunch of png's to ffmpeg and its processing fine until near the end of the pipe. at frame/png 55 it stops... nothing happens... and i have to close my binary writer to get it to continue then i get a pipe input/output error.. and it finishes off... why doesnt the pipe close gracefully?  http://pastebin.com/KnFTHh6U
[16:42] <Guest25204> driving me nuts... if i dont use pipe and test using the cmd line , it works fine with a image%d.png for input... but when piping it seems to hang. like its waiting for some buffer to be dealt with.but im already reading the output stream and error stream.
[16:42] <Guest25204> oh i see this is for devel of ffmpeg itself. sorry
[17:02] <cone-325> ffmpeg.git 03Clément BSsch 07master:b8d002dc9501: vp9/x86: clarify mixed splatb.
[17:32] <cone-325> ffmpeg.git 03Clément BSsch 07master:010732b73a08: vp9/x86: simplify FILTER_INIT.
[18:25] <BtbN> Is compiling ffmpeg with msvc broken in 2.2.1? It tries to pass unix paths to cl
[18:29] <cone-325> ffmpeg.git 03Vittorio Giovara 07master:58400ac133bc: lavfi: name anonymous structs
[18:29] <cone-325> ffmpeg.git 03Michael Niedermayer 07master:74a8dbe1c405: Merge commit '58400ac133bcfb6bf8196b4e5208bc178307739b'
[18:31] <BtbN> ok, found the problem. Out-of-tree builds don't work with msvc aparently.
[18:38] <cone-325> ffmpeg.git 03Vittorio Giovara 07master:d23fc8846d25: filtfmts: remove unused lavf include
[18:38] <cone-325> ffmpeg.git 03Michael Niedermayer 07master:6ca0a976b2e6: Merge commit 'd23fc8846d255e31896453136b4c77bc6d5e873f'
[18:44] <cone-325> ffmpeg.git 03Vittorio Giovara 07master:6ef96292d993: utils: add yvyu422 to avcodec_align_dimensions2
[18:44] <cone-325> ffmpeg.git 03Michael Niedermayer 07master:c1bc20bfd9f6: Merge commit '6ef96292d99302a59f824713fc763f6abd3754df'
[19:04] <cone-325> ffmpeg.git 03Janne Grunau 07master:34c5a6660a9e: h264: codec reinit: remove statements without effect
[19:04] <cone-325> ffmpeg.git 03Michael Niedermayer 07master:928b5708f94c: Merge commit '34c5a6660a9e5e3cf301691bb29d011638953dc2'
[19:28] <cone-325> ffmpeg.git 03Peter Ross 07master:07761294fc3f: Silicon Graphics RLE 8-bit video decoder
[19:28] <cone-325> ffmpeg.git 03Michael Niedermayer 07master:e37dbfddda03: Merge commit '07761294fc3f08e139e8a406ef7d5b63aaf1ecee'
[19:55] <kurosu> the strong intra smoothing was adopted at the last minute because of a strong visual issue
[19:56] <kurosu> basically, you'd create edges that didn't exist because of the quantization noise
[20:01] <cone-325> ffmpeg.git 03Peter Ross 07master:86a043268821: Silicon Graphics Motion Video Compressor 1 & 2 decoder
[20:01] <cone-325> ffmpeg.git 03Michael Niedermayer 07master:0c67ef272943: Merge commit '86a0432688216562926d4aee36118f01be6d5e1b'
[20:37] <cone-325> ffmpeg.git 03Peter Ross 07master:55ddd700c675: Silicon Graphics Movie demuxer
[20:37] <cone-325> ffmpeg.git 03Michael Niedermayer 07master:01a39a978c14: Merge commit '55ddd700c67529ff2c6c4e976673f1341bba7a82'
[20:49] <ubitux> so what's the avx2 trick to avoid vinserti128(vpunpcklbw(x, 0), vpunpckhbw(x, 0)) ?
[20:49] <ubitux> i naively thought vpunpcklbw x, 0 would been enough but...
[20:50] <ubitux> x being a ymm reg with only low filled, and i want to b->w to a whole ymm reg
[20:55] <ubitux> Skyler_ ^ ? :)
[20:56] <cone-325> ffmpeg.git 03Vittorio Giovara 07master:6dfd99c93808: fate: add tests for SGI RLE and MVC1&2 decoders
[20:56] <cone-325> ffmpeg.git 03Michael Niedermayer 07master:75ef907db80f: Merge commit '6dfd99c93808d6504dd5cb1fad847d68cb179352'
[21:59] <Skyler_> ubitux: pmovzxbw
[22:00] <ubitux> oh this sounds perfect, thx!
[22:04] <JEEB> I love those instruction names
[22:14] <nevcairiel> thats a nice instruction, its somewhat common that I do a load followed by unpack, wonder if its worth using it for xmm as well (I haven't really payed much attention to the sse3/4 instructions, tbh)
[22:15] <Skyler_> It's not actually faster than punpcklbw, it's often slower, for no explained reason
[22:15] <Skyler_> it's useful in avx2 because it's cross-lane
[22:15] <nevcairiel> i see
[22:16] <Skyler_> (basically it's typically not worth making pmovzxbw versions of punpcklbw functions)
[22:16] <Skyler_> pmovsx is useful though since sign extension often takes more instructions 
[22:16] <nevcairiel> i quickly looked it up in the docs and it seemed to have low latency and throughput
[22:16] <nevcairiel> but if its still slow, oh well
[22:21] <Skyler_> it's 3/1
[22:21] <Skyler_> what I meant is, on pre-avx2, i.e. 128-bit instructions
[22:21] <Skyler_> -in practice- it usually proves to be equal to or slower than punpcklbw-with-zeroes
[22:22] <Skyler_> I don't know why it's /ever/ slower; it probably shouldn't be, but it is.
[22:22] <Skyler_> pengvado's guess was something like "it pairs the load and zero-extend uop so they have to execute in the same cycle" or something
[22:23] <nevcairiel> interesting
[22:23] <nevcairiel> i should finally sit down and avx2 some of my sse2 code, its just so slow with 4k video, and i would learn something at the same time
[23:01] <BBB> ah yay we're building avx2 experts
[23:01] <BBB> that can only be good
[23:01] <BBB> ubitux: war are you avx'ing? :)
[23:03] <cone-325> ffmpeg.git 03Martin Storsjö 07master:911fa05b514e: mvc: Specify the pixel format for the mv-mvc* tests
[23:03] <cone-325> ffmpeg.git 03Michael Niedermayer 07master:373d7dd37160: Merge commit '911fa05b514e1be009e00b79d7004b93717c023b'
[00:00] --- Sun Apr 20 2014