[01:19] <cone-108> ffmpeg.git 03Carl Eugen Hoyos 07master:e337c9d56408: Read h264 headers from v4l2 to allow stream-copying. [01:19] <cone-108> ffmpeg.git 03Michael Niedermayer 07master:cf9429944892: Merge remote-tracking branch 'cehoyos/master' [01:35] <cone-108> ffmpeg.git 03Marton Balint 07master:b339dccbba87: lavc: add teletext decoder using libzvbi [04:47] <cone-158> ffmpeg.git 03Michael Niedermayer 07master:cdd5df8189ff: avfilter/vf_fps: make sure the fifo is not empty before using it [04:51] <BBB> ubitux: yes only 32x32 tx and smaller for 64x64 prediction blocks [04:52] <BBB> ubitux: there is no 64x64 tx [04:52] <BBB> ubitux: I wrote one, but it didn't work so well so we decided to ditch it [04:52] <BBB> (probably a bug and not enough time to debug it) [08:36] <cone-52> ffmpeg.git 03Carl Eugen Hoyos 07master:ec8a4841f7e8: Avoid a deadlock when decoding wma. [10:11] <cone-52> ffmpeg.git 03Carl Eugen Hoyos 07release/0.10:f4392277b02e: Avoid a deadlock when decoding wma. [10:11] <cone-52> ffmpeg.git 03Carl Eugen Hoyos 07release/0.11:a5ef62ede16a: Avoid a deadlock when decoding wma. [10:11] <cone-52> ffmpeg.git 03Carl Eugen Hoyos 07release/1.0:7599284ad349: Avoid a deadlock when decoding wma. [10:11] <cone-52> ffmpeg.git 03Carl Eugen Hoyos 07release/1.1:c93874c3a8f8: Avoid a deadlock when decoding wma. [10:11] <cone-52> ffmpeg.git 03Carl Eugen Hoyos 07release/1.2:7eee79ea2fd3: Avoid a deadlock when decoding wma. [10:11] <cone-52> ffmpeg.git 03Michael Niedermayer 07release/2.0:1da5ab751f99: avcodec/ffv1dec: move initial_states init to init_thread_copy() [10:11] <cone-52> ffmpeg.git 03Carl Eugen Hoyos 07release/2.0:8e1760f37f7a: avcodec/ffv1dec: reorganize thread init/update [10:11] <cone-52> ffmpeg.git 03Carl Eugen Hoyos 07release/2.0:f5a4bd23e9ae: Avoid a deadlock when decoding wma. [12:38] <cone-52> ffmpeg.git 03Michael Niedermayer 07master:62d07bb321a9: avcodec/pnmdec: use a more specific pointer type than void in samplecpy() [12:38] <cone-52> ffmpeg.git 03Michael Niedermayer 07master:4fb3e1a652a9: avcodec/pnmdec: fix unaligned read [15:06] <j-b> 'morning [15:11] <michaelni> morning [15:58] <av500> #ffmpeg-logspam anybody? [16:00] <durandal_1707> hmm, doesn't sound that bad [16:52] <michaelni> BuxiNess, there are some jpeg2000 patches on ffmpeg-devel [16:52] <michaelni> do you have time to review them ? [16:56] <michaelni> mateo` / ubitux can one of you review " [FFmpeg-devel] [PATCH] avformat/movenc: Use the rate from av_timecode_init_from_string() for tmcd" ? [16:56] <michaelni> its only a 1 line change [16:57] <ubitux> michaelni: did you look how timecode track from quick time products look like? [16:57] <ubitux> typically take the mov from big buck bunny [16:57] <ubitux> there is a tmcd track generated with one of the reference software [16:57] <JEEBsv> ubitux: btw were you at VDD? [16:57] <ubitux> JEEBsv: yes [16:58] <JEEBsv> :< didn't happen to meet you [16:58] <JEEBsv> oh well [16:58] <ubitux> :( [16:59] <michaelni> ubitux, i dnt understand what you suggest [17:00] <michaelni> is the code right is ot wrong or you dont care ? [17:00] <ubitux> i was wondering if it was affecting the output, but since there is no fate change i guess it's not [17:00] <ubitux> so forget my comment [17:00] <michaelni> the bug is about a large number being stored in a 8bit field [17:01] <durandal_1707> where? [17:01] <michaelni> or rather it causing an error and half a tag being stored [17:01] <michaelni> tmcd tag [17:01] <BuxiNess> michaelni, yep I know, I'll do that [17:01] <michaelni> BuxiNess, thx [17:02] <BuxiNess> but right now short in time [17:02] <michaelni> ubitux, my bugfix tries to fix it by favoring the average fps instead of the timebase for the tmcd tag [17:02] <michaelni> that way it fits in 8bit (as value of 30) [17:02] <michaelni> i dont know if this can have side effects [17:03] <michaelni> QT certainly stores 30 in there because larger values dont fit [17:03] <michaelni> like 299 2997 30000 or whatever [17:05] <ubitux> wont this affect the written nb_frames? [17:06] <ubitux> those values are likely irrelevant anyway but well [17:07] <michaelni> yes, the code tried ro store nb_frames=30000 with avio_w8() [17:08] <ubitux> oh that's what you fix [17:08] <ubitux> well i guess that's ok [17:19] <michaelni> ubitux, ok & thanks [17:23] <cone-52> ffmpeg.git 03Michael Niedermayer 07master:2501f6d3d6b6: avformat/movenc: Use the rate from av_timecode_init_from_string() for tmcd [18:03] <j-b> btw, where is the aac encoder bugtrack? [18:14] <ubitux> heh i just lost 2 hours debugging a compilation issue because of http://trac.ffmpeg.org/ticket/1783 [18:14] <ubitux> :( [18:18] <ubitux> (not with android, just cmake & c++) [20:17] <Daemon404> 30 [20:17] <Daemon404> woops [20:25] <durandal_1707> ubitux: i think that s/random/s lavfi patch you did is good idea [20:25] <ubitux> what? [20:25] <durandal_1707> the most boring ever branch [20:25] <ubitux> ow lol [22:01] <cone-52> ffmpeg.git 03Vignesh Venkatasubramanian 07master:fdd1aaf87aae: avpacket: Fixing side data copy when src == dst [23:02] <Daemon404> michaelni, my fate boxes should be up again some time this week, fyi [23:03] <michaelni> Daemon404, ok & thanks [23:23] <BBB> ubitux: pingpong [23:27] <ubitux> BBB: pongping [23:31] <BBB> ubitux: ah goos [23:31] <BBB> s/s/d/ [23:32] <BBB> ubitux: so, is 4x4_idct ok as a starter for you? it's quite straightforward since the vp8 one is quite similar, and serves as a nice start for larger ones, such as multiple 4x4s at a time (see ffh264; we never did this for vp8, so that's another way to optimize ffvp8), and also do 8x8/16x16/32x32 or any of the adst variants [23:32] <ubitux> yes sorry i didn't reply to your pm [23:32] <ubitux> sure it's fine with me [23:33] <BBB> ubitux: ok cool; so I'm working on making emu-edge work fully, and will then do mc and loopfilter [23:33] <ubitux> thought i got my first full time day work today so, i'm gonna lack some time [23:33] <BBB> then whoever finishes first can do mt [23:33] <BBB> that's fine, so will I [23:33] <BBB> optimization is less important in terms of time [23:33] <BBB> we can submit this as-is since it passes fate w/o emu-edge [23:33] <ubitux> this sentence out of context is weird ;) [23:33] <BBB> and the code isn't super-ugly [23:34] <BBB> hm right [23:34] <BBB> now that I re-read it [23:34] <ubitux> i think we need to change the assert & mark the codec as experimental before pushing i think [23:35] <ubitux> but maybe i think too much [23:36] <durandal_1707> so how much that missed thing in ffvp8 could increase speed? [23:38] <BBB> why experimental? [23:38] <BBB> it works on all samples and has no known security issues [23:39] <BBB> unless you want to prefer libvpx until simd is done? [23:39] <BBB> I don't think that's what experimental means [23:39] <BBB> because experimental means it won't use it w/o libvpx enabled [23:39] <BBB> unless you use -strict -2 or so [23:41] <ubitux> well im just afraid of ppl requesting optims asap [23:41] <ubitux> also i dont remember any official vp9/libvpx announce [23:41] <ubitux> and maybe such a big codec needs more testing before marking it "final" [23:42] <ubitux> i won't insist much on this, 'just my opinion [23:42] <durandal_1707> if i do not use loopfilter=all i get bus error whan playing vp8 (when compiled with clang3.3) [23:43] <durandal_1707> ubitux: there is code coverage just for that reason [23:45] <BBB> durandal_1707: file a bug or so, I haven't tested that for a while, maybe it broke [23:45] <durandal_1707> no, its some clang silly thing [23:48] <durandal_1707> gdb says (its far from useful on my system) that it crashes in ff_simple_idct_add_mmx [23:50] <durandal_1707> hmm this could be DECLARE/LOCAL aligned thing... [23:55] <durandal_1707> actually, is there any difference between two? [23:57] <BBB> yes [23:57] <BBB> DECLARE_ALIGNED is for heap [23:57] <BBB> LOCAL_ALIGNED is for stack [23:58] <BBB> rather, DECLARE_ALIGNED is for members in structs that by themselves are already aligned [23:58] <BBB> e.g. if a struct is 16byte aligned, then DECLARE_ALIGNED(16, type, member)[size]; means that struct member is also 16 byte aligned [23:58] <BBB> LOCAL_ALIGNED_16(type, name[size]); is for stack arrays [23:59] <BBB> why does vp8 end up in ff_simple_idt_add_mmx? [23:59] <BBB> vp8 has its own idct [23:59] <durandal_1707> line in 80 of libavcodec/x86/simple_idct.c use DECLARE... [00:00] --- Tue Sep 3 2013