Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

December 2015

1 participants
62 discussions

ffmpeg-devel.log.20151130
by burek 01 Dec '15

01 Dec '15

[04:05:40 CET] <Compn> wtf is this http://www.acm.org/about/se-code [09:29:29 CET] <fritsch> wm4: https://trac.ffmpeg.org/ticket/5047 <- that's for you I think :-) [09:29:50 CET] <fritsch> wm4: cause when looking through the commits i saw some by you in that direction [09:32:43 CET] <wm4> fritsch: that's not even a mp3, that's a mp4, so my dealings with the mp3 demuxer can't have broken it [09:33:07 CET] <wm4> it's probably a problem with enabling parsing [09:34:11 CET] <wm4> also getting 403 on the sample url [09:35:04 CET] <fritsch> wm4: retry fixed permission [09:35:06 CET] <fritsch> sorry for that [09:35:34 CET] <fritsch> plays nicely in the browser even :-) [09:39:33 CET] <wm4> and yes it's just mp3 in mp4 [09:48:05 CET] <wm4> unconditionally enabling full parsimg helps [09:48:32 CET] <nevcairiel> supposedly that breaks other things [09:50:15 CET] <nevcairiel> personally I would enable it and then try to fix the parser to not break things, even better if someone has a sample handy of such a case right now [09:58:13 CET] <wm4> nevcairiel: I'd feel better about that than about the arbitrary and unreliable heuristic that enables parsing [10:14:31 CET] <rcombs> https://github.com/rcombs/FFmpeg/commits/auto-bsf now with mpegts support [10:15:01 CET] <rcombs> also, I changed mpegts's write_header to init because it never actually writes anything, which also lets me remove some duplicated cleanup code :D [10:17:13 CET] <rcombs> so that leaves AVI and WTF still using ff_check_h264_startcode and needing auto-filtering for AVC, and MOV and FLV still needing auto-filtering for AAC [10:38:10 CET] <ubitux> so what happened to the idea of dropping -fno-tree-vectorize? [11:25:04 CET] <rcombs> nevcairiel: I'm good at typing; meant ff_stream_& [11:25:11 CET] <nevcairiel> i figured [11:25:24 CET] <wm4> so where does one get truehd specs? [11:25:38 CET] <rcombs> unless you have a better idea for the name [11:25:41 CET] <nevcairiel> one doesnt [11:25:47 CET] <rcombs> `ff_stream_&` feels super awkward [11:26:00 CET] <rcombs> specs? [11:27:27 CET] <rcombs> but I guess it just feels that way because `av_stream_&` mirrors the struct name [11:27:31 CET] <rcombs> so w/e [11:28:16 CET] <wm4> nevcairiel: why not? [11:28:20 CET] <wm4> is it like the DVD spec? [11:28:25 CET] <fritsch> wm4: from kodi's bitstream parser code [11:28:34 CET] <nevcairiel> dunno, but it seems rather carefully guarded [11:29:12 CET] <fritsch> wm4: https://github.com/FernetMenta/xbmc/blob/master/xbmc/cores/AudioEngine/Util… [11:29:13 CET] <nevcairiel> whats so special about the kodi code thats not in the ffmpeg decoder? :d [11:29:32 CET] <wm4> yeah ffmpeg has such code too [11:29:45 CET] <fritsch> nevcairiel: it was there before and no one yet replaced it [11:29:47 CET] <wm4> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/spdifenc.c [11:30:01 CET] <nevcairiel> when I worked on Atmos extensions last year, I googled for alternative truehd implementations [11:30:07 CET] <nevcairiel> all of them were based on the ffmpeg code [11:30:18 CET] <fritsch> see the author of the ffmpeg code [11:30:24 CET] <fritsch> he is also kodi audio dev [11:32:02 CET] <nevcairiel> so in short, all that is known about truehd/mlp can be found in ffmpeg, to get some extra info i had to get the disasm on [11:34:15 CET] <fritsch> nevcairiel: the reason we still have our part of the code is the architecture ... which needs some work to get the ffmpeg bits into place [11:34:40 CET] <nevcairiel> isnt that always the reason =p [11:34:56 CET] <wm4> I don't understand that... the ffmpeg code could just be used in place there [11:35:17 CET] <wm4> spdifenc is a big hack API-wise (it's a muxer, really?) [11:35:21 CET] <nevcairiel> i've been using spdifenc from avformat for a couple years now, and can confirm it works for all dolby and dts codecs, i didnt have hardware to test aac [11:37:43 CET] <fritsch> Anssi: ^^ our reason to not use it was "lack of time right"? I cannot remember the architecture argument [11:41:29 CET] <Anssi> fritsch: unfortunately I don't remember why gnif reimplemented it in our own code... I remember the ffmpeg code working just fine, but maybe I just forgot [11:42:55 CET] <Anssi> the code has grown some extra E-AC-3 support now, I think, though, that ffmpeg is missing, but it is somewhere in my long todo list to port it to ffmpeg [11:47:01 CET] <nevcairiel> ffmpeg supports eac3 in spdifenc [11:47:10 CET] <nevcairiel> my software uses it fine [11:47:27 CET] <fritsch> yeah - then lack of time is left as argument :-) [11:48:05 CET] <nevcairiel> although i'm not 100% sure if it works perfectly, as a few select people reported that eac3 didnt work for them, but it works on my hardware .. maybe their hardware is just more picky, or just plain out doesnt support it, hard to judge [11:48:51 CET] <fritsch> yeah - ours also works - just revisited it with pulseaudio some days ago as we restructed stream_type handling [11:49:00 CET] <fritsch> cause of android wants to have non IEC streams [11:50:32 CET] <wm4> I never can get pulse to pass through compressed audio [11:50:43 CET] <fritsch> wm4: then check our AESinkPULSE [11:50:44 CET] <fritsch> :-) [11:50:52 CET] <wm4> that's not the problem [11:50:59 CET] <fritsch> and follow the wiki: set device to stereo and enable dts/ac3/eac3 [11:51:03 CET] <wm4> the problem is configuring pulse in a way it does it at all [11:51:08 CET] <fritsch> ah [11:51:12 CET] <fritsch> yeah i have screenshots in the wiki [11:51:16 CET] <wm4> lol [11:51:25 CET] <fritsch> and the sink which works :-) [11:51:27 CET] <fritsch> so what is left? [11:51:27 CET] <wm4> so you're confirming my point or what? [11:51:45 CET] <wm4> (that it's a pain to setup pulse to do that if you need screenshots) [11:51:46 CET] <fritsch> just said: we are succesfully using PA for DTS /AC3 / EAC3 [11:51:48 CET] <nevcairiel> users need to do careful setup of audio settings for bitstreaming to work? yeah comfortable much :) [11:52:06 CET] <fritsch> wm4: open pavucontrol, check your hdmi device click ac3, dts, eac3, make sure it is stereo profile [11:52:16 CET] <fritsch> http://kodi.wiki/view/PulseAudio#Passthrough_Mode [11:52:33 CET] <nevcairiel> note that HD audio doesnt use stereo, it uses more channels, but maybe you just dont do HD [11:52:40 CET] <fritsch> hd audio won't work with PA [11:52:48 CET] <wm4> "REMEMBER: To use passthrough you need to be using 2.0 channel configuration via pavucontrol (e.g. Digital Stereo (HDMI)" [11:52:49 CET] <wm4> lol [11:52:52 CET] <fritsch> that's why I talk about dts, ac3, eac3 [11:53:08 CET] <wm4> what does hd audio mean? [11:53:13 CET] <fritsch> dts-hd, truehd [11:53:15 CET] <nevcairiel> truehd and dts-hd [11:53:19 CET] <fritsch> everything that needs more than 2 pcm channels [11:53:22 CET] <fritsch> to be sumbitted [11:53:28 CET] <wm4> lol [11:53:30 CET] <fritsch> in our case 8 + 192 khz [11:53:50 CET] <wm4> pulse, how to make your audio not work [11:54:27 CET] <fritsch> wm4: anything left? :-) the rest is in the AESinkPULSE [11:54:49 CET] <wm4> I implemented this years ago [11:54:56 CET] <fritsch> yeah, me too [11:55:00 CET] <wm4> but every time I test I have to struggle with pulse [11:55:05 CET] <fritsch> hehe [11:55:14 CET] <fritsch> it's straight forward [11:55:17 CET] <wm4> no [11:55:18 CET] <fritsch> only for eac3 you need to take care [11:55:29 CET] <fritsch> with old api using 4*encoded_sample_rate [11:55:34 CET] <fritsch> the new one does it automatically [11:55:55 CET] <wm4> what old and new API? [11:55:57 CET] <nevcairiel> I always have to suppress an evil laughter if i have to hear about the "fun" with linux audio [11:56:13 CET] <fritsch> yeah - not to mention the fun of windows directsound api ... [11:56:16 CET] <wm4> nevcairiel: I have my own share of fun with other platforms too [11:56:27 CET] <fritsch> which supports also only dts, ac3 and no eac3 [11:56:33 CET] <fritsch> and wasapi is a big mess [11:56:45 CET] <fritsch> if you need to handcode the delay measurements ... [11:56:45 CET] <nevcairiel> i can bitstream even HD through a directsound renderer [11:56:54 CET] <fritsch> nice - we can't [11:57:24 CET] <fritsch> https://github.com/FernetMenta/xbmc/blob/master/xbmc/cores/AudioEngine/Sink… <- wm4 [11:57:37 CET] <fritsch> prior to 2.0 [11:58:57 CET] <fritsch> nevcairiel: https://msdn.microsoft.com/en-us/library/windows/hardware/ff538534(v=vs.85)… <- we use this [11:59:06 CET] <fritsch> ac3 for both so that directsound "eats" it [11:59:12 CET] <fritsch> and then the header decides [11:59:18 CET] <wm4> fritsch: so you just hope PA assumptions somehow matches kodi assumptions about the raw format? [11:59:28 CET] <nevcairiel> i would have to find the code that deals with this [11:59:29 CET] <fritsch> nope - i know about the assumptions [11:59:32 CET] <fritsch> cause I read the PA code [11:59:47 CET] <fritsch> wm4: which assumptions btw.? [12:00:28 CET] <fritsch> it's not that complicated ... it takes eac3 format type iec encapsulated, stereo speaker config + matching format [12:00:31 CET] <fritsch> that's it [12:00:33 CET] <fritsch> and obviously the samplerate [12:01:05 CET] <wm4> ah ok, the kodi params are set in info? [12:01:41 CET] <fritsch> yes [12:02:06 CET] <fritsch> encoding, sample_format, channel_map, samplerate [12:02:33 CET] <fritsch> that's it the rest is "buffer" management and api management [12:02:34 CET] <wm4> that's weird, my code doesn't even use pa_sample_spec [12:02:45 CET] <wm4> (at init anyway) [12:02:53 CET] <fritsch> you most likely don't use pa_stream_new_extended [12:02:54 CET] <fritsch> then [12:03:11 CET] <wm4> I do [12:03:17 CET] <fritsch> argh wait [12:03:21 CET] <fritsch> see where we use it [12:03:21 CET] <wm4> it takes a pa_format_info [12:03:26 CET] <fritsch> ours, too [12:03:31 CET] <fritsch> https://github.com/FernetMenta/xbmc/blob/master/xbmc/cores/AudioEngine/Sink… [12:03:34 CET] <fritsch> just used here [12:03:35 CET] <fritsch> for validation [12:03:48 CET] <wm4> seems pointless [12:03:53 CET] <fritsch> and for estimating bytespersecond, framesize and so on [12:03:59 CET] <fritsch> not really [12:04:09 CET] <fritsch> that way you can make sure that PA likes what you setup [12:04:17 CET] <wm4> I have my own functions for calculating bitrate etc. [12:04:18 CET] <fritsch> and can easily get the management data you need [12:04:28 CET] <fritsch> yeah - if you like implementing it yourself [12:04:38 CET] <fritsch> i thought letting the API do as much as possible [12:04:43 CET] <fritsch> give me less code to maintain [12:05:10 CET] <wm4> mpv's pulse sink source file is slightly shorter than kodi's [12:05:15 CET] <fritsch> i think so [12:05:22 CET] <fritsch> we have a lot management stuff in there [12:05:24 CET] <fritsch> device hotplug [12:05:26 CET] <fritsch> enumeration [12:05:28 CET] <wm4> me too [12:05:36 CET] <fritsch> the addpackets method should be the same size [12:05:55 CET] <wm4> well, not that it means anything, but I still don't think the sample_spec thing is really needed [12:05:58 CET] <fritsch> and some AE_TYPE to pa_type static conversion stuff could be moved into a util method [12:06:17 CET] <fritsch> http://maemo.org/api_refs/5.0/5.0-final/pulseaudio/sample_8h.html#0d9ad972e… [12:06:20 CET] <fritsch> yeah [12:06:30 CET] <fritsch> most likely you would fail when you try to create the stream [12:06:47 CET] <wm4> I would hope so [12:07:51 CET] <wm4> the site you linked doesn't have pa_stream_new_extended [12:09:07 CET] <fritsch> it was about the valid [12:09:10 CET] <wm4> http://freedesktop.org/software/pulseaudio/doxygen/stream_8h.html#acf41f201… [12:09:14 CET] <wm4> "While connecting, the server will select the most appropriate format which the client must then provide." [12:09:16 CET] <wm4> whatever that means [12:09:27 CET] <wm4> (one format from the list, or possibly something very different?) [12:09:36 CET] <fritsch> we don't want something different [12:09:45 CET] <fritsch> and therefore ask before [12:09:48 CET] <fritsch> if the combination works [12:09:51 CET] <wm4> where? [12:09:58 CET] <fritsch> the _valid_ call [12:10:09 CET] <wm4> but that's probably client-side only, without involving the server [12:10:28 CET] <fritsch> yeah - but the server side is covered with the enumeration [12:10:35 CET] <fritsch> there we know what we can provide / server has [12:10:49 CET] <fritsch> -> lunch time :-) [12:10:56 CET] <fritsch> so the very moment the spec is valid [12:11:04 CET] <fritsch> and we have setup a format our sink can do (enumeration) [12:11:08 CET] <fritsch> -> it should work (TM) [12:11:15 CET] <wm4> why not use this? http://freedesktop.org/software/pulseaudio/doxygen/format_8h.html#a9efd301c… [12:11:31 CET] <wm4> fritsch: well it could change after enumeration [12:31:34 CET] <cone-636> ffmpeg 03Paul B Mahol 07master:376a3bdb7bbe: avfilter/af_sidechaincompress: add level_in and level_sc options [12:31:34 CET] <cone-636> ffmpeg 03Paul B Mahol 07master:6b978dadc654: avfilter/af_sidechaincompress: do not require writable input frames for acompressor filter [12:55:18 CET] <fritsch> wm4: see the our registering for the callback [12:55:23 CET] <fritsch> wm4: we get informed when this happens [12:55:26 CET] <fritsch> and change accordingly [12:55:44 CET] <fritsch> and ask AE factory to care for it, e.g. reinitializing us [13:59:18 CET] <Anssi> nevcairiel: yeah the ffmpeg e-ac-3 code works fine for normal streams, but it doesn't have any substream handling code, so e-ac-3 streams using substreams with independent streams might not (I haven't looked into this yet) [14:00:40 CET] <nevcairiel> i guess they might not work, i'm not sure, luckily discs using that concept are exceedingly rare [14:00:55 CET] <rcombs> yeah, substreams don't work at all [14:02:44 CET] <rcombs> adding support for dependent substreams (e.g. 7.1 eac3) will require some internal tweaks to how channels are handled, but it shouldn't be too bad [14:02:55 CET] <rcombs> for multiple independent substreams& I'm not even sure how that should work [14:03:01 CET] <nevcairiel> we're talking about bitstreaming [14:03:33 CET] <rcombs> oh, like spdif passthrough? [14:03:39 CET] <nevcairiel> yes [14:04:21 CET] <rcombs> I wonder how multiple independent substreams should be treated [14:04:22 CET] <rcombs> you'd probably want those as separate AVStreams, really [14:04:48 CET] <rcombs> but there's no mechanism for a parser or a decoder to output multiple streams [14:05:06 CET] <rcombs> there probably should be, though [14:05:12 CET] <rcombs> also for things like H.264 with embedded 708 captions [14:07:43 CET] <rcombs> here be all sorts of dragons [14:33:33 CET] <ubitux> why is fate-api-seek depending on fate-lavf? [14:35:54 CET] <Compn> mp3 in mp4 is a hack... [14:37:50 CET] <fritsch> Compn: in general or in ffmpeg realization? [14:38:23 CET] <nevcairiel> everything in multimedia is a hack [14:38:27 CET] <fritsch> lol [14:38:27 CET] <nevcairiel> especially Compn's existance [14:38:42 CET] <fritsch> concerning "the standard" it is perfectly fine [14:38:48 CET] <Daemon404> how is it a hack [14:38:51 CET] <Daemon404> doesnt it have a spec even [14:38:57 CET] <fritsch> it has - therefore I asked [14:40:10 CET] <wm4> anyway my funny little patch breaks the sample that was pointed out [14:40:36 CET] <wm4> and I'm too lazy (which actually means: busy) to analyze and fix it [14:40:57 CET] <fritsch> as 2.7 worked - a bisect should find the bugger [14:41:02 CET] <fritsch> i can do that if it's welcome tonight [14:41:45 CET] <wm4> might be a patch-that-fixes-one-sample-breaks-another thing [14:42:05 CET] <fritsch> funny the linked patch also talks about handbrake encoder [14:42:11 CET] <fritsch> the linked bug [14:42:34 CET] <fritsch> it's probably the third bug I file that happens with users using handbrake [14:42:53 CET] <wm4> oh yes we discussed it with a handbrake dev too [14:42:55 CET] <fritsch> which I think also uses ffmpeg under the hood? [14:43:15 CET] <fritsch> so that might be an ffmped 2.7 produced "stream" cannot be decoded properly with 2.8 [14:43:18 CET] <fritsch> that would suck [14:43:35 CET] <nevcairiel> handbrake likes to play a bit loose with the spec sometimes, the argument pretty much ended in "but the spec says this is valid" =p [14:44:02 CET] <fritsch> for us we always get: does not play in kodi 16 - but worked in kodi 15 [14:44:08 CET] <fritsch> fix it, it s regression they say :-9 [14:46:11 CET] <Compn> does quicktime play it ? [14:46:56 CET] <fritsch> without audio my colleague said [14:47:00 CET] <fritsch> i don't have quicktime [14:47:21 CET] <Compn> if quicktime cant play it, then its not valid mp4 :P [14:47:25 CET] <fritsch> mpv based on ffmpeg 2.7.x works [14:47:31 CET] <fritsch> ffplay 2.7.x also works [14:47:41 CET] <Compn> i realize that we can play such files of course [14:47:45 CET] <Compn> and that it is a regression [14:47:49 CET] <Compn> just sayin... [14:47:52 CET] <fritsch> the biggest problem here is: [14:47:57 CET] <fritsch> handbrake produces such stuff _right now_ [14:47:59 CET] <wm4> I bet mplayer with its old builtin mov demuxer can play it [14:48:07 CET] <Compn> of course mplayer can still play it :P [14:48:09 CET] <fritsch> I did not try [14:48:25 CET] <fritsch> i use kodi - if it fails I try mpv - if that also fails -> file is broken [14:48:27 CET] <fritsch> :-) [14:48:27 CET] <wm4> because mplayer uses mpg123, so mpg123 somehow pieces the data together [14:48:28 CET] <Compn> dont we have a handbrake author here on irc ? [14:48:49 CET] <Compn> fritsch : we should strongarm this person into disabling mp3 audio [14:49:43 CET] <fritsch> jstebbins seems the main author [14:49:45 CET] <fritsch> cannot find him here [14:49:58 CET] <Daemon404> fritsch, he is j45 [14:50:06 CET] <fritsch> j45: ping [14:50:16 CET] <fritsch> Daemon404: thx - yeah yours pinged him already [14:50:28 CET] Action: Compn goes afk [14:50:36 CET] <fritsch> Compn: haha [14:50:45 CET] <Compn> gotta run, 8:50 am on monday. [15:01:57 CET] <wm4> just tried it with mplayer, fails on at least 1 of the samples too [15:06:07 CET] <durandal_1707> kierank: whats status? [15:06:33 CET] <kierank> durandal_1707: ? [15:06:51 CET] <durandal_1707> of vc5 [15:07:39 CET] <kierank> dunno it's a weekend project [15:07:55 CET] <kierank> smpte people are investigating whether I can get reference decoder [15:09:49 CET] <durandal_1707> they contacted you? [15:32:29 CET] <kierank> Yes I asked for samples [15:33:07 CET] <kierank> Basically I understand bitstream now [15:33:17 CET] <kierank> Haven't found out how they choose Huffman tables [15:33:20 CET] <wm4> wait, do you mean the reference encoder source, or just a binary? [15:33:45 CET] <kierank> Reference Encoder source for vc-5 and samples (not the same as cfhd) [15:36:16 CET] <durandal_1707> vc-5 is just cfhd with extra bytes? [15:37:04 CET] <durandal_1707> cfhd is in avi, and vc-5 is raw format? [15:37:34 CET] <kierank> Vc-5 is a different format inspired by cfhd [15:37:51 CET] <kierank> But they share a few features [15:38:33 CET] <kierank> I will upload my tree to github later [15:39:10 CET] <kierank> I basically have a bitstream parser and a semi-working lowpass decoder [15:40:18 CET] <durandal_1707> for cfhd samples we have? [15:42:22 CET] <kierank> I have 3 [18:09:21 CET] <Daemon404> so many mjpeg variants [19:54:34 CET] <nevcairiel> if anyone cares, vs2015 update 1 final is available now [19:57:39 CET] <wm4> are there release notes or anything somewhere? interested about the supposed clang stuff [19:58:09 CET] <nevcairiel> thats not part of the update, but an extra addon, didnt find that one yet [19:58:19 CET] <Plorkyeran> there will probably be a blog post up today at http://blogs.msdn.com/b/vcblog/ [19:58:25 CET] <Plorkyeran> with more useful information than the marketing stuff [19:58:57 CET] <nevcairiel> another interesting feature is that VS can now talk to GDB and play debugging frontend with GDB as a backend [19:59:13 CET] <nevcairiel> breakpoints, memory inpsection, et al [20:00:10 CET] <nevcairiel> also, there is a tool now to only install the compiler and sdk without the IDE [20:00:22 CET] <nevcairiel> which might be useful for build systems or wine setups [20:10:32 CET] <Daemon404> nevcairiel, im one of those freaks that only uses the ide for debugging [20:10:40 CET] <Daemon404> and cl.exe directly [20:12:29 CET] <nevcairiel> my fate box would've probably used such a tool [20:12:33 CET] <nevcairiel> but alas its already setup now [20:13:01 CET] <Plorkyeran> should make it easier to update to newer versions, though [20:13:19 CET] <Daemon404> ... can you actually uninstall now? [20:23:29 CET] <Plorkyeran> the toolchain-only version should be uninstallable [20:23:43 CET] <Plorkyeran> since it doesn't have all the extra crap [20:23:55 CET] <Daemon404> hmmm [20:24:12 CET] <Plorkyeran> and they're switching to sqlite for intellisense etc. [20:24:21 CET] <nevcairiel> that reminds me to t urn on that option [20:24:24 CET] <nevcairiel> its apparently much faster [20:24:24 CET] <Plorkyeran> so maybe one day in the future there won't be a million sql server things that have to be uninstalled [20:26:00 CET] <BtbN> Doesn't it use an embedded sql express server, unless you explicitly enable a full one? [20:26:10 CET] <nevcairiel> it does [20:26:21 CET] <nevcairiel> but its still installed as a separate thing [20:26:22 CET] <BtbN> So basicaly MS-SQLite [20:26:30 CET] <nevcairiel> and apparently SQLite is faster [20:26:43 CET] <nevcairiel> so they added an option to switch to SQLite in update 1 [20:26:50 CET] <nevcairiel> its still considered experimental, so no default [20:26:54 CET] <nevcairiel> but in the future it may move there [20:43:02 CET] <nevcairiel> ..installing the upgrade takes as long as ever [20:47:45 CET] <jamrial> speaking of compilers, gcc 6 reached stage 3 (feature freeze) and fate passes [20:48:35 CET] <nevcairiel> 5.3 is also scheduled for release this or next week [20:48:38 CET] <nevcairiel> as is binutils 2.26 [20:51:38 CET] <wm4> do they specifically include fate in their tests now, or why is it passing even though it's not even released yet? [20:52:31 CET] <nevcairiel> a bunch of people here test fate on gcc master builds and instantly report breakage, that usually helps [20:54:48 CET] <nevcairiel> there fate box updated, lets see what happens [21:01:56 CET] <jamrial> i'm running a gcc trunk fate box, yeah [22:42:20 CET] <durandal_1707> Is it ok to use complex.h? [22:53:13 CET] <nevcairiel> probably not [22:53:29 CET] <nevcairiel> if you do, add a configure test and dependency and everything [00:00:00 CET] --- Tue Dec 1 2015

