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

burek burek021 at gmail.com
Thu Feb 16 02:05:03 CET 2012


[00:18] <ubitux> saste: you were right, i just using ts2str() instead of ts2timestr() in silencedetect
[00:23] <CIA-48> ffmpeg: 03Clément BSsch 07master * rd3b06399ff 10ffmpeg/libavfilter/af_silencedetect.c: lavfi/silencedetect: use av_ts2timestr() macro.
[00:44] <CIA-48> ffmpeg: 03Michael Niedermayer 07master * re7dbfa59f2 10ffmpeg/libswscale/x86/swscale_mmx.c: 
[00:44] <CIA-48> ffmpeg: swscale: enable some more SIMD functions.
[00:44] <CIA-48> ffmpeg: They no longer just segfault.
[00:44] <CIA-48> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[00:44] <CIA-48> ffmpeg: 03Paul B Mahol 07master * r83e2e9315a 10ffmpeg/libavcodec/ffv1.c: 
[00:44] <CIA-48> ffmpeg: ffv1: PIX_FMT_GRAY8 support
[00:44] <CIA-48> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[00:44] <CIA-48> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[00:47] <ubitux> i may have found a way to do a "build only"
[00:48] <ubitux> makeopts="FATE=" might do the trick
[00:48] <ubitux> since make fate FATE= doesn't run anything
[00:50] <ubitux> 'going to give it a try
[02:14] <CIA-48> ffmpeg: 03Diego Biurrun 07master * r9d03cb9fc5 10ffmpeg/libswscale/ (swscale_internal.h x86/swscale_mmx.c): swscale: Remove some write-only variables related to alpha handling.
[02:14] <CIA-48> ffmpeg: 03Paul B Mahol 07master * r1c77a5307f 10ffmpeg/libavformat/smjpegdec.c: 
[02:14] <CIA-48> ffmpeg: smjpegdec: implement seeking
[02:14] <CIA-48> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[02:14] <CIA-48> ffmpeg: Signed-off-by: Diego Biurrun <diego at biurrun.de>
[02:14] <CIA-48> ffmpeg: 03Martin Storsjö 07master * rdf6050188c 10ffmpeg/libavformat/movenchint.c: 
[02:14] <CIA-48> ffmpeg: movenc: Use defines instead of hardcoded numbers for RTCP types
[02:14] <CIA-48> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[02:14] <CIA-48> ffmpeg: 03Diego Biurrun 07master * rc3b57d6e76 10ffmpeg/ (4 files in 2 dirs): 
[02:14] <CIA-48> ffmpeg: librtmp: Add "lib" prefix to librtmp URLProtocol declarations.
[02:14] <CIA-48> ffmpeg: This allows easily differentiating between both implementations within the build
[02:14] <CIA-48> ffmpeg: system and combining the native implementation for plain RTMP with librtmp for
[02:14] <CIA-48> ffmpeg: the RTMPE, RTMPS, RTMPT, RTMPTE protocol variants.
[02:14] <CIA-48> ffmpeg: 03Janne Grunau 07master * rbf61ef2316 10ffmpeg/libavcodec/rv34.h: 
[02:14] <CIA-48> ffmpeg: rv34: use uint16_t for RV34DecContext.deblock_coefs
[02:14] <CIA-48> ffmpeg: It is used as bitfield with 16 entries.
[02:14] <CIA-48> ffmpeg: 03Janne Grunau 07master * r29330721b0 10ffmpeg/libavcodec/rv34.c: 
[02:14] <CIA-48> ffmpeg: rv34: use AVERROR return values in ff_rv34_decode_frame()
[02:14] <CIA-48> ffmpeg: Also adds an error message.
[02:14] <CIA-48> ffmpeg: 03Janne Grunau 07master * rb54b40b33c 10ffmpeg/libavcodec/rv40.c: rv40: prevent undefined signed overflow in rv40_loop_filter()
[02:14] <CIA-48> ffmpeg: 03Janne Grunau 07master * r2bd730010d 10ffmpeg/libavcodec/rv34.c: 
[02:14] <CIA-48> ffmpeg: rv34: handle size changes during frame multithreading
[02:14] <CIA-48> ffmpeg: Factors all context dynamic memory handling to its own functions.
[02:17] <Aaron_M> what's the right way to make interlacing info (whether or not a stream is interlaced) available inside a codec's parser?
[06:05] <red_wolf> hi. I want to try the ass filter, but while "./configure ... --enable-libass ..." shows ass in "Enabled filters", "./ffmpeg -filters" does not list ass in its supported filters. why?
[06:08] <relaxed> red_wolf: user questions belong in #ffmpeg
[06:08] <red_wolf> sorry.
[10:27] <CIA-48> ffmpeg: 03Clément BSsch 07master * r95317821ea 10ffmpeg/libavutil/audioconvert.c: audioconvert: consistent use of FF_ARRAY_ELEMS for channel_layout_map.
[10:27] <CIA-48> ffmpeg: 03Clément BSsch 07master * rcba4e2cbbc 10ffmpeg/libavfilter/af_pan.c: 
[10:27] <CIA-48> ffmpeg: pan: fix uninitialized channel_id variable.
[10:27] <CIA-48> ffmpeg: Fix broken parsing with pan=2:FL=FR:FR=FL and similar.
[12:10] <ubitux> devices are handled exactly the same as formats?
[12:11] <ubitux> found an interesting doxy, nevermind
[13:36] <ubitux> ### Compiler Error in file /home/ux/fate/ffmpeg/libavfilter/libmpcodecs/vf_fspp.c during Code_Expansion phase:
[13:36] <ubitux> ### ASM constraint <o> not supported
[13:36] <ubitux> mmh.
[13:36] <ubitux> seems vf_fspp is back again.
[13:37] <ubitux> michaelni: i added an open64 instance
[13:37] <ubitux> but seems to fail as states the message above
[16:25] <Compn> ffmpeg -i http://93.91.54.5:8001 -acodec copy -vcodec copy blah.ts
[16:25] <Compn> that work for anyone ?
[16:28] <Compn> i get [mpegts @ 0248AB00] Application provided invalid, non monotonically increasing dts to muxer in strea
[16:28] <Compn> but i'm also using older ffmpeg
[16:34] <^sandro^Zzz> hey has anyone succeeded in grabbing a udp://:port input using juts x264 ?
[17:14] <Compn> anyone remember how to fix the "non monotonically increasing dts to muxer" problem ?
[17:30] <michaelni> ubitux, does it work if you disable libmpcodecs or libavfilter ?
[17:32] <ubitux> how can i disable mpcodecs?
[17:33] <ubitux> oh, disable-filter=mp should do.
[17:33] <Compn> ubitux : what asm is it using in open64 ?
[17:34] <Compn> why not yasm/nasm ?
[17:34] <ubitux> it's inline asm, i don't know what's the assembler
[17:34] <Compn> the assembler is failing
[17:35] <Compn> what version, why not use yasm/nasm
[17:35] <ubitux> can yasm/nasm be used for inline asm?
[17:35] <Compn> oh, i dunno :D
[17:35] <ubitux> :)
[17:36] <Compn> ubitux : btw someone said --disable-optimizations build was broken, want to add a autobuild for that ?
[17:36] <ubitux> sure, ok
[17:38] <ubitux> added
[17:55] <ubitux> Compn: 'seems it worked
[17:57] <^sandro^Zzz> can anyone help me
[17:57] <^sandro^Zzz> with ffmpeg
[17:57] <^sandro^Zzz> [mp2 @ 0x2356360] Header missing
[17:57] <^sandro^Zzz> Error while decoding stream #0:3
[17:57] <^sandro^Zzz> [udp @ 0x23078e0] circular_buffer: OVERRUN
[17:57] <^sandro^Zzz> PES packet size mismatch.0 size=      46kB time=00:00:00.43 bitrate= 877.3kbits/s dup=1304 drop=0    
[17:57] <^sandro^Zzz> [mpegts @ 0x23073a0] PES packet size mismatch
[17:59] <ubitux> arg i don't know what's wrong with open64, it gets killed for random reasons...
[17:59] <ubitux> and i don't see any particular reason for
[18:07] <ubitux> line 110: Warning: Variable atom in fucntion read_kuki_chunk might be used uninitialized
[18:08] <ubitux> nice, a compiler with typo in error messages
[18:08] <ubitux> :D
[18:13] <Compn> ubitux : guess we dont need to autobuild it then, thanks for testing :)
[18:13] <Compn> lol
[18:13] <ubitux> well, it doesn't hurt
[18:31] <michaelni> ubitux, if all else fails you could try disable asm or optimizations for open64
[19:14] <ubitux> michaelni: i think the main issue now is that it gets killed randomly (sig9)
[19:14] <ubitux> the memory usage isn't heavy at all, no swap, nothing in the logs
[19:14] <ubitux> i have no idea what's happening
[20:00] <^sandro^Zzz> hello everyone
[20:00] <^sandro^Zzz> anyone have any idea how to capture a UDP sat channel and output to .ts
[20:01] <^sandro^Zzz> im doing ffmpeg -i udp://@:5000 but 
[20:01] <^sandro^Zzz> it keeps on giving me buffer overun errors
[20:12] <CIA-48> ffmpeg: 03Nicolas George 07master * rbd5080b1b0 10ffmpeg/libavfilter/af_pan.c: af_pan: comment a tricky piece of code.
[21:39] <CIA-48> ffmpeg: 03Michael Niedermayer 07master * r60991ad6ae 10ffmpeg/ffmpeg.c: 
[21:39] <CIA-48> ffmpeg: ffmpeg: Fix image allocation.
[21:39] <CIA-48> ffmpeg: This probably fixes some of the use of uninitialized issues valgrind shows in fate.
[21:39] <CIA-48> ffmpeg: It might also fix other issues.
[21:39] <CIA-48> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[21:39] <CIA-48> ffmpeg: 03Michael Niedermayer 07master * r25893ad6c9 10ffmpeg/libavcodec/ffv1.c: 
[21:39] <CIA-48> ffmpeg: ffv1: Warn the user if transparency is stored.
[21:39] <CIA-48> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[21:47] <pasteeater> beastd: did you ever mail your poster idea to ffmpeg-devel mailing list?
[21:48] <beastd> pasteeater: yes, i did. in reply to the CLT announcement. maybe i should have changed the subject to attract more readers.
[21:50] <pasteeater> what was the subject?
[21:50] <beastd> maybe i'll bump it later. or else just work further on it on my own. somehow many people i cannot really handle sketches ^^
[21:51] <pasteeater> the poster size should be A0 which is 1189x841 mm
[21:53] <beastd> oh as you say it. i think i forgot to mention it should be A0 and the minimum recommended resolution
[22:05] <^sandro^Zzz> hello.. anyone very familiar with UDP steaming
[22:05] <^sandro^Zzz> raw mpeg2 data
[22:09] <^sandro^Zzz> http://pastebin.com/ELPhg7VB  < ---- anyone know what is wrong.. other encoders seem to be receiving the signal properly.. i think its just ffmpeg on this one.. im stuck for over a week now
[22:11] <pasteeater> ^sandro^Zzz: you asked this at #ffmpeg, which is the right place, but you don't need to paste the same question in here too
[22:14] <^sandro^Zzz> ok
[22:14] <^sandro^Zzz> not sure if it is a developemnt issue
[22:14] <^sandro^Zzz> i think its a bug
[22:14] <vadim> ^sandro^Zzz: yes, it is... and a quite old one... 
[22:15] <vadim> dear developers... maybe you will find some time to solve this http://ffmpeg.org/trac/ffmpeg/ticket/609
[22:28] <^sandro^Zzz> did the fifo thing 
[22:28] <^sandro^Zzz> http://pastebin.com/vrAGvUN8
[22:28] <^sandro^Zzz> but nwo i get that
[22:29] <^sandro^Zzz> its complaining about something dup
[22:29] <^sandro^Zzz> duplicate frames
[22:29] <^sandro^Zzz> or something like that.
[22:29] <^sandro^Zzz> thats libx264
[22:29] <^sandro^Zzz> the frames are the same in a udp stream aren't tehy.. being sent from a device
[22:31] <vadim> ^sandro^Zzz: I confirm that the workarround described in ticket 609 does not work... any way it's a open bug
[22:32] <^sandro^Zzz> well that puts everything on hold
[22:33] <^sandro^Zzz> any other way to capture the UDP://@:port traffic and transcode it to h264
[22:33] <^sandro^Zzz> well i want it to .ts file
[22:33] <^sandro^Zzz> but at a lower bit rate
[22:36] <^sandro^Zzz> is there another capture / encoder that can be sued
[22:36] <^sandro^Zzz> that is good and stable ?
[22:36] <vadim> try VLC
[00:00] --- Thu Feb 16 2012


More information about the Ffmpeg-devel-irc mailing list