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

[burek]

[00:19] <llogan> michaelni: disabled by default
[00:21] <llogan> i see cehoyos wants auto. i don't really care that much.
[00:21] <llogan> i just prefer to manually enable most stuff
[00:25] <michaelni> well iam not smarter now if one says yes and one no :)
[00:25] <michaelni> ill leave it to you and carl to flame it out 
[00:26] <llogan> i have other things to do. you can auto it.
[00:45] <BBB> 
ubitux it's ok to factor things after commit :)
[00:45] <BBB> ubitux: but whichever way you prefer
[00:57] <llogan> michaelni: tickets 3096, 3097, and 3098 are spam
[00:58] <llogan> i already trained the bayes
[01:03] <michaelni> llogan, removed
[01:05] <llogan> michaelni: thanks
[02:15] <cone-562> ffmpeg.git 03Michael Niedermayer 07master:e1848aa469b7: avcodec/mpeg12dec: forward errors when EXPLODE is set
[07:34] <Zeranoe1> Is there a reason lto isn't enabled by default? Is it unstable?
[09:40] <ubitux> saste: nicolas was fine to remove his name from the copyright holders in the decoding example i submitted; i added mine just because there were some; do you mind if i don't add yours? (i find a bit silly to provide copyrighted api examples)
[09:40] <michaelni> has someone run benchmarks on lto ? compile time / runtime ?
[09:42] <durandal_1707> lto?
[09:42] <cone-863> ffmpeg.git 03Anton Khirnov 07master:5c0a09839c70: libopenjpegdec: return meaningful error codes
[09:42] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:4427fe7e4bf6: Merge commit '5c0a09839c707f10e5dba59460e219e989c1da93'
[09:43] <ubitux> durandal_1707: link time optim
[09:47] <saste> ubitux, fine to remove my name
[09:48] <ubitux> saste: ok, thanks
[09:48] <ubitux> i'm going to add audio decoding
[09:48] <ubitux> anyone has a sample that requires multiple decode for a single packet?
[09:48] <saste> ubitux, fine with me, but keep in mind that the more examples we have, the more effort we need to spend on them
[09:49] <ubitux> saste: maybe we can drop some
[09:49] <ubitux> when this one is in
[09:49] <ubitux> saste: also, this example is useful: it is easy to use, easy to valgrind-test, and allows to check both API modes
[09:50] <durandal_1707> remove mp2 example it is useless
[09:51] <ubitux> decoding_encoding?
[09:51] <saste> what happened of the example posted in libav-devel?
[09:52] <ubitux> they never push it
[09:52] <durandal_1707> K&R
[09:52] <ubitux> should we steal it?
[09:52] <durandal_1707> if you are lazy
[09:52] <saste> probably if it's useful
[09:53] <saste> but same considerations as before
[09:53] <saste> i can hardly do any relevant thing these days
[09:53] <saste> this happens when you have a lot of code to maintain
[09:56] <wm4> lol at that opencl discussion
[09:57] <nevcairiel> why is that public API anyway
[09:57] <nevcairiel> anyhow, i support the concept of certain parts of the API just not being stable yet, and not falling under API/ABI requirements
[09:58] <beastd> We need a API/ABI incubator?
[09:59] <saste> nevcairiel, note that the opencl API was always marked as experimental
[09:59] <saste> if an user relied on that and we broke it, she can't complain
[10:00] <nevcairiel> if that means its not required to be API compatible, thats fine
[10:00] <saste> that or we wouldn't never had that API in the first place
[10:02] <wm4> what I found funny is that the ffmpeg code was considered an (unmaintained) external snapshot by the devs, which they want to update now
[10:05] <durandal_1707> what devs?
[10:11] <av500> all devs
[10:13] <durandal_1707> what all devs?
[10:15] <durandal_1707> #include "h264data.h" // FIXME FIXME FIXME
[10:24] <cone-863> ffmpeg.git 03Anton Khirnov 07master:b9589f5a770e: lavc: add error checking to apply_param_change.
[10:24] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:558784f113f1: Merge commit 'b9589f5a770ec2357ab7920a5fabe8510b8601f9'
[10:32] <wm4> durandal_1707: multicoreware
[10:33] <cone-863> ffmpeg.git 03Anton Khirnov 07master:d4c12b8be4bd: oggparsetheora: K&R cosmetics, reformat
[10:33] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:70737b83f06e: Merge commit 'd4c12b8be4bdd2ffddb3bd5e11773de4c4c46f68'
[10:41] <cone-863> ffmpeg.git 03Anton Khirnov 07master:5e5fb21877d8: oggparsetheora: return meaningful error codes
[10:41] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:0b9e480b8f3b: Merge commit '5e5fb21877d8da7b3b8a27bb4d6a070d210c152d'
[10:53] <cone-863> ffmpeg.git 03Anton Khirnov 07master:4f2d8968c04e: oggparsetheora: check av_mallocz result
[10:53] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:7fd7a10efde7: Merge remote-tracking branch 'qatar/master'
[11:01] Action: ubitux realizes he still doesn't understand shit about how to decode properly audio with FFmpeg API
[11:02] <nevcairiel> its not too different to video, except that you have to implement the partial buffer decoding thing properly, because its used for many formats
[11:14] <ubitux> nevcairiel: it's a bit tricky to do properly
[11:14] <ubitux> there is also that cap delay thing btw
[11:26] <wm4> further lol at opencl discussion
[11:27] <wm4> now improvement is stifled, even though most likely nobody uses the opencl headers
[11:28] <nevcairiel> these arguments about mixing library versions are always fun, while in reality its most likely going to blow up anyway
[11:29] <nevcairiel> if i add new stuff to a library and use that in another library, it would blow up if the user only updates one of them
[11:29] <nevcairiel> well, the wrong one of them :p
[11:30] <wm4> indeed, it would be nice if libav* would stop pretending to be independent of each other
[11:51] <ubitux> we could have in each library a #define AVFORMAT_LAST_COMPATIBLE_AVCODEC_VERSION, AVFORMAT_LAST_COMPATIBLE_AVUTIL_VERSION, etc
[11:52] <ubitux> or simply a hard check 
[11:52] <ubitux> in each of them
[11:53] <wm4> how about a single, unified version number
[11:53] <wm4> say, FFMPEG_VERSION
[11:53] <wm4> hm needs AV prefix
[11:53] <wm4> AV_FFMPEG_VERSION
[11:54] <wm4> it would be incremented every time a version of a sub-library is changed
[11:54] <av500> LIBAV_FFMPEG_VERSION
[11:55] <wm4> and you could distinguish ffmpeg vs. libav by checking whether AV_FFMPEG_VERSION or AV_LIBAV_VERSION exists
[11:55] <wm4> if a 3rd fork shows up, just get your guns
[11:57] <Daemon405> [10:53] <+wm4> how about a single, unified version number
[11:57] <Daemon405> i have been arguing for this for years
[11:57] <Daemon405> neither side wants t
[11:57] <Daemon405> it
[11:57] <Daemon405> despite the fact that the libraries are essentially useless
[11:57] <av500> a single version number for 2 different pieces of code?
[11:57] <Daemon405> unless theyre from the same version
[11:57] <wm4> because it would be the obvious, good thing to do?
[11:57] <av500> lets call both 54 
[11:57] <av500> ah you mean per project :)
[11:57] <Daemon405> av500, no i mean the inter-library deps make independent library versioning retarded
[11:57] <Daemon405> and useless
[11:58] <av500> that yes
[11:58] <Daemon405> its a major headache for downstream (me)
[11:58] <wm4> you have 28 version number to care about
[11:58] <av500> all these versions are useless
[11:58] <Daemon405> it would be much nicer with a single unified version
[11:58] <wm4> 14 for each fork
[11:58] <Daemon405> for all of ffmpeg
[11:58] <av500> true
[11:58] <wm4> 7 compile versions, and 7 link versions
[11:58] <Daemon405> literally every downstream says this
[11:58] <Daemon405> every single one.
[11:58] <nevcairiel> i don't
[11:58] <nevcairiel> :D
[11:58] <wm4> 7 because lavc, lavf, sws, swr, lavd, postproc are separate
[11:58] <av500> if the linux kernel can be one version, so can libav/ffmpeg
[11:58] <wm4> and lavu
[11:59] <Daemon405> and lavr
[11:59] <ubitux> i'd be fine with libffmpeg
[11:59] <Daemon405> in practice the versions are useless
[11:59] <Daemon405> since everything depends on everything
[11:59] <Daemon405> and it clutters my coke with a billion huge version checks
[11:59] <wm4> the versions also make it hard to write code that works everywhere
[11:59] <Daemon405> yes
[11:59] <nevcairiel> one could argue that if you only use avutil (for whatever silly reason you would!), you dont need to update as often :p
[12:00] <Daemon405> 0 people do that
[12:00] <wm4> what about mplayer compiled without lavc/lavf?
[12:00] <wm4> (it supports that)
[12:00] <nevcairiel> wait, arguments need to map to reality now?
[12:00] <Daemon405> lol
[12:00] <Daemon405> wm4, mplayer is not downstream
[12:00] <Daemon405> it's same-stream
[12:00] <nevcairiel> lol
[12:00] <wm4> I was just providing the only existing and also absurd use case that exists for this
[12:01] <ubitux> isn't vlc only using lavc or something?
[12:01] <nevcairiel> at some point i did consider using avutil in a small project that didnt need lavf or lavc otherwise
[12:01] <wm4> ubitux: pretty sure vlc supports all aspects of ffmpeg
[12:01] <nevcairiel> but i gave up and just stole two functions that i wanted
[12:01] <durandal_1707> wm4: aspects?
[12:01] <Daemon405> i dont really understand the 'usefulness' of separate lib versions for everything
[12:01] <wm4> durandal_1707: decoding, demuxing, etc
[12:01] <Daemon405> in practice its pretty useless for lav*
[12:02] <durandal_1707> i do not agree
[12:02] <Daemon405> yes its been well established
[12:02] <wm4> even if someone wants to use only part of it, they can configure it so at compile time
[12:02] <Daemon405> the ffmpeg and lbav devs thing its Oh So Useful
[12:02] <Daemon405> while literally every downstream hates it
[12:02] <wm4> just like to can strip down lavc to contain only a h264 decoder etc.
[12:02] <wm4> s/to/you
[12:03] <durandal_1707> there was libavcore
[12:03] <Daemon405> im not saying separate libs are bad
[12:03] <av500> durandal_1707: bring libavcore back
[12:04] <ubitux> can someone with a debian system (or whatever other distro splitting packages) check what packages are depending on what libraries?
[12:04] <ubitux> so we can have an overview of that "every downstream"
[12:05] <ubitux> siretart: could you do that?
[12:05] <wm4> ask them whether they ever mismatch library versions
[12:05] <wm4> well, mismatch or mix
[12:06] <wm4> (using different sub-libs at compile or runtime)
[12:06] <Daemon404> nobody does
[12:06] <ubitux> the interesting part is to know if some project relies on libavcodec only and don't need libavformat for example
[12:06] <Daemon404> people aways use it fro teh same release / clone
[12:07] <wm4> ubitux: again, these can disable the unused parts at compile time
[12:07] <wm4> or they use a shared system lib, in which case it doesn't matter
[12:07] <Daemon666> iirc some only use libswscale
[12:07] <ubitux> wm4: think packaging
[12:07] <Daemon404> ubitux, in practice using lavc is not so fun
[12:07] <Daemon404> the projects than *can* like vlc and ffms2
[12:07] <wm4> packaging, and?
[12:07] <av500> I used lavc only in the past
[12:07] <Daemon404> have to copy/paste the codec id mappings
[12:07] <ubitux> wm4: think about a system where you don't have the libav* libraries, and you want to install a software which only depends on libavcodec for instance
[12:07] <av500> worked for me
[12:07] <av500> I just needed codecs
[12:08] <av500> you cannot use only lavf though
[12:08] <ubitux> wm4: in that situation, you wouldn't want to grab all the libraries
[12:08] <av500> it pulls in lavc or is useless
[12:08] <Daemon666> av500: what you used to demux?
[12:08] <ubitux> but just libavcodec, and the app 
[12:08] <av500> Daemon666: my own sauce
[12:08] <wm4> ubitux: even then you don't need separate lib versions
[12:08] <Daemon404> ^
[12:08] <wbs> Daemon404: I'm so fucking tired of hearing you cry about the codec mappings. if you use an external non-lavf demuxer to demux, your demuxer should tell you that this one fourcc actually is h264 or whatever that is, using that demuxer's api. then you map that one demuxer definition of h264 to the lavc one
[12:08] <av500> Daemon404: partly still do
[12:08] <ubitux> wm4: sure
[12:08] <wbs> Daemon404: seriously stoU it
[12:09] <wm4> (in the unlikely caseyou want to reduce binary size by splitting ffmpeg intpo sub-.libs)
[12:09] <ubitux> wm4: that is another point, i was wondering about a single lib
[12:09] <av500> wbs: thats what I did
[12:09] <Daemon404> wbs, i didnt say it was wrong
[12:09] <Daemon404> i said its no fun
[12:09] <av500> of course I mapped my H264 to CODEC_ID_H264
[12:09] <Daemon404> so calm down
[12:09] <wbs> Daemon404: yes. stop nagging about it
[12:09] <av500> etc..
[12:09] <Daemon404> im not nagging for anything
[12:09] <Daemon404> i have requested no hange to accomodate it
[12:09] <wbs> Daemon404: if you use an external demuxer, the external demuxer should take care about it. if not, why are you using a crappy external demuxer for it?
[12:10] <Daemon404> i am *agreeing* with you
[12:10] <Daemon404> jeez
[12:10] <Daemon404> not fun != not correct
[12:10] <wm4> (there are plently of better demuxers outside of lavf)
[12:10] <wbs> wm4: I don't disagree with that
[12:10] Action: av500 hugs his asf parser
[12:11] <wbs> wm4: but "my external demuxer only says that this is RIFF <foo> and I need the lavf table mapping to tell me what lavc codec this corresponds to" gets tiresome
[12:11] <Daemon404> wbs, so calm down... im saying youre right.
[12:11] <wbs> Daemon404: yes. so stop bringing this topic up then
[12:11] <Daemon404> when asking why people dont use lavc with ~lavf
[12:11] <wm4> doesn't lavf export some fourcc tables anyway?
[12:11] <Daemon666> wm4: what better demuxers than lavf have?
[12:11] <Daemon404> er !lavf
[12:11] <Daemon404> it is a legitimate response
[12:11] <nevcairiel> you cna even get the RIFF tables from lavf these days
[12:11] <Daemon404> peopel simply cant be arsed to
[12:11] <wm4> Daemon404: e.g. many vlc demuxers
[12:11] <wbs> wm4: yes, for riff stuff. for generic other containers, no
[12:12] <wm4> even mplayer's sometimes perform better than lavf
[12:12] <Daemon404> wm4, player's asf demuxer is much nicer
[12:12] <Daemon404> mplayer*
[12:12] <Daemon404> even tho its horrible too
[12:12] <Daemon666> is just bugs nobody want to fix
[12:12] <Daemon404> asf demuxer isnt bugs
[12:12] <Daemon404> it needs a ground up rewrite
[12:12] <Daemon404> from spec
[12:13] <Daemon404> but nobody wants to
[12:13] <Daemon404> =p
[12:13] <wbs> Daemon404: and for the original topic, debian packages the libav* libraries in separate packages, so you can easily upgrade libavutil without upgrading every single one of the other ones
[12:13] <wbs> whether you think that's good or not, that's up to you
[12:13] <Daemon404> separate libs and packages are not necessarily separate versions
[12:13] <Daemon666> Daemon404: iirc that spec is fake
[12:13] <Daemon404> i have a copy of the one MS sends to its partners
[12:13] <Daemon404> i doubt it's fake
[12:13] <Daemon404> merely wrong
[12:13] <wm4> an evil twin appeared
[12:14] <wm4> I didn't notice at first
[12:14] <wbs> no, but they don't force you to upgrade them in sync either, and you can have separate versions installed in parallel to work with binaries that use the old ABI
[12:14] <Daemon404> wbs, thats more or less a fringe feature in my eyes. i so very arrely see it used
[12:15] <Daemon404> even debian's use case doesnt make use of it really
[12:15] <wbs> well if you don't see and understand it, that's your loss
[12:15] <Daemon404> i certainly feel it though
[12:15] Action: Daemon404 stares at his soup of version checks
[12:16] <wm4> why don't we split every lavc decoder into its own so, and version it separately?
[12:16] <wm4> even more fun for distros
[12:16] <Daemon404> (supporting >1 version of libav/ffmpeg)
[12:16] <Daemon666> wm4: make each demuxer/muxer/decoder/encoder/filter separate project?
[12:16] <wm4> just separate libraries
[12:16] <Daemon404> nice strawman
[12:18] <Daemon404> i suppose this is kind of an atifically created issue
[12:18] <Daemon404> due to the massive api churn
[12:18] <Daemon666> wm4: it would be nightmare, only thing i want is separate build of libs, so adding new demuxer does not need to recompile all shit
[12:18] <Daemon404> i dream of a day when libav* stops changing api for a while
[12:18] <Daemon404> :D
[12:18] Action: Daemon404 runs
[12:18] <wm4> but then the API will stay horrible
[12:19] <nevcairiel> you have not used truely horrible api then
[12:19] <Daemon404> isnt that *why* it's changing
[12:19] <wm4> yes
[12:19] <Daemon404> one assumes it will be replaced by non horrbiel things
[12:19] <Daemon404> and then top changing so often
[12:19] Action: Daemon666 wonders what needs changing (besize libswscale)
[12:19] <Daemon404> but thats just my dream.
[12:20] <BBB> why do we have 2 daemons?
[12:20] <BBB> that's awful for tab completion
[12:20] <Daemon404> and id take a slightly bad and stable api over a constantly changing one any day
[12:20] <Daemon404> BBB, one is paul
[12:20] <BBB> aha
[12:20] <nevcairiel> but we wont tell you which
[12:21] <Daemon404> there's an entire cottage industry around libav*
[12:21] <Daemon404> that is "using the cli" or "using the api"
[12:21] <Daemon404> since it's so 'lovely'
[12:21] <Daemon404> :D
[12:41] <cone-863> ffmpeg.git 03Paul B Mahol 07master:62ef736f5a01: avcodec/motionpixels: use av_fast_padded_malloc()
[12:41] <cone-863> ffmpeg.git 03Paul B Mahol 07master:c783bec6dc57: avcodec/mdec: use av_fast_padded_malloc()
[12:41] <cone-863> ffmpeg.git 03Paul B Mahol 07master:2820562935e7: avcodec/4xm: use av_fast_padded_malloc()
[12:41] <cone-863> ffmpeg.git 03Paul B Mahol 07master:1de8dfcbc494: avcodec/binkaudio: use init_get_bits8()
[12:41] <cone-863> ffmpeg.git 03Paul B Mahol 07master:2508fa10c618: avcodec/xan: use init_get_bits8()
[12:41] <cone-863> ffmpeg.git 03Paul B Mahol 07master:49c6f0ae15a0: avcodec/apedec: use init_get_bits8()
[12:42] <cone-863> ffmpeg.git 03Paul B Mahol 07master:82e576046c6b: avcodec/wavpack: use init_get_bits8()
[12:42] <cone-863> ffmpeg.git 03Paul B Mahol 07master:8e609eb475fe: avcodec/utvideoenc: use av_fast_padded_malloc()
[12:42] <cone-863> ffmpeg.git 03Paul B Mahol 07master:268d0d6e6c89: avcodec/svq3: use av_fast_padded_malloc()
[12:42] <Daemon666> its not fun any more
[12:42] <Daemon999> tracking library interdependencies is hard => must be done by hand
[12:42] <saste> we have micro to accomplish that, but hardly anyone remembers to update it properly
[12:42] <saste> and nobody is tracking the interdependencies
[12:43] <saste> that said, a unique progressive id can be created
[12:43] <saste> but i don't know what would be the proper place where to put it
[12:44] <saste> Daemon404, indeed i don't know which is the proper fdk-aac repository
[12:44] <Daemon404> the one i linked
[12:45] <saste> allright i'll trust you
[12:45] <Daemon404> the one you have currently is wbs's personal repo
[12:50] <Daemon666> huh, did not update png lib and now i lost all icons
[12:50] <Daemon666> that is called stable api
[12:52] <saste> ubitux, "private" in ffmpeg has a special meaning
[12:53] <saste> it means "non-shared"
[12:53] <ubitux> i'd use "specific" but ok
[12:57] <saste> ubitux: http://ffmpeg.org/ffmpeg-codecs.html#toc-Codec-Options
[12:58] <ubitux> ok ok
[13:14] <beastd> yeah, the "private" options lingo sucks IMHO
[13:14] <ubitux> saste: the decoding example i'm writing can probably replace the "demuxing" example
[13:36] <ubitux> saste: "Also, some decoders might over-read the packet."
[13:36] <ubitux> seriously? :)
[13:36] <ubitux> (doc/examples/demuxing.c)
[13:37] <nevcairiel> isnt that in there to explain why the padding is mandatory
[13:38] <Daemon666> yes, decoders are free to overread, you must have 0(what about FFFF?) padded packet
[13:38] <Daemon666> michaelni: why is my get_bits patch ignored?
[13:38] <ubitux> oh, mmh ok
[13:39] <saste> ubitux: 06b269dac
[13:39] <ubitux> yeah i see that's nice
[13:39] <ubitux> btw, we should follow that logic in src_movie
[13:39] <Daemon666> nooooooooo, that hack should be finally fixed with new api
[13:48] <michaelni> durandal666, which get_bits patch ?
[13:50] <michaelni> there where several and most i applied broke fate
[13:50] <michaelni> applied locally that is
[13:51] <Daemon666> last one
[13:53] <michaelni> breaks fate 
[13:54] <michaelni> also i do not understand what these patches are supposed to fix
[13:54] <michaelni> make: *** [fate-vsynth1-dv-411] Error 1
[13:54] <Daemon666> michaelni: what fate test?
[13:55] <michaelni> make: *** [fate-vsynth1-dv] Error 1
[13:55] <michaelni> not sure if these are the only ones as i didnt use make -k
[13:55] <Daemon666> well all those codecs are broken as they call init_get_bits with 0 as size
[13:57] <michaelni> your patch makes size=0 an error
[13:58] <Daemon666> last one does not
[13:58] <cone-863> ffmpeg.git 03Paul B Mahol 07master:387e76f9934c: avcodec/mdec: use dsp.bswap16_buf()
[14:02] <michaelni> your patch corrupts bit_size when its 0
[14:05] <michaelni> also it no longer sets buffer to NULL when bitsize is negative
[14:05] <michaelni> and i still dont know what this patch is trying to do
[14:06] <michaelni> but iam spending hours debuging it for you
[14:06] <Daemon666> because you still fail to find that get_bits1 crash when you set buffer to null
[14:06] <Daemon666> and that happens when you do not check return code of init_get_bits
[14:07] <michaelni> so why do you ignore my repeated questions about what this fixes ?
[14:07] <Daemon666> on other case for 0 size it may loop forever if you do while(get_bits())
[14:08] <michaelni> while(get_bits) is not a good idea, its not robust
[14:08] <michaelni> it will loop or crash when the padding isnt there or not zeroed
[14:08] <Daemon666> yes, but do not blame me...
[14:09] <Daemon666> anyway all init_get_bits that can have very big size for buffer should be updated to check for return code
[14:11] <Daemon666> actually i fixed such nonsense in tta
[14:29] <cone-863> ffmpeg.git 03Paul B Mahol 07master:65988b991659: avcodec/cook: fix deadlock by using get_unary()
[14:29] <ubitux> saste: infinite loop at the end of demuxing
[14:29] <ubitux> (demuxing.c)
[14:30] <ubitux> these examples are all nicely broken in their own way
[14:35] <saste> yes so the user will exercise his debugging skills
[14:35] <saste> we get very few reports anyway, so i wonder if someone is actually using them
[14:35] <saste> i tend to work on them just when the need arise, e.g. when i use or update the API
[14:38] <cone-863> ffmpeg.git 03Clément BSsch 07master:0c6bb53bb28c: doc/examples/demuxing: reset got_frame.
[14:40] Action: Daemon666 got trac internal error
[14:41] <Daemon666> DatabaseError: database disk image is malformed
[14:43] <Daemon666> who should i punish?
[14:48] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:9f5b75f2416c: avcodec/flacdec: make while get_bits loop more robust by checking bits left
[14:48] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:b0f8b5c8190a: avcodec/flvdec: make while get_bits loop more robust by checking bits left
[14:48] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:719dbe86ea0e: avcodec/h261dec: make while get_bits loop more robust by checking bits left
[14:48] <Daemon666> ubitux: titles of commit message do not need dot (.) at end
[14:48] <ubitux> it shows if the message is truncated or not
[14:49] <ubitux> Daemon666: wanna fight a nitpick battle with me?
[14:49] <Daemon666> ubitux: you will lose
[14:50] <Daemon666> michaelni: i do not like 9f5b75f2416c
[14:53] <Daemon666> it this only me, or trac behaves strangely lattely
[14:54] <Daemon666> it is gone
[14:55] <michaelni> its the same issue probably that is reoccuring since a few months
[14:55] <michaelni> once every few weeks or so
[14:57] <Daemon666> who is maintainer and have any access to that machine?
[14:57] <beastd> Daemon666: i am on it
[14:59] <Daemon666> is hardware issue or something else?
[15:00] <beastd> Daemon666: seems to be a software issue. but i was not able to track it down yet.
[15:11] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:4b12930f79ed: avcodec/flacdec: use get_unary() simplify code
[15:11] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:489c575bd6f8: avcodec/ivi_common: make while get_bits loop more robust by checking bits left
[15:11] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:810f9c5eaac2: avcodec/ituh263dec: make while get_bits loop more robust by checking bits left
[15:11] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:94a80e36d307: avcodec/intelh263dec: make while get_bits loop more robust by checking bits left
[15:16] <beastd> Daemon666: Trac should be working again.
[16:54] <Daemon666> how much is get_bits1 fast/slow compared to get_bits(,1)?
[16:59] <kierank> Daemon666: not a confusing nick at all
[17:18] <saste> can MOV fragmentation help with playback delay?
[17:18] <saste> the idea is to reduce the size of the initial MOOV atom
[17:19] <saste> with a big file it can be on the order of several MiB
[17:19] <av500> on a slow connection?
[17:19] <av500> yes, MOV is brilliant like that
[17:20] <saste> but then I don't know how many players will be able to decode segmented MOV
[17:22] <av500> mine wont :)
[17:22] <saste> or it is just hopeless to have low delay playback with streamed MP4 content?
[17:23] <av500> its not really streamed
[17:23] <av500> its a download
[17:23] <saste> but players will start to buffer just after the header has been downloaded
[17:24] <saste> so the initial header size will add to the startup time
[17:25] <av500> yes
[17:25] <av500> of course the time to download the MOOV atom will delay plabayk start
[17:26] <saste> any cure to that (fragmentation)?
[17:26] <saste> or is it just "use a different technology"?
[17:26] <av500> didnt know fragmented MOOV exists
[17:26] <av500> it would be a way
[17:27] <ubitux> saste: any comment on the rename?
[17:27] <saste> ubitux, i'll comment on that tonight, i have to leave now
[17:27] <ubitux> ok
[17:27] <av500> saste: or do you mean DASH streaming?
[17:27] <av500> with "fragmented"
[17:27] <saste> but when i implemented that i was indeed thinking about a demuxing example
[17:28] <saste> av500, possible
[17:29] <av500> well, in DASH, fragments are only a few seconds long
[17:29] <av500> so startup is fast
[17:29] <av500> but its DASH, not just http://foo/bar.mp4
[17:29] <saste> how does it look like?
[17:29] <av500> two different things
[17:29] <saste> is that supported by ffmpeg?
[17:29] <av500> an XML file
[17:30] <av500> describing the pieces
[17:30] <av500> yes
[17:30] <saste> and what's more important, is that supported by most players?
[17:32] <av500> plain MOV
[17:33] <av500> DASH is not a file format
[17:33] <av500> its a streaming protocol
[17:34] <saste> well i'll have to do some research
[17:34] <saste> bye
[17:37] <ubitux> http://pastie.org/8443149
[17:37] <ubitux> any idea what this leak is about?
[17:41] <durandal_1707> lazy incompetent programmer?
[17:43] <nevcairiel> ubitux: sounds like the lockmgrs mutex was not freeed properly
[17:57] <cone-863> ffmpeg.git 03Martin Storsjö 07master:0c5f839693da: lavf: Remove a now useless parameter to ffurl_register_protocol
[17:57] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:7f019129e1bd: Merge remote-tracking branch 'qatar/master'
[18:31] Action: durandal_1707 just got someone that use -sameq
[18:35] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:44e8e82d347f: avcodec/get_bits: add skip_1stop_8data_bits
[18:35] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:34087b05642a: avcodec/dxva2_mpeg2: Use skip_1stop_8data_bits()
[18:36] <durandal_1707> heh
[18:36] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:9c284a8e1935: avcodec/flvdec: Use skip_1stop_8data_bits()
[18:36] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:711e981276d0: avcodec/h261dec: Use skip_1stop_8data_bits()
[18:36] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:ddc6ed91873e: avcodec/intelh263dec: Use skip_1stop_8data_bits()
[18:36] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:f4d312719747: avcodec/ituh263dec: Use skip_1stop_8data_bits()
[18:36] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:c882b62d14f6: avcodec/svq1dec: Use skip_1stop_8data_bits()
[18:36] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:9c7662aeba99: avcodec/svq3: Use skip_1stop_8data_bits()
[18:36] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:f03153181640: avcodec/vaapi_mpeg2: Use skip_1stop_8data_bits()
[18:44] <Daemon404> that is some....
[18:45] <Daemon404> "interesting" function naming
[18:45] <Daemon404> generated via markov chain?
[18:48] Action: kierank finally gets round to testing durandal_1707's smpte bars
[18:48] <kierank> might even move to ffmpeg
[18:56] <ubitux> from what?
[18:57] <Daemon404> thats a silly question
[18:59] <durandal_1707> ubitux: it is joke
[18:59] <ubitux> :(
[19:01] <Daemon404> it wasnt
[19:01] <kierank> durandal_1707: i'm not joking
[19:02] <kierank> depends how diverged swscale is to be honest
[19:02] <ubitux> what divergence are you afraid of?
[19:02] <kierank> I have a lot of changes to swscale
[19:02] <ubitux> ah
[19:02] <ubitux> ok :)
[19:03] <kierank> they are a pretty big speed improvement for me but they don't work with all the yuv combinations
[19:03] <ubitux> and you didn't submit patches :(
[19:03] <kierank> because they break fate
[19:03] <Daemon404> becase he threw out  bunch of stuff
[19:03] <durandal_1707> he meant avscale
[19:04] <kierank> yes I threw out stuff for speed as well
[19:04] <kierank> durandal_1707: i am not a libav die hard you know
[19:09] <kierank> though I am trying to figure out how to use testsrc with yuv422p
[19:10] <ubitux> ./ffmpeg -f lavfi -i testsrc,format=yuv422p -f null -
[19:10] <ubitux> ?
[19:12] <durandal_1707> i can change default from yuv420p to yuv422p
[19:13] <kierank> ubitux: thanks
[19:13] <kierank> i was trying -pix_fmt yuv422p
[19:13] <durandal_1707> though testsrc only supports rgb
[19:14] <ubitux> [auto-inserted scaler 0 @ 0x1cc3360] w:320 h:240 fmt:rgb24 sar:1/1 -> w:320 h:240 fmt:yuv422p sar:1/1 flags:0x2
[19:14] <ubitux> indeed
[19:14] <kierank> i meant smptehdbars of course
[19:14] <kierank> not testsrc
[19:14] <ubitux> in that case it works :)
[19:17] <kierank> i assume using vf_text requires a conversion to rgb
[19:18] <kierank> drawtext of course
[19:20] <ubitux> it's using drawutils, which is supposed to support yuv-like fmt
[19:20] <ubitux> (see ff_draw_init)
[19:27] <ubitux> ./ffmpeg -v verbose -f lavfi -i smptehdbars,format=yuv422p,drawtext=text=kierank -f null -
[19:27] <ubitux> i don't see any auto inserted filter
[19:45] <vitruvian> I need a little help... I'm trying to write in a raw socket within a protocol I made, just to test I did a small program to send a raw ethernet frame. But when I try to agregate that to ffmpeg sendto returns -1... failing
[19:52] <durandal_1707> vitruvian: sendto is libc here
[19:57] <kierank> ubitux: yeah seems to work
[19:58] <durandal_1707> just needs aevalsrc 
[20:01] <vitruvian> can't I use sendto inside ffmpeg durandal_1707 ?!
[20:02] <vitruvian> I mean... udp uses sendto, so I guess I can
[20:13] <vitruvian> I have exactly the same structure at ffmpeg and other c implementation for raw socket... someone have a hint on why in ffmpeg sendto returns -1?!
[20:19] <ubitux> BBB, wm4: i added a longer version of the sample from last time if you want; http://lucy.pkh.me/samples/vp9/etv5000.webm
[20:20] <wm4> I'll downloading that
[20:34] <wm4> ubitux: weird choice of source video, because it has all these black flashes
[20:35] <ubitux> yeah but i like it because there are a lot of ± fast motions, and color fucks
[20:35] <ubitux> wm4: the black flashes are the eyes blinking yes, and i think that's a pretty good use case actually
[20:36] <ubitux> since vp9 is using multiple reference frames i wonder if the encoders deels properly with this :)
[20:45] <{V}> vitruvian, did you check errno ?
[21:04] <durandal11707> llogan: is dalu547 subsribed or not?
[21:08] <llogan> durandal11707: what's the address?
[21:09] <llogan> durandal11707: no. (and I assume you mean -user)
[21:15] <durandal11707> yes, they write mail, do not subscribe, and when they do not get reply, send same message over and over again
[21:18] <llogan> ...and if you cc or bcc them they reply directly to you instead of list
[21:26] <vitruvian> {V}: I managed to find out, thanks a lot =]
[21:26] <{V}> congrats :)
[21:36] <vitruvian> Other thing... I need to send 1500 bytes over the network only (frame), but the buffer in X_write is 11000, I see udp implements a list but there is a way to shrink the buffer size?
[21:38] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:18802942d1a2: avcodec/mpeg12dec: Use skip_1stop_8data_bits()
[21:54] <cone-863> ffmpeg.git 03Reimar Döffinger 07master:4fab08c94f83: Optimize pure C unscaled yuv2rgb.
[22:00] <Mista_D> If one wants to call DSP from ffmpeg to encode YUV to HEVC, where does he start?
[22:03] <{V}> vitruvian, Mista_D, is this applicable "Questions about using FFmpeg or developing with the libav* libraries should be asked in #ffmpeg"  ? I don't mean to send you away, I just don't want you to feel ignored.
[22:06] <Mista_D> {V}: Its more a developer related question than a user one, but I will try asking it in ffmpeg channel as well. Thank you. 
[22:07] <{V}> Mista_D, you intend to improve ffmpeg?  "Discussions about the development of FFmpeg itself are ontopic here." 
[22:10] <Mista_D> {V}: Not sure yet, but it will involve buying a TI card in any case.
[23:38] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:cc0e47b55096: avcodec/jpeglsdec: check err value for ls_get_code_runterm()
[00:00] --- Thu Oct 31 2013