1 0

ffmpeg.log.20151130
by burek 01 Dec '15

01 Dec '15

[04:42:29 CET] <pinPoint> does -c copy loosy bitrate on videos? [04:46:00 CET] <Prelude_Zzzzz> hey, anyone know why when i start a stream it starts right but over time the audio/ video starts to drift out of sync ? [04:46:04 CET] <Prelude_Zzzzz> i am using -codec opy [04:46:06 CET] <Prelude_Zzzzz> copy* [04:47:30 CET] <pinPoint> i meant does it copy slightly lossy from original* [04:48:28 CET] <furq> pinPoint: it copies [04:49:23 CET] <furq> it puts the exact same streams in a new container [04:52:04 CET] <pinPoint> furq: but does the stream loosy bitrate? [04:52:52 CET] <furq> no [04:52:54 CET] <furq> that wouldn't be a copy [04:52:58 CET] <pinPoint> i went from what looks like 7900(Duration: 00:10:34.53, start: 0.000000, bitrate: 7980 kb/s) vs Copy (Duration: 00:10:34.60, start: 0.067000, bitrate: 7499 kb/s) [04:53:41 CET] <pinPoint> i'll have another go [04:54:07 CET] <furq> if it's actually lost bitrate then you'll have noticed ffmpeg taking ten times as long to reencode it instead of just copying it [04:54:33 CET] <furq> it will also say in the output [04:55:10 CET] <pinPoint> that is the result of ffprobe. But I will experiment again [04:55:12 CET] <furq> if you muxed it into a different container then i expect one of them is just reporting the bitrate wrongly [04:55:40 CET] <pinPoint> i did not specify containers just -c:v [04:56:11 CET] <pinPoint> ffmpeg -i bbb_sunflower_2160p_30fps_normal.mp4 -c copy -an BBB_COPY_NO_AUDIO.mkv [04:56:18 CET] <pinPoint> yeah I changed container.... heehhe [05:43:58 CET] <pinPoint> still getting that 7498 kb/s [05:44:08 CET] <pinPoint> ffmpeg -i bbb_sunflower_2160p_30fps_normal.mp4 -c copy -flags global_header -an BBB_COPY_NO_AUDIO.mp4 [05:47:50 CET] <furq> "Duration: 00:10:34.53, start: 0.000000, bitrate: 7980 kb/s" is the description of the whole file, not just the video stream [05:49:06 CET] <furq> the video stream bitrate will be in the line starting with "Stream #0:0" [05:49:21 CET] <furq> depending on the container [06:44:56 CET] <pinPoint> ah [06:45:03 CET] <pinPoint> it was missing the audio i see. ok [13:36:41 CET] <Kwoth> Hello, im trying to decode a video by writing bytes to the input stream of ffmpeg process in C#. [13:37:20 CET] <Kwoth> By using the bytes i got and writing them to file, and afterwards making ffmpeg read from them, i get it to work. The problem is using bytes directly to supply ffmpeg. [13:37:31 CET] <Kwoth> https://gist.github.com/Kwoth/2d5cf0301b533b647d01 this is what i try to do [14:09:28 CET] <dantti> how can I debug avcodec_find_encoder(AV_CODEC_ID_H264); not finding the encoder? I have built with both --enable-libx264 and --enable-encoder=libx264 flags but I'm out of ideas ... [14:13:24 CET] <durandal_1707> have you registered all codecs? [14:13:56 CET] <dantti> how do you mean? [14:15:06 CET] <dantti> actually I think it linked against libx264.so instead of .a and when deployed on android it might have failed to load the .so, now I removed the libx264.so and ffmpeg configure does not find libx264 anymore :P [14:15:06 CET] <durandal_1707> there is function [14:15:37 CET] <dantti> durandal_1707: I'm trying to follow the encoders example [14:15:46 CET] <dantti> didn't see such function [14:16:07 CET] <dantti> duh! [14:16:24 CET] <dantti> I missed avcodec_register_all(); :P [14:16:53 CET] <dantti> still if the .so of lib264 is available it seems to link to it, so it might fail I guess [14:32:54 CET] <Mavrik> dantti, did you load the x264 so_ [14:32:55 CET] <Mavrik> ? [14:33:31 CET] <dantti> I was trying to static link everything [14:33:53 CET] <dantti> now I get undefined refs.. to x264 calls [14:34:19 CET] <Mavrik> Did you compile x264 for Android as well? [14:34:22 CET] <dantti> yup [14:34:28 CET] <Mavrik> Also why aren't you using MediaCodec? :) [14:34:34 CET] <dantti> I was even calling it directly [14:34:39 CET] <dantti> what's it? [14:37:33 CET] <Mavrik> Interface to the device hardware H.264 encoder. [14:37:42 CET] <dantti> Mavrik: can't that be used to generate a mpegts stream? [14:37:46 CET] <Mavrik> x264 will be very very slow on those ARMs :/ [14:38:00 CET] <Mavrik> Those are two different things. [14:38:16 CET] <dantti> yup, it's the muxer part right? [14:38:19 CET] <Mavrik> You can use MediaCodec to encode AAC / H.264 and then use something else to mux it into MPEG-TS. [14:38:24 CET] <Mavrik> Mhm :) [14:38:38 CET] <Mavrik> It's true that Android doesn't include a MPEG-TS muxer. [14:38:54 CET] <Mavrik> But I'm just trying to warn you about the x264 performance - a 5 sec clip at 720p took up to 30s or more to encode on most Android devices. [14:39:24 CET] <dantti> sure, I had to reduce image quality to not drop frames [14:39:46 CET] <BtbN> You will also drain the battery. [14:39:50 CET] <dantti> I guess I need to learn how to call java code... [14:40:23 CET] <Mavrik> On the other hand, the HW video encoder quality is significantly worse. [14:40:41 CET] <Mavrik> You need to encode at 5Mbit what x264 would easily do in 1,5Mbit :) [14:41:48 CET] <dantti> the problem is also writing java code is boring... [14:42:16 CET] <dantti> BtbN: for the baterry the app is on a always on tablet so no issue there [14:42:31 CET] <Prelude_Zzzzz> good morning everyone.. running CentOS Linux 7 (Core) ... using nvenc for encoding .. when i turn up an encoding session i start seeing errors like " http://pastebin.com/G0hcWZwG ".. also i see a bunch of pixelation on the screen. Anyone know why ? Cpu's dont' look like they are doing much but it is as if there some sort of limitation that is causing these errors. [14:43:35 CET] <BtbN> Those are decoder errors, your source is already broken. [14:44:35 CET] <dantti> Mavrik: I can use more cores also to improve performance? of for muxing in mpegts it wouldn't work? [14:45:07 CET] <Mavrik> x264 will use as much cores as it can get, muxing itself isn't really expensive CPU-wise [14:45:22 CET] <Mavrik> the video encode takes a huge chunk of CPU [14:45:59 CET] <dantti> ok I was asking because when I called x264 directly I was wondering how to distribute frames to encode and still get them at the right order [14:46:22 CET] <dantti> as the call was blocking I didn't know how it worked [14:46:51 CET] <Mavrik> hmm, x264 should return frames in DTS order always [14:47:10 CET] <Mavrik> but ordering the frames is why DTS timestamp exists on them :) [14:47:35 CET] <Prelude_Zzzzz> BtbN , i am using another encoder ( elemental ) and it seems to be outputing correctly from the same source. :( .. only ffmpeg does this [14:48:09 CET] <Prelude_Zzzzz> i am trying to replace it with nvenc as it is more effecient but.... any way to correct some of these errors ? [14:48:19 CET] <BtbN> This is not related to the ffmpeg encoder at all, those happen wile ffmpeg is unpacking and decoding the h264 input. [14:48:24 CET] <dantti> right I guess what I mean was how to give more frames as the encode function blocked, I wasn't sure If I'd need to create more thread by myself [14:55:18 CET] <Prelude_Zzzzz> anyone know a good decoding filter that can help me get rid of those errors ? not sure which ones to use [15:03:30 CET] <Prelude_Zzzzz> BtbN ? can you please help me point in the right direction.. i am stuck :( [15:03:36 CET] <Prelude_Zzzzz> you usually pretty good .. [15:03:39 CET] <NoviceAlpha2> Hi all :) [15:04:04 CET] <BtbN> Your source gives you a broken stream, fix your source. [15:04:27 CET] <Prelude_Zzzzz> i can't fix it.. comes from satelite carrier [15:04:37 CET] <Prelude_Zzzzz> and i am using an elemental encoder and i have no errors [15:04:47 CET] <Prelude_Zzzzz> but with ffmpeg .. it acts up a lot [15:05:13 CET] <BtbN> Sounds like terrible signal quality. [15:05:21 CET] <Prelude_Zzzzz> well its 720p but.. [15:05:27 CET] <Prelude_Zzzzz> actually its 1080i [15:06:25 CET] <NoviceAlpha2> Hope you can help me out, Does any one know what is this error means? ERROR: librtmp not found using pkg-config basically librtmp.so is saying is missing but its there. i have even build it from fresh again and still wont go any futher, openssl its built from source, rtmpdump too, but have problems with ffmpeg, can i count on your help anyone? [15:06:52 CET] <Prelude_Zzzzz> or 720p .. depending.. we are taking the system from sat... outputing to UDP .. then taking that and transcoding it.. works fine on the other encoder and i am sure there are errors there too but at least the other encoder handles it well.. not sure how [15:07:03 CET] <Prelude_Zzzzz> maybe there is some decode filter that is being used that cleans it up and then it doesn't mess up the output [15:07:13 CET] <Prelude_Zzzzz> i dont know what filter to use :( [15:09:09 CET] <BtbN> There is no filter that magicaly fixes a broken stream [15:09:56 CET] <Prelude_Zzzzz> ya i know.. but the output is there.. but i see pixelation like weather related issues or something .. i don't see it on the other encoder ( same exact source ) [15:10:33 CET] <Prelude_Zzzzz> also. if i do 1 encode at a time it seems to be a lot better.. soon as i start pushing the server a bit it seems to act up more .. like cpu power but i am not using any cpu .. very very strange [15:16:42 CET] <c_14> NoviceAlpha2: upload your config.log to a pastebin service and link here please [15:22:07 CET] <Prelude_Zzzzz> BtbN .. i think this is something to do with some processing power or something.. so i encoded 1 time... no issues and no errors.. i add 4 simultanious encodings and i get errors flying on the screen.. like cpu can't keep up and causes errors.. [15:22:19 CET] <Prelude_Zzzzz> but.. cpu's don't look like they are doing much.. i don't get it [15:28:36 CET] <NoviceAlpha2> c_14: i am trying to change path's to toolchains, sdk, and libs, give me 5 min will see if script might be corrupted, im using oryginals from Compilation Guide Compile ffmpeg for Android with rtmp git clone. 1 min please [15:36:05 CET] <NoviceAlpha2> c_14: there is pastebin link, http://pastebin.com/GQBUaHsN [15:38:16 CET] <c_14> NoviceAlpha2: not build.log, ffmpeg's config.log. Should be in the ffmpeg source directory [15:39:36 CET] <NoviceAlpha2> c_14, will do 1 sec. [15:40:05 CET] <c_14> You probably just have to set PKG_CONFIG_PATH to "/home/test/android-ffmpeg-with-rtmp/src/rtmpdump/librtmp/android/arm"/lib/pkgconfig though [15:41:08 CET] <NoviceAlpha2> c_14: http://pastebin.com/H9jW1q4W [15:41:26 CET] <c_14> Package 'libssl', required by 'librtmp', not found [15:43:52 CET] <NoviceAlpha2> c_14: thanks i did not knew that config.log is there, ok will try to apply missed liblaries, thanks a lot [15:49:37 CET] <Prelude_Zzzzz> hey i may be onto something here.... source is h264 already.... i am doing " ${ffmpeg} -y -i "$stream" -c copy -map 0:p:$6 -f mpegts - | tee .... " what should i use instead of mpegts so i dont convert .. i just want to pass on to the tee to have the other stuff encode it [15:50:43 CET] <yongyung> Does someone here have experience with sony vegas? Or do you guys know a channel for sony vegas questions? [15:50:54 CET] <Prelude_Zzzzz> rawvideo !!! [15:52:29 CET] <DHE> mpegts is a container. if you used -c copy then it doesn't matter what you specify with -f (as long as it's acceptable for h264) [15:59:42 CET] <Prelude_Zzzzz> oh.. then my problem is not solved [15:59:43 CET] <Prelude_Zzzzz> :( [16:00:00 CET] <Prelude_Zzzzz> basically just want to output the input and tee it off to multiple processes :( [16:07:39 CET] <yongyung> Do you guys think there would be any visible difference between tga -> libx264 crf 4 -> editing/lossless .avi -> libx264 crf 18 and changing crf 4 to crf 16 in the first step? [16:18:49 CET] <DHE> it'd be pretty hard for a human eye to notice without frame-stepping the video. but it could be [16:19:03 CET] <DHE> but during high motion scenes it's far more likely [16:19:48 CET] <kepstin_> if you view the high-motion scenes in slow motion or frame-by-frame, at least :) [16:20:38 CET] <DHE> if you want constant quality, you use -qp instead. Using -crf will still reduce the image quality for high motion [16:26:46 CET] <kepstin_> of course, if you have the disk space and bandwidth, you could just skip the first x264 encode and put it right into the lossless format for editing... [16:29:24 CET] <DHE> well if there is an intermediate lossless step then it should be... [16:35:20 CET] <yongyung> kepstin_: The problem is that the vegas preview starts lagging horribly with crf 4 already, with crf 16 it's fine. [16:35:51 CET] <yongyung> DHE: I thought crf is already a variable bit rate/constant quality? It doesn't work the same as -qp? [16:36:42 CET] <kepstin_> crf is approximately constant visual quality (uses psy optimizations) when played back realtime [16:39:45 CET] <kepstin_> -qp is static quantizer, which means constant mathematical quality (this isn't exactly true, since there's still boosting on keyframes, etc) - but it's not really constant visual quality to a human viewer. [16:40:07 CET] <kepstin_> close tho [16:42:31 CET] <yongyung> Hmmm, I guess crf still makes more sense then^^ [16:43:19 CET] <kepstin_> keep in mind that the psy optimizations in crf mode are explicitly designed to remove data that might not be noticed in the video as it currently is. [16:43:30 CET] <kepstin_> if you're doing editing afterwards, that probably doesn't make sense [16:44:32 CET] <yongyung> Hmm yeah maybe. Does -preset still work the same way with -qp? [16:50:26 CET] <yongyung> Maybe -tune fastdecode would help, too [17:03:11 CET] <yongyung> qp 12 and fastdecode seem to work fine, preview is like 20 fps but that's enough for editing^^ [17:10:44 CET] <hanDerPeder> hi, does ffmpeg support googles tinyalsa as an replacement for alsa? [17:11:45 CET] <hanDerPeder> refering to the alsa capture device support in libavdevice [17:17:15 CET] <durandal_1707> Afaik no [17:26:10 CET] <hanDerPeder> the encoder/decoder files for alsa doesn't seem too intimidating, might be I can implement a tinyalsa device. has this been attempted? [17:29:05 CET] <prelude2004c> hey guys.. question.. i have a transport stream with many program ID's [17:29:40 CET] <prelude2004c> on of with is program 1895 for example.. i use " -map 0:p:1895 " to pull that out .. problem is the stram 0:19 ( video ) and the audio streams keep changing [17:30:23 CET] <prelude2004c> how do i map all the audio i want while the stream keeps changing [17:30:30 CET] <prelude2004c> can i somehow select the " 0x1511 " [17:31:41 CET] <debianuser> hanDerPeder: As I understand both alsa-lib and tinyalsa are just libraries providing an API to talk to alsa kernel drivers. So wherever tinyalsa works - alsa-lib should work too. [18:06:52 CET] <prelude2004c> hey anyone know how to select streamid hex inside a transport stream program id ? [18:07:17 CET] <prelude2004c> eg.. --map 0:p:$programid .. then -map 0xxxxx 0x2222 etc etc.. for the actual stuff i want from that program ID [18:11:52 CET] <c_14> prelude2004c: https://ffmpeg.org/ffmpeg.html#Stream-selection [18:24:15 CET] <autofsckk> hello, first of all thanks for this incredible application, its fantastic, i've been experimenting a bit with it and its great [18:24:57 CET] <prelude2004c> hey, can someone help with with this >>> http://pastebin.com/qSCgYKDm [18:25:03 CET] <prelude2004c> i am doing something wrong [18:25:07 CET] <autofsckk> by any chance is there a site or blog or something showing some cool tricks with it? [18:29:34 CET] <DHE> the trac web site has a couple of things strewn across various pages, from encoding tips/tricks to hard-to-use features to visualizing the video encoding itself [18:35:12 CET] <autofsckk> DHE -> thanks, one more question, in the command line how is the presedence of the commands considered? i am taking like 10s from a video-resize it and convert it to animated gif, that is done perfectly but now i tried to flip the gif horizontally, so i added -vf "hflip" just before the output name of the gif, but now it did something totally different, it didnt resize de video, showed just a part of i [18:35:18 CET] <autofsckk> t and made a lot much bigger file, ... [18:35:21 CET] <autofsckk> ... from 2.3M to 16M [18:37:40 CET] <DHE> the format of options are: ffmpeg [input1 options] -i input1 [[input2 options] -i input2 ...] [output1 options] output1 [[output2options] output2 ...] [18:38:01 CET] <c_14> prelude2004c: 0:p:1895:0 and 0:p:1895:1 afaik [18:38:29 CET] <DHE> now I'm not 100% sure but using -s will result in a scale filter being used to resize the video. maybe mixing -vf (manual video filters) affected that [18:38:37 CET] <autofsckk> http://pastie.org/10592871 [18:38:55 CET] <DHE> ah... yeah, chain your filters together. [18:39:04 CET] <DHE> -vf scale=600:-1,hflip [18:39:45 CET] <autofsckk> i see, i just c&p and didnt see that im repeiting -vf , so dumb, thanks man [18:42:07 CET] <dantti> libavcodec.a has x264_picture_init Undefined, if the link is static shouldn't it be defined? [18:44:09 CET] <DHE> libx264 needs to be linked as well [18:46:08 CET] <dantti> DHE: on my app? [18:47:06 CET] <dantti> if so I did that, actually I can get rid of undef symbol if I call the function in my app, but then there is another 10 calls to x264 lib [18:49:19 CET] <DHE> I'm saying x264_* functions require linking to libx264 [18:55:10 CET] <dantti> it's a static build I'd think that if libavcodec.a compiles fine it got linked but when I try to link to it I get the undef for libx264 [18:55:39 CET] <kepstin> dantti: yeah, because you have to also link to libx264 to pull in the code for it. [18:55:39 CET] <furq> dantti: -Wl,--whole-archive [18:56:26 CET] <furq> static libraries don't link anything, they're just an archive of object files [18:57:15 CET] <dantti> furq: that's probably why ldd doesn't return a link list as does .so file :P I add that to --extra-ldflags right? [18:57:24 CET] <kepstin> and static libraries don't know anything about dependencies, so you have to specify all of them during the final link. it's not like dynamic libs where linking to one pulls in its dependencies automatically. [18:57:50 CET] <furq> -Wl,--whole-archive -lx264 -Wl,--no-whole-archive [18:58:16 CET] <furq> when compiling your app [18:58:45 CET] <dantti> ok, I thought it would be when compiling ffmpeg [18:59:07 CET] <dantti> I have -lx264 in my app just not this (no)-whole-archive [18:59:15 CET] <dantti> btw don't they conflict? [18:59:17 CET] <kepstin> I don't think you need the whole-archive stuff, just putting -lx264 after the libav* libraries should be sufficient for the linker to pull in the needed stuff. [18:59:21 CET] <furq> no [18:59:35 CET] <furq> whole-archive applies to all static libraries until the next no-whole-archive [18:59:41 CET] <furq> kepstin might be right though [18:59:47 CET] <kepstin> with static archives, the order of linking is important :/ [18:59:50 CET] <dantti> must be after? I noticed that ffmpeg *.a need a right order [19:00:31 CET] <furq> it's been a while since i linked anything with static libraries because stuff like this happens [19:02:10 CET] <prelude2004c> hey ,can anyone point me in the right direction >> http://pastebin.com/qSCgYKDm [19:03:27 CET] <kepstin> what gets really fun is when you have two static libraries that use functions from each-other. e.g. if liba uses a function from libb and vice-verse. Then the correct link command is "-la -lb -la" :/ [19:03:36 CET] <kepstin> (or use -Wl,--whole-archive) [19:04:35 CET] <furq> surely the first item in the correct link order is "go back and make them shared libraries you fool" [19:05:03 CET] <dantti> kepstin: oh, I was trying to do something like that a while ago [19:05:12 CET] <dantti> decided to merge the two :P [19:06:23 CET] <kepstin> basically, the way it works is that the linker has a list of symbols in the program that it's missing the code for. Each time you pass a -l option with a static archive, it looks in that archive, and pulls in the functions that satisfy missing symbols. Then, after that, it adds any new missing symbols from the new functions to its list, and goes on to the [19:06:23 CET] <kepstin> next library. [19:07:53 CET] <kepstin> what the "whole archive" option does is makes it copy *all* of the functions from the static archive into the program, instead of only the functions that satisfy missing symbols. [19:07:54 CET] <dantti> so the -la -lb -la is just for a "second scan" of missing symbols right? [19:08:07 CET] <kepstin> yeah [19:09:04 CET] <dantti> yay, it compiled now let's see find_codec works on android this time :P [19:11:04 CET] <dantti> great, I can now start coding :P [19:11:07 CET] <dantti> thanks [19:28:40 CET] <prelude2004c> anyone have a sec to help me with a map function ? [19:30:04 CET] <prelude2004c> Stream #0:12[0x1511] the stream 0:12 keeps changing everytime i run it.. but the 0x1511 always maintains [19:30:21 CET] <prelude2004c> how do i use a selection based on the " 0x1511 " [21:06:02 CET] <autofsckk> im reading the -ss input/output and i dont understand really what the difference is, or when to use one or the other, for what i understand its better and faster to use input right? before the -i ? [21:16:17 CET] <ChocolateArmpits> autofsckk: before input the seeking is done via demuxer, before ouptut the seeking is done via decoder (I think). anyways, The latter is more accurate, but you lose speed. [21:17:41 CET] <autofsckk> ok ,thanks for the explanation, i dont know what demuxer and decoder are, well i have an idea but im really new at video editing, ill look about it thanks again [21:18:26 CET] <ChocolateArmpits> autofsckk: demuxer helps you get the video/audio stream contained in a file. Decoder does decoding of the coded video/audio stream [21:19:42 CET] <autofsckk> ok, thanks [21:38:06 CET] <cbsrobot-> anyone knows a tools that prints dolby leq(m) loudness ? [21:48:57 CET] <kepstin> autofsckk: basically, when -ss is an input option, ffmpeg tries to jump to the correct spot in the file and starts decoding there. When -ss is an output option, ffmpeg decodes the entire file from the start, but just throws out frames until it gets to the spot you wanted. [22:33:29 CET] <Polochon_street> Hi! I'm building a music analyzer, but I totally forgot about the floating-points formats in my decoding process. Is is really dirty to get floats in a temporary variable, like this v = ((float*)decoded_frame->extended_data[0])[i];, and then multiply it by max_in16_t, so that I can work with a « normal » s16 array? [22:35:49 CET] <JEEB> lossy audio in general is natively float, and only those formats by default get float output [22:35:54 CET] <kepstin> heh, i think it's more common for people to convert the int formats to floating format as a working format rather than the other way around. [22:36:16 CET] <JEEB> there is avresample and swresample to convert float outputs to integer if you require that [22:36:27 CET] <fritsch> take great care one is 32 bit and the other is a signed 16 bit [22:36:51 CET] <Primer> Hi, are -probesize and -analyzeduration the only ways to reduce startup latency when re-streaming via ffmpeg? I'm using filter_complex to turn 6 security cameras from a black box DVR that streams via rtsp and piping that to mpv to view locally [22:36:52 CET] <fritsch> use swresample to produce your target format [22:36:56 CET] <JEEB> the decoders themselves output whatever is native to them, basically [22:37:15 CET] <Primer> Is there no way to specify the parameters that the source streams use beforehand? [22:37:22 CET] <JEEB> what [22:37:26 CET] <JEEB> oh [22:37:29 CET] <JEEB> go on [22:37:31 CET] <ChocolateArmpits> Primer: you can try the buffer "reduction" settings, like nobuffer [22:37:39 CET] <Polochon_street> okay, so you suggest that I look into swresample? [22:37:41 CET] <Gunni> hey, i am trying to remove an audio channel from a dual audio video file, the original sounds fine but when i use the following command the audio goes severely out of sync -- ffmpeg -i in.avi -map 0:0 -map 0:2 -acodec copy -vcodec copy out.avi [22:37:44 CET] <ChocolateArmpits> I'm not sure how well that works [22:37:49 CET] <Polochon_street> wouldn't it be a loss in term of performance? [22:38:06 CET] <Primer> ChocolateArmpits: Well, I'm getting this: [cache] Cache is not responding - slow/stuck network connection? [22:38:17 CET] <JEEB> well optimized resampling is going to be quicker than unoptimized (if you require resampling) [22:38:19 CET] <Primer> Which lead me to looking at options to disable any form of caching [22:38:40 CET] <JEEB> there are two APIs with similar APIs (av|sw)resample available in FFmpeg, feel free to pick your poison [22:38:44 CET] <kepstin> Polochon_street: swresample is a pretty well optimized chunk of code; you'd use it to convert a whole buffer at a time between formats. [22:38:56 CET] <Polochon_street> okay, I trust you, thanks very much! :) [22:39:35 CET] <JEEB> basically you are going to get integer based output for lossless formats generally, while for lossy you are going to be getting floats [22:40:24 CET] <JEEB> or well, for lossless you are going to get whatever there was in the input [22:42:06 CET] <Polochon_street> yep, I only use lossless formats, and when someone tested what I wrote with a .mp3 well... It broke everything [22:42:16 CET] <Polochon_street> I'll be more cautious next time! [22:42:36 CET] <Gunni> can anyone help me with my audio sync issue? [22:43:46 CET] <Primer> I see no such option as nobuffer...unless you mean mvp [22:44:20 CET] <Primer> I've been messing with -probesize and that's made the video start much more quickly than without it [22:44:39 CET] <Primer> but ffmpeg is still reading each source stream in sequence [22:45:19 CET] <Primer> well, it _seems_ it's reading them sequentially [22:45:47 CET] <ChocolateArmpits> Primer: -fflags nobuffer [22:45:51 CET] <ChocolateArmpits> it's an input flag [22:46:17 CET] <ChocolateArmpits> https://www.ffmpeg.org/ffmpeg-formats.html#Format-Options [22:47:16 CET] <Primer> Anyhow, this is what I'm doing: http://ix.io/mzg [22:48:32 CET] <Primer> It's taking about 5-6 seconds before it appears [22:48:50 CET] <Primer> and I'm trying to get that down to as little as possible [22:49:04 CET] <ChocolateArmpits> then reduce analyzeduration [22:50:11 CET] <ChocolateArmpits> try something like 500 000 microseconds, which would be half second [22:50:29 CET] <ChocolateArmpits> lower it until ffmpeg process input anymore [22:50:33 CET] <ChocolateArmpits> can't* [22:51:21 CET] <Primer> The output from ffmpeg suggests it's reading each source sequentially. I don't suppose there's a way to make that concurrent? [22:52:16 CET] <Primer> Also, if the source is consistent, can't the source "attributes" (the things probing and analyzing are looking for) be specified beforehand? [22:52:55 CET] <ChocolateArmpits> I would guess the input are analyzed parallelly, but I'm not sure [22:53:10 CET] <ChocolateArmpits> you can specify framerate, format [22:53:25 CET] <ChocolateArmpits> again, I can't say if this will speed up the analysis [22:53:39 CET] <ChocolateArmpits> you can specifiy resolution and pixel format too [22:54:08 CET] <ChocolateArmpits> anyways start with analyzeduration [22:54:29 CET] <ChocolateArmpits> if there really are latency problems this is a definit setting that can change that [22:54:35 CET] <Primer> I set that to 0. The stream continues to work, but there's no appreciable speed up [22:55:08 CET] <ChocolateArmpits> ok try with one input [22:55:09 CET] <Primer> Well, I'm remote from the source at the moment, but I'm using the same script when I'm not [22:55:15 CET] <ChocolateArmpits> and don't set something to 0 [22:55:24 CET] <Primer> which is then on a local gigabit network [22:56:01 CET] <kepstin> default for -analyzeduration is 0... I wonder if that has the effect of 'unlimited'. [22:56:08 CET] <Primer> right [22:56:22 CET] <ChocolateArmpits> set it to a sensible value [22:56:28 CET] <ChocolateArmpits> as I said 500000 [22:57:15 CET] <Primer> yup, tried that, no difference [22:57:27 CET] <ChocolateArmpits> Primer: for all the inputs ,right ? [22:57:33 CET] <Primer> piping ffmpeg | mvp is hosing the terminal [22:57:34 CET] <Primer> yes [22:57:47 CET] <Primer> http://ix.io/mzh [22:58:13 CET] <Primer> Is the latest version [22:58:31 CET] <ChocolateArmpits> you should not be using probesize when using analyzeduration. The idea behind them is the same, but you either alter seconds or bytes [22:58:48 CET] <Primer> ahh [22:59:01 CET] <ChocolateArmpits> basically pick one depending on your situation [23:00:22 CET] <ChocolateArmpits> also mpv may have it's own buffer, see if you can reduce it there. Or just use ffplay and transplant latency reduction settings there [23:01:40 CET] <Primer> ffplay chokes on this [23:01:42 CET] <Primer> err [23:01:43 CET] <Primer> no [23:01:56 CET] <Primer> its fullscreen option is real full screen [23:02:01 CET] <Primer> not a borderless window [23:02:11 CET] <Primer> which is totally unacceptable [23:02:12 CET] <ChocolateArmpits> is that even an issue? [23:02:16 CET] <Primer> yes [23:02:22 CET] <Primer> I have 4 displays [23:02:24 CET] <ChocolateArmpits> afterall you're testing for latency and not for preview [23:02:48 CET] <Primer> and the displays flicker on and off for several seconds while going real full screen [23:03:15 CET] <ChocolateArmpits> is the latency present when you only have one of the inputs passed ? [23:03:51 CET] <Primer> yeah, -analyzeduration 500000 just goes back to taking forever for each stream [23:03:58 CET] <Primer> which is being handles sequentially, for sure [23:04:23 CET] <Primer> Not sure what you mean [23:04:41 CET] <ChocolateArmpits> when you only have one single input, rather than all of the them [23:05:03 CET] <ChocolateArmpits> can you "ffplay rtsp..." ? [23:05:12 CET] <ChocolateArmpits> and check what's the latency with just one of them [23:05:23 CET] <ChocolateArmpits> without all the added filter processing [23:06:15 CET] <Primer> seems ffplay is a separate package [23:06:43 CET] <Primer> but if I use mpv with just the rtsp url it takes several seconds [23:07:19 CET] <Primer> I have ffmpeg installed as a package (Linux Mint 17) but I compiled it myself. Not sure if ffplay was a separate package [23:07:54 CET] <JEEB> mpv has options to set libavformat parameters [23:08:00 CET] <JEEB> see the documentation or poke #mpv [23:08:19 CET] <JEEB> at least I remember it having a way to pass lavf parameters :P [23:08:24 CET] <Primer> vlc URL == 1-2 seconds [23:08:36 CET] <Primer> from hitting enter to where I see output [23:08:54 CET] <JEEB> because it doesn't use libavformat? [23:09:00 CET] <JEEB> at least for most formats, by default [23:09:18 CET] <JEEB> you can make it use by switching the demuxer on command line [23:09:49 CET] <Primer> not sure if mplayer is even relevant any more, but it just chokes [23:10:03 CET] <JEEB> it's barely being maintained by a guy or so [23:10:37 CET] <Primer> probesize seems to be the most effective argument so far [23:11:17 CET] <JEEB> https://mpv.io/manual/master/#options-demuxer-lavf-o [23:11:19 CET] <Primer> So going back to the entire reason for probesize and analyzeduration...can I not just specify these things? [23:11:21 CET] <JEEB> or heck [23:11:33 CET] <JEEB> mpv has demuxer-lavf-probesize [23:11:40 CET] <Primer> Because the source format/framerate/etc. is not going to change [23:11:43 CET] <JEEB> and demuxer-lavf-analyzeduration [23:11:57 CET] <JEEB> some of the things can be defined, yes. some can't [23:12:03 CET] <JEEB> at least not on command line :P [23:12:27 CET] <Primer> Well, the sources are all from the same device, so they'll all be identical, which the exception of stream 1 having audio [23:12:34 CET] <Primer> and the others having none [23:13:12 CET] <Primer> As far as duration, they're never ending streams, so... [23:13:33 CET] <Primer> All that remains are...transport, codecs, bitrates? [23:13:58 CET] <JEEB> well you can set the format at least, and the decoder. it will still have some parsing requirements [23:14:04 CET] <JEEB> format as in the container [23:14:47 CET] <Primer> I also have this: [nut @ 0x29a0ca0] Non-monotonous DTS in output stream 0:1; previous: 51611, current: 51608; changing to 51612. This may result in incorrect timestamps in the output file. [23:15:06 CET] <Primer> This seems to cause camera 1, the one with the audio, to lag behind the other 5 [23:15:23 CET] <Primer> video lag, that is [23:19:03 CET] <Primer> Anyhow, I'm very satisfied with this as it stands right now. Just trying to refine it as best as I can. [23:19:37 CET] <JEEB> well, did you try poking at the mpv options I noted? [23:19:38 CET] <Primer> At home I'm running a 50' HDMI cable from the device to the TV in my living room. The direct output from the device is real time [23:20:12 CET] <Primer> I have not, but from what I can tell it seems the majority of the the delay is happening on the ffmpeg side [23:20:13 CET] <JEEB> basically analyzeduration and probesize and you can define the container [23:20:26 CET] <JEEB> well those settings control libavformat... [23:20:32 CET] <JEEB> which is why I noted them from the goddamn manual [23:20:42 CET] <Primer> Pardon my ignorance, but how would I determine the container? The presume it's in the output? [23:21:12 CET] <JEEB> container is called "format" in ffmpegspeak [23:21:24 CET] <JEEB> I see nut mentioned in that one line you quoted, for example [23:21:39 CET] <JEEB> in ffmpeg it's around the "Input 0/1 things :P" [23:22:44 CET] <Primer> well, nut is what I'm using for output [23:23:03 CET] <JEEB> well then you define that in the reading side [23:25:11 CET] <Primer> sure [23:25:41 CET] <Primer> The sequence of events have lead me to try to speed up the ffmpeg side of things first though [23:26:14 CET] <Primer> initially without probesize, I'd see the output from the first stream take several seconds [23:26:35 CET] <Primer> again for the next, next, etc, then after a good 20-25 seconds, the video would appear [23:26:59 CET] <Primer> now with -probesize on the ffmpeg side, each video's output happens in about 1 second [23:27:16 CET] <Primer> http://ix.io/mzl [23:27:21 CET] <Primer> that's the output [23:27:33 CET] <Primer> redacted to remove the private parts [23:28:49 CET] <Primer> So I type ./ffmpeg.sh, hit enter, a chunk of text appears from reading the first stream in the first second, then the next check the second after that, etc. etc...6 seconds after hitting enter, the video appears [23:29:11 CET] <kepstin> yeah, the ffmpeg tool sequentially probes each input in order before setting up the filters and outputs. No real way around that. [23:29:27 CET] <Primer> I was hoping there was a way to do that concurrently [23:30:03 CET] <Primer> but I'd settle for speeding up the "probing" by specifying all parameters beforehand, considering the stream parameters (attributes, whatever) won't ever change [23:30:49 CET] <Primer> And I suppose I'd also try speeding up the mpv end as well by specifying [23:31:11 CET] <Primer> thing is, that's entirely local, so I figure that's already pretty optimal [23:31:26 CET] <Primer> the mpv end, that is, since I'm piping to it [23:31:31 CET] <kepstin> I wonder if predownloading the sdp to files and passing those to ffmpeg might help [23:31:41 CET] <kepstin> since it's the sdp that has all the connection setup stuff [23:32:14 CET] <kepstin> hmm, but I guess rtsp does more than that :/ [23:33:01 CET] <kepstin> tbh, if you want 0 setup time, directly using rtp with the server sending to statically configured addresses/ports would do it. [23:35:11 CET] <kepstin> I suspect that most of the per-stream setup time is the rtsp negotiation, rather than any stream probing. [23:45:18 CET] <kepstin> if you have to stick with rtsp, it might be that the best option is to set up the rtsp connections in an external app (in parallel), write the sdp to disk, then start up ffmpeg with the sdp. [23:45:28 CET] <Primer> yeah, it's a black box [23:46:05 CET] <Primer> I know it's running Linux and the telnet port is open, but I haven't looked into hacking it [23:46:14 CET] <Primer> I'm guessing it's using hardware encoders too [23:46:28 CET] <Primer> since the PC board on it is minimal [23:46:47 CET] <kepstin> the sdp would contain all the codec and format information, so in that case ffmpeg is basically just opening some udp ports for the rtp/rtcp and getting on with it. [00:00:00 CET] --- Tue Dec 1 2015

1 0