Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

August 2015

1 participants
62 discussions

ffmpeg-devel.log.20150810
by burek 11 Aug '15

11 Aug '15

[00:03:41 CEST] <philipl> I just read the updated nvidia driver readme. Although they decided to declare baseline support, they don't support the crazy features, unsurprisingly [00:05:58 CEST] <BBB> philipl: like constrained intra pred? [00:06:19 CEST] <philipl> "The NVIDIA VDPAU implementation does not support flexible macroblock ordering, arbitrary slice ordering, redundant slices, data partitioning, SI slices, or SP slices." [00:08:00 CEST] <rcombs> I've never gotten around to learning what all those things are [00:08:05 CEST] <rcombs> nor why they're not in Main/High [00:08:50 CEST] <philipl> They seem to be primarily 'useful' for dealing with extremely unreliable transports where you don't expect to receive intact pictures. [00:10:15 CEST] <philipl> So you divide your pictures up into independelty decodable regions, and have redundant data, etc, etc. [00:10:27 CEST] <philipl> Now why the video encoding format is the right way to deal with that kind of thing is beyond me. [00:10:36 CEST] <philipl> Clearly beyond everyone else too, given the 0% adoption. [00:11:08 CEST] <philipl> BBB: Tha't an SVC feature right? They don't say anything about SVC. [00:11:21 CEST] <philipl> Intel vaapi claims to support MVC and SVC. Never tried it though [00:11:38 CEST] <cone-801> ffmpeg 03Marton Balint 07master:0166d329c3e3: ffplay: add specific constants for buffer fullness settings when using external clock [00:11:38 CEST] <cone-801> ffmpeg 03Marton Balint 07master:8628b06b317e: ffplay: increase MIN_FRAMES to 25 [00:12:37 CEST] <cone-801> ffmpeg 03Niklesh 07master:d670848d4c27: movtextdec: Use default style information from movtext header [00:20:36 CEST] <wm4> philipl: I keep wondering about that [00:20:43 CEST] <wm4> philipl: e.g. how they even return the data [01:12:57 CEST] <philipl> wm4: One can only imagine. [01:45:09 CEST] <michaelni> philipl, last commit broke fate-sub-movtext fate-sub-subripenc [01:55:38 CEST] <michaelni> philipl, should the fate references be updated or something else ? [02:17:47 CEST] <cone-801> ffmpeg 03Michael Niedermayer 07master:0eb896b38dc5: Revert "movtextdec: Use default style information from movtext header" [02:19:16 CEST] <michaelni> philipl, i reverted it, the code does odd things and theres different output on x86 & mips both differing from the reference for the fate tests (also see my reply to the patch on ML) [02:31:32 CEST] <philipl> hmm [02:32:34 CEST] <philipl> I assumed the three byte copy was leaving an alpha byte untouched. [02:35:49 CEST] <jamrial> philipl: would AV_W*24 work for that? [02:36:42 CEST] <philipl> possibly. [02:51:32 CEST] <cone-801> ffmpeg 03Michael Niedermayer 07master:8c75a338124f: postproc: Deprecate QP_STORE_T, it lacks a PP/AV/FF prefix [04:54:10 CEST] <cone-801> ffmpeg 03Michael Niedermayer 07master:46f15de8a4ea: avformat/gifdec: correct r_frame_rate for single frame gifs [10:13:20 CEST] <thardin> is tim ever in here? [10:14:42 CEST] <thardin> or I guess any other mxf peeps [10:15:41 CEST] <thardin> thought I'd get a second opinion on marking mxfdec seeking as pts based [11:14:02 CEST] <cone-469> ffmpeg 03Luca Barbato 07master:0f562f5b833d: h264: Do not print an error when the buffer has to be refilled [11:14:02 CEST] <cone-469> ffmpeg 03Hendrik Leppkes 07master:b1d547fe024a: Merge commit '0f562f5b833d603e04123d198c59f8b2b5eb43e4' [11:18:07 CEST] <ubitux> what's the logic ffmpeg adopts for deciding which packets to write in the output when packets are coming from different sources? [11:18:12 CEST] <ubitux> smallest pkt.pts goes first? [11:18:38 CEST] <nevcairiel> there is probably some more advanced interleaving logic, but thats probably the major factor [11:18:49 CEST] <cone-469> ffmpeg 03Paolo Bizzarri 07master:1542ec96389f: cosmetics: Drop spurious spaces from if clauses [11:18:50 CEST] <cone-469> ffmpeg 03Hendrik Leppkes 07master:e1def4ffec20: Merge commit '1542ec96389f32e5081c6c607e4b6f5e257ccdf2' [11:18:52 CEST] <ubitux> any idea where this code is located? [11:19:00 CEST] <ubitux> except that "ffmpeg.c" [11:19:28 CEST] <nevcairiel> the actual interleaving is in avformat, probably utils.c [11:19:28 CEST] <ubitux> also wonder how that works with threading [11:19:36 CEST] <nevcairiel> not sure which part you are actually looking for [11:19:51 CEST] <nevcairiel> or mux.c, i think thats a thing [11:20:12 CEST] <ubitux> well, ffmpeg is most likely not relying on the avformat interleaving when you mux video from one file and audio from another one typically [11:20:18 CEST] <ubitux> it's not going to send all the video packets to avformat [11:20:19 CEST] <cone-469> ffmpeg 03Martin Storsjö 07master:8e34089e265a: movenc: Check that frag_info entries exist in mov_write_sidx_tag [11:20:20 CEST] <cone-469> ffmpeg 03Hendrik Leppkes 07master:6c52432b4812: Merge commit '8e34089e265a6b01e1e3301e8864439d26793753' [11:20:23 CEST] <ubitux> then all the audio packets [11:21:45 CEST] <ubitux> there is indeed a queue (max interleave something) in avformat, but that's probably for finer interleave adjustement [11:22:15 CEST] <ubitux> i'm more curious about the logic of ffmpeg as an api user dealing with distinct where it has to interleave somehow sources [11:22:33 CEST] <ubitux> (move "sources" before "where") [11:23:32 CEST] <cone-469> ffmpeg 03Martin Storsjö 07master:83f254e65f93: movenc: Rename reserved_moov_pos to reserved_header_pos [11:23:33 CEST] <cone-469> ffmpeg 03Hendrik Leppkes 07master:7653ebfff6ea: Merge commit '83f254e65f938657a4dbec711e4c94252a72daf9' [11:24:08 CEST] <wm4> are you sure it doesn't just buffer all video packets? it would be stupid, but required for good interleraving [11:24:45 CEST] <ubitux> i'm pretty sure ffmpeg doesn't explode in memory when i stream copy from different inputs [11:25:05 CEST] <wm4> but it also doesn't create broken files, right? [11:25:26 CEST] <ubitux> i think so [11:25:57 CEST] <wm4> then ffmpeg.c must be doing it [11:25:58 CEST] <ubitux> my guess is that it's controlling what sources need to be demuxed and avoid making a too large shift [11:26:04 CEST] <wm4> oh, that's what abou asked about [11:26:07 CEST] <ubitux> then avformat assures exact/proper interleaving [11:26:15 CEST] <wm4> s/abou/you [11:26:28 CEST] <ubitux> yeah, i'm curious how it manages to do that [11:26:46 CEST] <ubitux> and i think it was in place before the threading happened in ffmpeg.c [11:26:57 CEST] <cone-469> ffmpeg 03Martin Storsjö 07master:5f200bbf98ef: movenc: Place the sidx index after the initial moov/mdat pair [11:26:59 CEST] <cone-469> ffmpeg 03Hendrik Leppkes 07master:10ea06b3bb86: Merge commit '5f200bbf98efe50f63d0515b115d2ba8dae297bc' [11:27:54 CEST] <wm4> nevcairiel: nice work with the merging [11:27:58 CEST] <wm4> nevcairiel: how annoying is it? [11:28:03 CEST] <nevcairiel> not very [11:28:11 CEST] <nevcairiel> most changes apply easy enough [11:28:25 CEST] <ubitux> wait for the incoming pixel format negociation in lavfi [11:28:54 CEST] <ubitux> and anyway yeah, thank you for doing this [11:29:21 CEST] <wm4> <ubitux> wait for the incoming pixel format negociation in lavfi <- they're about to duplicate even their own code [11:29:52 CEST] <nevcairiel> and when called out on it, the answer was "I'll just commit this, and then clean it up later" =p [11:29:56 CEST] <nevcairiel> how unclean of them [11:30:14 CEST] <wm4> I needed to point it out twice, too [11:30:17 CEST] <cone-469> ffmpeg 03Paul B Mahol 07master:7a7ca3cc2f43: avfilter/vsrc_testsrc: smpte(hd)bars: fix uninitialized last rows and columns of chroma planes [13:04:55 CEST] <michaelni> ubitux, about SAMI_multilang_tweak_tester.smi vs. SAMI_ass_capability_tester.smi, should i upload the duplicate file ? [14:13:14 CEST] <BBB> JEEB: have you had time to look at the #libav logs? [14:27:37 CEST] <ubitux> > Now realize that Calligra has 609 CMakeLists.txt files [14:27:41 CEST] <ubitux> someone is looking for troubles [14:29:31 CEST] <wm4> wow [14:29:55 CEST] <wm4> I sure love bloated cmake files full of repeated broken code, which do the same thing pkg-config could do in 2 lines [14:32:04 CEST] <nevcairiel> that blog post was silly, that guy is that kind of developer i hate, considering all libraries god given and instead of appreciating constant maintenance on the libs, hating on every change [14:32:38 CEST] <nevcairiel> (and considering its not that hard to write an app that works with both qt4 and qt5, probably also terrible code in his project :P) [14:35:48 CEST] <wm4> to be fair, sometimes API changes can look very pointless and downstreams also won't appreciate that they have to change their code [14:36:52 CEST] <nevcairiel> If i get to avoid having to write my own h264 decoder, I tend to be a bit forgiving, all the API changes in the world wouldn't come close to the effort saved [14:40:52 CEST] <wm4> yeah, but they will think "why the fuck did you have to change this fine library, now I have to spend an afternoon to fix my perfectly working code... oh fuck and the new code doesn't work on debian's current libav package!" [14:55:24 CEST] <BBB> and next they complain about poor quality and low speed [14:59:16 CEST] <Daemon404> the only change which pisses me off to this day for libav* [14:59:22 CEST] <Daemon404> is #define'ing CodecID [14:59:24 CEST] <Daemon404> which is VERY generic [14:59:56 CEST] <Daemon404> and the errors it produces are confusing at best for downstream [15:00:03 CEST] <Daemon404> since it is a define, the compiler is confused [15:00:13 CEST] <wm4> how did this ever work in codebases where there's a conflict? [15:00:22 CEST] <wm4> C++? [15:01:17 CEST] <Daemon404> https://github.com/FFMS/ffms2/blob/f8edbc36a20c9b782f54fc835e0dd1628d45a720… [15:15:28 CEST] <nevcairiel> wm4: for me it just renamed it in one file, and i didnt even notice until i went into a debuffer and wondered where the hell the AV prefix comes from =p [15:15:47 CEST] <nevcairiel> probably some cases where it will even result in build failure though [15:20:16 CEST] <Daemon404> nevcairiel, see, that's an evil sort of failure [15:20:42 CEST] <nevcairiel> it didnt actually break anything, and not like C has reflections where the names of things are important [15:20:43 CEST] <nevcairiel> but yeah [15:32:25 CEST] <nevcairiel> the same goes for the PixelFormat define we still have today, but that one seemed to trip up much less often [15:32:51 CEST] <Daemon404> yes [15:34:02 CEST] <ubitux> because deprecated warning are raised maybe? [15:36:11 CEST] <Daemon404> ubitux, ? [15:36:15 CEST] <Daemon404> the CodecID define is silent. [15:36:25 CEST] <Daemon404> any downstream code using that generic name internally will silently fuck u [15:36:28 CEST] <Daemon404> p [15:37:25 CEST] <iive> well, what are the odds that there is a project that is using CodecID for its own things and just now it tries to use ffmpeg? [15:37:37 CEST] <Daemon404> ? [15:37:43 CEST] <Daemon404> tons of projects use CodecID internally [15:37:44 CEST] <nevcairiel> it happened so several projects [15:38:07 CEST] <Daemon404> any framework is going to have its own codec ids [15:38:13 CEST] <Daemon404> that you need to map to lavf [15:38:14 CEST] <Daemon404> for example. [15:38:16 CEST] <iive> any project that have been using ffmpeg should have already ironed out that thing. [15:38:22 CEST] <Daemon404> wut? [15:38:29 CEST] <Daemon404> in what sense [15:38:34 CEST] <Daemon404> it was a silent update [15:38:39 CEST] <Daemon404> iirc it wasn teven listed in APIChanges [15:38:53 CEST] <iive> oh, my bad. [15:39:07 CEST] <Daemon404> i think the define is gone now anyway [15:39:10 CEST] <Daemon404> at the time i was annoyed [15:39:29 CEST] <nevcairiel> CodecID is gone yes [15:39:41 CEST] <nevcairiel> i forgot why we even used a define instead of a typdef [15:39:46 CEST] <nevcairiel> there probably was some convoluted reason [15:39:52 CEST] <Daemon404> elenril had some convoluted reason [15:42:04 CEST] <ubitux> Daemon404: ok [15:42:50 CEST] <ubitux> michaelni: yes please keep the second name [15:46:46 CEST] <michaelni> ubitux, just to make sure i dont misunderstand "yes i should upload" or "i should not and keep the 2nd file already in the fate suite" ? [15:47:38 CEST] <ubitux> rm fate-suite/sub/SAMI_ass_capability_tester.smi; mv SAMI_multilang_tweak_tester.smi fate-suite/sub/ [15:55:23 CEST] <durandal_170> ubitux: I added log scale to frequency axis [15:56:12 CEST] <ubitux> so the representation of high freq are boosted? [15:57:19 CEST] <ubitux> what's the point of configuring the win size btw? you're making rectangle for smaller windows and averaging for larger ones? [15:58:16 CEST] <ubitux> (testing soon) [16:01:46 CEST] <ubitux> small windows are very laggy [16:01:51 CEST] <ubitux> expected? [16:03:11 CEST] <ubitux> fscale is curious heh [16:04:00 CEST] <Daemon404> win size? [16:04:43 CEST] <ubitux> number of sample in the fft [16:05:09 CEST] <ubitux> but i suppose running a lot of fft for a frame is making it slow [16:05:13 CEST] <Daemon404> oh. [16:07:54 CEST] <ubitux> heh, i like how libvpx farts on the colors when trying to encode a demo of this filter [16:08:34 CEST] <ubitux> i see shades of blue and purple [16:08:50 CEST] <ubitux> even though the input only has 4 colors (black orange green red) [16:15:00 CEST] <durandal_170> ubitux: if they overwrite each other they are ored [16:15:38 CEST] <durandal_170> But could do something similar as in drawgraph [16:16:18 CEST] <durandal_170> log for fscale is for lower frequencies [16:17:27 CEST] <durandal_170> Imho line mode is more useful [16:19:27 CEST] <durandal_170> I could add background color and draw grid [16:20:08 CEST] <ubitux> if you set a small window size, you get really a shit ton of frames [16:20:13 CEST] <ubitux> (obviously) [16:20:33 CEST] <ubitux> you might want to average them or something [16:20:39 CEST] <ubitux> but might get complex [16:20:59 CEST] <ubitux> i guess adding a asetnsamples after the filter would help [16:21:29 CEST] <ubitux> ah, my bad no you can't it's a video output& [16:21:44 CEST] <ubitux> so you can only drop [16:27:16 CEST] <michaelni> ubitux, uploded [16:27:23 CEST] <ubitux> michaelni: thx [17:00:20 CEST] <Daemon404> g 42 [17:13:53 CEST] <kierank> thardin: tim is on holiday for 3 weeks [17:17:08 CEST] <ubitux> http://lucy.pkh.me/showfreqs.webm [17:17:31 CEST] <ubitux> (i'm dropping frames here) [17:17:44 CEST] <ubitux> (showfreqs=win_size=w64,fps=25) [17:18:39 CEST] <ubitux> it seems there is a glitch in the first sample sometimes [17:26:37 CEST] <kierank> dericed: ping [17:29:01 CEST] <durandal_1707> ubitux: for this filter you need 8k display [17:47:06 CEST] <kierank> https://usercontent.irccloud-cdn.com/file/QUeMJChs/IMG_20150810_164556.jpg [17:49:46 CEST] <cone-469> ffmpeg 03Michael Niedermayer 07master:b26497f82424: avcodec/mjpegenc_common: do not ignore the color_range field [17:51:09 CEST] <kierank> durandal_1707: 4:47 PM <"kierank> https://usercontent.irccloud-cdn.com/file/QUeMJChs/IMG_20150810_164556.jpg [17:51:13 CEST] <kierank> something is slightly wrong [17:51:40 CEST] <nevcairiel> looks like it hits the squares [17:51:56 CEST] <nevcairiel> if thats what its supposed to do [17:54:29 CEST] <kierank> yes but there's that broken signal in the bakground [17:55:01 CEST] <kierank> and if you put it to analogue mode it looks even weirder [17:55:28 CEST] <thardin> kierank: ah [17:56:10 CEST] <nevcairiel> the echos look like aliasing in the signal [17:56:57 CEST] <durandal_1707> kierank: this is smptebar? [17:57:11 CEST] <nevcairiel> does it go through any f ormat conversions? probably swscale rgb transform? [17:57:22 CEST] <kierank> durandal_1707: yes [17:57:26 CEST] <kierank> no, all uyvy422 [17:58:00 CEST] <durandal_1707> maybe chroma is misaligned [17:58:07 CEST] <kierank> oh wait there seems to be some swscale functions called [17:58:39 CEST] <kierank> durandal_1707: can smptebars generate uyvy422 natively? [17:58:56 CEST] <durandal_1707> nope only planar [17:59:07 CEST] <kierank> bugger [17:59:27 CEST] Action: kierank doesn't trust swscale to convert properly [17:59:37 CEST] <durandal_1707> there should be planar equivalent? [17:59:40 CEST] <nevcairiel> enable swscale info printing and verify it uses the planar->packed special converter [17:59:53 CEST] <nevcairiel> if there is such a thing for yuv422p -> uyvy422 [18:00:02 CEST] <durandal_1707> and unscaled converter [18:00:03 CEST] <kierank> the output hardware takes packed [18:00:04 CEST] <nevcairiel> the generic path probably clobbers your image [18:00:57 CEST] <nevcairiel> seems like there is such a thing [18:01:02 CEST] <nevcairiel> and it should usually auto-select it [18:01:09 CEST] <nevcairiel> but better verify =) [18:01:25 CEST] <kierank> ah yes it's better with unscaled path [18:01:38 CEST] <kierank> But not exact [18:03:15 CEST] <nevcairiel> unscaled should at least result in a bitexact byte reshuffling [18:03:57 CEST] <kierank> https://usercontent.irccloud-cdn.com/file/sjmSa7ph/irccloudcapture-18576133… [18:03:57 CEST] <kierank> yeah [18:04:06 CEST] <nevcairiel> the aliasing is gone, hooray [18:04:08 CEST] <kierank> I'm not sure if there's meant to be a line going across [18:08:27 CEST] <nevcairiel> dont you have a reference to compare to [18:09:42 CEST] <durandal_1707> those are +i and q [18:10:01 CEST] <durandal_1707> I think [18:12:42 CEST] <kierank> https://usercontent.irccloud-cdn.com/file/xvLwo2IK/irccloudcapture-40541786… [18:12:56 CEST] <kierank> I figured out how to get the graticule [18:14:31 CEST] <kierank> I think *technically* there should be a smooth transition between colours [18:14:35 CEST] <kierank> but I don't care about that [18:14:39 CEST] <kierank> because that's an analogue thing [18:17:52 CEST] <durandal_1707> I didn't toke I and q from dveo, should I? [18:18:49 CEST] <kierank> please send a patch and I will try [18:18:56 CEST] <kierank> I'm curious to see which will be better [18:27:37 CEST] <kierank> durandal_1707: [18:27:37 CEST] <kierank> 5:26 PM <mdsh> I believe the point is not the exact values but the relationship between the two [18:38:57 CEST] <wm4> what sorcery is this anyway? is it physically measuring the output of some reference screen? [18:39:51 CEST] <durandal_1707> kierank: sent on ml [18:41:24 CEST] <nevcairiel> wm4: probably directly from the output of some hardware, not from a screen [18:41:57 CEST] <nevcairiel> ie. feed yuv422 output hardware into scopre [18:41:59 CEST] <nevcairiel> -r [18:42:05 CEST] <kierank> https://usercontent.irccloud-cdn.com/file/pkPaJG3G/irccloudcapture177591402… [18:42:10 CEST] <kierank> very slight difference [18:44:44 CEST] <kierank> durandal_170: new patch is better [18:46:16 CEST] <kierank> wm4: it's an analogue-style measurement [18:46:20 CEST] <cone-469> ffmpeg 03Lukasz Marek 07master:bc9305316142: lavf/ftp: implement directory listing callbacks [18:46:21 CEST] <cone-469> ffmpeg 03Mariusz SzczepaDczyk 07master:ee44cb3c81a9: lavf/ftp: properly read an empty path [18:46:23 CEST] <kierank> to make sure the colours match [18:59:33 CEST] <cone-469> ffmpeg 03Michael Niedermayer 07master:55a07cf49c00: avformat/ftp: Use av_freep() for dir_buffer [19:09:42 CEST] <nevcairiel> i find it funny that we have this directory listing api, but it doesnt even support the file protocol [19:09:50 CEST] <nevcairiel> i would've figured thats what i start with =p [19:38:51 CEST] <BBB> nevcairiel: send a patch" [19:59:50 CEST] <ebail> Hi guys, I just post a question about RTCP infos extraction on mailing list (http://ffmpeg.org/pipermail/libav-user/2015-August/008379.html) I wonder if it would need an additional dev or if I am wrong. Thanks. [20:03:00 CEST] <durandal_1707> does it make sense to port smpte rp155 as audio source? [20:15:02 CEST] <kierank> durandal_1707: If its a 1khz tone it can be done with aevalsrc [20:15:36 CEST] <kierank> But I couldn't use it because I need an exact number of samples [20:17:21 CEST] <durandal_1707> sine can do it but there is 1second of silence, also you can use asetnsamples [20:19:09 CEST] <kierank> I need it variable [20:19:31 CEST] <kierank> Because of NTSC [20:20:07 CEST] <kierank> So 1601,1602,1601 pattern [20:31:17 CEST] <ubitux> doesn't support eval? [20:31:36 CEST] <ubitux> or maybe timeline so you stack two of them? [20:33:31 CEST] <ubitux> bte, sine might be better than aevalsrc for that [20:36:11 CEST] <ubitux> actually that might be possible with a hack [20:38:10 CEST] <ubitux> or maybe not [20:40:52 CEST] <ubitux> kierank: you can hack easily the number of samples in sine filter [20:41:10 CEST] <ubitux> or do it properly by changing it as an eval expression [20:48:53 CEST] <ubitux> almost done a PoC actually [20:49:59 CEST] <durandal_1707> what? [20:50:33 CEST] <durandal_1707> kierank: do you have paper? [20:56:53 CEST] <ubitux> kierank: so what's the exact pattern? 1601,1602 repeated or 1601,1602,1061 repeated? [21:02:28 CEST] <ubitux> ok done [21:04:03 CEST] <ubitux> kierank: http://b.pkh.me/0001-avfilter-sine-support-expression-in-the-number-of-ou.p… [21:04:23 CEST] <ubitux> then ffmpeg -f lavfi -i "sine=1000:samples_per_frame='print(1601+bitand(N,1))'" ... [21:04:37 CEST] <ubitux> you can drop the print obviously [21:11:22 CEST] <ubitux> i suppose that's 1602,1601,1602,1601,1602 for 30/1.001? [21:11:44 CEST] <ubitux> the expression needs to be adjusted then [21:14:53 CEST] <ubitux> something like st(0,mod(N,5)); 1602-not(not(eq(ld(0),0)+eq(ld(0),3))) [21:15:02 CEST] <ubitux> (untested) [21:19:22 CEST] <ubitux> sorry typo [21:19:29 CEST] <ubitux> st(0,mod(N,5)); 1602-not(not(eq(ld(0),1)+eq(ld(0),3))) [21:19:31 CEST] <ubitux> this works [21:20:00 CEST] <ubitux> ffmpeg -f lavfi -i "sine=1000:samples_per_frame='print(st(0,mod(N,5)); 1602-not(not(eq(ld(0),1)+eq(ld(0),3))))'" ... [21:20:34 CEST] <Daemon404> this is all i see ubitux typing: http://33.media.tumblr.com/ef86987cc27600cf449df78ce4243c74/tumblr_mfjlubEN… [21:20:40 CEST] Action: Daemon404 runs [21:20:45 CEST] <ubitux> haha [21:20:56 CEST] <ubitux> i'm sure you can understand the expression with little effort :) [21:21:00 CEST] <Daemon404> yeah sure [21:21:08 CEST] <Daemon404> not one you escape it for the shell though [21:21:10 CEST] <Daemon404> once* [21:21:19 CEST] <ubitux> no need to [21:21:24 CEST] <ubitux> there is '' [21:21:36 CEST] <Daemon404> oh indeed. [21:21:43 CEST] Action: Daemon404 invents a shell that doesnt allow ' [21:22:07 CEST] <ubitux> and the expression is simply: store N%5 in register 0, then 1602 - (reg(0)==1 || reg(0)==3) [21:23:03 CEST] <Daemon404> i was hoping i was wrong about the assembly semantics. [21:23:08 CEST] <ubitux> (actually 1602 - !!((reg(0)==1) + (reg(0)==3)) because there is no OR) [21:23:27 CEST] <ubitux> i can save one ! easily [21:23:37 CEST] <ubitux> but who cares [21:24:33 CEST] <ubitux> Daemon404: it might not work with tcsh yeah [21:24:46 CEST] <ubitux> but -filter_script is your friend then [21:25:41 CEST] <Daemon404> people use tcsh? [21:26:28 CEST] <ubitux> don't underestimate them [21:29:48 CEST] <BBB> ebail: youre correct, to the best of my knowledge theyre not exposed [21:46:43 CEST] <llogan> durandal_1707: do you have a twitter account? [21:47:01 CEST] <durandal_1707> Nope [21:47:04 CEST] <llogan> i want to mention how many filters you've made in that last ~month [21:47:25 CEST] <durandal_1707> I have g+ [21:50:02 CEST] <llogan> damn...too many characters to list them all [21:56:13 CEST] <BBB> llogan: lol [21:57:07 CEST] <ebail> BBB: any advice to expose it ? [21:57:27 CEST] <BBB> ebail: like you said, add it to metadata dict [21:57:37 CEST] <BBB> ebail: in whatever form is useful for you [22:10:21 CEST] <ebail> BBB: ok. So it would be the responsabiliy of the application to read dict at time, i.e before a new RTCP report is received ? [22:14:04 CEST] <BBB> if you dont want to lose previous one, yes [22:14:14 CEST] <BBB> but I mean, this is just for display, right? then it doesnt matter if you lose 1 [22:14:26 CEST] <BBB> ifyou want to do stuff with it, you would want ot do that inside libavformat, not in your app [22:18:06 CEST] <ebail> BBB: not only for display. I want to implement a simple algorithm on top that will change the encoder bitrate [22:19:13 CEST] <ebail> so that we will converge on highest bitrate without packet drops [22:20:00 CEST] <BBB> right, you want to do that inside libavformat [22:20:04 CEST] <BBB> dont do that in your application [22:22:27 CEST] <ebail> BBB: to change bitrate, I could not find a better way than restarting completely encoder with new bitrate. So lot of stuff are anyway done in my app [22:22:55 CEST] <BBB> uhm& ok [22:23:09 CEST] <BBB> you know thats kind of inefficient, right? [22:23:22 CEST] <BBB> its like using a nuke to kill a fly [22:23:26 CEST] <BBB> it works, sure& but ... [22:23:43 CEST] <wm4> enterprise corps have enough money to pay the nukes! [22:23:45 CEST] <BBB> reminds me of that 90s game called worms [22:24:32 CEST] <nevcairiel> 90s game? they still make those! [22:24:37 CEST] <nevcairiel> and its still fun :d [22:24:47 CEST] <ebail> BBB: what would be your solution so ? [22:24:50 CEST] <wm4> wasn't Worms 3D not fun? [22:25:25 CEST] <BBB> ebail: well, for one, restarting means you have to send a new keyframe [22:25:28 CEST] <BBB> thats hugely inefficient [22:26:03 CEST] <BBB> ebail: so Id just add a transport stream connection and send requests for bitrate changes over there [22:26:07 CEST] <ebail> BBB: true. But I was not able to change bitrate in live [22:26:14 CEST] <BBB> why not [22:26:44 CEST] <nevcairiel> x264 supports bitrate changes on the fly [22:27:07 CEST] <BBB> any non-toy encoder should support that... [22:27:17 CEST] <ebail> hum interresting. [22:27:37 CEST] <ebail> could you develop a bit the way to do it ? [22:27:54 CEST] <BBB> develop=elaborate? [22:27:57 CEST] <ebail> :) [22:28:02 CEST] <ebail> yep sorry [22:29:48 CEST] <BBB> look at x264_encoder_reconfig [22:29:57 CEST] <BBB> (assuming you use x264) [22:30:50 CEST] <ebail> BBB: I do. But I also use vpx and mpeg4 [22:31:18 CEST] <nevcairiel> vpx is more of a toy encoder, so it might not support that =p [22:32:37 CEST] <BBB> oh come on, vpx is used in hangouts [22:32:45 CEST] <BBB> so it will support it in some way [22:32:53 CEST] <ebail> hangout do it. true [22:32:54 CEST] <BBB> mpeg4& I dont know, depends on encoder I guess [22:32:55 CEST] <BBB> ffmpeg4? [22:33:00 CEST] <nevcairiel> is that why hangouts is so terrible [22:33:20 CEST] <BBB> I like it [22:33:45 CEST] <ebail> BTW I am working on ring. A DHT based communication soft (ring.cx), formely know as sflphone [22:35:43 CEST] <ebail> I think for the moment, we will keep our 'ugly' encoder restart. But I will definitely look to x264_encoder_reconfig. Regarding RTCP, I will work on how to export RTCP RR values by av_opt [22:37:09 CEST] <llogan> heh, worms. "Oh, there were batt'ries left." [23:20:02 CEST] <BBB> ebail: sure, dont feel forced to do anything :) [23:23:29 CEST] <ebail> BBB: sure. But your advices are good. Thanks. I have to finish something and will work on it ASAP. [00:00:00 CEST] --- Tue Aug 11 2015

