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

[burek]

[00:43] <Timothy_Gu> Can someone explain this whole FF_QP2LAMBDA thing?
[00:44] <Timothy_Gu> From what I understand avctx->global_quality is set in "lambda" unit
[00:45] <Timothy_Gu> And ffmpeg -qscale is set in "QP" unit
[00:45] <Timothy_Gu> Right?
[00:46] <Timothy_Gu> Or maybe this should be in #ffmpeg channel...
[00:59] <michaelni> yes thats true
[00:59] <michaelni> some encoders i think use global_quality differently though
[01:01] <michaelni> the original idea was that the quality values would be codec independant rate distortion factors
[01:04] <michaelni> but for external libXYZ style encoders making the numbers passed as global quality match that libs command line tools seems to be prefered by more users & devels and or at least thats what most such encoders do 
[02:46] <cone-18> ffmpeg.git 03Michael Niedermayer 07master:ab6ea7a81921: avcodec/h264_refs: split conditions of if() up for better readability
[02:46] <cone-18> ffmpeg.git 03Michael Niedermayer 07master:e3d7a3978b85: avcodec/h264_refs: improve key frame detection heuristic
[02:59] <Timothy_Gu> Michaelni: and the ununified usage finally results in the vbr option for libfdk-aac
[03:01] <Timothy_Gu> michaelni: also what is "lambda"
[03:01] <Timothy_Gu> Well I know it is a Greek alphabet but what does it mean?
[03:06] <cone-18> ffmpeg.git 03Michael Niedermayer 07release/2.1:1141a18e89d2: avcodec/h264_refs: split conditions of if() up for better readability
[03:06] <cone-18> ffmpeg.git 03Michael Niedermayer 07release/2.1:c765b6464139: avcodec/h264_refs: improve key frame detection heuristic
[03:06] <michaelni> its a factor that weights distortion and bits together, or to say it differently the amount of added distortion you are willing to accept per 1 byte or bit smaller file
[03:07] <michaelni> i guess there are likely better explanations around. didnt try but maybe you find one when you search for rate distortion
[03:12] <michaelni> and distortion in this can be anything, from sum of squared differences to various psycho vissual and acoustic things
[03:19] <iive> http://cbloomrants.blogspot.com/2010/01/01-12-10-lagrange-rate-control-part-2.html
[03:19] <iive> (found by google).
[11:00] <plepere> so, I'm trying to make my code PIC compatible for shared libraries. I used vp8dsp.asm as reference, but I get a  "picregq undefined" when compiling.
[11:09] <plepere> ok, I found the error, but I still have a ' relocation R_X86_64_32 against `.rodata' can not be used when making a shared object' error
[11:10] <plepere> my code can be found at : http://pastebin.com/b9DiU2EA
[11:12] <plepere> basically, I put my table declarations from SECTION_RODATA with the %ifdef PIC thing, and used them like in vp8
[11:23] <plepere> but I finally get the same error as before I did the modifications
[11:47] <cone-672> ffmpeg.git 03Diego Biurrun 07master:7ffaa195704a: dsputil: x86: Move ff_inv_zigzag_direct16 table init to mpegvideo
[11:47] <cone-672> ffmpeg.git 03Michael Niedermayer 07master:be2312aa8f05: Merge remote-tracking branch 'qatar/master'
[11:47] <cone-672> ffmpeg.git 03Michael Niedermayer 07master:749eb46d643a: configure: put pthread_create() check back
[11:49] <re-G> Hi guys.
[11:49] <re-G> I used -metadata duration=123 with old 0.7 ffmpeg to set global duration metadata on destination.
[11:49] <re-G> With newer ffmpeg builds (including git head) it doesn't work any more. Is this bug or feature?
[11:50] <re-G> I found the commit which caused this: https://github.com/FFmpeg/FFmpeg/commit/714517b26a90eba208a0e3624193a7f4b8ea15af
[11:50] <re-G> container was flv
[11:51] <nevcairiel> its a feature obviously, it sets the duration based on the actual media duration it knows, and not some metadata that may or may not be correct
[11:52] <re-G> ok thanks
[11:54] <JEEB> re-G, the change itself makes sense in general, so the only way it's a bug is if it breaks something for you :P
[11:56] <re-G> :)
[12:19] <cone-672> ffmpeg.git 03Lenny Wang 07master:7b2534b0ea92: libavutil & opencl: remove opencl default device type
[13:07] <BBB> ubitux: I found it funny that your 1d idct macros had 2d names (idct4_2x2_1d or idct8_2x2_1d), that's why I changed my to be 1d again :-p
[13:08] <BBB> (given that 2x2 is 2d, not 1d; that'd be just 2)
[13:08] <ubitux> that's the 1d for the 2x2 block
[13:08] <ubitux> :p
[13:09] <ubitux> but yeah feel free to rename as you please
[13:13] <BBB> nah I'll keep it consistent for now
[13:13] <BBB> 2x2/2 is the same thing
[13:13] <BBB> maybe if we ever make assymetric 2d mixes I'll rename them
[13:13] <BBB> or not, who knows :-p
[13:14] <BBB> there's also vp9: minor refactorings in idct ssse3 assembly.
[13:14] <ubitux> oh missed that one sorry
[13:34] <BBB> I can also push this to a new branch to make merging easier
[13:34] <BBB> I'm currently looking at the 32x32 and 16x16
[13:35] <BBB> also, re: using >13 registers, I typically don't move rodata into regs beyond xmm5, because on win64 that will be slower (b/c of xmm6-15 backing up), unless you use it at least 4-6 times or so
[13:36] <BBB> I can fill up to xmm12 here I guess
[13:36] <ubitux> reviewed
[13:37] <ubitux> ok for >13 reg
[13:37] <BBB> also xmm6 is currently unused
[13:37] <BBB> because I free'ed it up in that macro
[13:38] <BBB> so we can probably change idct8 to use m6 where it previously used m12
[13:38] <BBB> and then make it use 12 instead of 13 regs
[13:38] <ubitux> that's cool :)
[13:39] <ubitux> if you drop it, you go down to 11 reg; 3 reg remaining before 32-bit can be supported? :p
[13:50] <Compn> re-G_ : i mean, if you have a patch that adds back in the feature you want, we can review it ..
[13:51] <BBB> ubitux: is 32bit important for us?
[13:51] <ubitux> for me, no
[13:52] <BBB> hm...
[13:55] <BBB> so we need to drop 5
[13:56] <BBB> my refactoring gives us 1
[13:56] <BBB> dropping rounding and 11585x2 gives us another 2
[13:56] <BBB> I think for the last two we can use stack as scratch-space on 32bit
[13:56] <BBB> let me see what I can do
[13:58] <ubitux> (oh i'm stupid, i understand why you removed the m% thing now, discregard my comment)
[14:00] <BBB> I fixed the zero double comment
[14:00] <BBB> 11585x2 can probably be split, sec
[14:02] <ubitux> don't forget to add yourself in the copyright after the split btw
[14:02] <ubitux> since you're doing changes to it
[14:03] <ubitux> (i remember you only put my name into it)
[14:03] <BBB> I'll do that after the 16x16
[14:04] <ubitux> are you doing the 16x16 before 32x32?
[14:04] <BBB> https://github.com/rbultje/ffmpeg/tree/vp9-frame-mt
[14:04] <BBB> I'm thinking about it, yes
[14:04] <BBB> 32x32 is such a bloody pain, I need to get productive again
[14:04] <BBB> so 16x16 first may be a more clever strategy
[14:04] <ubitux> :)
[14:04] <BBB> it seriously is
[14:05] <BBB> so yes, the idea for 32bit is to use [pd_round] instead of m7 as rounding argument
[14:05] <BBB> t
[14:06] <BBB> that's why it has a m as part of the argument in the macro
[14:06] <ubitux> yeah i realized that too late
[14:06] <ubitux> :p
[14:06] <BBB> whereas the others don't, so they can be used in SWAP
[14:06] <BBB> :-p
[14:06] <BBB> other patch: movq->movh done and macro renamed
[14:07] <ubitux> iirc swap support both syntax
[14:07] <BBB> I haven't done pre-loading yet, how about I make it 32bit compatible (which requires all kind of changes in this space anyway)
[14:07] <BBB> oh it does?
[14:07] <BBB> that's new
[14:07] <BBB> it used to not suppport it
[14:07] <ubitux> i see a "%ifnum ..."
[14:08] <ubitux> SWAP_INTERNAL_{NUM,NAME}
[14:08] <BBB> oh ok
[14:09] <ubitux>  <@BBB> https://github.com/rbultje/ffmpeg/tree/vp9-frame-mt // wrong branch?
[14:09] <BBB> my git is fscked up
[14:09] <BBB> I tried to push to a new branch and it wouldn't let me
[14:09] <BBB> $ git push -f github HEAD^:vp9-simd
[14:09] <BBB> error: unable to push to unqualified destination: vp9-simd
[14:09] <BBB> The destination refspec neither matches an existing ref on the remote nor
[14:09] <BBB> begins with refs/, and we are unable to guess a prefix based on the source ref.
[14:09] <BBB> error: failed to push some refs to 'git at github.com:rbultje/ffmpeg.git'
[14:09] <BBB> ??????
[14:09] <ubitux> remote "HEAD^:" ?
[14:09] <ubitux> remove*
[14:10] <BBB> I want to push HEAD^, not HEAD
[14:10] <ubitux> dunno
[14:10] <BBB> this works for frame-mt:
[14:10] <BBB> $ git push -f github HEAD^:vp9-frame-mt
[14:10] <BBB> [..] To git at github.com:rbultje/ffmpeg.git
[14:10] <BBB>  + 374bc5e...440120d HEAD^ -> vp9-frame-mt (forced update)
[14:11] <ubitux> no idea
[14:12] <BBB> https://github.com/rbultje/ffmpeg/tree/vp9-simd
[14:12] <BBB> works now
[14:12] <BBB> did some weird magic
[14:12] <BBB> brb
[14:37] <cone-672> ffmpeg.git 03Stefano Sabatini 07master:82e74ee6e486: doc/examples/filtering: make use of av_err2str()
[14:37] <cone-672> ffmpeg.git 03Stefano Sabatini 07master:55c57658d212: doc/examples/filtering_audio: add more error checks
[14:37] <cone-672> ffmpeg.git 03Stefano Sabatini 07master:a12bf9f50ff4: doc/examples/README: fix typo
[14:37] <cone-672> ffmpeg.git 03Stefano Sabatini 07master:3aa601801027: doc/examples/filtering_video: add some error handling in init_filters()
[14:37] <cone-672> ffmpeg.git 03Stefano Sabatini 07master:c7a99d99bdce: doc/examples/filtering_video: do not make use of AVBufferSinkParams
[14:39] <saste> ubitux, should we deprecate/drop buffersink_params stuff?
[14:39] <ubitux> no idea
[14:40] <saste> ubitux, also, what's wrong with filtering_audio? any reason why you didn't fix it (i see the ticket is still open)
[14:40] <ubitux> because it's not chunked
[14:40] <saste> ?
[14:40] <ubitux> chunked packets, not supported
[14:41] <ubitux> 1 packet = 1 frame currently
[14:41] <ubitux> demux/decode is wrong
[14:42] <saste> uh why? we push the frame only if we got_frame = 1
[14:43] <ubitux> we need to increment the pkt pointer according to the decode value
[14:43] <ubitux> it changes the logic
[14:44] Action: saste blames the API
[14:46] <saste> ubitux, what about refcounting? why the inconsisteny between audio and video?
[14:46] <ubitux> because i think nicolas attempted to fix the audio and not the video at some point
[14:48] <ubitux> the buffersink param thing is interesting
[14:49] <ubitux> code looks better without it :p
[14:49] <wm4> does it?
[14:50] <wm4> I'd think it's a nice way to pass the params without having to build an option string
[14:51] <ubitux> it seems you can use av_opt_set_*
[14:51] <ubitux> on the sink context
[14:51] <ubitux> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?p=ffmpeg.git;a=commitdiff;h=c7a99d99bdcec4d81a3859b0547dea7bd54bff42
[14:51] <ubitux> i'm reading this ^
[14:52] <wm4> is that even safe
[14:52] <wm4> it passes enum AVPixelFormat* to a function that expects an "int list"
[14:52] <wm4> whatever that means
[14:52] <wm4> but probably int*
[14:52] <nevcairiel> enums are always ints
[14:52] <saste> enum == int
[14:52] <wm4> not to mention that Libav doesn't have this function
[14:53] <wm4> does that make their pointer types compatible?
[14:53] <saste> wm4, yes
[14:53] <saste> libav buffersink is limited in the sense that you can't set a list of supported formats
[14:53] <saste> you have to set only one
[14:53] <wm4> then why is gcc complaining
[14:53] <saste> so it doesn't use buffersink/list_set
[14:54] <saste> not here
[14:55] <saste> the bounces guy, again!
[15:00] <ubitux> doesn't warn here either
[15:09] <wm4> well it certainly does warn here against something like "enum Foo e; int *i = &e;"
[15:09] <wm4> and gcc is probably right, because even though enums are almost ints, they're still different types
[15:10] <wm4> but I see av_opt_set_int_list() is actually a macro
[15:11] <wm4> doesn't stop it from being theoretically incorrect, lol
[15:11] <wm4> look at av_int_list_length_for_size(), that sure is some baggage
[15:15] <saste> wm4, what happened of the ffprobe patch?
[15:16] <wm4> uh I'm not sure about editing xml schemas and changing fate tests
[15:17] <ubitux> make -k fate |patch -p1
[15:17] <ubitux> it needs fate update because we check ffprobe output
[15:17] <ubitux> the diff will be obvious
[15:19] <saste> wm4, if it takes too much time for you i'll fix it, let me know
[15:19] <saste> in case you still think the feature is useful
[15:21] <ubitux> i think he did that mainly to report a bug
[15:21] <ubitux> which used that feature
[15:23] <cone-672> ffmpeg.git 03Stefano Sabatini 07master:893f33e7f005: doc/examples/filtering_audio: fix style
[15:23] <cone-672> ffmpeg.git 03Stefano Sabatini 07master:c490cd4c1ae3: doc/examples/filtering_audio: fix chunked audio decoding
[15:24] <saste> ubitux, is filtering_audio ref-counting correct?
[15:24] <ubitux> i don't think so
[15:24] <ubitux> i mean, it doesn't work iirc
[15:25] <ubitux> saste: but you know the decoding video is a cheat as i said
[15:25] <ubitux> it should have been correct
[15:25] <ubitux> it should work without my latest patch
[15:25] <ubitux> it just happens to not deal properly with ref counting
[15:25] <ubitux> without*
[15:26] <ubitux> somewhere in our api
[15:26] <ubitux> saste: FFMIN(ret, packet0.size)
[15:26] <ubitux> no?
[15:26] <saste> that would be a bug in the decoder
[15:27] <saste> bug should be fixed in the decoder, not in the application
[15:27] <ubitux> no it's not a bug iirc
[15:27] <ubitux> it just says how much it read
[15:27] <ubitux> and it might read above the packet (in the padded area) but this is expected
[15:27] <ubitux> you actually documented it in the demuxing_decoding example
[15:28] <ubitux> maybe our codec helper could do that op, if not already the case
[15:28] <saste> ubitux, not me, it was wm4
[15:29] <ubitux> ok
[15:29] <saste> but even in this case, I check for size <= 0, if ret > packet0.size it will be negative, no deal
[15:30] <ubitux> should we make the decode function do that FFMIN btw?
[15:31] <ubitux> (even though it would have read more)
[15:31] <wm4> the decoder should just return one frame for one packet
[15:31] <ubitux> it can't
[15:32] <wm4> either the codec parsers could segment the packets properly, or you could just have the decoder append to a frame
[15:33] <nevcairiel> both solutions have negative consequences
[15:33] <re-G_> Compn: ok, thanks. I'm using now my custom build and my patch just reverts the commit https://github.com/FFmpeg/FFmpeg/commit/714517b26a90eba208a0e3624193a7f4b8ea15af The commit was introduced between 0.8 and 0.9. Latest 0.8 does not include it.
[15:35] <wm4> how many codecs do this anyway? AFAIK not many
[15:40] <nevcairiel> mp3 at least
[15:41] <nevcairiel> and afaik splitting it in the parser is also a bit complicated
[15:41] <JEEBsv> re-G_: so it does break something for you?
[15:41] <JEEBsv> please explain instead of staying silent
[15:42] <nevcairiel> oh, and als is one of the codecs that definitely does it, no idea if it can be parsed though
[15:51] <re-G_> JEEBsv: i'm very sorry and quite busy now. It breaks my way to send metadata to flash element but situation is not problem for me because i can use custom build. I just wanted to know is it bug or not. :)
[15:51] <JEEBsv> so flash breaks if it doesn't get that info?
[15:52] <JEEBsv> when you get the time please explain the problem and then we can see where the problem lies and how it can be fixed in the best way possible
[15:52] <re-G_> JEEBsv: OK. Thanks a lot.
[16:28] <ubitux> i need a ufltp :X
[16:28] <ubitux> (audio sample format)
[16:29] <nevcairiel> unsigend float, why?
[16:30] <ubitux> some nasty opengl stuff
[16:31] <ubitux> i need audio values in [0;1] :P
[16:31] <nevcairiel> what does opengl do with audio?
[16:31] <nevcairiel> visualization?
[16:32] <ubitux> i'm doing that sort of thing
[16:33] <ubitux> well i guess i'll add a personnal sampler on top of it
[16:33] <ubitux> :p
[18:00] <Mavrik> hey... is there a struct to somehow signal FPS to the output codec/encoder?
[20:09] <cone-672> ffmpeg.git 03Diego Biurrun 07master:ad477710244c: build: Add shorthand for HOSTCC compile macro
[20:09] <cone-672> ffmpeg.git 03Michael Niedermayer 07master:a6c455cf6bb2: Merge commit 'ad477710244c761ad1c21246c34e0075fee12d11'
[20:23] <cone-672> ffmpeg.git 03Diego Biurrun 07master:5a9fcc7d2524: build: Add rule for building host-specific object files
[20:23] <cone-672> ffmpeg.git 03Michael Niedermayer 07master:6f9be8120d29: Merge commit '5a9fcc7d2524d6c0f86b2855019ee9f4cf360276'
[21:02] <j-b> Anyone around here looking for contract work?
[21:03] <llogan> what kind of work is it?
[21:04] <j-b> various, but mostly around codecs or VLC code
[23:03] <cone-672> ffmpeg.git 03Diego Biurrun 07master:21710ea82118: dv: Move DV VLC data tables out of header file
[23:03] <cone-672> ffmpeg.git 03Michael Niedermayer 07master:b58c1dd63268: Merge commit '21710ea82118c9d19bea9277b2a85a33096fdd95'
[23:13] <cone-672> ffmpeg.git 03Diego Biurrun 07master:97d19c2fec35: dv: Split off DV video encoder into its own file
[23:13] <cone-672> ffmpeg.git 03Michael Niedermayer 07master:830be99ae167: Merge remote-tracking branch 'qatar/master'
[23:54] <cone-672> ffmpeg.git 03Stefano Sabatini 07master:d5d51cf04dea: lavfi/volume: support all channel counts
[23:54] <cone-672> ffmpeg.git 03Stefano Sabatini 07master:6ca0ac5e5571: doc/ffserver: remove spurious NoAudio option from stream example
[00:00] --- Tue Dec  3 2013