Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

March 2013

1 participants
60 discussions

ffmpeg-devel.log.20130329
by burek 30 Mar '13

30 Mar '13

[00:11] <saste> michaelni, do you have comments about opencl design? [00:13] <michaelni> saste, what part in particular ? [00:14] <saste> michaelni, you had some remarks, i don't know if they have been addressed or discussed [00:14] <saste> especially with regards to thread-safeness and threading API usage [00:18] <michaelni> i was looking at opencl 1.0 which explicitly said half the functions are NOT thread safe, 1.2 says they are all thread safe [00:20] <saste> michaelni, another concern was that all the kernels are concatenated and compiled together [00:23] <michaelni> yeah, doesnt make me happy either but the author prefers it that way, also libavfilter itself is also a big blob and not loading the filters one by one [00:23] <saste> michaelni, are you ok with the global context? [00:24] <saste> also I'd prefer to leave review to the thread locking to someone else, they seem weird to me and i'm not familiar with that API [00:29] <llogan> jommy: i'm ogg ignorant, but did you trawl the bug tracker? https://ffmpeg.org/trac/ffmpeg [00:32] <michaelni> saste, ill look at the thread locking [00:34] <jommy> llogan, yes I searched through there but didn't find anything yet [00:36] <llogan> jommy: if you think it is a bug (I'm not sure) you can report it. [01:13] <michaelni> saste, about the global context, i have no real oppinion, if it works no objections from me [01:14] <saste> michaelni, same for me [01:14] <saste> it might work if i'm not too confused [01:17] <jojva> why wasn't ffmpeg/libav accepted in gsoc 2012, is it because of the friction with libav ? [01:18] <Plorkyeran> they didn't want to pick a fork iirc [01:18] <jojva> what about this year then ? [01:19] <j-b> This year is gonna be fun [01:19] <j-b> I will bet it will depend on BBB [01:20] <jojva> j-b, why ? [01:22] <j-b> You'll see :) [01:24] <ubitux> < Plorkyeran> they didn't want to pick a fork iirc // they actually picked the fork [01:24] <ubitux> j-b: he said he was out of the gsoc this year [01:24] <Plorkyeran> oh, they did end up accepting libav? [01:25] <ubitux> they pick libav and not ffmpeg last year [01:25] <Plorkyeran> I guess I stopped paying attention at some point [01:25] <ubitux> so we did a better page this year [01:25] <Plorkyeran> I just remember them initially saying they wouldn't take either to avoid picking sides or something [01:25] <ubitux> hopefully we will be selected this time [01:26] <j-b> what is your page? [01:26] <saste> ffmpeg was not accepted for various reasons, not necessarily related to the forking status [01:26] <saste> some of the reasons were explained and documented, so we should stick with the official reasons given by google [01:27] <jojva> I couldn't find them, which is why i asked directly here [01:27] <ubitux> j-b: http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_of_Code_2013 [01:28] <saste> also they should make room for new orgs from time to time, so was just in their right that they decided to favor other orgs in place of ffmpeg [01:28] <saste> jojva, official reasons were that we had a weak mentoring backup plan, which was true [01:29] <saste> and we hadn't "fleshed out" enough ideas [01:29] <saste> we are trying to do better this year [01:30] <iive> saste: the official reason was PR bulshit [01:30] <ubitux> :D [01:30] <iive> but I can say that because i'm not ffmpeg developer atm. [01:30] <saste> the real reasons, nobody knows but gsoc admins [01:31] <saste> also, who cares anyway? [01:31] <iive> afair they didn't wanted to fund 2 forks... so they picked libav, and BBB was belong the people who decided that. [01:31] <ubitux> saste: intro is nice btw [01:31] <jojva> saste, ok thx, I hope it works I'll definitely take my chance as a student. We'll know in a few days... [01:36] <ubitux> jojva: so you want to do the the mvc thing as student? :) [01:39] <jojva> ubitux: I've thought about it yes, and since the project is interesting (and there's a 5Gs reward :p), I'll apply. With the reward I can even make it a full-time job so, definitely yes. [01:41] <ubitux> ok :) [02:01] <ubitux> saste: can you come up with a new name for the decimate filter? [02:02] <ubitux> ! [02:02] <ubitux> :( [02:02] <ubitux> always the same :( [02:02] <ubitux> well, whatever [02:04] <michaelni> saste and the ping timeouts ... [02:08] <cone-184> ffmpeg.git 03Clément BSsch 07master:0fb9f77a39d3: LICENSE: add libutvideo in the GPL libraries list. [02:15] <cone-184> ffmpeg.git 03Michael Niedermayer 07master:6ae03353de66: mpegvideo: Make the table reallocation more robust. [02:15] <cone-184> ffmpeg.git 03Michael Niedermayer 07master:551f683861bb: yop: Do not keep a copy of parts of the returned packet [02:23] <iive> ubitux: dedup ? [02:23] <ubitux> it's not really a dedup [02:23] <ubitux> the main goal is to reach a certain framerate [02:23] <ubitux> so regularly drop a frame [02:24] <ubitux> it just happens to drop the dup [02:24] <iive> then fixed_fps or constant_fps [02:24] <iive> can it repeat frames, if needed? [02:25] <Daemon404> these are literally the dumbest names for a decimation filter ever [02:25] <Daemon404> it's decimation. that's what it is defined as. [02:25] <Daemon404> anything else is literally the wrong term. [02:25] <iive> so, it removes every 10th frame? [02:26] <Daemon404> >3:2 pattern [02:26] <Daemon404> yeah, no. [02:29] <Daemon404> ubitux, vdecimate / tdecimate / <something>decimate is pretty much what you want [02:30] <ubitux> fdecimate? [02:30] <Daemon404> thats actuall a different avs filter [02:30] <Daemon404> <.< [02:30] <ubitux> :( [02:30] <Daemon404> im not up to speed at why we want to keep the mp decimate as decimate (perhaps so poor poor souls will end up doing fm,decimate and getting terrible results?) [02:30] <Daemon404> i think not having fm and this decimate be obviously related somehow wildly violates teh principal of least astonishment [02:31] <ubitux> i defended that point [02:32] <ubitux> that was the reason motivating using the decimate name and moving current decimate to mpdecimate [02:32] <Daemon404> i can only see leading mpdecimate as decimate leading to Bad Things [02:32] Action: Daemon404 shrugs [02:32] <Daemon404> s/leading/leaving/ [02:33] <Daemon404> if you cant rename mpdecimate [02:33] <iive> Daemon404: so basically, you insist the filter to be called decimate, because avs calls it like this? [02:33] <Daemon404> actually its not caleld that n avs [02:33] <Daemon404> ubitux renamed them [02:33] <ubitux> fieldmatch, decimate [02:34] <ubitux> i renamed a few other things too [02:34] <ubitux> like the "MI" making no sense [02:34] <iive> you renamed avisynth filters? :O [02:34] <Daemon404> ubitux, if you cant rename mpdecimate, prefixing both of them would be the only otehr idea i have [02:35] <iive> Daemon404: i'm sorry, but what i hear and see is uter bulshit. [02:35] <ubitux> iive :) [02:35] <Daemon404> iive, in what way [02:35] <Daemon404> ? [02:35] <ubitux> https://github.com/ubitux/FFmpeg/commits/ivtc [02:35] <ubitux> fyi this is the current state [02:35] <Daemon404> mp decimate is a piece of shit [02:36] <iive> the filter name should make it obvious what the filter does and not be confusing in any way. [02:36] <Daemon404> ........ [02:36] <Daemon404> thats my fucking point [02:36] <Daemon404> [21:22] <@iive> ubitux: dedup ? [02:36] <Daemon404> aka this ^ [02:36] <Daemon404> is 100% wrong [02:36] <Daemon404> and does not represent what it does [02:36] <ubitux> iive: it's likely the current decimate filter will never be used after this anyway [02:37] <iive> I asked you, does the filter remove ever 10th frame, because this is what the word decimate means. [02:37] <ubitux> one solution is to add the current decimate options to the new one [02:37] <ubitux> to not break compat [02:37] <Daemon404> iive, that is NOT what decimate means [02:37] <ubitux> but i don't want to do that [02:37] <Daemon404> fucking look it up [02:37] <Daemon404> "10th frame" came from nowhere [02:37] <ubitux> iive: every N frames, the filter will drop one; it happens to be a dupped one often [02:38] <iive> deci means te [02:38] <Daemon404> http://en.wikipedia.org/wiki/Decimation_(signal_processing) [02:38] <iive> ten [02:38] <Daemon404> ................ [02:38] <Daemon404> are you retarded? [02:39] <iive> i'm referring to the first meaning http://en.wikipedia.org/wiki/Decimation_(Roman_army) , as this is the origin of the word. [02:39] <Daemon404> you realize decimation is a whitespread and well-defined word in he world if DSP? [02:39] <Daemon404> widespread* [02:39] <Daemon404> you are going to see it in any texts related to it [02:40] <Daemon404> and specifications [02:40] <Daemon404> lavfi happens to be a DSP library. [02:40] <iive> even the wiki article that you point gives better word, downsampling. [02:40] <Daemon404> ierally every resource you fin relating to IVTC and telecine [02:41] <Daemon404> will use the word decimation [02:41] <iive> and the article talks mostly about audio processing. [02:41] <Daemon404> literally* [02:41] <Daemon404> ... why am i wasting my time talkign to someone who clearly ha no goddamn clue [02:41] <iive> I don't care. The filter names should be explicit without having nerd dictionary. [02:44] <iive> ubitux: so, once again, what does the filter do exactly, what parameters does it get? [02:44] <ubitux> iive: see 02:35:37 <@ubitux> https://github.com/ubitux/FFmpeg/commits/ivtc [02:47] <iive> so, the filter collects a "cycle" number of frames and drops one of them, likely the duplicated one? [02:48] <ubitux> yes [02:48] <ubitux> 02:37:56 <@ubitux> iive: every N frames, the filter will drop one; it happens to be a dupped one often [02:49] <ubitux> iive: note that current decimate filter is likely unused [02:49] <ubitux> and if used, likely with no specific option, or without scripting [02:49] <ubitux> so i doubt the rename to mpdecimate will change anything [02:49] <ubitux> of course this will be done alone a minor bump of lavfi [02:49] <iive> i would guess that each frame in lavfi have its own pts, are these recalculated? [02:50] <ubitux> yess [02:50] <ubitux> at least in my filter [02:50] <ubitux> not sure about the mp one [02:50] <iive> the mp one is not supposed to. it just removes duplications. [02:51] <ubitux> the goal of the mp one was actually the same purpose [02:51] <ubitux> a post field matching filter [02:51] <ubitux> it was for ivtc as well [02:51] <ubitux> the original goal was likely lost at some point [02:52] <ubitux> and likely no one really care anyway [02:52] <iive> not really, most ivtc in mplayer don't produce duplicated frames. [02:52] <ubitux> i won't check the 5 ivtc filters in mplayer to prove you wrong :p [02:53] <iive> filmdint been the monster that does everything. ivtc, deinterlace and fps. [02:54] <ubitux> so monster it's disabled by the mp wrapper ;) [02:55] <iive> ndecimate may be a good name. it removes every N-th frame. [02:56] <ubitux> possibly, but as Derek pointed out, it will cause trouble for people wanting an obvious ivtc workflow [02:56] <iive> or one of every n-th frames. but to have the logic of the name revealed you should use this explanation somewhere. [02:56] <ubitux> "fieldmatch, then the decimate filter... let's use 'decimate'" [02:58] <iive> then rename mp decimate into deduplicate / dedup or something that does explain what it does. [02:58] <ubitux> current decimate filter is a bad name, and essentially an inappropriate filter in most of the cases, especially with this new filter incoming [02:58] <ubitux> also, i belive the rename won't hurt anything, and actually prevent harmful problems [02:59] <iive> well, both filters do remove samples, so both do "decimation" in DSP sense. [02:59] <ubitux> outside an ivtc workflow i failed to see any real cases for the current decimate filter [03:00] <ubitux> iive: are you so against renaming the current filter? [03:00] <ubitux> is that really a problem? [03:00] <iive> i'm happy when what the filter does is obvious by looking at its name. [03:01] <ubitux> decimate is really the name used everywhere when talking about ivtc [03:01] <iive> If I were to request something from the new filter, it would be to set the output framerate as number [03:02] <ubitux> you have thousands of xxxdecimatexxx filters [03:02] <BBB> iive: conspiracy theory 101? [03:03] <iive> no real conspiracy... just bad practices propagating because they are common. [03:03] <iive> oh, you talk about gsoc. [03:03] <BBB> yes [03:03] <BBB> my last highlight was from you [03:06] <iive> so? [03:06] <BBB> like I said, nice conspiracy 101, but I don't think that's quite reflective of reality [03:06] <BBB> but what do I know [03:07] <ubitux> BBB: btw, what is the status of the un-dsputil thing and related? [03:07] <ubitux> still some split to do to reduce size for chromium? [03:07] <BBB> no, chrome is done, afaik [03:08] <ubitux> oh, ok cool [03:08] <BBB> I can still do it for other codecs, but it's slightly lower-priority [03:08] <BBB> so I'll probably not do anything before vp9 is done [03:08] <iive> Well, maybe you can say it straight. Not just dance around the issue. [03:08] <ubitux> what's the current todo list then? [03:08] <BBB> iive: I'm not part of opensource labs, so I have no more information than you do [03:08] <BBB> ubitux: well, dsputil still exists [03:08] <BBB> ubitux: as long as it exists, it needs to die [03:09] Action: ubitux would like to use dsputils properly in lavfi :( [03:09] <BBB> not dsputil; dsp utilities [03:09] <ubitux> right [03:09] <BBB> that's a great idea [03:09] <ubitux> we currently use some deprecated interface, that sucks a bit [03:09] <ubitux> (see vf select and the scene detection for instance, or delogo iirc) [03:09] <BBB> do it like h264, vp8 etc. do it: make a new dsp context which either shares stuff between different components, or is specific for the one thing that needs dsp [03:09] <iive> BBB: so you have never ever given any advices to your colleagues about any projects in gsoc? and you have not been affiliated in any way with gsoc? [03:10] <BBB> iive: I've mentored for libav [03:10] <BBB> and I've mentored for ffmpeg before that [03:10] <BBB> I was admin for libav 2 yrs ago [03:10] <BBB> so it's hard to make a case that I was unaffiliated with gsoc [03:10] <iive> and that's all? [03:11] <bcoudurier> what time is it in europe ? [03:11] <iive> 2 am GMT [03:12] <BBB> I have colleagues in the opensource labs who organize gsoc and are fully responsible and make their own adult decisions about it. they are colleagues, so we may certainly have informal discussion on all kind of stuff related to opensource software in general [03:12] <BBB> but I don't advise them on what project to accept or not [03:12] <BBB> nor should I [03:13] <ubitux> so video dsp only has a edge mc utility? [03:14] <iive> oh, never underestimate the power of right words told to the right person. [03:14] <iive> people are influenced by their peers, by other people whom they trust. [03:15] <iive> anyway, other than that, I wanted to ask you if you have been involved in gsoc from the google side. [03:16] <ubitux> BBB: i'm not sure to get what would be the difference between dsp utilities and dsp util [03:16] <ubitux> BBB: i guess removing from dsputil the code specific functions? [03:17] <BBB> iive: well of course people are influenced by peers, I'm not denying that [03:17] <ubitux> i see huffyuv, h263 and h261 specific code [03:17] <BBB> ubitux: exactly [03:18] <BBB> huffyuv is an easy one [03:18] <ubitux> is there more? [03:18] <BBB> a few [03:18] <BBB> dnxhd I believe uses dsputil also [03:18] <BBB> all mpegvideo ones, as you said, huffyuv and some other similar lossless ones (they use the same functions, actually) [03:18] <BBB> snow [03:18] <BBB> I guess that's it? [03:19] <BBB> iive: I have not been involved in gsoc from either the google side or from the ffmpeg/libav side [03:19] <BBB> (this year) [03:19] <iive> i'm talking about the previous year (2012) [03:19] <ubitux> BBB: i didn't follow how the split was done; some were put in codec specific code, and since video codecs were mostly using dsputil for edge mc thing it was moved to a dedicated one? [03:20] <iive> You've already said (on multiple occasions) that you are not involved this year. [03:20] <ubitux> iive: can we discuss gsoc later, when we will be accepted/rejected instead? :) [03:21] <ubitux> no point really in living in what happened last year [03:21] <iive> (And if my conspiracy is true, this is quite unfortunate for ffmpeg ;) [03:21] <ubitux> that failure actually forced us to make a better gsoc page, i believe it's a good thing in one sense [03:21] <ubitux> whatever the reason we got rejected, something came out of it i believe, so let's stick on this :p [03:22] <BBB> ubitux: right [03:22] <ubitux> something *good* [03:22] <BBB> iive: like I said, conspiracy 101 [03:22] <BBB> let's not go there [03:22] <funman> ubitux: btw i got feedback from Kevin about the windows / sdl discussion this morning [03:22] <ubitux> funman: yeah he told me [03:22] <ubitux> i was trying to troll him [03:23] <ubitux> of course he reacted just as expected [03:23] <funman> well he told me 'it is not windows fault' so troll was succesful :P [03:23] <ubitux> :) [03:23] <iive> BBB: in every myth, there is one kernel of truth.... (e.g. mythbusters) [03:24] <funman> unfortunately i still don't know how to have console output AND not have a console window spawn each time you run the .exe from the desktop/explorer [03:24] <ubitux> don't ask me :p [03:25] <BBB> ubitux: http://pastebin.com/S8vVrgpC complete list of everything using DSPContext [03:26] <BBB> dirac seems like a mistake, the dsp functions for that were very recently added to dspcontext [03:26] <BBB> that should not have been done imo [03:26] <BBB> many of them look trivial and can probably be converted relatively easily [03:26] <ubitux> ok [03:26] <ubitux> btw, any idea why dsputil_init is deprecated? [03:27] <ubitux> shouldn't we have a avpriv_dsputil_init() or something? [03:27] <ubitux> (assuming dsputil is considered dsp utilities) [03:27] <ubitux> (which seems to be its transformation afaiu) [03:30] <ubitux> well i guess that's a lavfi specific issue anyway [03:31] <ubitux> that's the only library outside lavc which needs access to it [03:31] <ubitux> but i'm surprised sws or swr aren't using it [03:34] Action: ubitux wonders why mp=spp builds fine using ff_dsputil_init [03:35] <ubitux> anyone to port it btw? :( [03:38] <iive> BBB: I've been asking you if you have been involved in gsoc on google side for 2012, and so far you have dodged the question at least 2 times. I would like a straight answer. [03:39] <BBB> ubitux: dsputil != dsp utilities [03:39] <BBB> ubitux: dsputil needs to die [03:40] <BBB> ubitux: it can be split in small, manageable and well-designed dsp utilities, some of which may need a avpriv prefix [03:40] <ubitux> BBB: well, when codec specific code will be out of dsputil, won't it become a dsp utilities? :p [03:40] <BBB> also ff_ is fine except on shared library builds with symbol elimination [03:40] <BBB> if codec specific code goes out of dsputil, it no longer exists [03:40] <BBB> there is no single bit that can be shared across 100s of codecs [03:41] <BBB> some of it can maybe be shared between 10 or so? [03:41] <BBB> like emulated_edge_mc [03:41] <BBB> which is why we moved it to a more generically named videodsp [03:41] <ubitux> so you would split every "utility" in a different context? [03:41] <BBB> no, just group them together more logically [03:42] <BBB> I'm quite sure we both agree there's no need for huffyuv median prediction and h263 loopfilter to be in the same dsp utility context [03:42] <ubitux> i consider this codec specific [03:42] <BBB> it's highly unlikely that all codecs that require a h263 loopfilter also require huffyuv [03:42] <ubitux> but as i said, when you purge these things out of dsputil [03:43] <BBB> in fact it's highly unlikely that _any_ codec that uses h263 lf needs huffyuv code [03:43] <ubitux> it's likely dsputil will only contain generic dsp utilities, no? [03:43] <BBB> maybe [03:43] <BBB> I don't know [03:43] <ubitux> typically in lavfi we use sad, diff_pixel, etc [03:43] <BBB> I don't expect that to ever finish tbh [03:43] <BBB> I see DSPContext as something that can eventually be renamed to MpegEncDSPContext or so [03:44] <BBB> but maybe not, I don't know [03:44] <ubitux> looks like dsp utilities with various codec specific bits that need to be out of it to me [03:44] <ubitux> at least in the current state [03:44] <BBB> if you feel that sad can be shared between lavfi and lavc, either use dsputil, or split it out in a new context and use that [03:45] <BBB> it can be done both ways [03:45] <ubitux> so using dsputil as dsp utilities looks legit to me, at least in the context that i'm interested in: lavfi [03:45] <ubitux> BBB: we already use dsputil in 3 filters [03:45] <BBB> just be sure to know that you're incurring the cost of _all_ functions in it if you do that [03:45] <BBB> I know [03:45] <BBB> and I'm sad that we do [03:45] <BBB> I feel this whole thing could be deisgned better [03:45] <BBB> but I'm 100% realistic that many people dont care [03:45] <BBB> brb baby [03:47] <BBB> look, my point is that if you look at ffmpeg as a whole, right, all that code is already in there, so it makes no difference [03:47] <BBB> if you look at it as a collection of individual components, where you can pick and choose (like chrome does), I feel it's a bad idea [03:47] <BBB> but do what you feel is bad, I don't try to hold a decisive vote here [03:47] <BBB> just please don't reintroduce a dspcontext or mpegvideo dependency in h264 or vp8 or vp3 or aac or mp3 or vorbis [03:48] <ubitux> haha my goal was more lowly [03:48] <ubitux> just wondering about the dsputil warning :p [03:48] <BBB> oops, I said "bad" [03:48] <BBB> I meant "right" [03:49] <BBB> sorry, that was honest mistake [03:49] <BBB> do what you feel is right [03:49] <iive> The trick here is not the context on its own, but how it is filled with function pointers. because it have common init, all functions must be present, thus compiled and linked. [03:54] <BBB> ubitux: e.g. if you feel sad is useful, why not split that and some other related and similarly used functions out in a new context called DistortionDSPContext? [03:55] <ubitux> it's likely i will end up moving every lavfi function needed in it [03:55] <BBB> that sounds ok [03:55] <BBB> you could move that to lavutil [03:55] <BBB> and then lavfi would stop depending on all of lavc [03:55] <BBB> which is kind of nice [03:56] <BBB> like I said, some people care about tht sort of stuff, others don't. I don't really care (given that chrome doesn't use lavfi) [03:56] <ubitux> that will certainly make saste happy [03:56] <ubitux> BBB: note that lavfi doesn't depend on lavc [03:56] <BBB> you just told me it uses dsputil [03:56] <ubitux> having it against lavc enables some feature [03:57] <ubitux> yes, but it's not a hard dep [03:57] <ubitux> select has scene detection only if lavc is enabled [03:57] <ubitux> and filters using dsputil are conditionally enabled as well [03:57] <BBB> if you feel that's the best design, then by all means, go for it [03:58] <ubitux> i've no real opinion on it tbh :) [04:03] <ubitux> mmh i'm tempted to add a aperms before the volume in fate [04:05] <ubitux> does anyone know where fate stores some hard dep? [04:06] <ubitux> ok, found.. [04:09] <iive> ubitux: in case i didn't get to finish the point. about the new decimate filter. usually you want to get from 30 to 24 fps (ivtc). The problem with the "cycle" parameter is that you need to know the input and desired output framerate and [04:09] <iive> (most importantly) do some math outside of ffmpeg. [04:12] <iive> well, i'm off. [05:09] <cone-184> ffmpeg.git 03Michael Niedermayer 07master:aa28c4253438: mjpegdec: check buffer before using it [05:09] <cone-184> ffmpeg.git 03Michael Niedermayer 07master:24cfe91a2202: id3v2: allocate large enough buffer [11:02] <cone-819> ffmpeg.git 03Justin Ruggles 07master:c3d015775388: flvdec: use the correct audio codec id when parsing metadata [11:02] <cone-819> ffmpeg.git 03Michael Niedermayer 07master:8ed9d34aa7f0: Merge commit 'c3d015775388882b8a122afc337ea35108f652be' [11:13] <cone-819> ffmpeg.git 03Justin Ruggles 07master:e46a2a7309d8: flvdec: read audio sample size and channels metadata [11:13] <cone-819> ffmpeg.git 03Michael Niedermayer 07master:774a2684973e: Merge remote-tracking branch 'qatar/master' [11:59] <ubitux> isn't av_frame_copy_props() supposed to copy audio props as well? [11:59] <ubitux> i don't see the channels being copied [11:59] <ubitux> also, af volume seems not to use it [12:00] <nevcairiel> av_frame_copy_props only copies properties which are optional for the format, any code working with buffers is supposed to set the properties that are mandatory to describe the buffer itself [12:00] <nevcairiel> thats w/h/format for video, and nb_samples/channels/channel_layout for audio [12:00] <nevcairiel> oh and format too [12:01] <ubitux> so i spotted 2 bugs? [12:02] <ubitux> nb_samples, channels and channel_layout are not copied in av_frame_copy_props [12:02] <nevcairiel> intentionally so [12:02] <ubitux> oh misread what you said [12:02] <ubitux> ok [12:03] <nevcairiel> but yes there is a bug that af_volume doesnt call it when allocating a new buffer [12:03] <nevcairiel> ff_get_audio_buffer sets all the important properties [12:03] <ubitux> note that this part of the code is not covered by fate [12:03] <ubitux> i'll add aperms in front of the fate test [12:04] <ubitux> so this code path can be tested [12:05] <nevcairiel> not sure how many of the optional properties apply to audio, so it may not do anything [13:03] <saste> kierank, ping? [13:03] <kierank> pong [13:04] <saste> kierank, willing to mentor a gsoc task? [13:04] <saste> maybe something related to VC-1? [13:04] <kierank> i don't know much about vc-1 [13:04] <kierank> and i thought vc-1 was compliant now [13:04] <kierank> ?? [13:05] <saste> or something else [13:05] <saste> as for VC-1 I'm not the person to ask, but there are still some outstanding bugs as far as i know [13:05] <saste> just let me know in case [13:06] <saste> we have still ~1 week to fill the gsoc page [13:20] <michaelni> Ive seen several VC1 videos that show artifacts so theres definitly work left tp be done [13:20] <Compn> was vc1 interlacing finished ? [13:21] <michaelni> there where patches that implemented more of it which where applied i havnt checked if anything is left [13:22] <nevcairiel> the major features are in now, but there is still stuff missing to make it 100% idential to the reference decoder [13:23] <nevcairiel> like, loop filtering for interlaced [13:23] <nevcairiel> and some bugs [13:23] <Compn> k :) [13:23] <michaelni> nevcairiel, do you want to mentor a vc1 task that implements the missing things and fixes the bugs ? [13:23] <nevcairiel> i have no clue about video coding [13:24] <michaelni> Its not really about video coding its about comparing spec/reference against our code and fixing differences [13:25] <michaelni> boring work so maybe its not so bad idea as gsoc [13:29] <nevcairiel> i imagine fixing those [13:29] <nevcairiel> ugs also requires knowledge abouit video decoding [13:29] <nevcairiel> bugs* [13:31] <michaelni> it could be done simply by putting printf() in a reference decoder and av_log() in ours and running diff [13:31] <michaelni> IMHO this doesnt need much knowledge about video coding [13:32] <michaelni> of course its more work than it sounds when writing it that way [13:33] <michaelni> but i dont think it requires deep knowledge of the code ... [13:33] <ubitux> speaking of av_log, it would be nice to have a "printf" mode [13:33] <michaelni> printf mode ? [13:33] <ubitux> basically, no "last message repeated" [13:34] <ubitux> and eventually ignore ctx to not print any prefix [13:34] <ubitux> that's handy to make some stdout diff [13:36] <michaelni> indeed [13:38] <michaelni> should be rather simple to add such mode, iam a bit busy with other ffmpeg work ATM though [13:39] Action: ubitux not working on it either [13:53] <ubitux> btw, on GSOC page, "Qualification Task: TBD" on bayer rgb [13:53] <ubitux> might be relevant to set one [13:59] <michaelni> ubitux, fixed [14:00] <ubitux> thanks :) [14:28] <jojva> not to seem greedy but, does that happen often that students receive bad evaluations and aren't paid during gsoc ? [14:30] <Compn> not much [14:31] <Compn> only if a student does no work , missing, etc [14:31] <Compn> which has happened. students sign up then are unreachable [14:31] <Compn> unfinished projects still get paid iirc [14:31] <Compn> some students keep working after gsoc to finish it too... :) [14:39] <jojva> ok it's better than I expected [14:39] <jojva> Dissapearing is weird, it's a contract... It's like leaving a company without telling [14:42] <Compn> some people want to go on vacation :P [14:42] <Compn> or maybe got a job [14:43] <jojva> I guess vacation is possible, as long as the work is done and it's not "going to brazil for a roadtrip"^^^ [15:04] <iive> gsoc is kind of a job. You do the task you get money. [15:24] <nevcairiel> while the project doesnt necessarily need to be 100% finished, there at least have to be signs of good progress =p [15:28] <ubitux> that's certainly a great learning experience and give you recognition [15:29] <ubitux> who cares about money [15:29] <iive> this should not not be a problem if the student is working continuously and the mentor guides him. [15:29] <ubitux> ;) [15:46] <jojva> ubitux: students who can't pay their food for example ;) [15:47] <jojva> But I do agree with you, it's a very nice experience to do [15:48] <ubitux> :) [17:40] <ubitux> michaelni: i believe the help should show up with -help filters [17:41] <ubitux> and -help filter=mandelbrot [17:41] <ubitux> filter help already appears with -help full [17:42] <ubitux> (and on a side note, devices don't seem to appear with -help full) [17:42] <michaelni> ubitux, how does the user know of -help filter=mandelbrot ? [17:43] <michaelni> -vf crop=help is a quite natural way to ask the crop filter for help [17:43] <ubitux> Getting help: -h -- print basic options -h long -- print more options -h full -- print all options (including all format and codec specific options, very long) [17:43] <ubitux> i'd suggest to extend this text ^ [17:43] <durandal_1707> -acodec mp3=help [17:43] <michaelni> durandal_1707, yes, would be nice too [17:44] <ubitux> and maybe display it by default when calling ./ffmpeg [17:44] <durandal_1707> noo! [17:44] <ubitux> we already have a help display system [17:44] <ubitux> this is what we should improve [17:44] <durandal_1707> michaelni: i really dislike what that user proposed [17:45] <ubitux> ffmpeg -help {long,full,filters,formats,codecs,...} [17:45] <durandal_1707> and having flag in filter context for it is poor [17:45] <ubitux> ffmpeg -help codec=libmp3lame [17:45] <ubitux> ffmpeg -help filter=mandelbrot [17:45] <michaelni> Its a question if you want ffmpeg to be useable and intuitiv for non geeks [17:45] <ubitux> sounds relatively trivial as soon as the "Getting help" message is improved [17:46] <durandal_1707> michaelni: nonsense, non geeks dont use console tools, they use GUI [17:47] <durandal_1707> speaking of that what about some official gui for ffmpeg [17:47] <michaelni> durandal_1707, thats a great idea [17:47] <ubitux> a gui for constructing filtergraph too [17:48] <durandal_1707> pick gtk/qt/? [17:48] <microchip_> qt! [17:48] <ubitux> gtk [17:52] <durandal_1707> there are no "Prerequisites" for bayer gsoc task [17:54] <cone-819> ffmpeg.git 03Xidorn Quan 07master:c81d2fa96ddc: avutil/buffer: add get_opaque [17:54] <cone-819> ffmpeg.git 03Michael Niedermayer 07master:ef7b6b489ab3: ffmpeg/avformat: factor av_guess_frame_rate() out [17:57] <durandal_1707> what is prefered way to handle several sample formats in filter? [17:58] <durandal_1707> use single function to get samples inside for loops or macros - which is faster [18:01] <wm4> macros containing inline asm for max supper speed [18:03] <michaelni> durandal_1707, fixed prereq [18:03] <durandal_1707> ? [18:04] <michaelni> Prerequisites for bayer gsoc task [18:04] <durandal_1707> ah, don't write cripticy shorts [18:04] <ubitux> fxd prq [18:04] <durandal_1707> i wld spk lik ths [18:04] <michaelni> k [18:04] Action: ubitux undrsd wll [18:05] <michaelni> bcoudurier, IIRC you said you would be happy to mentor anything ? [18:06] <michaelni> any preferrance ? [18:07] <michaelni> for example something from: http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_of_Code_2013#Unment… [18:07] <michaelni> ? [18:13] <durandal_1707> ubitux: i gonna split filter into: (stereo)vectorscope, phasescope (with optional? history like showspectrum ([-1, 1] meter); balance(meter/scope/gram/???) same as phasescope with histogram; [cross?]correlation[scope?] ditto with history (eg, cross correlation calculated with FFT) [18:14] <ubitux> whatever you prefer :p [18:15] Action: ubitux wants some fft 2d utils :( [18:15] <durandal_1707> ubitux: elaborate [18:16] <ubitux> elaborate on 2d fft? [18:16] <ubitux> afaict ff rdft etc utils are 1d only [18:16] <durandal_1707> for what you will use it? [18:17] <cone-819> ffmpeg.git 03Xidorn Quan 07master:c7269e3a2697: vda_h264_dec: fit the new API [18:17] <ubitux> video filtering [18:17] <ubitux> a lot of algorithm depends on dft 2d run on mb [18:18] <durandal_1707> aw. i'm currenly in audio filtering waters [18:18] <ubitux> yes, 1d :) [20:05] <durandal_1707> it is ok to have memcmp in probe ? [20:17] <cone-819> ffmpeg.git 03Paul B Mahol 07master:8263726c69cf: lavc: fix typo [20:17] <cone-819> ffmpeg.git 03Paul B Mahol 07master:67f9bbbb3f62: noise_bsf: check if allocation failed [20:51] <cone-819> ffmpeg.git 03Paul B Mahol 07master:a345b7f906de: vmdav: use more unchecked bytestream2 variants where it makes sense [20:56] <durandal_1707> michaelni: fixing other sizeof(AVFrame) in lavc? [21:03] <durandal_1707> icoenc actually fails to write PAL8 bmps on big-endian [21:09] <michaelni> sizeof(AVFrame) use should be fixed unless we declare the libs to be ABI "linked" [21:11] <cone-819> ffmpeg.git 03Michael Niedermayer 07master:66e9716a3610: aacps: correct opdipd code to match spec [21:11] <durandal_1707> michaelni: i know that already, but question was/is: are you going/working to fix it at this moment/future? [21:13] <michaelni> at the moment no, i have other ffmpeg related work to do [21:19] <cone-819> ffmpeg.git 03Paul B Mahol 07master:1c11ab82d650: paf_video: make code independent of sizeof(AVFrame) [21:33] <wm4> <michaelni> sizeof(AVFrame) use should be fixed unless we declare the libs to be ABI "linked" <- I think the idea that the libraries are independent is an illusion, and causes more maintenance work and confusion for both developers and users [21:35] <durandal_1707> they currently are linked, but in future may not need to be, (once rewrite everything at last sunday of month on full moon stops) [21:41] <cone-819> ffmpeg.git 03Matt Wolenetz 07master:65340c976c66: Fix pthread_cond and pthread_mutex leaks in vp8 [22:03] <durandal_1707> for ffloger failed compile is same as failed test [00:00] --- Sat Mar 30 2013

