Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

July 2015

1 participants
62 discussions

ffmpeg-devel.log.20150630
by burek 01 Jul '15

01 Jul '15

[00:02:55 CEST] <durandal_170> wm4: you could write poetry [00:04:47 CEST] <wm4> wat [00:04:57 CEST] <Compn> durandal_170 : cropdetect is from mplayer iirc, thats why gpl ? [00:05:19 CEST] <Compn> dont quote me on that :P [00:09:19 CEST] <Compn> wm4 : asf_o should not become default until its tested against the wmv/asf/wma/dvr-ms samples in samples.ffmpeg.org . [00:09:44 CEST] <Compn> not even sure why i have to say this, should be common sense. [00:11:37 CEST] <nevcairiel> fixing the old demuxer now after it being broken for years is however also something that time should be spent on, it'll continue to have terrible code quality issues =p [00:12:02 CEST] <Compn> huh? [00:12:40 CEST] <Compn> ok then [00:13:12 CEST] <Compn> wonders if nevcairiel saw the list of bugs compn found on -devel [00:13:16 CEST] <durandal_170> New one will be fixed eventually [00:13:40 CEST] <nevcairiel> Compn: fix those instead of working on the old one now [00:13:51 CEST] <nevcairiel> if someone wanted to improve the asf demuxer, they could've started years ago [00:13:55 CEST] <nevcairiel> now its just for show [00:14:08 CEST] <philipl> Nevertheless, the new one is too buggy to switch over to as-is. [00:14:45 CEST] <j-b> Compn: are you compiling all the samples? [00:14:58 CEST] <Compn> j-b : i linked to the samples on -devel, yes [00:15:15 CEST] <Compn> (also i didnt find any bugs i nthe old asf demuxer while testing, or i would report them too) [00:16:18 CEST] <nevcairiel> I never said the new one should be default right now, its just that carl objected without even testing a single file, and then goes to fix the old demuxer to support his non-argument even more, which is just stupid [00:16:49 CEST] <Compn> i wasnt claiming you made that claim nevcairiel. thats why i was talking to wm4 when i said it [00:17:34 CEST] <wm4> what did I say? [00:17:58 CEST] <philipl> I don't disagree. Carl appears to have poisoned the waters somewhat. Compn went and found real failures that need to be addressed. [00:18:18 CEST] <philipl> Whether Carl is being productive or not is orthogonal, even if it's not desirable. [00:18:34 CEST] <Compn> wm4 : "The new demuxer was written based on the official ASF spec, and was [00:18:34 CEST] <Compn> tested against a number of real world samples. [00:18:51 CEST] <Compn> from your mail [00:19:39 CEST] <wm4> well that's probably not wrong [00:19:47 CEST] <Compn> wm4 : then "Which ones? Surely you know, as it has been severe enough that you got MiNi to block the new demuxer and not only keep the old demuxer, but to leave it as default." [00:20:42 CEST] <Compn> which is why i was disagreeing with whatever comment you made about defaults. [00:20:53 CEST] <Compn> not important, hope i dont offend anyone :P [00:21:08 CEST] <j-b> you offend me [00:21:18 CEST] <Compn> j-b : i'm going to commit those qsv patches :P [00:21:26 CEST] <philipl> haha. [00:21:36 CEST] <j-b> Compn: haha [00:21:47 CEST] <wm4> anyway, no matter how you look at it, having two demuxers in the code tree just because one was "merged" but found insufficient is a pretty absurd situation on its own [00:21:49 CEST] <philipl> I think we can all agree *those* are offensive. [00:21:58 CEST] <nevcairiel> companies, no clue about anything [00:22:25 CEST] <Compn> hmm [00:22:33 CEST] <Compn> didnt we have this exact same discussion before? [00:22:41 CEST] <Compn> i think about prores (and before that something else) [00:22:44 CEST] <wm4> we have them all the time [00:22:49 CEST] <philipl> intel have competent engineers who know how to work with open-source projects. Where's __gb__ when you need him? [00:22:49 CEST] <wm4> and it keeps happening [00:23:08 CEST] <wm4> haha, Intel [00:23:09 CEST] <j-b> libyami [00:23:10 CEST] <j-b> lol [00:23:13 CEST] <wm4> Intel never seem to finish anything [00:23:25 CEST] <wm4> just half-baken APIs and implementations where you look [00:23:31 CEST] <wm4> (probably some kind of management problem) [00:23:33 CEST] <kierank> their marketing is good though [00:23:34 CEST] <philipl> Not in our part of the world to be sure. [00:23:44 CEST] <kierank> half the world says "WHY DONT YOU SUPPORT HARDWARE ENCODING" [00:23:44 CEST] <philipl> But their kernel and Xorg work is fine. [00:24:03 CEST] <wm4> their GPU drivers keep causing issues [00:24:06 CEST] <Compn> wonder how many chinese ffmpeg forks with big hwaccel patches there are... [00:24:17 CEST] <wm4> it requires performing black magic not to get tearing with Intel GPUs [00:24:40 CEST] <nevcairiel> I dunno, qsv decoding just seems like wasted effort, whats wrong with dxva2 for windows and vaapi for linux [00:24:42 CEST] <philipl> wm4: That's a wider mesa issue I think. [00:25:07 CEST] <Compn> isnt qsv in the cpu ? [00:25:11 CEST] <wm4> philipl: I doubt it... Intel don't even use many parts of Mesa due to NIH [00:25:16 CEST] <Compn> or am i thinking of a diff api... [00:25:18 CEST] <nevcairiel> Compn: strictly in the gpu .. which is in the cpu [00:25:24 CEST] <Compn> oh yes [00:25:25 CEST] <Compn> that one [00:25:34 CEST] <nevcairiel> they just only built integrated-GPUs [00:25:46 CEST] <Compn> anyone use intel widi ? :P [00:25:47 CEST] <jamrial> i remember trying to use lavfilter's qsv decoding with a fresh haswell win8.1 notebook some time ago and got choppy video out of a 1080p h264 video [00:25:48 CEST] <nevcairiel> but if you buy a CPU without a built-in GPU, you dont get qsv [00:26:09 CEST] <philipl> wm4: This is true, but solving tearing requires co-ordination all the way up to the presentation layer. [00:26:12 CEST] <Compn> so its the intel atom thing all over again ? [00:26:58 CEST] <wm4> philipl: I suppose... but nvidia gets it right [00:27:05 CEST] <wm4> or at least "more right" [00:27:13 CEST] <philipl> wm4: Yes, the do. But they replaced everything :-) [00:27:28 CEST] <philipl> (and not without good reasons) [00:28:11 CEST] <Compn> wm4 : i think my nvidia card is dying - http://i.imgur.com/iaPdHXE.jpg [00:28:40 CEST] <nevcairiel> your OS is also dead for a decade already [00:28:52 CEST] <philipl> Anyway - two asf demuxers. The old one has known problems and is likely unsalvagable. The new one has different known problems, and can't credibly be switched in as the new default. [00:28:53 CEST] <kierank> windows xp [00:28:53 CEST] <kierank> nice [00:28:55 CEST] <wm4> lol direct2d... [00:29:03 CEST] <Compn> thats vista, i'll have you know. [00:29:12 CEST] <Compn> with classic theme [00:29:17 CEST] <Compn> because screw colors. [00:29:29 CEST] <philipl> So if you accept that the new one is more likely to be made workable than the old one, you need to have both around until the new one does reach that level. [00:29:35 CEST] <wm4> why don't you use win7 like normal people [00:29:51 CEST] <wm4> (and wow win8 is terrible I can't believe it) [00:29:53 CEST] <Compn> win7 is outdated too [00:30:11 CEST] <Compn> now you're all in the same boat as me! no one can upgrade! bwahaha [00:30:27 CEST] <wm4> I use windows for testing stuff only [00:30:43 CEST] <nevcairiel> 8.1 is fine, you can easily just ignore the new UI [00:31:12 CEST] <Compn> philipl : someone will be testing the new demuxer on a large group of samples soon. [00:31:31 CEST] <nevcairiel> and once 10 is stable, it should resolve the last concerns about UI problems that 8 had [00:31:53 CEST] <philipl> Compn: Right. I'm really just responding to people being unhappy that we've got two in the codebase. It seems that's unavoidable unless you want to believe the old one can be made good. [00:32:10 CEST] <jamrial> Win10 being a free upgrade makes me wonder if their intention is to push the Win Store, reduce fragmentation, or both [00:32:18 CEST] <Compn> philipl : you cant make everyone happy. [00:32:25 CEST] <philipl> Compn: agreed. [00:32:33 CEST] <Compn> jamrial : you know its going to be a subscription os, right? pay $100 year for windows. [00:32:43 CEST] <Compn> every year. until the end of time. [00:32:46 CEST] <jamrial> no, it's not [00:32:48 CEST] <wm4> a fresh win81 install is plastered with commercials [00:32:50 CEST] <Compn> no? [00:32:53 CEST] <jamrial> where did you get that? [00:32:57 CEST] <wm4> so no doubt they're pushing this store crap [00:33:01 CEST] <Compn> thats what i'd do if i was microsoften [00:33:09 CEST] <nevcairiel> what commercials [00:33:17 CEST] <nevcairiel> the only commercials a fresh 8.1 now gets is for windows 10 [00:33:20 CEST] <jamrial> Compn: good thing you don't work for them then :p [00:33:59 CEST] <wm4> nevcairiel: when you open what was once the start menu, there are dozens of "applets" active that get content from commercial third party sites [00:34:07 CEST] <wm4> like news, weather, whatever [00:34:12 CEST] <nevcairiel> oh, i never use that [00:34:12 CEST] <Compn> jamrial : http://www.forbes.com/sites/gordonkelly/2015/05/12/free-windows-10-has-high… [00:34:38 CEST] <wm4> and in the video player thing (whatever the heck it is) you readily can subscribe to TV shows etc. [00:34:51 CEST] <wm4> all geared towards dumb consumers [00:35:09 CEST] <nevcairiel> Compn: that article is sensationalism and FUD [00:35:10 CEST] <wm4> not even OSX is this bad [00:35:33 CEST] <Compn> nevcairiel : so windows will be free then ? [00:35:43 CEST] <nevcairiel> fact remains, if you upgrade within the first year, its entirely free [00:35:49 CEST] <nevcairiel> if you wait longer, you pay a one-time upgrade price [00:36:02 CEST] <nevcairiel> unless they extend it, they did that with 8 before [00:36:06 CEST] <wm4> the win10 thing keeps crashing for me [00:36:15 CEST] <wm4> and apparently it wants me to sign in to get win10? [00:36:25 CEST] <jamrial> Compn: it doesn't mention a yearly fee like you said above [00:36:39 CEST] <Compn> jamrial : "Yes, Windows 10 will be the last numbered version of the OS and going forward it will simply become a Windows subscription service. " [00:36:49 CEST] <nevcairiel> thats BS [00:37:00 CEST] <jamrial> so speculation is facts now? [00:37:02 CEST] <Compn> i believe you , thats the last i heard of it [00:37:07 CEST] <nevcairiel> some idea the author created [00:37:09 CEST] <Compn> i havent seen microsoft deny it [00:37:39 CEST] <Compn> i thought it was a news site, not blog speculation [00:37:42 CEST] <Compn> my bad. [00:38:08 CEST] <wm4> hm, tried seeking with the new asf demuxer [00:38:13 CEST] <wm4> it just doesn't work [00:39:34 CEST] <Compn> nevcairiel : to answer your question earlier, i'm no programmer, i cant fix the demuxer old or new. if i find bugs with either i'll report them with samples. [00:39:40 CEST] <nevcairiel> to be fair, it often also doesnt work with the old one wm4 =p [00:39:58 CEST] <wm4> yes [00:40:03 CEST] <nevcairiel> thats really the major complaint I hear from my users, seeking in asf is broken [00:40:10 CEST] <wm4> it's all fucked up [00:40:18 CEST] <Compn> why not port mplayer asf demuxer to ffmpeg ? [00:40:21 CEST] <michaelni> which ticket was that ? [00:40:21 CEST] <Compn> it works, and it doesnt suck :D [00:40:29 CEST] <Compn> for seeking* [00:40:39 CEST] <nevcairiel> Compn: its mplayer, it must suck .. also its probably GPL [00:41:05 CEST] <Compn> >wants to ripoff lgpl code >thinks gpl code is cancer? [00:41:30 CEST] <Compn> sorry, troll slipped out [00:41:46 CEST] <Compn> michaelni : can you do frame-accurate seek with asf file ? [00:41:58 CEST] <Compn> i'm not even sure ffmpeg has a frame accurate seek option [00:42:02 CEST] <nevcairiel> i dont need frame accurate, i need working =p [00:42:13 CEST] <nevcairiel> anyway, sleepy time [00:42:18 CEST] <Compn> nevcairiel : ffmpeg -i file.asf -ss 30 ? [00:42:22 CEST] <wm4> is there a git mirror for mplayer yet? or anything browseable [00:43:35 CEST] <Compn> wm4 : git clone git://git.mplayerhq.hu/mplayer [00:44:00 CEST] <Compn> not sure ............ if that works. [00:44:39 CEST] <wm4> it does [00:44:47 CEST] <Compn> or if updated. [00:45:03 CEST] <nevcairiel> what does mplayer use otherwise, cvs? =p [00:45:04 CEST] <philipl> I git-svn'ed my own. Only took 12 hours. [00:45:18 CEST] <Compn> hey i miss cvs , but mplayer is still on svn. [00:45:25 CEST] <nevcairiel> cvs is terrible [00:45:30 CEST] <wm4> https://github.com/pigoz/mplayer-svn/blob/master/libmpdemux/demux_asf.c [00:45:50 CEST] <Compn> mplayer asf demuxer is half the size of ffmpeg. although i wonder if dvr-ms is not supported [00:46:05 CEST] <wm4> there are other files [00:46:10 CEST] <Compn> ah [00:46:27 CEST] <wm4> asheader.c/h, asf.h, asfguid.h, and of course all the code messed into demuxer.c without any reason [00:46:31 CEST] <Compn> ah [00:46:36 CEST] <Compn> nevermind then [00:47:26 CEST] <Compn> mplayer has support for encrypted/drm asf too. i wasnt able to test that with ffmpeg demuxers-not sure if supported [00:55:22 CEST] <Compn> wm4 : so , just add parsing to lavf asf and will be simple to make it seek like mplayers ? [00:55:46 CEST] <wm4> wat [00:56:40 CEST] <Compn> nevermind, i'm thinking of non-seekable to seekable. [00:56:52 CEST] <Compn> back to jp2k i go. [01:03:18 CEST] <Compn> did anyone ever answer michaelni's question about who maintains asf_o ? [01:04:29 CEST] <Compn> durandal_170 : whos going to fix the new asf demuxer ? where should the bugs be reported? [01:06:40 CEST] <Compn> any volunteers ? [01:06:46 CEST] Action: Compn runs [01:18:10 CEST] <JEEBsv> Compn: sasshka is the author (elenril's sister), and thus the maintainer [01:19:45 CEST] <kierank> JEEBsv: lol [01:21:28 CEST] Action: JEEBsv goes back into thinking about a probing mode that knows its input is PCM and that something could be inside [01:24:49 CEST] <kierank> something in side PCM in ffmpeg [01:24:49 CEST] <kierank> lol [01:24:57 CEST] <kierank> won't work evah [01:25:26 CEST] <JEEBsv> I must say, I was quite surprised I got AAC in PCM to work as a test for my demuxer [01:25:42 CEST] <BBB> isnt PCM simply raw audio data? [01:25:45 CEST] <BBB> or is this another pcm? [01:25:45 CEST] <JEEBsv> I just forced AAC and told I needed full parsing [01:26:25 CEST] <JEEBsv> BBB: bitstreaming [01:27:05 CEST] <JEEBsv> I just got a demuxer working that works with old captures, back when raw MPEG-TS wasn't yet available [01:27:08 CEST] <kierank> there's lots of bitdepth oddities [01:27:26 CEST] <kierank> like how you deal with a 16-bit bitstream within 20-bit pcm (yes this is allowed) [01:28:05 CEST] <rcombs> 4 zero bits? [01:28:22 CEST] <JEEBsv> so it has re-encoded captured 4:2:2 video, and since you could tell your receiver the capture card can habla bitstreaming, bitstreamed AAC in PCM :3 [01:28:48 CEST] <kierank> rcombs: yes but in a continuous 20-bit bitstream [01:29:04 CEST] <kierank> nothing is byte aligned [01:29:06 CEST] <JEEBsv> this was the best you could get up until middle of '07 or so [01:29:15 CEST] <JEEBsv> as far as capturing Japanese DTV went [01:31:03 CEST] <JEEBsv> (unless you had one of those receivers that just gave you the MPEG-TS over firewire or so, although you possibly needed to hardware mod the STB to get that working) [01:44:01 CEST] <Compn> is the default audio encoder for mkv vorbis ? [01:44:35 CEST] <Compn> is vorbis the default audio encoder for mkv ? [01:47:59 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:84afc6b70d24: avcodec/mjpegdec: Fix small picture upscale [02:09:15 CEST] <llogan> Compn: ffmpeg -h muxer=matroska [02:11:16 CEST] <llogan> it depends on your build what the default is [02:55:00 CEST] <BBB> so my understanding is that we now have 2 asf demuxers that both suck? [02:55:05 CEST] <BBB> thats just awesome [03:16:52 CEST] <rcombs> people still care about asf? [03:36:01 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:4aa0de644a2d: avcodec/h264_refs: discard mismatching references [09:12:54 CEST] <cone-130> ffmpeg 03James Almer 07master:6415dcb01318: configure: fix hevc_vdpau_hwaccel dependencies [10:53:49 CEST] <cehoyos> Hi! Can anybody explain to me what "prediction method" means wrt jpeg2000? [11:09:39 CEST] <JEEBsv> Compn: the asf demuxer person woke up so I re-linked the samples you posted to her and she happily accepted them [11:09:41 CEST] <michaelni> cehoyos, the prediction_method is used by the j2k encoder to choose between the 5/3 and 9/7 wavelets, probably a private avoption should be added with a name like wavelet or wavelet_type [11:15:23 CEST] <cehoyos> I'll send a patch in a moment that changes the default pred to 1: This makes the encoder lossless which is what people expect. [11:16:03 CEST] <cehoyos> Or do you disagree? I was surprised to see that for both snow and j2k, "left" is 9/7, everything else is 5/3. [11:16:44 CEST] <cehoyos> JEEBsv, Compn: Are we now doing the reviews for avconv? Are there really so few bugs? [11:17:16 CEST] <cehoyos> So few bugs in FFmpeg, I mean... [11:18:02 CEST] <JEEBsv> of course not, I just see the new demuxer as a positive thing and if someone has taken the effort to test it with some samples and linked some broken ones that's always great [11:18:05 CEST] <JEEBsv> nobody's perfect [11:19:12 CEST] <michaelni> cehoyos, if people prefer lossless wavelet as default (as long as no non lossless quality/qscale is set) then that should be default of course [11:19:17 CEST] <cehoyos> Well, I remember also sending a link to broken samples: Did you forward them? [11:19:56 CEST] <cehoyos> I wonder why these samples aren't a sufficient starting point for her (if she really needs help, I honestly wonder where she searched for relevant samples if not on our bug tracker) [11:20:26 CEST] <JEEBsv> I haven't been looking at the ML :) [11:20:27 CEST] <cehoyos> michaelni: The jpeg2000 encoder does not listen to qscale, or does it? [11:21:03 CEST] <michaelni> s->lambda = s->picture->quality * LAMBDA_SCALE; [11:21:08 CEST] <cehoyos> Just found it... [11:21:33 CEST] <cehoyos> So what is the correct solution? And isn't the j2k encoder non-experimental if it can encode losslessly? [11:22:57 CEST] <michaelni> if people feel its good enough then the experimental flag could indeed be removed [12:09:50 CEST] <cehoyos> michaelni: No comments for "Only fail aac mpegts muxing if the first frame is broken"? [12:17:15 CEST] <Compn> cehoyos : that was literally 10 minutes worth of work and barely 30 samples i looked at. [12:18:00 CEST] <Compn> and i only did that because at least 3 developers in ffmpeg thought you and michaels' opinion of the demuxer was wrong [12:18:38 CEST] <cehoyos> So why do you think they thought we (I?) were wrong? [12:18:42 CEST] <cehoyos> I am curious... [12:18:51 CEST] <cehoyos> And I still didn't see their samples;-( [12:18:59 CEST] <Compn> they thought you were biased against any code from libav [12:19:09 CEST] <cehoyos> Of course! That is why I tested it. [12:19:22 CEST] <Compn> well they wanted you to post samples that you tested [12:19:28 CEST] <cehoyos> Didn't i? [12:19:34 CEST] <Compn> i dont remember any urls... [12:19:51 CEST] <cehoyos> http://ffmpeg.org/pipermail/ffmpeg-devel/2015-June/174755.html [12:20:10 CEST] <Compn> lol :) [12:20:28 CEST] <Compn> well, you know, link to one or two , not a list ;D [12:20:43 CEST] <cehoyos> And as said: I wonder what else could be the starting point, or do I miss something? [12:21:13 CEST] <Compn> you are right, that is the starting point, and all asf/wmv/dvr-ms samples on samples repo. why those files werent all tested is a mystery to me. [12:21:26 CEST] <cehoyos> I don't understand: Hendrik explained yesterday that he thinks one or two samples would make no difference (and I actually agree), so I posted all (or probably most) of the samples that fail. [12:21:49 CEST] <cehoyos> So now somebody agrees that this is a mystery, thank you! [12:22:06 CEST] <Compn> cehoyos : some devels dont like you or your opinions , i dont know why :( [12:22:10 CEST] <cehoyos> Now the question is: Why do I not trust those people and everybody else seems to trust them? [12:22:22 CEST] <Compn> i have not the answers. [12:23:11 CEST] <nevcairiel> We just don't distrust them on principal alone like you do [12:23:24 CEST] <cehoyos> Thank you for your enlightening explanations! Allow me to suggest once again to test a few (old!) tickets with status "new", we really need some help! [12:23:56 CEST] <Compn> cehoyos : i had to drop everything and test the demuxer before it became some kind of huge flamewar... [12:24:01 CEST] <Compn> but yes i need to test more tickets [12:24:14 CEST] <cehoyos> nevcairiel: What difference does this make? Yes, I tested the demuxer because I consider them evil people, but how is my opinion about them relevant for the asf demuxer? [12:24:16 CEST] <Compn> cehoyos : thank you for testing all of the trac that you do, its invaluable and you would be hard to replace. [12:25:20 CEST] <cehoyos> Or are you saying that you believe that new demuxer is not the default because I (or somebody) doesn't like the avconv developers? That is very hard to understand... [12:26:06 CEST] <Compn> cehoyos : nevcairiel is taking the position that libav does not use our code out of principal, so maybe he thinks you do the same thing. instead of reviewing for technical problems like ffmpeg has always done and always will do in the future. [12:26:23 CEST] <Compn> at least thats the only way i can read his statements [12:26:26 CEST] <cehoyos> As said, this is hard to understand... [12:26:58 CEST] <cehoyos> (Except for the issue that I believe you cannot know what FFmpeg will do in the future...) [12:27:06 CEST] <Compn> lol [12:27:14 CEST] <Compn> got me there [12:27:44 CEST] <durandal_170> I don't get it [12:27:50 CEST] <cehoyos> What? [12:28:30 CEST] <Compn> i dont get why libav has a malfunctioning bugreport system. [12:28:38 CEST] <cehoyos> It is not malfunctioning [12:28:44 CEST] <Compn> its on purpose? [12:28:49 CEST] <cehoyos> And to the best of my knowledge it was never malfunctioning. [12:28:57 CEST] <wm4> ffmpeg's bug report system is also malfunctioning [12:29:17 CEST] <cehoyos> Afaict, this was the explanation that Reinhrad used (or was told to use) when Debian asked what happens with bug reports on avconv. [12:29:38 CEST] <Compn> cehoyos : some devs dont like how you close their bugs. i've asked you in the past to leave bugreports alone if reported by Daemon404 and now i'm asking to leave wm4 bugs alone ;D [12:29:40 CEST] <cehoyos> (I use the avconv bugreport system very regularly to find issues) [12:29:54 CEST] <Compn> ah, so debian misinfo :\ [12:30:09 CEST] <Compn> remind me never to use debian/buntu again [12:30:21 CEST] <cehoyos> I leave bug reports alone that I cannot reproduce (as said there are many with status "new"), I will continue to close incomplete or duplicate reports. [12:31:02 CEST] <cehoyos> But please do replace me if you can do better, or suggest that somebody else replaces me: You would do me a favour! [12:31:02 CEST] <durandal_170> Why are you doing all this? [12:31:06 CEST] <cehoyos> What? [12:31:17 CEST] <Compn> well sometimes devs just want to report a bug without full uncut output, is that so wrong, cehoyos ? [12:31:27 CEST] <cehoyos> Yes, do you disagree? [12:31:29 CEST] <nevcairiel> Your definition of incomplete is what's the problem, bug reports against the API just don't come with a uncut ffmpeg output [12:31:45 CEST] <nevcairiel> Because ffmpeg.c is not involved [12:31:48 CEST] <cehoyos> Do you remember me closing an "API bug report"? [12:32:08 CEST] <cehoyos> I do close the ticket if no explanation is given if the issue can be reproduced with ffmpeg or not. [12:32:53 CEST] <cehoyos> durandal_170: Of which asf demuxer are you in favour? Which samples did you test? [12:33:33 CEST] <Compn> cehoyos : like i said, i cant replace you. i'm just trying to get other devs not to get so mad at you. i like your work. [12:33:51 CEST] <nevcairiel> Anyone that looked at the code should agree that the new one should be favored once it's been properly tested, the old one is just terrible spaghetti code [12:34:05 CEST] <cehoyos> Hmm. [12:34:07 CEST] <durandal_170> I tested several samples and mplayer asf demuxer is winner [12:34:23 CEST] <Compn> should port mplayer asf to ffmpeg :) [12:34:26 CEST] <Compn> gpl only! [12:34:30 CEST] <Compn> :)))) [12:34:32 CEST] <cehoyos> nevcarirel: It is true that this is an argument I am quite strongly biased against. [12:34:52 CEST] <wm4> <cehoyos> I do close the ticket if no explanation is given if the issue can be reproduced with ffmpeg or not. <- why do I have to go through the trouble to reverse-engineer ffmpeg.c just to see whether it can reproduce the problem [12:34:55 CEST] <cehoyos> durandal_170: I don't disagree but how is this related to question? [12:35:04 CEST] <wm4> or even to find out if it can [12:35:14 CEST] <Compn> wm4 : just paste some trac urls that are closed [12:35:19 CEST] <cehoyos> wm4: I believe you don't have to - there is irc and the user mailing lists. [12:36:13 CEST] <cehoyos> But from my experience bug reports that I fail to reproduce are very rarely fixed: So either you are interested in the issue and epxlain how it can be reproduced or it won't be fixed. [12:36:26 CEST] <cehoyos> (It will often be fixed accidentally of course.) [12:37:14 CEST] <cehoyos> And this is of course not a decision I made, I am just descirbing my ten-year experience with bug fixing in FFmpeg. [12:39:09 CEST] <durandal_170> there sure are bugs that you closed and I reopened [12:39:55 CEST] <cehoyos> And there are more bugs that you closed and I reopened;-)) [12:47:35 CEST] <Compn> nevcairiel : also no one made the argument that the code shouldnt be replaced until it was tested. its just our definition of 'tested' is different i think [12:48:53 CEST] <Compn> for instance, after its in libav for at least a year as the default, i think that would be a good test. [12:49:11 CEST] <Compn> although not a complete test, a good one. [12:49:32 CEST] <cone-130> ffmpeg 03Luca Barbato 07master:5bdfc17189e4: asf: Do not skip data streams [12:49:33 CEST] <cone-130> ffmpeg 03Michael Niedermayer 07master:8f9c39b3e8c9: avformat: rename asfdec.c to asfdec_f.c [12:49:34 CEST] <cone-130> ffmpeg 03Michael Niedermayer 07master:0d5a27c2b5a1: Rename asfdec-o.c to asfdec_o.c [12:49:35 CEST] <cone-130> ffmpeg 03Michael Niedermayer 07master:3cd6b6aa0f84: Merge commit '5bdfc17189e4ea63c6b46b6d5256852fcb409d68' [12:49:35 CEST] <Compn> or a good start. [12:49:54 CEST] <cehoyos> Compn: Who would test the new demuxer in the next year? [12:50:00 CEST] <Compn> shhhh you :D [12:50:31 CEST] <iive> what is the big deal with the asf demuxer? [12:50:45 CEST] <cehoyos> That's what I would like to know! [12:50:45 CEST] <wm4> iive: it was rewritten by evil people [12:50:45 CEST] <Compn> iive : they didnt even test samples from samples.ffmpeg.org on it. [12:51:09 CEST] <cehoyos> wm4: While this is true, it has no relevance whatsoever afaict. [12:51:11 CEST] Action: Compn wonders why we even bother having a samples repo if no one uses it [12:51:14 CEST] <cehoyos> (At least not for me!) [12:51:39 CEST] <cehoyos> Well, I need it very much and I would be quite unhappy if it disappears. [12:52:26 CEST] <iive> well, they rewrite stuff. what's the problem with it? [12:52:46 CEST] <iive> (it=asf demuxer) [12:52:52 CEST] <Compn> fails to decode bunch of files (all dvr-ms i think?) [12:53:09 CEST] <Compn> er demux* [12:53:20 CEST] <cehoyos> iive: No problem, it's their time! [12:53:42 CEST] <Compn> crashes on go2meeting , although i didnt reproduce that [12:54:18 CEST] <Compn> well i didnt test ffprobe [12:55:10 CEST] <wm4> Compn, cehoyos: can you give me a list of links to files that currently fail with the new demuxer? [12:55:22 CEST] <Compn> wm4 : the two mails i posted [12:55:31 CEST] <Compn> are the ones i found to fail [12:55:46 CEST] <Compn> i didnt test more than that [12:55:54 CEST] <cehoyos> Link to my email is above (although since you answered I believe you read it) [12:56:08 CEST] <Compn> they include the links [12:56:12 CEST] <Compn> i can paste them to you if you want [12:56:20 CEST] <Compn> i think someone posted them to the developer [12:56:41 CEST] <Compn> who i now know the irc nick of, so i can now report them properly next time :P [12:57:16 CEST] <Compn> but i probably wont spend more time on it, until at least all samples.ffmpeg.org are tested. [12:57:26 CEST] <Compn> including carl's url which has all trac samples... [12:58:23 CEST] <Compn> muh speghetti code [13:00:42 CEST] <cehoyos> wm4: Is ticket 4499 valid? Wouldn't the time that gets spent in the beginning now (iiuc) have to be spent anyway? Or do I misunderstand? [13:06:32 CEST] <cone-130> ffmpeg 03Luca Barbato 07master:1b4c468477f3: riff: Validate the wav header size before trying to parse it [13:06:32 CEST] <wm4> cehoyos: looks like the usual complaint about how subtitles are not part of the normal processing [13:06:33 CEST] <cone-130> ffmpeg 03Michael Niedermayer 07master:6d9dfb1267d0: Merge commit '1b4c468477f3b8d372da8ef4e5405539ad9c1501' [13:06:55 CEST] <wm4> that is, hardsubbing subtitles with lavfi [13:07:40 CEST] <cehoyos> So it is a duplicate of ticket 2067? [13:09:03 CEST] <wm4> probably [13:15:18 CEST] <cone-130> ffmpeg 03John Högberg 07master:42bc768e5240: mpegts: Add jpeg2000 stream type [13:15:19 CEST] <cone-130> ffmpeg 03Michael Niedermayer 07master:088b410ea2ee: Merge commit '42bc768e5240ec01237ad2eb7c69b917158de258' [13:23:59 CEST] <Compn> cehoyos : do you remember the bug where png files were being converted with lower luma? and colormatrix was the solution to set bt709 ? i cant seem to find that bug. trying to help mencoder user :P [13:24:49 CEST] <cehoyos> https://trac.ffmpeg.org/search?q=colormatrix ? (No, I don't remember atm) [13:25:05 CEST] <Compn> http://trac.ffmpeg.org/ticket/1582 is all i could find [13:25:56 CEST] <Compn> cehoyos : ah, http://trac.ffmpeg.org/ticket/225 [13:27:33 CEST] <Compn> arg its reopened [13:27:34 CEST] <Compn> ;P [13:29:29 CEST] <cehoyos> Isn't 225 an issue with playback software? [13:30:08 CEST] <Compn> i'm not sure i will have to review the samples. [13:31:38 CEST] <cehoyos> Does anybody know John Högberg? We would really need such a sample, I had searched for it before... [13:39:20 CEST] <cehoyos> Compn: Would you like to write him an email and ask him? [13:40:36 CEST] <cehoyos> (Michael has already done so though) [13:40:44 CEST] <Compn> cehoyos : https://trac.ffmpeg.org/ticket/2267 [13:43:46 CEST] <cone-130> ffmpeg 03James Zern 07master:e91f860ea74e: vp9/update_prob: prevent out of bounds table read [13:50:05 CEST] <Compn> cehoyos : i think this explains the problem , https://trac.ffmpeg.org/wiki/Create%20a%20video%20slideshow%20from%20images [13:50:08 CEST] <Compn> Color space conversion and chroma sub-sampling [13:50:09 CEST] <Compn> By default when using libx264, and depending on your input, ffmpeg will attempt to avoid color subsampling. Technically this is preferred, but unfortunately almost all video players, excluding FFmpeg based players, and many online video services only support the YUV color space with 4:2:0 chroma subsampling. Using the options -pix_fmt yuv420p or -vf format=yuv420p will maximize compatibility. [13:50:28 CEST] <Compn> or maybe not [13:51:42 CEST] <cehoyos> That cannot be the issue when converting from h264 to mpeg4 (which only supports yuv420p, not yuvj420p). [13:51:55 CEST] <cehoyos> I wonder if the issue is that the input files should be interpreted as yuv420p... [13:52:31 CEST] <Compn> i remember yuvj420p was a solution to some problems on the mailing list [13:52:44 CEST] <Compn> i give up for now, driving me crazy. [13:54:39 CEST] <wm4> the yuvj formats are deprecated [13:55:06 CEST] <Compn> great [13:55:42 CEST] <Compn> [image2 @ 031c0360] Pattern type 'glob' was selected but globbing is not supported by this libavformat build [13:56:02 CEST] <Compn> example on that page not support ed in muh nightly build ? [13:56:51 CEST] <cone-130> ffmpeg 03Michael Niedermayer 07master:5c047f3ad49c: avcodec/j2kenc: store libavcodec ident in a comment unless bitexact mode is used [13:57:08 CEST] <nevcairiel> it uses functions from the C runtime for globbing, which may not exist on windows, i dunno [14:01:01 CEST] <Compn> ah [14:15:56 CEST] <[-T-]> high all :) [14:16:01 CEST] <[-T-]> hi* [14:16:24 CEST] <durandal_170> hi [14:16:53 CEST] <[-T-]> using drocon11 qsv decoding implementation, I was able to do qsv decoding + qsv encoding :) [14:17:09 CEST] <[-T-]> actually, I merged drocon11 qsvdec*.c files in master [14:17:14 CEST] <[-T-]> and now it kinda works [14:17:39 CEST] <[-T-]> though, i cannot use ffmpeg sw deinterlacing because I only have NV12 pixels :/ [14:25:04 CEST] <wm4> wat [14:34:08 CEST] <[-T-]> wat wat ? [14:44:10 CEST] <cehoyos> michaelni: Pushed three patches to github, please merge; no opinion about http://ffmpeg.org/pipermail/ffmpeg-devel/2015-June/174749.html ? [15:09:01 CEST] <cone-130> ffmpeg 03Carl Eugen Hoyos 07master:8080688d0e3d: lavc/hapenc: Silence a warning for multithreaded encoding. [15:09:02 CEST] <cone-130> ffmpeg 03Carl Eugen Hoyos 07master:e97ec65630d1: doc: Add jpeg2000 encoder documentation. [15:09:03 CEST] <cone-130> ffmpeg 03Carl Eugen Hoyos 07master:0f5b99653120: lavc/j2kenc: Make jp2 output compatible with Kakadu. [15:10:59 CEST] <cehoyos> michaelni: I also pushed a small configure patch to show the relation of snappy and hap, please merge. [15:12:31 CEST] <michaelni> cehoyos, can you rebase this on top of master (without that trailing whitespace i removed from the previous commit) [15:12:52 CEST] <cehoyos> Sorry... [15:12:53 CEST] <michaelni> merge would be a mess otherwise [15:12:58 CEST] <cehoyos> Where was it? [15:13:01 CEST] <cehoyos> In the doc? [15:13:09 CEST] <michaelni> yes [15:14:30 CEST] <cehoyos> michaelni: Done, thank you! [15:22:36 CEST] <cone-130> ffmpeg 03Carl Eugen Hoyos 07master:9295ee137ac9: configure: Mention hap encoding for --enable-libsnappy. [16:04:13 CEST] <Compn> [-T-] : thanks for testing, but it looks like e veryone hates those patches. [16:05:26 CEST] <michaelni> hate ? what patches ? [16:06:25 CEST] <michaelni> qsv?, i dont hate clean qsv support [16:07:20 CEST] <michaelni> the patches need some cleanup yes [16:07:47 CEST] <[-T-]> yes ... [16:07:52 CEST] <wm4> "some" [16:08:12 CEST] <[-T-]> these patches are not fully functionnal [16:08:52 CEST] <[-T-]> but at least, https://github.com/drocon11/ffmpeg-qsv/tree/qsvdec works much better than master [16:09:00 CEST] <[-T-]> for qsv decoding ... [16:09:15 CEST] <[-T-]> now I miss VPP .. without it, no deinterlacing [16:09:35 CEST] <[-T-]> the dirty merge is here: https://github.com/TheTroll/ffmpeg [16:10:21 CEST] <wm4> as if vpp deint works in any shape or form [16:11:07 CEST] <[-T-]> what do you mean ? [16:13:05 CEST] <cone-130> ffmpeg 03Michael Niedermayer 07master:0083c16605aa: avfilter/vf_transpose: Fix rounding error [16:13:27 CEST] <wm4> [-T-]: I know xbmc struggled to get it to work [16:13:31 CEST] <wm4> and so did I [16:16:03 CEST] <[-T-]> quicksync VPP ? [16:16:33 CEST] <Compn> michaelni : i wasnt talking about you, but j-b seemed to indicate his displeasure for those patches. [16:16:42 CEST] <Compn> amongst other developers [16:16:58 CEST] <j-b> of course [16:17:01 CEST] <j-b> it's utter crap [16:17:26 CEST] <[-T-]> is there a way, besides trans-pifmt-ing and hw deinterlacing, to deinterlace NV12 ? [16:17:27 CEST] <j-b> as usual, with Intel, sorry to say [16:18:10 CEST] <Compn> [-T-] : add nv12 to deint filters or maybe some opengl shader deint... [16:18:28 CEST] <Compn> who has nv12 video anyway? :P [16:18:40 CEST] <[-T-]> quicksync :) [16:18:50 CEST] <Compn> it cant output normal pixfmt ? [16:18:50 CEST] <[-T-]> it outputs and takes as input NV12 [16:19:00 CEST] <[-T-]> that or RGB4 [16:19:04 CEST] <Compn> blurgh [16:19:32 CEST] <Compn> adding it to filters doesnt sound like that difficult of a task though [16:19:33 CEST] <[-T-]> which makes it impossible to use the regular imgconvert deint [16:19:36 CEST] <Compn> maybe i'm wrong... [16:19:48 CEST] <[-T-]> not sure how to do that :) [16:19:56 CEST] <[-T-]> if you have some spare time .. :p [16:20:14 CEST] <Compn> make sample of interlaced nv12 so we can test with [16:20:38 CEST] <Compn> preferably high motion of course [16:20:45 CEST] <j-b> interlaced NV12 ? [16:20:51 CEST] <j-b> Compn: all hardware decoder output NV12 [16:21:01 CEST] <j-b> Compn: it's the defacto standard [16:21:08 CEST] <Compn> yes i know nv12 is what all video cards use [16:21:14 CEST] <Compn> i just never seen it in an mkv file :P [16:21:25 CEST] <j-b> raw? me neither. [16:22:01 CEST] <j-b> for software, NV12 would be the standard too, if FFmpeg did not output I420 [16:22:02 CEST] <Compn> should ask intel to donate some hw to devs so we can test shit. [16:22:06 CEST] <[-T-]> Compn: can I easily do that with a ffmpeg command line ? [16:22:19 CEST] <[-T-]> using the h264_qsv decoder [16:22:33 CEST] <Compn> probably not, i like making difficult requests [-T-] [16:22:37 CEST] <[-T-]> :) [16:22:47 CEST] <[-T-]> well, if i ask for .yuv output [16:22:57 CEST] <[-T-]> will it transform pixels to YUV420 ? [16:23:00 CEST] <Compn> probably yes [16:23:52 CEST] <Compn> its just easier for some devs to work with a file instead of a hardware output... [16:23:55 CEST] <Compn> is all i'm saying [16:23:56 CEST] <[-T-]> if there an API i could use to dump the frames in a file ? [16:24:14 CEST] <Compn> because some devs dont have intel hardware [16:24:23 CEST] <Compn> or other... hardware [16:24:55 CEST] <Compn> ffmpeg can probably just generate nv12 [16:24:58 CEST] <Compn> in software [16:25:01 CEST] <Compn> just because. [16:29:12 CEST] <[-T-]> yes [16:29:36 CEST] <[-T-]> but anyway, getting the full QSV chain would be awesome [16:29:49 CEST] <[-T-]> for live tv transcoding for instance [16:40:41 CEST] <kierank> planar is just a historical oddity [16:40:45 CEST] <kierank> from avisynth et al [16:40:57 CEST] <kierank> most of the world uses packed chroma (x264 included) [16:41:36 CEST] <wm4> planar is easier to handle [16:41:44 CEST] <wm4> nv12 is just a wtf cross between packed and planar [16:41:55 CEST] <wm4> a sane world would use s 4:4:4 32 bit packed format only [16:42:53 CEST] <kierank> packed is faster [16:42:57 CEST] <kierank> cf x264 [16:44:01 CEST] <wm4> by how many percent? [16:44:23 CEST] <nevcairiel> low single digits, but still, its not like nv12 is a complex format [16:53:29 CEST] <BtbN> Bullshit of the day: nvenc is better than x264 because it produces smaller files at the same bitrate. [16:54:13 CEST] <nevcairiel> heh [16:54:32 CEST] <kierank> loool [16:54:49 CEST] <BtbN> According to the comments on that YouTube video, you also need at least an i5 for NVENC to perform propperly, and you might want to overclock it a bit. [18:21:41 CEST] <durandal_170> how much eedi3 is useful? [18:22:30 CEST] <JEEBsv> nnedi3 you mean? [18:22:58 CEST] <nevcairiel> there is also eedi .. there is a whole long family of algorithms of the edi kind [18:24:23 CEST] <JEEBsv> yeah [18:24:33 CEST] <JEEBsv> just that usually people use nnedi3 for general usage [18:43:20 CEST] <durandal_170> but that one use 20mb data [19:34:54 CEST] <philipl> wait, so libmxf works on linux? [19:35:10 CEST] <BtbN> Intel implemented it as a wrapper on top of libva there... [19:35:16 CEST] <philipl> so there's vaapi, yami and mfx on linux? [19:35:22 CEST] <BtbN> exactly [19:35:44 CEST] <BtbN> but only libva actualy interacts with the hardware [19:35:49 CEST] <BtbN> everything else just sits on top of it [19:36:02 CEST] <philipl> but the vaapi api is so terrible that no one will implement direct support in ffmpeg [19:36:16 CEST] <philipl> so we get these wrapper patches from intel. [19:36:31 CEST] <BtbN> Well, nice thing about mfx/qsv is, it also works on windows. [19:37:10 CEST] <philipl> sure. this patch set then makes the raw vaapi decoder redundant? [19:37:21 CEST] <BtbN> When i asked in the intel channel about improving the libva encoding api instead, i got called a troll who has obviously never had any experience with hardware encoders. [19:37:43 CEST] <philipl> hah. [19:38:12 CEST] <BtbN> "you have to manualy generate parts of the NAL and pass it to libva" "That's how all hardware encoders work" [19:38:27 CEST] <philipl> ok. so yami was rejected for being a useless wrapper. qsv is ok on linux because we have to have it for windows anyway. [19:38:41 CEST] <BtbN> currently, QSV is windows-only i think [19:38:41 CEST] <philipl> so beautiful. [19:38:48 CEST] <philipl> until now [19:38:52 CEST] <BtbN> without that patch, it doesn't work on linux. [19:38:56 CEST] <philipl> right [19:38:58 CEST] <BtbN> And i'm not exactly a fan of that. [19:39:09 CEST] <BtbN> (Of that patch) [19:39:37 CEST] <philipl> It could be made non shitty I guess. [19:40:07 CEST] <BtbN> I think the main point of that patch is that there is no vaapi hwaccell in the ffmpeg cli tool [19:40:19 CEST] <BtbN> With the qsv decoder, it could use hw decoding on intel hw [19:40:24 CEST] <philipl> right [19:40:35 CEST] <philipl> and that's desirsble. [19:40:38 CEST] <BtbN> I'd much rather see ffmpeg_vaapi.c instead [19:41:06 CEST] <philipl> i assume that would be horrible to write, hence no one doing it. [19:41:22 CEST] <BtbN> libva is not that terrible for decoding [19:41:23 CEST] <wm4> <philipl> ok. so yami was rejected for being a useless wrapper. <- not really... many were against it, but in the end the guy didn't post a new patch with all flaws fixed [19:41:45 CEST] <BtbN> Well, with all those complaints he got, that's not too surprising. [19:41:55 CEST] <wm4> BtbN: I was thinking about simplifying the ffmpeg vaapi api in the same way it was done for vdpau [19:42:01 CEST] <philipl> true, he walked away, but there were plenty of objections to the concept. [19:42:22 CEST] <BtbN> i never dealt with the ffmpeg/vaapi interop [19:42:56 CEST] <philipl> does anything use it? __gb__ never got his mplayer hooks merged. [19:43:05 CEST] <philipl> i guess kodi? [19:43:09 CEST] <BtbN> I think xbmc does [19:43:19 CEST] <BtbN> at least it did when i was still trying to add VPP support for hw deinterlacing [19:43:47 CEST] <BtbN> Which btw. was finaly done a few weeks ago(It was over a year ago when i gave up) [19:43:53 CEST] <philipl> heh. [19:45:59 CEST] <BtbN> I got my intel HTPC because of the great open source support [19:46:15 CEST] <BtbN> And ended up sticking an nvidia card in there, because their proprietary drivers actualy work [19:46:21 CEST] <philipl> so if this qsv stuff goes in, there's an argument to deprecate the vaapi stuff. [19:46:32 CEST] <BtbN> Not realy [19:46:34 CEST] <philipl> a familiar story. [19:46:45 CEST] <BtbN> no distro is ever going to package any qsv libraries [19:46:55 CEST] <philipl> libmxf is a disaster? [19:47:06 CEST] <BtbN> You need to register at intel to download it [19:47:19 CEST] <BtbN> And it's closed source [19:47:25 CEST] <philipl> *sigh*. so as broken as nvenc. [19:47:58 CEST] <philipl> i poked some people at nvidia about improving the nvenc header licence. maybe that will pan out. [19:48:34 CEST] <BtbN> I realy need to get some nvidia maxwell card, but they just won't release GT cards... [19:49:13 CEST] <BtbN> There's a bunch of maxwell stuff i'd like to add to nvenc [19:51:07 CEST] <philipl> such as? Most of it seemed behind the scenes. [19:51:35 CEST] <BtbN> primarily yuv444p lossless encoding [19:51:45 CEST] <philipl> Mm. right. [19:52:08 CEST] <philipl> Well, I'm sitting on a 960 and a 980 here ;-) [19:52:38 CEST] <philipl> But i don't want to steal your fun. and dont hsve time. [19:53:03 CEST] <BtbN> It shouldn't be much work. Needs a static init function, which sets the supported pixel formats to yuv444p when the lossless preset is selected, and limits it to the same SM level as it does for hevc [19:54:14 CEST] <BtbN> I need a new card for my HTPC anyway, as the current one has no slot cover plate, so it falls out of its PCIe slot when i move the PC the slightest bit [19:54:29 CEST] <BtbN> But nvidia just doesn't want to release new HTPC cards [20:03:52 CEST] <philipl> yeah. all the new low end cards listed in the last driver release are using recycled chips. no sign of a gm208 yet. [20:05:20 CEST] <wm4> BtbN, philipl: mpv uses vaapi and vpp too (the latter of which probably doesn't work) [20:05:52 CEST] <BtbN> vpp is a mess [20:06:11 CEST] <BtbN> and if you complain, you get told that it works in gstreamer [20:06:35 CEST] <BtbN> and after days of trying to get into that code, which intenaly wraps the api two times, you find out that it actualy doesn't work [20:08:19 CEST] <wm4> 2 times? [20:09:00 CEST] <BtbN> It first has wrappers around basicaly every libva function. And then it wrapts that into some intermediate api, which is then used by the actual gstreamer module [20:09:47 CEST] <BtbN> So even if you look at the intermediate api, you still have to lookup most of what it does [20:11:06 CEST] <wm4> awesome [20:11:08 CEST] <wm4> but why [20:11:25 CEST] <BtbN> I have no idea [20:11:34 CEST] <BtbN> propably someone else wrote each wrapper [20:13:40 CEST] <philipl> if we keep wrapping it, maybe it won't stink. [20:14:32 CEST] <BtbN> I actualy already wrote a "working" libva-only h264 encoder [20:14:41 CEST] <BtbN> But it's P-Frame only, and doesn't have propper rate control [20:14:51 CEST] <nevcairiel> stink always manages to find a way to get through all the wrapping [20:15:07 CEST] <BtbN> The base api is just incomplete [20:15:14 CEST] <BtbN> to make the lives of the people developing it easier [20:18:14 CEST] <philipl> The fact that it even lets you write that kind of partial implementation is damning. [20:36:32 CEST] <jamrial> hevc and mpeg2 qsv encoders on libav ml [20:36:52 CEST] <cone-342> ffmpeg 03Michael Niedermayer 07master:330863c9f19a: avcodec/h264_slice: Use w/h from the AVFrame instead of mb_w/h [20:46:48 CEST] <rcombs> jamrial: still windows-only and nonredistributable? [20:47:44 CEST] <nevcairiel> you can probably use them with lucas libmfx thing, which basically includes the libva thing on our ML, just in separate code [20:49:10 CEST] <rcombs> hmm, I got the impression there as a license issue with libmfx but now that I look, the Zeranoe builds have it [20:49:51 CEST] <nevcairiel> I wanted to investigate enabling qsv encoding for a distributed build, but I was told it breaks XP support of the binary, I need to confirm if I can do that yet [20:49:53 CEST] <nevcairiel> damn $work =p [20:50:45 CEST] <rcombs> >XP >2015.5 [20:50:48 CEST] <jamrial> also, mingw-w64 apparently added the missing bits to get d3d11va hwaccel working on trunk [20:51:03 CEST] <jamrial> mingw-w64 v5 is going to be nice [20:51:27 CEST] <nevcairiel> > mingw-w64 trunk, would rather shoot myself into the foot, and I'm still healing from the last foot injury! [20:52:19 CEST] <jamrial> hey, nobody forces you to use it. just wait for it to be branched and tagged :p [20:52:50 CEST] <jamrial> msys2's gcc package uses mingw-w64 trunk for some reason, so i'm using that [20:53:06 CEST] <nevcairiel> I dont think they actually really branch from trunk, they slowly merge a whole lot of stuff into the stable branch and tag/branch from that [20:53:14 CEST] <nevcairiel> well maybe for a major version like 5 they do [20:53:15 CEST] <jamrial> expect when i need to compile something that doesn't depend on a billion dlls, where i use a custom build static gcc using v4 [20:53:16 CEST] <nevcairiel> what do i know [20:53:23 CEST] <jamrial> *except [20:53:37 CEST] <nevcairiel> I always use my own gcc builds [20:53:42 CEST] <nevcairiel> in fact, just finished 4.9.3 [20:53:54 CEST] <nevcairiel> (if anyone cares: http://files.1f0.de/mingw/mingw-w64-gcc-4.9.3-stable-r14.7z) [20:55:01 CEST] <nevcairiel> I'm undecided if I should care about d3d11va .. there is one or two things I might like having, but I'm told its a bitch to setup, more boilerplate than dxva2 [20:55:56 CEST] <jamrial> my custom gcc is a recent snapshot from the 5.1 branch, which i will replace with 5.2.0 as soon as it comes out in two weeks [20:56:07 CEST] <nevcairiel> I guess more like 3 [20:56:13 CEST] <nevcairiel> they never hit their projected release dates [20:56:13 CEST] <cone-342> ffmpeg 03Vittorio Giovara 07master:3ad678a85b96: fate: Update ac3 test to the new request_channel_layout option [20:56:14 CEST] <cone-342> ffmpeg 03Michael Niedermayer 07master:a9aed08fa4e9: Merge commit '3ad678a85b96fc5fecd60e3d3a31ca5ffc89d67f' [20:56:42 CEST] <jamrial> is it Win8 only for that matter, or works also on Vista/7? [20:57:24 CEST] <nevcairiel> d3d11? Thats a bit .. odd. Its documented to only work on 8+, but it also seems to work on 7 to some degree [20:57:33 CEST] <jamrial> configuring ffmpeg with _WIN32_WINNT=0x0600 (AKA, Vista) seems to enable it using mingw-w64 trunk [20:58:34 CEST] <nevcairiel> mingw often has those version guards wrong, but in this case its not, d3d API is not protected by that at all [20:58:42 CEST] <nevcairiel> even msvc SDK has them unprotected [20:59:21 CEST] <nevcairiel> win7 has those APIs, but if the documentation is right it should result in runtime init failures, but apparently, it doesn't when you request a certain profile [20:59:46 CEST] <nevcairiel> its a bit contradictory in the docs [21:01:52 CEST] <cone-342> ffmpeg 03Paul B Mahol 07master:185e76976e82: avfilter/vf_ssim: fix some cosmetics issues [21:02:13 CEST] <nevcairiel> so TL;DR, it s eems to work on 7 at least [21:02:15 CEST] <nevcairiel> vista not sure [21:02:26 CEST] <jamrial> nobody cares about vista anyway :p [21:02:39 CEST] <jamrial> but Win7 looks like will be the new XP [21:02:41 CEST] <nevcairiel> luckily avcodec doesnt actually need to link against anything d3d11-wise [21:02:56 CEST] <nevcairiel> so no runtime deps on d3d11 being available from that side [21:04:17 CEST] <nevcairiel> people will irrationally stick to their long-time OS no matter what [21:04:19 CEST] <JEEBsv> jamrial: we'll see how much traction win10 gets with the free upgrades and seemingly rolling thing [21:04:28 CEST] <nevcairiel> but I think win10 might have the right sauce to win a bunch of them over [21:04:30 CEST] <JEEBsv> although sure, corps will stay on some LTS-like thing [21:04:42 CEST] <JEEBsv> (including one of the LTS versions of win10) [21:05:54 CEST] <jamrial> assuming dx12 is even half as good as it's being sold as, i'm making the switch [21:07:04 CEST] <nevcairiel> DX12 and the other low-overhead APIs should deliver, assuming the games actually use them properly to multi-thread more [21:19:23 CEST] <cone-342> ffmpeg 03Vittorio Giovara 07master:3e3056f2a020: h264: Allow stream and container cropping at the same time [21:19:24 CEST] <cone-342> ffmpeg 03Michael Niedermayer 07master:2e9dcb82e5d5: Merge commit '3e3056f2a020dd77efdf379dbd4c06a65b4a499a' [21:26:09 CEST] <cone-342> ffmpeg 03Vittorio Giovara 07master:303ec065a904: aic: Fix slice size computation for widths multiples of 32 macroblocks [21:26:10 CEST] <cone-342> ffmpeg 03Michael Niedermayer 07master:4ff0c61ba800: Merge commit '303ec065a90498c29d384b4add2ac626bc38d5eb' [22:01:32 CEST] <cone-342> ffmpeg 03Luca Barbato 07master:e95c7a61852c: mov: Preserve the metadata even when bit-exactness is requested [22:01:33 CEST] <cone-342> ffmpeg 03Michael Niedermayer 07master:cfcb9f5e3628: Merge commit 'e95c7a61852cc5b9ce5445ff034b87553e61958a' [22:06:05 CEST] <llogan> damn it. i was hoping ffmpeg-trac ML wouldn't break URLs [22:10:01 CEST] <cone-342> ffmpeg 03Luca Barbato 07master:6f4cd33efb5a: cosmetic: Reformat ff_h263_decode_mba [22:10:02 CEST] <cone-342> ffmpeg 03Michael Niedermayer 07master:5585da7c5e47: Merge commit '6f4cd33efb5a9ec75db1677d5f7846c60337129f' [22:16:38 CEST] <lglinskih_> wm4, kierank: can you review my first version of seek-test? Did I correctly understand what you want?=) https://github.com/lglinskih/FFmpeg/blob/59715a3353eaa319529d8c3a11dd93fe87… [22:18:36 CEST] <wm4> looking [22:19:29 CEST] <wm4> lglinskih_: duplicating the code for decoding before and after the seek isn't really ideal [22:19:46 CEST] <wm4> lglinskih_: it also should be able to perform multiple seeks, each with possibly different parameters [22:20:00 CEST] <wm4> and each time, a different number of packets might be read and decoded [22:27:06 CEST] <cone-342> ffmpeg 03Luca Barbato 07master:0a49a62f9987: h263: Always check both dimensions [22:27:07 CEST] <cone-342> ffmpeg 03Michael Niedermayer 07master:2a227fe8799e: Merge commit '0a49a62f998747cfa564d98d36a459fe70d3299b' [22:32:13 CEST] <lglinskih_> wm4: now it's actually reads and decodes a different number of packets, but it starts reading only from the first frame [22:32:50 CEST] <lglinskih_> wm4: next step -- seek not only to 0 [22:36:32 CEST] <cone-342> ffmpeg 03Vittorio Giovara 07master:0bfab80a0d9f: h264_sei: Group error check outside the switch block [22:36:33 CEST] <cone-342> ffmpeg 03Michael Niedermayer 07master:8e6c5c432236: Merge commit '0bfab80a0d9fce0180e8aa2a947267f89b725091' [23:07:49 CEST] <cone-342> ffmpeg 03Vittorio Giovara 07master:271ce76d317c: h264: Parse registered data SEI message and AFD value [23:07:50 CEST] <cone-342> ffmpeg 03Michael Niedermayer 07master:7e9c7b623f05: Merge commit '271ce76d317c5432e151216cf23f12b77ed6cb7e' [23:23:15 CEST] <cone-342> ffmpeg 03Nicolas DEROUINEAU 07master:04a68f43488c: avcodec/h264: Greenmetadata SEI parsing [23:33:43 CEST] <wm4> nevcairiel, Daemon404: remind me, can DLLs export variables? [23:35:10 CEST] <Plorkyeran> yes [23:35:13 CEST] <Plorkyeran> but please don't do that [23:35:28 CEST] <wm4> ffmpeg already seems to export av_util_ffversion [23:36:22 CEST] <nevcairiel> yeah its possible, but its rather ugly to import them [23:36:25 CEST] <Daemon404> we had purposely removd all exported variables [23:36:35 CEST] <wm4> too bad they're back! [23:36:51 CEST] <wm4> added in december 2014 [23:39:16 CEST] <wm4> it lacks av_export, which is apparently required for variables [23:39:39 CEST] <nevcairiel> there is still a few left, btw [23:39:43 CEST] <nevcairiel> avpriv mostly [23:41:03 CEST] <nevcairiel> codec data shared between decoder and demuxer [23:44:35 CEST] <kierank> lglinskih_: looks ok as long as you seek to somewhere not 0 :) [23:46:56 CEST] <kierank> I'm not 100% sure how you're going to make reference files [23:48:34 CEST] <wm4> hm, I also wonder how to confirm the results [23:48:53 CEST] <wm4> when seeking in a player, you often get visual corruption etc. if something is wrong [23:50:44 CEST] <BBB> even if something is not wrong you may still get visual corruption [23:50:50 CEST] <BBB> just try seeking in a hevc/annexb stream [23:51:13 CEST] <nevcairiel> one could argue something is wrong then =p [23:52:27 CEST] <BBB> I suppose [23:52:41 CEST] <BBB> I mean, when an asteroid hits earth and all dinosaurs die, you could claim something is wrong [23:52:59 CEST] <BBB> but I dont think that suggests theres a mechanism in place to prevent it - its the expected behaviour [23:53:13 CEST] <nevcairiel> h264 knows how to prevent it [23:53:20 CEST] <BBB> yeah, hevc doesnt do that :( [23:54:30 CEST] <BBB> brb [23:59:31 CEST] <wm4> could someone coerce Stephan Holljes into posting proper patches? [23:59:47 CEST] <wm4> that is, using git send-email [23:59:57 CEST] <nevcairiel> who now [00:00:00 CEST] --- Wed Jul 1 2015

