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

[burek]

[00:02] <Daemon404> kierank, most of my issues are ordering issues
[00:02] <Daemon404> like knowing to set some ctx var before calling some func
[00:02] <kierank> me too
[00:02] <Daemon404> which isnt really documented
[00:03] <Daemon404> more confusing so because the png encoder doesnt care if you set it before or after avcodec_open
[00:03] <Daemon404> but mjpeg does
[00:03] <Daemon404> so you may or may not run into the problemn depending on teh encoder
[00:20] <pross-au> anyone: is bytestream2 preferred in codecs over manual byte handling, as it produces cleaner code, and less prone to overflow bugs? 
[00:48] <michaelni> pross-au, for codecs where speed isnt important, using bytestream2 with full checks is probably better
[01:31] <ubitux> michaelni: btw, printing default value might be nice
[01:31] <ubitux> llogan: thx for that change, nice
[01:33] <llogan> ubitux: yw
[01:35] <cone-642> ffmpeg.git 03Michael Niedermayer 07a8e0d51bb814: opt: Add support to query ranges
[01:35] <cone-642> ffmpeg.git 03Michael Niedermayer 07f4ceca6261bd: opt: print ranges in opt_list()
[01:35] <cone-642> ffmpeg.git 03Michael Niedermayer 07e0a553d526d5: opt_list: fix vertical alignment of types
[01:40] <michaelni> ubitux, agree but i cant think of how/where to do it cleanly
[01:41] <ubitux> i'd make a "foo bar bla (from -1 to INT_MAX, default: 15)"
[01:42] <ubitux> or without the from
[01:44] <ubitux> michaelni: what's this "nb_range"?
[01:44] <ubitux> nb_ranges*
[01:44] <ubitux> how can you have more than 1?
[02:03] <michaelni> ubitux, for example you can have cif, qcif, and some other fixed ones supported but not any resolution between
[02:03] <michaelni> or 44100 48000 32000 as sample rates but nothing between
[02:03] <ubitux> oh, ok.
[02:04] <michaelni> "foo bar bla (from -1 to INT_MAX, default: 15)" looks nice / patch welcome, i hope it doesnt become too long
[02:04] <durandal11707> michaelni: l did some strange things with tak decoder, and I merged what I think was good, there is still some small stuff left but i see no real benefit in merging their code (extra malloc/memsets and local arrays)
[02:05] <ubitux> why did they do that?
[02:05] <durandal11707> the little evil plan
[02:06] <ubitux> we will have to deal with it at some point
[02:09] <durandal11707> there is still left to do asm optimisations of decorrelation code
[02:11] <durandal11707> lol, there is actually no any reason to use their code, because it is significantly slower for some encoding modes
[02:13] <ubitux> i guess they just wanted to do it differently then
[02:13] <ubitux> and didn't find how to make it better so they decided to make it worse
[02:13] <ubitux> :D
[02:13] Action: ubitux feels like being a troll a lot lately
[02:23] <ubitux> here we go, reformating shitstorm incoming
[02:23] <ubitux> :D
[02:24] <Daemon404> if youre referring to h264
[02:24] <Daemon404> i welcome taht
[02:25] <ubitux> please
[02:25] <ubitux> look at the last lines
[02:25] <ubitux> wtf is that?
[02:25] <ubitux> how can you call that an improvement?
[02:25] <cone-642> ffmpeg.git 03Paul B Mahol 073fd60d804996: gifdec: port to bytestream2 API
[02:25] <Daemon404> it's called consistency
[02:25] <ubitux> +    h->cbp                              =
[02:25] <ubitux> +        h->cbp_table[mb_xy]             = cbp;
[02:25] <ubitux> what about this?
[02:26] <Daemon404> i have no context for that
[02:26] <ubitux> there is none
[02:26] <ubitux> the tool just derped
[02:26] <ubitux> consistency does not overrule common sense Daemon404 
[02:26] <ubitux> it's not more readable i'm sorry
[02:27] <Daemon404> yes
[02:27] <Daemon404> yes it is
[02:27] <Daemon404> h264 is a mess of shitty formatted and unreadable code
[02:27] <ubitux> adding spaces is one things
[02:27] <Daemon404> cleanup has issues, but it's still a massive improvement
[02:27] <ubitux> breaking lines randomly, or adding tons of spaces for nonsensical align is pretty stupid
[02:27] <ubitux> i disagree
[02:27] <Daemon404> i agree to disagree
[02:28] <Daemon404> keep your crapcode
[02:28] <ubitux> lol it's not even done properly
[02:28] <ubitux> +    { 1, 1, 0},
[02:28] <ubitux> nice spaces consistency
[02:29] <Daemon404> that area looks correct
[02:29] <ubitux> {<space>xxxx<notspace>}
[02:29] <ubitux> +    tprintf(h->s.avctx, "pred_nnz L%X T%X n%d s%d P%X\n", left, top, n,
[02:29] <ubitux> +            scan8[n],
[02:29] <Daemon404> it's a very common wya to format such things
[02:29] <ubitux> +            i & 31);
[02:29] <ubitux> wtf is this line break?
[02:30] <ubitux> seriously, reformating is the most simple thing to do ever
[02:30] <Daemon404> that one's dumb, indeed
[02:30] <ubitux> why do they fail even at this?
[02:30] <Daemon404> but i sitll think youre just beign a torll here
[02:30] <ubitux> the whole patch is like this
[02:30] <ubitux> like all the previous one
[02:30] <Daemon404> most of it looks OK
[02:30] <ubitux> no
[02:31] <ubitux> and the removing of '{'
[02:31] <ubitux> wth is that?
[02:31] <Daemon404> for one line if/else?
[02:31] <durandal11707> does it produce different code?
[02:31] <ubitux> Daemon404: look at init_cavlc_level_tab
[02:31] <Daemon404> no it's cosmetics
[02:31] <ubitux> look at the first for loop
[02:32] <Daemon404> -static av_cold void init_cavlc_level_tab(void){
[02:32] <Daemon404> +static av_cold void init_cavlc_level_tab(void)
[02:32] <Daemon404> +{
[02:32] <Daemon404> this?
[02:32] <durandal11707> did you check, that binary is unchanged?
[02:32] <ubitux> this is not a for loop Daemon404 
[02:32] <Daemon404> thats like one of the fucking definitions of k&r
[02:32] <ubitux> 3 line below
[02:32] <Daemon404> is funcs have { on an ew line
[02:32] <ubitux> read what i say please :p
[02:32] <Daemon404> yes
[02:32] <Daemon404> you said it after
[02:32] <Daemon404> or whiel i was typing
[02:33] <Daemon404> and the { is not spec-required
[02:33] <ubitux> and it just makes the code unreadable to remove it
[02:33] <ubitux> anyway, half of the patch is complete nonsense
[02:33] <Daemon404> it's sitll far more readble than before
[02:33] <ubitux> luca just ran a badly configured uncrustify on the file
[02:33] <ubitux> and didn't check anything
[02:34] <Daemon404> [20:27] <@Daemon404> cleanup has issues, but it's still a massive improvement
[02:34] <Daemon404> larely youve just been bitching nonstop about libav
[02:34] <Daemon404> rather than bitch
[02:34] <Daemon404> why dont you just not merge shit
[02:35] <ubitux> you know the reasons
[02:35] <Daemon404> i used to think libav was teh worst with their complaining about michael, but i think this channe lhas surpassed that now
[02:35] <ubitux> stopping merges because libav is a cosmetic mafia would be stupid
[02:36] <Daemon404> id rather have a cosmetic mafia than mpeg*c
[02:36] <ubitux> i'd rather decode mpeg than having beautiful spaces
[02:36] <Daemon404> id rather have both
[02:37] <durandal11707> michaelni: is there function which sets pixels of whole frame without ignoring linesize?
[02:39] <Daemon404> you could probably memset whole planes, the extra padding and all
[02:39] <Daemon404> in a decoder anyway
[02:41] <durandal11707> well, i think stuff after linesize should not be touched
[02:41] <Daemon404> nothing uses it
[02:41] <Daemon404> afaik
[02:48] <Daemon404> ubitux, +1 for reply
[02:48] <Daemon404> i was going to just do that
[02:49] <ubitux> i was just pissed off to see them fail at simple tasks like this
[02:50] <iive> Daemon404: are you libav developers? I've never heard you say anything bad about them, you always defend them, no matter how stupid stuff they do...
[02:50] <Daemon404> im both sides
[02:50] <michaelni> durandal11707, there is but iam not sure its in any non static function
[02:50] <iive> and you also trash talk about ffmpeg.
[02:50] <Daemon404> and there is immensly stupid crap on either side
[02:51] <Daemon404> you simply miss all my complaints about libav
[02:51] <Daemon404> since this isnt libav.
[02:51] <durandal11707> michaelni: there is memsetw but it is not used by anything (code that use it is commented)
[02:51] <ubitux> so you just like opposition
[02:51] <ubitux> :))
[02:51] <Daemon404> i like sanity
[02:51] <Daemon404> and tehre is very little of it
[02:51] <Daemon404> you guys are like a high school man
[02:52] <Daemon404> (you guys == everyone on both)
[02:52] <michaelni> durandal11707, feel free to remove it
[02:52] <ubitux> Daemon404: i'm mostly alone to troll, people just agree ;)
[02:52] <ubitux> they can't deny anyway
[02:53] <durandal11707> michaelni: does compiler optimize memset?
[02:53] <Daemon404> compiler? one would think memset is optimzied in libc
[02:53] <Daemon404> in its impl
[02:53] <iive> durandal11707: is it constant size?
[02:53] <michaelni> Daemon404, memset(x,y,4) should not call lib
[02:54] <durandal11707> Daemon404: not here, last time i checked
[02:54] <Daemon404> michaelni, well i tend to think people wouldnt use memset for 4 bytes
[02:54] <Daemon404> :/
[02:54] <michaelni> Daemon404, they do that for consistency sometimes
[02:54] <Daemon404> fun
[02:54] <Daemon404> durandal11707, there's soem asm optimized memset and pals in most libcs
[02:54] <Daemon404> is what i meant
[02:55] <iive> of course they would do it.
[02:55] Action: Daemon404 remembers when it was cool to write your own asm optimized memcpy
[02:55] Action: Daemon404 doesnt miss that
[03:18] <durandal11707> python dictator left g
[08:39] <burek> i just saw the art contest for the winter logo
[08:39] <burek> next time we could post a contest to the devianart.com
[08:40] <burek> it's a place where very good designers meet and share their work and stuff
[11:06] <cone-616> ffmpeg.git 03Nicolas George 07e6701d51e1c7: lavc/mlpdec: reset layout when channels change.
[12:50] <cone-616> ffmpeg.git 03Stefano Sabatini 073eae531de287: lavfi/swapuv: switch to filter_frame API
[12:50] <cone-616> ffmpeg.git 03Stefano Sabatini 0735e81441fc24: lavfi/sendcmd: switch to filter_frame API
[13:38] <cone-616> ffmpeg.git 03Reimar Döffinger 078ee14aa5c7a2: lavf: improve avoid_negative_ts help text
[13:55] <cone-616> ffmpeg.git 03Martin Storsjö 072c9639227766: avpicture: Don't assume a valid pix fmt in avpicture_get_size
[13:55] <cone-616> ffmpeg.git 03Mans Rullgard 0792dad6687f59: arm: fix use of uninitialised value in ff_fft_fixed_init_arm()
[13:55] <cone-616> ffmpeg.git 03Anton Khirnov 07380232fac3a6: snow: fix build after 594d4d5df3c70404168701dd5c90b7e6e5587793
[13:55] <cone-616> ffmpeg.git 03Mans Rullgard 07c29d49c1b3c8: dct-test: arm: indicate required cpu features for optimised funcs
[13:55] <cone-616> ffmpeg.git 03Mans Rullgard 079ebd45c2d58a: configure: do not bypass cpuflags section if --cpu not given
[13:55] <cone-616> ffmpeg.git 03Michael Niedermayer 077181806dc180: Merge commit '9ebd45c2d58ad9241ad09718679f0cf7fb57da52'
[14:03] <cone-616> ffmpeg.git 03Mans Rullgard 071234c66a315b: configure: arm: detect toolchain default arch version
[14:03] <cone-616> ffmpeg.git 03Michael Niedermayer 07840a002b6940: Merge commit '1234c66a315b139339d52ca193b3f1d67af9ce19'
[14:08] <cone-616> ffmpeg.git 03Mans Rullgard 07f0fe245bc31c: configure: arm: set fast_clz and fast_unaligned in cpuflags section
[14:08] <cone-616> ffmpeg.git 03Michael Niedermayer 07fa6bab785722: Merge commit 'f0fe245bc31cf4fa3b3ed0240cd1ab6f0d5043ea'
[14:13] <cone-616> ffmpeg.git 03Mans Rullgard 077fd90119bbf1: configure: clean up check_inline_asm and check_as functions
[14:13] <cone-616> ffmpeg.git 03Mans Rullgard 07c6ebc9faa221: configure: add check_insn function
[14:13] <cone-616> ffmpeg.git 03Michael Niedermayer 074f0cf62d5add: Merge commit 'c6ebc9faa2210d7f36a3036c357f6f199520f575'
[14:17] <cone-616> ffmpeg.git 03Mans Rullgard 077f2b3dcabd10: configure: arm: check inline and external asm support for extensions
[14:17] <cone-616> ffmpeg.git 03Michael Niedermayer 07ee9e7a2e7a66: Merge commit '7f2b3dcabd108926bde819ad574017f4161d1546'
[14:24] <cone-616> ffmpeg.git 03Mans Rullgard 07a7831d509f8d: arm: use HAVE*_INLINE/EXTERNAL macros for conditional compilation
[14:24] <cone-616> ffmpeg.git 03Mans Rullgard 07637606de2d2e: configure: arm: make _inline arch ext symbols depend on inline_asm
[14:24] <cone-616> ffmpeg.git 03Michael Niedermayer 0789c8eaa3216a: Merge commit '637606de2d2e0af0a9fa2f23f943765d7d7c5cd5'
[14:29] <cone-616> ffmpeg.git 03Mans Rullgard 07b326755989b3: arm: rename ARMVFP config symbol to VFP
[14:29] <cone-616> ffmpeg.git 03Michael Niedermayer 07aba1a48cc5b3: Merge commit 'b326755989b346d0d935e0628e8865f9b2951c30'
[14:53] <cone-616> ffmpeg.git 03Michael Niedermayer 07b2b12a1022bd: mpegts: rename get_bits64 to get_ts64
[14:53] <cone-616> ffmpeg.git 03Michael Niedermayer 077efee140d7d6: get_bits: rename get_bits_longlong to get_bits64
[15:07] <cone-616> ffmpeg.git 03Mans Rullgard 07b57c1da81e4f: arm: detect cpu features at runtime on Linux
[15:07] <cone-616> ffmpeg.git 03Michael Niedermayer 0741540b36a19d: bitstream: add get_bits64() to support reading more than 32 bits at once
[15:07] <cone-616> ffmpeg.git 03Michael Niedermayer 07096abfa15052: parser: fix large overreads
[15:07] <cone-616> ffmpeg.git 03Michael Niedermayer 0757cee8502384: Merge commit '096abfa15052977eed93f0b5e01afd2d47c53c1f'
[15:17] <cone-616> ffmpeg.git 03Clément BSsch 077f70db3f4f77: doc: sync avoid_negative_ts option with internal help.
[15:24] <ubitux> saste: i forgot something: we don't support expression anymore, right?
[15:24] <ubitux> oh it was a constant expr, ok.
[15:26] <saste> ubitux: indeed, is that a problem?
[15:27] <saste> now the volume is processed through av_strtod()
[15:27] <ubitux> if it was an expression evaluated according to the time yes
[15:27] <saste> 1/2 should be ok, 1+2/3+3/4 is not
[15:27] <ubitux> yeah whatever :)
[15:28] <saste> i plan to add support for dynamic expressions, so it will be supported eventually
[15:28] <saste> let's see if users will complain
[15:28] <ubitux> i don't think they will
[15:30] <cone-616> ffmpeg.git 03Stefano Sabatini 07402ac72bbc8f: lavfi/volume_justin: fix a few grammar inconsistencies in options description
[15:30] <cone-616> ffmpeg.git 03Stefano Sabatini 07769546631ca0: lavfi/volume_justin: add support to option shorthands and introspection
[15:38] <wm4> is there anyone actively working on the network portion of libavformat?
[15:39] <durandal_1707> ?
[15:44] <cone-616> ffmpeg.git 03Stefano Sabatini 07759e7a237fb6: doc/filters: fix copy&paste error in volume_justin documentation
[15:44] <cone-616> ffmpeg.git 03Stefano Sabatini 0710db70d5e9c9: lavfi: drop af_volume_stefano.c in favor of af_volume_justin.c
[15:44] <cone-616> ffmpeg.git 03Stefano Sabatini 0764e174e8b897: doc/filters: move volumedetect documentation below volume
[15:45] <durandal_1707> michaelni: is there similar protocol that allows to select stream?
[15:46] <durandal_1707> wm4: well it should not be hard to select only some streams by default ...
[15:47] <wm4> durandal_1707: yeah... it's more of an API question
[15:47] <wm4> also, I'm not sure if streams can be switched at runtime, but I think they can
[15:51] <wm4> also, I didn't test whether this really works this way
[15:51] <wm4> mms is mostly a mystery to me
[15:53] <Compn> durandal_1707 : old realmedia rtsp has mbr streams
[15:53] <Compn> mms has mbr streams too
[15:54] <Compn> and yes i think you can choose only one stream, possibly by adding to the url /audio/1 or so , but probably read spec
[15:54] <wm4> mms over http has a direct "http" header for stream selection
[15:55] <Compn> wm4 : people work on network lavf, but the real question is , does anyone work on mms ? which microsoft has stopped supporting really
[15:55] <Compn> microsoft switched to rtsp ...
[15:55] <Compn> ms-rtsp that is, X-streams
[15:56] <wm4> "As of 2012 Microsoft still recommends[1] using "mms://" as a "protocol rollover[2] URL". "
[15:56] <Compn> rollover, aka failback ?
[15:56] <Compn> or fallback
[15:57] <wm4> I don't know... maybe as "frontend" URL that the users get
[15:57] <Compn> yeah, because wmp takes the mms url and tries rtsp first
[15:58] <Compn> and if you use the mms url in an old windows media player (say version 6.4) it wont work at all
[15:58] <Compn> so microsoft is pretty much full of shit :\
[15:59] <Compn> for some servers anyways
[15:59] <Compn> some servers still work
[16:03] <cone-616> ffmpeg.git 03Paul B Mahol 0757231e4d5b46: tak: demuxer, parser, and decoder
[16:03] <cone-616> ffmpeg.git 03Michael Niedermayer 073a7ef8dc44ab: Merge commit '57231e4d5b467833fb289439cd35a92513bb55c1'
[16:03] <michaelni> durandal_1707, you should add yourself to MAINTAINER for tak*
[16:04] <michaelni> maintainerS
[16:05] <wm4> michaelni: why does av_seek_frame() not work for some demuxers?
[16:05] <wm4> michaelni: and why does avformat_seek_file() normally perform two seeks if the demuxer does not support the old API?
[16:07] <cone-616> ffmpeg.git 03Stefano Sabatini 075825e9425ba9: lavfi/version: remove unused dropped symbol
[16:08] <michaelni> wm4, it should only do 2 seeks if the first fails
[16:09] <wm4> michaelni: oh, I overlooked something... it does 3 seeks in the worst case
[16:09] <wm4> if the first fails, it will try a second time; if the second time succeeds, it'll seek a 3rd time
[16:11] <wm4> michaelni: also, aside from this, there should be a way to know whether a seek would seek past the end of the file
[16:11] <wm4> you want this for media players
[16:15] <michaelni> the sek function could return AVERROR_EOF if the seek request cannot be satsfied due to the files end
[16:16] <wm4> that would be nice
[16:22] <cone-616> ffmpeg.git 03Paul B Mahol 071a4250493b3a: MAINTAINERS: add myself for my works
[16:23] <durandal_1707> michaelni: shouldn't deprecated codec ids be ours and not libavs?
[16:40] <cone-616> ffmpeg.git 03Mans Rullgard 07cd71af90a92d: takdec: fix initialisation of LOCAL_ALIGNED array
[16:40] <cone-616> ffmpeg.git 03Josh Allmann 07b3deec325310: takdec: fix initialisation of LOCAL_ALIGNED array
[16:40] <cone-616> ffmpeg.git 03Justin Ruggles 071c012e6bfb77: x86: float_dsp: fix loading of the len parameter on x86-32
[16:40] <cone-616> ffmpeg.git 03Janne Grunau 079a2e79116d62: golomb: use unsigned arithmetics in svq3_get_ue_golomb()
[16:40] <cone-616> ffmpeg.git 03Michael Niedermayer 075c076205a67d: Merge remote-tracking branch 'qatar/master'
[17:20] <cone-616> ffmpeg.git 03Matthieu Bouron 074cd40ef343d3: lavfi/idet: switch to filter_frame API
[17:20] <cone-616> ffmpeg.git 03Matthieu Bouron 077f154bd54f27: lavfi/setfield: switch to filter_frame API
[17:22] <ubitux> yay
[17:22] <ubitux> no more?
[17:22] <saste> overlay
[17:22] <ubitux> oh right you sent a patch
[17:32] <cone-616> ffmpeg.git 03Michael Niedermayer 070110108a7c2f: sbr_hf_gen_sse: Optimize code a bit more.
[18:08] <durandal_1707> huh multimedia.cx dead
[18:11] <JEEB> someone updated mediawiki and failed?
[18:12] <JEEB> or too old PHP for a newer version
[18:13] <JEEB> I would guess the guy is working on it :)
[18:20] <Compn> just the multimedia wiki
[18:20] <Compn> maybe it got hakked
[18:21] <wm4> [aac @ 0x90d2ba0] get_buffer() failed
[18:21] <wm4> ?
[18:21] <wm4> I always seem to get that when playing http://lr2mp0.latvijasradio.lv:8000
[18:22] <Compn> in your mplayer2 fork ?
[18:22] <Compn> or ffplay ?
[18:23] <wm4> ffplay too
[18:24] <wm4> also, it takes quite long probing - maybe the server doesn't start streaming at frame boundaries?
[18:24] <Compn> works here with older ffplay
[18:24] <Compn> and old mplayer
[18:25] <Compn> ffplay version N-43594-gf0896a6 Copyright (c) 2003-2012 the FFmpeg developers
[18:25] <wm4> mplayer uses its own aac demuxer
[18:25] <wm4> which doesn't require as much data for probing (so it starts faster)
[18:25] <Compn> with -demuxer lavf it works too
[18:26] <Compn> also mplayer ffmpeg://http://...
[18:26] <wm4> but it requires really long to start
[18:26] <Compn> yes
[18:26] <Compn> you can change the probe buffer in demux lavf
[18:26] <wm4> that's not really the point
[18:27] <Compn> the probe should be quicker with less data
[18:27] <wm4> the point is that libavformat wants about 400 KB of data before it's "convinced" that it's AAC (> AVPROBE_SCORE_MAX / 4)
[18:28] <cone-616> ffmpeg.git 03Stefano Sabatini 07642a60f1c20f: lavfi/setfield: add support to named options and introspection
[19:13] <ubitux> how can we filter opened issues when searching in the trac?
[19:14] <cone-616> ffmpeg.git 03Stefano Sabatini 070ad654d4c987: lavu/opt: perform misc cosmetical fixes
[19:39] <cone-616> ffmpeg.git 03Piotr Bandurski 07e5550c0d0971: mjpegdec: support more pix_fmt_ids for grayscale
[19:55] <cone-616> ffmpeg.git 03Stefano Sabatini 07129d73715084: lavu/opt: make av_opt_query_ranges_default() return a meaningful error code
[20:07] <ubitux> are the fate samples available through http?
[20:11] <saste> do we have a function to automatically grow an array?
[20:11] <ubitux> dynarray_add
[20:11] <ubitux> but entries must be allocated nodes
[20:12] <ubitux> i've written an alternate one for styledsubtitles if you want
[20:13] <ubitux> saste: http://pastie.org/5499455
[20:14] <saste> well i'll try something already available
[20:15] <ubitux> (and it's usable like this: http://pastie.org/5499461)
[20:15] <saste> i'm going to fix ffplay -codec:a (and possibly add the same option to ffprobe)
[20:15] <ubitux> saste: yes, look at dynarray_add then
[20:15] <ubitux> if it's ffprobe you can use grow_array
[20:15] <ubitux> iirc it is in the cmdutils or something
[20:16] <saste> i don't want to use internal function in tools
[20:17] <saste> grow_array will do
[20:17] <ubitux> cmdutils are utils for the tools :p
[20:17] <ubitux> you have av_dynarray_add for the public one
[20:17] <ubitux> (public version of dynarray_add)
[20:20] <saste> any reason of having both av_dynarray_add and grow_array?
[20:20] <saste> on the other hand grow_array also supports the element size, which is lacking in av_dynarray_add
[20:20] <ubitux> iirc grow_array is closer to my pastie code
[20:21] <ubitux> but growarray realloc everytime or something
[20:21] <ubitux> i don't remember the details
[20:21] <ubitux> dynarray requires to allocate each node (the array is made of pointers)
[20:21] <ubitux> that is, all i'm saying is from memory
[20:24] <saste> whatever i'll use grow_array as seems easier
[20:24] <saste> (no performance concerns here)
[21:31] <saste> is it possible to compile ffplay with no libavfilter?
[21:32] <ubitux> it should
[21:32] <ubitux> according to the CONFIG_AVFILTER
[21:32] <wm4> judging from the ifdefs, no (because who tests that)
[21:37] <saste> anyway yes it is
[21:49] <maister> Getting some warnings in latest git: http://pastebin.com/G6syvQrm is this intended?
[21:53] <cone-616> ffmpeg.git 03Ramiro Polla 07f2c49da9ac48: dshow: fix return code when opening device
[21:55] <michaelni> maister, that code is there since 2009-02-24
[21:56] <maister> strange that the warning started to show up just now ...
[21:56] <maister> maybe some other headers started including it
[21:56] <maister> But anyways, is GCC-only extensions allowed in the code base?
[22:03] <ubitux> changing them to unsigned should be safe
[22:03] <ubitux> hopefully
[22:03] <ubitux> :)
[22:07] <maister> Noticed one thing. I used ffmpeg 1.0 and to encode with mp3, vorbis and aac in libavcodec I had to use FLT format (even when codec said FLTP).
[22:07] <maister> Pulled from latest, and now I have to use FLTP, but audio is borked. When was this change made?
[22:10] <kierank> fltp = floating point planar
[22:11] <maister> Well, I'm using libavcodec directly, pasting console output is kinda hard :p
[22:11] <saste> maister, many codecs switched to produce planar output
[22:12] <saste> this simplified and optimized a few things, but the result is that you may need to convert the decoded samples layout
[22:12] <maister> I only encode
[22:12] <saste> one way to do it is to use libswresample (or hacking your special code for that)
[22:13] <saste> maister, that's the same, now some encoders only accepts planar formats (same reasons), so you need to convert *before* passing data to the encoder
[22:13] <maister> ye, thing is, in ffmpeg 1.0 libmp3lame for example supported planar only, FLTP, S16P etc
[22:14] <maister> However, if I used FLTP as format, it would fail, I had to use FLT, and actually use FLTP when encoding (avcodec_fill_audio_frame())
[22:14] <maister> for some strange reason.
[22:14] <michaelni> maister, AVCodec.sample_fmts if set lists the supported formats
[22:14] <maister> But it worked
[22:15] <maister> Now, with git pull, FLT doesn't work (guess it was fixed), but when I pass FLTP, and use avcodec_fill_audio_frame() with FLTP, the audio I get is borked :(
[22:16] <saste> maister, are you setting the right format in the encoder context?
[22:16] <maister> yes
[22:17] <kierank> are you setting the audio samples correctly
[22:17] <kierank> i use fltp for encoding and it works fine
[22:17] <kierank> from the api
[22:17] <maister> I set codec->sample_fmt = AV_SAMPLE_FMT_FLTP
[22:18] <maister> then I call avcodec_fill_audio_frame(frame, channels, codec->sample_fmt, buffer (this is in interleaved FLT, but I assume fill_audio_frame will fix this for me?), bytes, 1)
[22:19] <maister> It did in ffmpeg 1.0 at least
[22:19] <saste> maister, wrong assumption
[22:19] <maister> How come it worked in ffmpeg 1.0 though? Was the behavior changed?
[22:20] <saste> no, it was supporting packed and you was passing packed
[22:20] <saste> now it is not supporting packed and you're passing packed
[22:21] <maister> err... So you mean libmp3lame was supporting FLT, even when sample_fmts didn't say so?
[22:22] <maister> if that's the case that explains a thing or two
[22:23] <maister> Anyways, so, the buffer you pass to avcodec_fill_audio_frame()
[22:23] <maister> is a single pointer.
[22:23] <saste> maister, see commit 473b297f26b51a5d6bf4cd0126d950cc4b105bd7
[22:23] <maister> ok
[22:24] <maister> I see
[22:24] <maister> very strange that it worked before, but oh well
[22:24] <maister> So, how to use avcodec_fill_audio_frame() in that case?
[22:25] <maister> the 'buf' argument is a single pointer
[22:28] <maister> I have some packed float data I'd like to move into an AVFrame that I can pass to the FLTP encoder
[22:30] <saste> maister: you can't do that
[22:30] <saste> not directly
[22:30] <maister> So, how to pass data to a single pointer 'buf' then?
[22:33] <maister> I have to deinterleave it so that left and right buffer come after each other in memory?
[22:33] <saste> maister, did you look at the examples in doc/examples/
[22:34] <saste> and yes you need to provide the data in the same format expected by the encoder
[22:34] <maister> but that's the question, planar audio has multiple pointers
[22:34] <maister> but avcodec_fill_audio_frame only has a single pointer
[22:34] <maister> for your data
[22:35] <saste> maister: samples are always contained in a single buffer
[22:36] <saste> once you know the format, the number of samples, the alignment, and the number of channels you can always compute the pointers to the plane buffers
[22:36] <saste> so you pass a single buffer, and tell the utils how to interpret it
[22:36] <saste> note that nb_samples must be specified in AVFrame
[22:37] <maister> so, how is a FLTP frame laid out? LLLLLLLLRRRRRRR ?
[22:38] <saste> LLLLLL[PADDING]RRRRR....[PADDING]
[22:38] <saste> padding depends on the alignment
[22:38] <maister> If alignment is 1
[22:38] <maister> It's packed?
[22:38] <saste> or you can use a converter
[22:42] <maister> Is there some way to "planarize" easily with the API?
[22:46] <saste> maister: libswresample, check doc/examples/
[22:47] <cone-616> ffmpeg.git 03Stefano Sabatini 07f494647206c2: lavu/opt: change the way ranges are printed
[22:54] <maister> hm, using libswresample for that seems a bit overkill, guess I just planarize it myself.
[23:21] <maister> Ok, figured it out. Planarized it myself and now it works again.
[00:00] --- Sun Dec  9 2012