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

[burek]

[00:23] <cone-444> ffmpeg.git 03Mickaël Raulet 07master:fdb20db64259: hevc/rext: put a warning log message instead of an error log message
[00:23] <cone-444> ffmpeg.git 03Mickaël Raulet 07master:e1e3ec9b02ca: hevc: fix transquant_bypass
[04:05] <cone-371> ffmpeg.git 03Timothy Gu 07master:69c7aad49468: oss_audio: use a macro to simplify ioctl() error checking
[04:32] <cone-371> ffmpeg.git 03Diego Biurrun 07master:e0a2e60c0a6c: dct-test: Reuse enum idct_permutation_type instead of duplicating it
[04:32] <cone-371> ffmpeg.git 03Michael Niedermayer 07master:a86d527c8b37: Merge commit 'e0a2e60c0a6cbcceef08e94af5081d2aa8e6a52f'
[05:38] <cone-371> ffmpeg.git 03Michael Niedermayer 07master:76899be11355: swscale/swscale_internal: add needed version.h
[05:38] <cone-371> ffmpeg.git 03Michael Niedermayer 07master:e9f7c7aef96d: sws: Move fast bilinear C code into seperate file
[05:38] <cone-371> ffmpeg.git 03Michael Niedermayer 07master:6532a1a8286e: sws/x86: split mmxext fast bilinear scaler out
[05:45] <jamrial> michaelni: isn't the above change going to break msvc?
[05:45] <michaelni> why ?
[05:45] <jamrial> you removed HAVE_<opt>_INLINE guards when you moved the functions to the new file, and added it as part of OBJS instead of MMX-OBJS in Makefile
[05:47] <jamrial> you need to either put the guards back, or make the file be part of MMX-OBJS
[05:47] <jamrial> assuming it works and i'm not missing anything, the latter is probably cleaner
[05:54] <cone-371> ffmpeg.git 03Michael Niedermayer 07master:d5ee3580d84a: sws: move inline asm hscale to MMX_OBJS
[05:54] <michaelni> jamrial, fixed i hope
[06:30] <Timothy_Gu> Yay! Customized ffmpeg doc with texi2any/makeinfo with db0's new website stype is working!
[06:30] <Timothy_Gu> *style
[06:30] <Timothy_Gu> I'll submit a pull request when I have time (tomorrow or next week)
[07:37] <jamrial> michaelni: it didn't fix. it's tries to build the file and of course fails at it
[07:38] <jamrial> so just re-add the guards
[07:39] <jamrial> also we should probably look into fixing arch.mak so MMX-OBJS files are not compiled when inline asm is disabled
[10:37] <berzerka> how can i check against the libavcodec version macros?
[10:38] <wm4> berzerka: include libavcodec/version.h and use LIBAVCODEC_VERSION_INT and AV_VERSION_INT
[10:38] <berzerka> does something like #if(LIBAVCODEC_VERSION < 55280000) work?
[10:39] <berzerka> wm4: what is the difference between the two?
[10:39] <wm4> LIBAVCODEC_VERSION is a string
[10:39] <berzerka> ok
[10:39] <wm4> you need LIBAVCODEC_VERSION_INT
[10:39] <wm4> and build the version number with AV_VERSION_INT
[10:40] <berzerka> ok thank you
[10:40] <berzerka> ah i see it AV_VERSION_INT(a, b, c) (a<<16 | b<<8 | c)
[10:40] <berzerka> got it
[10:40] <wm4> meh that macro is in bad style
[10:40] <wm4> doesn't put the parameters into ( )
[10:41] <berzerka> but basically that's how it works, i will just use the macro provided.
[12:55] <mustafa_muhammad> Hi, I used static builds from http://ffmpeg.gusari.org/static/ and from http://johnvansickle.com/ffmpeg/ with exactly the same parameters and got very differnt results
[12:56] <mustafa_muhammad> The file size of the result of ffmpeg.static.64bit.2014-07-15 from http://ffmpeg.gusari.org/static/ is normal, 27MB.
[12:58] <mustafa_muhammad> But the file size of the result of ffmpeg-git-20140718-64bit-static from http://johnvansickle.com/ffmpeg/ is 201MB
[12:58] <mustafa_muhammad> I used vp9 codec with no audio, and I think there is a big problem in this build
[13:03] <nevcairiel> You should ask the people doing those builds, we have no way to check every build around the web
[13:06] <mustafa_muhammad> relaxed: Hi, I think this is your build?
[13:06] <mustafa_muhammad> nevcairiel: I asked here because these two static builds are on the download page of ffmpeg
[13:32] <cone-472> ffmpeg.git 03Michael Niedermayer 07master:54cba3f53efd: swscale/x86/hscale_fast_bilinear_simd: add inline asm guards
[13:45] <cone-472> ffmpeg.git 03Nidhi Makhijani 07master:d6e1d37100af: oss_audio: Split muxer and demuxer
[13:45] <cone-472> ffmpeg.git 03Michael Niedermayer 07master:80acedae3ed5: Merge commit 'd6e1d37100af568211f28ec0bcf7958a3a2a299e'
[13:55] <cone-472> ffmpeg.git 03Diego Biurrun 07master:85cabb8d002f: fdct: Move x86-specific declarations to a header in the x86 directory
[13:55] <cone-472> ffmpeg.git 03Michael Niedermayer 07master:6da96a9fc9cf: Merge commit '85cabb8d002f2cd100ced5cc17d87bfc9460d314'
[14:07] <ubitux> mustafa_muhammad: probably debug symbols
[14:09] <wm4> ubitux: he complains about the size of the _produced_ file, I think
[14:10] <cone-472> ffmpeg.git 03Diego Biurrun 07master:5dcc201505f7: simple_idct: Move x86-specific declarations to a header in the x86 directory
[14:10] <cone-472> ffmpeg.git 03Michael Niedermayer 07master:776647360db3: Merge commit '5dcc201505f71b1e73e9eef12ce89d4eed252ad0'
[14:10] <wm4> i.e. a vp9 file encoded with the builds
[14:12] <ubitux> ah mmh sorry
[14:12] <ubitux> well, not linking with the same libvpx then :p
[14:12] <ubitux> maybe.
[14:12] <wm4> maybe
[14:16] <cone-472> ffmpeg.git 03Diego Biurrun 07master:1a583c0c6024: fdct: Move ppc-specific declarations to a header in the ppc directory
[14:16] <cone-472> ffmpeg.git 03Michael Niedermayer 07master:7bdbd2653fdd: Merge commit '1a583c0c60240adb8fa6620c6df33f1a0a0fe5d9'
[14:23] <mustafa_muhammad> ubitux: wm4: Yes, I am talking about the resulting files.
[14:30] <cone-472> ffmpeg.git 03Christophe Gisquet 07master:5e55c7e1bcb7: hevc: report more precise progress
[14:43] <BBB> mustafa_muhammad: probably want to ask that in #vp8 (or #vp9), since that seems like a libvpx issue
[14:43] <BBB> mustafa_muhammad: but just in general, unless you tell us how you attempted to encode the files (what settings, commandline arguments, &), theres not much we can help with
[14:44] <BBB> it sounds like encoder defaults were changed
[14:44] <BBB> mustafa_muhammad: also, putting the two files up for upload may help analyze, or telling us something about the source material, number of frames, reported bitrate, etc.
[14:50] <mustafa_muhammad> BBB: This is the command and its output http://pastie.org/9405065
[15:04] <cone-472> ffmpeg.git 03Christophe Gisquet 07master:8da1defe6986: libavutil: document side effects of macros
[15:15] <ubitux> "The unaligned variants [of AV_[RW][BLN](16|24|32|48|64)] are AV_[RW][BLN][8-64]" 
[15:15] Action: ubitux doesn't get something
[15:16] <wm4> just say that the ones with A suffix require aligned pointers
[15:16] <wm4> and AV_COPY etc. look so weird, should they be used at all
[15:17] <ubitux> ok, so it's missing a '*U'
[15:21] <BBB> ubitux: AV_WN32A vs. AV_WN32
[15:21] <BBB> so missing A, not U
[15:21] <BBB> and then oddly, AV_COPY32 is actually aligned again
[15:21] <BBB> Im not sure why
[15:23] <kurosu> well I was not pleased with the documentation either, but mostly because it didn't sound as much clearcut as phrased
[15:38] <cone-472> ffmpeg.git 03Christophe Gisquet 07master:7a4a5515b0ce: hevc: use intreadwrite
[15:42] <wm4> also I wonder what's the point of this (hevc: use intreadwrite) patch is
[15:43] <wm4> apparently no speed advantage, and looks less readable and probably is more UB-prone
[15:43] <wm4> well, I don't know the hevc decoder, so I probably better shut up
[16:14] <rmklp> is there already an avutil function that converts AVCodecContext.flags or flags2 into something human-readable?
[16:24] <wm4> rmklp: I don't think so... if there is, it'd be a function that converts an avopt value to a string, but I don't see such a thing in libavutil/opt.h
[16:26] <rmklp> ok, thanks. Ill look around some more but since I do not know any place in the CL tools where something like this is output, I think there is a fair chance it just isnt there.
[17:19] <cone-472> ffmpeg.git 03Michael Niedermayer 07master:ba80b8d29b2a: avcodec/hevc: check nb_cpb
[17:46] <cone-472> ffmpeg.git 03Michael Niedermayer 07master:d13a731fc149: avcodec/hevc_ps: Check abs_delta_rps
[19:05] <kierank> how the hell can malloc be segfaulting
[19:08] <wm4> on random memory corruption?
[19:35] <michaelni> valgrind should be able to identify the cause
[19:50] <kierank> is libavfilter meant to depened on libavcodec still?
[19:51] <nevcairiel> It used to for a while unconditionally, but I thought that was fixed
[19:52] <ubitux> it's optional
[19:52] <ubitux> afaik
[19:52] <nevcairiel> Unless you use one of the filters that use avcodec directly
[19:52] <kierank> I still get errors about avcodec_find_best_pix_fmt_of_2
[19:52] <kierank> which is used in avfiltergraph.c
[19:53] <nevcairiel> I thought we had that in avutil now with a new name
[19:53] <nevcairiel> Maybe the patch rots on the ML
[19:53] <kierank> I thought too
[19:55] <kierank> we do it seems
[19:55] <kierank> but why I have it different in my repo I dunno
[20:11] <ubitux> Timothy_Gu: we're currently looking at setting it up on the server, but we've some trouble with the lessc insanity :p
[20:11] <ubitux> Timothy_Gu: we'll also likely squash all the commit so we can destroy the upload of generated dist in the history
[20:13] <ubitux> btw, should i look at integrating the new css to http://coverage.ffmpeg.org/ ?
[20:13] <ubitux> what about fate?
[20:26] <kierank> turns out I was using av_free instead of avcodec_free_context()
[20:39] <Daemon404> woo... ffmpeg built with clang-cl
[20:42] <cone-472> ffmpeg.git 03Michael Niedermayer 07master:d9ddbaa9245c: avfilter/avfilter: use av_malloc(z)_array()
[20:43] <cone-472> ffmpeg.git 03Michael Niedermayer 07master:a7bb22c5aaba: avformat/seek: use av_malloc_array()
[21:47] <cone-472> ffmpeg.git 03Michael Niedermayer 07master:cb169126c5ee: avformat/dvenc: Implement 32khz & 44.1khz for 25/50fps
[22:09] <kierank> the parameter for 44.1 audio are very complicated for ntsc
[22:10] <michaelni> :(
[22:10] <ubitux> Timothy_Gu: ping for the doc
[22:41] <rcombs> so, a note: we (Plex, Inc.) are looking into working with Intel to move forwards on a potential solution for getting QuickSync hardware encoding and decoding available in redistributable versions of ffmpeg
[22:46] <wm4> lol hardware encoding?
[22:46] <Mavrik> rcombs, hmm, isn't QuickSync available mostly only on Windows?
[22:47] <rcombs> wm4: it's fast and CPU-cheap!
[22:48] <rcombs> Mavrik: the libs are also available on Linux, and OS X has some sort of a facility for it (it's used for AirPlay mirroring from Macs), but I'm not sure of the details there
[22:48] <wm4> I think lu_zero did something with quicksync
[22:48] <wm4> but not sure what
[22:49] <Mavrik> hmm, the Linux part is news to me.
[22:49] <rcombs> there's a fork that had support, but because the libs are currently considered nonfree (accurately), it's not redistributable
[22:49] <rcombs> https://trac.ffmpeg.org/ticket/2591 see ticket
[22:51] <rcombs> we'll be working with Intel to see if either a GPL-compatible library can be released, or if their lawyers can determine whether or not the Media SDK can fall under the GPL System Library exception
[22:52] <rcombs> no promises, but we'd really like to see this implemented and available for redistribution, so I'll notify in here and comment on that ticket if something useful comes up
[22:52] <ubitux> can anyone tell me what's the difference between the source snapshot and the git snapshot?
[22:52] <ubitux> (on our download page)
[22:53] <rcombs> source snapshot is just the working tree; git snapshot includes git history
[22:53] <ubitux> ah, simply, ok
[22:54] <michaelni> rcombs, ok, thanks, more FLOSS is always good
[22:54] <rcombs> (this is explained on the page)
[22:54] <rcombs> to be painfully honest, I think it's more likely that they'd try to take the System Library exception route, based on previous conversations, but we'll see
[23:29] <cone-472> ffmpeg.git 03Michael Niedermayer 07master:d84abf35c0f3: swscale/utils: remove unused define
[23:29] <cone-472> ffmpeg.git 03Michael Niedermayer 07master:b53bdae11f1e: swscale/utils: fix rgb -> fullrange yuv
[00:00] --- Sun Jul 20 2014