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

[burek]

[00:43] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * r323d912010 10ffmpeg/libswresample/ (4 files): 
[00:43] <CIA-56> ffmpeg: swr: update copyright years
[00:43] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[00:43] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * r2dd2e42951 10ffmpeg/libswresample/rematrix.c: 
[00:43] <CIA-56> ffmpeg: swr: update rematrix coeffs to match AC-3
[00:43] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[00:43] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * rc5278cb84f 10ffmpeg/libswresample/ (rematrix.c swresample.c swresample_internal.h): 
[00:43] <CIA-56> ffmpeg: Add Dolby/DPLII downmix support to libswresample
[00:43] <CIA-56> ffmpeg: Based on code by John Stebbins <jstebbins.hb at gmail.com>
[00:43] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[01:46] <CIA-56> ffmpeg: 03Ben Jackson 07master * rde9f5b6853 10ffmpeg/ (libavcodec/vp6.c tests/ref/fate/vp60): 
[01:46] <CIA-56> ffmpeg: lavc/vp6: Disable deblock filtering for Simple Profile
[01:46] <CIA-56> ffmpeg: In vp6 Advanced Profile, deblock filtering is conditionally enabled in
[01:46] <CIA-56> ffmpeg: each frame header. In Simple Profile it should always be off. vp6 was
[01:46] <CIA-56> ffmpeg: inheriting the wrong default from ff_vp56_init.
[01:46] <CIA-56> ffmpeg: Signed-off-by: Ben Jackson <ben at ben.com>
[01:46] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[03:37] <Compn> whoa
[03:37] <Compn> ben at ben.com is his real addy
[03:37] <Compn> dont see too many 3 letter .com domains 
[04:07] <RT|AO> "<@Daemon404> configure on msys is SLOW" # you may try using my MSYS dash. http://roy.orz.hm/soft/dash.exe
[04:07] <RT|AO> on running libav configure:
[04:07] <RT|AO> 09:17 < RT|AO> mksh(msys+blin-printf)    1m5.03s real     1m50.72s user     0m28.29s system
[04:07] <RT|AO> 09:17 < RT|AO> dash(msys)    0m49.92s real     1m57.54s user     0m27.36s system
[04:07] <RT|AO> 09:19 < RT|AO> bash(msys)    1m20.57s real     2m20.38s user     0m34.68s system
[04:08] <RT|AO> but of course the "pwd -W" is not in dash, only CRLF is patched not causing issues in MSYS.
[04:11] <RT|AO> if you're asking dash patch, I posted here: http://article.gmane.org/gmane.comp.shells.dash/775
[05:30] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * ra33b4bc79c 10ffmpeg/libavfilter/buffer.c: 
[05:30] <CIA-56> ffmpeg: lavfi: factor copy_video_props() out
[05:30] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[05:30] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * rc9a0f9bf3c 10ffmpeg/libavfilter/ (avcodec.c avfilter.h buffer.c version.h video.c): 
[05:30] <CIA-56> ffmpeg: libavfilter: pass QP table through the filter chain
[05:30] <CIA-56> ffmpeg: Any volunteers to port the pp and spp filters from libmpcodec?
[05:30] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[06:56] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * rca7be934d6 10ffmpeg/libavfilter/buffer.c: 
[06:56] <CIA-56> ffmpeg: lavfi: 10l fix () placement
[06:56] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[10:02] <CIA-56> ffmpeg: 03Stefano Sabatini 07master * rcf5629c064 10ffmpeg/libavutil/opt.c: lavu/opt: reindent after last commit
[10:02] <CIA-56> ffmpeg: 03Stefano Sabatini 07master * r911519caec 10ffmpeg/libavcodec/libx264.c: 
[10:02] <CIA-56> ffmpeg: lavc/libx264: remap X264_LOG_INFO loglevel from AV_LOG_INFO to VERBOSE
[10:02] <CIA-56> ffmpeg: AV_LOG_INFO is more geared towards messages to be read by the user, the
[10:02] <CIA-56> ffmpeg: statistics shown by libx264 with X264_LOG_INFO are more useful at the
[10:02] <CIA-56> ffmpeg: debugging level.
[10:02] <CIA-56> ffmpeg: Help reducing the log spam.
[10:03] <CIA-56> ffmpeg: 03Ramiro Polla 07master * r37a0db50db 10ffmpeg/ (doc/indevs.texi libavdevice/dshow.c): 
[10:03] <CIA-56> ffmpeg: lavd/dshow: support video codec and pixel format selection
[10:03] <CIA-56> ffmpeg: Signed-off-by: Stefano Sabatini <stefasab at gmail.com>
[10:03] <CIA-56> ffmpeg: 03Ramiro Polla 07master * rdc5fcdb896 10ffmpeg/libavdevice/dshow.c: 
[10:03] <CIA-56> ffmpeg: lavd/dshow: use AV_OPT_TYPE_IMAGE_SIZE
[10:03] <CIA-56> ffmpeg: Signed-off-by: Stefano Sabatini <stefasab at gmail.com>
[10:46] <Tjoppen> grr. ffmpeg and libav don't use the same FATE samples :|
[11:50] <michaelni> Tjoppen, what differs and why does it matter?
[11:50] <michaelni> Tjoppen, also whats with the "audio timebases and MXF" patch?
[11:55] <Tjoppen> michaelni: if size==0 then avio_close() never gets called
[11:57] <saste> ubitux: [PATCH] ffmpeg: add -amerge option to merge audio streams
[11:57] <michaelni> Tjoppen, where what size ?
[11:57] <saste> why wasn't it never applied?
[11:58] <Tjoppen> -        if(size[i]){
[11:58] <Tjoppen> +        if(ret[i] >= 0){
[11:59] <Tjoppen> size[0] == 0 when it tries to demux a zero-sized file
[11:59] <Tjoppen> hence avio_close(f[i]); doesn't get called
[12:07] <saste> michaelni, ubitux: do we have any means to fill a discontinuous stream with dummy data?
[12:08] <saste> either at the filtering or at the ffmpeg level (async, vsync?)
[12:11] <michaelni> Tjoppen, reply to your patch sent
[12:14] <michaelni> Tjoppen, is the mxf patch ok/not ok or are you busy and i should try to find someone else to review it ?
[12:15] <Tjoppen> that was the NTSC audio durations getting rounded to zero, right?
[12:16] <michaelni> IIRC yes
[12:16] <michaelni> or also the, audio has no timestamps IIRC
[12:18] <Tjoppen> aren't those generated?
[12:18] <Tjoppen> oh right, the whole seeking bit. hm
[12:18] <Tjoppen> imma have lunch, then take a look. I'm out of tickets at work anyway
[12:43] <Yexo> Since I haven't been able to find any encoder for HD-SDI or SD-SDI I decided to write my own. Currently I'm able to write full SDI frames (video + audio) to a file. The video format I need is YUV 4:2:2 (Cb Y0 Cr Y1). The pixel format PIX_FMT_UYVY422 looks like what I need only that is 16bpp while I need 32bpp.
[12:43] <Yexo> Because I wasn't aware how pixel formats worked my first approach was to write an sdi codec (next to the sdi format) that takes PIX_FMT_YUV422P10 and writes uncompressed video. While this works I think it'd be better to add a new pixel format PIX_FMT_UYVY422_32 which would basically be a copy of PIX_FMT_UYVY422 but with extended bit depth.
[12:43] <Yexo> is that approach reasonable or is there a better way?
[12:44] <Yexo> ^^ sorry if I'm mixing up some terms, I'm still very new to ffmpeg development
[12:47] <saste> Yexo: check libavutil/pixfmt and libavutil/pixdesc
[12:47] <saste> you may also need to update libavcodec/imgconvert
[12:47] <saste> and add scaling utilities in libswscale
[12:47] <saste> (well the latter is not required)
[12:49] <Yexo> thanks
[12:50] <Yexo> related question: Is it possible to force a specific codec/pixfmt in an AVOutputFormat or do I have to explicitely check for that in the write_header function?
[12:52] <shroomM> Daemon404, I figured if I remove a --disable-network, the build went through fine
[13:11] <saste> Yexo: it depends, usually a muxer takes the input pixel format, and fails if it is not supported
[13:11] <saste> pixel format conversion is done outside the muxer
[13:12] <saste> Yexo: check how it is done in the sdl output device, assuming you're writing an output device
[13:28] <Yexo> saste: thanks again, the sdl output example is what I needed
[13:29] <Yexo> however I want to write the output to a file, so I had written a "format" (file in libavformat, not in libavdevice)
[13:29] <Yexo> in the future I might want to add an output device that takes this "format" as input, is that possible or would I have to duplicate the code in that case?
[13:30] <Yexo> ie can an output device accept a muxed format instead of raw audio/video streams?
[13:31] <Yexo> nvm that question, should have read the documentation first
[13:34] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * r5891e454a6 10ffmpeg/libavcodec/faxcompr.c: 
[13:34] <CIA-56> ffmpeg: faxcompr: fix out of array read
[13:34] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[13:34] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * ra7fbc7d7b7 10ffmpeg/libavformat/utils.c: 
[13:34] <CIA-56> ffmpeg: lavf: factor codec id forcing out
[13:34] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[13:35] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * r91141f2a13 10ffmpeg/libavfilter/ (avcodec.c avfilter.h buffer.c): 
[13:35] <CIA-56> ffmpeg: lavfi: add qp_table_size
[13:35] <CIA-56> ffmpeg: This avoid recalculating it and in case w/h changed avoids crashes.
[13:35] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[13:36] <saste> Yexo: what's exactly your problem?
[13:37] <saste> if you want to read yuvy422p16 images than what you need is a pixel format + converter utilities
[13:37] <saste> *uyvy42216
[13:38] <Yexo> the company I work for has SD-SDI and HD-SDI hardware. Currently we use a proprietary file format, but we want to open that file format and make a converter available. FFmpeg seems to be the best tools for the job. So for now I want to write this file format, in the future it might be possible to extend it to let FFmpeg write directly to the hardware
[13:38] <Yexo> the file format is basically a simple header and then the raw SDI format as defined by SMPTE
[13:40] <Tjoppen> ah, like SDTI-CP?
[13:40] <Tjoppen> it might be able to share code with mxfdec.c
[13:40] <saste> Yexo: in that case if it is not simple rawvideo data then a format should do
[13:41] <JEEB> then depending on if it's just a contianer for something or just a video or audio format I guess you're looking at either libavformat (containers and general format parsing etc.) or libavcodec (just video or audio streams)
[13:41] <saste> Yexo: note also that an output format is no different than an output device
[13:43] <saste> but still ffmpeg won't be able to write that format, if it only supports uyvy422_16, since it is currently unsupported by the scaling/conversions routines
[13:43] <Tjoppen> couldn't it remux it?
[13:43] <saste> yes
[13:44] <saste> for that you only need to extend pixfmt/pixdesc/imgconvert
[13:45] <Yexo> it can write every sample as 8, 10 or 16 bits. The 16bit version uses the 10 LSB and the 6MSB are 0. The 10bit version is preferred. uyvy422 only gives 8bits per sample, which means losing quality
[13:47] <Yexo> Tjoppen: SDTI-CP seems to be data packed inside the SDI format, that's something different
[13:47] <Yexo> I just want to write/read the raw SDI cable format to/from files
[13:49] <Tjoppen> hm. right
[13:50] <CIA-56> ffmpeg: 03Alberto Delmás 07master * r9699b3a2d7 10ffmpeg/libavcodec/mss12.h: (log message trimmed)
[13:50] <CIA-56> ffmpeg: mss12: avoid unnecessary division in arith*_get_bit()
[13:50] <CIA-56> ffmpeg: That division can be replaced with a comparison:
[13:50] <CIA-56> ffmpeg: ((c->value - c->low) << 1) + 1 >= range
[13:50] <CIA-56> ffmpeg: By expanding 'range' definition and simplifying this inequation we obtain
[13:50] <CIA-56> ffmpeg: the final expression.
[13:50] <CIA-56> ffmpeg: Suggested by Michael Niedermayer <michaelni at gmx.at>
[13:51] <CIA-56> ffmpeg: 03Janne Grunau 07master * r59383d5740 10ffmpeg/libavcodec/mpegvideo.c: 
[13:51] <CIA-56> ffmpeg: mpegvideo: set AVFrame fields to NULL after freeing the base memory
[13:51] <CIA-56> ffmpeg: Prevents dangling pointers and makes access after free more obvious.
[13:51] <CIA-56> ffmpeg: Setting AVFrame.qscale_table to NULL is required for successfully
[13:51] <CIA-56> ffmpeg: allocating a previously freed Picture with ff_alloc_picture().
[13:51] <CIA-56> ffmpeg: 03Alberto Delmás 07master * r290d1022b2 10ffmpeg/libavcodec/mss2.c: 
[13:51] <CIA-56> ffmpeg: mss2: simplify loop in decode_rle()
[13:51] <CIA-56> ffmpeg: It calculates the sum of power of two series, which can be done in one step.
[13:51] <CIA-56> ffmpeg: Suggested by Michael Niedermayer <michaelni at gmx.at>
[13:51] <CIA-56> ffmpeg: Signed-off-by: Kostya Shishkov <kostya.shishkov at gmail.com>
[13:51] <CIA-56> ffmpeg: 03Samuel Pitoiset 07master * r9afb7061f9 10ffmpeg/libavformat/ (cafdec.c mov.c mov_chan.c mov_chan.h): 
[13:51] <CIA-56> ffmpeg: mov_chan: Pass a separate AVIOContext for reading
[13:51] <CIA-56> ffmpeg: This fixes crashes when called from rtpdec_qt, where
[13:51] <CIA-56> ffmpeg: AVFormatContext->pb is null, a crash present since 3bab7cd128.
[13:51] <CIA-56> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[13:51] <CIA-56> ffmpeg: 03Martin Storsjö 07master * ra224b2cb30 10ffmpeg/configure: 
[13:51] <CIA-56> ffmpeg: configure: Set the right cc_e flags for msvc
[13:51] <CIA-56> ffmpeg: The default ones work, but outputs the preprocessed file on stdout
[13:51] <Tjoppen> it's not entirely raw data though, right? from what I recall you can stuff some metadata on it, like timecode. and audio (I think). in that case you need to write a demuxer
[13:52] <Yexo> sorry, I if I wasn't clear enough. Yes, you're right, it's not just raw video. It's uncompressed video + audio (and possible auxiliary data, but that's of no concern)
[13:55] <Tjoppen> it should be a rather simple format. just follow the SMPTE spec I suppose
[13:55] <Tjoppen> and look at some of the simpler demuxers
[13:55] <Yexo> yep, I've already done that, just in a posible incorrect way
[13:55] <Yexo> at least, the muxer is done, demuxer will follow sometime later
[13:56] <Tjoppen> as has been hinted above, you may need to add a pixel format corresponding to what the data looks like. that way less repacking has to be done
[13:56] <Tjoppen> I think the current 10-bit formats aren't shifted for instance
[13:56] <Yexo> that was exactly my original question ;)
[13:58] <Tjoppen> ah, I see. I'm guessing it's 10-bit UYVY put stuffed into 4x16-bit words
[14:00] <Yexo> not sure how to describe it, but I use this code to pack the 10-bit values in a byte array: http://pastebin.com/B0F8sgSh
[14:01] <Yexo> the only interesting case is nbits==10
[14:03] <Tjoppen> looks like a packed format
[14:03] <Tjoppen> so.. four samples to five bytes (40 bits)?
[14:03] <Yexo> yes
[14:04] <Tjoppen> k. luckily that could easily by packed/unpacked with a suitable "codec"
[14:05] <Tjoppen> in face.. that sounds like V210
[14:05] <Tjoppen> in which case you could simply set codec_id = AV_CODEC_ID_V210  and you're done :)
[14:06] <Yexo> almost, but v210 is yuv422p10 (planar, I need packed)
[14:09] <Tjoppen> well, it *decodes* to planar
[14:10] <Tjoppen> you need it interleaved for some processing code?
[14:11] <Yexo> if v210 is not planar but packed that would be perfect, lets see
[14:12] <Tjoppen> v210 is packed. however, the decoder turns it into planar (most likely because it's easier to deal with planar in libswscale)
[14:14] <Yexo> I see, it's indeed almost identical
[14:14] <Yexo> however v210 packs 3 10-bit samples in 4 bytes, while I need to pack 4 samples in 5 bytes
[14:16] <Yexo> so that brings me back to my first question: Is it better to write a codec that accepts planar and writes this packed format or is it better to define a new pixel format and use the raw video codec?
[14:18] <Tjoppen> what do you want to feed the stream to, ultimately?
[14:18] <saste> Yexo: don't take my word as the final word, but a good rule of thumb is:
[14:18] <saste> if the image can be sanely represented using pixdesc, than it is a pixel format
[14:18] <saste> otherwise it's a codec format
[14:18] <Yexo> Tjoppen: a muxer that adds some audio and write the sdi format
[14:19] <Tjoppen> ah, so mute SDI in + audio -> SDI w/ audio out?
[14:19] <CIA-56> ffmpeg: 03Tomas Härdin 07master * rd74af89317 10ffmpeg/libavformat/img2dec.c: 
[14:19] <CIA-56> ffmpeg: img2dec: Don't leave AVIOContexts open on zero byte files
[14:19] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[14:19] <Yexo> Tjoppen: "sdi video only in + audio in" -> "full sdi frame out"
[14:19] <Tjoppen> in that case you only need to remux the video, so don't bother caring about pixel formats at all. the data just needs to be copied
[14:20] <Yexo> but I don't have the sdi video in the correct video format (input is v210, but needs to be repacked)
[14:21] <Tjoppen> aha. I'd start with getting planar to work. later you could optimize it a bit by say having v210dec decode to an interleaved format (like UYVY422, but not 8-bit)
[14:21] <Tjoppen> settable via an option or something
[14:22] <Yexo> <Tjoppen> aha. I'd start with getting planar to work. <- that's what I've already done, but that was also before I knew anything about pixel formats at all
[14:22] <Yexo> thanks for all the help you've given me :)
[14:22] <Tjoppen> so it works, but it isn't fast enough? :)
[14:23] <Yexo> it works (speed doesn't matter at this moment, it's offline encoding for now anyway), but I was wondering about the "correct" way before doing more work on it
[14:23] <Tjoppen> I see
[14:24] <thresh> michaelni: can you please test libpostproc.git?
[14:25] <thresh> michaelni: you (and the rest of ffmpeg team) should have r/w access to it now
[14:26] <michaelni> thresh, fetch work (i assume push would work too), thanks alot!
[14:26] <thresh> sorry it took so much time, work & rl swamped me
[14:26] <michaelni> thresh, np
[14:33] <CIA-56> ffmpeg: 03Stefano Sabatini 07master * r25f139e72f 10ffmpeg/libavformat/utils.c: 
[14:33] <CIA-56> ffmpeg: lavf/utils: fix typo in has_codec_parameters
[14:33] <CIA-56> ffmpeg: Replace "unspecified sample size" with "unspecified frame size". +10l.
[14:33] <CIA-56> ffmpeg: 03Stefano Sabatini 07master * r09cc23e0f7 10ffmpeg/libavdevice/sdl.c: 
[14:33] <CIA-56> ffmpeg: lavd/sdl: decrease debug info notice log level from AV_LOG_INFO to VERBOSE
[14:33] <CIA-56> ffmpeg: Decrease log spam.
[14:33] <CIA-56> ffmpeg: 03Stefano Sabatini 07master * ra7c7b34d29 10ffmpeg/libavdevice/sdl.c: 
[14:33] <CIA-56> ffmpeg: lavd/sdl: remove trailing dot in messages
[14:33] <CIA-56> ffmpeg: This is consistent with the apparently prevailing convention.
[15:03] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * r54d7094f8b 10ffmpeg/.gitignore: 
[15:03] <CIA-56> ffmpeg: gitignore: codec_names.h is no more
[15:03] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[15:03] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * r7621c3538f 10ffmpeg/Makefile: 
[15:03] <CIA-56> ffmpeg: Makefile: remove old codec_names.h on distclean
[15:03] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[15:08] <Daemon404> nevcairiel, ill make a new build
[15:08] <saste> michaelni: am I right that aresample/libswr should be able to add silence packet to fill discontinuous audio streams?
[15:08] <Daemon404> i also have started sendign clean up patches (re: msvc in ffmpeg)
[15:09] <nevcairiel> i'm setting up a clean minimal build env right now, which i can then copy on my server for fate
[15:10] <nevcairiel> stupid msys is missing some tools
[15:10] <Daemon404> bc?
[15:10] <Daemon404> :P
[15:10] <nevcairiel> yea
[15:10] <Daemon404> grab gnuwin32's
[15:10] <Daemon404> it works fine
[15:10] <nevcairiel> thats what i just did
[15:10] <j-b> Daemon404: thx
[15:11] <saste> michaelni: on a related topic, what about adding a resampling.texi file documenting the various libswr parameters?
[15:13] <Daemon404> nevcairiel, i even got postproc to build with msvc
[15:15] <RT|Chatzilla> Daemon404: ping
[15:16] <nevcairiel> Daemon404: fascinating =p
[15:16] <Daemon404> RT|Chatzilla, hi
[15:16] <Daemon404> nevcairiel, http://pastebin.com/raw.php?i=RAhJwWht
[15:16] <Daemon404> just a small (cruddy) guide i wrote
[15:16] <Daemon404> its far less complicated if you dont want a static libclang
[15:16] <RT|Chatzilla> Daemon404: did you try my MSYS dash shell?
[15:16] <Daemon404> no but i should
[15:16] <Daemon404> i doubt it will be much faster
[15:16] <nevcairiel> whats wrong with the dash that comes with msys?
[15:16] <Daemon404> it comes with bash
[15:16] <nevcairiel> mine also has dash
[15:17] <nevcairiel> i just got the one that mingw-w64 spreads around
[15:17] <RT|Chatzilla> nevcairiel: dash will not strip CRLF correctly if not patched
[15:18] <nevcairiel> its msys, i doubt its a vanilla compile =P
[15:18] <RT|Chatzilla> I don't know wheres your dash comes from anyway
[15:18] <nevcairiel> http://sourceforge.net/projects/mingw/files/MSYS/Extension/dash/
[15:19] <nevcairiel> mingw-w64 just provides a zip which includes all msys packages in one
[15:21] <RT|Chatzilla> I checked that source and it doesn't have my patch
[15:21] <Daemon404> nevcairiel, my msys is vanilla
[15:21] <Daemon404> usng mingw-get
[15:21] <Daemon404> + my toolchain
[15:21] <nevcairiel> mingw-w64 is also vanilla, its just a finished zip for downloading without that weird installer
[15:22] <Daemon404> lol
[15:22] <nevcairiel> they even document it like that
[15:22] <Daemon404> uling new conv build
[15:22] <nevcairiel> just a convenience zip
[15:22] <Daemon404> i mean
[15:22] <Daemon404> building mingw is already arcane magic
[15:22] <Daemon404> buildign msys is black magic
[15:22] <nevcairiel> i've bneen told it requires some old and special version of gcc
[15:23] <Daemon404> awesome
[15:23] <Daemon404> https://www.dropbox.com/s/eseyt6sdp1i6l1a/c99wrap-7b1ee64.7z
[15:23] <nevcairiel> thanks
[15:24] <j-b> Daemon404: works on all c99 codebases?
[15:26] <ubitux> saste: <@saste> why wasn't it never applied? // -amerge was never applied because it's actually not that complicated to do it with amerge filter now
[15:26] <saste> ubitux: ok, i suspected that
[15:26] <michaelni> saste, 1:yes and 2:good idea
[15:26] <Daemon404> j-b, for various definitions of work
[15:26] <ubitux> saste: about the discontinuous stream, no idea
[15:26] <RT|Chatzilla> without patch, x_gcver=$(gcc -dumpversion) shows 'ver='4.3.3 in set, i.e. the trailing CR is count in, which cause config.h having CR and gcc treat it as new line and cause problems.
[15:26] <Daemon404> ir currently has one bug with ffmpeg
[15:27] <Daemon404> and missing features for vlc
[15:27] <saste> i was cleaning up my mbox, and i noticed the unfinished thread
[15:27] <j-b> Daemon404: like C99 for( int i = ) and anonym unions
[15:27] <saste> michaelni: could you suggest the relevant params?
[15:27] <JEEB> I think the C99 for loops with new variables aren't yet dealt
[15:31] <michaelni> saste, something like aresample=min_comp=0.001:min_hard_comp=0.100000 maybe
[15:31] <Daemon404> j-b, perhaps
[15:31] <Daemon404> the former for sure
[15:31] <saste> michaelni: thx i'll try and report
[15:31] <Daemon404> im of the opinion that for(int i = ...) is ugly anyway ;)
[15:33] <nevcairiel> When i dont add a gcc toolchain into the path, configure complains about a missing "nm", but seems to otherwise finish fine, wonder if thats important =p
[15:34] <j-b> Daemon404: ugly, maybe, but useful, definitively
[15:34] <RT|Chatzilla> (sorry on repasting)on running libav configure:
[15:34] <RT|Chatzilla> mksh(msys)    1m37.23s real     2m30.72s user     0m53.15s system
[15:34] <RT|Chatzilla> mksh(msys+blin-printf) 1m5.03s real 1m50.72s user 0m28.29s system
[15:34] <RT|Chatzilla> dash(msys) 0m49.92s real 1m57.54s user 0m27.36s system
[15:34] <RT|Chatzilla> bash(msys) 1m20.57s real 2m20.38s user 0m34.68s system
[15:36] <Daemon404> nevcairiel, im not sure what we use nm for
[15:36] <nevcairiel> some configure check only it seems
[15:36] <Daemon404> olol
[15:36] <nevcairiel> it configured and compiled fine
[15:37] <nevcairiel> although i accidentally build zlib with the wrong calling convention
[15:39] <nevcairiel> hm, i spoke too soon, the linking step failed because its missing "ar" as well
[15:39] <Daemon404> hopefully moving to lib.exe soon
[15:40] <Daemon404> also zlib needs -MT
[15:40] <Daemon404> not -MD
[15:40] <nevcairiel> yeah
[15:40] <Daemon404> as you noted
[15:40] <nevcairiel> i used the msvc10 project that comes with zlib in contribs, because it also builds the asm optimized objects
[15:40] <nevcairiel> but its set to stdcall instead of cdecl by default
[15:40] <Daemon404> oic
[15:41] <Daemon404> does makefile.msc not build the asm?
[15:41] <nevcairiel> no
[15:41] <Daemon404> thats dumb
[15:41] <nevcairiel> you can make it do it, but you have to assemble the objects manually before
[15:41] <nevcairiel> and i was lazy
[15:41] <Daemon404> ;p
[15:43] <nevcairiel> i wonder if ar is even required for a msvc build
[15:43] <nevcairiel> lets just try to null it!
[15:44] <Daemon404> it is
[15:44] <nevcairiel> yeah i just figured that out, guess i'll try to dig up the lib.exe parameters required
[15:44] <RT|Chatzilla> why we don't have native zlib codec in libav/ffmpeg?
[15:45] <nevcairiel> why would you reimplement zlib
[15:45] <JEEB> ^
[15:45] <JEEB> zlib and bzip2 are good enough libraries
[15:45] <JEEB> reinventing the wheel is not a good idea
[15:45] <Daemon404> teh only thing that uses bzip2 is matroskadec
[15:45] <JEEB> yeah
[15:45] <Daemon404> lyakh, lib /out:derp.lib <objects>
[15:46] <nevcairiel> indeed, and bz2 is not even in the spec anymore
[15:53] <Daemon404> eh
[15:53] <Daemon404> av_mallocz doesnt include a NULL check inside it does it?
[15:54] <nevcairiel> it checks if the alloc succeeded before it trys to zero it
[15:54] <nevcairiel> if thats what you mean
[15:54] <Daemon404> http://ffmpeg.org/doxygen/trunk/flashsv2enc_8c-source.html#l00224
[15:54] <Daemon404> im looking here
[15:55] <Daemon404> just wondered if those werent all unchecked mallocs
[15:55] <nevcairiel> mallocz returns NULL if alloc failed, so i guess so
[15:55] <Daemon404> fun
[15:56] <nevcairiel> this configure magic is beyond me to try to add proper lib.exe support for ar
[16:02] <Daemon404> lol
[16:02] <Daemon404> i just called lib manually
[16:02] <Daemon404> ar works fine per se
[16:02] <Daemon404> it just is annoying ot need it
[16:02] <nevcairiel> yeah, should be simple enough to replace it
[16:02] <nevcairiel> just have to know how the replacement magic works
[16:02] <Daemon404> hehe
[16:03] <Daemon404> problem is
[16:03] <Daemon404> iirc
[16:03] <Daemon404> 'rcs' is right in the Makefile
[16:03] <nevcairiel> needs a replacement token like CC_O or CC_E
[16:04] <Daemon404> yea
[16:05] <nevcairiel> which is what makes it a bit complicated to add if you dont know configure
[16:05] <Daemon404> yup
[16:05] <Daemon404> wbs or mru might now
[16:05] <Daemon404> know*
[16:06] <nevcairiel> i just got my mingw64 ar, lets see now
[16:09] <Daemon404> ;p
[16:09] <nevcairiel> or i could just build a simple shell script to convert the ar call =P
[16:09] <Daemon404> lulz
[16:10] <nevcairiel> ar rc name.lib -> lib.exe -out:name.lib .. not too bad :p
[16:27] <nevcairiel> that was simple enough
[16:27] Action: nevcairiel removes ar again
[16:30] <Daemon404> lol
[16:30] <nevcairiel> ar.sh -> lib.exe $(echo $* | sed 's/rc /-out:/')
[16:30] <nevcairiel> tada!
[16:31] <JEEB> lol
[16:32] <lyakh> Daemon404: that was a typo, right?
[16:33] <saste> next step will be to send a notice every time ffmpeg-* ML receive a message  ;)
[16:33] <Daemon404> lyakh, what was?
[16:34] <nevcairiel> you failed tab completion earlier
[16:34] <lyakh> Daemon404: "lyakh, lib /out:derp.lib <objects>"
[16:34] <Daemon404> oh
[16:34] <Daemon404> yes
[16:34] <lyakh> ok, np
[16:49] <Daemon404> michaelni, ping
[18:02] <michaelni> Daemon404, pong
[18:27] <Daemon404> michaelni, any reason why you didnt merge the HAVE_IO_H and HAVE_UNISTD_H stufff?
[18:30] <michaelni> which commit is that (that wasnt merged) ?
[18:30] <Daemon404> uh... let me find...
[18:32] <Daemon404> 3b1ab197be185b61247ef2472f15eeac3e765252 and 3b1ab197be185b61247ef2472f15eeac3e765252 and many others
[18:32] <CIA-56> ffmpeg: 03Derek Buitenhuis 07master * r1d4c4b0fbc 10ffmpeg/libavformat/wtvdec.c: 
[18:32] <CIA-56> ffmpeg: wtvdec: Remove unused strings.h header
[18:32] <CIA-56> ffmpeg: Signed-off-by: Derek Buitenhuis <derek.buitenhuis at gmail.com>
[18:32] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[18:32] <CIA-56> ffmpeg: 03Derek Buitenhuis 07master * ra2015b41a0 10ffmpeg/libavfilter/vf_colormatrix.c: 
[18:32] <CIA-56> ffmpeg: vf_colormatrix: Drop unused strings.h header
[18:32] <CIA-56> ffmpeg: It already uses av_strcasecmp.
[18:32] <CIA-56> ffmpeg: Signed-off-by: Derek Buitenhuis <derek.buitenhuis at gmail.com>
[18:32] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[18:33] <Daemon404> msvc does not have unistd.h, but the read() functions and stuff are located in io.h, and libav added HAVE_IO_H to their config.h... i couldnt find it in ffmpeg
[18:34] <Daemon404> ffmpeg seems to use HAVE_SETMODE to include io.h
[18:42] <michaelni> Daemon404, it appears i made a mistake in that merge, i will correct it ASAP
[18:44] <Daemon404> ok
[18:48] <CIA-56> ffmpeg: 03Ronald S. Bultje 07master * r9d0bc5c0bd 10ffmpeg/libavformat/rtpdec.c: 
[18:48] <CIA-56> ffmpeg: rtpdec: Don't explicitly include unistd.h any longer
[18:48] <CIA-56> ffmpeg: unistd.h used to be required for gethostname. On windows, gethostname
[18:48] <CIA-56> ffmpeg: is provided by winsock2.h. Now network.h includes both unistd.h and
[18:48] <CIA-56> ffmpeg: winsock2.h if they exist.
[18:48] <CIA-56> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[18:48] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[18:48] <CIA-56> ffmpeg: 03Ronald S. Bultje 07master * ra4d71eb5c3 10ffmpeg/libavutil/random_seed.c: 
[18:48] <CIA-56> ffmpeg: random_seed: Only read /dev/*random if we have unistd.h
[18:48] <CIA-56> ffmpeg: unistd.h is used for open/read/close, but if this header does not
[18:48] <CIA-56> ffmpeg: exist, there's probably no use in trying to open /dev/*random
[18:48] <CIA-56> ffmpeg: at all.
[18:48] <CIA-56> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[18:48] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[18:48] <CIA-56> ffmpeg: 03Ronald S. Bultje 07master * rf3be359707 10ffmpeg/ (configure libavformat/file.c): (log message trimmed)
[18:48] <CIA-56> ffmpeg: file: Only include unistd.h if it exists
[18:48] <CIA-56> ffmpeg: It is included for the open/read/write/close functions. On
[18:48] <CIA-56> ffmpeg: MSVC, where this header does not exist, the same functions
[18:48] <CIA-56> ffmpeg: are provided by io.h, which is already included.
[18:48] <CIA-56> ffmpeg: On windows, these functions are provided by io.h. Make sure
[18:48] <CIA-56> ffmpeg: io.h is included if it exists, regardless of the setmode
[18:49] <nevcairiel> speaking about unistd.h, for some reason the matroskadec decided to require it when including the zlib header, it must be setting some weird define
[18:50] <michaelni> Daemon404, should be fixed
[18:56] <Daemon404> \o/
[18:56] <Daemon404> nevcairiel, yes
[18:56] <Daemon404> its a zlib problem
[18:57] <Daemon404> in zconf.h
[18:57] <nevcairiel> i commented out the include in zconf.h, but i felt slightly dirty :p
[18:57] <Daemon404> i think it clashes with some stuff in our config.h
[18:57] <Daemon404> iirc
[19:01] <michaelni> Daemon404, btw, ive checked all Merges, this was the only one where all commits where lost unintendedly
[19:02] <michaelni> i suspect someone pushed something before i pushed the merge and i then messedup rebasing the changes
[19:06] <Daemon404> ok
[19:06] <Daemon404> good to know
[19:52] <ubitux> mmh we can't force the codec with ffplay?
[19:53] <ubitux> ah actually -codec might do the trick
[19:55] <ubitux> seems not
[19:55] <ubitux> any way to make ffplay use the h264_vdpau decoder instead of h264?
[19:56] <ubitux> (-codec h264_vdpau doesn't work)
[19:56] <ubitux> i mean, it's still using the h264 decoder
[20:10] <michaelni> ubitux, try  -codec:v ...
[20:17] <ubitux> oh indeed, much better, thx
[20:51] <nevcairiel> RT|AO: i tried your dash, and all it did was crash :(
[21:56] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * r9b326fc261 10ffmpeg/ (3 files in 2 dirs): 
[21:56] <CIA-56> ffmpeg: flashsv2enc: fix prev-Z-prime encoding
[21:56] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[21:56] <CIA-56> ffmpeg: 03Derek Buitenhuis 07master * r3174987b42 10ffmpeg/libavcodec/flashsv2enc.c: 
[21:56] <CIA-56> ffmpeg: flashsv2enc: Replace a VLA with a heap alloc
[21:56] <CIA-56> ffmpeg: Signed-off-by: Derek Buitenhuis <derek.buitenhuis at gmail.com>
[21:56] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[21:56] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * rdbb9117d18 10ffmpeg/libavcodec/flashsv2enc.c: 
[21:56] <CIA-56> ffmpeg: flashsv2enc: move blockbuffer realloc to reconfigure_at_keyframe()
[21:56] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[21:56] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * r9b6467fd46 10ffmpeg/libavcodec/flashsv2enc.c: 
[21:56] <CIA-56> ffmpeg: flashv2enc: reallocate not only on block count changes but on dimension changes.
[21:56] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:35] <CIA-56> ffmpeg: 03Derek Buitenhuis 07master * r80d2ec6bc9 10ffmpeg/libavdevice/ (dshow_capture.h dshow_pin.c): 
[22:35] <CIA-56> ffmpeg: dshow: Change WINBOOL to BOOL
[22:35] <CIA-56> ffmpeg: WINBOOL is MinGW-specific, and since both MSVC and MinGW
[22:35] <CIA-56> ffmpeg: have BOOL, use that instead.
[22:35] <CIA-56> ffmpeg: Signed-off-by: Derek Buitenhuis <derek.buitenhuis at gmail.com>
[22:35] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:35] <CIA-56> ffmpeg: 03Derek Buitenhuis 07master * rd940b0a0f9 10ffmpeg/configure: 
[22:35] <CIA-56> ffmpeg: vf_mp: Do not build if inline assembly is not available
[22:35] <CIA-56> ffmpeg: Rather than modify the mplayer filter sources, just disable
[22:35] <CIA-56> ffmpeg: vf_mp if inline assembly is not available.
[22:35] <CIA-56> ffmpeg: Signed-off-by: Derek Buitenhuis <derek.buitenhuis at gmail.com>
[22:35] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:35] <CIA-56> ffmpeg: 03Derek Buitenhuis 07master * r5f256f9df2 10ffmpeg/libswresample/resample.c: 
[22:35] <CIA-56> ffmpeg: swsresample: Fix unprotected inline asm
[22:35] <CIA-56> ffmpeg: Signed-off-by: Derek Buitenhuis <derek.buitenhuis at gmail.com>
[22:35] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:36] <CIA-56> ffmpeg: libswr: remove redundant ARCH_X86, MMX* implicates X86
[22:36] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:46] <maister> Having a weird problem. So in a custom video codec I'm writing out packets of roughly 30k each. It's muxed in mkv or avi (both have same issue). When I get packets to the decoder they're sometimes way short (like 2 or 4 bytes, sometimes even 0). In these first bytes I can recognize some "magic" that is supposed to be there at the start. Any idea on what could be happening?
[23:01] <michaelni> maister, hmm, try valgrind
[23:02] <maister> michaelni, trying to debug in matroskaenc.c to see if there's some corruption in-between.
[23:09] <maister> ok, logged mkv_write_block. It has no short writes. Checking decoder ...
[23:23] <maister> michaelni, interesting. mkv decoder returns correct data amount as well. Smells like memory corruption indeed :\
[23:27] <saste> what happens if i change "void av_image_copy(...)" to "int av_image_copy(...)"?
[23:27] <saste> would that affect ABI?
[23:28] <ubitux> int -> void would have been a problem but the other way around i'm not sure
[23:29] <maister> Depends on the system ABI I guess. If x86 always defines eax to be volatile, it shouldn't be an issue.
[23:33] <saste> if... I remember that we already did something like that, and nobody complained
[23:34] <saste> well I'll send a patch and we'll see
[23:35] <saste> ahh PSEUDO_PAL... what an hack
[23:39] <saste> michaelni: in av_image_copy_plane(), should we check that dst can contain src?
[23:40] <saste> currently we have no check, but the function is somehow performance-sensitive so we may want  to add checks there
[23:40] <saste> or we could add asserts here and there
[23:41] <saste> *we may want *not* to add checks there
[23:42] <michaelni> saste, you want to check bytewidth against dst_linesize ?
[23:42] <saste> michaelni: that's the idea
[23:43] <saste> right now it could cause silent memory corruption
[23:43] <michaelni> i agree that some check should be added
[23:43] <saste> now the question is: asserts or regular checks?
[23:44] <saste> in the latter, I could add a return value
[23:45] <michaelni> does the operation with |linesize| < bytes ever make any sense ?
[23:45] <michaelni> not counting linesize =0 and height=1 maybe 
[23:47] <saste> michaelni: I don't think so
[23:48] <saste> i mean why it should make sense if that could possibly overwrite memory?
[23:48] <michaelni> also, if currently |linesize| < bytes means undefined behavior then a assert failure should be ok
[23:49] <michaelni> one could surely argue toward a nice check and return too but iam a but concerned that some callers wont check and propagate it correctly
[23:49] <saste> my idea was to return int to say how much data it was copied
[23:49] <saste> it could simplify API usage a bit under specific circumstances, and at almost no price
[23:49] <saste> so I could use the return value to signal errors
[23:50] <saste> but an assert is good as well, as there are not meaningful situations when that condition would make sense
[23:51] <saste> also we currently have (!dst || !src) => return
[23:52] <saste> an idea (mostly useful for av_image_copy) would be to allocate the data when !dst
[23:52] <michaelni> from a security standpoint i dont like your ideas
[23:52] <saste> uhm no that won't make much sense for av_image_copy_plane...
[23:53] <saste> michaelni: that's why I'm asking you :)
[23:53] <michaelni> :)
[23:54] <saste> oh and I hate PSEUDO_PAL in libavutil, that's senseless
[23:54] <saste> and complicating the code for no advantage
[23:55] <michaelni> If we assume that |linesize| < bytes indicates that theres some internal error and some inconsistency has been created then ii think assert is safer than a return of some error code
[23:55] <michaelni> also its simpler in terms of implementation
[23:56] <saste> yes and you don't have to check the return code every time
[23:56] <saste> assuming that the operation will be successful if the input data is consistent
[23:56] <saste> I'm still not sure about how to deal with (!dst || !src)
[23:57] <saste> the safest choice would be to just return 0, meaning that no data was copied, and no harm was done
[23:57] <maister> michaelni, nvm. I must have been retarded when I wrote the code ... const uint8_t buf_size = avpkt->size;
[00:00] --- Sat Sep  8 2012