1 0

ffmpeg.log.20130329
by burek 30 Mar '13

30 Mar '13

[00:17] <Keshl> So, so, so so I has a video, .ts encoded with h.264. I'm trying to convert it to .mp4 using the x264 encoder, but any time I try the audio is horribly desynced with the video. The pitch is correct, leading me to believe that ffmpeg can't handle the framerate I expect. (59.94 FPS) The video is ahead of the audio. Here's an ffprobe of the .ts file, http://pastebin.com/diRyJpTZ . I've tried commands similar to "ffmpeg -r 59.94 -i foo.ts - [00:17] <Keshl> vcodec libx264 -preset medium -crf 25 bar.mp4" with no success. The .TS file, however, plays just fine. Oddly, when I ran "ffmpeg -r 60000/1001 -i foo.ts -vcodec libx264 -preset medium -crf 25 -acodec copy -t 30 bar.mp4", it produced a 35KB file VLC can't recognize and gave me an error reading "[mp4 @ 000000000037f720] malformated aac bitstream, use -absf aac_adtstoascav_interleaved_write_frame(): Operation not permitted". Does anyone has [00:17] <Keshl> any suggestions? .É.? [00:30] <llogan> Keshl: that's a lot of text, but i think it's telling you to try adding "-absf aac_adtstoasc" [00:32] <Keshl> Oh. .... OH, see, spaces are important. <.< [00:32] Action: Keshl tries. [00:33] <Keshl> That makes it work.. Hopefully it syncs the audio too.. [00:33] <Keshl> Nope. [00:33] <Keshl> x.x [00:34] <Keshl> Same as pretty much every other try. x.x [00:39] <llogan> maybe someone can help, but now i must go [00:42] <Keshl> http://pastebin.com/0Fvxcf0v for whoever needs it, oÉo [00:49] <smus> asked this yesterday, but i wasn't in here long enough. small riff on the main video_encode_example: http://pastebin.com/M5VuHM9b except the outbuf that's populated by avcodec_encode_video is all zeros. out_size > 0 though. ideas? [00:50] <smus> (this is running in Native Client, btw -- trying to make a video encoder that can be invoked from JavaScript!) [02:24] <Muon> hi [02:25] <Muon> I'm trying to record my desktop's audio, but it's getting recorded slowed [02:25] <Muon> I'm running PulseAudio [02:25] <Muon> neither -f pulse -i default nor -f alsa -i pulse works properly [02:26] <Muon> I've tried setting -sound_rate on -f pulse to 44100, but that didn't change anything [02:36] <Sanky> hello, I use ffmpeg to stream my desktop, but the audio desyncs (about five seconds from the beginning, but it falls behind even more) [02:37] <Sanky> what should I use to keep audio and video in sync? [02:39] <Muon> also, when recording from the desktop audio monitor, PA's CPU usage massively jumps [02:39] <Muon> around 30% in top [02:39] <Sanky> this is the command I've put together: http://pastie.org/7157324 [03:22] <Muon> hmm [03:22] <Muon> it was a problem with the sample rate on the PA side [03:23] <Muon> now to figure out why I can't record both the mic and the desktop audio at the same time [03:24] <klaxa> there's two ways to that [03:24] <klaxa> either you record two audio-tracks with ffmpeg, or you mix both audio-streams in pulseaudio and record only one [03:24] <klaxa> the first approach is cleaner though since you can do proper post-production on the different tracks [03:24] <klaxa> *post-processing [03:25] <Muon> klaxa: hmm? [03:25] <Muon> klaxa: I'm currently just specifying two pulse inputs [03:26] <Muon> but only the last one seems to be going through [03:26] <klaxa> how can you tell? [03:27] <Muon> hm, actually, no [03:28] <Muon> klaxao: if I put the system audio monitor in at all, it takes over [03:36] <Muon> ok [03:39] <Muon> klaxa: http://pastie.org/private/9llsgymvlnupncngbh0ga [03:40] <klaxa> Muon: try adding -map 0 -map 1 to your command line [03:42] <Muon> klaxa: nope, that just reintroduced the pitch problem [03:42] <klaxa> do you have two audio-tracks though? [03:42] <Muon> klaxa: ? [03:43] <klaxa> either the output of the command line you ran, or ffprobe <output> [03:43] <klaxa> on a pastebin-like site please :) [03:43] <Muon> sec [03:44] <Muon> klaxa: http://pastie.org/private/h6tr6igezihv0qv21n9ka [03:44] <klaxa> Stream mapping: [03:44] <klaxa> Stream #0:0 -> #0:0 (pcm_s16le -> libvorbis) [03:44] <klaxa> Stream #1:0 -> #0:1 (pcm_s16le -> libvorbis) [03:44] <klaxa> at least you have both audio streams :X [03:45] <klaxa> that's weird though [03:45] <klaxa> it doesn't look like there is any resampling going on even [03:45] <Muon> I can record both with parecord [03:45] <Muon> FWIW [03:45] <Muon> (at the same time) [03:46] <klaxa> yes, ffmpeg is recording both inputs now too (only on two different tracks, you will have to extract them individually and mix them again if you want to have them in one track) [03:48] <Muon> klaxa: right, but I want them to be mixed [03:48] <klaxa> ah you want to mix them without post-processing? (are you sure? your mic would probably create a lot of noise you might want to filter) [03:49] <klaxa> in that case however, you can use pulseaudio to mix the two streams to one single stream and record that one [03:49] <Muon> this is just for fun :) [03:49] <klaxa> to do that you have to load a null-sink module and one loopback-module in pulseaudio [03:49] <Muon> klaxa: can't ffmpeg do that? [03:50] <klaxa> hmm... i'm sure there is some mixing audio filter, but you might still have this weird pitch-issue [03:50] <Muon> I want to try [03:52] <klaxa> https://ffmpeg.org/ffmpeg-filters.html#amix [03:53] <klaxa> Muon: ^ [03:57] <Muon> klaxa: I love you :D [03:57] <Muon> thanks [03:57] <klaxa> :) [03:57] <Muon> it actually doesn't sound that bad [03:58] <Muon> maybe with a low-pass filter [03:58] <klaxa> Sanky: you still there? [03:59] <klaxa> you could try to add -async 1 to your command line [03:59] <klaxa> or a higher value [03:59] <klaxa> see the ffmpeg manpage for more details, it tries to keep the audio synced by adding or removing samples from the audio-stream [04:00] <klaxa> ah uh... [04:00] <klaxa> wait... 1 is a special case, also that option is deprecated :| [04:01] <klaxa> Sanky: https://ffmpeg.org/ffmpeg-filters.html#asyncts [04:04] <Muon> klaxa: http://pastie.org/private/1mv7hzdm9snckt9ptipkg [04:04] <Muon> I tried using aresample [04:07] <klaxa> okay from what i take from the output ffmpeg doesn't know which input to resample [04:07] <klaxa> hmm no wait [04:08] <klaxa> mh sorry dunno [04:08] <Muon> ah [04:08] <Muon> fixed it [04:08] <Muon> need to put the filter string in one filter command [04:08] <Muon> -filter_complex 'foo, bar, baz' [04:09] <klaxa> ah [04:13] <Muon> klaxa: it's better, but I still think I need a low pass filter to get rid of the hum produced by the computer [04:14] <Muon> and it claims that lowpass is not a filter [04:14] <klaxa> lolwut [04:14] <klaxa> paste it? [04:15] <Muon> klaxa: http://pastie.org/private/nyfknxdwlye9czm0qtbjw [04:16] <klaxa> weird [04:16] <klaxa> see if it shows up in "ffmpeg -filters" [04:16] <Muon> it doesn't [04:17] <klaxa> then you don't have it... and neither do i, i wonder why [04:17] <Muon> hrm [04:18] <klaxa> you might have to recompile and add --enable-filter=lowpass to ./configure [04:44] <stevenbell> Hi, I'm trying to simultaneously webcast and record a single video input (v4l2, in this case). I can easily do this by having two output files for one command, but I want to be able to start and stop the recording, while leaving the webcast running. [04:45] <stevenbell> Right now I'm doing this by having one instance that sets up the web stream (flv to Justin.tv) and another RTP stream, which is read by a second instance of ffmpeg. Is there a better way to do this? [10:33] <Zeeflo> how do I define srt (subtitles) playresx and y ? [10:33] <Zeeflo> and, can I define scale (size) of subtitles? [10:33] <Zeeflo> im using bureks build [10:34] <Zeeflo> ubitux, [10:44] <relaxed> Zeeflo: you probably want to convert them to ass [10:45] <Zeeflo> it takes out the ease of use with SRT and not having to convert them.. [10:45] <Zeeflo> Is it cause of some vobsub setting? [10:45] <relaxed> maybe you can find some software to edit them to your liking [10:46] <Zeeflo> nah.. I dont wanna edit all my subtitle files. [10:46] <Zeeflo> time saved = money saved [10:46] <Zeeflo> i was just wondering if I could specify the playres for srt [10:47] <relaxed> well, I know with ass it's specified in the subs [10:47] <Zeeflo> yea it is [10:47] <Zeeflo> as well as font etc [11:49] <PG12> so my question is can we output from ffmpeg to http ? [11:50] <PG12> something like ffmpeg -i RTP_H264 -o http://ip:80/file.vp8 [11:50] <PG12> is this possible? [11:50] <Mavrik> is there a server on ip:80? [11:50] <PG12> yes [11:52] <PG12> Mavrik: my concern is mainly is if ffmpeg can accept rtph64 and output to an http address [11:52] <Mavrik> iirc yes [11:53] <Mavrik> you will have to pass "copy" as codecs if you don't want to reencode [11:53] <PG12> i just heard that ffmpeg cant output http [11:53] <JEEB> yes, it cannot serve http [11:53] <JEEB> only ffserver can [11:54] <JEEB> VLC or ffserver are the alternatives with ffmpeg [11:54] <PG12> which one would be easier to get it running [11:54] <Mavrik> PG12, that's why I asked you [11:54] <Mavrik> if you have a server on the receiving side [11:54] <Mavrik> and you said "yes" [11:55] <Mavrik> there's a difference between being a server and sending to a server [11:55] <PG12> Mavrik: i do have a streaming server wuilling to accept the vp8 sent from ffmpeg [11:55] <Mavrik> then ffserver isn't a solution for you [11:55] <Mavrik> ffmpeg should work. [11:56] <JEEB> I remember trying to do http streming with apache once [11:56] <JEEB> wouldn't take my named pipe :V [11:57] <PG12> i didnt get it [11:57] <Mavrik> JEEB, I streamed VP8/vorbis to stream-m with ffmpeg over http with no problems [11:58] <JEEB> yeah, but what was serving http in that case? [11:58] <JEEB> and how did you feed it to your http server in that case? [11:58] <Mavrik> stream-m is a HTTP streaming server. [11:59] <JEEB> just out of interest, how did you feed the stream to it? [11:59] <PG12> Mavrik: how did you feeed the theora/vorbis from ffmpeg into the stream-m ? [11:59] <Mavrik> JEEB, with http :) [12:00] <Mavrik> JEEB, see the "publishing on linux" example https://code.google.com/p/stream-m/ [12:00] <PG12> Mavrik: how with http? [12:00] <Mavrik> stream-m had some stability problems though [12:00] <PG12> Mavrik: you used ffserver? [12:00] <Mavrik> no. [12:00] <JEEB> waait, I don't get it [12:00] <JEEB> does ffmpeg have http output now? [12:00] <PG12> -f webm http://example.com:8080/publish/first?password=secret ? [12:01] <Mavrik> JEEB, yeah. [12:01] <Mavrik> :) [12:01] <JEEB> ... [12:01] <JEEB> since when? [12:01] <Mavrik> had it for awhile afaik [12:01] <Mavrik> I tested this like a year ago [12:01] <Mavrik> (maybe less) [12:01] <JEEB> I've been pretty sure it couldn't do http serving [12:01] <Mavrik> it can't [12:01] <Mavrik> it can connect to a HTTP server [12:01] <Mavrik> it cannot act as a http server [12:01] <JEEB> aahhh [12:01] <Mavrik> (that's why you need ffserver for that) [12:01] <JEEB> so http post instead of get? [12:01] <JEEB> or whatever [12:02] <Mavrik> yeah [12:02] <JEEB> gotcha [12:02] <Mavrik> stream-m open HTTP socket where it receives video and then acts as a server [12:02] <Mavrik> *opens [12:02] <PG12> Mavrik: did you get it working with ffmpeg? [12:02] <PG12> or ffserver? [12:02] <PG12> i am confused [12:03] <JEEB> you need ffserver if you have no other streaming server, if you have a separate streaming server that takes in post [12:03] <JEEB> then you can use ffmpeg [12:03] <PG12> yes i have icecast [12:03] <PG12> ffmpeg -re -i univac.webm -vcodec copy -acodec copy \ [12:03] <PG12> -f webm http://ICECAST:8080/publish/first?password=secret [12:03] <PG12> that should work then? [12:09] <JEEB> PG12, I have no idea if icecast is supposed to work, but yes -- in general like that [12:10] <Mavrik> yeah, haven't tried icecast [12:30] <PG12> do you think the Raspberrypi can handle vp8 transcoding from a webcam and send to icecast? [12:50] <Sanky> klaxa: late thanks! [13:07] <Sanky> hm, I can't get asyncts nor aresample to work [13:08] <Sanky> and I've been using async (it's in the paste I provided) [13:10] <relaxed> Sanky: url? [13:11] <Sanky> relaxed: http://pastie.org/7157324 [13:11] <Sanky> I'm trying to get audio and video in sync, they start desynced and shift away even more with time [13:12] <relaxed> This is a common issue [13:13] <relaxed> try using a faster preset and/or less fps [13:13] <Sanky> that doesn't sound like a solution :/ [13:13] <Sanky> I'm already using the "fast" preset [13:14] <relaxed> do you need to change the audio's sample rate? [13:14] <Sanky> not sure, maybe I don't [13:14] <relaxed> well your paste shows medium, and that's all I have to go by [13:15] <Sanky> oh, geez, I have two presets set [13:15] <Sanky> FLV does not support sample rate 48000, choose from (44100, 22050, 11025) [13:15] <Sanky> yes, I need to set it [13:16] <relaxed> ok, try again with -tune zerolatency [13:16] <JEEB> it does support the sample rate of 48kHz -- but with AAC :P [13:16] <Sanky> yeah, I have to use flv [13:17] <JEEB> I didn't look at your command or what format you are using, but you just said something incorrect [13:17] <JEEB> FLV supports 48kHz [13:17] <JEEB> with AAC [13:17] <JEEB> if you are using something else but AAC, then yes [13:17] <Sanky> I said exactly what vlc spewed at me [13:17] <JEEB> then VLC is incorrect [13:17] <JEEB> you can go look at the FLV specification [13:17] <Sanky> relaxed: the audio is still behind with that option, but I don't know if it will or won't shift more with time [13:17] <JEEB> the VLC specification says that 48kHz is all OK for AAC in FLV [13:17] <JEEB> ugh [13:18] <JEEB> not VLC specification [13:18] <Sanky> if it's behind by a fixed amount I assume that could be fixed [13:18] <JEEB> FLV [13:18] <JEEB> I know libavformat got fixed regarding this some time ago (within the last year or so) [13:18] <Sanky> JEEB, oh, well I also use -acodec libmp3lame [13:18] <JEEB> yes, for MP3 it doesn't have wider support [13:18] <JEEB> it's only for AAC [13:19] <JEEB> also FLV is otherwise pretty much limited to stereo, but once again AAC is the exception [13:19] <relaxed> I'm not sure what to tell you, maybe someone with more screencasting experience will chime in. [13:20] <JEEB> for AAC it just says that you should write the values of 2ch/44.1kHz into the container, and then write your stream into it. And then the reader/player will ignore those container values and parse the data from the actual AAC stream [13:20] <JEEB> (that's what the actual FLV specs say :D ) [13:20] <Sanky> it's okay, I'll try streaming with this option the next time and see how it performs; thanks [13:21] <relaxed> most of the time it's best to simplify your command as much as possible [13:22] <relaxed> start with low bitrates and then introduce more complexity until it fails. [13:37] <Muon> hello again! [13:37] <Muon> this time I'm piping in data from a named pipe [13:38] <Muon> however, what I get recorded is not what I see [13:38] <Muon> (I hacked primusrun to dump frames to a named pipe) [13:39] <Muon> to be specific, it's not quite running at the same rate [13:40] <Muon> e.g. the loading screen apparently doesn't generate many frames, so in the combined output, the thing blurs by [13:49] <Muon> so, uh, yeah [13:50] <Muon> I've got variable rate raw video input [13:50] <Muon> how do I tell ffmpeg to put it together properly? [13:50] <Fjorgynn> what? [13:51] <Muon> Fjorgynn: ? [14:07] <Muon> Fjorgynn: I have variable frame rate input, how do I make ffmpeg output it with timestamps corresponding to when each frame was consumed? [14:07] <Muon> I can play it back using ffplay just fine [14:07] <Muon> (from the pipe) [14:25] <Muon> hmm [14:25] <Muon> some of the frames are skipped, but the playback appears to be slower than reality [14:45] <Muon> OK, seems it's treating it as a stream going at 25 FPS o_O [14:46] <Muon> I guess what I want is padding? [14:49] <Mavrik> ? [14:49] <Mavrik> padding? [14:50] <Muon> Mavrik: frames that are padding [14:50] <Muon> as in, duplication [14:51] <Muon> if we don't have a frame yet, and we need one, copy in the last one [14:51] <Mavrik> ah, padding usually means something else [14:51] <Muon> *shrug* [14:51] <Muon> this is just ridiculously annoying [14:52] <Muon> I was so happy when I managed to hack primusrun to dump frames to a pipe :( [16:12] <Muon> wait, I'm being silly [16:12] <Muon> I shouldn't be using a pipe [16:13] <Muon> a plain old file which is rewritten for every frame is enough [16:13] <Muon> the possibility of tearing does not concern me [16:13] <Muon> now how do I get this to re-examine a file all the time... [16:27] <bparker> what kind of video/image file has the header "frmh," ? [16:27] <bparker> I also see frma and frmv in the file [16:27] <bparker> it's an image sequence, but I think it might also contain audio [16:51] <Muon> right [16:51] <Muon> how do I limit the output FPS? [16:51] <Muon> uh [16:54] <Muon> http://pastie.org/private/ozurbzmy17xcbdmolvedq [16:54] <Muon> ^current command line and output [16:55] <Muon> as you can see it's running at about 42 fps even though -r 10 [16:59] <LithosLaptop> is shows 10... [16:59] <LithosLaptop> *it [17:00] <Muon> LithosLaptop: frame= 336 fps= 42 q=31.0 Lsize= 1693kB time=00:00:33.60 bitrate= 412.9kbits/s [17:02] <LithosLaptop> thats how fast it is encoding fps at, not the output fps [17:03] <Muon> LithosLaptop: which is important [17:03] <Muon> LithosLaptop: it's going to try to shove that down the internet stream at the same rate [17:07] <LithosLaptop> sorry I don't really understand, maybe somebdoy else could help. to me it seems like you are outputting to a file right? [17:08] <Muon> that's just for testing [17:09] <LithosLaptop> if somebody downloads it faster they still will playback the file at 10fps [17:09] <Muon> yes [17:09] <Muon> which means they will see slowed video [17:09] <Muon> the framebuffer can be sampled as much as you like [17:10] <LithosLaptop> does it look slow when you playback the file? [17:10] <Muon> yes [17:11] <LithosLaptop> ah [17:12] <LithosLaptop> you are saying your source is 10 fps [17:12] <Muon> my source is whatever FPS [17:12] <Muon> I just want it synced to my sound [17:12] <LithosLaptop> maybe move -r 10 after the input [17:13] <LithosLaptop> near the end of the command line [17:13] <Muon> tried that [17:13] <LithosLaptop> oh [17:13] <Muon> yeah [17:14] <Muon> it's running way to quickly [17:15] <Muon> *too [17:15] <Muon> but x11grab respects the settings [17:16] <LithosLaptop> wuthout -t 10 it works fine? [17:16] <LithosLaptop> I mean the duration [17:16] <LithosLaptop> *-r 10 [17:16] <Muon> no, -r 10 is my attempt at fixing this [17:17] <LithosLaptop> how many fps is the source? [17:17] <Muon> infinite [17:18] <Muon> I am just piping in a framebuffer-like file on loop [17:20] <LithosLaptop> its piping too fast [17:20] <Muon> obviously [17:20] <Muon> but fixing the rate doesn't help [17:20] <Muon> audio desynced [17:20] <LithosLaptop> so any ffmpeg settings would help [17:20] <LithosLaptop> *wont [17:21] <Muon> well, if you could somehow tell ffmpeg to read the framebuffery thing on loop [17:22] <LithosLaptop> yeah maybe [17:22] <Muon> this isn't very useful [17:22] <Muon> :( [17:23] <LithosLaptop> sorry I am not a ffmpeg guru [17:23] <LithosLaptop> I don't know where all the other people are [17:23] <LithosLaptop> maybe sleeping [17:23] <Muon> get the cattleprod [17:24] <LithosLaptop> can you maybe show how you are piping the raw video? [17:25] <Muon> LithosLaptop: not gonna be useful [17:25] <Muon> lemme see if I can hack up a loopy device [17:26] <Muon> because altering ffmpeg at 3:36 AM is totally sane [17:26] <LithosLaptop> haha [17:38] <Muon> seems it's gonna be easy to modify [17:38] <Muon> but sleepy [17:38] <Muon> curse youuuuu [17:38] <Muon> good night [19:23] <Sashmo> anyone have any luck with decklink SDI, HD sources and ffmpeg? [19:25] <Mavrik> hmm [19:25] <Mavrik> I only used HDMI source [19:25] <Mavrik> it worked on Windows through directshow [19:37] <Sashmo> any command line examples? [19:37] <Sashmo> my CPU is at 90% and its a monster machine, 12000 cpu benchmark points... and the video looks like crap [20:33] <Sashmo> does anyone know if there is a decomb filter for ffmpeg? google tells me nothing.... [20:34] <durandal_1707> decomb filter does what? [20:34] <Sashmo> like deinterlace [20:34] <Sashmo> but selective [20:35] <durandal_1707> selective on what? [20:36] <JEEB> IVTC you mean? [20:36] <Sashmo> http://pastebin.com/MqCBu6Sb [20:36] <JEEB> ubitux is porting vivtc from vapoursynth (which is a reimplementation of the avs TIVTC filter) [20:36] <JEEB> oh [20:36] <JEEB> Handbrake's decomb [20:37] <JEEB> that's an adaptive field matcher / deint filter IIRC [20:40] <durandal_1707> Sashmo: there is deinterleave filter in libavfilter/ffmpeg, its called il [20:41] <Sashmo> thanks I'll look into it [20:41] <JEEB> I /think/ yadif atm is the closest to what he wants [20:41] <Sashmo> is it the same as decomb? or similar? [20:41] <durandal_1707> JEEB: yadif is deinterlacer [20:41] <JEEB> yes, and that's what he wants, an adaptive deint/field match [20:42] <JEEB> and yadif is atm the closest to get that [20:42] <durandal_1707> no, from explanation he only wants deinterleaver [20:42] <durandal_1707> which is faster than deinterlacer [20:42] <JEEB> well decomb filter that he pastebin'd is slower [20:42] <JEEB> it's handbrake's EEDI2 + combing finding filter, which tries to be adaptive between field matching and deint [20:43] <JEEB> :V [20:43] <JEEB> so looking at that pastebin the closest ffmpeg has is yadif [20:43] <JEEB> but if you know better than I do... [20:43] <JEEB> sure [20:43] <JEEB> I don't know what his source is anyways (truly interlaced/hard telecine/whatever) [20:44] <durandal_1707> yes, you are right, there is no deinterleaving at all, i failed at reading [20:45] <durandal_1707> so he is actually looking for deinterlacer [20:45] <Sashmo> the byadif deinterlacer leaves ghosting [20:45] <Sashmo> yadif* [20:46] <llogan> are you using default settings? [20:47] <llogan> think of it as a feature. i hope it's a horror movie. [20:49] <Sashmo> umm, I've used in many ways, and really I get the same sort of result each time but filter:v yadif is the best that otuput [20:49] <Sashmo> BUT, its still leaving me some ghosting, specially on HD sources [20:50] <durandal_1707> what version you are using? [20:50] <durandal_1707> and what kind of HD sources is that (resolution, pixel format) [20:52] <Sashmo> SDi input HD 1080i, cant recall the pixel format [20:53] <durandal_1707> ffprobe output of some sort [20:59] <Sashmo> yuv420p is the format [21:03] <Sashmo> durandal_1707: what do you think? [21:04] <durandal_1707> fill bug report for better filter [21:04] <durandal_1707> otherwise nobody complains and code is left in status quo [21:05] <Sashmo> durandal_1707: thanks... I gues ;) [21:36] <grepper> The following works for me to output a frame every 5 minutes from an ntsc dvd video (for a static chapter menu): -filter:v select="not(mod(n\,8991))",setpts="N/(29.97*TB)" . What I am wondering is if its possible to output say 300 frames at interval N rather than just 1 frame ? [21:37] <durandal_1707> you mean each 5 minutes pick 300 frames? [21:38] <grepper> durandal_1707: sure, for example [21:38] <durandal_1707> yes its possible [21:39] <durandal_1707> read Expression Evaluation documentation [21:40] <grepper> I was afraid you would say something like that :) - I'm lost understanding filter theory, I was glad to find the above example with google [21:40] Action: grepper goes to look [21:43] <grepper> math is not my strong suit by a long shot, any hints durandal_1707 ? [21:51] <grepper> what is 'n' in the above filter: 'mod(n'? Current frame # ? [21:52] <durandal_1707> grepper: there are ld() - load variable and st() - store variable [21:52] <durandal_1707> grepper: 'n' is documented in select filter documentation [21:53] <durandal_1707> n - is the sequential number of the filtered frame, starting from 0 [21:54] <grepper> I see [21:55] <durandal_1707> and selecting 300 frames every 5 minutes could be done with some kind of periodic function like sin/cos [21:56] <durandal_1707> but that is far from user friendly - requiering non-trivial math knowledge is not feature [21:57] <durandal_1707> but you could do same with ifs,st,ld - which is ugly somehow [21:58] <durandal_1707> also there may be better solution .... [22:03] <grepper> okay thanks, I'll see if I can make heads or tails out of it [23:17] <esdf> hi, how can i convert from flv, mp4, avi and wmv to .webm at same quality? (sameq ain't really same quality) [23:22] <sacarasc> Same quality as what? [23:37] <smus_> trying again, small riff on the main video_encode_example: http://pastebin.com/M5VuHM9b except the outbuf that's populated by avcodec_encode_video is all zeros. out_size > 0 and seems valid though. any ideas what's going on? [23:38] <esdf> sacarasc as source [23:38] <esdf> well, at least higher then youtube quality [23:44] <UukGoblin> hi [23:44] <UukGoblin> I'm trying to set up some streaming of my desktop [23:44] <UukGoblin> my current problem is that ffplay doesn't seem to play anything [23:44] <UukGoblin> I've set up a simple avserver [23:45] <UukGoblin> ffmpeg seems to grab fine (grabs especially well to a file) [23:45] <UukGoblin> is avserver the way to go? Man page says it's unmaintained and broken :-/ [23:45] <gmaxwell> UukGoblin: perhaps your video needs better timestamps? [23:45] <UukGoblin> Hi gmaxwell :-) [23:46] <UukGoblin> I've no clue about any timestamps :-) [23:46] <UukGoblin> let me paste my stuff [23:47] <llogan> esdf: https://ffmpeg.org/trac/ffmpeg/wiki/vpxEncodingGuide [23:47] <llogan> would be a good start [23:48] <UukGoblin> http://pastebin.com/SeWj77P0 <- these are my attempts so far [23:48] <llogan> UukGoblin: avserver is not from FFmpeg [23:48] <UukGoblin> oh :-/ [23:49] <UukGoblin> gmaxwell, I've just got your joke, lol [23:50] <esdf> ty llogan [00:00] --- Sat Mar 30 2013

