[00:04] <cone-319> ffmpeg.git 03Lukasz Marek 07master:7151411b9cf7: lavd: add avdevice_app_to_dev_control_message API [00:05] <cone-319> ffmpeg.git 03Lukasz Marek 07master:102bd641687a: lavd: add avdevice_dev_to_app_control_message API [00:05] <cone-319> ffmpeg.git 03Lukasz Marek 07master:ded6b3af41cd: lavd: add opengl device [00:05] <cone-319> ffmpeg.git 03Michael Niedermayer 07master:c94ed2a72964: Merge remote-tracking branch 'lukaszmluki/master' [00:19] <BBB> ubitux: oh it's slower? ok, commit original then i guess [00:19] <BBB> ubitux: thanks for testing anyway [00:20] <BBB> ubitux: the not-less instructions is kinda weird, I think it's just ordering being off [00:21] <BBB> that is, the qdq step should be unnecessary [00:21] <BBB> if you need a qdq, it means original input ordering was wrong [00:21] <BBB> we can look into that some other time [00:21] <BBB> it's not urgent [01:27] <cone-319> ffmpeg.git 03Michael Niedermayer 07master:2a9c50798b79: avcodec/huffyuv: dont depend on bitstream_bpp having a specific value for version>2 [07:24] <ubitux> BBB: well this is basically the same has a 8x8B transpose [07:24] <ubitux> unless you know a way to simplify a 8x8B transpose, i don't know how we could make this simpler [07:24] <ubitux> s/has/as/ [07:37] <cone-125> ffmpeg.git 03Clément BSsch 07master:222c46c53108: x86/vp9lpf: add ff_vp9_loop_filter_[vh]_88_16_{ssse3,avx}. [07:37] <ubitux> BBB: feel free to try something ^ [07:44] <ubitux> BBB: fuzzed7.ivf available btw [09:10] <ubitux> cbsrobot: ping [09:14] <cbsrobot> ubitux: pong [09:15] <ubitux> cbsrobot: in the 2nd ebur128 patch, you removed a \n in the logging [09:15] <ubitux> why? [09:15] <cbsrobot> so the true peak can be added without having the context printed [09:15] <cbsrobot> but it's added at the end again [09:18] <ubitux> mmh [09:18] <ubitux> cbsrobot: but if the peaks are not enabled, the stdout is broken [09:18] <ubitux> no? [09:18] <ubitux> ah, no indeed it's at the end [09:18] <cbsrobot> well there is a "\n" at the end [09:18] <ubitux> my bad [09:19] <ubitux> i need to fix the FFLIBS thing btw [09:19] <ubitux> and it should be ok [09:19] <ubitux> cbsrobot: i assume you tested it properly? :p [09:27] <cbsrobot> ubitux: I could still run the ebu testset on it .... [09:35] <ubitux> cbsrobot: could be nice [09:35] <ubitux> Compnn: aren't you maintaining samples.ffmpeg.org? [09:36] <cbsrobot> well - ofc they don't test the true peak metering .... [09:44] <ubitux> meh, ped1080p.webm does not exist anymore :( [09:50] <BBB> ubitux: well I was thinking of the end-transpose (not the start-one) [09:50] <BBB> ubitux: then you do just bw, wd and dq (not qdq) [09:51] <ubitux> aah. [09:51] <BBB> at that point, I think "P7" and "P6" is in lo/hi m0, "P5" and "P4" in lo/hi m1 [09:51] <BBB> etc. [09:52] <BBB> I'm not sure it works for the start, thinking about it I think it doesn't actually [09:52] <BBB> (which I probably should've thought of before I told you all of this) [09:52] <ubitux> it's fine :) [09:53] <ubitux> BBB: fuzzed7 crashes only with threading btw [09:53] <BBB> ;( [09:53] <BBB> ok [09:54] <ubitux> (it triggers the large swscale error otherwise) [09:54] <BBB> I thought I ul'ed ped1080p.webm to incoming? [09:54] <BBB> need me to ul it again? [09:55] <ubitux> yeah but it seems it's not there anymore :( [09:55] <ubitux> it's fine, i have it @home [09:55] <ubitux> though, it should probably be uploaded along with etv5k.webm in the samples directory [09:56] <BBB> re-ul'ed [09:56] <ubitux> thanks :) [09:56] <BBB> yeah I agree, plus any other samples we want to use for general profiling in the future [09:56] <BBB> I guess this + etv5k is enough for now [10:01] <BBB> I started writing simd for intra pred btw [10:01] <BBB> no idea whether it helps any, but I was bored [10:01] <ubitux> gonna push the sse patch from james almer [10:02] <BBB> yeah [10:02] <BBB> ok I'm gonna try to sleep also [10:02] <ubitux> can you confirm punpckl{bw,qdq} and pshuf[hl]w are indeed available in sse? [10:02] <BBB> yeah they are [10:02] <ubitux> cool ok [10:02] <BBB> ssse3 introduces things like palignr, pshufb, pmaddubsw [10:02] <BBB> most "generic" stuff is sse2 [10:02] Action: BBB zzz [10:02] <ubitux> 'night :) [10:03] <cone-125> ffmpeg.git 03James Almer 07master:644c32ea4b80: x86/vp9lpf: add ff_vp9_loop_filter_[vh]_88_16_sse2() [10:08] <cbsrobot> ubitux: compared to http://www.kvraudio.com/forum/viewtopic.php?f=6&t=354995 I get http://pastebin.com/Sxw5R4cV , which is in the +/- 0.3 range of other implementations [10:09] <ubitux> ok [14:16] <ubitux> BBB: so, do you want me to do some more lpf functions? [14:16] <ubitux> like the 8/4? [14:16] <BBB> yes please [14:16] <ubitux> or i can start trying to do some ARM? [14:16] <ubitux> ok [14:16] <BBB> 48/84 should be really trivial now that 88 is done [14:16] <BBB> it's basically 88 with a fixed zeromask for filter6 for the 4-half [14:17] <BBB> 44 is a little bit more work if you want to erase filter6 altogether (you probably do) for more runtime savings [14:45] <Daemon404> [13:16] <@ubitux> or i can start trying to do some ARM? <-- nah, im sure phones will get hw vp9 decoders Any Day Now [14:45] <Daemon404> just like vp8 did... wait [14:45] <Daemon404> oops. [14:47] <ubitux> having h264 hw decoder doesn't prevent ppl from writing h264 arm asm :p [14:47] <Daemon404> true [14:47] <JEEB> the vp9 hw reference design is pretty spanky [14:47] <JEEB> bigger than cortex a9 was it? [14:47] <Daemon404> lol really? [14:48] <ubitux> meanwhile [14:48] <ubitux> [~/src/ffmpeg]- ls libavcodec/x86/hevc* [14:48] <ubitux> zsh: no matches found: libavcodec/x86/hevc* [14:48] <ubitux> :( [14:48] <Daemon404> blame the french [14:48] <Daemon404> they wrote intrinsics for some reason [14:49] <nevcairiel> you're welcome to take over that task ubitux. :D [14:49] <ubitux> i'm busy helping BBB puting libvpx at shame [14:49] <Daemon404> thats not hard [14:50] Action: Daemon404 runs [14:50] <ubitux> well, they have some simd at least [14:50] <Daemon404> nah i meant it does a pretty good job of it on its own [14:50] <Daemon404> for !simd reasons [14:51] <mateo`> ubitux: do you have some kind of comparaison between libvpx and lavc ? [14:52] <ubitux> i didn't bench myself, but according to BBB we're now about 35% faster iirc [14:52] <Daemon404> already? :o [14:52] <mateo`> ubitux: nice ! [14:53] <Daemon404> ubitux, any idea how our MT compares? [14:53] <Daemon404> or is ffvp9 mt'd yet [14:53] <ubitux> it's mt'd [14:53] <ubitux> > already [14:53] <ubitux> well, we have about 3k lines of asm :p [14:57] <ubitux> i7-3520M, i'm decoding 1080p footage at 120 fps with 1 thread [14:57] <ubitux> and 250+ fps with 4 threads [14:57] <ubitux> but the sample is too short (3:30) [14:58] <ubitux> so it's hard to tell (it was constantly increasing) [14:58] <Daemon404> i was encoding some 4k samples with it [14:58] <Daemon404> but theyre only 600 frames [14:58] <ubitux> 5k frames here [15:13] <cone-490> ffmpeg.git 03Michael Niedermayer 07master:bb7a7111562b: avcodec/huffyuvenc: frame multi-threading support [16:11] <ubitux> the ogg patches from mathstuff are not yet pushed? [16:12] Action: ubitux is bored at the "[ffmpeg] NULL: Invalid packet" while listening to his webradio with mpv and wonder if that patchset would help [16:17] <wm4> ubitux: yes it would help [16:17] <wm4> I think he has to post a new iteration of patches still [16:19] <wm4> also, I think the chosen interface is indeed not so great (e.g. what happens if file-global metadata changes? ogg is just so messed up that it makes file global metadata stream local) [16:21] <ubitux> no idea [16:26] <wm4> why the crap does av_init_packet() not initialize all fields anyway? [16:26] <wm4> who knows how many users fell into this trap [16:26] <wm4> who thought it was a good idea? [16:27] <nevcairiel> its only really needed when you send a AVPacket to the decoders, so i guess someone though the only actual mandatory fields should be explicitly set [16:27] <nevcairiel> thought* [17:13] <michaelni> Anssi, any news about the HLS patches? anything others can help with ? also theres: a new hls pull req https://github.com/FFmpeg/FFmpeg/pull/55 [17:14] <Anssi> michaelni: just been very busy with other stuff lately :/ I hope to work on it later this week [17:15] <michaelni> Anssi, ok, great, no hurry [18:10] <cone-490> ffmpeg.git 03Lukasz Marek 07master:4115cd0e768f: doc/APIchanges: add avdevice_*_control_message functions [18:10] <cone-490> ffmpeg.git 03Lukasz Marek 07master:9ff2cc685bdb: MAINTAINERS: add myself as opengl_enc.c maintainer [18:10] <cone-490> ffmpeg.git 03Lukasz Marek 07master:406cb21b6365: doc/general: update device and protocol status [19:12] <cone-490> ffmpeg.git 03Mikael Finstad 07master:5846d8a91ebd: avformat/hls: Fix cookies and user agent with encrypted HLS streams [19:30] <bneff> I'm using ffmpeg-1.2.5, and I'm getting a consistent crash with av_packet_get_side_data. Is this the appropriate place to help troubleshoot? [20:52] <michaelni> bneff, what are you doing to get it to crash ? [20:52] <michaelni> also is this a regression ? [22:00] <cone-490> ffmpeg.git 03Michael Niedermayer 07master:3e41e747d654: avfilter/vf_colormatrix: Support using the source AVFrame colorspace if none is specified [22:01] <cone-490> ffmpeg.git 03Michael Niedermayer 07master:b50efe85eaf2: avfilter/vf_colormatrix: update output AVFrame colorspace [22:40] <bneff> michaelni: I started with ffmpeg 1.2.0, and duplicated it on 1.2.5 so I'm not sure if this is a regression. I'm calling avcodec_decode_video2(), and passing it an AVPacket that i set .data and .size on. Eventually that calls av_packet_get_side_data, and passed that an AVPacket *, but that is NULL [22:41] <nevcairiel> did you init the AVPacket first, with av_init_packet? [22:42] <bneff> nevcairiel: yes. [22:42] <bneff> My program runs for quite some time e.g. 40 minutes of decode / encode, but then this same crash is triggered [22:43] <bneff> on the 1.2.5 source, in libavcodec/avpacket.c on line 219 it tries to do pkt->side_data_elems, but pkt is NULL [22:45] <michaelni> why is pkt NULL? [22:46] <bneff> I don't know, I don't pass that in. That is all done inside avcodec_decode_video2() [22:46] <michaelni> well, so do you have a backtrace and how to reproduce it [22:46] <michaelni> ? [22:46] <bneff> I have a backtrace [22:47] <bneff> and I've been poking around in gdb, but I just don't know about about ffmpeg to know what it should be [22:47] <bneff> in terms of how to reproduce, I do not have that, sorry [22:50] <llogan> feel free to start adding ideas and stuff [22:52] <bneff> here is the backtrace: http://pastebin.com/q1GSpuZ7 [00:00] --- Wed Jan 29 2014