Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

September 2017

1 participants
60 discussions

ffmpeg-devel.log.20170929
by burek 30 Sep '17

30 Sep '17

[00:09:37 CEST] <cone-230> ffmpeg 03Diego Biurrun 07master:533339bdcc3b: build: Drop leftover reference to old EXAMPLES logic [00:09:38 CEST] <cone-230> ffmpeg 03James Almer 07master:d4b00a23c682: Merge commit '533339bdcc3b39bbd708c723b3cd0b5898350f0f' [00:26:05 CEST] <cone-230> ffmpeg 03Diego Biurrun 07master:db4903eb4875: build: Avoid duplication in examples lists [00:26:06 CEST] <cone-230> ffmpeg 03James Almer 07master:0351b8e358f6: Merge commit 'db4903eb4875bed6c5b8a4259cdd7bc1768dfdf6' [00:35:36 CEST] <jamrial> why is there a Makefile in doc/examples if it's not included anywhere? [00:35:58 CEST] <jamrial> and why does it look like it's mean to be used post libraries installation? wtf [00:36:24 CEST] <jamrial> calling pkg-config for fflibs, duplicating the examples list [00:40:46 CEST] <wm4> because you build them separately [00:41:07 CEST] <wm4> (it's also something that really doesn't encourage me on working on the examples) [00:56:56 CEST] <jamrial> wm4: make examples works fine in an out of tree build without installing anything [00:57:26 CEST] <jamrial> from the root of the build folder i mean [00:59:59 CEST] <wm4> it does? [01:01:17 CEST] <jamrial> try it? [01:02:00 CEST] <jamrial> as i said, doc/examples/Makefile is not included anywhere [01:02:54 CEST] <jamrial> maybe some merge made it obsolete/unused and nobody realized it, because is see new entries have been added with ever new example [01:05:30 CEST] <wm4> seems to work fine [01:11:12 CEST] <Ahti333> wm4 wrt mp3 chapters: I don't see anything that would cause a crash. if both the format and id3 contain chapter info, it would probably mess up the order and/or cause duplicate chapters in s->chapters (or if they don't contain identical info, some or all of the id3 info could be overwritten by the format chapters). this depends on how the format identifies chapters and for some formats on chapter ids in the file. is that what you mean by [01:11:12 CEST] <Ahti333> undefined behaviour or would that be fine? [01:15:02 CEST] <wm4> sounds like it's probably fine then [01:21:20 CEST] <Ahti333> ok so what's the process to get this merged? do I need to do anything anywhere? i've already run fate test and they pass fwiw [01:40:38 CEST] <wm4> I don#t know, the difference between ff_id3v2_read and id3v2_read_internal hints that this was intentional [01:41:00 CEST] <tmm1> if i want to commit the hevc patchset that was reviewed on the list to master, do i need to add signed-off-by to the commits first? should i add myself or people who said LGTM on the ML too? [01:41:10 CEST] <wm4> and the way the apic thing is done demonstrates how to do it in a way how to avoid these potential issues [01:41:24 CEST] <wm4> if it were after me, I'd forbid using id3v2 in ffmpeg for most formats anyway [01:42:04 CEST] <wm4> tmm1: I think the convention is to add yourself as signed-off-by, although ffmpeg as a project doesn't seem to enforce or require this [01:42:31 CEST] <wm4> some people add "Reviewed-by: " headers for each reviewer [01:42:45 CEST] <wm4> but that's also not enforced or required in ffmpeg [01:43:55 CEST] <tmm1> ok thanks [01:46:48 CEST] <iive> the documentation ask the sender to sign it off [01:51:36 CEST] <cone-230> ffmpeg 03Aman Gupta 07master:c32077c0ee1b: avcodec/hevc_ps: extract SPS fields required for hvcC construction [01:51:37 CEST] <cone-230> ffmpeg 03Aman Gupta 07master:3d4f8b9184a4: avcodec/videotoolbox: add hevc support [01:52:19 CEST] <tmm1> and then i should reply to the patches on the list to say they were applied? [01:53:16 CEST] <wm4> yeah, that's usually done [01:56:50 CEST] <JEEB> so where in a patch could I add my own text which wouldn't get applied as the commit message? [01:57:37 CEST] <tmm1> format-patch cover letter? [01:58:01 CEST] <JEEB> that's separate [01:58:15 CEST] <JEEB> as in, cover letter is a separate file IIRC [01:58:32 CEST] <JEEB> while I've seen people put tl;dr in the patch in a location that doesn't get applied [01:59:26 CEST] <wm4> after commit message and before the first file I think [01:59:32 CEST] <JEEB> ah [01:59:42 CEST] <wm4> below the --- [01:59:49 CEST] <JEEB> right, there [01:59:50 CEST] <JEEB> cheers [02:00:05 CEST] <Ahti333> wm4 i guess the proper solution wouldn't require touching all the formats if we only supported id3 chapters in mp3 files, i'll take a stab at that later [02:03:37 CEST] <JEEB> alright, sent a patch out to add me to the general devs list in MAINTAINERS [02:10:11 CEST] <wm4> huh, ffmpeg still doesn't support ttml? [02:10:33 CEST] <rcombs> it's ~XML~ [02:10:38 CEST] <rcombs> though there's an XML parser now so [02:35:06 CEST] <cone-230> ffmpeg 03James Almer 07master:e16ea52ed35c: configure: fix enabling SDL2 without pkg-config [08:43:43 CEST] <cone-095> ffmpeg 03Tobias Rapp 07master:792b1629a881: fate: increase fuzz for refcmp filter tests [09:34:54 CEST] <JEEB> wm4: ugh, TTML [09:35:13 CEST] <JEEB> I've got some stuff around that needs to be pretty much rewritten with regards to that :D [09:57:40 CEST] <ubitux> so i'm killing vda today? [10:47:53 CEST] <JEEB> ok, seems like the test case worked but negative cts offset actually gets broken by additional sanity checks added to movenc.c in FFmpeg :) [10:48:00 CEST] <JEEB> I will be patching that and adding more tests [11:35:31 CEST] <JEEB> I have this feeling that check_pkt() is completely irrelevant to the spec in various ways [11:36:31 CEST] <JEEB> and is effectively breaking the negative cts offsets stuff [11:36:38 CEST] <JEEB> it just doesn't pop up with the tests, funny enough [12:12:46 CEST] <wm4> ubitux: kill it [12:46:04 CEST] <JEEB> ok, I'm now torn by either removing check_pkt with predjudice (since the sanity checks are not actually according to the spec and break even more now with negative cts offset) [12:46:37 CEST] <JEEB> so completely valid stuff gets "fixed" by that function (which is supposed to be some sort of "sanity checker"?) [12:47:24 CEST] <JEEB> or I'll try to make it closer to what the spec says and hope that it is not breaking any valid cases (removal of the function will make sure *all* valid cases get through) [13:52:20 CEST] <ubitux> ah fuck i didn't realized the public functions in vda.h [13:52:22 CEST] <ubitux> meh [13:53:07 CEST] <JEEB> \o/ [13:53:10 CEST] <wm4> these would need to be stubbed out [13:57:48 CEST] <nevcairiel> we already had stubs [13:57:55 CEST] <nevcairiel> in vda.c, for when the feature is disabled [14:25:02 CEST] <BBB> ubitux: but youre just deprecating it, right? [14:25:10 CEST] <BBB> so that should be ok [14:25:29 CEST] <ubitux> no, i'm dropping it [14:25:39 CEST] <ubitux> currently deprecating the pix fmt only [14:25:48 CEST] <ubitux> i'll have to deprecate the stubs too [14:34:50 CEST] <BBB> ubitux: ah, I see& sorry, that sucks, makes it a lot more complex :( [14:35:13 CEST] <ubitux> well, actually& [14:35:33 CEST] <ubitux> unless i'm missing something, the stubs in vda.o were never available [14:35:56 CEST] <ubitux> because the file is compiled conditionnally (whether you have vda or not) [14:36:18 CEST] <ubitux> OBJS-$(CONFIG_VDA) += vda.o videotoolbox.o [14:36:25 CEST] <ubitux> that's the only place where vda.o is added [14:42:33 CEST] <BBB> I dont tihnk you should be expected to fix that while deprecating it [14:42:45 CEST] <BBB> so maybe change the check for CONFIG_VDA inside vda.c to FF_API_VDA? [14:42:51 CEST] <BBB> then it actually does something meaningful ;) [14:43:02 CEST] <BBB> and it doesnt make it worse :-p [15:57:17 CEST] <BBB> so I guess that finishes vmafmotion, now on to vmafs dlm/adm& man this stuff takes so long [16:09:18 CEST] <atomnuker> kierank: https://www.nytimes.com/2017/09/28/us/politics/immigrants-social-media-trum… [16:10:14 CEST] <atomnuker> how stress-free will be your flight to demuxed now that the man knows you support labour? [16:12:51 CEST] <jamrial> ubitux, michaelni: care to check/test/comment https://github.com/jamrial/FFmpeg/commits/mergework ? [16:12:57 CEST] <jamrial> basically, as the libav commit states, it splits the logic for building examples from doc/ off into a separate Makefile in the doc/example folder [16:14:06 CEST] <jamrial> problem is, we already have a Makefile in that folder, but it's separate from the build system. it's meant to be installed as part of the documentation, to help users compile the installed .c example files [16:14:16 CEST] <wm4> atomnuker: so the US state is now doing what advertisers have done for years? [16:15:18 CEST] <jamrial> so what i did was move the existing for-install Makefile to "Makefile.install", then made the build system rename it when installing it [16:16:08 CEST] <jamrial> dunno if that's the best solution, but it works and doesn't clash with the new build system Makefile [16:17:15 CEST] <jamrial> what i might try later is remove the for-install Makefile altogether and create it automatically during configure (or maybe compilation) [16:18:07 CEST] <jamrial> to remove duplication. we have like three places where we need to add a line for every new example [16:18:22 CEST] <atomnuker> wm4: advertisers usually aren't resposible for border control or I think you'd have a headache by the time you got through [16:19:09 CEST] <ubitux> jamrial: i'll have a look tonight (let's say in about 4hours) [16:19:37 CEST] <jamrial> ubitux: ok, thanks! [16:20:15 CEST] <atomnuker> (though tbf you always feel stressed when going through border control, that's part of why schengen is awesome) [16:51:18 CEST] <hanna> you lose the moment you decide to enter the U.S. [16:58:30 CEST] <ldts> just created an account on trac.ffmpeg.org to add documentation support for V4L2 M2M (https://trac.ffmpeg.org/wiki/HWAccelIntro) but is unclear to me how to modify this page...do I need special permissions? [17:02:31 CEST] <ldts> btw this is Kodi running ffmpeg v4l2 being demoed today: https://goo.gl/E8iyZX [17:02:39 CEST] <wm4> ldts: is there a "Edit this page" button on the bottom? [17:03:08 CEST] <ldts> wm4: argh! I expected to be at the top. sorry, yes [18:14:28 CEST] <feliwir> hey, i am having trouble with resampling my audio. When i want to do av_free on a buffer allocated with av_samples_alloc my application always crashes [18:14:33 CEST] <feliwir> see here: https://gist.github.com/feliwir/0431412ab1419b17e9bd69df6b0c2fd8#file-audio… [18:15:23 CEST] <feliwir> help is greatly appreciated [18:17:38 CEST] <feliwir> JEEB, you told me i had to do resampling the other day. Maybe you see any errors? [18:35:07 CEST] <cone-095> ffmpeg 03Carl Eugen Hoyos 07master:44bdb88811a4: lavf/bit: Only build the G.729 bit demuxer if requested. [18:39:50 CEST] <feliwir> noone? :( [18:51:14 CEST] <cone-095> ffmpeg 03Carl Eugen Hoyos 07master:6f7bd8cd90de: lavf/bit: Use pkt->size instead of a constant for G.729 frame size. [19:17:41 CEST] <ubitux> jamrial: can you push on your master the hash on which merge work is based? [19:17:57 CEST] <ubitux> (it will help me identify where the mergework actually starts) [19:20:26 CEST] <jamrial> ubitux: done [19:20:38 CEST] <jamrial> i think [19:24:58 CEST] <ubitux> jamrial: what you did seems sane to me [19:25:10 CEST] <ubitux> i didn't look at the details, but your comment on irc makes sense [19:25:25 CEST] <jamrial> any suggestion for the name other than Makefile.install? [19:25:28 CEST] <ubitux> if you could add it to the commit description of the merge that would be nice [19:25:35 CEST] <ubitux> Makefile.example [19:25:46 CEST] <jamrial> ok [19:25:55 CEST] <ubitux> i'm not sure about having it generated btw, it's nice to be able to link to it in the source tree [19:26:14 CEST] <ubitux> (like, you give a gitweb url to someone "here is an example on how to build it") [19:26:16 CEST] <ubitux> but well [19:26:24 CEST] <ubitux> that could be discussed later [19:26:45 CEST] <jamrial> sure. just figured that having three files where you have to add a line for every new example seemed annoying [19:27:04 CEST] <ubitux> yeah, that sucks [19:27:15 CEST] <ubitux> btw, i'd rather remove the Makefile in the subdirs [19:27:23 CEST] <ubitux> since building within a subdir is not supported [19:27:47 CEST] <ubitux> i'd rather have a FFconfig [19:27:53 CEST] <ubitux> (as Kconfig in the kernel) [19:27:56 CEST] <ubitux> or config.mak [19:27:58 CEST] <ubitux> or whatever [19:28:21 CEST] <ubitux> so it's explicit that we do not actually support make runs in subdir [19:28:50 CEST] <jamrial> sounds like quite the overhaul, especially for the library makefiles [19:29:03 CEST] <ubitux> well, it can still be a makefile [19:29:04 CEST] <atomnuker> the kernel supports such but our dirs are so huge it would be pointless [19:29:15 CEST] <jamrial> the whole SUBDIR logic [19:29:18 CEST] <ubitux> just running "make" will not find any makefile [19:29:29 CEST] <ubitux> (unless you explicit the file) [19:29:30 CEST] <jamrial> ah, you mean renaming them [19:29:34 CEST] <ubitux> yeah :) [19:29:42 CEST] <jamrial> sorry, thought you wanted to merge everything into one massive file :p [19:29:45 CEST] <ubitux> jamrial: btw, you install as "Makefile"? [19:29:50 CEST] <ubitux> no no :) [19:30:28 CEST] <jamrial> I call install with -T (file as target rather than directory), and the target as doc/examples/Makefile [19:30:37 CEST] <JEEB> ugh, why did I press the "defragment virtual disk" button [19:30:44 CEST] <JEEB> now I can't work with the VM I wanted to work on \o/ [19:31:22 CEST] <ubitux> jamrial: then that's fine with me [19:31:42 CEST] <JEEB> (I wanted to fix up the movenc "sanity" check which was already borked before negative cts offsets, but now can also fsck up pretty much all cases of negative cts offsets) [19:32:07 CEST] Action: JEEB is getting a love-hate relationship with https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/movenc.c#L4992...L… [19:32:39 CEST] <ubitux> jamrial: btw, you may want to fix the Makefile dir reference in the faq.texi ("examples" vs "example") and explicit that it's in the installed data directory [19:32:46 CEST] <ubitux> or as "Makefile.example" in the source tree [19:32:55 CEST] <jamrial> ok [19:33:17 CEST] <ubitux> again, thanks for working on this [19:34:16 CEST] <jamrial> no prob. i want the queue gone as much as everyone else :p [19:34:45 CEST] <jamrial> for that matter, i'm about to reach the commit that will move the CLI files to a separate folder [19:35:16 CEST] <stephan_> what's the size of the buffer allocated with av_samples_alloc ? [19:35:49 CEST] <stephan_> when i use linesize as the size i get memory corruption [19:59:49 CEST] <BBB> stephan_: frame->buf[0]->size (assuming its interleaved channels, not planar channels) [20:06:50 CEST] <stephan_> BBB, i need the size writen by swr_convert [20:07:00 CEST] <stephan_> https://github.com/feliwir/arda/blob/master/src/audio/audiostream.cpp#L276 [20:39:59 CEST] <cone-095> ffmpeg 03Diego Biurrun 07master:acb0dea27eff: build: Split logic for building examples off into a separate Makefile [20:40:01 CEST] <cone-095> ffmpeg 03James Almer 07master:b25d6290c67e: Merge commit 'acb0dea27efff4b35796015b96570b59fd517078' [20:42:35 CEST] <JEEB> huh [20:42:36 CEST] <JEEB> http://up-cat.net/p/8df5d7e3 [20:47:06 CEST] <ubitux> doesn't seem to be used except for a sizeof [21:04:37 CEST] <jamrial> ugh [21:06:30 CEST] <jamrial> https://github.com/FFmpeg/FFmpeg/commit/b25d6290c67e193b91becab12e6c88df134… [21:06:32 CEST] <jamrial> any ideas? [21:07:26 CEST] <jamrial> ubitux: ^ [21:07:35 CEST] <jamrial> since you handled macOS build system stuff recently [21:08:15 CEST] <ubitux> it's like cp [21:08:19 CEST] <ubitux> you can explicit the outfile [21:08:31 CEST] <ubitux> install -m 644 Makefile.example /foo/bar/Makefile [21:08:55 CEST] <JEEB> oh fun, clang 5.0.x doesn't like our vorbis encoder :) I think this crashes is the second time http://up-cat.net/p/30903c31 [21:09:18 CEST] <JEEB> (it does the compile when I retry) [21:09:23 CEST] <ubitux> (what's this assistcontrol? a bot?) [21:09:37 CEST] <ubitux> JEEB: no warning? [21:10:16 CEST] <jamrial> ubitux: ok [21:14:43 CEST] <cone-095> ffmpeg 03James Almer 07master:72da8491ca05: build: don't call install with the -T option [21:29:58 CEST] <feliwir> why could avcodec_decode_audio4 possibly crash? [21:42:46 CEST] <jamrial> does it make sense for the examples to use PROGSSUF? [21:43:40 CEST] <wm4> like .exe? [21:44:40 CEST] <jamrial> no, suffix for the name, not a system dependant extension [21:44:45 CEST] <jamrial> that's EXESUF [21:45:15 CEST] <wm4> ah [21:45:18 CEST] <jamrial> it was added for ffmpeg and such. no idea why the examples would need it [21:45:58 CEST] <wm4> what can it be set to and what's the use case? [21:46:47 CEST] <jamrial> /usr/local/bin/ffmpeg-3.2, with /usr/local/bin/ffmpeg being 3.3 [21:47:04 CEST] <wm4> ok I have no idea why that would exist [21:47:20 CEST] <jamrial> more than one installation of both the libraries and CLI [21:47:55 CEST] <wm4> so, no opinion whether it makes sense for the examples [21:48:21 CEST] <jamrial> downstream projects use library suffix for the libraries, like nevcairiel's LAVFilters [21:48:28 CEST] <jamrial> prog suffix i assume is mainly for distro packagers [21:53:10 CEST] <feliwir> hell, even av_send_packet crashes now. I thought that new fancy api would be more stable -.- [21:53:44 CEST] <feliwir> https://github.com/feliwir/arda/blob/master/src/audio/audiostream.cpp#L264 (crashes in the 3rd iteration) [21:54:38 CEST] <feliwir> can't i call av_read_frame as many times as i'd like? [21:56:11 CEST] <nevcairiel> you dont seem to free any of the packets or frames you get [21:56:15 CEST] <nevcairiel> probably running out of memory [21:56:57 CEST] <feliwir> nevcairiel, i am decoding audio, and av_send_packet crashes in the 2nd iteration [21:57:00 CEST] <feliwir> i am good on memory [21:58:49 CEST] <nevcairiel> you also dont initialize the packet at all, should really do that [22:00:42 CEST] <BBB> nevcairiel: I understand your point, my personal opinion is that regardless of effort (hardly any), if the gain is exactly 0.0, then its never worth it :-p [22:00:58 CEST] <nevcairiel> well just dont break the ABI in any case? [22:01:23 CEST] <BBB> I agree with that part (so if vda.c was there, the ABI should remain, even if it becomes dysfunctional and always returns error codes) [22:01:24 CEST] <nevcairiel> if i build something today and build something tomorrow with the exact same configure command, and the ABI changes, thats a break [22:01:30 CEST] <BBB> yes, I agree [22:01:36 CEST] <BBB> Im not arguing against that [22:01:41 CEST] <BBB> I 100% agree [22:01:59 CEST] <BBB> just dont think its worth including vda.o abi on non-mac systems tomorrow since they werent there today [22:02:01 CEST] <feliwir> nevcairiel, it's not a pointer so what would i need to initialize? [22:02:05 CEST] <BBB> I agree its broken, but who cares [22:02:22 CEST] <nevcairiel> the dummy things in vda may never have worked, but vda itself did and was autodetected (ie. always on), so these functions were in a default build, and need to remain in that [22:03:01 CEST] <BBB> always on *on mac* :-p and so should remain on *on mac*, yes [22:03:23 CEST] <nevcairiel> i dont care if its mac only or always, mac only seems more work and people dont seem to want mroe work =p [22:03:30 CEST] <BBB> my understanding was that the question was whether the symbols should start to exist on linux builds. they should be in theory, but I dont think its worth it to do effort for that [22:03:39 CEST] <BBB> ok, I guess we agree then ;) [22:04:34 CEST] <jamrial> nevcairiel: hey, i just had to deal with a mac only stupid thing :p [22:05:18 CEST] <feliwir> nevcairiel, what you meant by i don't initialize the packet? :( [22:06:03 CEST] <jamrial> feliwir: you're not initializing it with av_init_packet() [22:06:46 CEST] <nevcairiel> also, for future stability, dont use AVPacket on the stack, instead make it a pointer and use av_packet_alloc() which does the init for you [22:08:31 CEST] <wm4> does anyone think this mac ABI thing is worth anything [22:08:40 CEST] <wm4> like, your time, or the effort of discussion [22:13:25 CEST] <cone-095> ffmpeg 03Diego Biurrun 07master:ab566cc96bc0: build: Separate logic for building examples from that for building avtools [22:13:25 CEST] <cone-095> ffmpeg 03James Almer 07master:eace20a8623d: Merge commit 'ab566cc96bc0c31b34d944214bc06cec8ae8b640' [22:20:26 CEST] <feliwir> ok, thanks nevcairiel [22:24:43 CEST] <feliwir> maybe also an idea what is making swr_convert crash here: https://github.com/feliwir/arda/blob/master/src/audio/audiostream.cpp#L285 ? [22:33:40 CEST] <atomnuker> use swr_convert_frame() [22:57:12 CEST] <cone-095> ffmpeg 03James Almer 07master:3df437c2d195: build: add missing changes to ensure examples build with progs-suffix [23:05:29 CEST] <feliwir> did anyone take a look at my swr_convert issue? [23:06:58 CEST] <Compn> more people are on the mailing list than are here :) [23:07:00 CEST] Action: Compn runs afk [23:08:57 CEST] <jamrial> feliwir: atomnuker made a comment. and this is not the channel to ask for help using the libraries [23:09:35 CEST] <feliwir> jamrial, which one is it then? In #ffmpeg they tell me to go to #ffmpeg-devel [23:09:45 CEST] <jamrial> they are wrong [23:09:57 CEST] <jamrial> this channel is for development of ffmpeg, not with ffmpeg [23:10:03 CEST] <jamrial> it's #ffmpeg, or https://lists.ffmpeg.org/mailman/listinfo/libav-user/ [23:10:33 CEST] <feliwir> i didn't get a single message from atomnunker [23:11:04 CEST] <feliwir> but i'll ask in #ffmpeg then, thanks [23:11:07 CEST] <jamrial> [17:33:41] <@atomnuker> use swr_convert_frame() [23:12:07 CEST] <feliwir> wow, nice [23:34:56 CEST] <JEEB> michaelni: do you have any recollection on why you set the sample[i+1].dts - sample[i].dts "duration" checks at INT_MAX instead of UINT32_MAX? (first in 2014 for assert0 and then in 2016 for the "j00ru" sample) [23:35:26 CEST] <JEEB> because sample_default_duration is uint32 and then stts is uint32 for sample_delta [23:36:00 CEST] <JEEB> ctts DTS-to-CTS offset can be either uint32 (v0) or int32 (v1) [00:00:00 CEST] --- Sat Sep 30 2017

1 0

ffmpeg.log.20170929
by burek 30 Sep '17

30 Sep '17

