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

[burek]

[00:07] <michaelni> durandal_1707, i gave multiple ffmpeg-devs coverity accounts last year
[00:09] <michaelni> its possible that by default everyone who has an account gets mails now
[01:07] <cone-963> ffmpeg.git 03Michael Niedermayer 07master:32fc8d6db65e: avcodec/jpeg2000dec: check that tp_end is after the start
[01:07] <cone-963> ffmpeg.git 03Michael Niedermayer 07master:c17dd513e7f1: bytestream2_init: assert that buf_size is valid
[01:25] <cone-963> ffmpeg.git 03Michael Niedermayer 07release/0.10:8ddc9790edc1: avformat/libmodplug: Reduce the probe score for small input
[01:25] <cone-963> ffmpeg.git 03Michael Niedermayer 07release/0.11:a1e4d1f933c9: avformat/libmodplug: Reduce the probe score for small input
[01:25] <cone-963> ffmpeg.git 03Michael Niedermayer 07release/0.9:340c1843c59c: avformat/libmodplug: Reduce the probe score for small input
[01:25] <cone-963> ffmpeg.git 03Michael Niedermayer 07release/1.0:8d18dbda1e45: avformat/libmodplug: Reduce the probe score for small input
[01:25] <cone-963> ffmpeg.git 03Michael Niedermayer 07release/1.1:2cfdf732efaf: avformat/libmodplug: Reduce the probe score for small input
[01:25] <cone-963> ffmpeg.git 03Michael Niedermayer 07release/1.2:e4bb67bc5069: avformat/libmodplug: Reduce the probe score for small input
[01:25] <cone-963> ffmpeg.git 03Michael Niedermayer 07release/1.2:073bde2b1fbb: avformat/iff: Byte seek is unsupported
[02:08] <durandal_1707> the thing that shows configuration parameters is cut in middle, like fixed size array was used
[03:18] <Daemon404> im retiring my linux fate instances i think
[03:18] <Daemon404> since clang 3.3 is out with ioc built in
[03:18] <Daemon404> adding icl instances to ffmpeg as we speak
[03:39] <cone-963> ffmpeg.git 03Michael Niedermayer 07master:79cd5d39ba11: avcodec/utvideodec: Fix vlc len
[03:40] <Daemon404> http://fate.ffmpeg.org/report.cgi?time=20130621013942&slot=i686-windows-icl
[03:41] <Daemon404> sure is lavfi failures
[03:50] <cone-963> ffmpeg.git 03Timothy Gu 07master:8cdea50f6eee: doc/decoders: Document libilbc decoder
[04:04] <BBB> Daemon404: I think ubitux wanted to help as well
[04:04] <BBB> maybe saste
[04:04] <BBB> we'll see how many end up helping
[04:04] <BBB> but yes aug should work, it'll be fun :)
[07:53] <ubitux> BBB: yes i made some time space for exactly one month full time in august :)
[08:04] <nevcairiel> interesting that ICL has the same fate rgb failure as MSVC. well, plus some more
[08:04] <nevcairiel> I should really find some time to figure out wtf is up
[08:06] <ubitux> [Parsed_amovie_0 @ 00A9AC20] Failed to avformat_open_input 'C' [lavfi @ 00AB9080] Error initializing filter 'amovie' with args 'C:/Msys/1.0/devel/fate/samles_ffmpeg/amrwb/seed-12k65.awb'
[08:06] <ubitux> classic shit ;)
[08:41] <ubitux> anyone tested -fsanitize=thread with clang?
[08:44] <ubitux> same question with "undefined" and "integer"
[09:15] <nevcairiel> ubitux: for these errors yes, its just the stupid parsing problem, but the rgb errors do not have that, so i'm going to assume its similar to the msvc problem
[09:16] <nevcairiel> especially because they produce the same frame hashes
[09:16] <ubitux> interesting :)
[09:16] <nevcairiel> if i remember correctly, we saw some chroma shift in these, right?
[09:16] <nevcairiel> maybe a rounding thing somewhere
[09:16] <nevcairiel> well, i'll try to check, maybe on the weekend
[09:17] <ubitux> yes it was something along those lines
[09:17] <ubitux> i'm wondering if that's not related to the pad code
[09:37] <ubitux> 09:33:31 <+av500> http://people.xiph.org/~xiphmont/demo/daala/demo1.shtml
[10:50] <cone-11> ffmpeg.git 03Anton Khirnov 07master:eeeb5c291d3f: vsrc_movie: do not free avoption variables in uninit()
[10:50] <cone-11> ffmpeg.git 03Michael Niedermayer 07master:5d509fbdcf62: Merge commit 'eeeb5c291d3f78eaade5b99c2614c7cab0e9be79'
[11:18] <cone-11> ffmpeg.git 03Anton Khirnov 07master:720a1de52fb4: lavc: free the padded last frame during audio encoding properly
[11:18] <cone-11> ffmpeg.git 03Michael Niedermayer 07master:98abe16522be: Merge remote-tracking branch 'qatar/master'
[12:36] <cone-11> ffmpeg.git 03Michael Niedermayer 07master:1ee8fadb811f: avdevice/x11grab: allocate just one Cursor
[12:36] <cone-11> ffmpeg.git 03Timothy Gu 07master:b43860ee0c27: doc/decoders: Document libopencore-amrnb decoder
[12:56] <cone-11> ffmpeg.git 03Hendrik Leppkes 07master:659df32a9d89: mathops/x86: work around inline asm miscompilation with GCC 4.8.1
[15:24] <BBB> nevcairiel: I have some very old local todo that says that the c code rgb to yuv or yuv to rgb conversion has some byte inversions compared to the simd
[15:25] <BBB> nevcairiel: since that (unscaled) code is inline mmx, it would mean that it is only triggered on systems missing any optimizations, or missing inline asm
[15:25] <BBB> nevcairiel: I don't think we have a fate station that does --cpu-mask 0
[15:28] <JEEB> BBB, reminds me that it was a difference in the YCbCr->RGB conversion code that broke my Ut Video encoder tests last year :D Since mru told me to remove the 'bitexact' flag ("Don't put in flags that you don't know"), and I was basically matching to the output of the asm'ified code path.
[15:31] <nevcairiel> BBB: well easy enough to test locally
[15:32] <nevcairiel> i'll do that this weekend iguess
[15:55] <nevcairiel> BBB: -cpuflags 0 still passes the test here
[16:06] <nevcairiel> even funnier, if i run MSVC with cpuflags=0, it passes
[16:06] <nevcairiel> o.O
[16:13] <nevcairiel> so one of the very few yasm swscale functions isnt playing nice, i guess
[16:18] <Chikuzen> old patch http://git.videolan.org/?p=ffmpeg.git;a=blobdiff;f=libavformat/avisynth.c;h=c4c523dc8a611b8f4ec7da0799a585658fe7b4b8;hp=3b695a9a0aaa19cf0f622aa191c93171e193f0f1;hb=5c742005fb7854dcfaa9f0efb65fd36a63ceaa2b;hpb=0fcf3013c4aa4f70c39899b7b3bd8c451fe2e493
[16:18] <Chikuzen> new patch https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2013-June/144927.html
[16:18] <Chikuzen> wtf
[16:19] <nevcairiel> wasnt the avisynth demuxer rewritten in between
[16:28] <JEEB> yes, qyotwhatever dude added avxsynth support
[16:28] <JEEB> and thus removed that thing
[16:32] <BBB> nevcairiel: then why would it pass on linux etc.?
[16:32] <BBB> nevcairiel: sounds more to me like an issue with stack alignment disabling certain optimizations or so
[16:33] <BBB> nevcairiel: e.g. there being a mmx and sse2, sse2 requiring aligned stack, thus being disabled on msvc
[16:33] <BBB> nevcairiel: can you try -cpuflags mmx etc. and up to see when it fails?
[16:34] <nevcairiel> i did, mmx gives wrong result, sse2 crashes
[16:34] <BBB> uh
[16:34] <BBB> ok
[16:35] <nevcairiel> not sure why "all" doesnt crash
[16:35] <BBB> missing bitexact flag?
[16:35] <nevcairiel> its set
[16:35] <BBB> I believe ffmpeg and libav have different meanings for sse2
[16:35] <BBB> if you want libav's meaning of sse2, you need to use mmx+mmx2+sse+sse2 or so
[16:36] <BBB> it was something horrific like that last time I looked
[16:36] <BBB> (I had the same issue a while ago)
[16:36] <nevcairiel> funny enough mmx+sse2 doesnt crash
[16:36] <nevcairiel> i'm confused
[16:36] <BBB> :)
[16:37] <BBB> ok but so mmx fails
[16:37] <BBB> I bet it's a missing stack alignment directive
[16:37] <BBB> or so
[16:38] <BBB> you can file a bug and assign it to me, maybe I'll have time to look
[16:51] <shurick> is there any bad consequences from increasing MAX_SLICES in libavcodec/h264.h from 16 to 512?
[17:02] <nevcairiel> memory requirements most likely
[17:02] <nevcairiel> why change it?
[17:04] <shurick> i have to work with heavily sliced h264 streams
[17:05] <shurick> i'd like this change to be persistent, if it would not cause any harm to other users
[17:05] <Skyler_> 16 is rather low IMO; it should be at least ~256
[17:05] <Skyler_> technically, most sliced streams work fine with it set to *1*
[17:06] <Skyler_> but it'll spam warnings, which is actually the main problem
[17:06] <Skyler_> the other problem is it's used in the calling code for one of the hardware decoders (dxva2?) so a many slice stream will actually crash there instead of just warn
[17:25] <cone-11> ffmpeg.git 03Michael Niedermayer 07release/1.1:d8e76a531cd7: avdevice/x11grab: allocate just one Cursor
[17:25] <cone-11> ffmpeg.git 03Michael Niedermayer 07release/1.2:fbb1af39e464: avdevice/x11grab: allocate just one Cursor
[17:48] <cone-11> ffmpeg.git 03Andrey Utkin 07master:3857aea6d960: doc/protocols: document "srtp" protocol
[17:48] <cone-11> ffmpeg.git 03Stefano Sabatini 07master:3f8750776f38: doc/protocols: apply very minor consistency fixes
[18:05] <nevcairiel> ahah i fixed it
[18:06] <nevcairiel> stupid swscale
[18:11] <nevcairiel> whole swscale gets messed up if your cpu flags contain sse2 but not mmx, luckily this is not a problem in real world, but really can make you get odd errors when using -cpuflags <.<
[18:28] <nevcairiel> \o/ msvc fate passes again with the patch
[18:28] <cone-11> ffmpeg.git 03Timothy Gu 07master:83647ace735d: doc/decoders: Add libopencore-amrwb decoder doc
[18:28] <cone-11> ffmpeg.git 03Stefano Sabatini 07master:7cc4115dd6d1: doc/decoders,decoders: add various missing final dots
[20:49] <cone-11> ffmpeg.git 03Michael Niedermayer 07master:2005fddcbb4e: h264/ff_h264_check_intra_pred_mode: fix input value check
[20:49] <cone-11> ffmpeg.git 03Michael Niedermayer 07master:d6a33f5d20b6: h264: fix size of arrays in ff_h264_check_intra_pred_mode()
[21:17] <cone-11> ffmpeg.git 03Hendrik Leppkes 07master:7cdf574c22b8: swscale: fix filter alignment reduction without inline asm
[21:54] <wingrime> michaelni: I hope you still remeber me, I need ask some help...
[21:56] <ubitux> anyone interested in a tsan fate instance?
[22:04] <nevcairiel> http://fate.ffmpeg.org/report.cgi?time=20130621200342&slot=x86_32-msvc10-dll-windows-native
[22:05] <nevcairiel> yay, its green again
[22:05] <nevcairiel> and it wasnt ubitux's fault afterall
[22:05] <ubitux> :)
[22:05] <ubitux> i guess moving to filter complex make a different filter insert
[22:05] <nevcairiel> i still wonder why it started failing the day you changed the fate tests
[22:05] <Daemon404> orite
[22:05] <Daemon404> ill enable more icl stuff today
[22:05] <Daemon404> i.e. 64
[22:06] <nevcairiel> you need to fix the pathes you use
[22:06] <Daemon404> me?
[22:06] Action: ubitux trying to add a tsan instance
[22:06] <nevcairiel> well unless you want the tests to fail until someone is annoyed enough to write a new option parser
[22:06] <Daemon404> eh
[22:06] <Daemon404> what magic do i need
[22:06] <Daemon404> this sounds annoying already
[22:06] <nevcairiel> use relative path
[22:07] <nevcairiel> the : in windows absolute confuses it
[22:07] <Daemon404> for what
[22:07] <Daemon404> there are like 6 paths to change
[22:07] <nevcairiel> fate samples url
[22:07] <Daemon404> o
[22:07] <Daemon404> well that just feels dirty
[22:07] <Daemon404> :(
[22:07] <Daemon404> also relative to WHAT
[22:07] <Daemon404> there are liek 4 possible places
[22:07] <nevcairiel> to the target path
[22:08] <nevcairiel> where the binary runs
[22:08] <Daemon404> thats still too vague
[22:08] <Daemon404> that coul be the traget path, .../install, .../install/bin
[22:08] <Daemon404> etc
[22:09] <Daemon404> whats teh CWD when fate runs
[22:09] <nevcairiel> i have it relative to what is set in target_path
[22:09] <Daemon404> ok
[22:09] <Daemon404> what a crapshoot.
[22:09] <nevcairiel> the problem is a combination of silly factors
[22:10] <nevcairiel> mostly because a msvc exe is being run from a msys shell
[22:10] <nevcairiel> it doesnt combine too well
[22:10] <nevcairiel> but also because the damn option parser uses : as a separator
[22:11] <Daemon404> wouldnt that fail being run from cmd.exe too
[22:11] <nevcairiel> eh, i forget, its been a while since i looked into it properly
[22:12] <Daemon404> if so
[22:12] <Daemon404> im pretty sure windows has a function that checks if some arbitrar string is a valid path
[22:12] <Daemon404> which could be useful
[22:13] <nevcairiel> i think it would probably fail with cmd.exe too
[22:13] <nevcairiel> curious that noone complained on trac yet (or i didnt see it), but guess most people still use mingw builds
[22:14] <Daemon404> because nobody uses lavfi
[22:14] Action: Daemon404 runs
[22:14] <nevcairiel> yeah its really only a problem if you use this lavfi input device instead of using a "normal" input and then piping it through a filter graph
[22:15] <nevcairiel> i can see how many people wouldnt use this special magic
[22:15] <Daemon404> http://msdn.microsoft.com/en-us/library/windows/desktop/aa364963(v=vs.85).aspx
[22:15] <Daemon404> call this when in doubt
[22:15] <Daemon404> to see if it fails
[22:15] <Daemon404> ?
[22:16] <nevcairiel> i'm sure the lavfi maintainers will enjoy MS specific code in their neat little files =)
[22:16] <Daemon404> because purity is more important than working? ;)
[22:17] <nevcairiel> that depends who you ask, i guess
[22:17] Action: Daemon404 points nevcairiel at haskell
[22:17] <nevcairiel> i dont know enough about the lavfi input parsing stuff to even figure out where to put that
[22:17] <ubitux> lavfi "maintainers" mostly just can't test with windows related stuff
[22:17] <nevcairiel> and frankly, i only use the libraries =)
[22:17] <Daemon404> ubitux, well thats why fate exists!
[22:18] <ubitux> that doesn't help to write windows code
[22:18] <ubitux> when you're running *nix systems only
[22:18] <Daemon404> the option parsing is reproducible in wine
[22:18] <Daemon404> or should be.
[22:18] <Compn> ubitux : help me in #mplayerdev :P
[22:18] <nevcairiel> i can setup a win7 VM with visual studio for anyone that wants to work on it :D
[22:18] <ubitux> Daemon404: ’ ENOCARE then
[22:18] <Daemon404> ?
[22:18] <Daemon404> i dont follow the logic
[22:18] <nevcairiel> even run it on my server for you to RDP into!
[22:19] <Daemon404> i was thinking
[22:19] <Daemon404> after that libav email about msvc
[22:19] <Daemon404> i see enough of those emails
[22:19] <ubitux> Compn :/
[22:19] <Daemon404> i might do a small sreencast
[22:19] <Daemon404> "this is how you build it"
[22:19] <nevcairiel> its really not that complicated
[22:19] <Daemon404> nevcairiel, ... youd be surprised
[22:19] <Daemon404> people work in MSVS 24/7 for years
[22:19] <Daemon404> msys is scary and confusing
[22:19] <Daemon404> etc
[22:20] <nevcairiel> well i suppose you need a small scavenger hunt to gather the tools required
[22:20] <Daemon404> i thought i documented it pretty well in platforms.texi
[22:20] <Daemon404> apparently not well enough.
[22:20] <nevcairiel> while i know where to find a finished msys package without much fuzz, people may not
[22:20] <Daemon404> eh?
[22:20] <Compn> isnt it better to crosscompile mingw using cygwin ?
[22:20] <Daemon404> mingw-get installer
[22:20] <Daemon404> is one click
[22:20] <Compn> because then you get cygwin bash and mingw exe files...
[22:20] <nevcairiel> thats "fuzz" for me, i rather get a zip and unpack, and there we go
[22:21] <nevcairiel> Compn: cygwin is horrible
[22:21] <Daemon404> cygwin runtime is not horrible
[22:21] <Daemon404> its standard env is though
[22:22] <nevcairiel> everytime i use cygwin i afterwards have to fix my filesystem permissions
[22:22] <Daemon404> but yeah i get at least one email a month
[22:22] <Daemon404> for help with msvc
[22:22] <Daemon404> i dont know how much of that is stupidity or not reading the docs or what
[22:23] <nevcairiel> i suppose if you also want zlib, and then zlib not dynamically linked (because carrying around zlib-1.dll or what its called is silly), it might end up scaring some people off
[22:24] <Compn> most builds are static
[22:24] <nevcairiel> the pre-built zlib for windows comes with the silly dll iirc
[22:24] <Daemon404> Compn, static is not feasible for many windows things
[22:24] <Daemon404> i.e.e not FOSS
[22:24] <Daemon404> because LGPL.
[22:25] <nevcairiel> can still static-link zlib into av* and then dynamic link those to your app
[22:25] <nevcairiel> no violations there
[22:25] <Daemon404> nevcairiel, and it builds with -MD b default
[22:25] <Daemon404> zlib, i mean.
[22:25] <nevcairiel> not really relevant if you static link it
[22:26] <Daemon404> well yeah it is
[22:26] <Daemon404> libav/ffmpeg are MT
[22:26] <nevcairiel> i havent had to change anything in zlib config at least when i built it a few weeks ago
[22:26] <Daemon404> mixing crt = n fun
[22:26] <Daemon404> no*
[22:26] <Plorkyeran> building ffmpeg/libav with MD is no longer difficult
[22:26] <nevcairiel> but static libraries dont carry the crt anyway
[22:27] <Daemon404> Plorkyeran, no but MT i still default
[22:27] <nevcairiel> they rely on the stuff you link to to provide it
[22:27] <michaelni> wingrime, what kind of help ?
[22:27] <michaelni> ubitux, more fate instances are always wanted
[22:27] <Daemon404> nevcairiel, that hasnt stopped msvc from crapping out botloads of problems with MT and MD generated code
[22:27] <Plorkyeran> that doesn't help with MD/MT stuff
[22:27] <Plorkyeran> the static library will still be looking for the wrong symbols
[22:27] <ubitux> michaelni: a first report should arrive "soon"
[22:27] <Daemon404> yea
[22:27] <ubitux> michaelni: hopefully in less time than helgrind or drd
[22:28] <ubitux> (and maybe less than a 800M report..)
[22:28] <wingrime> michaelni: with understandment witch hw decoder choose for implemnt
[22:28] <Plorkyeran> which runtime library to use isn't determined entirely by how you link the final executable/dll
[22:28] <nevcairiel> hm, maybe i just forgot that i changed it
[22:29] <nevcairiel> who knows
[22:29] <nevcairiel> links fine anyway
[22:29] <wingrime> michaelni: I mean hw  decoder API
[22:29] <Compn> michaelni : what hw decoder api is the current one? there is vda and ... something ?
[22:30] <michaelni> wingrime, you know your hw, so you should be able to choose how to implement it better than i (who doesnt know at all)
[22:31] <nevcairiel> doesnt ffmpeg already have all relevant hw APIs?
[22:31] <nevcairiel> i suppose some stuff for ARM devices isnt present
[22:31] Action: nevcairiel shrugs
[22:32] <wingrime> blob use self-made API
[22:33] <wingrime> michaelni: question was, witch API implement , vdpau, or ....
[22:34] <wingrime> I simply don't know witch will work with ARM and hw overlays
[23:00] <burek> this looks like an mpegts issue or so http://ffmpeg.gusari.org/viewtopic.php?f=16&t=957
[23:37] <michaelni> wingrime, thats really your dicission and i know even less which will work with "ARM and hw overlays", if someone else knows something iam sure he will reply though
[23:39] <cone-11> ffmpeg.git 03Hendrik Leppkes 07master:1a405c683e03: smvjpeg: remove redundant frame init code
[00:00] --- Sat Jun 22 2013