Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

October 2015

1 participants
62 discussions

ffmpeg-devel.log.20151020
by burek 21 Oct '15

21 Oct '15

[00:49:46 CEST] <rcombs> I just implemented ALPN support in curl's darwinssl [00:49:53 CEST] <rcombs> the weird thing is that I have no idea why I did that [00:50:05 CEST] <wm4> what is ALPN [00:50:27 CEST] <rcombs> the TLS extension that lets you tell the server what application-layer protocol you're using in the handshake [00:50:51 CEST] <wm4> what does it mean? [00:50:54 CEST] <rcombs> mostly used for negotiating HTTP/2 in the TLS handshake instead of starting at HTTP/1.1 and upgrading [00:51:21 CEST] <rcombs> Application Layer Protocol Negotiation [00:51:40 CEST] <rcombs> Secure Transport supports it but it's private/undocumented API [00:52:30 CEST] <wm4> http 2... how terrible [00:54:26 CEST] <llogan> pcm_* in mpeg ps is not kosher, right? [00:54:41 CEST] <rcombs> reverse-engineering it was fun though [00:54:53 CEST] <rcombs> because apparently absolutely nobody has written public docs on it before [00:56:54 CEST] <TD-Linux> rcombs, I was under the impression that chromium uses Secure Transport... did they also reverse it? [00:58:29 CEST] <wm4> btw., didn't nevcairiel write a native windows thing too? [00:58:48 CEST] <rcombs> they use NSS [00:58:50 CEST] <rcombs> wm4: yup [01:00:20 CEST] <spaceinvader> does anyone have an interest in the prores encoder? i've been doing some research as i have a hardware decoder that won't play files from ffmpeg and i'm working towards a patch, but I could do with some help / a mentor [01:00:37 CEST] <rcombs> aren't there 2 of those [01:00:40 CEST] <rcombs> have you tried the other one [01:00:48 CEST] <spaceinvader> yes, neither produce a "valid" output [01:01:07 CEST] <rcombs> make that 3, actually [01:01:16 CEST] <spaceinvader> 3? [01:01:47 CEST] <spaceinvader> at the moment I'm patching proresenc_anatoliy but I'll also look at proresenc_kostya. there's also a decoder, but AFAIK that works OK [01:02:05 CEST] <wm4> we should drop 2 of these 3 [01:02:07 CEST] <wm4> but politics [01:02:24 CEST] <kierank> spaceinvader: which hardware decoder [01:02:34 CEST] <rcombs> oh wait [01:02:38 CEST] <rcombs> only 2 but one of them has 2 names [01:02:40 CEST] <spaceinvader> if you specify -vcodec prores then it uses the anatoliy one [01:02:51 CEST] <spaceinvader> kierank: blackmagic hyperdeck studio thing [01:03:03 CEST] <kierank> ah I have one of those [01:03:13 CEST] <spaceinvader> having looked at all of the other prores files I have, it seems that actually there is an alignment issue [01:03:42 CEST] <spaceinvader> the encoders we have right now seem to be based of the same reverse engineer [01:04:02 CEST] <kierank> yes [01:04:33 CEST] <kierank> I guess you made sure to produce mov files that were exactly like the ones the hyperdeck make [01:04:58 CEST] <spaceinvader> yep. i can actually remux apple prores with ffmpeg and it still plays fine [01:05:14 CEST] <spaceinvader> and i've been messing around with the apple "Atom Inspector" [01:06:37 CEST] <kierank> what is aligned differently [01:07:12 CEST] <spaceinvader> http://wiki.multimedia.cx/index.php?title=Apple_ProRes#Frame_header so these are kostya's notes [01:08:09 CEST] <spaceinvader> i find if i pad the frame headers so they are divisible by 16 (with the padding counted in the hdrSize but not in any of the picture slices / pic_data_size) [01:08:13 CEST] <spaceinvader> then it almost plays [01:08:20 CEST] <spaceinvader> i'm still having trouble with a couple of frames [01:08:41 CEST] <spaceinvader> but also my padding is currently random memory and not zeros, so that might be to do with it [01:09:33 CEST] <kierank> you can PM kostya. his nick is "Keiler" [01:09:50 CEST] <spaceinvader> thanks [01:11:14 CEST] <kierank> the hyperdeck thing is quite interesting - it loads new firmware into the fpga depending on the codec you choose [01:12:34 CEST] <spaceinvader> cool. i noticed it has it's own fourcc too. most of the "apple licensed prores" encoders have one beginning with "a" for apple, e.g. "atf0" for "apple - The Foundry" and "abm0" for "Apple - BlackMagic DaVinci Resolve" [01:12:53 CEST] <spaceinvader> but the hyperdeck uses "bmd0", so it seems like they must have done their own implementation [01:13:16 CEST] <kierank> yes I believe so [01:13:24 CEST] <spaceinvader> in any case, app of my apple prores movs have frames that divide by 16, and all of the blackmagic hyperdeck created ones divide by 4 [01:13:51 CEST] <spaceinvader> but at the moment ffmpeg ones can be odd length [01:14:45 CEST] <kierank> how does apple pad the frame [01:15:13 CEST] <kierank> I guess I could find some SDI and record it and see [01:15:21 CEST] <kierank> the only prores file I have is 300GB [01:17:31 CEST] <rcombs> I can grab some [01:17:40 CEST] <spaceinvader> apple just seems to pad with zeros after all the slice data [01:17:42 CEST] <rcombs> got access to a couple Ki Pros [01:17:54 CEST] <rcombs> (also software) [01:18:25 CEST] <spaceinvader> i've been using records from the blackmagic, and output from apple compressor, the foundry nuke and davinci resolve [01:18:33 CEST] <spaceinvader> can get some sample files uploaded once i'm back at work tomorrow [01:20:42 CEST] <wm4> <kierank> the only prores file I have is 300GB <- is there a nice anecdote behind this? [01:20:55 CEST] <kierank> it's a 6 hour recording [01:21:33 CEST] <kierank> the anecode is I tried to download it at vdd13, assuming the speed would be fast at the ISP hosting the conf [01:21:49 CEST] <kierank> I gave up and downloaded it on my 3g plan [01:23:50 CEST] <kierank> https://scontent-lhr3-1.xx.fbcdn.net/hphotos-ash2/v/t1.0-0/p206x206/1011774… [01:23:53 CEST] <kierank> there is my proof [01:26:31 CEST] <llogan> 300gb. and here im still using an iphone 3gs.... [01:27:32 CEST] <spaceinvader> kierank: hey cool, you're OBE/OBS right? [01:27:59 CEST] <kierank> depending on your definition of OBS, ye [01:28:00 CEST] <kierank> s [01:29:16 CEST] <spaceinvader> i'm after some h264/zixi encoders, recognised your logo from the zixi website [01:29:55 CEST] <kierank> heh ok [01:54:24 CEST] <cone-278> ffmpeg 03Timothy Gu 07master:cb6f1f8bf95e: x86: fpel: Move prototypes for 4-px block functions [01:54:24 CEST] <cone-278> ffmpeg 03Timothy Gu 07master:607f820ec7c9: x86: fpel: Remove erroneous ff_put_pixels8_mmxext prototype [01:54:24 CEST] <cone-278> ffmpeg 03Timothy Gu 07master:a079cbf458fc: x86: vc1dsp_mmx: Move yasm initiation steps to vc1dsp_init [01:57:40 CEST] <cone-278> ffmpeg 03Timothy Gu 07master:068e6cb73205: huffyuvencdsp: Use intptr_t for width [02:04:25 CEST] <Timothy_Gu> kierank: can you install libc6-dev-i386 and preferably g++-multilib on avdev? [02:04:41 CEST] <Timothy_Gu> those are necessary for testing -m32 [02:05:11 CEST] <kierank> done [02:05:55 CEST] <Timothy_Gu> that was fast. Thanks! :) [02:33:04 CEST] <cone-278> ffmpeg 03Michael Niedermayer 07master:e91cd8a9c46f: compat/solaris/make_sunver.pl: Use /usr/bin/env perl instead of /usr/bin/perl [08:52:26 CEST] <thardin> I hear visual studio can compile ffmpeg nowadays. is this true? [08:52:36 CEST] <thardin> without using c99toc89 that is [08:52:46 CEST] <j-b> yes [08:53:48 CEST] <thardin> neat [09:02:38 CEST] <JEEB> 2013u2 or newer methinks [09:19:51 CEST] <thardin> http://blogs.msdn.com/b/vcblog/archive/2015/10/19/do-you-prefer-fast-or-pre… survey whether msvc should default to /fp:precise of /fp:fast [09:20:03 CEST] <thardin> is what got me thinking about it [10:06:44 CEST] <cone-732> ffmpeg 03Paul B Mahol 07master:0e08d6ca140a: avformat: add msf demuxer [10:06:44 CEST] <cone-732> ffmpeg 03Paul B Mahol 07master:35564318ad5a: avformat: add wve demuxer [11:41:40 CEST] <ubitux> lol google [11:41:45 CEST] <ubitux> MediaCodec, API C my ass [11:41:54 CEST] <ubitux> they don't map to the java thing [11:41:56 CEST] <ubitux> no async [11:42:15 CEST] <ubitux> (and sync one doesn't fit in the ff model either) [11:42:31 CEST] <ubitux> jni incoming [11:44:46 CEST] <mateo`> I want to drink to forget this thing [11:45:06 CEST] <wm4> lol [11:45:13 CEST] <wm4> wat [11:45:31 CEST] <wm4> ubitux: it might not matter if the C API can be as fast as the Java thing? [11:45:43 CEST] <wm4> what do you mean the sync one doesn't fit ffmpeg? [11:48:34 CEST] <mateo`> MediaCodec provides two main functions, dequeueInputBuffer, dequeueOutputBuffer that let you retreive the internal buffers [11:49:32 CEST] <mateo`> dequeueInputBuffer can returns TRY_AGAIN_LATER (meaning you can't feed more data into the decoder) [11:50:17 CEST] <mateo`> maybe i'm mistaken but the ffmpeg decode function feeds a packet into the decoder, and then call the decoder to output the frame [11:51:18 CEST] <mateo`> its the same for dequeueOutputBuffer [11:51:36 CEST] <rcombs> you generally call a single function that feeds a packet in and gets a frame out [11:52:00 CEST] <mateo`> yes this is what i meant (sorry if i'm not clear) [11:52:57 CEST] <mateo`> so here it means that when the decoder tell you to try again when you want to push a frame to it [11:53:08 CEST] <rcombs> so a MediaCodec wrapper would need to have its own queueing [11:53:18 CEST] <mateo`> you have to queue it locally, so you can queue it when in the next call of the decode function [11:57:07 CEST] <mateo`> well, it should fit the current api by queueing its input when needed [12:00:09 CEST] <iive> or allow the current api to take an empty packet and return frame and take a packet and don't return frame [12:17:49 CEST] <cone-732> ffmpeg 03wm4 07master:de1b1a7da9e6: avformat/mp3dec: improve junk skipping heuristic [12:18:04 CEST] <wm4> phew, no stale commits accidentally pushed this time [12:18:55 CEST] <wm4> mateo`: we were discussing an alternative API for libavcodec, which can handle decoupled packet/frame I/O [12:37:45 CEST] <mateo`> wm4: yes, i'm following the discussion [12:50:52 CEST] <cone-732> ffmpeg 03wm4 07release/2.7:9362282fd17f: avformat/mp3dec: improve junk skipping heuristic [12:50:54 CEST] <cone-732> ffmpeg 03wm4 07release/2.8:96b87d5cfaa5: avformat/mp3dec: improve junk skipping heuristic [13:06:50 CEST] <cone-732> ffmpeg 03Hendrik Leppkes 07master:00ae5b401b24: dca_parser: don't overwrite the sample rate, it may not be correct [18:26:51 CEST] <Alzathar> Hi everybody [18:28:02 CEST] <Alzathar> I would like to add the mime_type field for each demuxer. Is there any reason why it was not done before? [18:28:27 CEST] <wm4> there are mime types in some places [18:28:33 CEST] <wm4> but often they're just not needed [18:28:39 CEST] <wm4> for what do you want to use them? [18:28:48 CEST] <Alzathar> Yes but mostly for muxer [18:29:43 CEST] <Alzathar> I would like to integrate FFmpeg into Qt as QtMultimedia plugin. [18:30:00 CEST] <Alzathar> However, this requires to know the mime types [18:30:56 CEST] <wm4> what does it need to know them for? [18:32:59 CEST] <Alzathar> To determine if the media service support a media format [18:33:08 CEST] <Alzathar> http://doc.qt.io/qt-5/qmediaservicesupportedformatsinterface.html#supported… [18:33:41 CEST] <wm4> mime types are a very bad way to identify media file formats and anything [18:34:05 CEST] <wm4> it might make sense to return from that function whatever you can think of [18:34:33 CEST] <wm4> instead of doing it "properly" (which would just lead to mediocre results anyway) [18:35:12 CEST] <Alzathar> ok, thanks for the advice. [18:35:50 CEST] <wm4> (and libavformat itself identifies media types by probing the actual data) [18:37:25 CEST] <Alzathar> I will focus more on the second method which gives a list of codecs to know if they are supported. [18:37:40 CEST] <Alzathar> Yes, I [18:38:08 CEST] <Alzathar> Regarding libavformat, I found the way to idently the media type. [18:38:20 CEST] <TD-Linux> yeah sadly the documentation says very little. most qt apps probably use types from mime.types, so they aren't very useful [18:38:59 CEST] <TD-Linux> mediasource's isTypeSupported uses extended types like this: video/mp4; codecs="avc1.42E01E, mp4a.40.2" [18:39:23 CEST] <j-b> Qt multimedia is crap [18:39:50 CEST] <TD-Linux> but that requires the app to know what it's passing to phonon, which it probably doesn't. [18:40:05 CEST] <Alzathar> Phonon is no more used in Qt5 [18:40:12 CEST] <TD-Linux> err QtMultimedia [18:40:22 CEST] <j-b> phonon works with Qt5 [18:41:05 CEST] <Alzathar> @j-b: Maybe, but this is no more the default engine to read media service. [18:41:40 CEST] <Alzathar> *to read media [18:42:39 CEST] <j-b> good luck [18:45:58 CEST] <Alzathar> I am interested to extract video frame and overlay it with some information. The new QtMultimedia system seems well adapted for that: http://doc.qt.io/qt-5/qtmultimedia-video-qmlvideo-example.html [18:47:26 CEST] <JEEB> holy fuck [18:47:43 CEST] <JEEB> ARIB's standardization of MMT over UDP oover TLV [18:48:30 CEST] <JEEB> no idea if they will ever use that in reality, but it seems overconvoluted like hell [18:50:19 CEST] <wm4> fishing for consulting money? [18:54:08 CEST] <wm4> ubitux: someone reported this: https://sr.ht/jJ0A.txt [18:55:46 CEST] <kierank> JEEB: omg [18:58:39 CEST] <JEEB> kierank: just reading the specs is fun when you have no idea what those parts are at first: STD-B60 -> STD-B32 -> STD-B10 -> R-REC BT.1869 [18:59:50 CEST] <JEEB> I'm still reading wtf they mean with MMT [19:00:06 CEST] <JEEB> I get it that they're using MFU/MPU for video and audio [19:00:16 CEST] <TD-Linux> JEEB, oh no this? http://www.nhk.or.jp/strl/publica/bt/en/fe0061-6.pdf [19:00:19 CEST] <JEEB> (which can mean anything) [19:00:44 CEST] <JEEB> TD-Linux: sounds like it [19:01:01 CEST] <JEEB> instead of trying to find a simple brochure I jumped straight at the specs tho [19:01:14 CEST] <JEEB> when someone mentioned that someone was trying to spec MMT [19:01:38 CEST] <JEEB> because when I last read about MMT it was just some kind of weird umbrella wrapper on top of ISOBMFF and HTML5 and whatever [19:02:40 CEST] <TD-Linux> JEEB, well MMTP isn't standardized yet, I don't think they can standardize things using it :) [19:02:41 CEST] <kierank> mmt is mental [19:03:07 CEST] <JEEB> TD-Linux: well the ARIB specs are official and out :P [19:03:19 CEST] <TD-Linux> ... [19:03:35 CEST] <TD-Linux> it's still a -00 draft https://datatracker.ietf.org/doc/draft-bouazizi-tsvwg-mmtp/ [19:04:30 CEST] <JEEB> http://www.arib.or.jp/english/html/overview/doc/2-STD-B60v1_3.pdf , http://www.arib.or.jp/english/html/overview/doc/2-STD-B32v3_3.pdf , http://www.arib.or.jp/english/html/overview/doc/2-STD-B10v5_5.pdf [19:04:34 CEST] <JEEB> related specs [19:04:43 CEST] <JEEB> (not in english albeit the url says something else) [19:05:09 CEST] <JEEB> also fun, MMTP has a separate spec [19:05:20 CEST] <JEEB> I was reading the MPEG-H MMT document [19:05:22 CEST] <JEEB> and just going WTF [19:06:51 CEST] <TD-Linux> JEEB, well I guess it's gotta be ready for the 2020 japan olympics no matter what [19:07:04 CEST] <TD-Linux> and RTP is only enterprise grade, not entertainment grade [19:10:34 CEST] <ubitux> wm4: you're kidding me, right? [19:10:36 CEST] <ubitux> :D [19:10:52 CEST] <wm4> ubitux: apparently not [19:25:45 CEST] <TD-Linux> JEEB, my favorite part of the NHK paper is apparently "applets" and "html5" can go inside MMT [19:25:52 CEST] <JEEB> yes [19:25:55 CEST] <wm4> wat [19:26:05 CEST] <JEEB> MMT has a shitload of stuff on HTML5 [19:26:28 CEST] <JEEB> it reeks like MPEG-4 [19:26:31 CEST] <JEEB> with the viewpoint stuff [19:26:47 CEST] <TD-Linux> is there some other MMT spec besides the internet draft? [19:26:55 CEST] <JEEB> http://mpeg.chiariglione.org/sites/default/files/files/standards/parts/docs… [19:27:05 CEST] <JEEB> this is the actual MMT spec's draft [19:27:17 CEST] <JEEB> it might be out as an actual spec but ENOTSURE if free [19:27:23 CEST] <JEEB> it's part 1 of MPEG-H [19:27:42 CEST] <JEEB> http://www.iso.org/iso/catalogue_detail.htm?csnumber=62835 [19:27:45 CEST] <JEEB> yeah, not free [19:27:58 CEST] <TD-Linux> oh I see, so the IETF draft is no longer the real standard [19:28:12 CEST] <JEEB> the IETF thing is MMTP [19:28:15 CEST] <JEEB> this is MMT [19:28:20 CEST] <JEEB> *enjoy* [19:28:47 CEST] <JEEB> and the draft doc shows MMT protocol as being defined by MMT [19:28:56 CEST] <wm4> so this is basically satan in form of a standard? [19:29:04 CEST] <TD-Linux> wait MMT is more than just MMTP protocol? [19:29:57 CEST] <kierank> MMT = MP4 + MPEGTS + MXF in one [19:29:57 CEST] <JEEB> MMT Protocol seems to be part 7.3 of MMT [19:29:58 CEST] <kierank> imagine that [19:30:11 CEST] <TD-Linux> oh shit [19:30:12 CEST] <JEEB> yes, that's the feeling I'm getting here [19:30:29 CEST] <j-b> kierank: oh boy [19:31:05 CEST] <TD-Linux> so MMTP implements a file sending feature like HTTP, now I know what it's for and I wish I didn't [19:31:45 CEST] <JEEB> yes, Assets [19:32:01 CEST] <TD-Linux> "RTCP has been used in wired network for long time but it has drawbacks when used in wireless networks." [19:32:20 CEST] <j-b> MMT is a demuxer or a protocol? [19:32:39 CEST] <JEEB> MMT contains a protocol [19:32:46 CEST] <TD-Linux> j-b, "MMTP" is a protocol that is very similar to RTP [19:33:24 CEST] <TD-Linux> RTP is basically a container for UDP or SCTP usage [19:33:43 CEST] <TD-Linux> well, MMTP actually contains .mp4 files, so it's like a meta container [19:34:58 CEST] <JEEB> MPUs, which are basically a sequence with at least one random access point [19:35:11 CEST] <JEEB> and which have to be decode'able from the beginning [19:35:19 CEST] <JEEB> so it's basically a GOP [19:35:30 CEST] <TD-Linux> I wonder how this maps into audio? [19:35:44 CEST] <JEEB> these can then be put into MFUs and thus multiple MMTP payloads [19:36:19 CEST] <TD-Linux> yeah okay so in the end it's basically the same as DASH fragments, but with extra packetization [19:36:36 CEST] <JEEB> seems quite similar, yes [19:37:04 CEST] <JEEB> probably to enable less than one GOP of latency [19:37:15 CEST] <JEEB> since you don't have to index the whole thing [19:37:35 CEST] <JEEB> although to be honest I haven't gotten that good of a grasp of it to be sure it's usable like that [19:38:50 CEST] <kierank> 6:32 PM <TD-Linux> "RTCP has been used in wired network for long time but it has drawbacks when used in wireless networks." [19:38:51 CEST] <kierank> ? [19:39:07 CEST] <kierank> really [19:39:19 CEST] <TD-Linux> kierank, it's apparently justification for defining their own feedback format, CLI [19:39:31 CEST] <TD-Linux> the advantage is that it's not encrypted and can be man in the middled [19:39:55 CEST] <TD-Linux> according to the MMT spec [19:43:41 CEST] <TD-Linux> CI is apparently not HTML5 but HTML "inspired", featuring such beautiful elements such as <divLocation>. They've also taken the liberty to reinvent all the layout rules from scratch [19:48:20 CEST] Action: J_Darnley chuckles at these streaming people. [19:48:39 CEST] <JEEB> not even streaming [19:48:42 CEST] <JEEB> this is broadcast [19:48:56 CEST] <JEEB> although at the point of using UDP/IP over broadcast I'm not really sure which it is [19:49:55 CEST] <J_Darnley> Streaming to me implies a live broadcast [19:52:33 CEST] <kierank> for me streaming usually means some kind of http/tcp thing [19:52:44 CEST] <kierank> one to one [19:52:49 CEST] <kierank> broadcast for me means one to many [20:01:48 CEST] <Daemon404> amusing ticket name [20:02:41 CEST] <TD-Linux> so the CLI thing stands for "Cross-Layer Interface" and actually has to be produced by the lower level hardware, aka the wifi access point or whatever. basically it includes what the lower level radio guesses the achievable bitrate to be, how many bit errors, etc. [20:03:45 CEST] <TD-Linux> it seems that MMT, despite using UDP, isn't really designed to work over the Internet, only over special purpose broadcast links, which I guess I should have expected but the usage of "UDP" and "HTML5" distracted me [20:04:00 CEST] <TD-Linux> also explains why they made their own version of HTTP [20:04:38 CEST] <JEEB> yeah [20:18:52 CEST] <durandal_1707> ubitux: what random? [20:21:02 CEST] <ubitux> durandal_1707: shufflesframes=random=3 would cause a random order for every 3 frames ([2 1 0] [0 2 1] [0 1 2] [1 2 0] ...) [20:22:18 CEST] <ubitux> i thought the purpose of the filter was to create discontinuities in order to fuzz muxers/filters/codecs? [20:22:32 CEST] <ubitux> so maybe make it as unpredictable as possible [20:23:31 CEST] <durandal_1707> no, you have random filter for that [20:24:59 CEST] <durandal_1707> this one is to provide selectEvery feature from avisynth [20:27:04 CEST] <J_Darnley> Why would not not call it SelectEvery then? [20:27:56 CEST] <ubitux> because we're smarter @_@ [20:28:22 CEST] <ubitux> durandal_1707: does it has a use select can not cover? [20:31:46 CEST] <durandal_1707> you can not use select to shuffle/reorder frames [20:33:36 CEST] <durandal_1707> is there expression that accepts list as argument? [20:35:46 CEST] <durandal_1707> if one need to delete specific frames, using expr for this is pita [20:38:05 CEST] <ubitux> it's actually pretty easy [20:38:38 CEST] <ubitux> (to drop) [20:38:41 CEST] <ubitux> but i'm curious about the use case of shuffling and reordering frames [20:39:44 CEST] <J_Darnley> A broken video which was bob deinterlaced using the wrong order by a complete moron. [21:03:40 CEST] <durandal_1707> ubitux: user from #mpv [21:06:05 CEST] <durandal_1707> some Chinese from vs and avs are following me on twitter [21:16:39 CEST] <llogan> Outreachy is now "additionally open to residents and nationals of the United States of any gender who are Black/African American, Hispanic/Latin@, American Indian, Alaska Native, Native Hawaiian, or Pacific Islander." [21:17:43 CEST] <llogan> that means i qualify for fraud...i mean participation. [21:23:20 CEST] <Zeranoe> So what licenese does FFmpeg need to be compiled with for OpenSSL? Relivant configure line: enabled gpl && die_license_disabled_gpl nonfree openssl [21:23:43 CEST] <rcombs> --enable-nonfree [21:23:48 CEST] <rcombs> i.e. nonredistributable [21:24:10 CEST] <Zeranoe> rcombs: How is that different than: die_license_disabled nonfree libfaac [21:26:04 CEST] <rcombs> Zeranoe: just a different warning [21:26:15 CEST] <llogan> Zeranoe: while you're here, can you delete these? https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=1395#p6061 and https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=846#p5212 [21:26:36 CEST] <llogan> more Chinese GPL violating spammer shitsoft [21:26:41 CEST] <Zeranoe> llogan: I'd be happy to, not sure how those slipped in [21:26:49 CEST] <llogan> thanks [21:28:39 CEST] <Zeranoe> llogan: All taken care of. Thank you [21:29:08 CEST] <llogan> i put word censoring on the gusari forum. more for my amusement than anything (they get deleted quickly). so idealshare becomes iDealshit or similar. [21:36:37 CEST] <cone-732> ffmpeg 03Timothy Gu 07master:bc22cd244e4c: dnxhdenc: Optimize get_pixels_8x4_sym for 10-bit [21:43:08 CEST] <llogan> i love seeing console outputs from gentoo users [23:10:00 CEST] <Gramner> sigh @ that android 6.0 decision [23:13:18 CEST] <Gramner> i'd personally say it's working as intended and a workaround is to either use x86-64 or a less silly OS [23:19:35 CEST] <J_Darnley> What does any of that even mean? [23:23:35 CEST] <Gramner> doing PIC on 32-bit x86 is annoying because there's no rip-relative addressing unlike x86-64. it's simply easier to use relocations instead which also results in faster code. relocations does increase startup time by some milliseconds and requires duplicating some memory if you have multiple instances of the same .so though, but that's an ok tradeoff imo [23:24:10 CEST] <nevcairiel> Seems like stupid idea to force ban them [23:24:17 CEST] <Gramner> and for some unknown reason GOOG decided to start throwing an error in android 6.0. when loading a .so that contains textrels [23:28:06 CEST] <J_Darnley> That was a wonderful explaination so I'm sorry for wasting your time writing it. I don't know what PIC is either. [23:28:32 CEST] <Gramner> position-independent code [23:36:44 CEST] <Gramner> when you load a library you want to load it a a random starting address (due to ASLR for security issues but also to avoid address space conflicts with other libraries). you can either do this with PIC (where static memory accesses are relative to something, often the current instruction pointer) or with relocations (where static memory addresses are kept in a list and updated when you [23:36:45 CEST] <Gramner> load the library) [23:41:28 CEST] <Gramner> PIC is fine and dandy on archs such as x86-64 that has an instruction pointer-relative addressing mode where you can simply define static addresses as an offset from the current instruction, but 32-bit x86 doesn't have that so you basically need to use annoying hacks to be able to get the instruction pointer in a register so you can do loads explicitly relative to that register [23:42:59 CEST] <iive> you don't need to get the instruction pointer, you just have a pointer that holds the address of the heap data [23:43:13 CEST] <Gramner> well that works too [23:43:20 CEST] <iive> just data. [23:43:40 CEST] <Gramner> data with a known offset to the data you want [23:44:28 CEST] <J_Darnley> ah, security related stuff that I don't really care to understand [23:44:34 CEST] <iive> but the point still stands, you need to use a general purpose register for that. [23:44:39 CEST] <J_Darnley> "both a payroll program and an accounts receivable program built to run at address 32K could not both be run at the same time" - Wikipedia. [23:44:50 CEST] <J_Darnley> I want to go back to those days. [23:45:05 CEST] <Gramner> in C the compiler handles this of course, but in asm you need to do a bnuch of special casing for it. it's also slower (the additional register certainly doesn't help when x86 is register-starved as it is) [23:45:07 CEST] <iive> i think we are already there [23:45:23 CEST] <iive> you don't have segmentation in 64bit mode :) [23:45:41 CEST] <Gramner> you can do limited segmentation in 64-bit mode [23:46:09 CEST] <J_Darnley> When I say I want to go back to those days I mean that literally. [23:46:15 CEST] <Gramner> iirc some stack protection mechanisms can use that to have safe and unsafe stacks and whatever [23:46:20 CEST] <iive> yes, but the address space is global, [23:46:22 CEST] <J_Darnley> I want an amber or green crt. [23:46:44 CEST] <iive> so you can have only one program at address 32k [23:46:48 CEST] <J_Darnley> I want transistors you can see [23:47:11 CEST] <J_Darnley> I want things to be slow [23:48:11 CEST] <Gramner> go build a basic cpu in minecraft then [23:52:43 CEST] <iive> Gramner: indeed, i've heard people have done such things [23:54:28 CEST] <Gramner> yeah, tons of youtube videos of stuff like that [00:00:00 CEST] --- Wed Oct 21 2015

1 0

ffmpeg.log.20151020
by burek 21 Oct '15

21 Oct '15

[00:02:08 CEST] <maletor> can i use ffmpeg for passthrough audio to my audio card? [01:16:15 CEST] <Wader8> https://trac.ffmpeg.org/ticket/4947 [08:30:37 CEST] <inflex> Trying to find documentation on "invalid argument#012" return code from av_interleaved_write_frame() call, can't seem to find that particular one [08:45:48 CEST] <inflex> ah, looks like the calling program was stuffing the trailing end of the error, so the actual ffmpeg error is just "invalid argument".... now to wonder which argument :\ [08:46:20 CEST] <Wader8> morning [08:47:43 CEST] <inflex> morn [08:50:41 CEST] <Wader8> any devs here could fix this quickie https://trac.ffmpeg.org/ticket/4947 [08:51:28 CEST] <Wader8> but anyway I seem to be having an issue with one of DVDs im trying to convert (to put it for archival into 1 file x264 or hevc) [08:52:12 CEST] <Wader8> mediainfo seems to report that the framerate is 23.9 and progressive, but then it says scan order is 2:3 pulldown [08:52:25 CEST] <JEEB> the message comes from x264/5 not ffmpeg [08:52:57 CEST] <JEEB> your key/value list is just passed one by one to the library [08:53:56 CEST] <Wader8> and when i finally did the proper inverse telecine command I got 19 FPS so something's not right with mediainfo [08:54:39 CEST] <Wader8> is there any way to do a deep scan to get actual video details ? [08:55:00 CEST] <Wader8> jeeb: so ffmpeg guys can't do anything about it, weird ? [08:55:39 CEST] <JEEB> ok, not true for x265, although the mrssage is correct [08:55:51 CEST] <JEEB> unknown option :p [08:56:29 CEST] <Wader8> I just think it's natural for it to be an error and stop, I hope some of the devs feel that way [08:57:13 CEST] <JEEB> as for if it should be fatal or not is more towards a thing ffmpeg could decide on [08:58:40 CEST] <Wader8> well last time the devs also agreed https://trac.ffmpeg.org/ticket/4015 [09:13:02 CEST] <Wader8> hej jeeb is this true, there's no such thing as "MPEG-2 Program Stream" so if i pick "-f mpeg" or "-f vob" it won't say MPEG2, but if I use "-f mpegts" it will say "MPEG2 Transport Stream" in metadata [09:13:24 CEST] <Wader8> also, "-f mpegps" doesn't exist [09:13:35 CEST] <Wader8> https://ffmpeg.org/pipermail/ffmpeg-user/2012-March/005713.html [09:39:16 CEST] <Wader8> seems like some kind of a soft pulldown or something, im not sure if mediainfo is right or wrong, the windows7 details shows the file as 29 fps, but fraps shows 24 [09:39:17 CEST] <Wader8> http://ffmpeg-users.933282.n4.nabble.com/Detecting-24-FPS-pulldown-in-MPEG-… [09:39:35 CEST] <Wader8> the DVD is 23,9 progressive with 2:3 pulldown of some sort [09:40:07 CEST] <Wader8> unfortunately the old command -show_streams in ffprobe doesn't work anymore so i need to find that [09:41:34 CEST] <Wader8> but looks like someone already got an issue with this weird progressive pulldown and found out just setting -vf fps=24000/1001 fixes the pulldown without duplicated frames. [09:45:43 CEST] <satiender> Hi , which is best choice between dynamic linking or static linking [09:47:01 CEST] <satiender> when I am using ffmpeg api in my c program after compilation my ELF file size is 74 MB and that progam just show the metadata only [09:48:11 CEST] <luc4> Hello! Any idea how to access the constant CBCentralManagerScanOptionAllowDuplicatesKey from CBCentralManager from swift? [09:48:19 CEST] <satiender> My question is that suppose we are using any lib dynamic or static in our c program [09:49:07 CEST] <satiender> if I use only few functions of that lib then my program size is less or not [09:49:43 CEST] <satiender> I mean my program include whole static lib or only those function which I am calling or using [09:50:03 CEST] <satiender> please give me some accurate ans [09:50:06 CEST] <satiender> thanks [09:50:10 CEST] <satiender> ?? [09:53:15 CEST] <satiender> hi' [09:59:44 CEST] <luc4> satiender: configure ffmpeg to build only what you need [10:01:24 CEST] <satiender> luc4 : Thanks for reply [10:01:45 CEST] <satiender> Actually I compiled ffmpeg for android os [10:02:09 CEST] <satiender> I compiled it , and make .so and .a files [10:02:33 CEST] <satiender> Now I am using these libs in my C program [10:03:08 CEST] <satiender> And my question is that which one I can use for decrease the size of my exec [10:03:22 CEST] <satiender> luc4 : ?? [10:03:34 CEST] <luc4> satiender: then you need to rebuild for ios and disable everything you dont need during configure. [10:04:14 CEST] <satiender> luc4 : I think you not understand my issue [10:04:23 CEST] <satiender> My question is very simple [10:05:06 CEST] <satiender> Which lib is more better for decrease the size of my program static or dynamic [10:06:19 CEST] <satiender> Suppose I link static and I use only two functions of that static lib then my program include whole lib or only those two functions [10:06:20 CEST] <satiender> ?? [10:09:01 CEST] <luc4> Im sorry, I confused your question with another one. I thought you were talking about ios sorry :-) what makes a difference is if you disable the code you dont need in ffmpeg. However you can probably ask the compiler and linker to exclude the code you dont use: http://stackoverflow.com/questions/13525889/does-gnu-ld-link-in-whole-objec…. [10:15:36 CEST] <satiender> luc4 : on its ok bro and thanks for reply [10:15:48 CEST] <satiender> luc4 : I see your given link [10:16:30 CEST] <satiender> and I compile my code according to that given link but there have no change the size is same [10:16:33 CEST] <satiender> :( [10:47:20 CEST] <hero_biz> hi all [10:48:43 CEST] <hero_biz> a question. is every codec that is shown with ffmpeg -codecs command will be supported when I use ffmpeg? [10:49:43 CEST] <martijnb> it depends on what you mean by supported [10:50:07 CEST] <hero_biz> i mean can I use that codec? [10:50:11 CEST] <c_14> hero_biz: If it has a 'D' you can decode it, if it has an 'E' you can encode it. [10:50:25 CEST] <martijnb> those are the codecs that your ffmpeg version has [10:51:00 CEST] <martijnb> the letters in front of it, show what is supported using that codec [10:51:20 CEST] <hero_biz> i mean is it possble that some codec caannot be used based on compiling options even though it is listed here? [10:52:12 CEST] <c_14> hero_biz: read my message [10:52:17 CEST] <hero_biz> because I want to convert a pgs sub to ass, using ffmpeg -i a.mkv a.ass, but I get an error says: only ASS_SUBTITILE is supported. [10:52:34 CEST] <hero_biz> even though pgs sub is listed in ffmpeg -codecs [10:52:34 CEST] <c_14> pgs are image subtitles [10:52:36 CEST] <c_14> ass are text subtitles [10:52:54 CEST] <c_14> You'll have to OCR them first. [10:53:28 CEST] <hero_biz> @c_14, but it seems some tools like subtitle edit should be able to convert them. [10:53:57 CEST] <c_14> If they have an OCR, sure. [10:54:16 CEST] <c_14> If you build ffmpeg with tesseract, it can do ocr (though it outputs plain text and not subtitles iirc). [10:57:08 CEST] <hero_biz> how can i check if ffmpeg is built with tesseract? --version shows? [10:57:18 CEST] <c_14> -version [10:58:12 CEST] <hero_biz> what will be lib name? O.O [10:58:29 CEST] <hero_biz> libavutil 52. 18.100 / 52. 18.100 [10:58:29 CEST] <hero_biz> libavcodec 54. 92.100 / 54. 92.100 [10:58:29 CEST] <hero_biz> libavformat 54. 63.104 / 54. 63.104 [10:58:29 CEST] <hero_biz> libavdevice 54. 3.103 / 54. 3.103 [10:58:29 CEST] <hero_biz> libavfilter 3. 42.103 / 3. 42.103 [10:58:29 CEST] <hero_biz> libswscale 2. 2.100 / 2. 2.100 [10:58:29 CEST] <hero_biz> libswresample 0. 17.102 / 0. 17.102 [10:58:46 CEST] <c_14> Look at the configure command [10:58:53 CEST] <c_14> there should be an --enable-libtesseract [10:59:03 CEST] <c_14> And if you paste more than 3 lines please use a pastebin service. [10:59:05 CEST] <hero_biz> oh,then not supported [10:59:11 CEST] <hero_biz> ok,sry [10:59:13 CEST] <hero_biz> :) [11:00:01 CEST] Action: hero_biz wonders what I should do with these 120MB subtitles... [11:03:34 CEST] <hero_biz> if I rebuild a newer version of ffmpeg, will it replace older version when I use 'make install'? [11:04:38 CEST] <c_14> I wouldn't bet on it. [11:46:31 CEST] Action: hero_biz wonders how I can uninstall ffmpeg in order to installing newer version without 'make uninstall' [11:58:36 CEST] <BtbN> By not using "sudo make install" in the first place. [11:58:45 CEST] <BtbN> Use a prefix somewhere in your home [12:01:52 CEST] <claz> hero_biz: just to make install, it usually works [12:02:12 CEST] <claz> it's not the best way to do it but it's too late now [12:14:54 CEST] <zhanshan> hi [12:18:43 CEST] <zhanshan> I got this command line and need to combine right channel with left channel for video output. Thanks in advance! [12:18:48 CEST] <zhanshan> see: https://paste.debian.net/hidden/0bf90947/ [12:18:55 CEST] <zhanshan> what would be the command line for that? [12:41:24 CEST] <zhanshan> I got it from https://trac.ffmpeg.org/wiki/AudioChannelManipulation [12:41:33 CEST] <zhanshan> just gonna do it in two steps.. [12:56:45 CEST] <xsi> ffmpeg -f alsa -ac 2 -i hw:0,0 -f x11grab -framerate 30 -video_size 1280x1024 -i :0.0+0,0 -vcodec libx264 -preset veryfast -maxrate 1984k -bufsize 3968k -vf "format=yuv420p" -g 60 -acodec libmp3lame -b:a 96k -ar 44100 -f flv [12:57:34 CEST] <xsi> Sorry-sorry this is working but the sound isn't what to do, because each attemps in first learning fails in expe [13:26:16 CEST] <xsi> There are some numbers and letters after audio: man ffmpeg can't find what is -b because . -b is after sound [13:31:29 CEST] Action: hero_biz wonders if anyone can converts 6 pgs subtitles to srt for me.... [13:36:25 CEST] <anYc> benbro: could you apply this patch https://bpaste.net/show/3ea3ab0b0923 and send me the output? [13:44:16 CEST] <hero_biz> is there anyone anyone who can converts 6 pgs subtitles to srt for me? :P [13:49:46 CEST] <JEEB> no, OCR them yourself [14:13:24 CEST] <waressearcher2> anyone here ? [14:14:02 CEST] <durandal_1707> No [14:14:14 CEST] <waressearcher2> anyone else ? [14:14:19 CEST] <spaam> No [14:14:23 CEST] <durandal_1707> No [14:19:27 CEST] <DHE> absolutely not [14:22:12 CEST] <hero_biz> guys, when I try to compile ffmpeg again, I don't see an --enable-libtesseract option to enable in configure(for OCRing pgs subtitles into srt ones). [14:22:16 CEST] <hero_biz> any idea why? [14:29:20 CEST] <waressearcher2> now ? [14:29:43 CEST] <waressearcher2> I use that command: "ffmpeg -i file.avi -vn -ac 2 -ar 44100 -ab 320k -y -f wav file.wav" and this is the last few lines of output of encoding: http://sprunge.us/GcDb, what does those lines means: "[mp3 @ 0x808dc00] overread, skip -7 enddists: -4 -4s/s" ? does that mean I lose some data ? [14:30:03 CEST] <waressearcher2> [mp3 @ 0x808dc00] overread, skip -7 enddists: -4 -4s/s [14:30:11 CEST] <waressearcher2> is something wrong ? [14:30:16 CEST] <waressearcher2> how serious is it [14:31:31 CEST] <voice> what happens when you add -c:a libmp3lame? [14:32:19 CEST] <c_14> hero_biz: your version of ffmpeg is too old [14:32:54 CEST] <waressearcher2> voice: I don't know, haven't tryed it [14:32:57 CEST] <waressearcher2> why [14:33:28 CEST] <hero_biz> @c_14: I'm trying to compile latest version of ffmpeg. [14:33:42 CEST] <c_14> hero_biz: you need the git version [14:33:50 CEST] <c_14> It's not in a release yet. [14:33:53 CEST] <hero_biz> @c_14: should I enable anything special in ./configure for it? [14:34:00 CEST] <hero_biz> <.< [14:34:26 CEST] <hero_biz> oh,it is still not avilable in 2.8.1? [14:34:36 CEST] <voice> nvm, waressearcher2, its still early here, haven't finished my first cup of coffee yet [14:37:21 CEST] <waressearcher2> is there a way to set default settings ? [14:38:21 CEST] <hero_biz> yea,found it git version... [14:38:26 CEST] <waressearcher2> like for audio bitrate its always "128kb" right ? so I have to use "-ab 192kb" to get 192 bitrate, how to make it default ? [14:38:34 CEST] <voice> well, as far as I know, wav doesn't do bitrates [14:38:43 CEST] <voice> at least in that fashion [14:39:00 CEST] <waressearcher2> or how to make it "-vb 10000kb" by default ? [14:47:50 CEST] <sor_> when i trim a video like .. ffmpeg -ss 12 -i session-mix.avi -t 120 -c:v copy -c:a copy session-mix-trim.avi -- it stutters at the end ... how can i fix this [14:53:05 CEST] <waressearcher2> sor_: if you reencode instead of copying it doesn't stutters ? [14:53:40 CEST] <sor_> waressearcher2, yes it does [14:54:17 CEST] <sor_> waressearcher2, i tried various formats [15:10:58 CEST] <theeboat> hello, I am having an issue with the frame rate in two containers. I am using -codec copy -top 1, the source is h264, 1080i, 25fps, 25k. When I output this into a ts file ffprobe shows the file is 25 fps, 50 tbr, 90k tbn, 50 tbc, when i do the same into a mov it shows the following 50 fps, 50 tbr, 90k tbn, 50 tbc (default) [15:14:59 CEST] <xsi> is there a channel for newbie help? i'd want to ask a question on a topic from which place to start when i have working parameters but my sound is garbled? [15:17:06 CEST] <anYc> sor_: if you have some spare time and the video uses h264, could you check if it works with https://github.com/anyc/avcut ? [15:23:33 CEST] <arpu> hello what is the best way to transfer vp9 opus live stream from user to a mediaserver ? rtmp does not work with vp9 right? [15:33:38 CEST] <benbro> anYc: ./avcut/avcut test.mp4 out.mp4 258 318 > test.txt [15:33:44 CEST] <benbro> anYc: https://drive.google.com/file/d/0B12AhxvnYHrAbjZ3OFJTWjA2LUE/view?usp=shari… [15:34:10 CEST] <benbro> anYc: the avcut log you asked for [15:36:06 CEST] <anYc> uh, 136 mb :) thank you! [15:36:23 CEST] <anYc> 880 mb uncompressed 8) [15:36:44 CEST] <anYc> did you enable the debug flag? [15:40:23 CEST] <theeboat> hello, I am having an issue with the frame rate in two containers. I am using -codec copy -top 1, the source is h264, 1080i, 25fps, 25k. When I output this into a ts file ffprobe shows the file is 25 fps, 50 tbr, 90k tbn, 50 tbc, when i do the same into a mov it shows the following 50 fps, 50 tbr, 90k tbn, 50 tbc (default) [15:41:05 CEST] <arpu> oh i see vp89 works with -f webm and rtmp ! cool [15:41:10 CEST] <arpu> vp9 sorry [15:47:43 CEST] <benbro> anYc: I've applied your patch [15:47:50 CEST] <benbro> anYc: don't know about debug flag [15:55:36 CEST] <sor_> anYc, <builtin>: recipe for target 'avcut' failed make: *** [avcut] Error 1 [15:57:04 CEST] <xsi> no sound [15:57:10 CEST] <xsi> no help [16:22:56 CEST] <CristianC> Hello guys and girls! I'm trying to compile ffmpeg with libvpx using the latest git sources but i seem to be running into a issue with libvpxenc.c. The output of make is at http://pastebin.com/fqjVLPKg Has anyone seen this before? [16:23:58 CEST] <BtbN> looks like your version of libvpx is too old or too new. [16:24:15 CEST] <BtbN> I'd guess it's too old, but i have no idea if they break API on updates. [16:24:29 CEST] <CristianC> i just pulled it today from the git :-/ wierd [16:24:47 CEST] <BtbN> ffmpeg is also up-to-date? [16:25:02 CEST] <CristianC> yup, pulled it right now from git [16:25:51 CEST] <BtbN> Well, either you don't point it to your libvpx correctly, it they indeed did break the API [16:26:01 CEST] <BtbN> Or you didn't configure libvpx correctly, if that's posible. [16:26:19 CEST] <CristianC> Been looking at the latest commit, 12 hours ago https://chromium.googlesource.com/webm/libvpx/+/849e54cedd5efbd0841b32a757c… [16:26:49 CEST] <CristianC> seems to be removing some declarations, close to the problem i'm experiencing, will try to pull the build before that [16:34:01 CEST] <anYc> benbro: hm ok, unfortunately, I might need a sample file. the packet-frame matching seems to work for a long time until this GOP and I even can't find a matching myself. could you paste the output of "ffprobe -f csv -show_packets -select_streams v $myfile"? [16:35:15 CEST] <anYc> sor_: ok thanks, there should be an actual error message before this line. maybe you don't have the -dev packages installed. [16:36:41 CEST] <sor_> anYc, I run LFS no dev packages [16:40:04 CEST] <sor_> anYc, I am on my way out i will play with it later -- cheers [17:47:15 CEST] <benbro> anYc: https://drive.google.com/file/d/0B12AhxvnYHrASi1Nb2E3XzE3MVE/view?usp=shari… [18:36:17 CEST] <anYc> benbro: thanks, avcut is missing the last two frames of the video and I fail to imagine why they are not there. I will try some videos to see if I can reproduce this [19:15:30 CEST] <anYc> benbro: ok, found a file with the same error [19:28:29 CEST] <benbro> anYc: cool [20:53:38 CEST] <GILFHound69> heya [20:53:54 CEST] <GILFHound69> I'm having trouble streaming an mp4 file to RTMP [20:54:01 CEST] <GILFHound69> This is the command im using [20:54:17 CEST] <GILFHound69> ffmpeg -re -i "/var/lib/transmission-daemon/downloads/file.mp4" -c:v copy -c:a copy -f flv "rtmp://GILFHOUND:passhere@107.191.102.75/live/stream" [20:54:49 CEST] <GILFHound69> auth is fine now, and it says its streaming something, but nothing comes up on stream [20:55:03 CEST] <GILFHound69> Can anyone help? What command should I be using? [21:10:01 CEST] <wyatt8740> RTMP is black magic to me... I have no clue. [21:10:54 CEST] <GILFHound69> Damnit [21:11:58 CEST] <wyatt8740> I could never get rtmpdump to work, either... [21:12:20 CEST] <GILFHound69> I can get it to stream my desktop fine [21:12:37 CEST] <GILFHound69> But I'm streaming torrented anime from a VPS [21:12:39 CEST] <c_14> Are the audio/video settings acceptable? [21:12:59 CEST] <GILFHound69> c_14 I dont know thats what im trying to get help with [21:13:10 CEST] <c_14> ffprobe file.mp4 [21:13:14 CEST] <GILFHound69> sec [21:13:15 CEST] <c_14> And upload to a pastebin site [21:14:34 CEST] <GILFHound69> running it now [21:16:45 CEST] <GILFHound69> Sec, gotta install ffprobe. Apparently it didnt get installed. I built it from source [21:17:09 CEST] <c_14> You can also use ffmpeg -i file.mp4; gives mostly the same output [21:17:21 CEST] <c_14> Or just the output from the command you were running is usually enough [21:17:36 CEST] <GILFHound69> sec [21:17:40 CEST] <GILFHound69> I'll grab it [21:20:29 CEST] <GILFHound69> https://ghostbin.com/paste/9gjg6 [21:20:35 CEST] <GILFHound69> Thats from one of the files that didnt work [21:20:40 CEST] <GILFHound69> Let me run the one that did [21:22:37 CEST] <GILFHound69> oh [21:22:39 CEST] <GILFHound69> well shit [21:22:44 CEST] <GILFHound69> now its not working [21:23:04 CEST] <c_14> That's a good start. [21:23:17 CEST] <GILFHound69> sec [21:27:04 CEST] <GILFHound69> okay [21:27:05 CEST] <GILFHound69> my bad [21:27:26 CEST] <GILFHound69> Alright give me a sec and I'll give you the output of the one that said it streamed [21:27:35 CEST] <GILFHound69> I just renamed it to something else to avoid the problem [21:28:53 CEST] <GILFHound69> c_14 https://ghostbin.com/paste/hzd4p [21:28:57 CEST] <GILFHound69> That should be alot more info [21:31:24 CEST] <c_14> Can't really see any differences besides the samplerate and colorspace. [21:31:49 CEST] <c_14> What if you get rid of the c copys on the non-working command? [21:31:50 CEST] <GILFHound69> first one I fucked up [21:31:58 CEST] <GILFHound69> cd /var/lib/transmission-daemon/ on the end [21:32:05 CEST] <GILFHound69> was cding into another dir before and fucked it up [21:32:51 CEST] <GILFHound69> Second one is the usual output [21:33:01 CEST] <GILFHound69> says its streaming but nothing shows up on the stream [21:33:17 CEST] <thasp> Where could I find documentation on parameters for -c:v dnxhd? I can't find it in the standard manual. [21:33:40 CEST] <c_14> ffmpeg -h encoder=dnxhd [21:34:20 CEST] <thasp> thank you c_14! [21:34:54 CEST] <thasp> how would dnxhd come out compared to libx264 qp=1 with high profile? [21:35:19 CEST] <thasp> I have been using libx264=1 with high profile for microscopy recordings but editing is difficult if not impossible on most hardware. [21:35:30 CEST] <GILFHound69> c_14 so try removing the -c:v copy -c:a copy [21:35:32 CEST] <GILFHound69> ? [21:35:36 CEST] <c_14> ye [21:36:37 CEST] <c_14> thasp: no clue. Have you tried something made for editing like utvideo or prores? [21:37:04 CEST] <thasp> i haven't, i've just been using openbroadcaster to record a camcorder and microscope camera to libx264 so far [21:37:21 CEST] <thasp> i am debatign switching to prores of dnxhd but i am afraid of quality loss if i am going to be blowing up specific frames for use later [21:37:42 CEST] <furq> thasp: are you using -tune fastdecode [21:37:46 CEST] <thasp> furq: yes [21:38:04 CEST] <thasp> furq: it is usable but still owns most machines you try to edit on, even six core haswell [21:38:10 CEST] <thasp> with a PCIE ssd [21:54:24 CEST] <GILFHound69> Hey guys [21:54:32 CEST] <GILFHound69> c_14 it was a server-side issue [21:54:40 CEST] <GILFHound69> talked to the host and she fixed it [22:27:28 CEST] <grzegorzs> Hi [22:29:04 CEST] <grzegorzs> i need help, i've tried install ffmpeg on centos. Unoftunately final step ( compile ffmpeg) throw error: [22:29:09 CEST] <grzegorzs> libavcodec/libvpxenc.c:730: warning: coded_frame is deprecated (declared at libavcodec/avcodec.h:2880) [22:29:10 CEST] <grzegorzs> libavcodec/libvpxenc.c:730: warning: error is deprecated (declared at ./libavutil/frame.h:290) [22:29:10 CEST] <grzegorzs> libavcodec/libvpxenc.c:731: warning: coded_frame is deprecated (declared at libavcodec/avcodec.h:2880) [22:29:11 CEST] <grzegorzs> libavcodec/libvpxenc.c:731: warning: error is deprecated (declared at ./libavutil/frame.h:290) [22:29:13 CEST] <grzegorzs> make: *** [libavcodec/libvpxenc.o] Error 1 [22:29:45 CEST] <grzegorzs> do you have any idea what's going on with this. Ofcourse i've installed libvpx [22:29:51 CEST] <JEEB> no errors there [22:29:55 CEST] <JEEB> only warnings [22:30:05 CEST] <JEEB> so if you have a warning it's somewhere before that [22:30:11 CEST] <JEEB> time for a pastebin :P [22:30:15 CEST] <JEEB> not pasting on the channel [22:31:41 CEST] <grzegorzs> sorry for pasted text. Last line finished with Error 1 [22:32:54 CEST] <JEEB> yes, but there's a reason for that error which is somewhere else in that log [22:33:04 CEST] <JEEB> thus use a pastebin and post the whole darn thing [22:33:10 CEST] <JEEB> and link here [22:33:35 CEST] <grzegorzs> ok, give me a sec [22:34:58 CEST] <grzegorzs> http://pastebin.pl/view/3a88141c [22:35:52 CEST] <JEEB> wrapper/library version mismatch [22:36:06 CEST] <JEEB> either too old libvpx or too old FFmpeg [22:37:27 CEST] <grzegorzs> hmm quite strange all downloaded from repo [22:41:57 CEST] <grzegorzs> any other idea ? [22:54:10 CEST] <grzegorzs> @JEEB thx, i'm looking for deeper. [23:19:07 CEST] <anYc> sor_: I think I fixed the issue with the latest commit. If you're still interested, let me know if it worked for you! [23:52:27 CEST] <sor_> anYc, same thing let me try on another box [00:00:00 CEST] --- Wed Oct 21 2015

1 0

ffmpeg-devel.log.20151019
by burek 20 Oct '15

20 Oct '15

[00:20:46 CEST] <JEEB> durandal_170: < anon32> http://pastebin.com/ga4dak90 <-- can somebody forward this to the durandal dude? [00:26:13 CEST] <ubitux> durandal_170: so you are relying on the fact that every input frame is cloned (and thus has data aligned) in w3dif? [00:26:21 CEST] <ubitux> w3fdif* [00:26:55 CEST] <ubitux> (i was curious how sth like crop=x=1,w3fdif seemed to work even with mova [00:26:57 CEST] <ubitux> ) [00:28:04 CEST] <durandal_170> nonsense, I will not change -1 to int_min, whatever if value is reserved or not [00:29:26 CEST] <durandal_170> ubitux: workline is always aligned [00:29:59 CEST] <ubitux> but because of the av_frame_clone() [00:31:02 CEST] <cone-384> ffmpeg 03Clément BSsch 07master:ce0a117ed4f9: avutil/opt: display a better default value for int/int64 options [00:32:17 CEST] <ubitux> heh i should have use ffmpeg -h filter=showfreqs as an example, it's more obvious [00:41:44 CEST] <durandal_170> ubitux: no, movh is used for input and output [00:43:35 CEST] <kierank> do I need to align variables on the stack [00:44:12 CEST] <Gramner> stack is aligned to mmsize (assuming you allocate it through cglobal) [00:44:58 CEST] <kierank> I mean if I have dwords on the stack, is there a benefit to aligning them to mmsize for example? [00:45:02 CEST] <kierank> not mm [00:45:06 CEST] <kierank> the gpr size i mean [00:45:39 CEST] <Gramner> you only need to align elements to their native sizes [00:45:45 CEST] <Gramner> so 4 bytes for dwords [00:57:54 CEST] <rcombs> https://gist.github.com/16e91a2c04c541b9014f here have a(n incomplete) matroska thing [01:02:51 CEST] Action: rcombs looks at ubitux and wm4 [01:21:29 CEST] <wm4> yeah, that's an approach which a much older patch also tried [01:28:24 CEST] <atomnuker> kierank: would you mind installing autotools (autoreconf & the rest) on avdev? [01:28:45 CEST] <Timothy_Gu> what is avdev? [01:31:31 CEST] <kierank> it is a development machine I setup [01:32:02 CEST] <kierank> atomnuker: done [01:35:33 CEST] <Timothy_Gu> kierank: ok [01:35:44 CEST] <kierank> if you want access let me know [01:37:01 CEST] <atomnuker> kierank: thanks [01:43:14 CEST] <wm4> rcombs: if it can be made work in all cases, I'm looking forward to dropping mpv's mkv demuxer [01:43:22 CEST] <rcombs> wm4: I'm thinking of sending AV_PKT_DATA_NEW_EXTRADATA when making a segment switch [01:43:42 CEST] <wm4> rcombs: it should be possible, because lavfilter uses the same approach by reusing haali's demuxer [01:43:59 CEST] <wm4> yeah, something like this [01:44:25 CEST] <rcombs> I should look further into what mpv's does for that sort of case [01:44:37 CEST] <rcombs> right now I'm not stream matching at all [01:44:47 CEST] <rcombs> which means if the streams don't match all sorts of bad things can happen [01:46:00 CEST] <rcombs> I'd expect I want to run find_stream_info when a file's UID matches, then check stream codec count and IDs [01:46:17 CEST] <rcombs> export any non matching attachments [01:46:57 CEST] <rcombs> and if the external segment has extra non-attachment streams, drop packets from them [01:47:13 CEST] <wm4> you should do what haali does [01:47:28 CEST] <rcombs> also, scanning for potential segments takes longer than in mpv and I'm not sure why, so I'll need to look into that [01:47:41 CEST] <rcombs> probably extra demuxer overhead I can disable [01:47:50 CEST] <wm4> well, mpv just scans the ebml elements at th start, and gives up as soon as possible [01:48:09 CEST] <wm4> maybe you'll have to open and parse the file separately for scanning [01:48:16 CEST] <rcombs> could be [02:06:27 CEST] <rcombs> wm4: where's the relevant haali code anyway [02:07:31 CEST] <JEEB> I'd rather look at nev's code than Haali's at this point [02:08:21 CEST] <JEEB> http://git.1f0.de/gitweb?p=ffmpeg.git;a=blob;f=libavformat/matroskadec_haal… [02:08:47 CEST] <rcombs> also I don't allow recursion at all [02:08:50 CEST] <JEEB> and then that is abused by the LAV Splitter to then use all of the stuff [02:09:00 CEST] <rcombs> which is probably fine since it's compatible with haali [02:09:53 CEST] <wm4> yeah, that code [02:11:12 CEST] <rcombs> also, is there any way to name an edition? [02:12:19 CEST] <JEEB> as far as I can tell, yes [02:12:28 CEST] <JEEB> http://cccp-project.net/beta/test_files/%5bMKV%5d_Editions,_Linked_Segments… [02:12:37 CEST] <JEEB> http://cccp-project.net/beta/test_files/%5bMKV%5d_Editions_Sample.mkv [02:12:40 CEST] <JEEB> for two samples [02:12:41 CEST] <wm4> via tags afaik [02:12:52 CEST] <rcombs> of course it's tags [02:58:13 CEST] <wm4> ubitux: remember the mp4 EDL stuff, where we were thinking about implementing it on the demuxer level? one problem was that we'd have overlapping packet DTS... but maybe this is quite simple to solve with some sort of discontinuity flag [02:59:03 CEST] <wm4> everything would have to specifically support such a flag to prevent itself from getting confused, but after all it seems like a solution [03:00:22 CEST] <wm4> maybe I better go to bed [03:17:57 CEST] <atomnuker> is it too late to bump lavc minor version? [03:18:20 CEST] <atomnuker> just curious [03:19:34 CEST] <wm4> for what? [03:20:15 CEST] <atomnuker> a new codec id [03:20:53 CEST] <wm4> this can be done any time [04:03:33 CEST] <rcombs> JEEB: where's that code handle stream matching? [04:09:26 CEST] <rcombs> wow, those samples are lovely [04:09:31 CEST] <rcombs> multiple segments in the same file [04:09:33 CEST] <rcombs> why even [04:43:10 CEST] <cone-685> ffmpeg 03Matt Oliver 07master:216cc1f6fe33: lavu/intmath.h: Add msvc/icl ctzll optimisations. [04:43:10 CEST] <cone-685> ffmpeg 03Matt Oliver 07master:b0bb1dc62d40: lavu/intmath.h: Move x86 only msvc/icl functions to x86 specific header. [04:59:51 CEST] <wm4> rcombs: fortunately nobody uses this [04:59:58 CEST] <rcombs> good [05:00:02 CEST] Action: rcombs ignores that case for now [05:05:52 CEST] <wm4> the only reason mpv supports this case is because I found a relatively simple and unintrusive way to do so [05:06:14 CEST] <wm4> but I've found literally only 1 sample which uses it (the cccp test file) [05:06:32 CEST] <wm4> writing lots of code to make 1 sample work is fun [05:08:44 CEST] <rcombs> yeah, I won't work on it unless I actually get requests from my users [05:08:57 CEST] <rcombs> but what about stream matching? [05:09:28 CEST] <rcombs> I see where new_extradata side-data gets sent after switches [05:10:01 CEST] <wm4> in theory, all mkv segments are supposed to have exactly the same configuration [05:10:14 CEST] <wm4> same track order, IDs, codecs, extradata, etc. [05:10:20 CEST] <rcombs> but I'm missing the checks to make sure the stream counts and codecs are the same [05:10:22 CEST] <wm4> the extradata bit didn't quite work out [05:10:24 CEST] <rcombs> yeah, in theory :P [05:10:44 CEST] <wm4> and the extradata bit is also why the original patch (years ago) to add OC to lavf failed [05:10:50 CEST] <wm4> I think [05:11:10 CEST] <wm4> and also the design of this approach was controverse [05:11:21 CEST] <wm4> but by now I don't think I give a shit [05:11:56 CEST] <wm4> I'd rather be freed of the evil to handle segment switching on playback [05:12:37 CEST] <rcombs> seems to work well enough for LAV at least [05:13:10 CEST] <wm4> the lav thing was always a giant hack (which is also why nobody ever attempted to upstream it), but yeah [05:14:19 CEST] <rcombs> I'm pleased that I got basic support working in <400 lines [05:15:03 CEST] <Timothy_Gu> would it be acceptable if I submit a patch that chooses between sse2 and avx2 depending on the width of the picture? [05:15:22 CEST] <Timothy_Gu> and a threshold [05:15:30 CEST] <rcombs> does it help perf? [05:15:45 CEST] <Timothy_Gu> cuz avx2 is ~25% faster above that threshold and 2x slower below it [05:15:54 CEST] <rcombs> then sure, why not? [05:16:11 CEST] <rcombs> I did that for something in libass [05:16:23 CEST] <Timothy_Gu> ok cuz i'm not sure if the threshold is the same across all cpus [05:16:31 CEST] <Timothy_Gu> all models of cpus rather [05:16:34 CEST] <rcombs> hopefully people will bench it [05:40:06 CEST] <wm4> rcombs: I might be confused, but does the chapter_finished pts check really work? [05:41:26 CEST] <wm4> because pts is out of order [05:43:31 CEST] <rcombs> works on the samples I'm testing, at least [05:43:53 CEST] <rcombs> what's wrong? [05:47:51 CEST] <rcombs> side by side with mpv's demuxer, mine's a little bit smoother on the transition here [05:47:56 CEST] <rcombs> mpv's makes a popping sound [08:22:46 CEST] <ubitux> rcombs: omg [08:22:48 CEST] <ubitux> e [08:43:47 CEST] <Timothy_Gu> Is there a way to make sure AVPicture.data pointers are aligned to 32? [08:47:35 CEST] <rcombs> shouldn't they always be when AVX is available, since av_malloc does 32-byte alignment then? [08:48:22 CEST] <Timothy_Gu> they should be but I'm getting { 0x7ffff7fa3010, 0x7ffff7fd4810, 0x7ffff7fe0e10 } as frame->data [08:48:48 CEST] <Timothy_Gu> and since I'm writing AVX2 asm that means I can't use mova :( [08:55:32 CEST] <rcombs> missing memalign? (if not, guess you'll have to track down whatever's allocating or offsetting buffers by a non-32-byte-aligned amount) [08:59:28 CEST] <Timothy_Gu> `b malloc` :( [09:10:40 CEST] <wm4> rcombs: mpv has an additional wait for the video frame, which may underrun the audio buffer, or maybe the audio segment switching code is just broken (both problems with how segment switching is implemented on the higher levels, and goes away completely if implemented on the demuxer level) [09:11:06 CEST] <rcombs> yeah, figured it was something like that [09:15:08 CEST] <wm4> and the pts issue is that the first packet's (IDR) pts doesn't have to be the lowest, if I got this right [09:23:13 CEST] <rcombs> hmm? [10:28:32 CEST] <ubitux> wm4: the problem with pts/dts was something along the line "how do i adjust dts when cutting the video randomly" [10:28:46 CEST] <ubitux> but also something like "how will this work when it's going to support loop stuff" [10:29:19 CEST] <ubitux> and "how is this going to achieve a sample and frame accurate cutting" (maybe skip for audio?) [10:29:54 CEST] <ubitux> (and a skip decode flag for video?) [10:30:58 CEST] <nevcairiel> Timothy_Gu: if avx is enabled you should get 32-byte aligned allocations from av_malloc [10:31:57 CEST] <ubitux> rcombs: so when are you submitting aesni, crypto_bench new ssl code, and mkv ordered chapters? @_@ [10:58:23 CEST] <rcombs> ubitux: I'll resend the aesni series in a minute with Gramner's tweaks (which improve perf a bit further) [10:58:25 CEST] <rcombs> https://gist.github.com/a02c280533ad11e72876 [10:58:51 CEST] <ubitux> lavu_c is funny [10:58:53 CEST] <ubitux> :)) [10:58:58 CEST] <ubitux> s/funny/dramatic/ [10:59:10 CEST] <ubitux> nice numbers btw [10:59:24 CEST] <nevcairiel> crypto seems to scale much better with increasing key size [10:59:27 CEST] <nevcairiel> you should get on that [11:00:11 CEST] <rcombs> they parallelize modes where you can do that [11:00:28 CEST] <rcombs> ubitux: the lavu_c numbers are exaggerated [11:00:42 CEST] <rcombs> because that's without -O3 [11:00:49 CEST] <rcombs> https://gist.github.com/c7c4c693769abec50ccb with [11:01:02 CEST] <wm4> ubitux: yes, would need flags for skipping video frames (decoded ones) [11:01:33 CEST] <ubitux> rcombs: mmh, no -O* at all? [11:01:38 CEST] <rcombs> yeah [11:01:43 CEST] <ubitux> why? oO [11:01:54 CEST] <rcombs> because that's how I normally build when working on non-perf stuff [11:02:01 CEST] <nevcairiel> do people consider O3 safe for ffmpeg anyway? I've always stuck to O2 [11:02:25 CEST] <Timothy_Gu> nevcairiel: I do get 32-byte alignment from av_malloc but for some reason not as AVFrame.data pointers [11:02:29 CEST] <ubitux> nevcairiel: i'd remove -fno-tree-vectorize first [11:02:34 CEST] <Timothy_Gu> anyway, too late, need to sleep now [11:02:42 CEST] <rcombs> because --disable-optimizations results in easier debugging by a factor of $a lot [11:02:49 CEST] <ubitux> rcombs: ok [11:03:08 CEST] <rcombs> Timothy_Gu: break on alloc_buffers or whatever that function's called; set watchpoints on ->data; see who's fucking with them [11:03:27 CEST] <rcombs> nevcairiel: the funny part is that libcrypto was the slowest of the bunch when I started testing [11:03:39 CEST] <rcombs> well it was faster than lavu_c without optimizations but iirc slower than with [11:03:59 CEST] <rcombs> because crypto_bench was using the old API for doing AES [11:04:08 CEST] <rcombs> and apparently that uses a completely different and much worse implementation [11:05:57 CEST] <rcombs> I still don't actually understand why CBC is so much slower then ECB [11:06:18 CEST] <rcombs> there's a comment in the libcrypto code about it [11:06:25 CEST] <rcombs> apparently they don't know either [11:07:45 CEST] <ubitux> haha [11:08:54 CEST] <rcombs> it's literally a 1-instruction difference [11:10:02 CEST] <rcombs> apparently feeding the output back in incurs a penalty of some sort [11:11:08 CEST] <rcombs> crypto_bench openssl and other AES key sizes are ready to go [11:11:49 CEST] <rcombs> it'd probably be good to de-duplicate it a bit with macros though [11:12:15 CEST] <rcombs> but no reason that can't be done after applying [11:13:08 CEST] <rcombs> I should probably add decrypting as well, since it performs differently [11:13:55 CEST] <rcombs> but that can also be later [11:31:56 CEST] <rcombs> ubitux: well sent all the crypto stuff [11:32:13 CEST] <rcombs> as for mkv ordered chapters, it's not done yet :P [11:32:21 CEST] <ubitux> ok :) [11:32:28 CEST] <rcombs> needs handling for when extradata changes [11:32:36 CEST] <rcombs> and stream match checking [11:32:42 CEST] <rcombs> and some more error conditions [11:32:44 CEST] <rcombs> and testing [11:32:58 CEST] <rcombs> and checking file UIDs needs to be faster [11:33:17 CEST] <ubitux> maybe set the option for ffplay btw, so we can try it out [11:33:30 CEST] <ubitux> i mean, by default [11:34:12 CEST] <ubitux> "EBC" in patch 6 [11:34:37 CEST] <rcombs> and I intend to implement a simple text file format with lines like `[uuid]:<uri>` so you can provide a list of segments (and optionally UUIDs) instead of scanning the dir [11:35:36 CEST] <nevcairiel> dont bother, noone is going to use it [11:35:56 CEST] Action: rcombs pins a badge labeled "no-one" on himself [11:36:17 CEST] <rcombs> (I have a very specific use-case in mind) [11:36:17 CEST] <nevcairiel> why do you even use this feature at all is the real question [11:36:32 CEST] <rcombs> ordered chapters in general? [11:36:39 CEST] <nevcairiel> yes [11:36:57 CEST] <nevcairiel> or w ell external segments specifically, i guess [11:37:08 CEST] <nevcairiel> i used ordered chapters for a few seamless branching blurays [11:37:13 CEST] <nevcairiel> but always limited to one mkv file [11:37:22 CEST] <rcombs> I've got a few users bugging me about coalgirls anime encodes and a few users bugging me about 2-in-1 movie encodes [11:37:34 CEST] <ubitux> i have many samples with external segments [11:37:43 CEST] <ubitux> "samples" as in "shit i watch" [11:37:59 CEST] <nevcairiel> stop watching all that illegal anime! [11:38:00 CEST] <rcombs> til ubitux uses coalgirls [11:38:04 CEST] <ubitux> :D [11:39:31 CEST] <ubitux> looking at a random directory, i see at least 10 different teams [11:39:39 CEST] <ubitux> using this for OP/ED [11:39:52 CEST] <rcombs> they mostly use it to only encode the OP and ED once [11:40:00 CEST] <ubitux> yes [11:40:05 CEST] <rcombs> but there's also the whole concept of "playall" files [11:40:21 CEST] <rcombs> which makes me think nobody's ever heard of& playlists [11:40:24 CEST] <rcombs> or `mpv *` [11:40:49 CEST] <ubitux> > cli [11:40:52 CEST] <ubitux> > too complicated [11:41:00 CEST] <rcombs> fine then [11:41:07 CEST] <rcombs> selecting a bunch of files and double-clicking [11:41:09 CEST] <nevcairiel> use a m3u playlist then, most players can read those [11:41:17 CEST] <ubitux> * is not very good btw [11:41:25 CEST] <ubitux> if you have thousands of episodes, it won't work [11:41:28 CEST] <rcombs> or would windows open them all separately at the same time [11:41:30 CEST] <ubitux> but you can mpv a directory so it's fine. [11:41:37 CEST] <rcombs> ubitux: who puts thousands of episodes in the same dir [11:41:45 CEST] <ubitux> :-° [11:41:48 CEST] <nevcairiel> clearly the answer is anime people [11:41:53 CEST] <ubitux> :D [11:41:58 CEST] <rcombs> apart from being dumb from an organization perspective that sounds hellish when searching for external segments [11:42:18 CEST] <nevcairiel> in fact i've had people complain that scanning external segments is too slow [11:42:24 CEST] <nevcairiel> so i optimized the hell out of it [11:42:39 CEST] <nevcairiel> down to avoiding one extra system call per file [11:42:58 CEST] <rcombs> it's really slow in my demuxer right now [11:43:08 CEST] <rcombs> partly because I'm testing over SMB [11:43:25 CEST] <rcombs> and partly because I'm calling read_header for each potential file and that's not fast [11:43:30 CEST] <nevcairiel> i even wrote some simple code to just open the file and read its UID instead of doing a full header parse [11:43:31 CEST] <nevcairiel> just because [11:44:28 CEST] <nevcairiel> it probably took me months to get all the kinks worked out, but so far people seem happy [11:44:36 CEST] <rcombs> I might end up doing the same [11:44:40 CEST] <nevcairiel> except those idiots that mix different codecs, but i just tell them to go away [11:45:09 CEST] <rcombs> the hardest thing here is going to be exposing editions [11:45:19 CEST] <rcombs> because it'll probably need new public APIs [11:45:22 CEST] <nevcairiel> since its my own local fork, i just added new api functions =p [11:45:27 CEST] <rcombs> yeah I noticed [11:45:34 CEST] <mateo`> mov and mxf already handle external segments, why would mkv not looking at the future ! [11:46:52 CEST] <ubitux> rcombs: EVP is not a "new" api [11:47:06 CEST] <ubitux> you might want to say why you use it [11:47:12 CEST] <rcombs> ubitux: I'd imagine it's newer than whatever we were using [11:47:27 CEST] <rcombs> but yeah that's sensible [11:51:36 CEST] <wm4> rcombs: regarding loading external segments, there should indeed be a way to let the API user do it [11:51:59 CEST] <wm4> like letting the API user pass a list of URLs to try [11:52:03 CEST] <nevcairiel> way to bloat up complexity to 9000 wm4 :d [11:52:21 CEST] <rcombs> nevcairiel: if it's just passing a list it's not that complex [11:52:26 CEST] <rcombs> and I was planning on doing that anyway [11:52:49 CEST] <wm4> nevcairiel: well, I like losing control about the way external files are scanned the least [11:53:00 CEST] <rcombs> wm4: you OK with a file arg instead of taking the list directly as an AVOption with escaping? [11:53:48 CEST] <wm4> a file with an ad-hoc text format? [11:54:18 CEST] <rcombs> I was planning on having each line be `[uuid]:<uri>` [11:54:37 CEST] <nevcairiel> maybe he doesnt know the uuid and just wants to suggest a few files to try [11:54:38 CEST] <wm4> can't we have an AVDictionary somewhere [11:55:05 CEST] <rcombs> nevcairiel: that's why it's [uuid] instead of <uuid> :P [11:55:57 CEST] <rcombs> wm4: can you even pass a dict through AVOptions? [11:56:07 CEST] <rcombs> or are you saying this should be its own lavf public API [11:56:13 CEST] <wm4> dunno [11:56:25 CEST] <wm4> well I think I'm happy enough if you can pass this "fvile" as a string [11:56:29 CEST] <wm4> *file [11:56:47 CEST] <wm4> so poass the contents, rather than lavf opening a file [11:57:07 CEST] <rcombs> OK [11:57:13 CEST] <rcombs> oh and another thing I need to do before this is done [11:57:18 CEST] <rcombs> actually cleanup :P [11:57:21 CEST] <wm4> also, lavf has an open callback somewhere [11:57:28 CEST] <rcombs> ah yeah [11:57:30 CEST] <rcombs> I should use that [11:57:50 CEST] <rcombs> right now I don't free the allocations I make on exit yet [11:58:07 CEST] <rcombs> so, 'know, another thing for the checklist [11:58:46 CEST] <rcombs> uh [11:59:00 CEST] <rcombs> I should probably run the matroska probe on these files before actually opening them [11:59:37 CEST] <nevcairiel> personally I do that in the same step, open file, check for doctype, if match look for UID, done [11:59:50 CEST] <rcombs> and also fix the style extension check [12:02:29 CEST] <rcombs> well 'night [13:21:20 CEST] <wm4> michaelni_: not calling avformat_find_stream_info() breaks opening some .ts files, but only on ffmpeg, not Libav [13:23:02 CEST] <michaelni_> skiping avformat_find_stream_info() is not a good idea but how can this be reproduced ? [13:24:20 CEST] <wm4> why is it not a good idea? I want to open files immediately, not waste time on guessing useless, inaccurate info like bitrate etc. [13:24:42 CEST] <wm4> yes, for .ts files, reading ahead some makes sense, but still [13:26:02 CEST] <michaelni_> well, if your application can handle new streams, programs and codec_ids changing midstream, not sure these are all things .. then skiping avformat_find_stream_info() should be fine i think [13:26:44 CEST] <wm4> why would codec_ids change midstream [13:26:46 CEST] <wm4> don'T say flv [13:26:59 CEST] <michaelni_> codec probing [13:27:02 CEST] <wm4> flv should be fixed and add the streams only when codec id is known [13:27:50 CEST] <michaelni_> more "somewhere at the start of a stream but note exactly at the start" than "midstream" [13:30:17 CEST] <wm4> if codec ids can change midstream, there must be some sort of codec id change side data [13:30:44 CEST] <nevcairiel> i dont think it necessarily "changes" as such, just goes from none -> proper id [13:34:28 CEST] <michaelni_> it can change between other codec ids during probing, this should not happen once decoders are opened or probing is done [13:35:12 CEST] <wm4> pure insanity [13:54:03 CEST] <michaelni_> IIRC libavformat will not return a packet for a stream before probing for it is done and thus codec_id is fixed [13:55:02 CEST] <michaelni_> but what do you suggest ? [13:57:00 CEST] <superware> how can I promote trac.ffmpeg.org/ticket/4893 ? can someone help? [13:59:08 CEST] <superware> www.ff [13:59:16 CEST] <superware> sorry [14:00:15 CEST] <J_Darnley> Sure, here's the solution: --disable-network [14:02:04 CEST] <superware> great [14:02:42 CEST] Action: J_Darnley snickers [14:02:44 CEST] <J_Darnley> sorry [14:03:35 CEST] <wm4> michaelni_: can the api user know when the codec id is being probed, as opposed to unknown? [14:03:56 CEST] <nevcairiel> wm4: there is request_probe > 0 in the avstream i think [14:03:58 CEST] <wm4> michaelni_: what about other parameters (like width/height, extradata, etc.)? when does the API user know that they are known? [14:03:59 CEST] <nevcairiel> maybe codec context [14:04:39 CEST] <nevcairiel> wm4: those either appear right with the stream, or not at all - ie. in this case only after decoding [14:05:07 CEST] <nevcairiel> although extradata might be a bit different [14:05:10 CEST] <nevcairiel> not sure when that shows up [14:07:11 CEST] <michaelni_> wm4, request_probe should tell about the probing state [14:08:24 CEST] <michaelni_> w/h could be set by a parser in which case they should only be set after probing [14:09:20 CEST] <nevcairiel> if the parser can set it, then usually the decoder can figure it out on its own as well [14:09:36 CEST] <michaelni_> yes, also spliting a stream into packets can need a parser so it too can happen only after probing [14:10:14 CEST] <superware> michaelni_: hi, you've successfully helped me a few years ago with a "tough nut" issue :) can you please advice me on trac.ffmpeg.org/ticket/4893 ? what should I do to promote it? [14:11:02 CEST] <wm4> so it's like find_stream_info is optional, but don't complain if you get stabbed to death by 1000s of nonsense corner cases [14:12:30 CEST] <michaelni_> not running find_stream_info() is not well tested, maybe we should add some fate tests for that or something [14:16:47 CEST] <michaelni_> superware, i dont have time ATM to look into this, maybe Thomas Volkert or nicolas are interrested to look into a udp issue but ive not checked what exactly this one is about [14:19:33 CEST] <michaelni_> but if its a h264 issue then they are the wrong people to ask [14:19:53 CEST] <nevcairiel> looks like h264 from reading it briefly, the decoder seems to get into an error state and never recover [14:22:15 CEST] <michaelni_> can this be reproduced via a simple input file (no udp) ? (would be easier to work with a flat file than udp pcap) or is there some difference between the concatenated udp data and whet libavformats udp makes out of it ? [14:23:00 CEST] <nevcairiel> wonder if one couldnt simply dump the udp stream into a mpegts file for testing [14:23:07 CEST] <nevcairiel> superware should try that [14:23:59 CEST] <nevcairiel> perhaps with netcat [14:24:49 CEST] <michaelni_> its output could be compared to tools/aviocat just to be sure theres no libavformat protocol issue [14:25:16 CEST] <nevcairiel> oh right, aviocat could also dump it [14:28:07 CEST] <superware> michaelni_: well, the way I've successfully reproduced it was to omit every other packet (50%) and save that as a pcap for playback. [14:28:36 CEST] <nevcairiel> it would be easier if you could try to save the resulting stream with aviocat into a file and see if that also fails [14:28:42 CEST] <nevcairiel> replaying a pcap stream requires effort :p [14:30:51 CEST] <superware> ok, trying... [14:31:39 CEST] <nevcairiel> something like "aviocat udp://xxx..xxx.xx file.ts" should hopefully do the job [14:38:39 CEST] <superware> nevaciriel: where can I get aviocat executable? [14:39:22 CEST] <J_Darnley> :) I'm reading an HN thread where some guy is asking for suggestions for a platform to test some SIMD code on skylake. So far 3 people have told him to build his own like a $1000 system is loose change. [14:39:37 CEST] <J_Darnley> superdump: make tools/aviocat [14:40:38 CEST] <J_Darnley> sorry that should have been superware ^ [14:42:35 CEST] <Daemon404> J_Darnley, for a company who got a buttload of VC it is [14:42:41 CEST] <Daemon404> HN has VC-colored glasses [14:44:46 CEST] <BBB> all startups have VC-colored glasses [14:44:57 CEST] <Daemon404> and HN is about startups [14:45:06 CEST] <BBB> HN is startup elite central [14:45:56 CEST] <BBB> look at me Im YC12" [14:46:47 CEST] <BBB> reminds me of a woman my wife knew over there with a bumper sticker stanford 04 graduate or something like that [14:47:00 CEST] <BBB> thats your claim to fame, that you graduated from YC in 12 or Stanford in 04 [14:47:03 CEST] <BBB> ... [14:47:19 CEST] <J_Darnley> It is a strange place [14:49:42 CEST] <kierank> J_Darnley: stop reading hn [14:50:04 CEST] <Daemon404> i enjoy it in a morbid way [14:50:09 CEST] <Daemon404> like watching a car crash [14:50:28 CEST] <kierank> https://twitter.com/obencoder/status/655694258758881280 [14:50:43 CEST] <Daemon404> lol [14:50:48 CEST] <Daemon404> i dont even have to click that [14:50:50 CEST] <Daemon404> it's the bbc article [14:50:53 CEST] <Daemon404> abotu 10gige [14:50:54 CEST] <Daemon404> i bet [14:51:08 CEST] <nevcairiel> it is [14:54:13 CEST] <kierank> yeah there's a wall of text about TCP optimisation for web streaminjg [14:54:16 CEST] <kierank> on hn [14:54:59 CEST] <JEEB> yea [14:55:44 CEST] <Daemon404> lol [15:14:56 CEST] <superware> nevaciriel: aviocat is stuck on avio_read since there's no more packets to read, any idea? [15:15:30 CEST] <superware> since there's => when there are [15:15:50 CEST] <nevcairiel> just close it, it should've written the output file anyway [15:19:05 CEST] <superware> ok [15:33:44 CEST] <superware> michaelni_: ok, please see http://www.datafilehost.com/d/f097cc19 you will notice the frames stop (by starting PlayCap just after the "bad" point, ffplay is able to play everything that follows, so it must be something in that point) [15:44:17 CEST] <superware> nevaciriel: can you please verify the producted file indeed causes ffmpeg (and ffplay) to stop outputting frames? [15:44:56 CEST] <superware> produced* [16:01:05 CEST] <ubitux> async model, we want to pop a frame; do we want it blocking or not? [16:01:14 CEST] <wm4> context? [16:01:41 CEST] <ubitux> imagine a player, rendering thread, poping a frame to be display [16:02:04 CEST] <ubitux> does it want a fast return to refresh screen or whatever even if it has no new frame [16:02:07 CEST] <Daemon404> is this a thought experiment [16:02:13 CEST] <ubitux> or do we want to block until we get the new frame [16:02:26 CEST] <ubitux> it's about writing an async api [16:02:39 CEST] <ubitux> we could have both obviously [16:02:43 CEST] <Mavrik> I've always thought that blocking async APIs make for a cleaner code at the end. [16:02:44 CEST] <ubitux> depending on an option [16:03:09 CEST] <ubitux> Mavrik: yeah, but in case of a lag, one is responsive (with drops) and one isn't but will show every frame [16:03:36 CEST] <wm4> IMO, it should fetch from a thread-safe queue [16:03:41 CEST] <Mavrik> Good point there. [16:03:47 CEST] <wm4> the user should be able to get notified if there's a new frame [16:03:54 CEST] <wm4> this is enough to implement blocking wait too [16:04:00 CEST] <ubitux> wm4: yes, but let's say the queue is empty, what is the poping frame function supposed to do? [16:04:04 CEST] <ubitux> wait, or return nothing? [16:04:42 CEST] <ubitux> the thread poping frames is decoupled from the demux/decode/filter one, its only work is to... get data [16:04:44 CEST] <wm4> either way would work... if there's a notification mechanism, the other could be implemented ontop of the default semantics [16:04:56 CEST] <wm4> personally I don't think blocking behavior is all that useful [16:05:03 CEST] <wm4> because how do you interrupt it? [16:05:21 CEST] <ubitux> you don't [16:05:30 CEST] <ubitux> basically i'd say in a player a non-blocking is interesting [16:05:33 CEST] <ubitux> but in case of a transcode [16:05:41 CEST] <ubitux> you absolutely want the frame anyway, so you want it blocking [16:05:49 CEST] <ubitux> so i guess the api should provide both ways? [16:06:12 CEST] <nevcairiel> could do like most APIs and provide a timeout to the blocking wait, that way you can wait on a condition variable quite efficiently [16:06:24 CEST] <wm4> timeouts are nonsense [16:06:44 CEST] <ubitux> that's half assed, not sure in what scheme you would want that [16:06:53 CEST] <wm4> just provide a sane notification method, so the user can implement his own condition variable based blocking or so [16:07:01 CEST] <nevcairiel> or if you're waiting on a condition variable anyway, just make it signaled and the function returns [16:07:32 CEST] <Mavrik> Essentially what you're just trying to do with blocking API is to avoid spinlock waiting. [16:07:50 CEST] <Mavrik> So if you add a way to be notified on a frame then the main issue with non-blocking API kinda dissapear. [16:08:06 CEST] <ubitux> the user will have to prevent spinlock himself with cond in the non blocking mode [16:08:19 CEST] <ubitux> but i'm not sure to see the point of having such complexity [16:08:29 CEST] <ubitux> when we can deal with the blocking internally instead of letting the user do it [16:08:52 CEST] <wm4> I don't deny that providing helpers for blocking wait (so a user doesn't have to implement boilerplate) might be useful [16:08:59 CEST] <nevcairiel> having a totally block-free API makes some decisions a bit weird though .. do I need to feed the decoder more data? do I wait for frames to be done first? etc [16:09:01 CEST] <wm4> but there need to be some ways to make this not crap [16:09:21 CEST] <ubitux> ok ok [16:09:23 CEST] <wm4> for example, it might be better to let this blocking wait return if the decoder needs new _input_ [16:09:49 CEST] <wm4> so maybe decoder_wait(), with return values NEEDS_INPUT and HAS_OUTPUT [16:10:31 CEST] <wm4> this way no interruption is needed either, because the call will return as soon as the decoder is more or less idle (like with lavc's current API) [16:11:10 CEST] <wm4> nevcairiel: IMO the decoder should always signal when it wants new input [16:11:24 CEST] <wm4> you don't want to always feed it input, that'd just lead to excessive buffering [16:11:48 CEST] <ubitux> well, internally there is an automatically blocking queue [16:11:55 CEST] <ubitux> (on which as a user you can control the size if you want) [16:13:08 CEST] <nevcairiel> which means the input push function would eventually block? [16:13:33 CEST] <ubitux> yes [16:14:31 CEST] <wm4> IMO mandatory blocking is not good... it just requires the user to juggle around with more threads, and just how do you unblock the threads? [16:14:37 CEST] <nevcairiel> that needs a function to check if it would block then, so i can decide to process output first before waiting [16:15:04 CEST] <ubitux> then maybe block with timeout returning EAGAIN if it wasn't able to? [16:18:58 CEST] <nevcairiel> consider a demuxing driven setup, ie. you always enter the entire process with a new AVPacket to handle. Ideally I want to submit this packet immediately and then process decoder outputs, so in that scenario i wouldn't want to block on submit, but rather on poping frames, until the input queue is (nearly) empty and i need to loop again to get a new packet [16:19:45 CEST] <nevcairiel> in theory it should never happen in this setup that the input queue overflows th ough [16:19:48 CEST] <nevcairiel> so it might be ok [16:20:22 CEST] <nevcairiel> as long as I can get that information - i need to know if my input queue is (nearly) empty and i need to fetch more data before processing more output frames [16:20:34 CEST] <ubitux> so you're in a sync model trying to use the async api? [16:20:45 CEST] <ubitux> by basically pushing and popblock? [16:21:07 CEST] <nevcairiel> one advantage of that is that it can still decode in the background while i'm doing other things [16:21:11 CEST] <ubitux> (or maybe not block if there is nothing in output..) [16:21:38 CEST] <wm4> what nevcairiel said; you can decode in the background, even if your code looks synchronous [16:21:57 CEST] <nevcairiel> right now the decoder is doing nothing while i'm say filtering the image on the same thread [16:22:34 CEST] <nevcairiel> with the async API the decodre could be busy on its own async thread while I can still use the "main" thread for filtering and presenting [16:23:10 CEST] <nevcairiel> I currently emulate that in my own code by simply moving all decoding on a worker thread [16:23:26 CEST] <nevcairiel> but its a lot of plumbing that this API might be able to simply replace [16:23:38 CEST] <ubitux> i'm not sure to follow: do you have threads as a user? [16:23:47 CEST] <ubitux> (in your scenario) [16:24:01 CEST] <nevcairiel> you could, of course [16:24:24 CEST] <ubitux> but in the use case you're presenting [16:24:35 CEST] <nevcairiel> not necessarily [16:24:47 CEST] <nevcairiel> you could do it all in one thread for simplicity [16:24:59 CEST] <nevcairiel> while still having the decoder work on its own async worker thread internal to avcodec [16:25:28 CEST] <ubitux> in the api you have 2 func: one to push a packet, one to pop a frame; which would you see blocking, and what extra api you would like? [16:26:00 CEST] <nevcairiel> neither does really have to block, as long as there is other informational functions that I can use to block myself [16:26:07 CEST] <nevcairiel> or both could block if the conditions call for it [16:26:14 CEST] <nevcairiel> push could block if the internal queue is way too big [16:26:23 CEST] <wm4> ubitux: you'd have functions for both input and output to 1. query the state, 2. feed/receive data [16:26:24 CEST] <nevcairiel> (which you should not reach in my model, so non-issue) [16:26:36 CEST] <ubitux> so you want to deal with the blocking yourself? even in the simplest form, you don't think that can be handled by the api to limit the boilerplate? [16:26:45 CEST] <nevcairiel> and pop should block if the decoder needs no further interaction right now, ie. no output is ready, and no input is needed [16:26:49 CEST] <wm4> if the query function returns a positive result, the second operation should never block [16:26:58 CEST] <wm4> (think of it as poll(), read(), write()) [16:27:29 CEST] <wm4> now, what happens if you feed/receive without querying the state [16:27:34 CEST] <wm4> blocking would just lead to a deadlock [16:27:46 CEST] <nevcairiel> depends really [16:27:50 CEST] <wm4> you can't just block when reading output, because writing input might be required to make progress [16:28:02 CEST] <nevcairiel> if push just blocks while the input queue is too big, it would eventually unblock as the decoder works through the data [16:28:29 CEST] <nevcairiel> and if pull can return an error for "need more data", then thats also not a problem [16:28:32 CEST] <wm4> it could do that, but then it'd unblock with no data to return if the input queue runs out [16:28:40 CEST] <wm4> and also this loss of buffering would make it inefficient [16:28:49 CEST] <wm4> (so it's not really useful) [16:29:25 CEST] <nevcairiel> if you want the full efficiency, you might need to use the poll methods [16:29:45 CEST] <nevcairiel> or it just asks for more data if the queue input queue is empty, but the decoder still working [16:30:11 CEST] <nevcairiel> that should hopefully give you enough time to react [16:30:48 CEST] <wm4> maybe have a decoder_wait() function, which returns NEEDS_INPUT, HAS_OUTPUT, or IDLE [16:31:05 CEST] <nevcairiel> whats IDLE if not NEEDS_INPUT? :) [16:31:05 CEST] <wm4> maybe you could have a blocking version too, which wouldn't return IDLE [16:31:18 CEST] <wm4> IDLE is if it has enough input, but is still waiting for output [16:31:33 CEST] <nevcairiel> thats not a wait() function then, more like a poll() [16:31:39 CEST] <nevcairiel> wait sounds like blocking [16:31:44 CEST] <wm4> <wm4> maybe you could have a blocking version too, which wouldn't return IDLE [16:31:48 CEST] <wm4> well ok [16:32:39 CEST] <wm4> ubitux: makes sense? [16:32:50 CEST] <nevcairiel> i think we lost him [16:33:15 CEST] <ubitux> i was away 1 minute, i lost track indeed, will read & re-read, and re-ask again if needed [16:33:17 CEST] <ubitux> give me a moment [16:34:43 CEST] <ubitux> 16:28 <@nevcairiel> if push just blocks while the input queue is too big, it would eventually unblock as the decoder works through the data // this can not work if you're in a sync model as a user [16:34:47 CEST] <nevcairiel> personally I would make the pop function have the behavior of the suggested "wait" function (ie. block while decoder is happy, no input needed, no output ready), and on top have a poll function that just returns the three states without blocking for people that want to avoid the block there at all costs [16:35:03 CEST] <ubitux> (unless you have a query system as suggested) [16:35:06 CEST] <nevcairiel> ubitux: why not [16:35:16 CEST] <nevcairiel> it would just pile up in the output queue [16:37:42 CEST] <wm4> so I guess we agree that whatever you do, there can be 3 states: input needed, output ready, and idle|blocking [16:37:55 CEST] <ubitux> let's say the internal frame queue has 2 frames, you push a packet which is going to translate to 10 output frames (because sanity), then the api would mandate that you need to pop as much as you can? [16:38:08 CEST] <ubitux> (before trying to push another packet) [16:38:13 CEST] <nevcairiel> sure [16:38:17 CEST] <ubitux> ok [16:38:25 CEST] <nevcairiel> dont think anything else makes much sense [16:38:28 CEST] <ubitux> so blocking push and blocking pop [16:38:41 CEST] <wm4> of course you could always make the queues unbounded, but that'd be silly [16:38:43 CEST] <nevcairiel> with poll functions to query if it would block [16:38:47 CEST] <nevcairiel> thats what i would do, anyway [16:39:26 CEST] <wm4> and this conveniently takes care of both n:m decoding, and async decoding [16:39:26 CEST] <ubitux> query if what would block? just pushing? [16:39:35 CEST] <nevcairiel> both [16:39:46 CEST] <ubitux> the pop query might be innacurate then [16:39:51 CEST] <nevcairiel> how so [16:40:19 CEST] <ubitux> well, the frame could not be ready when you query, but soon after [16:40:26 CEST] <nevcairiel> thats fine [16:40:28 CEST] <ubitux> even before you try to push another packet [16:40:52 CEST] <ubitux> but that frame which got just ready might make the frame queue full [16:41:05 CEST] <nevcairiel> there should be no output frame queue [16:41:06 CEST] <ubitux> and so you're trying to push a packet even though you can't [16:41:06 CEST] <wm4> these states are stable, I'd say [16:41:26 CEST] <nevcairiel> well, no maximum size anyway [16:41:27 CEST] <ubitux> (or well, we need a packet queue as well i suppose) [16:41:37 CEST] <ubitux> no maximum size? no no.. [16:41:46 CEST] <nevcairiel> the decoder should always be able to put its decoded frame somewhere [16:42:14 CEST] <wm4> it's up to the decoder not to accept too much input that it can't output anymore [16:42:45 CEST] <nevcairiel> if the calling app keeps pushing new data but not cleaning out the output frames, its really its own fault =p [16:43:05 CEST] <wm4> so you should say feeding input should always succeed? [16:43:33 CEST] <nevcairiel> not necessarily, there should be an input queue with could have a max size [16:43:59 CEST] <nevcairiel> but without knowing how many packets make up a frame, setting an output queue size would be hard [16:44:05 CEST] <nevcairiel> i mean, you could get 10 frames out of 1 packet [16:44:07 CEST] <nevcairiel> now what [16:44:39 CEST] <wm4> yeah [16:44:41 CEST] <wm4> ok [16:44:59 CEST] <wm4> I mean, the decoder itself can know how many input packets it can take without overflowing the output queue [16:45:04 CEST] <wm4> in theory [16:45:22 CEST] <wm4> if there's too much output, it just can stop decoding [16:45:22 CEST] <nevcairiel> maybe defining an output queue size could be optional [16:45:41 CEST] <nevcairiel> in a full async model, you might otherwise get a bit of funny business [16:45:48 CEST] <nevcairiel> ie. one thread reads input and blocks on submit() [16:45:55 CEST] <nevcairiel> another thread reads output and displays it [16:46:19 CEST] <nevcairiel> decoder would be working overtime to decode the entire file into memory if its not bounded somewhere [16:46:51 CEST] <nevcairiel> hard to say really [16:47:05 CEST] <wm4> yes, that's what I mean by excessive buffering [16:48:01 CEST] <nevcairiel> i suppose the output queue should have a certain size limit, if you cant process output faster, its no good producing any more anyway [16:48:31 CEST] <nevcairiel> but then your submit packet function could indeed block forever [16:48:42 CEST] <nevcairiel> or it needs a return value that says "process output, dude" [16:50:26 CEST] <nevcairiel> ideally you should be able to use submit and pop without worrying about deadlocking, and only for further optimization or mapping to a sync process use the poll functions [16:52:04 CEST] <nevcairiel> .. which means you could make submit block indefinitely if output is never getting processed, but then I bet API users would *commonly* make the mistake of not polling first and locking themself up [16:55:58 CEST] <wm4> nevcairiel: that's why I'm saying there should be a central processing function, which essentially tells the API user what to do (send input, read output, or do wait) [16:56:57 CEST] <nevcairiel> to summarize: submit() should block if the input queue is full, and the output queue still has room - ie. the input queue will shrink soon without interaction from the user. pop() should block if no output is available, and no input is needed(), and there should be a poll() function to check the status (need input, has output, working) [16:57:41 CEST] <nevcairiel> the only question is what "need input" specifically means, input queue not full? input queue empty? [17:01:23 CEST] <wm4> good question, I would say queue empty [17:01:44 CEST] <wm4> if a decoder actually needs input, the input queue will quickly become empty again [17:01:59 CEST] <wm4> and if the user wants extra buffering, he can do that on his own [17:02:29 CEST] <nevcairiel> input queue needs a packet count function then [17:03:43 CEST] <nevcairiel> anyway the general concept is simple, any function should only block if its going to unblock on its own soon without user interaction [17:04:57 CEST] <wm4> sounds good [17:17:03 CEST] <martijnb> just so I get the gist, so if the decoder doesn't have output available because it's waiting for more input, you don't want it to block because you want to notify the API user that more input is needed first [17:17:25 CEST] <martijnb> that's roughly what you just said right [17:17:31 CEST] <wm4> yes [17:17:56 CEST] <martijnb> gotcha [17:18:36 CEST] <nevcairiel> if you do a full async model, this might not be ideal, but you can just usleep(1); and try again hoping that your feeding thread has provided more input now [17:19:33 CEST] <nevcairiel> or you still get the output-ready callback which you can wait for [17:19:48 CEST] <wm4> usleep(1? wtf [17:20:15 CEST] <wm4> use condition variables [17:20:26 CEST] <nevcairiel> its the lazy approach [17:20:35 CEST] <ubitux> note that VT and MC async api do NOT have a pop function [17:20:36 CEST] <nevcairiel> which wont really perform any worse in the end [17:20:38 CEST] <ubitux> they use a callback system [17:20:46 CEST] <ubitux> maybe we should map to something like this [17:20:56 CEST] <ubitux> s/to/do/ [17:21:43 CEST] <ubitux> (which btw raises question to me about the reordering in the callback function in VT; like, how can this even work if the user consume the frame too early...) [17:21:47 CEST] <wm4> yes I've been arguing that we should have notification callbacks [17:22:04 CEST] <ubitux> it's not about notification, it's about actually getting the data frame itself [17:22:10 CEST] <nevcairiel> but its not only notification, its a full blown "have a frame and do something with it" callback [17:22:18 CEST] <ubitux> mediacodec seems to do it the otherway around for the "pushing" btw [17:22:32 CEST] <ubitux> like, you are querying a buffer to push [17:22:32 CEST] <wm4> (what I want is a notification callback would fire whenever input is needed or output is ready) [17:22:35 CEST] <wm4> +that [17:22:53 CEST] <ubitux> (and you're not going to get a buffer to fill if the queue is full) [17:23:51 CEST] <nevcairiel> I think having a output queue and a pop function is fine .. if you want to do all the work in the callback, you can just pop right there and go nuts [17:23:58 CEST] <nevcairiel> but it makes it easier to use it in a half-sync model [17:24:27 CEST] <martijnb> hrm [17:25:14 CEST] <ubitux> nevcairiel: so, can you summarize again (sorry) your suggestion? [17:25:24 CEST] <ubitux> i'm looking for a model to actually implement [17:25:29 CEST] <martijnb> I mean, from a modeling standpoint, if you can implement it neatly, it'd probably be nice to just register observers that either wait to hear input is required or more output is ready [17:25:41 CEST] <ubitux> first for map to other async models, then to put our current sync model in [17:25:43 CEST] <martijnb> so my 2 cents are with wm4 ;p [17:27:07 CEST] <martijnb> those are the 2 states the API user wants to act on anyway [17:28:43 CEST] <ubitux> isn't the notification system adding an annoying threading boilerplate for the user (mandatory? only in async?) [17:29:50 CEST] <wm4> ubitux: well we'd have the poll/wait functions too [17:29:54 CEST] <wm4> so, optional [17:30:31 CEST] <ubitux> can you make a full summary of the api? which functions are available, with what callback, and what is blocking? [17:33:52 CEST] <nevcairiel> (1) submit, block if input queue full, output queue not full, (2) pop, block if no output ready, still input available, (3) poll(), non-blocking, return if input needed, output ready, or just working, (4) callback when output ready, (5) callback when input queue empty? [17:35:46 CEST] <wm4> this still needs an explanation how the blocking can be undone by the API user [17:35:59 CEST] <wm4> do you need to close the codec context on another thread or so? [17:36:12 CEST] <ubitux> yes, like what to do in case of seek or something [17:38:49 CEST] <nevcairiel> all these blocks should unblock by themself in not-too-long [17:38:59 CEST] <nevcairiel> but i suppose an extra unblock might not be too terrible [17:39:57 CEST] <ubitux> anyone comfortable with one or more existing async api? like, mediacodec, VT or something else? [17:40:22 CEST] <wm4> I now know mmal more than I'd like to [17:40:28 CEST] <ubitux> typically one which is comfortable for the user (prefered to one that allow more) [17:40:37 CEST] <ubitux> are you satisified with it? [17:41:00 CEST] <wm4> mmal probably isn't too bad, except the preallocated buffer business [17:41:33 CEST] <wm4> connecting it with the lavc sync API was hellish [17:45:23 CEST] <ubitux> mediacodec and videotoolbox provides 2 different API for both model [17:45:50 CEST] <ubitux> for videotoolbox it makes things slow as shit in sync, but it kinda work [17:51:08 CEST] <ubitux> https://www.libavg.de/site/projects/libavg/wiki/VideoDecoding [17:51:13 CEST] <ubitux> maybe some interesting stuff around here [17:52:38 CEST] <durandal_1707> libavs [17:53:16 CEST] <mateo`> speaking of mediacodec, i've taken the C route to begin with (so no jni involved for this version) [17:54:07 CEST] <mateo`> (and i'll get back to the jni version after) [18:00:21 CEST] <nevcairiel> ubitux: i know the Media Foundation API, which works somewhat similar, call ProcessInput, it can return a status for "process output first", call ProcessOutput, which can return need more input, or otherwise blocks until frame is done [18:02:01 CEST] <nevcairiel> ..with callbacks on top [18:02:55 CEST] <ubitux> so having callbacks is recurrent in most (all?) implementations? [18:07:55 CEST] <nevcairiel> proper async needs callbacks [21:11:55 CEST] <cone-033> ffmpeg 03James Zern 07master:7b4367d93ea2: vp9_parser: fix endless loop w/0-sized frame [21:32:47 CEST] <Timothy_Gu> Ah okay that's why: av_realloc returns a 16-byte aligned pointer [21:36:01 CEST] <Timothy_Gu> now the ultimate question: how can I get an aligned realloc'd memory [21:36:06 CEST] <jamrial> Timothy_Gu: it should be 32-byte if you have avx enabled at configure time [21:36:57 CEST] <rcombs> so you don't HAVE_ALIGNED_MALLOC? [21:37:27 CEST] <rcombs> using posix_memalign or memalign instead? [21:38:23 CEST] <Timothy_Gu> jamrial: av_malloc is 32-byte aligned, but av_realloc isn't [21:38:34 CEST] <Timothy_Gu> rcombs: no, at least not on linux [21:39:00 CEST] <jamrial> it should, assuming either HAVE_ALIGNED_MALLOC or CONFIG_MEMALIGN_HACK are true [21:39:15 CEST] <Timothy_Gu> on linux both are not [21:39:46 CEST] <wm4> AFAIK you can't have that [21:40:06 CEST] <rcombs> is the use of av_realloc() actually necessary? [21:40:07 CEST] <Timothy_Gu> so should we make CONFIG_MEMALIGN_HACK default on !HAVE_ALIGNED_MALLOC? [21:40:13 CEST] <wm4> that's also why av_malloc return values can't be used with av_realloc [21:40:38 CEST] <wm4> realloc doesn't keep the aligned property) [21:40:40 CEST] <rcombs> seems unusual for it to be used with frame data buffers [21:40:46 CEST] <Timothy_Gu> rcombs: idk it's used deep in av_new_packet [21:41:23 CEST] <rcombs> oh, is it packet data? [21:41:31 CEST] <rcombs> I thought we were talking about AVFrame [21:41:49 CEST] <Timothy_Gu> oh the packet data is directly passed to an AVFrame in rawvideodec [21:42:43 CEST] <wm4> AVFrame can be not-aligned for a number of reason [21:42:46 CEST] <wm4> like cropping [21:43:50 CEST] <nevcairiel> <Timothy_Gu> now the ultimate question: how can I get an aligned realloc'd memory <-- use windows \o/ [21:44:02 CEST] <nevcairiel> (it has aligned realloc functions) [21:44:11 CEST] <rcombs> go yell at linus [21:44:31 CEST] <rcombs> that feels a bit backwards [21:44:32 CEST] <iive> it's glibc issue [21:44:35 CEST] <rcombs> usually he's the one doing that [21:44:44 CEST] <Timothy_Gu> I would if the package management system is better in windows [21:44:52 CEST] <Timothy_Gu> chocolatey and nuget kind of suck [21:45:04 CEST] <nevcairiel> so, you are using rawvideo for testing, huh? [21:45:20 CEST] <nevcairiel> rawvideo in itself is a bit weird, it can result in all sorts of alignment issues because of the packet-data passthrough [21:45:22 CEST] <Timothy_Gu> I'm actually not [21:45:55 CEST] <nevcairiel> but but you mentioend rawvideodec [21:45:58 CEST] <Timothy_Gu> oops actually i am [21:46:16 CEST] <rcombs> lies [21:46:18 CEST] <Timothy_Gu> I just used vsynth1 and -stream_loop 10000 [21:47:50 CEST] <Timothy_Gu> anyway, I guess I'll have to keep using movu then :( [21:48:18 CEST] <rcombs> it's not much slower in cases where data _is_ aligned on modern CPUs, is it? [21:48:30 CEST] <nevcairiel> dont we have a bunch of things that would just die if an avframe is not properly aligned? [21:49:05 CEST] <durandal_1707> you mean data pointers? [21:49:17 CEST] <Timothy_Gu> rcombs: at least not slower on the xeon i'm testing on [21:49:23 CEST] <iive> btw, since when does windows have alligned (re)alloc ? [21:49:38 CEST] <rcombs> _aligned_realloc [21:49:51 CEST] <rcombs> (yay underscores :/) [21:50:06 CEST] <Timothy_Gu> durandal_1707: basically frame->data[0] & 0x1f != 0 [21:50:23 CEST] <Timothy_Gu> iive: since forever apparently: https://msdn.microsoft.com/en-us/library/y69db7sx(v=vs.71).aspx [21:50:40 CEST] <Timothy_Gu> "Win 98, Win Me, Win NT, Win 2000, Win XP [21:51:22 CEST] <durandal_1707> live with it, data may not be aligned [21:52:13 CEST] <Timothy_Gu> but thing is frame->data[0] & 0xf always == 0 [21:52:22 CEST] <Timothy_Gu> idk if that's a coincidence [21:52:30 CEST] <nevcairiel> you may just get lucky on your platform [21:52:47 CEST] <rcombs> could be your libc just mallocs with 16-byte alignment [21:52:50 CEST] <Timothy_Gu> ok I guess [21:53:10 CEST] <nevcairiel> and with rawvideo, data[0]+linesize[0] could be totally unaligned [21:54:05 CEST] <Timothy_Gu> I'm not worrying about linesize as huffyuv encodes by line (i think) [21:57:03 CEST] <durandal_1707> you are working with that codec? [21:57:04 CEST] <iive> Timothy_Gu: that's kind of strange, since ffmpeg had to use manual alignment on windows... [21:57:17 CEST] <nevcairiel> noone cared to look it up [21:57:23 CEST] <nevcairiel> or silly mingw just didnt offer it [21:57:26 CEST] <nevcairiel> who knows [21:57:49 CEST] <iive> yeh, most likely mingw fault. [21:58:13 CEST] <nevcairiel> internally these functions oftne w ork the same way as the manual alignment hack in ffmpeg however [21:58:15 CEST] <JEEB> yeah, ye olde mingw used to either not have that stuff or hide it behind options [21:58:51 CEST] <JEEB> but yeah, if it has been there since 9x then it makes no sense to limit it, so it probably just didn't have it [21:59:40 CEST] <Timothy_Gu> durandal_1707: yes [21:59:52 CEST] <Timothy_Gu> also can someone review https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-October/181570.html? [22:03:55 CEST] <wm4> michaelni_: actually ffmpeg has a similar check like mpg123 in its code: [22:03:57 CEST] <wm4> if((state&SAME_HEADER_MASK) != (s->header&SAME_HEADER_MASK) && s->header) [22:03:57 CEST] <wm4> s->header_count= -3; [22:04:13 CEST] <wm4> SAME_HEADER_MASK seems to include the bitrate bits [22:05:13 CEST] <wm4> I have no idea what this specific code does though [22:05:44 CEST] <wm4> I think it also tries to determine "the" format [22:18:41 CEST] <michaelni_> hmm, the comment says bitrate is in there but i dont think it is [22:20:33 CEST] <wm4> hm that seems possible [22:21:22 CEST] <wm4> is it fine if I simply use SAME_HEADER_MASK? [22:32:19 CEST] <michaelni_> i think so [22:33:11 CEST] <cone-033> ffmpeg 03Michael Niedermayer 07master:fb4d350ff309: avcodec/mpegaudio_parser: Update comment to match code [22:52:29 CEST] <nevcairiel> now the guy who refuses to benchmark his "optimization" patches complains about lack of information [22:52:29 CEST] <nevcairiel> he really seems annoying sometimes :p [00:00:00 CEST] --- Tue Oct 20 2015

1 0

ffmpeg.log.20151019
by burek 20 Oct '15

20 Oct '15

[00:03:18 CEST] <BullHorn> https://mega.nz/#!KllDnDyL!NWN8vmzBZCkH2Q9z5HbTIKoYT4rIoh6fi9mbMasTnBw [00:03:22 CEST] <BullHorn> if someone wants to take a look ;x [02:33:46 CEST] <ChazNunz> Hi. Any way to draw a progress bar on a video that would increase during playback? This would not be in a player, but [02:33:54 CEST] <ChazNunz> hardcoded and overlayed on the video. [02:38:31 CEST] <ChazNunz> I'm not looking for progress bar to indicate when encoding is completed, but rather a "playback" progress bar. [03:06:35 CEST] <kecharitomene> Hi. I have a video file, a film, with embedded subtitles (not hardcoded, if that's the right term, but stored in the video container). [03:06:56 CEST] <kecharitomene> I'm trying to convert a clip from it with hardcoded subs. [03:07:14 CEST] <kecharitomene> But I can only find instructions for where you have the .srt file. [03:07:59 CEST] <edman007> kecharitomene, https://trac.ffmpeg.org/wiki/HowToBurnSubtitlesIntoVideo [03:10:01 CEST] <kecharitomene> Do I want the ass filter then? [03:10:46 CEST] <kecharitomene> no [03:11:52 CEST] <edman007> ChazNunz, I would try something like -vf drawbox=h=10:w=n*2 (or if not, it should work with using drawtext to draw a box... [03:12:18 CEST] <edman007> ffmpeg -i video.mkv -vf subtitles=video.mkv out.avi [03:12:29 CEST] <edman007> reads the subtitles out of the video and draws them on [03:12:32 CEST] <edman007> that's what you want [03:12:46 CEST] <edman007> kecharitomene, [03:14:58 CEST] <ChazNunz> edman007, how would i get the box to increment as the video playback progresses? I see that drawbox has timeline editing support. Suppose i don't know the number of frames or duration of the video before I start encoding. [03:18:16 CEST] <kecharitomene> edman007: No such fillter: subtitles [03:18:53 CEST] <relaxed> kecharitomene: your ffmpeg version must be old, try http://johnvansickle.com/ffmpeg/ [03:29:20 CEST] <edman007> ChazNunz, I would just do two passed and measure the duration first, it shouldn't be hard to script... [03:30:02 CEST] <edman007> but 100*n/total_frames (with total frames being some number you know), would make it go from zero to 100px wide [03:30:42 CEST] <DHE> or take a shot of ffprobe with -show_format assuming it's an intact file on disk [03:31:09 CEST] <ChazNunz> OK, I'll look. I was trying not to do a second pass as I already have a complex filtergraph. I am concating 50 videos nightly and rendering is taking lots of time. [03:32:07 CEST] <ChazNunz> DHE, I'll look at ffprobe as well. [03:32:17 CEST] <DHE> 50 files? all concatenated? [03:32:31 CEST] <DHE> wow I thought my job was big [03:34:24 CEST] <ChazNunz> We are doing an efficiency study and pulling 20-30 sec clips from cameras. We pull 50 a day from 20 cameras. We then concat these and overlay them into 2x2 grid. [03:45:38 CEST] <edman007> DHE, heh.. I'm doing a focus stacked timelapse...so far I got ~10,000 4MB JPGs...and ran them into a 11 second video [03:46:04 CEST] <edman007> I'm starting to worry about my camera...I'll probably take another 10-20k pics this week... [03:46:56 CEST] <edman007> https://www.youtube.com/watch?v=R2msivqnFdc in 4K! [03:47:04 CEST] <edman007> not done yet [03:48:01 CEST] <DHE> there was an outdoor webcam outside the building I work while it was being built. every 5 minutes I took a single jpeg from it (daylight hours only). there's nearly 32,000 jpegs in here. turned it into a time lapse of the construction [03:50:47 CEST] <edman007> DHE, I got a shell script doing it, every five minutes it takes 25 pictures, changing the focus between every one, then I post process each of the 25 pics to find all the in focus bits and merge them into one jpg, then pass that to ffmpeg to get a video [03:51:25 CEST] <DHE> you win [03:51:47 CEST] <kecharitomene> edman007: I just updated to 2.8.1 and same thing [03:51:50 CEST] <kecharitomene> I'll check use flags [03:52:09 CEST] <edman007> kecharitomene, are you building it yourself? [03:52:16 CEST] <kecharitomene> yeah [03:52:23 CEST] <kecharitomene> from emerge [03:53:08 CEST] <kecharitomene> Ah, it's the libass use flag I think [03:53:23 CEST] <edman007> yea [03:53:28 CEST] <edman007> you need libass [03:53:34 CEST] Action: edman007 wonders who named that library [03:53:39 CEST] <kecharitomene> lol [03:56:16 CEST] <DHE> SubStation Alpha subtitles? [04:19:53 CEST] <Prelude_Zzzzz> hello everyone [04:23:31 CEST] <Prelude_Zzzzz> can someone help me.. i am using ffmpeg -i to get a stream and i keep getting errors like " Failed to open segment of playlist 0 , errro 500 internal server error on the stream. It freezes up a lot and frame rate drops like crazy. The interesting part is running from the same location with VLC the stream is clean. What am i doing wrong ? [04:23:41 CEST] <Prelude_Zzzzz> is there a bug in ffmpeg ? [04:54:01 CEST] <edman007> Prelude_Zzzzz, a "500 Internal Server Error" is an HTTP error thrown by the server hosting it [04:54:15 CEST] <edman007> it's not ffmpeg, I think the server hosting the stream is down [04:54:49 CEST] <edman007> 500 errors and just crappy streaming is pretty common if the server is at max capacity [05:15:11 CEST] <Prelude_Zzzzz> doesn't seem that way though [05:15:16 CEST] <Prelude_Zzzzz> vlc doesn't even hickup [05:15:40 CEST] <Prelude_Zzzzz> is there some param that ffmpeg can use that download segments faster ? like download multiple at the same time if necessary ? [05:16:03 CEST] <Prelude_Zzzzz> maybe it is falling behind due to speed issues and then because the segments are being removed on the oposite side .. maybe by the time it tries to get the next chunk it is gone [05:16:29 CEST] <Prelude_Zzzzz> so, i am thinking .. there may be some variable that can get set to buffer or something the chunks to insure they are all available [08:31:44 CEST] <satiender> hi one can help me , Can I call ffmpeg command from .so file [08:32:22 CEST] <satiender> I mean I have all ffmpeg's .so file then can i call ffmpeg from them ?? [08:49:49 CEST] <JEEB> satiender: you can do what ffmpeg does but not command line of course [08:51:36 CEST] <satiender> JEEB : Thanks for reply [08:52:29 CEST] <satiender> You mean we can do only video programming like ffmpeg source [08:52:53 CEST] <satiender> but that is very hard task [08:52:57 CEST] <satiender> :( [08:53:33 CEST] <satiender> Can you help me for give some reference [08:53:46 CEST] <JEEB> the examples in doc [08:54:01 CEST] <JEEB> and the doxygen [08:54:24 CEST] <satiender> ok [08:54:43 CEST] <satiender> Yeah ! I already doing that [08:56:20 CEST] <satiender> but that is very time spending task [09:12:13 CEST] <claz> can I use ffmpeg to restream a rtsp stream? [09:12:25 CEST] <claz> like a proxy [10:10:42 CEST] <AndrewPRS> hi everyone!! I have compiled the example video encoder example and the video I'm getting is empty... I can't open it with vlc. Do you guys know what could be happening? [10:15:10 CEST] <fritsch> how large is the file and what does ffprobe say? [10:15:49 CEST] <k_sze> For videos encoded as yuv422p in H.264, is there a way to query how many bits or bytes where spent encoding a certain portion of a frame? [10:18:01 CEST] <k_sze> I have two videos from the exact same model of camera, both encoded as yuv422p in H.264. One of them has part of the field of view covered, so it appears mostly black. But this video somehow results in double the file size as the other one, given the same libx264 preset. [10:18:44 CEST] <k_sze> My hypothesis is that the covered area actually exhibits more noise, which means increased entropy. [10:19:31 CEST] <k_sze> But I need a way to confirm. The logical way would be if I can ask ffmpeg how many bits where spent encoding the covered region. [10:41:20 CEST] <satiender> Hi anybody can give some Idea how we can understand the source code of ffmpeg , [10:41:46 CEST] <satiender> because reading code is very time spending [10:42:00 CEST] <satiender> please help anybody know [10:43:24 CEST] <Anoia> understand for what purposes? [10:43:39 CEST] <Anoia> generally the documentation is the best place to start if you're using the library [10:43:45 CEST] <Anoia> (created form inline comments) [10:48:32 CEST] <satiender> Anoia : Actually I build ffmpeg for android , And I run some given simple examples of ffmpeg on android that is working perfectly [10:48:48 CEST] <satiender> these are simple examples some I did it [10:49:48 CEST] <satiender> But if I want create a ffmpeg any filter use its api for android that is very hard for me [10:50:13 CEST] <satiender> because that is more than 1500 line code and that is very time spending [10:50:49 CEST] <satiender> and in android I can only do programming not use command line because ffmpeg is not official for android [10:51:06 CEST] <satiender> So , that is reason I asking ?? [10:51:11 CEST] <satiender> please help [10:51:14 CEST] <satiender> :) [10:51:25 CEST] <xsi> I want go ffmpeg twitch. Why does ffmpeg https://bpaste.net/show/be6685d2ed8b has :0.0: Invalid argument https://bpaste.net/show/696d19c96207? ffmpeg -formats : https://bpaste.net/show/a770c31faabc "D x11grab X11 screen capture, using XCB" [10:51:29 CEST] <xsi> [x11grab @ 0x21af630] Cannot open display 0.0, error 5. [10:51:32 CEST] <xsi> 0.0: Input/output error [10:51:38 CEST] <Anoia> so why not read the extensive documentation, dipping into the code where needed? [10:52:14 CEST] <Anoia> if you think you need to read the code, but don't want to I don't know what I can suggest. [10:55:00 CEST] <satiender> Anoia : as simple I tell you , In android can use native programming (C / C++) , ffmpeg is in C , So , I want design a blur filter using ffmpeg API [10:55:12 CEST] <satiender> that is my target [10:55:53 CEST] <Anoia> ok? [10:55:54 CEST] <satiender> So , for that purpose I think Code reading is necessary [10:56:13 CEST] <Anoia> and what cant you get from the documentation? [10:56:37 CEST] <satiender> but in the documentation have only command line details [10:56:53 CEST] <satiender> there have no detail about source code working [10:57:03 CEST] <satiender> and about libraries [10:57:23 CEST] <Anoia> no, the api documentation contains the api documentation [10:57:48 CEST] <satiender> I following dranger.com tutorial , but that is only for make a player [10:57:53 CEST] <satiender> ok [10:58:30 CEST] <Anoia> https://www.ffmpeg.org/documentation.html [10:58:56 CEST] <Anoia> scroll down [10:59:42 CEST] <furq> satiender: http://www.ffmpeg.org/doxygen/2.8/dir_687bdf86e8e626c2168c3a2d1c125116.html [11:01:04 CEST] <satiender> furq : Thanks for reply , I also following that link [11:01:06 CEST] <Anoia> at the very least, Google for "ffmpeg functionname" gives the api docs [11:02:20 CEST] <BullHorn> im getting a bunch of 'Past duration 0.999992 too large' errors when reencoding a video [11:02:26 CEST] <BullHorn> i have no idea what might be causing the problem [11:02:29 CEST] <BullHorn> it only happens when i use NVENC in OBS, doesnt happen with quicksync or x264 [11:02:36 CEST] <BullHorn> can someone take a look at the file? or should i provide something else ;x [11:02:39 CEST] <BullHorn> https://mega.nz/#!KllDnDyL!NWN8vmzBZCkH2Q9z5HbTIKoYT4rIoh6fi9mbMasTnBw [11:03:19 CEST] <satiender> furq : but there have very less details [11:03:40 CEST] <furq> BullHorn: they're warnings, not errors [11:03:54 CEST] <furq> if there's no issue with the output video then it's safe to ignore them [11:03:56 CEST] <BullHorn> does this slow down the re-encode? [11:04:05 CEST] <furq> i doubt it [11:05:36 CEST] <furq> if the logging is slowing it down you can use -loglevel error [11:15:17 CEST] <Anoia> satiender: the documentation will have less detail than the code by its very nature, but it gives you thebasic framework, which you can expand on by lookign at specific bits of the code [11:22:30 CEST] <satiender> Anoia : Thankyou [11:22:51 CEST] <satiender> There have no other resource for development [11:22:53 CEST] <satiender> ?? [11:23:12 CEST] <Anoia> apart form the code and the documentation? [11:23:17 CEST] <Anoia> I don;t know of any other [11:23:30 CEST] <Anoia> various tutorials online [11:23:43 CEST] <satiender> ok [11:24:02 CEST] <Anoia> what is it you're not getting fromt he docs? [11:24:25 CEST] <satiender> Anoia : Thanks for giving your expensive time to me :) [11:24:26 CEST] <Anoia> you've not said what's missing bar "less details" [11:24:56 CEST] <satiender> ???? [11:25:02 CEST] <satiender> missing bar ?? [11:25:24 CEST] <Anoia> except [11:25:54 CEST] <Anoia> all you've said is wrong is that the docs have "very less details" [11:27:00 CEST] <satiender> Anoia : ????? [11:27:50 CEST] <satiender> I said regarding code elaboration only , docs have just for use of ffmpeg command line [11:31:06 CEST] <Anoia> so you've not yet seen the code documentation I ave you link to? [11:34:21 CEST] <satiender> Anoia : Sorry ! [11:34:26 CEST] <satiender> I got it [11:34:38 CEST] <satiender> thanks I following now [11:34:44 CEST] <satiender> :) [11:37:24 CEST] <Anoia> there's wuite a bit more detail there :) [11:41:15 CEST] <satiender> yes [11:41:20 CEST] <satiender> I am wrong [11:41:26 CEST] <satiender> :) [11:44:50 CEST] <Anoia> it happens occasionally :p [11:53:33 CEST] <BullHorn> when i use ffmpeg to reencode with veryfast preset, does it use fullrange color? [11:53:35 CEST] <AndrewPRS> fritsch, sorry I forgot to answer. The problem is solved now I was not putting the encoded frames inside a container ... thank you [11:59:56 CEST] <satiender> Anoia : I have one another question but that is related to command line [12:00:36 CEST] <satiender> I have a .mp4 file I convert it in .ts because I want transfer it on the network and alos play live [12:02:13 CEST] <satiender> but when I transfer it on over the network , at receiving end that not play proper that is very fast [12:03:02 CEST] <satiender> I use : ffmpeg -i video.ts -vcodec copy -acodec copy -f mpegts udp://227.40.50.60:1234 [12:03:36 CEST] <satiender> so there have any solution ?? [12:03:42 CEST] <satiender> anyone can help me [12:03:44 CEST] <satiender> ????? [12:19:52 CEST] <martijnb> what is the problem? [12:20:07 CEST] <martijnb> it doesn't play properly? [12:28:57 CEST] <c_14> satiender: -re [12:30:06 CEST] <satiender> I mean one end I transfer the video and same time that is playing on another side which one i transferring that time [12:30:32 CEST] <satiender> video transferring is very fast as compare to normal video playing [12:30:39 CEST] <furq> satiender: listen to c_14 [12:30:58 CEST] <satiender> furq : ?? [12:31:04 CEST] <satiender> ok [12:31:39 CEST] <martijnb> I still haven't decyphered what the problem is [12:38:20 CEST] <satiender> matijnb : Can you give your few important mins , then I elaborate my problem , and believe me that is very interesting and also a big drawback in video streaming [12:44:46 CEST] <satiender> c_14 : [12:45:01 CEST] <satiender> matijnb : [12:45:23 CEST] <satiender> I elaborate the biggest problem in video streaming [12:46:12 CEST] <satiender> I capturing the destop and streaming that on network with multicast i [12:46:14 CEST] <satiender> ip [12:46:31 CEST] <satiender> at receiving end that is playing [12:47:07 CEST] <satiender> but when i analysis it in stream guru or some other video detectors like dictac [12:47:23 CEST] <satiender> there shows very large amount of jitters [12:47:57 CEST] <satiender> aproxy mate 50.00 jitter value [12:48:38 CEST] <satiender> but according to theory jitter value it 0.500 ns is acceptable [12:49:02 CEST] <satiender> so problem is that how we can over cum the network jitter [13:15:08 CEST] <satiender> ???????????? [13:19:51 CEST] <BtbN> sub 1ns jitter, what? [13:29:01 CEST] <martijnb> so you're streaming it over an unstable network? [13:30:30 CEST] <Mavrik> If I can understand anything through that english. [13:30:36 CEST] <Mavrik> He's not syncing on PCR :) [13:52:31 CEST] <superware> can someone please help me promote trac.ffmpeg.org/ticket/4893 ? [15:03:03 CEST] <xsi> Is paid soft - xsplit better? [15:40:33 CEST] <martijnb> better is a relative term [15:40:47 CEST] <martijnb> better than what? [15:41:00 CEST] <martijnb> to do what? [15:44:40 CEST] <superware> can someone please help me verify http://trac.ffmpeg.org/ticket/4893#comment:19 ? [15:45:02 CEST] <mat_ev> hi, I have a question about using ffmpeg to process and segment an mpeg-ts stream (into HLS), I used stream_segment format output, "-c copy -map 0" to copy all existing streams as-is, HOWEVER my problem is that the result Mpeg-ts chunks are missing some of the original mpeg-ts PIDs [15:45:08 CEST] <mat_ev> namely ECMs [15:45:19 CEST] <mat_ev> I tried using "-copy_unknown" but this doesn't help [15:45:20 CEST] <durandal_1707> verify what? [15:45:43 CEST] <mat_ev> any suggestion as how to preserve ALL original PIDs in mpeg-ts would be highly appreciated, thanks! [15:45:55 CEST] <DHE> mat_ev: somewhat tangental, there is an -f hls format which may be better suited [15:46:11 CEST] <superware> durandal_1707: that you can reproduce :) [15:46:19 CEST] <mat_ev> DHE: I tried this as well, same result [15:46:34 CEST] <mat_ev> resulting mpeg-ts has video, audio, subtitles, pat, pmt, sdt [15:46:43 CEST] <mat_ev> but no other PIDs (like ECMs) [15:46:59 CEST] <DHE> that's the crypto stuff right? [15:46:59 CEST] <xsi> martijnb mb better for combining streaming [15:47:24 CEST] <xsi> for expensive device support, more possibilities, more flexible?// [15:47:45 CEST] <mat_ev> right, ECM carry crypto information, my mpeg-ts is already encrypted and ready for decryption on end-devices, it's only a matter of cutting it into small HLS chunks, which ffmpeg does well, only losing some of the PIDs :( [15:47:55 CEST] <Mavrik> mat_ev, are other PIDs actually emitted often enough to make it in all segments? [15:48:07 CEST] <martijnb> combining streaming meaning? [15:48:16 CEST] <DHE> mat_ev: the HLS spec has its own encryption spec. you sure this is going to work in the first place? [15:48:32 CEST] <martijnb> I'd only use xsplit to do stream live captured content [15:48:59 CEST] <xsi> already captured? [15:49:06 CEST] <xsi> *and more quick.. [15:49:14 CEST] <mat_ev> Mavrik: other PIDs make it fine [15:49:21 CEST] <martijnb> if you're just streaming recorded content, there's hardly a point in using xsplit.. [15:49:44 CEST] <mat_ev> but even when ffmpeg starts processing the original mpeg-ts I can only see video audio and subs streams, no mention of other PIDs [15:50:27 CEST] <Mavrik> mat_ev, it's totally possible that ECM just isn't recognised and it's discarded. [15:50:28 CEST] <xsi> i'm new to this all i've just made a supposition that paid version is much more good [15:50:37 CEST] <mat_ev> DHE: yeah, the solution we're using is based on Marlin DRM, they handle encryption a little differently than the original HLS specification, each chunk carries ECM info [15:51:01 CEST] <xsi> i've never streamed or read smth .. to start with smth [15:51:11 CEST] <mat_ev> Mavrik: probably you're right, my question is: is there a way to force copying it? as I said -copy_unknown does not seem to help [15:51:45 CEST] <Mavrik> mat_ev, if the prober didn't detect it (you don't see the stream) then the command line switches probably won't do a thing [15:51:48 CEST] <martijnb> ok, well, if you want to know the difference between the free trial and subscription versions of xsplit, I'm sure they have a lot of information on their website [15:51:53 CEST] <Mavrik> mat_ev, should report a bug with a .TS sample [15:52:27 CEST] <martijnb> if you want free alternatives like xsplit, there's OBS [15:52:42 CEST] <xsi> ok it's a very nice point of theirs that they've got much info support [15:52:59 CEST] <martijnb> but neither of those really relate to this channel :p [15:53:49 CEST] <mat_ev> Mavrik: ok, so "the prober" will only know how to handle predefined stream types? like audio/video/subs? I can't use my private section data in mpeg elementary stream? [15:54:15 CEST] <Mavrik> I'd have to check the source what it does about those streams :/ [15:55:23 CEST] <mat_ev> well it seems that way:( it's a shame, because otherwise it would really suit our needs [15:55:32 CEST] <mat_ev> thanks for your help [15:56:21 CEST] <xsi> does one need a deep background in bitrate theory or so.. to be truly a person who uses ffmpeg professionally? [15:56:27 CEST] <DHE> mat_ev: I've dealt with a similar situation with a different DRM provider. mpegts chunk encryption isn't (officially) compatible with HLS which calls for a more [15:56:29 CEST] <xsi> sorry for my "russian" [15:56:38 CEST] <DHE> 'openssl enc' style of encryption [15:57:07 CEST] <xsi> which branch of science lies under ffmpeg? [15:58:06 CEST] <mat_ev> DHE: ok, what is your experience? did you end up using some other tool? or changing your encryption requirements? [15:58:36 CEST] <mat_ev> DHE: the thing is we already have the content encrypted, how we just wanted to chunk it up for HTTP delivery [15:58:50 CEST] <mat_ev> *now [16:00:23 CEST] <rocktop> I have compiled libfdk_aac but I am still enable to use it with ffmpeg I have this issue : Unknown encoder 'libfdk_aac' [16:00:42 CEST] <c_14> Did you then compile ffmpeg against libfdk_aac? [16:01:01 CEST] <rocktop> c_14: ./configure --prefix="$HOME/ffmpeg_build" --extra-cflags="-I$HOME/ffmpeg_build/include" --extra-ldflags="-L$HOME/ffmpeg_build/lib" --bindir="$HOME/bin" --pkg-config-flags="--static" --enable-gpl --enable-nonfree --enable-libfdk-aac --enable-libfreetype --enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 [16:01:17 CEST] <rocktop> c_14: yes I did [16:01:18 CEST] <c_14> Are you executing the correct version? [16:01:31 CEST] <c_14> Check the configure flags ffmpeg prints when it's executing. [16:02:00 CEST] <rocktop> c_14: ffmpeg version ? [16:02:15 CEST] <c_14> ie: ffmpeg -version [16:02:22 CEST] <c_14> The correct build per se [16:02:31 CEST] <c_14> If you have more than one on your system (which does happen). [16:04:19 CEST] <rocktop> c_14: ffmpeg version ? [16:04:29 CEST] <c_14> ie: ffmpeg -version [16:04:30 CEST] <c_14> The correct build per se [16:04:32 CEST] <c_14> If you have more than one on your system (which does happen). [16:04:47 CEST] <rocktop> I was disconnected [16:06:00 CEST] <rocktop> c_14: http://pastie.org/private/xjfhn2ouhv5pgztznjlaw [16:06:18 CEST] <c_14> >configuration: --enable-libx264 --enable-gpl [16:06:23 CEST] <c_14> that's the wrong version [16:06:35 CEST] <c_14> Did you run make install after compiling the new ffmpeg? [16:06:44 CEST] <c_14> is $HOME/bin in your path [16:06:59 CEST] <c_14> is $HOME/bin in your path ahead of other bin locations that might contain an ffmpeg binary [16:06:59 CEST] <rocktop> c_14: yes I have [16:07:42 CEST] <rocktop> c_14: no it is not in the path [16:08:46 CEST] <rocktop> c_14: http://pastie.org/private/hhxjzfjojjmt6srm72apia [16:09:16 CEST] <rocktop> c_14: still having Unknown encoder 'libfaac' [16:09:36 CEST] <c_14> Because you didn't build with libfaac? [16:09:39 CEST] <c_14> You built with libfdk_aac [16:10:03 CEST] <rocktop> c_14: oh yes sorry [16:11:31 CEST] <rocktop> c_14: thank you very much I really appreciate your help [16:47:49 CEST] <efesto> Good afternoon all, has there been any regression reported on drawtext timecode ? [16:48:54 CEST] <efesto> adding this to my command triggers a segfault :drawtext=fontfile=/home/efesto/devel/efesto/efesto-ftrack-deploy/modules/efestolab/efesto-submit/source/efesto_submit/profile/settings/fonts/lato.ttf:timecode=\'00:00:00:00\':r=25.0:fontcolor=white@1:fontsize=28:x=50:y=50-text_h [16:50:37 CEST] <c_14> What version are you using? [16:52:28 CEST] <efesto> latest stable [16:52:35 CEST] <efesto> here is a command to reproduce : [16:52:38 CEST] <efesto> ffmpeg -thread_queue_size 512 -hwaccel auto -threads 0 -y -r 25.0 -start_number 1 -i "/usr/tmp/tmpyCJaTB.%4d.png" -c:v libx264 -crf 18 -preset slow -strict -2 -movflags faststart -pix_fmt yuv420p -filter_complex "[0:v]null,scale=1920:1080, [16:52:38 CEST] <efesto> drawtext=timecode=\'00:00:00:00\':r=25.0:fontcolor=white@1:fontsize=28:x=50:y=50-text_h[clip];[clip]scale=1920:1080, fps=25.0, setdar=16:9[v]" -map [v] /home/efesto/Desktop/foobar.mov [16:53:09 CEST] <efesto> here is the version : ffmpeg [16:53:09 CEST] <efesto> ffmpeg version 2.8.1-static http://johnvansickle.com/ffmpeg/ Copyright (c) 2000-2015 the FFmpeg developers [16:53:09 CEST] <efesto> built with gcc 4.9.3 (Debian 4.9.3-4) [16:54:15 CEST] <efesto> replace timecode with text and it'll be working [16:54:36 CEST] <efesto> do you want me to open a bug report ? [16:56:59 CEST] <c_14> If you can reproduce with current git head, yes. [16:57:07 CEST] <c_14> You can just take the git static build [16:57:25 CEST] <efesto> I'll give it a shot now [16:57:27 CEST] <efesto> hang on [16:59:01 CEST] <efesto> yep [16:59:04 CEST] <efesto> segfault [16:59:11 CEST] <efesto> ffmpeg version N-50577-g777b305-static http://johnvansickle.com/ffmpeg/ Copyright (c) 2000-2015 the FFmpeg developers [17:01:23 CEST] <c_14> Then yes, please. [17:01:25 CEST] <c_14> https://ffmpeg.org/bugreports.html [17:01:39 CEST] <efesto> on it [17:01:40 CEST] <efesto> cheers [17:01:45 CEST] <c_14> If you can provide the gdb backtrace etc as listed under the "crash bug" thing it would be very helpful. [17:01:59 CEST] <efesto> I'll check [17:02:39 CEST] <Sir_Leto> Question, is it possible to change a headers on a stream after encoding? I tried to copy an hevc stream from a TS file into and MP4, and now the stream is incorrectly labeled as mp4 instead of hevc [17:03:48 CEST] <c_14> You mean metadata? [17:03:52 CEST] <Sir_Leto> YES [17:04:00 CEST] Last message repeated 1 time(s). [17:04:34 CEST] <Sir_Leto> It's simply labeled wrong and therefor the video stream isn't playable [17:05:29 CEST] <c_14> You can change most metadata. [17:05:53 CEST] <c_14> https://ffmpeg.org/ffmpeg.html#Main-options look for -metadata [17:07:23 CEST] <efesto> https://trac.ffmpeg.org/ticket/4945#ticket [17:07:34 CEST] <efesto> done, couldn't use ffmpeg_g , so I did run with -v debug [17:07:38 CEST] <efesto> hope is enough [18:12:37 CEST] <BasisBit> I am using the shared ffmpeg library in my application. any suggestion on what would be the best way to sync video playback to my SDL/bass audio-file-playback? [18:15:28 CEST] <JEEB> pts are for prewentation [19:24:01 CEST] <maletor> can i use ffmpeg for passthrough audio to my audio card? [19:37:09 CEST] <xsi> This config works but without sound. Sound appears only first seconds [19:37:10 CEST] <xsi> ffmpeg -f alsa -ac 2 -i hw:0,0 -f x11grab -framerate 30 -video_size 1280x1024 -i :0.0+0,0 -vcodec libx264 -preset veryfast -maxrate 1984k -bufsize 3968k -vf "format=yuv420p" -g 60 -acodec libmp3lame -b:a 96k -ar 44100 -f flv [19:37:34 CEST] <xsi> which bitrate and where to choose because: Past duration 0.994331 too large [19:40:13 CEST] <xsi> https://bpaste.net/show/2892dc00ec3d [19:40:22 CEST] <xsi> Here is the mouse-copied output [19:51:39 CEST] <xsi> https://bpaste.net/show/ca46c5b25e94 [19:55:06 CEST] <Wader8> hello [19:55:46 CEST] <Wader8> i do not know why does ffmpeg always say "input stream set from yuv420p to nv12" when i have the pix_fmt set in the cmd [19:56:41 CEST] <Wader8> i am converting some apparently? non-interlaced dvd video with 2:3 pulldown [19:57:42 CEST] <Wader8> I'm not sure what the FPS of the source film is, since it's not a hollywood film, but "amateur", it's, the DVD metadata says it's made for digital television [19:58:39 CEST] <Wader8> mediainfo reports 23,976 in both the VOBs (and concated VOB which im using) and in MP4 HEVC [19:59:39 CEST] <Wader8> i finally got the proper cmd to get the audio sync working, seems like decimate is not needed here, only pullup and not both, I will also try removing fieldmatch now [20:00:06 CEST] <Wader8> to see if only pullup is needed [20:02:19 CEST] <Wader8> i didn't change the size, i did had scale in vf (matching source) but i removed that and nothing negative happened, becuase it reports the size changed (same as input) but I'm not sure what's overrding pix_fmt [20:02:30 CEST] <Wader8> oh maybe HEVC is overriding pix_fmt ? [20:03:06 CEST] <JEEB> pastebin your command line and full terminal output [20:03:08 CEST] <JEEB> and link it here [20:04:40 CEST] <Wader8> http://pastebin.com/29kr6vJB [20:06:28 CEST] <Wader8> i was doing some DVD conversion for the past year have finished that, only to find out today that DUP messages mean duplicated frames so even tho reading up on telecine, pulldown, i didn't do enough researching i guess [20:06:56 CEST] <Wader8> so now I didn't got tons of dup messages, but this is unrelated to the other DVDs from months ago [20:07:25 CEST] <JEEB> can insert -v debug somewhere before the input? [20:07:35 CEST] <JEEB> it will output a lot of stuff but you can stop it right after it starts encoding [20:07:40 CEST] <Wader8> -v 8 is not enough ? [20:07:58 CEST] <JEEB> no idea what log level that maps to [20:08:04 CEST] <JEEB> I only use the named values [20:08:10 CEST] <Wader8> i also found about -v 9 today lol [20:08:31 CEST] <Wader8> no actually, i found someone using -v 9 and -loglevel 99 [20:08:32 CEST] <JEEB> anyways, nv12 should only happen when hw decoding is somewhere in the chain [20:08:57 CEST] <Wader8> i also found about hwaccell today, never knew this command existed [20:09:31 CEST] <JEEB> Input stream #0:0 frame changed from size:720x480 fmt:yuv420p to size:720x480 fmt:nv12 <- basically means that the decoded input became nv12 (which usually hints at HW decoding) [20:09:48 CEST] <Wader8> literally hours ago I put it together, google worked good today, im not sure if the -vf fps=24000 is correct for my source DVD but seems like im on a proper road now that the audio works [20:10:19 CEST] <JEEB> I am definitely not going to comment jack shit about your correctness of dealing with the content since I really don't feel like lecturing anyone tonight [20:11:00 CEST] <JEEB> but yeah, seems like either there's some preference for nv12 with the mpeg-2 decoder, or you're using HW decoding (more probable) :P [20:11:42 CEST] <Wader8> hehe okay, i was commenting, not asking, i have abandoned previous project cause I found someone has already mastered those DVDs for modern progressive, interlace removed and pulledup, and with advanced params it looks much better than source DVDs [20:12:19 CEST] <Wader8> this here, is just a few DVDs for archival [20:13:09 CEST] <Wader8> well i didn't abandon, i just switched the sources over to the x264 ones [20:13:24 CEST] <Wader8> one moment pastebin asap [20:14:06 CEST] <JEEB> also I find it funny how your buffer size is for... (300/2400) of a second [20:14:26 CEST] <JEEB> + I will have to say to you that you never, ever want to use minrate [20:14:31 CEST] <JEEB> maxrate+bufsize is all you need [20:14:59 CEST] <JEEB> also if you are doing 1pass encoding, for the love of whatever on earth use crf rate control and limit it with maxrate+bufsize [20:18:10 CEST] <Wader8> moment have problem copying cmd, have to add command to output to file [20:21:25 CEST] <Wader8> JEEB: okay this is with -v 9 and -loglevel 99 http://pastebin.com/G9kaQS7g [20:22:02 CEST] <Wader8> apparently loglevel 99 is above "debug" if the documentation is not obsolete, but i never saw -v before so not sure about that [20:22:17 CEST] <Wader8> brb i have to go to WC i'll read when i come back [20:25:12 CEST] <JEEB> Wader8: unfortunately it doesn't really tell much at all [20:25:31 CEST] <JEEB> but I still hold onto my theory of it just getting HW decoded with DXVA2 or something [20:25:38 CEST] <JEEB> nothing else outputs NV12 out of the decoder [20:26:03 CEST] <JEEB> mostly because you then have to convert it to planar YCbCr (yuv420p) in order to do something with it in ffmpeg [20:50:31 CEST] <Fozzy> I'm a newbie to ffmpeg, and was trying something out with ffplay. I was curious about CPU usage, and noticed it was using about 5% cpu. I specified "-nodisp -nostats" as arguments. Is there something basic that ffmpeg does that causes it to use the extra CPU time, compared to a few other players which mostly hover at 0%? [20:52:20 CEST] <JEEB> well if you are not doing decoding on the cpu and have no-copy rendering then of course you will have very low cpu usage (but on the other hand, higher (i)GPU usage because the ASIC is working for the decoding), although it still shouldn't be 0% because you have parsing and audio decoding as well as possible subtitles to deal with [20:52:27 CEST] <JEEB> also ffplay should not be benchmarked against [20:52:33 CEST] <JEEB> it's not a proper player [20:52:45 CEST] <JEEB> it's a proof of concept basic player that lets you test some things, maybe [20:54:53 CEST] <Fozzy> I apologize, I actually missed (an important?) note when I asked my original question. The media I am playing is a simple wav file, no video involved. [20:55:22 CEST] <Mavrik> I'm not sure what the question is :/ [20:55:47 CEST] <JEEB> Fozzy: in that case it's just ffplay's output not being exactly optimized - whatever audio output it uses [20:56:03 CEST] <JEEB> in which case I will just point towards the fact that ffplay is not a "real player" [20:56:22 CEST] <JEEB> you are of course free to improve it, but it is supposed to be just a thing to test with [20:56:24 CEST] <Fozzy> JEEB: Thank you! That does help a lot and I can look further [20:56:26 CEST] <JEEB> not an actual player [20:57:27 CEST] <Fozzy> I wasn't sure if it was naturally doing some FFT or histogram calculations (which might have been used for the display, if it had been activated) [20:57:48 CEST] <Fozzy> but I'll look through it and see what I can find. Thanks again! [21:43:55 CEST] <tomas2> Hello [21:45:45 CEST] <durandal_1707> hello [21:46:27 CEST] <tomas2> I got one question. I compiled ffmpeg on raspbian with configuration ./configure --arch=armel --target-os=linux --enable-gpl --enable-libx264 --enable-nonfree but when I write -vcodec libx264 I get error Illegal Instruction [21:47:33 CEST] <Wader8> JEEB: but is NV12 anything special, will the video be less compatible, i am not as familiar but i will try to look up, if I fail i would appreciate your input [21:47:54 CEST] <JEEB> same video data in another way [21:47:57 CEST] <Wader8> it is working for me in MPC-HC but ... [21:48:22 CEST] <JEEB> anyways, not like the input colorspace means anything as you are setting an output colorspace [21:48:25 CEST] <Wader8> it may have some HDTV compatability issues? [21:48:51 CEST] <Wader8> but it's not meant for HDTV, im just wondering [21:49:09 CEST] <Wader8> it's meant for archival, at least something in the future to be able to open it [21:49:37 CEST] <Wader8> sorry I am unfamiliar with colorspaces in the ffmpeg context, i do only know basics [21:51:37 CEST] <anYc> benbro: I think I got it now. could you check if you can cut your h264 mp4 and mkv with avcut? (https://github.com/anyc/avcut) [21:52:03 CEST] <tomas2> Thank you ... here is the pastebin: http://pastebin.com/NkF7Q5js [21:52:37 CEST] <Wader8> mediainfo still says YUV 420 in the output [21:52:55 CEST] <Wader8> but i've seen mediainfo not being accurate in the past so [21:53:12 CEST] <JEEB> Wader8: pix_fmt yuv420p is 4:2:0 YCbCr. [21:53:24 CEST] <JEEB> so, uh, yeah [21:53:27 CEST] <Wader8> well I know that ... [21:53:36 CEST] <JEEB> then what [21:53:54 CEST] <JEEB> I don't think you have an issue do you :P [21:54:05 CEST] <Wader8> well i didn't understand what you meant with one of the responses ... maybe i am also misunderstanding the log from ffmpeg [21:54:30 CEST] <Wader8> but now i think I get it, you think it's being transformed to nv12 for the GPU then back to yuv420 ? [21:54:39 CEST] <JEEB> nv12 is the source colorspace and it is also 4:2:0, a form of packing the chroma stuff together and luma being separate. GPUs love it and HW decoders output it [21:55:05 CEST] <JEEB> so as ffmpeg gets it, it shuffles the bytes again in memory to get fully planar YCbCr again :P [21:55:20 CEST] <Wader8> aha, so HW decoder outputs that, but ffmpeg puts it back into ordinary yuv420 then ? [21:55:33 CEST] <Wader8> aha aha, okay, now i get it [21:55:55 CEST] <JEEB> I actually wonder how much you are losing speed because of the conversion [21:55:57 CEST] <durandal_1707> tomas2: open bug report on bug tracker [21:56:04 CEST] <JEEB> compared to how much you are getting speed with the HW decoding [21:56:42 CEST] <Wader8> well, i'm just testing, if it's faster without i'll turn it off, i'm not required to use HW [21:58:37 CEST] <durandal_1707> tomas2: yes, that is our bot [21:58:42 CEST] <Wader8> but, i think it isn't being worded correctly, i'll test it without HW, then i'll objectively try to understand it to not make false assumption, only then i'll submit a tract [22:01:20 CEST] <benbro> anYc: trying [22:02:08 CEST] <benbro> anYc: in the readme, you mixed the installation instructions of libav and ffmpeg :) [22:05:58 CEST] <anYc> uhm, doesn't libav*-ffmpeg-dev install ffmpeg on libav-based ubuntus? [22:06:49 CEST] <JEEB> if it's new enough, yes [22:06:56 CEST] <JEEB> starting with 15.04 I think [22:13:22 CEST] <anYc> okay thanks! maybe benbro meant something else [22:29:44 CEST] <Wader8> JEEB CRF doesn't work in libx265 params, should this be noted in https://trac.ffmpeg.org/ticket/4284 or not, because the OP doesn't mention CRF. [22:30:23 CEST] <JEEB> -crf XX should work, check the output that libx265 gives regarding the options it uses [22:30:26 CEST] <Wader8> but i guess the guys who fix stuff might check all of them not just the one's mentioned, still, there's a lot of params i hope it's not a lot of code per param [22:31:18 CEST] <JEEB> but yes, with many other parameters you have to use -x265-params <actual libx265 API settings in key=value pairs> [22:31:23 CEST] <Wader8> well without the param comman CRF won't work, ffmpeg works otherwise, it just ignores the value, anywhere i set it below 28 it always used 300kbps bitrate [22:31:55 CEST] <JEEB> tell me what libx265 tells you [22:32:02 CEST] <JEEB> if you set -crf after input [22:32:08 CEST] <JEEB> it should match [22:32:16 CEST] <JEEB> if not, you have an old FFmpeg I'm pretty sure [22:32:18 CEST] <Wader8> after input ? [22:32:25 CEST] <Wader8> i downloaded it a few hours ago [22:32:35 CEST] <JEEB> after the input, as in -i herpderp_input.file [22:32:40 CEST] <Wader8> zeranoe winX64 [22:32:53 CEST] <JEEB> please answer the question [22:33:03 CEST] <JEEB> if you set crf value to something, does libx265's output follow or not [22:33:15 CEST] <JEEB> crf is an encoder setting, and thus you have to set it after the input [22:33:34 CEST] <JEEB> (as opposed to decoder options that are put before the input) [22:33:41 CEST] <Wader8> yeah i put it after the input, oh i mixed with "before" ... yes there is an error if it's used without the "param command" but if i do it properly, it doesn't do any errors or warnings [22:33:53 CEST] <JEEB> jesus christ [22:33:57 CEST] <Wader8> i can show you example with CRF at zero [22:33:58 CEST] <JEEB> is it that hard to just asnwer [22:34:00 CEST] <JEEB> *answer [22:34:13 CEST] <Wader8> let me read what you wrote, moment [22:34:15 CEST] <JEEB> if you put crf 14 f.ex. after -i [22:34:21 CEST] <JEEB> as in, after the input file [22:34:28 CEST] <JEEB> what does libx265 itself output to you [22:34:38 CEST] <JEEB> it outputs the parameters it uses on the general level onto the terminal output [22:34:43 CEST] <JEEB> CRF is there [22:35:13 CEST] <JEEB> also just to count out stupidity and mistakes, please pastebin full command line as well and link it here [22:36:09 CEST] <Wader8> roger, just, what I meant with "didn't work" wasn't literally [22:38:00 CEST] <JEEB> just fucking post the information/result and we'll go further from there. not exactly rocket science, is it [22:38:15 CEST] <benbro> For Ubuntu versions with libav as default, e.g., 15.04: [22:38:22 CEST] <benbro> apt-get install libavcodec-ffmpeg-dev libavformat-ffmpeg-dev libavutil-ffmpeg-dev [22:38:30 CEST] <benbro> it should be the instruction for ffmpeg [22:38:38 CEST] <benbro> anYc: ^^ [22:38:59 CEST] <benbro> ok, maybe I missread the instructions [22:42:48 CEST] <anYc> ok, I see what you mean [22:44:01 CEST] <anYc> but it's time to go to bed know, good night [22:44:29 CEST] <benbro> good night [22:45:37 CEST] <Wader8> sorry jeeb i got a lot of stuff on taskbar had to save&close down, in a moment [22:48:31 CEST] <Wader8> here http://pastebin.com/Ze2gswSU [22:49:12 CEST] <JEEB> uhh [22:49:21 CEST] <benbro> anYc: got an error: frame for pkt #214 (dts 16535900) not found [22:49:21 CEST] <JEEB> try with -crf 18 [22:49:33 CEST] <JEEB> although wait [22:49:35 CEST] <JEEB> uhh [22:49:36 CEST] <benbro> anYc: on another mp4. I'll try to create a test case and share [22:49:56 CEST] <JEEB> Wader8: I'll let you guess wtf you are doing wrong by this error message "[libx265 @ 0000000002b1b060] Unknown option: -crf." [22:50:17 CEST] <JEEB> hint: -crf is an ffmpeg option, libx265 parameter is just "crf" [22:50:50 CEST] <Wader8> well doesn't look like it appears visible in the CMD [22:50:52 CEST] <JEEB> leave out the -x265-params and just do -crf XX [22:51:13 CEST] <Wader8> i must have used the = back then they why it stopped in error [22:52:29 CEST] <Wader8> but i am sure that there's a bug in the output color let me test [22:52:43 CEST] <JEEB> you are setting -pix_fmt yuv420p and are getting 4:2:0 encoded as you are asking, please tell me more [22:53:55 CEST] <Wader8> JEEB, well okay I surrender, because I use verbose output, the whole screen scrolled down as it was a lot of text, so the error is cyan-yellow and it appeares in early [22:54:27 CEST] <Wader8> oh, it's not an error, a warning, so it doesn't stop the conversion [22:54:33 CEST] <JEEB> ffmpeg -your -parameters 2> hurrdurr.log [22:54:50 CEST] <JEEB> 2> redirects standard error [22:55:02 CEST] <JEEB> which is where ffmpeg outputs its stuff [22:55:16 CEST] <JEEB> (because standard output can be used for piping output of actual data) [22:55:31 CEST] <Wader8> i forgot what 2> means, i just pulled it off the internet last time i needed logfile output [22:55:51 CEST] <Wader8> because i neede it quickly i didn't read up on 2> [22:58:26 CEST] <Wader8> well maybe i can put a suggestion into trac to treat -crf as error not warning [00:00:00 CEST] --- Tue Oct 20 2015

1 0

ffmpeg-devel.log.20151018
by burek 19 Oct '15

19 Oct '15

[00:06:37 CEST] <BBB> TD-Linux: but that only makes sense if you scale references on resize [00:06:53 CEST] <BBB> TD-Linux: here, you scale ref data pixels in the block decoding loop as part of mc [00:06:55 CEST] <TD-Linux> BBB, right, versus scaling in MC [00:07:04 CEST] <BBB> TD-Linux: so it doesnt matter how many refs you keep, there is no overhead [00:07:19 CEST] <BBB> its just that the mc itself is super slow [00:07:25 CEST] <BBB> (if the ref is scaled) [00:08:27 CEST] <nevcairiel> wouldnt it potentially be faster to just upscale the refs once [00:08:32 CEST] <TD-Linux> yeah that seems a lot worse than doing a scale ahead of time imo [00:09:47 CEST] <J_Darnley> kierank: did you start on that drawutils function you asked about? [00:10:07 CEST] <TD-Linux> the memory bandwidth penalty of doing the one scale ahead of time seems better than the rather ridiculous upper bound of mc complexity [00:13:49 CEST] <BBB> the bound issue is solved by limiting scale factors [00:13:50 CEST] <nevcairiel> maybe they considered changing the size may happen often and refs stay long [00:13:56 CEST] <BBB> I believe it can go only up by 2 and down by 4 [00:14:00 CEST] <BBB> or the other way around [00:14:23 CEST] <BBB> anyway, its this way, sorry :( [00:14:28 CEST] <BBB> vp9 is finished, its not changing [00:44:00 CEST] <TD-Linux> well I'm probably going to add this sort of feature in Daala at some point, so there's room to do it correctly there :) [00:48:20 CEST] <atomnuker> TD-Linux: do you know if daala will use profiles [01:00:00 CEST] <cone-569> ffmpeg 03Ganesh Ajjanagadde 07master:62144b225d07: avfilter/internal: Doxygen for ff_fmt_is_in [01:55:30 CEST] <TD-Linux> atomnuker, not sure yet, ideally there wouldn't be any profiles. the big sticking point is 8-bit references [02:02:37 CEST] <cone-569> ffmpeg 03Paul B Mahol 07master:002b0499b62e: avfilter/af_ladspa: check functions return value in query_formats [03:49:02 CEST] <kierank> J_Darnley: not yet [03:52:14 CEST] <kierank> I don't see how the report is rude if I can't get gdb to backtrace [04:45:22 CEST] <J_Darnley> kierank: I was going to say I would start some work on it next time my game crashed but that never happened. [04:45:34 CEST] <J_Darnley> It is now 04.45 so I'm going to bed. [04:46:01 CEST] <J_Darnley> I might start poking at it "tomorrow" [11:42:00 CEST] <highgod> Hi, I want to ask a question, does ffserver support rtsp serfor for hevc stream? Thanks [12:12:58 CEST] <cone-384> ffmpeg 03Michael Niedermayer 07master:b379e1d6dfe2: avcodec/mpegvideo_enc: Factor new_picture unref out [12:12:58 CEST] <cone-384> ffmpeg 03Michael Niedermayer 07master:fd46d6deac9b: avcodec/mpegvideo_enc: Merge ifs with identical conditions [12:12:58 CEST] <cone-384> ffmpeg 03Alexis Ballier 07master:6e8d856ad6d3: libavcodec/mpegvideo_enc.c: Fix encoding videos with less frames than the delay of the encoder. [13:00:55 CEST] <ubitux> durandal_1707: http://yuzhikov.com/articles/BlurredImagesRestoration1.htm if you're bored [13:06:40 CEST] <Compn> enhance... [13:12:53 CEST] <durandal_1707> ubitux: writing nlmeans? [13:26:21 CEST] <wm4> can we have an uncrop filter [13:34:34 CEST] <durandal_1707> wm4: are you serious? [13:34:59 CEST] <J_Darnley> It exists! It's called pad! [14:17:27 CEST] <cone-384> ffmpeg 03Paul B Mahol 07master:bb1d3f1078e0: avformat/rsd: add VAG support [14:17:28 CEST] <cone-384> ffmpeg 03Paul B Mahol 07master:7bbd060324f0: avcodec/adpcm: increase max channels for ADPCM PSX to 8 [14:29:22 CEST] <cone-384> ffmpeg 03Carl Eugen Hoyos 07master:9496f565dcc7: configure: Simplify using --disable-all. [15:09:45 CEST] <ubitux> durandal_1707: yes i'm writing nlmeans [15:24:26 CEST] <cone-384> ffmpeg 03Ganesh Ajjanagadde 07master:e11e32686fdb: avcodec/bitstream: replace qsort with AV_QSORT [17:21:27 CEST] <JEEB> durandal_1707: seems like z's v2 rc is out [17:21:31 CEST] <JEEB> so it shouldn't get major changes [17:28:20 CEST] <durandal_1707> JEEB: simd have bug producing corrupt output [17:28:43 CEST] <JEEB> ok [17:30:32 CEST] <JEEB> is it easily repro'able? [17:33:04 CEST] <durandal_1707> maybe it got fixed, dunno [17:34:12 CEST] <JEEB> so what failed for you so I can test if I build it :P [17:43:56 CEST] <durandal_1707> corrupted pixels on right side when resizing [17:44:12 CEST] <JEEB> oh, I'm pretty sure that got fixed [17:44:22 CEST] <JEEB> also he's got unit tests now [17:44:48 CEST] <Daemon404> i recall that being an issue 1-2 weeks ago, no? [17:48:50 CEST] <JEEB> durandal_1707: what was your last patch? [17:50:22 CEST] <JEEB> is it the oct 2nd one? [17:51:21 CEST] <durandal_1707> I havent send it yet, mostly api changes, looking at alpha issue right now and than gonna push it [17:51:56 CEST] <JEEB> you have a wip repo? [17:56:04 CEST] <durandal_1707> locally [17:56:40 CEST] <durandal_1707> wm4: mpv thinks that gbrap is rgb555 [18:04:18 CEST] <wm4> durandal_1707: sample file? [18:05:17 CEST] <durandal_1707> -vf format-gbrap [18:06:58 CEST] <kierank> J_Darnley: I wasn't sure how to handle the constants in that function [18:07:03 CEST] <wm4> can't see anything with rgb555, although it converts to argb instead of outputting it directly [18:07:10 CEST] <durandal_1707> sorry its not mpv bug [18:08:56 CEST] <cone-384> ffmpeg 03Paul B Mahol 07master:416e35e5aafc: avfilter: add zscale filter [18:09:25 CEST] <JEEB> wow [18:09:31 CEST] <wm4> wow [18:09:52 CEST] <wm4> durandal_1707: when was grap introduced? maybe I have to ifdef it [18:15:57 CEST] <durandal_1707> No, nut muxer picks wrong tag [18:16:07 CEST] <JEEB> durandal_1707: first comment would be that -lstdc++ in extra-ldflags is required, at least for me [18:16:51 CEST] <durandal_1707> than zimg pkgconfig is broken [18:17:06 CEST] <JEEB> possibly [18:34:47 CEST] <Compn> >pkgconfig is broken [18:34:51 CEST] Action: Compn runs [18:38:13 CEST] <wm4> durandal_1707: I added support for these formats [18:38:20 CEST] <wm4> Compn: fuck your disgusting anti-developer attitude [18:51:18 CEST] <JEEB> well, simple YCbCr->YCbCr scaling seems to work at least [19:17:30 CEST] <durandal_1707> ycgco should also work [19:38:00 CEST] <durandal_1707> tell this MIT guy to other stuff [19:38:26 CEST] <durandal_1707> *to do [20:11:13 CEST] <J_Darnley> kierank: if they are really constant then use some RODATA like most other cases. [20:11:23 CEST] <kierank> they are not [20:11:26 CEST] <kierank> they are calculated constants [20:11:27 CEST] <J_Darnley> If you need to calculate them then use stack space [20:12:44 CEST] <J_Darnley> You can always try simplifying and only supporting 1 particualar config [20:12:51 CEST] <J_Darnley> like 420 and 8 bit mask [20:45:46 CEST] <cone-384> ffmpeg 03Michael Niedermayer 07master:94f7c97e0573: avformat/vag: Remove unused variable pos [21:02:34 CEST] <kierank> J_Darnley: I should probably learn how to use stack space... [21:22:08 CEST] <cone-384> ffmpeg 03Ganesh Ajjanagadde 07master:07d4fe3a871f: avutil: use EINVAL instead of -1 for the return code of crypto related init functions [21:34:48 CEST] <nicolas_> hi, i've found a bug on ffmpeg, i manage to fix it in 2 lines, but, i won't break something else, so i would like the opinion of dev of ffmpeg : [21:35:17 CEST] <nicolas_> in the protocol rtsp, at the disconnection, the client has to send a packet ; this is implemented in ffmpeg, but [21:35:41 CEST] <nicolas_> in the lowest network function, there is a test : "if (ff_check_interrupt(int_cb))" which make things not working [21:36:09 CEST] <nicolas_> i can : or remove this check, but i think that it could be usefull for something else, or [21:36:47 CEST] <nicolas_> add a parameter "force" to low network functions, but it touches the network.c of ffmpeg, so i guess you would not accept it easily [21:37:50 CEST] <nicolas_> the thing is that testing if the user requesting to quit in this function it not valid with the fact that rtsp protocol require network packet sending at the disconnection. [21:38:26 CEST] <BtbN> Mentioning what bug you are even trying to fix would be a good start. [21:39:25 CEST] <nicolas_> let me find the number in the tracker, but in one word : ffmpeg is currently not sending the tearing down packet at the disconnection. [21:39:55 CEST] <nicolas_> https://en.wikipedia.org/wiki/Real_Time_Streaming_Protocol [21:40:53 CEST] <nicolas_> [FFmpeg-trac] #4929 [21:46:36 CEST] <ubitux> nicolas_: fastest way to get feedback: see "contribute" on ffmpeg.org on how to suggest changes [21:46:47 CEST] <ubitux> (in case you don't get any feedback here) [21:48:04 CEST] <ubitux> atomnuker: it's really braindead; like, i'm able to trigger the crash only with http://pastie.org/10491407 now (or basically by just shuffling the code around) [21:51:41 CEST] <kierank> How do you deal with functions with > 8 arguments? [21:52:47 CEST] <J_Darnley> They're on the stack [21:53:09 CEST] <kierank> Are there any docs about how to use the stack (or good examples of stack use) [21:54:47 CEST] <nicolas_> ubitux, ok, prefered way is the mailing list ? [21:55:01 CEST] <ubitux> nicolas_: for sending patch, yes [21:55:17 CEST] <J_Darnley> Yadif uses it as does removegrain. [21:55:30 CEST] <J_Darnley> Whether they're clear or not I'm not sure [21:55:59 CEST] <J_Darnley> Basically: you ask for some as the 5th argument to cglobal [21:56:13 CEST] <J_Darnley> then you have it available starting at [rsp] [21:56:28 CEST] <kierank> I am going to just try and implement blend_pixel to begin with [21:59:29 CEST] <cone-384> ffmpeg 03Kyle Swanson 07master:32403d1fabb6: avfilter/af_flanger: free frame on ENOMEM [22:02:15 CEST] <atomnuker> ubitux: weird [22:08:03 CEST] <ubitux> atomnuker: btw, you can most likely remove the div in the corr and max_ratio calc and take it out of the 2 loops [22:08:52 CEST] <ubitux> the corr div might be tricky [22:09:34 CEST] <ubitux> maybe you can just drop the sqrt (and do it once outside the loop) [23:11:16 CEST] <kierank> J_Darnley: In "cglobal yadif_filter_line, 4, 7, 8, 80," what does the 80 mean? [23:11:49 CEST] <J_Darnley> 80 bytes of stack space will be reserved. [23:12:42 CEST] <kierank> ah ok in bytes [23:12:51 CEST] <kierank> just checking [23:13:56 CEST] Action: J_Darnley opens the code [23:16:46 CEST] <J_Darnley> The mmsize define can be used there to vary the space based on the SIMD register width [23:19:10 CEST] <kierank> And so you use [rsp+offset] to signal the args which haven't been loaded into registers? [23:19:32 CEST] <J_Darnley> Yes [23:20:11 CEST] <J_Darnley> but it is probably better to use rXm or rXmp to access where they should be [23:20:11 CEST] <kierank> Is it possible to control which args go into registers apart from the first n [23:20:15 CEST] <kierank> ok [23:20:28 CEST] <J_Darnley> and no [23:20:36 CEST] <jamrial> you don't need to reserve stack space for function arguments [23:20:58 CEST] <kierank> https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavfilter/drawutils.c;h=9… [23:21:06 CEST] <kierank> I don't need dst in a register for example [23:21:56 CEST] <J_Darnley> If it helps you then I suggest you make the argument order fit your needs [23:22:05 CEST] <kierank> ah I see [23:23:01 CEST] <J_Darnley> I also suggest you pass strides/linesizes as ptrdiff_t [23:34:11 CEST] <kierank> where does my allocated stack space start? [23:34:15 CEST] <kierank> do I have to work it out? [23:34:27 CEST] <nevcairiel> i think you can deduct from the stack pointer or something [23:34:53 CEST] <Gramner> [rsp] to [rsp+<whatever amount you allocated>] [23:35:08 CEST] <kierank> I see [23:37:16 CEST] <kierank> what does rXmp mean? [23:37:35 CEST] <nevcairiel> argument X's native position in native size [23:37:54 CEST] <kierank> and without the p? [23:38:06 CEST] <nevcairiel> not native size [23:38:28 CEST] <nevcairiel> (ie dword) [23:38:34 CEST] <Gramner> without size specified actually [23:39:04 CEST] <Gramner> it's just a memory reference, e.g. [rsp+<some value>] [23:39:14 CEST] <kierank> but yasm doesn't know the size of the elements in between either? [23:40:13 CEST] <J_Darnley> I don't understand the question. [23:40:43 CEST] <Gramner> stack arguments smaller than the native size are aligned to the native size, and the padding bytes are undefined if that's what you're asking [23:40:50 CEST] <kierank> oh i see [23:41:55 CEST] <Gramner> that's also why you should use ptrdiff_t instead of int for strides, otherwise the upper 32 bits are undefined and you need to manually clear them to use them safely [23:43:03 CEST] <kierank> so can I do "dec rXmpd"? [23:43:06 CEST] <kierank> is that allowed? [23:43:43 CEST] <J_Darnley> Probably [23:43:54 CEST] <nevcairiel> doesnt sound like something you can do [23:44:00 CEST] <J_Darnley> Many arithmetic instructions can work with memory [23:44:10 CEST] <kierank> but the height is an int [23:45:17 CEST] <nevcairiel> rXm should be dword, or so the docs in x86inc.asm claim [23:45:29 CEST] <nevcairiel> ; rNm is the original location of arg N (a register or on the stack), dword [23:46:32 CEST] <J_Darnley> The intel ref manual says dec can operate on memory [23:46:36 CEST] <Gramner> oh yeah, that comment is wrong then [23:47:11 CEST] <Gramner> note the code below where they are defined and you'll see that they have no specific size [23:47:31 CEST] <nevcairiel> interestingly if rNm points to a register, it does reference to rNd [23:47:53 CEST] <Gramner> yes, you need to specify a size for registers [23:48:04 CEST] <Gramner> that comment could be clarified a bit I guess [23:49:21 CEST] <nevcairiel> so how would he create a dword ref to rNm? use "dword r1m" as the operand? [23:49:57 CEST] <Gramner> yes, if you need to specify a size, but that's fairly rare [23:50:24 CEST] <Gramner> usually the size is implied by the instruction or a register that's part of the instruction [23:50:47 CEST] <nevcairiel> makes sense [23:52:08 CEST] <nevcairiel> kierank: sounds like you want to keep your loop counter on the stack, that seems somewhat inefficient to me tbh .. but if you're that low on regs.. [23:53:01 CEST] <kierank> Dunno, just trying to do what I'd usually do. dec rN jg .loop [23:53:28 CEST] <nevcairiel> and you're out of regs to store it in one? [23:53:42 CEST] <kierank> I am anticipating I will be [23:55:07 CEST] <nevcairiel> it should be possible to do that with "dec dword rXm" from what i understand (now), but still seems unusual [23:56:16 CEST] <jamrial> not really. it's done quite a bit on x86_32 functions when 7 gprs are not enough [23:56:50 CEST] <Gramner> yes, it's possible. but it requires a load-modify-store, so it's significantly slower than having it in a register. OOE might hide the latency though [23:57:21 CEST] <kierank> maybe I should just write x64 first [23:57:40 CEST] <Gramner> that's usually easier, yes [23:57:57 CEST] <kierank> I think I'll still need stack though [23:58:02 CEST] <kierank> lots of random values [23:58:35 CEST] <Gramner> 16 vector regs and 15 gprs not enough? [23:58:39 CEST] <Gramner> (for x64) [23:59:07 CEST] <kierank> got 10 arguments [00:00:00 CEST] --- Mon Oct 19 2015

1 0

ffmpeg.log.20151018
by burek 19 Oct '15

19 Oct '15

[00:01:32 CEST] <nerium> relaxed: I tried this with the latest https://gist.github.com/oleander/94881304756dbe1ca413 but it didint work [00:02:17 CEST] <StephenS> uhm how can I make timelapse, but from video?So actually to simulate that I have photos/frames..? [00:03:17 CEST] <RedH8> Dump the frames to png [00:03:45 CEST] <BtbN> You mean speed up a very long video? [00:03:54 CEST] <RedH8> You can set a start and stop position and just dump sections if you want [00:03:55 CEST] <BtbN> So you get a 5 minute video from a 24h recording? [00:04:06 CEST] <RedH8> Oh my bad [00:04:19 CEST] <StephenS> well not really [00:04:25 CEST] <StephenS> but to get timelapse from 10-20s long video [00:04:40 CEST] <BtbN> I'm not sure what you mean by timelapse then. [00:04:41 CEST] <StephenS> I saw speed/slow down video thing on ffmpeg, but thats not what I actually want [00:05:05 CEST] <RedH8> Do you want to create an image sequence? [00:05:19 CEST] <RedH8> Like snowboard magazines or skateboard mags? [00:05:21 CEST] <StephenS> nope [00:05:31 CEST] <StephenS> but most likely to drop every <x> frame from video [00:05:36 CEST] <RedH8> Kk ttying to grasp exactlt what ya want [00:05:36 CEST] <StephenS> so to get timelapse effect [00:05:41 CEST] <nerium> relaxed: So tcp seams to work, but not http [00:05:48 CEST] <RedH8> Ahh ok [00:06:40 CEST] <BtbN> So you do want to speed up the video... [00:06:44 CEST] <RedH8> Lol just use a lower framerate on your target output [00:06:50 CEST] <RedH8> It'll drop frames [00:07:05 CEST] <BtbN> Won't change the duration though, which is the whole point of a timelapse. [00:07:24 CEST] <RedH8> If you want some ugly choppy looking video yeah he'd have to speed it up somehow too [00:08:11 CEST] <StephenS> how or even better, how could I slowdown 70% of video and last 30% to just make it regular? [00:08:14 CEST] <BtbN> you propably want to use the setpts filter. [00:08:25 CEST] <RedH8> Not that ive ever looked but is there any relating info in the header of the container relating to framerate? [00:08:39 CEST] <BtbN> split the file, speedup the first one, then concat them again. [00:09:07 CEST] <BtbN> Or write a crazy setpts formula that knows where 70% start and uses a diffrent calculation then. [00:09:43 CEST] <StephenS> well I would rather do it all together :) [00:09:58 CEST] <BtbN> Have fun figuring out the calculation formula then. [00:12:07 CEST] <relaxed> nerium: did you read the man page? add -listen 1 [00:12:33 CEST] <TD-Linux> voice, they are still improving vp9 in libvpx (it's used on youtube so they care). vp10 is barely started at this point [00:12:57 CEST] <StephenS> something like this ffmpeg -i ino.mp4 -filter_complex " [0:v]trim=0:10[v1]; [0:v]trim=10:30[v2]; [0:v]trim=start=30[v3]; [v2]setpts=PTS/0.5[slowv]; [v1][slowv][v3]concat=n=3:v=1:a=0[outv]" -map [outv] map 0:a -c:v libx264 -c:a copy output.mp4 [00:13:07 CEST] <StephenS> but says map is invalid [00:13:31 CEST] <StephenS> Unable to find a suitable output format for 'map' [00:14:37 CEST] <relaxed> StephenS: I think you need to use the split filter first [00:15:43 CEST] <nerium> relaxed: thanks [00:15:56 CEST] <relaxed> hmm, but that will only give you two output labels [00:16:07 CEST] <StephenS> something is wrong with map? [00:17:30 CEST] <StephenS> ok it worked, but I added -map (dash) [00:17:42 CEST] <StephenS> and it generated video, but its not slowed down at all [00:44:23 CEST] <Lectem> Hi guys, I'm unsure if it was reported before, but on windows10 + msys2 + mingw32-w64, the configure script is broken. It doesnt recognize the os (Unknown OS 'msys_nt-10.0'.) and if I pass it --target-os=mingw32-w64 --host-os=mingw32-w64, it will fail to compile libavformat (libavformat/os_support.c:26:19: fatal error: netdb.h: No such file or directory) [00:47:46 CEST] <RedHate> Lectem: did you manage to get it to build anyways? Quick little addition of "//" infront of the include of said header? [00:52:02 CEST] <RedHate> Comment it out and attempt the build again. If something references it then it will stop again. [00:57:16 CEST] <RedHate> Or go compile netdb found https://www.google.ca/url?sa=t&source=web&rct=j&url=http://netdbtracking.so… [00:57:37 CEST] <RedHate> No fault of ffmpeg that you are missing prerequisite libraries. [01:06:13 CEST] <Lectem> RedHate: netdb is replaced by winsock2 on mingw32-w64 iirc [01:07:47 CEST] <RedHate> Ahh ok my bad net db is the unix tcp ip shit eh? Its been a while since ive dealt with thay [01:07:50 CEST] <RedHate> That** [01:08:12 CEST] <Lectem> yeah, its a system header [01:08:15 CEST] <RedHate> And yeah indeed mingw uses winsock [01:08:40 CEST] <RedHate> Id just comment all the network shit out who needs that anyways [01:08:40 CEST] <RedHate> Lol [01:08:52 CEST] <Lectem> well, rtsp and stuff ^^ [01:09:05 CEST] <RedHate> Fine fine fine *hissssssss* [01:09:07 CEST] <RedHate> :) [01:09:43 CEST] <Lectem> I think it used to compile just fine with older versions of mingw32-w64 [01:10:02 CEST] <Lectem> (in fact thats what is recommended on ffmpeg website, msys+mingw32-w64) [01:10:08 CEST] <Lectem> msys2* [01:10:51 CEST] <RedHate> Can you dump a .diff by comparing the two to trace the issue? [01:11:17 CEST] <RedHate> Lots of work for something you shouldnt have to fix however [01:11:25 CEST] Action: RedHate stfus [01:16:22 CEST] <Lectem> I don't really remember what version of mingw32-w64 used to work, it was on my old computer [01:26:39 CEST] <Lectem> actually nvm, I just cleaned reconfigured and all and now it seems to work... [01:28:01 CEST] <RedHate> Did you set the paths for include / libraries or something? [01:28:12 CEST] <RedHate> Or just a random bug? [01:28:57 CEST] <RedHate> For my own reference lol incase heh [01:39:47 CEST] <Lectem> to be honest, absolutely no idea why it suddenly worked [01:40:15 CEST] <Lectem> I did a bunch of things like git clean -fd, make clean [01:41:07 CEST] <RedHate> Weird yet excellent. [02:54:12 CEST] <BullHorn> hello [02:55:17 CEST] <BullHorn> i record 1440p30fps crf=21 video in OBS with x264 ultrafast preset. can i use ffmpeg cli to remux the video down with the same settings except using a slow preset? [02:55:22 CEST] <BullHorn> basically to keep the same quality and reduce filesize? [02:55:44 CEST] <BullHorn> people told me to use HandBrake but i already have ffmpeg cli and i think it should be able to do something like that? [02:56:32 CEST] <DHE> you'd have to use the same source material. otherwise there will be degradation from chained transcoding [02:57:09 CEST] <BullHorn> ok heres the thing [02:57:39 CEST] <BullHorn> i record into .flv containers (incase the recording software crashes) and then use ffmpeg to remux it into .mp4 for further editing in premiere [02:57:43 CEST] <BullHorn> thats what i use now: ffmpeg -i D:\Streaming\%1.flv -c copy -copyts F:\%2.mp4 [02:58:07 CEST] <BullHorn> convert flvpotato mp4tomato and it does it [02:58:21 CEST] <BullHorn> how can i make it use the slow x264 preset during this conversion [02:59:04 CEST] <DHE> as I said, it will degrade the image quality a bit... [02:59:31 CEST] <DHE> replace "-c copy" with "-c:a copy -c:v libx264 -crf 21 -preset:v slow" [02:59:48 CEST] <BullHorn> i guess i dont mind that, ill use crf 20 while recording [02:59:51 CEST] <BullHorn> ill try [03:05:53 CEST] <BullHorn> wow [03:05:59 CEST] <BullHorn> 30s video from 350mb to 140mb... [03:06:01 CEST] <BullHorn> thats awesome [03:06:03 CEST] <BullHorn> but too slow [03:06:07 CEST] <BullHorn> ill try medium preset now :) [03:07:25 CEST] <RedHate> Thats disgusting. Wtf 140mb for 30 seconds of video gasp [03:09:32 CEST] <BullHorn> its 1440p [03:09:39 CEST] <BullHorn> 78% more pixels than 1080p [03:09:44 CEST] <BullHorn> my mind was blown when i calculated this [03:09:45 CEST] <BullHorn> :| [03:10:27 CEST] <BullHorn> it makes most things look lossless but in arma3 you can still notice artefacts [03:10:30 CEST] <BullHorn> good source for editing :) [03:10:34 CEST] <BullHorn> thanks man, this really helped [03:10:50 CEST] <BullHorn> ill be using the fast preset though [03:10:53 CEST] <BullHorn> slow is WAY too slow [03:11:02 CEST] <BullHorn> medium and fast have the same file size, surprisingly [03:13:50 CEST] <TD-Linux> yeah there is no way to remux but it's pretty common for people to do a reencode from the live stuff [03:14:19 CEST] <TD-Linux> generally you use a high bitrate with ultrafast preset to record, then a lower bitrate for the final verison [03:14:30 CEST] <TD-Linux> (with a slower preset) [03:14:43 CEST] <BullHorn> yep thats what im testing now [03:15:00 CEST] <BullHorn> 30s ultrafast recording at crf=21, then converting to crf=23 with all presets, surprising results so far [03:15:21 CEST] <BullHorn> faster and veryfast produce smaller files than slow, medium and fast [03:15:29 CEST] <BullHorn> and more than x5 faster ;x [03:15:40 CEST] <TD-Linux> yeah but the visible quality is lower [03:15:56 CEST] <TD-Linux> crf is not an absolute quality setting [03:16:17 CEST] Action: RedHate upscales 240 to 4k cus it looks amazing. [03:16:23 CEST] <BullHorn> still, at crf=23 every ultrafast still looks pretty darn good [03:16:23 CEST] Action: RedHate is being a smart ass [03:17:16 CEST] <TD-Linux> yes, throw enough bitrate at anything and it will look great :) [03:18:27 CEST] <BullHorn> yea so heres my results [03:18:38 CEST] <BullHorn> veryslow, slow and medium = too slow [03:18:45 CEST] <BullHorn> superfast and ultrafast = huge files [03:19:12 CEST] <BullHorn> fast, faster and veryfast = same file size and barely noticeable difference [03:19:17 CEST] <BullHorn> in quality [03:19:21 CEST] <BullHorn> so ill stick to veryfast \o/ [03:19:47 CEST] <BullHorn> its a shame ffmpeg tells me so much info when it completes an encode, but it doesnt tell me how long it took [03:20:13 CEST] <BullHorn> i guess i should just look at the fps [03:25:45 CEST] <RedHate> Bullhorn i dunno about recent updates but the version i use only tells me how much has been encoded in seconds. [03:26:19 CEST] <RedHate> Its annoying. Like the formula to give it hours and minutes was to complex of an addition lol [03:26:28 CEST] <BullHorn> its fine [03:26:37 CEST] <BullHorn> i did all the reencodes, slow, medium, fast, etc [03:26:40 CEST] <RedHate> Nope nope seconds is good enough use a calculatpr [03:26:44 CEST] <RedHate> Calculator* [03:27:56 CEST] <BullHorn> slow was 8fps, medium was 16fps, fast was 25, veryfast was 40, superfast was 55 and ultrafast was 95 [03:28:07 CEST] <BullHorn> superfast and ultrafast too big files so veryfast it is :) [03:28:40 CEST] <DHE> the visual quality difference of using crf=X between the various presets should be non-existant for the same X number [03:29:03 CEST] <BullHorn> i ever use a higher X number in the reencode, just incase [03:29:07 CEST] <BullHorn> record with 21, reencode with 23 [03:29:12 CEST] <DHE> at least that's how it works with qp mode. crf might introduce changes since it studies the image to decide a qp value [03:30:28 CEST] <TD-Linux> DHE, I don't think that's really true, even for qp mode [03:30:45 CEST] <BullHorn> im testing the same thing with nvenc now instead of x264 and each line that it does prints this: [03:30:46 CEST] <BullHorn> http://i.imgur.com/mAsc7sJ.png [03:30:47 CEST] <TD-Linux> consider if a slower search find a better predictor, but in both cases the qp is high enough to skip the block [03:30:49 CEST] <BullHorn> whats the meaning ;x [03:59:24 CEST] <DHE> I'd try dropping the -copyts but check to see if anything happened to the video [03:59:48 CEST] <DHE> TD-Linux: I was trying it earlier. unless I messed up my testeding psnr and ssim didn't change [04:00:11 CEST] <DHE> wow I cannot type straight when I'm tired [04:00:48 CEST] <TD-Linux> DHE, ah well tests always trump hypotheses :) [04:02:52 CEST] <DHE> but I only tested qp mode. I'm trying to judge libx264 vs nvenc [04:10:46 CEST] <DHE> I love nvenc for the speed, but I am definitely seeing the quality difference when frame-stepping... [04:17:54 CEST] <BullHorn> DHE dropping -copyts didnt help [04:17:58 CEST] <BullHorn> its even worse with some files [04:18:11 CEST] <BullHorn> i get the Past duration 0.9something too large like 50 times between each ping [04:18:33 CEST] <BullHorn> only happens when i reencode stuff that i used nvenc to record [04:19:41 CEST] <BullHorn> http://i.imgur.com/M8V2i4F.png [04:26:52 CEST] <Nosomy> have the way to calculate a filesize of m2ts-file which is a ts-file remuxed? [04:35:39 CEST] <TD-Linux> ls -l [05:27:40 CEST] <edman007> Hi, so I got an interesting one... I got a lot of JPGs that I want to make into a video, once I do that I want to apply the deshake algorithm to ensure the image is still...then I want to apply the timestamp from the jpg's exif to each frame...how would I do that? [06:25:25 CEST] <foreverska> Is there a more machine readable form of the devices list? [07:47:28 CEST] <waressearcher2> is it possible to make every frame a I-frame ? [07:59:52 CEST] <Nosomy> yes [08:00:43 CEST] <Nosomy> but this could be make stroboscope video. [08:01:28 CEST] <Nosomy> if is libx264, -g 1 make this [08:01:55 CEST] <Nosomy> keyint x264 param [08:20:03 CEST] <waressearcher2> what is stroboscope ? [08:20:17 CEST] <waressearcher2> stroboscope video [08:20:19 CEST] <waressearcher2> how is that [08:22:04 CEST] <Nosomy> some pieces of frame like as those videos which causes epilepsy. [08:23:24 CEST] <waressearcher2> like the once they should use in TV store ? [08:24:49 CEST] <Nosomy> even if it does not cause the effect to the video, the bit rate goes up. [08:33:12 CEST] <Nosomy> random sample with 107 frames, 1080p23.97: --preset ultrafast --qp 0 : 134240kbps ; the same with keyint 1 : 146553kbps; Preset medium crf 23 (normal): 8614kbps; the same with keyint 1: 11172kbps [08:35:01 CEST] <waressearcher2> what it means ? [08:35:14 CEST] <Nosomy> ~20% more bitrate in average. [08:35:27 CEST] <waressearcher2> -20% ? [08:35:38 CEST] <waressearcher2> "~" means average ? [08:36:12 CEST] <Nosomy> "~" means approximately [08:52:43 CEST] <Nosomy> frame type decisions are better when made by the encoder. [08:53:05 CEST] <waressearcher2> is your name a word play on word "Sodomy" ? [08:53:23 CEST] <Nosomy> nop [10:41:43 CEST] <||arifaX> How can I bring down cpu usage of this command. Just a still image as video: http://pastebin.com/cnsFVWfY [10:54:27 CEST] <xsi> twitch caught, and it was live. But black screen [10:55:16 CEST] <BullHorn> My 22nd Birthday in: -141782115secs [10:55:25 CEST] <BullHorn> wrong button [10:55:25 CEST] <BullHorn> lol [10:55:39 CEST] <fritsch> and delay is negative :-) [10:56:08 CEST] <BullHorn> yeah i havent touched this scripts since i was 21 years old, apparently :p [10:56:22 CEST] <xsi> 31 [10:58:01 CEST] <fritsch> so, then you are 26 now and need to wait half a year to 27? [10:58:13 CEST] <BullHorn> yes [10:59:36 CEST] <chungy> chungy=> select '2015-10-18 01:55:16'::timestamp - '141782115 seconds'::interval - '21 years'::interval; [10:59:36 CEST] <chungy> ?column? [10:59:36 CEST] <chungy> --------------------- [10:59:36 CEST] <chungy> 1990-04-21 02:00:01 [11:00:39 CEST] <chungy> I think I'm off a year... [11:00:46 CEST] <chungy> oh yeah, 22nd birthday, not 21st [11:00:54 CEST] Action: chungy should go to bed [11:00:55 CEST] <fritsch> :-) [11:01:11 CEST] <fritsch> but guessing game has just started [11:01:22 CEST] <fritsch> chungy: you cannot leave yet [11:03:01 CEST] <chungy> Which game? :p [11:03:24 CEST] <fritsch> guessing BullHorn's life [11:03:38 CEST] <fritsch> BullHorn: any other script you could run? [11:03:56 CEST] <BullHorn> i just deleted them all [11:03:57 CEST] <BullHorn> :p [11:04:14 CEST] <fritsch> too bad [11:07:54 CEST] <BullHorn> so does anyone have an idea [11:08:12 CEST] <fritsch> i even forgot the question sadly [11:08:13 CEST] <BullHorn> why converting x264 flv to mp4 goes smooth [11:08:23 CEST] <BullHorn> and nvenc flv to mpr results in these repeated warnings: http://i.imgur.com/M8V2i4F.png [11:08:51 CEST] <klaxa> what ffmpeg version are you using? [11:09:04 CEST] <klaxa> i think those warnings were "fixed" a few months ago [11:09:15 CEST] <BullHorn> ffmpeg version N-75458-g198110d [11:09:21 CEST] <BullHorn> its like 2-4 weeks old [11:09:41 CEST] <klaxa> what's your command line? [11:09:55 CEST] <BullHorn> ffmpeg -i D:\Streaming\%1.flv -c:a copy -c:v libx264 -crf 23 -preset:v veryfast -copyts F:\%2.mp4 [11:10:48 CEST] <klaxa> doesn't look obviously wrong [11:11:05 CEST] <BullHorn> ill get 2.8.1 and try again [11:11:42 CEST] <fritsch> where is nvenc involved here? [11:11:54 CEST] <klaxa> yeah that too [11:11:58 CEST] <BullHorn> nvenc is the way i record the source video [11:12:18 CEST] <klaxa> what's the source? [11:12:38 CEST] <BullHorn> stuff on my screen [11:12:57 CEST] <klaxa> ok, thought if it wasn't a screencast you could save one encode [11:13:34 CEST] <xsi> black screen: https://bpaste.net/show/824eddd59992 [11:13:43 CEST] <xsi> idk firstly launched [11:14:40 CEST] <BullHorn> getting the same warnings with 2.8.1 [11:15:09 CEST] <klaxa> xsi: might want to regenerate your API key now ;) [11:16:30 CEST] <klaxa> xsi: you're missing -s $SIZE and -i :0.0 [11:17:10 CEST] <klaxa> you want: ffmpeg -f x11grab -framerate $FRAMERATE -s $SIZE -i :0.0 -f alsa -ac 2 -i hw:0,0 -vb $BITRATE -vcodec libx264 -threads 0 -acodec libmp3lame -ab 128k -ar 22050 -s $SIZE -f flv "rtmp://live.twitch.tv/app/$KEY" [11:17:29 CEST] <klaxa> (note that -framerate is "better" than -r) [11:17:38 CEST] <klaxa> using -r [11:17:47 CEST] <klaxa> *using -r as an input option may result in A/V desyn [11:17:50 CEST] <klaxa> *desync [11:17:53 CEST] <xsi> they were false because of use flags so i'd try [11:17:54 CEST] <xsi> w8 [11:17:58 CEST] <xerox> twitch does rtmp? [11:18:05 CEST] <klaxa> if x11grab can't provide frames fast enough [11:18:23 CEST] <xerox> oh maybe it's their endpoint to use if you're streaming [11:18:36 CEST] <klaxa> twitch also does rtmp [11:18:44 CEST] <klaxa> but also hls [11:19:27 CEST] <xerox> I use livestreamer to capture the streams, can you use ffmpeg directly? [11:19:53 CEST] <klaxa> it's a lot more hassle to find out the correct rtmp parameters, i'm using livestreamer too [11:20:28 CEST] <xerox> what options do you use? mine are livestreamer --ringbuffer-size=1024M --player-http -v --player ~/.bin/mplayer-stream [11:21:11 CEST] <xerox> (where the last thing is a bash script that runs mplayer on the 127.0.0.1:randomport url that ls generates) [11:21:18 CEST] <klaxa> >livestreamer -Q -O $stream best | /root/tools/ffmpeg/ffmpeg -i - -map 0:a -map 0:v -c copy -absf aac_adtstoasc -metadata creation=$(date +%s) "$date".mkv [11:22:30 CEST] <xerox> nice [11:22:37 CEST] <klaxa> mkvtoolnix doesn't like the aac i get from twitch, therefore the bitstream filter [11:23:15 CEST] <xerox> I do flv->mp4 and more often than not get the aac error yeah [11:23:31 CEST] <BtbN> It's just about the extradata, the aac itself is fine. [11:23:39 CEST] <klaxa> ah [11:24:03 CEST] <xerox> do you ever re-encode? twitch seems to use a lot of bandwidth even if the stream itself doesn't warrant it [11:24:15 CEST] <klaxa> no i don't re-encode if possible [11:24:27 CEST] <BtbN> Twitch uses as much bandwidth as the streamer decides to use. 3.5Mbit/s max. [11:26:26 CEST] <xerox> there is some "mosty static image" content whose filesize, at crf 18, gets halved [11:26:37 CEST] <xerox> or thereabouts [11:27:22 CEST] <BtbN> Remvoign the cbr padding should also achive that. [11:27:35 CEST] <xerox> how do you go about doing that? [11:27:47 CEST] <BtbN> A simple -c copy pass should get rid of it. [11:27:59 CEST] <xerox> hmm, that is not my experience [11:28:25 CEST] <xerox> I use: ffmpeg -i ${FLV} -acodec copy -bsf:a aac_adtstoasc -vcodec copy ${MP4} [11:30:18 CEST] <BtbN> There is no cbr padding then. [11:30:27 CEST] <BtbN> acodec/vcodec is deprecated, btw. [11:30:43 CEST] <xerox> didn't know that! what should I use instad? [11:30:46 CEST] <BtbN> -c [11:30:52 CEST] <BtbN> + stream specifiers [11:30:57 CEST] <xsi> klaxa :0.0: Invalid argument [11:31:09 CEST] <klaxa> gg wp [11:31:25 CEST] <klaxa> can you pastebin your complete output? [11:33:25 CEST] <BullHorn> i have no idea what might be causing the problem [11:33:31 CEST] <BullHorn> ;/ [11:34:05 CEST] <xsi> https://bpaste.net/show/696d19c96207 [11:35:45 CEST] <klaxa> does ffmpeg -formats show x11grab? [11:40:02 CEST] <xsi> https://bpaste.net/show/c56caddd5286 [11:41:30 CEST] <xsi> D [11:41:40 CEST] <xsi> D x11grab X11 screen capture, using XCB [11:50:58 CEST] <c_14> xsi: what's your command line [11:52:56 CEST] <xsi> ffmpeg -f x11grab -framerate $FRAMERATE -s $SIZE -i ":0.0" -f alsa -ac 2 -i hw:0,0 -vb $BITRATE -vcodec libx264 $ [11:53:04 CEST] <xsi> w8 [12:07:11 CEST] <xsi> https://bpaste.net/show/7d475699d713 [12:17:32 CEST] <c_14> Your command works for me. [12:19:31 CEST] <c_14> But a video bitrate of 128k is _really_ low. You might want to increase that. [12:30:04 CEST] <xsi> ok [12:30:36 CEST] <xsi> bbl . [12:32:50 CEST] <xsi> bbl [14:11:50 CEST] <DHE> well, the eyeball tests are in. nvenc loses to x264 without a doubt [14:15:12 CEST] <Phrk_> hello [14:15:36 CEST] <Phrk_> I'm trying to use nvenc, is there any doc ? The only option is -preset ? [14:21:28 CEST] <Mavrik> Huh, what's the catch at nvenc only supporting 2-pass mode with low latency presets? [14:21:55 CEST] <DHE> -preset, -profile, -level, -g, bitrate settings, etc [14:21:59 CEST] <DHE> also 'slow' does 2-pass [14:22:17 CEST] <DHE> also 2pass isn't the same as x264 2-pass. I think it's an internal thing where it encodes the frame twice [14:23:32 CEST] <Mavrik> Mhm, I just find it interesting that you'd do a low-latency encode preset and then let users do it twice. [14:23:44 CEST] <Mavrik> Did you perhaps test it? [14:24:33 CEST] <DHE> I'm focusing on the settings that matter to me. consequently I've mostly tested medium and slow presets. [14:25:18 CEST] <DHE> in x264 parlance low latency means the encode() function reads a frame and spits out the encoded version directly. without low latency x264 might sit on a few dozen frames before it starts giving you outputs. [14:25:39 CEST] <Mavrik> Mhm, [14:25:42 CEST] <Phrk_> how do you use 2pass? [14:26:01 CEST] <Mavrik> Just looking through doc, it seems that the point of 2-pass is really to get a nice CBR [14:26:04 CEST] <Phrk_> Im not sure to understand, the best quality and most expansive preset is ? [14:26:18 CEST] <Mavrik> Which then starts to make sense with low-latency, since they're probably using this profile to get Shield streaming working properly. [14:26:35 CEST] <Mavrik> Totally flat bandwidth usage with low latency that is. [14:27:06 CEST] <Phrk_> for encoding game ? [14:27:59 CEST] <DHE> when consistency matters [14:28:27 CEST] <Phrk_> and if i just want to encode hq video ? [14:28:31 CEST] <DHE> also lowlatency mode means no b-frames since that requires out-of-order decoding and that the encoder must sit on a few frames to produce them [14:29:10 CEST] <DHE> unfortunately when quality matters x264 wins hands down. even mixing x264 preset=fast and nvenc preset=slow [14:29:27 CEST] <DHE> though nvenc in this scenario still does double the framerate [14:29:56 CEST] <Mavrik> I doubt the realtime HW encoders will ever rival x264 quality wise. [14:30:07 CEST] <Mavrik> It's just not possible to reach same quality if you wanna do it fast. [14:30:27 CEST] <Mavrik> Since you can't afford a large lookahead and extensive search [14:30:34 CEST] <ChocolateArmpits> But should nvenc be more power-efficient when compared to encoding on cpus ? [14:30:39 CEST] <ChocolateArmpits> shouldn't* [14:30:49 CEST] <Mavrik> I guess. [14:31:02 CEST] <Mavrik> If they're actually using their encoder not CUDA. [14:31:13 CEST] <Mavrik> Whe main GPUs are powerhungry beasts. [14:31:22 CEST] <ChocolateArmpits> Like what is the general power efficiency when comparing a frame of similar quality encoded on nvenc and a typical cpu via x264 [14:31:29 CEST] <DHE> nvidia-settings reports distinct utilization stats for the video and main GU hardware... [14:31:37 CEST] <Mavrik> Phrk_, there's a command that dumps all parameters for a codec (don't remember it right now though) [14:31:43 CEST] <Mavrik> Phrk_, should give you all possible parameters for nvenc [14:32:16 CEST] <Mavrik> ChocolateArmpits, it's probably an order of magnitute different [14:32:29 CEST] <Phrk_> interesting [14:32:30 CEST] <ChocolateArmpits> Mavrik: in favor of which ? [14:32:30 CEST] <Mavrik> I haven't measured on desktop, but on mobile using the H.264 chip is extremely cheap power-wise. [14:32:43 CEST] <DHE> ffmpeg -h full > ffmpeg-help.txt # then search the file for nvenc [14:32:45 CEST] <ChocolateArmpits> the hardware solution, right ? [14:32:54 CEST] <Phrk_> well for backup of a dvd i go x264 then [14:32:57 CEST] <c_14> ffmpeg -h encoder=nvenc [14:33:13 CEST] <Mavrik> ChocolateArmpits, yes. [14:33:40 CEST] <DHE> those only show codec-specific parameters though. -b:v, -maxrate and -flags ildct also apply to nvenc [14:33:49 CEST] <Mavrik> I noticed the same on my Mac (which I think defaults to QuickSync, not Nvenc - hard to tell though). But haven't relly benchmarked it. [14:34:42 CEST] <Phrk_> nice [14:35:07 CEST] <ChocolateArmpits> Mavrik: quicksync comes at different quality with different versions of hd graphics [14:35:18 CEST] <Mavrik> But yeah, if you only have to do 2x bitrate from x264, then the HW decoder is actually rather good :) [14:35:26 CEST] <ChocolateArmpits> The rule is the newer it is the better encoding results you can expect [14:36:21 CEST] <Phrk_> Someone can explain me the 2pass thing, there is "rawvideo -y /dev/null" in my terminal but i dont understand why [14:36:57 CEST] <ChocolateArmpits> Phrk_: in pass 1 only the passlogfile is relevant, you don't need to write the rendered file [14:37:01 CEST] <DHE> in terms of x264 or nvenc? they mean different thing [14:37:02 CEST] <DHE> s [14:37:45 CEST] <Phrk_> x264 [14:37:48 CEST] <Mavrik> I guess that nvenc doesn't generate a passlog file, but just encodes it properly. [14:37:56 CEST] <Mavrik> So no two executions. [14:38:03 CEST] <Phrk_> OOOOKKK [14:38:33 CEST] <DHE> what ChocolateArmpits says. x264 makes a lot file graphing parameters from the video during pass 1. for pass 2 it uses that to make better choices about encoding. [14:38:42 CEST] <DHE> so the first pass you can just throw away the result [14:38:57 CEST] <Phrk_> interesting [14:38:57 CEST] <Mavrik> Yep... also you almost certanly shouldn't be doing 2-pass encoding on x264 :) [14:39:02 CEST] <Mavrik> Except in some very rare use-cases. [14:39:15 CEST] <Phrk_> What ? [14:39:15 CEST] <DHE> (which I qualify for) [14:39:23 CEST] <Phrk_> from mpeg2 ? [14:39:47 CEST] <DHE> it does double the encoding time and is only really useful when you have file size or bitrate constraints [14:39:48 CEST] <ChocolateArmpits> When you need to hit specific size requirements and you need the best quality for it [14:40:17 CEST] <Mavrik> Yep, and even for bitrate constraints the -crf -maxrate is pretty much spot on quality wise without the huge speed penalty :) [14:41:31 CEST] <ChocolateArmpits> It doesn't *really* double it. More like takes overall 1.6-1.7x time longer. Setting --pass 1 by default turns off a few things which speed up the encoding [14:42:17 CEST] <Mavrik> DHE, what's your usecase? Mobile streaming? [14:42:24 CEST] <DHE> basically yes [14:42:48 CEST] <ChocolateArmpits> Mavrik: I object crf without a bitrate ceiling. set the bufsize and maxrate next to it [14:43:08 CEST] <Mavrik> ? [14:43:26 CEST] <Mavrik> DHE, yeah, that makes sense. We do live TV so can't do 2-pass really, The quality is still pretty great :) [14:43:48 CEST] <ChocolateArmpits> well from my experience setting crf by itself can fluctuate the bitrate quite wildly [14:43:53 CEST] <Phrk_> Do you have good preset for my 4,5gb dvd to 1gb or 2 (good quality) [14:44:06 CEST] <ChocolateArmpits> in a number of cases it can break playback [14:44:35 CEST] <Mavrik> ChocolateArmpits, huh? [14:44:46 CEST] <Mavrik> In streaming environments yes, for stored content, no. [14:44:56 CEST] <ChocolateArmpits> because the bitrate gets so high the playback media can't send the data fast enough, for example writing the file to a dvd and having too high bitrate due to crf [14:45:47 CEST] <Phrk_> for storing on my computer and play on it [14:47:26 CEST] <Mavrik> Phrk_, to get a 2GB filesize for a 2 hour movie, you need to set somewhere between 2000-2500 kbit bitrate. [14:47:38 CEST] <Mavrik> So set that, do a slow profile and you're set. [14:47:45 CEST] <Mavrik> Adjust according to taste. [14:48:08 CEST] <Mavrik> If you don't care about hitting exactly 2GB, use a sane -crf parameter that still looks nice. [14:48:15 CEST] <Phrk_> if i go lossless with x264, filesize will be bigger than the mpeg2 file ? [14:48:17 CEST] <Mavrik> I guess somewhere around 22 or so. [14:48:22 CEST] <Mavrik> No. [14:48:50 CEST] <Phrk_> so what the most hq/sane -crf ? [14:48:59 CEST] <Phrk_> i don't care about the size [14:49:01 CEST] <Mavrik> ChocolateArmpits, unless you're doing some freak 4K encodes, that really shouldn't be a concern outside public internet. [14:49:03 CEST] <Phrk_> just need to be smaller [14:49:10 CEST] <Mavrik> Then you do care about the size. [14:49:43 CEST] <Mavrik> Phrk_, crf 23 is default and it's good enough for pretty much most content. [14:49:55 CEST] <Mavrik> The video should be smaller unless you have white noise :) [14:50:14 CEST] <Mavrik> Use -preset slow or something to squeeze a bit more quality out of video. [14:55:51 CEST] <furq> 2GB for a dvdrip is pretty huge [14:56:40 CEST] <DHE> Mavrik: for live video how big a lookahead buffer do you use? or are you using zerolatency? [14:56:56 CEST] <Mavrik> Oh no, zerolatency butchers the quality. [14:57:03 CEST] <Phrk_> Thanks guys ! [14:57:04 CEST] <DHE> yes I know... [14:57:08 CEST] <Mavrik> Afaik we just run the default slow preset. [14:57:27 CEST] <Mavrik> Medium/fast for channels that aren't really popular. [14:57:43 CEST] <Mavrik> 5 sec or so total delay from source to DVB emitter is acceptable atm. [14:57:50 CEST] <DHE> slow? that must be hell on the CPU though [14:58:21 CEST] <Mavrik> PAL + 48 core Xeons are just fine. [14:58:33 CEST] <DHE> oh, sd content [14:58:34 CEST] <Mavrik> But that's only a handful of channels that are watched the most. [14:58:47 CEST] <Mavrik> HD is medium mosty AFAIK [14:58:58 CEST] <Mavrik> fullHD is even encoded into 960x1080 [14:59:03 CEST] <Phrk_> yeah, -tune film -preset slow -crf 22 seem better quality than nvenc but same file size [14:59:05 CEST] <Phrk_> cool [15:00:33 CEST] <Mavrik> Phrk_, yp, you can even do like crf 24 (larger number - smaller file and worse quality) and see if it's still good enough for you. [15:01:24 CEST] <Phrk_> ffmpeg is so powerfull [15:01:44 CEST] <DHE> it is, but like any powerful tool you need to understand how to use it [15:02:54 CEST] <DHE> I learned how to make a single ffmpeg process output multiple variants of the same video (all part of the streaming process) and then everything changed... [15:08:10 CEST] <ChocolateArmpits> -tee is pretty great [18:36:41 CEST] <sine0> anyone know why there is not a package for ffmpeg in the repo [18:36:48 CEST] <sine0> of the debian distro [18:38:30 CEST] <c_14> There is if your version of debian is new enough. [18:45:36 CEST] <furq> sine0: jessie uses libav because politics are fun [18:45:51 CEST] <sine0> oh ok. [18:45:52 CEST] <furq> which is another good reason to not use debian stable [18:46:29 CEST] <sine0> well I was going to go stretch, but i tried to install it on my laptop and had some shizz going on with systemd so i thought i would play safe on my main box with jessie [18:49:19 CEST] <JEEB> well, I will also mention that the guy who maintained libav on debian seemed to do a whole lot more heavy lifting than the guy who seems to maintain FFmpeg there now [18:49:50 CEST] <JEEB> although it's still a bad situation there since even if software is dead debian doesn't seem to want to either a) remove those packages or b) distribute multiple versions of FFmpeg/Libav's libraries [18:50:34 CEST] <JEEB> of course this might just be my first act of communication I saw from the FFmpeg maintainer @ Debian, which was "no you cannot remove shit you deprecated 3 years ago" [18:52:54 CEST] <JEEB> but in any case, ffmpeg should be rather simple to build with the requirements most people have [18:53:08 CEST] <JEEB> due to the fact that pretty much every decoder is already in libavcodec [18:53:13 CEST] <JEEB> so it's left to what encoders you want to use [19:04:13 CEST] <furq> you could try installing the package from stretch [19:04:42 CEST] <furq> but after a point it's simpler to just upgrade to stretch [20:57:08 CEST] <edman007> Hi, I'm using the drawtext filter and %{n} does not actually print the frame number, for example it says it matches the frame number in the documentation, but frame 0 prints one, and then it increments by one or two each frame [20:57:19 CEST] <edman007> why is it not accurate? [21:08:37 CEST] <StephenS> ayo, is there a way to make a blinking video, on some parts, like the one taken in disco? [21:44:46 CEST] <lahwran> hey folks, I'm looking around for libraries I could use to splice h.264 video frames together [21:45:15 CEST] <lahwran> I'd like to take frames from a bunch of different files, and without uncompressing them, assemble them into a single video stream [21:45:24 CEST] <lahwran> (all frames involved will be keyframes) [21:45:54 CEST] <lahwran> is this something that libav* would help with? [21:46:25 CEST] <lahwran> I would expect it would, since one of the steps will need to be reading/writing mp4 files [21:46:43 CEST] <lahwran> can anyone give me pointers about how to do this? [21:47:10 CEST] <DHE> can you do that without transcoding? [21:47:23 CEST] <DHE> ffmpeg can let you assemble tiles of videos but the output will need to go through a video encoder at the end [21:47:43 CEST] <lahwran> are you asking if it can be done, or are you asking if I'm willing to do it differently? [21:48:11 CEST] <lahwran> I specifically am hoping that this will involve nothing but some copying and then generating mp4 headers [21:48:32 CEST] <DHE> I'm suggesting what you're asking probably can't be done with ffmpeg directly. my guess is you'd need to unpack the H264 yourself and stitch the macroblocks together yourself [21:48:37 CEST] <lahwran> oh sure [21:48:41 CEST] <lahwran> yes [21:48:45 CEST] <lahwran> I realize that [21:48:54 CEST] <lahwran> I came here to ask if ffmpeg's libraries will help me do that [21:49:27 CEST] <lahwran> probably they'll only help with the mp4-reading portion of the task, right? [21:49:34 CEST] <lahwran> and I'll need to learn the h264 format myself [21:50:06 CEST] <__gotcha> Is it possible to trim beginning of a video without recoding it ? [21:50:17 CEST] <lahwran> heh, similar question to what I'm asking [21:50:19 CEST] <DHE> there is an h264 "parser" which can help partially. but in the end you'll need to do it the hard way [21:50:29 CEST] <DHE> __gotcha: you can only start playback on a keyframe, but yes [21:50:36 CEST] <ChocolateArmpits> __gotcha: not in any conventional way, the trimmed file will have to be written [21:50:48 CEST] <__gotcha> I have read about keyframes [21:51:06 CEST] <__gotcha> s/read/heard/ [21:51:28 CEST] <lahwran> also, when I say splice frame together, what I mean is I have a bunch of mp4s, each named frame_%d.mp4, with exactly one frame in them. I'd like to turn them into a single video that is each frame in sequence. [21:51:29 CEST] <__gotcha> where can I dig deeper to understand what they are [21:51:44 CEST] <DHE> a keyframe is a single video frame that stands on its own. other frame types will depend on having intact previous frames to use as reference [21:51:53 CEST] <DHE> so you couldn't start playing video from anything besides a keyframe [21:52:40 CEST] <lahwran> (this probably seems insane, and I am aware of the concept of an XY problem; I'm not unaware of better options, I actually need to do this weird thing) [21:53:03 CEST] <__gotcha> iow, at the beginning of a video, there is a full frame, ie keyframe then other frames are diffed [21:53:12 CEST] <DHE> lahwran: oh.... that's a little more sane... [21:53:14 CEST] <DHE> (barely) [21:53:25 CEST] <__gotcha> and until there is another keyframe [21:53:35 CEST] <__gotcha> and again following frames diffed [21:53:56 CEST] <lahwran> it also needs to be as fast as humanly possible [21:53:57 CEST] <DHE> __gotcha: basically yes [21:54:00 CEST] <lahwran> :p [21:54:13 CEST] <__gotcha> DHE: I know I am very fuzzy [21:54:32 CEST] <__gotcha> but finally understand why I have lost time not understanding what was wrong [21:54:41 CEST] <__gotcha> DHE: thanks [21:54:42 CEST] <DHE> lahwran: if they all meet the same encoding criteria (eg: frame size) then it can be done. you'll probably have to timecode it yourself though. [21:54:50 CEST] <lahwran> ok [21:54:53 CEST] <lahwran> that's not too bad, then [21:55:21 CEST] <lahwran> hm, why does each frame have a timecode? [21:55:35 CEST] <lahwran> (this is an unrelated question, I'm just suddenly curious about h.264's design) [21:55:46 CEST] <DHE> it's not h264 directly. let me put it this way. what's the framerate of a 1-frame video? [21:56:26 CEST] <lahwran> hm. I thought the framerate was defined in a header [21:57:02 CEST] <lahwran> does each frame have a real-time offset from the previous one, or perhaps from an absolute point? can you have variable-framerate video? [21:57:11 CEST] <DHE> i'm not entirely sure about .mp4. but either way you're making a new .mp4 file out of just frames and each frame will have a time code of 0.00s from the source [21:57:15 CEST] <furq> you can have variable framerate video [21:57:20 CEST] <lahwran> huh I see [21:57:28 CEST] <DHE> it does vary by the container. mpeg-ts and MKV famously do variable FPS [21:57:37 CEST] <furq> some deinterlacers make use of that [21:57:56 CEST] <lahwran> so each frame has its own time then, and you have to set it to be a fixed offset from the previous one; and this is how framerate is defined [21:58:12 CEST] <lahwran> I'm going to read through the h.264 spec, but it's pretty intimidating [21:58:42 CEST] <DHE> more or less. the ffmpeg libraries have assistance in the form of time bases. you can set the timebase as 1/30 (1, 30) and then frame numbers correspond to playback as you would expect [21:58:52 CEST] <DHE> I think you'll see as you go [21:59:02 CEST] <JEEB> AVC doesn't really have timestamps by itself. You *can* write timestamps into additional SEI (?) messages methinks [21:59:08 CEST] <JEEB> but f.ex. x264 doesn't do that [21:59:27 CEST] <JEEB> at most you have a header that is often abused to signal a "frame rate", even though technically it is not that [21:59:34 CEST] <lahwran> oh hm [21:59:38 CEST] <JEEB> containers are what usually contain timestamps [21:59:43 CEST] <lahwran> if you leave off framerate, what will happen? [21:59:49 CEST] <lahwran> ahh [21:59:52 CEST] <lahwran> okay [21:59:56 CEST] <lahwran> that is how I thought it worked [22:00:04 CEST] <JEEB> usually decoders default to 25Hz if nothing is given [22:00:13 CEST] <JEEB> and then containers override that [22:01:08 CEST] <JEEB> and as I said, that field that is generally used for a "frame rate" with raw AVC is not really that [22:01:27 CEST] <ChocolateArmpits> wouldn't it be wiser to use 25Fps term in stead of 25Hz ? interlaced content is 50Hz so saying 25Hz would seem like it would play half as slow, even though it has 25 frames [22:01:29 CEST] <DHE> the x264 cli may not, but historically I found mencoder (really old version now) when dumping to raw .264 files still somehow "guessed" the right framerate... [22:01:44 CEST] <JEEB> DHE: that's not timestamp data [22:01:53 CEST] <JEEB> that's the thing that is generally used for "frame rate" [22:02:09 CEST] <JEEB> which is also what x264 writes when you set a constant frame rate for it [22:02:18 CEST] <DHE> that would work... [22:02:29 CEST] <JEEB> timestamp data in raw AVC is not something you generally see [22:02:50 CEST] <furq> lahwran: out of interest, have you tried concatenating the files with ffmpeg [22:03:05 CEST] <lahwran> I have not, I don't really know how to use ffmpeg itself very well [22:03:11 CEST] <lahwran> tell me more [22:03:30 CEST] <lahwran> the main thing i know about ffmpeg is that if I do "ffmpeg -i a b" then it'll magically guess the right thing to do :p [22:03:32 CEST] <furq> if they're all keyframes and all the same size i can't see any obvious reason why that wouldn't work [22:03:39 CEST] <lahwran> huh interesting [22:03:48 CEST] <lahwran> will it try to make them non-keyframe? [22:04:16 CEST] <lahwran> part of why I want them to stay keyframes is that they don't have a lot of inter-frame compressibility [22:04:16 CEST] <furq> i don't think so but i've never had a reason to find out [22:04:21 CEST] <lahwran> cool [22:04:39 CEST] <lahwran> how would one do this? just provide -i multiple times? [22:04:43 CEST] <DHE> use of the concatenation feature and copying might work... [22:04:54 CEST] <DHE> https://trac.ffmpeg.org/wiki/Concatenate [22:05:00 CEST] <lahwran> oh cool [22:05:01 CEST] <furq> ffmpeg -i %d.mp4 -c copy out.mp4 [22:05:01 CEST] <DHE> It's a somewhat tricky subject, so just read up on it [22:05:13 CEST] <furq> and if that doesn't work then yeah, try using the concat filter/protocol [22:05:21 CEST] <JEEB> uhh [22:05:33 CEST] <JEEB> furq: I don't see that thing really working in any way [22:05:57 CEST] <JEEB> you hae a single -i and then that shell thing will open up to multiple file names, unless that is handled by ffmpeg itself [22:06:00 CEST] <JEEB> *have [22:06:09 CEST] <furq> that works for multiple images according to the wiki [22:06:12 CEST] <JEEB> yes [22:06:20 CEST] <JEEB> that's a special thing with the image2 format thing methinks [22:06:23 CEST] <furq> fair enough [22:06:32 CEST] <furq> i don't have a bunch of single-frame mp4s here or i'd have tested it first [22:06:35 CEST] <lahwran> hehe [22:13:38 CEST] <StephenS> ayo, is there a way to make a blinking video, on some parts, like the one taken in disco? [22:14:05 CEST] <lahwran> ok, so that worked pretty well [22:14:46 CEST] <lahwran> it's not as fast as I hoped though. I suspect it's still transcoding it. [22:22:37 CEST] <lahwran> hm, no, not still transcoding it, I don't think [22:41:03 CEST] <DHE> lahwran: did you put "-c copy" in your commandline? [22:45:04 CEST] <lahwran> yeah [22:45:53 CEST] <lahwran> it's printing "[mov,mp4,m4a,3gp,3g2,mj2 @ 0x2d01460] Auto-inserting h264_mp4toannexb bitstream filter" a lot [22:48:09 CEST] <DHE> odd, that usually means the container type was changed.. [22:53:45 CEST] <lahwran> oh man, ok [22:54:00 CEST] <lahwran> when I try it with the concat protocol, it's MUCH faster [22:54:13 CEST] <lahwran> much, much, much faster, as in I gave it 2500 and it was the same speed as 250 [22:54:42 CEST] <lahwran> ...oh... [22:54:46 CEST] <lahwran> I don't think it's working... [22:54:47 CEST] <lahwran> oops [23:00:18 CEST] <lahwran> DHE: how do you set the framerate in the output container? will -framerate do that, or will it make it edit the timestamps on each frame? [23:00:29 CEST] <furq> -r [23:03:22 CEST] <lahwran> that's not working [23:03:37 CEST] <lahwran> when I give it a crapton of .ts files as input and an mp4 as output, with this command: [23:03:47 CEST] <lahwran> v="$(@ '"|".join(["/run/shm/frame.ts"] * 500)')"; time ffmpeg -nostats -loglevel 0 -f mpegts -i "concat:$v" -r 25 -c copy -y -an /run/shm/testsadf9.mp4 [23:04:08 CEST] <lahwran> then I check testsadf9.mp4, it says 12800 fps (!) [23:04:43 CEST] <lahwran> it seems to have copied the frames ok, but since each frame was a single file, it had the time coding problem DHE warned me about originally [23:04:55 CEST] <lahwran> I also tried -framerate [23:04:57 CEST] <lahwran> neither of them did it [23:05:25 CEST] <lahwran> @ is just a "run this python" command, so the bash variable v contains 500 repetitions of /run/shm/frame.ts [23:05:57 CEST] <lahwran> oh, when I shut off quiet, it has a bunch of messages like: [23:05:58 CEST] <lahwran> [mp4 @ 0x2eb0440] Non-monotonous DTS in output stream 0:0; previous: 494, current: 0; changing to 495. This may result in incorrect timestamps in the output file. [23:07:04 CEST] <DHE> decode timestamps... yep, called it [23:07:36 CEST] <lahwran> hehe [23:07:58 CEST] <lahwran> DHE: any ideas how to fix it, considering that -r and -framerate appear to have done nothing? [23:09:20 CEST] <lahwran> how do I specify whether -r is an input or an output option? [23:09:25 CEST] <DHE> before you specify the output filename use "-r 30 -vsync drop" [23:09:42 CEST] <lahwran> what does "vsync drop" do? [23:10:00 CEST] <DHE> the commandline format of ffmpeg is: ffmpeg [input1 opts] -i input1 [[input2 opts] -i input2]... [output1 opts] output1 [[output2 opts] output2]... [23:10:07 CEST] <lahwran> oic [23:10:13 CEST] <lahwran> destroys input timestamps [23:10:13 CEST] <DHE> it drops the video frame sync data forcing regeneration [23:10:33 CEST] <lahwran> whoops, now it crashes [23:10:39 CEST] <lahwran> av_interleaved_write_frame(): Invalid argument [23:11:00 CEST] <lahwran> same command as I pasted above, except with -vsync drop added after -r 25 [23:12:30 CEST] Action: DHE is throwing science at the wall and seeing what sticks, honestly [23:12:43 CEST] <lahwran> hehe [23:12:53 CEST] <lahwran> that's apparently a valid way to cook pasta ;) [23:13:18 CEST] <lahwran> I learned this recently. apparently the saying comes from that being an actually-used way of checking whether pasta is done [23:14:34 CEST] <furq> it doesn't work as well with conchiglie [23:18:47 CEST] <lahwran> seems to work quite well with conceptelli though [23:19:12 CEST] <lahwran> looking around a bit, it seems that this is actually a known ffmpeg bug [23:19:31 CEST] <lahwran> it had been around for a while unfixed in 2011 [23:39:34 CEST] <sebboh> Hello. I have an avi file. I'm trying to play it on my chromecast. When I play an mp4 in chrome (on android) I can send it to the chromecast. Can I just put the content of the avi into a mp4 container and try that? [23:40:04 CEST] <DHE> sebboh: usually. can't hurt to try. ffmpeg -i input.avi -c copy output.mp4 [23:40:20 CEST] <sebboh> I'm on linux and I just installed ffmpeg, winff, and mediainfo. Oh, ok, trying. [23:40:31 CEST] <DHE> but it may depend on the codecs. worst case it doesn't work [23:41:09 CEST] <Mavrik> AVI can have a lot of crap and I don't think chromecast does the most common DivX [23:41:29 CEST] <DHE> there was a transition period when people put h264 in AVI. you might get lucky [23:41:59 CEST] <DHE> and divx was mostly mpeg4 (sorta) so maybe? [23:42:25 CEST] <sebboh> the avi is indeed divx. [23:43:20 CEST] <Mavrik> worstcase is that you have to transcode :- [23:43:22 CEST] <Mavrik> :/ [23:43:50 CEST] <Mavrik> DivX is a MPEG4 Part 2 [23:43:59 CEST] <Mavrik> I'm just not 100% if it's totally compatible. [23:44:30 CEST] <DHE> I'd prefer XviD myself if it came to that... [23:45:00 CEST] <Mavrik> Different encoder, same result :) [23:49:41 CEST] <sebboh> oh, it is XviD. The .mp4 I just created with -c copy doesn't play in the chrome (android) browser nor on the chromecast. So, I should provide some other -c option, eh? [23:51:03 CEST] <sebboh> Internet says: ffmpeg -i input.avi -f matroska -vcodec h264 -acodec aac -ac2 [23:51:08 CEST] <sebboh> Sound good to you folks? [23:51:36 CEST] <sebboh> oh, what is pipe:1 ? [23:52:13 CEST] <sebboh> ... nevermind, that's for redirecting the output somewhere, eh? [23:55:53 CEST] <sebboh> oh gawd, four seconds of encoding time for one second of play time. Time for a beer. :) [23:59:11 CEST] <BullHorn> im getting a bunch of 'Past duration 0.999992 too large' errors when reencoding a video [23:59:14 CEST] <BullHorn> i posted about this yesterday [23:59:28 CEST] <BullHorn> can someone take a look at the file? or should i provide something else ;x [23:59:38 CEST] <BullHorn> it only happens when i use NVENC in OBS, doesnt happen with quicksync or x264 [00:00:00 CEST] --- Mon Oct 19 2015

1 0

ffmpeg-devel.log.20151017
by burek 18 Oct '15

18 Oct '15

[00:12:43 CEST] <rcombs> considering working on Matroska edition support in lavf [00:13:08 CEST] <rcombs> wondering how to expose the multiple editions [00:13:45 CEST] <rcombs> picking one could be done with a private option, but it seems useful to have an API for listing them, and if we're going to have that then editions themselves may as well be a bit more native [00:15:01 CEST] <cone-569> ffmpeg 03James Almer 07master:3d1690b8c69c: avutil: undo FF_API_CRYPTO_CONTEXT deprecation [01:09:31 CEST] <J_Darnley> The help already states that options precede the file to which they refer. [01:54:39 CEST] <cone-569> ffmpeg 03Ganesh Ajjanagadde 07master:cf52ae003b42: avutil/mem: add av_warn_unused_result [01:57:02 CEST] <BBB> nevcairiel: go go go go go! [02:32:33 CEST] <wm4> rcombs: how would that even be possible without ordered chapters support? without them, editions are pretty useless [02:33:45 CEST] <cone-569> ffmpeg 03Michael Niedermayer 07master:a878dfa4f57d: avcodec/ffv1: Initialize vlc_state on allocation [03:31:47 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:b9fb1db9b42c: aactab: move ltp_coef[] from aacdectab to aactab [03:31:48 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:8dd2d5e70a30: aacenc: indicate that TNS is off by default [03:31:49 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:564db3e55dfd: aacenc_pred: correct header information [03:31:50 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:2d9b5ae071c0: aacenc: slightly simplify and remove a redundant variable [03:31:51 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:3f3be1c07ac0: aacenc: correctly zero prediction_used array [03:31:52 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:148cf4690c81: aacenc_pred: only print predictor information if profile is aac_main [03:31:53 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:83900c0ed34c: aacenc: (re)enable Mid/Side coding by default [03:31:54 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:27d23ae07424: aacenc: add support for encoding files using Long Term Prediction [03:55:18 CEST] <rcombs> wm4: I meant both [03:59:34 CEST] <cone-569> ffmpeg 03Ganesh Ajjanagadde 07master:3835554bf8ed: avfilter/avfiltergraph: fix -Wunused-result warnings [04:17:39 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:e9299df7a6df: aacenc: partially revert previous commits to set options via a profile [04:29:20 CEST] <atomnuker> alright, that about wraps it up folks, the only profile left to implement is AAC_HE [04:30:53 CEST] <atomnuker> I'll fix up TNS so it can be enabled by default, Claudio has to merge his techno-synth psy-cutoff fix consisting of a few one-liners [04:31:16 CEST] <atomnuker> and we'll remove the flag [04:32:19 CEST] <atomnuker> SSR doesn't seem like it's easily doable using the current encoder and I haven't seen any files at all encoded using that profile [04:33:35 CEST] <atomnuker> and parametric stereo doesn't seem like it's worth the effort and the quality loss for dubious gains with very specific audio files [05:49:00 CEST] <Timothy_Gu> BtbN: can you review https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-October/181184.html when you get the time? thx [06:44:40 CEST] <atomnuker> just noticed, turning on Mid/Side by default decreased the stddev in fate and I forgot to fix the targets, will push the new ones in a few mins [07:01:05 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:777b305bed15: fate: adjust aac encoder test values and introduce MS and LTP tests [07:38:53 CEST] <atomnuker> I had no idea ffmpeg is still compilable by gcc 3.4 from 2005, but apparently it's miscompiling the M/S coding [08:03:32 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:590008e69619: aacenc: increase fuzz on aac-ms-encode test [10:16:59 CEST] <cone-569> ffmpeg 03Timothy Gu 07master:d2a1029724f5: opencl: Print error string when compilation fails [10:17:00 CEST] <cone-569> ffmpeg 03Timothy Gu 07master:893a648182e4: opencl: Print compilation log [10:17:01 CEST] <cone-569> ffmpeg 03Timothy Gu 07master:17c68933f44f: opencl: Use "opencl" as log context name [10:17:02 CEST] <cone-569> ffmpeg 03Timothy Gu 07master:801eca1372dd: opencl: Force the use of 1.2 APIs [11:05:45 CEST] <BtbN> Timothy_Gu, huh, I don't have that mail. But sure [11:07:13 CEST] <BtbN> Could you paste the patch somewhere? I have no idea how to get a propper patch out of the archives. [11:08:09 CEST] <BtbN> But it looks good, feel free to push. [12:11:00 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:8d18d28918df: aacenc_tns: add moving average filter for LTP [12:11:01 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:f3ad901a32c9: aacenc_tns: disable coefficient compression by default [12:11:02 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:bf39beca8784: aacenc_tns: simplify encoding function [12:11:03 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:fa4d900c275f: aacenc_tns: rework TNS descision logic [12:11:04 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:8ce6e24db428: fate: adjust the target for the new TNS changes [12:11:05 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:dfba1be96350: aacenc_tns: enable Temporal Noise Shaping by default [12:11:06 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:d4da15563fb2: fate: add a parameter to disable TNS for the other encoder tests [12:12:01 CEST] <ubitux> @_@ [12:24:47 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:6eff30b0bcf9: fate: increase fuzz on AAC LTP encoding test [12:29:28 CEST] <michaelni_> atomnuker, "make fate-aac-ltp-encode" fails with Assertion n <= 31 && value < (1U << n) failed at libavcodec/put_bits.h:157 (needs --assert-level=2 i assume) [12:30:21 CEST] <atomnuker> I always use assert-level 2 [12:30:35 CEST] <atomnuker> hm [12:34:11 CEST] <atomnuker> michaelni_: with which sample does it happen with? [12:34:46 CEST] <michaelni_> fate-suite//audio-reference/luckynight_2ch_44kHz_s16.wav [12:34:49 CEST] <ubitux> according to make fate-aac-ltp-encode V=1, /home/ux/fate-samples/audio-reference/luckynight_2ch_44kHz_s16.wav [12:34:59 CEST] <ubitux> i also have the abort [12:39:17 CEST] <atomnuker> can't replicate yet, but on it [12:59:25 CEST] <cone-569> ffmpeg 03Michael Niedermayer 07master:58b19b6f636e: tests/fate-run: Remove PROGSUF from function calls [12:59:26 CEST] <cone-569> ffmpeg 03Michael Niedermayer 07master:acf23d9451e9: avformat/genh: Check av_new_packet() return value [12:59:27 CEST] <cone-569> ffmpeg 03Michael Niedermayer 07master:92a26261d1cc: avformat/rsd: Check av_new_packet() return value [13:00:45 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:780dba01f9ae: aacenc_ltp: fix assertion [13:01:23 CEST] <atomnuker> michaelni_ ubitux: fixed, that was a lame mistake [13:11:13 CEST] <michaelni_> atomnuker, thx [13:14:36 CEST] <wm4> rcombs: well, how do you intend to implement them at all? [13:18:24 CEST] <ubitux> atomnuker: can't use av_clip_uintp2(lag, 11) btw? [13:19:50 CEST] <atomnuker> didn't know there was such a function, thanks [13:22:46 CEST] <nevcairiel> can we call that super-ticket closed by now? :) [13:23:10 CEST] <ubitux> what's remaining before removing the experimental bit? [13:23:24 CEST] <kurosu> 500 posts in that ticket [13:23:26 CEST] <nevcairiel> claudios two fixes [13:23:33 CEST] <ubitux> :) [13:23:35 CEST] <ubitux> ok [13:23:51 CEST] <nevcairiel> so with any luck this weekend [13:25:06 CEST] <nevcairiel> in other news my braswell NUC arrived, hopefully Intels vp9 dxva2 isnt broken and i can finish my code! [13:25:26 CEST] <ubitux> yay :) [13:26:28 CEST] <kurosu> isn't that hybrid ? not a big deal I guess, as getting dvxa2 vp9 support was a big incentive [13:26:30 CEST] <kurosu> will it have any other use afterwards? [13:26:52 CEST] <nevcairiel> i dont really care how the driver implements it, hardware or hybrid [13:27:03 CEST] <nevcairiel> if i can get it to work, it will work on any implementation [13:27:07 CEST] <kurosu> as long as it plays realtime [13:27:21 CEST] <wm4> which intel cpus supposedly support vp9? [13:27:48 CEST] <kurosu> > haswell, ie broadwell, braswell and skylake ? [13:27:56 CEST] <nevcairiel> haswell doesnt [13:27:57 CEST] <kurosu> (not sure about broadwell) [13:28:05 CEST] <nevcairiel> broadwell seems to [13:28:27 CEST] <nevcairiel> so broadwell, braswell and skylake [13:28:47 CEST] <wm4> ok... skylake definitely doesn't report vp9 on linux [13:28:51 CEST] <ubitux> no overview of hevc/vp9 enc&dec hw support somewhere? [13:28:58 CEST] <nevcairiel> probably somewhere [13:29:04 CEST] <wm4> ubitux: there's a bad wiki page [13:29:06 CEST] <wm4> but no [13:29:11 CEST] <wm4> if you mean ffmpeg's [13:29:30 CEST] <nevcairiel> i think he meant hardware [13:29:33 CEST] <ubitux> no, unrelated to ffmpeg, just to see which codec is getting ground [13:32:21 CEST] <nevcairiel> i dont know of a nice overview, just that Intel supports vp9-hybrid since gen8, thats broadwell/braswell, skylake is gen9 [13:32:30 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:b0a3c614b4e3: aacenc_ltp: replace av_clip() with av_clip_uintp2() [13:32:31 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:b1d290920de5: fate: use -profile:a aac_ltp instead of -aac_ltp 1 for LTP encode test [13:33:55 CEST] <nevcairiel> (gen9 adds full hardware hevc main and hybrid main10, gen8 only had hybrid main, no 10 at all) [13:34:48 CEST] <nevcairiel> presumably vp8 is fully hardware accelerated, but current drivers dont seem to implement the Microsoft vp9 dxva2 spec yet [13:35:50 CEST] <fritsch> on windows ... [13:35:53 CEST] <fritsch> the world seems more bright [13:36:26 CEST] <fritsch> i will stop caring for linux hevc 10 bit support ... it's not worth the hassle ... [13:36:28 CEST] <nevcairiel> i really cant complain about that, i even managed to make zero copy dxva2 hevc10 decoding work a couple weeks ago [13:36:39 CEST] <fritsch> next gen CPUs to be released in 2k16 will have hw to do it [13:36:52 CEST] <fritsch> and then linux should be fine again [13:37:10 CEST] <fritsch> linux is not really a market for intel anymore ... [13:37:20 CEST] <nevcairiel> does vdpau do 10-bit? [13:37:21 CEST] <fritsch> vaapi wise [13:37:26 CEST] <ubitux> what's the state of h26[45]/vp9 10-bit on ARM btw? [13:37:30 CEST] <fritsch> it's planned philipl said [13:37:36 CEST] <fritsch> vp9 and hevc 10 bit [13:37:37 CEST] <fritsch> work [13:37:41 CEST] <nevcairiel> ubitux: no h264 10-bit from everyone [13:37:42 CEST] <fritsch> on android [13:37:46 CEST] <nevcairiel> anyone* [13:37:49 CEST] <fritsch> and amlogic [13:37:51 CEST] <ubitux> sad. [13:38:02 CEST] <fritsch> h264 10 bit <- [13:38:03 CEST] <nevcairiel> but 265 you might get lucky eventually [13:38:04 CEST] <fritsch> hevc you mean [13:38:20 CEST] <ubitux> no i meant h264 too [13:38:21 CEST] <nevcairiel> and vp9 10-bit .. you keep dreaming :) [13:38:24 CEST] <ubitux> :D [13:38:34 CEST] <nevcairiel> dxva2 only covers profile0, that is 420 8 [13:38:57 CEST] <ubitux> i mean, i have a ton of h264 10-bit material, and i was wondering if sth !intel could play them :p [13:39:16 CEST] <fritsch> ubitux: amd radeon oss vdpau [13:39:17 CEST] <fritsch> no joke [13:39:23 CEST] <fritsch> christian könig had some patches ready [13:39:26 CEST] <nevcairiel> its not true though [13:39:34 CEST] <nevcairiel> you will not a spec compliant image [13:39:37 CEST] <nevcairiel> +get [13:39:42 CEST] <fritsch> it was some internal hack [13:39:43 CEST] <fritsch> yes [13:39:54 CEST] <nevcairiel> it uses the 8-bit decoder, so you can hope it doesnt artifact too badly [13:39:59 CEST] <fritsch> hehe [13:40:01 CEST] <fritsch> yeah [13:40:06 CEST] <ubitux> small amd radeon hw out there? [13:40:13 CEST] <nevcairiel> some people liked to advertise that as 10-bit support [13:40:17 CEST] <nevcairiel> i can only laugh at them [13:40:29 CEST] <wm4> <nevcairiel> i really cant complain about that, i even managed to make zero copy dxva2 hevc10 decoding work a couple weeks ago <- was it worth it? [13:40:48 CEST] <nevcairiel> wm4: why not, 0% cpu load when decoding 4k 10-bit? [13:40:58 CEST] <nevcairiel> well 0 is a bit over the top, maybe 1% for parsing [13:41:19 CEST] <wm4> don't know, you always sounded pretty convinced over your copyback approach [13:41:27 CEST] <nevcairiel> that works fine too [13:41:35 CEST] <nevcairiel> but some people just have low-end systems [13:41:52 CEST] <nevcairiel> and while you give up some flexibility with using the zero copy mode, it works fine on those [13:42:07 CEST] <nevcairiel> 10-bit 4k is quite a bit of data that otherwise roams around the bus [13:43:35 CEST] <nevcairiel> it wasnt actually hard to get it working, just needed to convince the video renderer to accept it and treat it properly, which surprisingly wasnt that bad [13:44:12 CEST] <nevcairiel> the only annoying part is that Microsofts Enhanced Video Renderer can accept dxva2 surfaces with 10-bit content, but software buffers don't work, need to go 8-bit there [13:44:17 CEST] <nevcairiel> its one of those wtf moments :p [13:45:25 CEST] <wm4> fun [13:49:19 CEST] <Compn> just have to tell the hentai groups to stop encoding 10bit h264.... ;p [13:52:46 CEST] <nevcairiel> while this NUC is installing windows, i can go have some lunch \o/ [13:56:12 CEST] <kierank> atomnuker: shall I copy you the crashing files on avdev and ffmpeg build? [13:57:01 CEST] <nevcairiel> kierank: maybe you should try fuzzing with raw audio files and appropriate command lines, then you can get all these annoyances with the demuxer and whatnot out of the way [13:57:28 CEST] <kierank> doesn't seem to be demuxer related (look at the valgrind log) [13:57:44 CEST] <nevcairiel> but it tries to decode your wav file as aac, who knows whats going on :D [13:57:54 CEST] <kierank> it seems to be warped files being misdetected as aac and the decoded garbled audio causing the encoder to crash [13:58:15 CEST] <kierank> but I guess there might be a less circuitous route [13:58:36 CEST] <fritsch> might be related to: https://trac.ffmpeg.org/ticket/4864#comment:2 [13:58:42 CEST] <fritsch> happens more often [13:58:46 CEST] <fritsch> in other places [13:58:56 CEST] <nevcairiel> thats specifically mp3 being annoying [13:58:59 CEST] <fritsch> this was ac3 as mp3 [13:59:26 CEST] <nevcairiel> the mp3 probe can be quite forgiving and accept whatever files [13:59:38 CEST] <fritsch> "Plays fine with WMP, I don't know if this will be fixed in FFmpeg." [13:59:47 CEST] <fritsch> i don't understand this answer btw. [14:00:15 CEST] <nevcairiel> noone understands carl sometimes [14:00:18 CEST] <fritsch> hehe [14:00:38 CEST] <fritsch> does that mean: he does not know, if he feels like fixing it [14:00:47 CEST] <fritsch> or he does not know, if someone will fix it [14:00:52 CEST] <fritsch> or if it's "fixable" [14:00:53 CEST] <fritsch> :-) [14:00:59 CEST] <fritsch> yeah, let's keep it open anyways [14:03:06 CEST] <nevcairiel> why does trac open a .ts file in a text viewer instead of offering me a download [14:29:32 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:4c9805538db0: aacenc_ltp: correct header description comment [15:02:09 CEST] <cone-569> ffmpeg 03Clément BSsch 07master:8c9c8fd035a9: avfilter/selectivecolor: fix correction_method option range [15:08:43 CEST] <J_Darnley> nevcairiel: I guess the server says its mime type is text ot html [15:39:26 CEST] <cone-569> ffmpeg 03Hendrik Leppkes 07master:a8e86b0e3f38: libavformat/Makefile: remove unnecessary object file from wtv demuxer [15:51:53 CEST] <durandal_1707> atomnuker: are you going to add he-aac? [16:43:37 CEST] <cone-569> ffmpeg 03Timothy Gu 07master:ed53c14a3ce2: chromakey: Use the pixel descriptor API for chroma subsampling info [16:47:48 CEST] <Timothy_Gu> BtbN: okay thx. pushed [16:59:33 CEST] <ubitux> btw, the "unit" thing in AVOption is weird; the const avoption .unit should simply refer to the related option name, instead of adding a double string of (often) the exact same value in the main option [16:59:44 CEST] <ubitux> or i'm missing something? [17:06:46 CEST] <nevcairiel> Timothy_Gu: your funny parsing comment totally confused ganesh :D [17:07:14 CEST] <Timothy_Gu> I'd like to declare 3 arguments to be stored on registers, 2 arguments on the stack, and 2 gprs. can I do that? [17:07:20 CEST] <Timothy_Gu> nevcairiel: yes it did :( [17:07:31 CEST] <Timothy_Gu> (in x86 asm) [17:07:33 CEST] <nevcairiel> registers == gprs [17:07:41 CEST] <Timothy_Gu> yes ik [17:07:54 CEST] <nevcairiel> you mean in that particular order? [17:07:57 CEST] <nevcairiel> then no, you cannot [17:08:18 CEST] <nevcairiel> you can only have trailing arguments on the stack, not some in the middle [17:08:34 CEST] <nevcairiel> of course you could emulate that yourself by simply loading the last 2 arguments into a reg [17:08:39 CEST] <Timothy_Gu> no the two args are trailing [17:08:50 CEST] <Timothy_Gu> and i want two free additional registers [17:08:56 CEST] <Timothy_Gu> not used for the args [17:09:02 CEST] <nevcairiel> i'm confused now [17:09:12 CEST] <nevcairiel> you want 5 arguments, 2 on stack? [17:09:16 CEST] <Timothy_Gu> yes [17:09:17 CEST] <nevcairiel> and 2 tmp registers? [17:09:19 CEST] <Timothy_Gu> yes [17:09:36 CEST] <nevcairiel> that should be possible [17:09:46 CEST] <nevcairiel> just declare 5 regs, 3 arguments [17:09:54 CEST] <nevcairiel> i think [17:10:00 CEST] <Timothy_Gu> oh [17:10:20 CEST] <nevcairiel> although getting ahold of the stack arguments might be a bit weird then [17:10:22 CEST] <nevcairiel> i dunno [17:10:26 CEST] Action: nevcairiel reads docs [17:10:42 CEST] <J_Darnley> on x68-64 4 or 6 args are passed registers [17:10:51 CEST] <J_Darnley> *in registers [17:11:10 CEST] <J_Darnley> The first param controls automatically loaded arguments [17:11:25 CEST] <J_Darnley> The second how many registers you want to use [17:11:38 CEST] <J_Darnley> total that is [17:11:51 CEST] <nevcairiel> you need to use stack pointer math to find your last two arguments then, though [17:12:09 CEST] <J_Darnley> rXm will work in that case [17:12:22 CEST] <nevcairiel> ah right [17:12:24 CEST] <nevcairiel> i forgot [17:12:29 CEST] <J_Darnley> or rXmp depending on size [17:13:07 CEST] <nevcairiel> "cglobal foo, 3, 5, X, arg1, arg2, arg3, tmp1, tmp2" should work then [17:13:12 CEST] <Timothy_Gu> so if i declared 3,5, my first args are in r0, r1, and r2 (properly named of course), next two args are in r3mp and r4mp, and two free registers are r3 and r4? [17:14:03 CEST] <J_Darnley> Yes, if on 32 bit [17:14:10 CEST] <Timothy_Gu> does that work with 64-bit since r3mp is technically equivalent to r3? [17:14:29 CEST] <nevcairiel> i would hope x86inc is s mart enough and doesnt assign r3 to tmp1 then [17:15:19 CEST] <J_Darnley> I don't think it is. [17:15:54 CEST] <Timothy_Gu> :( [17:16:44 CEST] <J_Darnley> Use the DEFINE_TMP_REG macro to set which registers are used on which platform [17:17:30 CEST] <J_Darnley> Yadif has an example of differing register usage [17:18:05 CEST] <Timothy_Gu> ok i'll take a look [17:18:21 CEST] <J_Darnley> (I'm sure others do too but I know yadif) [17:48:35 CEST] <ubitux> i have a memory corruption with a normal aac encode with ffmpeg; atomnuker, interested? [17:49:26 CEST] <ubitux> http://pastie.org/pastes/10488769/text [17:51:06 CEST] <kierank> wow [17:51:11 CEST] <ubitux> happens only with -profile:a aac_ltp (i was looking at #2686 and it was mentioned) [17:51:22 CEST] <kierank> ah [17:51:35 CEST] <ubitux> (86.69% ffmpeg_g ffmpeg_g [.] ff_aac_update_ltp btw..) [17:54:22 CEST] <ubitux> ADTS frame size too large: 8804 (max 8191) [17:54:25 CEST] <ubitux> damn. [17:54:31 CEST] <ubitux> i'm going to have some trouble making a small sample. [17:54:58 CEST] <kierank> mux it in latm [17:55:02 CEST] <ubitux> can't codec copy a aac :( [17:55:23 CEST] <ubitux> ah i'm stupid. [17:57:36 CEST] <ubitux> zsh: floating point exception (core dumped) [17:57:44 CEST] <ubitux> funny, i'm getting this with a sample of it... [18:04:59 CEST] <Timothy_Gu> apparently my WIP asm file stalls yasm ... [18:06:54 CEST] <JEEB> make sure it's newer than 1.2 [18:07:17 CEST] <JEEB> https://github.com/yasm/yasm/commit/e32ff2c2abc22532a58c9b687d922500d23fd709 [18:07:22 CEST] <JEEB> you pretty much want to have this [18:08:16 CEST] <Timothy_Gu> yasm --version [18:08:16 CEST] <Timothy_Gu> yasm 1.3.0 [18:08:17 CEST] <Timothy_Gu> Compiled on May 3 2015. [18:08:26 CEST] <Timothy_Gu> I think I messed somewhere with the macros [18:08:31 CEST] <Timothy_Gu> *messed up [18:08:35 CEST] <ubitux> atomnuker: http://trac.ffmpeg.org/ticket/4943 [18:11:20 CEST] <Timothy_Gu> hmm seems like it's because of a typo DEFINE_REG_TMP -> DECLARE_REG_TMP [18:11:39 CEST] <Timothy_Gu> nice one yasm [18:19:19 CEST] <Timothy_Gu> J_Darnley: how can you access a 64-bit argument in x86_32? [18:19:38 CEST] <nevcairiel> thats a bit more tricky [18:20:25 CEST] <Timothy_Gu> hm ok [18:28:25 CEST] <cone-569> ffmpeg 03Ganesh Ajjanagadde 07master:01790484c130: avfilter/internal: add av_warn_unused_result [18:33:18 CEST] <nevcairiel> i should setup distcc, poor braswell is melting trying to rebuild avcodec all the time [18:40:48 CEST] <cone-569> ffmpeg 03Marton Balint 07master:df239b761951: concatdec: fix file_start_time calculation regression [18:43:06 CEST] <jamrial> nevcairiel: ccache? [18:45:57 CEST] <atomnuker> ubitux: I can't seem to replicate the LTP crash [18:46:14 CEST] <ubitux> i can replicate with many inputs actually [18:46:20 CEST] <atomnuker> can you tell me if it still happens if you put -aac_tns 0 ? [18:48:43 CEST] <ubitux> will test in a moment [18:49:00 CEST] <ubitux> btw, i believe this: http://pastie.org/10488930 might improve speed (untested, random crashes don't help) [18:49:29 CEST] <ubitux> you might also want to define a NBITS 11 to make sure the samples_num is indeed interpreted as a scalar in that part [18:50:01 CEST] <ubitux> (and use 1<<11 and 1<<10 instead of samples_num and 1024, maybe) [18:50:01 CEST] <nevcairiel> hm [18:50:06 CEST] <nevcairiel> my vp9 hwaccel kind of works [18:50:12 CEST] <nevcairiel> it can decode key frames, apparently [18:51:05 CEST] <nevcairiel> ..and then something weird happens on the next frame :D [18:51:48 CEST] <ubitux> atomnuker: i can't reproduce the crash anymore; i'm starting to wonder if it was a ccache or random breakage on my system [18:52:43 CEST] <atomnuker> ubitux: even if you reenable aac_tns? [18:52:52 CEST] <ubitux> yeah, sth is fishy [18:53:03 CEST] <ubitux> gonna cleanup ccache cache & rebuild everything. [18:54:19 CEST] <J_Darnley> Timothy_Gu: for arithmetic I have no idea. You would have to look it up [18:58:01 CEST] <Timothy_Gu> ok [18:58:25 CEST] <Timothy_Gu> i'm using it in psraw anyway so i guess I can just pass in the stack offset [19:09:25 CEST] <rcombs> wm4: planning on going the lazy route in avformat/matroskadec (which should cover the vast majority of use-cases) [19:14:03 CEST] <cone-569> ffmpeg 03Michael Niedermayer 07master:66d36668031d: tests/fate-run: Remove ./ from run ffmpeg call [19:14:04 CEST] <cone-569> ffmpeg 03Michael Niedermayer 07master:c38a6077eea8: avcodec/aacenc: Fix "libavcodec/aacenc.c:540:13: warning: ISO C90 forbids mixed declarations and code" [19:17:36 CEST] <ubitux> atomnuker: i know what you're going to say, but can you reproduce with my patch applied? [19:18:21 CEST] <ubitux> i wonder if it's a race [19:20:09 CEST] <atomnuker> ubitux: how'd you know what I was going to say? I'd like to know what I was going to say. [19:20:19 CEST] <nevcairiel> my vp9 hwaccel works now... but only if threading is disabled [19:20:23 CEST] <nevcairiel> f'ing threading with hwaccels [19:20:24 CEST] <atomnuker> your patch did speed up encoding by a second for 10 second files [19:20:32 CEST] <ubitux> atomnuker: that if my patch is the cause of the crash [19:20:34 CEST] <nevcairiel> i should just patch it out of the sources secretly [19:20:38 CEST] <ubitux> i should patch it myself [19:20:52 CEST] <ubitux> (but i swear the crash happened before my patch too :() [19:20:58 CEST] <ubitux> (now i can only trigger it with my patch applied) [19:21:04 CEST] <ubitux> atomnuker: ah, that sounds pretty good [19:21:10 CEST] <ubitux> does it look correct to you? [19:22:06 CEST] <wm4> nevcairiel: propose a patch that disables threading while hwaccel is active [19:22:48 CEST] <nevcairiel> the real problem is that i dont know if its just a bug in my code or just the usual threading failure [19:22:53 CEST] <atomnuker> ubitux: yes, fate-aac-ltp-encode doesn't fail so it's probably making identical files [19:24:46 CEST] <fritsch> nevcairiel: is there any hwaccel that actually uses threading? [19:25:09 CEST] <nevcairiel> fritsch: no, they dont, and avcodec fudges it in such a way that frame threads just execute serially and never in parallel [19:25:14 CEST] <fritsch> we also handle that specially in kodi [19:25:16 CEST] <nevcairiel> but that doesn't account for a bunch of othre things [19:25:18 CEST] <fritsch> to not run into issues [19:25:27 CEST] <fritsch> most when processing thumbnails [19:25:39 CEST] <fritsch> okay [19:25:46 CEST] <nevcairiel> ie. avcodec doesnt know what the user code is going to do with the hw surfaces [19:25:55 CEST] <wm4> only vlc wants hwaccel and threads [19:26:04 CEST] <nevcairiel> because they have lazy devs [19:26:05 CEST] <nevcairiel> :P [19:26:08 CEST] <fritsch> hehe [19:26:16 CEST] <wm4> they want to use lavc's native sw decoding fallback [19:26:26 CEST] <fritsch> they don't have to loose it [19:26:28 CEST] <nevcairiel> yes, thats the lazy approach [19:26:29 CEST] <ubitux> atomnuker: https://github.com/ubitux/FFmpeg/compare/ltp-fast and with that last one? [19:26:29 CEST] <fritsch> see how kodi does it [19:26:36 CEST] <wm4> fritsch: how does kodi do it [19:26:41 CEST] <fritsch> wait I show you [19:26:49 CEST] <fritsch> that was a very long discussion [19:26:50 CEST] <nevcairiel> i do it clean and re-open the codeccontext [19:26:53 CEST] <nevcairiel> similar to mpv i believe [19:26:53 CEST] <fritsch> cause if hwaccel opening failed [19:26:57 CEST] <fritsch> we ended single threaded [19:27:08 CEST] <wm4> nevcairiel: yes [19:27:21 CEST] <wm4> I completely destroy and recreate the context [19:27:27 CEST] <nevcairiel> same [19:27:38 CEST] <atomnuker> ubitux: already did those, didn't result in much of a speedup [19:27:43 CEST] <ubitux> ok [19:27:46 CEST] <fritsch> https://github.com/xbmc/xbmc/blob/master/xbmc/cores/dvdplayer/DVDCodecs/Vid… [19:27:58 CEST] <ubitux> atomnuker: and with these patches, can't reproduce the crash? [19:28:11 CEST] <fritsch> so in case hwaccel fails to init we fully reopen [19:28:14 CEST] <fritsch> and set hints to software [19:28:22 CEST] <nevcairiel> sounds about the same [19:28:25 CEST] <ubitux> it seems to help triggering [19:29:02 CEST] <nevcairiel> thats what we do as well, if hwaccel fails for some reason, just do a complete reset and re-open the decoder with software [19:29:13 CEST] <nevcairiel> just vlc didnt want to do this, so now we have hacks :) [19:29:15 CEST] <nevcairiel> that barely work [19:29:56 CEST] <atomnuker> ubitux: nope [19:30:00 CEST] <ubitux> ok :( [19:30:23 CEST] <ubitux> should i send, apply, wait, or drop the patches? [19:30:35 CEST] <nevcairiel> maybe i can at least figure out why it crashess with threads, it didnt do that with h264 previously [19:31:01 CEST] <atomnuker> ubitux: well, I've already got a few more optimizations on top of your patches [19:31:08 CEST] <ubitux> ok ok [19:31:16 CEST] <ubitux> well i drop & wait then [19:31:21 CEST] <wm4> IMO a player needs to be more flexible about fallbacks, up to a point that the fallback (or hwaccel) might use a different AVCodec, or not even lavc at all [19:31:39 CEST] <nevcairiel> yeah i can do that [19:31:48 CEST] <ubitux> atomnuker: perf still says 82.41% in ff_aac_update_ltp, so i'm assuming there is a lot of room for improvement [19:31:50 CEST] <nevcairiel> i can fallback from vc1 hwaccel to the MS DMO decoder if need be [19:31:57 CEST] <nevcairiel> and that works nicely [19:31:59 CEST] <ubitux> anyway, thx, i'll check if i can reproduce the crash [19:35:17 CEST] <nevcairiel> nice to see that my vp9 hwaccel works otherwise though [19:36:27 CEST] <nevcairiel> wm4: unfortunately preventing frame threading with hwaccel is not really doable, since it sets up threading first and only then asks get_format eventually, and falling out of threaded mode is not going to be pretty [19:38:29 CEST] <wm4> can't it just send all work to a single thread? [19:38:39 CEST] <wm4> (I have no idea how exactly frame threading works) [19:39:09 CEST] <nevcairiel> could do it other way around, prevent hwaccel with threading [19:39:46 CEST] <wm4> wouldn't that break vlc hw decoding? [19:40:07 CEST] <nevcairiel> look at me caring [19:40:26 CEST] Action: rcombs stares at nevcairiel [19:40:49 CEST] <nevcairiel> apparently it crashes because every thread calls get_format [19:40:54 CEST] <nevcairiel> i wonder how other decoders do that [19:40:56 CEST] Action: nevcairiel checks [19:44:48 CEST] <Compn> did someone say binary codec loader ? [19:44:54 CEST] <Compn> ms dmo... [19:46:11 CEST] <BBB> nevcairiel: h264 disallows threads and hwaccel [19:46:17 CEST] <BBB> nevcairiel: you need to add such a check for vp9 also [19:46:21 CEST] <BBB> but it works! nice [19:46:24 CEST] <BBB> congrats [19:46:25 CEST] <nevcairiel> BBB: you would be surprised to know the opposite is true [19:46:25 CEST] <BBB> very cool [19:46:31 CEST] <BBB> ????? [19:46:34 CEST] <nevcairiel> it does not disallow it [19:46:34 CEST] <BBB> gotta be kidding me [19:46:35 CEST] <BBB> really? [19:46:49 CEST] <BBB> I would just disallow it [19:46:51 CEST] <BBB> but who am I [19:46:56 CEST] <nevcairiel> someone hacked it in a couple years ago [19:46:58 CEST] <BBB> I would swear it used to disallow it at some point [19:47:01 CEST] <nevcairiel> and it causes a bunch of issues [19:49:08 CEST] <wm4> all these obscure half-working features that cause trouble for everyone are awesome [19:49:51 CEST] <nevcairiel> last time i talked abour removing them a couple devs got all outraged [19:50:23 CEST] <Compn> slice threading ? [19:50:27 CEST] Action: Compn runs [19:51:02 CEST] <nevcairiel> so.. is get_format really supposed to be called everytime the size changes? [19:51:25 CEST] <nevcairiel> i dont think all other codecs do that [19:56:21 CEST] <wm4> well, you may need to reinit the hwaccel, right? [19:59:02 CEST] <nevcairiel> i'll just forget about the threading issue and propose a patch to disable the combination at a later time [19:59:16 CEST] <nevcairiel> or just do it locally in vp9 because EBROKEN [20:03:26 CEST] <cone-569> ffmpeg 03Paul B Mahol 07master:c37d2cd01cd6: avformat/vag: fix demuxing stereo files [20:03:56 CEST] <BBB> well the threading is initialized somewhere else [20:04:09 CEST] <BBB> maybe a cap so a codec can indicate if it supports mt+hwaccel at the same time [20:04:14 CEST] <BBB> and only set that in h264 [20:08:37 CEST] <nevcairiel> ah, as expected, the real crash is in the intel driver [20:08:40 CEST] <nevcairiel> with mt [20:08:56 CEST] <nevcairiel> i can live with that, it does weird things with the other codecs as well [20:09:22 CEST] <wm4> I can't really comprehend how hwaccel with threading works at all [20:09:47 CEST] <nevcairiel> it just ensures that no more than one decoder thread runs at a time [20:10:00 CEST] <nevcairiel> and that part is fine [20:10:22 CEST] <wm4> certainly it can't run multiple threads, because there's so much shared state that would conflict [20:10:42 CEST] <BBB> maybe you can report the crash to intel and ask them to fix it [20:10:43 CEST] <BBB> :-p [20:10:45 CEST] <nevcairiel> however, the problem starts when the calling code starts using the surface afterwards, which is no logner controlled by avcodec, so calling code and next decoder thread collide and who knows what happens [20:11:40 CEST] <nevcairiel> hrm for other weird reasons, running the decoder in mt mode allocates the same surface for the first X frames [20:11:44 CEST] <nevcairiel> why would it do that o.o [20:12:46 CEST] <wm4> scary [20:12:58 CEST] <nevcairiel> thats certainly reason for my crash [20:13:42 CEST] <rcombs> I can't really comprehend how hwaccel works at all [20:13:52 CEST] <rcombs> (mostly because I haven't looked very closely) [20:16:41 CEST] <nevcairiel> ..as if its not actually allocating a new frame on the new threads [20:16:45 CEST] <nevcairiel> but why the hell would it not [20:17:09 CEST] <rcombs> seen that libav patch adding qsv transcoding in ffmpeg? [20:17:17 CEST] <rcombs> it kinda scares me [20:17:37 CEST] <rcombs> hoping that's just temporary and something more generic replaces it [20:22:02 CEST] <wm4> the years of cleanup work always have to be preceded by something [20:23:06 CEST] <BBB> qsv transcoding? [20:23:12 CEST] <BBB> what is that [20:23:21 CEST] <JEEB> intel stuff [20:24:23 CEST] <BtbN> A giant horrible mess, specialy on linux. [20:25:24 CEST] <rcombs> now with extra dedicated handling in avconv.c [20:25:44 CEST] <rcombs> (to do no-copy hardware transcode pipelines) [20:26:16 CEST] <rcombs> Intel wrote a patch like that for their previous hardware transcoding infrastructure, too [20:26:26 CEST] <rcombs> on top of ffmpeg, like, 0.9 or something [20:30:10 CEST] <nevcairiel> 99% of the code is contained in a single extra file, so its not too bad imho [20:39:45 CEST] <nevcairiel> ok its broken because it keeps re-allocating the hwaccel on every thread, because the vp9 decoder actually runs a full init for every frame thread to allocate a few things, no idea how to prevent that from happening [20:44:58 CEST] <wm4> clearly this is a good enough reason to just disallow threads [20:45:01 CEST] <wm4> with hwaccel [20:45:12 CEST] <wm4> I suggest adding a simple check, and let decoder init fail [20:45:24 CEST] <nevcairiel> init doesnt know if we do hwaccel yet [20:45:28 CEST] <wm4> so if get_format returns a hwaccel and there are multiple threads -> error [20:45:44 CEST] <nevcairiel> but yeah could throw it in get_format checks [20:49:47 CEST] <nevcairiel> https://github.com/Nevcairiel/FFmpeg/commit/a8d8ade7f4bbf0ade12e619768a8bed… [20:49:50 CEST] <nevcairiel> this should already do it [20:50:23 CEST] <wm4> yeah [20:50:37 CEST] <wm4> but vlc will be mad [20:51:25 CEST] <nevcairiel> the change in itself is not perfect because it still calls get_format first [20:51:39 CEST] <nevcairiel> but its the cleanest position to put it [20:54:05 CEST] <fritsch> nevcairiel: if you see the code I posted before [20:54:13 CEST] <fritsch> nevcairiel: you see the work around for the getFormat call [20:54:18 CEST] <fritsch> if I see that correctly [20:54:54 CEST] <fritsch> mmh, VC1 only [20:54:59 CEST] <fritsch> i think we did not test VP9 :-) [20:55:02 CEST] <fritsch> might be the same issue [21:03:00 CEST] <cone-569> ffmpeg 03Derek Buitenhuis 07master:516d34de424f: mpegts: Make the pat_period a double [21:03:01 CEST] <cone-569> ffmpeg 03Derek Buitenhuis 07master:4ffdba2418ab: mpegts: Make the sdt_period a double [21:30:46 CEST] <nevcairiel> wm4: i sent the hwaccel threading patch as a rfc [21:32:26 CEST] <wm4> cue to drama [21:33:44 CEST] <wm4> ah, ffmpeg-devel only [21:44:40 CEST] <nevcairiel> iirc reimar was one of the local devs that complained last time [21:44:46 CEST] <nevcairiel> lets see if someone is still alive that cares [22:37:23 CEST] <cone-569> ffmpeg 03Marton Balint 07release/2.8:e0e28dad9092: concatdec: fix file_start_time calculation regression [22:53:53 CEST] <nevcairiel> BBB: majority of fate-vp9 also passes with the hwaccel, just some special ones like resizing frames dont work .. thats probably going to be annoying to support, too [22:54:11 CEST] <BBB> its part of profile 0, so it should work [22:54:18 CEST] <BBB> you may have to do some special reinitialization [22:54:31 CEST] <BBB> is resize the only one that doesnt work? or is there more? [22:54:44 CEST] <nevcairiel> yeah it needs handling on the api user side, as right now any size change throws away everything [22:55:00 CEST] <BBB> in your code, you mean? [22:55:05 CEST] <BBB> right, you shouldnt do that [22:55:08 CEST] <BBB> you need to keep refs [22:55:10 CEST] <BBB> thats important [22:55:14 CEST] <wm4> a resize should cause get_format to be called, to reinit the decoder [22:55:20 CEST] <wm4> wait what [22:55:25 CEST] <wm4> keep refs on resizes? [22:55:28 CEST] <BBB> yes [22:55:33 CEST] <BBB> vp9 includes scaling in profile 0 [22:55:33 CEST] <wm4> that's fucking trippy [22:55:33 CEST] <nevcairiel> vp9 specifically allows refs with different sizes [22:55:35 CEST] <BBB> like mpeg4 [22:55:43 CEST] <BBB> wm4: tell that to the dude that added it (not me!) [22:55:48 CEST] <wm4> lol [22:56:00 CEST] <wm4> anyway, I don't think get_format implies flushing, or does it? [22:56:02 CEST] <nevcairiel> the dxva2 spec even specifies which scaling algorithm the hardware should use [22:56:28 CEST] <nevcairiel> there is however one problem to the entire deal [22:56:35 CEST] <BBB> I feel that scaling in vp9 is like mbaff in h264 [22:56:42 CEST] <BBB> Im not sure itll re-appear in vp10 [22:56:42 CEST] <nevcairiel> dxva2 at least has to create all surfaces up front and init the encoder with a list of said surfaces [22:56:53 CEST] <nevcairiel> decoder* [22:57:12 CEST] <nevcairiel> so.. i have to re-create the decoder with the new sized surfaces, but somehow keep references [22:57:13 CEST] <wm4> this preallocation stuff is annoying [22:57:23 CEST] <nevcairiel> i could try to be creative and copy the old surfaces onto the new one or something [22:57:28 CEST] <nevcairiel> but its not going to be pretty [22:57:45 CEST] <nevcairiel> but yes BBB, vp-05-resize is the only fate test that fails [22:57:53 CEST] <nevcairiel> and of course all non-profile0 tests dont use the hwaccel [22:57:54 CEST] <BBB> congrats [22:58:00 CEST] <wm4> do these references really have to be part of the preallocated surface list? [22:58:01 CEST] <BBB> yeah thats ok [22:58:26 CEST] <nevcairiel> wm4: i have no idea, but I would assume it just barfs otherwise [22:58:49 CEST] <nevcairiel> not sure this feature is worth giving me a headache right now though [22:58:58 CEST] <BBB> hehehe [22:59:04 CEST] <wm4> do you know on resize if or which frames need to be "kept"? [22:59:17 CEST] <BBB> I probably spend >50% of total ffvp9 time (simd not included) on scaling [22:59:19 CEST] <BBB> wm4: all [22:59:29 CEST] <wm4> nasty, then [22:59:29 CEST] <BBB> wm4: sclaing is completely unrelated to ref frame management [22:59:32 CEST] <nevcairiel> so the answer is, you dont [22:59:34 CEST] <BBB> so all refs stay alive on a resize [22:59:46 CEST] <BBB> you dont scale the refs though; scaling happens in mc [22:59:52 CEST] <BBB> (Im serious) [22:59:54 CEST] <wm4> how does thw sw decoder handle it?? [22:59:54 CEST] <nevcairiel> yeah i understood that part [23:00:01 CEST] <BBB> wm4: you scale in mc [23:00:06 CEST] <BBB> in the per-block decoding loop [23:00:10 CEST] <BBB> Im serious [23:00:38 CEST] <wm4> I mean, how does it handle the surfaces? [23:00:56 CEST] <nevcairiel> software doesnt really care [23:01:12 CEST] <nevcairiel> it just creates a new frame pool, and the old frames get deleted as soon as they are unref'ed [23:01:26 CEST] <wm4> uh, ok [23:01:56 CEST] <nevcairiel> the dxva2 spec mentions that knowing the maximum size would be super as i could pre-alloc the frames then and just draw small frames on big surfaces [23:02:04 CEST] <nevcairiel> but really, when do you know that [23:02:19 CEST] <wm4> lol [23:02:34 CEST] <wm4> this part of vp9 is really not sane [23:02:46 CEST] <wm4> being too clever about obscure things like midstream resizing [23:02:57 CEST] <nevcairiel> I might try to implement that in my own code and see how it works, and maybe if I feel really crazy backport to ffmpeg_dxva2.c [23:02:59 CEST] <BBB> thats easy to say as an engineer writing decoders [23:03:10 CEST] <wm4> BBB: so can every mc reference a scaled part of another frame? [23:03:13 CEST] <BBB> you should see the sparkles in the eyes of users, when they hear this is part of the base codec [23:03:24 CEST] <nevcairiel> why would users care [23:03:31 CEST] <nevcairiel> how do you even feed that to vpxenc [23:03:31 CEST] <BBB> wm4: if the ref size != my size, the mc automatically scales [23:03:40 CEST] <BBB> I dont think vpxenc supports it [23:03:46 CEST] <BBB> theres just test scripts [23:03:50 CEST] <nevcairiel> so, no real world samples [23:03:53 CEST] <wm4> BBB: fucking hell, so it's active only when frame sizes change? [23:03:54 CEST] <nevcairiel> i'm not going to do this then! [23:03:56 CEST] <BBB> correct [23:04:00 CEST] <BBB> wm4: yes [23:04:06 CEST] <BBB> nevcairiel: good idea :-p [23:04:08 CEST] Action: wm4 shakes head [23:04:25 CEST] <BBB> oh you want it to work on zooms? [23:04:27 CEST] <BBB> like in mpeg4? [23:04:29 CEST] <nevcairiel> going to clean up some parts in the patch [23:04:47 CEST] <nevcairiel> there are one or two ugly parts in vp9.c that i had to do though :( [23:05:03 CEST] <BBB> Ill look [23:05:10 CEST] <BBB> if I hate it, Ill poke you [23:05:14 CEST] <nevcairiel> https://github.com/Nevcairiel/FFmpeg/commit/35a617787638e82f99dda87a590ec4f… [23:05:22 CEST] <nevcairiel> that block in particular was super annoying [23:05:36 CEST] <nevcairiel> you check AVFrame->format :( [23:06:30 CEST] <BBB> do you need the segmentation map in hw? [23:06:35 CEST] <nevcairiel> no [23:06:41 CEST] <nevcairiel> just some of the metadata [23:06:57 CEST] <nevcairiel> all that is in vp9.h in master now is enough [23:07:04 CEST] <BBB> so cant you skip allocating that then? [23:07:12 CEST] <BBB> in vp9_alloc_frame [23:07:17 CEST] <nevcairiel> i suppose [23:07:28 CEST] <nevcairiel> is that big enough to care? [23:08:19 CEST] <nevcairiel> i can also skip decoding the compressed frame headers, nothing of that is needed [23:08:23 CEST] <nevcairiel> but meh optimizations :) [23:09:10 CEST] <BBB> lol [23:09:21 CEST] <BBB> I mean, I would, because why not [23:10:35 CEST] <BBB> also nice gotos [23:10:48 CEST] <BBB> can you unindent the #define? [23:11:28 CEST] <nevcairiel> hwaccel_max? sure [23:19:23 CEST] <TD-Linux> the main use case for the scalable reference frames is video conferencing, where you want to react to a change in available bandwidth by changing res [23:20:31 CEST] <nevcairiel> cant you just do what everyone does and send a new intra and be done with it [23:21:08 CEST] <TD-Linux> intra frames are really expensive and terrible [23:21:44 CEST] <TD-Linux> however, doing something like limiting the # of references that are saved in a resolution change to 1 would have been sane [23:32:57 CEST] <nevcairiel> i could make the hwaccel support decreasing the size without much trouble, as i can keep the same surfaces then [23:33:01 CEST] <nevcairiel> increasing is another matter [23:35:23 CEST] <nevcairiel> i suppose if you are dealing with video conferencing, you might know the maximum size beforehand and could setup the decoder with that info [23:37:53 CEST] <TD-Linux> yeah that's how I would do it, to avoid runtime allocation. but I guess vp9 doesn't really have a way to signal that [23:38:57 CEST] <TD-Linux> though, I guess you can't have the same src and dest buffer for scaling, so maybe not [23:40:26 CEST] <nevcairiel> if the bitstream actually included that max size, that would've been nice [23:53:18 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:7303962f1467: aacenc_ltp: adjust and speed up autocorrelation calculations [00:00:00 CEST] --- Sun Oct 18 2015

1 0

ffmpeg.log.20151017
by burek 18 Oct '15

18 Oct '15

[00:24:19 CEST] <Guest6668> d [00:24:52 CEST] <Guest6668> Hello , I would love to help your on ffmpeg , in fact I try to apply a watermark text as follows DrawText = " fontfile = / var / www / test / arial.ttf : text = \" http © \ : \ / \ / www \ .test \ .com \ ' : fontcolor=white(a)1.0 : fontsize = 36: x = ( w- text_w ) / 2 : y = h- th- 10: 1 box = : = black boxcolor @ 0.4 " this one applies well by cons on small size videos (height / width ) réelement the watermark is too big. I want to [00:25:59 CEST] <Guest6668> the watermark text taking into account the size of the video, thank you very much for your help and sorry for my poor english lol [00:26:18 CEST] <zenny> Hi, I have a multiseat setup. I am trying to capture the xserver running in :1 from the xerver running in :0, but reports "Cannot open display :1.0, error 1. :1.0: Input/output error" [00:26:48 CEST] <zenny> Using a command, "$ ffmpeg -report -f x11grab -s 1920x1080 -framerate 5 -i :1 -pix_fmt yuv420p -c:v rawvideo -f v4l2 /dev/video7" [00:30:41 CEST] <zenny> xservers are run with the commands as shown in http://picpaste.com/8S44ALch.png [00:31:38 CEST] <Guest6668> what zenny my ? [02:12:27 CEST] <BasisBit> Zeranoe, is ffmpeg 2.8.1 supposed to have an older version number for libavutil than 2.8.0? [02:29:33 CEST] <BtbN> The libav* version numbers are not related to the main ffmpeg version number. [02:30:29 CEST] <BasisBit> BtbN, I know. was talking about ffmpeg 2.8.1^^ [02:30:42 CEST] <BtbN> hm? [02:31:43 CEST] <BtbN> the libav* version numbers should be the same within the same release. Or what do you mean? [02:35:07 CEST] <BasisBit> I mean, that the libavutil version number in the ffmpeg 2.8.1 package is older then the libavutil version number in 2.8.0 release. nothing else. [02:36:49 CEST] <BtbN> So what exactly are those two version numbers? [03:28:15 CEST] <Prelude_Zzzzz> hey everyone.. good evening.. anyone know what this means ? Failed to open segment of playlist 0 .. keeps going and then shows up and then keeps going and shows up.. not sure what to do about it [04:02:56 CEST] <DHE> playing an HLS stream? or other online streaming service [04:06:50 CEST] <Prelude_Zzzzz> HLS stream [04:07:06 CEST] <Prelude_Zzzzz> funny thing is.. i am playing in VLC and it seems better [04:07:22 CEST] <Prelude_Zzzzz> but soon as i pull with FFMPEG frame rate drops and the errors start [04:17:56 CEST] <Zeranoe> BasisBit: where are you seeing that [04:20:48 CEST] <DHE> is there a way to get the 'qp' value of an encoded h264 video frame? after the fact obviously. an estimate is fine. want to compare different encoders' quality [04:26:05 CEST] <Prelude_Zzzzz> seesm that settings buffer_size=10000k helps [04:26:12 CEST] <Prelude_Zzzzz> or maybe not [08:27:58 CEST] <inflex> trying to adjust some source code to make ffmpeg generate fragmented mp4 files ( ie, moov atom at the start, not end ) but can't seem to get it to do that. Have tried av_opt_set(oc, "movflags", "+empty_moov", 0); and +frag_keyframe but still the same output. Any recommendations? [08:54:24 CEST] <inflex> tried faststart as well, still the same [08:58:08 CEST] <v32itas> hi [09:00:29 CEST] <v32itas> Maybe there is a simple way to do 'gif + ogg' or 'gif + mp3' ? I want to make video clips out of OpenBSD songs http://www.openbsd.org/lyrics.html for open source propoganda there are just a few available on youtube and I'm not ant expert on these things it looks tricky [09:01:30 CEST] <v32itas> audio video codecs ... -_- [10:15:35 CEST] <waressearcher2> is anyone here ? [10:15:53 CEST] <waressearcher2> what are keyframes exist what is their purpose ? [10:18:15 CEST] <xerox> waressearcher2: https://en.wikipedia.org/wiki/Video_compression_picture_types aka I-frames [10:19:21 CEST] <waressearcher2> what [10:19:26 CEST] <waressearcher2> you mean read ? [10:20:13 CEST] <xerox> I mean read [10:21:28 CEST] <inflex> nope nope nope and nope... just can't seem to get this mp4 to be written as fragmented mode :( [10:25:08 CEST] <waressearcher2> inflex: smoking ? [10:25:37 CEST] Action: inflex doesn't smoke. [11:14:09 CEST] <Mavrik> inflex, how about switching to a container that's actually meant for streaming? :) [11:29:33 CEST] <psiklops> Hi Does ffmpeg support https out of the box or must i enable this feature when configuring ? [11:31:59 CEST] <Mavrik> psiklops, yes you need to enable the SSL lib - either gnutls or openssl. [11:33:30 CEST] <psiklops> Mavrik, can i set both options in ./configure --enable-openssl --enable-gnutls ? [11:34:43 CEST] <psiklops> Mavrik, what effects would this have ? [11:34:58 CEST] <psiklops> Mavrik, thanx [11:35:47 CEST] <Mavrik> Uh. [11:36:22 CEST] <Mavrik> Having two libraries doing the same thing will cause you compilation collisions :) [11:40:35 CEST] <psiklops> ok [11:40:39 CEST] <psiklops> :-) [11:40:46 CEST] <psiklops> later [11:44:20 CEST] <inflex> Mavrik: primarily the mp4 is being long-term stored / archival (security footage), it's just that during the writing process for each block it'd be nice to be able to play/view the partial file. Switching to ismv format has resolved the issue partially, though bought about likely a new set of issues. [12:00:01 CEST] <Mavrik> MP4 just isn't a streamable format in such a way :/ [12:00:15 CEST] <Mavrik> MOOV atom cannot be written before the file is complete and the fragmented mode is silly just for storage. [12:00:24 CEST] <Mavrik> (Since it's not widely compatible with all players.) [12:01:51 CEST] <inflex> Any suggestions/recommendations? Right now the stream comes from rtsp h264 sources (ip security cams), stream is simply put in to the mp4 container and saved in (say) 10 minute blocks [12:04:12 CEST] <inflex> Existing commercial suites already do this and provide the ability to watch past events/time from 0 seconds. Only thing I can think of is a temporary file suited for immediate playback (MJPEG?) though it's a bit of a CPU/IO hit. [12:16:21 CEST] <Mavrik> Why not keep files in MPEG2-TS format? [12:16:34 CEST] <Mavrik> It's built for streaming and can be arbitrarily seeked. [12:16:53 CEST] <Mavrik> Other suites implement a full streaming server that fakes MOOV stuff. [12:21:20 CEST] <inflex> Thanks. [12:23:42 CEST] <noob> Hello. I'm on Windows, using zeranoe's ffmpeg bild (ffmpeg-20151017-git-e9299df-win64-static). Here is my question: I'm trying to cut an .mkv file with hevc (h265) codec, I want to keep the second part of it from a given point to the end of it. [12:23:49 CEST] <noob> If I use either "ffmpeg -i a.mkv -acodec copy -vcodec copy -ss 00:00:01.25 1.mkv" or "ffmpeg -i a.mkv -ss 00:00:01.25 -acodec copy -vcodec copy 1.mkv" the resulting video has the correct length, but the video doesn't show at all (it remains black). [12:23:54 CEST] <noob> But if I use "ffmpeg -ss 00:00:01.25 -i a.mkv -acodec copy -vcodec copy 1.mkv" it doesn't make any cut at all, it shows the video, but from the beginning, instead of starting at 1.25 seconds. [12:23:59 CEST] <noob> If I don't chose -vcodec copy then it makes the cut and the video shows, but it uses h264 as default, but I need the video codec and everything to be exactly the same as the source video, since I want to merge it afterwards. Am I doing something wrong? Is there any way to achieve it? Thanks for any help you can provide me. [15:55:51 CEST] <jebeke> hey folks, hoping someone can point me tothe right information. I am trying to set the "Alternate Group ID" when encoding a file and I can find no mention of how to do so in any of the documentation. Is it possible? [16:31:47 CEST] <lenovo> Hey is there a way I can compile the lastest ffmpeg on FreeBSD system ? [16:32:05 CEST] <klaxa> ./configure && make [16:32:09 CEST] <lenovo> it seem that on NeXTBSD system in ports the ffmpeg is broken. [16:32:41 CEST] <lenovo> it breaks at when trying to compile libavutil and stop at error.o [16:32:52 CEST] <klaxa> pastebin your config.log [16:32:56 CEST] <lenovo> sure [16:33:03 CEST] <lenovo> give me a min here [16:36:08 CEST] <lenovo> http://pastebin.com/2b26GEGa [16:38:03 CEST] <lenovo> http://pastebin.com/gCPauR9c [16:38:44 CEST] <klaxa> huh [16:38:46 CEST] <waressearcher2> ./configure && make && make install && make clean [16:38:46 CEST] <klaxa> that's weird [16:40:03 CEST] <lenovo> i think it probably to do with the Mach IPC kernel bits on NeXTBSD, since NeXTBSD is using some Darwin stuff with freebsd-current branch [16:40:23 CEST] <klaxa> ok [16:40:29 CEST] <c_14> Can you upload /usr/include/sys/_lock.h ? [16:40:30 CEST] <klaxa> i'm not familiar with *BSD [16:40:40 CEST] <lenovo> sure [16:40:50 CEST] <c_14> And maybe grep for u_int in /usr/include [16:41:10 CEST] <c_14> preferably a typedef or a define [16:42:06 CEST] <c_14> Is this a regression? [16:42:12 CEST] <c_14> Have you ever compiled ffmpeg on NeXTBSD before? [16:43:55 CEST] <lenovo> http://pastebin.com/Mij0pQfj [16:44:51 CEST] <lenovo> well ffmpeg install ok on the pkg (binary source) but i need other features like x11grab and mp3lame so with the binary source its not preset with it [16:45:46 CEST] <lenovo> so i need to use ports and usually i never had problems with ffmpeg so this will be the first time doing it on NeXTBSD i have done it many times of FreeBSD system and always work good. NeXTBSD is basicly FreeBSD current using the core bits of darwin into the freebsd unstable branch [16:50:37 CEST] <JEEB> well it's a whole different system :P [16:50:47 CEST] <lenovo> not entirely [16:50:57 CEST] <lenovo> it still uses FreeBSD userland [16:51:01 CEST] <JEEB> yes, but in a lot of core system related ways [16:51:33 CEST] <lenovo> Well yes i see where the error stops at the mach part in the error i get when trying to compile ffmpeg [16:52:05 CEST] <lenovo> well you can compile ffmpeg on Darwin right ? [16:52:16 CEST] <JEEB> the OS X flavour, yes [16:52:34 CEST] <JEEB> basically somewhere deep in mach there's an 'u_int' required which is not included :P [16:52:38 CEST] <JEEB> that could be a toolchain issue [16:52:44 CEST] <lenovo> hmm [16:53:42 CEST] <JEEB> I would recommend poking the nextbsd folk or whomever are dealing with the system libraries about this first [16:53:54 CEST] <lenovo> i have mention it [16:54:09 CEST] <lenovo> i'm just trying to get it to work as i ant to use ffmpeg :) [16:54:21 CEST] <lenovo> but thanks i will mention this to them [16:54:26 CEST] <JEEB> pretty hard when it's the system going nope :P [16:56:14 CEST] <JEEB> does that happen when you just clone the FFmpeg repo and do './configure' in it? [16:56:29 CEST] <JEEB> or only with all those over 9000 options that the ports system (?) is poking at it [16:59:03 CEST] <lenovo> its ports [16:59:18 CEST] <lenovo> i havn't got the src code should i try it alone [17:00:36 CEST] <lenovo> i'm getting the ffmpeg git source now [17:02:56 CEST] <lenovo> i don't think freebsd 10x and up can use gcc it is using clang [17:03:08 CEST] <lenovo> could probably cross compile [17:06:23 CEST] <lenovo> ok [17:06:31 CEST] <lenovo> well it failed with a clean source too [17:06:48 CEST] <lenovo> with the same error i'm guessing something is up with mach_time.h and mach_types.h [17:07:13 CEST] <JEEB> and with a simple configure? can you look at how the binary package was configured? [17:07:23 CEST] <JEEB> since you said you had a binary package [17:08:08 CEST] <lenovo> Well yeah it install ffmpeg with a pkg install ffmpeg [17:08:43 CEST] <UNIXn3rd> unless its not designed to be compiled on Oses with Mach Kernels yet [17:10:16 CEST] <JEEB> lenovo: just find out how that was configured :P [17:12:03 CEST] <lenovo> UNIXn3rd: it compiles on Darwin which is using a mach kernel, as to NeXTBSD is a simular model [17:13:02 CEST] <lenovo> it does install using the binary package but with the source base package it won't install something is wrong here :/ i notice a ffmpeg0 in ports too [17:13:05 CEST] <lenovo> hmm [17:13:51 CEST] <DHE> Which is better for comparing video encoder quality? SSIM or PSNR? (using the ffmpeg filters of the same name for testing settings) [17:13:58 CEST] <c_14> ssim [17:14:12 CEST] <JEEB> neither of those is as good as human eyes [17:14:16 CEST] <c_14> Your eyes are usually the best bet though. [17:14:30 CEST] <JEEB> but generally SSIM is a more modern way of checking that doesn't like blur as much [17:14:40 CEST] <lenovo> haha tahts the older ffmpeg version which doesn't work and i don't understand why thats still there :/ [17:14:43 CEST] <DHE> true, but when there's tons of results to go through it's nice to let the computer do the work [17:15:27 CEST] <lenovo> thanks JEEB [17:15:44 CEST] <lenovo> i suppose its up to the maintainer on NeXTBSD to fix this. [17:15:47 CEST] <lenovo> cheers [17:16:53 CEST] <JEEB> DHE: just remember that you are thus not really talking about quality but SSIM in that case. some psychovisual optimizations lower both SSIM and PSNR [17:17:13 CEST] <JEEB> and encoders like x264 have specific tunings for ssim or psnr [17:21:08 CEST] <DHE> I'm comparing quality for speed of encoding mostly... comparing nvenc settings and libx264 settings [17:22:05 CEST] <DHE> nVidia's own presentation slides say nvenc can get better ssim/psnr vs x264. I'm calling test methodology looks flawed. [17:22:55 CEST] <JEEB> well psnr or ssim are not quality [17:23:00 CEST] <JEEB> that's what you check with your eyes [17:23:19 CEST] <JEEB> anyways, just remember to use psnr or ssim optimizing settings with both encoders [17:23:33 CEST] <JEEB> because any sane encoder optimizers for psy-opts by default [17:23:37 CEST] <JEEB> *optimizes [17:23:51 CEST] <JEEB> (including x264, and yes - that lowers both ssim and psnr score) [17:26:15 CEST] <DHE> I was afraid of that... [18:16:50 CEST] <StephenS> c_14, you are very active in here? :D [18:17:25 CEST] <StephenS> btw, to ffmpeg users, how come that the same video, only taken in diff resolution cannot be played on old browsers, and the other one in smaller resolution, can? Its the same codec and all.. [18:18:07 CEST] <StephenS> I can paste ffmpeg -i vid if you want to take a look? [18:19:58 CEST] <c_14> Either because the browser is stupid, or because you oversaw something. [18:22:08 CEST] <StephenS> here is the paste http://pastebin.com/Q926QAnu [18:22:16 CEST] <StephenS> c_14, you can take a look if you wish :D [18:22:36 CEST] <StephenS> thats transcoded video, because of rotation tag, which android adds for portrait orientation, by default. [18:22:42 CEST] <StephenS> both are transcoded btw [18:24:53 CEST] <StephenS> bitrate is also different, alot, but everything else, is the same [18:24:57 CEST] <StephenS> what might be the issue? [18:25:34 CEST] Action: c_14 is going to go with browsers being stupid [18:25:57 CEST] <StephenS> heh :D [18:26:06 CEST] <StephenS> it was tested on firefox btw [18:26:13 CEST] <StephenS> and both of my friends (one male and one female) have FF [18:26:32 CEST] <StephenS> female friend have 27.0.1 of ff [18:26:46 CEST] <StephenS> for a male one, I dont know, but its impossible that its so old version [18:26:59 CEST] <StephenS> I mean, how on earth facebook and youtube have those failovers..? [18:27:07 CEST] <StephenS> Actually its not about fallback either, its something with the video [18:27:16 CEST] <StephenS> how can I make video available on older browsers? [18:28:23 CEST] <c_14> webm/flash/hls probably all 3 [18:29:29 CEST] <StephenS> so what do you suggest? [18:29:46 CEST] <StephenS> because for my friends, video diddnt worked when they accessed direct link, bla.com/vid.mp4 [18:29:52 CEST] <c_14> Don't use web browsers. [18:30:04 CEST] <StephenS> yeah thats what I thought [18:30:07 CEST] <c_14> They are without exception awful. [18:30:10 CEST] <StephenS> but I need 3 different versions of the same video [18:30:13 CEST] <c_14> (As are most things) [18:30:27 CEST] <StephenS> or am I missing something? :D [18:30:40 CEST] <c_14> If you want it to work everywhere, yes. You might even need 4. [18:30:48 CEST] <StephenS> heh [18:30:55 CEST] <StephenS> and for now I only have video in mp4 format eh.. [18:30:56 CEST] <StephenS> :D [18:31:55 CEST] <c_14> webm should get you the newer browsers, hls should get you ios + presumably android, flash will give you cancer, and mp4 for wherever that works and the other stuff doesn't [18:33:12 CEST] <grublet> i've had people unable to play webms on their android phones [18:33:20 CEST] <grublet> is that normal? [18:34:09 CEST] <c_14> probably, everything's broken somewhere [18:34:11 CEST] <c_14> What version? [18:34:12 CEST] <DHE> hls does work on android. the chrome browser will play .m3u8 [18:34:13 CEST] <StephenS> c_14, yeah but how do you explain that the same format (mp4), can be played in ff, and the other one video, also mp4 cannot? [18:34:19 CEST] <StephenS> the diff is in bitrate and resolution, only [18:34:22 CEST] <StephenS> thats so weird [18:37:13 CEST] <grublet> c_14: i woudln't know; they don't know and im new to smartphones [18:37:20 CEST] <grublet> mine plays them and it's 4.4 [18:46:34 CEST] <Zxcvb> is it possible to convert a mp4/h264 video from profile level 4 to profile level 3.2 without transcoding? [18:50:50 CEST] <DHE> no. adhering to a level is a matter of encoding parameters (eg: reference frames, image size, framerate) [18:51:20 CEST] <DHE> you can specify a target level of 4 but if the settings meet the criteria it might already be 3.2 compatible [18:53:25 CEST] <c_14> He's already gone. [18:53:44 CEST] <DHE> 3 minute wait... nice. [18:55:53 CEST] <StephenS> heh :D [18:56:05 CEST] <StephenS> thats why I'm always here :) really helpful answers you guys have ;] [19:02:46 CEST] <DHE> my next line would have been: https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels [19:51:09 CEST] <ahoo> hey [19:51:50 CEST] <ahoo> i have a still image, and an mp3 file (music for youtube). how would i create the smallest possible file? [19:51:59 CEST] <ahoo> i'm currently using -loop 1 for the image and -shortest [19:52:17 CEST] <ahoo> but it's nowhere near the size of jpeg+mp3 [19:52:26 CEST] <ahoo> and it doesn't look like the first frame is actually hold [19:52:36 CEST] <ChocolateArmpits> I think both mp4 and webm should support using image as an album art, so you don't have to actually render a video track out of the image [19:52:39 CEST] <captainkraft> I'm trying to stream to Twitch. When I attempt to stream with music, the sound pops and crackles and I can't figure out how to fix it. This is the script I use to start streaming: http://pastebin.com/0tRazihe [19:54:56 CEST] <c_14> ahoo: lower the framerate, increase the crf [19:55:20 CEST] <ahoo> thx i'll try that [19:58:07 CEST] <c_14> captainkraft: have you tried without -ar [19:58:51 CEST] <captainkraft> I have not [20:01:28 CEST] <captainkraft> c_14, FLV does not support sample rate 48000, choose from (44100, 22050, 11025). Audio codec mp3 not compatible with flv. [20:02:12 CEST] <c_14> put the ar in front of -i pulse [20:02:14 CEST] <JEEB> which audio format are you using? [20:02:17 CEST] <c_14> ah [20:02:19 CEST] <c_14> use aac [20:02:22 CEST] <JEEB> because flv does support 48kHz with AAC [20:02:43 CEST] <JEEB> (or well, it supports pretty much everything with it because it just says "set this to 44.1kHz and actually read the AAC stream for actual details) [20:03:39 CEST] <JEEB> if you are using AAC already, then you just have an old FFmpeg because it was more than a year ago that additional sample rates were enabled for AAC in FLV [20:03:42 CEST] <captainkraft> so '-aac 2' ? [20:04:22 CEST] <JEEB> switch the acodec to any aac encoder :P [20:04:48 CEST] <JEEB> libmp3lame is an mp3 encoder [20:06:24 CEST] <captainkraft> I see. Thanks. Trying that now. [20:06:55 CEST] <JEEB> also wat [20:07:04 CEST] <JEEB> your pastebin says you're setting the audio rate [20:07:36 CEST] <captainkraft> I took this script from somewhere and edited a few values. That was in the script already, so I assumed it was OK [20:08:31 CEST] <JEEB> I'm just going off a leg here, but your pastebin has no b:a set [20:08:41 CEST] <JEEB> did you even check at which audio bit rate you were encoding? :P [20:09:11 CEST] <ahoo> hm [20:09:49 CEST] <captainkraft> I set that earlier but didn't hear any change so I took it back out [20:10:08 CEST] <captainkraft> I know very little about audio, so I'm going by what I can find online. [20:10:27 CEST] <JEEB> the question still remains that did you actually see what the audio bit rate was set to in either case :P [20:10:33 CEST] <ahoo> my mp3+still frame jpeg have a total size of 12 mb. the resulting mp4, even with -crf 1 and -r 1 is somewhere around 18 mb - is that the best i can get? what i would like is a frame hold at frame 0 and a resulting file size of about 13-14 mb [20:10:52 CEST] <captainkraft> JEEB, I don't remember what I set it to before. [20:11:10 CEST] <JEEB> I'm just going to bet that you were setting it too low for mp3 [20:11:22 CEST] <JEEB> and the default probably was something as funky as that [20:11:30 CEST] <captainkraft> Gotcha, so I should use b:a to pick one. What rate should I use? [20:11:56 CEST] <JEEB> whatever rate you require :P with mp3 you definitely don't want to go under 128k [20:13:22 CEST] <captainkraft> If I switch to an aac encoder, what range should I use? I don't know how to tell what rate I require. [20:15:35 CEST] <JEEB> depends on the aac encoder. if you are using an older version then the internal aac encoder is rather bad, but the patches that are improving it have finally lately almost fully gotten in [20:16:00 CEST] <JEEB> with the internal one I usually went for 128-192k if I had to use it [20:16:20 CEST] <JEEB> with the latest improvements you could possibly use it for lower rates as well [20:20:03 CEST] <captainkraft> That's very helpful, thank you. [20:23:52 CEST] <captainkraft> Does a higher bitrate reduce popping noises if you hear them while streaming? [20:24:38 CEST] <captainkraft> I don't hear much difference when I go from 128k to 192k [20:25:13 CEST] <JEEB> depends on if it's created by the encoding or on the quality of the encoder [20:25:30 CEST] <JEEB> I would say that even the internal encoder shouldn't produce audible artifacts like that at 192kbps [20:25:40 CEST] <JEEB> it did in like 2010-11 or so, that was a lot of fun :P [20:26:49 CEST] <JEEB> also if you are live streaming it could be something related to not having enough perf to do the video+audio transcoding together with capture fast enough, although I have no idea if it would lead to that kind of noise :P [20:27:25 CEST] <JEEB> I would probably try to write audio as wav first locally, then add the aac encoder, then add the rest [20:27:32 CEST] <JEEB> and see at which point your artifacts start [20:32:11 CEST] <captainkraft> This creates a wav file with the same artifacts 'ffmpeg -f alsa -i pulse -b:a 128k test.wav' [20:32:28 CEST] <JEEB> uhh [20:32:33 CEST] <JEEB> leave the bit rate out [20:32:36 CEST] <JEEB> doesn't make sense [20:32:42 CEST] <captainkraft> I did that as well, same result. [20:32:46 CEST] <JEEB> ok [20:32:51 CEST] <JEEB> then it's your input, simple as that [20:51:24 CEST] <ahoo> thank you for your help [20:51:28 CEST] <ahoo> and thank you for the music [21:02:58 CEST] <captainkraft> JEEB, I've found out that the audio is clear when I record from digital stereo output. I don't get sound to my speakers, but it records to the wav file nicely. Is there a way to get ffmpeg to record that channel while my speakers output analog stereo? [21:27:10 CEST] <brotherBox> Hey people, I'm having some problem compiling ffmpeg from the git with libx265 support on Ubuntu 14.04. It cant seem to find the libx265.so.75. I have read that it has to do with disabling shared flags, but its not clear to me if i need to set those on libx265 or on ffmpeg. Either way, I cannot get it to run. would someone explain to me how i can successfully compile it? [21:27:52 CEST] <c_14> LD_LIBRARY_PATH=install_prefix/lib ffmpeg [21:30:46 CEST] <brotherBox> c_14: that does it, wonderful! Is there a way to remove the environment variable and run it just with ffmpeg or is that required for now? [21:31:21 CEST] <c_14> recompile with LD_RUN_PATH set, or with static libraries for x264. [21:31:47 CEST] <brotherBox> *x265 [21:32:19 CEST] <c_14> eh, that [21:32:25 CEST] <c_14> same difference [21:33:35 CEST] <JEEB> you can in theory add the dir of your custom prefix into a config file under /etc/ld.so.conf.d/ and then run ldconfig as root every time you remove or add a shared library from there [21:33:48 CEST] <JEEB> or you just have that env variable set by default :P [21:34:32 CEST] <brotherBox> I'll try to compile x265 statically, but all that cmake stuff doesnt make it easy to me, i find it convoluted [21:35:44 CEST] <brotherBox> if that doesnt work I'll aslias it in the shell and leave it be [21:35:47 CEST] <brotherBox> *alias [22:07:37 CEST] <StephenS> c_14, so .webm .mp4 and .ogv ? That would be enough for browsers? And also I have fallback to flash, if all three fail... and whats hls? [22:09:21 CEST] <c_14> Don't know of any browsers supporting ogv. [22:09:23 CEST] <c_14> https://en.wikipedia.org/wiki/HTTP_Live_Streaming [22:09:45 CEST] <c_14> ffmpeg has hls output, just need to offer it via a http server [22:11:44 CEST] <furq> firefox, opera and chrome support theora [22:11:56 CEST] <furq> all the major browsers support h264 in mp4 now though [22:12:10 CEST] <StephenS> yeah but older ones, I have issue with them :D [22:12:34 CEST] <TD-Linux> what exact browser versions do you need? [22:12:51 CEST] <StephenS> well to cover all major ones and older ones, till 10+ release [22:12:51 CEST] <TD-Linux> don't use HLS unless you need it for other reasons [22:13:07 CEST] <TD-Linux> I suggest using caniuse.com [22:13:08 CEST] <StephenS> I dont need HLS in fact [22:13:12 CEST] <furq> http://caniuse.com/#feat=mpeg4 [22:13:54 CEST] <TD-Linux> for 10 versions back you don't need theora, you can use webm vp9 [22:14:12 CEST] <TD-Linux> which covers the same set that support theora, but is newer and shinier [22:15:01 CEST] <TD-Linux> but if you can do all three you'll get support for everything back to the earliest fx [22:15:04 CEST] <furq> firefox has supported mp4 since 21 on windows and 26 on linux [22:15:30 CEST] <TD-Linux> firefox mp4 support depends on the OS though, so on linux it only works if you have ffmpeg locally [22:15:44 CEST] <furq> Firefox supports H.264 on Linux since version 26 if the appropriate gstreamer plug-ins are installed. [22:15:48 CEST] <TD-Linux> (or on non-nightly, gstreamer-plugins-ffmpeg [22:15:50 CEST] <TD-Linux> ) [22:16:14 CEST] <TD-Linux> but regardless, do mp4 and a free format to be safe (ogv, webm vp8 or vp9) [22:16:23 CEST] <StephenS> well my friend had a problem playing video on FF 27.0.1 [22:16:26 CEST] <StephenS> and format is mp4 [22:16:35 CEST] <furq> why is he using firefox 27 [22:16:36 CEST] <StephenS> however, the same format mp4, in lower resolution, it played fine [22:16:42 CEST] <TD-Linux> yeah not surprising, it took a while to get the OS support working well for mp4 [22:16:54 CEST] <TD-Linux> also it won't work on windows xp [22:16:56 CEST] <StephenS> furq, it's a "she" and I have no idea [22:17:17 CEST] <StephenS> but I need a way to fix this for older browsers [22:17:37 CEST] <StephenS> I could play'd her str8 from flash, but then I need to cut off html5 video, which I dont want to [22:17:50 CEST] <TD-Linux> StephenS, yeah, don't use flash, webm or ogv will fix it for you [22:18:15 CEST] <StephenS> I thought about dropping mp4, and using only .webm [22:18:20 CEST] <StephenS> webm is more supported I guess? [22:18:59 CEST] <StephenS> also here is info about two videos http://pastebin.com/Q926QAnu [22:19:02 CEST] <furq> it's not supported in IE or safari [22:19:16 CEST] <StephenS> first one doesnt work on ff 27.0.1 and second one works fine, because bitrate is lower and its in lower resolution [22:19:19 CEST] <StephenS> which is really weird [22:19:30 CEST] <furq> and weirdly it apparently only has partial support in android browser [22:19:33 CEST] <furq> nice work google [22:19:38 CEST] <StephenS> lol [22:19:53 CEST] <StephenS> so if I have 3 formats, how would I show my users, which format? [22:20:03 CEST] <StephenS> I cant render each browser and check does it supports it [22:20:23 CEST] <TD-Linux> StephenS, use 3 sources in your <video> tag, the browser will pick which one it supports [22:20:32 CEST] <StephenS> actually I can do <video><source src="bla.mp4"></source><source src="newone.web"></source></video> [22:20:34 CEST] <StephenS> webm* [22:20:47 CEST] <furq> i was going to suggest just using mp4 and having a flash fallback player [22:20:54 CEST] <StephenS> furq, thats what I have [22:20:56 CEST] <furq> but multiple sources might be simpler [22:20:56 CEST] <TD-Linux> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/video [22:21:09 CEST] <StephenS> furq, no no, I have 2 sources and flash fallback :) [22:21:16 CEST] <StephenS> Ill support mp4 and webm [22:21:18 CEST] <TD-Linux> you just use multiple <source> tags inside the <video> element [22:21:22 CEST] <furq> yeah i wouldn't bother with theora [22:21:29 CEST] <StephenS> because whoever supports ogv/hls, must support webm [22:21:48 CEST] <TD-Linux> hls is something different that only safari supports, don't get confused [22:23:07 CEST] <furq> apparently chrome and edge support hls now [22:23:23 CEST] <furq> oh nvm it's only mobile chrome [22:23:49 CEST] <StephenS> ok, so I can forget about hls, ogg and ogv, right? [22:23:55 CEST] <TD-Linux> yeah [22:24:06 CEST] <StephenS> I can support mp4 and webm only and should work on most of the browsers? With flash fallback ofc. [22:24:21 CEST] <furq> hls is a streaming protocol [22:24:24 CEST] <TD-Linux> yes [22:24:30 CEST] <furq> you don't need anything like that if you're just serving up videos [22:24:31 CEST] <TD-Linux> you shouldn't even need the flash fallback then [22:25:31 CEST] <furq> those two will support pretty much everything except IE8 and prior [22:26:34 CEST] <furq> and i can't imagine anyone still using IE8 is surprised when things don't work [22:26:37 CEST] <StephenS> what IE needs? [22:26:41 CEST] <furq> flash [22:26:48 CEST] <StephenS> well I have fallback for that [22:26:51 CEST] <StephenS> so even IE should work :) [22:27:08 CEST] <furq> 9+ supports mp4 natively [22:28:45 CEST] <StephenS> cool [22:32:15 CEST] <StephenS> how to convert types with ffmpeg? [22:32:39 CEST] <StephenS> ffmpeg -i m.mp4 out.webm wont convert it, I guess [22:33:57 CEST] <furq> it'll guess appropriate codecs from the output file extension [22:34:13 CEST] <StephenS> with current configuration http://pastebin.com/Q926QAnu Im not able to convert video to webm? [22:34:14 CEST] <furq> you'll need to provide encoder settings though [22:34:24 CEST] <StephenS> I need a52 enabled from my understanding [22:35:03 CEST] <furq> i think you just need libvpx and libvorbis [22:35:29 CEST] <StephenS> that, I have :) [22:37:29 CEST] <StephenS> furq, hmm, when converted that way, quality is really bad [22:40:28 CEST] <furq> apparently it defaults to 256kbps video [22:40:57 CEST] <furq> https://trac.ffmpeg.org/wiki/Encode/VP9#constantq [22:41:42 CEST] <StephenS> well I tried ffmpeg -i in.mp4 -qscale 0 outx.webm [22:41:49 CEST] <StephenS> but that gives me the same bad quality [22:41:53 CEST] <furq> try -b:v 0 -crf 10 [22:42:13 CEST] <furq> you probably want to set -q:a as well [22:42:42 CEST] <relaxed> StephenS: https://trac.ffmpeg.org/wiki/Encode/VP9 [22:43:02 CEST] <StephenS> ffmpeg -i in.mp4 -c:v libvpx-vp9 -crf 10 -b:v 0 -c:a libvorbis out.webm [22:43:04 CEST] <StephenS> is very slow [22:43:12 CEST] <furq> it sure is [22:44:52 CEST] <StephenS> and its twice in size [22:45:04 CEST] <StephenS> original mp4 is 1.8MB and new webm is 3.3MB [22:45:04 CEST] <StephenS> :O [22:45:12 CEST] <furq> try -crf 20 [22:46:13 CEST] <nerium> Is there a way to transcode a stream? [22:46:39 CEST] <DHE> specify a codec besides 'copy' [22:46:51 CEST] <StephenS> furq, still slow [22:47:00 CEST] <nerium> The input would be a stream (m3u) and output an mp4 stream [22:47:33 CEST] <furq> StephenS: iirc you need to explicitly pass -threads with libvpx [22:48:03 CEST] <furq> it is generally really slow compared to x264 though [22:48:30 CEST] <furq> maybe use vp8 if this is just for a fallback [22:49:35 CEST] <StephenS> how? [22:49:36 CEST] <nerium> Anyone know what to search for? [22:50:09 CEST] <voice> what are you trying to use libvpx for? [22:51:18 CEST] <furq> StephenS: -c:a vp8 [22:51:33 CEST] <relaxed> -c:v [22:51:37 CEST] <furq> er, yeah [22:51:48 CEST] <StephenS> Invalid encoder type 'vp8' [22:51:50 CEST] <StephenS> eh [22:51:58 CEST] <furq> try -c:v libvpx [22:51:59 CEST] <voice> vp8 - libvpx [22:52:06 CEST] <voice> vp9 - libvpx-vp9 [22:52:33 CEST] <StephenS> Invalid encoder type 'libvpx' [22:52:49 CEST] <voice> you don't have libvpx or your ffmpeg wasn't compiled with vpx support [22:53:11 CEST] <furq> you are using -c:v and not -c:a right [22:53:11 CEST] <StephenS> it was.. [22:53:17 CEST] <StephenS> look at this http://pastebin.com/Q926QAnu [22:53:20 CEST] <furq> and yeah he was just encoding vp9 [22:53:28 CEST] <StephenS> --enable-libvorbis --enable-libv4l2 --enable-libvpx [22:53:46 CEST] <voice> ffmpeg -codecs | grep vp9 [22:55:14 CEST] <StephenS> DEV.L. vp9 Google VP9 (decoders: vp9 libvpx-vp9 ) (encoders: libvpx-vp9 ) [22:55:35 CEST] <voice> -c:v libvpx-vp9 didn't work? [22:55:41 CEST] <StephenS> but why would I want vp8 anyway [22:55:44 CEST] <StephenS> vp8 is older [22:56:02 CEST] <StephenS> -c:v libvpx-vp9 works [22:56:06 CEST] <voice> because some media players like VLC don't support VP9 unless you build from source [22:56:33 CEST] <voice> anyways, heres a VP9 encoding set I typically use, -c:v libvpx-vp9 -qmin 30 -qmax 35 -crf 35 -threads 8 -speed 1 -tile-columns 6 -frame-parallel 1 -auto-alt-ref 1 -lag-in-frames 25 -c:a libopus -b:a 96 [22:56:56 CEST] <furq> also because it encodes faster [22:58:03 CEST] <voice> -b:a 96k* [22:58:32 CEST] <furq> you'll want -b:a vorbis if this is for the web [22:58:54 CEST] <StephenS> so ffmpeg -i in.mp4 -c:v libvpx-vp9 -qmin 30 -qmax 35 -crf 35 -threads 8 -speed 1 -tile-columns 6 -frame-parallel 1 -auto-alt-ref 1 -lag-in-frames 25 -c:a libopus -b:a 96 o.webm [22:58:57 CEST] <StephenS> should be faster? [22:59:01 CEST] <voice> Chromium and Firefox support WebM w/ VP9 and Opus [22:59:01 CEST] <furq> -c:a vorbis i mean ;_; [22:59:10 CEST] <furq> it's for old browser compatibility [22:59:13 CEST] <StephenS> ok [22:59:19 CEST] <StephenS> ffmpeg -i in.mp4 -c:v libvpx-vp9 -qmin 30 -qmax 35 -crf 35 -threads 8 -speed 1 -tile-columns 6 -frame-parallel 1 -auto-alt-ref 1 -lag-in-frames 25 -c:a vorbis -b:a 96 o.webm [22:59:35 CEST] <relaxed> 96k [22:59:41 CEST] <voice> StephenS, adjust -threads to be the number of CPU cores you have, also -b:a 96k [22:59:45 CEST] <furq> use -threads 4 unless you have an i7 [22:59:51 CEST] <StephenS> [vorbis @ 0x11533a0] The encoder 'vorbis' is experimental but experimental codecs are not enabled, add '-strict -2' if you want to use it. [22:59:52 CEST] <StephenS> [vorbis @ 0x11533a0] Alternatively use the non experimental encoder 'libvorbis'. [22:59:55 CEST] <furq> or one of those silly amd cpus [23:00:08 CEST] <voice> use libvorbis [23:00:54 CEST] <StephenS> model name : Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz [23:01:07 CEST] <StephenS> cpu cores : 1 [23:01:08 CEST] <StephenS> xd [23:01:16 CEST] <voice> vps? [23:01:26 CEST] <StephenS> yeah [23:01:31 CEST] <StephenS> cloud though :D [23:01:34 CEST] <StephenS> but VPS yap [23:01:48 CEST] <voice> it'll just take longer to make [23:02:08 CEST] <StephenS> so this is final one [23:02:09 CEST] <StephenS> ffmpeg -i in.mp4 -c:v libvpx-vp9 -qmin 30 -qmax 35 -crf 35 -threads 8 -speed 1 -tile-columns 6 -frame-parallel 1 -auto-alt-ref 1 -lag-in-frames 25 -c:a libvorbis -b:a 96k o.webm [23:02:12 CEST] <furq> libvpx's multithreading isn't very good in my experience [23:02:27 CEST] <voice> -threads 1 [23:02:47 CEST] <furq> -tile-columns and -frame-parallel aren't needed without multithreading are they [23:03:00 CEST] <voice> not really sure [23:03:50 CEST] <furq> my experience with libvpx is spending ten minutes failing to get it to run faster than 5fps and then going back to x264 [23:08:06 CEST] <StephenS> ok [23:08:07 CEST] <StephenS> ffmpeg -i in.mp4 -c:v libvpx-vp9 -qmin 30 -qmax 35 -crf 35 -threads 1 -speed 1 -tile-columns 6 -frame-parallel 1 -auto-alt-ref 1 -lag-in-frames 25 -c:a libvorbis -b:a 96k outnew.webm [23:08:16 CEST] <StephenS> worked and I got even lower in size o.webm [23:08:26 CEST] <StephenS> however its still slow.. maybe when I switch to dedi with more cores, it will get faster [23:09:15 CEST] <furq> fwiw i get 10fps encoding a 480p clip on an i7 [23:09:20 CEST] <furq> vp9 is just slow [23:09:37 CEST] <relaxed> x264 spoiled us [23:09:46 CEST] <furq> good old x264 [23:10:07 CEST] <StephenS> can I do something with x264 :D [23:10:27 CEST] <furq> yes, you can encode an mp4 and leave all the outdated browser users hanging [23:10:53 CEST] <furq> that sounded negative but that is totally what i'd do [23:11:29 CEST] <StephenS> heh :D [23:17:50 CEST] <StephenS> thanks for help, im off to sleep ;] [23:27:39 CEST] <nerium> Is there a way to set the output stream to tcp instead of udp? [23:28:03 CEST] <nerium> I currently have this in the end udp://127.0.0.1:10000, but I want tcp [23:29:56 CEST] <relaxed> nerium: yes, ffmpeg -protocols [23:30:22 CEST] <relaxed> man ffmpeg-protocols [23:31:25 CEST] <nerium> relaxed: Im justing getting Connection to tcp://127.0.0.1:60001 failed: Connection refused when trying http and tcp instead of udp [23:32:33 CEST] <relaxed> you probably need ?listen on the end [23:32:37 CEST] <nerium> relaxed: Do I need to set up a server of tcp, but not udp? [23:33:19 CEST] <nerium> relaxed: Nope, same thing :/ [23:35:17 CEST] <TD-Linux> StephenS, you can also do a vp8 webm which is way faster but larger filesize for same quality [23:35:37 CEST] <StephenS> but I dont have vp8 [23:35:46 CEST] <TD-Linux> -c:v libvpx is vp8 [23:36:07 CEST] <TD-Linux> I can pretty much guarantee you that you have vp8 :) [23:38:40 CEST] <StephenS> wow, this is actually faster and Q is pretty decent [23:38:44 CEST] <StephenS> and file size is not that big either [23:38:51 CEST] <StephenS> its even smaller than the original one [23:40:22 CEST] <nerium> relaxed: Any idea? [23:42:11 CEST] <relaxed> nerium: this works for me, ffmpeg -i input.mp4 -c copy -f flv 'tcp://127.0.0.1:60001?listen' [23:42:43 CEST] <nerium> relaxed: What version of ffmpeg are u using? [23:43:27 CEST] <StephenS> how hard is to add existing "transparent" fire ball on existing video? [23:44:40 CEST] <relaxed> StephenS: someone should write a dhalsim filter [23:45:02 CEST] <furq> StephenS: https://ffmpeg.org/ffmpeg-filters.html#overlay-1 [23:45:36 CEST] Action: relaxed yoga fire [23:46:17 CEST] <StephenS> :O [23:46:20 CEST] Action: StephenS do the happy dance [23:46:31 CEST] <relaxed> nerium: recent git master, but it should work with any version [23:53:09 CEST] <RedH8> Sweeeet an ffmpeg room!!! Total roll of the dice and it comes up big! [23:53:30 CEST] <RedH8> <3 fellow transcoders. [23:53:30 CEST] <TD-Linux> StephenS, cool, glad it worked. vp9 has a lot of potential but the encoder is still pretty slow. libvpx 1.5.0 will give it about 20% more but it's still not a super good choice for the impatient :) [23:56:01 CEST] <voice> who knows how much longer Google will be focusing on VP9, it looks like VP10 is already showing up in the repos [00:00:00 CEST] --- Sun Oct 18 2015

1 0

ffmpeg-devel.log.20151016
by burek 17 Oct '15

17 Oct '15

[00:00:04 CEST] <nevcairiel> that website doesnt work [00:00:23 CEST] <Justin`> Medium CVE-2015-6761: Memory corruption in FFMpeg [00:00:38 CEST] <nevcairiel> that thing seems to be filled against chromium [00:00:46 CEST] <Timothy__Gu> see https://code.google.com/p/chromium/issues/detail?id=447860 [00:00:48 CEST] <nevcairiel> if we dont get reports, we dont fix shit [00:00:57 CEST] <Timothy__Gu> "global-buffer-overflow at vp56_rac_get_prob_branchy" [00:01:28 CEST] <Justin`> nevcairiel, it's a FFmpeg CVE [00:01:32 CEST] <Justin`> Chromium just happen to use ffmpeg [00:01:51 CEST] <nevcairiel> if chromium gets a report and we dont get it forwarded, we dont fix shit :P [00:02:05 CEST] <Justin`> That attitude is amazing! [00:02:08 CEST] <nevcairiel> reading the chromium issue, it doesnt seem to be an actual issue though [00:02:19 CEST] <nevcairiel> Justin`: you tell me how we're supposed to fix issues noone tells us about [00:02:30 CEST] <Justin`> You could be checking your own software for CVEs? [00:02:38 CEST] <Timothy__Gu> how? [00:02:48 CEST] <Timothy__Gu> mitre never informs us [00:03:08 CEST] <Justin`> Maybe you could open a dialog with them and get reports forwarded? [00:03:34 CEST] <nevcairiel> Like I said, this issue was filed against chromium, it would've been up to them to forward it [00:03:37 CEST] <Timothy__Gu> so basically it's our responsibility to google "ffmpeg vulnerability" 24-7 [00:03:41 CEST] <nevcairiel> but, chromium found it to be a non-issue [00:04:00 CEST] <Justin`> Timothy__Gu, no. [00:04:03 CEST] <nevcairiel> apparently asan triggers some mis-compilation [00:04:35 CEST] <nevcairiel> so in short, there never was a problem [00:04:47 CEST] <nevcairiel> unless you consider an asan build being broken a problem [00:05:17 CEST] <Justin`> I'm not sure what an asan is. I just came here to see if you guys had patched ffmpeg to negate the CVE flag. [00:06:06 CEST] <nevcairiel> asan is a development tool that instruments the binary with extra analysis tools [00:06:12 CEST] <nevcairiel> in this case, it appears to actually cause bugs [00:06:32 CEST] <nevcairiel> if the chromium ticket can be believed, normal builds dont exhibit any problems [00:06:35 CEST] <nevcairiel> hence, no security issue [00:06:41 CEST] <Justin`> Of chromium. [00:06:47 CEST] <Justin`> What about builds of other software that uses ffmpeg? [00:06:58 CEST] <nevcairiel> how would we know, we didnt get told [00:07:06 CEST] <Justin`> I didn't say you should know. [00:07:16 CEST] <Justin`> I'm asking if you guys knew and if a patch had been created. [00:07:17 CEST] <jamrial> Justin`: that nist link says cve not found [00:07:28 CEST] <nevcairiel> says server error for me [00:07:38 CEST] <nevcairiel> after like 5 minutes of loading [00:07:52 CEST] <Justin`> jamrial, here https://security-tracker.debian.org/tracker/CVE-2015-6761 [00:08:12 CEST] <jamrial> on mitre https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-6761 it says "reserved" [00:10:01 CEST] <Justin`> https://cve.circl.lu/cve/CVE-2015-6761 [00:10:04 CEST] <Justin`> https://access.redhat.com/security/cve/CVE-2015-6761 [00:10:12 CEST] <Justin`> A few more links for more info. [00:10:52 CEST] <kierank> none of them explain how to reproduce the bug [00:10:55 CEST] <kierank> or have a sample or have anything [00:11:29 CEST] <jamrial> the circl.lu link at least has a description [00:11:33 CEST] <Justin`> kierank, I am not sure how else to help. [00:11:50 CEST] <Justin`> I am just trying to help out by bringing the CVE to your attention. [00:12:04 CEST] <nevcairiel> the latest link even has a link to something that presumably is a fix, although it says its not reproducable in ffmpeg [00:12:04 CEST] <kierank> https://git.videolan.org/?p=ffmpeg.git;a=commit;h=dabea74d0e82ea80cd344f630… [00:14:21 CEST] <jamrial> that was backported for 2.8.2 [00:15:06 CEST] <Justin`> jamrial, is it possible to release a bugfix release like 2.8.1.1? [00:15:19 CEST] <iive> Justin`: it is bug in the clang-asan compiler [00:15:34 CEST] <jamrial> 2.8.1 is a bugfix release for 2.8 [00:15:41 CEST] <jamrial> the next one will be 2.8.2 [00:15:43 CEST] <Justin`> ok [00:15:51 CEST] <Justin`> any eta on it? [00:15:55 CEST] <nevcairiel> Justin`: its not a bug that affects any release builds [00:15:59 CEST] <nevcairiel> so no hurry [00:16:15 CEST] <Justin`> hmm ok, so is it based on how other apps implement ffmpeg? [00:17:26 CEST] <jamrial> Justin`: usually a few weeks or a month after the previous point release, depending on how many fixes pile up [00:17:35 CEST] <Justin`> k [00:25:11 CEST] Action: durandal_170 added RSD6WADP support [00:27:51 CEST] <durandal_170> kierank: shouldn't you fuzz with crc disabled? [00:28:23 CEST] <kierank> probably but I just wanted to decode as a normal user would with a random file [00:29:40 CEST] <jamrial> i thought crc was disabled by default [03:36:44 CEST] <cone-635> ffmpeg 03Michael Niedermayer 07master:d6f6e98eb158: avutil/crc: use EINVAL instead of -1 for the return code of av_crc_init() [04:28:27 CEST] <cone-635> ffmpeg 03Ganesh Ajjanagadde 07master:ef62f573ca5e: swresample/swresample_internal: add av_warn_unused_result [04:33:44 CEST] <cone-635> ffmpeg 03Ganesh Ajjanagadde 07master:0418541d5d3f: avutil/cast5: update Doxygen for av_cast5_init with return information [08:22:20 CEST] <ubitux> Timothy_Gu: fate.ffmpeg.org menu doesn't match ffmpeg.org one [08:26:32 CEST] <Timothy_Gu> ubitux: fixed. thx for spotting [08:28:07 CEST] <ubitux> Timothy_Gu: also https:// etc [08:28:45 CEST] <ubitux> mmh but yeah i guess it's a different site [08:28:48 CEST] <ubitux> anyway, thx [09:48:44 CEST] <wm4> so is there really a point in Ganesh adding av_warn_unused_result to fucking everything [09:49:06 CEST] <nevcairiel> no, but we've always needed a K&R-style person [09:50:34 CEST] <TimNich> Everyone loves a style guru ;) [11:18:04 CEST] <mateo`> hey i've bumped my original thread regarding an avfoundation patch (https://ffmpeg.org/pipermail/ffmpeg-devel/2015-August/177845.html) from an email not registered on the ml, would be possible to get it moderated so it can reach the ml a bit faster ? [11:27:25 CEST] <BtbN> mateo`, you could just subscribe, way faster than asking around for someone to approve it. [11:34:12 CEST] <mateo`> BtbN: done, i've subscribed with my other email address [13:56:17 CEST] <cone-569> ffmpeg 03Ganesh Ajjanagadde 07master:5e80a6cd315d: avdevice/alsa: add av_warn_unused_result [14:11:28 CEST] <durandal_1707> gonna push psx patchset [14:14:02 CEST] <cone-569> ffmpeg 03Christophe Gisquet 07master:42c1dcde683f: fate: use PROGSSUF [14:55:46 CEST] <cone-569> ffmpeg 03Hendrik Leppkes 07master:e12908d71e7a: vp9: use AVFrame.buf[0] to check if a frame is valid [14:55:47 CEST] <cone-569> ffmpeg 03Hendrik Leppkes 07master:97be5d4d2007: w32pthreads: fix mingw build on x86 with -msse2 or higher [14:58:52 CEST] <cone-569> ffmpeg 03Michael Niedermayer 07release/2.8:e3fcd88f08f4: avcodec/jpeg2000dec: Clear properties in jpeg2000_dec_cleanup() too [14:58:53 CEST] <cone-569> ffmpeg 03hSÇ 07release/2.8:1a67b0f9ae6c: avcodec: loongson optimize h264dsp idct and loop filter with mmi [15:26:15 CEST] <BtbN> That OpenCL maintainer dude is realy bad with response-quoting in mails. [15:26:57 CEST] <BtbN> And some other people have a weird unreadable IN> ... quoting style [15:27:04 CEST] <nevcairiel> you should try reading those mails from the quicksync guy [15:27:11 CEST] <nevcairiel> i can barely figure out where his responses start [15:27:18 CEST] <nevcairiel> yeah that him [15:27:20 CEST] <nevcairiel> *thats [15:27:42 CEST] <BtbN> In the latest OpenCL mail the response is hidden in the git version number, which is printed in light gray with a very small font for me. [15:27:48 CEST] <nevcairiel> hehe [15:27:54 CEST] <ubitux> can't read those either [15:28:09 CEST] <ubitux> i just hope he will never talk to me [15:28:31 CEST] <BtbN> At least he does respond now [15:28:40 CEST] <BtbN> A few more days and i'd have just pushed [15:30:52 CEST] <BtbN> It's also realy annoying that we _have_ to top-post at work... [15:31:05 CEST] <J_Darnley> What? [15:31:14 CEST] <J_Darnley> How can anyone possibly like that? [15:31:28 CEST] <BtbN> It's to hard for people to scroll down to read the response, too many missed the response and got confused. So top-responding got a policy. [15:31:38 CEST] <nevcairiel> I used to do it at work too because the other guys would just get confused and not find my answers [15:31:44 CEST] Action: J_Darnley rants privately [15:32:01 CEST] <BtbN> Top-Responding is fine in a normal conversation imo [15:32:16 CEST] <BtbN> but making it a policy and shouting at people when they don't... [15:33:14 CEST] <BtbN> It's also encouraged to keep the entire history, so bottom posting would mean you have to skip several thousand lines at some point. [15:33:15 CEST] <J_Darnley> Perhaps in a conversation between exactly 2 people it might be fine. Each one of you has read all of the thread. [15:33:44 CEST] <J_Darnley> And that just makes it worse. [15:33:48 CEST] Action: J_Darnley runs [16:10:19 CEST] <Timothy_Gu> ubitux: you mean https://fate.f.o? i dont have the AES keys etc. so you have ask michaelni or baptiste for that [16:10:44 CEST] <cone-569> ffmpeg 03Michael Niedermayer 07master:377883c4be7a: avfilter/avfilter: Error out if audio parameters change instead of failing an assert [16:10:49 CEST] <ubitux> Timothy_Gu: yeah no sorry, forget about it [16:38:11 CEST] <cone-569> ffmpeg 03Paul B Mahol 07master:8b11e4379926: avcodec: add ADPCM PSX decoder [16:38:12 CEST] <cone-569> ffmpeg 03Paul B Mahol 07master:af70117c38b6: avformat: add genh demuxer [16:38:13 CEST] <cone-569> ffmpeg 03Paul B Mahol 07master:c0aeee944342: avformat: add vag demuxer [16:38:14 CEST] <cone-569> ffmpeg 03Paul B Mahol 07master:3919089beb50: avformat: add ads demuxer [16:38:15 CEST] <cone-569> ffmpeg 03Paul B Mahol 07master:3a6389015417: avformat/rsd: add WADP support [16:38:16 CEST] <cone-569> ffmpeg 03Paul B Mahol 07master:8e7571eacda5: avformat: add svag demuxer [18:37:50 CEST] <cone-569> ffmpeg 03Agatha Hu 07master:2b5dda3f4861: avcodec/nvenc: fix b frame n_quant_offset [19:24:14 CEST] <durandal_1707> michaelni_: have you looked at ffv1 bugs? [19:27:54 CEST] <michaelni_> durandal_1707, which ffv1 bugs ? [19:28:43 CEST] <durandal_1707> michaelni_: on tracker [19:28:54 CEST] <kierank> I have many more :) [19:29:01 CEST] <kierank> but three is enough for now [19:29:55 CEST] <durandal_1707> something about corruption [19:32:13 CEST] <michaelni_> i see just one feature request with keyword=ffv1 [19:32:36 CEST] <michaelni_> no bugs have keyword=ffv1 [19:33:35 CEST] <kierank> https://trac.ffmpeg.org/ticket/4931 [19:33:36 CEST] <kierank> https://trac.ffmpeg.org/ticket/4932 [19:33:37 CEST] <kierank> https://trac.ffmpeg.org/ticket/4933 [19:33:40 CEST] <kierank> those are the bugs [20:40:23 CEST] <durandal_1707> michaelni_: added keywords to ffv1 bugs [21:13:50 CEST] <cone-569> ffmpeg 03James Almer 07master:8297f560cca2: avformat/rsd: propagate return values of extradata helper functions [21:17:13 CEST] <cone-569> ffmpeg 03Michael Niedermayer 07master:4c2d4e8700cd: avcodec/ffv1dec: Clear slice coordinates if they are invalid or slice header decoding fails for other reasons [21:43:14 CEST] <ubitux> what's the general opinion about "edge emu"? that is, what is generally prefered between border checks in the loop vs memcopying the frame into a larger padded area to skip checks? [21:44:01 CEST] <ubitux> having the edge emu looks simpler for the processing function, but i'm wondering if it's worth the trouble given that i'm unsure about the performance impact of doing so [21:45:45 CEST] <ubitux> context: filters [21:54:18 CEST] <kurosu> edge emu is useful for codecs where it's actually unusual to go in those areas [21:54:44 CEST] <kurosu> for filters, it happens every time, so it's less suited [21:55:07 CEST] <kurosu> on the other hand, you can partially unroll loops to have special case for those borders, too [21:56:24 CEST] <ubitux> yeah indeed [21:56:31 CEST] <kurosu> ubitux, besides that, it can be a source of bugs for encoders - see dnxhd which was accessing blocks of 16x16, ie reading 1088 lines out of 1080 [21:56:59 CEST] <kurosu> for those, one can wonder whether always padding to 1088 or let it do the best job out of those 8 lines is useful [21:58:10 CEST] <ubitux> unrolling sounds fair; i'm unsure where to unroll the left/right borders though [21:58:21 CEST] <kurosu> in dnxhd case, edge emu is actually worse but for different reasons [21:58:22 CEST] <ubitux> that is, inside the line processing, or after processing the whole frame [21:59:06 CEST] <kurosu> I'm not very well versed with filters, but in some cases you can do filtering in place [21:59:37 CEST] <kurosu> but what do you do with slice processing then? you could consider this is not an edge, except another thread could have modified those pixels already [21:59:42 CEST] <ubitux> if you need borders cases, you most likely need a squared surrounding area [21:59:46 CEST] <ubitux> so not inplace [22:00:14 CEST] <ubitux> consider in and out distinct [22:00:16 CEST] <kurosu> except if you special case borders, eg convolution filters or equivalent [22:00:27 CEST] <kurosu> nevemind [22:00:53 CEST] <kurosu> *nevermind, later lines would access filtered lines, which is not intended [22:02:03 CEST] <kurosu> looks like a filter property anyway [22:02:14 CEST] <kurosu> it's up to the filter to decide what's best for it [22:03:44 CEST] <ubitux> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavfilter/vf_edgedetect.c;… [22:03:49 CEST] <ubitux> this is a typical example [22:04:07 CEST] <ubitux> where the 2 lines on top and bottom are outrolled [22:04:13 CEST] <ubitux> and column are handled inside the loop [22:04:38 CEST] <ubitux> in this simple case, it looks fine to handle the special left/right inside the loop [22:04:52 CEST] <ubitux> but sometimes i wonder if it would make sense to handle the whole column at once to simplify the inner loop [22:05:02 CEST] <ubitux> but i'm afraid of cache locality issues [22:07:26 CEST] <kurosu> left and right borders make it unclean simd-wise: basically, you probably need to copy those 2 pixels left and right after processing the line [22:08:14 CEST] <kurosu> in that case, I'd think it's always better than memcpying a whole image to avoid edge cases [22:09:54 CEST] <ubitux> yeah that's what i was thinking too [22:09:56 CEST] <ubitux> ok [22:09:58 CEST] <ubitux> thanks [22:10:01 CEST] <kurosu> on the other hand, for that case where the 2 pixels left and right are actually not processed, they could look weird depending on the filter effect [22:10:23 CEST] <ubitux> yeah, borders are kinda shity with that filter [22:10:32 CEST] <ubitux> but it could be any special case processing [22:11:40 CEST] <kurosu> really, it looks like a filter property: if you don't want or can't handle edge case efficiently, request padding, on the other hand, it somewhat free when other filters in the chain are not in-place [22:11:53 CEST] <durandal_1707> have you saw what vf_neighbor does? [22:12:21 CEST] <kurosu> you pass an image with larger stride, and invoke padding after the output image has been produced [22:13:09 CEST] <kurosu> durandal_1707, nope, but to each filter its own [22:15:27 CEST] <kurosu> use pointers instead of offset, so that multiple pointers refer the same line, without need for padding [22:41:52 CEST] <cone-569> ffmpeg 03Michael Niedermayer 07master:5063a18f5635: avcodec/ffv1dec: update progress in case of broken pointer chains [22:47:08 CEST] <kierank> michaelni_: another deadlock on it's way [22:52:13 CEST] <kierank> hmm maybve not [22:53:33 CEST] <cone-569> ffmpeg 03Vittorio Giovara 07master:e240a28b2068: cmdutils: Add auto to threading capabilities report [22:53:34 CEST] <cone-569> ffmpeg 03Hendrik Leppkes 07master:0ad43d0f15e3: Merge commit 'e240a28b20680b326a39b0860fda37d7e459bfc0' [22:55:37 CEST] <kierank> found more [22:57:51 CEST] <cone-569> ffmpeg 03Vittorio Giovara 07master:9ef748173a4e: cmdutils: Print general codec capabilities [22:57:52 CEST] <cone-569> ffmpeg 03Hendrik Leppkes 07master:93ac7a98e022: Merge commit '9ef748173a4e0e58d40afaf38397783cd2537eaa' [22:59:00 CEST] <cone-569> ffmpeg 03Vittorio Giovara 07master:2d59159508c5: lavc: AV-prefix a few left out capabilities [22:59:01 CEST] <cone-569> ffmpeg 03Hendrik Leppkes 07master:53fc900ca0d8: Merge commit '2d59159508c5c1830cc5da907a9454e229077320' [23:02:43 CEST] <cone-569> ffmpeg 03Vittorio Giovara 07master:1f84b008bf2b: fate: Move screenpresso to the appropriate screen capture file [23:02:44 CEST] <cone-569> ffmpeg 03Hendrik Leppkes 07master:ba94e985a33d: Merge commit '1f84b008bf2b1eaca473937c48788cb4e4ce1aea' [23:04:28 CEST] <cone-569> ffmpeg 03Derek Buitenhuis 07master:504e3f75bf73: aac: Make codec init run under ff_thread_once [23:04:29 CEST] <cone-569> ffmpeg 03Hendrik Leppkes 07master:d307c44bafc6: Merge commit '504e3f75bf73a488d39a80a42962bae2a353dd6b' [23:04:41 CEST] <cone-569> ffmpeg 03Luca Barbato 07master:49d7fcd774ac: mpeg12: Unbreak building stale code [23:04:42 CEST] <cone-569> ffmpeg 03Hendrik Leppkes 07master:eebea62671b6: Merge commit '49d7fcd774ac31f242818ad9d45d9c013f3bb3db' [23:05:13 CEST] <cone-569> ffmpeg 03Luca Barbato 07master:b52307933b57: wrapped_avframe: Drop a now-unused variable [23:05:14 CEST] <cone-569> ffmpeg 03Hendrik Leppkes 07master:af065bf11b61: Merge commit 'b52307933b576eba741c80108c3dad09eb48ba12' [23:05:25 CEST] <cone-569> ffmpeg 03Hendrik Leppkes 07master:68e00ad66d13: w32pthreads: fix mingw build on x86 with -msse2 or higher [23:05:26 CEST] <cone-569> ffmpeg 03Hendrik Leppkes 07master:02daf2b36025: Merge commit '68e00ad66d13c57d9eb3a3862b44ab3fb030e19f' [23:17:38 CEST] <kierank> michaelni_: https://trac.ffmpeg.org/ticket/4939 [23:17:49 CEST] <ubitux> nevcairiel: can you elaborate on 53fc900? [23:19:05 CEST] <nevcairiel> the only hunk ffmpeg didnt have from that commit is the one that got reverted in 49d7fcd [23:19:16 CEST] <nevcairiel> no point in introducing breakage for a few commits if i know about it [23:20:49 CEST] <ubitux> i'm confused at git grep '[^_]CODEC_CAP_HWACCEL' [23:20:51 CEST] <ubitux> but ok [23:20:53 CEST] <ubitux> thx [23:24:20 CEST] <cone-569> ffmpeg 03Ganesh Ajjanagadde 07master:cd8a0a9a9a9e: swscale/swscale: add av_warn_unused_result to sws_init_context [23:26:02 CEST] <cone-569> ffmpeg 03Ganesh Ajjanagadde 07master:31ed189d5c05: avutil/internal: add av_warn_unused_result to avpriv_open [23:27:26 CEST] <cone-569> ffmpeg 03Ganesh Ajjanagadde 07master:a0b079ac25fe: avutil/file: add av_warn_unused_result to av_file_map [23:27:47 CEST] <nevcairiel> wonder if my braswell already arrives tomorrow, then I could hopefully get the vp9 hwaccel done [23:30:18 CEST] <cone-569> ffmpeg 03Ganesh Ajjanagadde 07master:6d0c8cb79ac0: avdevice/internal: add av_warn_unused_result [23:56:06 CEST] <rcombs> heh, I've always wondered why libx264rgb existed [00:00:00 CEST] --- Sat Oct 17 2015

1 0

ffmpeg.log.20151016
by burek 17 Oct '15

17 Oct '15

[00:44:41 CEST] <orbisvicis> does ffmpeg -i file.mp3 show the average bitrate of vbr files, or just the first frame ? [01:34:40 CEST] <orbisvicis> is there a more approriate statistic flag than "ffmpeg -i" [01:34:51 CEST] <orbisvicis> "ffmpeg -i" keeps complaining about incorrect syntax, missing files [06:19:01 CEST] <Zeranoe> Is anyone familiar with data that comes from 8mm/Digital8 tapes and what the helical scan receives? [09:15:55 CEST] <_julian> when using mpeg2video encoder are there any parameters outside of AVCodecContext which could influence the bitrate? [09:20:07 CEST] <_julian> I'm trying to figure out why a vlc-transcoded video has twice the sice of the same video transcoded with ffmpeg directly. a diff of the AVCodecContext is not spotting any relevant diff (see: http://pastebin.com/tFCjuY22) [09:21:37 CEST] <BtbN> Well, the mpeg2 encoder parameters. [09:27:28 CEST] <_julian> ah yes, I should propably check the options AVDictionary on avcodec_open2... [09:31:51 CEST] <anYc> benbro: I also started with a ffmpeg script but there were always glitches at the cutpoints. I think I found the issue with your video but I'm still thinking about how I should fix it without breaking other types [09:39:53 CEST] <_julian> BtbN: is there anything else besides the options AVDictionary that could influence the encoder parameters? those are the same now as well (ffmpeg passet bitrate tolerenace in there, vlc did not). but still the vlc file remains unchanged in size [09:45:24 CEST] <_julian> hm, surprisingly the bitrate does not change, no matter what avctx->bit_rate is set to [09:48:07 CEST] <gr8> hi, I have an mkv file with two audio streams, 0: german dts and 1: english AC3. I want to extract the zero-th stream in a given time interval. How do I do that? [09:48:22 CEST] <gr8> I want the quality to be very high, if possible [09:50:34 CEST] <Nosomy> gr8 use -c:a copy option with map option [09:50:35 CEST] <relaxed> gr8: ffmpeg -i input -map 0:a:0 output.flac [09:51:53 CEST] <Nosomy> without "copy" ffmpeg will reencode. [09:52:30 CEST] <gr8> relaxed: using that command, ffmpeg asks if I really want to replace $input ?! [09:52:49 CEST] <gr8> ah no, sorry [09:52:53 CEST] <gr8> pressed tab once too often [09:53:54 CEST] <gr8> it results in an empty file [09:56:34 CEST] <gr8> alright I think this works now [10:02:13 CEST] <satiender> Hi any body use ffmpeg for android ??? [10:04:57 CEST] <benbro> anYc: if you cut at keyframes, why there are glitches? [10:05:34 CEST] <benbro> anYc: you have three parts - beginning|body|end [10:06:00 CEST] <benbro> you re-encode beginning and end. you cut body at keyframes and copy [10:06:07 CEST] <benbro> shouldn't it fit exactly? [10:11:22 CEST] <anYc> that's what I was thinking as well. maybe it has something to do with the starting offset of the streams. if you look at them with ffprobe, the video frames sometimes start at 0.08s while the audio starts earlier [10:12:45 CEST] <gr8> yeah this is perfect, thanks a lot guys [10:13:05 CEST] <pinPoint> gr8: what was the command you used? [10:14:24 CEST] <gr8> ffmpeg -i input -ss $time -t $length -map 0:1 output.flac [10:15:16 CEST] <anYc> benbro: it that is the issue, it may work if the streams are separated, concatenated and then muxed together. but I didn't try it and started to write avcut instead [10:15:53 CEST] <pinPoint> gr8: you are going to rejoin the english with the mkv I assume? [10:15:56 CEST] <benbro> anYc: ok [10:17:08 CEST] <gr8> pinPoint: nope, working further with Audacity on the output [10:17:18 CEST] <pinPoint> ok [10:20:04 CEST] <benbro> anYc: I had a problem concatenating when crf between parts was wrong [10:20:25 CEST] <benbro> anYc: is it possible to detect the quantization to make the three parts match? [10:23:57 CEST] <gr8> curiously the index seems to be broken a bit, because when selecting a time with VLC, the time cursor jumps a bit forward [11:09:08 CEST] <satiender> Hi , Anybody do working on ffmpeg for android [11:25:25 CEST] <gr8> satiender: you need to ask correct questions. [11:26:26 CEST] <satiender> gr8: I am doing work on ffmpeg more than 1.6 year but command line [11:26:37 CEST] <gr8> ok [11:26:39 CEST] <satiender> gr8: Now I want use it in android [11:26:41 CEST] <gr8> ok [11:26:47 CEST] <satiender> I done that [11:26:53 CEST] <gr8> nice [11:26:59 CEST] <satiender> ffmpeg working on android perfectly [11:27:02 CEST] <gr8> great [11:28:39 CEST] <satiender> but problem is that I want mix two videos [11:29:04 CEST] <satiender> means one is text video and another is proper playback video [11:29:30 CEST] <satiender> I search a lot on google I not get anything [11:29:45 CEST] <satiender> gr8: can you help me [11:29:48 CEST] <satiender> ?? [11:30:09 CEST] <gr8> nope. Wait until someone answers, it may take a while. [11:31:18 CEST] <satiender> ok [11:31:53 CEST] <satiender> gr8: Anothe thing is that how we can use ffmpeg binary in android apk [11:45:32 CEST] <JEEB> the usual way? you build a shared library and load it up? [11:45:43 CEST] <JEEB> in the NDK documentation you have plenty of information on this AFAIK [11:48:07 CEST] <codingquark> Question: I have one video on top of another (scaled) via overlay. After fading out, it keeps a black area. Anyway I could remove that black area? [12:20:19 CEST] <codingquark> Does it have to do something with video formats? Input and output are mp4 [13:00:38 CEST] <satiender> JEEB: you mean if I use .so files of ffmpeg then I can directly using following command : [13:01:14 CEST] <satiender> ffmpeg -i /sdcard/video.ts -vcodec copy -acodec copy -f mpeg2video video.mp4 [13:05:10 CEST] <maseck> ffmpeg -i video.mp4 -threads 1 video.y4m doesn't seem to decode on one thread. Any advice? [13:07:30 CEST] <qwebirc58121> hello [13:07:42 CEST] <qwebirc58121> does anyone know how i trim mp4 video-only without reencoding it [13:12:44 CEST] <maseck> Ok, I figured it out. [13:13:15 CEST] <maseck> Ok, I figured it out. "ffmpeg -threads 1 -i video.mp4 video.y4m" was what I wanted. [13:13:56 CEST] <maseck> Is ffh264 the default decoder for h264 video? [13:23:56 CEST] <anYc> benbro: oh, I don't know that much about ffmpeg and h264, sorry [14:12:03 CEST] <DHE> maseck: there are 2 h264 decoders. one is pure software, one uses vdpau on your graphics card but is only usable for video playback [14:12:41 CEST] <maseck> Is the software on ffh264? [14:12:49 CEST] <maseck> *one [14:13:32 CEST] <DHE> probably... [14:13:48 CEST] <DHE> a checking of the documentation says there are other h264 decoders and the two above are all I have available to me. :) [14:27:23 CEST] <Duridurum> Hi there. Build of ffmpeg failed in fritzbox-freetz current trunk version. [14:27:38 CEST] <Duridurum> ah, never mind. Forgot to set TMPDIR [15:15:15 CEST] <Chagalle> I can't seem to read standard error/output from ffmpeg on Linux (from debian jessie package manager), what's wrong with it? [15:16:02 CEST] <Chagalle> using Qt, while QProcess.waitForReadyRead() -> readAllStandardError/Output, neither outputs anything. Works on Windows [15:28:51 CEST] <Chagalle> also is there any way to get progress with 2 pass encoding without calculating it based on duration and frame rate? [15:53:38 CEST] <bove> Can a concat list file hold separate audio and video files? [16:14:05 CEST] <waressearcher2> can I ask about audacity ? [16:14:12 CEST] <waressearcher2> I loaded "project_name" and it showed dialog window with message "project check of project_name folder found 2 orphan block files, these files are unused by the project but might belong to other projects, they are doing no harm and are small", what could be the reason they appeared ? can I delete them ? [16:16:16 CEST] <zenny> Hi how to pipe the ffmpeg output to the v4l2 looback device? [16:18:51 CEST] <zenny> I am trying to capture a screen and then output to the v4l2 loopback device, fyi. [16:26:21 CEST] <kiki67100> Hello everybody [16:26:34 CEST] <kiki67100> I would to resize simple mp4 video but ffmpeg show error message [16:26:55 CEST] <kiki67100> Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height [16:26:59 CEST] <kiki67100> Someone help me ? [16:27:45 CEST] <kiki67100> Here the output [16:27:45 CEST] <kiki67100> http://pastebin.com/r1SujkaF [17:00:41 CEST] <Duridurum> maybe incorrect parameters such as bit_rate, rate, width or height, kiki67100 [19:19:26 CEST] <zenny> Is there a way that I can output the ffmpeg capture to the v4l2 loopback device? [19:19:36 CEST] <zenny> or say pipe to? [19:20:22 CEST] <klaxa> you can output to a pipe like so for example: ffmpeg -i input.mkv -c copy -f matroska - | cat - [19:25:56 CEST] <zenny> klaxa: That I know of. But how can I pipe to the v4l2loopback device? [19:26:34 CEST] <klaxa> ooh, it's like a virtual device? [19:26:42 CEST] <zenny> yes [19:27:20 CEST] <klaxa> maybe like ffmpeg -i input.mkv -f v4l2 /dev/video0 or something? [19:27:27 CEST] <klaxa> v4l2 is an output format at least [19:27:33 CEST] <zenny> that is the capture part. [19:28:33 CEST] <zenny> I guess this example will give you some idea. http://ubuntuforums.org/showthread.php?t=901612&p=5669427#post5669427 However, they are outdated and mjpegtools_yuv_to_v4l part in that instructions does not compile [19:29:18 CEST] <klaxa> wait [19:29:21 CEST] <klaxa> what do you want to do? [19:29:21 CEST] <zenny> klaxa: I want to capture a screenshot and pipe to a virtual device. [19:30:02 CEST] <klaxa> what's your virtual device called? [19:30:26 CEST] <klaxa> like i said, it should be possible with ffmpeg [something something] -f v4l2 /device/name [19:30:36 CEST] <klaxa> maybe it needs specific codecs [19:31:36 CEST] <zenny> @klaxa: you are talking about capture part which I can do that with the x11grab, but how to output (pipe to the virtual device)? [19:31:49 CEST] <klaxa> no i am not [19:32:26 CEST] <klaxa> your recording probably looks like this: ffmpeg -f x11grab -framerate 30 -s 1920x1080 -i :0.0 output.mp4 [19:32:41 CEST] <klaxa> instead of output.mp4 you want to pipe it to a special device file [19:32:49 CEST] <zenny> Something like: ffmpeg -f x11grab -s 640x480 -r 5 -i :0.0 -pix_fmt yuv420p -s 320x240 -r 5 -f yuv4mpegpipe -an - | | mjpegtools_yuv_to_v4l /dev/video2 [19:33:13 CEST] <zenny> I can get the first part, but not the latter part. [19:33:19 CEST] <klaxa> replace -r with -framerate (it's "more correct", see the manpage) [19:33:41 CEST] <klaxa> what's that double pipe doing there? [19:33:46 CEST] <klaxa> pasting error? [19:33:50 CEST] <zenny> that is a typo [19:33:57 CEST] <klaxa> well what's not working? [19:34:04 CEST] <zenny> single pipe and I would like to know how to pipe? [19:34:04 CEST] <klaxa> can you pastebin the complete output? [19:34:18 CEST] <klaxa> it looks correct [19:34:53 CEST] <zenny> The mjpegtools_yuv_to_v4l tool from http://panteltje.com/panteltje/mcamip/mjpegtools_yuv_to_v4l-0.2.tgz is so old that it is not compiling. And I thought maybe ffmpeg has natively built this. [19:35:26 CEST] <klaxa> have you tried using -f v4l2 /dev/video2 instead of using a pipe? [19:35:38 CEST] <klaxa> or just -f v4l2 - > /dev/video2 [19:35:57 CEST] <klaxa> instead of -f yuv4mpegpipe - [19:36:05 CEST] <klaxa> you can also get rid of the -an [19:38:44 CEST] <klaxa> if there's something you don't understand just ask [19:40:15 CEST] <zenny> ffmpeg -report -f x11grab -s 640x480 -r 5 -i :0.0 -pix_fmt yuv420p -s 320x240 -r 5 -f image2pipe - | ffmpeg -f v4l2 /dev/video7 tried with this, but didn't work. [19:43:41 CEST] <zenny> Error: Output #0, v4l2, to '/dev/video7': Output file #0 does not contain any stream. /dev/video7 is the v4l2loopback device. [19:47:12 CEST] <zenny> This works alright: $ ffmpeg -report -f x11grab -s 1920x1080 -r 5 -i :0.0 -pix_fmt yuv420p -f mjpeg -r 5 -f yuv4mpegpipe - | ffplay - &>/dev/null [19:47:50 CEST] <zenny> but the question is how to pipe the screencast to v4l2loopback virtual device? [19:48:49 CEST] <klaxa> well the first doesn't work, because you don't have an input for the ffmpeg process you called [19:49:29 CEST] <klaxa> have you tried: ffmpeg -report -f x11grab -s 1920x1080 -framerate 5 -i :0.0 -pix_fmt yuv420p -c:v mjpeg -f v4l2 /dev/video7 [19:49:38 CEST] <klaxa> or replace v4l2 with yuv4mpegpipe [19:49:41 CEST] <klaxa> not sure if that will work though [19:51:05 CEST] <zenny> klaxa: yes I did and didn't work. Says "Incompatible pixel format 'yuv420p' for codec 'mjpeg', auto-selecting format 'yuvj420p' [swscaler @ 0x2e7d720] deprecated pixel format used, make sure you did set range correctly [v4l2 @ 0x2e76f40] V4L2 output device supports only a single raw video stream" [19:51:17 CEST] <klaxa> ah [19:51:21 CEST] <klaxa> try -c:v rawvideo then [19:51:23 CEST] <zenny> And "Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument" [19:51:29 CEST] <klaxa> instead of -c:v mjpeg [19:53:15 CEST] <zenny> @klaxa: thanks the latter worked. :D [19:53:23 CEST] <klaxa> :) [19:53:50 CEST] <klaxa> ok then off to the shower~ [19:54:06 CEST] <zenny> have a nice shower, then ;-) and thanks for helping! [20:02:28 CEST] <blue_misfit> hey guys... anyone know offhand if XDCAM HD422 supports adaptive GOP or if it MUST be fixed for compatibility? [20:07:20 CEST] <ChocolateArmpits> blue_misfit: should support [20:07:31 CEST] <blue_misfit> neat :) [20:07:55 CEST] <blue_misfit> I'm making some workflows to encode MEPG-TS with an XDCAM HD422 compatible essence that can be rewrapped to MXF for playout if necessary [20:07:56 CEST] <ChocolateArmpits> Well if judging by the last gop is enough for you [20:08:13 CEST] <ChocolateArmpits> Also I'm looking at an XDCAM HD 35 file [20:08:23 CEST] <ChocolateArmpits> basically 4:2:0 35mbps equivalent [20:08:29 CEST] <blue_misfit> hmmm [20:08:43 CEST] <blue_misfit> yeah that may not be apples to apples, pretty sure XDCAM HD is VBR [20:08:48 CEST] <ChocolateArmpits> it uses same mpeg2 encoding so I'm not all that worried [20:08:50 CEST] <blue_misfit> whereas HD422 is CBR [20:09:54 CEST] <ChocolateArmpits> Dang I only have color bars test footage here [20:10:04 CEST] <ChocolateArmpits> So the bitrate viewer results may not be accurate [20:10:09 CEST] <blue_misfit> gotcha [20:10:11 CEST] <ChocolateArmpits> though it stays cbr [20:10:14 CEST] <blue_misfit> welp I'll just test [20:10:29 CEST] <blue_misfit> I'm using Harmonic WFS to make this file and can test with real playout gear so it shouldn't be too hard [20:12:53 CEST] <ChocolateArmpits> There is bmx library for wrapping up mxf files, but you will have to unwrap the essence in the ts prior to wrapping the ts. With ffmpeg this is a one step process.. [20:13:15 CEST] <ChocolateArmpits> I mean wrapping the essence [20:14:26 CEST] <ChocolateArmpits> It has plenty of nice tweaking options not really available with ffmpeg and can wrap to multiple flavours for delivery [20:14:59 CEST] <ChocolateArmpits> I'm personally using it to concatenate mxf files for archival [20:18:03 CEST] <blue_misfit> interesting! [20:18:42 CEST] <blue_misfit> We use Telestream stuff to rewrap because we also usually need to merge in caption data from SCC files - e.g. taking the 608 data and synthesizing 708 data and then storing all of it in a SMPTE 436M VANC track [20:18:53 CEST] <blue_misfit> FlipFactory and Vantage are out go-to apps for this [20:25:14 CEST] <ChocolateArmpits> So does ffmpeg step into your workflow anywhere ? [20:55:21 CEST] <bf_> Hey, can anybody help me to strip the audio track from an mkv into a mp3 file using liblame? [20:55:35 CEST] <bf_> I have found some ffmpeg command from 2009, but it won't work [20:57:26 CEST] <ChocolateArmpits> bf_: ffmpeg -i [input.mkv] -map 0:a -vn -acodec libmp3lame -b:a 256k [output.mp3] [20:57:28 CEST] <ChocolateArmpits> like this ? [20:58:01 CEST] <ChocolateArmpits> this presumes that your mkv has only one audio track [20:58:02 CEST] <bf_> oh thanks [20:58:20 CEST] <bf_> I was stuck with having multiple map commands, and didn't know i could just use "a" (I suppose it means audio) [20:58:37 CEST] <ChocolateArmpits> yeah it basically means "everything audio" [20:59:02 CEST] <ChocolateArmpits> you can do a more specific map like 0:a:0 which would map the first audio track of the first input [20:59:17 CEST] <bf_> thats pretty, cool. I think it works ChocolateArmpits, thank you so much [20:59:34 CEST] <ChocolateArmpits> map_channel is even more specific allowing to remap channels in tracks [20:59:35 CEST] <bf_> Previously I had a command with -map 0:0 - map 1:0 -map 2:0 iirc [20:59:57 CEST] <ChocolateArmpits> well that's a confusing map [21:00:25 CEST] <ChocolateArmpits> the mapper should have his cartography club membership revoked [21:00:50 CEST] <ChocolateArmpits> but yeah, it helps if you the documentation [21:00:55 CEST] <ChocolateArmpits> read * [21:01:10 CEST] <ChocolateArmpits> the examples there are mostly common use case [21:03:34 CEST] <onyx-> Im using nginx with the rtmp module that uses ffmpeg to transcode a live stream from an IP camera [21:04:01 CEST] <onyx-> its working but after a few minutes it stops and I have to restart nginx for it to start working again [21:04:14 CEST] <onyx-> any idea what can be causing this issue? [21:06:48 CEST] <bf_> :D ChocolateArmpits good to see you take that with humor : [21:06:49 CEST] <bf_> :) [21:07:12 CEST] <bf_> onyx-: maybe nginx is really not made to be used in such a scenario? [21:07:32 CEST] <bf_> I mean if there is a memory leak somewhere it might run out of memory and stop [21:08:35 CEST] <onyx-> its a 2gb ram server, I been trying to see if nginx erros out but it doesnt [21:10:52 CEST] <onyx-> how do I check the ffmpeg error log? [21:11:27 CEST] <ChocolateArmpits> there's a -report command that outputs all log to a file [21:11:49 CEST] <ChocolateArmpits> -loglevel sets the logging level, check documentation for accurate description of values [21:11:56 CEST] <onyx-> ok [21:32:16 CEST] <blue_misfit> ChocolateArmpits, not really :) [22:21:24 CEST] <xrisk> Hello folks, I'm building ffmpeg with lame, and even though the lame binary is on my path, I get a libmp3lame not found. Any ideas? [22:22:19 CEST] <BtbN> ffmpeg does not use the lame binary. [22:24:14 CEST] <xrisk> BtbN: oh, I did not know that. Can you tell me how it works? [22:24:24 CEST] <xrisk> A link to some doc would be fine. [22:24:32 CEST] <BtbN> It just uses the library. [22:24:45 CEST] <BtbN> Which you already named yourself. [23:31:35 CEST] <TikityTik> i forgot how to calculate bitrate based off duration and filesize [23:31:52 CEST] <Mavrik> O.o [23:31:59 CEST] <Mavrik> divide filesize with duration? :P [23:32:07 CEST] <Mavrik> The unit of bitrate IS bits/s :) [23:32:46 CEST] <ln-> danger! if the duration is 0, do not divide by it, or bad things happen. [23:33:19 CEST] <TikityTik> so how? [23:33:50 CEST] <TikityTik> kbps = 4096 Kb / 1 min 30 seconds? [23:34:15 CEST] <TikityTik> err nvm [23:34:47 CEST] <TD-Linux> you need to convert from microwave time to seconds [00:00:00 CEST] --- Sat Oct 17 2015

1 0