[00:00:40 CEST] <JEEB> -af "pan=5.1|c0=blah|c1=blah" and so on [00:00:42 CEST] <JEEB> I guess? [00:01:12 CEST] <JEEB> for mapping the FL and FR channels as stereo it'd be -af "pan=stereo|c0=FL|c1=FR" [00:02:03 CEST] <JEEB> so the "5.1" is the name of the 5.1 channel mapping [00:02:03 CEST] <SpeakerToMeat> Yes but then I don't get the center to left and right or back to left and right that I get with the built in mapper [00:02:26 CEST] <JEEB> I just gave the latter as a nexample [00:02:46 CEST] <JEEB> you map the correct channels from your 12ch input as 5.1 [00:03:00 CEST] <JEEB> by making the first line I posted full with all the six channels [00:03:10 CEST] <JEEB> and instead of blah having the correct identifiers [00:03:17 CEST] <JEEB> then after that you cna downmix to stereo [00:04:53 CEST] <SpeakerToMeat> Ok so the first line, the filter goes before the input file so it gets associated with it? [00:05:00 CEST] <JEEB> no [00:05:18 CEST] <JEEB> filtering is always in transcoding, post decoding [00:05:38 CEST] <SpeakerToMeat> Ok, [00:05:50 CEST] <JEEB> also I wonder if there's a better way... I remember utilizing filter_complex for this sort of stuff ages ago [00:06:24 CEST] <SpeakerToMeat> and in that pan filter, c0 is the input or output? I mean: c0=FL is assigning a channel tagged FL to channel 0, or assigning channel 0 to the FL channel tag [00:06:45 CEST] <JEEB> channel 0 being FL (from the input) [00:06:54 CEST] <JEEB> probably other ways of notating things too [00:07:53 CEST] <SpeakerToMeat> I'll see if I can kick firefox into responding to get the pan filter doc [00:08:18 CEST] <JEEB> oh [00:08:19 CEST] <JEEB> pan="5.1| c0=c1 | c1=c0 | c2=c2 | c3=c3 | c4=c4 | c5=c5" [00:08:24 CEST] <JEEB> the examples had this :P [00:08:53 CEST] <JEEB> so you can just use c0=c0 , and so forth [00:09:22 CEST] <JEEB> https://ffmpeg.org/ffmpeg-filters.html#Remapping-examples [00:09:29 CEST] <SpeakerToMeat> A thing of beauty [00:09:39 CEST] <SpeakerToMeat> Thank you, sorry to ask so much but my FF is locked up right now [00:10:09 CEST] <JEEB> also do note that if you copypasta what I pasted from the example as is, the first two channels get swapped [00:10:27 CEST] <JEEB> just in case you didn't notice :p [00:10:38 CEST] <JEEB> if you started typing it yourself again then it should be OK [00:10:49 CEST] <SpeakerToMeat> Yes I gathered that [00:12:12 CEST] <SpeakerToMeat> Thanks [00:50:40 CEST] <moniker-> does anyone know what is VLD bitstream decoding [00:51:13 CEST] <moniker-> when i turn it off in my potplayer i can play multiple 1080p60 streams without problem, right now im playing 4 [00:51:44 CEST] <moniker-> when it is on (by default) i can only play 1 stream if i open second then the other stream will be at 15-20 fps [00:54:02 CEST] <pzich> moniker-: according to the internet, it's "variable-length decoding", which I could see being more expensive to decode [00:54:40 CEST] <moniker-> oh wait im stupid [00:54:44 CEST] <moniker-> well ofc [00:54:59 CEST] <moniker-> if i turn of VLD then it's not hw accelerated anymore, it's sw [00:55:08 CEST] <pzich> oh hah, that'd do it [00:55:08 CEST] <moniker-> nvm -.- [00:55:18 CEST] <moniker-> that explains why i can run so many streams [01:03:31 CEST] <SpeakerToMeat> Is there any way I can tell ffmpeg that a video is nto actually 25 fps but 24? constant frame count... [01:04:10 CEST] <SpeakerToMeat> Specially when converting from discrete image frames... [01:06:53 CEST] <pzich> I think you just need -r 24 [01:07:06 CEST] <pzich> Or maybe -framerate, I can't remember [01:07:58 CEST] <SpeakerToMeat> pzich: Left of the input I think [01:08:05 CEST] <pzich> Ah yes [01:08:12 CEST] <SpeakerToMeat> I think that's it, thanks [01:08:20 CEST] <pzich> something like ffmpeg -framerate 24 -i images%d.jpg ... [01:13:24 CEST] <SpeakerToMeat> it's -r I think, let me try [01:13:49 CEST] <SpeakerToMeat> Hmm no doesn't seems to [01:14:56 CEST] <pzich> pretty sure it's -framerate, at least according to https://en.wikibooks.org/wiki/FFMPEG_An_Intermediate_Guide/image_sequence#M… [01:16:38 CEST] <SpeakerToMeat> Yep you're right [01:16:44 CEST] <SpeakerToMeat> Thank you [01:17:53 CEST] <SpeakerToMeat> Ok time to run home, see you all. [01:17:55 CEST] Action: SpeakerToMeat bows [03:12:47 CEST] <hendry> is there a FFMPEG script to create like a 10 frame poster image like how Youtube do it? [03:12:58 CEST] <hendry> Browser's seem hopeless as previewing a bunch of MP4s [03:26:26 CEST] <rafasc> Is there a way to limit this just to the first couple of seconds? ffmpeg -f lavfi -i 'amovie=file.mp4,showspectrumpic=s=800x600' spec.jpg [03:28:58 CEST] <furq> trim=end=2,showspectrumpic [03:29:10 CEST] <furq> also i'm not sure why you'd use the movie filter there but i guess it still works [03:30:39 CEST] <rafasc> I tried not using it, but wasn't able to make it work [03:32:54 CEST] <rafasc> thanks furq, in my case needed atrim, but you pointed me to the right direction. :) [03:35:34 CEST] <furq> -i file.mp4 -filter_complex [a:0]atrim=end=2,showspectrumpic [03:35:37 CEST] <furq> but nvm [03:36:04 CEST] <furq> 0:a rather [03:45:54 CEST] <rjp421> anyone with a pi and pi-cam, and updated packages+kernel+ffmpeg-git: can you please test piping raspivid to ffprobe or ffmpeg? please confirm whether or not ffmpeg crashes (pls let me know results so i can stop spamming this) [03:57:08 CEST] <rafasc> showspectrumpic doesn't allow setting limits to the vertical resolution? I just wanted to plot lets say, between 0 and ~200hz [06:03:27 CEST] <blap> showspec-trump-ic [06:55:49 CEST] <lindylex> why does this fail : ffmpeg -i left.mp4 -i right.mp4 -filter_complex "[0:v]crop=638:720, pad=640:720:0:0:green[tmp0]; [1:v]crop=638:720, pad=640:720:2:0:green[tmp1]; [tmp0][tmp1]hstack[v];" -y o.mp4 with this error : [AVFilterGraph @ 0x558bbf274f20] No such filter: '' [06:55:49 CEST] <lindylex> Error initializing complex filters. [06:55:49 CEST] <lindylex> Invalid argument [07:05:50 CEST] <dystopia> what are you trying to do lindylex [07:06:40 CEST] <lindylex> I am adding to videos side by side and placing a border color between them. Both videos have no audio and this is causing problems I think. [07:06:45 CEST] <lindylex> No audi stream [07:06:47 CEST] <lindylex> audio [07:09:32 CEST] <lindylex> dystopia : I solved it ffmpeg -i left.mp4 -i right.mp4 -filter_complex "[0:v]crop=638:720, pad=640:720:0:0:green[tmp0]; [1:v]crop=638:720, pad=640:720:2:0:green[tmp1]; [tmp0][tmp1]hstack[v]; anullsrc[silent1]; anullsrc[silent2]; [silent1][silent2]amerge=inputs=2[a]" -map [v] -map [a] -ac 2 -y o.mp4 [09:40:58 CEST] <dreamon_> hello. I have a UHD Video 29GB converted by using "ffmpeg -i input.mov -c:v libx265 -crf 28 output.mp4" now File is around 1.9GB. But having issues to let it play. Its hooking and vlc player isnt playing its sometimes gray fragmented. [09:42:15 CEST] <dreamon_> I play it with a intel i5 notebook and nvidia support. Original file 29GB is also hooking on this laptop. but runs on a UHD TV perfectly [09:46:42 CEST] <dreamon_> how can I find out my cpu/gpu is fast enough to play it in UHD? [09:55:45 CEST] <JEEB> dreamon_: if mpv can play it then it's fast enough :P [09:58:31 CEST] <rabbe> hi. i want to stream a webcam under linux, using ffmpeg and ffserver in (modified) mp4 and webm containers for support across major browsers in a html5 video tag. but since i don't have the hardware yet i want to use the screen as source for now [09:59:08 CEST] <rabbe> someone have any premade ffmpeg parameters for this? [10:00:15 CEST] <dreamon_> JEEB, mpv plays it same hooking. but Im not sure it uses hw support nvidia. tried windows10 and ubuntu .. [10:00:24 CEST] <rabbe> am i on the right track that i first create a .ffm stream and then in ffserver-config i specify information of the mp4 and webm streams which will then be available to the web page? [10:00:57 CEST] <JEEB> dreamon_: --hwdec=dxva2-copy with nvidia [10:01:29 CEST] <JEEB> dreamon_: but basically that means that your CPU is not fast enough, and using dxva2 the dedicated decoder hardware will be utilized for HEVC [10:04:05 CEST] <dreamon_> dxva2 is that a cpu or a gpu part? [10:04:39 CEST] <JEEB> depends on which gets utilized by DXVA2 if you have a HW decoder chip in your CPU [10:05:11 CEST] <JEEB> generally speaking it utilizes decoder hardware on graphics stuff (which both an intel CPU would have in addition to the nvidia GPU) [10:05:23 CEST] <JEEB> most likely if you have an nvidia GPU stuck in there it will utilize it [10:05:39 CEST] <JEEB> as you have to have a screen connected to the intel iGPU to get that poked, I think [10:05:40 CEST] <dreamon_> JEEB, how can I find out? [10:05:52 CEST] <JEEB> -v outputs it I think [10:06:27 CEST] <JEEB> but it's not the CPU part of the CPU even if it uses the CPU [10:06:39 CEST] <JEEB> it's the dedicated chip that does video decoding :P [10:06:45 CEST] <JEEB> (which is part of the GPU on the CPU) [10:07:01 CEST] <JEEB> (this all with --hwdec=dxva2-copy) [10:07:12 CEST] <JEEB> without that it's all CPU [10:07:27 CEST] <JEEB> as in, CPU CPU [10:08:21 CEST] <dreamon_> cat /proc/cpuinfo | grep dxva2 no output. [10:09:22 CEST] <dreamon_> can you give me how syntax? [10:10:24 CEST] <JEEB> oh, you're on linux [10:10:28 CEST] <JEEB> you just said windows 10 :P [10:10:42 CEST] <dreamon_> Im on Linux, too [10:10:58 CEST] <JEEB> DXVA2 is the windows hw decoding API [10:11:53 CEST] <JEEB> on linux I'm actually not sure. it used to be vdpau for nvidia, vaapi for intel/amd [10:11:56 CEST] <dreamon_> ffmpeg is only running on Linux.. at the moment. but playing video I tried on both OS [10:12:16 CEST] <JEEB> but now vdpau is broken for some formats and doesn't support 10 bit :P [10:13:07 CEST] <JEEB> anyways, I'll let you figure it out yourself on linux :P [10:23:45 CEST] <dreamon_> JEEB, tried in Windows ffmpeg -v --hwdec=dxva2-copy.. but invalid [10:23:52 CEST] <JEEB> I was speaking of mpv [10:24:06 CEST] <JEEB> mpv --hwdec=dxva2-copy file [10:26:33 CEST] <rabbe> please help me when you can. i need this for a robot project [10:28:19 CEST] <dreamon_> JEEB, What the ****.. now it plays totaly smoothly. [10:29:12 CEST] <dreamon_> Fast as hell. [10:30:23 CEST] <dreamon_> JEEB, how can I tell windows it should start every video play by mpv with this option? [10:37:19 CEST] <JEEB> dreamon_: basically your CPU is not fast enough but your GPU's hw decoder *is* fast enough :P [10:37:31 CEST] <JEEB> you can add a hwdec=dxva2-copy to the config file if you really want to [10:39:32 CEST] <dreamon_> JEEB, an the other Players like M$, VLC, dont use this option? [10:40:46 CEST] <JEEB> no fucking idea [10:41:40 CEST] <dreamon_> JEEB, THANK YOU VERY VERY MUCH!! [10:42:48 CEST] <dreamon_> do you think there is such a option for linux users too? [10:43:01 CEST] <JEEB> vaapi or vdpau are the alternatives [10:43:27 CEST] <JEEB> or I think they might have nvdec now for nvidia as well [10:47:30 CEST] <rabbe> can someone help me getting my mp4 stream for html5 video to work? https://pastebin.com/vF7WzHb2 [13:19:05 CEST] <Kadigan> Hey, I have a question -- ffmpeg accepts two duration formats - the classic H:MM:SS.ms, and the S.ms format... but is there a way to escape the : when doing this for filters? [13:19:44 CEST] <Kadigan> I was getting a fairly confusing error about unknown filter configuration 23.76, until I realized it was the : being parsed, splitting the time format and breaking things. [13:21:12 CEST] <Kadigan> Or do I need to use strictly the seconds[.ms] format in there? (I was using this in conjuction w/ afade, ie. "afade=t=out:st={computed time}:d=01.00") [13:57:00 CEST] <dreamon> JEEB, For Linux "mpv --hwdec=vaapi-copy movie.mp4" works very well!! [13:57:23 CEST] <JEEB> congrats [13:57:31 CEST] <JEEB> I have vaapi set up on my intel laptop as well [13:57:46 CEST] <JEEB> although I only need it in very specific cases because generally software decoding is more stable [13:58:48 CEST] <dreamon> JEEB, Linux laptop only as intel gpu activated. But this as you told me a cpu option.. ;) So it works with this device perfect [13:59:56 CEST] <dreamon> Yes. without -copy its get stucked by seeking video. but with -copy it works good for me [14:11:37 CEST] <JEEB> dreamon: it doesn't matter if the chip is on CPU or GPU [14:11:43 CEST] <JEEB> it's hw decoding [14:11:44 CEST] <JEEB> not sw [14:13:03 CEST] <dreamon> JEEB, How can I check out witch one (cpu/gpu) has it implented? -v? [14:19:01 CEST] <titbang> lol wut JEEB [14:32:12 CEST] <JEEB> dreamon: yes [14:32:20 CEST] <JEEB> or well, it will list which driver it loads [14:32:30 CEST] <JEEB> i965 for intel's, and otherwise for nvidia [14:32:44 CEST] <JEEB> titbang: intel iGPU vs (any) dGPU. [14:32:51 CEST] <JEEB> where the decoder ASIcs are [15:38:46 CEST] <lindylex> Greeting all. I am placing to videos with no audio side by side. I ran the following and it seems to be in a never ending loop. It is take forever and still has not completed. ffmpeg -i left.mp4 -i right.mp4 -filter_complex "[0:v]crop=638:720, pad=640:720:0:0:green[tmp0]; [1:v]crop=638:720, pad=640:720:2:0:green[tmp1]; [tmp0][tmp1]hstack[v]; anullsrc[silent1]; anullsrc[silent2]; [silent1][silent2]amerge=inputs=2[a]" -map [v] [15:38:48 CEST] <lindylex> -map [a] -ac 2 -shortest -y o.mp4 [15:43:52 CEST] <isabella> hi, Can anyone help me with applying instagram-like filter on video, please? [15:45:29 CEST] <lindylex> isabella : What do you want your video to look like? Show us a photo. [15:45:58 CEST] <isabella> https://www.cssfilters.co/ [15:46:29 CEST] <isabella> like the first one [15:46:32 CEST] <isabella> 1977 style [15:47:20 CEST] <isabella> i'm currently doing a project enabling the user adding filter to their video [15:47:34 CEST] <isabella> for the front side, it's easy to do that using css filters. [15:48:07 CEST] <isabella> but it's difficult to apply the exact same effect using ffmpeg. since i'm not familiar with it. [15:50:52 CEST] <isabella> i do find some video filters corresponding like hue, with which i can configure brightness, saturation and hue (same with css filters) [15:51:04 CEST] <lindylex> isabella : try this ffmpeg -i myvideo.mov -f lavfi -i "color=brown:s=1280x720" -filter_complex "[0:v]setsar=sar=1/1[s]; [s][1:v]blend=shortest=1:all_mode=screen:all_opacity=0.9[out]" -map [out] -map 0:a -y out.mp4 [15:51:28 CEST] <isabella> thank you. i'm trying it. [15:59:49 CEST] <isabella> lindylex: it works if i change the size to 320x240 and opacity to 0.5 [16:03:22 CEST] <isabella> is there any clue that can help me to map the css filters to the ffmpeg video filters? [16:07:22 CEST] <isabella> lindylex May i ask you how to do the 'Lofi'? [16:13:11 CEST] <isabella> for the color, can i assign it with hex value instead of color name like 'brown'? [16:13:54 CEST] <lindylex> yes [16:14:49 CEST] <lindylex> isabella : Like this 0x000000 . This give you black. [16:16:27 CEST] <isabella> lindylex: ok, thank you [16:18:07 CEST] <lindylex> isabella : The grsnular control you desire will come from this >>> eq= I do not have enough experience to consult you on this, others do. [16:20:56 CEST] <isabella> i tried the eq by setting only the contrast, but it seems not exactly the same effect with css filters. [16:28:24 CEST] <isabella> lindylex how can i keep the same quality of video? its size decreased to 880KB from 1.1MB [16:31:56 CEST] <lindylex> isabella : Quality is a difficult question to answer. Does it look terrible from the original? How will it be consumed? What is the quality of the video that is being modified? [16:33:12 CEST] <titbang> 0xFFFFFFF [16:35:40 CEST] <isabella> it's fine. it does not look terrible [16:36:08 CEST] <lindylex> Congrats and best of luck have a great weekend. [16:37:14 CEST] <isabella> lindylex thx. you too. but i have a question of processing mp4 video. [16:37:45 CEST] <isabella> it provoke error if the input video is mp4 [16:38:03 CEST] <isabella> Stream map '0:a' matches no streams. To ignore this, add a trailing '?' to the map. [16:38:31 CEST] <lindylex> It looks like your video has no audio. Am I correct? [16:38:56 CEST] <isabella> exactly [16:39:28 CEST] <lindylex> Your ffmpeg string has map 0:a in it and this is searching for a video with audio stream. [16:39:52 CEST] <lindylex> You must modify it to handle videos without audio. [16:40:41 CEST] <isabella> adding a trailing '?' will solve the problem? if no. how can i modify it [16:40:49 CEST] <isabella> to no audio case [16:42:50 CEST] <lindylex> Please post your ffmpeg string. [16:43:16 CEST] <isabella> ffmpeg -i video4.mp4 -f lavfi -i "color=0x4c59ba:s=1280x720" -filter_complex "[0:v]setsar=sar=1/1[s]; [s][1:v]blend=shortest=1:all_mode=screen:all_opacity=0.5[out]" -map [out] -map 0:a? -y video4.2.mp4 [16:44:46 CEST] <isabella> it's in progress. not yet finished. [16:45:05 CEST] <furq> !filter eq @isabella [16:45:05 CEST] <nfobot> isabella: http://ffmpeg.org/ffmpeg-filters.html#eq [16:45:36 CEST] <furq> presumably for 1977 you just want -vf eq=1.1:1.1:1.3 [16:45:58 CEST] <furq> !filter colorchannelmixer [16:45:58 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#colorchannelmixer [16:46:02 CEST] <furq> then you can do grayscale and sepia with that [16:46:04 CEST] <lindylex> I am trying to solve the same problem with how do I handle a video with no audio. I did this : ffmpeg -i left.mp4 -i right.mp4 -filter_complex "[0:v]crop=638:720, pad=640:720:0:0:green[tmp0]; [1:v]crop=638:720, pad=640:720:2:0:green[tmp1]; [tmp0][tmp1]hstack[v]; anullsrc[silent1]; anullsrc[silent2]; [silent1][silent2]amerge=inputs=2[a]" -map [v] -map [a] -ac 2 -y o.mp4 but it renders the video indefinitely. It is in some kind [16:46:04 CEST] <lindylex> of loop. [16:47:01 CEST] <furq> you can just do anullsrc=c=2 for stereo fyi [16:47:08 CEST] <furq> and then add -shortest as an output option [16:47:24 CEST] <lindylex> furq: thanks let me try this. [16:47:27 CEST] <isabella> lindylex ok. so it's not gonna work with no audio video [16:47:35 CEST] <furq> although anullsrc apparently defaults to stereo [16:47:45 CEST] <isabella> furq nofobot. thank you [16:48:10 CEST] <isabella> i tried. but i don't know how to map the values [16:48:14 CEST] <furq> just remove -map 0:a [16:48:32 CEST] <lindylex> isabella : correct furq is much more experienced with this. I will try my best to help you. If I solve mine then it will apply to yours. [16:48:40 CEST] <furq> you don't really need filter_complex if you only have one input stream [16:49:00 CEST] <furq> just ffmpeg -i in.mp4 -vf eq=1.1:1.1:1.3 out.mp4 [16:49:32 CEST] <isabella> ok. for the moment single input feed my needs [16:49:40 CEST] <lindylex> furq : was this for me? anullsrc=c=2 [16:49:52 CEST] <furq> lindylex: apparently it's anullsrc=stereo [16:49:56 CEST] <furq> but also that should be the default [16:50:26 CEST] <lindylex> This is what I need to modify : ffmpeg -i left.mp4 -i right.mp4 -filter_complex "[0:v]crop=638:720, pad=640:720:0:0:green[tmp0]; [1:v]crop=638:720, pad=640:720:2:0:green[tmp1]; [tmp0][tmp1]hstack[v]; anullsrc[silent1]; anullsrc[silent2]; [silent1][silent2]amerge=inputs=2[a]" -map [v] -map [a] -ac 2 -y o.mp4 [16:50:46 CEST] <furq> just get rid of everything after [silent1] [16:51:27 CEST] <furq> unless you actually want quadraphonic output [16:51:59 CEST] <furq> and yeah add -shortest as an output option to stop it from running forever [16:53:05 CEST] <isabella> furq https://www.cssfilters.co/ how to do the 'Lofi' filter with eq, please? [16:53:22 CEST] <furq> 1.5:1:1.1 [16:53:50 CEST] <furq> it's probably not going to match exactly fwiw [16:55:28 CEST] <isabella> furq i get all white. [16:56:43 CEST] <isabella> ffmpeg -i video1.mp4 -vf "eq=1.5:1:1.1" video4.1.mp4 [16:57:03 CEST] <isabella> is it because of the input video is mp4 [16:57:15 CEST] <furq> oh nvm brightness is -1 to 1 [16:57:26 CEST] <furq> it should be 1.5:0:1.1 then [16:57:52 CEST] <furq> but like i said the values won't map exactly between the sliders on that page and the eq filter [16:57:55 CEST] <furq> you'll need to mess around with it a bit [16:59:19 CEST] <isabella> ok [16:59:22 CEST] <furq> eq and colorchannelmixer will get you most of the effects on there though [16:59:24 CEST] <isabella> how to do the sepia? [16:59:45 CEST] <furq> !filter colorchannelmixer [16:59:45 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#colorchannelmixer [16:59:47 CEST] <furq> see the examples on there [17:01:15 CEST] <furq> there's also hue for hue rotate, and boxblur (and a million other blur filters) for blur [17:02:03 CEST] <isabella> i don't understand it colorchannelmixer=.393:.769:.189:0:.349:.686:.168:0:.272:.534:.131 [17:02:19 CEST] <isabella> what are those values? [17:04:53 CEST] <isabella> nfobot furq could you please explain it to me? [17:05:45 CEST] <isabella> what does .393 correpond to? [17:09:59 CEST] <isabella> ah. ok i understand. [17:10:32 CEST] <isabella> <feColorMatrix type="matrix" values=" (0.393 + 0.607 * [1 - amount]) (0.769 - 0.769 * [1 - amount]) (0.189 - 0.189 * [1 - amount]) 0 0 (0.349 - 0.349 * [1 - amount]) (0.686 + 0.314 * [1 - amount]) (0.168 - 0.168 * [1 - amount]) 0 0 (0.272 - 0.272 * [1 - amount]) (0.534 - 0.534 * [1 - amount]) (0.131 + 0.869 * [1 - amount]) 0 0 0 0 0 1 0"/> [17:14:33 CEST] <rhinoTMT> Hello good people. I'm trying to join two image sequences together in two different folders. I see that one way to do it is to create a separate text file containing the paths i.e. "file './intro/frame_%04d.png'. I don't want my image sequences to start at 0, though. Is there any way to incorporate the -start_number and -vframes tags into that text file before the concat occurs? [17:17:29 CEST] <relaxed> rhinoTMT: might be easier to write a script and `ln` exactly what you want to a temp dir [17:18:46 CEST] <cryptodechange> I tried aq-mode 3 on anime [17:18:56 CEST] <rhinoTMT> relaxed: thanks. I think I might be over my head here, so I'm just going to bulk rename the sequences I need. [17:18:57 CEST] <cryptodechange> Not sure if it's the aq, but the colours seem to be a bit different [17:20:52 CEST] <isabella> furq ffmpeg -i video4.mp4 -vf "colorchannelmixer=.393:.769:.189:0:.349:.686:.168:0:.272:.534:.131" video4.1.mp4 [17:21:07 CEST] <isabella> it does not work with this command [17:21:44 CEST] <isabella> how can i pass the sepia value? [17:24:48 CEST] <isabella> nfobot ? [17:46:17 CEST] <ubitux> isabella: -vf curves=vintage? :p [17:48:34 CEST] <lindylex> furq : ffmpeg -i left.mp4 -i right.mp4 -filter_complex "[0:v]crop=638:720, pad=640:720:0:0:green[tmp0]; [1:v]crop=638:720, pad=640:720:2:0:green[tmp1]; [tmp0][tmp1]hstack[v]; anullsrc[silent1]" -map [v] -map [silent1] -ac 2 -shortest -y o.mp4 [17:48:34 CEST] <lindylex> this run forever as it looks like it is in a loop. [18:04:23 CEST] <isabella> ubitux thx. [18:07:32 CEST] <cryptodechange> what can cause a somewhat overall color pallette/tone shift in anime encodes? [18:08:59 CEST] <cryptodechange> using deblock=0 aq=3:0.8 psy-rd=0.7:0.1 [18:31:54 CEST] <dystopia> did you have "-tune animation" set cryptodechange? [18:36:57 CEST] <kepstin> cryptodechange: probably colour matrix issues, x264 preserves colours quite well in general [18:51:15 CEST] <lindylex> This runs forever. I need to place these two video side by side they have no audio and it is creating a problem. ffmpeg -i left.mp4 -i right.mp4 -filter_complex "[0:v]crop=638:720, pad=640:720:0:0:green[tmp0]; [1:v]crop=638:720, pad=640:720:2:0:green[tmp1]; [tmp0][tmp1]hstack[v]; anullsrc[silent1]" -map [v] -map [silent1] -ac 2 -shortest -y o.mp4 [19:15:51 CEST] <Johnjay> Hrm when I do the detectvolume feature on these two audio files, both are max 0db [19:16:08 CEST] <thebombzen> lindylex: it's probably a buffering issue that's making it take so long. I'd recommend using a color= video source to create a 4x720 green video [19:16:19 CEST] <Johnjay> the quieter one is -20db mean vol and the louder one is -9.8db [19:16:23 CEST] <thebombzen> and then hstack the three videos together. it's probably faster than padding it and you might not run into buffering issues [19:16:34 CEST] <thebombzen> when you have enormous filtergraphs it can hang [19:16:41 CEST] <Johnjay> how do I go about normalizing the audio in this case? [19:17:32 CEST] <thebombzen> Johnjay: are you looking for the loudnorm filter? [19:17:36 CEST] <thebombzen> !filter loudnorm [19:17:36 CEST] <nfobot> thebombzen: http://ffmpeg.org/ffmpeg-filters.html#loudnorm [19:18:20 CEST] <Johnjay> possibly. I also need to understand what the hell I'm doing as well [19:18:32 CEST] <thebombzen> I have no idea how to use that, but that does do loudness normalization [19:18:45 CEST] <Johnjay> it says it resamples to 192Mhz. Is that a problem? [19:18:52 CEST] <Johnjay> er Khz sorry [19:19:30 CEST] <thebombzen> well you can just add an aresample=48k afterward [19:19:50 CEST] <thebombzen> but also you could consider acompressor [19:20:17 CEST] <thebombzen> also checkout dynaudnorm [19:20:19 CEST] <thebombzen> !filter dynaudnorm [19:20:19 CEST] <nfobot> thebombzen: http://ffmpeg.org/ffmpeg-filters.html#dynaudnorm [19:21:55 CEST] <Johnjay> no such filter 'loudnorm' [19:21:56 CEST] <Johnjay> huh? [19:22:49 CEST] <Johnjay> does the windows port not have it? [19:24:47 CEST] <Johnjay> well it's not in ffmpeg -filters so... [19:25:07 CEST] <thebombzen> it might be recent [19:26:05 CEST] <cryptodechange> dystopia: I used the animation settings from -fullhelp, and dialed it a bit closer to that of film. [19:26:15 CEST] <cryptodechange> kepstin: how would I identify/rectify the colour matrix issues? [19:26:30 CEST] <Johnjay> well at any rate I think I manually solved it with brute force with -af volume=5.0 [19:27:10 CEST] <Johnjay> but basically i have two sets of audio files and one is much louder than the other [19:27:23 CEST] <Johnjay> not sure what the best way is to fix that in general without that loudnorm thing you said [19:28:16 CEST] <thebombzen> Johnjay: loudnorm is recent [19:28:29 CEST] <thebombzen> grab a recent build from Zeranoe https://ffmpeg.zeranoe.com/builds/ and it should be there [19:28:45 CEST] <Johnjay> ok but can you explain in layman's terms if it's even what I need? [19:29:14 CEST] <Johnjay> I'm listening to the volume=5.0 file now and it sounds a little tinny [19:29:31 CEST] <thebombzen> that's because the volume filter just multiplies all the samples by 0.5 [19:30:04 CEST] <Johnjay> loudnorm will do it more intelligently i guess? [19:30:59 CEST] <thebombzen> you probably are looking for acompressor though [19:32:15 CEST] <thebombzen> !filter acompressor [19:32:15 CEST] <nfobot> thebombzen: http://ffmpeg.org/ffmpeg-filters.html#acompressor [19:32:46 CEST] <Johnjay> apparently my ffmpeg is located in a folder called "FFmpeg for Audacity" [19:33:00 CEST] <thebombzen> the FFmpeg for Audacity is very old [19:33:22 CEST] <Johnjay> i thought i installed it separately though. wtf [19:33:29 CEST] <thebombzen> download a build from Zeranoe and put it in something in your path (I prefer ~/bin) [19:33:44 CEST] <Johnjay> well i'm on windows [19:33:57 CEST] <Johnjay> I've been using C:\Users\Public\bin for that [19:34:02 CEST] <thebombzen> sure, okay [19:34:06 CEST] <Johnjay> no idea what that is but it seems to work [19:34:10 CEST] <stephan_> what's the size of the buffer allocated with av_samples_alloc ? [19:35:21 CEST] <Johnjay> google tells me it is what it is, a folder for all users to share files with each other [19:41:26 CEST] <Diag> Wow guys, the epa is looking to outlaw R718(dihydrogenmonoxide) refrigeration systems by 2020 because of how harmful it is to the environment. [19:50:01 CEST] <redrabbit> you old troll [20:03:11 CEST] <lindylex> thebombzen : it's probably a buffering issue that's making it take so long. I'd recommend using a color= video source to create a 4x720 green video << This and then overlay it? [20:03:27 CEST] <thebombzen> no, don't use overlay [20:03:41 CEST] <lindylex> I have no idea what to do. [20:04:08 CEST] <lindylex> It is balking because of the no audio. It work well when the video has audio. [20:04:24 CEST] <thebombzen> you said it's going forever [20:04:35 CEST] <thebombzen> do you mean it's hanging? or do you mean it just won't stop encoding null audio? [20:04:56 CEST] <lindylex> Wont stop encoding I believe. [20:05:03 CEST] <thebombzen> oh, then you have a different issue [20:05:10 CEST] <thebombzen> but -shortest should fix that, though. [20:05:52 CEST] <thebombzen> emphasis on complete console output, (as you already pasted your command) [20:06:04 CEST] <pzich> if necessary, it's also pretty easy to add a silent audio track [20:06:19 CEST] <pzich> -shortest sounds like it should fix it based on what you've said though [20:06:20 CEST] <thebombzen> that's what it looks like they're doing with anullsrc [20:06:40 CEST] <thebombzen> although if your goal is to add silence, you should probably be using aevalsrc=0, rather than anullsrc [20:06:44 CEST] <thebombzen> because anullsrc doesn't zero out memory [20:07:00 CEST] <thebombzen> unless I'm wrong about that, it just allocates and passes uninitilized data [20:07:03 CEST] <pzich> I think I missed the pasted command, is it pretty far back? [20:07:19 CEST] <thebombzen> it was: ffmpeg -i left.mp4 -i right.mp4 -filter_complex "[0:v]crop=638:720, pad=640:720:0:0:green[tmp0]; [1:v]crop=638:720, pad=640:720:2:0:green[tmp1]; [tmp0][tmp1]hstack[v]; anullsrc[silent1]" -map [v] -map [silent1] -ac 2 -shortest -y o.mp4 [20:07:20 CEST] <lindylex> https://pastebin.com/wy5XQ74y [20:07:32 CEST] <thebombzen> lindylex: emphasis on complete console output [20:08:10 CEST] <pzich> incase it's unclear: run it and copy everything that ffmpeg spits out too [20:09:17 CEST] <lindylex> https://pastebin.com/qtL9QsAR [20:10:18 CEST] <pzich> was it sitting at 799 for a while before you ^C-ed? [20:11:03 CEST] <lindylex> It was working and I had to ctrl - c to sto it. [20:11:46 CEST] <ianbytchek> greetings. can anyone tell what AVMEDIA_TYPE_NB means, NB abbreviation in particular? documentation doesn't say anything on this. not narrowband is t? [20:11:51 CEST] <pzich> and this works when both files have audio, but not one? or neither? [20:12:49 CEST] <lindylex> thebombzen : This is correct >> ffmpeg -i left.mp4 -i right.mp4 -filter_complex "[0:v]crop=638:720, pad=640:720:0:0:green[tmp0]; [1:v]crop=638:720, pad=640:720:2:0:green[tmp1]; [tmp0][tmp1]hstack[v]; anullsrc[silent1]" -map [v] -map [silent1] -ac 2 -shortest -y o.mp4 [20:14:14 CEST] <lindylex> thebomzen : The solution you were suggesting was to dynamically create a video with the dimension and then add three videos horizontally. [20:14:32 CEST] <pzich> ianbytchek: it's hard to say for sure, but based on other uses of _NB and _nb, it may indicate the number of occurences or type of something? https://github.com/FFmpeg/FFmpeg/blob/183fd30e0f6fdc762fd955a24cfc7e6a49e10… [20:15:45 CEST] <ianbytchek> pzich: interesting& :D [20:16:42 CEST] <thebombzen> lindylex: ignore what I said before, I had misunderstood your problem [20:16:51 CEST] <lindylex> Got it. [20:17:08 CEST] <thebombzen> either way, what happens if you don't use the anullsrc and don't use -map [silent1] [20:17:10 CEST] <pzich> ianbytchek: yeah, I'm also seeing functions like "av_get_channel_layout_nb_channels", which "Return the number of channels in the channel layout." https://www.ffmpeg.org/doxygen/2.2/group__lavu__audio.html#gac95619abeb32e4… [20:17:19 CEST] <thebombzen> that is what happens if you don't add an extra audio track? [20:18:19 CEST] <pzich> it seems like with -shortest added it should work with or without audio tracks [20:18:27 CEST] <lindylex> Let me try to construct this. [20:22:23 CEST] <lindylex> thebombzen : I hate my life. What you said works : ffmpeg -i left.mp4 -i right.mp4 -filter_complex "[0:v]crop=638:720, pad=640:720:0:0:green[tmp0]; [1:v]crop=638:720, pad=640:720:2:0:green[tmp1]; [tmp0][tmp1]hstack[v]" -map [v] -y o.mp4 [20:22:34 CEST] <pzich> yup [20:22:38 CEST] <pzich> you didn't want the audio, did you? [20:22:59 CEST] <thebombzen> what I find strange is that -shortest did nothing [20:23:15 CEST] <thebombzen> perhaps it's a bug in FFmpeg that has been fixed since last may? seems recent for a bug like that though [20:23:26 CEST] <pzich> I see that hstack has its own shortest flag? maybe that needs to be set? https://ffmpeg.org/ffmpeg-filters.html#toc-hstack [20:23:35 CEST] <thebombzen> hstack does, but the audio was the issue [20:23:36 CEST] <pzich> err https://ffmpeg.org/ffmpeg-filters.html#hstack [20:23:37 CEST] <thebombzen> not one of the videos [20:24:17 CEST] <thebombzen> The only reason -shortest shouldn't do anything would be if the video also was running forever, but it wasn't, which is why I asked that question [20:24:19 CEST] <pzich> do you need the audio to be mixed? or passed through at all? if not, just leave it off, way easier [20:25:08 CEST] <lindylex> pzich : I am writting a python wrapped around this and I needed to handle situations when there is no audio. [20:25:46 CEST] <pzich> right, but do you need the audio in the resulting file? if not, just don't map an audio track and it'll be ignored [20:25:58 CEST] <pzich> or add -an [20:27:00 CEST] <thebombzen> using -map will automatically unmap anything else. so if you're using -map [vout] or whatever you called it, you won't have audio by default [20:27:08 CEST] <pzich> right [20:27:40 CEST] <lindylex> I tested to see if both videos have audio. If one of them was missing audio I just sent the videos to the ffmpeg command that handles no audio track [20:27:42 CEST] <thebombzen> if you want to preserve the audio from the left file, you can add -map 0:a? -c:a copy which will map the audio stream(s) from the left input file but only if they exist [20:28:16 CEST] <thebombzen> using -map 0:a? will map audio tracks from input 0, if they exist. similarly, -map 1:a? will map audio stream(s) from input 1, but only if they exist [20:28:32 CEST] <thebombzen> then you can use -c:a copy to avoid re-encoding, or you can use -c:a aac -b:a 128k [20:28:33 CEST] <pzich> if anything, I'd do the opposite. If it has audio, run `ffmpeg -i in.mp4 -an -c copy out.mp4` and handle the both with no audio [20:28:43 CEST] <pzich> ok bye then [20:28:57 CEST] <thebombzen> rip [20:53:08 CEST] <BytesBacon> Question with the -map switch. If I'm using mediainfo to look at the track information, I'm assuming that it's like an array in programing. Where 0 is the first one? (I have that right) [20:57:31 CEST] <DHE> BytesBacon: yes, but also keep in mind that -map supports things like 0:v for "first video stream" to assist in decision making [20:58:05 CEST] <BytesBacon> DHE, thanks. [20:58:52 CEST] <JEEB> if you want a parse'able info of the file, use ffprobe with -of json and -show_streams [21:00:07 CEST] <Diag> redrabbit: if you were talking to me water DOES in fact have an R number assigned XD [21:01:47 CEST] <BytesBacon> JEEB, thank you! That'll make it even easier for me. [21:02:38 CEST] <JEEB> 3/25 [22:16:06 CEST] <cryptodechange> is there any documentation regarding aq-mode 3 and 4? can't seem to find it on x264 fullhelp [22:17:13 CEST] <cryptodechange> oh nvm found it [22:33:36 CEST] <cryptodechange> Getting some banding (look at top right), and the colour tone shift > https://imgur.com/a/QWq34 [22:34:59 CEST] <cryptodechange> With the aq-strength being at 0.8, a little higher than animation, what can be done to reduce banding? if that is even banding [22:42:05 CEST] <lindylex> Sorry about that I had some hardware failure. [22:55:08 CEST] <thebombzen> cryptodechange: try -aq-mode:v 3 [22:55:26 CEST] <thebombzen> you should use that by default for your encodes anyway, it's a good ide [22:55:35 CEST] <thebombzen> idea* [22:57:09 CEST] <thebombzen> aq-mode:v 3 weights darker areas as greedier for bits, so color banding in darker areas is less of a problem. the cost will be color banding in lighter areas which is far less noticeable by the way human eyes work [22:57:47 CEST] <cryptodechange> I have an aq-mode:3 in that example, unless you mean something different? [22:58:17 CEST] <thebombzen> rip, didn't see it :O [22:58:22 CEST] <thebombzen> ignore me, I'm being dumb right now [22:59:26 CEST] <thebombzen> cryptodechange: in that case, try increasing psy-rd [22:59:32 CEST] <thebombzen> perhaps to 0.8. see what happens [22:59:41 CEST] <cryptodechange> there's so much conflicting advice when it comes to anime that deviates from the animation tune defaults [22:59:58 CEST] <cryptodechange> People stating it softens the linework too much, etc [23:00:01 CEST] <thebombzen> correct, the usual advice is that "tune animation is bad, don't use it" [23:00:11 CEST] <thebombzen> it sets the psy-rd too low [23:00:29 CEST] <thebombzen> also aq-strength=0.8 is fairly standard for high quality sources, so I would leave it at 0.8 [23:00:35 CEST] <thebombzen> you can up it if you want to preserve grain though [23:00:44 CEST] <cryptodechange> I've used deblock -3 and aq=0.8 for most of my film streams [23:00:55 CEST] <thebombzen> I would not use deblock -3 for anime though [23:01:02 CEST] <thebombzen> I usually leave it at -1:-1 [23:01:02 CEST] <cryptodechange> even -1 seemed too much [23:01:21 CEST] <thebombzen> -1 is good for anime [23:01:24 CEST] <cryptodechange> e.g. I just downloaded some encoded anime that uses deblock 1,-1 [23:01:32 CEST] <thebombzen> ew [23:01:39 CEST] <thebombzen> should try to keep the numbers the same [23:01:56 CEST] <cryptodechange> aq .85 and default psy-rd 1,0 [23:02:10 CEST] <thebombzen> either way, in your case, leave aq-mode at 3, and aq-strength at 0.8 and try upping the psy-rd slightly. perhaps to 0.8, and see how that affects the artifacts in the upper right [23:02:27 CEST] <cryptodechange> What's your opinion on the overall color? [23:02:34 CEST] <cryptodechange> the browns specifically [23:02:48 CEST] <cryptodechange> There's a tint of difference in both aq 1 and 3 [23:03:20 CEST] <thebombzen> it's hard for me to tell without diff.pics [23:04:14 CEST] <thebombzen> yea, you're right. that's probably a colorspace or range issue [23:04:22 CEST] <thebombzen> rather than an issue with x264 itself [23:04:57 CEST] <thebombzen> make sure the colorspace stuff is correct (probably bt.709( [23:05:22 CEST] <thebombzen> are you converting full to partial range? [23:05:30 CEST] <cryptodechange> lemme compare on mediainfo [23:06:00 CEST] <cryptodechange> -c:v libx264 -preset veryslow -pix_fmt yuv420p10le -profile:v high10 -level 4.1 [23:06:31 CEST] <thebombzen> don't set the level or the profile manually [23:06:36 CEST] <thebombzen> unless you *really need* to [23:06:48 CEST] <thebombzen> but for 10-bit video I find it hard to believe that you would really need to [23:07:02 CEST] <thebombzen> and that's probably libswscale screwing with the conversion [23:07:13 CEST] <thebombzen> I would try this: -vf zscale,format=yuv420p10le [23:07:30 CEST] <cryptodechange> original = BT.709 [23:07:33 CEST] <thebombzen> you're upping to 10-bit with libswscale. I would recommend using zimg instead [23:07:53 CEST] <cryptodechange> mediainfo for encode test doesn't have anything regarding BT [23:08:28 CEST] <thebombzen> cryptodechange: rather than using -pix_fmt yuv420p10le, try using -vf zscale,format=yuv420p10le [23:08:51 CEST] <cryptodechange> will run a test now [23:08:58 CEST] <cryptodechange> ty [23:09:13 CEST] <JEEB> also you most likely want to actually make sure you are tagging your output as the same colorspace as well [23:09:21 CEST] <JEEB> so if BT.709 in then BT.709 out as well [23:10:56 CEST] <cryptodechange> How would I do that JEEB? [23:13:10 CEST] <thebombzen> cryptodechange: if you want it to be exact, you can use -vf zscale=p=709:t=709:m=709:r=full:agamma=false,format=yuv420p10le [23:13:37 CEST] <cryptodechange> sweet christmas [23:13:49 CEST] <cryptodechange> alright i'mma do it! [23:13:52 CEST] <thebombzen> but I believe JEEB meant to tag the metadata [23:13:57 CEST] <JEEB> thebombzen: that doesn't map the output stream necessarily [23:14:21 CEST] <JEEB> and I think if you don't override and input is set and your family is the same then the filter should keep it [23:14:35 CEST] <thebombzen> probably [23:14:45 CEST] <thebombzen> as for how to tag the output as 709? I don't know [23:15:08 CEST] <JEEB> -colorspace bt709 [23:15:16 CEST] <thebombzen> ah, that does it lol [23:15:26 CEST] <cryptodechange> so back to my original? [23:15:35 CEST] <cryptodechange> pixfmt and add colorspace? [23:15:56 CEST] <thebombzen> no, keep -vf zscale,format=yuv420p10le [23:16:01 CEST] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html => ctrl+F "color_primaries" [23:16:08 CEST] <JEEB> and then all that are under it until whatchamacallit [23:16:20 CEST] <feliwir> hey, question: when i use srw_convert_frame does it says that the output frame must already be initialized (with format set). The format is already set when i create my resampler, so why that additional step? [23:16:21 CEST] <JEEB> until color_range are relevant [23:16:36 CEST] <JEEB> feliwir: just for the record when I was doing resampling I just used avfilter [23:16:39 CEST] <thebombzen> cryptodechange: what -pix_fmt does it is automatically adds "-vf scale,format=yuv420p10le" but using -vf zscale,format=yuv420p10le should help [23:16:47 CEST] <JEEB> since I could just give it avframes and om nom nom [23:16:56 CEST] <thebombzen> aresample filter yea [23:16:56 CEST] <JEEB> also avfilter let me get N samples [23:17:14 CEST] <JEEB> which was very useful when a decoder returned a different amount of samples than an encoder wants [23:17:21 CEST] <JEEB> which is a real issue [23:17:29 CEST] <feliwir> hm, so there are 2 libraries to do the same thing? [23:17:40 CEST] <JEEB> no, underneath avfilter uses swresmaple [23:17:46 CEST] <JEEB> but it offers a more "convenient" interface [23:17:51 CEST] <JEEB> with the filtering [23:18:10 CEST] <JEEB> you create the audio filter chain and push/pull to/from it [23:23:30 CEST] <cryptodechange> hopefully when I tuned this right, it will be a one-size fit all for all my anime encodes [23:23:34 CEST] <Mista_D> vdpau advice needed, can't use Nvidia in CENTOS to decode. [23:23:45 CEST] <cryptodechange> apart from the super grainy 'remastered' blurays... [23:25:04 CEST] <Mista_D> https://pastebin.ca/3880077 VFPAU errors [23:27:10 CEST] <BtbN> Is h264_vdpau even a thing? oO [23:29:37 CEST] <Mista_D> BtbN: apprently not... ) [23:30:32 CEST] <BtbN> Well, it does not fail, so it has to exist [23:30:57 CEST] <BtbN> try if the vdpau -hwaccel just works. And if not, it might just not be wried up in ffmpeg.c [23:39:19 CEST] <cryptodechange> thebombzen a bit of an improvement https://imgur.com/a/VjTaC [23:40:07 CEST] <cryptodechange> but even with the colorspace parameter there is still a tonal shift [23:40:14 CEST] <CoreX> never seen somebody spend so much time wanting to get the colours right [23:40:40 CEST] <JEEB> then you have not seen the mpv opengl renderer guy [23:40:58 CEST] <CoreX> OCD about it i bet [23:41:25 CEST] <JEEB> well, you just want to get things right after you've spent reading the specifications enough [23:41:28 CEST] <JEEB> lol [23:41:45 CEST] <cryptodechange> this has ruined my life [23:41:55 CEST] <cryptodechange> honestly, it started me just enjoying content I download [23:42:14 CEST] <cryptodechange> then encoding my own media to try and get a consistent quality [23:42:25 CEST] <cryptodechange> then buying my own blurays and here I am [23:42:46 CEST] <cryptodechange> can't binge watch anything because I deem the quality not to my standards :D [23:43:37 CEST] <JEEB> if I watch I don't encode [23:43:44 CEST] <JEEB> after I've watched I can encode [23:43:50 CEST] <JEEB> (if needed) [23:44:18 CEST] <cryptodechange> Yeah, I am happy just storing raw remuxes, but I travel a lot and use plex [23:44:47 CEST] <cryptodechange> Plex uses ffmpeg veryfast if I'm not mistaken, which has a noticeable quality degradation vs. encoding it myself to that bitrate or thereabouts [23:45:41 CEST] <cryptodechange> but I'm not too fussed about getting the colours right, but flicking back and forth between the sample images (which I normally do for films, etc), there's quite a noticeable change in the overall area [23:45:58 CEST] <cryptodechange> I'm more concerned what causes it if there's something I've missed [23:46:01 CEST] <cryptodechange> about* [23:47:01 CEST] <JEEB> what are you utilizing to check the clip btw? [23:48:24 CEST] <cryptodechange> VLC, stepping frames with E and taking snapshots with shift+S [23:48:31 CEST] <JEEB> I recommend mpv [23:48:32 CEST] <thebombzen> http://mpv.io/ [23:48:37 CEST] <thebombzen> lol you ninjad me on that one [23:49:17 CEST] <cryptodechange> That being said, the original was played on a network drive whilst I'm connected to my VPN as it's ~4gb [23:49:37 CEST] <cryptodechange> Not sure if that would affect anything [23:49:44 CEST] <cryptodechange> switching to mpv naow [23:49:48 CEST] <thebombzen> mpv has a cache feature so you should be fine [23:50:35 CEST] <cryptodechange> will resample both images [23:51:16 CEST] <JEEB> also you should always check if swscale is stabbing you in the back [23:51:22 CEST] <JEEB> I think -v verbose does output that [23:51:33 CEST] <JEEB> (hopefully, I remember it should probably for the filter hcains) [23:52:13 CEST] <cryptodechange> I also did some comparisons with psy-trellis [23:53:01 CEST] <cryptodechange> 5 tests between 0 to 0.2, it ended up being 'eeny meeny miny moe' [23:54:08 CEST] <cryptodechange> as there was only subtle variations in the artifacts and grains [23:55:53 CEST] <cryptodechange> In relation to grains, apart from denoising filters, what should I focus on with much grainier sources? [23:56:23 CEST] <redrabbit> deblock [23:56:52 CEST] <cryptodechange> with my 'anime preset' at deblock -1, would you recommend 1 instead? [23:57:03 CEST] <cryptodechange> I suppose a higher AQ too? possibly 1? [23:57:36 CEST] <redrabbit> there's a preset for grain [23:57:58 CEST] <redrabbit> lower deblock values to preserve grain [23:58:25 CEST] <redrabbit> if you put enough bitrate of course [23:58:34 CEST] <Mista_D> anyway to improve FFmpeg's efficiency in terms of using more cores with libx264? [23:58:49 CEST] <cryptodechange> With grain, I suppose 2pass would be better than CRF (CRF I normally use) [23:59:18 CEST] <notdaniel> Mista_D, run 3 instances of ffmpeg and split your inputs between them ;) [23:59:26 CEST] <cryptodechange> I wouldn't mind flattening the grain a little if it doesn't hurt the quality too much [23:59:32 CEST] <BtbN> two pass encoding is only good if you target a specific file size, nothing else [23:59:36 CEST] <Mista_D> notdaniel: concat is not too accurate there... [23:59:59 CEST] <cryptodechange> E.g. with this test encode of One Punch Man I had an average bitrate of 8.5mbps [00:00:00 CEST] --- Sat Sep 30 2017

1 0

ffmpeg-devel.log.20170928
by burek 29 Sep '17

29 Sep '17

