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

[burek]

[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