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

[burek]

[01:15] <cone-233> ffmpeg.git 03Michael Niedermayer 07master:9ccc7aeeea1b: doc/Doxyfile: use 5 columns for alphabetical index
[01:42] <cone-233> ffmpeg.git 03Timothy Gu 07master:5b58692ed4a7: swresample: misc. doxy improvements
[01:55] <cone-233> ffmpeg.git 03Michael Niedermayer 07master:0ebcf878032f: protect unistd.h with #if HAVE_UNISTD_H in code from recent av_bprint_fd_contents() patches
[02:03] <cone-233> ffmpeg.git 03Michael Niedermayer 07master:39ea21713c54: avcodec/libxvid: add HAVE_UNISTD_H around #include <unistd.h>
[02:03] <cone-233> ffmpeg.git 03Michael Niedermayer 07master:1574eedd0e91: tools/yuvcmp: add HAVE_UNISTD_H around #include <unistd.h>
[02:03] <cone-233> ffmpeg.git 03Michael Niedermayer 07master:307239bdb629: ffserver: add HAVE_UNISTD_H around #include <unistd.h>
[02:44] <cone-233> ffmpeg.git 03Timothy Gu 07master:865a76108186: doc: add doxy-wrapper.sh to doc/doxygen/html dependencies
[02:44] <cone-233> ffmpeg.git 03Timothy Gu 07master:cee98aadb129: doc: make doxygen program configurable
[02:44] <cone-233> ffmpeg.git 03Timothy Gu 07master:8e6a66b6625c: doc: add doxygen target tag
[03:03] <cone-233> ffmpeg.git 03Michael Niedermayer 07master:0dbcecc8dc6b: avdevice/oss_audio: Add #if HAVE_UNISTD_H around  #include <unistd.h>
[03:03] <cone-233> ffmpeg.git 03Michael Niedermayer 07master:576ced55309f: avfilter/vf_drawtext: Add #if HAVE_UNISTD_H around  #include <unistd.h>
[03:03] <cone-233> ffmpeg.git 03Michael Niedermayer 07master:0ffba9feb649: avutil/cpu: Use HAVE_UNISTD_H instead of HAVE_SYSCONF for #include <unistd.h>
[03:03] <cone-233> ffmpeg.git 03Michael Niedermayer 07master:5c7bf354dc0c: avcodec/crystalhd: Add #if HAVE_UNISTD_H around  #include <unistd.h>
[03:31] <ejl> is there an explanation anywhere of what SSE2_PERM and MMX_PERM do?
[03:33] <BBB> they permute the coefficient matrix scantable
[03:33] <BBB> to make it transparent to the codec what the ideal permutation is for that particular optimization
[03:34] <BBB> sse2perm is a full 8x8 transpose of the normal scantable
[03:34] <ejl> ah
[03:34] <BBB> mmxperm is basically grid-transpose, where the 8x8 scantable is divided into 2x2 subsquares, each of which is 4x4 coefficients - each such 4x4 subblock is then transposed
[03:36] <ejl> I'm looking at porting an SSE2 version of j_rev_dct but it does the vertical pass without transposing, so I guess NO_PERM
[03:37] <BBB> I guess (I havent ever looked at that implementation so I wouldnt know)
[03:38] <BBB> typically a scantable matrix transpose helps because it is free (since stores of coefficients are scalar-based anyway), but saves an actual transpose in the idct itself
[03:40] <cone-233> ffmpeg.git 03Diego Biurrun 07master:a9aee08d900f: dsputil: Split off FDCT bits into their own context
[03:40] <cone-233> ffmpeg.git 03Michael Niedermayer 07master:14e2406de7d2: Merge commit 'a9aee08d900f686e966c64afec5d88a7d9d130a3'
[03:40] <ejl> yeah this one doesn't transpose though
[03:43] <ejl> http://pastebin.com/rL5WzT5W   original version
[03:44] <ejl> I think the temps can be eliminated on x64
[09:09] <durandal_1707> i get error when compiling
[09:10] <durandal_1707> gmake: *** No rule to make target `libavcodec/x86/dsputil_qns_template.c', needed by `libavcodec/x86/dsputilenc_mmx.o'.  Stop.
[09:10] <plepere> good morning
[10:02] <ubitux> why is config_propos in vf fps settings the link w/h?
[10:03] <ubitux> durandal_1707: git clean -fdx?
[10:03] <durandal_1707> yea
[10:03] <ubitux> or just rm/edit the appropriate .d
[10:34] <ubitux> michaelni: about the backward b-frame mv blocks in the vismv representation, do they need a different interpretation from the pf & bf, or that's just a classification for debug?
[10:34] <ubitux> like, do they actually represent a move from the previous frame?
[10:37] <ubitux> i've displayed the bb in a few videos and it's not really obvious if they are actually following the overall movement
[10:37] <ubitux> (they are generally small and somehow look pretty random)
[13:18] <michaelni> ubitux, backward motion vectors point to future frames
[13:18] <michaelni> otherwise there should be no magic with them
[13:56] <cone-338> ffmpeg.git 03Andrew Kelley 07master:d3cfd7aff86e: af_compand: make sure request_frame always outputs at least one frame
[13:56] <cone-338> ffmpeg.git 03Michael Niedermayer 07master:e1f729d977be: Merge commit 'd3cfd7aff86ee3d449ca68aba21d67b9b2136a9b'
[14:07] <ubitux> michaelni: so if i'm exporting the mvs i should make no distinction with the direction?
[14:08] <ubitux> like i can squash all the pf/bf/bb in one side data without exporting that "type" information?
[14:09] <michaelni> well, interpreting mvs might need the direction, depends on what one does with them
[14:10] <michaelni> also backward ones would be in the opposit direction when printed id expect
[14:11] <ubitux> i was going to store the block size, absolute source position and absolute dest position
[14:11] <ubitux> i guess i can switch the source and dest in case of backward?
[14:14] <michaelni> i dont know the details of your format but it also needs some kind of information about which reference frame is used, (h264 would allow more than 1 and in B frames forward and backward flipped point to different frames)
[14:17] <ubitux> michaelni: so when displaying the mvs with -vismv, only the pf actually make sense?
[14:18] <michaelni> they all make sense to me 
[14:19] <michaelni> maybe we should use a different color for backward ones or for how far the reference frame is away
[14:21] <ubitux> in the case of pf, it's always the mvs between previous frame and current frame that are displayed?
[14:41] <cone-338> ffmpeg.git 03Roman Savchenko 07master:3d90f27ad584: avformat_new_stream: make the AVCodec parameter const
[14:41] <cone-338> ffmpeg.git 03Michael Niedermayer 07master:70b423e1484f: Merge commit '3d90f27ad5843ccd63d34fd6da4d4bff212c1bfe'
[14:58] <ubitux> mmh actually the pf might have a few (b) frames after the reference it's using, right?
[14:59] <michaelni> ubitux, for mpeg2 PF MVs can come from 2 fields which may be part of seperate frames
[15:00] <ubitux> mmh
[15:00] <michaelni> B frames can reference I and P frames before and after (in time)
[15:01] <michaelni> or better said B frames can reference I/P frames before and after it in pressentation time but of course not in decode time
[15:01] <michaelni> references must be available to the decoder before they can be used ...
[15:01] <michaelni> h264 also allows B frames to reference other B frames
[15:01] <michaelni> so do "post h264" codecs
[15:02] <ubitux> assuming no interlacing and no slicing, if you have let's say IBBBP, you get 5 complete frames out of it, and the P frame is actually constructed from moving blocks from the I frames, so 4 frames earlier, right?
[15:02] <ubitux> from the I frame*
[15:03] <michaelni> if IBBBP is meant in presentation order so that its transmitted as IPBBB then yes the P frames uses the I frame as reference
[15:04] <ubitux> ok
[15:05] <ubitux> it will always be transmitted as IPBBB, or it's allowed to transmit with nasty delay like in presentation order?
[15:07] <michaelni> i mpeg1/2 mpeg4-asp you get I(some B frame could be here)PBBB 
[15:08] <michaelni> h264 can do pretty much any order as long as references are available before use
[15:08] <michaelni> so i think h264 could do IBBBP but then the B frames couldnt use the P frame
[15:09] <michaelni> so in h264 backward MVs could in this case then actually point in the same direction as forward ones
[15:10] <michaelni> i think h264 doesnt use the forward/backward terms though (maybe for that reason)
[15:13] <ubitux> ok :)
[15:13] <ubitux> thx
[15:19] <plepere> hmm
[15:20] <plepere> I still see no improvement of using AVX2. :/
[15:40] <Daemon404> ffprobe.c:2535: warning: dereferencing pointer id does break strict-aliasing rules
[15:40] <Daemon404> ffprobe.c:2536: warning: dereferencing pointer id does break strict-aliasing rules
[15:40] <Daemon404> has ffprobe always had these warnings?
[15:40] Action: Daemon404 doesnt remember them
[15:45] <cone-338> ffmpeg.git 03Martin Storsjö 07master:79fce1ec8abd: arm: Avoid using the 'setend' instruction on ARMv7 and newer
[15:45] <cone-338> ffmpeg.git 03Michael Niedermayer 07master:1f935c3d0b8c: Merge commit '79fce1ec8abd017593c003917fc123f7119a78d6'
[16:38] <cone-338> ffmpeg.git 03Michael Niedermayer 07master:5a4edf6f0db7: avformat/movenc: check that the video resolution is supported
[16:38] <cone-338> ffmpeg.git 03Michael Niedermayer 07master:a981d1b6aae9: avformat/nutdec: if all else fails try to lookup video tag in isom
[16:53] <Daemon404> michaelni, once i add 10bit utvideo support, do you see a reason to keep libutvideo*.cpp
[16:54] <Daemon404> i regret writing it.
[16:54] <ubitux> reference comparison purposes?
[16:54] <Daemon404> ubitux, the biggest no-no for me is that we need to use a fork of Ut Video
[16:55] <Daemon404> upstream doesnt actually build on unix anymore
[16:55] <Daemon404> ubitux, reference comparison seems like a cruddy reason to keep such a bad piece of code
[16:55] <Daemon404> c++ nonetheless
[16:55] <ubitux> okay
[16:55] <ubitux> i thought it was interesting for bugs & benchmarks
[16:56] <saste> Daemon404, about ffprobe, the warnings are added by some new compiler versions, I can't see them here
[16:56] <ubitux> but i never used it so i'm not really concerned
[16:56] <Daemon404> saste, gcc version 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC)
[16:56] <Daemon404> "new"
[16:56] <Daemon404> lol
[16:57] <saste> Daemon404, gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1
[16:57] <ubitux> doesn't warn with 4.9 here
[16:57] <ubitux> 4.4 was probably confused at enum being int or something
[16:58] <Daemon404> ubitux, ffmpeg doesnt even compile properly with 4.9.0
[16:58] <Daemon404> so irrelevant
[16:58] <Daemon404> :D
[16:58] <ubitux> works fine here ;)
[16:58] <Daemon404> 4.9.0 miscompiled golomb stuff didnt it
[16:58] <ubitux> yes, but it's fixed somehow
[16:59] <Daemon404> that's... terrifying really
[16:59] <Daemon404> it's fixed "somehow"
[17:00] <ubitux> in gcc i mean
[17:01] <Daemon404> ah
[17:01] <Daemon404> its fixed in svn yes
[17:01] <Daemon404> i mean the tarball of 4.9.0 is broken
[17:02] <ubitux> ah, seems my distro is using a snapshot
[17:02] <ubitux> _snapshot=4.9-20140604
[17:02] <Daemon404> yeah
[17:02] <Daemon404> i built my own mingw gcc from tarballs, or openembedded toolchains
[17:18] <cone-338> ffmpeg.git 03Michael Niedermayer 07master:fe4c76b3d09f: avcodec/roqvideoenc: fix infinite lambda increasing loop
[17:44] <cone-338> ffmpeg.git 03Michael Niedermayer 07master:7c7441b37de1: avcodec/roqvideoenc: check dimensions against maximum
[17:47] <ubitux> michaelni: "Dimensions are max 32768", did you mean 65535x65535?
[17:47] <michaelni> yes
[17:47] <michaelni> i meant what i commited ;)
[17:47] <michaelni> theres also "Warning: dimensions not power of two"
[17:48] <ubitux> i mean 32768 ` 65535
[17:48] <michaelni> yes, but it only allows powers of 2
[17:48] <ubitux> ah, okay
[17:49] <michaelni> hmm actually theres a error message if its not power of 2 but no error return /:
[17:53] <michaelni> seems the power of 2 test was there that way from the original commit and seems to work with 65520x128 (with our decoder)
[18:10] <cone-338> ffmpeg.git 03Michael Niedermayer 07master:7cb8f7ded418: avcodec/proresenc_anatoliy: check against maximum dimensions
[18:55] <Navion> Any Audacity users here? I'm using OSX 10.9.3 on a new mac pro interfaced for playback over firewire (Thunderbolt to FW800 Apple adapter cable) to a Presonus StudioLive 16.4.2AI. Audacity stutters like crazy. If I start another audio application like VLC (in record) or Audition, the audio from Audacity sounds clean. Is there a missing part in Audacity? Maybe to do with timing?
[18:58] <gnafu> I think I can safely say that this is not the place to ask, but good luck with your endeavor!
[18:59] <Navion> Yeah, I know but I'm desperate. I posed to the #audacity group too but no replies.
[18:59] <gnafu> That's the most likely place you'll find Audacity help on IRC, I expect.  Otherwise, you might try their mailing list.
[19:00] <Navion> Thanks
[19:01] <gnafu> Navion: A quick question for you before we end this topic (since it is out of place here): have you tried using your PreSonus with Linux?
[19:02] <gnafu> I think I've seen they should work in general, but I wondered how well.
[19:03] <Navion> gnafu: I haven't. It really seems to be an Audacity specific problem. As far as Presonus working with Linux in general, they seem to be on top of things so I'd be surprised if it was really broken. I don't have any Linux machines with FW interfaces though.
[19:08] <StarBrilliant> I was just reading the ffmpeg source code
[19:08] <StarBrilliant> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/subtitles.c#L92
[19:08] <StarBrilliant> for (i = 0; i < q->nb_subs; i++) if (q->subs[i].duration == -1 && i < q->nb_subs - 1)
[19:09] <StarBrilliant> is there any reason of not writing it directly as for (i = 0; i < q->nb_subs - 1; i++)  ?
[19:09] <StarBrilliant> it does multiple comparisions within each loop
[19:10] <gnafu> Navion: Cool, thanks.  My church has a couple PreSonus boards, and I have dreams of eventually interfacing them with a Linux machine :-).
[19:12] <Navion> Wow! I "Fixed" it. I change the buffer to 300 ms from the 100 ms default. I can't imagine I'm out of CPU but maybe OSX isn't scheduling the process running Audacity for realtime. 
[19:12] <Navion> I recommended the Presonus board to a church group here. The meter bridge feature is really useful for them.
[19:14] <Navion> Argh! It's back... It fixed it for about a minute not it's back to stuttering.
[19:55] <michaelni> Daemon404, about libutvideo support, it could be usefull as reference as ubitux says, so iam slightly in favor to keep it unless it causes some non trivial work, but you are the author and maintainer of it so its your decission ...
[20:24] <cone-338> ffmpeg.git 03Michael Niedermayer 07master:550bda741cfe: avcodec/alpha/dsputil_alpha: fix build
[21:04] <cone-338> ffmpeg.git 03Michael Niedermayer 07master:eee6ad38f99a: avdevice/lavfi: add io.h, should fix msvc build
[21:38] <cone-338> ffmpeg.git 03Luca Barbato 07master:52a1c32c0a86: nut: Use nut->version in the version range check
[21:38] <cone-338> ffmpeg.git 03Michael Niedermayer 07master:a26ecba07514: Merge commit '52a1c32c0a86e84d43f977c5148e62975a0c6917'
[21:52] <cone-338> ffmpeg.git 03Martin Storsjö 07master:cf280ed004b5: avplay: Handle pixel aspect ratio properly
[21:52] <cone-338> ffmpeg.git 03Michael Niedermayer 07master:839688bc63e1: Merge commit 'cf280ed004b5c618560f8f43d14ff264bd1e4c3d'
[22:03] <cone-338> ffmpeg.git 03Martin Storsjö 07master:18fb38fb9ea7: mov: Remove a variable that is set but never used
[22:03] <cone-338> ffmpeg.git 03Michael Niedermayer 07master:fd3388d63d8e: Merge commit '18fb38fb9ea7e2d5997c096fccfcd4cb43f70294'
[22:16] <jamrial> michaelni: lavf/segment.c is missing a HAVE_SYS_TIME_H check
[22:18] <cone-338> ffmpeg.git 03Alexander V. Lukyanov 07master:863595433506: avformat/mpegts: pass MpegTSContext ptr explicitly (fixes #3721)
[23:00] <cone-338> ffmpeg.git 03James Almer 07master:2375b094734e: alpha/idctdsp: move idct init code out of dsputil
[23:00] <cone-338> ffmpeg.git 03Michael Niedermayer 07master:7125b6ca90d4: avformat/segment: remove gettimeofday() use, remove sys/time.h
[00:00] --- Wed Jul  9 2014