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

Wed Aug 1 02:05:02 CEST 2012

[00:32] <j-b> Daemon404: pong
[00:33] <Daemon404> j-b, is there an eta befor i find out if im elligable for vd funding? (sorry to ask, tickets get far mroe expensive as it gets closer)
[00:37] <j-b> Daemon404: I thought it was quite clear
[00:37] <Daemon404> ?
[00:37] <Daemon404> 'it'?
[00:37] <kierank> oh fuck i need to reply to that
[02:05] <Compn> videolan funding devs to RE some codecs? :P
[03:16] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * r3b5ba60aa7 10ffmpeg/libavcodec/ (vc1.c vc1.h): 
[03:16] <CIA-41> ffmpeg: vc1dec: fix handling of max_coded dimensions
[03:16] <CIA-41> ffmpeg: Fixes Ticket1502
[03:16] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[03:16] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * r30c8573dc7 10ffmpeg/libavcodec/mpeg4videoenc.c: 
[03:16] <CIA-41> ffmpeg: mpeg4videoenc: ensure SAR is within the supported range
[03:16] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[04:25] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * r00ddf62078 10ffmpeg/libavformat/mpeg.c: 
[04:25] <CIA-41> ffmpeg: mpegdemux: Fix probing of unrecognized_mpeg_video.mpg
[04:25] <CIA-41> ffmpeg: Fixes Ticket1586
[04:25] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[11:05] <slackyman> Hi
[11:05] <slackyman> I'm cross-compiling ffmpeg win w64-mingw32 on slackware 13.37
[11:05] <ubitux> http://szeged.github.com/nevada/ fun.
[11:05] <slackyman> all went well until I add some c++ libs
[11:06] <slackyman> c++ libs DO NOT link statically and require libstdc++-6.dll
[11:06] <slackyman> I don't want any shared lib
[11:07] <ubitux> --extra-libs=-lstdc++ ?
[11:07] <slackyman> Now I'm trying adding "-static -Wl,-Bstatic,-lstdc++" to LDFLAGS
[11:08] <slackyman> if I use --estra-libs=lstdc++ it keep linking shared libs
[11:08] <slackyman> ok, that's another point
[11:09] <slackyman> even if I copy the libstdc++-6.dll file it links dinamically to another one that is MISSING
[11:09] <slackyman> Now I'm trying adding "-static -Wl,-Bstatic,-lstdc++" to LDFLAGS". It's the correct way?
[11:10] <slackyman> Or is it only a workaround?
[11:11] <slackyman> I think ffmpeg has to try linking statically ever
[11:11] <slackyman> it works good for c libs
[11:11] <slackyman> buut not for c++ libs
[11:12] <slackyman> Or what if I simply add --extra-libs='-static -lstdc++'
[11:12] <slackyman> ?
[11:13] <slackyman> something's wrong in the tollchain, maybe, not in ffmpeg
[11:13] <slackyman> *toolchain
[11:20] <slackyman> anyone?
[11:23] <ubitux> afaict the build system is not perfect when dealing with static link & external libraries
[11:26] <slackyman> my only problems are with c++ libs. Maybe I have to try avoiding their use
[11:31] <slackyman> I can confirm that adding "-static -Wl,-Bstatic,-lstdc++" to LDFLAGS solve the issue
[12:19] <slackyman> bye
[13:32] <CIA-41> ffmpeg: 03Stefano Sabatini 07master * rb4c3359828 10ffmpeg/libavfilter/f_settb.c: 
[13:32] <CIA-41> ffmpeg: lavfi/asettb: do not create a new reference in filter_samples()
[13:32] <CIA-41> ffmpeg: There is no need to duplicate the input reference, since a filter should
[13:32] <CIA-41> ffmpeg: not pass along a reference which is later modified. If this happens the
[13:32] <CIA-41> ffmpeg: filter passing the reference should be fixed.
[13:32] <CIA-41> ffmpeg: Also improve consistency with start_frame() of settb, allowing a pending
[13:32] <CIA-41> ffmpeg: factorization.
[13:33] <CIA-41> ffmpeg: 03Stefano Sabatini 07master * ra7c3720e87 10ffmpeg/libavutil/bprint.h: 
[13:33] <CIA-41> ffmpeg: lavu/bprint: readd documentation for 0 and 1 av_bprint_init() special values
[13:33] <CIA-41> ffmpeg: The documentation was erroneously removed in 7cf9aadd.
[13:33] <CIA-41> ffmpeg: 03Stefano Sabatini 07master * r23fc4dd6e7 10ffmpeg/ (4 files in 2 dirs): 
[13:33] <CIA-41> ffmpeg: lavc: add channels field to AVFrame
[13:33] <CIA-41> ffmpeg: This is required otherwise it is not always possible to guess the number
[13:33] <CIA-41> ffmpeg: of channels from the layout, for example if the channel layout is
[13:33] <CIA-41> ffmpeg: unknown.
[13:33] <CIA-41> ffmpeg: 03Stefano Sabatini 07master * rc809b89a12 10ffmpeg/ (doc/ffprobe.xsd ffprobe.c): ffprobe: show audio frame channels and channel_layout
[13:33] <CIA-41> ffmpeg: 03Stefano Sabatini 07master * r52bd9cb4d2 10ffmpeg/libavfilter/src_movie.c: 
[13:49] <saste> ubitux: amovie problem should be fixed now
[14:01] <ubitux> saste: thx :)
[14:41] <ubitux> i'm working on issue 1576, but there is something strange
[14:41] <ubitux> the input video stream has time base 2997/1 and codec time base 30/1
[14:42] <ubitux> in the muxer, the codec time base is re-use, so it should be 30/1
[14:42] <ubitux> but it's actually 2997/1, which is "invalid" somehow
[14:42] <ubitux> any idea what could cause this?
[15:13] <ubitux> in the header callbackm, in mxf muxer, i have tb=1/90000 & tbc=1001/90000 which makes sense, but in mov muxer i have tb=1/90000 & tbc=1/2997
[15:13] <ubitux> both with codec copy
[15:21] <ubitux> ok it seems related to the timebase heuristics in transcode_init
[15:28] <saste> michaelni: can you comment on "[PATCH] lavfi: add duration field to AVFilterBufferRef"?
[15:34] <durandal_1707> can demuxer open various protocols?
[16:21] <CIA-41> ffmpeg: 03Nicolas George 07master * r89898cd3b6 10ffmpeg/ (doc/ffprobe.xsd ffprobe.c): 
[16:21] <CIA-41> ffmpeg: ffprobe: fix validity error with tags and data.
[16:21] <CIA-41> ffmpeg: Add "data" and "extradata" attributes to the schema.
[16:21] <CIA-41> ffmpeg: Add "tag" element in "streams".
[16:21] <CIA-41> ffmpeg: Print extradata before tags to avoid closing the element.
[16:21] <CIA-41> ffmpeg: Fix trac ticket #1588.
[17:35] <CIA-41> ffmpeg: 03Nicolas George 07master * r9009fa6de4 10ffmpeg/libavcodec/movtextdec.c: movtextdec: fix return value for too small packets.
[17:36] <CIA-41> ffmpeg: 03Nicolas George 07master * r3d5dc7d87d 10ffmpeg/libavcodec/mmvideo.c: 
[17:36] <CIA-41> ffmpeg: mmvideo: count preamble size in return value.
[17:36] <CIA-41> ffmpeg: MM_PREAMBLE_SIZE is subtracted from buf_size almost immediately.
[17:36] <CIA-41> ffmpeg: The original size is still in avpkt->size.
[17:36] <CIA-41> ffmpeg: 03Nicolas George 07master * rcc7eff1fa0 10ffmpeg/libavcodec/vc1dec.c: vc1dec: count ENDOFSEQ code in return value.
[17:36] <CIA-41> ffmpeg: 03Nicolas George 07master * r1c98781837 10ffmpeg/libavcodec/8svx.c: 
[17:36] <CIA-41> ffmpeg: 8svx: use a more direct condition.
[17:36] <CIA-41> ffmpeg: esc->table was inited based on codec->id: re-testing codec->id
[17:36] <CIA-41> ffmpeg: is code duplication and can lead to inconsistencies.
[17:36] <CIA-41> ffmpeg: 03Nicolas George 07master * r5caea648d4 10ffmpeg/libavcodec/8svx.c: 
[17:36] <CIA-41> ffmpeg: 8svx: remove useless rounding code.
[17:36] <CIA-41> ffmpeg: samples_size and samples_idx are supposed to be multiple of
[17:36] <CIA-41> ffmpeg: channels at all time. If they are, the division is exact;
[17:36] <CIA-41> ffmpeg: if they are not, something is very wrong in the code.
[17:36] <CIA-41> ffmpeg: 03Nicolas George 07master * r7a539e67f4 10ffmpeg/libavcodec/8svx.c: 8svx: unify mono and stereo code paths.
[17:36] <CIA-41> ffmpeg: 03Nicolas George 07master * r91ec1c6cc3 10ffmpeg/libavcodec/loco.c: 
[17:36] <CIA-41> ffmpeg: loco: take decode overflow into account.
[17:36] <CIA-41> ffmpeg: Commit 2bf0982 introduced an overflow check in loco_decode_plane,
[17:36] <CIA-41> ffmpeg: but the error code is never taken into account, leading to
[17:36] <CIA-41> ffmpeg: completely idiotic return values.
[17:36] <CIA-41> ffmpeg: 03Nicolas George 07master * rd2ca5dd0f3 10ffmpeg/libavcodec/loco.c: 
[17:36] <CIA-41> ffmpeg: loco: fix return value.
[17:36] <CIA-41> ffmpeg: The return value was the number of bytes left,
[17:36] <CIA-41> ffmpeg: it is supposed to be the number of bytes used.
[17:36] <CIA-41> ffmpeg: 03Nicolas George 07master * rb2814b034e 10ffmpeg/libavcodec/sp5xdec.c: 
[17:36] <CIA-41> ffmpeg: sp5xdec: sanitize return value.
[17:36] <CIA-41> ffmpeg: i is the decoded size of a recoded packet, which is larger
[17:37] <CIA-41> ffmpeg: than the original packet. Assume that if decoding succeeded,
[17:37] <CIA-41> ffmpeg: all the packet was used.
[17:38] <ubitux> is it me or first_pts is unused in ffmpeg?
[19:01] <ubitux> ok that's because we don't use vf fps
[19:21] <ubitux> ost->sync_opts = frame->pts + frame->nb_samples;
[19:22] <ubitux> i don't understand this
[19:22] <ubitux> how can that work?
[19:23] <ubitux> i mean the time base of pts could be anything
[19:24] <ubitux> shouldn't we have nb_samples rescale to the frame pts?
[19:24] <ubitux> (it's some audio stuff in ffmpeg.c)
[19:26] <ubitux> well anyway, check_recording_time() is made prior to this..
[21:25] <sandyiscool> hello all
[21:30] <sandyiscool> i am new to this channel. i want to develop and contribute code to ffmpeg. but i am a total newbie to ffmpeg and multimedia codecs. i downloaded ffmpeg source and built it on my fedora distro. the build process was successful, albeit with some errors
[21:31] <sandyiscool> now i want to start with studying the source code of ffmpeg and make myself comfortable in browsing and understanding the code
[21:31] <sandyiscool> but as i said, i am a total newbie to video/audio encoding/decoding and muxing/demuxing
[21:32] <sandyiscool> can anyone help with any tutorials that explain the basics of multimedia codecs, coding/decoding, muxing/demuxing of audio/video ?
[21:34] <sandyiscool> sorry for the mistake. i meant to say that i successfully built ffmpeg from source , with few build warnings
[21:38] <sandyiscool> hello Anssi
[21:42] <michaelni> hi sandyiscool
[21:42] <michaelni> what do you want to work on ?
[21:43] <ubitux> sandyiscool: i'd recommend http://xiph.org/video/vid1.shtml and http://lurkertech.com/lg/video-systems/
[21:44] <ubitux> (for general stuff)
[21:44] <sandyiscool> thank you ubitux. i am having a look at the links now
[21:45] <ubitux> as michaelni asked, it also really depends on what you are willing to do
[21:45] <sandyiscool> hi michaelni
[21:45] <sandyiscool> well, right now, I am trying to understand how ffmpeg works as a whole
[21:45] <sandyiscool> i am trying to understand the big picture
[21:46] <sandyiscool> right now i do not have any specific idea about what i should work on
[21:47] <ubitux> mmh big picture...
[21:47] <ubitux> you should first look at https://ffmpeg.org/about.html
[21:47] <ubitux> it gives a quick summary of each tool & library
[21:48] <sandyiscool> okay
[21:52] <sandyiscool> okay... so i read the 'about' page on the ffmpeg website
[21:54] <sandyiscool> after reading, i have shortlisted three libraries in order of my interest to work on each :  libavformat > libavcodec > libavdevice
[21:56] <sandyiscool> the rationale is : i have always been fascinated how two different streams i.e. audio and video are interleaved in one stream and how they are separated by a player and played. secondly, i have always wanted to know what happens in the background by multimedia codecs.
[21:56] <sandyiscool> thirdly, i want to know how video streams are rendered on screen and how audio stream is sent to the audio out
[22:04] <sandyiscool> thanks ubitux for the two links for more info on video systems. i have to sign out now as its pretty late here.
[22:06] <sandyiscool> will be nack later with my questions :)
[22:06] <sandyiscool> *back
[22:06] <sandyiscool> goodnight
[22:22] <ubitux> philipl: you never submitted the 3 commits you showed right?
[22:22] <ubitux> (the srtdec/txtdec patches)
[22:23] <philipl> ubitux: I did not. No one ever commented on them originally and I focused on the movtext stuff.
[22:23] <philipl> But they are in my overall pile of things that need to happen before mkv -> mp4 can work correctly
[23:05] <CIA-41> ffmpeg: 03Ronald S. Bultje 07master * rb829b4ce29 10ffmpeg/libavcodec/x86/ (h264_deblock.asm h264dsp_mmx.c): 
[23:05] <CIA-41> ffmpeg: h264: convert loop filter strength dsp function to yasm.
[23:05] <CIA-41> ffmpeg: This completes the conversion of h264dsp to yasm; note that h264 also
[23:05] <CIA-41> ffmpeg: uses some dsputil functions, most notably qpel. Performance-wise, the
[23:05] <CIA-41> ffmpeg: yasm-version is ~10 cycles faster (182->172) on x86-64, and ~8 cycles
[23:05] <CIA-41> ffmpeg: faster (201->193) on x86-32.
[23:05] <CIA-41> ffmpeg: 03Diego Biurrun 07master * r8728b381cb 10ffmpeg/libavcodec/x86/h264dsp_mmx.c: 
[23:05] <CIA-41> ffmpeg: x86: h264dsp: Adjust YASM #ifdefs
[23:05] <CIA-41> ffmpeg: This fixes compilation with YASM disabled.
[23:05] <CIA-41> ffmpeg: 03Samuel Pitoiset 07master * r9c9c21eaa1 10ffmpeg/libavformat/rtmpproto.c: 
[23:05] <CIA-41> ffmpeg: rtmp: do not warn about receiving metadata packets
[23:05] <CIA-41> ffmpeg: They are managed in get_packet()
[23:05] <CIA-41> ffmpeg: Signed-off-by: Luca Barbato <lu_zero at gentoo.org>
[23:05] <CIA-41> ffmpeg: 03Diego Biurrun 07master * rd1505db067 10ffmpeg/libavfilter/x86/yadif.c: 
[23:05] <CIA-41> ffmpeg: 03Anton Khirnov 07master * rf2ed006c90 10ffmpeg/libavformat/mpc8.c: mpc8: return more meaningful error codes.
[23:16] <slackyman> Hi
[23:17] <philipl> ubitux: any further comments on the movtext encoder? I'd like to push it this week and then move on to sorting out the textdec and convergence_duration stuff.
[23:18] <slackyman> I'm cross-compiling one of the latest ffmpeg-git and I found some solution to most of the issue you can find on the Internet
[23:19] <slackyman> E.g.: for the libcdio - compiling it gives a "unknown type name 'ULONG'"
[23:19] <ubitux> philipl: well if the timing are correct on playback, and if it passes fate i guess i don't have any comment
[23:19] <slackyman> I've sent an email to Zeranoe
[23:20] <slackyman> and, lately, I found that ffmpeg source DOES NOT link statically to c++ libs
[23:20] <slackyman> co you have to add "-static -Wl,-Bstatic,-lstdc++" to LDFLAGS
[23:20] <slackyman> I hope that someone take notes about these
[23:23] <michaelni> slackyman, is this a regression ?
[23:23] <michaelni> that is did this work before ?
[23:25] <slackyman> I've made different version of "ffmpeg.exe" but never used c++ libs
[23:25] <slackyman> this time i used libcdio and ut video
[23:26] <slackyman> and they link ffmpeg to the shared libstdc++
[23:26] <slackyman> there's a little bug in my toolchain
[23:26] <slackyman> I'm using mingw-64
[23:27] <slackyman> and the libstdc++-6.dll link to a missing lib
[23:27] <philipl> ubitux: ok. thanks.
[23:27] <slackyman> so no matter if I copy the file in the executable folder
[23:28] <slackyman> it breaks the execution of the binary (not the compiling or the linking)
[23:28] <nevcairiel> the library has to exist somewhere or linking wouldnt work
[23:31] <slackyman> I try to explain better the case
[23:31] <slackyman> libstdc++-6.dll links to LIBGCC_S_SJLJ-1.DLL
[23:32] <Daemon404> thats nothing to do with ffmpeg
[23:32] <Daemon404> whoever compiled your toolchain did it poorly.
[23:32] <slackyman> yes, just I said before: this is a bug in the toolchain
[23:32] <Daemon404> its not a bug either
[23:32] <Daemon404> its an option
[23:32] <slackyman> but the ffmpeg compilation problem is beside the static linking
[23:33] <slackyman> as far as I know ffmpeg try to link libs statically if there's a static version
[23:34] <Daemon404> it just tries -lstdc++ and uses whatever is there
[23:34] <slackyman> but if I DO NOT specify CFLAGS+="-static -Wl,-Bstatic,-lstdc++" it DOES NOT
[23:34] <slackyman> I have BOTH static and shared lstdc++
[23:35] <Daemon404> thats default gcc behavior. perhaps we shoul have a flag
[23:35] <slackyman> I did't mean to criticize anyone
[23:35] <Daemon404> there's actually a far mode hideous bug related c++ linking too
[23:35] <Daemon404> if you generate shared libav*
[23:35] <Daemon404> the generated export libs get screwed
[23:36] <slackyman> I'm only saying that whilst ffmpeg link statically to C libraries it doesn't do the same for c++ ones
[23:36] <slackyman> but you have to SAY to it that you want link statically
[23:36] <Daemon404> ffmpeg does nto link statically to libc anywhere.
[23:36] <Daemon404> unless you force it to
[23:37] <slackyman> I compiled every external lib statically
[23:37] <slackyman> then configure ffmpeg
[23:37] <Daemon404> libc does not get linked statically.
[23:37] <Daemon404> it links to msvcrt.dll
[23:37] <Daemon404> on windows
[23:37] <slackyman> and... enough! It links statically!
[23:37] <Compn> whoa
[23:37] <Compn> slackyman : how big is your binary? :)
[23:37] <slackyman> I stripped it
[23:38] <slackyman> but it's big
[23:38] <Daemon404> slackyman, it does NOT link the ms c runtiem statically. just fyi
[23:38] <Compn> does libcdio even work on windows ?
[23:38] <Daemon404> the difference is the teh gnu toolchain has its own c++ runtime
[23:38] <slackyman> no, I know, Daemon404, we are saying two different things
[23:38] <slackyman> yes, it works
[23:38] <slackyman> Compn
[23:38] <Compn> i guess it does, ignore methen :)
[23:38] <Daemon404> [17:36] < slackyman> I'm only saying that whilst ffmpeg link statically to C libraries it doesn't do the same for c++ ones
[23:39] <Daemon404> ^ it does link statically to teh libraries
[23:39] <Compn> slackyman : did you see zeranoe's builds ? those are static
[23:39] <Daemon404> it links dynamically to teh c++ runtime
[23:39] <Daemon404> teh libraries themselves are statically linked.
[23:39] <Compn> Daemon404 : what are you arguing anyhow
[23:39] <slackyman> ok, Daemon404, now I know, but before this talk I ignore it
[23:40] <slackyman> to have a big-static-monolithic executable I have to link statically to every lib
[23:40] <Daemon404> and ffmpeg's behavior is to respect the system gcc's preference for linking libstdc++ static or dynamic
[23:40] <slackyman> so i add "-static -Wl,-Bstatic,-lstdc++" and that's all
[23:40] <Daemon404> whic his a toolchain option
[23:40] <Daemon404> and unrelated.
[23:40] <slackyman> ok
[23:41] <slackyman> I'm not into C++
[23:41] <slackyman> didn't know
[23:41] <Daemon404> grab nevcairiel's toolchain if you want a working mingw toolchain
[23:41] <Daemon404> that is static
[23:41] <Daemon404> or well, nevcairiel's repackaging of my toolchain.
[23:41] <slackyman> I used Zeranoe build script to compile my mingw-w64
[23:41] <JEEB> not any more
[23:42] <slackyman> and it works great on my slackware 13.37
[23:42] <Daemon404> slackyman, zeranoe has an option to create a fully-static toolchain
[23:42] <Daemon404> during setup
[23:42] <slackyman> yes, but it fails to compile 
[23:42] <Daemon404> works here
[23:42] <slackyman> so i left everything unchanged
[23:43] <slackyman> I have a Slackware 13.37 
[23:43] <Daemon404> yes i use debian.
[23:43] <slackyman> Daemon404, which version of gcc runs on debian?
[23:43] <slackyman> I have a 4.5.2
[23:43] <Daemon404> system gcc, or my cross-toolchain?
[23:44] <slackyman> system
[23:44] <Daemon404> debian unstable is on 4.7 and 4.6.3, and ubuntu si on 4.6.3
[23:44] <slackyman> since the toolchain compiles under the system one
[23:44] <Daemon404> i havent tried on debian stable
[23:44] <Daemon404> which is 4.4.5
[23:44] <Daemon404> or so
[23:44] <Daemon404> 4.4.x, anyway.
[23:44] <slackyman> slackware use the old 4.5.2 since they test everything sooooo long before to distribute
[23:45] <Daemon404> debain stable is older.
[23:45] <slackyman> Daemon404, have you tried to cross-compile ut-video?
[23:46] <slackyman> or libcdio?
[23:46] <slackyman> and include them in ffmeg?
[23:46] <Daemon404> considering i wrote libutvideo's makefiles, and ffmpeg's libutvideo*.cpp
[23:46] <Daemon404> yes
[23:46] <Daemon404> yes i have.
[23:46] <slackyman> ok :)
[23:46] <slackyman> sorry, I'm  new here 
[23:47] <Daemon404> i actually fixed asm support for utvideo with makefiles
[23:47] <Daemon404> so you can cross-compile with utvideo's asm
[23:47] <Daemon404> patch is it my git repo
[23:47] <slackyman> thanks
[23:47] <Daemon404> have you had trouble?
[23:47] <slackyman> yes, I modified the GNUMakefile
[23:48] <Daemon404> which part
[23:48] <slackyman> I had to remove GlobalConf from linking
[23:49] <Daemon404> ah
[23:49] <slackyman> and make some changes to 2 header files
[23:49] <Daemon404> i didnt add that.
[23:49] <Daemon404> sec
[23:49] <Daemon404> let me link you to the patch of mine
[23:49] <Daemon404> it fixes mingw builds too
[23:49] <Daemon404> there was a missing heaer include
[23:49] <Daemon404> and stuff
[23:49] <Daemon404> https://github.com/dwbuiten/utvideo/commit/42351ecb5f81dede1f13ffa695ba506046ce93ab
[23:49] <Daemon404> x86 asm works on all platforms
[23:49] <slackyman> I used the utvideo 11.1.1
[23:50] <Daemon404> x64 asm only works on windows
[23:50] <Daemon404> that patch is to 11.1.1
[23:50] <Daemon404> it will apply cleanly
[23:51] <slackyman> yes, but I have to untar again since I modified a lot
[23:51] <Daemon404> mv dir dir.old && unzip utv.zip
[23:52] <Daemon404> or just git clone my repo
[23:52] <Daemon404> since it is up to date
[23:52] <slackyman> git clone https://github.com/dwbuiten/utvideo.git
[23:52] <slackyman> I'm waiting... :D
[23:52] <Daemon404> ;p
[23:53] <slackyman> I often modify Makefiles instead to launch make SOMESTUFF=otherstuff
[23:53] <slackyman> I make a copy of the orig
[23:53] <Daemon404> lazymodo
[23:53] <slackyman> then rename the new to Makefile.win
[23:54] <slackyman> and launch make -f Makefile.win
[23:54] <slackyman> so I can still copmile for linux
[23:54] <slackyman> with very little changes
[23:54] <slackyman> ok
[23:54] <slackyman> let me see how it works
[23:57] <slackyman> I checked the GNUMakefile
[23:58] <slackyman> it seems that libutvideo it's not shared
[23:58] <slackyman> ok, I think this is made well
[23:59] <slackyman> now I remove the old lib, install the new one and try to recompile ffmpeg
[23:59] <Daemon404> libutvideo is gener shared
[23:59] <Daemon404> never*
[23:59] <Daemon404> i couldnt be arsed to add support
[00:00] --- Wed Aug  1 2012