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

[burek]

[00:00] <slackyman> I made a 22MB static ffmpeg
[00:00] <slackyman> a 22MB static ffplay
[00:01] <Daemon404> that sounds about right.
[00:01] <slackyman> and a 22MB static ffprobe
[00:01] <slackyman> ALL possible windows libs were included
[00:02] <slackyman> librtmp with polarssl support (due to the impossiblility to make p11-kit static)
[00:02] <slackyman> freetype, libfribidi, fontconfig
[00:02] <Daemon404> i recall librtmp being annoying to cross-compile
[00:02] <slackyman> and x264, gsm, xavs etc
[00:02] <Daemon404> and what on earth are you using fontconfig for?
[00:02] <slackyman> yep
[00:02] <slackyman> I make my own scripts
[00:03] <slackyman> ok, if you wanted to know, configure went well
[00:03] <slackyman> now let's compile
[00:03] <slackyman> (I had MANY MANY linking error in compiling and linking with the old one)
[00:04] <slackyman> sorry if It takes too much but there's a lot of libs and I only have a Q8800
[00:05] <slackyman> "make" started
[00:05] <slackyman> [OT] I really love GitHub
[00:05] <slackyman> :)
[00:06] <slackyman> another question
[00:06] <slackyman> does ffmpeg reads the "private" libs on pkg-config?
[00:08] <Daemon404> what?
[00:09] <slackyman> I noticed that many code in ffmpeg has changed since my last git
[00:09] <slackyman> ffmpeg, as far as I know, add libs defined in the pkg-config of a defined lib added
[00:10] <slackyman> but last time I had to move what's in Libs.Private to Libs
[00:10] <slackyman> since ffmpeg didn't add that flags
[00:11] <ubitux> reminds me https://ffmpeg.org/trac/ffmpeg/ticket/1539
[00:11] <ubitux> since i'm not familiar with all the cross-compil & toolchain stuff, maybe someone else want to comment when you found out the problem
[00:12] <Daemon404> slackyman, indeed pkg-config needs to be called with --static if so
[00:12] <slackyman> yes, I know
[00:12] <slackyman> sorry
[00:12] <slackyman> I'm on the phone... a call
[00:20] <slackyman> anyone knows where can I find libilbc source without having to extract to hte IETF doc?
[00:20] <slackyman> no, leave it
[00:20] <slackyman> I don't want to get in business with propertary libs
[00:22] <Daemon404> you cant legally distribute nonfree builds 
[00:22] <slackyman> yes, I know
[00:22] <slackyman> I enable "version3"
[00:23] <slackyman> and it's good that ffmpeg refuse to copmpile when finds comflicts between licenses
[00:24] <slackyman> I don't really know how google develop chrome using gpl'ed code and closing some source without license infrangements
[00:25] <slackyman> but I really don't care :)
[00:25] <slackyman> I only use gpl code
[00:27] <slackyman> Daemon404, compile and linking to your git is OK!
[00:27] <Daemon404> :)
[00:27] <slackyman> utvideo.o is linked without warnings
[00:28] <slackyman> I even modified ffmpeg Makefile to add resources like icons and versioninfo
[00:29] <slackyman> I'm pretty proud of my Monolith-version of ffmpeg
[00:32] <slackyman> ok
[00:33] <slackyman> I have to go
[00:33] <slackyman> thanks and good-evening-night-day (it depends where are you from)
[00:33] <slackyman> bye
[01:19] <durandal_1707> michaelni: i can reproduce strange bug in FFmpeg code
[01:20] <durandal_1707> ffmpeg -i wavpack_sample.wv -f null -
[01:20] <durandal_1707> will show error on end of decoding
[01:20] <durandal_1707> it appers libav does not have this bug
[01:22] <michaelni> durandal_1707, where can i find  wavpack_sample.wv ?
[01:23] <durandal_1707> michaelni: fate have many of them
[01:23] <durandal_1707> this is because of ape tags handling
[01:25] <durandal_1707> error cames from check for wpkt tag
[01:25] <durandal_1707> somehow check if we reached ape tags is not working
[01:26] <michaelni> the output from the decoder is fine though its just the error message
[01:27] <durandal_1707> am talking about bogus error mesage
[01:28] <durandal_1707> even worse (with flac and others) happens if you use -c copy
[01:28] <durandal_1707> you get spam with messages about invalid picture 0x0 size
[01:30] <durandal_1707> michaelni: i think that check libav folk addes is just ridicilous - it does now work in non-seekable case
[01:31] <durandal_1707> instead for containers for which there is no way to know when is end of stream chek for APE stuff should be added
[01:33] <michaelni> durandal_1707, this is not a difference between libav & ffmpeg, I tried latest libav and it has this bug too
[01:34] <durandal_1707> michaelni: than folk on libav channel lied to me
[01:35] <michaelni> avconv version v0.8-2587-g9e4bca1, Copyright (c) 2000-2012 the Libav developers
[01:35] <michaelni> 12bit-partial.wv: Input/output error
[01:36] <durandal_1707> hmm that is not same error, that is just partial file
[01:37] <michaelni> <michaelni> durandal_1707, where can i find  wavpack_sample.wv ?
[01:37] <durandal_1707> it can be created with wavpack
[01:37] <durandal_1707> and it does not need to have ape tags at all
[01:38] <durandal_1707> also what about related issue:
[01:38] <durandal_1707> ffmpeg -i test.flac -c copy -f null -
[01:39] <michaelni> 4.0_8-bit.wv: Invalid data found when processing input (also same between libav and ffmpeg)
[01:51] <michaelni> durandal_1707, how do i create wavpack_sample.wv with wavpack ?
[01:52] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * rd57a9928ea 10ffmpeg/ffmpeg.c: 
[01:52] <CIA-41> ffmpeg: ffmpeg: avoid bogus error with "test.flac -c copy -f null -"
[01:52] <CIA-41> ffmpeg: Reported-by: durandal_1707
[01:52] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[01:54] <durandal_1707> michaelni: something like: wavpack input.wav output.wv
[01:56] <durandal_1707> without that output...
[01:58] <michaelni> i get tests/data/asynth-44100-2.wv: Invalid data found when processing input
[01:58] <michaelni> but libav produces that too
[01:59] Action: durandal_1707 sigh
[02:00] <durandal_1707> but file should not have any tags so i dunno why this happens at all
[02:01] <durandal_1707> and i could swear i did not happened before
[02:02] Action: michaelni tries some older versiosn
[02:02] <michaelni> ffmpeg 0.11.1 is clean
[02:03] <michaelni> so its a regression
[04:11] <msmithng> durandal_1707: you had mentioned git format-patch
[04:12] <msmithng> I presume this is after I've made my changes to ffmpeg.c
[04:12] <msmithng> just trying to be sure I provide the appropriate details
[04:22] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * rb0c51bbcd1 10ffmpeg/libavcodec/h264_mc_template.c: 
[04:22] <CIA-41> ffmpeg: h264_mc_template: switch to av_assert
[04:22] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[04:23] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * r38d1c5a4cc 10ffmpeg/libavcodec/g722enc.c: 
[04:23] <CIA-41> ffmpeg: g722enc: switch to av_assert
[04:23] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[05:12] <durandal_1707> msmithng: that is how usual work is done, you work on one branch and than format-patch againts master and git send-email patches....
[05:15] <CIA-41> ffmpeg: 03Paul B Mahol 07master * rc36bad3b89 10ffmpeg/libavformat/xwma.c: 
[05:15] <CIA-41> ffmpeg: xvma: remove unused variable
[05:15] <CIA-41> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[05:17] <CIA-41> ffmpeg: 03Paul B Mahol 07master * r296bcdd2a7 10ffmpeg/libavcodec/paf.c: 
[05:17] <CIA-41> ffmpeg: paf: use reget_bufer() instead of get_buffer()
[05:17] <CIA-41> ffmpeg: Pallete is written to frame->data[1] only if it changes.
[05:17] <CIA-41> ffmpeg: This fixes PAL8->PAL8 transcoding.
[05:17] <CIA-41> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[05:26] <msmithng> hmm... it's at least nice to see that the kbps output is still incorrect in the newest fetch
[05:26] <msmithng> frame= 3093 fps= 30 q=21.0 size=       0kB time=00:01:41.93 bitrate=   0.0kbits/s dup=3 drop=0
[05:30] <durandal_1707> msmithng: when was it correct?
[05:33] <durandal_1707> actually that currently seems to work only for seekable output
[06:29] <msmithng> dang... stepped away and he's gone
[06:29] <msmithng> if anyone's interested, I'm putting together a patch that will fix this for non-seekable output
[06:30] <msmithng> additionally it will disclose the same details for any extra ost
[08:39] <CIA-41> ffmpeg: 03Carl Eugen Hoyos 07master * rd1ebb25ac6 10ffmpeg/libavformat/mov_chan.c: 
[08:39] <CIA-41> ffmpeg: Skip chan tag padding.
[08:39] <CIA-41> ffmpeg: Fixes ticket #1580
[08:55] <ubitux> michaelni: it seems 618fb9cc is causing me an issue
[08:56] <ubitux> on ticket 1576, the codec tb is invalid
[08:56] <ubitux> because it is not copied
[08:56] <ubitux> what issue does this commit solve?
[10:39] <CIA-41> ffmpeg: 03Nicolas George 07master * r6eee9f5596 10ffmpeg/libavcodec/8svx.c: 
[10:39] <CIA-41> ffmpeg: 8svx: ensure that packet size is multiple of channels.
[10:39] <CIA-41> ffmpeg: Fix an assert failure with packets of invalid size.
[11:10] <CIA-41> ffmpeg: 03Stefano Sabatini 07master * r2702e38477 10ffmpeg/libavfilter/ (Makefile defaults.c): lavfi: remove unused defaults.c file
[11:10] <CIA-41> ffmpeg: 03Stefano Sabatini 07master * r7ddf082f04 10ffmpeg/libavfilter/vsrc_testsrc.c: lavfi/testsrc: drop pointless parentheses
[11:26] <ubitux> Assertion ref->buf->refcount > 0 failed at libavfilter/buffer.c:147
[11:26] <ubitux> meh.
[11:28] <ubitux> vf tile looks broken
[11:30] <ubitux> (./ffmpeg -f lavfi -i testsrc -vf tile -f null - fails)
[11:30] <ubitux> i thought we had a test for this
[11:30] <ubitux> ah actually fate looks broken
[11:35] <ubitux> saste: is it me or everything is broken?
[11:37] <saste> ubitux: is fate (the server) working?
[11:37] <ubitux> it's down since a while&
[11:37] <saste> no seems up
[11:37] <ubitux> fate locally fails anyway
[11:38] <ubitux> saste: huh?
[11:38] <ubitux> oh :o
[11:38] <ubitux> indeed.
[11:38] <saste> ubitux: seems a problam in tile, probably introduced by anton buf_out patches
[11:39] <saste> do you want to fix it?
[11:39] <ubitux> no
[11:39] <ubitux> :)
[11:39] <ubitux> i'm trying to understand why fate fails hard locally
[11:39] <ubitux> and also why the lavfi regressions didn't spot the tile assert
[11:39] <saste> do we have a tile tests?
[11:40] <ubitux> i thought we had
[11:40] <saste> *test
[11:40] <ubitux> seems not...
[11:41] <ubitux> btw, maybe we should move the tests to tests/fate/filter.mak
[11:45] <saste> ubitux: why?
[11:45] <saste> i mean what's the pro?
[11:46] <ubitux> less messy than script shells
[11:47] <saste> makefiles are convoluted to read, unless you have your head well buried into them
[11:47] <saste> which it's not the case for me, most of the times
[11:47] <ohsix> just remember target: stuff-to do-target
[11:48] <saste> yes, and the includes and the definitions in other files included in often very non obvious ways
[11:48] <ubitux> (lol @ https://lists.libav.org/pipermail/libav-devel/2012-August/032466.html)
[11:48] <ohsix> indeed
[11:50] <saste> ubitux: some tests should be easily ported to makefile (tests/fate/filter.mak)
[11:51] <saste> the advantage is that it bookeeps dependency, i.e. if the component is not build then it won't run the test
[11:51] <ubitux> <@saste> makefiles are convoluted to read, unless you have your head well buried into them // well i like the idea of having all the tests in tests/fate/*.mak, and they are pretty easy to read
[11:51] <ubitux> and yes, it handle dependencies in a sane way
[11:52] <saste> the disadvantage is that it looks less flexible, for example see the do_lavfi_pixfmts function
[11:52] <saste> i wouldn't know how to "port" it to filter.mak
[11:53] <saste> that said, patches are welcome
[11:53] <ubitux> :)
[11:53] <ubitux> saste: are you looking at the tile issue or should i just send a mail to nicolas?
[11:54] <saste> not at the moment, my todo list is already mighty and growing, and i'm supposed to have a life after all
[11:54] <ubitux> ok :)
[11:54] <ubitux> use vsrc life
[13:05] <CIA-41> ffmpeg: 03Nicolas George 07master * rf952b23ed4 10ffmpeg/libavfilter/vf_tile.c: 
[13:05] <CIA-41> ffmpeg: vf_tile: fix output buffer ownership.
[13:05] <CIA-41> ffmpeg: There is no need to start_frame immediately on the output link
[13:05] <CIA-41> ffmpeg: since the rest is only done with the last frame of the tile.
[13:05] <CIA-41> ffmpeg: link->out_buf is now automatically dereferenced; since we give
[13:05] <CIA-41> ffmpeg: it away it must be cleared.
[13:05] <CIA-41> ffmpeg: Fix an assert failure; found by Clément BSsch.
[13:44] <CIA-41> ffmpeg: 03Nicolas George 07master * rff2955a4f7 10ffmpeg/libavformat/apetag.c: 
[13:44] <CIA-41> ffmpeg: apetag: return value when required.
[13:44] <CIA-41> ffmpeg: Should fix compilation on clang.
[15:19] <CIA-41> ffmpeg: 03Nicolas George 07master * r39b0d40d92 10ffmpeg/tests/ (lavfi-regression.sh ref/lavfi/tile): fate: add test for the tile video filter.
[17:06] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * r1894f88546 10ffmpeg/configure: 
[17:06] <CIA-41> ffmpeg: configure: add support for dlltool when lib.exe is unavailable
[17:06] <CIA-41> ffmpeg: The lib.exe test is untested. Someone who has lib.exe please test and fix it if it doesnt work
[17:06] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[17:10] <Daemon404> yay
[17:36] <CIA-41> ffmpeg: 03Clément BSsch 07master * r1f68be4764 10ffmpeg/libavutil/timecode.c: timecode: show frame rate when invalid.
[18:10] <Daemon404> michaelni, get_vlc2 is indeed a fair bit slower than my code.. trying to work out why with `perf` and mru.
[18:10] <Daemon404> re: canopus
[18:10] <Daemon404> http://chromashift.org/perf_anno.txt <-- perf log here if anyone interested
[18:11] <durandal_1707> Daemon404: what about GET_VLC ?
[18:11] <Daemon404> GET_VLC is called inside get_vlc2
[18:13] <Daemon404> gonna try with -fno-inline-functions to make it easier
[18:57] <msmithng> durandal_1707: ping
[18:57] <durandal_1707> what?
[18:58] <msmithng> to answer your question from last night... 
[18:58] <msmithng> "durandal_1707: actually that currently seems to work only for seekable output"
[18:59] <msmithng> you're correct, at least in as far I can understand the code thus far
[19:00] <msmithng> I'm working on getting a patch to accurately track and log for non-seekable (aka live) output
[19:00] <msmithng> although, I had built it against N-41668-g564bb24
[19:02] <msmithng> you had also mentioned git format-patch... I'll admit, I'm not entirely familiar with this git command. Is there a particular process you (or anyone else for that matter) like to use when creating a patch?
[19:04] <durandal_1707> did you clone repo with git?
[19:04] <msmithng> yes
[19:06] <durandal_1707> read doc/git-howto.txt
[19:06] <rexbron> I'm having trouble transcoding a mov file with a timecode track and get the following error: http://pastebin.com/fyQHtTqn. Looking at libavcodec/timecode.c, it apears that it doesn't support non-integer framerates. The timecode track in question has a frame rate of 23.98
[19:06] <msmithng> swell... thanks
[19:07] <durandal_1707> rexbron: framerate is rational and that is not integer
[19:08] <rexbron> durandal_1707: yep. It seems that -ss triggers the problem. I can transcode it as long as I don't try and seek, which unfortunately is what I want to do.
[19:11] <rexbron> nevermind, fixed in 1f68be4764adb0ee82ac0ca962ff467142ee2af9
[19:16] <rexbron> or I
[19:16] <rexbron> or I'm dumb
[19:20] <rexbron> hmm, forcing the rate with -r seems to have fixed it
[19:31] <Daemon404> durandal_1707, tirns out manually calling GET_VLC is indeed faster (with OPEN/CLOSE_READER outside the loop)
[19:31] <Daemon404> turns*
[19:32] <durandal_1707> Daemon404: michaelni already said that.....
[19:32] <ohsix> i didn't look at the trace, were you recording dcache/tlb misses and stuff? cachegrind can help with t hat sort of stuff
[19:33] <Daemon404> durandal_1707, i must have missed it
[19:33] <Daemon404> oh wait... now i remember
[19:33] <Daemon404> yes.
[19:33] <Daemon404> d'oh.
[19:37] <CIA-41> ffmpeg: 03Reimar Döffinger 07master * re1bc0171c0 10ffmpeg/libavcodec/nuv.c: 
[19:37] <CIA-41> ffmpeg: nuv: check size of buffer before accessing it instead of after.
[19:37] <CIA-41> ffmpeg: Signed-off-by: Reimar Döffinger <Reimar.Doeffinger at gmx.de>
[19:37] <CIA-41> ffmpeg: 03Reimar Döffinger 07master * r98b0120668 10ffmpeg/libavcodec/nuv.c: 
[19:37] <CIA-41> ffmpeg: nuv: Fix playback of RTjpeg from current MythTV,
[19:37] <CIA-41> ffmpeg: The previous validity check seems to work only for some
[19:37] <CIA-41> ffmpeg: (presumably older) files, in current versions the first bytes
[19:37] <CIA-41> ffmpeg: now contain the data size.
[19:37] <CIA-41> ffmpeg: Signed-off-by: Reimar Döffinger <Reimar.Doeffinger at gmx.de>
[19:46] <durandal_1707> can -maxrate be used for upper limit of vbr encoding?
[19:47] <Daemon404> that would depend on the codec
[19:53] <JEEB> also afaik maxrate goes hand-in-hand with bufsize, which is the buffer size over which the rate used in maxrate is calculated
[20:00] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * rc99d3e2e6c 10ffmpeg/tests/tiny_psnr.c: 
[20:00] <CIA-41> ffmpeg: tiny_psnr: fix undefined shift
[20:00] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[20:44] <CIA-41> ffmpeg: 03Clément BSsch 07master * r53a3748ed2 10ffmpeg/ffmpeg.c: (log message trimmed)
[20:44] <CIA-41> ffmpeg: ffmpeg: honor -ss and -t parameters with muxed subtitles.
[20:44] <CIA-41> ffmpeg: This patch fixes two things:
[20:44] <CIA-41> ffmpeg:  - in case of subtitles, check_recording_time() is comparing the current
[20:44] <CIA-41> ffmpeg:  PTS to the recording time (-t option, set to INT_MAX by default), so
[20:44] <CIA-41> ffmpeg:  the -ss option needs to be taken into account. It is not required in
[20:44] <CIA-41> ffmpeg:  do_{audio,video}_out() because this adjustment is set while polling
[20:49] <durandal_1707> what is range for qscale arguments?
[20:50] <Daemon404> it depends on the encoder
[20:50] <Daemon404> it varies between them
[20:53] <ubitux> it's insane how -ss/-t and stream copy never actually work
[20:53] <ubitux> a & v are *never* in sync :)
[20:53] <Daemon404> >implying -ss ever works reliably ever
[20:54] <durandal_1707> Daemon404: than how user know what value give best quality?
[20:54] <Daemon404> durandal_1707, its listed in the codec options... i think
[20:54] <durandal_1707> no it is not
[20:54] <ubitux> Daemon404: yeah, it seems the issue is that it jump between "chunks" of time, and never cut the packets data
[20:55] <Daemon404> durandal_1707, i guess its just not documented
[20:55] <Daemon404> ugly, etc
[21:02] <llogan> same goes for aq/q:a
[21:21] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * rb9df3f4f6c 10ffmpeg/libswresample/swresample.c: 
[21:21] <CIA-41> ffmpeg: swr: fix 10l typo mixing in and out config.
[21:21] <CIA-41> ffmpeg: Fixes ticket1458
[21:21] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[21:26] <Compn> assange documentary about his extradition , sweden, etc -- http://www.abc.net.au/4corners/stories/2012/07/19/3549280.htm
[22:17] <CIA-41> ffmpeg: 03Paul B Mahol 07master * rc2502b7b34 10ffmpeg/libavcodec/alac.c: 
[22:17] <CIA-41> ffmpeg: alac: remove redundant "alac: " from log messages
[22:17] <CIA-41> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[22:20] <Compn> j-b : can libbluray handle bluray iso ?
[22:21] <Compn> i keep getting answers from 2011
[22:21] <j-b> No
[22:21] <j-b> because noone added udf support
[22:21] <nevcairiel> libbluray can only read the files, something else would need to mount it
[22:21] <Compn> k
[22:21] <j-b> many claimed they would do it
[22:21] <j-b> noone did it
[22:22] <j-b> except by doing overly horrible hacks
[22:22] <Compn> aww, whats a few hacks between friends ? :P
[22:23] <Compn> make it a qualification task for next year GSOC ? :P
[22:23] <Compn> who has 40gb iso files anyways... crazyness.
[22:23] <Daemon404> i do
[22:23] <Daemon404> blurays
[22:23] <j-b> well, libdvdread has the right code 
[22:24] <j-b> so, it should not be hard to extract it
[22:24] <Daemon404> j-b, ping about pm i left you a night or two ago.
[22:25] <philipl> ubitux: So, your -ss -t change is ok with differing time bases?
[22:25] <philipl> I've done a bunch of work with Handbrake generated files as test input and they use 1/90000 as the timebase. Seriously...
[22:25] <philipl> (for mp4)
[22:25] <j-b> Compn: not hard to do, if someone has the guts
[22:27] <Compn> j-b : videolan recieved any threats from sony/ bluray yet ?
[22:27] <Compn> or shouldnt i ask...
[22:28] <j-b> You can ask
[22:28] <j-b> And we did not.
[22:28] <Compn> i think its been pretty quiet on the ole front as of late
[22:29] <Compn> pretty strange imo, especially with all of the big codecs (prores!) and such
[22:29] <Compn> maybe the 2000s was just a crazy lawyer playground that the world has outgrown?
[22:30] <j-b> oh, no.
[22:30] <j-b> AAC comes very often
[22:30] <j-b> DTS made MX Player to remove the DTS decoder from their Android app
[22:31] <j-b> Dolby attacks a lot
[22:31] <Daemon404> are the aac people the ones who dont understand this whle internet thing
[22:31] <j-b> Daemon404: yes
[22:31] <Compn> yikes
[22:31] <Daemon404> i was on a call with DTS once and mentioned ffmpeg
[22:31] <nevcairiel> Shouldnt they be happy people use their codecs instead of just using another one :p
[22:31] <Daemon404> yeah bad idea.
[22:32] <Compn> nevcairiel : no, they want to sell each and every decoder license
[22:32] <Compn> people not using their codecs arent 'users' , but people using ffmpeg are 'lost sales' ... bad math
[22:36] <ubitux> philipl: it should; do you have some issues?
[22:37] <philipl> No, but I was just catching up on the thread and I saw the question came up and you said you'd only seen 1/1000 samples.
[22:37] <Daemon404> j-b, is there a document or page somewhere that details how to submit for reimbursment, or how to find out whats goin on with hotels 'n' stuff? (sorry, first time with this whole shebang)
[22:38] <kierank> j-b: well aac = dolby
[22:38] <ubitux> philipl: yep, i just played with one sane mkv+ass input
[22:38] <philipl> Ok. Cool.
[22:38] <j-b> kierank: untrue.
[22:39] <kierank> via licensing = dolby, no?
[22:39] <j-b> yes
[22:39] <j-b> aac != dolby though :)
[22:39] Action: j-b runs
[22:39] <kierank> yes i was about to correct myself there
[22:39] Action: j-b runs faster
[22:50] <CIA-41> ffmpeg: 03Stefano Sabatini 07master * r20e940e768 10ffmpeg/libavfilter/vsrc_testsrc.c: 
[22:50] <CIA-41> ffmpeg: lavfi/testsrc: free the context in uninit
[22:50] <CIA-41> ffmpeg: Keeping stuff in the context can be useful for debugging purposes.
[22:50] <CIA-41> ffmpeg: 03Stefano Sabatini 07master * r33474eb1c6 10ffmpeg/libavfilter/vsrc_testsrc.c: lavfi/testsrc: extend logic in request_frame, support static image output
[22:50] <CIA-41> ffmpeg: 03Stefano Sabatini 07master * r4c8fc6a2a4 10ffmpeg/libavfilter/vsrc_testsrc.c: 
[22:50] <CIA-41> ffmpeg: lavfi/testsrc: use AVFILTER_DEFINE_CLASS for defining the filter classes
[22:50] <CIA-41> ffmpeg: Factorize.
[23:05] <ubitux> saste: i'll look at re-submitting showspectrum this week end, sorry for the delay :)
[23:05] <saste> ubitux: cool
[23:05] <ubitux> i've added the colors and fixed most of the stuff you mentioned
[23:05] <saste> ubitux: is it working now?
[23:06] <ubitux> well it already worked the other day
[23:06] <ubitux> but testing various channels stuff led to crashes so i delayed :p
[23:06] <saste> ok
[23:06] <ubitux> since it should be fixed now in lavfi and stuff, it might work
[23:07] <ubitux> the last issue i have is the jerky playback in various cases
[23:07] <ubitux> and i need to check the buffer perms stuff as you pointed out
[23:07] <ubitux> anyway, will look this week end
[23:08] <ubitux> saste: how is the dvd stuff coming btw? ;)
[23:08] <saste> ubitux: sleeping hard
[23:08] <ubitux> :D
[23:09] <ubitux> i'm really curious to see how it will deal with the only dvd i have
[23:10] <ubitux> especially with the subtitles
[23:10] <saste> ubitux: i'm toying with the idea of creating a small kickstarter project for it, and see if the prospect of getting some money will foster me
[23:10] <ubitux> hehe
[23:10] <ubitux> ok :)
[23:14] <ubitux> saste: hey so we lost the only buffer local reuse case when moving color to testsrc, right?
[23:15] <saste> ubitux: uh? what do you mean?
[23:16] <saste> i extended the testsrc framework, so it is now already reusing the buffer, same with the color->testsrc merge
[23:16] <ubitux> oups my bad i thought the vf color code was moving to testsrc
[23:16] <saste> check how it is done with rgtestsrc
[23:17] <saste> i'll apply the color patch soon if no one will comment
[23:18] <ubitux> mmh ok seems like it's actually doing something similar
[23:18] <ubitux> i was imaginating things again
[23:20] <slackyman> Hi
[23:20] <slackyman> Daemon404, are you here?
[23:20] <Daemon404> ... yes?
[23:21] <slackyman> I'm compiling the same ffmpeg configuration for linux (except for the windows-relative libs)
[23:21] <slackyman> I'm recompiling some system libs since they're shared
[23:21] <slackyman> and put in a different path
[23:22] <slackyman> but I have a problem with SDL
[23:22] <slackyman> when compiling SDL statically it includes some sys lib like libvga
[23:23] <slackyman> but when I'm using its relative sdl-config I get an arror regardin the fact that "ld cannot find -lvga'
[23:24] <slackyman> i edited my configure file to make it use my own recompiled sdl-config
[23:25] <Daemon404> not my domain
[23:25] <Daemon404> also, this belongs in #ffmpegf\
[23:25] <Daemon404> er
[23:25] <Daemon404> #ffmpeg
[23:26] <slackyman> ok
[23:26] <slackyman> thanks
[23:26] <slackyman> bye
[23:40] <CIA-41> ffmpeg: 03Anton Khirnov 07master * r921063877e 10ffmpeg/libavformat/apetag.c: apetag: change a forgotten return to return 0
[23:40] <CIA-41> ffmpeg: 03Diego Biurrun 07master * r6376a3ad24 10ffmpeg/libavcodec/x86/h264dsp_mmx.c: x86: h264dsp: Remove unused variable ff_pb_3_1
[23:40] <CIA-41> ffmpeg: 03Diego Biurrun 07master * r13a79cf84e 10ffmpeg/libavcodec/ (Makefile dca.c): 
[23:40] <CIA-41> ffmpeg: dca: Rename dca.c ---> dcadec.c
[23:40] <CIA-41> ffmpeg: This will allow adding dca.c with tables used from other files.
[23:40] <CIA-41> ffmpeg: 03Diego Biurrun 07master * r9e4bca16f8 10ffmpeg/ (7 files in 2 dirs): dca: Move tables used outside of dcadec.c to a separate file.
[23:40] <CIA-41> ffmpeg: 03Ronald S. Bultje 07master * r53dfaedc01 10ffmpeg/libavcodec/x86/ (dsputilenc_mmx.c fdct_mmx.c motion_est_mmx.c mpegvideo_mmx.c): x86/dsputilenc: bury inline asm under HAVE_INLINE_ASM.
[23:40] <CIA-41> ffmpeg: 03Ronald S. Bultje 07master * rb6a3849adb 10ffmpeg/libavcodec/x86/ (Makefile fft.c fft_3dn.c fft_3dn2.c fft_mmx.asm): 
[23:40] <CIA-41> ffmpeg: fft: port FFT/IMDCT 3dnow functions to yasm, and disable on x86-64.
[23:40] <CIA-41> ffmpeg: 64-bit CPUs always have SSE available, thus there is no need to compile
[23:40] <CIA-41> ffmpeg: in the 3dnow functions. This results in smaller binaries.
[23:40] <CIA-41> ffmpeg: 03Mans Rullgard 07master * r998170913c 10ffmpeg/libavcodec/arm/ (5 files): 
[23:40] <CIA-41> ffmpeg: ARM: use standard syntax for all LDRD/STRD instructions
[23:40] <CIA-41> ffmpeg: The standard syntax requires two destination registers for
[23:40] <CIA-41> ffmpeg: LDRD/STRD instructions. Some versions of the GNU assembler
[23:40] <CIA-41> ffmpeg: allow using only one with the second implicit, others are
[23:40] <CIA-41> ffmpeg: more strict.
[23:40] <CIA-41> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[23:40] <CIA-41> ffmpeg:  ARM: use =const syntax instead of explicit literal pools
[23:40] <CIA-41> ffmpeg:  ARM: use standard syntax for all LDRD/STRD instructions
[23:40] <CIA-41> ffmpeg:  fft: port FFT/IMDCT 3dnow functions to yasm, and disable on x86-64.
[23:40] <CIA-41> ffmpeg: 03Ronald S. Bultje 07master * rddbe71b44f 10ffmpeg/libavcodec/dct-test.c: dct-test: allow to compile without HAVE_INLINE_ASM.
[23:40] <CIA-41> ffmpeg: 03Mans Rullgard 07master * rfaa788227f 10ffmpeg/libavcodec/arm/ (simple_idct_arm.S simple_idct_armv5te.S simple_idct_armv6.S): 
[23:40] <CIA-41> ffmpeg: ARM: use =const syntax instead of explicit literal pools
[23:40] <CIA-41> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[00:00] --- Thu Aug  2 2012