Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

September 2017

1 participants
60 discussions

ffmpeg-devel.log.20170919
by burek 20 Sep '17

20 Sep '17

[00:18:33 CEST] <loudmax> Hi, may I ask some questions about big endian mips? [00:21:35 CEST] <iive> go ahead and ask. getting answer is whole another thing :D [00:22:51 CEST] <loudmax> IŽm working at the high bit depth support for interlace filters [00:23:19 CEST] <loudmax> fate test failed for be [00:24:11 CEST] <loudmax> I need to test on be mips, but IŽm not able to make the compiler work [00:24:47 CEST] <loudmax> I tried on windows, which was a pain in the ass [00:25:02 CEST] <loudmax> now I set up linux and it is the same [00:25:28 CEST] <loudmax> ffmpeg compilation mips help doesnŽt work [00:29:22 CEST] <loudmax> Can anybody explain, how to compile ffmpeg on linux mint for mips and making fate tests with big endian? [00:32:00 CEST] <durandal_170> loudmax: filter nirmally work in native endianes [00:33:27 CEST] <loudmax> ThatŽs what I hoped, but see this: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-September/216392.html [00:41:50 CEST] <wm4> anything with mips will be a PITA [00:42:04 CEST] <wm4> I'm not sure why we try to support anything big endian [00:42:11 CEST] <wm4> it's just a lot of work for practically no gain [00:46:03 CEST] <loudmax> wm4: Is there a way to disable functionality for big endian inside a filter? [00:46:23 CEST] <jamrial> wm4: the same will happen with ppcbe [00:46:53 CEST] <jamrial> loudmax: what you did in your second patch was in the right direction (enabling only the LE variants of the pixfmts) [00:47:30 CEST] <jamrial> you were probably missing adding a bunch of av_le2ne16() to some load and store lines somewhere [00:48:04 CEST] <jamrial> see how other video filters do it [00:48:57 CEST] <loudmax> jamrial: I found your new lut filter patch. Something like that? [00:49:55 CEST] <jamrial> that one removes the ifdeffery. but yes, av_le2ne16() simply expands into av_bswap16() on big endian targets, and does nothing on little endian targets [00:58:31 CEST] <loudmax> jamrial: That would be many av_le2ne16(): [00:58:47 CEST] <loudmax> jamrial: https://thepasteb.in/p/nZhlNkV668GFY [01:01:27 CEST] <jamrial> loudmax: you may not need that many, but in any case i'm not the person to ask about this. durandal_170 and ubitux have actually written filters, unlike me [01:03:50 CEST] <loudmax> durandal_170, ubitux: What do you think? [02:38:27 CEST] <jamrial> loudmax: try this. read pixels with AV_RL16() from both dst and src buffers. use local variables if necessary (when used in more than one calculation or comparison) [02:38:57 CEST] <jamrial> then use AV_WL16() to write to the dst buffer at the end if needed [02:39:14 CEST] <jamrial> look at interpolate_bilinear16() in vf_rotate [02:39:23 CEST] <jamrial> I can't say that will be enough, but it's worth a try [02:43:07 CEST] <jamrial> include libavutil/intreadwrite.h for the above functions [02:47:09 CEST] <loudmax> Okay, I will have a look. Just finished the patches v2 with av_le2ne16(). But I check AV_WL16()... [02:55:31 CEST] <loudmax> jamrial: av_le2ne16() seems to make more sense to me. It leaves the little endian totaly untouched. [02:56:17 CEST] <loudmax> Having said that, I actually donŽt see the big difference [02:57:11 CEST] <loudmax> Both are swapping a single pixel? [03:17:51 CEST] <loudmax> jamrial: Now IŽm again having the problem of not having a big endian system for testing [03:18:49 CEST] <loudmax> I will send my patches with av_le2ne16() to the ML. Maybe Michael can check mips qemu [03:19:39 CEST] <loudmax> Thank you for the hints [03:19:58 CEST] <loudmax> Need to go to bed now. [04:27:54 CEST] <cone-108> ffmpeg 03Henrik Gramner 07master:18821e3ba1ba: x86/exrdsp: optimize ff_reorder_pixels_avx2() [05:29:49 CEST] <kevinn__> Hi! Does anyone have any good examples of decoding x264 buffers with libavcodec? [05:30:07 CEST] <kevinn__> I can't seem to find any nice and simple sample [07:10:00 CEST] <FishPencil> After doing some quick testing it looks like FFmpeg's nlmeans filter is ~5.6x slower than this one: https://github.com/farindk/ffmpeg I know there was talk of having this filter use SIMD, but I don't see any of that in farindk's fork [07:23:18 CEST] <FishPencil> ah looks like there is some SSE2 [13:58:20 CEST] <JEEB> > estimating packet duration for subtitle packets from formats without an end timestamp [13:58:29 CEST] <JEEB> sounds like I will need something heavy... [14:01:40 CEST] <JEEB> rcombs: sounds like the TTML folk just figured all the subtitles for a fragment would be in a single sample :D [14:01:51 CEST] <JEEB> where's my whiskey [14:54:03 CEST] <cone-214> ffmpeg 03Hendrik Leppkes 07master:b4ecf2b582f3: vp9: move VP9SharedContext back to the top of VP9Context [16:54:33 CEST] <durandal_1707> why we have own implementation of strdup? [17:10:02 CEST] <BBB> durandal_1707: because av_strdup is a memory allocator so it needs to use the same allocater as av_malloc [17:10:14 CEST] <BBB> durandal_1707: its stupid but unfortunately necessary [17:10:52 CEST] <BBB> durandal_1707: the alternative is to keep very careful track of using free for strdup and av_free for av_malloc, but thats complicated and sometimes nearly impossible when mixing things [17:13:35 CEST] <wm4> strdup is also not available on every shitty shit we appear to be supporting [21:19:24 CEST] <JEEB> someone either please disagree or take in :) https://patchwork.ffmpeg.org/patch/5148/ [21:19:32 CEST] <JEEB> we've got two people for this now [21:19:41 CEST] <BtbN> Privacy Error! [21:19:50 CEST] <JEEB> youtube spams a lot of that [21:19:51 CEST] <BtbN> You cannot visit patchwork.ffmpeg.org right now because its certificate has been revoked. [21:19:55 CEST] <BtbN> well [21:20:01 CEST] <JEEB> oh [21:20:02 CEST] <JEEB> startcom [21:20:11 CEST] <BtbN> There is also no override option [21:20:14 CEST] <JEEB> my latest beta firefox still trusts startcom o_O [21:20:19 CEST] <JEEB> someone... uhh [21:20:21 CEST] <BtbN> I just plain cannot visit it, at all. [21:20:23 CEST] <JEEB> should switch the CA [21:20:24 CEST] <BtbN> This is stable chrome. [21:20:34 CEST] <JEEB> "GnuTLS: eat PREMATURE_TERMINATION error" [21:20:40 CEST] <JEEB> is the topic [21:20:53 CEST] <nevcairiel> they announced enforcing the revocation with chrome 61 a long time ago [21:20:59 CEST] <JEEB> yea [21:21:06 CEST] <JEEB> I was just surprised mozilla hadn't revoked it yet [21:21:09 CEST] <JEEB> since I'm on the beta [21:21:52 CEST] <BtbN> I stopped caring about Firefox when they announced to turn it into a chrome-clone [21:22:18 CEST] <JEEB> they've done good job lately IMHO [21:22:30 CEST] <BtbN> They are about to kill off pretty much all useful AddOns [21:22:41 CEST] <BtbN> And only allow Chrome-Like Extensions [21:22:59 CEST] <JEEB> well, even with that you can do cool stuff https://addons.mozilla.org/en-US/firefox/addon/multi-account-containers/ [21:23:35 CEST] <JEEB> and out of my daily extensions I'm only going to miss tab groups [21:23:58 CEST] <JEEB> since the developer console's cookie management has gotten good enough I think I don't need Advanced Cookie Manager any more [21:24:00 CEST] <BtbN> LastPass is going to be gimped like it is in Chrome, cliget will be dead, Mouse Geatures will be dead. [21:24:04 CEST] <JEEB> but yes, it'll be painful as hell [21:24:14 CEST] <JEEB> since people are making extensions on their free time [21:24:30 CEST] <BtbN> The new API just does not give that kind of power that those kind of addons need [21:24:32 CEST] <JEEB> and thus when you tell them "pls rewrite" not many will go for it [21:25:02 CEST] <JEEB> BtbN: as far as I have seen new APIs have been added to the WE side when requirements are clearly seen [21:25:04 CEST] <BtbN> You just can't modify the download dialog with an extension that only lives inside of the websites that are displayed [21:25:25 CEST] <BtbN> Same for global mouse gestures [21:25:28 CEST] <JEEB> BtbN: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/user_interface [21:25:33 CEST] <JEEB> well... that is available [21:25:38 CEST] <JEEB> so it's not only the site [21:26:39 CEST] <JEEB> I'm not saying everything is there and even if it would be there it still doesn't make people rewrite their things that they did out of pure interest and don't want to do all that new work for [21:26:49 CEST] <JEEB> I will see how badly I get bitten when 57 hits beta [21:27:19 CEST] <BtbN> The cliget author also said that he didn't feel like to bash his head against the wall that is mozilla support to maybe in a few years give him the interfaces he needs for the addon [21:28:27 CEST] <JEEB> also while limited, it seems like some gestures are already implemented as WE https://addons.mozilla.org/en-US/firefox/addon/foxy-gestures/ [21:28:38 CEST] <JEEB> but yea, I do agree that it will be a big pain point [21:28:43 CEST] <BtbN> It will be limited the same way it is in Chrome [21:28:50 CEST] <BtbN> Only works on websites [21:28:56 CEST] <BtbN> not in the settings, not on "special pages" [21:29:23 CEST] <JEEB> also it seems like the quickest way to get your APIs around is to make an experiment out of them a la https://github.com/autonome/webext-experiment-showOnlyTheseTabs/tree/master… [21:29:39 CEST] <JEEB> which is basically a way to create the interfaces [21:31:10 CEST] <BtbN> I just Switched to Chrome. It's faster anyway, and as Firefox will soon have the same limitations to its Extensions... [21:31:33 CEST] <JEEB> I just don't want to be on the chromium train [21:31:48 CEST] <JEEB> which is a personal thing more than anything tbqh [21:31:58 CEST] <JEEB> although I really like the new multithreaded stuff etc [21:32:17 CEST] <JEEB> https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-engine-quantum-cs… [21:32:20 CEST] <JEEB> etc [21:32:58 CEST] <BtbN> There soon will be only Blink and Firefox left anyway [21:33:11 CEST] <BtbN> Except for whatever MS and Apple decide to use [21:33:25 CEST] <atomnuker> I quite like the synced tab stuff, I started using it a few days ago after I learned it does encryption properly [21:33:43 CEST] <JEEB> the "containers" concept is nice, too [21:33:58 CEST] <JEEB> completely separate sets of local storage [21:37:42 CEST] <wm4> funny how the "convergence" to browsers kills browser people as well (Firefox) [21:37:50 CEST] <wm4> you only need chrome [21:58:30 CEST] <iive> BtbN: I can't get used to Chrome... it's so... second guessing... [21:58:50 CEST] <BtbN> Well, Firefox is getting there as well [21:59:00 CEST] <iive> I'm probably going to try some firefox fork [21:59:14 CEST] <BtbN> All the Firefox forks so far have been a security nightmare [21:59:19 CEST] <iive> something that would keep my extensions working. [21:59:30 CEST] <JEEB> just use the LTS version then [21:59:34 CEST] <BtbN> You just can't maintain a Browser without some grade of large professional backup [21:59:42 CEST] <JEEB> the forks are all something I would not trust [21:59:54 CEST] <iive> i've heard they are not going to make another long term support version before the break [22:00:02 CEST] <iive> so 52 or die [22:00:31 CEST] <nevcairiel> security is probably the prime reason the extensions are getting gutted anyway, so those are never coming back [22:00:42 CEST] <iive> imho, 57 deadline is way too soon. most popular extensions are not yet ported. [22:00:43 CEST] <jamrial> the xul extensions are both what made firefox stand out from chrome and what made it infamous among the average user [22:00:55 CEST] <jamrial> many would break with every browser update [22:01:10 CEST] <jamrial> many would not play well with others, makign firefox seem unstable or broken [22:01:20 CEST] <jamrial> same with all the plugins like flash, java and shit like office, antivirus, skype and such installed without your authorization [22:02:02 CEST] <jamrial> firefox in the eyes of too many people became the slow, bloated browser whereas Chrome was the fast, clean, it just werks browser [22:02:25 CEST] <BtbN> I only ever see people memeing about Chrome eating was too much RAM [22:02:27 CEST] <BtbN> not about Firefox [22:02:27 CEST] <iive> well, is there noscript for chrome? [22:02:30 CEST] <jamrial> so by killing xul that's dealt with [22:02:38 CEST] <jamrial> but the one thing that made it unique also gone [22:02:44 CEST] <jamrial> xul extensions, i mean [22:03:10 CEST] <iive> i do agree, by killing xul, firefox commits suicide [22:03:23 CEST] <jamrial> so now the adblockers like ublock actually load the ads, then hide them [22:03:30 CEST] <jamrial> whereas before they would not be loaded at all [22:03:37 CEST] <BtbN> I don't think they do that in Chrome [22:03:41 CEST] <BtbN> and I doubt they will in Firefox [22:04:03 CEST] <wm4> slack in firefox is slow on Linux, and the slack people gave up on that [22:04:14 CEST] <wm4> and it's not because of any extensions [22:04:15 CEST] <nevcairiel> chrome improved that, you can have ads not loading at all, yeah [22:04:35 CEST] <BtbN> uBlock in Chrome seems pretty perfect to me [22:04:43 CEST] <jamrial> iive: if the firefox devs actually implement all the interfaces needed so the most popular extensions work as intended, then things will be ok [22:04:59 CEST] <wm4> firefox would just need to offer an alternative to xul [22:05:00 CEST] <iive> jamrial: no, there is not enough time [22:05:06 CEST] <BtbN> They got one more release for that [22:05:07 CEST] <wm4> I don't believe they don't do this? [22:05:14 CEST] <BtbN> once the current beta hits live, the Interface will be frozen [22:05:15 CEST] <jamrial> BtbN: try to open a page with a slow computer and/or slow connection. You'll probably get to see an ad before it's hidden [22:05:26 CEST] <wm4> because not doing it would be a big fat fuck you to users [22:05:39 CEST] <wm4> (but we all know browsers and their users are in an abusive relationship) [22:05:43 CEST] <JEEB> jamrial: that seems to only happen to me right after boot [22:06:01 CEST] <iive> wm4: this is exactly what they do [22:07:42 CEST] <iive> wireshark could probably tell you if they do load other websites [22:07:57 CEST] <iive> there must be an firefox internal method for that too... [22:07:58 CEST] <wm4> or the browser js debugger [22:08:14 CEST] <wm4> (web dev tools or what they call it) [22:08:44 CEST] <JEEB> jamrial: also I had that issue with adblock plus too, which AFAIK was a XUL extension [22:08:56 CEST] <iive> yeh, but you should know how to use it and it may still lie to you . [22:09:20 CEST] <iive> JEEB: that was an option of adblock [22:10:52 CEST] <jamrial> so yeah, i bet there were many heated discussions among firefox devs before making this drastic decision. they put stability and idiot proof approach to extensions in one scale and the versatility and power of xul extensions in another [22:10:57 CEST] <jamrial> and the former won [22:11:50 CEST] <iive> the problem is, they cannot be better chrome than chrome [22:15:40 CEST] <jamin> I've already posted this in the user's channel and seemingly stumped the folks there... I'm trying, without success, to get ffmpeg to open a multicast stream... https://pastebin.com/6nS0FXdt [23:42:36 CEST] <kevinn__> Hi! Does anyone have any good examples of decoding x264 buffers with libavcodec? [23:42:43 CEST] <kevinn__> I can't seem to find any nice and simple sample [00:00:00 CEST] --- Wed Sep 20 2017

1 0

ffmpeg.log.20170919
by burek 20 Sep '17

20 Sep '17