1 0

ffmpeg-devel.log.20130328
by burek 29 Mar '13

29 Mar '13

[00:34] <saste> llogan, status? :) [00:35] <saste> i'm going to ping mentors / backup mentors, and I'll fill the missing backup mentors with myself tomorrow [00:39] <llogan> saste: i'm re-working the "getting started" section now. [00:40] <saste> llogan, thanks [00:40] <saste> i realize i mixed second and third person when writing the text [00:40] <Daemon404> i can mentor or backup mentor <something> [00:40] <Daemon404> i have no preference [00:40] <saste> probably no-one will notice that anyway [00:40] <saste> Daemon404, anything specific? [00:40] <Daemon404> let me look at the list [00:41] <llogan> saste: i'm s/task/project/g (except qualification task). "project" sounds more like fun and "task" sounds more like work. [00:42] <saste> llogan: s/task/funtask/ [00:42] <Daemon404> yeah no preference really [00:42] <Daemon404> apng sounds fairly easy. [00:43] <Daemon404> also [00:43] <Daemon404> "a controller filter which allows to send commands to other filters (e.g. to adjust volume, contrast, etc.), e.g. like the sendcmd filter but through an interactive GUI" [00:44] <Daemon404> wouldnt this make more sense as a GUI using lavfi [00:44] <Daemon404> using a filter itself for the gui sounds insane [00:44] <saste> Daemon404, sounds like a funny proof of concept [00:44] <saste> Daemon404, ideally that could be done with lua scripting, once we have it [00:45] <Daemon404> heh [00:45] <Daemon404> like i said before [00:45] <Daemon404> the only idea i had was way too hard for a SoC student [00:45] <Daemon404> or perhaps even mortals [00:45] <saste> Daemon404, what? [00:46] <saste> understanding nut specs? [00:46] <Daemon404> "fix" libavformat so it can properly handle virtual timelines [00:46] <Daemon404> liek edit lists in mp4 [00:46] <Daemon404> or matroska timelines [00:46] <saste> Daemon404, what about accurate seeking in libavformat? [00:46] <saste> otoh i don't know if that's really feasible, but definitively a popular request [00:47] <Daemon404> its feasible [00:47] <Daemon404> ffms2 achieves this [00:47] <Daemon404> you just need a higher level api [00:47] <Daemon404> which indexes [00:48] <saste> Daemon404, do you want to propose a funtask for that, or you prefer to co-mentor some already existing ones? [00:48] <Daemon404> i dont know if i like either idea for lavf [00:48] <Daemon404> cause that means the SoC sudent designs a public API [00:48] <Daemon404> history shows thats not a Great Idea [00:49] <saste> Daemon404, yes i tend to agree... [00:49] <saste> ideally coding tasks with a well defined area are favored [00:50] <Plorkyeran> if you limit it too frame accurate seeking and punt on audio there's not too much space for them to fuck up [00:50] <Plorkyeran> but yeah, gsoc api design sounds like a terrible idea [00:50] <Daemon404> saste, perhaps a small idea for the lavfi task: vf_vapoursynth.c [00:51] <Daemon404> its liekly not much work [00:51] <saste> Daemon404, if you can help that's perfectly fine [00:51] <Daemon404> i can [00:52] <saste> i can help that to the ideas list for the lavfi-task [00:52] <Daemon404> s/help/add/ ? [00:52] <saste> Daemon404, wtf yes [00:52] <Daemon404> ok [00:52] <Daemon404> Plorkyeran, iirc a gsoc api design is how lavfi came to be [00:53] <Daemon404> or so the Old Ones have told me [00:57] <cone-985> ffmpeg.git 03Michael Niedermayer 07master:c6831e2a70f7: wavpack: check K, fix assertion failure [00:57] <cone-985> ffmpeg.git 03Michael Niedermayer 07master:a56d963f111b: vp3: Check fps validity more completely [00:58] <Daemon404> oh lord [00:58] <Daemon404> mysterious j00ru fixes again [00:59] <Daemon404> michaelni, what is "k" in "k is too large" [00:59] <Daemon404> no value k is checked [01:00] <Daemon404> just "add" [01:04] <michaelni> Daemon404, the argument of get_tail() its k [01:05] <llogan> do they just contact you directly? [01:08] <Daemon404> well that doesnt really explain what k is [01:08] Action: Daemon404 shrugs [01:10] <michaelni> k is a parameter to the vlc reading function, its always called k [01:10] <llogan> i need some trolls to look at the "getting started" and "qualification task" sections and tell me what is unclear/retarded [01:10] <llogan> http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_of_Code_2013 [01:11] <Daemon404> a lot of other things are called k too. heh. [01:11] Action: Daemon404 goes to grab food [01:11] <wm4> Daemon404: don't you like hating on mplayer stuff? http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2013-March/071551.html [01:11] <wm4> I like how he defends this convoluted crap called "direct rendering" [01:12] <wm4> which is completely horrible compared to refcounted images [01:12] <Daemon404> fun stuff. i do use DR, but not for what mplayer does. [01:12] <Daemon404> an it is very convolued. [01:13] Action: Daemon404 really foods now [01:13] <wm4> mplayer's filter chain basically works by the same principles as what you know as DR in ffmpeg [01:13] <wm4> it makes the simplest filters hilariously complex [01:15] <saste> llogan, looks much better to me [01:15] <saste> but i'm no troll [01:15] <saste> i'll have another look at it tomorrow [01:17] <llogan> saste: i've been looking at it too long now. a sentence on "3. apply" explaining that a student that completes a qual task will more likely be picked...or similar [01:17] <llogan> would be a good addition [01:18] <llogan> but i think i'm basically done. [01:25] <michaelni> llogan, "visiting our our IRC" [01:26] <michaelni> "Feel free to ask any questions you may have." <--- is it clear "where" ? [01:26] <michaelni> "projects are are additional" [01:28] <michaelni> mixed person first "Contact us. If you find a project that you are interested in " then "and a qualification task will show us that the student is motivated" [01:31] <michaelni> "If you are new to FFmpeg, and have relatively small experience" -> little experience id say [01:34] <michaelni> is "Optional goodies: " supposed to look bold like the other headings ? [01:41] <llogan> thanks. These are are now fixed. except for "optional goodies"; i don't think it needs bold [01:49] <highgod> Hi, michaelni, are you on line? [02:07] <michaelni> highgod, yes [02:10] <wm4> so, would it be possible to multithread libavfilter? so that, if enough frames are queued via buffersrc or so, libavfilter will automatically distribute the work load over multiple threads if possible [02:11] <wm4> this would require filters to report if they are thread-safe and whether there are dependencies between frames, I think [02:11] <cone-985> ffmpeg.git 03Michael Niedermayer 07master:1831274ff1ef: electronicarts: check timebase, fix assertion failure [02:11] <cone-985> ffmpeg.git 03Michael Niedermayer 07master:ea9a6709a941: estimate_timings_from_bit_rate: Check timebase and bitrate [02:13] <highgod> Hi, michaelni, about the opencl patch "this should be where the other OBJS-$(...) are" I don't get what it mean, shouldn't it be comliled when set opencl [02:13] <michaelni> wm4, everything is possible [02:14] <michaelni> highgod, there are several lines in the Makefile that look like "OBJS-$(...)" the one you add should be added closer to them [02:14] <michaelni> thats purely cosmetical difference [02:14] <highgod> OK [02:17] <highgod> and you said ffmpeg will compile all the kernel, I don't think it is a problem, it does not cost much time [02:19] <highgod> and about one command queue for each kernel is not need, if like this, it will awaste of resource [02:22] <highgod> about the thread problems, you said the empty function, I think the macro HAVE_MEMORYBARRIER HAVE_SYNC_VAL_COMPARE_AND_SWAP HAVE_MACHINE_RW_BARRIER have the system ensure for this, is it right? I reference the atomic code [02:29] <michaelni> it doesnt cost much time with just one filter [02:30] <michaelni> when there are many filters this design will become annoying [02:30] <michaelni> especially on embeded hardware [02:31] <michaelni> the command que changing functions from openCL are not thread safe [02:32] <michaelni> so if theres just one then all access to it needs to be under a global mutex [02:33] <michaelni> but the accesses are all set to blocking so it would be blocking with a locked global mutex [02:33] <michaelni> thats not good design [02:35] <michaelni> about the empty lock function, if its empty its empty and doesnt lock [02:35] <michaelni> so no concurrency is possible in that case [02:36] <michaelni> it basically means opencl will only work when pthreads are available or there are no threads [02:42] <michaelni> said differently the current code will randomly fail with threading systems other than pthreads [02:45] <wm4> shouldn't thread-safety be the concern of the caller then? [02:46] <wm4> like it's with everything [02:46] <michaelni> wm4, who is the caller ? [02:46] <michaelni> the avfilter? [02:46] <michaelni> if so it would need a lock shared with all other possible users of the opencl code [02:47] <michaelni> other filters, maybe codecs , ... [02:47] <j-b> what's up? [02:47] <wm4> the one creating the opencl context is obviously the one responsible, then [02:47] Action: j-b kicks cone-985 [02:48] <michaelni> wm4, the context gets created by the first filter using it and reused by all others IIRC [02:49] <michaelni> or one could say the opencl code in libavutil creates the context [02:50] <michaelni> but its missing some locks still [02:51] <highgod> michaelni:about the compile time, we have a way that compile all kernel in one time and write the compile info in a binary file, when ffmpeg run the second time, it just load the binary file and use with out compile, but you have said it is not safe. we will implement this later [02:52] <highgod> michaelni:so I think we can do it as what we do now, and add optimize it later [02:52] <wm4> actually the nvidia driver on Linux caches OpenGL shader compilation on disk transparently [02:53] <highgod> as you said, there are not many kernels now, if we change the method, it will make the compile operation more complex [02:57] <michaelni> If we end up having to change later it will be more work [02:58] <michaelni> also compiling after registration might allow optimizations like having user specified parameters be constants in the compile, i dont know if that makes any sense though performancewise [02:59] <michaelni> anyway i can live with the monolithic load and compile if its hard to make it more fine grained [03:00] <michaelni> but can you explain what is the added complexity that would have ? [03:04] <highgod> we want to implement as the binary file to optimize the compile operation whitch can make ffmpeg compile just once. it should compile all kernels in ffmpeg. it is the best way to compile operation [03:04] <oneal> assuming there are two caller, the firest caller has 3 kernels, the second caller has 4 kernels, if every caller need to compile and load it, then both of the 2 kernels need to run 2 compiler and load, the time for running 2 compile is longer than running 1 compile. [03:06] <oneal> Yes, like what's hihdgod said, OpenCL kernel compile can genenrate a bin file which is a Intermediate code. there is a time reduction when building the kernel from the binary [03:07] <oneal> now OpenCL have tow compile procedure, one the compile from kernel source code, like the c compiler, another is compile from the binary which is generated by the pre-compile. [03:09] <oneal> the binary is a Intermediate code, this must be to be interpreted by OpenCL runtime. [03:09] <highgod> michaelni:about the golobal context and command queue, we have tested that it is safe for multi-threads [03:09] <highgod> so we use like this [03:09] <oneal> so the security of the binary code has a security guarantees [03:11] <michaelni> the documentation explicitly states that its not safe [03:11] <michaelni> "OpenCL API calls [03:11] <michaelni> that queue commands to a command-queue or change the state of OpenCL objects such as [03:11] <michaelni> command-queue objects, memory objects, program and kernel objects are not thread-safe. [03:11] <michaelni> " [03:12] <michaelni> and you cannot "test" thread saftey [03:13] <michaelni> it can work a million times and crash the million+1 time [03:14] <oneal> the commands in the command queue can change the status of OpenCL time. such as the status mechine. [03:15] <oneal> for every signle OpenCL objects, such buffer, command queue, context, it is not the thread-safe [03:16] <oneal> the user application must to do the mechanism in multi-thread sence. [03:21] <michaelni> the user application has no means to do it, it doesnt access filters one by one [03:21] <michaelni> it pushes things into a filter graph [03:22] <michaelni> consider a codec using opencl and a filter using opencl [03:22] <michaelni> if the user application would do sync that would mean it could not run any filter or any codec at the same time as any other [03:23] <michaelni> also that would break current API & ABI which allows codecs & filters to run at the same time [03:24] <highgod> michaelni, I don't get what you mean, I have test two opencl kernels in this way [03:25] <michaelni> highgod, undefined behavior is undefined behavior you cant test it. It can work perfectly now and break with a different hardware or different driver revission or maybe you are just lucky [03:25] <michaelni> today [03:26] <michaelni> That is if we agree that the documentation does say that this is not ok [03:27] <wm4> michaelni: so the entire problem is that opencl is somehow global... is that because opencl forces you to, or other reasons? [03:27] <highgod> michaelni, the document you mean OpenCL Specification Version: 1.2? [03:28] <michaelni> hmm, seems its 1.0 [03:28] <michaelni> where can i find 1.2 ? [03:31] <highgod> I will send you one [03:34] <michaelni> I found www.khronos.org/registry/cl/specs/opencl-1.2.pdf [03:38] <highgod> michaelni, I have sent it to you [03:41] <michaelni> highgod, it seems 1.2 extends thread saftey to all functions [03:43] <michaelni> so it should be ok without locks on the que access if i understand it correctly [03:44] <michaelni> that leaves the empty locks in absence of pthreads [03:48] <michaelni> i guess for now you could make pthreads a dependancy of the opencl code [04:03] <highgod> ok,michaelni. [04:04] <highgod> Hi, michaelni, do you mean I can delete the lock_opencl function? [04:07] <michaelni> you could use pthread_mutex_lock() directly for now yes, maybe later if you want to support other threading systems we need to find another solution, we do have some generic lock manager bit its in avcodec not avutil ... [04:08] <highgod> michaelni, do you mean the command queue and context don't need the muti-thread, right? [04:09] <cone-985> ffmpeg.git 03Michael Niedermayer 07master:10ece44d0948: h264_cavlc: fix assertion failure due to reading too long vlc [04:09] <cone-985> ffmpeg.git 03Michael Niedermayer 07master:e234daa5180f: mlpdec: Fix reading state with 0 bit elements. [04:10] <michaelni> highgod, the concern i had was based on the 1.0 spec, the 1.2 spec makes more gurantees so it could be ok i dont know opencl well enough to say for sure [04:11] <llogan> i wonder why -vf works with ffplay but -filter:v is not recognized. [04:14] <michaelni> llogan, probably because of "grep '"filter"' ffplay*c ffmpeg*c" [04:14] <llogan> i guess i could have tried that. [04:17] <highgod> michaelni,and about the compile operation, can you accept the recent way? it can be use in the binary way, if we change it, we will change back when we use the binary way. it add works [04:25] <michaelni> I think its pretty much the decission of the maintainer (which would be you) if you want to support fine grained compile&load [04:26] Action: michaelni falls asleep [05:38] <ubitux> < michaelni> ubitux, a bit early ;) but n8 // right, but seems i woke up early too :) [08:26] <ubitux> michaelni: when merging the fate tests from libav, please keep our own (even if you add the ones from them) [09:11] <highgod> why I use the sdl to compile ffplay on mingw, then the output of ffmpeg is disappear? [09:14] <av500> ? [09:16] <highgod> I install sdl to compile ffplay on mingw,than all the output info of ffmpeg and ffplay is now show on the screen [09:18] <highgod> I install sdl to compile ffplay on mingw,than all the output info of ffmpeg and ffplay is not show on the screen [09:35] <highgod> ?? [09:36] <ubitux> highgod: a user was complaining about such thing a few days ago [09:36] <ubitux> might be a bug [09:36] <ubitux> none of the developers are working with mingw afaik, so you're on your own [09:37] <highgod> I tried other computers [09:37] <highgod> the same errpr [09:37] <highgod> error [09:37] <highgod> is is a bug of sdl or ffmpeg? [09:38] <ubitux> i don't know, most likely mingw [09:49] <funman> highgod: ffmpeg as well? but it's not built with sdl, only ffplay [09:50] <highgod> but ffmpeg's out put is disappear too [09:51] <funman> i guessed console vs Gui windows application [09:51] <funman> on windows if you have a GUI application it can not write to the console anymore [09:51] <highgod> so if I unstall sdl, it will fix? [09:52] <funman> i don't really understand what 'no output' means [09:52] <highgod> the out put information of ffmpeg and ffplay, [09:53] <funman> like copyright, help? [09:53] <funman> you're running it in cmd.exe? [09:54] <ubitux> < funman> on windows if you have a GUI application it can not write to the console anymore // wat? oO [09:54] <ubitux> seriously? :D [09:54] <funman> not with cmd.exe at least [09:54] <funman> with some msys terminals/shells combos it works [09:56] <funman> The Windows GUI development doesn't conveniently support the access to cout, cerr, stdout, or stderr. It may be difficult to obtain these under direct control of the window program. At least there exist some tricks to obtain the information if really needed. [11:03] <cone-938> ffmpeg.git 03Janne Grunau 07master:d767e2f96993: configure: fix dependencies of XvMC and old vdpau mpeg2 decoders [11:03] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:021547bfcc90: Merge commit 'd767e2f969933b4e450ed4e69ea2bf8ca864838c' [11:09] <cone-938> ffmpeg.git 03Janne Grunau 07master:757d85868b77: vdpau: fix obsolete mpeg1 vdpau decoder when mpeg2 is disabled [11:09] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:7609d42d0f46: Merge commit '757d85868b77c4fdec7b77a3b7de1faf16c031e8' [11:19] <cone-938> ffmpeg.git 03Janne Grunau 07master:b24725392977: vdpau: wrap codec specific functions in appropiate #ifs [11:19] <cone-938> ffmpeg.git 03Diego Biurrun 07master:1db6a080bddd: dca: Move ff_dca_convert_bitstream() to the DCA common code [11:19] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:b1064dd783b2: Merge commit '1db6a080bddd14fed6b29140ecd2e21e42b1c022' [11:25] <cone-938> ffmpeg.git 03Diego Biurrun 07master:b6649ab5037f: cosmetics: Remove unnecessary extern keywords from function declarations [11:25] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:63a97d56748a: Merge commit 'b6649ab5037fb55f78c2606f3d23cea0867cdeaa' [11:36] <cone-938> ffmpeg.git 03Diego Biurrun 07master:eee2000b4123: mpeg12: Move some ff_mpeg1_* function declarations to a more suitable place [11:37] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:385ffc7650d2: Merge commit 'eee2000b41234ae9465c314e18bfec1700181f32' [11:53] <cone-938> ffmpeg.git 03Diego Biurrun 07master:1b6d66745ac1: Split MPEG-1/2 decoder code off from MPEG-1/2 common code [11:53] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:016c00cf68a4: Merge commit '1b6d66745ac1768adb387c2227cdcf4452271149' [12:00] <cone-938> ffmpeg.git 03Diego Biurrun 07master:e557584aa7df: mpeg12: Move Mpeg1Context declaration to the only place it is used [12:00] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:2bfcd74ad3e3: Merge commit 'e557584aa7df6ac9f52af7ee7e5c963437da2e2f' [12:09] <ubitux> ok, only documentation left for ivtc [12:10] <ubitux> that was more painful than i imagined [12:12] <cone-938> ffmpeg.git 03Martin Storsjö 07master:3891a270f5b4: msmpeg4: Split decoding related functions to a separate file [12:12] <cone-938> ffmpeg.git 03Diego Biurrun 07master:b4d24b471bc5: build: Remove configure-generated .config file on distclean [12:12] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:2b6185cac945: Merge commit 'b4d24b471bc52f1f78a43ee330199e70483e51c3' [12:16] <wm4> ubitux: what was painful? [12:17] <ubitux> wm4: understanding, and different filtering logics [12:17] <cone-938> ffmpeg.git 03Diego Biurrun 07master:7c22d0489fa4: build: Move setting of SRC_DIR to the only place it is used [12:17] <cone-938> ffmpeg.git 03Kostya Shishkov 07master:472391b9a7e1: ape: use correct context for the bit table printed in debug [12:17] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:dac1d92cb757: Merge commit '472391b9a7e15e3bff33b016e7b6dbfa6a555975' [12:18] <wm4> I still don't get why ffmpeg needs a port of this, but whatever [12:23] <ubitux> since you don't want to understand, i won't repeat myself for the nth time :P [12:24] <wm4> you're doing it for fun and to learn [12:25] <ubitux> you forgot some important points [12:25] <wm4> and because ffmpeg needs an ivtc filter [12:25] <cone-938> ffmpeg.git 03Martin Storsjö 07master:cfe5908a72e7: configure: Add error_resilience as dependency to the eatqi decoder [12:25] <cone-938> ffmpeg.git 03Reimar Döffinger 07master:e9cc98839574: win32: Allow other programs to open the same files [12:25] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:e63ebaca16b7: Merge commit 'e9cc98839574c7e8d546e890ebbf57d1766e5d8a' [12:26] <ubitux> we should be able to drop mp={detc,divtc,filmdint,pullup,ivtc} after this btw [12:32] <ubitux> there won't be much filters left in the mp wrapper [12:32] <ubitux> likely eq2, mcdeint and spp will be relevant [12:32] <ubitux> that will be quite an achievement :) [12:32] <ubitux> wm4: and so for the nth time, the main argument of using a vsynth wrapper instead of a native ivtc filter is that it will be a huge pain for users to have a ffmpeg build with an ivtc [12:32] <ubitux> unless we copy/paste source code from vsynth and write a wrapper just like mp [12:32] <ubitux> and i'd like to avoid that. [12:32] <ubitux> also, writing a vsynth wrapper won't be that trivial [12:32] <ubitux> IMO [12:32] <ubitux> and since no one wants to do it, i'd better have a native ivtc filter and everyone will be happy [12:33] <ubitux> especially after dropping 4.5k code of unused ivtc code in the mp wrapper [12:33] <wm4> lol using that as argument [12:33] <ubitux> wm4: do you understand now or i will need to repeat myself in 2-3 days? [12:34] <cone-938> ffmpeg.git 03Reimar Döffinger 07master:ad04025987e5: win32: Make ff_win32_open more robust [12:34] <cone-938> ffmpeg.git 03Hendrik Leppkes 07master:85a46ad68504: win32: Use 64-bit fstat/lseek variants for MSVC as well [12:34] <cone-938> ffmpeg.git 03Anton Khirnov 07master:cf53704c5537: AVOptions: make av_set_options_string() forward options to child objects [12:34] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:fd37a7dc3c1b: Merge commit 'cf53704c55378cc0dcfc16637cdac7d58f0b3107' [12:34] <wm4> so when will you fix that users have to go through pain to build ffmpeg with h264 encoder enabled? [12:35] <ubitux> wm4: what are you talking about? [12:35] <ubitux> libx264 is packaged all over [12:35] <wm4> so what until vapoursynth gets more popular? [12:36] <wm4> *wait [12:36] <ubitux> i don't know if it will ever happen in the next month [12:36] <ubitux> it took me 1-2 week to port the filter [12:37] <ubitux> i wonder why you insist so much on having a vsynth wrapper [12:37] <ubitux> just write it if you want it [12:38] <ubitux> ivtc is an essential feature, it belongs to the libavfilter core [12:38] <wm4> because I think it'd be much better to help a young project (with the potential to become as powerful as avisynth), rather than sabotage it by porting away the useful bits? [12:38] <ubitux> wm4: do you think we should have linked against pulseaudio for af volume because pulseaudio already had some volume normalization assembly code? [12:38] <kierank> There are other people who'd like to use filters outside of an avisynth style framework [12:39] <ubitux> wm4: oh so that is your actual concern? [12:39] <wm4> ubitux: if you want to make a comparison, why don't you do that with frei0r or sox? [12:39] <ubitux> we actually do [12:40] <wm4> ubitux: that, and also that porting it and having it maintaining it yourself makes 0 sense [12:40] <ubitux> we have a wrapper, but we are writing a lot of features into ffmpeg as builtin [12:40] <ubitux> wm4: you know what is the purpose of the project right? [12:40] <wm4> NIH on steroids? [12:41] <ubitux> this is not NIH, it's a port [12:41] <ubitux> with full credits [12:42] <ubitux> wm4: i don't think it's relevant to prevent adding features in ffmpeg because it will kill younger projects [12:42] <ubitux> and if vsynth is a good project, that will certainly not kill it [12:42] <ubitux> i believe it's strength is not only in having useful filters ported [12:43] <ubitux> but more like having python scripting, and a filtering scripting appreciated in various communities [12:44] <ubitux> wm4: we should also not ever add frame seeking in ffmpeg because ffms2 has this feature, and it will kill it if we add the feature to ffmpeg? [12:44] <ubitux> that argument is silly imo [12:44] <ubitux> now if you don't mind, i'm going to add the documentation to the filter, which is not present in vsynth [12:44] Action: ubitux & [12:44] <wm4> don't worry, ffmpeg's API will always be convoluted and tricky enough that ffms2 will be needed [12:45] <ubitux> and lavfi will be always trolled for its filtergraph, so no worry vsynth won't die [12:45] <wm4> you mean http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2012-October/132031.html ? [12:46] <ubitux> speaking of this, we did quite some improvements [12:59] <cone-938> ffmpeg.git 03Paul B Mahol 07master:705b607db88f: lavfi/biquads: fix min allowed option value [13:04] <ubitux> durandal_1707: you should give credits to the guy in these cases [13:05] <durandal_1707> really, ask guy to send real patch [13:05] <durandal_1707> and his name is not in ascii [13:05] <ubitux> mine isn't either :) [13:05] <ubitux> he actually sent a patch, not in a proper form right, but a patch anyway [13:06] <ubitux> you could have at least mentioned it in the commit description :p [13:11] <cone-938> ffmpeg.git 03Anton Khirnov 07master:a4208b9b7d62: avconv: add options for reading filtergraphs from a file. [13:11] <cone-938> ffmpeg.git 03Diego Biurrun 07master:f2a59722d161: fate: filter: Add dependencies [13:11] <cone-938> ffmpeg.git 03Clément BSsch 07master:8b9a153ef367: lavfi/gradfun: do not increment DC pointer for odd values. [13:11] <cone-938> ffmpeg.git 03Clément BSsch 07master:2d66fc543b01: lavfi/gradfun: fix rounding in MMX code. [13:11] <cone-938> ffmpeg.git 03Clément BSsch 07master:38a2f88d39e5: lavfi/gradfun: fix dithering in MMX code. [13:11] <cone-938> ffmpeg.git 03Clément BSsch 07master:1ae44c87c924: lavfi/gradfun: remove rounding to match C and SSE code. [13:11] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:ac1a1fd7088c: Merge commit '1ae44c87c924b69a0657256fbaa8ad140df2f27c' [13:30] <jojva> can someone explain to me what is expected from a project of gsoc ? Would it be possible for me to have a summer job and contribute on ffmpeg only when I have the time ? Or is it expected that gsoc is a kind of "full-time" job ? [13:31] <durandal_1707> its not full time job [13:32] <durandal_1707> it does not need to be one... [13:33] <ubitux> jojva: i remember stefano saying the students were expected to work around 6-8 hours per week [13:33] <ubitux> depending on the project it might be required to work more [13:33] <jojva> mvc is quite big... and i'm already working more than 6h/week on it [13:34] <ubitux> you'll have about ~3 months [13:34] <Compn> jojva : you are working on h264 mvc for ffmpeg ? [13:34] <Compn> if so we should probably take mvc off our gsoc list... [13:35] <jojva> i can't say i'm working FOR ffmpeg right now, it's a project I'm doing for university [13:35] <ubitux> Compn: or he could do it as a student. [13:36] <Compn> ubitux : sure [13:37] <ubitux> he looks like the perfect candidate to me [13:38] <av500> doing something for uni and gsoc in parallel? [13:39] <Compn> jojva : mvc (and hevc) is probably the biggest task [13:39] <jojva> I must say that my first priority is to get a paid job (I have a rent^^), but then implementing mvc could be a great thing (and also on my resume) [13:39] <jojva> I guess so [13:40] <jojva> Although with MVC I don't even have to know how cabac/cavlc work [13:40] <Compn> :) [13:40] <jojva> but still big [13:41] <jojva> av500 : not in parallel, the uni project started a month ago and will be finished in a few eeks [13:41] <av500> ok [13:43] <jojva> I mean the decoder won't be finished, it's just the time we have to do a bigger project (film an object like a skull head with a 3D cam, decode the video, compute the depthmaps then output a 3D model) [13:44] <Compn> people film 3d on youtube using two webcams :) [13:44] <Compn> ehe [13:44] <Compn> and mplayer/ffmpeg stereo3d filter [13:45] <jojva> what do you mean ? [13:45] <jojva> and btw, do not take mvc off the gsoc list [13:45] <jojva> it's still relevant [13:46] <Compn> i mean you can use any 2 regular cameras and combine the video together later using filters [13:46] <Compn> dont need a special 3d camera... [13:47] <Compn> with dumb 3d h264 codec :P [13:47] <jojva> I know, but this decoder needs to be done anyway [13:47] <Compn> yep yep [13:47] Action: Compn afk [13:48] <jojva> Spec was released in 2009 I think, I was really surprised when I learnt it wasn't implemented [13:49] <jojva> I guess it's because 3D is a dead fish [13:49] <jojva> not the good expression, I meant it's dead before it was born [13:51] <durandal_1707> i dont think 3d is dead [13:54] <jojva> it's tiring, some people can't see it, it's more expensive for a 'meh' result... [13:54] <av500> one eyed people cannot see it [13:54] <av500> the whole real world is wasted on them [13:54] <jojva> poor cyclops [13:55] <durandal_1707> when was last time you go to cinema? [13:55] <cone-938> ffmpeg.git 03Anton Khirnov 07master:7cec12748a37: FATE: add a test for the gradfun filter [13:56] <cone-938> ffmpeg.git 03Anton Khirnov 07master:a222997650eb: FATE: add a test for the boxblur filter [13:56] <cone-938> ffmpeg.git 03Anton Khirnov 07master:feb4922b257e: FATE: add a test for the drawbox filter [13:56] <cone-938> ffmpeg.git 03Anton Khirnov 07master:1a6d4bd7b607: FATE: add a test for the fade filter [13:56] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:6f1a6a9f6ba0: Merge commit '1a6d4bd7b60761bd7d955011ce7df4dd6b87b497' [13:56] <jojva> Django but it was 2D [13:57] <nevcairiel> i saw a 3d movie 2 weeks ago, and maybe the cinema i go to just sucks, or its an inherent 3d problem, but i think it just looks terribly blurry [13:57] Action: nevcairiel prefers a 2D screening any day [13:57] <durandal_1707> perhaps you hand poor glasses [13:57] <nevcairiel> whatever glasses they hand out [13:58] <nevcairiel> in fact, another 3d movie tonight [13:58] <durandal_1707> or maybe your left and right have different zooming [13:58] <jojva> I'm just hoping we'll arrive soon to hologram cinemas, this will be actual, real, beautiful 3d, but when ? [13:58] <nevcairiel> i actually bought my own glasses now because theirs are terribly uncomfortable as well, maybe it'll be better [13:58] <ubitux> michaelni: are there some more stuff to merge in tests/fate/filter.mak or i can start updating our tests with the dep helpers in it? [13:59] <durandal_1707> ubitux: gonna write test for other filters? [13:59] <ubitux> i plan to add a video output test for ebur128 but that's all [14:00] <ubitux> but i'd like to use the filter macro helper in that file to start with [14:00] <michaelni> ubitux, a few more to merge left [14:00] <ubitux> michaelni: ok [14:01] <ubitux> michaelni: can you nudge me when you're done with it? [14:01] <ubitux> (there is no hurry) [14:03] <michaelni> ubitux, ok [14:06] <ubitux> thx :) [14:10] <cone-938> ffmpeg.git 03Anton Khirnov 07master:ad85e8d9a5bb: FATE: add a test for the unsharp filter [14:10] <cone-938> ffmpeg.git 03Anton Khirnov 07master:0bdbd85e47f2: FATE: add a test for the transpose filter [14:10] <cone-938> ffmpeg.git 03Anton Khirnov 07master:71f3ede24e8c: FATE: add a test for the hqdn3d filter [14:10] <cone-938> ffmpeg.git 03Anton Khirnov 07master:ea290d919a52: FATE: add a test for the setpts filter [14:10] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:8823ec4f9e92: Merge commit 'ea290d919a52f0f8c7e30d69328bb011ed13f61a' [14:18] <durandal_1707> there is no api to draw font in lavfi? [14:18] <durandal_1707> ebur128 does something on its own [14:22] <ubitux> yes it's using an exported charmap [14:22] <ubitux> there are one or two functions available, but they couldn't be used in this case [14:26] <ubitux> durandal_1707: the other solution was to use fontconfig and stuff just like drawtext [14:27] <ubitux> but it was a real pain [14:27] <ubitux> totally overkill :p [14:34] <cone-938> ffmpeg.git 03Anton Khirnov 07master:3d8c80b611aa: FATE: add a test for the overlay filter [14:34] <cone-938> ffmpeg.git 03Anton Khirnov 07master:f91742037863: FATE: add a test for the negate filter [14:35] <cone-938> ffmpeg.git 03Anton Khirnov 07master:33942b7bdeda: FATE: add a test for the channelmap filter [14:35] <cone-938> ffmpeg.git 03Anton Khirnov 07master:43a8333a16c7: FATE: add a test for the channelsplit filter [14:35] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:7a14564b2d4d: Merge commit '43a8333a16c796b3d855fb3aaa742103cb62731f' [14:35] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:acaee26008c1: af_channelsplit: set output channels, fix assertion failure [14:56] <ubitux> it would be nice to have a AV_OPT_TYPE_BOOL.. [14:57] <Plorkyeran> @ubitux> wm4: we should also not ever add frame seeking in ffmpeg because ffms2 has this feature, and it will kill it if we add the feature to ffmpeg? <-- as the activest developer of ffms I would be fucking delighted if I could delete 90% of it and leave just a thin wrapper for a better API [14:58] <ubitux> :) [14:58] <wm4> so will we get that exact frame seeking? [14:58] <Plorkyeran> killing other projects by making them redundant is great as long as they're not just replaced by something worse that isn't quite bad enough to be unusable [14:59] <durandal_1707> wm4: once you send patch [14:59] <wm4> k [14:59] <ubitux> Plorkyeran: any reason you didn't try to integrate the feature to ffmpeg? [14:59] <wm4> ffms2 also provides a stable API AFAIK [14:59] <Plorkyeran> at the minimum it'd require completely rewriting it since it's C++ [15:00] <Plorkyeran> and I don't particularly like writing C [15:00] <ubitux> ok [15:00] <Plorkyeran> and contributing a new higher-level API to ffmpeg seems like a good way to get stuck in bikeshed hell [15:00] <ubitux> Plorkyeran: how much code does it represent approximately? [15:01] <Plorkyeran> not a ton [15:01] <TheFluff> it's probably less than 10k lines [15:01] <Plorkyeran> cloc says 7.6k code, ignoring avisynth/vapoursynth plugins [15:01] <TheFluff> probably less than 5k even if you only count the really relevant stuff [15:01] <TheFluff> right [15:02] <TheFluff> does that count matroskaparser.c? [15:02] <TheFluff> because that's like 2-3k right there [15:02] <ubitux> it supports frame seeking in any formats? [15:02] <Plorkyeran> yeah [15:02] <Plorkyeran> 2.7k [15:02] <Plorkyeran> so more like 5k [15:03] <ubitux> so there is a generic frame seeking, and dedicated code for some formats? [15:03] <ubitux> afaik the api is ready to have frame seeking; it just needs to be implemented in formats [15:03] <ubitux> but i may be missing something [15:03] <TheFluff> there's a complete matroska parser in there, for historical reasons [15:03] <Plorkyeran> there's format-specific stuff for mkv and vp8 [15:03] <Plorkyeran> the mkv stuff may not actually be a good idea anymore [15:03] <TheFluff> yeah [15:03] <ubitux> nothing specific for mpeg and avi? [15:04] <nevcairiel> but it implements this by re-indexing all the data, doesn't it? [15:04] <TheFluff> there's also an interface to a directshow mpeg ts/ps parser [15:04] <TheFluff> and ogg [15:04] <Plorkyeran> it indexes the video, and fully decodes the audio [15:04] <ubitux> this looks like a pretty appropriate GSoC task to me [15:04] <ubitux> i wonder if we still have time to add it [15:04] <TheFluff> for video only, maybe [15:05] <Plorkyeran> yeah, the video stuff is relatively straightforward [15:05] <Plorkyeran> audio basically requires fixing all of the decoders [15:05] <TheFluff> trying to do format-agnostic sample accurate seeking in audio with ffmpeg is an exercise in futulity [15:05] <TheFluff> futility* [15:05] <Plorkyeran> since most of them don't give the slightest fuck about accurate seekability [15:06] <Plorkyeran> which is sort of reasonable as no one will actually notice the first 1k samples after a seek being slightly wrong [15:06] <TheFluff> https://code.google.com/p/ffmpegsource/source/browse/trunk/src/core/audioso… <-- just read the comments in this file [15:07] <ubitux> too bad so much effort wasn't done in ffmpeg to start with, but well too late [15:09] <TheFluff> the effort required in ffmpeg would require different skills [15:09] <TheFluff> it'd require reading and understanding how the decoders actually work [15:09] <TheFluff> for a bunch of different decoders [15:10] <TheFluff> adding this kind of hack on top of the api would most likely never get accepted [15:10] <TheFluff> but on the other hand it can be done without knowing stuff about codec internals [15:12] <TheFluff> the video stuff on the other hand is pretty straightforward; it reads the file, stashes the pts/dts data and some other interesting stuff in an index and then just fakes it 'til it makes it [15:13] <TheFluff> it's maybe 1k lines of code total [15:21] <ubitux> ok [15:35] <cone-938> ffmpeg.git 03Anton Khirnov 07master:9e9cd98aed5c: FATE: add a test for the volume filter [15:35] <cone-938> ffmpeg.git 03Anton Khirnov 07master:8a2f5f0c6372: FATE: add a test for the join filter [15:35] <cone-938> ffmpeg.git 03Alexandra Khirnova 07master:0afcf97e1ece: vmdav: convert to bytestream2 [15:35] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:37bdf33cffd2: Merge remote-tracking branch 'qatar/master' [15:35] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:e0dd8cadcc38: af_join: fix channel count and format [15:35] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:e14f8bd07ef7: fate: Disable af_join test, as its output is not deterministic currently [15:35] <michaelni> ubitux, merge done [15:36] <ubitux> michaelni: ok thx [15:37] <michaelni> ubitux, also do you want to look at af_join (fate issue) ? [15:37] <ubitux> no, libav is on it [15:37] <ubitux> i let them deal with it [15:38] <michaelni> ok, even better, i like it when libav is working for me :) [15:38] <ubitux> don't tell it that loud or they will keep it broken just to piss you off [15:52] <ubitux> mateo`_: if later the extradata needs to be changed (to add some information or such), it will break with unmatching lavc and lavf version [15:52] <ubitux> isn't it possible to make more information in that extradata? [15:52] <ubitux> like the complete header section if not big [15:54] <mateo`_> ubitux: which header setion ? [15:57] <ubitux> well, the whole descriptor for instance [15:57] <ubitux> if it makes sense [15:57] <ubitux> (or maybe just the id of the desc and share it if hardcoded?) [15:58] <durandal_1707> are you deinterlacing in decoder? [16:09] <durandal_1707> ubitux: so true peak pm is missing in ebur128, why it was not implemented? [16:09] <ubitux> i have a branch for it [16:10] <ubitux> durandal_1707: i'm still not decided how to print it visually so... [16:10] <ubitux> and i want to get done with the normalization [16:10] <ubitux> durandal_1707: https://github.com/ubitux/FFmpeg/commit/ebbdf552627f4c0aa2a1a10b3e81d06efae… [16:10] <ubitux> need to be rebased on head [16:11] <ubitux> i'll do it when the live normalization is done [16:16] <durandal_1707> i added some colors to "phasescope" - i still not sure how to name this filter, or perhaps split it into several filters [16:18] <ubitux> phasescope is not good? [16:19] <GRMrGecko> Whenever I compile FFmpeg 1.2 for i386, I'm getting the error "./libavcodec/x86/dsputil_mmx.h:31: error: redefinition of struct xmm_reg" [16:20] <mateo`_> durandal_1707: i'm reconstructing the full frame within the decoder. [16:20] <ubitux> GRMrGecko: please go to #ffmpeg for user questions [16:20] <GRMrGecko> ok [16:20] <ubitux> GRMrGecko: and try to make distclean and run ./configure again [16:20] <durandal_1707> ubitux: there are at least 2 different meters: balance and correlation [16:21] <ubitux> durandal_1707: "audiometers" then maybe [16:21] <ubitux> or simply "ameters" [16:25] <cone-938> ffmpeg.git 03Giorgio Vazzana 07master:b97f7d9d2432: lavd/v4l2: replace ioctl() with v4l2_ioctl() [16:25] <cone-938> ffmpeg.git 03Giorgio Vazzana 07master:5009863ab5a4: lavd/v4l2: fix printing of list_formats table [16:33] <durandal_1707> what volume meter is actually useful? [16:40] <GRMrGecko> libavcodec/x86/dsputil_mmx.h line 31 should be "typedef struct { uint64_t a, b; } xmm_reg;" [16:41] <ubitux> GRMrGecko: for 1.2 right? [16:41] <ubitux> what about git/master? [16:41] <GRMrGecko> ubitux: yes [16:41] <GRMrGecko> I don't know... [16:41] <GRMrGecko> Let me look [16:43] <GRMrGecko> (I don't have it cloned yet, so give me a minute) [16:46] <GRMrGecko> ubitux: I don't even see it being defined in the master. [16:46] <ubitux> does it build? [16:46] <GRMrGecko> I'll try compiling the master to see the result [16:48] <GRMrGecko> ubitux: It was moved to ./libavutil/x86/asm.h:27 [16:48] <GRMrGecko> testing my fix [16:50] <ubitux> where was it first defined? [16:50] <GRMrGecko> ./libavcodec/x86/dsputil_mmx.h:31 [16:51] <GRMrGecko> that was in 1.2 [16:51] <ubitux> i mean why does it complain on redefinition? [16:51] <ubitux> where is it already defined? [16:52] <GRMrGecko> ubitux: On the same line. "typedef struct xmm_reg { uint64_t a, b; } xmm_reg;" vs "typedef struct { uint64_t a, b; } xmm_reg;" [16:52] <ubitux> it's not the same [16:53] <ubitux> one is the struct name and the other the typedef name [16:53] <ubitux> a struct xmm_reg might exists somewhere else [16:53] <GRMrGecko> yet, it's a redefinition of the same name. You're defining both the struct and the type with the same name. [16:54] <ubitux> that's not a problem [16:54] <ubitux> since the struct needs the struct prefix to be used [16:54] <ubitux> that's legal C [16:54] <GRMrGecko> don't know why GCC 4.2 complains then, [16:54] <ubitux> [~]- cat a.c [16:54] <ubitux> typedef struct foo { int a; int b; } foo; [16:54] <ubitux> [~]- gcc -Wall -Wextra -c a.c [16:54] <ubitux> [~]- [16:55] <ubitux> it's perfectly valid [16:55] <ubitux> GRMrGecko: my guess is that the struct xmm_reg is already defined in another header [16:55] <ubitux> what is the full error? [16:55] <GRMrGecko> hold on [16:57] <SenGlar> hi, i need to know if it is possible to set the encoding audio frame size to another size a little bit larger. For example, using 48kHz 2ch S16, the frame size should be 4096Bytes, but I'm getting from a camera a size of 7680. It is possible to encode such size per frame? [16:57] <GRMrGecko> SenGlar: I think you should be asking in #ffmpeg [16:58] <SenGlar> thanks, I was not shure where to ask this kind of question, I've done it there also! [16:59] <GRMrGecko> ubitux: http://p.webra.in/dn [17:00] <ubitux> pullup oh shit :) [17:00] <GRMrGecko> ubitux: http://p.webra.in/dj [17:00] <ubitux> (git grep is your friend) [17:01] <GRMrGecko> git grep? Never knew of that [17:01] <GRMrGecko> returns the same thing [17:01] <ubitux> yes sure [17:01] <ubitux> it smells like a double include somewhere [17:01] <GRMrGecko> maybe [17:02] <GRMrGecko> ubitux: Isn't #ifndef AVUTIL_X86_ASM_H suppose to stop that? [17:02] <ubitux> yes [17:04] <ubitux> you say it's reproducible with --arch=i386? [17:05] <GRMrGecko> ubitux: Let me give you the command I run for x86_64 [17:07] <ubitux> i just built with ./configure --enable-gpl --arch=i386 [17:07] <ubitux> and it worked fine [17:07] <ubitux> are you sure it's not a compiler bug? [17:07] <ubitux> can you try with --cc=clang or whatever? [17:07] <GRMrGecko> x86_64 http://p.webra.in/d8 [17:07] <GRMrGecko> i386 http://p.webra.in/d1 [17:08] <ubitux> i just realized that's mac os [17:08] <ubitux> maybe that's the problem ;) [17:08] <GRMrGecko> :P [17:08] <GRMrGecko> maybe I need --target-os=darwin [17:13] <ubitux> michaelni: "fate-filter-gradfun-ubitux" is really cute [17:13] <durandal_1707> what, not that nonsense again [17:13] <ubitux> durandal_1707: i asked him to keep them, i'm working on it [17:13] <durandal_1707> drop one with less coverage or rename test [17:14] <durandal_1707> i dont want decoder/encoders/filters/test/documentation/random file with alex/clark/denzel/elviss/tux/god/sam/joe/jane name in it [17:15] <ubitux> you forgot speedy gonzales [17:16] <durandal_1707> if you have so little creativity to name things, ask me first [17:17] <durandal_1707> ubitux: there is such file? [17:18] <ubitux> no but there is such author [17:19] <GRMrGecko> ubitux: It seems to just be the fact that it is i386 vs x86_64& I tried making the same exact command, just changing from i386 to x86_64& i386 doesn't build, but x86_64 does. [17:20] <GRMrGecko> and it's just that one line that stops the build. [17:24] <GRMrGecko> ubitux: Maybe it's something the configure script changes with the GCC command? [17:24] <ubitux> i don't know; check with a make V=1 [17:25] <GRMrGecko> ok [17:34] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:27b7bfc7b5be: avidec: Fix demuxing of non seekable avis with multiple RIFFs [17:36] <GRMrGecko> found SDL isn't compiled for i386& Maybe that is the issue? I doubt it& But I'll check [17:45] <cone-938> ffmpeg.git 03Clément BSsch 07master:ac00755e0af6: fate/filter: stick delogo test with its deps (cosmetics). [17:46] <cone-938> ffmpeg.git 03Clément BSsch 07master:4694af108842: fate/filter: rename 'ubitux' rules to 'sample'. [17:46] <cone-938> ffmpeg.git 03Clément BSsch 07master:7f19fc99e0aa: fate/filter: remove pointless indirections for gradfun and hqdn3d. [17:46] <cone-938> ffmpeg.git 03Clément BSsch 07master:b1213c911c53: fate/filter: move some CMD below deps for consistency. [17:46] <cone-938> ffmpeg.git 03Clément BSsch 07master:0adc93ba2b4c: fate/filter: move concat filtergraph to a dedicated script. [17:46] <cone-938> ffmpeg.git 03Clément BSsch 07master:ef4020ca7dd4: fate/filter: move gradfun filtergraph to a dedicated script. [17:46] <GRMrGecko> ubitux: Determined the issue to be "-mmacosx-version-min=10.4" vs "-mmacosx-version-min=10.5" [17:47] <GRMrGecko> gcc probably changes the way it works when you say you're building for 10.4 [17:49] <GRMrGecko> I can possibly just have a patch to fix this issue when building for 10.4. [17:50] <ubitux> no idea, i never touched a mac os [17:53] <ubitux> Daemon404: you were looking at overlay because of the fate failure? [17:53] <ubitux> it's likely because sws_flags are not set to bitexact [17:53] <ubitux> in ./tests/filtergraphs/overlay [17:55] <cone-938> ffmpeg.git 03Clément BSsch 07master:dd17843b8ab3: fate/filter: make overlay test bitexact. [17:56] <ubitux> hopefully it will calm down fate [20:57] <Bor0> what exactly does "crippled build" mean when specifying --disable-yasm? [21:11] <michaelni> it means it will be very slow, you want to install yasm if you intend to "use" that build [21:20] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:92002db3eb43: h264_refs: Check for attempts to assign pictures to short & long. [22:36] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:76e6b1eba1fe: wmv2: Use emu edge mode when the edge is too small [22:36] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:8fc52a5ef947: wmv2: drop non emu edge mode [22:36] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:3969b4b861ce: gmc: Always use edge emu [23:47] <jommy> hello [23:52] <michaelni> hallo [23:54] <jommy> do you know of a bug in avformat/oggdec.c where start_granule is never set? [23:55] <jommy> hence the starting timestamp is always zero [00:00] --- Fri Mar 29 2013

