Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

August 2015

1 participants
62 discussions

ffmpeg-devel.log.20150805
by burek 06 Aug '15

06 Aug '15

[00:04:55 CEST] <peloverde> FYI http://vidtechcon.com/ [00:11:49 CEST] <Daemon404> sf is a little far off for me [00:15:53 CEST] <j-b> nevcairiel: if you have 99.9% of the code, and are the only contributor of those 99.9% of the code, actully, you can. [00:17:30 CEST] <philipl> Just down the road [00:17:34 CEST] <cone-801> ffmpeg 03Michael Niedermayer 07master:e5774f28d158: avcodec/dvbsubdec: Do not stop decoding at a invalid depth [01:33:56 CEST] <BBB> peloverde: shall I submit same talk I did at webm summit and at vdd? [01:34:30 CEST] <BBB> I guess thatd be boring [01:36:26 CEST] <peloverde> I think the talk you did for webm summit would be super good for that conf [01:36:38 CEST] <peloverde> in particular the quality vs enc cpu stuff [01:37:47 CEST] <BBB> need a few more slides I guess [01:37:50 CEST] <BBB> its not quite 3 minutes [01:37:52 CEST] <BBB> but also not quite 25 [01:38:00 CEST] <BBB> (its 13) [01:38:17 CEST] <BBB> will they pay for my travel and hotel? [01:40:20 CEST] <peloverde> I'd email them and ask, I know they wanted to attract speakers who weren't locals [01:40:52 CEST] <peloverde> team(a)vidtechcon.com [08:06:04 CEST] <razzledazzle> trying to build ffmpeg for android, stumbled upon something, how can this be fixed? http://pastie.org/private/1nn6anrcoxidfpu3fjtkng [12:05:51 CEST] <durandal_1707> ubitux: what's wrong with high frequencies? [12:06:32 CEST] <ubitux> blinking high peaks [12:07:57 CEST] <ubitux> durandal_1707: i'm trying ./ffplay -f lavfi "amovie=$HOME/samples/pachelbel.mp4,asplit=2[out1],showfreqs=mode=bar[out0]" (http://lucy.pkh.me/pachelbel.mp4) [12:08:07 CEST] <wm4> philipl: so some nvidia cards have hybrid hevc support... is that any useful? [12:08:27 CEST] <ubitux> durandal_1707: btw you have LINEAR for default mode but it's a scale option [12:08:43 CEST] <ubitux> (and you probably want "bar" instead of "line" for default, but nitpick) [12:10:55 CEST] <durandal_1707> ubitux: frequencies are on x axis and db on y axis [12:10:58 CEST] <cone-803> ffmpeg 03Luca Barbato 07master:4fee11ab05fc: png: Be more informative regarding signature errors [12:10:59 CEST] <cone-803> ffmpeg 03Hendrik Leppkes 07master:00b5c1966185: Merge commit '4fee11ab05fc8569ef35c0ce86a60375c903eefb' [12:13:33 CEST] <ubitux> durandal_1707: yes i know, but high frequencies are not supposed to appear with compressed audio, especially not like that [12:14:01 CEST] <ubitux> (they are blinking and shit, it looks like an overread or something) [12:14:29 CEST] <ubitux> btw, the magnitudes are not correct for the first samples [12:15:06 CEST] <ubitux> there is the real part of the last sample in position 1 [12:15:22 CEST] <ubitux> (complex for first & last are assumed to be 0) [12:15:54 CEST] <ubitux> N samples in, N/2+1 duo samples out, so 2 samples to save somewhere with inplace [12:16:00 CEST] <cone-803> ffmpeg 03Luca Barbato 07master:fe026ba96079: drawtext: Drop stray guards [12:16:01 CEST] <cone-803> ffmpeg 03Hendrik Leppkes 07master:4eded225ade3: Merge commit 'fe026ba960790a004adfcff33f44f96b05538e5c' [12:18:58 CEST] <cone-803> ffmpeg 03Luca Barbato 07master:98c9ade9853a: drawtext: Move the strftime expansion in a separate function [12:18:58 CEST] <cone-803> ffmpeg 03Hendrik Leppkes 07master:7e2717ba3c64: Merge commit '98c9ade9853a9c413534ef243174d65f3f7506fa' [12:19:16 CEST] <cone-803> ffmpeg 03Shiz 07master:b197f7832961: configure: Silence error messages when probing compiler [12:19:17 CEST] <cone-803> ffmpeg 03Hendrik Leppkes 07master:45d9d16863de: Merge commit 'b197f78329615893201c0e241d00b71b7c749dbb' [12:21:08 CEST] <nevcairiel> a whole bunch of merges of nothing [12:22:03 CEST] <wm4> heh [12:22:04 CEST] <wm4> nice [12:22:41 CEST] <nevcairiel> the two drawtext things just dont exist in ffmpeg anymore like this, and the configure change was applied independently, so yeah [12:22:41 CEST] <nevcairiel> :D [12:23:23 CEST] <nevcairiel> but now i understand why every commit has to be merged, otherwise the script wont knoe which commits still need merging [12:41:32 CEST] <wbs> well, put another way also, if you do a git merge but not for all commits, all the preceding commits would still be included and appear in the history, not just the one you merged [12:41:53 CEST] <wbs> but doing it one commit at a time gives you better control and less risk of screwing up, and better bisectability [12:46:03 CEST] <nevcairiel> oh yeah skipping commits probably wouldnt work anyway, right [12:46:38 CEST] <wbs> exactly; the way you do it is pretty much equivalent to doing a cherrypick of all commits, one at a time, though, but then you'd be able to skip commits [12:46:57 CEST] <wbs> but as a merge, git history knows what commits aren't part of what you already have and all such [12:47:02 CEST] <nevcairiel> merging can probably track changes better [12:47:12 CEST] <wbs> possibly [12:47:19 CEST] <nevcairiel> doing weird octopus merge strategies etc [12:49:19 CEST] <iive> git is written in python, isn't it? [12:49:26 CEST] <nevcairiel> perl [12:49:31 CEST] <iive> oh... [12:49:32 CEST] <nevcairiel> although some parts are C by now, i think [12:50:26 CEST] <wbs> no, the core is all C [12:50:37 CEST] <wbs> only very highlevel/external things are perl and some other things, and shellscript [12:50:41 CEST] <wbs> but the core sure is very much C [12:50:42 CEST] <wbs> because linus [12:51:08 CEST] <wbs> (wanting to squeeze all the performance out of all trivial operations that he does millions of times per day) [12:52:44 CEST] <nevcairiel> somehow i thought more parts were perl [12:52:50 CEST] <nevcairiel> was it always C from the start? [12:53:35 CEST] <wbs> yes, C and shell script [12:53:41 CEST] <wbs> with some shell scripts parts being migrated to C [12:53:51 CEST] <wbs> perl is used as well but not for anything core [12:54:16 CEST] <iive> oh, this explains it then. [12:54:17 CEST] <wbs> things like rebase -i might have been shellscript/perl [12:57:25 CEST] <wm4> it's all a bit scary [12:57:34 CEST] <wm4> gitk is also a single huge TCL file [12:58:43 CEST] <iive> is that for gui? [12:58:50 CEST] <wm4> yeah [15:04:18 CEST] <durandal_170> ubitux: I use similar code as in showspectrum so I don't get it where is bug [15:07:16 CEST] <ubitux> durandal_170: i see no freq glitches in showspectrum for that same sample [15:07:45 CEST] <ubitux> ./ffplay -f lavfi "amovie=$HOME/samples/pachelbel.mp4,asplit=2[out1],showspectrum=mode=separate:color=intensity:slide=1:scale=cbrt[out0]" [15:07:57 CEST] <ubitux> top of the graph are pretty fine [15:15:51 CEST] <ubitux> what's the point of incrementing yourself the position of writing if you are using strlcatf? [15:15:59 CEST] <ubitux> (re: 4fee11ab05fc8569ef35c0ce86a60375c903eefb) [15:16:04 CEST] <j-b> a1m [15:16:40 CEST] <ubitux> +i*5 and -i*5 looks redundant [15:16:50 CEST] <ubitux> or i'm missing something? [15:20:27 CEST] <cone-803> ffmpeg 03Ronald S. Bultje 07master:22b30f925d0d: vf_psnr: add psnr_avg to stats file. [15:55:58 CEST] <cone-803> ffmpeg 03Michael Niedermayer 07master:500bfbe27ae2: avcodec/hapenc: Remove use of deprecated ff_alloc_packet() [15:55:59 CEST] <cone-803> ffmpeg 03Michael Niedermayer 07master:4ab1f33daf48: avcodec/avcodec: Replace AV_CODEC_FLAG* values by 1 << C style for consistency [15:56:00 CEST] <cone-803> ffmpeg 03Michael Niedermayer 07master:e740659a5d37: avcodec/avcodec: Define CODEC_CAP_* based on AV_CODEC_CAP_* [16:21:10 CEST] <ubitux> does anyone know in what potential situation(s) we end up with more than one nal unit in a h264 stream? [16:21:24 CEST] <ubitux> per packet* [16:22:25 CEST] <cone-803> ffmpeg 03Anton Mitrofanov 07master:8db0f71b49a3: x86inc: warn if XOP integer FMA instruction emulation is impossible [16:27:30 CEST] <kierank> ubitux: ? [16:27:36 CEST] <kierank> multiple slices? [16:28:11 CEST] <ubitux> i'm going to ask very dumb question, bear with me; does it happen only with interlacing? [16:29:01 CEST] <ubitux> i was wondering if with threading it was going to make a nal per thread or something, but apparently not [16:30:52 CEST] <kierank> no it can happen for other reasons [16:31:01 CEST] <kierank> interlacing (field mode PAFF) is one reason [16:32:40 CEST] <ubitux> do you see another reason? [16:33:05 CEST] <ubitux> and the other way around, can you have 1 nal per packet with interlacing? [16:33:48 CEST] <kierank> ubitux: yes multiple slices in a frame [16:33:54 CEST] <kierank> you can have one nal per packet with MBAFF, yes [16:34:58 CEST] <philipl> Every combination is possible! It's so much fun! [16:35:42 CEST] <nevcairiel> note that are also extra NALs like SPS, PPS, AUD, SEI which also occur in packets [16:35:46 CEST] <nevcairiel> not only slices [16:36:00 CEST] <kierank> that too [16:36:12 CEST] <kierank> I was trying to keep it simple... [16:36:14 CEST] <ubitux> within ffmpeg context they end up in extradata, no? [16:36:45 CEST] <nevcairiel> SPS and PPS get copied to extradata, but in a AnnexB stream they are supposed to be repeated regularly [16:37:02 CEST] <nevcairiel> so cutting is possible [16:38:55 CEST] <ubitux> assuming video data, larger segmentation such as with more than 2 nal per packet happens? [16:39:09 CEST] <nevcairiel> Blu-rays have 4 slices [16:39:14 CEST] <nevcairiel> so 4 nals per frame [16:39:15 CEST] <ubitux> (video data i mean ignoring the stream meta mentioned above) [16:39:26 CEST] <ubitux> nevcairiel: what's the purpose of this slicing? [16:39:37 CEST] <nevcairiel> slice threading possibility, i guess [16:39:51 CEST] <ubitux> ok [16:40:03 CEST] <nevcairiel> but the spec asks for 4 slices on 1080p video [16:40:26 CEST] <ubitux> the bluray specs you mean? [16:40:30 CEST] <nevcairiel> yes [16:40:45 CEST] <ubitux> ok, thanks, makes sense [16:40:54 CEST] <kierank> ubitux: error resilience too [16:40:59 CEST] <kierank> so that errors don't propagate along slices [16:41:14 CEST] <ubitux> ok [16:41:34 CEST] <ubitux> the overhead in size of using multiple slices is not too high? [16:41:44 CEST] <kierank> not in a large frame size [16:42:26 CEST] <ubitux> is it possible to cut one slice in multiple nal? [16:42:33 CEST] <ubitux> i mean, can nal segmentation be more arbitrary? [16:43:49 CEST] <ubitux> sorry, maybe i should read the specs by myself instead [16:49:16 CEST] <kierank> I think one slice has to go in one NAL [16:49:55 CEST] <ubitux> ok, thank you [16:53:04 CEST] <philipl> This is what made crystalhd so 'fun' to work with. Decoder consumed the entire bitstream without requiring any parsing on the application side, but then you have no idea if you'll get 1:1, 2:1 or 1:2 output pictures vs input packets [16:53:51 CEST] <kierank> that's arguably the right way to do it [16:54:23 CEST] <kierank> there's tons of weird field weaving stuff in ffh264 [16:54:24 CEST] <nevcairiel> generally its not a big problem, just that our 1:1 avcodec decode API just doesnt handle it [16:54:26 CEST] <kierank> which is fine [16:54:30 CEST] <kierank> yeah [16:56:58 CEST] <nevcairiel> for future extensibility, moving towards a n:m API might be mandatory, but such a big api change will take years [16:57:14 CEST] <philipl> yeah. That's what made it a real struggle. [16:57:35 CEST] <nevcairiel> even existing decoders sometimes do extra buffering due to that API design [16:57:53 CEST] <nevcairiel> and doing interlaced encoding with x265 is practically impossible with the old api [16:58:18 CEST] <philipl> yeah. [16:58:24 CEST] <nevcairiel> ... because the absence of interlaced coding tools in h265 has actually made it more annoying, not less :( [16:58:40 CEST] <philipl> Aren't we supposed to be in the post-interlaced era at this point? [16:58:41 CEST] <ubitux> hey i have other questions for h264; maybe you can redirect me to the appropriate part of the specs though; i'm trying to understand the difference regarding data reuse between a full intra frame and a ref frame (that can be a P frame apparently) [16:58:55 CEST] <nevcairiel> even B can be ref [16:59:03 CEST] <nevcairiel> h264 is flexible like that [16:59:05 CEST] <kierank> ubitux: data reuse? [17:02:06 CEST] <ubitux> kierank: yeah, like i can skip any frame non ref, it won't cause a decoding problem, but if i skip one, it's causing trouble somehow [17:02:23 CEST] <BBB> ref frames depend on each other [17:02:24 CEST] <kierank> there are flags in the NAL which signal whether a frame is skippable [17:02:36 CEST] <BBB> thats what IDR means [17:02:37 CEST] <kierank> iirc [17:02:39 CEST] <BBB> independently decodeable ref [17:03:19 CEST] <kierank> isn't it instantaneous decoder refresh [17:03:38 CEST] <BBB> something like that yes [17:04:08 CEST] <BBB> ubitux: so any ref depends (indirectly) on _all_ previous refs, not just the last ref [17:04:23 CEST] <ubitux> so you can have like 7 successive frames not depending on each other but only on the ref one, which could not be an intra one? [17:04:38 CEST] <nevcairiel> its unlikely, but yes [17:04:50 CEST] <ubitux> in which case, what is re-used from this ref frame? everything, just like intra? [17:05:13 CEST] <nevcairiel> there is no difference, they depend on the reconstructed frame [17:05:23 CEST] <ubitux> ok [17:05:55 CEST] <nevcairiel> so if your ref is broken because it was missing refs, then every following frame will inhereit the problem [17:07:32 CEST] <nevcairiel> are you trying to solve your 240 fps problem by skipping more frames now :d [17:08:50 CEST] <philipl> Are these 240fps files encoded just using a special GOP or do they use SVC? [17:09:11 CEST] <nevcairiel> ordinary h264 fles [17:09:23 CEST] <ubitux> nevcairiel: well, i'm just trying to have more understanding of h264 because i'm probably going to have to write that async code out of ffmpeg [17:09:55 CEST] <ubitux> which is a shame but i need to figure out how all of this work without the current hindrance of the limitation of the sync api [17:10:04 CEST] <ubitux> before i can try something smart in ffmpeg [17:10:12 CEST] <nevcairiel> doesnt iOS come with a decoder you could call [17:10:51 CEST] <ubitux> well, i need vtb api [17:11:03 CEST] <ubitux> the format layering api is too limited for my needs [17:11:39 CEST] <ubitux> avformat is much better; at least i can seek properly [17:13:04 CEST] <ubitux> anyway, i was really happy to be able to use everything in ffmpeg, but unfortunately, it's not fast enough [17:13:24 CEST] <ubitux> so i'll need to mess with the packets themselves and the apple api for now [17:17:53 CEST] <ubitux> btw, why is qp table not exported with h264 but in the other mpeg like codecs it is? [17:24:42 CEST] <Zeranoe> In regards to Michael's resignation email, is there more information about "But even now as the last distributions are preparing to remove Libav". [17:27:23 CEST] <ubitux> Zeranoe: gentoo & debian (+derivatives) were using libav as default provider for the libs*; it changed recently [17:27:47 CEST] <wm4> kierank: I've always wondered, how does the field weaving stuff work? [17:27:58 CEST] <wm4> does it actually decode to separate fields, and then "weave" them? [17:28:10 CEST] <ubitux> git grep FF_QSCALE_TYPE_H264 makes me sad; michaelni, any idea? [17:28:25 CEST] <nevcairiel> wm4: you decode to the same frame and muck with the linesize to put it in the right place, iirc [17:29:06 CEST] <wm4> oh I see [17:29:07 CEST] <wm4> scary [17:29:21 CEST] <wm4> would it have been better if ffmpeg had decided to output fields only? [17:29:38 CEST] <nevcairiel> considering every user API wouild have to weave then [17:29:44 CEST] <nevcairiel> nothing accepts field input =p [17:29:58 CEST] <wm4> but easier for deinterlacer etc. to handle [17:30:15 CEST] <wm4> and weaved output is ugly as sin [17:30:33 CEST] <wm4> most video APIs actually allow you to stretch the output [17:30:42 CEST] <wm4> so doing what bob does these days would have been trivial [17:30:54 CEST] <Zeranoe> ubitux: Who still uses Libav above FFmpeg? [17:31:03 CEST] <ubitux> "above"? [17:31:17 CEST] <Zeranoe> ubitux: default, instead of [17:31:37 CEST] <Mavrik> Ubuntu LTE [17:31:40 CEST] <Mavrik> *LTS [17:31:46 CEST] <Mavrik> Until 16.04 is out [17:32:14 CEST] <ubitux> Zeranoe: i don't know any, but probably a bunch of debian derivatives [17:32:17 CEST] <Mavrik> They're one of the largest install bases, pretty much everyone else defaults to ffmpeg [17:32:29 CEST] <ubitux> Zeranoe: also, it didn't switch in current debian stable [17:32:37 CEST] <Zeranoe> Since that ML post, has there been any progress in merging the two projects back together [17:32:55 CEST] <ubitux> no, libav didn't say much since then [17:33:24 CEST] <ubitux> we're (maybe only me) still waiting for a list of expectations etc [17:34:03 CEST] <Zeranoe> Is it the desire of most FFmpeg developers to merge back together? [17:34:35 CEST] <ubitux> Zeranoe: see http://ffmpeg.org/pipermail/ffmpeg-devel/2015-August/176556.html for the thread concerning ffmpeg devs opinions [17:35:12 CEST] <ubitux> many still didn't answer though [17:51:00 CEST] <ubitux> michaelni: ok never mind, i'll send a patch to do the export soon [18:04:54 CEST] <lglinskih> kierank: how can I determine, if codec is floating-point? [18:06:35 CEST] <kierank> Bitexact flag [18:06:48 CEST] <kierank> (On my phone now so can't reply in full) [18:11:48 CEST] <lglinskih> oh, wrong verb, sorry=/ how can I recognize that some codec is floating-point? [18:25:45 CEST] <wm4> lglinskih: bitexact is still the right answer [18:26:13 CEST] <wm4> a decoder which uses floats can output floats, but doesn't have to [18:26:41 CEST] <wm4> so whether the output of a decoder for the same input is the same on all platforms and CPUs depends on the bitexact flag [18:27:08 CEST] <lglinskih> cool! [18:28:03 CEST] <nevcairiel> dont think decoders are flagged like that, are they [18:28:41 CEST] <wm4> right, you can request it, but the codecs don't report it, I guess [18:28:51 CEST] <wm4> I have no idea [18:29:16 CEST] <wm4> some codecs are flagged as lossless, but it's not the same of course [18:31:29 CEST] <lglinskih> but should all codecs act like bitexact if this flag is set? [18:32:09 CEST] <wm4> probably not, some codecs likely miss support, but I don't know [18:39:28 CEST] <lglinskih> for what situations should I set the value of idct_algo? [18:39:59 CEST] <lglinskih> can it helps me to get fixed output on different platforms for more codecs? [18:45:44 CEST] <kierank> iirc it should be posible to set it to an integer idct [18:58:11 CEST] <lglinskih> sooooooooo...I don't know what to do) now I can compare decoder's output with small deviation, but don't know for what codecs I should test it. [18:59:36 CEST] <lglinskih> and it looks like comparing crcs is more useful as a test [19:01:05 CEST] <lglinskih> so should I add fate-tests using api-decode-test with bitexact param for...almost all codecs? [19:01:51 CEST] <kierank> for AV_CODEC_FLAG_BITEXACT you can use crc [19:01:55 CEST] <kierank> for others you need to use deviation [19:02:29 CEST] <kierank> but yes [19:02:40 CEST] <kierank> I'm a bit confused too [19:03:25 CEST] <lglinskih> =) [19:03:46 CEST] <kierank> give me 5 mins and i'll see how fate does bitexactness [19:03:50 CEST] <kierank> might well just be hardcoded [19:04:09 CEST] <lglinskih> ) [19:05:23 CEST] <philipl> Are there any h.264 FMO/ASO samples around? I didn't see anything obvious in the conformance sample set we have [19:06:03 CEST] <nevcairiel> dont think i have ever seen FMO in action [19:06:18 CEST] <kierank> i've seen one in the real-world [19:06:24 CEST] <kierank> but it's a baseline only feature so meh [19:07:03 CEST] <philipl> I wanted to see if the new nvidia drivers really handle it. I assume they do because they made such a big deal about only claiming baseline support if they did [19:07:18 CEST] <nevcairiel> does avcodec even do it [19:08:37 CEST] <philipl> Hmm. There was a thread about it in 2010. [19:08:56 CEST] <kierank> most people use constrained baseline [19:08:59 CEST] <philipl> Indeed. [19:09:01 CEST] <kierank> which doesn't have all those weird features [19:09:04 CEST] <kierank> ah ok [19:09:06 CEST] <philipl> This is pure curiosity. [19:09:10 CEST] <kierank> they actually mean baseline baseline [19:09:12 CEST] <kierank> wow [19:09:24 CEST] <philipl> Yeah. [19:20:25 CEST] <durandal_170> there are so many vamp visualizations plugins [19:27:10 CEST] <kierank> lglinskih: I think they're just hardcoded so you could just reuse the fate tests but decode them using the api [19:29:36 CEST] <wm4> maybe we could add new API for this? [19:31:40 CEST] <lglinskih> kierank: you mean all tests in fate that uses framecrc, right? [19:32:00 CEST] <kierank> I mean fate tests that are not bitexact [19:32:05 CEST] <kierank> I thought perhaps fate could query the codec [19:32:21 CEST] <kierank> but it just has the error hardcoded in the test [19:53:08 CEST] <wm4> why are the videotoolbox/vda decoders some freaky mixture of hwaccel and full bitstream deocders? I don't quite get it [20:56:12 CEST] <wm4> ignore my lavc patch on the ML [20:56:35 CEST] <BBB> does anyone know why https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-trac/ Archives link refers to avcodec.org? [21:11:21 CEST] <cone-803> ffmpeg 03Marton Balint 07master:b1f78632c681: ffplay: do not block audio thread on WIN32 [21:13:41 CEST] <Compn> BBB : humm, i think for like a day or two during the 2011 server move we had avcodec.org registered in case we didnt have a domain... [21:14:00 CEST] <Compn> so its possible that was used in the config of the ffmpeg-trac mailing list [21:14:13 CEST] <Compn> probably ask one of the ml admins or root to fix that [21:14:45 CEST] <Compn> avcodec.org still directs to ffmpeg.org [22:00:41 CEST] <wm4> should I push that matroskaenc patch? since I apparently reviewed it [22:03:19 CEST] <jamrial> yeah [22:37:11 CEST] <cone-803> ffmpeg 03Sasi Inguva 07master:31852540d4fb: libavformat/matroska: Write stream durations in metadata, in the format of mkvmerge. [23:04:45 CEST] <rtogni> BBB, Compn list url fixed [23:04:52 CEST] <BBB> ty very much [23:17:55 CEST] <cone-803> ffmpeg 03hSÇ 07master:71575d98f5af: avcodec: loongson optimized h264pred with mmi v2 [23:23:25 CEST] <cone-803> ffmpeg 03Henrik Gramner 07master:5e8e121fccc2: checkasm: Remove unnecessary include [00:00:00 CEST] --- Thu Aug 6 2015

1 0

ffmpeg.log.20150805
by burek 06 Aug '15

06 Aug '15

[00:00:21 CEST] <kyleogrg> other words, 33% of *640* is 211. [00:01:41 CEST] <kyleogrg> and to do this, I can do scale=iw*sar:ih, then scale=iw*0.33? [00:12:31 CEST] <PlanC> I'm trying to experiment with a new thing [00:12:40 CEST] <kyleogrg> it works if i do 50%, but not 33%. probably a mod 2 issue or something. [00:12:49 CEST] <PlanC> We have a website which has a bunch of demo videos that get a decent amount of downloads [00:13:00 CEST] <PlanC> Users can download these in different formats with the help of FFMPEG [00:13:43 CEST] <PlanC> But the downside is that they have to wait for the video to be converted to 100% before they can start downloading [00:14:15 CEST] <PlanC> I got the idea that I perhaps could convert chunks at a time and serve it to the user [00:14:50 CEST] <PlanC> Does FFMPEG have a feature for this which would allow me to convert one chunk at a time and serve it to the user (I'll serve it with PHP but that's kind of irrelevant) [00:15:21 CEST] <c_14> use the segment muxer? [00:15:22 CEST] <PlanC> another option would be to use concatenate and have FFMPEG convert let's say 1 second at a time [00:15:41 CEST] <PlanC> c_14: what does the segment muxer do? [00:16:03 CEST] <c_14> cuts the video up into n x length segments [00:16:22 CEST] <c_14> https://ffmpeg.org/ffmpeg-formats.html#segment_002c-stream_005fsegment_002c… [00:16:46 CEST] <PlanC> was reading that just now [00:16:56 CEST] <PlanC> so I can basically stream the conversion [00:17:32 CEST] <PlanC> but does this update a file or does it output the chunks right in the shell? [00:18:09 CEST] <c_14> This outputs n x-length files. [00:18:16 CEST] <c_14> It sounds to me an awful lot like you want HLS though. [00:18:45 CEST] <llogan> kyleogrg: use -2 in w [00:19:08 CEST] <PlanC> HLS? [00:19:11 CEST] <PlanC> what's that? [00:19:39 CEST] <c_14> https://en.wikipedia.org/wiki/HTTP_Live_Streaming [00:20:47 CEST] <PlanC> no I'll be sending the file mime type headers with PHP to have the browser force-download the file instead of playing it [00:21:08 CEST] <PlanC> from there the chunks will be sent to the user [00:21:42 CEST] <PlanC> now I'm trying to figure out how I can progressively get each chunk from FFMPEG using the segment muxer [00:23:57 CEST] <c_14> You could output to a format that's streamable. [00:23:59 CEST] <kyleogrg> llogan: hmm, can you give me an example? [00:24:04 CEST] <c_14> So you could send it out while it's encoding. [00:25:41 CEST] <llogan> kyleogrg: scale=-2:ih/3 [00:25:46 CEST] <PlanC> almost all formats are streamable though, right? [00:25:59 CEST] <c_14> mp4 isn't [00:26:12 CEST] <PlanC> I'll be streaming mp4, avi, mp3 (sound effects), etc [00:26:37 CEST] <PlanC> actually they don't need to be streamable [00:26:46 CEST] <PlanC> because the user will play it after it's downloaded [00:27:11 CEST] <PlanC> I'm just trying to get the download to start sooner so that the user doesn't have to wait until the conversion reaches 100% [00:27:40 CEST] <PlanC> my goal is to have the user start the download by getting the output from 1% to 100% [00:27:57 CEST] <kyleogrg> llogan: what I have now is "scale=iw*sar:ih,scale=iw*0.5". (0.5 because 0.33 didn't work.) i'm not sure how to use your suggestion [00:28:44 CEST] <llogan> scale=iw*sar:ih,scale=-2:ih/3 [00:29:34 CEST] <c_14> PlanC: And the user is supposed to use a media player to view the stream or download it to file with something like curl/wget [00:29:37 CEST] <c_14> ? [00:31:31 CEST] <PlanC> c_14: the user will download it with their regular browser, save it to their PC and play it [00:32:00 CEST] <kyleogrg> llogan: that works. thanks a lot. [00:33:04 CEST] <c_14> PlanC: Because the thing is, you can't just encode (most formats) to individual files and then concatenate them willy-nilly so that it looks like only one file to the client. [00:35:35 CEST] <kyleogrg> since I am encoding with super-low bitrates, would it make sense to also shrink video resolution? [00:36:57 CEST] <KarlFran1> I think it does. [00:37:28 CEST] <KarlFran1> If you have a 1080 video with a very low bitrate you are defeating the point of high resolution. [00:37:55 CEST] <KarlFran1> And also getting a worse bitrate per pixel than using a low resolution for the same video bitrate :-) [00:41:31 CEST] <kyleogrg> right. i guess i will estimate what the res should be given the bitrate [00:42:30 CEST] <KarlFran1> You can always calculate the bitrate per pixel when you are stimating. I don't know if it is technichaly correct, but results don't look bad. [00:43:14 CEST] <KarlFran1> Say that if a video with X bitrate on 720 looks crappy, a 1080 video with resolution X x 2.25 will look also crappy. [00:45:31 CEST] <kyleogrg> yeah, i was wondering about that. [00:46:22 CEST] <kyleogrg> what if it's 92k bitrate for a 640x480 video at 14.985p? [00:47:50 CEST] <KarlFran1> wow, that is low fps. [00:48:21 CEST] <kyleogrg> yup. 29.97/2 [00:49:00 CEST] <KarlFran1> You are likely to see compression artifacts in that. [00:49:11 CEST] <KarlFran1> Just try it and tell us the results. [00:49:12 CEST] <PlanC> c_14: I'll have to read more about this before I can even get a basic understanding of what I'm trying to do [00:49:15 CEST] <PlanC> thanks for your help [00:51:47 CEST] <kyleogrg> KarlFran1: i've tried it already, and there are artifacts. i'm just experimenting with super-low bitrates, seeing how much video proxies i can cram on a thumb drive. [00:52:27 CEST] <KarlFran1> I think that h.264 starts being not-so-good at 500k for 720. [00:52:47 CEST] <KarlFran1> You can do the math for the resolutions you want. [00:53:30 CEST] Action: KarlFran1 usually uses VP8. [00:54:33 CEST] <kyleogrg> i'm using x265 [04:48:45 CEST] <k_sze> Does anybody know of an easy-to-use ffmpeg binding for .NET that supports seeking? I think so far I haven't seen any binding that is both easy to use and supports seeking. [05:47:06 CEST] <vee> if i am making a slideshow from a series of pictures using -i "format string" - is there a method of verbosity that outputs the current picture it is processing (which causes a swscaler warning/error)? [10:11:05 CEST] <hassoon> what's with this red notification i get whenever i open a media file with mpv, in debian '[ffmpeg/audio] aac: element type mismatch 1 != 0' [10:11:23 CEST] <hassoon> https://i.imgur.com/d0Mf7wR.png [10:42:41 CEST] <lilibox_> hi [10:43:38 CEST] <lilibox_> does ffmpeg's development follow the latest cameras format? ARRI/Red/Sony? [11:08:39 CEST] <JEEB> lilibox_: they should use standard stuff, and if they don't someone gives samples and support might be added depending on how disgusting the hacks can be [11:19:57 CEST] <santhoshsd> how do I embed a closed caption file (scc) into a video file ? [11:33:38 CEST] <whald> hi! i'm currently fighting with an IP camera producing a pretty crappy MJPEG stream. i'm using a command like "ffmpeg -f mjpeg -i "<URL>" -c:v libx264 ... -f mpegts udp://239.192.23.23:1234" to convert it to an multicast stream. [11:34:38 CEST] <whald> this kind-of works, but the camera does only produce ~2fps, which, because of buffering on playback side, introduces huge latencies [11:35:48 CEST] <whald> i've played around with the "-r" and "-vf 'fps'" options to get a 25fps stream (duplicating frames as necessary), but it seems to have no effect. any clue what i'm missing? [11:36:54 CEST] <whald> i.e. inserting a "-vf 'fps=fps=25'" right after the "-i" has no effect, but from the documentation i assume it should? [12:53:44 CEST] <sco_> greetings, I'm compiling ffmpeg on nvidiaa tegra tk1. After satisfying all of the .configure eroors, I'm now getting a make error: "bad instruction 'emm'. can anyone help me? [12:53:56 CEST] <sco_> emms [12:58:13 CEST] <spaam> maybe if you show us the configure line you used. [12:58:34 CEST] <sco_> 1 sec .... [12:58:56 CEST] <spaam> it will be easier to help you if you show us that :) then someone might be able to help you with it :D [12:59:18 CEST] <sco_> have to reboot my system. Will send the config in a minue .... [12:59:38 CEST] <iive> sco_: "emms" is mmx instruction, aka x86 [12:59:59 CEST] <sco_> I'm not use 32 bit [13:00:04 CEST] <sco_> using [13:01:17 CEST] <sco_> still booting zzzzzzzzzzzzzzzz [13:03:21 CEST] <sco_> ./configure --prefix=/usr --bindir=/usr/bin --datadir=/usr/share/ffmpeg --incdir=/usr/include/ffmpeg --libdir=/usr/lib64 --mandir=/usr/share/man --arch=x86_64 --optflags='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' --enable-bzlib --disable-crystalhd --enable-frei0r --enable-libass --enable-libcdio --enable-libcelt --enable-libdc1394 --disable-indev=jack --enable-libfreetype --enable- [13:03:22 CEST] <sco_> libmp3lame --enable-openal --enable-libopencv --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-libv4l2 --enable-libvpx --enable-libx264 --enable-libxvid --enable-x11grab --enable-avfilter --enable-postproc --enable-pthreads --disable-static --enable-shared --enable-gpl --disable-debug --disable-stripping --shlibdir=/usr/lib64 --enable-runtime-cpudetect --enable- [13:03:23 CEST] <sco_> nonfree --enable-gpl --enable-version3 --enable-libbluray --enable-libmp3lame --enable-libopenjpeg --enable-libfaac --enable-libfdk-aac --enable-libwebp --enable-opencl --enable-x11grab --enable-opengl --cpu=native --enable-nvenc [13:03:31 CEST] <sco_> sorry for the long post [13:03:47 CEST] <sco_> didnt know it would be more than 3 lines [13:06:43 CEST] <spaam> sco_: are you using that line to compile ffmpeg on your nvidia tegra tk1? [13:07:42 CEST] <spaam> sco_: it looks like you trying to use the same configure line that you have on your x86 64bit computer [13:08:18 CEST] <spaam> sco_: last time i checked nvidia tegra tk1 have an ARM cpu and not x86 one [13:09:08 CEST] <sco_> yes [13:09:29 CEST] <sco_> you are right. My mistake. What should I change [13:09:32 CEST] <sco_> ? [13:09:42 CEST] <sco_> arch [13:09:47 CEST] <sco_> i see. [13:09:52 CEST] <sco_> What else? [13:10:07 CEST] <spaam> libdir maybe or just remove it [13:10:37 CEST] <chungy> you shouldn't need to pass most of those options to configure on either arch [13:10:52 CEST] <sco_> I c. I didnt take note. [13:10:54 CEST] <spaam> that too :) [13:11:56 CEST] <sco_> ok I removed all that nonsense. I'll recomile and see what else I messed up. :-) [13:24:13 CEST] <sco_> http://paste.opensuse.org/39568055 [13:24:20 CEST] <sco_> more errors [13:31:40 CEST] <spaam> configure line ? [13:34:34 CEST] <sco_> 1 sec ... [13:36:55 CEST] <sco_> http://paste.opensuse.org/37500319 [13:56:45 CEST] <yaron> hey guys how do i create overlay between 2 videos and not keeping them in the background ? [13:57:21 CEST] <yaron> something like overlay=shortest=1:eof_action=pass .. but i want to pass to next vid and not for the main blank [16:01:47 CEST] <whald> just in case anyone cares about my "-r" and "-vf fps" having no effect problems I asked a few hours ago: it was caused by using a what appears to be broken git checkout from about a month ago. i just re-compiled a current checkout and everything works as expected. [16:02:12 CEST] <whald> *sigh* [16:06:18 CEST] <Anaphaxeton> hello! [16:07:14 CEST] <Anaphaxeton> i wanted to ask, can ffmpeg add srt subtitles in a file having converted them to vobsub first? [16:08:12 CEST] <KarlFranz> I use mkvmerge for that. [16:08:27 CEST] <KarlFranz> I think ffmpeg can, but I would have to look at it. [16:08:41 CEST] <Anaphaxeton> i use that tool but i ve never seen that feature :-/ [16:08:53 CEST] <KarlFranz> Oh, you mean you want to do the vosub -> srt conversion with ffmpeg... I think you are out of luck. [16:09:09 CEST] <KarlFranz> You will need tools with OCR support which, as far as I know, don't work great. [16:09:11 CEST] <Anaphaxeton> yes [16:09:24 CEST] <Anaphaxeton> bur mkvmerge will still do it? [16:09:31 CEST] <Anaphaxeton> but* [16:09:46 CEST] <KarlFranz> mkvmerge will merge any subtitle stream, but won't do the conversion. [16:09:58 CEST] <Anaphaxeton> oh [16:09:58 CEST] <KarlFranz> Unless you have a very good reason, I would not convert the subtitle stream. [16:10:06 CEST] <KarlFranz> It is too much hassle for saving 3 Mb. [16:10:12 CEST] <Anaphaxeton> i do. a crappy TV set [16:10:26 CEST] <KarlFranz> Your TV set cannot display vosubs? [16:10:37 CEST] <Anaphaxeton> i dont know yet [16:10:39 CEST] <KarlFranz> vosubs are very standard. [16:10:48 CEST] <KarlFranz> It is what DVDs have inside. [16:10:49 CEST] <Anaphaxeton> as i said i fave srts [16:10:57 CEST] <Anaphaxeton> yes yes [16:12:15 CEST] <Anaphaxeton> for example i watch a movie with subs on my pc. the glyphs are so beautifully rendered by vlc... and i want that on my tv too :( [16:12:51 CEST] <Anaphaxeton> oops no i meant subrip -> vobsub [16:13:08 CEST] <Anaphaxeton> no OCR needed just proper rendering [16:14:21 CEST] <KarlFranz> Then I suppose it will be easier, but that is nothing I have ever done. [16:14:32 CEST] <KarlFranz> ffmpeg can hardburn if you really need it. [16:14:39 CEST] <KarlFranz> I don't like hardburning myself. [16:15:08 CEST] <klaxa|work> nobody should :P [16:15:45 CEST] <Anaphaxeton> indeed [16:17:03 CEST] <klaxa|work> my (slightly outdated) ffmpeg on my server says it supports encoding dvd_subtitle (see ffmpeg -codecs to check with your version) [16:17:13 CEST] <klaxa|work> that might be what you want [16:17:17 CEST] <Anaphaxeton> mine too [16:17:34 CEST] <Anaphaxeton> i am expploring it now [16:19:49 CEST] <whald> ehm, I have to correct myself: a current git checkout does *not* fix the problem, but with version 2.5.3 it works as expected. should I file a bug report? [16:46:06 CEST] <chungy> whald: absolutely. that's a regression [16:46:13 CEST] <chungy> Should also see how the latest 2.7 release behaves [16:54:12 CEST] <nyuszika7h> I'm having trouble trying to convert hdmv_pgs_subtitle to ASS / SRT [16:55:25 CEST] <nyuszika7h> http://dpaste.com/09NWD2Y [16:57:05 CEST] <nyuszika7h> and if I try to convert to SRT, "Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height" [16:58:18 CEST] <nyuszika7h> oh they are image subs. nvm [17:05:56 CEST] <chungy> yea, you'll likely want some other OCR program to convert them to text. [17:06:23 CEST] <chungy> depending on the sub, it can either be fairly quick and easy, or slow and difficult :P [17:07:36 CEST] <andrew1> Hello! I am interested in using the audio filter 'dynaudnorm' which I see is listed in the FFmpeg Filters Documentation page at ffmpeg.org. I cannot seem to invoke the filter with any success, however. Running a simple test on the command line, e.g. 'ffmpeg -i in.wav dynaudnorm out_test.wav' returns an error indicating that FFmpeg cannot find a filter by that name. I just recently built the most recent stable [17:07:39 CEST] <andrew1> version of FFmpeg on an Ubuntu LTS 14.40 system (2.7.2) - no dice. Any help would be appreciated! [17:08:04 CEST] <c_14> AFAIK that filter is only in recent git head [17:08:12 CEST] <c_14> try it with a static build [17:08:13 CEST] <c_14> http://johnvansickle.com/ffmpeg/ [17:33:19 CEST] <sco_> that's good then [17:38:59 CEST] <andrew1> c_14 Thanks so much, that is a great resource! Will report back with my results. [17:56:40 CEST] <edoceo> ffmpeg really fails on this timing, shows the video is 200+ hours long [17:56:42 CEST] <edoceo> http://edoceo.io/paste?p=WWBa9V [18:11:44 CEST] <jdp> hey all. i'm using ffmpeg to extract sections of large mp4 files stored remotely (say on s3), using the seek flags. so on a multiple-hour movie i'm only grabbing a couple minutes toward the middle [18:12:51 CEST] <jdp> invoked like `ffmpeg -i https://domain/folder/video -ss ... -d ... output.mp4` or somesuch [18:13:30 CEST] <jdp> it seems like ffmpeg downloads the whole movie up until the seek time, so there is the network overhead before transcoding starts [18:13:44 CEST] <klaxa> move -ss before -i [18:13:47 CEST] <klaxa> and see if that helps [18:14:00 CEST] <klaxa> also see: https://trac.ffmpeg.org/wiki/Seeking [18:14:43 CEST] <jdp> right on i'll check it out. thanks [18:14:56 CEST] <klaxa> if you use -ss after -i it is doing accurate seeking and needs to decode every frame until the time specified by -ss [18:23:09 CEST] <jdp> klaxa: that did it. thanks! [18:23:22 CEST] <kyleogrg> hi [18:23:23 CEST] <kyleogrg> In ffmpeg, is there a difference between actual resolution and display resolution? So let's say I encode a video a 320x240 but want it to be resized (in VLC for example) to 640x480 when it is played. [18:23:50 CEST] <kyleogrg> Is this possible, and is there even any reason to do this? [18:28:44 CEST] <jdp> a follow up question: is there a way to re-scale the progress reporting? i see progress climb from 0% to ~0.7% when doing the input seek and taking a couple minutes from the movie, and then the command completes [18:29:03 CEST] <jdp> is it possible to rescale so it goes from 0 to 100%? [19:08:38 CEST] <JEEB> kyleogrg: usually stuff like display res is just used as a display aspect ratio kind of thing in those formats that have such [19:08:46 CEST] <JEEB> (like matroska, IIRC) [19:09:11 CEST] <JEEB> how big the actual shown size is is completely up to the player [19:35:19 CEST] <kyleogrg> JEEB: ok. but i mean, if I make a 640x480 mkv, VLC will display at that size, right? why would it change it? [19:35:55 CEST] <kyleogrg> I know you can change display *aspect ratio*, so VLC may change the width, for example -- ie, change 720x480 to 640x480... [19:35:58 CEST] <kyleogrg> brb [19:38:21 CEST] <JEEB> kyleogrg: there's a whole lot of reasons why a player would change or not change the size of your video when played back. including user settings etc. and if the file has a display width/height that is one of the things used for changing that size. [19:38:46 CEST] <JEEB> of course, even if a container does have a display width/height kind of thing - that is usually used for aspect ratio purposes in the player [19:39:03 CEST] <JEEB> even if the field is "diplay width" or "display height" [19:39:05 CEST] <kyleogrg> ok [19:39:31 CEST] <JEEB> and what I meant is that for the longest time you set the display aspect ratio in matroska by setting the display resolution :P [19:39:37 CEST] <kyleogrg> yesterday i was talking about encoding super low bitrate videos, so we were discussing the idea of shrinking video res. [19:39:55 CEST] <JEEB> only recently did matroska get a way of setting a display aspect ratio [19:40:01 CEST] <kyleogrg> now, what if the bitrate is so low that the res needs to be tiny? [19:40:25 CEST] <JEEB> (which I think just changes the meaning of the display width/height fields) [19:40:30 CEST] <kyleogrg> what if it needs to be encoded at 320x240, but i want it to be displayed at 640x480? [19:40:33 CEST] <kyleogrg> ok [19:40:46 CEST] <JEEB> pretty much "tough luck" [19:40:50 CEST] <kyleogrg> yeah [19:40:57 CEST] <JEEB> because while formats like matroska let you set a display res [19:41:02 CEST] <kyleogrg> basically the conclusion i came up with [19:41:08 CEST] <JEEB> that is usually interpreted as the aspect ratio [19:41:18 CEST] <JEEB> not as the size the player should default to [19:41:19 CEST] <kyleogrg> i see... [19:41:59 CEST] <kyleogrg> all right. thanks [19:42:01 CEST] <kyleogrg> brb [23:06:20 CEST] <sine0> c_14: are you here [23:33:57 CEST] <ploopkazoo> I'm trying "ffmpeg -i file.mkv out.ogg" but it's transcoding the video too, how can I get it to ignore video and only transcode audio? [23:34:20 CEST] <ploopkazoo> (ogg intended to be vorbis obviously) [23:36:27 CEST] <grepper> ploopkazoo: -vn will ignore video [23:37:15 CEST] <ploopkazoo> grepper: thanks [00:00:00 CEST] --- Thu Aug 6 2015

1 0

ffmpeg-devel.log.20150804
by burek 05 Aug '15

05 Aug '15

[00:02:15 CEST] <philipl> wm4: I would just drop it. [00:02:30 CEST] <philipl> In the mpv case, the user who refuses to upgrade can disable the hwdec in configuration [00:02:44 CEST] <philipl> By the time 2.8 is released, the driver will have been out for a while. [00:02:54 CEST] <philipl> Before then, you're expected to know how to take care of yourself [00:03:49 CEST] <philipl> Worst case you can do a version check through vdpau but that will fail at a later stage and make the fallback hard to do gracefully. [00:06:22 CEST] <wm4> well, mpv has hw decoding disabled by default, but other software might not be so conservative [00:06:28 CEST] <wm4> though I don't remember what vlc does [00:06:46 CEST] <j-b> disabled by default [00:06:50 CEST] <j-b> it's too broken [00:07:23 CEST] <j-b> The likelyhood of having correct drivers, correct vdpau version, correct version of libavcodec, corect fork is too small [00:08:53 CEST] <philipl> That was my impression of most players. [00:09:09 CEST] <philipl> Kodi defaults vdpau to on but I don't know how much internal version checking they do. [00:12:51 CEST] <wm4> j-b: and on windows? [00:12:53 CEST] <wm4> or osx [00:13:01 CEST] <wm4> aka systems where hw decoding actually works [00:17:28 CEST] <j-b> wm4: Windows, no, but we're thinking about it [00:17:43 CEST] <j-b> wm4: iOS and Android, will be defaulted to true, though. [00:18:26 CEST] <wm4> not like there's a choice [00:19:55 CEST] <kierank> does cpu decoding really make much of a difference on mobile, say compared to the screen [00:23:32 CEST] <philipl> My personal experience is that it does. [00:23:58 CEST] <j-b> kierank: yes. significantly [00:23:59 CEST] <philipl> You can feel the temperature difference in your hand - never mind that it won't decode in realtime for high resolution/bitrate anyway. [00:24:18 CEST] <j-b> 4K HEVC on mobile is not hard to do those days [00:24:32 CEST] <philipl> j-b: you mean in hardware, I assume. [00:24:45 CEST] <philipl> I know my desktop won't software decode 4K HEVC smoothly :-) [02:46:31 CEST] <llogan> do we need more FATE machines? perhaps some/any of the proposed donated servers could be used for FATE stuff. [03:45:33 CEST] <Compn> llogan : better question is who is now maintaining fate machines and servers ? [03:45:52 CEST] <Compn> the roots i've seen are mostly busy (reimar, beastd) [03:46:03 CEST] <Compn> i cant even name the other roots because they arent here [03:46:04 CEST] <Compn> :P [03:46:24 CEST] <Compn> michaelni was doing too much [03:46:30 CEST] <Compn> maintaining a fleet of fate machines [04:25:35 CEST] <cone-361> ffmpeg 03Michael Niedermayer 07master:d903b62750b3: avcodec/internal: improve min_size documentation for ff_alloc_packet2() [04:25:35 CEST] <cone-361> ffmpeg 03Michael Niedermayer 07master:e322b7061f87: avcodec/dcaenc: clear bitstream end [05:08:52 CEST] <llogan> finally, spam for "h.265" chinese cameras. what took them so long? [05:09:06 CEST] <michaelni> Compn, the fate boxes need relatively little work, also we have some tickets related to fate: https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&keywor… [05:09:45 CEST] <michaelni> but nothing of that is high importance or such [05:10:17 CEST] Action: michaelni falls asleep [05:44:14 CEST] <philipl> oooo. hi444pp was enabled in the new driver. [06:53:39 CEST] <philipl> whoops. The high444p decoder is enabled but there's no support for 444 video surfaces. *sigh* [07:13:06 CEST] <rcombs> philipl: driver for? [07:33:44 CEST] <philipl> nvidia linux driver [09:17:10 CEST] <wm4> philipl: so it decodes to 420? [10:12:14 CEST] <ubitux> is it possible to return no frame in a hwaccel to wait for another roundtrip (more packets)? (still trying to figure out how to async in vtb) [10:12:44 CEST] <nevcairiel> not in a hwaccel [10:12:54 CEST] <nevcairiel> its expected to decode the slice its given and nothing else [10:13:17 CEST] <nevcairiel> you would need a seperate decoder for that [10:16:14 CEST] <ubitux> then stupid question; what's the downside of a decoder over an hwaccel? [10:16:44 CEST] <nevcairiel> that depends how much the API in question does for you [10:17:08 CEST] <nevcairiel> for one all these extra decoders usually dont export the same amount of metadata as the h264 decoder [10:17:13 CEST] <nevcairiel> if any at all [10:17:34 CEST] <nevcairiel> and of course the api needs to offer full bitstream parsing, frame re-ordering and whatnot [10:17:39 CEST] <nevcairiel> things that the hwaccel doesnt use [10:19:57 CEST] <ubitux> mmh ok [10:21:54 CEST] <nevcairiel> its just generally a lot more code [10:22:04 CEST] <nevcairiel> so unless there is a clear advantage, hwaccel is favorable [10:22:31 CEST] <nevcairiel> and some APIs, like VDPAU, VAAPI and DXVA2, dont allow anything else anyway [10:23:09 CEST] <ubitux> ok [10:23:27 CEST] <ubitux> i'm still pretty confused on how i'm going to achieve a decent speed in the current state [11:38:15 CEST] <wm4> michaelni: how do I reproduce your benchmark? [11:49:31 CEST] <michaelni> wm4, assuming iam copy and pasting the right ones: time ./ffmpeg -threads 1 -i matrixbench_mpeg2.mpg -vcodec huffyuv -threads 1 -f null - AND time ./ffmpeg -threads 1 -i matrixbench_mpeg2.mpg -vcodec rawvideo -threads 1 -f null - [11:50:10 CEST] <wm4> and matrixbench_mpeg2.mpg is from where? [11:53:58 CEST] <ubitux> wm4: http://samples.ffmpeg.org/benchmark/testsuite1/matrixbench_mpeg2.mpg [12:09:16 CEST] <cone-801> ffmpeg 03Shiz 07master:2480da12a41e: configure: Silence error messages when probing compiler. [12:51:34 CEST] <BBB> is my explanation to that qsv guy so bad? [12:51:38 CEST] <BBB> or doesnt it make any sense? [12:51:59 CEST] <nevcairiel> he has understanding problems [12:52:13 CEST] <nevcairiel> or i just understand your comments because i know how its supposed to work [12:58:00 CEST] <cone-801> ffmpeg 03Michael Niedermayer 07release/2.7:b1863e3d9484: avcodec/ffv1enc: fix assertion failure with unset bits per raw sample [13:12:47 CEST] <cone-801> ffmpeg 03Matthieu Bouron 07master:f6518e51b8ed: lavf/mxfdec: support segmented frame layout as separate fields layout [13:17:41 CEST] <BBB> nevcairiel: the bad thing is that it means after each change he does, well have to re-test seeking (flushing) as well as all these things re: bugs you found [13:18:00 CEST] <BBB> does kieranks students seek-test help with that? [14:22:49 CEST] <nevcairiel> i suppose it might actually [14:27:21 CEST] <cone-801> ffmpeg 03Michael Niedermayer 07master:3f87a1706331: avcodec/dvbsubdec: Allow selecting the substream, or all substreams [14:31:29 CEST] <ubitux> > Using the file extension .stem.mp4, this single file can be managed just like an mp3 file. [14:31:34 CEST] <ubitux> what am i reading [14:33:37 CEST] <wm4> didn't you know? music can be encoded using mp3 only [14:33:49 CEST] <wm4> using other formats is a novel concept [14:34:03 CEST] <wm4> and you need to convince users it's as convenient [14:43:39 CEST] <ubitux> Shiz: thx for the patch [14:47:17 CEST] <Shiz> np [15:04:24 CEST] <cone-801> ffmpeg 03Carl Eugen Hoyos 07master:4c4f14c7179c: lavd/v4l2: Use AVSTREAM_PARSE_FULL_ONCE when reading a h264 stream. [15:04:25 CEST] <cone-801> ffmpeg 03Carl Eugen Hoyos 07master:087c0a0a934a: lavc/dvbsub: Do not fail on clut depth 0. [15:28:16 CEST] <cone-801> ffmpeg 03Paul B Mahol 07master:63c442e3b1fe: avfilter/avf_showspectrum: reindent [15:36:29 CEST] <BBB> so if I push a mips patch, should I even bother testing it? [15:36:44 CEST] <BBB> I mean, I dont have a mips system and I dont think I have a functional qemu setup lying around [15:36:49 CEST] <wm4> heh [15:36:55 CEST] <wm4> I'd say trust them [15:37:03 CEST] <wm4> they're probably the only ones interested in this stuff anyway [15:46:31 CEST] <iive> doesn't fate have mips systems? [15:52:33 CEST] <BBB> it probably does [15:52:46 CEST] <BBB> Id hate to turn it red on my first push since, well, ever [15:52:56 CEST] <BBB> plus my push isnt working anyway [15:57:00 CEST] <lglinskih> kierank: now my test compares raw frame's data using tiny_psnr.c, but my ref file is too big (6.3 Mb). And I don't know is it ok...all that I did)) [16:57:09 CEST] <philipl> wm4: No. It decodes to 444 but you can't create a 444 surface for it to write to. If you create a 420 surface and give that to the decoder, you just get garbage on screen, as you'd expect. [16:58:09 CEST] <wm4> that's... bad [17:00:38 CEST] <philipl> at least the user visible failure experience is unchanged in practice because we try and fail to create the 444 video surfaces first [17:02:00 CEST] <kierank> lglinskih: hmm [17:02:37 CEST] <kierank> lglinskih: I'll be back in 15 mins but I need to see how the psnr thresholds are decided in FATE [17:05:57 CEST] <BBB> does anyone here regularly push and know how to solve ssh: connect to host source.ffmpeg.org port 2222: No route to host? [17:06:10 CEST] <BBB> I think I had to chagne a port number somewhere but I forgot how/where [17:06:38 CEST] <BtbN> .ssh/config? [17:07:02 CEST] <BtbN> But so far i allways pushed to a videolan URL, and it worked fine. [17:12:07 CEST] <BBB> whats your git push url? [17:12:44 CEST] <ubitux> i'm using git@source.ffmpeg.org:ffmpeg [17:12:54 CEST] <ubitux> and have no problem; but i don't push that often anymore [17:13:03 CEST] <BtbN> url = git@git.videolan.org:ffmpeg.git [17:13:18 CEST] <BBB> ubitux: thats what I have, and it doesnt work :( [17:13:28 CEST] <BBB> do you have any special config in ~/.ssh/config? [17:13:37 CEST] <ubitux> no [17:13:38 CEST] <BtbN> propably caused by the server move, try pusing to videolan instead [17:13:59 CEST] <ubitux> check your /etc/hosts [17:14:00 CEST] <nevcairiel> BBB: if your ssh tries to use port 2222, then some ssh config is overriding the standard port of 22 [17:15:23 CEST] <BBB> ah indeed [17:15:27 CEST] <BBB> my .ssh/config is messed up [17:16:01 CEST] <BBB> let me see if pushing works [17:16:06 CEST] <BBB> if I screw up, Im really sorry [17:16:18 CEST] <cone-801> ffmpeg 03Shivraj Patil 07master:dec16372df3a: avcodec/mips: MSA (MIPS-SIMD-Arch) optimizations for VP8 functions [17:16:29 CEST] <BBB> ok well that worked ok so far [17:18:09 CEST] <BtbN> i think there are a few hooks in place to prevent the worst screwups [17:25:22 CEST] <cone-801> ffmpeg 03Philip Langdale 07master:aa10f0aab0e2: avcodec/vdpau_hevc: Remove experimental flag [17:25:23 CEST] <cone-801> ffmpeg 03Philip Langdale 07master:f038bbd4edd7: avcodec/vdpau_hevc: Properly signal the num_delta_pocs from the SPS RPS [17:25:24 CEST] <cone-801> ffmpeg 03Philip Langdale 07master:3c8652208b1a: MAINTAINERS: Add myself to vdpau maintainers [17:25:28 CEST] <lglinskih> kierank: fate can compare values of standard deviation or maxdist between bytes. For each test I can set expected value and "fuzz" [17:25:55 CEST] <kierank> you should replicate that but I don't know where the "fuzz" numbers came from exactly [17:42:30 CEST] <lglinskih> kierank: I don't know how to choose "fuzz" correctly, but by default it's 1. [17:42:35 CEST] <kierank> ok [17:47:51 CEST] <lglinskih> kierank: so is big size of the ref file ok? [17:50:04 CEST] Action: kierank tries to find his copy of fate samples [18:03:05 CEST] <BBB> lglinskih: typically yes, but for that reason we try to keep fate tests - esp. for non-bitexact audio sort stuff - very small [18:27:45 CEST] <kierank> philipl: bitmoving favourited my troll [18:32:38 CEST] <wm4> which troll? [18:35:10 CEST] <kierank> https://twitter.com/obencoder/status/628294591129759744 [18:38:58 CEST] <wm4> right [18:39:02 CEST] <wm4> I wonder how this makes sense [18:50:43 CEST] <kierank> ooh got a response [18:50:47 CEST] <kierank> https://twitter.com/bitmovin/status/628608598508081155 [18:53:29 CEST] <JEEB> because mass-mailing people is not spamming at all... [19:01:59 CEST] <peloverde> what did they send? [19:02:16 CEST] <kierank> "Maybe you are interested in testing our encoding service http://www.bitcodin.com , which encodes video 100x faster than realtime,..." [19:03:25 CEST] <peloverde> wow that's super spammy, I was figuring it was going to be something like "halp with our half baked feature" [19:06:44 CEST] <wm4> didn't ffmpeg.c have nanomsg support or something similar? [19:08:47 CEST] <ubitux> wm4: there is a zmq filter [19:09:02 CEST] <ubitux> and also on the cli you have an input [19:09:30 CEST] <wm4> right, zmq [19:09:32 CEST] <ubitux> maybe nanomsg would have been a better idea than ømq [19:09:46 CEST] <wm4> dunno [19:09:56 CEST] <wm4> just looking for inspiration [19:10:00 CEST] <ubitux> it has limited scope [19:10:10 CEST] <ubitux> it's just for filter commands [19:13:48 CEST] <lglinskih> kierank: can you review my new version of test? https://github.com/lglinskih/FFmpeg/commit/077a37ba763e265ed7fede22235a268b… [19:14:45 CEST] <wm4> a non-ASCII ref file? that seems unfortunate... [19:15:10 CEST] <kierank> yeah the printf("%c" thing is weird [19:15:30 CEST] <wm4> maybe it could be done as hex if it has to be this way [19:18:25 CEST] <philipl> kierank: haha. [19:20:36 CEST] <lglinskih> kierank, wm4: I've tried to find how it was done in ffmpeg.c, but it always impossible for me (find any example of realization in ffmpeg.c) =/ [19:21:09 CEST] <lglinskih> so doing printf with %x is normal way?) [19:24:38 CEST] <wm4> yeah, I think I'd prefer it in hex [19:25:11 CEST] <wm4> maybe %02x or so would format it correctly (not sure) [19:25:27 CEST] <wm4> and I don't know what ffmpeg.c does either, but I'm lacking context [19:26:48 CEST] <wm4> but maybe it's a matter of taste [19:26:58 CEST] <wm4> do we have existing ref files that are binary? [19:29:06 CEST] <nevcairiel> non-bitexact tests should just use the fate tools we have for such things, stddev checks or things like that [19:31:03 CEST] <nevcairiel> how is that not bitexact though? is it a floating point thing or what? [19:36:24 CEST] <wm4> it's decoded raw data [19:36:28 CEST] <wm4> doesn't seem ideal either [19:36:45 CEST] <wm4> lglinskih: I didn't follow this; why remove the hashing and dump the raw data directly to the ref file? [19:39:32 CEST] <lglinskih> wm4: the main idea is to support non-bitexact codecs. So in that case we should compare frames with some deviation. As I understand crc isn't applicable for that target [19:40:16 CEST] <wm4> right [19:40:34 CEST] <nevcairiel> but even non-bitexact codecs should decode to the same frame on every system [19:40:39 CEST] <nevcairiel> unless floating point or inexact simd [19:40:42 CEST] <wm4> and apparently ffmpeg.c can do it, but you didn't find out how (I don't know either) [19:42:00 CEST] <nevcairiel> i dont understand how storing binary data works around the "not bitexact" problem, but a hash of the binary data does not [19:42:50 CEST] <wm4> hm, I think FATE doesn't do it with ffmpeg.c, but separate utils? [19:42:59 CEST] <nevcairiel> probably [19:43:02 CEST] <iive> imho, mpeg2 should always produce the same output using the same idct implementation. [19:43:13 CEST] <nevcairiel> if framecrc in ffmpeg isnt enough, then it uses external test tools [19:43:50 CEST] <nevcairiel> tiny_psnr maybe [19:44:25 CEST] <iive> afair bitexact was introduced in encoders and muxers that use random numbers. (e.g. security while streaming) [19:48:33 CEST] <lglinskih> hmmmmmmmmmm [19:49:41 CEST] <JEEB> iive: it's also used for stuff like colorspace conversions where there are non-bitexact SSE(2) paths [19:49:55 CEST] <JEEB> I remember having to add a bitexact flag to an encoder test [19:50:05 CEST] <JEEB> because the source was generated in a non-bitexact way [19:50:33 CEST] <lglinskih> so now my test is able to compare some sort of messy output with small deviation using tiny_psnr.c tool [19:51:02 CEST] <lglinskih> but for most of codecs I can still use comparing of crcs? [19:52:20 CEST] <kierank> if it's bitexact yes [19:52:30 CEST] <kierank> but that's not most I think [19:55:46 CEST] <nevcairiel> why not [19:55:58 CEST] <nevcairiel> why would decoding results differ on different systems [19:56:03 CEST] <nevcairiel> video doesnt often use floating point [19:56:19 CEST] <nevcairiel> and you can force a specific IDCT to avoid differences there [20:02:45 CEST] <BtbN> philipl, are you around? Could you have a quick look at https://github.com/BtbN/FFmpeg/commits/master the top three commits basicaly? First two ones are just cosmetic/trivials though. [20:06:34 CEST] <kierank> nevcairiel, lglinskih: yes you're right - I'm mixing up encoder/decoder mismatch [20:07:13 CEST] <nevcairiel> some video codec specs are not bitexact [20:07:15 CEST] <nevcairiel> ie. mpeg2 [20:07:23 CEST] <nevcairiel> but thats a mismatch between different mpeg2 decoders [20:07:38 CEST] <nevcairiel> avcodec should still be the same at all times =) [20:11:02 CEST] <wm4> unless it selects an "optimized" idct for some obscure cpu? [20:11:16 CEST] <BtbN> The twopass vbr seems to work, but i can't see a notable difference. [20:11:23 CEST] <nevcairiel> yeah you can override the idct choice just in cas [20:11:25 CEST] <nevcairiel> +e [20:11:59 CEST] <cone-801> ffmpeg 03Hendrik Leppkes 07master:2ab5002e3cd2: ffmpeg: avoid scanf in keyboard command parsing [20:12:00 CEST] <cone-801> ffmpeg 03Hendrik Leppkes 07master:99f8fc725de4: ffmpeg: remove access to private FILE struct members on Windows [20:15:21 CEST] <lglinskih> What is bitexact flag used for? [20:16:56 CEST] <ubitux> reproducible constant output [20:17:57 CEST] <ubitux> which means disabling the printing of ffmpeg libs versions in meta of the outputs, or disabling optimizations that plays on architecture approximations, etc [20:18:17 CEST] <ubitux> anything that would produce different results on different architecture, configuration, or eventually versions [20:33:45 CEST] <cone-801> ffmpeg 03Henrik Gramner 07master:826790f59640: x86inc: Support arbitrary stack alignments [20:33:46 CEST] <cone-801> ffmpeg 03Henrik Gramner 07master:f0b7882ceb79: x86inc: Drop SECTION_TEXT macro [20:43:01 CEST] <BBB> nevcairiel: well, for e.g. scalable video (resolution changes), we invoke swscale before generating the crcs, and thus we depend on swscale being bitexact (which it isn't) [20:43:10 CEST] <BBB> nevcairiel: I remember that being annoying at some point [20:43:16 CEST] <BBB> so even video is sometimes not 100% easy [20:43:22 CEST] <nevcairiel> i guess [20:43:29 CEST] <nevcairiel> but those cases are known then [21:21:14 CEST] <nevcairiel> mm i should really just re-do my fate VM entirely and cleanse the old stuff off of it before installing vs2015 on it [21:22:52 CEST] <nevcairiel> it still has vs2010 installed on it, havent been running that for years :D [21:23:49 CEST] <jamrial> lol [21:23:56 CEST] <jamrial> vs2012 is still broken for that matter [21:24:14 CEST] <jamrial> either whatever's wrong with c99-to-89 (or the lavc code failing the assertion) is fixed, or we just drop vs2012 support altogether [21:24:45 CEST] <BtbN> I don't see a problem with dropping support for old msvc versions. [21:25:17 CEST] <nevcairiel> you could beg BBB or wbs to look at it, not that i think they still care much about c99-to-c89, but they would be the ones to fix it [21:25:46 CEST] <BBB> c99-to-c89 is likely utterly broken [21:26:27 CEST] <BBB> I havent looked at that code for ages [21:26:42 CEST] <BBB> wbs: wdyt? [21:26:57 CEST] <BBB> who else wrote that thing& wasnt it derek also? [21:27:14 CEST] <wm4> isn't c99-to-89 still useful for the things msvc2015 fails at? [21:27:46 CEST] <wbs> wm4: no, it isn't useful after msvc2013 [21:28:01 CEST] <BBB> didnt he say 2012? [21:28:11 CEST] <BBB> jamrial: whats broken? [21:28:13 CEST] <wbs> wm4: it only does the c99 syntax fixes, like c99 designated initializers and such, it doesn't add any other c99 compat wrapping like fixing printf stuff or so [21:28:18 CEST] <nevcairiel> BBB: Assertion failed: index_is_unique(&struct_array_lists[rec.parent->data.sal_idx], sai->index), file convert.c, line 1601 [21:28:25 CEST] <nevcairiel> in wmv2enc.c [21:28:27 CEST] <wbs> BBB: yes, but wm4 asked about use on current versions [21:28:35 CEST] <BBB> true [21:28:41 CEST] <wm4> wbs: thinking about the msvc preprocessor handling varargs incorrectly (in general, not in context of ffmpeg) [21:28:43 CEST] <jamrial> 2012 needs it, but some recent change triggered that assertion in the wmv2 encoder [21:28:54 CEST] <jamrial> 2013 and newer don't use or need it at all [21:29:10 CEST] <wbs> jamrial: do you have the really latest version of it? I've fixed some such crash in the last 12 months or so [21:29:32 CEST] <jamrial> i don't have msvc. i'm looking at the fate client [21:29:37 CEST] <wbs> ah [21:29:38 CEST] <jamrial> http://fate.ffmpeg.org/report.cgi?time=20150804165024&slot=x86_32-msvc11-wi… [21:29:45 CEST] <nevcairiel> i cant build that thing, so unless someone provides binaries [21:29:47 CEST] <jamrial> it's nevcairiel's [21:29:56 CEST] <nevcairiel> its using 1.0.3 [21:30:05 CEST] <wbs> nevcairiel: I think Daemon404 might have done a new release at some point [21:31:06 CEST] <nevcairiel> 1.0.3 is from december 2014 [21:31:12 CEST] <nevcairiel> only one change is missing in that, apparently [21:31:58 CEST] <nevcairiel> and that seems unrelated [21:32:23 CEST] <nevcairiel> i might just drop 2012 [21:33:27 CEST] <wbs> nevcairiel: fwiw, libav still builds just fine with 2010 and 2012; I don't see anything relating to the converter in that build report as such, only that the configure seems to be broken somehow (wrt _BitScanForward and such) [21:33:40 CEST] <BBB> I dont see any suspcious code in wmv2enc.c as of this year [21:33:44 CEST] <nevcairiel> i found the problem i think [21:35:21 CEST] <cone-801> ffmpeg 03Carl Eugen Hoyos 07master:128e722bc101: lavf/swf: Fix auto-detection of compressed files. [21:35:33 CEST] <nevcairiel> just need to make a build to verify [21:36:30 CEST] <nevcairiel> suprising no other compiler at least warns about this [21:36:38 CEST] <cone-801> ffmpeg 03Hendrik Leppkes 07master:bec062e57c11: wmv2enc: remove duplicate priv_class in codec definition [21:37:07 CEST] <nevcairiel> merge gone wrong, i guess [21:37:09 CEST] <BBB> -Wshadow? [21:37:45 CEST] <nevcairiel> i think 2012 is going to work again now :d [21:37:56 CEST] <BBB> oh I see [21:38:04 CEST] <BBB> I dont think thats illegal in C [21:38:09 CEST] <BBB> its incredibly stupid :D [21:38:16 CEST] <BBB> Im happy for c99-to-c89 to abort on that [21:38:46 CEST] <BBB> ty nevcairiel [21:39:23 CEST] <nevcairiel> guess i will re-install vs2012 on the new vm then [21:42:22 CEST] <philipl> BtbN: looking now [21:43:19 CEST] <philipl> BtbN: looks good to me [21:44:50 CEST] <BtbN> I'm unable to spot any difference though. The encode fps don't change a bit, and the quality looks the same to me. [21:44:58 CEST] <BtbN> bitrate is also unaffected [21:45:19 CEST] <philipl> Yeah. But who knows how they implement this stuff under the covers. Might be designing the API for future hardware capabilities [21:46:03 CEST] <philipl> Best feature in the new nvidia driver release is that it locks up on system resume every time [21:46:10 CEST] <cone-801> ffmpeg 03Timo Rothenpieler 07master:bef740688d7d: avcodec/nvenc: Fix indentation [21:46:11 CEST] <cone-801> ffmpeg 03Timo Rothenpieler 07master:3a20e5bc3b8c: avcodec/nvenc: Only set h264 parameter when encoding h264 [21:46:12 CEST] <cone-801> ffmpeg 03Timo Rothenpieler 07master:2ae45816b2f3: avcodec/nvenc: Add support for 2pass rc in vbr mode [21:46:33 CEST] <BtbN> I gave up on using any kind of suspend/resume entirely. [21:46:49 CEST] <BtbN> It just causes way too many issues, and a full boot only takes a few seconds anyway. [21:47:09 CEST] <philipl> Up until this point it's been pretty reliable. It reached a peak before they rewrote their displayport device detection code. [21:47:13 CEST] <wm4> I've used it for years with nv drivers without issues [21:47:18 CEST] <philipl> Then it started crashing X if displays were off at resume time [21:47:21 CEST] <philipl> Now I have this. [21:47:50 CEST] <wm4> though when my nv card was new, the driver at the time caused random crashes (was fixed after a week or so) [21:48:03 CEST] <philipl> They do a good job overall, but regressions happen. [21:48:17 CEST] <philipl> Does anyone have any samples that exercise the weird baseline-only h.264 features? [21:48:34 CEST] <BtbN> I stopped using open source drivers for nvidia when nouveau phyiscaly killed one of my cards. And the devs just shrugged it of as a known bug that could sometimes cause this. [21:49:04 CEST] <philipl> BtbN: Progress requires sacrifice. [21:49:25 CEST] <BtbN> The card was done, wasn't even recognized to be present anymore by the system. [21:49:59 CEST] <BtbN> Aparently a bug in their reverse engineered firmware, massively overvolting something [21:50:07 CEST] <philipl> haha. [21:50:12 CEST] <philipl> But I am sorry for your loss. [21:50:27 CEST] <BtbN> It was a 30¬ GT card, so not too horrible of a loss. Still annoying [21:50:41 CEST] <wm4> amazing [21:50:53 CEST] <philipl> I'm still impatiently awaiting their lowend cards with HEVC. I want to put my 980 back in so I can play Shadows of Mordor. [21:50:57 CEST] <philipl> Runs like shit on a 970 [21:50:59 CEST] <philipl> 960 I mean [21:51:09 CEST] <BtbN> 980 doesn't have hevc? oO [21:51:13 CEST] <philipl> That's normal. [21:51:21 CEST] <nevcairiel> 960 is the only card with the new decoder so far [21:51:21 CEST] <wm4> oh there isn't one? how unfortunate since I need to buy a new GPU soon [21:51:24 CEST] <philipl> They debute new video engines on the mid-range second wave cards [21:51:35 CEST] <BtbN> Mordor runs great on my 760 though. [21:51:36 CEST] <philipl> It's like intel tick-tock [21:51:41 CEST] <nevcairiel> the 950 is coming out soon, it may have the new decoder as well [21:51:46 CEST] <nevcairiel> no real low-end though [21:52:03 CEST] <BtbN> i think the gt630 Rev. 2 is the best low-end you can get. [21:52:05 CEST] <philipl> 950 will have it. but I need a single slot card to be able to fit it into the system as a second card [21:52:14 CEST] <BtbN> It's already a bit luck if you want a kepler based gt card [21:52:15 CEST] <philipl> 950 will probably still be two slot [21:52:25 CEST] <nevcairiel> 950 may be low enough to get some custom single slot designs [21:52:33 CEST] <nevcairiel> the 750 did at least, and it should be on a similar level [21:52:46 CEST] <philipl> good point. I shall hope for the best [21:53:07 CEST] <wm4> I just want something passively cooled [21:53:11 CEST] <BtbN> I won't get any new cards until i get an entirely new PC [21:53:16 CEST] <wm4> so it has ot be low-end, I guess [21:53:19 CEST] <wm4> *to [21:53:30 CEST] <nevcairiel> passive is rather rare these days [21:53:33 CEST] <philipl> wm4: passive or silent? water cooled :-) [21:53:46 CEST] <nevcairiel> although many GPUs come with a hybrid approach, they just turn off the fan until a certain temp is reached [21:53:52 CEST] <nevcairiel> which you only do when you put 3D load on it [21:53:59 CEST] <wm4> no fan and no whatever the fuck water cooling would require [22:00:10 CEST] <philipl> https://www.pugetsystems.com/mineral-oil-pc.php [22:01:45 CEST] <wm4> fucking hell [22:02:11 CEST] <llogan> someone needs to get laid [22:02:40 CEST] <wm4> even the goddamn PSU is in oil [22:10:47 CEST] <lglinskih> kierank: resume: I should fix an output format (for codecs which uses some floating point values) and add bitexact flag to get the same crcs for non-bitexact codecs. Is it correct? [22:48:26 CEST] <Daemon404> [20:30] <@wbs> nevcairiel: I think Daemon404 might have done a new release at some point <-- no not yet [22:48:36 CEST] <Daemon404> https://github.com/libav/c99-to-c89/compare/release-1.0.3...master [22:48:38 CEST] <Daemon404> the diff is... small [22:48:53 CEST] <Daemon404> [20:32] <+nevcairiel> i might just drop 2012 <-- yeah i did [22:48:57 CEST] <Daemon404> pre-c99 msvc is dead to me [22:51:22 CEST] <philipl> Daemon404: Has microsoft finally shipped a c99 compliant msvc? [22:51:48 CEST] <nevcairiel> 2013 already worked good enough for ffmpeg [22:51:55 CEST] <nevcairiel> with a few hacks [22:52:01 CEST] <nevcairiel> 2015 doesnt even need the hacks anymore [22:52:13 CEST] <philipl> It only took them 16 years. Good work. [22:52:21 CEST] <Daemon404> it's not 100% c99 [22:52:24 CEST] <Daemon404> it doesnt support VLAs [22:52:26 CEST] <Daemon404> but i dont care [22:52:29 CEST] <Daemon404> cause VLAs are evil [22:52:32 CEST] <nevcairiel> arent VLAs optional [22:52:34 CEST] <Daemon404> and you shouldnt use the [22:52:34 CEST] <philipl> VLAs were downgraded for c11 [22:52:35 CEST] <wm4> philipl: msvc is somewhat c99 compatible; they don't support some C-only things (like the tgmath header), and their preprocessor is broken [22:52:41 CEST] <Daemon404> nevcairiel, in c11 yes [22:52:43 CEST] <philipl> Now they're optional. [22:52:50 CEST] <philipl> Presumably so msvc could be c11 compliant [22:52:53 CEST] <Daemon404> wm4, tgmath is shit [22:52:57 CEST] <Daemon404> it should never have been made [22:53:06 CEST] <wm4> not going to miss it [22:53:12 CEST] <Daemon404> nobody is [22:53:25 CEST] <Daemon404> yeah i wish theyd fix their preprox [22:53:27 CEST] <wm4> but I miss a correct preprocessor [22:53:28 CEST] <Daemon404> #define E(X) x [22:53:30 CEST] <Daemon404> ^ msvc bs [22:53:34 CEST] <Daemon404> s/X/x/ [22:54:18 CEST] <nevcairiel> tgmath is the only part of the c99 stdlib which is missing, which is pretty good [22:54:24 CEST] <Daemon404> oh boy bitmovin followed me on twitter [22:54:36 CEST] <Daemon404> even though they found me cause i liked a tweet from kierank mocking them [22:54:37 CEST] <wm4> nevcairiel: wasn't there something else? but whatever [22:54:53 CEST] <nevcairiel> "Our C99 Standard Library implementation is complete, except for tgmath.h (which is irrelevant in C++) and the CX_LIMITED_RANGE/FP_CONTRACT pragma macros." [22:54:56 CEST] <nevcairiel> whatever those macros are [22:55:42 CEST] <Daemon404> yeah that's cause 2015 had a major crt rewrite [22:55:44 CEST] <Daemon404> allowing for it ot hapen [22:55:47 CEST] <Daemon404> happen* [22:56:12 CEST] <wm4> now I'm waiting for C11 support [22:56:18 CEST] <nevcairiel> the new printf is nice, it finally warns you for format specifier and var datatype mismatches =p [22:56:19 CEST] <wm4> I bet they'll never implement stdatomics.h [22:56:22 CEST] <Daemon404> wm4, does gcc even have it? [22:56:27 CEST] <wm4> yes [22:56:32 CEST] <wm4> took a while [22:56:38 CEST] <Daemon404> there wasn't much in c11 i wanted a lot [22:56:38 CEST] <BBB> given c99 took 15 years [22:56:41 CEST] <Daemon404> i can't think of any [22:56:45 CEST] <BBB> c11 will be done around 2026 [22:56:50 CEST] <wm4> though it's easy to emulate with ancient atomic intrinsics [22:56:59 CEST] <Daemon404> BBB, it will be done whenever the c11 headers make it to c++ [22:57:05 CEST] <BBB> c99 was equally easy to emulate, wm4 [22:57:16 CEST] <BBB> that was the whole point of c99-to-c89 [22:57:37 CEST] <Daemon404> some bits werent, so they were removed (VLA) [22:57:39 CEST] <wm4> stdatomic.h requires compiler support, and is useful for C only [22:57:42 CEST] <wm4> (C++ has its own shit) [22:57:47 CEST] <BBB> true [22:57:48 CEST] <wm4> ideal candidate to be ignored by MS [22:57:50 CEST] <BBB> fortunately we dont use vla [22:58:03 CEST] <BBB> although its sometimes nice for quick hack tests [22:58:08 CEST] <Daemon404> we did before msvc support was added, BBB [22:58:15 CEST] <BBB> I know [22:58:18 CEST] <BBB> mru insisted on it [22:58:20 CEST] <BBB> I dont recall why [22:58:28 CEST] <wm4> VLAs don't make much sense anyway [22:58:29 CEST] <BBB> I can only guess some silly arm compiler didnt support it [22:58:33 CEST] <wm4> either your buffer is bounded or not [22:58:41 CEST] <wm4> and for both cases there's a good answer what to do [22:58:45 CEST] <Daemon404> mru is one of those "if it is the standard, i must defend its use" [22:58:47 CEST] <Daemon404> people [22:58:57 CEST] <Gramner> the msvc printf stuff rewrite was way overdue, it was hilariously bad before. "Before this refactoring, the sprintf functions, which write formatted data to a character buffer, were implemented by wrapping the result buffer in a temporary FILE object and then deferring to the equivalent fprintf function" [22:59:21 CEST] <wm4> Gramner: using a temporary FILE object is a good idea [22:59:32 CEST] <Gramner> it's also slow [22:59:35 CEST] <wm4> nope [22:59:45 CEST] <wm4> musl had quite good results with this approach [23:00:11 CEST] <wm4> of course musl code is all about being compressed and unreadable, but stil [23:00:12 CEST] <wm4> l [23:00:24 CEST] <Daemon404> we'll all care about musl when midipix works [23:00:25 CEST] <Daemon404> and is public [23:00:26 CEST] <Daemon404> so never. [23:00:42 CEST] <wm4> snprintf is basically equivalent with the fast path for FILE I/O (you write to the IO buffer) [23:00:50 CEST] <wm4> midipix is public now [23:00:58 CEST] <Daemon404> iirc nto rentirely [23:01:03 CEST] <Daemon404> and not in a feasibly workign state [23:01:12 CEST] <wm4> the latter is probably true [23:01:50 CEST] <smarter> Gramner: the part I liked the most in their description: "The CRT provides 142 different variations of printf, but most of the behavior is the same for all of the functions, so there are a set of common implementation functions that do the bulk of the work. These common implementation functions were all defined in output.c in the CRT sources(1). This 2,696 line file had 223 conditionally compiled regions of code (#ifdef, #else, etc.), over [23:01:50 CEST] <smarter> half of which were in a single 1,400 line function. This file was compiled 12 different ways to generate all of the common implementation functions. " http://blogs.msdn.com/b/vcblog/archive/2014/06/10/the-great-crt-refactoring… [23:02:17 CEST] <Daemon404> didnt they also say they were trying to commit to ABI stability for the core crt now [23:02:20 CEST] <Daemon404> or something [23:02:21 CEST] <Daemon404> post-2015 [23:02:35 CEST] <nevcairiel> yes [23:02:41 CEST] <nevcairiel> splitting the crt in two parts [23:02:47 CEST] <Daemon404> yes that was it [23:03:07 CEST] <nevcairiel> the VCRuntime which remains compiler dependent (but is small), and the Universal CRT, which is a OS component now and remains stable [23:03:12 CEST] <Gramner> smarter: maybe they were aiming for IOCCC with the old code [23:03:15 CEST] <wm4> so when can mingw stop doing the "use an ancient msvcrt" bullshit? [23:03:26 CEST] <Daemon404> wm4, they never will [23:03:28 CEST] <nevcairiel> well only windows 10 ships with the new CRT natively [23:03:45 CEST] <Daemon404> nevcairiel, still mingw should *not* be using msvcrt.dll by default [23:03:50 CEST] <Daemon404> given vista is the lowest supported os [23:04:09 CEST] <wm4> lowest supported OS by what? [23:04:17 CEST] <Daemon404> the vendor itself. [23:04:22 CEST] <wm4> lol [23:04:31 CEST] <wm4> I sure wish XP would die [23:04:58 CEST] <Daemon404> it is dead to me [23:05:04 CEST] <Daemon404> xp users aren't people [23:07:08 CEST] <nevcairiel> what I wish I could do is use a newer crt and static link that into a mingw build, like I do with my msvc builds [23:07:12 CEST] <nevcairiel> but alas, thats not possible afaik =p [23:07:47 CEST] <Daemon404> as in build with mingw + static crt? [23:08:18 CEST] <Daemon404> man i remember the good old days of using a sketchy "dll2lib" converter to convert proprietary dll blobs into static libs.... [23:08:23 CEST] <Daemon404> maybe they were the bad old days. [23:08:34 CEST] <wm4> not sure why you'd care about static linking [23:08:38 CEST] <wm4> unless maybe for installers [23:08:56 CEST] <Daemon404> wm4, because i was a stupid teenager? [23:09:16 CEST] <wm4> well, nevcairiel [23:09:27 CEST] <nevcairiel> i dont want to ship the silly runtime dll [23:09:40 CEST] <Daemon404> nevcairiel, they also discourage that [23:09:50 CEST] <nevcairiel> its unsupported with 2015, i know [23:10:18 CEST] <wm4> are you talking about static linking, or shipping the dll? [23:10:20 CEST] <nevcairiel> static linking is also discouraged, but what can i do, i dont want to stick to ages old dev env just to avoid everyone screaming at me that they dont want to install runtimes [23:10:23 CEST] <nevcairiel> so i static link :p [23:10:39 CEST] <Daemon404> nevcairiel, you could embed teh dll as a resoource an load it at runtime [23:10:44 CEST] <Daemon404> but that's incredibly evil [23:10:53 CEST] <nevcairiel> app-local deployment (ie shipping the dll just in the folder) is entirely unsupported in vs2015 [23:10:53 CEST] <Daemon404> and probably will be caught as malware [23:11:01 CEST] <nevcairiel> static linking is discouraged, but still possible [23:11:21 CEST] <wm4> nevcairiel: so, how are you supposed to ship builds compatible to all windows versions? [23:11:29 CEST] <wm4> use an old msvc? [23:11:33 CEST] <Daemon404> wm4, do what games do [23:11:34 CEST] <nevcairiel> ship the installer to the runtime [23:11:37 CEST] <Daemon404> they bundke the runtime installer [23:11:42 CEST] <Daemon404> and integrate it [23:11:45 CEST] <Daemon404> all video games do this [23:11:49 CEST] <Daemon404> every time you install a steam game [23:11:50 CEST] <Daemon404> etc [23:11:58 CEST] <wm4> so the installer calls the MS runtime installer? [23:12:07 CEST] <Daemon404> with some flags yeag [23:12:09 CEST] <BtbN> steam games can just tell steam to make sure some common runtime is installed [23:12:11 CEST] <nevcairiel> or if you dont need XP support, you can also add a dependency in your manifest file, which will trigger windows update to install it [23:12:16 CEST] <nevcairiel> although no idea how that really works [23:12:20 CEST] <Daemon404> BtbN, same idea though [23:12:21 CEST] <nevcairiel> i just read that its possible [23:12:22 CEST] <Daemon404> it is silent to the user [23:14:56 CEST] <nevcairiel> if you happen to use a MSI installer, it also has some magic ways to get the runtime through windows update [23:15:07 CEST] <nevcairiel> but mostly, just bundle the vcredist installer [23:15:26 CEST] <BtbN> Which is kind of a problem if you are packaging GPL software. [23:15:33 CEST] <nevcairiel> as if anyone cares [23:15:35 CEST] <nevcairiel> just do it [23:15:35 CEST] <nevcairiel> :p [23:15:49 CEST] <Daemon404> only one guy cares [23:16:54 CEST] <nevcairiel> Who would have legal standing to complain? MS? They are not going to block you from building software for your apps. The dev of the app? Well if he doesn't want a windows version, he might use it to screw you, but usually, why would he not want his stuff shipped? [23:18:13 CEST] <BtbN> It's kind of a dumb rule imo, i don't see what it tries to pretect. [23:18:55 CEST] <Daemon404> nothing [23:18:59 CEST] <Daemon404> it's pedantic nerds [23:19:03 CEST] <Daemon404> and "M$" people [23:23:31 CEST] <nevcairiel> somehow that reminded me that I wanted to continue looking into moving to LGPL [23:25:07 CEST] <Daemon404> how would that even matter for you [23:25:12 CEST] <Daemon404> it's a dshow filter [23:25:19 CEST] <nevcairiel> companies keep asking [23:25:33 CEST] <Daemon404> idiot companies? [23:25:37 CEST] <nevcairiel> the legal situation is probably a bit grey [23:25:41 CEST] <Daemon404> you sure dont link a dshow filter [23:26:01 CEST] <nevcairiel> well they cant exactly ship it with their software [23:26:09 CEST] <nevcairiel> or i dunno [23:26:10 CEST] <Daemon404> why not [23:26:15 CEST] <Daemon404> people ship e.g. x264.exe [23:26:34 CEST] <nevcairiel> i dlopen avcodec with x264 static linked, does that make it ok? [23:26:56 CEST] <nevcairiel> its the same thing really [23:26:57 CEST] <Daemon404> who knows [23:27:08 CEST] <nevcairiel> COM just puts dlopen duties into MS hands [23:27:13 CEST] <Daemon404> i can write a x264 plugin for adobe premier [23:27:19 CEST] <Daemon404> who goes after who for what? [23:27:24 CEST] <Daemon404> it's just a shitty mes. [23:27:42 CEST] <BtbN> I think the (L)GPL doesn't impose any restrictions on how to ship them. [23:27:43 CEST] <nevcairiel> anyway, since LAV is like 99.9% all my code, relicensing shouldnt be that impossible [23:27:49 CEST] <wm4> lawyers make up what's supposed to be acceptable [23:27:50 CEST] <nevcairiel> just need to track down the 0.1% [23:27:55 CEST] <wm4> techies don't get to decide [23:27:58 CEST] <nevcairiel> but i've been lazy [23:28:08 CEST] <nevcairiel> maybe some company offers to pay for the priviledge [23:28:15 CEST] <Daemon404> you should ask [23:28:30 CEST] Action: Daemon404 is reminded of yadif [23:28:44 CEST] <JEEB> nevcairiel: also you don't have any dead bodies in the 0.1% yet (most probably) [23:28:49 CEST] <JEEB> so it should be rather painless [23:29:10 CEST] <nevcairiel> JEEB: i did base some of the code on some old mpc-hc code at the beginning though, need to try to find out if any of that is still left [23:29:18 CEST] <JEEB> ah [23:29:33 CEST] <wm4> according to some people, it doesn't matter if nothing is left [23:29:34 CEST] <nevcairiel> mostly in the splitter, decoders are practically all mine [23:29:43 CEST] <wm4> it still counts as derived from the original code [23:29:51 CEST] <wm4> so the original authors still have rights on it [23:30:17 CEST] <nevcairiel> I learned C from a book, do its authors have rights on all my code now? Its derived from that C knowledge, afterall [23:30:32 CEST] <wm4> a lawyer would probably say no [23:30:37 CEST] <wm4> but still insist on the former [23:32:24 CEST] <nevcairiel> I suppose there is some logic in that, but it never was more than some concepts that i took and re-wrote, but I suppose since I read their code and then came up with mine based on that, it still applies [23:32:29 CEST] <nevcairiel> nonsense still, but shrug [23:33:13 CEST] <wm4> don't know, I just read that on some SO post anyway [23:33:15 CEST] <nevcairiel> I could just replace the license file now and I bet noone would ever complain [23:33:29 CEST] <wm4> maybe ask j-b, he's almost a license lawyer [23:33:53 CEST] <nevcairiel> well he clearly doesnt agree, since they did re-license [23:34:30 CEST] <nevcairiel> which included re-writing some parts of code [23:35:51 CEST] <wm4> yeah, but not all code [23:36:14 CEST] <wm4> and they probbaly did the rewrite parts in a lawyer approved way [23:36:24 CEST] <wm4> which means pretend you didn't look at the replaced code [23:44:45 CEST] <nevcairiel> i refactored things so often in the early times, that I could probably claim its not even influenced by the original much anymore .. other than knowing it was a bad concept =p [23:45:09 CEST] <BBB> every time I hear a mplayer dev email on ffmpeg-devel@, I cringe [23:45:12 CEST] <BBB> am I a bad person? [23:45:32 CEST] <BBB> I think I start cringing already before Ive opened the email, but with every line I read, my cringing gets worse [23:45:47 CEST] <BBB> I think my cringing gets worse because of the content of the email but I have not scientifically verified that hypothesis [23:52:04 CEST] <llogan> IBM claims they will sponsor bounties for fixing issues related to POWER or z systems (they even mention FFmpeg). [23:52:12 CEST] <llogan> https://www.bountysource.com/teams/ibm/issue_suggestions/new [23:52:21 CEST] <nevcairiel> do they also send me such a system? [23:52:53 CEST] <llogan> who knows, but don't ask me to ask them. i tend to never get replies. [23:52:58 CEST] Action: llogan looks at Linode [23:53:36 CEST] <llogan> huh, there is some power stuff on fate [23:53:38 CEST] <nevcairiel> apparently that page sponsors you for finding and reporting those issues, not necessarily fixing [23:54:49 CEST] <nevcairiel> they'll probably open individual bounties once found [23:55:06 CEST] <llogan> ah, here's the current list https://www.bountysource.com/teams/ibm/bounties [23:57:54 CEST] <BBB> bounties really are the uber of software engineers [23:58:13 CEST] <BBB> (or lyft) [00:00:00 CEST] --- Wed Aug 5 2015

1 0

ffmpeg.log.20150804
by burek 05 Aug '15

05 Aug '15

[00:56:31 CEST] <Craytor> When I run this: ffmpeg -f x11grab -vc x264 -s xga -r 30 -b:v -g 300 -i :1.0 session-recording.avi, I get: :1.0: protocol not found [00:56:42 CEST] <Craytor> Suggestions/help please? [01:03:47 CEST] <edoceo> What's the best/preferred format container for huffyuv video stuffss? .avi or mpegts or mkv or ?? [01:03:54 CEST] <edoceo> I'm hoping to get one that is "fast" [01:04:07 CEST] <Nolski> edoceo: I've used .avi which has been pretty fast [01:04:20 CEST] <Craytor> Can someone help me please? [01:04:24 CEST] <Nolski> .avi has also given me the least amount of trouble [01:06:14 CEST] <Craytor> Nolski, http://pastebin.com/wgUreEqs [01:07:02 CEST] <Nolski> Craytor: What are you intending to do with -i [01:07:22 CEST] <Craytor> Nolski: Get the display... [01:09:14 CEST] <Craytor> Nolski: is there something wrong with it? [01:20:43 CEST] <Nolski> Craytor: Yeah, I don't think ffmpeg -i :1.0 grabs the display [01:21:07 CEST] <c_14> It does. [01:21:15 CEST] <c_14> It grabs the X display on :1.0 [01:23:49 CEST] <Nolski> Wouldn't it be :0.0+1? [01:24:07 CEST] <c_14> The + is just offset stuffs [01:24:14 CEST] <Nolski> ahh I see [01:24:37 CEST] <Craytor> So is there any way to get this to work then? [01:25:09 CEST] <c_14> The first X display is on :0.0 the second on :1.0 [01:26:16 CEST] <c_14> Oh, I see the problem [01:26:25 CEST] <c_14> >-b:v -g 300 [01:26:35 CEST] <c_14> first of all, those are both output options, second that's broken [01:27:51 CEST] <Craytor> So what do I do? [01:27:56 CEST] <Craytor> Remove -b:v? [01:28:07 CEST] <c_14> What are you trying to do? [01:28:15 CEST] <Craytor> Record the screen [01:28:32 CEST] <c_14> ffmpeg -f x11grab -i :1.0 out.avi [01:29:50 CEST] <Craytor> hmm [01:30:04 CEST] <Craytor> Okay, I need to open that file to see if it worked, then I'll tell you what's going on ;) [01:30:13 CEST] <Craytor> But this is the farthest I've gotten yet [01:36:30 CEST] <Craytor> c_14, the file is being created, but it's content is just black [01:36:36 CEST] <Craytor> aka, no desktop display [01:36:53 CEST] <c_14> What resolution is the desktop? [01:37:50 CEST] <Craytor> I'm not sure, how do I tell? [01:37:56 CEST] <Craytor> I'm using a VNC connection [01:38:41 CEST] <Craytor> Got it, 1024x768 [01:39:25 CEST] <c_14> try adding -video_size 1024x768 before the -i [01:40:38 CEST] <Craytor> Viewing window when I played it was larger [01:40:40 CEST] <Craytor> But still black [01:45:49 CEST] <DHE2> anything blocking shared memory? does adding -use_shm 0 help? [01:45:58 CEST] <DHE2> (this will adversely affect performance, just suggesting it as a debug aid) [01:48:36 CEST] <Craytor> DHE2, where would I go and put that? [01:48:43 CEST] <DHE2> before -i like the other option [01:49:19 CEST] <Craytor> It says it's an unrecognized option. [01:51:05 CEST] <llogan> ...if you haven't yet [01:52:31 CEST] <Craytor> http://pastebin.com/Y3qJYfUg [01:53:51 CEST] <DHE2> must be using the xcbgrab variant which does't have that option... sorry [01:55:10 CEST] <Craytor> I don't know why, but OBS won't work either [01:55:32 CEST] <Craytor> Should you be able to use these on a VPS? [01:59:26 CEST] <well0ne> well, now i have the same problem with concatenating, i have 5 streams with each 200 files which works flawless, withouth asynchronit [01:59:58 CEST] <well0ne> but some other files, (they are all having the same settings), are getting async [02:00:09 CEST] <DHE2> I'm using x11grab with Xvnc for over a year now. nigh-flawlessly. it does work [02:34:37 CEST] <well0ne> i concenate 2 files, same x264/mp3 settings, but when it starts with the seconds file, the audio is async/has gone (depends on the player) [02:34:44 CEST] <well0ne> any recommendations? [02:35:14 CEST] <well0ne> i can try to make a sample [02:40:17 CEST] <well0ne> http://mozz.top/sample.ts [02:40:38 CEST] <well0ne> Here is the sample file, concenated the last seconds and the first 20 seconds, there you can see that it get async [02:40:45 CEST] <well0ne> can someone tell me more about it ? [02:45:24 CEST] <well0ne> http://mozz.top/out1.ts and http://mozz.top/out2.ts [02:45:28 CEST] <well0ne> are the sources [02:48:29 CEST] <well0ne> well i think i got it by myself [02:49:02 CEST] <well0ne> the audio stream is 15 seconds longer than it should be [02:49:14 CEST] <well0ne> is there a easy way to fix this? [02:54:42 CEST] <Craytor> DHE2, are you still here? [02:58:21 CEST] <DHE2> intermittently [02:58:43 CEST] <Craytor> What version of Ubuntu are you running? [02:58:56 CEST] <Craytor> What's your VM host as well (if you don't mind)? [03:05:31 CEST] <DHE2> it's centos for me [03:06:39 CEST] <Craytor> Hmm [03:06:41 CEST] <Craytor> Okay [03:07:05 CEST] <Craytor> I don't know what to do to get this working [03:07:06 CEST] <DHE2> and it's bare metal, but no GUI installed [03:07:11 CEST] <Craytor> And you said it works [03:07:29 CEST] <Craytor> Then how can you use ffmpeg to record your screen? [03:08:36 CEST] <DHE2> ffmpeg-x11grab -f x11grab -draw_mouse 0 -s 1280x720 -r 30 -i :1.0 .... [03:08:39 CEST] <DHE2> that's my commandline [03:09:25 CEST] <Craytor> What's it do? [03:10:46 CEST] <DHE2> 30fps of the indicated size [03:11:35 CEST] <Craytor> Yeah, are you recording the terminal or a desktop of something? [03:12:12 CEST] <prelude2004c> hey guys.. i am having trouble getting somethign working with parallel... i am using ffmpeg to output files and then i am using inotifywait to poush those files via ssh [03:12:24 CEST] <prelude2004c> the parallel processes have to happen but its not working well for me [03:13:03 CEST] <prelude2004c> inotifywait -m -e CLOSE_WRITE /var/www/channels/"${CHN}"| while read -r path action file ;do parallel rsync --timeout=20 -vz -e ssh "$path$file" "10.10.10.1":/ramdrive/html/channels/${CHN}/;done [03:13:17 CEST] <prelude2004c> anyone see what is wrong with it? i keep getting zombie processes when i do &done at the end [03:14:16 CEST] <DHE2> use -n on ssh (see man page) [03:17:08 CEST] <Craytor> DHE2 - was that to me? [03:17:41 CEST] <DHE2> no [03:18:20 CEST] <Craytor> ok [03:18:29 CEST] <Craytor> What version of ffmpeg are you using? [03:18:33 CEST] <Craytor> Did you compile it yourself? [03:20:05 CEST] <DHE2> yes, I needed to build it custom becaues it runs on a headless system and I really like git versions [03:20:32 CEST] <Craytor> Okay [03:20:48 CEST] <Craytor> Could you maybe walk me through an install so I can maybe get tthis working/ [03:20:49 CEST] <prelude2004c> oh -n wasn't for me :) [03:21:00 CEST] <DHE2> prelude2004c: it was. you're the one with ssh problems [03:21:11 CEST] <prelude2004c> ssh problems ? no not ssh problems [03:21:14 CEST] <prelude2004c> :) [03:21:27 CEST] <prelude2004c> its a parallel problem actually of rsync of the segmented data [03:22:04 CEST] <prelude2004c> i am sending it off to rsync and ssh but for each inotifywait it has to send a process.. but i dont want to wait for that process to finish before sending another [03:22:19 CEST] <prelude2004c> i had it working but for some reason never closes the process so i get stuck with thousands of defunct messages [03:22:24 CEST] <prelude2004c> i dont know how to fix it [03:22:25 CEST] <DHE2> oh, okay I see... [03:23:21 CEST] <prelude2004c> yup and i don't know enough to fix it myself [03:23:49 CEST] <DHE2> the traditional way is called a double-fork. bit of a pain [03:23:55 CEST] <llogan> doesn't seem like a ffmpeg issue to me [03:35:57 CEST] <Craytor> DHE2 - should OBS work on the VPS or not? [03:43:32 CEST] <DHE2> I don't see why not. what does being in a VM matter? [03:45:58 CEST] <Craytor> There isn't a physical display? [03:46:19 CEST] <Craytor> DHE2 - also, which one of these builds do you recommend? https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu [03:57:32 CEST] <Craytor> I tried this again, and VLC is still playing a black stream [03:57:37 CEST] <Craytor> No content, just black [03:57:38 CEST] <Craytor> no idea [04:18:37 CEST] <Craytor> So for some reason, all ffmpeg is doing is create a video that has no content, it's just a video that has black 24/6 [04:18:41 CEST] <Craytor> *24/7 [04:33:17 CEST] <Craytor> DHE2 - you still here? [05:34:03 CEST] <Craytor> DHE2 - does your vps have a gpu? [05:34:11 CEST] <Craytor> I can't seem to get mine running - still. [08:10:33 CEST] <Guest12368> i want to attach png image mp4 video. [08:10:46 CEST] <Guest12368> using ffmpeg. [08:10:55 CEST] <Guest12368> can anyone help me on that ? [08:11:21 CEST] <Guest12368> i want to attach this png logo at end of video. [08:17:38 CEST] <Boscop> hi, is there a tutorial for processing each frame in a video with a custom filter/effect? [08:53:54 CEST] <Guest12368> Anyone there ? [09:00:08 CEST] <Boscop> Guest12368: yes [09:00:24 CEST] <Boscop> how can i use a custom avfilter with ffmpeg? [09:03:37 CEST] <Guest73378> we want to overlay png image on mp4 video after specific time. we also want to fade in and fade out that png image. [09:03:47 CEST] <Guest73378> does anyone help us on this ? [09:03:57 CEST] <Guest73378> cas anyone help us on this ? [09:04:02 CEST] <Guest73378> can anyone help us on this ? [09:13:10 CEST] <durandal_1707> Boscop: what custom filter? [09:13:23 CEST] <Boscop> durandal_1707: that i wrote [09:13:31 CEST] <Boscop> to process each video frame [09:14:41 CEST] <Boscop> durandal_1707: using avfilter [09:14:41 CEST] <durandal_1707> did you compiled it? [09:15:03 CEST] <Boscop> yes, the question is, how can i "register it" so i can use it with ffmpeg ? [09:15:51 CEST] <durandal_1707> you need to edit allfilters and Makefile in libavfilter/ [09:16:39 CEST] <Boscop> durandal_1707: do i have to compile ffmpeg manually? [09:16:51 CEST] <durandal_1707> yes [09:18:29 CEST] <Guest73378> overlay feature won't help us on this ? [09:19:46 CEST] <durandal_1707> Guest73378: it is possible, read documentation [09:20:00 CEST] <Boscop> Guest73378: https://ffmpeg.org/ffmpeg-filters.html#Description [09:20:09 CEST] <Boscop> the time constraints [09:20:55 CEST] <Boscop> durandal_1707: so every time i add another filter i have to recompile ffmpeg? [09:21:15 CEST] <Boscop> isn't it supposed to be a plugin system? [09:22:41 CEST] <durandal_1707> exactly, open bug report, there is patch somewhere which addresses this [09:23:24 CEST] <Boscop> ah [09:25:01 CEST] <JEEB> Boscop: you have to recompile the parts that are required to be recompiled (the makefiles keep an eye on what stuff has changed and in most cases it works) [09:25:30 CEST] <Boscop> JEEB: on windows should i use mingw or msvc? [09:25:31 CEST] <JEEB> but yes, it requires linking a new avfilter and ffmpeg :P [09:25:53 CEST] <JEEB> Boscop: msys2 + mingw-w64 is probably simplest, if you have MSVC 2013 or 2015 you can use those, too [09:27:20 CEST] <Boscop> JEEB: can i process two video feeds from two usb webcams in real-time using ffmpeg and then stream them? [09:27:50 CEST] <JEEB> depends on a lot of stuff, but I've seen restreaming webcams with ffmpeg :P [09:28:11 CEST] <JEEB> although most of that is on lunix, I have no idea of how it'd be accessed on windows [09:28:23 CEST] <Boscop> JEEB: so i can open multiple usb webcam streams at the same time with ffmpeg? [09:28:33 CEST] <JEEB> there seems to be a dshow input but I have no idea how good it is [09:28:51 CEST] <JEEB> Boscop: you are talking as if there's a single way of doing it :P [09:29:09 CEST] <JEEB> depends on your OS, how stupid your webcams are etc [09:29:51 CEST] <JEEB> I've seen a person on linux using v4l2 grabbing AVC streams from specific USB web cams and restreaming that [09:30:48 CEST] <JEEB> since you mention MSVC it implies that you're on windows. thus, you will have to find out what your options are for grabbing the pictures from the web cam [09:31:06 CEST] <JEEB> as I said, there is a DirectShow input at least, and I remember that some webcams might be DShow inputs [09:31:15 CEST] <JEEB> but as I also said, I have no idea how good that stuff is [09:32:18 CEST] <Boscop> JEEB: i can switch to linux for this. do you have a link to a post of the person who did it on linux? [09:34:12 CEST] <JEEB> it's somewhere in my backlog but I'm lazy to grep my #libav logs :P it should be pretty straightforward if you look at how the v4l2 inputs are used in the ffmpeg documentation [09:34:21 CEST] <JEEB> ffmpeg-all.html in google and then look there :P [09:45:05 CEST] <Boscop> JEEB: thanks. btw, do you know what the easiest way is to align two stereoscopic videos, is there a library for it? [09:45:37 CEST] <Boscop> for timing alignment using audio correlation and vertical alignment etc [09:47:45 CEST] <JEEB> why the hell would you use audio correllation for timing? one would think you'd use timestamps from the camera (implying they are not stupid enough to not have timestamps on their output picture streams) [09:48:06 CEST] <JEEB> and even in that case you could theoretically use the wallclock as the main clock [09:48:52 CEST] <JEEB> for the alignment I have no idea, but if you just want to put two things next to each other libavfilter should have something for that [09:56:37 CEST] <Boscop> JEEB: i'm traveling so i can't use large equipment, i was thinking of recording with two phones next to each other [09:57:20 CEST] <Boscop> which wallclock? [15:47:03 CEST] <mathieu_> Hi, i've got a question about motion_val [15:47:19 CEST] <mathieu_> It's quite stupid :p [15:47:41 CEST] <mathieu_> I want to copy the table, and im a bit confused about the syntax [15:47:57 CEST] <mathieu_> I have this: [15:48:20 CEST] <mathieu_> copy_motion_val = malloc(2 * mb_width * mb_height * 2 * sizeof(int16_t)); [15:49:18 CEST] <mathieu_> is this correct? and what casting do I need for the malloc? [15:49:37 CEST] <mathieu_> it's a really strange structure syntax :p [16:19:49 CEST] <eik> I'm having issues with the trim filter not dropping frames outside the specified range, it rather duplicates them for some reason. Anyone got any ideas on what I'm doing wrong? Command used http://pastebin.com/8pAQZvSY [16:23:51 CEST] <ubitux> from vfr to cfr maybe [16:25:23 CEST] <ubitux> eik: you probably want to -ss and -t [16:27:58 CEST] <eik> ubitux: I was hoping I could get this filter to work as intended. It would be nice to use the start_frame parameter [16:29:43 CEST] <ubitux> eik: trim filters are automatically inserted with ffmpeg [16:29:51 CEST] <ubitux> i wonder if you can see them with -v verbose or something [16:30:01 CEST] <ubitux> (try -v verbose with -ss / -t just in case) [16:30:44 CEST] <eik> I can't use -ss in this case I think, since it's positional (comes before or after -i / -o changes behaviour) [16:31:26 CEST] <eik> Due to how I send arguments to ffmpeg from an external app, this is not an option :/ [16:32:36 CEST] <ubitux> no i mean, just to see how ffmpeg does it [16:32:48 CEST] <ubitux> so you can copy the behaviour [16:33:02 CEST] <ubitux> it looks weird though [16:35:26 CEST] <eik> I tried with -v verbose on the trim filter first. It says "*** 900 dup!" then skips to frame 902 at ~30s in. I'll try -ss with verbose now [16:41:47 CEST] <eik> -ss works as expected, it skips 30s and marks that as the new 00:00:00. While with trim it just duplicates the first 30s and then goes to frame 900 [16:52:05 CEST] <eik> ubitux: Here are the two outputs from trim and -ss. http://pastebin.com/ZPeCgdYq http://pastebin.com/mMeiZQX8 So trim doesn't drop until the start like the docs say, it rather duplicates. [16:53:28 CEST] <ubitux> you might want to add a setpts after the trim [16:54:09 CEST] <ubitux> because triming is not going to adjust the time gap between trim chunks (assuming you have multiple ones, but same if you pick a time in the middle like this) [16:54:39 CEST] <ubitux> so you need to adjust the times of the frame [16:55:27 CEST] <ubitux> i would guess ffmpeg assumes the frame doesn't change (enhance assume vfr) but is trying to output cfr (so it will dup the last frame N times) [16:55:46 CEST] <ubitux> i suppose that's the kind of scenario that's happening [16:56:30 CEST] <ubitux> in your case, maybe a setpts=PTS-STARTPTS would work [16:56:45 CEST] <ubitux> (since you only have one trim and you want to adjust the gap at start time [16:57:20 CEST] <ubitux> so trim=30:45,setpts=PTS-STARTPTS ... maybe :p [17:09:35 CEST] <reza> hi , can i stream live over UDP usnig ffserver? [18:22:22 CEST] <dv__> slightly OT: why do webradio links often offer .pls and .m3u playlists with the actual webradio HTTP link inside, and not just the HTTP link directly? if it is about possible future stream location changes: these could also be taken care of by using a HTTP 302/303 return code [18:27:38 CEST] <ChocolateArmpits> dv__: I guess to support adaptive playback [18:27:46 CEST] <ChocolateArmpits> oh webradio [18:27:50 CEST] <ChocolateArmpits> beats me [19:18:29 CEST] <klaxa> dv__: probably so people can store the playlist on their desktop and double-click it [20:01:25 CEST] <kyleogrg> hi [20:01:54 CEST] <kyleogrg> What's the most painless way to build FFmpeg with libfdk_aac? [20:04:08 CEST] <sfan5> use some kind of build script and modify it to enable fdk-aac (e.g. pkgfile from AUR if you're using arch) [20:13:37 CEST] <kyleogrg> what about windows [20:14:34 CEST] <sfan5> then you're probably out of luck [20:15:15 CEST] <llogan> maybe the zeranoe site has a build script you can modify [20:15:37 CEST] <sfan5> aren't those cross-compiled from linux? [20:15:41 CEST] <llogan> i don't know [20:15:43 CEST] <kyleogrg> Oh? [20:15:45 CEST] <kyleogrg> hmm [20:16:12 CEST] <ChocolateArmpits> kyleogrg: use this guide: http://taer-naguur.blogspot.com/2013/09/compiling-x64x86-ffmpeg-with-fdk-aa… [20:16:46 CEST] <kyleogrg> ChocolateArmpits: I was about to post something from the same author: http://taer-naguur.blogspot.com/2013/10/ffmpeg-autobuild-tool-x64.html [20:16:46 CEST] <ChocolateArmpits> In the x264 compile options remove --bit-depth=10 or change it to--bit-depth=8 [20:17:23 CEST] <kyleogrg> I actually successfully used that script to build ffmpeg with libfdk_aac... but [20:17:40 CEST] <kyleogrg> I want to build libx265 not libx264 [20:18:14 CEST] <kyleogrg> As a relative novice, I did not know how to adjust the script to do this. Any suggestions? [20:18:31 CEST] <ChocolateArmpits> I'm not familiar with the script [20:19:03 CEST] <ChocolateArmpits> In the step-by-step guide however you will probably need to add --enable-libx265 in ffmpeg's compile options [20:19:13 CEST] <ChocolateArmpits> and precompile x265 [20:19:23 CEST] <ChocolateArmpits> I don't know what options that might have [20:19:38 CEST] <ChocolateArmpits> But the process should be the same [20:19:44 CEST] <kyleogrg> hmm ok [20:19:46 CEST] <sfan5> not really [20:19:52 CEST] <sfan5> x265 uses CMake [20:20:01 CEST] <sfan5> x264 uses a "normal" configure script IIRC [20:20:27 CEST] <kyleogrg> oh [20:20:28 CEST] <ChocolateArmpits> Wouldn't that just need additional binaries ? [20:21:06 CEST] <sfan5> probably [20:21:51 CEST] <kyleogrg> let's say i want to build a "standard" zeranoe ffmpeg. is that easy? then can i do a simple mod to add libfdk_aac? [20:22:16 CEST] <sfan5> it's not that simple [20:22:37 CEST] <BtbN> The zeranoe builds are everything but standard. There's quite a bunch of stuff enabled. [20:22:42 CEST] <sfan5> you'd need to add a "section" to the script that downloads/compiled and install fdk-aac [20:23:28 CEST] <kyleogrg> ok. [20:23:40 CEST] <kyleogrg> i wish it was simpler [20:24:40 CEST] <kyleogrg> i can download zeranoe ffmpeg for libx265. i can use the above-mentioned script for libfdk_aac. but i can't easily have both... [20:29:25 CEST] <kyleogrg> maybe i should try vp9 and opus [20:30:22 CEST] <sfan5> libvpx is slow [20:30:26 CEST] <sfan5> libvpx-vpp9 even slower [20:31:28 CEST] <kyleogrg> yeah.. but in terms of an alternative to x265, it's very competetive, i believe [20:35:29 CEST] <JEEB> lol [20:35:37 CEST] <JEEB> did you drink some google kool-aid? [20:35:45 CEST] <JEEB> if so, I'd like a couple of truckloads of it as well [20:41:16 CEST] <kyleogrg> haha [20:41:46 CEST] <kyleogrg> is x265 more efficient? [20:42:33 CEST] <JEEB> x265 isn't too great but so far it's got better rate control, psychovisual opts, more asm and better threading [20:42:48 CEST] <JEEB> so currently out of the current-gen format encoders it's probably the least retarded [20:43:22 CEST] <kyleogrg> one thing is "-tune grain" didn't work last time i checked [20:43:48 CEST] <JEEB> you shouldn't expect libx264 and libx265 be in any kind similar, since they pretty much aren't [20:44:02 CEST] <JEEB> there are some similarly named features and things that kind of do similar things [20:44:06 CEST] <kyleogrg> yeah, but i think this is an option in x265 [20:44:43 CEST] <ChocolateArmpits> JEEB: wouldn't it be smarter to add a hack multithreading for vp9 that would render several segments parallellely and then concatenate them ? [20:44:43 CEST] <JEEB> yeah, it is. I think with libx265 the decision was made that you're supposed to use an option that takes in API options instead of having o9k global options [20:45:20 CEST] <sfan5> -x265_params iirc [20:45:23 CEST] <sfan5> or maybe with a - [20:45:29 CEST] <sfan5> or param without s [20:45:32 CEST] <JEEB> because it gets at times a bit lulz when people try to use various libx264-specific options with other encoders [20:45:33 CEST] <sfan5> i can never remember that [20:45:49 CEST] <JEEB> ChocolateArmpits: you could do the same with encoders too and gain with it [20:45:57 CEST] <JEEB> if you aren't doing live encoding that is [20:46:06 CEST] <kyleogrg> do you think libopus is more efficient/better than libfdk_aac? [20:46:37 CEST] <sfan5> turns out it's -x265-params [20:46:46 CEST] <ChocolateArmpits> JEEB: well yeah, but if Google isn't ready to add proper multithreading until some time later, this can be a shortterm solution for offline video [20:46:46 CEST] <JEEB> I am all for opus vs aac [20:47:01 CEST] <JEEB> if only your clients support opus, go for it [20:47:15 CEST] <JEEB> you can distribute binaries with libopus so it even makes that thing a non-problem [20:47:49 CEST] <kyleogrg> well, i wonder if i should try libx265+libopus for maximum efficiency [20:50:06 CEST] <ChocolateArmpits> kyleogrg: try for lowest bitrate as a challenge [20:50:14 CEST] <ChocolateArmpits> as in sub-500kbps [20:51:02 CEST] <kyleogrg> yeah [20:53:04 CEST] <kyleogrg> i wanted to try an experiment. i have a 60-minute video which i want to convert to a 60 MB (!) video [20:53:50 CEST] <ChocolateArmpits> what genre ? [20:53:53 CEST] <kyleogrg> let's say it's basically a dvd-quality source [20:53:56 CEST] Action: JEEB is reminded of the floppy sized animation episodes [20:54:07 CEST] <JEEB> 24min in 1.44MB [20:54:15 CEST] <kyleogrg> wow [20:54:27 CEST] <ChocolateArmpits> tell us more [20:54:39 CEST] <ChocolateArmpits> was that text animation or something ? [20:54:55 CEST] <ChocolateArmpits> or sprites ?? [20:55:16 CEST] <JEEB> animoo basically [20:55:34 CEST] <JEEB> not action but still somewhat animated. + x264 is very good at keeping your rate [20:55:34 CEST] <ChocolateArmpits> so a slideshow ? [20:55:50 CEST] <kyleogrg> basically i want to convert a video archive into a *proxy* video archive that will fit on a thumb drive. so i want the maximum quality given the limited file space. [20:56:33 CEST] <BtbN> Isn't x264 currently still better for low resolutions/bitrates? [20:56:34 CEST] <sfan5> 2-pass encoding is what you want [20:56:41 CEST] <kyleogrg> Let [20:56:43 CEST] <ChocolateArmpits> kyleogrg: 136kbps average overall allowed at 60min/60MB [20:57:01 CEST] <kyleogrg> Let's say I want to fit 1,000 hours of DVD video on 60GB. [20:57:11 CEST] <kyleogrg> Which I know is very small. [20:57:14 CEST] <ChocolateArmpits> BtbN: last I saw x265 was better, if that tears of steel video isn't borked [20:57:40 CEST] <ChocolateArmpits> from my personal experience at 400kbps only SD conference videos hold up [20:57:50 CEST] <ChocolateArmpits> with x264 [20:58:03 CEST] <kyleogrg> That's 61.44MB per minute. So...? [20:58:47 CEST] <kyleogrg> So x264 is better than x265 at low bitrates? [20:59:24 CEST] <ChocolateArmpits> well, I wouldn't argue codecs specifically but standards [20:59:38 CEST] <ChocolateArmpits> so h265 is better than h264 at lower bitrates [20:59:53 CEST] <BtbN> Of course h265 is in theory better. But there currently is no implementation that's able to make use of it. [21:00:41 CEST] <kyleogrg> BtbN: I'm not sure what you mean... If I use libx265 on placebo, won't that be better than libx264? [21:01:31 CEST] <BtbN> Depends, for 4K stuff, yes, very likely [21:01:39 CEST] <BtbN> for targeting low res/bitrate, i don't think so [21:01:47 CEST] <ChocolateArmpits> check these out [21:01:48 CEST] <ChocolateArmpits> https://x265.com/hevc-video-files/ [21:01:54 CEST] <ChocolateArmpits> supposed comparisons [21:02:25 CEST] <ChocolateArmpits> I wouldn't go by images alone [21:02:57 CEST] <Daan_> Hi, Could you guys release compiled versions for Unix in the future? [21:03:20 CEST] <kyleogrg> before i dig into comparisons online, what's your opinion offhand? that libx264 is better right now for low bitrate? [21:03:47 CEST] <llogan> Daan_: http://johnvansickle.com/ffmpeg/ [21:03:53 CEST] <BtbN> Daan_, your distribution most likely packages ffmpeg or at least libav for you. [21:04:00 CEST] <BtbN> For more than that, compile it yourself. [21:04:22 CEST] <ChocolateArmpits> kyleogrg: I haven't tried x265 but at those bitrates x265 beats x264 [21:04:40 CEST] <kyleogrg> you mean high bitrates? [21:04:52 CEST] <ChocolateArmpits> low bitrates [21:04:59 CEST] <ChocolateArmpits> literally sub-500kbps [21:05:01 CEST] <kyleogrg> ok [21:05:26 CEST] <ChocolateArmpits> anything higher and I'm getting my doubts if it's worth it [21:05:45 CEST] <kyleogrg> given my goal (tiny video proxies), I wonder if I should reduce the frame rate to put more quality into each frame [21:06:43 CEST] <ChocolateArmpits> kyleogrg: well it will speed up encoding [21:06:56 CEST] <kyleogrg> i could go from 30p to 15p, for instance. i wonder if that will still be watchable [21:07:42 CEST] <ChocolateArmpits> From my experience the smaller the viewing window the less noticeable low fps rate is [21:08:05 CEST] <kyleogrg> watchable enough to say "hey, that's a good clip. i want to get the original and use it in my project." [21:08:05 CEST] <ChocolateArmpits> especially for static scenes [21:08:26 CEST] <kyleogrg> yeah [21:08:48 CEST] <kyleogrg> this is all sorts of scenes - some static, some random [21:12:21 CEST] <kyleogrg> what about 30p (30 frames) vs. 30i (15 frames, 30 fields)? [21:13:07 CEST] <kyleogrg> instead of having 15 progressive frames, what if i had 30 fields? [21:13:27 CEST] <kyleogrg> wouldn't the motion be smoother? [21:14:00 CEST] <sfan5> ugh interlacing [21:15:46 CEST] <kyleogrg> haha [21:16:02 CEST] <kyleogrg> but i have a unique situation [21:16:56 CEST] <ChocolateArmpits> I would suggest against non-standard practises [21:17:13 CEST] <ChocolateArmpits> technically it would better to call it 15i [21:17:38 CEST] <ChocolateArmpits> besides interlacing flags need additional bitrate [21:18:01 CEST] <ChocolateArmpits> I don't know if x265 codes the field separately or no [21:18:21 CEST] <kyleogrg> uh-huh. would a 15p video be much smaller than a 15i? [21:19:22 CEST] <ChocolateArmpits> can't say by how much [21:21:19 CEST] <niknok> does ffmpeg accepts a subtitle file in .pac format? [21:53:09 CEST] <Rayne> Hello *, I have a problem with the filter "overlay" with a looped image and a video file. Both ffmpeg (Windows) and avconv (Linux) don't stop processing after the "shortest video" is processed. [21:53:19 CEST] <Rayne> Source: http://nopaste.linux-dev.org/?665597 [21:53:56 CEST] <Rayne> Example 2 returns a "Undefined constant or missing '(' in 'shortest=1'" error [21:55:23 CEST] <Rayne> Do you have an idea? [21:57:47 CEST] <pzich> I think you'll have better luck in an avconv-specific channel [22:04:40 CEST] <llogan> or show the real ffmpeg command and complete console output. [22:04:55 CEST] <llogan> otherwise you'll have to go to the avconv echo-chamber [22:06:55 CEST] <kyleogrg> ffmpeg won't let me use "-ar 22050" for libopus [22:07:03 CEST] <kyleogrg> it complains [22:08:13 CEST] <JEEB> opus is a wee bit special regarding that kind of stuff. so just don't set an audio rate [22:08:22 CEST] <kyleogrg> "Error while opening encoder for output stream #0:1 - maybe incorrect parameters such as bit_rate, rate, width or height" [22:08:25 CEST] <kyleogrg> oh? [22:09:10 CEST] <llogan> that's not a supported sample rate, but as JEEB said... [22:09:28 CEST] <kyleogrg> then if i want to reduce the audio file size, what can i do [22:09:35 CEST] <JEEB> just set the audio bit rate [22:09:38 CEST] <kyleogrg> just set the bitrate, i guess [22:09:39 CEST] <JEEB> or quantizer [22:09:52 CEST] <kyleogrg> is quantizer the quality setting? [22:10:16 CEST] <JEEB> do not mistake quantizer for quality :P [22:10:35 CEST] <kyleogrg> does "-vbr on" work? [22:11:10 CEST] <llogan> there is a -vbr private option. see "ffmpeg -h encoder=libopus" [22:13:00 CEST] <kyleogrg> hmm. so is -vbr 0 to -vbr 2 a quality setting? [22:14:32 CEST] <kyleogrg> oh. 0 = off. 1 = on. 2 = constrained. [22:14:54 CEST] <Rayne> llogan, PEBKAC. Thank you. No problem with ffmpeg. :-) [22:42:03 CEST] <kyleogrg> for 2-pass encoding, i'm supposed to do "-f mp4 NUL && \" (windows). however, i am encoding an mkv file. should i replace "mp4" with "mkv"? [22:43:38 CEST] <JEEB> format takes in formats, see a list of them with `ffmpeg -formats` [22:44:37 CEST] <kyleogrg> okay. so i guess i will do "matroska" [22:47:47 CEST] <kyleogrg> ffmpeg automatically optimizes threads right? that is, it will use all cores by default? [23:41:50 CEST] <llogan> kyleogrg: depends on the encoder (I'm assuming you're referring to encoding) [23:42:16 CEST] <kyleogrg> yes. libx265 [23:45:40 CEST] <llogan> i would guess it does [23:45:58 CEST] <kyleogrg> ok [23:53:05 CEST] <kyleogrg> when encoding, how can i scale video res to 33% of original size? [23:53:56 CEST] <llogan> -vf scale=iw*0.3333333333333333333333333333333333333333 [23:54:20 CEST] <llogan> eh, well, you get the idea [23:54:32 CEST] <kyleogrg> ok, actually it's a bit more complicated. how can i first convert to square pixels, and then get 33% of the size.... [23:55:33 CEST] <kyleogrg> the source is a non-square-pixels, 720x480 vid. so it needs to become 640x480, and then 33% of that. [23:55:50 CEST] <llogan> if you're lazy use two scales [23:55:58 CEST] <kyleogrg> i know that this will convert to square pixels: scale=iw*sar:ih [23:56:21 CEST] <kyleogrg> lazy is fine if it works... [23:56:26 CEST] <Nolski> Cant you just create a filter graph? [23:56:35 CEST] <kyleogrg> idk what that is [23:57:20 CEST] <Nolski> -filter_complex "scale=iw*sar:ih; scale=iw*0.3333333" [23:57:33 CEST] <kyleogrg> llogan: would this work? -vf "scale=iw*sar:ih,scale=iw*0.3333...." [23:58:07 CEST] <llogan> iw*<your desired value>:-1 [23:58:10 CEST] <kyleogrg> Nolski: okay. [23:58:23 CEST] <llogan> or iw*<whatever>:ih*<whatever> [23:58:54 CEST] <Nolski> ^ right what he said [23:59:57 CEST] <kyleogrg> bit confused. source, which is 720x480, should become 640x480, which should become 211x158 (33%). [00:00:00 CEST] --- Wed Aug 5 2015

1 0

ffmpeg-devel.log.20150803
by burek 04 Aug '15

04 Aug '15

[00:00:21 CEST] <nevcairiel> j-b: qsvdec_mpeg2 isnt that much longer in libav either, although a bit logner indeed, but the common qsv code in theirs is just smarter [00:00:42 CEST] <j-b> it's over 100LoC more [00:00:56 CEST] <j-b> and it's actually doing stuff in flush [00:00:56 CEST] <nevcairiel> yeah but thats only the input packet buffering [00:01:30 CEST] <nevcairiel> the point is, all the hard work happens in common code for both decoders [00:01:36 CEST] <nevcairiel> the one we have just is broken [00:01:47 CEST] <wm4> I don't know qsv, but connecting the sync API with the async decoder was incredibly tricky with mmal [00:01:50 CEST] <j-b> I mean, I wish the QSV API was that simple. [00:01:53 CEST] Action: Daemon404 is so happy he doesnt use any hw stuff [00:02:09 CEST] <j-b> but what I remember from the encoder in VLC, it was not. and it was very tricky. [00:02:23 CEST] <j-b> maybe the decoder is really simpler, but I doubt it [00:02:24 CEST] <michaelni> please report the issues to ivan, slandering him behind his back is completely destructive and wont solve anything [00:03:05 CEST] <wm4> <Daemon404> [22:54] <+nevcairiel> i tried to review them [00:03:05 CEST] <wm4> <Daemon404> [22:54] <+nevcairiel> but it was ignored [00:03:26 CEST] <nevcairiel> i should actually build the latest code with qsv support and see how badly i can break things [00:03:39 CEST] <nevcairiel> shouldnt be hard [00:03:47 CEST] <michaelni> wm4, please ping the issues then if something was ignored [00:04:58 CEST] <michaelni> nevcairiel, if you can test, please do and report (to the ML) what all is broken/not working [00:05:06 CEST] <nevcairiel> In any case, should not merge more "decoders" from him until the issues with the core are resolves, i'll test and send a report tomorrow [00:07:23 CEST] <nevcairiel> from the looks of it, a frame size change will likely result in a crash too [00:07:29 CEST] <nevcairiel> but i'll test that tomorrow [00:07:59 CEST] <michaelni> please do and take your time, i wont apply the mjpeg one till these questions are resolved [01:47:05 CEST] <BBB> Gramner: re stack alignment change, its somewhat involved and I have to admit Im intrigued by it because I wrote the original version - is there a trivial explanation for what the changes are related to in general? is it just a different way of impleenting the same thing, or were there bugs in the original version? [01:55:46 CEST] <cone-962> ffmpeg 03Emanuel Czirai 07master:7ab1c57a64b6: libavcodec/aacdec_template: Use init_get_bits8() in aac_decode_frame() [01:55:47 CEST] <cone-962> ffmpeg 03Michael Niedermayer 07master:7f46a641bf25: avcodec/aacdec: Fix integer overflow in argument to decode_audio_specific_config() [03:40:54 CEST] <cone-962> ffmpeg 03Henrik Gramner 07master:f151fbd9e58c: x86inc: Disable vpbroadcastq workaround in newer yasm versions [04:09:42 CEST] <cone-962> ffmpeg 03Henrik Gramner 07master:127203ba5a0b: x86inc: Various minor backports from x264 [04:59:03 CEST] <prelude2004c> hello .. looking for a good developer to incorporate verimatrix DRM into segmenter.c [05:34:57 CEST] <prelude2004c> hey guys... need some asssistance [05:35:03 CEST] <prelude2004c> anywhere around? [05:35:14 CEST] <Compn> kinda [05:35:18 CEST] <Compn> but sleeping now prelude2004c [05:35:22 CEST] <prelude2004c> it relates to the segment outputs of ffmpeg..i did the segmenting and it looks right and generates the data correctly [05:35:43 CEST] <Compn> prelude2004c : ask on the mailing list for devels, not all of them are on irc [05:35:52 CEST] <prelude2004c> problem is .. i have 30 chunks ( 3 seconds each ) .. and when i playback through VLC it doesn't start at 00000.ts .. it jumps right to near end of the stream ( realtime ) [05:58:31 CEST] <prelude2004c> i am having a problem i can't seem to figure out... i have an index file ( m3u8 ) with 30 segments ( each with 3 second chunks ) .. eg.. file_0000001.ts , ..000002.ts, etc etc .. for some reason everytime i pull up vlc [05:58:32 CEST] <prelude2004c> and try to play the stream .. it starts up near the end or somewhere else but never at the first segment .. i don't undersatnd wh [10:26:37 CEST] <cone-756> ffmpeg 03Sebastien Zwickert 07master:11d923d41412: avcodec: add new Videotoolbox hwaccel. [10:40:37 CEST] <ubitux> anyone with a OSX knows where the "Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1" crap comes from when running configure? [10:46:30 CEST] <Shiz> lessee [10:46:58 CEST] <Shiz> i think it's gcc/clang [10:48:00 CEST] <Shiz> ++ gcc --version [10:48:01 CEST] <Shiz> ++ head -n1 [10:48:03 CEST] <Shiz> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 [10:48:05 CEST] <Shiz> sh -x is useful [10:48:23 CEST] <Shiz> i'd suggest adding 2>/dev/null to the gcc --version invocation to make that useful [10:48:37 CEST] <Shiz> it prints that configured line to stderr [10:51:41 CEST] <ubitux> alright, thanks [10:52:01 CEST] <ubitux> indeed i should have sh -x... derp [10:52:20 CEST] <Shiz> line 3535 is where the change is needed [10:52:33 CEST] <Shiz> in v2.7.2 [10:53:01 CEST] <ubitux> feeling like sending a patch? :) [10:53:05 CEST] <Shiz> sure [10:53:54 CEST] <ubitux> great, thanks [12:22:09 CEST] <Shiz> posted [12:32:48 CEST] <BBB> nevcairiel: could you test [PATCH 1/4] x86inc: Support arbitrary stack alignments on msvc-32bit? [12:32:53 CEST] <BBB> (or anyone, for that matter) [12:32:58 CEST] <BBB> if its tested, its ok [12:33:34 CEST] <nevcairiel> in a couple hours [14:19:23 CEST] <j-b> "seeking is broken" <= no way? [14:21:21 CEST] <Compn> Daemon404 : bluray have 1080 mpeg2 last i checked. [14:21:31 CEST] <nevcairiel> i was asked to document it on the ML, so i took the major issues and put them there, either it gets fixed now, or he'll disappear and we get to fix it ourselves =p [14:22:13 CEST] <Compn> if you guys continue to harass NEW developers and would rather rm all of their work instead of fix it, you realize that we will never get any more new developers/contributors, right ? [14:22:24 CEST] <Compn> j-b : really i expect better from you [14:22:52 CEST] <Compn> its not like ffmpeg-mt was perfect in the first commit or anything [14:22:59 CEST] <Compn> nor anyones' first work [14:23:07 CEST] <nevcairiel> Compn: the point is, his patches made things much worse [14:23:11 CEST] <nevcairiel> it was OK [14:23:13 CEST] <nevcairiel> then it got worse [14:24:04 CEST] <Compn> i understand [14:24:22 CEST] <j-b> Compn: sorry, but no. [14:24:23 CEST] <Compn> i'm not even saying it should have been committed [14:24:45 CEST] <j-b> Compn: I explained why those were wrong, and even _I_ could see it could not work. [14:24:47 CEST] <Compn> i'm just addressing the attitude displayed to new developers [14:24:57 CEST] <j-b> new developers? [14:25:07 CEST] <nevcairiel> j-b: do you have a minute to delete the funky branch i pushed to the ffmpeg repo accidentally? its called "cf1ccfffa4b72d6dc39ea8a04bc391a4ff268fb8" ... :d [14:25:17 CEST] <nevcairiel> Compn: he is a paid drone, but yeah [14:25:19 CEST] <j-b> He's a paid-by-Intel developer that is stealing lu_zero's work and doing it badly. [14:25:50 CEST] <Compn> you are saying paid drones cant/wont be contributors in the future [14:26:08 CEST] <Compn> i have not investigated into stealing allegations, of course i dont agree with that [14:26:21 CEST] <j-b> I'm saying merging features just to not merge libav's, because of hatred, is stupid [14:26:32 CEST] <Compn> sure, i can agree with that [14:26:40 CEST] <Compn> ask nevcairiel to revert and merge libavs then [14:26:48 CEST] <nevcairiel> libavs was merged [14:26:56 CEST] <Compn> or revert intel until its fixed [14:26:58 CEST] <j-b> nevcairiel: there is no branch like this :) [14:27:07 CEST] <nevcairiel> thanks j-b [14:27:08 CEST] <j-b> nevcairiel: there was never a branch named like this :) [14:27:18 CEST] <Compn> nevcairiel : it might be on your local checkout only.. [14:27:19 CEST] <j-b> and those droids are not the ones you are looking for. [14:27:24 CEST] <j-b> :D [14:27:29 CEST] <nevcairiel> Compn: he is just making jokes [14:27:36 CEST] <j-b> ouch [14:27:41 CEST] <Compn> ah [14:27:43 CEST] <nevcairiel> but he did remove it [14:27:45 CEST] <nevcairiel> so yay [14:27:45 CEST] <j-b> I'll tag </s> and </j> [14:27:53 CEST] <Compn> sorry , its early here [14:28:02 CEST] <ubitux> /nick j-k [14:28:29 CEST] <nevcairiel> i figured out how that problem happened in the first place, so i better not do that particular push mistake in the future [14:28:59 CEST] <ubitux> so what's the story with qsv? [14:29:17 CEST] <ubitux> ah there is a summary on the ml [14:29:33 CEST] Action: Compn hides under his rock [14:30:01 CEST] <nevcairiel> in short, libav decoder was merged and worked fine for h264-only at first, some paid-by-intel developer showed up and started patching the ffmpeg version, breaking half of it in the process [14:30:35 CEST] <nevcairiel> but as long as we stop merging new features from him until its all fixed again, we can hopefully remedy it [14:30:40 CEST] <ubitux> what did he do, or tried to do? [14:30:50 CEST] <nevcairiel> adding more codecs [14:30:50 CEST] <ubitux> adding more codecs? [14:30:55 CEST] <ubitux> that's all? [14:31:08 CEST] <nevcairiel> his code refactoring failed [14:31:11 CEST] <nevcairiel> for now thats all [14:31:14 CEST] <ubitux> ok [14:31:17 CEST] <nevcairiel> i think he wants to add post-processing features [14:31:31 CEST] <ubitux> is qsv usable on linux [14:31:33 CEST] <ubitux> ? [14:31:34 CEST] <Compn> i think it would be neat to have mjpeg hwaccel , but thats just me :P [14:31:45 CEST] <nevcairiel> ubitux: yes, if you use lucas mfx library [14:31:55 CEST] <nevcairiel> (https://github.com/lu-zero/mfx_dispatch) [14:32:14 CEST] <ubitux> ok [14:32:23 CEST] <nevcairiel> not sure official intel sdk has linux support yet [14:32:25 CEST] <nevcairiel> but maybe it does [14:32:38 CEST] Action: nevcairiel doesnt know nor care [14:32:55 CEST] <Compn> intel should give us some chips to test these with :P [14:33:19 CEST] <BBB> poor intel people [14:33:21 CEST] <nevcairiel> there is even software emulation, at least on windows, you dont necessarily need hardware support [14:33:27 CEST] <BBB> I had a chat with one of them at the webm summit [14:33:39 CEST] <Compn> nevcairiel : well, i want to benchmark :P [14:33:51 CEST] <[-T-]> i am using it under linux [14:33:55 CEST] <[-T-]> it works but it's a pain to setup [14:34:35 CEST] <ubitux> what's the reason to have that code in a lib btw? c++ only? [14:34:49 CEST] <Compn> instead of where? kernel ? [14:34:54 CEST] <Compn> or put in ffmpeg ? [14:34:58 CEST] <ubitux> instead of ffmpeg obv [14:35:08 CEST] <nevcairiel> that library is c++ yes, but its only a small dispatcher library that loads the intel binary plugins [14:35:11 CEST] <ubitux> or libav fwiw [14:35:16 CEST] <nevcairiel> the code is from the intel sdk [14:35:16 CEST] <Compn> probably so other things can use it i guess [14:35:22 CEST] <Compn> also binary. [14:35:22 CEST] <nevcairiel> slightly adapted for easier building [14:35:29 CEST] <ubitux> nevcairiel: ok [14:35:34 CEST] <nevcairiel> might be license problems to include it directly [14:35:35 CEST] <nevcairiel> also, bloat [14:35:36 CEST] <Compn> and so we dont have to maintain it [14:35:36 CEST] <nevcairiel> .D [14:35:43 CEST] <ubitux> ok [14:35:50 CEST] <Compn> wm4 : someone is thinking about bloating ffmpeg, get out here and tell him not to! :P [14:36:04 CEST] <ubitux> just asking to check if the sole reason would be c++ (because iirc libav doesn't allow it, while we ended up tolerating it) [14:36:13 CEST] <nevcairiel> its quite a bit of code, too [14:36:14 CEST] <Compn> fair enough, good question. [14:36:31 CEST] <Compn> i think we had similar argument about vaapi or some other api [14:36:31 CEST] <nevcairiel> and considering its practically 1:1 from the Intel SDK, keeping it separate is probably ok [14:36:43 CEST] <Compn> s/api/hwaccel [14:36:54 CEST] <nevcairiel> i think luca added the linux module in his fork there [14:36:54 CEST] <ubitux> nevcairiel: yeah ok [14:37:42 CEST] <nevcairiel> ok then lets test the asm thing for bbb [14:38:04 CEST] <[-T-]> the biggest pain to me is to have to patch the i915 module [14:38:13 CEST] <[-T-]> i had to go back to kernel 3.14 to use it [14:38:45 CEST] <ubitux> (so nevcairiel is our new leader? @_@) [14:38:51 CEST] <nevcairiel> nah [14:39:02 CEST] <nevcairiel> i'm way too lazy to lead anyone [14:40:47 CEST] <Compn> no leader, maybe we should split leader duty into different jobs [14:41:37 CEST] <Compn> e.g. one person to resolve technical conflicts/reverts , then one person to handle policy conflicts? i dunno [14:42:56 CEST] <BtbN> idealy more than one person, so someone can actualy take a break without stuff falling apart [14:44:51 CEST] <nevcairiel> I'm just trying to help out a bit, I was asked before but didn't really have the time at the time, so.. [14:46:14 CEST] <cone-236> ffmpeg 03Michael Niedermayer 07master:77fb14f03903: avcodec/rawenc: Use ff_alloc_packet2() [14:46:14 CEST] <cone-236> ffmpeg 03Michael Niedermayer 07master:fdc2385ca96c: avcodec/libwebpenc_animencoder: Use ff_alloc_packet2() [14:46:14 CEST] <cone-236> ffmpeg 03Michael Niedermayer 07master:4302a9283531: avcodec/pcm: Better min_size for ff_alloc_packet2() [14:49:06 CEST] <wm4> <Compn> wm4 : someone is thinking about bloating ffmpeg, get out here and tell him not to! :P <- I'm not sure what you're trolling about now, but this QSV disaster is a good example how adding new features breaks shit [14:51:08 CEST] <nevcairiel> the worst part is that its just a function of impatience [14:51:21 CEST] <nevcairiel> as libav is working on the same things [14:51:40 CEST] <nevcairiel> (or ignorance of what happens at libav, who knows if that dev even knows they exist) [14:52:16 CEST] <Compn> see you c ould show them libav threads [14:52:25 CEST] <Compn> you guys know its ok to post libav urls on the ffmpeg ml right ? [14:52:26 CEST] <Compn> :P [14:52:47 CEST] <ubitux> if the guys doesn't react, just revert it [14:53:02 CEST] <nevcairiel> he probably will react [14:53:26 CEST] <Compn> and you can totally send the intel guy to libav. theres no reason to duplicate work [14:53:34 CEST] <nevcairiel> the real question is how long until the issues are fixed in a satisfactory manner [14:53:37 CEST] <Compn> and theres no policy banning free speech here... [14:54:06 CEST] Action: Compn wonders if he just talks to himself [14:54:08 CEST] Action: Compn afk bbl [14:54:17 CEST] <Compn> thanks nevcairiel btw :) [14:54:19 CEST] <ubitux> Compn: why are you talking about duplicated work, it's not what it's about [14:54:28 CEST] <nevcairiel> well kind of is [14:54:35 CEST] <Compn> some kind of duplication at least [14:54:36 CEST] <ubitux> isn't he working on top of libav work? [14:54:39 CEST] <nevcairiel> he duplicated a bunch of things that libav changed a week later [14:54:40 CEST] <Compn> if they arent working together. [14:54:54 CEST] <wm4> nevcairiel: haha [14:55:03 CEST] <wm4> nevcairiel: so he literally copied the patches off the Libav ML? [14:55:06 CEST] <nevcairiel> ubitux: he is working on the first version that libav produced, but libav is still continuing their work, now in parallal with the other guy [14:55:19 CEST] <nevcairiel> wm4: they wouldnt be as broken then i would wager [14:55:22 CEST] <wm4> or were these things that Libav changed separate git commits? [14:55:47 CEST] <wm4> because if he copied the patches without attribution, that's a blatant copyright violation [14:55:57 CEST] <nevcairiel> nah i think he tried to do it himself [14:56:03 CEST] <nevcairiel> but result was pretty similar, just more broken [14:56:59 CEST] <nevcairiel> for example, libav uses the avcodec parsers to detett changes in the bitstream, so they can re-init the decoder to handle frame size changes etc [14:57:34 CEST] <nevcairiel> but the guys plans include more codecs than we have parsers for, so instead of building a parser (which libav would've done), he removed the avcodec parser usage and used the media sdk parser instead [14:57:48 CEST] <nevcairiel> ... but now frame size changes are not handled at all anymore :) [14:57:55 CEST] <cone-236> ffmpeg 03Michael Niedermayer 07master:6b0fa73b4d47: avcodec/videotoolbox: Fix bistream typo [14:57:56 CEST] <cone-236> ffmpeg 03Michael Niedermayer 07master:8bdd0dbd60b0: avcodec/videotoolbox: Add missing AV_ prefix to CODEC_ID in comment [14:58:27 CEST] <wm4> nevcairiel: wow that's bad [14:58:45 CEST] <ubitux> michaelni: thx, sorry i didn't notice the AV_ [14:58:52 CEST] <nevcairiel> amazingly it doesnt crash when the frame size increases [14:59:01 CEST] <nevcairiel> the intel thing must validate buffers more than i expected it to [15:01:11 CEST] <nevcairiel> it did give me an excuse to fix my secondary box with an intel gpu in it though [15:07:32 CEST] <ubitux> michaelni: maybe -1 could be a special case where 3rd == 4th arg? i see only two cases so far [15:07:39 CEST] <ubitux> either 0, or 3rd arg duplicated [15:07:48 CEST] <ubitux> (ff_alloc_packet2) [15:07:54 CEST] <nevcairiel> magic values :( [15:07:55 CEST] <thardin> michael resigned? [15:08:02 CEST] <thardin> I feel like I've been living under a rock [15:08:55 CEST] <wm4> must have been a heavy rock [15:12:56 CEST] <michaelni> ff_alloc_packet2 is documented in internal.h, if the docs are shit, tell me and ill fix it in a few hours but please be specific on what is bad so i know what needs to be improved [15:17:07 CEST] <wm4> libavformat/internal.h? [15:17:16 CEST] <wm4> I don't see it there [15:17:57 CEST] <ubitux> codec [15:18:30 CEST] <nevcairiel> that always confuses me as well, for some reason the packet managing functions are avcodec [15:18:36 CEST] <nevcairiel> but i always look in avformat [15:19:05 CEST] <prelude2004c> good morning everyone [15:19:09 CEST] <nevcairiel> but admittedly both make sense [15:19:17 CEST] <nevcairiel> avformat creates and eats avpackets [15:19:20 CEST] <nevcairiel> but so does avcodec [15:19:22 CEST] <prelude2004c> i am using ffmpeg to segment out the HLS .. [15:19:31 CEST] <prelude2004c> i am having a problem i can't seem to figure out... i have an index file ( m3u8 ) with 30 segments ( each with 3 second chunks ) .. eg.. file_0000001.ts , ..000002.ts, etc etc .. for some reason everytime i pull up vlc and try to play the stream .. it starts up near the end or somewhere else but never at the first segment .. i don't undersatnd why [15:20:04 CEST] <nevcairiel> its probably a live playlist, where the specification says you are supposed to start near the end to stay close to the "live" position [15:20:17 CEST] <prelude2004c> how do i change that ? [15:20:21 CEST] <prelude2004c> so it alwasy uses the first file [15:20:37 CEST] <prelude2004c> but is in a live stream [15:20:54 CEST] <nevcairiel> you probably cant [15:21:09 CEST] <nevcairiel> its the players choice where to start [15:21:09 CEST] <prelude2004c> can't i set with VOD without the END ? [15:22:01 CEST] <nevcairiel> VOD requires an endlist, or its invalid [15:22:27 CEST] <nevcairiel> what you could use is an event playlist, but i dont know how the players react to that specifically [15:23:59 CEST] <prelude2004c> :( [15:25:16 CEST] <nevcairiel> looks like any live playlist is specified for the player to resume near the end [15:25:28 CEST] <nevcairiel> ie. any with no end tag [15:25:54 CEST] <prelude2004c> there has to be a way to tell the players to alwasy start at the top [15:26:17 CEST] <prelude2004c> because that is silly.. i am doing some long distance transfring and on purpose i setup a queue of like 30 files to make sure the playback stays well ahead of the upload [15:26:27 CEST] <prelude2004c> if it starts near realtime .. doens't help me very much :( [15:26:35 CEST] <nevcairiel> thats not what hls is for, i guess [15:26:41 CEST] <prelude2004c> i don't mind the 2 - 3 min delay [15:27:05 CEST] <prelude2004c> any recommendations on how i could take a stream and segment via fiels to play on the other end [15:27:23 CEST] <prelude2004c> the internet is slow .. i mean i can transfer 10 files at once at 100Kbit/s each .. but i can't transfer 1 file at 1Mbit/s each [15:27:35 CEST] <wm4> michaelni: I have no idea what the min_size parameter does [15:27:38 CEST] <prelude2004c> so it queues and i send them all one by one for example.. and within 10 seconds all files show up at once [15:28:05 CEST] <BtbN> what kind of broken connection is that? [15:29:37 CEST] <prelude2004c> its silly from canada / china [15:29:38 CEST] <kierank> Compn: no offence but you are just confusing this guy about pcm_s24le [15:29:43 CEST] <kierank> it's clearly integer [15:29:46 CEST] <prelude2004c> the latency causes slow upload [15:29:56 CEST] <prelude2004c> but i can do multiple simultaniously [15:30:29 CEST] <prelude2004c> hey what is the difference between segment_list_flags +live and segment_list_flags live [15:31:21 CEST] <prelude2004c> maybe there is some way for me to select vod without an endlist [15:33:19 CEST] <nevcairiel> that would be an invalid list, and may not change the behavior of players [15:33:36 CEST] <nevcairiel> for example, ffmpegs logic is simple, if the list is not finished, it'll pick one close to the end [15:33:39 CEST] <nevcairiel> no matter if vod or not [15:33:55 CEST] <BtbN> so.. just use udp streaming and the latency shouldn't matter? Might run into massive packet loss then though [15:33:58 CEST] <nevcairiel> which makes perfect sense, since vod lists are supposed to be finished [15:36:01 CEST] <prelude2004c> ya can't use UDP . huge packet loss [15:36:23 CEST] <BtbN> well, you can't realy get a stable stream in that situation [15:36:27 CEST] <prelude2004c> the only solution to my problem is to buffer the data there in terms of files. and for each segment send the file ( eg. 3 second files ) to the destination one by one [15:36:34 CEST] <BtbN> something like rtmp might work best [15:36:35 CEST] <prelude2004c> and send them all at the same time if we have to [15:36:47 CEST] <prelude2004c> rtmp wouldn't work iether i don't think [15:36:53 CEST] <prelude2004c> not with packet loss [15:37:12 CEST] <BtbN> you just want to transmit a video file, or what are you trying to do? Or a live stream? [15:37:50 CEST] <prelude2004c> i like the logic of... queue 30 files... send one and if its not finished its ok send the other.. and then there may be 10 files uploading at a time.. thats ok because as long as the customer never catches up to the realtime files they will never reach the end where there is a problem [15:37:56 CEST] <prelude2004c> live stream [15:38:02 CEST] <prelude2004c> vod would be easy [15:38:06 CEST] <prelude2004c> but what i need to do is a live stream [15:38:45 CEST] <BtbN> none of the protocols in existance would handle that situation [15:38:59 CEST] <prelude2004c> yup i know.. so that is why i am tryign to do it differnetly :) [15:39:11 CEST] <prelude2004c> so really i may have to adjust a player and customize it ? [15:39:16 CEST] <prelude2004c> like an open source player or something [15:39:45 CEST] <nevcairiel> ffmpegs hls demuxer has an option that lets you specify from which segment to start [15:39:55 CEST] <nevcairiel> but you still need a player to use that option [15:40:10 CEST] <prelude2004c> really what option is that ? vlc doesn't support ? [15:40:17 CEST] <BtbN> that won't make it load multiple segments in parallel [15:40:31 CEST] <prelude2004c> i have the option of " start_number 1 " set but didn't do anything [15:40:38 CEST] <nevcairiel> ie. ffmpeg -live_start_index 0 -i hlsurl .... [15:40:50 CEST] <nevcairiel> or 1, or whatever index it starts with [15:41:00 CEST] <prelude2004c> ahh you mean for playback [15:41:08 CEST] <nevcairiel> of course [15:41:18 CEST] <prelude2004c> ya wont help me though. [15:41:29 CEST] <prelude2004c> the player isn't the problem.. its getting files to the other end on time [15:41:46 CEST] <BtbN> well, the only propper solution for that is fixing your connection. [15:41:51 CEST] <prelude2004c> i have to adjust a player that will play HLS from the beginning if m3u8 ( alwasy beginning of stream ) [15:42:03 CEST] <prelude2004c> can't fix connection [15:42:06 CEST] <BtbN> If you have 50% package loss and multi-second latency, no magic can safe you [15:42:24 CEST] <prelude2004c> latency is 300ms and packet loss is like 20 % [15:42:33 CEST] <BtbN> Use mpeg-ts with strong fec and send it via udp. [15:42:38 CEST] <prelude2004c> but.. i have found that i run parallel uploads and eventually they all show up [15:42:48 CEST] <prelude2004c> if hte queue is large enough, it never shows up [15:42:55 CEST] <prelude2004c> eg.. it takes 10 seconds to upload a 3 second file [15:43:03 CEST] <prelude2004c> if you upload 5 files at once.. it never catches up [15:43:30 CEST] <BtbN> I'm not sure if ffmpeg is able to insert fec data for mpegts though [15:43:46 CEST] <nevcairiel> dont think so [15:44:02 CEST] <kierank> no it can't [15:44:07 CEST] <prelude2004c> you gav eme an idea... what about on the other end.. ffmpeg -i start at index 0 and output to rtmp or something [15:44:10 CEST] <prelude2004c> so the players can use rtmp [15:44:15 CEST] <prelude2004c> its not adaptive but... [15:44:27 CEST] <kierank> and the only standardised fec supports ~20%ish packet loss [15:44:28 CEST] <prelude2004c> at least i can force it locally to be from beginning [15:44:38 CEST] <kierank> you'd have to essentially roll your own if you want more [15:44:43 CEST] <nevcairiel> ffmpeg probably cant even read fec data [15:48:51 CEST] <ubitux> i'm planing to add a lock/condition pthread mechanism in VTB private context to control async mode; not familiar with either apple framework and the ffmpeg accels, does it make sense to do it that way? [15:49:36 CEST] <nevcairiel> dont think any ffmpeg hwaccel has any precendence for that [15:50:38 CEST] <wm4> qsv and mmal connect async decoders with the sync ffmpeg api [15:50:50 CEST] <wm4> (not sure about qsv?) [15:50:53 CEST] <nevcairiel> yeah but not with any thread functions [15:50:59 CEST] <ubitux> i didn't see any cb mechanism in qsv, but i looked very quickly [15:51:03 CEST] <nevcairiel> the API does the syncing without needing threads [15:51:12 CEST] <nevcairiel> (ie. it does threads internally) [15:51:13 CEST] <wm4> it's mostly a data flow issue IMO? [15:51:45 CEST] <BtbN> The nvenc async api uses WinAPI, so i didn't even bother dealing with it. [15:52:15 CEST] <nevcairiel> nvenc is still plenty fast [15:52:21 CEST] <BtbN> it is now [15:52:51 CEST] <nevcairiel> i wonder if these dataflow hacks could also help ubitux's performance woes [15:52:55 CEST] <nevcairiel> or if async is the only answer [15:53:07 CEST] <BtbN> i guess it does the async stuff internaly now [15:53:09 CEST] <nevcairiel> depends how the driver acts i guess [15:53:24 CEST] <BtbN> copying the buffers internaly to system ram when the bandwidth is free [15:53:26 CEST] <BtbN> or something like that [15:53:29 CEST] <prelude2004c> so i am going to try something.. i have the files on the remote side but the problem is the player ... so.. going to try the ffmpeg -live_start_index 0 -i http://localhost/...m3u8 and then -f flv to a local port where people can stream from [15:53:31 CEST] <prelude2004c> that may work [15:53:36 CEST] <nevcairiel> nvidia is pretty good with copying to sysram anyway [15:53:46 CEST] <nevcairiel> they actually use DMA for that so you dont have to use secret sauce to make it fast [15:53:51 CEST] <prelude2004c> can someone tell me what the best output should be ? [15:54:00 CEST] <BtbN> there are various modes in which the buffers can be mapped [15:54:01 CEST] <nevcairiel> intel and amd .. you better have sse4 copy functions handy, or its going to be slow [15:54:10 CEST] <BtbN> SYSTEM_CACHED was the fastest in my tests [15:54:47 CEST] <nevcairiel> even talking generic like in dxva2, when i map a dxva surface for reading, its already in system memory with nvidia, so any plain memcpy is fast [15:54:59 CEST] <nevcairiel> with intel or amd, you directly map the gpu memory [15:55:04 CEST] <nevcairiel> so you have to be careful to access it fast [15:55:13 CEST] <BtbN> it's not even gpu memory in case of intel [15:55:22 CEST] <nevcairiel> well its still slow withotu sse4 things [15:55:34 CEST] <BtbN> yeah, because they use some weird memory type [15:55:41 CEST] <BtbN> but it's in the system memory portion [15:55:45 CEST] <cone-236> ffmpeg 03Hendrik Leppkes 07master:5d324dae114e: dxva2_hevc: properly signal the num_delta_pocs from the SPS RPS [15:56:45 CEST] <nevcairiel> anyway, the point was, nvidia is nice to you and DMA's it into system memory when you arent looking [15:56:50 CEST] <nevcairiel> which is plenty fast [15:57:17 CEST] <BtbN> unless you force it to happen imediately aparently [15:57:26 CEST] <nevcairiel> the only downside, they reserve a DMA buffer in frame size for every surface you use [15:57:30 CEST] <nevcairiel> which can eat memory [15:57:41 CEST] <nevcairiel> especially when handling 4k 10bit in a 32-bit process [15:58:12 CEST] <nevcairiel> BtbN: i guess forcing a sync will break every advantage at some point :D [15:58:26 CEST] <BtbN> 4k would result in 32 buffers beeing used [15:58:34 CEST] <BtbN> that's quite a bit of address space [15:58:35 CEST] <wm4> if I copy back to RAM with system memcpy on vaapi/intel, it usually seems to be ok [15:58:42 CEST] <nevcairiel> why 32 buffers [15:58:49 CEST] <BtbN> because the doc says so [15:59:00 CEST] <nevcairiel> for encoding? [15:59:17 CEST] <nevcairiel> but yeah thats a lot of buffers [15:59:18 CEST] <BtbN> yeah, they basicaly told you how to calculate the buffer count, i just used the exact forumla [16:00:04 CEST] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/nvenc.c;hb=HEAD#l… [16:00:05 CEST] <nevcairiel> wm4: dont know about vaapi, but with dxva2 its butt-slow on intel without the special sse4 instructions [16:00:44 CEST] <nevcairiel> oh its just a small limiter to not exceed memory constraints i guess [16:03:07 CEST] <BtbN> i actualy reduced the count for the later case [16:03:19 CEST] <BtbN> it was 96 in their example [16:03:35 CEST] <BtbN> setting it to a fixed 32 would propably work fine, too [16:03:39 CEST] <nevcairiel> i guess thats the number of frames it can use for look-ahead to some degree? [16:04:03 CEST] <BtbN> it handles keeping frames for look-ahead internaly [16:04:11 CEST] <BtbN> you don't need to bother with that [16:04:33 CEST] <nevcairiel> then its just for parallel encoding? [16:04:34 CEST] <prelude2004c> hey should i use for streaming udp:// or rtmp:// [16:04:40 CEST] <prelude2004c> which is going to be better for a customer playback [16:04:48 CEST] <BtbN> for parallel copying back to sysmem i'd guess [16:04:53 CEST] <nevcairiel> or that [16:05:10 CEST] <BtbN> it propably collects a few frames, and then does one big dma copy, or something like that [16:05:16 CEST] <prelude2004c> or rtp? [16:06:12 CEST] <nevcairiel> if its a singlecast operation (ie 1 user), something using tcp is probably better, but if multiple users are supposed to receive it, low-overhead UDP may have advantages [16:06:51 CEST] <prelude2004c> hum.. [16:07:04 CEST] <prelude2004c> what do you think is the best way for me to do it.. eg [16:07:33 CEST] <prelude2004c> ffmpeg -live_start_index 0 -i http://localhost:8080/channels/source/source.m3u8 -codec copy -f < some local port > [16:07:45 CEST] <prelude2004c> if i can't use m3u8 for playback then i would like to use something else [16:07:50 CEST] <prelude2004c> if ffmpeg can play from beginning its perfect [16:08:08 CEST] <prelude2004c> ffmpeg will do the playback and send it to some other process that the actual vlc will play or stb will play from customer location [16:08:30 CEST] <prelude2004c> i just have to decide on the best output approach [16:08:39 CEST] <prelude2004c> rtmp/ rtp / udp/ etc [16:08:44 CEST] <prelude2004c> not sure which would work the best [16:09:49 CEST] <BtbN> Why exactly are you talking about this in #ffmpeg-devel? [16:10:36 CEST] <prelude2004c> sorry guys.. because i don't know if the ffmpeg guys would know this :( [16:10:43 CEST] <prelude2004c> but its ok i can move there and try [16:12:19 CEST] <BtbN> It's mostly the same people over there, this channel exists to keep user support and ffmpeg development separated. [16:14:23 CEST] <wm4> and the ones only on this channel don't want to deal with user questions [16:16:54 CEST] <ubitux> lol he's still submitting mjpeg stuff [16:19:00 CEST] <prelude2004c> they BtbN you said -live_start_index 0 but doesnt' work .. still starts near the bottom [16:28:37 CEST] <nevcairiel> his quoting style annoys me too, because whatever mail app he uses puts the posters initials there, my mail thing doesnt detect it as quotes and its not displayed properly :( [16:30:22 CEST] <wm4> mine does, amazingly [16:30:49 CEST] <wm4> there are so many ways to quote in email... [16:31:07 CEST] <nevcairiel> surprisingly most tools just use a single > [16:31:26 CEST] <wm4> can't have a single style... too simple [16:31:46 CEST] <nevcairiel> sadly mail headers dont seem to tell me what tool he uses [16:52:06 CEST] <kierank> nevcairiel: his response is hillarious [16:53:01 CEST] <JEEB> lol [16:53:10 CEST] <JEEB> they are all known and in my TODO list :V [16:53:33 CEST] <kierank> BBB: are your vp9 conference slides published anywhere [16:54:09 CEST] <nevcairiel> why does ffmpeg over stdin not work on windows, or am i just too dumb to pipe a ts file in there [16:54:29 CEST] <BBB> kierank: I intend to publish a blog post about it soon'ish [16:54:34 CEST] <BBB> but havent gotten to that yet [16:54:43 CEST] <ubitux> nevcairiel: seeking? [16:54:52 CEST] <nevcairiel> ts shouldnt need seeking [16:55:40 CEST] <nevcairiel> it works a bit, it outputs like one frame [16:55:43 CEST] <nevcairiel> then claims its done [16:55:47 CEST] <nevcairiel> but the file is 4 minutes long [16:55:59 CEST] <Daemon404> ship it [16:58:44 CEST] <Daemon404> "In general all these issues are known and in my todo list. [16:58:45 CEST] <Daemon404> " [16:58:46 CEST] <Daemon404> wat [17:01:18 CEST] <ubitux> Daemon404: "trust me i'm an engineer" [17:01:24 CEST] <ubitux> "i'm pissing in your mouth, no worry" [17:02:00 CEST] <Daemon404> ubitux, are you referring to the engineer song? [17:02:23 CEST] <ubitux> not really, it's just the expression of my huge creativity [17:03:12 CEST] <Daemon404> https://www.youtube.com/watch?v=rp8hvyjZWHs [17:03:56 CEST] <ubitux> didn't know from where the trust me engineer thing was coming from [17:13:50 CEST] <kierank> no it's from dilbert [17:17:59 CEST] <J_Darnley> nevcairiel: does something change stdin/stdout to be "text format"? [17:19:00 CEST] <nevcairiel> they both start out as text format unless someone sets them to binary [17:19:37 CEST] <nevcairiel> but i would think someone would've noticed that long ago in ffmpeg if that wasnt done [17:19:40 CEST] <nevcairiel> wouldnt they... [17:20:02 CEST] <J_Darnley> I would have thought so. [17:21:02 CEST] <nevcairiel> the pipe protocol does call the thing to set it to binary [17:22:04 CEST] <J_Darnley> I don't know what to say then. [17:32:56 CEST] <wm4> what happens if someone writes W text to a binary pipe? [17:34:00 CEST] <nevcairiel> it comes out the receiving end just like it went in? [17:42:20 CEST] <wm4> as utf-16 or what? [17:42:45 CEST] <nevcairiel> its binary, so however it was written n the input [17:42:52 CEST] <nevcairiel> +o [17:43:07 CEST] <nevcairiel> from a windows app, utf16, on linux probably utf32 [17:43:21 CEST] <wm4> I'm asking because windows has separate W APIs [17:43:45 CEST] <wm4> and it's not really clear what would happen if you write text with a W API to a binary pipe, and read them as bytes [19:19:15 CEST] <wm4> haha, gstreamer failed on an obscure ffmpeg API requirement [19:19:27 CEST] <nevcairiel> not using stack avframes isnt that obscure [19:19:37 CEST] <wm4> this one http://cgit.freedesktop.org/gstreamer/gst-libav/commit/?id=30a4a28793f2e0ff… [19:19:41 CEST] <wm4> input padding [19:19:58 CEST] <nevcairiel> the crash quoted in that ticket shows a stack avframe [19:20:04 CEST] <nevcairiel> which is more likely to cause breakage =p [19:20:45 CEST] <wm4> yeah, I'm not sure how this commit is related to the ticket [19:21:06 CEST] <nevcairiel> gst is full of bad api use [19:21:15 CEST] <nevcairiel> although it seems to have been corrected recently [19:21:15 CEST] <wm4> (but I didn't look too hard) [19:21:27 CEST] <nevcairiel> of course this is linux [19:21:32 CEST] <nevcairiel> it takes years for fixes to spread to users [19:21:51 CEST] <wm4> that's not fair... the oldest outdated ffmpeg builds are windows builds [19:21:57 CEST] <wm4> or was that OSX [19:22:16 CEST] <nevcairiel> well with windows its just up to the app you use, so you can just blame the app developers [19:22:28 CEST] <nevcairiel> but the app developer is in full control at all times [19:22:42 CEST] <wm4> except when he needs to support XP [19:22:51 CEST] <nevcairiel> git master still works on xp [19:22:51 CEST] <nevcairiel> :D [19:24:35 CEST] <nevcairiel> but say gst has a new major version out, and all these ff fixes are only in that, then an existing linux install will take ages to get these fixes, because they tend to only spread minor upgrades to existing installs [19:25:06 CEST] <nevcairiel> although that particular ticket seems to be from someone on gentoo, that should be easier for him then [19:44:00 CEST] <cone-236> ffmpeg 03Michael Niedermayer 07master:2ca0ed9cfda2: doc/git-howto: Replace "git push" example by one with dry-run [20:08:48 CEST] <llogan> so, did i miss anything when i left town for a few days? [20:27:27 CEST] <philipl> llogan: tell me about it. [20:28:19 CEST] <nevcairiel> that'll teach you do take days of, in the summer of all times [20:28:56 CEST] <philipl> A grave mistake to make. [20:29:32 CEST] <philipl> So is our official position that we're going to keep going, and that an un-fork is something we'd like but not required for a sustainable future? [20:29:56 CEST] <philipl> I support that but some of the conversations sounded like an un-fork was required to have a future. [20:30:44 CEST] <nevcairiel> some people seem to panic a bit, but if we dont even try to go on, we'll certainly have no future [20:33:23 CEST] <llogan> We have chance to survive make our time. [20:33:40 CEST] <philipl> nevcairiel: agreed. [20:34:09 CEST] <philipl> latest nvidia driver releases finally enables all the missing h264 profiles (but not 444 yet) [20:34:45 CEST] <nevcairiel> i find it fascinating that they can encode more profiles than they can decode now :D [20:35:15 CEST] <philipl> I was told that 444 decode was an intern project that, surprise, didn't reach a shippable state but somehow made it into the release notes for some driver. [20:35:32 CEST] <philipl> But the hardware is capable [20:36:05 CEST] <wm4> did they fix hevc decode yet? [20:36:05 CEST] <nevcairiel> i dont know enough about h264 to know if there is actually different capabilities required for higher chroma profiles, or if its just more chroma data but otherwise just the same [20:36:30 CEST] <philipl> wm4: I don't think so. José apparently committed the change just past the window for this release. [20:37:33 CEST] <philipl> nevcairiel: the high chroma modes are profiles in and of themselves [20:38:20 CEST] <Gramner> chroma in 4:4:4 is basically treated more like luma instead of chroma in 4:2:0/4:2:2 [20:38:20 CEST] <philipl> If we're still talking nvidia, I don't think their hardware supports > 8bit for any h264 - even the 444 profile is 8bit only [20:38:59 CEST] <nevcairiel> yeah high bit depth is another thing entirely [20:39:05 CEST] <philipl> I did learn they have hardware support for 10 -> 8 at the end of the decode path for hevc 10bit [20:39:34 CEST] <nevcairiel> i never tried to do that, as i refuse to commit such crimes [20:39:56 CEST] <nevcairiel> but it can give me full 10-bit out as well, so i also was never tempted to try [20:39:58 CEST] <wm4> philipl: urgh why [20:40:09 CEST] <wm4> philipl: so we get some sort of shitty hardware dithering? [20:40:25 CEST] <nevcairiel> dxva can give you 10-bit surfaces, vdpau not have that? [20:41:06 CEST] <nevcairiel> i never tried what happens when i use 8-bit surfaces and a 10-bit bitstream [20:41:35 CEST] <philipl> vdpau has no 10bit support so without the conversion it would require API changes [20:41:41 CEST] <wm4> vdpau does have API support for high bit depth surfaces, I think [20:41:47 CEST] <philipl> which should happen eventually [20:41:55 CEST] <philipl> wm4: It has support for output surfaces but not video surfaces [20:41:58 CEST] <wm4> hm, or maybe not [20:42:53 CEST] <wm4> the "HIGH_DEPTH" flag in ffmpeg's vdpau API means support for non-4:2:0 subsampling [20:42:58 CEST] <philipl> So the quickest way to expose MAIN_10 is to use the dithering [20:43:12 CEST] <nevcairiel> did you check by any chance if they actually dither? [20:43:20 CEST] <nevcairiel> and not just round? [20:43:56 CEST] <philipl> nevcairiel: I didn't. I could ask [20:45:57 CEST] <wm4> some form if simple dithering seems likely [20:59:25 CEST] <thardin> what fresh hell is j2ki/mxf [21:00:22 CEST] <Daemon404> i = interlaced? [21:00:46 CEST] <thardin> yes [21:01:00 CEST] <thardin> seems it's each field stored as a separate j2k blob [21:02:04 CEST] <nevcairiel> Evil [21:02:37 CEST] <Daemon404> like hevc, kinda? [21:02:39 CEST] <Daemon404> each field is a pic [21:03:00 CEST] <thardin> yeah [21:03:06 CEST] <thardin> nevcairiel: it gets worse [21:03:15 CEST] <thardin> SeparateLines is a thing in MXF [21:03:38 CEST] <wm4> MXF - supports everything, except nothing works [21:03:43 CEST] <thardin> or rather, LineWrapping (compare: ClipWrapping, FrameWrapping) [21:04:11 CEST] <thardin> MXF - creates consulting hours [21:04:38 CEST] <JEEB> oh yes [21:51:18 CEST] <philipl> Anyone else get 'bitcodin' spam? [21:51:40 CEST] <JEEB> it seems to have been pushed around [21:51:47 CEST] <kierank> spam about what [21:51:59 CEST] <JEEB> "Maybe you are interested in testing our encoding service www.bitcodin.com, which encodes video 100x faster than realtime,..." [21:52:02 CEST] <philipl> That one. [21:52:58 CEST] <kierank> because you are on the ffmpeg-ml? [21:53:13 CEST] <philipl> The email claimed it came from github trawling. [21:53:28 CEST] Action: kierank might troll them on twitter [22:00:04 CEST] <philipl> kierank: ask them if just use nvenc on ec2 gpu instances... [22:00:19 CEST] <kierank> probably a slice and dice [22:00:21 CEST] <kierank> or that [22:01:30 CEST] <kierank> https://twitter.com/obencoder/status/628294591129759744 [22:01:31 CEST] <kierank> flame on [22:02:09 CEST] <philipl> hehe. [22:07:01 CEST] <wm4> ff_alloc_packet2 is my new favorite function [22:11:41 CEST] <nevcairiel> I think i got similar spam from some company because i forked googles ExoPlayer repository, trying to sell me some other DASH solutions [22:11:52 CEST] <nevcairiel> i wouldnt know how they otherwise figured out that I use ExoPlayer [22:12:27 CEST] <cone-236> ffmpeg 03James Almer 07master:5750d6c5e9d1: x86: move XOP emulation code back to x86inc [22:12:41 CEST] <nevcairiel> oh [22:12:42 CEST] <nevcairiel> same company [22:12:44 CEST] <nevcairiel> figures [22:12:57 CEST] <JEEB> :D [22:13:11 CEST] <J_Darnley> Well, now I'm just sad that nobody has spammed me yet. [22:13:19 CEST] <rcombs> "you just found a working free solution? Consider paying us!" [22:13:34 CEST] <J_Darnley> Should I get a Github account to receive some? [22:14:40 CEST] <Shiz> bitcodin is only one letter away from bitcoin [22:16:18 CEST] <thardin> I see I'm not the only one who got that spam [22:16:30 CEST] <Daemon404> i got that too [22:16:37 CEST] <nevcairiel> ididnt get their newest one [22:16:41 CEST] <nevcairiel> despite having a ffmpeg repo [22:16:53 CEST] <nevcairiel> but like i said, i got something about DASH a couple days ago [22:17:23 CEST] <thardin> I had in mind to send something like "why, I'd be deliighted to recommended a company that sends unsolicited e-mail to people" [22:17:28 CEST] <Daemon404> their claims are pretty lulz [22:17:40 CEST] <kierank> I didn't get any spam [22:17:47 CEST] <Daemon404> "Video encoding 100x faster than any other encoding service" [22:17:55 CEST] <Daemon404> not 100x realtime [22:17:57 CEST] <Daemon404> 100x ANY service [22:17:58 CEST] <Daemon404> :D [22:18:05 CEST] <JEEB> yup [22:18:41 CEST] <thardin> sometimes I wonder how many bogus companies like that there are [22:18:46 CEST] <nevcairiel> with segmenting its probably possible to do that [22:18:48 CEST] <nevcairiel> but i doubt they do [22:19:00 CEST] <thardin> why would you need that? [22:19:20 CEST] <thardin> like, if you have lots to encode you can just encode each file offline on separate processes [22:19:41 CEST] <thardin> if realtime then 1x realtime etc [22:19:49 CEST] <thardin> (with room to spare ofc) [22:20:51 CEST] <Daemon404> nevcairiel, possible to do whta? [22:20:55 CEST] <Daemon404> any service can do it [22:21:00 CEST] <Daemon404> you cant encode 100x faster than any service [22:21:01 CEST] <Daemon404> ;) [22:21:11 CEST] <nevcairiel> if noone else does it, then its still true [22:21:16 CEST] <nevcairiel> :D [22:21:24 CEST] <Daemon404> and that's already untrue [22:21:40 CEST] <philipl> My email says 100x realtime [22:22:17 CEST] <Daemon404> philipl, their siet says 100x any service [22:22:20 CEST] <Daemon404> site* [22:22:25 CEST] <philipl> hah. [22:22:30 CEST] <BBB> oh yeah I got that email also [22:22:39 CEST] <BBB> its not hard to make something thats 100x faster than anything [22:22:40 CEST] <nevcairiel> so by reflection, any other service only offers realtime? :) [22:22:58 CEST] <BBB> just write a static sps/pps/vps and a static image of size NxN that has no coefficients and does dc prediction [22:23:00 CEST] <BBB> entirely grayscale [22:23:02 CEST] <BBB> superfast [22:23:17 CEST] <BBB> and whenever people complain about quality, just say psnr sucks [22:23:24 CEST] <BBB> easy peasy [22:23:55 CEST] <philipl> https://aws.amazon.com/blogs/aws/build-3d-streaming-applications-with-ec2s-… [22:24:00 CEST] <philipl> I too can start such a service. [22:24:57 CEST] <kierank> 3d [22:24:58 CEST] <kierank> lol [22:28:15 CEST] <Gramner> just write some H.264 headers and output raw yuv as PCM blocks. from and to a RAM-disk. it's really fast AND the psnr is excellent. [22:28:26 CEST] <nevcairiel> lol [22:31:41 CEST] <JEEB> :D [23:39:48 CEST] <philipl> sweet. latest nvidia driver fixes the hevc bug. they updated the release notes [23:52:53 CEST] <wm4> philipl: I wonder what we do about the code disabling it in ffmpeg [23:52:56 CEST] <wm4> maybe just drop it [23:53:29 CEST] <wm4> unless there's the possibility that the broken drivers will be around for a longer time for some reason [00:00:00 CEST] --- Tue Aug 4 2015

1 0

ffmpeg.log.20150803
by burek 04 Aug '15

04 Aug '15

[02:08:04 CEST] <prelude2004c> hello everyone [02:08:24 CEST] <prelude2004c> i am using ffmpeg with segmenter and the m3u8 files are all segmented correctly and in order [02:08:41 CEST] <prelude2004c> odd, when we are playing the files via vlc , it jumps around [02:08:46 CEST] <prelude2004c> anyone know why this could be ? [02:09:00 CEST] <prelude2004c> could it be file times are applicable ? [02:09:40 CEST] <prelude2004c> i dont see why that should be lelavent [02:09:45 CEST] <prelude2004c> relavent* [02:49:19 CEST] <prelude2004c> anyone? [03:00:08 CEST] <DHE> lack of replies usually means nobody knows [03:00:19 CEST] <DHE> I use the ffmpeg hls output format anyway [03:00:58 CEST] <prelude2004c> you do [03:01:09 CEST] <prelude2004c> any issues ? [03:01:35 CEST] <prelude2004c> the stuff is sequenced correcly in the m3u8 .. the odd part is.. i dont now why on the remote server its jumping around all over the place [03:01:40 CEST] <prelude2004c> that part i dont understand [04:33:42 CEST] <Craytor> Hello everyone, is anyone on this late at night? [04:45:34 CEST] <Craytor> If anyone gets this, I currently have ffmpeg set up and it is streaming to twitch. I am trying it with a VNC connection, so I have my monitor/display device set with :1. FFMPEG is streaming and twitch says I'm live, but it is only a black video. Does anyone know how I could get the connection's desktop or at least a firefox window to stream? [04:46:01 CEST] <Craytor> I'm trying to go ahead and set up a 24/7 weather stream (I have a js web app) to youtube. [05:33:58 CEST] <prelude2004c> hello anyone around ? [05:34:06 CEST] <prelude2004c> can anyone tell me a good channel to get some HLS asstance ? [05:59:11 CEST] <prelude2004c> i am having a problem i can't seem to figure out... i have an index file ( m3u8 ) with 30 segments ( each with 3 second chunks ) .. eg.. file_0000001.ts , ..000002.ts, etc etc .. for some reason everytime i pull up vlc and try to play the stream .. it starts up near the end or somewhere else but never at the first segment .. i don't undersatnd why. anyone ? [10:45:40 CEST] <mathieu_> hi [10:47:11 CEST] <mathieu_> i'm trying to modify the avcodec_decode_video2() method, but i'm running into issues because of the ff_thread_decode() that happens instead [10:47:20 CEST] <mathieu_> is there anyway to turn the threading off? [10:48:51 CEST] <JEEB> set the threading off with the related avoption [11:24:35 CEST] <mathieu_> JEEB, I don't really find anything on that, how does that work? [13:05:37 CEST] <barneygale> Hi folks. I'm running ffmpeg to record my screen, via x11grab. Is there any way to know when ffmpeg has captured the first frame? [13:05:43 CEST] <barneygale> programmatically [14:25:48 CEST] <amol> can anyone tell me what is the return value of 'AVERROR_EOF'. [14:29:15 CEST] <durandal_170> see source [14:45:59 CEST] <nyuszika7h> ffmpeg doesn't like special characters in -vf subtitles= [14:46:10 CEST] <nyuszika7h> like apostrophes, it just pretends they aren't there. I did quote the argument properly [14:46:18 CEST] <nyuszika7h> worked around by renaming file but it's annoying [15:47:21 CEST] <frenda> Hey there [15:49:25 CEST] <frenda> Is it possible to grap a part of video. For example the origin one is 1920x1080, grabing it to 720x480; I don't mean `converting to 720x480`; Like the time you take a snapshop of part of your desktop [15:52:46 CEST] <RobotsOnDrugs> you mean cropping? [15:53:10 CEST] <frenda> Ah, exactly [15:53:33 CEST] <RobotsOnDrugs> yes, there is a crop filter [15:54:05 CEST] <RobotsOnDrugs> http://ffmpeg.org/ffmpeg-filters.html#crop [15:57:41 CEST] <frenda> cool [15:58:58 CEST] <frenda> I'm going to crop a 1920x1080 video. Which size would be the best to be used as a full background of a `coming soon` web template? [16:11:01 CEST] <prelude2004c> hey, is there some way for ffmpeg to pickup and play a local m3u8 file stream ? [16:11:15 CEST] <prelude2004c> eg.. i have a bunch of files ( m3u8 stream ) located on the hard drive that is being written in realtime [16:11:30 CEST] <prelude2004c> i want to playback that into a new format like UDP:// or RTP or RTMP [16:11:36 CEST] <prelude2004c> what's the best way to do it [16:18:00 CEST] <well0ne> -c copy then [17:36:18 CEST] <prelude2004c> hey guys.. any easy way to take an HLS stream and without transcoding it making it info RTP localhost:port [17:36:35 CEST] <prelude2004c> i want people to pickup teh stream on the server ( they can't pickup HLS ) due to a playback error [18:01:59 CEST] <ozone89> hello! does anybody know how many fps does -showmode 2 go? I want to a frame every X but don't want to fall short, nor to take too many :) [18:02:25 CEST] <ozone89> FYI, the line I'm invoking is [18:02:29 CEST] <ozone89> ffmpeg -v verbose -f lavfi -i "amovie=$1, asplit[out0],showspectrum=s=1920x1080:slide=1,select='not(mod(n,25))'[out1]" -vsync 0 -f image2 test/image-%5d.png [18:08:50 CEST] <prelude2004c> anyone know the best place to get M3U8 Support ? [18:31:45 CEST] <shevy> can ffmpeg create simple .wma files? [18:31:55 CEST] <shevy> like from a .wav file [18:32:13 CEST] <BtbN> why would you want to use wma? [18:37:22 CEST] <relaxed> yes [18:37:51 CEST] <BtbN> to my knowledge wma is horrible and never sounds flawless [18:41:44 CEST] <ozone89> how do i change the pixels per sample in showspectrum? its result is way more condensed than showmode 2 [18:52:32 CEST] <chungy> there is a lossless variant of wma. by definition it will sound flawless :P [18:52:44 CEST] <chungy> Though outside of WMP and ffmpeg, you're better off just using FLAC. [18:53:09 CEST] <JEEB> note: win10 actually plays FLAC [18:53:31 CEST] <chungy> ffmpeg can only encode the lossy versions of ffmpeg, but it can decode the lossless too [18:53:46 CEST] <chungy> lossy versions of wma, I meant [18:54:16 CEST] <JEEB> yes [19:28:56 CEST] <UKCoder> Hi folks - I'm using ffprobe to analyze an M2TS AV file and I'm getting the following error "[mpegts @ 000000000222f600] PES packet size mismatch". My question is what does the 222f600 relate to? Is that a byte offset, a PCR, something else? [19:29:31 CEST] <JEEB> I think that's the memory address of that API thing [19:29:36 CEST] <JEEB> so not related to the file itself [19:35:58 CEST] <UKCoder> JEEB : Thanks, is there a way to relate that to file so that I could find out which is the offending PES packet? [22:02:37 CEST] <Craytor> Hello, is anyone present? [22:02:39 CEST] <Craytor> If so.... [22:02:48 CEST] <Craytor> I currently have ffmpeg set up and it is streaming to twitch. I am trying it with a VNC connection, so I have my monitor/display device set with :1. FFMPEG is streaming and twitch says I'm live, but it is only a black video. Does anyone know how I could get the connection's desktop or at least a firefox window to stream? [22:02:53 CEST] <Craytor> I'm trying to go ahead and set up a 24/7 weather stream (I have a js web app) to youtube. [22:29:32 CEST] <spYro_88> hey there :) [22:30:10 CEST] <spYro_88> Just a question: Anybode here who can help me with FFmpeg (with DTS) on Synology NAS? [22:58:37 CEST] <ChocolateArmpits> Craytor: Download OBS, it's streamlined for streaming and you can capture monitors/windows/desktop region and stream it https://obsproject.com/ [22:59:12 CEST] <ChocolateArmpits> MultiPlatform is slightly more capable so you can try that [23:43:02 CEST] <Craytor> ChocolateArmpits: I've tried using obs, but I get an error at launch. This is the launch log: pastebin.com/e92Px23M [00:00:00 CEST] --- Tue Aug 4 2015

1 0

ffmpeg-devel.log.20150802
by burek 03 Aug '15

03 Aug '15

[00:00:14 CEST] <Compn> the clear statement should be "please stop fighting and trolling each other projects" [00:00:23 CEST] <kierank> that the project goes on, michael still remains active and we want to proceed with some kind of merge [00:00:33 CEST] <kierank> it's not a statement to libav though [00:00:36 CEST] <reynaldo> I'd focus on the fact michael is stepping down, add the thank you note and invite ppl to participate in the discussions tending to find a way around his resignation. I wouldnt even mention libav [00:00:38 CEST] <kierank> it's a statement to everyone [00:00:47 CEST] <Compn> i agree with reynaldo [00:00:50 CEST] <Compn> dont mention libav [00:00:55 CEST] <Compn> lets fix our own project first [00:00:55 CEST] <kierank> libav isn't mentioned [00:00:56 CEST] <reynaldo> thanks Compn [00:01:07 CEST] <reynaldo> kierank: is clearly hinted [00:01:08 CEST] <kierank> there was a whole hour long thing about that in etherpad [00:01:22 CEST] <ubitux> well you said you would send a patch [00:01:25 CEST] <ubitux> :p [00:01:29 CEST] <reynaldo> "nd to have reconciliation between the forks" for example [00:01:35 CEST] <kierank> ubitux: yes, sorry [00:01:48 CEST] <kierank> but this is going to get stuck in a bikeshed otherwise [00:01:49 CEST] <Compn> kierank : the message has a lot about "last four years" stuff , thats not what we want to talk about [00:01:54 CEST] <ubitux> heh, told you "the forks" was going to cause troubles... [00:02:00 CEST] <Compn> :P [00:02:23 CEST] <Compn> kierank : you mind if i fix it up? [00:02:25 CEST] <Compn> :) [00:02:29 CEST] <michaelni> I think reynaldo should write it IMHO [00:02:29 CEST] <kierank> on etherpad, sure [00:02:38 CEST] <Compn> whats etherpad url again [00:02:42 CEST] <Compn> pls paste for me [00:02:42 CEST] <kierank> like 20 people wrote it michaelni [00:02:46 CEST] <kierank> https://etherpad.mozilla.org/Cem9NXUdZw [00:03:01 CEST] <reynaldo> would you mind if I add a candidate full text at the end? as its a destructive change I would like to propose it without wreaking havoc to the current edition [00:03:09 CEST] <reynaldo> kierank, everyone ^ ? [00:03:32 CEST] <reynaldo> ah, now it looks a lot better [00:03:40 CEST] <Compn> how do i save this ? [00:03:43 CEST] <reynaldo> let me take a full look at it again [00:03:44 CEST] <kierank> you don't save it [00:03:48 CEST] <Compn> oh ok :P [00:03:52 CEST] <Compn> hows it look now ? :) [00:04:01 CEST] <Compn> just removed some paragraphs, otherwise untouched. [00:04:05 CEST] <ubitux> btw, "a few hours" is not a long time window, even on michael time scale :P [00:04:09 CEST] <ubitux> (for a review) [00:04:34 CEST] <Compn> ubitux : you should be blaming whoever gave kierank ffmpeg-web access :p [00:04:35 CEST] <Compn> ehe [00:04:43 CEST] <kierank> ubitux: it's been on irc for 24 hours and on ml for a while as well [00:04:46 CEST] <Compn> reynaldo : hows etherpad look? [00:04:52 CEST] <ubitux> i'm not blaming anyone, 'enough drama [00:04:56 CEST] <Compn> :) [00:04:59 CEST] <kierank> you're just cutting out things that a lot of peopel wrote [00:05:11 CEST] <Compn> kierank : unneeded things [00:05:14 CEST] <Compn> less is more [00:05:28 CEST] <kierank> I regret doing this now [00:05:35 CEST] <Compn> just trying to help [00:05:50 CEST] <ubitux> collaborative editing is really calling for problems imo [00:05:52 CEST] <Compn> dont get discouraged kierank, it happens to everyone, nobody is ever happy [00:06:02 CEST] <wm4> whoever wrote "huge loss" please undo it [00:06:04 CEST] <wm4> mini didn't die [00:06:07 CEST] <ubitux> it should be one writer for consistency, then review and fixes on it [00:06:16 CEST] <kierank> ubitux: that's what it was [00:06:26 CEST] <reynaldo> wm4: is still a huge lost to have your lider resign [00:06:32 CEST] <ubitux> no, it's a collaborative edit by many people we don't know [00:06:41 CEST] <wm4> yes but now it sounds weird [00:06:48 CEST] <wm4> we're not finding a solution "to the loss" [00:06:50 CEST] <kierank> ubitux: most of it was people we knew [00:06:55 CEST] <kierank> ubitux: the anonymous are just lurkers [00:06:56 CEST] <wm4> we want to find a solution to the fork situation [00:06:59 CEST] <ubitux> there is no visibility [00:07:08 CEST] <wm4> mini even resigned for _that_ reason, he said it himself [00:07:14 CEST] <ubitux> just do it like we've done for years [00:07:22 CEST] <reynaldo> wm4: in understand that being an issue but the anouncement is about our leader resignation [00:07:36 CEST] <kierank> no the announcement is about also the crazy stuff going around on the internet [00:07:51 CEST] <reynaldo> we dont need to "anounce" that I think [00:07:52 CEST] <kierank> and flames on HN [00:08:00 CEST] <Compn> you should just say "fuck hn and reddit" then :P [00:08:03 CEST] <kierank> no, it's to show that the online trolls have no relevance and can't set the story [00:08:05 CEST] <wm4> reynaldo: yes we do, because the internet is speculation dumb shit [00:08:07 CEST] <kierank> it's ffmpeg's story [00:08:11 CEST] <wm4> *speculating [00:08:55 CEST] <Nightrose> hey [00:08:59 CEST] <Compn> hello lydia [00:09:21 CEST] <reynaldo> wm4: I do understand your point of view but as stated, I would just anounce mini resigned and add a thank you note and an invitation for the dev comunity to step in and help us find a way around it [00:09:29 CEST] <ubitux> kierank: can you fix the paragraph <p> thing at least? [00:09:31 CEST] <reynaldo> sounds both humane and positive [00:09:33 CEST] <kierank> ubitux: i did [00:09:42 CEST] <kierank> reynaldo: it's not a message to the dev community [00:09:45 CEST] <kierank> that's a message on the ML [00:09:47 CEST] <kierank> ffmpeg-devel [00:09:49 CEST] <kierank> it's a message to everyone [00:10:02 CEST] <kierank> saying, ffmpeg is here, it's a sad loss, we want to move forward together [00:10:12 CEST] <Compn> Nightrose : btw the etherpad is now live at www.ffmpeg.org , so please dont scared away by current etherpad changes. [00:10:17 CEST] <kierank> michael said his resignation was there in order to achieve that [00:10:32 CEST] <ubitux> kierank: 23:57 <@ubitux> kierank: you closed a paragraph already closed. [00:10:46 CEST] <kierank> ubitux: I sent a separate commit, no? [00:10:52 CEST] <wm4> <Compn> Nightrose : btw the etherpad is now live at www.ffmpeg.org , so please dont scared away by current etherpad changes. <- lol [00:10:57 CEST] <ubitux> kierank: i was refering to your "fix" [00:11:01 CEST] <Nightrose> ;-) [00:11:04 CEST] <kierank> ubitux: ah it's the bloody text editor [00:11:24 CEST] <kierank> there's a </p> at the end of line [00:11:25 CEST] <Compn> wm4 : i ate a few words there [00:11:30 CEST] <wm4> so I got worked up over nothing [00:11:32 CEST] <Nightrose> just to repeat what i said in the etherpad: i think what's live is the right message to send to the outside world at this point [00:11:36 CEST] <wm4> business as usual [00:11:38 CEST] <Compn> wm4 : lol! [00:11:48 CEST] <Compn> whiney people.... [00:12:04 CEST] <ubitux> Nightrose: just curious, who are you? [00:12:20 CEST] <Compn> he means what project you work on, and in what capacity [00:12:25 CEST] <kierank> ubitux: do you not remember lydia, she tried to moderate all the ffmpeg/libav meetings in the past [00:12:35 CEST] <ubitux> i never went to any meeting of that sort [00:12:41 CEST] <reynaldo> yeah, the current version is something I feel is close, just need some minor gramar fixes but the content seems ok [00:12:50 CEST] <kierank> reynaldo: i think you are totally ruining the message [00:12:52 CEST] <Compn> ubitux : you didnt miss much... [00:12:56 CEST] <kierank> and it comes out a lot worse to the rest of the world [00:13:00 CEST] <Nightrose> ubitux: Lydia - president of kde eV, product manager for wikidata and random advisor and mediator for videolan [00:13:03 CEST] <ubitux> Compn: i know, that's why i didn't go [00:13:11 CEST] <ubitux> Nightrose: ok, thx [00:13:21 CEST] <reynaldo> kierank: is really not my intention to ruin anything :/ [00:13:33 CEST] <Compn> kierank , dont you want reynaldo's input ? [00:13:38 CEST] <Compn> or mine... [00:13:42 CEST] <Compn> or michaelni's ? [00:13:42 CEST] <kierank> yes but the etherpad is slash and burn [00:13:48 CEST] <kierank> michaelni I have heard nothing from [00:13:59 CEST] <kierank> you are discounting the work of a lot of people [00:14:05 CEST] <ubitux> (he said he didn't like it) [00:14:09 CEST] <Compn> [18:02] <michaelni> I think reynaldo should write it IMHO [00:14:18 CEST] <Compn> 12 mins ago [00:14:22 CEST] <Nightrose> ubitux: do you know why specifically? [00:14:32 CEST] <ubitux> no idea, ask him [00:14:41 CEST] <michaelni> it felt a bit offensive to say that my resignation gives opertunities, i understand this is techincally true and i agree its true just doesnt feel very friendly worded [00:14:49 CEST] <reynaldo> the previous text was like an obituary with an added invitation to agree on how to distribute the dead's man wealth [00:14:52 CEST] <Compn> michaelni: +1 [00:14:55 CEST] <reynaldo> like, bad taste [00:14:57 CEST] <wm4> michaelni: but you said it YOURSELF [00:15:03 CEST] <kierank> michaelni: you said exactly this [00:15:05 CEST] <kierank> that's why we said that [00:15:06 CEST] <wm4> you're being fucking idiots [00:15:12 CEST] <wm4> you have a chance for reconcillation [00:15:14 CEST] <Compn> wm4 / kierank : i think you may have misread his email [00:15:19 CEST] <wm4> and you're ruining it with your petty politics [00:15:31 CEST] <ubitux> omg it's getting heated here [00:15:37 CEST] Action: ubitux goes away [00:15:42 CEST] <durandal_1707> Indeed [00:15:52 CEST] <Compn> yeah, why so angry ? [00:15:57 CEST] <reynaldo> wm4: drop the attitude pal, its uncalled for [00:16:00 CEST] <kierank> Compn: because we spent a lot of time on this [00:16:05 CEST] <kierank> and then you are just slashing and burning [00:16:09 CEST] <wm4> reynaldo: yopur behavior is uncalled for [00:16:09 CEST] <Nightrose> kierank: want me to help you reword that specific part? [00:16:14 CEST] <wm4> we're trying to fix shit [00:16:17 CEST] <wm4> you're ruining it [00:16:20 CEST] <reynaldo> wm4: im just trying to help [00:16:34 CEST] <wm4> sorry for being aggressive, but it happened all the time in the last 4 years [00:16:51 CEST] <Compn> you can blame me for the past 4 years, i dont mind :) [00:17:02 CEST] <kierank> this is really pissing me off [00:17:02 CEST] <wm4> I blame you for being noise [00:17:07 CEST] <kierank> i've spent much of my saturday night doing this [00:17:10 CEST] <kierank> and you just shit all over it [00:17:23 CEST] <Nightrose> if we can rework the opportunity part is everyone happy? [00:17:45 CEST] <reynaldo> michael, Compn and myself are against that part [00:17:46 CEST] <Compn> i ok'd it in the mail i sent to kierank about it btw [00:17:49 CEST] <Nightrose> or are there other major things worth being angry about? [00:18:00 CEST] <reynaldo> (from what I understand) [00:18:01 CEST] <ubitux> i'd say the important point is that you need to stick to the project policy [00:18:08 CEST] <ubitux> that is write a patch and send it for review [00:18:10 CEST] <Compn> he parted ubitux [00:18:13 CEST] <Compn> ragequit [00:18:16 CEST] <wm4> michaelni: well, if you don't agree that you're giving an opportunity to fix the fork situation, then you resigned for nothing, and just put the project into trouble by suddenly not maintaining it anymore [00:18:22 CEST] <ubitux> because the feeling is that it's written by third parties [00:18:34 CEST] <wm4> which puts your resignation in quite a different light, IMHO [00:18:38 CEST] <ubitux> so it would be nice if ppl on the mailing list could comment [00:18:52 CEST] <ubitux> Compn: well, there are still people talking, he didn't write everything afaict [00:20:15 CEST] <ubitux> Nightrose: i think onl kierank & wm4 are angry/frustrated because of various opposition after it's done [00:21:00 CEST] <Nightrose> well i can try to help you find a middle ground but i don't think that's going to work with a full rewrite at this point [00:21:20 CEST] <michaelni> wm4 i agree that ive given the opertunity and yes i want to. but it somehow feels ot of place in that announcement with that wordig [00:21:34 CEST] <ubitux> i kind of agree with the fact that the wording is not very nice [00:21:42 CEST] <ubitux> a "shock" sounds really like an accident [00:21:53 CEST] <ubitux> i actually have comments to do, but i wasn't expecting to see it pushed like this [00:22:03 CEST] <ubitux> anyway, a link to the announcement would actually be useful [00:22:11 CEST] <ubitux> in the meantime i think it makes sense to revert [00:22:13 CEST] <Compn> Nightrose : imagine if you quit your job and everyone now says there is an opportunity to get it all fixed. [00:22:20 CEST] <ubitux> and think calmely about rewording [00:22:21 CEST] <durandal_1707> well it could be announced and not done abruptly [00:22:47 CEST] <Nightrose> Compn: i don't have a stake in this one way or another. i can try to help you fix this or go to bed ;-) [00:22:51 CEST] <wm4> michaelni: well, after all, the reconcillation part doesn't take much space in the announcement [00:22:59 CEST] <Compn> did not answer question :P [00:23:16 CEST] <Compn> i guess i missed the "how would you feel about it?" [00:23:24 CEST] <wm4> the first paragraph is about saying thanks to michael etc. [00:23:27 CEST] <Nightrose> well it really depends on the situation and how i personally percive it [00:23:30 CEST] <wm4> the second is about reconcillation [00:23:51 CEST] <wm4> the third is about talking on vdd, which also can includes ffmpeg internal issues [00:24:15 CEST] <ubitux> i just reverted [00:24:18 CEST] <Compn> wm4 : i really want to see you at vdd in one of these meetings. [00:24:21 CEST] <ubitux> we can now do it properly [00:24:42 CEST] <Compn> 100 devs from other projects and 4-5 people from ffmpeg and 4-5 people from libav, with everyone telling us what to do :) [00:24:51 CEST] <wm4> sigh [00:24:53 CEST] <wm4> fuck everything [00:25:30 CEST] <Compn> Nightrose : there is no helping us, thanks anyhow [00:25:41 CEST] <reynaldo> the rage quits dont signal a comming reconciliation tbh [00:25:42 CEST] <Nightrose> i don't think that's true [00:26:00 CEST] <Compn> both of them are mostly neutral [00:26:07 CEST] <ubitux> i was willing to go to sleep but i guess i'm going to try rewording and shit and send a patch [00:26:14 CEST] <reynaldo> I need to go now but will try to get online latter if ppl want to continue working on the text [00:26:14 CEST] <ubitux> can anyone summarizes the complains? [00:26:36 CEST] <Compn> ubitux : i dunno , my opinion was not well liked, at all. [00:26:47 CEST] <reynaldo> I like your opinion Compn [00:26:51 CEST] <Compn> thanks reynaldo [00:26:51 CEST] <ubitux> yes, and i understand why [00:26:53 CEST] <reynaldo> I feel pretty much the same way [00:27:04 CEST] <durandal_1707> people leave than come back and start complaining [00:27:23 CEST] <reynaldo> anouncement on mini resignation, thank you note and invitation to discuss matters in the coming days [00:27:27 CEST] <reynaldo> thats my take [00:27:36 CEST] <reynaldo> Compn: would you agree ^ ? [00:28:02 CEST] <Compn> sure [00:28:09 CEST] <durandal_1707> No reconciliation? [00:28:12 CEST] <Compn> reynaldo : what about note to stop fighting about which project is better ? [00:28:17 CEST] <reynaldo> Cool. OK, need to leave now, tty ppl latter o/ [00:28:22 CEST] <Compn> directed specifically at hn and reddit ? [00:28:23 CEST] <ubitux> going to rewrite it... [00:28:41 CEST] <ubitux> give me half an hour or so and i'll send a proper patch [00:28:47 CEST] <reynaldo> Compn: it'd only feed them I think [00:28:55 CEST] <reynaldo> anyhow, really need to leave now [00:28:56 CEST] <reynaldo> o/ [00:28:58 CEST] <Compn> cya [00:29:57 CEST] <iive> have fun [00:30:14 CEST] <Compn> ubitux : better make a note to thank everyone who worked on the wording... [00:30:21 CEST] <ubitux> no [00:30:31 CEST] <Compn> lol :) [00:30:43 CEST] <Compn> i just meant in the patch mail [00:30:45 CEST] <Compn> but ok haha [00:33:11 CEST] <Compn> j-b : pick leader :P [00:33:57 CEST] <ubitux> so [00:34:03 CEST] <ubitux> 3 information to cover, right? [00:34:31 CEST] <ubitux> michael leadership, project continuation, av/ff reconciliation attempt + vdd, right? [00:35:03 CEST] <Compn> i have no idea, ask Nightrose and check up kierank's original mail (or whoever wrote that we "needed" an announcement [00:35:23 CEST] <ubitux> should be done pretty soon anyway [00:35:33 CEST] <Nightrose> that was pretty much what the previous one said. if we can fix the opportunity part it should be good then? [00:35:44 CEST] <ubitux> it was bad wording tbh [00:35:56 CEST] <ubitux> it wasn't clear enough either imo [00:36:06 CEST] <michaelni> Nightrose, iam really happy with anything didnt thing people would ragequit [00:36:09 CEST] <durandal_1707> so just everything without shocking part? [00:36:12 CEST] <Nightrose> from a public relations pov it was very good [00:36:23 CEST] <ubitux> anyway, i'll send a message written by a semi autistic person with clear wording [00:36:29 CEST] <ubitux> hopefully [00:36:41 CEST] <Nightrose> michaelni: ok :) [00:37:26 CEST] <Nightrose> general tip: let people write this who have some experience with public relations [00:38:10 CEST] <michaelni> no objections from me [00:40:30 CEST] <michaelni> Nightrose, if you want to write it i dont mind, i am really just resigning and just felt that one phrase a bit offensive but maybe i should have stayed silent [00:41:12 CEST] <Nightrose> michaelni: no if this bugs you it should be fixed. and i have no desire to write it but i am here to help and advice if you want me to [00:41:34 CEST] <Compn> michaelni : if you ever do come back, in my opinion, you should just pick a different nickname so no one knows its you :P [00:41:44 CEST] <Compn> thats what my goal is to be, anonymous so no one can hate me forever [00:42:05 CEST] <ubitux> i'll send a patch in 5-10 min [00:42:25 CEST] <Compn> i'll probably kill my own nickname next year and remove all of my emails and start fresh [00:42:29 CEST] <michaelni> Nightrose, sure i want your advice but iam not writing this text at all [00:43:08 CEST] <Nightrose> ok. let's see what ubitux comes up with then. [00:43:14 CEST] <Nightrose> i can stay up for another 15 mins [00:43:19 CEST] <michaelni> ok [00:44:19 CEST] <durandal_1707> Compn: you and your clones.... [00:44:19 CEST] Action: Compn afk [00:44:42 CEST] <Compn> durandal_1707 : you'll probably be able to spot me by my punctuation [00:48:24 CEST] <ubitux> patch on the ml [00:48:35 CEST] <ubitux> Nightrose, michaelni [00:48:51 CEST] <Nightrose> ubitux: link? sorry - not subscribed to list [00:49:03 CEST] <ubitux> basically 3 new paragraphs, kept 2 [00:49:06 CEST] <ubitux> Nightrose: http://ffmpeg.org/pipermail/ffmpeg-devel/2015-August/176579.html [00:49:20 CEST] <Nightrose> thx [00:49:49 CEST] <Nightrose> doing an outstanding work <- no an [00:50:19 CEST] <ubitux> fixed locally [00:50:21 CEST] <Nightrose> project is now facing another crisis in its history <- you really don't want to phrase it like that in public communication [00:50:34 CEST] <michaelni> Nightrose, +1 [00:50:38 CEST] <ubitux> ok [00:50:45 CEST] <ubitux> suggestion? [00:50:59 CEST] <Nightrose> i think the wording in the previous version was good there [00:51:42 CEST] <michaelni> "To illustrate this, we are in the process of a reconciliation with the Libav project." <-- you want that but if that will happen/succed is not kown [00:51:50 CEST] <Nightrose> Nevertheless, the community will continue to contribute to the project and will try to satisfy as much as possible the expectations of everyone. <- sounds very fatalistic. i think you want to send a message of hope and progress [00:52:00 CEST] <ubitux> michaelni: that's what the next paragraph says [00:52:27 CEST] <ubitux> Nightrose: if you were refering to "We hope that in the future he will be able to continue to contribute to the project." i don't call this hope [00:52:42 CEST] <iive> also, by community you mean ffmpeg team, don't you? [00:52:43 CEST] <ubitux> it feels like a desperate "plz michael come back save us" [00:53:24 CEST] <Nightrose> ubitux: that was in the previous version? hmm no that's not good either [00:53:31 CEST] <ubitux> yes [00:53:39 CEST] <ubitux> "the FFmpeg project will be managed by the active contributors, until we can find a more permanent solution." and this is like "active contributors" are not good enough for the long term [00:53:46 CEST] <michaelni> maybe just fixing that one phrase in the previous version is easier ? [00:53:54 CEST] <Nightrose> "We don't really know yet if this is going to result in anything, but in the meantime we urge our common users to avoid making any loud statements and assumption regarding both sides. <- you don't want to communicate uncertainty like this [00:54:04 CEST] <Nightrose> michaelni: i believe it is [00:54:41 CEST] <ubitux> Nightrose: well, that's the truth [00:54:41 CEST] <Compn> ubitux : you fool! it will never be good enough :P [00:54:51 CEST] <ubitux> Nightrose: we have absolutely no clue [00:54:59 CEST] <iive> Compn: we don't need another rage quit! [00:55:07 CEST] <Nightrose> ubitux: that's fine but that's not what you want to shout to the world [00:55:24 CEST] <Compn> iive : sorry :P [00:55:29 CEST] <michaelni> Nightrose, can you just write some text or resurrect the last good one with any correction you feel should be in it ? [00:55:45 CEST] <ubitux> yeah, feel free to just do that [00:55:53 CEST] <Nightrose> michaelni: sure. can someone get me the text kiran commited? [00:55:53 CEST] <durandal_1707> less is more [00:55:55 CEST] <ubitux> but honestly the first paragraph was very bad [00:56:01 CEST] <Compn> durandal_1707 : shhhhhh [00:56:10 CEST] <ubitux> Nightrose: yes just am oment [00:56:14 CEST] <Nightrose> thx [00:57:24 CEST] <ubitux> Nightrose: http://b.pkh.me/orig-msg not sure if it's a form you will like [00:57:35 CEST] <ubitux> i can provide the patch or something [00:57:47 CEST] <Nightrose> that works [00:57:53 CEST] <Nightrose> give me two mins [01:02:42 CEST] <ubitux> take your time [01:02:54 CEST] <Nightrose> ubitux: michaelni: https://etherpad.mozilla.org/Cem9NXUdZw <- fixed some things. can you check? [01:03:51 CEST] <ubitux> i'm nitpicking, but "the FFmpeg project will be managed by the active contributors, until we can find a more permanent solution." feels like contributors are not enough to handle the project :p [01:04:07 CEST] <Nightrose> ok [01:04:21 CEST] <Nightrose> the intention was to say that this is not a viable permanent solution [01:04:24 CEST] <ubitux> no other comment [01:04:27 CEST] <ubitux> well [01:04:32 CEST] Action: Nightrose thinkshow to make that clearer [01:04:34 CEST] <ubitux> who else than developers? [01:04:36 CEST] <ubitux> :D [01:04:49 CEST] <ubitux> i mean, is this supposed to say that a big corp needs to handle it or something? [01:04:59 CEST] <Nightrose> no but that a leader is needed i think [01:05:07 CEST] <ubitux> we are not sure about that [01:05:08 CEST] <Nightrose> or some other form of covernance [01:05:14 CEST] <Nightrose> ok [01:05:17 CEST] <ubitux> and you might not want to say that we are looking for a leader [01:05:22 CEST] <Nightrose> right [01:05:24 CEST] <ubitux> that's one of the "requests" from libav [01:05:32 CEST] <Nightrose> ok [01:06:04 CEST] <Nightrose> how about making it "in the meantime the ffmpeg project will be managed by the active contributors" [01:06:09 CEST] <michaelni> Nightrose, your text sounds fine to me, i wont nitpick [01:06:10 CEST] <ubitux> otherwise no other comment; when it's done, please give me a name <mail> to put in sign off and send the patch [01:06:25 CEST] <ubitux> Nightrose: yeah sure, fine [01:06:28 CEST] <Nightrose> michaelni: ok cool [01:06:32 CEST] <Nightrose> ubitux: ok will change [01:06:38 CEST] <michaelni> Nightrose, i meant the whole text in case it wasnt clear [01:06:45 CEST] <ubitux> also, maybe not "will", present tense is fine [01:06:52 CEST] <Nightrose> and Lydia Pintscher <lydia(a)kde.org> [01:06:54 CEST] <Nightrose> ubitux: k [01:06:57 CEST] <ubitux> ok [01:07:18 CEST] <Nightrose> ubitux: done [01:10:02 CEST] <ubitux> Nightrose: http://ffmpeg.org/pipermail/ffmpeg-devel/2015-August/176583.html [01:10:06 CEST] <ubitux> thanks [01:10:49 CEST] <Nightrose> \o/ [01:11:02 CEST] <ubitux> not pushed yet, waiting for a few comments [01:11:06 CEST] <Nightrose> you can do this folks ;-) [01:11:09 CEST] <Nightrose> ok [01:11:11 CEST] <ubitux> yeah sure [01:11:40 CEST] <iive> maybe add "the FFmpeg project will continue to be managed by..." [01:12:08 CEST] <ubitux> kierank: can you stop acting on a whim like this? :p [01:12:19 CEST] <kierank> like what? [01:12:24 CEST] <ubitux> like the mail you just sent [01:12:35 CEST] <kierank> well it's a patch with my name on it with code I didn't write [01:12:39 CEST] <kierank> well text I didn't write [01:12:42 CEST] <kierank> the new one is better [01:12:49 CEST] <ubitux> i didn't know the author [01:13:10 CEST] <ubitux> so i took the one who commited originally and kept 2 paragraph of it [01:13:20 CEST] <ubitux> i'm aware my attempt was not pretty but i explained myself [01:13:32 CEST] <kierank> ok [01:13:34 CEST] <ubitux> there is no need to be in a hurry to send flamebait like you just did [01:13:37 CEST] <ubitux> anyway, welcome back [01:13:46 CEST] <kierank> sorry I am in a bad mood after spending much of my evening on this [01:13:54 CEST] <kierank> and having a belief that things could get better [01:14:36 CEST] <durandal_1707> Nightrose: tnx [01:14:41 CEST] <ubitux> it always feel like a nuclear war starts everytime there is a few exchanges, that's really crazy [01:14:45 CEST] <Nightrose> no problem [01:14:52 CEST] <mark4o> s/-/—/ [01:14:56 CEST] <kierank> ubitux: and that's a social problem [01:14:58 CEST] <kierank> not a technical one [01:15:10 CEST] <kierank> but I have struggled (and given up) for years to explain that [01:15:25 CEST] <ubitux> except there was absolutely no need to overreact here [01:15:53 CEST] <kierank> after 10-15 people by email, irc, etherpad saying the message was fine, 3 people just ripping it apart [01:15:54 CEST] <ubitux> we need to learn to keep calm, because this is only the beginning of the incoming shitstorm [01:15:58 CEST] <kierank> after we all spent a long time on it [01:16:44 CEST] <ubitux> yeah well, i understand the frustration, but that's not how social relationships work, you know that better than me [01:17:03 CEST] <kierank> yeah in an ideal world those three people would not rip it apart [01:17:08 CEST] <kierank> but respect the fact a lot of people worked on it [01:17:16 CEST] <kierank> and realise that things are bigger than their own views [01:17:38 CEST] <ubitux> that's why maybe you needed to take into account the opinion of 3 more ppl [01:18:01 CEST] <ubitux> because these 3 more ppl might have been as much concerned as the 15 others [01:18:08 CEST] <kierank> and those 3 need to understand the views of others [01:18:10 CEST] <ubitux> anyway, whatever, story almost done [01:18:18 CEST] <ubitux> and that's why it was in a discussion [01:18:40 CEST] <ubitux> and it was slightly stressful because it was pushed in a hurry [01:18:47 CEST] <kierank> it wasn't pushed in a hurry [01:18:55 CEST] <mark4o> It might be good to update the "FFmpeg needs a new host" news item to say that new hosts have been found; otherwise two bad news in a row makes it look like the project is falling apart [01:18:57 CEST] <ubitux> 24h is too short [01:19:08 CEST] <ubitux> especially for that kind of stuff [01:19:10 CEST] <kierank> it's been on irc for ages and I asked on etherpad many times [01:19:11 CEST] <kierank> LOOOL [01:19:25 CEST] <kierank> the irony [01:19:33 CEST] <kierank> when ffmpeg patches appear out of nowhere [01:19:47 CEST] <ubitux> well maybe you don't want to make the same mistake you blamed for years [01:21:10 CEST] <kierank> this is clearly a time sensitive issue [01:21:19 CEST] <kierank> https://www.reddit.com/r/programming [01:21:23 CEST] <kierank> look what's at the top [01:21:27 CEST] <kierank> reddit misinformation [01:21:33 CEST] <ubitux> it won't stop [01:21:39 CEST] <kierank> yesterday was HN [01:21:43 CEST] <kierank> it'll stop when there's a statement [01:21:47 CEST] <kierank> that's why it had to be made [01:22:01 CEST] <Nightrose> it wont stop but it gets worse if you're not ahead of it and get out with your message/version of the story [01:22:42 CEST] <ubitux> patch applied [01:23:11 CEST] <kierank> might have some minor grammar changes [01:23:26 CEST] <ubitux> too late, feel free to amend directly [01:23:34 CEST] <ubitux> well, not amend [01:24:40 CEST] <ubitux> erm [01:25:01 CEST] <ubitux> yeah i asked for a change of tense because it is the case presentely [01:25:10 CEST] <ubitux> but well, nitpick wahtever [01:25:13 CEST] <kierank> the english is wrong [01:25:16 CEST] <kierank> in the old one [01:26:25 CEST] <Compn> kierank : thanks for working on it [01:26:51 CEST] <ubitux> kierank: yeah [01:27:41 CEST] <Nightrose> good night, folks [01:27:47 CEST] <kierank> night [01:28:10 CEST] <michaelni> night [01:28:52 CEST] <kierank> reynaldo: can you tweet the new version [01:29:31 CEST] <jamrial> i agree with mark4o, btw. if not a new entry the existing news entry could use an "update: We got some offers, thanks" or such [01:30:25 CEST] <michaelni> jamrial, +1 [01:30:27 CEST] <rcombs> https://www.openssl.org/blog/blog/2015/08/01/cla/ fuck yes [01:30:48 CEST] <mark4o> Yeah people from outside will see the top two news items are loss of host and loss of project leader, and think the project is in its death throes. Someone knowledgeable about the new hosts should update that with some positive news. [01:31:35 CEST] <kierank> rcombs: cla? [01:31:48 CEST] <rcombs> kierank: Contributor License Agreement [01:31:50 CEST] <Plorkyeran> wow, apache 2 openssl would be amazing [01:31:51 CEST] <kierank> rcombs: how the hell can they make it apache2 [01:31:56 CEST] <kierank> there's so many people [01:32:47 CEST] <michaelni> jamrial, do you want to write a update for the server or should i ? [01:32:49 CEST] <Plorkyeran> it's gotta be months or years of work [01:32:50 CEST] <wm4> isn't apache 2 LGPL incompatible [01:33:12 CEST] <Plorkyeran> it's 3+ compatible only [01:33:19 CEST] <wm4> also lol forced CLA [01:33:52 CEST] <Compn> it makes sense now [01:33:57 CEST] <Compn> that we need an announcement [01:33:59 CEST] <Plorkyeran> the previous post is good news too [01:34:04 CEST] <Compn> because the rumors at internet sites are making our projects look bad [01:34:10 CEST] <Compn> which in turn makes us have less contributors [01:34:12 CEST] <Compn> i get it now [01:34:17 CEST] <Plorkyeran> dropping BeOS, NeXT, Tandem, Cray, Win16... [01:34:23 CEST] <Compn> you guys should explain it to the dum dums like me :P [01:34:38 CEST] <kierank> Compn: loool [01:34:57 CEST] <Compn> oh fuck yes on openssl relicensing [01:35:08 CEST] <Compn> thanks rcombs [01:35:15 CEST] <jamrial> michaelni: if you can do it then that'd be best. you know more about how many offers we got and their nature [01:35:15 CEST] <kierank> Compn: I thought you understood that... [01:35:25 CEST] <wm4> good thing Compn isn't in charge of openssl [01:35:43 CEST] <rcombs> Apache is an interesting choice, but at this point anything's better than what they have now [01:35:50 CEST] Action: BBB gives ubitux and kierank a big hug [01:35:57 CEST] <BBB> ubitux: btw I said it was fine, so blame me also then [01:36:00 CEST] <michaelni> jamrial, my information is less than what i would prefer to write news [01:36:16 CEST] <michaelni> but ill try and post a patch [01:36:38 CEST] <jamrial> as i said a simple "update" line at the end of the existing news item is enough [01:36:50 CEST] <BBB> mark4o has a good point btw, we need to add an update to the previous news item and say the issue is resolved [01:36:53 CEST] <ubitux> BBB: no worry :p [01:36:55 CEST] <BBB> (at least temporarily) [01:36:59 CEST] <Plorkyeran> the update should be at the beginning [01:37:01 CEST] <Plorkyeran> not the end [01:37:02 CEST] <BBB> we need to mingle bad news with good news [01:37:06 CEST] <BBB> yes [01:37:14 CEST] <jamrial> Plorkyeran: true, my bad [01:37:42 CEST] <Compn> kierank : i've been at a loud electronic music festival for most of the day [01:37:44 CEST] <ubitux> BBB: i wasn't trying to blame anyone, but not reverting wouldn't have help the situation (and yeah i know my wording was shit but the purpose wasn't exactly to get my version in) [01:37:59 CEST] <kierank> ubitux: can you post the new thing to hacker news please [01:38:07 CEST] <kierank> i have anti-procrast on [01:38:14 CEST] <ubitux> kierank: okay [01:38:18 CEST] <ubitux> is it a good time? [01:38:25 CEST] <kierank> probably [01:38:26 CEST] <Compn> also tell hackernews to fuck off and stop making hate filled posts to both projects while we work on things [01:38:32 CEST] <Compn> :P [01:38:43 CEST] <kierank> lwn as well needs to be informed [01:39:22 CEST] <ubitux> kierank: https://news.ycombinator.com/item?id=9989147 [01:40:47 CEST] <michaelni> server update mail sent [01:41:14 CEST] <michaelni> Compn, also i think mplayerhq page needs similar update [01:41:30 CEST] <michaelni> not sure if it was on other pages too [01:45:43 CEST] <iive> and people don't forget the most important part: [01:45:47 CEST] <iive> have fun. [01:45:50 CEST] <iive> see ya [01:45:58 CEST] <Compn> michaelni : ok [01:46:30 CEST] <Compn> hmmm where did i put mplayer web repo [01:49:11 CEST] <Compn> michaelni : done [01:49:32 CEST] <Compn> yes, i lazy :P [01:50:44 CEST] <Compn> kierank , wm4 , Nightrose , michaelni , ubitux , reynaldo : btw the new language on ffmpeg.org looks wayyyy better. thanks! [01:51:18 CEST] <Compn> and whoever else i missed [01:51:22 CEST] <Compn> everyone who worked on etherpad [01:54:27 CEST] <Compn> wm4 / kierank: sorry if my changes were too drastic [01:54:44 CEST] <Compn> i didnt mean to upset anyone [01:54:52 CEST] <kierank> ok [02:01:30 CEST] <Compn> hmm [02:01:43 CEST] <Compn> if baptiste adds a binary codec loader to ffmbc , i'd switch to his project... [02:01:48 CEST] <Compn> :) [02:02:39 CEST] <kierank> what can't you play? [02:04:51 CEST] <Compn> i'm on a crusade to play vivo files and .... movie codec (mvi2 fourcc) [02:05:40 CEST] <Compn> there seems to be a lack of reverse engineer developers at the moment [02:11:32 CEST] <kierank> Compn: send the mvi2 author an email [02:12:29 CEST] <kierank> https://www.linkedin.com/pub/christian-huygen/69/854/7 [02:15:47 CEST] <Compn> kierank : i tried and failed before to send messages over linkedin. anyway i can beg you to ask for me? just a simple "i'm an ffmpeg developer and i want to get mvi2 support in ffmpeg. please help" type thing [02:16:06 CEST] <kierank> how is that guy making firefox use ffmpeg [02:17:24 CEST] <Compn> on youtube :D [02:17:28 CEST] <Compn> i mean good question [02:17:37 CEST] <Compn> because i hate flash player [02:18:24 CEST] <Compn> gstreamer it looks like [02:18:42 CEST] <BtbN> firefox is the worst browser if you hate flash though [02:18:47 CEST] <Compn> hoho ... /usr/src/debug/media-plugins/gst-plugins-libav-1.4.5-r1/gst-libav-1.4.5/ext/libav/gstavauddec.c:475 [02:19:29 CEST] <kierank> lol [02:19:34 CEST] <Compn> BtbN : which is why i use old outdated version of opera [02:19:54 CEST] <BtbN> That's propably even worse in terms of html5 video support [02:20:40 CEST] <Compn> it plays youtube html5, thats about it though [02:20:56 CEST] <BtbN> It most likely doesn't support MSE, so it only plays low-quality videos. [02:21:06 CEST] <Compn> otherwise i just have a javascript button that sends the youtube url to vlc ... [03:17:10 CEST] <colink> Hey everyone!! I see that you guys are looking for a server to keep this project online and I am ready to host and administer the ffmpeg project for free. Please email me at colin.b.kelly(a)gmail.com [03:17:18 CEST] <colink> ;) [03:21:51 CEST] <colink> hey mat ;) [03:25:42 CEST] <jamrial> colink: we already got several offers and i think one or two were chosen, but thanks anyway :) [03:26:52 CEST] <colink> oh :'( [03:27:29 CEST] <colink> I looking to help this project as I really do want to see ffmpeg thrive [03:28:26 CEST] <colink> to be honest... I hate libav with a passion [03:28:39 CEST] <razzledazzle> hello there, I have questions regarding audio mixing, not directly related to ffmpeg [03:29:01 CEST] <colink> you mean dj-ing [03:29:52 CEST] <razzledazzle> from what I've read, two audio samples can be mixed by just adding them and taking their average, the resulting sample would be mixed, ignoring clipping and other matters, should there be change in the pitch of the output audio? [03:30:02 CEST] <razzledazzle> haha not dj-ing [03:30:23 CEST] <colink> lol [03:30:38 CEST] <relaxed> read the topic [03:31:38 CEST] <colink> Jamrial, are you an admin of the ffmpeg project? [03:32:12 CEST] <razzledazzle> just hunting for insights [03:32:16 CEST] <Compn> colink : we are happy to have you contribute in any way you want :) [03:32:39 CEST] <BtbN> letting "random" people administer servers is unlikely to happen though [03:32:45 CEST] <Compn> quite. [03:33:04 CEST] <Compn> although there are a lot of people who want to see ffmpeg and libav work together again, so maybe dont hate so much , colink [03:33:56 CEST] <colink> lol BtbN, I understand your logic though I can honestly give the full root access of a dedi without haveing access to it [03:34:16 CEST] <colink> unlimited bandwidth also [03:34:47 CEST] <BtbN> i'm not sure what the current status on the server thing is, but i believe it's resolved and hosts have been chosen [03:34:56 CEST] <Compn> we have two nice hosts now [03:34:59 CEST] <Compn> all lined up [03:35:02 CEST] <Compn> well 3 if you count vlc [03:35:14 CEST] <Compn> 3, we have 3 hosts lined up, the number of servers is 3. [03:35:27 CEST] <BtbN> next step is propably moving stuff to some kind of conatiners, so future migrations become easier [03:35:35 CEST] <colink> cool I understand [03:35:42 CEST] <Compn> virtualized or qemu machines, yes [03:36:23 CEST] <colink> So the 3 hosts are VPS'? lol [03:36:33 CEST] <BtbN> No, the 2 hosts are strong dedicated servers [03:36:40 CEST] <Compn> vlc is the virtual [03:36:53 CEST] <colink> okok got ya [03:37:02 CEST] <BtbN> but the services on them are intended to be moved to (seperated) virtual machines, so it becomes easier to move them around [03:37:16 CEST] <Compn> protect against infiltrations and zero day exploits [03:37:17 CEST] <Compn> too [03:37:37 CEST] <BtbN> Well, do VMs realy help against that? [03:37:37 CEST] <colink> well openstack would be my technology of choice obviously [03:37:38 CEST] <colink> with kvm on top of that [03:37:48 CEST] <Compn> bsd? [03:38:38 CEST] <Compn> BtbN : lets say you have a zero day against a web server, but the web server is on a different vm than the git server, so now you cant get root on the git server by exploiting the webserver [03:39:02 CEST] <BtbN> yes, on that level, of course [03:39:57 CEST] <colink> alright calm down people, why the hell would someone use a 0day hack on the ffmpeg repo? has that happened in the past? [03:40:06 CEST] <Compn> anyways [03:40:10 CEST] <Compn> colink : are you a programmer ? [03:40:13 CEST] <BtbN> Have you ever looked at webserver logs on a public webserver? [03:40:18 CEST] <BtbN> or ssh login logs? [03:40:23 CEST] <BtbN> On any server with a public ip? [03:40:24 CEST] <Compn> gigabytes of logs of ssh login attempts [03:40:37 CEST] <colink> probably libav lol [03:41:18 CEST] <colink> Yup! but wouldnt be considered a programmer to you C++ and C programmers lol [03:41:40 CEST] <colink> Im a PHP programmer working with mvc and sh*t [03:42:11 CEST] <BtbN> At work we have a bunch of VMWare ESXi hosts with a vCenter. It's a very good solution imo, but not viable for ffmpeg. [03:42:25 CEST] <colink> Compn you are are that SSH brute force is not considered as an 0day right? [03:42:56 CEST] <Compn> colink : ah no problem, i'm not a programmer, nor even a php scripter! [03:42:58 CEST] <colink> you should drop VMware and go for an openstack infrastructure [03:43:06 CEST] <BtbN> There are armys of bots out there that jump on every exploit that comes up and try use it on everything they can find. [03:43:10 CEST] <Compn> was just seeing if you wanted to fix bugs [03:43:28 CEST] <colink> lol ok [03:44:18 CEST] <BtbN> If there realy is a serious remote code exec bug in a primary server software, i wouldn't even bother checking if someone got in. I would just restore the machine from a backup. [03:45:14 CEST] <colink> Oh well if you are talking about bugs on the website I will definitely be able to contribute. However, if you are talking abbout ffmpeg bugz.. your gonna have to give me a couple of years before I start tackling such bugz [03:48:42 CEST] <cone-435> ffmpeg 03Vesselin Bontchev 07master:336822edf4fc: avformat/mov: fix regression in processing .aax files [03:49:07 CEST] <Compn> no problem [03:49:16 CEST] <Compn> i'm just tired today and cant think up ideas right now [03:58:57 CEST] <Compn> i like that bug [03:59:04 CEST] <Compn> the youtube ffmpeg firefox one [03:59:16 CEST] <Compn> maybe we should write something nicer on the patch guidelines page [03:59:26 CEST] <Compn> it sounds like its scaring contributors [03:59:36 CEST] <Compn> https://trac.ffmpeg.org/ticket/4749 [03:59:48 CEST] <Compn> "Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker." [03:59:49 CEST] <Compn> but the rules there seem to be kinda strict https://ffmpeg.org/contact.html#MailingLists [03:59:49 CEST] <Compn> I'll just drop the patches here for now, as they are. [03:59:59 CEST] <Compn> ^^ we should fix that [04:00:14 CEST] <Compn> somehow. [04:00:36 CEST] <kierank> but that youtube firefox one is for libav [04:01:02 CEST] <BtbN> It's for gst-libav which is using ffmpeg [04:01:04 CEST] <Compn> its possible he is compiling gst-libav with ffmpeg ? [04:01:06 CEST] <kierank> yes [04:01:10 CEST] <kierank> exactly [04:01:26 CEST] <BtbN> And gst using the api wrong in various ways isn't a new problem [04:01:31 CEST] <Compn> anyways i was talking about the patch submission guidelines [04:01:51 CEST] <Compn> how they maybe scaring people from posting on the ml, especially posting patches [04:02:29 CEST] <Compn> its not just this guys comment, i should say, i've seen multiple people over the years who would rather dump a patch o n a pastebin and run then register on a ml [04:02:46 CEST] <Compn> so we should have a patch dump too. if possible [04:02:52 CEST] <Compn> non registration patch dump [04:03:16 CEST] <Compn> with disclaimer that all non-copyrighted code will be accepted as lgpl v2 or later... [04:04:21 CEST] <kierank> could make an ffmpeg pastebin [04:06:35 CEST] <cone-435> ffmpeg 03Michael Niedermayer 07master:f080a01fd301: avcodec/hevc_mp4toannexb_bsf: Remove ;; [04:06:56 CEST] <rcombs> "non-copyrighted code"? [04:07:08 CEST] <mark4o> there shouldn't be a need for a pastebin, people just want to upload the patch to trac [04:07:14 CEST] <mark4o> the problem is how to review it [04:07:32 CEST] <BtbN> Someone would have to adopt the patch and send it through the usual review process [04:08:49 CEST] <Compn> oops i just approved a mail for paid hosting [04:08:57 CEST] <Compn> oh well. [06:24:10 CEST] <reynaldo> kierank: done [06:24:19 CEST] <reynaldo> just got back. Sorry for the delay [06:25:08 CEST] <reynaldo> kierank: do you still want to have access to the twitter account? [10:52:03 CEST] <michaelni> philipl, BtbN, https://github.com/FFmpeg/FFmpeg/pull/142 [10:52:46 CEST] <nevcairiel> is that a new PR with the same changes we had before? [10:53:05 CEST] <nevcairiel> hm apparently he didnt clean up before doing a new change [10:54:21 CEST] <nevcairiel> I sure hope i dont make anything blow up now [10:54:26 CEST] Action: nevcairiel pushes a merge [10:54:51 CEST] <nevcairiel> hm, it didnt let me [10:55:00 CEST] <nevcairiel> and I did put the Merged-By things in there :( [10:59:47 CEST] <nevcairiel> michaelni: are you sure there are no special permissions, putting the Merged-By: into the body doesnt seem to make the hook happy [11:01:20 CEST] <michaelni> nevcairiel, "Merged-by:" it might be case sensitive [11:01:38 CEST] <nevcairiel> hm how annoying [11:01:45 CEST] <nevcairiel> how do i reward 6 merge commits [11:01:48 CEST] <nevcairiel> reword* [11:02:31 CEST] Action: michaelni is not aware of a nice way to do that [11:04:11 CEST] <michaelni> that is nicest i know of the top of my head is reset --hard HEAD^^... and then redo with previous diffs and commit messages [11:04:53 CEST] <nevcairiel> i think filter-branch actually worked using a simple sed replace script [11:05:05 CEST] <nevcairiel> just need to verify it didnt screw anything up [11:05:13 CEST] <michaelni> yes that could work too [11:06:50 CEST] <cone-206> ffmpeg 03Michael Niedermayer 07cf1ccfffa4b72d6dc39ea8a04bc391a4ff268fb8:HEAD: avcodec/hevc_mp4toannexb_bsf: Remove ;; [11:06:54 CEST] <nevcairiel> ok that failed [11:07:02 CEST] <nevcairiel> stupid git [11:07:28 CEST] <nevcairiel> .. and i cant delete the broken branch :( [11:07:53 CEST] <michaelni> nevcairiel, ALWAYS do a --dry-run first ALWAYS [11:08:00 CEST] <nevcairiel> i did [11:08:02 CEST] <nevcairiel> it looked fine [11:09:24 CEST] <michaelni> for deleting the branch you will need j-b or thresh or some other vlc admin [11:15:15 CEST] <cone-206> ffmpeg 03Anton Khirnov 07master:90e648c508fa: fate/mp3: use the f32le format as output [11:15:16 CEST] <cone-206> ffmpeg 03Hendrik Leppkes 07master:cf1ccfffa4b7: Merge commit '90e648c508fa6b97587ce62699a1449123f7d285' [11:15:20 CEST] <nevcairiel> that looks better [11:17:59 CEST] <cone-206> ffmpeg 03Alexandra Hájková 07master:cd4d9df22738: asfdec: free AVDictionaries properly when closing the demuxer [11:18:00 CEST] <cone-206> ffmpeg 03James Almer 07master:7a7df34c91e1: blowfish: add av_blowfish_alloc() [11:18:01 CEST] <cone-206> ffmpeg 03James Almer 07master:ae365453c370: rc4: add av_rc4_alloc() [11:18:02 CEST] <cone-206> ffmpeg 03James Almer 07master:b469832de993: rc4: extend av_rc4_init() doxy [11:18:03 CEST] <cone-206> ffmpeg 03James Almer 07master:5d8bea3bb235: xtea: add av_xtea_alloc() [11:18:04 CEST] <cone-206> ffmpeg 03James Almer 07master:d9e8b47e3144: des: add av_des_alloc() [11:18:05 CEST] <cone-206> ffmpeg 03James Almer 07master:3e853ff7acc5: des: extend av_des_init() doxy [11:18:06 CEST] <cone-206> ffmpeg 03Alexandra Hájková 07master:78491fe8cfed: asfdec: do not export empty metadata [11:18:07 CEST] <cone-206> ffmpeg 03Alexandra Hájková 07master:33dc1913ab7a: asfdec: remove improper assignement that caused wrong timestamps [11:18:08 CEST] <cone-206> ffmpeg 03David Holm 07master:80ea66112817: avcodec: h264: Extract decoder methods [11:18:09 CEST] <cone-206> ffmpeg 03Hendrik Leppkes 07master:988ddfea5e32: Merge commit 'cd4d9df22738e6f147521ccb72c7930db6050914' [11:18:10 CEST] <cone-206> ffmpeg 03Hendrik Leppkes 07master:9ed59f16e005: Merge commit '7a7df34c91e16ea8936f59524145a2cdd6b790f9' [11:18:11 CEST] <cone-206> ffmpeg 03Hendrik Leppkes 07master:a130ec9540b4: Merge commit 'ae365453c370c85f278bff7fbf9e20d9d335cb2a' [11:18:12 CEST] <cone-206> ffmpeg 03Hendrik Leppkes 07master:52566efd5cf8: Merge commit 'b469832de993dabbfe037bef59c68e90e82ebca5' [11:18:13 CEST] <cone-206> ffmpeg 03Hendrik Leppkes 07master:9ca19971bcdd: Merge commit '5d8bea3bb2357bb304f8f771a4107039037c5549' [11:18:14 CEST] <cone-206> ffmpeg 03Hendrik Leppkes 07master:3cf08e96fc85: Merge commit 'd9e8b47e3144262d6bc4681740411d4bdafad6ac' [11:18:15 CEST] <cone-206> ffmpeg 03Hendrik Leppkes 07master:d95fee442528: Merge commit '3e853ff7acc56b180950ab39e7282f1b938c8784' [11:18:16 CEST] <cone-206> ffmpeg 03Hendrik Leppkes 07master:07094e5e4054: Merge commit '78491fe8cfed83d2aead95dafe26f0d3f999e961' [11:18:17 CEST] <cone-206> ffmpeg 03Hendrik Leppkes 07master:2ab827389bc1: Merge commit '33dc1913ab7aaefc991b3e665d1d0b5d0b088672' [11:18:18 CEST] <cone-206> ffmpeg 03Hendrik Leppkes 07master:db395bef7f9a: Merge commit '80ea66112817c719b476de8f7d8d3b325f4c7dd1' [11:21:43 CEST] <michaelni> \o/ [11:22:48 CEST] <nevcairiel> now i only need j-b to remove the broken branch, and I think i have most figured out how to handle this [11:26:33 CEST] <iive> congratulations :) [11:30:19 CEST] <harisk92> good morning [11:30:23 CEST] <harisk92> i need your help [11:30:26 CEST] <harisk92> did anyone tried to install ffmpeg with qsv on debian jessie [11:36:27 CEST] <cone-206> ffmpeg 03Michael Niedermayer 07master:582d98aed97a: tests/fate/mp3: Fix fate-mp3-float-extra_overread on mips-qemu [11:48:21 CEST] <j-b> nevcairiel: I'm in a week-end, in the middle of nowhere, but I can do all you want on the server, tomorrow [11:48:50 CEST] <nevcairiel> no worries, its not exactly a big problem, just some weird branch sitting there harming noone [11:51:43 CEST] <ubitux> nevcairiel: nice :) [11:51:51 CEST] <ubitux> thank you for doing this [12:19:11 CEST] <cone-206> ffmpeg 03Luca Barbato 07master:2cd841c07765: hevc: Use a proper enum for the SEI values [12:19:12 CEST] <cone-206> ffmpeg 03Hendrik Leppkes 07master:2e290d61147a: Merge commit '2cd841c0776535be56e4db67485fdd9509c9b9f4' [12:25:53 CEST] <cone-206> ffmpeg 03Luca Barbato 07master:043f46f5741e: hevc: Use switch instead of if-nests in decode_nal_sei_message [12:25:54 CEST] <cone-206> ffmpeg 03Hendrik Leppkes 07master:90ec89a629b3: Merge commit '043f46f5741e1a5caedf55d788e1a72aae3b7605' [12:29:45 CEST] <cone-206> ffmpeg 03Luca Barbato 07master:979cb55103fa: hevc: Split the sei parsing in 3 functions [12:29:46 CEST] <cone-206> ffmpeg 03Hendrik Leppkes 07master:b3e5d59537cb: Merge commit '979cb55103fa8e8274806e496901203742c686d1' [12:41:17 CEST] <cone-206> ffmpeg 03Henrik Gramner 07master:ebaf571aca2d: x86: dct: Disable dct32_float_sse on x86-64 [12:41:18 CEST] <cone-206> ffmpeg 03Alexandra Hájková 07master:fdbc544d2917: asfdec: prevent the memory leak while reading metadata [12:41:19 CEST] <cone-206> ffmpeg 03Anton Khirnov 07master:14e558024642: opusdec: properly handle mismatching configurations in multichannel streams [12:41:20 CEST] <cone-206> ffmpeg 03Hendrik Leppkes 07master:1ce298dac51c: Merge commit 'ebaf571aca2dd6ce3caeeeec4210a3fccd47e7db' [12:41:21 CEST] <cone-206> ffmpeg 03Hendrik Leppkes 07master:190e52112339: Merge commit 'fdbc544d29176ba69d67dd879df4696f0a19052e' [12:41:22 CEST] <cone-206> ffmpeg 03Hendrik Leppkes 07master:9f56aceaec5c: Merge commit '14e558024642638085ae2bbeffc6087612e6a3f9' [12:57:22 CEST] <cone-206> ffmpeg 03Michael Niedermayer 07master:8b11ce713750: avcodec/libutvideoenc: Remove coded_frame usage [13:04:24 CEST] <cone-206> ffmpeg 03Hendrik Leppkes 07master:a95210bfbdf6: MAINTAINERS: Add myself as maintainer for dxva2 and Windows/MSVC [13:19:35 CEST] <ubitux> durandal_1707: are you going to push allyuv? [13:19:55 CEST] <ubitux> i'd like to use for testing selectivecolor (and maybe more) [13:19:59 CEST] <ubitux> +it [13:20:39 CEST] <ubitux> allrgb would be nice though [13:20:51 CEST] <ubitux> if you aren't working on it already [13:34:48 CEST] <cone-206> ffmpeg 03Paul B Mahol 07master:ff8f6691ce81: avfilter/f_drawgraph: stop making foreground color transparent [13:45:21 CEST] <wm4> I love how that HN thread for the recent annoucement repeats the old inflammatory shit the internet has been spreading [13:45:42 CEST] <Shiz> stop reading hn [13:46:32 CEST] <wm4> I just looked at that thread ubitux linked (or actually, the thread that was linked from there) [13:47:05 CEST] <ubitux> well that was pretty much to be expected [13:50:24 CEST] <Shiz> man wm4 now you tricked me [13:50:26 CEST] <Shiz> >Both code bases are open source. I'm wondering if there is so much turmoil here, why doesn't someone (like VLC) take the best features from both projects and create their own library? [13:50:40 CEST] <Shiz> why am i raeding this :( [13:50:46 CEST] <wm4> lol [13:52:26 CEST] <JEEB> my condolences [13:54:17 CEST] <durandal_1707> ubitux: the colors are not perfectly positioned, do you care about it? [13:54:30 CEST] <ubitux> what do you mean? [13:55:16 CEST] <ubitux> durandal_1707: anyway, i'll probably use/write a dumb allrgb [13:55:47 CEST] <ubitux> no smart sorting whatsoever, just for testing purpose [13:56:07 CEST] <durandal_1707> if you zoom you will see its not nicely going from one color to another [13:57:06 CEST] <ubitux> okay... what would you use this filter for? [13:57:26 CEST] <ubitux> like, being pretty doesn't really help testing [13:57:39 CEST] <ubitux> or maybe for human visual testing? [14:02:09 CEST] <cone-206> ffmpeg 03Paul B Mahol 07master:ff6c92447d85: avfilter/vf_deband: add mising slice thread flag [14:05:37 CEST] <durandal_1707> well if it is continuous it makes easier testing, but I can push it as is and 'fix' it later [14:36:31 CEST] <BBB> nevcairiel: the reason for ARCH_X86_64 == 0 is x264 (x264 doesnt have ARCH_X86_32, so x264-copied bits use ARCH_X86_64 == 0, and that gets copied aorund) [14:36:43 CEST] <BBB> ARCH_X86_32 is a ffmpeg/libav'ism [14:36:49 CEST] <cone-206> ffmpeg 03Paul B Mahol 07master:49a14a7616d8: avfilter: add allyuv source filter [14:53:55 CEST] <BBB> Shiz: yesterday there was a comment isnt daala a superset of vp8 and vp9? [14:53:59 CEST] <BBB> or something like that [14:54:01 CEST] <BBB> very fun [14:54:07 CEST] <Shiz> lol [14:54:19 CEST] <nevcairiel> BBB: i'm confused [14:54:27 CEST] <nevcairiel> what are we talking about :D [14:54:40 CEST] <wm4> HN comments [14:55:04 CEST] <wm4> <BBB> Isn't VP8/9 a subset of Daala? Perhaps I'm confused. [14:55:21 CEST] <BBB> oh wait crap wrong hendrik, sorry [14:55:25 CEST] <ubitux> durandal_1707: thx [14:55:26 CEST] <BBB> nevcairiel: shouldve been gramner [14:55:30 CEST] <BBB> wasnt reading correctly [14:55:46 CEST] <nevcairiel> ah [14:55:47 CEST] <ubitux> wm4: i really wonder how they come up with something like this if it's not just pure trolling [14:55:51 CEST] <BBB> Gramner: the reason for ARCH_X86_64 == 0 is x264 (x264 doesnt have ARCH_X86_32, so x264-copied bits use ARCH_X86_64 == 0, and that gets copied aorund); ARCH_X86_32 is a ffmpeg/libav'ism (sorry poked wrong person initially) [14:56:04 CEST] <BBB> nevcairiel: apologies [14:56:07 CEST] <wm4> ubitux: they're like mini-compns [14:56:08 CEST] <Gramner> yeah, I kinda figured that out [14:56:15 CEST] <nevcairiel> BBB: no worries [15:00:46 CEST] <Gramner> btw, would you prefer if I submitted patches to ffmpeg-devel as well or are you fine with merging? so far i just posted stuff to libav-devel because michaelni was awesome at merging stuff and I was lazy (sorry) [i have no intention of getting involved with any "politics" regarding the two projects] [15:07:37 CEST] <Compn> Gramner : good question. some devs submit to both lists to get more reviews and then send updated patches to both lists [15:08:11 CEST] <Compn> just depends how much work you want to do [15:08:57 CEST] <iive> i'd say it is better if you do the merge, since you should know your code better :) [15:10:03 CEST] <Compn> ubitux / wm4 : you guys may do well to understand that people may not communicate perfectly, and that misunderstandings may seem like trolls but if you take the time to explain things or ask for clarification, there will be less problems. [15:11:25 CEST] <Compn> BBB : also i blame there being 4 or 5 different names for each new codec. h265 , hevc or vp3/theora or h264/mpeg4avc/x264 (yes x264 derp). [15:12:11 CEST] <Compn> even though i said 4-5 my examples only list 2... [15:12:35 CEST] <Shiz> theora isn't vp3, just vp3-based [15:12:57 CEST] <RiCON> <+wm4> <BBB> Isn't VP8/9 a subset of Daala? Perhaps I'm confused. <- reddit, actually [15:13:34 CEST] <Compn> Shiz : i stand corrected. [15:15:38 CEST] <BBB> Gramner: whatever is easiest for you, at this point [15:15:50 CEST] <BBB> Gramner: so if you like it this way, its fine with me [15:16:00 CEST] <BBB> (thats just my opinion, others may disagree) [15:16:37 CEST] <BBB> I thought theora was vp3 in bitstream terms? [15:16:42 CEST] <BBB> I mean, at least the core bitstream [15:16:46 CEST] <BBB> the header is different perhaps [15:16:56 CEST] <Gramner> iive: I guess that's true, but then people from both MLs might waste time pointing out the same issue. I could wait for stuff to get accepted on one project, and after that sumbit it to the other? of course, then some other issue might be found and a fix has to be submitted to the first project. [15:17:03 CEST] <BBB> (they wanted hw bw compat) [15:18:08 CEST] <iive> Gramner: that's why you work in parallel :) [15:18:37 CEST] <Shiz> BBB: fair point, i don't think it deviates from vp3 that much [15:19:09 CEST] <BBB> vp8 or vp9 have only marginal relationship to each other, in terms of bitstream [15:19:15 CEST] <BBB> the codebase is clearly derived [15:19:26 CEST] <BBB> but the bitstream is & only very marginally similar [15:19:46 CEST] <BBB> things like nearmv/nearestmv/zeromv/newmv still exist, but other than that, pretty much everything changed [15:19:59 CEST] <BBB> and daala vs vpN, well, no similarity whatsoever [15:20:46 CEST] <Gramner> how about I just buy everyone enough beer at VDD to make you drunk enough to make out with each other instead? [15:23:33 CEST] <beastd> Gramner: It is never perfect :( I think it is fine to submit to both lists and wait for review. You will have to judge yourself about resubmissions and such... [15:24:11 CEST] <durandal_1707> comments for atadenoise? [15:25:15 CEST] <beastd> Gramner: VDD is a really nice event. I attended 2-times myself. But I am on par with ubitux that it is kind of a bad "solution" for "re-union" of FFmpeg and Libav... [15:26:15 CEST] <BBB> Gramner: beer sounds good, ty [15:26:38 CEST] <BBB> (dont I buy you beer? youve done tons of work on x86inc.asm in the past years, were just using it :) ) [15:27:46 CEST] <Gramner> beastd: maybe that's true, but I don't really know enough of the backstory (and tbh I'm not really interested in looking at the past either) to comment on that [15:28:05 CEST] <beastd> BBB, Gramner: Please share the beers at VDD however you want -- I never meant to interfere with that ;-) [15:29:10 CEST] <BBB> I guess we all get beer [15:29:38 CEST] <Gramner> all I know is that I met some devs last year at VDD and they all seemed like decent folks [15:30:49 CEST] <beastd> Gramner: Understood. Please be sure to continue conrtibuting in whatever way seems best for you. I do not think that situation is as grim as it looks. We'll see... [15:31:10 CEST] <Shiz> my personal opinion would be that discussions about any potential re-unions should be focused on online/irc/ml discussions, for a number of reasons [15:31:26 CEST] <Shiz> 1) clearly not every ffmpeg/libav developer can make it to VDD, including some of the 'main' people [15:31:38 CEST] <Shiz> 2) real-life discussions have different dynamics than online ones, which may be detrimental to some people and the points they are able to make, no matter how valid (we ARE nerds here, after all...) [15:31:51 CEST] <Shiz> 3) real-life discussions lack the important feature of being loggable easily [15:32:52 CEST] <beastd> Shiz: ack. well said. [15:33:03 CEST] <Shiz> that is not to say discussion can't take place at VDD, but it shouldn't be the 'main venue' for it [15:33:09 CEST] <Shiz> in my opinion [15:34:16 CEST] <Nightrose> mediation experience: if you want to make any significant progress it needs to be f2f - just my 2ct [15:36:39 CEST] <Gramner> I do believe it's easier to have discussions online with people you have met IRL though, so even if VDD isn't _the_ solution you could always just go there and have good time while focusing on other stuff (or maybe you all know each other already? i have no clue) [15:36:54 CEST] <Compn> wedesoft 1 day ago [15:36:54 CEST] <Compn> To whoever contributed to it: the swscale library (colorspace conversions) was really helpful during my PhD work. [15:37:04 CEST] <Compn> ^ michaelni , someone found swscale useful :) [15:39:13 CEST] <beastd> Nightrose: You can discuss face to face of course, but results need to be written down and sent to the projects communication backbone like fffmpeg-devel ml for public scrutiny if they matter in anyway. if it is about laying aside personal differences that is sth different. [15:39:27 CEST] <Nightrose> sure [15:39:45 CEST] <Compn> heh [15:39:53 CEST] <Compn> Nightrose was there at vdd during the libav ffmpeg meeting [15:40:03 CEST] <wm4> Shiz: I'm also a bit suspicious against the IRL meeting, but why not try it? [15:40:16 CEST] <Compn> the meeting was transcribed too [15:40:47 CEST] <Compn> at least one of them. [15:40:48 CEST] <ubitux> nothing will be achieved at irl meeting, because many ffmpeg developers won't be present so any negociation will be meaningless [15:41:15 CEST] <ubitux> in the best situation, some devs will agree, and when going back online, you'll get some opposition [15:41:34 CEST] <ubitux> (and the ppl who are exclusively online will be accused of fucking up everything) [15:41:43 CEST] <Compn> just want to work on code, dont want to organize anything... [15:42:39 CEST] <ubitux> if the negociation ends up with "alright, now we need to review everything in ffmpeg", how do you think it's going to be accepted for those who werent present? [15:42:42 CEST] <Shiz> wm4: sure, i even said that's not to say discussion can't take place there [15:42:50 CEST] <Shiz> but i don't think any final decisions should be taken there [15:42:52 CEST] <Shiz> :P [15:42:55 CEST] <wm4> even online, "some" people will barge in later and destroy all discussion that has been had earlier [15:43:12 CEST] <wm4> because these "some" people were mysteriously not available during the online discussion [15:43:19 CEST] <ubitux> wm4: except you can setup some vote system over several days or whatever online [15:43:40 CEST] <ubitux> and it's much harder to do that in a small time window in a single place on earth [15:44:02 CEST] <ubitux> so yeah it's not perfect online, but real life is not going to be any better in that regard [15:44:52 CEST] <Shiz> i think real life certainly can help, partially also due the different conversation dynamics involved [15:44:57 CEST] <Nightrose> except that voting on something will not solve your issues [15:44:59 CEST] <Shiz> so i wouldn't write it off as useless [15:45:04 CEST] <Shiz> just not the end-all be-all [15:45:19 CEST] <Compn> ubitux : no reason to argue about it, wont change anything :P [15:45:56 CEST] <Compn> ubitux : i almost wrote something in reply to unification email on ffmpeg-devel , but i dont think it will help so i rm'd it. [15:46:08 CEST] <Compn> i'll try to post something later , think up some ideas. [15:46:12 CEST] <ubitux> Nightrose: we don't know what the issues are, no one on libav side said what they want yet; almost every wishes has been granted in ffmpeg over the years [15:46:38 CEST] <Nightrose> ubitux: exactly. that's why a vote won't help you if you don't even know what to vote on ;-) [15:46:59 CEST] <ubitux> Nightrose: but my guess is that they're going to push development methods incompatible with ffmpeg ones (from what i could tell on irc) [15:47:10 CEST] <wm4> ubitux: they want their git tree [15:47:20 CEST] <ubitux> Nightrose: and don't you think it would be simpler for everyone if they expressed their needs in a few sentences? [15:47:37 CEST] <ubitux> wm4: ah? well that won't work then [15:47:52 CEST] <ubitux> no need for a meeting [15:48:05 CEST] <ubitux> end of the story, lets not waste everyone's time :) [15:48:37 CEST] <Compn> j-b : whos tree should we use? pick tree. [15:49:13 CEST] <ubitux> btw, i don't think i will attend VDD if they don't make the wish list [15:49:34 CEST] <Compn> you could attend, but skip any meetings, as i will be doing [15:49:34 CEST] <Shiz> q: has anyone actually approached them yet to ASK what they want [15:49:41 CEST] <ubitux> Shiz: yes [15:50:38 CEST] <wm4> ubitux: I hope you're joking [15:50:59 CEST] <ubitux> who knows [15:51:28 CEST] <ubitux> Shiz: we got a few disconcerted answers on irc, but no one has written anything yet [15:51:28 CEST] <Compn> gotta bbl. please dont all ragequit the project. its still kinda fun working on it [15:52:42 CEST] <Shiz> what about preparing an "official" (as official as a statement from ffmpeg can get) post to their ML? [15:52:51 CEST] <Shiz> you may get a more coherent answer is a nontransient medium [15:52:59 CEST] <Shiz> in a* [15:53:18 CEST] <ubitux> i'm unsure about forwarding the thread i started the other day [15:53:27 CEST] <ubitux> might make them angry for whatever reason [15:53:44 CEST] <ubitux> that is, http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-August/176556.html [15:53:53 CEST] <ubitux> they were requested to do something similar to this [15:53:55 CEST] <Compn> we should have j-b ask libav about a statement [15:54:03 CEST] <ubitux> but i'm starting to doubt they will [15:54:13 CEST] <ubitux> Compn: he did [15:54:15 CEST] <Shiz> putting a list of demands in their lap may come across as intimidating, yes [15:54:20 CEST] <Compn> oh good then [15:58:11 CEST] Action: Compn afk [16:00:19 CEST] <durandal_1707> there is lack of manpower on both sides [16:00:32 CEST] <ubitux> yeah, definitely [16:02:41 CEST] <ubitux> lack of manpower, but keep duplicating stuff anyway ;) [17:07:27 CEST] <kierank> Well put [17:31:32 CEST] <jamrial> nevcairiel: is that new branch in one of the merges intended? [17:33:37 CEST] <ricotz> hello, could someone take a look at libshine.c failure https://paste.debian.net/plain/288432 -- https://paste.debian.net/plain/288433 [17:36:39 CEST] <ubitux> jamrial: the branch was a mistake apparently, but it can't be removed without the help of videolan admins [17:38:39 CEST] <jamrial> ah ok [17:42:20 CEST] <ubitux> ricotz: lgtm, looks like a chunk forgotten in e36db49b [17:42:31 CEST] <ubitux> and it seems to be the only instance [17:42:48 CEST] <ubitux> ricotz: can you send a patch? [17:45:20 CEST] <BBB> ubitux: I will be there [17:45:45 CEST] <BBB> ubitux: wont you? [17:45:50 CEST] <BBB> ubitux: jb is paying :D [17:46:06 CEST] <ubitux> not a money problem; i live in paris you know :p [17:46:48 CEST] <BBB> rly [17:46:54 CEST] <BBB> I thought you were belgian [17:47:02 CEST] Action: BBB feels stupid [17:47:13 CEST] <ubitux> sorry to disappoint you [17:47:22 CEST] <ubitux> :) [17:47:30 CEST] <BBB> ok [17:47:31 CEST] <BBB> so [17:47:36 CEST] <BBB> we have a conference in your homewotn [17:47:39 CEST] <BBB> *town [17:47:42 CEST] <BBB> and youre not coming? [17:47:54 CEST] <BBB> Im flying over all the way from americanistan, you know [17:49:11 CEST] <ubitux> i might come, but i hate these meetings anyway [17:55:16 CEST] <wm4> does anyone have an idea what could break HLS after timestamps go over ~24 hours? [18:01:44 CEST] <BBB> wm4: Im going to say timestamp overflow [18:01:46 CEST] <BBB> but I dont know [18:02:06 CEST] <BBB> ubitux: I think we all hate meetings to some extend, but it does help to talk face to face sometimes, even if its just to say hi and have a beer [18:02:11 CEST] <BBB> (you drink beer right?) [18:02:55 CEST] <ubitux> i don't drink alcohol [18:03:33 CEST] <ubitux> i also don't eat anymore btw (joylent master race) [18:05:05 CEST] <BBB> um [18:05:06 CEST] <BBB> ok [18:05:20 CEST] <BBB> so how do I bribe you? [18:05:30 CEST] <BBB> the normal candidates dont seem to work for you [18:06:30 CEST] <ubitux> i don't know how to bribe myself anymore [18:07:26 CEST] <ubitux> anyway, see if you can make libav communicate a little before the event [18:07:28 CEST] <ubitux> that might help. [18:07:41 CEST] <michaelni> Gramner, as the one doing merges in the past, i definitly preferred patches on ffmpeg-dev and no extra merge work but iam not the one doing the merges anymore. Still patches developed on ffmpeg, tested on ffmpeg are better then if they are developed on a branch that forked 4+years ago, theres some risk that code merged has new issues after merging [18:10:24 CEST] <Gramner> michaelni: got it, i'll try to [18:10:36 CEST] <Gramner> post stuff on ffmpeg-devel [18:10:57 CEST] <michaelni> thanks! [18:12:20 CEST] <ricotz> ubitux, https://paste.debian.net/plain/288437 [18:22:43 CEST] <cone-962> ffmpeg 03Paul B Mahol 07master:5b69fb783e9d: avfilter: add atadenoise [18:49:29 CEST] <cone-962> ffmpeg 03Paul B Mahol 07master:3fe01eca21d5: avcodec/xfaceenc: remove coded_frame usage [19:03:15 CEST] <cone-962> ffmpeg 03Rico Tzschichholz 07master:a0044beccac8: libshine: Fix faulty ff_alloc_packet2 usage [19:03:23 CEST] <ubitux> ricotz: thx [19:33:40 CEST] <BBB> ubitux: Im not in active communication with any of them, sadly [20:31:29 CEST] <kierank> ubitux: [20:31:30 CEST] <kierank> 5:03 PM <"ubitux> i also don't eat anymore btw (joylent master race) [20:31:32 CEST] <kierank> is it any good? [20:32:13 CEST] <nevcairiel> i tried it, and i couldnt do it [20:32:33 CEST] <nevcairiel> even with a proper mixer, i couldnt get it to stop tasting like dust in my mouth [20:32:40 CEST] <ubitux> i didn't really like it at the beginning, but now i can't do without it, and i enjoy it pretty much [20:32:54 CEST] <kierank> I struggled with zero noodles but I've been eating them for a year [20:33:22 CEST] <kierank> so i wonder if this stuff is any good [20:33:41 CEST] <kierank> my friend made is own joylent [20:33:41 CEST] <ubitux> it definitely doesn't taste good in the beginning [20:33:44 CEST] <kierank> buying random ingredients [20:33:59 CEST] <ubitux> but well, after a few weeks it's pretty much ok [20:34:46 CEST] Action: jamrial wonders what's wrong with actual food that people need to come up with these alternatives [20:35:08 CEST] <kierank> takes too long to cook [20:35:14 CEST] <ubitux> and you need to think about it [20:35:41 CEST] <nevcairiel> i mostly order in these days because i'm too lazy to cook, and i have like 3 things i order because i cba to think about new things =p [20:35:54 CEST] <kierank> nevcairiel: lol [20:35:55 CEST] <nevcairiel> so i liked the general idea, but i just couldnt do it [20:35:58 CEST] <kierank> I cba to cook new things [20:36:00 CEST] <kierank> I do know how to cook [20:36:21 CEST] <nevcairiel> someone suggested i should leave it in the fridge over night to get rid of the dust-y taste [20:36:29 CEST] <nevcairiel> but i never bothered after the first try :d [20:37:25 CEST] <kierank> how long does joylent take to arrive? [20:37:56 CEST] <nevcairiel> usually pretty fast [20:37:57 CEST] <ubitux> very variable; they don't have banana anymore currently so it might take a while if you take a mix with some [20:38:02 CEST] <jamrial> well, i'm not a fan of cooking, but even if it's something quick i very much prefer eating proper meals :p [20:38:09 CEST] <kierank> oh I bought one of each [20:38:13 CEST] <kierank> really looking forward to it [20:38:30 CEST] <ubitux> nevcairiel: cold can taste somehow better, but it's way more thick [20:38:46 CEST] <thresh> what about your family? did they also convert? [20:38:54 CEST] <ubitux> honestly i don't mind the "dust" anymore [20:39:04 CEST] <ubitux> i usually drink the meal in about 3 minutes [20:47:56 CEST] <cone-962> ffmpeg 03Michael Niedermayer 07master:4a8ec0218e0a: avcodec/avuienc: Use ff_alloc_packet2() [20:47:57 CEST] <cone-962> ffmpeg 03Michael Niedermayer 07master:107026ea8188: avcodec/aliaspixenc: Use ff_alloc_packet2() [21:38:30 CEST] <BBB> jamrial: Im wondering the same thing, I love a good steak with baked potatoes or similar stuff [21:38:35 CEST] <BBB> yummy [21:38:55 CEST] <BBB> or even something simple like a nice sandwitch [21:39:12 CEST] <BBB> theres whole newspaper articles on making good, yummy sandwitches if you want to do it at home [21:45:14 CEST] <jamrial> when i have time i cook an elaborate meal, but if i'm in a hurry a burger, salad or something quick like that does the trick [21:45:48 CEST] <jamrial> and when i'm lazy i just order a pizza :p [21:47:29 CEST] <Compn> protein shakes yuck :P [21:47:40 CEST] <Compn> stick to eating hemp... [21:49:39 CEST] <cone-962> ffmpeg 03Michael Niedermayer 07master:06f265989194: avcodec/v210enc: Use ff_alloc_packet2() [21:49:40 CEST] <cone-962> ffmpeg 03Michael Niedermayer 07master:7e9cd4e10008: avcodec/libwebpenc: Use ff_alloc_packet2() [22:03:58 CEST] <iive> soilent is more than protein shake. it contains all nutrients. [22:05:45 CEST] <iive> i'm quite sure that ubitux wouldn't mind having a nice meal, if he is not the one who have to make it. [22:06:50 CEST] <wm4> if you want to know his motivations, why don't you ask him [22:11:22 CEST] <iive> what make you think that? [22:12:26 CEST] <wm4> instead of loudly guessing his motivations [22:16:12 CEST] <iive> he already pretty much explained it already. no need to ask him. [22:16:59 CEST] <iive> <kierank> takes too long to cook \n <ubitux> and you need to think about it [22:19:58 CEST] <kierank> Compn: i've just bought some [22:20:04 CEST] <kierank> it's a great idea [22:20:12 CEST] <kierank> I've been waiting for soylent for ages [22:22:31 CEST] <iive> just don't take the green one. [22:23:25 CEST] <iive> ;) [22:25:21 CEST] <iive> tbh, i've heard about it, but I had no idea it had reached Europe. [22:27:33 CEST] <Compn> kierank : hemp? yes hemp is great... [22:27:37 CEST] <Compn> oh joylent, ok then [22:27:50 CEST] <kierank> ubitux may have changed my friends life [22:27:54 CEST] <kierank> he has been waiting years for this moment [22:28:09 CEST] <Compn> http://www.joylent.eu/products/joylent-vegan has hemp in it [22:28:43 CEST] <Compn> the text makes it sound like the regular joylent has meat in it [22:33:59 CEST] <Compn> http://joylent.s3.amazonaws.com/how_to_use/english.pdf [22:34:03 CEST] <Compn> guh [22:34:48 CEST] <nevcairiel> regular soylent has fish in it [22:36:38 CEST] <Compn> ah [22:36:41 CEST] <nevcairiel> fish oil to be precise for fat [22:36:54 CEST] <Compn> wheres the antioxidents though? [22:37:55 CEST] <nevcairiel> plenty vitamin C and E which serve that purpose [22:39:34 CEST] <iive> so, joylent and soylent are different brands? [22:40:01 CEST] <Compn> different name of same brand possibly for usa/uk audience ? [22:40:11 CEST] <nevcairiel> joylent is for the EU [22:40:18 CEST] <iive> that's what i want to know. [22:40:20 CEST] <nevcairiel> had to split it for reasons [22:40:34 CEST] <nevcairiel> probably importing such food into the EU would be problematic [22:40:40 CEST] <nevcairiel> so they renamed and produce it here [22:40:42 CEST] <iive> so... it is subdevision of soylent? [22:40:57 CEST] <iive> not competition? [22:41:18 CEST] <iive> i see that joylent delivers all over the world. [22:42:04 CEST] <nevcairiel> its not real competition as soylent is still only in the US i think, and joylent focus on everything else, but i dont think its directly run by the same people [23:12:34 CEST] <cone-962> ffmpeg 03Michael Niedermayer 07master:0508657f42ed: avcodec/cngenc: Use ff_alloc_packet2() [23:13:02 CEST] <ubitux> nevcairiel: i think soylent ended up dropping it [23:13:24 CEST] <ubitux> joylent has some original stuff anyway, it's kind of different (and cheaper) [23:13:47 CEST] <ubitux> they're looking into doing solid food btw (less preparation, yay) [23:18:55 CEST] <atomnuker> food that gets you everything you'll need/might need all in one, huh? [23:19:08 CEST] <atomnuker> this reminds me of the soup they had on the ship in the first matrix movie [23:19:30 CEST] <nevcairiel> It looks like that too :p [23:19:48 CEST] <ubitux> and it's not tasty either (at least at the beginning) [23:19:56 CEST] <nevcairiel> Solid may be interesting [23:20:00 CEST] <atomnuker> I don't think I'm ready to join such a future yet though [23:52:05 CEST] <nevcairiel> man this qsv decoder is so many levels of f'ed up [23:52:13 CEST] <nevcairiel> dont try seeking with it, it wont be pleasant [23:52:32 CEST] <Daemon404> i have a rule of thumb [23:52:44 CEST] <Daemon404> if the commit messages doesnt understand tenses, it's prob bad [23:52:47 CEST] <nevcairiel> you know what the stupid thing is [23:52:53 CEST] <Daemon404> stuff like "added thing decoder" [23:52:56 CEST] <Daemon404> or "adding thign decoder" [23:53:00 CEST] <nevcairiel> the one which was not merged from libav would've actually worked =p [23:53:09 CEST] <wm4> hurrr [23:53:15 CEST] <Daemon404> lmao [23:53:24 CEST] <j-b> of course [23:53:30 CEST] <j-b> I said so many times [23:53:33 CEST] <nevcairiel> but we have some random corporate drone sending broken decoders :D [23:53:40 CEST] <j-b> the MPEG-2 one is sooo wrong it's not funny [23:53:49 CEST] <nevcairiel> they are all equally wrong [23:53:51 CEST] <wm4> whatever happened to code quality [23:53:56 CEST] <Daemon404> ... hw decoding mpeg-2? [23:53:58 CEST] <nevcairiel> dunno [23:54:00 CEST] <nevcairiel> i tried to review them [23:54:03 CEST] <nevcairiel> but it was ignored [23:54:07 CEST] <wm4> awesome [23:54:15 CEST] <nevcairiel> the guy sending the patches isnt very smart [23:54:18 CEST] <j-b> I know people don't like Lu_zero and Anton, but come on, their decoder is twice longer. It's not because they like pain... [23:54:19 CEST] <nevcairiel> or very bad at english [23:54:21 CEST] <nevcairiel> one of those [23:54:39 CEST] <j-b> the guy does not even flush anything... [23:54:43 CEST] <wm4> does the Libav have the usleep calls? [23:54:52 CEST] <kierank> some intel bugs iirc [23:54:55 CEST] <nevcairiel> wm4: thats normal for hardware decoders [23:55:01 CEST] <nevcairiel> dxva has that too [23:55:06 CEST] <nevcairiel> sometimes hardware is busy and you gotta wait [23:55:17 CEST] <wm4> mmal, vdpau, vaapi don't [23:55:26 CEST] <nevcairiel> maybe they do it internally then [23:55:29 CEST] <wm4> mmal for one is an async decoder, but has an event-based approach [23:55:48 CEST] <nevcairiel> for dxva it depends on the driver [23:56:01 CEST] <nevcairiel> only ever seen nvidia return the "eagain" error code [23:56:05 CEST] <nevcairiel> others just seem to block [23:56:18 CEST] <j-b> wm4: I did not see the sleep on the mpeg2 one. [23:56:40 CEST] <j-b> but, seriously, on the mpeg2 one, there are 20 lines of code. [23:56:47 CEST] <j-b> that can't be right. [23:57:01 CEST] <nevcairiel> apparently thats how all decoders should look now since the magic happens in shared code [23:57:42 CEST] <j-b> without doing anything in flush ? [23:58:38 CEST] <nevcairiel> thats another issue entirely [23:58:42 CEST] <nevcairiel> it could call a central flush [23:59:00 CEST] <j-b> magically? [23:59:24 CEST] <michaelni> please report the issues and problems you raise here to Ivan Uskov [23:59:38 CEST] <nevcairiel> we should just use the libav decoder, it actually works [23:59:40 CEST] <Daemon404> history has shown that doesn't work, fyi [23:59:43 CEST] <j-b> Ivan is an incompetent coder who's paid by the hour [23:59:50 CEST] <Daemon404> [22:54] <+nevcairiel> i tried to review them [23:59:50 CEST] <Daemon404> [22:54] <+nevcairiel> but it was ignored [23:59:57 CEST] <wm4> damn Daemon404 was faster [00:00:00 CEST] --- Mon Aug 3 2015

1 0

ffmpeg.log.20150802
by burek 03 Aug '15

03 Aug '15

[02:28:35 CEST] <swift110> hello all [02:28:55 CEST] <swift110> I am trying to convert a file from 3gp to .flac how do I do that [02:29:01 CEST] <swift110> I have linux mint 17.2 btw [02:29:09 CEST] <c_14> ffmpeg -i file.3gp out.flac [02:30:39 CEST] <swift110> thanls [02:31:21 CEST] <swift110> linux mint used avconv can i just substitute that for ffmpeg [02:31:25 CEST] <swift110> ? [02:32:57 CEST] <swift110> http://dpaste.com/3XNBNN1 [02:33:13 CEST] <c_14> You'll probably want to dl a static build from [02:33:17 CEST] <c_14> http://johnvansickle.com/ffmpeg/ [02:33:33 CEST] <c_14> Though avconv should also work for you (support for avconv is in #libav though) [02:33:58 CEST] <swift110> ok thanks [02:52:26 CEST] <Pursuit> I'm writing a small script that runs an ffmpeg command and logs its output to a file. I'm getting hundreds of these entries: http://paste.fedoraproject.org/250625/38476657/ [02:52:46 CEST] <Pursuit> I'd like to make it only output the startup/shutdown messages and any errors encountered [02:55:05 CEST] <c_14> -loglevel error [02:57:54 CEST] <Pursuit> c_14: Hmm, that makes it output nothing... is there no in-between? [02:58:22 CEST] <c_14> you can try warning [02:58:31 CEST] <c_14> default is info [03:02:06 CEST] <Pursuit> alright, no logs it is then! at least by default. that's what configs are for ;) [03:31:56 CEST] <well0ne> sup everyone [04:29:47 CEST] <pgimeno> does ffmpeg support any raw video+audio format? e.g. raw .dv? [04:33:55 CEST] <relaxed> pgimeno: yes [04:42:38 CEST] <pgimeno> relaxed? thanks, what formats does it support and how do I select them? [04:55:49 CEST] <relaxed> pgimeno: what are you doing? [05:06:25 CEST] <relaxed> ffmpeg -i input output.dv [07:01:45 CEST] <aptwebapps> As I understand it, -vcodec copy does not do any encoding. Is there a way to re-encode, but to extract the parameters/codec from the file? [07:02:00 CEST] <aptwebapps> Or more to the point, from one of the files when combining multiple files? [07:02:40 CEST] <aptwebapps> Or do I have to do my homework and figure out what parameters to specify to reproduce the desired encoding? [07:04:02 CEST] <aptwebapps> If that's not clear enough, I have three mp4s I want to combine into one. The first one has a slightly different encoding than the other two. They were not encoded by ffmpeg in the first place, AFAIK. (Youtube) [07:26:14 CEST] <pgimeno> relaxed: sorry, I tried that but got this error: "Error while opening encoder for output stream #0.0 - maybe incorrect parameters such as bit_rate, rate, width or height" [07:27:30 CEST] <pgimeno> I also tried -vcodec rawvideo, to no avail [07:28:26 CEST] <relaxed> pgimeno: try, ffmpeg -i input -target dv output.dv [07:29:24 CEST] <pgimeno> ok, -target pal-dv seems to work, thanks! [07:29:50 CEST] <pgimeno> (got an error that I neeed to specify pal-, ntsc- or film- so I did) [07:51:55 CEST] <CitizenJane> I need to determine the GOP structure of a mp4 video I have [07:52:00 CEST] <CitizenJane> is there a command for this? [08:05:40 CEST] <pgimeno> thanks again [09:51:22 CEST] <xerox> anybody had success with brew install ffmpeg --with-ffplay on osx? it does not seem to install ffplay at all [10:32:51 CEST] <spaam> xerox: did you install sdl? [10:33:10 CEST] <kvz> Hi. I work for a company that has a big interest in ffmpeg. We heard about Michael's departure and are wondering what we can do to help the project. While there's probably not much in terms of healing that we can do, maybe we can at least make sure there are no other obstacles. We noticed the question about hosting, has that been taken care of already? If not we would like to offer ffmpeg hosting of the project for free. [10:37:00 CEST] <xerox> spaam: it did install libsdl yes [10:40:28 CEST] <xerox> I'm going to try to compile it again [10:42:21 CEST] <xerox> the brew formula does not seem to imply X11 is necessary for it, is it? [10:43:05 CEST] <xerox> https://github.com/Homebrew/homebrew/blob/master/Library/Formula/ffmpeg.rb [10:46:11 CEST] <xerox> oh it was PEBKAC, my fault, thanks [10:49:37 CEST] <michaelni> kvz, hosting _probably_ has been taken care of. We still search for some trusted volunteers to move all services over into some virtualized environments (qemu or whatever) for better isolation/security/future migration ... [11:00:53 CEST] <kvz> michaelni: Good to hear. I might still be able to help tho with my background. I founded transloadit.com (wanting to sponsor ffmpeg hosting via that entitity) but I was the tech lead of a hosting company for 8 years before that. We could e.g. address those concerns via packer, docker, and terraform. open source tools that I've come to use & love and are imho perfect for better isolation/security/future migrations. [11:04:57 CEST] <kvz> I'm unsure how far you are, and am certainly not looking to poke in people's solutions or get into fights over picked tech. But if you're still in the early stages and these things sound interesting please feel free to reach out. I owe a lot to ffmpeg and would be willing to return a favor and discuss this further [11:13:58 CEST] <michaelni> kvz, probably best to contact beastd or just mail root @ ffmpeg, i idont think theres anything very far yet [11:19:25 CEST] <kvz> michaelni: Will mail root, thanks. And also I want to voice my appreciation for your work these past 14 years. It's humbling, and I hope you'll stick around [11:27:32 CEST] <harisk92> good morning people [11:27:38 CEST] <harisk92> i need your help [11:27:57 CEST] <harisk92> did anyone tried to install ffmpeg with qsv on debian jessie [11:40:52 CEST] <CitizenJane> I need to determine the GOP structure of a mp4 video I have [11:41:02 CEST] <CitizenJane> is there a command for this? [11:54:19 CEST] <CitizenJane> ugh you lousy ingrates! I have a corporate presentation due tomorrow and I have to get it done before my manager complains! [11:54:41 CEST] <CitizenJane> god? aren't you guys supposed to be here to help people? what kind of product is this [11:55:16 CEST] <CitizenJane> I NEED AN ANSWER. I've been here for almost FIVE hours now [11:55:31 CEST] <CitizenJane> HELP ME SOLVE MY VIDEO ISSUE. thanks! [12:00:57 CEST] <iive> hehehe [12:01:18 CEST] <iive> your question is quite specific... [12:01:40 CEST] <JodaZ> CitizenJane, use the showinfo filter maybe? it shows "type:B" "type:P" etc for the individual frames [12:02:15 CEST] <CitizenJane> Yeah, and that works for mpeg's? How do I use that filter, is there a page on it? [12:02:40 CEST] <CitizenJane> also, good morning, thanks for waking up, or I dunno, finally deciding to help me [12:02:59 CEST] <iive> btw, i'd direct you toward ffprobe documentation, it have an option to display frame types and other stuff. [12:03:01 CEST] <CitizenJane> but yeah, continue [12:03:21 CEST] <iive> not sure if this would include Group Of Picture information [12:03:48 CEST] <CitizenJane> Jodaz seems like he can help me but he isn't spilling. [12:03:51 CEST] <CitizenJane> SPILL [12:04:07 CEST] Action: CitizenJane throws a chair at Jodaz SPILL so I can be done with this and get some sleep [12:04:19 CEST] <CitizenJane> please [12:04:24 CEST] <JodaZ> CitizenJane, you should be able to find an example of how to use showinfo in a ffmpeg commandline yourself >_> [12:05:26 CEST] <CitizenJane> Oh right, you don't want to save me a few minutes of searching, you'd rather sadistically have me try and fail, then come back here after wasting 30 minutes of scanning the ffmpeg documentation only to have you finally explain it more clearly [12:05:28 CEST] <JodaZ> ffmpeg -i file.mpg -vf showinfo -an -y test.mp4 [12:05:30 CEST] <CitizenJane> No no silly me [12:05:46 CEST] <CitizenJane> I'm just being cranky, excuse me for wanting to make my morning easier [12:05:49 CEST] <JodaZ> tho i am not sure if it works on input or output, hmm [12:09:40 CEST] <iive> ffprobe -show-frames -i file.mp4 [12:09:48 CEST] <iive> ops.. -show_frames [12:13:56 CEST] <CitizenJane> precisesly why I ask for an explanation before I search [12:14:03 CEST] <CitizenJane> this happens all of the time here [15:27:31 CEST] <Boscop> hi. is ffmpeg the easiest way to create my own visual effects (processing each video frame)? [19:14:55 CEST] <well0ne> sup'? [21:11:57 CEST] <Blueeyez> It would be nice if you did show on the donations page how much you have recived in donations.. also maby the expected amount of bills... [21:23:32 CEST] <durandal_170> Blueeyez: request like this are done on bug tracker otherwise they are ignored [21:24:27 CEST] <Blueeyez> durandal_170 thanks :) [23:51:30 CEST] <quux> hi [23:51:35 CEST] <quux> why is there a fork? [00:00:00 CEST] --- Mon Aug 3 2015

1 0

ffmpeg-devel.log.20150801
by burek 02 Aug '15

02 Aug '15

[00:08:50 CEST] <nevcairiel> I cant say I have much experience with any of those review tools, I used the one from the atlassian suite at work for a bit but I didn't really like it that much [00:09:14 CEST] <jamrial> BtbN: if you check the mailman archives for the email in question you can click on the sender's address which is a mailto: link with the id of the email embedded [00:09:28 CEST] <nevcairiel> But obviously any workflow we use should satisfy two basic requirements. 1) Easy to submit patches, 2) Easy to review/get feedback [00:09:59 CEST] <nevcairiel> Just from years of watching ffmpeg-devel, ML doesn't really fullfil (1) [00:10:08 CEST] <nevcairiel> people struggle way too o ften with git and patch sending =p [00:10:26 CEST] <BtbN> well, new devs struggling with git won't change [00:10:35 CEST] <BtbN> jamrial, good to know, thanks [00:11:39 CEST] <nevcairiel> I suppose one of those tools that sits on top of the ML and manages patch sets could maybe satisfy (2), but since people do struggle with patches and mail, those tools often get confused [00:11:56 CEST] <nevcairiel> so some integrated solution that somehow does both better would be something worth thinking about [00:12:12 CEST] <BtbN> Can't reviewboard/gerrit automaticaly import patch-mails? [00:12:32 CEST] <Shiz> phabricator is not fantastic from my experience [00:12:57 CEST] <nevcairiel> like i said such tools exist, but there is often manual labor involved because people mess up references in the mails and break threads and whatnot [00:12:59 CEST] <Shiz> another option is hooking up github issues to an ML [00:13:12 CEST] <Shiz> and have bidirectional sync [00:13:25 CEST] <BtbN> There definitely won't be an imediate switch, but not doing anything won't be one at all. [00:15:04 CEST] <peloverde> does gerrit offer a lighter comment comment system than the one used by chromium's instance? [01:41:43 CEST] <andrewrk> philipl, what's wrong with github PRs? (I'm not defending them, just didn't know of any problems and curious) [01:50:11 CEST] <cone-377> ffmpeg 03Ihar A. Tumashyk 07master:293e25be615d: libavcodec/utils: av_get_exact_bits_per_sample fixed to return "1" for DSD codecs. [02:23:57 CEST] <cone-377> ffmpeg 03Yu Xiaolei 07master:2ef6994ef635: avcodec/libx264: expose nv21 input support [02:30:33 CEST] <Plorkyeran> github PRs aren't *terrible*, but they're about as feature-light as you can get and still be usable for code review as long as you structure your workflow around what they support [02:30:56 CEST] <Plorkyeran> so people who have used better code review tools tend to dislike github's [02:33:53 CEST] <BtbN> they are quite accesible though, getting used to gerrit takes a while [02:56:40 CEST] <cone-377> ffmpeg 03Rostislav Pehlivanov 07master:6d175158e914: aacenc: remove redundant argument from coder functions [03:18:45 CEST] <kierank> peloverde: so atomnuker thinks his patches will beat dolby... :) [03:18:50 CEST] <kierank> in aac encoding [03:20:13 CEST] <peloverde> cool [03:20:36 CEST] <atomnuker> subjectively [03:20:45 CEST] <atomnuker> key word here, subjectively [03:22:56 CEST] <Compn> there was software to check if a patch posted to ml was applied or lost [03:23:07 CEST] <Compn> someone ran it over the ffmpeg archives once and did a statistic [03:23:17 CEST] <Compn> some kind of research thesis for university [03:23:25 CEST] <Compn> dont remember the name though [03:24:02 CEST] <cone-377> ffmpeg 03Stephan Holljes 07master:cf6c871beec9: lavf/network: split ff_listen_bind into ff_listen and ff_accept [03:24:03 CEST] <cone-377> ffmpeg 03Stephan Holljes 07master:5125e4b53f71: lavf/avio: add ffurl_accept and ffurl_handshake [03:24:04 CEST] <cone-377> ffmpeg 03Stephan Holljes 07master:63c07a956bb2: lavf/avio: add avio_accept and avio_handshake [03:24:05 CEST] <cone-377> ffmpeg 03Stephan Holljes 07master:21198155a79a: lavf/tcp: add tcp_accept [03:24:06 CEST] <cone-377> ffmpeg 03Stephan Holljes 07master:75235a25506c: lavf/tcp: increase range for listen and call the underlying socket operations accordingly [03:24:07 CEST] <cone-377> ffmpeg 03Stephan Holljes 07master:3240e69de6d3: lavf/http: Implement server side network code. [03:24:08 CEST] <cone-377> ffmpeg 03Stephan Holljes 07master:1d46e0ee051a: doc/protocols: document experimental mutli-client api [03:24:09 CEST] <cone-377> ffmpeg 03Stephan Holljes 07master:25410c524dde: doc/example: Add http multi-client example code [03:24:10 CEST] <cone-377> ffmpeg 03Michael Niedermayer 07master:55ea31ab8981: Merge branch 'simple_http_server_api_implementation' of http://git.klaxa.eu/git/ffmpeg [03:39:11 CEST] <cone-377> ffmpeg 03Michael Niedermayer 07master:b27d4fd99736: Revert "libavcodec/utils: av_get_exact_bits_per_sample fixed to return "1" for DSD codecs." [11:19:34 CEST] <ubitux> if anyone is feeling that sharing http://ffmpeg.org/pipermail/ffmpeg-devel/2015-August/176556.html might be relevant on libav side, please do so [11:19:43 CEST] <ubitux> if you think it will bring troubles, then don't [11:20:22 CEST] <nevcairiel> for reasons, your mail didnt arrive in my mailbox [11:20:30 CEST] <ubitux> i just sent it [11:20:40 CEST] <nevcairiel> mail is usually pretty instant [11:20:46 CEST] <nevcairiel> but probably still in a spam filter somewhere [11:20:49 CEST] <ubitux> :( [11:20:54 CEST] <nevcairiel> ah there it is [11:20:58 CEST] <nevcairiel> analysis takes a while, you know [11:21:14 CEST] <ubitux> :) [11:43:27 CEST] Action: rcombs off to register #MultimediaDrama-devel [11:46:39 CEST] <rcombs> I've never been a fan of "libav" as a name because the project also incorporates several tools that aren't libraries, though "ffmpeg" is kinda silly at this day in age too, since "mpeg" only applies to a small portion of the code these days and I had to look up what "FF" stands for here [11:46:56 CEST] <rcombs> but on the other hand, it's an established name [11:48:15 CEST] <rcombs> but I'm putting the cart before the horse by even talking about naming before anyone's even come to an agreement on whether or not a reunification will happen [11:48:37 CEST] <nevcairiel> Realistically, I'm not seeing it happen [11:48:40 CEST] <nevcairiel> but we can hope [11:52:13 CEST] <rcombs> I haven't even see any priorities/expectations/conditions/whatever from any of the libav guys [11:53:48 CEST] <ubitux> they expressed some yesterday on their channels [11:53:55 CEST] <ubitux> but give them some time [11:54:12 CEST] <rcombs> yeah, obviously this won't be over in a day [11:55:15 CEST] <rcombs> ubitux: also, I'd imagine you've noticed that you're acting like a de-facto ffmpeg "leader" at the moment [11:56:52 CEST] Action: wm4 prostrates before ubitux [11:57:21 CEST] Action: rcombs performs a zigzag salute [11:57:26 CEST] <relaxed> if the shoe fits, wear it [11:57:45 CEST] <rcombs> it seems like the consensus is that we shouldn't really need one of those going forwards, though [11:58:19 CEST] <nevcairiel> that depends entirely if we manage to agree on something that works without [11:58:25 CEST] <ubitux> lol [11:58:33 CEST] <ubitux> alright i'm going back to playing counter strike then [11:58:50 CEST] <rcombs> do enjoy [11:59:03 CEST] <nevcairiel> we need to be able to make majority decisions without a single developer blocking everything, otherwise a leader is needed to unblock such things [11:59:33 CEST] <rcombs> what does libav do? [11:59:58 CEST] <nevcairiel> dunno, dont think i've seen them have an argument like that before [12:00:09 CEST] <nevcairiel> they seem mostly ambivalent what the others do =p [12:00:51 CEST] <rcombs> what, they just work on a software project instead of having ML and IRC arguments? [12:00:56 CEST] <rcombs> where do they get their drama, then? [12:01:30 CEST] <nevcairiel> tv? [12:01:31 CEST] <nevcairiel> i dunno [12:01:32 CEST] <wm4> getting upset over hn posts [12:01:37 CEST] <rcombs> huh [12:02:27 CEST] <rcombs> though obviously that TV viewing is done using libavcodec [12:02:36 CEST] <nevcairiel> there are discussions of course, but it mostly just ends with one side easily giving up, so no deadlocks [12:02:59 CEST] <nevcairiel> (or more accurately, giving in) [12:03:25 CEST] <rcombs> people are more interested in the advancement of the greater project than their own minor concerns? [12:04:47 CEST] <rcombs> I don't actually keep enough track of the ffmpeg ML to know much about the internal drama [12:07:58 CEST] <durandal_1707> ubitux: stop playing games, go finish selectivecolor and nlmeans! [12:08:38 CEST] <ubitux> durandal_1707 :( [12:08:41 CEST] <ubitux> alright alright [12:13:40 CEST] <durandal_1707> you can play games instead of posting on that channel :-/ [12:16:08 CEST] <durandal_1707> michaelni still cares for security issues that get reported? [14:13:44 CEST] <michaelni> durandal_1707, is there any new security issue that needs attention ? [14:16:06 CEST] <durandal_1707> I dunno I'm just asking are you still doing that kind of job... [14:17:39 CEST] <michaelni> if someone reports a sec issue to me, yes i would try to look into it [14:38:33 CEST] <blue112> Hi here. Is this the good place for talking about trying to compile libav with mvsc ? [14:40:52 CEST] <Compn> no, #ffmpeg is better place [14:41:01 CEST] <Compn> this channel is only if you are developing some code in ffmpeg [14:41:14 CEST] <Compn> or fixing some msvc ffmpeg bug [14:41:21 CEST] <nevcairiel> the process should be adequately documented however [14:41:53 CEST] <blue112> Ok, I'm going there then, thanks. [15:11:28 CEST] <kierank> ubitux: so much for community statements then :( [16:02:35 CEST] <ubitux> kierank: sorry? [16:02:58 CEST] <kierank> we wrote a community statement on etherpad yesterday [16:16:50 CEST] <ubitux> kierank: oh, i missed that, sorry [16:18:19 CEST] <durandal_1707> link? [16:18:51 CEST] <ubitux> https://etherpad.mozilla.org/Cem9NXUdZw [16:19:44 CEST] <ubitux> i have very high doubt that VDD is going to solve anything in itself [16:20:11 CEST] <ubitux> it seems to be again sold as the holy grail, but whatever [16:20:15 CEST] <kierank> probably but it avoids flames on HN and reddit [16:20:35 CEST] <kierank> HN is definitely not the place to have this flame [16:20:43 CEST] <kierank> and neither side is going to go on the others ml [16:20:45 CEST] <nevcairiel> HN isnt the place for anything =p [16:21:55 CEST] <kierank> ubitux: it's not the holy grail but it's the only neutral venue [16:22:16 CEST] <ubitux> not really [16:22:27 CEST] <ubitux> it just feels like spectacle [16:22:50 CEST] <kierank> what other neutral venues are there? [16:23:09 CEST] <kierank> vdd is the least worst place [16:23:36 CEST] <ubitux> problems came up online, i don't see why they can't be solved online [16:23:52 CEST] <kierank> but where? [16:23:54 CEST] <kierank> HN? [16:23:59 CEST] <kierank> with all the neckbeards? [16:24:00 CEST] <ubitux> another irc channel, whatever [16:24:17 CEST] <kierank> remember the joint ML idea? [16:24:21 CEST] <kierank> how badly that went [16:24:28 CEST] <ubitux> it didn't went badly [16:24:36 CEST] <ubitux> just nothing happened [16:24:43 CEST] <kierank> erm. you forget the massive flames [16:24:55 CEST] <ubitux> not really [16:25:15 CEST] <ubitux> we've been asked for an irc meeting several times you know [16:25:26 CEST] <durandal_1707> the others do not want to see michaelni in any role, even as just contributor [16:25:35 CEST] <kierank> doubt that [16:25:57 CEST] <ubitux> durandal_1707: we don't know, that's the point of gathering expectations [16:26:28 CEST] <durandal_1707> I just read what they wrote [16:26:31 CEST] <wm4> huh, so there was a joint ml? [16:26:36 CEST] <ubitux> without an honest list from both side, VDD is really going to feel like we are going to accept a whim from libav [16:26:45 CEST] <ubitux> but whatever [16:27:03 CEST] <ubitux> wm4: no, but we tried to suggest the idea, remember? [16:27:16 CEST] <ubitux> like a mail or something was sent to both ml [16:27:21 CEST] <wm4> yeah [16:27:25 CEST] <wm4> but that was chaos anyway [16:27:41 CEST] <ubitux> not what i remember of it but ok [16:28:05 CEST] <durandal_1707> who is going to do merges? If nobody I will do cherry picks or even commit directly [16:28:35 CEST] <ubitux> durandal_1707: i'd like to keep going the way it was done so far until we decide what to do [16:29:05 CEST] <durandal_1707> currently nothing is done [16:29:20 CEST] <ubitux> i mean, just making sure git log ..libav/master --oneline keep track of the difference [16:29:31 CEST] <ubitux> so far very few commits [16:29:34 CEST] <nevcairiel> I offered to look into doing them, since I do believe its a good idea to keep them doing, but I don't currently have push access, nor is there consensus i guess [16:29:38 CEST] <ubitux> i think the next one in queue requires to sync samples [16:30:13 CEST] <wm4> nevcairiel: send mini a ssh key [16:30:35 CEST] <durandal_1707> public key [16:31:00 CEST] <nevcairiel> and yeah i also dont have access to upload fate samples [16:31:12 CEST] <nevcairiel> as ubitux points out, the next one needs new ones [16:31:19 CEST] <ubitux> durandal_1707: so yeah, someone needs to sync some mp3-conformance samples before merging [16:31:37 CEST] <ubitux> iirc [16:31:40 CEST] <durandal_1707> I don't have access [16:32:06 CEST] <ubitux> or maybe it was actually merged, dunno [16:32:16 CEST] <ubitux> yeah no it's not [16:32:21 CEST] <ubitux> just done locally [16:32:24 CEST] <ubitux> :p [16:33:06 CEST] <nevcairiel> yeah the new ssamples are not on fate rsync yet [16:33:09 CEST] <nevcairiel> i checked [16:34:16 CEST] <nevcairiel> I guess I should send a mail to the ML to offer to keep those merges going, even if maybe not as fast as michael used to do them [16:34:24 CEST] <nevcairiel> assuming access is given etc [16:36:52 CEST] <michaelni> if anyone needs git or shell access, send me your ssh key [16:39:23 CEST] <cousin_luigi> michaelni: Hello, I just wanted to thank you for your work and your availability. [16:39:38 CEST] <cousin_luigi> I heard about the recent decision. Best wishes for the future. [16:40:50 CEST] <michaelni> cousin_luigi, thx [16:44:15 CEST] <ubitux> rcombs: so, are you going to push that srt patch? [16:47:40 CEST] <michaelni> durandal_1707, ive added your pub ssh key from git to the server you should be able to login and also change/add samples & fate samples [16:48:42 CEST] <michaelni> nevcairiel, can you send me your key ? [16:48:52 CEST] <nevcairiel> sure [16:48:59 CEST] <nevcairiel> i'll mail it i guess, might be too long for irc [16:49:05 CEST] <michaelni> ok [16:50:14 CEST] <nevcairiel> should be on its way [16:57:31 CEST] <michaelni> nevcairiel, added to git, can you confirm that it works (i did copy and paste from mutt inline mail so i might have gotten a char wrong) [16:58:55 CEST] <nevcairiel> seems to work [17:01:48 CEST] <nevcairiel> thanks [17:03:16 CEST] <michaelni> also added a ssh account with access to samples & fate samples for you [17:04:57 CEST] <nevcairiel> whats the username on those? [17:05:18 CEST] <michaelni> nevcairiel [17:05:28 CEST] <nevcairiel> thats easy to remember [17:05:30 CEST] <nevcairiel> thats my name [17:05:40 CEST] <michaelni> :) [17:06:38 CEST] <michaelni> if anyone else needs access, please ping me [17:06:55 CEST] <nevcairiel> it works, thanks [17:09:19 CEST] <Daemon404> man i chose a bad week to go on vacation... [17:09:38 CEST] <Daemon404> has any kind of thing been decided WRT merges? [17:10:37 CEST] <nevcairiel> i just sent a mail to offer to keep doing them until the collective decides otherwise [17:11:26 CEST] <kierank> Daemon404: lol [17:11:58 CEST] <BtbN> nevcairiel, +1 from me for that. [17:14:18 CEST] <Daemon404> nevcairiel, ok. i am sure i can help if you are away or w/e. [17:14:27 CEST] <Daemon404> mind you im right in the middle of vacation atm [17:14:34 CEST] <Daemon404> only found out cause of hacker news [17:14:38 CEST] <nevcairiel> i should go on vacation [17:14:42 CEST] <nevcairiel> havent really had any this year yet [17:16:38 CEST] <nevcairiel> in any case, I uploaded the new mp3 fate refs so they can sync around the world until the merge thing is confirmed [17:18:06 CEST] <BBB> nevcairiel: cool, ty [17:18:18 CEST] <michaelni> +1 [17:19:45 CEST] <BBB> so michaelni, are you actually taking a vacation now? I dont believe it [17:20:28 CEST] <BBB> I bet youre writing something [17:20:38 CEST] <BBB> (good choice btw!) [18:44:41 CEST] <cone-494> ffmpeg 03Rostislav Pehlivanov 07master:ec2090d21f54: aacenc: add description to the 'aac_coder' option [18:45:02 CEST] <lglinskih_> kierank: hi! did you see my patch on ml? [18:45:22 CEST] <kierank> lglinskih_: hi [18:45:23 CEST] <kierank> yes [18:45:25 CEST] <kierank> let me look [18:46:08 CEST] <kierank> looks ok to me [18:46:13 CEST] <kierank> not sure if wm4 has comments [18:47:23 CEST] <wm4> what [18:47:46 CEST] <wm4> also I just had my first user asking about xvmc support [18:48:22 CEST] <BtbN> that still exists? [18:48:28 CEST] <BtbN> Isn't that the broken stuff fglrx uses? [18:50:04 CEST] <iive> no, fglrx one is called XvBA [18:50:05 CEST] <beastd> BtbN: Why would you necesarrily connect xvmc to fglrx? I for sure used it without fglrx... [18:50:16 CEST] <BtbN> i can't think of any other driver that needs it [18:50:19 CEST] <iive> xvmc is provided by nvidia and mesa-gallium [18:50:43 CEST] <BtbN> ah, yes. XvBA is what I was thinking about. [18:55:33 CEST] <BBB> michaelni: any experienced dev working on jpeg2k would be fantastic, that decoder has been not-quite-perfect for ages, and needs something like what you+mike/etc did for h264 trying to get all conformance samples to work [18:56:33 CEST] <Daemon404> BBB, conformance is one thing... iirc we actually just refuse to decode 4k j2k [18:56:40 CEST] <Daemon404> which makes it useless for DCP [18:56:58 CEST] <nevcairiel> i think dcp actually worked, but only the limited dcp profile, not generic 4k j2k [18:57:09 CEST] <nevcairiel> but its way slow in any case [18:57:35 CEST] <JEEB> tears of steel master played at least [18:57:39 CEST] <JEEB> lavf+mpv [18:57:43 CEST] <JEEB> slow as molasses, yes [18:59:53 CEST] <ubitux> as long as gif 4k decoding is fast, who cares [19:01:05 CEST] <nevcairiel> go away [19:01:09 CEST] <nevcairiel> you enabler of evil :( [19:01:40 CEST] <Daemon404> nevcairiel, i would be happy if i could even just transcode 4k [19:01:45 CEST] <Daemon404> to something playable [19:01:51 CEST] <Daemon404> does it perhaps work with an external decoder [19:01:55 CEST] <Daemon404> like libopenjpeg or w/e [19:02:01 CEST] <nevcairiel> openjpeg if anything yeah [19:02:09 CEST] <nevcairiel> did you try after all the recent work on j2k? [19:02:22 CEST] <Daemon404> hmmm havent for about a year or two [19:02:23 CEST] <JEEB> yeah, after I updated lavc j2k the tears of steel thing started working [19:02:29 CEST] <Daemon404> at the time it just said "lol your res is too big, go away" [19:02:31 CEST] <JEEB> it's just slow, but it seems correct [19:02:41 CEST] <JEEB> before that it decoded, but was corrupt [19:41:11 CEST] <cone-494> ffmpeg 03Paul B Mahol 07master:5bf8590d6e76: avfilter/avf_showvolume: stop making output fully transparent [20:07:29 CEST] <BBB> Im happy to optimize [20:07:38 CEST] <BBB> but as long as its not decoding compliant, theres nothing to optimize [20:08:26 CEST] <durandal_1707> BBB: optimize vf_deband? [20:08:51 CEST] <BBB> fix all files in the conformance suite [20:09:26 CEST] <nevcairiel> durandal_1707: j2k [20:11:11 CEST] <durandal_1707> I know, I just trying someone to write asm [20:11:33 CEST] <durandal_1707> for lavfi [20:14:08 CEST] <j-b> and there is all the patches of Buxiness on jp2k that were never merged [20:15:01 CEST] <j-b> and this alloed me to decode the 1080p version on a big laptop without too much hassle [20:15:09 CEST] <lglinskih_> kierank: oh, I didn't see your last messages. What should I do next? New tests or upgrade my previous tests on more cases and codecs? [20:16:52 CEST] <kierank> I think extend existing tests now [20:18:32 CEST] <BBB> durandal_1707: I wrote ssim/psnr simd [20:18:51 CEST] <BBB> j-b: link? I can review if that needs doing [20:19:29 CEST] <BBB> I certainly do think companies with a coprorate interest in j2k should sponsor this kind of work, its ridiculous that most corporate j2k solutions go for millions and they expect us to do this work for free (for them!) [20:19:44 CEST] <j-b> BBB: it was 2 years ago [20:20:10 CEST] <durandal_1707> BBB: I know, never enough simd [20:20:33 CEST] <j-b> BBB: he is finishing the PhD in September, but I called him last week, and he could rebase them, if there is interest. [20:20:51 CEST] <durandal_1707> I should really start learning it [20:23:49 CEST] <j-b> Hey, btw, did you publish that etherpad on ffmpeg.org? [20:24:02 CEST] <j-b> (very slow network here, IRC is all I got) [20:24:43 CEST] <BBB> j-b: link to old patches? [20:24:47 CEST] <BBB> Id like to see what it was [20:25:20 CEST] <j-b> BBB: can I do that on Monday, please? [20:25:26 CEST] <BBB> of course [20:25:33 CEST] <j-b> I'll add this to the top of my Monday Todolist? [20:25:33 CEST] <BBB> ty [20:25:35 CEST] <j-b> deal? [20:25:39 CEST] <BBB> middle is ok [20:25:47 CEST] <BBB> :-p [20:25:57 CEST] <j-b> BBB: you don't want to be in the middle [20:26:05 CEST] <BBB> oh one of these todo lists [20:26:10 CEST] <BBB> I have a couple of them too [20:26:12 CEST] <j-b> middle is roughly in 3 weeks [20:26:21 CEST] <BBB> they tend to live in ~/Projects/ffmpeg/TODO and so on [20:26:23 CEST] <j-b> anyway, I got to go [20:26:26 CEST] <BBB> bye! [20:26:38 CEST] <j-b> but you should really publish your etherpad on the website [20:26:40 CEST] <j-b> bye! [20:26:54 CEST] <kierank> who can edit ffmpeg.org? [20:27:22 CEST] <BtbN> propably root [20:27:29 CEST] <BtbN> whoever that is right now [20:27:54 CEST] <kierank> ubitux: ping [20:29:24 CEST] <kierank> Compn: ping [20:31:14 CEST] <BBB> isnt anyone who commits to ffmpeg-web an editor of ffmpeg.org? [20:31:58 CEST] <beastd> kierank, BtbN: what BBB said (no need for root (usually)) [20:32:55 CEST] <kierank> ok I will write a patch [20:34:19 CEST] <kierank> I'll send the etherpad to the ml first [20:38:17 CEST] <ubitux> kierank: pong [20:38:25 CEST] <kierank> ubitux: see ml [20:38:53 CEST] <kierank> basically we (me, j-b, wm4 etc) think our etherpad should be published on ffmpeg.org [20:38:54 CEST] <kierank> https://etherpad.mozilla.org/Cem9NXUdZw [20:41:04 CEST] <ubitux> not sure what's this public forum is about [20:41:15 CEST] <BBB> blogs [20:41:19 CEST] <BBB> gentoo/debian mls [20:41:22 CEST] <BBB> lwn comments [20:41:31 CEST] <BBB> and lots and lots of irc yanking [20:41:32 CEST] <kierank> hacker news [20:41:33 CEST] <kierank> reddit [20:41:35 CEST] <ubitux> but again i don't like the sound of this vdd as a messy; it would be relevant to say that this reconciliation process has already started [20:41:51 CEST] <BBB> theres a ffmpeg reddit? [20:41:58 CEST] <kierank> no but there has been trolls in the past iirc [20:42:09 CEST] <kierank> it's top on /r/programming right now [20:42:14 CEST] <BBB> great [20:42:45 CEST] <kierank> ubitux: can you change the wording please? [20:42:48 CEST] <ubitux> (and i don't think any IRL can be neutral, because it gives a huge advantage to good talkers) [20:43:10 CEST] <kierank> as i said, it's the least worst place as history shows [20:43:57 CEST] <ubitux> i disagree [20:44:05 CEST] <ubitux> i personally see vdd as a huge concession, but well [20:44:24 CEST] <wm4> how so? [20:44:25 CEST] <ubitux> but i'm just a single dev, so whatever [20:44:58 CEST] <ubitux> wm4: because this irl meeting is just a whim from libav folks for years [20:45:23 CEST] <wm4> kierank: the text still says "michael's resignation _today_" [20:45:26 CEST] <ubitux> (and i hate real life contacts as i already expressed) [20:46:53 CEST] <kierank> ubitux: is that better? [20:47:51 CEST] <ubitux> yeah it's fine [20:47:54 CEST] <BBB> Isn't VP8/9 a subset of Daala? Perhaps I'm confused. [20:47:55 CEST] <BBB> omg [20:48:01 CEST] <ubitux> haha BBB [20:48:03 CEST] <JEEB> lol [20:48:05 CEST] <BBB> /r/programming quality of comments is & [20:48:09 CEST] <BBB> I have no words for it [20:48:20 CEST] <BBB> speechless [20:48:57 CEST] <Shiz> it's /r/programming quality [20:49:04 CEST] <ubitux> try to explain them how VP8 is actually GIFv after that [20:49:12 CEST] <ubitux> (or the other way around) [20:50:18 CEST] <wm4> I've stopped going there long ago because everyone was so retarded [20:50:49 CEST] <wm4> I used to defend ffmpeg or libav there once [20:51:14 CEST] <kierank> ubitux: the problem is exactly how you said. everyone on HN etc is doing a godwin [20:51:21 CEST] <kierank> whereas most people don't care any more [20:51:29 CEST] <wm4> and hn doesn't seem much better [20:51:29 CEST] <kierank> but then people just think ffmpeg cares about godwin [20:51:34 CEST] <kierank> because that's all they read about [20:51:58 CEST] <ubitux> i never suggested to have a discussion on HN, reddit or /. you know [20:52:12 CEST] <kierank> ubitux: well that's how it happened [20:52:28 CEST] <kierank> and it makes us all look nuts [20:52:46 CEST] <ubitux> i suggested an irc channel, but it seems to much simple to move people around the globe that doing a /join for whatever reason [20:52:57 CEST] <ubitux> s/to much/so much/ [20:53:43 CEST] <kierank> yes but we need a statement imo [20:53:45 CEST] <durandal_1707> which irc channel? [20:53:51 CEST] <kierank> otherwise we just let HN take over the news [20:54:15 CEST] <ubitux> durandal_1707: i don't know, whatever #libavffmpeg2015, who cares [20:54:32 CEST] <ubitux> opened by a neutral party who is op [20:54:35 CEST] <jamrial> ubitux: what better idea than to put a bunch of introverts in a room and ask them to agree on something? :p [20:54:38 CEST] <durandal_1707> libvas [20:54:43 CEST] <ubitux> who will voice and unvoice ppl and that's it [20:55:16 CEST] <kierank> dunno how that works [20:55:20 CEST] <wm4> ubitux: one issue is that you can get people to join that, most likely [20:55:22 CEST] <kierank> how do you know when someone wants to speak [20:55:24 CEST] <ubitux> /mode +v, /mode -v [20:55:28 CEST] <ubitux> no i mean [20:55:28 CEST] <wm4> with VDD it seems people are coming anyway? [20:55:36 CEST] <wm4> at least some people [20:55:38 CEST] <ubitux> kierank: you do it when someone is annoying [20:56:12 CEST] <kierank> I've seen enough times ffmpeg and libav people are on irc to know that's bad [20:56:16 CEST] <ubitux> wm4: what makes you think they are comfortable talking irl? [20:56:50 CEST] <wm4> I have no idea, but it seems worth a try [20:56:54 CEST] <ubitux> as i said many times, IRL talks are for me a huge threat [20:56:58 CEST] <wm4> other methods didn't work either [20:57:21 CEST] <ubitux> wm4: because not enough people tried [20:57:29 CEST] <kierank> really? [20:57:32 CEST] <kierank> we tried soooo many times [20:57:35 CEST] <kierank> and it ended up the same way [20:57:37 CEST] <kierank> stories about 2011 [20:57:43 CEST] <kierank> let's hear everyone's view about what happened [20:57:54 CEST] <ubitux> i never saw a single irc channel opened by a third party [20:57:56 CEST] <ubitux> never [20:58:02 CEST] <ubitux> or even by either side [20:58:32 CEST] <kierank> we tried a ml and it was bad [20:58:33 CEST] <ubitux> ffmpeg devs seems to be willing to communicate exclusively online, and libav devs seems to be willing to communicate exclusively irl [20:58:44 CEST] <kierank> i don't see why an irc will be different [20:58:56 CEST] <kierank> irc is always heated when libav comes to ffmpeg and ffmpeg goes to libav [20:59:04 CEST] <kierank> no reason it will suddenly get better on a neutral channel [20:59:05 CEST] <ubitux> because it can have moderation [20:59:17 CEST] <ubitux> from a neutral party [20:59:19 CEST] <jamrial> ubitux: exclusively or preferred? [20:59:21 CEST] <ubitux> just like what you suggest irl [20:59:26 CEST] <kierank> it can't because everyone talks on irc [20:59:33 CEST] <ubitux> jamrial: yeah, prefered if you want :) [20:59:49 CEST] <ubitux> kierank: then the neutral party says to shut up and people do? [20:59:58 CEST] <ubitux> and if they don't they get devoiced [21:00:03 CEST] <kierank> shut up when [21:00:03 CEST] <ubitux> what's so complicated? [21:00:04 CEST] <kierank> ? [21:00:11 CEST] <kierank> like you could just talk for hours [21:00:20 CEST] <kierank> and the neutral party has no reason to stop you [21:00:30 CEST] <ubitux> then what will be different irl? [21:00:40 CEST] <ubitux> are you going to talk louder? [21:01:00 CEST] <kierank> no but everyone can wait and let everyone hear [21:01:09 CEST] <kierank> I don't say it's brilliant - i mean i didn't even go last year [21:01:13 CEST] <kierank> because it was painful [21:01:17 CEST] <jamrial> ideally we shouldn't need a mediator/arbiter... [21:01:21 CEST] <kierank> but irc is going to be a disaster [21:01:23 CEST] <kierank> history shows [21:01:31 CEST] <kierank> we have the best opportunity for discussion [21:01:40 CEST] <kierank> irc will be lighting a match under a firework [21:01:42 CEST] <ubitux> there is absolutely no reason irl is not going to be a disaster [21:01:55 CEST] <ubitux> the only reason i think it might work is because we would accept a whim from libav [21:02:01 CEST] <ubitux> to show them some concession [21:02:07 CEST] <kierank> maybe [21:02:09 CEST] <kierank> I dunno [21:03:12 CEST] <ubitux> (and while this request makes absolutely zero sense to me is the reason i consider it a concession) [21:03:23 CEST] <kierank> ok [21:03:32 CEST] <kierank> ubitux: do you agree though that the ffmpeg project needs to make a public statement [21:03:44 CEST] <ubitux> yeah sure, it's fine [21:03:46 CEST] <kierank> otherwise HN, reddit etc will make that statement (incorrectly) instead of us [21:04:14 CEST] <ubitux> did you see the ml post i made recently btw? [21:04:29 CEST] <ubitux> i'm mentioning the fact that we want people to stop bitching at each other [21:04:38 CEST] <kierank> yes the godwin thing was good [21:04:47 CEST] <ubitux> so maybe call for the community to calm down and lie by saying everyone is looking for a reconciliation [21:04:54 CEST] <ubitux> in that announcement [21:05:17 CEST] <ubitux> maybe that would help [21:05:27 CEST] <ubitux> but since i have no idea what libav wants, i don't know [21:05:31 CEST] <kierank> I was trying to say that subtly yes [21:05:45 CEST] <ubitux> i mean, i believe we've been doing almost everything they wanted to change originally [21:05:54 CEST] <wm4> the lack of interested from the Libav side is worrisome [21:06:20 CEST] <ubitux> like, we don't even have a leader anymore, why is there still no communication or anything positive? [21:06:31 CEST] <ubitux> wasn't the fork all about michael being a leader? [21:06:42 CEST] <kierank> they need time to digest [21:06:53 CEST] <kierank> ubitux: well there has been response [21:07:02 CEST] <kierank> unfortunately it has been fighting on HN, g+ etc [21:07:12 CEST] <ubitux> yeah i'm going to ignore this [21:07:43 CEST] <ubitux> it's honestly very frustrating to not know what they want [21:07:52 CEST] <ubitux> (which is part of the reason i sent that mail) [21:10:16 CEST] <ubitux> ...and i don't want to wait for a month to just hear IRL, "well fu we don't want to work with you, give us apologies and die" or that sort of thing [21:10:30 CEST] <ubitux> so if anyone can push them to communicate anything *before*, that will be appreciated [21:10:48 CEST] <ubitux> even if that's really just what i stated [21:11:11 CEST] <ubitux> so we can forget this reconciliation, move on, and continue "winning" this silly war [21:11:45 CEST] <ubitux> silence is so much more annoying that hate messages [21:11:49 CEST] <ubitux> anyway, afk [21:12:22 CEST] <wm4> so, uh, how much time do they need to "digest"? [21:13:05 CEST] <wm4> I suppose for now it might be better to put them under stress, but in the end we'll have to convince them too, possibly using somewhat stronger language [21:13:29 CEST] <wm4> (never hire me as diplomat) [21:14:29 CEST] <BBB> hehehe [21:14:51 CEST] <BBB> look, I dont know what their ideal end scenario is, but either project is unlikely to just evaporate in thin air [21:15:11 CEST] <BBB> so a reasonable end scenario would be for us to move major obstacles out of the way and try to work together again [21:15:40 CEST] <BBB> but who am i [21:21:57 CEST] <kierank> where is llogan? [21:27:24 CEST] <kierank> does anyone have access to twitter apart from llogan? [21:27:50 CEST] <BBB> can you email him? [21:29:23 CEST] <kierank> yeah I emailed him [21:37:51 CEST] <kierank> who has commit rights to ffmpeg-web? [21:38:54 CEST] <nevcairiel> where does that repo even live [21:39:16 CEST] <kierank> I cloned it from git://git.ffmpeg.org/ffmpeg-web [21:39:54 CEST] <nevcairiel> isnt that just a redirect [21:40:18 CEST] <kierank> i think that's the actual repo [21:42:07 CEST] <nevcairiel> then no idea [21:50:27 CEST] <BBB> I have commit rights [21:50:31 CEST] <BBB> but so should everyone else, no? [21:50:39 CEST] <BBB> at least I had commit rights back a long time ago [21:50:45 CEST] <BBB> I can try if you want [21:50:50 CEST] <BBB> but you should have commit rights also [21:51:06 CEST] <nevcairiel> i have rights to the main repo, but i dont know what the push url for that web thing would be [21:53:48 CEST] <JEEB> jesus damn, someone finally started thinking that parsing the mkvmerge metadata duration is a good idea to base something upon :| [21:54:32 CEST] <kierank> I'll wait a few hours to make sure there are no more ML comments [21:54:50 CEST] <nevcairiel> you should know that before he wanted to introduce his own metadata to do the same thing JEEB [21:54:51 CEST] <kierank> and I need to find someone to tweet it and perhaps facebook it as well [21:56:58 CEST] <michaelni> the keys for web and main git arent automatically synced. beastd & ubitux sure have access but i could add more people if needed [21:59:43 CEST] <kierank> michaelni: can you add me please [22:01:38 CEST] <wm4> sigh, this mp3 probing code [22:04:48 CEST] <michaelni> kierank, added [22:05:05 CEST] <kierank> thx [22:12:15 CEST] <lglinskih_> kierank: should bitexact flag be applicable for all decoders? [22:12:27 CEST] <kierank> no, some decoders are not bitextact (float audio) [22:12:31 CEST] <kierank> mpeg-2 [22:12:32 CEST] <kierank> etc [22:12:59 CEST] <kierank> you might need to write equivalent code that fate has to allow small deviations [22:16:22 CEST] <lglinskih_> kierank: so in that case I should compare bits of a frames, not crcs? [22:16:48 CEST] <kierank> iirc fate does some kind of standard deviation on the output data [22:16:51 CEST] <rcombs> what would anyone think of having the duration field on AVStream/AVFormatContext be meaningful when encoding? [22:16:53 CEST] <kierank> and there are thresholes [22:17:08 CEST] <rcombs> like, if it's set, write that duration in the header [22:18:07 CEST] <rcombs> possibly making a file have a valid (if approximate) duration during a live encode, and/or avoiding a seekback later [22:52:33 CEST] <BBB> rcombs: yeah I had that issue recently for ivf [22:52:55 CEST] <BBB> rcombs: http://git.videolan.org/?p=ffmpeg.git;a=commit;h=3a18d3fa047535980aa5368ebf… [22:53:11 CEST] <BBB> rcombs: if theres some way to make that easier, Id love it [22:53:37 CEST] <wm4> in general you don't know it in advance [22:53:50 CEST] <wm4> e.g. filters could do arbitrary things to the timeline [22:53:51 CEST] <rcombs> BBB: right now I have ffmpeg.c hacked to insert a private duration parameter in the metadata, and matroskaenc hacked to parse and use it [22:54:04 CEST] <rcombs> wm4: yeah, but in the case where you do know, it can be useful [22:54:16 CEST] <wm4> btw. can ffmpeg change video speed? (with also changing audio speed) [22:54:36 CEST] <BBB> rcombs: if we can initialize duration to something sane and write that in the header, thatd be great [22:55:00 CEST] <BBB> then, if the demuxer wants to privately keep track of duration and write a more precise version at end of stream (if seekable), thats even better [22:55:07 CEST] <BBB> rcombs: so Im all for it [22:55:14 CEST] <BBB> (but right now we both know it doesnt work :D) [22:56:20 CEST] <rcombs> wm4: maybe let filters present a function that takes the input durations (or, well, the approximations thereof) of their input streams and returns the expected output duration, given what they know about their parameters [22:56:38 CEST] <kierank> problem is in vfr duration of a file is meaningless [22:56:47 CEST] <kierank> what's the duration of the last frame? [22:57:22 CEST] <rcombs> so filters like subtitles, scale, etc... that don't adjust the timeline just don't present it and it's treated like the input duration [22:57:50 CEST] <rcombs> ones that adjust in a predictable manner (e.g. atempo) return a decent approximation [22:58:01 CEST] <rcombs> and ones that are unpredictable return NOPTS_VALUE [22:58:38 CEST] <rcombs> kierank: that doesn't make it meaningless, it just makes it an approximation [22:58:51 CEST] <rcombs> which can still be useful [22:59:46 CEST] <BtbN> something i just wondered, with this FF_API_CODED_FRAME deprecation, how would for example an rtmp output muxer know which frames to drop in case of network congestion? [22:59:51 CEST] <kierank> durandal_1707: ping [23:00:01 CEST] <wm4> rcombs: sounds too complicated [23:02:10 CEST] <durandal_1707> kierank: pong [23:02:50 CEST] <kierank> durandal_1707: any views on the statement? [23:03:17 CEST] <kierank> https://etherpad.mozilla.org/Cem9NXUdZw [23:03:18 CEST] <iive> BtbN: you can always add more meta-data :) [23:03:47 CEST] <BtbN> Well, the meta-data is already there. And deprecated without a replacement. [23:04:16 CEST] <BtbN> The argument for it seems to be that it's not reliable, but for frame-drop estimation for rtmp it's more than usefull [23:04:34 CEST] <durandal_1707> that thing? whatever. Sadly I'm not available on vdd. [23:04:45 CEST] <kierank> ok [23:05:03 CEST] <kierank> I want to commit it today but I don't want people getting angry at me saying they weren't consulted [23:09:05 CEST] <wm4> isn't it acknowledged only by those who have signed? [23:09:47 CEST] <rcombs> wm4: it's that or assume filters don't adjust the duration, let them set a flag that says they might, and unset it if any of those are in play [23:09:54 CEST] <kierank> wm4: well I'm sticking it on ffmpeg.org [23:09:58 CEST] <kierank> so essentially it is the project speaking [23:12:35 CEST] <rcombs> it's uh... [23:12:41 CEST] <rcombs> kinda unfocused [23:12:47 CEST] <rcombs> (that pad) [23:13:00 CEST] <rcombs> paragraphs don't seem to know where they're going [23:14:50 CEST] <wm4> feel free to correct it [23:19:31 CEST] Action: kierank wonders who Blue guy is [23:19:35 CEST] <kierank> is he just a random troll [23:21:21 CEST] <wm4> lol [23:21:26 CEST] <nevcairiel> he kinda speaks like durandal_1707 [23:21:54 CEST] <kierank> yeah but durandal_1707 knows what the plan is [23:21:56 CEST] <kierank> since he's in the thread [23:27:43 CEST] <kierank> reynaldo: ping [23:28:09 CEST] <reynaldo> kierank: pong [23:28:22 CEST] <kierank> so when we make the statement can you put it on twitter [23:28:23 CEST] <kierank> https://etherpad.mozilla.org/Cem9NXUdZw [23:28:28 CEST] <kierank> it's going to go on ffmpeg.org [23:29:25 CEST] <reynaldo> Im going to be offline for the rest of the day starting 5m from now [23:29:37 CEST] <reynaldo> maybe Lou can help? [23:29:41 CEST] <kierank> lou is away too [23:29:58 CEST] <kierank> can you pm me the twitter password? [23:35:59 CEST] <kierank> blue troll is annoying [23:37:52 CEST] <Compn> I is back [23:38:37 CEST] <Compn> ett e pad looks pk , wording change to "we cant thank him enough" [23:39:00 CEST] <kierank> a bit informal [23:39:09 CEST] <kierank> imo [23:39:50 CEST] <Compn> we must thank him almost sounds like a forced gtatitude [23:39:55 CEST] <reynaldo> kierank: feel about uneassy about giving away the passwd as its under lou email address, would you understand if we bounce this to him be email? I will take care of this tweet [23:39:58 CEST] <Compn> hehe [23:40:04 CEST] <reynaldo> so you dont et blocked [23:40:04 CEST] <kierank> reynaldo: ah ok [23:40:20 CEST] <reynaldo> kierank: hope you understand [23:40:25 CEST] <kierank> it's ok [23:40:31 CEST] <reynaldo> everyone has right to it I guess, its just that its his account [23:41:10 CEST] <kierank> I'm not sure when to actually push it to ffmpeg.org [23:42:56 CEST] <reynaldo> kierank: send me an email once you guys make a desicion and I will handle it [23:43:46 CEST] <Compn> kierank, did you get access, or do you need me? [23:43:51 CEST] <kierank> I got access [23:44:13 CEST] <Compn> ok, ill be afk then. [23:50:16 CEST] <kierank> Compn: ping [23:50:17 CEST] <kierank> are you still there [23:51:08 CEST] <Compn> ye [23:51:14 CEST] <kierank> Compn: any idea why I get fatal: remote error: access denied or repository not exported: /ffmpeg-web [23:51:20 CEST] <kierank> what url should I be using [23:52:17 CEST] <bencoh> (meh, why did I ever try to backlog the past 24 hours ... :]) [23:52:26 CEST] <Compn> hmm [23:52:45 CEST] <Compn> kierank : what addy did you use ? [23:53:03 CEST] <kierank> url = git://source.ffmpeg.org/ffmpeg-web [23:53:13 CEST] <kierank> bencoh: lol [23:53:25 CEST] <Compn> url = gil@git.ffmpeg.org:ffmpeg-web [23:53:36 CEST] <Compn> is in my config [23:53:46 CEST] <Compn> probably shouldnt be pasting it here but oph well [23:53:48 CEST] <kierank> gil? [23:53:57 CEST] <Compn> git light or something no idea [23:54:02 CEST] <kierank> ok seems to work [23:54:12 CEST] <Compn> do a test commit typo fix or somethin [23:54:28 CEST] <kierank> https://ffmpeg.org/#message [23:54:32 CEST] <kierank> does it look ok? [23:54:34 CEST] <reynaldo> kierank: I would rephrase the text as a thank you note only tbh, and add the invitation for coordination and discussion at the end (the videolan section). Im worried about bits like "the current situation gives us an opportunity ..." as it reads as if michael was the one blocking a *solution* [23:54:39 CEST] <reynaldo> just my two cents [23:55:04 CEST] <kierank> reynaldo: it's written like that because that's what michael said in his letter [23:55:08 CEST] <ubitux> kierank: last paragraph is not closed properly [23:55:54 CEST] <Compn> i just dont think we'll solve anything at vdd, as we didnt the last few years when we tried.... [23:56:02 CEST] <Compn> but whatever, you want to try again, go for it [23:56:02 CEST] <kierank> neither do i [23:56:17 CEST] <kierank> it's the best chance we have though [23:56:42 CEST] <reynaldo> kierank: even with that, is the ffmpeg community speaking now, he deserves a huge thank you and "hope he remains around", I'd put it that way [23:56:59 CEST] <reynaldo> but again, Im not the one writting, just think it would be better that way [23:57:13 CEST] <kierank> dunno, there's like 10 other people in etherpad [23:57:28 CEST] <Compn> yeah i dunno if this is even an opportunity to do anything with michaelni gone :\ [23:57:32 CEST] <kierank> lydia just said push it because we kept tweaking it [23:57:41 CEST] <ubitux> kierank: you closed a paragraph already closed. [23:57:43 CEST] <Compn> yes lydia who isnt even in irc chat [23:57:55 CEST] <kierank> yes but lydia tried for 4 years to get the projects to merge [23:57:59 CEST] <michaelni> i dont like the wording either [23:58:11 CEST] <ubitux> who is lydia? [23:58:27 CEST] <kierank> michaelni: what don't you like [23:58:52 CEST] <Compn> just seems like some rushed words , without even talking to libav people [23:58:56 CEST] <ubitux> (kierank: you didn't send a patch as announced :p) [23:59:35 CEST] <kierank> Compn: otherwise the HN and reddit agenda takes over [23:59:38 CEST] <kierank> and we hear 2011 stories again [23:59:50 CEST] <Compn> pfft, that happens anyway. [23:59:57 CEST] <kierank> not if we make a clear statement [00:00:00 CEST] --- Sun Aug 2 2015

1 0

ffmpeg.log.20150801
by burek 02 Aug '15

02 Aug '15

[00:18:05 CEST] <bencc> can I merge audio and video files with offset that changes over time? [00:18:23 CEST] <c_14> setpts/asetpts [00:18:26 CEST] <bencc> let's say I have a list of 'real' timestamps from both files I can use [00:19:30 CEST] <c_14> Interpolate a function between all those points. [00:19:45 CEST] <c_14> Timestamp on x, difference between them on y. [00:20:15 CEST] <c_14> Then use the function in setpts/asetpts depending on which direction you want to adjust [00:20:33 CEST] <bencc> c_14: you mean get a polynom? [00:21:26 CEST] <c_14> linear interpolation would be f(x) = mx + b [00:22:04 CEST] <bencc> c_14: what if the drift is not linear? [00:22:08 CEST] <c_14> x would be the "PTS" variable [00:22:19 CEST] <c_14> Use a quadratic/cubic etc interpolation [00:22:41 CEST] <c_14> You can also use splines if you feel so inclined. [00:22:45 CEST] <bencc> c_14: ok, so a polynom [00:22:58 CEST] <c_14> A polynomial function, yes. [00:23:20 CEST] <well0ne> good evening [00:23:34 CEST] <c_14> You can also use noncontinous functions [00:23:35 CEST] <bencc> c_14: can you link to the function in the docs? [00:23:57 CEST] <c_14> https://ffmpeg.org/ffmpeg-filters.html#setpts_002c-asetpts [00:24:53 CEST] <c_14> basically setpts=m*PTS+b <- for linear. analog for quadratic etc [00:25:05 CEST] <bencc> c_14: does it require re-encoding? [00:25:18 CEST] <c_14> yes. Of either the video or audio track [00:25:18 CEST] <bencc> if I have .webm video and .opus audio files [00:25:37 CEST] <bencc> reencoding the audio is probably better [00:25:44 CEST] <c_14> usually, yes [00:25:46 CEST] <bencc> I guess it will be less noticable [00:28:09 CEST] <bencc> c_14: can you give a full example that use opus and webm as input and output to a merged webm? [00:29:23 CEST] <c_14> What timescale should I use? [00:29:28 CEST] <c_14> make one up? [00:29:43 CEST] <bencc> cubic will be nice [00:58:12 CEST] <c_14> ffmpeg -i out.webm -i whip-way.opus -af asetpts='(((0.0122908/TB)*PTS)*((0.0122908/TB)*PTS)*((0.0122908/TB)*PTS))' -c:v copy out2.webm <- something like this I guess. It was a bit hard because I had to make up a cubic function to use. You just have to make sure you divide each of the actual numbers you get during the interpolation by the Timebase (TB). [00:58:43 CEST] <c_14> And yes, the cubic part is pretty annoying. [01:00:00 CEST] <c_14> Eh, like this actually -af asetpts='(0.0122908/TB)*(PTS*PTS*PTS)' [01:00:10 CEST] <c_14> Accidentally pulled that number into the cube [01:19:29 CEST] <bencc> thanks [10:35:36 CEST] <Guest53840> I am using a live subtitle file which is generated in real time .But ffmpeg is not able to embed it in video. [10:36:05 CEST] <Guest53840> What is wrong with ffmpeg?Does it need complete subtitle file [12:09:44 CEST] <well0ne> Hello [13:09:07 CEST] <elmargol> Can I use yuvj420p x264? or do i have to use yuv420p? [13:09:25 CEST] <elmargol> What devices are going to have problems? [13:14:45 CEST] <JEEB> elmargol: if you mean hardware devices without your custom player that handles full range correctly - everything [13:15:14 CEST] <elmargol> I'm just wondering what a safe color space to use is. [13:15:29 CEST] <elmargol> It should work on chromecast, android, chrome and smarttvs [13:15:34 CEST] <JEEB> well the difference between the J and the non-J ones is just the range [13:15:48 CEST] <elmargol> yuv420p looks washed out here [13:15:59 CEST] <JEEB> then you have dealt with it incorrectly [13:16:58 CEST] <JEEB> limited range and full range YCbCr should both have the same stuff, just that limited range has less values in between (because highest and lowest values are out of range there) [13:17:21 CEST] <JEEB> washed out sounds like you have full range YCbCr and then you are showing it as limited range :P [13:17:33 CEST] <JEEB> (because then stuff clips) [13:17:34 CEST] <elmargol> Stream #0:0(eng): Video: h264 (Main) (avc1 / 0x31637661), yuvj420p(pc), 1280 [13:17:35 CEST] <elmargol> x720 [SAR 1:1 DAR 16:9], 15281 kb/s, 50 fps, 50 tbr, 50k tbn, 100 tbc (default) <- source [13:18:06 CEST] <JEEB> someone was perverted enough to use full range coding [13:18:23 CEST] <elmargol> Stream #0:0(eng): Video: h264 (High), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], [13:18:23 CEST] <elmargol> 50 fps, 50 tbr, 1k tbn, 100 tbc (default) <- encoded video [13:18:25 CEST] <JEEB> is that by chance a funimation encode reflagged correctly by HS? [13:18:50 CEST] <elmargol> source is from a gopro 720p 50 fps [13:18:55 CEST] <JEEB> jesus fuck [13:18:59 CEST] <JEEB> gopro does full range? [13:19:08 CEST] <elmargol> yes [13:19:15 CEST] <JEEB> way to go creating files that nothing can play out of the box [13:19:20 CEST] <elmargol> true [13:19:27 CEST] <elmargol> thats why I',m batch converting [13:19:37 CEST] <JEEB> I'm not even sure if the editors handle that correctly [13:19:45 CEST] <elmargol> ffmpeg -i $file.Name -crf "18" -maxrate 8000k -c:a "copy" -pix_fmt "yuvj420p" $outfile [13:20:13 CEST] <elmargol> thats the current line if i do yuv420p it looks washed out [13:20:16 CEST] <JEEB> yeah, you will basically want to convert the range from full to limited (aka PC to TV) [13:20:31 CEST] <JEEB> and seemingly for you if you set the pix_fmt correctly it doesn't do that [13:20:34 CEST] <elmargol> maybe I should just up the contrast? [13:20:47 CEST] <JEEB> nah, there should be a way to do that with a filter [13:20:56 CEST] <JEEB> and it wouldn't be the contrast anyways [13:21:13 CEST] <elmargol> so i should not use "yuvj420p"? [13:21:26 CEST] <JEEB> nope [13:22:09 CEST] <JEEB> also the J marked things should already die but I think swscale still needs them or so (it should just say yuv420p (pc) or yuv420p (tv)) [13:22:29 CEST] <JEEB> because the data is the same, it's just the used range [13:22:39 CEST] <JEEB> anyways, trying to google on how to convert the range [13:23:36 CEST] <elmargol> JEEB, gopro has a tool for windows to convert the video to a watchable format. I don't use this tool [13:23:45 CEST] <elmargol> I use blender to edit my videos [13:23:59 CEST] <JEEB> also... washed out... could that actually be the conversion working but the videos actually being limited range (while being signaled as full range) [13:24:18 CEST] <elmargol> maybe the video player is just stupid [13:24:19 CEST] <JEEB> basically, is it blacks becoming grey or so? [13:24:45 CEST] <JEEB> a sample would be fabulous if you can create a small one quickly [13:24:58 CEST] <JEEB> elmargol: what OS are you on? [13:25:09 CEST] <elmargol> windows 7 and ubuntu 14.04 [13:25:13 CEST] <elmargol> currently win7 [13:25:23 CEST] <JEEB> you can check out how https://mpv.srsfckn.biz/ renders it [13:25:35 CEST] <JEEB> if your opengl video drivers don't suck it should pretty much be the reference [13:25:56 CEST] <JEEB> if that thing looks washed out, then gopro fucked up signaling the range [13:26:27 CEST] <JEEB> if that thing looks fine, then most probably the signaling is correct and you just need to correctly convert the range with a video filter [13:26:50 CEST] <JEEB> you use it by drag and dropping a file on the exe [13:27:03 CEST] <JEEB> (which uses the file as the first command line argument) [13:31:34 CEST] <elmargol> JEEB, https://drive.google.com/file/d/0B-tNIlJJusNxTHEwNEkzdDBhU0k/view?usp=shari… [13:32:26 CEST] <JEEB> decoded pictures don't really help too much. also do try the mpv method I just noted [13:34:36 CEST] <JEEB> basically if you want to provide a sample it'd rather be a short clip from the camera [13:34:58 CEST] <elmargol> ok so it is the player making the difference [13:35:16 CEST] <elmargol> ok so my encoding is fine [13:35:30 CEST] <JEEB> so does mpv on the source look fine? [13:35:44 CEST] <elmargol> on pmv both look the same [13:36:16 CEST] <elmargol> on ffplay / vlc the contrast on the source is higher [13:36:31 CEST] <elmargol> and the encoding looks washed out [13:37:16 CEST] <JEEB> anyways, if you want to provide a short sample from the source with the thing evident then I can poke at things as well to double-check [13:37:17 CEST] <elmargol> CompVideo is the player where it looks worst [13:37:32 CEST] <elmargol> JEEB, no need for that I'm happy like it is now [13:37:52 CEST] <elmargol> funny thing... the encoding is larger than the source... [13:38:47 CEST] <JEEB> but yeah, if mpv is used with the opengl renderer it should be good (if your opengl drivers are at the least bit capable) [13:39:14 CEST] <JEEB> it might be falling back on some other renderer if the opengl one can't initialize, and that might not be as good [13:39:15 CEST] <elmargol> Do you know a decent tool to compare two videos side by side? [13:39:51 CEST] <elmargol> Or one on top and one at the bottom or something like that [13:39:55 CEST] <JEEB> avisynth/vapoursynth come to mind [13:40:09 CEST] <JEEB> although I generally interleave things [13:42:53 CEST] <JEEB> here's how I compared three clips in vapoursynth, f.ex. http://up-cat.net/p/ef944b2a [13:42:54 CEST] <elmargol> reencoding the audio Stream #0:1(eng): Audio: aac ([255][0][0][0] / 0x00FF), 48000 Hz, stereo, 128 kb/s (default) does not make sense does it? [13:43:03 CEST] <JEEB> yeah [13:43:06 CEST] <JEEB> -c:a copy that [13:43:59 CEST] <elmargol> ok [13:45:37 CEST] <JEEB> (and in that vapoursynth script I used L-SMASH Works for the LWLibavSource filter and fmtconv for the fmtc functionality [13:46:06 CEST] <JEEB> but I guess if you've never scripted anything that looks really terrifying [13:46:46 CEST] <elmargol> why are you cropping the original source? [13:47:06 CEST] <JEEB> I did the same with the encodes [13:47:13 CEST] <JEEB> there was a lil' bit of black [13:47:17 CEST] <JEEB> borders [13:47:31 CEST] <elmargol> ah ok [13:47:44 CEST] <elmargol> doesn't look to terrifying :) [13:48:02 CEST] <JEEB> yeah, and then you open that in something like Vapoursynth Editor [13:48:05 CEST] <JEEB> and you can preview it [13:48:16 CEST] <elmargol> never used Vapoursynth [13:48:29 CEST] <JEEB> I moved my encoding tests to it a few months back [13:48:42 CEST] <JEEB> was getting tired of having to hack around high bit depth content with avisynth [13:48:53 CEST] <JEEB> which was another frame serving thing [13:48:59 CEST] <elmargol> never used avisynth *g* [13:49:36 CEST] <JEEB> basically software that lets you write scripts/filter chains and then preview them :) [13:49:49 CEST] <JEEB> (or push them to encoders) [13:50:00 CEST] <elmargol> yes I know what it is [13:53:39 CEST] <JEEB> it's very powerful and can be used for fun and profit :) [13:54:18 CEST] <JEEB> vapoursynth is multiplatform, but doesn't have an official way of handling audio. although there is a filter for that which saves audio as side data in the video frames, IIRC? [13:54:52 CEST] <JEEB> I never handled audio in avisynth so it really wasn't a loss of capability for me :) [13:59:00 CEST] <elmargol> Well I use blender for all my editing needs [13:59:13 CEST] <elmargol> Works decent [14:00:43 CEST] <elmargol> mkvtoolnix if I have to cut something out, ffmpeg to encode. [14:00:55 CEST] <elmargol> blender for nonlinear editing [14:10:12 CEST] <durandal_1707> elmargol: there is framepack filter in ffmpeg [14:10:20 CEST] <ribasushi> ubitux: in case you want to add more info to https://trac.ffmpeg.org/ticket/3956 [14:10:54 CEST] <ribasushi> ubitux: final resolution is this (patch referenced within at [4]): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794327 [14:11:50 CEST] <elmargol> durandal_1707, I was thinking about ffplay not ffmpeg [14:12:12 CEST] <elmargol> I have 3-4 different encodings and like find the best quality/size [14:15:12 CEST] <durandal_1707> ffplay can use same filters and you can use pipe with ffmpeg [14:16:06 CEST] <elmargol> interesting [14:24:37 CEST] <ubitux> ribasushi: ah, sure, thanks [14:25:57 CEST] <ubitux> amended [14:26:16 CEST] <ribasushi> ubitux: cheers! [14:26:20 CEST] <ubitux> :) [14:26:34 CEST] Action: ribasushi grumbles in the corner on the amount of time between updates :( [14:43:08 CEST] <blue112> Hi here. I'm having bad time trying to compile libav to ffmpeg on msvc. I've installed msys and mingw, but the ./configure --toolchain=msvc is failing with "Symbol mangling check failed". What should I do next ? [14:43:27 CEST] <JEEB> which MSVC are you using? [14:43:46 CEST] <JEEB> also pastebin'ing config.log is useful [14:43:49 CEST] <blue112> 2010 express [14:43:54 CEST] <blue112> Sure, wait. [14:44:05 CEST] <JEEB> that's too old [14:44:16 CEST] <JEEB> you need 2013 u2 or newer for proper'ish capabilities [14:44:27 CEST] <JEEB> I think the documentation mentions this [14:44:32 CEST] <blue112> That's the version I need for several other projects. There's no way to compile it using 2010e ? [14:44:42 CEST] <JEEB> no [14:44:52 CEST] <JEEB> that shit just cannot do proper C [14:45:25 CEST] <blue112> 2013u2 is free to use ? [14:45:58 CEST] <JEEB> there is an express version which is free for everyone, as well as the community version which is available for private individuals as well as small businesses [14:46:12 CEST] <JEEB> express I think should be fine for FFmpeg [14:46:18 CEST] <blue112> I'll try that, thanks :) [14:46:22 CEST] <JEEB> community is pretty much pro [14:46:29 CEST] <JEEB> but with licensing limitations due to being free [14:46:41 CEST] <JEEB> like not being able to use it in a company bigger than X etc [14:47:05 CEST] <blue112> I think express will be plenty enough. [14:47:11 CEST] <JEEB> most probably :) [14:47:16 CEST] <JEEB> also 2015 is just out as well [14:47:20 CEST] <blue112> 6.5GB omg :( [14:48:31 CEST] <JEEB> also I see MSVC 2010 being mentioned in the docs but I'm pretty sure that is a mistake. and you are in for a world of pain if you use 2012 because you have to use a separate preprocessor to mangle the C code into stuff that 2012 can eat [14:48:49 CEST] <JEEB> 2013 was the first one with less-than-bad C support and 2015 improves on that [17:07:44 CEST] <JodaZ> "But even now as the last distributions are preparing to remove Libav" distros are removing libav? [17:15:30 CEST] <Orbixx> You guys still need help with finding a new server? [17:22:31 CEST] <BtbN> JodaZ, debian does, and so Ubuntu will follow. [17:23:08 CEST] <JodaZ> are the reasons discussed anywhere [17:23:54 CEST] <BtbN> there are some mails about it, and i think there also is some wiki page explaining the decision. [18:43:22 CEST] <blue112> Installed MSCV Express 2013, and got "chmod.exe: warning: this program is not supported by Windows NT", and then a LOT a "line 416; xxxxxx command not found" [18:43:27 CEST] <blue112> JEEB ? [19:57:37 CEST] <frenda> Hey there [19:58:36 CEST] <frenda> How can I find size of video? (I want to create an slideshow and then --> add it to the end of video) [20:01:08 CEST] <c_14> ffprobe -select_streams v -show_entries stream=width,height [20:14:44 CEST] <frenda> c_14: was excellent [20:35:27 CEST] <Timster> Hey, guys - I am concatenating multiple files, each a couple of hours long. Unfortunately, Unfortunately, I have out-of-sync issues between audio and video. The first file is perfectly fine (it is randomizing the order, so it's not everytime the same), but from file to file it gets more async'ed. Any idea what could cause this and how I can attempt to fix it? [20:42:22 CEST] <well0ne> how do you do this [20:42:28 CEST] <well0ne> concatenating [20:43:05 CEST] <well0ne> i had the same problem, until i pre-encoded everyfile with the same settings [20:44:17 CEST] <Timster> Hm, how about using -async 1 maybe? [20:44:44 CEST] <well0ne> that argument wasnt working for me [20:47:31 CEST] <Timster> You#re asking how I concatenate or how it works in general? [20:48:09 CEST] <Timster> I am trying to -async according my fps now. Hope that this might fix it. If not I guess I have to pre-encode as well [20:48:41 CEST] <well0ne> i meant how do you do it, not in geleral [20:49:23 CEST] <well0ne> well you gave us to few informations [20:49:46 CEST] <well0ne> what's the input/output, are the files having the same framerate [20:49:51 CEST] <well0ne> etc etc [20:50:02 CEST] <well0ne> which container/video/audio codec you're using [20:51:46 CEST] <Timster> Sorry, one second. [20:53:02 CEST] <Timster> This should explain most of it: http://stackoverflow.com/questions/31749414/concatenating-with-ffmpeg-audio… [20:57:46 CEST] <frenda> "+: [20:58:11 CEST] <frenda> Is there any trick to add effect between slides: https://trac.ffmpeg.org/wiki/Create%20a%20video%20slideshow%20from%20images ? [20:59:10 CEST] <well0ne> Timster, i have no answer for you, i had the same problems a year ago, in the meantime i use h264+mp3 preencoded and concatenate them to a livestream, since the i have no problems [20:59:12 CEST] <xerox> anybody compiled ffmpeg --with-ffplay on osx via brew? it did not install ffplay for me [20:59:36 CEST] <well0ne> meanwhile* [21:00:45 CEST] <Timster> So you're recording the audio stream seperate from video into a mp3 container? [21:01:23 CEST] <xerox> also is it possible to compile it in such a way that -hide_banner is the default? [21:02:37 CEST] <well0ne> nono, i just dont use aac [21:02:50 CEST] <sfan5> xerox: changing this to 1 will probably work https://github.com/FFmpeg/FFmpeg/commit/b4c89c90ffc723c38282fbf061bf65da67e… [21:09:21 CEST] <xerox> sfan5: neat. thanks [00:00:00 CEST] --- Sun Aug 2 2015

1 0