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

[burek]

[00:05] <saste> J_Darnley, no
[00:05] <saste> init -> query_formats -> configure links
[00:06] <J_Darnley> Yeah, I thought so.  Thanks
[00:08] <saste> well documentation page starts to look nice
[00:09] <J_Darnley> Perhaps I should consider looking at them now
[00:09] <saste> now we need someone to do some web design
[00:09] <ubitux> saste: gonna push documentation patchset & overlay?
[00:10] <saste> documentation patchset -> already in
[00:10] <saste> just missing the final patch
[00:10] <saste> overlay: i want to review nicholas patch before
[00:10] <saste> then i don't want if i'll be still awake
[00:10] <ubitux> i think he did
[00:11] <saste> he did what?
[00:11] <ubitux> review overlay
[00:11] <saste> and now i have to review his patches!
[00:11] <ubitux> oh, ok
[00:13] <saste> michaelni, you ok with latest nicolas patchset?
[00:13] <saste> i ask because I see there was a long thread about audio/channel layout with you and nicolas
[00:14] <michaelni> saste, i only object to channel layout being set to some fake layout 
[00:15] <michaelni> that is layout should be 0 or the correct layout
[00:15] <saste> seems correct
[00:15] <saste> well i'm going to review it now
[00:21] <ubitux> saste: fyi, i have this queued in my local tree: http://pastie.org/5554987#10 on top of the concat patch
[00:21] <ubitux> so don't worry about fixing such links, unless i missed some
[00:21] <saste> ah ok
[00:22] <saste> i wonder if an ffmpeg-faq.1 manual would be useful
[00:22] <saste> but we would lose the nice links unfortunately
[00:22] <saste> so better to keep things as they are
[00:23] <saste> i'd like to switch to a more powerful system soon or later
[00:23] <saste> so we can do texi <-> wiki and other funny things
[00:25] <wm4> why does AVFrame.extended_data exist?
[00:25] <ubitux> to avoid breaking binary compat with a limited sized data[8] i guess
[00:25] <ubitux> (for audio with 8+ channels)
[00:25] <wm4> but didn't adding "extended_data" break ABI anyway?
[00:26] <ubitux> because it was added at the end maybe
[00:26] <wm4> and why is AV_NUM_DATA_POINTERS 8 and not 4? (you'd have 4 if you designed it for image data only)
[00:27] <ubitux> maybe there was a "8 channels will be enough for everyone" step
[00:27] <ubitux> dunno
[00:28] Action: wm4 facepalms
[00:28] <ubitux> i really don't know :)
[00:30] <saste> wm4: extended data is good if you have more than 8 channels
[00:30] <saste> why should it break compatibility?
[00:30] <saste> AV_NUM_DATA_POINTERS -> who committed that?
[00:30] <wm4> why not set AV_NUM_DATA_POINTERS to the max. channel count in the first place?
[00:30] <saste> max channel count?
[00:31] <saste> i suppose that could be 64 or even more for funny audio equipment
[00:31] <saste> also *that* would have broken ABI compatibility
[00:31] <wm4> 560f773c7 (Justin Ruggles                 2011-11-14 16:07:03 -0500 1082) #defin
[00:31] <wm4> e AV_NUM_DATA_POINTERS 8
[00:31] <wm4> well, the plan using the same data structures for audio and video sure worked out fine, lol
[00:32] <wm4> so you have to do something magically different if you want more than 8 channels
[00:32] <wm4> while below 8 channels, you'll never be aware of the difference
[00:33] <ubitux> oh shit i was right for the 8ch?
[00:33] <saste> wm4, you should be aware of the difference
[00:33] <saste> is extended_data allocated in case channels <= 8?
[00:34] <wm4> how often do people test with > 8 channels? this invites creating bugs
[00:34] <wm4> nice API
[00:34] <saste> wm4, ask libav, we only merge stuff
[00:34] <ubitux> yep
[00:34] <ubitux> we are not doing any important work here
[00:37] <saste> wm4: Both data and extended_data will always be set by get_buffer()
[00:38] <saste> basically that means that you can always access extended_data for audio and be safe
[00:38] <wm4> then why is data set for audio at all?
[00:38] <saste> even if i wonder what's the gain of having 8 elements in data
[00:38] <wm4> it would be actually _simpler_ if it weren't
[00:38] <saste> wm4: i guess backward compatibility or some mess like that
[00:39] <saste> you're free not to use it I guess
[00:39] <michaelni> extended_data is always safe, unless it points to data (which it does most of the time) and you copy the struct (happens) in that case it then points to the previous struct and will crash eventually
[00:39] <michaelni> that is AVFrame.extended_data = &AVFrame.data
[00:42] <saste> what was the reason for using data for audio? maybe a performance reason (no alloc in case channels <= 8)?
[00:43] <wm4> lol
[00:43] <wm4> as if that'd matter
[00:44] <saste> wm4: but really should ask libav, or read the logs or the (unexistent) IRC libav logs where they do most design discussion
[00:44] <ubitux> yeah, or ask ruggles directly
[00:44] <saste> unexistent -> i think they are not public
[01:03] <Compn> saste : careful, we've been accused of complaining about libav too much :P
[01:04] <saste> Compn, I propose to state the rule that we should provide ten patches every time libav is mentioned
[01:04] <saste> doc and web patches count as well, so you're not exempted
[01:07] <ubitux> would be nice if someone could re-read all the doc and check for outdated/incomplete/wrong/whatever info
[01:09] <wm4> for starters, remove almost all links from the doc main page
[01:11] <saste> wm4, why?
[01:12] <wm4> because most linked pages are outdated and misleading?
[01:12] <saste> wm4: where, what doc main page?
[01:12] <saste> and our ffserver manual is pretty funny
[01:13] <wm4> yes, for example consider these: http://wiki.multimedia.cx/index.php?title=FFmpeg_filter_HOWTO http://www.inb.uni-luebeck.de/~boehme/using_libavcodec.html
[01:13] <saste> wm4: yes, and patches welcome
[01:13] <wm4> it's your own mess, take care of it
[01:13] <wm4> (this should be a generic response to "patches welcome")
[01:13] <saste> wm4, it's also your own mess, if you use it
[01:14] <wm4> is that what you tell to your users?
[01:14] <wm4> "your fault for reading the docs"
[01:16] <saste> wm4: this a mostly volunteer based project, if your an user it is also in your interest to clean it up
[01:16] <saste> and we lack the manpower to do everything
[01:19] <cone-267> ffmpeg.git 03Clément BSsch 07master:521a963a7d72: doc/faq: improve concatenation entry.
[01:19] <cone-267> ffmpeg.git 03Clément BSsch 07master:52b866471ec9: doc/faq: move filter links to the ffmpeg-filters.html page.
[01:22] <ubitux> saste: your documentation work is starting to look pretty good
[01:22] <Compn> saste  / ubitux : sounds like a good project to hire an outside person with programming skills to review all docs
[01:23] <ubitux> :)
[01:23] <saste> Compn, do you have experience with crowd-funding?
[01:23] <ubitux> would be nice to have some more eval examples
[01:23] <Compn> saste : how much we got in SPI ?
[01:24] <saste> Compn: around 500$ last time I checked
[01:24] <saste> less processing fees
[01:24] <Compn> i'm currently trying a indiegogo thing, seems to work ok so far
[01:24] <Compn> paypal and credit cards accepted
[01:24] <saste> there are a bunch of things we could improve to raise some funds
[01:24] <Compn> obv not non-profit
[01:24] <saste> T-shirt, mugs comes to mind
[01:25] <Compn> saste : could always ask libav for some money...
[01:25] <saste> eheh, yes so we can fund mergework
[01:26] <durandal_1707> ask != get
[01:26] <saste> i'll have possibly some time starting from february, i could create some ffmpeg-related tasks on a crowd-funding service
[01:27] <saste> another idea could be to create a task for funding bug fixing (bug fixed = 100$ or something like that)
[01:27] <Compn> nice idea :)
[01:27] <saste> and we could send nice t-shirts with the ffmpeg logo around the world
[01:28] <ubitux> saste: i think it would be appropriate to somehow link to vf scale in the ffmpeg-scaler
[01:28] <ubitux> and aresample in the ffmpeg-resampling doc
[01:30] <ubitux> also, it could be nice to have a left "frame" for the index in the documentations :p
[01:30] <saste> ubitux: yes
[01:30] <saste> about the left frame, that's something related to CSS layout
[01:30] <ubitux> yes
[01:30] <saste> we should really improve the current one, which is starting to look pretty outdated
[01:31] <ubitux> it's always a bit tricky since the server css is not in sync with what's on the repo
[01:33] <saste> ubitux, we should add the CSS to the repo, and rely on that for both internal docs and web CSS
[01:33] <saste> at least this is a possibility
[01:33] <ubitux> i'm not sys/web admin on the server
[01:34] <ubitux> (and don't want to)
[01:34] <saste> CSS is fun
[01:34] <saste> maybe i'll work in that direction around the XMAS period
[01:34] <ubitux> :)
[01:36] <saste> i got a chinese mail in reply to my web patch...
[01:37] <saste> FFmpeg on Mac OS X HOWTO
[01:37] <saste> this should be moved to the wiki
[01:38] <saste> there's no point having it in the main page
[01:39] <ubitux> it can be removed
[01:39] <ubitux> it's still referencing ffmpeg svn&......
[01:39] <ubitux> oups dots attack
[02:07] <ubitux> j-b: op1a issue reproducible with ffmpeg?
[02:07] <j-b> I think so, of course.
[02:07] <ubitux> is there a bug somewhere?
[02:08] <j-b> https://ffmpeg.org/trac/ffmpeg/ticket/2029 
[02:08] <j-b> I would say
[02:08] <ubitux> Tjoppen: was that pushed?
[02:09] <j-b> http://streams.videolan.org/incoming/Archive.zip for VLC bugreport
[02:09] <ubitux> j-b: if it affects libav it might not be this one
[02:09] <j-b> I don't know. My users complain, they don't say which one they use :)
[02:09] <j-b> stupid users, change users.
[02:10] <durandal_1707> they report vlc issue or?
[02:10] <j-b> they report: 'it does not work'
[02:11] <durandal_1707> with vlc?
[02:11] <cbsrobot> the patch Tjoppen sent breaks fate
[02:11] <j-b> ok
[02:12] <cbsrobot> a few days ago he said he'll work on it
[02:14] <ubitux> j-b: your sample seems to work fine with ffplay 
[02:14] <ubitux> what's the issue?
[02:14] <j-b> then probably too old ffmpeg lib for my moronic user
[02:14] <ubitux> it doesn't with avplay though
[02:14] <ubitux> video is laggy
[02:15] <cbsrobot> the only issue I saw was the duration and bitrate
[02:15] <cbsrobot> laggy video is normal for j2k
[02:16] <ubitux> i mean it looks like half frame rate
[02:16] <ubitux> while it's ok with ffplay
[02:18] <j-b> did I mention I hate mxf?
[02:24] <ubitux> :)
[02:24] <durandal_1707> j-b: why you hate your users so much?
[02:24] <j-b> durandal_1707: I don't, but some are Uber annoying
[02:25] <j-b> like mailing us every day
[02:26] <ubitux> <@j-b> I don't know. My users complain, they don't say which one they use :) // can't you print the libav* version used in the default output? 
[02:26] <ubitux> mplayer does this, that's pretty handy
[02:26] <ubitux> (what is it compiled against, and what version is ran)
[02:26] <j-b> good idea
[02:28] <ubitux> mplayer2/mpv shows up the mismatching versions between built & runtime
[02:28] <ubitux> not sure about mplayer, since it's static only
[02:42] <cone-267> ffmpeg.git 03Anton Khirnov 07master:77bd1bc73a19: avconv: use new options parser.
[02:42] <cone-267> ffmpeg.git 03Michael Niedermayer 07master:af4b1c02acf6: Merge commit '77bd1bc73a1946b0f0ce09a7cbb242a65e138d06'
[02:42] <cone-267> ffmpeg.git 03Michael Niedermayer 07master:ba4bcb191aa8: cmdutils: implement debug/fdebug log level update differently.
[02:49] <durandal_1707> michaelni: what could case framemd5 duration column to be 5 for demuxer and 1 for decoder:
[02:49] <durandal_1707> 0,          0,          0,       15,     1457, dd3900d55110e5cf53324bfd05858c97
[02:49] <durandal_1707> vs
[02:50] <durandal_1707> 0,          0,          0,        1,    10920, 8dfacbffbea503d713db1edf44ffdd4f
[02:51] <cone-267> ffmpeg.git 03Anton Khirnov 07master:e82cb79adf3b: avconv: pass the actually selected decoder to filter_codec_opts().
[02:51] <cone-267> ffmpeg.git 03Janne Grunau 07master:acb571c89a06: avcodec: bump minor for adaptive h264 frame-mt
[02:51] <cone-267> ffmpeg.git 03Michael Niedermayer 07master:1667152a9c1a: Merge commit 'acb571c89a065d943163c11efb46de35774f1909'
[02:55] <cone-267> ffmpeg.git 03Ronald S. Bultje 07master:a34d9ad96974: lavc: merge latest x86inc.asm fixes with x264
[02:55] <cone-267> ffmpeg.git 03Janne Grunau 07master:45635885e44c: mpegvideo: increase edge_emu_buffer size for VC1
[02:55] <cone-267> ffmpeg.git 03Michael Niedermayer 07master:7e90053822f4: Merge remote-tracking branch 'qatar/master'
[02:58] <michaelni> durandal_1707, is the timebase the same ?
[03:03] <durandal_1707> isn't timebase set only in demuxer
[03:03] <durandal_1707> then it should be same
[03:12] <durandal_1707> michaelni: with -c copy i get 3.67 fps and without i lost that info
[03:14] <michaelni> framecrc prints the timebase like "#tb 0: 1/25"
[03:15] <michaelni> if it matches then i dunno why durations differ ... would need to be debuged
[03:21] <ubitux> i just added & updated some fate instances, which might fail because of fate dependencies
[03:21] <ubitux> do not believe the failure are regressions
[03:22] <durandal_1707> michaelni: there are only 2 frames
[03:50] <cone-267> ffmpeg.git 03Clément BSsch 07master:e5e5664ca002: fate: add and fix subtitles dependencies.
[03:55] <cone-267> ffmpeg.git 03Clément BSsch 07master:53fa6f58632e: doc/general: sort subtitles formats.
[04:09] <ubitux> what is the error?
[04:10] <ubitux> i see only warnings
[04:16] <cone-267> ffmpeg.git 03Michael Niedermayer 07master:73db0bf1b060: mpegvideo: increase scratchpad sizes
[04:22] <michaelni> ubitux, maybe its the warnings, moment ill fix em
[04:25] <wm4> so, mpeg video doesn't seem to set DR1 buffer hints, and you can't know whether the frame is going to be reused... disappointing
[04:26] <cone-267> ffmpeg.git 03Michael Niedermayer 07master:a46c565796d9: ffmpeg_opt: fix pointer types
[04:26] <cone-267> ffmpeg.git 03Michael Niedermayer 07master:8525fa7c2c34: h264: remove unused variable
[04:26] <michaelni> wm4, mpeg doesnt reuse buffers
[04:27] <michaelni> all that do reuse should set hints ideally
[04:27] <wm4> if I just write into an output frame decoded by h264, it seems to cause corruption
[04:28] <wm4> maybe I did something wrong, but then ffplay's lavfi code always sets AV_PERM_PRESERVE too
[04:33] <michaelni> h264 uses the frames as references but does not reuse them in the sense of reget_buffer()
[04:33] <michaelni> see AVFrame.reference
[04:37] <wm4> michaelni: couldn't it set buffer hints from AVFrame.reference then?
[04:41] <michaelni> i see no reason ATM why that wouldnt be possible
[04:42] <wm4> if I try to use AVFrame.reference manually (after decoding), it doesn't seem to work
[04:43] <wm4> using something like: if AVFrame.reference==0, the data is writeable
[04:43] <wm4> oh nevermind
[04:43] <wm4> inverted condition... so it seems to work
[05:14] <cone-267> ffmpeg.git 03James Almer 07master:974ac57e83f3: astenc: Remove two AVRationals with denominator 1
[05:17] <cone-267> ffmpeg.git 03Clément BSsch 07master:174c483e2e75: lavfi/select: fix compilation with avcodec disabled.
[05:20] <ubitux> strange, i tested compilation without it&
[05:23] <ubitux> huh, --disable-devices doesn't disable indevs
[05:23] <ubitux> so the avdevice can be 0 and indevs can be set to 1
[05:23] <ubitux> oO
[10:51] <durandal_1707> microchip_: why is in24 tag same for both be and le in isom.c ?
[10:51] <durandal_1707> michaelni: ^
[11:00] <durandal_1707> michaelni: aiff tags table is pointlessly duplicated in muxer and demuxer
[11:55] <saste> wbs: what's hlsenc good for?
[11:55] <saste> i mean with respect to the segment muxer
[11:56] <saste> also the logic for setting the filename is bugged
[11:58] <michaelni> durandal_1707, in24 uses enda tag to handle endianness
[12:00] <durandal_1707> michaelni: good to know
[12:03] <cone-202> ffmpeg.git 03Michael Niedermayer 07release/1.0:97ec20a20ade: mov: fix time types related to mov_metadata_creation_time
[12:09] <wm4> the pixel format change thing crashes ffplay
[12:10] <durandal_1707> for h264?
[12:10] <wm4> durandal_1707: yes, tried your sample (pixfmtchange.mpg)
[12:11] <wm4> maybe it even crashes inside the decoder...
[12:11] <durandal_1707> but it worked before
[12:11] <durandal_1707> wm4: are you using latest ff version?
[12:12] <cone-202> ffmpeg.git 03Victor Lopez 07master:1c8bf3bfed5f: h264: fix sps parsing for SVC and CAVLC 4:4:4 Intra profiles
[12:12] <cone-202> ffmpeg.git 03Janne Grunau 07master:bb2bab92e737: mov: handle h263 and flv1 for codec_tag 'H','2','6','3'
[12:12] <cone-202> ffmpeg.git 03Anton Khirnov 07master:c661cb6672af: cmdutils: pass number of groups to split_commandline().
[12:12] <cone-202> ffmpeg.git 03Michael Niedermayer 07master:40ea3438661e: Merge commit 'c661cb6672af5ebcb900ec8766b24761bd2ab011'
[12:12] <wm4> durandal_1707: tried with 174c483e2e751c71
[12:12] <durandal_1707> michaelni: did you actually tested mt pix_fmt change?
[12:12] <michaelni> durandal_1707, yes
[12:13] <michaelni> but only with ffmpeg not ffplay
[12:15] <michaelni> where can i find pixfmtchange.mpg ?
[12:16] <wm4> I got it from durandal_1707
[12:17] <wm4> even crashes with -threads 1
[12:20] <michaelni> ffmpeg too or just ffplay ?
[12:20] <wm4> ffplay
[12:21] <wm4> ffmpeg crashes too, even with -threads 1
[12:24] <cone-202> ffmpeg.git 03Anton Khirnov 07master:582368626188: mpeg12: do not decode extradata more than once.
[12:24] <cone-202> ffmpeg.git 03Justin Ruggles 07master:b2fe6756e34d: lavr: add option for dithering during sample format conversion to s16
[12:24] <cone-202> ffmpeg.git 03Michael Niedermayer 07master:41135b7f64e6: Merge remote-tracking branch 'qatar/master'
[12:26] <michaelni> posted a patch for ffplay + h264-mt resolution changes, maybe it fixes pixfmt too
[12:28] <wm4> michaelni: posted a patch where?
[12:28] <durandal11707> wm4: i dont have that file anymore
[12:29] <wm4> then, where can I upload it?
[12:29] <durandal11707> but!! it is trivial to create several files with different pix fmt and cat it
[12:29] <durandal11707> there are nice filters use them
[12:30] <michaelni> wm4 patch on ffmpeg-devel
[12:31] <michaelni> i dont need the file, already have my own
[12:33] <wm4> michaelni: does that mean AVCodecContext.width and height don't contain useful information anymore?
[12:34] <durandal11707> wm4: that is for codec only
[12:34] <durandal11707> and it can change per frame
[12:34] <durandal11707> so good idea is to use frame width/height/...
[12:35] <wm4> what do you mean by "for codec only"
[12:35] <durandal11707> that should be from the start (i really dislike how stuff are designed here)
[12:36] <durandal11707> wm4: codec context, use internaly for decoder/encoder
[12:36] <durandal11707> there is only one context, not bunch of them when something changes
[12:36] <wm4> ok
[12:37] <wm4> what is AVCodecContext.coded_frame?
[12:38] <durandal11707> something bad
[12:38] <wm4> xD
[12:38] <durandal11707> comment says picture in bitstream
[12:40] <durandal11707> wm4: i think you are mostly interested in frames returned by decoder
[12:42] <wm4> same fields are in AVCodecContext only, like colorspace
[12:43] <durandal11707> argh, as i said bad design
[12:55] <wm4> michaelni: ffmpeg still crashes
[12:55] <michaelni> wm4 ill commit a fix in a moment
[12:57] <cone-202> ffmpeg.git 03Michael Niedermayer 07master:a9275b4f6938: h264: Fix code to also handle pix format changes.
[13:00] <wm4> thanks
[13:03] <saste> michaelni, don't we have a test for that?
[13:06] <michaelni> saste, pixfmt change in h264, mpeg2, ... no
[13:06] <michaelni> btw we need ffplay regression tests
[13:11] <cone-202> ffmpeg.git 03Nicolas George 07master:238edd2fe33d: lavfi: add a channels field to AVFilterLink.
[13:11] <cone-202> ffmpeg.git 03Nicolas George 07master:34de47aa35a3: lavfi: add an accessor for ref->audio->channels.
[13:11] <cone-202> ffmpeg.git 03Nicolas George 07master:5033a1af1711: lavfi/buffersrc: remove init of rate and layout.
[13:11] <cone-202> ffmpeg.git 03Nicolas George 07master:0146c1f0f173: lavfi: remove init and check of rate and layout.
[13:14] <wm4> why do all libav* have different version numbers? the separate version numbers are not very useful, and actually make staying compatible much harder
[13:24] <saste> wm4, they are different libraries, with different version numbers
[13:24] <Compn> wm4 : dont like backwards compatability huh
[13:25] <Compn> wm4 : you realize just about everyone wants point releases and api compatability
[13:25] <wm4> saste: that's a delusion
[13:25] <Compn> and people have asked for that for years
[13:25] <wm4> Compn: wat
[13:25] <Compn> distros too
[13:25] <wm4> Compn: I'm talking about libavformat, libavcodec etc. having different version numbers from each other
[13:26] <wm4> Compn: and this actually makes backwards compatibility much harder
[13:26] <Compn> those numbers are used to make sure they are compatable with each other
[13:26] <Compn> e.g. 50 will give some errors working with 52
[13:26] <wm4> and how would that stop working if all of these would use the same
[13:26] <iive> wm4: it is for the case where libraries are used separately
[13:27] <Compn> wm4 : i agree with you. its the distros that want this crap...
[13:27] <iive> so an api break in one library won't be treated as incompatibility in another.
[13:27] <saste> wm4, are you suggesting that we should bump all minor/major/micro numbers when i bump a filter micro?
[13:27] <cbsrobot> next release will be 1.1 ?
[13:28] <wm4> saste: yes (whether you do it by hand or whether there's an automagic mechanism to do this is another question)
[13:28] <wm4> saste: well, you'd bump the other micros only, obviously
[13:28] <saste> wm4, no automagic since you need an human brain to decide if there is a compatibility break
[13:30] <wm4> micro bumps don't break compatibility, and actual compatibility breaks should be done in batches on releases/whatever, so it doesn't matter if you'd bump all libs
[13:30] <saste> wm4, did you look at our version.h files?
[13:30] <wm4> yes?
[13:31] <saste> backward compatibility is handled there
[13:31] <saste> but sometimes you add a symbol in libx, and make use of that feature in liby
[13:31] <saste> so you have that liby depends on libx version X
[13:32] <cbsrobot> burek: ^
[13:32] <wm4> saste: and?
[13:32] <saste> this is not easy to address, since the developer will hardly track when a certain library starts to use a certain feature in another library
[13:33] <saste> but the rule of thumb: you should use the libraries which come from the same revision number of the project
[13:33] <wm4> what's also a öain: library versions literally have nothing to do with release versions
[13:33] <wm4> *pain
[13:34] <saste> users usually install all the libraries from the same checkout, so that's a non problem
[13:34] <saste> but for distros (e.g. they decide they want to upgrade libavcodec, but don't update libavutil)
[13:34] <wm4> and why would you allow mismatching library versions? distroshit?
[13:34] <wm4> then slap them
[13:34] <saste> why bump it if there is no need?
[13:34] <wm4> and make libav* abort() if they mismatch
[13:35] <saste> we follow the philosophy: every library can be used independently from the others
[13:35] <saste> if we bump lavfi, why should we bump lavu as well?
[13:35] <wm4> then how do I use libavformat without libavcodec?
[13:35] <saste> you can use libavutil without using libavcodec
[13:35] <saste> or libavcodec without using libavformat
[13:36] <saste> or libavfilter standalone, depending only on lavu/lsws/lswr
[13:36] <wm4> and like I said: if breaking changes really come in batches, this won't matter anymore
[13:36] <wm4> there'll be some breaking changes in lavfi, but there'll be some in lavu
[13:41] <Compn> wm4 : this is how distros have worked , you want to change that, good luck.
[13:42] <Compn> send a mail to a mailing list and ask them to change
[13:42] <Compn> wont take you more than 30 seconds
[13:42] <Compn> debian-devel ?
[13:42] <wm4> debian doesn't package ffmpeg anymore
[13:43] <wm4> or was it ubuntu, or both
[13:43] <wm4> but if they would, you could just force them
[13:43] <wm4> abort() is a wonderful standard library function
[13:45] <durandal_1707> ?
[13:45] <wm4> durandal_1707: abort() if library versions mismatch
[13:46] <durandal_1707> send patch/fill bug/pay someone to do that/...
[13:49] <uau> rather uninformed discussion above...
[13:49] <uau> AFAIK distros updating libavcodec without updating libavutil is very rare; debian/ubuntu certainly do not do that (the libraries come from the same source package)
[13:50] <uau> however, you can not require the libraries to have matching versions unless you always bump the major version in each at the same time
[13:50] <uau> which has not been done so far
[13:51] <wm4> basically I'm advocating that there's only one version number
[13:51] <wm4> it could be just in libavutil
[13:53] <uau> requiring major version bumps in every library when only one actually changes API does have some drawbacks
[13:53] <wm4> like I said, batch the changes like you should
[13:53] <wm4> git has branches
[13:53] <uau> especially if you consider new/experimental libraries like recent libavfilter
[13:54] <uau> branches are no magic solution to that
[14:01] <cbsrobot> Tjoppen: ping
[14:27] <Tjoppen> cbsrobot: oh, right
[14:27] <Tjoppen> make fate-rsync && make fate   should be enough to reproduce, right?
[14:27] <cbsrobot> yes
[14:28] <cbsrobot> or make fate-rsync && make fate lavf-mxf_d10
[14:31] <Tjoppen> ugh, d10. better grab a coffee :)
[14:32] <Tjoppen> TEST    lavf-mxf_d10
[14:32] <Tjoppen> uh.. it works?
[14:32] Action: Tjoppen re-pulls
[14:36] <Tjoppen> make fate-lavf-mxf_d10  works fine with current master
[14:36] Action: Tjoppen runs "make -j4 fate"
[14:40] <Tjoppen> cbsrobot: works fine
[14:41] <Tjoppen> 64-bit Ubuntu
[14:41] <cbsrobot> I'll retry
[14:42] <Tjoppen> uh, wait.. perhaps that patch hasn't been pushed
[14:43] <Tjoppen> applied. fate-lavf-mxf_d10 still passes. running full FATE
[14:47] <Tjoppen> you meant seek-lavf-mxf_d10 :)
[14:49] <ubitux> valgrind is not happy
[14:49] <ubitux> http://fate.ffmpeg.org/report.cgi?time=20121220060251&slot=x86_64-archlinux-gcc-valgrindundef
[14:52] <cbsrobot> Tjoppen: I still have errors
[14:52] <Tjoppen> yeah, the d10 seek test fails
[14:52] <Tjoppen> probably because lolaes3
[15:11] <mateo`> Tjoppen: is there a regression on d10 seeking ?
[15:11] <ubitux> mateo`: https://ffmpeg.org/trac/ffmpeg/ticket/2029
[15:12] <Tjoppen> I see it now - when seeking on an audio stream the timestamp is naturally in SampleRate unots
[15:12] <Tjoppen> *units. so I need to reverse the conversion dealie there
[15:12] <ubitux> mateo`: and it seems a regression from your 83cab07 commit :p
[15:13] <Tjoppen> git-blame points to everyone!
[15:16] <mateo`> ubitux: :/
[15:17] <Tjoppen> don't worry, it happens to the best of us
[15:19] <mateo`> i should burn some MXF files for this :)
[15:19] <mateo`> -s
[15:20] <ubitux> and a witch
[15:20] <Tjoppen> burn it all, ralph
[15:25] <mateo`> After some thought, the logic of the code i introduced seems bad in case of seeking. After a seek, the sample count should be re-computed in the next call of mxf_read_packet not in mxf_read_seek. I'm confused.
[15:26] <Tjoppen> now I get this:
[15:26] <Tjoppen>  ret: 0         st: 1 flags:1  ts: 0.200833
[15:26] <Tjoppen> -ret: 0         st: 0 flags:1 dts: 0.000000 pts: 0.000000 pos:5117952 size:150000
[15:26] <Tjoppen> +ret: 0         st: 0 flags:1 dts: 0.200000 pts: 0.200000 pos:1071104 size:150000
[15:26] <Tjoppen> isn't this correct? it tries to seek to 0.200833 and whereas before it landed at 0.0 now it lands on 0.2 instead
[15:28] <Tjoppen> mateo`: computing in the seek is fine
[16:01] <Tjoppen> cbsrobot, mateo`: new patch sent to ML
[16:06] <durandal_1707> git lgs
[16:11] <cone-202> ffmpeg.git 03Piotr Bandurski 07master:52f21763667c: aiffenc: set correct number of bits foru8 in aiff
[16:15] <durandal_1707> nooooo
[16:15] <durandal_1707> michaelni: you enjoy commiting ugly commit logs?
[16:17] <cone-202> ffmpeg.git 03Clément BSsch 07master:0072116ccbf7: lavf: split packets before muxing.
[16:17] <cone-202> ffmpeg.git 03Clément BSsch 07master:1dab8d9157f9: lavf/srtdec: switch to FFDemuxSubtitlesQueue API.
[16:17] <cone-202> ffmpeg.git 03Clément BSsch 07master:6c26fc770436: lavf/srtenc: honor subtitle position side data.
[16:17] <cone-202> ffmpeg.git 03Clément BSsch 07master:217bdd08e347: lavf/srtdec: reindent after previous commits.
[16:31] <cbsrobot> Tjoppen: the fix works for me
[16:32] <Tjoppen> sweet
[16:40] <cbsrobot> Thnks a lot for the fix
[16:41] <cone-202> ffmpeg.git 03Piotr Bandurski 07master:17714adbf807: tiffdec: support LZW compression with inverted FillOrder
[16:59] <ubitux> michaelni: did you see the problem with recording time option?
[17:01] <michaelni> ?
[17:01] <michaelni> where ?
[17:01] <ubitux> 14:49:15 <@ubitux> http://fate.ffmpeg.org/report.cgi?time=20121220060251&slot=x86_64-archlinux-gcc-valgrindundef
[17:02] <ubitux> the old code to reset recording time might not be necessary anymore, and somehow it's currently causing problems
[17:11] <teratorn> hi, enum PixelFormat constants always map to the same int, right? reading pixfmt.h makes me wonder - I guess because I don't know what AV_PIX_FMT_ABI_GIT_MASTER is for (?)
[17:12] <wm4> teratorn: shitty compatibility hacks for Libav
[17:12] <teratorn> hahaha figures
[17:12] Action: teratorn frowns at Debian
[17:12] <teratorn> so uhm
[17:13] <teratorn> there wasn't a way to extend the pixel formats in a cross-library-compatible way...
[17:13] <cone-202> ffmpeg.git 03Nicolas George 07master:c7a1239bf980: lavfi/af_aconvert: update audio->channels.
[17:13] <teratorn> so I guess that symbol is defined *if* you want ffmpeg version of reality, and not, if you want libav version?
[17:14] <teratorn> though, since you guys always sync from libav, I'm not sure how the pix formats got out of sync...
[17:14] <teratorn> or can you explain what is/was wrong?
[17:17] <michaelni> teratorn, we added more formats, libav added different ones in their place later
[17:17] <teratorn> michaelni: hilarious.
[17:17] <teratorn> michaelni: OK
[17:17] <teratorn> the problem I have is that I am COPYING
[17:17] <teratorn> your PixelFormat struct in to my library
[17:17] <teratorn> because I need such a list in my API
[17:18] <teratorn> and I don't want to *require* the user to have ffmpeg dev headers/libs
[17:18] <teratorn> so
[17:18] <teratorn> I'll just copy without the libav junk and be happy
[17:24] <durandal_1707> there are interlaced gifs
[17:36] <michaelni> ubitux, the code is still needed, ill fix it
[17:47] <cone-202> ffmpeg.git 03Michael Niedermayer 07master:103410d67ec9: ffmpeg_opt: fix recording time in->out carryover.
[17:49] <ubitux> thanks
[17:50] <ubitux> i think Anton is planning to make the tool complain hard when an output option is set for an input one (and the other way around)
[17:51] <ubitux> 22:11 <@elenril> now to make avconv stab users when applying input options to output files...
[17:54] <durandal_1707> i dont want to be stabed
[17:56] <durandal_1707> does anyone get anything suspicious under valgrind with heart.gif?
[17:57] <ubitux> i do
[17:57] <ubitux> invalid write
[17:57] <ubitux> also, VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV)
[17:57] <ubitux> :)
[17:58] <durandal_1707> invalid write but where?
[17:58] <ubitux> http://pastie.org/5557950
[17:59] <ubitux> Carl sent a patch for this, no?
[17:59] <ubitux> btw, this code is not covered by fate
[18:00] <durandal_1707> like 50 % of code
[18:00] <ubitux> http://lucy.pkh.me/ffmpeg-coverage/ffmpeg/libavcodec/gifdec.c.gcov.html
[18:00] <ubitux> no i mean, this part
[18:00] <durandal_1707> i mean overall ;)
[18:02] <durandal_1707> Carl sent something for tranparent background
[18:04] <ubitux> it was touching this part of the code so i was wondering
[18:05] <ubitux> or maybe not
[18:13] <ubitux> durandal_1707: you don't have valgrind?
[18:15] <durandal_1707> useless here
[18:23] <durandal_1707> g4 compression with pamtotiff seems to not decode correctly
[18:49] <cone-202> ffmpeg.git 03Paul B Mahol 07master:c004de0b1c5b: gifdec: fix invalid write in giff_fill_rect
[19:00] <cone-202> ffmpeg.git 03Paul B Mahol 07master:9321e9350281: gifdec: fix invalid write in gif_copy_img_rect
[20:29] <durandal_1707> michaelni: can you explain what 568e18b1 really does?
[20:30] <durandal_1707> for gifdec only
[20:32] <durandal_1707> i dont think that check is relevant any more
[22:17] <michaelni> durandal_1707, that commit is 7 years old
[22:18] <michaelni> the unsigned casts look not strictly needed, but do no harm
[23:09] <cone-202> ffmpeg.git 03Carl Eugen Hoyos 07master:d4fdaafdb76a: Always write all colours for animated gif files, including transparent ones.
[23:19] <ubitux> nice epileptic rainbow with chompy.gif
[23:24] <ubitux> saste: going to push the overlay stuff?
[23:34] <saste> ubitux: no i discovered a crash in ffplay
[23:34] <ubitux> :(
[23:49] <cone-202> ffmpeg.git 03Stefano Sabatini 07master:ca3327d56fa3: doc/ffmpeg-formats: include metadata chapter
[23:49] <cone-202> ffmpeg.git 03Stefano Sabatini 07master:b448677e6ea7: doc: remove inclusion of libav* documentation in tools
[23:50] <saste> \o/
[23:58] <ubitux> yay
[23:59] <ubitux> readable ffmpeg.html ToC \o/
[00:00] --- Fri Dec 21 2012