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

[burek]

[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 at 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 at 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 at 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 at 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 at gmail.com>
[02:53] <CIA-108> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at 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 at gmail.com>
[02:53] <CIA-108> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at 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 at gmail.com>
[02:53] <CIA-108> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at 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 at gmail.com>
[03:39] <CIA-108> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[07:20] <funman> FYI doc/APIchanges is broken http://git.videolan.org/?p=vlc.git;a=commitdiff;h=5b55c4dbab0ee2700300f9d8b79747a42ef26158;hp=49944dcb5ac7ecc39da86bdb300bd7be8c9d2e47
[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 at 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 at 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 at 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 at 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 at gmail.com>
[18:45] <CIA-108> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at 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 at gmail.com>
[18:45] <CIA-108> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at 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 at gmail.com>
[18:45] <CIA-108> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at 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 at gmail.com>
[18:45] <CIA-108> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at 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 at gmail.com>
[21:08] <CIA-108> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at 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 at 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 at 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 at 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 at 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