[00:00:18 CEST] <BBB> oh boy [00:00:40 CEST] <BBB> btw [00:00:46 CEST] <Compn> triggered [00:05:07 CEST] <cone-906> ffmpeg 03Diego Biurrun 07master:dad7a9c7c0ae: configure: Rework dependency handling for conflicting components [00:05:08 CEST] <cone-906> ffmpeg 03James Almer 07master:7659f35638e2: Merge commit 'dad7a9c7c0ae8ebc56f2e3a24e6fa4da5c2cd491' [00:07:33 CEST] <cone-906> ffmpeg 03Martin Storsjö 07master:57ec83e4246b: omx: Use the EOS flag to handle flushing at the end [00:07:34 CEST] <cone-906> ffmpeg 03James Almer 07master:f1cdfd29590c: Merge commit '57ec83e4246b21c2f0c068b9151d806737d4497f' [00:09:23 CEST] <jkqxz> jamrial: d1e7e4fbe wasn't quite enough. <http://sprunge.us/gPeD>? [00:09:42 CEST] <cone-906> ffmpeg 03Diego Biurrun 07master:c546147db07d: configure: Correctly recurse in do_check_deps() [00:09:43 CEST] <cone-906> ffmpeg 03James Almer 07master:57db1faf7a47: Merge commit 'c546147db07d16a76c2fb698d2e8a3057f393475' [00:10:40 CEST] <jamrial> jkqxz: yeah, saw it on fate. I don't have such a system so i couldn't test if it was enough back then [00:10:59 CEST] <jamrial> jkqxz: the current error is missing size_t, so including stddef.h should fix it, i think [00:11:04 CEST] <jkqxz> I've actually tested it, now works for me. [00:11:22 CEST] <jkqxz> avcodec.h is enough for everything currently missing (size_t, AVFrame, AVPacket). [00:12:07 CEST] <jamrial> ok, push it then [00:12:47 CEST] <wm4> hm I noticed the v4l encoder is preferred over libx264 [00:12:50 CEST] <wm4> that's probably not right [00:12:58 CEST] <cone-906> ffmpeg 03Mark Thompson 07master:da53c424b96f: lavc/v4l2: Add missing header include [00:13:08 CEST] <jkqxz> jamrial: ^ Thanks. [00:13:29 CEST] <jamrial> thanks to you for fixing it, if anything :p [00:13:47 CEST] <jkqxz> wm4: Huh, so it is. [00:13:53 CEST] <JEEB> call for pokes on https://ffmpeg.org/pipermail/ffmpeg-devel/2017-September/216816.html , https://ffmpeg.org/pipermail/ffmpeg-devel/2017-September/216699.html :3 [00:13:57 CEST] <jkqxz> (Barfs immediately on x86, of course.) [00:13:59 CEST] <jkqxz> Let me fix that too. [00:15:44 CEST] <jamrial> wm4, jkqxz: should be a matter of changing the order in allcodecs.c [00:16:37 CEST] <jkqxz> Yeah, on it. [00:24:27 CEST] <jkqxz> wm4: jamrial: <http://sprunge.us/JGQe>? [00:25:03 CEST] <jamrial> jkqxz: no, just move the encoders. keep the decoders where they are [00:25:32 CEST] <jamrial> also, i don't think h263 needs to be moved [00:26:00 CEST] <jamrial> the internal encoder entry is before the v4l2 entry, so it's fine [00:26:11 CEST] <jkqxz> Why does that help? CUVID/NVENC is a similar case, and is in the lower list. [00:26:40 CEST] <wm4> hm I'm too tired to see the difference [00:27:04 CEST] <jamrial> the point here is to make sure the hw encoders are after the external software libraries like libx264/5, libvpx and such [00:27:23 CEST] <jamrial> hw decoders being right below the internal decoder in the list is ok [00:27:32 CEST] <jkqxz> Yes. And moving them all like this is the most consistent way to do it. [00:27:38 CEST] <jkqxz> Otherwise they are very mixed up. [00:28:13 CEST] <jkqxz> Hmm, qsv is the way you are saying. [00:28:21 CEST] <jamrial> jkqxz: something like https://pastebin.com/raw/ENyr3c4s [00:28:44 CEST] <jamrial> ah, there's a mistake there now that i see [00:28:59 CEST] <jamrial> added H264_V4L2M2M decoder twice :p [00:29:00 CEST] <jkqxz> It should move all of them. [00:29:02 CEST] <jamrial> second should be encoder [00:29:13 CEST] <jkqxz> I'll do the same thing as qsv, then. [00:29:51 CEST] <jamrial> the decoders down there like vp9_cuvid and such could be moved up IMO [00:30:41 CEST] <jamrial> as long as they are below the native decoder it should be ok [00:30:50 CEST] <jamrial> but that's some other patch [00:31:11 CEST] <jamrial> right now libx264/5/vpx should have priority [00:31:57 CEST] <jkqxz> Really those encoders just shouldn't be used at all without being requested. [00:32:42 CEST] <jkqxz> VAAPI should never be picked by default. [00:35:36 CEST] <jkqxz> ... maybe there should be a "don't use this by default" flag. [00:35:53 CEST] <JEEB> doesn't sound like a bad idea [00:35:55 CEST] <jkqxz> (Kindof like AVOID_PROBING.) [00:40:10 CEST] <cone-906> ffmpeg 03Martin Storsjö 07master:0331c3f5e8cb: arm: vp9itxfm: Make the larger core transforms standalone functions [00:40:11 CEST] <cone-906> ffmpeg 03Martin Storsjö 07master:115476018d2c: aarch64: vp9itxfm: Make the larger core transforms standalone functions [00:40:12 CEST] <cone-906> ffmpeg 03Martin Storsjö 07master:47b3c2c18d18: arm: vp9itxfm: Move the load_add_store macro out from the itxfm16 pass2 function [00:40:13 CEST] <cone-906> ffmpeg 03Martin Storsjö 07master:79d332ebbde8: aarch64: vp9itxfm: Move the load_add_store macro out from the itxfm16 pass2 function [00:40:14 CEST] <cone-906> ffmpeg 03Martin Storsjö 07master:5eb5aec475aa: arm: vp9itxfm: Do a simpler half/quarter idct16/idct32 when possible [00:40:15 CEST] <cone-906> ffmpeg 03Martin Storsjö 07master:a63da4511d0f: aarch64: vp9itxfm: Do separate functions for half/quarter idct16 and idct32 [00:40:16 CEST] <cone-906> ffmpeg 03Martin Storsjö 07master:3933b86bb93a: arm: vp9itxfm: Share instructions for loading idct coeffs in the 8x8 function [00:40:17 CEST] <cone-906> ffmpeg 03Martin Storsjö 07master:4da4b2b87f08: aarch64: vp9itxfm: Share instructions for loading idct coeffs in the 8x8 function [00:40:18 CEST] <cone-906> ffmpeg 03Martin Storsjö 07master:ed8d293306e1: aarch64: vp9itxfm: Use a single lane ld1 instead of ld1r where possible [00:40:19 CEST] <cone-906> ffmpeg 03Martin Storsjö 07master:3dd7827258dd: aarch64: vp9itxfm: Use the right lane sizes in 8x8 for improved readability [00:40:20 CEST] <cone-906> ffmpeg 03Martin Storsjö 07master:8476eb0d3ab1: aarch64: vp9itxfm: Update a comment to refer to a register with a different name [00:40:21 CEST] <cone-906> ffmpeg 03Martin Storsjö 07master:0c0b87f12d48: aarch64: vp9itxfm: Fix incorrect vertical alignment [00:40:22 CEST] <cone-906> ffmpeg 03James Almer 07master:276f035a4d0f: Merge commit '0c0b87f12d48d4e7f0d3d13f9345e828a3a5ea32' [00:41:55 CEST] <jkqxz> jamrial: <http://sprunge.us/LcZc>? [00:43:13 CEST] <jamrial> jkqxz: yeah, that should be good [00:45:40 CEST] <wm4> yeah looks good [00:46:19 CEST] <jkqxz> Output looks right. Building with libx264 only, it gets picked for mkv. webm picks vp8_v4l2m2m and barfs. [00:47:51 CEST] <thebombzen> while we're on automatic order, for NUT, mpeg4 gets picked by default rather than ffv1 [00:48:00 CEST] <thebombzen> this doesn't make sense [00:48:24 CEST] <cone-906> ffmpeg 03Mark Thompson 07master:c1f22c295930: lavc: Move V4L2 encoders lower in the list [00:49:22 CEST] <jkqxz> thebombzen: Yes. Change <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/nutenc.c;h=a92ff…>? [00:49:48 CEST] <thebombzen> sure. I'll send a patch to the mailing list [00:49:58 CEST] <wm4> lol at that mpeg audio logic [00:50:23 CEST] <JEEB> lol [00:51:25 CEST] <jkqxz> Matroska is libvorbis ? Vorbis : AC-3. Wtf? [00:52:33 CEST] <thebombzen> should I also change the audio to FLAC or libopus? [00:53:44 CEST] <thebombzen> I'm thinking changing the default for nut to FLAC off of libvorbis, if we're using FFV1 as the default video codec [00:54:10 CEST] <jamrial> jkqxz: external library encoder first if possible, and if not available, a decent internal encoder [00:54:37 CEST] <jkqxz> Well, AC-3 would not be my first choice of internal encoder. [00:54:38 CEST] <jamrial> that's the logic used in these muxers [00:54:44 CEST] <jkqxz> But yes, I suppose it's fair. [00:55:00 CEST] <jamrial> it could maybe be changed to aac now, if it's no longer tagged as experimental [00:55:17 CEST] <wm4> we don't have a proper internal opus encoder yet? [00:55:27 CEST] <jamrial> yes, but tagged experimental i think? [00:55:43 CEST] <thebombzen> I believe psy was added recently to internal opus but that doesn't mean it's ready [00:56:10 CEST] <jamrial> for mkv aac is the better choice. opus for webm. but i don't know if the internal encoders for both are good enough for that [01:01:28 CEST] <JEEB> aac encoder is pretty good [01:01:31 CEST] <JEEB> at this point [01:05:30 CEST] <thebombzen> would it make sense to set the default encoder for nut to be flac internal rather than libvorbis? [01:05:47 CEST] <thebombzen> currently the order is libvorbis -> libmp3lame -> mp2 [01:16:14 CEST] <thebombzen> jkqxz: I just sent a patch to the mailing list. I also had to change the fate tests, because they do not specify the codec so the output files changed. [01:28:04 CEST] <cone-906> ffmpeg 03Derek Buitenhuis 07master:77c23704c769: avcodec: Mark some codecs with threadsafe init as such [01:28:05 CEST] <cone-906> ffmpeg 03James Almer 07master:d96363cc8437: Merge commit '77c23704c769168e4210956314775a1931f6aa0b' [01:30:05 CEST] <cone-906> ffmpeg 03Timo Rothenpieler 07master:a52976c0feab: nvenc: make gpu indices independent of supported capabilities [01:30:06 CEST] <cone-906> ffmpeg 03James Almer 07master:91feb62b3dbf: Merge commit 'a52976c0feab6e86138983c248bd01fa45cdda69' [01:32:23 CEST] <cone-906> ffmpeg 03Martin Storsjö 07master:bc2589763042: utvideodec: Add a missing include [01:32:24 CEST] <cone-906> ffmpeg 03James Almer 07master:09b1a9d74038: Merge commit 'bc2589763042dc2384b724b203ec778f35bcebad' [01:34:48 CEST] <cone-906> ffmpeg 03Luca Barbato 07master:b6093e8c72a8: hlsenc: Correctly write down all 16 bytes in hex [01:34:49 CEST] <cone-906> ffmpeg 03James Almer 07master:9cf1376aadcd: Merge commit 'b6093e8c72a80710f086c678ab0730cf30953b5c' [01:36:07 CEST] <cone-906> ffmpeg 03Vittorio Giovara 07master:ce6d72d10776: imgutils: Document av_image_get_buffer_size() [01:36:08 CEST] <cone-906> ffmpeg 03James Almer 07master:1a115a31d430: Merge commit 'ce6d72d10776b03c6780d4aa676414ce002285d4' [01:42:22 CEST] <rcombs> isn't the AC-3 encoder hot garbage [01:42:42 CEST] <JEEB> supposedly it's based on one of the other OSS ac3 encoders [01:42:58 CEST] <JEEB> so it's top tier OSS quality, IIRC. no idea how it compares against non-OSS encoders [01:43:01 CEST] <JEEB> lol [01:44:00 CEST] <rcombs> or to things that aren't AC3 [01:44:21 CEST] <JEEB> I kind of expected one to actually somehow need AC3 if it came up [01:44:37 CEST] <rcombs> well it's the default for matroska if libvorbis isn't available apparently [01:44:54 CEST] <JEEB> top keks [01:47:29 CEST] <cone-906> ffmpeg 03Vittorio Giovara 07master:53ea595eec98: mov: Rework stsc index validation [01:47:30 CEST] <cone-906> ffmpeg 03James Almer 07master:b35f6d3aa359: Merge commit '53ea595eec984e3109310e8bb7ff4b5786d91057' [01:50:12 CEST] <iive> JEEB: ffmpeg ac3 decoder is quite old. and I'm not even aware that there is another FOSS ac3 encoder [01:53:23 CEST] <cone-906> ffmpeg 03Martin Storsjö 07master:5e0c2158fbc7: aarch64: vp9mc: Simplify the extmla macro parameters [01:53:24 CEST] <cone-906> ffmpeg 03Martin Storsjö 07master:fea92a4b57d1: arm: vp9mc: Calculate less unused data in the 4 pixel wide horizontal filter [01:53:25 CEST] <cone-906> ffmpeg 03Martin Storsjö 07master:388e0d2515bc: aarch64: vp9mc: Calculate less unused data in the 4 pixel wide horizontal filter [01:53:26 CEST] <cone-906> ffmpeg 03Martin Storsjö 07master:a76bf8cf1277: arm: vp9itxfm: Optimize 16x16 and 32x32 idct dc by unrolling [01:53:27 CEST] <cone-906> ffmpeg 03Martin Storsjö 07master:3fcf788fbbcc: aarch64: vp9itxfm: Optimize 16x16 and 32x32 idct dc by unrolling [01:53:28 CEST] <cone-906> ffmpeg 03Martin Storsjö 07master:e1f9de86f454: arm/aarch64: vp9lpf: Calculate !hev directly [01:53:29 CEST] <cone-906> ffmpeg 03Martin Storsjö 07master:435cd7bc9967: arm: vp9lpf: Use orrs instead of orr+cmp [01:53:30 CEST] <cone-906> ffmpeg 03James Almer 07master:7f89e9621b9e: Merge commit '435cd7bc99671bf561193421a50ac6e9d63c4266' [01:56:58 CEST] <cone-906> ffmpeg 03Anton Khirnov 07master:99684f3ae752: avio: add a destructor for AVIOContext [01:56:59 CEST] <cone-906> ffmpeg 03Anton Khirnov 07master:6f554521afdf: Use the new AVIOContext destructor. [01:57:00 CEST] <cone-906> ffmpeg 03James Almer 07master:4ad0264ab3d4: Merge commit '6f554521afdf7ab4edbfaa9536660a1dca946b19' [02:01:01 CEST] <cone-906> ffmpeg 03Anton Khirnov 07master:5c8a5765dc5f: scale_npp: explicitly set the output frames context for passthrough mode [02:01:02 CEST] <cone-906> ffmpeg 03James Almer 07master:5256a86da067: Merge commit '5c8a5765dc5f4e29afb85b95be393c30f45412a8' [03:12:44 CEST] <ldts> wm4: it seems that I was handling correctly the end of stream and the only issue is that the driver I was using for testing was failing to interpret the new API (so the dummy buffer is not required); on my end all it will be needed is to remove the timeout...once I have a fixed version of the driver that allows me to test I will push the correction to the baseline. [03:14:50 CEST] <wm4> oh nice [03:31:25 CEST] <jamrial> wm4: do i keep the return value as size_t, or can i change it to int? seems stupid used size_t for a value that will be 32 max right now, 64 next year or so, and 128 in like five years [03:31:36 CEST] <jamrial> would the difference between the projects be too much of a headache? [03:35:35 CEST] <wm4> sigh, that issue again [03:35:58 CEST] <wm4> Libav seems hell-bent on introducing inconsistencies for a few decades until eventually everything is size_t [03:36:22 CEST] <wm4> I'd say just keep it size_t since as a return value it doesn't introduce too much confusion? [03:37:28 CEST] <jamrial> sure [03:38:01 CEST] <jamrial> and yes, the whole size_t thing is getting silly. used for things where it makes no sense [03:38:08 CEST] <atomnuker> well then don't use it [03:38:26 CEST] <atomnuker> I think BBB also objected to using special types for non-special variables [03:39:06 CEST] <atomnuker> e.g. uint8_ts always used for bools, etc., since the compiler may have to implicitly convert them to ints or whatever [03:39:55 CEST] <wm4> jamrial: they insist on using it "semantically" correct, so alignment would have to be size_t of course [03:49:47 CEST] <Ahti333> wm4 did you see my reply to your comment on my patch (http://ffmpeg.org/pipermail/ffmpeg-devel/2017-September/216885.html) i messed up the thread structure trying to reply manually [03:50:42 CEST] <wm4> Ahti333: thread appears fine here, and I didn't reply yet [03:51:19 CEST] <Ahti333> oh, weird, the archives show me replying to myself but whatever :D, take your time, thanks :) [03:52:38 CEST] <wm4> Ahti333: doing it in a way that prevents overriding chapters in "proper" file formats like it's done for apic sounds good to me [03:52:50 CEST] <wm4> Ahti333: do you think that would be hard to add? [03:56:19 CEST] <Ahti333> I'm not sure, I think it would require adjusting all the places ff_id3v2_read(_dict) is used (10~ places in the different fomat handlers). splitting up the code that reads the tags and storing it in the extra_meta itself should be relatively simple. [03:58:11 CEST] <wm4> Ahti333: you could also take a brief look at formats that support chapters (not many) and look whether id3-added chapters could make them crash/UB [03:58:19 CEST] <wm4> if not, your patch would be fine [04:15:48 CEST] <cone-906> ffmpeg 03Anton Khirnov 07master:e6bff23f1e11: cpu: add a function for querying maximum required data alignment [04:15:49 CEST] <cone-906> ffmpeg 03James Almer 07master:522f87708653: Merge commit 'e6bff23f1e11aefb16a2b5d6ee72bf7469c5a66e' [04:15:50 CEST] <cone-906> ffmpeg 03James Almer 07master:3b345d389be2: avutil/cpu: split flag checks per arch in av_cpu_max_align() [04:18:32 CEST] <Ahti333> wm4 I don't see anything that would cause a crash. if both the format and id3 contain chapter info, it would probably mess up the order and/or cause duplicate chapters in s->chapters [04:18:40 CEST] <cone-906> ffmpeg 03Anton Khirnov 07master:f44ec22e095c: lavc: use av_cpu_max_align() instead of hardcoding alignment requirements [04:18:41 CEST] <cone-906> ffmpeg 03James Almer 07master:24ee1b8c6343: Merge commit 'f44ec22e095c5ba00ffeadd891655c456e3dd014' [04:23:44 CEST] <Ahti333> (or if they don't contain identical info, some or all of the id3 info would be overwritten by the format chapters) [04:34:56 CEST] <cone-906> ffmpeg 03Anton Khirnov 07master:4de220d2e375: frame: allow align=0 (meaning automatic) for av_frame_get_buffer() [04:34:57 CEST] <cone-906> ffmpeg 03James Almer 07master:7aa6b8a68fce: Merge commit '4de220d2e3751c459f8739a08ac6ca52e63eba30' [04:37:08 CEST] <cone-906> ffmpeg 03wm4 07master:04f3bd349651: AVFrame: add an opaque_ref field [04:37:09 CEST] <cone-906> ffmpeg 03James Almer 07master:11f3a7ae108a: Merge commit '04f3bd349651694f30feeb8c4ed9bc58106fca54' [04:39:04 CEST] <cone-906> ffmpeg 03wm4 07master:c2f97f050870: hwcontext_dxva2: support D3D9Ex [04:39:05 CEST] <cone-906> ffmpeg 03James Almer 07master:596a4cbd0a1b: Merge commit 'c2f97f050870897575570708ac48c5c15e6a0dd8' [04:42:24 CEST] <cone-906> ffmpeg 03Luca Barbato 07master:0ee78020cd41: configure: Move up the avbuild directory creation [04:42:25 CEST] <cone-906> ffmpeg 03James Almer 07master:b02b43a823a6: Merge commit '0ee78020cd41d81eec651acd7fc65906207796f3' [04:50:57 CEST] <cone-906> ffmpeg 03Luca Barbato 07master:ba30b74686f0: aac: Validate the sbr sample rate before using the value [04:50:58 CEST] <cone-906> ffmpeg 03James Almer 07master:e9a388061371: Merge commit 'ba30b74686f0cb6c9dd465ac4820059c48bf9d08' [04:53:11 CEST] <cone-906> ffmpeg 03Luca Barbato 07master:9c2d36fcaf87: dv: Convert to the new bitstream reader [04:53:12 CEST] <cone-906> ffmpeg 03James Almer 07master:a1dcb057e3dc: Merge commit '9c2d36fcaf8748b9baa9aba9264abefce711d67b' [04:58:55 CEST] <cone-906> ffmpeg 03James Almer 07master:774295a3e01a: doc/libav-merge: mention skipped or incomplete runtime alignment commits [05:01:37 CEST] <cone-906> ffmpeg 03Martin Storsjö 07master:e18c39005ad1: arm: vp9lpf: Interleave the start of flat8in into the calculation above [05:01:38 CEST] <cone-906> ffmpeg 03Martin Storsjö 07master:b0806088d3b2: aarch64: vp9lpf: Interleave the start of flat8in into the calculation above [05:01:39 CEST] <cone-906> ffmpeg 03Martin Storsjö 07master:07b5136c481d: aarch64: vp9lpf: Fix broken indentation/vertical alignment [05:01:40 CEST] <cone-906> ffmpeg 03James Almer 07master:d987f9cfe370: Merge commit '07b5136c481d394992c7e951967df0cfbb346c0b' [05:05:10 CEST] <cone-906> ffmpeg 03Mark Thompson 07master:44f2eda39ff5: lavc: Add device context field to AVCodecContext [05:05:11 CEST] <cone-906> ffmpeg 03James Almer 07master:d7458ca8d7c8: Merge commit '44f2eda39ff55c69d4d739fb12a42a10b7ce581c' [05:06:28 CEST] <cone-906> ffmpeg 03Mark Thompson 07master:5dd9a4b88b28: vaapi: Implement device-only setup [05:06:29 CEST] <cone-906> ffmpeg 03James Almer 07master:752bc6b402ae: Merge commit '5dd9a4b88b287bf8c93520afda7becb1ad0d1894' [05:08:02 CEST] <cone-906> ffmpeg 03Mark Thompson 07master:e791b915c774: hwcontext_vaapi: Try to support the VDPAU wrapper [05:08:03 CEST] <cone-906> ffmpeg 03James Almer 07master:2838ab65ccf5: Merge commit 'e791b915c774408fbc0ec9e7270b021899e08ccc' [05:11:53 CEST] <cone-906> ffmpeg 03Luca Barbato 07master:b446f0e98f85: mov: Do not try to parse multiple stsd for the same track [05:11:54 CEST] <cone-906> ffmpeg 03James Almer 07master:d99c3af7072d: Merge commit 'b446f0e98f85e2e931b476e52b319f1c49244660' [05:14:14 CEST] <cone-906> ffmpeg 03Diego Biurrun 07master:871b4f365463: configure: Check for xcb as well as xcb-shape before enabling libxcb [05:14:15 CEST] <cone-906> ffmpeg 03James Almer 07master:e2a5fa11b2a2: Merge commit '871b4f3654636ed64560e86b9faa33828d195ceb' [05:41:49 CEST] <cone-906> ffmpeg 03Alexandra Hájková 07master:0539d84d985e: asfdec: Account for different Format Data sizes [05:41:50 CEST] <cone-906> ffmpeg 03James Almer 07master:42f27d1b8eab: Merge commit '0539d84d985e811e5989ef27c13f7e2dda0f9b89' [05:47:23 CEST] <cone-906> ffmpeg 03Martin Storsjö 07master:030de53e9cc2: libopenh264dec: Let the framework use the h264_mp4toannexb bitstream filter [05:47:24 CEST] <cone-906> ffmpeg 03James Almer 07master:e9b6212de29a: Merge commit '030de53e9cc225dc767458aedcc87efd457b4f3b' [05:50:21 CEST] <cone-906> ffmpeg 03James Almer 07master:93dfc4f174d8: avcodec/libopenh264dec: check for ff_set_dimensions() return value [05:52:58 CEST] <cone-906> ffmpeg 03Mark Thompson 07master:82989bd98c7f: avconv: Move rescale to stream timebase before monotonisation [05:52:59 CEST] <cone-906> ffmpeg 03James Almer 07master:e862a433d8e3: Merge commit '82989bd98c7f4e87f59af2147b645b8fd8f31c53' [05:54:29 CEST] <cone-906> ffmpeg 03Martin Storsjö 07master:8847eeaa1418: aarch64: Add parentheses around the offset parameter in movrel [05:54:30 CEST] <cone-906> ffmpeg 03James Almer 07master:d2ec2e27f819: Merge commit '8847eeaa141898850381400000fb2b8a7adc7100' [06:06:09 CEST] <cone-906> ffmpeg 03Diego Biurrun 07master:d00a0d8e84fe: configure: Handle SDL version check through pkg-config [06:06:10 CEST] <cone-906> ffmpeg 03James Almer 07master:47d6b02f6c3d: Merge commit 'd00a0d8e84fef1b9124bfaf71cc17df79ca464a6' [08:13:08 CEST] <FishPencil> I feel like there's a type in configure, should be "-lmfx" instead of it looking for liblibmfx https://github.com/FFmpeg/FFmpeg/blob/master/configure#L5948 [08:13:17 CEST] <FishPencil> s/type/typo [10:38:20 CEST] Action: JEEB does the annoying thing of the morning http://ffmpeg.org/pipermail/ffmpeg-devel/2017-September/216816.html , http://ffmpeg.org/pipermail/ffmpeg-devel/2017-September/216699.html [16:00:43 CEST] <jamrial> michaelni: what do you think of 8f5de34c8f? does it apply to us? [16:01:50 CEST] <jamrial> our code started to deviate with your commit bca59d7745e, followed by the merge commit aa40df483b2 [16:19:35 CEST] <jamrial> nicolas still thinking he can do whateve the fuck he wants... [16:20:03 CEST] <wm4> wew [16:20:13 CEST] <wm4> it's nice that he gives me arguments to easily [16:20:21 CEST] <wm4> I'll ignore his comments as well in the future [16:23:44 CEST] <JEEB> evening poke wrt http://ffmpeg.org/pipermail/ffmpeg-devel/2017-September/216816.html , http://ffmpeg.org/pipermail/ffmpeg-devel/2017-September/216699.html [16:24:27 CEST] <wm4> JEEB: just push them, nobody said no [16:24:40 CEST] <JEEB> E_NO_RIGHTS [16:24:54 CEST] <JEEB> (it's funny how people think I have :D) [16:26:02 CEST] <wm4> did you reject them? everybody and their dog have push rights [16:26:33 CEST] <wm4> otherwise talk to michaelni (who apparently still manages these things...) [16:26:57 CEST] <JEEB> I didn't reject them, just was never asked and I thought it was rude to ask for them :D [16:27:09 CEST] <JEEB> since most people seemed to get asked if they want them [16:27:09 CEST] <wm4> (I think you've been long enough active in multimedia open source that we can trust you) [16:29:51 CEST] <jamrial> wm4: to prevent an escalation of the situation with nicolas, send an email explaining why you're against the patch [16:32:01 CEST] <wm4> if he actually asks for clarification (which he could have done days ago), also I don't know why he wants to remove it, he doesn't state any reason, so it's hard to argue against it other than saying "nope" [16:33:14 CEST] <jamrial> he will not ask, so please, just send an email explaining why you're against it. don't give him arguments, no matter how small [16:33:51 CEST] <michaelni> jamrial, the fade commits are from 2013, but i think our fixes where complete and the problematic slice_h FFALIGN is also removed [16:34:08 CEST] <jamrial> michaelni: ok, will skip then. thanks [16:35:12 CEST] <michaelni> JEEB, are you in MAINTAINERs ? [16:40:49 CEST] <JEEB> michaelni: not that I remember [16:46:18 CEST] <jamrial> wm4: thanks [16:49:16 CEST] <jamrial> next time please do this from the get go. don't give nicolas reasons to start flamewars [16:51:07 CEST] <JEEB> michaelni: so regarding the patches. I added the docs so anything else you'd want from them? [16:51:16 CEST] <JEEB> second patch contains the FATE tests [16:52:20 CEST] <wm4> maybe next time nicolas could actually give reasons instead of blaming me for it [17:05:55 CEST] <michaelni> JEEB, ill look at the patches and ill apply them if i dont spot anything ... about maintainers, do you maintain anything or want to maintain anything ? [17:06:42 CEST] <michaelni> if yes, please send a patch to add yourself to MAINTAINERS [17:10:29 CEST] <JEEB> I'm not really stable regarding what I poke... http://git.videolan.org/?p=ffmpeg.git&a=search&h=HEAD&st=author&s=Jan+Ekstr… [17:10:47 CEST] <JEEB> (and then there's the backports that I post which are of course not by me) [17:12:03 CEST] <wm4> add yourself to "Developers with git write access who are currently not maintaining any specific part" [17:15:51 CEST] <JEEB> k [17:18:34 CEST] <wm4> I didn't know that adding git access was suddenly so public and formal, but I guess it's a good thing [17:21:48 CEST] <JEEB> yea [17:25:19 CEST] <kierank> wm4: https://www.thegazette.co.uk/notice/2311020 [17:25:21 CEST] <kierank> needs to be in there [17:25:23 CEST] <kierank> A PROCLAMATION [17:31:02 CEST] <wm4> wat [17:31:34 CEST] <kierank> that's how the queen gives a proclamation [17:32:05 CEST] <wm4> seems roundabout [17:55:37 CEST] <cone-230> ffmpeg 03Martin Storsjö 07master:8f5de34c8fb1: vf_fade: Make sure to not miss the last lines of a frame [17:55:37 CEST] <cone-230> ffmpeg 03James Almer 07master:e63e0b65446b: Merge commit '8f5de34c8fb18fa1416e77d2cb998773a49ddb3d' [18:08:36 CEST] <cone-230> ffmpeg 03Mark Thompson 07master:17aeee5832b9: vaapi_encode: Discard output buffer if picture submission fails [18:08:37 CEST] <cone-230> ffmpeg 03Mark Thompson 07master:2d518aec4c78: vf_deinterlace_vaapi: Create filter buffer after context [18:08:38 CEST] <cone-230> ffmpeg 03James Almer 07master:bf209013bff8: Merge commit '2d518aec4c781316092be65893b47922c8f71b67' [18:09:40 CEST] <jamrial> jkqxz: do we need 7cb9296db8 from libav? [18:11:20 CEST] <wm4> we had vaapi vp8 for a while in ffmpeg, so I guess not [18:11:58 CEST] <jkqxz> It's more fallout from the VP8 hwaccel which never got merged. Some people hated on that part of the patch and I wasn't really interested in pursuing it further. [18:13:02 CEST] <jamrial> it wasn't merged? [18:13:21 CEST] <jkqxz> wm4: There is no VP8 decode hwaccel in ffmpeg (there is encode). [18:13:25 CEST] <wm4> ah [18:13:59 CEST] <jamrial> what do i do then? and shouldn't that be merged at some point? [18:14:37 CEST] <jkqxz> It should. [18:14:52 CEST] <jkqxz> Skip the patch now, though. [18:16:30 CEST] <jamrial> ok, thanks [18:17:12 CEST] <cone-230> ffmpeg 03Martin Storsjö 07master:07e4be7ec94c: movenc: Add an option for enabling negative CTS offsets [18:17:13 CEST] <cone-230> ffmpeg 03Martin Storsjö 07master:5455a44aa507: movenc-test: Add tests for negative cts offsets [18:23:18 CEST] <cone-230> ffmpeg 03Mark Thompson 07master:7cb9296db872: webp: Fix alpha decoding [18:23:19 CEST] <cone-230> ffmpeg 03James Almer 07master:983705cf137b: Merge commit '7cb9296db872c4221453e5411f242ebcfca62664' [18:41:14 CEST] <cone-230> ffmpeg 03John Stebbins 07master:42cf7f91f1e9: dv: Don't return EIO upon EOF [18:41:15 CEST] <cone-230> ffmpeg 03James Almer 07master:6c9f44a3c2cc: Merge commit '42cf7f91f1e9dabf494ff469d8f67ac8b33b0f63' [18:43:24 CEST] <cone-230> ffmpeg 03Diego Biurrun 07master:00b160af117b: nvenc: Fix nvec vs. nvenc typo [18:43:25 CEST] <cone-230> ffmpeg 03James Almer 07master:1a4d2e8b4da7: Merge commit '00b160af117b782292619c98effce6c8273792e5' [18:47:40 CEST] <cone-230> ffmpeg 03Diego Biurrun 07master:54e39b102e29: configure: Explicitly spell out first require_pkg_config() parameter [18:47:41 CEST] <cone-230> ffmpeg 03James Almer 07master:00a61f30a05a: Merge commit '54e39b102e29adcc2f59f1eca85be5f86c89454b' [20:20:35 CEST] <BBB> jkqxz: what was the hate? [20:20:50 CEST] <atomnuker> webp [20:21:38 CEST] <BBB> . o O ( o m g ) [20:21:42 CEST] <BBB> ok [20:24:09 CEST] <nevcairiel> all i ever heard about AMF is how horrible it is, do people really want to use that [20:24:58 CEST] <nevcairiel> (also, the code has serious style issues just from the first sight) [20:25:32 CEST] <nevcairiel> also, its C++ api with vtbl madness [20:29:44 CEST] <wm4> seems like some sort of COM-made-portable like decklink (or whatever it was) [20:30:00 CEST] <jkqxz> Um, these ffmpeg things in AMF are wrappers for parts of ffmpeg? Sounds like a bad idea to include those bits... [20:30:58 CEST] <wm4> wut, so it's recursive? [20:31:01 CEST] <wm4> didn't look too closely [20:31:02 CEST] <JEEB> lol [20:31:16 CEST] <jkqxz> '#define FFMPEG_DLL_NAME L"amf-component-ffmpeg64.dll"' [20:31:37 CEST] <JEEB> ^_^ [20:32:25 CEST] <wm4> does it work on Linux at all? [20:33:45 CEST] <jkqxz> I think it's meant to, but it requires the crazy proprietary stack. [20:33:56 CEST] <jkqxz> (Which I have never run, so I can't confirm that.) [20:36:22 CEST] <Gramner> that amf patch sure is something [20:38:03 CEST] <jkqxz> "case $target_os in mingw32*|mingw64*|win32|win64|cygwin*) ;; *) disable amf ;; esac" - for this patch, no. [20:38:23 CEST] <nevcairiel> we have a similar thing for cuvid [20:39:43 CEST] <jkqxz> Batch file for testing, nice. [20:40:34 CEST] <jkqxz> There is D3D11 integration, that's nice. (Somewhere that libmfx falls over...) [20:50:25 CEST] <wm4> nevcairiel: I mentioned that in my reply [22:14:35 CEST] <cone-230> ffmpeg 03Gildas Fargeas 07master:cb8b729180cc: avdevice/decklink_dec: add support for more pixel formats [22:14:36 CEST] <cone-230> ffmpeg 03Karthick J 07master:e6cdf30fb44f: avdevice/decklink_dec: Added VANC search for all resolutions [22:14:37 CEST] <cone-230> ffmpeg 03Karthick J 07master:a8755785d7a9: avdevice/decklink_dec: Extraction of luma from V210 VANC modularized [22:14:38 CEST] <cone-230> ffmpeg 03Karthick J 07master:b6cf66ae1c49: avdevice/decklink_dec: Added Closed caption decode from VANC [22:14:39 CEST] <cone-230> ffmpeg 03Karthick J 07master:f7b7d51a37dd: avcodec/decode: Pass on the Closed Captions Side Data [23:33:06 CEST] <BtbN> this AMF patchset [23:34:27 CEST] <atomnuker> yeah [23:34:34 CEST] <atomnuker> don't they expose those with vaapi? [23:36:04 CEST] <BtbN> Isn't AMF Windows-Only? [23:37:06 CEST] <wm4> on Windows you can just use MediaFoundation [23:37:31 CEST] <BtbN> does ffmpeg support hw encoding using media foundation? [23:37:48 CEST] <cone-230> ffmpeg 03Diego Biurrun 07master:7208e5b5d638: configure: Restructure the way check_pkg_config() operates [23:37:49 CEST] <cone-230> ffmpeg 03James Almer 07master:d81b34069e80: Merge commit '7208e5b5d638d4b9c2784036b4fc5728f32233c7' [23:37:51 CEST] <wm4> I have a patch [23:38:10 CEST] <BtbN> I'd guess using AMF gives you more control? [23:38:42 CEST] <wm4> as a vendor specific API, most likely? [23:38:57 CEST] <BtbN> as generic media foundation [23:41:52 CEST] <cone-230> ffmpeg 03Rostislav Pehlivanov 07master:05dfa21d47f3: opus_pvq: make max_den a float [23:43:40 CEST] <rcombs> jkqxz: thoughts on the new VAAPI FEI thing? [23:44:37 CEST] <wm4> jkqxz: while we're at it, does this include the magic that would make radeon GL mapping work? [23:44:47 CEST] <jkqxz> Maybe usable to do stuff like lookahead. Otherwise mostly only useful for people who want weird shit. [23:45:06 CEST] <rcombs> mmm, that's what I was hoping [23:45:06 CEST] <jkqxz> I'm just finishing that off now. [23:47:21 CEST] <jkqxz> I suppose you mind if the mpv patch doesn't work with libva < 2? [23:48:36 CEST] <cone-230> ffmpeg 03Pablo Montilla 07master:1015982f45d8: lavf/mov: Allow reading very large files. [23:49:58 CEST] <wm4> jkqxz: you could just duplicate the implementation as another hwdec_ file [23:50:43 CEST] <wm4> libva<2 will probably stay around for a longer time [00:00:00 CEST] --- Fri Sep 29 2017

1 0

ffmpeg.log.20170928
by burek 29 Sep '17

29 Sep '17