1 0

ffmpeg.log.20150630
by burek 01 Jul '15

01 Jul '15

[00:00:47 CEST] <Nolski> llogan: sorry I'm a bit new to ffmpeg. What's the difference between using the concat protocol vs the demuxer. (or what is the syntax to the demuxer?) [00:09:40 CEST] <kepstin-laptop> Nolski, concat protocol is for when the container type supports file concatenation to join segments (e.g. mpeg-ts). Concat demuxer is for when containers cannot be concatenated (e.g. mp4), but the video stream inside them could be (same codec, parameters, whatever). Concat filter is for when neither of those work and you need to fully decode the video. [00:25:41 CEST] <Nolski> kepstin-laptop: Oh boy, so my videos are all guerenteed to be the same format but I do not know what they may be (very likely either webm or mp4) do I have to choose my command depending on the file type? [00:27:32 CEST] <Mavrik> Are they guaranteed to have the same resolution, framerate, aspect ratio? [00:36:25 CEST] <kepstin-laptop> Nolski, the other thing to consider - are you re-encoding the video anyways? if so, you could just always use the filter method [00:36:41 CEST] <kepstin-laptop> the other two methods are only really useful if in some cases you might not want to re-encode. [00:36:50 CEST] <Nolski> Mavrik: yes [00:37:09 CEST] <Nolski> kepstin-laptop: I wouldn't mind re-encoding [00:37:30 CEST] <Nolski> I might try the filter method. It does look pretty scary haha [01:13:22 CEST] <Nolski> Hmm.. It's saying too many inputs for concat. Am I doing this wrong? https://pastebin.mozilla.org/8838081 [01:14:40 CEST] <c_14> Nolski: well, you should obviously have n=3 [01:14:46 CEST] <c_14> since you have 3 inputs [01:14:58 CEST] <Nolski> Oooh I thought n=3 meant the amount of tracks [01:15:05 CEST] <Nolski> because in the example there were 2 audio and 1 video [04:12:37 CEST] <brewtany> hi [04:12:55 CEST] <brewtany> how can ffmpeg change mpegts start_time? [04:18:17 CEST] <brewtany> to offset the dts/pts [05:18:38 CEST] <pandb> i'm experimenting with generating videos from image sequences. what's the preferred format for such input images? [05:19:39 CEST] <pandb> right now i'm using imagemagick to convert random images from the web to 8-bit rgb pngs that are all 640x480 [05:53:08 CEST] <grepper> I'm no expert on ffmpeg, but png sounds good because it is lossless. [06:50:31 CEST] <grepper> unless you are talking about naming, in which case something like a printf %06d format, ie. 000001.png 000002.png etc [07:22:33 CEST] <pandb> yeah, png seems to work well [07:23:45 CEST] <pandb> my current problem is that i know how to generate a video from a sequence of images. I also know how to broadcast a video to an rtmp server(twitch.tv in this case). [07:24:15 CEST] <pandb> but what I can't figure out is how to do that all in one step [07:24:56 CEST] <chungy> I'm not positive on it, but I think ffmpeg would be able to work with input images of varying dimensions. (btw, you can also use ffmpeg to rescale to 640x480 PNGs) [07:25:07 CEST] <pandb> i.e. broadcast video to rtmp that's generated on-the-fly by a bunch of png files in a directory somewhere [07:25:25 CEST] <chungy> It's the same as both methods. [07:25:41 CEST] <chungy> I'd just give the image sequence as the input, and the rtmp server as the output [07:26:02 CEST] <pandb> chungy, i've been trying different variations on that to no avail [07:26:21 CEST] <chungy> well, [07:26:24 CEST] <pandb> i've even been able to broadcast my X display successfully [07:26:35 CEST] <pandb> um sure [07:26:42 CEST] <pandb> might take a second [08:17:48 CEST] <pandb> fflogger (and anyone else interested), here is some console output related to my problem of streaming a video generated by still images to an RTMP server: http://pastebin.com/LBHX2EqE [08:25:23 CEST] <pandb> oh also chungy, too [09:47:58 CEST] <brewtany> hi, how to change start time of mpegts files? [10:53:38 CEST] <PeterNT> Hello everybody, hope someone can help me: i use ffmpeg for windows and im trying to transcode using the h264_qsv codec. Without QuickSync everything works but with qsv enabled i get a error after some time: Non-monotonous DTS in output stream 0:0; previous: XX, current: 0; changing to XX. This may result in incorrect timestamps in the output file. [10:53:51 CEST] <PeterNT> any idea what i can do? [11:30:54 CEST] <pkeuter> hi there [11:32:33 CEST] <pkeuter> question: when I stream an input device to a file, that file gets locked and im unable to do anything with it. Is there any way I can use the file while it is recording? [11:38:25 CEST] <pandb> pkeuter: can you make a temporary copy of it? [11:40:22 CEST] <nashgul> hi, i've a question, why the 'colorkey filter' is not available on ffmpeg-linux? [11:46:54 CEST] <pkeuter> pandb: that sounds like a good idea. Just copy the recording every n seconds. thanks! [11:49:13 CEST] <durandal_170> nashgul: what is ffmpeg-linux? [11:49:25 CEST] <nashgul> durandal_170: ffmpeg on linux [11:51:49 CEST] <nashgul> i want to overlay to inputs, and replace a color from one input with transparency [11:52:38 CEST] <durandal_170> what is? [11:53:10 CEST] <durandal_170> Operating system name [11:53:15 CEST] <nashgul> archlinux [11:54:24 CEST] <durandal_170> filter is only in git version currently [11:54:42 CEST] <nashgul> libav-git? [11:55:16 CEST] <nashgul> or ffmpeg-git? [11:55:19 CEST] <durandal_170> ffmpeg-git [11:55:23 CEST] <nashgul> ok, thanks [12:02:45 CEST] <BtbN> it's not exactly finished yet though [12:03:36 CEST] <nashgul> well, it's too late, i've removed ffmpeg, and now i'm packing ffmpeg-git :-D [12:07:02 CEST] <chungy> arch packages the stable version of ffmpeg. anything only in the master branch won't be in the arch package :P [12:10:06 CEST] <nashgul> well, no problem, if ffmpeg-git does not work fine i always can come back to stable version, arch is very effective in that case [12:10:58 CEST] <chungy> yup. or do custom compiles and keep the git version in your home directory only. Either way works. :) [12:11:26 CEST] <chungy> (tbh, might be beneficial if ffmpeg-git installed into /opt or somewhere and kept it non-conflicting... but heh) [12:11:34 CEST] <nashgul> chungy: yeah, a good choice [12:12:02 CEST] <chungy> keeping it separate just would reduce the chance of other packages breaking because the libraries underneath changed. [12:13:26 CEST] <nashgul> chungy: i've to remove x265 by x265-hg, i don't know how that change affects to ffmpeg [12:14:15 CEST] <nashgul> maybe only affects when encode with h265 [12:14:34 CEST] <chungy> I wonder if anyone makes a docker images available for ffmpeg. would be awesome for testing :) [12:21:26 CEST] <nashgul> well, by the moment works fine :-D [12:21:42 CEST] <nashgul> durandal_170: thanks a lot for the info [12:56:49 CEST] <nashgul> i don't find the filter or the option for making the output only black & white.. [13:00:41 CEST] <durandal_170> Hardmix with blend filter? [13:00:56 CEST] <nashgul> ummm [13:02:28 CEST] <nashgul> durandal_170: blend filter requieres 2 videos, i have only one [13:02:56 CEST] <durandal_170> some complicated geq expression [13:03:01 CEST] <nashgul> maybe [13:04:18 CEST] <durandal_170> nashgul: for blend that would be some kind of grayscale gradient [13:05:39 CEST] <nashgul> really, what i want to do is: apply showwave filter to an audio input, and then remove the black pixels making them transparency, and after overlay it with the original video source, the problem is showframes creates a greyscale video, i need that video B/W [13:05:43 CEST] <chungy> what about -vf hue=s=0 ? [13:05:51 CEST] <durandal_170> and that one could be created with geq too [13:05:53 CEST] <nashgul> i'll try it [13:07:22 CEST] <theeboat> Does anybody know if its possible to write the timecode on a video file as the current time on the machine capturing the stream? [13:07:49 CEST] <durandal_170> in docs [13:08:26 CEST] <chungy> This might be a weird and complex question, but does anyone know how to apply CRT and/or VCR-like effects to a video? [13:09:03 CEST] <chungy> mainly introducing scanlines and subduing the colors to something like NTSC. Bonus for adding a curved-screen effect. [13:09:31 CEST] <theeboat> when I have done experiments with the examples in the docs I have only got incremental timecodes starting from 00:00. unless theres a specific one which you have got in mind.... [13:11:33 CEST] <nashgul> theeboat: something like this: ffmpeg -i input.file -filter_complex "drawtext=textfile=/file/which/contains/timemachine:reload=1" output.file [13:11:37 CEST] <nashgul> ?? [13:12:11 CEST] <nashgul> also you will need a simple command to writes every second the time on that file [13:12:35 CEST] <theeboat> no sorry. i dont mean to burn the timestamp onto the video. [13:13:21 CEST] <nashgul> theeboat: my command does not show the timestamp, show the local time on your machine [13:14:27 CEST] <nashgul> shows* [13:16:13 CEST] <theeboat> im under the impression drawtext overlays the time on the video? our editors use adobe premier. we record football games and our editors want to be able to refer to specific timestamps [13:17:14 CEST] <nashgul> yes [13:17:51 CEST] <nashgul> drawtext draws text over the video [13:18:49 CEST] <theeboat> yes, thats not what I need ffmpeg to be able to do. I need the timecode of the video to be the actual timestamp of when the video is captured [13:19:42 CEST] <theeboat> for instance now is 11:19 GMT if i was to start recording now i want ffmpeg to write the timecode as 11:19:00 [13:19:53 CEST] <nashgul> time(0) [13:21:18 CEST] <nashgul> https://www.ffmpeg.org/ffmpeg-utils.html#toc-Expression-Evaluation --> time(0) [13:23:27 CEST] <nashgul> theeboat: write in a text file or write over the video? [13:25:15 CEST] <theeboat> neither. when you open a video file you have a timecode as a reference point. if i wanted to skip to 30 seconds into the video i would go to 00:30. What I want is this time code to be the time of when the video began capturing. [13:26:04 CEST] <theeboat> an example would be if i was to start recording at 19:30:00 and i wanted to skip two minutes of the recording i would go to 19:32:00 rather than 00:02:00 [13:27:47 CEST] <nashgul> theeboat: how do you know the time when the record begins? [13:28:07 CEST] <theeboat> the timestamp on the server [13:28:19 CEST] <theeboat> in linux typing the command date [13:28:22 CEST] <theeboat> would show this [13:28:26 CEST] <nashgul> ok ok [13:28:51 CEST] <nashgul> you can make a simple bash script to calculate the offset time [13:29:48 CEST] <nashgul> if video begins at 18:05.43 and you want play 19:00.00 -> 19:00.00 - 18:05.43 [13:30:07 CEST] <nashgul> 00:54.17 [13:30:38 CEST] <nashgul> -ss 00:54:17 ... [13:31:49 CEST] <theeboat> is it not possible to write this as the timecode within the video file? [13:33:06 CEST] <theeboat> basically the reason behind this is that when we capture the videos its possible that the cameraman may unplug the camera. ffmpeg will not fill this with blank frames it will just jump from when the video stopped and when the cameraman plugged the video back in [13:37:38 CEST] <nashgul> -timestamp HH:MM:SS.xxx output.file ? [13:45:31 CEST] <davidpeach> hello people [13:46:50 CEST] <davidpeach> I am currently streaming mp4 output into node pipe to the browsers But the result is choppy - it loads a bit, plays that bit really fast, waits for next piece, plays that really fast thn on and on. Any ideas? Thanks in advance. [13:50:10 CEST] <davidpeach> ill add code to pastebin [13:51:25 CEST] <davidpeach> http://pastebin.com/3iEY7kEN [13:51:35 CEST] <davidpeach> thank you to whoever answers my query [14:09:24 CEST] <davidpeach> hi - can anybody help my query please? [14:14:29 CEST] <davidpeach> I am currently streaming mp4 output into node pipe to the browsers But the result is choppy - it loads a bit, plays that bit really fast, waits for next piece, plays that really fast thn on and on. Any ideas? Thanks in advance. [14:14:35 CEST] <davidpeach> http://pastebin.com/3iEY7kEN [14:29:55 CEST] <davidpeach> I am currently streaming mp4 output into node pipe to the browsers But the result is choppy - it loads a bit, plays that bit really fast, waits for next piece, plays that really fast thn on and on. Any ideas? Thanks in advance. [14:29:56 CEST] <davidpeach> http://pastebin.com/3iEY7kEN [14:33:27 CEST] <PeterNT> Hello everybody, hope someone can help me: i use ffmpeg for windows and im trying to transcode using the h264_qsv codec. Without QuickSync everything works but with qsv enabled i get a error after some time: Non-monotonous DTS in output stream 0:0; previous: XX, current: 0; changing to XX. This may result in incorrect timestamps in the output file. [14:33:37 CEST] <PeterNT> any ideas? [14:49:13 CEST] <hadrien> Hello, is seeking supposed to work with the mt2s container? [14:50:56 CEST] <hadrien> More precisions: ffmpeg -ss 00:13:00.000 -i 00001.m2ts -to 00:14:00.000 -c:v copy -an -sn out.mkv just never stops, when it should do approximately 1min [14:53:29 CEST] <davidpeach> I am currently streaming mp4 output into node pipe to the browsers But the result is choppy - it loads a bit, plays that bit really fast, waits for next piece, plays that really fast thn on and on. Any ideas? Thanks in advance. [14:53:31 CEST] <davidpeach> http://pastebin.com/3iEY7kEN [14:55:45 CEST] <relaxed> hadrien: try with -ss and -to before the -i [14:57:24 CEST] <hadrien> Error: Option to (record or transcode stop time) cannot be applied to input file 00001.m2ts [14:58:12 CEST] <relaxed> hmm, try with both after the -i [14:58:24 CEST] <hadrien> That's what I tried. [14:58:41 CEST] <hadrien> What's strange is that this exact syntax works on my mp4 and mkvs, but on this mt2s. [14:58:47 CEST] <hadrien> -ss -i -t works [14:59:11 CEST] <relaxed> and you tried with both before the -i too? [14:59:42 CEST] <hadrien> Yeah [14:59:51 CEST] <hadrien> The error i reported was from this one [15:01:05 CEST] <relaxed> tsmuxer is probably the tool to use, then. http://forum.doom9.org/showthread.php?t=168539 [15:02:19 CEST] <hadrien> It was just to test high422 10bit, anyway. But it seems strange for such a common option to fail like this [15:10:37 CEST] <davidpeach> relaxed : I wonder if you could help me please? [15:13:18 CEST] <davidpeach> relaxed : with ffmpeg stream [15:16:08 CEST] <relaxed> davidpeach: I would try streaming flv instead of mp4 [15:16:16 CEST] <ffmpeguser> Hi Guys [15:16:24 CEST] <ffmpeguser> someone can help me [15:16:57 CEST] <hadrien> Ask your question [15:17:42 CEST] <ffmpeguser> when i do an ffmpeg -i input.wmv -vcodec libx264 output.mp4 i get the error Unknown encoder 'libx264' [15:18:02 CEST] <ffmpeguser> ffmpeg version 2.6.git Copyright (c) 2000-2015 the FFmpeg developers built with gcc 4.9.2 (Debian 4.9.2-10) configuration: --enable-gpl --enable-libx264 WARNING: library configuration mismatch avutil configuration: --enable-shared avcodec configuration: --enable-shared avformat configuration: --enable-shared avdevice configuration: --enable-shared avfilter configuration: --enable-shared swscale [15:18:49 CEST] <hadrien> Maybe you don't have libx264 installed? [15:19:05 CEST] <ffmpeguser> thanks hadrien [15:19:23 CEST] <ffmpeguser> how to check if libx264 is installed ? [15:19:52 CEST] <hadrien> Not a debian guy, but something like apt-get install libx264 should install it if it's not [15:20:12 CEST] <ffmpeguser> i did several times [15:20:19 CEST] <ffmpeguser> thus gues its installed [15:20:44 CEST] <relaxed> dpkg -l "libx264*" | grep ^ii [15:21:05 CEST] <ffmpeguser> ii libx264-146:amd64 3:0.146.2538+git121396c-dmo2 amd64 x264 video coding library ii libx264-dev:amd64 3:0.146.2538+git121396c-dmo2 amd64 Development files for libx264 [15:21:59 CEST] <relaxed> ffmpeguser: Might be easier to use my static build, http://johnvansickle.com/ffmpeg/ [15:23:10 CEST] <hadrien> Don't you have to install some libavcodec-extra-something on Debian and derivatives? [15:23:18 CEST] <Eduardo_1> it must appear in: ffmpeg2 -codecs | grep x264 [15:24:22 CEST] <Eduardo_1> sorry without the "2", i have a lot of ffmpegs to test stuff: ffmpeg -codecs | grep x264 [15:25:20 CEST] <theeboat> isnt it ffmpeg -encoders | grep libx264 [15:26:01 CEST] <ffmpeguser> postproc configuration: --prefix=/usr --extra-cflags='-g -O2 -fstack-protector-strong -Wformat -Werror=format-security ' --extra-ldflags='-Wl,-z,relro' --cc='ccache cc' --enable-shared --enable-libmp3lame --enable-gpl --enable-nonfree --enable-libvorbis --enable-pthreads --enable-libfaac --enable-libxvid --enable-postproc --enable-x11grab --enable-libgsm --enable-libtheora --enable-libopencore-amrnb --enable-libopencore-amrwb [15:27:55 CEST] <claz> is there any reason why this command "ffmpeg -i src.mp4 -vf fps=1 frames/%d.jpg" cuts frames at 0.466, 1.466, 2.466 etc? [15:28:06 CEST] <claz> i mean, why the 0.466 offset? can i set it to 0? [15:29:47 CEST] <davidpeach> relaxed: thanks for reply. My issue is, is that I need it to work with html 5, not reliant on flash, which I believe flv is. [15:31:14 CEST] <relaxed> davidpeach: you're trying to stream mp4 while it's encoding? [15:31:58 CEST] <ffmpeguser> looks like the codec is installed properly [15:32:03 CEST] <davidpeach> yer. It is streaming, just a bit choppy [15:32:16 CEST] <davidpeach> relaxed: well, very choppy [15:34:31 CEST] <relaxed> I don't think the mp4 container is a good choice for what you're trying to do. webm is streamable and works with html5 [15:34:33 CEST] <davidpeach> relaxed: any ideas, at all? Or links to look at? Ive been trying to get it to work for a few days now [15:34:50 CEST] <davidpeach> relaxed: webm, mmm [15:35:23 CEST] <davidpeach> relaxed: so i use the -f option to specify container? [15:35:55 CEST] <relaxed> yes, -f webm [15:36:21 CEST] <relaxed> https://trac.ffmpeg.org/wiki/Encode/VP8 [15:38:36 CEST] <relaxed> well, I would try vp9 first https://trac.ffmpeg.org/wiki/Encode/VP9 [15:38:58 CEST] <hadrien> VP9 encoding is slower than the coming of gimp 2.10 [15:39:08 CEST] <hadrien> I wouldn't recommend it for streaming [15:39:34 CEST] <davidpeach> relaxed: is mp4 a no-go? Basically I need it cross browser, and webm needs separate things installing for both safari and ie9 [15:39:49 CEST] <davidpeach> relaxed: I appreciate your help btw [15:47:52 CEST] <relaxed> davidpeach: maybe https://www.ffmpeg.org/ffmpeg-formats.html#hls-1 [15:51:52 CEST] <davidpeach> relaxed: thankyou. How is that implemented please? at the moment I am piping it with '-' at the end for the output, then node js feeds it to browser. Can your suggestion be added easy? [15:51:54 CEST] <relaxed> I don't think there's one choice that will work with everything [15:51:59 CEST] <Eduardo_1> html5 does not work well with streaming. HLS support only exists in mobile browsers, on android 4.x and iOS, on desktop only in safari on MAC OSX [15:52:14 CEST] <JEEBsv> Eduardo_1: stuff that supports MSE has good changes for streaming [15:52:17 CEST] <JEEBsv> with DASH or something similar [15:52:22 CEST] <ffmpeguser> still no succes [15:52:54 CEST] <JEEBsv> I think recent IE, Chrome and Firefox support it and most probably there are flash based solutions for the rest [15:53:20 CEST] <JEEBsv> also with MSE in theory you could implement HLS without the browser itself supportingi t [15:53:56 CEST] <Eduardo_1> yes, but there's still not a wide support [15:54:26 CEST] <davidpeach> this is a tough one [15:54:59 CEST] <Eduardo_1> still using hls is a good option [15:55:22 CEST] <Eduardo_1> you could use a flash based player, with hls support, and in mobile browsers do a fallback to html5 [16:56:16 CEST] <pgunnars> whatsup fellas [16:57:13 CEST] <pgunnars> im trying to insert a custom header into the streams i stream. ffmpeg -headers="" doesnt seem to be a valid call, please to be helped [16:58:28 CEST] <pgunnars> custom http header* [16:58:32 CEST] <pgunnars> to allow cross domain shit [17:48:43 CEST] <pgunnars> can some1 point me to an example of the -headers option actually working? [17:51:45 CEST] <zhanshan> hi [17:51:46 CEST] <zhanshan> how can I change the keyframe-setting (key frames are exactly 10 seconds apart)? [17:52:17 CEST] <zhanshan> my command is: $ ~/bin/ffmpeg -f image2 -pattern_type glob -i '*.jpg' -i '' -pix_fmt yuv420p -c:v libx264 -crf 18 -c:a flac '.mkv' [17:53:59 CEST] <pgunnars> ffmpeg -i input -headers $'Access-Control-Allow-Origin: *\r\n' output, the headers option isnt picked up by anything, any1 know why? [17:54:36 CEST] <Brian> Has anyone manage to compile a static build of ffmpeg on OS X? I am in the middle of figuring it out, but it seems impossible with static libraries missing i.e. fontconfig.a [17:56:28 CEST] <pgunnars> does anyone have any answears or is everyone just lost [17:56:29 CEST] <Eduardo_1> @zhanshan try : -force_key_frames expr:gte$t,n_forced*10$ [17:57:23 CEST] <Brian> or busy [17:57:25 CEST] <Eduardo_1> @pgunnars don't know what are you doing, but the headers Access-Control-Allow-Origin, go in the webserver configuration [17:59:29 CEST] <pgunnars> ? [17:59:34 CEST] <pgunnars> Eduardo_1: please explain further [18:04:11 CEST] <pgunnars> where is that [18:04:12 CEST] <pgunnars> what is love [18:06:26 CEST] <pgunnars> Eduardo_1: I'm working with ffserver, not just ffmpeg. I am sending the headers to a server feed [18:14:59 CEST] <pgunnars> don't leave me hanging bro [18:17:09 CEST] <Eduardo_1> sorry don't know how to use ffmpeg server, i do know that the header Access-Control-Allow-Origim, goes in the configuration of the webserver, in case you're using nginx or apache [18:19:40 CEST] <pgunnars> Eduardo_1: I'm using ffserver [18:19:50 CEST] <pgunnars> :( [18:25:44 CEST] <pgunnars> how is google not coming up with anything [18:26:30 CEST] <Eduardo_1> it should be on the documentation: https://www.ffmpeg.org/ffserver.html [18:27:48 CEST] <pgunnars> except it isnt [18:27:54 CEST] <pgunnars> no mention of http header [18:30:07 CEST] <zhanshan> Eduardo_1 wow, what a special command! it's something normal like -g 3 or something [18:30:25 CEST] <zhanshan> thanks [18:48:43 CEST] <zhanshan> Eduardo_1 does it make sense to change to keyframes? [18:49:02 CEST] <zhanshan> the file will be much bigger probably? [18:50:01 CEST] <Eduardo_1> @zhanshan that option doesn't make every keframe 10 seconds apart, but it makes sure that every 10 seconds there is a keyframe. it's difficult (or impossible) to make every keyframe 10 seconds apart, because codecs needs keyframes on scene change and decoders need keyframes on a steady rate [18:50:36 CEST] <Eduardo_1> it depends on what do you want to do [18:50:57 CEST] <zhanshan> ah maybe I didn't explain right [18:51:10 CEST] <Eduardo_1> keyframes every 2 o 3 seconds ensure that a file is seekeable when playing [18:51:27 CEST] <Eduardo_1> i asumed that you wanted a keyframe every 10 seconds [18:51:32 CEST] <zhanshan> on my command the output was "key frames are exactly 10 seconds apart" [18:51:34 CEST] <Eduardo_1> maybe for segementation [18:51:37 CEST] <zhanshan> but I wanted more I guess [18:51:51 CEST] <zhanshan> there were some playback issues with the sound [18:51:54 CEST] <Eduardo_1> why 10 seconds? [18:52:01 CEST] <zhanshan> I don't know if that's why? [18:52:49 CEST] <zhanshan> yah, when seeking mpv player needed some seconds to synchronize the sound (maybe depening on the keyframe?) [18:52:54 CEST] <Eduardo_1> yes [18:53:05 CEST] <Eduardo_1> more keyframes more "seekeable" [18:53:07 CEST] <zhanshan> it's kinda annoying [18:53:33 CEST] <zhanshan> so why did that happen on the command above and how can I make ffmpeg create keyframes more often? [18:53:45 CEST] <Eduardo_1> usually players seek to the closest keyframe, if there's no keyframe it takes a while to find one [18:53:48 CEST] <zhanshan> which key-frame amount makes sense [18:54:22 CEST] <Eduardo_1> like a said 2 o 3 seconds is a good amount of tiem to have a keyframe [18:55:05 CEST] <Eduardo_1> the codec will insert a keyframe if needed, for example on scene change [18:55:11 CEST] <zhanshan> so within the given command above how can I increase the amount? [18:55:31 CEST] <Eduardo_1> what encoder are you using? [18:55:36 CEST] <Eduardo_1> libx264? [18:55:58 CEST] <zhanshan> yes [18:57:00 CEST] <Eduardo_1> -force_key_frames expr:gte$t,n_forced*10$, 10 is the number of seconds, you can change that [18:57:50 CEST] <zhanshan> alright I'm gonna try [18:57:52 CEST] <Eduardo_1> also you can try: -x264opts "keyint=90" [18:58:22 CEST] <Eduardo_1> keyint, keyframe interval, 90 frames, if your video is about 30 fps, thats about 3 seconds [18:58:35 CEST] <zhanshan> or 50 if using 25 per second and for two second interval [18:58:42 CEST] <zhanshan> yeah [18:58:42 CEST] <Eduardo_1> right [19:36:38 CEST] <zhanshan> Eduardo_1, it's strange, if I seek forward in mpv player while playing the resulting file there's no delay, only if I seek backwards there's a delay of maximum 2s [20:30:27 CEST] <durandal_170> dericed: ping [23:17:01 CEST] <Nolski> Hey all, I have a question. I am using ffmpeg to do a lot of video editing and some of the final product of videos may contain sections that is just text on a background. is there any way for me to render a background of a blank color to create a base video to work on? [23:18:43 CEST] <kepstin-laptop> Nolski, sure, use the "color" filter [23:19:15 CEST] <Nolski> but there is no input video [23:19:18 CEST] <Nolski> kepstin-laptop: [23:19:28 CEST] <kepstin-laptop> color is an input filter, you don't need an input video [23:19:34 CEST] <kepstin-laptop> er, a source filter [23:20:20 CEST] <kepstin-laptop> you can do e.g. 'ffmpeg -filter_complex color=c=white output.mkv' to generate an infinitely long blank white video :) [23:20:36 CEST] <kepstin-laptop> (there are options to set resolution, length, etc.) [23:20:43 CEST] <Nolski> ...This tool is so freaking awesome [23:20:48 CEST] <Nolski> Thanks kepstin-laptop [23:33:39 CEST] <llogan> Nolski: then use drawtext to make your text. it can even read from a file. [00:00:00 CEST] --- Wed Jul 1 2015

1 0