[00:01:12 CEST] <FishPencil> -vf bitplanenoise,metadata=print -f null - did the trick [00:16:10 CEST] <FishPencil> Hm, I wonder if it's possible to filter a frame first with bitplanenoise and then feed the results into nlmeans denoise strength... [00:20:56 CEST] <Johnjay> FishPencil: I have no idea what those things are. [00:22:01 CEST] <Johnjay> when i ask google what it is the 3rd, 4th, and 5th hits mention ffmpeg. lol. [00:22:29 CEST] <furq> you'd think it would be the first on account of them both being ffmpeg filters [00:23:00 CEST] <Johnjay> The first is a tweet of a Dave Rice using it. The second is Bit Plane on wikipedia [00:24:51 CEST] <FishPencil> Does anyone know if that's possible on a frame by frame basis? detect the amount of noise, and then denoise based on that? [00:28:47 CEST] <durandal_170> FishPencil: not in one go [00:29:19 CEST] <FishPencil> durandal_170: is it even possible in two if the metadata is saved to a file or piped? [00:29:34 CEST] <durandal_170> also bitplanenoise calcullates noise of single bit plane [00:30:36 CEST] <durandal_170> FishPencil: no because nlmeans have options for all frames [00:31:07 CEST] <durandal_170> except if you gonna filter each frame separately [00:31:36 CEST] <FishPencil> durandal_170: so maybe the best option then is to do one pass to dump all the frames noise a take the mean? [00:32:55 CEST] <durandal_170> maybe, but you need to first find corellation between the two [00:33:37 CEST] <FishPencil> durandal_170: do the bitplanes reefer to the chroma and luma values? I guess I need to research what that actually means [00:34:36 CEST] <durandal_170> FishPencil: no, bitplane is plane of bits so 8 planes for 8bpp frame [00:36:38 CEST] <FishPencil> I really would like to have per frame detection and respective strength settings. Some scenes from the same media have vastly different amounts of noise [00:38:22 CEST] <durandal_170> yea, some kind of iso noise measurement [00:38:51 CEST] <FishPencil> durandal_170: is that a thing? [00:39:00 CEST] <durandal_170> dunno [00:39:49 CEST] <FishPencil> does ffmpeg accept patches that just tie two filters together? [00:40:34 CEST] <DHE> you can feed the same frame to multiple filters [00:41:56 CEST] <FishPencil> as far as I'm setting the issue is that nlmeans uses per stream strength values, not per frame [00:42:04 CEST] <FishPencil> s/setting/seeing [00:43:00 CEST] <FishPencil> perhaps if the denoise filter was modified to support metadata=ma.txt which contained the bitplanenoise info [00:45:00 CEST] <durandal_170> hmm, but how will you map numbers to options? [00:47:46 CEST] <FishPencil> well if the metadata option is present than the strength setting is used as a relative strength to the detected per frame one [01:06:52 CEST] <hiihiii> hello [01:07:21 CEST] <hiihiii> I'm trying to pipe ffmpeg with gzip or zip [01:17:51 CEST] <Johnjay> TIL what a bitplane is [01:18:42 CEST] <degenerate> hey guys, so i've had a client send me some new iphone photos, they're in this .heic format. I figured out with MP4Box i can dump the tiles to a series of .hevc files, but i'm stuck on how to combine all these .hevc files back into a single image with ffmpeg. [01:18:45 CEST] <degenerate> One person suggested this: [01:18:50 CEST] <degenerate> MP4Box -dump-item 1:path=item1.hevc ~/test_001.heic [01:18:54 CEST] <degenerate> ffmpeg -i item1.hevc -frames:v 1 -vsync vfr -q:v 1 -y -an item1.bmp [01:19:07 CEST] <degenerate> but this only does 1 tile. how do i do a series of tiles all into 1 image at the end? [01:19:47 CEST] <Johnjay> FishPencil: Sorry I don't understand clearly. What are you trying to do with bitplanes? tweak an existing ffmpeg setting? [01:19:53 CEST] <Cracki> tiles, so it's a kind of mosaic? [01:20:10 CEST] <Cracki> you're perhaps better off converting them to something else and then using imagemagick [01:20:38 CEST] <degenerate> Cracki: To be honest i barely understand how this new format works: https://en.wikipedia.org/wiki/High_Efficiency_Image_File_Format [01:20:51 CEST] <degenerate> Cracki: no can do, imagemagick no support: https://github.com/ImageMagick/ImageMagick/issues/507 [01:20:51 CEST] <Cracki> sounds like a single HEVC intra frame [01:21:05 CEST] <Cracki> use ffmpeg to convert to png or something [01:21:11 CEST] <Cracki> then use imagemagick for puzzling [01:21:24 CEST] <Cracki> what kinda resolution is that anyway? [01:21:32 CEST] <Johnjay> When I googled for mp4box I got gpac [01:21:34 CEST] <Cracki> I haven't heard of an "image" format being tiles before [01:21:38 CEST] <Johnjay> When I looked for that I got https://gpac.wp.imt.fr/ and still don't know what it is [01:21:56 CEST] <Cracki> ignore [01:22:06 CEST] <degenerate> yeah i just leared about MP4Box and gpac today, becasue they are the only thing i could find that has HEIC support so far [01:22:06 CEST] <Cracki> did you get ffmpeg to read it? [01:22:21 CEST] <degenerate> it seems really new and a lot of the libraries out there just don't support it [01:22:23 CEST] <Cracki> or, well, you unpacked that thing, right? [01:22:31 CEST] <degenerate> i wish i just had a single line command that converted it from HEIC to PNG [01:22:35 CEST] <degenerate> that would be awesome [01:22:52 CEST] <Cracki> *heic/heif [01:23:00 CEST] <degenerate> so far i'm here: for i in `seq 51`; do MP4Box -dump-item $i:path=item$i.hevc IMG_5915.HEIC; done [01:23:11 CEST] <degenerate> basically i dumped the 51 tiles from the HEIC into hevc files [01:23:17 CEST] <degenerate> so now i've got 51 HEVC files [01:23:18 CEST] <Cracki> nice [01:23:35 CEST] <Cracki> you might wanna try getting ffplay to "play" these single frames [01:23:39 CEST] <Cracki> i.e. display them [01:23:39 CEST] <degenerate> so i guess you're right i gotta convert each one to png or something [01:23:45 CEST] <degenerate> and then try to stich with imagemagic [01:23:46 CEST] <degenerate> brutal [01:23:50 CEST] <Cracki> if that works, ffmpeg can turn them into tamer image formats [01:23:52 CEST] <degenerate> i guess i'll write a python wrapper that does the whole thing [01:23:53 CEST] <Cracki> aye :) [01:24:29 CEST] <degenerate> So can you suggest a ffmpeg command to go from a single hevc to say, png or jpg? [01:24:31 CEST] <Cracki> it MIGHT be possible with some voodoo to get an ffmpeg filter to place consecutive frames or "video files" at computed positions in a resulting frame... [01:24:43 CEST] <Cracki> first I'd try if ffplay can deal with the tiles [01:24:46 CEST] <Cracki> single tile [01:25:01 CEST] <degenerate> so is this correct? [01:25:02 CEST] <degenerate> ffmpeg -i item1.hevc -frames:v 1 -vsync vfr -q:v 1 -an test.jpg [01:25:42 CEST] <Cracki> no clue [01:25:43 CEST] <Cracki> try [01:25:59 CEST] <Cracki> but I'd try with ffprobe and ffplay first [01:26:24 CEST] <klaxa> if you want to reduce quality loss, use a lossless codec like png [01:27:25 CEST] <Cracki> HEIF seems to have come out within the last few months [01:27:29 CEST] <Cracki> https://photofocus.com/2017/06/09/ios-11-photos-a-new-image-format/ [01:28:12 CEST] <Cracki> it's not a smart format... hevc licensing and all [01:30:44 CEST] <Cracki> 500px.com says it's a "still picture" profile of hevc [01:39:02 CEST] <degenerate> Cracki: yeah, but i'm about to get slammed by users trying to upload these files, and i still need to handle it. whether or not it is a smart format, my users are dumb and just take pictures with their phones and then try to upload them [01:39:26 CEST] <degenerate> and i've not even yet touched the video compression they're doing something similar too, while still in a .mov container, it's using this new HEIF stuff under the hood [01:39:52 CEST] <degenerate> those .mov's don't even play in apple's quicktime player (maybe mines out of date, but yeah, totally silly) [01:40:35 CEST] <degenerate> common quicktime! YOU HAD ONE JOB. play mov's and you can't even do that anymore. [01:42:57 CEST] <Johnjay> what users degenerate? [01:43:01 CEST] <Johnjay> On your website? [01:43:04 CEST] <degenerate> yup [01:55:47 CEST] <Johnjay> ddd [01:56:06 CEST] <Johnjay> So what do you need exactly a change to ffmpeg for your site? [01:56:17 CEST] <degenerate> ? [01:57:59 CEST] <Johnjay> Oh nevermind I finally found your initial comment [01:58:28 CEST] <degenerate> k :) [02:02:57 CEST] <Cracki> you're welcome to post sample files :) [02:03:12 CEST] <degenerate> linked in last post on this thread [02:03:13 CEST] <degenerate> https://github.com/gpac/gpac/issues/901 [02:03:20 CEST] <degenerate> HEIC Conversion.zip [02:03:33 CEST] <degenerate> sorry, direct link: https://github.com/gpac/gpac/files/1312599/HEIC.Conversion.zip [02:03:44 CEST] <degenerate> but that post does describe the current state of things, and what the files are [02:04:50 CEST] <FishPencil> Does FFmpeg/avfilter have a way to generate a 1920x1808 frame of noise? [02:07:29 CEST] <Cracki> certainly [02:07:50 CEST] <Cracki> there is a noise source filter [02:08:08 CEST] <atomnuker> ffmpeg -f rawvideo -s 1920x1808 -pix_fmt yuv420p -i /dev/urandom [02:08:14 CEST] <Cracki> or that [02:08:20 CEST] <atomnuker> there isn't a noise source filter for video, only audio [02:08:38 CEST] <Cracki> oh, then I thought of gstreamer :/ [02:09:37 CEST] <FishPencil> without using urandom? [02:10:36 CEST] <Cracki> you could use the audio noise, pipe it out as binary, pipe it back in and interpret as video [02:10:50 CEST] <Cracki> (in case your system doesn't have /dev/urandom or something similar) [02:12:04 CEST] <c_14> you could use color to create a white or black frame and then use the noise filter to add noise [02:12:54 CEST] <Cracki> ^ [02:13:10 CEST] <FishPencil> I like that [02:13:53 CEST] <Cracki> btw, ffplay "plays" the .hevc items just fine [02:14:20 CEST] <Cracki> and I see you got the hevc->png step done too [02:15:04 CEST] <degenerate> yeah, i think i'm good tbh [02:15:12 CEST] <degenerate> unless you see anything wrong wiht my conversion flags [02:15:32 CEST] <degenerate> for i in `seq 51`; do ffmpeg -i item$i.hevc -frames:v 1 -vsync vfr -q:v 1 -an image$i.png; done [02:15:47 CEST] <degenerate> thanks for your help btw [02:15:55 CEST] <Cracki> image50 is a thumbnail i see [02:16:08 CEST] <Cracki> I don't see a need for vsync, but if you do, it's ok [02:16:19 CEST] <degenerate> no, i just copied this command from somewhere [02:16:24 CEST] <Cracki> ah [02:16:37 CEST] <Cracki> -q:v might not make sense for png either [02:16:39 CEST] <degenerate> yeah, image50 is a thumbnail, and apparently image49 is some sort of grid thumbnail that doesn't convert [02:16:46 CEST] <degenerate> and also image51 is EXIF metadata [02:16:47 CEST] <Cracki> if the pngs are temp files, doesn't matter how well they were compressed [02:16:58 CEST] <Cracki> you could even store bitmaps... if that's a tempfs in ram [02:17:03 CEST] <degenerate> my hope is to grab that EXIF metadata and then re-apply it to the final image i create with imagemagic after restiching the tiles [02:17:10 CEST] <Cracki> ah, the exif data, ffmpeg or imagemagick might be able to copy that [02:17:13 CEST] <Cracki> yeah [02:17:39 CEST] <Cracki> item49 is empty [02:18:02 CEST] <degenerate> yeah i don't really get what item49 is supposed to be used for TBH [02:18:06 CEST] <Cracki> the header is even wrong, says length 24, but 16 bytes in total [02:19:51 CEST] <Cracki> you might wanna poke the imagemagick people [02:29:39 CEST] <degenerate> Hey Cracki does ffmpeg have some way of automatically detecting "letterboxing" and cropping it out? For example i've managed to get past the stiching point, and this was the result: [02:29:39 CEST] <degenerate> https://www.dropbox.com/s/4jwgdy49tuotuit/combined.png?dl=0 [02:29:55 CEST] <Cracki> I *think* there might be a filter [02:30:13 CEST] <degenerate> because of the image tiles being a standard height and width, and the image itself is not exactly a multiple of that size, you end up with this black bar on the right and bottom [02:30:28 CEST] <Cracki> check the video filters list, I think it'll be there [02:30:40 CEST] <degenerate> thnx [04:40:49 CEST] <Johnjay> thebombzen [04:41:00 CEST] <Johnjay> oops no auto complete [04:44:52 CEST] <Ober> is there any way to use ffmpeg to do transitions between small clips made from a larger image? [04:45:06 CEST] <Ober> or even gluing them together ala cat(1) [05:15:22 CEST] <kevinn_> Hi! Does anyone have any good examples of decoding x264 buffers with libavcodec? [05:15:35 CEST] <kevinn_> I can't seem to find any nice and simple sample [07:36:24 CEST] <kjshdlkafhslh> Is anyone here? [07:36:36 CEST] <blap> dunno [07:36:45 CEST] <kjshdlkafhslh> I am but a useless nerd trying to make my gif and mp3 together in one webm [07:36:49 CEST] <blap> btw get a droid 4 with sailfish os [07:37:05 CEST] <kjshdlkafhslh> I have all three source files in a folder with the ffmpeg.exe [07:38:17 CEST] <kjshdlkafhslh> I have tried this multiple times [07:38:19 CEST] <kjshdlkafhslh> However [07:38:28 CEST] <kjshdlkafhslh> I can only get a webm which holds a single frame [07:38:31 CEST] <kjshdlkafhslh> I do not know why [09:05:10 CEST] <jeffW_> Could someone explain to me, where in this: https://trac.ffmpeg.org/wiki/CompilationGuide/MSVC is it explaining how to compile FFmpeg in MSVC? Other than the beginning, it seems to me like it is explaining how to compile in Linux or MSYS2. [09:06:38 CEST] <jeffW_> No where does it explain how to setup anything in MSVC, it only tells you to perform Linux commands such as: ./configure --toolchain=msvc make make install [09:11:55 CEST] <JEEB> jeffW_: yes the same build system is used but --toolchain=msvc tells the system to utilize MSVC tools [09:12:24 CEST] <JEEB> it makes no sense to duplicate the build system [09:12:37 CEST] <JEEB> so yes, you need msys2 or something else that provides you with the basic shell etc [09:12:50 CEST] <JEEB> and you can call that from the visual studio development command line [09:13:10 CEST] <jeffW_> To build 64bit you need to run this command to enable the 64bit compiler and linker: vcvarsall.bat amd64 [09:13:37 CEST] <jeffW_> What does running vcvarsall.bat amd64 do? How is running this .bat file going to help MSYS2? [09:14:04 CEST] <JEEB> it adds the MSVC tools into the environment, although usually you go the other way... not that I've read that document on the wiki recently :P [09:14:32 CEST] <JEEB> the visual studio command line link in the start menu does pretty much that I think? [09:15:29 CEST] <jeffW_> Start menu? [09:15:48 CEST] <jeffW_> Does pretty much what? [09:16:32 CEST] <JEEB> what I'm trying to explain is that while I haven't read that document, the vcvarsall.bat is what those "open visual studio development command line" shortcuts in the start menu utilizes [09:16:55 CEST] <JEEB> so "how does this help" => "it is supposed to bring the tools into your environment (PATH etc)" [09:17:28 CEST] <JEEB> anyways, I've got work to do so I can't be hand-feeding you here >_> [09:18:21 CEST] <jeffW_> Bye. [09:19:08 CEST] <jeffW_> Does anyone else know to get the information presented here: https://trac.ffmpeg.org/wiki/CompilationGuide/MSVC to work? [09:48:38 CEST] <cart_man> Hey everyone [09:50:07 CEST] <cart_man> I am trying to grab 2 frames a second from a video. My command is as followings ffmpeg.exe -y -vf fps=2/1 ./Input.asf ./conv/%03d.jpg ...IT gives me this error howeverset video filters cannot e applied to input url. :( [09:50:24 CEST] <cart_man> Is there another way to grab roughly 2 frames a second instead of all of them? [09:58:57 CEST] <Nacht> cart_man: ffmpeg.exe -i ./Input.asf -y -vf fps=2/1 ./conv/%03d.jpg [09:59:28 CEST] <Nacht> define the input file with -i and place the -vf after it, cause you are applying it to the output, not the input [10:24:04 CEST] <cart_man> ok that worked...Thanks allot! [10:27:03 CEST] <jeffW_> Is anyone here familiar with compiling ffmpeg with MSYS2/mingw-w64 ? [10:27:47 CEST] <jeffW_> I am trying to follow the MSVC guide on the wiki: https://trac.ffmpeg.org/wiki/CompilationGuide/MSVC [10:28:53 CEST] <jeffW_> When I type which link produces: /c/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/x86_amd64/link and which cl produces: /c/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/x86_amd64/cl [10:29:22 CEST] <jeffW_> Yet when I run: $ ./configure --enable-asm --enable-yasm --arch=x86_64 --disable-ffserver --disable-doc --disable-ffprobe --disable-ffmpeg --enable-shared --disable-static --disable-bzlib --disable-libopenjpeg --disable-iconv --disable-zlib --prefix=/c/ffmpeg-output-shared2 --toolchain=msvc [10:29:57 CEST] <jeffW_> I get: cl is unable to create an executable file. If cl is a cross-compiler, use the --enable-cross-compile option. Only do this if you know what cross compiling means. C compiler test failed. If you think configure made a mistake, make sure you are using the latest version from Git. If the latest version fails, report the problem to the ffmpeg-user(a)ffmpeg.org mailing list or IRC #ffmpeg on irc.freenode.net. Include the log [10:32:13 CEST] <jeffW_> Here is the ffbuild/config.log : https://pastebin.com/EBCcZTP7 [10:40:00 CEST] <BtbN> that looks like your MSVC is just broken, or your environment is missettup [10:41:55 CEST] <jeffW_> :( [10:43:19 CEST] <jeffW_> Alright, well MSVC did give me a warning about possibly needing repair after I uninstalled Community version [10:43:55 CEST] <jeffW_> I'll try Repair it and report back. [16:35:19 CEST] <voltagex> hey, anyone awake? I've got an mp4 file that appears to switch resolution part way through. Wondering if I can upload it anywhere as I'm not sure how to file a bug for it [16:35:36 CEST] <JEEB> there were multiple places for samples if I recall correctly [16:36:13 CEST] <Nacht> Maybe it's an adaptive bitrate vod /s :) [16:36:36 CEST] <JEEB> well you can have multiple parameter set things and each sample can in theory point to one of the initialization data things [16:36:53 CEST] <JEEB> and/or you just have initialization data in-band within the samples [16:37:04 CEST] <Nacht> https://streams.videolan.org/upload/ ? [16:37:06 CEST] <JEEB> both ways enable you to do complete changes of the video track [16:37:14 CEST] <JEEB> yes, that's one way of doing it I think [16:41:21 CEST] <voltagex> I think it's being grabbed by ffmpeg incorrectly in the first place. https://video.vice.com/en_us/video/motherboard-speed-daemons-los-angeles-dr… if anyone's interested (filter chrome traffic for m3u) [19:23:39 CEST] <jamin> I'm experiencing an odd hang when trying to open a multicast stream with ffmpeg. With tcpdump I an see that packets are arriving, but ffmpeg does nothing [19:24:03 CEST] <jamin> https://pastebin.com/y5zYLgEh [19:24:31 CEST] <JEEB> you might want to specify the source(s) [19:24:47 CEST] <JEEB> udp://MULTICAST:PORT?sources=SOURCE_IP [19:25:15 CEST] <DHE> got an iptables rule dropping the traffic? [19:25:27 CEST] <DHE> (I assume linux) [19:26:07 CEST] <jamin> DHE: there is an iptables rule to drop 0 sized udp packets but not the others... and even without it ffmpeg hung at the same point [19:26:14 CEST] <jamin> and yes, Linux [19:26:32 CEST] <JEEB> for me it's usually the lack of source IP, because otherwise lavf won't register [19:26:37 CEST] <JEEB> that has often been a thing for me [19:27:36 CEST] <jamin> getaddrinfo(sources=192.168.1.238, 0): Name or service not known [19:27:55 CEST] <jamin> nvm, typo [19:28:12 CEST] <jamin> nah, even with sources it hangs in the same place [19:28:38 CEST] <JEEB> also set timeout in microseconds to know if it's just thinking it's not getting data? [19:28:53 CEST] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#udp [19:30:01 CEST] <JEEB> jamin: also try setting localaddr to make sure it tries to bind the correct interface [19:30:10 CEST] <JEEB> other than that, no idea [19:30:23 CEST] <jamin> udp://@239.255.42.42:5004?sources=192.168.1.238&timeout=1000: Input/output error [19:30:37 CEST] <JEEB> that's in microseconds so that's... really low timeout [19:30:52 CEST] <jamin> udp://@239.255.42.42:5004?sources=192.168.1.238&timeout=100000: Input/output error [19:31:14 CEST] <jamin> udp://@239.255.42.42:5004?sources=192.168.1.238&timeout=10000000: Input/output error [19:31:23 CEST] <JEEB> yea, that looks alright range already [19:31:39 CEST] <JEEB> so indeed, it doesn't listen where the thing is [19:31:44 CEST] <JEEB> try defining localaddr [19:32:05 CEST] <JEEB> which is the local address of the interface [19:32:08 CEST] <JEEB> also you don't need the @ [19:36:08 CEST] <jamin> removed the iptables rule entirely, also removed the @ [19:36:12 CEST] <jamin> udp://239.255.42.42:5004?sources=192.168.1.238&timeout=10000000&localaddr=192.168.1.100: Input/output error [19:36:37 CEST] <JEEB> rip [19:37:00 CEST] <JEEB> at this point it would have worked for me (after I add the source) [19:37:10 CEST] <JEEB> try strace'ing? [19:39:39 CEST] <jamin> just a bunch of these [19:39:40 CEST] <jamin> futex(0x5619b6fa7640, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, {tv_sec=1505842716, tv_nsec=804757000}, 0xffffffff) = -1 ETIMEDOUT (Connection timed out) [19:41:39 CEST] <JEEB> ffv1 mentioned \o/ https://pbs.twimg.com/media/DKFi2QWWsAg6Ysl.jpg:orig [21:15:40 CEST] <pgorley> can a hwaccel fail (barring catastrophic hardware meltdowns) if it was succesfully created with av_hwdevice_ctx_create? [21:16:20 CEST] <pgorley> on calls to avcodec_send_packet/avcodec_receive_frame or av_hwframe_transfer_data? [21:17:20 CEST] <BtbN> if you send it nonsensical or broken data, sure [21:17:25 CEST] <BtbN> Or something it plain does not support [21:21:55 CEST] <pgorley> makes sense [21:22:52 CEST] <pgorley> how do i make sure the hwaccel supports what i'm gonna send it? (resolution, codec, all that) [21:24:52 CEST] <Diag> pgorley: check the wiki or try it [21:25:23 CEST] <pgorley> i was hoping for way to check that in code? [21:30:18 CEST] <JEEB> pgorley: I'm not sure if there's a good way [21:30:30 CEST] <JEEB> generally things tend to not let you send things in if they're not 8bit, 4:2:0 [21:30:47 CEST] <JEEB> after that you hope the driver doesn't BSoD on you for sending too many reference frames or whatever [21:31:04 CEST] <JEEB> hw decoding has gotten better, but it's still kind of fragile [21:32:03 CEST] <BtbN> If it decodes the first frame and you don't start sending it vastly different stuff or garbe, it will continue working [21:32:24 CEST] <BtbN> so testing if it works is done by doing just that [21:32:51 CEST] <pgorley> no other way than to start sending it frames then, alright [21:32:54 CEST] <pgorley> thanks! [23:42:23 CEST] <kevinn_> Hi! Does anyone have any good examples of decoding x264 buffers with libavcodec? [23:42:24 CEST] <kevinn_> I can't seem to find any nice and simple sample [00:00:00 CEST] --- Wed Sep 20 2017

1 0

ffmpeg-devel.log.20170918
by burek 19 Sep '17

19 Sep '17

[00:10:20 CEST] <cone-797> ffmpeg 03James Almer 07master:98d7ad085e20: avcodec/exrdsp: improve the ExrDSPContext->reorder_pixels prototype [00:10:21 CEST] <cone-797> ffmpeg 03James Almer 07master:7323c896b2cb: checkasm: add an exrdsp test [03:26:17 CEST] <cone-550> ffmpeg 03Carl Eugen Hoyos 07master:3118e81f8606: lavc/frame_thread_encoder: Do not mix variable declaration and code. [05:19:50 CEST] <cone-550> ffmpeg 03Thomas Mundt 07master:4492237e333c: fate: add tinterlace lowpass filtering tests [05:19:51 CEST] <cone-550> ffmpeg 03James Almer 07master:3af1060319b4: avfilter/tinterlace: Simplify checks for lowpass filtering flags [09:26:39 CEST] <cone-896> ffmpeg 03Tobias Rapp 07master:35d6be199a55: avformat/mxfenc: fix aspect ratio when writing 16:9 DV frames [09:26:40 CEST] <cone-896> ffmpeg 03Tobias Rapp 07master:147bface1a56: fate: add mxf_dv25/dvcpro50 regression tests [09:26:41 CEST] <cone-896> ffmpeg 03Tobias Rapp 07master:3ffd3b7f5f13: avformat/mxfenc: cosmetic changes [17:48:30 CEST] <BBB> jya: re that bug report, can you point me again at the file where the ffvpx decoders are accessed in the webgit of mozillas source tree? [17:48:38 CEST] <BBB> jya: that last comment might be helpful [18:25:53 CEST] <kurosu> jamrial / Gramner: regarding ST{ART,OP}_TIMER vs checkasm, does checkasm try to bypass cache when writing the data to be read? [18:26:26 CEST] <Gramner> no, pretty much all of checkasm is L1 [18:26:38 CEST] <kurosu> the former causes I guess register pressure, while the later doesn't have the actual memory access of a real decoder [18:26:53 CEST] <Gramner> real world scenarios will be memory bottlenecked in many cases [18:27:09 CEST] <kurosu> I know you and a lot of people prefer using checkasm though [18:27:17 CEST] <kurosu> (for convenience maybe) [18:28:24 CEST] <kurosu> does arm have data cache? and a way to bypass it? Not sure using some form of movnt* is worth the hassle anyway [18:28:41 CEST] <kurosu> for x86 [18:28:49 CEST] <Gramner> (START|STOP)_TIMER isn't really an accurate measurement either due to out-of-order execution [18:29:14 CEST] <kurosu> isn't rdtsc imply a fence ? [18:29:17 CEST] <kurosu> *doesn't [18:29:57 CEST] <Gramner> rdtsc;lfence is. but by adding it it's no longer a real scenario [18:30:43 CEST] <Gramner> it's like quantum physics. by measuring you change the outcome [18:31:10 CEST] <kurosu> yeah, each have its drawback [18:31:14 CEST] <kurosu> *has [18:31:43 CEST] <kurosu> I've just discovered rdtscp [18:31:56 CEST] <kurosu> anyway, same issue [18:31:58 CEST] <Gramner> rdtscp is basically the same as rdtsc;lfence [18:32:04 CEST] <Gramner> (on most cpus) [18:33:09 CEST] <iive> STOP_TIMER executes a fence [18:33:34 CEST] <iive> so you need to do a null function in order to know the specific OOE depth [18:34:04 CEST] <iive> tht is start and then stop timer without anything between them. [19:23:22 CEST] <jya> BBB: I'm not sure I understand [19:23:44 CEST] <BBB> the code that calls avcodec_decode_video2(), where is it located? [19:30:53 CEST] <jya> Dom/ [19:31:15 CEST] <jya> Sorry I'm driving :) [19:32:49 CEST] <jya> BBB: https://dxr.mozilla.org/mozilla-central/source/dom/media/platforms/ffmpeg/F… [19:33:03 CEST] <BBB> omg this is not urgent please dont type while driving [19:33:05 CEST] <BBB> this can wait [19:33:53 CEST] <jya> Google keyboard sucks at spelling path :) [00:00:00 CEST] --- Tue Sep 19 2017