1 0

ffmpeg.log.20130328
by burek 29 Mar '13

29 Mar '13

[01:09] <smus> avcodec_encode_video(...) seems to return a valid byte size, but the output buffer I pass in is just zeros. Any ideas? Here's my code (very slightly modified from example): http://pastebin.com/M5VuHM9b [02:59] <Jordan_> what would happen if you use an x86 ffmpeg build to run on an input file greater than 2GB? [02:59] <Jordan_> is that a problem? [03:02] <iive> Jordan_: do you mean 32bit build? It should not be a problem, as unix provides 64 seeking for 32 bit functions. [03:02] <Jordan_> yes 32bit build and i'm on windows [03:04] <Jordan_> i'd like to test it to be sure, can you append multiple files together? [03:05] <iive> well, windows should also provide functions for 64 access, I hope the mingw uses them. [03:06] <iive> there are some ways to concatenate files, but i'm not sure how and how good it is. [03:07] <relaxed> use MP4Box to concat .mp4 and mkvmerge for everything else [03:07] <relaxed> ffmpeg works for mpeg containers [04:30] <relaxed> My static builds now have ffmpeg with 8bit & 10bit libx264 support. [04:40] <sacarasc> Cool. [05:01] <relaxed> I plan to include an x264 binary with lavf, swsscale, and gpac support as well. [11:32] <Zeeflo> has anyone here experience with setting up a RTMP server? [11:32] <Zeeflo> in other words, has anyone experience with setting up a CDN? [11:41] <Mavrik> which one? [11:41] <Mavrik> Wowza works very nicely [11:43] <Zeeflo> wowza [11:46] <Zeeflo> it looks like wowza is a service like amazon, where you pay to have them do your streaming? [11:47] <Zeeflo> ah.. its server software [11:48] <Zeeflo> Mavrik, do you use it yourself? [11:49] <Mavrik> used it [11:49] <Mavrik> bbl [12:23] <brontosaurusrex> is there a way to embed a thumbnail into mp4? [13:50] <__raven> hi [13:50] <__raven> what is the right encoder for mpeg1 layer 2 audio? [13:51] <durandal_1707> mp2? [15:51] <Zeeflo> anyone here familiar with wowza? [16:22] <ubitux> GRMrGecko: also, what configure flags are you using? [16:23] <GRMrGecko> ubitux: http://p.webra.in/d5 [16:24] <ubitux> (--disable-shared --enable-static is not necessary) [16:24] <ubitux> (--enable-pthreads as well afaik) [16:25] <GRMrGecko> ubitux: Here is the full config with the result of my script http://p.webra.in/d1 [16:27] <GRMrGecko> I'm able to compile for x86_64 just fine [16:28] <GRMrGecko> it is erroring in vf_yadif_init.c [16:28] <GRMrGecko> I'm looking through code [16:29] <ubitux> feel free to discuss on the ffmpeg-devel channel if you're willing to send a patch [16:29] <ubitux> (sorry for the back & forth) [16:29] <ubitux> it's likely a macro definition mess again [16:30] <GRMrGecko> ubitux: ok [16:32] <GRMrGecko> ubitux: Forgetting C& Because xmm_reg is defined twice in "typedef struct xmm_reg { uint64_t a, b; } xmm_reg;" isn't that the issue? [16:33] <GRMrGecko> should it be something like "typedef struct xmm_reg_struct { uint64_t a, b; } xmm_reg;" [16:33] <ubitux> i admit i didn't look yet [16:33] <GRMrGecko> or maybe forget the last part of xmm_reg [16:37] <GRMrGecko> ubitux: It's not fully compiled yet, but it seems to have passed the point where it errored out. [16:37] <GRMrGecko> "typedef struct { uint64_t a, b; } xmm_reg;" [16:39] <GRMrGecko> compiled [16:55] <SenGlar> hi, i need to know if it is possible to set the encoding audio frame size to another size a little bit larger. For example, using 48kHz 2ch S16, the frame size should be 4096Bytes, but I'm getting from a camera a size of 7680. It is possible to encode such size per frame? [16:58] <ubitux> do you still need to set the size with a recent api? [16:59] <jure> hi [17:00] <jure> can fdk-aac encode with a variable bitrate but at a nominal bitrate? [17:03] <durandal_1707> SenGlar: latest api have no limit on frame size that is going to be encoded/decoded [17:03] <SenGlar> @ubitux : I'm using the Magic version for implementing my encoder, and it seems that most encoders/codecs are not able to encode variable frame size, and I'm wondering if it could be easily done if I add the flag for example and/or so on. [17:05] <durandal_1707> Magic version? [17:05] <SenGlar> @durandal_1707 : but if I'm using an audio configuration of 48kHz stereo and S16 it seems that I can't encode 7680Bytes per frame, [17:05] <SenGlar> ffmpeg 1.2 version :P [17:06] <durandal_1707> SenGlar: you did not provided enought info, decoding/encoding >7680 bytes per frame is certainly possible [17:07] <SenGlar> with AAC (the native one or libfaac) encoder it is also possible? [17:08] <SenGlar> I want to encode 7680Bytes per frame that I got from a camera that is working at 25fps 48kHz stereo S16 [17:09] <Washu> Is there a way to concatenate all files in a directory as opposed to putting all the filenames in a file first? [17:09] <durandal_1707> aac can not encode arbitary size, and that is codec limit and not api limit [17:09] <SenGlar> OK! [17:11] <SenGlar> I need to know if it was a technologic limit or API limit, because when I implemented this scenario with the oggvorbis API from xiph.org I could do that with no problem. So I was wondering if it could be done, also because of the comparison that using the vorbis encoder of the ffmpeg API it can't be done neither. [17:11] <durandal_1707> Washu: via concat protocol but that probably does not work in your scenario [17:12] <Washu> durandal_1707: doesn't that involve typing all the filenames into the command though? [17:12] <durandal_1707> Washu: yes, if you want some feature open bug ticket [17:16] <Washu> so anyone using ffmpeg put all the filenames in a file or in the command to concat? seems pretty complicated for it to always have been like that [17:18] <durandal_1707> if nobody complains (open ticket) it will reamain in that state [17:19] <Washu> Fine, just seems weird that a project like this wouldn't have thought of that which leaves me with the impression the bug will be ignored :P [17:19] <SenGlar> @ druandal_1707 : so, do you mean that it is technologically impossible to re-implement the AAC codecs used in the ffmpeg API to reach the specs I've told? [17:21] <durandal_1707> SenGlar: i already told you that aac does not support arbitary frame size, should API have support for some kind of fifo is different question [17:25] <Washu> SenGlar: I think the answer to your question is yes if you wanted to write some AAC if it's even possible at all with that codec but ffmpeg doesn't support what you asked for because aac itself does not suppprt it [17:25] <SenGlar> Ok! thanks! Also to point out that I've implemented a fifo structure with the methods of the ffmpeg API but it breaks the 7680Bytes in 4096Bytes and encode it, then the residual 3584B are also encoded but with padding... [17:25] <SenGlar> Thanks anyway people! [17:25] <SenGlar> You are doing a good job! :) [17:32] <durandal_1707> SenGlar: you mean with last frame? [17:33] <durandal_1707> not all codecs supports trucated/small last frame [17:34] <durandal_1707> but bad native aac encoder supports small last frame [17:51] <SenGlar> yes, but I don't want a last frame with padding, I want to get a continue stream that is getting 7680 raw bytes per frame to encode [18:11] <SenGlar> I'm leaving! [18:11] <SenGlar> thanks anyway! :) [18:11] <SenGlar> See yah!! [20:55] <Bor0> what exactly does "crippled build" mean when specifying --disable-asm? [20:55] <Bor0> yasm* [20:58] <JEEB> it will be slow [20:58] <JEEB> as in, the usefulness will be much much lower [21:01] <Bor0> could that be the reason why video playback for some videos causes the player to freeze completely? [21:01] <Bor0> and then eventually crash [21:01] <bparker> o/ [00:00] --- Fri Mar 29 2013

1 0

ffmpeg-devel.log.20130327
by burek 28 Mar '13

28 Mar '13

