[00:58] <CIA-108> ffmpeg: 03Mans Rullgard 07master * raac46e088d 10ffmpeg/libavcodec/ (Makefile aacsbr.c aacsbrdata.h sbr.h sbrdsp.c sbrdsp.h): [00:58] <CIA-108> ffmpeg: aacsbr: move some simdable loops to function pointers [00:58] <CIA-108> ffmpeg: This prepares for assembly optimisations by moving the most [00:58] <CIA-108> ffmpeg: time-consuming loops to functions called through pointers [00:58] <CIA-108> ffmpeg: in a new context. [00:58] <CIA-108> ffmpeg: Signed-off-by: Mans Rullgard <mans@mansr.com> [00:58] <CIA-108> ffmpeg: 03Mans Rullgard 07master * r8996ed2b73 10ffmpeg/libavcodec/ (aacsbr.c aacsbrdata.h sbr.h): [00:58] <CIA-108> ffmpeg: aacsbr: align some arrays [00:58] <CIA-108> ffmpeg: Signed-off-by: Mans Rullgard <mans@mansr.com> [00:58] <CIA-108> ffmpeg: 03Alex Converse 07master * r7181c4edee 10ffmpeg/ (91 files in 6 dirs): cosmetics: Remove extra newlines at EOF [00:58] <CIA-108> ffmpeg: 03Mans Rullgard 07master * rbe822d77b6 10ffmpeg/libavcodec/ (5 files in 2 dirs): [00:58] <CIA-108> ffmpeg: aacsbr: ARM NEON optimised sbrdsp functions [00:58] <CIA-108> ffmpeg: Overall speedup of HE-AAC decoding 2.3x on Cortex-A8, 1.2x on A9. [00:58] <CIA-108> ffmpeg: Signed-off-by: Mans Rullgard <mans@mansr.com> [00:58] <CIA-108> ffmpeg: 03Anton Khirnov 07master * r2d9535ad31 10ffmpeg/libavcodec/utils.c: [00:58] <CIA-108> ffmpeg: avcodec_align_dimensions2: set only 4 linesizes, not AV_NUM_DATA_POINTERS. [00:58] <CIA-108> ffmpeg: This function is video-only, so there's no point in setting more [00:58] <CIA-108> ffmpeg: linesizes. [00:58] <CIA-108> ffmpeg: Fixes stack corruption in avplay. [00:58] <CIA-108> ffmpeg: 03Anton Khirnov 07master * r44911f2985 10ffmpeg/doc/APIchanges: [00:59] <CIA-108> ffmpeg: There was no minor bump for making avcodec_alloc_context3() public and [00:59] <CIA-108> ffmpeg: deprecating the other two, so I'm using the first next lavc bump. [00:59] <CIA-108> ffmpeg: 03Anton Khirnov 07master * r9bfe218299 10ffmpeg/libavcodec/avcodec.h: lavc: extend doxy for avcodec_alloc_context3(). [00:59] <CIA-108> ffmpeg: 03Anton Khirnov 07master * r91b3bfba88 10ffmpeg/avplay.c: [00:59] <CIA-108> ffmpeg: avplay: use the correct array size for stride. [00:59] <CIA-108> ffmpeg: AV_NUM_DATA_POINTERS instead of 4. [00:59] <CIA-108> ffmpeg: 03Nathan Caldwell 07master * r2e626dd513 10ffmpeg/libavcodec/aacenc.c: [00:59] <CIA-108> ffmpeg: aacenc: Fix LONG_START windowing. [00:59] <CIA-108> ffmpeg: Forgot to add the equivalent amount to the incoming sample pointer as the output pointer. [00:59] <CIA-108> ffmpeg: Signed-off-by: Anton Khirnov <anton@khirnov.net> [01:00] <CIA-108> ffmpeg: 03Michael Niedermayer 07master * rc065255bba 10ffmpeg/: (log message trimmed) [01:00] <CIA-108> ffmpeg: Merge remote-tracking branch 'qatar/master' [01:00] <CIA-108> ffmpeg: * qatar/master: [01:00] <CIA-108> ffmpeg: aacenc: Fix LONG_START windowing. [01:00] <CIA-108> ffmpeg: aacenc: Fix a bug where deinterleaved samples were stored in the wrong place. [01:00] <CIA-108> ffmpeg: avplay: use the correct array size for stride. [01:00] <CIA-108> ffmpeg: lavc: extend doxy for avcodec_alloc_context3(). [01:00] <CIA-108> ffmpeg: 03Nathan Caldwell 07master * rdc7e7d4dd9 10ffmpeg/libavcodec/aacenc.c: [01:00] <CIA-108> ffmpeg: aacenc: Fix a bug where deinterleaved samples were stored in the wrong place. [01:00] <CIA-108> ffmpeg: 10l: Forgot to adjust deinterleave for new location of incoming samples in 7946a5a. [01:00] <CIA-108> ffmpeg: This produced incorrect, but surprisingly listenable results. [01:01] <CIA-108> (2 lines omitted) [02:18] <durandal_1707> some headers still heave deprecated stuff which is pointless because required code is gone [02:53] <CIA-108> ffmpeg: 03Paul B Mahol 07master * rcbf1dc4eb4 10ffmpeg/tests/ (codec-regression.sh ref/vsynth1/y41p ref/vsynth2/y41p): [02:53] <CIA-108> ffmpeg: fate: add Y41P encoding/decoding test [02:53] <CIA-108> ffmpeg: Signed-off-by: Paul B Mahol <onemda@gmail.com> [02:53] <CIA-108> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni@gmx.at> [02:53] <CIA-108> ffmpeg: 03Paul B Mahol 07master * r6bcc8275a1 10ffmpeg/libavcodec/r210enc.c: [02:53] <CIA-108> ffmpeg: r210enc: fix encoding for unaligned widths [02:53] <CIA-108> ffmpeg: Signed-off-by: Paul B Mahol <onemda@gmail.com> [02:53] <CIA-108> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni@gmx.at> [02:53] <CIA-108> ffmpeg: 03Paul B Mahol 07master * r931ec4a2f6 10ffmpeg/tests/ (codec-regression.sh ref/vsynth1/r210 ref/vsynth2/r210): [02:53] <CIA-108> ffmpeg: fate: add R210 encoding/decoding test [02:53] <CIA-108> ffmpeg: Signed-off-by: Paul B Mahol <onemda@gmail.com> [02:53] <CIA-108> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni@gmx.at> [03:31] <durandal_1707> hmm r210 fails on bigendian [03:32] <durandal_1707> probably because test needs explicit rgb48le? [03:39] <CIA-108> ffmpeg: 03Paul B Mahol 07master * r9719528e05 10ffmpeg/tests/codec-regression.sh: [03:39] <CIA-108> ffmpeg: fate: fix r210 test on big endian [03:39] <CIA-108> ffmpeg: Signed-off-by: Paul B Mahol <onemda@gmail.com> [03:39] <CIA-108> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni@gmx.at> [07:20] <funman> FYI doc/APIchanges is broken http://git.videolan.org/?p=vlc.git;a=commitdiff;h=5b55c4dbab0ee2700300f9d8b7... [07:59] <michaelni> funman, never trust APIchanges [08:00] <michaelni> noone is maintaining it sadly [08:01] <michaelni> always use git log / git blame to find at which revission things where introduced [08:04] <funman> i found e.g. that commit 526604545fb1cc0c11af356fbffd5cddf8cdc95f introduced it [08:04] <funman> but git describe fails on it [08:04] <funman> and git describe --tags says nothing useful [08:10] <funman> in vlc or rockbox i see e.g. 1.3.0-git-895-g4ca6ef0 [08:10] <funman> last tag - number of commits since -gHASH [08:11] <nevcairiel> the non-linear history because of all the merges terribly confuses git describe [08:12] <funman> it confused me as well :/ [08:13] <funman> write to lkml and suggest to Linus that his tool sucks [08:14] <funman> hop, fixed in 2 days =) [08:39] <michaelni> funman, try: [08:39] <michaelni> git describe --tags --match N `git rev-list 52660454..HEAD --ancestry-path --merges | tail -1` [08:39] <michaelni> dunno if theres a easier way ... [08:40] <michaelni> s/HEAD/master/ probably [08:42] <funman> nope [09:16] <michaelni> well the command i suggested should return the merge commit that brought the change in [09:17] <michaelni> and looking into its version.h files should show the corresponding version [09:17] <michaelni> but maybe i misunderstood [09:18] Action: michaelni goes to bed [10:41] <vtorri> when compiling on windows, there are several warnings about printf, conversion characters that are unknown [10:41] <vtorri> i would like to define some FMT_XXX, which have some values on windows, other on linux, to remove these warnings [10:42] <vtorri> is there a "private" header where i can define them, and which is included by all the source files ? [10:43] <funman> you use mingw? [10:43] <vtorri> another question: git diff is sufficient for you to create a patch, or does one use someting else [10:43] <funman> you should use -D__USE_MINGW_ANSI_STDIO=1 to have mingw use posix/c99 printf format [10:43] <vtorri> funman: it's not important, as the libc of microsoft i used [10:43] <nevcairiel> git format-patch is usually the better choice [10:44] <vtorri> funman: not with visual studio [10:44] <vtorri> nevcairiel: ok [10:44] <funman> why building with visual studio? [10:44] <vtorri> funman: we already had that discussion :) [10:44] <funman> ah right [10:44] <funman> =) [10:44] <nevcairiel> ffmpeg isnt designed to build with visual studio anyway [10:44] <vtorri> ha ? [10:45] <nevcairiel> all the C99 features used will just blow up in your face [10:45] <ubitux> vtorri: for your git diff question: git commit and use git format-patch -1 to generate a correct patch [10:45] <vtorri> well, then FATE should be configured with that preprocessor macro :) [10:45] <funman> vtorri: USE_MINGW_ANSI_STDIO is mingw specific [10:46] <funman> ah there's a mingw fate? [10:46] <vtorri> fate is using mingw-w64 [10:46] <vtorri> well, ffmpeg one [10:46] <funman> yeah i see it [10:46] <funman> though it says x86_64 mingw32 :P [10:46] <ubitux> removing -fPIC from mingw build would be nice too btw :) [10:47] <ubitux> the build system is quite complex to deal with though [10:47] <nevcairiel> whats wrong with PIC? [10:47] <ubitux> nevcairiel: http://fate.ffmpeg.org/log.cgi?time=20120129065158&log=compile&slot=x86_64-debian-mingw32-gcc-4.6 [10:47] <nevcairiel> except on x64 builds, it crys that all code is PIC enabled. :p [10:47] <nevcairiel> but not so on x86 builds [10:49] <vtorri> wher should I put the patch (it only fixes some warnings) ? [10:49] <nevcairiel> i suppose having configure smart enough to set that based on mingw and which arch would be good, but configure is meh to work on [10:49] <vtorri> where* [10:49] <ubitux> vtorri: ffmpeg-devel ml [10:49] <vtorri> arg [10:50] <vtorri> i didn't want to subscribe :/ [10:50] <ubitux> you don't need to [10:50] <ubitux> but you will have to wait for moderation [10:50] <vtorri> ho [10:50] <funman> vtorri: you can subscribe [10:50] <vtorri> good enough for me :) [10:50] <ubitux> (and you'll need to specify in the mail you want to be CC) [10:50] <funman> then after you get your pass go to mailman management [10:50] <ubitux> http://ffmpeg.org/contact.html  btw, read the first two paragraph [10:50] <funman> and disable 'Mail delivery' [10:56] <vtorri> sent [10:57] <vtorri> funman: USE_MINGW_ANSI_STDIO is mingw or mingw-w64 specific ? [11:01] <funman> mingw [11:02] <vtorri> ok [14:17] <CIA-108> ffmpeg: 03Reimar Döffinger 07master * r05741d70c7 10ffmpeg/ (22 files in 3 dirs): (log message trimmed) [14:17] <CIA-108> ffmpeg: Fallback to input timestamps for non-delay encoders. [14:17] <CIA-108> ffmpeg: Causes FFmpeg to pass through the correct pts values, [14:17] <CIA-108> ffmpeg: instead of clobbering all to AV_NOPTS_VALUE (the av_init_packet [14:17] <CIA-108> ffmpeg: default) to then make up new ones based on only fps when muxing. [14:17] <CIA-108> ffmpeg: Included are also the related FATE ref changes, which all [14:17] <CIA-108> ffmpeg: some reasonable on quick investigation. [14:17] <CIA-108> ffmpeg: 03Reimar Döffinger 07master * r6a9b565e0a 10ffmpeg/ (3 files in 2 dirs): [14:17] <CIA-108> ffmpeg: FRAPS: Do not needlessly use reget_buffer. [14:17] <CIA-108> ffmpeg: Codec has only I- and skip-frames, so there is no [14:17] <CIA-108> ffmpeg: need for reget_buffer, change it so it works with [14:17] <CIA-108> ffmpeg: get_buffer. [14:17] <CIA-108> ffmpeg: Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de> [14:22] <CIA-108> ffmpeg: 03Reimar Döffinger 07master * r95e873bb14 10ffmpeg/libavcodec/fraps.c: [14:22] <CIA-108> ffmpeg: fraps: fix indentation. [14:22] <CIA-108> ffmpeg: Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de> [14:42] <ubitux> avctx->subtitle_header = av_malloc(avctx->extradata_size); [14:42] <ubitux> if (!avctx->extradata) [14:42] <ubitux> return AVERROR(ENOMEM); [14:42] <ubitux> huh? [14:43] <nevcairiel> looks like someone copy pasted too much. :) [14:48] <CIA-108> ffmpeg: 03Reimar Döffinger 07master * rf4e8292eb7 10ffmpeg/libavcodec/fraps.c: [14:48] <CIA-108> ffmpeg: fraps: Add release_buffer forgotten when reget_buffer was removed. [14:48] <CIA-108> ffmpeg: Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de> [14:50] <durandal_1707> ubitux: who is goint to post patch? [14:51] <ubitux> i have a local patch [14:51] <durandal_1707> then post it [14:51] <ubitux> i'm checking some stuff before sending it [14:51] <ubitux> yes don't worry, i'll post it :) [14:53] <CIA-108> ffmpeg: 03Paul Kendall 07master * r7df9937fcc 10ffmpeg/libavcodec/dvbsubdec.c: Fix dvb subtitle decoding when display segment is missing. [16:27] <ubitux> i'm a bit lost with st->codec->extradata; it seems to be allocated in various places (ffmpeg.c, codec, demuxer), but also free'd from various places (codec, demuxer, lavf utils in the format close, ...) [16:27] <ubitux> how is it supposed to work? [16:29] <nevcairiel> th demuxer sets and frees it, decoders just read it but never change it, encoders set and free it, muxers just read it and never change it [16:30] <nevcairiel> that should be the essence of it [16:30] <ubitux> libavcodec/libx264.c: av_freep(&avctx->extradata); [16:30] <ubitux> what about this one? [16:30] <nevcairiel> its an encoder, isnt it. :) [16:31] <ubitux> oh sorry. [16:31] <ubitux> then, why: [16:31] <ubitux> libavcodec/utils.c- if (codec_is_encoder(avctx->codec)) [16:31] <ubitux> libavcodec/utils.c: av_freep(&avctx->extradata); [16:31] <ubitux> ? [16:31] <ubitux> handle the encoders which don't free it? [16:31] <nevcairiel> so that if an encoder creates it but doesnt free it itself, it gets freed? [16:32] <ubitux> if there is such thing, why not just drop all the av_freep from the encoders? [16:32] <nevcairiel> who knows [16:32] <nevcairiel> x264 can have varying extradata in the same stream, maybe its somehow ralted to that? [16:32] <nevcairiel> related* [16:33] <nevcairiel> not sure x264 generates such streams, but the format is capable. :) [16:34] <ubitux> "demuxer sets and frees it [...] encoders set and free it" [16:34] <nevcairiel> whoever creates the data is also responsible for freeing it again [16:34] <ubitux> do you have examples of use case for the two situations? [16:35] <ubitux> the demuxer sets it to transmit format data to the encoders, and sometimes there is a need of transmitting data from the decoder to the demuxer? [16:36] <ubitux> and if so, can it be possible to do both without "conflicts"? [16:36] <nevcairiel> the demuxer sets it to transmit it to the decoders, because there its needed [16:36] <nevcairiel> a demuxer and a encoder will possibly never work on the same format context [16:36] <ubitux> oh wait i mixed up things with decoders. [16:37] <ubitux> i need to read more carefully again; sorry. [16:37] <nevcairiel> you demux, decode, encode, mux, the first two can share a context, and the second two can [16:37] <nevcairiel> everything else will possibly result in trouble. :) [16:57] <ubitux> ok, it makes sense now, thank you nevcairiel [17:35] <CIA-108> ffmpeg: 03Reimar Döffinger 07master * r7fabef1f01 10ffmpeg/libavcodec/fraps.c: [17:35] <CIA-108> ffmpeg: fraps: optimize pseudo-YUV to RGB conversion. [17:35] <CIA-108> ffmpeg: With gcc 4.6 this part of the code is ca. 4x faster, resulting [17:35] <CIA-108> ffmpeg: in an overall speedup of around 5% for fate-fraps-v5 sample. [17:35] <CIA-108> ffmpeg: Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de> [17:54] <CIA-108> ffmpeg: 03Carl Eugen Hoyos 07master * ra915618a29 10ffmpeg/libavcodec/wavpack.c: [17:54] <CIA-108> ffmpeg: Improve decoding quality for lossy wavpack. [17:54] <CIA-108> ffmpeg: This reverts e6e7bfc1 and 365e1ec2. [17:54] <CIA-108> ffmpeg: The code may be incorrect both before and after the revert, but we [17:54] <CIA-108> ffmpeg: do not have any samples that were fixed by the original commits. [17:54] <CIA-108> ffmpeg: Fixes ticket #871. [18:03] <CIA-108> ffmpeg: 03Carl Eugen Hoyos 07release/0.10 * rb2f27d2926 10ffmpeg/libavcodec/wavpack.c: [18:03] <CIA-108> ffmpeg: Improve decoding quality for lossy wavpack. [18:03] <CIA-108> ffmpeg: This reverts e6e7bfc1 and 365e1ec2. [18:03] <CIA-108> ffmpeg: The code may be incorrect both before and after the revert, but we [18:03] <CIA-108> ffmpeg: do not have any samples that were fixed by the original commits. [18:03] <CIA-108> ffmpeg: Fixes ticket #871. [18:03] <CIA-108> ffmpeg: (cherry picked from commit a915618a29f3f4197832151a4ed03ccdd585f9cf) [18:45] <CIA-108> ffmpeg: 03Peter Ross 07master * r15d838b745 10ffmpeg/libavformat/bintext.c: [18:45] <CIA-108> ffmpeg: bintext: use private options now that AVFormatParameters has been removed [18:45] <CIA-108> ffmpeg: Reviewed-by: Stefano Sabatini <stefasab@gmail.com> [18:45] <CIA-108> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni@gmx.at> [18:45] <CIA-108> ffmpeg: 03Paul B Mahol 07master * r8e46e12222 10ffmpeg/tests/ (codec-regression.sh ref/vsynth1/yuv4 ref/vsynth2/yuv4): [18:45] <CIA-108> ffmpeg: fate: add yuv4 encoding/decoding test [18:45] <CIA-108> ffmpeg: Signed-off-by: Paul B Mahol <onemda@gmail.com> [18:45] <CIA-108> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni@gmx.at> [18:45] <CIA-108> ffmpeg: 03Paul B Mahol 07master * r668a0b152b 10ffmpeg/libavcodec/libvpxenc.c: [18:45] <CIA-108> ffmpeg: libvpxenc: update after FF_API_X264_GLOBAL_OPTS removal [18:45] <CIA-108> ffmpeg: Signed-off-by: Paul B Mahol <onemda@gmail.com> [18:45] <CIA-108> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni@gmx.at> [18:45] <CIA-108> ffmpeg: 03Paul B Mahol 07master * r3b93a524c2 10ffmpeg/tests/ (codec-regression.sh ref/vsynth1/v308 ref/vsynth2/v308): [18:45] <CIA-108> ffmpeg: fate: add v308 encoding/decoding test [18:45] <CIA-108> ffmpeg: Signed-off-by: Paul B Mahol <onemda@gmail.com> [18:45] <CIA-108> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni@gmx.at> [19:17] <durandal_1707> why is openbsd's fate failing in configuration? [19:34] <durandal_1707> r210 failing in valgrind case could mean only one thing: we need to write explicitly write zeroes when padding width [19:35] <kierank> why [19:36] <kierank> we don't do it in v210 iirc [19:39] <durandal_1707> kierank: there is memset [19:39] <kierank> oh [21:08] <CIA-108> ffmpeg: 03Paul B Mahol 07master * r371946bc27 10ffmpeg/ (4 files in 4 dirs): [21:08] <CIA-108> ffmpeg: r210enc: don't write uninitialized data [21:08] <CIA-108> ffmpeg: Also fix r210 fate decoding test. [21:08] <CIA-108> ffmpeg: Signed-off-by: Paul B Mahol <onemda@gmail.com> [21:08] <CIA-108> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni@gmx.at> [21:26] <burek> does anyone know what are these compilation errors related to: http://pastebin.com/a0HE7i1z [21:30] <durandal_1707> i never got that rtsp warning when compiling static [21:30] <durandal_1707> but i'm not using linux.... [21:30] <burek> :D [21:31] <iive> libfontconfig.a [21:31] <iive> it seems to use some other lib for xml parsing, and that one is missing. [21:32] <burek> hmh.. I've tried apt-file search XML_GetCurrentLineNumber but it didn't give me any results [21:32] <burek> I'll try google [21:33] <iive> that's function not library [21:33] <burek> yes, but I don't know the name of the lib [21:33] <burek> seems like libexpat [21:33] <iive> check `pkg-config --libs fontconfig` [21:33] <durandal_1707> by build of shared fontconfig depends on : libfreetype, libz, libc and libexpat [21:34] <durandal_1707> you have sttix libexpat? [21:34] <durandal_1707> s/sttix/static [21:34] <burek> # pkg-config --libs fontconfig [21:34] <burek> -lfontconfig [21:34] <iive> --cflags ? [21:35] <burek> umm didn't modify cflags [21:35] <burek> only ldflags [21:35] <burek> durandal_1707, I'll download/compile libexpat [21:35] <burek> the rest I have [21:35] <iive> add --static to the --libs [21:36] <burek> -lfontconfig -lexpat -lfreetype -lz [21:37] <durandal_1707> michaelni: why is openbsd failing? [21:40] <funman> as a project? [21:40] <durandal_1707> funman: lol, noo [21:50] <durandal_1707> maybe it is sh bug in openbsd... [21:53] <CIA-108> ffmpeg: 03Reimar Döffinger 07master * r3469c88804 10ffmpeg/libavcodec/fraps.c: [21:53] <CIA-108> ffmpeg: fraps: Minor simplification, use local variable. [21:53] <CIA-108> ffmpeg: Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de> [21:53] <CIA-108> ffmpeg: 03Reimar Döffinger 07master * r0efdb942a6 10ffmpeg/libavcodec/fraps.c: [21:53] <CIA-108> ffmpeg: fraps: Deduplicate some code. [21:53] <CIA-108> ffmpeg: Also moves it before the get_buffer call so that most error exits [21:53] <CIA-108> ffmpeg: happen before it. [21:53] <CIA-108> ffmpeg: Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de> [21:53] <CIA-108> ffmpeg: 03Reimar Döffinger 07master * rf9eb622944 10ffmpeg/libavcodec/fraps.c: [21:53] <CIA-108> ffmpeg: Fix offset validity checks. [21:53] <CIA-108> ffmpeg: Offsets are relative to the end of the header, not the [21:53] <CIA-108> ffmpeg: start of the buffer, thus the buffer size needs to be subtracted. [21:53] <CIA-108> ffmpeg: Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de> [21:53] <CIA-108> ffmpeg: 03Reimar Döffinger 07master * rcd3ced1bb9 10ffmpeg/libavcodec/fraps.c: [21:53] <CIA-108> ffmpeg: fraps: frame threading support. [21:53] <CIA-108> ffmpeg: Codec is too simple to gain much from it at lower resolutions, [21:53] <CIA-108> ffmpeg: but should help at very high resolutions, particularly for [21:53] <CIA-108> ffmpeg: v3 and v5 where a not too optimized pseudo-YUV to RGB [21:53] <CIA-108> ffmpeg: is done in the codec. [21:53] <CIA-108> ffmpeg: Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de> [21:57] <nevcairiel> and just a few weeks ago someone complained to me that his fraps recordings were not decoding fast enough, that gotta shut them up [21:57] <durandal_1707> nevcairiel: you mean doom9 thread? [21:57] <nevcairiel> yes [21:58] <nevcairiel> thats usually where all the complaints pile up =p [22:14] <michaelni> someone (who regularly reads doom9) should open tickets for all complaints found there [22:15] <durandal_1707> hmm AV_PIX_FMT_ABI_GIT_MASTER is not in history [23:04] <CIA-108> ffmpeg: 03Alexander Strasser 07master * r90bf7c7b41 10ffmpeg/configure: build: configure: Restore alphabetical order for CMDLINE_SET [23:11] <durandal_1707> why x262? [23:12] <Daemon404> [15:50] < durandal_1707> maybe it is sh bug in openbsd... <-- dont tell theo [23:12] <Daemon404> OpenBSD is Perfect (TM) [23:14] <durandal_1707> 4.8 is pretty old, there is 4.9 [23:14] <Daemon404> i dont really know who even runs openbsd realistically [23:14] <Daemon404> :/ [23:14] Action: cbsrobot does [23:15] <ohsix> he doesn't know you bro [23:15] <ohsix> better watch out, things can get sketchy! [23:15] <Daemon404> does it have non-fail SMP yet? [23:15] <cbsrobot> not sure - it's all a bit slower but at least theres not a zillion changes afterwards [23:16] <Daemon404> and does it support amd64 yet? lol [23:16] Action: Daemon404 recalls openbsd was a bit... slow on that front [23:16] <cbsrobot> let me check my uptime [23:16] <Daemon404> lol [23:16] <durandal_1707> openbsd is not about performance [23:16] <Daemon404> i know [23:17] <cbsrobot> 68 days ... on amd64 [23:17] <Daemon404> openbsd is about code audition and security [23:17] <Daemon404> it's produced great software [23:17] <Daemon404> i just dont like its kernel :P [23:18] <cbsrobot> politicas aside but they made some nice tools aswell [23:18] <cbsrobot> openssh, pf, ntpd are quite nice [23:19] <cbsrobot> durandal_1707: 4.9 is old - theres 5.0 [23:19] <Daemon404> cbsrobot, yes [23:19] <cbsrobot> and durandal_1707 x262 = mpeg 2 [23:19] <cbsrobot> x264 = mpeg 4 [23:19] Action: Daemon404 sort of wonders why people still use mpeg-2 [23:20] <cbsrobot> DVD ? [23:20] <JEEBsv> cbsrobot: for future reference, MPEG-4 has multiple video codecs .-. [23:20] <ohsix> it might be all those broadcast standards and hardware [23:20] <JEEBsv> so you might want to specify which you are referencing [23:20] <ohsix> part 10 [23:20] <cbsrobot> JEEBsv: well - thats just how I make it up in my brain ... [23:21] <Daemon404> [17:20] < ohsix> it might be all those broadcast standards and hardware <-- pretty much every in-use standard allows avc iirc [23:21] <Daemon404> tho existign hardware and $$ are plausible reasons [23:21] <ohsix> gj [23:22] <ohsix> unless you need to worry about bandwidth (eg. a cable provider) you don't need to be very nimble with backhaul and stuff, unless it saves you more money than the equipment you'd buy to adapt it [23:22] <Daemon404> i did just say money was a valid reason [23:22] <ohsix> and for broadcast you have to not use a bunch of neat mpeg4 features [23:23] <Daemon404> not sure how thats relevant... [23:25] <kierank> existing hw is the reason [23:26] <Daemon404> yea thats what i said/figured [23:26] <ohsix> surely "mpeg4 is awesome" and "mpeg2 sucks i don't know why they use it" implies some use of the features the former offer over the latter [23:26] <Daemon404> do you do anything besides troll? [23:27] <ohsix> you said you don't know why people use mpeg2, i guess you can continue to elaborate; but i pretty much already knew what you meant when you said it [23:27] <durandal_1707> back to the topic: what's wrong with ffmpeg mpeg 2 encoder? [23:28] <cbsrobot> lol [23:31] <cbsrobot> durandal_1707: ask kierank [23:34] <kierank> durandal_1707: it's easier to add mpeg-2 support to x264 than to add all of x264's decent features to ffmpeg's mpeg-2 encoder [23:34] <kierank> i.e time taken to reach a world class mpeg-2 encoder is drastically lower [23:35] <durandal_1707> kierank: you mean from code standpoint? [23:35] <kierank> yes and by extension time [23:42] <cbsrobot> kierank: whats the status on x262 ? [23:43] <kierank> well progressive works [23:43] <cbsrobot> is there a commit you recommend ? [23:43] <kierank> and things may be changing in the near future but i can't comment on that [00:00] --- Mon Jan 30 2012