1 0

ffmpeg.log.20170918
by burek 19 Sep '17

19 Sep '17

[06:19:21 CEST] <thebombzen> do any codecs in FFmpeg support gbrapf32le other than rawvideo? [06:36:40 CEST] <FunkyBob> so ... back again... with my issue of jumping to frame N of a video stream [06:37:16 CEST] <FunkyBob> it seems the PTS value is... not usable as such :/ [12:34:40 CEST] <Questions> Quick question please anyone. Im trying to use FFmpegInterop within my Universal Windows Project: Does FFmpeg allow users to stream https urls? [12:35:41 CEST] <Questions> Quick question please anyone. Im trying to use FFmpegInterop within my Universal Windows Project: Does FFmpeg allow users to stream https urls?? [12:55:17 CEST] <cart_man> Morning... Is there some way I can limit the pictures I extract out of a video to 2 or 3 per second? [13:09:01 CEST] <Nacht> cart_man: You mean, as in taking a screenshot every nth second ? [13:09:16 CEST] <cart_man> Well I would like it to take 3 shots per 1 second [13:09:19 CEST] <cart_man> or 2 shots per 1 second [13:09:44 CEST] <Nacht> I recon something like: "-vf fps=2/1" [13:23:31 CEST] <bparticle> Hi there ffmpeg user support! I'm trying to encode a series of images to a video and I run into a problem that I can't find anywhere else [13:24:30 CEST] <bparticle> I have a list of images namef output0001.jpg output0002.jpg etc. [13:25:56 CEST] <bparticle> Any command I run to make these into images, ffmpeg asks me if I want to overwrite the actual source images. When I comply, then I end up with all the images being overwritten by the first image [13:27:35 CEST] <Nacht> bparticle: Are you making images->video or video->images. Cause you're saying both now [13:28:17 CEST] <Nacht> bparticle: Also, what is the command you're running ? [13:28:38 CEST] <bparticle> I just figured it out..! I swear I tried to make it work for the last two days, now I got it [13:29:15 CEST] <bparticle> it was my usage of %3d to source the files [14:49:59 CEST] <pgorley> hi, what does --enable-libdrm do? didn't vaapi already use drm if it was available? [14:51:25 CEST] <JEEB> configure:kmsgrab_indev_deps="libdrm" [14:51:32 CEST] <JEEB> it's for the KMS screen capture [14:51:35 CEST] <JEEB> not vaapi [14:52:11 CEST] <pgorley> oh, thanks [14:59:32 CEST] <jkqxz> If you use the libraries then it enables the DRM hwcontext stuff, including DRM-to-VAAPI mapping. kmsgrab is the only directly visible component, though. [15:01:11 CEST] <pgorley> how does it compare to xcb screen grab? [15:04:30 CEST] <jkqxz> It's trickier to use and only works on some hardware/kernel setups. On the other hand, it doesn't depend on X, so it can capture Wayland and VTs as well (including transitions between them). [15:05:09 CEST] <jkqxz> Also, in combination with VAAPI mapping it can capture the screen using ~zero CPU. [15:29:50 CEST] <kerio> can anyone think of a way to make ffmpeg drop exact duplicate frames? [15:30:24 CEST] <kerio> mpduplicate with a "hi" parameter of 0 kinda does the job but it will not deal with gray16le video [15:30:36 CEST] <kerio> er, mpdecimate [15:32:42 CEST] <kerio> alternatively, can I tell the fps filter not to insert duplicate frames? [15:32:59 CEST] <kerio> all I want is to round the timestamps to a specific frame rate [15:49:27 CEST] <pgorley> thanks, jkqxz, i'll keep that in mind for later [19:25:17 CEST] <Ober> are there any good frontends to ffmpeg for less technically inclined mac users? [19:27:22 CEST] <Mavrik> Handbrake I guess? [19:34:30 CEST] <Ober> is it free? [19:36:01 CEST] <Ober> thanks [22:52:18 CEST] <FishPencil> Does FFmpeg have anything that can detect the amount of noise in a given clip? I have some media with more noise than others, but I'd like to denoise them to roughly the same output [23:03:44 CEST] <durandal_170> FishPencil: bitplanenoise filter [23:05:04 CEST] <Ober> nice. are tehre any ml plugins to help identify what is in a video? [23:15:08 CEST] <FishPencil> How do I actually use bitplanenoise? '-t 60 -vf bitplanenoise -f null -' doesn't give any info [23:36:33 CEST] <FishPencil> line 190 is telling me it's going to the metadata, but I don't see anything for it when it's done https://github.com/FFmpeg/FFmpeg/blob/master/libavfilter/vf_bitplanenoise.c… [00:00:00 CEST] --- Tue Sep 19 2017

1 0

ffmpeg-devel.log.20170917
by burek 18 Sep '17

18 Sep '17

[02:19:20 CEST] <atomnuker> rcombs: will you send an update for your flac cover art patches? [02:19:51 CEST] <rcombs> I can rebase and resend; I forget if there was actually anything left to do on them [02:19:56 CEST] <rcombs> mailing lists are impossible [02:41:34 CEST] <jamrial> rcombs: look at my last reply. you were missing an av_freep or something like that [02:41:43 CEST] <rcombs> ah yeah [05:53:48 CEST] <Ahti333> hi! could someone familiar with libavformat have a look at this regression https://trac.ffmpeg.org/ticket/6558 ? I just ran into it after upgrading my ffmpeg. I'm not familiar with libavformat, but a quick read of the code reveals that since ff_id3v2_read_dict doesn't take an AVFormatContext, read_chapter doesn't know where to put the chapter data (see here: https://github.com/FFmpeg/FFmpeg/blob/0cc6dd1b817bc4510714dd99122625d939092… [05:53:48 CEST] <Ahti333> ormat/id3v2.c#L682 ). the comment mentions ff_id3v2_parse_apic which faces a similar problem, so fixing this probably means extracting part of read_chapter into another function and calling that from avformat_open_input [05:54:12 CEST] <Ahti333> that link didn't work out so well. https://github.com/FFmpeg/FFmpeg/blob/0cc6dd1b817bc4510714dd99122625d939092… [10:01:39 CEST] <nevcairiel> why would there not be a AVFormatContext, avformat should always have one [13:01:27 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.2:892ceb512f0f: avcodec/diracdec: Check weight_log2denom [13:01:27 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.2:19938f1a1135: avcodec/diracdsp: fix integer overflow [13:01:27 CEST] <cone-934> ffmpeg 03Steven Siloti 07release/3.2:16ee4057077b: avformat/utils: fix memory leak in avformat_free_context [13:01:27 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.2:b66aa37834c2: avcodec/h264_slice: Fix overflow in slice offset [13:01:27 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.2:e5950870481b: avcodec/aacdec_fixed: fix invalid shift in predict() [13:01:27 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.2:52c4069119ba: avcodec/dirac_dwt: Fixes integer overflows in COMPOSE_DAUB97* [13:01:28 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.2:342d5c20ce0a: avcodec/mpeg4videodec: Clear mcsel before decoding an image [13:01:29 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.2:04db307c77c1: avcodec/ffv1dec_template: Fix undefined shift [13:01:30 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.2:952393b69e66: avcodec/diracdec: Check perspective_exp and zrs_exp. [13:01:31 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.2:5bc3b18e3d98: avcodec/diracdec: Fixes integer overflow [13:01:32 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.2:bd09e3b19c71: avcodec/snowdec: Fix off by 1 error [13:01:33 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.2:98cd9cd4c29c: avcodec/fic: Fixes signed integer overflow [13:01:34 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.2:dc86479e5feb: avcodec/dirac_dwt_template: Fix integer overflow in vertical_compose53iL0() [13:01:35 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.2:d15b1da8bcb3: avcodec/me_cmp: Fix crashes on ARM due to misalignment [13:01:36 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.2:6da5e63ba71d: avcodec/aacdec_template: Fix running cleanup in decode_ics_info() [13:01:37 CEST] <cone-934> ffmpeg 03Vitaly Buka 07release/3.2:febea34f914b: avcodec/utils: Fix signed integer overflow in rc_initial_buffer_occupancy initialization [13:01:38 CEST] <cone-934> ffmpeg 03Vitaly Buka 07release/3.2:74410f2abab0: avformat/mov: Fix signed integer overflows with total_size [13:01:39 CEST] <cone-934> ffmpeg 03Vitaly Buka 07release/3.2:50cb32480b76: avformat/aviobuf: Fix signed integer overflow in avio_seek() [13:01:40 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.2:53a6cdf89d69: avformat/rtpdec_h264: Fix heap-buffer-overflow [13:01:41 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.2:3738a41830fb: avcodec/hevc_ps: Check delta_pocs in ff_hevc_decode_short_term_rps() [13:01:42 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.2:726133b6d2cd: ffprobe: Fix null pointer dereference with color primaries [13:01:43 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.2:baca98fc0971: ffprobe: Fix NULL pointer handling in color parameter printing [13:01:44 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.2:2920c7cec0b1: avformat/hls: Fix DoS due to infinite loop [13:01:45 CEST] <cone-934> ffmpeg 03Yi and *®() 07release/3.2:f94517934bf0: avformat/asfdec: Fix DoS due to lack of eof check [13:01:46 CEST] <cone-934> ffmpeg 03Yi and *®() 07release/3.2:98e177c72885: avformat/cinedec: Fix DoS due to lack of eof check [13:01:47 CEST] <cone-934> ffmpeg 03Yi and *®() 07release/3.2:2bbef8ee2712: avformat/rmdec: Fix DoS due to lack of eof check [13:01:48 CEST] <cone-934> ffmpeg 03Yi and *®() 07release/3.2:5bc9f70441d7: avformat/rl2: Fix DoS due to lack of eof check [13:01:49 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.2:d4fc6b211f19: avformat/mvdec: Fix DoS due to lack of eof check [13:01:50 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.2:a4cc1101cc98: avcodec/sbrdsp_fixed: Fix undefined overflows in autocorrelate() [13:01:51 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.2:50d726273e9c: avcodec/hevc_ps: Fix undefined shift in pcm code [13:01:52 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.2:e29c9ef2d56a: avcodec/snowdec: Fix integer overflow in decode_subband_slice_buffered() [13:01:53 CEST] <cone-934> ffmpeg 03Yi(SÑ) 07release/3.2:a051de092e9c: avformat/nsvdec: Fix DoS due to lack of eof check in nsvs_file_offset loop. [13:01:54 CEST] <cone-934> ffmpeg 03Yi(SÑ) 07release/3.2:9cbac3602610: avformat/mxfdec: Fix DoS issues in mxf_read_index_entry_array() [13:01:55 CEST] <cone-934> ffmpeg 03Yi(SÑ) 07release/3.2:816f7337bf3e: avformat/mxfdec: Fix Sign error in mxf_read_primer_pack() [13:01:56 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.2:2173539519fa: avcodec/diracdec: Fix integer overflow in INTRA_DC_PRED() [13:01:57 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.2:d5b42af8e7ca: avcodec/dirac_dwt: Fix multiple overflows in 9/7 lifting [13:01:58 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.2:372bb594385f: avcodec/dirac_vlc: Fix invalid shift in ff_dirac_golomb_read_32bit() [13:01:59 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.2:c9527df274ad: avformat/mov: Fix DoS in read_tfra() [13:02:00 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.2:4e4177dde23b: avformat/asfdec: Fix DoS in asf_build_simple_index() [13:02:01 CEST] <cone-934> ffmpeg 03Mark Wachsler 07release/3.2:36c0958fbd9f: libavcodec/h264_parse: don't use uninitialized value when chroma_format_idc==0 [13:02:02 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.2:256ebf8bb414: avcodec/dirac_vlc: limit res_bits in APPEND_RESIDUE() [13:02:03 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.2:f3c3cd5afbac: avcodec/diracdec: Fix overflow in DC computation [13:02:04 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.2:03bf78eba693: avcodec/hevcdsp_template: Fix undefined shift in put_hevc_pel_bi_w_pixels [13:02:05 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.2:87ef295ddf53: avcodec/jpeg2000dsp: Fix multiple integer overflows in ict_int() [13:02:06 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.2:2cfabd8ce791: avcodec/shorten: Move buffer allocation and offset init to end of read_header() [13:02:07 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.2:0a5251d28eb6: avcodec/hevc_ps: Fix c?_qp_offset_list size [13:02:08 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.2:98f8f5b12f2a: Update for 3.2.8 [15:53:04 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07n3.2.8:HEAD: avcodec/vorbisenc: Fix mixed declaration and statements [16:54:22 CEST] <cone-934> ffmpeg 03Steven Siloti 07release/3.1:ee17fdffd4cb: avformat/utils: fix memory leak in avformat_free_context [16:54:23 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.1:74e9dbf0dfb0: avcodec/h264_slice: Fix overflow in slice offset [16:54:24 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.1:46023f3258f4: avcodec/aacdec_fixed: fix invalid shift in predict() [16:54:25 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.1:55fe7a738f4c: avcodec/dirac_dwt: Fixes integer overflows in COMPOSE_DAUB97* [16:54:26 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.1:a5c83b586b80: avcodec/mpeg4videodec: Clear mcsel before decoding an image [16:54:27 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.1:df2efc212dab: avcodec/diracdec: Check perspective_exp and zrs_exp. [16:54:28 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.1:1b5548cc0913: avcodec/snowdec: Fix off by 1 error [16:54:29 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.1:96d578602744: avcodec/fic: Fixes signed integer overflow [16:54:30 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.1:b2f99c424f15: avcodec/dirac_dwt_template: Fix integer overflow in vertical_compose53iL0() [16:54:31 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.1:3ee6a9cfb44c: avcodec/me_cmp: Fix crashes on ARM due to misalignment [16:54:32 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.1:1fa31e28fd5d: avcodec/aacdec_template: Fix running cleanup in decode_ics_info() [16:54:33 CEST] <cone-934> ffmpeg 03Vitaly Buka 07release/3.1:edac23286036: avcodec/utils: Fix signed integer overflow in rc_initial_buffer_occupancy initialization [16:54:34 CEST] <cone-934> ffmpeg 03Vitaly Buka 07release/3.1:7b6dba892f63: avformat/mov: Fix signed integer overflows with total_size [16:54:35 CEST] <cone-934> ffmpeg 03Vitaly Buka 07release/3.1:6622be010b09: avformat/aviobuf: Fix signed integer overflow in avio_seek() [16:54:36 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.1:5351c8bd46e2: avformat/rtpdec_h264: Fix heap-buffer-overflow [16:54:37 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.1:0575adfd4a59: avcodec/hevc_ps: Check delta_pocs in ff_hevc_decode_short_term_rps() [16:54:38 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.1:5ff09443c516: ffprobe: Fix null pointer dereference with color primaries [16:54:39 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.1:d4a333f00b50: ffprobe: Fix NULL pointer handling in color parameter printing [16:54:40 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.1:0d32491b7494: avformat/hls: Fix DoS due to infinite loop [16:54:41 CEST] <cone-934> ffmpeg 03Yi and *®() 07release/3.1:0eb399381a2b: avformat/asfdec: Fix DoS due to lack of eof check [16:54:42 CEST] <cone-934> ffmpeg 03Yi and *®() 07release/3.1:64aa8bb886a1: avformat/cinedec: Fix DoS due to lack of eof check [16:54:43 CEST] <cone-934> ffmpeg 03Yi and *®() 07release/3.1:770482def3b3: avformat/rmdec: Fix DoS due to lack of eof check [16:54:44 CEST] <cone-934> ffmpeg 03Yi and *®() 07release/3.1:953c6259d601: avformat/rl2: Fix DoS due to lack of eof check [16:54:45 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.1:28c08ab9434b: avformat/mvdec: Fix DoS due to lack of eof check [16:54:46 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.1:fcc2119eac26: avcodec/sbrdsp_fixed: Fix undefined overflows in autocorrelate() [16:54:47 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.1:f69905e2305b: avcodec/hevc_ps: Fix undefined shift in pcm code [16:54:48 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.1:0e4612ea6826: avcodec/snowdec: Fix integer overflow in decode_subband_slice_buffered() [16:54:49 CEST] <cone-934> ffmpeg 03Yi(SÑ) 07release/3.1:5d6785139213: avformat/nsvdec: Fix DoS due to lack of eof check in nsvs_file_offset loop. [16:54:50 CEST] <cone-934> ffmpeg 03Yi(SÑ) 07release/3.1:92ec4eacf964: avformat/mxfdec: Fix DoS issues in mxf_read_index_entry_array() [16:54:51 CEST] <cone-934> ffmpeg 03Yi(SÑ) 07release/3.1:22dbd1eb31d6: avformat/mxfdec: Fix Sign error in mxf_read_primer_pack() [16:54:52 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.1:93a32c15a849: avcodec/diracdec: Fix integer overflow in INTRA_DC_PRED() [16:54:53 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.1:5cc3add03695: avcodec/dirac_dwt: Fix multiple overflows in 9/7 lifting [16:54:54 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.1:29b950521504: avformat/mov: Fix DoS in read_tfra() [16:54:55 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.1:5e7ddf0b4a69: avformat/asfdec: Fix DoS in asf_build_simple_index() [16:54:56 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.1:10ae5fb26961: avcodec/diracdec: Fix overflow in DC computation [16:54:57 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.1:4b43dd03edde: avcodec/hevcdsp_template: Fix undefined shift in put_hevc_pel_bi_w_pixels [16:54:58 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.1:33e67eb80cf2: avcodec/jpeg2000dsp: Fix multiple integer overflows in ict_int() [16:54:59 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.1:19045efd0573: avcodec/shorten: Move buffer allocation and offset init to end of read_header() [16:55:00 CEST] <cone-934> ffmpeg 03Michael Niedermayer 07release/3.1:61c5c89d0438: avcodec/hevc_ps: Fix c?_qp_offset_list size [19:48:12 CEST] <Ahti333> nevcairiel the commit linked in the trac issue changed avformat_open_input from calling ff_id3v2_read to calling ff_id3v2_read_dict, which doesn't take an avformatcontext parameter, which I assumed was for a reason, but it may be a simpler solution to add a format context parameter to the latter (although ff_id3v2_read_dict seems to be public api so that would be a no-go except for a major release i guess)? i don't know why avformat_open_inpu [19:48:12 CEST] <Ahti333> t was changed in this way. michaelni, could you have a look at this https://trac.ffmpeg.org/ticket/6558 ? you commited the commit mentioned, although it was not written by you [21:55:52 CEST] <michaelni> Ahti333, you should discuss this issue with the author(s) of the patch and the developers reviewing and approving it. Or if you have an idea on how to fix it propose a patch please [21:56:05 CEST] <michaelni> there where at least 2 patches / threads [21:58:45 CEST] <michaelni> an older one from Ben Boeckel, "flac: ignore IDv3 tags if vorbis tags exist"/ "flac: ignore duplicated ID3 tags if vorbis tags exist" and the one from "Paul Arzelier", "[PATCH] Ignore duplicate ID3 tags if vorbis tags exist" [22:55:12 CEST] <cone-797> ffmpeg 03Martin Vignali 07master:9b8c1224d7e1: libavcodec/exr : add X86 SIMD for reorder_pixels [00:00:00 CEST] --- Mon Sep 18 2017

1 0

ffmpeg.log.20170917
by burek 18 Sep '17

18 Sep '17