[00:00] <ubitux> saste: ping [00:00] <saste> ubitux, pong [00:00] <ubitux> saste: so what's going on for the gsoc page? [00:01] <ubitux> 2 days left afaik [00:01] <ubitux> (introduction etc) [00:01] <saste> ubitux, llogan^ [00:01] <saste> i'll do it tomorrow if llogan won't have do it in the meantime [00:02] <saste> will not have done it or whatever [00:02] <saste> also i should ping mentors and backup mentors [00:02] <saste> bcoudurier, ping for gsoc [00:03] <saste> mentors and co-mentors are welcome [00:03] <bcoudurier> yes [00:03] <bcoudurier> put me on any project [00:03] <bcoudurier> I'll mentor [00:03] <saste> bcoudurier, http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_of_Code_2013 [00:04] <saste> you can choose amongst the several unmentored task, or propose a new task, or volunteer as backup mentor [00:04] <saste> you need an account from Mike Melanson for editing the wiki, or just tell me or llogan and will fill it [00:04] <saste> *we'll [00:05] <llogan> any suggestions, ideas, requirements for intro? [00:06] <saste> llogan, a small section about telling what the project consists (pay for twisting bits etc.) [00:07] <saste> some guidelines about how and where to contact mentors, recommending to discuss with the candidate mentors or with the community [00:07] <saste> you should mention that the students can propose a task, even in that case they need to find a mentor willing to help [00:08] <saste> then we should probably add some guidelines about the qualification task [00:08] <saste> for example student who do a good task, who interact with the community have more chances of being accepted [00:10] <saste> i/we can tweak the text once after you write a first draft [00:10] <llogan> ok. i'll try to get something within the next 3.5 hours [00:10] <saste> the soon we start the better, since we only have two days and i'm busy 90% of my time [00:19] <kierank> i don't think mvc is a gsoc worth of work [00:20] <llogan> we'll bikeshed it until it is [00:29] <ubitux> wtf [00:30] <llogan> so many people stopping by and someone hammering next door makes me not write well. [00:37] <michaelni> kierank i dont mind droping MVC if people think its too easy [00:37] <michaelni> kierank, btw do you want to mentor something ? [00:37] <kierank> dunno what i'd mentor [00:38] <michaelni> you know alot about a lot of things [00:38] <michaelni> something you like to mentor, like to see in ffmpeg or think would be important and realistic for a gsoc task [00:43] <iive> if mvc is too easy, why it haven't been done yet? [00:43] <kierank> 3d is dead [00:44] <kierank> and there's a guy doing it afaik [00:44] <iive> it is not dead, it just smells funny. [00:44] <iive> ;) ok, if there is somebody working on it, then it is entirely different matter. [00:45] <michaelni> iive do you want to mentor something ? [00:46] <iive> nope. i probably won't be able to navigate ffmpeg myself. [00:47] <michaelni> iive you contributed code in the past and you managed to navigate it ... [00:48] <iive> i should first contribute some new code, before trying to help somebody else. [00:49] <saste> damn sent two times the same mail.. [00:49] <llogan> welcome to the club [00:56] <saste> iive, backup mentors are welcome as well [00:57] <saste> which possibly mean to guide the student when the poor mentor takes a well-deserved one-week vacation [01:10] <ubitux> saste: no coverage for lut* filters? :( [01:10] <saste> ubitux, return AVERROR_PAWE [01:11] <ubitux> pawe? [01:11] <ubitux> "Power for Association with Error"? [01:11] <saste> AVERROR_PATCHWELCOME [01:11] <ubitux> oh. [01:12] <ubitux> :( [01:16] <michaelni> if i hear no objections then ill follow kieranks suggestion and remove MVC [01:17] <ubitux> i remember seeing a guy talking about mvc recently [01:17] <ubitux> maybe he has some opinion on the matter [01:17] <ubitux> michaelni: we don't have much tasks btw, would be nice to replace it with another one if you drop it [01:19] <ubitux> his nick was "jojva" [01:19] <ubitux> "< jojva> Well, I'm a student (master's) and with a few people we have this project. The purpose is to film an object with the 3d cam, then transform it into a 3d model" [01:20] <cone-383> ffmpeg.git 03Carl Eugen Hoyos 07release/0.10:5dd5cfd0b8d3: Only test the first frame for missing aac_adtstoasc bistream filter. [01:20] <cone-383> ffmpeg.git 03Carl Eugen Hoyos 07release/0.11:8538811a1fef: Only test the first frame for missing aac_adtstoasc bistream filter. [01:20] <cone-383> ffmpeg.git 03Carl Eugen Hoyos 07release/0.9:402bc31d8787: Only test the first frame for missing aac_adtstoasc bistream filter. [01:20] <cone-383> ffmpeg.git 03Carl Eugen Hoyos 07release/1.0:fe995dcd84c6: Only test the first frame for missing aac_adtstoasc bistream filter. [01:20] <cone-383> ffmpeg.git 03Carl Eugen Hoyos 07release/1.1:fc7071cb53de: Only test the first frame for missing aac_adtstoasc bistream filter. [01:20] <cone-383> ffmpeg.git 03Carl Eugen Hoyos 07release/1.2:9ecfd7daa37d: Only test the first frame for missing aac_adtstoasc bistream filter. [01:21] <ubitux> and a WIP seems available here: https://github.com/jojva/FFmpeg/commits/master [01:21] <ubitux> anyway, i have no opinion on whether mvc should be part of gsoc or not [01:21] <ubitux> but it seems there is some slight interest in it [01:27] <michaelni> ubitux, if jojva is a student maybe he would want to work on MVC under gsoc ? [01:27] <ubitux> that's what i wonder yes [01:30] <llogan> latest message in -devel appears to be a student wanting to add SILK support (i'm not familair with that or know if it is "big" enough for a project) [01:39] <kierank> that became opus, no? [01:43] <Skyler_> Yeah, SILK is now part of opus, so [01:43] <cone-383> ffmpeg.git 03Michael Niedermayer 07master:e370b6589778: tests/tiny_ssim: include the 2 macros instead of a header [01:44] <cone-383> ffmpeg.git 03Clément BSsch 07master:1a3f7ded147f: doc: "av* tools" -> "ff* tools". [01:45] <saste> llogan, did you join #gsoc btw? [01:45] Action: llogan apparently wasn't paying attention to SILK 'n friends [01:46] <llogan> saste: i've been there twice [01:46] <saste> llogan, i wonder if candidate mentors need to register before application [01:46] <saste> but i don't think so [01:46] <llogan> might be mentined in the FAQ and/or manual(s) [01:47] <llogan> Skyler_: want to mentor anything? [01:47] <Skyler_> Um, I'm not sure I'd do a very good job; do we have any idea what the projects are? [01:47] <llogan> http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_of_Code_2013 [01:48] <Skyler_> oh, cool, APNG! [01:48] <llogan> of course you can make your own too [01:49] <Skyler_> oh nice, there's a VP7 spec now :o [01:50] <ubitux> looks like it's xmas for Skyler_ [01:52] <kierank> don't shoot the messenger but it is probably not a good idea for Skyler_ to be involved in gsoc [01:52] <saste> llogan, #gsoc confirms that no registration is required for candidate mentors [01:53] <highgod> Hello, for the multi-thread synchronization of OpenCL patch, in the our original design, the thread synchronzation is controled by the user application,so we didn't add the the thread controle in the APIs related to the OpenCL [01:53] <llogan> saste: ok, thanks. [01:55] <ubitux> would it make sense to have a filter to randomize linesizes? [01:55] <ubitux> just like (a)perms, in order to test filters etc [01:55] <ubitux> typically here in the filter i'm working on, i was assuming that successive frames had the same linesize [01:56] <ubitux> while it's true in practice, it might not be in some cases [01:56] <cone-383> ffmpeg.git 03Carl Eugen Hoyos 07master:7857ddceecdd: Fix a typo in the Monkey's Audio demuxer. [01:56] <ubitux> can anyone think of filters where it would make sense to test such thing? [01:59] <michaelni> ubitux, maybe you should add a vf_jerk that randomizes everything [01:59] <ubitux> :D [02:00] <ubitux> do you see other things to randomize? [02:00] <llogan> random curves preset for lols [02:00] <ubitux> llogan: hehe :) [02:01] <michaelni> it could inject random command & metadata maybe optionally change w/h [02:01] <ubitux> oh that would be evil [02:02] <michaelni> aspect, timestamps, position [02:02] Action: iive likes the idea [02:02] <ubitux> let's add a GSoC [02:03] <ubitux> "be a jerk and write tools to break ffmpeg by all means" [02:04] <saste> ubitux, curves=bikeshed? [02:04] <ubitux> saste: i doubt this is going to break much stuff [02:04] <ubitux> unless you meant something else? [02:05] <Skyler_> kierank: yeah, one failed project later and after the drama in code-in, I figure it'd be easier if not... [02:05] <ubitux> saste: i'm still waiting for you pink profile btw ;) [02:06] <saste> ubitux, really we need a bikeshed curves profile [02:06] <saste> even if sadly it won't break nothing [02:06] <ubitux> saste: feel free to propose anything [02:07] <Skyler_> (and given this is an identity I kind of want to limit the use of, I don't want to have to dedicate hours more a week to it...) [02:07] <saste> bcoudurier, ping for the gsoc task, mail if also fine [02:08] Action: saste sleeps [02:19] <highgod> Hi, michaelni, is there any multi-thread code whitch I can reference? [02:19] <highgod> in libavutil? [02:20] <highgod> I have little experience in ffmpeg thread operations [02:27] <michaelni> highgod, for atomic operations look at atomic.h, for a use example look at buffer.c, for mutex examples just grep for pthread_mutex_lock its used in various parts of avcodec and avformat [02:32] <funman> school didn't teach me much but grep did.. :) [02:39] <cone-383> ffmpeg.git 03Carl Eugen Hoyos 07master:92a9a3020d2c: Support pcm_mulaw in Hikvision CCTV mpeg program streams. [02:46] <michaelni> kierank, I dont see a problem with Skyler_ mentoring if he wants to but saste / llogan are gsoc admins this year so this is just my oppinon also i dont know any details of the "drama" (which isnt my buisness anyway) just that there was some drama [02:54] <highgod> michaelni, Thanks [04:00] <cone-383> ffmpeg.git 03d s 07master:444001bda6ad: Fix avisynth_context_create constructor error handling. [04:00] <cone-383> ffmpeg.git 03d s 07master:914f48ddf022: Update MAINTAINERS with information about avisynth demuxer. [04:07] <llogan> instead of writing the intro like i should have i made a FFmpeg gsoc logo... beer time and then maybe i'll finish the intro tonight. [04:35] <ubitux> yay, fieldmatch fixed [04:37] <ubitux> now i wonder why the the micmatch is mismatching so much.. [04:37] <ubitux> Daemon404: would you mind testing something for me in tfm? [04:38] <KSV> hi guys [04:39] <KSV> how many frames are decoded by ffplay in advance [04:39] <KSV> and can we control this value? [06:32] <ubitux> Daemon404: with your kyoani_cm_mechagirl.ts sample, i get a lot of still combed frames in the output as soon as the micmatching is enabled (default), whatever the mode [06:32] <ubitux> OTOH, when micmatching is disabled, it works perfectly fine, not a single combed frame [06:33] <ubitux> (both vivtc and the ffmpeg's one i'm writing based on it) [06:33] <ubitux> so i wonder if this is a problem with vfm, or if it's the same with tfm [06:33] <ubitux> unfortunately, it's hard for me to test [06:39] <ubitux> Myrsloik_: you might be interested in this btw ^ [06:40] <Myrsloik_> ok [06:40] Action: Myrsloik_ probably got some condition mixed up [06:41] <ubitux> do you have the sample? [06:42] <ubitux> (chromashift.org/<samplename>) [11:39] <cone-985> ffmpeg.git 03Martin Storsjö 07master:a2acadd0584b: x86: vc1dsp: Fix indentation [11:39] <cone-985> ffmpeg.git 03Martin Storsjö 07master:3b2d0ec473b0: configure: Remove the mpegvideo dependency from svq1 [11:39] <cone-985> ffmpeg.git 03Michael Niedermayer 07master:ef8ab2f95307: Merge commit '3b2d0ec473b036bdd0a5bc0d896fd5292915f44d' [11:50] <cone-985> ffmpeg.git 03Martin Storsjö 07master:2ece5bf3ec8b: configure: Remove a stray msmpeg4v1 encoder declaration [11:50] <cone-985> ffmpeg.git 03Janne Grunau 07master:c24469e81250: utils: add workaround for AVHWAccel in ff_get_buffer compat code [11:50] <cone-985> ffmpeg.git 03Michael Niedermayer 07master:12f203a09879: Merge commit 'c24469e812501903a46a06eff9722a82e136e841' [11:59] <cone-985> ffmpeg.git 03Janne Grunau 07master:05fa79b84480: hwaccel: fix use with frame based multithreading [11:59] <cone-985> ffmpeg.git 03Michael Niedermayer 07master:ace0cfea60a3: Merge remote-tracking branch 'qatar/master' [12:46] <highgod> how can I use filter options, for example "deshake_options", how can I use command to input it? [13:07] <ubitux> highgod: deshake=foo=bar:bla=xxx [13:07] <ubitux> check the documentation [13:25] <highgod> @ubitux:can you tell more details?which document, I tried your command [13:25] <highgod> but failed [13:25] <ubitux> what did you try? [13:27] <ubitux> http://ffmpeg.org/ffmpeg-filters.html [13:31] <durandal_1707> ubitux: what is funny in phasescope output? [13:32] <ubitux> durandal_1707: i got strange cases of different "layouts" depending on the music [13:33] <durandal_1707> "layouts"? [13:34] <ubitux> layouts, patterns, .. [13:34] <ubitux> i'll show you in a moment [13:38] <durandal_1707> those should be lissajous curves, my goal is to implement something like this: http://www.izotope.com/support/help/ozone/pages/meters_vectorscope.htm [13:39] <ubitux> durandal_1707: http://ubitux.fr/pub/pics/_phasescope.png [13:39] <ubitux> got a music which gives me this [13:39] <ubitux> almost all the song [13:40] <durandal_1707> well default is really slow fading of previous frames [13:41] <ubitux> there is no fading problem [13:41] <ubitux> it's more like the horizontal/vertical patterns [13:43] <durandal_1707> unless this is because of broken max/min_samples (and thus reading wrong data) there is afaik nothing wrong with filter [13:44] <ubitux> i'm not saying there is anything wrong [13:44] <ubitux> i find the pattern funny [13:44] <ubitux> at least different from some other songs: http://ubitux.fr/pub/pics/_phasescope2.png [13:44] <ubitux> this one looks more common for instance ^ [13:45] <ubitux> i need to test with more songs :) [13:45] <ubitux> anyway, i'm looking forward some fancy outputs [13:45] <durandal_1707> do you like this correlation meter bellow? [13:46] <durandal_1707> i dunno would i put its fade out as different option [13:46] <ubitux> with colors it would be even more awesome ;) [13:46] <durandal_1707> or put it as separate mode [13:46] <highgod> thanks [13:46] <highgod> ubitux [13:47] <durandal_1707> colors? you mean instead of white use green? or multiple colors at same time [13:47] <ubitux> color gradiants for instance [13:47] <ubitux> like showspectrum [13:47] <ubitux> a nice rainbow [13:48] <durandal_1707> your music is very mono friendly , unlike mine [13:48] <ubitux> what do you mean? :) [13:48] <durandal_1707> correlation meter on bottom is 99% on right side [13:49] <durandal_1707> so when you convert to mono you would not experience strange music [13:50] <durandal_1707> what is left to do is polar mode (current one is just lissajous) and balance meter [13:51] <ubitux> i have a more symmetric looking here: http://ubitux.fr/pub/pics/_phasescope3.png [13:52] <ubitux> zsh: segmentation fault (core dumped) ./ffplay -f lavfi 'amovie=requiem.flac,asplit[out0],phasescope[out1]' [13:52] <ubitux> :( [13:52] <durandal_1707> this is still good [13:52] <durandal_1707> i usually have very bright left side [13:53] <ubitux> at libavfilter/avf_phasescope.c:184 [13:53] <ubitux> 184 x = ((ptr[1] - (int)ptr[0]) / (float)UINT16_MAX + 1) * hw; [13:53] <ubitux> want that sample? :) [13:53] <durandal_1707> what happens? [13:53] <ubitux> crash [13:54] <ubitux> almost immediately [13:54] <durandal_1707> i would prefer patch [13:54] <ubitux> :D [13:54] <ubitux> ok give me a moment :) [13:57] <durandal_1707> how is balance between L & R calculated? it is just some average of sum? [13:59] <ubitux> i have a lot of invalid read here [13:59] <ubitux> with any file [13:59] <ubitux> and use of uninit data [14:00] <durandal_1707> hmm, than max/min is broken [14:00] <durandal_1707> or you mean invalid write [14:00] <ubitux> nope invalid read first [14:01] <ubitux> uninit: [14:01] <ubitux> ==27839== Use of uninitialised value of size 8 [14:01] <ubitux> ==27839== at 0x469F29: filter_frame (avf_phasescope.c:187) [14:01] <ubitux> invalid read: [14:01] <ubitux> ==27839== Invalid read of size 2 [14:01] <ubitux> ==27839== at 0x469EE0: filter_frame (avf_phasescope.c:184) [14:03] <durandal_1707> x/y calculation is buggy [14:04] <ubitux> yup :p [14:05] <ubitux> i'll let you fix your code yourself [14:05] <ubitux> got some stuff to do [14:09] <durandal_1707> actually it read too much, so that probably reason why some strange straight lines appears [14:17] <durandal_1707> ubitux: crash happens because of invalid read or write? [14:17] <durandal_1707> anyway upload sample that causes crash somewhere [14:22] <ubitux> pm [14:27] <durandal_1707> thx [14:37] <ubitux> mmh [14:37] <ubitux> + * Copyright (C) 2012 Peng Gao <peng(a)multicorewareinc.com> [14:37] <ubitux> + * Copyright (C) 2012 Li Cao <li(a)multicorewareinc.com> [14:37] <ubitux> + * Copyright (C) 2012 Wei Gao <weigao(a)multicorewareinc.com> [14:37] <ubitux> i wonder if the 'C' is not meant to be a 'G' [14:38] <ubitux> and if so... fear. [14:40] <durandal_1707> i beat there is at least 10 Wei Gao in china at least [14:41] <av500> 10? [14:41] <iive> 10k [14:41] <ubitux> Gao reminds me the cry of misuzu in Air btw... [14:42] Action: ubitux wonders if pasting https://www.youtube.com/watch?v=IPbtKMYlV7U on the mailing list will be taken as a bad joke [14:45] <durandal_1707> those animes all like same [14:46] <ubitux> i found the "gao~" only once in another anime [14:46] <ubitux> ( http://lolicri.es/#touch-minami-asakura) [15:03] <durandal_1707> ubitux: i think i fixed strange patterns and crash [15:26] <kierank> i wonder who is paying for opencl filtering [15:27] <ubitux> durandal_1707: indeed that's better [15:28] <ubitux> durandal_1707: OTOH the sample from my first screenshot now only displays a vertical line [15:28] <ubitux> not a single pixel outside that vertical line [15:28] <ubitux> want a sample? [15:31] <ubitux> i got some pretty outputs with some samples though [15:31] <ubitux> like this one http://ubitux.fr/pub/pics/_pretty-phasescope.png [15:31] <durandal_1707> ubitux: perhaps its mono [15:32] <ubitux> durandal_1707: what do you mean by mono? all channels the are the same? [15:33] <durandal_1707> yes [15:34] <ubitux> durandal_1707: Assertion x < p->w failed at libavfilter/avf_phasescope.c [15:34] <ubitux> want another sample? :) [15:35] <durandal_1707> yes [15:35] <ubitux> uploading.. [15:35] <durandal_1707> i couldn't get that with random() [15:35] <ubitux> i got it with my 3rd test ;) [15:37] <ubitux> pm [15:37] <ubitux> it doesn't happen in the first second, you can reproduce easily with ffmpeg [15:37] <ubitux> ./ffmpeg -i hoc.flac -filter_complex phasescope -f null - triggers it immediately [16:05] <cone-985> ffmpeg.git 03Michael Niedermayer 07master:a2b58256490d: vsrc_mandelbrot: support coloring the outside white [16:16] <durandal_1707> ubitux: that file is very loud at end [16:19] <ubitux> that's the power of sound [16:19] <ubitux> so loud it breaks softwares [16:20] <durandal_1707> actually this was of by one overflow [16:23] <durandal_1707> fixed, added balance mode (dunno if it is correct) [16:26] <durandal_1707> now should i rotate those one by default, if user wants to overlay several ones it can use transpose filter [16:27] <cone-985> ffmpeg.git 03Michael Niedermayer 07master:79938a4e9748: mandelbrot: add outer coloring method showing bailouted z [19:30] <llogan> would it be preferrable for students to use github or whatever for simple pull requests (assuming they finish something)? [19:31] <ubitux> llogan: whatever they prefer i guess [19:32] <cone-985> ffmpeg.git 03Michael Niedermayer 07master:0d6e5a17124d: vsrc_mandelbrot: Mandel morphing support [19:39] <ubitux> hehe [19:39] <ubitux> michaelni: maybe you could add a julia mode now :) [19:41] <llogan> is Small FFmpeg Tasks page fairly up to date? [19:42] <ubitux> michaelni: i'm looking forward a buddhabrot btw ;) [19:42] <ubitux> llogan: url? [19:43] <ubitux> llogan: btw, the "Proposing ideas" and various other developers annotation could be dropped from the page [19:44] <ubitux> michaelni: https://upload.wikimedia.org/wikipedia/commons/5/51/Nebulabrot.jpg :) [19:47] <michaelni> ubitux, patch welcome :) [19:48] <durandal_1707> there is bunch of different fractals [19:48] <durandal_1707> so separate filter for each of them is littly sillz [19:49] <ubitux> michaelni: i don't want to steal the fun :p [19:50] <ubitux> a pretty animated nebulabrot would be nice though [19:52] <durandal_1707> there is xaos, with bunch of assembly i think [19:52] <llogan> ubitux: http://wiki.multimedia.cx/index.php?title=Small_FFmpeg_Tasks [19:52] <llogan> i was waiting (hoping) for bcoudurier to add something [19:52] <durandal_1707> rewrite swscale [19:53] <llogan> ..before archiving Proposing to the page discussion [20:04] <michaelni> J_Darnley, do you want to mentor something in ffmpeg google summer of code ? [20:06] <michaelni> TimNich, Tjoppen, mateo`_ if you want to mentor something please add yourself to the gsoc wiki page [20:08] <llogan> or ask me or saste and we can add anything you want if you don't yet have an account [20:08] <durandal_1707> you repeated this at least two times [20:08] <durandal_1707> nobody wants to mentor [20:09] <J_Darnley> michaelni: I'm not sure I'm experienced enough but I will have a look at the ideas list [20:09] <llogan> i think the ideas page is much better than last years [20:10] <michaelni> J_Darnley, thx [20:14] <ubitux> frame_rate: 0/0 | time_base: 1/1 [20:14] Action: ubitux wonders how useful these fields are [20:15] <ubitux> (context: lavfi filter links) [20:16] <ubitux> and in my case the input is supposed to be cfr [20:42] <J_Darnley> michaelni: I could manage to mentor someone about their interactions with FFmpeg and what we would expect from them... [20:43] <J_Darnley> but I don't think I could judge how well they were doing their task [20:44] <J_Darnley> The proposed tasks are above my level of experience with codecs [20:56] <michaelni> J_Darnley, i was thinking that you maybe would want to mentor something libavfilter related, also google pays 500USD to each mentor IIRC [20:57] <durandal_1707> i doubt that [21:02] <michaelni> durandal_1707, http://www.google-melange.com/document/show/gsoc_program/google/gsoc2012/fa… [21:02] <michaelni> "Google will provide a stipend of 5500 USD per accepted student developer, of which 5000 USD goes to the student and 500 USD goes to the mentoring organization." [21:06] <ubitux> isn't this only if the student succeed? [21:07] <michaelni> ubitux, probably yes, [21:07] <michaelni> s/,// [21:08] <michaelni> but then it wont be much work for the mentor if the student just disappears or does nothing ... [21:09] <ubitux> sure [21:09] <ubitux> btw, if the frame rate was correctly injected in lavfi, we could make select and similar filters adjust pts properly [21:10] <ubitux> that would be nice... [21:10] <ubitux> with cfr of course [21:10] <michaelni> ubitux, do you have a testcase ? [21:10] <ubitux> i have various use case [21:11] <ubitux> first one is extracting pictures from a video with select [21:11] <ubitux> it doesn't work unless you -vsync cfr for example [21:11] <ubitux> another example is the decimate filter i'm writing currently [21:11] <michaelni> do you have a command line, sample file and such so i can see where it fails ? [21:12] <ubitux> i'll come up with one [21:12] <ubitux> give me about an hour, i'd like to do some tests before [21:12] <michaelni> ok [21:27] <ubitux> michaelni: the output of ffmpeg -lavfi testsrc -t 60 -vsync cfr test-cfr.avi is considered to be cfr, right? [21:28] <ubitux> and same with other container such as mpg or mkv? [21:29] <michaelni> ubitux, looks like cbr [21:30] <michaelni> cFr :) [21:32] <ubitux> mmh, it might be a problem in my code [21:32] <ubitux> the frame rate is indeed well populated [21:40] <ubitux> michaelni: ok, got it; with ffplay it's not set [21:41] <ubitux> michaelni: with http://pastie.org/7142307 you can compare "./ffmpeg -i test-cfr.avi -vf select -f null -" vs "./ffplay test-cfr.avi -vf select" [21:55] <michaelni> ubitux, patch posted [21:56] <ubitux> wow great [21:56] <ubitux> michaelni: isn't this code shared with ffmpeg? [21:57] <michaelni> could be factored out yes [21:57] <ubitux> i'd be happy to such such magical code factorized [21:58] <ubitux> a lavf util function or such [21:58] <ubitux> and eventually, automatically done by lavf in one random field [22:00] <michaelni> ill factor it out [22:00] <ubitux> anyway, thx for the patch, that will ease my testing [22:02] <ubitux> seems to work fine [22:02] <ubitux> in[tb:1/90000 rate:30000/1001] out[tb:1/90000 rate:30000/1001] [22:02] <ubitux> just as expected, thx [22:46] <ubitux> my ivtc branch should be ready for testing for those who want to play with it [22:47] <ubitux> i need to do some more work on the decimate filter, but it's working [22:58] <ubitux> michaelni: the frame doesn't seem to be used at all for guessing the rate; is this supposed to change later? [22:59] <ubitux> same for the format [23:00] <ubitux> sorry for reviewing on irc; maybe i should post on the ml instead [23:00] <michaelni> i thought it could become usefull in the future saving us from s func2() [23:01] <michaelni> also its similar to the aspect guessing func [23:01] <ubitux> while i can imagine some potential improvements based on format, i wonder how the frame could be help [23:06] <durandal_1707> ffplay -f lavfi -i "amovie=/tmp/hoc.flac,asplit=3[a][b][c],[a]phasescope=s=400x400:d=20[o0],[b]phasescope=m=balance:d=25:s=20x400[o1],[c]phasescope=m=correlation:d=25:s=20x400[o2],[o0][o1]overlay[t0],[t0][o2]overlay=380:0" [23:08] <ubitux> oh [23:08] <ubitux> that's nice [23:08] <ubitux> with a split=4 to listen at the same time that's perfect :) [23:14] <durandal_1707> now imagine frame full of such meters [23:14] <durandal_1707> vu, ppm, sco and probably others left to write [23:20] <cone-985> ffmpeg.git 03Michael Niedermayer 07master:460d30406bca: avformat: change some seeking related assert to av_asserts [23:20] <cone-985> ffmpeg.git 03Michael Niedermayer 07master:e9d3b4005293: snow: drop commented out asserts [23:22] <ubitux> http://lucy.pkh.me/phasescope.webm [23:22] <ubitux> for those who are too lazy to check out durandal_1707's branch ^ [23:23] <ubitux> i like the 'V' appearing around 34sec [23:29] <ubitux> 'night [23:47] <michaelni> ubitux, a bit early ;) but n8 [23:59] <cone-985> ffmpeg.git 03Dale Curtis 07master:81e85bc95cb1: Fix heap-buffer-overflow in matroska_parse_block [00:00] --- Thu Mar 28 2013

1 0

ffmpeg.log.20130327
by burek 28 Mar '13

28 Mar '13

[01:44] <Jordan_> what happens if you try to encode a higher frame rate than the source [01:51] <llogan> Jordan_: ffmpeg will duplicate frames to attempt to reach your desired output frame rate [02:04] <Jordan_> what would be the point in that? [02:09] <llogan> for example if you have image inputs that you want to decode at a certain frame rate but your outputencoder or container may only suport certain frame rates [03:38] <Demon_Fox> Anyone know how to take the first couple seconds out of a video into a new file for tests? [03:38] <Demon_Fox> not like dd [03:40] <klaxa> ffmpeg -i <input> -ss 10 -c copy <output> [03:40] <klaxa> copies the first 10 seconds in a new file [03:40] <klaxa> copies all codecs, skips attachments though [03:40] <Demon_Fox> what does -c do? [03:41] <Demon_Fox> oh [03:41] <klaxa> codec [03:41] <Demon_Fox> thanks [03:41] <Demon_Fox> I wanted to do some tests with high motion scenes using x264 to know how high to set the crf [04:57] <bigmac> im looking to batch process a large list of movies... each video may already exist as different size's and formats (700mb.avi to 2000mb.mp4 etc)... the end result i would like to be a smaller file size for a droid phone [04:58] <bigmac> i struggle to produce these results [05:09] <relaxed> bigmac: figure out which libx264 -crf value looks good and fire away [05:11] <relaxed> bigmac: a slower -preset will yield better compression [05:35] <bigmac> relaxed: im not sure of this -crf... maybe a example you can show me a example? [14:36] <alal> Hello [14:36] <alal> I have a problem with decoding an mp3 flow and would like to ask if anyone can check what could be wrong with it [14:37] <alal> http://listen.radionomy.com/Remzouille-Radioo [14:37] <alal> it is a web radio [14:37] <alal> When I open it in Chrome it seems to work (although there is a noise for the first 1s) [14:42] <alal> Thanks in advance for any hints [16:57] <gormux> hi all [16:57] <gormux> I'm searching infos on hardware encoding, and there are not many as it seems [16:58] <gormux> anyone uses vdpau or other piece of hardware to do the encoding with ffmpeg ? [16:58] <retard> i didn't even know vdpau could do encoding [17:00] <gormux> hum, maybe not vdpau, but it seems it is supported by vaapi, at least with intel [17:08] <Mavrik> gormux, short answer: not supported by ffmpeg [17:08] <Mavrik> :) [17:10] <gormux> raaah, I want a solution :p [19:01] <johnny_|_> Hey. How can I check if h264_vda is working. I have nvidia 8800gt and os x 10.7.3. I have ffmpeg with --enable-vda flag and ffmpeg -codecs | grep h264 outputs: DEV.LS h264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (decoders: h264 h264_vda ) (encoders: libx264 libx264rgb ) [20:01] <schtinky> so I know you can cat two or more MPEG-TS streams together... wondering if it's possible to also directly extract still frames from MPEG-TS without ffmpeg [20:01] <schtinky> I assume not as the stream is still motion encoded and therefore is not a series of still frames [20:02] <schtinky> can anyone confirm/deny? [20:03] <ubitux> concat demuxer maybe? [20:03] <ubitux> https://ffmpeg.org/faq.html#How-can-I-concatenate-video-files_003f [20:07] <Mavrik> schtinky, well you do have to decode the stream :) [20:07] <schtinky> ok that's what I was looking for [20:07] <Mavrik> schtinky, only I-frames are encoded fully, others are motion encoded :) [20:07] <Mavrik> ability to concat means that the container is flexible enough to alow that :) [20:08] <Mavrik> nothing more [20:08] <schtinky> how often to i-frames occur? [20:08] <Mavrik> well... as often as the guy encoding your stream set it [20:08] <schtinky> how do I find out? [20:09] <schtinky> (also, iframes sounds like Apple's competitor to google glass) [20:09] <schtinky> just throwing that out there [20:09] <Mavrik> :D [20:10] <Mavrik> schtinky, depending on format... for MPEG-2 usually mediainfo shows I-frame interval (as "GOP size") [20:10] <Mavrik> for H.264 it can be arbitrary, but mediainfo can show parameters [20:10] <Mavrik> you can also use ffmpeg's "frameinfo" filter to see how often they showup [20:11] <Mavrik> also, I've used "StreamEye" software at work to show me that info [20:11] <Mavrik> schtinky, usually it's about once per second for TV-streamed TS and much rarer on everything else [20:11] <schtinky> interesting [20:11] <schtinky> so in theory, given a TV mpeg-ts stream, I should be able to directly extract i-frames [20:12] <Mavrik> yeah, but you still need to decompress them :) [20:12] <schtinky> you said "encoded fully", if it's an image, what format is that? [20:12] <schtinky> it's no longer MPEG-TS, it's what, png? jpeg? [20:13] <Mavrik> um, it's something else :) [20:13] <Mavrik> MPEG formats have their own way of encoding images [20:15] <schtinky> ok thanks for the help mavrik. it's getting more complicated than it needs to be. I'll just use ffmpeg. I assume ffmpeg extracts images in the most efficient way possible anyway [20:15] <Mavrik> that's correct :) [20:15] <Mavrik> schtinky, what's your usecase? [20:15] <schtinky> grabbing still frames from ATSC TV signal [20:16] <schtinky> hardware encoder grabs in MPEG-TS [20:16] <Mavrik> ah, on what interval? [20:16] <johnny_|_> Hi. I am on OS X 10.7.3, nvidia 8800 GT and I get: "[h264_vda @ 0x&.]Failed to init VDA decoder: -12473.". Is it because outdated hardware? [20:16] <schtinky> using ffmpeg to grab a frame every second, wondering if I could just grab them raw [20:16] <schtinky> apparently not [20:16] <Mavrik> schtinky, nah, just decoding the stream and grabbing frame each second is ok [20:16] <Mavrik> schtinky, look at "select" filter [20:16] <Mavrik> to filter them out and just set png output or something [20:18] <schtinky> ok it's not computing yet. I'm using image output with %3d.jpg (or similar) and it's taking quite a bit of CPU [20:18] <schtinky> are you saying select can do it more efficiently? [20:18] <schtinky> when you say "them" what is "them"? The iframes? Or my once-per-second frames? [20:19] <Mavrik> schtinky, "select" basically just (heh) selects frame by the criteria you choose and throws away everything else [20:19] <Mavrik> schtinky, so if you set it to select one frame every second [20:20] <Mavrik> you won't have to save 25 PNGs each second :) [20:20] <Mavrik> which will be noticable on your CPU [20:27] <schtinky> mavrik, whoa, that filter gave me tons of iframes [20:29] <schtinky> ffmpeg -i test0.mpg -vf "select=eq(pict_type\,I)" /hoozon/test/%3d.jpg [20:29] <schtinky> that just gave me 2200 images for a 10-15 second video [20:30] <schtinky> oops, 38 seconds, but still [20:30] <Mavrik> huh? that seems unlikely [20:30] <Mavrik> you couldn't have more than a 1000 frames in 38 secs [20:30] <schtinky> and they're all very pixelated [20:31] <schtinky> you can make out what it is, but it's like encoding at 100kbps or something [20:31] <schtinky> that's the quality [20:31] <durandal_1707> because of jpg output [20:31] <Mavrik> schtinky, well you're not setting jpeg quality anywhere ;) [20:31] <Mavrik> use qscale parameter [20:32] <schtinky> ah, right [20:32] <Mavrik> schtinky, qscale 0 being best, 31 worst [20:32] <schtinky> but why 2200 frames? [20:32] <Mavrik> no idea :) [20:34] <schtinky> changed it to png, still wrote 2200 frames. That's an SSD killer :) [20:34] <Mavrik> ;) [20:34] <schtinky> high quality, though [20:35] <durandal_1707> png is lossless (slow zlib compression) [20:37] <schtinky> http://pastebin.mozilla.org/2251415 [20:37] <schtinky> and yes, it's the yum version [20:37] <schtinky> packaged, I mean, whatever [20:41] <Mavrik> um, for some reason ffmpeg created 2200 duplicate frames O.o [20:41] <Mavrik> 68fps input video? :) [20:42] <ubitux> try to -vsync cfr [20:43] <ubitux> -vsync vfr sorry [20:43] <ubitux> Mavrik: see https://ffmpeg.org/trac/ffmpeg/ticket/1644 [20:43] <ubitux> well, schtinky actually. [20:49] <schtinky> nice, I got 2 frames per second, high quality, huge reduction in CPU [20:49] <schtinky> any idea why 2 frames per second, though? [20:50] <Mavrik> becuase the video has 2 I-frames per second? :) [21:21] <Smashcat> Hi, id ffmpeg==avconv ? [21:21] <Smashcat> *is [21:26] <Smashcat> Ok thanks. So they should take the same arguments I guess. avconv is crashing out while trying to create an h264 video from images (ubuntu 12.10 here). I'll see if I can get a copy of ffmpeg and see if that can do it [21:28] <Smashcat> The error is "This stream was generated by a broken encoder, invalid 8x8 inference". And it helpfully generates a video of 0 bytes size :) [21:28] <Mavrik> there are subtle differences in arguments and implementation [21:28] <Mavrik> I suggest you ask people on #libav [21:28] <Smashcat> ok thanks [22:31] <i_s> i'm trying to build an old version of ffmpeg, and i'm getting this error: No rule to make target `libavcodec/hpel_template.c', needed by `libavcodec/dsputil.o'. Stop. [22:32] <i_s> anyone know what is wrong? [23:46] <Picola-GR> hello is there a way to append the output of ffmpeg to a file? [23:46] <Picola-GR> like for example convert file1, file2 and concat both files into file3 [23:49] <klaxa> http://ffmpeg.org/trac/ffmpeg/wiki/How%20to%20concatenate%20%28join,%20merg… [23:49] <klaxa> Picola-GR: ^ [23:50] <Picola-GR> thanks [00:00] --- Thu Mar 28 2013