[00:28:35 CEST] <Hopper_> BtbN: Thanks, so I would have C/read.txt and d/read.txt, and I delete C/read.txt then move d/read.txt to /? [00:28:42 CEST] <Hopper_> c/ [00:50:13 CEST] <kepstin> Hopper_: what os? [01:08:45 CEST] <Hopper_> kepstin: w10 [01:26:51 CEST] <relaxed> Hopper_: if you know the timing, maybe ass subs are the way to go [01:27:23 CEST] <Hopper_> What timing? [01:29:38 CEST] <relaxed> if you know beforehand when the text should change, you can orchestrate it using ass subs [01:29:57 CEST] <relaxed> based on timestamps of the video [01:30:55 CEST] <Hopper_> No, it is a live stream, and there is a serial input creating data that I want overlayed on the video. [01:31:08 CEST] <relaxed> ok [01:31:58 CEST] <Hopper_> relaxed: So stop looking into ASS Subs? [01:33:03 CEST] <relaxed> indeed. maybe write a script that backgrounds ffmpeg and send text to the drawtext file [01:33:25 CEST] <JEEB> for dynamic live stuff maybe casparcg or something? [01:33:32 CEST] <JEEB> used in norwegian public broadcasting, IIRC [01:33:37 CEST] <JEEB> for overlays etc [01:34:17 CEST] <Hopper_> JEEB: Thanks, looking at it now. [01:34:19 CEST] <relaxed> only JEEB will break out norwegian public broadcasting [01:34:49 CEST] <JEEB> well it's pretty obvious this person will not want to write his own app to dynamically create overlays [01:34:59 CEST] <JEEB> and the one thing I know that seems to be working for live stuff is casparcg [01:35:03 CEST] <JEEB> overkill? maybe [01:35:13 CEST] <Hopper_> JEEB: Give me some credit here! [01:35:35 CEST] <JEEB> :D [01:35:43 CEST] <Hopper_> casparcg seems to have too high of system requirements. [01:35:53 CEST] <furq> this seems like a good opportunity for sendcmd [01:35:57 CEST] <furq> if only anyone actually knew how to use it [01:36:01 CEST] <JEEB> lol [01:36:10 CEST] <relaxed> JEEB: no, I just find you're uncanny experience funny [01:36:18 CEST] <relaxed> your! [01:36:34 CEST] <Hopper_> My plan is to have a python program generate a .txt file of the most recent complete serial data, and have ffmpg just keep using that file so it will display all updated info. [01:36:47 CEST] <JEEB> ffmpeg.c is scary [01:36:52 CEST] <JEEB> so much can be done with it [01:36:56 CEST] <JEEB> until it is no longer possible :3 [01:37:16 CEST] <JEEB> as in, you suddenly hit a brick wall because of design of ffmpeg.c or so [01:37:51 CEST] <JEEB> (and yes, I've done the mistake myself as well at times where I've based something on ffmpeg.c and then extending that becomes not-really-possible easily) [01:38:00 CEST] <JEEB> (and then it's API client writing time) [01:38:11 CEST] <JEEB> fun times dot jaypeg [01:39:14 CEST] <Hopper_> JEEB, relaxed: Think I can do what I'm planning on? [01:39:33 CEST] <JEEB> API-wise yes [01:39:37 CEST] <JEEB> ffmpeg.c, no idea [01:39:46 CEST] <furq> that should work fine with drawtext [01:39:51 CEST] <relaxed> scripting, yes [01:40:33 CEST] <furq> write a line to tmpfile.NamedTemporaryFile and then move it to the path you gave ffmpeg [01:40:41 CEST] <furq> as long as they're on the same fs that should be fine [01:41:02 CEST] <JEEB> rename() magick [01:41:03 CEST] <Hopper_> And if ffmpeg can't find it, will it just ditch the text for that frame, or stop functioning completely? [01:41:28 CEST] <furq> no idea [01:41:34 CEST] <furq> but it should always be able to find it [01:41:36 CEST] <relaxed> just cat text to a file [01:42:17 CEST] <relaxed> echo "new text" > drawtext.txt [01:42:18 CEST] <furq> yeah python is overkill if you're not already using it [01:42:28 CEST] <furq> also don't do that. that will break [01:42:38 CEST] Action: relaxed stabs furq [01:42:44 CEST] <relaxed> will it? [01:42:50 CEST] <furq> yeah you need to write to a temp file and do an atomic replace [01:43:16 CEST] <Hopper_> If not python, what would you suggest? [01:43:19 CEST] <relaxed> that's no fun [01:43:50 CEST] <furq> so more like tmp=$(mktemp); cat "foo" > $tmp; mv $tmp $drawtext [01:44:07 CEST] <furq> but if you're on windows it's probably less hassle to just use python [01:44:40 CEST] <relaxed> or awk [01:45:01 CEST] <Hopper_> This build is on windows. [01:45:34 CEST] <furq> i assume if it's windows you'll need something to read from serial as well [01:45:46 CEST] <Hopper_> Ya, that's why I was going to use python. [01:45:53 CEST] <furq> right [01:45:58 CEST] <Hopper_> It can do everything with the same program. [01:46:06 CEST] <furq> well yeah just do the thing i just said except in python [01:46:24 CEST] <furq> python has tempfile.mkstemp and stuff [01:46:45 CEST] <Hopper_> That bit is beyond me, have a link? [01:47:43 CEST] <relaxed> what is coming off serial? [01:48:14 CEST] <Hopper_> a string that will end up being a CSV. [01:48:39 CEST] <relaxed> just curious, can you be more specific? [01:49:07 CEST] <furq> https://docs.python.org/2/library/tempfile.html [01:49:12 CEST] <Hopper_> Sure, this is an airborne device that will be logging the data, but also sending the data over a live video stream. [01:49:15 CEST] <Hopper_> furq: Thanks [01:49:25 CEST] <relaxed> a drone? [01:49:41 CEST] <Hopper_> I shouldn't get into it. [01:50:09 CEST] <Hopper_> But when the project it live, you will all be able to see the result, I'll post it. [01:50:17 CEST] <relaxed> we need to go back in time and take out Hopper_ [01:56:03 CEST] <Hopper_> Okay, well tomorrow we will get started on updating text overlays in FFMPEG. [01:57:55 CEST] <relaxed> I look forward to the results [03:42:00 CEST] <acos> Sup all [04:30:42 CEST] <Ch3ck> I want to demux a decoded data stream [04:33:39 CEST] <Ch3ck> Using the ffmpeg binary I run this this command "ffmpeg -i -ar 44100 -ac 2 -ab -f mp3 out.mp3 < data_stream" [04:35:10 CEST] <Ch3ck> Which libraries do I look at for this? [04:35:37 CEST] <furq> i'm not really sure what you're asking, but that command won't demux, it'll reencode [04:35:43 CEST] <furq> once it's fixed, anyway [04:36:01 CEST] <Ch3ck> I want to implement this in Go using cgo [04:36:09 CEST] <Ch3ck> I don't want to call ffmpeg directly in the code [04:36:25 CEST] <furq> you want libavformat then [04:36:44 CEST] <Ch3ck> I wish to know which functions to look at in there [04:36:52 CEST] <Ch3ck> furq, do you have a sample command [04:36:59 CEST] <furq> for ffmpeg? [04:37:05 CEST] <furq> it depends what data_stream is [04:37:07 CEST] <Ch3ck> using libavformat [04:37:15 CEST] <Ch3ck> it's a map [04:37:20 CEST] <Ch3ck> map of strings [04:37:49 CEST] <furq> ?? [04:38:12 CEST] <furq> that doesn't sound like something ffmpeg can demux [04:38:38 CEST] <Ch3ck> furq i wish to convert this decoded byte stream to mp3 [04:38:53 CEST] <Ch3ck> I was thinking of using this: https://github.com/Ch3ck/goav [04:39:44 CEST] <furq> https://github.com/viert/lame [04:39:48 CEST] <furq> if you literally just want an mp3 [04:40:07 CEST] <furq> the ffmpeg libs are massive and bindings to them are usually outdated, incomplete or both [04:40:36 CEST] <Ch3ck> furq, thanks for the link \ [04:41:14 CEST] <Ch3ck> It'll help me greatly [05:24:15 CEST] <shank> Hello, I'm trying to install ffmpeg on a mac and I get the "yasm/nasm not found or too old" error. I have the latest nasm version installed. Is there anythign else I should try? [05:25:06 CEST] <shank> change.log has the following output [05:25:08 CEST] <shank> asm: fatal: unrecognised output format `macho64' - use -hf for a list type `nasm -h' for help yasm/nasm not found or too old. Use --disable-yasm for a crippled build. [05:28:11 CEST] <Ch3ck> furq, I can't seem to find libmp3lame0 [05:28:25 CEST] <Ch3ck> Any ideas where I can find it? [06:58:26 CEST] <andrsussa> hello, I am trying to pipe input data from another program into ffmpeg, is there anything I should take into account if that data I'm piping is a mp4 file? [15:40:05 CEST] <zort> https://slexy.org/view/s2w0hAtEPA ffmpeg is telling me "Unsafe file name", so I added "-safe 0" as they say to do, but it says "Option safe not found." [15:42:49 CEST] <fx1592345> Hey, I'm encoding video from my webcam into vp8 / webm and the stream it via http into my own nodejs application which then takes the chunks and sends them to a browser over a websocket, my problem is: when the browser first connects to the websocket and then the encoding is started everything works, when first starting encoding and then opening the websocket the video in the browser never starts? [15:43:50 CEST] <fx1592345> I'm already taking the first chunk/cluster with the header/information of the webm and cache it in my nodejs application which sends it out on a new ws connection as first packet, so the client theoretically should know how to decode following chunks? [15:45:03 CEST] <fx1592345> Restarting ffmpeg on an open connection results in a working video, I can see ffmpeg retransmits the header in wireshark and then normal webm clusters follow [16:08:47 CEST] <chuckleplant> Hi guys, if the SPS info in my H264 stream does not contain timing_info... how does ffmpeg obtain the time_scale? I'm trying to do the same with my H264 parser for an IP camera [16:13:54 CEST] <Mavrik> chuckleplant, well, that's essentially an external information that comes from the source that grabbed it [16:14:02 CEST] <Mavrik> Your frames need to have timestamps [16:14:07 CEST] <Mavrik> And by that they imply timebase as well [16:14:40 CEST] <chuckleplant> Mavrik, could you please elaborate on what the source that grabbed it is? [16:14:47 CEST] <Mavrik> in your case, IP camera. [16:14:56 CEST] <Mavrik> Your IP camera is sending frames with timestamps [16:15:03 CEST] <Mavrik> and they need some kind of timebase just by existing :) [16:15:38 CEST] <chuckleplant> Yes, I do get timestamps, but the time_base of the codecContext is not set [16:15:55 CEST] <chuckleplant> As far as I know, this value is set via the extradata info, in which I feed the SPS / PPS header [16:16:03 CEST] <Mavrik> well, you need to set it to the time_base your camera uses then. [16:16:15 CEST] <Mavrik> I don't know what kind of protocol are you using [16:16:23 CEST] <chuckleplant> RTSP RTP H264 [16:16:24 CEST] <Mavrik> But if timebase isn't set, you'll have to set it to fit whatever your camera is sending [16:17:28 CEST] <chuckleplant> I've also tried setting timebase manually, but even in that case I don't know the framerate and I don't get timestamps in my decoded AVFrames [16:36:51 CEST] <zort> solved my "unsafe file name" problem by using relative paths instead of absolute [17:07:21 CEST] <chuckleplant> On playback synchronization of H264 streams... As I'm using RTP, I found that: "The RTP timestamp is set to the sampling timestamp of the content. [17:07:22 CEST] <chuckleplant> A 90 kHz clock rate MUST be used" [17:07:48 CEST] <chuckleplant> So, my time_base must be 1/90000, which matches what ffprobe was telling me [17:07:57 CEST] <titbang> you need to set it to 60Hz [17:08:15 CEST] <chuckleplant> titbang, why? [17:08:54 CEST] <chuckleplant> I got that from the RTP payload spec: https://tools.ietf.org/html/rfc6184 [17:25:02 CEST] <iive> chuckleplant: i think he is just trolling you [17:26:30 CEST] <chuckleplant> iive, thanks... anyways, I'll sent my doubts to the mailing list [17:27:19 CEST] <iive> the timebase is usually the reverse of the fps, so 60 is ok if you are with 60fps [17:27:31 CEST] <iive> howeve 90kHz is what mpeg-ts is using [17:27:57 CEST] <iive> there is mode that extends it to 27MHz [17:28:29 CEST] <acos> Haha trolling on the internet. [17:42:26 CEST] <Loriker> 90kHz is used for RTP when encapsulating MPEG-TS [17:42:59 CEST] <Loriker> 27 MHz is used in MPEG-TS [17:43:31 CEST] <Loriker> no 60 Hz [17:45:36 CEST] <bencoh> actually depends on what you're referring to, but PCR is 27mhz-based, yes [17:57:47 CEST] <Loriker> exactly [18:48:31 CEST] <Ch3ck> furq: I have some quick issues with lame [18:51:05 CEST] <Ch3ck> When I take a json response body and pass to the lame writer and encode with the required input and stuff the output I get is white noise [18:51:40 CEST] <Ch3ck> I can't actually listen to the read sound waves. I don't know if there's something I might be doing wrong [23:55:50 CEST] <SpeakerToMeat> Hello good people. [23:56:27 CEST] <SpeakerToMeat> Question, if I have an audio file that has 12 channels, but I want to treat the first 6 as 5.1 for using the "-ac 2" automatix 5.1 -> stereo downmixer, is there any way to do so? [23:57:40 CEST] <JEEB> if you're going to be remapping the audio anyways you might as well do the to-stereo thing in the same af [23:58:28 CEST] <SpeakerToMeat> Hmmm yeah I could use mapping, but then I need to specify the value of each channel or can I use the built in mapper in a map chain? [23:58:42 CEST] <SpeakerToMeat> af chain not map chain [00:00:00 CEST] --- Fri Sep 29 2017

1 0

ffmpeg-devel.log.20170927
by burek 28 Sep '17

28 Sep '17

[00:03:06 CEST] <horox> test file: http://openartist.org/magiclantern/10bit.MLV [00:03:16 CEST] <michaelni> jamrial, 740e557d6eac3b579dfed53ed92ae70e2089c77c breaks build with shared libs [00:03:38 CEST] <michaelni> libavfilter/libavfilter.so: undefined reference to `FcPatternAddString' [00:06:31 CEST] <jamrial> michaelni: should i revert? i thought adding a _suggest for an external lib seemed odd [00:09:06 CEST] <jamrial> i'm going to revert. the change is pointless anyway [00:10:34 CEST] <michaelni> jamrial, sure, it looked odd to me too, i just didnt reply as i havnt tested yet if it works with it revretd bt at least build works [00:11:51 CEST] <cone-080> ffmpeg 03James Almer 07master:8f2ab1806352: Revert "Merge commit '66988320794a107f2a460eaa71dbd9fab8056842'" [00:11:58 CEST] <jamrial> michaelni: done, thanks for pointing it out [00:17:44 CEST] <cone-080> ffmpeg 03Martin Storsjö 07master:3bc5b28d5a19: arm: vp9itxfm: Avoid .irp when it doesn't save any lines [00:17:45 CEST] <cone-080> ffmpeg 03Martin Storsjö 07master:58d87e0f49bc: aarch64: vp9itxfm: Restructure the idct32 store macros [00:17:46 CEST] <cone-080> ffmpeg 03James Almer 07master:0c224ce231c8: Merge commit '58d87e0f49bcbbc6f426328f53b657bae7430cd2' [00:19:55 CEST] <cone-080> ffmpeg 03Alexandra Hájková 07master:f7ec7f546f00: wma: Convert to the new bitstream reader [00:19:56 CEST] <cone-080> ffmpeg 03James Almer 07master:0e56321aef0b: Merge commit 'f7ec7f546f0021d28da284b024416b916b61c974' [06:17:31 CEST] <Ahti333> wm4 i replied to your mail on ffmpeg-devel, but couldn't get the headers right (i posted the patch without being subscribed initially): http://ffmpeg.org/pipermail/ffmpeg-devel/2017-September/216885.html [08:21:13 CEST] <LongChair> jkqxz: sorry for the lag, yeah those changes look fine, feel free to squash, and push :) [08:22:44 CEST] <kurosu> I feel the consensus on the bitstream cache is libav version will not be merged [08:23:12 CEST] <kurosu> For sake of not changing *all the things* [08:23:59 CEST] <kurosu> But I somewhat prefer libav version [08:24:35 CEST] <kurosu> Maybe legacy one will lend itself better to combining with a 32b version [08:26:01 CEST] <kurosu> That cache mostly affects high bitrate codecs, ie mostly lossless or near [08:27:36 CEST] <kurosu> So, not a real need (otherwise someone would have committed the time) [08:47:18 CEST] <nevcairiel> paul send patches for optionally adding a cache to our reader, but it still had soem conflicts that were not resolved yet, iirc [10:29:43 CEST] <ubitux> so we're going to add another VT hwaccel instead of a proper decoder? [10:30:04 CEST] <ubitux> VT as hwaccel is close to pointless [10:30:13 CEST] <ubitux> the performances are way below what we can expect [10:33:24 CEST] <ubitux> tmm1: ^ [10:33:37 CEST] <nevcairiel> i dont see anyone submitting a better solution to the ML [10:34:21 CEST] <ubitux> a decoder with basic reordering is way better in practice [10:34:35 CEST] <nevcairiel> besides the code to support hevc in the VT code we already have seems pretty simple [10:34:47 CEST] <ubitux> it's day and night wrt speed since you can enable async [10:35:26 CEST] <ubitux> and you can't reach real time with some footage if you don't enable it [10:35:52 CEST] <nevcairiel> (also, hwaccels have many other advantages, you automatically get the full sei/metadata handling from the software decoders, which full hardware decoders generally *always* lack) [14:15:47 CEST] <Chloe> How can we remove the sdl2, opengl and caca output devices? libavdevice doesnt need visual output devices which serve no purpose other than having multiple things which do the same thing. The SDL2 and opengl output devices are covered by the functionally in ffplay, and caca is just... well, caca--does anyone actually use it apart from just testing it for the lulz [14:18:48 CEST] <JEEB> second call for comments on back-ports http://ffmpeg.org/pipermail/ffmpeg-devel/2017-September/216816.html , http://ffmpeg.org/pipermail/ffmpeg-devel/2017-September/216699.html [14:23:21 CEST] <wm4> Chloe: deprecate, remove [14:30:57 CEST] <Chloe> wm4: I guess a av_log in the header function of each device is good enough to 'deprecate' them? [14:36:24 CEST] <wm4> Chloe: hm probably yes [14:36:41 CEST] <wm4> not familiar with how "devices" get deprecated [14:37:51 CEST] <Chloe> in my experience they dont [14:38:02 CEST] <Chloe> gonna change that though [14:38:12 CEST] <Chloe> I reckon it's good enough just to print out a warning [15:23:24 CEST] <Chloe> Mmh i missed the xv device [15:23:46 CEST] <Chloe> I guess I can add it after I get a response [15:51:46 CEST] <wm4> I'm always amazed by how much people like trash [15:52:30 CEST] <durandal_1707> lavd is not trash, its just bad design [16:16:40 CEST] <cone-906> ffmpeg 03Tobias Rapp 07master:f102a4efcef3: avfilter/f_metadata: avoid trailing whitespace in filter output [16:16:41 CEST] <cone-906> ffmpeg 03Tobias Rapp 07master:bee01ee2ba2e: fate: add tests for psnr and ssim filter [17:00:23 CEST] <Chloe> durandal_1707: yes, and output devices dont fit in [17:00:33 CEST] <Chloe> Lavd needs a rethink entirely [17:00:45 CEST] <Chloe> Removing bullshit outdevs is the first step [17:04:18 CEST] <Chloe> durandal_1707: what's 'NAK' mean? [17:04:40 CEST] <mateo`> Not Ack -> Not ok [17:07:26 CEST] <Chloe> Right so what do you want changed [17:12:53 CEST] <wm4> "please add a new API and rewrite everything" [17:46:18 CEST] <cone-906> ffmpeg 03Diego Biurrun 07master:0ce3761c781f: configure: Add stdlib.h #include to CPPFLAGS check helper functions [17:46:19 CEST] <cone-906> ffmpeg 03Diego Biurrun 07master:71a49fe25f2e: configure: Use cppflags check helper functions where appropriate [17:46:20 CEST] <cone-906> ffmpeg 03James Almer 07master:407a7547dad5: Merge commit '0ce3761c781f2c2de40a5a8a99563878804f47cc' [17:46:21 CEST] <cone-906> ffmpeg 03James Almer 07master:e00e8639b22a: Merge commit '71a49fe25f2e4468fbbadbebef8d073b1b3cc1a5' [17:48:17 CEST] <cone-906> ffmpeg 03Diego Biurrun 07master:a25dac976a44: Use bitstream_init8() where appropriate [17:48:18 CEST] <cone-906> ffmpeg 03James Almer 07master:79ebf1e19b9e: Merge commit 'a25dac976a4478331e4db86d44c3db4456c93eff' [18:09:00 CEST] <cone-906> ffmpeg 03Josh de Kock 07master:56d2154b72fb: lavd: remove deprecated dv1394 device [18:26:08 CEST] <ubitux> wm4: in the end, i just copied avframe stuff, and it seems to be enough; https://github.com/ubitux/FFmpeg/compare/export-udta [18:26:17 CEST] <ubitux> i haven't handled the side data format transfer yet though [18:26:57 CEST] <wm4> please no [18:27:06 CEST] <wm4> not another half-assed copy of the side data code [18:27:14 CEST] <ubitux> ? [18:27:29 CEST] <wm4> we had so much issues with this and there's no end in sight, and your addition adds another set of duplicated functions [18:28:21 CEST] <ubitux> there are abi issues if i "factor them all" [18:28:31 CEST] <ubitux> they lie in different libraries [18:29:06 CEST] <wm4> you don't have to replace the existing code... that's obviously much harder [18:29:55 CEST] <ubitux> then i'm not sure what you are asking me to do [18:30:08 CEST] <ubitux> what's half assed here? [18:31:48 CEST] <BBB> didnt we have a native daala decoder submitted at some point? [18:31:52 CEST] <BBB> or am I misremembering? [18:32:29 CEST] <BBB> yes; [RFC 1/3] daaladec: Implement a native Daala decoder [18:32:35 CEST] <BBB> atomnuker: why isnt that in? :-p [18:32:54 CEST] <jamrial> because it's obsolete by now? :p [18:33:03 CEST] <wm4> ubitux: I hoped you'd add a generic side data list struct or so, which could be used in the future for other cases where we need side data, or to replace the existing side data mess eventually [18:33:05 CEST] <BBB> omg the Q&A in that patchset is amazing (in 20/20 hindsight) [18:33:07 CEST] <BBB> Q: What about AOMedia and the IETF? [18:33:08 CEST] <BBB> A: There's a (high) chance that the current libdaala codebase will be [18:33:09 CEST] <BBB> used, and thus this decoder will continue tracking whatever becomes [18:33:09 CEST] <BBB> of libdaala. [18:33:18 CEST] <BBB> (side note: they did not use libdaala :-p) [18:33:32 CEST] <wm4> ubitux: in that aspect duplicating the side data stuff yet again is half-assed :) [18:33:39 CEST] <BBB> Q: What if libdaala dies and AOMedia/IETF come up with something [18:33:40 CEST] <BBB> completely different (unlikely). [18:33:40 CEST] <BBB> A: This decoder will continue tracking whatever they come up with [..] [18:33:49 CEST] <BBB> atomnuker: so did you continue tracking? [18:35:41 CEST] <ubitux> wm4: so you want yet another implementation of side data? [18:35:55 CEST] <wm4> ubitux: yes, but this time a reusable one [18:36:00 CEST] <wm4> think AVSideDataList [18:36:19 CEST] <wm4> and AVFormatContext would have a "AVSideDataList *side_data;" field [18:37:27 CEST] <ubitux> ok [18:38:04 CEST] <atomnuker> BBB: nope, the used the libvpx codebase because no one had strong feelings about which codebase to use except hardware guys who thought it would be quicker since its more complete [18:38:14 CEST] <atomnuker> hindsight is always 20/20, no? [18:38:29 CEST] <BBB> of course, but its fun to go back in time and look at what we said back then ;) [18:38:49 CEST] <atomnuker> or didn't say in this case [18:38:57 CEST] <BBB> yeah [18:39:22 CEST] <wm4> jamrial: do you have an idea how such a new generic side data API should handle side data element sizes? [18:40:48 CEST] <jamrial> is the way the existing packet/frame side data does it inadequate? [18:41:39 CEST] <wm4> it's pretty roundabout [18:41:47 CEST] <wm4> and most side data types have only 1 size [18:42:10 CEST] <wm4> but I'm worried that the side data impl doesn't always have the side data element structs available [18:42:30 CEST] <wm4> because the impl. is in libavutil, and various side data could be defined in the other libs [18:43:14 CEST] <wm4> we could do the following: 1. require all side data type structs to be defined in libavutil, 2. have the side data impl. know about _all_ of them [18:43:34 CEST] <wm4> so the side data allocator could be part of the side data impl. [19:30:45 CEST] <ldts> wm4: hi [19:31:49 CEST] <ldts> wm4: can you hold v2 of the patch that I just sent please? I talked to the venus developer and a dummy size of 0 on the buffer should not be used (the kernel will raise a warning which I didnt notice since I didnt have my console enabled); apparetly the driver needs to be fixed [19:32:16 CEST] <ldts> wm4: will send v3 properly fixed now [19:32:45 CEST] <wm4> k [19:33:15 CEST] <wm4> I'm amazed that this requires discussion with a developer of a certain codec - shouldn't this be part of the kernel API/ABI instead? [19:41:52 CEST] <ldts> wm4: the v4l2 core changed recently ; it used to accept null size as an eos [19:42:30 CEST] <ldts> wm4: then it changed to the flag and it raises a warning on the console when size 0 is used to let the driver developer know that such a driver should be fixed [19:43:39 CEST] <ldts> wm4: this means that the data in the buffer carrying the flag should be valid if possible (not an issue if it is not...so bytesize=1 is what most people use) [19:44:34 CEST] <ldts> wm4: which leads to my question, is there any way in ffmpeg to identify the last frame from the stream with valid data? then I wont have to send a dummy buffer... [19:44:58 CEST] <wm4> no, unless you buffer a packet to see whether EOF will come [19:45:35 CEST] <wm4> what would a buffer with bytesize=1 contain? [19:46:06 CEST] <ldts> wm4: it would contain nothing, no real data [19:46:36 CEST] <ldts> wm4: just works around the kernel warning when 0 is used (I dont like doing it) [19:46:39 CEST] <wm4> so maybe a (uint8_t)0? [19:47:24 CEST] <ldts> wm4: as data? [19:48:48 CEST] <wm4> I mean as buffer contents [19:49:20 CEST] <cone-906> ffmpeg 03Carl Eugen Hoyos 07master:dc522cfa0789: lavf/version: Bump minor after dv1394 removal. [19:49:20 CEST] <wm4> it's 1 byte, but what is the value of that byte? [19:52:02 CEST] <ldts> wm4: I guess it can be anything - testing on my end it doesnt make any difference; I think the cleanest as you said is to buffer the input data and set the flag properly on the last valid buffer. [19:52:45 CEST] <ldts> wm4: however that will not work on drivers not using the flag.... [19:53:25 CEST] <ldts> wm4: but I think ffmpeg should just follow the API and those drivers that fail should be updated. [19:55:24 CEST] <wm4> my guess would be that the drivers try to parse any input as Annex B data [19:55:37 CEST] <wm4> anyway, I don't understand why bytesize=0 is not accepted [19:56:54 CEST] <ldts> wm4: it is accepted but the v4l2 kernel maintainers want to move away from it so you get a nasty warning in the console [19:56:57 CEST] <ldts> https://hastebin.com/qomonitacu.xml [19:57:51 CEST] <wm4> why do they want to move away from it? [19:59:32 CEST] <ldts> ldts: I believe it is the thought of having a dummy buffer pushed to the driver to indicate EOS...makes sense to me as well - it seems wrong [20:00:08 CEST] <ldts> wm4: it makes much more sense that the last buffer with valid data should carry the flag [20:01:05 CEST] <ldts> wm4: I'll try to do this buffering on my end (I hope it is not too nasty) [20:01:45 CEST] <wm4> that increases the latency by 1 frame for absolutely no reason [20:02:05 CEST] <wm4> in general a demuxer or application won't really know whether a frame is the last one [20:02:27 CEST] <wm4> especially in ffmpeg it just doesn't work this way [20:02:51 CEST] <wm4> I don't see how a 1 byte dummy buffer is better than just a 0 sized buffer either [20:03:11 CEST] <ldts> ldts: agreed...then maybe I should send the dummy (with byte=1 to avoid the kernel warning) and re-open the discussion with the kernel maintainers? [20:03:42 CEST] <wm4> yeah [20:03:46 CEST] <ldts> wm4: 1 byte just works around the warning...it is not accepted either but does the trick since the hardware will handle it [20:04:16 CEST] <ldts> wm4: ok. will reopne the thread - can I add you to it? [20:04:39 CEST] <wm4> sure, but note I'm not subscribed to any kernel mailing list [20:05:25 CEST] <ldts> ldts: ok. will keep you updated. gtg now [20:05:42 CEST] <ldts> wm4: will send v3 later today with byte size = 1 [20:17:22 CEST] <cone-906> ffmpeg 03James Almer 07master:55cc0bccf357: Revert "Merge commit 'a97563c889fefd81ad6b3758471434d8c2e2e550'" [20:30:41 CEST] <kurosu_> who is interested in yadif and/or edited it? elenril@#libav-devel may want rewriting it [20:41:53 CEST] <durandal_1707> why rewrite? [20:43:18 CEST] <iive> there are improved deinterlacers [20:46:54 CEST] <iive> kurosu: what is the target of the yadif rewrite by elenril? better looking C code? improved speed? better algorith/working/results? [20:46:55 CEST] <BtbN> And because of that you re-write an existing one? [20:47:11 CEST] <BtbN> I wasn't aware of any issues with yadif. [20:47:28 CEST] <BtbN> Except for some tied to the algorithm, and changing the algorithm of a pre-existing deinterlacer seems weird [20:47:52 CEST] <kurosu> Just notes saying rewrite [20:48:49 CEST] <kurosu> Last I actually heard from him sounded more conservative, like bugfix [20:49:19 CEST] <kurosu> Hence the 'may' [20:49:55 CEST] <iive> what bugs? [20:50:00 CEST] <kurosu> I think the filter can badly overread under conditions in libav [20:50:34 CEST] <kurosu> This might have been fixed in ffmpeg, I wouldn't know [20:50:56 CEST] <iive> the original yadif was designed to overread, but I think that the ffmpeg port takes care of that. [20:51:42 CEST] <kurosu> In any case, if anyone cares, I'll leave it up to inquire [20:52:03 CEST] <iive> what does that mean? [21:09:12 CEST] <jamrial> iive: that if you care about yadif, you may want to discuss or keep track of what elenril plans to do [21:09:31 CEST] <iive> hahaha [21:17:48 CEST] <cone-906> ffmpeg 03Kaustubh Raste 07master:deeaaba1ab1e: avcodec/mips: preload data in hevc sao edge 45 degree filter msa functions [21:17:49 CEST] <cone-906> ffmpeg 03Kaustubh Raste 07master:ed1586b921d7: avcodec/mips: Removed generic function call in avc intra msa functions [21:17:50 CEST] <cone-906> ffmpeg 03Kaustubh Raste 07master:10ab5534e043: avcodec/mips: Improve avc weighted mc msa functions [21:17:51 CEST] <cone-906> ffmpeg 03Kaustubh Raste 07master:b8854e2439c3: avcodec/mips: Improve avc chroma vert mc msa functions [21:17:52 CEST] <cone-906> ffmpeg 03Kaustubh Raste 07master:6796a1dd8c14: avcodec/mips: Improve avc put mc 20, 01 and 03 msa functions [21:18:49 CEST] <jkqxz> LongChair: Thanks, looking at it now. [21:23:54 CEST] <LongChair> cool :) [21:53:18 CEST] <cone-906> ffmpeg 03Diego Biurrun 07master:9127ac5ebc94: configure: Add name parameter to require_pkg_config() helper function [21:53:19 CEST] <cone-906> ffmpeg 03James Almer 07master:d1256750e896: Merge commit '9127ac5ebc941d5e54828a91e5072c876be8ec42' [22:35:16 CEST] <feliwir> hey, why does AVFrame contain 2 data pointers when decoding audio? [22:35:26 CEST] <feliwir> what is the meaning of each? [22:35:42 CEST] <JEEB> if it's planar audio then you have the channels separate [22:36:15 CEST] <nevcairiel> planar would be the only case where you get multiple, so yeah, channels [23:08:29 CEST] <feliwir> JEEB, it is planar [23:08:40 CEST] <feliwir> but how would i play that back with OpenAL :( [23:09:09 CEST] <JEEB> if you need interleaved you either use libswresample which has an optimized thing around, or do your own [23:11:20 CEST] <feliwir> ok, guess that's the way to go then [23:14:27 CEST] <wm4> if you were to simulate 3D audio with openal, planar would actually be more convenient because you could feed each plane directly to an openal buffer [23:14:48 CEST] <JEEB> true [23:43:14 CEST] <tmm1> i'm trying to figure out how to add a configure check for kCMVideoCodecType_HEVC [23:43:19 CEST] <tmm1> it's an enum value.. should i use check_type ? [23:45:01 CEST] <wm4> hm I guess you want check_code [23:45:08 CEST] <wm4> which takes an arbitrary statement [23:45:29 CEST] <cone-906> ffmpeg 03Lionel CHAZALLON 07master:f3aefb3e1c3c: lavc: Add support for RockChip Media Process Platform [23:49:50 CEST] <tmm1> hmm, and then what? define some flag? [23:50:25 CEST] <jkqxz> What's wrong with check_type? [23:51:13 CEST] <jkqxz> Oh, enum value doesn't work there. Ignore that. [23:51:50 CEST] <wm4> there are plenty of examples, e.g. check_code cc linux/videodev2.h "int i = V4L2_PIX_FMT_MPEG1;" && enable mpeg1_v4l2_m2m [23:51:51 CEST] <tmm1> look like check_func_headers was used before (260ea7a7b3) [23:52:28 CEST] <tmm1> but that got rewritten into a runtime check.. that's probably what I should do too [23:53:09 CEST] <BBB> wm4: what wrong with prores? [23:53:16 CEST] <BBB> prores is awesome [23:53:27 CEST] <BBB> its stupid. its simple. its braindead. its awesome [23:53:37 CEST] <wm4> forcing half range [23:53:41 CEST] <wm4> that's so backwards [23:53:53 CEST] <BBB> :D its 12-bit so its not like it matters much in precision [23:57:15 CEST] <kierank> wm4: half range? [23:57:52 CEST] <wm4> I mean tv/mpeg/whatever range [23:58:08 CEST] Action: kierank repeats same argument as at vdd [23:58:15 CEST] <kierank> clipping is bad [23:58:22 CEST] <kierank> tv range is necessary [00:00:00 CEST] --- Thu Sep 28 2017

1 0

ffmpeg.log.20170927
by burek 28 Sep '17

28 Sep '17

[00:00:10 CEST] <JEEB> I guess -x264-params "deblock=2:2" or even more? [00:00:18 CEST] <JEEB> I'm checking what psnr tune did again [00:01:46 CEST] <kepstin> "--aq-mode 0 --no-psy" [00:01:50 CEST] <JEEB> yea, I found it [00:02:32 CEST] <JEEB> although wait, x264-params won't work like that because : is the delimiter [00:02:33 CEST] <JEEB> lol [00:03:05 CEST] <JEEB> unless it was "," [00:03:10 CEST] <JEEB> in which case it will work [00:03:31 CEST] <JEEB> av_dict_parse_string(&dict, x4->x264_params, "=", ":", 0) [00:03:40 CEST] <JEEB> yup, it was = and : so no-go with 2:2 [00:03:51 CEST] <redrabbit> its a TV>phone use case, when on the move i have to go for the lowest bitrate situation when on the move [00:04:05 CEST] <redrabbit> so 800k is optimal, i dont get much cuts [00:04:21 CEST] <JEEB> oh, there's an avoption for libx264 [00:04:23 CEST] <redrabbit> just 1 second or 2 when changing tower [00:04:24 CEST] <JEEB> -deblock [00:04:27 CEST] <kepstin> JEEB: deblock is mapped as an avoption, just use taht [00:04:28 CEST] <kepstin> yeah [00:04:29 CEST] <JEEB> yes [00:04:34 CEST] <JEEB> -deblock "2:2" [00:04:37 CEST] <JEEB> or more [00:04:40 CEST] <JEEB> see the results and tweak [00:04:44 CEST] <redrabbit> ok [00:04:55 CEST] <horox> ffplay output: https://pastebin.com/Z7jV9knA [00:05:01 CEST] <horox> test file: http://openartist.org/magiclantern/10bit.MLVFS [00:05:12 CEST] <horox> even more samples: http://www.magiclantern.fm/forum/index.php?topic=11899.0 [00:05:40 CEST] <kepstin> x264's defaults are designed to prefer blocking rather than smoothing on parts of the video which originally had high-frequency details [00:06:07 CEST] <kepstin> works better on higher-res videos, where the block size is relatively smaller. [00:07:15 CEST] <JEEB> horox: ok, so what happens is that most likely swscale cannot handle bayer_rggb16 correctly. I get the same effect because mpv doesn't handle bayer_rggb16 either [00:07:31 CEST] <JEEB> as in, the decoding might be correct [00:07:37 CEST] <horox> ok [00:07:38 CEST] <JEEB> but what happens after decoding [00:07:44 CEST] <JEEB> as in conversion to ye normal RGB [00:07:45 CEST] <JEEB> goes bonkers [00:07:58 CEST] <JEEB> horox: for funzies post that file on mpv's bug tracker ;) [00:08:19 CEST] <JEEB> if you're on windows you can grab mpv from https://mpv.srsfckn.biz/ for a screenshot [00:08:21 CEST] <horox> I also get the same color on mpv [00:08:23 CEST] <JEEB> yea [00:08:31 CEST] <JEEB> make an issue and attach the sample on the issue :D [00:08:39 CEST] <JEEB> let's see if haasn bites it :P [00:09:02 CEST] <JEEB> (he's the video renderer guy, so if he adds support for bayer_rggb16 [00:09:23 CEST] <horox> so mpv bug tracker.. I will do so, thanks! [00:09:47 CEST] <JEEB> of course it will not fix ffmpeg's conversion, but it might give us insight into how to do it correctly :) [00:10:10 CEST] <JEEB> because so far I've learned that that guy wants to do things Correctly [00:11:47 CEST] <horox> nice. [00:11:54 CEST] <horox> as for now, I use -vf lut3d=/opt/FFplay_mlv_dump.cube posted at https://www.magiclantern.fm/forum/index.php?topic=18392.0 [00:12:49 CEST] <JEEB> that might be worth noting as well, together with any possible references on how magic lantern saves data in those files [00:14:36 CEST] <horox> I have also used little crossplatform floss MLV App http://www.magiclantern.fm/forum/index.php?topic=20025.0 which is kind of a developer.converter for .mlv files, they get it right [00:14:56 CEST] <JEEB> specifications are generally preferred, but sure [00:15:11 CEST] <horox> yeah [00:15:41 CEST] <horox> would be nice to iron that out, it disturbs me [00:19:53 CEST] <redrabbit> -deblock 2:2 does seems to smooth it out [00:20:20 CEST] <redrabbit> does look a bit better for low res [00:21:47 CEST] <JEEB> seems like it's kind of specified @ http://www.magiclantern.fm/forum/index.php?topic=7122.0 [00:21:53 CEST] <JEEB> I wonder what the multimedia.cx wiki says [00:22:48 CEST] <JEEB> not much else than the header :D https://wiki.multimedia.cx/index.php/MLV [00:24:58 CEST] <redrabbit> Deblock has two parameters: alpha (strength) and beta (threshold)., 2 2 seems nice for my 700k avc 640*360 stream. idk if i should try other values [00:26:39 CEST] <JEEB> if it works it works. if it's good enough why work harder :D [00:26:48 CEST] <JEEB> (since you're not making a "proper" test anyways) [00:26:53 CEST] <redrabbit> yep [00:27:14 CEST] <redrabbit> what would be proper just curious [00:28:08 CEST] <JEEB> playing with the parameter in various ways while keeping other things static (including file size). and then doing blind tests between the results [00:28:26 CEST] <redrabbit> oh that's far from my protocol [00:28:51 CEST] <redrabbit> im just tuning in to tv from my mobile phone and look for artifacts / overall feeling [00:32:14 CEST] <redrabbit> ah, looks like i can increase resolution a bit now [00:32:18 CEST] <redrabbit> looks better [01:02:22 CEST] <redrabbit> -vcodec libx264 -x264-params vbv-maxrate=700:vbv-bufsize=1400:aq-mode=0:no-psy -deblock 2:2 -crf 24 -g 50 {framerate} -map 0:v:0 -map 0:a:0 -s 896x504 -preset veryslow [01:04:33 CEST] <JEEB> maxrate and bufsize of course have global avoptions, and those latter two are just -tune psnr [01:04:46 CEST] <JEEB> so no x264-params needed [01:05:01 CEST] <redrabbit> works the same heh [01:05:14 CEST] <JEEB> yes, the result should be the same [01:05:41 CEST] <redrabbit> this is looking a lot better than my old setting [01:05:55 CEST] <redrabbit> -vcodec libx264 -bufsize 1400k -maxrate 700k [01:06:02 CEST] <hanna> JEEB: this would most likely be a user shader sort of thing [01:06:04 CEST] <redrabbit> -crf 24 -g 50 {framerate} -map 0:v:0 -map 0:a:0 -s 640x360 -preset veryslow [01:06:11 CEST] <hanna> actually I guess not [01:06:43 CEST] <redrabbit> it does look more like HEVC [01:06:46 CEST] <redrabbit> neat [01:07:37 CEST] <JEEB> redrabbit: so basically until a certain point the stuff that makes higher bit rates look good start creating artifacts, which bring an image of sharpness first and then just look bad [01:08:06 CEST] <JEEB> at that point just blurring crap the hell out actually leads to a more watchable image [01:08:40 CEST] <JEEB> and yes, HEVC seems to have a lot of coding tools that are really simple to optimize for that, since optimizing for PSNR has similar effects [01:08:55 CEST] <JEEB> plus x265 doesn't seem to have as much psychovisual stuff going on in general [01:44:04 CEST] <iive> HEVC does blur the hell out of low bitrate videos. It doesn't look like artifacts, but it looks like lower resolution. [02:04:19 CEST] <moniker-> what does term "caps" mean? as in raster caps [02:04:53 CEST] <moniker-> limit? [02:05:10 CEST] <moniker-> or for ex "shader caps" [02:06:05 CEST] <drv> capabilities [02:06:12 CEST] <moniker-> right [02:13:00 CEST] <moniker-> i've run into a comment confirming my card amd r7 poor dxva performance running multiple streams https://ffmpeg.org/pipermail/libav-user/2015-September/008527.html [02:13:15 CEST] <moniker-> from the comment: "With Intel (HD5500) we see 4+ 4K30 and 30+ FHD [02:13:15 CEST] <moniker-> streams running in parallel, AMD/ATI from R7 to [02:13:15 CEST] <moniker-> W8100 does not support 4K and is more or less unusable [02:13:15 CEST] <moniker-> with more than 2 streams(?)." [03:24:12 CEST] <thebombzen_> does anyone here have a recommendation for a container to put mp3 streams in? raw mp3 is really awkward [03:35:10 CEST] <furq> m4a, mka [03:40:59 CEST] <thebombzen_> I thought about m4a but I was worried that it might confuse players because m4a usually contains AAC [03:41:12 CEST] <thebombzen_> or will that not really be a problem [03:41:22 CEST] <thebombzen_> (obviously not for mpv, but I meant on mobile) [03:42:13 CEST] <moniker-> are there any particular benefits (performance) in using ffmpeg64.dll ? [03:43:04 CEST] <thebombzen_> you should always use 64-bit programs on a 64-bit operating system [03:43:17 CEST] <moniker-> right [03:45:09 CEST] <redrabbit> anybody tried staxrip [03:46:07 CEST] <redrabbit> the nvenc stuff work wonders with ti [03:46:16 CEST] <redrabbit> it.. i get 600+fps [04:05:01 CEST] <furq> well yeah it's nvenc [04:12:08 CEST] <redrabbit> output plays fine with vlc however dvbviewer seems to have micro lags.. like it stutters for fraction of seconsd [04:12:12 CEST] <redrabbit> uploading it [04:23:57 CEST] <redrabbit> imgpost.cf/sample.mkv [04:31:45 CEST] <redrabbit> well mpchc works fine as well, only dvbviewer has the playback issue [04:34:20 CEST] <Ch3ck> Anyone tried this: https://github.com/giorgisio/goav [05:16:28 CEST] <acos> Howdy folks [05:23:11 CEST] <redrabbit> -c:v h264_nvenc -x264-params output-depth=10 < this is strange that i have to use -x264-params but i didnt found another way to use 10 biot [05:23:14 CEST] <redrabbit> bit* [05:27:32 CEST] <redrabbit> https://github.com/Brainiarc7/ffmpeg-nvenc-windows-build-with-mxe/blob/mast… [05:27:39 CEST] <redrabbit> char *x264_params; // List of x264 options in opt:arg or opt=arg format [05:30:10 CEST] <dkh> is that a newish feature or no? [05:31:03 CEST] <redrabbit> well its looking like i can use x264_params to use command line parameters for nvenc [05:31:13 CEST] <dkh> not sure what it handles, but i know ive had difficulty in the past attempting to figure out reasonable settings similar to what i would set in x264, since crf/cq are different in each [05:31:16 CEST] <redrabbit> its just an odd syntax [05:31:49 CEST] <dkh> yeah 10bit seems like something it ought to support on its own as well [05:33:13 CEST] <acos> So I just exported a video I'm working on to a bunch of frames because the other export options are no good. I'm wondering if ffpmeg will be the right tool to use to merge 5000 frames to make a video. [05:36:17 CEST] <dkh> acos, sure [05:36:47 CEST] <acos> It's still exporting. Is it a long command I have to type in? [05:37:51 CEST] <acos> It's a tiff sequence with file names 0336 to 5000 [05:39:56 CEST] <dkh> not really. `ffmpeg -i {input_pattern} -framerate 30 -vcodec libx264 {output}.mp4` or similar [05:40:09 CEST] <acos> Do I need to use %d? [05:42:11 CEST] <dkh> %04d.tiff in your case i think [05:43:33 CEST] <dkh> you should also just be able to do `-pattern_type glob -i "*.tiff"` if you dont need to be precise about it [05:43:38 CEST] <acos> Thanks dkh :) will it auto magically set frame size based on the frames? [05:43:51 CEST] <acos> Ah I'm on Windows if that help any [05:44:17 CEST] <dkh> you can set `-s 1280x720` or whatever if you need to scale them [05:46:00 CEST] <acos> Cool sounds great [05:50:08 CEST] <redrabbit> Reading option '-x264-params' & matched as AVOption 'x264-params' with argument 'output-depth=10'. [05:50:12 CEST] <redrabbit> from my logs [05:50:23 CEST] <redrabbit> im not sure it does work in 10 bit though [05:51:26 CEST] <redrabbit> makes no sense that -x264-params is a parameter name with nvenc [05:51:37 CEST] <redrabbit> but its in libnvenc.c [05:51:50 CEST] Action: redrabbit is puzzled [05:52:28 CEST] <acos> redrabbit: video is confusing [05:57:51 CEST] <c3r1c3-Win> But isn't NVENC a form of x264? [05:58:04 CEST] <c3r1c3-Win> which means it's run on the same parameters (in general)? [05:59:38 CEST] <acos> Perhaps [06:02:00 CEST] <dkh> it's the encoder for gpu encoding with nvidia cards [06:02:51 CEST] <c3r1c3-Win> dkh: Yes, and it encodes a few different formats... one of them being x264... [06:03:48 CEST] <dkh> yes, it is for x264, no, the parameters are not identical [06:04:06 CEST] <dkh> in fact many are a few totally different concepts between them [06:05:50 CEST] <kepstin> c3r1c3-Win: h264 is the name of a video codec, x264 and nvenc are two completely unrelated encoders that can output h264 [06:06:08 CEST] <kepstin> they options the two use are significantly different [06:08:09 CEST] <redrabbit> looks like -profile:v main10 is the option for 10 bit, however my build doesnt support it. 'x264-params' with argument 'output-depth=10' seems to work with nvenc though idk if it does anything however [06:08:33 CEST] <redrabbit> (my 1060 supports 10 bit but the ffmpeg build may not) [06:08:33 CEST] <dkh> one way to find out :P [06:08:44 CEST] <kepstin> redrabbit: assuming you're actually using nvenc, the -x264-params option should print a warning message and be ignored [06:09:00 CEST] <dkh> haha, great [06:09:04 CEST] <redrabbit> https://github.com/Brainiarc7/ffmpeg-nvenc-windows-build-with-mxe/blob/mast… [06:09:08 CEST] <redrabbit> look at this [06:09:16 CEST] <kepstin> redrabbit: that's not ffmpeg? [06:09:17 CEST] <redrabbit> x264-params in there ! [06:09:35 CEST] <kepstin> that's some fork, ffmpeg doesn't even have a file named 'libnvenc.c' [06:09:56 CEST] <redrabbit> strange stuff.. [06:10:03 CEST] <redrabbit> well [06:10:49 CEST] <dkh> hadnt heard of it myself [06:11:01 CEST] <redrabbit> im using this build https://github.com/illuspas/ffmpeg-hw-win32/tree/master/static/x86_64/bin [06:11:32 CEST] <redrabbit> Reading option '-x264-params' & matched as AVOption 'x264-params' with argument 'output-depth=10' [06:11:45 CEST] <redrabbit> it does take the x264-params with nvenc [06:11:48 CEST] <redrabbit> :| [06:12:09 CEST] <kepstin> well, i have no idea what that build is and can't support it [06:12:49 CEST] <redrabbit> np [06:13:32 CEST] <acos> I got my build from the official site. Let's see if these tifs will merge to a video [06:13:48 CEST] <kepstin> it looks like ffmpeg can do 10bit with nvenc_hevc, but not nvenc_h264 [06:14:09 CEST] <kepstin> assuming hardware support, of course. [06:15:56 CEST] <kepstin> it looks like no nvidia hardware has ever supported 10bit h264 encoding [06:16:21 CEST] <acos> Cpu encode it? [06:17:44 CEST] <kepstin> cpu encoding is generally preferred if possible, the software encoders give better quality at the same bitrate than hardware in general [06:18:10 CEST] <kepstin> pretty much the main reason to use a hw encoder is if your cpu is busy doing something else [06:19:15 CEST] <acos> Ah. I walk away from my laptop during encodes and move to desktop. [06:20:09 CEST] <notdaniel> well yeah, i mean you use nvenc to do it faster and using the gpu :P [06:20:33 CEST] <notdaniel> saved us a loooot of money switching to nvenc, but yeah, the issue is getting the quality settings ideal [06:21:34 CEST] <acos> Ya it's hard to get settings just right [06:22:44 CEST] <notdaniel> still havent gotten them right [06:23:12 CEST] <acos> I'm just trying basic h264 haha [06:23:17 CEST] <notdaniel> 4 million encodes later or something [06:23:52 CEST] <acos> Wow. Hope you find the settings [06:24:20 CEST] <notdaniel> haha yeah seriously [06:24:29 CEST] <kepstin> x264 is a lot easier to tweak, for most use cases you just pick a rate control method, and a value for "-preset" that meets your speed requirements [06:24:57 CEST] <kepstin> with nvenc... you're probably not gonna do better than "ok", and there's fewer things you can tweak with hw encoders. [06:24:58 CEST] <acos> My videos look too blocky [06:25:17 CEST] <acos> Ok I think these frames are ready to encode [06:25:35 CEST] <notdaniel> nvenc is a harsh mistress of its own [06:26:46 CEST] <acos> Only took 30 min to export 4213 frames it a 9.88gb. Now to move to h264 [06:28:18 CEST] <kepstin> huh, that's not really all that many frames, for such a huge file size. Only ~3 minutes of video at 24fps. [06:31:37 CEST] <acos> Ugh globbing not supported [06:36:36 CEST] <acos> Wow it seems to be working. [06:41:05 CEST] <redrabbit> -c:v hevc_nvenc -profile:v main10 > works [06:41:30 CEST] <redrabbit> while main10 and h264_nvenc wont [06:42:12 CEST] <redrabbit> so i'm using [06:42:13 CEST] <redrabbit> -c:v h264_nvenc -x264-params output-depth=10 [06:42:24 CEST] <redrabbit> and it works, well it outputs stuff. [06:42:32 CEST] <redrabbit> idk if it does use 10bit ! [06:43:06 CEST] <acos> My video says yuv444p [06:43:12 CEST] <acos> Is that bad? [06:43:36 CEST] <acos> It also looks like it's making a 25fps I told it to be 29.97 [06:47:23 CEST] <acos> Why is the video 25fps? [06:47:47 CEST] <redrabbit> notdaniel: can you share your nvenc settings [06:49:05 CEST] <acos> I used the -framerate command [06:49:10 CEST] <acos> It didn't work at all [06:49:46 CEST] <acos> Changing it to -r seemed to work [06:49:51 CEST] <notdaniel> acos, may need to set -r to actually force it [06:49:52 CEST] <notdaniel> yeah [06:49:57 CEST] <notdaniel> 29.97 blows though [06:50:26 CEST] <redrabbit> 06:15 < kepstin> it looks like no nvidia hardware has ever supported 10bit h264 encoding > StaxRip does have the 10Bit option with AVC and nvenc [06:50:31 CEST] <acos> Well that's what I shot it at. Trying to keep same format [06:51:00 CEST] <redrabbit> "--output-depth 10" [06:51:02 CEST] <acos> Will YouTube accept a 444p file? [06:51:45 CEST] <acos> I probably should have set camera to 24p [06:53:32 CEST] <redrabbit> notdaniel: also how do you use nvenc ? [06:53:56 CEST] <redrabbit> only ffmpeg or straight up nvenc / both [06:54:50 CEST] <redrabbit> -c:v h264_nvenc -x264-params output-depth=10 -b:v 3500k -maxrate 3500k -rc vbr_2pass -rc-lookahead 32 < current settings [06:55:51 CEST] <acos> What's current version? Is it bad I'm using 20170718-012620a win64 static? [07:00:37 CEST] <acos> Why does ffmpeg say dupe frames. It cut some off the video. [07:03:23 CEST] <acos> Wow. Mixed the frame numbers up. Sw works great. [07:06:12 CEST] <jnollette> hey everyone - can yall help me out - i am curious about HE-AAC... I see it in itunes, but want to compress audio, and can't find the flags or info [07:06:26 CEST] <jnollette> any shared experiance would be helpful [07:16:10 CEST] <notdaniel> here's the big part of our encoding command: https://ghostbin.com/paste/x3ogz [07:16:12 CEST] <notdaniel> redrabbit [07:18:16 CEST] <notdaniel> using it on ec2 gpu instances [07:20:16 CEST] <notdaniel> looks like 56 of them at the moment. would be so much worse and more expensive with x264 [07:22:21 CEST] <acos> Wow [08:11:00 CEST] <wani> why would this work: ffmpeg -i new.mkv -c copy -ss 00:10:06.230 -t 00:00:8.175 output.mkv [08:11:11 CEST] <wani> but this not ffmpeg -i new.mkv -c:v libvpx-vp9 -crf 30 -b:v 0 -c:a libvorbis -ss 00:10:06.230 -t 00:00:8.175 output.mkv [08:12:17 CEST] <wani> well it just starts encoding but never gets past the first frame, just repeats frame= 0 fps=0.0 q=0.0 Lsize= 7kB time=00:00:00.00 bitrate=N/A speed= 0x [09:18:12 CEST] <_julian> morning [09:18:37 CEST] <_julian> is it allowed to change the codecpar struct in an AVStream on the fly to signal a format change of this stream? [17:12:25 CEST] <acos> Thanks for the help last night everyone. I got my video out. [18:01:36 CEST] <Hopper_> Mornin' FFMPEG, anyone available to help me refine my video stream? [18:10:08 CEST] <Hopper_> I am running FFMPEG on a LattePanda (A single board comp similar to the RaspberryPi, but running windows), and I am having issues with framerate and CPU usage. [18:10:57 CEST] <Hopper_> Here is my current command: https://pastebin.com/WSHBpBEF [18:14:32 CEST] <furq> Hopper_: the default codec for mpegts is mpeg2video [18:14:42 CEST] <furq> if you want to use x264 then add -c:v libx264 [18:14:58 CEST] <Hopper_> Which SHOULD I use? [18:15:05 CEST] <furq> shrug [18:15:07 CEST] <furq> probably x264 on that cpu [18:15:14 CEST] <Hopper_> Lower demand? [18:15:15 CEST] <furq> i don't think the m2v encoder is multithreaded [18:15:42 CEST] <Hopper_> It seems to increase usage on the cpu 2x when I add -=threads 0 [18:16:07 CEST] <furq> nvm i guess it does slice threading [18:16:07 CEST] <Hopper_> And "-c:v libx264" is an output command? [18:16:12 CEST] <furq> yes [18:16:47 CEST] <furq> if x264 ultrafast is too slow then you're probably going to have to capture at a lower resolution [18:17:18 CEST] <furq> i assume capturing lossless and then encoding later is out of the question on an sbc [18:17:39 CEST] <Hopper_> Yes, this is broadcast OTA from an airborne device. [18:18:04 CEST] <redrabbit> use hw encoders [18:18:30 CEST] <redrabbit> you wont have enough cpu on an ARM board for encoding [18:18:35 CEST] <furq> it's not arm [18:18:37 CEST] <furq> it's an atom x8300 [18:18:40 CEST] <redrabbit> well, its weak [18:18:46 CEST] <furq> which doesn't have quicksync [18:18:54 CEST] <furq> oh wait [18:18:55 CEST] <furq> maybe it does [18:18:59 CEST] <redrabbit> even the rpi has hw encoders heh [18:19:12 CEST] <redrabbit> even the rpi0, 5$ board :p [18:19:23 CEST] <furq> well yeah but the pi's hw encoding is practically useless [18:19:38 CEST] <redrabbit> its for the webcam [18:19:44 CEST] <redrabbit> works mkay [18:20:39 CEST] <Hopper_> Well "-c:v libx264" seems to maintain the same CPU usage, but does help with the framerate coming from one of the webcams. [18:21:44 CEST] <furq> https://ark.intel.com/products/87383/Intel-Atom-x5-Z8300-Processor-2M-Cache… [18:21:56 CEST] <furq> no quicksync mentioned here but someone on a forum claims it does actually have it [18:22:05 CEST] <furq> using quicksync on windows is some kind of nightmare though [18:22:30 CEST] <furq> Hopper_: if those are usb3 webcams you might want to use rawvideo as input instead of mjpeg [18:22:41 CEST] <furq> that won't work with usb2 though [18:23:43 CEST] <Hopper_> Here are my options for both cams. https://pastebin.com/vizvERZh [18:25:59 CEST] <Hopper_> furq: I can't capture raw with one of my devices. [18:26:18 CEST] <furq> you can't do it with either [18:26:41 CEST] <furq> oh wait nvm i'm reading the wrong column [18:27:16 CEST] <furq> actually no i'm not. they both do 1080p rawvideo but only at 5fps [18:27:23 CEST] <furq> so i'm guessing they're usb2 [18:28:00 CEST] <furq> i doubt that'll make a huge difference on an atom anyway [18:28:27 CEST] <Hopper_> Hm, I wonder what my limitation is. [18:29:44 CEST] <furq> that's a 4W CPU, it's never going to be good at this sort of thing [18:30:16 CEST] <Hopper_> I know, but at a previous point in this project I was running similar encoding on the same board but running debian and it was performing better. [18:30:56 CEST] <Hopper_> Well also, I'm tasting the code currently on my desktop and I'm still having the framerate issue. [18:31:15 CEST] <furq> what's the issue [18:31:21 CEST] <furq> i take it it's just not encoding at 30fps [18:31:42 CEST] <Hopper_> Correct, one cam seems to be at full speed, but the c920 is at a low framerate. [18:31:56 CEST] <furq> does it happen when you capture from that cam by itself [18:32:36 CEST] <Hopper_> No, but it does look pixelated and bad. [18:37:39 CEST] <Hopper_> I wonder what was different before. [18:41:40 CEST] <Hopper_> furq, redrabbit: Any clever ways to reduce overhead? [18:44:33 CEST] <furq> not that i didn't already mention [18:45:09 CEST] <furq> unless that cpu does actually support quicksync, in which case use that instead of x264 [18:45:09 CEST] <Hopper_> Well, Thanks! You gave me a great starting point. [18:45:21 CEST] <Hopper_> I can at least try, right? [18:47:14 CEST] <furq> that build has libmfx, so i guess try -c:v h264_qsv [18:47:28 CEST] <furq> not sure if you need anything else for it to work [18:48:07 CEST] <Hopper_> So why would I be getting the framerate issue on my i5 desktop? [18:48:49 CEST] <furq> oh right [18:48:54 CEST] <furq> maybe some issue with dshow [18:49:27 CEST] <furq> if you're not maxing out your cpu then there's probably some kind of capture issue [18:49:40 CEST] <Hopper_> Hm, okay [19:57:35 CEST] <rjp421> anyone with a pi and pi-cam, and updated packages+kernel+ffmpeg-git: can you please test piping raspivid to ffprobe or ffmpeg? confirm whether or not ffmpeg crashes (pls let me know results so i can stop spamming this) [20:06:28 CEST] <relaxed> rjp421: can you pastebin.com the command and console output [20:11:20 CEST] <rjp421> relaxed, i pasted it a few days ago, i will try to find the link.. sdcard is shot, so i cant get the original cmd from it... but 'raspivid <options> -o - | ffprobe -i -' i think should work [20:15:42 CEST] <relaxed> what is raspivid piping? [20:17:17 CEST] <rjp421> relaxed, not sure exactly, but i think h264.. [20:18:12 CEST] <rjp421> furq, JEEB, pls post my last pastebin link if you happen to have it still (im still looking) [20:22:59 CEST] <relaxed> rjp421: you probably need something like, raspivid <options> -o - | ffmpeg -f h264 -framerate $fps - ... [20:23:44 CEST] <relaxed> er, that should have been "-i - ..." [20:24:02 CEST] <rjp421> relaxed, the same cmd that crashed had been working fine, before i went and updated packages+kernel [20:26:34 CEST] <relaxed> you can't test this now? [20:28:38 CEST] <rjp421> relaxed, i need a new sdcard for the pi before i can test :( [20:31:47 CEST] <relaxed> to get proper support you should wait until then [20:33:56 CEST] <rjp421> i may not be the only one who needs it fixed, hence hoping it can be tested before i am able to (which may be a while) [20:35:37 CEST] <relaxed> when you're back in action, see if my arm builds make any difference -> https://www.johnvansickle.com/ffmpeg/ [20:36:23 CEST] <rjp421> cool, ty :) [20:40:05 CEST] <lindylex> I am using the following to generate a video that is side by side. ffmpeg -i left.mp4 -i right.mp4 -filter_complex "[0:v]setpts=PTS-STARTPTS, pad=iw*2:ih[bg]; [1:v]setpts=PTS-STARTPTS[fg]; [bg][fg]overlay=w" -y final.mp4 I would like to place a vertical black line on top right in the middle or add a black border to the video on the left. If I add a border to the left video I would like to maintain the original sum dimension [20:40:05 CEST] <lindylex> of the original videos. This solution would require subtracting the border width from the left videos width. I will take either solution. [20:53:36 CEST] <ZoeB> Hi! When transcoding one file to another with ffmpeg, is it possible to custom map the specific metadata tags? I'm batch converting FLACs to MP3s and would love to be able to set ALBUMARTISTSORT in the source to ARTIST in the output etc. [20:55:59 CEST] <relaxed> lindylex: use cut,pad on both left and right [20:56:15 CEST] <relaxed> I meant crop,pad [20:57:44 CEST] <rjp421> relaxed, found the paste https://pastebin.com/raw/2zycD73c [20:58:33 CEST] <rjp421> relaxed, oops wrong one, sorry. sec [20:59:04 CEST] <rjp421> https://pastebin.com/raw/hWRK9dVC and https://pastebin.com/raw/APRbBSgw [21:01:03 CEST] <relaxed> can't do much until your system is back up [21:01:21 CEST] <rjp421> that was with an old /opt/vc (incl raspivid), which i was updating when the sdcard crapped out [21:05:15 CEST] <lindylex> relaxed: I am having some issue trying to add this to the filter. Let me show you what I am trying. [21:09:41 CEST] <lindylex> relaxed: This is what I tried ffmpeg -i c4.mov -i c5.mov -filter_complex "[0:v]setpts=PTS-STARTPTS, pad=iw*2:ih[bg], crop=1000:720:0:0; [1:v]setpts=PTS-STARTPTS[fg]; [bg][fg]overlay=w" -y final.mp4 It cuts the width from the original video and does not combine them. [21:29:11 CEST] <furq> rjp421: i don't have a pi cam [21:31:05 CEST] <rjp421> furq, i found the paste, nvm :p [21:34:55 CEST] <lindylex> How do i crop the video to the left before placing them side by side? ffmpeg -i c4.mov -i c5.mov -filter_complex "[0:v]setpts=PTS-STARTPTS, pad=iw*2:ih[bg], crop=1000:720:0:0; [1:v]setpts=PTS-STARTPTS[fg]; [bg][fg]overlay=w" -y final.mp4 [21:35:24 CEST] <lindylex> This crops the left video but it does not combine the videos. [21:37:42 CEST] <furq> move crop before [bg] [21:37:51 CEST] <furq> also you probably want to use hstack instead of pad+overlay [21:47:41 CEST] <lindylex> Can you explain what is hstack? [21:49:07 CEST] <llogan> a filter for horizontal stacking of video: https://ffmpeg.org/ffmpeg-filters.html#hstack [21:50:10 CEST] <llogan> it's faster and easier than using pad+overlay [21:57:29 CEST] <lindylex> something like this? ffmpeg -i c4.mov -i c5.mov -filter_complex "[0:v][1:v] crop=1000:720:0:0 ,hstack[v];[0:a][1:a]amerge=inputs=2[a]" -map "[v]" -map "[a]" -ac 2 -y f2.mp4 [21:58:00 CEST] <lindylex> It fails and does nothing. How do I target the left video for cropping? [21:59:09 CEST] <furq> hstack goes first [21:59:31 CEST] <furq> hstack,crop;amerge [22:00:30 CEST] <furq> actually, if you're cropping the right side off the left-hand video, then that doesn't work [22:01:01 CEST] <lindylex> Yes this is what i want to do and add a black 2 pixel border. [22:01:04 CEST] <furq> [0:v]crop=1000:720[tmp0];[tmp0][1:v]hstack[out] [22:04:42 CEST] <lindylex> furq: this throws an error : ffmpeg -i c4.mov -i c5.mov -filter_complex "[0:v]crop=1000:720[tmp0];[tmp0][1:v]hstack[out];[0:a][1:a]amerge=inputs=2[a]" -map "[v]" -map "[a]" -ac 2 -y f2.mp4 [22:05:03 CEST] <lindylex> error : Output with label 'v' does not exist in any defined filter graph, or was already used elsewhere. [22:06:33 CEST] <furq> change out to v [22:06:42 CEST] <lindylex> I just saw that. [22:08:06 CEST] <lindylex> Ok I think I get what you are doing. [22:24:40 CEST] <lindylex> I think I understand but this does not work :: ffmpeg -i c4.mov -i c5.mov -filter_complex "[0:v]crop=300:720[tmp0]; [tmp0]pad=298:720:0:0:black[tmp0]; [tmp0][1:v]hstack[v];[0:a][1:a]amerge=inputs=2[a]" -map "[tmp0]" -map "[a]" -ac 2 -y f2.mp4 [22:25:09 CEST] <lindylex> I am trying to crop the video on the left to leave a black border on the right.' [22:27:50 CEST] <lindylex> Thought this might work ffmpeg -i c4.mov -i c5.mov -filter_complex "[0:v]crop=300:720, pad=0:0:-2:0:black[tmp0];[tmp0][1:v]hstack[v];[0:a][1:a]amerge=inputs=2[a]" -map "[v]" -map "[a]" -ac 2 -y f2.mp4 [22:33:15 CEST] <furq> lindylex: crop,pad [22:33:40 CEST] <furq> if one filter's output goes straight to the next filter's input, use , [22:33:54 CEST] <furq> you only need labels and ; if you want different inputs to the next filter [22:35:19 CEST] <lindylex> furq : ffmpeg -i c4.mov -i c5.mov -filter_complex "[0:v]crop=300:720, pad=0:0:-2:0:black[tmp0];[tmp0][1:v]hstack[v];[0:a][1:a]amerge=inputs=2[a]" -map "[v]" -map "[a]" -ac 2 -y f2.mp4 This passes the crop to the padding correct using commas? [22:35:34 CEST] <furq> should do [22:37:02 CEST] <lindylex> If the left video is 300:720 I want to add 2 pixel of black to the right of left video witha final left video output of 300:720 not 302:702 [22:37:25 CEST] <lindylex> This is why I tried this :: ffmpeg -i c4.mov -i c5.mov -filter_complex "[0:v]crop=300:720[tmp0]; [tmp0]pad=298:720:0:0:black[tmp0]; [tmp0][1:v]hstack[v];[0:a][1:a]amerge=inputs=2[a]" -map "[tmp0]" -map "[a]" -ac 2 -y f2.mp4 [22:38:00 CEST] <lindylex> sorry wait that is a mistake one sec [22:39:02 CEST] <lindylex> furq : This is what I am trying :: ffmpeg -i c4.mov -i c5.mov -filter_complex "[0:v]crop=300:720, pad=298:720:2:0:black[tmp0];[tmp0][1:v]hstack[v];[0:a][1:a]amerge=inputs=2[a]" -map "[v]" -map "[a]" -ac 2 -y f2.mp4 [22:43:22 CEST] <lindylex> I think I got it :: ffmpeg -i c4.mov -i c5.mov -filter_complex "[0:v]crop=300:720, pad=352:720:2:0:black[tmp0];[tmp0][1:v]hstack[v];[0:a][1:a]amerge=inputs=2[a]" -map "[v]" -map "[a]" -ac 2 -y f2.mp4 [22:43:41 CEST] <lindylex> furq : Thanks [22:43:47 CEST] <lindylex> llogan: thanks [22:43:58 CEST] <lindylex> relaxed : thanks [23:00:23 CEST] <Hopper_> furq: Should I use this as an example for drawing a text overlay from a file on my video which updates regularly? http://ffmpeg.gusari.org/viewtopic.php?f=11&t=1897 [23:04:10 CEST] <furq> sure? [23:05:13 CEST] <Hopper_> so drawtext will update from a .txt file? [23:08:56 CEST] <furq> it will with reload=1 [23:10:33 CEST] <Hopper_> Hm, so I have to figure out how to write my .txt atomically. [23:12:48 CEST] <BtbN> write it somewhere else, then mv [23:13:03 CEST] <BtbN> on the same fs [00:00:00 CEST] --- Thu Sep 28 2017

