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

[burek]

[00:07] <cone-365> ffmpeg.git 03Diego Biurrun 07master:831a1180785a: Update dsputil- and SIMD-related comments to match reality more closely
[00:07] <cone-365> ffmpeg.git 03Diego Biurrun 07master:edd1f833fa14: x86: h264_idct_10_bit: Use proper type in function prototype comments
[00:07] <cone-365> ffmpeg.git 03Diego Biurrun 07master:55519926ef85: x86: Make function prototype comments in assembly code consistent
[00:07] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:1c788eaca9a0: Merge commit '831a1180785a786272cdcefb71566a770bfb879e'
[00:07] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:a9b1936a4e46: Merge commit 'edd1f833fa145eb9c5026877c699ebe6efca00a0'
[00:07] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:4104eb44e629: Merge commit '55519926ef855c671d084ccc151056de9e3d3a77'
[00:16] <cone-365> ffmpeg.git 03Diego Biurrun 07master:0a8f91b1fbc1: dsputil: Remove disabled avg_no_rnd_qpel leftovers
[00:16] <cone-365> ffmpeg.git 03Diego Biurrun 07master:8199bb7be0db: dsputil.h: Clean up comments
[00:16] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:ea2bd139b75d: Merge commit '0a8f91b1fbc1b627d8db8c734c812beb32102936'
[00:16] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:153557dfcb10: Merge commit '8199bb7be0db423bcbbd252d092386634fcf1d68'
[00:24] <cone-365> ffmpeg.git 03Diego Biurrun 07master:503dda7d4f5b: dsputil.h: K&R formatting cosmetics
[00:24] <gueb> hello again
[00:24] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:db94b144e95f: Merge commit '503dda7d4f5b4d76eed0239e9da66993a182b009'
[00:25] <gueb> wm4, are you there?
[00:36] <cone-365> ffmpeg.git 03Diego Biurrun 07master:bb12c2e9c00e: dsputil: K&R formatting cosmetics
[00:37] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:dd7c2e9bce0c: Merge commit 'bb12c2e9c00e3d3c393885849b8fa31cd849dc92'
[00:44] <wm4> gueb: sort of...
[00:44] <gueb> :D
[00:45] <gueb> hello
[00:45] <cone-365> ffmpeg.git 03Diego Biurrun 07master:635ec127d4bc: dsputil: Merge variable declarations and initializations
[00:45] <cone-365> ffmpeg.git 03Diego Biurrun 07master:05563ccacc98: dsputil: cosmetics: Lose camelCase on ff_cropTbl and ff_squareTbl names
[00:45] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:16f619f57c07: Merge commit '635ec127d4bc0c49ae0ac4a50acd3da1ca8c2150'
[00:45] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:6016b8329bca: Merge commit '05563ccacc98fd185affdbf8cbaf094caf36b852'
[00:45] <gueb> what do you think that is easier, making my own muxer or modifying an existing one?
[00:46] <nevcairiel> for simple audio codecs just define a TwoCC RIFF code and shove it into existing containers, many support that
[00:47] <wm4> yeah, there's a big lookup table somewhere
[00:47] <nevcairiel> avformat/riff.c -> ff_codec_wav_tags
[00:48] <gueb> thanks
[00:48] <gueb> wow, 0x1234 is not taken :P
[00:50] <nevcairiel> the "official" codes are just sequentially numbered from 1 upwards, although there are some more modern codecs with higher numbers, mostly AAC related
[00:50] <Compn> does the world need yet another audio codec ? :P
[00:51] <cone-365> ffmpeg.git 03Diego Biurrun 07master:acd2b8e42df2: rnd_avg.h: K&R formatting cosmetics
[00:51] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:3a27f968f990: Merge commit 'acd2b8e42df25d46440583f93c12e5f285aebb31'
[00:52] <gueb> flac's tag is F1AC
[00:52] <gueb> :O
[00:52] Action: wm4 wonders if 0xBEEF is taken
[00:52] <nevcairiel> any 16-bit number will do
[00:53] <nevcairiel> as long as its not taken
[00:53] <gueb> no, BEEF neither
[00:54] <gueb> it works :D
[00:57] <cone-365> ffmpeg.git 03Diego Biurrun 07master:945673f792eb: dsputil_template: K&R formatting cosmetics
[00:57] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:fdf4eb7911b3: Merge commit '945673f792eb4141860ed66664156df685f7b7f0'
[00:58] <nevcairiel> anyway, with a riff code defined, putting it into wav, avi or even mkv should work
[00:58] <nevcairiel> probably a bunch more
[00:58] <gueb> yes, I am trying it with matroska
[01:08] <cone-365> ffmpeg.git 03Diego Biurrun 07master:6a8b35dc88b4: dsputilenc_mmx: Merge two assignment blocks with identical conditions
[01:08] <cone-365> ffmpeg.git 03Diego Biurrun 07master:38675229a879: dsputil_mmx: K&R formatting cosmetics
[01:08] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:55f53f6c29ac: Merge commit '6a8b35dc88b4a1a452f192fbbf53ae7f59bc3f23'
[01:08] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:d926c4b240ed: Merge commit '38675229a879aa5258a8c71891fc8cbf74cf139f'
[01:18] <cone-365> ffmpeg.git 03Diego Biurrun 07master:a36947c167d7: dsputilenc_mmx: K&R formatting cosmetics
[01:18] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:b7a5f5dc6662: Merge commit 'a36947c167d7278b891453083b57dc56b7a7f5c5'
[01:25] <cone-365> ffmpeg.git 03Diego Biurrun 07master:f8bbebecfd7e: x86: motion_est: K&R formatting cosmetics
[01:25] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:925ce6faf4dd: Merge commit 'f8bbebecfd7ea3dceb7c96f931beca33f80a3490'
[01:42] <cone-365> ffmpeg.git 03Diego Biurrun 07master:4cb4680c1087: x86: dsputil_x86.h: K&R formatting cosmetics
[01:42] <cone-365> ffmpeg.git 03Diego Biurrun 07master:441b09391571: x86: dsputil_init: K&R formatting cosmetics
[01:42] <cone-365> ffmpeg.git 03Diego Biurrun 07master:db3f61a04f1f: x86: dsputil_init: Drop some unnecessary parentheses
[01:42] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:236874a57192: Merge commit '4cb4680c1087a2cd13d4b0c9167a2eb3147f99d8'
[01:42] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:27cab16ce719: Merge commit '441b093915717afa7d24be34bdab2a4911b30a57'
[01:42] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:5dd97d5809ad: Merge commit 'db3f61a04f1f66746660f921bb2780ddf1141f3b'
[01:47] <Compn> i thought we were going to do one giant k&r commit and get it over with
[01:47] <Compn> did that plan fail ?
[01:48] <cone-365> ffmpeg.git 03Diego Biurrun 07master:671c8785596e: bfin: dsputil: Remove unused global variable
[01:48] <cone-365> ffmpeg.git 03Diego Biurrun 07master:14efbe694ac5: bfin: dsputil: Drop broken vsad bits
[01:48] <cone-365> ffmpeg.git 03Diego Biurrun 07master:f5f099766816: bfin: hpeldsp: Drop broken put_pixels_*_xy2_nornd bits
[01:48] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:0f95856834d0: Merge commit '671c8785596ea4a45817ba302289004ff456630a'
[01:49] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:c686cf23aa86: Merge commit '14efbe694ac5beff98f5c5e652c166603f1738cf'
[01:49] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:2b02c1a698e3: Merge commit 'f5f099766816aab3ad805c63e85f12cb664dc9a8'
[01:56] <cone-365> ffmpeg.git 03Diego Biurrun 07master:1e33095b83ad: bfin: dsputil: Drop broken and trivial profiling code
[01:56] <cone-365> ffmpeg.git 03Diego Biurrun 07master:a3e7562621bd: bfin: dsputil: K&R formatting cosmetics
[01:56] <cone-365> ffmpeg.git 03Diego Biurrun 07master:e99af2a3b166: bfin: Refactor duplicated l1_text/l1_data_B macros
[01:56] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:a4369dbb8fda: Merge commit '1e33095b83addd8d24bc16bd08aa734fa161d515'
[01:56] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:edf426135005: Merge commit 'a3e7562621bd96ce909e07149c419b6ba85cc54f'
[01:56] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:91a61c4c156d: Merge commit 'e99af2a3b1660b4f328335149980064692097cad'
[02:04] <cone-365> ffmpeg.git 03Diego Biurrun 07master:da785231ea0b: bfin: Refactor duplicated assembly-related macros
[02:04] <cone-365> ffmpeg.git 03Diego Biurrun 07master:80173c71bab3: bfin: hpeldsp: K&R formatting cosmetics
[02:04] <cone-365> ffmpeg.git 03Diego Biurrun 07master:bbf0ef57e9d2: bfin: Move all assembly declarations only used within one .c file there
[02:04] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:3141b04c7fd4: Merge commit 'da785231ea0b82b5c2526babbb2871c935b21a87'
[02:04] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:cbf190f7aef0: Merge commit '80173c71bab3b8817c148837bdc920557018f428'
[02:04] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:c49797637ff7: Merge commit 'bbf0ef57e9d2d7bb2995f664dd74c8229bca25f5'
[02:10] <gueb> how is managed aligned memory?
[02:10] <gueb> is there a function for request aligned memory?
[02:10] <wm4> av_malloc
[02:10] <gueb> oh
[02:10] <gueb> so simple!
[02:12] <gueb> I am adapting a code for using matrices
[02:12] <cone-365> ffmpeg.git 03Diego Biurrun 07master:13ae97b210f3: bfin: hpeldsp: "nornd" ---> "no_rnd" function name suffix for consistency
[02:12] <cone-365> ffmpeg.git 03Diego Biurrun 07master:a7cc4ac9d99b: bfin: dsputil: Unconditionally compile hpel pixels code
[02:12] <cone-365> ffmpeg.git 03Diego Biurrun 07master:929ec39ec449: bfin: hpeldsp: Split no_rnd pixel operations off into a separate file
[02:12] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:866e11b33b29: Merge commit '13ae97b210f35d77290f4edb0d6846269271729a'
[02:12] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:26f4a509820d: Merge commit 'a7cc4ac9d99bd586c8939f4312f8c9e56d5f5730'
[02:12] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:be60e20498c7: Merge commit '929ec39ec4497827f7530f2aaa31646ef35462ee'
[02:13] <gueb> and I would like to align rows, so I need to put some padding
[02:13] <gueb> at the end of each row
[02:13] <gueb> is there any way to know the align size?
[02:14] <gueb> a macro, perhaps
[02:14] <wm4> well, you can look what libavutil/mem.c does
[02:15] <gueb> mmmm
[02:16] <gueb> alignement is 16 unless AVX is present, then is 32
[02:16] <gueb> thanks
[02:18] <cone-365> ffmpeg.git 03Diego Biurrun 07master:eb2b8bce39c9: bfin: Use more sensible file names
[02:18] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:f3d3e3fa4e10: Merge commit 'eb2b8bce39c93d16a02656238248c6cf697f447f'
[03:20] <Zeranoe> lol http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=17&t=1851
[03:26] <Compn> llogan : bypassing an opportunity to bikeshed about number of developers in git repo list on ffmpeg.org ? you're no fun!
[03:27] <michaelni> Zeranoe, i dont think a default of 1.4center + 0.5 surround would work with all kinds of 5.1 input
[03:27] <michaelni> s/work/sound good/
[03:34] <Compn> michaelni : want to run some double blind tests? :p
[03:38] <michaelni> cant hurt if you have volunteers, diverse input material and someone to organize it
[04:21] <llogan> Zeranoe: lol indeed. much anger in that one.
[04:27] <llogan> Compn: next bikeshed is site redesign. go ape.
[04:41] <gueb> good night
[04:43] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:dded5ed9c5eb: avcodec/libx265: fill headers in extradata
[04:59] <Zeranoe> Hats off to FFmpeg, ffplay was able to handle 4k at 60fps while VLC and MPC-HC chocked. Proabably multithreaded decoding
[05:34] <Zeranoe> Does the output bitrate effect encoding speed?
[06:05] <anshul> yes encoding speed directly propotional bitrate
[06:20] <Zeranoe> anshul: Lower bitrate=faster speeds?
[06:21] <anshul> higher birate = faster speeds
[06:23] <anshul> since algorithm of encoders time complexity increase when lower bitrate
[06:23] <anshul> lower bitRate = more compression
[06:23] <anshul> morecompression = high timecomplexity
[06:24] <anshul> high timecomplexity = slow speed
[06:24] <anshul> hence lower bitrate = slow speed
[06:25] <Zeranoe> I'm looking to do some benchmarking of a few encoders. Is there a fall off point where the higher bitrate will start to cause IO problems?
[06:26] <Zeranoe> I'm looking for some data for the fastest realtime encoder FFmpeg has.
[06:28] <anshul> when bitrate is high then look for swap read write when encoder start using swap then they go slow because of time taken to read write from swap is very high.
[06:29] <anshul> so the benchmark for higher bitrate might depend on ram size used and specification of PC
[06:29] <anshul> It might also depend on number of application already running on that PC 
[06:30] <anshul> sp bench mark for dedicated server and personal pc differs a lot
[06:31] <Zeranoe> will benchmark results be helpful to other people, or not because of what you just said
[06:34] <anshul> benchmark will help in choosing the encoder.
[06:49] <anshul> so things wil help if we get  time , bitrate , ramsize graph of different encoder
[06:54] <Zeranoe> wow vp9 is slow
[07:00] <Zeranoe> I think mjpeg is the fastest realtime encoder
[07:39] <ubitux> https://blog.mozilla.org/research/2014/03/05/introducing-the-mozjpeg-project/
[07:40] <ubitux> seems it's talking about you pengvado (jpgcrush)
[07:41] <ubitux> > So far as we know, no production encoder has this functionality built in
[07:41] <ubitux> meh
[09:21] <RT|AO> ubitux: mozjpeg breaks in many situations now, at least I found 2. 1 for RGB, another 1 for CMYK/YCCK.
[09:22] Action: RT|AO is thinking about writing his own JPEG stripper in C.
[09:23] <anshul> I was trying to add closed caption  in ffmpeg, I found that some frames startbyte are fc, fe fd which means that they contain EIA-608 and EIA -708 
[09:24] <anshul> is it really possible that one stream contain both standurd of closed caption
[10:23] <kierank> anshul: yes
[10:23] <kierank> For backwards compat
[10:24] <kierank> Closed captions are complicated
[10:26] <anshul> In ffmpeg we have two codec 608 and 708, if select anything on basis of startbyte it may lead to wrong result
[10:31] <anshul> I think selection to be done per frame basis.
[10:36] <kierank> Yes it is allowed to change
[10:36] <kierank> And it does in reality
[11:44] <BBB> omg there is a question on the libvpx mailing list about how to calculate bitrate, the answers people come up with is amazing
[11:45] <av500> send it to phoronix
[11:46] <av500> codec-devel?
[11:46] <ubitux> BBB: hey
[11:47] <ubitux> BBB: filter_8tap_2d_fn() in x86/vp9dsp_init
[11:47] <ubitux> iirc plepere suggested to make a single merged asm version 
[11:48] <ubitux> do you think it's worth the effort?
[12:00] <cone-797> ffmpeg.git 03Vittorio Giovara 07master:2e708f17083f: ljpeg: fix duplicated pixel format entry
[12:00] <cone-797> ffmpeg.git 03Michael Niedermayer 07master:0c402810faf6: Merge commit '2e708f17083fc41f10161f2406d57ec154c75468'
[12:15] <cone-797> ffmpeg.git 03Luca Barbato 07master:afdf94689c4e: aac: K&R formatting cosmetics
[12:15] <cone-797> ffmpeg.git 03Michael Niedermayer 07master:b5bdd04f0818: Merge remote-tracking branch 'qatar/master'
[12:23] <BBB> ubitux: yes!
[12:24] <BBB> ubitux: if you're in for that, I'll happily review... not sure how much gain to expect, but a few percent might be possible
[12:25] <ubitux> i don't think i'm in currently
[12:25] <BBB> av500: yes
[12:25] <ubitux> i was just wondering again about that while looking at namespacing the asm symbols
[12:25] <BBB> yeah they're both good ideas
[12:25] <ubitux> (for consistency i had to rename those into ff_vp9_*
[12:25] <ubitux> )
[12:25] <ubitux> (consistency ’ for making it work actually)
[12:33] <BBB> did plepere post a new patch on the ml?
[12:34] <BBB> I don't see any
[12:55] <plepere> BBB : I didn't give a new version
[12:56] <plepere> BBB : I've added plenty of stuff, and mraulet wants to review it before me pushing it.
[12:57] <BBB> plepere: ok
[12:57] <BBB> plepere: when you've got something you'd like me to look at, poke me
[12:57] <BBB> plepere: I thought it was pretty good last time, so hopefully after next round it can go in
[12:57] <plepere> :D
[12:58] <plepere> do you want to see the 2d_8tap I've done ?
[12:58] <BBB> yeah
[12:58] <plepere> mraulet suggests not using it and just using a C wrapper, though. :(
[12:58] <BBB> I hope it doesn't have 7 movdqas per row :-p
[12:58] <BBB> but I don't know how else to do it
[12:58] <JEEB> :)
[12:59] <plepere> well I'm doing shifting registers, so I've got that going for me. :)
[13:00] <plepere> BBB : can I send you a patch with everything I've done, so you've got an intermediate version of what I'm probably going to submit ?
[13:00] <BBB> sure, but I don't mind waiting another few days
[13:01] <BBB> do whatever is faster for you
[13:01] <BBB> getting it in is more important than me looking at it 2 days early or so ;)
[13:01] <plepere> if I can have some input during the week-end, I'm all for it. :)
[13:02] <BBB> ok
[13:16] <plepere> BBB : ok, sent. :)
[13:17] <BBB> \o/
[13:18] <BBB> will look over the weekend
[13:18] <plepere> thanks a bunch.
[13:18] <BBB> happy to, let's get it in, maybe I'll want to write some assembly myself later on
[13:19] <BBB> I mean, we can mux it into mp4 and x265 is not dog-slow anymore right? so it's actually like something that can be used for real now
[13:19] <plepere> BTW, unrelated : I'm starting to look for my next job for the end of the year. Do you know any company interested in a low-level programmer ?
[13:19] <BBB> google hires people like that
[13:20] <JEEB> too bad google jobs usually mean that one has to relocate and that usually means visas and that usually means that one has to already have papers out of the uni \o/
[13:20] <BBB> email me privately I can list a few companies, also tell me specifically what you want to do (or if you don't know yet), there's a lot of sectors where such skills are useful but they're not all related to multimedia or even in pure engineering firms
[13:21] <BBB> although typically out of uni you'll want a pure engineering firms, the other jobs require a few years experience
[13:21] <BBB> (most of the time - not always)
[13:21] <plepere> JEEB : I want to relocate. :D
[13:21] Action: JEEB just got a call from intel
[13:22] <Compn> JEEB : are they inviting you to join the cabal of evil ?
[13:22] <BBB> work time now, bbl
[13:22] <JEEB> Compn, yes -- they want to check if I am as people have told for two hours on tuesday
[13:22] <plepere> BBB : x264 is the encoder. :p but yeah, openHEVC is starting to have interesting performance with all this assembly.
[13:23] <JEEB> x265 is pretty fast now, preset placebo and refs/bframes maxed is now ~0.4fps with 720p on a i5 3570K
[13:24] <plepere> I think once I've got the sao and idct done, we'll be able to decode  ra HD @ 50fps on a single core.
[13:25] <saigono> 0.4fps is pretty fast? No way
[13:25] <saigono> doesn't seem that perfomance increased since summer or autumn '13
[13:26] <JEEB> yeah, but that at least gives you better quality than x264 maxed out :P
[13:26] <JEEB> and it is fast when compared to libvpx and VP9
[13:26] <JEEB> you can go faster, but I'm not sure how fast you can go until you start losing the edge on x264
[13:26] <JEEB> anyways, 0.4fps is something I can already kind of use if I have the need to
[13:27] <saigono> well, it's still far away from realtime encoding :) 
[13:28] <JEEB> you missed the "preset placebo" part?
[13:28] <saigono> oh
[13:28] <saigono> yep
[13:29] <plepere> hmmm.
[13:30] Action: plepere wonders if he should do a script to convert all his "holiday videos" to h264.
[13:45] <mraulet> BBB: as you have the patch and you are on mac, you would probably see the same segfault than me. if you have any idea where it comes from. it would be good to know.
[15:00] <yanrong> I'd like to contribute a new fft kernel to FFmpeg, which is optimized for Power platform,  single precision float point format. The kernel will be written in c language and will be optimized with PowerPC VSX built-in functions, so that one can use GCC compiler options to switch between big endian and little endian cases without extra code. Is there any comments on this contribution proposal? Appreciate your feedback.
[15:01] <av500> powerpc still a thing?
[15:02] <Compn> do we want BE/LE runtime code ?
[15:03] <Compn> or are mac people used to making those dual-binary programs ?
[15:03] <Compn> for ppc and intel-mac
[15:03] <Compn> yanrong : sounds good :)
[15:04] <yanrong> Thanks. I noticed the current fft kernel is written in assembler code. There maybe some problems when run on little endian Power platforms (e.g. IBM power8), so I want to do some contribution.
[16:36] <plepere> ubitux. I don't understand something. 
[16:37] <plepere> I've doce C wrappers so when doing a filter on a block width of 12 and plus, it calls multiple times the functions for the block width 4 or 8.
[16:37] <plepere> *done
[16:38] <plepere> I've got a function, it works with the widths 12 and more, but not on the core 4 and 8 functions.
[16:38] <plepere> even though the large widths, using the smaller ones are correct !
[17:01] <michaelni> yanrong, how does it perform  speedwise compared to existing code ?
[17:27] <cone-797> ffmpeg.git 03Michael Niedermayer 07master:2c9e5cb1a698: avcodec/arm/fft_fixed_neon: reduce diff by 2 spaces to libav
[17:27] <cone-797> ffmpeg.git 03Peter Ross 07master:7380201451a2: avcodec/adpcm: squelch 'mismatch in coded sample count' warning for AV_CODEC_ID_ADPCM_EA_R2/3
[18:21] <cone-797> ffmpeg.git 03James Almer 07master:722b48bc1256: configure: add missing avx2 support check
[18:34] <cone-797> ffmpeg.git 03Diego Biurrun 07master:36b822b8be7f: arm: dsputil: Drop restrict keyword from add_pixels_clamped_armv6 prototype
[18:34] <cone-797> ffmpeg.git 03Diego Biurrun 07master:07ea8a7e943e: configure: Group and sort function/struct/type checks
[18:34] <cone-797> ffmpeg.git 03Michael Niedermayer 07master:5e5d8ace8a7f: Merge commit '36b822b8be7f9ecd6f9d87acaa786b128a873cd9'
[18:34] <cone-797> ffmpeg.git 03Michael Niedermayer 07master:2b94189e961b: Merge commit '07ea8a7e943ea6a7bdcd736e2fc3ed357dc15c57'
[18:47] <cone-797> ffmpeg.git 03Diego Biurrun 07master:d0adf55c05be: configure: Split some logical blocks off from CONFIG_LIST
[18:47] <cone-797> ffmpeg.git 03Michael Niedermayer 07master:332f1698559e: Merge commit 'd0adf55c05beaf80420747dded2d1884bff377ec'
[19:15] <cone-797> ffmpeg.git 03Diego Biurrun 07master:7a650caf6436: configure: Split some logical blocks off from HAVE_LIST
[19:15] <cone-797> ffmpeg.git 03Michael Niedermayer 07master:56a498bbba3f: Merge commit '7a650caf6436ddfe417bdcb5ce520c96c779af7b'
[19:24] <cone-797> ffmpeg.git 03Vittorio Giovara 07master:999d31d354f1: codec_desc: K&R formatting cosmetics
[19:24] <cone-797> ffmpeg.git 03Michael Niedermayer 07master:11e66d20d51f: Merge commit '999d31d354f1f0616a09691913659ac0abdcc899'
[19:25] <gueb> hello!
[19:33] <cone-797> ffmpeg.git 03Vittorio Giovara 07master:d42ea06798b8: codec_desc: add missing .long_name
[19:33] <cone-797> ffmpeg.git 03Michael Niedermayer 07master:4d10b93bd196: Merge commit 'd42ea06798b83d87397449ec6aad40cb5ea46e43'
[19:33] <michaelni> hello
[19:46] <cone-797> ffmpeg.git 03Vittorio Giovara 07master:f20977921be5: codec_desc: group image codecs together
[19:46] <cone-797> ffmpeg.git 03Michael Niedermayer 07master:a8a84fa8b2cd: Merge remote-tracking branch 'qatar/master'
[21:51] <gueb> what should I do to manage endianness?
[21:51] <gueb> for example
[21:52] <gueb> I have audio samples s16le
[21:52] <gueb> on x86 I can use it without problem
[21:52] <gueb> but on another architectures...
[21:52] <JEEB> look at the AV_RLXX/AV_WLXX
[21:52] <JEEB> functions
[21:53] <JEEB> you can read and write something from/to specific endianness
[21:53] <JEEB> or well, macros
[21:53] <JEEB> not functions
[21:54] <gueb> oh, nice
[21:57] <gueb> what is N?
[21:57] <JEEB> native
[21:58] <JEEB> as in, not specific ÖP
[21:58] <JEEB> :P
[21:58] <gueb> :S
[23:02] <gueb> I am puzzled :S
[23:02] <gueb> I am trying to read from frame->data
[23:02] <gueb> but I get segmentation fault
[23:03] <gueb> I am using two channels
[23:03] <gueb> when I read from frame->data[1][0] it breaks
[23:03] <gueb> where is the second channel?
[23:04] <wm4> gueb: that depends entirely on the audio format
[23:04] <wm4> data[1] is used only with non-interleaved format (called planar in ffmpeg)
[23:04] <gueb> oh
[23:04] <wm4> for normal (interleaved) formats, all data is packed in data[0]
[23:05] <gueb> thanks, wm4 
[23:06] Action: Compn wonders if libav is asking any other devels to 'reunite'
[23:06] <wm4> Compn: what where
[23:06] <Compn> wm4 : in private of course
[23:06] <Compn> libav way, always private
[23:07] <wm4> no
[23:07] <wm4> currently they're backporting ffmpeg stuff
[23:07] <wm4> because debian possibly wanting to switch to ffmpeg makes them nervous
[23:08] <Compn> wm4 : do you troll in their channel ? :P
[23:08] <gueb> :O
[23:08] Action: Compn wonders who is trolling there
[23:08] <wm4> wherever I am I must also troll
[23:08] <Compn> :)
[23:08] <gueb> I discovered libav just some days ago
[23:09] <Compn> gueb : we used to be one project :P
[23:09] <gueb> I know, have read about that
[23:10] <gueb> ego's programmers strikes back :P
[23:13] Action: Compn goes afk
[23:14] <gueb> bless valgrind
[23:31] <cone-797> ffmpeg.git 03Michael Niedermayer 07master:f6122ed375ab: configure: remove unused identifer that was added by cleanups
[23:31] <cone-797> ffmpeg.git 03Michael Niedermayer 07master:c17dea05f746: configure: factorize mips arch extensions out
[23:31] <cone-797> ffmpeg.git 03Yu Xiaolei 07master:fbe9ae482d51: avfilter: make avfilter_graph_get_filter use const string name
[00:00] --- Sat Mar 15 2014