1 0

ffmpeg-devel.log.20130326
by burek 27 Mar '13

27 Mar '13

[00:34] <saste> ubitux: http://vimeo.com/enhancer?utm_campaign=2262&utm_medium=newsletter-features-… [00:34] <saste> for more preset ideas :) [00:59] <ubitux> saste: add any you want [01:09] <saste> ubitux, pink-saste-sunshine [01:09] <ubitux> :) [01:09] <ubitux> saste: note that those filters also have an advanced noise filter [01:10] <ubitux> afaict [01:10] <saste> and some addgrain filters [01:10] <ubitux> yeah well, grain/noise [01:26] <ubitux> i get fun output with the phasescope filter from Paul :) [02:00] <FFmpeg-github> 01[13FFmpeg01] 15michaelni pushed 5 new commits to 06master: 02http://git.io/sSjItg [02:01] <FFmpeg-github> 13FFmpeg/06master 14dc65d78 15Clément BSsch: lavfi/curves: add presets support.... [02:01] <FFmpeg-github> 13FFmpeg/06master 14183f345 15Clément BSsch: lavfi/curves: support preset shorthand. [02:01] <FFmpeg-github> 13FFmpeg/06master 14133035c 15Clément BSsch: lavfi/curves: add forgotten strong_contrast preset. [04:09] <cone-338> ffmpeg.git 03Michael Niedermayer 07master:ea7b96af961e: avcodec/x86/dsputil_qns_template: use av_assert [04:10] <FFmpeg-github> 01[13FFmpeg01] 15michaelni pushed 4 new commits to 06master: 02http://git.io/PAGY4g [04:10] <FFmpeg-github> 13FFmpeg/06master 14e600d06 15Clément BSsch: lavfi/perms: remove unecessary indirection after f7324c06. [04:10] <FFmpeg-github> 13FFmpeg/06master 149371467 15Clément BSsch: lavfi/perms: add seed option. [04:10] <FFmpeg-github> 13FFmpeg/06master 14e32cbd0 15Clément BSsch: lavfi/perms: add myself to the copyright header. [09:11] <Granjow> I am again trying to figure out why seeking fails so terribly (ffmpegsource does not seem so easy to use at first glance) [09:12] <Granjow> For example, I seek to frame 39 in my avi file, and ffmpeg says, yes, you successfully decoded PTS 39 DTS 39 at position 8269008 [09:13] <Granjow> unfortunately this is frame 61 (DTS/PTS) and 39 would be at 4891856 [09:14] <Granjow> as of my understanding, this is off by a tiny bit [09:15] <av500> a tiny wee bit [09:33] <TheFluff> 09:11:52 < Granjow> I am again trying to figure out why seeking fails so terribly (ffmpegsource does not seem so easy to use at first glance) <-- if you think ffms is hard to use and ffmpeg itself isn't then I really dunno what to say to help you [09:41] <Granjow> TheFluff: ffmpegsource says it needs Haali's Media Splitter for seeking in MPEG. Its page is offline. Well, in case that this does not affect MJPEG, it might work ... [09:42] <TheFluff> it refers to the mpeg ts/ps containers only [09:42] <TheFluff> and you had avi, did you not? [09:43] <Granjow> ah. Yes. [09:43] <TheFluff> also, it's an optional component [09:43] <TheFluff> it can work with lavf too, it's just that lavf hates seeking in ts [09:45] <Granjow> Where am I supposed to find libavresample/avresample.h? [09:48] <Granjow> Hm, I guess it is not in 0.10.2 yet? [09:54] <ubitux> 0.10.2 might have libswresample [09:54] <ubitux> but 0.10 is very old [09:54] <ubitux> libavresample is not really supported in ffmpeg anyway [09:59] <Granjow> Okay, git says it is not. Problem is, the project has to run on Windows, and MXE for cross-compiling only has 0.10.2 in its repositories. Afair I tried to and miserably failed in compiling ffmpeg myself on mxe ... [10:00] <Granjow> ubitux: Well, ffmpegsource relies on it [10:00] <Granjow> but maybe I can convince it otherwise [10:01] <Granjow> or maybe I just check out an older version of ffmpegsource :-] [10:02] <TheFluff> you can download a precompiled binary you know [10:02] <TheFluff> there's an sdk download link [10:05] <ubitux> http://www.sview.ru/en/sview2009/info is the ugly interlacing supposed to make a 3d effect? [10:08] <Granjow> TheFluff: precompiled binary of ffmpegsource? [10:10] <TheFluff> https://code.google.com/p/ffmpegsource/downloads/detail?name=ffms-2.17-sdk.… [10:12] <Granjow> I'd rather re-write ffmpeg from scratch than trying to compille with VS [10:13] <Granjow> had enough pain with it, and at one point in time it is enough ;) [10:13] <ubitux> it should be relatively trivial now to compile ffmpeg with VS [10:13] <Granjow> mxe also has the benefit that I can do automated builds on Linux [10:14] <Granjow> Well, last time it was trivial to get all sorts of compiler errors, I spent days on it and nothing good came from the attempts [10:14] <TheFluff> if you want to do automated builds on linux then maybe you should actually build a version that isn't ancient~ [10:14] <TheFluff> just saying [10:14] <ubitux> Granjow: https://www.ffmpeg.org/platform.html#Microsoft-Visual-C_002b_002b [10:18] <Granjow> better ancient than broken, as ffmpeg's seeking appears to be [10:22] <ubitux> can you reproduce the seeking problem with a recent FFmpeg and the ffmpeg tool? [10:27] <Granjow> ubitux: I just have 1.0.4 installed. Could try 1.0.6. (0.10.2 is for the Windows build.) [10:29] <ubitux> can you share a sample so we can reproduce? [10:32] <Granjow> ubitux: Sure, avi is here http://granjow.net/uploads/temp/seeking.avi (400 MB), uploaded yesterday. Code is at git://granjow.net/phenoCam.git, branch seeking, executable can be built with «mkdir build; cmake ../src; make seeking» [10:33] <Granjow> in src/test/seeking.cpp [10:33] <Granjow> though you may want to test with your own code which is more likely to be using ffmpeg correctly [10:35] <ubitux> there is no frame seek in ffmpeg btw [10:36] <ubitux> mmh wait, we have AVSEEK_FLAG_FRAME though [10:37] <ubitux> i'm guessing it doesn't work though :p [10:37] <Granjow> ubitux: The docs says it seeks to keyframes. The video has nothing else but keyframes. [10:37] <Granjow> So either my code is wrong, or the docs are. [10:40] <TheFluff> I don't think AVSEEK_FLAG_FRAME has ever done what the docs claims it does [10:41] <nevcairiel> i dont think it does much at all [10:41] <TheFluff> this is why you let someone else figure out this stuff for you [10:43] <Granjow> Well, I don't even use it, actually. Or, it makes no difference in the result. [10:53] <TheFluff> well [10:54] <TheFluff> I'd still say it'd be much more productive to just use ffms [10:54] <TheFluff> but that's just me [10:54] <TheFluff> vOv [10:55] <Granjow> TheFluff: Still trying to integrate it into CMake. [10:59] <Granjow> would be much easier if ffmpeg just worked. [10:59] <av500> +1 [10:59] <av500> and seeking in avi is at least not hard [10:59] <av500> since you have an index entry for every frame [11:00] <av500> and its CFR [11:11] <Granjow> ha ha very funny. Even when I seek to Byte 4653016 (lower bound 3653016) it arrives at 8294840 [11:12] <Granjow> (i.e. with avformat_seek_file) [11:14] <Granjow> If I seek to frame 0 and then continue until I arrive at byte 4653016 by just reading frames it works [11:16] <Granjow> I wonder why ffmpeg always shows an offset of 8 compared to the table displayed by aviindex [11:16] <Granjow> maybe this breaks seeking :P [11:17] <av500> Granjow: because it reads the 4+4 byte header before the actual data [11:18] <av500> 00wb and the 4 byte frame size [11:18] <av500> and returns that as pos [11:25] <Granjow> Okay. [11:26] <Granjow> But either the video or the code is broken, as not even the DTS values returned are correct when seeking. [11:33] <av500> its possible that there is a bug, yes :) [11:54] <Granjow> later [12:23] <cehoyos> nevcairiel: If you look into this DShow installer: http://polppolservice.com/ul/index.php?dir=CCTV/&file=EN-Hik_DSFilters_V6.0… Do you see for which kind of files the splitter is used? Ie how does it know that a particular file should be handled with this splitter? (vlc ticket 8344) [13:10] <cone-921> ffmpeg.git 03Janne Grunau 07master:e5c2794a7162: x86: consistently use unaligned movs in the unaligned bswap [13:10] <cone-921> ffmpeg.git 03Michael Niedermayer 07master:cb69a9dbf4c4: Merge commit 'e5c2794a7162e485eefd3133af5b98fd31386aeb' [13:10] <cone-921> ffmpeg.git 03Michael Niedermayer 07master:9b9205e760d2: x86/dsputil.asm: make unaligned bswap actually work [13:18] <Compn> cehoyos : isnt that set using GUID in the registry ? [13:18] <Compn> or somewhere in directshow stuff [13:18] <Compn> i mean, the filter pin has a guid , directshow uses it based on the file / riff [13:18] <cehoyos> Compn: That is my question. [13:19] <cone-921> ffmpeg.git 03Martin Storsjö 07master:ccd349e555d8: h264: Remove an unused variable [13:19] <cone-921> ffmpeg.git 03Kostya Shishkov 07master:613a37eca4c7: ape: 3.80-3.92 decoding support [13:19] <cone-921> ffmpeg.git 03Michael Niedermayer 07master:795b911bd8ac: Merge commit '613a37eca4c7b8eefceaa3e0231c23ad090ca94f' [13:19] <Compn> is that hikvision? http://samples.ffmpeg.org/camera-dvr/hikvision/ [13:20] <cehoyos> Iiuc, the company produces many cameras (with may formats), my patch and question are about vlc ticket 8344 [13:21] <Compn> erm so whats the question again ? [13:21] <Compn> you want the guid of the installed filters ? or ? [13:22] <cehoyos> How does WMP know that is should use the newly installed splitter for a particular file? [13:22] <Compn> "where in the file is it looking for the hikvision riff" ? [13:22] <Compn> riff/identification ? [13:23] <Compn> there was a document that explains this [13:23] <Compn> somewhere [13:23] <cehoyos> More like "What is the hikvision riff" but that already assumes that there is a "riff" concept in the file while it actually is a mpeg program stream [13:23] <Compn> lets see if i can find it [13:23] <Compn> i understand [13:24] <Compn> so theres not a certain mpeg_ps stream 0xwhatever that declares hikvision ? [13:24] <cehoyos> And this should of course not be "What is the hikvision riff" but "What is the riff (assuming this is the right word) in the given sample." [13:24] <Compn> When WMP requests DirectShow to render a file, filter graph manager goes through existng file and protocol associations in order to pick proper source filter. That is, the filter of interest needs to be registered as described in the following MSDN topic: [13:24] <Compn> http://stackoverflow.com/questions/13745383/provide-directshow-filter-for-w… [13:25] <Compn> http://msdn.microsoft.com/en-us/library/windows/desktop/dd377513(v=vs.85).a… [13:25] <cehoyos> My question is now: What is done for this installer: http://polppolservice.com/ul/index.php?dir=CCTV/&file=EN-Hik_DSFilters_V6.0… [13:26] <Compn> These are ulaw and alaw. G711a is alaw and G711u is ulaw. [13:26] <Compn> according to google ^ [13:27] <Compn> you should be able to get the registered filetypes and 'riff' by using graphedit after you install those codecs [13:27] <Compn> i guess i could try it on my winxp box [13:28] <cehoyos> Without knowing much about DShow, I assume you are talking about "decoders" (however they are called in DShow language), but my question is how does WMP know it should use the newly installed demuxer for a particular file? [13:28] <cone-921> ffmpeg.git 03Martin Storsjö 07master:75644335b907: lavc: Move start code finding to utils.c [13:28] <cone-921> ffmpeg.git 03Michael Niedermayer 07master:2cdedcbceab9: Merge commit '75644335b907919057960716508477239c26fed4' [13:28] <cone-921> ffmpeg.git 03Michael Niedermayer 07master:7834bb092a95: Revert "Fix compilation with --disable-everything --enable-parser=h264." [13:28] <cehoyos> michaelni: Thank you! [13:28] <Compn> directshow scans the file, then it looks for any splitter (demuxer) and decoder that handles that file [13:29] <cehoyos> So what does it look for to choose the splitter in http://polppolservice.com/ul/index.php?dir=CCTV/&file=EN-Hik_DSFilters_V6.0… ? [13:29] <Compn> let me install this and find out [13:30] <durandal11707> ubitux: i can't find that hack for min/max_samples [13:31] <ubitux> //* This is currently necessary for the min/max samples to work properly. * FIXME: remove me when possible */ [13:31] <ubitux> this ^ [13:31] <ubitux> audio_request_frame [13:34] <Compn> cehoyos : this comes up in my search, its what the installer adds to windows registry and files > http://www.siteadvisor.com/sites/60.191.58.151/downloads/32013536/ [13:35] <Compn> cehoyos : but thats not the exact same as the v6 installer... [13:35] <durandal11707> Compn: directshow scans file? i dont think so ... [13:35] <durandal11707> RULE #0 : do not commit hacks [13:35] <cehoyos> My question is now: Do the modifications of the system registry tell you for which kind of files the Hikvision Splitter is used? [13:35] <durandal11707> RULE #1 : revert hacks [13:36] <Compn> durandal11707 : wmp is still able to play files when you rename the file extension :P [13:36] <Compn> cehoyos : good question, no idea :) [13:36] <nevcairiel> cehoyos: it assigns it self for files with .264 and .mp4 extensions, and for files starting with bytes 34484b48 (in hex) [13:37] <cehoyos> thats not the exact same as the v6 installer <-- I am only interested in the installer I linked above because that installer allows (supposedly) to play the file in question [13:37] <cehoyos> nevcairiel: Is 34484b48 IMKH ? [13:37] <nevcairiel> at least the info Compn linked, the thing is downloading very slow [13:37] <cehoyos> (Sorry!) [13:38] Action: Compn looks at hex to ascii converter [13:38] <durandal11707> cehoyos: nope [13:38] <Compn> nevcairiel : it wasnt slow for me. i can send the zip to you if you want [13:38] <nevcairiel> 4HKH if my ascii table didnt lie [13:38] <nevcairiel> but anyway, thats the text Compn linked, not the installer [13:38] <Compn> thats an old installer the siteadviser one [13:39] <cehoyos> That is unfortunately a completely unrelated start of file (that is the one we have samples for) [13:39] <nevcairiel> 5 more minutes for the installer =p [13:39] <Compn> ehe [13:39] <cehoyos> .. but cannot decode (durandal11707: That may be something for you) [13:39] <durandal11707> all of this for mulaw/alaw in mpeg? [13:39] <Compn> [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Media Type\ [13:39] <Compn> is where thats stored :P [13:40] <cehoyos> No, for you this is about completely unsupported file, find them at http://samples.ffmpeg.org/camera-dvr/hikvision/ (and leave the trivial issue to me) [13:40] <ubitux> does anyone know if it's possible with the ff tools to force the message repeating? [13:40] <Compn> ubitux : verbose doesnt do it ? [13:41] <ubitux> it seems there is a log flag but it doesn't look settable at cli level, or i miss something [13:41] <ubitux> Compn: mmmh [13:41] <ubitux> nope [13:42] <ubitux> well, whatever [13:43] <Compn> cehoyos : ok i found that key from the new installer in my registry [13:43] <cehoyos> So? [13:44] <cehoyos> Or do you mean: You found IMKH ? [13:44] <Compn> IMKH is there [13:44] <Compn> yes [13:45] <Compn> sorry, i had to hex convert it [13:45] <Compn> looks like the IMKH should be in the same place as 4HKH [13:45] <Compn> if i'm reading this correctly [13:46] <Compn> the file also handles 4MSH [13:46] <Compn> the splitter (demuxer) that is [13:47] <durandal11707> ubitux: swap what? I just replaced private time_base with frame_rate which actually is. So if setting frame_rate instead of time_base makes sense it should be done in another commit because that changes functionality [13:47] <ubitux> test->time_base.num = frame_rate_q.den; [13:47] <ubitux> test->time_base.den = frame_rate_q.num; [13:48] <ubitux> there is num/den swap which you seem to have removed [13:48] <ubitux> or did i miss something? [13:49] <durandal11707> ahh [13:49] <durandal11707> i did not noticed this nonsense [13:49] Action: Compn goes afk [13:50] <ubitux> durandal11707: fate wasn't complaining btw? [13:50] <durandal11707> there is invert? [13:50] <durandal11707> ubitux: doesn't belive in fate [13:51] <Compn> cehoyos : let me know if you want a screenshot of my registry :P [13:51] Action: Compn gone [13:51] <cehoyos> Compn, nevcairiel: Thank you for answering question 1 (of two), the second one is more difficult for me to express because my DShow knowledge is 0: [13:51] <cone-921> ffmpeg.git 03Martin Storsjö 07master:f1e9398621af: lavc: Rename avpriv_mpv_find_start_code after moving out from mpegvideo [13:51] <cone-921> ffmpeg.git 03Michael Niedermayer 07master:b19604cc4bbf: Merge commit 'f1e9398621af0bc9d166014e4ce6996bb4f141d0' [13:52] <cehoyos> How is mulaw chosen? Does the splitter set "mulaw" or does it set some value that is then again searched for in the registry? [13:53] <cehoyos> The mpegps file in question uses the default (correct) stream_format for H264 and 0x91 for mulaw. [13:53] <nevcairiel> formats are identified by a GUID, so it somehow has to create a GUID for the audio stream, which is then looked up in the registry [13:53] <cehoyos> Iiuc, 0x91 can be AC-3, so it is not a good idea to always choose mulaw for 0x91 [13:53] <nevcairiel> usually audio/video use a FourCC based format, where the first 4 byte are the FourCC and the other bytes a static postfix [13:54] <cehoyos> And is it possible to find out how the splitter sets the guid (because of which stream_format) or would that already require reverse-engineering? [13:54] <nevcairiel> thats totally up to it, so you would need to RE that [13:54] <cehoyos> Can you verify that 0x91 can be AC-3 ? [13:55] <Compn> where can we go to get a list of mpeg stream hexs ? [13:55] <cehoyos> (Do you already have the installer?) [13:55] <cehoyos> http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/M2TS.html [13:56] <durandal11707> run your favorite dissasembler [13:56] <nevcairiel> 0x81 seems to be AC3 [13:56] <nevcairiel> never heard of 0x91 [13:56] <cehoyos> Yes, I found some sites without sources that claim 0x91 is also AC-3 [13:56] <nevcairiel> and neither has our mpegts demuxer [13:57] <cehoyos> AC-3 can be auto-detected, so users will not report such samples;-( [13:58] <cehoyos> This site claims 0x91 is A52b: http://erato1004.tistory.com/entry/mpeg-stream-type [13:58] <nevcairiel> 0x91 is standardized for Blu-rays to be the IG stream (interactive graphics, ie. the menu) [13:59] <cehoyos> Are they supposed to be equal for ps and ts? [14:00] <cehoyos> How does the GUID look like that is registered for mulaw for the mentioned installer? [14:00] <cehoyos> (Does it point to "0x91"?) [14:01] <nevcairiel> it seems to use a completely random GUID [14:01] <Compn> it installs 'g711' codec [14:01] <Compn> g711codc.ax [14:02] <cehoyos> And which GUID's are associated with that codec? (Or do I misunderstand?) [14:03] <nevcairiel> Compn: i dont see g711codc.ax [14:03] <nevcairiel> only HikDecoder.ax [14:03] <Compn> cehoyos : other directshow audio decoders are set correctly, for example, acelp sipro is set to 'subtype: fourcc' 00000130 (aka 0x130) [14:04] <Compn> nevcairiel : oh, maybe its unrelated file then... [14:04] <nevcairiel> hikdecoder.ax uses {0F41A4CC-57F2-4378-A240-7665889AD3B0} [14:04] <nevcairiel> which is just a random guid [14:05] <Compn> but thats because sipro is only found in avi or wav, which uses fourccs and riffs ... [14:06] <durandal11707> w64, asf and maybe others use guids [14:07] <Compn> http://bbs.csdn.net/topics/240081106 [14:08] <Compn> is definitely something to do with the hikvision ax [14:08] <cehoyos> nevcairiel: User KuroiTsuki (and I) would like to know why mingw is so bad (ie how can we see it is bad)? [14:08] <nevcairiel> you mean classic mingw? [14:08] <cehoyos> Yes [14:08] <cehoyos> http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/160953/focus=160956 [14:08] <nevcairiel> becuase mingw-w64 is just fine [14:09] <cehoyos> Sorry, but that is not 100% convincing;-) [14:09] <nevcairiel> mostly because its outdated and abandoned [14:09] <Compn> did mingw ever fix the 4gb limit on files ? [14:09] <Compn> the off_t thing [14:09] <Compn> sherpya has a long standing patch for mingw system headers [14:09] <nevcairiel> it doesn't support many windows APIs [14:10] <nevcairiel> for example, windows has aligned memory allocations, which avutil/mem.c can even use, but not with mingw32, so it has to fallback to its own memory hack [14:10] <cehoyos> Let me try again: If I compile a pre-atomic version of FFmpeg with mingw(old), does it have any disadvantages over mingw64? [14:10] <nevcairiel> there are several of such cases [14:11] <JEEB> other than the atomics, it's mostly the memalign hack [14:11] <JEEB> and then possibly some other things [14:11] <cehoyos> So mingw-64 does allow aligned allocation, mingw not? [14:11] <nevcairiel> there are alot of improvements to the gnu string fucntions that are badly emulated in mingw32, not sure how much that is of consequence [14:11] Action: durandal11707 wants coverage for mandelbrot, cellauto, ..., generally for libavfilter [14:11] Action: Compn afk [14:11] <JEEB> oh right, mingw-w64 doesn't let you use BBB's windows compat stuff for the string stuff [14:11] <JEEB> uhh [14:11] <JEEB> wrote that wrong [14:12] <JEEB> !mingw-w64 [14:12] <JEEB> is what I meant :P [14:12] <Compn> cehoyos : ask sherpya about mingw v mingw64 , http://oss.netfarm.it/mplayer-win32.php [14:12] <JEEB> the stuff that's in compat/win32 IIRC [14:12] <JEEB> that doesn't get enabled with ye olde mingw at least [14:12] <nevcairiel> not to mention that mingw32 has no support for 64-bit and as of gcc 4.8, even gcc requires mingw-w64 [14:12] <JEEB> (mingw32 is mostly limited to Win2000 APIs) [14:13] <Compn> ehe [14:13] <nevcairiel> cehoyos: the real question is, why do people feel they need to stick to mingw32? [14:13] <cehoyos> Compn: But I wanted to ask the developer who wrote on ffmpeg-devel that mingw is old and deprecated (I don't claim that this is not true, I was simply - together with a user who has already left this channel - searching for an explanation) [14:13] <Compn> :) [14:13] <JEEB> well [14:13] <JEEB> 1) mingw32 is old [14:13] <cehoyos> nevcairiel: Because nobody told them (me) that there is something else [14:13] <nevcairiel> oh and mingw32 doesnt come with dxva2 headers [14:14] <JEEB> 2) a dead project most probably can't call itself "deprecated" [14:14] <nevcairiel> so you cant use it [14:14] <JEEB> nevcairiel, yes because that stuff came after windows 2000 :D [14:14] <cehoyos> But despite the existing headers, you still did not review the dxva decoding patch... (or did you and it was abandoned?) [14:14] <JEEB> or I'm not sure if the project is dead, but I'd bet my backside on the CVS being (mostly) dead [14:15] <nevcairiel> I'm not all that motivated to review a patch that i think is conceptually wrong [14:15] <nevcairiel> hm that word seems wrong [14:15] <cehoyos> https://ffmpeg.org/platform.html#Native-Windows-compilation-using-MinGW-or-… doesn't sound as if we would recommend against mingw [14:15] <nevcairiel> old docs are old? [14:16] <nevcairiel> of course it works, or well at least it worked [14:16] <nevcairiel> but i wonder how many hacks are hidden for old mingw versions [14:16] <cehoyos> We cannot test VDPAU easily, I fear that stagefright might not even compile, so if there is a possibility to test dxva I don't think a conceptual wrongness should stop the patch. [14:17] <durandal11707> see RULE #0 [14:17] <nevcairiel> i wont let dxva be broken for a long time, dont worry :P [14:17] <nevcairiel> my users would kill me [14:17] <JEEB> nevcairiel, disabling threads and it compiles... with all of those ye olde hacks :D [14:17] <cehoyos> But it would be even easier for you if Michael would already see the problems on fate [14:18] <nevcairiel> fate is problematic for dxva. my boxes are on windows, but they are servers with no dxva capable gpu, and i wonder if anyone else would have one =P [14:19] <cehoyos> I remember, but this would still allow developers to (theoretically) test it. [14:19] <nevcairiel> because its a runtime dependency, its hard to automatically test it [14:20] <cehoyos> Simply disable-decoder=h264 ? [14:21] <cehoyos> You mean the gpu is a run-time dependency: Of course this is a problem, but it would still mean that dxva could be tested from inside FFmpeg [14:21] <cehoyos> (And perhaps we can give you a gpu.) [14:21] <nevcairiel> anyhow, i would rather put some energy into gwenoles plans for HWAccel v2 which is supposed to take a lot of the leg-work away from the applications [14:22] <nevcairiel> its not like i dont have a gpu, its a server and didnt need one :) [14:22] <nevcairiel> i think i would even have one in some closet that would work for basic testing :p [14:22] <cehoyos> As long as it doesn't break VDPAU deinterlacing, I am certainly not against it;-) [14:24] <iive> nevcairiel: I was thinking about implementing the X specific functions for hw decoding in libavdevice or something... [14:25] <durandal11707> but anton want to merge libavdevice into libavformat [14:25] <cehoyos> Concerning mingw: I found this on the mailing list: "things that are known to be broken with [mingw]", so I am now curious what this is. [14:27] <nevcairiel> atomics are known to be broken :) [14:28] <nevcairiel> most other broken things have been worked around over the years, i dont really remember specifics anymore [14:28] <cehoyos> All-in-all, this does not sound extremely convincing... [14:28] <nevcairiel> but as devs are moving forward, it will break more often in the future [14:28] <cehoyos> I thought you were writing about bugs that can be reproduced, not bugs that cannot be reproduced because work-arounds exist. [14:29] <nevcairiel> the fact that workarounds are required should already be convincing enough to suggest a better version (with no known drawbacks) :) [14:29] <cehoyos> KuroiTsuki (the user with the compilation problem) now claims that there is no toolchain for mingw-w64 [14:29] <cehoyos> Where can it be found? [14:29] <cone-921> ffmpeg.git 03Paul B Mahol 07master:7606f4a1af7d: lavfi/fps: make use of AV_OPT_TYPE_VIDEO_RATE [14:29] <cone-921> ffmpeg.git 03Paul B Mahol 07master:54056c6655c2: lavfi/testsrc: make use of AV_OPT_TYPE_VIDEO_RATE [14:29] <cone-921> ffmpeg.git 03Paul B Mahol 07master:975efc8864a9: lavfi/mandelbrot: make use of AV_OPT_TYPE_VIDEO_RATE [14:29] <cone-921> ffmpeg.git 03Paul B Mahol 07master:8c5b37b4022d: lavfi/life: make use of AV_OPT_TYPE_VIDEO_RATE [14:29] <cone-921> ffmpeg.git 03Paul B Mahol 07master:401f9c95e9ad: lavfi/cellauto: make use of AV_OPT_TYPE_VIDEO_RATE [14:29] <cone-921> ffmpeg.git 03Paul B Mahol 07master:62d36abef4b7: lavfi/mptestsrc: make use of AV_OPT_TYPE_VIDEO_RATE [14:30] <cehoyos> Which work-arounds do you mean? [14:30] <nevcairiel> i build a toolchain myself (http://files.1f0.de/mingw/) but i think there is a kinda-official release too [14:31] <cehoyos> (Sorry, I originally found it very likely that mingw is outdated, but the more I ask, the more this sounds like a former FFmpeg developer said to be active on Ubuntu and Debian) [14:31] <durandal11707> mingw is dead. full stop. [14:32] <cehoyos> "FFmpeg is deprecated?" [14:32] <nevcairiel> believe what you want, but in contrast to your comparison, mingw32 is actually dead and no longer under active development and lacks support for any modern Windows APIs [14:32] <cehoyos> or was it "not developed anymore"? [14:33] <cehoyos> I do believe, but I'd like to tell users that ask me something [14:33] <cehoyos> (like where they can find a toolchain, and this information should go to platform.html) [14:34] <durandal11707> you can still find various posts on web, where ubuntu users mention that ffmpeg is deprecated/no more developed [14:34] <cehoyos> Is this what should be used? http://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/ [14:35] <nevcairiel> thats becaue ubuntus "ffmpeg" claims that to be the truth, durandal11707 [14:35] <cehoyos> To tell the truth, it is one liar to claims this. [14:35] <cehoyos> s/to/who [14:35] <nevcairiel> cehoyos: those are source releases [14:36] <cehoyos> Thank you, that is what the user told me;-( [14:36] <iive> even if mingw32 is not developed anymore, I've heard that mingw64 does support 32bit tool chain. [14:36] <cehoyos> He explained that when he saw that mingw is needed to compile mingw-w64, he started to doubt that our (FFmpeg's) reasoning makes sense. [14:36] <nevcairiel> yea dont let yourself be fooled by the name, mingw-w64 can target both 32-bit and 64-bit =p [14:36] <iive> and mingw32 is not the issue here, atomic operations exist only for pthreads. [14:37] <cehoyos> iive: I suspect you are wrong here. [14:37] <nevcairiel> mingw is the issue because it doesnt support windows-native atomics [14:37] <nevcairiel> well sure, you could implement a second fallback for atomics using windows threads [14:38] <nevcairiel> cehoyos: the official builds they host seem to be mostly focused for building win32 apps on linux, not win32 apps on windows [14:39] <nevcairiel> for all i care, you can link my toolchain folder, i can even give it a nicer index page instead of the apache folder index :p [14:39] <cehoyos> I have hear/read this before - it is extremely difficult to understand for me - it is in a way above my "Wahrnehmung" [14:40] <iive> oh, the code is in atomic_win32.h [14:40] <iive> so it is configure test failing? [14:40] <nevcairiel> its mingw32 lacking proper header support for those [14:40] <cehoyos> iive: No, see ticket 2363 [14:40] <nevcairiel> in a perfect world, a gcc compiler should also use the gcc atomics [14:41] <nevcairiel> but apparently the default mingw32 mode doesn't enable them [14:41] <nevcairiel> unless you use --arch=i486 or anything higher [14:41] <cone-921> ffmpeg.git 03Ronald S. Bultje 07master:0b499c9b06b2: h264: Make it possible to compile without error_resilience [14:41] <cone-921> ffmpeg.git 03Michael Niedermayer 07master:365ad0042a63: Merge remote-tracking branch 'qatar/master' [14:42] <cehoyos> nevcairiel: Did you test this? (I can, but not atm) [14:43] <nevcairiel> i know that i686 fixes it, i believe i saw wbs referring to i486 also unlocking it when the topic came up over there [14:43] <cehoyos> Because in this case, it should be easy to fix, I don't think i386 support should be a primary concern. [14:44] <iive> the kernel removed smp i386 support... [14:45] <cehoyos> Wasn't i386 support actually removed? (not only smp) [14:46] <nevcairiel> https://bugzilla.libav.org/show_bug.cgi?id=471 [14:46] <nevcairiel> there, a user tested --march=i486 and it worked [14:53] <durandal11707> where are those unsupported samples which are actually just uncompressed video [14:53] <cehoyos> durandal: Which samples do you mean? [14:53] <cone-921> ffmpeg.git 03Michael Niedermayer 07master:79c845659afa: configure: the snow encoder is not supposed to depend on error resilience [14:53] <cone-921> ffmpeg.git 03Michael Niedermayer 07master:07d405cc9ec4: configure: mpegvideo should not depend on error resilience [14:54] <durandal11707> cehoyos: any which is unsupported but have fourcc such that is obvious it is uncompressed [14:54] <cehoyos> Sorry, I don't understand (I thought you are maybe referring to the Hikvision samples) [14:54] <durandal11707> what about gsoc task: rewrite libswscale (have this been mentioned already?) [14:55] <cehoyos> Please don't! [14:55] <cehoyos> Two fat trolls are really enough on this channel;-) [14:55] <durandal11707> but current libswscale does not support 99% of interleaved yuv formats [14:56] <cehoyos> Given that the usual protest is "it is too convoluted" I am not convinced this argument is 100% useful [14:56] <durandal11707> and sure code can look much better [14:57] <cehoyos> And I believe it should support formats that are output by compressed codecs and/or can be output on devices [15:05] <durandal_1707> ubitux: heard about BS.1770 ? [15:05] <ubitux> yes [15:05] <ubitux> that's the basis for ebu r128 [15:07] <kierank> 13:56:03 <"durandal11707> but current libswscale does not support 99% of interleaved yuv formats --> ? [15:07] <kierank> like what? [15:07] <kierank> nv12, uyvy are supported [15:08] <nevcairiel> all the stuff we have decoders for instead [15:08] <nevcairiel> Y210 etc [15:08] <cehoyos> Probably v210 ;-)) [15:08] <nevcairiel> oh yeah, it was v, not a Y [15:08] <kierank> oh yeah the unaligned stuff [15:10] <durandal_1707> and others for which we do not have decoders ... [15:11] <kierank> i don't think there are many other yuv packings [15:12] <durandal_1707> all interleaved variants of planar ones [15:12] <cehoyos> nevcairiel: The user reports that i486 does not work (I will test myself, but not atm) [15:13] <kierank> 14:12:41 <"durandal_1707> all interleaved variants of planar ones --> such as? [15:19] <durandal_1707> kierank: see fourcc site [15:20] <kierank> most of those are theoretical [15:22] <cone-921> ffmpeg.git 03Carl Eugen Hoyos 07master:8af593dd8079: mpegtsenc: Only test the first frame for missing h264_mp4toannexb filter. [15:22] <cone-921> ffmpeg.git 03Carl Eugen Hoyos 07master:1741fece7073: Only test the first frame for missing aac_adtstoasc bistream filter. [15:28] <ubitux> huh? [15:29] <durandal_1707> huh for what? [15:29] <ubitux> i don't understand 1741fece very well [15:30] <ubitux> cehoyos: a more explicit warning would have been welcome btw :p [15:30] <cehoyos> Michael also wanted that but I am not sure I understand what is more explicit when remuxing than "invalid bitstream" [15:32] <ubitux> i'm refering to "aac bitstream error" [15:36] <cehoyos> nevcairiel: The user reports that -march=i686 does not work either [15:37] <nevcairiel> dont trust a user =p [15:38] <nevcairiel> --extra-cflags=-march=i686 ? [15:39] <nevcairiel> or --arch=i686? [15:39] <nevcairiel> aactually, it should be --cpu=i686 if you want to use configure's mechanism [15:40] <nevcairiel> but extra-cflags should work [15:40] <nevcairiel> unless their compiler is way too old [15:40] <cehoyos> arch makes no difference here for a native Linux compilation, so I wonder what it will change on MSYS/mingw, I did not test the other yet [15:41] <nevcairiel> --arch is wrong, it just switches between x86 and x86_64 .. --cpu should set the compiler -march option, and extra-clfags does the same [15:42] <nevcairiel> --cpu=i686 should also make the build a bit faster because it enables some optimizations like cmov and fast_cmov based code [15:44] <nevcairiel> or everything via --extra-cflags ;) [16:40] <josetorn> Works perfectly for AV_SAMPLE_FMT_FLTP but AV_SAMPLE_FMT_S16P--> int dataSize = swr_convert(resampleCtx, &resampledOut, AVCODEC_MAX_AUDIO_FRAME_SIZE,(const uint8_t**)decoded_frame.extended_data, (decoded_frame.linesize[0]) / (pCodecCtx->channels * 2)); av_fifo_generic_write(fifoPlayback,(uint8_t *)resampledOut,dataSize*pCodecCtx->channels*2,NULL); [16:40] <josetorn> what am i missing here? [16:41] <durandal_1707> that it is extremly unreadeable piece of code [16:42] <josetorn> sorry, 1sec [16:47] <josetorn> http://pastebin.com/MUCJRZbA [16:47] <josetorn> this works perfectly for aac decoded data -> FLTP, but not mp3 decoded data AV_SAMPLE_FMT_S16P [16:48] <durandal_1707> FLTP takes 4 bytes per sample and S16P 2 bytes [16:49] <josetorn> i tried replacing "2" with "1" in (pCodecCtx->channels * 2) [16:49] <josetorn> but it didn't work too [16:50] <durandal_1707> there is nice way to get number of decoded samples [16:52] <durandal_1707> michaelni: what is most efficient way to calculate correlation between two arrays (in this case stereo audio) ? [16:52] <durandal_1707> i found some dumb n! code [16:55] <josetorn> To be used at the last parameter of swr_convert, the only way i know is (decoded_frame.linesize[0]) / (pCodecCtx->channels * 2) [16:55] <josetorn> am i doing wrong by using linesize[0]? [16:57] <durandal_1707> using linesize[] is certainly wrong because it is different for planar [16:58] <durandal_1707> and number of decoder samples per channel is always available in lavc [16:58] <josetorn> may you direct me to the right way? [17:02] <durandal_1707> josetorn: are there examples in source itself? [17:03] <durandal_1707> actually every decoded frame have nb_samples set [17:13] <josetorn> av_fifo_generic_write(fifoPlayback,(uint8_t *)resampledOut,dataSize*decoded_frame.nb_samples,NULL); [17:13] <josetorn> this crashes the app [17:14] <durandal_1707> because its wrong [17:15] <josetorn> i have changed (decoded_frame.linesize[0]) / (pCodecCtx->channels * 2) with decoded_frame.nb_samples) as you've said, for swr_convert [17:16] <durandal_1707> dataSize*decoded_frame.nb_samples ? [17:17] <josetorn> i need the final dataSize, as it is the value given to me by swr_convert [17:18] <durandal_1707> but why multiplication? [17:21] <josetorn> ok. replacing line size etc.. with nb_samples and using this worked: av_fifo_generic_write(fifoPlayback,(uint8_t *)resampledOut,dataSize*pCodecCtx->channels*2,NULL); [17:21] <josetorn> however, this is same with the flip code.. so if flip is 4 bytes, this shouldn't have worked... [17:21] <josetorn> flip = fltp [17:22] <durandal_1707> your code is still so ugly that i do not want waste my time on it [17:23] <michaelni> durandal_1707, correlation or cross correlation ? [17:23] <michaelni> for correlation the naive solution is just O(n) anyway [17:24] <durandal_1707> josetorn: in other words. it use variables to calculate some other variable which it should not - because it works only is special situations..... [17:27] <josetorn> thank you very much durandal_1707 for your time, i will look more into this. [17:35] <durandal_1707> michaelni: you can see "correlation code" in tau function in my jfmeter branch [17:35] <durandal_1707> its copied from meterbridge [17:36] <durandal_1707> the idea is that correlation is used to find out how much two channels differes 1 - mono, -1 out of phase [18:03] <durandal_1707> it mp ivtc filter useful at all? [18:09] <wm4> probably not [18:10] <wm4> let's say it in this way: unless like vf_gradfun etc., it has no fans [18:11] <durandal_1707> remaining filters are more complicated and with inline assembly but with 0 users [18:12] <durandal_1707> also why we have 2 equalization filters? [18:12] <wm4> because mplayer had 2 [18:16] <durandal_1707> still have? [18:18] <durandal_1707> eq2 have big lut16 table - this stinks as "micro optimization" [18:18] <michaelni> durandal_1707, why dont you use a normal correlation coefficient that is sum (a[i]-b[i])^2 style ? but i think your tau function can be implemented in O(n log n) with a balanced tree, dunno if theres a simpler/faster way [18:20] <durandal_1707> michaelni: as i already mentioned i stoled it from meterbridge, and i failed to find any other implementation (and i'm not motiviated to RE other pro tools to find out what they do) [18:21] <durandal_1707> so i just search for pictures on web and try to cargo copy such tech (result may be good laugh) [18:23] <durandal_1707> so expected result from function should be [-1, 1] [18:24] <durandal_1707> 1 you get with mono source [18:25] <durandal_1707> and -1 with phase out channels - when mixing them to produce mono you would get silence [18:26] <ubitux> <@durandal_1707> it mp ivtc filter useful at all? // all the ivtc related filters in mp wrapper will be deleted soon© [18:26] <ubitux> so ivtc, pullup, etc [18:27] <ubitux> i just need to get done with my port [18:27] <michaelni> durandal_1707, a normal correlation coefficient will also behave this way [18:29] <wm4> I get s segfault in ff_mpeg_update_thread_context() when switching video tracks in a mp4/mpeg4 file [18:29] <wm4> libav spams error messages like "get_buffer() cannot be called after ff_thread_finish_setup()" in this case (I'm not overriding get_buffer) [18:30] <durandal_1707> perhaps you need to lock something [18:30] <wm4> dunno if it's my fault, but one issue is that video switching basically feeds random packets to the decoder (random as in it doesn't start with the first packet the demuxer returns) [18:30] <wm4> and it doesn't happen if I force 1 decoding thread (thread_count=1) [18:32] <wm4> another error that happens on the start of track switching: "Context scratch buffers could not be allocated due to unknown size." (that's probably just the decoder being confused, so not an actual issue) [18:32] <wm4> that's libav again (ffmpeg just segfaults) [18:32] <wm4> it also happens only with this specific file [18:33] <wm4> how to proceed? [18:33] <wm4> I think ffplay or ffmpeg don't support this kind of track switching [18:34] <durandal_1707> i see 2 new bug candidates [18:34] <nevcairiel> sounds like you need flush the decoder [18:35] <durandal_1707> wm4: actually ffplay can switch streams [18:35] <wm4> nevcairiel: the decoder is recreated on track switching, so it starts in a fresh state [18:36] <wm4> it just doesn't reset the demuxer [18:36] <nevcairiel> demuxer demuxes all streams separetely, its your duty do pick the stream you want [18:37] <wm4> my point is just that the decoder gets packets from the middle of the stream, which triggers the issue [18:37] <wm4> normally, the decoder will barf some bad frames and then recover on video stream switching (heh) [18:38] <mateo`_> Tjoppen: hello, would you like to review my mxfdec_j2ki branch before I submit it to the ml ? https://github.com/mbouron/FFmpeg/tree/mxfdec_j2ki [18:43] <wm4> here's a sample, it might be possible to reproduce this with mplayer when setting the thread count: http://ompldr.org/vaHcydA [18:44] <wm4> also I think I got this sample from samples.mplayerhq.hu, but I didn't find it again [18:44] <michaelni> durandal_1707, that tau can be implemented with qsort() in n log n time i think [18:48] <durandal_1707> michaelni: why sort? [18:58] <michaelni> sorting the elements pairwise doesnt change the tau value this allows the problem to be simplified to 1 array instead of 2 (as the other array would be sorted then) [18:59] <durandal_1707> but perhaps i actually need cross-correlation [19:00] <michaelni> in a 2nd stage the remaining array can be solved by merging blocks recursively to get the tau value o think [19:00] <michaelni> s/o/i/ [19:01] <michaelni> it ends with O(n log n) too like a tree but probably faster in practice due to higher overhead of trees [19:02] <michaelni> for cross correlation theres the well known FFT based solution [19:13] <durandal_1707> michaelni: so its "n log n" vs "n * (n-1) / 2"? [19:14] <michaelni> yes [19:16] <michaelni> i think it also can be calculated in O(n*m) where m is the number of possible sample values, that is 2^16 for int16_t [19:17] <michaelni> so if you have a really large n that would make it O(n) ... [19:27] <llogan> michaelni: do you know if the ffmpeg server is subscribed to email blacklist services? [19:27] <llogan> who is the admin anyway? [19:29] <llogan> i tried sending a test message to ffmpeg-user from nabble using a non subscribed account and I got nothing in the mod queue (but not 550 5.7.1 message yet either). [19:29] <michaelni> llogan, arpi is the one to speak with about mail on ffmpeg.org unless its something simple [19:30] <llogan> as mentioned by email to ffmpeg-user-owner by michael rampe [19:30] <michaelni> i think ive forwarded him this mail already though [19:32] <llogan> ah, ok. also, i reply to most messages sent to -owner if you were wondering. i just don't always cc you for needless noise [19:32] <llogan> i can if you prefer [19:34] <michaelni> probably good idea to CC me, yes [19:34] <michaelni> or owner [19:35] <wm4> arpi is still active? [19:37] <durandal_1707> hell no [19:56] <saste> llogan, ping on the gsoc blurb [19:57] <llogan> saste: i'll try to work on it today...i got too distracted over the weekend [20:25] <Tjoppen> mateo`_: took a quick peek. looks OK I suppose. the field rate vs. frame rate thing still bothers me [20:26] <Tjoppen> can we use some UL to differentiate the samples? [20:37] <cone-921> ffmpeg.git 03Loren Merritt 07master:064146480b22: tools: add tiny_ssim [20:37] <cone-921> ffmpeg.git 03Michael Niedermayer 07master:4c587b4f3003: tiny_ssim: Avoid "for(int ..." [20:37] <cone-921> ffmpeg.git 03Michael Niedermayer 07master:7b3ca7ae8b51: mpegvideo/h264: drop period_since_free [22:04] <cone-921> ffmpeg.git 03Michael Niedermayer 07master:46c48d546ddf: mpegvideo: fix null pointer dereference on switching streams [22:22] <wm4> michaelni: was that commit for me? it works now [22:22] <wm4> michaelni: and better than libav in this case [22:23] <nevcairiel> speaking of this, the file you linked earlier only had one stream? :) [22:24] <wm4> nevcairiel: doesn't matter, and you still can switch to no-video [22:25] <nevcairiel> if the problem is simply starting payback mid stream, a seek should do I guess [22:25] <nevcairiel> playback [22:25] <wm4> sure, but the point is the decoder shouldn't crash on random input [22:26] <wm4> and in libav, it never recovers [00:00] --- Wed Mar 27 2013

