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

[burek]

[01:35] <cone-27> ffmpeg.git 03Michael Niedermayer 07master:83f7bd6dcf00: avcodec/g2meet: fix stride calculation, use correct format field
[01:35] <cone-27> ffmpeg.git 03Michael Niedermayer 07master:6d9dad6a7cb5: avcodec/g2meet: check available space before copying palette
[02:09] <clever> when using ffplay, how do i hide the    2.78 M-V:  0.181 fd=  61 aq=    0KB vq=  921KB sq=    0B f=0/0   
[02:18] <cone-27> ffmpeg.git 03Martin Storsjö 07master:dc80e2f7a529: Makefile: Fix building programs on systems with a nonempty executable suffix
[02:18] <cone-27> ffmpeg.git 03Michael Niedermayer 07master:875f9aea3ea0: Merge commit 'dc80e2f7a529d6e4416b40b68699be16fed62d6c'
[02:18] <llogan> clever: "-loglevel quiet" is one method but i'm not sure if that's what you want
[02:23] <clever> thats probly enough, all of my logging is raw printf
[02:24] <clever> looks good
[02:33] <cone-27> ffmpeg.git 03Diego Biurrun 07master:4da3f410d176: configure: Restore doc option to disable building the documentation
[02:34] <cone-27> ffmpeg.git 03Michael Niedermayer 07master:5b326f398e9d: doc/Makefile: fix building examples if a program suffix is set
[02:34] <cone-27> ffmpeg.git 03Michael Niedermayer 07master:6f24566f56b8: Merge commit '4da3f410d176dd1a55d7cbe5d2e2ead342027f13'
[02:36] <llogan> clever: there's also fatal, error, and warning
[02:36] <clever> llogan: i think my problem is with reading the frames out of omx
[02:37] <clever> going to try to modify the demo app to output raw frames
[02:43] <cone-27> ffmpeg.git 03Diego Biurrun 07master:92f0abb27fe2: build: Check for pod2man instead of perl for manual page generation
[02:43] <cone-27> ffmpeg.git 03Michael Niedermayer 07master:a12b4bd107cf: Merge remote-tracking branch 'qatar/master'
[08:40] Action: Compn wonders what kannada language is
[08:47] <cbsrobot> Compn: I think it a dialect from east canada. see http://imgur.com/gallery/FiDTXwA 
[10:14] <cone-203> ffmpeg.git 03Lukasz Marek 07master:3aaa50a9972c: lavd/pulse_audio_enc: add buffer size control options
[10:38] <cone-203> ffmpeg.git 03Andreas Unterweger 07master:10421bcf0ab5: Add an audio transcoding example.
[10:38] <cone-203> ffmpeg.git 03Michael Niedermayer 07master:715f3623f8cd: Merge remote-tracking branch 'qatar/master'
[11:45] <cone-203> ffmpeg.git 03Michael Niedermayer 07master:02abc905cd98: doc/examples/transcode_aac: fix project name
[11:45] <cone-203> ffmpeg.git 03Michael Niedermayer 07master:60b099c37100: get_audio_buffer: fix usage where channels are not set but layout is
[11:45] <cone-203> ffmpeg.git 03Michael Niedermayer 07master:7497c894cd36: doc/examples/transcode_aac: switch to swresample
[11:45] <cone-203> ffmpeg.git 03Michael Niedermayer 07master:ba728c1a2527: doc/examples/transcode_aac: remove non converted codepath
[12:32] <ubitux> hello spam
[14:06] <ubitux> michaelni: do you plan to update doc/examples/Makefile?
[14:07] <ubitux> (adding transcode_aac to EXAMPLES should be enough)
[14:07] <michaelni> ubitux, i was not aware it needs an update
[14:07] <michaelni> if you want to updat e it dont hestitate
[14:08] <ubitux> probably later
[14:08] <ubitux> i need to update the readme anyway
[14:09] Action: michaelni is trying to figure out why qpeg fails on openbsd
[14:17] <saste> ffserver is hopeless...
[14:18] <saste> ffserver: big pile of broken, untested, undocumented procedural code
[14:19] <ubitux> http://mail.madler.net/pipermail/zlib-devel_madler.net/2013-November/003087.html
[14:23] <ubitux> saste: companies still use it :)
[14:23] <saste> ubitux, which companies?
[14:23] <ubitux> i can't give names :)
[14:23] <ubitux> but they do, definitely
[14:24] <saste> i suppose they patch and go, never contributing back to master
[14:24] <saste> as is, i can't understand how it can be used
[14:24] <saste> i'm not even able to set private options
[14:24] <ubitux> unpatched ffserver is working
[14:25] <ubitux> at least last time i tried it was working, but it's been a while now
[14:25] <saste> yes, it runs
[14:25] <saste> but not working properly
[14:25] <ubitux> i mean it was streaming
[14:25] <saste> which codecs?
[14:26] <saste> because with libx264 you need at least to set private options (preset and profile)
[14:26] <saste> things work randomly
[14:26] <ubitux> didn't try h264
[14:27] <ubitux> probably mpeg2 or 4
[14:27] <saste> documentation is not existing, feedback is poor to say the least, parsing facilities are broken, error recovery is non-existent
[14:27] <Mavrik> saste, em... you CAN set private options?
[14:27] <Mavrik> AVOptionVideo?
[14:28] <saste> Mavrik, why do you say that?
[14:28] <saste> the fact that the option exists doesn't imply that it works
[14:28] <Mavrik> because I tested it?
[14:28] <Mavrik> at least couple of versions ago when I cared a little about it :)
[14:28] <Mavrik> it might have been broken in later instances tho.
[14:28] <saste> Mavrik, do you have a conf file to share?
[14:29] <Mavrik> hmm... only for webm: https://www.virag.si/2012/11/streaming-live-webm-video-with-ffmpeg/ :/
[14:29] <Mavrik> then I decided to use something more... maintanable :)
[14:30] <saste> Mavrik, like what?
[14:30] <Mavrik> we got Wowza licenses :P
[14:30] <Mavrik> not a practical suggestion I know :)
[14:32] <saste> I believe private options are ignored, in your case "AVOptionVideo quality good"
[14:32] <saste> *silently ignored
[14:33] <Mavrik> *shrug* as I said, they (at least partially) worked when I tested it, I did some tests with x264 and presets as well. I'll look at ffserver.c when I get a little time to see if it's worth losing hair over.
[14:34] <ubitux> i wonder when zlib will finally add a namespace to their function
[14:40] <cone-203> ffmpeg.git 03Derek Buitenhuis 07master:ec0b0c2b5875: doc/platform: Update to reflect current MSVC build situation
[14:42] <ubitux> Daemon404: it's not maintained on videolan side anymore?
[14:42] <Daemon404> "maintained" ?
[14:42] <Daemon404> it was a mirror.
[14:42] <ubitux> yes that's what i mean
[14:42] <Daemon404> the official releases are on the official project page
[14:42] <ubitux> mirrored if you want
[14:42] <Daemon404> i.e. github.
[14:42] <ubitux> i think we had a discussion about that stuff
[14:42] <ubitux> you know how buthurt we are
[14:42] <Daemon404> ... OMG LIBAV N THE URL
[14:43] <Daemon404> -_-
[14:43] <Daemon404> it's the *actual* project page
[14:43] <Daemon404> get over it
[14:43] <ubitux> i think the existence of the mirror was for this whole reason
[14:43] <Daemon404> o
[14:43] <Daemon404> no
[14:43] <Daemon404> it was not.
[14:43] <ubitux> ok
[14:43] <Daemon404> teh existed of teh videolan mirror was because github axes binaries
[14:43] <Daemon404> which are back now
[14:43] <Daemon404> as "releases"
[14:43] <ubitux> heh, fun ok
[14:44] <Daemon404> and now google code axed binaries
[14:44] <Daemon404> an people move to github
[14:44] Action: Daemon404 just lols
[14:44] <Daemon404> still better than sf.net...
[14:45] <nevcairiel> i'm still undecided what to do about binaries as of january when gcode shuts down
[14:45] <nevcairiel> maybe just host them myself
[14:54] <cone-203> ffmpeg.git 03Michael Niedermayer 07master:f13f139febf4: avcodec/qpeg: make qpeg_decode_inter() noinline
[14:56] <Daemon404> nevcairiel, depends how much traffic it gets
[14:56] <Daemon404> i.e. a cheap kimsufi may or may not handle it
[14:57] <nevcairiel> i see the number of downloads on gcode today, and its not that high
[14:57] <nevcairiel> and i have plenty bandwidth and traffic
[14:57] <nevcairiel> i mean, its just lav :p
[14:57] <Daemon404> :P
[14:58] <nevcairiel> the bulk of its userbase get it through players that embed it, and thats not my bandwidth
[14:58] <Daemon404> i wonder what percentage of installs come from CCCP
[14:58] <Daemon404> or mpc
[14:59] <nevcairiel> i typically get somewhat around 35k downloads the first month after a release, mpc-hc is probably quite a bit more, no idea about cccp
[14:59] <Daemon404> JEEB might know
[15:00] <nevcairiel> oh i missed one entry, its more like 40k
[15:00] <nevcairiel> but yeah
[15:00] <nevcairiel> half of those on gcode right now, the other half directly from my server
[15:00] <nevcairiel> well or 2/3 gcode, varies a bit
[15:05] <saste> Daemon404, what's wrong with the c89->99 old link?
[15:06] <Daemon404> it is more correct to provide the official binary download link than a mirror
[15:06] <Daemon404> of teh actual project.
[15:06] <Daemon404> mirror is guarantee to be updated
[15:06] <saste> is?
[15:06] <Daemon404> er
[15:06] <Daemon404> isnt
[15:06] <Daemon404> typo.
[15:07] <Daemon404> oh, right
[15:07] <Daemon404> do you need that SDL thing tested
[15:07] <Daemon404> i totally forgot
[15:09] <saste> Daemon404, i spent a day on mingw/win world
[15:09] <saste> i finally managed to test the SDL device
[15:09] <Daemon404> oh
[15:09] <Daemon404> sorry that i forgot.
[15:09] <saste> the weird thing was that ffplay was crashing in libsdl
[15:09] <Daemon404> sdl makes me sad
[15:09] <Daemon404> in more than one way
[15:09] <saste> some MMX optims
[15:10] <Daemon404> random inline asm
[15:10] <saste> but the SDL device was working fine...
[15:10] <wm4> so is the plan to retarget ffplay to use libavdevice for output?
[15:11] <saste> wm4, no plan in so far
[15:11] <saste> the plan was to switch to opengl, but i'm no maintainer
[15:11] <Daemon404> it's not like anyone uses ffplay as their standard player
[15:11] <JEEB> Daemon404, since we don't have anything more thorough to check for numbers, analytics tell me /download.php?type=cccp was hit  202,415 times in the last month, uniquely
[15:11] <Daemon404> ^ nevcairiel 
[15:12] <michaelni> Daemon404, i would prefer if we link to a mirror run by a neutral 3rd party like videolan 
[15:12] <ubitux> saste: isn't sdl2 able to use opengl?
[15:12] <Daemon404> michaelni, it is not "run" by libav
[15:12] <nevcairiel> honestly i'm glad not to have that many direct users, I always intended it to be picked up by devs and me not having to deal with all the end-users
[15:12] <Daemon404> please stop being so tinfoilhat-paranoid
[15:12] <Daemon404> it's wbs, BBB, and myself
[15:12] <Daemon404> nobody else.
[15:13] <Daemon404> it's a url. get over it.
[15:13] <wm4> Daemon404: it's bad publicity *grin*
[15:13] <Daemon404> this is so retarded.
[15:14] <Daemon404> clearly we are going to package anti ffmpeg malware
[15:14] <Daemon404> and videolan wont.
[15:14] <michaelni> Daemon404, anyone can check who the members of the github repo are and that arent BBB, wbs and you
[15:14] <michaelni> also a github under the name of libav "belongs" to / is under the control of libav
[15:15] <Daemon404> ... this is so fuckign retarded
[15:15] <michaelni> yes
[15:15] <Daemon404> it's *the upstream*
[15:15] <Daemon404> we wrote it.
[15:15] <Daemon404> we maintain it.
[15:15] <Daemon404> there is no anti ffmpeg agenda
[15:15] <Daemon404> its a freaking url
[15:15] <Daemon404> i cant believe its such a big goddamn issue
[15:15] <wm4> it makes perfect sense from a publicity-bullshit point of view
[15:15] <Daemon404> the videolan mirror syncs the binaries from *us*
[15:16] <Daemon404> which *I* build
[15:16] <Daemon404> which are what gets put on teh github url
[15:16] <ubitux> then no need to change the url ;)
[15:16] <michaelni> if there is no bias toward libav and away from ffmpeg why is libav in the url and why is it hostedn on libavs github ?
[15:17] <michaelni> i trust you Daemon404 and so do i trust BBB and wbs but i do not trust libav
[15:17] <Daemon404> because at the time it seemed like a good place to put it, since all its authors were part of said project
[15:17] <Daemon404> this isnt true anymore
[15:17] <Daemon404> see: BBB
[15:17] <Daemon404> but serious its a fucking url
[15:17] <Daemon404> and i cant beliee how butthrt and paranoid you people are
[15:17] <Daemon404> it's ridiculous.
[15:17] <ubitux> it's not paranoia
[15:17] <Daemon404> tribalistic?
[15:18] <ubitux> we are not suggesting any probably future hostility because of an url
[15:18] <saste> ubitux, i guess so (about sdl2), but i never tested/checked
[15:18] <ubitux> we are requesting for a neutral url
[15:18] <Daemon404> ubitux, WHY
[15:18] <ubitux> because we prefer neutrality over flaming
[15:18] <Daemon404> omg cant link the canonical upstream cause we dont like the url
[15:18] <Daemon404> you know how insane that is?
[15:18] <Daemon404> .. flamning? from whom? you lot are the *only* people with issues.
[15:19] <nevcairiel> i dont consider videolan neutral in all of this, if you really care :p
[15:20] <Daemon404> how can you trust VLC? they buld wiht libav one release, and ffmpeg in another!
[15:20] <Daemon404> conspiracy!!!
[15:20] <ubitux> i don't know why you insist so much on the paranoia aspect
[15:20] <wm4> they used Libav once? obviously VLC can't be trusted
[15:20] <ubitux> it was never the question
[15:20] <michaelni> I remember quite well how ffmpeg.mplayerhq.hu was redirecting to libav against both ffmpeg and mplayer develoepers wishes i dont want to link to places that are under the control of the same people who did that
[15:20] <Daemon404> ubitux, there's no legitimate reason to change the url. only tribalism / butthurt.
[15:21] <nevcairiel> ubitux: if you are afraid that someone is going to break it just to spite ffmpeg, then thats paranoia
[15:21] <ubitux> pushing a patch that links to a competitive and openly hostile project was ofc going to cause a little drama
[15:21] <ubitux> who ever talk about breaking ffmpeg?
[15:21] <Daemon404> ubitux, except this project wrote the goddamn tool
[15:21] <Daemon404> linkign elsewhere is disingenuous.
[15:22] <wbs> linking anywhere else than to that url is not giving proper credit to where credit is due and is interpreted as you not giving credit to those who actually wrote it
[15:22] <wbs> that's my opinion
[15:22] <Daemon404> me too.
[15:22] <Daemon404> enjoy opinions of two of the authors.
[15:23] <ubitux> ok
[15:23] <wbs> of course you're allowed to link anywhere you want, but don't expect much support or help
[15:23] <wbs> if you insist on removing credit and insulting the authors of that given tool
[15:23] <michaelni> wbs, noone removes credit
[15:24] <wbs> michaelni: I take it as a personal insult if you change the link to point anywhere else
[15:24] <Daemon404> by linking to a random mirror, that is in fact, removign credit
[15:24] <ubitux> (credits are in URL?)
[15:24] <ubitux> it's a goddamn url Daemon404 
[15:24] <michaelni> there is a diference between crediting the authors and advertising ones political party
[15:24] <ubitux> :s
[15:24] <Daemon404> README, project info etc
[15:24] <Daemon404> a random dir listing doesnt have this
[15:25] <Daemon404> nor does it provide an issue tracker
[15:25] <wbs> michaelni: when we created this one tool we wanted the tool to advertise this one political party as well
[15:25] <wbs> if you want the tool (and want to play nice with the authors), then suck it up and use this url
[15:25] <wm4> obviously the solution is that ffmpeg forks this tool, and from now on links to the fork
[15:25] <Daemon404> wm4, they almost did that originally
[15:25] <Daemon404> i know youre jesting
[15:25] <Daemon404> but its a bit close to home.
[15:25] <wm4> I am, but I feel bad for it
[15:25] <michaelni> wbs, are you sure your views are in line with the license that you put on the code ?
[15:26] <wbs> michaelni: of course the license itself allows you to do whatever you want with it
[15:26] <Daemon404> leave it to michaelni to not understand human interaction
[15:26] <wbs> michaelni: but by doing that you are taking stance that you don't want my help with using/maintaining it
[15:26] <Daemon404> and things like respecting others work
[15:26] <michaelni> wbs, dont fear i do respect your wishes
[15:27] Action: Daemon404 would also like to point out that he's done plenty of ffmpeg-specific MSVC/c99wrap changes
[15:29] <michaelni> Daemon404, yes and i and ffmpeg is if a project can, thankfull to you for that
[15:29] <wbs> michaelni: but please go ahead and fork it and maintain the tool yourself if you don't trust the libav branded version, I'm sure you've got nothing better to do than maintain even more forks
[15:30] <Daemon404> let's settle down now...
[15:30] <michaelni> wbs, i certainly prefer if there are less forks, it tends to help noone
[15:30] Action: Daemon404 hands wbs a beer
[15:31] <Daemon404> if we wait a sufficiently long time, c99conv wont even be needed
[15:31] <Daemon404> just a reminder ;)
[15:31] <wbs> yes, I've worked hard to make it unnecessary lately
[15:31] <Daemon404> yep
[15:31] <Daemon404> right now it only exists for legacy msvc support.
[15:31] <nevcairiel> that reminds me, i need to update my fate to remove the manual c99wrap noconv line
[15:32] <nevcairiel> from the early days of 2013
[15:32] <Daemon404> ;p
[15:32] <wm4> wbs: what kind of work?
[15:32] <wbs> wm4: making sure that configure checks whether c99->c89 conversion actually is needed
[15:32] <wm4> oh, right
[15:32] <Daemon404> ea9f7173ae912566e26e9ab7bf89a75b42a72f8d
[15:32] <wbs> wm4: and making sure that configure/make can use the official parameter formats of cl.exe instead of needing a separate unofficial parameter syntax for converting paths from msys to win32 format
[15:33] <wbs> -> needing no out of repo tools at all if you use ICL or msvc2013
[15:33] <Daemon404> the most important part was trolling ms to c99
[15:33] <wm4> it's like hell has frozen over
[15:34] <Daemon404> nah
[15:34] <Daemon404> thats reserved for when libav and ffmpeg merge
[15:34] <Daemon404> and all 3 mplayers merge
[15:34] <wm4> physically impossible
[15:34] <nevcairiel> we should just delete some of the mplayers
[15:34] <wm4> mplayer2 apparently died...
[15:34] <Daemon404> shocking
[15:35] <wm4> (so I made a new one)
[15:41] <Daemon404> hmm... i feel like should update my libx265 patch
[15:41] <Daemon404> but x265 is still crap
[15:41] <Daemon404> /motivation
[15:42] <ubitux> there are quite some activity around x265
[15:43] <JEEB> yes, the indian and chinese offices are in full speed >_>
[15:45] <Daemon404> its still worse than x264
[15:45] <Daemon404> nontrivially worse
[15:50] <cone-203> ffmpeg.git 03Stefano Sabatini 07master:8adaee56c414: ffserver: factorize opt_audio/video_codec
[15:50] <cone-203> ffmpeg.git 03Stefano Sabatini 07master:6b58488f926a: doc/ffmpeg: use @command{} for programs mentioned in -override_ffserver
[16:42] <saste> where is FFM2 defined?
[16:43] <saste> also how it is ffm supposed to cope with private options?
[16:44] <saste> git show b2b67fd6
[16:44] <saste> what is this phantomatic FFM2??
[16:44] <ubitux> a new more flexible format
[16:45] <ubitux> version of* the format
[16:45] <saste> ubitux, yes, and where is it defined?
[16:46] <ubitux> saste: 9829ec1a9c0d51d090c5060a7f430fddffaf52c5 
[16:46] <ubitux> + the hash you just showed
[16:48] <saste> uhm.. so no way whatsoever to set private options
[16:49] <saste> the whole system is pretty limited and unflexible
[17:09] <saste> michaelni, since FFM is an FFmpeg-specific hack, why don't you consider the possibility to send the configuration parameters
[17:10] <saste> so the encoder can choose the correct encoder (in case several encoders are mapped to the same codec ID), and private options
[17:11] <saste> it won't work with anything else than ffmpeg, but i don't think you can make it work with anything else even now
[17:11] <saste> as is, ffserver usefulness is very limited
[17:13] <michaelni> saste, me not considering? do i ? dont i ?
[17:13] <michaelni> not sure i understand you
[17:14] <saste> that's the basic idea about ffm / ffserver as far as i understand it
[17:14] <saste> ffserver specifies encoding params in the stream section, these are mainly old-style MPEG encoding parameters
[17:15] <michaelni> yes
[17:15] <saste> then these parameters are encoded in the header which is sent to the encoder, which is configured with these parameters
[17:15] <michaelni> yes minus bugs
[17:15] <saste> now the problem is that for example you can't specify the codec implementation
[17:15] <saste> nor private options
[17:15] <saste> since the set of encoding parameters is hardcoded in the format specification (which is in this case basically the implementation)
[17:16] <saste> example
[17:16] <cone-203> ffmpeg.git 03Michael Niedermayer 07master:808c10e728db: avutil/log: check that len is within the buffer before reading it
[17:16] <saste> i was setting libfdk_aac in the stream, and ffmpeg was automatically selecting libfaac
[17:17] <michaelni> yes, that should be extended, it should become possible to pass arbitrary options
[17:17] <saste> private options are basically discarded, so with recent libx264 it will fail because it can't set proper presets
[17:18] <michaelni> a simple key,value string list might do to fix that 
[17:18] <saste> yes
[17:34] <saste> michaelni, the workaround for the moment is to use ffmpeg -override_ffserver
[17:34] <cone-203> ffmpeg.git 03Derek Buitenhuis 07master:fa515c2088e1: doc/platform: Update to reflect current MSVC build situation
[17:34] <cone-203> ffmpeg.git 03Michael Niedermayer 07master:b723c4e67e20: Merge remote-tracking branch 'qatar/master'
[20:25] <llogan> michaelni: is trac admin web interface still being weird?
[20:25] <llogan> i believe that last spam got through because the user may have existed prior to new spam plugins
[20:26] <llogan> and i didn't remove it due to the admin slowness
[20:35] <Zeranoe1> michaelni: It looks like you did some work with the amv codec. Do you know if it accepts bitrate options? It seems to just ignore them for me even with minrate maxrate bufsize set
[20:59] <michaelni> llogan, who knows, just try to use it and tell me if you notice something weird
[21:00] <michaelni> but note, please only try when iam around, so i can fix it if something goes wrong ;)
[21:02] <Zeranoe1> michaelni: Your sure that was for llogan? I might have missed something but that could be a reply to me
[21:06] <michaelni> Zeranoe1, does the official amv encoder support bitrates ?
[21:07] <Zeranoe1> michaelni: "official"?
[21:07] <nevcairiel> every format has an official encoder
[21:09] <michaelni> yes, like for h264 that would be the reference stuff from ITU, for a game format thats something that the company who made the game used
[21:11] <Daemon404> isnt the official decoder just random chinese mp3 players
[21:12] <michaelni> how are these videos encoded ?
[21:12] <Daemon404> no idea
[21:12] <Zeranoe1> Daemon404: As far as I know, yes. So assuming it doesn't have a bitrate option... how would it know what bitrate to use? If it doesn't support bitrate, how would I control quality
[21:13] <Zeranoe1> http://code.google.com/p/amv-codec-tools/wiki/AmvDocumentation
[21:14] <michaelni> if the official encoder doesnt have a bitrate nor quality option then theres no official way to control either
[21:15] <michaelni> the format doesnt look like it was designed for variable quality but i might be missing something
[21:15] <michaelni> of course one could try to hack something in the encoder
[21:16] <michaelni> to trade off between bits and quality but the quantization seems fixed 
[21:20] <Zeranoe1> michaelni: So if it doesnt support a bitrate or quality option, is the bitrate the same as input?
[23:46] <cone-203> ffmpeg.git 03Timothy Gu 07master:ca21116b3f53: configure: add #include "version.h" to config.h
[00:00] --- Thu Nov 28 2013