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

[burek]

[00:00] <ubitux> anyway, doesn't matter
[00:00] <Compn> fedora has some crazy security things
[00:00] <Compn> used to affect mplayer even
[00:00] <Compn> or was that redhat
[00:00] <Compn> hmm
[00:01] <gnafu> I haven't had any issues with SELinux for the last few releases at least.  The default policy has gotten a ton better, and the tools are very well documented for when you need to change things.
[00:35] <CIA-46> ffmpeg: 03Lou Logan 07master * ra2c419848d 10ffmpeg/doc/filters.texi: 
[00:35] <CIA-46> ffmpeg: docs: remove extra sar entry for scale filter
[00:35] <CIA-46> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[01:41] <CIA-46> ffmpeg: 03Alex Converse 07master * rb5fc571e4f 10ffmpeg/libavcodec/aacdec.c: 
[01:41] <CIA-46> ffmpeg: latmdec: Check AudioSpecificConfig length before decoding extradata.
[01:41] <CIA-46> ffmpeg: This is different than a normal get_bits() over read because
[01:41] <CIA-46> ffmpeg: decode_audio_specific_config() creates its own GetBitContext.
[01:41] <CIA-46> ffmpeg: Fixes Bug 170.
[01:41] <CIA-46> ffmpeg: 03Christophe GISQUET 07master * r3faa303a47 10ffmpeg/libavcodec/ (7 files in 2 dirs): (log message trimmed)
[01:41] <CIA-46> ffmpeg: rv34: DC-only inverse transform
[01:41] <CIA-46> ffmpeg: When decoding coefficients, detect whether the block is DC-only, and take
[01:41] <CIA-46> ffmpeg: advantage of this knowledge to perform DC-only inverse transform.
[01:41] <CIA-46> ffmpeg: This is achieved by:
[01:41] <CIA-46> ffmpeg: - first, changing the 108x4 element modulo_three_table into a 108 element
[01:41] <CIA-46> ffmpeg:  table (kind of base4), and accessing each value using mask and shifts.
[01:41] <CIA-46> ffmpeg: 03Kostya Shishkov 07master * r08bab32cf1 10ffmpeg/libavcodec/ (indeo4.c indeo4data.h): 
[01:41] <CIA-46> ffmpeg: indeo4: add some missing static and const qualifiers
[01:41] <CIA-46> ffmpeg: From the patch by Reimar Döffinger.
[01:41] <CIA-46> ffmpeg: 03Paul B Mahol 07master * rf7f3563214 10ffmpeg/libswscale/ (rgb2rgb.c rgb2rgb.h swscale_unscaled.c): 
[01:41] <CIA-46> ffmpeg: rgb2rgb: rgb12tobgr12()
[01:41] <CIA-46> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[01:41] <CIA-46> ffmpeg: 03Anton Khirnov 07master * rb2ce3b998b 10ffmpeg/avconv.c: avconv: use AVFrame.width/height/format instead of corresponding AVCodecContext fields
[01:41] <CIA-46> ffmpeg: 03Anton Khirnov 07master * r0fd88d3988 10ffmpeg/libavformat/riff.c: 
[01:41] <CIA-46> ffmpeg: riff: remove references to sonic codec ids
[01:41] <CIA-46> ffmpeg: They are deprecated and will be purged on next major bump.
[01:41] <CIA-46> ffmpeg: 03Anton Khirnov 07master * rf3d02a8b28 10ffmpeg/libavcodec/ (v410dec.c v410enc.c vble.c): lavc: replace some remaining FF_I_TYPE with AV_PICTURE_TYPE_I
[01:41] <CIA-46> ffmpeg: 03Anton Khirnov 07master * ra29c25a9b2 10ffmpeg/libavcodec/options.c: lavc: ifdef out parse_only AVOption
[01:41] <CIA-46> ffmpeg: 03Janne Grunau 07master * r3547f8e8f8 10ffmpeg/libavcodec/rv34.c: 
[01:41] <CIA-46> ffmpeg: rv34: fix and optimise frame dependency checking
[01:41] <CIA-46> ffmpeg: The sporadic threading errors during fate-rv30 were caused by calling
[01:41] <CIA-46> ffmpeg: ff_thread_await_progress with mb row -1 as argument. That returns
[01:41] <CIA-46> ffmpeg: immediately since progress is initialized to -1. Not yet computed
[01:41] <CIA-46> ffmpeg: motion vectors from the reference could be used for the first
[01:42] <CIA-46> ffmpeg: ARM: rv34: fix asm syntax in dc transform functions
[01:42] <CIA-46> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[01:42] <CIA-46> ffmpeg: Signed-off-by: Janne Grunau <janne-libav at jannau.net>
[01:42] <CIA-46> ffmpeg: 03Michael Niedermayer 07master * rb18e17eabf 10ffmpeg/: (log message trimmed)
[01:42] <CIA-46> ffmpeg: Merge remote-tracking branch 'qatar/master'
[01:42] <CIA-46> ffmpeg: * qatar/master: (21 commits)
[01:42] <CIA-46> ffmpeg:  utils: Check for extradata size overflows.
[01:42] <CIA-46> ffmpeg:  ARM: rv34: fix asm syntax in dc transform functions
[01:42] <CIA-46> ffmpeg:  avio: Fix the value of the deprecated URL_FLAG_NONBLOCK
[01:42] <CIA-46> ffmpeg:  rv34: fix and optimise frame dependency checking
[01:42] <CIA-46> ffmpeg: 03Anton Khirnov 07master * r3167dc9515 10ffmpeg/ (4 files in 2 dirs): lavfi: move version macros to a new installed header version.h
[01:43] <CIA-46> ffmpeg: 03Anton Khirnov 07master * r136ee32da3 10ffmpeg/avprobe.c: avprobe: use avio_size() instead of deprecated AVFormatContext.file_size.
[01:43] <CIA-46> (18 lines omitted)
[02:31] <ubitux> michaelni: ffmpeg has libpostproc 51.2.100 while libav has a +1 on major; this seems problematic for compatibility
[02:37] <durandal11707> yep, mplayer2 is checking for this
[02:38] <durandal11707> (i fixed that in my mplayer2 fork)
[02:39] <michaelni> well, iam not against installing postproc under both sonames, its the 100% same ABI anyway
[02:40] <michaelni> that is if that fixes it ...
[03:06] <ubitux> michaelni: i think "amongth" is not a correct english word
[03:07] <ubitux> maybe you wanted to use "among" (or eventually "amongst" which seem less common)
[03:13] <michaelni> ubitux, locally fixed, thx
[03:43] <durandal11707> hmm rsync server is sending crap to me
[03:46] <ubitux> seriously& wtf: http://stackoverflow.com/questions/5637178/clang-2-9-crt1-not-found-error
[03:46] <ubitux> it's been 1 hour i'm trying to understand why clang isn't able to build a single binary
[03:46] <ubitux> i needed to add the gcc version in that list&
[04:28] <ubitux> michaelni: i think i won't use ioc soon
[04:28] <ubitux> it just ate my 6GB of ram in a few seconds running one of the fate test
[04:28] <ubitux> so i don't think it's wise to use it on my box :p
[04:30] <ubitux> i may be doing something wrong or hiting an incompatibility somewhere
[04:30] <ubitux> but well, i don't have much time for this, i already gave it too much time
[04:49] <durandal11707> libcdio input format is missing long name
[15:21] <cbsrobot> ubitux ping
[16:05] <ubitux> cbsrobot: pong
[16:05] <cbsrobot> ubitux: just a (maybe stupid) question
[16:05] <cbsrobot> how should I pass the timecodecontext from the decode to the encoder ?
[16:07] <ubitux> i don't know at all :)
[16:07] <cbsrobot> and should we add a dummy codec for timecode streams ?
[16:07] <cbsrobot> lol
[16:09] <cbsrobot> and I guesst the timecode api is not stable yet
[16:09] <cbsrobot> ok to change the the arguments for [avpriv,ff]_framenum_to_smtpe_timecode ?
[16:14] <ubitux> do you really need to change that?
[16:14] <ubitux> changing it means deprecating the old one
[16:14] <ubitux> what do you need to change?
[16:22] <cbsrobot> Im ff_timecode I replaced the drop with a flags
[16:23] <cbsrobot> and instead of submitting drop to them I need to submit flags
[16:24] <cbsrobot> but I can also add a workaround
[16:25] <ubitux> ah yes i wanted to do that for the new api
[16:26] <cbsrobot> so what do you think ?
[16:26] <ubitux> well the best things to do is to rewrite the timecode api in lavu properly
[16:27] <ubitux> i will work on this starting monday
[16:27] <cbsrobot> ok
[16:27] <cbsrobot> I'll send a WIP to the ML
[16:27] <ubitux> atm i don't have time for this unfortunately
[16:27] <ubitux> yes good idea
[16:28] <cbsrobot> ok
[16:28] <ubitux> feel free to change the prototype for the WIP
[16:28] <cbsrobot> ok
[16:31] <cbsrobot> btw - mov can add a fontname (size etc.) to the timecode atom
[16:31] <ubitux> yes
[16:31] <cbsrobot> what to do with it ?
[16:31] <cbsrobot> missude metadata ?
[16:31] <cbsrobot> *misuse 
[16:31] <ubitux> i don't really know&
[16:32] <ubitux> in the best world a timecode track just like subtitles should be generated
[16:32] <ubitux> with the style set with ass tags
[16:33] <ubitux> but we are not at that point yet, i'd ignore it&
[16:33] <ubitux> except if you need to keep it in transcode maybe
[16:34] <cbsrobot> well yes
[16:35] <cbsrobot> two more things to consider when doing transcode is the udta tag for the timecode track
[16:35] <cbsrobot> it's used for the name of the track
[16:35] <cbsrobot> I think it's used by editing applications like final cut to be able to match the timecode type
[16:36] <cbsrobot> like auxTC, sourceTC, etc
[16:37] <cbsrobot> and there seems to be the tref tag on the video track referencing to the timecode tracks
[16:38] <cbsrobot> but I'm not sure what happens if they are ignored
[16:39] <ubitux> i really don't know much about the mov
[16:39] <ubitux> i won't be able to help a lot
[16:43] <NapHtaKeRoSene> i have invented area map in 8 hours, good time?
[16:58] <ubitux> can anyone try "make libavutil/eval-test && valgrind ./libavutil/eval-test" and tell me if there are valgrind failures?
[16:58] <ubitux> i don't understand the issue here, and i suspect a valgrind or libc bug
[16:59] <ubitux> though, i'm not able to reproduce it in a simpler .c
[17:28] <ubitux> mmh, might be related to http://sourceware.org/bugzilla/show_bug.cgi?id=12424
[17:39] <j-b> is Carl around?
[17:44] <av500> on irc?
[17:44] <av500> rarely I would say
[17:56] <j-b> crap
[17:57] <ubitux> my logs say he came only once here in 2011
[17:57] <ubitux> for exactly 3 minutes
[17:58] <av500> j-b: you lost email access?
[17:59] <j-b> yes
[18:01] <av500> hadopi?
[18:01] <j-b> yes
[18:02] <av500> j-b: if you are on the run, I have friends in paris that could hide you
[18:02] <j-b> not yet
[18:02] <j-b> source code of BD+ is still hidden
[18:02] <j-b> and the keys are still on http://vlc-bluray.whoknowsmy.name/
[18:04] <funman> what's the plan for revealing BD+ source btw?
[18:12] <j-b> having someone test it
[18:12] <j-b> and fix it
[18:12] <j-b> separate the sensitive data
[18:21] Action: JEEB wonders if any of his discs actually contain BD+
[18:23] <gnafu> Wait, there's progress being made on playing back BD+ discs?  Awesome!
[18:24] <gnafu> The day I can play most or all commercial Blu-ray discs in VLC is the day I buy a BD-ROM drive for my computer and start buying at least a few Blu-rays.
[18:26] <JEEB> I already buy stuff I like, or what I find cheaply. But I don't have a drive .-. I get the data of those blu-ray discs in other ways.
[18:26] <Compn> j-b : i can mail carl if you want ?
[18:27] <j-b> Compn: you're nice
[18:27] <j-b> I will do it
[18:27] Action: Compn asks the dumb questions :)
[18:28] <gnafu> JEEB: Yeah, I'll probably start buying some soon anyway.  There are certain movies I know will really benefit from HD, and then other Blu-rays that are just so darn cheap.
[18:29] <JEEB> yeh
[18:29] <gnafu> I just got a projector, so I'll probably be buying a dedicated player soon anyway.  Right now, I just have an Oppo 971H (which is excellent for upscaling DVDs, but it's not the same).
[18:30] <Compn> encryption schemes only hurt paying customers
[18:30] <JEEB> indeed
[18:30] <Compn> i will not buy into something that affects my use of it :P
[18:31] Action: Compn is blu free!
[18:31] <j-b> http://source.ffmpeg.org/?p=libaacs.git;a=summary
[18:32] <gnafu> Compn: That's largely how I feel, but it's getting hard to resist now that I have a 70" HD display (and a nice 1080p monitor for my computer as well)...
[18:33] <gnafu> But I'm trying to hold out for an open source implementation, allowing me to have my cake (commercial Blu-ray discs) and eat it too (watch it, decode it, and play with it in Linux).
[18:35] <funman> iiuc libbd+ contains mandatory powerdvd9 memdumps, that's all taht is "sensitive"
[18:37] <j-b> dvd8
[18:40] <Compn> well
[18:40] <Compn> j-b : you could always tell those secret blu key guys to submit patches to mplayer
[18:40] <Compn> mplayer isnt afraid of anything :D
[18:41] <j-b> this is not like 10 years ago, you know
[18:41] <Compn> is it worse? 
[18:41] <gnafu> I think mplayer is a pretty cool guy.  Eh fights copy protection and doesnt afraid of anything.
[18:42] <j-b> Compn: yes, way worse
[18:42] <j-b> Compn: to host it correctly, you need now servers outside of USA, EU, Russia and Japan
[18:43] <Compn> ah, software patents
[18:43] <j-b> no
[18:43] <j-b> DRM breakage
[18:43] <Compn> ah
[18:43] <Compn> i thought it was still legal in usa for interoperability
[18:43] <j-b> no
[18:43] <j-b> Compn: shipping 30M/month binaries libdvdcss, I know the mess
[18:43] <Compn> i guess that one key showed that was incorrect :\
[18:43] <Compn> doh
[18:43] <j-b> and Sony will fight
[18:43] <Compn> yeah, you know best :)
[18:43] <j-b> they already told me
[18:48] <Compn> i remember they tried to harass digg about that aacs key
[18:49] <Compn> are there distros that even accept libdvdcss ?
[18:49] <funman> what we (including i) don't get is how libaacs is different from libdvdcss
[18:49] <funman> and libbd+
[18:50] <funman> Compn: iirc altlinux (russian distro) did/does
[18:53] <gnafu> funman: Well, the content on Blu-ray discs is, like, 6 times the resolution of DVD content, so it's at least 6 times more important to protect it.
[18:56] <funman> so i can go and sell VHS copies in front of MPAA offices?
[18:56] <funman> well i hope oyu're not serious
[18:56] <Compn> that would only make sense if you could divide by zero
[18:56] <Compn> funman
[18:56] <funman> if you sell drugs your sentence isn't proportional to the amount you sold
[18:57] <funman> video content isn't worth protecting only at some resolution
[18:57] <funman> to me libaacs + libbd+ = libdvdcss, same same
[18:57] <Compn> and yes that was a joke
[18:58] <Compn> gnafu also did the mplayer doesnt afraid of anything meme :)
[18:58] <funman> sorry i didnt catch it - bad day
[18:58] <Compn> j-b : anyways, lots of people want to help if they can with bluray stuff. just let us know if we can.
[18:58] Action: Compn goes afk
[19:00] <funman> Compn: j-b: first thing would be release code to select peoples remove "sensitive" stuff, then release non-working sources so everyone can improve on it
[19:02] Action: ubitux kicks CIA-31 
[19:02] <CIA-31> ow
[19:04] <gnafu> funman: General rule of thumb for interpreting what I say is that I'm probably not serious ;D.
[19:05] <gnafu> Especially if I use one or more smilies, or if I put "like" in the middle of a sentence like a valley girl :-).
[19:06] <ubitux> Tjoppen: it seems the ptses is leaking in mxf demuxer
[19:07] <ubitux> Tjoppen: http://pastie.org/3179588 with fate-lavf-mxf 
[19:14] <CIA-31> ffmpeg: 03Stefano Sabatini 07master * r3fcf841ff5 10ffmpeg/libavformat/mpegtsenc.c: mpegtsenc: fix some typos: aac -> AAC, adts -> ADTS
[19:14] <CIA-31> ffmpeg: 03Stefano Sabatini 07master * r0be8e66174 10ffmpeg/libavformat/mpegtsenc.c: 
[19:14] <CIA-31> ffmpeg: mpegtsenc: do not reference the deprecated ffmpeg option 'vbsf' in a log message
[19:14] <CIA-31> ffmpeg: Give a more generic advice.
[19:14] <CIA-31> ffmpeg: 03Stefano Sabatini 07master * r7efc6f2932 10ffmpeg/ffmpeg.c: ffmpeg: clarify error message in case of bitstream filter opening failure
[19:14] <CIA-31> ffmpeg: 03Stefano Sabatini 07master * r9a7f2aa958 10ffmpeg/libavformat/mpegtsenc.c: mpegtsenc: use more meaningful error codes
[19:15] <CIA-31> ffmpeg: 03Michael Niedermayer 07master * r645569e19f 10ffmpeg/libavformat/riff.c: 
[19:15] <CIA-31> ffmpeg: Revert "riff: remove references to sonic codec ids"
[19:15] <CIA-31> ffmpeg: This reverts commit 0fd88d398896353074fee153259dbf3530ca423f.
[19:15] <CIA-31> ffmpeg: Theres no reason to drop support for this.
[19:15] <CIA-31> ffmpeg: 03Nicolas Noirbent 07master * r62a22b2865 10ffmpeg/libavformat/segment.c: 
[19:15] <CIA-31> ffmpeg: segment: fix FPE when segment_list_size is 0
[19:15] <CIA-31> ffmpeg: With the added benefit that allowing -segment_list_size 0 makes it
[19:15] <CIA-31> ffmpeg: possible to keep all segment entries in the list file.
[19:15] <CIA-31> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[19:15] <CIA-31> ffmpeg: 03Peter Ross 07master * r3a1df393b8 10ffmpeg/libavformat/icodec.c: 
[19:15] <CIA-31> ffmpeg: ico: favour BITMAPHEADER dimensions over IconEntry dimensions
[19:15] <CIA-31> ffmpeg: Fixes ticket 759.
[19:15] <CIA-31> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[19:15] <CIA-31> ffmpeg: 03Nicolas Noirbent 07master * rc949d5b15d 10ffmpeg/ffmpeg.c: 
[19:15] <CIA-31> ffmpeg: ffmpeg.c: transcode_video(): do not go through filter network if encoding is not required
[19:15] <CIA-31> ffmpeg: This fixes a segmentation fault when doing a transcoding and a stream
[19:16] <CIA-31> ffmpeg: copy of the same input stream at the same time, e.g.:
[19:16] <CIA-31> ffmpeg: ffmpeg -i in.mkv -c:v mpeg2video transcode.m2v -c copy copy.ts
[19:16] <CIA-31> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[19:16] <CIA-31> ffmpeg: 03Clément BSsch 07master * re3127db438 10ffmpeg/ffmpeg.c: ffmpeg: use av_asprintf() in opt_old2new() and fix a memleak.
[19:16] <CIA-31> ffmpeg: 03Clément BSsch 07master * r2a81e0c2ad 10ffmpeg/ffmpeg.c: ffmpeg: fix parse_option() string memleak.
[19:16] <CIA-31> ffmpeg: 03Clément BSsch 07master * rf2193569a5 10ffmpeg/libavcodec/8svx.c: 8svx: fix memleak in iff-fibonacci fate test.
[19:16] <CIA-31> ffmpeg: 03Stefano Sabatini 07master * re4fa15d156 10ffmpeg/configure: 
[19:16] <CIA-31> ffmpeg: configure: provide libavfilter/version.h header to get_version()
[19:16] <CIA-31> ffmpeg: Fix libavfilter library version numbers generation, which was broken in
[19:16] <CIA-31> ffmpeg: 3167dc9515810bbdd86d99d773bcf84657d2e72a.
[19:20] <CIA-31> ffmpeg: 03Ray Simard 07master * r7f6004fc74 10ffmpeg/libavfilter/vf_deshake.c: 
[19:20] <CIA-31> ffmpeg: vf_deshake: zero-init Transform structs in end_frame()
[19:20] <CIA-31> ffmpeg: Initialize Transform structs t and orig to zero.
[19:20] <CIA-31> ffmpeg: Signed-off-by: Ray Simard <rhs.ffmpeg at sylvan-glade.com>
[19:20] <CIA-31> ffmpeg: Signed-off-by: Stefano Sabatini <stefasab at gmail.com>
[19:20] <CIA-31> ffmpeg: 03Ray Simard 07master * r369befb41e 10ffmpeg/libavfilter/vf_deshake.c: 
[19:20] <CIA-31> ffmpeg: vf_deshake: remove unused variable totalangles
[19:20] <CIA-31> ffmpeg: Variable totalangles was created and assigned, but never used.
[19:20] <CIA-31> ffmpeg: Signed-off-by: Ray Simard <rhs.ffmpeg at sylvan-glade.com>
[19:20] <CIA-31> ffmpeg: Signed-off-by: Stefano Sabatini <stefasab at gmail.com>
[19:30] <CIA-31> ffmpeg: 03Clément BSsch 07master * rad12d60d73 10ffmpeg/ffmpeg.c: ffmpeg: fix return value in opt_old2new after e3127db4.
[19:35] <funman> gnafu: ok
[19:51] <CIA-31> ffmpeg: 03Reimar Döffinger 07master * r4cef928ef7 10ffmpeg/libavcodec/j2kdec.c: 
[19:51] <CIA-31> ffmpeg: j2kdec: Fix memleak, ensure cleanup is called also on error.
[19:51] <CIA-31> ffmpeg: Fixes valgrind fate with fate-suite/r3d/4MB-sample.r3d.
[19:51] <CIA-31> ffmpeg: Signed-off-by: Reimar Döffinger <Reimar.Doeffinger at gmx.de>
[20:17] <ubitux> it seems running all the valgrind tests doesn't take 1-2hours actually, but more like 6 or 8
[20:17] <ubitux> :(
[21:53] <uau> michaelni: IIRC libpostproc is not quite "100% the same ABI" in 51 and 52
[21:54] <uau> there was a help string symbol that changed, IIRC from a pointer to a string to the string itself
[21:55] <uau> yes ffmpeg still has this in postprocess.h:
[21:55] <uau> extern const char *const pp_help; ///< a simple help text
[21:55] <uau> #else
[21:55] <uau> extern const char pp_help[]; ///< a simple help text
[21:57] <ohsix> what are the implications of the constness change to code that is built against the old version
[21:58] <michaelni> uau, i had not realized that this changed :(
[21:58] <uau> ohsix: what "constness change"? you must have misread that
[21:59] <ohsix> * pp_help and pp_help[] are the same, *const pp_help and pp_help[] are not
[22:00] <uau> ohsix: you're confused
[22:01] <ohsix> and?
[22:02] <ohsix> i guess if it's in front of const it's not the same, nevermind
[22:04] <ohsix> or is it
[22:04] <beastd> if i am not mistaken it is an array-vs-pointer change
[22:04] <ohsix> that's what cdecl says
[22:07] <uau> ohsix: that difference actually mattered for mplayer2 code (and likely for mplayer 1, as the relevant part came from it)
[22:07] <ohsix> but it doesn'ttt
[22:08] <ohsix> an array declared like that is equivalent to a pointer
[22:08] <ohsix> it just changes the constness of the reference
[22:08] <uau> there was a global constant help string struct where one element was initialized to "&pp_help"
[22:09] <ohsix> what jerks
[22:09] <uau> in postproc 51 that means pointer to the pointer
[22:09] <uau> in postproc 52 that means pointer to the first character of the string
[22:09] <uau> definitely completely different meanings
[22:10] <ohsix> that's an api change though, unless you have something writing the strings (that's discernable at compile time, all bets for constness are off at runtime), not an abi change
[22:10] <uau> it is an abi change
[22:10] <uau> in 51 abi the symbol "pp_help" is resolved to point to the first byte of a pointer
[22:11] <uau> in 52 abi the symbol "pp_help" is resolved to point to the first byte of a string
[22:11] <uau> definitely different abi
[22:11] <ohsix> oh i see
[22:11] <ohsix> pointer size change since it's char
[22:11] <uau> you're still missing the biggest difference
[22:12] <ohsix> i'm not missing the one that drew me to the wrong conclusion now, though
[22:12] <uau> the api actually changed "less" in a way; something like say "pp_help[0]" would still give the same result on an API level, even though the underlying ABI changed
[22:13] <uau> in 51 abi that'd mean "read pointer from the location given by pp_help, then read character from the location given by the pointer"
[22:13] <uau> in 52 abive that'd mean "read character from the location given by the pp_help symbol"
[22:15] <beastd> ohsix:  what makes you think it is equivalent to a pointer? the syntax deceives you into using it like pointer/array but the binary interface is quite a different thing, isn't it?
[22:16] <ohsix> beastd: yea the binary interface is what i was thinking of, and assuming char and the native pointer size were wquivalent
[22:16] <beastd> ohsix: you are missing the (now missing) indirection
[22:17] <ohsix> ok
[22:17] <michaelni> i guess the best way to resolve this in 0.9.2 would be to compile & install postproc for both ABIs
[22:20] <iive> i actually wonder how the underling assembler have changed.
[22:20] <michaelni> maybe someone has a better idea ...
[22:22] <uau> iive: you mean when using the symbol?
[22:23] <iive> yes. I would assume that in the [] case the linker would try to overwrite the address in the calling binary.
[22:23] <uau> "char *p = pp_help;" in 51 this would resolve the symbol pp_help (which could have been done at link time, or could result in a call to resolve dynamic linking), and then would do a load from the pp_help address
[22:24] <uau> in 52 it would resolve the symbol pp_help, and that itself would be the result
[22:41] <iive> michaelni: building and installing two separate and almost identical libraries sounds like horrible idea. especially for such small difference. And then you'd have the same problem for the headers and picking the right library at link time...
[22:42] <michaelni> iive, the headers are a problem :(
[22:44] <michaelni> i guess that leaves adding a switch to configure so the person compiling can choose which he wants
[22:47] <iive> there is another solution, you can make the pointer a null one. it would also constitute an empty string. still I'm not sure it NULL pointer won't break the programs that use it without checking.
[22:48] <iive> it NULL/if NULL
[22:48] <iive> and is horrible bit of hackery....
[23:19] <funman> any clue on a win64 application using ffmpeg's dxva2?
[23:19] <funman> i know it's broken in vlc/win64 but no idea if it's on ffmpeg or vlc side
[23:20] <funman> and WMP works
[23:40] <Compn> funman : dumb question, why not just use 32bit ?
[23:43] <funman> Compn: 64 is 2 times better than 32!!
[23:43] <Compn> when it works.
[23:43] <funman> more seriously 32bits work fine
[23:43] <Compn> ah
[23:43] <funman> the question could have been "why using windows" :)
[23:44] <Compn> well since you cant really use ffmpeg dxva2 by itself, its going to be difficult to figure if its ffmpeg or vlc
[23:44] <funman> well the bug is somewhere
[23:44] <Compn> and since its pretty much only vlc (and possibly mpc-ht) using dxva2, if they fix it, they will fix ffmpeg too ;P
[23:44] <funman> and debugging tools for windows are crap when they exist at all
[23:44] <funman> yeah
[23:44] <funman> they = me in this case
[23:44] <Compn> oh ok
[23:45] <Compn> so your question is
[23:45] <Compn> how do you debug a win64 mingw app ?
[23:45] <kierank> gdb
[23:45] <Compn> right
[23:45] <funman> do you guys have gdb/mingw skills?
[23:46] <Compn> add in a bunch of printfs' to vlc and ffmpeg and see how far it gets
[23:46] <funman> well in fact i have a backtrace
[23:46] <Compn> gdb works fine on mingw, well, on 32bit, i havent tested 64 but it should be the same.
[23:46] <funman> but only function names, no lines
[23:46] <Compn> did you compile everything with debug symbols ?
[23:46] <funman> and vlc use DLLs so it's a bit special
[23:46] <funman> yeah
[23:46] <Compn> but if you paste the backtrace at least we can try to figure where its crashing
[23:47] <Compn> even without lines, maybe
[23:47] <funman> are you interested in helping me with that? i'll reboot to windows
[23:47] <Compn> i am trying to figure out who is the mingw64 master
[23:48] <Compn> kshawkeye / zeranoe and whoever added dxva2 to ffmpeg
[23:48] <Compn> who else does 64mingw 
[23:48] Action: Compn thinks
[23:48] <funman> ramiro
[23:49] <Compn> Gianluigi Tiesi also does a lot of mplayer mingw stuff
[23:50] <Compn> reimar plays with it i think
[23:51] <Compn> well you can always boot to windows and ask
[23:51] <Compn> we can try :)
[23:53] <funman> ok let's see
[00:00] --- Sat Jan 14 2012