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

[burek]

[00:07] <saste> wow a doc document with a screenshot image
[00:08] <saste> actually two screenshot images
[00:12] <llogan> don't get me started. i setup a wordpress site for some local union and they simply use it to post MS office files instead of simply making posts/pages.
[00:17] <saste> they re-adapt their usual workflow
[00:20] <cone-621> ffmpeg.git 03Stefano Sabatini 07HEAD: tools: add ffescape utility
[01:06] <cone-621> ffmpeg.git 03Paul B Mahol 0773f9d2e88731: cafenc: make .long_name match demuxer
[01:59] <cone-621> ffmpeg.git 03Matthieu Bouron 07cfb1c3c9f01a: aiffdec: read ID3 attached pictures
[02:07] <durandal_1707> can we get new logo? current one is really ugly.
[02:18] <llogan> durandal_1707: we can go back to the standard logo. michaelni and maybe Compn can do that.
[02:18] <llogan> probably about time anyway, IMO.
[02:28] <Compn> we should make a pretty one with sexy girls for durandal_1707 :)
[02:29] <llogan> girls? FFmpeg? i've never heard of this combination.
[02:29] <llogan> maybe i'll make one that incorporates 10L of soft drink bottles
[02:29] <Compn> news entry: ffmpeg developers seeking women for marketing purposes.
[02:30] <llogan> we used our allotment already. she made the summer logo.
[02:31] <Compn> doh
[02:32] <Compn> i dont think its ugly
[02:32] <Compn> its fall colors
[02:32] <Compn> around here its orange, red, yellow and green leaves everywhere
[02:41] <llogan> it's hemisphericist
[03:39] <cone-621> ffmpeg.git 03Michael Niedermayer 07f69f9b387624: aacenc: replace scale factor warning by assert
[03:39] <cone-621> ffmpeg.git 03Michael Niedermayer 070018aa9013db: aacps: loose self assignment
[03:39] <cone-621> ffmpeg.git 03Michael Niedermayer 079f36ec6aa936: aacps: fix order of operands of ipdopd_reset().
[14:23] <ubitux> hey
[14:24] <ubitux> actually we *can* print the pts with drawtext.
[14:27] <ubitux> but there's something fishy
[14:27] <thegeek> anyone got any good ideas for debugging the asm-crashes I get with a mingw-compiled ffmpeg 1.0 ?
[14:27] <thegeek> ticket #1844
[14:27] <Compn> thegeek : what ver yasm ?
[14:28] <thegeek> let me check
[14:28] <thegeek> 1.1
[14:28] <thegeek> I'm cross-compiling on a ubuntu VM
[14:29] <thegeek> I build the entire cross-compiling toolchain with the "mxe" framework/project
[14:29] <thegeek> latest mingw-w64 etc (gcc 4.7.2)
[14:29] <ubitux> ffplay -f lavfi 'testsrc=s=640x480,drawtext=text=%T:basetime=0:box=1:x=w/2-tw/2:y=50:fontsize=50'
[14:29] <ubitux> yay.
[14:30] Action: ubitux doesn't understand why it starts at 02:00:00
[14:31] <thegeek> Compn: If I disable asm or specify a wrong (unknown) arch it works
[14:31] <thegeek> will specifying a bad arch in cross-compiling mode also disable asm?
[14:31] <Compn> well the asm is for x86, so if you specify some diff arch, it wont get compiled...
[14:31] <thegeek> yes that makes sense, I can stop looking at the whole arch thing then
[14:32] <thegeek> it's basically just something to do with asm
[14:32] <thegeek> static/shared makes no difference
[14:32] <thegeek> and I've tried disabling additional libs etc
[14:32] <nevcairiel> you can disable asm at runtime when you specify -cpuflags 0 or something like that
[14:33] <thegeek> hmm, that's interesting
[14:33] <nevcairiel> might help debugging
[14:33] <thegeek> yeah
[14:33] <Compn> your gdb says it crashes in sse2 ?
[14:33] <Compn> of course, i have no clue 
[14:33] <thegeek> nevcairiel: indeed, with cpuflags 0 the command does not crash, might be a temporary workaround if nothing else
[14:34] <nevcairiel> will most likely be rather slow
[14:34] <thegeek> Compn: I've seen it in both the sse2 and avx version of the function
[14:34] <thegeek> nevcairiel: yes, why I don't want to disable it for the entire build;P
[14:34] <Compn> maybe race condition ?
[14:34] <thegeek> it happens _every_ time
[14:34] <Compn> can you shrink your command line further ?
[14:34] <thegeek> hmm, I'll try
[14:35] <Compn> on windows, you can also output to NUL which is like devnull ...
[14:36] <Compn> course that might just add noise :P
[14:37] <Compn> crashes in swresample ? try setting a different channel mix or something too
[14:38] <thegeek> ah ok
[14:38] <Compn> why stereo to mono ?
[14:38] <Compn> try setting it stereo output probably makes it work :P
[14:38] <Compn> anyways, cant help much , not a programmer
[14:38] Action: Compn goes afk
[14:38] <Compn> good lcuk
[14:38] <thegeek> thanks:)
[14:39] <ubitux> ./ffplay -f lavfi 'testsrc=s=640x480,drawtext=text=%T:basetime=0:box=1:x=w/2-tw/2:y=50:fontsize=50[plane]; aevalsrc=sin(2*PI*t*220)*exp(-4*mod(t\,1)),asplit[out1][a]; [a]showwaves=s=300x100[waves]; [plane][waves] overlay=50:H/2-h/2 [out0]'
[14:39] <ubitux> @_@
[14:40] <ubitux> michaelni: since you added that basetime option, any idea why it starts at 2 hours?
[14:42] <ubitux> mmh maybe some localisation issue
[14:43] <divVerent> ubitux: haha, learned something new
[14:43] <divVerent> so ffplay is now a function plotter ;)
[14:43] <ubitux> :D
[14:44] <ubitux> it's too bad this basetime thing is not documented, i recently told someone this kind of thing wasn't supported
[14:46] <cone-965> ffmpeg.git 03Luca Barbato 0742c26a4864f1: rawvideo: use a specific read_header
[14:46] <cone-965> ffmpeg.git 03Luca Barbato 075f0e161dd615: g722: refactor out of rawdec.c
[14:46] <cone-965> ffmpeg.git 03Luca Barbato 072ef4d586d635: pcmdec: remove dependency from rawdec
[14:46] <cone-965> ffmpeg.git 03Luca Barbato 07587874ef1c94: rawdec: remove ff_raw_read_header
[14:46] <cone-965> ffmpeg.git 03Janne Grunau 07285b706b551b: avfilter: fix graphparser memleaks on error paths
[14:46] <cone-965> ffmpeg.git 03Janne Grunau 071b891d17c531: avconv: fix bitrate report when writing to /dev/null
[14:46] <cone-965> ffmpeg.git 03Michael Niedermayer 07507f2940ccdc: Merge commit '1b891d17c531e8a63c2974aab4bf997ce70746f3'
[14:48] <ubitux> 'testsrc=s=640x480,hue=H=2*PI*t,drawtext=text=%T:basetime=0:box=1:x=w/2-tw/2:y=50:fontsize=50[plane]; aevalsrc=sin(2*PI*t*220)*exp(-4*mod(t\,1)),asplit[out1][a]; [a]showwaves=s=300x100[waves]; [plane][waves] overlay=50:H/2-h/2 [out0]'
[14:48] <ubitux> even more psychedelic
[14:49] <durandal_1707> i dont have drawtext
[14:49] <ubitux> too bad ;)
[14:49] <michaelni> ubitux, feel free to document all undocumented things
[14:49] <divVerent> document ALL the things ;)
[14:49] <ubitux> michaelni: i'd like to fix the timezone thing :p
[14:50] <ubitux> can anyone else confirm the timer isn't starting at 00:00:00?
[14:50] <divVerent> ah, hue effect ;)
[14:50] <cone-965> ffmpeg.git 03Paul B Mahol 077fe6f6e2b10f: caf muxer: write metadata
[14:52] <divVerent> ubitux: haha, found a really nasty and hard to track down bug in showspectrum or aevalsrc...
[14:52] <divVerent> or rather
[14:52] <divVerent> maybe the bug is that they don't work with float values ;)
[14:52] <ubitux> you found a bug?
[14:53] <saste> impossible, ffmpeg has no bugs
[14:53] <divVerent> either that, or a missing feature
[14:53] <saste> (just undocumented features)
[14:53] <divVerent> ffplay -f lavfi "aevalsrc=tan(3000*t), showspectrum=s=640x480 [out0]"
[14:53] <divVerent> expected result: all frequency lines are equally strong
[14:53] <ubitux> herm crash :(
[14:53] <divVerent> because tan(x) = 2*(sin(2x) + sin(4x) + sin(6x) + ...)
[14:53] <divVerent> so all the overtones should look equally bright
[14:54] <divVerent> but the lower ones are stronger :P
[14:54] <divVerent> better use 10000*t :)
[14:54] <divVerent> admitteldy, this function IS evil
[14:54] <ubitux> zsh: segmentation fault  ./ffplay -f lavfi "aevalsrc=tan(3000*t), showspectrum=s=640x480 [out0]"
[14:54] <ubitux> :(
[14:55] <divVerent> my conclusion from how it looks is that somewhere, the samples get clipped... could it aevalsrc clips samples into [-1..1] range?
[14:55] <ubitux> and when i run it with valgrind it works... and spots no error
[14:55] <divVerent> haha
[14:55] <divVerent> valgrind makes it so slow the error doesn't happen :P
[14:55] <ubitux> :D
[14:56] <divVerent> ffplay -f lavfi "aevalsrc=tan(2*PI*440*t), showspectrum=s=640x480 [out0]"
[14:56] <divVerent> is more sensible anyway :P
[14:56] <divVerent> ah, indeed, it must be sample clipping
[14:56] <divVerent> the spectrum looks good when I add a * 0.01
[14:56] <ubitux> crashes with * 0.01
[14:57] <ubitux> wth.
[14:57] <divVerent> well, you do know what tan() does and why it is evil... but shouldn't crash
[14:57] <divVerent> maybe you hit a t value for which you get a NaN...
[14:57] <saste> ubitux: it doesn't crash here
[14:57] <divVerent> on the other hand
[14:57] <ubitux> divVerent: do you have the same results if you just remove the showspectrum?
[14:57] <divVerent> aevalsrc=1/0 does not crash
[14:58] <ubitux> yes ffmpeg prevents black holes
[14:58] <divVerent> ubitux: I have no results if I remove showspectrum
[14:58] <divVerent> because then there is nothing to see
[14:59] <divVerent> oh wait, there is
[14:59] <divVerent> ffplay has automatic showspectrum
[14:59] <divVerent> sounds HORRIBLE btw, but I expected that :P
[14:59] <divVerent> I wonder how evil playing the tan() is on OS X, which has a floating point audio system
[14:59] <divVerent> could result in a sound whose volume you can't turn down ;)
[15:01] <ohsix> it would sound find
[15:01] <ohsix> fine, glaghgh
[15:02] <ohsix> was actually just reading about how that crap all worked; trying to find some references i know i read a few years ago but couldn't find again :]
[15:02] <divVerent> I mean, CoreAudio is fp32... does that mean applications can output sound values > 1? What if they output really HUGE values... and using the internal speaker of a Mac mini, which has no hardware volume control
[15:03] <divVerent> if output clamping takes place only after mixing, then there would be no way to turn this sound to sensible level
[15:03] <ubitux> < divVerent> ffplay has automatic showspectrum // the filter is based on this ffplay rdft mode
[15:04] <ubitux> if you have a different output, that's not wanted
[15:04] <divVerent> ah, I see
[15:04] <divVerent> the output is the same
[15:04] <ubitux> <@durandal_1707> i dont have drawtext // you need --enable-fontconfig --enable-libfreetype
[15:06] <divVerent> ubitux: okay... avalsrc outputs double* samples
[15:07] <divVerent> [Parsed_showspectrum_1 @ 0x7f4ee40021e0] auto-inserting filter 'auto-inserted resampler 0' between the filter 'Parsed_aevalsrc_0' and the filter 'Parsed_showspectrum_1'
[15:07] <divVerent> [auto-inserted resampler 0 @ 0x7f4ee40090c0] chl:mono fmt:dblp r:44100Hz -> chl:mono fmt:s16p r:44100Hz
[15:07] <divVerent> there's the "problem" :)
[15:08] <ubitux> so what's wrong here?
[15:08] <divVerent> that the spectrum filter requires 16bit integer samples
[15:08] Action: durandal_1707 http://doom10.org/index.php?topic=2413.msg11037#msg11037
[15:08] <divVerent> my tan() example was not really serious, but some people would quite surely like at least 24bit precision in it
[15:09] <ubitux> < divVerent> that the spectrum filter requires 16bit integer samples // that's the reason the resampler is resampling it
[15:09] <divVerent> yes
[15:09] <divVerent> the resampling filter insertion is fine
[15:09] <divVerent> but why does the spectrum filter insist on s16p
[15:09] <durandal_1707> patch welcome
[15:09] <ubitux> oh because the original code was using 16-bit
[15:09] <ubitux> so i didn't change it
[15:09] <divVerent> just asking, as there may be a good reason
[15:10] <divVerent> wonder what type FFTSample is
[15:10] <divVerent> as it mainly depends on that
[15:10] <ubitux> float
[15:10] <divVerent> float... okay, that sounds like it should be somewhat easy to add more formats
[15:11] <divVerent> and ffplay.c's code has a similar issue, sample_array is 16bit
[15:12] <ubitux> 15:09:42 <@ubitux> oh because the original code was using 16-bit
[15:12] <ubitux> :)
[15:12] <divVerent> but that file has quite some code depending on that property
[15:12] Action: divVerent just asks himself why that code in ffplay.c even works
[15:13] <divVerent> where does it ensure the audio data actually is int16 :P
[15:13] <divVerent> ah, it forces S16 output format
[15:13] <divVerent> I see now
[15:14] <divVerent> I wonder if we already got some audiophiles who claimed that 24bit flacs sound so much better in ffplay than 16bit flacs ;)
[15:14] <ubitux> divVerent: try replacing AV_SAMPLE_FMT_S16P with AV_SAMPLE_FMT_DBLP in the lavfi/avf_showspectrum.c
[15:14] <ubitux> and see if it still works
[15:14] <ubitux> (or works better?)
[15:15] <divVerent> that can't work ;)
[15:15] <ubitux> why?
[15:15] <divVerent>     /* fill RDFT input with the number of samples available */
[15:15] <divVerent> this loop needs then duplicating for the different formats
[15:15] <ubitux> ah indeed there is this one
[15:15] <divVerent> and that's the point where I'd ask the coding style questions before making a patch
[15:15] <ubitux> s/int16_t/double/g might work
[15:15] <divVerent> I'd probably use a macro here
[15:16] <divVerent> sure, but then it's double-only
[15:16] <divVerent> it's probably more sensible to have the filter support multiple formats
[15:16] <ubitux> sure, but just to test if it fixes your "problem"
[15:16] <divVerent> to not convert back and forth
[15:16] <divVerent> I know it does :P
[15:16] <ubitux> yup
[15:16] <ubitux> check af_volume
[15:16] <divVerent> putting that on my TODO for now
[15:16] <ubitux> where there are multiple supporte formats
[15:16] <ubitux> supported
[15:17] <divVerent> it seems quite straightforward, the hard part is duplicating the code "cleanly" for the different formtas
[15:17] <divVerent> is there an aversion in ffmpeg against macros?
[15:17] <divVerent> like
[15:17] <divVerent> #define HANDLE_FORMAT(..., ...) ... \ ... \ ... \
[15:17] <divVerent> and then
[15:17] <divVerent> HANDLE_FORMAT(AV_SAMPLE_FMT_S16P, int16_t, 32767)
[15:17] <divVerent> HANDLE_FORMAT(AV_SAMPLE_FMT_DBLP, double, 1)
[15:17] <divVerent> like this
[15:18] <divVerent> or do ffmpeg authors rather prefer explicitly duplicating the code?
[15:18] <ubitux> in that particular case, as maintainer of this filter, i don't give a damn
[15:19] <divVerent> and I'm the type of guy who would prefer going with macros in such case
[15:19] <divVerent> or C++ templates ;)
[15:21] <divVerent> ah, nice... this filter is apparently a lot better than ffplay.c's ;)
[15:21] <divVerent> it can show the channels separately in colors
[15:22] <ubitux> same as ffplay
[15:22] <ubitux> really it's doing exactly the same, except two things:
[15:22] <divVerent> oh? I listened to stuff with it and never saw any colors
[15:22] <durandal_1707> ??? i get different colors to with ffplay
[15:22] <ubitux> - it has a different windowing function
[15:22] <ubitux> - it can have a sliding mode
[15:22] <divVerent> don't tell me Germany's most known acapella band does mono mixes... ;)
[15:22] <ubitux> rest should be identical
[15:22] <durandal_1707> showspectrum is somehow slow for me and is not continuous
[15:23] <ubitux> durandal_1707: i guess this depends on the window size
[15:23] <ubitux> try setting a asetnbsamples filter maybe
[15:23] <ubitux> <@durandal_1707> ??? i get different colors to with ffplay // really? oO
[15:25] <durandal_1707> ubitux: so you get mono only?
[15:25] <ubitux> Program received signal SIGSEGV, Segmentation fault.
[15:25] <ubitux> fft16_avx () at libavcodec/x86/fft.asm:321
[15:25] <ubitux> 321	    mova       m2, Z(2)
[15:25] <ubitux> arhem.
[15:25] <ubitux> :(
[15:26] <ubitux> durandal_1707: i don't understand your question
[15:26] <ubitux> the color thing should be the same as ffplay
[15:26] <ubitux> durandal_1707, try: http://lucy.pkh.me/samples/6ch.flac
[15:26] <cone-965> ffmpeg.git 03Janne Grunau 07dcdfb8ede358: pcmdec: change default of channels parameter to 1
[15:26] <cone-965> ffmpeg.git 03Luca Barbato 0722f7942fe7d7: ffv1: set the range coder state in decode_slice_header
[15:26] <divVerent> ah, colors do work
[15:26] <cone-965> ffmpeg.git 03Luca Barbato 07254056c4ab61: pcm: change references to raw to pcm
[15:26] <cone-965> ffmpeg.git 03Martin Storsjö 07121604b024cf: build: Include HEADERS-yes in the HEADERS variable
[15:26] <cone-965> ffmpeg.git 03Michael Kostylev 07eadfb0560a2f: configure: recognise more sparc variants as --cpu argument
[15:26] <cone-965> ffmpeg.git 03Mans Rullgard 076aa93689abe8: configure: sanitise sparc vis check
[15:26] <cone-965> ffmpeg.git 03Michael Niedermayer 079aa630a520eb: Merge remote-tracking branch 'qatar/master'
[15:27] <divVerent> it's just that usually, the channels are too similar for it to be visible
[15:27] <divVerent> ffplay -f lavfi "amovie=0.mp3, pan=2:c0=c0:c1=0*c1 [out0]"
[15:27] <divVerent> shows that they work
[15:27] <ubitux> you can play with the channels with aevalsrc too
[15:27] <divVerent> or that, sure
[15:27] <ubitux> line sin(2*t*PI*440):0 and 0:sin(2*t*PI*440) maybe
[15:27] <ubitux> like*
[15:28] <divVerent> sure
[15:28] <divVerent> that'll work as well
[15:28] <divVerent> just the coloring is apparently so subtle that typically you can't see it
[15:28] <ubitux> (michaelni: any idea for the sigsegv?)
[15:30] <ubitux> i guess i'll have to git bisect
[15:37] <ubitux> mmh strange it doesn't work in 1.0 either
[15:39] <ubitux> btw, still no one to implement a motion estimation filter? :P
[15:41] <durandal_1707> ubitux: mplayer have something like that?
[15:41] <ubitux> not that i know of
[15:42] <ubitux> from mplayer i believe what we lacks is the dvd input and the various telecine related filters
[15:42] Action: durandal_1707 found serious caf demuxer bug
[15:49] <ubitux> looks like the fft16 is broken from the beginning
[15:49] <ubitux> at least it was broken when i added showspectrum
[15:49] <ubitux> or actually, showspectrum might be broken.
[15:55] Action: ubitux wonders why mru didn't pick 42ee9f398 and prefered to fix it his own may :-°
[16:03] <ubitux> ah, i found the problem.
[16:06] <ubitux> (i use realloc so it's not aligned)
[16:10] <ubitux> divVerent: there is indeed a different output with doubles
[16:11] <ubitux> and we need to change some stuff in the filter :p
[16:21] <michaelni> saste, compare http://ffmpeg.org/doxygen/0.8/examples.html and http://ffmpeg.org/doxygen/0.9/examples.html, both generated by the same doxgen file
[16:21] <michaelni> do you have any idea why it no longer finds the examples ?
[16:25] <michaelni> saste, figured it out, ill fix it
[16:29] <durandal_1707> michaelni: what is ridiculous about avio_get_str()?
[16:34] <michaelni> durandal_1707, is that question supposed to make sense ?
[16:36] <nevcairiel> stupid make and its segfaults
[16:37] <michaelni> does it always segfault at the same place ?
[16:38] <cone-965> ffmpeg.git 03Michael Niedermayer 071bf50711042c: rmdec: use av_assert for audio_pkt_cnt
[16:38] <cone-965> ffmpeg.git 03Michael Niedermayer 07c01a462cda8d: rmdec: fix null derefercne
[16:38] <cone-965> ffmpeg.git 03Michael Niedermayer 07ca28cb5f8388: examples: fix doxy so they appear on the example page
[16:41] <michaelni> ubitux, do you maintain swfenc.c ?
[16:42] <michaelni> or only swfdec.c ? 
[16:42] <nevcairiel> michaelni: nah, the segfault is rather random, msys is just old and crappy
[16:42] <michaelni> yep but i was wonderin where in the make code it faults because if its always the same spot it could be fixed maybe easily
[16:43] <michaelni> or can it be upgraded somehow to some working version easily ?
[16:43] <nevcairiel> compiling stuff for msys is like black magic
[16:44] <michaelni> is msys actvely maintained by someone ?
[16:44] <michaelni> if so reporting that crashes would be a good idea
[16:46] <durandal_1707> michaelni: i was reading commit messages, so was interested in reasoning
[16:47] <nevcairiel> i dont think msys is getting much love these days
[16:49] <durandal_1707> michaelni: see 4118d66cb39f96a22
[16:56] <michaelni> durandal_1707, ahh yes, i think get_strz() API is cleaner and simpler
[17:04] <ubitux> michaelni: swfdec.c
[17:04] <ubitux> assuming i'm the maintainer :p
[17:05] <ubitux> at least that's the file i contributed most
[17:05] <durandal_1707> ubitux: you understand whole code in there?
[17:06] <ubitux> i don't think so
[17:06] <michaelni> ubitux, was just asking because coverity issues
[17:07] <michaelni> are there any left in files you maintain ?
[17:08] <ubitux> i fixed them already afaict
[17:08] <michaelni> durandal_1707, do you maintain tak_parser ?
[17:08] <ubitux> if you see anything i missed, please tell me
[17:08] <ubitux> i've fixed the subtitles overflow, ebur128 and a few others iirc
[17:09] <durandal_1707> michaelni: something is broken?
[17:09] <michaelni> coverity found an issue in it, didnt look at all, so dunno if trivial or not
[17:11] <durandal_1707> it is same as mlp one
[17:11] <ubitux> i've a srtenc fix pending btw (not related to coverity)
[17:11] <ubitux> (waiting for review on the ml)
[17:11] <ubitux> which is a somehow serious issue since it prevents encoding srt
[17:12] <ubitux> (lavc/srtenc: fix invalid read in case of SubRip.)
[17:13] <ubitux> btw, about the timezone issue i have
[17:13] <ubitux> http://pastie.org/5119293
[17:14] <ubitux> i wonder how this could be fixed properly
[17:14] <ubitux> i could change the env but it will break standard usage
[17:15] <ubitux> one way could be to parse the result of a strftime %z
[17:15] <ubitux> and use it to shift the 0 value
[17:16] <ubitux> ohh, extern long timezone mmh
[17:17] <michaelni> saste, btw as you have a coverity account now, please fix or mark as false postive(intentional  all issues in files you maintain
[17:18] <durandal_1707> hah, saste finally got his coverity account :)
[17:20] <ubitux> http://pastie.org/5119322 got it.
[17:24] <durandal_1707> lol, why I marked issue as fixed if i did not send fix?
[17:24] <ubitux> "the bug doesn't exist"
[17:33] <ubitux> mmh it's fun the borders of the drawtext are messed up
[17:33] <durandal_1707> ubitux: what happened to coverage?
[17:34] <ubitux> i don't know
[17:34] <ubitux> it broke
[17:34] <ubitux> a long time ago :(
[17:35] <ubitux> http://lucy.pkh.me/coverage.log
[17:36] <cone-965> ffmpeg.git 03Paul B Mahol 07adc61d68b02c: bit: check av_new_packet() return value
[17:36] <ubitux> btw
[17:36] <ubitux> http://lucy.pkh.me/lavfi.webm
[17:36] <ubitux> the left & right of the drawtext box are a bit weird& :)
[17:39] <durandal_1707> lol
[17:40] Action: ubitux loves lavfi
[17:40] <durandal_1707> i want to remove myself from issue ownership
[18:25] <cone-965> ffmpeg.git 03Michael Niedermayer 0759eae884292d: cws2fws: check inflateInit return value
[18:25] <cone-965> ffmpeg.git 03Michael Niedermayer 0786aba86b1b03: cws2fws: check lseek() return
[18:25] <cone-965> ffmpeg.git 03Michael Niedermayer 075b45b66220ff: cws2fws: check fstat return code.
[18:51] <ubitux> philipl: can you have a look to "[PATCH 1/3] lavc/srtenc: fix invalid read in case of SubRip." ?
[19:15] <philipl> ubitux: ok
[19:25] <ubitux> philipl: thanks :)
[19:26] <philipl> np
[19:26] <philipl> Some day soon I'll have to time to come back to writing code. I want to sort out that duration precision problem, seeing as Nicholas hasn't gone back to it.
[20:05] <durandal_1707> is it ok to remove rectangle filter?
[20:07] <Compn> is it ported ?
[20:07] Action: Compn has no idea what rectangle filter does
[20:07] <Compn> :D
[20:07] <Daemon404> makes rectangles
[20:07] <Daemon404> i bet.
[20:10] <durandal_1707> also this yuv colorspace converter, wtf - is that from ages before swscale?
[20:11] <durandal_1707> will remove it too
[20:11] <nevcairiel> swscale isnt exactly good at converting between different yuv colorspace
[20:12] <nevcairiel> in fact, it fails completely
[20:13] <durandal_1707> nevcairiel: submit bug report, lavfi is not colorspace converter - and this filter does not do whay you think it does
[20:13] <nevcairiel> which filter exactly?
[20:14] <durandal_1707> yuvcsp
[20:15] <nevcairiel> well that one serves very little purpose, i though you were referring to anothet one =p
[20:15] <durandal_1707> which one?
[20:15] <ubitux> colormatrix i guess
[20:16] <durandal_1707> colomatrix is ported from mp filter?
[20:17] <nevcairiel> no, from an avisynth filter
[20:17] <Compn> ugh
[20:17] <Compn> usa govt , how much is it spending on open source?
[20:18] <Compn> Daily Open Source Infrastructure Report
[20:18] <Compn> 22 October 2012
[20:18] <Compn> daily infrastructure report??
[20:18] <Compn> 43. October 19, The H – (International) Microsoft and Secunia warn of FFMpeg
[20:18] <Compn> vulnerabilities. Microsoft provided details of several critical vulnerabilities in older
[20:18] <Compn> versions of FFmpeg’s open source video codec tools and libraries; these could allow an
[20:18] <Compn> attacker to execute arbitrary code on a system by getting users to open a specially
[20:18] <Compn> crafted media file. 
[20:18] <durandal_1707> so many years passed and nobody improved swscale to properly handle colorspace conversions,
[20:18] <Compn> This would execute the malicious code with the same permissions as the user. Another issue reported by Secunia could have the same effect. For the Microsoft flaws, all versions of FFmpeg up to and including 0.10 are vulnerable, while for the Secunia issue, versions up to and including 0.11.2 are affected. 
[20:19] <durandal_1707> Compn: stop pastin' webs here
[20:19] <Compn> ehe 
[20:19] <Compn> ok
[20:20] <Compn> which colorspace conversions are you talking about durandal_1707 ?
[20:20] <durandal_1707> the one nevcairiel is complaining about
[20:20] <nevcairiel> what the colormatrix filter does
[20:20] <nevcairiel> swscale doesnt really implement it
[20:20] <nevcairiel> although it has APIs for setting a matrix, those options do nothing
[20:21] <JEEB> I think they do in one direction
[20:21] <JEEB> but not the other
[20:21] <JEEB> (in YCbCr<->RGB)
[20:21] <JEEB> I think YCbCr->RGB might work now
[20:21] <Compn> oh between the 601 > 709 profile thing
[20:21] <Compn> i thought there was an option to do it
[20:21] <Compn> maybe i'm thinking of a patch that was never applied
[20:22] <nevcairiel> option yes, working no
[20:22] <JEEB> ^
[20:22] <nevcairiel> the API is there, the code behind it ignores it :p
[20:22] <nevcairiel> oh well i dont usually need that anymore
[20:22] <JEEB> yes, you did like most people do it
[20:23] <JEEB> they implement it themselves
[20:23] <JEEB> :3
[20:23] <Compn> does ffmbc have it working ?
[20:31] <Daemon404> ffmbc uses colormatrix
[20:32] <Compn> well there you go
[20:33] <Compn> 5 people complaining, then writing own implementation, no one fixes it in ffmpeg
[20:33] <Compn> derp
[20:33] <durandal_1707> rectangle filter functionality is in drawbox?
[20:33] <Compn> but a box isnt a rectangle!
[20:33] <Compn> :P
[20:34] <JEEB> Compn, the thing is -- not many people exactly understand and/or like the swscale code paths
[20:34] <Compn> i get that
[20:34] <JEEB> writing your own stuff is not the best thing
[20:34] <durandal_1707> Compn: what is difference?
[20:34] <Compn> durandal_1707 : i'm just trolling
[20:34] <JEEB> but I really can't say "They are bad people!" either
[20:34] <Compn> i'm not pointing fingers at anyone
[20:35] <JEEB> but yes, I do agree it's herp derp
[20:37] <Daemon404> [14:33] <@Compn> 5 people complaining, then writing own implementation, no one fixes it in ffmpeg <-- they probably tried
[20:37] <Daemon404> and then :swscale" hit them
[20:37] <Daemon404> it's super effective!
[20:37] <Compn> do or do not, there is no try
[20:37] <Daemon404> wat
[20:37] <Daemon404> thats a load of shit
[20:38] <Compn> star wars quote :P
[20:38] <Compn> haha
[20:38] Action: Daemon404 doesnt like star wars; thinks it's overrated tripe
[20:44] <durandal_1707> lol, libav adding bunch of YUVA formats - what a brainfuck
[21:05] <durandal_1707> there is myirad deinterleavers in libmpcodecs
[21:06] <ubitux> yes
[21:06] <ubitux> mplayer/mencoder has a lot of filters for ripping dvd
[21:10] <ubitux> again, it would be pretty nice if ffmpeg was able to do all the stuff mentioned here: http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-telecine.html
[21:11] <durandal_1707> is harddup filter useful?
[21:11] <Compn> if you want to duplicate frames, sure
[21:12] <Compn> i use it only because mencoder cant handle sync if its not used sometimes :P
[21:12] <durandal_1707> and ffmpeg does not have own functionality?
[21:12] <Compn> i havent a clue
[21:14] <gnafu> I know I have some DVDs that only turn out right if I use mencoder with pullup,softskip.
[21:14] <Compn> yeah, some players cant handle null frames
[21:14] <Compn> so a hard duplicate fixes such
[21:16] <gnafu> The copy of Akira I have will have interlacing artifacts in the encoded file if I don't use pullup to properly invtelecine it.  Only in certain scenes.
[21:18] <gnafu> And I would have to use harddup if I was passing raw video from it to, say, vpxenc.
[21:18] <gnafu> Because then vpxenc would have a fixed frame rate of 24000/1001 to match mencoder's 24000/1001.
[21:18] <gnafu> All very hairy, and it would be nice if the whole thing could be done with ffmpeg with good-looking results.
[21:19] <Compn> basically, we should completely ignore encoding dvds, because its impossible to get good results from them
[21:19] <Compn> focus on bluray and move into the future.
[21:20] <Compn> think theres a reason there is no universal dvd ripping program ?
[21:21] <gnafu> Well, I got good results when using mencoder ;D.
[21:22] <gnafu> But I agree, it will be nice as I start to buy more Blu-rays and get a BD-ROM drive.
[21:22] <JEEB> funny how I actually own blu-rays but still haven't grabbed a drive
[21:22] <gnafu> But when I want to encode for a mobile device that has less than DVD resolution anyway, why start with a Blu-ray if I already have an easier-to-rip DVD?
[21:22] <Compn> i dont own any bluray or drive, but got a free hd-dvd of blade runner :D
[21:23] <gnafu> Ooh, fun.
[21:23] <gnafu> I need to get that on Blu-ray.  I have the Final Cut DVD, and it is a very good-looking DVD, so I can only imagine how much better the Blu-ray must look.
[21:23] <JEEB> haha, I remember when suddenly all of those x360 hd-dvd drives went on extra sale right after toshiba announced their loss
[21:23] <Compn> gnafu : because you spend 10 hours manually getting a dvd to rip properly vs a bluray that is easier to rip?
[21:24] <gnafu> Compn: It only takes me a few minutes (if that) to figure out what mencoder settings I need, and then it's really fast.
[21:24] <JEEB> although then again even blu-ray is not perfect. You still have interlaced contents on some discs
[21:24] <gnafu> So many things they could have fixed and didn't :-(.
[21:25] <JEEB> that said, more bitrate and a bigger buffer is <3
[21:25] <JEEB> couldn't believe my eyes when I saw the bufsize for DVDs
[21:25] <Compn> gnafu : point taken . at least your dvd source doesnt change fps on you :)
[21:26] <Compn> encoding VFPS might also be good idea
[21:26] <gnafu> I've been under the impression that Blu-ray still letterboxes 2.35:1 content.  Is that correct?
[21:26] <gnafu> It's not fully anamorphic, right?
[21:26] <nevcairiel> its fixed resolution
[21:26] <gnafu> That was something they could have gotten right :-(.
[21:27] <nevcairiel> always comes with square pixels
[21:27] <nevcairiel> not sure why they didnt make that more dynamic
[21:27] <gnafu> Especially for people with projectors with anamorphic lenses, and these newer "21:9" TVs coming out, filling the whole 1920x1080 frame would have been great.
[21:28] <gnafu> Or, of course, specifying a higher resolution, like 2592x1080.
[21:28] <nevcairiel> Maybe they wouldnt want the image subject to some scaling algorithm
[21:29] <nevcairiel> HDMI doesnt carry an aspect ratio, so the bluray player has to scale the image to fit 1920x1080, not sure encoding it differently would've helped much
[21:29] <gnafu> In the anamorphic lens case, it would be scaled by the glass, with the 1920x1080 stretched image being reproduced pixel-for-pixel at the projector :-D.
[21:30] <gnafu> But I know, that's a very niche case.
[21:30] Action: gnafu doesn't have an anamorphic lens anyway.
[21:30] <gnafu> But I might someday!
[21:34] <gnafu> Oh, well.  Blu-ray is probably the last physical media format, with all future enhancements shifting to The Cloud".
[21:35] <nevcairiel> doubtful that media will be served in the cloud at that quality anytime soon
[21:36] <nevcairiel> a blu-ray is still quite large, even for todays internet speeds
[21:36] <gnafu> While I won't try to say it's equivalent or anything, I have been very impressed with Amazon's streaming video.  Their HD is only 720p, and probably 3-4Mbps at best, but I have yet to notice any glaring encoding artifacts or anything.  So while it's no Blu-ray replacement for those who care, it's certainly "good enough" for a lot of people.
[21:37] <gnafu> It seems to me a lot of people reencode Blu-rays using x264 to reduce the size quite a bit without noticeably reducing quality.  If only the whole world used x264, we could do Blu-ray-quality 1080p at well under 10Mbps ;D.
[21:38] <nevcairiel> yeah the commercial encoders used for those discs aren't always the best
[21:38] <gnafu> Anyway, we'll see how things go.  I agree with you that Blu-ray is superior, and I'm sure it will have a long and fruitful life, but you have to wonder if it will be the last of its kind.
[21:39] <gnafu> By the time Blu-ray becomes EOL, Internet speeds will be up, video bitrates will be down, and the movie industry will want to have an even tighter deathgrip than it does now.
[21:39] <nevcairiel> TVs are going 4K, maybe next year or the one after 4K will be the big thing in new TVs, but what good is it without content, so they will come up with something
[21:40] <gnafu> It is an exciting time to be alive, that's for sure :-).
[21:42] <Daemon404> pointresize those sd films
[21:42] <JEEB> reminds of certain blu-rays
[21:43] <JEEB> although you could argue that pointresizing that stuff is better than those warpsharpey things Sony and Q-Tec started using lately
[21:43] <nevcairiel> the really bad blu-rays usually are just terribly grainy, dont think i have seen one that had obvious scaling artifacts or anything like that
[21:44] <JEEB> some US live action BDs were pointresize/bilinear IIRC
[21:44] <JEEB> doom9 should have some threads from a year or two ago
[21:47] <gnafu> Where are we at with ripping Blu-rays anyway?  Is it to the point where you can rip pretty much any commercial Blu-ray using open source tools, or are is that a ways away?
[21:48] <JEEB> all of the ripping apps more or less depend on an oracle approach
[21:48] <JEEB> anydvd/blue monkey stuff
[21:48] <JEEB> there are open source tools too but those generally lack the keys
[21:49] <gnafu> But if you have keys, can both AACS and BD+ be overcome with open source tools, or just AACS?
[21:49] <JEEB> only AACS
[21:49] <gnafu> I was afraid of that.
[21:50] <nevcairiel> there is some hidden libbdplus somewhere in videolands backrooms
[21:50] <nevcairiel> not sure if it doesn anything useful
[21:50] <nevcairiel> videolans*
[21:51] <JEEB> it is getting along but not exactly ready for publication
[21:59] Action: gnafu is looking forward to that, as he only runs Linux at home and prefers to use open source software whenever possible.
[21:59] Action: gnafu would love to rip his Blu-rays as he buys them and play them over the network on his Raspberry Pi.
[21:59] <durandal_1707> ubitux: mark issues you own properly - New -> Bug
[22:00] <ubitux> do i still own issues?
[22:00] <JEEB> gnafu, blue monkey IIRC works over wine, and then there's that mkvwhatever that can also rip the folder structure as-is
[22:00] <JEEB> latter has an actual linux binary
[22:02] <durandal_1707> ubitux: yes
[22:02] <ubitux> durandal_1707: can you give me a reference or something?
[22:02] <durandal_1707> srtdec
[22:04] <ubitux> ah that was the reason it was still in the list
[22:04] <gnafu> JEEB: When the day comes, I will have to try those.  Thanks.
[22:04] <ubitux> i though a "submitted fix" was enough
[22:04] <ubitux> i updated them
[22:06] <gnafu> JEEB: And I believe you're referring to MakeMKV.
[22:07] <JEEB> gnafu, yeah
[22:07] <JEEB> it does have a mode that just decrypts though
[22:07] <JEEB> instead of remuxing to matroska
[22:08] <gnafu> That's good to know.  That's probably what I'd want in most (or all) cases.
[23:18] <cone-965> ffmpeg.git 03Clément BSsch 07eb36ee1ee11c: lavc/srtenc: fix invalid read in case of SubRip.
[23:18] <cone-965> ffmpeg.git 03Clément BSsch 075f0105b820fa: lavf/srtenc: allow zero duration events.
[00:00] --- Sat Oct 27 2012