[00:06:17 CEST] <MelchiorGaspar> Thx for the info.. I use Avanti-GUI [01:25:14 CEST] <wondiws> hello, what should I use instead of AVFrame coded_frame, now that has been deprecated? [01:30:33 CEST] <jkqxz> What are you using it for? You probably want something in the packet or side data. [01:31:58 CEST] <wondiws> jkqxz, I'm not exactly sure; it's not my code, I think they want to get a timestamp or something [01:32:32 CEST] <wondiws> jkqxz, nah, I don't need it anyway [03:09:30 CEST] <notdaniel> Schwarzbaer, you're using it in order to use dash/hls on the fly? [03:10:20 CEST] <Schwarzbaer> notdaniel, I don't have a use case, so... Sure, why not? [03:11:46 CEST] <notdaniel> i'm currently looking for the reverse [03:12:02 CEST] <notdaniel> serving up mp4s from a dash manifest [03:12:42 CEST] <Schwarzbaer> TBH I don't even know what a dash manifest is. [03:14:16 CEST] <notdaniel> so nginx-rtmp is just there for your amusement [03:14:24 CEST] <Schwarzbaer> Yup. [03:14:27 CEST] <notdaniel> rad [03:14:58 CEST] <notdaniel> well, dash/hls are the specs used most now for adaptive video streaming, like how a 720p youtube video will kick down to 480 if your internet slows but back up if it speeds up [03:15:37 CEST] <notdaniel> we recently switched our video platform to _only_ use dash/hls and delete the original mp4 for cost reasons [03:16:30 CEST] <notdaniel> we then discovered that probably 8% of our traffic will never be able view videos again, but we've already made the switch, so i'm now attepting to figure out a hliarious way to remux them back into mp4s on demand for those specific users [03:18:08 CEST] <Schwarzbaer> Yyyyeah, that's the fun bit about hobby projects, "If it works for me, that's good enough." [03:19:11 CEST] <DHE> does ffmpeg not have a dash decoder? I only see an encoder [03:19:14 CEST] <notdaniel> yeah you have that luxury [03:19:21 CEST] <notdaniel> in our case, we get 3000 angry emails [03:19:53 CEST] <notdaniel> DHE, dash isnt a format in itself. the media is typically fragmented mp4s [03:20:11 CEST] <notdaniel> dash is the spec telling the player which media to use at which bandwidth levels [03:20:20 CEST] <DHE> yes, I know. I'm more an HLS guy myself but still. converting an HLS stream back into an .mp4 (by selecting a single bitrate) is easy [03:20:31 CEST] <notdaniel> oh, no, we can totally do it [03:20:55 CEST] <notdaniel> but doing it on demand, without killign performance, while also not incurring the storage costs we started deleting the mp4s to begin with in order to get [03:21:18 CEST] <notdaniel> hls/dash are essentially the same anyway [03:21:38 CEST] <DHE> if you need both, are you sure you can't get the additional storage needed? [03:21:50 CEST] <DHE> clearly you have a need [03:21:56 CEST] <notdaniel> it's why it's great. we use the same media for hls and dash, and they arent segmented. if only we hadn't given the finger to ios9 and ie11 users in the process, it wouldve been perfect [03:22:28 CEST] <notdaniel> DHE, we're a funded but very small startup running a free video platform [03:22:38 CEST] <notdaniel> just deleting the mp4 they uploaded was like a $35k/month savings [03:22:48 CEST] <DHE> amazon s3? (or similar) [03:22:53 CEST] <notdaniel> yup [03:23:17 CEST] <notdaniel> we _thought_ dash/hls was supported enough that this was fine. and in most respects this is still the case -- new iphone release will see upgrades and the problem will be lessened [03:23:48 CEST] <notdaniel> issue is there are sporadic problems with ie and firefox, even in builds that claim to support dash/hls, due to nuances and minor spec changes and such [03:26:59 CEST] <Schwarzbaer> Apparently I'll have a lot of learning to do... Anybody please give me pointers? For instance, AFAIK DASH is a HTTP-based protocol? I assume it's about the data going over a websocket? [03:31:14 CEST] <Schwarzbaer> Also, what is HLS, how does it differ from DASH? [03:33:19 CEST] <notdaniel> hls is a similar concept, but is implemented on ios devices and like ie edge [03:34:00 CEST] <notdaniel> same concept, very slightly different implementation, and as ive mentioned, theyve now merged to the point where you can use the same video files with both, the only difference is the format of the text file with the manifests [03:34:40 CEST] <notdaniel> google favors dash, apple favors hls, both are supported by most platforms and browsers that existed after 2015 [03:34:40 CEST] <Schwarzbaer> I see. Suddenly I'm not interested in HLS anymore, but thank you. ^^ [03:34:44 CEST] <notdaniel> haha [03:34:53 CEST] <notdaniel> well, cant give the finger to ios users :) [03:35:13 CEST] <Schwarzbaer> Not if you're paid, sure. Freedom of the hobbyist... ^^ [03:35:23 CEST] <notdaniel> and again, the videos are the same. in order to spit out hls alongside dash, i literally just add an --hls flag to the dash command [03:35:31 CEST] <Schwarzbaer> How much work is involved in providing both, though? [03:35:52 CEST] <Schwarzbaer> I see. [03:35:55 CEST] <notdaniel> actual work? one long command to a free open source tool [03:36:05 CEST] <notdaniel> costs of bandwidth and such are a whole other ball game [03:36:25 CEST] <notdaniel> but we're still saving 50% beause hls and dash share the same video files [03:36:43 CEST] <notdaniel> bento4 is the tool to use for this [03:37:00 CEST] <Schwarzbaer> At what part does DASH come into play, anyway? I assume that it's yet another protocol, thus one more module in nginx? [03:37:30 CEST] <notdaniel> much simpler [03:37:54 CEST] <notdaniel> dash/hls are the frameworks that tell the player/browser which media to retrieve based on the user's connection speed [03:38:04 CEST] <notdaniel> after that, it's just all basic http requests for the one it picks [03:38:48 CEST] <notdaniel> "use media file A if bandwidth is lower than 8mbit. switch to media B if bandwidth is measured to be at least 14mbit." etc [03:38:48 CEST] <Schwarzbaer> That means I need to provide multiple streams? [03:39:09 CEST] <notdaniel> well sure, so from the original video file, you go make a 1080p, 720p, 480p version [03:39:14 CEST] <notdaniel> (or whatever you want to support) [03:39:17 CEST] <Schwarzbaer> And here I was hoping it was a matter of on-the-fly recoding. Which probably wouldn't scale, though. [03:39:42 CEST] <notdaniel> nginx-rtmp does do this on the fly supposedly [03:39:49 CEST] <Schwarzbaer> Right now, I have a 640x480 webcam as my media source. ^^ [03:39:52 CEST] <notdaniel> we are doing this all ourselves [03:40:04 CEST] <notdaniel> haha well then you dont even need dash anyway :P the lowest resolution is the only choice [03:40:46 CEST] <notdaniel> we have people uploading shit in like 4k 60p needlessly [03:41:09 CEST] <notdaniel> so we go make a bunch of versions of it and then dash/hls will switch to a different format every few seconds if bandwdith is too low/high [03:41:23 CEST] <Schwarzbaer> Actually, 640x480 is high for my circumstances. It works within my LAN (although there's a 7 sec delay, the source of which I haven't found yet), but if I'd be serving that over my 60kb/s connection, I'd still have to downsample that. [03:41:44 CEST] <notdaniel> yeah i suppose it coudl still be a high bitrate despite the resolution [03:41:55 CEST] <notdaniel> if you want to "see" this, here: http://dashif.org/reference/players/javascript/latest/samples/dash-if-refer… [03:42:17 CEST] <notdaniel> just pick anything from the dropdown and hit "load" and then look at the charts, and youll see as the format picks the correct one based on your internet speed [03:42:36 CEST] <notdaniel> force a slowdown in chrome tools and a few seconds later itll adapt. thus is the point, and it's absolutely vital [03:43:22 CEST] <notdaniel> especially for, say, mmobile, where you might have 5mbits and walk ten feet and have nothing for a few seconds and then get 2mbits and etc [03:43:43 CEST] <notdaniel> video would be unbearable on mobile had this not been implemented years ago by youtube and such [03:47:27 CEST] <notdaniel> webtorrent will soon make all of this irrelavent anyway [03:50:07 CEST] <Schwarzbaer> ... Let me guess, ad hoc p2p data distribution networks in everybody's browser? [03:56:21 CEST] <notdaniel> if you go watch a video on bitchute, if someone else also goes to watch it, you'll be seeding it to them as long as youre on it [03:56:30 CEST] <notdaniel> reducing the cost to the video platform [03:56:54 CEST] <Schwarzbaer> I assume that won't just be for video? [03:56:59 CEST] <notdaniel> but the thing that really astounded me is, go open the web inspector and look at all the xhrs bitchute makes [03:57:15 CEST] <notdaniel> it's like several http requests per second, but somehow performance is stellar [03:58:10 CEST] <notdaniel> webrtc can be fun. but this is also only usable in latest browsers, isnt compatible with existing standards, and would also only benefit videos that have multiple concurrent viewers at any given time [03:58:17 CEST] <notdaniel> but still interesting [03:59:11 CEST] <Schwarzbaer> Well, I'm interested in serving large data blobs at some time in the future, so it's still of interest to me... if it's not just for video. [04:00:44 CEST] <notdaniel> webtorrent still implies multiple seeders simultaneously and such [04:01:47 CEST] <notdaniel> but if your use-case is data blobs that are shared by lots of users at any given time, man, stop paying that bandwidth [04:01:50 CEST] <Schwarzbaer> To re-summarize... RTMP is for feeding audio/video to a server, and streaming it from it; DASH is for streaming it, and re-negotiating the video source on the fly, and it's the protocol between player and server. HLS is DASH in Appleish. And webtorrent is the near future. So far, so correct? [04:01:55 CEST] <notdaniel> (once all your users switch to latest firefox and chrome of course) [04:02:36 CEST] <notdaniel> rtmp is a misnomer in the context of nginx-rtmp [04:02:49 CEST] <notdaniel> rtmp was the protocol that video used when everything was flash-based [04:03:15 CEST] <JEEB> no, it's still the feeding protocol [04:03:53 CEST] <JEEB> so it's not a misnomer, and he understands correctly that it looks like <feeder>->RTMP-><nginx><-DASH/HLS over HTTP<-<client> [04:04:14 CEST] <Schwarzbaer> Is it a misnomer for the streaming bit? Because I've pointed a player at the same endpoint, got the stream, and was very confused. [04:04:30 CEST] <JEEB> left of nginx being feeding to the server, and right being what's served to clients [04:04:41 CEST] <JEEB> although of course it also can provide you RTMP as well [04:04:47 CEST] <JEEB> for the client that is [04:05:00 CEST] <JEEB> it's just that usually only software players and flash support RTMP [04:05:07 CEST] <notdaniel> yeah you are correct, but if i read "rtmp" my brain thinks "flash" not "live remuxing to dash/hls" [04:06:43 CEST] <notdaniel> and this is not correct, but it's habit. the practical result is a dash/hls manifest [04:09:04 CEST] <notdaniel> still so much fragmentation out there. IE Edge supports new dash/hls specs with shared fragmented mp4s, but it seems to choke if the manifest is provided as a data blob [04:09:32 CEST] <notdaniel> it's all basically a big mess and we are now paying the price for having tried to save money by deleted our mp4s [05:00:18 CEST] <JC_Yang> quetions about avc1 streams, in this mdsn docs, https://msdn.microsoft.com/zh-cn/library/dd757808(v=vs.85).aspx, it is so stated that the size of length field of avc1 frame can vary, how can I read the size of the length field of a avc1 frame with libavformat? which parameter should I read? AVStream->what? [11:43:15 CEST] <wondiws> hi there [11:48:05 CEST] <wondiws> Just to make sure, I know this is probably a superfluous question, but ffmpeg uses LGPL, right? [11:49:50 CEST] <JEEB> it uses LGPL as long as it's configured with LGPL, there are some components that require additional licensing paramters such as '--enable-version3' or '--enable-gpl' [11:50:14 CEST] <JEEB> or '--enable-nonfree' which is very rare thankfully, but will make binary distribution impossible due to licensing incompatibility [11:50:44 CEST] <JEEB> if you just do ./configure --disable-autodetect -- that should result in an LGPL configured FFmpeg [11:50:51 CEST] <iive> also linking it to GPL library like libx264 turns it into GPL too. [11:51:01 CEST] <JEEB> iive: that's why you require --enable-gpl for libx264 :P [11:52:03 CEST] <wondiws> I read something along the lines that LGPL libraries are usually dynamically linked. Is there some clause that forbids statically linking ffmpeg to your proprietary executable? [11:53:12 CEST] <JEEB> no, but since the LGPL requires you to make it possible to switch the libraries shared linking is more often preferred [11:53:25 CEST] <JEEB> because with static linking you'd have to provide the object files for the proprietary parts [11:53:33 CEST] <JEEB> for the final linking [11:53:43 CEST] <wondiws> JEEB, let me try to digest that for a second [11:53:54 CEST] <wondiws> switch the libraries? [11:54:11 CEST] <JEEB> yes, in other words if someone builds FFmpeg just like you did, he should be able to switch the libraries [11:54:26 CEST] <wondiws> switch to what? [11:54:30 CEST] <JEEB> his own binaries [11:54:36 CEST] <JEEB> not that you have to give support for that, just that it is technically possible [11:54:42 CEST] <JEEB> that's what's in the LGPL [11:54:55 CEST] <JEEB> you give out the source code for the LGPL component (in this case, FFmpeg) [11:55:10 CEST] <JEEB> and make sure that you can technically replace the libraries linked into your application [11:55:14 CEST] <wondiws> but I don't make changes to the ffmpeg code [11:55:18 CEST] <JEEB> that doesn't matter [11:55:29 CEST] <JEEB> the license is the same whether you make changes or not [11:55:55 CEST] <JEEB> you publish sources for the LGPL part + make it possible to change the FFmpeg in your proprietary app [11:56:04 CEST] <JEEB> or whatever is under LGPL I mean [11:56:11 CEST] <iive> the user shuold be able to change its ffmpeg library [11:56:26 CEST] <JEEB> that's why people opt for shared libraries, because the user can just change the solib/dylib/DLL [11:57:06 CEST] <wondiws> oh, so you should be able to update the ffmpeg, and have the proprietary program still be able to work? [11:57:11 CEST] <JEEB> no [11:57:30 CEST] <JEEB> but if the person builds the same version in the same way [11:57:36 CEST] <JEEB> he should be able to technically switch [11:57:51 CEST] <JEEB> since FFmpeg's API changes any larger updates are out of scope (But people can try if they really want to) [11:58:20 CEST] <wondiws> so if you just release a proprietary binary with ffmpeg statically linked into it, you're are not compliant to the ffmpeg license? [11:58:32 CEST] <JEEB> s/ffmpeg license/LGPL/ [11:58:35 CEST] <JEEB> since this is not FFmpeg specific [11:58:45 CEST] <wondiws> yes, the LGPL license [11:58:48 CEST] <JEEB> also no, you can be compliant with static linking [11:58:59 CEST] <JEEB> but you will then have to provide the object files [11:59:03 CEST] <JEEB> for the final linking [11:59:23 CEST] <JEEB> because without them the user cannot replace the LGPL component if he wishes to [11:59:31 CEST] <JEEB> that's why people generally don't do it [11:59:47 CEST] <JEEB> because it's more effort than just having the shared libraries there [11:59:50 CEST] <wondiws> so the end user must have the possibility to do the linking process himself? [11:59:59 CEST] <JEEB> with static libraries yes [12:00:03 CEST] <wondiws> ah ok [12:00:05 CEST] <JEEB> since that's how you replace the library [12:00:22 CEST] <JEEB> with dynamic libraries it's often enough to just replace the solib/dylib/DLL [12:00:41 CEST] <wondiws> ah I see [12:00:48 CEST] <Fyr> guys, I experience some troubles in conversion. please, take a look at this: [12:00:48 CEST] <Fyr> https://pastebin.com/PyCyevgD [12:01:34 CEST] <Fyr> all the 23 episodes were converted successfully, only the final failed. [12:01:48 CEST] <wondiws> I'm using ffmpeg in this program, I use a MJPEG stream. Is it possible to use OMX (raspberry pi) acceleration on MJPEG? [12:02:44 CEST] <JEEB> Fyr: seems like it stumbled on invalid chapters? [12:03:01 CEST] <Fyr> JEEB, so, it's only the wrong metadata? [12:03:11 CEST] <Fyr> I don't really need chapters. [12:03:23 CEST] <JEEB> that's how it looks like, since the failed write happens right after the chapter error in the matroska muxer [12:03:34 CEST] <JEEB> there was a way to ignore the metadata or so I think? [12:03:40 CEST] <Fyr> ok, how do I avoid metadata? [12:03:44 CEST] <JEEB> also rip shana. that BD upscale was bad :< [12:03:57 CEST] <JEEB> they warpsharp()'d it to hell and back [12:03:58 CEST] <Fyr> JEEB, I'm ripping. [12:04:12 CEST] <Fyr> I've downloaded and trying to convert the video. [12:04:21 CEST] <JEEB> basically the upscaling they did for the TV was OK, but the blu-rays are goddamn awful [12:04:23 CEST] <Fyr> (to watch it on my ipad) [12:04:34 CEST] <Fyr> I know [12:04:42 CEST] <JEEB> well, then you know :P [12:04:46 CEST] <Fyr> I'm trying to make the bitrate right. [12:04:55 CEST] <JEEB> wondiws: there's OMX hwaccel for some formats but not sure about MJPEG [12:05:05 CEST] <Fyr> JEEB, what is the way to exclude metadata? [12:05:30 CEST] <JEEB> it should be mentioned somewhere on ffmpeg-all.html, I just don't fucking know out of the top of my mind :D [12:05:36 CEST] <JEEB> I just know it exists [12:05:41 CEST] <JEEB> I think it had to do with mapping [12:06:26 CEST] <Fyr> -map_metadata -1 doesn't work. [12:06:43 CEST] <Fyr> FFMPEG still tries to open the metadata to avoid it. [12:07:19 CEST] <Fyr> and stops the conversion as soon as finds out that it's invalid. [12:07:30 CEST] <JEEB> rip [12:07:39 CEST] <Fyr> I tried to pipe the video, however failed with the same reason. [12:07:50 CEST] <JEEB> use mkvmerge or something to pre-process the file first [12:13:02 CEST] <wondiws> JEEB, where do I need to search for in ffmpeg-all? :) [12:14:00 CEST] <wondiws> I know I can encode h264 using "ffmpeg -i whatever.vob -vcodec h264_omx output.mp4" [12:14:10 CEST] <JEEB> uhh, that was for Fyr [12:14:36 CEST] <wondiws> :( [12:15:26 CEST] <wondiws> gstreamer does support mjpeg, but gstreamer doesn't use ffmpeg code, right? [12:15:34 CEST] <wondiws> (I've never used gstreamer before) [12:16:51 CEST] <JEEB> it uses FFmpeg in the background in various cases [12:16:58 CEST] <JEEB> also omx.c seems to mostly/only encode [12:17:03 CEST] <JEEB> under libavcodec [12:17:15 CEST] <wondiws> JEEB, and probably only h264, right? [12:17:19 CEST] <wondiws> or perhaps h263? [12:17:27 CEST] <wondiws> I think I recently looked there [12:17:28 CEST] <JEEB> it also has mpeg-4 part 2 and AVC [12:17:37 CEST] <wondiws> yeah, h263 [12:17:37 CEST] <JEEB> so yes, two formats that I can see [12:17:41 CEST] <JEEB> no, H.263 is different [12:17:49 CEST] <wondiws> I thought that was part 2? [12:18:13 CEST] <JEEB> part 2 based on H.263 but removed features [12:18:17 CEST] <JEEB> like in-loop deblocking [12:18:28 CEST] <JEEB> which is why ITU-T never adopted MPEG-4 Part 2 [12:18:54 CEST] <wondiws> but MPEG-4 part 2 does comply with h263, just not the other way around? ;) [12:19:19 CEST] <JEEB> not sure about that [12:19:34 CEST] <wondiws> if part2 is a subset of h263, but nevermind [12:19:39 CEST] <JEEB> yes, IFF it is [12:19:52 CEST] <JEEB> I am not sure of the bit stream [12:23:33 CEST] <JC_Yang> that's no known-to-me way to read this piece of information, the length header size... help please [12:29:05 CEST] <Fyr> I've posted the bug report. [12:34:28 CEST] <furq> wondiws: last time i checked ffmpeg's mmal implementation only supports h264 [12:34:56 CEST] <wondiws> furq, we just established it also supports MPEG-4 part 2 ;) [12:35:04 CEST] <furq> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/mmaldec.c#L376-L388 [12:35:15 CEST] <furq> i'm probably remembering wrong but i did remember there's no mjpeg [12:35:27 CEST] <JEEB> furq: right, the decoder was MMAL [12:35:31 CEST] <furq> yeah [12:35:32 CEST] <JEEB> omx.c had just the encoders [12:35:40 CEST] <JEEB> which were mpeg-4 part 2 / AVC [12:36:19 CEST] <furq> also i assume you still need to buy the m2v/vc-1 decoders for ffmpeg to be able to use them [12:39:48 CEST] <wondiws> oh, so I can decode MPEG2 using mmal? [12:40:00 CEST] <wondiws> and mpeg4, vc1, h264? [12:40:59 CEST] <Fyr> what is "h264_mmal"? [12:41:12 CEST] <Fyr> I can't find an explanation for this. [12:43:04 CEST] <furq> mmal is the raspberry pi's hardware decoder [12:43:14 CEST] <furq> wondiws: you sure can [12:43:32 CEST] <furq> mmal does definitely support mjpeg but it looks like it's not made it into libavcodec yet [12:43:59 CEST] <furq> which is odd considering 90% of support questions in here about an rpi not working are about usb2 webcams [12:48:28 CEST] <wondiws> "unknown decoder mpeg2_mmal" :( [12:49:00 CEST] <wondiws> furq, also the dedicated RPi camera is tied in to the omx chip [12:56:41 CEST] <wondiws> wow, I disabled audio encoding, and the I go from 26fps to 110fps encoding [12:59:18 CEST] <furq> nice [12:59:36 CEST] <furq> what codec [13:00:17 CEST] <wondiws> furq, h264_omx [13:00:24 CEST] <furq> i mean what audio codec [13:00:40 CEST] <wondiws> oh, previously I got aac [13:00:56 CEST] <furq> you might want to try with fdk if your build has it [13:01:04 CEST] <furq> or lame [13:01:28 CEST] <wondiws> furq, I think AVC should be accompanied by AAC ;) [13:01:40 CEST] <furq> fdk is an aac encoder [13:01:56 CEST] <furq> it's optimised for android so maybe it'll be faster on arm, idk [13:02:07 CEST] <wondiws> furq, in due time ;) [13:02:11 CEST] <furq> but yeah lame will definitely be faster than either [13:10:18 CEST] <wondiws> furq, great I got a 200kbps video... why in the world would it default to such rate... [13:10:30 CEST] <wondiws> with HEVC it might be watchable though :P [13:15:09 CEST] <doslas> Hi [13:15:15 CEST] <doslas> https://imgur.com/O4BZK4J [13:15:19 CEST] <doslas> Opera [13:23:20 CEST] <JEEB> wondiws: that's the libavcodec default if the encoder doesn't override it :) [15:51:26 CEST] <arpu> can i use drawtext on a 360 video equirectangular? i think i need to remap the rectangualr font to equirectangular? [17:45:35 CEST] <timofonic> Hello [17:48:55 CEST] <timofonic> Is it true FFmpeg has some specific features related to streaming? They reiterate FFmpeg is very bad at downloading HLS streams for different reasons (lack of http keep-alive support and bad bitrate selection). They also say it has very basic MPEG-DASH and RTMP support. Has this changed? Any hope? [19:45:18 CEST] <DHE> timofonic: ffmpeg generally doesn't select a bitrate. if you're making a player, you likely want to make your own DASH parser and just have ffmpeg parse/decode the real video files [19:46:09 CEST] <DHE> RTMP is supported, but ffmpeg is not an RMTP server. It is an endpoint. Use something like nginx-rtmp and have ffmpeg feed it [21:04:36 CEST] <panzerknacker> Hello everyone! [21:07:55 CEST] <panzerknacker> I have a question: I'm using Dave Rice' Filter from here (http://dericed.com/2012/display-video-difference-with-ffmpegs-overlay-filte…) to compare files, and just noted that if I compare the same file (using same -i both times) that it does show differences in the output, while I understand that it should not show anything at all since there is no difference. The line I'm using is: https://pastebin.com/ynxuuFvQ [21:09:40 CEST] <panzerknacker> The question being, what am I doing wrong :) [21:13:14 CEST] <furq> you can just use lut2 for that [21:13:19 CEST] <furq> !filter lut2 @panzerknacker [21:13:19 CEST] <nfobot> panzerknacker: http://ffmpeg.org/ffmpeg-filters.html#lut2_002c-tlut2 [21:26:08 CEST] <DHE> shouldn't you use a semicolon in a filter_complex when using [labeledoutputs] ? [21:26:33 CEST] <DHE> I mean the one before the [0:v] labeled input [21:27:39 CEST] <SavinaRoja> so I am working on trying to prepare a video file for MPEG-Dash streaming, and I've managed to effectively allocate keyframes for stream fragmentation, but the tool I'm trying to use to prepare the manifest appears to be complaining that the audio stream is not fragmented [21:30:32 CEST] <SavinaRoja> my general question is: is there an audio codec reference I should look at to see how I might set up a fragmented stream for audio? [21:54:59 CEST] <SavinaRoja> I don't even seem to google anything up about how to fragment an audio stream in mp4, except that it can be done by a tool in bento4 [22:17:34 CEST] <SavinaRoja> finally realized I was being daft, the fragmentation is configured on the container, not the stream [22:18:16 CEST] <SavinaRoja> -frag_duration in https://ffmpeg.org/ffmpeg-formats.html#Options-8 is what I wanted [22:52:53 CEST] <timofonic> DHE: RTMP server why?? Why not put that code into FFmpeg and avoid code duplication? [22:53:41 CEST] <BtbN> Because ffmpeg is not a server, not suited to act as one. [23:04:30 CEST] <DHE> timofonic: a server needs to handle a large number of simultaneous sockets. that's not the intended use of the ffmpeg RTMP muxer. nginx is much better suited to this [00:00:00 CEST] --- Mon Sep 18 2017