1 0

ffmpeg.log.20150810
by burek 11 Aug '15

11 Aug '15

[00:14:04 CEST] <puzzles> Hello all, I'm having a problem encoding a PPM stream piped from another program stops encoding after exactly 360 frames. There is no error, ffmpeg just gracefully stops. [00:14:42 CEST] <puzzles> ffmpeg version 2.7.2-1 [00:16:18 CEST] <puzzles> c_14: http://0a5cf807cb72f95a.paste.se/ [00:17:39 CEST] <c_14> Get rid of the -t 6 [00:19:43 CEST] <puzzles> c_14: Thanks. I managed to push past 360 frames, at least. I take it multithreading is still experimental? [00:20:57 CEST] <c_14> -t isn't short for threads [00:21:27 CEST] <c_14> https://ffmpeg.org/ffmpeg.html#Main-options [00:21:31 CEST] Action: puzzles facepalms [00:24:29 CEST] <puzzles> c_14: Thanks. I had tried it without the -t option before, but was missing some other options which gave a similar problem. [05:36:15 CEST] <eijin> i have a h264 file encoded with x264.exe. im trying to use ffmpeg to convert it to mp4, the output mp4 ends up being variable frame rate mode but the source is contant frame rate [05:36:24 CEST] <eijin> ffmpeg -i file.h264 -r 29.970 -vcodec copy file.mp4 [05:36:35 CEST] <eijin> i even specified the frame rate with -r. any idea what im doing wrong? [08:31:53 CEST] <relaxed> eijin: ffmpeg -r 30000/1001 -i file.h264 -c copy output.mp4 [08:54:07 CEST] <eijin> relaxed doesn't seem to work [08:54:10 CEST] <eijin> ffmpeg -r 30000/1001 -i file.h264 -c copy output.mp4 [08:54:10 CEST] <eijin> mediainfo output.mp4 [08:54:10 CEST] <eijin> Frame rate mode : Variable [08:54:10 CEST] <eijin> Frame rate : 29.970 fps [08:54:10 CEST] <eijin> Minimum frame rate : 25.000 fps [09:23:20 CEST] <relaxed> eijin: oh, try ffmpeg -framerate 30000/1001 -i file.h264 -c copy output.mp4 [09:26:22 CEST] <relaxed> ffmpeg -h demuxer=h264 [09:26:58 CEST] <durandal_1707> how you expect to framerate change if you use copy and trust mediainfo output [09:33:11 CEST] <relaxed> it works with stream copying [10:04:37 CEST] <satinder> Hi , How I can use ffmpeg libraries in my own c code ?? please help . [10:09:49 CEST] <JEEB> there are examples in the source tree [10:10:01 CEST] <JEEB> https://github.com/FFmpeg/FFmpeg/tree/master/doc/examples [10:13:39 CEST] <satinder> I want make a c program using ffmpeg library for detect the vocals from any mp4 song [10:14:05 CEST] <satinder> is that possible with ffmpeg library ?? please help . [10:33:35 CEST] <eijin> relaxed> eijin: oh, try ffmpeg -framerate 30000/1001 -i file.h264 -c copy output.mp4 [10:33:38 CEST] <eijin> why did that work :p [10:33:58 CEST] <eijin> i tried -r initially shouldnt -r be the same as -framerate? [10:55:55 CEST] <eijin> even viewing ffmpeg -h long i dont see -framerate just -r [10:58:48 CEST] <JEEB> framerate is an muxer-specific option IIRC [10:58:52 CEST] <JEEB> *a [10:59:19 CEST] <JEEB> uhh, also I meant *demuxer-specific [10:59:25 CEST] <JEEB> usually it should only work with screen capture inputs, at least that's where I've seen it being used [11:00:12 CEST] <eijin> no this is just a regular video file i encoded to h264. nothing screen related :p [11:00:50 CEST] <eijin> i was just surprised it finally gave me a constant frame rate with ffmpeg cause everywhere i looked only found '-r' and it always resulted in variable despite fact source is constant [11:01:26 CEST] <relaxed> it works with raw inputs too [11:02:04 CEST] <eijin> but i heard from a few ppl its a known ffmpeg bug.. well when muxing in m4a audio encoded variably, ffmpeg will mangle the header somehow and make it appear constant (diff bug) [11:08:13 CEST] <eijin> any ideas on how to mux in aac audio (variable) with mp4 file (video only) and have the resultant mp4 audio stay variable? ffmpeg makes it 'constant' somehow. not sure if there's a workaround for that [11:08:43 CEST] <relaxed> what happens if you copy the stream? [11:13:18 CEST] <elmargol> Is there a Clapperboard detection in ffmpeg? [11:27:32 CEST] <eijin> relaxed like this? ffmpeg -i out.mp4 -i out.m4a -c:v copy -c:a copy result.mp4 [11:28:18 CEST] <eijin> i cancelled it because of how slowly it was going but it seemed to preserve the fact audio was encoded variably. is there a faster way to do that? just mux aac audio with video already in mp4 container? [11:28:47 CEST] <elmargol> eijin, can't you use mkv? [11:29:25 CEST] <eijin> well i can but i wanted to keep it in a mp4 container [11:29:43 CEST] <elmargol> If you don't mind mkv https://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html [11:29:52 CEST] <eijin> i copy 770 fps with that command which is kind of odd since it's a cached ssd disk [11:30:42 CEST] <eijin> i decided to use mp4box instead which does it in like a few seconds. i dont see why ffmpeg cant mux just as quickly though [11:30:47 CEST] <elmargol> eijin, you can try https://trac.ffmpeg.org/wiki/Concatenate [11:31:35 CEST] <elmargol> does not work for all codecs [11:33:45 CEST] <BtbN> concat != merging an audio and a video file [11:35:27 CEST] <eijin> so the way is the only only way to mux video and audio together no (copy and not transcode)? [11:35:33 CEST] <eijin> so the way i mentioned* [11:36:40 CEST] <BtbN> some -map parameters might be usefull, but in general, yes, that's how it works. [12:15:05 CEST] <atzorvas> in order to hide mouse from the recording I have to do draw_mouse 0 right? [12:41:32 CEST] <satinder> how I can create shared library of ffmpeg [12:41:45 CEST] <satinder> anybody can help [12:44:11 CEST] <ened> Hi! Given a MKV file has no language header set for a track, will ffmpeg auto-set the tracks language to 'eng' (English)? [12:45:26 CEST] <JEEB> I think no language info is implicitly English, you'd have to set unk or whatever to note that it's unknown. Or that might have been how mkvmerge does it. [12:52:15 CEST] <ened> JEEB: Yes, you are correct. I've been chatting with the #matroska folks as well, ffmpeg does the right thing. Thank you! [12:53:55 CEST] <ened> JEEB: As in "eng" is the default. http://www.matroska.org/technical/specs/index.html [14:12:49 CEST] <seeit> if I'm trying to live transcode a stream say from mkv to mp4 using -c copy to an apple tv should I use ffserver in that process? the problem is if the initial stream starts to buffer the output stream terminates on the apple tv [14:37:59 CEST] <BtbN> seeit, mp4 can't be live-streamed. [15:22:21 CEST] <seeit> sorry, we have a streamer in node.js and there's a module that allow us to pipe ffmpegs output directly to a http response, our problem with all approaches taken so far is that if the input stream buffers ffmpeg hits basically an EOF and kills our output stream. One idea I've had is to lie in the http header of our streamer of with an approximation of what the file converted to mp4 will be [15:24:53 CEST] <seeit> BtbN is ffmpeg aware and is there possible output to track the conversion percentage of a stream with fixed time length? [15:32:41 CEST] <DHE> I'm looking for something like ffserver but without transcoding. Basically take whatever I give it via .ffm and it just serves it to anybody who connects using only the equiv of "-codec copy" is that possible and I'm just not interpreting the docs right? [18:22:42 CEST] <ebail> Hi guys, I just post a question about RTCP infos extraction on mailing list (http://ffmpeg.org/pipermail/ffmpeg-user/2015-August/027924.html) IRC exchange might be easier. Thanks [18:24:27 CEST] <Timster> Hello, I am having trouble with concatenating multiple (some hour long) video files. Audio and video is getting out of sync more and more when it changes between them, but the files itself are perfectly fine. Does anybody have a clue on how to fix it? [20:46:58 CEST] <kyleogrg> hi [20:47:08 CEST] <kyleogrg> this should be a simple question for yall [20:47:23 CEST] <kyleogrg> I'm doing a cross-compile from linux for windows [20:47:36 CEST] <kyleogrg> using a build helper script [20:47:47 CEST] <kyleogrg> so i run the command: ./cross_compile_ffmpeg.sh [20:48:08 CEST] <kyleogrg> this works. now I want to customize the build by adding --high_bitdepth=y. can I add this to the above command? [20:49:31 CEST] <JEEB> that doesn't sound like an ffmpeg configure option [20:49:41 CEST] <kyleogrg> When I try this, I get an error: ./cross_compile_ffmpeg.sh --high_bitdepth=y. I know i'm missing something obvious [20:49:54 CEST] <JEEB> you should actually read the cross compilation script :P [20:49:56 CEST] <kyleogrg> it's an option in the .sh file [20:50:36 CEST] <JEEB> well I have no idea what the damn script you're using and so forth. so I'm not at all sure how this relates to ffmpeg [20:50:59 CEST] <JEEB> not to mention that there is no such high bit depth option in ffmpeg's own configure either [20:51:11 CEST] <JEEB> so it's most probably an option you give to one of the libraries used by ffmpeg [20:51:38 CEST] <kyleogrg> right. well, the problem probably is that i'm new to this and thus tend to miss some of the obvious steps [20:52:56 CEST] <kyleogrg> pastebin.com/dSr2LFgB [20:53:51 CEST] <kyleogrg> hmm, it's working now that I replaced the underscore with a hyphen. [22:00:55 CEST] <kyleogrg> how can I put two ffmpeg commands into one command line? [22:01:53 CEST] <Nolski> kyleogrg: you can put it into a shell script? [22:02:07 CEST] <llogan> ffmpeg && ffmpeg. ...depending on your shell, and how you want it to handle failures, etc [22:02:52 CEST] <kyleogrg> perhaps this will help: http://pastebin.com/7knM4gJC [22:03:11 CEST] <kyleogrg> i want to know if this is formatted correctly (for windows) [22:03:24 CEST] <kyleogrg> llogan: in windows cmd? [22:03:33 CEST] <llogan> FIIK [22:04:44 CEST] <ChocolateArmpits> Putting on one command line won't make them execute parallel [22:05:51 CEST] <kyleogrg> no... it's just that my current method (see pastebin) didn't seem to be working [22:06:13 CEST] <llogan> might want to ask in a powershell (or whatever) channel [22:06:31 CEST] <ChocolateArmpits> you need to use the bracket ^ at the end of the line [22:06:33 CEST] <ChocolateArmpits> http://stackoverflow.com/questions/69068/long-commands-split-over-multiple-… [22:06:56 CEST] <ChocolateArmpits> if you want to split a command line [22:07:16 CEST] <kyleogrg> okay. but is this used to combine independent commands? [22:07:36 CEST] <DHE> Is there an option to copy keyframes from input to output? That is, if frame number X in the input is a keyframe, then frame number X will also be a keyframe in the output [22:08:24 CEST] <ChocolateArmpits> kyleogrg: commands are combined by either using && or & [22:09:00 CEST] <ChocolateArmpits> ^ simply allows to separate a continous single command line over multiple lines for easier management [22:09:07 CEST] <kyleogrg> ChocolateArmpits: okay... so i just tried &. in ffmpeg cmd, i get the message" file NUL already exists. exiting. [22:09:21 CEST] <ChocolateArmpits> you need -y parameter [22:09:29 CEST] <ChocolateArmpits> NUL is a an empty file [22:09:37 CEST] <edoceo> I have a source media that ffprobe reports a Video stream, but when I convert to mp4 that stream is gone. [22:09:47 CEST] <edoceo> Playing the source webm with VLC there is no video. [22:09:52 CEST] <ChocolateArmpits> -y forces ffmpeg to overwrite it, even when it's an empty file [22:10:04 CEST] <edoceo> But how can I make ffmpeg realise that the video is missing and then just make a blank video stream? [22:10:37 CEST] <kyleogrg> ChocolateArmpits: i will try that [22:10:42 CEST] <ChocolateArmpits> edoceo: does the stream contain any bytes ? [22:10:54 CEST] <edoceo> I don't think it does, I cannot tell [22:11:03 CEST] <edoceo> Or, I don't know how to tell [22:12:11 CEST] <kyleogrg> ChocolateArmpits: it works, thanks a lot [22:12:18 CEST] <ChocolateArmpits> kyleogrg: np [22:13:30 CEST] <ChocolateArmpits> edoceo: I think your situation is too specific to give a general answer, we need something to judge if the stream is viable or not [22:13:49 CEST] <edoceo> Oh, when I play it I see nothing [22:13:52 CEST] <kyleogrg> ChocolateArmpits: but then, i cannot use -n to skip already-encoding files, can i? [22:14:01 CEST] <kyleogrg> already-encoded* [22:14:05 CEST] <edoceo> What if I have a webm with crappy video and then just want to replace it with like lavfi or something? [22:15:15 CEST] <ChocolateArmpits> kyleogrg: write a batch script that checks if the file exists, if the bytes are no longer being written and then skip encoding [22:15:37 CEST] <kyleogrg> ChocolateArmpits: yeah. thanks [22:15:45 CEST] <ChocolateArmpits> kyleogrg: other way would be to create a temporary variable to signify that encoding has completed [22:15:54 CEST] <ChocolateArmpits> and then check that variable upon starting another encoding [22:16:00 CEST] <kyleogrg> ok [22:16:22 CEST] <ChocolateArmpits> I feel like I got somewhat rusty with batch over the last months that I started using Powershell [22:16:27 CEST] <llogan> ffmpeg -f lavfi -i testsrc=d=5 -f rawvideo -pix_fmt yuv420p - | ffmpeg -f rawvideo -video_size 320x240 -framerate 25 -pixel_format yuv420p16le -i - -c:v rawvideo -f nut - | ffplay -i - [22:17:17 CEST] <ChocolateArmpits> edoceo: You mean blank black video ? [22:41:30 CEST] <kyleogrg> okay, so when two-pass encoding, ffmpeg makes a log file: ffmpeg2pass-0.log [22:41:40 CEST] <kyleogrg> can i choose where this temporary file is saved? [22:47:35 CEST] <c_14> -passlogfile [22:47:36 CEST] <c_14> iirc [22:55:49 CEST] <kyleogrg> c_14: how can it be used in a two-pass command, for example [22:55:51 CEST] <kyleogrg> ? [22:58:53 CEST] <c_14> ffmpeg -i video -c:v libx264 -pass 1 -b:v 9001k -passlogfile rtfm out.mkv [23:00:59 CEST] <kyleogrg> ok thx [23:57:34 CEST] <Platonides> hello [23:57:35 CEST] <Platonides> I'm trying to cut a video fragment with avconv version 0.8.17-6:0.8.17-1 by providing -ss (start time) -t (duration). [23:57:43 CEST] <Platonides> I tried both before and after -i inputfile.avi buy it starts the new one from the beginning nonetheless (ie. it seems to ignore -ss) [23:57:57 CEST] <Platonides> am I missing anything obvious? [23:59:32 CEST] <klaxa> well first of all this is #ffmpeg, for avconv support there is #libav also your version is old (ancient) [00:00:00 CEST] --- Tue Aug 11 2015

1 0

ffmpeg-devel.log.20150809
by burek 10 Aug '15

10 Aug '15

