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

[burek]

[02:03] <Compn> adobe source code leaked? hmmm
[02:04] <Compn> http://techcrunch.com/2013/10/03/adobe-gets-hacked-product-source-code-and-data-for-2-9m-customers-likely-accessed/
[02:24] <vigneshv> i'm trying to build a static binary with libopus in it. i built libopus with --enable-static --disable-shared and have the resulting includes and libs in a separate directory. how do i tell ffmpeg's configure to look for libopus in that directory? i tried CFLAGS and it didn't work. any pointers really appreciated?
[03:34] Action: Compn wonders if anyone ever worked on an updated binary codec loader in another project
[08:03] <cone-320> ffmpeg.git 03Clément BSsch 07master:41fd6f07961b: avcodec/dvdsubdec: factor out rectangles reset.
[08:03] <cone-320> ffmpeg.git 03Clément BSsch 07master:71e0ae22aca7: avcodec/dvdsubdec: extract every subtitle in a different file (debug).
[08:03] <cone-320> ffmpeg.git 03Clément BSsch 07master:95cafeb684d7: avcodec/dvdsubdec: reconstruct incomplete SPU packets.
[08:03] <cone-320> ffmpeg.git 03Clément BSsch 07master:dbfe61100bd7: avformat/vobsub: fix several issues.
[08:04] <ubitux> wm4: i'll backport this eventually later, but there are large changes and i got no review, so i'd like to have a little testing time space first
[09:37] <cone-320> ffmpeg.git 03Clément BSsch 07master:d4dc67345516: avformat/vobsub: raise packet even if apparently incomplete.
[10:06] <burek> i'm trying to understand this answer http://superuser.com/questions/536001/variable-bit-rates-with-vb-and-minrate-maxrate-settings-in-ffmpeg in order to write an article on our wiki, about a proper usage of -minrate, -maxrate and -bufsize... one thing is not very clear to me and i would appreciate if any of you would have a moment to comment on this.. the thing i dont understand is this: "You typically only use this for streaming, since the technique 
[10:06] <burek> how does the "underflow" make sense in this scenario?
[10:07] <burek> or was that a typo and he meant "overflow" ?
[10:16] <TimNich> I think underflow was meant.  You do not watn to get into the situation where the max bitrate is so high that in the time it takes to stream a high bitrate section, the buffer has emptied itself, so the decoder stalls waiting for more data. Its a balance between the buffer size, the max bit rate, and the expected streaming rate, (i.e your target bit rate).
[10:19] <burek> oh, I think I understand now.. thanks :)
[10:42] <saste> michaelni_, what about an AV_OPT_TYPE_CH_LAYOUT to use in swr?
[10:43] <saste> this would break syntax, OTOH having to specify an int64 to code for a channel layout is not very handy
[10:48] <michaelni_> why would it break synatx ?
[10:54] <saste> michaelni_, right now if you want to specify a channel layout with aresample, you need to set the int64 coding for that channel layout
[10:55] <saste> if we change swr options to support channel layout symbolic names, it will not recognize the integers
[10:58] <michaelni_> i dont see why you cant support both ways to specify a channel layout
[10:59] <saste> michaelni_, see av_get_channel_layout()
[11:21] <cone-320> ffmpeg.git 03Michael Niedermayer 07master:02a6ee51685e: avfilter/vf_frei0r: fix out of array read
[11:24] <michaelni_> saste, interpreting 5 and 0x5 differently does not seem like a good idea to me
[11:28] <cone-320> ffmpeg.git 03Maxim Poliakovski 07master:6a5bfd4d49e7: atrac: Add missing av_cold
[11:28] <cone-320> ffmpeg.git 03Michael Niedermayer 07master:8378aae72935: Merge commit '6a5bfd4d49e7433f6de869ccfe682940dbca8740'
[11:30] <saste> michaelni_, that was settled much time ago
[11:31] <saste> i'm not against changing the syntax if developers agree
[11:33] <michaelni_> also AV_OPT_TYPE_CH_LAYOUT doesnt need to reproduce the av_get_channel_layout() syntax down to every detail if that causes API issues
[11:33] <michaelni_> they could differ and print a warning where there is ambiguosity
[11:34] <michaelni_> is anyone/ anything using the base 10 syntax for specifying "layouts" ?
[11:34] <saste> michaelni_, i'm against different parsers for different contexts
[11:34] <saste> michaelni_, i don't think so, but see the thread "[FFmpeg-user] aresample out_channel_layout values"
[11:35] <saste> people trying to use aresample to perform channel conversion
[11:35] <saste> that was previously done with aformat or aconvert, which both accept symbolic channel layout specs
[11:36] <saste> so in practice i don't think it will be a problem if we change swr
[11:36] <saste> not a big problem, as most users won't notice
[11:39] <cone-320> ffmpeg.git 03Diego Biurrun 07master:80fefbed6234: x86: cpu: Restore some explanatory comments removed in 7160bb7
[11:39] <cone-320> ffmpeg.git 03Michael Niedermayer 07master:1e678007800a: Merge commit '80fefbed623491b92fe59ead99225f99c0d0ca08'
[11:50] <michaelni_> iam not in favor of "layout" = "5" setting layout to a value different of 5, thats a quite unexpected thing for the API user
[11:51] <michaelni_> that is one who initializes things maybe with a snprintf("%d")
[11:51] <ubitux> note that such changes might affect usage of filters like pan
[11:51] <ubitux> where there is various mangled parsing of layouts etc
[11:51] <ubitux> dunno if it's relevant in that case
[11:53] <saste> so what about chaning the syntax?
[11:53] <saste> cl=5 means channel layout #5
[11:53] <saste> cl=5c means default with 5 channels
[11:53] <saste> we just force the optional "c" to specify the number of channels
[11:54] <saste> again this is a break in a different place
[11:54] <cone-320> ffmpeg.git 03Diego Biurrun 07master:47b6cfc2a033: avformat/output-example: Declare link dependency on libswscale in the Makefile
[11:54] <cone-320> ffmpeg.git 03Michael Niedermayer 07master:90e1fc8bec1b: Merge commit '47b6cfc2a0333fb24f074d27830bf35ae5007050'
[11:55] <ubitux> it seems libav is slightly moving to doc/examples
[11:57] <saste> ubitux, so we'll have more redundant examples
[11:57] <ubitux> dunno how they're going to nih this yet
[11:57] <ubitux> it seems it was triggered by an external proposing an example
[11:58] <saste> yeah i wonder if the guy is aware of ffmpeg/doc/examples
[11:58] <ubitux> likely not
[11:59] <saste> then he sorely misses google search skills (?)
[12:00] <saste> anyway having more examples could be useful
[12:00] <saste> but it's more maintainance work, given the speed of API changes
[12:06] <cone-320> ffmpeg.git 03Vittorio Giovara 07master:49fe9c05f97b: oggparsevorbis: K&R formatting cosmetics
[12:06] <cone-320> ffmpeg.git 03Michael Niedermayer 07master:f3968ab47ca8: Merge commit '49fe9c05f97bc2cfafd8fdcfea2f313d7c8e2c48'
[12:12] <ubitux> saste: if we're not even prepared to update our small api examples, the api is moving too fast
[12:19] <saste> http://ffmpeg.org/pipermail/ffmpeg-devel/2011-November/116494.html
[12:24] <xlinkz0> there might be a bug when using force_key_frames and avoid_negative_ts at the same time
[12:25] <xlinkz0> when not using avoid_negative_ts force_key_frames is accurate
[12:25] <xlinkz0> when using it, the keyframe ends up + or - 100ms from the target timestamp
[12:41] <saste> xlinkz0, as expected
[12:41] <saste> avoid_negative_ts is applied at the muxer level (it is a format option), which takes place *after* packets are processed by ffmpeg
[12:43] <xlinkz0> saste: on my tests i select the seek time very accurately close to the keyframe
[12:43] <xlinkz0> so close that even without avoid_negative_ts the cuts i make have a 0.00000 start time
[12:44] <xlinkz0> essentially i don't need avoid_negative_ts in this scenario, but even so there's a delay
[12:44] <xlinkz0> is this not a bug because it is 'unavoidable'?
[12:45] <saste> xlinkz0, why do you use negative_ts if you don't need it?
[12:45] <saste> and then complain that things don't work if you use it?
[12:45] <xlinkz0> what
[12:46] <xlinkz0> how is that relevant
[12:46] <xlinkz0> ok i'll test without cutting on a keyframe
[12:46] <xlinkz0> will it be a bug then?
[12:46] <saste> no
[12:46] <saste> i can't understand why do you mention avoid_negative_ts if it is not relevant
[12:47] <mateo`> hello there !
[12:47] <xlinkz0> it is relevant because with it force_key_frames isn't accurate
[12:47] <xlinkz0> i doubt that it is because i cut near a key-frame
[12:47] <mateo`> i would like to insert the mjpeg_parser before decoding a mjpeg frame, is there a way to do that ?
[12:47] <saste> force_key_frames can't be accurate if you don't have frames around the specified time
[12:48] <xlinkz0> i do have them
[12:48] <xlinkz0> how else would it be accurate without avoid_negative_ts? :|
[12:49] <xlinkz0> ok it might be a problem because i use avoid_negative_ts when transcoding which afaik is redundant
[12:49] <xlinkz0> but it still is a bug
[12:50] <saste> xlinkz0, i already explained
[12:50] <saste> the avoid_ts shift is applied after ffmpeg did its processing, when the packet is written to the output file
[12:51] <saste> the only solution is not to use avoid_negative_ts, for example using a suitable format
[12:51] <xlinkz0> if that is so then avoid_negative_ts shouldn't break force_key_frames when the file already doesn't have negative timestamps
[12:51] <saste> that's what i'd expect
[12:51] <xlinkz0> then it might be a bug
[12:51] <saste> might be
[12:52] <cone-320> ffmpeg.git 03Diego Biurrun 07master:b2bed9325dbd: cosmetics: Group .name and .long_name together in codec/format declarations
[12:52] <cone-320> ffmpeg.git 03Michael Niedermayer 07master:ee77140afab7: Merge commit 'b2bed9325dbd6be0da1d91ffed3f513c40274fd2'
[13:34] <cone-320> ffmpeg.git 03Clément BSsch 07master:b46f19100b08: cosmetics: group remaining .name and .long_name.
[13:34] Action: ubitux feels so useful...
[13:39] <ubitux> it's impressive the number of additional codecs we have
[13:48] <Compn> but you didnt give attribution to diego
[13:48] <Compn> ;P
[13:49] <Compn> at least partial
[13:49] <ubitux> why should I? oO
[13:49] <Compn> oh nevermind
[13:49] Action: Compn feels stupid
[13:49] <Compn> thought it was the same commit
[13:49] <Compn> didnt realize we had 60 more codecs :P
[13:49] <ubitux> actually i think we have something like 100+
[13:49] <ubitux> lemme check.
[13:51] Action: Compn brb afk
[13:52] <xlinkz0> is reading frames with av_read_frame as fast as ffmpeg -ss <timestamp> -i input ?
[13:52] <xlinkz0> without decoding
[13:52] <cone-320> ffmpeg.git 03Martin Storsjö 07master:a6b361325f2b: rtmpproto: Print the error code string if there's no description
[13:53] <cone-320> ffmpeg.git 03Michael Niedermayer 07master:373d15525d3d: Merge commit 'a6b361325f2bfc8d9d4e5f761d6c1a07b209c4fb'
[13:54] <ubitux> yeah well a bit less than 100
[13:54] <ubitux> http://lucy.pkh.me/diff/diff-codecs.html
[13:54] <ubitux> Compn ^
[13:54] <ubitux> i was mistaken with the filters i guess
[13:55] <saste> yes we have xface :)
[13:55] <ubitux> :D
[13:56] <saste> (and lot more subs codecs, and more fringe/special purpose codecs, and snow)
[13:56] <saste> sometimes having less is considered a feature
[13:58] <ubitux> http://i1.kym-cdn.com/photos/images/newsfeed/000/140/938/responsibility12%28alternate%29.png
[13:58] <ubitux> saste ^
[14:02] <burek> in the ffmpeg documentation, this example was described as "To set the video bitrate of the output file to 64 kbit/s" and the command line is: ffmpeg -i input.avi -b:v 64k -bufsize 64k output.avi
[14:02] <burek> is it missing the -maxrate ?
[14:13] <cone-320> ffmpeg.git 03Martin Storsjö 07master:4d6d70292e91: rtmpproto: Pass the 'live' parameter in the right unit
[14:13] <cone-320> ffmpeg.git 03Michael Niedermayer 07master:d32eec3359da: Merge commit '4d6d70292e91a7ef027824d731b6b6570ceabf2f'
[14:15] <xlinkz0> after i seek with av_seek_frame the frames i get with av_read_frame have a coded_picture_number starting at.. 0
[14:15] <Daemon404> ubitux, how new is the libav rev
[14:15] <xlinkz0> can i get the real coded_picture_number?
[14:15] <Daemon404> since libav sure does have a webp decoder
[14:15] <ubitux> it's today pull
[14:16] <ubitux> most likely a dup Daemon404 
[14:16] <ubitux> since we had it a while ago
[14:16] <Daemon404> heh
[14:16] <Daemon404> why would allcodecs.c have dpes
[14:17] <Daemon404> dupes*
[14:17] <Daemon404> its ordered
[14:17] <ubitux> mmh maybe the diff is not up-to-date (mis-uploaded?)
[14:17] <ubitux> lemme check
[14:18] <cone-320> ffmpeg.git 03Martin Storsjö 07master:72540e514cea: rtmpproto: Clear the flv allocation size on reallocp failures
[14:18] <cone-320> ffmpeg.git 03Michael Niedermayer 07master:205b6021358e: Merge commit '72540e514ceaaed8ecb97ed63637b2a2a4447ab8'
[14:18] <ubitux> Daemon404: ah, should be better now
[14:19] <ubitux> ah it seems we might be around 100 now
[14:24] <Paranoialmaniac> xlinkz0: there is no general way to get real codec_picture_number since container may have no index of each picture/frame
[14:24] <cone-320> ffmpeg.git 03Martin Storsjö 07master:24fee95321c1: rtmpproto: Move the flv header/trailer addition to append_flv_data
[14:24] <cone-320> ffmpeg.git 03Michael Niedermayer 07master:b8e44118b136: Merge commit '24fee95321c1463360ba7042d026dae021854360'
[14:24] <Daemon404> i see the vp9 decode went in
[14:25] <xlinkz0> Paranoialmaniac: i only need it to work on mp4, is it possible?
[14:25] <Paranoialmaniac> xlinkz0: so mp4 is possible but i don't know libavformat supports that
[14:26] <xlinkz0> do you know of any other mp4utilities that could do this?
[14:27] <Paranoialmaniac> why do you want coded_picture_numebr?
[14:27] <xlinkz0> to pass it to x264
[14:28] <Paranoialmaniac> l-smash project i manage can seek by picture number
[14:28] <xlinkz0> it's complicated, i need to use the x264 binary in a very specific use case
[14:28] <xlinkz0> i need to get picture number based on timestamp, can it do that?
[14:29] <Paranoialmaniac> no.
[14:29] <cone-320> ffmpeg.git 03Martin Storsjö 07master:8921e32f730c: rtmpproto: Readjust the end of the flv buffer if handle_metadata exited early
[14:29] <cone-320> ffmpeg.git 03Michael Niedermayer 07master:5bb3ef3b369a: Merge commit '8921e32f730c191543b84e61338bc9d549aa05a3'
[14:30] <Paranoialmaniac> since timestamp thing is complicated in mp4
[14:30] <Paranoialmaniac> pts != cts
[14:30] <xlinkz0> cts?
[14:30] <Paranoialmaniac> composition timestamp
[14:30] <xlinkz0> well, based on pts
[14:30] <Paranoialmaniac> this is a thing of media layer
[14:31] <Paranoialmaniac> pts is a thing of presentation, movie or track layer
[14:31] <xlinkz0> so there's no way to get frame number based on pts , atleast not in a very fast way?
[14:31] <xlinkz0> like < 50ms
[14:31] <xlinkz0> 100ms
[14:32] <Paranoialmaniac> to get frame based on pts, you need construct presentation timeline
[14:32] <Paranoialmaniac> from all edits
[14:32] <Paranoialmaniac> a frame can have multiple PTSs
[14:32] <Paranoialmaniac> because of edits
[14:33] <Paranoialmaniac> a frame can only one CTS
[14:33] <Paranoialmaniac> *can have only one CTS
[14:33] <xlinkz0> AVFrame has only dts and pts, you're telling me there's another thing, cts that ffmpeg doesn't expore in the api?
[14:33] <xlinkz0> s/expore/expose
[14:33] <Daemon404> ffmpeg doesnt handle edits at all
[14:34] <Paranoialmaniac> ffmpeg doesn't expose
[14:34] <Daemon404> more or less
[14:34] <Paranoialmaniac> so you cant seek by pts on mp4 by using ffmpeg
[14:34] <Paranoialmaniac> actually
[14:34] <xlinkz0> ok so is there any way faster than <100ms to find the frame number based on pts or not?
[14:36] <cone-320> ffmpeg.git 03Martin Storsjö 07master:cd818b3a5709: rtmpproto: Validate the embedded flv packet size before copying
[14:36] <cone-320> ffmpeg.git 03Michael Niedermayer 07master:74b2b0ed9fc3: Merge commit 'cd818b3a5709b9b08bd5901cb8863a8b61be265e'
[14:42] <cone-320> ffmpeg.git 03Diego Biurrun 07master:6cc133ec58b8: x86: fdct: Only build fdct code if encoders have been enabled
[14:42] <cone-320> ffmpeg.git 03Michael Niedermayer 07master:9d8e8495c9d7: Merge remote-tracking branch 'qatar/master'
[14:45] <Paranoialmaniac> coded_picture_number is AVFrame thing, and libavcodec resets it internally when flush_buffers. so there is no way to get coded_picture_number i think
[14:46] <xlinkz0> thanks
[15:04] <kierank> +
[15:13] <saste> blitz review
[15:21] <wm4> so what I see in "[FFmpeg-devel] [RFC] Change av_get_channel_layout() syntax" is that you're making the API more crap just to make the ffplay/ffmpeg tools more userfriendly
[15:21] <wm4> Daemon404: let me join you in your AVOption hate
[15:21] <Daemon404> welcome
[15:21] <Daemon404> to the club
[15:21] <Daemon404> \o/
[15:22] <ubitux> why do you assume it will be more crap?
[15:22] <Daemon404> wait what
[15:22] <Daemon404> /change/ its syntax
[15:22] <Daemon404> thats a massive no-no
[15:22] <Daemon404> api-wise
[15:22] <ubitux> that, ok
[15:22] <saste> Daemon404, how's that related to AVOptions API?
[15:22] <wm4> oh wait I was misreading this mail
[15:23] <wm4> I'll take back what I said
[15:23] <Daemon404> saste, i just read it now, ask wm4
[15:23] <Daemon404> saste, api synta should *not* be changed.
[15:23] <wm4> I was merging it with something else in my mind
[15:24] <saste> in a way or another, it's gonna suck
[15:24] <wm4> anyway, I'm really glad I didn't use the ffmpeg API helpers for channel layout stuff
[15:24] <Daemon404> saste, changing behavior of a function with the same name between versions is gonna piss downstream right the hell off
[15:24] <Daemon404> compat between diff ffmpeg versions is a massive pain as it is already
[15:24] <Daemon404> without overlappinng names
[15:25] <saste> but that's a feature no one is probably using
[15:25] <wm4> anyway, so what is the goal: "In order to switch to symbolic names, we need to switch to a new option type for channel layout,"
[15:25] <Daemon404> [14:25] <@saste> but that's a feature no one is probably using <- ................
[15:25] <saste> ch_layout=1234
[15:25] <Daemon404> really, that is not a good reason to rationalize such a terrble thing
[15:25] <saste> this means 1234 channels at the moment
[15:26] <Daemon404> it's an api, it exists, it is public
[15:26] <Daemon404> you *cannot* change its syntax
[15:26] <wm4> (whoever thought passing raw numeric masks via something user-facing was a good idea...)
[15:26] <saste> why, the API exists to be broken
[15:26] <saste> that's our API guideline in ff*av land
[15:27] <wm4> *beep* wrong attitude
[15:27] <Daemon404> .........
[15:27] <Daemon404> thats a shit attitude
[15:27] <Daemon404> and a terribe one for downstream
[15:27] <Daemon404> and shows absolutely no regard whatsoever for actual api users
[15:27] <saste> Daemon404, that's called (silly) humorism
[15:27] <Daemon404> saste, poe's law.
[15:28] <ubitux> saste: stop aggro mobs
[15:28] <ubitux> :(
[15:28] <wm4> here's a theory: most API suckage comes from low level APIs trying to satisfy the need of high level programs like ffplay/ffmpeg
[15:28] <j-b> theory or troll ? :D :D
[15:28] <wm4> so what you need to do is move ffmpeg and ffplay to a separate repo
[15:29] <wm4> and develop it separately
[15:29] <wm4> (ok, ffmpeg would collapse, oh well)
[15:29] <saste> what i am actually trying to accomplish is letting user to specify symbolic channel layout names
[15:30] <wm4> then fix ffplay and ffmpeg
[15:30] <saste> as opposed to, say aresample=out_cl=123456
[15:30] <wm4> what does this have to do with low level APIs
[15:30] <Daemon404> saste, my point was do not use the same function name
[15:30] <Daemon404> and yeah, changing behavior of low level apis to facilitate cli arguments
[15:30] <Daemon404> sounds batshit retarded
[15:30] <Daemon404> very very mplayer-like.
[15:31] <saste> Daemon404, that's probably doable, but it sucks in a different way, since I have to provide a separate parser
[15:31] <saste> (and probably make the actual parser compatible at the next bump)
[15:32] <wm4> not having proper API but AVOptions (even string based one) is really annoying
[15:33] <saste> wm4, i know that song, still it is what we have at the moment
[15:33] <saste> i won't redesign it from scratch, i already tried, and failed
[16:04] <durandal_1707> burek: where is irc log of 1st in this month?
[16:41] <cone-320> ffmpeg.git 03Stefano Sabatini 07master:719b4eef5db7: lavu/common: add warning to GET_UTF8 doxy
[16:41] <cone-320> ffmpeg.git 03Stefano Sabatini 07master:515e651f56e8: lavu/opt: fix doxy for av_opt_get* functions about return value
[16:44] <ubitux> wtf @ #3029
[16:44] <ubitux> i don't even.
[16:44] <ubitux> Priority: critical, ofc.
[16:54] <burek> durandal_1707, is it ok now?
[17:07] <saste> durandal_1707, why to change priority if the ticket was meaningless?
[17:08] <durandal_1707> because it is not critical
[17:09] <wm4> saste: shouldn't the new utf-8 function be inline?
[17:09] <wm4> as much as I dislike putting code in headers, it would probably be appropriate here
[17:09] <saste> wm4, whatever
[17:09] <wm4> because otherwise everyone will be like LOL USE THE MACRO INSTEAD FOR SPEED
[17:10] <saste> also I'm not sure I understand 7ba0c1b390a6ea67ca5e9cbade3005285b51b70f
[17:10] <saste> and the code probably needs more consistency checks, now that it's not speed critical
[17:12] <wm4> looks like 7ba0c1b390a6 checks the length bits as part of the loop or so
[17:13] <wm4> ideally, you'd have two functions
[17:13] <wm4> one for raw parsing, and one that does verification
[17:13] <wm4> e.g. checking for over-long sequences and invalid code points
[17:14] <Daemon404> .. eta until libaviconv?
[17:14] <Daemon404> or lib swiconv
[17:15] <wm4> nicolas is going to need it
[17:15] <wm4> libswchardet
[17:15] <durandal_1707> can you propose something more constructive?
[17:16] <Daemon404> wm4 has proposed plenty of constructive things to nicolas
[17:16] <Daemon404> but nicolas is having none of that.
[17:16] <Plorkyeran> I'd be all for libswchardet if it actually works
[17:16] <Plorkyeran> none of the current options work very well
[17:16] <wm4> Daemon404: again, what nicolas wants with subtitles should be ffmpeg.c/ffplay.c's problems, not libavformats
[17:17] <wm4> there's no standard lib for Mozilla's code either
[17:18] <Daemon404> even if there was, it would be "mozilla-style"
[17:18] <Daemon404> ever tried to use NSS? :V
[17:20] <durandal_1707> Daemon404: what happened with that lavfi deadlock?
[17:21] <Daemon404> durandal_1707, still being looked into
[17:21] <Daemon404> it happens in libav-origin code
[17:21] <Daemon404> i thin
[17:21] <Daemon404> k
[17:23] <durandal_1707> i would like to have that fixed
[17:23] <ubitux> "it's still locked! i'm waiting"
[17:23] <Daemon404> durandal_1707, then learn some patience
[17:24] <Daemon404> race conditions arent exactly easy or fun to debg
[17:24] <Daemon404> debug*
[17:24] <Daemon404> especially when helgrind shows nothing
[17:24] <ubitux> there is also a tsan instance
[17:24] <ubitux> which doesn't give much more insight i know
[17:25] <Daemon404> ubitux, right now im trying to et it to occur on debug builds
[17:25] <Daemon404> so i can get some useful info
[17:32] <Daemon404> ubitux, btw its such a pain that you cant specify the # of threads in lavfi
[17:32] <Daemon404> from cli
[17:33] <ubitux> why do you tell me this?
[17:33] <ubitux> i almost never worked on threading
[17:33] <Daemon404> s/ubitux, //
[17:33] <durandal_1707> it pains me too
[17:33] <ubitux> ...and i think you actually can
[17:33] <Daemon404> nope
[17:33] <Daemon404> you cannot
[17:33] <ubitux> don't we have a threads option at lavfi level?
[17:34] <Daemon404> it is not exposed via ffmpeg cli
[17:34] <durandal_1707> also i do not like how timeline is done
[17:35] <durandal_1707> it allows it only for codecs that have some option to set
[17:36] <durandal_1707> burek: much better
[17:41] <ubitux> durandal_1707: huh?
[17:41] <ubitux> didn't understand the codecs/lavfi-timeline thing
[17:53] <durandal_1707> you can add timeline to vflip/hflip
[17:53] <durandal_1707> *can not
[17:54] <durandal_1707> i told you this ages ago
[17:54] <cone-320> ffmpeg.git 03Michael Niedermayer 07master:e41ea866fc26: avformat/mov: force parsing of headers if stts is absent
[17:55] <ubitux> ah
[18:51] <cone-320> ffmpeg.git 03Paul B Mahol 07master:a2c14ba2b19c: avfilter/vf_histogram: use const for variables that are not supposed to change
[18:52] <ubitux> BBB: i'm back on vp9, but working on the asm for now
[18:55] <durandal_1707> how nice, when you finish, i expect you will write asm for lavfi
[18:55] <ubitux> i'd like to
[18:56] <ubitux> but unfortunately a lot of things need reshaping first...
[19:27] <Compn> so , twitter stock, buy or not ?
[19:53] <ubitux> sounds like the config.d project is going to be an epic fail...
[19:55] <durandal_1707> ?
[19:56] <ubitux> durandal_1707: they're going to scatter configure all around in an attempt to make it usable by other projects
[19:56] <ubitux> but unless that system is taking out of the repository, no one will use it (unless they copy more or less up-to-date versions of it in their project)
[19:57] <ubitux> so i'm guessing this is going to be either moved out of the project as a dependency
[19:57] <ubitux> or copied and get unsync like it was for libpostproc
[19:57] <ubitux> desync*
[19:58] <ubitux> if that "succeed" we're going to have some more packaging clashes between ffmpeg and libav
[19:58] <durandal_1707> why?
[19:58] <ubitux> if that fails, which is likely, we're just going to have a desync vapourware, and the configure exploded in multiple files
[19:58] <ubitux> durandal_1707: because libav's configure doesn't support c++ for instance, to take one of the many examples
[19:59] <ubitux> basically the two config.d won't work together
[20:03] <durandal_1707> perhaps libav wants to compete with cmake/automake/and others?
[20:03] <ubitux> yes sure that's the goal
[20:03] <ubitux> which is honorable TBH
[20:04] <ubitux> it just won't happen without a lot of troubles
[20:04] <ubitux> durandal_1707: are you using vim?
[20:05] <durandal_1707> yes?
[20:05] <ubitux> k, just curious
[20:06] <Compn> going to make the configure be ... the next autoconf ?
[20:08] <durandal_1707> ubitux: it have blockwise visual-mode
[20:08] <ubitux> durandal_1707: how do you deal with \ macro align btw?
[20:08] <ubitux> durandal_1707: yes, ^v is really cool
[20:09] <durandal_1707> manual work, there sure are plugins but :effort
[20:09] <ubitux> k, i was wondering, because i do the same
[20:30] <durandal_1707> why you hate non-anonymous structs?
[20:31] <ubitux> because the name appears two times for no benefit
[20:32] <durandal_1707> its needed for function i added in struct
[20:32] <durandal_1707> without it clang gives warnings
[20:32] <ubitux> ah, ok in that case
[20:32] <ubitux> missed the func ptr, my bad
[20:35] <ubitux> durandal_1707: about fate i was wondering if you tried with a aformat=s16 etc
[20:35] <durandal_1707> yes, but due rounding it may be different....
[20:36] <ubitux> durandal_1707: as long as the results are mostly accurate it's good enough
[20:36] <durandal_1707> for 0.1 and s16 samples all sample formats (s16/s32/flt/dbl) output is same
[20:37] <durandal_1707> the idea is to add silence removal filter
[20:37] <durandal_1707> its shame ffmpeg doesn't have one, and one need to use sox one
[21:48] <ubitux> writing simd really feels like playing tetris, with a time dimension
[21:48] <ubitux> trying to rearrange the game all over again according to the mess of pieces
[21:50] <durandal_1707> one really slow tetris game
[21:50] <ubitux> :)
[22:27] <teratorn> anything like the testsrc avfilter except for audio?
[22:29] <ubitux> aevalsrc
[22:29] <durandal_1707> teratorn: see http://ffmpeg.org/ffmpeg-filters.html#Audio-Sources
[22:29] <teratorn> thank you kind sirs
[22:30] <ubitux> ./ffplay -f lavfi "aevalsrc='sin(440*2*PI*t)*exp(-4*mod(t,1))'" 
[22:31] <durandal_1707> can't do simple tone?
[23:39] <cone-451> ffmpeg.git 03Lukasz Marek 07master:b611ea041de6: lavd/pulse: add MAINTAINERS entry
[23:39] <cone-451> ffmpeg.git 03Michael Niedermayer 07master:e1f8184a1a97: avformat/gifdec: make GIF_APP_EXT_LABEL parsing more robust
[00:00] --- Sat Oct  5 2013