1 0

ffmpeg-devel.log.20170916
by burek 17 Sep '17

17 Sep '17

[00:40:02 CEST] <testsin> Hi [00:40:06 CEST] <testsin> @Holden [01:08:03 CEST] <cone-379> ffmpeg 03Kaustubh Raste 07master:e5a650e14154: avcodec/mips: Improve avc lpf msa functions [01:08:04 CEST] <cone-379> ffmpeg 03Kaustubh Raste 07master:0105ed551cb9: avcodec/mips: Improve avc mc copy msa functions [01:08:05 CEST] <cone-379> ffmpeg 03Kaustubh Raste 07master:1a85fb7e1eb3: avcodec/mips: Improve hevc sao band filter msa functions [01:08:06 CEST] <cone-379> ffmpeg 03Thomas Mundt 07master:a7f6bfdc185a: avfilter/interlace: prevent over-sharpening with the complex low-pass filter [01:08:07 CEST] <cone-379> ffmpeg 03Thomas Mundt 07master:ed48e22748ee: avfilter/interlace: simplify code [01:08:08 CEST] <cone-379> ffmpeg 03Thierry Foucu 07master:42a41c395697: vf_fps: Fix memory leak introduced by eea64ef4 [01:38:15 CEST] <atomnuker> jamrial: if postproc isn't enabled (which here it isn't enabled by default) libavfilter's pkg-config still indicates it depends on libpostproc [01:38:51 CEST] <atomnuker> (so it fails if you look for libavfilter) [01:44:38 CEST] <atomnuker> the hell, even with --disable-postproc it's still depending on libpostproc [02:27:30 CEST] <tmm1> Anssi: i'd like to teach hls.c to take advantage of http keep-alives, to avoid making a new tcp connection for every segment. any thoughts on the matter? [02:27:36 CEST] <jamrial> atomnuker: https://pastebin.com/raw/EBAXvrvy [02:28:18 CEST] <tmm1> seems it would be easier if using URLContext with ff_http_do_new_request(), but hls.c was converted from using URLContext to AVIOContext [02:35:23 CEST] <tmm1> well AVIOContext seems to wrap URLContext for http anyway, so it should be possible to create the context with multiple_requests=1, keep it open and then re-use it for subsequent requests [02:35:57 CEST] <nevcairiel> URLContext should not be used outside of avio [02:46:03 CEST] <tmm1> hmm ok [02:46:32 CEST] <atomnuker> jamrial: pkg-config files get regenerated after a configure, right? [02:47:41 CEST] <tmm1> so maybe io_open can be passed an existing AVIOContext along with something like AVIO_FLAG_REUSE and it will re-use if the underlying context is a URLContext and re-use is possible (http host matches existing connection) [02:53:43 CEST] <jamrial> atomnuker: if you run configure without first doing make clean or make distclean it will not be regenerated. the build system only tracks the library's version.h file as dependency for the .pc files it seems [02:55:08 CEST] <jamrial> sorry, distclean only. .pc is a distclean suffix [02:58:18 CEST] <atomnuker> ok, that solves it then [02:58:25 CEST] <atomnuker> I basically never run distclean [02:59:10 CEST] <jamrial> i never do it either. i run "rm -rf *" on my out-of-tree build folder :p [03:00:26 CEST] <jamrial> guess it should depend on something else. just the library's version.h is insufficient [03:01:26 CEST] <jamrial> maybe config.h [03:02:59 CEST] <jamrial> mmh, fuck, it should probably track version.h of every other library the library depends on as well, or something like that [04:34:37 CEST] <cone-553> ffmpeg 03Aman Gupta 07master:73bf0f42e342: avformat/hlsenc: fix segfault when using -hls_segment_type fmp4 with -hls_segment_filename [16:57:14 CEST] <cone-411> ffmpeg 03Reimar Döffinger 07master:a149fa97d950: avcodec/frame_thread_encoder: Fix AV_OPT_TYPE_STRING handling in avctx [19:56:04 CEST] <cone-411> ffmpeg 03Michael Niedermayer 07master:0f5576a22b11: avutil/imgutils: Fix warning: missing braces around initializer [19:56:05 CEST] <cone-411> ffmpeg 03Michael Niedermayer 07master:d76838c1adc2: avcodec/fits: Fix include type [19:56:06 CEST] <cone-411> ffmpeg 03Michael Niedermayer 07master:08ec828de966: avcodec/vorbisenc: Fix mixed declaration and statements [00:00:00 CEST] --- Sun Sep 17 2017

1 0

ffmpeg.log.20170916
by burek 17 Sep '17

17 Sep '17

