[00:34] <philipl> ubitux: So, ignoring the lace_duration thing, do you think it's reasonable? [00:35] <ubitux> well in theory it looks good yes, but i didn't test the patch [00:36] <ubitux> i'm assuming you fixed the 2-spaces indent block too :p [00:39] <philipl> Sure. :-) [00:40] <ubitux> philipl: do you have any downside relevant to that patch btw? [00:41] <philipl> So, if there's no stupid timebase, then there's no downside for sure. [00:42] <philipl> If there is a stupid time base, then the difference in behaviour is duration will be the overflowed value instead of zero. [00:42] <philipl> That may or may not be considered a downside, but neither is correct. [00:42] <ubitux> do you plan to add some pts rescaling? [00:43] <philipl> I'd like to try and do it eventually, but at a glance it's going to hurt my brain, trying to keep all the different pieces of the matroska time scale straight. [00:44] <ubitux> i'm not sure that's the role of the demuxer, but in that case doing the rescale to 1/1000 for subtitles in any case sound appropriate [00:44] <ubitux> ok [00:44] <ubitux> it would be interesting to get some samples with these insane tb [00:44] <philipl> yeah, maybe we restrict it to subtitles only, but that may end up being harder to deal with. [00:44] <philipl> I'm sure mkvmerge can generate them. [00:48] <ubitux> philipl: what about first checking for the insane tb and set only duration64 if so? [00:48] <ubitux> so no rescale atm but no breakage? [00:48] <philipl> ubitux: Yeah, so no rescale in the short term, but no breakage of cases that worked before. [00:48] <ubitux> i'm a bit worried about how much samples with creepy subtitles tb there are in the wild [00:48] <philipl> ubitux: we could do such a check, but it doesn't really buy anything. [00:49] <philipl> Those samples will continue to work correctly in every scenario where they worked before. [00:49] <philipl> (ie: extract to srt and playing with mplayer. Pretty much everything else would be busted) [00:50] <philipl> ubitux: oh, and the reason not to do a check is if there's any clients that only read convergence_duration. You'd break them if you stopped always writing it. [00:51] <ubitux> i meant not writing in duration but only duration64 if necessary [00:51] <ubitux> so duration64 get used when broken [00:52] <ubitux> if the tb is stupid, mplayer isn't able to handle properly the timing? [00:52] <ubitux> if the tb is stupid, duration64 still makes sense no? [00:53] <ubitux> sorry if i'm a bit confused again [00:56] <philipl> So, you mean if the tb is stupid, don't write the normal duration, and leave it at zero? [00:57] <philipl> Ok, yeah, I can do that. It would mean the broken case would stay broken in the same way. [00:57] <ubitux> yeah or any marker that will make the api user aware that it should use the convergence_duration [00:58] <ubitux> note that we use a negative duration to notice the "last until the next sub" [00:58] <ubitux> -1 to be more specific [00:58] <philipl> Well, I don't want to endorse this mechanism anymore than it's already used. [00:58] <philipl> So I'd rather not introduce a formal marker. Just keep the existing de facto behaviour [00:59] <ubitux> do what you think is the best, you have a good understanding of the problem [00:59] <philipl> Ok. Thanks for the thoughts. [00:59] <ubitux> but it would be nice if you wouldn't stop now and do the proper rescale at some point ;) [01:00] <philipl> No, I won't give up. I'll do the rescale. I just didn't want to leave the normal case broken when there's a quick fix for that. [01:00] <ubitux> sure :) [01:10] <CIA-56> ffmpeg: 03Andrey Utkin 07master * r7870722592 10ffmpeg/libavformat/ (avio.c url.h): [01:10] <CIA-56> ffmpeg: Add 'rw_timeout' into URLContext [01:10] <CIA-56> ffmpeg: If set non-zero, limits duration of retry_transfer_wrapper() loop, thus [01:10] <CIA-56> ffmpeg: affects ffurl_read*(), ffurl_write() [01:10] <CIA-56> ffmpeg: Measured in microseconds. [01:10] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni@gmx.at> [01:10] <CIA-56> ffmpeg: 03Andrey Utkin 07master * r028b6d2b5c 10ffmpeg/ (doc/protocols.texi libavformat/udp.c): [01:10] <CIA-56> ffmpeg: Add 'timeout' option to UDP protocol [01:10] <CIA-56> ffmpeg: This patch accepts 'timeout' option for input mode only. As far as i know, UDP output cannot introduce delays. [01:10] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni@gmx.at> [03:02] <llogan> has something changed to make mjpg encoder ignore q:v? http://pastebin.com/yyUWCHhS [03:04] <Daemon404> have you tried to add -flags +qscale [03:04] <llogan> no change. [03:08] <llogan> works in 0.11.1 apparently. [03:08] <llogan> i mean my original command [04:31] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * r2d5c80b2e8 10ffmpeg/libavcodec/frame_thread_encoder.c: [04:31] <CIA-56> ffmpeg: frame_thread_encoder: pass frame pict type and quality [04:31] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni@gmx.at> [04:31] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * r097a909ea1 10ffmpeg/libavcodec/ (frame_thread_encoder.c frame_thread_encoder.h utils.c): [04:31] <CIA-56> ffmpeg: frame_thread_encoder: pass private options [04:31] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni@gmx.at> [06:14] <philipl> ubitux: I posted an updated diff that tries to be cleverer. It checks for overflow and doesn't write the regular duration in that case. [06:15] <philipl> I also checked and mkvmerge doesn't let you go below 1us for the time base, so I suspect there are no crazy files in the wild. [07:38] <nevcairiel> I think the conditions in that block are weird. The first part of the if checks for codec_id == Subrip, and the second part checks for type != subtitle, so what happens to all other subtitles? [11:35] <CIA-56> ffmpeg: 03Paul B Mahol 07master * re4fff08f5b 10ffmpeg/libavcodec/exr.c: [11:35] <CIA-56> ffmpeg: exr: fix decoding ZIP16 and height not multiple of 16 [11:35] <CIA-56> ffmpeg: Signed-off-by: Paul B Mahol <onemda@gmail.com> [11:37] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * r85c830331c 10ffmpeg/libavcodec/utils.c: [11:37] <CIA-56> ffmpeg: lavc: protect calls to frame_thread_encoder by HAVE_THREADS [11:37] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni@gmx.at> [18:09] <CIA-56> ffmpeg: 03Martin Storsjö 07master * r0b58c77ed1 10ffmpeg/libavcodec/audio_frame_queue.c: [18:09] <CIA-56> ffmpeg: audio_frame_queue: Define af_queue_log_state before using it [18:09] <CIA-56> ffmpeg: This fixes building with DEBUG defined after the function was made [18:09] <CIA-56> ffmpeg: static and the prototype removed in d7f9786cbc. [18:09] <CIA-56> ffmpeg: Signed-off-by: Martin Storsjö <martin@martin.st> [18:09] <CIA-56> ffmpeg: 03Martin Storsjö 07master * r6f5b1a2ba4 10ffmpeg/libavcodec/h264.c: [18:09] <CIA-56> ffmpeg: h264: Check that the codec isn't null before accessing it [18:09] <CIA-56> ffmpeg: This fixes crashes introduced by 2e8f3cbcda5, the codec can be null [18:09] <CIA-56> ffmpeg: when called from parsers. [18:09] <CIA-56> ffmpeg: Signed-off-by: Martin Storsjö <martin@martin.st> [18:09] <CIA-56> ffmpeg: 03Diego Biurrun 07master * refbd04c332 10ffmpeg/libavcodec/x86/ (Makefile dct32_sse.asm imdct36_sse.asm): x86: avcodec: Drop silly "_sse" suffixes from filenames [18:09] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * r6d35470063 10ffmpeg/ (13 files in 2 dirs): [18:09] <CIA-56> ffmpeg: utvideoenc: use ff_huff_gen_len_table [18:09] <CIA-56> ffmpeg: Avoid code duplication and provide faster and better compression. [18:09] <CIA-56> ffmpeg: Signed-off-by: Luca Barbato <lu_zero@gentoo.org> [18:09] <CIA-56> ffmpeg: 03Martin Storsjö 07master * r06b5246c84 10ffmpeg/libavformat/sdp.c: [18:09] <CIA-56> ffmpeg: sdp: Include profile-level-id for H264 [18:09] <CIA-56> ffmpeg: This is required for playback with the Stagefright RTSP framework [18:09] <CIA-56> ffmpeg: on Android. [18:09] <CIA-56> ffmpeg: Signed-off-by: Martin Storsjö <martin@martin.st> [18:09] <CIA-56> ffmpeg: 03Martin Storsjö 07master * rdd4169ab92 10ffmpeg/tools/qt-faststart.c: [18:09] <CIA-56> ffmpeg: qt-faststart: Use other seek/tell functions on MSVC than on mingw [18:09] <CIA-56> ffmpeg: Signed-off-by: Martin Storsjö <martin@martin.st> [18:09] <CIA-56> ffmpeg: 03Diego Biurrun 07master * rbcc45d6348 10ffmpeg/libavcodec/x86/ (11 files): x86: avcodec: Drop silly "_mmx" suffixes from filenames [18:09] <CIA-56> ffmpeg: 03Martin Storsjö 07master * r212ec5faf9 10ffmpeg/tools/ (cws2fws.c pktdumper.c): [18:10] <CIA-56> ffmpeg: huffman: add ff_huff_gen_len_table [18:10] <CIA-56> ffmpeg: The function will be used by utvideo as well. [18:10] <CIA-56> ffmpeg: Signed-off-by: Luca Barbato <lu_zero@gentoo.org> [18:10] <CIA-56> ffmpeg: 03Martin Storsjö 07master * rd4bba93f4d 10ffmpeg/libavformat/sdp.c: [18:10] <CIA-56> ffmpeg: sdp: Use static const char arrays instead of pointers to strings [18:10] <CIA-56> ffmpeg: Signed-off-by: Martin Storsjö <martin@martin.st> [18:10] <CIA-56> ffmpeg: 03Samuel Pitoiset 07master * r6af2480aa6 10ffmpeg/libavformat/rtpdec_h264.c: [18:10] <CIA-56> ffmpeg: rtpdec_h264: Don't set the pixel format [18:10] <CIA-56> ffmpeg: There is no need for this depacketizer to set the pixel format, [18:10] <CIA-56> ffmpeg: the decoder can do that just fine. [18:10] <CIA-56> ffmpeg: Signed-off-by: Martin Storsjö <martin@martin.st> [18:10] <CIA-56> ffmpeg: 03Martin Storsjö 07master * r3ad9eac5a0 10ffmpeg/ (libavcodec/motion-test.c libswscale/colorspace-test.c): [18:10] <CIA-56> ffmpeg: testprogs: Remove unused includes [18:10] <CIA-56> ffmpeg: Signed-off-by: Martin Storsjö <martin@martin.st> [18:10] <CIA-56> ffmpeg: 03Ronald S. Bultje 07master * rb64a72e1b2 10ffmpeg/libswscale/yuv2rgb.c: [18:10] <CIA-56> ffmpeg: yuv2rgb: handle line widths that are not a multiple of 4. [18:10] <CIA-56> ffmpeg: This introduces support for width%4==2 in addition to width%4==0. For [18:10] <CIA-56> ffmpeg: odd widths, some more checks are needed, since the current code always [18:10] <CIA-56> ffmpeg: handles two luma items in a row, thus there is a possibility of an [18:10] <CIA-56> ffmpeg: overread by one. [18:10] <CIA-56> ffmpeg: 03Martin Storsjö 07master * r09d5e02ab0 10ffmpeg/tools/graph2dot.c: [18:10] <CIA-56> (12 lines omitted) [18:16] <CIA-56> ffmpeg: 03Diego Biurrun 07master * rd39791bf39 10ffmpeg/libavcodec/x86/ (mpegvideoenc.c mpegvideoenc_template.c): [18:16] <CIA-56> ffmpeg: x86: mpegvideoenc: Do not abuse HAVE_ variables for template instantiation [18:16] <CIA-56> ffmpeg: This avoids trouble if HAVE_ variables are used elsewhere in the file. [18:16] <CIA-56> ffmpeg: 03Diego Biurrun 07master * r2f2aa2e542 10ffmpeg/libavcodec/x86/mpegvideoenc.c: [18:16] <CIA-56> ffmpeg: x86: mpegvideoenc: fix linking with --disable-mmx [18:16] <CIA-56> ffmpeg: The optimized dct_quantize template functions reference optimized [18:16] <CIA-56> ffmpeg: fdct symbols, so these functions must only be enabled if the relevant [18:16] <CIA-56> ffmpeg: optimizations have been enabled by configure. [18:16] <CIA-56> ffmpeg: 03Mans Rullgard 07master * r095792f253 10ffmpeg/ (Makefile common.mak configure): [18:16] <CIA-56> ffmpeg: build: add separate setting for host linker [18:16] <CIA-56> ffmpeg: This adds new HOSTLD and related settings for host linker allowing [18:16] <CIA-56> ffmpeg: it to be different from HOSTCC. [18:16] <CIA-56> ffmpeg: Signed-off-by: Mans Rullgard <mans@mansr.com> [18:16] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * r8579d4b2f0 10ffmpeg/: (log message trimmed) [18:16] <CIA-56> ffmpeg: Merge remote-tracking branch 'qatar/master' [18:16] <CIA-56> ffmpeg: * qatar/master: [18:16] <CIA-56> ffmpeg: build: export filtered -lz flag in config.mak [18:16] <CIA-56> ffmpeg: build: add separate setting for host linker [18:16] <CIA-56> ffmpeg: configure: probe_cc: use separate variable for linker output flag [18:16] <CIA-56> ffmpeg: x86: Always compile files with functions that are called unconditionally [18:16] <CIA-56> ffmpeg: 03Diego Biurrun 07master * r2e6f93a284 10ffmpeg/libavcodec/x86/Makefile: x86: Always compile files with functions that are called unconditionally [18:16] <CIA-56> ffmpeg: 03Mans Rullgard 07master * r7baa115a33 10ffmpeg/ (Makefile configure): [18:16] <CIA-56> ffmpeg: build: export filtered -lz flag in config.mak [18:16] <CIA-56> ffmpeg: This is needed to link tools/cws2fws using a linker with non-standard [18:16] <CIA-56> ffmpeg: command line syntax. [18:17] <CIA-56> ffmpeg: 03Mans Rullgard 07master * r2763587c83 10ffmpeg/configure: [18:17] <CIA-56> ffmpeg: configure: probe_cc: use separate variable for linker output flag [18:17] <CIA-56> ffmpeg: Some tools use different command line syntax for specifying output [18:17] <CIA-56> ffmpeg: when compiling and linking. To accomodate these, separate variables [18:17] <CIA-56> ffmpeg: must be used. No currently supported compilers/linkers are affected [18:17] <CIA-56> ffmpeg: by the change. [18:17] <CIA-56> ffmpeg: Signed-off-by: Mans Rullgard <mans@mansr.com> [18:18] <CIA-56> ffmpeg: 03Philip Langdale 07master * r7816c7e772 10ffmpeg/libavcodec/codec_desc.c: [18:18] <CIA-56> ffmpeg: Add missing codec descriptor for timingless subrip. [18:18] <CIA-56> ffmpeg: Signed-off-by: Philip Langdale <philipl@overt.org> [18:26] <CIA-56> ffmpeg: 03Nicolas George 07master * ra5704659e3 10ffmpeg/libavfilter/af_atempo.c: [18:26] <CIA-56> ffmpeg: lavfi/af_atempo: use av_malloc for rDFT buffers. [18:26] <CIA-56> ffmpeg: Memory obtained from av_realloc is not aligned enough for AVX. [18:26] <CIA-56> ffmpeg: The other similar allocations are changed too because they use [18:26] <CIA-56> ffmpeg: the same macro. The buffers were cleared afterwards anyway. [18:26] <CIA-56> ffmpeg: Fix trac ticket #1692. [19:02] <CIA-56> ffmpeg: 03Ramiro Polla 07master * rad7fae4ee1 10ffmpeg/ (doc/indevs.texi libavdevice/dshow.c): [19:02] <CIA-56> ffmpeg: dshow: allow user to specify audio buffer size [19:02] <CIA-56> ffmpeg: Based on patch by rogerdpack <rogerpack2005@gmail.com> [19:02] <CIA-56> ffmpeg: Tested-by: Roger Pack <rogerdpack2@gmail.com> [19:02] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni@gmx.at> [19:26] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * r818f3dc907 10ffmpeg/libavcodec/audio_frame_queue.c: [19:26] <CIA-56> ffmpeg: audio_frame_que: remove broken code that is specific to old audio_que [19:26] <CIA-56> ffmpeg: This should fix compilation with -DDEBUG [19:26] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni@gmx.at> [20:38] <philipl> ubitux: Hi. [20:38] <ubitux> hey philipl :) [20:39] <ubitux> 07:38:49 < nevcairiel> I think the conditions in that block are weird. The first part of the if checks for codec_id == Subrip, and the second part checks for type != subtitle, so what happens to all other subtitles? [20:39] <ubitux> did you see that? [20:39] <philipl> No. [20:39] <philipl> What's the context? [20:39] <philipl> Discussing the original logic? [20:39] <ubitux> not long after you left saying stuff about your updated diff [20:40] <ubitux> (there is nothing else) [20:40] <philipl> I think the punch line is that there are three types of valid subtitles in mkv: subrip, ass and vobsub. Both ass and vobsub use inband timing. [20:40] <philipl> so it doesn't set duration for any of them. [20:41] <philipl> (or rather, for ass the demuxer restores the inband timing) [20:41] <ubitux> i didn't look at the updated patch yet [20:41] <philipl> Anyway, the updated diff does a check against UINT_MAX to decide whether its safe to set the normal duration. [20:41] <ubitux> why unsigned? [20:41] Action: Daemon404 wonders why nevcairiel cares [20:41] <ubitux> isn't duration signed? [20:42] <philipl> urp. [20:42] <Daemon404> he doesnt use lavf's mkv stuff anyway [20:42] <philipl> ubitux: you're right. its signed. [20:43] <philipl> So INT_MAX then :-) [20:44] <philipl> And at this point I'm pretty sure there's no tool to create a stupid mkv. ffmpeg only allows 1ms time_base and mkvmerge won't go below 1us. [20:46] <philipl> and handbrake uses 90ms... [20:46] <philipl> Someone really needs to explain that to me... [20:47] <Daemon404> 90ms.l.. what? [20:47] <Daemon404> 90ms precision? [20:47] <philipl> Sorry, (1/90)ms [20:47] <Daemon404> oh [20:47] <ubitux> mpeg related? [20:47] <philipl> I guess. [20:47] <kierank> yes [20:47] <kierank> definitely [20:47] <ubitux> 1/90000 reminds me of mpeg tb [20:47] <Daemon404> i know my gf complained that stuff transcoded with handbrake had horribly tiemd subtitles [20:47] <Daemon404> when the input didnt [20:47] <philipl> now you know why. [20:48] <philipl> It made my testing miserable. I was desperately trying to understand why the timing kept changing on my transcodes. [20:49] <Daemon404> http://pastebin.com/raw.php?i=QhqbiW7N [20:49] <Daemon404> @ Rodeo_ [20:50] <Rodeo> oh, OK [20:51] <Rodeo> j45 may be more familiar with why we use that timebase etc. [20:51] <kierank> Daemon404: subtitles need to be displayed with a precision greater than 1/90000ms? [20:51] <kierank> wow [20:51] <kierank> that's madness [20:51] <Daemon404> kierank, no [20:51] <Daemon404> but its doing -something- wrong [20:51] <Daemon404> when converting [20:51] <kierank> 1/90ms i mean [20:51] <Rodeo> but basically, we use a 90 kHz timebase internally [20:52] <Daemon404> kierank, generally will only need 42ms or 33ms [20:52] <Daemon404> but its borking timings somehow [20:52] <philipl> It's compounded rounding errors. [20:52] <Daemon404> possible [20:53] <kierank> if you use the timebase conversion functions in libavutil you should be fine [20:53] <philipl> doesn't seem to work out that way in practice. [20:54] <philipl> there's also the annoyance of ass having a 10ms timebase and all subtitle conversion must go through it. [20:58] <Compn> why not fix libass then ? [20:59] <Compn> stupid question, i have to ask [20:59] <Daemon404> its not a libass problem [20:59] <Compn> oh, ass itself ? [21:00] <Daemon404> no [21:00] <Daemon404> its handbrake. [21:00] Action: Compn looks to see what channel hes in [21:00] <philipl> two topics here :-) [21:00] <philipl> the ass timebase is in the ass spec. [21:01] <Rodeo> hmm, OK, so this timestamp issue is ASS-specific? [21:01] <Rodeo> (in addition to being HandBrake-specific?) [21:01] <philipl> There's a lot of moving parts :-) [21:02] <philipl> If I want to convert a handbrake produced mkv to, say mp4, then it goes 1/90000 -> ? -> 1/100 (ass) -> 1/1000 [21:02] <philipl> The ? may or may not exist. :-P [21:03] <philipl> Let me start again. [21:03] <philipl> if the original subtitle is srt then: [21:03] <philipl> 1/9000 -> 1/1000 -> 1/100 -> 1/1000. [21:03] <philipl> 1/90000 [21:03] <philipl> anyway - the ass thing in the middle is annoying, but honestly doesn't explain the weird divergences. [21:04] <Rodeo> well, if it's SRT, it doesn't start at 1/90000, does it? [21:04] <philipl> In mkv it does. the timestamps are moved to the container. [21:04] <Daemon404> philipl, ive seen handbrake be many frames off [21:04] <Rodeo> ah, OK [21:04] <Daemon404> it cant just be rounding errors. [21:04] <philipl> Hmm. I haven't seen that. My issue is stuff like: [21:05] <philipl> Original: 00:00:03,056 --> 00:00:04,740 Transcoded: 00:00:03,056 --> 00:00:04,736 [21:05] <philipl> I can't explain that. [21:05] <Daemon404> maybe it is trying to be 'smart; [21:05] <Daemon404> and snap to frames [21:05] <Rodeo> I don't think so, but I'm not terribly familiar with that part of the code [21:06] <Rodeo> j45 would be the one to talk to [21:06] <philipl> Oh, in my example 'original' is the handbrake output. [21:06] <Rodeo> (he'll be at VDD, FWIW) [21:06] <Rodeo> OK [21:06] <Rodeo> and transcoded is? [21:06] <philipl> ffmpeg [21:06] <Rodeo> OK [21:07] <Compn> stupid question #2 [21:07] <Compn> why arent you extracting subs, and remuxing them later using real tools ? [21:08] <philipl> I'd like to do a one pass transcode with ffmpeg. That's why I've been having all this fun with mp4 subtitles :-) [21:10] <Rodeo> Daemon404: so in your case HandBrake was several frames off when it came to video/subtitle sync? [21:11] <Daemon404> subtitles were out of sync with video and audio [21:11] <Daemon404> (hardcoded i may add) [21:11] <Daemon404> [15:07] <@Compn> why arent you extracting subs, and remuxing them later using real tools ? <-- because my girlfriend is not a techie [21:11] <Daemon404> she just wants a tool to transcode stuff for her ipad [21:11] <saste> j-b, ubitux: who will attend VDD from the ff* side this year? [21:11] <Rodeo> do you still have a test case? [21:12] <Daemon404> Rodeo, ill check tonight [21:12] <Rodeo> we'd love to see a good bug report, if there's a bug [21:12] <Daemon404> saste, im attending from "both sides" if it counts [21:12] <Daemon404> ubitux is... [21:12] <Rodeo> we handle bug reports through our forum, usually: https://forum.handbrake.fr/viewforum.php?f=12 [21:12] Action: beastd will be there too [21:12] <Rodeo> though #handbrake would work too [21:13] <Daemon404> no trac> [21:13] <Daemon404> ? [21:13] <Rodeo> we actually have track, but we don't allow public registration [21:13] <Rodeo> not sure why, but TBH I don't care much [21:13] Action: ubitux hi5 beastd [21:14] <ubitux> saste: dunno who else will come [21:17] Action: beastd does a passive hi5 against ubitux [21:17] <ubitux> :) [21:25] <j-b> saste: ubitux, Daemon404, dilaroga, nicolas, beastd and people in the middle like vitor or merbanan [21:25] <ubitux> oh nicolas george will be there? [21:25] <j-b> Yes [21:25] <Daemon404> j-b, in in the middle as well. [21:25] <ubitux> nice [21:25] <Daemon404> ;p [21:25] <j-b> saste: so, well, a bit more than expected, I will miss you [21:25] <Daemon404> im not sure who dilaroga is [21:26] <j-b> and I will miss Compn and michaelni, but well [21:26] <saste> time to get a ffdd in Wien? [21:27] <j-b> organizing Dev Days is fucking tiring [21:27] <Compn> i should go [21:28] <Compn> just getting tired of flying [21:28] <j-b> but this year, we will have VLC, x264, x262, libav, handbrake, xiph, mozilla, google, amd, intel, libbluray, mplayer, xine [21:29] <Daemon404> wasnt there also dvblast [21:29] <j-b> and lighttpd and tomahawk [21:29] <j-b> and dvblast [21:29] <Daemon404> wat [21:29] <Daemon404> lighttpd? [21:29] <j-b> yep [21:29] <Daemon404> O.o [21:29] <Compn> that lighttpd dude hangs around [21:29] Action: Compn forgets name [21:29] <j-b> so, quite a bit of people [21:29] <Daemon404> 2x vimeo, but thats also libav/ffmpeg [21:30] <j-b> vimeo are bad people :'( [21:30] <Daemon404> ohlol what did we do? [21:30] <Compn> spaam is a lighttpd guy [21:31] <Daemon404> j-b, cant tell if troll or not so -- :V [21:32] <beastd> Interesting, didn't know that spaam is a lighttpd guy. [21:32] <j-b> moogaloop... [21:32] <Daemon404> j-b, the player? [21:32] <Daemon404> not my area, but.. why is it bad? [21:32] <j-b> the page change [21:32] <Daemon404> ? [21:33] <j-b> http://git.videolan.org/?p=vlc.git;a=blob;f=share/lua/playlist/vimeo.lua;hb=... [21:33] <Daemon404> o [21:33] <Daemon404> um [21:33] <Daemon404> why dont you just use the api [21:33] <j-b> because the API does not allow open source applications. [21:33] <Daemon404> brb asking someone [21:36] <Daemon404> right [21:36] <Daemon404> secret keys [21:36] <Daemon404> gpl problems [21:36] <Daemon404> etc [21:36] <j-b> exactly [21:36] <Daemon404> same would go for most apis [21:36] <Daemon404> id guess [21:36] <Daemon404> (github) [21:48] <Daemon404> well i found out why we block teh VLC useragent... lol [21:49] <Compn> when is vdd ? :P [21:49] <Daemon404> 2 days [21:49] <Compn> ah haha [22:57] <llogan> saste: RE: decimate filter: "unregarding" sounds weird. </nit> [22:58] <saste> llogan: suggestions? [22:58] <saste> disregarding [22:58] <llogan> yeah, that's better. [23:10] <retrosnub> could someone take a look at the patch in ticket #1537 ? [23:13] <nitlord> retrosnub: would it be possible for you to send the patch to the ffmpeg-devel mailing list? it will get more attention there. [23:14] <nitlord> ...and easier to make inline comments. [23:15] <retrosnub> ok [23:34] <saste> michaelni: is it expected, that AVFrame.display_picture_number is almost always set to 0? [23:34] <saste> only a few codecs seem to make use of it [23:41] <michaelni> saste, well yes [23:42] <michaelni> its not used by much ... [23:43] <saste> because I was thinking to expose it in ffprobe [23:43] <saste> but right now it is not that much useful [23:45] <LordRPI> Hey guys, stoopid n00b question. In the h264 code (decode_mb_cabac), I'm not sure what the contruct IS_DIR() means and it's affect on why it's needed with a different parameter for the ref into fill_rectangle [23:45] <LordRPI> http://pastebin.ca/2199200 <- for reference [23:46] <LordRPI> any help clarifying this for me would be greatly appreciated [23:47] <Skyler> if the mb type uses that motion vector list (L0 or L1) [23:48] <LordRPI> thanks [23:58] <saste> next one will be "resampling.c" [00:00] --- Thu Aug 30 2012