1 0

ffmpeg.log.20130326
by burek 27 Mar '13

27 Mar '13

[02:02] <FergyA> I'm having trouble capturing video from my webcam in raspbian (debian) linux. I'm running the capture on a raspberry pi so I need to capture the raw mjpeg, but whenever I use the copy codec I get buffer underflows about 30 seconds in and the cap dies. I'm using ffmpeg-f video4linux2 -input_format mjpeg -i /dev/video0 -vcodec copy out.mpeg [02:02] <FergyA> anyone able to give any advice? [02:50] <FergyA> I'm using ffmpeg on arch linux to capture a mjpeg stream from a webcam, but for some reason while I'm recording I'm constantly getting "libv4l2: error dequeuing buf: Resource temporarily unavailable" and the video output is choppy. Is there any way to fix this? The command I'm using is ffmpeg -f video4linux2 -input_format mjpeg -r 15 -s 854x480 -i /dev/video0 -vcodec copy out.avi [02:51] <FergyA> one moment [02:53] <ubitux> also, could you compile current git head without "--enable-libv4l2" and try again? [02:54] <FergyA> ummm, if compiling didnt take like 15 hours sure [02:54] <FergyA> im running on a raspberry pi, and crosscompiling is a royal pain [02:54] <ubitux> it will take a while if you're compiling on the r-pi :p [02:55] <ubitux> maybe you can just test: [02:55] <FergyA> and give me a bit longer on the pastebin... my ssh client doesnt have a big enough buffer thanks to all the spam [02:55] <ubitux> forget the pastebin; try with one of the static build here [02:55] <ubitux> iirc they're not build with libv4l2 [02:55] <FergyA> kk [02:56] <FergyA> how would i go about checking what kernel version im running? [02:56] <ubitux> uname -a [02:56] <ubitux> it seems you hit this issue: https://ffmpeg.org/trac/ffmpeg/ticket/2367 [02:56] <FergyA> perfect, ty [02:57] <ubitux> i wonder if you can not just drop the -input_format mjpeg etc [02:57] <ubitux> also, what's your current ffmpeg version? [02:57] <FergyA> ffmpeg version 1.1.3 [02:58] <FergyA> built on Feb 27 2013 01:35:10 with gcc 4.7.2 (GCC) [02:58] <FergyA> and unfortunately those static builds probably wont work for me since im on ARM [02:58] <ubitux> oh, true [02:58] <ubitux> mmh [02:58] <FergyA> let me try a copy of ffmpeg i compiled yesterday... [02:59] <FergyA> from the git [02:59] <FergyA> that was for raspbian, but maybe itll work [02:59] <ubitux> btw, does it work if you remove -input_format mjpeg? [03:00] <FergyA> i get a libv4l2: error allocating conversion buffer [03:00] <FergyA> [video4linux2,v4l2 @ 0xa1d090] mmap: Cannot allocate memory [03:00] <FergyA> /dev/video0: Cannot allocate memory [03:00] <FergyA> if i drop it [03:00] <ubitux> not good [03:00] <ubitux> :P [03:01] <ubitux> well try to upgrade anyway [03:01] <FergyA> yeah, unfortunately im stuck capping in mjpeg as YUV requires encoding [03:01] <ubitux> also, removing --enable-libv4l2 certainly helps [03:01] <FergyA> which a 700mhz arm just cant do on the fly [03:01] <ubitux> check the trac bug issue i pointed out, and feel free to comment here [03:02] <FergyA> will do, thanks [03:03] <FergyA> looks like the updated version works, shame im only getting 1fps [03:03] <FergyA> and I guess my cross compiler toolchain must work ^^ [03:05] <ubitux> are you sure a scale filter is not inserted? [03:05] <ubitux> you should use -video_size to set the input size [03:05] <ubitux> not -s [03:05] <ubitux> -s might be inserting a filter (check with -v verbose) [03:05] <FergyA> _fractually hold up [03:06] <FergyA> i just threw the input format back in [03:06] <FergyA> and im getting 15 fps now [03:06] <ubitux> do you need to set the rate too? [03:06] <ubitux> ffmpeg -f v4l2 -i /dev/video0 should work fine out of the box [03:07] <ubitux> then you can play with the input v4l2 config options listed in ffmpeg -help full [03:07] <FergyA> yeah, doing a straight output does work, it just totally kills the cpu :P [03:08] <FergyA> since its doing encoding [03:08] <ubitux> what's your cmd line? [03:08] <ubitux> you can still use -c:v copy [03:08] <FergyA> just ffmpeg -f v4l2 -i /dev/video0 [03:08] <FergyA> test.avi [03:08] <ubitux> what about ffmpeg -f v4l2 -i /dev/video0 -c:v copy test.avi? [03:09] <FergyA> hmm, can i change formats in v4l2? [03:09] <ubitux> with -input_format as input option i guess [03:10] <ubitux> mmh lavd options are not listed in the help, that sucks a bit [03:10] <FergyA> yeah, soon as i throw the copy option in it goes nuts [03:10] <FergyA> I start getting messages like [avi @ 0x15606e0] st:0 PTS: 1318 DTS: 1318 < 1373 invalid, clipping [03:10] <ubitux> what about using test.mjpeg as output instead of avi? [03:10] <FergyA> let me give it a try [03:11] <FergyA> seems okay so far [03:11] <ubitux> ok, with avi, does it help with -fflags +genpts? [03:12] <ubitux> (as output option) [03:12] <ubitux> oh no [03:12] <ubitux> there is an option [03:13] <ubitux> try for example ffmpeg -f v4l2 -ts abs -i /dev/video0 -c:v copy out.avi [03:13] <ubitux> maybe [03:13] <ubitux> :p [03:13] <FergyA> with -fflags +genpts it dies after about 25s [03:13] <ubitux> you also can try -ts mono2abs [03:13] <FergyA> from skipped frams [03:13] <ubitux> or stuff like that [03:13] <ubitux> also, maybe try to play with the -framerate option (it's v4l2 option as well, so as input option) [03:14] <ubitux> (both -framerate and -ts are) [03:14] <FergyA> i think if i just avoid avi ill be good tbh [03:14] <ubitux> :) [03:15] <FergyA> the mjpeg works, its just got a really high bit rate [03:15] <FergyA> so ill just have to do some tweaking there i think [03:24] <FergyA> yeah, i dont know what it is about 30 seconds in, but it doesnt seem to matter what format i use (besides mjpeg) it has issues [03:25] <FergyA> and actually mjpeg just did it too :/ [03:25] <FergyA> so picky heh [04:47] <chouwa> is there a simple way to overlay video timestamps (i.e. running time, like ffms2's ffinfo) w/ ffmpeg? [04:55] <chouwa> ah, nvm [11:51] <RSDRSDRSD> how can i make a video faststart? [11:52] <ubitux> -movflags +faststart [12:36] <RSDRSDRSD> is this flag as good as native qt-faststart [12:36] <RSDRSDRSD> or the python script [12:46] <durandal_1707> RSDRSDRSD: what flag? [12:47] <RSDRSDRSD> -movflags +faststart [12:47] <durandal_1707> it does same as other scripts [12:47] <durandal_1707> point of flag is to not depend on 3rd stuff [13:19] <RSDRSDRSD> http://www.stoimen.com/blog/2010/11/12/how-to-make-mp4-progressive-with-qt-… [13:19] <RSDRSDRSD> if you read the last paragraph [13:20] <RSDRSDRSD> does ffmpeg also have this problem? [13:20] <RSDRSDRSD> last two paragraphs [13:20] <ubitux> with -movflags +faststart, the mov/mp4 muxer will move it itself reliably [13:21] <ubitux> qt-faststart is an old tool distributed by ffmpeg [13:21] <ubitux> because doing a 2nd pass inside the muxer was not easy [13:21] <ubitux> qt-faststart basically is a hack (notably to look for some atoms) [13:21] <ubitux> now ffmpeg has a "native" support to move the header on top [13:22] <ubitux> it should be more reliable [13:22] <ubitux> but OTOH it's more recent, and thus less tested [13:22] <ubitux> try it yourself. [13:26] <RSDRSDRSD> ok thanks for the answer [13:26] <RSDRSDRSD> ill use the native one ;-) [13:41] <rob_> hi [13:42] <rob_> im trying to stream a v4l webcam and embed the stream in a webpage served by the local computer - it's my understanding that webm is the best format to use but im having some trouble [13:42] <rob_> here is the line im using: avconv -f video4linux2 -r 10 -s 640x360 -i /dev/video1 stream.webm [13:43] <ubitux> rob_: please use a recent ffmpeg and pastebin command line and output, or ask support to the fork you are using [13:44] <rob_> avconv is ffmpeg isnt it? [13:44] <ubitux> no it's not, it's a fork [13:44] <ubitux> see ^ [13:44] Action: rob_ goes to read [13:46] <rob_> ah. [13:49] Action: rob_ installs actual ffmpeg [13:56] <rob_> i've taken the example from the docs and this is the result: http://pastebin.com/D0f3xiHv [13:59] <ubitux> ok so, various things: [14:00] <ubitux> 1) you don't need to run ffmpeg as root (operation not permitted errors generally are due to a return -1 somewhere in the code) [14:00] <ubitux> 2) ffmpeg 0.10 is very old [14:00] <ubitux> we are in ffmpeg 1.2 now [14:00] <ubitux> try these ^ [14:01] <ubitux> rob_: and the name is "video4linux2" or "v4l2" [14:01] <ubitux> unless you want to use the old v4l? [14:01] <ubitux> (iirc that's not supported anymore) [14:01] <rob_> no i dont think so [14:01] <ubitux> so use -f v4l2 [14:01] <rob_> ok, i'll the static lib from dropbox [14:07] <rob_> ok that seems to work, thanks ubitux [14:07] <rob_> i have another problem but im not sure whether it's ffmpeg related.. [14:07] <rob_> when i embed the webm in a web page, it only displays the first frame - http://rw.wtf.im/ [14:08] <rob_> is this because im using the wrong sort of file format? [14:09] <ubitux> opening directly your webm file works [14:09] <ubitux> maybe your http server has a problem [14:09] <ubitux> like mime-types or such [14:11] <rob_> the mime type is set to video/webm which is correct [14:16] <ubitux> http://rw.wtf.im/stream.webm [14:16] <ubitux> this works here [14:16] <ubitux> so maybe something is wrong in your html [14:16] <rob_> yeah think it's not autoplaying [14:16] <rob_> anyway thanks for the help! i really appreciate it :) [14:19] <rob_> oh, one more question [14:19] <rob_> so with ffmpeg im writing this file and ive got it embedded in my web page [14:19] <rob_> but i'd like it to be a live stream [14:19] <rob_> can ffmpeg do that? [14:20] <rob_> at the moment whenever i open the web page it starts the stream from the beginning [14:21] <ubitux> live streaming is a bit different; you might need to use ffserver [14:22] <rob_> ahh ok [14:22] <rob_> will look into that [14:22] <rob_> thanks [16:15] <foonix> when using twice -ss (seek and decode) then -to gets tricked by seek time, is it a bug or do i miss something? [16:16] <foonix> (on version 1.2) [16:20] <foonix> i can use -t or -vframes but this would be easier [16:33] <rob_> ubitux: ended up having to compile ffmpeg from source to get ffserver support - now everything works perfectly :) [16:33] <rob_> ubitux: pretty bad that the packages people are distributing are that broken [16:34] <ubitux> rob_: complain to you distro :p [16:35] <ubitux> foonix: that might be a bug [16:37] <rob_> ubitux: from that thread it sounds like the maintainer of libav has taken over the ffmpeg name in ubuntu? [16:37] <xentrac> rob_: correct [16:38] <rob_> that is ridiculous :) [16:38] <ubitux> complain to your distro :) [17:12] <cbsrobot_> foonix: can you show me your command line ? [17:27] <xentrac> rob_: there are project forks that were better handled [18:07] <foonix> cbsrobot_: http://pastebin.com/AXP6GeQE [20:11] <josetorn> ffmpeg is no longer able to connect to shoutcast servers starting from version 1.9.9beta, any ideas? Something is probably changed but i don't know what is that.. Because, VLC fails too. [20:18] <saste> josetorn, version 1.9.9beta -> doesn't exist [20:19] <saste> or is that the version of the server? [20:19] <josetorn> version of the server [20:20] <josetorn> i can give you example stream addresses [20:21] <josetorn> http://38.96.148.39:8746 [21:53] <cbsrobot_> foonix: well the first -ss is ignored becase -ss is an output option [22:13] <foonix> cbsrobot_: so seeking should not work with -to ? [22:13] <cbsrobot_> no [22:13] <cbsrobot_> it's rather the second -ss overwrites the first -ss [22:13] <foonix> in this combination quick+accurate .. i think doing just quick seek it will work ok [22:14] <foonix> accurate = decoded [22:14] <cbsrobot_> try it [22:14] <cbsrobot_> you'll see [22:15] <`WarpKat> is -filter:v the same as -vf and will having both on the same line conflict? [22:16] Action: cbsrobot_ always uses -vf [22:19] <foonix> cbsrobot_: if its just -ss before input it seeks to position but starts from there as it is 00:00:00 [22:19] <`WarpKat> i'm assuming i can do something like this, then: -vf 'scale=960:-1;yadif' [22:19] <`WarpKat> ??? [22:21] <foonix> cbsrobot_: my idea is to avoid decoding as much as possible, ie start from 1h5min -ss 01:04:00 -i some_input -ss 00:01:00 ... [22:21] <cbsrobot_> foonix: if i remeber the code wel it's rather -ss bofore the firs input will be used as an output option for it, but if you define -ss again I guess it will be overwritten [22:24] <cbsrobot_> foonix: the commit message states: there is a corner case: if -ss is specified in front of the input file [22:24] <cbsrobot_> then -to will behave like -t. [22:24] <foonix> oh thanks [22:25] <foonix> i didnt check that for sure [22:25] <cbsrobot_> np [22:35] <mark4o> `WarpKat: -vf & -filter:v are the same, use only one; syntax would be -vf scale=960:-1,yadif [22:35] <`WarpKat> thanks, mark4o - kinda figured it out when it complained about my ;...lol is yadif the only deinterlacing option for 1.2? [22:35] <`WarpKat> the old one seemed to work much better, imho [22:37] <mark4o> I think the old one was thought to be worse and was removed. I've never used the old one so I can't say. [22:38] <mark4o> actually you probably want to deinterlace before scaling so it would be -vf yadif,scale=... [22:39] <`WarpKat> so the order makes that much of a difference, eh? [22:39] <mark4o> yes [22:40] <mark4o> well if you were doing vertical scaling it would anyway [22:41] <mark4o> I don't know your source dimensions [22:42] <`WarpKat> the scale is variable depending on a condition, but in this case, doesn't matter - but your suggestion worked to my liking - thanks for your help [22:59] <Eric___> Kind of very interesting question Which one is better to use and why for HTTP Live streaming ffmpeg or Gstreamer? [23:01] <JEEB> I have no idea which is simpler to use for that exact use case because while ffmpeg is nice to use in general, for HTTP stuff you have to use something called ffserver, and that is one undocumented mess. GStreamer just generally sucks so welp [23:02] <Eric___> @<JEEB> thats true, thats why thought taking expert opinions before putting lot of time on it.... [23:02] <Eric___> ffmpeg is very simple to implement [23:03] <Eric___> gstreamer's Plugin-based architecture -> too many shared libraries to add [23:04] <Eric___> any other good suggestions [23:05] <JEEB> just streaming f.ex. mpeg-ts into a http port? VLC [23:06] <Eric___> use mpegts and use it for hls [23:10] <JEEB> oh [23:10] <JEEB> I think ffmpeg itself could do hls [23:10] <JEEB> although you need a web server to serve the files IIRC [23:10] <JEEB> there's -f hls methinks [23:11] <Eric___> thanks JEEB [00:00] --- Wed Mar 27 2013

1 0

ffmpeg-devel.log.20130325
by burek 26 Mar '13

26 Mar '13

