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

[burek]

[00:00] <durandal11707> random crap crash with low mem
[00:58] <Compn> whats the low mem
[00:58] <Compn> i didnt understand it from the bug report
[00:59] <Compn> oh max_alloc
[01:00] <Compn> durandal11707 : all the old stuff (h263, rm , indeo) will probably crash. those decoders are in some ... not great shape
[01:41] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:6d6eabd399eb: mjpeg_decode_dc: check code before using it in get_xbits()
[01:41] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:13c56e9a9cf1: 4xm: check for invalid zero ac coeffs
[01:41] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:68efb1d60a99: 4xm: Dont ignore dc run errors
[01:41] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:ff130d7363e0: get_xbits: assert validity of the number of bits
[01:42] <Compn> durandal11707 : so are these crashes something that might affect regular systems or is it just another 'fill the code up with checks no one needs' ?
[01:43] <durandal11707> Compn: could you please stop highlighting me?
[01:43] <Compn> ok
[08:19] <superware> michaelni: hi
[09:59] Last message repeated 1 time(s).
[11:22] <cone-914> ffmpeg.git 03Loren Merritt 07master:cc6714bb16b1: lpc: remove "decay" argument
[11:22] <cone-914> ffmpeg.git 03Michael Niedermayer 07master:d3bd320e63bf: Merge commit 'cc6714bb16b1f0716ba43701d47273dbe9657b8b'
[11:25] <superware> michaelni: hi, you here?
[11:30] <cone-914> ffmpeg.git 03Loren Merritt 07master:41578f70cf8a: lpc: use function pointers, in preparation for asm
[11:30] <cone-914> ffmpeg.git 03Michael Niedermayer 07master:c93a424718c3: Merge commit '41578f70cf8aec8e7565fba1ca7e07f3dc46c3d2'
[11:32] <ubitux> superware: just speak, he will read later
[11:33] <superware> michaelni: remember your "udp: Fix receiving large udp packets"? well, my stream still doesn't play (while it's dump does), please ping me when you see this.
[11:34] <michaelni> superware, can you post the full uncut output of the new version again / is the error that occured last time still occuring ?
[11:38] <superware> michaelni: http://pastebin.com/7BQpVYGG
[11:39] <superware> no [udp] errors/warnings, but still not playing
[11:41] <michaelni> superware, then probably theres a second issue with this stream
[11:41] <superware> :) its dump plays
[11:42] <superware> please let me stream it to you
[11:46] <michaelni> superware, maybe later but i already have an idea what it could be so it wont help much
[11:46] <superware> a) I've tried various MPEG-2 Transport Stream packet analyzers, b) even implemented my own TS depacketizer, c) VLC plays from udp, d) raw dump plays
[11:48] <superware> michaelni: ok, I just thought trying the stream directly will lead to all bugs/issues at once :)
[11:50] <superware> michaelni: maybe I can stream it to someone else here?
[11:55] <michaelni> superware, i will look into it later when i have time, it wont help to stream to me until iam out of things to fix
[12:11] <superware> michaelni: ok, I appreciate your help on this. Please tell me if you need me to do/test something, I'll be here.
[12:14] <cone-914> ffmpeg.git 03Loren Merritt 07master:502ab21af0ca: x86: lpc: simd av_update_lls
[12:14] <cone-914> ffmpeg.git 03Michael Niedermayer 07master:78b547963362: Merge commit '502ab21af0ca68f76d6112722c46d2f35c004053'
[12:14] <cone-914> ffmpeg.git 03Michael Niedermayer 07master:0b40c505087f: lls.asm: put avx code under if HAVE_AVX_EXTERNAL
[12:14] <cone-914> ffmpeg.git 03Michael Niedermayer 07master:a285079bc75a: lls.asm: disable ff_update_lls_avx
[12:19] <cone-914> ffmpeg.git 03Loren Merritt 07master:b545179fdff1: x86: lpc: simd av_evaluate_lls
[12:19] <cone-914> ffmpeg.git 03Michael Niedermayer 07master:6e76e6a05a56: Merge commit 'b545179fdff1ccfbbb9d422e4e9720cb6c6d9191'
[12:41] <cone-914> ffmpeg.git 03Loren Merritt 07master:c93ccf5a4cca: lpc: use levinson for the first pass of multipass cholesky
[12:41] <cone-914> ffmpeg.git 03Michael Niedermayer 07master:32a39552597a: Merge commit 'c93ccf5a4cca722b39f05e9f5660b4cb75bc1740'
[12:41] <cone-914> ffmpeg.git 03Michael Niedermayer 07master:e27be795f019: avcodec/lpc: Use a function pointer from an initialized context
[13:05] <cone-914> ffmpeg.git 03Luca Barbato 07master:183880cfc4aa: pictor: use the correct logging context
[13:05] <cone-914> ffmpeg.git 03Michael Niedermayer 07master:97947d9bba51: Merge commit '183880cfc4aae53ce504e13337791cad5841c80c'
[13:23] <cone-914> ffmpeg.git 03Luca Barbato 07master:d4a217a408da: wmapro: check the min_samples_per_subframe
[13:23] <cone-914> ffmpeg.git 03Michael Niedermayer 07master:490ed7f0eccf: Merge commit 'd4a217a408da4bd63acc02cd8f9ebe378a2ad65a'
[13:43] <cone-914> ffmpeg.git 03Luca Barbato 07master:02ec656af720: wmapro: error out on impossible scale factor offsets
[13:43] <cone-914> ffmpeg.git 03Michael Niedermayer 07master:c1fc4ff937cd: Merge commit '02ec656af72030eea4f3d63e30b25625cce6a3df'
[13:44] <cone-914> ffmpeg.git 03Derek Buitenhuis 07master:7798a59dc14a: avconv: Don't include colorspace.h
[13:44] <cone-914> ffmpeg.git 03Michael Niedermayer 07master:06549cee4281: Merge commit '7798a59dc14ae27efe64e639a42646002608a908'
[13:57] <cone-914> ffmpeg.git 03Luca Barbato 07master:7520d9779c6d: mjpeg: Move code out of else branch
[13:57] <cone-914> ffmpeg.git 03Michael Niedermayer 07master:e3fb8ac9564b: Merge commit '7520d9779c6d30b385df5a0a42da508238076192'
[14:12] <cone-914> ffmpeg.git 03Luca Barbato 07master:6765ee7b9cba: mjpeg: Check the unescaped size for overflows
[14:12] <cone-914> ffmpeg.git 03Michael Niedermayer 07master:afddf0d9105d: Merge remote-tracking branch 'qatar/master'
[15:30] <superware> michaelni: regarding the udp-ts problem, do you still think this is an ffmpeg issue?
[15:30] <michaelni> superware, i dont uderstand the question ?
[15:31] <michaelni> superware, iam working on it, theres a bug in the mpegts demuxer code
[15:31] <superware> michaelni: "maybe later but i already have an idea what it could be so it wont help much"
[15:32] <superware> oh, great
[15:32] <michaelni> of course i dont know if thats the only issue left :)
[15:34] <superware> michaelni: that's why I'm trying to convince you to try this (challenging yet probably valid) stream out :)
[15:42] <superware> michaelni: after you fix it I hope we'll be able to try it out ;)
[16:10] <durandal_1707> michaelni: why asm doesn't compile with yasm from ubuntu?
[16:10] <michaelni> durandal_1707, why ask me ??
[16:11] <BBB> durandal_1707: probably too old version of yasm
[16:13] <durandal_1707> michaelni: well you just disabled it
[16:15] <michaelni> durandal_1707, yes, code that breaks build should be disabled until someone fixes it
[16:16] <durandal_1707> but what about other cases where it does not break build?
[16:17] <michaelni> durandal_1707, you want to wok on the issue ?
[16:18] <michaelni> iam working on another issue and then have many other issues that we need to fix before the release
[16:18] <michaelni> ... to work on 
[16:19] <michaelni> and this one will be fixed by the people from the fork as they are affected too
[16:19] <michaelni> i am not interrested in doing the work twice
[16:21] <superware> michaelni: are you going to release 1.3?
[16:22] <durandal_1707> but they are certainly interested in redoing it in another sometimes worse way...
[16:28] <cone-914> ffmpeg.git 03Michael Niedermayer 07master:b7c6685268d7: mpegts_read_header: goto fail instead of return directly
[16:28] <cone-914> ffmpeg.git 03Michael Niedermayer 07master:a5f23d8da08e: mpegts: factor seek_back() out
[16:28] <cone-914> ffmpeg.git 03Michael Niedermayer 07master:4e9966049311: mpegts: use seek_back() for all seek backs
[16:34] <nevcairiel> so who broke msvc today? :D
[16:44] <durandal_1707> what test is failing?
[16:51] <nevcairiel> some flac thing
[16:52] <nevcairiel> flac-16-lpc-cholesky
[16:57] <durandal_1707> i will push wavpack encoder soon
[16:57] <durandal_1707> because it looks like new release is not going to happen any time soon
[17:07] <nevcairiel> interesting, apparenly not only msvc broken but all 32-bit x86
[17:08] <nevcairiel> that'll motivate someone to fix it sooner and i don't have to bother debugging in msvc =)
[18:29] <JEEB> btw, anyone here interested in seeing why these certain ogm samples can't seek?
[18:31] <JEEB> (if you try to -ss before -i with https://fushizen.eu/samples/lavf_ogm_seeking_borked.ogm you will basically get ~8 frames decoded and it suddenly stops)
[18:31] <nevcairiel> EFILETOOBIG
[18:32] <JEEB> yes, I have no idea if I could dd
[18:32] <JEEB> don't remember how ogm works
[18:32] <nevcairiel> i can sum it up in one word: badly
[18:32] <JEEB> well yes
[18:32] <JEEB> I don't disagree there in any way
[18:33] <JEEB> but this sample can be seeked with gabest's or haali's splitter
[18:33] <michaelni> superware, patchset that may fix the mpegts-udp thing is on ffmpeg-devel
[18:33] <JEEB> otherwise I wouldn't bring it up at all
[18:33] <JEEB> elenril said something about index entries being too far from each other IIRC
[18:35] <superware> michaelni: what's a patchset/ffmpeg-devel?
[18:36] <cone-914> ffmpeg.git 03Matthieu Bouron 07master:9e6d063dbc47: lavf/movenc: use ffio_fill()
[18:36] <superware> michaelni: let me help you simply test it :)
[18:38] <michaelni> superware, http://en.wikipedia.org/wiki/Patch_%28computing%29
[18:38] <ubitux> superware: http://ffmpeg.org/pipermail/ffmpeg-devel/2013-June/145286.html and the two following
[18:39] <ubitux> michaelni: maybe you could put them in a branch on your github to ease testing?
[18:40] <superware> ubitux: and why not in the git?
[18:42] <ubitux> patches are posted for testing before going upstream
[18:42] <wm4> wow 2013 and still trouble with ogm
[18:42] <JEEB> "There's this thing called code review"
[18:42] <JEEB> wm4, pretty much the last problem I can find with libavformat :P
[18:42] <superware> yes, it's not a small fix
[18:46] <durandal_1707> wm4: ogm/ogg is crap
[18:46] <wm4> doesn't mean it should not work
[18:47] <JEEB> OGM is crap, I don't think anyone disagrees with that. Too bad I can see certain other splitters handling this sample fine so I can't see any reason why it shouldn't be handled fine in theory in libavformat as well :s
[18:48] <JEEB> Otherwise I could have told people that they should stick that file up their you-know-what
[18:51] <cone-914> ffmpeg.git 03Paul B Mahol 07master:7e112df47095: flac_parser: check return value of av_fifo_alloc()
[19:05] <durandal_1707> no more filters :(
[19:06] <cone-914> ffmpeg.git 03Michael Niedermayer 07master:247425241cb3: avutil/x86: disable ff_evaluate_lls_sse2() for 32bit
[19:07] <Daemon404> pengvado, ^
[21:24] <cone-914> ffmpeg.git 03Carl Eugen Hoyos 07master:6258e86d4b1c: Drop local lable from ppc asm timer.
[21:24] <cone-914> ffmpeg.git 03Carl Eugen Hoyos 07master:33f5d70df589: Rename constant HZ in af_biquads.c as HERTZ.
[21:24] <cone-914> ffmpeg.git 03Carl Eugen Hoyos 07master:674d8a962960: Rename thread_init() in libavcodec and libavfilter as library_thread_init().
[21:24] <cone-914> ffmpeg.git 03Carl Eugen Hoyos 07master:742b9617698f: Rename constant FRAMESIZE in ra144 codec as FRAME_SIZE.
[21:24] <cone-914> ffmpeg.git 03Carl Eugen Hoyos 07master:0915b531bc62: Rename "AVClass class" as "AVClass component_class".
[21:24] <cone-914> ffmpeg.git 03Carl Eugen Hoyos 07master:f803e0dc0e75: Support compilation on aix with gcc.
[21:24] <cone-914> ffmpeg.git 03Michael Niedermayer 07master:b00e56bec5f8: Merge remote-tracking branch 'cehoyos/master'
[21:34] <durandal11707> local lable? yo that serious?
[21:36] <durandal11707> cehoyos: is flac oom fixed by 7e112df47095?
[21:44] <cone-914> ffmpeg.git 03Paul B Mahol 07master:84343dd9d3b8: indeo3: check return values of av_malloc()
[21:59] <cehoyos> durandal11707: Sorry, but how did you find the issues with flac and indeo3 ?
[22:00] <durandal11707> what?
[22:04] <cehoyos> You told me that the commits you made are unrelated to two tickets that were opened yesterday, since I want to improve myself, I'd like to learn how you found these issues.
[22:07] <durandal11707> well you told yourself that patch for indeo3 did not fully fixed ticket
[22:07] <durandal11707> and for flac i dunno, i never tried to reproduce bug
[22:08] <durandal11707> i just search for av_malloc/or related call where value is never checked
[22:08] <durandal11707> there is bunch of such cases in code
[22:09] <cehoyos> This is how everybody except me does it, it is called fixing tickets and of course your commits fix both the indeo3 and the flac tickets.
[22:13] <ubitux> JEEB: did you open a ticket?
[22:13] <JEEB> the sample is over 200MB and I don't know if I can just dd it >_> And I didn't want to put the link on the tracker.
[22:14] <cehoyos> What kind of issue?
[22:14] <JEEB> seeking fails with certain kinds of OGM files
[22:15] <JEEB> I would have told the person who brought the sample to me to go off, but Gabest and Haali can handle it :s
[22:15] <JEEB> <JEEB> (if you try to -ss before -i with https://fushizen.eu/samples/lavf_ogm_seeking_borked.ogm you will basically get ~8 frames decoded and it suddenly stops)
[22:16] <Daemon404> and theyre all dropped.
[22:19] <wm4> can't you just upload it to the samples ftp?
[22:19] <superware> michaelni: hi, would you like to check your patches with my mpegts stream?
[22:21] <durandal11707> superware: why can't you do it yourself?
[22:22] <durandal11707> you constantly ask michaelni to fix bug(s) for you and than also ask to check if its really fixed
[22:30] <superware> durandal11707: I don't think I can do it myself. I think Michael can speak for himself, if you're so interested he said "maybe later" for testing. I really don't think he's fixing things "for me", but rather for the project/community. His help is much appreciated, and if you're here then I guess yours also.
[22:30] <Compn> durandal11707 : cehoyos is asking how to find code without checks on it
[22:30] <Compn> durandal11707 : do you have a script or tool that shows what to look for ?
[22:31] <durandal11707> grep av_malloc/actually any non void function that returns something and may fail
[22:31] <superware> durandal11707: technically, my stream had several issues with ffmpeg, and since it seems to be difficult to reproduce, testing the source stream seems like the fastest path forward.
[22:32] <durandal11707> superware: than you open bug report and upload sample with wich one can reproduce issue or provide link or way how to reproduce bug
[22:32] <Compn> cehoyos : "grep av_malloc/actually any non void function that returns something and may fail"
[22:33] <superware> "difficult to reproduce" seems clear to me, the issues aren't with the data, but rather with udp/ip.
[22:33] <durandal11707> Compn: and code that use such functions never checks return value ...
[22:34] <superware> durandal11707: a raw dump of the streams plays just fine, for example.
[22:35] <durandal11707> yes, but ffmpeg have udp protocol r/w
[22:38] <superware> durandal11707: ?
[22:39] <Compn> superdump : ffmpeg can output udp stream too
[22:39] <Compn> r/w = read / write
[22:40] <superware> so?
[22:40] <superware> I meant: and the point?
[22:42] <Daemon404> so
[22:42] <Daemon404> without context
[22:42] <Daemon404> what are you tryin to do, superware 
[22:42] <Daemon404> (ill try to be less useless than Compn)
[22:42] <durandal11707> superware: i was trying to redirect you to providing way how to reproduce bug with ffmpeg itself
[22:43] <Compn> Daemon404 : i just translate english to more english around here :P
[22:43] <superware> I have a "problematic" stream that seems to raise a few issues with ffmpeg, michaelni found some of the buggy sections and fixed them.
[22:44] <superware> durandal11707: reproduce without an externally sourced stream?
[22:45] <Daemon404> anyway, side note for anyone: after giving up on many of ffmpeg's streaming facilities, i found havng ffmpeg handle udp and using wowza to multiplex worked very well
[22:45] <superware> the source origin is hardware
[22:45] Action: Daemon404 wanders off
[22:48] <superware> anyway, thank you all for helping out, great project.
[22:50] <durandal11707> superdump: i wonder how michaelni can fix your issue without even exact step how to reproduce it
[22:50] <Daemon404> wrong nick
[22:50] <durandal11707> fuck
[22:50] <Daemon404> superware left
[22:55] <durandal11707> cehoyos: why you don't create normal patches with "git format-patch" that have actuall commit log message?
[23:39] <wm4> durandal11707: any plans to enable audio decoding threads by default?
[23:44] <wm4> I like how these AVERROR "fourccs" make it really hard to look up an error
[23:45] <ubitux> how so?
[23:46] <ubitux> also, it's done to be abi compatible
[23:47] <ubitux> %.4s should help you btw
[23:50] <wm4> no, that doesn't help, because there are sometimes plain numbers in there anyway
[23:51] <wm4> so better suggest av_err2str()
[23:52] <wm4> still... why can't it just use numbers?
[23:52] <Daemon404> i just converted them all to numbers
[23:52] <Daemon404> and kept them in a text file
[23:52] <Daemon404> as a LUT
[23:52] <wm4> heh
[23:52] <Daemon404> -_-
[23:52] <Daemon404> whats mroe confusng
[23:52] <wm4> and by numbers I mean small numbers, starting from 1 (or -1)
[23:53] <Daemon404> i that SOMETIMES thyre fuurccs
[23:53] <Daemon404> other times theyre from errno
[23:53] <Daemon404> but negative
[23:53] <Daemon404> e.g. AVERROR(ENMEM)
[23:53] <Daemon404> er ENOMEM
[23:53] <wm4> ugh
[23:53] <wm4> I saw strerror_r in error.c, but using them intentionally is a bit worse
[23:53] <wm4> as opposed to trying to propagate libc error numbers
[23:54] <wm4> well, still better than "return -1;" I guess
[23:54] <Daemon404> a lot of times, the "useful" retrn codes are no better than -1
[23:54] <Daemon404> becase every error in a file will be INVALIDATA
[23:54] <Daemon404> or w/e
[23:54] <ubitux> wm4: i suggested mostly for debugging, indeed av_err2str() is more appropriate
[00:00] --- Mon Jul  1 2013