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

burek burek021 at gmail.com
Tue Dec 25 02:05:02 CET 2012


[00:54] <cone-367> ffmpeg.git 03Clément BSsch 07master:00ebac6dfdcb: doc: stop generating syntax.html.
[00:54] <cone-367> ffmpeg.git 03Clément BSsch 07master:98dc25672fb7: lavc/pthread: do not re-define _GNU_SOURCE if already defined.
[01:39] <cone-367> ffmpeg.git 03Stefano Sabatini 07master:86c6bf040bd3: doc/filters: remove outdated comments
[01:58] <cone-367> ffmpeg.git 03Michael Niedermayer 07master:eeb111d364c6: Changelog: reword H264-MT entry
[02:10] <michaelni> Coverity SCAN is down for installing new version.
[02:10] <michaelni> Coverity SCAN will be up in 16 Hours, 34 Minutes, 57 Seconds. 
[02:10] <michaelni> 57 seconds LOL
[02:29] <ubitux> :D
[02:49] <Compn> hmm
[02:50] <Compn> i'm not getting the joke
[02:50] <Compn> whats the 57 seconds ?
[02:52] <ubitux> it's very accurate
[02:52] <ubitux> and given the timescale (16 hours)
[02:52] <ubitux> that's a bit ridiculous
[02:52] <michaelni> Compn, --> http://scan5.coverity.com:8080/
[02:53] <Compn> >javascript
[03:01] <cone-367> ffmpeg.git 03Michael Niedermayer 07master:d4d8d4f786d9: rl2: return EOF on EOF
[03:58] <ubitux> channel mapping in lavr, haha :)
[04:45] <Compn> vlc made slashdot :P
[04:46] <Compn> j-b : do you have a puter with windows8 ?
[04:46] <Compn> or w8 install
[04:50] <cone-367> ffmpeg.git 03Michael Niedermayer 07master:98b7a50a2100: tiffdec: Fix runend handling
[04:55] <Compn> ehe slashot people remember ios app too
[04:55] <j-b> Compn: lol
[04:59] <Compn> oh kierank is part of this too
[04:59] <j-b> Compn: yep
[04:59] <Compn> we can bug him about w8 now 
[04:59] <j-b> lol.
[05:01] <j-b> Compn: w8 is a bitch and we hate it. But we need to adapt before it is used widely
[05:01] <Compn> yeah i understand
[05:01] <Compn> i dont want to learn it
[05:01] <Compn> but i guess i better try it so i can fix my grandmothers pc
[05:01] <Compn> but they both bought ipads. so i'm good for a while :P
[05:02] <Compn> cant even transfer a file to an ipad, how useful
[05:02] <j-b> crazy stupid
[05:03] <j-b> I hate those new devices
[05:03] <Compn> its weird relying on so many free services on the ipad
[05:03] <Compn> cloud storage, email, etc
[05:04] <Compn> like they can just snatch those away whenever they want
[05:04] <Compn> pay up... or else
[05:12] <michaelni> ubitux, win32 has "vf_pp.o : error LNK2019: unresolved external symbol _pp_get_mode_by_name_and_quality referenced in function _pp_init"
[05:13] <michaelni> (the red one on fate)
[05:14] <michaelni> freebsd: av_interleaved_write_frame(): No space left on device :)
[05:14] <ubitux> huh
[05:15] <ubitux> what sorcery is this
[05:17] <michaelni> ubitux, about win32 no idea, i didnt look
[05:17] <ubitux> i'm even surprised vf pp actually got built
[05:19] <ubitux> postprocessing support    yes
[05:20] <ubitux> mp isn't enabled though, maybe because of inline asm dep
[05:24] <michaelni> maybe Daemon404(not here) or nevcairiel know what is missing for pp on win32  
[05:25] <ubitux> the symbols are globally set, postproc dll is well built, postproc dep from lavfi appears in the .pc here, &
[05:25] <ubitux> i don't get it
[05:31] <michaelni> i think this will need someone with a win32-msvc devel environment or knowledge ...
[05:31] <ubitux> :(
[05:31] <ubitux> 05:31:42 [freenode] ::: Inviting Daemon404 to #ffmpeg-devel
[05:32] <michaelni> but if you want to fix it yourself you could try to setup the needed env
[05:33] <michaelni> IIRC msvc command line compiler is available for download from MS
[05:33] <michaelni> i dunno if its enough or how exactly to set it up
[05:45] <ubitux> michaelni: postproc looks handled a bit differently in the configure
[05:45] <ubitux> like not being part of the LIBRARY_LIST
[05:46] <ubitux> not sure if that matters
[05:50] <ubitux> what's the idea behing the postproc version mess?
[05:59] <ubitux> ok i need beastd
[06:00] <ubitux> 79f80f5c1f6e292af5d6413600e7129d36cb9be6  i don't get how that is really relevant
[10:46] <burek> vlc is giving me this error when i instruct it to use ffmpeg as the audio encoder ( aenc=ffmpeg{codec=libaacplus} )
[10:46] <burek> [libaacplus @ 0x2749620] nb_samples (0) != frame_size (2048) (avcodec_encode_audio2)
[10:47] <burek> what does that error mean
[10:49] <burek> when i try with ffmpeg, it works without any warnings/errors: ffmpeg -f alsa -i dsnooped -c:a libaacplus -ab 32k -ac 2 -ar 44100 out.flv
[13:21] <burek> i was git bisecting vlc to find out where does some segfault occur for the first time
[13:21] <burek> and found out that this http://git.videolan.org/?p=vlc.git;a=blobdiff;f=modules/codec/avcodec/encoder.c;h=73f5dd3a21a39707bf0bca04b65623bab9704607;hp=86acd339debc74a701c776b9fde376f6d3d1a797;hb=f41ea01243;hpb=99ba52e3d2fe94122d9c08734975d99d630f409d
[13:21] <burek> o man.. what a link
[13:21] <burek> anyway
[13:22] <burek> the only change was
[13:22] <burek> -    avcodec_free_frame( &frame );
[13:22] <burek> +    av_freep( &frame );
[13:22] <burek> is av_freep a vlc's function or ffmpeg's ?
[13:35] <kierank> Compn: i am just the middleman for the money
[13:38] <Compn> burek : av_* is usually ffmpegs
[13:48] <burek> Compn, thanks :) i guess that means that the bug is in ffmpeg after all
[13:48] <burek> most probably some null pointers or so
[14:52] <cone-843> ffmpeg.git 03Luca Barbato 07master:7e98956e721a: hlsenc: correctly report target duration
[14:52] <cone-843> ffmpeg.git 03Luca Barbato 07master:f5f1cf522407: oggdec: K&R cosmetic formatting
[14:52] <cone-843> ffmpeg.git 03Michael Niedermayer 07master:c6664242e070: Merge commit 'f5f1cf52240759208b42477e2157a7b4409ade10'
[15:22] <cone-843> ffmpeg.git 03Luca Barbato 07master:ba064ebe4837: oggdec: check memory allocation
[15:22] <cone-843> ffmpeg.git 03Diego Biurrun 07master:ed40b6bf0734: configure: cosmetics: Separate hwaccel dependencies from decoders/encoders
[15:22] <cone-843> ffmpeg.git 03Diego Biurrun 07master:f3298f12997e: Return proper error code after av_log_ask_for_sample()
[15:22] <cone-843> ffmpeg.git 03Michael Niedermayer 07master:d69238e99184: Merge commit 'f3298f12997eb4b7ad203766f768f92e3dd72a2a'
[15:38] <cone-843> ffmpeg.git 03Diego Biurrun 07master:5af53731d978: avfilter: Compile FIFO filters unconditionally
[15:38] <cone-843> ffmpeg.git 03Martin Storsjö 07master:0940580adb5e: lavc: Correct the description of pkt_dts
[15:38] <cone-843> ffmpeg.git 03Stefano Sabatini 07master:3193b13aa1e2: hlsenc: Allocate enough space for the pattern string
[15:38] <cone-843> ffmpeg.git 03Michael Niedermayer 07master:ba8e909c8251: Merge commit '3193b13aa1e271f6d2dd68de67d448c08aef3c00'
[15:54] <cone-843> ffmpeg.git 03Martin Storsjö 07master:4a9f7d2bf9fb: hlsenc: Don't duplicate a string constant
[15:54] <cone-843> ffmpeg.git 03Anton Khirnov 07master:3eab60075240: bmp: cosmetics, reformat
[15:54] <cone-843> ffmpeg.git 03Anton Khirnov 07master:f6e395e1320c: c93: set palette_has_changed.
[15:54] <cone-843> ffmpeg.git 03Anton Khirnov 07master:c6303f8d70c2: yop: simplify/sanitize the decoding loop
[15:54] <cone-843> ffmpeg.git 03Michael Niedermayer 07master:9dbedf331eca: Merge commit 'c6303f8d70c25dd6c6e6486c78bf99c9924e2b6b'
[16:24] <cone-843> ffmpeg.git 03Anton Khirnov 07master:8adfacff5c45: zmbv: remove some pointless comments and empty lines
[16:24] <cone-843> ffmpeg.git 03Anton Khirnov 07master:261f0b14ed81: zerocodec: remove an unused variable.
[16:24] <cone-843> ffmpeg.git 03Anton Khirnov 07master:99e36ddd3ee5: ansi: do not depend on get_buffer() initializing the frame.
[16:24] <cone-843> ffmpeg.git 03Anton Khirnov 07master:51648da4dc7a: xan: remove a trivially true if().
[16:24] <cone-843> ffmpeg.git 03Anton Khirnov 07master:0a9132b84c05: wnv1: cosmetics, reformat
[16:24] <cone-843> ffmpeg.git 03Michael Niedermayer 07master:7681b8e9a922: Merge remote-tracking branch 'qatar/master'
[16:47] <wm4> why does ffmpeg need endian-dependent pixel formats? do most decoders not use native-endian? rawvideo could swap the pixel data on its own
[16:47] <wm4> audio formats works like this too
[16:52] <wm4> also the 9-14 bit formats could just be shifted and be 16 bit instead (then the LSB instead of the MSB would be set to 0 and unused)
[16:52] <wm4> this would easily drop the pixel format count by how much, 25%?
[16:53] <wm4> or rather 75% (other way around)
[17:30] <nevcairiel> ubitux: i briefly looked at the pp shared build failure, and for some reason it doesnt add the import library for postproc to the linker command
[17:31] <ubitux> thanks nevcairiel 
[17:31] <ubitux> i wonder if it's not one of the consequence of not having it as part of the LIBRARY_LIST
[17:31] <ubitux> i sent a patch to fix that (but it's reverting a "feature")
[17:31] <ubitux> not sure if that will help
[17:35] <nevcairiel> possibly
[17:35] <nevcairiel> i could easily try
[17:35] <nevcairiel> gimme a sec
[17:39] <michaelni> wm4, we "need" endian dependant pixel formats, for example because what is stored in containers is in bytes not native intXY also its easier for doing bitexact regression tests
[17:41] <michaelni> about 9-14, yes it could be all just a 16bit format, this is also what i wanted
[17:45] <nevcairiel> as long as it still stores the native bitdepth somewhere, like with S32 audio which can also just be shifted 24-bit, i would be fine with that myself
[17:46] <nevcairiel> ubitux: no luck, your patch doesnt fix it, if i remember i'll try to look into why it fails  when i have some more time again
[17:47] <ubitux> :(
[17:47] <ubitux> thx nevcairiel :)
[18:33] <cone-843> ffmpeg.git 03Michael Niedermayer 07master:e9c4f36c5282: lavf/mpeg: suppress warning: lpcm_header_len may be used uninitialized in this function
[18:33] <cone-843> ffmpeg.git 03Michael Niedermayer 07master:70d5cd103a72: mcdec: suppress "warning: a/vst may be used uninitialized in this function"
[18:58] <wm4> michaelni: why would you need endian swapped formats for regression tests? endian swapping is a lossless operation
[19:26] <burek> i like these weird kind of bugs
[19:26] <burek> during the grab of webcam video + audio, using vlc (but using ffmpeg as encoder for libaacplus), most of the time video starts streaming normally, but after some times it just stops
[19:27] <burek> now i degraded both vlc and ffmpeg to certain revisions, that i know work on another machine
[19:27] <burek> and now everything is just working normally :)
[19:27] <burek> so... how can i now file a bug report based on nothing :)
[19:28] <wm4> burek: first test which combination of new/old vlc/ffmpeg causes the issue, then bisect the one that's causing it
[19:30] <burek> it's a bit more complicated than that :) vlc has got additional issues, beside this one, which i did git bisect and narrowed down the exact commit version that introduced it, but now i need to bisect ffmpeg
[19:30] <burek> to see which version will introduce this exact bug im interested in
[19:30] <burek> but, i need to let the streaming play for some time in order to see if it will stop after some time
[19:30] <burek> which is really inconvenient for testing..
[19:33] <burek> i guess i could do 1 bisect per day :) it might be a good indicator if something works or not, i guess :)
[19:52] <michaelni> wm4 CRC of a file changes if it stores native endian 16bit integers, the regressio tests should produce the same CRC on big and little endian though
[19:52] <wm4> michaelni: is that with rawvideo output?
[19:54] <kierank> 15:52:11 <wm4> also the 9-14 bit formats could just be shifted and be 16 bit instead (then the LSB instead of the MSB would be set to 0 and unused)
[19:54] <kierank> 15:52:32 <wm4> this would easily drop the pixel format count by how much, 25%?
[19:54] <kierank> it was like that before
[19:54] <kierank> it's hugely wasteful though
[19:54] <kierank> there are benefits to keeping things in 10-bit in swscale and x264
[19:54] <wm4> actual bit size could still be provided as additional information?
[19:54] <kierank> you avoid unnecessary shifts on large files
[19:55] <kierank> still means the shift has to be done
[19:56] <wm4> so, these formats are the "easiest" for the actual decoders?
[19:56] <kierank> yes
[19:57] <wm4> are there any concrete numbers known how much of a performance win introducing these special formats gave?
[19:59] <kierank> dunno
[19:59] <kierank> there are some swscale operations which require > 16-bit for 16-bit files but are within 16-bit for 10-bit
[20:10] <michaelni> almost all cases touching these 16bit samples do a shift at the end already
[20:10] <michaelni> that is 9-16bit or 8bit or anything
[20:10] <michaelni> shifting differently wont be slower
[20:11] <michaelni> if one wants to clean out the lowwer bits so they are 0 it would need an additional and that masks them out
[20:13] <michaelni> as is with 9-14bit one needs cliping that could be done for free in many SIMD instruction sets if all was 16bit
[20:33] <michaelni> "there are some swscale operations which require > 16-bit for 16-bit files but are within 16-bit for 10-bit" // one can also use the faster operations for 9-1Xbit that are stored as 16bit
[20:34] <michaelni> s/can/could/
[20:34] <wm4> about the endian formats - so _why_ are they needed? audio works fine without internal endian sample format alternatives
[20:36] <michaelni> try to replace s16le (in grep and replace style) for the fate tests (there are 97 matches of s16le) with s16be
[20:36] <michaelni> fate should fail
[20:36] <michaelni> its what would happen on big endian if there was no LE format support
[20:37] <wm4> I see no s16le in libavutil/samplefmt.h
[20:38] <michaelni> true, if what you mean is to drop endian specific pixel formats and introduce a rawvideo codec id for each endian X pixel format, that should work in theory
[20:39] <wm4> yes
[20:40] <kierank> michaelni: but you still have to shift to begin with
[20:42] <michaelni> depends
[20:43] <michaelni> if the code used 16*16->(low)16bit then you would have to shift but this style should have precission problems already
[20:43] <michaelni> for 16*16->(high)16bit having the input aligned with the MSB could actually be easier to work with
[20:44] <michaelni> for 16x16->32 it probably doesnt matter how the input is shifted you can adjust the coefficient
[20:59] <michaelni> hmm, for the last case there could be need for a shift if theres no unsigned 16x16->32 instruction available
[21:11] <ubitux> huh, didn't Anton broke ABI by removing {src,cur,out}_buf from avfilter.h:AVFilterLink?
[21:11] <wm4> lol thinking that this is under ABI
[21:12] <wm4> everyone actually using lavfi externally probably killed himself already
[21:13] <ubitux> there is never a need to read a field from the links?
[22:00] <iive> well, cleanup == api/abi breakage.
[22:03] <ubitux> i mean without deprecating time
[22:52] <cone-115> ffmpeg.git 03Michael Niedermayer 07master:bd16f0a331eb: avfiltergraph: put variables used in #if 0 code themselfs under #if 0
[22:52] <cone-115> ffmpeg.git 03Michael Niedermayer 07master:ec40d15d823c: oggdec: fix warning: assignment discards qualifiers from pointer target type
[00:00] --- Tue Dec 25 2012


More information about the Ffmpeg-devel-irc mailing list