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

burek burek021 at gmail.com
Fri Jun 20 02:05:02 CEST 2014


[01:14] <cone-261> ffmpeg.git 03Rong Yan 07master:ab12373956e9: ppc: Fix the bug of fft for little endian environment on POWER7 and later
[01:46] <j-b> a1m
[04:39] <nevcairiel> man gcc and clang are annoying, why do they only support intrinsics of a certain instruction set if the whole binary is compiled for that instruction set ....
[04:41] <Plorkyeran> isn't it only that TU that has to be compiled for that instruction set?
[04:42] <nevcairiel> annoying enough
[04:42] <nevcairiel> msvc allows me to use any intrinsics i want :p
[04:42] <Plorkyeran> quite annoying, but possible to deal with at least
[04:43] <nevcairiel> gcc apparently at least has pragmas to even do it per-function
[04:43] <nevcairiel> clang does not
[04:43] <nevcairiel> well screw mac users
[04:44] <nevcairiel> you get slower builds!
[04:46] <Plorkyeran> if you aren't being all efforty and releasing universal builds, requiring sse 4.1 on os x isn't all that unreasonable
[04:46] <nevcairiel> hm right, mac osx is generally all intel
[04:47] <nevcairiel> no stupid AMD cpus which introduced instruction sets way too late
[04:47] <nevcairiel> and i only want ssse3 right now even
[04:47] <Plorkyeran> and the first model with a 64-bit processor can't actually run any 64-bit versions of the OS
[04:48] <nevcairiel> i shall discuss it with our mac expert tomorrow
[05:00] <jamrial> i wonder what the hell was AMD thinking back in the Barcelona days. they refreshed that arch like three times and at no point they considered that maybe ssse3 and sse4.1 were worthy additions to reduce the gap with conroe/penryn/nehalem
[05:01] <jamrial> they obviously changed the strategy now with Bulldozer, where each refresh adds like two or three new intruction sets, but the damage is done nonetheless
[05:05] <Compn> was that right about when they bought ati ?
[05:06] <jamrial> no idea, but could be
[05:17] <cone-746> ffmpeg.git 03Diego Biurrun 07master:e74433a8e6fc: dsputil: Split clear_block*/fill_block* off into a separate context
[05:17] <cone-746> ffmpeg.git 03Michael Niedermayer 07master:2b05db4f8102: Merge commit 'e74433a8e6fc00c8dbde293c97a3e45384c2c1d9'
[06:00] <cone-746> ffmpeg.git 03Michael Niedermayer 07master:042a82ca374b: avcodec/x86/lossless_videodsp: Fix size of values read for left/left_top
[06:22] <cone-746> ffmpeg.git 03Christophe Gisquet 07master:e7fc5d53a02c: huffyuv: change statistics initialization
[13:14] <cone-797> ffmpeg.git 03James Almer 07master:fe782233aa6a: x86/blockdsp: move asm code out of dsputil
[13:24] <cone-797> ffmpeg.git 03James Almer 07master:454c019cb536: x86/hevc_idct: fix movd parameter size in DC_ADD_INIT
[13:24] <cone-797> ffmpeg.git 03James Almer 07master:60a06400a9fa: configure: fix NASM output format on Win64
[13:31] <cone-797> ffmpeg.git 03James Almer 07master:4c9ee1590feb: lavf/Makefile: fix standalone compilation of live_flv demuxer
[13:51] <BBB> michaelni: Ive got resample_common_float_sse ported to yasm, I can push to github for review& cant merge yet, until avx/linear are also done, but that should be relatively minor (theyre just trivial variations of the same theme afaics)
[13:55] <michaelni> you could post a patch with [WIP] or so, i suspect more people read the mailing list than look at github
[14:08] <BBB> ok done
[14:09] <BBB> Ill do the linear version next
[14:09] <BBB> then avx last (that should be very trivial)
[14:57] <cone-797> ffmpeg.git 03Michael Niedermayer 07master:08c5859f17ed: avcodec: add simpleauto idct
[15:17] <cone-797> ffmpeg.git 03Dirk Ausserhaus 07master:b2290bf10b12: i263: skip dummy frames
[15:17] <cone-797> ffmpeg.git 03Michael Niedermayer 07master:47c8d1e174b8: Merge commit 'b2290bf10b12b7772f55fcab014a47e18e9fdef2'
[18:06] <cone-797> ffmpeg.git 03Diego Biurrun 07master:852c329a69dd: configure: Drop duplicate pkg-config entry from help output
[18:06] <cone-797> ffmpeg.git 03Michael Niedermayer 07master:a68c05cf13c9: Merge commit '852c329a69ddfd635807f60454df07d021c64901'
[18:31] <wm4> does decoding on AVSubtitle always set a copy?
[18:31] <wm4> or can the AVSubtitle have pointers to data that will be freed or reused on the next decode call?
[18:39] <cone-797> ffmpeg.git 03James Almer 07master:a5ce608fc7ea: x86/blockdsp: restore author attribution
[19:17] <cone-797> ffmpeg.git 03Carl Eugen Hoyos 07master:891307b4d194: s86/scale: Do not return the result of a (void) function from a void function.
[19:27] <J_Darnley> I am shocked, SHOCKED(!), to discover that ffmpeg doesn't have signed 8-bit audio.
[19:31] <J_Darnley> Now then, I wonder if I am allowed to modify the input AVFrame in a filter...
[19:39] <J_Darnley> OMFG!  Damn docs!  Will you just stay disabled!
[19:48] <wm4> J_Darnley: well yes
[19:48] <wm4> J_Darnley: you must make it writable first
[19:49] <wm4> J_Darnley: there's a function in frame.h for this
[19:49] <wm4> it'll copy the frame if needed
[19:50] <J_Darnley> Oh yeah, silly me.  I've read about that.
[19:50] <J_Darnley> I'll just write into my own buffer then.
[19:52] <wm4> write into your own buffer, and then write again into the output frame?
[19:53] <J_Darnley> No, I'm talking about the audio input of an a->v filter
[20:17] <nevcairiel> audio frames should always be writeable, they dont really have references much
[20:17] <nevcairiel> but of course there is the API to tell you
[20:26] <cone-797> ffmpeg.git 03Michael Niedermayer 07master:5bf5e6b1c0fd: avcodec/h264: Use named identifier for single thread fall-back return from ff_h264_decode_slice_header()
[20:54] <cone-797> ffmpeg.git 03Gaullier Nicolas 07master:650ef180787d: avformat/utils: better probing for duration in estimate_timings_from_pts()
[21:10] <tab1293> I am trying to learn how to use libavcodec to encode a video stream in an application I want to write. I am very new to ffmpeg and it doesn't seem like there is much documentation on the website. Anyone have any suggestions on how I should go about learning how to use libavcodec?
[21:11] <nevcairiel> there are a bunch of examples in the source tree
[21:11] <nevcairiel> ie in doc/examples
[21:11] <Daemon404> doxygen too
[21:11] <Daemon404> on the siye
[21:11] <Daemon404> site
[21:12] <tab1293> okay let me check that out. But any resources available that provide more of a conceptual overview of the framework and how to use it?
[21:13] <nevcairiel> i think i saw something like that in the docs
[21:14] <tab1293> alright I'm grabbing the source now
[21:18] <Daemon404> ubitux, i have no works for the "bash" fix
[21:18] <Daemon404> (he uses "bash" to mean "shell" i think)
[21:21] <cone-797> ffmpeg.git 03Michael Niedermayer 07release/2.2:f378636d90af: avformat/mp3enc: drop redundant and uninitialized variable
[21:28] <tab1293> how do I build the docs? I tried running make doc in the doc folder but that doesn't work
[21:31] <Daemon404> http://ffmpeg.org/doxygen/trunk/
[21:33] <tab1293> but what about the texi files how do I generate the documentation from those?
[21:33] <Daemon404> configure and make?
[21:33] <Daemon404> theyre also all on the website
[21:33] <Daemon404> all of this is linked from the documentation page
[21:33] <Daemon404> also this belong in #ffmpeg
[21:41] <nevcairiel> speaking of examples, wasnt there an invalid api usage patch floating around
[21:41] <nevcairiel> whatever happened to that
[21:45] <nevcairiel> oh right it was about re-using the context
[21:47] <Daemon404> i wrote it
[21:47] <Daemon404> its been ignored since feb
[21:52] <michaelni> Daemon404, pinged the question you ignored
[21:55] <wm4> AFAIK the plan on libav side seems to be to remove codeccontexts completely from libavformat?
[21:56] <wm4> also, I can't understand how reusing the codec context can work
[21:56] <wm4> what if parameters change?
[21:57] <nevcairiel> thats why its not safe
[21:57] <nevcairiel> changes to parameters are out of sync
[21:57] <Daemon404> michaelni, ? my client shows it as  responded
[21:57] <nevcairiel> well technically you never answered the question other then "anton said so" :P
[21:57] <michaelni> Daemon404, yes with "According to Anton, we should never reuse it from there.
[21:57] <michaelni> He give me the reason why, but it is buried in my IRC logs
[21:57] <michaelni> somewhere (old patch is old)."
[21:58] <michaelni> but thats no way to explain what a patch does
[21:58] <nevcairiel> iirc, the reason is that a demuxer/parser can change the info during demuxing, while the decoder is still a couple frames behind and that would get messy
[21:59] <Daemon404> worst case is the example shows more api usage
[21:59] <michaelni> such a demuxer / parser is broken and violating API
[21:59] <Daemon404> which is hardly bad
[22:00] <Daemon404> using copy_context fixed a crash/bug i had in my code
[22:00] Action: Daemon404 looks for that
[22:01] <Daemon404> i think it was what nevcairiel said
[22:01] <michaelni> showing more api usage is a mixed bag, yes i agree its good to have more stuff covered by examples but then the doing X example should show X and not additionally things that confuse the reader
[22:02] <michaelni> examples should be minimal
[22:03] <michaelni> or it should be clearly documented what is optional in them
[22:04] <michaelni> the context split / copy is recent so it surely worked fine for a long time without it
[22:06] <Daemon404> it was never explicitly documented to work for decoding iirc
[22:06] Action: Daemon404 stabs grep
[22:07] <michaelni> there sadly was alot that wasnt documented
[22:08] <michaelni> but comparing long time ago to now i think docs have improved quite a bit
[22:09] Action: J_Darnley pasive-agressively mentions his emails about filters
[22:12] <michaelni> J_Darnley, maybe try to submit the code as git patch, might result in more comments
[22:14] <J_Darnley> I'll try that, sometime soon(ish)
[22:52] <cone-797> ffmpeg.git 03James Almer 07master:05d95c53a70f: alpha/blockdsp: move clear_blocks out of dsputil
[23:30] <J_Darnley> michaelni: thanks for your reply
[23:40] <miep1> I know I should ask this question on #ffmpeg, but nobody there seems to be awake. Is there anyone here who can point me to the right direction on how to use the #ffmpeg libraries to implement an audio-stripper? The idea is to take a video and strip the audio in an android app. I can NDK compile the libraries and call them with JNI, but now I'm left to implement the C-part, and I can't really find my way through the doc/example(s)
[23:44] <michaelni> just drop audio packets
[23:45] <nevcairiel> yeah that should be pretty easy, look at the demuxing and muxing examples, and just drop the audio in the middle
[23:53] <llogan> [matroska @ 0x181c400] Using AVStream.codec.time_base as a timebase hint to the muxer is deprecated. Set AVStream.time_base instead
[23:53] <llogan> that's going to freak out users like that other deprecated message
[23:54] <nevcairiel> easy enough fixed
[00:00] --- Fri Jun 20 2014


More information about the Ffmpeg-devel-irc mailing list