Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

April 2016

1 participants
60 discussions

ffmpeg-devel.log.20160409
by burek 10 Apr '16

10 Apr '16

[00:18:35 CEST] <cone-433> ffmpeg 03Matthieu Bouron 07master:7abc8e7ae3aa: swscale/arm: add ff_hscale_8_to_15_neon [01:12:50 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07master:d433623fba2b: avcodec/pngdec: Fix alpha detection with skip_frame [02:59:47 CEST] <michaelni> atomnuker, you are listed as mentor on wiki for TrueHD encoder but not in gsoc for the actual proposal(s), is that intended ? [03:03:49 CEST] <michaelni> thardin, you are listed as mentor for "MXF Demuxer Improvements" on 2016-Qualis, durandal_170 as mentor on wiki and noone in gsoc interface, if thats intended, then all ok just want to make sure its not forgotten [03:16:49 CEST] <thardin> uh, i don't have time [03:16:55 CEST] <thardin> :/ [03:25:37 CEST] <michaelni> thardin, did the student do some qualifiation task or started one or anything ? [03:29:12 CEST] <thardin> not as far as I rexall [11:40:27 CEST] <cone-250> ffmpeg 03Carl Eugen Hoyos 07master:56cb465b38ab: lavf/gsmdec: Add raw gsm autodetection. [11:45:38 CEST] <cone-250> ffmpeg 03Carl Eugen Hoyos 07master:b0c026a27f94: lavf/rawenc: Add a raw gsm muxer. [15:39:04 CEST] <Daemon404> back in europe, but been up 24 hrs, so no merge [15:39:36 CEST] <wm4> D: [15:40:28 CEST] <Daemon404> also there seems to be some outstanding issue(s) [15:40:31 CEST] <Daemon404> lol ffserver [15:40:42 CEST] <Daemon404> (thats the real reason) [15:40:57 CEST] <Daemon404> https://github.com/dwbuiten/FFmpeg/issues/33 [15:40:58 CEST] <Daemon404> and this [15:41:27 CEST] <wm4> doesn't seem overlay critical [15:41:33 CEST] <wm4> maybe some bitrate guess off [15:41:40 CEST] <nevcairiel> seems odd that it would change, frame count remains the same, i didnt look at matroskaenc changes though [15:47:12 CEST] <Daemon404> ill merge tomorrow if those two can get cleared up (maybe by me tomorrow if you guys hate ffserver so much( [15:47:22 CEST] <Daemon404> (screw ffserver) [15:47:24 CEST] <Daemon404> (so much) [15:49:51 CEST] <wm4> I'd just ignore ffserver, seriously [16:37:35 CEST] <durandal_170> Why is left shift by >31 wrong? [16:37:42 CEST] <wm4> UB [16:38:42 CEST] <durandal_170> what? [16:39:25 CEST] <wm4> undefined behavior [16:39:31 CEST] <fritsch> on 32 bit hw [17:28:03 CEST] <Daemon404> i cant even repro/test ffserver [17:28:11 CEST] <Daemon404> Sat Apr 9 16:27:42 2016 FFserver started. [17:28:11 CEST] <Daemon404> Sat Apr 9 16:27:44 2016 127.0.0.1 - - [DESCRIBE] "rtsp://localhost:8554/h264-cut.mkv RTSP/1.0" 200 157 [17:28:14 CEST] <Daemon404> from ffserver [17:28:21 CEST] <Daemon404> [rtsp @ 0x3c94240] method DESCRIBE failed: 404 Not Found [17:28:21 CEST] <Daemon404> rtsp://localhost:8554/h264-cut.mkv: Server returned 404 Not Found [17:28:24 CEST] <Daemon404> from ffmpeg [17:28:38 CEST] <nevcairiel> maybe thats the problem? =p [17:28:49 CEST] <Daemon404> it isnt [17:28:55 CEST] <Daemon404> i had this before when i tried to test other stuff [17:29:05 CEST] <nevcairiel> i cant even build ffserver because it needs something linux-y which i dont have [17:29:08 CEST] <nevcairiel> i forgot what [17:29:31 CEST] <Daemon404> Sat Apr 9 16:27:42 2016 Opening feed file 'h264-cut.mkv' for stream 'h264-cut.mkv' [17:29:34 CEST] <Daemon404> Sat Apr 9 16:27:42 2016 [matroska,webm @ 0x2f0ebe0]Format matroska,webm detected only with low score of 1, misdetection possible! [17:29:37 CEST] <Daemon404> Sat Apr 9 16:27:42 2016 [matroska,webm @ 0x2f0ebe0]EBML header parsing failed [17:29:40 CEST] <Daemon404> Sat Apr 9 16:27:42 2016 Could not open 'h264-cut.mkv': Invalid data found when processing input [17:29:43 CEST] <Daemon404> so uh [17:29:43 CEST] <Daemon404> this is probably why [17:29:49 CEST] <Daemon404> i dont see what michael sees though [17:29:54 CEST] <nevcairiel> what did you do to the file [17:30:03 CEST] <Daemon404> $ file h264-cut.mkv [17:30:03 CEST] <Daemon404> h264-cut.mkv: HTML document, UTF-8 Unicode text [17:30:05 CEST] <Daemon404> dammit [17:30:10 CEST] <nevcairiel> ahaha [17:30:25 CEST] <Daemon404> trac is stupid [17:34:36 CEST] <Daemon404> there i fixed ffserver [17:34:39 CEST] <Daemon404> rot in hell ffserver [17:35:04 CEST] <Daemon404> not bad for nearing 30 hrs awake. [17:36:15 CEST] <wm4> it detects a text file as matroska? [17:36:41 CEST] <Daemon404> i did because of the extension lol [17:36:43 CEST] <Daemon404> it* [17:36:44 CEST] <nevcairiel> score 1 based on extension probably [17:38:25 CEST] <wm4> well lol at ffmpeg.c for still opening it [17:39:20 CEST] <Daemon404> that was ffserver [17:40:30 CEST] <Daemon404> is this duation bug in matroska or everything [17:42:19 CEST] <wm4> my theory: .ts duration incorrect, but is written as is to the mkv file (didn't check if it's true) [17:42:38 CEST] <wm4> hm if -t is used, maybe that's wrong [18:00:24 CEST] <Daemon404> michaelni, is this just for matroska or all formats [18:08:19 CEST] <michaelni> Daemon404, IIRC i saw it only in .mkv and .webm so probably yes just matroska [18:09:31 CEST] <Daemon404> ok [18:10:28 CEST] <nevcairiel> Daemon404: how does ffserver open this thing so that codecpar isnt filled .. or let me guess, thats a manual copy from somewhere else again? [18:27:41 CEST] <Daemon404> nevcairiel, everything is manual [18:27:54 CEST] <Daemon404> it even allocates everything inside the stream [18:27:59 CEST] <JEEB> :D [18:29:47 CEST] <nevcairiel> but doesnt it have to open the file somewhere [18:41:51 CEST] <Daemon404> yes but it doesnt use that info, it copies it [18:43:19 CEST] <Daemon404> /* FIXME: This code should use avformat_new_stream() */ [18:43:20 CEST] <Daemon404> ^ [18:43:59 CEST] <wm4> lol [18:44:56 CEST] <wm4> wow it was added 4 months ago [18:45:02 CEST] <wm4> (the comment) [18:45:22 CEST] <Daemon404> yes after i got mad at the 'maintainer' for adding more internal struct hacks [18:45:35 CEST] <Daemon404> the solution was a fixme that was never fixed [18:46:06 CEST] <wm4> ffserver even fork()s [18:51:25 CEST] <BtbN> just get rid of ffserver, it only causes user-confusion and frustration with noone knowing how to use it and no maintainer. [18:54:59 CEST] <Compn> would it be easier to split ffserver off as a seperate repo ? [18:55:06 CEST] <Compn> if you dont want to fix it [18:55:16 CEST] <Compn> leave it with current (or previous to codecpar) git [18:55:32 CEST] <Compn> that way its not removed, if someone wants to fix it they can... [18:57:05 CEST] <wm4> <Compn> would it be easier to split ffserver off as a seperate repo ? <- the point that tortures us all this time is that you can'tr [20:05:09 CEST] <Compn> wm4 : i mean a repo with everything including ffserver [20:05:14 CEST] <Compn> and then just remove ffserver from git master [20:05:28 CEST] <Compn> or just disable compilation of it [20:05:38 CEST] <Compn> or something :\ [20:10:38 CEST] <Daemon404> wm4, mkv extradata is difference on that mkv duration change [20:11:00 CEST] <wm4> huh [20:11:01 CEST] <Daemon404> i dunno what sort of extradata mpeg2video has in mkv... [20:11:21 CEST] <nevcairiel> mpeg2video shouldnt have any [20:11:36 CEST] <nevcairiel> but its not mpeg2 [20:11:39 CEST] <nevcairiel> its encoding to x264 [20:11:56 CEST] <Daemon404> oh, i tested to mpeg4 [20:11:58 CEST] <Daemon404> woops [20:12:01 CEST] <Daemon404> but its the same issue [20:12:02 CEST] <Daemon404> -#extradata 0: 49, 0x016c0b65 [20:12:03 CEST] <Daemon404> +#extradata 0: 49, 0x01710b66 [20:12:11 CEST] <Daemon404> ^ with mpeg4 anyway [20:12:14 CEST] <Daemon404> + duration change [20:12:33 CEST] <nevcairiel> no clue what mpeg4 stores in there [20:12:36 CEST] <Daemon404> (mertadata duration) [20:12:37 CEST] <nevcairiel> i didnt think it needs extradata [20:12:53 CEST] <Daemon404> it can, e.g. in mp4 [20:12:59 CEST] <Daemon404> xvid has some crap in there [20:13:12 CEST] <Daemon404> so ours probablyt does too [20:13:18 CEST] <Daemon404> vo/vol or something [20:17:39 CEST] <Daemon404> problem doesnt occur with anything but mpeg4 or h264 afaict [20:35:58 CEST] <Daemon404> well i see why its happening [20:36:10 CEST] <Daemon404> the pkt duration its getting is 0 [20:36:30 CEST] <Daemon404> and 0.96s is the last timestamp it gets [20:36:39 CEST] <Daemon404> 0.04s is the pkt duration in master [20:36:42 CEST] <nevcairiel> that makes sense [20:36:50 CEST] <nevcairiel> 0.04 is appropriate for 25fps too [20:38:18 CEST] <Daemon404> i have no idea why [20:38:29 CEST] <wm4> when is pkt duration ever correctly set? [20:39:52 CEST] <Daemon404> "duration_time": "0.040000", [20:39:57 CEST] <Daemon404> ffprobe shows it set... [20:40:14 CEST] <Daemon404> is there some special thing encoders do [20:41:05 CEST] <nevcairiel> maybe it gets lost in between decoding and re-encoding [20:41:42 CEST] <Daemon404> confirmed the demuxer is setting it correctly [20:43:25 CEST] <Daemon404> so av_read_frame is returning 0.04s [20:43:31 CEST] <Daemon404> but write_frame gets a 0 [20:43:36 CEST] <Daemon404> is ffmpeg.c doing funky crap [20:45:00 CEST] <nevcairiel> the real question still ebing what changed [20:55:25 CEST] <jamrial> should we add extradata/sidedata checks to framemd5 before merging codecpar? it effectively found a couple issues in tests using framecrc, so framemd5 tests may be hiding similar bugs [20:55:58 CEST] <jamrial> there are not a lot of tests using framemd5 [20:56:23 CEST] <jamrial> i can write a patch for this [21:02:10 CEST] <Daemon404> nevcairiel, i even find out where its happening [21:02:17 CEST] <Daemon404> but im also overtired, so. [21:29:38 CEST] <cone-929> ffmpeg 03Paul B Mahol 07master:82ee37f1f3b9: avcodec/shorten: fix decoding of very large (>2048) block sizes [21:29:38 CEST] <cone-929> ffmpeg 03Paul B Mahol 07master:0c90b2e01360: avcodec/shorten: add support for AIFF packing, not bitexact [21:48:00 CEST] <durandal_170> michaelni: I selected want to mentor the lavfi interpolation filter guy [21:48:30 CEST] <durandal_170> what else needs to be done [22:19:59 CEST] <michaelni> he should pass qualification, we need to request enough slots and we need to receive enough slots from google and i assume we need to assign a slot and no other org should assign one [22:21:13 CEST] Action: michaelni is a bit unhappy that the new gsoc web interface gives mentors apparently no way to rate proposals [23:11:01 CEST] <durandal_170> michaelni: who decide it passes qualification? [23:29:04 CEST] <michaelni> durandal_170: mentor [23:30:00 CEST] <durandal_170> and how to mentor tell it that that happened? [23:43:46 CEST] <michaelni> either mentor or student should update https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2016-Qualis i guess [23:53:48 CEST] <durandal_1707> but none updated it [23:54:35 CEST] <durandal_1707> and last time it was from google that one could pass student [23:55:26 CEST] <durandal_1707> I already selected what want to mentor, are you one who confirm that? [00:00:00 CEST] --- Sun Apr 10 2016

1 0

ffmpeg.log.20160409
by burek 10 Apr '16

10 Apr '16

[00:07:50 CEST] <andross> sorry was away [00:08:04 CEST] <andross> JEEB: what about all the dependencies though [00:08:18 CEST] <andross> should i grab the third party stuff like they suggest in that guide [00:10:19 CEST] <JEEB> andross: basic ffmpeg doesn't need anything esle [00:10:31 CEST] <JEEB> the guide is for making a kitchen sink including build [00:10:38 CEST] <andross> well i want lame and aac encoding [00:10:49 CEST] <JEEB> LAME is GPL so you can't use that [00:10:53 CEST] <JEEB> AAC is included [00:11:12 CEST] <JEEB> the only other AAC encoder worth using cannot be distributed [00:11:16 CEST] <andross> huh [00:11:22 CEST] <andross> what about libfdk-aac [00:11:30 CEST] <JEEB> non-distributable [00:11:46 CEST] <JEEB> the internal aac encoder is pretty good for LC-AAC now though [00:11:57 CEST] <JEEB> oh, ok. LAME is LGPL [00:12:05 CEST] <JEEB> but really, start off without anything extra first [00:12:13 CEST] <JEEB> I really can't stress that enough [00:12:28 CEST] <JEEB> getting a basic build with all the internal stuff going is the basic of all basics [00:13:16 CEST] <JEEB> trying to find out how to build other stuff with mingw-w64 before even getting to ffmpeg is like begging for blood from your nose [00:13:44 CEST] <andross> well its not too difficult to get lame compiled libraries [00:14:34 CEST] <JEEB> and it's not worth trying to lean too much forward considering you get pretty much everything with the standard build [00:15:03 CEST] <JEEB> just try building a basic binary and see if you succeed [00:15:29 CEST] <JEEB> I bet you will hit hurdles (if not, fine), but at least your hurdles will be related to ffmpeg [00:15:34 CEST] <JEEB> not any of extra dependencies [00:15:39 CEST] <JEEB> do you underestand what I'm saying? [00:15:44 CEST] <andross> yes [00:16:07 CEST] <andross> im just waiting for this git clone to finish [00:19:53 CEST] <andross> i686-w32-mingw32-gcc is unable to create an executable file. [00:19:53 CEST] <andross> C compiler test failed. [00:19:57 CEST] <andross> i686-w32-mingw32-gcc is unable to create an executable file. [00:20:08 CEST] <furq> andross: fwiw you probably want git clone --depth 1 [00:20:13 CEST] <furq> that'll make it much faster [00:20:17 CEST] <andross> too late [00:23:43 CEST] <andross> JEEB ^ [00:24:49 CEST] <drv> if you are using mingw-w64, it should typically be called i686-w64-mingw32-gcc [00:24:55 CEST] <drv> (w64, not w32) [00:25:23 CEST] <furq> what he said [00:25:33 CEST] <furq> that is definitely what it's called on debian [00:25:36 CEST] <furq> or ubuntu [00:28:05 CEST] <andross> thanks [00:28:17 CEST] <andross> well i think it built, but i got this warning: WARNING: i686-w64-mingw32-pkg-config not found, library detection may fail. [00:29:30 CEST] <furq> pass --pkg-config=pkg-config to ffmpeg ./configure [00:29:44 CEST] <furq> actually for mingw you probably want --pkg-config="pkg-config --static" [00:31:05 CEST] <andross> well i want to build shared [00:33:53 CEST] <andross> so do i want to do --pkg-config="pkg-config --shared" [00:33:57 CEST] <andross> furq ? [00:41:20 CEST] <furq> no [00:42:01 CEST] <furq> all of the external libs should be static libs [00:42:10 CEST] <furq> which are the ones which need to be found by pkg-config [00:42:24 CEST] <furq> for LGPL compliance you only need libavxxx to be dynamic libs [00:42:25 CEST] <andross> ok [00:42:36 CEST] <andross> so with configure [00:42:48 CEST] <andross> do i need to run it with all those options plus yours again, or can i just pass yours? [00:43:07 CEST] <furq> run configure again with --pkg-config="pkg-config --static" [00:43:13 CEST] <andross> got it [00:43:41 CEST] <furq> it probably makes no difference whether or not you pass --static, but some libs need it [00:43:44 CEST] <furq> notably zimg [00:44:15 CEST] <andross> and then what next [00:44:19 CEST] <andross> do i just run make? [00:44:22 CEST] <furq> yeah [00:44:39 CEST] <furq> run it with -j set appropriately or else it'll take forever [00:44:45 CEST] <andross> too late :( [00:44:52 CEST] <furq> just ^C and restart it [00:44:56 CEST] <furq> it'll pick up where it left off [00:45:03 CEST] <andross> ^C? [00:45:06 CEST] <furq> ctrl-c [00:45:14 CEST] <andross> got it [00:45:37 CEST] <furq> set -j to however many cores you have [00:45:50 CEST] <andross> ah well [00:45:58 CEST] <andross> im running ubuntu in a virtual machine so [00:46:07 CEST] <andross> hmm [00:46:55 CEST] <furq> oh wtf [00:47:05 CEST] <furq> apparently opus is the reason this shared library build doesn't work [00:47:10 CEST] <furq> how annoying [00:47:43 CEST] <andross> i only have 1 core on this vm [00:47:49 CEST] <andross> so should i not bother with -j [00:47:54 CEST] <furq> probably not [00:48:00 CEST] <furq> you could assign more cores to the vm [00:48:06 CEST] <andross> cant be bothered [00:48:19 CEST] <furq> it shouldn't be too bad with only two external libs [00:49:19 CEST] <tp_> make -jX is faster even with a single core [00:53:13 CEST] <andross> uh oh [00:53:21 CEST] <andross> my vm is starting to run out of space lol [01:16:23 CEST] <andross> ranlib: libavcodec/libavcodec.a: No space left on device [01:16:26 CEST] <andross> crap [01:16:34 CEST] <andross> how much space does ffmpeg take up in total? [01:17:24 CEST] <andross> brb i guess i better increase the disk size allocated [01:30:50 CEST] <andross> gparted [01:30:53 CEST] <andross> oops [02:28:15 CEST] <andross> okay im back [02:28:29 CEST] <andross> i finally managed to increase the hard disk size in this virtual machine [02:28:42 CEST] <andross> continuing make... [02:36:09 CEST] <andross> i... think it finished? [02:36:52 CEST] <andross> and now make install? [02:37:12 CEST] <c_14> presumably [02:37:16 CEST] <c_14> you can use it without [02:37:20 CEST] <c_14> but it won't be in your path [02:38:27 CEST] <andross> indeed [02:38:32 CEST] <andross> so where has it built it? [02:38:44 CEST] <c_14> ./ffmpeg [02:40:18 CEST] <andross> should i do make distclean [02:40:30 CEST] <c_14> probably not [02:40:35 CEST] <c_14> that would delete all your hard work [02:40:52 CEST] <andross> i dont know what files im looking for tbh [02:41:18 CEST] <c_14> You want the binary or the libs? [02:41:25 CEST] <andross> libraries [02:41:29 CEST] <andross> for windows [02:41:49 CEST] <c_14> did you build using a prefix? [02:42:05 CEST] <andross> i dont know, i dont think so [02:42:20 CEST] <andross> i just ran configure with the settings JEEB said, and then did make and make install [02:42:21 CEST] <c_14> the libraries are in libav*/libav*.a [02:42:34 CEST] <c_14> eh, and swscale and swresample [02:42:56 CEST] <c_14> I think you can do make DESTDIR=foo install; and it will throw everything in there [02:43:50 CEST] <andross> right i see the *.a's [02:43:55 CEST] <andross> does it produce dlls as well? [02:44:04 CEST] <furq> it does if you ran it with --enable-shared [02:44:07 CEST] <c_14> did you --enable-shared ? [02:44:21 CEST] <andross> im pretty sure i did [02:44:55 CEST] <c_14> then they should be next to the .a files [02:44:57 CEST] <andross> i mean i think it was in the configure settings jeb gave [02:45:52 CEST] <andross> dont see it, just see e.g. libavcodec.a, libavcodec.pc & libavcodec.v [02:47:16 CEST] <andross> i dont have the exact commands jeeb gave anymore as that was in a previous session [02:47:19 CEST] <andross> doh! [02:47:24 CEST] <andross> unless irssi has a log somewhere [02:48:06 CEST] <c_14> check the first line of your config.log [02:48:13 CEST] <c_14> in the ffmpeg source directory [02:48:17 CEST] <c_14> your configure command gets logged there [02:48:50 CEST] <andross> well [02:48:56 CEST] <andross> # ./configure --pkg-config='pkg-config --static' [02:49:06 CEST] <andross> but i did another configure command before that [02:49:15 CEST] <c_14> whatever you run last stays [02:50:00 CEST] <andross> i was given the impression running that command wouldnt undo the configuration from my previous command? [02:50:26 CEST] <c_14> it does [02:50:32 CEST] <andross> doh! [02:50:38 CEST] <andross> alright [02:50:41 CEST] <andross> how do i restart then [02:51:27 CEST] <c_14> make distclean; ./configure --blah; make [02:52:40 CEST] <andross> are you able to scroll up and see the configure command jeeb supplied? [02:53:01 CEST] <c_14> µ | ./configure --cross-prefix=i686-w32-mingw32- --arch=i686 --target-os=mingw32 --disable-static --enable-shared [02:53:15 CEST] <andross> thanks [02:54:39 CEST] <andross> so im going to do this: [02:54:45 CEST] <andross> ./configure --cross-prefix=i686-w32-mingw32- --arch=i686 --target-os=mingw32 --disable-static --enable-shared --pkg-config='pkg-config --static' [02:55:26 CEST] <andross> oops, need to replace the 32 with 64 [02:55:35 CEST] <furq> andross: i might as well save you a bit of time here [02:55:41 CEST] <furq> add --extra-ldflags="-static-libgcc" [02:55:54 CEST] <furq> otherwise you'll have to fish out the libgcc dll and distribute that [02:56:03 CEST] <andross> thanks [02:56:12 CEST] <relaxed> doesn't Zeranoe have a cross compile build script? [02:56:20 CEST] <furq> no [02:56:25 CEST] <furq> his build script builds a toolchain [02:56:31 CEST] <furq> which isn't very useful [02:56:36 CEST] <relaxed> oh, yeah [02:56:57 CEST] <furq> i have a build script but i still haven't figured out how to get it working with shared libs [02:57:20 CEST] <furq> some bullshit is going on with one of the external libs and __declspec(dllexport) [02:57:35 CEST] <relaxed> the horror [02:58:01 CEST] <andross> i have a feeling whatever im doing now, ill still need to do all over again to enable lame [02:58:10 CEST] <furq> hopefully it's because this opus patch didn't work, otherwise i don't have to disable 30 libs one-by-one to figure out who's to blame [02:58:14 CEST] <furq> s/don't// [02:58:24 CEST] <furq> but not today [02:59:01 CEST] <furq> andross: yes, you do [02:59:11 CEST] <furq> you need --enable-libmp3lame at configure time [03:00:47 CEST] <andross> yup [03:00:58 CEST] <andross> but jeeb told me not to [03:01:07 CEST] <furq> fwiw if you wait until tomorrow i'll have probably figured this shared library thing out [03:01:11 CEST] <andross> to confirm it works without first or something [03:02:25 CEST] <furq> did you assign more cores to the vm [03:03:05 CEST] <andross> nah [03:03:09 CEST] <andross> it doesnt take that long [03:12:53 CEST] <andross> or maybe it does -_\\ [03:21:51 CEST] <andross> alright i see the dlls [03:23:04 CEST] <andross> furq: to avoid patent licensing issues i was thinking of making my app require the user to supply a lame dll [03:23:16 CEST] <andross> is that possible in conjunction with ffmpeg? [03:23:37 CEST] <furq> you'd still need to compile ffmpeg with --enable-libmp3lame [03:23:48 CEST] <andross> right [03:24:00 CEST] <andross> so what now [03:24:01 CEST] <furq> you're also bundling an aac encoder, which is at just as much risk from patent issues [03:24:10 CEST] <andross> it is? [03:24:29 CEST] <andross> but mp3 has that weird site where they demand royalties [03:24:49 CEST] <andross> extortionate ones at that [03:25:47 CEST] <furq> oh nvm there are no usage fees for aac [03:26:06 CEST] <furq> it is still patented, though, and i'm not a lawyer [03:26:32 CEST] <furq> "An AAC patent license is needed by manufacturers or developers of end-user encoder and/or decoder products." that may or may not apply to your use case [03:29:15 CEST] <andross> god damn [03:29:39 CEST] <andross> is it possible to have the end user drop in an aac dll as well? [03:30:07 CEST] <furq> yeah but you'd have to disable the builtin encoder and use fdk-aac [03:30:20 CEST] <furq> i also don't know for sure whether that absolves you from licensing issues [03:30:45 CEST] <furq> or patent issues, rather [03:31:07 CEST] <furq> i take it you're in the US since otherwise this isn't an issue [03:31:12 CEST] <andross> oh! [03:31:15 CEST] <andross> im in the UK [03:31:31 CEST] <andross> but i wouldnt be surprised if its an issue here too [03:32:14 CEST] <furq> depends if nigel farage wins in july [03:32:39 CEST] <andross> meaning the patent applies to EU too? [03:32:47 CEST] <furq> no [03:32:49 CEST] <furq> https://en.wikipedia.org/wiki/Software_patents_under_the_European_Patent_Co… [03:33:03 CEST] <furq> you can't get a european patent for software [03:33:42 CEST] <andross> great, does that mean i can use lame as well [03:34:16 CEST] <furq> but maybe when we leave the EU and embrace a glorious future of unrestricted fishing quotas and pre-decimal currency, that might change [03:34:31 CEST] <furq> but yeah you're pretty much safe for now if you're not in the US [03:34:38 CEST] <andross> heh [03:34:57 CEST] <andross> but [03:35:03 CEST] <andross> what if i sell to american customers? [03:35:24 CEST] <furq> i'm not really qualified to answer that [03:36:24 CEST] <andross> btw do you know if major software developers like VLC pay these licenses? [03:36:45 CEST] <furq> i'm pretty sure ffmpeg don't pay any licenses [03:36:53 CEST] <furq> i doubt any open-source stuff does [03:37:47 CEST] <furq> but open-source software isn't a very lucrative target [03:38:08 CEST] <andross> okay well do microsoft [03:38:23 CEST] <andross> in fact is there any company actually known to pay these fees [03:39:52 CEST] <furq> loads of companies pay usage fees [03:39:58 CEST] <furq> idk about encoder fees [03:40:27 CEST] <furq> pretty much any large video streaming service pays h.264 usage license fees [03:40:30 CEST] <furq> including the bbc [03:40:57 CEST] <furq> that's half the reason google are backing vp9 [03:43:08 CEST] <andross> i actually only need ffmpeg for its audo encoding [03:45:50 CEST] <andross> anyway, is the fact that the dlls buit enough to show that it compiled fine, or do i need to do some kind of testing on them [03:46:04 CEST] <furq> you should probably make sure it actually runs on windows [03:47:05 CEST] <furq> apparently you could be in trouble if you sell to the US, but you'd have to be extradited for US patent law to be enforceable [03:47:12 CEST] <furq> so maybe just don't go to america [03:47:59 CEST] <andross> is this for aac or mp3? [03:48:48 CEST] <furq> either [03:48:53 CEST] <furq> they're both covered by patents [03:52:15 CEST] <andross> apparently all the mp3 licenses expire in 2017 [03:59:59 CEST] <Prelude2004c> hey, can anyone give me advise [04:00:01 CEST] <Prelude2004c> [hls @ 0x295cf60] Non-monotonous DTS in output stream 0:1; previous: 8535563676, current: 8535043243; changing to 8535563677. This may result in incorrect timestamps in the output file. [04:00:23 CEST] <Prelude2004c> i can't fix the source obviously because it comes from a satelite signal... is there something ic an use to try and keep timestamps correctly without drifting ? [04:00:44 CEST] <Prelude2004c> i tried the aresampe and i tried async 1 but the server just crashes with memory leak and cpu usage [04:05:57 CEST] <andross> gtg, thanks for the help furq c_14 & JEEB and whoever else [05:45:18 CEST] <k_sze> If I understand correctly, m4a/m4r files *can* contain MP3 audio? [05:45:49 CEST] <c_14> ye [05:46:06 CEST] <k_sze> There is this ringtone that I would like to remux from .mp3 into .m4a: http://bit.ly/1W3CTSK [05:46:20 CEST] <k_sze> I'm not sure what I'm supposed to pass as argument [05:46:35 CEST] <k_sze> apparently it has a h264 cover in addition to mp3 audio. [05:46:48 CEST] <c_14> ffmpeg -i mp3 -c copy out.mp4 [05:47:19 CEST] <k_sze> If I just do ffmpeg -i ... -c:a copy out.m4a, ffmpeg complains "Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument" [05:48:41 CEST] <k_sze> same thing with ffmpeg -i ... -c copy out.m4a [05:49:45 CEST] <c_14> hmm, looks like ffmpeg doesn't want to put mp3 in m4a. you can output to mp4 and rename to m4a it's basically the same thing [05:51:34 CEST] <k_sze> ok, that works, to a certain degree [05:52:21 CEST] <k_sze> if I do remux to mp4, then rename to m4a, I can open the track in VLC, but VLC fails to count the time as it plays. Not sure if it's VLC being buggy. [06:00:24 CEST] <k_sze> And VOX can't play it at all. :/ [06:00:46 CEST] <k_sze> Let me try iTunes now. *gasp* [06:01:43 CEST] <k_sze> iTunes also doesn't recognize it. [08:02:52 CEST] <relaxed> k_sze: I think m4a is for only alac or aac [09:22:38 CEST] <momomo> is there a way to -map 0:m:language:eng if it exists, otherwise use the default [09:49:02 CEST] <relaxed> momomo: no, you'll need to script it [09:49:32 CEST] <momomo> how do I script it in the same command? do i have to connect to get the metadata first, and then reconnect again? [11:15:01 CEST] <momomo> relaxed, do you know? [12:51:21 CEST] <relaxed> momomo: I would write an actual script for it, like a bash script [12:51:47 CEST] <relaxed> or whatever you're familiar with using [13:20:22 CEST] <momomo> relaxed, but i would still have to perform to connections, one to get the metadata first .. right? [14:14:17 CEST] <kepstin> momomo: if it's a remote stream? yeah. (use ffprobe to do the initial connection, then generate an ffmpeg command) [14:52:47 CEST] <satinder___> Hi I guys I am so surprised from ffmpeg , I am working on filter and my command is following : [14:53:24 CEST] <satinder___> ffmpeg -re -i /dev/video0 -vf drawtext='fontsize = 20 : fontfile = /usr/share/fonts/truetype/freefont/FreeSansBold.ttf : textfile = file : reload = 1' -f v4l2 /dev/video1 [14:53:47 CEST] <satinder___> everything is working but output is showing like follow : [14:54:00 CEST] <satinder___> open: No such file or directory=N/A time=00:00:35.16 bitrate=N/A dup=469 drop=0 [14:54:01 CEST] <satinder___> open: No such file or directory [14:54:03 CEST] <satinder___> ??? [14:54:20 CEST] <satinder___> Anybody please help what I am doing wrong [15:17:38 CEST] <Mateon1> Hello, I'm having issues trying to build ffmpeg under MSYS with x265 support. x265 got installed into my Windows program files (x86) folder, but the configure script misinterprets the path to the pkgconfig directory because of spaces and brackets [15:21:08 CEST] <JEEB> yeah, you usually don't do that :P spaces can be "fun" and even more fun depending on your tooling [15:21:15 CEST] <JEEB> KISS is the way to go [15:21:25 CEST] <JEEB> set your prefix to something simple [15:21:28 CEST] <Mateon1> Sorry? [15:23:18 CEST] <Mateon1> I've pasted the log on pastebin, pkg-config itself works, but the configure script doesn't http://pastebin.com/eze43sUt [15:23:37 CEST] <Mateon1> I'll try making a symlink or junction within the MSYS environment [15:25:11 CEST] <JEEB> it's possible it's an issue with the configure script as well, yes. depends on how actually pkg-config outputs the value [15:28:35 CEST] <Mateon1> Oh, this might be an issue. The variables in the pkg-config script still point through the C:\Program Files path [15:28:52 CEST] <Mateon1> I'll try configuring again anyway [15:31:06 CEST] <Mateon1> Nope, same issue [15:47:14 CEST] <Mateon1> Okay, I managed to install x265 into the msys lib, instead of program files. I hope this will work [15:48:21 CEST] <JEEB> you might have to set PKG_CONFIG_PATH accordingly [15:48:44 CEST] <JEEB> PKG_CONFIG_PATH=/your/prefix/lib/pkgconfig/ ./configure [15:48:56 CEST] <Mateon1> Oh, it's already set up properly. Just without the spaces now. [15:49:10 CEST] <JEEB> no the pkg-config search path [15:49:20 CEST] <JEEB> where it looks for the pkg-config pc files [15:49:43 CEST] <JEEB> there's two of them, one overrides the whole search path and the other appends [15:49:49 CEST] <Mateon1> Configure just succeeded. [15:49:54 CEST] <JEEB> ok, great then [15:50:09 CEST] <Mateon1> The original search path had /usr/lib/pkgconfig [15:50:16 CEST] <JEEB> ah [15:50:30 CEST] <JEEB> just thought you set a prefix that was not there in the default search path :) [15:50:38 CEST] <JEEB> or well, that's the usual thing that happens when you set a custom prefix [15:50:59 CEST] <JEEB> for example on lunix I usually have a directory in my home directory [15:51:45 CEST] <Mateon1> Oh god, now I have to sift through issues in make... Undefined variables everywhere! [15:52:53 CEST] <JEEB> given that I have never had issues with either windows (ye olde msys and cygwin + mingw-w64) or lunix, your system's really funky [15:52:56 CEST] <Mateon1> conflicting types for time_t, undefined __c_plus_plus, redefined __STRINGIFY, redefined errno [15:53:05 CEST] <JEEB> oh [15:53:13 CEST] <JEEB> I wonder if you need -lstdc++ [15:53:20 CEST] <JEEB> in extra-ldflags [15:53:33 CEST] <Mateon1> It's a configure argument? [15:53:44 CEST] <JEEB> --extra-ldflags="-lstdc++" [15:57:57 CEST] <Mateon1> Hm, doesn't seem to be the case. I think it's crashing during the compilation step [15:58:14 CEST] <JEEB> pastebin time? [15:58:23 CEST] <Mateon1> I guess so. [15:58:36 CEST] <Mateon1> Should I include ./configure output as well? [15:58:57 CEST] <JEEB> config.log is the more detailed one so if you want to include config-related stuff that would be it [16:01:06 CEST] <Mateon1> Okay, I need to rerun the configure/make step without the -j9 option. [16:01:11 CEST] <Mateon1> Or should I leave it? [16:01:47 CEST] <JEEB> if you want to try again from a clear position, do make distclean and re-configure and run make without any -j [16:02:01 CEST] <JEEB> that way it will fail on the first file that fails and you don't get too much spam there [16:02:08 CEST] <JEEB> and you pastebin both config.log and the output of make [16:02:15 CEST] <Mateon1> Okay, cool [16:02:51 CEST] <furq> Mateon1: you might need --pkg-config="pkg-config --static" [16:03:17 CEST] <JEEB> but even without that it shouldn't fail to build, right? [16:03:24 CEST] <JEEB> it would just prefer the static lib vs shared [16:03:35 CEST] <furq> no, some libs have -lstdc++ in Libs.private [16:03:49 CEST] <JEEB> yes, this one seems to have that as well [16:03:52 CEST] <furq> but it shouldn't even make it through configure if that fails [16:03:57 CEST] <JEEB> yeah [16:04:22 CEST] <JEEB> since the configure check should try linking as well as inclusion of the header [16:04:42 CEST] <Mateon1> It does seem to fail on system headers [16:05:11 CEST] <Mateon1> I've compiled a lot of other libs with no (or little) issues, though [16:07:31 CEST] <JEEB> just get that pastebin done and leave random guessing out :P [16:08:20 CEST] <furq> fwiw i've never had much luck with msys [16:08:27 CEST] <furq> i've always found it easier to cross-compile in a vm [16:08:44 CEST] <JEEB> msys with a custom mingw-w64 toolchain has worked well enough for me [16:09:01 CEST] <JEEB> people do say that the msys2 packaged mingw-w64 toolchain can be "fun" but I guess it should work [16:09:23 CEST] <JEEB> many people just don't grasp the difference between the different compilers distro'd in msys2 (msys targeting one, mingw-w64 targeting one etc) [16:09:40 CEST] <JEEB> which is of course what they also find out about when they start doing cross-compilation on lunix :P [16:09:56 CEST] <furq> i had a bunch of weird issues with msys2's autotools [16:10:08 CEST] <furq> the actual compiler toolchain seemed to work fine [16:10:27 CEST] <furq> although i don't doubt that it has a lot of fun issues [16:10:33 CEST] <Mateon1> http://pastebin.com/HfjTdnMm - The shell log, uploading the config.log in a minute [16:11:23 CEST] <furq> speaking of which [16:11:52 CEST] <JEEB> Mateon1: you didn't distclean [16:12:05 CEST] <Mateon1> Config.log http://pastebin.com/jVCBkUxP [16:12:41 CEST] <Mateon1> JEEB: I distcleaned before the config, however I had to terminate a previous ./configure to add the --pkg-config option [16:12:58 CEST] <Mateon1> I can redo it, but ./configure takes 5 minutes on my system [16:15:00 CEST] <JEEB> wat [16:18:13 CEST] <Mateon1> JEEB: http://i.imgur.com/Sy2janK.png [16:58:59 CEST] <FredT> Hi, I'm trying to figure out what I'm doing wrong with the following command: ffmpeg -v debug -s 1280x720 -pix_fmt yuv420p -i "input%04d.yuv" "test%04d.png" [16:59:55 CEST] <FredT> Trying to convert individual YUV frames to something else. Error I get is input%04d.yuv: No such file or directory but the file is really there [17:00:28 CEST] <JEEB> nothing in ffmpeg really supports that form of input (I'm pretty sure the image2 demuxer's thing is just a hack somewhere) [17:00:50 CEST] <JEEB> so I recommend you input raw YCbCr as one file [17:00:59 CEST] <JEEB> you build a cat command with the right shell thing [17:01:01 CEST] <FredT> ok [17:01:07 CEST] <JEEB> and then pass it through with a pipe [17:01:22 CEST] <JEEB> and of course on the other side of the pipe you have ffmpeg reading from stdin [17:01:27 CEST] <FredT> you call ffmpeg twice? [17:01:33 CEST] <JEEB> no [17:01:51 CEST] <JEEB> cat <WHATEVER YOU COME UP WITH> | ffmpeg -OPTIONS -i INPUT OUTPUT [17:01:53 CEST] <FredT> ok got it [17:02:03 CEST] <JEEB> ffmpeg will read multiple frames from raw yuv [17:03:05 CEST] <shaps> Hey guys -- new to the channel -- no question just yet, but thought I'd say hi. I'm working on an iOS app and looking to use ffmpeg for decoding video files. Could someone just clarify that this is the right channel for me to be in? That way, when I have a question, I'll know where to go ;) [17:07:49 CEST] <JEEB> Shaps: this is the channel to ask questions on using the libav* libraries and the ffmpeg cli application [17:09:56 CEST] <Shaps> ok, so useful from a pure ffmpeg usage point of view? but non-specific to ios/platform? [17:10:22 CEST] <Shaps> that's still really useful for me, because some of the concepts are new to me, so I'm fairly cetain I'm going to have questions in time ;) [17:11:26 CEST] <Shaps> so far my question revolve around decoding in general, not even specific to a lib, but I want to research a lot more before I bother you guys with my question ;) I don't have a specific problem atm :) [22:47:38 CEST] <jpabq> Regarding CODEC_CAP_DELAY, how do you handle multiple streams? If I am decoding all the streams in a MPTS and hit the end of the file, how do I flush any streams that need flushed? Searching I came across http://ffmpeg-users.933282.n4.nabble.com/about-flushing-decoder-at-the-end-… but it does not look like anyone ever answered him. [22:59:10 CEST] <jkqxz> jpabq: The multiple streams shouldn't be relevant. For each AVCodecContext, call decode_video2() repeatedly with an empty packet until got_frame is false. [23:24:49 CEST] <jpabq> jkqxz: Okay. I was relying on the retrieved packet to tell me which context to decode, but I see what you are saying. [23:27:03 CEST] <jpabq> jkqxz: Thanks. I just need to think about this a bit differently. [00:00:00 CEST] --- Sun Apr 10 2016

1 0

ffmpeg-devel.log.20160408
by burek 09 Apr '16

09 Apr '16

[00:26:52 CEST] <erraunt> Hi. Why are entries on trac concerning jpeg2000 tagged 'j2k' ? Wikipedia states that j2k is some close source codec. [00:27:57 CEST] <llogan> maybe to differientiate between jpeg2000 and libopenjpeg decoders? [00:28:26 CEST] <llogan> just guessing. not that i looked or anything [00:30:48 CEST] <mark4o> JPEG2000 and J2K are the same format [00:31:42 CEST] <mark4o> there are various implementations with names like OpenJPEG (open source), and J2K-Codec (proprietary) [00:32:13 CEST] <llogan> *decoders/encoders [02:42:11 CEST] <rcombs> just got an undeliverable message reply to an ML message from gerrad8(a)nate.com [02:58:17 CEST] <jamrial> i've been getting those for every email i sent in the past week or so as well [02:59:27 CEST] <jamrial> could be full inbox or the address is no longer valid, but in any case maybe the list admin should unsubscribe it? [02:59:54 CEST] <llogan> i haven't seen any such messages. are they all from that particular user? [03:02:40 CEST] <jamrial> llogan: yes, all are about that email rcombs mentioned above. automated undeliverable message replies, in korean [03:03:13 CEST] <jamrial> they aren't sent to the ml, mind you, but to the person that wrote the email that couldn't be delivered [03:05:02 CEST] <llogan> i'll disable mail delivery to that user [03:05:53 CEST] <jamrial> rcombs: did you test this patchset applied to Daemon404's codecpar repo? [03:06:05 CEST] <rcombs> jamrial: I did not [03:06:10 CEST] <rcombs> will shortly [03:07:29 CEST] <jamrial> do it if you can, because it will be merged this saturday and it will save you and him some time :p [03:08:31 CEST] <jamrial> rcombs: Daemon404 added an autobsf for movenc to the codecpar branch but then removed it, not sure why [03:08:51 CEST] <rcombs> jamrial: probably because it broke movenc-test and dash [05:17:50 CEST] <Daemon404> [02:08] <+rcombs> jamrial: probably because it broke movenc-test and dash <-- yes [09:48:44 CEST] <cone-216> ffmpeg 03Paul B Mahol 07master:3e99b377fc8b: avcodec: remove "get_buffer() failed" message [10:07:18 CEST] <cone-216> ffmpeg 03Paul B Mahol 07master:ae8a13c56022: avcodec/shorten: if allocation fails reset max_frame_size [10:45:45 CEST] <ubitux> wbs: do you know cases of aarch64 misassembling? [10:52:33 CEST] <wbs> ubitux: no [10:54:27 CEST] <ubitux> ok actually bytecode is the same, i'm lost [10:54:39 CEST] <ubitux> i have a weird bug [10:55:08 CEST] <ubitux> where execution on ios doesn't seem to lead to the same output as qemu or other boards [11:03:28 CEST] <rcombs> calling convention oddity? [11:07:23 CEST] <ubitux> bug is fucked up gamma with jpeg [11:40:44 CEST] <ubitux> rcombs: actually it might be that [11:40:54 CEST] <ubitux> adding av_logs fucks it up more [12:07:58 CEST] <mateo`> for reference and fun: https://developer.apple.com/library/ios/documentation/Xcode/Conceptual/iPho… [12:16:19 CEST] <ubitux> > iOS diverges from Procedure Call Standard for the ARM 64-bit Architecture in several ways [12:16:21 CEST] <ubitux> fuck you apple :( [12:19:53 CEST] <wm4> lol [12:20:41 CEST] <ubitux> so the convert code ends up reading a random y coeff from somewhere else [12:20:51 CEST] <ubitux> which happens sometimes to be in the table of coeff [12:21:14 CEST] <ubitux> actually it might be reading args from the wrapper [12:22:33 CEST] <ubitux> i'm gonna need https://www.youtube.com/watch?v=6Viwwetf0gU [12:46:44 CEST] <cone-216> ffmpeg 03Dmitriy 07master:c3320a51df2b: avcodec/pngenc: restore image size before copying frame [12:46:45 CEST] <cone-216> ffmpeg 03Paul B Mahol 07master:1490682bcb0f: avcodec/pngenc: check return value of av_frame_copy() [13:19:53 CEST] <cone-216> ffmpeg 03Paul B Mahol 07master:259879d32d12: avformat/nistspheredec: fix silly bug [13:26:37 CEST] <ubitux> ok great [13:26:50 CEST] <ubitux> the arguments on the stack are packed within ios calling convention [13:26:52 CEST] <ubitux> ffs [13:26:56 CEST] <ubitux> fuck them :( [13:29:08 CEST] <wm4> I wonder what apple engineers were thinking [13:29:20 CEST] <wm4> "I know, let's have a different ABI from everyone else! great idea!" [13:45:09 CEST] <ubitux> http://b.pkh.me/0001-sws-aarch64-yuv2rgb-honor-iOS-calling-convention.patch [13:45:11 CEST] <ubitux> makes me sad :( [14:16:32 CEST] <ubitux> oh fun readvitc [15:02:29 CEST] <kierank> eugh feature creep [15:02:33 CEST] <kierank> now ffmpeg handles analogue data [15:02:34 CEST] <kierank> eugh [15:03:56 CEST] <durandal_170> kierank: what? [15:04:04 CEST] <kierank> readvitc patch [15:04:30 CEST] <durandal_170> that's digital [15:04:46 CEST] <wm4> obviously ffmpeg should be handling everything [15:04:57 CEST] <wm4> I need a new mail client too, I should implement it as libavdevice demuxer [15:05:03 CEST] <kierank> durandal_170: he's doing analogue vitc [15:13:02 CEST] <nevcairiel> we have all sorts of crazy avfilters, as long as its nicely contained in one filter, just let them have it [15:43:51 CEST] <durandal_170> wm4: client? Server, send encodes to you mail server [15:48:01 CEST] <ubitux> readvitc is pretty cool [15:48:11 CEST] <ubitux> i wonder if you can forward the meta and read it from drawtext [15:48:19 CEST] <ubitux> since we already draw it from here [15:50:36 CEST] <durandal_170> from what? [15:51:27 CEST] <durandal_170> I added feature to drawtect so it can use metadata [15:51:40 CEST] <durandal_170> Long ago [15:53:38 CEST] <ubitux> yes but timecode needs special formatting [15:53:53 CEST] <ubitux> oh well it's already formatted in the meta [15:54:52 CEST] <durandal_170> someone should really write drawass filter [16:23:19 CEST] <kierank> Is there an instruction to do ABCDEFGH IJKLMNOP -> ACEGIKMO [16:23:55 CEST] <BBB> psrlw x, 8; pxrlw y, 8; packuswb x, y? [16:24:05 CEST] <BBB> (or pand instead of psrlw) [16:24:22 CEST] <BBB> I guess on x86 it would be pand [16:26:12 CEST] <kierank> hmm packuswb might be better for what we want anyway [16:26:23 CEST] <kierank> (uyvy422-10bit -> planar 10-bit) [16:26:47 CEST] <kierank> dw* [16:26:57 CEST] <durandal_170> that's all corporate code? [16:27:07 CEST] <kierank> well it's on github but there's nowhere to merge it [16:27:42 CEST] <kierank> I don't really want to add a uyvy422 10-bit to swscale [16:27:46 CEST] <durandal_170> its actually closed? [16:27:48 CEST] <kierank> no [16:27:53 CEST] <kierank> https://github.com/kierank/ffmpeg-sdi/commits/master [16:28:03 CEST] <durandal_170> Ah [16:28:14 CEST] <kierank> but none of these formats exist in the file world [16:36:13 CEST] <BBB> dont add it to swscale [16:36:17 CEST] <kierank> exactly [16:36:24 CEST] <BBB> just make it a decoder or something like that [16:36:41 CEST] <BBB> its really only a raw format in containers, right? its not like any actual real decoder outputs this format [16:36:47 CEST] <kierank> it's not even in containers [16:36:49 CEST] <kierank> it's in hardware [16:36:53 CEST] <BBB> I see... [16:36:55 CEST] <BBB> how shitty [16:36:56 CEST] <kierank> or intermediates to hardware [16:37:38 CEST] <BBB> so this is 5 bytes per 2 pixels uyvy? [16:38:43 CEST] <BBB> Id also like to push my filter today, so Ill send an updated patch later [16:38:47 CEST] <BBB> working on some other stuff first [16:39:13 CEST] <TD-Linux> shitty? that's what makes it professional broadcast grade (tm) [16:39:43 CEST] <kierank> just designed for fpgas that's all [16:39:50 CEST] <BBB> let me rephrase that: how professional [16:39:54 CEST] <BBB> how corporate? [16:40:45 CEST] <TD-Linux> right, it does let you convert colorspaces without any buffering [16:40:50 CEST] <wm4> does anyone know what AV_PIX_FMT_UYYVYY411 is good for [16:41:48 CEST] <TD-Linux> HDCAM dv files? [16:43:16 CEST] <kierank> 3:40 PM <TD-Linux> right, it does let you convert colorspaces without any buffering --> wow someone in OSS acknowledging broadcast design decisions :) [18:00:12 CEST] <cone-216> ffmpeg 03Clément BSsch 07master:cab9661dba47: sws/aarch64/yuv2rgb: honor iOS calling convention [18:00:41 CEST] <ubitux> wbs: some apple bs you might be interested in ^ [18:25:58 CEST] <atomnuker> Gramner: see any obvious way to speed this asm up? http://sprunge.us/YLTj?diff [18:27:00 CEST] <Gramner> that's a lot of shuffles [18:31:11 CEST] <kierank> seems overcomplicated, yes [18:33:29 CEST] <Gramner> input is u0 y0 v0 y1 u1 y2 v1 y3 u2 y4 v2 y5 u3 y6 v3 y7, right?. use one pshufb to turn that into u0 u1 u2 u3 v0 v1 v2 v3 y0 y1 y2 y3 y4 y5 y6 y7, then SBUTTERFLY:s until you're done [18:34:29 CEST] <kierank> yes [18:35:00 CEST] <atomnuker> but they're all in different registers [18:35:01 CEST] <kierank> input is 10-bit [18:35:16 CEST] <kierank> so just u0 y0 v0 y1 u1 y2 v1 y3 [18:35:27 CEST] <kierank> and u2 y4 v2 y5 u3 y6 v3 y [18:35:29 CEST] <Gramner> ah, yes. but same principle applies [18:39:12 CEST] <Gramner> actually the SBUTTERFLY macro wont help since the unpack sizes will be different for the lower and upper halves. just do unpacks explicitly then I guess [18:54:47 CEST] <Gramner> atomnuker / kierank: something like this (completely untested): http://pastebin.com/PYNFTSU2 [18:55:19 CEST] <kierank> Gramner: he has to learn =p [19:10:30 CEST] <atomnuker> well, it's not any faster on the 2 machines I tested on but it's shorter [19:12:24 CEST] <Gramner> that's weird. it's a lot fewer shuffles and shuffles are quite slow on modern intel cpus compared to everything else. or are you on a pre-haswell machine? [19:13:39 CEST] <atomnuker> skylake [19:14:27 CEST] <atomnuker> according to perf the last load (4*mmsize) is taking up most of the time [19:14:55 CEST] <Gramner> I wouldn't trust that [19:19:27 CEST] <Gramner> non-temporal stores might be worth it if you're dealing with entire frames though [19:19:33 CEST] <Gramner> e.g. movnta [19:21:31 CEST] <Gramner> er. I mean loads [19:23:46 CEST] <Gramner> or maybe non-temporal stores was more efficient? I don't remember [19:24:59 CEST] <atomnuker> well, dealing with just a single line here, so I don't know if it would help much [19:25:51 CEST] <kierank> doing that deliberately btw because there's an interlaced to field conversion necessary [19:26:53 CEST] Action: Daemon404 stabs rcombs [19:40:06 CEST] <wbs> ubitux: yep, I saw it. you'd have to have an insane amount of parameters to end up on the stack on aarch64 though [19:45:23 CEST] <ubitux> wbs: yeah but that happens with the unscaled path of swscale since it's not slice oriented but frame oriented, and you have all kind of coeffs and offsets [19:45:41 CEST] <ubitux> we could save a few args somehow though [19:46:47 CEST] Action: rcombs dies [20:14:04 CEST] <durandal_170> Nobody knows shorten? [21:48:30 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07master:6936c11533a4: fate: Add test for Ticket 2397 (dvdsub) [22:25:52 CEST] <furkan> would there be any interest in accepting a pull request to implement a SIP client for ffmpeg, to be able to connect to a SIP URL and play back the audio/video? [22:26:42 CEST] <JEEB> if it fits within the libraries' design feel free to send out a patch onto the ML [22:27:02 CEST] <furkan> ok, i haven't started yet, but was just considering it [22:27:16 CEST] <furkan> i'm looking now at how MPlayer does it, seems they use the live555 library [22:28:19 CEST] <furkan> seems like it just uses the SIP client to get the SDP description, and from that point on it's just RTP [22:33:19 CEST] <wm4> I don't know about this sip etc. crap, but doesn't ffmpeg already have stuff for this? just make sure it doesn't before you start... [22:36:12 CEST] <furkan> wm4: i was looking for it but couldn't find anything in the documentation [22:36:36 CEST] <furkan> i found that mplayer is able to play SIP URLs, so i started looking at the source code [22:37:14 CEST] <JEEB> wm4: seems like it's like telling the encoder/server to serve stuff in specific format or so [22:37:20 CEST] <furkan> and i know mplayer uses ffmpeg, but for the SIP URLs it uses the SIP client from live555 to get the SDP file [22:37:22 CEST] <JEEB> so not only reading stuff [22:37:37 CEST] <furkan> right, SIP negotiates the codec etc. for the session [22:37:56 CEST] <furkan> and then it generates an SDP file and you start streaming over RDP [22:37:59 CEST] <furkan> *RTP [22:39:04 CEST] <furkan> so the client requests the codec, server responds with an SDP file if it supports the codec, and then client starts streaming [22:39:56 CEST] <furkan> at least that's what i'm understanding by looking at libmpdemux/demuxrtp.cpp (in the mplayer source) [22:40:32 CEST] <furkan> *libmpdemux/demux_rtp.cpp [22:44:41 CEST] <wm4> sounds like something that would fit into libavformat anyway [22:45:34 CEST] <JEEB> probably [22:51:12 CEST] <jkqxz> Not sure that making SIP calls is really in scope. Doing the RTP handling, sure. But doing all the SIP stuff to make calls would rather quickly have to deal with SIP registrations and whatnot, which isn't obviously appropriate. [22:54:55 CEST] <furkan> jkqxz: isn't registration only needed if you want to receive calls? [23:03:46 CEST] <jkqxz> Directly, yes; but registrars and proxies tend to conflate in order to make identity work sensibly. The case you want is what; just outgoing ad-hoc calls to endpoints which will send one-way media to you? [23:05:44 CEST] <michaelni> atomnuker, aac-yoraw-encode fail under valgrind: http://fatebeta.ffmpeg.org/report/x86_64-archlinux-gcc-valgrindundef/201604… [23:10:50 CEST] <furkan> jkqxz: right, outgoing call and receiving one-way media [23:26:10 CEST] <jkqxz> furkan: I guess that's not unreasonable, assuming it doesn't scope-creep excessively. Do you have some particular use case in mind? [23:28:15 CEST] <furkan> jkqxz: the use case is that we have a sound system connected to the LAN, which you can call from a VoIP phone and listen to, but sadly it doesn't have an RTSP server or anything [23:28:28 CEST] <furkan> so i'd just like to be able to connect to the sound system, receive the audio, and stream it online [23:29:00 CEST] <TD-Linux> well ffmpeg already has support for SDP so it's not a big stretch [23:29:03 CEST] <furkan> but of course that's a really niche application... not sure if other people would have uses for it too [23:47:35 CEST] <cone-433> ffmpeg 03Paul B Mahol 07master:966d43d7786d: avcodec/shorten: fix decoding of last frame [23:47:36 CEST] <cone-433> ffmpeg 03Paul B Mahol 07master:a4790e1890a1: avformat/nistshperedec: add support for mu-law as sample-byte-format [23:47:37 CEST] <cone-433> ffmpeg 03Paul B Mahol 07master:c18fdc86928e: avcodec/shorten: remove useless if condition and comment, reindent [23:47:38 CEST] <cone-433> ffmpeg 03Paul B Mahol 07master:dee138624fdf: avcodec/shorten: fix decoding of files with number of samples lower than max_frame_size [00:00:00 CEST] --- Sat Apr 9 2016

1 0

ffmpeg.log.20160408
by burek 09 Apr '16

09 Apr '16

[00:03:38 CEST] <zamba> i have an old video that's got some interlace issues.. i grab this from /dev/video0 and video4linux2.. should i do the deinterlacing when capturing? [00:09:55 CEST] <llogan> zamba: you can give it a try. see yadif, w3fdif, and bwdif filters. I've only used yadif [00:10:04 CEST] <zamba> i settled for yadif [00:10:13 CEST] <zamba> it's just simply -vf yadif, right? [00:10:24 CEST] <llogan> yes, if you just want to use the defaults [00:10:34 CEST] <zamba> i don't have the knowledge to not use the defaults :) [00:11:14 CEST] <zamba> i also have some artifacts at the edges of the video.. how can i just remove this when capturing? [00:11:27 CEST] <zamba> the source is 720x576 [00:12:00 CEST] <llogan> as for yadif the mode option is likely the most important in your case. just try yadif=1 or yadif=0 and see what looks better. default is 0 but i find 1 looks better with some content [00:12:28 CEST] <llogan> what are the artifacts? just black padding? [00:13:59 CEST] <zamba> one sec.. i'll create a screenshot [00:16:32 CEST] <zamba> http://i64.tinypic.com/27wrgpx.png [00:17:47 CEST] <llogan> that's typical overscan from analog sources. the bottom looks like the usual head switching noise. [00:18:22 CEST] <zamba> how should i best handle it? [00:18:50 CEST] <llogan> i mean the overscan in broadcast monitors (and your old tv) will crop out the black border [00:19:18 CEST] <llogan> you can just leave it, you can cover it, or you can crop it [00:20:06 CEST] <zamba> well.. if i open it on a computer - which most people do these days, then they're a bit annoying [00:20:28 CEST] <llogan> if you're just viewing on a computer then feel free to crop that stuff [00:20:55 CEST] <furq> zamba: there's a new deinterlacing filter in 3.0 which should be better than yadif [00:20:58 CEST] <furq> https://ffmpeg.org/ffmpeg-filters.html#nnedi [00:21:30 CEST] <llogan> i wonder how slow it is [00:21:40 CEST] <furq> probably fairly slow [00:22:25 CEST] <zamba> well.. it should still be usable for SD video in real time encoding, or? [00:22:46 CEST] <zamba> too many options here.... :) [00:23:02 CEST] <furq> actually i wonder if it's multithreaded [00:23:07 CEST] <kepstin> it'd be... iffy on realtime, even if sd [00:23:12 CEST] <kepstin> it's not multithreaded [00:23:17 CEST] <furq> yeah that sounds bad [00:23:24 CEST] <llogan> zamba: also consider a little bit of denoising: see hqdn3d filter. then end the filterchain with format=yuv420p if your output is H.264 [00:23:26 CEST] <zamba> ok, we'll drop that, then [00:23:28 CEST] <furq> i get 40fps tops using multithreaded QTGMC, which is nnedi3-based [00:23:34 CEST] <furq> zamba: give it a try and see how slow it is [00:23:39 CEST] <zamba> llogan: now we're getting there [00:23:40 CEST] <furq> i would expect much better quality than yadif [00:23:53 CEST] <zamba> hm.. i have to get 3.0 [00:23:55 CEST] <kepstin> the nnedi3 filter *can* do realtime - if you use the windows implementation, which can be gpu-accellerated (it runs the neural net on a gpu) [00:24:24 CEST] <kepstin> the ffmpeg implementation is plain c with no gpu support. [00:24:59 CEST] <furq> with that said i've been dealing with DVDs [00:26:13 CEST] <furq> if it's a straight 50i signal and you want to convert it to 50p then yadif might do an ok job [00:26:31 CEST] <zamba> furq: how do i know if it is? [00:26:34 CEST] <furq> you could also just encode it interlaced and let the player do the job [00:27:05 CEST] <llogan> also, it is old analog stuff. may not make a huge difference which deinterlacer you use. [00:27:16 CEST] <zamba> furq: i thought the same, but i was going to preview it using the video tag in html5.. that has nothing like that, right? [00:27:53 CEST] <kepstin> yeah... i wouldn't expect the browser renderers to deinterlace. you'll want to do it before encoding. [00:27:53 CEST] <zamba> llogan: i'm sorry to bother you move, but could you provide me with an example of a full recommended list of options? [00:28:20 CEST] <zamba> llogan: you mention the hqdn3d filter, for instance.. but i have no idea about the optins [00:28:23 CEST] <zamba> options* [00:28:45 CEST] <zamba> currently i'm just doing: ffmpeg -f video4linux2 -i /dev/video0 -f alsa -i default -vf yadif <outputfile>.mp4 [00:28:47 CEST] <llogan> http://ffmpeg.org/ffmpeg-filters.html#hqdn3d-1 [00:28:49 CEST] <kepstin> to be honest, if it's VHS stuff, you might as well just halve the vertical resolution, dropping every other line. That'll turn the 50i into 50p without really removing any detail. [00:29:11 CEST] <kepstin> depends on the source quality tho [00:29:14 CEST] <furq> yadif does a halfdecent job of that without costing much speed though [00:30:52 CEST] <zamba> llogan: which of those options should i be using? [00:31:05 CEST] <furq> denoising is a bit of a black art [00:31:11 CEST] <furq> it's very much dependent on the source quality [00:31:11 CEST] <llogan> try the default first. if that doesn't work then monkey with it [00:31:32 CEST] <furq> basically, increase those numbers to remove more noise but also remove more fine detail [00:31:59 CEST] <zamba> llogan: what is the default? just -vf hqdn3d? [00:32:02 CEST] <furq> yeah [00:32:11 CEST] <zamba> so the command line will then look like? [00:32:12 CEST] <furq> -vf yadif,hqdn3d [00:32:16 CEST] <zamba> aight [00:32:30 CEST] <zamba> and then the stuff about ending the filterchain? [00:32:32 CEST] <llogan> didn't you want to crop? also, you forgot format [00:32:46 CEST] <furq> yeah put crop in the middle of those [00:32:58 CEST] <zamba> yeah, i think i want to either crop or replace it with some black parts [00:33:00 CEST] <zamba> what is "best"? [00:33:09 CEST] <kepstin> hmm, i'd put the crop before the yadif - it would reduce bad matches on edge noise. [00:33:13 CEST] <zamba> i guess there's a point in maintaining the aspect ratio, or? [00:33:57 CEST] <kepstin> zamba: most analog video captures intentionally capture an image wider than the standard "4:3" area, and for computer video you're pretty much intended to crop it or hide the extra during playback. [00:34:02 CEST] <furq> i figured it might screw with the field order but i guess it's set to autodetect anyway [00:34:23 CEST] <kepstin> hmm, if you crop an odd number of lines off the top, yeah :/ [00:34:39 CEST] <zamba> hehe, you're talking a bit over my head now.. :) [00:34:42 CEST] <llogan> zamba: are you going to make DVDs? or just files for watching on a computer and uploading to 'tube 'n stuff? [00:35:09 CEST] <zamba> llogan: i think maybe both.. but in today's age, primarily the latter.. meaning files for watching on a computer.. [00:35:16 CEST] <furq> zamba: it's probably best to just crop whatever you can unless you need a particular target resolution (e.g. for DVD) [00:35:35 CEST] <llogan> take a crop, if it's shitty you can dump it, wipe the file, and start over [00:35:55 CEST] <furq> the source AR isn't really significant, and you can set the DAR of the output file independently [00:36:05 CEST] <zamba> haha.. if you replace "crop" with "crap" there, then the whole sentence has a whole new meaning :) [00:36:23 CEST] <kepstin> if you do make a dvd later, you can always just put black borders back later. [00:36:24 CEST] <llogan> yeah, it was a bad joke... [00:36:31 CEST] <zamba> kepstin: yeah, i was thinking the same [00:36:38 CEST] <zamba> so.. what options do i end up with? [00:36:38 CEST] <furq> what would you do if your crop wasn't shitty [00:36:44 CEST] <furq> see a doctor? [00:38:10 CEST] <furq> i guess -vf crop=0:0:0:0,yadif,hqdn3d [00:38:23 CEST] <llogan> ,format=yuv420p [00:38:27 CEST] <furq> oh yeah [00:38:32 CEST] <kepstin> that would give you a 0x0 image, which would certainly compress well. [00:38:49 CEST] <furq> it'll compress even better after denoising [00:39:01 CEST] <iive> actually, it would compress infinitely bad :) [00:39:12 CEST] <furq> it'll be -1 bytes [00:39:55 CEST] <zamba> crop=0:0:0:0 is autocrop? [00:40:01 CEST] <furq> no [00:40:06 CEST] <furq> replace the 0s with your actual crop values [00:40:09 CEST] <zamba> ah [00:40:16 CEST] <iive> -vf cropdetect [00:40:23 CEST] <zamba> ah! i remember that one [00:40:49 CEST] <kepstin> lets see. I'd do crop=696:560:4:0 with the example image you posted [00:40:51 CEST] <furq> cropdetect tends to be too conservative [00:41:01 CEST] <llogan> cropdetect won't account for the ~10 px head switching noise [00:41:30 CEST] <zamba> -vf crop=720:560:0:6 [00:41:34 CEST] <zamba> it suggested that [00:42:01 CEST] <iive> you can quick test options with ffplay [00:42:09 CEST] <zamba> kepstin: yeah, i agree with you [00:42:11 CEST] <furq> http://oi64.tinypic.com/27wrgpx.jpg [00:42:13 CEST] <kepstin> zamba: yeah, cropdetect will give bad results with that video. I'd crop manually. [00:42:14 CEST] <furq> for that? [00:42:18 CEST] <furq> yeah that's no good [00:42:24 CEST] <zamba> kepstin: maybe even remove another pixel or two from the right side [00:43:03 CEST] <kepstin> zamba: make sure you crop with multiples of 2, at a minimum :) [00:43:27 CEST] <kepstin> (multiples of 8 are typically recommended, but that's not really an issue with modern codecs as much, any more) [00:43:39 CEST] <furq> it'll throw an error if you don't anyway [00:43:51 CEST] <iive> still, it is good to have it on block boundary [00:44:15 CEST] <kepstin> tell that to the people who picked 1080 as a standard vertical res for HD ;) [00:44:55 CEST] <kepstin> well, I guess that is a multiple of 8, but the block size of most of the codecs used for that is 16 now, iirc? [00:45:04 CEST] <iive> no [00:45:08 CEST] <zamba> so is that crop=694:560:2:0 ? [00:45:09 CEST] <iive> that's macroblock [00:45:43 CEST] <kepstin> zamba: I'd probably still take 4 off the left, since there's a bit of ringing there, but sure. [00:46:38 CEST] <zamba> so crop=694:560:4:0? [00:46:50 CEST] <furq> 692 [00:47:16 CEST] <kepstin> zamba: up to you, of course :) You'll want to preview it in at least a couple places over the video to make sure it looks good [00:48:02 CEST] <zamba> kepstin: well.. i don't know what i'm not seeing.. and i haven't fully understood the values and it's practical use [00:48:10 CEST] <zamba> height:width:x:y [00:48:13 CEST] <zamba> the x and y confuses me [00:48:28 CEST] <furq> x and y are offsets from the left and top [00:48:29 CEST] <kepstin> x is the offset from the left, y is the offset from the top [00:48:50 CEST] <kepstin> and it's width:height:x:y :) [00:49:57 CEST] <furq> the crop from the left side is x, the crop from the right side is input_width - (width + x) [00:50:04 CEST] <zamba> yeah, this looks good: crop=692:560:2:0 [00:50:48 CEST] <furq> i still find left:top:right:bottom more intuitive but it's probably a bit late now [00:51:12 CEST] <iive> btw, ffmpeg crop filter have another syntax. e.g. you can do stuff like `-vf crop=h=ih-6:y=4 ` [00:51:33 CEST] <iive> aka you can use formulas to calculate stuff. ih is input height [00:53:38 CEST] <zamba> ok, i tried with the new command and i immediately see that the bitrate has dropped quite significally [00:53:54 CEST] <furq> yeah denoising will do that [00:53:59 CEST] <zamba> $ ffmpeg -f video4linux2 -i /dev/video0 -f alsa -i default -vf crop=694:560:2:0,yadif,hqdn3d,format=yuv420p <output>.mp4 [00:54:11 CEST] <zamba> but that's a "good thing"? :) [00:54:23 CEST] <furq> it can be [00:54:26 CEST] <zamba> hehe [00:54:26 CEST] <furq> it sounds like it probably is in this case [00:57:08 CEST] <zamba> hm, no.. there's something very odd about the new video [00:57:13 CEST] <zamba> now the audio is out of sync [00:57:30 CEST] <iive> btw, i think that when you work with interlaced images, you have to round to 4, not just 2 [00:58:05 CEST] <iive> that is if you do work in yuv420 format. [00:58:37 CEST] <zamba> i don't know if i work in yuv420 format :) [00:59:00 CEST] <iive> i mean, about cropping image, or more precisely, the x,y (starting cut off) [00:59:14 CEST] <iive> you do have format=yuv420 in there :P [00:59:38 CEST] <zamba> so i should have crop=692:560:4:0? [00:59:47 CEST] <iive> i'm just not sure if it converts to yuv [01:01:08 CEST] <iive> hum, it converts to it [01:01:41 CEST] <iive> if your input is yuv444 or yuv422, then you can cut by 2 [01:02:11 CEST] <zamba> Stream #0:0: Video: rawvideo (YUY2 / 0x32595559), yuyv422, 720x576, 165888 kb/s, 25 fps, 25 tbr, 1000k tbn, 1000k tbc [01:02:20 CEST] <zamba> but there's something odd about the audio here [01:02:23 CEST] <iive> no problem then [01:02:48 CEST] <zamba> if i start playing the file with mplayer, then the video is all black.. i can hear the audio, but i have to seek to get the actual video [01:03:22 CEST] <zamba> oh, no.. i don't get video at all.. totally black video [01:03:27 CEST] <iive> the ffmpeg output result? [01:03:44 CEST] <zamba> yeah [01:04:46 CEST] <zamba> but the conclusion about the cropping is that i can round to 2? [01:05:41 CEST] <iive> zamba: you know that yuv420 have smaller resolution for chroma samples. [01:06:20 CEST] <iive> this means that for 4 pixels you have 4 luma samples (y) , 1 u and 1 v samples. [01:06:33 CEST] <iive> the 4 pixels are aranged in 2x2 block. [01:06:40 CEST] <zamba> *blank stare* [01:06:44 CEST] <zamba> what is chroma and luma? :) [01:07:05 CEST] <iive> luma is luminance, basically light intensity, or gray level [01:07:12 CEST] <iive> chroma is color [01:10:35 CEST] <zamba> i'll try removing the noise reduction and also the format thingy.. see if i have better results from playback [01:11:12 CEST] <iive> the noise won't change anything about playback [01:11:54 CEST] <zamba> well, something made the video unplayable [01:12:06 CEST] <iive> you do generally want to encode in yuv420, as it is most commonly used video format [01:21:04 CEST] <zamba> huh.. the problem was mplayer [01:23:43 CEST] <zamba> all of a sudden i had to specify -vo x11 [01:27:02 CEST] <zamba> heh.. sound is gone [01:27:20 CEST] <zamba> $ ffmpeg -f video4linux2 -i /dev/video0 -f alsa -i default -vf crop=694:560:2:0,yadif,hqdn3d,format=yuv420p <output.mp4> [01:27:23 CEST] <zamba> anything wrong with that? [01:28:04 CEST] <iive> zamba: are you with intel video as primary card? [01:28:28 CEST] <zamba> iive: the playback issue is no issue.. i can live with specifying -vo x11 for now [01:29:59 CEST] <zamba> just now i need to figure out how to get sound in my video again [01:31:37 CEST] <furq> pastebin the ffprobe output just in case [01:31:40 CEST] <zamba> http://pastebin.com/58VP3hCG [01:32:18 CEST] <furq> i guess that works too [01:32:21 CEST] <furq> looks fine [01:32:37 CEST] <furq> wait did you build that ffmpeg yourself [01:32:47 CEST] <zamba> furq: nope [01:32:53 CEST] <furq> is that from ubuntu repos? [01:33:00 CEST] <zamba> furq: well, i get no sound.. neither from ffplay, mplayer or vlc [01:33:09 CEST] <furq> it shouldn't have --enable-libfdk-aac if you downloaded the binary [01:33:29 CEST] <furq> although as far as you're concerned, that's a bonus, because that's the best aac encoder [01:33:45 CEST] <zamba> well, this is the machine doing the playback.. not the same as the one doing the encoding [01:33:53 CEST] <furq> oh [01:35:09 CEST] <furq> are you sure it captured any audio [01:35:15 CEST] <furq> it could just be silent rather than not playing [01:35:45 CEST] <furq> with that said, if that audio track is 134k VBR then it obviously contains something [01:37:35 CEST] <zamba> hehe, you're right [01:37:42 CEST] <zamba> somehow the alsamixer changed the capture source [01:40:16 CEST] <furq> fun [01:40:31 CEST] <furq> also you should make sure you're encoding with either libfdk-aac or the post-3.0 builtin aac encoder [01:40:39 CEST] <furq> all of the other aac encoders are crap [01:44:09 CEST] <zamba> err.. [01:44:20 CEST] <zamba> Stream #0:1: Audio: aac (libfaac) ([64][0][0][0] / 0x0040), 48000 Hz, stereo, s16, 128 kb/s [01:44:28 CEST] <furq> yeah libfaac is pretty bad [01:44:32 CEST] <zamba> oh, come on [01:44:48 CEST] <furq> if it sounds ok to you then it'll be fine [01:45:12 CEST] <furq> or you could use -c:v libmp3lame [01:45:16 CEST] <furq> er, -c:a [01:45:43 CEST] <zamba> this is an mp4 container [01:45:48 CEST] <zamba> mp3 will work fine there? [01:46:04 CEST] <furq> actually you mentioned playing it back in a browser didn't you [01:46:07 CEST] <furq> it's safest to stick with aac then [01:46:13 CEST] <zamba> exactly [01:46:25 CEST] <furq> mp3 should work anywhere in mp4, but i've had issues with it in browsers [01:46:58 CEST] <zamba> can i get a good version of ffmpeg from an apt source somewhere? [01:47:07 CEST] <zamba> so i can get a proper aac encoder? [01:47:15 CEST] <furq> where did you get that ffplay from [01:47:22 CEST] <furq> that apparently has fdk-aac [01:48:02 CEST] <zamba> hm.. how do i check that again? :) [01:48:30 CEST] <zamba> Version: 7:3.0.0+git1~trusty [01:49:03 CEST] <furq> https://launchpad.net/~mc3man/+archive/ubuntu/trusty-media [01:49:05 CEST] <furq> from there, by the looks [01:49:37 CEST] <furq> that should have both decent aac encoders then [01:49:40 CEST] <furq> or rather it does [01:50:03 CEST] <furq> it shouldn't have fdk-aac because you're not allowed to distribute ffmpeg binaries with fdk because of a fun license party [01:50:17 CEST] <furq> but apparently it does so you might as well make use of it [01:50:54 CEST] <furq> -c:a libfdk_aac -b:a 128k [01:50:59 CEST] <furq> or -c:a libfdk_aac -vbr 5 [01:51:44 CEST] <zamba> argh.. my encoding machine is running mint [01:52:16 CEST] <furq> you should still be able to use ubuntu PPAs on mint [01:52:29 CEST] <furq> failing that: http://johnvansickle.com/ffmpeg/ [01:52:36 CEST] <furq> that has the new builtin encoder (-c:a aac) [01:53:28 CEST] <zamba> ah.. static built ones [01:55:33 CEST] <zamba> what's ffmpeg-10bit? [01:56:41 CEST] <zamba> hm.. this new version complains a lot [01:56:53 CEST] <zamba> [alsa @ 0x3eb7780] ALSA buffer xrun. [01:56:55 CEST] <zamba> [alsa @ 0x3eb7780] ALSA buffer xrun. 29kB time=00:00:02.08 bitrate= 115.6kbits/s speed=0.517x [01:56:57 CEST] <zamba> [alsa @ 0x3eb7780] ALSA buffer xrun. 55kB time=00:00:04.24 bitrate= 106.5kbits/s speed=0.702x [01:56:59 CEST] <zamba> [alsa @ 0x3eb7780] ALSA buffer xrun. 84kB time=00:00:06.40 bitrate= 108.0kbits/s speed=0.792x [01:57:12 CEST] <furq> 10-bit has high-bit-depth encoders [01:57:21 CEST] <furq> if you care about compatibility you don't want those [01:58:07 CEST] <zamba> $ /usr/local/bin/ffmpeg -f video4linux2 -i /dev/video0 -f alsa -i default -vf crop=694:560:2:0,yadif,hqdn3d,format=yuv420p -t 01:05:00 12-jeppeturne.mp4 [01:58:09 CEST] <zamba> here we go [01:58:22 CEST] Action: relaxed wonders if anyone even uses ffmpeg-10bit [01:58:52 CEST] <furq> i use something called ffmpeg-10bit but not your binaries [01:59:05 CEST] <furq> i would if i wasn't on windows [01:59:11 CEST] <zamba> getting lots and lots of these "Past duration X too large" messages again [01:59:23 CEST] <zamba> it's probably just me, but i hate warnings that flood the screen [01:59:33 CEST] <furq> https://github.com/qruf/ffmpeg-10bit [01:59:49 CEST] <furq> in case anyone wants non-infringing windows binaries with 10-bit x264 [02:00:05 CEST] <furq> i should probably update those [02:02:38 CEST] Action: kepstin has his x264 set up so he can switch between the two by setting LD_LIBRARY_PATH :/ [02:04:09 CEST] <furq> that's nice but it doesn't really help people using static binaries [02:04:40 CEST] <kepstin> yeah, I'm still kind of annoyed that the x264 folks haven't looked at supporting both in one library [02:04:47 CEST] <furq> yeah [02:04:51 CEST] <furq> x265 seems to manage it just fine [02:05:43 CEST] <kepstin> it should be as simple as building it twice with symbol mangling, then have the initialization functions pick the implementation to use based on requested bit size. [02:05:57 CEST] <kepstin> but.. more work than I want to put into it, at least :( [02:06:23 CEST] <furq> i don't really mind having two ffmpeg binaries [02:24:59 CEST] <Prelude2004c> hey guys.. godo day [02:25:17 CEST] <Prelude2004c> having a serious problem and would like some help with it.. i am transcoding some data .. and i keep getting the system doing this [02:25:18 CEST] <Prelude2004c> [hls @ 0x295cf60] Non-monotonous DTS in output stream 0:1; previous: 8535563676, current: 8535043243; changing to 8535563677. This may result in incorrect timestamps in the output file. [02:25:18 CEST] <Prelude2004c> [aac @ 0x29c4720] Queue input is backward in time [02:25:30 CEST] <Prelude2004c> i already put in the copytb 1 [02:25:42 CEST] <Prelude2004c> still keeps coming up with that randomly.. can anyone help? [02:28:38 CEST] <Prelude2004c> anyone? [02:40:26 CEST] <davidmichaelkarr> I'm trying to play a mp4 on centos7, and it says I need a H-264 decoder. I installed "gstreamer-ffmpeg" because a SO posting said that would fix it, and it only changed where I got the message about needing that decoder. I have the nux-desktop repo. [02:41:00 CEST] <c_14> davidmichaelkarr: with what video player? [02:41:09 CEST] <llogan> c_14: centos7 [02:41:41 CEST] <c_14> Last time I checked that was an OS and not a video player. [02:42:06 CEST] <llogan> that was a joke [02:42:14 CEST] <c_14> ah :p [02:43:21 CEST] <c_14> long day [02:44:46 CEST] <davidmichaelkarr> c_14: Well, I first just tried double-clicking from file-roller, but someone just told me about "vlc", which appears to work. Any way to configure file-roller to open mp4s with vlc? [02:46:53 CEST] <davidmichaelkarr> c_14: I saw a page that talked about setting defaults when installing vlc, but I just installed it through yum. Is there a way to do this in the vlc interface? [02:47:50 CEST] <c_14> Probably. This isn't related to ffmpeg though. ask in #videolan or #centostnos exists) [02:48:02 CEST] <JPorter> hello, i was wondering if i can get clarifcation about using the ffmpeg library in proprietary software, it's not clear to me if that's allowed or not [02:48:13 CEST] <c_14> *#centos if that exists [02:48:33 CEST] <davidmichaelkarr> c_14: "centostnos"? That doesn't exist. [02:49:01 CEST] <c_14> davidmichaelkarr: X ate my input, I meant #centos [02:49:58 CEST] <c_14> JPorter: depends, the (L)GPL doesn't restrict use. It just places restrictions on redistribution [02:50:05 CEST] <davidmichaelkarr> c_14: Yeah, that's where I first asked this. That's where I heard about vlc. [02:50:09 CEST] <c_14> i.e. if you distribute your program linked against ffmpeg [02:50:52 CEST] <JPorter> c_14: do i have to do dynamic linking? [02:52:57 CEST] <furq> yes [02:52:58 CEST] <c_14> It's not a matter of _how_ you link, but _that_ you link. afaik you can link against an LGPL FFmpeg and redistribute so long as you also distribute the source code of FFmpeg along with it, and any modifications of the FFmpeg source code and make it possible for users to link your proprietary code against their version of FFmpeg (provided they patch it assuming you added patches) [02:53:06 CEST] <furq> https://www.ffmpeg.org/legal.html [02:53:09 CEST] <furq> there's a checklist here [02:53:31 CEST] <furq> you don't have to distribute the source of your application as long as you're using ffmpeg libraries compiled without --enable-gpl [02:53:36 CEST] <c_14> Note: we are all not lawyers, your lawyer knows best [02:53:48 CEST] <furq> and yeah, what he said [02:54:19 CEST] <JPorter> but would i be able to use these builds for instance: https://sanje2v.wordpress.com/2014/04/15/ffmpeg-lgpl-v3-binaries-for-window… [02:54:52 CEST] <furq> i guess [02:54:56 CEST] <furq> those are pretty old though [02:56:28 CEST] <furq> also that guy isn't distributing ffmpeg and library sources, which he's obliged to do [02:56:40 CEST] <JPorter> im confused why this guy provides static builds though [02:56:45 CEST] <furq> so i wouldn't trust him to be an expert on license compliance given he hasn't managed to comply himself [02:56:51 CEST] <JPorter> wouldnt .dll's be far more useful? [02:57:04 CEST] <furq> that is also a good point [02:57:30 CEST] <furq> i guess that's for people who want to distribute the binary with their application [02:58:25 CEST] <JPorter> to interact via command line? [02:58:30 CEST] <JPorter> is that allowed under LGPL? [02:58:33 CEST] <furq> if your app relies on an external ffmpeg binary for a significant part of its functionality it could be argued that it's a derived work [02:58:49 CEST] <furq> it's as allowed as linking is [02:59:33 CEST] <furq> you should probably just compile ffmpeg yourself, it's not that hard [02:59:47 CEST] <furq> especially if you don't need any external libraries [03:00:46 CEST] <JPorter> ive heard its quite a pain [03:02:21 CEST] <JPorter> is that why Zeranoe offers Quote Request [03:02:25 CEST] <JPorter> do they charge? [03:02:37 CEST] <furq> what else would quote mean [03:04:38 CEST] <JPorter> ive noticed you can only have windows builds with that [03:05:19 CEST] <furq> ? [03:07:00 CEST] <JPorter> on the quote request page [03:07:15 CEST] <JPorter> only windows build architecture is available [03:07:27 CEST] <furq> oh right [03:07:43 CEST] <furq> i doubt there's much money in offering linux builds [03:08:09 CEST] <JPorter> well i intend my software to be cross platform [03:08:16 CEST] <JPorter> particular mac & windows [03:08:47 CEST] <furq> like i said, it's not that difficult to build ffmpeg [03:09:02 CEST] <furq> on *nix, with no external libraries, it's three commands [03:09:10 CEST] <furq> and you can cross compile for windows and osx from *nix [03:09:26 CEST] <JPorter> hmm, well im on win tho have *nix vm [03:09:45 CEST] <JPorter> but i will need external libraries for mp3 [03:10:06 CEST] <furq> https://github.com/qruf/ffmpeg-mingw [03:10:09 CEST] <furq> you can give that a try if you want [03:10:22 CEST] <furq> it doesn't produce shared libs though [03:10:41 CEST] <kepstin> I actually found it easier to build ffmpeg for windows on a linux machine than natively on windows, when I was doing it :/ [03:10:49 CEST] <furq> yeah i've always cross compiled [03:10:49 CEST] <kepstin> dunno if that's changed since [03:10:57 CEST] <furq> i always had issues building libraries with msys [03:11:45 CEST] <furq> i've got a branch of ffmpeg-mingw which does produce shared libs but i've not finished or tested it yet [03:11:47 CEST] <JPorter> hmm, i guess i could do that in my vm then [03:11:50 CEST] <furq> i should probably finish it up [03:11:55 CEST] <kepstin> was kind of funny, the last time i was doing windows stuff with ffmpeg, I did all the dev on linux with mingw32 and wine. [03:13:59 CEST] <JPorter> what happens if i just build my application with shared ffmpeg GPL libraries, but don't distribute the libraries/dlls with my application and ask the user to obtain the dll and drop it into the application folder himself? [03:19:32 CEST] <JPorter> is that legal? [03:23:15 CEST] <c_14> I think so, but ianal [04:03:26 CEST] <JPorter> why do you need to literally include the source code rather than just provide a link to where you can obtain it, isnt that a little antiquated for LGPL projects? [04:04:57 CEST] <furq> because the link might die [04:05:48 CEST] <furq> you don't have to include the source code, you just need to make it available in the same place as the binaries are downloaded from [04:06:35 CEST] <furq> iirc it's sufficient to make it available on request, but if you're going to ensure you have it available if requested then you might as well just upload it [04:06:48 CEST] <furq> since you'd need the correct version etc [05:15:01 CEST] <Guest12199> Hi all [06:15:10 CEST] <Samsam> Hiiiiiiiiii [06:15:40 CEST] <Samsam> Could u please guide me what is the command line to encode a video to hevc? [06:30:48 CEST] <Samsam> Could u please guide me what is the command line to encode a video to hevc? [07:22:38 CEST] <pinPoint> does anyone know whether I could export from premiere cc bridge the export(temp file_ to ffmpeg and have ffmpeg do prores out? [07:23:01 CEST] <pinPoint> like a proxy [07:44:31 CEST] <pzich> pinPoint: you want to export from premiere in an intermediate codec, then re-render into a final prores encoding with ffmpeg? [07:46:36 CEST] <prago_1> hi. I try to extract all images of a video via "ffmpeg -f image%d.png myvideofile.avi" . How can I be sure to get the best image quality/resolution? because the videos are all of different qualities/resolutions? [07:49:02 CEST] <pzich> if you're using PNG as your output, the quality should already be "lossless", as best as it can decode it [07:49:58 CEST] <prago_1> ok. simple answer. thank you very much. thats what I wished to know. bye [08:19:36 CEST] <Gringe> Hey, I'm trying to do a low latency streaming from one Pc in my local Network to another. At the Moment the latency is about 1-2 Seconds. Therefor on the host side I run [08:19:50 CEST] <Gringe> ffmpeg -f dshow -framerate 24 -i video=screen-capture-recorder -vf scale=1280:720 -vcodec libx264 -force_key_frames "expr:gte(t,n_forced*2)" -pix_fmt yuv420p -tune zerolatency -preset ultrafast -f mpegts udp://239.255.1.2:1234 [08:20:00 CEST] <Gringe> and on clientside : [08:20:09 CEST] <Gringe> ffplay -fflags nobuffer -infbuf -fast -framedrop -vf "setpts=(PTS*0.95)" udp://239.255.1.2:1234 [08:20:20 CEST] <Gringe> any Ideas, how I could improve this ? [08:20:57 CEST] <Gringe> I am running host and client at the same Pc for testing [08:22:01 CEST] <zamba> furq: there's something seriously wrong with that static ffmpeg you linked me yesterday.. it only produced hiss and clicks for the audio.. [09:49:56 CEST] <pinPoint> pzich: I want to export to a proxy while picking it up with ffmpeg [09:50:08 CEST] <pinPoint> since premiere has not prores output [09:51:25 CEST] <pzich> I guess I don't know what you mean by proxy. In the past I've exported from Premiere or AE to something high quality, then had a script to watch for new .mov files and create a corresponding .mp4 [09:51:42 CEST] <pinPoint> ok [11:15:31 CEST] <Gringe> Hey, I'm trying to do a low latency streaming from one Pc in my local Network to another. At the Moment the latency is about 1-2 Seconds. Therefor on the host side I run [11:15:42 CEST] <Gringe> ffmpeg -f dshow -framerate 24 -i video=screen-capture-recorder -vf scale=1280:720 -vcodec libx264 -force_key_frames "expr:gte(t,n_forced*2)" -pix_fmt yuv420p -tune zerolatency -preset ultrafast -f mpegts udp://239.255.1.2:1234 [11:15:52 CEST] <Gringe> and on clientside : [11:16:01 CEST] <Gringe> ffplay -fflags nobuffer -infbuf -fast -framedrop -vf "setpts=(PTS*0.95)" udp://239.255.1.2:1234 [11:16:18 CEST] <Gringe> any Ideas, how I could improve this ? [11:21:45 CEST] <zamba> furq: nah, the result is very disappointing.. there's something very off with the audio [12:13:26 CEST] <momomo> does this make sense ? -b:v 2048k -bufsize 2048k -maxrate 300k ? [12:13:48 CEST] <momomo> maxrate should be the same no, but this has a different effect [12:14:34 CEST] <JEEB> how the effect is seen depends on the encoder. basically you are setting a rate control mode and then you are further limiting the max rate over bufsize to be 300k [12:17:11 CEST] <momomo> but the file output now is about 700kb .. when maxrate is at 2048 and bufsize the same i am hitting 2.7 mb [12:17:21 CEST] <JEEB> of course [12:17:32 CEST] <JEEB> maxrate in any sane encoder overrides your main rate control [12:17:36 CEST] <momomo> so it is not +- bufsize [12:17:54 CEST] <JEEB> bufsize is just the amount of bits during which the VBV/HRD rate is calculated [12:17:59 CEST] <momomo> libx264 [12:18:15 CEST] <JEEB> in layman terms, maximum allowed in VBV/HRD is maxrate over bufsize [12:18:35 CEST] <momomo> ook .. is a high bufsize good for cpu performance ? [12:18:47 CEST] <momomo> so i should go for maxrate to determine the output size [12:19:04 CEST] <momomo> i want to keep cpu usage low [12:19:15 CEST] <momomo> but be able to control filesize [12:19:46 CEST] <momomo> within say +- 100kb .. to around 2048 mb for 10 seconds [12:19:50 CEST] <momomo> kb [12:30:58 CEST] <momomo> high bufsize, performance implications ? [12:31:04 CEST] <momomo> anyone? [13:05:45 CEST] <Eiken_> anyone else getting a green border on the bottom of the output when encoding dnxhd .mxf files? [13:06:05 CEST] <Eiken_> input is 1920x1080 and dnxhd should always be that but becomes 1920x1088 [13:11:33 CEST] <Eiken_> lol [13:11:41 CEST] <Eiken_> i am stupid, that seems to be correct for those files [17:40:45 CEST] <momomo> how can I select the english audio track if there are multiple on the source ? [17:41:11 CEST] <furq> -map 0:a:language:eng [17:41:11 CEST] <c_14> -map 0:m:lang:eng [17:41:22 CEST] <furq> m? [17:41:32 CEST] <c_14> I'm pretty sure you need the m to match metadata [17:41:40 CEST] <furq> ah [17:41:43 CEST] <c_14> Says so in the manpage anyway [17:44:13 CEST] <momomo> is there a quick command to get the metadata only? right now, the first command is the ffmpeg to hls command [17:44:27 CEST] <momomo> i tried -map 0:a:language:eng .. i got the same audio but the picture is gone [17:44:37 CEST] <c_14> you also have to map the video stream [17:44:42 CEST] <c_14> -map 0:v:0 probably [17:44:49 CEST] <furq> using -map enables manual stream selection [17:45:00 CEST] <furq> unless you use it to deselect a stream [17:53:36 CEST] <zamba> furq: are you able to help me out a bit more? [17:54:01 CEST] <zamba> furq: running with the static ffmpeg gives me choppy audio.. lots of hiss and encoding static.. [17:54:30 CEST] <momomo> -map 0:m:language:eng -map 0:v:0 worked [17:54:35 CEST] <momomo> the others not [17:55:02 CEST] <momomo> zamba, maybe using libacc ... i upgraded to aac [17:55:16 CEST] <momomo> i was getting the same before .. i think it's gone [17:55:31 CEST] <furq> zamba: pastebin the command [17:56:27 CEST] <zamba> furq: oh, i have to run.. i'll check back over the weekend.. thanks :) [18:10:06 CEST] <SixEcho> so i'm using "ffmpg -f concat" - but would like it to copy the metadata from the first video& how to specify? [18:11:10 CEST] <SixEcho> actually these videos are from a gopro& and have a tmcd stream which concat does not work with is there any way to preserve the tmcd(timecode) streams and concat them? [18:12:47 CEST] <SixEcho> here is the concat warning: [concat @ 0x7f8e02800800] Could not find codec parameters for stream 2 (Unknown: none): unknown codec; Consider increasing the value for the 'analyzeduration' and 'probesize' options [18:13:08 CEST] <SixEcho> and the stream info: [18:13:09 CEST] <SixEcho> Stream #0:2(eng): Data: none (tmcd / 0x64636D74) (default) [18:13:09 CEST] <SixEcho> Metadata: [18:13:09 CEST] <SixEcho> creation_time : 2016-04-05 18:34:43 [18:13:09 CEST] <SixEcho> timecode : 18:33:36:31 [18:44:55 CEST] <himura> hi [18:46:50 CEST] <durandal_170> Hi [18:48:45 CEST] <himura> I am facing an "Unknown encoder 'libvo_aacenc' 'when trying to convert a file to .mp4 .webm [18:49:03 CEST] <furq> himura: which ffmpeg version [18:49:13 CEST] <furq> if it's newer than 3.0 then libvo_aacenc was removed [18:49:17 CEST] <furq> use -c:a aac [18:51:44 CEST] <himura> I use the versio 2.8.6 [18:51:50 CEST] <himura> on fedora 23 [18:54:51 CEST] <furq> himura: ffmpeg -codecs | grep aac [18:54:54 CEST] <klaxa> webm suports aac? [18:54:58 CEST] <klaxa> that's news to me [18:55:10 CEST] <furq> i assume he means to mp4 from webm [18:55:33 CEST] <klaxa> aah [19:09:22 CEST] <himura> problem solved furq [19:09:46 CEST] <himura> thank you [19:24:14 CEST] <rrva> is there any tool like http://gopchop.sourceforge.net/ but for h264? [19:28:49 CEST] <furq> you can cut on gop boundaries with ffmpeg [19:29:06 CEST] <furq> i don't know of any gui for it though [19:30:14 CEST] <furq> maybe avidemux [20:31:18 CEST] <ZeNEX> Hello guys. I am following a guide on how to use ffmpeg for development. A source file includes the header file ffmpeg/swscale.h however I do not find the ffmpeg libraries in Debian. What package should I look for? [20:32:27 CEST] <furkan> ZeNEX: try apt-file search swscale.h [20:32:35 CEST] <furkan> ZeNEX: in ubuntu the package name is libswscale-dev [20:32:59 CEST] <ZeNEX> furkan, apt-file command not found [20:33:15 CEST] <furkan> ZeNEX: you'll need to apt-get install apt-file, and then run apt-file update to download the database of files [20:33:34 CEST] <ZeNEX> Thanks [20:33:37 CEST] <furkan> i guess apt-file isn't a default package [20:33:39 CEST] <furkan> np [20:36:31 CEST] <furkan> i want to set up a computer that acts as a VoIP phone, so that anybody can call the computer's extension, and then the computer will stream the phone call to the internet via RTMP, does anybody know if ffmpeg can do this? [20:38:25 CEST] <c_14> If you can setup a SIP client to automatically accept all incoming calls and then feed the audio to an ffmpeg process it spawns, sure. [20:39:51 CEST] <c_14> eh [20:39:54 CEST] <c_14> you'll also need an rtmp server [20:40:05 CEST] <furkan> rtmp server is no problem [20:40:31 CEST] <furkan> i guess if there is a sip client that can stream to rtsp://localhost [20:40:50 CEST] <furkan> i could spawn the ffmpeg process myself and take the local stream as input, and then stream it to a remote rtmp server... [20:40:59 CEST] <c_14> You could check if there's a sip client with a "record command" option or something [20:43:06 CEST] <furkan> oh interesting, SIP uses RTP to carry the audio stream [20:43:13 CEST] <furkan> so i guess there must be a way to sniff that [20:51:02 CEST] <t4nk036> i failed compiling ffmpeg on ubuntu 14.04 [20:51:22 CEST] <t4nk036> problem starts here: pastebin.com/EuPTSCKK [20:52:28 CEST] <t4nk036> from following this guide: https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu [20:54:17 CEST] <c_14> did you ever run ./configure? [20:55:57 CEST] <t4nk036> yes, i copied the full command from the guide [20:57:25 CEST] <c_14> maybe your shell is fucking up. try only copying the part related to the configure [20:58:43 CEST] <t4nk036> im starting again from scratch [20:59:03 CEST] <kepstin> t4nk036: do one command at a time, and make sure it completes successfully before going on to the next. [21:00:34 CEST] <strk> given a set of .ts files, being the video and the audio streams in pieces, how can I get them played in sync and one after the other ? [21:00:56 CEST] <strk> like: segment262_1_av.ts segment429_0_av.ts segment595_1_av.ts segment761_1_av.ts segment99_1_av.ts [21:01:24 CEST] <kepstin> strk: cat segment262_1_av.ts segment429_0_av.ts segment595_1_av.ts segment761_1_av.ts segment99_1_av.ts >combined.ts [21:02:37 CEST] <strk> cat segment*_0_av.ts > combined_0_av.ts; cat segment*_1_av.ts > combined_1_av.ts [21:02:58 CEST] Action: strk just hopes the bash does the right thing [21:03:24 CEST] <strk> assuming it did, now how do I put togheter the two streamns ? (one is audio, the other is video) [21:03:47 CEST] <c_14> ffmpeg -i audio -i video -c copy out.ts [21:04:00 CEST] <c_14> assuming there's only 1 audio and 1 video stream [21:04:19 CEST] <kepstin> oh, it's separate audio and video files? [21:04:44 CEST] <furq> strk: glob expansion in bash should be in alphabetical order [21:04:54 CEST] <furq> so `cat *.ts > out.ts` should work [21:06:09 CEST] <furq> or should have worked, rather, since you already did that [21:06:42 CEST] <t4nk036> PATH="$HOME/bin:$PATH" PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" ./configure [21:06:47 CEST] <t4nk036> is that supposed to be one line? ^ [21:07:03 CEST] <furq> yes [21:07:23 CEST] <strk> segment1_ segment9_ segment111_ [21:07:30 CEST] <strk> alphabetical, unfortunately, won't work [21:07:42 CEST] <strk> also, therels _0_ and _1_ (two streams) [21:07:55 CEST] <strk> are you saying I should concatenate stream 0, stream 1 and back ? [21:08:13 CEST] <strk> kepstin: I _think_ they are separated, but not sure now [21:08:13 CEST] <c_14> cat segment*0* > a.ts; cat segment*1* > b.ts [21:08:23 CEST] <c_14> eeeh [21:08:25 CEST] <c_14> wait [21:08:46 CEST] <c_14> might need some better globs there [21:09:54 CEST] <kepstin> segment*_0_av.ts and segment*_1_av.ts would be better :) [21:10:14 CEST] <kepstin> I assume the 0 and 1 at the end refer to the stream, where one of them is audio, th other video [21:10:27 CEST] <kepstin> but yeah, you have to check and make sure that's correct :) [21:11:47 CEST] <strk> actually, stream _0_ seems to be all [21:11:55 CEST] <strk> maybe _1_ is another quality [21:14:55 CEST] <furq> ls -v segment*_0_av.ts | xargs cat >> out.ts [21:14:56 CEST] <furq> there [21:15:10 CEST] <furq> now you can delete everything you've done so far and run a slightly better command. hooray [21:17:08 CEST] <kepstin> ls with a glob is completely redundant... [21:17:19 CEST] <furq> -v is natural sort order [21:17:32 CEST] <furq> natural being 9 < 10 [21:17:37 CEST] <kepstin> ah, in case you have e.g. both 567 and 1234 ? [21:17:40 CEST] <furq> yeah [21:28:17 CEST] <strk> so stream 1 is higher quality, great [21:28:27 CEST] <strk> I used seq(1) to put order :) [21:48:59 CEST] <rrva> furq: how to cut on GOP boundaries, without any remuxing preferably [21:49:31 CEST] <rrva> furq: ssegment ? [21:49:42 CEST] <furq> just use -ss and -t [21:49:48 CEST] <furq> it'll seek to the nearest idr frame [21:50:26 CEST] <furq> if you want every gop as a separate file then use segment [21:59:15 CEST] <Prelude2004c> hey guys.. good day [21:59:17 CEST] <Prelude2004c> can anyone help me [21:59:28 CEST] <Prelude2004c> [20:24:14] <Prelude2004c> [hls @ 0x295cf60] Non-monotonous DTS in output stream 0:1; previous: 8535563676, current: 8535043243; changing to 8535563677. This may result in incorrect timestamps in the output file. [21:59:28 CEST] <Prelude2004c> [20:24:14] <Prelude2004c> [aac @ 0x29c4720] Queue input is backward in time [21:59:42 CEST] <Prelude2004c> not sure what to do about it.. i tried the async 1 but ti overloads the server and cpu [21:59:55 CEST] <t4nk036> can soneone link me to a good guide to cross compiling ffmpeg with mxe? [22:04:35 CEST] <BtbN> well, fix your source so it doesn't have non-monotonous DTS [22:07:27 CEST] <furkan> i can't seem to find a solution to my SIP problem... is there any way for ffmpeg to connect to a SIP URL? looks like mplayer can do it [22:08:13 CEST] <BtbN> ffmpeg is not a sip client, i'd be surprised if that works. [22:09:50 CEST] <furkan> and i can't find a SIP client i could use to pipe the RTP stream to ffmpeg... [22:10:11 CEST] <furkan> i'm sort of confused that there's no easy way to do this [22:10:16 CEST] <c_14> Well, sip uses both sdp and rtp and ffmpeg supports both. So on a certain level there isn't _that_ much missing. [22:12:24 CEST] <c_14> You're probably going to go furthest by finding an SIP library for your favorite scripting language which accepts calls and then forwards the rtp to ffmpeg [22:13:39 CEST] <furkan> c_14: hmm interesting idea... i'll see if there's a way i can do that with python, thanks for the suggestion [22:14:08 CEST] <furkan> if all else fails... maybe i should try to implement it myself in ffmpeg lol [22:14:35 CEST] <furkan> it can't be that bad, most of the pieces are in place as you pointed out [22:22:51 CEST] <Prelude2004c> BtbN , i can't fix the source [22:22:56 CEST] <Prelude2004c> it comes from satelite [22:23:14 CEST] <BtbN> well, nothing you can realy do then [22:31:21 CEST] <kurtcobain> I'm experiencing significantly slower encoding speeds with ffmpeg's VP9 encoder vs. the VP8 encoder (all else being equal). Is this a known problem? [22:31:48 CEST] <JEEB> vp9 and vp8 are both handled by libvpx [22:31:55 CEST] <JEEB> libavcodec just has wrappers for those [22:32:00 CEST] <furq> what makes you think two different codecs would be the same speed [22:32:02 CEST] <JEEB> the encoding that is [22:32:09 CEST] <hpp> VP9 and h.265 are soo slow [22:32:14 CEST] <JEEB> and yes, the vp9 encoding will be slow [22:33:11 CEST] <kurtcobain> I can't say I thought they would be the same speed, but I just wanted to confirm what I was seeing. [22:33:43 CEST] <kurtcobain> Only saw a couple of rumblings about it through searching Google, so thought it best to check here. [22:33:45 CEST] <kurtcobain> Thanks! [22:37:21 CEST] <andross> oops [22:37:40 CEST] <andross> im looking for help cross compiling from linux to windows [22:38:40 CEST] <furq> what kind of help [22:39:48 CEST] <JEEB> just install a mingw-w64 toolchain (either targeting 32bit or 64bit windows) and add it to your PATH [22:39:53 CEST] <JEEB> then set cross-prefix [22:40:11 CEST] <andross> is msx one of those tool chains? [22:40:17 CEST] <JEEB> no idea [22:40:25 CEST] <JEEB> probably someone distributing a toolchain, maybe [22:40:39 CEST] <JEEB> for specifics for specific toolchains, resort to their documentation or support [22:40:59 CEST] <JEEB> I can only say that you set the cross-prefix and maybe the OS? [22:41:12 CEST] <JEEB> and you can get FFmpeg itself built [22:41:16 CEST] <andross> set it where, on configure? [22:41:19 CEST] <JEEB> yes [22:41:26 CEST] <JEEB> ./configure --help | less [22:41:29 CEST] <JEEB> and seach for cross-prefix [22:41:32 CEST] <furq> andross: https://github.com/qruf/ffmpeg-mingw [22:41:35 CEST] <furq> you can try that if you want [22:41:37 CEST] <andross> also i wish to build shared/dynamic link libraries [22:41:38 CEST] <furq> it's pretty simple though [22:41:44 CEST] <furq> well that fell through quickly [22:41:48 CEST] <andross> heh [22:41:50 CEST] <JEEB> --disable-static --enable-shared [22:41:54 CEST] <JEEB> is all you need for shared-only [22:41:58 CEST] <JEEB> default is static [22:42:07 CEST] <furq> i should really fix up this shared library branch [22:42:12 CEST] <andross> well it cant be static for lgpl right? [22:42:29 CEST] <JEEB> it can but it makes it much less simple to be in general LGPL compliant :P [22:42:43 CEST] <JEEB> and you mean in a context where LGPL is used from a proprietary thing that is [22:42:51 CEST] <andross> yea [22:43:08 CEST] <JEEB> because LGPL is a license that gives the user the right to replace the library if he/she so wants [22:43:19 CEST] <JEEB> so for static you have to give everything required to link it :P [22:43:25 CEST] <JEEB> which includes your object files [22:43:51 CEST] <JEEB> for shared it's usually just the source code used to generate the library so the same kind can be built by the user and used instead [22:44:40 CEST] <JEEB> andross: http://fatebeta.ffmpeg.org/history/x86_64-mingw-w64-windows-native so you need cross-prefix, arch and target-os [22:44:47 CEST] <JEEB> those are three main params :) [22:45:05 CEST] <JEEB> the rest are stuff related to the configuration or testing setup [22:47:29 CEST] <JEEB> the toolchain you would want to have would either have i686-w64-mingw32-TOOL or x86_64-w64-mingw32-TOOL [22:47:41 CEST] <JEEB> depending on win32 vs win64 [23:04:27 CEST] <andross> sorry was away [23:05:35 CEST] <andross> hold on which one is win32 [23:05:55 CEST] <JEEB> mingw-w64 for win32 is i686-w64-mingw2- [23:06:18 CEST] <JEEB> mingw-w64 being the fork of mingw which is kind of updated [23:06:18 CEST] <andross> thats confusing :S [23:06:30 CEST] <JEEB> well, it's either i686 or x86_64 :P [23:06:45 CEST] <JEEB> although the name of the fork is kind of confusing because it started off as just having 64bit support [23:06:55 CEST] <JEEB> then "ye olde mingw" kind of withered off [23:07:03 CEST] <JEEB> so now mingw-w64 is the alive mingw [23:09:35 CEST] <andross> what is the package name for i686-w64-mingw32-TOOL? [23:11:07 CEST] <BtbN> package name? [23:11:41 CEST] <andross> how/where do i grab that toolchain [23:11:43 CEST] <TD-Linux> depends on distribution [23:11:59 CEST] <BtbN> emerge crossdev and instruct it to build you that toolchain [23:12:53 CEST] <andross> also just to clarify, im a windows user running an ubuntu virtual machine so i dont have much experience with linux [23:15:18 CEST] <furq> if you're on ubuntu just apt-get install mingw-w64 [23:15:25 CEST] <furq> you'll probably also need build-essential and yasm [23:16:50 CEST] <JEEB> yeah, which are standard compilation tools and yasm is to be used when building stuff for intel architectures [23:17:15 CEST] <JEEB> and yeah, git of course to get the source code :P [23:18:13 CEST] <furq> you can just get the snapshot [23:18:36 CEST] <JEEB> yeah, but what's the fun in that [23:18:54 CEST] <JEEB> not to mention you can jump between versions if you really require, as well as tag versions you've used before [23:21:52 CEST] <andross> okay i got mingw-w64 [23:22:46 CEST] <andross> can i just follow this guide until the final configure step https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu [23:28:44 CEST] <JEEB> no [23:29:12 CEST] <JEEB> also you shouldn't start off building a kitchen sink included build [23:29:57 CEST] <JEEB> just get ffmpeg's source code with git, get the mingw-w64 i686-w64-mingw32 toolchain (if you want win32 builds) and build-essential + yasm [23:30:04 CEST] <JEEB> then do a very basic configuration [23:31:03 CEST] <JEEB> ./configure --cross-prefix=i686-w32-mingw32- --arch=i686 --target-os=mingw32 --disable-static --enable-shared [23:31:28 CEST] <JEEB> you could even drop the last two for a test, but that should let you get shared FFmpeg built as LGPL (default) [00:00:00 CEST] --- Sat Apr 9 2016

1 0

ffmpeg-devel.log.20160407
by burek 08 Apr '16

08 Apr '16

[00:33:04 CEST] <durandal_1707> will push cri aix [00:51:31 CEST] <Shiz> ohi [09:09:52 CEST] <cone-122> ffmpeg 03Paul B Mahol 07master:2d720069a91b: avformat: add aix demuxer [09:52:03 CEST] <rcombs> Daemon404: nevcairiel: got movenc moved to auto-bsf [09:52:30 CEST] <rcombs> also, I'm adding an autobsf fflag (on by default) so things like dashenc and segment and movenc-test can turn it off [09:52:55 CEST] <rcombs> (the actual bsf insertion is harmless, but delaying the header can be problematic) [09:57:50 CEST] <rcombs> what version should I bump when adding a macro? [09:58:53 CEST] <rcombs> looks like minor [10:07:43 CEST] <nevcairiel> rcombs: Daemon404 already had that done, except it failed without such a flag so he moved it back for later [10:08:06 CEST] Action: rcombs shrugs [10:21:45 CEST] <rcombs> guh, but dashenc relies on mov_init running during dash_init [10:22:07 CEST] <rcombs> for time_base reasons [10:22:44 CEST] <rcombs> might be a good reason to expose an API to init a decoder without writing the header [10:22:48 CEST] <rcombs> s/decoder/muxer/ [10:22:51 CEST] <rcombs> I'm good at words today [10:23:31 CEST] <wbs> rcombs: doesn't dashenc already do that, by setting the delay_moov flag? [10:23:39 CEST] <wbs> so it effectively doesn't write anything to the output during write_header [10:24:59 CEST] <rcombs> it writes an initialization segment [10:26:00 CEST] <wbs> yes, but it only does this on the first call to dash_flush [10:27:31 CEST] <rcombs> oh, does it? [10:27:34 CEST] <wbs> yes [10:27:53 CEST] <wbs> in order to be able to write an edit list and all other stuff that requires you to know the first sample [10:28:27 CEST] <rcombs> well, still has the issue of mov_write_header wanting extradata [10:29:17 CEST] <rcombs> though it might be harmless for it to be missing at write_header time [10:29:22 CEST] <wbs> it actually can do that later as well, look for "copy extradata if it exists" in ff_mov_write_packet [10:29:31 CEST] <rcombs> yeah, just saw that [10:29:33 CEST] <wbs> although I'm not sure if this strictly is permitted after codecpar any longer [10:29:37 CEST] <rcombs> not sure how that interacts with codecparyeah [10:31:46 CEST] <rcombs> hmm, I guess I'll assume it's fine for now and then I can change it later if need be [10:40:04 CEST] <rcombs> gah, I definitely need that for segment though [10:40:22 CEST] <rcombs> welp guess I'll do that tomorrow [11:06:32 CEST] <omerjerk> Hi [11:06:54 CEST] <omerjerk> What's the IRC handle of Thilo Borgmann ? [11:07:12 CEST] <omerjerk> I couldn't find it on the GSoC page. [11:07:23 CEST] <nevcairiel> dont think he does irc [11:07:25 CEST] <nevcairiel> best to mail him [11:07:40 CEST] <omerjerk> ohkay. [12:56:11 CEST] <durandal_1707> michaelni: whats needs to be done for not accepting proposal, just not mentoring it? [13:14:40 CEST] <michaelni> if theres no mentor then a proposal cannot be accepted, also you can comment in the gsoc web interface or send a mail to the admins, i dont know why the rateing system gsoc had last year so everyone could rate proposals isnt there anymore [13:42:18 CEST] <wm4> durandal_1707: can has a/v source filter for A/V sync testing [13:43:03 CEST] <cone-285> ffmpeg 03Michael Niedermayer 07master:c169062073d7: swscale/utils: Remove unused variable [13:43:07 CEST] <durandal_1707> wm4: I need more info [13:44:09 CEST] <wm4> durandal_1707: generate some sort of audio blip that happens at the same time as a flash on the video or something [13:44:18 CEST] <wm4> there are many test videos out there that do this [13:44:53 CEST] <wm4> and while those test videos do the job, it'd be nice if it could be done without involving actual decoders, demuxers, and their bugs [13:45:56 CEST] <wm4> (and sample rate and video FPS should be adjustable if possible) [14:19:21 CEST] <cone-285> ffmpeg 03F.Sluiter 07master:3a9611d623fe: avfilter: add remap filter [14:39:00 CEST] <durandal_1707> wm4: what frame size in samples than to pick? [15:01:59 CEST] <ubitux> http://b.pkh.me/psy.jpg i love when i end up with glitches like this [15:04:10 CEST] <ubitux> (should be http://b.pkh.me/nopsy.jpg ; i might have messed up a bit) [15:45:34 CEST] <kierank> durandal_1707: that's the problem [15:45:38 CEST] <kierank> you can't align the two [15:55:22 CEST] <durandal_1707> one dont need to [15:55:42 CEST] <durandal_1707> There are pts [15:57:14 CEST] <kierank> so in the simple case of ntsc, how many samples do you make your blip when a single frame blips? [15:57:23 CEST] <kierank> and then extend that complexity to vfr [15:58:39 CEST] <durandal_1707> Blip starts and end with flashing frame [15:58:41 CEST] <BBB> ubitux: nice artifact [15:59:11 CEST] <BBB> ubitux: do you want to give my patch another full round of review? or should I ask others? [15:59:16 CEST] <BBB> (maybe simd needs someone else to review) [15:59:58 CEST] <durandal_1707> kierank: duration of frame [16:00:09 CEST] <kierank> durandal_1707: which has not integer number of audio samples [16:00:42 CEST] <durandal_1707> rounding? [16:01:44 CEST] <kierank> then the player has to resample [16:01:46 CEST] <durandal_1707> I'm still amazed that there's shorten in nistsphere [16:01:53 CEST] <kierank> or drop/dup audio samples [16:06:02 CEST] <kierank> BBB: did a bit of cosmetic asm review [16:07:08 CEST] <BBB> \o/ [16:07:19 CEST] <BBB> wait, I dont see it [16:07:31 CEST] <BBB> oh there it is [16:08:10 CEST] <BBB> Ill look into variable sharing between filters, I dont remember exactly where that stands [16:08:21 CEST] <BBB> (so yes I totally ignored that, my bad) [16:42:30 CEST] <Daemon404> feelin' pretty good about codecpar [16:42:40 CEST] <Daemon404> tentatively can merge on sat/sun [16:43:07 CEST] <Daemon404> (i would have said friday, but i would then have to push the merge and hope on a plane for half a day with no wifi) [16:49:57 CEST] <wm4> yeah that seems fine [16:52:00 CEST] <kierank> Gramner: any more optimisations we can make for http://sprunge.us/OjTX?diff [16:52:09 CEST] <kierank> it's doing planar 8-bit to uyvy422 10-bit [16:52:43 CEST] <durandal_1707> Upsampling is evil [16:58:14 CEST] <kierank> durandal_1707: why [16:58:50 CEST] <durandal_1707> you don't do debanding [16:59:09 CEST] <kierank> it's meant to be a bitexact conversion though [17:00:40 CEST] <durandal_1707> It is ugly, 8bit is ugly [17:01:43 CEST] <kierank> I agree but people send us that [18:09:36 CEST] <Gramner> kierank: only comments I have is basically the same as the ones I wrote for planar_to_uyvy_10, but those are kind of minor stuff [18:09:45 CEST] <kierank> ok thanks [18:20:04 CEST] <BBB> michaelni: why would you add a format more than once, and why would you use atomics for something that could simply use a lock around the whole function since its utterly and clearly not at all performance sensitive in any way whatsoever? [18:22:11 CEST] <kierank> different threads I guess [18:29:51 CEST] <michaelni> BBB, as kierank says, different threads [19:02:37 CEST] <wm4> https://twitter.com/NicolasWeil/status/717728473960333313 [19:02:58 CEST] <kierank> wm4: you read my twitter trolls right? [19:04:23 CEST] <wm4> no [19:04:32 CEST] <TD-Linux> kierank, I did, they were quality [19:07:24 CEST] <JEEB> wm4: oh wow, that IP over broadcast stuff is going to ATSC as well? [19:07:42 CEST] <JEEB> I read the Japanese spec and went to sniff some paint afterwards to brain bleach it out of my mind [19:08:41 CEST] <TD-Linux> I have a hard time seeing the FCC accepting this for over the air at least. [19:23:15 CEST] <BBB> michaelni: of course different threads, dude, you know Im not a 101 n00b - but why use atomics and all this hideous stuff instead of a lock around the function? is this performance critical? [19:44:58 CEST] <cone-583> ffmpeg 03Mulvya 07master:b7a776aa7bb6: doc/filters: add drawtext example [20:32:01 CEST] <michaelni> BBB, a lock around t could be used but it would need to be created, its possible wth AVOnce, not sure if that would be simpler, unless i miss some simpler API I was just trying to fix the bug. [20:32:30 CEST] <BBB> what youre currently creating is one big race [20:32:49 CEST] <BBB> I really dont think its a good idea to try and support concurrency in any realistic way between multiple threads calling register without locks [20:32:52 CEST] <BBB> it just doesnt make any sense [20:33:43 CEST] <Daemon404> context for this? [20:33:54 CEST] <BBB> patch on ml [20:34:18 CEST] <michaelni> BBB i wasnt trying to avoid a lock [20:34:29 CEST] <Daemon404> oh [20:34:45 CEST] <michaelni> the original code predates AVOnce [20:35:02 CEST] <BBB> so lets not make it any worse :) [20:40:57 CEST] <michaelni> do we have a clean &simple API to create a "once" mutex ? or its needed to hack one into existence with AVOnce ? [20:57:35 CEST] <jamrial> michaelni: you can use static initialization, if that's what you mean [20:58:22 CEST] <jamrial> static AVOnce once_init = AV_ONCE_INIT; [20:58:45 CEST] <wm4> we could also extend the windows wrapper to support static initializers [20:59:06 CEST] <wm4> but it'd probably lower performance (not sure if we can get fast and correct double-checked locking) [20:59:17 CEST] <jamrial> it already does, for pthread_once at least [20:59:40 CEST] <michaelni> something like PTHREAD_MUTEX_INITIALIZER would be usefull [20:59:43 CEST] <wm4> hm or actually that isn't even needed, whether the mutex is statically initialized or not is a constant flag [21:00:02 CEST] <wm4> the main "problem" is that unloading libavformat as dll would leak memory [21:00:11 CEST] <wm4> (potentially) [21:03:18 CEST] <wm4> maybe we could allocate some sort of exit handler to free the mutex... [21:03:56 CEST] <michaelni> one problem with using new APIs in bugfixes though is that bugfixes cannot be backported [21:03:59 CEST] <wm4> for now I'd still consider this superior to potential race conditions [21:04:04 CEST] <wm4> ah hm [21:05:08 CEST] Action: Daemon404 wonders how one even manages to hit this bug in normal code [21:06:02 CEST] <michaelni> i hit it with my eyes when reviewing a pull request fro github ... i agree that its pretty hard to hit that in actual code [21:07:52 CEST] <jamrial> wm4: did you ever get around to use pthread_once to fix the race in crc table generation? [21:10:27 CEST] <wm4> ah, no [21:10:32 CEST] <wm4> that should be done [21:25:49 CEST] <Daemon404> michaelni, what are your thoughts on merging on saturday [21:37:37 CEST] <michaelni> I suspect waiting longer would not improve the commit much [21:38:06 CEST] <Daemon404> i agree [21:39:06 CEST] <Daemon404> so saturday it is. [21:39:43 CEST] <wm4> looking at the commit message for the avconv codecpar update: " The switch is not yet complete because the parsers and the bistream filters do not have a new AVCodecParam-based API yet." [21:39:44 CEST] <wm4> hurr [21:40:01 CEST] <wm4> also adds FIXMEs to the code [21:41:38 CEST] <Daemon404> wm4, my idea was to noop that commit and wait until the bitstream filters were merged [21:41:43 CEST] <Daemon404> and then convert ffmpeg.c [21:42:11 CEST] <wm4> might be a good idea [21:42:21 CEST] <wm4> I don't think converting ffmpeg.c should be done as merge anyway [21:42:30 CEST] <wm4> (not sure how this was handled in the pasT?) [22:58:19 CEST] <cone-583> ffmpeg 03Paul B Mahol 07master:0c9490609d88: avformat: support shorten in nistshpere demuxer [00:00:00 CEST] --- Fri Apr 8 2016

1 0

ffmpeg.log.20160407
by burek 08 Apr '16

08 Apr '16

[00:01:59 CEST] <durandal_1707> what? [00:04:30 CEST] <bergeron37> Is there a way to know when the segment muxer is done with a file? [00:05:36 CEST] <bergeron37> My thought is to have it save the files to a particular directory and maybe watch that directory for changes using watchdog in python, but that doesn't feel particularly great [00:11:45 CEST] <c_14> The segment muxer is done with a file when it starts with the next one. [00:11:48 CEST] <c_14> Why do you care? [00:14:33 CEST] <bergeron37> @c_14 I care because once that file is no longer being modified, I want to do something with it [00:15:37 CEST] <bergeron37> My best solution right now is to watch the directory where the files are being saved and doing something with the file that was modified before the file that was just created [00:16:17 CEST] <Tiago_> durandal_1707: When i set a callback function for locking (CRYPTO_set_locking_callback), i usually tested like: if(mode & CRYPTO_LOCK) [00:16:24 CEST] <Tiago_> now the CRYPTO_LOCK seems to not be defined [00:20:42 CEST] <c_14> bergeron37: either that, or use a segment_list and watch that. ffmpeg will replace the file every time a file is finished writing and the last entry in the list will be the finished file. [00:21:54 CEST] <bergeron37> @c_14: I might like that better than just watching some arbitrary directory. I'll look into it. Thanks! [00:23:28 CEST] <c_14> Just to clarify, you can't just run tail on the file because the file is atomically replaced with rename instead of appended to. [00:25:59 CEST] <mxisaac> anyone have a workflow for doing distributed encoding over a network? [00:27:00 CEST] <mxisaac> i deal with batch transcoding at a post production facility, and I'm trying to figure out how to distribute the transcode to our network of 20 computers. [00:28:14 CEST] <c_14> chop the input up by keyframe, remove audio, scatter, encode, reduce, add audio [00:30:21 CEST] <mxisaac> hmm, would need to preserve timecode too. [00:30:42 CEST] <mxisaac> maybe that can be striped back in. [00:30:45 CEST] <c_14> preserve timecode? [00:30:54 CEST] <mxisaac> 05:21:01:22 [00:31:07 CEST] <c_14> What is that? duration? [00:31:27 CEST] <c_14> Is it metadata, or? [00:31:58 CEST] <mxisaac> It's probably metadata. Each frame assigned a number. It's more commonly now just the time of day. [00:32:41 CEST] <mxisaac> So the video would start at HH:MM:SS:ff (Hours, Minutes, Seconds, Frames) [00:32:50 CEST] <bergeron37> @c_14 thanks! [00:33:59 CEST] <c_14> If it's the PTS, you can use -copyts if it's stream metadata you can map that from the source file during the final concat [00:51:38 CEST] <mxisaac> hmm not familiar with -copyts, lemme read more about it [00:51:43 CEST] <TAFB> Hey folks :) I'm trying to use ffmpeg to stream a mp4 file from my computer to a nginx rtmp re-streaming server. The video file is 25fps but after it has been streaming for a minute or two the frame rate drops down to 23fps or so, which causes my viewers to run out of buffer (using VLC player for example). So every few minutes VLC player will pause while the buffer fills back up then continue [00:51:43 CEST] <TAFB> playing for a few minutes, then pause and wait for the buffer again. Pretty annoying :( [00:51:53 CEST] <TAFB> I'm using this commandline: ffmpeg -i "source_video.mp4" -c copy -f flv rtmp://myserver.com/myapp/mystream [00:52:16 CEST] <furq> er [00:52:16 CEST] <TAFB> I tried with the recommended -re switch but then it's even worse, streaming at around 19fps so it runs out of buffer lots :( [00:52:25 CEST] <furq> i don't see how that's working without -re [00:52:50 CEST] <furq> unless you're bandwidth limited [00:55:04 CEST] <TAFB> I should be. The stream is bitrate=2473.9kbits/s and my isp upload is 10mbps and I've tested my connection to the nginx-rtmp server at around 8.5mbps using winscp sftp upload. [00:55:09 CEST] <TAFB> i shouldn't be :) [00:56:01 CEST] <TAFB> if I could somehow force ffmpeg to spit out 26fps then it would probably solve the problem [00:56:52 CEST] <mxisaac> thanks @c_14 [00:57:29 CEST] <petecouture> TAFB: It sounds like you need to create a 30 second window for playback [00:57:40 CEST] <petecouture> I believe you'll need to run ffserver in front of ffmpeg to do that. [00:57:54 CEST] <furq> no [00:58:01 CEST] <furq> please don't tell people to use ffserver [00:58:03 CEST] <TAFB> never heard of ffserver before :D [00:58:14 CEST] <furq> you should keep it that way [00:58:31 CEST] <petecouture> furq: Isn't that how you handle sliding windows in ffmpeg? [00:58:40 CEST] <petecouture> and MBR [00:59:07 CEST] <TAFB> ffserver work on windows? [00:59:17 CEST] <furq> i don't think ffserver is how you handle anything other than wasting an afternoon on broken unmaintained software [01:00:08 CEST] <furq> fortunately i don't think it works on windows anyway [01:00:34 CEST] <petecouture> hmm good to know. My understanding was ffserver is needed to do both slidingwindows/DVR and also to create MBR m3u8's [01:00:36 CEST] <furq> TAFB: i've used that exact command (plus -re) to stream to nginx-rtmp a bunch of times and it works fine [01:00:51 CEST] <TAFB> ok, I'll try -re again, brb [01:00:51 CEST] <furq> so i assume there's some non-ffmpeg problem [01:01:00 CEST] <petecouture> TAFB what's your encoding setting? [01:01:07 CEST] <furq> it shouldn't work at all without -re, it ought to be streaming as fast as it can decode [01:01:18 CEST] <petecouture> make sure -re is at the output end and not the input end TAFB [01:01:20 CEST] <furq> so there's obviously some external limitation [01:02:35 CEST] <TAFB> petecouture: could you give me an example command line based on the one I posted? [01:02:49 CEST] <furq> put -re before -i [01:02:55 CEST] <furq> that's it [01:02:59 CEST] <petecouture> err [01:03:12 CEST] <TAFB> furq: my ISP has been having problem with my cable modem upload (dropping packets) so that might explain the issue. [01:03:21 CEST] <furq> that sounds like cable [01:04:06 CEST] <petecouture> TAFB: Is it your home line? I've noticed Timewarner has been getting fussy with me streaming a satalite outta my house lately. [01:04:29 CEST] <TAFB> yep, my home isp (I'm in Canada) :) [01:04:42 CEST] <TAFB> with the -re switch VLC player studders almost constantly [01:05:45 CEST] <furq> can you install nginx-rtmp on localhost/lan and see if it has the same issue [01:06:00 CEST] <TAFB> if it can run on windows, sure. [01:06:17 CEST] <furq> nginx can [01:06:42 CEST] <furq> now you get to experience the joy of cross-compiling [01:06:50 CEST] <TAFB> nice. I could tell ffmpeg to re-encode the stream at a lower bitrate and see if that helps (to see if it's a bandwidth issue). [01:07:07 CEST] <furq> yeah, or use a lower-bitrate source file [01:07:23 CEST] <TAFB> ahhhh, I can do that! 1 sec :D [01:12:45 CEST] <TAFB> seems to be streaming a slightly lower bitrate file like a champ, no hesitation in vlc player yet [01:13:39 CEST] <furq> fwiw i can stream 6mbit fine with 10mbit cable upload [01:13:56 CEST] <furq> so if you can't manage 2.5mbit then something's wrong [01:14:08 CEST] <Tiago_> https://www.openssl.org/docs/man1.0.1/crypto/CRYPTO_set_locking_callback.ht… [01:14:23 CEST] <Tiago_> how I can know how to port the locking code to newest version? [01:22:28 CEST] <TAFB> furq: yeah, hopefully they fix my internet before the weekend :) [04:30:22 CEST] <balrog> hi all [04:30:30 CEST] <balrog> why would avformat_open_input() return EINPROGRESS? [05:32:00 CEST] <TAFB> i need some serious help :( for 3 days I've been trying to get a smooth uploading streaming, nothing is working. I'm 100% sure it's not upload bandwidth. I just tried HLS streaming and I see it download a big chunk, then my internet connection sits there and does nothing and it gets to the end of the chunk and sits there for a few seconds, THEN downloads the next chunk. Complete joke :( [05:33:05 CEST] <TAFB> What I'm doing is capturing a live .flv and re-streaming it (so it'll be like 60 seconds behind) which should be TONS of buffer but ffmpeg only uploads it at 25fps (same as the video file), so the nginx rtmp streamer never "gets ahead" [05:33:43 CEST] <TAFB> so if you know of a good solution I can a) run on windows to stream the .flv file live to b) some re-streaming software that runs on my ubuntu vps server. [05:35:29 CEST] <Prelude2004c> hey guys.. quick question.. i have a mpegts source that has a video and two audio pids. ( eng and san [described video]), i am encoding but the san is coming up first... is there some way to set it to map english to the first channel and san to the second channel ? [05:45:53 CEST] <Ekho> is webm vp9 video encoding limited to 1 thread? [05:46:05 CEST] <Ekho> I cannot seem to get anything above 8% cpu usage [05:59:31 CEST] <Prelude2004c> hey anyone know what this means or how to fix this ? Non-monotonous DTS in output stream .. i am encoding and hours later it starts to do this [05:59:33 CEST] <Prelude2004c> i am not sure why [08:05:46 CEST] <petecouture> Do the ffpresets use the old naming convenstions? I seem to have issues trying to write script using c:A [08:05:50 CEST] <petecouture> err c:a rather [14:23:40 CEST] <hendry> I want to edit an mp4 in Audacity to improve its sound [14:24:12 CEST] <hendry> by then it cant export directly back into the mp4. i wonder if there is recipe to replace the audio track of an mp4? [15:09:34 CEST] <potus> anywhere here got the magic code for youtube's 4k videos? [15:10:43 CEST] <potus> I am uploading a true 4k movie in .mov mpeg4 video mpeg 4 audio 4096x 2160.. once uploaded.. youtube only gives me 720... not even 1080 [15:10:46 CEST] <cowai> is -c:v h264 and -c:v libx264 the same? Or h264 a native encoder? [15:11:25 CEST] <cowai> potus: have you tried in a google blessed browser like google chrome? [15:11:36 CEST] <potus> cowai: tried uploading or playing? [15:11:46 CEST] <cowai> playing [15:11:50 CEST] <potus> no [15:12:00 CEST] <cowai> I remember using firefox on linux and only got 720 [15:12:05 CEST] <potus> i have iceweasle i dont trust them google people ;-) [15:12:11 CEST] <potus> ooo [15:12:16 CEST] <cowai> I guess its that [15:12:18 CEST] <potus> cowai would u mind just checking to see if the option is there for u? [15:12:31 CEST] <cowai> yes no problem [15:12:38 CEST] <cowai> give me the link and I can try [15:12:40 CEST] <potus> https://www.youtube.com/watch?v=G0JkO4pGwa4 [15:13:04 CEST] <cowai> I get everything up to 2160p [15:13:32 CEST] <cowai> this is in firefox. I guess google fixed it for firefox, but not iceweasel. [15:13:34 CEST] <potus> really? [15:13:37 CEST] <potus> fyucking a it worked!!!! [15:13:56 CEST] <cowai> yeah really :) [15:14:21 CEST] <cowai> 2160p at the top, 1440p second, and 1080p as third. [15:14:34 CEST] <potus> i was stressing i spent 4 days in cinelerra battling! [15:14:42 CEST] <potus> audio offset.. the bane as they say.. [15:15:06 CEST] <potus> turned out.. i was using 5.0 which isnt the latest version 2.3 is.. (boggled) hadda compile it from source and got jackpot! [15:15:36 CEST] <potus> cowai: i wonder why i dont get the 4k label next to the video like it shows up for some in my search [15:16:57 CEST] <cowai> Need to go, my wife needs to go to the doctor! [15:17:14 CEST] <potus> thanks for help cowai [15:17:17 CEST] <potus> cya soon [15:17:20 CEST] <hendry> potus: you edited under linux? [15:17:24 CEST] <potus> hendry yes [15:17:30 CEST] <potus> all open source free software as well [15:17:33 CEST] <potus> =) [15:17:39 CEST] <hendry> potus: does cinelerra-cv do audio sync ups? [15:17:49 CEST] <hendry> i thought cinelerra-cv was limited to 1080p or something like that [15:18:17 CEST] <potus> hendry: cinelerra-cv 2.3 synced audio out of box. after a prolonged apt-file search <deps> one by one [15:18:38 CEST] <potus> i compiled it from source... now the cinelerra from cinelerra.org altho offering more plugins.. does not work and audio is out of sync [15:19:01 CEST] <potus> people say u can add offsets.. but they are not true.. e.g. when u add a 1 second offset it does nothing to the video. [15:19:23 CEST] <hendry> potus: what's the URL to your video btw? [15:19:33 CEST] <potus> i ended up having to do quicktime for linux with 4096x2160 mpeg 4 video and mpeg 4 audio.. according to cowai it works in 4k! [15:19:56 CEST] <potus> hendry: scroll up 2 screens [15:21:48 CEST] <potus> hendry: do u got 4k display? [15:21:56 CEST] <hendry> yes, i see the option [15:22:04 CEST] <potus> awesome [15:22:06 CEST] <potus> mine didnt show [15:22:18 CEST] <potus> i was about to delete it and try new cinelerra settings [15:22:30 CEST] <potus> now, if i can get a real time preview.. this program would be killer [15:23:40 CEST] <hendry> all i need is to sync up audio with the better audio i've taken seperately [15:24:57 CEST] <Caedus> Would anyone not recommend using ffserver to live stream a video feed to a browser? We're sending data from a webcam on a raspberry pi to an aws instance and then streaming from ffserver on the aws instance to a browser, but we're running into issues actually displaying the video in a webpage. [15:26:04 CEST] <potus> hendry: what application you using? [15:26:16 CEST] <JEEB> ffserver is a piece of code that you must be ready to start maintaining yourself [15:26:30 CEST] <JEEB> almost no-one knows how it's supposed to be used and barely anyone maintains it [15:26:33 CEST] <Mavrik> Caedus, ffserver is a dead project not fit for production. [15:26:48 CEST] <Mavrik> Use something modern like Wowza or nginx streaming server [15:27:02 CEST] <JEEB> it will also most probably be removed soon after some APIs get through the deprecation-removal [15:27:02 CEST] <Caedus> Thank you, Mavrik, I was beginning to suspect as much [15:27:10 CEST] <JEEB> because it bases on some really icky API usage [15:27:22 CEST] <JEEB> which will become impossible as some older things get removed [15:27:50 CEST] <potus> hendry: i read u can just add the offset to ffmpeg, although, i opted to fix my problem at source. [15:28:08 CEST] <potus> happy to hear i didnt have to reconvert the video from .mov to .mkv [15:30:55 CEST] <hendry> potus: haven't found the right application yet. https://www.youtube.com/watch?v=dgpC0CCNTOA will check out cinerella [15:31:21 CEST] <potus> hendry: beware there is three forks of cinelerra. each with their own versions [15:31:32 CEST] <potus> the one i had success with is cinelerra-cv-2.3 [15:31:36 CEST] <potus> compiled from source. [15:32:00 CEST] <potus> it will keep telling u "cant run right missing stuff" use apt-file to find the libs one by one until it takes. then run ldconfig and ull be good to go [15:32:40 CEST] <hendry> potus: i just loaded an mp4 into cinerella-cv on Archlinux and the audio is totally screwed [15:35:01 CEST] <potus> hendry: compile from source [15:35:09 CEST] <potus> also make sure your framerates are correct [15:35:21 CEST] <potus> e.g. if you shot in 24p and your framerate is 30p in project.. the audio will be off [15:35:41 CEST] <potus> settings -> format to change it [15:35:57 CEST] <potus> mine reads 24p 4096x2160 .. i shot it with a panasonic 4k cam. [15:36:22 CEST] <potus> once u have the version working.. no audio offset was needed.. deletethe program you have save urself a headache! [16:12:27 CEST] <jancoow> Hi there. I'm working on a home automatic system with several raspberry pi's spread in the house. I want to add surveilance camera with usb webcam's accross the house, and save a log of video for 7 days or something on a central server. Do you think a combination of ffserver and ffmpeg is a good solution for this? [16:13:40 CEST] <furq> i don't think ffserver is a good solution for anything [16:14:04 CEST] <jancoow> oh haha [16:14:23 CEST] <jancoow> well my thought was: raspberry pi's aren't really powerfull for live decoding etc. [16:14:32 CEST] <jancoow> so that would be better to do on the server [16:15:01 CEST] <furq> the rpi has a hardware h.264 encoder but you can't use it from ffmpeg afaik [16:15:08 CEST] <furq> you can use gstreamer [16:15:22 CEST] <ln-> since you need to buy new hardware anyway (i.e. the cameras), why not just buy network cameras. [16:16:00 CEST] <jancoow> well, i already have like 10 rpi around the house, and i think a camera only is cheaper then a network camera [16:16:03 CEST] <furq> otherwise, if you need to do the encoding remotely then it gets a bit more tricky [16:16:15 CEST] <jancoow> it was just a thought [16:16:45 CEST] <jancoow> was more curious what you guys think what's the best to do [16:17:17 CEST] <TD-Linux> which generation of rpi? [16:18:12 CEST] <jancoow> different. Most are pi b+ [16:18:21 CEST] <ln-> i don't know what's the situation nowadays, but like 7..10 years ago many usb webcams didn't have any linux drivers, or not proper drivers. [16:18:43 CEST] <furq> jancoow: the first thing that comes to mind is using gst-omx and a central rtmp server [16:18:51 CEST] <jancoow> most work with v4l. I just loan 2 philips webcams from school (with a horrible resolution btw..) and they work out of the box [16:18:53 CEST] <furq> but that's probably because my only streaming experience is with rtmp [16:19:07 CEST] <jancoow> furq: well ty! i will check that! [16:19:09 CEST] <furq> if you can find a streaming server which accepts whatever format comes off the camera, that's probably better [16:19:18 CEST] <jancoow> yeah exactly [16:19:31 CEST] <furq> i guess an rtp/rtsp server should handle that but i can't recommend one [16:24:37 CEST] <furq> jancoow: if you do go the rtmp route then https://github.com/arut/nginx-rtmp-module/wiki/Directives#record will handle the logging [16:25:41 CEST] <TD-Linux> jancoow, I'd actually suggest using the "motion" software and just recording jpegs [16:25:49 CEST] <TD-Linux> and then cron'ing them to another server [16:26:04 CEST] <TD-Linux> (or network mounting a drive) [16:26:17 CEST] <furq> i assume he wants live streams as well as a log [16:26:18 CEST] <jancoow> furq: thanks looks promising; I will try to create a test setupt tonight! :) [16:26:43 CEST] <jancoow> TD-Linux: yeah motion uses a LOT of bandwidht. 1.8mb/s for 1 stream + it uses all the cpu of a rpi [16:26:49 CEST] <TD-Linux> for the live streams you probably need to figure out the hw encoder, or use an older codec like theora [16:26:52 CEST] <jancoow> furq: yeah indeed i wanna live stream [16:27:04 CEST] <TD-Linux> theora has armv6 opts so it *might* work on a rpi. still iffy though [16:27:31 CEST] <furq> if you're encoding anything on an rpi then the hardware encoder is the way to go [16:27:46 CEST] <furq> and the h.264 one is the only one you don't have to pay extra for [16:28:03 CEST] <jancoow> yeah exactly, and if it works great then the server has less load [16:28:33 CEST] <jancoow> raspberry pi's are almost doing nothing the whole day so that's great for sharing load over the house [16:28:43 CEST] <furq> it's just a shame ffmpeg doesn't support omx yet [16:31:03 CEST] <TD-Linux> gstreamer is pretty easy to use for this though. arguably easier than ffmpeg [17:02:44 CEST] <raijin> hai, I'm having a small issue with the .aa demuxer, specifically -aa_fixed_key option, its parsing it incorrectly [17:27:44 CEST] <raijin> or, the script I used is only returning 4 bytes instead of 16 [17:28:10 CEST] <raijin> is the code wrong when asking for 16? or is there something I am missing?? [17:36:09 CEST] <FranceBB> Hi everybody! I would like to know where I can download a sample .imf file and I would like to know whether ffmpeg supports it or not. Thank you in advance. [17:43:28 CEST] <durandal_1707> FranceBB: I'm also interested in sample [17:44:37 CEST] <Gringham> Hey, I'm trying to do a low latency streaming from one Pc in my local Network to another. At the Moment the latency is about 1-2 Seconds. Therefor on the host side I run : [17:44:41 CEST] <Gringham> ffmpeg -f dshow -re -i video=screen-capture-recorder -vf scale=1280:720 -vcodec libx264 -maxrate 3000k -bufsize 3000k -pix_fmt yuv420p -g 60 -tune zerolatency -preset ultrafast -f mpegts udp://239.255.1.2:1234 [17:45:22 CEST] <Gringham> and on the Client Side I run : [17:45:23 CEST] <Gringham> ffplay -fflags nobuffer -infbuf -fast -framedrop -vf "setpts=(PTS*0.95)" udp://239.255.1.2:1234 [17:45:44 CEST] <Gringham> Any ideas, how I can improve this ? [17:55:03 CEST] <potus> gringham: I have never done streaming via ffmpeg.. what are the hippups your encountering? [18:24:45 CEST] <cirdan> afternoon all. trying to figure something out. downloading some pbs videos for my son, and ffmpeg grabs the hd stream from the m3u, but not the subtitles. the subs are in vtt format. is there anyway to have it download both at the same time, but keep the subs as a seperate file? so I'd get video.mp4 and video.vtt [18:35:04 CEST] <Plonker> Hello, I'm compleatly new to ffmpeg. Could someone help me with something? [18:35:12 CEST] <cirdan> Plonker: wht are you trying to do? [18:36:00 CEST] <Plonker> Hi Cirdan, i'm trying to use ffmpget and imageMagik to create a movie barcode [18:36:24 CEST] <cirdan> oh. i dont know that :) [18:36:49 CEST] <cirdan> you mean a normal barcode? theres tools to do that [18:37:06 CEST] <Plonker> nah, something like this http://i.imgur.com/jOKAoaP.png [18:37:19 CEST] <cirdan> o. [18:37:27 CEST] <Plonker> it take the dominant colour from each frame [18:38:56 CEST] <cirdan> https://github.com/NickHurst/MovieBarcodeCreator [18:39:37 CEST] <cirdan> that does it all for you [18:40:12 CEST] <Plonker> haha thanks [18:40:18 CEST] <Plonker> thats no fun though :P [18:40:36 CEST] <cirdan> it does the same thing you'd be doing in the shell [18:40:45 CEST] <furq> cirdan: it looks like pbs serves the captions in a separate playlist [18:40:55 CEST] <cirdan> furq: yes, linked from the main [18:41:02 CEST] <furq> ffmpeg -i captions.m3u8 out.vtt [18:41:04 CEST] <furq> that should work [18:41:14 CEST] <cirdan> I do that already, its just a bunch of manual steps [18:41:43 CEST] <cirdan> hoped it could do both with 1 master m3u8 [18:43:15 CEST] <cirdan> the barcode from the images of the frames is really cool looking [18:43:26 CEST] <cirdan> 2d instead of 1d :-) [18:46:50 CEST] <momomo> is there a way to say to hls_list_size 3 but delete segment files after say 100 ? [18:48:18 CEST] <furq> cirdan: sorry, misread [18:48:32 CEST] <furq> it looks like there's already a feature request for reading EXT-X-MEDIA [18:48:34 CEST] <furq> https://trac.ffmpeg.org/ticket/2833 [18:48:41 CEST] <cirdan> hmm [18:49:13 CEST] <cirdan> I did see something about timestamps getting changed converting vtt to srt because of libass, so I've been doing that w/a web page for now [18:49:20 CEST] <cirdan> (never thought i'd say that...) [18:49:34 CEST] <furq> weird [18:49:48 CEST] <furq> i wouldn't have thought libass would be involved at all in that conversion [18:49:55 CEST] <cirdan> http://www.nikse.dk/SubtitleEdit/Online is cool [18:51:02 CEST] <furq> momomo: not with ffmpeg [18:51:10 CEST] <furq> you could probably do it with inotify or something [18:51:12 CEST] <cirdan> https://trac.ffmpeg.org/ticket/3148 [18:51:40 CEST] <momomo> furq, ok, i could have a separate thread do that perhaps [18:52:02 CEST] <furq> cirdan: that's srt to mov_text [18:52:23 CEST] <cirdan> furq: yeah I saw the same thing somewhere with vtt -> srt [18:52:43 CEST] <cirdan> that was the first timecode bug google gave me :-) [18:54:14 CEST] <furq> you might just be able to keep them in vtt [18:54:21 CEST] <furq> mpv supports it if nothing else [18:54:44 CEST] <cirdan> yeah I'm putting it in mp4 [18:55:10 CEST] <cirdan> hmm can ffmpeg convert the subs? lemme compare [18:56:47 CEST] <cirdan> oh. i feel dumb. the timestamps were correct. and it can convert. wonder what I read that made me think that... maybe someone converted to .ass and I didn't realize [20:12:25 CEST] <varu-> so i have a device sending a live rtp stream to me, h264 & mp2 audio i believe [20:12:30 CEST] <varu-> if i tune into it with vlc, it works great. however, if i pcap the stream and try to play it back, it's completely broken. the same happens if i try to process it (even live) with ffmpeg [20:12:37 CEST] <varu-> any idea why this could be? pcap here: https://www.sendspace.com/file/i6lsx9 [20:18:20 CEST] <yesyesyes> Hello. I need to mute around two small sections of over an hour Video VOB File (1GB). I am using following command. After completing whole file it shows this at the last::: [20:18:20 CEST] <yesyesyes> [ac3 @ 00000000003ab820] incomplete frame. [20:18:48 CEST] <yesyesyes> ffmpeg VTS_07_1.VOB -af "volume=enable='between(t,4,11)':volume=0, volume=enable='between(t,15,21)':volume=0" output.vob [20:19:23 CEST] <yesyesyes> Output is there but with only 350MB poor qualiy video [20:19:57 CEST] <yesyesyes> yes ! [20:24:01 CEST] <yesyesyes> http://pastebin.com/BRUrfNrc [20:24:45 CEST] <yesyesyes> Output is there but with only 350MB poor qualiy video. Any suggestions are welcomed ! [20:28:18 CEST] <llogan> yesyesyes: that's not the complete output. you can trim the repeating stuff in the middle, but i need to at least see the first ~50 and last ~50 lines. [20:29:01 CEST] <yesyesyes> ok Sir. i will get that [20:36:09 CEST] <yesyesyes_> http://pastie.org/private/v8lxr2ss4bp0b75idzzblq Here Sir [20:45:39 CEST] <llogan> yesyesyes: add "-codec:v copy" [20:45:51 CEST] <yesyesyes> i am trying right now [20:49:10 CEST] <yesyesyes> it does not work. here is the command and output http://pastie.org/private/oqoimkr94dvunfqzh3y0w [20:50:07 CEST] <llogan> you forgot the "-i" [20:52:13 CEST] <yesyesyes> my bad! trying again. [20:55:06 CEST] <yesyesyes> i've set the command.....waiting for output ...... [21:00:24 CEST] <yesyesyes> llogan, thanks it worked ! [21:01:18 CEST] <yesyesyes> Input file is 0.99GB ; but output file is 1.01GB [21:02:21 CEST] <yesyesyes> I have to actually mute over 100 sections in this file. Can i use all the sections to be cut in single command? [21:05:22 CEST] <llogan> sorry, but i don't understand your question [21:10:46 CEST] <yesyesyes> Am editing a Speech in which Lecturer delivers a sentence in English and then Interpreter interpretes in another language instantly; then Lecturer speaks and interpreter interpretes and it keeps on going for an hour. I need to mute all interpretations done and put 3rd language interpretations there. [21:11:06 CEST] <yesyesyes> well, dubbing [21:13:38 CEST] <llogan> yesyesyes: may be easier to export the audio, edit in audacity, then re-mux [21:14:49 CEST] <yesyesyes> i take that suggestion. extracting audio right now [21:22:28 CEST] <yesyesyes> I extracted the Audio from the file in AAC format but AudaCity do not accept that Format. [21:24:10 CEST] <fritsch> use ffmpeg to decode it to wav [21:24:11 CEST] <fritsch> :-) [21:24:37 CEST] <yesyesyes> thanks fritsch . Doing [21:26:04 CEST] <llogan> yesyesyes: extract it again from original file, but as wav. don't use the aac file as the input to make the wav [21:26:32 CEST] <yesyesyes> ok thanks ! [21:26:35 CEST] <yesyesyes> doing [21:32:47 CEST] <yesyesyes> Unable to extract wav from the file http://pastie.org/private/jc2akuu5swef0oa3rewuq [21:33:14 CEST] <yesyesyes> It produces a 900 MB Wav File output. [21:34:07 CEST] <llogan> yes, they can be large, but does it matter? it's just a temp file for editing [21:34:18 CEST] <explodes> My decoder is (randomly?) giving me a great 'ol SIGABRT on sws_setColorspaceDetails, don't know from where, presumably when I can sws_scale. What pre-conditions are necessary for sws_scale? [21:36:19 CEST] <yesyesyes> llogan, editing the file in AudaCity. [22:10:00 CEST] <yesyesyes> Done. Please tell me how can i add me how can I add 'wav' Audio file to a silenced 'Vob' Audio file. i got no idea. [22:44:01 CEST] <llogan> yesyesyes: ffmpeg -i input.vob -i audio.wav -map 0:v -map 1:a -c:v copy -c:a ac3 output.vob (if you want ac3, alternatively you could use mp2 or probably some sort of PCM) [22:45:46 CEST] <yesyesyes> i used ffmpeg -i input.VOB -i input.wav -codec copy -shortest final.vob [22:46:02 CEST] <yesyesyes> but its still running, its over 15min [22:47:03 CEST] <yesyesyes> i am cancelling it and trying ur;s [22:53:24 CEST] <yesyesyes> llogan, your command quickly gave the output. THANks ! [22:56:12 CEST] <llogan> you can add -shortest just in case there is a significant differenc between length for whatever reason [22:57:05 CEST] <yesyesyes> Do u mean this? ffmpeg -i input.vob -i audio.wav -map 0:v -map 1:a -c:v copy -c:a ac3 -shortest output.vob [22:59:28 CEST] <zamba> i need to change from the matroska container to mp4.. can i do that without reencoding anything? [23:02:29 CEST] <zamba> nevermind, figured it out :) [23:32:53 CEST] <Magmatic> I'm trying to listen to multiple rtp streams (on different ports of course) and send each one to an icecast server. I think I will have to do this with multiple commands running in the background. I go the first one working, but when I try the second one, it says "udb @ 0xba5ad60] bind failed: Address already in use". Any advice? [23:34:33 CEST] <Magmatic> My command looks something like this: ffmpeg -v verbose -i rtp://localhost:5801 -legacy_icecast 1 -content_type audio/mpeg -ice_name "Channel1" -f mp3 icecast://source:hackme@example.com:8000/channel1 [00:00:00 CEST] --- Fri Apr 8 2016

1 0

ffmpeg-devel.log.20160406
by burek 07 Apr '16

07 Apr '16

[01:07:19 CEST] <jkqxz> wm4: I agree that the Raspberry Pi / OpenMAX patch isn't very good (and OpenMAX deserves all hate we can throw at it), but this seems like a case where the thing should probably be accepted (suitably cleaned up) because it does have significant value to users and currently there is no sensible alternative. [01:07:43 CEST] <nevcairiel> does mmal not offer encoding? [01:08:07 CEST] <jkqxz> Is anyone actually working on it? [01:08:22 CEST] <rcombs> I had a patch to add encoding once [01:08:44 CEST] <rcombs> and have been saying ever since that one day I'll clean it up and get it working properly again [01:09:54 CEST] <wm4> jkqxz: probably [01:15:34 CEST] <rcombs> jkqxz: is all the infrastructure required to do relatively-painless full-hardware transcode pipelines (including filtering) already merged? [01:15:46 CEST] <jkqxz> wm4: And is going to post something working in the near future? [01:15:54 CEST] <rcombs> (i.e. not actual encoder and filter implementations, but the mechanisms they need to wkr) [01:15:56 CEST] <rcombs> *work [01:16:52 CEST] <jkqxz> rcombs: hwcontext stuff? The remaining parts are stuck behind codecpar. [01:17:04 CEST] <rcombs> ah [01:17:09 CEST] <rcombs> so merged in libav and just not in ffmpeg yet? [01:17:40 CEST] <jkqxz> Yes. You can VAAPI decode-filter-encode in hardware with libav now. [01:18:19 CEST] <rcombs> oh, those implementations have also been merged? [01:18:20 CEST] <rcombs> sweet [01:19:58 CEST] <jkqxz> There are still a lot of missing features, but the structural stuff is all there. [01:21:57 CEST] <michaelni> wm4, patch works fine [01:22:57 CEST] <wm4> michaelni: then I'll add some comments and push if nev is fine with it (tomorrow) [01:23:34 CEST] <nevcairiel> i still find it fishy that codecpar could end up with no w/h at all w hen lowres is used [01:23:48 CEST] <nevcairiel> but what do i care, people that use lowres deserve sillyness i guess [01:24:31 CEST] <wm4> ffmpeg.c and maybe ffplay.c is most likely the only software using it this way [01:36:45 CEST] <Daemon404> wm4, or at all [01:47:16 CEST] <nevcairiel> once st->codec compat is removed we could probably force-disable lowres in find_stream_info and populate codecpar properly [01:54:04 CEST] <BBB> ubitux: thanks for review! [01:54:20 CEST] <BBB> ubitux: a few of those I already addressed in my github repo, Ill address the rest in next round [01:54:31 CEST] <BBB> ubitux: and yes I have assembly for pretty much everything (on github) [03:17:58 CEST] <cone-545> ffmpeg 03Michael Niedermayer 07master:2c697c650ca7: fate: force fixed point aac decoder in filter-meta-4560-rotate0 [03:29:22 CEST] <jamrial> michaelni: that test, shouldn't it do a codec copy for the audio? [03:30:15 CEST] <jamrial> the important part is the video stream, there's no need to reencode the audio afaik [03:31:11 CEST] <jamrial> you could even create the temp mov file without the audio stream from the source sample [03:31:20 CEST] <jamrial> unless i'm missing something [03:44:19 CEST] <michaelni> jamrial, i thought about using copy too but thought more testing maybe cant hurt, actually would have been nice we could have used float aac if it was bitexact on all platforms as that would have been the only float aac test that would have detected a +-1 difference [03:50:37 CEST] <jamrial> alright [04:14:16 CEST] <cone-545> ffmpeg 03Claudio Freire 07master:8005b6de4f88: AAC encoder: fix valgrind errors [05:21:49 CEST] <cone-545> ffmpeg 03James Almer 07master:374974886aa7: fate: add missing filter-meta-4560-rotate0 dependencies [07:09:08 CEST] <rcombs> just filed a radar for a ridiculous audiotoolbox issue [07:10:03 CEST] <rcombs> was trying to tweak the decoder to not rely on parsers for channel counts + sampling rates, since I'm not sure how that'll interact with codecpar changes and there are some APIs that are meant to serve that purpose [07:10:46 CEST] <rcombs> there's a property called "kAudioFormatProperty_ASBDFromMPEGPacket", which you pass to AudioFormatGetProperty ( AudioFormatPropertyID inPropertyID, UInt32 inSpecifierSize, const void *inSpecifier, UInt32 *ioPropertyDataSize, void *outPropertyData ); [07:11:03 CEST] <rcombs> and it's meant to parse an MPEG audio packet and give you some basic info (codec ID, channel count, sampling rate) [07:11:26 CEST] <rcombs> you'd think `inSpecifier` would be a pointer to the packet data, and `inSpecifierSize` would be the size of the packet [07:11:57 CEST] <rcombs> nope, `inSpecifierSize` is 4, and `inSpecifier` is& the first 4 bytes of the packet (containing the sync word) [07:12:07 CEST] <rcombs> not a pointer to the first 4 bytes, just the first 4 bytes casted to `const void*` [07:13:22 CEST] <rcombs> naturally, none of this is documented [11:21:16 CEST] <nevcairiel> rcombs: giving it 4 bytes of the packet seems fine for mpeg audio, but the type casting sure is mad [11:21:26 CEST] <rcombs> nevcairiel: yeah [11:21:39 CEST] <rcombs> I think it's probably a mistake somewhere [11:22:03 CEST] <rcombs> like, someone meant to take a void** or something [11:22:19 CEST] <rcombs> I can't find any instance of code that actually uses this [11:23:30 CEST] <rcombs> but hey there's always ff_mpa_decode_header [11:23:50 CEST] <wm4> but that's cheating! [11:24:39 CEST] <rcombs> while researching this I found code in the lib to parse the same information out of AC3 headers [11:24:45 CEST] <rcombs> (undocumented, unsupported) [11:25:43 CEST] <rcombs> though technically usable without any private symbols, since it's all via this "property" API [11:31:26 CEST] <ubitux> anyone has some video tearing stress test? [11:32:46 CEST] <wm4> those vertically moving bars are good for it [12:08:22 CEST] <wm4> ubitux: OGM with srt subtitles that are exported as "text", opinion? https://0x0.st/PWS.ogm [12:08:40 CEST] <wm4> also, ogm still has completely broken timestamps [12:09:00 CEST] <nevcairiel> kierank: since this is likely from your world somewhere, do you know if mpeg2 intra-refresh has some sort of metadata to indicate how long until the image is fully reconstructed, like h264 has? [12:10:04 CEST] <ubitux> wm4: looks wrong since it contains markup [12:10:21 CEST] <ubitux> probably safer to make them export as subrip by default [12:10:29 CEST] <wm4> maybe the text decoder should always redirect to srt [12:10:48 CEST] <wm4> since that is what many players probably do anyway [12:11:32 CEST] <ubitux> i don't know, maybe& [12:11:45 CEST] <ubitux> quick fix is to just fix the codec id in the demuxer [12:23:45 CEST] <wm4> ubitux: also, converting subs from ogm to srt with ffmpeg makes the tags show up [12:23:51 CEST] <wm4> strictly speaking this is incorrect [12:24:18 CEST] <ubitux> ? [12:24:44 CEST] <wm4> the srt file contains things like "<i>The wind came down... </i>" [12:24:54 CEST] <wm4> no attempt to escape the tags [12:25:06 CEST] <wm4> the source codec is "text", so it should do that [12:28:34 CEST] <ubitux> codec being text means it will consider tags are part of the text, they're not going to be stripped [12:28:43 CEST] <ubitux> if you want "text" in your srt, you need to -c:s text [12:29:02 CEST] <ubitux> again, the issue is simply that it's exported as text while it's actually not [12:40:27 CEST] <wm4> I don't get that but whatever [12:55:02 CEST] <kierank> nevcairiel: yes I have seen it [12:55:23 CEST] <kierank> Not sure about metadata [13:12:43 CEST] <cone-807> ffmpeg 03Martin Vignali 07master:6d7f5667a0c4: avcodec/exr: enable mipmap, ripmap decoding [14:39:21 CEST] <ghici> hello [14:48:26 CEST] <ghici> i`m trying to re encode just audio from e-ac3 to mp2 audio from a ts to a ts, video is copied without transcoding, and from time to time i get some : exponent out-of-range , error decoding the audio block [14:48:46 CEST] <ghici> and at that time you can hear some glitches. [14:50:57 CEST] Action: durandal_1707 summons reviews [14:54:56 CEST] <BtbN> Hm, is there no way to select a specific decoder with the ffmpeg cli util, or am I just blind? [15:00:23 CEST] <nevcairiel> specify -c before the inpout file [15:00:24 CEST] <atomnuker1> yeah there is, put -c:a <decoder> before -i [15:05:33 CEST] <BtbN> It didn't like that, but I'll rebuild and try again [15:16:34 CEST] <BtbN> There's a space at the end of the decoder name, nevermind... [15:59:07 CEST] <kierank> does libavcodec allow proprietary codec plugins? [15:59:12 CEST] <kierank> seems to be what that guy is doing [15:59:24 CEST] <BtbN> libavcodec supports plugins? [16:00:33 CEST] <BtbN> you mean that guy on the ml, right? [16:01:20 CEST] <TD-Linux> kierank, yes, libfdk-aac [16:01:32 CEST] <kierank> that's not distributable [16:01:47 CEST] <BtbN> libfdk-aac isn't proprietary. It just has a weird as hell license that's not GPL compatible. [16:02:07 CEST] Action: TD-Linux is not sure how that's better than AGPL [16:02:20 CEST] <BtbN> It doesn't taint the stream coming out of it?! [16:02:38 CEST] <BtbN> it only has weird clauses about what derived works have to be named, which is what makes it incompatible [16:02:56 CEST] <TD-Linux> I don't think the interpretation of AGPL "taining the stream" is correct [16:03:12 CEST] <TD-Linux> might be wise to email the fsf [16:03:28 CEST] <TD-Linux> (or not care about j2k...) [16:03:47 CEST] <BtbN> This is unrelated to the j2k guy. [16:03:53 CEST] <thardin> agpl doesn't taint anything. it just prevents you from doing SaaS kind of things [16:04:35 CEST] <Daemon404> "just" [16:04:50 CEST] <BtbN> If youtube would use an AGPL ffmpeg for encoding their videos, they would have to give their modified ffmpeg source along with it. [16:04:56 CEST] <BtbN> I'd call that "tainting the stream" [16:05:07 CEST] <thardin> no, they would have to give the source code for all of youtube [16:05:36 CEST] <kierank> I wasn't even talking about lgpl [16:05:38 CEST] <durandal_1707> nice [16:05:39 CEST] <kierank> I'm talking about that suresh guy [16:06:05 CEST] <thardin> so as a license it's a tool that should be used.. carefully [16:06:11 CEST] <BtbN> kierank, it's fine what he's doing, as long as he doesn't distribute his modified copy, he can do whatever he wants. [16:06:19 CEST] <kierank> ofc [16:06:31 CEST] <ubitux> http://sprunge.us/fLCI thanks gdb [16:06:38 CEST] <ubitux> useful as usual [16:27:08 CEST] <Daemon404> wow no new codecpar bugs today? [16:31:32 CEST] <durandal_1707> just because no time... [16:31:44 CEST] <RiCON> how much time left on that 2-day deadline? [16:31:56 CEST] <RiCON> some bug will show up in the last minutes [16:36:29 CEST] <wm4> concat is still left [16:37:27 CEST] <Daemon404> yeah [16:37:36 CEST] <Daemon404> im not sure whats going on with it [16:37:54 CEST] <Daemon404> it's a 1 byte difference, and the decoded result is the same [16:38:00 CEST] <Daemon404> as is output to e.g. .h264 [16:38:13 CEST] <Daemon404> i resent that demxuer [16:38:44 CEST] <ubitux> did you ask nicolas? [16:39:08 CEST] <Daemon404> i dont think he'd be able to to help re: codecpar [16:39:35 CEST] <Daemon404> also some bsf crap is happening, which im convince is workign correctly... but yet [16:39:48 CEST] <Daemon404> also it leaks memory in git master (which i fixed in codecpar because i had to) [16:40:06 CEST] <Daemon404> it's just an all around meh piece of code that is "useful" [17:17:38 CEST] <Daemon404> wm4, yeah i just cant figure out why concatdec is being this way [17:17:51 CEST] <Daemon404> i mean, it *must* be to do with bsf crap [17:20:12 CEST] <wm4> so all packets are 1 byte too long? [17:21:00 CEST] <Daemon404> no [17:21:05 CEST] <Daemon404> there's some odd difference [17:21:37 CEST] <Daemon404> and it's all in the packets themselves afaict [17:21:49 CEST] <Daemon404> (if i mux to mp4, the only non-pos differences are in mdat( [17:22:36 CEST] <Daemon404> going to binary diff the .avi output now [17:27:03 CEST] <Daemon404> http://chromashift.org/a.tar.xz <-- output in 3 formats [17:31:37 CEST] <wm4> h264: AVC: nal size 100663272 [17:31:44 CEST] <Daemon404> yes i know [17:33:23 CEST] <Daemon404> oh... hmmm [17:33:33 CEST] <Daemon404> it is perhaps the way teh bsd inside concatdec.c is acting with the muxing [17:33:45 CEST] <Daemon404> because when you output to a format that uses annexb (.h264, .ts) it is fine [17:33:55 CEST] <Daemon404> but when it is a mp4-like output, it fucks uo [17:34:07 CEST] <Daemon404> when it does mp4style->annexb->backtomp4 [17:34:41 CEST] <Daemon404> likely because concatdec is doing bistream filtering in the demuxer itselg [17:36:06 CEST] <Daemon404> though im not sure where/why it messes up [17:38:56 CEST] <Daemon404> actually where the hell is concatdec creating streams [17:41:37 CEST] Action: Daemon404 donest understand this crap at all [17:42:51 CEST] <nevcairiel> does concatdec even work on master for mp4? [17:42:57 CEST] <Daemon404> yes [17:43:03 CEST] <nevcairiel> i remember it forcing annexb conversion, so how would that work with mp4 [17:43:16 CEST] <Daemon404> i assumign during muxing it parses it back to mp4 format [17:43:20 CEST] <Daemon404> in the muxer [17:43:24 CEST] <Daemon404> this is concat*dec* [17:43:58 CEST] <Daemon404> it might have relied on updating stuff during ff_read_packet that cant be now [17:43:58 CEST] <nevcairiel> maybe whatever the bsf is doing needs to shove the new extradata somewhere? [17:44:20 CEST] <nevcairiel> its probably the same old problem, extradata can't be updated after-the-fact [17:44:29 CEST] <Daemon404> oh [17:44:34 CEST] <Daemon404> i think it might be that it shouldnt have extradata [17:44:51 CEST] <Daemon404> maybe the muxer is getting the old mp4 extradata + annexb format packets [17:45:00 CEST] <nevcairiel> sounds like it from that error [17:45:40 CEST] <nevcairiel> the bsf usually converts the extradata to annexb format [17:45:51 CEST] <nevcairiel> not sure if mp4 needs that or it would find it from the stream [17:46:08 CEST] <nevcairiel> h264 split function would probably extract it from the stream either way [17:48:06 CEST] <Daemon404> i have no idea where/how to fix this though [17:48:51 CEST] <Daemon404> i cant even figure out where concatdec is creating streams [17:49:57 CEST] <Daemon404> hmm copy_stream_props [17:56:11 CEST] <Daemon404> nevcairiel, setting extradata to NULL (and size to 0) right after avcodec_parameters_copy fixes it [17:56:19 CEST] <Daemon404> but uh... i highly doubt that is correct. [17:56:33 CEST] <nevcairiel> yes, you should free it and not just null it [17:56:34 CEST] <nevcairiel> :D [17:56:42 CEST] <Daemon404> i mean for non-h264 codecs :P [17:56:50 CEST] <nevcairiel> well clearly only for h264 [17:57:02 CEST] <Daemon404> if h264 -> null? [17:57:05 CEST] <Daemon404> is that ok? lol [17:57:08 CEST] <nevcairiel> av_freep! [17:57:16 CEST] <Daemon404> same idea [17:57:20 CEST] Action: Daemon404 leaks nevcairiel's memoru [17:57:57 CEST] <nevcairiel> its not ideal, but it is "correct" for some definitions of the word [17:57:59 CEST] <wm4> add random hacks until fate passes [17:58:00 CEST] <Daemon404> i guess i dont feel too bad about it [17:58:09 CEST] <Daemon404> concatdec already has stupid h264-specific bsfs [17:58:20 CEST] <wm4> oooh [17:58:25 CEST] <nevcairiel> the ideal case would be to get the annexb extradata out of the bsf and set that as extradata instead [17:58:29 CEST] <Daemon404> yes concatdec ONLY uses bsfs for h264 [17:58:30 CEST] <wm4> is it related to the fact that the h264 bsf changes the avctx extrdata? [17:58:47 CEST] <kierank> Gramner: any suggested speedups to atomnuker1's code: https://0x0.st/PWU.patch [17:58:54 CEST] <wm4> can't wait for the new bsf API [17:58:56 CEST] <kierank> it's doing planar 10-bit to uyvy422 10-bit [17:59:02 CEST] <nevcairiel> but if you can't do the ideal case, then set no extradata for h264, because then some other code will step in and extract the new extradata back out of the actual stream =p [17:59:11 CEST] <Daemon404> yes [17:59:22 CEST] <Daemon404> concatdec is a poo-pile. [17:59:58 CEST] <Daemon404> keep in midn concatdec onyl even does this for h264 [18:00:00 CEST] <Daemon404> hevc? nah. [18:01:00 CEST] <jamrial> kierank: that function is sse2, not ssse3 [18:02:53 CEST] <Daemon404> fix pushed [18:02:59 CEST] <Daemon404> \o/ [18:04:28 CEST] <Daemon404> no open bugs \o/ [18:04:57 CEST] <wm4> awesome [18:07:04 CEST] <neufeld> Just a heads-up, I've filed a bug against glibc https://sourceware.org/bugzilla/show_bug.cgi?id=19917 in which the ffmpeg x.264 library multi-threading is badly broken (adding a second thread slows things down, adding more makes it worse). I found the bad commit with a git bisect. I figured people here might be interested as well. [18:08:40 CEST] <wm4> wow [18:08:50 CEST] <wm4> can you link the commit? (a gitweb url or so) [18:09:00 CEST] <Daemon404> luckily not much ahs moved to 2.23 yet... [18:10:31 CEST] <Gramner> kierank: the loads could be done as 3-arg avx ops instead of explicit mova:s (maybe by changing the CLIPW macro to take 3-4 args?). one of the unpacks doesn't have to be 3-arg, also the punpckh + punpckl combo is called a butterfly and the SBUTTERFLY macro does that. you can use fewer vector registers [18:10:41 CEST] <Gramner> those changes aren't really going to make stuff faster though [18:10:57 CEST] <Daemon404> wm4, https://sourceware.org/ml/glibc-cvs/2015-q3/msg00435.html [18:11:07 CEST] <Daemon404> seems liek an odd revision to break on? [18:11:32 CEST] <Daemon404> oh, reading closer, maybe not [18:11:37 CEST] <wm4> didn't he say it's bisected [18:12:10 CEST] <wm4> lol at glibc delayed loading making everythign horrible [18:28:01 CEST] <BBB> ubitux: the obvious answer is I dont really care about it" [18:28:34 CEST] <ubitux> then ignore and move on :p [18:29:48 CEST] <BBB> the nice thing on top of colormatrix is that this thing actually *does* have simd [18:30:32 CEST] <BBB> I can work on mt also, shouldnt be difficult (although you never know&) [18:31:11 CEST] <Shiz> unsurprisingly, ifunc hell makes things worse [18:31:54 CEST] <BBB> brb [18:56:50 CEST] <BtbN> oh great. This CUVID decoder does not have its own parser... I guess the ffh264 bitstream parser can't be invoked independently? [18:58:18 CEST] <nevcairiel> actually the cuvid api has a parser [18:58:28 CEST] <BtbN> only on Windows [18:58:36 CEST] <nevcairiel> well then you are screwed =p [18:59:05 CEST] <BtbN> it wants all kind of h264 bitstream info, just like the normal hwaccels [18:59:08 CEST] <nevcairiel> without that cuvid is a slice decoder, so make it a hwaccel [18:59:20 CEST] <nevcairiel> everything else would be insane :) [19:00:13 CEST] <BtbN> it's pointless as a hwaccel, the whole idea is that it generates AV_PIX_FMT_CUDA frames that the potential future CUDA filters and nvenc can then process without the frames ever leaving GPU memory [19:00:51 CEST] <nevcairiel> hwaccels generate frames in a hwaccel pixfmt [19:01:41 CEST] <BtbN> CUVID would be a very weird hwaccel, it doesn't need any other outside help like the other ones [19:02:04 CEST] <Daemon404> [17:58] <@BtbN> only on Windows <-- wut [19:02:08 CEST] <Daemon404> lol. [19:02:24 CEST] <BtbN> Daemon404, it probably just uses some Windows-Media-API for the parsing? [19:02:37 CEST] <Daemon404> no idea [19:02:38 CEST] <nevcairiel> it does not [19:02:47 CEST] <Daemon404> even more lulz then [19:07:02 CEST] <nevcairiel> anyway if the complexity of that code goes through the roof, it also kinda defeats the point =p [19:10:15 CEST] <BtbN> it would probably work as hwaccel and with an additional ffmpeg_cuda.c [19:18:52 CEST] <BtbN> meh, don't feel like digging into that right now [19:19:01 CEST] <BtbN> It seems pretty straight forward though [19:19:25 CEST] <BtbN> Just _a lot_ of code that's required before testing it becomes possible at all [19:21:04 CEST] <Daemon404> isnt that kind of par for the course for most hw things [19:22:21 CEST] <BtbN> depends, it's usualy worse if Intel is involved. [19:27:28 CEST] <jkqxz> BtbN: Making the hwaccel output work sensibly isn't too bad. Look at <https://git.libav.org/?p=libav.git;a=commit;h=5d273d3efac340ef8de445c955ff4…>. [19:28:06 CEST] <BtbN> I'm aware of how it works, I just don't feel like implementing all that stuff for CUDA right now [19:30:13 CEST] <fritsch> when reading this diff [19:30:20 CEST] <fritsch> wondering if the "output_format" makes any sense [19:30:28 CEST] <fritsch> or if it's really coming via VPP [19:30:32 CEST] <fritsch> mapped to something ffmpeg internal [19:30:39 CEST] <fritsch> else: it's pointless [19:31:07 CEST] <BtbN> which output_format? [19:31:37 CEST] <fritsch> ah I see it [19:31:40 CEST] <fritsch> they do it with vpp in deed [19:32:04 CEST] <fritsch> they specify it in the ctx [19:32:09 CEST] <fritsch> i wonder if they really tested it [19:32:20 CEST] <fritsch> last I looked ... VAAPI could not reliable share buffers [19:32:23 CEST] <fritsch> other than NV12 [19:32:31 CEST] <fritsch> or RGBA via vaPutSurface [19:32:50 CEST] <BtbN> it's probably left inside of its buffer, and passed around as VAAPI frame [19:33:00 CEST] <fritsch> av_hwframe_transfer_data <- [19:33:24 CEST] <BtbN> that's called in vf_hwdownload/hwupload [19:33:36 CEST] <fritsch> yeah and here the output->format is set via the ctx [19:34:27 CEST] <fritsch> // do so. Assume for now that we are always dealing with YUV 4:2:0, so [19:34:30 CEST] <fritsch> + // pick a format which does that [19:34:33 CEST] <jkqxz> The transfer is only done there if you actually want output in normal memory. "-hwaccel_output_format vaapi" gives you the hardware surface directly with no copying. [19:34:34 CEST] <fritsch> haha [19:34:56 CEST] <fritsch> knowing the internals of the vaapi driver ... [19:35:09 CEST] <fritsch> it's not easily possible to get those without a copy [19:35:41 CEST] <fritsch> last I looked they did a full copy to either an X11Picture or you got the data by using EGL transfer via drm [19:36:13 CEST] <fritsch> ouh and it seems the run it frame_threaded [19:36:24 CEST] <jkqxz> An AV_PIX_FMT_VAAPI AVFrame is just a VASurfaceID. [19:36:28 CEST] <fritsch> yeah [19:36:51 CEST] <fritsch> if we talk about color conversion [19:37:08 CEST] <fritsch> you can only do that in VPP [19:37:18 CEST] <fritsch> and after that is done - you did not yet share those buffers (data) [19:37:46 CEST] <fritsch> so getting the frames out there for display / postprocessing (without vpp) was the big issue with vaapi [19:37:49 CEST] <fritsch> in the past [19:37:58 CEST] <BtbN> the idea is to not get them out of there, ever [19:38:08 CEST] <fritsch> good :-) [19:38:29 CEST] <fritsch> so use the c*pled vaapi display api? [19:38:41 CEST] <BtbN> or just encode it again [19:38:58 CEST] <jkqxz> The case that patch adds is intending to support hardware transcode, not output of any form. [19:39:01 CEST] <fritsch> which also only works if you use vaapi again [19:39:04 CEST] <BtbN> libav is pushing hard for full-hw-transcode [19:39:07 CEST] <fritsch> jep [19:39:12 CEST] <fritsch> seen that in libyami [19:39:33 CEST] <jkqxz> (You can also pass them into opencl and do whatever there, if you like.) [19:39:35 CEST] <fritsch> vaapi's big problem is: sharing the (decoded) data with something standard [19:39:48 CEST] <fritsch> jkqxz: how does that passing happen without a copy? [19:40:11 CEST] <fritsch> how to acces the real data from opencl? [19:40:17 CEST] <jkqxz> They're just DRM surfaces. Both APIs can deal with them. [19:40:27 CEST] <fritsch> drm can to my knowledge only deal with NV12 [19:40:52 CEST] <jkqxz> (You can also do whatever else with DRM surfaces that you like, like DRI2 for display in X.) [19:41:44 CEST] <fritsch> this again depends on the surface layout / format [19:41:53 CEST] <fritsch> to my knowledge the only direct transferable is NV12 [19:42:01 CEST] <fritsch> which also only works for intel's libva-driver [19:43:03 CEST] <jkqxz> No, VPP can do arbitrary transformations between surface formats. [19:43:13 CEST] <fritsch> :-) ey [19:43:16 CEST] <fritsch> we talk about sharing those [19:43:19 CEST] <fritsch> not about what vpp can do [19:43:34 CEST] <fritsch> i fixed some segfaults with VPP in the intel driver when implemented: [19:43:36 CEST] <fritsch> https://github.com/xbmc/xbmc/blob/master/xbmc/cores/VideoPlayer/DVDCodecs/V… [19:43:58 CEST] <fritsch> and when we last checked, we only could share NV12 which got implemented for us [19:44:03 CEST] <fritsch> and RGBA which is expensive [19:44:46 CEST] <fritsch> is there a real drm api in place now, that works completely without EGL? or is it still used the same? [19:45:21 CEST] <fritsch> i did not see that gwenole's patches would have been merged into mesa / nor intel driver [19:45:32 CEST] <jkqxz> You share by using VPP to go to/from whatever DRM buffer you have from somewhere else? So far I've only used this with DRI2, but it certainly works for both capture and display in X. [19:45:45 CEST] <fritsch> can you show me your code? [19:50:09 CEST] <jkqxz> For what? To read from/write to DRM buffers you get the buffer name (from whatever other place, like DRI2) and then create VA surfaces out of them with the attributes for that. Then using VPP on them just works and everything is good. [19:51:17 CEST] <fritsch> for display would have been interesting [19:51:24 CEST] <fritsch> but I see you are mainly into transcoding [19:54:35 CEST] <BBB> ubitux: github now has multithreading and all your comments are addressed [19:54:48 CEST] <BBB> ubitux: I can simply split it in two patches and re-submit, is that ok with you? [19:54:56 CEST] <ubitux> sure [19:56:26 CEST] <jkqxz> fritsch: Most of an lavd driver for X11 capture is at <http://ixia.jkqxz.net/~mrt/vaapi/ffmpeg/v6/0006-libavdevice-XCB-DRI2-VAAPI-…> (working but never cleaned up; also uses the older form of the VAAPI stuff, which got replaced by hwcontext). [19:56:39 CEST] <wm4> concatdec is f0 9f 92 a9 [19:56:42 CEST] <wm4> uh what [19:56:53 CEST] <Daemon404> wm4, ? [19:56:58 CEST] <Daemon404> i already pushed a fix to concatdec [19:56:59 CEST] <wm4> your commit message [19:57:01 CEST] <BtbN> is that hwcontext stuff for vaapi even in ffmpeg? [19:57:10 CEST] <wm4> BtbN: no [19:57:11 CEST] <Daemon404> wm4, your unicode is outdated [19:57:19 CEST] <Daemon404> lacks emoji [19:57:25 CEST] <wm4> ok [19:57:29 CEST] <wm4> (good) [19:57:29 CEST] <Daemon404> its the "pile of poo" emoji [19:58:35 CEST] <fritsch> jkqxz: thx much - i am looking [20:02:49 CEST] <jkqxz> Output is basically the same, you just write to the surfaces and swap buffers rather than waiting for buffer changes and reading. [20:06:06 CEST] <fritsch> i will have a detailed look when we get hevc-10 bit support as we need a new way in kodi for handling these [20:08:59 CEST] <wm4> I wonder how anyone will do hevc 10 on GLES shit [20:09:03 CEST] <wm4> because it has no matching texture format [20:09:57 CEST] <jkqxz> Convert to 8-bit and hope noone notices. [20:10:06 CEST] <fritsch> hehehehe [20:10:12 CEST] <BBB> ubitux: enjoy round 2 of review! [20:10:20 CEST] <wm4> good joke... oh wait they'll totally do that [20:10:30 CEST] <fritsch> they really do that ... [20:10:40 CEST] <fritsch> to keep their vaPutSurface working [20:10:46 CEST] <BBB> wm4: Im confused, cant you upload to uint16 in opengl? [20:11:00 CEST] <wm4> BBB: GLES has no 16 bit fixed point texture format [20:11:03 CEST] <BBB> wm4: (and then have a shader that multiplies by 64) [20:11:14 CEST] <fritsch> we basically want to avoid the conversion of the originally decoded data .. [20:11:16 CEST] <wm4> desktop GL does and always did [20:11:35 CEST] <BBB> oh I see [20:11:44 CEST] <BBB> es [20:11:45 CEST] <BBB> :-p [20:11:47 CEST] <fritsch> but vaapi guys do it that way ... they make an RGB32 conversion [20:11:58 CEST] <fritsch> to keep their api working [20:12:51 CEST] <wm4> without colorspace/range hints? [20:12:55 CEST] <jkqxz> vaPutSurface() is an abomination. [20:13:09 CEST] <fritsch> vaPutSurface has some old flags [20:13:14 CEST] <BBB> ubitux: next thing I could do is to add scaling to this filter, and then call it swscale :-p [20:13:16 CEST] <fritsch> for BT709 / BT 601 [20:13:24 CEST] <fritsch> but now they have proper implemented VPP color conversion [20:13:46 CEST] <wm4> not too much better [20:13:49 CEST] <fritsch> not really [20:13:56 CEST] <fritsch> but they wanted to do it without it [20:14:14 CEST] <fritsch> when the first patches appeared I intervened and asked to do it "right" [20:14:25 CEST] <fritsch> and in deed the intel guy came back with vpp patches [20:14:32 CEST] <fritsch> i was quite impressed [20:15:27 CEST] <fritsch> for the buffer sharing ... perhaps one can misuse a RGBA32 buffer (just the data) to get the values in [21:11:46 CEST] <ubitux> BBB: wait, you added rgb2yuv too? [21:11:53 CEST] <BBB> ? [21:12:03 CEST] <BBB> rgb2yuv was always there [21:12:11 CEST] <ubitux> erh yeah indeed my bad [21:12:18 CEST] <ubitux> my brain didn't process it [21:12:32 CEST] <BBB> to convert yuv to yuv with a rgb intermediate, you need rgb2yuv and yuv2rgb :-p [21:26:14 CEST] <Daemon404> wm4, https://github.com/dwbuiten/FFmpeg/issues/31 [21:26:33 CEST] <Daemon404> oh, duh youre there [21:27:06 CEST] <Daemon404> reading is hard [21:28:50 CEST] <wm4> parsers should have been fixed before that but elenril doesn't have anything ready lol [21:42:42 CEST] <wm4> " This file can be READ ONLY on a Panasonic TV (HDR + 4K) !!! " [21:42:43 CEST] <wm4> lol? [21:44:10 CEST] <nevcairiel> proprietary formats etc [21:44:34 CEST] <wm4> that's the thing that was just posted to ffmpeg-devel, according to durandal_1707 it's DRMed [21:44:39 CEST] <BBB> security through obscurity [21:44:49 CEST] <BBB> if you make sure only these tvs can read it, you dont need drm [21:44:54 CEST] <BBB> \o/ [21:50:31 CEST] <durandal_1707> av_strcasecmp is broken [00:00:00 CEST] --- Thu Apr 7 2016

1 0

ffmpeg.log.20160406
by burek 07 Apr '16

07 Apr '16

[00:23:50 CEST] <rjp421> petecouture, do u have a ustream token? [00:29:00 CEST] <rjp421> hmmm nvm i thought they accepted hls input [00:52:41 CEST] <petecouture> rjp421 no I don't. Thanks for trying. [01:32:16 CEST] <t4nk536> Hello, I'm working on a free educational project, I was auditioning with ffmpeg for conversion of videos in Windows, the settings are very conplicadas, someone could support me? [01:36:39 CEST] <t4nk574> hello [01:38:18 CEST] <leonardo_> hello [01:38:57 CEST] <leonardo_> Do you speak in spanich? [01:39:49 CEST] <leonardo_> hello iive [01:40:13 CEST] <leonardo_> wath do you do? [02:41:58 CEST] <DolpheenDream> howdy [02:42:52 CEST] <DolpheenDream> anyone has any idea whether it is necessary to have the HD tag set in the mp4 file ? e.g. to play on ATV for instance ? what does the presence of this HD tag really do, if the movie is a HD (1080p) anyway ? [02:48:47 CEST] <relaxed> what is ATV and do you have a file with this tag set? [02:49:14 CEST] <DolpheenDream> hehe :) atv = appleTV [02:49:46 CEST] <DolpheenDream> files purchased from iTunes store have HD set (if HD version was purchased) and it shows in ATV as HD label.. [02:51:06 CEST] <relaxed> pastebin.com the output of "ffmpeg -i file" on one of these files [02:53:10 CEST] <relaxed> it's probably just metadata you can replicate with ffmpeg [03:10:53 CEST] <john_doe_jr> I'm having a delay in my streaming using rtp protocol and was wondering if I should use rtsp&would that be better? [03:11:03 CEST] <john_doe_jr> I found this link: https://ffmpeg.org/ffmpeg-protocols.html#rtsp [03:17:07 CEST] <yeoj> if i know the coordinates of a moving object in a video, is there some way i can pass the coordinates to an ffmpeg blur filter in a stream and only blur the moving object and coordinates i'm looking for in a video? [03:24:19 CEST] <yeoj> nevermind, looks like i wasn't searching for the right thing.. http://zulko.github.io/moviepy/cookbook/blurred_face.html seems promising [03:24:38 CEST] <furq> john_doe_jr: afaik you need an external server for rtsp [03:27:38 CEST] <john_doe_jr> furq: what is the fastest possible stream w/ ffmpeg&do u know? [03:28:50 CEST] <furq> i've no idea for just audio [03:29:52 CEST] <furq> you probably want to check your player's buffer settings [03:31:24 CEST] <john_doe_jr> furq: alright&it's vlc [03:32:32 CEST] <john_doe_jr> furq: I found the "http://ffmpeg-users.933282.n4.nabble.com/async-td935787.html" option @ http://lzone.de/cheat-sheet/ffmpeg just for audio [05:15:01 CEST] <kurtCobain> When I used AVFoundation to record the desktop and produce segments of .webm videos, portions of the videos are sped up during playback. http://pastebin.com/m1AKJTGD [05:17:35 CEST] <relaxed> kurtCobain: I'm pretty sure that should be -framerate 24 [05:18:34 CEST] <relaxed> ffmpeg -h muxer=avfoundation [05:18:43 CEST] <relaxed> er, ffmpeg -h demuxer=avfoundation [05:33:43 CEST] <kurtcobain_> Seems like -r -> -framerate made a difference. Monitoring the console output the framerate was more consistently at or close to 24 fps and the speed was right around 1x. [06:19:01 CEST] <aletorrado> Hi!!!! I'm using latest FFMPEG 3.0 and trying to do adaptive live streaming with the recent DASH MUXER, but don't know how to specify multiple conversions. I'm currently doing this: ffmpeg -v verbose -i rtsp://stream.eltrecetv.com.ar/live13/13tv/13tv1 -c:v copy -c:a copy -f dash output.mpd [06:19:55 CEST] <aletorrado> A 720p & 480p output example would be VERY appreciated :) :) [06:21:32 CEST] <relaxed> aletorrado: http://wiki.webmproject.org/adaptive-streaming/instructions-to-playback-ada… [06:21:52 CEST] <aletorrado> Nope! I want to use libx264! [06:22:18 CEST] <aletorrado> Cannot use webm_dash_manifest [06:23:30 CEST] <relaxed> maybe http://stackoverflow.com/questions/28429526/ffmpeg-h-264-encoding-for-html5… [06:23:45 CEST] <relaxed> google should provide some examples [06:24:57 CEST] <aletorrado> I've already read that [06:25:22 CEST] <aletorrado> He doesn't do adaptive [06:26:53 CEST] <thebombzen> aletorrado: if you mean you want to take the input stream and encode two versions of the output stream, you can specify -map twice. that is, if you use -map 0:v -map 0:v then you get two streams [06:27:01 CEST] <thebombzen> you can scale them individually with -filter_complex [06:28:50 CEST] <thebombzen> another thing you could try is this: -filter_complex '[0:v] scale=1280:720 [v1] ; [0:v] scale=854:480 [v2]' -map '[v1]' -map '[v2]' [06:29:01 CEST] <aletorrado> that is! Thanks @thebombzen ! [06:29:38 CEST] <thebombzen> for more info on how to do weird stuff, I'd read the filtering guide. FFmpeg's filtering is extremely powerful and flexible [06:29:58 CEST] <thebombzen> careful that you also have to map the audio [06:30:40 CEST] <thebombzen> once you have two video streams, you can select them with "stream specifiers" i.e. you could set the codec for both with -c:v libx264 [06:31:13 CEST] <thebombzen> if you want the codec for the first to be different you could use -c:0 libx264 -c:1 mpeg4 hypothetically [06:31:18 CEST] <aletorrado> yeap I've just tested and added audio :) [06:31:22 CEST] <thebombzen> cool :D [06:41:33 CEST] <aletorrado> thanks a lot @thebombzen [09:57:58 CEST] <andrey_utkin> is it legal to stitch into MP4 container two x264 videos, in which the second part has customly decreased i_keyint_max? The extradata is taken from first clip (with "longer" i_keyint_max, apparently default one, which seems to be ~250 frames) [10:00:00 CEST] Last message repeated 1 time(s). [10:10:19 CEST] <zamba> hi! i'm trying to convert some video from vhs to digital format.. i'm using a simple command like: ffmpeg -f video4linux2 -i /dev/video0 -f alsa -i default output.mkv [10:10:46 CEST] <zamba> when looking at the CR line output i see that fps is currently at 22 [10:10:49 CEST] <zamba> why not 24 or 25? [10:10:57 CEST] <zamba> speed is also at 0.999x [10:12:13 CEST] <zamba> this is the input: Input #0, video4linux2,v4l2, from '/dev/video0': Duration: N/A, start: 10449717.744269, bitrate: 165888 kb/s | Stream #0:0: Video: rawvideo (YUY2 / 0x32595559), yuyv422, 720x576, 165888 kb/s, 25 fps, 25 tbr, 1000k tbn, 1000k tbc [10:12:27 CEST] <zamba> so the input is 25 fps, but the output shows: [10:12:38 CEST] <zamba> frame=58963 fps= 22 q=28.0 size= 1062851kB time=00:43:52.92 bitrate=3306.9kbits/s dup=0 drop=91 speed=0.999x [10:12:47 CEST] <zamba> do i have anything to worry about here? [10:16:57 CEST] <relaxed> zamba: fps= 22 is how fast it's encoding, not the output framerate [10:18:24 CEST] <relaxed> drop=91 is maybe something to worry about [10:18:48 CEST] <zamba> relaxed: i got that pretty early in the capture [10:18:56 CEST] <zamba> relaxed: and it's been stable at 91 for a long time now [10:19:26 CEST] <relaxed> what's your command? [10:19:41 CEST] <zamba> see above: ffmpeg -f video4linux2 -i /dev/video0 -f alsa -i default output.mkv [10:19:42 CEST] <relaxed> oh, nevermind [10:20:15 CEST] <relaxed> add -framerate 25 before -i /dev/... [10:20:22 CEST] <zamba> what does that do? [10:20:31 CEST] <relaxed> er, it assumes that [10:21:17 CEST] <zamba> hm? [10:22:02 CEST] <relaxed> the default input framerate for -f video4linux2 is 25 fps, which is the same for PAL [10:23:33 CEST] <zamba> do i need to add -framerate 25, then? [10:23:46 CEST] <relaxed> You do not [10:24:52 CEST] <relaxed> zamba: how does the video look? [10:25:06 CEST] <zamba> relaxed: it looks ok, but it's a bit.. eh.. laggy here and there [10:26:25 CEST] <zamba> dunno how better to describe it :) [10:30:51 CEST] <relaxed> zamba: have a look at "ffmpeg -h demuxer=video4linux2" and https://trac.ffmpeg.org/wiki/Capture/Webcam [10:32:36 CEST] <zamba> oh.. but i have no idea what to get from this :) [10:49:08 CEST] <zamba> and the output of ffmpeg is filled with errors like "Past duration 0.xxxxxx too large" [10:49:18 CEST] <zamba> that i have no idea how to interpret [12:21:20 CEST] <ingolfur> I just installed ffmpeg on Ubuntu 14.04. When I run ffmpeg -version I get the following: ffmpeg version N-79139-gde1a0d4 Copyright (c) 2000-2016 the FFmpeg developers. built with gcc 4.8 (Ubuntu 4.8.4-2ubuntu1~14.04.1) [12:21:30 CEST] <ingolfur> does anyone know what version that is of ffmpeg? [12:24:59 CEST] <relaxed> git from 2016-03-26 [12:28:30 CEST] <ingolfur> Thanks! [12:54:39 CEST] <momomo> momomo [14:14:38 CEST] <brm> dead channel [14:17:15 CEST] <DHE> Umm, wrong. besides it's only just morning in north america. [14:50:53 CEST] <ghiciro> hello [14:51:36 CEST] <ghiciro> i`m trying to re encode just audio from e-ac3 to mp2 audio from a ts to a ts, video is copied without transcoding, and from time to time i get some : exponent out-of-range , error decoding the audio block and you can hear the audio glitch at that time [16:38:02 CEST] <PowerOn> Good morning all [16:39:35 CEST] <PowerOn> Can I make a question? Ive compiled ffmeg on ubuntu 14.04 and now I have ~/ffmpeg_build ~/ffmpeg_sources ~/bin/ [16:39:47 CEST] <PowerOn> Is there any way to move those folders from home, to another place? [16:39:53 CEST] <PowerOn> without losing everything? [16:41:14 CEST] <PowerOn> sorry for bothering you folks :) [16:57:57 CEST] <zamba> relaxed: yeah, i'm able to reproduce it.. in that sense that i'm able to see that playing back the same part of the tape several times reveal the image lag at different positions [16:58:14 CEST] <zamba> relaxed: so there's probably something with I/O or the encoding process [16:59:29 CEST] <DHE> PowerOn: the binaries ffmpeg and ffprobe are usually all you need. copy them into /usr/local/bin or something like that [16:59:52 CEST] <DHE> if they're really big (ie. 15 megabytes or more) then there should be no further dependencies that were built with them [17:08:40 CEST] <PowerOn> Hi DHE! [17:09:15 CEST] <PowerOn> So, If I move the 3 folders into /usr/local/bin should work? [17:09:34 CEST] <furq> no [17:09:41 CEST] <furq> move the contents of ~/bin to /usr/local/bin [17:10:03 CEST] <PowerOn> and what about the other folders? Can I remove them? [17:10:24 CEST] <furq> if you don't want to compile ffmpeg again then sure [17:11:18 CEST] <PowerOn> Thanks furq! [17:11:27 CEST] <PowerOn> I'll take that shoot [17:20:06 CEST] <Nosomy> which video format is super fast to encode?, mpeg1, mpeg2 or xvid? [17:20:51 CEST] <Mavrik> mjpeg. [17:21:35 CEST] <Nosomy> mjpeg have a high bitrate [17:22:29 CEST] <TD-Linux> the others you listed aren't exactly winners either [17:22:36 CEST] <Nosomy> another alternative ? [17:22:43 CEST] <Mavrik> H.264 with hardware encoder :P [17:23:00 CEST] <TD-Linux> or even with a software one. [17:23:02 CEST] <Mavrik> You said nothing about the details of your usecase. [17:23:13 CEST] <Mavrik> So whatever, raw video? :P [17:23:17 CEST] <Nosomy> quality is no required [17:23:31 CEST] <TD-Linux> so use mjpeg with a lower quality setting? [17:24:16 CEST] <Nosomy> mjpeg in lower quality setting is high bitrate yet. [17:24:30 CEST] <Nosomy> but,thanks for tip [17:24:34 CEST] <furq> you didn't say anything about bitrate [17:39:10 CEST] <kepstin> x264 with the correct options can be very fast to encode, and unlike most mpeg1/2/4 encoders it can do multithreaded too [17:39:16 CEST] <furq> he already left [17:39:32 CEST] <kepstin> ... [17:39:35 CEST] <kepstin> ok then [18:06:46 CEST] <PowerOn> what's the diff between ffmpeg-snapshot.tar.bz2 and ffmpeg-3.0.tar.xz? [18:06:52 CEST] <PowerOn> which is the latest? [18:06:55 CEST] <c_14> snapshot [18:06:57 CEST] <c_14> It's from git. [18:07:05 CEST] <c_14> Whereas 3.0 is the release branch [18:07:15 CEST] <PowerOn> thanks C [18:35:25 CEST] <zamba> i'm trying to capture audio from my line in jack.. i've killed pulseaudio.. and i'm trying to do "-f alsa -i default" [18:35:38 CEST] <zamba> but it looks like ffmpeg wants to use pulseaudio still? [18:35:40 CEST] <zamba> ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Connection refused [18:35:56 CEST] <c_14> zamba: you still have pulse configs lying around in your alsa directories [18:36:14 CEST] <zamba> c_14: what's an alsa directory? [18:36:44 CEST] <c_14> the config directories for alsa. /usr/share/alsa iirc [18:36:45 CEST] <zamba> or rather, where are they? [18:37:09 CEST] <zamba> ah [18:47:57 CEST] <dailyuser> Hi all, I am trying to cross fade 2 videos segments using the http://superuser.com/questions/778762/crossfade-between-2-videos-using-ffmp… but the resolution I am trying to get is 1280x720. [18:48:11 CEST] <dailyuser> The output is always 960x720 instead [18:48:39 CEST] <dailyuser> Yes, I did change the command to be 1280x720 [18:49:03 CEST] <c_14> get rid of the scale filter [18:50:38 CEST] <dailyuser> Thanks will try that. Also, is there a way to make it faster.. Currently, it takes around 30 seconds to cross fade 2 videos 10 seconds each [18:51:16 CEST] <dailyuser> The only thing that I want to do is add cross fade between 2 videos [19:04:59 CEST] <zamba> i switched hardware, and then the encoding goes smooth.. it's dead solid on 25 fps.. and the video is smooth as well when played back.. even though the first hardware i tried it on should be way better [19:05:33 CEST] <zamba> it's also not using that much cpu as it did on the newer hardware - where it consumed all four cores.. now it's just humming along.. [19:05:47 CEST] <zamba> exactly the same command [20:07:34 CEST] <dailyuser> ffmpeg -i 1.mp4 -i 2.mp4 -f lavfi -i color=black -filter_complex \ "[0:v]format=pix_fmts=yuva420p,fade=t=out:st=4:d=1:alpha=1,setpts=PTS-STARTPTS[va0];\ [1:v]format=pix_fmts=yuva420p,fade=t=in:st=0:d=1:alpha=1,setpts=PTS-STARTPTS+4/TB[va1];\ [2:v]scale=1280x720,trim=duration=9[over];\ [over][va0]overlay[over1];\ [over1][va1]overlay=format=yuv420[outv]" \ -vcodec libx264 -map [outv] out.mp4 always ends up giving me a 960x720 video [20:08:48 CEST] <dailyuser> Can some one please help me try to figure why I keep getting a 960x720 even when specifying 1280x720 there? [20:26:39 CEST] <Polochon_street> Hi! I'm using the ffmpeg lib in C, and want to turn off debug info (like [mp3 @ 0x556caf8327c0] Estimating duration from bitrate, this may be inaccurate), is there any easy way to do it? [20:28:27 CEST] <Polochon_street> there's a « log_level_offset » in AVCodecContext, but I can't figure out what it's related to [20:28:39 CEST] <fritsch> Polochon_street: https://ffmpeg.org/doxygen/2.5/group__lavu__log.html#ga14034761faf581a8b9ed… [20:29:03 CEST] <Polochon_street> fritsch: thanks very much! [20:29:14 CEST] <fritsch> take care to the threadsafety [20:30:29 CEST] <fritsch> you can have a look in kodi's FFmpeg.cpp [20:30:42 CEST] <fritsch> which implements a logger with that signature [20:31:15 CEST] <Polochon_street> well I'm just using av_log_set_level, thanks very much :) [20:31:27 CEST] <fritsch> hehe [20:31:32 CEST] <fritsch> to not log anything [20:31:34 CEST] <fritsch> hehe [20:32:50 CEST] <ffmpeg-user> Hi, sorry to repost again but I am trying to add cross fading between 2 videos of 1280x720p using the instructions mentioned here http://superuser.com/questions/778762/crossfade-between-2-videos-using-ffmp… [20:33:12 CEST] <ffmpeg-user> The output is always 960x720 even when I change the scale on it [20:33:26 CEST] <ffmpeg-user> If I remove the scale the output is of 960x720 [20:33:36 CEST] <ffmpeg-user> I mean 360x420 [21:08:55 CEST] <Amitari> I just found out that lossless H264 isn't lossless at all. Does anyone know how to modify the commands "ffmpeg -framerate 50 -pattern_type glob -i '*.png' -q:v 0 out.mkv" so that it outputs any form of lossless video? [21:09:27 CEST] <pzich> you almost certainly don't want lossless [21:09:38 CEST] <pzich> you can try -crf 0, but make sure you have a lot of disk space... [21:11:37 CEST] <Amitari> I'll try! [21:12:15 CEST] <furq> Amitari: what makes you think it isn't lossless [21:12:34 CEST] <furq> i guess from the fact you're converting png that it's doing a colourspace conversion [21:12:53 CEST] <pzich> yeah [21:12:59 CEST] <furq> you could try -pix_fmt yuv444p [21:13:10 CEST] <pzich> if you really want lossless you could export to raw BGRA, but be prepared for a big file :D [21:13:12 CEST] <furq> but if you need to keep it rgb then there are other lossless codecs which support that [21:13:13 CEST] <Amitari> I extracted the images from a video that was pixelart, and it had some sorta PNG-based video codec. All the colours were completely solid. [21:13:22 CEST] <Amitari> After reassembling these in a video, it wasn't.. [21:13:37 CEST] <furq> yeah it'll probably default to yuv420p which has 1/4 chroma resolution [21:13:43 CEST] <pzich> solid as in not blurry, or richer colors? [21:14:04 CEST] <furq> oh [21:14:08 CEST] <furq> apparently x264 does support rgb [21:14:14 CEST] <pzich> hmm, in my experience it hasn't defaulted to yuv420p and I've had to specify it if I want qt-compatible files [21:14:28 CEST] <furq> Amitari: use -pix_fmt yuv444p or -pix_fmt rgb24 [21:14:43 CEST] <pzich> depending on what player you're playing it back in [21:14:58 CEST] <Amitari> pzich: The colours had a bunch of artifacts in them. [21:15:02 CEST] <fritsch> will get funny 50 fps [21:15:07 CEST] <fritsch> + rgb24 [21:15:12 CEST] <fritsch> as this will be software accelerated [21:15:25 CEST] <furq> well lossless x264 is already shitty for playback [21:15:35 CEST] <Amitari> Hey, this is just to archive stuff losslessly. [21:15:46 CEST] <furq> also for reference you should use -q:v 0, not -crf 0 [21:15:46 CEST] <fritsch> png's are good for archiving [21:15:55 CEST] <furq> -crf 0 is only the same with 8-bit x264 [21:16:03 CEST] <Amitari> Yeah, but I want it in a video format. [21:16:11 CEST] <fritsch> he used -q:v 0 initially [21:16:22 CEST] <furq> i know [21:16:23 CEST] <Amitari> This is mainly to archive the stuff, either for uploading to YouTube, or to encode to lossy formats later. [21:16:30 CEST] <furq> 20:09:38 ( pzich) you can try -crf 0, but make sure you have a lot of disk space... [21:16:38 CEST] <fritsch> jep [21:16:40 CEST] <furq> i was responding to that [21:17:16 CEST] <Amitari> Alright, I'll try that pix_fmt thing. [21:18:02 CEST] <furq> iirc there will be some slight loss by converting from rgb to yuv444p [21:18:29 CEST] <furq> nowhere near as bad as with 4:2:0 though [21:19:02 CEST] <furq> there is also no point keeping it rgb if you're going to be converting it to a yuv-based format later [21:19:35 CEST] <Amitari> But I want to have it archived in a lossless format! [21:19:45 CEST] <fritsch> then keep the pngs [21:19:49 CEST] <fritsch> don't use h264 [21:19:54 CEST] <furq> keep the pngs or use -pix_fmt rgb23 [21:19:59 CEST] <furq> s/3/4/ [21:20:13 CEST] <Amitari> I tried that, but it said "Incompatible pixel format 'rgb24' for codec 'libx264', auto-selecting format 'yuv444p'". [21:20:17 CEST] <furq> oh [21:20:19 CEST] <Amitari> And that format gave a lossy result. [21:21:26 CEST] <fritsch> it's h264 after all ... try mjpeg (yeah jpeg sucks) but that way you get a lot "keyframes" [21:21:50 CEST] <fritsch> mjpeg with highest quality [21:21:59 CEST] <Amitari> Will that be lossless JPG? [21:22:01 CEST] <fritsch> no [21:22:04 CEST] <fritsch> 100% not [21:22:08 CEST] <fritsch> all those formats are not lossless [21:22:09 CEST] <Amitari> Oh... [21:22:24 CEST] <Amitari> Well, I know there's a way to save JPG pictures losslessly as long as they don't use transparency and stuff. [21:22:43 CEST] <fritsch> try [21:22:49 CEST] <furq> i'm not sure if ffmpeg has any lossless codecs with rgb support [21:22:58 CEST] <furq> i think ffv1 is yuv-only [21:23:16 CEST] <Amitari> This doesn't really have anything to do with colours at all, the pixel-art video got artifacts when I tried. [21:23:20 CEST] <kepstin> I thought recent versions of x264 you could actually do a lossless rgb encoding. [21:23:32 CEST] <furq> yeah i read that but he says it doesn't work [21:23:35 CEST] <furq> maybe it's an old ffmpeg [21:23:48 CEST] <kepstin> jpeg does conversion to yuv and chroma subsampling in most modes [21:23:54 CEST] <Amitari> ffmpeg 1:3.0.1-1 [21:23:57 CEST] <kepstin> so it's not gonna be lossless [21:24:13 CEST] <furq> not an old ffmpeg then [21:24:32 CEST] <furq> also i think i'm wrong about ffv1 [21:24:43 CEST] <furq> Amitari: try -c:v ffv1 -pix_fmt rgb24 [21:24:54 CEST] <Amitari> Sure, lemme try... [21:25:38 CEST] <kepstin> ah, in ffmpeg, the rgb mode of x264 has a different name [21:25:44 CEST] <kepstin> try -c:v libx264rgb [21:25:49 CEST] <furq> oh how convenient [21:25:51 CEST] <Amitari> Hmm, now it actually looks like it's lossless in VLC at least, lemme try extracting the pics now. [21:25:52 CEST] <kepstin> with -q:v 0 it'll be lossless [21:26:44 CEST] <Amitari> It wasn't when I tried. [21:26:49 CEST] <furq> 20:25:44 ( kepstin) try -c:v libx264rgb [21:26:50 CEST] <furq> ^ [21:27:08 CEST] <Amitari> "-c:v ffv1 -pix_fmt rgb24" made it completely lossless. :P [21:27:10 CEST] <Amitari> :D [21:27:26 CEST] <kepstin> but yeah, ffv1 would be a good choice for this as well [21:27:45 CEST] <Amitari> Sure, but isn't the option that worked first the most simple one? [21:27:53 CEST] <Amitari> I only encode really short videos in lossless, so... [21:28:24 CEST] <Amitari> The thing that takes up most space is all the frames I'm extracting. [21:29:23 CEST] <Amitari> I set VLC to extract all frames, and then I stop it when I know it has extracted the ones I want. [21:29:43 CEST] <furq> you know you could just do that with ffmpeg [21:29:58 CEST] <Amitari> Yeah, but I can't know what exact frame I'm on. [21:30:25 CEST] <Amitari> Then I delete all the ones I don't want, and then I open the audio in Audacity and calculate exactly what part of the audio I should use. Then I save that in FLAC, which I mux together with the video track after that has been reassembled. [21:49:47 CEST] <petecouture> Could someone explain this flag a little more then what's in the 264 spec [21:49:49 CEST] <petecouture> sc_threshold [21:49:59 CEST] <petecouture> sc_threshold: Adjusts the sensitivity of x264's scenecut detection. Rarely needs to be adjusted. Recommended default: 40 [21:50:37 CEST] <furq> it's how much of the frame needs to change for x264 to insert an IDR frame [21:50:38 CEST] <petecouture> I'm working to create multibit rate encoding and it's recommended to set that to - [21:50:50 CEST] <petecouture> set it to 0 rather [21:51:07 CEST] <petecouture> furq: Do you mean pixel bitmap data? [21:51:09 CEST] <furq> the only reason to set that to 0 is for fixed-size gops [21:51:20 CEST] <furq> i don't know exactly how it calculates it [21:51:30 CEST] <petecouture> AHHH perfect thank you [21:51:35 CEST] <furq> "x264 calculates a metric for every frame to estimate how different it is from the previous frame. If the value is lower than scenecut, an IDR frame is used." [21:51:39 CEST] <petecouture> I do need a fixed size gop [21:51:53 CEST] <furq> you can use keyint_min instead [21:52:02 CEST] <petecouture> I am [21:52:09 CEST] <furq> you only need one or the other [21:52:13 CEST] <petecouture> The whitepaper I'm reading on it has both [21:52:21 CEST] <furq> afaik scenecut won't override keyint_min [22:02:15 CEST] <petecouture> furq: Thank you for the information. I think by setting it to 0 it shuts off that detection algorthym which will be good. -r 24 -g 48 -keyint_min 48 -sc_threshold 0 [22:02:48 CEST] <petecouture> If you use that configureation above you always get perfect keyframe alignment between multiple bitrates [22:12:20 CEST] <furq> you don't need keyint_min if scenecut is disabled [22:12:38 CEST] <furq> the reverse might be true but it might still cause a slowdown, i'm not familiar enough with the code [22:23:04 CEST] <aletorrado> Hi!! I'm dealing with the new DASH MUXER in FFMPEG 3.0 for adaptive streaming. I've noticed the muxer is not saving the BANDWIDTH VALUE for the VIDEO STREAMS in the MANIFEST. This breaks the automatic adaptive switch on every DASH player. [22:23:45 CEST] <aletorrado> This is the command I'm using to test, pretty simple: ffmpeg -v verbose -i rtsp://stream.eltrecetv.com.ar/live13/13tv/13tv1 -filter_complex '[0:v:0] scale=128:72 [v0] ; [0:v:0] scale=256:144 [v1]' -map '[v1]' -map '[v0]' -map 0:a -f dash output.mpd [22:24:55 CEST] <JEEB> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/dashenc.c#L601 [22:25:12 CEST] <JEEB> as far as I can tell by the code, it does set either the bit rate or the VBV maxrate value in there [22:25:41 CEST] <JEEB> so if one of those is set by your video encoder, you are going to get the bandwidth thing there [22:25:44 CEST] <furq> does it set the bitrate if -b:v hasn't been set [22:26:08 CEST] <JEEB> if the encoder has a default bit rate I think it might default to whatever libavcodec defaults to for that format [22:26:24 CEST] <JEEB> but it doesn't have to be b:v, it can also be maxrate:v [22:33:07 CEST] <aletorrado> Awesome. You're my heroes! [22:39:14 CEST] <petecouture> in a h264 stream, there's no preference between having the audio or video stream coming first is there? [22:39:40 CEST] <furq> do you want to reconsider that third word [22:40:26 CEST] <petecouture> encoding [22:40:35 CEST] <petecouture> m3u8 stream [22:41:08 CEST] <bergeron37> I'm using avfoundation to record the user's desktop and the segment muxer to spit out recording files every 10 seconds or so. Is there an accurate way for me to obtain the timestamp at which the recording files video was taken? [22:41:41 CEST] <petecouture> bergeron37, the timestamp the files were created at or the timestamp of the playback? [22:41:59 CEST] <furq> petecouture: it shouldn't make a difference with mpegts, but some players might expect video first [22:42:00 CEST] <bergeron37> @petecouture recorded at [22:42:38 CEST] <petecouture> bergeron37: With ffmpeg 3.0+ I would recommend using the HLS muxer instead of segment. I just converted mine over. You can save the files using the actual ts [22:43:02 CEST] <petecouture> Also if you have ffmpeg within an application you should get status information as the stream is processing which contains the current encoding ts [22:43:33 CEST] <petecouture> From the client side if you playing it as a stream, you should have meta data events thrown during playback that will contain the current ts of the video [22:44:17 CEST] <petecouture> furq: Thank you I think VLC may. I'm having issues loading this m3u8 with vlc. Plays fine with everything else. [22:45:49 CEST] <petecouture> bergeron37: Here's how my output script has changed from segment to hls http://pastebin.com/PtrL0i1J [22:46:13 CEST] <furq> bergeron37: -f ssegment -srtftime 1 output_%H%M%S.ts [22:46:22 CEST] <furq> s/srtf/strf/ [22:46:44 CEST] <petecouture> furq: That command didn't work for me on ffmpeg 2.7 dunno if it was a bug but it's why I updated to 3 [22:47:56 CEST] <bergeron37> @furq do you know how accurate that timestamp is? [22:49:03 CEST] <bergeron37> I'm trying to figure out if I can use it to identify the time of the recording accurately [22:50:21 CEST] <petecouture> sycronized broadcasts? [22:55:04 CEST] <bergeron37> Specifically, do you know if there is any way to get it within milliseconds [23:14:29 CEST] <petecouture> Woot I finally got perfect 10 second ts segments from a live feed! [23:14:58 CEST] <petecouture> ffmpeg has the learning curve of Eve online. You think it's easy at first glance but then you start reading the details of the documetnation.... [23:54:55 CEST] <Tiago_> Hello guys. Was the CRYPTO_LOCK Deprecated? [00:00:00 CEST] --- Thu Apr 7 2016

1 0

ffmpeg-devel.log.20160405
by burek 06 Apr '16

06 Apr '16

[00:03:06 CEST] <Daemon404> stupid valgrind [00:03:10 CEST] <Daemon404> telling me utils.c is not helpful [00:03:13 CEST] <Daemon404> WHICH utils.c [00:03:55 CEST] <Daemon404> not sure why it doesnt show full by default [00:03:58 CEST] <Daemon404> or at least relative [00:11:02 CEST] <Angus> Is there a header for this .c file? https://www.ffmpeg.org/doxygen/2.8/ffmpeg__vdpau_8c_source.html [00:19:28 CEST] <Daemon404> its not part of the library [00:19:34 CEST] <Daemon404> it us a utility [00:19:35 CEST] <Daemon404> is* [00:25:17 CEST] <Daemon404> fixed ffserver [00:25:23 CEST] <Daemon404> well. "fixed" as it can be. [01:11:28 CEST] <michaelni> Its getting hard to find issues in codecpar, i think its getting close to being ok once the ones reported are fixed or marked unimportant, i still might find one or another but dont expect alot more unless you want me to report every case where a output file changes by a byte somewhere [01:12:14 CEST] <nevcairiel> only if you think the new output is "worse" [01:19:04 CEST] <nevcairiel> but dont worry, we'll break more when we update ffmpeg.c to actually use the new api instead of the legacy code [01:20:04 CEST] <Daemon404> yes but that will be separate [01:27:20 CEST] <Daemon404> nevcairiel, "For autobsf to work this would need a check_bitstream function to actually insert a bsf when needed." [01:27:23 CEST] <Daemon404> i do have one [01:27:29 CEST] <nevcairiel> the patch didnt show anything [01:27:38 CEST] <Daemon404> yeah i force pushed an update [01:27:39 CEST] <Daemon404> sorry [01:27:59 CEST] <Daemon404> ive also tested it and it owrks [01:28:03 CEST] <Daemon404> works* [01:28:05 CEST] <Daemon404> and all of fate passes [01:28:09 CEST] <nevcairiel> i looked at the latest branch, there is no such thing [01:28:12 CEST] <nevcairiel> or where did you hide it in [01:28:33 CEST] <Daemon404> ... well i DID have one [01:28:39 CEST] <Daemon404> i must have reset --hard [01:28:39 CEST] <Daemon404> shit [01:28:44 CEST] <Daemon404> at least it was incredibly easy [01:28:48 CEST] <Daemon404> ill re-push it [01:28:51 CEST] <Daemon404> as a ne commit [01:28:53 CEST] <Daemon404> new* [01:28:53 CEST] <nevcairiel> yeah those functions are trivial [01:28:59 CEST] <nevcairiel> for adts aac anyway [01:29:43 CEST] <Daemon404> oh good a 2nd ffserver segfault [01:29:48 CEST] <Daemon404> wanna bet its internal stuff nto allocated right? [01:29:57 CEST] <nevcairiel> probably [01:30:19 CEST] <Daemon404> i resent having to fix ffserver btw [01:30:27 CEST] <Daemon404> i should have to fix users of internal shit [01:31:10 CEST] <Daemon404> hmm [01:31:15 CEST] <Daemon404> i figured out the acc bug kinda [01:31:19 CEST] <Daemon404> ugh [01:31:40 CEST] <Daemon404> av_get_audio_frame_duration2 is returning different results than av_get_audio_frame_duration for earlier frames [01:31:46 CEST] <Daemon404> probably before codecpar is updated from decoding [01:32:41 CEST] <nevcairiel> maybe parser needs to set one more property [01:32:53 CEST] <Daemon404> its not the parser [01:32:59 CEST] <Daemon404> aac parser doesnt set anything [01:33:06 CEST] <Daemon404> theres a big if != AAC in te parser [01:33:07 CEST] <nevcairiel> doesnt? [01:33:09 CEST] <nevcairiel> oh well [01:33:18 CEST] <JEEB> lol [01:33:44 CEST] <Daemon404> funily enough it says adts headers cant be trusted as teh reason for that [01:33:51 CEST] <Daemon404> but theyre correct for this file and would have make it work [01:34:19 CEST] <JEEB> the usual :P trusting file breaks broken stuff so let's not do that [01:34:27 CEST] <nevcairiel> if you dont trust the adts headers, what other information do you use? [01:34:29 CEST] <nevcairiel> there is none [01:34:33 CEST] <nevcairiel> you need config data for aac [01:34:37 CEST] <JEEB> and that [01:34:46 CEST] <Daemon404> i dont know where it gets this info from [01:35:11 CEST] <Daemon404> see: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/aac_ac3_parser.c#L82 [01:35:30 CEST] <Daemon404> but im thinking it might be stuff liek block_align [01:35:38 CEST] <Daemon404> im slowly printf comparing all the attributes [01:35:59 CEST] <nevcairiel> well ok, HE might overwrite the adts values when it applies SBR [01:36:05 CEST] <JEEB> oh, is this the HE-AAC thing where sample rate can be /2 etc [01:36:14 CEST] <JEEB> and yeah, it updates it on the fly [01:36:18 CEST] <JEEB> as it gets decoded [01:40:17 CEST] <nevcairiel> similar to how i made the dca parser stop setting the sample rate, since it only knew about the core and none of the extensions [01:41:54 CEST] <Shiz> Daemon404: remove all header parsing, replace it by heuristics [01:41:56 CEST] <Shiz> even the resolution [01:42:00 CEST] <Shiz> just heuristicize it all [01:42:09 CEST] <Daemon404> case AVMEDIA_TYPE_AUDIO: [01:42:09 CEST] <Daemon404> + avcodec_parameters_from_context(st->codecpar, st->internal->avctx); [01:42:12 CEST] <Daemon404> frame_size = av_get_audio_frame_duration2(st->codecpar, pkt->size); [01:42:15 CEST] <Daemon404> this fixes it [01:42:16 CEST] <Daemon404> nevcairiel will slap me [01:42:19 CEST] <Daemon404> but lol [01:42:22 CEST] <nevcairiel> where is this? [01:42:30 CEST] <Daemon404> ff_compute_frame_duration [01:43:16 CEST] <nevcairiel> doing it everytime seems evil t hough [01:43:24 CEST] <Daemon404> i have no idea what to check for though [01:43:28 CEST] <Daemon404> it's just stuff being updated [01:43:34 CEST] <Daemon404> as frames decode [01:44:02 CEST] <Daemon404> i could check for teh one specific thing that changes and updated... but eh... [01:44:05 CEST] <Daemon404> seems just as bad [01:44:13 CEST] <nevcairiel> we have a avctx version of that function, do we not? if (st->internal->avctx_inited [01:44:16 CEST] <nevcairiel> argh [01:44:33 CEST] <Daemon404> er [01:44:36 CEST] <Daemon404> cannot parse [01:44:41 CEST] <Daemon404> explain more [01:44:44 CEST] <nevcairiel> nevermind everything after the ? [01:45:05 CEST] <Daemon404> teh duration2 func you mean? [01:45:14 CEST] <nevcairiel> yes [01:45:25 CEST] <Daemon404> yes but i am pretty sure it is deprecated now [01:45:30 CEST] <nevcairiel> doesnt seem to be [01:45:45 CEST] <Daemon404> oh ho [01:45:46 CEST] <Daemon404> no it isnt [01:45:50 CEST] <Daemon404> and yeah i already tested it [01:45:52 CEST] <Daemon404> it fixes it [01:46:12 CEST] <nevcairiel> in that case, if (st->internal->avctx_inited) duration = av_get_audio_frame_duration(st->internal->avctx, ...); else ... = av_get_audio_frame_duration2(st->codecpar, pkt->size); [01:46:19 CEST] <Daemon404> lets try. [01:46:20 CEST] <nevcairiel> slightly ugly but not that bad [01:46:49 CEST] <nevcairiel> while avctx_inited is set the decoder is running on it [01:47:01 CEST] <nevcairiel> once its unset, codecpar was sync'ed to the new info [01:47:43 CEST] <Daemon404> ah [01:48:01 CEST] <Daemon404> yes [01:48:02 CEST] <Daemon404> that works [01:48:13 CEST] <nevcairiel> still ugly, but what can you do [01:48:19 CEST] <nevcairiel> the "active" context changes =p [01:48:38 CEST] <Daemon404> yeah [01:49:01 CEST] <Daemon404> running fate and ill push [01:49:02 CEST] <nevcairiel> ideally it should probably fill this info when it actually reads these packets for delivery to the user [01:49:11 CEST] <nevcairiel> ie. after find_stream_info finished [01:49:17 CEST] <nevcairiel> but the dataflow here is a bit wonky [01:49:35 CEST] <Daemon404> dwbuiten/FFmpeg] Starship_Troopers.vob doesnt show subtitles anymore (#28) [01:49:36 CEST] <Daemon404> igh [01:49:44 CEST] <Daemon404> this file again [01:49:57 CEST] <nevcairiel> i dont think that file had a subtitle track? [01:50:06 CEST] <Daemon404> it does [01:50:31 CEST] <nevcairiel> let me guess, ffplay/ffmpeg is dumb and uses the CC properties flag to setup closed caption decoding, which is now unavailable? [01:50:42 CEST] <Daemon404> thats the file where dump.c stopped printing Closed Captions [01:50:50 CEST] <Daemon404> dunno [01:50:51 CEST] <nevcairiel> thats not a subtitle track though =p [01:52:09 CEST] <Daemon404> Stream #0:5[0x20]: Subtitle: dvd_subtitle [01:52:09 CEST] <Daemon404> Stream #0:6[0x22]: Subtitle: dvd_subtitle [01:52:13 CEST] <Daemon404> i see these in git master [01:52:19 CEST] <nevcairiel> it changed? [01:52:34 CEST] <Daemon404> nope [01:52:39 CEST] <Daemon404> theyre there in codecpar too [01:52:55 CEST] <nevcairiel> but no worky, i assume [01:52:55 CEST] <Daemon404> [mpeg @ 0x21a0240] Could not find codec parameters for stream 5 (Audio: ac3, 48000 Hz, 5.1(side), fltp, 384 kb/s): unknown codec [01:52:59 CEST] <Daemon404> Consider increasing the value for the 'analyzeduration' and 'probesize' options [01:53:02 CEST] <Daemon404> [mpeg @ 0x21a0240] Could not find codec parameters for stream 6 (Audio: ac3, 48000 Hz, 5.1(side), fltp, 384 kb/s): unknown codec [01:53:05 CEST] <Daemon404> Consider increasing the value for the 'analyzeduration' and 'probesize' options [01:53:08 CEST] <Daemon404> these are there though [01:53:08 CEST] <nevcairiel> it thinks they are ac3 now? [01:53:10 CEST] <Daemon404> not in master [01:53:12 CEST] <Daemon404> i have NFC [01:53:36 CEST] <Daemon404> oh shit [01:53:45 CEST] <Daemon404> that audio duration change make pmp-demux match the old ref [01:53:48 CEST] <Daemon404> go figure. [01:53:50 CEST] <nevcairiel> lol [01:53:55 CEST] <nevcairiel> yay for that [01:54:56 CEST] <nevcairiel> these messages are definitely odd, it thinks they are ac3 first but then goes ahead to show them as dvd subs [01:55:05 CEST] <nevcairiel> i wonder if there isnt something that needs the update context flag [01:55:36 CEST] <Daemon404> yeah not sure [01:56:14 CEST] <Daemon404> st->request_probe = request_probe; [01:56:22 CEST] <Daemon404> this is the api for probing via packets right? [01:56:26 CEST] <nevcairiel> yes [01:56:36 CEST] <nevcairiel> i made that set the flag though when it probes [01:56:44 CEST] <Daemon404> i see [02:00:46 CEST] <Daemon404> im not gonna dig into that tonight [02:00:54 CEST] <nevcairiel> its probably related to that ac3 error messages somehow [02:00:58 CEST] <Daemon404> yeah i know [02:01:19 CEST] <Daemon404> fixing the 2nd ffserver BS bug [02:01:23 CEST] <Daemon404> then thats itfor me tonight [02:01:33 CEST] <Daemon404> do you have time to poke a few things tomorrow before i wake up? [02:02:00 CEST] <nevcairiel> that depends how my work inbox looks when i wake up [02:02:17 CEST] <Daemon404> lol k [02:03:31 CEST] <nevcairiel> i will look at the vob ac3 thing, will see what else i can dig into [02:04:11 CEST] <nevcairiel> it sounds like some stupid mistake somewhere since it shows the info of a previous track [02:04:13 CEST] <nevcairiel> but who knows [02:05:15 CEST] <nevcairiel> well ok the error was a stupid mistake [02:05:26 CEST] <nevcairiel> but now it shows the actual error =p [02:05:41 CEST] <Daemon404> ;p [02:05:47 CEST] <Daemon404> ok [02:05:55 CEST] <nevcairiel> [mpeg @ 02640ec0] Could not find codec parameters for stream 5 (Unknown: none): unknown codec [02:05:57 CEST] <nevcairiel> yay? [02:06:33 CEST] <Daemon404> wut? [02:06:36 CEST] <Daemon404> context? [02:06:54 CEST] <nevcairiel> thats what happens if i fix the logging of the error [02:07:00 CEST] <Daemon404> o [02:07:15 CEST] <Daemon404> anyway... i gotta run off [02:07:19 CEST] <Daemon404> ttyl [02:07:24 CEST] <Daemon404> (and go to bed) [02:09:58 CEST] <rcombs> incomplete codecpar probably shouldn't cause outright failures in ffmpeg.c [02:15:30 CEST] <nevcairiel> i fixed the errors, but i dont have ffplay setup to test if i get subs [02:15:31 CEST] <nevcairiel> oh well [02:15:48 CEST] <nevcairiel> actually i lied the errors came back [02:15:51 CEST] <nevcairiel> what did i break now [02:20:46 CEST] <nevcairiel> now i made it go away [02:29:48 CEST] <nevcairiel> Daemon404: fate-movenc seems broken, that one is your speciality =p [02:30:43 CEST] <nevcairiel> (probably from init/write_header) [02:32:40 CEST] <nevcairiel> also can someone upload the new sample for vp6a already? that fate failure is annoying :) [05:29:33 CEST] <Daemon404> oh good [07:22:24 CEST] <Timothy_Gu> Hmm http://fatebeta.ffmpeg.org/report/x86_32-linux-gnu-gcc-4.8-tg/2016040402410… [09:00:42 CEST] <durandal_170> I gonna push musx/dat4 [09:03:50 CEST] <cone-268> ffmpeg 03Claudio Freire 07master:7d49abdf4750: AAC encoder: fix filling of wi.clipping array [09:31:14 CEST] <j-b> 'morning [11:02:48 CEST] <nevcairiel> github is no fun when its half broken [11:05:11 CEST] <JEEB> nevcairiel: yeqah [11:05:18 CEST] <JEEB> at least the git part in general seems to be more stable [11:05:24 CEST] <thardin> what did they do now? [11:05:32 CEST] <JEEB> their web side is pretty bad right now [11:05:33 CEST] <nevcairiel> its just being slow as fuck because down [11:05:44 CEST] <thardin> good thing git is this decentralized thing then [11:05:54 CEST] <nevcairiel> i'm trying to use the issue tracker though [11:06:21 CEST] <JEEB> yeah, that gets really aggravating. esp. with the new "loading bar" [11:06:33 CEST] <thardin> just gitlab [11:11:55 CEST] <nevcairiel> interesting though, I did push to github but the UI doesnt show those commits :D [11:13:16 CEST] <nevcairiel> ah they showed up [11:19:53 CEST] <fritsch> github currently has a minor outtage [11:20:07 CEST] <nevcairiel> i got a unicorn error page earlier, thats not minor to me [11:20:20 CEST] <wm4> for github it is lol [11:20:59 CEST] <nevcairiel> actually github it self calls it a major outtage [11:21:07 CEST] <nevcairiel> https://status.github.com/messages [11:21:11 CEST] <nevcairiel> although seems to be coming back now [11:29:36 CEST] <cone-268> ffmpeg 03Paul B Mahol 07master:8a4c3f525831: avcodec: add adpcm dat4 decoder [11:29:37 CEST] <cone-268> ffmpeg 03Paul B Mahol 07master:56a3a3f01ca5: avformat: add musx demuxer [12:30:23 CEST] <cone-268> ffmpeg 03Clément BSsch 07master:040598218f48: sws/aarch64: restore ff_hscale_8_to_15_neon() [13:33:11 CEST] <wm4> hm, current codecpar_rebase doesn't pass fate? [13:36:28 CEST] <nevcairiel> lowres of course [13:36:35 CEST] <nevcairiel> also the vp6a sample still isnt uploaded anywhere [13:36:36 CEST] <wm4> fate-movenc [13:44:29 CEST] <nevcairiel> oh yeah that got broken last night [13:47:32 CEST] <ubitux> the guy forked openjpeg without changing the library name? [13:47:37 CEST] <ubitux> reminds me of a story [13:48:04 CEST] <ubitux> nasty to also change the license at the same time [13:48:06 CEST] <ubitux> iiuc [13:53:02 CEST] <nevcairiel> well he changed the project name, but changing the library name itself would of course require getting people to support his shit instead of being a drop-in replacement =p [13:59:17 CEST] <ubitux> i suggest to refuse that patch then [14:03:10 CEST] <JEEB> not sure if my opinion is worth anything, but just by the fact that we don't generally allow new licenses (knowingly) and due to what a clusterfuck the guy's license is I'm also against merging support for his fork [14:14:27 CEST] <durandal_170> guy is buzzinesman obviously [14:39:39 CEST] <wm4> what the heck faa2930f191099621e03c55cca32662467d3cc15 [14:39:56 CEST] <wm4> ever since that AV_PKT_DATA_NEW_EXTRADATA is ignored [14:40:00 CEST] <wm4> in the aac decoder [15:25:21 CEST] <wm4> how hard would it be to make ffmpeg.c act on the decoder output (first AVFrame), instead of the demuxer info? the codecpar API change even mandates this to a degree [15:37:38 CEST] <wm4> wow [15:37:50 CEST] <wm4> lowres is not only failing because the codec parameters are messed up [15:38:01 CEST] <wm4> it's also failing because lowres is not set on the decoder context? [15:38:33 CEST] <wm4> or maybe I'm just dumb [15:39:22 CEST] <wm4> yeah, the latter [15:51:17 CEST] <av500> what is lowres? [15:51:31 CEST] <wm4> an extremely shitty feature that only 1 dev cares about [15:51:32 CEST] <av500> I'm only with the project since 2003, so I might not remember... [15:51:43 CEST] <wm4> decoding video at half res [15:51:59 CEST] <av500> for interlaced? [15:52:03 CEST] <wm4> no [15:52:16 CEST] <nevcairiel> typically formats which somehow tend to support that, like jpeg [15:54:07 CEST] <wm4> the feature alone is pretty harmless (probably), but the influence it has on other code sucks [15:55:05 CEST] <durandal_170> and exr and j2k [15:55:50 CEST] <durandal_170> it should be moved to private option [16:00:11 CEST] <wm4> nevcairiel: acceptable? http://sprunge.us/JhAh [16:00:15 CEST] <wm4> it's a bit fragile [16:01:24 CEST] <nevcairiel> if the container w/h are not set, or invalid, codecpar will end up wrong [16:02:01 CEST] <wm4> I don't see how lowres could work if they're not set [16:02:19 CEST] <nevcairiel> the codec might produce them? [16:03:01 CEST] <kierank> av500: using dc coefficients to produce a lowres version [16:03:15 CEST] <kierank> kinda like progressive jpeg [16:03:30 CEST] <wm4> nevcairiel: it's at the end of avformat_find_stream_info(), so if it doesn't produce them, when will it ever [16:04:08 CEST] <nevcairiel> you are telling it not to update codecpar w/h from the avctx [16:04:15 CEST] <nevcairiel> so if the container didnt set any, then codecpar will be empty [16:04:47 CEST] <nevcairiel> or if the container set wrong dimensions, they will remain wrong [16:04:47 CEST] <wm4> so should I check for st->internal->avctx_inited? [16:05:47 CEST] <nevcairiel> your entire approach still has the potential to change codecpar when lowres is set, which is what we're trying to avoid [16:06:39 CEST] <wm4> when? if the parser does? [16:07:02 CEST] <nevcairiel> [16:04:08] <nevcairiel> you are telling it not to update codecpar w/h from the avctx [16:07:02 CEST] <nevcairiel> [16:04:15] <nevcairiel> so if the container didnt set any, then codecpar will be empty [16:07:02 CEST] <nevcairiel> [16:04:47] <nevcairiel> or if the container set wrong dimensions, they will remain wrong [16:14:04 CEST] <nevcairiel> doesnt mpeg2 support lowres? if you use that from mpegts with lowres decoding, codecpar probably ends up without w/h [16:16:14 CEST] <wm4> works with ffplay and from mpeg-ps [16:17:31 CEST] <nevcairiel> that doesnt use codecpar tho [16:21:20 CEST] <wm4> oh, right, lowres must also be passed to find_stream_info [16:21:51 CEST] <wm4> michaelni: what other programs use this lowres API? [16:22:33 CEST] <ubitux> api user that need a fast first pass analysis i guess [16:23:01 CEST] <ubitux> actually not even api [16:23:08 CEST] <ubitux> (if supported) [16:39:40 CEST] <Daemon404> nevcairiel, im just going to move the autobsf mov stuff to a diff branch [16:39:49 CEST] <Daemon404> its not needed for codecpar, but id still like to submit it after [16:40:03 CEST] <nevcairiel> i guess [16:40:14 CEST] <Daemon404> im pretty sure i know the issue [16:40:17 CEST] <nevcairiel> take both commits then for simplicity [16:40:20 CEST] <Daemon404> yes [16:40:30 CEST] <Daemon404> both = both to movenc, i assume [16:40:41 CEST] <nevcairiel> yes the init split and the check_bitstream [16:40:50 CEST] <Daemon404> they should be one commit anyway [16:41:26 CEST] <Daemon404> how's lowres going (i havent read backlog0 [16:49:15 CEST] <wm4> Daemon404: I tried a hack, nevcairiel said it's too fragile [16:49:21 CEST] <wm4> patch http://sprunge.us/JhAh [16:49:40 CEST] <wm4> the problem is that these can be overwritten later anyway in whatever situations [16:50:05 CEST] <darkapex> Is it fine if two people work on the same qualification task for different programs (gsoc and outreachy)? [16:50:29 CEST] <Daemon404> wm4, right [16:50:37 CEST] <Daemon404> also i love that a different ugly hack i aded is the ine patch context [16:50:41 CEST] <Daemon404> makes me all warm and fuzzy inside [16:53:12 CEST] <wm4> the thing I regret is that we have to live with those for 2 years [16:53:23 CEST] <wm4> (apparently) [16:53:27 CEST] <kierank> darkapex: yes [16:53:55 CEST] <Daemon404> wm4, we've lived with worse, for longer [16:54:01 CEST] <Daemon404> it starst with ff and ends with server [16:54:27 CEST] <ubitux> michaelni: i'm doing `ffmpeg -f lavfi -i testsrc2=s=5472x3648 -frames:v 1 -y /tmp/test.jpg` then `./ffmpeg -i /tmp/test.jpg -vf scale=512x512 -y /tmp/out.jpg`; in the second command both yuv2yuvX_sse3 AND yuv2planeX_8_c are called [16:54:28 CEST] <nevcairiel> everything around here starts with ff [16:54:33 CEST] <ubitux> any idea why? [16:55:01 CEST] <Daemon404> nevcairiel, except swscale [16:55:04 CEST] <Daemon404> and swr [16:55:13 CEST] <Daemon404> wait av != ff [16:55:14 CEST] <Daemon404> brb coffee [16:55:18 CEST] <ubitux> michaelni: the "timeline" looks something like http://sprunge.us/URVg [16:55:21 CEST] <ubitux> i'm a bit lost [17:00:35 CEST] <durandal_170> when meeting? [17:00:52 CEST] <durandal_170> I want to vote? [17:16:32 CEST] <ubitux> michaelni: basically, it appears to call ff_sws_init_output_funcs() without calling ff_sws_init_swscale_x86() afterwards like the first time [17:16:59 CEST] <cone-268> ffmpeg 03Derek Buitenhuis 07master:fdd7a594c3e9: libxvid: Create extradata in init using a dummy frame [17:17:47 CEST] <ubitux> /* hmm looks like we can't use MMX here without overwriting [17:17:49 CEST] <ubitux> * this array's tail */ [17:17:54 CEST] <ubitux> i guess it comes from this, meh. [17:21:50 CEST] <Daemon404> wm4, i dont have any better ideas for lowres [17:26:39 CEST] <ubitux> michaelni: ah, my bad, apparently it's just for a small part of the image [17:40:01 CEST] <Daemon404> michaelni, can you upload the new vp6a test to the fate rsync servers [17:52:47 CEST] <Daemon404> time to look at ogm... lol [17:53:03 CEST] <Daemon404> without even looking at the file, i know it is anime. [17:55:13 CEST] <Plorkyeran_> is there any non-anime ogm? [17:55:25 CEST] <Daemon404> good point [17:56:34 CEST] <gnafu> I think I tried to rip a non-anime DVD to OGM once a very long time ago. [17:56:49 CEST] <gnafu> In my younger, more impressionable days. [17:56:51 CEST] <Daemon404> oh [17:57:01 CEST] <Daemon404> i have some futurama OGMs somewhere [17:57:05 CEST] <Daemon404> ... from an anime release group. [17:57:17 CEST] <gnafu> And there it is. [17:58:47 CEST] <Daemon404> the borken file in question was indeed anime [17:58:49 CEST] <Daemon404> tenchi muyo. [18:00:40 CEST] <Daemon404> Stream #0:1(English): Audio: vorbis, 48000 Hz, stereo, fltp, 4294967 kb/s [18:00:43 CEST] <Daemon404> Stream #0:2(Japanese): Audio: vorbis, 48000 Hz, stereo, fltp, 4294967 kb/s [18:00:46 CEST] <Daemon404> somehow i dont think this bitarte is correct [18:00:51 CEST] <Daemon404> this is with git master too [18:19:37 CEST] <Shiz> Daemon404: lies and slader [18:19:41 CEST] <Shiz> there's VN OGMs too [18:28:48 CEST] <kierank> LAVFI TROLL UPCOMING [18:29:00 CEST] <kierank> so vf_blackdetect? how does one use it? [18:29:05 CEST] <kierank> it just prints to the cli [18:29:07 CEST] <kierank> totally useless [18:29:15 CEST] <nevcairiel> most of those detect filters just do that [18:29:21 CEST] <nevcairiel> with any luck it may set metadata [18:29:34 CEST] <wm4> the "proper" way to do that is to set AVFrame.metadata or something [18:29:48 CEST] <kierank> well I want to write a stuck frame filter [18:33:20 CEST] <nevcairiel> Daemon404: technically the seek-test tool tests both seek modes, backwards and forwards, only one of those is supposed to end up before the seek point [18:33:40 CEST] <Daemon404> i see [18:33:57 CEST] <nevcairiel> not that it matters much [18:34:07 CEST] <Daemon404> if i print the info, before that one seek, info is garbage [18:34:10 CEST] <Daemon404> since the file is broken [18:34:45 CEST] <Daemon404> i.e. it may rely on a *different* stream getting updated to seek based on that stream [18:34:52 CEST] <Daemon404> (i could be reading it wrong) [18:35:04 CEST] <Daemon404> im still inclined to say "i dont care about changes on this kind of broken file" [18:38:12 CEST] <Daemon404> who else besides michaelni has access to upload fate files/ [18:38:41 CEST] <nevcairiel> i do [18:38:53 CEST] <Daemon404> o [18:39:02 CEST] <Daemon404> i have a copy of the new ref if you wanna upload it [18:39:21 CEST] <nevcairiel> link me the file and where to, and i will [18:41:47 CEST] <Daemon404> http://chromashift.org/300x180-Scr-f8-056alpha.mov [18:41:57 CEST] <Daemon404> goes in the flash-vp6 dir [18:44:59 CEST] <nevcairiel> shiuld be there [18:45:02 CEST] <nevcairiel> should* [18:45:07 CEST] <Daemon404> yep [18:45:09 CEST] <Daemon404> sync'd it [18:45:18 CEST] <Daemon404> so did we give up on lowres toay? [18:45:19 CEST] <Daemon404> today* [18:47:14 CEST] <wm4> my patch could probably be extended so that it works, in whatever situation it'd break now [18:47:42 CEST] <Daemon404> i see [18:49:20 CEST] <wm4> my patch is pretty fragile, but I haven't seen any api usage/sample to break it yet [18:49:54 CEST] <nevcairiel> because we dont have anything that uses codecpar [18:50:20 CEST] <wm4> I tried with my own code [18:50:31 CEST] <wm4> but it doesn't pass parameters to av_find_stream_info [18:50:38 CEST] <wm4> so, probably pointless [18:57:44 CEST] <wm4> [ac3 @ 0x7b9a40] The maximum value for lowres supported by the decoder is 0 [18:58:09 CEST] <nevcairiel> use -vlowres =p [19:21:10 CEST] <wm4> hm even if I pass lowres to av_find_stream_info I can't break it [19:21:19 CEST] <wm4> of course that means nothing in general [19:22:07 CEST] <nevcairiel> just try with ffplay and print codecpar at the end to verify its actually filled properly, on a container which doesnt provide container level infos and needs the decoder to fill some in [19:22:31 CEST] <nevcairiel> or even worse, a container that provides the wrong container level info =p [19:22:45 CEST] <nevcairiel> it sounds to me like it would end up with empty w/h [19:22:51 CEST] <nevcairiel> (or retain the wrong one) [19:24:38 CEST] <wm4> ok, breaks with mpeg2, so I'll try to fix this case [19:24:59 CEST] <wm4> it retains the original res, but unfortunately also on the avstream.codec [19:27:55 CEST] <nevcairiel> does a lowres decoder export the lowres factor so we could un-lowres? [19:28:41 CEST] <wm4> we can't un-lowres because of rounding [19:28:45 CEST] <wm4> but yes it does [19:37:03 CEST] <wm4> lol [19:37:10 CEST] <wm4> the mpg2 case is broken in git master? [19:37:16 CEST] <Daemon404> it is? [19:37:19 CEST] <Daemon404> lol [19:37:23 CEST] <wm4> let me double-check [19:37:33 CEST] <wm4> err, ffmpeg 2.8 [19:37:37 CEST] <wm4> but shouldn't matter much [19:37:57 CEST] <wm4> Input stream #0:0 frame changed from size:720x576 fmt:yuv420p to size:180x144 fmt:yuv420p [19:38:00 CEST] <wm4> with ffmpeg 2.8 [19:38:01 CEST] <wm4> lol [19:38:13 CEST] <wm4> michaelni: can you confirm this? [20:16:06 CEST] <Daemon404> is that agpl thign STILL going? [20:16:28 CEST] <RiCON> the guy is still going* [20:16:34 CEST] <Daemon404> hah [20:16:36 CEST] <michaelni> wm4, it seems you are correct, mpeg2 lowres doesnt fully work [20:17:58 CEST] <wm4> k [20:19:11 CEST] <michaelni> it works with ffplay it doesnt work with ffmpeg [20:20:56 CEST] <wm4> because ffmpeg.c is stupid [20:21:15 CEST] <wm4> but according to you that's the API anyway, and it's broken in gi master [20:21:17 CEST] <wm4> *git [20:36:56 CEST] <michaelni> the API is sadly defined by how its used and ffmpeg.c uses it that way [20:43:48 CEST] <wm4> nevcairiel: so should I push my current patch? [23:06:44 CEST] <sb_> Is there a way to configure the build so that all headers are included? [23:19:08 CEST] <michaelni> about the "hardware assist H264 video encoding for the Raspberry Pi" patch, i intend to apply this in a few days if theres no clear objection. I will of course not apply if someone clearly states that he is against [23:19:30 CEST] <michaelni> just saying here too so its not missed in the thread [23:23:58 CEST] <wm4> miI'm still against it [23:24:19 CEST] <wm4> s/mi/michaelni:/ [23:24:32 CEST] <JEEB> I guess MMAL is better than OMX? [23:27:20 CEST] <michaelni> wm4, you spoke of a lowres patch above, where can i find that? (for testing & review) [23:35:22 CEST] <wm4> michaelni: http://sprunge.us/JhAh [00:00:00 CEST] --- Wed Apr 6 2016

1 0

ffmpeg.log.20160405
by burek 06 Apr '16

06 Apr '16

[00:08:41 CEST] <nadermx> I have a bizzar issue, I have ffmpeg on two servers. Installed the same on both, but when I try and run a command using http_proxy it works on one but other gives 403 error so I figure the other isn't using the proxy [00:12:41 CEST] <nadermx> the only thing i see different when running in debug mode is [https @ 0x5d030a0] Setting default whitelist 'http,https,tls,rtp,tcp,udp,crypto,httpproxy' [00:13:05 CEST] <nadermx> vs the one that works seems to not have 'httpproxy' as a whitelist option [04:18:40 CEST] <circ-user-wCvyX> does ffmpeg support persistent connections when playing HLS? [04:52:00 CEST] <circ-user-wCvyX> hello [05:56:12 CEST] <taliatina> Hi all [05:56:44 CEST] <taliatina> Could u please guide me ... [05:57:16 CEST] <taliatina> I wish to know is it ffmpeg use to encode to h264? [05:57:53 CEST] <taliatina> does ffmpeg use to encode to h264? [05:58:02 CEST] <petecouture> yes [05:58:09 CEST] <petecouture> but only if you wish it hard enough [05:59:20 CEST] <petecouture> taliatina: I'd recommend starting with a google search for beginners guide +h264. You'll find what you're looking for. [05:59:47 CEST] <taliatina> I am reading a paper it is used ffmpeg. this is the sentence of paper "e sequences were first compressed with ffmpeg 30 times (static quantizer scale values ranging 231 are supported by ffmpeg)." [06:00:31 CEST] <taliatina> I cant understand what does it mean? [06:01:10 CEST] <petecouture> Ya that's beyond my knowledge at the moment. I would look for a breakdown of the protocol or look up the RTC spec on it if you need to get dirty. [06:03:06 CEST] <taliatina> I am very new in this field [06:03:52 CEST] <taliatina> paper called the result of ffmpeg "MPEG-4 files" [06:04:48 CEST] <taliatina> does it mean that ffmpeg enchode the video to mpeg-4? [06:06:39 CEST] <taliatina> which format of encode file is possible to have by converting the video if using ffmpeg? [06:08:19 CEST] <taliatina> I would appreciate if you can guide me [06:09:08 CEST] <FlorianBd> Hi there! Just encoded an avi to mp4 for html5 use, and the audios is messed up, here's the output. Anything wrong you notice? Any suggestion? THanks! http://pastebin.com/iiZ1MV1J [06:11:02 CEST] <taliatina> I am reading an article about Evalvid-RA [06:11:26 CEST] <taliatina> it is written that as a pre process they gave video to ffmpeg [06:11:55 CEST] <taliatina> the result is mpeg-4 files [06:12:28 CEST] <taliatina> then they gave the mpeg-4 files to mp4.exe to have ASCII trace files [06:12:44 CEST] <taliatina> the ASCII trace files goes through the ns2 [06:13:04 CEST] <taliatina> i was looking att the site of ffmpeg [06:14:17 CEST] <taliatina> to find any information about that. to understand what is really the goal of ffmpeg? and is it really possible to change video to mpeh-4? [06:14:22 CEST] <taliatina> if yes [06:14:33 CEST] <taliatina> mpeg-4* [06:14:54 CEST] <taliatina> what else is possible to make by ffmpeg [06:35:05 CEST] <petecouture> How do I tell when a feature was added to ffmpeg? I'm getting option not found for use_localtime [08:32:04 CEST] <momomo> kepstin, i think i will keep this version and try to update in maybe a month if this patch might get in later on? [08:33:00 CEST] <momomo> even better would be an option for being able to set a target duration .. which could prove useful to force prefetching for slow networks [09:20:59 CEST] <AleXoundOS> Hi. Does it matter if I apply -fflags to input or output? [10:45:58 CEST] <cowai> Hi, do anybody know how I can add more caching time for hls as a input? [10:46:33 CEST] <cowai> the hls server that I use as input is very slow and sometimes leads to timeouts [10:52:46 CEST] <DHE> a bigger -hls_time may help. Maybe 6-10 seconds? [10:53:08 CEST] <cowai> my output is udp mpegts [10:53:18 CEST] <cowai> isnt hls_time only for hls output? [10:53:31 CEST] <DHE> oh, you using wowza or something? [10:54:03 CEST] <cowai> I dont know what the hls is produced by [10:54:06 CEST] <cowai> its a live stream [10:54:40 CEST] <cowai> I just want to have like a 30second buffer to let it get all segments in time if there is any timeouts [10:54:49 CEST] <cowai> I am restreaming it as udp mpegts on my local lan [10:55:06 CEST] <DHE> oh, you mean HLS to UDP? [10:55:51 CEST] <cowai> yes exactly [10:55:56 CEST] <cowai> input is hls, output is udp [10:56:03 CEST] <DHE> normally I go the other way... [10:56:20 CEST] <cowai> yes I know its a little unusual [10:56:50 CEST] <cowai> I am monitoring a hls channel but the equipment I am using only supports udp [11:29:56 CEST] <momomo> cowai, i have been going through similar issues [11:30:05 CEST] <momomo> it's not an easy problem to resolve [11:31:06 CEST] <momomo> but basically, once the first hls segment and playlist is ready, you need to block your users for some time .. the easiest is to block them access for the same amount of time as the hls segment lenght + 1s .... that way, when they get the playlist file it will contain at least 2 segments [11:31:13 CEST] <momomo> but start playing on first [11:32:06 CEST] <momomo> if you want your wait to be lower then you need more advanced approach and manipulate the EXT_TARGET value accordinngly but only the first time . [14:24:04 CEST] <meldron> Hi guys, is it possible to cut a x264 video without reencoding [14:40:30 CEST] <BurnerGR> yes [14:42:28 CEST] <furq> meldron: yes, if you cut on IDR frames [14:43:36 CEST] <meldron> furq: is there a simple approach to do so with ffmpeg? [14:43:39 CEST] <thunfisch> is it possible to record a rtsp stream, which is already h264 encoded, and add audio from a alsa source without reencoding? https://paste.xinu.at/Ihkk/ using this right now, but it's reencoding. :( [14:44:42 CEST] <BurnerGR> meldron, something like this will usually work: ffmpeg -ss <seconds> -t <seconds> -i input.mp4 -c:a copy -c:v copy cut_scene.mp4, but as furq say, you will have to find the IDR frames in order to do it properly [14:45:35 CEST] <furq> that will work, it'll just seek to the nearest (next?) IDR frame [14:45:48 CEST] <meldron> BurnerGR: this was my first approach, but without regard to the IDR frames and very bad results [14:45:53 CEST] <furq> if you want to cut on any other frame you need to reencode [14:48:00 CEST] <meldron> BurnerGR: if I do it your way, the first x seconds are counted as negative numbers [14:50:28 CEST] <BurnerGR> meldron, it seek -ss seconds into the file, find the next IDR frame, and start encoding -t seconds from there [14:50:51 CEST] <BurnerGR> I'm not sure what you mean by negative numbers? [14:52:10 CEST] <meldron> BurnerGR: http://storage6.static.itmages.com/i/16/0405/h_1459860759_1217091_2c37086a5… [14:52:37 CEST] <BurnerGR> thunfisch, you need to add -c:v copy in order to tell ffmpeg to copy the video codec instead of reencoding [14:52:38 CEST] <meldron> so i seeked in 4 seconds, but the cut started at 0 and this 4 seconds were shown as negative numbers [14:53:41 CEST] <thunfisch> BurnerGR: tried that at first, but got the error "Unknown decoder 'copy'" [14:53:51 CEST] <furq> thunfisch: put it after -i [14:53:52 CEST] <BurnerGR> meldron, I suppose frame 0 were the closest IDR frame then [14:54:16 CEST] <thunfisch> furq: still won't work [14:54:30 CEST] <furq> after the second -i [14:55:01 CEST] <thunfisch> oh, wow, yes. [14:55:05 CEST] <thunfisch> that works. thanks alot! [14:56:04 CEST] <furq> meldron: you can use -avoid_negative_ts 1 if the cut is close enough for you [16:02:59 CEST] <meldron> furq: thanks, i think i will reorder my general approach [17:39:46 CEST] <sb_> is there a way using the public api (av_opt_set_int) to set an MOV flag in AVOutputFormat's priv_data? [17:59:11 CEST] <ac_slater> hey all. I want to use ffmpeg as input to another application (an external h.264 encoder). I fear that `ffmpeg -i ... | my_enc` won't work as my_enc needs to know the size of the input. Is there a way for ffmpeg to spit out output size? [17:59:25 CEST] <ac_slater> size of each frame* [18:00:46 CEST] <paule32> hello [18:01:10 CEST] <paule32> i have following config: http://fpaste.org/349918/98720251/ [18:01:27 CEST] <paule32> what have i do, to see the stream in browser or vlc? [18:02:30 CEST] <ac_slater> paule32: is this an ffserver config? [18:02:39 CEST] <paule32> nginx [18:02:49 CEST] <paule32> have i do a ffserver? [18:02:50 CEST] <ac_slater> ah, good luck there. [18:02:56 CEST] <ac_slater> paule32: google it mate [18:03:10 CEST] <ac_slater> https://ffmpeg.org/ffserver.html [18:03:17 CEST] <furq> don't use ffserver [18:03:25 CEST] <furq> paule32: https://github.com/dailymotion/hls.js/ [18:03:34 CEST] <furq> you should be able to play the rtmp url in vlc, or the hls .m3u8 [18:03:44 CEST] <paule32> thx [18:20:09 CEST] <john_doe_jr> I'm trying to record my audio using the following command but when I play the out.mpg with ffmpeg it is not very loud and of poor quality&any ideas why? Here is the command I am using: ffmpeg -f avfoundation -i ":0" out.mpg [18:20:52 CEST] <furq> it's probably encoding it with the builtin mp2 encoder using the default settings [18:21:04 CEST] <furq> do you have some good reason for using mpg [18:21:38 CEST] <john_doe_jr> furq: Nope&I'm a newbie trying to learn ffmpeg&what's the best quality and loudness I can get then? [18:21:48 CEST] <furq> the best quality would be wav or flac [18:21:53 CEST] <furq> or some other lossless codec [18:22:11 CEST] <furq> you'd probably need some kind of audio filter for loudness [18:23:29 CEST] <bencoh> not sure what you mean by "best loudness" though [18:23:42 CEST] <bencoh> EBU-R128 compliance? [18:24:01 CEST] <bencoh> or just "louder"? [18:24:09 CEST] <durandal_170> dynaudnorm,volume,compand,acompressor,alimiter, [18:24:29 CEST] <john_doe_jr> bencoh: just louder..I can hardly hear it [18:24:38 CEST] <furq> john_doe_jr: -af volume=volume*2 will double the volume [18:24:56 CEST] <furq> there are more scientific ways to do it [18:26:27 CEST] <john_doe_jr> furq: so this would be a better command: ffmpeg -f avfoundation -i ":0" -af volume=volume*2 out.wav [18:26:29 CEST] <furq> er, -af volume=volume=2 [18:26:38 CEST] <furq> but yeah [18:27:31 CEST] <furq> if you don't care about listening while it's being recorded you'd be better off normalising it after the recording is done [18:27:38 CEST] <john_doe_jr> furq: it still sounds far away [18:27:59 CEST] <john_doe_jr> furq: normalizing it? [18:28:30 CEST] <furq> normalising it will bring the peak volume to 0.0dB [18:28:44 CEST] <furq> you obviously don't know what the peak is until you can process the whole thing [18:28:48 CEST] <john_doe_jr> furq: I've found this link: https://trac.ffmpeg.org/wiki/Encode/HighQualityAudio [18:29:14 CEST] <john_doe_jr> furq: so what would be the command line to do that then? [18:30:43 CEST] <john_doe_jr> furq: it's recording through the microphone&.maybe I should redirect output using sound flower or something [18:31:01 CEST] <bencoh> john_doe_jr: see what d.urandal_170 said [18:31:33 CEST] <bencoh> and read corresponding audio filters documentation :) [18:31:53 CEST] <furq> http://sprunge.us/EANi [18:31:56 CEST] <furq> something like that if you're on *nix [18:32:04 CEST] <john_doe_jr> furq: I'm on mac [18:32:10 CEST] <furq> that should work then [18:34:14 CEST] <john_doe_jr> fuq [18:34:46 CEST] <john_doe_jr> furq: what does the command have it's input as "-i test.flac" when I'm attempting to record the sound card on my mac&just wondering [18:35:02 CEST] <furq> run those after you've finished recording [18:35:12 CEST] <furq> otherwise you'll need to use a more complicated filter like dynaudnorm [18:36:22 CEST] <john_doe_jr> furq: so the test.flac is actually my output.wav that I'm currently outputtting [18:36:37 CEST] <furq> right [18:37:13 CEST] <john_doe_jr> furq: should I just call it test.flac now instead of output.wav? [18:37:21 CEST] <furq> it doesn't really make any difference [18:39:17 CEST] <john_doe_jr> furq: First command, "ffmpeg -i test.flac -af volumedetect -f null /dev/null 2>&1 | grep max_volume" just hangs [18:43:48 CEST] <paule32> ok [18:43:59 CEST] <paule32> ffserver is running [18:44:00 CEST] <paule32> http://fpaste.org/349946/74588145/ [18:45:30 CEST] <zamba> hi.. i'm in the process of digitalizing some old vhs tapes.. they have some distortion on them, maybe some frames here and there that needs to be just removed from the stream.. can ffmpeg help out here? or do i have to use some other tool for this? [18:45:36 CEST] <zamba> if so, which tool do you recommend? [18:45:57 CEST] <zamba> i basically just need to replace these frames with a frame before or after, to maintain the sync [18:46:12 CEST] <zamba> but it'll be a manual process, i fully understand that [18:46:17 CEST] <furq> john_doe_jr: what happens if you remove | grep max_volume [18:46:31 CEST] <furq> zamba: avisynth has some good filters for cleaning stuff like that up [18:46:53 CEST] <kepstin> zamba: it's doable with e.g. the 'select' filter, then put an 'fps' filter after it to duplicate frames to replace the ones you dropped. [18:47:24 CEST] <zamba> furq: it can do it automatically as well? [18:47:31 CEST] <furq> it depends [18:47:36 CEST] <zamba> kepstin: ffmpeg? [18:48:11 CEST] <kepstin> zamba: well, the tricky bit is figuring out whether or not you want to keep a frame [18:48:12 CEST] <zamba> because it's vhs, it's basically just some frames that are totally off, so if you analyze the video sequentially, you should be able to spot them pretty easily [18:53:10 CEST] <paule32> can you help? [18:53:55 CEST] <furq> paule32: i thought you were using nginx [18:54:03 CEST] <furq> ffserver is basically abandoned and nobody uses it [18:54:34 CEST] <paule32> furq: out of date? [18:54:42 CEST] <paule32> what can i use? [18:54:53 CEST] <furq> nginx? [18:55:19 CEST] <paule32> i think nginx is not so good, in your post? [18:55:31 CEST] <furq> ? [18:55:57 CEST] <paule32> i show you a config, and someone said good by [18:56:33 CEST] <furq> i said "don't use ffserver" [18:57:25 CEST] <paule32> ok, i misplaced [19:04:01 CEST] <momomo> furq, good news ... i am manipulating the target duration on the fly now .. and it works just flawless :D [19:04:14 CEST] <zamba> furq & kepstin: do any of you have any more details about either method? :) [19:04:16 CEST] <momomo> was pretty complicated though [19:05:39 CEST] <paule32> what means: Tue Apr 5 12:04:57 2016 xx.xx.xx.xx - - [POST] "/video.flv HTTP/1.1" 404 146 [19:17:38 CEST] <paule32> http://fpaste.org/349964/14598766/ [19:17:46 CEST] <paule32> while idle? [19:18:11 CEST] <paule32> i must say i sit behind a nat [19:18:27 CEST] <paule32> have i use a vpn? other port? [19:18:37 CEST] <furq> if this is with nginx-rtmp then that's the wrong url [19:18:58 CEST] <furq> you want -f flv rtmp://abc.de/live/xyz [19:19:53 CEST] <paule32> its with ffserver [19:20:02 CEST] <paule32> http://<ffserver_ip_address_or_host_name>:<ffserver_port>/<stream_name> [19:20:52 CEST] <paule32> https://trac.ffmpeg.org/wiki/ffserver [19:23:18 CEST] <shincodex> anyone know if jsoncpp is a leaky junk library? [19:33:45 CEST] <paule32> what port should i get, to get back upstream flv video? [19:33:56 CEST] <paule32> i want to use port 80 [19:34:06 CEST] <paule32> because it s not blocked [19:34:18 CEST] <paule32> but it seems it does not work [19:44:06 CEST] <petecouture> Arrgg, I recently upgraded to the latest version of ffmpeg and now my script doesn't work. ffmpeg runs like it's encoding but it doesn't show any framecount increasing. Anyone help :-( http://pastebin.com/8szPhCuE [19:44:45 CEST] <paule32> http://fpaste.org/349985/59878274/ [19:45:04 CEST] <paule32> what is wrong with ffmpeg/server [19:47:37 CEST] <melkor> I have an image, I want to create an animation where I start at the bottom and pan to the top. Is ffmpeg good for that, or should I write a quick program in java? [19:47:41 CEST] <tuelz> I've been playing around with this idea in my head, that I'll likely never get around to implementing, but it's still fun to think about...but basically having a p2p live streaming service where the central server is only handling presence and registry problems, while each viewer of a channel downloads and then uploads the video stream to a few people themselves to help it scale without incurring too much [19:47:43 CEST] <tuelz> latency from hops [19:48:04 CEST] <petecouture> melkor: I think you'd want Flash or ImageMagik [19:48:11 CEST] <pzich> melkor: that is possible to do, but if you want things like animation easing and easy controls, you're probably better off with something else [19:48:31 CEST] <tuelz> the biggest problem I don't know how to solve and I'm curious if it's possible...is I would like for the tree to heal itself via logic on the presence server and then via logic on the presence server to heal the video buffer that you lose while healing the p2p tree [19:48:35 CEST] <melkor> pzich: it is going to be to be a scroll up and then dwell a bit on the last image. [19:48:49 CEST] <tuelz> is stitching together two video streams in order to build back up a buffer difficult? [19:48:57 CEST] <petecouture> melkor: ffmpeg isn't the type of tool you use for animations like that. [19:49:15 CEST] <petecouture> I'd recommend Flash and learning how to tween on the timeline [19:49:27 CEST] <pzich> I really wouldn't recommend Flash if Flash isn't what he wants [19:49:36 CEST] <melkor> I don't do flash. [19:50:16 CEST] <melkor> I can do a different way pretty quickly, but if there was a convenient ffmpeg way to do it I was going to learn. [19:50:18 CEST] <petecouture> Flash would be the easiest to understand for someone just starting animation rendering. [19:52:04 CEST] <tuelz> so, a usecase. a first tier viewer is downloading and serving one person video...everyone starts with ~5 second buffer. When tier one person leaves, logic upgrades that tier 2 video to a tier 1 who is now bringing in data from the broadcaster directly, but it took 1 second to do that and now that viewer has 2 seconds worth of buffer....is it possible to use another tier 1 viewer to upload to our focus view [19:52:06 CEST] <tuelz> and heal his buffer back up to 3 seconds? [19:52:34 CEST] <tuelz> (I think my numbers are off there, pretend I said 3 second buffer at the start) [19:53:10 CEST] <petecouture> melkor: I'm not an advanced user of ffmpeg so I don't know if object timing and position can be rendered on an image the way you're looking for. But if you're looking to create some sort of automated animation creation system you could create the animation itself in x11 and then have ffmpeg record that screen. [19:53:46 CEST] <pzich> I also wouldn't recommend screen recording if you want it to be decent quality and no potential for dropped frames. [19:54:22 CEST] <melkor> I can pretty quickly create the sequence of images I want, and then use ffmpeg to turn it into an animated gif or short video. [19:54:32 CEST] <tuelz> essentially my presence server would know which part of the buffer my focus viewer needed and could send only that video, so my problem and I'm hoping ffmpeg has ways to deal with it, is stiching together video data seamlessly [19:54:39 CEST] <petecouture> pzich: but that would be the way to do it within ffmpeg without creating an application that uses the source though right? [19:54:41 CEST] <pzich> There are ways to control the filters via variables and other input value (e.g. time and frame number), so you could so something with crop similar to what they're doing with zoom here: http://stackoverflow.com/questions/23240841/zooming-animation-in-ffmpeg [19:55:18 CEST] <pzich> if you have a way to create the images you want and turn them in to a sequence, that may be better. Particularly if you aren't already familiar with variable and function usage in ffmpeg filters [19:55:26 CEST] <petecouture> ^ [19:56:18 CEST] <petecouture> pzich: I get why you could use filters to do it but without some sort of tween interface to design the transitions it's a nasty way to get the job done. [19:56:51 CEST] <petecouture> Also highly limited in animation capibilities. Assuming there's no easing packages [19:56:52 CEST] <pzich> agreed, if I really needed to do something like that in ffmpeg I'd probably probably write a script to generate the filter string for me. [19:57:15 CEST] <pzich> I mean you can go hardcore if you want, I believe there's sin(), cos() and friends :D [19:57:42 CEST] <melkor> I put my buddies head on a hot body, and I want it to scroll up to his face. [19:57:47 CEST] <pzich> but if it's an option, I'd definitely recommend animating elsewhere, Flash and screengrabbing just wouldn't be my first choice (or personally, my choice over raw ffmpeg) [19:58:51 CEST] <furq> melkor: you should be able to do it with the crop filter [19:58:56 CEST] <pzich> yeah [19:58:57 CEST] <furq> https://ffmpeg.org/ffmpeg-filters.html#crop [19:59:05 CEST] <pzich> and the time or frame number as the input value [19:59:17 CEST] <melkor> I can definitely get 1 image the way I want with the crop filter. [19:59:22 CEST] <furq> see the second and third from last examples [19:59:35 CEST] <furq> they show how to do a dynamic crop based on frame count [20:00:28 CEST] <paule32> furq: http://fpaste.org/349985/59878274/ [20:00:47 CEST] <furq> why did you highlight me with that [20:00:51 CEST] <furq> i don't know how to use ffserver [20:00:59 CEST] <paule32> sorry [20:01:24 CEST] <furq> the only ffserver advice i can offer is "don't use ffserver" [20:01:29 CEST] <pzich> :D [20:01:33 CEST] <furq> i doubt anyone else in here will be able to improve on that [20:01:35 CEST] <petecouture> this seems like sooo much work for just panning a simple mage [20:01:51 CEST] <petecouture> It can be done in 2 seconds in Flash and rendered to MOV [20:01:59 CEST] <pzich> but that's Flash [20:02:34 CEST] <petecouture> He's not looking for a long term solutions. It sounds like it's just a joke [20:02:38 CEST] <melkor> furq: So I would change the input framerate and the output framerate and then 1 image would become N images and I can specify the location of the crop box. [20:02:45 CEST] <paule32> me? [20:02:53 CEST] <furq> why would you need to change the input framerate [20:03:00 CEST] <petecouture> not u paule [20:03:04 CEST] <melkor> 1 image -> many images. [20:03:20 CEST] <pzich> I think you need -loop 1 [20:03:58 CEST] <furq> if you just want to pan up a static image then yeah, use -loop or -loop_input or whatever it is these days [20:03:59 CEST] <pzich> I think ffmpeg -loop 1 input-image.jpg -t <duration> -vf ... [20:04:07 CEST] <pzich> err, -i should be in there [20:04:35 CEST] <pzich> looks like -loop 1 is the new -loop_input: https://ffmpeg.org/pipermail/ffmpeg-user/2011-October/002531.html [20:04:57 CEST] <furq> -vf crop=w=320:h=240:x=0:y=-n [20:05:00 CEST] <furq> or something along those lines [20:05:14 CEST] <pzich> tweak and iterate as needed [20:05:22 CEST] <furq> you might need to figure out how many frames you need and pass that to -loop [20:05:24 CEST] <pzich> math is at your disposal! [20:05:31 CEST] <melkor> Ill give it a shot and use -stream_loop [20:06:51 CEST] <furq> -vf crop=w=in_w:h=320:x=0:y=(in_h-320-n) [20:06:52 CEST] <furq> or that, rather [20:11:03 CEST] <pzich> I'm not sure what happens when that hits a negative number, but you should be able to do something like min(0, in_h-320-n) if you need to [20:11:22 CEST] <pzich> err, actually max() in this case [20:15:00 CEST] <melkor> Soo close. [20:18:03 CEST] <rjp421> anyone have luck outputting ffmpeg to castnow? http://pastie.org/pastes/10786517/text [20:18:48 CEST] <rjp421> if i dont pipe and just put file.mp4, castnow will play the file [20:19:04 CEST] <melkor> Awesome, got it working, it seems like the overflow just sets the crop to the last good one. [20:19:07 CEST] <rjp421> can i do it live? [20:23:25 CEST] <furq> rjp421: does -f flv work [20:24:48 CEST] <rjp421> furq, just ...'-f flv - | castnow --quiet -'? [20:24:56 CEST] <furq> yeah just replace -f mp4 with -f flv [20:25:05 CEST] <rjp421> sec [20:25:08 CEST] <furq> failing that you can try -f mp4 -movflags frag_keyframe+empty_moov [20:26:33 CEST] <rjp421> furq, it started to encode but gave "Error: Load failed".. ill try with those ty [20:27:22 CEST] <furq> that looks like a castnow error [20:27:28 CEST] <furq> the line above that will probably be the ffmpeg error (if there is one) [20:29:52 CEST] <rjp421> furq awesome the movflags worked ty :D [20:29:59 CEST] <pzich> sweet [20:50:11 CEST] <thunfisch> i'm getting a 403 error when trying to stream to a ffserver on the same machine. acl allows 127.0.0.1. any ideas whats going wrong there? [20:58:13 CEST] <john_doe_jr> I would like to stream directly to another computer&the following is not working but why? ffmpeg -re -f avfoundation -i ":0" -acodec libmp3lame -f rtp rtp://192.168.12.55 [21:08:18 CEST] <john_doe_jr> anybody? [21:14:26 CEST] <melkor> john_doe_jr: how do you know it is not working? [21:24:05 CEST] <john_doe_jr> melkor: I get the following error: "av_interleaved_write_frame(): Can't assign requested address [21:24:06 CEST] <john_doe_jr> Error writing trailer of rtp://192.168.12.55: Can't assign requested address" [21:25:07 CEST] <furq> you probably need to assign a port [21:26:08 CEST] <john_doe_jr> furq: that worked! [21:27:09 CEST] <john_doe_jr> furq: well on the client I"m getting: "Guessing on RTP content - if not received properly you need an SDP file describing it" [21:46:21 CEST] <john_doe_jr> ok now I'm getting "Protocol not on whitelist 'file'" [21:55:57 CEST] <petecouture> john_doe_jr: IU can help with that [21:56:07 CEST] <petecouture> on a call one sec [21:56:43 CEST] <petecouture> So the new ffmpeg needs to have somethings whitelisted for security reasons I guess. Here's what i have ffmpeg -loglevel debug -protocol_whitelist file,udp,rtp,crypto -re -y -probesize 2147483647 -analyzeduration 2147483647 -i [21:56:54 CEST] <petecouture> that cuts off right beofre my sdp file load [21:57:06 CEST] <petecouture> but you can see the -protocol_whitelist parameter [21:59:41 CEST] <petecouture> I'm actually having a lot of issues with RTP input on the latest version of ffmpeg [22:25:57 CEST] <paule32> i get "av_interleaved_write_frame(): Connection reset by peer" how to fix? [22:28:56 CEST] <petecouture> looks like the rtp client is reseting? [22:30:11 CEST] <paule32> http://fpaste.org/350070/45988818/ [22:31:38 CEST] <petecouture> this comes first [libx264 @ 0x2e3be60] non-strictly-monotonic PTS [22:32:33 CEST] <paule32> what does it mean, how to fix? [22:32:53 CEST] <john_doe_jr> petecouture: I figured it out [22:33:11 CEST] <petecouture> cool, that flag wasn't documented when I ahd to look into it [22:33:19 CEST] <petecouture> it took 2 days to figure itout [22:33:32 CEST] <john_doe_jr> petecouture: I just googled the error [22:35:05 CEST] <petecouture> There wasn't anything in searchs when I looked a month ago. Nothing worth while at least. [22:37:34 CEST] <john_doe_jr> This is the command line that I have currently but the performance is that good&How can I make this better? [22:37:38 CEST] <john_doe_jr> ffmpeg -re -f avfoundation -i ":0" -acodec libmp3lame -ar 11025 -f rtp rtp://192.168.8.143:1234 [22:38:17 CEST] <petecouture> -vn ? [22:38:25 CEST] <petecouture> your just streaming audio yes? [22:38:29 CEST] <john_doe_jr> yes [22:38:37 CEST] <BtbN> why are you using such a crappy samplerate? [22:39:02 CEST] <john_doe_jr> BtbN: did not notice that&what would be a good sampling rate? [22:39:07 CEST] <BtbN> the default [22:39:19 CEST] <john_doe_jr> BtbN: so don't even define it [22:39:32 CEST] <BtbN> unless you need a specific one, no [22:40:17 CEST] <john_doe_jr> BtbN: so this is what I have so far: ffmpeg -re -f avfoundation -vn -i ":0" -acodec -f rtp rtp://192.168.8.143:1234 [22:40:31 CEST] <BtbN> well, you should still specifc your audio codec. [22:40:35 CEST] <BtbN> *y [22:41:56 CEST] <john_doe_jr> BtbN: ok..that was just a copying mistake, this is what I have: ffmpeg -re -f avfoundation -vn -i ":0" -acodec libmp3lame -f rtp rtp://192.168.8.143:1234&is that the best? [22:42:30 CEST] <BtbN> looks ok, acodec isn't up to date anymore though, just use c:a [22:42:45 CEST] <BtbN> but what exactly is the problem you are trying to solve? That command looks like it works? [22:42:47 CEST] <furq> -vn is an output option [22:42:52 CEST] <furq> move it after -i ":0" [22:43:35 CEST] <furq> i also don't think you should be using -re with a capture source [22:43:56 CEST] <petecouture> I had that issue myself BtbN, I've been scratching my head all day and removed -re and now my script works [22:44:17 CEST] <petecouture> Though the documentation on -re is confusing. It says not to use it for live sterams but it should be used for live streaming.... [22:44:28 CEST] <furq> don't use it if your input is a live stream [22:44:34 CEST] <furq> use it if your output is a live stream [22:44:44 CEST] <furq> the first one takes precedence [22:45:08 CEST] <john_doe_jr> furq: so maybe I should output my audio to a file and then live stream that file [22:45:20 CEST] <petecouture> Honestin I just reread what I wrote and realized why I got it wrong [22:45:21 CEST] <furq> ? [22:45:26 CEST] <paule32> 2 video.flv x.y.z HTTP/1.1 WAIT_FEED [22:45:33 CEST] <paule32> what that? [22:45:56 CEST] <petecouture> ? That look slike osme sort of caching script for that file [22:45:56 CEST] <paule32> the browser pops out a dialog - but vlc is not display/started [22:47:27 CEST] <john_doe_jr> This is what I have so far: ffmpeg -re -f avfoundation -vn -i ":0" -acodec libmp3lame -f rtp rtp://192.168.8.143:1234....how do I remove the -acodec and use c:a? [22:47:40 CEST] <furq> you do the thing you just said [22:47:44 CEST] <furq> replace -acodec with -c:a [22:48:12 CEST] <furq> acodec is just the old name for that option [22:48:26 CEST] <john_doe_jr> furq: When I do that I get, "Unable to find a suitable output format for 'rtp'" [22:48:40 CEST] <furq> paste the command [22:48:53 CEST] <john_doe_jr> furq: ffmpeg -re -f avfoundation -i ":0" -vn c:a -f rtp rtp://192.168.8.143:1234 [22:49:03 CEST] <furq> 21:47:44 ( furq) replace -acodec with -c:a [22:49:03 CEST] <petecouture> -c:a libmp3lame [22:49:05 CEST] <furq> do precisely that [22:50:15 CEST] <petecouture> furq: What if the input and output is a live stream. Do you use -re for that? [22:50:20 CEST] <furq> no [22:50:43 CEST] <furq> well, it depends on the type of live stream, but usually no [22:50:55 CEST] <furq> if it encodes at the correct framerate for the output stream then don't use -re, it just complicates everything [22:51:15 CEST] <john_doe_jr> furq: so should I use it? [22:51:24 CEST] <furq> probably not [22:51:37 CEST] <furq> if it starts encoding much too fast then put it back [22:52:11 CEST] <john_doe_jr> furq: so this is the best I can do on the streaming command: ffmpeg -f avfoundation -i ":0" -vn -c:a libmp3lame -f rtp rtp://192.168.8.143:1234 [22:52:20 CEST] <furq> i guess [22:52:37 CEST] <furq> you probably want to specify a bitrate or quality level for mp3 [22:52:42 CEST] <furq> or use a newer codec like aac [22:52:44 CEST] <petecouture> ^ [22:52:57 CEST] <furq> i think libmp3lame defaults to 128k which should be fine [22:56:37 CEST] <john_doe_jr> I'm getting the following error message now: "A description in SDP format is required to receive the RTP stream. Note that rtp://URIs cannot work with dynamic RTP payload format (97)&.any ideas what that means? [23:03:32 CEST] <petecouture> can you paste your sdp [23:03:46 CEST] <petecouture> in a link [23:07:59 CEST] <paule32> ok, i qm happy, all works [23:08:08 CEST] <paule32> great software [23:11:37 CEST] <petecouture> Anyone ever get this error when trying to load a m3u8 in vlc VLC can't recognize the input's format [23:11:46 CEST] <petecouture> It finally plays in iOS [23:11:55 CEST] <petecouture> But it crashes VLC when I try to load it [23:15:49 CEST] <paule32> wrong format that vlc does not support? [23:21:18 CEST] <petecouture> paule32: It's encoded to h264 and aac which is should open. [23:21:36 CEST] <petecouture> this didn't used to work on iOS but I'm using the HLS muxer now and it that seems to have taken care of the problem. [23:22:16 CEST] <petecouture> But now i"m trying to get VLC to open the live stream and no dice. It can play the feed coming from the satalite going through a professional encoding service. I'm trying to match that. [23:29:17 CEST] <sb_> Anyone know if there's a way to configure the build to include all headers in the include path? [23:32:12 CEST] <JEEB> the public ones are always installed unless you disable header installation. the private ones will never be installed because they are not and will not be part of the public APIs and if you use them your stuff can blow up at any point [23:34:23 CEST] <sb_> so JEEB: if I'm looking to set a flag on the private muxer, `av_opt_set_int(outputFormatContext->priv_data, "flag_i_want", 1, 0);` hasn't worked [23:34:44 CEST] <sb_> was hoping to cast to an MOVMuxContext and pack the flag in myself [23:38:58 CEST] <JEEB> ok, so you're like wanting to set a thing for f.ex. the dash muxer's internal mov muxer? [23:41:16 CEST] <sb_> right, so specifically I've added a custom flag in AVOptions in the MOV/MP4 muxer (works using -movflags from the cli), now I want to set that flag programatically using the libavformat [23:42:03 CEST] <JEEB> you want the DASH muxer to set it or you just want to set a flag for movenc itself? [23:42:13 CEST] <sb_> to set one for movenc [23:42:21 CEST] <JEEB> ok, then no private APIs needed there [23:43:32 CEST] <JEEB> as far as I can tell av_dict_set(POINTER, "movflags", "one+two+three", 0); should do it [23:43:57 CEST] <sb_> oh that's interesting [23:44:19 CEST] <JEEB> in a similar way to https://ffmpeg.org/pipermail/libav-user/2013-June/004817.html [23:44:20 CEST] <sb_> would AVFormatContext->priv_data be an AVDictionary in addition to AVOptions? [23:44:54 CEST] <sb_> oh using the second arg in avformat_write_header.. [23:45:00 CEST] <JEEB> pretty sure you don't have to touch the priv_data [23:45:27 CEST] <sb_> I had looked at the source for that and it didn't appear to pass through the options when calling in to the private muxer [23:45:34 CEST] <sb_> thanks, I'll give that a go [23:45:39 CEST] <JEEB> what do you mean with "private muxer" [23:45:59 CEST] <JEEB> if it's a muxer that calls a muxer (like dashenc), it gets funkier [23:47:23 CEST] <sb_> I meant to say the way av_write_header calls through to moveenc [23:47:41 CEST] <sb_> mov_write_header takes a single AVFormatContext arg [23:48:33 CEST] <JEEB> I hope you took a look at the muxing example [23:49:51 CEST] <JEEB> muxing for an API user in general is a more high level thing than looking at the avformat internals [23:51:40 CEST] <sb_> yeah I've already built a muxer [23:52:05 CEST] <sb_> I've got a fork that I'm adding functionality too for an eventual contribution back to core [00:00:00 CEST] --- Wed Apr 6 2016

1 0