[00:02:34 CEST] <DHE> no, it's a safety setting in ffmpeg in case someone gives you a 32000x32000 resolution video in an attempt to cause your system to swap itself to death [00:03:11 CEST] <DHE> you're looking for -maxrate for most codecs [00:04:16 CEST] <Ober> hmm usage() is not returning that as a valid option [00:04:31 CEST] <DHE> what are you looking at? [00:04:39 CEST] <Ober> --help output [00:04:43 CEST] <DHE> of ffmpeg? [00:04:53 CEST] <Ober> Unrecognized option '-maxrate'. [00:05:08 CEST] <Ober> this is 3.3.4 [00:06:47 CEST] <DHE> $ ffmpeg -f lavfi -i testsrc2 -t 30 -c libx264 -maxrate 1M -b 1M -bufsize 1M output.mp4 # generates a test pattern video named output.mp4, 30 seconds long, about 1 megabit on the video [00:07:16 CEST] <Ober> what version? HEAD? [00:07:40 CEST] <DHE> this particular version I'm running is a git build from june 2017 [00:07:52 CEST] <DHE> but it should still work as long as it has libx264 enabled [00:07:52 CEST] <Ober> ahh. brew here [00:11:55 CEST] <Ober> order args no doubt [00:12:00 CEST] <Ober> order of args rather [00:12:39 CEST] <Ober> thanks for the example [00:16:46 CEST] <DHE> ffmpeg [input 1 opts] -i input1 [[input 2 opts] -i input2] ... [output1 opts] output1 [[output2 opts] output2]... [00:17:01 CEST] <DHE> some args are global, so their position doesn't matter [00:18:33 CEST] <Ober> clearly for options that are codec specific their position matters [00:35:51 CEST] <thebombzen> Ober: you can mitigate this by using -maxrate:v which causes it to only apply to video streams [00:36:02 CEST] <thebombzen> same with -b, which you should by habit use -b:v anyway rather than just -b [00:36:13 CEST] <thebombzen> otherwise -b will apply to the audio streams too [00:36:55 CEST] <Ober> right. [00:37:38 CEST] <thebombzen> so the order of options doesn't matter much for codecs. what does matter is that for output options, latter options take precedence [00:37:53 CEST] <thebombzen> so if you use -c copy -c:v libx264, it'll copy all streams except it'll use libx264 for all video streams [00:38:11 CEST] <thebombzen> using -c:v libx264 -c copy will copy everything, because -c copy applies to all streams and it comes later [00:38:43 CEST] <thebombzen> the order of global options like -hide_banner or -y doesn't matter much (although -y should be an output option, I feel) [00:42:11 CEST] <microchip_> Ober: keep in mind. Last option overwrites all previous ones :) [00:42:53 CEST] <DHE> but order still matters. it has to come before the output filename, but after the input filename [00:43:01 CEST] <microchip_> right [00:43:05 CEST] <DHE> I suspect that was his problemn [00:50:14 CEST] <Ober> yeah it was [05:28:37 CEST] <berndj> can i get a video-diff with ffmpeg, to see if (and how) two video files differ? [05:33:55 CEST] <blap> you can diff the files [05:37:45 CEST] <berndj> i don't want a bytewise diff; i want something like a frame-by-frame subtract operation [07:03:53 CEST] <blap> berndj: interesting idea [07:04:16 CEST] <blap> you could use it to detect manipulated video, or encoding errors [07:05:04 CEST] <berndj> yes. right now i just want to see if anything changed in some random youtube video i downloaded some time ago, and apparently again two days ago. same video id, but different (bytewise) contents [07:06:17 CEST] <blap> searching... [07:09:13 CEST] <blap> the simplest plugin would be one that creates an output video simply consisting of per-pixel difference of each frame, perhaps normalized/expanded for visibility [07:13:58 CEST] <blap> berndj: maybe the blend filter [07:14:52 CEST] <blap> http://trac.ffmpeg.org/ticket/5586 this has an example of usage [07:15:41 CEST] <Ober> do does webm have equivalents to maxrate bufsize and bitrate? [07:16:14 CEST] <blap> https://ffmpeg.org/ffmpeg-filters.html#blend [07:16:54 CEST] <blap> use 'difference' [07:18:16 CEST] <jasom> how do I encode streams that aren't present at the beginning of my input? I have a TS where the audio starts at ~.250 seconds in and -map 0:a:0 says "Stream map '0:a:0' matches no streams." [07:19:54 CEST] <blap> you're welcome berndj :) [07:19:59 CEST] <berndj> bleh, the version of ffmpeg i have doesn't have filter_complex (debian jessie version) [07:20:16 CEST] <berndj> thanks though, at least i have something to look forward to [07:22:07 CEST] <blap> or compile it. apt-get build-dep ffmpeg should pull-in all needed libraries and headers [07:44:21 CEST] <berndj> oh well, i did an eyeball-diff [07:52:45 CEST] <Schwarzbaer> Hi. I'm using 'ffplay -i /dev/video0 -vf "vflip,hflip"' to use a weirdly upside-down webcam; that works well. I've set up a very basic ffserver, use ffmpeg to stream the camera to it, use ffplay to watch it; works nice. Then I added the aforementioned -vf arguments to the feeding ffmpeg; nothing happens. The image is as upside-down as it was before. Why, and how do I fix it? [07:55:15 CEST] <blap> the video filter works for me [08:02:26 CEST] <jasom> aha, I found the answer buried in the wiki; specifyign -probesize 50M -analyzeduration 50M before the -i flag works. Couldn't find either of those in the official docs though [08:03:31 CEST] <jasom> ah, it's in ffmpeg-formats [08:09:09 CEST] <Ober> jasom: lisp? really? [08:09:44 CEST] <jasom> Ober: no, not really; I'm just in that channel to specifically troll you [08:11:12 CEST] <jasom> Ober: wait, are you akkad? [08:32:26 CEST] <Ober> yes [08:32:33 CEST] <Ober> why fore? [08:32:34 CEST] <Ober> for [08:37:10 CEST] <Ober> jasom: ever use Clame? [08:37:27 CEST] <Ober> clave rather [08:45:45 CEST] <jasom> Ober: nope [08:47:06 CEST] <Ober> jasom: you know akkad? [08:47:22 CEST] <jasom> Ober: remember seeing you in #lisp in the past [11:18:01 CEST] <Fyr> guys, when doing a weather forecast people replace green color on video with another video. is it possible to that with FFMPEG? [11:22:38 CEST] <klaxa> https://ffmpeg.org/ffmpeg-filters.html#chromakey [11:24:08 CEST] <Fyr> thanks [11:24:24 CEST] <Fyr> I didn't know what I should google. [11:26:11 CEST] <Fyr> I've found out how to put subtitles with scaling onto a video. [11:26:27 CEST] <Fyr> using chromakey! [11:42:15 CEST] <furq> didn't you want good antialiasing [11:42:50 CEST] <furq> this was 15 minutes ago so you probably already found out for yourself, but you are not going to get nice edges with chromakey [12:49:04 CEST] <Fyr> furq, I guess, those people that do weather forecast don't use FFMPEG. [12:49:51 CEST] <furq> i should hope not [12:50:01 CEST] <Fyr> =) [12:50:47 CEST] <furq> i did something similar to this before but i can't remember what i did now [12:50:56 CEST] <furq> something like color=#00000000,format=yuva420p [12:51:08 CEST] <furq> then draw on that, resize and overlay [12:58:01 CEST] <CoreX> green screen porn? [12:59:28 CEST] <Fyr> CoreX, I'm trying to smooth subtitles on video when burning them. [13:35:43 CEST] <Fyr> guys, one should add +faststart for MP4. is there the same option for MKV? [13:36:15 CEST] <JEEB> no, matroska doesn't require the index for playback [13:36:25 CEST] <JEEB> since it keeps the codec specific init data in a specific structure that's separate [13:36:41 CEST] <Fyr> I found an option: reserve_index_space [13:36:41 CEST] <JEEB> while in mp4 that data is in the index, which has to be written last due to well, duh [13:37:15 CEST] <JEEB> yea, but it's not as useful because the initialization data is generally written in the beginning of the file [13:37:21 CEST] <JEEB> since it's not in the index in matroska [13:37:30 CEST] <Fyr> ok [13:37:52 CEST] <JEEB> as in, if you start writing into a .mkv file you should be able to play it as soon as the init data is written [14:43:02 CEST] <arpu> is it possible to use the av1 encoder with ffmpeg? [14:44:47 CEST] <ZexaronS> bwaahha i looked at some video codecs in depth and noticed for the first time ever XvidDivX is called MPEG-4 ASP , asp for Advanced Simple Profile lfao [14:44:50 CEST] <ZexaronS> lmfao [14:45:07 CEST] <ZexaronS> advanced simple [14:45:54 CEST] <ZexaronS> this whole european boreucrat standards just got to a new level of ridicolousness [14:46:30 CEST] <ZexaronS> actual programmers in computers/gaming need to work on these things, not mathematicians and physicists from france, belgium and germany [14:46:46 CEST] <ZexaronS> they have no clue wtf are they talking about [14:48:46 CEST] <ZexaronS> there's really no proper archival codec out there, thinking of just making it myself then, on github, or if I could find such a project that exists already [14:49:03 CEST] <ZexaronS> it should be built from ground up to go well with stuff like ZFS/BTRFS [14:49:06 CEST] <JEEB> EU is currently trying to standardize ffv1 and matroska for archival [14:49:13 CEST] <JEEB> ffv1 being a lossless video format [14:49:21 CEST] <JEEB> and matroska being a container [14:50:02 CEST] <JEEB> (and I think FLAC is being poked as the audio, although usually there's not enough audio data compared to compressed video that would raise the file size largely even if it was raw PCM [14:50:41 CEST] <JEEB> arpu: libaom is not included yet because the whole AV1 stuff isn't stabilized yet [14:50:54 CEST] <JEEB> so even if you'd build libaom and encode stuff with it today [14:51:14 CEST] <JEEB> that might not be playback'able when the AV1 format is finished [14:51:31 CEST] <JEEB> since the whole thing is still in development from the format point of view as well [14:52:51 CEST] <ZexaronS> But that's a bit too hardcore unless you have a 500 billion dollar underground datacenter ... I'm not keen on totally uncompressed, I'm thinking of a really simple and super-future-proof-endtimes-dig-up-old-data-drive-from-frozen-lake kind of proof ... nees to have a ton of features build in and the design to be easily decodable, so the mpeg-TS kind of redundancy is what should it be based upon, but not sure if going to to having an [14:52:51 CEST] <ZexaronS> index/metadata per-frame would be so wise either, that would definitely prove to be very corruption-resistant, so you'd get all the non-corrupt frames out piece of cake, but it add to the size [14:53:41 CEST] <JEEB> well, consider that compressed lossless video will go to dozens of megabits if not hundreds [14:53:56 CEST] <JEEB> and then you have a few megabits of audio at most [14:54:05 CEST] <JEEB> you might as well not compress at that point :P [14:55:22 CEST] <ZexaronS> but it wouldn't be like H264, it wouldn't be doing those kinds of tradeoffs of quality, this archival format would be also meant to made for quality [14:55:57 CEST] <JEEB> you make no sense to be honest at this point [14:56:07 CEST] <ZexaronS> well I meant about slight lossy compression, like 95% ... for example in JPEG, if you see size diff from 100% and 96% it's a lot, but it doesn't look that much different [14:56:38 CEST] <ZexaronS> then it would also have lossless compression mode and the totally uncompressed mode [14:56:50 CEST] <JEEB> bits and pieces of something semi-coherent and a lot of stuff that just is out there most likely due to you not understanding the problem space [14:57:23 CEST] <ZexaronS> No no I don't need to understand the problems out there, I'm talking a format/codec that I want [14:57:45 CEST] <ZexaronS> for myself, but i would share it ofcourse [14:58:00 CEST] <JEEB> please just don't NIH shit for NIH's sake because you don't understand things [14:58:23 CEST] <JEEB> also my "might as well not compress at that point" comment was towards audio, if that was not yet clear enough [14:58:39 CEST] <JEEB> video should 100% be losslessly compressed for archival [14:59:18 CEST] <JEEB> and lossy compression for archival just doesn't make sense [14:59:23 CEST] <ZexaronS> I have no idea what NIH is and the stuff I was talking about is what I would want someday, If I get a good job and have the necessary resources I will pay developers to do it for me, as I don't have the necessary programming experience and have a ton of other projects I'd be working on to have time for learning deep c++ [14:59:33 CEST] <JEEB> Not Invented Here (syndrome) [15:00:13 CEST] <JEEB> just fucking use ffv1+flac+matroska if you need to archive shit. [15:00:23 CEST] <JEEB> since the EU folk are moving to standardizing that trio for archival [15:00:32 CEST] <JEEB> and ffv1 actually can give good lossless compression ratios [15:01:29 CEST] <ZexaronS> You are correct but for me personally, I don't have the resources of a 100 billion datacenter to have it all uncompressed, that's a dream so I'm not going to assume I'll ever have my own underground facility, so I can't go this extreme route [15:01:40 CEST] <JEEB> are you even reading me? [15:01:52 CEST] <JEEB> where am I saying uncompressed? [15:02:02 CEST] <ZexaronS> okay okay [15:02:04 CEST] <JEEB> other than regarding audio [15:02:08 CEST] <JEEB> which is miniscule in the fucking size [15:02:13 CEST] <JEEB> compared to video [15:02:23 CEST] <JEEB> because generally you have 2 channels of PCM [15:02:38 CEST] <ZexaronS> I didn't catch that, fine, but you don't need to take it like ... I was saying it in general. [15:03:02 CEST] <JEEB> I'm just telling you there are solutions for the fucking archival problem [15:03:08 CEST] <ZexaronS> I didn't knew ffv1 is lossless compression [15:03:18 CEST] <JEEB> I said it multiple times for fuck's sake [15:03:34 CEST] <ZexaronS> the size seemed pretty big when I tried ... but yeah I didn't knew much 3 years ago when I was doing those tests/initial research [15:03:51 CEST] <JEEB> lossless is always big, and there's parameters to tweak [15:04:00 CEST] <JEEB> I mean, bigger than highly compressed lossy shit [15:04:06 CEST] <JEEB> but you're doing *archival* [15:04:13 CEST] <JEEB> you'd archive something to conserve it [15:04:19 CEST] <JEEB> as it was originally [15:04:47 CEST] <JEEB> so you build your RAID, with redundancy, take checksums, do back-ups [15:04:55 CEST] <JEEB> maybe use tapes [15:05:16 CEST] <JEEB> check the consistency of data periodically between the copies of data etc [15:06:43 CEST] <ZexaronS> Actually, I get your point from the fact of visuals, the thing is, most of my things are not really visually important, they're just interviews, people sitting and talking, some of them are visually important, the context/evidence is transferred to a future viewer they same no matter if visual quality is 100 or 80 or even 50%, imo [15:07:26 CEST] <JEEB> then you go off for a slippery slope [15:07:44 CEST] <JEEB> because it's easy to define the input as the thing you archive [15:08:06 CEST] <JEEB> but if someone wants you to arvhive something, how do you define how much loss they're OK with? [15:08:23 CEST] <ZexaronS> The stuff that I'd archive right now, ofcourse in future visuals might get a lot more important when HDR/WCG Rec2020 is involved and I think we'll have to even put features in for authenticity stuff, the virtual reality graphics will be booming with all the fakes [15:09:42 CEST] <JEEB> also lossless copies are easier to validate [15:09:49 CEST] <ZexaronS> and ffv1 has no things build in that would help the analyzer or an analysis tool to get metadata/info about the video to look for clues that would help with figuring out if it's forged/simulated [15:09:57 CEST] <ZexaronS> built* [15:10:13 CEST] <ZexaronS> allright then we use ffv1 as base and make ffv2 [15:10:17 CEST] <JEEB> that is not a fucking job of a fucking video format. you sign the fucking archived thing [15:10:33 CEST] <JEEB> then if the signature is OK you know that data has not been played around with since archival [15:10:46 CEST] <JEEB> if the archival process was fooled with you have a separate problem [15:11:07 CEST] <ZexaronS> well that's more complicated then in a post-doomsday scenario with .. high-tech is very fragile [15:11:57 CEST] <JEEB> and? if your requirements are to hold through such a scenario then you have to design with it in mind [15:12:07 CEST] <ZexaronS> This is crazy, I can't even find a full video of something from 3 years ago, only short crappy copies ... things move so fast that old things get forgotten, data is made but also erased out there [15:12:21 CEST] <JEEB> it's not a job of your fucking video format. a video encoder takes in raw images and outputs decode'able pieces of data [15:13:01 CEST] <JEEB> if you need validity of that data you use signing or something to "stamp" the matroska container of an archived "unit" [15:13:08 CEST] <ZexaronS> Well look I have it more thought out in my mind than I can bring out so it feels I'm throwing random things up, but I meant ... [15:13:51 CEST] <JEEB> and then you can have per-sample metadata for checksums [15:13:56 CEST] <JEEB> which is different from trust [15:14:14 CEST] <JEEB> and rather putting data validity checkers there for backup verification [15:14:58 CEST] <JEEB> and the whole nuclear doomsday scenario is anyways its own set of requirements and you just handle it on its own level, if it is required [15:15:05 CEST] <ZexaronS> I meant that it would have support for whatever camera natively would use it for encoding/saving, and authenticity stuff (metadata about camera sensor, advanced deep stuff, stuff that doesn't exist yet) would be written in some fashing along with the codec, but why with the codec, well it has to be per-frame if you want 100% of the video covered [15:15:28 CEST] <ZexaronS> So if that video gets shared, you have it in there, in the source, [15:15:28 CEST] <JEEB> or you just do per-sample metadata like I mentioned [15:16:38 CEST] <JEEB> so if you have your magical camera metadata there per-frame, you have per-frame checksum metadata there and then you sign the fucker at the end of that single unit (whatever that is in the end) [15:17:57 CEST] <ZexaronS> I get the point of authenticity of the datacenter it self, that one thing, this is another thing, if the source gets shared, so you have many sites hosting the source, ...SHA265 won't be enough, the supercomputers outthere in future could crack it, use a forged video, bruteforce the necessary finetuning of the bits to make the hash identical, and were screwed [15:18:10 CEST] <ZexaronS> the datacenter would also be offline, not connected to net [15:19:18 CEST] <arpu> JEEB, thx for this information , i found this https://bugzilla.mozilla.org/show_bug.cgi?id=1368838 so firefox nightly can play av1 now! [15:19:29 CEST] <arpu> so i want to try this [15:19:32 CEST] <JEEB> if someone cares enough to brute force N sample checksums and forge your signature with the private key that you have not published anywhere I'd commend them [15:20:03 CEST] <JEEB> arpu: yea they started enabling libaom-based decoding [15:20:20 CEST] <JEEB> and yes the comments there note exactly why FFmpeg doesn't yet support libaom out of the box [15:20:31 CEST] <JEEB> because the format is still being developed [15:20:38 CEST] <arpu> ok! [15:20:52 CEST] <ZexaronS> When i get enthusiastic i may talk optimistic, a bit inaccurate, ISO people are EU boreucrat mathematicians/physicsists ... MPEG not so much from what I'm reading... canada is the founding place heh [15:20:53 CEST] <JEEB> just use ffmpeg + libaom's cli encoder to create test clips if you really want to [15:21:25 CEST] <JEEB> ZexaronS: anyways you're way out there enough that you're just creating fucking noise. [15:21:47 CEST] <JEEB> you have no idea about things yet you think you can call things names and then you have this vague shit that you think you know should go somehow [15:22:08 CEST] <JEEB> while it's pretty obvious taht there's layers for all of that shit that you might or might not need in your post-apocalypse archival piece of shit [15:22:13 CEST] <ZexaronS> that's because I'm thinking about solutions to the problems that don't exist yet [15:23:01 CEST] <JEEB> for example, there are reasons to ridicule MPEG-4 Part 2 (which you incorrectly called MPEG-4 ASP - ASP is a goddamn profile of Part 2), but all of your comments just show how little you know of these subjects [15:23:22 CEST] <ZexaronS> vague, because I'm not really seriously putting down a draft, im merely chatting about some of the stuff going on in my head, If I had more resources and meet interesting people up for such a project, it'd be more serious and I'd have drafts drawn already and I'd shown you those instead [15:23:57 CEST] <JEEB> ZexaronS: you are fucking spamming this channel with even more shit at this point, which is what I'm trying to say. Maybe I should just be ignoring you instead of telling this to you, but whatever. [15:24:55 CEST] <ZexaronS> well that ASP thing is wikipedia, so my fault, I should have known not to take that as a fact [15:25:41 CEST] <ZexaronS> secondly, you seem like you want to talk, but you get limited because i'm geing out of the box, like innovations are made not being inside the box, so whatever [15:26:16 CEST] <JEEB> no, most of your shit is adding random requirements and then trying to dump things onto incorrect layers (like putting more and more shit into the video coding layer instead of the container layer) [15:27:01 CEST] <JEEB> and no, you are not out there. people have been working with archival for years for fuck's sake [15:27:06 CEST] <ZexaronS> thirdly you took my words too literally, I have merely brushed on the idea, but indeed that's more of my mistake, I aplogize for not putting more effort into my initial statements and being too haste, [15:27:13 CEST] <JEEB> they design their systems against their requirements [15:27:25 CEST] <JEEB> if they have to go through a motherfucking nuclear war then the requirements start there [15:27:36 CEST] <JEEB> then it goes to more and more details and/or implementation detals [15:27:59 CEST] <JEEB> if you need to not only make sure the data is valid but that it is also come from the source you think it comes from then there's signing blah blah [15:28:29 CEST] <JEEB> fucking hell, this is not new and/or groundbreaking. it's just something that you come up while you keep a calm head and think about the problems you need to solve [15:30:59 CEST] <ZexaronS> Yes I was mixing a lot of different things, the per-frame, codec-integrated camera-authentication stuff is more meant for the video taken on a camera when the video/audio is saved, how exactly would that authentication part be done, via hashing, encrypting, I can't say as I didn't dig into it yet, yes this part has no connection to the datacenter thing and the signing you mentioned there, but seem we can have multiple layers of such [15:30:59 CEST] <ZexaronS> security/authentication not just one [15:31:36 CEST] <Schwarzbaer> I'm using ffmpeg with a -vf, and write the output to a file. The filter is applied. I send the stream to an ffserver. The filter is not applied. This is bizarre... [15:31:57 CEST] <JEEB> Schwarzbaer: my condolences on having ffserver in the mess [15:32:30 CEST] <JEEB> but yea, not many here know anything of it and generally people are recommended to not utilize it [15:33:58 CEST] <ZexaronS> What I just mentioned, is more for the stuff like UFO/alien videos ... in order for the person to be trusted, he would have to provide the exact camera he took the video with and along the exact source file of the video, then the analyzers would go compare the camera with other same cameras to make sure hardware isn't hacked first, then they would go check the video file to see if it really came from that camera and look for various [15:33:58 CEST] <ZexaronS> clues and annomalies that video editing software would leave behind and ofcourse annomalies that would be seen in the visuals that it was actually computer generated graphics [15:34:28 CEST] <ZexaronS> Now that I properly explained it, there's no way this isn't a good idea [15:36:15 CEST] <JEEB> that would literally mean that each video would have to be identifiable to its own camera and that you trust hardware that is 100% in the hands of someone you don't trust to not have been tampered in a way that doesn't require physical modification. and in that case, that it wasn't reverse'd. [15:37:23 CEST] <ZexaronS> Because, all of these codes throw a ton of sensor data away, no doubt forensics will have hard time with a lossy thing like that with a lot of false-positives artifacts that the lossy compression makes ... there's a ton of videos on youtube where such artifacts are fooling a ton of people and the blackhat monetization spammers abuse this a lot [15:39:59 CEST] <ZexaronS> JEEB: yes it's actually quite complicated at the end, to do it really good you need so many checks and backups to really make sure, it's definitely not something any company would ever think about doing in consumer market, and companies really don't care about the truth to begin with [15:40:44 CEST] <Schwarzbaer> JEEB, then how *do* people stream their videos? Also, I'd suspect the problem to be on ffmpeg's side; ffserver shouldn't even know about the filter. [15:40:48 CEST] <ZexaronS> Google is fine with ad money generated from 20 million people being fooled with fake ufo videos each week [15:40:49 CEST] <JEEB> also this is out of scope of this channel, but seriously - you'd be checking trust against something given to you by a non-trusted actor? all the darn metadata in the world can be faked and the software on the camera reverted back to a normal state afterwards. also privacy advocates would just kill you for marking each video against its camera. because those need to be unique [15:41:10 CEST] <JEEB> Schwarzbaer: there are various solutions for various means of "streaming" [15:41:25 CEST] <JEEB> Schwarzbaer: define your use case of "streaming" and someone might be able to help [15:42:14 CEST] <ZexaronS> I guess you're right, I'm glossing over it, it's not something we do regularly, it's a good insight, policing things to keep on one topic strictly really doesn't help innovation either, there's a lot of value in sometimes looking and conneting several topics together to get a better undersanding [15:43:32 CEST] <JEEB> yes, but you are clearly out there and lacking any understanding on the actual topics of this channel. see your mocking of MPEG-4 Part2 which had ZERO of this: https://guru.multimedia.cx/15-reasons-why-mpeg4-sucks/ (this blog incorrectly calls it "mpeg4" instead of "mpeg-4 video" or "mpeg-4 part 2", but at that point other video formats in mpeg-4 did not yet have wide usage) [15:44:46 CEST] <ZexaronS> JEEB: emm, sorry, with the term "metadata" i just meant like 10 things, I can't think of right now, how to explain them, various features, secondly, I wasn't that direct on the video uniqueness ... I may have said it wrong, I meant more that it would prove the video came from that camera model and it wasn't altered, not the exact camera serial number [15:45:36 CEST] <ZexaronS> Those are details that can be changed/finetuned to ofcourse alleviate those issues you mentioned [15:46:16 CEST] <Schwarzbaer> It's less a matter of having a use case than of wanting to be able to use the toolset. Simplest case would be "make this webcam available to be watched over the internet", but in general I want to be able to point people and tools at an HTTP endpoint, and mix the video that they'll see. [15:46:44 CEST] <JEEB> Schwarzbaer: for web-based streaming people usually use something like nginx-rtmp [15:46:59 CEST] <JEEB> you feed it rtmp, and it outputs HLS/DASH for browsers and RTMP for flash [15:47:24 CEST] <JEEB> the former supported by mobile clients as well, as well many other stuff at this point :P [15:47:36 CEST] <ZexaronS> You are correct that I don't understand fully how stuff works currently, but if I'm building something to replace it, the question would be, why would we even have to fully understand it, we already see from basics/fundamentals it's underpar, not really hard to see it, it's like seeing it from space, or seeing it from the earth, don't even need to send a probe to see it in detail imo [15:48:27 CEST] <ZexaronS> Like the Sun is H264 ... it's yellow and red ... in details, more yellow and red shades [15:49:00 CEST] <JEEB> Schwarzbaer: ffserver is a thing that is in the FFmpeg code repository and some people are fighting hard to keep it in there. but it's a problem filled thing that nobody can recommend nor help with [15:49:17 CEST] <JEEB> so as soon as you mention ffserver people will generally take a step backwards [15:49:33 CEST] <JEEB> "if it works for you, great. but don't come around here with any issues because nobody here uses/works with it" [15:50:28 CEST] <Schwarzbaer> That's bizarre. How *do* people mangle their streams then, putting picture-in-picture, greenscreen, and all the stuff that ffmpeg offers? [15:51:36 CEST] <ZexaronS> good talk tho, no need to annoyed, I usually speak to the world, don't intend to rant towards anyone in particular [15:52:07 CEST] <Schwarzbaer> For example, I was thinking of another setup with an output stream consisting of four tiles, each showing a feed, with the feeds going online or offline independent of each other. I wouldn't even know how to do something like that without ffserver. [15:52:58 CEST] <JEEB> people either use ffmpeg.c or their own applications on top of the FFmpeg APIs and feed to a media server [15:53:05 CEST] <JEEB> also did ffserver even do that? [15:53:17 CEST] <JEEB> I'd think every time you'd lose a source things would go woo-woo [15:53:47 CEST] <JEEB> because the overlay filter would still be waiting for the image on the missing source [15:54:11 CEST] <JEEB> and the overlying application would have to know when it has or doesn't have an input, and it would have to know how to re-connect to that input [15:54:24 CEST] <JEEB> it's certainly possible but I'd be surprised if any of ff* tools support that [15:54:46 CEST] <Schwarzbaer> I see... And here I was hoping that it'd simply go black, or rather go defined-default-image... [15:55:14 CEST] <JEEB> that generally is something that the user of that filter defines [15:55:24 CEST] <JEEB> the filter itself is just taking in N inputs and overlaying [15:55:34 CEST] <JEEB> I mean, that way you are handling the complexity where it should be [15:55:47 CEST] <JEEB> Schwarzbaer: also I have never used ffserver just like many others here. [15:55:54 CEST] <JEEB> so if it handles that, cool [15:56:14 CEST] <JEEB> still doesn't make it any less of a black box in the sense of wtf it's doing there [16:04:28 CEST] <Schwarzbaer> Okay, I've looked a little into nginx-rtmp now (meaning that I'm still skimming the intro page). Apparently it acts as a replacement for ffserver, meaning that I point ffmpegs at it to feed media streams, and (hopefully) ffplays to watch those streams. So in my "feeds going on and off" scenario, could I have a handful of locations that do or do not get feeds at any given time, and one continuously running ffmpeg [16:04:29 CEST] <Schwarzbaer> instance that reads from those locations, mixes the output image, using default images if a given location is currently not being fed, and then feeds the output back into nginx-rtmp? [16:05:15 CEST] <Schwarzbaer> Also, where can I read up on what RTMP, HLS, and DASH actually *are*? [16:05:36 CEST] <JEEB> yes, or your own app if ffmpeg.c doesn't do the fallbacks and re-synchronization or whatever like you need [16:06:05 CEST] <JEEB> basically you separate the actual transcoding and the serving of content [16:06:11 CEST] <JEEB> which is a common separation line [16:06:47 CEST] <JEEB> Schwarzbaer: if you want technicalities then for RTMP I guess https://wiki.multimedia.cx/index.php/RTMP is good [16:06:58 CEST] <Schwarzbaer> Thanks. [16:07:12 CEST] <JEEB> HLS and DASH are just ways of streaming video through HTTP with small chunks and a constantly updating playlist/manifest [16:07:24 CEST] <JEEB> so the player keeps querying that file for new segments etc [16:07:43 CEST] <Schwarzbaer> Also, there doesn't seem to be a Debian package for nginx-rtmp, which is unfortunate and bizarre. [16:08:27 CEST] <JEEB> also I would generally keep the hell away from ffplay if not for testing purposes [16:08:43 CEST] <JEEB> it's a proof-of-concept player done on top of the FFmpeg libraries and SDL(2) [16:08:48 CEST] <BtbN> nginx-rtmp is a nginx module [16:08:57 CEST] <BtbN> and nginx does not support truly dynamic modules [16:08:58 CEST] <JEEB> if you want a player that bases on top of FFmpeg then I recommend mpv [16:09:02 CEST] <BtbN> so you have to compile it in yourself [16:09:25 CEST] <Schwarzbaer> Well, on a day-to-day basis I'm usually using mplayer. [16:09:33 CEST] <JEEB> mpv is the least retarded fork of mplayer [16:09:38 CEST] <BtbN> mplayer is old, half-dead and horrible [16:10:28 CEST] <Schwarzbaer> I'll give mpv a try then. [16:12:09 CEST] <JEEB> but for testing in browsers I recommend hls.js and dash.js since most players utilize one of those for their playback [16:12:22 CEST] <JEEB> and for android you have the exoplayer example app [16:12:31 CEST] <JEEB> and for iOS you can just embed the HLS url in a video tag [16:16:52 CEST] <Schwarzbaer> TBH right now I don't care about phones, since I still don't have a smartphone. And web players are, right now, also a flight of fancy at best. [16:17:30 CEST] <Schwarzbaer> Actually, to go on a bit of a tangent, do js players play nice with Tor? [16:17:49 CEST] <Schwarzbaer> (bbiab) [16:17:54 CEST] <JEEB> if the HTTP requests go through OK I don't see Tor as anything else than a proxy :P [16:18:18 CEST] <JEEB> that said the tor network's management might not like you doing high bandwidth stuff over it [16:19:14 CEST] <BtbN> That's the whole point of piping absolutely everything through http [16:19:25 CEST] <BtbN> tor will usually be way too slow for any kind of streaming [16:20:10 CEST] <JEEB> no, the point of HTTP and segments was to utilize the existing content delivery infra :D [16:20:21 CEST] <JEEB> that's why things moved away from actual streaming protocols [16:26:39 CEST] <wondiws> hello [16:37:50 CEST] <Schwarzbaer> Well, I didn't *plan* to stream high bandwidth media, and I think that as my current upload is limited to 60kb/s, Tor management probably wouldn't even notice. It's more a matter of "If I should ever want to, could I?", to which the answer is apparently "Yes." And since I've got ffmpeg in the pipeline, I should be able to downsample the media streams arbitrarily anyway. Anybody wanna watch my 4x3 pixels webcam [16:37:50 CEST] <Schwarzbaer> stream? :D [16:39:17 CEST] <BtbN> 60kb/s is barely enough for music [16:42:06 CEST] <JEEB> depends on your quality expecations etc [16:42:29 CEST] <JEEB> x264 can compress your shit down, as noted by me setting 6 kbps as my maxrate and wondering where my image goes after the 16 megabit buffer gets filled [16:47:29 CEST] <Schwarzbaer> As long as I can stream around strings within my LAN, I'll be happy for the moment. ^^ [17:29:42 CEST] <Schwarzbaer> Well then... Seems like I've just build nginx with rtmp. Time to look into configuring it. After getting some food... [18:34:03 CEST] <arpu> any on an idea why i get Invalid data found when processing input on ffmpeg -i $(youtube-dl -J "https://www.youtube.com/watch?v=XmL19DOP_Ls" | jq -r ".requested_formats[0].manifest_url") [18:34:24 CEST] <arpu> this should work since this commit message http://git.videolan.org/?p=ffmpeg.git;a=commit;h=96d70694aea64616c68db8be30… [18:34:54 CEST] <BtbN> Because it's far from perfect. [18:39:03 CEST] <arpu> but why its in the commit message ? stevenliu [18:39:43 CEST] <JEEB> because some URL at some point worked [18:39:45 CEST] <JEEB> probably? [18:40:18 CEST] <BtbN> I still think that changelog should not have been pushed in the commit message [18:41:19 CEST] <JEEB> I tested a certain stream I had around that contained +5 seconds of audio compared to video, and I couldn't even get ffmpeg.c rolling :) [18:41:30 CEST] <JEEB> since ffmpeg.c said I was buffering too many packets or something [18:41:53 CEST] <JEEB> (the end point was the same, but there was for some reason +5 seconds of audio from before the video segments started) [18:42:26 CEST] <JEEB> tested with two other DASH clients and it worked a-OK with those [18:42:56 CEST] <JEEB> but since i've gotten such a message generally it feels like it's not DASH-specific and the demuxer was just pushing out all samples from the manifest :) [18:43:12 CEST] <BtbN> DASH is stupidly complex [23:54:29 CEST] <Schwarzbaer> Woohoo, I got nginx-rtmp to work, and indeed now my video filters get applied correctly. Now I just have to learn about how to configure access controls... [23:54:58 CEST] <Schwarzbaer> And maybe about using an embedded player after all, just for the kick of it. [23:56:35 CEST] <MelchiorGaspar> got a quick question,.... what FFmpeg cmd will display the source files code res info? [23:58:18 CEST] <JEEB> use ffprobe for getting info on a file [23:58:32 CEST] <JEEB> if you are going to be using it by an app that reads its output, use -of json [23:58:35 CEST] <JEEB> which outputs JSON [23:58:40 CEST] <JEEB> then you can do stuff like -show_streams [23:58:45 CEST] <JEEB> or -show_frames [23:59:00 CEST] <JEEB> which gives a brickload of stuff for you to parse [23:59:19 CEST] <JEEB> -show_streams shows the basic info on the streams in the file [00:00:00 CEST] --- Sun Sep 17 2017

1 0

ffmpeg-devel.log.20170915
by burek 16 Sep '17

16 Sep '17

