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

[burek]

[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