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

[burek]

[00:04] <j-b> smarter: if ever you need work, please let me know :)
[00:06] <smarter> I may soon, we'll see ;)
[00:15] <kierank> smarter: are you going to be in geneva in november?
[00:16] <kierank> smarter: http://tech.ebu.ch/devcon13
[00:16] <kierank> might be interesting
[00:16] <smarter> kierank: unless something unexpected happens, yes ;)
[00:16] <kierank> you should go
[00:16] Action: kierank is going
[00:17] <smarter> 100 CHF to register?
[00:19] <j-b> cheap
[00:30] <saste> llogan: yes they're fast and reliable when they have to pay
[00:33] <kierank> smarter: nominal fee i think
[00:33] <kierank> for food etc
[01:06] <cone-159> ffmpeg.git 03Michael Niedermayer 07master:3ed65d98c616: avutil/log: fix race between setting and using the log callback
[01:20] <wm4> michaelni: I doubt the code an optimizing compiler generates is even different before and after the call
[01:20] <wm4> s/call/commit
[01:21] <michaelni> wm4, i thought so too, but its more correct now
[01:22] <wm4> you'd need at least a memory barrier I guess
[01:22] <wm4> technically
[01:24] <michaelni> yes
[01:24] <wm4> also, while we're at it, ffmpeg shouldn't even have a global log callback
[01:24] <wm4> what if two libraries loaded into the same process use libav* at the same time?
[01:25] <wm4> that's not even unlikely, considering how important ffmpeg is
[01:26] <michaelni> libs cant (shouldnt) set the callback currently for that reason
[01:26] <Kovensky> "it hurts when I do that" "then don't do that, duh" :>
[01:27] <wm4> "currently"
[01:27] <wm4> so what about those things that actually require you to parse log output? (lol lavfi)
[01:32] <michaelni> well, that either means we should add non global callback support somehow or use something else for these cases than av_log() + user app/lib parsing
[02:48] <cone-159> ffmpeg.git 03Mickaël Raulet 07master:b4948943904a: hevc: optimize residual coding(cherry picked from commit 70692a44708157b4dfa50e402e446bfa2b27f55e)
[02:48] <cone-159> ffmpeg.git 03Mickaël Raulet 07master:a7e300649a7a: hevc: fix pcm with different chroma luma bit widths(cherry picked from commit 6a444516f338424d062c0ef2806714036283603b)
[02:57] <BBB> ubitux: yes, I'm using ssse3 as minimum also
[02:57] <BBB> ubitux: too lazy to use sse2 only
[02:58] <BBB> ubitux: if you have sse2, use vp8 ;)
[08:43] <cone-569> ffmpeg.git 03Martin Storsjö 07master:d433e1aefabd: mem: Make av_strdup allocate using av_realloc
[08:43] <cone-569> ffmpeg.git 03Michael Niedermayer 07master:21b3563dcbaa: Merge remote-tracking branch 'qatar/master'
[09:53] <mraulet> michaelni: do you want me to crosscheck hevc in ffmpeg?
[10:26] <cone-569> ffmpeg.git 03Dirk Farin 07master:2ac31773f3fc: avformat/hevcdec: cosmetics, whitespaces
[10:26] <cone-569> ffmpeg.git 03Dirk Farin 07master:56cf6151ae9f: avformat/hevcdec: add more irap cases to hevc_probe()
[10:26] <michaelni> mraulet, yes, please do!
[10:27] <michaelni> theres 1 file left that doesnt decode correct from the stuff in fate
[10:27] <michaelni> fate-hevc-conformance-PPS_A_qualcomm_7 that is
[10:41] <durandal_1707> michaelni: there is floating exception for some values of cotrast in swscale
[10:48] <durandal_1707> also x264opts is buggy and should be deprecated
[10:57] <mraulet> PPS_A_qualcomm_7 still there with one thread
[10:59] <cone-569> ffmpeg.git 03Carl Eugen Hoyos 07master:a0d13d84a928: Add some necessary casts in the wtv demuxer.
[10:59] <cone-569> ffmpeg.git 03Michael Niedermayer 07master:f90eb8cfc8c4: Merge remote-tracking branch 'cehoyos/master'
[11:49] <ubitux> i need a relatively high bitrate clip, any recommendation?
[11:49] <ubitux> elephant dreams, sintel, ... ?
[11:55] <durandal_1707> anything non-trivial with high motion
[14:11] <cone-656> ffmpeg.git 03Michael Niedermayer 07master:2db65472376c: swscale/utils/sws_setColorspaceDetails(): fix indention
[14:11] <cone-656> ffmpeg.git 03Michael Niedermayer 07master:d0a3bc13025b: swscale/yuv2rgb: clip cy, avoid division by 0 with 0 contrast
[14:38] <SilverCode> hi
[14:39] <SilverCode> what would be the easiest way to add a new boolean command line switch that I could access from libavformat/riff.c ?
[14:41] <SilverCode> it doesn't need to be clean or extensible, I just need to be able to tell avconv to write a "hacked" size when writing an avi header
[14:42] <durandal_1707> ffmpeg does not have avconv
[14:42] <SilverCode> are avconv and ffmpeg not the same?
[14:42] <durandal_1707> avconv is from libav
[14:43] <SilverCode> ah
[14:43] <SilverCode> off to libav-devel then
[14:43] <SilverCode> thanks
[14:48] Action: durandal_1707 away at lunch
[15:05] <mraulet> michaelni: it works well for sequences I have
[15:06] <mraulet> except for PPS_A_qualcomm_7 that has a weird behavior with one thread
[15:09] <michaelni> mraulet, does PPS_A_qualcomm_7 work better with the openhevc code ?
[16:01] <mraulet> it was working before
[16:01] <mraulet> now we align both code
[16:07] <saste> michaelni, are you fine with "[PATCH] lavu/opt: add AV_OPT_TYPE_CHANNEL_LAYOUT and handler functions" ?
[16:09] <saste> also the patch doesn't make sense without the swresample patch which changes INT -> channel layout
[16:15] <durandal_1707> isn't that breaking API/ABI?
[16:17] <saste> durandal_1707, no
[16:18] <saste> CHANNEL_LAYOUT options can be set by INT handlers
[16:31] <saste> what's the supposed content of an av_opt_get() buffer?
[16:39] <michaelni> saste, didnt i already say ok to that patch ?
[16:40] <michaelni> or maybe just if wm4 is ok with it or somethig like that
[16:42] <saste> michaelni, no you replied about the swscale filter patch
[16:43] <saste> also you're maintainer of libswr so the patch may concern you
[16:45] <saste> anyway i found a minor issue, will repost it soon
[16:45] <michaelni> the only change affecting swr is the change of avopt type and obviously a more specific type is better (if it doesnt break ABi and all that which it doesnt )
[16:45] <saste> michaelni, ok
[16:46] <saste> i'm almost done with it, will test more and will push if wm4 has no comments
[16:46] <saste> i changed the av_get_channel_layout patch so that no manual tweaking is necessary at the next bump
[16:47] <saste> all is handled by the preprocessor (would be otherwise extremely annoying when testing major bumping)
[16:49] <saste> wm4?
[16:58] <ubitux> wasn't ffv1 encode supposed to be threaded?
[16:58] <ubitux> it doesn't seem to make much use of the cpu
[17:13] <ubitux> it's too bad, because it's as fast as x264 with qp=0, but it's more than 2 times bigger
[17:14] <ubitux> it's still smaller than huffyuv or utvideo, but ~3x slower
[17:23] <durandal_1707> use slice threading
[17:23] <ubitux> shouldn't it be set by default?
[17:24] <durandal_1707> and you can change gop to make frame thread encoder faster
[17:24] <durandal_1707> s/decoder
[17:25] <durandal_1707> ubitux: compare with threading disabled
[17:38] <saste> how can i show swscale or swresample options?
[18:06] <durandal_1707> saste: aren't they displayed with ffmpeg?
[18:06] <michaelni> ubitux, default ffv1 is using a older version for compatibility with most decoders
[18:07] <saste> durandal_1707, yes, i was looking for something like ffmpeg -h scaler
[18:24] <cone-186> ffmpeg.git 03Stefano Sabatini 07master:98e7c1eed559: lavu/opt-test: use automatic set and free handlers
[18:24] <cone-186> ffmpeg.git 03Stefano Sabatini 07master:b236eb49e1a1: lavu/opt.h: fix grammar typo in av_opt_get* doxy
[18:24] <cone-186> ffmpeg.git 03Stefano Sabatini 07master:d96e377c394c: lavu/channel_layout: change av_get_channel_layout() behavior at the next bump
[18:24] <cone-186> ffmpeg.git 03Stefano Sabatini 07master:8696e51bafdc: lavu/opt: add AV_OPT_TYPE_CHANNEL_LAYOUT and handler functions
[18:24] <cone-186> ffmpeg.git 03Stefano Sabatini 07master:904c89ac1bdc: lswr/swresample: convert ocl and icl options to AV_OPT_TYPE_CHANNEL_LAYOUT
[19:02] <ubitux> durandal_1707, michaelni; ah, ok for ffv1
[19:03] <ubitux> i still don't get why threading would be affected by versions
[19:03] <ubitux> but ok
[19:09] <durandal_1707> ubitux: so how fast are other versions?
[19:10] <ubitux> 21 fps ’ 55 fps with -level 2
[19:10] <ubitux> -level 3*
[19:10] <ubitux> sorry
[19:11] <ubitux> which is pretty cool
[19:14] <michaelni> ubitux, also try larger numer for -slices
[19:19] <ubitux> 10 fps faster with -slices 16
[19:19] <ubitux> -rw-r--r-- 1 ubitux ubitux 628M Oct 17 19:17 out-ffv1-legacy.mkv
[19:19] <ubitux> -rw-r--r-- 1 ubitux ubitux 631M Oct 17 19:12 out-ffv1.mkv
[19:19] <ubitux> -rw-r--r-- 1 ubitux ubitux 489M Oct 17 19:15 out-x264.mkv
[19:19] <ubitux> so legacy and x264 at ~21 fps
[19:20] <ubitux> and ffv1 "3" at 65 fps
[19:20] <ubitux> (x264 is lossless, qp=0)
[19:20] <ubitux> so well ok, not as good, but definitely faster now, so that's a good trade off at least
[20:15] <cone-186> ffmpeg.git 03Diego Biurrun 07master:f52fd3f3b26f: fate: aac: Add test for AAC-LD
[20:15] <cone-186> ffmpeg.git 03Michael Niedermayer 07master:123c6ca80983: Merge commit 'f52fd3f3b26f0d80e4f0b374b7695383feca5b92'
[20:30] <cone-186> ffmpeg.git 03Martin Storsjö 07master:a27f1116cdfe: fate: Increase the tolerance in the lavr tests
[20:30] <cone-186> ffmpeg.git 03Michael Niedermayer 07master:57c018d54272: Merge remote-tracking branch 'qatar/master'
[20:36] <humanvitr> Can anyone give me a direction... I'm implementing a new protocol, based in sockets for video transmission, I see they are listed in ./libavformat, as I want to implement one from scratch, where should I reference my files so ffmpeg can read from there?!
[21:06] <michaelni> humanvitr, Makefile, allformats.c
[21:14] <humanvitr> thanks michaelni 
[21:35] <humanvitr> michaelni, I compiled everything, but my ffmpeg says "Protocol not found", you know where else shall I put my protocol?
[21:36] <cone-186> ffmpeg.git 03Clément BSsch 07master:0bf85803545d: avcodec/hevcpred: fix make checkheaders.
[21:36] <michaelni> humanvitr, you need to rerun configure after you added the protocol
[21:37] <humanvitr> I did...
[21:38] <humanvitr> maybe REGISTER_PROTOCOL is not enough to ffmpeg gather the protocol
[21:38] <durandal_1707> what protocol?
[21:39] <humanvitr> I'm developing one, basically a raw socket
[21:39] <llogan> name it "rawket"
[21:39] <ubitux> kawaii
[21:40] <ubitux> humanvitr: can you show the diff without the .c?
[21:41] <ubitux> actually, make sure the name matches in the .c
[21:44] <humanvitr> I think I found where I missed something
[21:45] <humanvitr> you know what this line in the configure means? udp_protocol_select="network"
[21:48] <humanvitr> I think is like some sort of heritage, because rtp uses udp, thank you all people
[21:53] <durandal_1707> ubitux: you have flv spec?
[21:53] <ubitux> they are public
[21:54] <ubitux> https://www.adobe.com/devnet/f4v.html
[21:55] <ubitux> annex E
[21:55] <durandal_1707> you have it open?
[21:57] <ubitux> yes
[22:13] <ubitux> BBB: in vp8, there is something weird
[22:15] <ubitux> afaiu, VP8_MULTIPLY_SUMSUB() is doing something like this:
[22:15] <ubitux> a' = ((a+a)*y)>>16 - ((a*x)>>16 + a)
[22:15] <ubitux> b' = ((b+b)*y)>>16 + ((b*x)>>16 + b)
[22:15] <ubitux> i don't understand why it's not doing:
[22:15] <ubitux> a' = ((a+a)*y)>>16 - ((a+a)*x)>>16)
[22:15] <ubitux> b' = ((b+b)*y)>>16 + ((b+b)*x)>>16)
[22:15] <ubitux> basically swapping the first 2 mul with the 2 following add
[22:16] <ubitux> what am i missing?
[22:16] <ubitux> (yeah i know i should be working on vp9 instead)
[22:16] <ubitux> i'll likely won't have to care about this since i'm going to use pmaddwd from ssse3, but i'm curious
[22:18] <ubitux> (x and y being the 2 constants)
[22:24] <ubitux> or maybe it should be:
[22:24] <ubitux> a' = (a*y)>>16 - ((a*x)>>16 + a)
[22:24] <ubitux> b' = (b*y)>>16 + ((b*x)>>16 + b)
[22:24] <ubitux> (looking at the c code)
[22:24] <ubitux> but in that case i don't get why there is this extra x2 in the left side
[22:51] <Compn> anyone seen samples with "aacf"  isom ?
[22:51] <Compn> some kind of aac obviously
[00:00] --- Fri Oct 18 2013