1 0

ffmpeg-devel.log.20170926
by burek 27 Sep '17

27 Sep '17

[01:50:08 CEST] <JEEB> aaa, blame it on the 02:50 [01:50:26 CEST] <JEEB> didn't even notice in my editor that the docs were also 80 char/line [01:52:30 CEST] <JEEB> (yes, my editor window happened to be rather narrow) [01:55:39 CEST] <JEEB> there, that should be OK [02:30:08 CEST] <cone-082> ffmpeg 03James Almer 07master:ecb9741ba294: avcodec/avpacket: deprecate av_copy_packet() [02:30:08 CEST] <cone-082> ffmpeg 03James Almer 07master:a447b75de8ed: avformat: replace all uses of av_copy_packet() [02:30:08 CEST] <cone-082> ffmpeg 03James Almer 07master:c463b81d037f: ffplay: replace use of av_copy_packet() [04:06:19 CEST] <jamrial> rcombs: do you think you could look at the current dashenc merge queue and see if they can/should be applied or just no-op'd? [04:06:29 CEST] <rcombs> how do I do that [04:07:00 CEST] <jamrial> it's about seven commits, starting with https://git.libav.org/?p=libav.git;a=commitdiff;h=9df9309d233f59d9706444a1e… [04:07:43 CEST] <jamrial> you can try to merge them yourself (look at doc/libav-merge.txt) [04:08:12 CEST] <jamrial> or just create a brach in github or somewhere with the same commits but adapted to apply to ffmpeg [04:08:25 CEST] <jamrial> and i'll handle the mergign [04:09:38 CEST] <jamrial> we've been stuck at this point for months since the person that wrote some apparently incompatible dashenc code for us hasn't replied or taken care of this, so it'd be nice if we could resume the merges [04:17:08 CEST] <tmm1> i need to create an hvcC atom in memory for videotoolbox. looks like the code i need is in ff_isom_write_hvcc(), but that requires a AVIOContext to write to.. is there an easy way i can create a fake iocontext with a memory buffer? [04:23:21 CEST] <jamrial> tmm1: you can't call ff_isom_write_hvcc() from libavcodec if that's your intention [04:24:43 CEST] <tmm1> no? [04:25:15 CEST] <tmm1> so i have to replicate it into lavc either way [04:27:10 CEST] <rcombs> jamrial: sorry, what's the full commit range? [04:27:36 CEST] <jamrial> rcombs: 9df9309d233f59d9706444a1e24ac24139f2640d to 7295b7373862ee54903b33d6ef3335531dfa93ad [04:34:14 CEST] <jamrial> tmm1: does videtoolbox only need extradata in hvcc format, or also the bitstream? [04:36:00 CEST] <tmm1> just the hvcc [04:36:17 CEST] <tmm1> just the extradata i mean [04:36:28 CEST] <tmm1> to set up the decoder [04:39:26 CEST] <jamrial> so basically a simple function like ff_videotoolbox_avcc_extradata_create() but for hevc? then yeah, duplicating a bit of code from lavf in lavc is fine [04:48:24 CEST] <cone-082> ffmpeg 03James Almer 07master:89a2472ec536: avformat/img2enc: remove av_dup_packet() call [04:49:46 CEST] <tmm1> jamrial: yes exactly [04:49:55 CEST] <tmm1> seems like a lot more code for hvcc though [04:50:19 CEST] <tmm1> theres a struct and a bunch of decoding and encoding routines [04:53:35 CEST] <jamrial> tmm1: the code in lavf avc.c is also longer than what's in ff_videotoolbox_avcc_extradata_create(). you don't need all that [04:54:04 CEST] <jamrial> for starters, in videotoolbox.c you have the NALUs already split and parsed [05:02:54 CEST] <tmm1> fair enough [05:07:17 CEST] <rcombs> I was considering adding HEVC after finishing up the split of VideoToolbox into independent decoders [05:08:06 CEST] <rcombs> the only thing that's missing (afaik) is adding code mirroring the `if (s->dts_sync_point >= 0) {` block in h264_parser.c to the parsers for the other relevant codecs [05:13:57 CEST] <jamrial> rcombs: do we need decoders when we already have hwaccels? [05:14:33 CEST] <rcombs> the hwaccels integrate messily with the software decoders, and pull in unnecessary dependencies [05:14:53 CEST] <rcombs> (because VT is meant to be used for full-stream decode) [05:22:46 CEST] <rcombs> jamrial: see github/rcombs/ffmpeg/dash-merge; there's a fixup I couldn't figure out how to get rid of [05:22:53 CEST] <rcombs> other than that it's pretty clean [05:23:04 CEST] <rcombs> haven't tested [05:28:28 CEST] <jamrial> rcombs: you couldn't squash the fixup commit into the commit merge in question? [05:28:46 CEST] <rcombs> I tried! [05:28:51 CEST] <rcombs> for some reason it stuck around [05:29:28 CEST] <jamrial> i suppose that without it, the merge prior to it is broken? if so i'll try to squash it here [05:29:48 CEST] <rcombs> yeah [05:30:40 CEST] <tmm1> rcombs: are you working on vt decoders? [05:30:56 CEST] <tmm1> did you find a way to reorder frames [05:32:01 CEST] <rcombs> tmm1: I've got a dumb method that just reorders based on pts+dts, which is fine for h264 since the parser can generate those already [05:33:22 CEST] <jamrial> rcombs: thanks a lot for that matter. should have asked for your help earlier :p [05:33:29 CEST] <jamrial> i'm surprised it applied so cleanly [05:33:43 CEST] <rcombs> I mean there were conflicts, but they weren't hard to resolve [05:33:56 CEST] <rcombs> just some stuff that moved around, really [05:35:29 CEST] <jamrial> i see there were small conflicts, but i assumed our codebase had diversed a lot more than this [06:41:50 CEST] <jamrial> rcombs: https://github.com/jamrial/FFmpeg/commits/mergework [06:42:06 CEST] <jamrial> ubitux: ^ :D [06:42:15 CEST] <jamrial> if you want/can test it [06:42:45 CEST] <jamrial> or review it [10:17:24 CEST] <cone-080> ffmpeg 03Frédéric Devernay 07master:eec67f25224a: avcodec/dnxhdenc: fix DNxHR 444 encoding crashes [11:19:05 CEST] <BtbN> The CUDA thumbnail filter sure munches some VRAM [11:19:38 CEST] <BtbN> My 1050 with 2GB of VRAM can handle around n=350 [11:19:50 CEST] <BtbN> at 1080p [15:07:13 CEST] <cone-080> ffmpeg 03Moritz Barsnick 07master:16c8a9feeab3: lavf/tls_gnutls: fix compilation with GnuTLS 2.x [15:07:14 CEST] <cone-080> ffmpeg 03Moritz Barsnick 07master:6bf48c4805cb: lavf/tls_gnutls: fix warnings from version check [16:15:31 CEST] <Chloe> Is there any reason to have both the dv1394 and iec61883 libavdevices? [16:16:33 CEST] <Chloe> also looks like dv1394 is legacy from https://www.kernel.org/doc/Documentation/ABI/removed/dv1394 [16:19:30 CEST] <wm4> nice [16:19:34 CEST] <wm4> is that 7 years ago [16:30:40 CEST] <jamrial> cool, send a patch to remove it then [16:31:58 CEST] <Chloe> will do [16:33:48 CEST] <jamrial> ubitux: going to push your vda removal patch? [16:52:43 CEST] <ubitux> jamrial: dunno& maybe i should [16:52:48 CEST] <mateo`> go [16:53:01 CEST] <ubitux> i was able to "refactor" the apple garbage kit without dropping vda [16:53:14 CEST] <ubitux> so i care less about it now [16:53:17 CEST] <ubitux> just some more zombie code [16:53:34 CEST] <wm4> the zombie code will cause us more problems later [16:53:44 CEST] <wm4> such as getting rid of hwaccel-specific stuff in ffmpeg.c [16:54:30 CEST] <Chloe> ubitux: if it removes code, push it [16:54:40 CEST] <Chloe> any patch that removes code is probably a good patch [16:55:10 CEST] <ubitux> you can remove all the code with that reasonning [16:55:34 CEST] <ubitux> but yeah sure i'll drop it, maybe tomorrow© [16:55:48 CEST] <ubitux> jamrial: cool btw the merge work [16:55:57 CEST] <ubitux> i'm working on the side data thing [16:56:10 CEST] <ubitux> i basically copied the avframe side data [16:56:29 CEST] <ubitux> it's a bit of a shame that you can't really have multiple side data of the same type, but whatever [16:56:36 CEST] <ubitux> at least it's buffer ref counter [16:56:38 CEST] <ubitux> -r+d [17:11:42 CEST] <jamrial> ubitux: if you mean in packet side data, the thing about only one per type was a recent change of mine [17:11:59 CEST] <jamrial> since get_side_data() would just fetch the first one and ignore any other you could have added [17:12:09 CEST] <jamrial> you can undo that if needed [17:13:09 CEST] <ubitux> i meant in frame side data [17:13:17 CEST] <ubitux> where the get only raise the first match [17:13:43 CEST] <jamrial> you can have more than one in frame side data, but get() will also only give you the first, yeah [17:14:19 CEST] <wm4> I'm also going to argue that side data should have a flat/global namespace [17:14:30 CEST] <jamrial> with packet, the new() functions will replace the existing one if you add a new one, unlike in frame [17:15:16 CEST] <JEEB> any additionaly opinions on http://ffmpeg.org/pipermail/ffmpeg-devel/2017-September/216816.html and http://ffmpeg.org/pipermail/ffmpeg-devel/2017-September/216699.html ? [17:15:16 CEST] <atomnuker> jamrial: the example command on the doc commit in mergework needs to be fixed [17:16:04 CEST] <jamrial> atomnuker: what should it be? [17:17:10 CEST] <wm4> JEEB: probably good? is it ported from Libav? [17:17:24 CEST] <atomnuker> jamrial: avconv -> ffmpeg [17:17:33 CEST] <jamrial> right [17:17:45 CEST] <JEEB> wm4: yea [17:18:11 CEST] <JEEB> took me a while to back-port it and I double-checked that the tests' CTS offsets match (other than the time base, FFmpeg's for some reason makes the time base 512 times bigger) [17:18:20 CEST] <JEEB> but on the other hand the patch touches *nothing* in the time base stuff [17:18:28 CEST] <JEEB> so (Ž4@) [17:18:41 CEST] <wm4> Libav merges usually don't require reviews for pushing [17:18:47 CEST] <JEEB> so where in libav you have +/-1 offset with a time base 30 [17:18:55 CEST] <wm4> as long as you make clear from which libav commit it was merged, probably [17:19:09 CEST] <JEEB> you have +/-512 offset with a time base of 30*512 [17:19:19 CEST] <JEEB> so the code works correctly [17:19:22 CEST] <jamrial> oh yeah, add a "cherry picked from" line if it comes from libav [17:19:46 CEST] <JEEB> I don't have push rights so whoever pushes it can do that I guess... or do I send a v4 :D [17:20:05 CEST] <JEEB> let me find the hashes [17:20:31 CEST] <JEEB> https://git.libav.org/?p=libav.git;a=commit;h=c380a0d7f7a2c7411aae60463e25d… , https://git.libav.org/?p=libav.git;a=commit;h=7c35bee0251efc271c8f7900ce816… [19:33:37 CEST] <cone-080> ffmpeg 03Peter Große 07master:9df9309d233f: dashenc: calculate stream bitrate from first segment if not available [19:33:38 CEST] <cone-080> ffmpeg 03Peter Große 07master:3d23a5f96ad7: dashenc: add support for assigning streams to AdaptationSets [19:33:39 CEST] <cone-080> ffmpeg 03Peter Große 07master:efd2fc41b3f0: dashenc: allow assigning all streams of a media type to an AdaptationSet [19:33:40 CEST] <cone-080> ffmpeg 03Peter Große 07master:ca9bc9de6902: dashenc: default to one AdaptationSet per stream [19:33:41 CEST] <cone-080> ffmpeg 03Peter Große 07master:dce2929efa8e: dashenc: copy language and role metadata from streams assigned to sets [19:33:42 CEST] <cone-080> ffmpeg 03Peter Große 07master:01f1f017d831: dashenc: use avio_dynbuf instead of packet_write callback [19:33:43 CEST] <cone-080> ffmpeg 03Peter Große 07master:7295b7373862: dashenc: add webm support [19:33:44 CEST] <cone-080> ffmpeg 03Peter Große 07master:c5c663541739: doc: add dash muxer [19:33:45 CEST] <cone-080> ffmpeg 03James Almer 07master:52223ffe4461: Revert "lavf/dashenc: update bitrates on dash_write_trailer" [19:33:46 CEST] <cone-080> ffmpeg 03Rodger Combs 07master:3b9ef1358836: Merge commit '9df9309d233f59d9706444a1e24ac24139f2640d' [19:33:47 CEST] <cone-080> ffmpeg 03Rodger Combs 07master:777d53c793a2: Merge commit '3d23a5f96ad72961c14ba3a0c2add8f2ab374b61' [19:33:48 CEST] <cone-080> ffmpeg 03Rodger Combs 07master:c0fae3ff902e: Merge commit 'efd2fc41b3f0749f9715d50b581f22bbaa8c5b99' [19:33:49 CEST] <cone-080> ffmpeg 03Rodger Combs 07master:3f7a8bb67b27: Merge commit 'ca9bc9de690258d4761a19b0df6e9c9113b80115' [19:33:50 CEST] <cone-080> ffmpeg 03Rodger Combs 07master:5c9373385d1a: Merge commit 'dce2929efa8e82b0832a828f7e8cb81ff8c20a4e' [19:33:51 CEST] <cone-080> ffmpeg 03Rodger Combs 07master:a9f51d19d6b5: Merge commit '01f1f017d831cf14617aaaeafcec3ae3a81efce7' [19:33:52 CEST] <cone-080> ffmpeg 03Rodger Combs 07master:1b8ef01f04ab: Merge commit '7295b7373862ee54903b33d6ef3335531dfa93ad' [19:33:53 CEST] <cone-080> ffmpeg 03Rodger Combs 07master:3eb1d05ef719: Merge commit 'c5c663541739cb813a2a5668ee8339b535b35d7d' [19:35:03 CEST] <wm4> nice [19:35:33 CEST] <jamrial> now a bunch of noops [19:38:13 CEST] <wm4> philipl: did you ever take a look at Libav's cuvid support? [19:39:26 CEST] <wm4> it definitely looks like it would require adding a few new symbols to our cuvid headers [19:39:36 CEST] <wm4> and I have no idea how to do this without violating copyright [19:39:57 CEST] <wm4> although the headers say " * Copyright (c) 2010-2017 NVIDIA Corporation" so *shrug* [19:46:01 CEST] <cone-080> ffmpeg 03Mark Thompson 07master:f033ba470fba: vaapi_encode: Support VBR mode [19:46:02 CEST] <cone-080> ffmpeg 03Mark Thompson 07master:eddfb5721029: vaapi_h264: Enable VBR mode [19:46:03 CEST] <cone-080> ffmpeg 03Mark Thompson 07master:ff35aa8ca406: vaapi_encode: Pass framerate parameters to driver [19:46:04 CEST] <cone-080> ffmpeg 03Mark Thompson 07master:ca62236a89f4: vaapi_encode: Add VP8 support [19:46:05 CEST] <cone-080> ffmpeg 03James Almer 07master:efc4b3e9d702: Merge commit 'ca62236a89f47bd871eaf69d8d9e837c93c55a6c' [19:50:21 CEST] <cone-080> ffmpeg 03Mark Thompson 07master:708e84cda1bd: mov: Avoid memcmp of uninitialised data [19:50:22 CEST] <cone-080> ffmpeg 03James Almer 07master:a6596831a03d: Merge commit '708e84cda1bdbffb92847f3d6ccf6fbeb26d9948' [20:01:45 CEST] <cone-080> ffmpeg 03Andreas Cadhalpun 07master:612cc0712836: pgssubdec: reset rle_data_len/rle_remaining_len on allocation error [20:01:46 CEST] <cone-080> ffmpeg 03James Almer 07master:4c359200b142: Merge commit '612cc0712836af2f025b0c68b11da29b9f259d5a' [20:04:25 CEST] <cone-080> ffmpeg 03Diego Biurrun 07master:ab87af41636b: configure: Add proper weak dependency of avformat on network [20:04:26 CEST] <cone-080> ffmpeg 03James Almer 07master:7289c7658a1a: Merge commit 'ab87af41636b081dd3562423999351b5444fa09e' [20:09:02 CEST] <cone-080> ffmpeg 03Diego Biurrun 07master:d4c2103bd30f: golomb: Convert to the new bitstream reader [20:09:03 CEST] <cone-080> ffmpeg 03Alexandra Hájková 07master:0c89ff82e9dd: aic: Convert to the new bitstream reader [20:09:04 CEST] <cone-080> ffmpeg 03Alexandra Hájková 07master:ffc00df0a61b: cavs: Convert to the new bitstream reader [20:09:05 CEST] <cone-080> ffmpeg 03Alexandra Hájková 07master:6b1f559f9a06: dirac: Convert to the new bitstream reader [20:09:06 CEST] <cone-080> ffmpeg 03Alexandra Hájková 07master:0f94de8a092b: fic: Convert to the new bitstream reader [20:09:07 CEST] <cone-080> ffmpeg 03Alexandra Hájková 07master:d85b37a95531: loco: Convert to the new bitstream reader [20:09:08 CEST] <cone-080> ffmpeg 03Alexandra Hájková 07master:5a6da49dd0c0: ralf: Convert to the new bitstream reader [20:09:09 CEST] <cone-080> ffmpeg 03Alexandra Hájková 07master:2b94ed12de7b: shorten: Convert to the new bitstream reader [20:09:10 CEST] <cone-080> ffmpeg 03Alexandra Hájková 07master:2d72219554ad: h261dec: Convert to the new bitstream reader [20:09:11 CEST] <cone-080> ffmpeg 03Alexandra Hájková 07master:ab2539bd374f: ffv1: Convert to the new bitstream reader [20:09:12 CEST] <cone-080> ffmpeg 03James Almer 07master:475ff3ec2487: Merge commit 'ab2539bd374fe7ddbc6e2f058b62645cd5076192' [20:10:51 CEST] <wm4> so they're all skipped, right [20:24:24 CEST] <tmm1> woohoo, i got vt hevc decoding working [20:24:35 CEST] <tmm1> building that hvcC was a pita [20:29:02 CEST] <JEEB> 'grats [20:29:15 CEST] <JEEB> and yea, hvcC is overly complex if I recall correctly [20:29:23 CEST] <JEEB> you duplicate a crapload of stuff that's in the darn parameter sets [20:29:38 CEST] <rcombs> jamrial: \o/ [20:30:48 CEST] <wm4> did they make it worse than avcc [20:30:53 CEST] <JEEB> yes [20:30:58 CEST] <wm4> how... [20:31:05 CEST] <JEEB> wm4: https://lists.matroska.org/pipermail/matroska-devel/2013-September/004567.h… [20:31:14 CEST] <JEEB> this is pretty much 1-1 to the 14496-15 thing [20:31:40 CEST] <wm4> oh right, I remember this [20:32:24 CEST] <nevcairiel> for some reason they keep mirroring more and more info from the sps into it [20:32:31 CEST] <JEEB> yea [20:33:09 CEST] <JEEB> probably to enable things that don't implement the parameter set parsing to get some values so that players can say nope quicker? [20:34:34 CEST] <wm4> that kind of stuff is the only thing that'd make sense [20:34:41 CEST] <TD-Linux> is parsing a sps really that hard? [20:34:42 CEST] <wm4> but it's still dumb [20:35:13 CEST] <JEEB> TD-Linux: it had some coding mode for the values [20:35:19 CEST] <TD-Linux> do they still have inband and out of band sps [20:35:22 CEST] <JEEB> which I guess people are lazy to implement? [20:35:38 CEST] <JEEB> there's one identifier for "you can have in and out of band" [20:35:45 CEST] <JEEB> and another for no in-band [20:35:56 CEST] <JEEB> apple decided to use the "no in-band" one [20:45:37 CEST] <cone-080> ffmpeg 03Anton Khirnov 07master:b420a27e7475: avconv: allow -b to be used with streamcopy [20:45:38 CEST] <cone-080> ffmpeg 03James Almer 07master:2508e606fba8: Merge commit 'b420a27e74750b60d2e064236afb10be06a38ace' [20:52:26 CEST] <tmm1> JEEB: you mean the array_completeness flag? [20:52:40 CEST] <JEEB> yea [20:52:53 CEST] <JEEB> there was a rule related to the identifier regarding that IIRC [20:53:02 CEST] <tmm1> i just tried sending first PPS in hvcC and second in stream [20:53:04 CEST] <tmm1> and it seems to work [20:53:18 CEST] <tmm1> with array_completeness=0 in the hvcc [20:54:32 CEST] <JEEB> pretty sure that is against the spec tho :D [21:02:31 CEST] <wm4> you know, Apple could just have fixed the videotoolbox API [21:08:18 CEST] <rcombs> 1. accept Annex B sans-extradata [21:08:24 CEST] <rcombs> 2. reorder internally [21:08:29 CEST] <rcombs> but nope [21:23:58 CEST] <cone-080> ffmpeg 03Anton Khirnov 07master:fd9212f2edfe: Mark some arrays that never change as const. [21:23:59 CEST] <cone-080> ffmpeg 03James Almer 07master:318778de9ebe: Merge commit 'fd9212f2edfe9b107c3c08ba2df5fd2cba5ab9e3' [21:28:30 CEST] <rcombs> jamrial: wait shit I done fucked up [21:28:51 CEST] <jamrial> rcombs: how so? [21:29:18 CEST] <jamrial> i ran the example command in the dashenc doxy and the output seemed the same, for that matter [21:29:40 CEST] <rcombs> swapped write_header/init_output [21:29:45 CEST] <rcombs> patch in a sec [21:30:02 CEST] <rcombs> though it might not matter with the dynbuf change [21:30:22 CEST] <cone-080> ffmpeg 03wm4 07master:3ad825793a43: hwcontext_cuda: implement frames_get_constraints [21:30:23 CEST] <cone-080> ffmpeg 03James Almer 07master:e7c91850531a: Merge commit '3ad825793a43253154bed05827f27425fc0757df' [21:39:12 CEST] <rcombs> jamrial: OK, while trying to test this, I'm finding dashenc is broken in a weird unrelated way [21:39:36 CEST] <rcombs> init_output_stream_streamcopy copies the codec_tag from the input to the output, which breaks because the output doesn't have compatible tags [21:39:44 CEST] <rcombs> if e.g. the input is MPEGTS and the output is DASH [21:40:10 CEST] <jamrial> rcombs: that'd be something that 61f589e31e fixes [21:40:12 CEST] <jamrial> i think [21:40:22 CEST] <jamrial> we can cherry pick that since it's too far away in the queue [21:40:42 CEST] <rcombs> if anything it would be the opposite [21:40:49 CEST] <rcombs> dashenc already doesn't have a codec_tag here [21:41:04 CEST] <jamrial> actually no, you're right [21:41:21 CEST] <rcombs> the problem is that there isn't a tag member, so ffmpeg.c tries to copy it [21:41:32 CEST] <rcombs> so, either ffmpeg.c should stop that, or dashenc should unset it [21:43:30 CEST] <cone-080> ffmpeg 03wm4 07master:577326d43059: lavc: deprecate refcounted_frames field [21:43:31 CEST] <cone-080> ffmpeg 03James Almer 07master:b1cf151c4dfd: Merge commit '577326d430593a25456393a75212b95d1cd94131' [21:43:41 CEST] <rcombs> I don't know when this regressed [21:43:46 CEST] <jamrial> wm4: why didn't you apply that here back then? [21:44:19 CEST] <wm4> oh, it's not? not sure [21:44:50 CEST] <jamrial> rcombs: maybe d086e40459 [21:45:06 CEST] <rcombs> is that applied? [21:45:20 CEST] <jamrial> thats an ffmpeg commit, so yes :p [21:45:43 CEST] <jamrial> i mean that one might have introduced the regression. it's the one that removed .codec_tag [21:49:25 CEST] <rcombs> yeah that seems likely [21:49:56 CEST] <rcombs> I'll copy the handling code from segment.c [21:50:37 CEST] <jamrial> that commit was needed btw because mov muxer changed something regarding codec_tags [21:51:52 CEST] <cone-080> ffmpeg 03Diego Biurrun 07master:b3825723dcef: configure: Merge compiler/libc/os hacks sections [21:51:53 CEST] <cone-080> ffmpeg 03James Almer 07master:f9445760289d: Merge commit 'b3825723dceffc64240da7b0e562bd1fd024da26' [21:54:17 CEST] <rcombs> it'd have also been needed due to adding matroska dash support [21:55:11 CEST] <rcombs> alright, patches sent [21:56:12 CEST] <jamrial> rcombs: you could have just applied the merge fix [21:56:46 CEST] <rcombs> ¯\_(Ä)_/¯ [21:57:28 CEST] <jamrial> i mean, it's not like it needs a review if it's rolling back an accidental change you did :p [22:05:32 CEST] <cone-080> ffmpeg 03Diego Biurrun 07master:24d5680bbc01: configure: Simplify inline asm check with appropriate helper function [22:05:33 CEST] <cone-080> ffmpeg 03James Almer 07master:932e28b13e9a: Merge commit '24d5680bbc01fc124709d522d348572ad4672563' [22:09:16 CEST] <cone-080> ffmpeg 03Diego Biurrun 07master:66988320794a: configure: Add proper weak dependency of drawtext filter on libfontconfig [22:09:17 CEST] <cone-080> ffmpeg 03James Almer 07master:740e557d6eac: Merge commit '66988320794a107f2a460eaa71dbd9fab8056842' [22:13:12 CEST] <cone-080> ffmpeg 03Diego Biurrun 07master:acfa7a2178f0: configure: Drop weak dependencies on external libraries for webm muxer [22:13:13 CEST] <cone-080> ffmpeg 03James Almer 07master:3f9e7ddd90d3: Merge commit 'acfa7a2178f08fd81b66279959cd55ec3ae237e2' [22:14:32 CEST] <cone-080> ffmpeg 03Alexandra Hájková 07master:c29da01ac95e: svq3: Convert to the new bitstream reader [22:14:33 CEST] <cone-080> ffmpeg 03James Almer 07master:a901869c19ed: Merge commit 'c29da01ac95ea2c8c5c4b3a312a33aaaa8fb7068' [22:19:25 CEST] <rcombs> jamrial: also did you see my commit changing the merge tool to use HEAD instead of master [22:19:44 CEST] <jamrial> yes, but didn't push it since it's not a merge [22:20:09 CEST] <jamrial> send it to the ml, or ask ubitux what he thinks (he wrote the script afaik) [22:21:48 CEST] <rcombs> OK [22:24:21 CEST] <cone-080> ffmpeg 03Diego Biurrun 07master:a97563c889fe: configure: Simplify libxcb check [22:24:22 CEST] <cone-080> ffmpeg 03James Almer 07master:1985071e41f4: Merge commit 'a97563c889fefd81ad6b3758471434d8c2e2e550' [22:32:26 CEST] <cone-080> ffmpeg 03Diego Biurrun 07master:aba7fdcc8baa: configure: Add require_header() convenience function [22:32:27 CEST] <cone-080> ffmpeg 03James Almer 07master:14194090a6f6: Merge commit 'aba7fdcc8baaed35e804c7882b70a848a0e566c7' [22:34:40 CEST] <ubitux> rcombs: master or origin/master? [22:35:35 CEST] <ubitux> jamrial: thx a lot for the merges btw [22:35:52 CEST] <JEEB> yea, great stuff [22:36:14 CEST] <jamrial> ubitux: no prob [22:36:33 CEST] <durandal_1707> more oil on fire [22:37:06 CEST] <JEEB> I ain't seeing no fire [22:38:22 CEST] <rcombs> ubitux: patch sent [22:39:36 CEST] <wm4> jamrial: yeah, it's great to see merges continuing [22:40:47 CEST] <ubitux> rcombs: oh you're actually switching from master to HEAD mmh [22:41:00 CEST] <durandal_1707> why? [22:41:09 CEST] <rcombs> yeah, to allow doing merges while not on local master [22:41:30 CEST] <ubitux> should be fine i guess [22:45:37 CEST] <ubitux> what's going on with the bitstream reader? [22:45:51 CEST] <ubitux> we still haven't the 64-bit version? [22:54:09 CEST] <durandal_1707> you mean libav one? [22:55:28 CEST] <ubitux> no, ffmpeg [22:55:33 CEST] <ubitux> or was it merged? [22:55:40 CEST] <ubitux> i mean, pushed [22:56:26 CEST] <durandal_1707> pushed what? [22:56:38 CEST] <ubitux> our get_bits.h was supposed to get a 64-bit cache version [22:56:44 CEST] <ubitux> enabled on some configurations [22:56:55 CEST] <ubitux> i thought a patch was sent for that purpose [22:57:14 CEST] <durandal_1707> you are misinformed [22:57:59 CEST] <durandal_1707> it have issues [22:58:06 CEST] <ubitux> https://patchwork.ffmpeg.org/patch/4260/ [22:58:12 CEST] <ubitux> you were actually the one behind this [22:58:52 CEST] <ubitux> i mean, we have a performance gap to close compared to libav on x86 with important decoders such as h264 [22:59:48 CEST] <BBB> most h264 doesnt use get_bits (cavlc), though... [23:00:11 CEST] <durandal_1707> see last review by foo86 [23:06:24 CEST] <cone-080> ffmpeg 03Diego Biurrun 07master:bcaedef1189a: configure: Add require_cpp_condition() convenience function [23:06:25 CEST] <cone-080> ffmpeg 03James Almer 07master:c83c164f05cb: Merge commit 'bcaedef1189a3531aa4dfb020627eb0133ffa89c' [23:29:56 CEST] <cone-080> ffmpeg 03Martin Storsjö 07master:a1a143adb0fd: rtmp: Rename packet types to closer match the spec [23:29:57 CEST] <cone-080> ffmpeg 03James Almer 07master:f858a6e27817: Merge commit 'a1a143adb0fd11c474221431417cff25db7d920f' [23:35:56 CEST] <cone-080> ffmpeg 03Martin Storsjö 07master:15a92e0c402c: rtmp: Correctly handle the Window Acknowledgement Size packets [23:35:57 CEST] <cone-080> ffmpeg 03James Almer 07master:4ea63d2cdd04: Merge commit '15a92e0c402c830b607f905d6bf203b6cfb4fa8c' [23:49:19 CEST] <cone-080> ffmpeg 03Diego Biurrun 07master:740b0bf03b4b: build: Ignore generated .version files [23:49:21 CEST] <cone-080> ffmpeg 03Diego Biurrun 07master:7abdd026df6a: asm: Consistently uppercase SECTION markers [23:49:21 CEST] <cone-080> ffmpeg 03James Almer 07master:62f1c9f10671: Merge commit '740b0bf03b4bb8b0a0e964750817ac0363a33c55' [23:49:22 CEST] <cone-080> ffmpeg 03James Almer 07master:0c005fa86f01: Merge commit '7abdd026df6a9a52d07d8174505b33cc89db7bf6' [23:51:46 CEST] <cone-080> ffmpeg 03John Stebbins 07master:8e67039c6312: asfdec: Use the ASF stream count when iterating [23:51:47 CEST] <cone-080> ffmpeg 03James Almer 07master:e666c2b5ec97: Merge commit '8e67039c6312ba520945f2c01b7b14df056d5ed1' [23:56:46 CEST] <horox> sample video uploading... here is discussion of the problem: https://www.magiclantern.fm/forum/index.php?topic=18392.0 a issue with black level decoding (Green Cast).... [23:57:19 CEST] <JEEB> right, bayer_rgb16le [23:58:59 CEST] <horox> https://pastebin.com/Z7jV9knA [00:00:00 CEST] --- Wed Sep 27 2017

