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

[burek]

[00:36:00 CEST] <cone-151> ffmpeg 03Michael Niedermayer 07master:7856afef524d: avformat/hdsenc: Change duration from single to to double precision
[00:55:26 CEST] <cone-151> ffmpeg 03Luca Barbato 07master:9b56ac74b170: mpjpeg: Initial implementation
[00:55:27 CEST] <cone-151> ffmpeg 03Michael Niedermayer 07master:8985e7c56130: Merge commit '9b56ac74b170d12027fbc81f581a451a709f1105'
[01:19:13 CEST] <cone-151> ffmpeg 03Luca Barbato 07master:252d6200c36e: avio: Add avio_put_str16be
[01:19:14 CEST] <cone-151> ffmpeg 03Michael Niedermayer 07master:ce838ad950fc: Merge commit '252d6200c36e7eaa79f8d5205b7d731179e94897'
[01:30:47 CEST] <cone-151> ffmpeg 03nu774 07master:677c804aa3a7: aac: correctly map 7.1ch-wide AAC from FDK AAC encoder
[01:30:48 CEST] <cone-151> ffmpeg 03Michael Niedermayer 07master:8eb2c411c1e5: Merge commit '677c804aa3a78d61b21e6423165a252846c20f0e'
[01:43:01 CEST] <cone-151> ffmpeg 03Sebastian Dröge 07master:a188108ebf28: aac: Support channel configurations 11 and 12
[01:43:02 CEST] <cone-151> ffmpeg 03Michael Niedermayer 07master:476692abdb32: Merge commit 'a188108ebf28ebac9d2b8fc7d5b391aef45698b3'
[02:42:19 CEST] <cone-151> ffmpeg 03Luca Barbato 07master:bc76c4694327: aac: Wait to know the channels before allocating frame
[02:42:20 CEST] <cone-151> ffmpeg 03Michael Niedermayer 07master:153d23ee39db: Merge commit 'bc76c46943272515805d7ac48ca39f14826d1fed'
[02:42:22 CEST] <cone-151> ffmpeg 03Michael Niedermayer 07master:990605768c86: avcodec/aacdec: Do not return a uninitialized value
[03:54:55 CEST] <cone-151> ffmpeg 03Caligula useraccount 07master:51ac1f616f58: avformat: Add single jpeg muxer
[03:54:56 CEST] <cone-151> ffmpeg 03Caligula useraccount 07master:3b89a673155f: ffserver: Use singlejpeg muxer for jpeg
[03:54:57 CEST] <cone-151> ffmpeg 03Michael Niedermayer 07master:5cf84e595d7c: doc/ffserver: Add entry for missing jpeg variant
[03:59:05 CEST] <lglinskih> michaelni: hi! Not as good as I expected. I'm trying to locate my test in "tests" directory. And also I want to build it there)
[04:01:31 CEST] <lglinskih> the magic of makefiles is not easy for me
[06:57:21 CEST] <thardin> hey, does ffmpeg have an anti-sourceforgization thing in its license?
[06:57:25 CEST] <thardin> because it should
[07:30:01 CEST] <rcombs> it's LGPL
[07:30:13 CEST] <rcombs> with optional GPL components and no OpenSSL exception
[07:35:48 CEST] <thardin> myes, I know
[07:42:11 CEST] <ubitux> michaelni__: thx for avio*
[12:06:05 CEST] <cone-068> ffmpeg 03Michael Niedermayer 07master:ac2dad9690ad: avformat/version: Bump version for single jpeg muxer
[12:06:06 CEST] <cone-068> ffmpeg 03Max Poliakovski 07master:d765e07322a1: atrac3plus: add support for GHA phase inversion.
[12:06:07 CEST] <cone-068> ffmpeg 03Max Poliakovski 07master:4b343f7c359b: atrac3plus: give the phase_shift flag a better name.
[13:17:05 CEST] <cone-068> ffmpeg 03Michael Niedermayer 07master:7630cce4b309: avformat/mxfenc: Allow overriding /manual setting of the signal standard
[13:43:44 CEST] <lglinskih_> michaelni: I'm sorry! it was 5 a.m. in my city and I didn't expect you to answer to me. So I went to sleep)
[13:44:56 CEST] <michaelni> sure, np
[13:45:19 CEST] <michaelni> could you resolve the problem with the  test ?
[13:47:59 CEST] <lglinskih_> About makefiles: my test (api-flac-test) is already integrated in "make fate", but the command for running test is placed in libavcodec.mak in /tests/fate
[13:50:22 CEST] <michaelni> yes, i dont know what kierank prefers (he is your mentor so better ask him than me) but i would just leave it in libavcodec.mak if that works
[13:56:36 CEST] <lglinskih_> My first wish was to locate all source files of API tests in one place. Kieran didn't argue with me, but now I think that I can't do it by myself.=/
[13:57:29 CEST] <kierank> lglinskih_: hmm
[13:58:42 CEST] <kierank> if you're getting stuck then perhaps you should just leave things as they are and continue with libavcodec.mak
[13:59:26 CEST] Action: kierank gets lunch
[14:20:23 CEST] <Daemon404> man that ticket...
[14:21:55 CEST] <cehoyos> I tested this extensively last time and I was unable to see any (even a small) difference in time.
[14:22:18 CEST] <cehoyos> Now why -f aac should be slower than -f mp4 is not easy to understand...
[14:31:09 CEST] <Compn> i'm curious why his curl and wget times are so different
[14:31:16 CEST] <Compn> is curl using multiple connections or something ?
[14:31:52 CEST] <Daemon404> curl does not, no
[14:32:00 CEST] <Daemon404> his pipe is probably not stable.
[14:32:44 CEST] <Compn> heh
[14:33:27 CEST] <cehoyos> I cannot reproduce a different time between wget and curl (curl is slower here if at all)
[14:33:47 CEST] <Compn> he could have a broken wget or something
[14:34:03 CEST] <cehoyos> But I can reproduce the "-vn" issue;-(
[14:35:09 CEST] <Compn> i dont doubt there is a bug there somewhere, thats why i asked for more info (and bench) :)
[14:35:30 CEST] <cehoyos> I don't understand: If you saw a bug why didn't you explain how to reproduce it?
[14:35:35 CEST] <cehoyos> I wasn't able to reproduce it...
[14:38:38 CEST] <cehoyos> It's a regression;-(
[14:39:35 CEST] <cone-068> ffmpeg 03Rodger Combs 07master:6dd5371e34c6: lavf/tls: let the user specify what name to verify against
[15:39:49 CEST] <cone-068> ffmpeg 03Donny Yang 07master:ed09bb3782e2: avcodec/apng: Dispose previous frame properly
[16:03:26 CEST] <TimNich> Is the mailserver working OK at the moment?
[16:04:10 CEST] <Daemon404> was it that one of your mails never went through?
[16:06:01 CEST] <cone-068> ffmpeg 03Donny Yang 07master:0ab1c46fe07f: avcodec/apng: Add blending support for non-alpha pixel formats
[16:08:36 CEST] <TimNich> its that I havent seen it, but michaelni obviously has..
[16:10:06 CEST] <Daemon404> spam collection maybe
[16:10:14 CEST] <Daemon404> i often see a pile of TimNich mails in my spam folder
[16:10:17 CEST] <Daemon404> due to yahoo mail address
[16:11:28 CEST] <TimNich> Ah, I see an Excess bounce in the spam folder& I fixed the DMARC issues ages ago...
[16:13:37 CEST] <TimNich> Nothing from me via ffmpeg-devel should come from me.
[16:14:01 CEST] <Daemon404> thats true
[16:14:07 CEST] <Daemon404> we, wait no its not
[16:14:12 CEST] <Daemon404> man my brain is broken
[16:15:41 CEST] <TimNich> Hmmm. I also patched up the new server ready for the change over, so maybe it got unpatched&
[16:24:29 CEST] <TimNich> no, the adress munging is still happening from avserver2
[16:25:48 CEST] <cone-068> ffmpeg 03Donny Yang 07master:33292c07fe19: avcodec/apng: Add support for blending with GRAY8A pixel format
[16:37:20 CEST] <cone-068> ffmpeg 03Donny Yang 07master:130a6c04a466: avcodec/apng: Add partial support for blending with PAL8 pixel format
[16:37:41 CEST] <TimNich> OK all good now , so I guess a hiccup at the change over.
[19:01:01 CEST] <Luigi12_work> hello :o)  I would like to do one more (hopefully last) ffmpeg security update for Mageia 4.  Would it be possible to roll one more 2.0.x ffmpeg release with the current CVE fixes?
[19:11:14 CEST] <iive> Luigi12_work: michaelni is the person responsible for most of that. he should answer (and this would highlight him :)
[19:11:44 CEST] <cone-068> ffmpeg 03Michael Niedermayer 07master:653bf3c5a150: avcodec/hq_hqa: Fix signness of tag
[19:13:04 CEST] <llogan> i wonder how many other downstreams use 2.0 (no others are listed on wiki downstreams page)
[19:13:31 CEST] <michaelni> Luigi12_work, ill see what i can do
[19:14:43 CEST] <llogan> Luigi12_work: do you have an EOL date yet for Mageia 5?
[19:16:48 CEST] <Luigi12_work> llogan: not yet, since it hasn't been released yet.  It should be this week though, so I will update the wiki page.  It'll be release date + 18 months.
[19:17:11 CEST] <Luigi12_work> michaelni: thank you!
[19:17:30 CEST] <llogan> Luigi12_work: ok, thanks.
[19:17:36 CEST] <Luigi12_work> glad my downstreams wiki page has been useful :o)
[19:51:07 CEST] <cehoyos> michaelni: Your commit also fixed ticket 4510 for me.
[19:53:06 CEST] <cehoyos> Am I the only one who gets "libswresample/swresample.c:696:5: warning: "ASSERT_LEVEL" is not defined [-Wundef]" ?
[19:54:15 CEST] <michaelni> cehoyos, cant reproduce 4510 either, feel free to close
[19:55:26 CEST] <cehoyos> You cannot reproduce on x86-64 or on x86-32?
[19:55:43 CEST] <cehoyos> Because I just tested again, and it always crashed here...
[20:10:55 CEST] <jamrial> cehoyos: no, i also get that warning
[20:14:17 CEST] <michaelni> cehoyos, i tried the ticket with 32 ad 64bit after the patch and couldnt repro, i didnot try before the commit
[20:24:30 CEST] <cone-068> ffmpeg 03Michael Niedermayer 07master:56f0fe6b8434: swr: Fix ASSERT_LEVEL warning
[20:24:59 CEST] <michaelni> cehoyos, fixed the warning
[20:49:33 CEST] <cehoyos> michaelni: Thank you!
[20:49:56 CEST] <cehoyos> The crash with x86-32 was only reproducible before your patch.
[20:50:52 CEST] <cone-068> ffmpeg 03Luca Barbato 07master:a6f19d6a9f8d: configure: Support MSVC 2015
[20:50:53 CEST] <cone-068> ffmpeg 03Michael Niedermayer 07master:a4557b7a98f7: Merge commit 'a6f19d6a9f8d1e08653d9d77581e8c823f4955c2'
[21:04:33 CEST] <jamrial> the mpjpeg probe function made valgrind and asan go nuts, lol
[21:04:49 CEST] <cone-068> ffmpeg 03James Almer 07master:34d278f9838e: mpjpegdec: fix memory leak in probe function
[21:04:54 CEST] <jamrial> there
[21:06:19 CEST] <wm4> jamrial: this must have been very evil
[21:06:40 CEST] <jamrial> http://fate.ffmpeg.org/report.cgi?time=20150608135429&slot=x86_64-archlinux-gcc-valgrindundef
[21:06:56 CEST] <jamrial> about 2000 tests failed because of that :p
[21:07:12 CEST] <nevcairiel> another quality libav implementation
[21:07:16 CEST] <nevcairiel> wait, i shouldn't troll
[21:09:28 CEST] <jamrial> huh, they fixed it already
[21:09:42 CEST] <jamrial> now it looks like i stole attribution for it, ouch
[21:10:01 CEST] <wm4> http://git.libav.org/?p=libav.git;a=blobdiff;f=libavformat/mpjpegdec.c;h=72891e7cd808b6d8d8554d673e62b2c4d46740c9;hp=354278c6c817a7da20e9a266be0958200ebd91c5;hb=caf7be30b11288c498fae67be4741bfbf083d977;hpb=925b80d64029d41962e5998d7d901226c3a9baea
[21:10:21 CEST] <wm4> well
[21:10:27 CEST] <wm4> you didn't remove the blank line
[21:10:36 CEST] <wm4> copyright violation averted!
[21:10:48 CEST] <wm4> (copyright is stupid)
[21:11:04 CEST] <nevcairiel> i would consider that change trivial and therefor not protected under copyright =p
[21:11:14 CEST] <jamrial> michaelni: when you merge Janne Grunau's fix for the mpjpeg leak don't reference my commit, or at least don't do it making it look like mine was first
[21:11:25 CEST] <jamrial> because it wasn't. i was seven hours late :p
[21:12:48 CEST] <cone-068> ffmpeg 03Vittorio Giovara 07master:da0c8664b4dc: mpegvideo: Move various temporary buffers to a separate context
[21:12:49 CEST] <cone-068> ffmpeg 03Michael Niedermayer 07master:db8ae37a783a: Merge commit 'da0c8664b4dc906696803685f7e53ade68594ab8'
[21:16:05 CEST] <rcombs> http://blogs.windows.com/buildingapps/2015/06/05/using-ffmpeg-in-windows-applications/ huh
[21:16:30 CEST] <nevcairiel> we saw that yesterday already
[21:16:34 CEST] <nevcairiel> its kinda lol
[21:16:42 CEST] <nevcairiel> also their managed API is all kinds of terrible
[21:16:45 CEST] <rcombs> and, uh, https://github.com/Microsoft/FFmpegInterop
[21:16:54 CEST] <nevcairiel> (also, i hate managed c++, its just terrible, use C# if you want managed)
[21:18:06 CEST] <Compn> did it get posted to twitter ?
[21:19:41 CEST] <rcombs> a coworker just linked it to me
[21:21:15 CEST] <nevcairiel> dunno where it showed up first, but it was linked here yesterday i think
[21:23:09 CEST] <wm4> rcombs: I already trolled on the issue tracker
[21:23:53 CEST] <nevcairiel> your troll was stupid though, some developer of a media interop isnt going to run to the kernel devs and demand they implement pthread already
[21:24:47 CEST] <nevcairiel> (not to mention that ffmpeg works perfectly fine without pthreads)
[21:24:53 CEST] <wm4> too bad if my troll isn't good enough for them
[21:25:20 CEST] <cehoyos> It may even be faster...
[21:26:12 CEST] <nevcairiel> I'm not sure your troll even makes sense, even pthreads in ffmpeg needs the silly lockmanager
[21:27:15 CEST] <nevcairiel> (and the default implementation of the lockmgr in ffmpeg works fine with w32threads, so all they probably need to do is ensure w32threads actually works for them, and then request threading)
[21:27:16 CEST] <cone-068> ffmpeg 03Vittorio Giovara 07master:f8716a1408f4: mpegvideo: Rework frame_size_alloc function
[21:27:17 CEST] <cone-068> ffmpeg 03Michael Niedermayer 07master:e05fda99f7a4: Merge commit 'f8716a1408f4f4ec63857b7015fbd62f9eac344a'
[21:27:49 CEST] <wm4> nevcairiel: native pthreads could avoid it, because static mutex initializers work
[21:27:59 CEST] <wm4> nevcairiel: just ffmpeg's pthread "emulation" can't
[21:28:41 CEST] <nevcairiel> if you claim to only support one locking mechanism, you could of course just get rid of the lockmgr and and hardcode the mutex calls, but that doesn't really change much at all
[21:29:51 CEST] <wm4> I think there's a strong point that if win supported pthread, we'd just make it mandatory
[21:39:19 CEST] <jamrial> or you could ask them to implement a way to statically initialize critical sections (aka, mutex)
[21:44:37 CEST] <cone-068> ffmpeg 03Andreas Cadhalpun 07master:b18eac7ff223: vp9: change type of tile_size from unsigned to int64_t
[22:04:42 CEST] <cone-068> ffmpeg 03Vittorio Giovara 07master:9bb11be0e5a7: mpegvideo: Split picture allocation for encoding and decoding
[22:04:43 CEST] <cone-068> ffmpeg 03Michael Niedermayer 07master:3244a176505b: Merge commit '9bb11be0e5a75782c3139ad058c2b571499aa37d'
[22:04:53 CEST] <ubitux> FYI, apparently LOTRO is using ffmpeg, avcodec 53 (0.10?) with the following flags: http://pastie.org/pastes/10230189/text
[22:05:44 CEST] <ubitux> also this in the strings: "e:/src/ffmpeg-head/ffmpeg/source/patched-ffmpeg/libavcodec/options.c"
[22:06:10 CEST] <JEEBsv> yeah, a lot of stuff uses lavf/lavc
[22:08:35 CEST] <nevcairiel> BtbN: do you know if nvenc has a particular max bitrate it cannot/would not exceed?
[22:13:52 CEST] <cone-068> ffmpeg 03Vittorio Giovara 07master:925b80d64029: mpegvideo: Move OutFormat enum to mpegutils.h
[22:13:53 CEST] <cone-068> ffmpeg 03Michael Niedermayer 07master:83e3516e64dc: Merge commit '925b80d64029d41962e5998d7d901226c3a9baea'
[22:25:20 CEST] <philipl> nevcairiel: we can run it with increasing bitrates and see when it stops paying attention
[22:25:43 CEST] <nevcairiel> well its hard to judge if the content is just perfectly coded at that point
[22:25:52 CEST] <nevcairiel> need high frequency noise pattern!
[22:35:45 CEST] <cone-068> ffmpeg 03Janne Grunau 07master:caf7be30b112: mpjpgdec: free AVIOContext leak on early probe fail
[22:35:46 CEST] <cone-068> ffmpeg 03Michael Niedermayer 07master:402b18afcc51: Merge commit 'caf7be30b11288c498fae67be4741bfbf083d977'
[22:36:52 CEST] <jamrial> michaelni: thanks
[22:37:07 CEST] <michaelni> np
[22:40:11 CEST] <baptiste> that's kinda cool though, microsoft/ffmpeg who would have thought ?
[22:40:20 CEST] <baptiste> can they finish the vc1 decoder ? :)
[22:40:51 CEST] <nevcairiel> microsoft has changed quite a bit over the last two-ish years, they are quite different now
[22:41:23 CEST] <philipl> nevcairiel: Did you read the SDK docs? I don't remember it being discussed, but maybe I missed it.
[22:42:07 CEST] <baptiste> yeah, it's changing
[22:42:30 CEST] <jamrial> or maybe they could make wmalossless 24bit work
[22:45:47 CEST] <cone-068> ffmpeg 03Vittorio Giovara 07master:8ef98855d25e: sctp: Always initialize outmsg struct
[22:45:49 CEST] <cone-068> ffmpeg 03Vittorio Giovara 07master:f7e932473314: audiointerleave: Always initialize new_pkt
[22:45:49 CEST] <cone-068> ffmpeg 03Michael Niedermayer 07master:01a6ae1396b5: Merge commit '8ef98855d25e457094468e2e1a79d9b10d6445b2'
[22:45:50 CEST] <cone-068> ffmpeg 03Michael Niedermayer 07master:d1f7b313ac34: Merge commit 'f7e932473314e6ca4c851d49cbde8570b6e66383'
[22:56:01 CEST] <cone-068> ffmpeg 03Vittorio Giovara 07master:bc1eace1b365: jack: Check memory allocation
[22:56:02 CEST] <cone-068> ffmpeg 03Michael Niedermayer 07master:77510a969861: Merge commit 'bc1eace1b3654c490cb2c226b3c80854244dbb9a'
[22:59:44 CEST] <philipl> nevcairiel: And their SDK doc never discusses encoder performance except for providing numbers for 720p. Nothing else.
[22:59:53 CEST] <philipl> Not even to state if you can hope 4k60 can be done.
[23:00:37 CEST] <nevcairiel> yeah i didnt find many numbers
[23:00:51 CEST] <nevcairiel> shadowplay goes to 130mbit, so i'm going to assume that at least works
[23:01:48 CEST] <philipl> You're asking out of curiosity or you need to support multi-hundred-megabit encoding? :-)
[23:02:11 CEST] <nevcairiel> mostly curiousity
[23:02:33 CEST] <nevcairiel> was also wondering if it would increase the quality to just boost it into the sky
[23:02:39 CEST] <nevcairiel> 50mbit still has noticeable loss
[23:02:44 CEST] <nevcairiel> but that may be 4:2:0 ..
[23:02:51 CEST] <philipl> Probably not. They probably don't pay much attention above 50mbit
[23:02:54 CEST] <nevcairiel> (game recording)
[23:03:07 CEST] <philipl> (I mean, don't pay attention to how well it uses the bits)
[23:03:27 CEST] <philipl> In general nvenc quality is pretty pants.
[23:03:57 CEST] <nevcairiel> doesnt it do 444 encoding
[23:03:58 CEST] <cone-068> ffmpeg 03Vittorio Giovara 07master:6308cd4868d2: mov: Check memory allocation
[23:03:59 CEST] <cone-068> ffmpeg 03Michael Niedermayer 07master:3d6635749ab2: Merge commit '6308cd4868d2bd5fdf8bfa8dd10856c9a91874f5'
[23:04:01 CEST] <nevcairiel> or did i misremember
[23:04:21 CEST] <philipl> nevcairiel: It does. But I'm pretty sure that won't do anything for painfully visible blocking.
[23:04:33 CEST] <nevcairiel> i dont get blocking, just a somewhat soft image
[23:04:38 CEST] <nevcairiel> which may be the 4:2:0 effect
[23:04:43 CEST] <philipl> possibly.
[23:05:10 CEST] <philipl> It's basically a toy as far as I can see. Quality is too terrible for any non-realtime uses IMHO.
[23:05:42 CEST] <nevcairiel> yeah my only use-cases for it are realtime, game recording through shadowplay, and realtime encoding for mobile streaming
[23:06:00 CEST] <nevcairiel> (mobile in my use-case being the tablet on my nightstand <.<)
[23:06:27 CEST] <philipl> You're re-encoding for bandwidth reasons?
[23:06:40 CEST] <nevcairiel> nah
[23:06:46 CEST] <nevcairiel> mostly just convenience
[23:07:02 CEST] <philipl> I mean, there isn't much material out there today that isn't natively supported on a tablet.
[23:07:13 CEST] <philipl> in terms of codecs and features.
[23:07:23 CEST] <nevcairiel> in a generic case, its better to transcode everything and have everything play, rather than transcode nothing and have a couple things not play
[23:07:42 CEST] <philipl> True, but a good server can be selective.
[23:07:49 CEST] <nevcairiel> well, i was lazy
[23:08:10 CEST] <nevcairiel> .. and i do watch a lot of old TV shows which are mpeg4
[23:08:26 CEST] <philipl> android tablets support that :-)
[23:08:36 CEST] <philipl> And actually, ipads do as well.
[23:08:54 CEST] <philipl> Sort-of. I think they screw up packed b frames.
[23:08:55 CEST] <nevcairiel> dont think i ever really tried, the android player i'm using right now certainly doesnt
[23:09:06 CEST] <philipl> Kodi should handle it.
[23:09:18 CEST] <philipl> I know my android devices expose hardware mpeg4 asp
[23:09:39 CEST] <philipl> Heck, I got mpeg2 working on my nexus 6 just by adding it to the xml file.
[23:10:21 CEST] <nevcairiel> Well, strictly speaking its all not my stuff, but $work software, including the android player app, which uses Google's ExoPlayer, which is really nice, but doesn't have very broad format support yet
[23:10:39 CEST] <nevcairiel> but supporting passthrough h264 on the server is certainly a goal for the next push on streaming features
[23:11:48 CEST] <nevcairiel> not sure i'll bother with mpeg4-asp
[23:12:20 CEST] <nevcairiel> transcoding will always need to be an option for bandwidth reasons when you are actually out, and not just using it over 300mbit wifi in your flat =p
[23:12:22 CEST] <cone-068> ffmpeg 03Vittorio Giovara 07master:4733a12dd17a: rtpdec_asf: Check memory allocation and free memory on error
[23:12:23 CEST] <cone-068> ffmpeg 03Michael Niedermayer 07master:d5a645625d87: Merge commit '4733a12dd17a91d606e0079ff9bb48b9f419cbef'
[23:27:51 CEST] <cone-068> ffmpeg 03James Almer 07master:1382add59df1: mpjpegdec: don't try to alloc an AVIOContext when probe is guaranteed to fail
[23:31:16 CEST] <cone-068> ffmpeg 03Andreas Cadhalpun 07master:6fdbaa2b7fb5: vp8: change mv_{min,max}.{x,y} type to int
[23:34:13 CEST] <llogan> c_14: in 43c1d82 you changed the example from pan=1 to pan=1c. was this due to d96e377?
[23:35:03 CEST] <llogan> with 1c i just get silence
[23:38:27 CEST] <c_14> IIRC, yes.
[23:38:47 CEST] <c_14> Let me test.
[23:44:12 CEST] <c_14> llogan: using 1c works correctly on 43c1d82b, looks like a regression somewhere afterwards
[23:44:57 CEST] <llogan> i thought i tested on 43c...but i already forgot and now am recompiling for something else
[23:58:54 CEST] <jamrial> ubitux: i wonder if implementing av_clip_int* with sse2 packss instructions would be faster than the c version
[23:58:58 CEST] <c_14> Wait, hmm. Now it's not working.
[00:00:00 CEST] --- Tue Jun  9 2015