[00:12:33 CEST] <kierank> durandal_170: maybel [00:12:49 CEST] <kierank> https://github.com/kierank/dveo-linux-master/blob/master/Examples/SDIVIDEO/… [00:13:01 CEST] <kierank> dunno if it's correct though [12:11:28 CEST] <durandal_1707> kierank: qctools have scoop [12:30:20 CEST] <ubitux> http://blitiri.com.ar/p/libfiu/ [14:34:31 CEST] <cone-402> ffmpeg 03Michael Niedermayer 07master:c64f01227ff6: swscale/swscale: Document param[0..1] [14:34:31 CEST] <cone-402> ffmpeg 03Michael Niedermayer 07master:16df02fd2e5b: avcodec/snowenc: Avoid use of deprecated me_method [14:34:40 CEST] <kierank> durandal_1707: thanks [14:40:33 CEST] <kierank> durandal_1707: i sent you the spec, right? [14:41:46 CEST] <durandal_1707> I have hd spec where numbers are [14:43:07 CEST] <durandal_1707> and the code you linked have diffference by 1 sometimes for hd version [14:43:13 CEST] <kierank> I don't understand your 75% grey number [14:44:12 CEST] <kierank> the comment is wrong I think [14:44:15 CEST] <kierank> it should be 75% white [14:44:36 CEST] <durandal_1707> probably [14:46:35 CEST] <BBB> michaelni: so now that param is documented... [14:46:46 CEST] <BBB> michaelni: can we deprecate it and use properly named private options for each scaler? [14:47:00 CEST] <BBB> michaelni: just like we do for codec-specific options in libavcodec or demuxer-specific options in libavformat [14:47:26 CEST] <BBB> michaelni: next thing, someone will add an option called specialvalue to AVCodecContext and avcodec_open3() [14:47:45 CEST] <BBB> (same for the flags I guess, thats a mixed back of all kind of stuff) [14:48:39 CEST] <wm4> BBB: well the swscale API is very redundant [14:48:49 CEST] <wm4> you don't always need to use the weirder "older" functions [14:49:03 CEST] <wm4> I think alloc_context + av_set_opt gives you almost all swscale features [14:49:15 CEST] <BBB> last time I checked, param was only exposed as param [14:49:22 CEST] <BBB> there was no other (more useful) way to set them [14:49:39 CEST] <wm4> you can set it with av_set_opt [14:49:42 CEST] <wm4> at least now [14:50:03 CEST] <wm4> (param0 and param1) [14:50:11 CEST] <BBB> what are the opts called? [14:51:23 CEST] <BBB> param0 and param1" [14:51:26 CEST] <BBB> and their docs are even better [14:51:29 CEST] <BBB> scaled param 0 [14:51:40 CEST] <BBB> so, lets deprecate them [14:51:44 CEST] <BBB> and use useful names [14:51:47 CEST] <wm4> avoption docs are usually very poor [14:52:12 CEST] <BBB> theres bad opensource projects in the world [14:52:15 CEST] <BBB> lets be just like them [14:52:34 CEST] <BBB> Id like to move to become better :) [14:55:30 CEST] <ubitux> it would be nice to fix the sws flags yes [14:55:50 CEST] <ubitux> many are exclusive [14:56:01 CEST] <wm4> currently it sounds like we're moving towards more compatibility, to other awesome OSS projects which happen to depend on us [14:56:02 CEST] <ubitux> like scaling algorithm [14:56:24 CEST] <ubitux> there is also a mess related to dithering [14:57:09 CEST] <ubitux> maybe it's fixed though [15:01:15 CEST] <michaelni> BBB, yes param[] should be replaced by named private options, the param[]stuff is really old and predates AVOption & AV* [15:01:25 CEST] <BBB> right [15:01:53 CEST] <BBB> I know param[] predates a lot of stuff and so I know why it was added [15:02:07 CEST] <BBB> I think now is a good time to reconsider param[] conceptually and get rid of it [15:02:45 CEST] <michaelni> yes [15:13:24 CEST] <BBB> I really conceptually like the avframe to avframe sws api idea [15:13:42 CEST] <BBB> I can see theres some issues, but for many users this would be great [15:14:16 CEST] <BBB> esp. because it can hide complexity without losing information [15:14:35 CEST] <BBB> e.g. lets say I have a frame that happens to be bt709 and all I care about is rescaling it from 1920x1080 to 1280x720 [15:15:01 CEST] <BBB> I can just set the resolution in the target frame, and leave everything else unset, and the api can fill it for optimal conversion (which means keeping it same as original) [15:15:06 CEST] <BBB> and it all just works, no information was lost [15:15:10 CEST] <BBB> but it was super-easy for the user [15:17:25 CEST] <BBB> wm4: and no, lets not be more compatible with old api, old api thats bad should die. transition periods of 2 years are more than enough [15:18:28 CEST] <wm4> not for dbian trollol [15:18:36 CEST] <BBB> so object to his patches [15:18:43 CEST] <BBB> I supported your objections and indicated why [15:19:01 CEST] <BBB> debian carries per-projec tpatches already [15:19:09 CEST] <BBB> these patches are super-trivial to generate [15:19:20 CEST] <BBB> he can either have patches that re-introduce old api on his support roll [15:19:24 CEST] <BBB> or he can patch the downstreams [15:19:30 CEST] <BBB> in our tree, the code will be gone [15:19:37 CEST] <BBB> 2 years is more than enough [15:19:54 CEST] <BBB> esp. for easily-sedable changes [15:19:56 CEST] <nevcairiel> unfortunately there seem to be some people that agree with him [15:20:40 CEST] <wm4> maybe we should use the argument that this will discourage future changes [15:20:47 CEST] <nevcairiel> and some even obstruse ideas like "just lets keep the broken code and not fix it, not even security issues, if they use it, their faul" [15:20:48 CEST] <wm4> but they might like this... [15:21:45 CEST] <BBB> imagine that 5 years from now, swscale param0 is still there [15:21:48 CEST] <BBB> I would be moritifed [15:21:58 CEST] <BBB> mortified* [15:22:42 CEST] <BBB> I already proposed that I will help him generate patches for the downstreams [15:23:01 CEST] <BBB> if he prefers to keep patches in debians ffmpeg version to reintroduce the old (deleted) apis, thats fine with me also [15:23:08 CEST] <BBB> andreas can choose which of these two he prefers [15:23:20 CEST] <BBB> 2 years is enough, really [15:23:32 CEST] <nevcairiel> I don't really mind that much if we keep an alias for an existing function one version longer or something, but some stuff is particularly convoluted to support (like get_buffer/release_buffer), and should just go [15:25:08 CEST] <nevcairiel> and some things are known to just be broken, like the old deinterlacer. Admittedly using lavfi to access yadif as a replacement is quite some effort, but still [15:25:25 CEST] <BBB> do you want me to put up replacement code? [15:25:38 CEST] <BBB> I think example code is easier for people if they can just copy it [15:25:58 CEST] <BBB> (my first lavfi took forever also; however, now I just copy the same code all over and its ok) [15:26:18 CEST] <BBB> if we give people copypasteable yadif replacement code, theyll be much happier for us to delete av_deinterlace [15:29:11 CEST] <nevcairiel> sure, such things will probably make some people happy [15:29:14 CEST] <nevcairiel> not andreas though [15:30:58 CEST] <BBB> is andreas on irc? [15:31:42 CEST] <nevcairiel> i think he was occasionally [15:31:47 CEST] <nevcairiel> not a regular though [15:34:52 CEST] <iive> projects that use ffmpeg libs hate to change their code... even when it is trivial. [15:35:38 CEST] <wm4> well it's not like we want to torture these projects for nothing [15:35:43 CEST] <nevcairiel> everyone likes a stable API, but stable shouldnt become stale [15:35:46 CEST] <iive> it might look prettier on ffmpeg side, but an application might be forced to ifdef its way into supporting both new and old api, in order to support larger range of distributions. [15:36:01 CEST] <wm4> iive: trust me, I've done enough of this [15:36:18 CEST] <wm4> supporting a relatively large range of releases, both FFmpeg and Libav [15:36:43 CEST] <wm4> (usually the latest release of each, and their git versions) [15:36:58 CEST] <wm4> and I can confirm that renames are very annoying [15:37:07 CEST] <wm4> but you can survive it [15:37:08 CEST] <nevcairiel> latest release and git should usually have the same available API, if you dont use deprecated things [15:37:20 CEST] <wm4> it's not that simple [15:37:27 CEST] <wm4> Libav releases are usually old [15:37:46 CEST] <wm4> and git often likes to deprecate and trash the deprecated thing at the same time [15:37:48 CEST] <nevcairiel> well "new" functions may not be available [15:38:30 CEST] <nevcairiel> thats something I've always found a bit hypocritical, lets keep the function or struct member around, but just make it stop working [15:38:36 CEST] <nevcairiel> that way apps can still link against it [15:38:41 CEST] <nevcairiel> but working, who cares [15:38:42 CEST] <nevcairiel> :D [15:38:56 CEST] <wm4> yeah, that's a bit strange [15:39:26 CEST] <wm4> so I'm in favor of making at least 1 release that contains both the reprecated functionality (still working), and the new replacement [15:39:38 CEST] <wm4> this makes updating your code relatively painless [15:39:46 CEST] <BBB> wait, Im not suggesting to not have compat periods [15:39:50 CEST] <BBB> Im saying 2 years is enough [15:39:52 CEST] <wm4> yeah [15:39:53 CEST] <BBB> 2 years really is totally enough [15:39:55 CEST] <nevcairiel> big changes should hopefully get rarer in the future anyway [15:40:03 CEST] <nevcairiel> most renames for namespacing have been done [15:40:09 CEST] <wm4> I really don't know what's going on with the debian guy [15:40:14 CEST] <wm4> I mean, it's 2 years! [15:40:18 CEST] <nevcairiel> its even longer [15:40:24 CEST] <nevcairiel> those are 2011/2012 things [15:40:33 CEST] <nevcairiel> (the ones libav suggested to drop) [15:40:58 CEST] <BBB> some of them were pushed fw several times already [15:41:03 CEST] <wm4> btw. is there any project that uses av_reverse? [15:41:03 CEST] <BBB> they should die [15:41:11 CEST] <nevcairiel> wm4: if any, then mplayer [15:42:09 CEST] <nevcairiel> if there were many users of it, someone may have complained already that its not exported in msvc builds [15:42:13 CEST] Action: kierank uses av_reverse [15:43:15 CEST] <iive> nevcairiel: libmpcodecs/dec_teletext.c is the only use in mplayer [15:43:38 CEST] <iive> but i've never heard of anybody compiling mplayer with msvc [15:44:31 CEST] <wm4> and mplayer still prefers the in-tree ffmpeg "copy" instead of dynamic linking [15:44:58 CEST] <nevcairiel> well of course, because all the private symbols they use are hidden in dynamic links =p [15:45:17 CEST] <BBB> bbl [15:46:16 CEST] <wm4> you can build it with shared ffmpeg now, but it still accesses some non-public fields in ffmpeg structs [15:46:28 CEST] <wm4> unless they fixed that meanwhile [16:07:32 CEST] <cone-402> ffmpeg 03Michael Niedermayer 07master:b7faa9d314f2: swscale/alphablend: support packed pixel formats [16:07:33 CEST] <cone-402> ffmpeg 03Michael Niedermayer 07master:f28ba31b1b18: swscale/alphablend: Fix big endian formats on LE [16:54:18 CEST] <cone-402> ffmpeg 03Michael Niedermayer 07master:87100e828a59: swscale/alphablend: Factor target computation out of the loops [17:29:56 CEST] <cone-402> ffmpeg 03Michael Niedermayer 07master:c5ebeaa3085b: swscale/alphablend: Support SWS_ALPHA_BLEND_CHECKERBOARD [17:46:09 CEST] <durandal_1707> ubitux: can you comment showfreqs? How to display bigger fft size on smaller width? [18:14:15 CEST] <cone-402> ffmpeg 03Michael Niedermayer 07master:0f9d46b70d2a: swscale/alphablend: Support chroma subsampling [19:17:44 CEST] <michaelni> nevcairiel, can you review ivans qsv patches ? (he said he will be away for 2 weeks from 11th, so might make sense to give him some feedback before he leaves) [19:41:57 CEST] <philipl> Well, all that work and the vdpau wmv3 playback is pretty dodgy. Anything that's no vc-1 seems to exhibit glitches while the software decoder is fine. [19:42:26 CEST] <philipl> Now I need to work out if that's just the hardware not really supporting non-Advanced content poorly or the integration is bad :-/ [19:53:58 CEST] <durandal_170> showspectrum should be called showspectogram [20:03:15 CEST] <nevcairiel> philipl: works mostly fine with dxva2 [20:03:22 CEST] <nevcairiel> michaelni: i'll have a look later [20:07:03 CEST] <michaelni> nevcairiel, thanks! [20:10:08 CEST] <wm4> I hope that email was "spicy" enough [20:20:58 CEST] <philipl> nevcairiel: http://samples.ffmpeg.org/V-codecs/WMV9/halo2_wmp9_WMV3+audio0x162.wmv [20:21:07 CEST] <philipl> Does that play correctly on dxva2? It's a disaster on vdpau [20:23:27 CEST] <nevcairiel> i cant try right now, will check later [20:23:54 CEST] <Compn> a lot of these files maybe broken, incorrect or just created by mencoder... so dont trust them to be valid at any rate :P [20:24:20 CEST] <Compn> i bet nvidia/ati hate our samples ;D [20:24:51 CEST] <philipl> Maybe so. Mind you, I have an nvidia purevideo marketing video in wmv that doesn't play right :-) [20:24:56 CEST] <philipl> Not sure if it came from them in wmv though [20:25:03 CEST] <Compn> fair enough [20:25:47 CEST] <Compn> probably decodes with binary codec though [20:26:04 CEST] <philipl> decodes fine with our decoder. [20:53:08 CEST] <BBB> where do you guys want me to put yadif examples as drop-in replacement for avpicture_deinterlace()? [20:53:33 CEST] <BBB> Id like to put this somewhere so we can point users to it and put an end to any discussion about removing avpicture_deinterlace() [20:53:38 CEST] <BBB> I want that crap gone [20:53:52 CEST] <ubitux> durandal_170: maybe tmr [20:53:58 CEST] <ubitux> remind me then [20:54:23 CEST] <ubitux> BBB: yadif is already auto inserted by ffmpeg when doing -deinterlace [20:55:13 CEST] <ubitux> BBB: grep do_deinterlace -A15 ffmpeg_filter.c [20:58:36 CEST] <cone-402> ffmpeg 03hSÇ 07master:7fbafd0b1bfb: avcodec: loongson optimize h264qpel with mmi v1 [21:00:18 CEST] <wm4> man I wonder how Libav ever managed to switch audio decoder to planar output [21:00:20 CEST] <BBB> ubitux: I mean api, not ffmpeg.c [21:00:24 CEST] <wm4> because that was a huge change [21:01:04 CEST] <BBB> ubitux: I have some local code that replaces avpicture_deinterlace() with libavfilter code, and would like to put it somewhere for documentation/example purposes and so we can link to it on stackoverflow/mailinglist/irc [21:01:06 CEST] <ubitux> BBB: lavfi api is quite more than calling avpicture_deinterlace; pasting the code of that function instead of using the lavfi api is probably a better solution :D [21:01:21 CEST] <BBB> I know, thats exactly the idea [21:01:28 CEST] <ubitux> doc/examples already contains a filtering_video.c example [21:01:30 CEST] <BBB> I want to put this code somewhere so people can copy paste it into their project [21:01:40 CEST] <BBB> super-lazy [21:02:21 CEST] <ubitux> BBB: just link to the file at an old revision [21:02:42 CEST] <jamrial> philipl: using "ffmpeg -hwaccel dxva2" with that sample i get garbage [21:02:58 CEST] <BBB> http://pastebin.com/YyN19RG6 [21:03:26 CEST] <BBB> the interesting code is line 101-102 and line 217-218 [21:03:31 CEST] <jamrial> philipl: it also gives me the warnings "Old WMV3 version detected, some frames may be decoded incorrectly" and "Reserved bit is not implemented" during decoding [21:03:47 CEST] <ubitux> BBB: you can just link to http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/imgconvert.c;h=dc… [21:03:53 CEST] <ubitux> and be done with it [21:04:36 CEST] <jamrial> philipl: this is with an AMD HD7950, so not Nvidia if that's what you were looking for [21:04:45 CEST] <ubitux> i don't think moving all that code in doc/examples is really a good example of using ffmpeg api [21:04:54 CEST] <ubitux> it's a c tutorial example [21:05:00 CEST] <BBB> Ill keep it on pastebin then [21:58:02 CEST] <nevcairiel> philipl: jamrial: if it issues that warning, then its not a compliant stream and thus expected failure [22:05:21 CEST] <jamrial> nevcairiel: mpc-hc (which uses lavfilters) doesn't try to use dxva2 with this video. did it detect it wasn't compliant, or lavfilters doesn't support wmv3 dxva2 at all? [22:07:04 CEST] <jamrial> hmm, just tried some (alledgedly) sane wmv3 videos and it's the same with those, so i guess it's not supported [22:07:07 CEST] <jamrial> VC-1 videos in contrast do work with dxva2 [22:07:21 CEST] <nevcairiel> wmv3 works in general [22:07:24 CEST] <nevcairiel> not on amd though [22:07:36 CEST] <nevcairiel> amds vc-1 dxva decoder doesnt so wmv3 for some reason [22:07:41 CEST] <nevcairiel> at least on some models [22:07:50 CEST] <nevcairiel> but noone cares enough about wmv3 for me to build a model list [22:08:40 CEST] <jamrial> haha, true enough [22:10:36 CEST] <iive> wmv3 have flags in its headers that indicate some legacy features [22:10:50 CEST] <iive> the other programs might detect those. [22:54:21 CEST] <philipl> Yeah, the software decoder plays that video just fine [22:54:48 CEST] <philipl> jamrial: likely failing for the same reason vdpau failed - the mis-ordered profile matching [22:54:54 CEST] <philipl> unless dxva2 doesn't try to profile match [22:55:11 CEST] <nevcairiel> there is only a condition in place to drop complex profile [22:55:21 CEST] <nevcairiel> anyway, not in the dxva2 ffmepg code anyway [22:55:26 CEST] <nevcairiel> its left to the user code [22:55:58 CEST] <nevcairiel> its a much too complex topic to handle that in avcodec, as dxva2 itself doesnt expose any info whats supported [22:57:37 CEST] <nevcairiel> .. and because of reasons, my own code doesnt do a profile check in get_format, but after avcodec_open2 returns [22:57:41 CEST] <nevcairiel> so it works :d [23:31:49 CEST] <philipl> Heh. fair enough. Well, I'm reasonably certainly I've done what I can here. [23:58:00 CEST] <wm4> nevcairiel: I just copy&pasted your ffmpeg code btw. [23:58:19 CEST] <wm4> I'd say this code is plenty of boilerplate-ish [00:00:00 CEST] --- Mon Aug 10 2015

1 0

ffmpeg.log.20150809
by burek 10 Aug '15

10 Aug '15

[05:24:44 CEST] <mrboc> greetings [05:31:35 CEST] <mrboc> Is anyone familiar with using ffmpeg for transcoding to uPnP clients? [09:19:56 CEST] <chungy> With the concat protocol, can you escape ' characters in file names? [09:20:11 CEST] <chungy> I've tried both \' and '' without luck. [09:24:07 CEST] <mrboc> have you tried double quotes [09:44:47 CEST] <chungy> Just did, doesn't work, only single quotes are valid (and it would just shift the problem to escaping double quotes in file names, too... :/) [16:56:37 CEST] <Stalkr_> Any idea why `-t hh:mm:ss` is getting ignored? It just keeps going past the duration. `-t s` works fine though [16:58:45 CEST] <Stalkr_> I have tried `ffmpeg -ss 00:03:55 -t 00:04:00 -i INPUT -c:v libx264 -c:a libfdk_aac OUT.mp4` and `ffmpeg -ss 00:03:55 -i INPUT -c:v libx264 -c:a libfdk_aac -t 00:04:00 OUT.mp4` without success [17:47:50 CEST] <durandal_1707> Stalkr_: it worked before? [17:48:12 CEST] <Stalkr_> durandal_1707: First time I try [18:25:11 CEST] <c_14> Stalkr_: are you confusing -t and -to ? [18:39:32 CEST] <Stalkr_> c_14: I think I was. Found out the difference. It had to do with specifying -ss before the input file though, helped to move it after the input. However I am trying to do "re-encode"-free cutting with -c copy, but this causes the output file to initially freeze. Any idea why that is? [18:40:09 CEST] <Stalkr_> The first second or so freezes [18:40:15 CEST] <c_14> While cutting or while playing the output file? [18:40:43 CEST] <Stalkr_> Playing it [18:40:59 CEST] <c_14> Maybe your player doesn't like negative timestamps. [18:42:17 CEST] <Stalkr_> Does seem to be happening in VLC but not MPlayerX [18:42:20 CEST] <Stalkr_> Can it be fixed? [18:42:53 CEST] <Stalkr_> Just doing: ffmpeg -i rm.mkv -ss 00:10:00 -t 12 -c copy out.mkv [18:43:02 CEST] <c_14> Either fix the player or reencode the video while cutting. [18:43:16 CEST] <c_14> When you copy the video codec you have to cut at the nearest I-frame. [18:43:42 CEST] <c_14> If that frame is before the seek point you want ffmpeg gives those frames a negative timestamp so that players won't play them. [18:44:00 CEST] <Stalkr_> Should I just enable -accurate_seek? [18:44:27 CEST] <Stalkr_> "When doing stream copy or when -noaccurate_seek is used, it will be preserved" [18:44:33 CEST] <Stalkr_> I assume that's what I am doing [18:45:14 CEST] <c_14> It's enabled by default. [18:45:29 CEST] <c_14> It just doesn't work with codec copy [18:45:59 CEST] <Stalkr_> So it can't be enabled with codec copy? [18:46:29 CEST] <Stalkr_> Sounds like the easiest is just to re-encode (unfortunately) [00:00:00 CEST] --- Mon Aug 10 2015

1 0

ffmpeg-devel.log.20150808
by burek 09 Aug '15

09 Aug '15