1 0

ffmpeg.log.20170926
by burek 27 Sep '17

27 Sep '17

[00:00:04 CEST] Action: relaxed whispers xeon [00:00:49 CEST] <furq> !filter crossfeed @thebombzen [00:00:50 CEST] <nfobot> thebombzen: http://ffmpeg.org/ffmpeg-filters.html#crossfeed [00:00:53 CEST] <furq> that got added recently [00:01:14 CEST] <relaxed> a new bot! [00:01:18 CEST] <furq> idk whether it's better than the others but i use it in mpv and it sounds better than nothing [00:01:27 CEST] <furq> oh hey someone else did it [00:01:44 CEST] <furq> could do with the windows/osx builds as well though [00:02:26 CEST] <relaxed> who is fflogger's master? [00:02:36 CEST] <furq> no idea [00:02:44 CEST] <furq> nfobot is mine if it wasn't obvious from the fact that nobody else ever uses it [00:04:24 CEST] <BytesBacon> If I go say with a pair of Intel Xeons, is there a way to limit the threads to one CPU and then another instance of ffmpeg on the 2nd CPU. [00:04:54 CEST] <relaxed> BytesBacon: you probably only need one- https://www.intel.com/content/www/us/en/products/processors/xeon/e7-process… [00:05:41 CEST] <BytesBacon> LOL I was thinking about going on ebay, but maybe I'll look at the newer ones. [00:05:42 CEST] <furq> i would have thought those would be more expensive than a last-gen dual socket system [00:05:45 CEST] <furq> yeah [00:05:59 CEST] <furq> 2-3 generation old dual socket boards are usually quite cheap on ebay [00:06:22 CEST] <furq> it really depends on your use case though [00:11:15 CEST] <Johnjay> generation meaning intel gen? [00:11:48 CEST] <Johnjay> nfobot: how do I add silence to an audio stream? [01:41:47 CEST] <rjp421> anyone with a pi and pi-cam, and updated packages+kernel+ffmpeg-git: can you please test piping raspivid to ffprobe or ffmpeg? confirm whether or not ffmpeg crashes [02:02:31 CEST] <blap> ultima ftw [02:09:59 CEST] <Ultima> hmm? [02:15:29 CEST] <blap> the games [02:15:39 CEST] <thebombzen> furq: I use nfobot occasionally [02:15:41 CEST] <blap> broke new ground [02:15:49 CEST] <thebombzen> although I ususally call it furqbot [02:17:46 CEST] <furq> please respect my brand [04:21:55 CEST] <stunts513> im a bit lost. i just transcoded a live stream to an mp4 and apparently there were some hiccups along the way as i have a 2.3gb mp4 thats a little over 3 min long. [04:22:14 CEST] <stunts513> it keeps trying to seek past that but has issues. any ideas? [05:35:50 CEST] <koyglreg> Which produces better quality - mpeg2video vs x262? [05:36:17 CEST] <koyglreg> I want a DVD-compatible MPEG file. [06:29:26 CEST] <dystopia_> goto mpeg2 for dvd's koyglreg [06:35:05 CEST] <linoobx> Has anyone here compiled FFmpeg for Windows before? I am new to Linux and trying to make a modified version of ffplay, but before I start making any changes to the code, I first want to see if I can just compile the default, unmodified code to build a working ffplay.exe. [06:35:37 CEST] <linoobx> I have of course looked at: https://trac.ffmpeg.org/wiki/CompilationGuide/CrossCompilingForWindows [06:37:34 CEST] <linoobx> When googling, almost all "How-to's" are circa 2010, and out-dated instructions (e.g. using SDL-1.2, etc.) [06:41:54 CEST] <linoobx> Even the aforementioned website was written in 2013. I am trying to make a 64-bit build, and have run: apt-get install libsdl2-dev and apt=get install mingw-w64 [06:43:34 CEST] <linoobx> Based off the aforementioned website, and https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu I set: PATH="/home/jeff/code/bin:$PATH" PKG_CONFIG_PATH="/home/jeff/code/ffmpeg_build/lib/pkgconfig" [06:43:54 CEST] <linoobx> then used: ./configure prefix="/home/jeff/code/ffmpeg_build" --disable-d3d11va --disable-dxva2 --arch=x86_64 --enable-shared --disable-static --enable-cross-compile --disable-network --disable-postproc --enable-asm --disable-encoders --disable-libopenjpeg --disable-iconv --disable-zlib --disable-bzlib --disable-doc --disable-ffprobe --disable-ffmpeg --disable-ffserver --pkg-config=pkg-config --pkg-config-flags="--static" --extra-cflags="-I/ [06:43:57 CEST] <linoobx> home/jeff/code/ffmpeg_build/include" --extra-ldflags="-L/home/jeff/code/ffmpeg_build/lib" --bindir="/home/jeff/code/bin" --target-os=mingw64 [06:46:00 CEST] <linoobx> However, when looking at the ./configure output, it does not show sdl2 under "outdevs:", and therefore, also does not show ffplay under "programs:" [06:48:07 CEST] <linoobx> apt-mark showinstall gcc-mingw-w64-x86-64 shows that it is installed, but when I add --cc=gcc-mingw-w64-x86-64 to ./configure, it fails. [06:54:33 CEST] <linoobx> Anyone know how to get this to work, or what I am missing? [07:00:26 CEST] <linuxnoob> Also, could anyone explain why something more recent like this: https://kimathir.wordpress.com/2016/10/12/ffmpeg-cross-compile-2016/ is using SDL-1.2 ?? [07:06:56 CEST] <linuxnoob> Is there any benefit to using SDL-2 over SDL-1.2 ? [07:11:16 CEST] <c3r1c3-Win> linuxnoob: 1. Have you tried asking Kimathir? [07:11:28 CEST] <c3r1c3-Win> 2. Have you looked at the SDL docs? [07:16:43 CEST] <linoobx> 1. No I have not. Who is Kimathir? How do I get in touch with them? [07:17:46 CEST] <linoobx> 2. Only at the SDL2 docs (I had made a simple image viewer with SDL2 to experiment with it.). [07:22:49 CEST] <linoobx> Does anyone know how to execute a "script"? Such as this: https://ffmpeg.zeranoe.com/forum/viewtopic.php?f=41&t=5036&sid=3433b6748258… (Second link) [07:29:36 CEST] <xacktm> it looks like any other bash script [07:29:52 CEST] <linoobx> ah [07:31:22 CEST] <linoobx> <--- still doesn't even know what the difference between the "terminal" command prompt and "bash" is. I know it is Bourne-Again-Shell, after the name of the creatore of the first shell [07:31:42 CEST] <linoobx> But that's about it [07:31:45 CEST] <tdr> linoobx, explain what you mean between the two [07:32:05 CEST] <linoobx> which two? [07:32:20 CEST] <linoobx> Sorry, about the shells? or the scripts? [07:32:28 CEST] <tdr> linoobx, bash is a shell you can run on a console (text mode) VT or over ssh or on a gui shell that displays a prompt [07:33:35 CEST] <tdr> linoobx, on a desktop, the "shell windows" are essentially the same as a command line only box shell, except behind the scene, the gui ones are pseudo-terminals (a ptty) vs a true terminal (tty) [07:34:40 CEST] <tdr> linoobx, pseudo since they are run through X and whatnot, they are not directory on control-alt-f1 c-a-f2 etc [07:34:52 CEST] <tdr> directly [07:38:59 CEST] <linoobx> hmm. I feel extreemly ignorant right now. [07:39:36 CEST] <tdr> linoobx, for most folks, there is very minimal or no differance between if you open a shell on your desktop vs on command line login. [07:41:37 CEST] <linoobx> ah.. Okay. I was just doing what I saw someone do in a YouTube video of how to setup Debian 9 on VMWare. (He clicked "Activities" in the topleft and then typed "terminal" into the search box. I've Just been using that). [07:42:29 CEST] <tdr> linoobx, to run a script, you'd either call it directly ./scriptname or if it's not marked executable you'd need say to execute it with a shell: bash ./scriptname [07:42:58 CEST] <linoobx> I presume then that I've been using a GUI shell. [07:43:10 CEST] <linoobx> ah ok [07:43:13 CEST] <tdr> linoobx, ok thats just one specific graphical terminal he's launching on his desktop. any other terminal would work too [07:44:05 CEST] <tdr> xterm, konsole, terminator, aterm, eterm, .... there are a billion different "terminals" ... one specific one is called "terminal" [07:44:19 CEST] <linoobx> ah.. [07:45:19 CEST] <linoobx> Yeah, I noticed that when I typed in terminal, Konsol, Qterminal, Qterminal Drop Down, also show up. Was wondering what the difference was. [07:45:31 CEST] <tdr> that search block the video used is just like using the "run" line on windows or using spotlight on mac to locate "terminal" [07:46:16 CEST] <linoobx> bash ./scriptname is what the person did on this website I was looking at: https://kimathir.wordpress.com/2016/10/12/cross-compile-ffmpeg-for-windows-… ( 8th line down in the grey area) [07:46:20 CEST] <tdr> any shell window would work (well any you likely have) [07:47:07 CEST] <linoobx> However I was hesitant to execute that b/c on the line above he says you should do: chmod 755 ./mingw-w64-build-3.6.7 [07:47:13 CEST] <tdr> the correct way to do it would be to make the file executable and at the top of the script, specify which shell it's supposed to run with. (shebang magic ... like #!/bin/bash) [07:48:09 CEST] <tdr> yes, that would make it executable, then you can run it using your default shell (probably bash) using its path ./scriptname (./ means "this directory") [07:48:57 CEST] <linoobx> After typing in: man chmod and not really understanding what 755 is, I decided against it. I mean man chmod does say something about 3 octadecimal digits, but the values only go as high as 4 for the options available. [07:49:47 CEST] <tdr> basic unix permissions, one per digit. 7 is read/write/execute, 5 is read + execute. 3 digits: owner, group, world [07:51:01 CEST] <linoobx> ah... [07:51:02 CEST] <tdr> octals since they are "base 8" digits vs base 10 where 9+1 = 10 so the 1 rolls over. [07:51:12 CEST] <linoobx> yeah [07:51:25 CEST] <linoobx> since you count from 0 [07:51:36 CEST] <tdr> the #s add. 1 = execute, 4 = read, 2 = write. [07:51:42 CEST] <linoobx> I see, but it was the summation of the codes [07:51:43 CEST] <tdr> 0 = no permission [07:52:07 CEST] <tdr> ok, but they add "per place" ... there is no "roll over to the next column" really [07:52:25 CEST] <linoobx> yeah [07:52:25 CEST] <tdr> so first digit 7 is 1+2+4 [07:52:38 CEST] <tdr> 5 = 4+1 for read/execute [07:52:41 CEST] <linoobx> so 1 + 4 + 2 =7, hence the 7 in "755" that he used. [07:52:49 CEST] <linoobx> I see. [07:52:54 CEST] <tdr> for basic permissions yeah thats how it works. [07:56:00 CEST] <linoobx> I'm still confused as to whether I should even use his instructions though, since the Zeranoe script he says to use is not the latest, one of the links he gives is dead ( https://github.com/rdp/ffmpeg-windows-build-helpers/blob/master/patches/min… ) Although, if you go to https://github.com/rdp/ffmpeg-windows-build-helpers/tree/master/patches there is " mingw-w64-build-r22.local" , And... he uses SDL-1.2, even th [07:56:02 CEST] <linoobx> ough I had read repeatedly on forums people telling others that they were having problems because they were using old instructions and needed to upgrade to SDL-2. [07:56:58 CEST] <tdr> ok see which sdl version you have and use the script that matches [07:57:34 CEST] <linoobx> well, from following some other instructions else where I had done, apt-get install libsdl2-dev [07:57:53 CEST] <tdr> the sdl version may effect how any gui part looks etc, it shouldnt change how it operates tho [07:58:22 CEST] <linoobx> oh really? [07:58:40 CEST] <tdr> yeah its just different versions of the toolkit [07:59:08 CEST] <linoobx> hmm.. I thought a new version would have been warrented b/c of major changes. I guess there is nothing to worry about there then. [07:59:20 CEST] <tdr> so if it makes a gui, it may look slightly different and the "guts" may make different calls but those you shouldnt even notice [08:00:26 CEST] <linoobx> Ah, OK. [08:01:17 CEST] <tdr> my system i have both, sdl2 is newer but i cant tell you if there were any gaping holes for the old one [08:03:04 CEST] <linoobx> I know that when I ran apt-mark showinstall libsdl2-2.0-0 it showed up (I had removed libsdl2-dev) and then tried to do ./configure on ffmpeg and it failed [08:03:31 CEST] <linoobx> then i put libsdl2-dev back on, and it worked (but then during make something crashed) [08:03:41 CEST] <tdr> if you're linking against it you'll want the -dev back yeah [08:04:25 CEST] <linoobx> Or, I should say, something crashed, hence I tried ./configure w/o libsdl2-div. [08:04:33 CEST] <linoobx> dev* [08:05:13 CEST] <tdr> if you dont want sdl support, you can prob just disable it with a switch. ./configure --help [08:06:38 CEST] <linoobx> Well, my main goal is to build my own version of ffplay (mess around with the keyboard commands to control the video) but to compile ffplay, you need SDL. [08:07:33 CEST] <dan2wik> Is there a way to read a jsmpeg stream? [08:08:48 CEST] <tdr> linoobx, the -dev package is going to have the headers that will teach it how to speak or call sdl things [08:10:57 CEST] <linoobx> Hmm... makes me wonder what the regular (non-dev) package would be for then... just to provide a .sh (or .dll in Windows-speak) ? [08:11:40 CEST] <tdr> linoobx, the non-dev package is the tools, the -dev package is like the decoder that teaches it the correct way to call the tools [08:13:43 CEST] <tdr> so the header may tell it the correct # of parameters to use, what order, what types of variables for each etc when it says "draw a line" [08:14:55 CEST] <linoobx> Ah, I see. [08:16:37 CEST] <tdr> so you need the headers when you build, it has all the syntax etc [08:18:29 CEST] <linoobx> Just wondering, but things like zlib or vicon would not be needed to play back video (for ffplay), correct? [08:20:25 CEST] <tdr> linoobx, if your build system has those and if you're building static, it should bundle everything you need ... how/what/if depends on how thorough the build script is youre using [08:21:22 CEST] <tdr> otherwise yeah you can use your headers to build but you'd need the runtime libs on the system you execute it on [08:22:31 CEST] <linoobx> Ah, I had been trying to compile before using MSYS2 using settings such as: --disable-encoders --disable-libopenjpeg --disable-iconv --disable-zlib --disable-bzlib [08:23:48 CEST] <tdr> linoobx, if you turn those all off, your end product is going to be pretty limited [08:26:57 CEST] <linoobux> Connection died... [08:28:16 CEST] <linoobux> Seems "linoobx" is still registered though. [08:28:25 CEST] <tdr> it just quit [08:28:35 CEST] <linoobx> Ah. There we go [08:29:10 CEST] <linoobx> As I'd been saying, I had been trying to compile before using MSYS2 using settings such as: --disable-encoders --disable-libopenjpeg --disable-iconv --disable-zlib --disable-bzlib [08:29:26 CEST] <linoobx> My plan was to continue to use such settings, since my interest is still only in building ffplay. [08:30:12 CEST] <JEEB> a few weeks ago disable-autodetect was added if that's why you're setting diasable openjpeg etc [08:30:47 CEST] <linoobx> I assume there shouldn't be any issues with ffplay being built with such settings, correct? [08:32:12 CEST] <JEEB> also zlib I *think* might have been used for the header compression stuff in matroska? [08:32:26 CEST] <linoobx> I had set --disable-libopenjpeg since I saw someone else do that. [08:32:55 CEST] <linoobx> As with the others. [08:33:18 CEST] <JEEB> it's an external library so if you don't have it installed it doesn't matter. but as I noted, just use disable-autodetect to minimize automatically added deps [08:33:47 CEST] <JEEB> then you can just set disable-encoders if you want [08:34:51 CEST] <linoobx> ah... Okay, I hadn't seen that setting [08:35:15 CEST] <JEEB> of course you then probably have to manually add sdl [08:35:23 CEST] <JEEB> with enable-sdl [08:35:44 CEST] <JEEB> but hey, that is explicitly configuring what you want or do not want :p [08:35:57 CEST] <linoobx> ah yeah, good point [08:37:24 CEST] <linoobx> I assume ffplay also would not need postproc or network ? [08:44:58 CEST] <JEEB> postprpc probably not, network is required for network protocols of course [08:45:21 CEST] <JEEB> of course if you want an actual player I would recommend mpv [08:45:32 CEST] <JEEB> since ffplay is just a PoC [08:45:40 CEST] <linoobx> PoC? [08:45:52 CEST] <JEEB> proof of concept [08:45:57 CEST] <linoobx> ah [08:46:36 CEST] <linoobx> Well it was very simplistic, has no interface, making it very similar to a program I had made using Python and pygame (which uses SDL) [08:47:20 CEST] <linoobx> But my little program sufferes from severe performance issues (at start-up) so I decided to make a C/C++ version [08:49:03 CEST] <JEEB> mpv and libmpv are an actual minmalistic embeddable player [08:49:24 CEST] <linoobx> And being able to seek quickly in a video is a "mission-critical" criterion of my program (which was using vlc.dll or some-such, one of FFmpeg's strong points [08:49:51 CEST] <linoobx> hmm [08:50:03 CEST] <linoobx> yes, i had tried downloading the source for mpv [08:50:36 CEST] <JEEB> so if (lib)mpv's license is ok for your use case I would recommend it instead of ffplay [08:51:27 CEST] <linoobx> but found it just as confusing, and after 2 weeks or more of messing around with MSYS2, I gave up and installed VMWare with Debian 9, and now am trying to learn the-one-and-the-way with Linux. [08:52:11 CEST] <linoobx> So far it isn't turning out to be as dead simple as I thought it would be. [08:52:30 CEST] <tdr> linoobx, your end-goal is making windows binaries using linux tho? [08:52:39 CEST] <linoobx> (The process of compiling the program I mean, not learning Linux) [08:52:59 CEST] <linoobx> Learning something is always going to take time... usually. [08:53:06 CEST] <linoobx> Yeah, correct tdr. [08:54:16 CEST] <linoobx> (Also thinking of applying to a job that has knowing Linux as "a plus") [08:54:32 CEST] <bencoh> s/a plus/a must/ [08:54:34 CEST] <linoobx> So this endavor is two-fold.. [08:54:48 CEST] <linoobx> s/a? [08:57:16 CEST] <linoobx> Also teaching myself C/C++ for the past 2 weeks or so.... made the stupid assumption that if I downloaded the FFmpeg-snapshot, unzipped it into a folder then used Code::Blocks to open up "ffplay.c" and hit F9 to "build and run" that it would give me my "ffplay.exe" [08:57:43 CEST] <linoobx> Needless to say.... it did not. :) [08:59:20 CEST] <linoobx> Nor after messing with the files for several days in both Code::Blocks and MSVC. Turns out FFmpeg is not as simple a program as that. [09:14:27 CEST] <JEEB> linoobx: visual studio is the only thing where that is a thing :P (click button, receive build) - but on the other hand the procedure of "Configure" is completely out of scope of that build system [09:15:50 CEST] <linoobx> Hmm, good point, come to think of it, there is no equivalent to ./configure in VS. [09:17:18 CEST] <linoobx> And I couldn't understand why there needed to be a configure script. [09:17:26 CEST] <Mavrik> ffmpeg should migrate to cmake! ;P [09:18:56 CEST] <linoobx> But considering it, the precessence/abscence of ./configure sort of underscores the fundamental differences between Unix/Unix-like and Non-Unix-like (MS and Apple) [09:25:33 CEST] <JEEB> linoobx: well as far as I'm concerned out of mobile space apple uses these same paradigms as well [09:25:57 CEST] <JEEB> anyways, you can call configure from within an IDE, I've once done it myself with Qt Creator to see how it worked with C code :P [09:26:03 CEST] <JEEB> (not FFmpeg but a smaller thing) [09:26:20 CEST] <JEEB> and as long as you can integrate that build system into the IDE's thing the world's your oyster [09:35:00 CEST] <stunts513> im a bit lost. i just transcoded a live stream to an mp4 and apparently there were some hiccups along the way as i have a 2.3gb mp4 thats a little over 3 min long. [09:35:08 CEST] <stunts513> it keeps trying to seek past that but has issues. any ideas? [09:37:08 CEST] <linoobx> <--- never used Apple computers/mobile devices, so I'll have to take your word for it. [09:40:03 CEST] <linoobx> Hmm.. well, a Windows machine running Code::Blocks with the search directories set to a path with the FFmpeg snapshot unzipped in it certainly does not give you the ability to execute a configure script. [09:40:23 CEST] <linoobx> I've learned that much. [11:10:48 CEST] <Nacht> hmmm. i have a feeling my itsoffset options isn't doing anything :/ [11:10:59 CEST] <Nacht> ffmpeg -itsoffset 10.0 -i total.ts -i total.ts -c copy -map 0:1 -map 1:0 -y -hide_banner -f mp4 offset.mp4 [11:11:14 CEST] <Nacht> I put it to an extreme number (10), and it's still the same video [11:18:24 CEST] <Wodjin> Hello everyone, can someone help me with an ffmpeg filtering question? [11:22:04 CEST] <Nacht> Wodjin: Just ask away [11:22:24 CEST] <Wodjin> allrighty :) [11:23:11 CEST] <Wodjin> So, basically im just trying to fade a text in and out (the text has a background), at the moment, what i have is this: [11:23:32 CEST] <Wodjin> drawtext=fontfile=HelveticaNeue.ttf:text='Testing': fontcolor=white: fontsize=40: box=1: boxcolor=black@0.5:boxborderw=5:x=(w-text_w)/2:y=(h-text_h)/2[subtitles]; [11:23:52 CEST] <Wodjin> -- This draws the text exacly as I want it, inside a complex filter, after this i do this: -- [11:24:08 CEST] <Wodjin> [subtitles][0:v] blend=all_expr='A*(if(between(T,1,2),(T-1),0))+B*(1-(if(between(T,1,2),(T-1),0)))'[out] [11:24:43 CEST] <Wodjin> this blend expression correcly fades the text and its background, with a fade duration of 1sec that starts on the 1st second of the video and ends on the 2nd second [11:25:19 CEST] <Wodjin> but now i'm stuck trying to fade the text out, because if I mess with the numbers on that blend expression above the results are not quite what is expected [11:26:31 CEST] <Wodjin> I've tried adding another copy drawtext and doing a simple fade out on that one but I didn't have any success [11:37:50 CEST] <Wodjin> I have also tried something a bit more simple on the fade side, with: [11:37:51 CEST] <Wodjin> [subtitles]fade=t=in:st=2:d=1,fade=t=out:st=3:d=1[out] [11:38:07 CEST] <Wodjin> but it also doesnt work because this fades the entire video and not only the subtitles part [13:20:45 CEST] <Wodjin> https://stackoverflow.com/questions/46423715/ffmpeg-fading-text-with-backgr… >> Question about ffmpeg advanced filters if someone wants to have a look and eventually help me out :) [16:58:40 CEST] <pgorley> hi, since AVIOContext->buffer is freed and malloc'd many times by FFmpeg internally, why does it need to be malloc'd and freed by the user? couldn't FFmpeg take care of that? [18:44:02 CEST] <chuckleplant_> Hi, here's a question I could not get an answer to in chat or mailing list, I've put up a SO bounty if anyone's interested: https://stackoverflow.com/questions/46358285/pts-not-set-after-decoding-h26… [19:13:34 CEST] <braininabat> hello, I'm trying to get an mp4 file getting video from a webcam and audio from a mic through Jack audio. While running ffmpeg everything seems to go well and I get the output file. When watching the file it seems fine, audio and video synced, but after 30 seconds on avg I get 10-15 seconds of distorted audio and while that happens I get to hear double playback of sound, like echoed. After that audio goes back to normal but then [19:13:38 CEST] <braininabat> I have tried several combinations of audio and video codecs, on different containers, but the problem persists. It may be a problem with the input but I can't see anything wrong with it and I can't see any warning message from ffmpeg. Is there anything I am missing or should consider? [19:40:02 CEST] <thebombzen> trying recording just audio and see what happens [20:08:17 CEST] <braininabat> thebombzen I had tested only audio and seemed like it didn't happen. I just tested it again several times and now it keeps happening even when having only audio as input and encoding it to mp3.... so I may think that it is an only audio problem? [20:09:41 CEST] <thebombzen> what happens if you don't encode it lossily and just save it as a flac or something? [20:10:06 CEST] <thebombzen> also, try playing it back with ffplay [20:10:12 CEST] <thebombzen> this can help diagnose if it's a mic problem [20:10:42 CEST] <thebombzen> but first, try saving it as a WAV or a FLAC just to see if it's an issue with the mp3 encoder or with the capture itself [20:11:13 CEST] <thebombzen> er, never mind, I just read your thing again [20:12:12 CEST] <thebombzen> try using ffplay though to play it back rather than ffmpeg, and see if the issue exists in realtime [20:29:07 CEST] <braininabat> thebombzen, it does not happen in realtime, while I am recording I am always hearing my voice through headphones and it is always clear and in good quality. [20:45:08 CEST] <jnollette> hey guys, anyone have any good ffmpeg scripts???? curious about compressing my entire collection into h265, and wanted to automate some things [20:45:50 CEST] <jnollette> I've written a recursive script, that basically works, but you still need to flag the output size and quality [20:46:10 CEST] <dystopia_> you can do it with a for loop [20:47:17 CEST] <jnollette> im using find, grep, and a loop so far.... just wondering if there any any tips for scaling output size depending on input [20:47:39 CEST] <jnollette> "if 1920 wide, 300kbp/s" [20:47:51 CEST] <dystopia_> i never set a bitrate [20:48:08 CEST] <dystopia_> just leave it to it's deafults [20:49:58 CEST] <dystopia_> ffmpeg -i in.ext -vf crop=width:height:left:top -vcodec libx265 -acodec copy out.mkv [20:50:12 CEST] <dystopia_> i don't think force setting a bitrate per resolution is a good idea anyway [20:50:35 CEST] <dystopia_> it would be better to set it per content type, high motion stuff vs low motion stuff [20:50:46 CEST] <dystopia_> but probably better to just leave it to it's defaults [20:51:24 CEST] <redrabbit> compressing my entire collection into h265, >>> how's that remotely worth your time [20:51:31 CEST] <redrabbit> just get a bigger disk [20:52:40 CEST] <redrabbit> and id use CRF quality settings [20:52:44 CEST] <moniker-> hello [20:52:59 CEST] <kepstin> defaults with libx264 and libx265 are crf, iirc [20:53:39 CEST] <moniker-> i have somewhat peculiar issue that i just want to get more understanding is it normal, or not, perhaps bug, etc, it's not directly connected to ffmpeg but to gpu [20:54:56 CEST] <jnollette> redrabbit - im compressing a lot of clips down, like half the size, or sometimes less if I reduce from 1080 > 480 for archive [20:54:57 CEST] <moniker-> i have amd r7 260x gpu with 1 gb video ram, and i'm wondering dxva accelerated videos (lets say h264) do they have limit in resolution/framerate and is it approximately known? [20:55:29 CEST] <redrabbit> i dont see the point tbh [20:55:52 CEST] <jnollette> fair enough [20:56:18 CEST] <moniker-> what happens is that i play any stream on twitch.tv, 1080p60 and it plays fine at 60 fps, but if i play one more 1080p60 then the most i can get is other stream to play at 15-20 fps, which then leads me to conclude that gpu can't hw decode more than lets say 80-90 fps 1080p resolution? [20:56:20 CEST] <dystopia_> i would want 1080p for the archive heh [20:56:24 CEST] <moniker-> is that normal? [20:56:29 CEST] <redrabbit> dystopia_: same [20:56:54 CEST] <thebombzen_> moniker-: hardware decoding is fairly slow for H.264 [20:57:02 CEST] <thebombzen_> you should just decode one in software [20:57:11 CEST] <redrabbit> spending lots of time for inferior quality.. :( [20:57:25 CEST] <moniker-> so would you say it is normal to only be able to achieve hw accelerated decoding for one video and that's it? [20:57:29 CEST] <thebombzen_> the only reason you'd want hardware decoding for H.264 is if you're already using your cpu for something really intensive [20:57:36 CEST] <moniker-> one 1080p60 that is [20:57:49 CEST] <thebombzen_> yes, 60-80 fps is not a surprise [20:57:57 CEST] <thebombzen_> hardware decoding isn't usually worth it for H.264 [20:58:12 CEST] <redrabbit> depends [20:58:30 CEST] <moniker-> because what happens is that most browsers, chrome, firefox have hw accelerated video decoding, so i essentially can't open two streams on twitch because everything begins to stutter and crawl [20:58:37 CEST] <redrabbit> for playback i always prefer HW decoding [20:58:55 CEST] <redrabbit> maybe its card related [20:59:05 CEST] <redrabbit> my 1060 can play lots at the same time [20:59:10 CEST] <moniker-> the only way around is to either disable hw decoding in browser for videos, or to stream to a video player application via livestreamer that will decode in software [20:59:41 CEST] <moniker-> redrabbit can you test by opening two twitch streams and 1080p60 at the same time in browser and making sure they are hw accelerated? [20:59:44 CEST] <moniker-> please [21:00:19 CEST] <moniker-> oh you were referring to card nvdia 1060 [21:00:30 CEST] <moniker-> ye that is much stronger gpu i wouldnt be surprised [21:01:30 CEST] <redrabbit> looks like FF uses cpu on twitch [21:01:35 CEST] <redrabbit> 20% cpu with two streams [21:01:38 CEST] <moniker-> are you on linux? [21:01:42 CEST] <redrabbit> windows [21:01:50 CEST] <moniker-> it should use hw decoding on twitch [21:01:56 CEST] <moniker-> on windows [21:01:59 CEST] <redrabbit> idk. works smooth anyways [21:02:01 CEST] <moniker-> which version? [21:02:22 CEST] <moniker-> it's smooth if it's on cpu, even for me [21:02:29 CEST] <redrabbit> 55.0.3 [21:02:29 CEST] <moniker-> only when hw accelerated it stutters [21:03:10 CEST] <thebombzen_> moniker-: also what's your internet download speed? are you sure you're not stuttering because you can't download 2 streams at once? [21:03:15 CEST] <moniker-> can you make sure that in about:config media.hardware-video-decoding.enabled;true [21:03:28 CEST] <thebombzen_> twitch recently upped their bitrate so it's no longer capped at 3.5 Mbps [21:03:48 CEST] <redrabbit> moniker-: it is true [21:03:48 CEST] <moniker-> it's not internet then it would be buffering not stuttering whole browser and slowing down, my down speed is 120mbit [21:03:53 CEST] <moniker-> weird [21:04:05 CEST] <redrabbit> so.. works i guess [21:04:11 CEST] <moniker-> but you say 20% cpu [21:04:19 CEST] <redrabbit> well. yeah [21:04:30 CEST] <redrabbit> media.hardware-video-decoding.enabled > true [21:04:40 CEST] <redrabbit> anyways [21:04:40 CEST] <moniker-> redrabbit can you duplicate tab for one more stream [21:04:52 CEST] <moniker-> and then duplicate again till you reach a point of slowdown? [21:05:00 CEST] <redrabbit> nope sorry [21:05:01 CEST] <redrabbit> :p [21:05:15 CEST] <moniker-> why not it is easy fast test [21:05:20 CEST] <thebombzen_> moniker-: just enable software decoding [21:05:25 CEST] <thebombzen_> that should fix it [21:05:41 CEST] <iive> moniker-: what kind of hardware acceleration do you mean. aka video acceleration, or browser composotition? [21:05:41 CEST] <moniker-> ye but that's not the point, the point is i would like to have 2 streams in hw decoding [21:05:49 CEST] <moniker-> unless i have confirmation that my gpu can't do it [21:05:58 CEST] <thebombzen_> I am telling you your gpu can't do it [21:06:02 CEST] <moniker-> but it's so hard to get that confirmation [21:06:05 CEST] <thebombzen_> the recommendation here is to usually leave hardware decoding off for H.264 [21:06:38 CEST] <iive> moniker-: have you tried hw-video decoding with mpv ? [21:06:42 CEST] <thebombzen_> [14:57:57] <thebombzen_> hardware decoding isn't usually worth it for H.264 [21:06:42 CEST] <moniker-> do you have insight in how gpu h264 scales between gpus of different generation thebombzen? [21:06:54 CEST] <thebombzen_> "newer = better" what do you want me to say [21:06:54 CEST] <moniker-> gpu h264 decoding [21:07:03 CEST] <moniker-> ye but that's not true insight [21:07:05 CEST] <moniker-> even i know that [21:07:15 CEST] <moniker-> that doesn't tell me anything about how facts really are [21:07:53 CEST] <iive> hw-video decoding uses dedicated silicon in the gpu, not the general shaders [21:08:08 CEST] <moniker-> there must be some kind of test that determines gpu is capable of x amount of streams at 1080p60 [21:08:22 CEST] <iive> moniker-: try with `mpv` [21:08:39 CEST] <iive> aka, dedicated video player [21:09:06 CEST] <moniker-> for example when i read specs for my r7 260x chip i think ive read spec that it can use amd VCE encoding up to oh i dunno like 7-8 streams at the same time [21:09:19 CEST] <dystopia_> my question is why do you want to stream 2 things at once [21:09:28 CEST] <dystopia_> when you can only watch 1 thing at once [21:09:30 CEST] <moniker-> iive i'm using potplayer, is it much different? [21:09:43 CEST] <iive> never heard of potplayer [21:09:46 CEST] <iive> are you on linux? [21:09:50 CEST] <moniker-> nope windows [21:09:50 CEST] <JEEB> it's yet another DShow player [21:09:58 CEST] <JEEB> mpv I can recommend if you like minmalism [21:10:01 CEST] <JEEB> the windows support is <3 [21:10:16 CEST] <moniker-> and what would using mpv reveal to me? [21:10:26 CEST] <JEEB> dunno, just noted it's good :P [21:10:32 CEST] <moniker-> oh ok, i'll try it [21:10:41 CEST] <moniker-> i thought there was some test i could perform [21:10:43 CEST] <JEEB> anyways, even if your hw supports X streams you can't really know without testing [21:10:47 CEST] <JEEB> as in, for encoding [21:10:59 CEST] <JEEB> if you want to test decoding then mpv with --hwdec=dxva2 [21:11:02 CEST] <moniker-> ye but i can probably test that [21:11:14 CEST] <moniker-> except i already read that in specs somewhere [21:11:31 CEST] <moniker-> while i cant read anywhere in any spec about video decoding capability [21:11:32 CEST] <iive> mpv is best at vdpau, but that's linux api, that works on nvidia and radeon [21:11:33 CEST] <JEEB> yea, but you always need to double-check IMHO. as in, does it just stop you from accessing it more [21:11:45 CEST] <JEEB> mpv's DXVA2 support through FFmpeg is pretty good [21:11:48 CEST] <JEEB> I'm using it for HEVC [21:11:50 CEST] <JEEB> because swdec sucks [21:12:14 CEST] <moniker-> potplayer uses ffmpeg to decode almost all videos [21:12:59 CEST] <moniker-> this is how setting for dxva acceleration looks like in potplayer https://i.imgur.com/2qXkuf4.png [21:13:06 CEST] <JEEB> moniker-: one of the mpv maintainers does windows builds of mpv btw https://mpv.srsfckn.biz/ [21:13:14 CEST] <JEEB> (lachs0r @ #mpv) [21:13:59 CEST] <JEEB> anyways, no other way of testing dxva2 decoding other than opening more and more of them and seeing when you either get a crash or just "doesn't play" :) [21:14:09 CEST] <moniker-> and same thing happens in potplayer as it happens in browsers, just to a slightly less degree, can't play 2 twitch streams 1080p60 without slowdown [21:14:10 CEST] <JEEB> (or you "just" get slow-down [21:14:25 CEST] <moniker-> with hw acceleration, with software it's fine ofc [21:14:47 CEST] <moniker-> JEEB i suspected that to be the case [21:14:58 CEST] <JEEB> well, give two mpvs a try with youtube-dl so you can feed it the twitch url. then you get three results that are similar [21:15:00 CEST] <moniker-> but i don't have another gpus to test for comparisons [21:15:12 CEST] <JEEB> --hwdec=dxva2 or --hwdec=dxva2-copy [21:15:34 CEST] <moniker-> have you got a windows download link for mpv? [21:15:38 CEST] <JEEB> I just linked it :) [21:15:44 CEST] <moniker-> oops missed it soz [21:15:44 CEST] <JEEB> "one of the mpv maintainers..." [21:16:05 CEST] <moniker-> 32 or 64 bit shouldnt play a role here right? [21:16:14 CEST] <JEEB> 64bit is recommended unless you're on a 32bit OS [21:16:19 CEST] <JEEB> but shouldn't really affect hwdec [21:16:48 CEST] <JEEB> see comment about youtube-dl so you can feed mpv the twitch URL [21:16:59 CEST] <JEEB> "To play content from various media streaming sites..." [21:17:32 CEST] <JEEB> to enable hwdec you either have to edit a config file or just use the command line (--hwdec=dxva2 or dxva2-copy) [21:17:44 CEST] <moniker-> i have livestreamer perhaps i could use it to stream to it? [21:17:47 CEST] <iive> why not simply play same local file? [21:17:54 CEST] <iive> this would eliminate the network as factor [21:18:03 CEST] <JEEB> sure [21:18:03 CEST] <JEEB> :) [21:18:09 CEST] <moniker-> it's a tool used to streams sites like youtube, twitch to video players that support it [21:18:23 CEST] <JEEB> moniker-: it's just that youtube-dl has integration in mpv so it becomes simpler, that's all [21:18:33 CEST] <JEEB> `mpv "URL"` JustWorks and I like it <3 [21:18:34 CEST] <moniker-> ok [21:19:31 CEST] <JEEB> and yes, I would prefer you test with local files [21:19:46 CEST] <JEEB> since that way you can indeed remove any resemblance of the network being the issue :) [21:20:10 CEST] <JEEB> (you're still left with IO, but generally your hard drives are fast enough - you're not dealing with 900mbps+ lossless stream after all) [21:20:28 CEST] <iive> `member the time when Vista limited network speed when playing audio? [21:20:38 CEST] <JEEB> nope [21:20:51 CEST] <moniker-> are there no settings at all in mpv? [21:21:00 CEST] <JEEB> there's plenty but as I said, it's minimalistic [21:21:10 CEST] <moniker-> can't find any? [21:21:18 CEST] <JEEB> https://mpv.io/manual/master/ [21:21:23 CEST] <JEEB> have the manual [21:21:40 CEST] <moniker-> should it be hw accelerated by default? [21:21:42 CEST] <JEEB> no [21:21:44 CEST] <JEEB> as I said [21:21:51 CEST] <JEEB> mpv --hwdec=dxva2 or dxva2-copy [21:21:56 CEST] <JEEB> (or create a config file) [21:21:59 CEST] <moniker-> sorry im doing 10 things at the moment so i miss [21:22:24 CEST] <JEEB> I would recommend just opening two command prompts for the testing [21:22:29 CEST] <JEEB> and using the command line [21:22:37 CEST] <JEEB> if you end up liking mpv, then you can dive deeper [21:22:58 CEST] <moniker-> dxva2-copy is worse right [21:23:07 CEST] <moniker-> it's copyback ive read something about it being worse [21:23:12 CEST] <moniker-> native is better [21:23:23 CEST] <JEEB> it copies the image once back into RAM so it's slower, but on the other hand it makes sure mpv's video renderer gets untouched video [21:23:36 CEST] <JEEB> mpv's manual actually has a good write-up on hw decoding and caveats [21:23:46 CEST] <JEEB> https://mpv.io/manual/master/#options-hwdec [21:24:00 CEST] <JEEB> scroll down to "Quality reduction with hardware decoding" [21:24:46 CEST] <JEEB> also it seems like d3d11va is preferred to dxva2 now by default :) [21:25:49 CEST] <moniker-> ok thx for all info, plz give me like 30 mins something came up i can't respond immediately [21:32:37 CEST] <iive> JEEB: https://blogs.technet.microsoft.com/markrussinovich/2007/08/26/vista-multim… [22:38:31 CEST] <moniker-> so i tried mpv with hwdec=dxva2-copy since dxva2 throws some error, and playing 2 streams 1080p60 similar thing happens one stream is fine at 60 fps but if i open one more other stream is at 9 fps https://i.imgur.com/UFLNJr0.jpg [22:38:44 CEST] <moniker-> dunno why dxva2 throws error [22:39:03 CEST] <moniker-> [vo/opengl/dxva2-egl] Failed to create EGL surface [22:39:19 CEST] <moniker-> i guess it uses opengl instead of dx [22:40:00 CEST] <moniker-> in any case, this would be a final test to conclude that it is limitation of gpu that it can't play more than one stream 1080p60? [22:40:33 CEST] <moniker-> i'm wondering does having 1gb video ram plays a role here? [22:41:07 CEST] <JEEB> the real final one would be without the network stuff but if you're 100% sure that's not a problem then SureFine [22:41:27 CEST] <JEEB> btw, try with d3d11va [22:41:30 CEST] <JEEB> instead of dxva2 [22:41:58 CEST] <JEEB> 1GiB of video RAM... not sure, you'd have to check the actual VRAM usage on the card to see that [22:42:04 CEST] <JEEB> quite likely not, though [22:42:33 CEST] <JEEB> it's more likely that the ASIC can't do it (or the drivers, but it all ends up in the same ballpark for you since you can't fix the drivers, either) [22:42:50 CEST] <moniker-> same, one stream at 60 fps and other stream now at 3 fps [22:43:29 CEST] <moniker-> well this was important to me to verify it's not some kind of bug [22:43:40 CEST] <moniker-> i can accept if it's limitation of card [22:44:04 CEST] <moniker-> JEEB what about memory, that shouldn't play a role right? [22:44:38 CEST] <JEEB> well if you're not going anywhere close to your limits that should be unrelated [22:45:38 CEST] <moniker-> i seriously doubt a video would require 500 mb video ram [22:45:56 CEST] <JEEB> well you don't have to think, you should be able to know [22:46:00 CEST] <JEEB> with procexp or something else [22:46:02 CEST] <JEEB> per-process VRAM usage [22:49:02 CEST] <moniker-> committed gpu memory around 100mb https://i.imgur.com/2iS0cA5.png [22:49:41 CEST] <JEEB> yea [22:49:48 CEST] <JEEB> peanuts, basically :P [22:50:07 CEST] <moniker-> at least now i have idea how much gpu memory 1080p60 stream takes [22:50:28 CEST] <moniker-> see this is the type of insight im looking for, thx for all your suggestions [22:50:38 CEST] <Hopper__> surprisingly low for 60fps. [22:50:49 CEST] <JEEB> the frame rate doesn't really matter there, since you usually always have N textures [22:50:57 CEST] <JEEB> and you get new ones from the decoder [22:51:07 CEST] <JEEB> and/or memcpy and recycle with -copy hwaccels [22:51:31 CEST] <JEEB> basically, frame rate doesn't affect as much the rendering chain [22:51:41 CEST] <JEEB> memory usage wise, that is [22:51:55 CEST] <JEEB> since your vsync is always triple or whatever buffered [22:52:35 CEST] <moniker-> btw does vsync got anything remotely to do with it? [22:52:50 CEST] <moniker-> with possible performance? [22:53:45 CEST] <JEEB> of course, but I would say it doesn't affect like that. otherwise I wouldn't be able to play multiple things with software either :P [22:57:12 CEST] <moniker-> now if i could get someone to test some of newer cards and their limits how mnay such streams can they play hw accelerated [22:57:23 CEST] <moniker-> before slowdowns [22:57:32 CEST] <moniker-> to get some kind of perspective [22:58:32 CEST] <JEEB> lol [22:58:38 CEST] <moniker-> one more question, i keep hearing about LAV filters, are they on par/better/worse than ffmpeg [22:58:48 CEST] <durandal_1707> worse [22:58:54 CEST] <JEEB> LAV utilizes FFmpeg's libraries underneath [22:58:57 CEST] <moniker-> in quality/performance/all ? [22:59:04 CEST] <JEEB> it's a DShow filter built around FFmpeg [22:59:13 CEST] <JEEB> or well, filters [22:59:18 CEST] <JEEB> Video|Audio|Splitter [22:59:37 CEST] <durandal_1707> its windows shit [22:59:57 CEST] <moniker-> well ye, im on windows [23:01:09 CEST] <kepstin> if you have an application written using directshow apis, and want it to be able to handle a few formats through ffmpeg that it couldn't handle otherwise, lav filters are helpful. [23:03:29 CEST] <JEEB> moniker-: basically LAV is based on top of FFmpeg so you get the same thing with the same caveats. plus DShow means that those filters only play that specific role in the playback chain [23:03:38 CEST] <JEEB> you then have some renderer or whatever connected to them [23:03:43 CEST] <moniker-> kk [23:03:43 CEST] <JEEB> that is up to your DShow playback chain [23:06:09 CEST] <moniker-> do you see this format, rendering, standards mess ever getting simplified in the near future or will it remain such mess and possibly even get more complicated? [23:07:19 CEST] <JEEB> moniker-: I just tried running two instances of a 50Hz 2160p sample at the same time and while the rendering was off (I was getting 8bit output for a 10bit clip so it was doing stuff behind my back), but it works fine. nvidia in this case [23:07:40 CEST] <moniker-> which card [23:07:44 CEST] <kepstin> once we get star trek level computers that can receive an arbitrary alien video signal and decode & format it correctly, then I guess we're done? [23:07:46 CEST] <moniker-> and can i download that sample? [23:08:08 CEST] <JEEB> sure, google "TravelXP_4K_HDR_HLG" [23:08:21 CEST] <moniker-> ah but 4k isn't hw accelerated on my gpu [23:08:41 CEST] <moniker-> i actually need 1080p samples preferably at 60 fps that's why i use streams on twitch [23:08:58 CEST] <JEEB> anyways, the exact model doesn't really matter to be honest, rather the ASIC [23:09:01 CEST] <JEEB> at least with nvidia [23:09:09 CEST] <moniker-> i'd still like to know which card you got [23:09:29 CEST] <JEEB> GTX 1080, which actually has an older ASIC than 1050 I think [23:09:35 CEST] <JEEB> (not sure about 1030's ASIC) [23:09:49 CEST] <JEEB> ASICs are the dedicated hardware that do the decoding [23:09:51 CEST] <moniker-> can you try 3 or 4 videos at the same time to see where is the limit? [23:10:02 CEST] <JEEB> I don't really care so I won't :P [23:10:08 CEST] <moniker-> ok XD [23:13:06 CEST] <JEEB> also you can just download the twitch thing with youtube-dl or something [23:13:09 CEST] <JEEB> and have a local sample [23:13:14 CEST] <JEEB> if that's what you want [23:18:32 CEST] <furq> if the decoder is part of the nvenc asic then it doesn't exist on the 1030 [23:19:27 CEST] <q66> JEEB: i think the older asic thing was for 980, not 1080 [23:19:56 CEST] <q66> 980 vs 960 i mean [23:20:47 CEST] <JEEB> furq: it definitely does exist even on the lower end ones so probably different pieces of hardware [23:21:05 CEST] <q66> it has to, all the cards have decoding [23:21:23 CEST] <furq> makes sense [23:22:02 CEST] <q66> encoding is a separate matter though [23:22:07 CEST] <q66> gt == no nvenc, gtx == has nvenc [23:22:11 CEST] <furq> right [23:23:14 CEST] <furq> GP107 can apparently decode 10-bit vp9 and GP104 can't [23:23:47 CEST] <furq> so i guess it is an older asic on the 1080 [23:24:28 CEST] <furq> i wouldn't be surprised if it performed identically for formats people actually use though [23:28:16 CEST] <redrabbit> nvenc is good with the right settings [23:28:22 CEST] <q66> furq: ah, right [23:28:52 CEST] <q66> furq: that said, it's kind of irrelevant [23:29:03 CEST] <q66> something this high end won't be in a PC with a shitty CPU [23:29:16 CEST] <q66> most likely CPU in that kinda machine can decode anything you throw at it in real time [23:29:21 CEST] <redrabbit> Cmd=-analyzeduration {analyzeduration} {offset} {realtime} -i "{infile}" -f mpegts -pat_period 0.2 -c:v h264_nvenc -b:v 3500k -maxrate 3500k -rc vbr_2pass -rc-lookahead 32 -g 50 {framerate} -map 0:v:0 -map 0:a:0 -s 1920x1080 -preset slow -c:a copy -async 1 -y "{outfile}" [23:29:34 CEST] <q66> especially vp9 which is fast compared to hevc [23:29:51 CEST] <redrabbit> this is the good stuff: -preset slow -rc vbr_2pass -rc-lookahead 32 [23:30:16 CEST] <redrabbit> helps with motion heavy content [23:31:46 CEST] <redrabbit> for real time i wont bother with x264 exept for low bitrate situations [23:31:59 CEST] <furq> well yeah realtime is the whole point of nvenc [23:32:33 CEST] <furq> it's acceptably good at that if you have a bit of bandwidth to spare [23:32:34 CEST] <moniker-> q66 the issue isn't whether cpu can decode it, most certainly can, even multiple streams, the issue is if you have gpu card that can hw decode it why use 30-40 or even more cpu % utilization on multiple high res streams when you don't have to [23:32:41 CEST] <redrabbit> well with theses settings the difference at high bitrate starts to be less perceivable [23:32:50 CEST] <redrabbit> vs x264 [23:32:53 CEST] <furq> well yeah anything looks equally good if you throw enough rate at it [23:33:01 CEST] <moniker-> i don't want to run in the background multiple streams on cpu and have 40% cpu utilization [23:33:15 CEST] <redrabbit> i mean comparing vs same bitrate x264 [23:33:32 CEST] <furq> right [23:33:43 CEST] <furq> 10mbps 480p30 nvenc is going to look as good as anything else at 10mbit [23:33:58 CEST] <redrabbit> i mean 5mbps 1080p [23:35:00 CEST] <redrabbit> -rc-lookahead 32 allows better bitrate distribution [23:35:49 CEST] <redrabbit> really helps VS defaults were motion heavy scenes were youd previously see lots of artifacts [23:37:26 CEST] <moniker-> is this quality comparison between x265 and x264 at low bitrate 400kbps 1080p true? https://x265.com/hevc-video-files/ [23:37:46 CEST] <moniker-> or did they mess up x264 encoding on purpose [23:37:48 CEST] <redrabbit> i mean if you use nvenc -preset slow -rc vbr_2pass -rc-lookahead 32 is a must try [23:38:21 CEST] <furq> moniker-: it's 1080p at 400kbps, what do you expect [23:38:35 CEST] <moniker-> i didn't expect h265 to be so clean [23:38:44 CEST] <moniker-> or should i say i didn't expect such difference [23:38:57 CEST] <redrabbit> they are trolling you though [23:39:06 CEST] <furq> yeah it's a bit worthless without the source [23:39:17 CEST] <furq> they obviously don't want to show the source because you'd see how much detail is lost in the x265 pic [23:39:25 CEST] <redrabbit> of course hevc looks a bit better [23:39:40 CEST] <moniker-> ye but the point isn't how much detail is lost compared to source the point is which encoder did it better [23:39:54 CEST] <furq> that sort of is the entire point of video encoding [23:39:55 CEST] <redrabbit> but to be realistic its only 30% better for the same bitrate [23:40:08 CEST] <furq> also yeah we don't know what x264 settings were used [23:40:10 CEST] <moniker-> i already knew about hevc quality but didn't know it was that much difference [23:40:22 CEST] <furq> i mean [23:40:29 CEST] <moniker-> maybe it's deliberately made bad h264 encode [23:40:32 CEST] <furq> i'd probably do my own tests rather than looking at a few screenshots on the x265 site [23:40:39 CEST] <redrabbit> on the pics its not an honest comparison [23:40:44 CEST] <redrabbit> just do encodes yourself [23:40:45 CEST] <moniker-> you also have videos to download if you follow links [23:40:58 CEST] <redrabbit> and see for yourself [23:40:58 CEST] <moniker-> im not sure about the source video though [23:41:18 CEST] <furq> huh [23:41:24 CEST] <furq> i actually can't complain about those x264 settings [23:41:34 CEST] <furq> that still isn't a very realistic usage scenario though [23:42:59 CEST] <furq> the x265 sample also still looks pretty bad in motion [23:44:57 CEST] <redrabbit> when you see how much more ressources a proper hevc encode needs vs proper avc [23:45:51 CEST] <redrabbit> its good when you have to deal with weak internet speeds and want to stream video [23:46:09 CEST] <redrabbit> like this summer i had to deal with 800kbps link [23:46:16 CEST] <redrabbit> (free hotspot) [23:46:38 CEST] <redrabbit> well, in that case hevc was quite useful [23:47:10 CEST] <horox> I have another question regarding video files played with wrong color tint. FFMPEG has support for Magic Lantern .mlv files for quite a while now, but they are all played back with a greenish color tint - Should I file a bug? [23:47:35 CEST] <horox> ups [23:48:05 CEST] <horox> that should be: hello, FFMPEG has support for Magic Lantern .mlv files for quite a while now, but they are all played back with a greenish color tint - Should I file a bug? [23:48:26 CEST] <durandal_1707> yes, with samples [23:48:29 CEST] <JEEB> depends on if it's a decoding issue or a colorspace issue. can you post a `ffprobe file.mlv` output? [23:48:36 CEST] <JEEB> in a pastebin that is [23:48:41 CEST] <JEEB> or a ticket with a sample, yes [23:48:41 CEST] <JEEB> :) [23:52:26 CEST] <horox> one moment [23:53:09 CEST] <redrabbit> so low bitrate situations is where hevc gets really interesting, no wonder they picked up 400k [23:53:34 CEST] <redrabbit> i watched the samples [23:53:50 CEST] <redrabbit> that's kind of like what TV looked on my free wifi [23:54:11 CEST] <JEEB> yes, I've found x265 to have been better at very low bit rates where you will in either case have artifacts galore of some sort [23:54:21 CEST] <JEEB> of course it also takes a crapload of time more [23:55:02 CEST] <redrabbit> with the right resolution you dont see much artifacts, its more of an "sd" look though [23:55:25 CEST] <JEEB> I mean yes, it just blurs the hell away with PSNR-helping tools :D [23:56:08 CEST] <JEEB> you can kind of get a similar look from x264 by pushing out deblock higher etc [23:56:21 CEST] <JEEB> but IIRC x265 is better in that niche [23:56:39 CEST] <JEEB> just because those specific tools don't have to be psychovisually optimized [23:56:40 CEST] <JEEB> lol [23:58:19 CEST] <redrabbit> Cmd=-analyzeduration {analyzeduration} {offset} {realtime} -i "{infile}" -f mpegts -pat_period 0.2 -vcodec libx264 -bufsize 1400k -maxrate 700k -crf 24 -g 50 {framerate} -map 0:v:0 -map 0:a:0 -s 640x360 -preset veryslow -c:a copy -ac 1 -async 1 -y "{outfile}" << how would you improve on that one [23:58:40 CEST] <redrabbit> "pushing out deblock higher" [23:58:46 CEST] <redrabbit> just curious to try for the lols [23:59:23 CEST] <JEEB> trying to remember if -tune psnr could be a good alternative if you're looking for that "BLUR ME MORE!" look [23:59:34 CEST] <JEEB> -x264-params is the way you set specific libx264 API settings [23:59:39 CEST] <JEEB> in a key=value:key=value way [00:00:00 CEST] --- Wed Sep 27 2017