[00:10:07 CEST] <cone-754> ffmpeg 03Jun Zhao 07master:462568185b0a: kmsgrab: Fix build failure with old libdrm [00:10:07 CEST] <cone-754> ffmpeg 03Jun Zhao 07master:197d298ab3b2: hwcontext_vaapi: Fix build failure with old libdrm [02:47:33 CEST] <cone-754> ffmpeg 03Kaustubh Raste 07master:f692e55aab79: avcodec/mips: Improve hevc lpf msa functions [02:47:34 CEST] <cone-754> ffmpeg 03Kaustubh Raste 07master:c6314cd750df: avcodec/mips: Improve hevc idct msa functions [02:47:35 CEST] <cone-754> ffmpeg 03Thierry Foucu 07master:eea64ef4cfb5: vf_fps: when reading EOF, using current_pts to duplicate the last frame if needed. [05:19:39 CEST] <kode54> nice [05:19:55 CEST] <kode54> I made a 3 line patch to FFmpeg CAF handler to add support for Opus [05:20:12 CEST] <kode54> verified working on High Sierra dev beta 9, will test GM seed once I have updated my primary install to that [05:20:43 CEST] <kode54> unfortunately, Apple's own encoder appears to be limited to producing mono streams [05:20:47 CEST] <kode54> using afconvert to encode [05:21:06 CEST] <kode54> whereas QuickTime does manage to play back stereo streams that I've remuxed using the patched FFmpeg [05:26:45 CEST] <jamrial> kode54: odd, someone else was able to make stereo opus caf files using afconvert i remember [05:26:52 CEST] <kode54> strange [05:26:57 CEST] <kode54> I don't know what settings to use for that, then [05:27:07 CEST] <kode54> maybe I need to mess with the channel layout parameter [05:27:24 CEST] <kode54> I do know that the OS and QuickTime accept my FFmpeg muxed file [05:27:58 CEST] <jamrial> what did you put in the kuki chunk? [05:28:20 CEST] <kode54> 'o','p','u','s' [05:29:10 CEST] <kode54> afconvert lists the codec ids it supports, and requires them as the parameter for encoding [05:29:25 CEST] <jamrial> i'm not talking about the codec tag. the kuki chunk, where most other codecs put extradata [05:29:27 CEST] <kode54> they also support reading flac [05:29:30 CEST] <kode54> oh [05:29:37 CEST] <kode54> I didn't touch that [05:29:46 CEST] <kode54> presumably it got the same extradata as the ogg stream [05:29:59 CEST] <jamrial> it's not, i already checked that [05:30:02 CEST] <kode54> oh [05:30:03 CEST] <kode54> weird [05:30:11 CEST] <kode54> I'll check what's in the file I converted with afconvert [05:30:23 CEST] <jamrial> any opus file you're creating is not really compliant, then [05:30:26 CEST] <jamrial> even if quicktime reads it [05:30:43 CEST] <jamrial> it contains a bunch of values related to the stream. i was able to figure a few but not all [05:31:09 CEST] <kode54> the file I encoded has [05:31:11 CEST] <kode54> 00 00 08 00 00 00 BB 80 00 00 03 C0 FF FF FC 18 00 00 00 01 00 00 00 00 00 00 00 00 [05:31:53 CEST] <jamrial> things like sample rate, channel count (not layout), frames per packet, etc, are in there [05:31:57 CEST] <kode54> not sure what the 2048 is there for, bb80 is the sample rate, 3c0 is the samples per frame, 01 is the channels [05:32:01 CEST] <jamrial> but other values i have no idea what the represent [05:32:42 CEST] <kode54> weird, QuickTime accepted the other file without a kuki chunk [05:32:57 CEST] <jamrial> fffffc18 is -1000 [05:33:16 CEST] <kode54> maybe that's the start of stream delay [05:33:53 CEST] <jamrial> it never seems to change. other files i've seen encoded with afconvert also set that exact value [05:33:59 CEST] <kode54> huh [05:34:47 CEST] <jamrial> until apple releases some spec, i'm going to assume it's unfinished and ignored by even their own software, as you were able to confirm with quicktime [05:35:30 CEST] <jamrial> in any case, I'd not allow the muxer to create such files. better not spread potentially non compliant files if possible [05:57:00 CEST] <TD-Linux> kode54, documentation of what you've found so far would still be really useful. I've wanted to make a JS side CAF remuxer for browser support. [05:57:14 CEST] <kode54> nice [05:57:35 CEST] <kode54> they also support FLAC files in QuickTime [05:57:57 CEST] <kode54> I haven't tried converting to FLAC with afconvert, though [05:58:15 CEST] <kode54> naturally, iTunes doesn't support either of these formats [06:01:30 CEST] <TD-Linux> I wonder if you can shove CAF into MSE [06:17:50 CEST] <jamrial> TD-Linux: https://lists.libav.org/pipermail/libav-devel/2017-July/084460.html [06:19:21 CEST] <TD-Linux> no pre-skip is pretty obnoxious (unless that's one of the unknown values) [06:19:59 CEST] <TD-Linux> does pre-skip work? e.g. if you use afconvert to make a caf opus and back to wav, does it get longer? [06:55:07 CEST] <kode54> TD-Linux: pre-skip works for the afconvert-encoded CAF, if it's decoded by afconvert again [06:55:23 CEST] <TD-Linux> and end trimming? [06:55:43 CEST] <TD-Linux> er I guess that's part of the CAF spec itself [06:56:08 CEST] <kode54> the lengths are identical [06:57:07 CEST] <kode54> the CAF, according to FFmpeg, appears to be one packet longer than the source audio [13:37:41 CEST] <cone-598> ffmpeg 03Jacek Jendrzej 07master:e2f8f14052d9: lavf/http: Reset compressed header flag, fix http 302 request [14:17:28 CEST] <JEEB> > HEIF [14:21:30 CEST] <cone-598> ffmpeg 03Matthieu Bouron 07master:dd8ffb191fd2: lavc/mediacodec_wrapper: fix jni vaargs types [14:22:26 CEST] <mateo`> JEEB: ^ that might fix the issues you reported a while ago about ndk >= 15 and the ffmpeg wrapper [14:22:41 CEST] <JEEB> oh [14:22:46 CEST] <JEEB> I did wonder for a moment [14:22:48 CEST] <JEEB> will test [14:23:05 CEST] <JEEB> the 64bit file pointer stuff will make me fix stuff in mpv anyways to test it, though :) [14:23:16 CEST] <JEEB> since one of the components in mpv utilizes the define [14:23:23 CEST] <JEEB> which used to work (with silent 32bit pointers) [14:25:12 CEST] <mateo`> I have an issue related to that at work, they fixed the 64bit file pointer and they broke their (unified) headers [14:26:19 CEST] <JEEB> yea, basically if you do stuff against an old enough API version you don't have the normal file pointer stuff IFF you define the 64bit define [14:26:33 CEST] <JEEB> too bad a lot of code/build systems expect to be able to use the "make things 64bit" define [14:27:56 CEST] <mateo`> python defines __USE_FILE_OFFSET=64, and some C++ modules includes cstdio ... [14:28:13 CEST] <JEEB> yup :) [14:29:19 CEST] <mateo`> rcombs: are you still working on heif support ? [14:29:59 CEST] <mateo`> I stopped working on it when you dropped your patch on the ml [14:49:56 CEST] <rcombs> mateo`: planning to; haven't done much since, though [14:50:04 CEST] <rcombs> mateo`: was hoping you'd post some comments [15:04:05 CEST] <cone-598> ffmpeg 03Clément BSsch 07master:1a08285f05c9: build: fix coreimage filters dependency to AppKit framework [15:09:09 CEST] <cone-598> ffmpeg 03Clément BSsch 07master:674335155800: lavf/http: fix compilation without zlib [15:09:56 CEST] <jkqxz> Ha, I was just about to send a patch for that. [15:10:03 CEST] <jkqxz> ubitux: Thank you! [15:10:25 CEST] <ubitux> np :p [15:10:31 CEST] <JEEB> :) [15:10:34 CEST] <ubitux> dammit asan is stalled again [15:10:46 CEST] <ubitux> in fate-filter-fps this time [15:10:57 CEST] <ubitux> wth does it freeze instead of failing [15:18:01 CEST] <BtbN> sounds like a bug in asan itself? [15:18:09 CEST] <BtbN> like, something running it into an infinite loop [15:18:34 CEST] <ubitux> yeah, dunno [15:18:40 CEST] <ubitux> i disabled the instance, it's pointless anyway [15:18:49 CEST] <ubitux> valgrind spot these errors [15:26:05 CEST] <nevcairiel> asan is good at finding errors, it just sucks at reporting them? :p [15:30:10 CEST] <ubitux> i'm betting on our fate script being stalled in a pipe [15:30:18 CEST] <ubitux> but i don't know.. [16:25:55 CEST] <BBB> does asan always stall on that test? or is it flaky? [16:26:12 CEST] <BBB> if it is consistently reproducible, that may be interesting to pursue further [16:55:59 CEST] <ubitux> BBB: yes, consistently reproducible [16:56:04 CEST] <ubitux> ==17774==ERROR: AddressSanitizer: SEGV on unknown address 0x7f0b73d85008 (pc 0x7f0b7a95fdea bp 0x7ffffa338500 sp 0x7ffffa338068 T0) [16:56:07 CEST] <ubitux> ==17774==The signal is caused by a READ memory access. [16:56:09 CEST] <ubitux> and then it reads stdin [17:07:59 CEST] <jamrial> it's the same crash as with the previous leak [17:08:17 CEST] <jamrial> both were lavfi leaks, but it's probably an asan bug [17:14:28 CEST] <BBB> dont forget that asan is useful for tracking stack overflows, I dont know if valgrind supports these nowadays (it didnt find them in the past) [17:28:15 CEST] <lotharkript> ubitux: do you still have a problem with valgrind? [17:35:31 CEST] <BBB> lotharkript: http://fate.ffmpeg.org/report.cgi?time=20170915043055&slot=x86_64-archlinux… [17:36:14 CEST] <BBB> ==2374== 140,630 (528 direct, 140,102 indirect) bytes in 1 blocks are definitely lost in loss record 8 of 8 [17:36:30 CEST] <lotharkript> BBB: I just tried valgrind and it works here.. I did not run the fate test, but the ffmpeg command line and it is fine. [17:37:46 CEST] <BBB> ==134036== definitely lost: 528 bytes in 1 blocks [17:37:46 CEST] <BBB> ==134036== indirectly lost: 140,102 bytes in 7 blocks [17:37:53 CEST] <BBB> thats not fine at all ;) [17:38:18 CEST] <BBB> it also says: ==134036== Rerun with --leak-check=full to see details of leaked memory [17:38:28 CEST] <BBB> --track-origins=yes may be helpful also [17:39:15 CEST] <JEEB> `--leak-check=full --track-origins=yes` is how I usually run stuff under valgrind [17:46:23 CEST] <lotharkript> ok.. Find the leak.. Will be sending something [17:50:31 CEST] <lotharkript> BBB: just sent a patch for it. [17:50:42 CEST] <BBB> cool! [17:50:53 CEST] <lotharkript> Sorry about that. [17:50:59 CEST] <BBB> it happens [00:00:00 CEST] --- Sat Sep 16 2017

1 0

ffmpeg.log.20170915
by burek 16 Sep '17

16 Sep '17