[00:11:34 CEST] <jamrial> BBB: think you could add (or feel like adding) vp9 support to tests/checkasm sometime? it would make benching and testing new versions of the functions much easier [00:11:39 CEST] <jamrial> benching ipred and mc right now is a pita for example [00:11:55 CEST] <BBB> uh, ok, I guess [00:12:01 CEST] <BBB> I havent looked much at it tbh [00:12:15 CEST] <BBB> I have my own (private, never cleaned up) version of an asm testing tool thats probably very similar [00:12:23 CEST] <BBB> I use it for all kinds of things, including ffvp9 optimizations [00:12:57 CEST] <BBB> Ill see what I can do to add tests to checkasm [00:13:04 CEST] <BBB> where does the code live? [00:13:18 CEST] <jamrial> tests/checkasm folder [00:15:48 CEST] <Gramner> writing checkasm unit tests is pretty easy as long as you know which the valid input ranges are (for stuff like pixel data it's fairly obvious) [00:16:06 CEST] <BBB> hm, yeah, that looks fairly similar [00:16:35 CEST] <Gramner> the tests are also run as part of FATE [00:16:43 CEST] <BBB> I guess one difference is that mine doesnt have to know about cputypes, it just automatically calls the cpu flag masking function with random flags (~0>>n) and checks the resulting cpu functions to see if it changed from the previous call or the c function [00:17:19 CEST] <Gramner> you don't need to know anything about cpu types for writing the actual tests [00:17:33 CEST] <Gramner> the code that calls the tests handles that [00:18:03 CEST] <BBB> I know, but checkasm.c has some stuff about cpu types, which looked weird/out-of-place [00:18:03 CEST] <BBB> can you force running one type of test? [00:18:03 CEST] <BBB> mine has string recognition of testnames [00:18:09 CEST] <BBB> ok [00:19:01 CEST] <Gramner> it runs all tests, but you can specify a function for benchmarking purposes [00:19:27 CEST] <BBB> so if I want to run just the 10bit version of intra_pred_8x8_chroma h264 planar, how doI do that? [00:19:52 CEST] <BBB> (ideally just the sse2 version, not the mmx version) [00:20:02 CEST] <BBB> (although admittedly mine doesnt allow you to specify that yet :-p) [00:21:51 CEST] <jamrial> apparently that's not currently possible. checkasm only accepts a seed value as argument or --bench [00:22:24 CEST] <Gramner> i don't really see any point in skipping tests, it runs pretty fast aside from benchmarks [00:22:52 CEST] <BBB> so, lets say you have a 32x32 idct [00:22:54 CEST] <BBB> thats quite slow [00:23:14 CEST] <BBB> so you dont want to run other tests while tweaking that simd, or run that while tweaking other simd (e.g. the idct16x16) [00:24:00 CEST] <Gramner> run tests/checkasm/checkasm and see for yourself, it finishes pretty much instantly [00:24:16 CEST] <Gramner> benchmarkes takes more time, but you can specify those using --bench=<function name> [00:24:37 CEST] <Gramner> (using just --bench runs all benchmarks) [00:24:49 CEST] <Gramner> compile by running make checkasm [00:27:22 CEST] <Gramner> now it could perhaps be useful to do more interations etc. and in that case it might make more sense to be able to specify tests, but the code is really new so it hasn't been tweaked a lot yet [00:29:18 CEST] <BBB> so what I have in mind is this (rough copypaste of some personal scripts here) [00:29:20 CEST] <BBB> http://pastebin.com/qwgPf8uq [00:30:25 CEST] <BBB> the way I run that is something along the lines of testasm -n 20 mc 0 0 4 4 0 0 1 1 1 1 [00:30:51 CEST] <BBB> and then it runs just the mc function for width=64, filter=0 (sharp), put (not avg), and subpel interpolation in both directions [00:31:20 CEST] <BBB> so if I make changes to that function, I can see the results on just that function immediately without havign to run the other 2*2*2*5*4-1 [00:31:26 CEST] <BBB> *number_of_optimizations [00:35:22 CEST] Action: BBB gonna go home, brb [00:35:29 CEST] <BBB> jamrial: Ill try to write some tests [00:35:46 CEST] <jamrial> ok, thanks [01:28:40 CEST] <BBB> Gramner: if you think its interesting, Ill try to port some of these features to checkasm, I think its useful [01:28:48 CEST] <BBB> (Im not sure anyone else would use it) [01:30:39 CEST] <Gramner> that'd be nice. both correctness verification and benchmarking are useful fore sure. and it's a lot more useful when commited instead of just being various scripts that someone has locally [01:31:48 CEST] <Gramner> on x86, checkasm also verifies that you don't use the upper half of 32-bit integers and that all clobbered callee-saved registers are saved and restored properly [01:31:51 CEST] <BBB> yeah :-p [01:31:53 CEST] <BBB> sorry about that [01:32:34 CEST] <BBB> so, the 32bit integer thing is & kinda weird, because I think we use ptrdiff_t everywhere [01:32:45 CEST] <BBB> (so we fix that at a different level than x264) [01:32:53 CEST] <BBB> I mean this is mostly to fix int stride not being sign-extended, right? [01:32:57 CEST] <Gramner> x264 does the same, just with intptr_t [01:33:19 CEST] <Gramner> but sometimes an int width or whatever is added to a pointer [01:33:51 CEST] <BBB> oh I see [01:33:56 CEST] <Gramner> I caught some of those after writing checkasm tests [01:33:59 CEST] <BBB> yeah sounds useful [01:34:01 CEST] <BBB> cool [01:34:14 CEST] <BBB> do you also do xmm clobber testing? [01:34:17 CEST] <Gramner> yes [01:34:29 CEST] <BBB> cool [01:34:41 CEST] <BBB> (all kind of stuff mine didnt do :-p) [01:37:58 CEST] <cone-899> ffmpeg 03Niklesh 07master:ecc806a224d7: movtextdec: Fix memory leaks by freeing mem allocs correctly [01:38:17 CEST] <philipl> BtbN: Did that Turkish guy ping you about temporal layer encoding? [02:25:25 CEST] <wm4> we really need some sort of async decoding API in lavc [02:25:40 CEST] <wm4> or reject async hw decoders in lavc and put them in a different lib [02:26:08 CEST] <wm4> it's just so damn impractical and clunky to wrap an async decoder in a sync API [02:29:54 CEST] <philipl> Yeah. [02:30:41 CEST] <wm4> the fucking corner cases [02:32:29 CEST] <baptiste> isn't it just a matter of ? "wait for callback to return" ? [02:32:41 CEST] <wm4> no [02:33:02 CEST] <wm4> you want buffering between input and output [02:33:27 CEST] <wm4> the sync API wants a full lock-stepped operation with one output frame per input frame (possibly with a delay) [02:33:38 CEST] <nevcairiel> async as in N:M relationship between input/output, not async as in threads and callbacks [02:33:49 CEST] <wm4> a hw decoder can request input packets and output decoded frames any time it wants [02:34:01 CEST] <wm4> N:M makes it easier [02:34:10 CEST] <wm4> but full async would be helpful too [02:34:19 CEST] <nevcairiel> although once you have the N:M api, adding a frame-ready threaded callback is probably not hard [02:34:40 CEST] <wm4> with N:M you can simplify buffering a lot [02:34:50 CEST] <wm4> and don't need to do stupid shit to ensure the lock-stepped operation [02:36:37 CEST] <baptiste> interesting, what's the interest of having a N:M relationship when lowest delay possible is usually a goal ? [02:37:51 CEST] <nevcairiel> but this is what would allow lowest delay [02:38:15 CEST] <nevcairiel> without it, you have to potentially buffer output frames because you cannot return 2 or 3 right away [02:38:33 CEST] <baptiste> but you can wait [02:38:45 CEST] <nevcairiel> buit then you have delay [02:38:51 CEST] <nevcairiel> waiting is delay [02:39:41 CEST] <nevcairiel> and there is also codecs where this is required to function properly .. say encoding interlaced hevc, for every input frame, it would produce two output packets .. which is something which is impossible right now [02:39:42 CEST] <baptiste> yes, I mean delay in frame not in time [02:39:47 CEST] <wm4> I can't wait to deprecate the old decoding API (thinking ahead here) [02:40:23 CEST] <nevcairiel> N:M wouldnt add delay, it could still work 1:1 if thats the best for a specific codec [02:40:28 CEST] <nevcairiel> but the point is, it doesnt have to :) [02:40:36 CEST] <rcombs> wm4: wouldn't proper async be significantly faster as well [02:40:39 CEST] <baptiste> if you do one frame in, one frame out with delay, how can you do better than that ? [02:40:47 CEST] <wm4> rcombs: depends [02:41:00 CEST] <wm4> I believe with mmal I already add a lot of buffering [02:41:04 CEST] <wm4> so it doesn't that much [02:41:14 CEST] <wm4> but the mmaldec.c logic is also complex and fickle [02:41:27 CEST] <nevcairiel> the codec could completely control how it wants data delivered and how it sends frames out [02:41:30 CEST] <nevcairiel> it can request more input [02:41:33 CEST] <nevcairiel> or push more output [02:41:49 CEST] <baptiste> I understand, hence my question of what is the interest [02:41:51 CEST] <nevcairiel> you dont have to buffer any output frames, or delay their output until you get more input [02:42:14 CEST] <nevcairiel> because many external decoders work that way [02:42:21 CEST] <nevcairiel> and wrapping them in ffmpeg is a big pain [02:42:54 CEST] <baptiste> I get that, but what is the ultimate interest of behaving like that, I'm trying to understand [02:42:56 CEST] <nevcairiel> the ffmpeg h264 decoder can buffer a bunch of frames at times to compensate, while other h264 decoders will just output them in one go when they are ready (it happens) [02:43:04 CEST] <baptiste> most settop boxes have very accurate timing [02:43:13 CEST] <nevcairiel> getting rid of the damn buffering isnt g ood enough of a reason? [02:43:19 CEST] <nevcairiel> buffering fully decoded frames in memory isnt fun [02:43:25 CEST] <baptiste> never fun [02:43:30 CEST] <baptiste> but don't ask for more then :) [02:43:42 CEST] <baptiste> ask one frame, output one frame [02:43:55 CEST] <nevcairiel> but thats not how advanced codecs work [02:44:05 CEST] <nevcairiel> they are not intra codecs that just decode their input [02:44:31 CEST] <baptiste> wouldn't most hw decoders in the world are probably h.264 decoders in settop boxes ? [02:45:13 CEST] <wm4> no, phones [02:45:27 CEST] <nevcairiel> many hardware APIs I have seen work in a M:N fashion, they can output more than one output frame when the situation allows for that [02:45:42 CEST] <baptiste> possibly yeah, but I don't think it would be intra codecs [02:45:42 CEST] <philipl> Is it enough to extend the existing API to allow the decode/encode to return that the packet was not consumed and should be resubmitted? [02:46:05 CEST] <nevcairiel> philipl: if we're going to break API, might as well do it properly [02:46:46 CEST] <baptiste> philipl, you can just wait in that case [02:48:08 CEST] <baptiste> so far Im not understanding the value in working in a M:N fashion, there must be some hardware consumption value or something like that when decoding 5 frames at once is more energy efficient [02:48:46 CEST] <nevcairiel> its not about that [02:49:10 CEST] <wm4> it's also much easier to use [02:49:25 CEST] <nevcairiel> its just that h264 for example decodes frames like that, at some point it wants to return more than one without needing more input, to reduce the decoder-internal buffers [02:49:35 CEST] <baptiste> wm4, not according to lavc, apparently :) [02:49:41 CEST] <wm4> ? [02:49:45 CEST] <nevcairiel> the h264 decoder in avcodec has some elaborate delay buffering to compensate for the 1:1 api [02:50:17 CEST] <baptiste> huh ? [02:50:31 CEST] <baptiste> if delay is 2 frames, it will wait 2 frames then 1-1 [02:50:51 CEST] <baptiste> the first delay is inevitable [02:51:36 CEST] <baptiste> the only example where I can see an example like you mention would be b frame packing like old divx was doing for the windows api [02:51:47 CEST] <baptiste> where in effect you had 2 frames at once [02:53:29 CEST] <baptiste> also some decoders back in days could be fed partial packets and would "auto parse" but that was phased out IIRC [02:56:31 CEST] <peloverde> vpnein still has packed bitstream... errr superframes [02:56:50 CEST] <nevcairiel> there is also situations where the coding parameters change, where you might want to flush out any frames from before the change before applying the change and resuming decoding [02:57:05 CEST] <nevcairiel> you cant do that without buffering input or output right now [02:57:17 CEST] <rcombs> what does M:N refer to? [02:57:29 CEST] <nevcairiel> M input packets produce N output frames [02:57:36 CEST] <nevcairiel> right now, its 1:1 [02:57:54 CEST] <wm4> basically decoupling input and output [02:58:12 CEST] <nevcairiel> well, technically its 1:N, since a decoder can decide not to output a frame [02:58:12 CEST] <wm4> like a video filter [02:58:26 CEST] <nevcairiel> but a decoder cannot decide to output two frames [02:58:40 CEST] <rcombs> nevcairiel: and you can send null packets to get more frames out, but you don't know when that's necessary, yeah? [02:58:43 CEST] <wm4> not outputting a frame is also sketchy [02:58:45 CEST] <baptiste> well you could call decode_video without input to flush [02:59:04 CEST] <wm4> but it sort of works because delaying also works like this [02:59:09 CEST] <nevcairiel> for one that would be something the user code has to control, and how would it ever know when to do that [02:59:20 CEST] <baptiste> a codec flag [02:59:26 CEST] <nevcairiel> thats dumb [02:59:38 CEST] <baptiste> huh, why is it dumb ? [02:59:45 CEST] <nevcairiel> whats wrong with a clean api [02:59:45 CEST] <baptiste> we have codec caps since ages [03:00:00 CEST] <baptiste> sure, what's a clean api ? [03:00:14 CEST] <nevcairiel> more obscure flags and special behavior is not going to make it any easier to use [03:00:32 CEST] <baptiste> depends, what's easier to use ? [03:00:44 CEST] <wm4> baptiste: a clean and simple API [03:00:52 CEST] <baptiste> sure, do you have more details ? [03:02:07 CEST] <wm4> I thought libav had a "blueprint" wiki page, but apparently not [03:02:12 CEST] <nevcairiel> for this particular case, two decode functions that work in tandem, one that submits an AVPacket, and one that retrieves decoded frames .. so you can do: while (more input) { submit(data); while(get(frame)) ...; } [03:03:02 CEST] <baptiste> from a user standpoint ? [03:04:38 CEST] <baptiste> if so, thats not a lot different than calling decode_video(null) [03:06:11 CEST] <nevcairiel> its just much clearer api this way, no special behavior on null, no weird *got_frame parameter anymore, just two functions which take one parameter each and return an appropriate error/success [03:06:47 CEST] <wm4> also for mmal it's significantly simpler on the implementation side (and I'd expect the same for similar APIs) [03:06:55 CEST] <baptiste> I mean you want new names and new prototypes, sure, we can do :) [03:07:09 CEST] <nevcairiel> shoe-horning things onto the old API is what makes the API so convoluted and complicated to use sometimes [03:07:18 CEST] <baptiste> the api is really simple [03:07:30 CEST] <wm4> too simple [03:07:30 CEST] <nevcairiel> it looks that way at first [03:07:37 CEST] <nevcairiel> and then you figure out all the special cases [03:07:39 CEST] <wm4> so you have to deal with weird corner cases [03:08:26 CEST] <nevcairiel> both wm4 and myself do have our own decently sized projects that make use of all the libraries, so we do deal with these things regularly [03:08:50 CEST] <baptiste> trust me I have a big project using the libs :) [03:08:59 CEST] <nevcairiel> some other devs only see ffmpeg.c unfortunately =p [03:10:15 CEST] <nevcairiel> anyway time to try sleeping in this heat [03:10:29 CEST] <wm4> hm, does anyone know if ffmpeg.c uses a separate decoder AVCodecContext? [03:10:30 CEST] <baptiste> Im interested in hearing about the corner cases though [03:10:34 CEST] <wm4> or does it use the stream's? [03:10:58 CEST] <nevcairiel> i think it creates a copy [03:11:10 CEST] <wm4> it does something weird to the extradata here (I hate life) [03:11:10 CEST] <Daemon404> which is Most Correct [03:13:18 CEST] <wm4> crystalhd.c has some weird code to "backup" the extradata [03:13:25 CEST] <wm4> I guess I need this too [03:13:40 CEST] <baptiste> yeah that messing with AVStream avctx was always weird [03:13:43 CEST] <nevcairiel> it does this because of the annexb converter, which converts the extradata [03:13:53 CEST] <wm4> nevcairiel: I know, but why does it matter [03:14:02 CEST] <wm4> if the decoder context is really a copy... [03:14:03 CEST] <wm4> oh wait [03:14:06 CEST] <nevcairiel> but didnt that qsv guy add a parameter to the converter to not process the extradata [03:14:10 CEST] <wm4> maybe it's libavformat/utils.c? [03:14:30 CEST] Action: Daemon404 popcorn.h264 [03:14:40 CEST] <wm4> doesn't make sense either [03:14:50 CEST] <wm4> because forced codecs don't influence libavformat [03:15:23 CEST] <baptiste> all right guys, have a good one, good luck with your decoder, wm4 [03:15:56 CEST] <nevcairiel> ffmpeg.c definitely copies the input context [03:16:14 CEST] <nevcairiel> the problem is that find_stream_info would already invoke all the code and then covnert the extradata [03:16:22 CEST] <nevcairiel> so when the real decoder is opened, it will never see the original [03:18:03 CEST] <wm4> ok avformat_find_stream_info is opening this decoder [03:18:13 CEST] <wm4> I don't get why [03:18:34 CEST] <wm4> maye this AVOption shit magically causes it (instead of only being interpreted by ffmpeg.c)? [03:19:27 CEST] <nevcairiel> ffmpeg.c overrides the decoder choices before calling that function [03:20:25 CEST] <nevcairiel> hm or not [03:20:28 CEST] <nevcairiel> no idea how it would [03:20:32 CEST] <nevcairiel> those dont have a codec id [03:22:44 CEST] <nevcairiel> oh there it is [03:22:52 CEST] <nevcairiel> yes it can override the codecs before running that function [03:23:01 CEST] <nevcairiel> but its a bit crude, only one per codec type [03:23:06 CEST] <nevcairiel> ie. one video codec [03:23:09 CEST] <nevcairiel> not per-stream [03:23:22 CEST] <wm4> I bet it's a ffmpeg "improvement" [03:23:32 CEST] <wm4> it didn't happen in Libav back then [03:23:42 CEST] <wm4> though it the end it doesn't matter too much [03:23:59 CEST] <wm4> just that you don't really want to invoke the hw decoder to "analyze" your streams [03:24:09 CEST] <wm4> what if they're e.g. using an unsupported profile [03:24:11 CEST] <nevcairiel> i suppose its generally not too bad that it actually probes with the codec you want [03:42:07 CEST] <wm4> I wonder if I should send my shitty mmal patches for review, or if I should just push them [03:53:38 CEST] <atomnuker> wm4: send them in to the ML and wait a few days before merging them if there are no problems [05:05:06 CEST] <philipl> wm4: Oh man, that backup extradata shit. [09:54:02 CEST] <cone-692> ffmpeg 03Ludmila Glinskih 07master:8ec89681af26: tests/api/api-h264-test: structure changes to avoid duplicate code [10:15:08 CEST] <michaelni> kierank, are the api-band/seek-test ready to be comited or still need a review or changes ? i think the last patch revissions have no replies on the ML [11:04:54 CEST] <cone-692> ffmpeg 03Carl Eugen Hoyos 07master:176698260ca7: configure: mpegvideo depends on mpeg_er. [12:12:24 CEST] <cone-692> ffmpeg 03Carl Eugen Hoyos 07master:7e9cd9962709: lavc: The h263 encoder (also) depends on h263data.o [13:23:44 CEST] <BBB> JEEB: do you think youll have time to look at the #libav logs? [13:26:51 CEST] <cone-692> ffmpeg 03Michael Niedermayer 07master:c382d9e8cbee: swscale: Add sws_alloc_set_opts() [13:26:52 CEST] <cone-692> ffmpeg 03Michael Niedermayer 07master:d0e0757e9a96: swscale: Implement alphablendaway for planar 4:4:4 formats [13:26:53 CEST] <cone-692> ffmpeg 03Michael Niedermayer 07master:41e733c1ef20: avfilter/graphparser: Do not ignore scale_sws_opts if args == NULL [13:26:54 CEST] <cone-692> ffmpeg 03Michael Niedermayer 07master:165fb7eba80c: cmdutils: Export all sws options using a AVDictionary like the other subsystems do [13:26:55 CEST] <cone-692> ffmpeg 03Michael Niedermayer 07master:e755954a84c9: ffplay: pass all sws options to the filter graph [13:38:10 CEST] <wm4> BBB: what are you looking for? (not sure if I have complete logs myself) [13:42:52 CEST] <BBB> #libav logs from as early as possible (probably march 2011) to now [13:45:13 CEST] <wm4> mine definitely don't go that far back.. maybe half-way [14:11:56 CEST] <BBB> wm4: anything is better than nothing, how far back do yours go? [14:12:47 CEST] <JEEB> BBB: I did work until late and then I've been on the move this whole day in southwest finland [14:12:58 CEST] <JEEB> so maybe later but haven't had any time so far [14:13:11 CEST] <BBB> JEEB: thanks! [14:25:50 CEST] <BtbN> philipl, yes, i told him i don't have any compatible hardware. [16:31:18 CEST] <cone-692> ffmpeg 03Michael Niedermayer 07master:d3d776ccf94c: avfilter/vf_scale: apply generic options after flags. [16:31:19 CEST] <cone-692> ffmpeg 03Michael Niedermayer 07master:6dbaeed6b7b7: ffmpeg: switch swscale option handling to AVDictionary similar to what the other subsystems use [16:31:20 CEST] <cone-692> ffmpeg 03Michael Niedermayer 07master:408c9cf0e21d: cmdutils: Fix overriding flags on the command line. [17:05:34 CEST] <cone-692> ffmpeg 03Michael Niedermayer 07master:5edab1d207d2: cmdutils: remove sws_opts usage, simplify code [17:14:51 CEST] <philipl> BtbN: nvenc appears to support temporal layers, but requires the app to specify which layer each frame will go into. [17:43:27 CEST] <BtbN> philipl, hm, that'd require quite a bit of refactoring. And i'm not sure if it's worth it. If I understand that feature right, all it does is make it possible to play streams at a lower framerate on machines too slow for the real one? [17:43:34 CEST] <BtbN> Seems like an odd hack to me [17:49:15 CEST] <philipl> BtbN: Yeah. It would require a lot of logic in our code to control which frames go in which layer [17:50:12 CEST] <philipl> I suppose it might be used for slow-mo sections in a video too? (Hi ubitux) [17:50:37 CEST] <philipl> This Turkish guy seems to think it will be important for broadcasters sending 120fps streams to 'old' 60fps-only TVs [17:51:04 CEST] <BtbN> I highly doubt that. [17:51:19 CEST] <JEEB> lol [18:38:38 CEST] <philipl> BtbN: I am also skeptical. [19:02:41 CEST] <BBB> so & mr filter experts. if I asked you about the ten most exciting audio and video filters& which ones would you claim they are? [19:03:34 CEST] <wm4> svp4lyfe [19:05:23 CEST] <BBB> ? [19:06:48 CEST] <wm4> motion interpolation seems to be one of the most requested features [19:06:56 CEST] <wm4> although I don't quite know why [19:07:00 CEST] <wm4> it adds terrible artifacts [19:15:17 CEST] <Compn> BBB : recoloring filter and the one that can edit photos and recombine them i forgot its name right now. [19:15:53 CEST] <wm4> all of the postproc filters! [19:16:25 CEST] <Compn> BBB : for audio, i'd like to see karaoke and reversekaraoke , to isolate dialog or to exclude dialog on center [19:16:50 CEST] <BBB> but which ones are the most exciting filters that we already have? [19:18:21 CEST] <Compn> everyone says yadif deinterlacer [19:28:47 CEST] <ubitux> BBB: depends [19:28:55 CEST] <ubitux> i like lut3d related filters and ebur128 :D [19:29:03 CEST] <ubitux> but obviously i'm biased [19:29:26 CEST] <wm4> I bet most low-profile libavfilter uses are for vf_yadif [19:29:28 CEST] <ubitux> palette stuff maybe too [19:29:32 CEST] <wm4> ebur might be used a lot too [19:29:39 CEST] <wm4> (from my impressions) [19:30:00 CEST] <ubitux> BBB: but to be honest the main drag in writing new filters currently is the inability to keep a lot of context [19:30:04 CEST] <ubitux> or said differently, no seeking [19:30:15 CEST] <ubitux> you see that in thumbnail filter typically [19:30:28 CEST] <ubitux> the filter is going to pick just one frame out of N [19:30:49 CEST] <ubitux> technically it doesn't need to keep them all in memory if it could query back one [19:30:56 CEST] <ubitux> (it based its selection on histograms) [19:31:08 CEST] <ubitux> but since filters are stream based, it has to cache them all [19:32:03 CEST] <wm4> seeking really wouldn't fit in well libavfilter's model [19:32:14 CEST] <ubitux> maybe [19:32:24 CEST] <wm4> maybe a more general filter model (think dshow/gstreamer) would be more appropriate [19:32:36 CEST] <wm4> but it'd end up with messing it into libavfilter, and the result would be terrible [19:32:51 CEST] <ubitux> well technically the seeking wouldn't be in lavfi [19:33:01 CEST] <ubitux> lavfi needs a model to request a frame to the user [19:33:11 CEST] <BBB> so yadif and ebur [19:33:13 CEST] <BBB> thats it [19:33:28 CEST] <ubitux> BBB: well, we have many cool filters [19:33:41 CEST] <BBB> tell me a few cool ones that you think are particularly useful [19:33:54 CEST] <ubitux> any color filter [19:34:11 CEST] <ubitux> hue, eq, color*, lut, lut3d/haldclut, ... [19:34:32 CEST] <ubitux> palettegen/paletteuse for hq gif [19:34:40 CEST] <BBB> hqdn3d? [19:34:45 CEST] <ubitux> hqx/xbr for scaling pixel based material [19:34:49 CEST] <Compn> dont bring that up around ubitux :P [19:34:49 CEST] <BBB> or, whats the best denoise filter? [19:34:54 CEST] <Compn> er around wm4 [19:34:59 CEST] <ubitux> we have various denoisers [19:35:01 CEST] Action: Compn confusing things up [19:35:20 CEST] <ubitux> owdenoise, dctdnoiz, fftfilt maybe [19:35:28 CEST] <BBB> I know we have 20 [19:35:31 CEST] <BBB> which is the best? [19:35:34 CEST] <ubitux> try it [19:35:38 CEST] <BBB> ... [19:35:40 CEST] <ubitux> i'm currently writing another one [19:35:44 CEST] <BBB> which one do we recommend to novice users? [19:35:49 CEST] <BBB> the ones without eyes [19:36:05 CEST] <ubitux> i don't recommend any because i don't know which is the best [19:36:09 CEST] <Compn> hqdn3d is cheap [19:36:14 CEST] <Compn> owdenoise is slower iirc [19:36:25 CEST] <Compn> which usually means better [19:36:33 CEST] <Compn> sorry i have also not tested these in years [19:36:34 CEST] <ubitux> BBB: fieldmatch/decimate or pullup are used quite a bit [19:36:39 CEST] <ubitux> (unrelated to denoising) [19:36:56 CEST] <ubitux> testsrc is used a lot for testing ;) [19:37:32 CEST] <ubitux> the usual scale, drawtext, crop filters are used a lot too [19:37:42 CEST] <ubitux> ass/subtitles filter for burning subtitles too [19:38:06 CEST] <ubitux> you can add pad and overlay filter in the scale/drawtext/crop list [19:39:32 CEST] <ubitux> ah, and [t]blend can be very useful [19:39:47 CEST] <ubitux> anyway, i'll end up listing them all [19:40:27 CEST] <nevcairiel> the only one i have ever used is yadif because deint is mandatory with todays displays [19:40:34 CEST] <BBB> ok thats better [19:40:38 CEST] <BBB> so what about audio filters? [19:40:45 CEST] <BBB> give me 5 awesome audio filters [19:40:48 CEST] <BBB> I already have ebur128 [19:41:26 CEST] <nevcairiel> biquad is pretty powerful, but you need a degree in audio dsp to figure out to use it properly :) [19:43:31 CEST] <ubitux> BBB: resampling obviously, pan/amerge filter to play with channels, aevalsrc for synth (similar to geq video one) or sine [19:44:02 CEST] <ubitux> i often use asplit when i need to mix it with showspectrum/showwaves/showcqt [19:44:58 CEST] <ubitux> BBB: http://trac.ffmpeg.org/wiki/FancyFilteringExamples [19:45:49 CEST] <ubitux> ffplay -f lavfi life=s=300x200:mold=10:r=60:ratio=0.1:death_color=#C83232:life_color=#00ff00,xbr=3 [19:45:50 CEST] <ubitux> :D [19:46:04 CEST] <BBB> ok that should do [19:46:27 CEST] <BBB> most awesome codecs of the past 5 years? I selected prores, vp9, h264 high bitdepth, hevc, g2m, jpeg2k [19:46:34 CEST] <ubitux> gif [19:46:39 CEST] <wm4> ubitux: it died atfer a few seconds [19:46:41 CEST] <BBB> and for audio wma lossless and atrac3+ [19:46:52 CEST] <ubitux> wm4: it stabilized* yeag [19:51:05 CEST] <ubitux> BBB: didn't you forget opus? [19:51:15 CEST] <BBB> probably yes [19:51:32 CEST] <ubitux> ffv1 got some attention recently too [19:53:41 CEST] <BBB> well ffv1 is like gif [19:53:46 CEST] <BBB> it exists [19:53:48 CEST] <BBB> we fixed some stuff [19:53:50 CEST] <BBB> yay [19:53:52 CEST] <BBB> next [19:55:35 CEST] <ubitux> it was improvements more than fixing [19:55:40 CEST] <ubitux> (for ffv1) [19:55:53 CEST] <ubitux> also standardization process [19:56:04 CEST] <BBB> ok, ffv1.N? [19:56:13 CEST] <BBB> 3? [19:56:15 CEST] <BBB> 4? [19:56:20 CEST] <ubitux> 1.3 or 1.4, dericed or michaelni should know better [19:57:16 CEST] <ubitux> in the past 5 years i think we saw the rise (and fall?) of utvideo? [19:57:25 CEST] Action: ubitux tickles Daemon404 [19:58:28 CEST] <BBB> 1.3 I guess [19:58:31 CEST] <atomnuker> how is atrac3+ awesome? [19:58:34 CEST] <BBB> changelog mentions only 1.3 [20:02:58 CEST] <durandal_1707> Nobody tested atadenoise, deband, dynaudnorm, astats, and afade [20:03:30 CEST] <durandal_1707> afade is used a lot when googling [20:04:15 CEST] <ubitux> ah yeah, fade filters [20:04:22 CEST] <ubitux> ted uses fade filters typically [20:05:08 CEST] <durandal_1707> and do not forget compand [20:05:26 CEST] <ubitux> atempo is quite nice btw [20:05:47 CEST] <ubitux> but again we're going to end up listing them all [20:06:33 CEST] <durandal_1707> noise filter is also useful for testing [20:07:06 CEST] <durandal_1707> karaoke can be done with pan [20:07:20 CEST] <ubitux> (and ass filter @_@) [20:07:49 CEST] <Daemon404> [18:57] <@ubitux> in the past 5 years i think we saw the rise (and fall?) of utvideo? [20:07:52 CEST] <Daemon404> [18:57] * ubitux tickles Daemon404 [20:07:54 CEST] <Daemon404> fall yes [20:07:59 CEST] <Daemon404> so much so that nobody has garassed me to add 10bit support [20:08:04 CEST] <Daemon404> while upstream has had it for like 1-2 years [20:08:13 CEST] <Daemon404> but... eh [20:08:25 CEST] <Daemon404> i think it is still widely used in anime land [20:08:33 CEST] <Daemon404> i dont know of anything replacing it [20:08:39 CEST] <Daemon404> /storytime [20:09:06 CEST] <ubitux> i guess huffyuv with the support of the new pix fmt, or ffv1 could be a good replacement [20:09:26 CEST] <JEEB> I think Ut Video might actually be more used in video editing than animoo world [20:09:29 CEST] <Daemon404> iirc the reason people used utvideo over huffy was tiled threads [20:09:31 CEST] <Daemon404> er, striped. [20:09:40 CEST] <JEEB> because the damn thing has plugins for every damn media framework [20:09:48 CEST] <JEEB> VFW, QT, MF, DS [20:10:14 CEST] <Daemon404> >implying anything uses MF [20:10:34 CEST] <JEEB> indeed [20:10:40 CEST] <JEEB> but VFW and QT is already a lot [20:10:42 CEST] <Daemon404> clearly it needs gst. [20:10:50 CEST] <JEEB> gst has it through lavc [20:10:59 CEST] <Daemon404> lavc doesnt have 10bit [20:11:10 CEST] <JEEB> very few are using that it seems [20:11:22 CEST] <JEEB> although it is called "Ut Video Pro" [20:11:24 CEST] <JEEB> or so [20:11:26 CEST] <Daemon404> the only people doing 10biy lossless i know, are using FFV1. [20:11:33 CEST] <JEEB> so I'd see some corporate'y folk using it [20:11:35 CEST] <JEEB> just for the name [20:12:48 CEST] <ubitux> huffyuv supports > 8bit now [20:13:08 CEST] <Daemon404> but not low-latency threading (tiled or striped) [20:13:13 CEST] <Daemon404> which what ut vidoe was aimed at [20:13:15 CEST] <Daemon404> for NLE [20:14:03 CEST] <ubitux> ok [20:26:41 CEST] <jamrial> ubitux, BBB: regarding fancy audio filters, someone wrote this aevalsrc example some time ago http://pastebin.com/XzfPqWcG [20:29:20 CEST] <ubitux> i yeah i remember; it was a port [20:29:46 CEST] <ubitux> ffplay -f lavfi ... [20:30:03 CEST] <ubitux> it's pretty cool [20:31:33 CEST] <wm4> I only see relatively inelegant hacks [20:31:38 CEST] <wm4> that would be cool if done properly [20:31:45 CEST] <wm4> *nag nag* [20:49:14 CEST] <kierank> durandal_1707: ping [20:50:42 CEST] <durandal_1707> kierank: pong [20:52:52 CEST] <kierank> durandal_1707: do you remember why the numbers in smptebars don't match [20:52:55 CEST] <kierank> like for example blue [20:53:43 CEST] <durandal_1707> perhaps colorspace conversion is done? [20:54:03 CEST] <durandal_1707> what value blue should be? [20:54:15 CEST] <wm4> wasn't thre something about this being wrong because it outputs rgb instead of yuv? [20:54:40 CEST] <durandal_1707> that was, no more true [20:54:47 CEST] <kierank> durandal_1707: in the code itself there are two different values [20:55:35 CEST] <wm4> does this code set the output colorspace? [20:56:03 CEST] <wm4> av_frame_set_colorspace(picref, AVCOL_SPC_BT709); [20:56:51 CEST] <wm4> libavfilter has no proper concept of colorspaces, so maybe the AVFrame-based passing of it somehow fails at some point [21:01:43 CEST] <durandal_1707> kierank: one is 75% blue [21:03:27 CEST] <kierank> 838 static const uint8_t blue[4] = { 32, 240, 118, 255 }; [21:03:34 CEST] <kierank> the spec doesn't use those numbers [21:04:01 CEST] <kierank> oh i see [21:04:17 CEST] <kierank> ignore that then [21:04:21 CEST] <kierank> but there's still a bug i need to find [21:04:29 CEST] <kierank> will have to do it when i have access to scope [21:05:52 CEST] <durandal_1707> what scope you want to use? [21:06:14 CEST] <kierank> I have a vectorscope (sd only) at work [21:06:23 CEST] <kierank> and dericed said hd fails on his scope too [21:13:41 CEST] <durandal_1707> you mean pure blue fail or everything is shifted? [21:14:44 CEST] <durandal_1707> smptebars and smptehdbars have different colorspace set [21:16:44 CEST] <kierank> everything fails [21:17:00 CEST] <kierank> it shouldn't matter because the scope is yuv all the way [21:36:34 CEST] <kierank> durandal_170: so I think smptebars should all be 75% [21:36:38 CEST] <kierank> that might be why it fails [22:02:54 CEST] <cone-557> ffmpeg 03Andreas Cadhalpun 07master:2e9c8be8342c: avcodec: add missing FF_API_CODEC_ID guard [22:02:55 CEST] <cone-557> ffmpeg 03Andreas Cadhalpun 07master:8bd74aafe85c: avfilter: remove obsolete function declarations [22:02:56 CEST] <cone-557> ffmpeg 03Andreas Cadhalpun 07master:9126ae4b6ba3: use avfilter_pad_get_{type,name} accessor functions [22:02:57 CEST] <cone-557> ffmpeg 03Andreas Cadhalpun 07master:e66a43f69455: graphdump: include internal.h for AVFilterPad [22:06:52 CEST] <philipl> I've got some wmv3 files here that are reporting '-99' as their profile numeric value. [22:07:09 CEST] <philipl> That's, obviously, causing the vdpau profile verification to fail. but the files play fine [22:12:20 CEST] <durandal_170> kierank: do you have 8bit yuv file with correct colors? [22:16:20 CEST] <durandal_170> also do you mean both smptehdbars and smptebars are wrong? [22:36:50 CEST] <nevcairiel> -99 is the value for unknown profile phh [22:36:56 CEST] <nevcairiel> philipl: [22:37:01 CEST] <philipl> EH. [22:37:15 CEST] <philipl> Yet, mediainfo accurately reports the profile [22:37:40 CEST] <philipl> So we're ballsing that up [22:37:59 CEST] <nevcairiel> profiles are often not viewed as crucial data and more informative [22:38:07 CEST] <nevcairiel> so not every codec sets it very reliably [22:38:20 CEST] <philipl> No doubt, but at least one and possibly two problems here. [22:38:37 CEST] <philipl> the vdpau init code tries to map report avctx->profile to known supported profiles on the vdpau side [22:38:51 CEST] <philipl> The vc1dev code appears to check profile values [22:40:05 CEST] <philipl> So, where does avctx->profile get set? [22:40:26 CEST] <philipl> In this particular case, the profile is read and stored in the private vc1 context and that's how the internal decoder decisions are made [22:40:33 CEST] <philipl> Is avctx->profile from the demuxer? [22:41:15 CEST] <philipl> Ok, so the bug is vc1dec doesn't set avctx->profile [22:41:55 CEST] <nevcairiel> i think it does [22:42:14 CEST] <nevcairiel> but maybe not in the wmv3 case [22:42:21 CEST] <philipl> Not in any case. [22:42:31 CEST] <nevcairiel> avctx->profile = v->profile; [22:42:34 CEST] <nevcairiel> seems to =p [22:42:37 CEST] <philipl> hrm [22:43:16 CEST] <philipl> Certainly one of my test files is wmv [22:43:20 CEST] <philipl> one is m2ts [22:43:22 CEST] <philipl> both don't work [22:43:42 CEST] <philipl> the m2ts one is a vc-1 bluray extract [22:43:45 CEST] <philipl> so that's not wmv3 for sure [22:44:49 CEST] <nevcairiel> i dont even do profile checks for vc1, its universally advanced profile really =p [22:44:56 CEST] <nevcairiel> only have to exclude wmv3 complex [22:46:46 CEST] <philipl> and yet here we are. [22:49:17 CEST] <philipl> Looks the vdpau init code runs before the profile is extracted from the bitstream [22:54:19 CEST] <ubitux> who is rtogni? [22:56:07 CEST] <iive> Roberto Togni? [22:56:34 CEST] <iive> rxt [22:56:48 CEST] <ubitux> he seemed to have replaced avcodec_frame_alloc() with av_frame_alloc() in mplayer just now [22:57:01 CEST] <ubitux> but... someone probably wants to look deeper here [22:57:44 CEST] <ubitux> because avcodec_alloc_frame() needs to be freed with avcodec_free_frame(), and av_frame_alloc() with av_frame_free() [22:57:48 CEST] <wm4> this stuff can be pretty tricky, although refcount not being on by default probably helps compatibility for stuff like mplayer here [22:57:56 CEST] <ubitux> iirc they're not exactly compatible regarding refcounting [22:58:18 CEST] <iive> ubitux: write and ask him. [22:58:21 CEST] <ubitux> well they're probably going to have some surprises anyway [22:58:34 CEST] <ubitux> iive: no i don't really care, i don't use mplayer for years now [22:58:36 CEST] <philipl> wm4: Where does the hwaccel->init() get called in mpv? I'm struggling to find it [22:58:48 CEST] <ubitux> it just passed in my mbox and i was a bit concerned [22:59:12 CEST] <iive> ubitux: so you are still subscribed. [22:59:26 CEST] <iive> just reply to the commit and repeat what you said here. [22:59:27 CEST] <ubitux> iive: yeah, seems so [22:59:36 CEST] <wm4> philipl: vd_lavc_hwdec.init is called in init_avctx [22:59:39 CEST] <Shiz> mplayer still exists? [22:59:45 CEST] <wm4> philipl: before the decoder is created [22:59:49 CEST] <iive> rxt is reasonable guy. [22:59:58 CEST] <philipl> wm4: I'm trying to work out the call chain to the ffmpeg hwaccel->init method [23:00:16 CEST] <philipl> To work out how to reconcile this profile stuff being out of order [23:00:19 CEST] <wm4> philipl: ah... I don't know either without doing some digging [23:00:41 CEST] <wm4> philipl: but it's not called from mpv AFAIK [23:00:45 CEST] <wm4> (or any API user) [23:01:06 CEST] <philipl> Yeah, except I can't see it called in ffmpeg.git either except in end_frame(!) [23:01:26 CEST] <rtogni> avcodec_alloc_frame() is just return av_frame_alloc() (libavcodec/utils.c) [23:01:32 CEST] <wm4> vdpau.c:264: return avctx->hwaccel->init(avctx); [23:01:35 CEST] <wm4> this one? [23:01:48 CEST] <wm4> (264 is a line number) [23:01:52 CEST] <ubitux> oh you're on the channel, my bad [23:01:54 CEST] <rtogni> so if they behaved diffrenetly originally, that code is already broken [23:02:21 CEST] <wm4> I remember when I tried to keep my code compatible to both pre- and post-refcounting [23:02:25 CEST] <wm4> it wasn't pretty [23:03:05 CEST] <wm4> philipl: I guess end_frame is where parsing is done, and the frame just needs to be "rendered"? [23:03:12 CEST] <rtogni> and unless I missed something, they are never freed in mplayer [23:03:21 CEST] <wm4> "is done" as in was done before calling the function [23:08:39 CEST] <philipl> wm4: I guess so [23:08:52 CEST] <philipl> but if it's delayed that long, how can it possible be running before the vc1_decoder_init [23:08:55 CEST] <philipl> Anyway. [23:09:28 CEST] <wm4> that's not possible [23:09:38 CEST] <wm4> unless another decoder was created before it [23:10:28 CEST] <philipl> I'll keeping digging. [23:15:17 CEST] <philipl> Ok. [23:15:33 CEST] <philipl> It's because vc1_decode_init calls ff_get_format very early and that triggers the hwaccel init [23:16:01 CEST] <philipl> That needs to be reversed. [23:16:06 CEST] <wm4> fun [23:18:12 CEST] <philipl> Gawd. [23:44:58 CEST] <philipl> FJKLLKSDFJKL [23:45:20 CEST] <philipl> vc1_decode_init calls msmpeg4_decode_init which calls h263_decode_init, which calls get_format. [23:45:23 CEST] <philipl> ARGH [23:46:13 CEST] <wm4> lol [23:46:28 CEST] <wm4> yeah, that must be part of the mpegvideo mess [23:46:58 CEST] <philipl> quite. [23:47:01 CEST] <philipl> So much pain [23:47:20 CEST] <philipl> And I obviously can't tell if the vc1 specific init stuff must come after that or if I can move it up [23:52:47 CEST] <philipl> Seems to have worked, however. [00:00:00 CEST] --- Sun Aug 9 2015

1 0

ffmpeg.log.20150808
by burek 09 Aug '15

09 Aug '15

[02:08:11 CEST] <DHE> does playing with presets for libx264 affect the quality/bitrate of iframes? (I'm making an iframe-only video) [02:18:08 CEST] <DHE> apparently not, placebo mode has no speed effect... [10:13:17 CEST] <blue112> Hi here. [11:22:27 CEST] <blue112> How hard is it to compile libav with MSVC ? [14:43:03 CEST] <blue112> I've compiled libav with MSVC (--toolchain=msvc). First, I have two types of .a : libavcodec.a and libavcodec.dll.a. Which ones do I need to use when linking? Secondly, when I try to link using MSVC, I have undefined references to, for example, _av_frame_alloc. Why so ? [15:16:58 CEST] <dongs> why does ffmpeg require kernel 2.6.wahtever. [15:17:07 CEST] <dongs> how does a userspace app even begin to need a specific kernel version [15:17:39 CEST] <dongs> it is exactly this kinda shit why people are no longer using linux [15:17:56 CEST] <JEEB> > bcas.tv [15:18:03 CEST] <JEEB> nice domain thar [15:18:19 CEST] <dongs> it has nothign to do with TV or ffmpeg if thats what you're wondering [15:18:56 CEST] <JEEB> I know b-cas at least ;) did some arib b-25 related stuff at one point [15:19:28 CEST] <dongs> right. doens't help my question tho. [15:19:39 CEST] <JEEB> but on a more serious note, not sure if ffmpeg requires anything [15:19:44 CEST] <dongs> it does. [15:19:48 CEST] <dongs> ./ffmpeg [15:19:49 CEST] <dongs> FATAL: kernel too old [15:19:49 CEST] <JEEB> pre-built binaries might [15:19:52 CEST] <JEEB> oh [15:21:04 CEST] <DHE> it's actually more a glibc thing [15:21:22 CEST] <dongs> i thought the shit was static [15:21:35 CEST] <DHE> glibc is still built with certain features, like threading, that may be kernel-specific [15:21:48 CEST] <dongs> kinda like the whole point, so I dont have to deal wiht idiocy of tryin to chase down lunix versions [15:22:02 CEST] <DHE> What are you running this on anyway? 2.4 ? [15:22:26 CEST] <dongs> sure, does it even matter? i dont see how something that reads and writes files and does some junk on them meanwhile would depend on kernel version [15:22:27 CEST] <DHE> I have a static build of ffmpeg that has 2.6.16 as its minimum. that help? [15:22:36 CEST] <dongs> sure [15:22:54 CEST] <dongs> thanks ^_^ [15:22:59 CEST] <DHE> one sec... [15:24:45 CEST] <dongs> DHE thankies [15:25:13 CEST] <dongs> ah, only one problem 64bit [15:25:16 CEST] <dongs> lols. [15:25:48 CEST] <dongs> all my 64bit capable machiens have long been upgraded to windows 10 [15:26:03 CEST] <DHE> ... [15:27:25 CEST] <anshul_> how to select program in ffplay in mpegts with muliple program [15:27:40 CEST] <dongs> jeeb. what did you do with b25 . ffmpeg related? or what [15:30:41 CEST] <JEEB> dongs: just played around as a hobby and had a guy relicense his shit proper oss :) [15:30:50 CEST] <JEEB> guy = marumo [15:31:28 CEST] <dongs> ah that guy [15:31:30 CEST] <dongs> he's a bit of a cunt [15:32:02 CEST] <JEEB> dunno, haven't drunk enough beer with him to know [15:33:00 CEST] <blue112> I've compiled libav with MSVC (--toolchain=msvc). First, I have two types of .a : libavcodec.a and libavcodec.dll.a. Which ones do I need to use when linking? Secondly, when I try to link using MSVC, I have undefined references to, for example, _av_frame_alloc. Why so ? Anyone ? [15:33:05 CEST] <dongs> what would tehre be to relicense? did he rip something from somewhere? [15:33:14 CEST] <dongs> i thought most of his stuff was original work and he could license it as wahtever the fuck he wanted. [15:34:05 CEST] <dongs> i dont really like his coding style tho of that weird pseudoc++-in-c [15:38:19 CEST] <dongs> well fuck in 20mins i wont need ffmpeg for what i was going to do anyway so i might as well just go wash dishes instead of trying to figure out how to compile this stuff [15:38:33 CEST] <dongs> bbiab [15:43:38 CEST] <anshul_> Does ffplay support multiprogram streams [18:01:08 CEST] <kagami_> Hi guys. Could you please explain, is it safe to cut&concat two parts of the same video if cut ranges are not integral? Say I want to reencode 2.5 seconds of video from 00:04.5 to 00:07 in two parts, and then glue them together. What's the best variant: 00:04.5÷00:05.5 + 00:05.5÷00:07 or 00:04.5÷00:06 + 00:06÷00:07 ? [18:05:56 CEST] <c_14> If you're reencoding it shouldn't matter. [18:07:58 CEST] <kagami_> Is it because new frames will be created and the previous frame boundaries don't matter? [18:08:55 CEST] <c_14> If you're reencoding, all cuts ffmpeg makes are frame-perfect. It'll create a new gop for them. [18:09:24 CEST] <kagami_> Get it, thanks. [21:34:54 CEST] <Pangas> Hello! [21:35:07 CEST] <Pangas> Problem i n FFMPEG stuream. [21:35:14 CEST] <Pangas> *in [21:35:26 CEST] <Pangas> *stream [21:40:26 CEST] <Pangas> Hello! [21:43:54 CEST] <Pangas> ffmpeg: relocation error: ffmpeg: symbol av_dict_set_int, version LIBAVUTIL_54 not defined in file libavutil.so.54 with link time reference [21:45:07 CEST] <Pangas> I'll have to recompile the library? [21:53:17 CEST] <Pangas> Hello! [22:15:14 CEST] <Pangas> I'am back. [23:23:22 CEST] <kyleogrg> I'm a bit new to this. Is this a script that will build ffmpeg for me? https://ffmpeg.zeranoe.com/blog/?p=414#more-414 [00:00:00 CEST] --- Sun Aug 9 2015

1 0

ffmpeg-devel.log.20150807
by burek 08 Aug '15

08 Aug '15

[00:00:25 CEST] <debianuser> Yeah, but it looks like they haven't thought it would cause so much noise. They're just kind of friends with Pocket developer: http://www.planet-libre.org/?post_id=18514 - "we've know Nate for a very long time". And they wanted to deliver a feature they thought to be useful... [01:06:47 CEST] <haasn> debianuser: most of the concerns would be placated by making the server free and open source, and making it so you can self-host your own version [01:06:50 CEST] <haasn> (same for sync) [03:31:59 CEST] <cone-384> ffmpeg 03Michael Niedermayer 07master:bee2e702ccd8: tests/fate/mp3: increase mp3-float-extra_overread FUZZ for ppc64be-RHEL7.0-gcc-4.8.2-ibmcrl to 23 from 20 [04:43:49 CEST] <haasn> another silly thing about the whole WebP situation is the fact that WebM exploded onto the internet when it came out, and how every browser has support for it. There's literally no reason WebP couldn't do the same, if it provides tangible benefits over JPEG (which it does) [05:10:08 CEST] <cone-384> ffmpeg 03James Almer 07master:9c0407e8563f: x86/sbrdsp: remove an unnecessary mova in sbr_autocorrelate [06:05:08 CEST] <doublebackslash> hey, got a quick question on. Is the use of alloca acceptable or would it not compile / break in some environments? [06:06:26 CEST] <doublebackslash> I'm just using it for some small pointer arrays in an audio filter. The thinking is that there is no need to invoke malloc for such small amounts of memory but I'm not sure if that is acceptable in mainline [06:13:30 CEST] <doublebackslash> not sure if quiet this time of night or barking up the wrong tree... [06:16:30 CEST] <c_14> doublebackslash: probably just quiet. wait around or ask on the ml [06:17:52 CEST] <doublebackslash> fair enough. I'll switch to av_malloc for now or persist the alloctions between invocations via the priv struct [06:18:08 CEST] <doublebackslash> can't be worse than breakign a build :p [06:27:57 CEST] <doublebackslash> okay, this one is a bit more ffmpeg related than memory. Taking a cue from amix I'm using samples as a PTS. It works for me but I'm worried I might be missing a trick. Any fancier / more correct way to handle this? [06:31:49 CEST] <rcombs> I think alloca is usually frowned upon [06:32:10 CEST] <rcombs> but I'm not the arbiter of ffmpeg memory allocation calls [06:32:53 CEST] <doublebackslash> when in doubt do as the Romans do [06:36:44 CEST] <rcombs> (the romans appear not to use alloca) [07:42:41 CEST] <durandal_1707> doublebackslash: what filter does? [09:25:56 CEST] <cone-790> ffmpeg 03Rostislav Pehlivanov 07master:c47c781e83fd: aacenc: Move local encoder specific tables to a separate file [09:28:18 CEST] <cone-790> ffmpeg 03Alexandra Hájková 07master:944f60866f50: asfdec: read values properly [09:28:19 CEST] <cone-790> ffmpeg 03Luca Barbato 07master:e5997152f54f: asf: Use time_t where needed [09:28:20 CEST] <cone-790> ffmpeg 03Hendrik Leppkes 07master:b54cf4b8863d: Merge commit '944f60866f507e3c0850ae9c2f30dac1da54587c' [09:28:21 CEST] <cone-790> ffmpeg 03Hendrik Leppkes 07master:3d2d6728288f: Merge commit 'e5997152f54f790229c99f237f8eb6b5b1ee683a' [09:56:03 CEST] <cone-790> ffmpeg 03Jake Sebastian-Jones 07master:9469370fb326: h264: Use AVERROR return codes instead of -1 [09:56:04 CEST] <cone-790> ffmpeg 03Hendrik Leppkes 07master:8015150f4387: Merge commit '9469370fb32679352e66826daf77bdd2e6f067b5' [16:02:44 CEST] <ubitux> hum, avio_close_dyn_buf doesn't allow a call with a NULL pbuf so that we don't have to get the pointer and free it afterward? [16:40:50 CEST] <BBB> does anyone have chat logs from libav-devel from the past few years? [16:41:22 CEST] <nevcairiel> technically yes, i guess, but i would have to build a script to extract them from the database they are stored in [16:41:47 CEST] <nevcairiel> my irc client doesnt forget [16:41:48 CEST] <nevcairiel> :d [16:42:57 CEST] <ubitux> BBB: i have 2012 to beginning 2015 in irssi format [16:43:08 CEST] <ubitux> rest of 2015 in weechat format [16:43:46 CEST] <ubitux> with some random holes because of network troubles & stuff i guess [16:45:30 CEST] <kierank> I have logs too for a similar perioid [16:46:01 CEST] <BBB> does anyone have them from 2011? [16:46:05 CEST] <Gramner> since 2011-03-22 [16:46:39 CEST] <BBB> thats probably as early as exists [16:46:43 CEST] <BBB> when did the channel start? [16:48:09 CEST] <cone-790> ffmpeg 03Paul B Mahol 07master:2bdd026b264e: avfilter/avf_avectorscope: stop making output fully transparent [16:48:23 CEST] <Gramner> Registered : Mar 13 16:16:37 2011 [16:48:55 CEST] <BBB> cool, thats about as good as itll get then [17:12:18 CEST] <Daemon404> i was gonna ask why nevcairiel hasnt merged libav recently... but then i saw libav has had one commit in liek 2 months [17:12:56 CEST] <Daemon404> ... nope firefox just autocomplete teh wronh url [17:13:10 CEST] Action: Daemon404 asks nevcairiel about merges [17:13:15 CEST] <BBB> lol [17:15:27 CEST] <ubitux> Daemon404: well, only one commit, no? [17:15:59 CEST] <ubitux> which was actually fixed in the merge commit itself [17:16:04 CEST] <Daemon404> hmm right [17:16:04 CEST] <Daemon404> ok [17:16:17 CEST] <Daemon404> [16:15] <@ubitux> which was actually fixed in the merge commit itself <-- nooooooooo dont start this again [17:16:39 CEST] <ubitux> well the commit was wrong so it had to be fixed [17:16:43 CEST] <ubitux> the merge commit is here for that [17:16:54 CEST] <ubitux> it's more like partially merged [17:16:56 CEST] <ubitux> instead of "fixed" [17:16:59 CEST] <Daemon404> its absolutely infuriating to try and bisect and find the change *in* a merge commit [17:17:08 CEST] <ubitux> git show 8015150f43875531f05e31ac5021ea676fb20e40 [17:17:36 CEST] <ubitux> git log ..libav/master --oneline to see how much difference with libav [17:17:56 CEST] <Daemon404> heh [17:25:43 CEST] <nevcairiel> Daemon404: wah, i did merge this morning [17:25:53 CEST] <Daemon404> i was mistaken [17:26:03 CEST] <Gramner> would using cherry-pick/rebase instead of merge be an option? [17:26:10 CEST] <Gramner> if you don't like merge commits [17:26:25 CEST] <nevcairiel> nah that would be annoying [17:26:36 CEST] <nevcairiel> merging has the advantage that git tracks for you which changes are not in yet [17:27:03 CEST] <Daemon404> yeah cheryr pick is a bad road [17:29:26 CEST] <BBB> ok I got irc logs for devel channels [17:29:34 CEST] <BBB> does anyone here reside in #libav and #ffmpeg? [17:29:41 CEST] <BBB> (with logs going back to 2010-2011 or so) [17:30:43 CEST] <Daemon404> i only have the devel channels [17:30:46 CEST] <Daemon404> back to 2010/2011 [17:30:53 CEST] <BBB> I already have those [17:30:59 CEST] <Daemon404> i know [17:31:16 CEST] <BBB> maybe I should sit in #libav/#ffmpeg and ask there [17:45:52 CEST] <c_14> BBB: this should have most of the #ffmpeg logs http://ffmpeg.gusari.org/irclogs/ [17:46:20 CEST] <BBB> I think I have that one, its from nov 2011 onwards [17:46:27 CEST] <BBB> Im hoping to get 2010-2011 also, if possible [17:46:42 CEST] <Daemon404> 2010 wouldnt exist for libav [17:47:12 CEST] <BBB> right, thatd (hopefully) be from 2011 (march?) onwards [17:47:55 CEST] <Daemon404> $ head -1 \#libav-devel.log [17:47:56 CEST] <Daemon404> --- Log opened Thu Apr 07 10:41:52 2011 [17:48:06 CEST] <Daemon404> for me [17:48:36 CEST] <BBB> gramner had them starting in march, which seems to be when the channel got registered [17:48:44 CEST] <Daemon404> ah [17:48:46 CEST] <BBB> so I suppose thats the earliest available logs [17:48:54 CEST] <Daemon404> why do you want logs anyway? [17:54:56 CEST] <JEEB> I might have #ffmpeg logs, since I was masochistic enough to stay around [17:55:03 CEST] <JEEB> #libav I often forgot to join [17:56:02 CEST] <BBB> JEEB: would you be willing to share logs with me? or statistics on logs [17:56:12 CEST] <BBB> youre on 24/7 right? [18:00:24 CEST] <drv> BBB: i have #ffmpeg and #ffmpeg-devel from early 2009 on [18:00:25 CEST] <drv> https://drv.nu/irclogs/ [18:00:37 CEST] <BBB> \o/ [18:00:58 CEST] <BBB> now to find #libav logs [18:01:06 CEST] <BBB> JEEB: if you have anything on #libav, thatd be awesome [18:18:03 CEST] <BBB> drv: that goes until may 2014 btw [18:18:14 CEST] <BBB> Ill use the mailinglist for the rest I suppose [18:21:19 CEST] <drv> oh, i have the newer stuff too, just haven't merged the files yet [18:21:23 CEST] <drv> i dropped them in the same dir [18:29:50 CEST] <BBB> drv: ty! [18:29:59 CEST] <BBB> now only to find libav logs [18:30:04 CEST] <BBB> #libav logs, that is [18:31:06 CEST] <JEEB> BBB: I do have some, but they are currently stranded between two different systems and at least three different directories [18:31:17 CEST] <JEEB> so I would most probably be the best of sources [18:31:31 CEST] <BBB> Ill take whatever I can get [18:31:41 CEST] Action: BBB puts on his pretty please face [18:32:54 CEST] <JEEB> I'll look into exact details soon (tm) [18:33:05 CEST] <JEEB> but if I can scrape stuff off I can deliver it [18:35:53 CEST] <BBB> ty! would be very much appreciated [20:12:40 CEST] <c_14> Is there any reason av_freep would segfault when av_free doesn't? The segfault occurs in the call to free() according to the backtrace. [20:13:21 CEST] <rcombs> c_14: forgot a &? [20:13:46 CEST] <c_14> Ah, yep. Thanks. [20:13:47 CEST] <c_14> That was stupid. [20:15:44 CEST] <BBB> did you call it with &? [20:15:44 CEST] <BBB> av_free(ptr) vs. av_freep(&ptr) [20:16:02 CEST] <rcombs> BBB: beat you to it :) [20:16:50 CEST] <BBB> I think my internet is shitty [20:18:45 CEST] <BBB> like, I swear, in my chat window, its like as if I said it first [20:18:59 CEST] <rcombs> then one of us has some significant lag [20:19:21 CEST] <BBB> [2:13pm] <BBB> did you call it with &? [20:19:22 CEST] <BBB> [2:13pm] <BBB> av_free(ptr) vs. av_freep(&ptr) [20:19:22 CEST] <BBB> [2:15pm] <rcombs> c_14: forgot a &? [20:19:22 CEST] <BBB> [2:15pm] <c_14> Ah, yep. Thanks. [20:20:22 CEST] <rcombs> yeah, happens when ~latency~ [20:20:57 CEST] <BBB> probably me [20:20:57 CEST] <BBB> my internet is shit today [20:21:17 CEST] <kurosu> more like the irc server you're on? [20:21:28 CEST] <kurosu> there's a solid 2 minutes between rcombs and you [20:27:09 CEST] <BBB> who knows [21:13:44 CEST] <wm4> remind me, how do I force the video decoder for ffprobe? [21:14:10 CEST] <nevcairiel> -c:v no worky? [21:14:14 CEST] <wm4> no [21:31:35 CEST] <wm4> yeah, seems not possible [23:06:55 CEST] <cone-899> ffmpeg 03Michael Niedermayer 07master:005d0069389a: avcodec/libopenh264enc: Avoid usage of deprecated ff_alloc_packet() [23:06:55 CEST] <cone-899> ffmpeg 03Michael Niedermayer 07master:7d3aa2ca63c2: avutil/float_dsp: Remove use of deprecated av_set_cpu_flags_mask() [23:33:46 CEST] <wm4> trying to use a debugger with ffmpeg is always such a drag [23:34:03 CEST] <wm4> you can't disable optimizing because of some retarded "cute hack" someone made [23:34:15 CEST] <wm4> installing strips by default, even if compiled with -g (????) [23:35:17 CEST] <wm4> and setting "STRIP=" in config.mak somehow segfaults here [23:36:22 CEST] <Shiz> STRIP=echo [23:36:27 CEST] <Shiz> ( V?V) [23:36:31 CEST] <wm4> yes that works [23:36:33 CEST] <wm4> and it's lame [23:36:49 CEST] <jamrial> did you try --disable-stripping during configure? [23:37:02 CEST] <wm4> no, who thinks of this [23:37:19 CEST] <Daemon404> dont forget --optflags=-O0 [23:38:50 CEST] <jamrial> wouldn't -O0 choke with all the stuff that depends on dead code elimination? [23:39:02 CEST] <jamrial> --disable-optimizations sets it at -O1 [23:40:11 CEST] <iive> try -Og [23:40:44 CEST] <iive> i haven't tested it, but somebody should try it :) [23:44:39 CEST] <jamrial> wm4: try running configure with --enable-debug=gdb --disable-optimizations --disable-stripping for a gdb debug build [23:47:13 CEST] <wm4> usually I just add #pragma GCC optimize("O0") [23:47:19 CEST] <wm4> I was annoyed by the crappy defaults [23:47:26 CEST] <wm4> why strip when it's a debug build? [23:47:38 CEST] <wm4> or whatever --enable-debug is supposed to mean [23:50:33 CEST] <BBB> I usually just compile the one file I care about with O0 [23:50:38 CEST] <BBB> the rest stays in O3 [00:00:00 CEST] --- Sat Aug 8 2015

1 0

ffmpeg.log.20150807
by burek 08 Aug '15

08 Aug '15

[00:01:56 CEST] <OstlerDev> Is there something that I can do in that situation c_14 ? [00:02:57 CEST] <c_14> You could use fragmented moov, but most players won't support that [00:03:33 CEST] <c_14> The moov atom is usually written once the entire file has been written out, and usually at the end of the file though it can be moved to the front. [00:04:14 CEST] <OstlerDev> I am currently using ts segments for the conversion: https://github.com/OstlerDev/PopcornTV/blob/master/webserver.js#L704 [00:04:39 CEST] <OstlerDev> However my issue comes when FFMPEG tries to convert a section of the video that has not been downloaded yet, it crashes and ends the conversion [00:05:10 CEST] <OstlerDev> What I am looking for is a way to continue the conversion either from that same spot, add onto the segment file, or to continue attempting a section even after an error rather then crashing [00:05:31 CEST] <OstlerDev> currently I use -re to slow the encoder down to 1 second converted for each second played, but if the file is still not downloading that fast it crashes [00:07:02 CEST] <c_14> Not without modifying the source. [00:10:28 CEST] <OstlerDev> What would I need to do to modify the source to allow something like that? [00:11:25 CEST] <c_14> You'd have to go into the code and find the position where the file open/read fails and then make it retry indefinitely. [00:14:57 CEST] <kyleogrg> in yadif, there is few settings for "mode" [00:15:11 CEST] <kyleogrg> 0 = Output one frame for each frame. [00:15:38 CEST] <kyleogrg> 2 = Same thing, but skips the spatial interlacing check. [00:15:49 CEST] <kyleogrg> What is "the spatial interlacing check"? [00:17:04 CEST] <OstlerDev> c_14 is there a way of resuming with a flag or something? With segmentation (my current method) it overwrites the playlist file. [00:20:08 CEST] <OstlerDev> I am fine to switch to a different output format if that would be needed [00:24:04 CEST] <debianuser> shadowkyogre: (copypaste from #alsa in case it's useful for someone else) -f x11grab -s 1920x1080 -r 60 - that could be a problem. There's a bug (or important feature missing) of ffmpeg having no optimized codepath for x11grab 0RGB to yuv420p color conversion, it uses generic code, which is very slow, 30-40fps max. [00:24:07 CEST] <debianuser> I reported that months ago, even wrote a patch to fix it, but somewhy my patch was still slow (~55 fps instead of 30-40fps without the patch, but still not 120fps as I wanted it to be). It could be faster if someone implemented that color conversion in assembler, but I haven't got it that far. [00:24:10 CEST] <debianuser> If you're not afraid of the dark ritual of building ffmpeg, I can share you my patch. It's far from perfect but I was able to get 50-55 fps with it on my old slow cpu. Or you can try SimpleScreenRecorder. Its streaming features are limited, but it actually implemented color conversion in sse3, that should be fast (i wish someone adopted that SSR code into ffmpeg). [00:30:19 CEST] <shadowkyogre> debianuser: I'd definitely be interested in trying the patch (also going to try simplescreenrecorder too) [00:38:23 CEST] <debianuser> shadowkyogre: http://pastebin.com/ThcNjhVP - that's the patch draft. [00:42:31 CEST] <debianuser> (now looking at it... there's probably a bug there, lines 76-78 should be 8*i+4/5/6, not 8*i+3/4/5) [14:23:32 CEST] <AlexJumper> hello, who can help me with my problem? [14:26:35 CEST] <AlexJumper> i have FFmpeg generated audio stream, FFplay succ read it, but when stream end, FFplay looping last sound packet. How to configure FFplay to autostop, when stream end? [15:03:25 CEST] <ScottSteiner> How can I stream a video file to icecast? I've tried multiple guides but have yet to find one that works [18:00:34 CEST] <edoceo> AlexJumper: ffplay -autoexit my_file.avi [00:00:00 CEST] --- Sat Aug 8 2015

1 0

ffmpeg-devel.log.20150806
by burek 07 Aug '15

07 Aug '15

[01:29:44 CEST] <cone-803> ffmpeg 03Michael Niedermayer 07master:ace837665362: avformat/matroskaenc: Avoid "for (int i" syntax for better compatibility [01:53:26 CEST] <rcombs> what does that actually improve compatibility with [01:54:46 CEST] <kierank> old compilers [02:06:55 CEST] <wm4> (lol) [02:12:59 CEST] <Shiz> oh for crying out [02:33:06 CEST] <BBB> does anyone know if libav logs their irc somewhere? [02:35:20 CEST] <Compn> wow a wild rtogni and i missed him :D [02:43:30 CEST] <philipl> c89 forever! [02:44:25 CEST] <philipl> The Hotel California of programming languages. [02:45:37 CEST] <wm4> I want to see a supported compiler which doesn't do c99 decls [02:45:56 CEST] <philipl> *mumble*dec alpha*mumble*? [02:47:05 CEST] <philipl> michaelni: which build failed without that syntax change? [02:49:00 CEST] <wm4> *drummroll* [02:52:12 CEST] <jamrial> wow, we have fate clients with gcc 3.4 [02:55:12 CEST] <philipl> gcc 2.95 should be good enough for anyone. [02:59:22 CEST] <Shiz> cygwin life [03:04:52 CEST] <philipl> Ironically, gcc 2.95 is about the same age as c99. [03:05:06 CEST] <michaelni> philipl, i just spoted it, i dont know which compilers would have failed. [03:06:16 CEST] <philipl> wouldn't you rather let it be and see who screams? And then tell them to choose from any of the compilers released in the last decade? [03:07:02 CEST] <michaelni> well, i dont want to violate our coding rules to experiment around like this [03:07:15 CEST] <Shiz> 'experiment' [03:07:20 CEST] <Shiz> using 16 year old language features [03:07:39 CEST] <philipl> I believe that's how old the coding rules are too. [03:07:40 CEST] <philipl> But anyway. [03:07:54 CEST] <philipl> That's fair enough. [03:08:10 CEST] <philipl> I agree we should change the rules rather than ignore them. [03:08:17 CEST] <michaelni> yes [03:08:47 CEST] <michaelni> if this is not needed anymore it should be removed fro the rules [03:15:56 CEST] <michaelni> or rather "i dont want to violate our coding rules to experiment around like this in a undeclared fashion. If its intended as a experiment to check if any compilers still have issues then it should be clearly declared to be there for this purpose" [03:42:28 CEST] <BBB> peloverde: team(a)vidtechcon.com doesnt work :( [07:56:07 CEST] <razzledazzle> why is the compiler not generating the ffmpeg binary? Following params have been set, http://pastie.org/private/ss1lsjaujwnkbpj7kvrxw [09:06:11 CEST] <wm4> I sure wish we actually had coding standards [10:10:35 CEST] <razzledazzle> really, what are the requirements for the ffmpeg cli program, it doesn't get built.. [10:15:51 CEST] <nevcairiel> you disable avfilter, that might be related [10:16:41 CEST] <nevcairiel> and depending on what you want the cli to do, you also might need a few more extra filters [10:16:46 CEST] <nevcairiel> at least scale is probably useful [10:17:55 CEST] <razzledazzle> hmm.. I guess I might have to do some more tests, if only there were some message about the prequisites/dependencies [10:19:17 CEST] <razzledazzle> trying for a very minimal executable binary for Android, just for the overlay filter, I'm not sure about the fundamentals :P [10:20:07 CEST] <nevcairiel> just remove the --disable-avfilter, i think configure may automatically select the individual filters that the cli wants [10:22:40 CEST] <razzledazzle> that's neat then [10:23:05 CEST] <razzledazzle> thanks for some input :) [10:26:32 CEST] <razzledazzle> nevcairiel: that worked! appreciate your help! :D [11:08:51 CEST] <BtbN> philipl, according to https://developer.nvidia.com/nvidia-video-codec-sdk a gtx980 should work for hevc encoding [11:09:57 CEST] <cone-384> ffmpeg 03wm4 07master:94c0df79c7e8: lavc: propagate hwaccel errors [11:10:55 CEST] <nevcairiel> BtbN: oddly enough they put encoding into their media functionality before they finished decoding :D [11:11:15 CEST] <nevcairiel> but yeah the 980 supports hevc encoding [11:11:17 CEST] <nevcairiel> but not decoding [11:12:35 CEST] <wm4> hm do we really like the "if ((ret = foo()) < 0) return ret;" idiom? [11:16:01 CEST] <BtbN> nevcairiel, strange [11:17:38 CEST] <ubitux> wm4: up to you [11:21:04 CEST] <nevcairiel> i dont mind that particular structure, as long as careful placement of the braces is observed [11:21:21 CEST] <nevcairiel> personally i probably would use two lines [11:21:50 CEST] <wm4> I normally prefer two lines too [11:22:05 CEST] <wm4> but ffmpeg code generally seems to prefer the idiom [11:33:55 CEST] <ubitux> it really depends on who wrote the code [11:34:50 CEST] <ubitux> see also 2f0f9a87d0e8d27ce6ad5b81134d01b9d2392cd1 :p [11:36:36 CEST] <wm4> yeah I had that too yesterday [11:36:44 CEST] <wm4> I wondered why the fuck my code didn't work [12:04:58 CEST] <durandal_1707> ubitux: are now high freqs ok? [12:57:12 CEST] <cone-384> ffmpeg 03Michael Niedermayer 07master:a368920eefbf: avcodec/options: Silence deprecated warning about coded_frame [12:57:13 CEST] <cone-384> ffmpeg 03Michael Niedermayer 07master:cb5190bc9df3: avcodec/diracdec: Move reference to DiracFrame, avoid use of the deprecated field from AVFrame [15:06:51 CEST] <cone-384> ffmpeg 03Paul B Mahol 07master:40ddbc87c5cd: avfilter/avf_showspectrum: use av_calloc() [15:07:30 CEST] <ubitux> durandal_1707: looking at it [15:17:03 CEST] <ubitux> durandal_1707: green & red reflects the increase & decrease from previous frames? [15:18:40 CEST] <ubitux> what's the logic for the representation of high freqs btw? cropping or padding with zero? [15:19:01 CEST] <ubitux> if you're cropping, maybe a vertical line (or gray rectangle of the unused part) would be welcome [15:19:44 CEST] <ubitux> and magnitude for the first sample (and maybe last) is still wrong [15:20:25 CEST] <ubitux> i got a high freq glitch once though (so not as common as previously) [15:22:51 CEST] <durandal_1707> ubitux: its separate color for each channel [15:23:01 CEST] <ubitux> oh, ok [15:27:44 CEST] <cone-384> ffmpeg 03wm4 07master:8024002d408f: vc1dec: propagate error codes and return meaningful error codes [16:08:14 CEST] <durandal_1707> ubitux: high freqs are not displayed if width is too small [16:08:32 CEST] <ubitux> ok, cropping then, alright [16:09:40 CEST] <durandal_1707> what you mean by magnitude of first sample is wrong? [16:20:08 CEST] <ubitux> durandal_1707: what i told you yesterday; remember the transform is going to transform N samples into N/2+1 complex [16:20:40 CEST] <ubitux> so from a size PoV, that results in N+2 output, which can fit into the source buffer (it's in-place transform) [16:20:48 CEST] <ubitux> so to counter that there is a trick done [16:21:08 CEST] <ubitux> the first complex has actually a complex value assumed to be 0, just like the last one [16:21:29 CEST] <ubitux> as a result, the real part of the last complex sample is stored in place of the complex part of the first sample [16:23:00 CEST] <ubitux> (which *can't* fit into the source buffer, sorry) [16:26:09 CEST] <ubitux> am i clear enough? [16:26:26 CEST] <ubitux> note that other fft filters are actually wrong in that regard too [16:26:41 CEST] <ubitux> i initially added a comment for that in showspectrum but it was dropped [16:26:48 CEST] <ubitux> s/comment/FIXME/ [16:27:13 CEST] <ubitux> we're not giving a good usage example of our api :) [16:28:13 CEST] <ubitux> durandal_1707: btw, if you're interested in learning SIMD (i think i saw you talking about that the other day), you might be interested in ticket #3921 [16:36:32 CEST] <ubitux> durandal_1707: http://pastie.org/10333545 here is an example on how to deal with the MAGNITUDE thing [17:10:59 CEST] <durandal_1707> ubitux: that bug report is too advanced to my skills [17:11:15 CEST] <ubitux> well, you said you wanted to learn [17:13:49 CEST] <philipl> BtbN: for encoding, yes. [17:13:53 CEST] <philipl> Did I ever say otherwise? [17:16:20 CEST] <BtbN> not too sure anymore, i expected it to be the same [17:42:52 CEST] <cone-384> ffmpeg 03Niklesh 07master:2e7a684e7214: movtextdec.c: Add support for font names [18:08:21 CEST] <durandal_1707> ubitux: but in smaller steps like adding simd to blend diff mode [18:46:24 CEST] <haasn> How likely is it for ffmpeg to include AVX512 acceleration in libavcodec, once it gets released (in Skylake Xeon chips)? Also, how likely is it that AVX512 would offer any sort of tangible performance boost? [18:47:11 CEST] <Daemon404> if someone writes it, and it's useful it will be included [18:47:59 CEST] <nevcairiel> i think i heard the resident asm experts say that usefulness is going to be limited [18:51:58 CEST] <kierank> haasn: there isn't much avx2 in libavcodec [18:52:02 CEST] <kierank> let alone avx512 [18:57:15 CEST] <Compn> haasn : more likely if someone else writes it, less likely unless someone donates some brand new cpu+mobo to developers to work on it [18:57:33 CEST] <Compn> cant really write code without the hardware to test and bench. [18:57:56 CEST] <Compn> and yeah avx2 isnt even used much [20:18:51 CEST] <BBB> haasn: codecs like vp9 and hevc will see greats benefits from avx512 [20:19:01 CEST] <BBB> great, I mean, significant, as much as avx2 [20:19:22 CEST] <nevcairiel> all i heard is that avx512 is not a straight evoluition of avx2, but much more specialized [20:19:27 CEST] <BBB> haasn: as for avx2 not being used very much, thats expected; I mean, were an opensource project and most people here simply contribute whats useful for themselves; I have no use for avx2 since I have no avx2 machine [20:19:30 CEST] <nevcairiel> which makes its usefulness kinda limited [20:20:18 CEST] <BBB> but if someone would buy me a new machine and pay my rent, Id be happy to write avx512 or avx2 for libavcodec (hevc or vp9 or whatever) [20:20:38 CEST] <BBB> arent people expecting a new skylake-based macbook pro 15 at the end of this year? [20:20:43 CEST] <BBB> Id love to get one [20:20:46 CEST] <haasn> Interesting [20:21:03 CEST] <kierank> only the xeon skylake's have avx2 [20:21:06 CEST] <kierank> avx512 [20:21:07 CEST] <kierank> * [20:21:08 CEST] <haasn> BBB: The skylake desktop CPUs (i7) etc. don't include AVX512 [20:21:14 CEST] <haasn> what kierank said [20:21:22 CEST] <nevcairiel> which is why avx512 usefulness for decoding is probably limited [20:21:23 CEST] <BBB> oh crap [20:21:24 CEST] <BBB> well [20:21:27 CEST] <nevcairiel> maybe encoders can use it more [20:21:28 CEST] <BBB> then no avx512 from me for a while [20:21:36 CEST] <nevcairiel> which often run on server hardware as well [20:21:38 CEST] <haasn> Aren't Xeons better value than i7s either way? [20:21:50 CEST] <kierank> depends [20:21:53 CEST] <BBB> do xeons fit on laptops? [20:22:00 CEST] <kierank> the e3-xeons are essentially i7's with ECC [20:22:05 CEST] <kierank> and possibly more pcie lanes [20:22:07 CEST] <haasn> kierank: and without the iGPU [20:22:10 CEST] <kierank> yes [20:22:16 CEST] <haasn> for cheaper [20:22:20 CEST] <nevcairiel> they have xeons with gpu [20:22:25 CEST] <kierank> yes but not many [20:22:27 CEST] <nevcairiel> which can be useful if you want to access the transcoder [20:22:56 CEST] <haasn> nevcairiel: from what I heard, it can still only do 8-bit AVC/HEVC/VP9, not 10-bit? [20:23:05 CEST] <haasn> Which limits its usefulness kinda since all mainstream HEVC content is going to be 10 bit pretty much [20:23:15 CEST] <haasn> (And VP9 is easy to decode) [20:24:11 CEST] <BBB> (which hevc content :-p ) [20:25:41 CEST] <haasn> BBB: the japanese UHDTV recordings on nyaa.eu :p [20:25:58 CEST] <haasn> (The ones that are so terrible in quality that x264 would be significantly better) [20:26:06 CEST] <haasn> (At half the bitrate) [20:26:07 CEST] <BBB> did you know theres around 10 vp8 streams on the internetz also? [20:26:11 CEST] <BBB> like, whoa [20:26:12 CEST] <BBB> omg [20:26:59 CEST] <haasn> BBB: On a more serious note, next blu-ray spec uses HEVC and is planned to hit the market around christmas 2015 [20:27:11 CEST] <haasn> (Spec was finalized a month ago or so) [20:27:30 CEST] <haasn> So we will quite likely be seeing some HEVC content pop not too far from now [20:27:38 CEST] <BBB> meanwhile, the world is watching netflix and their shareprice is skyrocketing [20:28:12 CEST] <BBB> I mean, you could say that hevc is being streamed by netflix to samsung tvs [20:28:22 CEST] <BBB> thats actually somewhat modestly meaningful [20:28:28 CEST] <BBB> (although the quality sucks) [20:28:50 CEST] <BBB> sorry, I guess Im being overly negative [20:29:09 CEST] <BBB> Ill let Daemon404 take it from here :-p [20:29:56 CEST] <haasn> I understand your concern, but didn't you just claim that we simply care about what's useful for us? :p [20:30:03 CEST] <haasn> I do not intend to watch netflix at any point in my life [20:30:11 CEST] <haasn> But I fully intend to watch 4K blu-ray as soon as it hits the market [20:30:19 CEST] <BBB> fair point, yes [20:30:21 CEST] <haasn> So I care about HEVC quite some bit more than about netflix's low-bitrate garbage [20:30:51 CEST] <haasn> not saying intel is making a bad choice, just saying that their iGPU's usefulness for *me* is limited :) [20:31:11 CEST] <haasn> Although I did say mainstream HEVC content. I guess that's wrong [20:31:17 CEST] <haasn> Mainstream is youtube and netflix, of course ;) [20:31:44 CEST] <haasn> I meant mainstream more as in I can actually download and watch mainstream movies in HEVC [20:34:42 CEST] <Daemon404> [19:28] <@BBB> thats actually somewhat modestly meaningful [20:34:44 CEST] <Daemon404> you cant [20:34:50 CEST] <Daemon404> it was a deal between samsung and netflix [20:35:00 CEST] <Daemon404> netflix even came out and set it has 0 gains over h264 [20:35:04 CEST] <Daemon404> said* [20:35:11 CEST] <Daemon404> (which is obvious to anyone with a brain cell) [20:35:17 CEST] <Daemon404> the encoder they used, i mean. [20:36:37 CEST] <Daemon404> i am not actually aware of any hevc encoder which beats x264 at bitrates suitable for transparency [20:36:41 CEST] <Daemon404> in terms of grain retention etc [20:36:44 CEST] <BBB> I didnt say it helped [20:36:48 CEST] <BBB> I said they were streaming it [20:36:54 CEST] <BBB> I also didnt say they wanted to stream it [20:36:57 CEST] <Daemon404> to a super tiny amount of people [20:36:59 CEST] <Daemon404> ;) [20:37:00 CEST] <BBB> :-p [20:37:36 CEST] <BBB> you should work at netflix [20:37:43 CEST] <BBB> might actually make their service better [20:37:51 CEST] <Daemon404> i know some smart people there [20:37:58 CEST] <Daemon404> i hear its not so easy [20:38:00 CEST] <BBB> and when did I become a netflix recruiter [20:38:01 CEST] <Daemon404> too big at this point [20:38:02 CEST] <BBB> blegh [20:38:39 CEST] <Daemon404> BBB, youre a poor recruiter then [20:38:52 CEST] <Daemon404> you didnt even say it was a disruptive bleeding edge company [20:38:53 CEST] <Daemon404> or whatever [20:39:08 CEST] <haasn> Daemon404: if you work at netflix, can you please add a feature that lets me download full movies as plain, non-DRM-protected files at blu-ray bitrates without requiring registration, payment or any sort of personally identifying information? [20:39:10 CEST] <haasn> That would be pretty useful [20:39:21 CEST] <Daemon404> i do not work at netflix [20:39:39 CEST] <haasn> if you end up working at netflix* [20:39:52 CEST] <Daemon404> 0% chance of that [20:39:56 CEST] <Daemon404> i would never live in SF. [20:39:58 CEST] <Daemon404> ;) [20:40:37 CEST] <kierank> haasn: hahahahahahahahaha [20:40:44 CEST] <kierank> you miss the entire point of netflix [20:40:56 CEST] <Daemon404> click buttan -> stream convenience [20:40:59 CEST] <Daemon404> nobody cares about dling [20:41:04 CEST] <kierank> or DRM [20:41:18 CEST] <haasn> kierank: I guess I do. I've never understood the point of netflix, it confuses me [20:41:22 CEST] <haasn> Daemon404: but what if I want to rewatch it? [20:41:28 CEST] <kierank> just watch it [20:41:29 CEST] <haasn> Or watch it when I don't have an internet connection? [20:41:29 CEST] <kierank> again [20:41:32 CEST] <BBB> netflix allows me to watch stuff [20:41:33 CEST] <haasn> Or watch it on an unstable internet connection? [20:41:36 CEST] <BBB> that youtube doesnt have [20:41:38 CEST] <Daemon404> haasn, youre not the majority of the oaying public [20:41:38 CEST] <BBB> so its useful [20:41:41 CEST] <BBB> like, Mad Men [20:41:54 CEST] <Daemon404> kierank, i care insomuch as i cannot view HD versions of some stuff on my laptop [20:41:57 CEST] <Daemon404> i have to use a tv or xbox [20:42:01 CEST] <BBB> haasn: so lets say you read about Mad Men (or any series) on some website, how do you watch it? [20:42:02 CEST] <kierank> on linux it does that [20:42:02 CEST] <Daemon404> but that's all. [20:42:04 CEST] <BBB> I netflix it [20:42:08 CEST] <BBB> haasn: what do you do? [20:42:13 CEST] <BBB> you dont watch it? [20:42:18 CEST] <BBB> or you go to the video store? [20:42:23 CEST] <BBB> or you get a cable subscription? [20:42:23 CEST] <kierank> Daemon404: iplayer lets you download programmes [20:42:32 CEST] <kierank> literally once I watched a programme on a plane [20:42:34 CEST] <Daemon404> kierank, thats fine i pay a tv license [20:42:50 CEST] <Daemon404> BBB, same thing most of us do [20:42:51 CEST] <kierank> you don't need a tv licence to dl iplayer [20:42:52 CEST] <Daemon404> piracy [20:43:04 CEST] <Daemon404> most shows i want o watch i simply cant [20:43:06 CEST] <Daemon404> 0 legal ways. [20:43:31 CEST] <BBB> netflix [20:43:38 CEST] <Daemon404> no. [20:43:45 CEST] <BBB> means I dont have to go through 10 porn sites or 10 fake movies before I find what Im looking for [20:43:48 CEST] <Daemon404> it's not on netflix in the uk. [20:43:53 CEST] <BBB> poor you [20:43:54 CEST] <Daemon404> and only 1 season of 10 is [20:43:56 CEST] <Daemon404> etc [20:44:03 CEST] <Daemon404> (in the us) [20:44:11 CEST] <BBB> mad men? [20:44:15 CEST] <haasn> BBB: I go on a torrent tracker and download the first episode [20:44:18 CEST] <Daemon404> example here was Adventure Time [20:44:19 CEST] <BBB> youre kidding me, I just started season 4 [20:44:22 CEST] <BBB> oh [20:44:23 CEST] <Daemon404> but it can apply ot e.g. Helix [20:44:40 CEST] <Daemon404> it's on prime and itunes. [20:44:42 CEST] <BBB> I dont know that series, anyway, yeah, piracy is a good second option [20:44:42 CEST] <Daemon404> in the USA only. [20:44:45 CEST] <Daemon404> most stuff is USA only. [20:44:50 CEST] <BBB> move here [20:44:52 CEST] <BBB> :-p [20:44:54 CEST] <BBB> its wonderful [20:44:55 CEST] <Daemon404> id rather not. [20:44:56 CEST] <BBB> they also pay better [20:45:45 CEST] <Daemon404> i get USA pay anyway. [20:47:08 CEST] <haasn> BBB: what's better for quality, the rips you can get off private torrent trackers or the stuff netflix streams? [20:47:20 CEST] <haasn> I obsess over video quality :/ [20:47:21 CEST] <kierank> depends actually [20:47:29 CEST] <Compn> torrent, always [20:47:30 CEST] <BBB> I never compared [20:47:33 CEST] <kierank> Compn: not true [20:47:38 CEST] <kierank> there are places on the internet where people have compared [20:47:40 CEST] <BBB> torrent is hard to find one thats not fake [20:47:40 CEST] <haasn> Compn: Okay, so YIFY then? :p [20:47:44 CEST] <kierank> it's a mixed bag [20:47:50 CEST] <Compn> obviously netflix gets hd versions of films that arent released in hd anywhere else [20:47:51 CEST] <BBB> theres so much fake crap within the mix [20:47:55 CEST] <Compn> so in that case, netflix would have the higher quality [20:48:05 CEST] <haasn> I don't watch TV shows, just movies from time to time. For movies you can generally find BD remuxes if you look hard enough [20:48:06 CEST] <Compn> and someone has to screenrip it to put up on a torrent site... [20:48:21 CEST] <Daemon404> lol screenrip [20:48:22 CEST] <haasn> Compn: films that aren't released on blu-ray? Like what? [20:48:32 CEST] <Daemon404> as if you cant just dump in-memory buffers [20:48:33 CEST] <Compn> haasn : you said private torrent sites, yify is mostly public tracker garbage :P [20:48:39 CEST] <haasn> (apart from older stuff) [20:48:50 CEST] <Compn> haasn : movies from the "old times" pre-2000 [20:48:57 CEST] <haasn> Compn: Those exist in HD? [20:49:01 CEST] <Compn> of course. [20:49:05 CEST] <Compn> they were shot on film! [20:49:15 CEST] <Compn> film !!! 35mm! 70mm! delicious film. :( [20:49:24 CEST] <Daemon404> and if youre lucky, the BD remasters will be DNR'd to hell [20:49:27 CEST] <haasn> Compn: The ones that get remastered in HD usually get Blu-ray releases for the HD versions, don't they? [20:49:28 CEST] <Daemon404> and look worse than the dvd [20:49:51 CEST] <Compn> blurays are shit dnr colorcorrected , i dont own any bluray :) [20:50:08 CEST] <Compn> haasn : sometimes hd releases, sometimes not. [20:50:18 CEST] <Compn> sometimes they just air them on MGM HD or other HD-only movie channels [20:50:41 CEST] <Compn> theres really no rhyme nor reason what films get dvd/bluray releases [20:50:52 CEST] <Compn> some movies havent even been released again since vhs/laserdisc... [20:51:12 CEST] <Compn> people hacking together workprints and vhs and vcds lol [20:51:44 CEST] <Compn> and then crazy people with their own film reels and telecine machines doing their own 35mm rips [20:52:17 CEST] <Compn> Jurassic Park 35MM Cinema DTS v1.0 [20:52:21 CEST] <Compn> glorious... [20:53:31 CEST] <kierank> film scanners are relatively cheap [20:53:33 CEST] <kierank> £20k [20:53:52 CEST] <philipl> usenet [20:54:18 CEST] <Compn> or cheaper since film companies are going out of bidness... all you have to do is move a room-size machine that weighs a few thousand pounds [20:54:52 CEST] <Daemon404> preferably a clean room [20:55:01 CEST] <Daemon404> unless you want tasty dust on your scan [20:55:27 CEST] <Compn> oh cool, someone posted the open-matte ver of jpark [20:55:35 CEST] <Compn> thats what i was waiting for [20:55:41 CEST] <llogan> not Beastmaster? [20:56:10 CEST] <llogan> "My friends call me Dar." [20:56:43 CEST] <Compn> well this is a 35mm scan, beastmaster probably is low on the list of films to scan [20:57:47 CEST] <Compn> haasn : i'm more of a video purist than a quality whore. i want the film as originally cut by the director , as originally colored by the cinematographer etc, as originally edited in theatrical release (or first cut). [20:58:00 CEST] <kierank> the director didn't shoot open matte [20:58:25 CEST] <Compn> true, but i like seeing more details in open matte [20:58:44 CEST] <haasn> Compn: I want to see the actor's nose hairs :p [21:02:57 CEST] <Compn> ah i guess the open matte wasnt posted yet :\ [21:07:42 CEST] <Compn> Daemon404 : oh i'll take all the dust, grime, cig burns, hairs in the gate. all that fun stuff. digital is so boring. [21:15:45 CEST] <dericed> some film scanners have a wet film gate where the film is submerged in a liquid of similar viscosity so it prevents the light traveling through the film from being bent to make a scratch [21:32:17 CEST] <Daemon404> dericed, is it dangerous to the physical film? [21:33:33 CEST] <dericed> it's not generally considered dangerous, the machinery cleans it off gently after existing the gate. it is far easier to remove film scratches (dark shadow ones) with wetgate transfers than trying to clean that later digitally [21:34:00 CEST] <dericed> when film shows white scratches, that's because the emulsion is scratch off and is a lot harder to resolve [21:37:37 CEST] <Daemon404> interesting [21:37:46 CEST] <Daemon404> i have some "rematsered" bds where you see terrible stuff [21:37:49 CEST] <Daemon404> like actual hairs [21:37:50 CEST] <Daemon404> on the film [21:38:07 CEST] <Daemon404> and others where they just DNR'd the entire thing to hide any effecxts [21:38:09 CEST] <Daemon404> makes me sad. [21:39:41 CEST] <dericed> Daemon404: ya, there's a LOT of bad film transfers out there. I sent some films out to make 4K DPX file sets, then ran through ffmpeg to make ffv1 files. They look great. [21:46:07 CEST] <kurosu> re avx2, hevc mc benefited around 5%, and I'd expect the same for correctly written transforms (hint: x265's is worse than an average sse2 version) [21:46:40 CEST] <Daemon404> kurosu, i am not shocked by that (the last bit) [21:46:41 CEST] <kurosu> other parts play a lesser role, so even with relative large improvements, they don't improve much anything [21:49:09 CEST] <kurosu> I've been told x265 is not exactly the best encoder reference quality+speed-wise, but I don't know the status of the corresponding offering [21:49:41 CEST] <Daemon404> x265 is the best of a bad showing [21:49:44 CEST] <kurosu> best encoder reference, compared to some other encoders [21:50:08 CEST] <Daemon404> from earlier: [21:50:08 CEST] <Daemon404> [19:36] <@Daemon404> i am not actually aware of any hevc encoder which beats x264 at bitrates suitable for transparency [21:50:11 CEST] <Daemon404> [19:36] <@Daemon404> in terms of grain retention etc [21:50:17 CEST] <Daemon404> most i have tested cant even beat it at mid range rates [21:50:50 CEST] <kurosu> and those would be? [21:50:53 CEST] <Daemon404> the only one i cant test is ateme, since they wont give us the time of day [21:50:59 CEST] <kurosu> ah [21:51:43 CEST] <kurosu> that was the one I had in mind, actually [21:52:07 CEST] <Daemon404> they dont seem interested in us [21:52:39 CEST] <Daemon404> so i /care'd, since it isn't really feasible to distribute hevc yet anyway [21:53:41 CEST] <kurosu> I think netflix evaluated it, but they prefer not having to pay for their encoders [21:53:51 CEST] <Daemon404> that's a lie [21:53:58 CEST] <Daemon404> cause netflix used vanguard for their hevc [21:54:02 CEST] <kurosu> then I've been lied to, ok [21:54:03 CEST] <Daemon404> not sure if they now dropped it [21:54:33 CEST] <Daemon404> nothing else usable existed at the time iirc [21:54:43 CEST] <Daemon404> i heard they always intended to dorp it [21:55:03 CEST] <Daemon404> one of those 'first to market' sort of deals. [21:56:18 CEST] <Daemon404> (i had predicted hevc will win... but with the 2 patent pools, and now a future MPEG-DASH patent pool.... eh... well see) [21:56:23 CEST] Action: Daemon404 stops rambling [21:58:37 CEST] <ubitux> gif master race [22:13:00 CEST] <rcombs> Daemon404: apparently some devices can decode HEVC in 4K, and H.264 only up to 1080p [22:13:19 CEST] <Daemon404> yes.... some [22:15:31 CEST] <rcombs> come to think of it it's probably quite a lot of them [22:15:46 CEST] <rcombs> since for 3840x2160 you need L5.1 at least [22:15:49 CEST] <philipl> You keep the decoding blocks you already have if you can get away with it [22:16:33 CEST] <Daemon404> rcombs, not enough stuff for a website to justify distributing it [22:16:34 CEST] <Daemon404> imo [22:17:46 CEST] <rcombs> and apparently despite putting together an HEVC decoder that I'd imagine has all the e.g. RAM requirements of an H.264 L5.2 one, they still leave the H.264 decoder capable of only, eh, 4.0 to 4.2, Main or High only [22:18:04 CEST] <Daemon404> it's likely for marketing [22:18:08 CEST] <Daemon404> push hevc because OMG RES [22:18:13 CEST] <Daemon404> not because it's actually better right now [22:18:14 CEST] <Daemon404> that [22:18:19 CEST] <Daemon404> that si what netflix did* [22:18:23 CEST] <rcombs> hurr [22:19:18 CEST] <rcombs> I've been wondering how feasible a single H.264 frame would be as an image format, a la BPG [22:19:41 CEST] <Daemon404> x264 has tune stillimage fyi [22:19:42 CEST] <nevcairiel> didnt that exist [22:23:07 CEST] <kierank> rcombs: I have wanted to do that for years [22:23:17 CEST] <thardin> implement it, then megabytes of emscripten'd h264dec to decode it [22:23:17 CEST] <kierank> but the browser mimetype mafia say h264 is for videos [22:23:33 CEST] <rcombs> I'd imagine it performs better than JPEG [22:23:48 CEST] <philipl> Can you put up a single frame in a <video> tag and get the right results? [22:23:54 CEST] <philipl> especially with the gifv stuff to hide the controls [22:24:10 CEST] <rcombs> <video> doesn't get controls by default anyway [22:24:17 CEST] <philipl> so isn't that sufficient? [22:24:21 CEST] <rcombs> depends [22:24:42 CEST] <rcombs> a _lot_ of embedded stuff only lets you have one <video> in the DOM at once [22:27:31 CEST] <rcombs> I was just imagining something involving feeding the <video> into a <canvas> and copying all the frames out and into wherever onscreen you need them, but then remembered a lot of these systems don't let you write from <video> to <canvas> either [22:28:18 CEST] <rcombs> so it'd really only work in native software where you can actually handle the decoding and display yourself [22:31:29 CEST] <philipl> Yeah, wouldn't surprise me. [22:34:16 CEST] <rcombs> (or if you used megabytes of emscripten'd h264dec but ~slow~) [22:36:20 CEST] <philipl> tasty. [22:36:32 CEST] <philipl> Or server-side conversion to jpeg :-P [22:37:00 CEST] Action: Daemon404 notes they already serve different images to different browsers [22:37:04 CEST] <Daemon404> adding one more is hardly effort [22:37:23 CEST] <Daemon404> h264 is very suboptimal on mobile full stop though [22:37:31 CEST] <Daemon404> e.g. it will display the play icon over the image [22:37:34 CEST] <Daemon404> on some [22:37:40 CEST] <Daemon404> for images i mean [22:38:23 CEST] <philipl> Maybe the gifv stuff would help with that. [22:38:36 CEST] <Daemon404> gifv is just clever stuff [22:38:43 CEST] <Daemon404> imgur serves gif to mobile by default [22:38:47 CEST] <Daemon404> except in their app [22:38:56 CEST] <Daemon404> it servers webm in some browsers too [22:39:14 CEST] <Daemon404> (they in fact use ffmpeg) [22:41:48 CEST] <philipl> what's the motivation here again? [22:41:58 CEST] <philipl> Better still images on a little phone screen? [22:42:30 CEST] <Daemon404> smaller files [22:42:33 CEST] <Daemon404> imgur uses a lot of bw [22:42:53 CEST] <Daemon404> usually the webm or h264 looks worse than the gif version... [22:42:57 CEST] <Daemon404> but not always [22:43:11 CEST] <nevcairiel> well its to be expected [22:43:16 CEST] <philipl> They're usually transcoded from gif in those situations right? [22:43:23 CEST] <nevcairiel> its a lossy compression which was created from the gif original [22:43:35 CEST] <nevcairiel> so best you can do is "equal" visually [22:43:42 CEST] <nevcairiel> but chances are, it may look slightly worse [22:43:46 CEST] <nevcairiel> much, much smaller though [22:44:30 CEST] <Daemon404> nevcairiel, the input is increasingly youtube videos and such [22:44:37 CEST] <Daemon404> imgur has a tool for that [22:44:44 CEST] <Daemon404> they still manage to look worse than the gif versions [22:44:48 CEST] <nevcairiel> making a gif from actualy video content will usually look horrible though [22:45:05 CEST] <nevcairiel> so unless they go youtube -> gif -> webm, it should probably look better [22:46:10 CEST] <philipl> Clearly webp is the solution. [22:48:07 CEST] <jamrial> for still images why not? already supported by webkit/blink browsers, so almost the entire mobile market and more than half the desktop market [22:48:37 CEST] <Daemon404> jamrial, we serve webp to such [22:48:41 CEST] <philipl> safari supports it?? Surely not. [22:48:42 CEST] <ubitux> well at least with give you don't have chroma subsampling [22:48:45 CEST] <ubitux> with gif* [22:48:56 CEST] <philipl> 256 colours should be enough for anyone. [22:48:57 CEST] <Daemon404> amazingly, sometimes webp looks much worse than similarly sized jpegs made with mozjpeg [22:49:18 CEST] <ubitux> no need for a loop filter either, no blocks! [22:49:54 CEST] <philipl> Truly the technology of the future. [22:49:56 CEST] <ubitux> maybe daala should take inspiration in gif [22:50:47 CEST] <philipl> Didn't fabrice, or someone, try to propose an h.264 still image format before bpg? [23:21:42 CEST] <BBB> why do you want a still image format? [23:22:04 CEST] <BBB> the problem is not proposing new image formats; the problem is convincing people to actually use it; jpeg has won that war [23:22:12 CEST] <BBB> (see webp) [23:22:14 CEST] <philipl> Yeah. [23:22:29 CEST] <BBB> you cant beat the jpeg no patents, coverage everywhere factor [23:22:37 CEST] <BBB> I mean, thats absolutely priceless [23:22:41 CEST] <philipl> I don't know if rcombs was just curious or has a real need. [23:22:48 CEST] <philipl> mpeg2 only has three years to go! [23:23:20 CEST] <rcombs> I mean, JPEG sucks, and I'd love to see something that doesn't [23:24:41 CEST] <thardin> just use Accept headers properly [23:24:45 CEST] <kierank> well jpeg is doing quite well actually [23:24:49 CEST] <thardin> then serve both [23:25:12 CEST] <thardin> does webp support anything but 8-bit 4:2:0 yet? [23:26:25 CEST] <philipl> Don't think so. [23:26:35 CEST] <philipl> I assume a vp9 based webp could fix that. [23:27:18 CEST] <haasn> BBB: What's wrong with webp? [23:27:44 CEST] <BBB> technically? nothing [23:27:51 CEST] <haasn> As far as I can tell, JPEG is only winning because browser vendors are blindly refusing to add support for any other image format, claiming JPEG already won as the only reason why [23:27:56 CEST] <BBB> I mean, its vp8-based, but what can you do, thats what they had when they started it [23:28:13 CEST] <haasn> For example, YouTube is already using WebP but eg. Mozilla simply refuses to support it, despite perfectly fine patches already being written, multiple times [23:28:20 CEST] <BBB> also, google can use it for youtube thumbnails or stuff like that if browser supports it [23:28:24 CEST] <haasn> yeah [23:28:29 CEST] <BBB> exactly [23:28:33 CEST] <BBB> mozilla has jpeg [23:28:34 CEST] <thardin> I thought browser vendors were all about shoving everything and the kitchen sink in [23:28:37 CEST] <BBB> they dont _need_ webp [23:28:54 CEST] <haasn> thardin: nah, just proprietary botnet stuff like Pocket [23:29:03 CEST] <thardin> Pocket? [23:29:05 CEST] <haasn> not useful stuff like webp support or a video player that isn't garbage [23:29:07 CEST] <BBB> thardin: it has rgb and lossless [23:29:14 CEST] <BBB> thardin: but these are not vp8-based obviously [23:30:01 CEST] <thardin> ah [23:30:02 CEST] <haasn> thardin: Pocket is a proprietary service for storing your tabs and stuff; it used to be an addon but the mozilla devs decided to include it as part of the firefox source code in exchange for money [23:30:22 CEST] <thardin> uhh.. that sounds.. fishy [23:30:24 CEST] <haasn> (luckily, you can still disable it using about:config and/or patch it out again) [23:30:31 CEST] <haasn> thardin: a lot of mozilla's post-eich decisions have been.. fishy [23:30:31 CEST] <thardin> is it in iceweasel too? [23:30:34 CEST] <haasn> doubtful [23:30:44 CEST] <thardin> good [23:30:47 CEST] <haasn> but I have no idea about how much iceweasel diverges from firefox [23:30:55 CEST] <haasn> check for browser.pocket.* I guess [23:31:22 CEST] <haasn> thardin: I have somewhere a list of like 20 hidden settings that you need to disable in a new firefox installation to get rid of all the tracking [23:31:26 CEST] <thardin> typing pocket in about:config shows nothing [23:31:26 CEST] <haasn> they've gotten just as bad as google [23:31:53 CEST] <thardin> I've been pondering switching to a browser that plays well with yacy [23:32:03 CEST] <Gramner> actually, they didn't even get paid to include it which makes it even more weird [23:32:17 CEST] <haasn> I've been pondering forking Firefox and removing the stuff I don't want, but it seems like too much effort every time I try [23:32:18 CEST] <thardin> since any centralized web search service inevitably becomes shit [23:32:44 CEST] <haasn> thardin: My current favorite is searx, which you can self-host [23:32:50 CEST] <haasn> (I use an instance hosted by lachs0r) [23:33:11 CEST] <haasn> So it's sort of distributed, in that there's no clear central company that would benefit from you using their engine [23:33:36 CEST] <haasn> But it's also just a glorified proxy, you don't crawl the web yourself [23:34:01 CEST] <haasn> Its core is a computer program written in Java distributed on several hundred computers, as of September 2006, so-called YaCy-peers. Why does all this p2p stuff always end up being written in Java [23:34:05 CEST] <haasn> Reminds me of Freenet [23:34:07 CEST] <thardin> I kinda want to host a crawler so it produces a lot of clearnet chaff [23:34:35 CEST] <haasn> Great concept but completely unusable because it runs on Java and consumes literally like 1GB of RAM just to bootstrap a connection; and idles at 10% CPU usage (no, seriously) [23:35:13 CEST] <thardin> eh, java is alright [23:37:00 CEST] <haasn> https://en.wikipedia.org/wiki/Yacy#Disadvantages meh [23:37:04 CEST] <haasn> I'm sure there can be a better distributed search engine [23:51:05 CEST] <debianuser> haasn: Heh. They didn't do it for money. People asked a lot about that in #firefox. They wanted to deliver some mobile-compatible reader, and they worked on their "Reader Mode", but still had a lot to do. So they thought "Pocket works, let's deliver firefox at least with Pocket support for now until we make our reader-mode better". :) [23:55:04 CEST] <cone-384> ffmpeg 03Michael Niedermayer 07master:ae413a48e642: avcodec/movtextdec: check that ftab has been allocated before dereferencing it [23:55:50 CEST] <haasn> debianuser: I don't get it. Firefox is not a product. It's a free software project. They don't need to placate their users and keep their shareholders happy [23:56:10 CEST] <haasn> If anything, pocket integration has caused more controversy and scared people away from firefox.. [00:00:00 CEST] --- Fri Aug 7 2015

1 0

ffmpeg.log.20150806
by burek 07 Aug '15

07 Aug '15

[00:06:54 CEST] <c_14> sine0: yes, why? [01:13:16 CEST] <kyleogrg> how can i convert a "normal" color space video to 256 colors? [01:14:30 CEST] <kyleogrg> in other words, how can i reduce the amount of colors when encoding a video? [01:22:12 CEST] <kepstin> kyleogrg, for what, an animated gif? you'll want to look into the palettegen and paletteuse filters [01:22:39 CEST] <kyleogrg> no, just wondering if it was possible [01:22:54 CEST] <kepstin> for anything other than an animated gif you probably don't want to do that, it'll make the video harder to encode/look worse for most codecs. [01:27:40 CEST] <kyleogrg> ok [01:34:31 CEST] <durandal_1707> look at elbg filter [01:40:50 CEST] <kyleogrg> okay [01:42:15 CEST] <edoceo> if I've got lots of video to filter (scale, crop, layout) what can I choose as a reliable, maybe fast interim codec/format? [01:44:24 CEST] <kepstin> edoceo, if you've got lots of disk space and io bandwidth, something like ffvhuff is ridiculously fast [01:44:43 CEST] <kepstin> ffv1 is smaller/slower [01:45:16 CEST] <kepstin> could also try using a lossy codec like x264 with high quality/fast encode settings [01:45:55 CEST] <edoceo> which audio ? flac Ok? MKV contasiner? [01:46:18 CEST] <kepstin> sure, flac's a decent choice for audio, and any of the above codecs should work in mkv i think. [01:48:43 CEST] <kevmitch> If you're doing processing on the audio, it's better to use an interim format that supports float [01:49:25 CEST] <kevmitch> wav is probably easiest, but there's also wavpack [01:50:28 CEST] <edoceo> so ffvhuff and wav in a mkv ? [01:50:35 CEST] <kepstin> hmm, most of the time you probably won't be doing enough to audio to worry about 16bit being a limit. [01:50:45 CEST] <kepstin> and flac can do 24bit audio which should be more than enough. [03:48:27 CEST] <kyleogrg> hey [03:48:45 CEST] <kyleogrg> i have a command all ready, and now i'd like to run it on a bunch of videos [03:48:59 CEST] <kyleogrg> i've done this before a couple of different ways [03:49:19 CEST] <kyleogrg> but is there a gui which lets you do this and shows a progress bar with estimated time remaining? [04:46:15 CEST] <k_sze> When reading frames from a video file with ffmpeg, does it care that the reading is performed on multiple threads? [04:48:11 CEST] <k_sze> I want to have a timer that triggers the reading of a frame, but this will be a .NET System.Timers.Timer, so the timer action will run on any available thread in a thread pool. [04:49:10 CEST] <k_sze> Synchronizing my own timer action so that is is effectively sequential and non-reentrant is not a big problem. [04:51:32 CEST] <k_sze> My question is more like, would ffmpeg say "Look, this file is opened in Thread 1, I can't allow you to demux and decode in Thread 2." [09:29:22 CEST] <baadf00d> Hi, i have a question regarding distribution. Apparently I can use gpl versioned ffmpeg from my non-gpl software, if I use it through command line. [09:29:49 CEST] <baadf00d> but can I distribute gpl ffmpeg along with my non-gpl software? [11:51:55 CEST] <spvhere> trying to live stream webcam audio & video feed using ffmpeg and ffserver in webm format, libvorbis for audio and libvpx for video, I get a dimension not set on ffserver and conversion failed on ffmpeg [14:37:58 CEST] <termos> when printing out the pts values converted to seconds for audio and video the video is about 2.5 seconds behind the audio. The audio and video is synced though, I'm guessing because of interleave_frame [14:38:09 CEST] <termos> should this cause any problems? [14:54:34 CEST] <Mavrik> only if the decoder doesn't have a small buffer [14:54:36 CEST] <Mavrik> er. [14:54:45 CEST] <Mavrik> only if decoder's buffer is smaller than 2.5 seconds [14:54:51 CEST] <Mavrik> ideally the offset should be close to 0 [14:55:34 CEST] <termos> okey thanks, I don't know where this offset comes from. I'll try to see what the pts is right after the demuxing [15:18:50 CEST] <Stifler> King of kong: fistfull of quarters ; Chasing ghosts ; TILT The battle to save pinball ; [15:18:58 CEST] <Stifler> Best movies ever!! [15:19:30 CEST] <Stifler> I am old :p [15:35:07 CEST] <termos> Mavrik seems like the internal encoding buffer for video is larger than the one for audio (fdk_aac) [20:25:23 CEST] <Nolski> Hey, could someone explain to me what the error "Error while decoding stream #1:1: Cannot allocate memory" means exactly? I see it pretty often in a variety of commands but the output normally seems fine. [20:34:03 CEST] <llogan> the command and console output would be helpful [20:46:43 CEST] <DHE> also if you're running other commands that would consume resources. running out of swap, having too many processes, running in 32 bit mode, etc may cause these kinds of errors. (too many processes manifests in several strange ways along the pipeline) [20:52:09 CEST] <Nolski> DHE: llogan It's a part of a massive batch of edits on one file (that's generated by a python script). [20:52:25 CEST] <Nolski> But here is kind of a sample of the output where it happens (check out line 53) https://gist.github.com/Nolski/40027414f49be4cc1b34 [20:54:12 CEST] <Nolski> drop keeps increasing until it hits the total number of frames and then the command ends [21:05:29 CEST] <OstlerDev> Is there a flag that allows conversion of a file that has not finished downloading? Or on an error just try again instead of crashing? [21:29:38 CEST] <c_14> OstlerDev: mp4? [21:57:15 CEST] <kyleogrg> Do you think yadif is necessary in this command? http://pastebin.com/7UKiJYSK [21:57:53 CEST] <kyleogrg> I'm converting interlaced ntsc avi video to super-low bitrate, low-res videos [21:58:07 CEST] <kyleogrg> at half the frame rate [21:58:42 CEST] <kyleogrg> I'm wondering if the quality is too low to notice the difference between yadif and a faster deinterlacer [21:59:14 CEST] <DHE> well, if you're using placebo then I'd say "use the better deinterlacer" :) [21:59:36 CEST] <kyleogrg> yeah [22:00:06 CEST] <kyleogrg> what if i did "framestep" before "yadif"? would that hurt anything? [22:02:30 CEST] <edoceo> How can one fix corrupt Duration on a video? [22:02:48 CEST] <edoceo> I've transcoded to an interim format and back but the Duration still reports 2 years [22:03:53 CEST] <edoceo> I need an ffmpeg consultant to get in here and help with some of these issues [22:05:00 CEST] <DHE> kyleogrg: based on the source I'd say that yadif does use multiple frame to assist in deinterlacing and you should move framestep down the filter chain [22:05:10 CEST] <DHE> ie. leave it as is [22:05:40 CEST] <DHE> though why are you scaling it twice? [22:06:14 CEST] <kyleogrg> the first scaling is to convert it to square pixels (ie, 720x480 becomes 640x480) [22:07:13 CEST] <kyleogrg> is that can be converted into one formula (i don't know exactly how) and it will make encoding faster, then i'd like to know [22:07:24 CEST] <kyleogrg> if* that .... [22:10:15 CEST] <klaxa> edoceo: did you try the ffmpeg-user mailing list? [22:10:24 CEST] <edoceo> I have not yet [22:11:00 CEST] <klaxa> i think more devs read that ML than this irc channel (because of the real-time nature of irc) [22:11:14 CEST] <klaxa> it can't hurt to post it there too [22:45:55 CEST] <kyleogrg> can this be combined into one scale? scale=iw*sar:ih,scale=-2:ih/3.3333 [23:44:50 CEST] <shadowkyogre> for some reason, the ffmpeg command yields a lot sloppier sound than using arecord to record the speaker input [23:44:51 CEST] <shadowkyogre> .asoundrc: https://ptpb.pw/G2hY [23:44:51 CEST] <shadowkyogre> command I used to test ffmpeg audio quality with video recording: https://ptpb.pw/wAjP (I get a bunch of cannot estimate delay errors in vlc. Some poking in the #alsa channel pointed out that the yuv420p flag was causing issues. The audio is better when I remove it, but the audio still plays a bit funny) [23:44:51 CEST] <shadowkyogre> command I used to test ffmpeg audio quality w/o video: ffmpeg -f alsa -ac 2 -ar 48000 -i dsnoop:Loopback,1 myloop.wav [23:44:51 CEST] <shadowkyogre> command I used to test audio quality with normal arecord: arecord -fdat -D "dsnoop:Loopback,1" -d 10 test-mix.wav [23:53:44 CEST] <OstlerDev> c_14 Yes, to mp4 [23:56:55 CEST] <c_14> OstlerDev: then no [23:57:02 CEST] <c_14> mp4 store important metadata at the end of the file [23:57:46 CEST] <OstlerDev> c_14 you can add the setting to put the metadata at the start [23:57:53 CEST] <OstlerDev> Oh, you mean source file? [23:57:58 CEST] <OstlerDev> Usually AVI or MKV [23:58:16 CEST] <OstlerDev> I want to convert to MP4, or some other h.264 format for streaming to an Apple TV [00:00:00 CEST] --- Fri Aug 7 2015

1 0