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

[burek]

[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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at gmail.com>
[19:02] <CIA-56> ffmpeg: Tested-by: Roger Pack <rogerdpack2 at gmail.com>
[19:02] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at 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 at 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=HEAD
[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