[01:01:39 CEST] <braininabat> hello, i've been having problems to use the tee funcionality. I have a working stream with ffmpeg, and now I want to also have it store into a file, I am trying to use the same command I use for the stream and adding the tee part based on the tee examples found on the documentation, apparently it starts normally, but Im not getting the stream, the file I do though... any thoughts? [01:02:43 CEST] <klaxa> paste your command line [01:08:42 CEST] <braininabat> this is my working stream command: https://pastebin.com/k5ehk84i this is the tee command not working: https://pastebin.com/P9vWyhwC [01:09:10 CEST] <braininabat> the stream is only video [01:09:18 CEST] <braininabat> the file video + audio [01:10:28 CEST] <braininabat> I am starting to think now it could be ffsever config matter? [01:11:16 CEST] <klaxa> hmm... ffserver is not really supported anymore [01:12:40 CEST] <braininabat> hmm... I may be using it still for the stream I guess... what it's been used now in its place? [01:18:33 CEST] <klaxa> nginx-rtmp, hls or mpeg-dash [01:18:48 CEST] <klaxa> btw, i can't really find anything wrong with your command :/ [01:22:30 CEST] <braininabat> klaxa, ok thank you, I've been going around it for some time I can't see anything wrong either, I will look into the streaming alternatives you mentioned... thanks!!! gn [03:01:40 CEST] <grkblood13> whenever I run the following script with a link to a valid mpegts stream as the input I get the error "Output #0, mpegts, to ' ': [03:01:40 CEST] <grkblood13> Output file #0 does not contain any stream [03:01:40 CEST] <grkblood13> ". What am I doing wrong? [03:01:48 CEST] <grkblood13> https://pastebin.com/6CCDzZsN [03:07:34 CEST] <DHE> can you run: bash -x $THIS_SCRIPT $INPUT and pastebin the whole inupt and output? (feel free to censor any private data with XXXX or the like, but don't remove anything) [03:08:54 CEST] <grkblood13> ok, 1 minute [03:09:08 CEST] <DHE> alternatively add "set -x" to the top of your script. what it does is make bash print each line just before executing it. great for debugging [03:14:26 CEST] <grkblood13> i might have a new problem. Ill need abour 5-10 minutes. i dont expect you to wait around for me. [03:17:41 CEST] <grkblood13> is ffmpeg -f mpegts -s 1920x1080 -i $1 not a valid video size? [03:18:06 CEST] <grkblood13> its spitting out Option video_size not found. now [03:22:20 CEST] <DHE> usually mpegts carries an mpeg style video which doesn't need to be told the resolution. the decoder will figure it out for itself [06:12:39 CEST] <blap> hola. not finding the cause of this problem [06:12:53 CEST] <blap> mpv -af=lavfi='[dynaudnorm=g=5:f=250:r=0.9:p=0.5]' test.mp4 [06:13:03 CEST] <blap> [ffmpeg] src: Media type mismatch between the 'src' filter output pad 0 (video) and the 'Parsed_dynaudnorm_0' filter input pad 0 (audio) [06:13:36 CEST] <blap> Version: 7:3.3.4-1 [06:55:34 CEST] <blap> found the problem, sorry to bother you [07:16:29 CEST] <DeadDred> Is it possible to make a video from 1000+ mp3's in a directory and write the name, extracted from the .mp3 title/ID3 data in the video for the duration on each track/mp3? [07:21:07 CEST] <furq> not in one command [07:21:23 CEST] <furq> the easiest way to do that would probably be to use mutagen and write a subtitle file to burn in [07:21:45 CEST] <furq> or you could probably do it with ffprobe and sh if you don't want to use python, which is understandable [07:25:53 CEST] <DeadDred> Ok seems I might be able to skip the complexity and add subtitles as the Track Names to the video in YouTube although might not look as good [07:26:23 CEST] <DeadDred> I guess just create a subtitle/CC file with times stamps and upload [07:27:23 CEST] <furq> well if you're encoding the video anyway you might as well burn it in with ffmpeg [07:27:31 CEST] <furq> once you have the subtitle file it's just -vf subtitles=foo.ass [07:27:43 CEST] <furq> and you could do nice transitions and whatnot with that [07:28:48 CEST] <DeadDred> hmm ok so once the video is compiled I can add the subtitles inside a file to be shown on screen? [07:29:21 CEST] <furq> no [07:29:28 CEST] <furq> -vf subtitles burns the subtitles in when you're encoding the video [07:29:33 CEST] <DeadDred> ok [07:29:56 CEST] <furq> or you can create a vtt file or whatever youtube wants and upload that separately [07:30:49 CEST] <DeadDred> can the on screen position of the subtitle be set too? Say if I add a background for the video and crate a space in the image and the show the subtitle there? [07:31:02 CEST] <furq> sure [07:31:05 CEST] <DeadDred> ok [07:31:06 CEST] <furq> !filter subtitles @DeadDred [07:31:06 CEST] <nfobot> DeadDred: http://ffmpeg.org/ffmpeg-filters.html#subtitles-1 [07:31:28 CEST] <furq> or you can set styles, positioning etc if you use .ass subtitles [07:31:48 CEST] <DeadDred> ok ty [07:31:54 CEST] <furq> if you just want one global style and positioning for everything then srt is probably easier [07:33:03 CEST] <DeadDred> Yah wa thinking of a background and then in the image create a rounded rectangle where I would like to show the track name. Although with 1500 tracks using a background would proably add quite a bit to the file size [07:33:24 CEST] <furq> static images compress very well [07:33:44 CEST] <furq> and youtube encodes everything at a roughly fixed bitrate anyway [07:37:04 CEST] <DeadDred> Crap just read YT has a 11 hour video limit looks like it'll have to be 6+ individual 11 hour video files then [07:47:27 CEST] <ffmpeg911> Hello, i am not experienced in working with ffmpeg api. How can i implement crop of file. It works with this line "ffmpeg -ss 00:00:09 -i vidseek108.mkv -t 00:00:03 -vcodec copy -acodec copy -y final.mkv" [07:49:02 CEST] <dystopia_> what do you want to crop [07:49:54 CEST] <ffmpeg911> Specific range from the file that still gets written [07:50:37 CEST] <dystopia_> -vf crop=in_width:in_height:crop_left:crop_top [07:50:47 CEST] <dystopia_> i meant how many pixels did you want to crop heh [07:51:17 CEST] <ffmpeg911> Ohh, i saw that i throw different exaample [07:51:21 CEST] <dystopia_> for example if the video was 1920x1080 and you wanted to crop 4 pixels from the left and 4 pixels from the right you would do [07:51:22 CEST] <ffmpeg911> I use this sample [07:51:22 CEST] <ffmpeg911> ffmpeg -i vidseek108.mkv -ss 00:00:50.0 -codec copy -t 20 output.mkv [07:51:44 CEST] <ffmpeg911> it cut out 20s starting from the second 50 in file [07:51:47 CEST] <dystopia_> -vf crop=1912:1080:4:9=0 [07:52:01 CEST] <dystopia_> you want to cut, not crop? [07:52:27 CEST] <dystopia_> crop == removing black borders from video [07:52:27 CEST] <ffmpeg911> crop is for pixels ? [07:52:49 CEST] <ffmpeg911> I need range of frames from the video file [07:53:36 CEST] <dystopia_> a cut won't be exact [07:53:47 CEST] <dystopia_> as it will use the nearest i-frames as cut points [07:53:55 CEST] <dystopia_> instead of your exact time code [07:54:07 CEST] <ffmpeg911> I need this one implemented by api methods ffmpeg -i vidseek108.mkv -ss 00:00:50.0 -codec copy -t 20 output.mkv [07:58:31 CEST] <ffmpeg911> Is it at least hard or easy task ? :) [09:03:04 CEST] <Fyr> guys, ffmpeg -hwaccels shows only cuvid on Intel 4000 HD on Linux. [09:03:16 CEST] <Fyr> how do I enable hardware decoding here? [09:23:57 CEST] <JEEB> Fyr: vaapi library (and development package of course), and the intel vaapi driver [09:24:09 CEST] <JEEB> then you can build FFmpeg with VA-API [09:24:26 CEST] <Fyr> JEEB, installed only vaapi-dummy-driver [09:24:27 CEST] <Fyr> =) [09:24:52 CEST] <JEEB> or well, FFmpeg itself only needs vaapi itself. then the VA-API library will try to load some driver [09:25:00 CEST] <JEEB> and fail like in my case when I didn't have intel's driver installed :) [09:25:51 CEST] <JEEB> tl;dr --enable-vaapi [09:25:59 CEST] <JEEB> is the thing on FFmpeg's side [09:27:33 CEST] <Fyr> JEEB, does libx264 need it? [09:27:40 CEST] <JEEB> no [09:29:02 CEST] <JEEB> I mean, libx264 is fully software. there's an OpenCL PoC but that's a Proof of Concept that I don't consider worth anyone's time due to it being just one of the lookaheads [09:29:54 CEST] <JEEB> libx264 is just --enable-gpl (because x264 is GPL unless you corp license it) and --enable-libx264 [10:56:51 CEST] <next> Hi all [10:57:03 CEST] <next> Stream map '0:2' matches no streams. To ignore this, add a trailing '?' to the map. [10:57:38 CEST] <next> Show what you need to enter, I do not understand. [10:57:49 CEST] <next> Pleas. [10:58:23 CEST] <dystopia_> i think it means map 0:? [10:58:28 CEST] <dystopia_> but im not certain [10:58:42 CEST] <dystopia_> if track doesn't exist, no need to use map on it [11:01:24 CEST] <next> ffmpeg -i X.VOB -i 1.ac3 -i 2.ac3 -map 0:0 -map 0:1 -map 0:3 -c:a copy -c:v copy 0.VOB [11:02:17 CEST] <next> Stream map '0:2' matches no streams. To ignore this, add a trailing '?' to the map. [11:04:49 CEST] <next> ffmpeg -i X.VOB -i 1.ac3 -i 2.ac3 -map 0:0 -map 0:1 -map 0:? -c:a copy -c:v copy 0.VOB [11:05:00 CEST] <next> Invalid media type data for output stream #0 [11:05:00 CEST] <next> Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument [11:11:17 CEST] <next> I need to combine two audio with one video. [11:25:30 CEST] <e-40> can anyone can help me with ffmpeg installation in redhat [11:25:48 CEST] <moshisushi> Hello! I'm trying to encode and package an audio file with a static image as HLS. My current command line is this: ffmpeg -i myaudio.wav -i myimage.jpg -profile:v baseline -level 3.0 -pix_fmt yuv420p -start_number 0 -hls_time 5 -hls_list_size 0 -f hls master.m3u8 [11:26:25 CEST] <moshisushi> without myimage.jpg it works fine (but with no video obviously), but if I add the image i only get one single master0.ts segment [11:26:48 CEST] <Mavrik> moshisushi, try adding -r 30 ? [11:26:58 CEST] <Mavrik> to make sure you get a 30fps video of the image? [11:26:59 CEST] <moshisushi> Mavrik: ta I'll give it a shot [11:27:03 CEST] <e-40> redhat support? [11:27:03 CEST] <moshisushi> oooh I see [11:27:38 CEST] <moshisushi> Mavrik: legend! it workded :) [11:27:50 CEST] <moshisushi> seeing lots of segments being written now [11:30:50 CEST] <e-40> redhat support? [11:30:59 CEST] <e-40> how to install in red hat [11:42:24 CEST] <next> -map 0:v -map 1:a -map 2:a [11:42:31 CEST] <next> ha ha ha [11:42:38 CEST] <next> sorry [11:43:35 CEST] <moshisushi> Mavrik: actually spoke to soon [11:44:01 CEST] <moshisushi> still only one segment with -r 30 added [11:44:11 CEST] <Mavrik> Ah, no idea then :/ [11:46:06 CEST] <moshisushi> Mavrik: actually I wonder if it matters where -r is used (the actual argument position) [11:46:18 CEST] <Mavrik> the ordering tends to be important yeah [11:46:25 CEST] <Mavrik> Put it next to video parameters :) [11:46:39 CEST] <Mavrik> Btw, can you also pastebin the output ffmpeg gives you when it starts encoding? [11:47:05 CEST] <moshisushi> Mavrik: yeah sure [11:47:44 CEST] <moshisushi> Mavrik: https://pastebin.com/QJ33X6Xs [11:49:24 CEST] <Mavrik> I don't see anything obviously wrong :/ [11:53:10 CEST] <moshisushi> Mavrik: I'll try encoding the image to a video first then and package it with the loop option or something [11:53:20 CEST] <moshisushi> I'm sure there's at least an ugly solution lurking somewhere :) [11:53:59 CEST] <moshisushi> Mavrik: not the first time i've had to preprocess for HLS... my ffmpeg build is quite unhappy about flac in HLS as well.. works fine if decoding to wav first though [12:30:01 CEST] <next> How do I use the -ilme option? [12:32:20 CEST] <next> Unrecognized option 'ilme'. [12:34:11 CEST] <next> -target ntsc-dvd,ilme [12:34:25 CEST] <next> Ok. sorry [12:54:57 CEST] <next> ilme bitrate=28771.2kbits/s :( [12:55:24 CEST] <next> How is this removed? [12:57:37 CEST] <DHE> you mean interlaced mode? [12:58:05 CEST] <next> yeah [12:58:34 CEST] <DHE> it's used as -flags ilme (see also -flags ildct) [12:59:15 CEST] <next> I need to save the interlace but the ilme mode gives too much bitrate. How to subtract a high bitrate? [12:59:49 CEST] <next> Ok. [13:00:18 CEST] <DHE> if the source is interlaced, you need to encode it in interlaced mode [13:00:27 CEST] <DHE> from the history it looks like you're encoding to a DVD? [13:00:47 CEST] <next> yes [13:07:46 CEST] <next> -target ntsc-dvd,ildct bitrate=28771.2kbits/ [13:08:23 CEST] <next> i need 8000k [13:10:26 CEST] <next> ildct and ilme one and the same [13:21:13 CEST] <Yos> Hi everybody, pls forgive my noob-ility, i was wandering if the new snapshot release as per today had some major modifications on osx linking dependencies... to be more precise, i am totally able to compile a working executable using the stable one with --enable-vda , the snapshot instead gices me this : ERROR: vda requested, but not all dependencies are satisfied: vda_framework pthreads, how comes? [13:21:57 CEST] <Yos> *give [13:22:04 CEST] <next> -target ntsc-dvd -flags ilme OK. Sorry [13:22:29 CEST] <next> Thenks DHE [13:35:20 CEST] <c_14> Yos: isn't vda eol in favor of videotoolbox? [13:37:23 CEST] <Yos> c_14: most likely, but this error has no sense at all anyway, i guess [13:37:30 CEST] <c_14> And yes, there have been recent changes that could have broken the configure code for that (there's also an RFC on the mailing list to remove vda completely) [13:38:23 CEST] <c_14> Can you upload the content of your config.log to a pastebin service? [13:39:24 CEST] <c_14> do you need vda, or could you use videotoolbox? [13:39:35 CEST] <Yos> c_14: i checked that and it was complaining about a directory (actually non existent) in my actal config [13:40:22 CEST] <Yos> c_14: nope not really was a curiosity since the stable had no such an error [13:41:27 CEST] <c_14> Yeah, there's been some recent changes in configure with regards to it that nobody can test because none of the devs have an old enough OSX. If you don't need it, I'd just disable it since it probably doesn't have long left to live anyway [13:43:08 CEST] <Yos> c_14: ok i see, that make sense ofc, thanks for your help / advise [14:15:18 CEST] <moshisushi> Mavrik: i solved it with a rather ugly and slow 2 stage rocket :) [14:15:26 CEST] <moshisushi> ffmpeg -loop 1 -i image.jpg -i audio.wav -c:v libx264 -tune stillimage -c:a aac -b:a 128k -pix_fmt yuv420p -shortest out.mp4 [14:15:29 CEST] <moshisushi> ffmpeg -i out.mp4 -profile:v baseline -level 3.0 -pix_fmt yuv420p -start_number 0 -hls_time 5 -hls_list_size 0 -f hls master.m3u8 [14:15:52 CEST] <moshisushi> might be possible to merge the 2 [15:49:09 CEST] <Ducky^> hi all, I'm trying to send encoded video over the network to a second device [15:49:32 CEST] <Ducky^> I'm only intending to play the video on one device so I'm not using ffserver (yet) [15:49:44 CEST] <BtbN> ffserver is dead, better leave it like that. [15:49:54 CEST] <Ducky^> fair enough [15:50:09 CEST] <Ducky^> I found that a lot of frames are dropped/the video is glitchy when I use udp and I thought I'd try with tcp instead [15:50:14 CEST] <devinheitmueller> Just set the ffmpeg output to rtp and use VLC. [15:50:37 CEST] <BtbN> dropped packets on udp usually mean you are overloading the link [15:50:44 CEST] <devinheitmueller> Is it the Internet? Or a LAN? [15:51:04 CEST] <Ducky^> it's a LAN [15:51:16 CEST] <devinheitmueller> Generally speaking, if it looks bad with UDP switching to TCP wont really help. [15:51:36 CEST] <devinheitmueller> Try lowering the bitrate and see if you still get frame dropping. [15:52:06 CEST] <Ducky^> would rtp be better for this or is udp fine as long as the bitrate is right? [15:52:30 CEST] <furq> rtp is normally over udp anyway [15:52:38 CEST] <devinheitmueller> RTP and UDP have effectively the same performance characteristics. [15:52:50 CEST] <devinheitmueller> And as furq pointed out, RTP is generally over UDP. [15:53:21 CEST] <devinheitmueller> One thing to watch out for is to make sure you dont have a sender with GigE and a receiver with 100 Mbit Ethernet. [15:53:42 CEST] <furq> are these both wired connections [15:55:13 CEST] <Ducky^> ffmpeg claims the bitrate is around 2.3kbits [15:55:19 CEST] <Ducky^> but the video is still very glitchy and blocky [15:55:29 CEST] <furq> kbps? [15:55:38 CEST] <Ducky^> yep [15:55:45 CEST] <furq> that seems unlikely [15:56:04 CEST] <furq> unless this is just a still frame [15:56:28 CEST] <Ducky^> no it's 1080p video [15:56:54 CEST] <Ducky^> it does seem low.. [15:57:08 CEST] <furq> yeah that sounds about three orders of magnitude too low [15:57:10 CEST] <devinheitmueller> Well 2.3 Mbps would be low for 1080p video. 2.3 kbps is just insane. [15:57:35 CEST] <furq> is it actually sending data [15:57:37 CEST] <Ducky^> frame= 833 fps= 24 q=22.0 size= 8744kB time=00:00:34.99 bitrate=2047.0kbits/s speed=0.999 [15:57:44 CEST] <furq> oh [15:57:46 CEST] <devinheitmueller> Ok, so that is 2048 kbps. [15:57:48 CEST] <furq> yeah htat's 2mbps [15:57:51 CEST] <devinheitmueller> As in 2.0 mpbs. [15:58:05 CEST] <Ducky^> sorry yes, I can't read [15:58:14 CEST] <furq> so yeah is the receiver wired [15:58:29 CEST] <furq> if it's over wifi then it might be worth trying tcp [15:58:38 CEST] <Ducky^> yes all wired, iperf claims 50Mb bandwidth between the two [15:59:51 CEST] <Ducky^> if I run it locally on the same machine it runs perfectly smooth [16:01:30 CEST] <DHE> the newest versions of ffmpeg support the -bitrate option for UDP to set the transmission rate. it has to be at or higher than the real total bitrate. if using mpegts also use -muxrate at an equal or lower value [16:17:30 CEST] <Ducky^> DHE: -bitrate 1000k -muxrate 1000k for e.g. gives me: [16:18:02 CEST] <Ducky^> [mpegts @ 0x40c7e00] dts < pcr, TS is invalidme=00:00:34.41 bitrate=2233.1kbits/s speed=0.999x [16:18:04 CEST] <Ducky^> Last message repeated 13 times [16:18:06 CEST] <Ducky^> av_interleaved_write_frame(): Cannot allocate memory [16:18:08 CEST] <Ducky^> Error writing trailer of udp://10.249.0.14:1234: Cannot allocate memory [16:34:22 CEST] <DHE> Ducky^: well ffmpeg is estimating a ~2.3 megabit feed and you've requested a 1 megabit muxrate and transmission rate [16:50:59 CEST] <Ducky^> DHE would -b:v 1000k be the right option to use here? [16:51:25 CEST] <Ducky^> after setting that the errors still come through although it isn't running out of memory this time [16:52:04 CEST] <Ducky^> oh no it still broke after a while [17:00:08 CEST] <DHE> there's more overhead than that. and don't forget about your audio [17:00:24 CEST] <DHE> mpegts has around 10% muxing overhead [19:06:49 CEST] <lightbulb6> is it possible for an expression in ffmpeg to evaluate to a string? [19:09:10 CEST] <durandal_1707> lightbulb6: no [19:09:56 CEST] <lightbulb6> durandal_1707: do you know of any way to get the drawtext filter to render different text depending on the frame number? [19:10:46 CEST] <durandal_1707> using another drawtext with enable set [19:10:49 CEST] <lightbulb6> I wanted to use the expression mechanism for that with a couple of nested ifs, like if n is 0 (the first frame) then render "foo", else if n is equal to 1, render "bar", etc [19:11:00 CEST] <lightbulb6> oh [19:11:25 CEST] <lightbulb6> i see [19:11:27 CEST] <lightbulb6> thank you [19:19:23 CEST] <lightbulb6> durandal_1707: "drawtext= text='foo': enable='eq(n, 0)', drawtext= text='bar': enable='eq(n, 1)'" did the trick [19:19:36 CEST] <lightbulb6> thanks [19:28:27 CEST] <doublya> is there any way to build ffmpeg with cuda_sdk and still be redistributable? [19:28:57 CEST] <BtbN> no [19:29:20 CEST] <BtbN> The License of that stuff is so entirely not (L)GPL compatible, that there is no chance for that. [19:58:57 CEST] <Fyr> guys, my subtitle files use fonts that are not available on my system. why does FFMPEG not using the fonts available? [20:00:44 CEST] <c_14> it should fall back to fonts you have [20:00:59 CEST] <c_14> (But that's a fontconfig thing if it doesn't) [20:01:20 CEST] <Fyr> I got: [20:01:20 CEST] <Fyr> Could not create a libass track when reading file '1.srt' [20:01:28 CEST] <Fyr> Error initializing filter 'ass' with args '1.srt' [20:03:57 CEST] <Fyr> here is the paste: [20:03:57 CEST] <Fyr> https://pastebin.com/qAekt4yp [20:04:11 CEST] <c_14> You can't feed .srt files to the ass filter [20:04:15 CEST] <JEEB> Fyr: does the ass filter even support srt btw? I thought it'd just try to feed the file to libass [20:04:16 CEST] <c_14> Use the subtitles filter instead [20:04:18 CEST] <JEEB> which expects ASS [20:04:44 CEST] <kepstin> Fyr: does the mkv file have internal subtitles? [21:01:44 CEST] <Fyr> guys, how to render subtitles into a big video_size, then downscale and burn them into another video? [21:01:57 CEST] <Fyr> it's supposed to antialiasing. [21:02:02 CEST] <Fyr> *to be [21:42:26 CEST] <DHE> probably want to use filter_complex [21:42:47 CEST] <DHE> make a big blank that's transparent, burn the subtitles into it, scale it, and then overlay onto the real video [21:43:01 CEST] <DHE> big blank canvas [22:29:13 CEST] <Ober> Have a lot of 4k Quicktime movs. Converted to webm, but not useful for ios. What is the recommended format for ios? mp4/aac? Looking for preserving the best quality if it can be made smaller than the current quicktime file. [22:31:42 CEST] <klaxa> i think so, you can put h264+aac in mov too i think [22:32:37 CEST] <Ober> webm did a great size reduction job. Just trying to do self hosting off s3. [22:33:07 CEST] <kepstin> you can almost certainly just copy the streams from a mov file to mp4 and it'll work [22:33:24 CEST] <kepstin> if you do want it smaller, use h264 (via the libx264 encoder) [22:33:33 CEST] <klaxa> that will not reduce the size reasonably though (which is the goal) [22:33:40 CEST] <klaxa> yes [22:37:54 CEST] <Ober> is there a ffmpeg command to get info on a given file? [22:38:22 CEST] <klaxa> ffmpeg -i file.mp4 [22:38:35 CEST] <kepstin> Ober: in a pinch, "ffmpeg -i filename" will print some info (and exit with an error you can ignore). For more info in a machine-readable format, try ffprobe [22:39:30 CEST] <Ober> Stream #0:0(eng): Video: mjpeg (jpeg / 0x6765706A), yuvj420p(pc, bt470bg/unknown/unknown), 3840x2160, 60121 kb/s, 25 fps, 25 tbr, 60k tbn, 60k tbc (default) Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 127 kb/s (default) [22:39:31 CEST] <Ober> [22:39:43 CEST] Last message repeated 1 time(s). [22:39:43 CEST] <Ober> wonder if h264 will make a difference [22:40:04 CEST] <alexpigment> mjpeg is a very inefficient codec [22:40:15 CEST] <alexpigment> h264 will certainly be better in terms of file size [22:40:52 CEST] <alexpigment> MJPEG doesn't have interframe compression [22:41:36 CEST] <Ober> ok. good to know. was afraid it would not improve. will the default be to preserve resolution? [22:41:59 CEST] <alexpigment> yes, the resolution will be preserved if you don't specify a resolution specifically [22:42:13 CEST] <Ober> thanks. [22:42:23 CEST] <alexpigment> just make sure and choose a good CRF value for x264 [22:42:36 CEST] <Ober> so mp4-h264/webm should cover everything? [22:42:44 CEST] <Ober> crf max 32? [22:42:50 CEST] Action: Ober forgets the scale on crf [22:42:58 CEST] <alexpigment> i like to use crf of 18-20 or so [22:43:43 CEST] <Ober> excellent, thanks. moved off all my stuff from youtube to videojs on s3. it was unknown ios would not handle webm by me [22:43:46 CEST] <alexpigment> but if you're playing on iOS, you probably won't notice any quality loss with something like 22 or 23 [22:43:57 CEST] <alexpigment> oh this is for streaming [22:44:21 CEST] <alexpigment> you'll probably want to limit the bitrate in some way [22:44:23 CEST] <Ober> well not rtmp streaming [22:44:31 CEST] <Ober> just direct web/video tag. [22:44:40 CEST] <Ober> had not figured out rtmp yet [22:44:42 CEST] <alexpigment> sure, but crf 18-20 will end up with a large file [22:44:53 CEST] <kepstin> crf works okish for streaming if you accept big buffers, but it does make the behaviour a bit unpredictable on low bw connections [22:45:26 CEST] <alexpigment> kepstin: yeah, but he's doing 4k, so it might even bottleneck some "average" connections too [22:46:05 CEST] <kepstin> quite true. For mobile devices you probably want to downscale to 1080p or even 720p [22:46:05 CEST] <alexpigment> i'd probably go with -crf 23 and put a maxrate and bufsize of 15M or so [22:46:12 CEST] <alexpigment> if not downscale, yeah [22:46:57 CEST] <alexpigment> hell, i don't even know if my iPhone 5S will *play* 4k [22:47:05 CEST] <kepstin> 720p is acceptable on most phones up to 5" or thereabouts, above that you might want 1080p. [22:47:24 CEST] <alexpigment> 1080p certainly has hardware support in most modern phones [22:48:02 CEST] <kepstin> i still find it weird that my phone has a 720p screen, but it can record 4k video on the camera :/ [22:48:51 CEST] <alexpigment> well, anyone smart in the phone world would know that you only want to do high density if you can do integer scaling [22:48:58 CEST] <JEEB> "your camera has a 320x240 screen and it can take 15 megapixels worth of pictures" [22:49:19 CEST] <JEEB> I guess that is as weird as that video recording kepstin :) [22:49:48 CEST] <alexpigment> kepstin: your phone battery probably is much better off for it :) [22:49:59 CEST] <Ober> thanks. this will help. [22:50:00 CEST] <alexpigment> there's no way in hell you'd be able to *see* 4K [22:50:09 CEST] <Ober> nothing worse than a crappy video site [22:50:18 CEST] <Ober> "the webm downloaded a 1 gb file!" [22:52:05 CEST] <Ober> what is a realistic max bitrate? [22:52:09 CEST] <Ober> for mobile devices?) [22:52:41 CEST] <kepstin> Ober: if you want to be all fancy & state of the art, you'd do a few encodes at different bitrates/video sizes, as DASH with aligned keyframes in the segments, then have an adaptive player. [22:53:01 CEST] <Ober> yeah. that makes sense. [22:56:59 CEST] <Cracki> 4k on a big screen, or in magnified still photos, is a good thing [22:57:11 CEST] <Cracki> more high res footage of riots is also great for law enforcement [22:59:47 CEST] <kepstin> before i start recording video in 4k on my phone, it prints a message saying that it may quit unexpectedly if the phone overheats. [22:59:50 CEST] <kepstin> great fun. [23:02:38 CEST] <Ober> -b:v 2000 for mobile? [23:02:56 CEST] <Ober> or is it more like -b:v 2M? [23:09:17 CEST] <Ober> ffmpeg -i ./20170201_120004.MOV -vcodec h264 -b:v 600k -crf 18 -s hd1080 -acodec aac test2.mp4 [23:15:02 CEST] <Cracki> 600k video bitrate? that's very low [23:15:07 CEST] <Cracki> while crf 18 is good quality [23:15:12 CEST] <Cracki> pick either or [23:18:09 CEST] <microchip_> Ober: in your cmd, -crf overwrites -b:v as it comes after it [23:19:58 CEST] <Ober> ahh so I should just remove crf? [23:20:06 CEST] <microchip_> Ober: also, use -c:a instead of -acodec. The latter is old and will be obsolete "soon" [23:20:42 CEST] <Ober> k [23:20:52 CEST] <microchip_> Ober: depends. It's not clear what you want to use, crf or bitrate-based encoding [23:20:53 CEST] <Ober> ffmpeg -i ./20170201_120004.MOV -threads 8 -c:v h264 -b:v 600k -s hd1080 -c:a aac test2.mp4 [23:21:05 CEST] <Ober> I assume for mobile streaming I want constant bitrate [23:21:16 CEST] <Ober> going to test and see what it yields [23:21:25 CEST] <Ober> ffmpeg -i ./20170201_120004.MOV -threads 8 -c:v h264 -b:v 600k -s hd1080 -c:a aac test2.mp4 [23:25:58 CEST] <microchip_> Ober: use -c:v libx264. There's not "h264" codec in ffmpeg [23:26:07 CEST] <Cracki> I can tell you now 600k for fullhd video is going to be bad [23:26:43 CEST] <microchip_> Ober: for streaming, you also want vbv [23:29:23 CEST] <Ober> Cracki: recommending for bitrate? [23:30:04 CEST] <Cracki> 2-10 Mbit/s, depending on footage. if it's a webcam, 600k might be good enough :P [23:30:11 CEST] <Cracki> any motion and you want to turn it up [23:30:25 CEST] <microchip_> Ober: for 1080p? at least 5 Mbps and that's the lower end [23:31:36 CEST] <Ober> or vbv-maxrate recommendations? [23:31:39 CEST] <Ober> yeah I suck at the math [23:32:10 CEST] <Ober> lots of motion [23:33:35 CEST] <Cracki> handheld camcorders output 17-32 Mbit/s, for lectures we (at my uni) compomise by delivering 2M on demand, streaming around 3-8M [23:34:29 CEST] <Ober> how do you calculate these magic values for a given resolution? --bitrate B --vbv-maxrate R --vbv-bufsize S [23:34:30 CEST] <Ober> [23:34:50 CEST] <redrabbit> you try [23:34:58 CEST] <redrabbit> and look at the output [23:35:07 CEST] <redrabbit> then try again with a slight different value [23:35:08 CEST] <Cracki> bitrate correlates with quality. [23:35:11 CEST] <redrabbit> then again [23:35:20 CEST] <Cracki> maxrate and bufsize are relevant for streaming *clients* [23:35:23 CEST] <Ober> yeah... I can get a 28.8k modem and test [23:35:31 CEST] <redrabbit> till you are happy with the results [23:35:37 CEST] <Cracki> bufsize is what a client needs to allocate [23:36:00 CEST] <Ober> well given it's math, trial and error seems expensive [23:36:07 CEST] <Cracki> rule of thumb is ~1 second * maxrate = bufsize [23:36:31 CEST] <redrabbit> i use buffize = 2x maxrate here [23:37:06 CEST] <redrabbit> (twice the maxrate) [23:37:40 CEST] <Cracki> bufsize allows the bits to be "distributed across time" a bit more [23:38:01 CEST] <Cracki> so complex frames can still get their bits without the maxrate getting violated [23:38:03 CEST] <Ober> thanks. [23:38:16 CEST] <Cracki> think "leaky bucket", there's a budget the encoder can spend [23:43:37 CEST] <Ober> thanks for the help. much better progress [23:44:55 CEST] <redrabbit> if you want great results a lot of trials helps [23:45:22 CEST] <Ober> no doubt. [23:45:36 CEST] <Ober> writing a program to do this for me. [23:46:05 CEST] <redrabbit> i spend whole nights before i was satisfied with my iptv transcoding settings [23:46:15 CEST] <redrabbit> a handful of them :p [23:46:32 CEST] <redrabbit> trying over 3G modems / capped links etc [23:46:36 CEST] <Cracki> one flavor of "trial" is twopass encoding, but that's not for livestreaming [23:48:15 CEST] <Ober> wow have not heard iptv in 15 years [23:50:29 CEST] <DHE> bitrate is your target bitrate overall. maxrate is the maximum bitrate you want the video to ever consume, and the bufsize is usually somewhere between 50% and 200% of the maxrate [23:50:50 CEST] <DHE> usually set bitrate==maxrate for live [23:51:55 CEST] <DHE> these should give you guidance for what settings to go with. just need to choose a maxrate based on your users, server capabilities, and quality requirements [23:52:38 CEST] <redrabbit> in some cases you can use crf with maxrate [23:59:29 CEST] <Ober> so -max_alloc is the buffer size? [00:00:00 CEST] --- Sat Sep 16 2017

1 0