[FFmpeg-devel-irc] IRC log for 2010-04-04

[irc at mansr.com]

[05:09:16] <_av500_> Christos voskres!
[05:13:46] <pentanol> sup sup
[07:19:01] <CIA-1> ffmpeg: siretart * r22795 /trunk/libavcodec/zmbv.c:
[07:19:01] <CIA-1> ffmpeg: Avoid division by zero
[07:19:01] <CIA-1> ffmpeg: Based on clang-scan report http://permalink.gmane.org/gmane.comp.video.ffmpeg.devel/107290
[08:01:34] <KotH> salut
[10:27:35] <twnqx> koth: vhdl looks so bloated
[10:28:29] <peloverde> I always much prefered the verilog
[10:32:14] * KotH hates verilog
[10:32:40] <KotH> vhdl is very verbose and you've to type quite a bit of info twice, but at least the language is consistent (unlike verilog)
[10:32:48] <twnqx> umm
[10:32:55] <twnqx> it uses /= where != belongs
[10:33:05] <KotH> that's because it's not c
[10:33:11] <twnqx> and & as concatenation is a terrible choice in a logic language
[10:33:14] <KotH> vhdl's origins are in ada, not c
[10:33:21] <KotH> no it's not
[10:33:35] <KotH> it's only because you are used to c derived languages
[10:33:36] <twnqx> i was wondering for quite some time why he'd AND the constants...
[10:34:08] <KotH> forget whatever you know about c, java, etc when you work with vhdl
[10:34:19] <KotH> 1) it's ada based (which is a totally different beast than c)
[10:34:24] <KotH> 2) it's a dataflow language
[10:34:36] <KotH> 3) it's a simulation, not a hardware design language
[10:35:49] <twnqx> mh
[10:36:33] <twnqx> so why do people use if for hardware design?
[10:36:43] <KotH> because they can :)
[10:37:23] <KotH> back in the days, when vhdl and verilog were conceived, nobody thought about using them for building hardware, but rather to simulate and verify their designs
[10:37:41] <KotH> there werent any synthesis tools, everything was done by hand
[10:38:31] <KotH> ie, you'd first simulate your device on various levels (behavioural, rtl, gate, transistor) and verify that your design worked as you expect it to, then draw single transistors and gates in a different tool
[10:38:38] <twnqx> indexOut <= (B"0" & T) + (B"0" & Y); <-- he's adding a zero in front of T and Y, so the addition doesn't overflow?
[10:39:03] <KotH> direct synthesis out of vhdl/verilog started iirc in early 90s
[10:39:40] <KotH> no, he is adding a 0 infront of T and Y because indexOut is a longer signal than T and Y
[10:39:49] <twnqx> yeah, i know... so you'd use vhdl as the behavioural, then verilog as the RTL?
[10:39:57] * twnqx always wrote both in verilog
[10:39:58] <KotH> unlike C, vhdl does not do any type casting
[10:40:30] <KotH> actually, it cannot do type casting because the simulator/synthesiser does not know what types your signals represent
[10:40:47] <twnqx> i would not want "types" in my circuits anyway
[10:41:04] <KotH> no, you do behavioral and rtl in the same language.
[10:41:18] * twnqx uses integers in verilog only for test layers
[10:41:23] <KotH> it's just that verilog was designed for pretty much the same use as vhdl was a few years earlier
[10:42:12] <KotH> twnqx: ok, then think about what would happen if you'd write indexOut <= T + Y;
[10:42:49] <twnqx> well, i know that in verilog you'd end up qith 1+1=0 :D
[10:43:28] <KotH> .o0(another reason why i hate verilog: it doesnt tell me when i'm doing something wrong)
[10:43:39] <twnqx> it's just like C
[10:43:45] <KotH> it's worse than c
[10:43:47] <twnqx> it does what you tell it, and leasves the thinking to you :P
[10:43:53] <KotH> c is 99% consistent
[10:43:55] <KotH> verilog isnt
[10:43:58] <peloverde> 2'b1 + 2'b1
[10:44:31] <KotH> actually, verilog is what you get if you beat c until you can model hardware with it
[10:44:32] <twnqx> rather {1'b0, T} + {1'b0, Y}
[10:44:34] <twnqx> :)
[10:45:12] <twnqx> KotH: well... yeah
[10:45:17] <KotH> vhdl is what you get if you take people who know ada (a lot of goverment people were involved back then) and let them design a new language from scratch
[10:45:43] <twnqx> which just happens to suck if you like C's syntax :)
[10:46:05] <KotH> twnqx: stop using the same hammer... try another one
[10:46:22] <KotH> as i said, forget everything you know about c based languages
[10:46:34] <KotH> it'll get just in your way anways (even if you do verilog)
[10:47:29] <pentanol> it's a bug or I'm silly? http://codepad.org/wpBPNdZk
[10:47:49] <KotH> pentanol: if in doubt, you're silly
[10:47:50] <KotH> ;)
[10:48:32] <pentanol> heh, but it works on i386
[10:48:45] <pentanol> and won't  on arm
[11:05:10] <twnqx> ah well. so far is is supposed to work, just have to turn the separate input and output busses into a bidirectional tristate bux using xilinx buffers. i waonder if i can wrap that with verilog :]
[12:00:30] <KotH> pentanol: could be that 1) av_next_option returns an invalid value (possibly due to memory corruption), 2) *opt is not correctly alligned 3) your compiler is broken
[12:10:03] <mru> pentanol: where does it fail?
[12:12:25] <pentanol> mru there newest http://codepad.org/nUH1CWWe
[12:21:02] <CIA-1> ffmpeg: michael * r22796 /trunk/libavformat/avformat.h:
[12:21:02] <CIA-1> ffmpeg: Allow AVFormatContext.duration to be set if no individual stream duration is known.
[12:21:02] <CIA-1> ffmpeg: Demuxers already do this ...
[13:26:31] <pentanol> mru no ideas? both arm and i386 in same little-endian
[13:51:23] <CIA-1> ffmpeg: stefano * r22797 /trunk/ffmpeg.c: Rename av_encode() to av_transcode(), the new name is more meaningful.
[13:51:24] <CIA-1> ffmpeg: stefano * r22798 /trunk/ffmpeg.c: Reindent.
[14:22:25] <CIA-1> ffmpeg: stefano * r22799 /trunk/libavformat/file.c:
[14:22:25] <CIA-1> ffmpeg: Implement support to the AVSEEK_SIZE operation in file_seek().
[14:22:25] <CIA-1> ffmpeg: Avoid the need to use seeking for getting the file size, use fstat
[14:22:25] <CIA-1> ffmpeg: instead, which is significantly faster.
[14:22:25] <CIA-1> ffmpeg: See thread:
[14:22:25] <CIA-1> ffmpeg: Subject: [FFmpeg-devel] [PATCH] Add support to AVSEEK_SIZE to the file protocol seek callback
[14:22:26] <CIA-1> ffmpeg: Date: Fri, 2 Apr 2010 13:13:27 +0200
[14:24:38] <mru> pentanol: compiler? flags?
[15:36:48] <CIA-1> ffmpeg: diego * r22800 /trunk/doc/general.texi:
[15:36:48] <CIA-1> ffmpeg: Document minimum binutils requirements on Unix-like platforms.
[15:36:48] <CIA-1> ffmpeg: based on a patch by Michael Kostylev, michael.kostylev gmail com
[20:57:36] <pentanol> mru here  http://codepad.org/0XtJGThF  also I tries different optimisations, anyway got a segfaul, but for -O2 earliest then -O3
[20:58:21] <twnqx> did you ever run it in a debugger?
[21:02:09] <mru> pentanol: what gcc is the arm one?
[21:02:33] <mru> please post output of armv5l-gcc -v
[21:02:48] <pentanol> gcc version 4.1.2for arm
[21:03:12] <pentanol> on my camera I've had strace
[21:03:47] <mru> and the -v output?
[21:06:33] <pentanol> http://codepad.org/qPw6vs7v -v out
[21:09:36] <mru> pentanol: add -v to the command line compiling the .c file and post the output
[21:11:32] <pentanol> ok http://codepad.org/y4ZM1Tag
[21:15:12] <pentanol> twnqx trace  on camera...  but there nothing unusual http://codepad.org/IrvGZMsy
[21:16:13] <pentanol> afk, will be here
[21:21:04] <mru> pentanol: can you post a disassembly of the function where it crashes?
[21:21:29] <mru> do you get a core dump?
[21:21:43] <mru> if so, gdb info registers will be useful
[21:59:58] <CIA-1> ffmpeg: mstorsjo * r22801 /trunk/libavformat/rtsp.c:
[21:59:58] <CIA-1> ffmpeg: Zero-initialize the reply struct
[21:59:58] <CIA-1> ffmpeg: The status_code field is read in the fail codepath, where it could be
[21:59:58] <CIA-1> ffmpeg: read uninitialized earlier. Found by clang.
[22:20:32] <CIA-1> ffmpeg: michael * r22802 /trunk/libavformat/utils.c:
[22:20:32] <CIA-1> ffmpeg: Fix rounding direction for calculation of AVPacket.duration.
[22:20:32] <CIA-1> ffmpeg: Fixes issue1579