1 0

ffmpeg-devel.log.20170925
by burek 26 Sep '17

26 Sep '17

[03:02:45 CEST] <atomnuker> rcombs: ping [03:45:58 CEST] <rcombs> atomnuker: pushed on my gh fork; I forget if there's anything left to be done [07:17:19 CEST] <Ahti333> michaelni could you take a quick look at https://github.com/ahti/FFmpeg/commit/8b5f83021caf14c230727eeeff387c970b85b… and let me know wether this is an appropriate way to resolve https://trac.ffmpeg.org/ticket/6558 ? [09:19:31 CEST] <nevcairiel> seems fine to me Ahti333, you should sent it to the mailing list [10:57:29 CEST] <michaelni> Ahti333, id say post the patch to the ML [11:25:52 CEST] <JEEB> did lavu have a function to produce a timestamp from int64_t+timebase? [11:26:13 CEST] <JEEB> (or from a double since we have the int64_t+timebase => double thing at least) [11:26:54 CEST] <JEEB> as in, speaking of the timestamp string that a lot of subtitle formats use ("00:00:00.000") [11:29:51 CEST] <nevcairiel> you can always use rescale for that [11:31:15 CEST] <nevcairiel> oh you want a string timestamp? [11:33:31 CEST] <nevcairiel> apparently we dont, at least srtenc does it manually [11:38:13 CEST] <JEEB> yea, I checked there :) [11:38:26 CEST] <JEEB> ffprobe also used its own thing [11:38:37 CEST] <JEEB> so ok, no such thing yet [12:13:48 CEST] <cone-542> ffmpeg 03Paul B Mahol 07master:5d07275529f6: avfilter/af_headphone: increase max ir length [12:24:40 CEST] <cone-542> ffmpeg 03Michael Niedermayer 07release/3.1:7333799de5fc: avcodec/pngdec: Clean up on av_frame_ref() failure [12:24:41 CEST] <cone-542> ffmpeg 03Michael Niedermayer 07release/3.1:bfb7744aaffa: avcodec/svq3: Fix overflow in svq3_add_idct_c() [12:24:42 CEST] <cone-542> ffmpeg 03Michael Niedermayer 07release/3.1:b9f0979e16c0: avcodec/ffv1dec: Fix integer overflow in read_quant_table() [12:24:43 CEST] <cone-542> ffmpeg 03Michael Niedermayer 07release/3.1:743354358b31: avcodec/dirac_dwt: Fix integer overflow in COMPOSE_FIDELITYi*() [12:24:44 CEST] <cone-542> ffmpeg 03Michael Niedermayer 07release/3.1:c7ad616ddaaa: avcodec/takdec: Fix integer overflows in decode_subframe() [12:24:45 CEST] <cone-542> ffmpeg 03Michael Niedermayer 07release/3.1:dc5240a4d797: avcodec/proresdec2: Check bits in DECODE_CODEWORD(), fixes invalid shift [12:24:46 CEST] <cone-542> ffmpeg 03Michael Niedermayer 07release/3.1:27505de3b9fe: avcodec/takdec: Fix integer overflow in decode_lpc() [12:24:47 CEST] <cone-542> ffmpeg 03Michael Niedermayer 07release/3.1:38c1df15c6a3: Update for 3.1.11 [17:16:06 CEST] <LongWork> Could anyone clarify a few things around SDR / HDR / HDR10 for me ? [17:16:38 CEST] <LongWork> I have a device which has two settings for colorspaces and color management. And the more i read about those on various articles , the more i get confused [17:17:48 CEST] <LongWork> seems like i have a setting calles EOTF which has the following options SDR / HDR / HDR10 [17:18:25 CEST] <LongWork> i suppose that 10 bits videos should use the HDR10, but then i have no idea on how to know from an AVFrame if it's SDR or HDR [17:38:11 CEST] <LongWork> it's kind of fuzzy for me what can be deduced for TRC / colorspace and colorprimaries [17:50:23 CEST] <iive> my guess, not based on any knowladge or facts, is that these are 8/9/10 bits [17:52:02 CEST] <LongWork> from what i have read it can be more complicated :) [17:55:59 CEST] <wm4> iive: no [17:56:24 CEST] <wm4> HDR usually requires 10 bit or so to avoid banding, that's all [17:56:43 CEST] <wm4> LongWork: generally, you need to export the correct colorspace [17:57:10 CEST] <wm4> AVCOL_SPC_BT2020_NCL would usually be HDR [17:57:19 CEST] <wm4> you might also have to export a bunch of other metadata [17:58:00 CEST] <wm4> potentially parts of AV_FRAME_DATA_MASTERING_DISPLAY_METADATA and AV_FRAME_DATA_CONTENT_LIGHT_LEVEL [17:58:06 CEST] <LongWork> is HDR necessary 10 bits ? [17:58:22 CEST] <wm4> I suppose in theory it could be applied to 8 bits... [17:58:42 CEST] <wm4> possible, but doesn't make too much sense I guess [17:58:53 CEST] <wm4> on the other hand, 10 bit does not necessarily mean the file uses HDR [17:59:02 CEST] <iive> LongWork: is the device capture (camera) or playback (monitor) ? [17:59:08 CEST] <LongWork> because i have two settings available on the hardware, one is called EOTF which can be SDR / HDR or HDR10, the other one relates to colorspace [17:59:41 CEST] <LongWork> and i'm trying to determine how to adjust those two settings from ffmpeg TRC / colorspace and Primaries [17:59:51 CEST] <wm4> iive: he is working with a decoder [18:00:57 CEST] <wm4> LongWork: right, I think that corresponds to AVColorTransferCharacteristic [18:01:33 CEST] <wm4> yeah, I think Bt.2020 colorspace does not mean yet that it's HDR [18:01:47 CEST] <wm4> but if the transfer function is Bt.2020, it is HDR [18:01:50 CEST] <wm4> probably [18:02:38 CEST] <wm4> and apparently there are different bitstream values depending on bitness: AVCOL_TRC_BT2020_10 and AVCOL_TRC_BT2020_12 [18:02:40 CEST] <wm4> for whatever reason [18:03:46 CEST] <wm4> I might be talking non-sense, I'm not all that familiar with those [18:04:01 CEST] <LongWork> that's at least some light on all this mess :) [18:04:33 CEST] <wm4> digging a bit deeper BT2020 TRC is still not HDR, but AVCOL_TRC_SMPTEST2084 is [18:04:59 CEST] <wm4> I'd just make sure that your hw decoder wrapper returns the same parameters as sw decoding [18:05:49 CEST] <LongWork> yeah it seems to be the case, i have the same enums as ffmpeg for TRC [18:10:11 CEST] <wm4> oh right, they just stole that without respecting copyright [18:10:40 CEST] <wm4> then what is that stuff you talked about? [18:12:37 CEST] <LongWork> wm4 : well i need to set the colorspace info to the display system trhru drm [18:12:50 CEST] <LongWork> that is possible with setting DRM plane properties [18:13:09 CEST] <LongWork> there are two properties there to adjust color stuff [18:13:22 CEST] <LongWork> one is called EOTF and can be SDR/ HDR / HDR10 [18:13:29 CEST] <wm4> oh [18:13:52 CEST] <wm4> so that's completely different from what I thought you're talking about, oops [18:14:08 CEST] <LongWork> second is called COLOR_SPACE and can be one of the following values : https://github.com/torvalds/linux/blob/master/include/uapi/linux/videodev2.… [18:14:32 CEST] <LongWork> so the question is basically, how do i match the TRC & colorspace info i'm getting to those settings [18:15:10 CEST] <wm4> I have not the slightest clue [18:15:27 CEST] <wm4> maybe you could ask hanna, if you explain the choices which DRM offers well enough [18:15:45 CEST] <hanna> context? [18:16:26 CEST] <hanna> LongWork: `HDR10` might refer to the HDR10 Media Profile [18:16:39 CEST] <hanna> Which is a metadata thing only [18:16:45 CEST] <hanna> and shouldn't be confused with the bit depth... [18:17:13 CEST] <hanna> BT.2020 also has nothing to do with HDR. HDR itself is a meaningless term, also [18:17:21 CEST] <LongWork> hmmm [18:17:23 CEST] <hanna> The only underlying question is which TRC you use: PQ or HLG; and with how many bits [18:18:22 CEST] <hanna> `SDR`, `HDR` and `HDR10` are completely meaningless descriptions of EOTFs [18:18:27 CEST] <JEEB> yea [18:18:34 CEST] <LongWork> well all i have in input is the amount of bits in the video 8 /10, and the usual info from ffmpeg TRC / primaries / colorspace [18:18:50 CEST] <hanna> I can only vaguely guess that they're supposed to map to either `BT.1886` or `SRGB` for `SDR`, and HDR / HDR10 probably both map to PQ but the latter also takes mastering metadata into account? [18:19:01 CEST] <hanna> but who knows [18:19:05 CEST] <LongWork> then the "settings" available thru drm on the hardware are that EOTF and thte colorspace properties [18:19:15 CEST] <JEEB> HDR says nothing, HDR10 usually is BT.2020 + SMPTE ST.2084 with the mastering metadata (and 10bit HEVC) [18:19:32 CEST] <JEEB> since HDR10 is what UHD BD uses :P [18:19:43 CEST] <JEEB> HDR10+ is the dynamic metadata bullshit [18:20:28 CEST] <hanna> also lol are those enums supposed to describe both the primaries and the transfer? [18:20:46 CEST] <hanna> `EOTF` is normally just the transfer [18:21:00 CEST] <JEEB> yea [18:21:03 CEST] <LongWork> yeah that's what i was given [18:21:13 CEST] <hanna> so BT.2020 would be irrelevant [18:21:21 CEST] <JEEB> which API are we talking about? [18:21:24 CEST] <hanna> (BT.2020 only concerns the colorspace, not the EOTF) [18:21:29 CEST] <JEEB> I just know what "HDR10" means [18:21:41 CEST] <LongWork> available values for EOTF are : [18:21:42 CEST] <LongWork> * TRADITIONAL_GAMMA_SDR = 0, [18:21:42 CEST] <LongWork> * TRADITIONAL_GAMMA_HDR, [18:21:42 CEST] <LongWork> * SMPTE_ST2084,/* HDR10*/ [18:21:47 CEST] <hanna> (although BT.2020 *does* specify an OETF, the BT.2020 OETF, which is a counter-part to BT.1886 i.e. `SDR`) [18:21:57 CEST] <hanna> traditional gamma HDR [18:22:08 CEST] <hanna> oh so it's BT.1886 but allows values above 1.0? [18:22:12 CEST] <hanna> what a confusing thing to call HDR [18:22:25 CEST] <hanna> although traditional gamma is also ambiguous as fuck [18:22:31 CEST] <hanna> is it PPC? BT.1886? sRGB? [18:22:59 CEST] <LongWork> all that crap is chinese for me :) [18:23:33 CEST] <LongWork> i was just hoping to get an idea on what the matrix would be between TRC & EOTF [18:23:56 CEST] <LongWork> then i suppose that colorspace stuff should more or less match [18:24:29 CEST] <wm4> where are the docs for that? [18:24:34 CEST] <wm4> or is that kernel-style NO DOCS [18:25:01 CEST] <LongWork> the latter :) it's not even in kernel yet, just landed as a patch for testing in the mail [18:25:54 CEST] <hanna> context? [18:25:57 CEST] <hanna> I still have no clue wtf this is about [18:26:17 CEST] <hanna> oh V4L2 [18:26:26 CEST] <LongWork> not quite [18:26:27 CEST] <hanna> What is V4L2 anyway? just for capture cards and shit? [18:26:35 CEST] <wm4> no I think this is DRM [18:26:38 CEST] <hanna> hmm [18:27:08 CEST] <wm4> LongWork works on the rockchip decoder wrapper, whose support lib conveniently steals ffmpeg's code for this, so no problem [18:27:23 CEST] <wm4> LongWork: so, link to patch? [18:27:23 CEST] <LongWork> yeah i have the media info fine [18:27:32 CEST] <LongWork> sure [18:27:35 CEST] <wm4> MediaInfo? [18:27:52 CEST] <LongWork> https://patchwork.ffmpeg.org/patch/5250/ [18:27:58 CEST] <LongWork> this is the patch [18:28:15 CEST] <BtbN> patchwork still broken/down :( [18:28:24 CEST] <LongWork> but that's not where the issue is, with that patch i get the media information as ffmpeg [18:28:40 CEST] <wm4> LongWork: I mean the DRM one [18:29:10 CEST] <LongWork> from that AVFrame info in which i get TRC / colorspace & primaries i need to pass that info to the display system so that gamma is handled properly by the display [18:29:58 CEST] <LongWork> I use DRM for dispalying, and the only way to set color information is to define two properties in the DRM plane i'm sending to display [18:30:17 CEST] <LongWork> one of these props is EOTF as mentioned above with 3 available values [18:30:41 CEST] <LongWork> the other one is COLOR_SPACE which can be set to the values of the V4L2 enums above [18:31:17 CEST] <LongWork> so I wanted to know how to select the right EOTF / COLOR_SPACE values from ffmpeg TRC / colorspace / primaries [18:31:43 CEST] <LongWork> from what i got ffmpeg TRC should match EOTF, and ffmpeg colorspace should match COLOR_SPACE [18:32:28 CEST] <LongWork> now the question is that ffmpeg TRC has like https://github.com/FFmpeg/FFmpeg/blob/ec1573f879b1974050c68fdcb69b654e500ef… a couple values which i need to turn into 3 possible settings [18:32:55 CEST] <LongWork> the COLOR_SPACE one should be matching more what ffmpeg has in it's colorspace info [18:33:04 CEST] <wm4> LongWork: the ffmpeg ones are pretty much those from the codec bitstream [18:33:52 CEST] <LongWork> i suppose AVCOL_TRC_SMPTE2084 should patch their * SMPTE_ST2084,/* HDR10*/ [18:34:16 CEST] <LongWork> but i'm not sure about the other two "TRADITIONAL_GAMMA_SDR" and "TRADITIONAL_GAMMA_HDR" [18:35:06 CEST] <LongWork> so was wondering if someone could shed some light on what could be matching any of those, should there be any sense in that :) [18:35:50 CEST] <wm4> not sure why you're asking that - the author of the kernel API should know (and in a sane world, the kernel API would document this properly) [18:35:59 CEST] <wm4> or, well, DRM API [18:36:26 CEST] <LongWork> DRM is sorrowfully not very well documented [18:36:42 CEST] <LongWork> and even worse there is no standard for these property as they are not part of legacy API [18:37:09 CEST] <hanna> TRADITIONAL_GAMMA_* could mean literally anything, and I don't think ffmpeg implies any explicit clipping semantics on either of those [18:38:58 CEST] <LongWork> yeah was afraid of that :) [18:39:13 CEST] <LongWork> ok i'll get back to them for some further clarification then [18:39:28 CEST] <hanna> keep in mind that DRM probably has different goals here, or something [18:39:47 CEST] <hanna> Actually DRM doesn't concern itself with compositing at all, right? [18:39:55 CEST] <hanna> It assumes it gets a single image from whatever's feeding it? [18:39:56 CEST] <wm4> actually it does [18:40:02 CEST] <hanna> hmm [18:40:04 CEST] <wm4> it gives you access to the hardware compositor [18:40:13 CEST] <hanna> What does hardware compositor mean? [18:40:27 CEST] <wm4> it means the GPU magically composites multiple layer [18:40:30 CEST] <jkqxz> It represents the scanout planes and nothing else. If compositing is supported there then it's exposed, otherwise not. [18:40:31 CEST] <hanna> ah [18:40:42 CEST] <hanna> Isn't the scanout plane shit for stereo vision and whatnot [18:40:45 CEST] <hanna> or maybe I'm confused [18:40:55 CEST] <wm4> think of it as hardware overlays [18:41:20 CEST] <LongWork> most of the tiem on embedded, the compsiting device is not the GPU, they have some video processing unit that will do that job. [18:41:21 CEST] <jkqxz> There is usually a cursor overlay at least. [18:41:38 CEST] <LongWork> so they have a primary plane, a few overlays and a cursor plane [18:41:53 CEST] <hanna> in any case, TRADITIONAL_GAMMA_SDR probably means to whatever we were doing before, TRADITIONAL_GAMMA_HDR probably maps to whatever we were doing before but allow out-of-range values which will get signalled to the display in god knows what manner, and HDR10 probably means signal to the display that the content is to be interpreted as PQ, with attached metadata [18:42:03 CEST] <hanna> maybe it translates TRADITIONAL_GAMMA_HDR to PQ internally [18:42:11 CEST] <LongWork> you will draw to these planes with GPU but the end cmpositing of such planes is done by another hardware than GPU [18:42:12 CEST] <hanna> because I don't believe display connections have a standard for HDR that isn't PQ? [18:42:34 CEST] <hanna> unless this is the xvYCC shit or something [18:42:48 CEST] <hanna> scRGB I mean [18:42:56 CEST] <jkqxz> LongWork: Where do you pass this information to the DRM modesetting API? Is it a plane or CRTC property somehow? [18:43:08 CEST] <hanna> I mean technically scRGB is meant for wide gamut and not HDR but I don't even know what the difference between the two is even more (both are just out-of-range values...) [18:43:27 CEST] <hanna> ah Large positive numbers allow high dynamic range images to be represented, though the range is inferior to that of some other high dynamic range formats such as OpenEXR.[1] [18:43:31 CEST] <LongWork> jkqxz: you need the Atomic API and set the properties on the drmPlane [18:43:34 CEST] <hanna> seems like out-of-range = negative values, not just positive [18:43:42 CEST] <hanna> maybe we need support for negative value tone-mapping in mpv [18:44:03 CEST] Action: hanna hides somewhere wm4 can't find him [18:44:26 CEST] <LongWork> jkqxz: FYI (still WIP, don't bother about the mess) https://github.com/LongChair/mpv/commit/11f531265b0043446ed5a7cd19863a7afc0… [18:44:34 CEST] <hanna> seems like HDMI can do xvYCC 4:4:4 [18:44:48 CEST] <LongWork> jkqxz: would be done in the same way as those : https://github.com/LongChair/mpv/commit/11f531265b0043446ed5a7cd19863a7afc0… [18:44:54 CEST] <hanna> but god knows what the display hardware will actually do with this [18:45:04 CEST] <hanna> it's all fucked [18:45:21 CEST] <LongWork> yeah on those devices, what the call VOP (scaler, compositor), can also handle the colorspace conversion [18:47:08 CEST] <LongWork> jkqxz: the bad thing about that is that there are a few legacy properties that are in DRM standards (the ones in the code). but there is no standard for colorspace stuff, so basically each vendor would have it's own props... which is rather bad [18:47:16 CEST] <jkqxz> Hehe, KMS atomic <3. (Clearest API evar.) [18:47:52 CEST] <LongWork> yeah ... but on such devices, there is no performance without drm .. :/ [18:47:57 CEST] <jkqxz> I don't see any properties for this on Rockchip (<http://sprunge.us/RajG>). This needs some exciting new kernel? [18:48:49 CEST] <LongWork> nope the ones in the code i linked are DRM standard, they are there :) [18:49:17 CEST] <jkqxz> The colourspace ones, I mean.# [18:49:44 CEST] <LongWork> oh yeah colorspace ones are not in kernel yet :) [18:50:16 CEST] <LongWork> i get some uncooked patches from RK usually :p [18:50:31 CEST] <LongWork> then do the guinea pig and then they are pushed :p [18:50:49 CEST] <LongWork> jkqxz: btw did you test the latest ffmpeg decoder patch ? [18:50:51 CEST] <jkqxz> (I looked at this before on Rockchip to test kmsgrab stuff, all of the nonstandard plane formats are fun too.) [18:51:03 CEST] <LongWork> yeah the NV12_10 [18:51:04 CEST] <jkqxz> Just looking at it. I think it's good now. [18:51:39 CEST] <LongWork> they did that for ddr bandwidth .. but that's not enought for 4K@60 obviously, i wish they went the AFBC way [18:51:54 CEST] <LongWork> although would have probably been more difficult to use from ffmpeg [18:52:13 CEST] <wm4> AFBC? [18:52:28 CEST] <LongWork> Arm Frame Buffer Compression [18:52:55 CEST] <LongWork> it's some sort of framebuffer compression that allows to divide the bw by 2/3 [18:53:11 CEST] <LongWork> most ARM chips like GPU or VPU can decode encode that [18:53:28 CEST] <LongWork> and allows to minimize the memory transfer bandwidth, especially with video stuff [18:53:52 CEST] <LongWork> https://developer.arm.com/technologies/graphics-technologies/arm-frame-buff… [18:54:23 CEST] <LongWork> the problem is that i don't think ABFC code is public [18:56:00 CEST] <atomnuker> intel has a similar thing, turned on by default nowadays [19:05:22 CEST] <jkqxz> LongWork: Two minor things: DRM_FORMAT_* should be a uint32_t (around rkmpp_get_frameformat()); ret is sometimes pointlessly initialised to MPP_NOK in functions returning AVERROR - they all get overwritten, but if you don't initialise it then the compiler will check that for you :) [20:01:16 CEST] <kurosu_> all GPU vendors have equivalent stuff for compressing their buffers [20:01:37 CEST] <kurosu_> often a mix of delta (from a neighbor), palette and old school techniques [20:02:05 CEST] <kurosu_> though not sure how they achieve lossless, fixed rate, and not too large risk of expansion [20:02:57 CEST] <kurosu_> famous s3tc [20:17:41 CEST] <iive> s3tc is lossy [20:18:48 CEST] <iive> it is basically half by half image and smaller deltas. [20:19:45 CEST] <LongChair> jkqxz: mind replying to these in ML so that i can keep track of that ? :) [21:09:17 CEST] <llogan> i need to set an alias for ffmpeg as "gg,[rh" due to my occassional, but odd, one-key-to-the-right typos [21:38:59 CEST] <cone-694> ffmpeg 03Paul B Mahol 07n3.1.11:HEAD: avfilter/af_headphone: increase max ir length [21:52:51 CEST] <jkqxz> LongChair: <http://sprunge.us/LLBJ> [21:53:02 CEST] <jkqxz> Mostly cosmetic. I can just squash that in if you're happy with it? [21:53:13 CEST] <jkqxz> Does anyone else want to comment on Rockchip decoder? wm4? [21:53:40 CEST] <wm4> I've looked at it much earlier and have nothing more to say [21:55:24 CEST] <jkqxz> I don't think anyone else is interested, so if LongChair is happy with that then I'll just push it. [21:55:46 CEST] <wm4> no objection here [22:13:59 CEST] <hanna> 20:02 <@kurosu_> though not sure how they achieve lossless, fixed rate, and not too large risk of expansion <- the answer is simple: they don't [22:14:08 CEST] <hanna> I've yet to see a lossless texture compression mode [22:14:44 CEST] <cone-694> ffmpeg 03Thomas Mundt 07master:d491d6a0cd01: avfilter/interlace: rename two variables for consistency [22:28:35 CEST] <jamrial> wm4: patch deprecating copy_side_data and suggesting to use copy_props on the ml [22:29:13 CEST] <wm4> sounds fine [22:44:45 CEST] <jamrial> for that matter, was sizeof(AVPacketSideData) meant to be part of the ABI? [22:44:53 CEST] <jamrial> i ask because sizeof(AVFrameSideData) is not [22:47:43 CEST] <wm4> that's unknown [22:48:01 CEST] <wm4> since it's not explicitly documented as such, you probably have to assume that it's part of the ABI [22:48:39 CEST] <wm4> actually, the packet side data is an array of structs [22:48:45 CEST] <wm4> so it's definitely part of the ABI [22:48:50 CEST] <wm4> I hate this inconsistent crap [22:49:01 CEST] <jamrial> right [22:49:14 CEST] <wm4> I wonder if ubitux will go through with making a reusable side data list thing [22:50:28 CEST] <ubitux> didn't start, maybe tomorrow [22:51:05 CEST] <jamrial> my intention was making packet side data refcounted, much like BBB did for frame side data, but guess that's not an option [22:51:45 CEST] <wm4> at least not without some major deprecation dances [22:51:46 CEST] <jamrial> can't add an AVBufferRef pointer to AVPacketSideData, and i have to assume downstream users implemented their own code handling side data, which would break badly [22:52:25 CEST] <atomnuker> jamrial: we're bumping api versions soon, couldn't we change it (or do we have to wait 2 years)? [22:53:08 CEST] <jamrial> i don't know. can we simply say "ok, this is not part of the abi anymore" after a bump? [22:53:45 CEST] <wm4> no idea [22:54:17 CEST] <wm4> I'd nuke it from orbit, and replace it with ubitux shiny yet-to-exist thing, and some painfully messy compat code [22:54:19 CEST] <atomnuker> if anyone was using sizeof(AVPacketSideData) they'd have to recompile because abi isn't preserved so nothing would break in theory [22:54:57 CEST] <ubitux> wm4: is that side data thing really rocket science? [22:55:11 CEST] <wm4> not really [22:55:26 CEST] <jamrial> atomnuker: it's more about existing code assuming it's part of the abi, manually handling side data instead of using the helpers and potentially breaking if we suddenly make it ref counted [22:55:49 CEST] <nevcairiel> jamrial: technically you probably could, but the unfortunate part is that we cant really enforce that or even notify users if they are using it wrong, so its easy to cause subtle bugs [22:56:00 CEST] <wm4> atomnuker: that's a bit naive... things could happen like API users accidentally copying a AVBufferRef* field without handling it properly etc. [22:58:39 CEST] <wm4> what's the state of sizeof(AVPacket) [22:58:52 CEST] <wm4> as long that is part of the ABI, nothing can happen [22:59:13 CEST] <wm4> (tbh I'd just abolish ABI and rule that ABI only needs to be kept for minor releases) [23:03:33 CEST] <rcombs> add a `char _padding[1024 * 1024 * 1024]` to the end of the struct, and subtract that from sizeof() when malloc()ing it [23:03:40 CEST] <rcombs> that oughtta stop people from putting it on the stack [23:04:34 CEST] <wm4> nice one, but UB [23:04:41 CEST] <wm4> (probably) [23:05:00 CEST] <nevcairiel> people came up with all sorts of ideas to try to get compilers to yell at you when you try [23:05:05 CEST] <nevcairiel> but there is no clean way [23:05:23 CEST] <rcombs> alternately move it to a private header and add getters and setters [23:06:29 CEST] <nevcairiel> we're trying to go away from getters and setters again [23:06:31 CEST] <nevcairiel> noone likes those [23:07:59 CEST] <jamrial> what nobody likes is getters and setters for fields from structs in an installed header :p [23:08:45 CEST] <wm4> setters and getters are annoying, but reasonable for opaque structs [23:09:05 CEST] <wm4> what I don't like are setters and getters _and_ public or half-public fields _and_ AVOption crap all at once [23:09:19 CEST] <JEEB> yup [23:09:33 CEST] <rcombs> oh yeah that's dumb as hell [23:27:42 CEST] <durandal_1707> wm4: so how filters should set its options? [00:00:00 CEST] --- Tue Sep 26 2017