[00:29] <ubitux> llogan: oh that's quite a bunch of examples you added there :) [00:29] <ubitux> llogan: don't you think it could make sense to add some predefined presets in the filter instead? [00:31] <llogan> ubitux: yeah, but i don't know how [00:31] <ubitux> i guess i could do it [00:32] <ubitux> llogan: btw, didn't you needed to specify some intensity curve? [00:32] <ubitux> it seems gimp as such thing, which is additionnal to the colors [00:32] <ubitux> has* [00:32] <ubitux> no idea about photoshop [00:33] <llogan> i only looked at the gimp briefly. i can check again, but the results were very similar to photoshop, as far as i could tell [00:33] <ubitux> cool [00:33] <ubitux> how did you get the values btw? [00:34] <llogan> manually swiped from photoshop. it uses a 0-255 range. [00:34] <ubitux> ok :) [00:34] <ubitux> ok well [00:34] <ubitux> let me add some presets inside the filter [00:34] <ubitux> that should be handy [00:35] <llogan> for example, medium contrast is 73/56 163/164 [00:35] <llogan> watch a movie in color negative is interesting [00:36] <ubitux> you can use -vf negate :P [00:36] <llogan> it's not the same (i also added "negative" which is like negate) [00:37] <llogan> also, people can find "negative" if they fail to find negate. [00:38] <ubitux> what motivated you to play with the filter btw? :) [00:38] <llogan> lol... [00:38] Action: ubitux happy to have already one user [00:38] <llogan> a bad rip of Beastmaster 3 for a "bad movie night" [00:38] <ubitux> ok :) [00:39] <llogan> also, it wasn't the GSoC ideas page that i was supposed to work on instead [00:39] <llogan> i can give you more decimals if you like for more "photoshop" precision [00:40] <ubitux> i don't think it matters [00:40] <ubitux> since it's multiplied by 255 after [00:40] <ubitux> you need enough precision to get back the original int [00:40] <llogan> numbers aren't my strong point [00:40] <ubitux> that makes me think it might need some rounding [00:41] <ubitux> but well [00:41] <llogan> yeah, i just trunc-ed the originals [00:42] <llogan> anyway, curves are great. i find them much more useful for color correction than dedicated "color correction" video editor plugins [00:44] <ubitux> :) [00:45] <ubitux> i'll send a patch in about an hour [00:47] <llogan> thanks. i'll let you know if i end up with more presets [00:48] <llogan> also, Zardoz is weird as shit. [00:57] <Compnn> one of these days i'll animate an ffmpeg logo using my tablet :) [01:01] <cone-454> ffmpeg.git 03Michael Niedermayer 07master:01df2a13c32a: avcodec/utils: initialize pixel buffer pool [01:02] <ubitux> ok got the presets working yay [01:05] <llogan> ubitux: that was quick. i have to go now, but i'll definitely take a look tomorrow. [01:05] <ubitux> ok :) [01:05] <ubitux> i need to update the doc, it's a pain [01:05] <ubitux> :D [01:31] <ubitux> strange, the audio path is not tested in the concat filter [04:10] <Compnn> ubitux : i got some dumb questions... [04:11] <Compn> ubitux : did you test your ivtc filter on files with bad timestamps? can your filter detect if a file is interlaced or not? what does it do on non-interlaced video? does it distort it? [04:21] <ubitux> the timestamps should not cause any problems (though i need to fix them in decimate) [04:22] <ubitux> it's not the purpose of fieldmatching to detect if the file is interlaced or not [04:22] <ubitux> you can use vf idet for this [04:22] <ubitux> but it of course has some interlaced metrics in it [04:22] <ubitux> it shouldn't affect non-interlaced video [04:22] <ubitux> but i wouldn't recommend to enable it by default if you have this in mind [04:22] <ubitux> (because sloooww) [04:27] <Compn> well thats what i was asking [04:27] <Compn> i guess [04:27] <Compn> if it could detect non-interlaced and be faster [04:27] <Compn> i'm sure lots of people would like that as a feature [04:28] <Compn> i know people stick yadif into mplayer configs , and are able to enable/disable it by pressing D key ... [04:28] <Compn> (i know, different feature, but you get my point) [04:29] <Compn> people also want autocrop, as long as i'm asking for a pony [04:34] <ubitux> the main purpose is for encoding [04:38] <Compn> mixed video with some interlacing and some progressive then [04:38] <Compn> how about that ? [04:38] <Compn> :P [04:38] <Compn> you know... they put that stuff in dvds sometimes [04:38] Action: Compn just giving ubitux a hard time [04:44] <ubitux> it will work, it's just not really a good idea for playback imo [04:45] <ubitux> at least no unconditionnally [04:45] <Compn> you know users, they dont have good ideas [04:45] <Compn> but by planning , at least we can help users not shoot themselves in the feet [04:47] <Compn> anyways patch welcome i'm sure :P [04:47] Action: Compn goes to troll other people now [09:51] <pierre-olivierro> Hi all, I'm looking from some informations on how to use the av_packet_new_side_data related API functions to add customized data into video packets. [09:52] <pierre-olivierro> Got some issues for now with latest FFmpeg versions [10:56] <xlinkz0> if anyone can help i'd greatly appreciate it : http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=1088 [11:54] <michaelni> xlinkz0, does this happen only with ffplay or also ffmpeg & ffprobe ? [11:55] <xlinkz0> all of them, but i think i figured out the problem, guys at mingw-w64 say it's because SDL is built with -mwindows [12:04] <michaelni> pierre-olivierro, see the headers and source code, i dont think theres docs elsewhere but what are you trying to do and what issues ? [12:05] <nevcairiel> oh yeah it could happen if its build as a gui application, which have their stdout turned off [12:17] <saste> http://bugzilla.libsdl.org/show_bug.cgi?id=1725 [12:21] <highgod> Hi, saste, I submit the opencl patch [12:21] <saste> highgod, thanks [12:21] <saste> do you have a link? [12:22] <highgod> sorry for the mistake I made of the previous patches, it a waste of your time. [12:22] <highgod> sorry, what is "a link"? [12:23] <saste> http://bugzilla.libsdl.org/show_bug.cgi?id=1237 [12:23] <saste> but they closed it with no explanation^ [12:24] <nevcairiel> wonder if you can override with -mno-windows [12:24] <saste> highgod, no problem [12:25] <saste> i'll try to review the patch tonight [12:26] <highgod> Thank you very much, if there is anything I can do for the community, I will pleased to help. [12:26] <saste> highgod, but i agree with michael, there is are security concerns with regards to the access-binary() function [12:27] <saste> a library should not write files if not explicitely requested, and the read binary files could have been forged by a malignant user [12:28] <saste> so we may need to devise some mechanism to specify the paths [12:29] <highgod> ok, but I don't know how to do that,it may different between operation systems [12:30] <highgod> if the kernels added more and more, it will take a long time to compiles kernels every time [12:33] <saste> we could create a context for the opencl environment, where we can specify options [12:34] <highgod> that's good and also for the build-log, which for the error informations of build kernel [12:35] <highgod> is there any code I can reference? [12:36] <saste> highgod, check at the end of libavutil/opt.c [12:37] <saste> contains an example of how it is possible to set options on a context [12:37] <saste> you could create the context when initing opencl, but this needs some thinking [12:38] <highgod> should I have to specific the patch that save the binary file? [12:39] <highgod> and if run next time, I have to specific the patch of the file and ffmpeg read it? [12:41] <saste> when you init opencl ffmpeg creates a specific context, which can be accessed some way [12:41] <saste> then you could set the path to be read when looking for opencl binary files [12:41] <saste> and the build log file [12:44] <highgod> Yes, I agree with you, and I just read the mail Michael replied about this problem [12:55] <highgod> Can we think about just runing opencl without using the binary file? Because the important thing is run OpenCL code at this stage. and the other optimize code can be added later. [12:57] <saste> highgod, sure, that can be done in a second step [13:02] <highgod> and the kernels is just deshake in this step, it doesn't take a long time to compile [13:03] <highgod> OK, I have little experence on linux things, so about the path setting, maybe I will ask a lot of questions,hehe [13:04] <saste> highgod, it's not linux specific, the same security concerns apply to windows as well [13:05] <saste> about the specific path for the compiled opencl binaries, yes that may be OS dependent [13:06] <highgod> @saste, thanks, we didn't think about it before, our other project just implement like this,hehe. [13:29] <pierre-olivierro> michaelni: I just want to add some uint8_t values, for customize a little the video stream. I think i'm using functions correctly, but when writing packets, side data seems not to be taken into account [13:54] <michaelni> pierre-olivierro, customize ? are you sure side data is what you want to use ? [13:55] Action: michaelni wonders where cone is again [14:13] <pierre-olivierro> michaelni: yes, i want to add specific data to each video frame, how can I do it without using side data ? [14:14] <pierre-olivierro> michaelni: and a few version ago, it was working like this. [15:02] <michaelni> pierre-olivierro, it probably stoped working due to ubitux changes to side data split/merge for muxers but iam not sure if how you use side data is a good idea [15:06] <pierre-olivierro> michaelni: ok. So if y want to add some other data in a stream, per video frame, how can i do this ? (without using another stream in the container) [15:07] <durandal_1707> michaelni: your compiler does not dump warnings? [15:09] <michaelni> durandal_1707, which warning ? [15:10] <durandal_1707> yop one [15:10] <durandal_1707> void function which should not be void [15:12] <michaelni> oops, ill fix in a moment [15:16] Action: michaelni looks and still sees no cone [15:17] <michaelni> pierre-olivierro, metadata but this likely will only work with some containers [15:19] <michaelni> pierre-olivierro, a hack to get side data working is to call av_packet_merge_side_data() probably [15:20] <durandal_1707> icoenc have some funny code [15:21] <durandal_1707> libavformat/icoenc.c:48:62: warning: self-comparison always evaluates to false [-Wtautological-compare] [15:22] <wm4> durandal_1707: why did you accept the jpeg colorspace hack? isn't that deprecated? [15:22] <durandal_1707> wm4: i'm evil [15:22] <wm4> hurr [15:23] <durandal_1707> seriously, alternative does not work and nobody cares [15:23] <wm4> what alternative are you thinking of [15:23] <durandal_1707> the one which caused pix fmt to get deprecated at first place [15:24] <durandal_1707> iirc setting color_range (lol) [15:24] <wm4> it's as easy as passing through color levels [15:25] <durandal_1707> it is more like color space, thats why is there yuv444 and rgb and not just some 888 format [15:25] <nevcairiel> the problem is swscale, it only really works properly with the J pixfmts, trying to set it through other means fails [15:26] <wm4> nevcairiel: I think that got fixed [15:26] <nevcairiel> at least thats my experience [15:26] <nevcairiel> maybe, i didnt re-try for a year or so =P [15:26] Action: nevcairiel has his own yuv->rgb now [15:26] <durandal_1707> wm4: really? swscale does care what is color_range at all [15:26] <wm4> half a year ago, it worked, but using it with RGB yielded random results (this was fixed too) [15:27] <wm4> so vf_colormatrix seems to be redundant too to vf_scale [15:27] <wm4> (if vf_scale would handle colorspaces/ranges correctly) [15:28] <durandal_1707> it is trivial to make colormatrix just call swscale (if swscale really can do that) [15:29] <wm4> I think it can (though I'm not 100% sure) [15:31] <durandal_1707> when i asked michaelni (swscale author) about it, he said it is incomplete [15:31] <wm4> well, I think I did verify it to some degree [15:32] <wm4> though I did only try hard with ranges (there's even a test program on some ticket), while I just visually confirmed color_space_ [15:33] <michaelni> rgb->yuv doesnt support all yuv variants but thats independant of how the yuv variant is specifid (color_* or pixfmt) [15:35] <michaelni> also the first thing sws does with yuvj is to change the pixel format to the yuv variant and set the color_* stuff apropriately [15:37] <durandal_1707> because there is no way to change color_* stuff via lavfi, there is no way to force same color_* stuff in blend filter [15:57] <Granjow> Hi there! I use this code for seeking: http://codepad.org/AMyojmxV Problem is, works fine for the first 14 frames, but then I get this frame twice (so the frames returned consecutively are 13 14 14 15 16 etc.). [15:57] <Granjow> How can this happen? [16:01] <Granjow> Should seeking not be accurate? [16:12] <wm4> Granjow: no, seeking usually snaps to key frames [16:13] <wm4> Granjow: this is due to how video codecs work (you have to decode a number of frames to get a complete decoded picture of a non-keyframe) [16:14] <wm4> Granjow: unless your video codec is intra-only of course (then every frame is a keyframe, and frame-exact seeking should be trivial) [16:17] <Granjow> wm4: Not sure what it is: Stream #0:0: Video: mjpeg (MJPG / 0x47504A4D), yuvj420p, 1280x1040, 10 tbr, 10 tbn, 10 tbc [16:17] <wm4> Granjow: sounds like it is intra-only, what's your container? [16:18] <Granjow> wm4: .avi? Or is the container format something else? [16:20] <av500> the duplicated frame could be a simple rescale issue [16:21] <Granjow> When I simply seek frames from 0 to 49 then I get more duplicates the further I seek: http://codepad.org/FVF25FUh And although the PTS/DTS jumps by 2, the actual frame does not [16:21] <Granjow> av500: Rescale issue? [16:21] <av500> int64_t seekTarget = av_rescale_q(frame, AV_TIME_BASE_Q, rv->pCodecContext->time_base); [16:21] <av500> does this produce the exact same timestamps as when playing the file? [16:22] <av500> ok, seems so with an 1/10 timebase [16:22] <Granjow> av500: I'm not actually using seekTarget, sorry for the code still being there. I just work with the frame number directly since seekTarget is always 0. [16:22] <av500> ah right [16:23] <av500> what container? [16:23] <Granjow> how can I find out? File extension is .avi [16:23] <wm4> then it's probably avi [16:24] <wm4> maybe av_seek_frame is limited by the precision of the avi index? I can only guess here [16:24] <av500> the AVI index has every frame [16:24] <av500> or should [16:25] <av500> but I dont see AVSEEK_FLAG_FRAME support in AVI [16:25] <Granjow> Not sure, but I just happened to try and find the aviindex utility [16:25] <av500> oops [16:25] <wm4> Granjow: if you need frame exact access, you could use ffms [16:25] <wm4> Granjow: http://code.google.com/p/ffmpegsource/ [16:26] <Granjow> http://codepad.org/R6lAV7IF are the first lines [16:27] <av500> Granjow: try to seek to a timestamp [16:27] <av500> the one from the av_rescale [16:27] <Granjow> wm4: sounds convenient. But afair there is a fix in ffmpeg which is not yet included in their version. [16:27] <av500> and drop the frame flag [16:28] <wm4> Granjow: "their version"? ffms uses ffmpeg proper as library [16:28] <wm4> Granjow: it just does all the indexing stuff for you [16:28] <wm4> Granjow: so depending on what you want to do, this might be a great time saver [16:28] <Granjow> av500: How do I use av_rescale correctly? Since my seekTarget is constantly at 0 [16:28] <av500> Granjow: I dont know, see the source code [16:30] <Granjow> wm4: Ah. Well, currently I have already written a wrapper for everything I need, except correct seeking, that is. Is it in development? I.e. is ffmpegsource alive? [16:31] <TheFluff_> it needs updating for some new ffmpeg stuff but nobody has gotten around to it yet since all of the developers got busy with their fulltime jobs [16:31] <wm4> Granjow: it's been used a long time and seems very much stable (I haven't used it myself, but it's used for avisynth and aegisub) [16:31] <av500> AVI is pretty much frame number based already [16:31] <av500> I dont think a wrapper can help much [16:31] <TheFluff_> plork said he was going to look at it one of these eekends [16:32] <TheFluff_> or well he actually did look at it already, it's just kinda buggy and not ready to be merged yet [16:32] <wm4> av500: AFAIk the advantage is that ffms already contains all workarounds needed, and it'll work for any (or most) formats [16:32] <JEEB> TheFluff_, I think his git master got merged into trunk [16:33] <JEEB> so now ffmpegsource's trunk can be built with current ffmpeg, methinks [16:33] <TheFluff_> oh [16:33] <TheFluff_> yes [16:33] <TheFluff_> he merged it yesterday [16:34] <av500> wm4: I understand that [16:35] <TheFluff> Granjow: ffmpeg and correct seeking do not get along well, that's why things like ffms and l-smash exist [16:36] <TheFluff> I'd say that if you care about more than one format it's gonna be pretty annoying to roll your own seeking solution [16:36] <Paranoialmaniac> ? [16:36] <Granjow> TheFluff: [16:36] <TheFluff> Paranoialmaniac: sorry if I mis-alerted you [16:37] <Paranoialmaniac> l-smash and l-smash works is different thing :P [16:37] <TheFluff> right [16:38] <Paranoialmaniac> well, l-smash works can handle intra-refresh and pre-roll using l-smash [16:38] <Granjow> TheFluff: Yeah, actually more than 0 formats apparently. As far as I see I would have to try to guess the correct AVPacket.pos and then advance until I'm at the right position, or something like this o.O [16:40] <Granjow> I guess I'll do a quick test of ffmpeg source and switch to it if it works. [16:40] <av500> Granjow: your AVI file is video only with all frames as key frames [16:41] <av500> so seeking to a timestamps as frame# * timebase should work [16:41] <av500> otherwise its a bug [16:43] <Granjow> av500: Does not work, I removed the flag and get the same results. [16:45] <av500> print the timestamps and frame numbers pls [16:45] <wm4> I think I can say libavformat in general proved to be pretty unreliable for me [16:45] <av500> also the resulting pts/dts [16:45] <wm4> even mplayer's really crappy demuxers sometimes work better [16:45] <av500> yeah, but seeking in AVI is pretty straightforward [16:45] <av500> if that is broken it should be fixed [16:46] <av500> instead of relying on ffms to fix it [16:46] <wm4> also I have to say mhpeg in avi sounds pretty obscure [16:46] <wm4> *mjpeg [16:46] <Granjow> av500: Which fields are those? [16:47] <Granjow> AVPacket.? [16:47] <av500> pts [16:47] <av500> dts [16:47] <av500> wm4: that is not obscure at all [16:47] <av500> digital cameras did that for a long time for "video recordings" [16:48] <av500> some at least [16:48] <av500> Canon_Ixus_750.avi [16:49] <av500> Casio_Exilim.avi [16:49] <av500> CanonSD800is.AVI [16:51] <Granjow> av500: http://codepad.org/tgtxfPfE [16:53] <durandal_1707> wm4: what is unreliable in lavf? [16:53] <Granjow> Somehow it starts failing after the last frame I already read in in the first loop [16:53] <Granjow> If I only read the first 5 frames and then start seeking, then it fails there already, now with 30 it fails at 31 [16:54] <durandal_1707> Granjow: what codec ? [16:54] <Granjow> Here is the same but only reading 5 frames first http://codepad.org/zj5KWg20 [16:55] <Granjow> durandal_1707: Where? Used in my code or described by ffmpeg? [16:55] <durandal_1707> the one you use with code [16:56] <Granjow> durandal_1707: Not sure, I open it automatically: http://codepad.org/5ngEtkqb [16:56] <durandal_1707> hmm, i don't see why seeking could not work, it is keyframe only stream [16:57] <Granjow> ah, I'm actually printing it [16:57] <Granjow> MJPEG (Motion JPEG) [17:01] <wm4> durandal_1707: with some broken wmv files, I can't even seek backwards [17:01] <wm4> durandal_1707: and incomplete uninterleaved avi files are unseekable [17:01] <wm4> durandal_1707: even though all of these work with mplayer demuxers [17:02] <wm4> durandal_1707: so yeah, there are plently of obscure cases left where mplayer internal demuxers work better than lavf [17:02] <durandal_1707> open ticket [17:03] <wm4> I did [17:03] <Granjow> I have uploaded the avi file here: http://granjow.net/uploads/temp/seeking.avi (400 MB) for testing. [17:04] <wm4> durandal_1707: https://ffmpeg.org/trac/ffmpeg/ticket/1993 [17:04] <Granjow> Just in case it might help. [17:04] <wm4> durandal_1707: "FFmpeg does not support non-interleaved avi files without index" [17:05] <Granjow> Need to run for the train now -- thanks a lot for helping. Will check if ffmpegsource works and switch in case it does. [20:26] <NovaSt0rM> is there a fastish reliable way to determine the number of bytes that would be decoded in an audio stream? [20:26] <NovaSt0rM> using av_read_frame but skipping the actual decode part? [20:29] Action: NovaSt0rM reads the topic [22:28] <FFmpeg-github> 01[13FFmpeg01] 15none pushed 3 new commits to 06master: 02http://git.io/Qywsuw [22:28] <FFmpeg-github> 13FFmpeg/06master 148097e5b 15Michael Niedermayer: yop: Fix return type... [22:28] <FFmpeg-github> 13FFmpeg/06master 1467607e2 15Michael Niedermayer: xxan: make code independent of sizeof(AVFrame)... [22:28] <FFmpeg-github> 13FFmpeg/06master 14a2f7314 15Michael Niedermayer: libpostproc: silence valgrind/fate warning about using uninitialized data... [22:29] <gnafu> Well, that's new. [22:30] <FFmpeg-github> 01[13FFmpeg01] 15michaelni pushed 1 new commit to 06master: 02http://git.io/i1LLDw [22:30] <FFmpeg-github> 13FFmpeg/06master 14ea4c99d 15Michael Niedermayer: dshow_pin: dont return a value from a void function... [22:31] <michaelni> i enabled the github bot again until cone re-appears [22:31] <gnafu> :-) [22:34] <durandal_1707> but this one gives delayed spam [22:37] <michaelni> yes ... you can ask j-b or thresh about cone, i dunno why its not here ... [22:37] <durandal_1707> it wasted too much bandwitch? [23:26] <saste> llogan? [23:41] <FFmpeg-github> 01[13FFmpeg01] 15michaelni pushed 1 new commit to 06master: 02http://git.io/XH1qOg [23:41] <FFmpeg-github> 13FFmpeg/06master 144a595cf 15Michael Niedermayer: ffserver/ctime1: avoid using strcpy()... [23:42] <j-b> michaelni: thresh will fix tomorrow, he said [23:42] <michaelni> j-b, ok thx [23:48] <saste> is mashiat sarker on IRC? [23:49] <saste> what's usually his nickname? [23:50] <ubitux> shahriman? [23:51] <saste> ok [00:00] --- Tue Mar 26 2013

1 0

ffmpeg.log.20130325
by burek 26 Mar '13

26 Mar '13

[00:18] <ItsMeLenny> hellooo [00:18] <ItsMeLenny> is there a way to change the fps in a container, in terms of the playback fps [00:19] <ItsMeLenny> with and/or without recontaining it [02:57] <ItsMeLenny> is there a way to change a containers frame rate, say i have a file thats 25fps and i want it to play back at 50fps, so its double speed [03:02] <retard> ItsMeLenny: yes [03:04] <ItsMeLenny> retard, how would i go about doing that [03:39] <retard> ItsMeLenny: probably by doing some extremely simple websearches [03:39] <retard> then using what you've learned [03:46] <ItsMeLenny> retard, nope [03:46] <ItsMeLenny> and thanks for the non help [03:46] <ItsMeLenny> why would i ask if ive found the answer in my many websearches [04:10] <HACKhalo2> ok, I got this script http://pastebin.com/XrpqEYkf that /should/ stream to justin.tv, and it does. The issue is that it only streams audio [04:14] <HACKhalo2> and I have no clue why [04:14] <HACKhalo2> it's using the right X display, the dimentions are right for the screen size [04:16] <HACKhalo2> ok, now video works [04:17] <HACKhalo2> apparently -crf 0 blanks the video [04:17] <HACKhalo2> never mind then [04:21] <strikeout> hi! can anybody please give me a headsup on how to install ffmpeg with TWO versions of x264, one for 8bit, one for 10bit? :) [04:21] <strikeout> *on ubuntu 12.04 [09:12] <xlinkz0> i'm trying to compile ffmpeg with freetype and fontconfig on windows with mingw-w64 [09:12] <xlinkz0> and i get this : http://codepad.org/bdbHVVox [09:13] <xlinkz0> people in the mingw channel say i don't specify the xml lib.. but there's no xml flag for configure [09:14] <xlinkz0> ubitux, morning :D [09:19] <ubitux> i didn't touch a windows system since about 10 years [09:19] <ubitux> so i have no idea what your problem is [09:22] <xlinkz0> well it's mingw.. which is pretty similar to unix style.. [10:34] <RSDRSDRSD> What is the best method to scale anamorphic videos to 1:1 [10:39] <xlinkz0> ok this is weird, i configure and make and everything finishes ok but the ff tools don't output anything on the terminal stdout [10:40] <xlinkz0> it's not from the terminal, i've pasted in an 'officially' built ffmpeg variant in the same directory and calling it from the same terminal [10:40] <xlinkz0> and it outputs text, the one i built doesn't [10:41] <xlinkz0> this is my config.h http://codepad.org/uimbPKKp [10:46] <RSDRSDRSD> is there a way to letterbox automatically? [10:53] <DX099> hello, can someone help me create a script that would convert all files in different subfolders while keeping them in their folder ? [10:59] <92AAAAGZY> is there a way to convert RTSP VP8/Vorbis to HTTP VP8/Vorbis in Webm container? [11:05] <RSDRSDRSD> http://pastebin.com/9HnjsvCA is that a good method to get rid of anamorphic video? [11:05] <RSDRSDRSD> For one video it works, but don know what happens if a video is converted with odd sizes? [11:25] <92AAAAGZY> is there a way to convert RTSP VP8/Vorbis to HTTP VP8/Vorbis in Webm container? [11:34] <RSDRSDRSD> someone? [12:41] <tschoepler> hi everyone [12:42] <tschoepler> I was wondering if HAP-codec is being implemented in ffmpeg [12:42] <tschoepler> http://vdmx.vidvox.net/blog/hap [12:43] <tschoepler> or where can I make a suggestion? [12:44] <saste> tschoepler, !bugs [12:44] <saste> iirc there is already a ticket for that feature [12:44] <saste> !tickets [12:44] <tschoepler> ah, thanks. [12:45] <saste> https://ffmpeg.org/trac/ffmpeg [12:45] <92AAAAGZY> is there a way to convert RTSP VP8/Vorbis to HTTP VP8/Vorbis in Webm container? [13:01] <RSDRSDRSD> where to find al variables like iw, ow etc ? [13:01] <RSDRSDRSD> cant find them [13:02] <ubitux> sounds like filter specific variables [13:03] <ubitux> http://ffmpeg.org/ffmpeg-filters.html#scale [13:03] <ubitux> ? [13:13] <RSDRSDRSD> if a movie has for example a duration of 300 seconds, how can I make 6 screenshots such that it makes a screen shot every 50 seconds because 300/6=50 [13:13] <RSDRSDRSD> yes was looking for that one, but those variables aren available in the whole commandline do they? [13:16] <saste> RSDRSDRSD, select=gte(t, selected_n*50) [13:16] <saste> or something like that [13:18] <RSDRSDRSD> but the 50 must be variable such that it is duration / n where n is number of screenshots [13:19] <saste> RSDRSDRSD, then you need some (trivial) scripting [13:20] <RSDRSDRSD> ok, thanks for that, first i have to get the duration with ffprobe [13:41] <elkng> to extract subtitles from mkv do one need to built ffmpeg with "--enable-libass" option or there is some other build option ? [13:43] <JEEB> libass is only needed to render subtitles [13:43] <JEEB> not extract them [13:44] <elkng> what is "--enable-gnutls" for ? [13:44] <elkng> for ffserver ? [14:15] <bk76> hi [14:16] <bk76> when trying to screen capture under win7 i got this error "Could not enumerate video devices" [14:16] <bk76> "video=UScreenCapture: Input/output error" [14:18] <elkng> why not to use FRAPS ? [14:18] <elkng> if on win7 [14:18] <bk76> http://pastebin.com/Wcnddud3 [14:18] <bk76> I don't know this program [14:22] <sacarasc> Fraps is a programme to record ones desktop on Windows. You have to pay for it. [14:22] <bk76> I would like to use ffmpeg [14:23] <bk76> I'm useing on Linux [14:24] <bk76> I just installed FRAPS and now I remember that it is that shitty program that dosen't worked for me well [14:24] <bk76> and it only records 30sec of video [14:25] <sacarasc> Unless you pay for it! [14:25] <bk76> I don't intend to pay for it [14:26] <bk76> so why ffmpeg is not working? [14:26] <bk76> there should not be here such advice to use another program insteed [14:33] <bk76> I'm back [14:33] <bk76> some uninstaller closed my webchat [14:33] <bk76> so can anyone help me? [15:21] <RSDRSDRSD> can someone confirm the following [15:21] <RSDRSDRSD> if I have scale=iw*sar*min(456/(iw*sar)\,342/ih):ih*min(456/(iw*sar)\,342/ih) for scaling [15:22] <RSDRSDRSD> do I get in trouble if the iw and ih have odd sizes [15:22] <RSDRSDRSD> does ffmpeg round it correctly? [15:28] <elkng> there are same video in two formats 1) "1920x1080 bitrate: 5228 kb/s" and 2) "1280x720 bitrate: 2705 kb/s" , if I want to get video "650x365 bitrate: 2000 kb/s" is it matter which one I use ? or they both will look the same in 650x365 [15:28] <elkng> anyway so I can use second one to convert it faster ? [15:30] <Yulth> Hi everyone! [15:30] <durandal_1707> RSDRSDRSD: afaik it is using eval, and that one is using floats, and i don't remember how that one rounds, but there are function in eval for rounding [15:32] <Yulth> currently for me, option '-map_metadata 0:s:0' only copies the metadata from 'mp3' input files. When input are 'ogg' files, for example, the metadata is ignored [15:33] <Yulth> any ideas about how to copy the full metadata from input files (regardless on which format they're encoded) to the new encoded files? (currently HE-AAC into MP4 container) [15:33] <RSDRSDRSD> in some examples i see trunc [15:34] <RSDRSDRSD> they divide by 2 and then multuply by 2 [15:40] <Yulth> any suggestions? [15:42] <elkng> http://imagebin.org/index.php?mode=image&id=251557 do they look the same ? [15:43] <durandal_1707> elkng: no [15:48] <elkng> I mean one of them was 1920x1080 5228 kb/s initially and another one was 1280x720 2705 kb/s now they are both 650x365 2000 kb/s, are they looks same ? which one is better ? [15:48] <sacarasc> The top one looked better, less washed out. [15:49] <sacarasc> But, we're comparing a JPG, which is another lossy encode. [16:14] <Yulth> Any way to copy all metadata from input file to output file regardless the container of the input file? :S I've tried all combinations, but what works in one container doesn't work in other container... [17:11] <Yulth> In this pastebin: http://pastebin.com/zr1fuG8A 2 commands are shown to convert both mp3 and ogg to aac. The metadata is correctly stored when the input file is OGG, but nothing is stored when is MP3. Could anybody help me please with this issue? [17:12] <durandal_1707> mp3 uses id3 and that use special keys [17:13] <Yulth> and How I can fix it? [17:16] <durandal_1707> Yulth: actually, mp3->mp4 should work [17:16] <durandal_1707> does it happen with any mp3? [17:17] <Yulth> yes [17:18] <durandal_1707> could you upload mp3 somewhere? [17:19] <Yulth> some mp3 sample files? [17:20] <durandal_1707> the ones that do not work [17:22] <Yulth> ok, let me 1 minute [17:24] <Yulth> durandal_1707: for example, this one doesn't work [17:24] <Yulth> durandal_1707: https://mega.co.nz/#!S0hkHKjS!MG7yB3OQVc5GfDqkAULm0BGDaD4d30CdPHHUMXc_hoc [17:28] <durandal_1707> Yulth: could you uploaded somewhere where flash is not required to download file? [17:29] <durandal_1707> also you could try same command with latest version [17:29] <durandal_1707> and if bug still happens report bug on tracker [17:29] <Yulth> I've installed 'ffmpeg version 1.0.1' [17:30] <durandal_1707> that is not latest version [17:30] <Yulth> ams, I understand. This is the latest version on FreeBSD [17:39] <Yulth> ok I'm going to try it with the latest version. I'll inform of any error if it still persist [20:29] <NovaSt0rM> is there a fastish reliable way to determine the number of bytes that would be decoded in an audio stream? using av_read_frame but skipping the actual decode part? [22:56] <gp> Can ffprobe detect if source is interlaced now that there is the idet filter? [23:14] <durandal_1707> gp: no, ffprobe does not run idet filter [23:15] <gp> durandal_1707: dang. thanks [00:00] --- Tue Mar 26 2013

1 0