1 0

ffmpeg.log.20170925
by burek 26 Sep '17

26 Sep '17

[00:02:30 CEST] <wondiws> hi, I got this code from someone else that uses the ffmpeg libraries to open video streams. I usually use http:// streams, but is it possible to use video4linux as well? It looks to me that the avformat_open_input function opens the stream. Is there a prefix or url that I need to use v4l? [00:02:37 CEST] <wondiws> just entering /dev/video0 didn't work for me [00:06:43 CEST] <JEEB> l4v2 is supported if that module was built in libavformat [00:07:26 CEST] <JEEB> ok, no - it's in libavdevice [00:08:22 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavdevice/v4l2.c;h=f087bad… [00:21:38 CEST] <blap> i'd like a head-tracking and zooming filter that will just capture the head and shoulders of a lecturerer, if one is present, and then a full res of whatever slide is shown [00:32:33 CEST] <wondiws> JEEB, do I need to do something like v4l2://dev/video0? [00:35:13 CEST] <sshowcat> yo! trying to join a local, live video stream with a live remote rtp audio stream. are there any techniques to synchronizing the two? they have 5-15seconds mismatch on each attempt [01:31:51 CEST] <iive> wondiws: `man ffmpeg-all` look for "-f v4l2" ; -f sets format, but is also used to select input/output module, (de)muxer etc.. [01:32:16 CEST] <wondiws> iive, I'm not using a command line program, I'm using C code [01:32:45 CEST] <iive> then you might want to look in libavdevice [07:49:07 CEST] <doslas1> 'G [07:49:12 CEST] <doslas1> hi [07:50:48 CEST] <doslas1> i need live streaming audio with photo on youtube? [07:55:27 CEST] <doslas1> https://gist.github.com/imdario/c1176e770c1570a07d06 [13:28:08 CEST] <doslas> hi [13:29:26 CEST] <doslas> i need live streaming audio file with photo on youtube? [13:35:14 CEST] <doslas> durandal_1707, ran [14:02:16 CEST] <doslas> ubitux, [14:10:55 CEST] <blap> i dunno [14:11:19 CEST] <Nacht> Anyone has any idea as to why the following happends. We have a few TS files, which we concat together. Playing the total.ts plays fine, but when I transmux it to MP4, the file gets screwed up. Some parts the audio runs, but the video is static, other parst the video runs but no audio. [14:16:56 CEST] <doslas> ?? [14:19:26 CEST] <BtbN> mpegts is a lot more tolerant to sudden format changes in the middle [14:19:28 CEST] <BtbN> mp4 is not [14:21:00 CEST] <flux> hmm, but iso base media format does support least multiple sample descriptions? that is not sufficient? [14:21:45 CEST] <BtbN> it supports what? [14:22:30 CEST] <ritsuka> yes it does, but some players and muxers don't [14:26:11 CEST] <BtbN> You can't suddenly change major encoding parameters of a stream in the middle of the file. It only has one extradata header [14:29:22 CEST] <ritsuka> no, isobff and mov supports multiple sample descriptions (and extradata) [14:30:45 CEST] <BtbN> If it does, I doubt any muxer seriously implements it. Let alone players [14:31:10 CEST] <ritsuka> QuickTime does :P [14:47:04 CEST] <JEEB> libavformat now supports multiple sample descriptions thanks to koda I think [14:48:27 CEST] <BtbN> Question is if it's intelligent enough to make use of it when fed a bunch of randomly concatenated mpegts files [14:48:38 CEST] <BtbN> And what players, or YouTube, will do with it [14:52:42 CEST] <JEEB> yea, I think it was on the demuxing side, totally not sure about mux [16:56:21 CEST] <doslas> ???????????????? [16:57:05 CEST] <durandal_1707> doslas: do you have actual question? [16:59:17 CEST] <doslas> Already [16:59:57 CEST] <doslas> I asked a while ago and waited so long. [17:00:45 CEST] <doslas> ok [17:00:51 CEST] <doslas> <doslas> i need live streaming audio file with photo on youtube? [17:01:27 CEST] <doslas> <durandal_1707> [17:02:58 CEST] <durandal_1707> never done that [17:03:35 CEST] <durandal_1707> what you need? full help or just command? [17:04:07 CEST] <doslas> full help plz [17:04:46 CEST] <doslas> How to broadcast live audio file [17:05:00 CEST] <doslas> on youtube [17:07:24 CEST] <doslas> *I use translator! [17:08:01 CEST] <doslas> Often [17:09:22 CEST] <doslas> durandal_1707, You with me? [17:10:15 CEST] <Nacht> ffmpeg -re -i images.png -i audio.mp3 -c:v libx264 -f flv rtmp://a.rtmp.youtube.com/live2/<KEY> [17:11:25 CEST] <doslas> Nacht, My dear friend [17:12:14 CEST] <doslas> Thank you so much for helping me out. [17:12:23 CEST] <Nacht> oeh forgot the framerate. -framerate 24 [17:12:44 CEST] <Nacht> ffmpeg -re -framerate 25 -i images.png -i audio.mp3 -c:v libx264 -f flv rtmp://a.rtmp.youtube.com/live2/<KEY> [17:13:36 CEST] <doslas> Thanks :) [17:14:12 CEST] <doslas> I'll try now [17:14:56 CEST] <Nacht> To explain what it does: 'framerate' sets your input framerate. 're' is needed for streaming, otherwise it will go to fast. 'c:v libx264' encodes the video with h264, '-f flv rmtp... ' is where it will be outputted to [17:15:12 CEST] <Nacht> Be sure to update the <KEY> with what Youtube gives you [17:17:01 CEST] <doslas> OK [17:19:17 CEST] <doslas> loop?? [17:19:55 CEST] <doslas> Re-broadcast automatically? [17:20:24 CEST] <doslas> I need that, too. [17:20:52 CEST] <doslas> I don't want the broadcast to end. [17:21:35 CEST] <Nacht> Then it's perhaps easier to first create a single file, and just stream that [17:22:14 CEST] <Nacht> so first: [17:22:22 CEST] <Nacht> ffmpeg -re -framerate 25 -i images.png -i audio.mp3 -c:v libx264 -f mp4 stream_file.mp4 [17:22:23 CEST] <Nacht> then [17:22:55 CEST] <Nacht> ffmpeg -stream_loop -1 -re -i stream_file.mp4 -c copy -f flv rtmp://a.rtmp.youtube.com/live2/<KEY> [17:23:54 CEST] <doslas> Looks like you forgot the picture. [17:24:10 CEST] <doslas> -i images.png [17:24:15 CEST] <doslas> [17:24:56 CEST] <doslas> ffmpeg -re -stream_loop -1 -framerate 25 -i images.png -i audio.mp3 -c:v libx264 -f flv "$YOUTUBE_URL/$KEY/$STREAMNAME" [17:25:07 CEST] <doslas> OK? [17:25:14 CEST] <Nacht> no, you already integrated it in the first one [17:25:31 CEST] <Nacht> ffmpeg -re -framerate 25 -i images.png -i audio.mp3 -c:v libx264 -f mp4 stream_file.mp4 || Creates an .mp4 file with audio AND video. [17:25:46 CEST] <Nacht> ffmpeg -stream_loop -1 -re -i stream_file.mp4 -c copy -f flv rtmp://a.rtmp.youtube.com/live2/<KEY> || Streams that video to youtube [17:26:17 CEST] <Nacht> That way, you only transcode once, and after that you just transmux. Less cpu needed [17:26:18 CEST] <doslas> oeh [17:27:22 CEST] <doslas> Yes I understand , you mean I put the two things together? [17:29:09 CEST] <doslas> Could you make me a script like last time? [17:31:46 CEST] <doslas> OK [17:31:53 CEST] <doslas> this [17:32:02 CEST] <doslas> ffmpeg -re -framerate 25 -i images.png -i audio.mp3 -c:v libx264 -f mp4 stream_file.mp4 [17:32:23 CEST] <doslas> Creates an .mp4 file with audio AND video [17:32:37 CEST] <furq> uh [17:32:41 CEST] <furq> don't use -re in that command [17:33:00 CEST] <doslas> ffmpeg -stream_loop -1 -re -i stream_file.mp4 -c copy -f flv rtmp://a.rtmp.youtube.com/live2/<KEY> [17:33:05 CEST] <doslas> this [17:33:12 CEST] <doslas> in script? [17:50:47 CEST] <doslas> furq, -re It'll make it happen a lot. Isn't it? [18:31:04 CEST] <jrun> i have a big file that mpv plays back all black. it was recorded on pixel phone. how do i upload a small bit for you guys to see? [18:33:04 CEST] <relaxed> jrun: can you try ffplay? [18:36:07 CEST] <blap> helping google customers is definitely not on my todo list [18:36:24 CEST] <jrun> ffplay actually plays it back. [18:36:45 CEST] <jrun> except saying this: [swscaler @ 0x7f44740a5390] deprecated pixel format used, make sure you did set range correctly [18:37:14 CEST] <jrun> with massive cpu spike [18:37:34 CEST] <alexpigment> does the pixel phone record at 10-bit 4:2:2? [18:37:53 CEST] <alexpigment> sorry, i meant to say 10-bit or 4:2:2 [18:38:21 CEST] <jrun> https://gist.github.com/484dd5da8b45117cd91df765e8a51517 [18:38:40 CEST] <alexpigment> ah, yuvj420p [18:38:51 CEST] <alexpigment> i suspect that's the problem [18:39:42 CEST] <relaxed> jrun: then I would try a different --vo with mpv and if it stills happens, ask in #mpv [19:05:09 CEST] <vans163> does ordering matter for a h264 decoder? if im slicing the frame into udp packets of size 1320~ [19:06:09 CEST] <vans163> also when slicing like this, is losing 1% of any packet okay? or is losing a key packet like the first sps going to forever break the stream? [19:06:18 CEST] <vans163> 1% of total packets** [19:09:04 CEST] <BtbN> re-submit them with every I frame if you are streaming via UDP. [19:15:48 CEST] <doslas> Too many packets buffered for output stream 0:1 [19:16:23 CEST] <doslas> It doesn't work [19:18:36 CEST] <doslas> furq, [19:30:15 CEST] <nohop> I decided to use the nginx-rtmp route, and not try to reinvent the wheel and use my own server (As per my questions last week :) ) Now, is there a prefered way of creating an hls stream to nginx using ffmpeg's api, or should I just pipe my raw data into ffmpeg's standard input ? (feels wrong :) ) [19:30:43 CEST] <BtbN> "hls stream to nginx"? [19:30:53 CEST] <BtbN> It's not something you deliberately send somewhere. [19:31:02 CEST] <BtbN> You use rtmp for the ingest, as the name might suggest. [19:31:06 CEST] <kepstin> nohop: if you're using the nginx-rtmp module, then you send rtmp to nginx [19:31:21 CEST] <kepstin> if you're using hls, then use the hls muxer to save to disk, then serve with any http server. [19:36:18 CEST] <nohop> hmmm [19:37:15 CEST] <nohop> it's an application that creates a video stream, it's not to be saved on disk, since it's a live video-stream. I'm using nginx' rtmp module with the "hls on;" option. [19:38:02 CEST] <nohop> as a test, i can stream to nginx with ffmpeg, using a file on disk. But in our application I just want to give my raw video frames to ffmpeg, and have ffmpeg stream it to the streaming server [19:39:04 CEST] <nohop> BtbN: since nginx with the rtmp module and hls support, yes, i am deliberately sending it to the streaming server [19:39:42 CEST] <BtbN> that's not how HLS works. You cannot direct it somewhere. [19:39:46 CEST] <BtbN> You serve it from a http server. [19:39:58 CEST] <BtbN> That's what rtmp is used for. [19:40:00 CEST] <furq> nohop: ./foo | ffmpeg -f rawvideo -i - -c:v libx264 -f rtmp rtmp://nginx:1935/bar [19:40:15 CEST] <furq> plus whatever other options you need for rawvideo. probably -s and -r [19:40:28 CEST] <nohop> yeah, that's what I was wondering [19:40:28 CEST] <furq> and er [19:40:29 CEST] <furq> -f flv [19:40:42 CEST] <nohop> do i just pipe, or is there a 'neater' option that uses the API [19:40:42 CEST] <BtbN> What even produces raw video frames that you want to take in that way? [19:40:50 CEST] <BtbN> what? [19:40:54 CEST] <nohop> but, ok, i'll just pipe raw data up it's butt :) [19:41:04 CEST] <furq> you can do it with the api if you want [19:42:01 CEST] <nohop> BtbN: our application collects video streams from multiple camera's, does some processing and combining and sticks that in some raw streaming output buffer [19:42:23 CEST] <nohop> furq: play, I was hoping that was the case :) I couldn't find examples... [19:44:12 CEST] <kepstin> I'm sure you've found some "encoding with libavcodec" examples, right? The only differences will be that you use the flv muxer and use a url starting with rtmp: as the output [19:45:48 CEST] <nohop> Yeah, i'm already encoding to disk using other muxers. Just not sure how to create the output context for an rtmp stream, i guess :) [19:47:07 CEST] <nohop> wait, do i actually just use the url as the filename, and set format_name to "flv" !? [19:49:38 CEST] <nohop> as arguments to avformat_alloc_output_context2(), that is [19:53:57 CEST] <doslas> I want live stream with stereomix? [19:55:24 CEST] <blap> declarative statements do not use question marks [20:31:10 CEST] <redrabbit> :) [20:38:45 CEST] <doslas> blap, thanks [20:40:00 CEST] <doslas> redrabbit, What are you laughing at? [20:41:20 CEST] <doslas> Did you instead answer my question, to help me? [20:41:30 CEST] <nohop> Holy balls, that actually worked. Sorry for all the questions... It's always unbelievable when things are simpler than they seem :) [20:43:03 CEST] <doslas> I want live stream with stereomix [21:47:54 CEST] <redrabbit> i want chocolate [22:04:23 CEST] <rjp421> anyone with a pi and pi-cam, and updated packages+kernel+ffmpeg-git: can you please test piping raspivid to ffprobe or ffmpeg? confirm whether or not ffmpeg crashes [22:36:07 CEST] <dan3wik> I'm trying to transcode a websockets JSmpeg stream from a server but I can't seem to work out how to do it if it is even possible. [23:29:52 CEST] <BytesBacon> Does reading from one drive and writing to another drive, increase the speed of ffmpeg with on ultraslow switch settings? [23:30:19 CEST] <JEEB> not unless IO is your bottleneck [23:34:43 CEST] <BytesBacon> Okay, I think right now my bottleneck is CPU, even with 6 cores. I'm going to have to start looking at dual CPU boards I think. [23:38:01 CEST] <thebombzen> what is recommended for good headphone listening? is bs2b better or worse than earwax? [23:42:59 CEST] <JEEB> BytesBacon: remember that with dual CPU you will get into the NUMA problem. [23:44:22 CEST] <BytesBacon> JEEB, thanks for the heads up, I'll have to read into that. [23:45:49 CEST] <BytesBacon> Is that only with x265 tho? Right now I'm just using libx264. [23:48:42 CEST] <BytesBacon> JEEB, thanks, I see now, x264 doesn't support the non-uniform memory from the dual CPUs. Hmm [23:57:47 CEST] <alexpigment> BytesBacon: what is your current CPU? [23:58:10 CEST] <alexpigment> not everything can be processed in parallel, and sometimes fast clock speeds are what you need [23:58:24 CEST] <alexpigment> the new i7-8700 seems like a really good balance of both [23:58:41 CEST] <alexpigment> 8700k, rather [23:59:20 CEST] <BytesBacon> It's older AMD Phenom II x6 1055T at 2.8GHz. [23:59:32 CEST] <alexpigment> ah, yes, you need better IPC than that chip can provide [23:59:57 CEST] <alexpigment> Ryzen is a big step up in terms of IPC, but Intel is still king of that [00:00:00 CEST] --- Tue Sep 26 2017

1 0