Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

July 2017

1 participants
62 discussions

ffmpeg-devel.log.20170730
by burek 31 Jul '17

31 Jul '17

[00:00:13 CEST] <iive> aha, [01:22:38 CEST] <cone-843> ffmpeg 03Jun Zhao 07master:1e0c75ea165c: examples/hw_decode: Add a HWAccel decoding example. [02:32:29 CEST] <atomnuker> jamrial: fixed everything and added sse3 version [02:32:40 CEST] <atomnuker> one problem: changing the alignment to 32 segfaults [02:32:59 CEST] <atomnuker> any ideas why that could happen? [02:33:59 CEST] <jamrial> atomnuker: put sign_adjust_5 at the end [02:36:44 CEST] <atomnuker> jamrial: didn't work [02:38:04 CEST] <jamrial> it should. if the first constant is 16 bytes, whatever comes next will not be 32 byte aligned [02:38:46 CEST] <jamrial> if you put sign_adjust_5 after the three new 32 byte contants, it should be good [02:38:55 CEST] <atomnuker> oh, misread _5 as _r [02:42:54 CEST] <iive> atomnuker: you need a new font for irc [02:48:54 CEST] <atomnuker> jamrial: sent a v2 of the patch to your first reply [03:44:47 CEST] <atomnuker> jamrial: what CPUs does HAVE_AVX2_FAST filter out which have avx2? [04:00:30 CEST] <jamrial> atomnuker: excavator [04:01:29 CEST] <atomnuker> its slower than avx there? [04:02:40 CEST] <jamrial> anything using ymm regs is slow in bulldozer based cpus [04:02:54 CEST] <jamrial> of those, excavator is the only one with avx2 [04:03:52 CEST] <atomnuker> what were amd thinking even flagging avx2 support [04:07:04 CEST] <jamrial> a checkmark in the feature list? then there's broadcast instructions, variable bit shift instructions (even though xop had its own kind as well), vpblendd, all working with xmm regs [04:17:28 CEST] <atomnuker> I'll need to put a big warning on the mdct function which says it underreads and overreads the input [04:18:00 CEST] <atomnuker> aac and opus have the input in a struct with stuff before and after it so it won't segfault [04:18:40 CEST] <atomnuker> its dirty as hell but damn non-power-of-two transforms [04:20:37 CEST] <atomnuker> len8 is mod 4 but not mod 8 [04:40:58 CEST] <atomnuker> jamrial: the SSE3 version can be made to run on 32 bit machines too, since I'm using 8 grps and 8 xmm regs [04:41:05 CEST] <atomnuker> https://pars.ee/temp/0001-mdct15-add-inverse-transform-postrotation-SIMD.pa… [04:41:25 CEST] <atomnuker> do you see any way to save a single grp somewhere somehow? [04:51:37 CEST] <jamrial> atomnuker: you could move len8 back to stack (mov len8m, len8q) before the loop, load the second offset argument, use len8m in cmp, then move it back to a reg right after the loop [04:52:26 CEST] <jamrial> no wait, those offsets are not arguments [04:55:14 CEST] <jamrial> also, you can avoid having two cglobal lines by doing 5, 8, 8 + cpuflag(avx2) * 4 [04:58:41 CEST] <jamrial> atomnuker: maybe just push out/exp/len8 before LUT_LOAD_4D, reuse the reg instead of r7q, then pop it back [04:59:15 CEST] <jamrial> you probably need to use PUSH and POP (x86inc magic) [05:01:28 CEST] <atomnuker> huh, that was easy [05:09:34 CEST] <atomnuker> it does slow things down by around 500 decicycles though [05:15:44 CEST] <atomnuker> I found a better way, I can free up len8q's reg from the loop and push/pop it at the start and end [05:24:41 CEST] <atomnuker> better yet I can omit len8 after init [05:25:10 CEST] <atomnuker> turns out that I don't overwrite the end at all since its mod 8 [05:25:51 CEST] <atomnuker> but because I offset the negative offset by 4 at the start I underwrite the output [06:31:52 CEST] <cone-610> ffmpeg 03Matt Oliver 07master:a3833bee9482: win32_dlfcn: Support WinRT/UWP. [06:31:52 CEST] <cone-610> ffmpeg 03Matt Oliver 07master:6cc677c0e828: lavf/os_support: Use existing WinRT config value. [06:31:52 CEST] <cone-610> ffmpeg 03Matt Oliver 07master:b0c61209cd30: lavc/makefile: Add missing file dependencies. [08:39:38 CEST] <cone-610> ffmpeg 03Rostislav Pehlivanov 07master:70eb77b34e9f: mdct15: add inverse transform postrotation SIMD [08:40:27 CEST] <atomnuker> much cleaner, no crazy alignment requirements, no overreading/underreading, 32 bit sse3 version, 9%!! [08:42:31 CEST] <atomnuker> crazy mdcts: 0, me: 2 [08:43:45 CEST] <atomnuker> only thing not SIMDd is the prereindexing, and the gains would be much lower there and having a forward version would be impossible [10:27:15 CEST] <ubitux> atomnuker: i think you need to declare temp earlier in OVERALLOC() [10:31:48 CEST] <atomnuker> I didn't need to have any OVERALLOC at all [12:37:22 CEST] <cone-563> ffmpeg 03Nicolas George 07master:1daacba91f7c: Revert "Revert "lavfi/buffersrc: push the frame deeper if requested."" [12:37:22 CEST] <cone-563> ffmpeg 03Nicolas George 07master:cffea1b4837b: lavfi: copy framesync into framesync2. [12:37:22 CEST] <cone-563> ffmpeg 03Nicolas George 07master:873306f265de: lavfi/framesync2: rename all conflicting symbols. [12:37:22 CEST] <cone-563> ffmpeg 03Nicolas George 07master:b77f041dff5f: lavfi: make FFERROR_NOT_READY available to filters. [12:37:22 CEST] <cone-563> ffmpeg 03Nicolas George 07master:ed1c884b9e0d: lavfi: add outlink helper functions. [12:37:22 CEST] <cone-563> ffmpeg 03Nicolas George 07master:4e0e9ce2dc67: lavfi/framesync2: implement "activate" design. [12:37:22 CEST] <cone-563> ffmpeg 03Nicolas George 07master:0dd8320e16bc: lavfi/vf_stack: move to "activate" design. [12:37:23 CEST] <cone-563> ffmpeg 03Nicolas George 07master:d07e25de763e: lavfi/vf_threshold: move to "activate" design. [12:37:24 CEST] <cone-563> ffmpeg 03Nicolas George 07master:dbf7a670942d: lavfi/vf_remap: move to "activate" design. [12:37:25 CEST] <cone-563> ffmpeg 03Nicolas George 07master:b894415a703e: lavfi/vf_premultiply: move to "activate" design. [12:37:26 CEST] <cone-563> ffmpeg 03Nicolas George 07master:620608467f26: lavfi/vf_midequalizer: move to "activate" design. [12:37:27 CEST] <cone-563> ffmpeg 03Nicolas George 07master:a5e3b0c1934f: lavfi/vf_maskedmerge: move to "activate" design. [12:37:28 CEST] <cone-563> ffmpeg 03Nicolas George 07master:0bc331bd57dc: lavfi/vf_mergeplanes: move to "activate" design. [12:37:29 CEST] <cone-563> ffmpeg 03Nicolas George 07master:27d8af03ae0d: lavfi/vf_maskedclamp: move to "activate" design. [12:37:30 CEST] <cone-563> ffmpeg 03Nicolas George 07master:dbc4af862e74: lavfi/vf_lut2: move to "activate" design. [12:37:31 CEST] <cone-563> ffmpeg 03Nicolas George 07master:5dbb111900b6: lavfi/vf_hysteresis: move to "activate" design. [12:37:32 CEST] <cone-563> ffmpeg 03Nicolas George 07master:8b2cd8e0e412: lavfi/vf_displace: move to "activate" design. [14:28:33 CEST] <cone-563> ffmpeg 03Marton Balint 07master:e433497160bd: avdevice/decklink_dec: set field order via codecpar [16:09:06 CEST] <cone-563> ffmpeg 03Clément BSsch 07master:ca23d3491d4c: sws/tests/pixdesc_query: save every pix fmts in a list [16:09:07 CEST] <cone-563> ffmpeg 03Clément BSsch 07master:d2c70fc88790: sws/tests/pixdesc_query: sort pixel formats [16:09:08 CEST] <cone-563> ffmpeg 03Clément BSsch 07master:4158fba3cdb7: sws/tests/pixdesc_query: replace rgb based pix fmts with endianess agnostic names [16:10:26 CEST] <cone-563> ffmpeg 03Michael Niedermayer 07release/3.2:66395ac32bfb: Update for 3.2.7 [17:08:40 CEST] <cone-563> ffmpeg 03Clément BSsch 07n3.2.7:HEAD: sws/tests/pixdesc_query: replace rgb based pix fmts with endianess agnostic names [19:32:12 CEST] <rindolf> Hi all! In http://ffmpeg.org/download.html , it reads: « 3.2.7 was released on 2017-07-30. It is the latest stable FFmpeg release from the 3.2.7 release branch, which was cut from master on 2016-10-26. » the second "3.2.7" should be "3.2" [19:33:33 CEST] <rindolf> also, the /topic reads "3.3.2" but there is already "3.3.3" [19:47:39 CEST] <ubitux> durandal_1707: do you have a use case of the filter? [19:48:24 CEST] <durandal_1707> its gimp replacement [19:49:05 CEST] <ubitux> rindolf: topic fixed, web may need a patch [19:49:41 CEST] <rindolf> ubitux: thanks [19:50:05 CEST] <rindolf> ubitux: can i send a pull-request? [19:50:14 CEST] <ubitux> better send a patch to the ml [19:50:23 CEST] <rindolf> ubitux: ok [19:50:36 CEST] <rindolf> ubitux: where are the sources? [19:51:18 CEST] <ubitux> https://git.ffmpeg.org/ffmpeg-web [19:52:11 CEST] <rindolf> ubitux: thanks [19:52:34 CEST] <ubitux> durandal_1707: oh, it's the bucket thing? [19:55:27 CEST] <durandal_1707> ubitux: yeah [19:57:25 CEST] <ubitux> you need a threshold, a (optionally negative) border overlap and alpha fading in the overlap ;) [20:06:40 CEST] <rindolf> ubitux: sent, thanks [20:11:26 CEST] <durandal_170> ubitux: what? [20:46:21 CEST] <ubitux> jamrial: you sent that mail in private [20:46:29 CEST] <ubitux> durandal_170: i'm just enumerating features [20:46:40 CEST] <ubitux> jamrial: that mail htmlsub [20:46:42 CEST] <jamrial> ubitux: ugh, sorry [20:46:49 CEST] <ubitux> no worry :) [20:47:00 CEST] <jamrial> i thought i clicked reply list. stupid thunderbird [20:50:00 CEST] <cone-563> ffmpeg 03Clément BSsch 07master:797c232ef84d: sws/tests/pixdesc_query: fix use of free() instead of av_free() [00:00:00 CEST] --- Mon Jul 31 2017

1 0

ffmpeg.log.20170730
by burek 31 Jul '17

31 Jul '17

[00:53:02 CEST] <ZexaronS> hello [00:56:40 CEST] <ZexaronS> I kinda floated this idea a few times but nothing conclusive (i'm still busy with other projects and chores) the idea of making some kind of algorithm to use good analysis on top of a video or a large volume of images, that would also offer detailed parameters to fine tune, but basically it would create a very good looking smooth timelapse but also at a good storage size, because it would detect movement at pixel level, analysing [00:56:40 CEST] <ZexaronS> over many frames/images, and pick out more images when there is more activity and vice versa using less images when there is lower activity (pixel change, even down to which colors changes how much from this to this frame or from minute 1 to minute 2, patterns, statistics etc taken into account) [00:57:31 CEST] <ZexaronS> But I kinda forgot what or where would be the place to start something like this, would this be some kind of a separate filter that could be integrated into ffmpeg, or something else ? [00:59:04 CEST] <ZexaronS> I have done some research but it's not full proof, since no tools were build specifically for timelapse, the end result video has to be fixed 30 or 60 or whatever fps, that should be completely separate from the above algorithm that picks out the images to use [02:15:30 CEST] <qebafhzn> hey guys, i'm trying to set up a video server to stream a movie for some friends, but ffserver throws up a 503 error whenever i try to feed it video from ffmpeg. my conf is https://pastebin.com/BPqQMKb3. anyone know what i'm doing wrong? [02:39:45 CEST] <yyf> jion [02:53:34 CEST] <ebrock> hi [02:53:58 CEST] <ebrock> trying to set up ffmpeg with rtmp [02:56:47 CEST] <ebrock> error log and stuff: https://p.teknik.io/NRk8e [02:58:29 CEST] <ebrock> the main error: av_interleaved_write_frame(): Connection reset by peer [02:59:44 CEST] <ebrock> any hints on what's going on? [04:56:27 CEST] <klaxa> ebrock: afaik rtmp can't stream mp4 [05:57:17 CEST] <ebrock> hmm [08:00:34 CEST] <ebrock> im back [08:00:40 CEST] <ebrock> also im pretty sure it can [08:04:46 CEST] <ebrock> wait nvm [08:04:49 CEST] <ebrock> lol [09:03:18 CEST] <DaVu> I have a problem with a file I'm trying to convert. Mediainfo of that file: http://paste.ubuntu.com/25203701/ [09:04:21 CEST] <DaVu> and here is the error I get: http://paste.ubuntu.com/25203706/ [09:05:29 CEST] <DaVu> that's the command I use: ffmpeg -y -hwaccel cuvid -c:v h264_cuvid -vsync 0 -i 21_t00.mkv -map 0 -c copy -vcodec hevc_nvenc 21-hevc.mkv [09:05:52 CEST] <DaVu> already found this: https://trac.ffmpeg.org/ticket/6375 [09:06:27 CEST] <DaVu> but adding: '-max_muxing_queue_size 400' only gets me other errors [13:51:15 CEST] <momomo> i was running ffprobe on over night on 1000+ streams [13:51:21 CEST] <momomo> it is behaving a bit strange [13:52:49 CEST] <momomo> last commadn started 07:46 and haven't finished [13:52:52 CEST] <momomo> ffprobe -v verbose -select_streams v:0 -show_format -of json -show_streams -timeout 5000000 http://192.168.0.3:9981/play/stream/service/ad67267e2e99fd7bcd19c0 [13:52:57 CEST] <momomo> the timeout here is 5 seconds [13:53:03 CEST] <momomo> so I don't get what is holding it up [13:53:33 CEST] <JEEB> have you tested that that is the correct timeout parameter? [13:53:50 CEST] <momomo> yes, i think it has worked for other urls before [13:53:53 CEST] <JEEB> ok [13:53:56 CEST] <momomo> it's supposed to be in microseconds [13:54:06 CEST] <JEEB> yea, that's the default timebase for many option [13:54:08 CEST] <JEEB> *options [13:54:29 CEST] <JEEB> in that case it might not be a connection timeout thing [13:54:34 CEST] <JEEB> but rather something else [13:55:03 CEST] <momomo> I am trying something here [13:55:07 CEST] <JEEB> (I think the timeout option only gets gets handled by the IO side of things, although it depends on the protocol) [13:55:15 CEST] <momomo> if I decrease the timeout to 5000 then it times out [13:55:21 CEST] <momomo> for that particular url [13:55:30 CEST] <momomo> but when I put it at 5000 000 then it doesnt [13:56:06 CEST] <JEEB> you'd have to debug at what stage it gets stuck [13:56:16 CEST] <JEEB> because it seems like it can definitely get a connection [13:56:38 CEST] <momomo> yes, i am not getting a very verbose output either ... maybe try trace [13:56:39 CEST] <JEEB> you can add verbosity to debug and put stderr (2>) into a file [13:57:04 CEST] <JEEB> afterwards also running ffprobe under something like strace can be very useful [13:57:26 CEST] <momomo> output kind of keeps repeating this kind of message: https://hastebin.com/kunevepuva.go [13:57:51 CEST] <JEEB> yea, so it's getting mpegts from the input [13:58:05 CEST] <JEEB> it even gets a program from one of the PMTs [13:58:12 CEST] <momomo> looks like a debug of somekind where it ends up in a while loop and never able to get out to check if timeout has elapsed [13:58:33 CEST] <momomo> i guess an while ( && timeoutHasNotElapsed() ) needs to be added someplace [13:58:41 CEST] <momomo> fcuk [13:58:47 CEST] <JEEB> the timeout is for IO and you have no issues with IO [13:59:04 CEST] <momomo> JEEB: but I want a global timeout, is that possible? [13:59:11 CEST] <JEEB> there's options starting with probe or analyze (and ending with duration/whatever) [13:59:23 CEST] <JEEB> you might be able to figure things out with that [13:59:28 CEST] <JEEB> *those [13:59:45 CEST] <JEEB> momomo: I don't think there's a global timeout, usually the thing that started the process knows that the best [14:00:07 CEST] <momomo> JEEB: yes, I guess. I'll look into adding a timeout kill switch [14:00:18 CEST] <JEEB> anyways, what it looks like is that the stream is there and IO layer is a-OK [14:00:25 CEST] <JEEB> but ffprobe is trying to find the streams [14:00:29 CEST] <JEEB> from the mpeg-ts [14:00:35 CEST] <JEEB> while the stream is only giving out metadata [14:00:40 CEST] <momomo> yes, let me try play it in vlc [14:00:44 CEST] <JEEB> so it keeps reading and reading [14:01:23 CEST] <JEEB> vlc -vvv -Idummy -Adummy -Vdummy -Sdummy URL [14:01:27 CEST] <JEEB> is a good way usually [14:01:30 CEST] <momomo> vlc not playing it seems [14:01:38 CEST] <JEEB> that outputs you stuff in the terminal as well [14:01:43 CEST] <momomo> oh nice... is that real argumetns? [14:01:45 CEST] <momomo> haha [14:01:47 CEST] <JEEB> like "received PMT" [14:02:03 CEST] <JEEB> and yes, it's very likely that the stream is a minimal viable MPEG-TS :P [14:02:18 CEST] <JEEB> so it only has metadata of the program (PMT is program mapping table) [14:02:21 CEST] <momomo> vlc command: 00007fd970c140c8] ts demux debug: * event id=32 start_time:1501430400 duration=21600 running=1 free_ca=1 [14:02:21 CEST] <momomo> [00007fd970c140c8] ts demux debug: - short event lang=ita 'Shopping Tv 1' : '(null)' [14:02:21 CEST] <momomo> [00007fd970c140c8] ts demux debug: - extended event lang=ita [0/0] [14:02:21 CEST] <momomo> [00007fd970c140c8] ts demux debug: - text='Shopping Tv' [14:02:21 CEST] <momomo> [00007fd970c140c8] ts demux debug: - tag=0x5f(95) [14:02:23 CEST] <momomo> [00007fd970c140c8] ts demux debug: - tag=0x54(84) [14:02:25 CEST] <momomo> [00007fd970c140c8] ts demux debug: - tag=0xcc(204) [14:02:29 CEST] <momomo> [00007fd96c005ca8] core input debug: EsOutProgramEpg: number=14558 name=Shopping Tv [Program 14558] [14:02:31 CEST] <momomo> [00000000008bd328] dbus interface debug: Getting property Position [14:02:37 CEST] Last message repeated 2 time(s). [14:02:37 CEST] <momomo> getting repeated the last messages [14:02:40 CEST] <momomo> getting property position [14:02:53 CEST] <momomo> i guess this is not a valid stream, so i will just put my own timeout and nix it [14:02:54 CEST] <JEEB> yea, don't paste long pieces of text on teh channel in the future, please :) [14:03:14 CEST] <momomo> JEEB: i know, but I think we are the only ones here now :p [14:03:17 CEST] <JEEB> well the stream might be valid but for something that wants actual video/audio/subtitle streams [14:03:20 CEST] <DHE> doesn't matter [14:03:23 CEST] <momomo> hehe [14:03:42 CEST] <JEEB> I guess the analyze/probe parameters might help you there [14:03:46 CEST] <momomo> DHE: may I debate this issue? the actual logic / rationale behind that rule? [14:03:50 CEST] <JEEB> "give up if you couldn't find the streams after X" [14:04:15 CEST] <JEEB> if your paste doesn't fit into a single line or so you use a secondary channel of providing that :P [14:04:18 CEST] <momomo> If there are no competing discussions, and there are no posts coming in between, what would be the harm of pasting a few lines to speed up sharing? [14:04:58 CEST] <DHE> what you don't see is that your IRC client is intentionally rate-limiting your messages, roughly 2 seconds per line. [14:05:09 CEST] <momomo> JEEB: i know the rules, but they just don't always make sense. much like swedish rules about not using the washing room on sundays and after 16.00 on saturdays ... whyyyyyy, that's when I have time. not on weekdays [14:05:19 CEST] <DHE> IRC servers will kick you off with the message "Excess flood" for large or rapid floods, which is why your clients throttles itself [14:05:26 CEST] <JEEB> momomo: try -analyzeduration and -probesize [14:05:31 CEST] <JEEB> first one is in the usual time based [14:05:36 CEST] <JEEB> and the second is in bytes I think? [14:06:02 CEST] <momomo> DHE: thanks for the explanation [14:06:29 CEST] <momomo> the swedish socialist enforcement of work, don't wash your clothes on sundays are still fcuked up though! [14:06:29 CEST] <momomo> haha [14:06:34 CEST] <momomo> communism [14:07:25 CEST] <momomo> JEEB: I just tried: [14:07:26 CEST] <momomo> ffprobe -v trace -select_streams v:0 -show_format -of json -show_streams -timeout 5000000 -analyzeduration 1000 -probesize 1000 http://192.168.0.3:9981/play/stream/service/ad67267e2e99fd7bcd19c01330fe70a3 [14:07:35 CEST] <momomo> are those values integeres ? [14:07:39 CEST] <JEEB> yes [14:07:42 CEST] <momomo> did not help stop the stream though [14:07:52 CEST] <momomo> let me try lower to 1 [14:08:11 CEST] <DHE> http://bash.org/?7936 Hence jokes like this :) [14:08:41 CEST] <JEEB> anyways, seems like lavf really doesn't like mpegts without any actual streams connected to the program :P [14:09:06 CEST] <JEEB> still sounds like a boog [14:09:23 CEST] <JEEB> since it should give up trying to get the streams [14:09:24 CEST] <momomo> I guess i will have to start a separate thread/process that manages the time for this one [14:09:31 CEST] <momomo> or maybe just install nix [14:10:31 CEST] <JEEB> if I ever get free time I should probably try and generate that kind of sample. (which I most likely won't have the time to do) [14:10:47 CEST] <momomo> JEEB: I can give you access to that stream if you want [14:10:48 CEST] <JEEB> just keep pushing out PMTs and PATs [14:11:14 CEST] <JEEB> momomo: coolio. would be enough to dump like a few megs of it [14:11:36 CEST] <JEEB> so you don't really have to give access to the live stream but even a byte dump of the data would be enough (something.ts) [14:12:03 CEST] <momomo> ook, i'll generate some now [14:20:35 CEST] <momomo> JEEB: seems ffmpeg also gets stuck in the same way [14:20:37 CEST] <momomo> no output [14:20:39 CEST] <JEEB> yea [14:20:46 CEST] <JEEB> I mean, they both use libavformat in the basement [14:20:48 CEST] <momomo> ffmpeg -v trace -reconnect 1 -reconnect_at_eof 1 -reconnect_streamed 1 -reconnect_delay_max 3000 -i http://192.168.0.3:9981/play/stream/service/ad67267e2e99fd7bcd19c01330fe70a3 -map 0:a:0 -map 0:v:0 -preset veryfast -c:v libx264 -sn /momomo/Generated/Tv/streams/FFProbe.video [14:20:55 CEST] <JEEB> and if libavformat has a problem [14:21:26 CEST] <momomo> yes, I guess this is not good for ffmpeg either because you'd need a timeout there too [14:21:34 CEST] <JEEB> also I recommend using something like curl for the dumping of the input :P (or if you really want, you can use vlc's demux=dump demuxdump-file=blah.ts [14:21:46 CEST] <momomo> otherwise it will get stuck forever [14:21:49 CEST] <momomo> and take a mux for nothing [14:22:57 CEST] <momomo> JEEB: hit me up on email if you ever need access to stream .. let me take note of the name incase url changes [14:23:03 CEST] <momomo> want my email? [14:24:29 CEST] <JEEB> not really :D anyways, if you can share a sample where the same happens after you dump the stream into a file, that'd be lovely. then you don't have to provide access to the actual stream, as I noted [14:24:52 CEST] <JEEB> and since the sample has no video/audio/subtitle tracks in the stream, it should be OK to share :P [14:25:32 CEST] <Blubberbub_> could one just use wget to get that sample? [14:27:35 CEST] <JEEB> or curl [14:27:42 CEST] <momomo> JEEB: output to stream or video to stream? [14:27:52 CEST] <momomo> video to stream wasn't possible [14:27:54 CEST] <JEEB> momomo: you take your source HTTP url, and dump data from it [14:28:00 CEST] <JEEB> as-is, no processing [14:28:04 CEST] <momomo> ook [14:28:07 CEST] <JEEB> wget,curl,whatever [14:28:08 CEST] <momomo> wget ? [14:28:23 CEST] <JEEB> as long as you can just stop the GET at some point and then check the sample that's fine [14:28:49 CEST] <JEEB> the file extension for MPEG-TS is .ts [14:29:00 CEST] <momomo> JEEB: I am running this now: wget http://192.168.0.3:9981/play/stream/service/ad67267e2e99fd7bcd19c01330fe70a3 ffprobe.wget.error [14:29:01 CEST] <JEEB> (which the data is) [14:29:58 CEST] <momomo> hmm.. when aborted i get nothing .. i think it's stored temporarily someplace else [14:30:09 CEST] <JEEB> that's why I like curl :P [14:30:15 CEST] <JEEB> curl "URL" > file.ts [14:30:23 CEST] <JEEB> then you can just abort it with ctrl+C [14:30:38 CEST] <momomo> hell yeah [14:30:46 CEST] <momomo> i am a convert [14:31:01 CEST] <JEEB> if the URL contains a file name then you usually want `curl -LO "URL"` [14:31:03 CEST] <momomo> upload online? [14:31:06 CEST] <JEEB> in this case it doesn't [14:31:16 CEST] <JEEB> can you check first if the issue happens with the file as well? [14:31:44 CEST] <JEEB> I have a hunch it might have to do with no EOF/slow reading [14:32:23 CEST] <JEEB> so it might not happen with a static file. but yea, after there's a sample it can be poink'd [14:39:33 CEST] <momomo> I get a different output on the file [14:39:36 CEST] <momomo> I ran this: [14:39:38 CEST] <momomo> ffprobe -v trace -select_streams v:0 -show_format -of json -show_streams -timeout 30000000 /momomo/ffprobe.wget.error [14:39:48 CEST] <momomo> maybe i need to change something for a local file? [14:40:10 CEST] <momomo> i guess it has to be served slowly otherwise it will finish fast [14:40:16 CEST] <JEEB> yea [14:40:18 CEST] <momomo> here is the file anyway [14:40:18 CEST] <momomo> https://ufile.io/d18qm [14:40:28 CEST] <JEEB> I guess you could loop the file or something [14:40:42 CEST] <momomo> JEEB: this is a real problem within ffmpeg [14:40:49 CEST] <momomo> since you can not timeout a ffmpeg conneciton [14:40:58 CEST] <momomo> since it continues to run for a long time [14:41:18 CEST] <momomo> only way is try to parse some error messages and wait for some output that determines its ok [14:41:47 CEST] <JEEB> that's why in the end using the APIs is the only real thing to left to do [14:41:56 CEST] <momomo> do you know what is the best way to commuinicate about the state of ffmpeg? [14:42:14 CEST] <JEEB> using the API, unfortunately (since it seems like you're trying to avoid making your own API client) [14:42:16 CEST] <momomo> JEEB: that looked timeconsuming on a tight deadline. I guess the second best thing is parse the output ? [14:42:34 CEST] <JEEB> that's a shitty thing and will break as soon as the command line output changes :P [14:42:53 CEST] <JEEB> there's some stuf that you can send commands from tty or so [14:43:00 CEST] <JEEB> but I've never seen that myself [14:43:35 CEST] <JEEB> oh, the program actually contains streams but they don't get any packets? [14:43:38 CEST] <momomo> JEEB: yes, i know, but that is it? couldn't ffmpeg just keep a file with a state that one can read...or get an status stream where ffmpeg could write data by making http kind like requests with status ? [14:43:43 CEST] Action: JEEB just finally got to checking out the sample [14:45:15 CEST] <JEEB> momomo: I would agree that some mechanism of getting the state would be nice, but the workload of that would be very similar to hooking such a thing to your API client since ffmpeg.c is also an API client [14:45:26 CEST] <momomo> like a flag: ffmpeg - .... -communicate http://path/to/my/recieving/url -onevent [status, bitrate, ... ] ... then ffmpeg could make requests there as these things happen [14:46:33 CEST] <momomo> JEEB: sound like a mix of that and the ffmpeg api might be a solution ... to write an ffmpeg libav addon that can push things onto a url/file [14:48:33 CEST] <JEEB> well the thing would be 100% a client thing rather than a libav* thing [14:48:44 CEST] <JEEB> since the client knows its state and when it last received a packet from input etc [14:49:05 CEST] <JEEB> so in that sense it shouldn't touch the underlying libraries at all [14:50:12 CEST] <momomo> yes that would be great, along with a nice way to hook into that [14:50:34 CEST] <momomo> rest based would be ideal .. and very simple for users to get access to [14:50:49 CEST] <momomo> no need to dive into writing complex libav code :) [14:50:59 CEST] <momomo> although i'd like to learn that as well. [14:51:01 CEST] <JEEB> you can almost forget about any HTTP stuff. it's theoretically possible but something like a state file would most likely be much more possible [14:51:10 CEST] <JEEB> in the end libav* isn't that complex [14:51:15 CEST] <momomo> JEEB: but that would be overwritten [14:51:30 CEST] <JEEB> well your state-checking thing would request it [14:51:37 CEST] <JEEB> say it's a tty command [14:51:42 CEST] <JEEB> write-state /path/to/file [14:51:56 CEST] <JEEB> then when that returns it goes to look for the newly written state [14:52:04 CEST] <momomo> you replace the file? maybe i won't be quick enough to caputre last message [14:52:05 CEST] <JEEB> or heck, you could even output it there [14:52:14 CEST] <JEEB> as in, return it from that command [14:52:22 CEST] <momomo> i guess that's possible though [14:52:25 CEST] <JEEB> although not sure how :P [14:52:43 CEST] <momomo> i think the output is already clogged up with messages [14:52:49 CEST] <momomo> from the log [14:53:04 CEST] <JEEB> also libav* coding is not that hard really. requires some trial and error but that's the case with everything [14:53:28 CEST] <JEEB> Í mostly develop inside the libav* libs but I've done an API client now three times I think [14:53:35 CEST] <DHE> can confirm. made my own app with it and it was actually pretty nice to work with [14:53:47 CEST] <momomo> JEEB: yes sure, but there is a slight uphill battle .. more so than readin a file .. it would be nice if ffmpeg eventually evolved on that wrong [14:53:49 CEST] <momomo> front [14:54:06 CEST] <momomo> DHE: opensource? care to share? [14:54:07 CEST] <JEEB> ffmpeg.c is already a mutant doing way too many things and having workarounds that actually end up breaking your shit [14:54:23 CEST] <DHE> sorry, it's a company application [14:54:25 CEST] <JEEB> which is why as soon as you get past the very basic "can the FFmpeg libs do this" [14:54:37 CEST] <JEEB> you should start thinking if it's a good idea to make your own API client [14:54:54 CEST] <JEEB> my initial API client is https://github.com/jeeb/matroska_thumbnails/blob/master/src/matroska_thumbn… [14:54:56 CEST] <momomo> is the base class ffmpeg.c ? [14:55:07 CEST] <JEEB> no, ffmpeg.c is the command line API client [14:55:11 CEST] <JEEB> (and related files) [14:55:24 CEST] <JEEB> this thing is from 2013, though [14:55:30 CEST] <JEEB> (the matroska thumbnailer thing) [14:55:41 CEST] <JEEB> and it was literally my babby's first API client [14:55:41 CEST] <JEEB> :D [14:56:04 CEST] <momomo> matroska sounds russian :) [14:56:30 CEST] <Blubberbub_> mkv = matroska? [14:56:33 CEST] <JEEB> yes [14:56:44 CEST] <JEEB> specifically typo'd so it's not the shirt [14:56:51 CEST] <momomo> only experience i have with c code was from a class in university ... that was 10 years ago ... i got an A+ though! haha [14:56:56 CEST] <JEEB> or wait no, the doll :P [14:57:02 CEST] <momomo> i will look into it though [14:57:12 CEST] <JEEB> yea, I recommend. the examples under docs can get you surprisingly far [14:57:35 CEST] <JEEB> esp. the ones that use the newer decoding/encoding APIs [14:57:52 CEST] <momomo> I'd be up for a github fork collaboration thing to develop some api for getting info on various things [14:57:54 CEST] <JEEB> you notice those because they have separate push (?) and receive [14:58:01 CEST] <momomo> without coding c code [14:58:34 CEST] <JEEB> well the status is a thing for your app, which is on top of the libs. so it's rather specific to your use case [14:58:44 CEST] <JEEB> as app I mean the API client [14:59:54 CEST] <JEEB> also while I do completely agree that getting the state of ffmpeg.c would be nice, I have a feeling that it would make people use ffmpeg.c even more. which I'm mostly scared of because it's such a monster and of limited design. [15:00:10 CEST] <JEEB> I mean, lavf can do dynamic stream selection but ffmpeg.c doesn't [15:00:48 CEST] <JEEB> albeit the way you do that stuff is suboptimal because you have to check the stream ID on each AVPacket read [15:16:14 CEST] <guysoft42> hey all, I am compiling ffmpeg for raspberrypi and i all seems well. I was wondering - is there a way to make the make-install take less space? Anything I can remove? [15:17:19 CEST] <mnr200> how do access streamed video from web browser [15:40:40 CEST] <MaSTeR|2> Hello everyone! I have a little question about hardware accelerated video decoding. Is there someone that can help me? [15:43:51 CEST] <JEEB> just ask your question and stay around and maybe someone will reply [15:47:17 CEST] <MaSTeR|2> okie. So I wanted to know why av_hwdevice_ctx_create for AV_HWDEVICE_TYPE_D3D11VA returns always error -12. I'm getting the same with av_hwdevice_ctx_alloc and I know that this means ENOMEM but I can't understand why it keeps saying that there's no enough memory when any other hardware device types is working normally [15:51:32 CEST] <jkqxz> MaSTeR|2: Does your build actually contain D3D11VA device support? [15:52:23 CEST] <MaSTeR|2> Yes, I think so, we made our build using --enable-d3d11va [15:52:46 CEST] <jkqxz> It looks like you get ENOMEM for that case because it tries to allocate the context for it and fails because it isn't there. I guess that's rather a misleading error code. [15:53:11 CEST] <jkqxz> What does "ffmpeg -init_hw_device list" show? [15:53:48 CEST] <MaSTeR|2> let me check [15:54:09 CEST] <jkqxz> The device support for it was only added quite recently, though the hwaccels have been around for a while (with user-supplied context). [15:56:10 CEST] <MaSTeR|2> I can see d3d11va in supported hardware device types [15:56:16 CEST] <MaSTeR|2> also --enable-d3d11va [15:57:05 CEST] <jkqxz> Odd. I can't see any other way for that to return ENOMEM. [15:58:33 CEST] <jkqxz> If you call av_hwdevice_iterate_types() from your program it can iterate over the supported device types and make sure D3D11VA is there, I guess. [15:59:32 CEST] <MaSTeR|2> That's weird but I just downloaded ready binaries and everything is fine now [16:00:15 CEST] <MaSTeR|2> Thanks for your help :) I can't even imagine that problem was on the libraries side [16:08:45 CEST] <MaSTeR|2> oh, and also. Should this work with gpl disabled? or that's only for GPL version of ffmpeg? [16:09:30 CEST] <jkqxz> Should be fine. I don't think there is anything around hardware stuff which needs GPL code. [20:13:21 CEST] <lucifer333> yo [20:13:39 CEST] <lucifer333> i have a directory full of *wav files, how do i conver them to *webm? [20:30:57 CEST] <dystopia_> https://trac.ffmpeg.org/wiki/Encode/VP8 [20:33:03 CEST] <lucifer333> thats not really helpfull [20:33:06 CEST] <lucifer333> wav to webm [20:33:33 CEST] <lucifer333> I can google the docs, i dont have the time to look up every fucking option [20:33:50 CEST] <lucifer333> and synthesise wav-> webm [20:34:01 CEST] <lucifer333> the link has only examples mp4-> webm [20:34:03 CEST] <lucifer333> ok? [20:39:25 CEST] <DHE> Opus? or what codec did you have in mind? [20:40:30 CEST] <kepstin> lucifer333: you're basically gonna have to write a shell or batch script that runs "ffmpeg -i file.wav file.webm" in a loop over each file, and add additional ffmpeg options to taste based on preferred codec & quality. [20:40:55 CEST] <lucifer333> yeah, uuh, just the one liner for ffmpeg, i know how to use find [20:41:07 CEST] <lucifer333> i am here for ffmpeg not basic bash scripting [20:41:44 CEST] <lucifer333> how do i use ffmpeg to convert wav to webm [20:41:47 CEST] <DHE> something like: ffmpeg -i input.wav -c opus -b 128k output.webm # adjust the codec and audio bitrate to meet your preferences [20:41:55 CEST] <lucifer333> nice [20:41:57 CEST] <kepstin> lucifer333: I gave you the command in that message [20:42:05 CEST] <dystopia_> lucifer333 [20:42:06 CEST] <DHE> try it with one file first, make sure the quality is to your liking. wav is uncompressed (usually) [20:42:12 CEST] <lucifer333> lets wrap that in a "find" [20:42:13 CEST] <dystopia_> ren *.wav *.webm [20:42:20 CEST] <lucifer333> yeah [20:42:28 CEST] <lucifer333> will test it on one file [20:49:06 CEST] <lucifer333> oh one thing [20:49:10 CEST] <lucifer333> it will be used for web [20:49:11 CEST] <lucifer333> html [20:49:19 CEST] <lucifer333> so opus is correct codec for this? [20:50:59 CEST] <lucifer333> it says opus is experimental [20:51:01 CEST] <lucifer333> waaaat? [21:03:46 CEST] <ebrock> im back [21:03:55 CEST] <ebrock> i checked the rtmp spec and mp4 should work [21:04:11 CEST] <ebrock> is there anywhere i should post the error logs? [21:04:34 CEST] <ebrock> also should i post my nginx config? (im using nginx compiled with rtmp support) [21:04:53 CEST] <ebrock> i nmapped it and the port seems to be open so idk [21:08:32 CEST] <ebrock> ebrock | error log and stuff: https://p.teknik.io/NRk8e [21:08:39 CEST] <ebrock> ebrock | the main error: av_interleaved_write_frame(): Connection reset by peer [21:08:44 CEST] <ebrock> what i posted before [21:08:59 CEST] <lucifer333> thank you everybody; kepstin , dystopia_ etc, i convered all ogg, wav, etc to webm [21:09:09 CEST] <lucifer333> it seems to be the media standerd for browsers [21:09:11 CEST] <lucifer333> donno [21:09:46 CEST] <kepstin> well, if your source was .ogg, you should probably use "-c copy" to avoid a lossy re-encode [21:10:06 CEST] <kepstin> probably aac in mp4 is more browser compatible overall [21:11:31 CEST] <DHE> donno? [21:24:46 CEST] <kerio> 128kbps aac is perceptually lossless, right? [21:26:28 CEST] <TD-Linux> lucifer333, you want to use -c:a libopus, not opus [21:27:41 CEST] <kepstin> kerio: depends on the encoder used [21:27:47 CEST] <kerio> itunes [21:27:58 CEST] <kepstin> kerio: for example, libvo_aacenc is never perceptually lossless at any bitrate [21:27:59 CEST] <kerio> so quicktime i guess [21:28:16 CEST] <kepstin> itunes is one of the best yeah, 128kbit there should be pretty good [21:40:40 CEST] <furq> http://listening-test.coresv.net/s/scores_by_tracks_en.png [21:41:09 CEST] <furq> i'd expect that to be a solid 5 at 128k [21:41:40 CEST] <furq> i normally use fdk -vbr 5 when i need aac [23:35:01 CEST] <paul_> hi [23:35:16 CEST] <paul_> Hi, is there someone here who can help me build ffmpeg in the architecture sh4 [23:35:43 CEST] <JEEB> shouldn't be any different from any other cross-compilation [23:35:55 CEST] <JEEB> http://fate.ffmpeg.org/ [23:35:59 CEST] <JEEB> see some examples here [23:36:31 CEST] <JEEB> there's some arm stuff there at least [23:36:54 CEST] <JEEB> also ppc64 [23:37:38 CEST] <paul_> Can i compile ffmpeg on linux on a laptop under sh4 architecture? I have ubuntu [23:37:52 CEST] <paul_> a moze jest tu jakies polak ? [23:38:22 CEST] <JEEB> i don't know if it will actually build since I'm pretty sure sh4 isn't exactly a well-tested architecture [23:38:53 CEST] <atomnuker> holy shit someone's compiling for sh4 [23:39:02 CEST] <paul_> I :) [23:39:17 CEST] <atomnuker> awesome, I've always wanted an sh4 processor to play around with [23:39:44 CEST] <atomnuker> we had some sh4 asm code many years ago but it was very little and was removed [23:39:46 CEST] <paul_> Wants to play .webm files on ffmpeg and must be libvpx [23:39:46 CEST] <JEEB> but the parameters would be --arch=XX --cpu=XX --cross-prefix=your-triplet-prefix- [23:39:58 CEST] <JEEB> for cross-compilation [23:40:08 CEST] <JEEB> probably not needed for native sh4 building [23:40:21 CEST] <atomnuker> paul_: you don't need libvpx to play vp8/vp9 files, we have native decoders [23:40:59 CEST] <paul_> Can you explain? [23:41:09 CEST] <JEEB> vp8 and vp9 have internal decoders within libavcodec [23:41:13 CEST] <JEEB> which is an FFmpeg library [23:41:27 CEST] <JEEB> (you can also use libvpx which has a wrapper in libavcodec separately) [23:42:05 CEST] <paul_> I can show you what I currently have ffmpeg [23:44:19 CEST] <paul_> http://pastebin.ca/3849168 [23:44:59 CEST] <paul_> You can check whether I have ffmpeg can see .webm? [23:46:01 CEST] <JEEB> ffmpeg -formats |grep webm , ffmpeg -decoders |grep vp [23:47:11 CEST] <atomnuker> paul_: you don't have --enable-decoder=vp8 and --enable-decoder=vp9 [23:47:26 CEST] <JEEB> yea, if it's an "all disabled" build [23:47:31 CEST] <JEEB> then you need to specifically enable them [23:47:32 CEST] <atomnuker> and --enable-demuxer=mkv [23:47:49 CEST] <JEEB> yup [23:47:52 CEST] <atomnuker> yeah, just use ccache and enable everything [23:48:24 CEST] <paul_> But it has to be compiled first, right? [23:48:33 CEST] <JEEB> yes [23:48:53 CEST] <JEEB> --enable-cross-compile --cross-prefix=sh4-linux- --target-os=linux --arch=sh4 [23:48:57 CEST] <JEEB> seem to be the primary parameters [23:49:01 CEST] <paul_> With these settings? --enable -libvpx [23:49:04 CEST] <JEEB> no [23:49:10 CEST] <JEEB> just don't use disable-everything [23:49:14 CEST] <JEEB> start with a base build [23:49:28 CEST] <JEEB> don't add any parameters, just set the cross compilation parameters [23:49:45 CEST] <JEEB> you can optimize build times after you get used to things [23:50:12 CEST] <paul_> Is there a tutorial on the internet? Step by step [23:50:21 CEST] <JEEB> you get your cross compiler [23:50:24 CEST] <JEEB> add it to PATH [23:50:30 CEST] <JEEB> and literally those three parameters I just noted [23:50:42 CEST] <JEEB> which i got from your build's configuration output [23:51:03 CEST] <JEEB> or if you want to be insane and build on the laptop I don't think you need any parameters? [23:51:14 CEST] <JEEB> just mkdir -p build && cd build && ../configure [23:52:34 CEST] <paul_> jeeb Would you do this to me by teamviewer? [23:52:44 CEST] <JEEB> pfft [23:52:56 CEST] <JEEB> maybe atomnuker if he cares about access to your box [23:53:55 CEST] <paul_> detriment [23:54:58 CEST] <atomnuker> i'm not the most appropriate person having cross compiled exactly 0 things in my life [23:55:32 CEST] <paul_> me too [23:55:34 CEST] <paul_> :) [23:57:33 CEST] <atomnuker> just compile ffmpeg on the box and go grab a beer and wait for a few hours [23:57:52 CEST] <JEEB> yea [23:59:05 CEST] <paul_> on the box ? Rather not because it's just a satellite decoder. I ffmpeg I wanted to compile on a laptop with ubuntu. [23:59:48 CEST] <JEEB> well, if you have the STM cross-compiler then at least you could get to it :P [00:00:00 CEST] --- Mon Jul 31 2017

1 0

ffmpeg-devel.log.20170729
by burek 30 Jul '17

30 Jul '17

[00:58:43 CEST] <atomnuker> is there a short and easy way of swapping the high 64 bits of each lane in a 256bit reg? [00:59:16 CEST] <kierank> pshubf? [00:59:26 CEST] <atomnuker> it does crosslane? [00:59:36 CEST] <kierank> ah crosslane i dunno [01:00:43 CEST] <atomnuker> so 0-64 and 128-192 stay as-is but 64-128 and 192-256 get swapped [01:01:32 CEST] <atomnuker> I got 4 registers I need to haddps and 2 of them are in reverse of what they need to be [01:02:57 CEST] <atomnuker> (and I'd rather avoid doing 4 haddps on each register when 2 gets them almost right) [01:15:34 CEST] <iive> atomnuker: check "vpermps", it's avx2 [01:16:24 CEST] <iive> 3 latency and 1 throughput [01:17:40 CEST] <atomnuker> doesn't seem too bad [01:17:51 CEST] <JEEB> hmm, where was the service_name stuff defined for MPEG-TS? [01:17:52 CEST] <atomnuker> my code's already using some avx2 unnecessarily [01:24:49 CEST] <iive> atomnuker: what are you working on? [01:27:29 CEST] <atomnuker> mdct15 postrotate and (un)folding [01:27:51 CEST] <atomnuker> though really I just want to see how slow vgather is [01:29:20 CEST] <iive> :D [02:39:58 CEST] <kierank> atomnuker: any idea why you do this in vc2enc_dwt? [02:39:59 CEST] <kierank> s->buffer = av_malloc(2*p_width*p_height*sizeof(dwtcoef)); [02:40:02 CEST] <kierank> 2*? [02:44:12 CEST] <atomnuker> not a clue, can't remember [02:47:05 CEST] <kierank> looks very unnecessary [02:49:56 CEST] <atomnuker> yep, it does [03:17:59 CEST] <atomnuker> huh, haddps interleaved the coefficients but the chinese graphs I look on google images every time I need to visualize say it doesn't [03:18:46 CEST] <atomnuker> how come these chinese graphs (http://www.officedaytime.com/tips/simdimg/punpckhwd.png) are the only good graphs anyone has made [03:37:18 CEST] <J_Darnley> I remember some like that from the intel manual but I think many of the new instructions miss them. [04:37:51 CEST] <atomnuker> vpermps is awesome, it does cross lane stuff [04:49:48 CEST] <cone-829> ffmpeg 03Kaustubh Raste 07master:36ea41de3736: libavcodec/mips: Improve avc dequant-idct luma dc msa function [04:49:48 CEST] <cone-829> ffmpeg 03Michael Niedermayer 07master:08c073434e25: avformat/rtmppkt: Convert ff_amf_tag_size() to bytestream2 [04:49:48 CEST] <cone-829> ffmpeg 03Michael Niedermayer 07master:ffcc82219cef: avformat/rtmppkt: Convert ff_amf_get_field_value() to bytestream2 [04:49:48 CEST] <cone-829> ffmpeg 03Michael Niedermayer 07master:2c630d159ffe: avcodec/takdec: Fix integer overflow in decode_subframe() [04:49:48 CEST] <cone-829> ffmpeg 03Michael Niedermayer 07master:c0220c768c7f: avcodec/diracdec: Fix integer overflow in divide3() [06:51:03 CEST] <atomnuker> things were going so great, I wrote some nice asm and it barely took me a few hours and now it turns out that I can't overwrite my output [06:52:57 CEST] <atomnuker> and all this could have been avoided if the voip megasperglords fixed their crap to work with a non-integer amount of frames per second [06:54:07 CEST] <atomnuker> I think you need to do some effort to even make your crap _not_ work with a non-interger amount of frames per second [08:00:30 CEST] <atomnuker> ah well, bodged it to save and restore the area +-mmsize around the output [08:03:57 CEST] <atomnuker> holy fucking shit, 2 vgathers of 4 doubles cost me around 2700 decicycles [08:04:33 CEST] <atomnuker> without them the function is 1200 decicycles [09:50:29 CEST] <durandal_1707> atomnuker: whats missing in your audio denoiser filter? [09:53:02 CEST] <atomnuker> the actual business part (detection and subtraction) [09:53:25 CEST] <atomnuker> plus jmspeex posted a very good noise reduction filter based on neural nets [09:54:27 CEST] <atomnuker> https://jmvalin.ca/misc_stuff/noisy.wav vs https://jmvalin.ca/misc_stuff/denoised1.wav [09:56:05 CEST] <atomnuker> he's training it with various types of noises atm so might be a better idea to borrow it instead [09:56:48 CEST] <Blubberbub_> atomnuker, is there a text about how its done? [09:57:13 CEST] <atomnuker> nope, its neural nets so its magic [09:58:22 CEST] <Blubberbub_> but what are the inputs to the network? layout of the network? how is it trained? [09:59:40 CEST] <atomnuker> not a clue, ask jmspeex in #opus [10:02:47 CEST] <Gramner> >(@atomnuker) is there a short and easy way of swapping the high 64 bits of each lane in a 256bit reg? [10:02:53 CEST] <Gramner> vpermq for int, vpermpd for float [10:03:28 CEST] <Gramner> takes an imm8, so no need for .rodata shuffle masks [10:05:34 CEST] <atomnuker> Gramner: why can I only multiply by 8 in e.g. [inq + offsetq*8] ? [10:05:51 CEST] <atomnuker> 16 and above don't wok [10:05:56 CEST] <atomnuker> *work [10:06:33 CEST] <Gramner> the multiplier is really a shift, and it's encoded in 2 bits so there's only 4 possible values. 1, 2, 4, and 8 [10:07:03 CEST] <atomnuker> so its not a preprocessor thing? that explains a few things [10:07:21 CEST] <Gramner> no, it's an integral part of x86 addressing [10:08:19 CEST] <atomnuker> (I thought the preprocessor handled them an expected some speedup if I got rid of them, but I got a slight slowdown instead) [10:12:11 CEST] <Gramner> iirc simple addresses (like [reg]) results in shorter latency on some cpu:s, but if some address calculation needs to be made it's generally best to let the addressing unit deal with it as much as possible [10:21:03 CEST] <atomnuker> btw Gramner, could you review the pyramid vector quantization SIMD on the ML? [10:39:45 CEST] <durandal_1707> atomnuker: wheres rhat code? [10:42:02 CEST] <atomnuker> durandal_1707: the noise reduction one? its still being trained, that was just a wip with limited training [11:40:18 CEST] <durandal_1707> atomnuker: is there code for training? [11:42:30 CEST] <atomnuker> tensorflow, though if you ask him he'll probably give you the script he's using [11:43:04 CEST] <atomnuker> though he's training on a 32 core machine with a gpu with water cooling [11:47:36 CEST] <durandal_1707> atomnuker: and how are such networks appllied? [11:48:00 CEST] <durandal_1707> also it requires big files, no? [11:54:01 CEST] <atomnuker> durandal_1707: https://github.com/xiph/opus/blob/e6704abcad486c9966e79fda3663074a36870c0f/… <- data [11:54:53 CEST] <atomnuker> https://github.com/xiph/opus/blob/e6704abcad486c9966e79fda3663074a36870c0f/… <- usage [13:05:38 CEST] <ZeroWalker> is it possible to get the length of the audio/video when encoding/capturing to a file. As i need to sync the audio as it will be shorter than the video over time, so i need ot add silence [13:16:42 CEST] <kierank> Use timestamps for that [13:33:27 CEST] <ZeroWalker> you mean the pts? [13:33:42 CEST] <ZeroWalker> that would work, quite obviously -_-, thanks [16:02:51 CEST] <durandal_1707> neural networks are overrated [17:44:42 CEST] <ElementalBlack> How does slice threading work? Are multiple threads opened for each row of pixels in an image or something? [17:45:47 CEST] <ubitux> in libavfilter? [17:45:58 CEST] <ElementalBlack> yeah [17:46:28 CEST] <ubitux> you define how much slices you can have [17:46:34 CEST] <ubitux> in the filter itself [17:46:47 CEST] <ubitux> it's generally something like the number of lines [17:46:59 CEST] <ubitux> or if you're working with 8-pix height block it's height/8 [17:47:13 CEST] <ubitux> so that's your maximum of threads [17:47:35 CEST] <ubitux> then you pick as much threads as the user specified (or automatically picked by the number of core) [17:47:40 CEST] <ubitux> and clamp it to that value [17:48:16 CEST] <ubitux> in your thread function process, you then defined the range according to the number of threads and the thread id [17:48:24 CEST] <ElementalBlack> I think nlmeans supports slices, but I was only seeing like 2% CPU usage last I checked. [17:48:29 CEST] <ubitux> in nlmeans_slice, this is jobnr / nb_jobs [17:49:28 CEST] <gh0st__> In vp9 for example, num of threads = num of tiles there are in a frame. [17:50:55 CEST] <gh0st__> So each tile is decoded in a separate thread. [17:51:21 CEST] <ubitux> ffmpeg -lavfi testsrc2=s=hd1080,nlmeans -f null - [17:51:35 CEST] <ubitux> i have about 50% cpu use on each core with this currently [17:52:01 CEST] <ubitux> maybe hiting a memory bus factor or something [17:52:59 CEST] <ElementalBlack> ubitux: lemme test [18:08:53 CEST] <ElementalBlack> seems better, 80% usage. .4fps for 1080p, .1fps for a 4k input [18:10:26 CEST] <ElementalBlack> do those fps's seem low, or is that just what it is [19:02:09 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07master:bf8ab72ae95b: avcodec/dirac_dwt: Fix multiple integer overflows in COMPOSE_DD97iH0() [19:19:36 CEST] <ubitux> ElementalBlack: nlmeans is not meant for real time [19:19:44 CEST] <ubitux> that said, yeah it should probably be optimized [19:20:00 CEST] <ubitux> i'm still looking into making the map created with simd [19:20:09 CEST] <ubitux> not sure what else can be done to improve speed [19:21:05 CEST] <ElementalBlack> ubitux: do you know which function is eating up comp time? [19:21:53 CEST] <ubitux> "nlmeans_slice()" :p [19:24:25 CEST] <ubitux> basically 85% in nlmeans_slice(), 15% in nlmeans_plane() [19:24:41 CEST] <ElementalBlack> lol [19:24:47 CEST] <ubitux> making the integral faster will decrease that 15% [19:25:00 CEST] <ElementalBlack> ubitux: I still don't see 100% usage on 8 cores [19:25:08 CEST] <ElementalBlack> ubitux: 70% for 4k [19:25:17 CEST] <ubitux> yeah, same here [19:25:33 CEST] <ElementalBlack> is 100% possible? [19:26:18 CEST] <ubitux> who knows [19:26:32 CEST] <ElementalBlack> ubitux: i've heard positive results on GPU nlmeans. working on that now [19:26:52 CEST] <ubitux> sure, good luck :) [19:27:05 CEST] <ubitux> not sure if the integral method is appropriate for a gpu though [19:27:17 CEST] <ubitux> you may attempt a different approach [19:28:10 CEST] <ElementalBlack> ubitux: This is currently my reference kernel https://github.com/opencv/opencv/blob/master/modules/photo/src/opencl/nlmea… [19:37:17 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.3:aadfec7d6ca9: avcodec/pixlet: Simplify nbits computation [19:37:18 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.3:d40bb6f5e934: avcodec/diracdec: Fix integer overflow in signed multiplication in UNPACK_ARITH() [19:37:19 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.3:0d2b67d17c9b: avformat/rtmppkt: Convert ff_amf_tag_size() to bytestream2 [19:37:20 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.3:6de5ec8ef818: avformat/rtmppkt: Convert ff_amf_get_field_value() to bytestream2 [19:37:21 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.3:38d9a782a585: avcodec/takdec: Fix integer overflow in decode_subframe() [19:37:22 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.3:934878f2a62f: avcodec/diracdec: Fix integer overflow in divide3() [19:37:23 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.3:4f714352488d: avcodec/dirac_dwt: Fix multiple integer overflows in COMPOSE_DD97iH0() [19:37:24 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.3:9079c70d2095: Changelog:update [19:48:43 CEST] <durandal_1707> what filter you find missing in lavfi? [19:50:50 CEST] <ubitux> "good ones"© [19:50:59 CEST] <ubitux> improve existing [19:53:25 CEST] <durandal_1707> which ones? [19:56:07 CEST] <ElementalBlack> what is this 'const int w = i ? s->chroma_w : inlink->w;' in 'for (i = 0; i < s->nb_planes; i++)' actually doing? does that just mean that the first plane is a luma plane? [19:57:53 CEST] <ubitux> durandal_1707: fieldmatch? :° [19:58:07 CEST] <ubitux> ElementalBlack: yes [19:59:15 CEST] <durandal_1707> ubitux: whats wrong with it? [19:59:39 CEST] <ubitux> sync with upstream [19:59:49 CEST] <ubitux> more extensive tests [20:00:17 CEST] <ubitux> pretty sure something needs to be done about deshake or any related filter [20:00:29 CEST] <ubitux> i always forget if we have a decent slowmo filter [20:00:51 CEST] <ubitux> we need to port the remaining features from the mpeg dec to codeview [20:01:10 CEST] <ubitux> (and probably add more features such as the ones used in vp9 and hevc) [20:01:14 CEST] <ubitux> ( segmentation) [20:21:13 CEST] <jamrial> ubitux: https://pastebin.com/GNU1FFUU after adding a bunch of noinline attribute to functions [20:21:38 CEST] <ubitux> diff? [20:22:31 CEST] <jamrial> ubitux: https://pastebin.com/gENtTgY4 [20:23:29 CEST] <jamrial> writing simd for ssd_integral_image would help quite a bit [20:26:25 CEST] <ubitux> funny [20:26:50 CEST] <ubitux> well, i still plan to write the simd for aarch64 [20:27:03 CEST] <ubitux> i think i have a branch for that [20:27:34 CEST] <ubitux> i'd say it's 2-3h of work max [20:28:46 CEST] <ubitux> i'll have time in 2 weeks [20:29:54 CEST] <ElementalBlack> should be interesting to compare that to a GPU one [20:32:04 CEST] <ElementalBlack> might be a #git question, but is there a way to update my master branch and merge the changes to my local branch before commiting? [20:45:00 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07n3.3.3:HEAD: avcodec/dirac_dwt: Fix multiple integer overflows in COMPOSE_DD97iH0() [20:52:31 CEST] <ubitux> damn, where is wm4, i have a surprise for him [20:53:50 CEST] <JEEB> he's enjoying a long-needed vacation [20:54:00 CEST] <ubitux> sounds reasonable [20:54:31 CEST] <ubitux> anyway, i improved the subrip engine [20:54:40 CEST] <ubitux> it should be much less shitty for end users [21:18:43 CEST] <DHE> ElementalBlack: if you have your own branch, update the master branch first, switch to your custom branch and run "git rebase master" [22:39:51 CEST] <atomnuker> more opus simd on the ML, gives around 8% decoder speedup on CBR constant frame-size [22:40:19 CEST] <atomnuker> jamrial: could you take a look at it? and the pvq SIMD patch iive posted? [22:43:03 CEST] <iive> that chunk @@ -253,13 +283,14 @@, seems to have some cosmetics embedded. [22:44:45 CEST] <atomnuker> no idea what those numbers mean [22:44:53 CEST] <atomnuker> "s->imdct_half = imdct15_half;"? [22:45:17 CEST] <atomnuker> that's because postrotate was longer than any of the rest so I had to realign them otherwise it would look ugly [22:48:37 CEST] <iive> oh, ok. [22:53:16 CEST] <ubitux> durandal_1707: please submit new filters with a doc, or at least a description in the commit message for the review if it's a WIP/RFC [22:53:52 CEST] <durandal_1707> never [22:54:18 CEST] <ubitux> well, if you don't want reviews just push them without sending them to the ml [22:54:45 CEST] <durandal_1707> nooo, im trolling [22:56:33 CEST] <iive> atomnuker: so, is the LUT__LOAD_4D faster than the vgather ? [22:58:37 CEST] <atomnuker> yep [22:58:50 CEST] <iive> another win for Intel /sarcasm [22:59:10 CEST] <atomnuker> it was around 2x faster than what I had before [22:59:10 CEST] <iive> atomnuker: btw, the macro has small issue, it doesn't use %2 anywhere. it works because you use %1 and %2 as same register. [22:59:21 CEST] <atomnuker> yeah [22:59:27 CEST] <atomnuker> I can't do anything about it though [22:59:45 CEST] <iive> yes you can :D [22:59:49 CEST] <atomnuker> the arguments are replaced by the preprocessor before they're replaced by the macro [23:00:01 CEST] <atomnuker> so I can't mix e.g. %2 and x%2 [23:00:17 CEST] <atomnuker> since that'll become ymm2 and xymm2 [23:00:33 CEST] <iive> xmm%1 would give you the xmm variant of the register [23:00:45 CEST] <atomnuker> yeah, but then I'd have to pass numbers [23:00:52 CEST] <iive> NO [23:00:53 CEST] <atomnuker> I'll do it for v2 [23:01:20 CEST] <atomnuker> I'll have to pass numbers [23:01:25 CEST] <iive> x86inc has them as redefines of xmmymm0 [23:01:38 CEST] <atomnuker> ? [23:01:40 CEST] <iive> aka xmmymm0 -> xmm0 [23:02:08 CEST] <atomnuker> huh, wasn't aware of that [23:02:11 CEST] <iive> xmm%1 when %1==ymm => xmmymm0 => xmm0 [23:03:11 CEST] <iive> it's very clever and neat :D [23:05:28 CEST] <Gramner> atomnuker: what gather sequence did you compare LUT_LOAD_4D to? movdqa + pcmpeqd + vgatherdps? [23:08:05 CEST] <Gramner> err, vgatherdpd I mean [23:09:34 CEST] <atomnuker> pcmpeq for the mask, then a movu [lut_offset] for the address, then vgatherqpd m1, [inq + m4*8], m3 for the loads [23:09:51 CEST] <atomnuker> all this 2x for the negative and positive offset parts [23:10:18 CEST] <Gramner> on what cpu? [23:10:35 CEST] <atomnuker> i7-6700HQ [23:11:26 CEST] <Gramner> qpd? aren't the lut values 32-bit? [23:12:35 CEST] <atomnuker> they were 64 bit ones since I wanted to use bytes for offset_p/n and wanted to look up the indices the same way I did exp values [23:12:48 CEST] <atomnuker> but I ended up just multiplying everything by 8 [23:13:10 CEST] <atomnuker> and that saved me having a separate counter register [23:13:37 CEST] <atomnuker> and then I could just multiply the offsets by 4 to switch to having 32 bit values [23:14:07 CEST] <atomnuker> I'll try to measure it again now, its just a few instructions [23:15:23 CEST] <Gramner> gathers seem to have a high additional latency penalty over individual loads. I guess they're mostly only useful with zmm regs in combination with scatters in a load-modify-store scenario for now [23:15:52 CEST] <durandal_1707> so there is simd for lut ? [23:17:28 CEST] <Gramner> you can do some crazy lut simd stuff with avx-512. even with conflict detection for overlapping indices, but that part is insanely slow on SKL-X unfortunately [23:21:26 CEST] <Gramner> vpconflict* instructions are µcoded on SKL-X and are like 30/10 (compared to 3/1 on KNL) [23:21:49 CEST] <Gramner> which eats up pretty much all the performance gain [23:22:02 CEST] <Gramner> 30/20 even [23:22:58 CEST] <Gramner> I'm guessing that will be resolved in the next µarch [23:23:07 CEST] <atomnuker> Gramner: did another test, vgather 1000 to 1700 decicycles slower on 20ms frames [23:23:58 CEST] <atomnuker> what do you need vpconflict for? [23:24:26 CEST] <Gramner> if it's that bad on skylake it's gong to be atrocious on haswell and zen [23:25:26 CEST] <atomnuker> do you know if any microcode updates speed up any complex instructions? [23:25:27 CEST] <Gramner> if you have overlapping indices. say you want to load 8 values, add some other value to them, and store write them back [23:25:48 CEST] <Gramner> that will break if you just do gather+add+store [23:25:58 CEST] <Gramner> if two values have the same address [23:26:51 CEST] <Gramner> conflict detection allows you to detect if two indicies are identical and deal with it [23:27:24 CEST] <atomnuker> I can't see how that's useful, you're better of redoing your luts and making sure you have no identical indices [23:28:09 CEST] <atomnuker> (and I don't know of any luts I've done that have had repeating indices) [23:28:14 CEST] <Gramner> if your indices are calculated dynamically you don't know if they're going to overlap or not [23:29:10 CEST] <atomnuker> that's going to be very slow anyway, can't do much about it [23:29:15 CEST] <iive> how is the store done? [23:31:07 CEST] <Gramner> https://git.videolan.org/?p=x264.git;a=blob;f=common/x86/mc-a2.asm;h=e93cfc… real-world use-case (corresponding C: https://git.videolan.org/?p=x264.git;a=blob;f=common/mc.c;h=65af5b9e25ad252… ) [23:32:07 CEST] <Gramner> it's just not that beneficial over doing that part in scalar at the moment due to vpconflictd being slow as hell. it's like a third of the runtime of the entire function in that instruction [23:36:23 CEST] <Gramner> microcode updates tends to be about bug fixes [23:37:03 CEST] <iive> avx2 doesn't have scatter and "conflict" opcodes [23:37:13 CEST] <Gramner> no, avx2 doesn't [23:38:13 CEST] <iive> also, i don't understand what is the problem if 2 indexes are the same, if all you do is add same constant to all of them. (if it was different then yeh) [23:38:48 CEST] <durandal_1707> what about undocumented instructions ? [23:38:52 CEST] <iive> i mean, the result might be written twice, but with the same value. [23:39:43 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:e5d9f0c3cd05: avcodec/takdec: Fixes: integer overflow in AV_SAMPLE_FMT_U8P output [23:39:44 CEST] <cone-843> ffmpeg 03Anton Mitrofanov 07release/3.2:312f96053ae5: avcodec/h264_cabac: Fix CABAC+8x8dct in 4:4:4 [23:39:45 CEST] <cone-843> ffmpeg 03Anton Mitrofanov 07release/3.2:b36c97a0aea7: avcodec/h264_mb: Fix 8x8dct in lossless for new versions of x264 [23:39:46 CEST] <cone-843> ffmpeg 03Anton Mitrofanov 07release/3.2:f7addaece89b: avcodec/h264: Fix mix of lossless and lossy MBs decoding [23:39:47 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:66735ddd7220: avcodec/htmlsubtitles: Replace very slow redundant sscanf() calls by cleaner and faster code [23:39:48 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:27ad04e128cb: avcodec/aacdec_fixed: Check s for being too small [23:39:49 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:9125bbb3e58d: avcodec/wavpack: Fix undefined integer negation [23:39:50 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:b97e0e98b4e5: avcodec/lpc: signed integer overflow in compute_lpc_coefs() (aacdec_fixed) [23:39:51 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:dd4fd80fe68b: avcodec/mpeg4videodec: Fix overflow in virtual_ref computation [23:39:52 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:80dc5b497e5d: avcodec/hevc_filter: Fix invalid shift [23:39:53 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:6d951be24de8: avcodec/cfhd: Fix undefined shift [23:39:54 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:9bca2f698bbc: avcodec/cfhd: Check bpc before setting bpc in context [23:39:55 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:220ee7e58369: avcodec/tiff: Update pointer only when the result is used [23:39:56 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:00a6211b458a: avcodec/takdec: Fix integer overflow [23:39:57 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:a7c0243e2f61: avcodec/wavpack: Fix integer overflow [23:39:58 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:a2bde1363c93: avcodec/mpeg4videodec: Fix GMC with videos of dimension 1 [23:39:59 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:fc24783c6d19: avcodec/wavpack: Fix integer overflow in wv_unpack_stereo() [23:40:00 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:5bb861d45b86: avcodec/apedec: Fix integer overflow [23:40:01 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:bbf911b660b9: avcodec/jpeg2000dwt: Fix integer overflow in dwt_decode97_int() [23:40:02 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:20ce366feefc: avcodec/vb: Check vertical GMC component before multiply [23:40:03 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:d986096963fc: avcodec/cfhd: Fix invalid left shift of negative value [23:40:04 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:2b85709bee16: avcodec/hevc_ps: Fix integer overflow with beta/tc offsets [23:40:05 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:aaecd2ef68d9: avcodec/h264_slice: Fix signed integer overflow [23:40:06 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:a954b531f63b: avcodec/wavpack: Fix invalid shift [23:40:07 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:a76db7176ab8: avcodec/sbrdsp_fixed: Fix integer overflow in sbr_hf_apply_noise() [23:40:08 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:6405c66a5142: avcodec/ylc: Fix vlc of 31 bits [23:40:09 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:1268784d9f6c: avcodec/aacps (fixed point): Fix multiple signed integer overflows [23:40:10 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:fa427bdb5999: avcodec/mjpegdec: Clip DC also on the negative side. [23:40:11 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:aa01a35dd507: avcodec/magicyuv: Check that vlc len is not too large [23:40:12 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:3abe6554c1eb: avcodec/aacdec_template: Fix undefined integer overflow in apply_tns() [23:40:13 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:13c0467c4923: avcodec/ffv1dec_template: Fix signed integer overflow [23:40:14 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:97e35bc40be7: avcodec/aacdec_template (fixed point): Check gain in decode_cce() to avoid undefined shifts later [23:40:15 CEST] <cone-843> ffmpeg 03Vodyannikov Aleksandr 07release/3.2:539dc1746a8b: avcodec/cfhd: Fix decoding regression due to height check [23:40:16 CEST] <cone-843> ffmpeg 03Brice Waegeneire 07release/3.2:79f6269fd0ac: doc/filters: typo in frei0r [23:40:17 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:c368f0756536: avcodec/dirac_vlc: Fix undefined shift [23:40:18 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:7f638d56bde9: avcodec/aacdec_fixed: fix: left shift of negative value -1 [23:40:19 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:b905d2948a0e: avcodec/aacps: Fix multiple integer overflow in map_val_34_to_20() [23:40:20 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:00b0d595eb4e: avcodec/ylc: Fix shift overflow [23:40:21 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:6cc7777d4bcb: avformat/oggparsecelt: Do not re-allocate os->private [23:40:22 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:efb649467cb8: avcodec/hevc_ps: fix integer overflow in log2_parallel_merge_level_minus2 [23:40:23 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:6a10b962e305: avcodec/dnxhddec: Move mb height check out of non hr branch [23:40:24 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:8c7b477b97fb: avcodec/diracdec: Fix integer overflow in signed multiplication in UNPACK_ARITH() [23:40:25 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:f2a6f41dd7b9: avformat/rtmppkt: Convert ff_amf_tag_size() to bytestream2 [23:40:26 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:b375cc8bb74a: avformat/rtmppkt: Convert ff_amf_get_field_value() to bytestream2 [23:40:27 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:bae812711ad2: avcodec/takdec: Fix integer overflow in decode_subframe() [23:40:28 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:7827b06d7731: avcodec/diracdec: Fix integer overflow in divide3() [23:40:29 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:e8893979249a: avcodec/dirac_dwt: Fix multiple integer overflows in COMPOSE_DD97iH0() [23:42:23 CEST] <Gramner> if you add something to the same destination multile times you generally want to have them be additative and not arbitrarily just add one of the values and overwrite the rest [23:43:45 CEST] <Gramner> e.g. a+=b; a+=c; is not equivalent to tmp=a; a=tmp+b; a=tmp+c; [00:00:00 CEST] --- Sun Jul 30 2017

1 0

ffmpeg.log.20170729
by burek 30 Jul '17

30 Jul '17

[00:27:23 CEST] <LABcrab> Hi. I'm looking for help with ffmpeg2theora (.VOB to .OGV). What is the best setting? Should I simply use 640x480? Here is the command I currently use: [00:27:33 CEST] <LABcrab> ./ffmpeg2theora --deinterlace -x 640 -y 480 /Volumes/DiscName/VIDEO_TS/VTS_01_1.VOB -o ~/output.ogv -a 7 [00:28:52 CEST] <furq> wtf how is that still maintained [00:29:12 CEST] <LABcrab> It works for me. I'll gladly use ffmpeg2vp8 if there is such a thing. [00:29:32 CEST] <furq> why not just use ffmpeg [00:29:42 CEST] <furq> ffmpeg -i foo.vob out.ogv [00:29:46 CEST] <furq> will convert to vp8/vorbis [00:29:51 CEST] <TD-Linux> it's no longer maintained [00:29:57 CEST] <furq> it was updated in 2016 [00:30:06 CEST] <furq> i'm not sure why [00:30:25 CEST] <TD-Linux> I take that back, it's mildly maintained [00:30:35 CEST] <furq> i'm amazed it was updated that recently [00:30:40 CEST] <furq> i remember using that like 10+ years ago [00:30:40 CEST] <LABcrab> furq, are there any reasons for me to use VP8/VP9/etc. over Theora? [00:30:45 CEST] <furq> they're much better [00:30:52 CEST] <furq> theora was never good and it's especially not good now [00:31:12 CEST] <furq> you should probably also use opus over vorbis [00:31:35 CEST] <LABcrab> Is Theora more lightweight, or is it as performance-intense as VP8? [00:31:42 CEST] <furq> i have no idea [00:32:08 CEST] <furq> the vp8 encoder in ffmpeg is reasonably quick iirc [00:32:17 CEST] <furq> i take it you specifically want license-free codecs [00:32:31 CEST] <LABcrab> This is my player: https://BarlowGirl.ca/wp-content/BigShinyPlanet/BigShinyPlanet.html [00:32:41 CEST] <LABcrab> I would prefer license-free. [00:33:24 CEST] <LABcrab> The video is uploaded at 720x480, but I'm thinking of reuploading it at 640x480, and with deinterlacing if absent. [00:33:31 CEST] <furq> vp8/webm is more widely supported than theora/ogv now anyway [00:33:49 CEST] <furq> edge and android chrome support webm but not ogv [00:34:02 CEST] <furq> safari supports neither but then safari doesn't support anything [00:34:14 CEST] <furq> unless they get mpeg-la backhanders for it [00:34:19 CEST] <LABcrab> Android doesn't support Theora at all? [00:34:27 CEST] <furq> http://caniuse.com/#search=theora [00:34:29 CEST] <furq> not according to this [00:34:57 CEST] <LABcrab> Also, should I use 720x480 (original) or 640x480 (force 4:3)? [00:35:10 CEST] <furq> use 720x480 and set the aspect ratio [00:35:20 CEST] <furq> -aspect 4:3 if you're not cropping [00:36:17 CEST] <TD-Linux> LABcrab, theora is less resource intensive to decode [00:36:20 CEST] <TD-Linux> I recommend VP9 though [00:36:21 CEST] <furq> or uh [00:36:24 CEST] <furq> -aspect 15:11 [00:36:26 CEST] <furq> ITU baby [00:36:51 CEST] <LABcrab> TD-Linux Thanks. :-) Do you have a page somewhere that explains why? [00:37:07 CEST] <TD-Linux> no but I could make one [00:37:09 CEST] <furq> probably just that it's a much simpler codec [00:37:31 CEST] <TD-Linux> theora is VP3++ [00:37:42 CEST] <LABcrab> VP3 with goodies? [00:37:53 CEST] <TD-Linux> yes, a much better encoder and extra bitstream features [00:37:54 CEST] <furq> VP3 was made public domain, theora is based heavily off it [00:38:09 CEST] <TD-Linux> the original VP3 encoder was nearly unusably slow [00:38:11 CEST] <furq> then eventually google bought on2 [00:39:09 CEST] <furq> but yeah vp3 is like 17 years old [00:39:19 CEST] <LABcrab> Thanks so much for the aspect ratio trick. I typed 1.33 as this is a DVD. What does the computer do? Does it render the 720 width as 640? [00:39:28 CEST] <furq> something like that [00:39:38 CEST] <furq> like i said, it should be 15:11 if you're not cropping [00:39:48 CEST] <furq> 704*480 is 4:3 [00:39:54 CEST] <furq> it's not a huge deal though [00:40:04 CEST] <TD-Linux> you'll find VP9 encoding pretty slow, you can put higher numbers into cpu-used if it's too slow [00:40:12 CEST] <TD-Linux> if 6 is still too slow then switch to VP8 [00:40:25 CEST] <furq> you'll want to set a bitrate as well [00:40:25 CEST] <furq> or crf [00:40:26 CEST] <LABcrab> I'm not dealing with VP9 yet. With TenFourFox, for example, VP9 doesn't play nice. [00:40:39 CEST] <LABcrab> The default is quality 6. [00:40:50 CEST] <TD-Linux> ah yeah actually if you're targeting tenfourfox you'll probably want to compare both vp8 and theora [00:41:39 CEST] <furq> ffox 45 should have a vp9 decoder [00:41:45 CEST] <furq> i guess maybe it was removed for ppc though [00:42:12 CEST] <LABcrab> It is present, but either the PPC CPU is too slow or the code isn't fully optimized. [00:42:16 CEST] <TD-Linux> more importantly it may not have altivec assembly [00:42:24 CEST] <TD-Linux> libtheora is more likely to have altivec, let me check [00:43:01 CEST] <furq> https://code.google.com/archive/p/tenfourfox/issues/28 [00:43:04 CEST] <furq> looks like it's being worked on [00:43:11 CEST] <furq> or was worked on, rather [00:43:17 CEST] <TD-Linux> yeah no there's no altivec, you'll just have to pick the one that is fastest [00:43:21 CEST] <furq> ^ [00:43:37 CEST] <furq> that's from 2011 though so maybe it predates vp9 [00:43:48 CEST] <furq> vp8 is still ok though [00:43:55 CEST] <TD-Linux> if VP8 is too slow, theora is a reasonable choice. there are certainly worse choices. [00:44:24 CEST] <furq> i can't really think of any that work in web browsers [00:44:46 CEST] <TD-Linux> yeah ok [00:44:51 CEST] <furq> maybe sorenson spark in flv [00:44:56 CEST] <furq> that's cheating though [00:45:00 CEST] <LABcrab> On the files that I already have, should I copy them via ffmpeg, but add aspect 1.33? [00:45:02 CEST] <TD-Linux> and also worse than theora [00:45:15 CEST] <furq> LABcrab: yeah that works [00:45:22 CEST] <furq> -c copy -aspect 15:11 [00:45:36 CEST] <furq> -aspect sets the container's dar flag, not the stream's [00:45:49 CEST] <LABcrab> I'm thinking ffmpeg2theora doesn't have that setting, so I'd have to use ffmpeg after. [00:46:04 CEST] <TD-Linux> you can use ffmpeg directly instead of ffmpeg2theora [00:46:04 CEST] <furq> you should really just use ffmpeg for the whole thing [00:46:20 CEST] <TD-Linux> ffmpeg -i file.mp4 file.ogv [00:46:25 CEST] <LABcrab> What exactly is the difference? [00:46:35 CEST] <furq> ffmpeg2theora predates ffmpeg supporting theora [00:46:40 CEST] <furq> circa ~10 years ago [00:46:46 CEST] <LABcrab> (15:11 works either way; my mistake.) [00:46:47 CEST] <furq> but it's supported it for a long time [00:46:47 CEST] <TD-Linux> also the CLI options are different [00:47:26 CEST] <LABcrab> Isn't 720x480 1.5:1 though? [00:47:50 CEST] <furq> it is if the sar is 1:1 [00:47:51 CEST] <furq> but it isn't [00:48:35 CEST] <furq> ffmpeg -i foo.vob -c:v libvpx -b:v 0 -crf 30 -c:a libopus -b:a 128k out.webm [00:48:37 CEST] <furq> something like that [00:48:41 CEST] <furq> er [00:48:45 CEST] <furq> ffmpeg -i foo.vob -c:v libvpx -b:v 0 -crf 30 -c:a libopus -b:a 128k -aspect 15:11 out.webm [00:49:20 CEST] <furq> someone who works on libvpx can probably tell me if -b:v 0 works for vp8 [00:49:25 CEST] <furq> if only there were someone like that here... [00:49:33 CEST] <LABcrab> Is there an article about 15:11? [00:49:48 CEST] <TD-Linux> it does [00:51:44 CEST] <redrabbit> is aac a fine choice for avg 120k stereo TS [00:52:32 CEST] <redrabbit> too bad opus dont work with .ts [00:53:21 CEST] <JEEB> huh [00:53:26 CEST] <JEEB> it is defined so it might be the muxer [00:53:39 CEST] <redrabbit> does webm video codecs compete with x265 [00:53:42 CEST] <redrabbit> maybe [00:53:47 CEST] <JEEB> except my browser history has a patch for opus in mpegts [00:53:53 CEST] <TD-Linux> actually I take back what I said about VP8, it uses -b:v as the max bitrate so you need to set it really high instead [00:54:01 CEST] <TD-Linux> redrabbit, VP9 does [00:54:50 CEST] <JEEB> redrabbit: so actually FFmpeg's muxer does support it :P http://git.videolan.org/?p=ffmpeg.git;a=commit;h=01509cdf9287b975eced1fd609… [00:54:57 CEST] <JEEB> since late 2015 [00:55:06 CEST] <furq> LABcrab: 704*480 is exactly 4:3 with a sample aspect ratio of 10:11 [00:55:18 CEST] <furq> 720*480 is 15:11 [00:56:21 CEST] <LABcrab> Okay. What is 4:3, then? I guess that old TVs use 720x480? What happens when a video like that is played on a 640x480 PC monitor? [00:56:39 CEST] <furq> NTSC DVDs are always 720*480 [00:56:58 CEST] <furq> SD NTSC broadcast is 704*480 iirc [00:58:27 CEST] <furq> there's some long and tortuous history behind this that someone in here could probably get into [00:58:55 CEST] <LABcrab> Yeah, there is a gremlin out there who made videos 720x480, maybe. [00:58:56 CEST] <furq> i just ended up writing a script that gives me the correct dar and decided not to care about why it was correct [00:59:40 CEST] <voip_> hello guys i need compile/configure in centos7 ffmpeg with h264_qsv support. So where i cand found guide step by step ? [01:00:21 CEST] <TD-Linux> furq, even worse 704x486 [01:00:35 CEST] <TD-Linux> (NTSC is analog, so we're going with SDI resolution here) [01:02:57 CEST] <LABcrab> I'll send my link again. [01:03:37 CEST] <LABcrab> https://BarlowGirl.ca/wp-content/BigShinyPlanet/BigShinyPlanet.html [01:03:51 CEST] <LABcrab> Should I change my fixed width and height on the player so that it reflects 15:11? [01:06:15 CEST] <furq> should be 654*480 i guess [01:15:18 CEST] <redrabbit> ill try to use opus again [01:41:19 CEST] <LABcrab> What is the link to the website listing which browsers support which codecs? [01:42:08 CEST] <voip_> guys i need compile/configure in centos7 ffmpeg with h264_qsv support. So where i cand found guide step by step ? [01:44:34 CEST] <furq> LABcrab: http://caniuse.com/ [01:44:41 CEST] <LABcrab> Thanks. :-) [01:54:39 CEST] <LABcrab> The video file displays at ~640x480, so to furq and the Linux user, I'm really grateful for your help. The settings you gave are correct. :-) [02:12:13 CEST] <redrabbit> strange, i got the dll from https://opus-codec.org/downloads/ in the same folder as ffmpeg and -c:a libopus -b:a 128k -ac 2 -async 1 outputs a video only strem [02:12:40 CEST] <redrabbit> its with dvbviewer iptv media server i dont know where i can check the logs [02:18:36 CEST] <redrabbit> -c:a aac works fine [02:30:35 CEST] <redrabbit> do you guys recommand -cutoff ? i use 15000 atm [10:47:45 CEST] <dorvan> hi all [10:49:31 CEST] <dorvan> i'm trying to make a html live streaming from a network camera stream acquired with ffmpeg, how i can make a socket buffer to make the video really "live" ? [12:10:04 CEST] <q3cpma> Hello, I have a few questions. Is the native AAC encoder (as of 3.3.2) really as good as fdk? Is there a way to convert FLAC replay gain metadata to AAC gain during conversion? [12:48:51 CEST] <j605> I am trying to play an hls stream using mpv, I ran into this bug:https://trac.ffmpeg.org/ticket/4275 [12:49:20 CEST] <j605> logs are taken by using mpv: https://0x0.st/kZ_.txt [12:49:31 CEST] <j605> problem starts at: [ 187.935][e][ffmpeg/audio] aac: channel element 1.0 is not allocated [12:49:55 CEST] <durandal_1707> and how that is relevant? [12:53:27 CEST] <j605> I was able to reproduce it with: outube-dl --hls-prefer-native -o - http://www.sonyliv.com/details/live/5519365900001/LIVE---Sri-Lanka-vs-India… | ffplay - [12:58:34 CEST] <j605> logs with ffplay: https://0x0.st/kZL.log [13:05:33 CEST] <j605> durandal_1707: is this relevant? [13:49:04 CEST] <j605> compiling without libfdk-aac fixes the issue [14:33:13 CEST] <dorvan> hi all, i'm trying to make a html live streaming from a network camera stream acquired with ffmpeg, how i can make a socket buffer to make the video really "live" without a server? [15:36:15 CEST] <DHE> dorvan: you need a server of some kind to serve it to multiple users, unless maybe you only have 1 user. even if it's just running HTTP (like apache or IIS) [15:37:32 CEST] <dorvan> DHE: as output for ffmpeg conversion of source stream? [15:46:12 CEST] <DHE> dorvan: are you referring to HLS when you say Html live streaming? [15:46:19 CEST] <DHE> (it actually stands for http live streaming) [15:47:33 CEST] <dorvan> DHE: yes, I know, HLS, or MPEG-DASH, or simple the play of h264 datastream read by a socket... [15:48:36 CEST] <DHE> HLS and MPEG-DASH allow you to stream using only an ordinary HTTP server, but the latency involved tends to be high. I'd assume 10 seconds best case [15:48:44 CEST] <dorvan> netcam (rtsp/rtmp)-input-> ffmpeg acquisition, -output-> (something) ->HSL [15:49:24 CEST] <DHE> I'm running at myself [15:49:53 CEST] <dorvan> DHE: i need to permit the view of live stream channel of the netcam in a web, html5 application frontend, with less I/O as possible. [15:50:49 CEST] <dorvan> can be also good a "gw" for source stream to be viewed from html5 page. [15:50:57 CEST] <DHE> if /var/www/html is your HTTP serving directory (default on some distros) you can run: ffmpeg -i rtsp://....../source -c copy -f hls -hls_list_size 5 -hls_time 4 -hls_flags +delete_segments /var/www/html/mystream.m3u8 # assumes H264 camera source and AAC or AC3 audio [15:51:15 CEST] <DHE> you can replace -c copy with whatever codec options you want to adjust bitrates or whatever [15:51:24 CEST] <DHE> HLS.js can give you a pure javascript video player [15:51:54 CEST] <dorvan> thanks for the cmdline, i need that!!! [15:52:24 CEST] <dorvan> HLS, have problem with angularjs we use for the gui, we have to review.. [15:52:51 CEST] <dorvan> so i can point to file path of m3u8 file? [15:53:07 CEST] <DHE> basically [15:53:25 CEST] <DHE> you can test with VLC using Open Network Source and put in the URL to the m3u8 file [15:54:05 CEST] <dorvan> great! So HLS can play it without a backend server? [15:54:32 CEST] <JEEB> the thing you are writing the playlists and segments to is a server [15:54:45 CEST] <JEEB> and you are using a httpd to serve those files [15:54:48 CEST] <DHE> you need an HTTP server. I'm assuming that's rather easy to obtain [15:55:00 CEST] <dorvan> DHE: obviously :-D [15:55:13 CEST] <JEEB> DHE: also technically the minimal latency for HLS is 3xsegment length [15:55:32 CEST] <dorvan> DHE: but you don't need a repeater like nginx + rtsp module as backend for live [15:55:35 CEST] <DHE> JEEB: yes, but people like concrete numbers. :) [15:55:40 CEST] <JEEB> so if you do 0.5 second segments then you can get it down to 1.5s f.ex. [15:56:04 CEST] <JEEB> of course that is on top of your encoder delay etc [15:56:11 CEST] <DHE> JEEB: maybe, but that assumes no encoder latency and such a tiny segment length is kinda nuts [15:56:20 CEST] <JEEB> I don't disagree :D [15:56:45 CEST] <JEEB> DASH actually lets you make segments without a RAP in the beginning so you could separate things into multiple segments if you require short segments [15:56:50 CEST] <dorvan> DHE: we have to tune it... :-) [15:57:08 CEST] <JEEB> but generally I don't remember what the MPEG DASH playback buffering spec was [15:57:31 CEST] <dorvan> thanks guys [15:58:00 CEST] <dorvan> JEEB: it's on client side, in the view [15:58:14 CEST] <JEEB> I'm pretty sure we're talking about different things :P [15:59:25 CEST] <JEEB> there should be some specification on how MPEG-DASH players should handle live streams and buffering. just like the HLS spec notes "player has to buffer the last three segments". that controls the minimum latency you can do by poking at the HLS side of things (as opposed to the encoding part before that) [16:00:08 CEST] <dorvan> ah ok... [16:02:03 CEST] <dorvan> how i can tune the format to be "mobile" compatible with less I/O? source and converted video it's already a 30fps 4MP h264+aac in mp4 container. but i have problem to see it in "android" device browser (all) [16:04:47 CEST] <dorvan> about recordings, not live [16:06:27 CEST] <DHE> if you got live streaming working, HLS can be used in the same way for a pre-created video. set hls_list_size to 0 [16:07:22 CEST] <dorvan> DHE: but have to pre-load the segments? [16:08:18 CEST] <DHE> on the server side you run ffmpeg on the original video to convert it to HLS. the client will stream the segments as needed [16:09:19 CEST] <dorvan> DHE: so is it possble presents all recordings as 1 navigable (with timeline) video with HLS? [16:09:35 CEST] <DHE> HLS supports a simple seek bar, yes [16:10:06 CEST] <dorvan> DHE: ah ok, i have to convert videos... [16:10:15 CEST] <dorvan> so no time metadata? [16:10:19 CEST] <DHE> of course, a pre-recorded .mp4 video will give better efficiency if you can make use of it. just encode it with output option -movflags faststart [16:12:48 CEST] <dorvan> example: our system records only on motion event triggers, triggers launch ffmpeg stream acquisition for recording to copy source stream format and forward fastest as possible maintaining frame rate. [16:14:47 CEST] <dorvan> at moment we register 1 minute video, for any motion event. and put the event in the timeline... is it usefull use hsl segments instead of mp4 and manage the recording as sliced stream? [16:15:05 CEST] <DHE> that's not something I've done and I don't know... [16:15:40 CEST] <DHE> the spec does allow for some timecode information in the playlist but I'm not aware of anyone using that feature and the ffmpeg encoder does not make use of it [16:16:16 CEST] <dorvan> ok, i think managing single mp4 it's more lightweight, and "standard" about timecodes [17:35:08 CEST] <dorvan> DHE: are you there? [17:35:20 CEST] <dorvan> JEEB: are you there? [17:35:52 CEST] <dorvan> DHE: I've made the first try with your suggested options [17:36:19 CEST] <dorvan> but lag it's heavy.... 25-20 secs [17:36:23 CEST] <dorvan> 15-20* [17:36:42 CEST] <DHE> I did warn that 10 seconds was the minimum expected latency [17:37:09 CEST] <JEEB> well not exactly but that's what you often end up with [17:37:16 CEST] <DHE> reducing the hls_time to 2 or 3 might shave off some seconds [17:37:19 CEST] <JEEB> as I said, three segments' worth [17:37:29 CEST] <DHE> I did specify a segment size of 4 seconds [17:37:36 CEST] <JEEB> ok [17:37:51 CEST] <DHE> and that's not knowing the GOP size of the camera involved [17:37:55 CEST] <JEEB> yup [17:41:55 CEST] <dorvan> GOP? [17:42:07 CEST] <DHE> group of pictures. the technical name for what is often called the keyframe interval [17:42:28 CEST] <dorvan> ah ok... [17:51:16 CEST] <dorvan> the -movflag faststart it's for mp4 or hls? [17:52:38 CEST] <dorvan> ffmpeg -re -loglevel warning -i "rtmp://src" -preset ultrafast -tune zerolatency -c copy -f hls -hls_list_size 5 -hls_time 2 -hls_flags delete_segments /Data/mystream.m3u8 [17:53:02 CEST] <dorvan> DHE: i have to put also the movflag faststart? [17:53:51 CEST] <dorvan> JEEB: what do you think about, -re it's wrong in this case? rtsp instead of rtmp, say want pthreads support and not threads support. [17:53:52 CEST] <DHE> that's if you output to .mp4. it makes mp4 streamable [17:54:12 CEST] <DHE> -re is for realtime reading of a file. but if the source is already going to be a realtime bottleneck, don't bother. [17:54:32 CEST] <DHE> use -re if you're taking a pre-recorded file and want to make it into a live stream virtual source [18:01:04 CEST] <dorvan> i see -re it's reported as "best practice" for acquisition to force the stream copy without conversion maintaining the framerate... it's wrong? for recording i say (recordings are triggered by motion event) [18:01:42 CEST] <klaxa> -re means reading in realtime [18:02:51 CEST] <DHE> it means ffmpeg will pause running for a moment if it's receiving data faster than real-time. which is very possible reading a file from disk. not so much when receiving a live feed from a camera [18:17:28 CEST] <dorvan> DHE: i have to manage all streams realtime as possible and reduce lag, and force ffmpeg to not convert or manage the input stream. [18:18:28 CEST] <dorvan> i have to understand, considering i have 2 processes for a single stream (recording and hsl), the right option set, [18:20:00 CEST] <dorvan> DHE: on https://trac.ffmpeg.org/wiki -re, it's related to input stream and input device... not only on file [18:38:33 CEST] <DHE> dorvan: if your source already produces realtime feeds, it's not necessary [18:46:00 CEST] <dorvan> DHE: the netcam it's not "realtime" it's a small arm architeture with a 50% of cpu and memory load, a polling request can help to make it more realtime. [21:08:35 CEST] <lmao_> Trying to convert video encoder from QuickTime 264 to DNxHR, but cant seem to do it. [21:12:07 CEST] <ChocolateArmpits> lmao_, can you provide the command line and resulting log ? [21:35:06 CEST] <timofonic> Hello [21:37:11 CEST] <timofonic> I just have a naive question, I'm a total n00b: What ffmpeg's framework system provide? Does it support shader ones to be used over OpenGL/Vulkan/Direct3D? [21:40:50 CEST] <JEEB> FFmpeg's libraries provide a framework for you to read,demultiplex,decode,filter,encode,multiplex and write multimedia things [21:41:16 CEST] <JEEB> some HW decoders do have the capability to output into D3D surfaces but in most of the cases you are dealing with YCbCr images in RAM [21:41:26 CEST] <JEEB> you can then upload that to your GPU and handle it however you want [21:41:45 CEST] <JEEB> presentation of media in general isn't what FFmpeg's focus is, there are actual *player* projects that handle that [21:42:18 CEST] <JEEB> (many players use FFmpeg's libraries for what happens before presentation) [21:43:16 CEST] <timofonic> JEEB: I say it because many players like MPV use shaders to filter video, so the filtering work is done only by the GPU. I just wondered if there's something similar in FFMpeg framework, providing "multiplatform shaders" that get later converter to the ones of the native OS (OpenGL, Vulkan, Direct3D, Metal...) [21:43:40 CEST] <JEEB> no [21:43:42 CEST] <timofonic> JEEB: I see [21:44:34 CEST] <timofonic> JEEB: Is it because of project focus or because no developer provided code for it? [21:44:45 CEST] <JEEB> mpv utilizes FFmpeg for a lot of stuff but presentation related stuff that uses opengl is 100% mpv's own stuff [21:45:15 CEST] <JEEB> timofonic: probably closer to latter although I'm not sure how much you'd gain for filtering on GPU in non-presentation cases [21:45:17 CEST] <timofonic> I think mpv is also able to use Direct3D stuff [21:45:32 CEST] <JEEB> ANGLE lets you use opengl es with d3d only [21:45:44 CEST] <timofonic> JEEB: Well, there's shaders, OpenGL and CUDA [21:45:51 CEST] <timofonic> OpenCL CL [21:46:01 CEST] <JEEB> yea but how useful is that is something someone would have to check [21:46:11 CEST] <timofonic> JEEB: I see [21:46:16 CEST] <JEEB> I know GPU processing can be very good when you don't have to take your results back at least [21:46:33 CEST] <JEEB> but in most cases for non-presentation for FFmpeg the use case would require getting those resulting textures back to RAM [21:46:45 CEST] <JEEB> not sure if that would be as optimal as with upload+presentation [21:46:52 CEST] <JEEB> which is what players do [21:47:39 CEST] <JEEB> tl;dr GPU filtering can be useful but nobody has taken enough time and effort to see if the upload and download of stuff doesn't take too much time [21:48:21 CEST] <timofonic> JEEB: I see. Another think I imagine would be if would be possible to compile FFMPeg codecs to OpenCL/CUDA, to make them run under GPU only and not depend on proprietary implementations inside GPU of a few codecs (mpeg, H264, H265 in newer ones...) [21:48:53 CEST] <timofonic> JEEB: And maybe the GPU could be used to decode audio. After all, most people these days use HDMI [21:49:23 CEST] <timofonic> And there has been an ATi Radeon API for that in the past, I think [21:49:37 CEST] <timofonic> JEEB: I see [21:55:29 CEST] <JEEB> timofonic: for decoding and encoding of already available formats give up - that's not what GPUs are good for [21:55:35 CEST] <JEEB> for actual image filtering they are good [21:56:07 CEST] <JEEB> pure GPGPU decoders and encoders are only good when the format has from the ground up been made for a very large amount of threads [21:56:21 CEST] <JEEB> ATi back in the day showed off some nice graphs with a made-up format they made [21:56:37 CEST] <JEEB> but of course the more threadability on that level you add, generally the less compression it will give [22:02:16 CEST] <timofonic> JEEB: Oh, I see [22:04:43 CEST] <JEEB> timofonic: there's a reason why the GPU manufacturers pretty much stopped feeding people the GPGPU meme with regards to video compression [22:04:53 CEST] <JEEB> (because it just didn't work well) [22:05:05 CEST] <JEEB> having ASICs on the board optimized for the job works much better [22:06:29 CEST] <JEEB> the only case which was a semi-successful proof of concept was the some sort of lookahead for x264 that MultiCoreWare did. the result was that the data they calculated was based on smaller frame sizes (they downscaled) and it was not necessarily faster at all compared to doing the full thing on CPU) [22:07:19 CEST] <JEEB> and that was not actual coding, they could only manage it because the lookahead didn't have to be synchronized with the actual coding [22:07:36 CEST] <JEEB> so it could be run in a completely separate set of threads without synchronization [22:07:59 CEST] <DHE> sometimes it would give a +20% performance boost, sometimes it would give a -20% performance penalty... [22:09:02 CEST] <JEEB> so basically if someone wants to do stuff with the GPU, one should focus on what GPUs are known to actually excel at [22:18:41 CEST] <luminarys> is it normal that an avfiltergraph with basic resampling screws up pts's in the output frames? [22:19:20 CEST] <luminarys> I'm correcting the output with av_frame_get_best_effort_timestamp, but even that gives very slightly incorrect values (it provides some duplicate pts's) [22:20:42 CEST] <timofonic> JEEB: Nice to know [22:20:53 CEST] <timofonic> Thanks for your magistral class :D [23:06:43 CEST] <idklol> I'm trying to convert h.264 to dnxhd, can anyone give me the correct command? 720p 60fps. [23:10:24 CEST] <ChocolateArmpits> idklol, use this http://www.deb-indus.org/tuto/ffmpeg-howto.htm#Encoding_VC-3 [23:15:28 CEST] <idklol> ChoclateArmpits, I get an error, "Invalid chars 'b' at the end of expression '220Mb'" [23:16:25 CEST] <JEEB> what's the b doing there? ffmpeg.c parameters take just prefixes [23:16:35 CEST] <JEEB> so mega-something would just be M [23:21:45 CEST] <idklol> I get another error, "Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height". [23:22:02 CEST] <JEEB> the actual error is usually higher up in the log [23:22:05 CEST] <JEEB> that is the final error [23:22:21 CEST] <JEEB> as in, whatever catches the error from the deeper place [23:22:36 CEST] <idklol> Video parameters incompatible with DNxHD. Valid DNxHD profiles: [23:22:41 CEST] <idklol> and lists all profiles [23:24:43 CEST] <durandal_1707> idklol: what pixel format is your source? [23:25:03 CEST] <durandal_1707> also what profile you need? [23:25:42 CEST] <idklol> Pixel format? I need 720p 60FPS. I'm trying to change my codec because DaVinci Resolve doesn't accept H.264. [23:26:41 CEST] <idklol> durandal_1707 you there? [23:26:58 CEST] <durandal_1707> idklol: pastebin whole fgmpeg output if you dont know a bunch [23:27:17 CEST] <idklol> One sec [23:29:13 CEST] <dystopia_> davinci resolve is horrible [23:29:23 CEST] <dystopia_> i got that bundled with my capture card [23:29:32 CEST] <idklol> https://pastebin.com/iz0z0J2k durandal_1707 [23:29:38 CEST] <idklol> what else would I use? [23:29:40 CEST] <idklol> :p [23:31:26 CEST] <durandal_1707> you trimmed most important part [23:31:53 CEST] <idklol> oh [23:32:48 CEST] <idklol> ffmpeg -i video.mp4 -vcodec dnxhd -b:v 220M output.mov [23:32:48 CEST] <durandal_1707> anyway, dnxhd supports only some params if you pick limited profile [23:33:42 CEST] <durandal_1707> and what about resolution of input video? [23:34:01 CEST] <idklol> it's 1280x720 [23:35:07 CEST] <ThugAim> wooowee [23:36:41 CEST] <durandal_1707> idklol: you could use one of dnxhr profile [23:37:02 CEST] <idklol> alright, what's the codec name? [23:37:23 CEST] <durandal_1707> -profile:v dnxhr_hq [23:37:37 CEST] <durandal_1707> i think [23:37:49 CEST] <durandal_1707> just add that to your command [23:38:09 CEST] <idklol> ok [23:46:53 CEST] <durandal_1707> you may need to update dnxhd codec component if davinci cant load file [00:00:00 CEST] --- Sun Jul 30 2017

1 0

ffmpeg-devel.log.20170728
by burek 29 Jul '17

29 Jul '17

[00:18:25 CEST] <BBB> Ive started reading up into this signed integer arithmetic overflow is undefined [00:18:30 CEST] <BBB> because it so bothers me [00:19:35 CEST] <BBB> so, my understanding is: undefined in the context of signed additions/multiplications (outside the scope of pointer arithmetic) is a misnomer and they really just mean we cant guarantee the outcome. so, it should have been implementation-defined, not undefined. the spec is a piece of crap when it comes to fine distinctions like this [00:20:07 CEST] <BBB> second, the only reason this behaviour exists, is to allow implementations that dont use twos complement [00:20:23 CEST] <BBB> within the sub-speace of twos complement, the behaviour is essentially defined [00:20:44 CEST] <nevcairiel> does anything even exist that doesnt use two's complement [00:20:46 CEST] <BBB> (its just that the c space doesnt know whether we are twos complement or not, so thats not helpful for auto-fuzzers) [00:21:00 CEST] <BBB> but the point is: by making it unsigned, we enforce twos complement behaviour anyway [00:21:04 CEST] <nevcairiel> (anything that matters, that is) [00:21:18 CEST] <BBB> treating signed overflows as unsigned, as our docs state, only works if you use twos complement [00:21:29 CEST] <BBB> otherwise its & implementation-defined! :) [00:21:36 CEST] <BBB> (i.e. undefined-but-not-insecure) [00:21:40 CEST] <BBB> so... [00:22:01 CEST] <BBB> why are we going through all this effort to make signed stuff unsigned and thus reflect c spec for non-twos complement, if that requires twos complement? [00:22:04 CEST] <BBB> I dont get it [00:22:29 CEST] <nevcairiel> I doubt any of these things have ever been actually security relevant, the argument people usually use is "its undefined, so the compiler might remove bounds checks since it was undefined!!!" [00:22:50 CEST] <BBB> as said, its undefined because of the requirement to work on non-twos complement [00:22:55 CEST] <BBB> within twos complement, it is very much defined [00:23:15 CEST] <BBB> but by making it unsigned, we require twos complement anyway [00:23:19 CEST] <BBB> so it sounds like one big fraud to me [00:23:24 CEST] <nevcairiel> it is [00:23:29 CEST] <BBB> (I know thats not nice, but I dont know how else to say it) [00:23:34 CEST] <nevcairiel> but someone has to pay security researches [00:23:34 CEST] <BBB> so then why do we do it? [00:23:39 CEST] <BBB> screw them [00:23:42 CEST] <BBB> the code gets very unclean [00:26:03 CEST] <BBB> by making it unsigned, we ensure that the code will not work on non-twos complement systems [00:26:17 CEST] <nevcairiel> i've never seen anyone actually use a real argument to support this, the best you get "its undefined behavior, which means anything can happen", which is just a cop-out [00:26:18 CEST] <BBB> by keeping it signed, we may actually be able to make it work on non-twos complement systems [00:27:02 CEST] <BBB> so it seems much better to me - not just for code quality, but also for portability - to re-read the c-spec within this subpart as implementation-defined, not undefined, because its obvious that thats what was intended [00:27:42 CEST] <BBB> the whole point of the c spec is to enable portability, and this particular piece basically does the exact opposite [00:32:33 CEST] <peloverde> C spec defines a >> b as implementation defined when a is less than 0. It defines a << b as undefined when a is less than 0. This is an asymmetry in the spec. [00:33:29 CEST] <BBB> I agree [00:35:29 CEST] <peloverde> so it's known broken behavior but the spec authors seem to be in no big hurry to fix it. [00:36:02 CEST] <BBB> I hate that were bending backwards to fix our codebase to comply with a known-broken spec [00:36:09 CEST] <BBB> and make our codebase less portable in the process [00:36:41 CEST] <BBB> (and ugly) [03:06:51 CEST] <iive> BBB: I guess you haven't read the llvm articles or any of the emails i've written. gcc have -fwrapv that "defines" signed overflow as wrapping. [03:07:11 CEST] <iive> (the emails on the subject). [03:40:23 CEST] <cone-516> ffmpeg 03Michael Niedermayer 07master:aeddb3607be9: avcodec/pixlet: Simplify nbits computation [03:40:23 CEST] <cone-516> ffmpeg 03Michael Niedermayer 07master:8e275a74b09c: avcodec/diracdec: Fix integer overflow in signed multiplication in UNPACK_ARITH() [05:22:13 CEST] <ElementalBlack> Where is the "unsharp" kernel function defined that's referenced on line 331 in unsharp_opencl.c (https://github.com/FFmpeg/FFmpeg/blob/master/libavfilter/unsharp_opencl.c#L… I don't see that function in the kernel header [05:30:18 CEST] <ElementalBlack> ah [05:30:25 CEST] <ElementalBlack> maybe in allkernels.c [05:57:04 CEST] <jamrial> ElementalBlack: pretty much nobody really knows the lavfi opencl code. it was submitted long ago and nobody has touched it since then [05:58:20 CEST] <ElementalBlack> jamrial: I figured it out, it's using av_stristr() to find the provided string in the kernel source. Seems like a weird way to do it, but it works. [08:44:17 CEST] <hanetzer> heyo. some questions regarding ffmpeg on mingw-w64. I'm using gentoo, amd64 glibc, and I've set up a cross toolchain that successfully crosscompiles a fair amount of libraries and programs without issue. the resultant binaries run on wine and windows 10. However, attempting to cross-compile ffmpeg fails for lack of detecting pthreads. this is version 3.3.2. Trying again and will post build logs. [08:49:55 CEST] <hanetzer> https://paste.pound-python.org/show/ranPsBZQC7nXKJCf34IG/ gentoo build.log [08:50:22 CEST] <hanetzer> https://paste.pound-python.org/show/JHFldMNA9lqD79WPlz15/ ffmpeg config.log [12:09:46 CEST] <ldts> michaelni: on V4L2 patchset: gst imports the necessary v4l2 headers to guarantee the builds wont break (since the kernel API wont break legacy code) that means importing: v4l2-common.h v4l2-controls.h videodev2.h into ffmpeg...is there are place in the tree where these files should go? (some ext/v4l2/ ? or should I just add them to libavcodec/?) [12:10:31 CEST] <ldts> michaelni: I am proposing to do just what gst does (ie bring the v4l2 header files into the ffmpeg tree) [13:00:36 CEST] <Mavrik> This is strange... if I move AVPacket from one thread (calling av_read_frame) to another (calling avcodec_decode_video2), I'm getting bunch of decoding errors in H.264. Are there thread safety issues with reference counted packets? [13:02:02 CEST] <ldts> michaelni: aballier : compat/v4l2/* [13:10:57 CEST] <nevcairiel> whats the point of that? its not like its actually going to run if the kernel doesnt have support [13:11:14 CEST] <nevcairiel> better to build against what is actually available [13:20:54 CEST] <ubitux> why do we still have that sdl dep? [13:21:06 CEST] <ubitux> it's causing me issues for the autodetect thing :( [13:21:45 CEST] <ubitux> is it just a shorthand? [13:25:53 CEST] <JEEB> :< [14:14:47 CEST] <ubitux> philipl: do you mind testing if crystalhd still work after the patch(set)? [14:25:58 CEST] <JEEB> didn't his hardware die regarding that? [14:26:07 CEST] <JEEB> I might be misremembering of course [14:34:14 CEST] <ubitux> arh, actually it seems i missed something in that patchset [14:43:18 CEST] <philipl> ubitux: I don't mind but I can't test until a week from now [14:43:38 CEST] <philipl> One my cards died. I still have one left :-) [15:05:34 CEST] <JEEB> ah, so you still have one left :D [15:51:19 CEST] <JEEB> are lavf stream indexes unique? [15:51:28 CEST] <JEEB> during a single input lavf context [15:52:11 CEST] <JEEB> as in, can I just put stream indexes into a list of "these I don't care about" and know that no new stream is going to get there [15:58:16 CEST] <nevcairiel> its only ever going to add new streams in an existing context [15:59:06 CEST] <JEEB> so effectively it wouldn't remove an indexed thing and re-add it [15:59:11 CEST] <JEEB> as another thing [15:59:22 CEST] <JEEB> (not that it would need since we have the positive side of int available) [16:32:01 CEST] <ZeroWalker> is this wrong? audio->frame->pts += audio->frame->nb_samples / (audFormat.Samplerate / 1000) ; [16:32:57 CEST] <iive> why the 1000? [16:33:13 CEST] <ZeroWalker> aren't you supposed to make it in ms? [16:33:57 CEST] <iive> no idea, but i know that there are things like timebase or something like that [16:35:31 CEST] <ZeroWalker> isn't the timebase supposed to be the same as samplerate/fps? [16:35:54 CEST] <iive> it usually is, to easy the calculations [16:36:37 CEST] <ZeroWalker> context->sample_rate = 48000; context->time_base = AVRational{ 1, context->sample_rate }; So i got this part right;p? [16:37:03 CEST] <iive> the problem above is that you are making a rounding error, quite bit at that. and in audio error accumulates easily. [16:37:39 CEST] <ZeroWalker> elaborate, how does it occur? [16:37:41 CEST] <iive> aka, it easies the calculations, so you just add the number of samples. [16:38:40 CEST] <iive> the logic is simple, you have e.g. 48000 samples, and timebase of 1/48000, so it makes 1second. [16:39:10 CEST] <iive> once again. i'm not familiar with this code, i'm just regargulating basic principles. I could be wrong. [16:39:28 CEST] <ZeroWalker> ah, so adding pts just tells it (48000 pts == 1 second) [16:39:42 CEST] <ZeroWalker> so as i have the same, i can just add samples [16:39:44 CEST] <iive> pts*timebase=time [16:39:49 CEST] <ZeroWalker> that makes sense [16:39:50 CEST] <ZeroWalker> ah [16:40:23 CEST] <ZeroWalker> hmm, well then it's probably not the timebase thing that messes up the audio for me, guess it's the resampling as it worked fine without it. Was sure i had the resampling working -_- [16:49:08 CEST] <ZeroWalker> or maybe not, the audio time is super long compared to what it should be xd [18:10:48 CEST] <Blubberbub_> ZeroWalker, it might be possible, that your output expects a different time_base than 1/samplerate, though [18:11:01 CEST] <Blubberbub_> then you cannot do PTS += nb_samples [18:13:08 CEST] <ZeroWalker> how would i determine that? [18:13:20 CEST] <Blubberbub_> i learned that from afade [18:13:30 CEST] <ZeroWalker> afade? [18:13:37 CEST] <Blubberbub_> filter in libavfilter [18:13:44 CEST] <ZeroWalker> ah [18:14:14 CEST] <Blubberbub_> there is this av_rescale_q-method(or something like that) that is used there [18:22:43 CEST] <ZeroWalker> ah yeah seen that, but i don't think i am supposed to use it as as the encoder and the frame has the same samplerate [18:30:12 CEST] <PaoloP> Hello. It seems that the mpegts muxer wants TWO adts-aac frames (av_write_frame()), before producing output. Do you know why? [20:22:28 CEST] <J_Darnley> atomnuker: would you be kind enough to look at this when you have time [20:22:29 CEST] <J_Darnley> https://pastebin.com/xfptY2v1 [20:23:06 CEST] <J_Darnley> and tell me whether you think that looks correct for the legall 5_3 transform? [20:26:16 CEST] <J_Darnley> I tried to remove the edge handing from your transforms [20:27:03 CEST] <J_Darnley> but I get left with a dark or black sample in the last of each row and column of a slice [20:32:24 CEST] <JEEB> ubitux: gj with the patch set [20:32:45 CEST] <atomnuker> BBB: oh wow tile threading [20:33:00 CEST] <atomnuker> any performance comparisons yet? [20:33:19 CEST] <JEEB> oh, cool [20:37:42 CEST] <nevcairiel> the real question is if you can saturate your cpu with frame threading, because if you can all you might gain is reduced latency [20:38:16 CEST] <JEEB> yea [20:39:06 CEST] <BBB> no, its not bitexact yet [20:39:11 CEST] <BBB> loopfilter still to be done [21:29:11 CEST] <ubitux> JEEB: thx :) [21:29:16 CEST] <ubitux> iconv still needs fixing tho [21:37:33 CEST] <PaoloP> Hello. It seems that the mpegts muxer wants TWO adts-aac frames (av_write_frame()), before producing output. Do you know why and/or if is there a way to avoid this buffering? [21:50:57 CEST] <ZeroWalker> is there some good site where i can upload a test file to provide here. I would like to have help diagnosing what the issue is with my audio encoding, or if it's timing or something. It works fine with having it in PCM with just writing directly. But resampling/FIFO causes issues, and i can't figure out what [22:17:56 CEST] <BBB> is someone here familiar enough with pkg-config to review "configure: require pkg-config for libvmaf"? [22:18:18 CEST] <BBB> I dont understand that kind of stuff and there were some comments about it earlier, so Id like to make sure that resolves all the issues with the configure-part of this feature [22:31:45 CEST] <ZeroWalker> when adding a stream, are you supposed to copy the parameters of the already initialized codec to that stream or something, or is just avformat_new_stream enough? [22:35:47 CEST] <BBB> I thought avcodec was supposed to be invisible to the avformat layer, and sharing of such parameters was supposed to be done using avcodecparameters? [22:37:04 CEST] <ZeroWalker> well i have been doing that, by using avcodec_parameters_from_context [22:37:21 CEST] <ZeroWalker> not sure where i got that from, but i guess i reached the same conclusion [22:37:35 CEST] <ZeroWalker> but i see examples that handle it differently, so a bit confused [22:38:01 CEST] <BBB> the examples may be old :-/ [22:39:32 CEST] <ZeroWalker> true [22:41:08 CEST] <ZeroWalker> but trying to fix my damn timing errors. and i think it actually might be something with this. Cause i think it ignored the timebase i set on my codec, it seems to follow a "1/1000" timebase, and that's what the streams seems to default to after av_write_header, for some reason, but it feels like it should already be set in by then [22:42:51 CEST] <Blubberbub_> do you set a time_base on your output stream? [22:43:23 CEST] <Blubberbub_> because you need to do that. [22:46:01 CEST] <ZeroWalker> not sure what that means so probably not [22:46:19 CEST] <ZeroWalker> i thought the stream is basically the codec, so it used that timebase [22:47:48 CEST] <Blubberbub_> well - i had that problem when writing a demuxer, that i did avformat_new_stream in read_header and something was weird with timings. Turned out that i had to set (AVStream *)->time_base to (AVRational){1, sample_rate} [22:49:44 CEST] <JEEB> yea some containers have hardcoded time bases and in other cases you can set it yourself [22:50:22 CEST] <ZeroWalker> http://paste.awesom.eu/YGRs [22:50:28 CEST] <ZeroWalker> well i tried to do something like this [23:00:42 CEST] <Blubberbub_> time_base is not uninitialized, like it was in my case, i guess [23:04:22 CEST] <ZeroWalker> well i am just more confused xd [23:06:03 CEST] <Blubberbub_> but didn't you calculate the PTS yourself? Maybe the time_base from the codec is not 1/sample_rate, like you assume in your pts-code? [23:11:20 CEST] <ZeroWalker> but i set my time_base manually, so shouldn't it be that;s [23:21:04 CEST] <Blubberbub_> i have no idea - and probably only confuse you even more with my attempts :( [23:27:31 CEST] <ZeroWalker> it's probably super simple but i just can't see it xd [23:27:48 CEST] <ZeroWalker> not that used to the ffmpeg API so find many thing confusing. [23:28:41 CEST] <ZeroWalker> But well this might also be why the bitrate i set on the video is all messed up, it doesn't follow it at all. But that might also be cause it's VFR (which is set by milliseconds, which seems to work, but it shouldn't as it should be fps timebase:S) [23:48:02 CEST] <ZeroWalker> okay when calling avcodec_receive_packet, do you have to used a cleared AVPacket? [23:48:29 CEST] <ZeroWalker> http://paste.awesom.eu/GHOo [00:00:00 CEST] --- Sat Jul 29 2017

1 0

ffmpeg.log.20170728
by burek 29 Jul '17

29 Jul '17

[03:15:44 CEST] <Tatsh> so [03:15:58 CEST] <Tatsh> if you have a source for h264 that has constqp, vbr, or cbr which should you use? [03:16:03 CEST] <Tatsh> what's best? [03:17:05 CEST] <c_14> the one that looks best [03:24:44 CEST] <furq> i mean probably not the cbr one but it depends what the bitrate is [03:24:52 CEST] <furq> so basically what c_14 said [03:25:01 CEST] <furq> he is truly wise [04:34:38 CEST] <ElementalBlack> is there some sort of external library required for png output support? [04:34:58 CEST] <furq> no [04:35:38 CEST] <ElementalBlack> not sure why I'm getting "Automatic encoder selection failed for output stream #0:0. Default encoder for format image2 (codec png) is probably disabled. Please choose an encoder manually." then [04:35:47 CEST] <ElementalBlack> is it version 3 gpl? [04:36:09 CEST] <furq> all the internal decoders and encoders are lgpl [04:36:18 CEST] <furq> so unless you specifically disabled it, it should be there [04:36:57 CEST] <ElementalBlack> I'm not disabling it... [04:37:13 CEST] <furq> pastebin the output of ffmpeg -version [05:18:28 CEST] <kepstin> i think the png encoder requires zlib? so if you build your own ffmpeg and don't have the zlib dev stuff available, it could be missing [05:52:48 CEST] <hanna> Is it normal that seeking on HEVC files produces a bunch of corrupt garbage (mostly grey) until I let it play for about a second? [05:53:05 CEST] <hanna> It also seems like there's a regression, in the past, when I framestepped backwards it would always give me a correct frame again [05:53:16 CEST] <hanna> but now I also get garbage even when framestepping backwards from a garbage frame [05:54:00 CEST] <hanna> Actually not all HEVC files [05:55:02 CEST] <hanna> Hmm I think it only happens for MPEGTS [05:55:59 CEST] <hanna> Yeah works fine after transcoding to matroska [05:56:01 CEST] <hanna> I'll just do that from now on [05:58:20 CEST] <kepstin> what player? [05:58:43 CEST] <kepstin> it should work on any format where recovery frames are correctly marked, and it'll usually work better in formats with seek indexes (like matroska) [05:59:33 CEST] <hanna> kepstin: mpv [09:16:48 CEST] <lindylex> why is this not using my font? ffmpeg -i zoom1920.mp4 -vf "drawtext='fontfile=.\fonts\SoulMission.ttf':text=#MOTIONDESIGNSTUDIO FAILED:fontcolor=0xFFFFFFFF:fontsize=99:x=20:y=10: #shadowcolor=0x000000EE:shadowx=2:shadowy=2" -c:v libx264 -preset slow -crf 18 -c:a copy -pix_fmt yuv420p -y zover.mp4 It defaults to [Parsed_drawtext_0 @ 0x5599f67e5140] Using "/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf" [09:43:16 CEST] <luc4> Hello! I have a weird video file here that ffprobe reports being of size 854x480 [SAR 1280:1281 DAR 16:9]. Now I understand the resolution is 854x480, but any idea why SAR is 1280:1281? Why should someone declare the size of the frame with a size different from the resolution of the video stream? [13:41:31 CEST] <nahsi> how do I change DAR (display aspect ratio) of a video stream in mkv container? The original dimension is 1440x1080 but aspect ratio is 16:9. Tried mkvtoolnix but it creates 'Original display aspect ratio' and when I upload video to youtube it's 16:9 not 4:3. How can I completely erase any info on aspect ratio from a container? Tried also extract just a plain avc stream and repack it - didn't work [13:49:15 CEST] <mickie> Hi All, I can't get mpv to show subtitles ... I used ffmpeg with '-codec:s dvb_subtitle -metadata:s:s:0 language=eng' providing the video and .srt files as inputs. Am I missing some option from ffmpeg? [13:49:55 CEST] <nahsi> >dvb_subtitle that is not correct [13:50:02 CEST] <nahsi> use mkvmerge [13:50:33 CEST] <mickie> I am trying to convert the stream to .rec which is a Topfield mpeg2 format. [13:51:43 CEST] <mickie> All .rec files have the subtitles defined as a 'Subtitle: dvb_subtitle' format [13:52:04 CEST] <mickie> I'll look into mkvmerge to see if this will do [13:52:09 CEST] <mickie> Thanks nahsi [13:52:15 CEST] <nahsi> No-no mkvmerge will only merge [13:52:23 CEST] <mickie> Ah! [13:52:29 CEST] <nahsi> You need to convert right? I'm googling right now [13:52:47 CEST] <mickie> Yes I need to convert from srt to dvd_subtitle format [13:53:07 CEST] <mickie> This is why I used the syntax I posted just now. [13:54:06 CEST] <mickie> ffprobe shows the subtitle stream as it should be, similar to other .rec files, but mpv won't display it. :( [13:54:54 CEST] <nahsi> Is you mpv is built with dvb support? [13:55:00 CEST] <rev0n> I was wondering if any of you know how I can "repair" chunks of webm video generated by getUserMedia() with MediaStreamRecorder API. FFMPEG has problem reading the chunks, and when I tried mkvalidator (for validating webm files) I got such errors: https://pastebin.com/tiG9w3qT [13:55:30 CEST] <mickie> Hmm ... too obvious - why didn't I check before? [13:55:42 CEST] <mickie> Ha! No it is not built with dvd support! [13:56:27 CEST] <mickie> However, playing .rec files with this same mpv shows their subtitles fine. Only my converted file won't show any. [13:58:47 CEST] <nahsi> try -c:s dvbsub ? [13:58:48 CEST] <mickie> I'll convert the .ts file to .rec with the ProjectX java application I use for this purpose and see what gives. [13:59:00 CEST] <mickie> Thanks nahsi, will do. [13:59:04 CEST] <nahsi> np [14:01:29 CEST] <mickie> Same thing happens. mpv or vlc recognise the subtitles stream and allow me to enable it, but they won't display it. :-/ [14:04:12 CEST] <mickie> Hmm ... vlc shows some vdpau_display vout errors. Not sure if it is a red herring [14:04:44 CEST] <mickie> something about 'VdpVideoSurface of a different size' [14:05:11 CEST] <mickie> Thanks again, need to run. [15:37:28 CEST] <zetax> has ffmpeg some issue with opus audio conversation? result sounds horrible, vorbis is fine. [15:37:46 CEST] <DHE> did you specify a good quality or bitrate setting? [15:38:05 CEST] <zetax> just standard quality 5 on vbr [16:23:34 CEST] <kepstin> opus doesn't have a 'quality' setting [16:26:51 CEST] <kepstin> that said, the default setting for opus is 96kbps vbr, which should sound quite good [16:27:39 CEST] <kepstin> (obviously you want to make sure you have the latest libopus too, since there's quality improvements in each version) [16:31:55 CEST] <iive> ffmpeg have internal opus encoder, too. [16:39:05 CEST] <kepstin> yeah, but using libopus is recommended for the time being. The internal encoder's still marked experimental, even [16:40:08 CEST] <zack_s_> how can I convert a 3D video to 2D? [16:40:18 CEST] <zack_s_> its a top-bottom videos [16:40:20 CEST] <furq> close one eye [16:40:31 CEST] <kepstin> zack_s_: crop it [16:40:53 CEST] <kepstin> I mean, the internal opus encoder works, and it is *faster* than libopus, and at sufficient bitrates it sounds fine. [16:41:04 CEST] <furq> !filter stereo3d @zack_s_ [16:41:04 CEST] <nfobot> zack_s_: http://ffmpeg.org/ffmpeg-filters.html#stereo3d [16:41:07 CEST] <c_14> zack_s_: use the stereo3d filter with ml or mr as out format [16:41:12 CEST] <furq> ^ [16:41:36 CEST] <furq> although i don't see what benefit that has over cropping [16:42:19 CEST] <c_14> eeeeeh [16:42:22 CEST] <c_14> more complicated = better ? [16:42:27 CEST] <furq> this is true [16:44:32 CEST] <furq> zack_s_: also if this is a vr video and you want to map it to a 2d plane, then i don't think ffmpeg does that [16:44:52 CEST] <zack_s_> its a 3d video [16:44:55 CEST] <zack_s_> no vr [16:44:58 CEST] <furq> ok good [16:48:17 CEST] <zack_s_> ffmpeg -i input.mkv -vf stereo3d=abl output.mkv [16:48:24 CEST] <zack_s_> this seems to work [16:48:48 CEST] <zack_s_> but why does it make it the video to 2d? [16:48:54 CEST] <zack_s_> where is the command for that? [16:49:09 CEST] <zack_s_> and I am not satisified with the encoding profile used, different then input [16:49:24 CEST] <zack_s_> and the bitrate and so on [16:50:41 CEST] <zack_s_> furq: ? [16:51:40 CEST] <furq> er [16:51:48 CEST] <furq> that command will convert to arcd [16:51:57 CEST] <furq> also you didn't provide any encoder settings so it's using the defaults for mkv [16:52:33 CEST] <zack_s_> I have an mp4 video [16:52:35 CEST] <zack_s_> as input [16:52:51 CEST] <zack_s_> how to I specifiy that the input encoding profile is used as output encoding profile? [16:52:54 CEST] <zack_s_> furq: ? [16:59:05 CEST] <kepstin> by profile you mean https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Profiles - like, restrictions so it'll play on particular devices? [16:59:33 CEST] <kepstin> just set it yourself, if you want to apply restrictions on the output, there's nothing to 'copy' it. [17:00:45 CEST] <kepstin> but you obviously also need to set bitrate and quality settings as appropriate, "copying" them doesn't make sense. [17:05:16 CEST] <zack_s_> kepstin: I want all input settings, also be the output settings [17:05:24 CEST] <zack_s_> the encoding profile [17:05:37 CEST] <zack_s_> such as level, bitrate, GOP [17:05:38 CEST] <kepstin> but that doesn't make sense, you're removing half the video and maybe even using a different encoder [17:05:39 CEST] <zack_s_> and so one [17:06:00 CEST] <zack_s_> I convert a 3D mp4 video to 2D mp4 video [17:06:52 CEST] <kepstin> yes, so now you need to do a new encoder of this now significantly modified video - so you have to pick new settings that are appropriate for how you want to use the result. [17:07:52 CEST] <zack_s_> okay, so it doesnt work with ffmpeg [17:08:10 CEST] <zack_s_> anyway, setting everything again manually, I start with the profile: ffmpeg -i input.mkv -vf stereo3d=abl -profile:v high -level 4.1 output.mkv [17:08:13 CEST] <zack_s_> doesnt work [17:08:23 CEST] <zack_s_> "Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height" [17:08:48 CEST] <kepstin> there should be an earlier line in the output saying exactly what is wrong [17:11:43 CEST] <kepstin> but you're also not setting any bitrate or quality settings in that command line, so you're going to get the defaults, which are kind of ... mediumish. [17:12:48 CEST] <zack_s_> fflogger: https://paste.ee/p/i0cPg#Wr7miFkisqF9qMEh8JCwXXUf9TotKs47 [17:14:53 CEST] <kepstin> huh, weird, the stereo3d filter must have converted that do a different pixel format [17:15:13 CEST] <kepstin> really, try just using crop instead, if it's above/below. [17:15:57 CEST] <kepstin> alternatively, add "-pix_fmt yuv420p" output option to make it reconvert back to a pixel format allowed in the h264 profile you picked (this will be slower). [17:17:20 CEST] <zack_s_> kepstin: do you have a command, how to use crop? [17:19:13 CEST] <kepstin> if your input is above/below, and you want the output to be 1080p, this should work: "-vf crop=1920:540,scale=1920:1080" [17:20:43 CEST] <zack_s_> kepstin: na doesnt work [17:20:51 CEST] <zack_s_> the output is one eye [17:20:55 CEST] <zack_s_> but it is cut in half [17:21:27 CEST] <zack_s_> its displaced [17:22:08 CEST] <kepstin> lets see, you say 'stereo3d=abl' works? [17:22:13 CEST] Action: kepstin looks up what that does [17:22:52 CEST] <zack_s_> yes [17:22:55 CEST] <zack_s_> this worked [17:23:44 CEST] <kepstin> ... I don't think that does what you think it does. "setereo3d=abl" turns above/below content into anaglyph red/cyan [17:24:36 CEST] Action: kepstin is kind of surprised that the crop didn't work, but he hasn't seen the actual video you have, so... [17:26:09 CEST] <kepstin> the command output says the input is 1920x1080 with sar 1:2, so that should be correct :/ [17:27:32 CEST] <kepstin> that said, you can also try doing -vf stereo3d=abl:ml [17:27:47 CEST] <kepstin> which might avoid the color space issue, since it won't do the anaglyph conversion [17:31:39 CEST] <zack_s_> kepstin: now I can set the level 4.1 [17:32:59 CEST] <zack_s_> kepstin: how can I set the bitrate? [17:33:09 CEST] <fred1807> can ffmpeg interpret 4m02s ? [17:33:28 CEST] <fred1807> or just 00:04:02 [17:33:29 CEST] <kepstin> fred1807: no, that's not a supported time format for any of the options [17:34:11 CEST] <kepstin> zack_s_: do you actually need a specific bitrate? with x264 encoder, it's usually better to set a -crf value instead to get a single-pass constant quality encode. [17:34:40 CEST] <kepstin> (the default is -crf 23, i think; use a lower value to get higher quality) [17:35:02 CEST] <kepstin> most people consider around -crf 18 and below to be difficult to distinguish from the input [17:35:59 CEST] <zack_s_> kepstin: why is crf better then settings constant bitrate? [17:36:23 CEST] <kepstin> zack_s_: because with constant bitrate, the quality changes over time depending on how 'hard' each frame is to encode [17:37:15 CEST] <kepstin> (the workaround to this is to do a 2-pass encode instead - but with crf you only need 1 pass) [17:38:17 CEST] <zack_s_> kepstin: ahh crf is a variable bitrate [17:40:02 CEST] <kepstin> also note that x264 defaults to using "-preset medium" - you can get smaller files/better quality by using a slower preset (e.g. "-preset veryslow") instead, but the encode will take longer. [17:40:24 CEST] <kepstin> or, the opposite, use a faster preset if you need it done sooner and don't mind bigger files :) [17:40:28 CEST] <zack_s_> kepstin: can ffmpeg use also hardware encoding? [17:40:48 CEST] <zack_s_> with intel hardware for example? [17:41:03 CEST] <kepstin> yes, but you should only do that if your cpu is way too slow or if you're e.g. screen capturing a game or something [17:41:16 CEST] <zack_s_> how can I do it? [17:41:17 CEST] <kepstin> the hardware encoders generally have lower quality than software encoders [17:42:59 CEST] <kepstin> what os? [17:43:25 CEST] Action: kepstin notes that getting the intel hw encoder working is sometimes a bit of a pain on linux, and he has no idea how to do it on windows. [17:43:40 CEST] <zack_s_> kepstin: windows [17:43:48 CEST] <kepstin> not worth the trouble to get lower quality encodes, in general :/ [17:47:37 CEST] <zack_s_> kepstin: adding -h encoder=h264_qsv [17:47:41 CEST] <zack_s_> seems not to work [17:49:02 CEST] <zack_s_> ok I am out [17:49:06 CEST] <zack_s_> kepstin: bye [17:49:13 CEST] <zack_s_> thanks for the help [17:49:44 CEST] <hexhaxtron> Can I convert 3D MKV to MP4? [17:50:00 CEST] <fred1807> I am having a strange issue with a bash script and ffmpeg. I have this video that I can command ffmpeg -i input.mp4 -c copy -ss 00:00:24 -t 00:04:34 output.mp4 without any problem. But when I run this command inside a bash script, I am getting error: Invalid duration specification for t: 00:04:34 [17:50:34 CEST] <fred1807> the duration is not invalid, because I can command this on this same video [17:50:57 CEST] <fred1807> this error only happens when inside a bash script (the duration is passed as a argument, but it is the same duration) [18:04:23 CEST] <kepstin> fred1807: it's probably a syntax or escaping issue in your script then :/ not really something we can help with unless we can see it. [18:06:12 CEST] <tdr> [18:12:55 CEST] <PaoloP> Hello. It seems that the mpegts muxer wants TWO adts-aac frames (av_write_frame()), before producing output. Do you know why? [18:13:16 CEST] <PaoloP> and if it's a way to reduce that to one frame... [18:17:44 CEST] <PaoloP> and if is there a way to reduce that to one frame... [18:42:25 CEST] <rev0n> Anyone had issues piping data to ffmpeg? [18:45:41 CEST] <Blubberbub_> what kind of issues? [18:48:14 CEST] <rev0n> I get webm chunks from user with getUserMedia() (js), and send them to Python tornado server. When I try to pipe the data to ffmpeg I get bunch of errors, ffmpeg looks like stuck. When I write binary data from the socket to a file with file.write() I can successfully convert the video to any format. Which does not work while piping. It's exact same data! [19:02:44 CEST] <Blubberbub_> are you sure there is no additional data piped to ffmpeg? [19:03:05 CEST] <Blubberbub_> so compare to what happens if you pipe to a file isntead of using file.write [19:19:18 CEST] <ioan> hi. Is there a way to save a rtsp stream localy AND break it in ... multiple files (by time or by size)? [19:30:05 CEST] <DHE> there is a `tee` muxer that could split it into multiple outputs [19:30:50 CEST] <ioan> I found the answer on stackoverflow, I'm trying it right now [19:32:10 CEST] <ioan> actually on superuser and it works: ffmpeg -i rtmp://source.com/live/stream -c copy -flags +global_header -f segment -segment_time 60 -segment_format_options movflags=+faststart -reset_timestamps 1 test%d.mp4 [19:40:23 CEST] <DHE> oh, I thought you wanted a split version and a solid version at the same time... [19:41:28 CEST] <rev0n> Blubberbub_: it looks like there's no additional data. Not sure why there would be [20:01:45 CEST] <mickie> Hi All, I've been trying to convert an mp4 containing h264 video and aac audio into a ts container with mpeg2 video and mp2 audio. I also have subtitles in a .srt (subrip) file. I am not sure how I can embed the .srt subtitles into a dvbsub format. [20:02:10 CEST] <mickie> Do I need to use overlay? [20:02:45 CEST] <kepstin> I thought dvbsub was a teletext format, not image-based. [20:02:49 CEST] <Blubberbub_> overlay sounds like embedding the subtitles directly into the video stream, which si not what you want? [20:03:10 CEST] <mickie> Right, I want a separate stream with the subtitles in it. [20:03:17 CEST] <kepstin> It should in theory be as simple as setting -c:s dvbsub but I dunno if ffmpeg actually supports that. [20:03:44 CEST] <kepstin> er, wait, no, it is an image based format [20:03:46 CEST] <kepstin> never mind [20:03:57 CEST] <mickie> That's what I've tried ... but it didn't work when I tried to convert the .ts file to a .rec file using ProjectX [20:04:28 CEST] <mickie> ProjectX ignored the stream which had the dvbsub in it. [20:04:49 CEST] <mickie> ALso, mpv/vlc do not show subtitles from the dvbsub stream [20:05:04 CEST] <lindylex> why is this not using my font? ffmpeg -i zoom1920.mp4 -vf "drawtext='fontfile=.\fonts\SoulMission.ttf':text=#MOTIONDESIGNSTUDIO FAILED:fontcolor=0xFFFFFFFF:fontsize=99:x=20:y=10: #shadowcolor=0x000000EE:shadowx=2:shadowy=2" -c:v libx264 -preset slow -crf 18 -c:a copy -pix_fmt yuv420p -y zover.mp4 It defaults to this and ouputs this error >>> [Parsed_drawtext_0 @ 0x5599f67e5140] Using "/usr/share/fonts/truetype/dejavu/DejaVuSans.tt [20:05:04 CEST] <lindylex> f" [20:05:39 CEST] <kepstin> lindylex: what os are you using? [20:05:44 CEST] <lindylex> Linux [20:05:56 CEST] <kepstin> so, change the \ to a / [20:06:22 CEST] <kepstin> on linux, \ is either a special escape character or normal character, it's not a path separator... [20:07:47 CEST] <lindylex> kepstin: sorry I knew this Imust have been experimenting, I still get the same error. When I use this >>> ffmpeg -i zoom1920.mp4 -vf "drawtext='fontfile=./fonts/SoulMission.ttf':text=#MOTIONDESIGNSTUDIO FAILED:fontcolor=0xFFFFFFFF:fontsize=99:x=20:y=10: #shadowcolor=0x000000EE:shadowx=2:shadowy=2" -c:v libx264 -preset slow -crf 18 -c:a copy -pix_fmt yuv420p -y zover.mp4 [20:08:00 CEST] <lindylex> Or this ffmpeg -i zoom1920.mp4 -vf "drawtext=fontfile=/usr/share/fonts/truetype/SoulMission.ttf:text='#MOTIONDESIGNSTUDIO FAILED':fontcolor=0xFFFFFFFF:fontsize=99:x=20:y=10: #shadowcolor=0x000000EE:shadowx=2:shadowy=2" -c:v libx264 -preset slow -crf 18 -c:a copy -pix_fmt yuv420p -y zover.mp4 [20:12:59 CEST] <kepstin> hmm, not sure why that wouldn't be working, unless for some reason fontconfig can't understand the font file format or something [20:13:14 CEST] <kepstin> have you confirmed the font works in other applications? [20:13:34 CEST] <kepstin> also consider installing it then loading it by name with the "font=" parameter, which will use fontconfig [20:16:45 CEST] <mickie> OK, I've tried this: "ffmpeg -i My_video.ts -i My_video.srt -target pal-dvd -aspect 16:9 -codec:a mp2 -ar 48000 -b:a 256k -codec:s dvbsub -metadata:s:s:0 language=eng test.ts" but the subtitles in mpv are not recognised. ffprobe shows: "Stream #0:0[0x1bf]: Data: dvd_nav_packet, Stream #0:1[0x1e0]: Video: mpeg2video (Main)[snip...], Stream #0:2[0x1c0]: Audio: mp2[snip...], Stream #0:3[0x20]: Subtitle: [20:16:51 CEST] <mickie> dvd_subtitle". [20:17:16 CEST] <mickie> Then mpv/vlc show Subtitle:no [20:17:19 CEST] <mickie> :( [20:19:58 CEST] <kepstin> lindylex: I downloaded the font you're using, installed it, and it worked perfectly in ffmpeg for me with the option "font=SoulMission" [20:20:11 CEST] <kepstin> if you've put it into /usr/share/fonts, that should be sufficient. [20:32:58 CEST] <lindylex> kepstin: I can use the font in Libre Office. [20:33:38 CEST] <lindylex> Are thinking something like this? [20:33:39 CEST] <lindylex> ffmpeg -i zoom1920.mp4 -vf "drawtext='fontfile=SoulMission':text=#MOTIONDESIGNSTUDIO FAILED:fontcolor=0xFFFFFFFF:fontsize=99:x=20:y=10: #shadowcolor=0x000000EE:shadowx=2:shadowy=2" -c:v libx264 -preset slow -crf 18 -c:a copy -pix_fmt yuv420p -y zover.mp4 [20:35:07 CEST] <lindylex> kepstin: This worked ffmpeg -i zoom1920.mp4 -vf "drawtext='font=SoulMission':text=#MOTIONDESIGNSTUDIO FAILED:fontcolor=0xFFFFFFFF:fontsize=99:x=20:y=10: #shadowcolor=0x000000EE:shadowx=2:shadowy=2" -c:v libx264 -preset slow -crf 18 -c:a copy -pix_fmt yuv420p -y zover.mp4 [20:35:12 CEST] <lindylex> Thanks [20:44:56 CEST] <Blubberbub_> is someone familiar with the "silenceremove" filter? Because to me it looks like it does not do what it documentation says it does... [21:21:10 CEST] <momomo> what is the best way to test a stream? if it works or not? ffmpeg or some other tool? [21:22:37 CEST] <JEEB> ffprobe is usually pretty good for basic "is there anything in the input?" kind of testing [21:23:25 CEST] <momomo> JEEB: Ok, I see the output format differs from the ffmpeg output format when you initially connect to a stream [21:23:47 CEST] <JEEB> you can specify an expected output format for parsing with of [21:23:48 CEST] <momomo> That would potentially force us to parse the output twice [21:23:50 CEST] <JEEB> -of json for json [21:23:57 CEST] <momomo> JEEB: nice let me try [21:25:33 CEST] <momomo> cool! [21:27:41 CEST] <momomo> When connecting with ffmpeg, you've get an initial output. Is there a way to get that in a particularly parsable format? [21:28:29 CEST] <momomo> Here is the output for ffprobe in json: https://hastebin.com/zojecoduru.json [21:28:40 CEST] <momomo> Here is the output using ffmpeg connection: https://hastebin.com/uraxukisol.md [21:28:52 CEST] <momomo> For ffmpeg output, ignore the initial nubmers up to colon : [21:29:13 CEST] <JEEB> what "initial output"? [21:29:43 CEST] <momomo> JEEB: when yoou connect .. see the second link: https://hastebin.com/uraxukisol.md [21:29:50 CEST] <momomo> It contains data about the stream [21:29:54 CEST] <JEEB> no I mean which part [21:30:02 CEST] <JEEB> because you can ask for various things from ffprobe [21:30:22 CEST] <JEEB> and a lot of the stuff about the /input/ is already there [21:30:28 CEST] <momomo> Here is what I am running: ffprobe -v error -show_format -of json -show_streams paht/to/url [21:30:57 CEST] <JEEB> no I mean what do you /want/ from that thing rather than what you have now [21:32:43 CEST] <momomo> Whatever good I can get. Ideally, later on, since some streams would contain multiple language files, i would like to download them separately .. i think you the data before you make the initial connection [21:32:50 CEST] <JEEB> no, I mean what are you missing? [21:32:51 CEST] <momomo> as of now, I just do -map 0:a:0 -map 0:v:0 [21:32:58 CEST] <JEEB> because you clearly noted that something's missing, no? [21:33:02 CEST] <JEEB> by linking the ffmpeg output [21:33:57 CEST] <PaoloP> Hello. It seems that the mpegts muxer wants TWO adts-aac frames (av_write_frame()), before producing output. Do you know why and/or if is there a way to avoid this buffering? [21:33:58 CEST] <momomo> JEEB: I am just saying they have different outputs. I can't afford to run ffprobe prior to ffmpeg everytime since that will slow things down, so rather I would like to be able to update the once a day run ffprobe generated data as I connect to ffmpeg [21:34:19 CEST] <JEEB> momomo: sounds like you rather want to write a custom app using the APIs then [21:34:28 CEST] <JEEB> if you need some specific data etc [21:34:31 CEST] <momomo> So I'd like to see a coherent consistent looking output [21:34:44 CEST] <momomo> Well, the output fromm ffprobe is good [21:34:45 CEST] <JEEB> ffmpeg.c command line output is not meant for parsing. QED [21:35:26 CEST] <JEEB> so yea, sounds like sooner than later you will want a custom API client that provides you exactly what you want [21:35:32 CEST] <momomo> JEEB: is there a way to run ffbropbe at the same time to get the output without incurring potential additional connection costs ? [21:35:41 CEST] <momomo> "custom api client" ? [21:35:57 CEST] <JEEB> something that utilizes the FFmpeg API libraries (libav*) [21:36:12 CEST] <JEEB> that way you can get exactly what you need without opening additional connections or anything else [21:36:25 CEST] <momomo> ooh , damn .. is that complex to pull off ? [21:36:28 CEST] <JEEB> no [21:36:44 CEST] <JEEB> docs/examples has examples and then you just start setting your own logic [21:37:02 CEST] <JEEB> I find it generally makes more sense to make a proper API client for your use case then hacking around [21:37:15 CEST] <momomo> do you know if there similar tools/plugins available already? althouhg i like the idea of taking control [21:37:17 CEST] <JEEB> I do also agree that ffmpeg.c lets you get scary far [21:38:10 CEST] <JEEB> momomo: a whole massload of apps or libraries use libav* libraries in the background but I'm not sure if anything is doing exactly what you need [21:38:59 CEST] <momomo> any direct link I can start looking, ffmpeg.c is ? [21:39:48 CEST] <JEEB> ffmpeg.c is the command line application (which is also an API client) [21:40:09 CEST] <JEEB> docs/examples under the FFmpeg git repository is where the various examples reside [21:46:21 CEST] <momomo> JEEB: thanks, i look into that. that code looks like a nightmare for someone not familiar with the base libraries :( [21:46:45 CEST] <JEEB> momomo: ffmpeg.c is a nightmare, yes [21:47:03 CEST] <JEEB> it's a pile of hacks on top of hacks and an immense amount of variable functionality [21:47:15 CEST] <JEEB> what you should instead do is look at the examples [21:47:24 CEST] <JEEB> since what you need is a thing that does one thing and one thing well [21:47:40 CEST] <Blubberbub_> i would say: one problem with trying to understand ffmpeg.c is, that one has to first know that a lot of functionality is actually in different files :D [21:47:47 CEST] <JEEB> that too [21:47:53 CEST] <JEEB> demux_decode being the first thing and transcoding example being another [21:48:01 CEST] <JEEB> I'd rather look at those and starting to play with the libraries [21:48:20 CEST] <JEEB> first you learn how to open your input and then you learn to read packets [21:48:27 CEST] <JEEB> and then you start decoding those packets into frames [21:48:29 CEST] <JEEB> etc etc [23:28:12 CEST] <momomo> is there a "quickest" way to execute ffprobe? like if asking for minimal amount of data, would result in faster response? [23:33:05 CEST] <JEEB> probe- and analyzeduration are a thing [23:55:25 CEST] <momomo> Thanks, I'll look into that [00:00:00 CEST] --- Sat Jul 29 2017

1 0

ffmpeg-devel.log.20170727
by burek 28 Jul '17

28 Jul '17

[00:02:01 CEST] <cone-864> ffmpeg 03Michael Niedermayer 07master:5d0b69f3b7e5: avcodec/jpeg2000dec: Fix h/vden typo [00:50:37 CEST] <atomnuker> michaelni: take a look at CID1415718, this looks alot like a false positive but I'm not sure [00:51:49 CEST] <atomnuker> nevermind, its not [00:56:18 CEST] <cone-864> ffmpeg 03Rostislav Pehlivanov 07master:133dafe24fc7: pngdec: fix potential memory leak [00:57:55 CEST] <atomnuker> COVERITY YOU PIECE OF SHIT [00:58:18 CEST] <atomnuker> last commit fixes CID1415718, not the one in the comment [00:59:01 CEST] <atomnuker> whoever designed the interface can burn in their own special excel-styled hell [01:00:45 CEST] <atomnuker> going on their crappy website is 99.9% of the work one has to do to mark a bug as fixed [01:02:23 CEST] <atomnuker> if they didn't have email notifications I wouldn't be able to fix anything because seeing all issues at once is impossible [01:03:56 CEST] <atomnuker> I did it once I think, I think I had to prove riemann's hypothesis and then once I viewed all I had to be brainwashed to forget the solution [01:26:43 CEST] <BBB> lol [01:26:52 CEST] <BBB> atomnuker: calm down dude [01:26:56 CEST] <BBB> theres worse things in the world [01:27:04 CEST] <BBB> I know thats a poor mans defense [01:27:06 CEST] <BBB> but its okay [02:26:45 CEST] <philipl> jkqxz: Care to comment on the thread with Yogenda (nvidia guy) about automatically adding hwupload to a filter chain? [02:44:59 CEST] <atomnuker> I'm trying to benchmark vgatherqps [02:45:10 CEST] <atomnuker> vgatherqps m3, [inq+m5], m15 <- how does addressing work here? [02:45:24 CEST] <atomnuker> do I fill m5 with indices [03:07:57 CEST] <cone-864> ffmpeg 03Michael Niedermayer 07master:296debd213bd: avcodec/dnxhddec: Move mb height check out of non hr branch [03:52:25 CEST] <cone-864> ffmpeg 03Vodyannikov Aleksandr 07release/3.3:20c440edbc89: avcodec/cfhd: Fix decoding regression due to height check [03:52:26 CEST] <cone-864> ffmpeg 03Brice Waegeneire 07release/3.3:4627033a236c: doc/filters: typo in frei0r [03:52:27 CEST] <cone-864> ffmpeg 03Michael Niedermayer 07release/3.3:f10252e47d81: avcodec/dirac_vlc: Fix undefined shift [03:52:28 CEST] <cone-864> ffmpeg 03Michael Niedermayer 07release/3.3:a930db5c8299: avcodec/aacdec_fixed: fix: left shift of negative value -1 [03:52:29 CEST] <cone-864> ffmpeg 03Michael Niedermayer 07release/3.3:b44a3cd06e22: avcodec/aacps: Fix multiple integer overflow in map_val_34_to_20() [03:52:30 CEST] <cone-864> ffmpeg 03Michael Niedermayer 07release/3.3:b120685dcae9: avcodec/ylc: Fix shift overflow [03:52:31 CEST] <cone-864> ffmpeg 03Michael Niedermayer 07release/3.3:a9081b36f4d2: avformat/oggparsecelt: Do not re-allocate os->private [03:52:32 CEST] <cone-864> ffmpeg 03Michael Niedermayer 07release/3.3:2f75ebe24a77: avcodec/hevc_ps: fix integer overflow in log2_parallel_merge_level_minus2 [03:52:33 CEST] <cone-864> ffmpeg 03Michael Niedermayer 07release/3.3:47c0626ec721: avcodec/dnxhddec: Move mb height check out of non hr branch [04:19:29 CEST] <atomnuker> ...why does x86asm not warn about missing RETs [04:23:48 CEST] <jamrial> how would it? [04:28:00 CEST] <atomnuker> good point [04:55:44 CEST] <FishPencil_> I'm curious why Clément BSsch (ubitux) rewrote the nlmeans filter when Dirk Farin had already written one https://github.com/farindk/ffmpeg [04:57:50 CEST] <jamrial> was that ever sent to the ml? [04:59:16 CEST] <FishPencil_> I don't think so, but it's GPL so why not just bring it in [04:59:58 CEST] <jamrial> well, if it was never sent to the ml, there was no way to know it was written at all [05:00:13 CEST] <jamrial> and the current filter in the tree is lgpl [05:00:27 CEST] <FishPencil_> I see [05:02:33 CEST] <FishPencil_> ubitux: just reading the code, it doesn't look like it handles multiple images across threads? [05:47:07 CEST] <FishPencil_> Is there any better quality denoising algorthm than NLMeans (in FFmpeg or not). [05:50:25 CEST] <atomnuker> dctdnoiz, hqdn3d, owdenoise, vaguedenoiser, atadenoise [05:51:05 CEST] <atomnuker> no idea which one is the best, but I bet they all have their pros and cons for a given source [05:56:48 CEST] <FishPencil_> atomnuker: There's a lot to suggest that nlmeans is the best quality denoiser, as slow as it is. It's getting older now though, so I'm curious if there's anything new/better [07:45:11 CEST] <ubitux> FishPencil_: hi [07:45:37 CEST] <ubitux> FishPencil_: nlmeans supports slice threading; there is no such thing as frame filtering with lavfi currently [07:46:48 CEST] <ubitux> reasons for writing one: Dirk Farin never submitted the patch, LGPL vs GPL, and i wanted to understand how that filter worked [07:47:46 CEST] <ubitux> i need to write some SIMD for the integral at some point, but feel free to compare speed and efficiency [07:50:13 CEST] <ubitux> atomnuker: pretty sure nlmeans is one of the best; dctdnoiz is more an experiment, hqdn3d and owdenoise mostly target real time [07:50:34 CEST] <ubitux> can't comment on the other two, but nlmeans is a reference [07:50:58 CEST] <ubitux> most "new gen" filters rely on nlmeans logic one way or another [07:57:46 CEST] <ubitux> you may want to check removegrain and nnedi though [07:58:08 CEST] <ubitux> wait no, nnedi is not a denoiser [07:58:16 CEST] <ubitux> which one i had in mind... [07:58:29 CEST] <ubitux> well, whatever [07:58:35 CEST] <atomnuker> nlmeans is spatial domain, interest = lost [07:59:24 CEST] <ubitux> it can be extended to time domain [07:59:35 CEST] <atomnuker> yeah but not the frequency domain [08:00:16 CEST] <ubitux> as long as it's more efficient, who cares? :) [08:02:40 CEST] <atomnuker> dctdnoiz looks great, I should play with it some day [08:03:53 CEST] <ubitux> it's just one of those slow bluring filters ;) [08:05:10 CEST] <ubitux> atomnuker: you may be interested in https://github.com/ubitux/dct [08:05:52 CEST] <ubitux> (that's the code used to generate the dctdnoiz code) [08:06:30 CEST] <atomnuker> heh, the daala guys made one too though theirs is fixed-point [08:06:56 CEST] <ubitux> yeah, it should be made fixed point now ;) [08:07:10 CEST] <ubitux> so we can at least test it with fate properly [08:09:37 CEST] <atomnuker> why are intel not improving the horizontal functions [08:09:54 CEST] <atomnuker> I want an haddsubps/hsubaddps [08:10:15 CEST] <nevcairiel> probably because their use is very limited, and implementation complex [08:10:57 CEST] <atomnuker> butterflies are very common :/ [08:11:51 CEST] <stevenliu> Clément is ubitux? [08:15:10 CEST] <stevenliu> the edc43c571d in libav is return AVERROR(EIO) in ffmpeg is AVERROR(EINVAL) , dose ffmpeg must use EIO? i think the EINVAL maybe better [08:15:43 CEST] <stevenliu> or ffmpeg must copy or merge all things from libav? [08:19:06 CEST] <nevcairiel> it doesnt have to be exactly the same, if we can improve something we should [08:36:35 CEST] <ubitux> stevenliu: you need to reference the 5caaa3a49e76b084ff8a9840d541bad64d96d7f7 hash in your commit description [08:36:40 CEST] <ubitux> because that's what matters [08:46:51 CEST] <stevenliu> Then, What should i do next step? [08:47:38 CEST] <stevenliu> modify the return AVERROR(EINVAL); to return AVERROR(EIO); ? [08:47:45 CEST] <stevenliu> and fix the documentation? [08:56:26 CEST] <cone-028> ffmpeg 03Tobias Rapp 07master:60008c0fe94b: fate: update pixfmt_best test to check for endianness [09:16:06 CEST] <stevenliu> ubitux: Can you give me some express point? about next step? [09:17:00 CEST] <stevenliu> the options has implement at hlsenc of ffmpeg. [11:49:09 CEST] <j-b> Any good samples to test 601 or 709? [11:54:27 CEST] <ubitux> smptebars and smptehdbars? [11:54:38 CEST] <ubitux> (source filters) [11:58:28 CEST] <J_Darnley> atomnuker: I have (yet another) question about vc2. It is specific this time. [11:58:49 CEST] <J_Darnley> ... just a mo [12:00:00 CEST] <atomnuker> ment? [12:00:33 CEST] <J_Darnley> yes [12:00:36 CEST] <J_Darnley> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/vc2enc_dwt.c#L166 [12:00:49 CEST] <J_Darnley> Is this line handling the edge of the picture? [12:01:56 CEST] <atomnuker> it looks like it does [12:02:26 CEST] <J_Darnley> Okay, thank you. [12:03:03 CEST] <ubitux> j-b: ffmpeg -lavfi smptehdbars=d=5 -y -c:v libx264 -pix_fmt yuv444p -colorspace bt709 -color_trc bt709 /tmp/bt709.mkv [12:03:06 CEST] <ubitux> maybe? [12:04:36 CEST] <ubitux> then smptebars, bt470bg etc, i guess [12:05:11 CEST] <J_Darnley> atomnuker: do you also think that the next line (just under "lifting stange 1") is handling the other edge? [12:05:18 CEST] <J_Darnley> *stage [12:06:34 CEST] <atomnuker> yeah, looks like that ones does the left side of the image [12:09:47 CEST] <J_Darnley> thank you again [12:09:52 CEST] <stevenliu> ubitux: [12:10:27 CEST] <ubitux> stevenliu: sorry, missed your messages [12:10:30 CEST] <ubitux> just a sec [12:10:37 CEST] <stevenliu> :-) [12:14:36 CEST] <ubitux> stevenliu: AVERROR(EIO) may be better [12:14:39 CEST] <ubitux> what do you think? [12:14:54 CEST] <ubitux> about the doc, it seems the options are documented [12:15:05 CEST] <ubitux> i'm not familiar with hlsenc: you are maintaining that code [12:15:20 CEST] <ubitux> so if you think it has everything from libav, that's good [12:15:25 CEST] <ubitux> just reference the hashes in the commit [12:15:37 CEST] <ubitux> so typically, you reference 5caaa3a49e76b084ff8a9840d541bad64d96d7f7 [12:18:15 CEST] <stevenliu> I think it maybe invalid with openssl, so that is EINVAL, then i have not modify it to EIO, i think EIO maybe a fatal error, for example file broke or device broke, Let me check the suggestion, do you mean i need add one line in the commit comment: reference the commit id: 5caaa3a49e76b084ff8a9840d541bad64d96d7f7 [12:18:53 CEST] <ubitux> yes [12:19:23 CEST] <stevenliu> Thank you, i modify the patch :D [12:19:23 CEST] <ubitux> just "See 5caaa3a49e76b084ff8a9840d541bad64d96d7f7." should be enough [12:19:29 CEST] <stevenliu> ok [14:25:20 CEST] <FishPencil_> ubitux: BM3D is another high quality one, but it's implementations are limited due to licensing I believe [15:24:40 CEST] <cone-932> ffmpeg 03Paul B Mahol 07master:9835ee60da31: avcodec/dnxhdenc: enable frame threading [19:23:00 CEST] <cone-932> ffmpeg 03James Almer 07master:9f449227a3ad: doc/APIChanges: add missing entry for ICC Profile side data type. [21:28:45 CEST] <tdjones> I'm having serious difficulty on detminging the cause of clipping in the vorbis encoder. Making it more difficult for the encoder to switch frame types seems to have no effect [21:29:44 CEST] <tdjones> determining* [21:30:42 CEST] <tdjones> I can remove most of the clicking at normal quality levels, but once I drop the quality, it quickly gets much worse [21:39:36 CEST] <atomnuker> tdjones: actually maybe I was wrong and it wasn't transient->nontransient switching which was the issue [21:39:58 CEST] <atomnuker> well it was, but to solve it correctly you wouldn't need to do limiting yourself [21:40:20 CEST] <atomnuker> rather the rate control system should based on the rate determine if a transient is possible [21:40:32 CEST] <atomnuker> since you have to spend more bits on making a transient sound better [21:41:03 CEST] <atomnuker> because long frames just have more pre-echo which sounds better than clicking [21:41:56 CEST] <tdjones> I had a suspicion that vbr would have a greater impact on reducing it [21:42:28 CEST] <atomnuker> tdjones: I just remembered the vorbis encoder has no rate control and needs -q:a so vbr mode only [21:42:40 CEST] <atomnuker> you'll have a ton of actual fun implementing a rate control system [21:42:50 CEST] <atomnuker> start by having a lambda value first [21:43:00 CEST] <atomnuker> where the lambda value starts off as 1.0f during init [21:43:29 CEST] <atomnuker> and for every frame you multiply it by the ratio of bits_used / ideal_bits [21:44:07 CEST] <atomnuker> where ideal_bits is the bitrate divided by the (samplerate divided by the frame_size in samples) [21:44:31 CEST] <atomnuker> if you were to encode with ideal bits you'd nail the rate exactly [21:44:51 CEST] <atomnuker> so what happens is the lambda values goes up (or its supposed to go up) if you undershoot the rate [21:44:58 CEST] <atomnuker> and go down if you overshoot the rate [21:45:20 CEST] <atomnuker> and you plug the lambda value as the rate multiplier into your search and quantization [21:45:48 CEST] <atomnuker> and if everything works correctly it'll on average maintain the rate specified [21:46:50 CEST] <tdjones> Yeah, I've tried to follow the bit rate managing in libvorbis, but I then remember how much xiph enjoyed obfuscating any non-trivial code [21:46:57 CEST] <JEEB> :D [21:47:11 CEST] <atomnuker> look at how s->lambda is set in aacenc.c [21:47:58 CEST] <tdjones> I'll take a look. [21:47:59 CEST] <atomnuker> the ratio there is clipped between 0.9 and 1.1 but I don't think that does much good [21:48:51 CEST] <atomnuker> its there to prevent huge variations and allow the rate to play a little but as it is the aac encoder keeps its rate extremely constrained [21:51:22 CEST] <tdjones> Well, I have a patch the supports mono streams, and a patch for some clip avoidance. Should I resubmit the transient patches with the changes suggested on the mailing list and follow that up with these couple patches? [21:52:03 CEST] <atomnuker> the first patch was fine, just resubmit that one [21:52:14 CEST] <tdjones> I almost have support for 5.1 streams, I just need to fix some of the channel muxing problems that I've had with the mapping configurations [21:52:14 CEST] <atomnuker> (with the nits I had) [21:52:53 CEST] <atomnuker> 5.1 would be nice but its in no way a priority and would probably complicate things [21:53:07 CEST] <atomnuker> (that apart I've never seen a 5.1 vorbis file anywhere) [21:54:52 CEST] <tdjones> I mean it should work for any file with LFE. I'll put it on the back-burner for now [21:57:46 CEST] <tdjones> Did you also want me to move codebooks to vorbis_data.c? I had mentioned that they are only used in the encoder, so I wasn't sure what the convention was for that. [21:58:35 CEST] <atomnuker> yep [21:59:06 CEST] <atomnuker> actually, how many total lines of tables does the encoder use? [21:59:25 CEST] <atomnuker> (encoder only tables that is, which the decoder doesn't need) [22:00:11 CEST] <tdjones> The decoder doesn't use pre-built tables at all afaik. [22:00:21 CEST] <tdjones> It only pulls tables from the header of the bit stream [22:00:50 CEST] <atomnuker> oh you're right [22:01:30 CEST] <atomnuker> damn, in that case its fine to have a separate encoder-only tables file [22:02:46 CEST] <tdjones> ok [22:02:47 CEST] <atomnuker> tdjones: btw did you know there was a proprietary tool to re-entropy encoder vorbis files by scanning it and making optimal tables up [22:03:04 CEST] <atomnuker> 10 years ago though, and it only gave like 3% IIRC [22:04:09 CEST] <tdjones> I did not know that. I know that you can train new codebooks in libvorbis if you flag for it at compile-time, but I've never tried it. [23:22:21 CEST] <cone-936> ffmpeg 03Wan-Teh Chang 07master:8c3b329da21a: avcodec/h264_slice: don't sync default_ref[] between threads. [23:22:21 CEST] <cone-936> ffmpeg 03Wan-Teh Chang 07master:58fbcf885d97: pthread_frame: revert 2e664b9c1e73c80aab91070c1eb7676f04bdd12d. [00:00:00 CEST] --- Fri Jul 28 2017

1 0

ffmpeg.log.20170727
by burek 28 Jul '17

28 Jul '17

[00:12:58 CEST] <stapler> and libavformat handles most of what i need to do rt(s)p streaming? [00:28:11 CEST] <DHE> stapler: it should be fairly obvious how to map ffmpeg command-line parameters to libav. RTSP is no different than any other output format [00:29:29 CEST] <stapler> DHE, i suppose so [04:35:39 CEST] <cryptodechange> so a 10bit encode with the same CRF produces a file only ~0.4mbps smaller [04:36:13 CEST] <cryptodechange> Though I noticed some artifacts in darker areas on the 8bit, smoother on the 10bit [04:44:14 CEST] <blimpse_> Is there a specific way I need to compile ffmpeg to support converting .SPC files? [04:44:46 CEST] <blimpse_> This is the command I tried and its output: https://pastebin.com/4rGWucE7 [04:55:02 CEST] <kepstin> blimpse_: by spc you mean snes emulated audio? [04:56:41 CEST] <kepstin> I think you have to have a version of ffmpeg compiled with libgme ("game music emu") in order to do anything with that [05:00:11 CEST] <furq> the ffmpeg in debian has libgme [05:00:22 CEST] <furq> i guess that's from a PPA or something if it's ubuntu 14.04 though [05:00:57 CEST] <furq> oh nvm i guess you built it yourself [05:14:49 CEST] <blimpse_> Thanks! I'm compiling it with libgme now. [10:04:20 CEST] <franciscui> Hi,all,I use the command "ffmpeg -re -fflags +genpts -f concat -safe 0 -i /data/videos/vod2live/dst/20170721230010192470 3playlist.txt -vcodec h264 -acodec aac -ac 2 -bufsize 3M -preset fast -f flv rtmp://127.0.0.1:8081/live/101924703" to push stream ,and [10:04:36 CEST] <franciscui> then ,i WriteN, RTMP send error 104 (129 bytes) WriteN, RTMP send error 32 (44 bytes) WriteN, RTMP send error 9 (42 bytes) av_interleaved_write_frame(): Operation not permitted Last message repeated 1 times [flv @ 0x21908c0] Failed to update header with correct duration. [flv @ 0x21908c0] Failed to update header with correct filesize. Error writing trailer of rtmp://127.0.0.1:8081/live/101924703: Operation not permittedframe=222 [10:05:29 CEST] <franciscui> I meet above problem,can anyone help me ,thanks [11:26:33 CEST] <squ> operation not permitted it says [11:26:39 CEST] <squ> :) [12:35:32 CEST] <mnr200> I'm receiving Unknown input format: 'dshow' error [12:36:08 CEST] <mnr200> with the option dshow [12:36:42 CEST] <mnr200> can anyone give me an idea what is wrong here? [12:36:58 CEST] <stevenliu> command line? [12:39:18 CEST] <mnr200> stevenliu, ffmpeg -f dshow -i video="Virtual-Camera" -preset ultrafast -vcodec libx264 -tune zerolatency -b 900k -f mpegts rtsp://localhost:8554/live.sdp [12:39:36 CEST] <stevenliu> ffmpeg -show_devices [12:40:04 CEST] <stevenliu> ffmpeg -devices [12:41:15 CEST] <mnr200> https://pastebin.com/2myU2pwt [12:42:21 CEST] <mnr200> I'm trying to stream live video from webcam [12:45:41 CEST] <mnr200> stevenliu, ffmpeg -f video4linux2 -s 640x480 -r 30 -i /dev/video0 -f rtsp -rtsp_transport tcp rtsp://localhost:8554/live.sdp this one somewhat works [12:46:02 CEST] <stevenliu> ok [12:46:04 CEST] <mnr200> but huge latency with and delay [12:50:15 CEST] <mnr200> so whats the problem with the above command, any idea? [12:52:11 CEST] <stevenliu> what codec from the camera? [12:52:19 CEST] <stevenliu> mjpeg? AVC? [12:53:31 CEST] <mnr200> not sure, mjpeg may be [12:53:38 CEST] <mnr200> how do I find it? [13:34:23 CEST] <stevenliu> you can find the message at input info [13:43:31 CEST] <long-klong> hello ! [13:43:41 CEST] <long-klong> I want to implement a close to real time encoded image into a video stream from a camera ov5642 , and I will like to parallelize using openCL some part of the algo [13:43:50 CEST] <long-klong> is it possible on a raspberry pi 3 ? [13:43:56 CEST] <long-klong> has anyone done something close to this ? [13:49:38 CEST] <squ> some codecs are parallelized [16:06:18 CEST] <rev0n> anyone here? [16:06:46 CEST] <c_14> no [16:09:37 CEST] <rev0n> that's fine ;) so maybe I will just ask a question. Is it possible with ffmpeg lib to convert blob data from the socket to another format and also output it as a stream, rather then writing it to file? If so - how? [16:10:11 CEST] <furq> i couldn't tell you how to do it with the libs, but that's certainly possible [16:12:34 CEST] <DHE> ffmpeg can make a basic TCP/UDP socket itself as well as common network protocols like rtsp, or you can specify a virtual IO library for ffmpeg to use for reads/writes. then use that as an input or output [16:13:10 CEST] <c_14> rev0n: depends on what "blob data" is [16:13:30 CEST] <c_14> it has to be in a format/protocol that FFmpeg can read [16:13:44 CEST] <rev0n> blob data means webm endoded package [16:14:01 CEST] <c_14> webm should be fine [16:17:05 CEST] <rev0n> I actually try to record the stream from the webcam on the client-side, send it through websockets to some python tornado server (very basic one as I started learning python just yesterday - you know, PHP / Java developer), convert it then to flv and write to rtmp nginx based server for further publishing via HLS to viewers. What's the purpose you would ask - I'm trying badly to avoid Flash for live webcam streaming [16:20:06 CEST] <faLUCE> hello. Is there some option for 0 latency on the aac encoder? [16:22:06 CEST] <kepstin> faLUCE: define "0" latency [16:22:30 CEST] <kepstin> and with aac-lc, what the internal aac encoder supports, there is no real low latency ability. [16:22:46 CEST] <faLUCE> kepstin: something like h264. The encoder doesn't have to buffer before outputting an encoded frame [16:23:13 CEST] <faLUCE> I mean: it doesn't have to buffer MORE than 1 aac frame (1024 samples) [16:24:02 CEST] <c_14> rev0n: assuming you can grab the webcam on the client side you can generate hls directly with ffmpeg or pass it to nginx-rtmp with ffmpeg. Might not even need to use the libraries directly (assuming the webcam has dshow/v4l2) [16:26:13 CEST] <rev0n> for getting webcam I use html5 getUserMedia which is browser thing. So one Idea I had was to stream data from the camera with JS WebSockets. This is why I cannot generate any other format than webm [16:26:34 CEST] <kepstin> faLUCE: well, buffering 1024 samples is already ~23ms, and I think aac needs info from the next frame for overlapping mdct windows to encode the current frame. [16:28:31 CEST] <kepstin> reducing audio latency with lossy codecs usually involves making frames shorter; e.g. opus can go down to 2.5ms (at significantly reduced efficiency) [16:28:51 CEST] <faLUCE> kepstin: the time for buffering 1024 samples depends on the sample rate.... [16:29:09 CEST] <kepstin> faLUCE: I assumed 44.1kHz there, adjust as needed. [16:29:58 CEST] <faLUCE> In addition, I need to understand the minimum amount of frames that aac has to buffer before producing the first encoded frame... do you think they are two frames or more? [16:30:04 CEST] Action: kepstin notes that opus has additional latency of 2.5-4ms on top of the frame size depending on settings. [16:30:58 CEST] <kepstin> faLUCE: I don't know the details of the aac format well enough. I suspect that it is "at least x samples from the next frame" [16:31:51 CEST] <rev0n> How can I open an input ffmpeg socket then to retrieve the data from user? [16:33:18 CEST] <kepstin> rev0n: a websocket? ffmpeg doesn't have native support for that; you'd have to handle the socket in your own code and pass the data to ffmpeg. [16:34:03 CEST] <faLUCE> kepstin: aac has a framesize of 1024 [16:34:09 CEST] <faLUCE> it's fixed [16:34:31 CEST] <faLUCE> I wonder how many frames are required to buffer before outputting the first encoded frame [16:34:33 CEST] <rev0n> kepstin: ok, I have that - Python Tornado server. But how I can feed ffmpeg with this data? [16:36:00 CEST] <kepstin> rev0n: i don't know of any way to use ffmpeg libraries directly from python usefully, but one option you could do is create an ffmpeg cli subprocess which is reading from a pipe, and then write the data from the socket to that pipe in your python app. [16:38:19 CEST] <rev0n> kepstin: thank you. That's what I'm gonna try. I thought maybe there's better way. Should be fine tho [16:42:38 CEST] <kepstin> faLUCE: it looks like the size of the aac transform is 2048 samples at 1024 sample offsets, but most encoders use a number of priming samples that's not a multiple of 1024. [16:42:40 CEST] <kepstin> In theory an aac encoder only needs 1024 future samples, but if you're giving it 1024 sample frames, they'll be misaligned, so it'll need 2 future frames. [16:43:37 CEST] <kepstin> faLUCE: so one way to reduce encoder delay might be to provide audio to the encoder in smaller chunks [16:43:58 CEST] <kepstin> (i dunno if this works with ffmpeg's aac encoder, need to find someone familiar with the internals) [16:44:31 CEST] <faLUCE> kepstin: I provide to the encoder chunks of 148. Then it buffers them to a frame with size=1024 [16:45:02 CEST] <faLUCE> (1024 samples) [16:45:21 CEST] <kepstin> faLUCE: then you're probably already doing as well as can be expected with aac. [16:45:34 CEST] <faLUCE> kepstin: it seems that a minimum of 2 frames (2048 samples) is required... in fact I see that it buffers 2 frames [16:45:43 CEST] <faLUCE> but I wonder if this can be reduced to 1 frame [16:45:52 CEST] <kepstin> faLUCE: yes, that's what I said above [16:46:03 CEST] <kepstin> "the size of the aac transform is 2048 samples at 1024 sample offsets" [16:46:12 CEST] <kepstin> the only way to reduce that is to use a different codec. [16:46:23 CEST] <faLUCE> kepstin: but I wonder if is there some "zerolatency" option for aac too... [16:46:28 CEST] <faLUCE> that reduces it [16:47:39 CEST] <kepstin> there's "aac-ld" which reduces latency to ~20ms, but keep in mind that although it's called "aac" it's actually a fairly different codec from the common aac-lc, and it's not supported by all decoders. [16:47:55 CEST] <kepstin> and ffmpeg's internal aac encoder can't encode anything besides aac-lc right now, i think [16:48:25 CEST] <kepstin> if you're switching codecs anyways to reduce latency, just use opus :) [16:48:41 CEST] <faLUCE> kepstin: what about mp2 ? [16:50:40 CEST] <kepstin> faLUCE: I think mp2 uses even larger frames (1152 samples), but i dunno how much overlapping it needs. might have less latency than aac? probably still not great. [16:52:40 CEST] <faLUCE> kepstin: you said that [16:26] <kepstin> faLUCE: well, buffering 1024 samples is already ~23ms, <---- but I measured it, it seems 35ms [16:52:46 CEST] <faLUCE> (at 44100) [16:53:32 CEST] <lukas_gab> Hi folks. I want to record split screen from few IP cameras, I try this way https://pastebin.com/82y7bi9h but I have an error "Filter overlay has an unconnected output". How can I fix it?? Thnaks for yout help and time. [16:53:33 CEST] <kepstin> 44100 Hz is 44100 samples in 1 second. 1024 samples is therefore 1024/44100 = 23.2ms [16:53:50 CEST] <kepstin> any additional delays are due to something other than simply buffering 1024 sample increments [16:55:15 CEST] <faLUCE> I see, thanks [17:51:32 CEST] <lukas_gab> ok, I split screen succesfull [17:51:38 CEST] <lukas_gab> but I have other troble [17:51:46 CEST] <lukas_gab> I do this - [17:51:46 CEST] <lukas_gab> ffmpeg -rtsp_transport tcp -i "rtsp://admin:Pass@192.168.88.76:554/h264" -rtsp_transport tcp -i "rtsp://admin:Pass@192.168.88.76:554/h264" -filter_complex "[0:v][1:v]hstack" -c:v libx264 combo.avi [17:52:16 CEST] <lukas_gab> but output has hi resolution, ffmpeg go to 100% of cpu, loss packet and give me error [17:52:32 CEST] <lukas_gab> how can I resize streams before split and encoding ? [17:52:37 CEST] <lukas_gab> pleas help me [17:52:50 CEST] <rev0n> Has anybody any clue if I should do some additional data convertion while retrieving webm chunks via websocket? The data seems to be ok on the JS client side, but when the data comes to python server and I try to save it as bytes to a .webm file I get file working in VLC but the image looks like multiplied by four (actually I get 4 images on a splitscreen) [18:01:47 CEST] <kepstin> rev0n: i can't think of anything that would cause that other than something in how the video is encoded at the source [18:06:13 CEST] <rev0n> Just found the problem. It was some stupid mistake as I had multiplied stream by my js code. It's fine now. However I have one more problem: [mp4 @ 0x5610442d44a0] Non-monotonous DTS in output stream 0:1; previous: 143394, current: 137320; changing to 143395. This may result in incorrect timestamps in the output file. [18:06:30 CEST] <rev0n> and in fact my output file is empty [18:10:23 CEST] <rev0n> any ideas? [18:21:24 CEST] <rev0n> Input #0, matroska,webm, from 'pipe:': [18:21:24 CEST] <rev0n> Metadata: [18:21:24 CEST] <rev0n> encoder : Chrome [18:21:24 CEST] <rev0n> Duration: N/A, start: 0.000000, bitrate: N/A [18:21:24 CEST] <rev0n> Stream #0:0(eng): Audio: opus, 48000 Hz, mono, fltp (default) [18:21:25 CEST] <rev0n> Stream #0:1(eng): Video: vp8, yuv420p, 640x480, SAR 1:1 DAR 4:3, 16.67 tbr, 1k tbn, 1k tbc (default) [18:21:27 CEST] <rev0n> Metadata: [18:21:29 CEST] <rev0n> alpha_mode : 1 [18:21:49 CEST] <rev0n> looks fine,doesn't it? [18:23:13 CEST] <durandal_1707> lukas_gab: use scale filter [18:54:17 CEST] <rev0n> Could you please help me out with right configuration to convert webm to flv for rtmp stream? [19:09:56 CEST] <furq> -i foo.webm -c:v libx264 -c:a aac rtmp:// [19:16:31 CEST] <faLUCE> Do you know if is there a way to obtain less than 2 frames latency with the aac encoder? [19:17:10 CEST] <faLUCE> without aac-lc [19:26:04 CEST] <kepstin> faLUCE: no, that's inherent to the design of the codec. [19:26:27 CEST] <kepstin> er, inherent to the design of aac-lc [19:27:27 CEST] <faLUCE> kepstin: I see... I was hoping for a different answer ;-) [19:28:13 CEST] <faLUCE> kepstin: anyway, about mp2, even if it has a larger frame-size (1152samples), maybe it doesn't need to buffer two frames...? [19:28:58 CEST] <kepstin> i don't know enough about mp2, but it has a simpler design, so that might be the case. [19:29:11 CEST] <kepstin> my recommendation of 'use opus' stands. [19:31:25 CEST] <Blubberbub> is 2 frames really that big of a deal? [19:31:57 CEST] <kepstin> two frames in aac plus the other delays in the codec probaly add up to around 50ms [19:32:42 CEST] <kepstin> which isn't terrible, but it's a bit too long for e.g. synced musical performances and whatnot [19:34:43 CEST] <rev0n> furq: I get the following error: [NULL @ 0x55ceb7926d20] Unable to find a suitable output format for 'rtmp:// [19:35:47 CEST] <rev0n> obviously there's whole rtmp address, I was able to stream from mp4 to exact same rtmp server [19:44:11 CEST] <rev0n> relaxed: https://pastebin.com/90FgV4XL I try to pipe data from websocket to ffmpeg and convert it actually to any other format then webm [19:46:57 CEST] <furq> rev0n: add -f flv [19:49:03 CEST] <rev0n> furq: I tried that. It does not work properly. It seems like there's something with my incoming stream, however it seems ok, ffmpeg recognize webm, but I cannot convert it to any other format [19:54:45 CEST] <rev0n> Input #0, matroska,webm, from 'pipe:': [19:54:45 CEST] <rev0n> Metadata: [19:54:45 CEST] <rev0n> encoder : Chrome [19:54:45 CEST] <rev0n> Duration: N/A, start: 0.000000, bitrate: N/A [19:54:45 CEST] <rev0n> Stream #0:0(eng): Audio: opus, 48000 Hz, mono, fltp (default) [19:54:46 CEST] <rev0n> Stream #0:1(eng): Video: vp8, yuv420p, 640x480, SAR 1:1 DAR 4:3, 1k tbr, 1k tbn, 1k tbc (default) [19:55:31 CEST] <kepstin> rev0n: please use a pastebin site, and include the *complete* output. [19:55:32 CEST] <relaxed> your error referred to the output format [19:59:20 CEST] <rev0n> just trying to get full log, however my lack of knowledge in Python complicates things. Also my ffmpeg runs on docker which gives me limited number of lines while getting log from docker [19:59:57 CEST] <rev0n> and I can't seem to write log to a file with ffmpeg as it does not recognize > something.txt [20:00:14 CEST] <kepstin> the logs are put on stderr, not stdout [20:00:55 CEST] <faLUCE> kepstin: I can't use opus, I use mpegts as muxer [20:00:59 CEST] <faLUCE> as container [20:01:30 CEST] <JEEB> opus is specified in mpeg-ts [20:01:46 CEST] <JEEB> usually it's the receiver that you'll have issues with with opus-in-mpegts [20:01:50 CEST] <kepstin> is the muxing actually implemented in ffmpeg tho? [20:01:58 CEST] <JEEB> not sure [20:02:57 CEST] <JEEB> I know demuxing should be there at least [20:04:03 CEST] <kepstin> faLUCE: are you sending mpegts over udp or something like that? [20:04:05 CEST] <faLUCE> kepstin: what do you mean with that, exactly? [19:31] <kepstin> two frames in aac plus the other delays in the codec probaly add up to around 50ms <--- it is the codec which adds two frame latency [20:04:18 CEST] <faLUCE> kepstin: over http [20:04:22 CEST] <kepstin> lol [20:04:33 CEST] <kepstin> why are you even worrying about the encoder delay then [20:04:49 CEST] <faLUCE> kepstin: I already made a ~0 latency http mpegts h264 streamer + receiver [20:05:13 CEST] <kepstin> well, aside from until a packet gets dropped and you have to wait for a retransmit [20:05:14 CEST] <faLUCE> now I want to obtain a good result for audio too [20:06:12 CEST] <kepstin> but yep, looks like ffmpeg can mux opus in mpegts [20:06:20 CEST] <faLUCE> [20:05] <kepstin> well, aside from until a packet gets dropped and you have to wait for a retransmit <--- what do you mean? [20:06:22 CEST] <kepstin> and since you control both ends of the stream, should be ok [20:06:32 CEST] <faLUCE> kepstin: I drop frames in the receiver [20:06:52 CEST] <kepstin> faLUCE: http is build on tcp, which is a reliable stream transport that implements buffering and packet retransmit at a lower level than the application [20:07:15 CEST] <faLUCE> kepstin: I know that [20:07:29 CEST] <kepstin> so it can add unpredictable delays which you can't do anything about in the face of network errors like dropped packets [20:07:45 CEST] <faLUCE> but for LAN is good [20:08:32 CEST] <kepstin> usually, yeah, but if you're building a custom app anyways why not use udp? which will also work well for lan, with potentially less os-level buffering [20:09:09 CEST] <faLUCE> kepstin: I already made a library: https://github.com/paolo-pr/laav [20:09:13 CEST] <kepstin> i assume you're already setting the tcp stream with the nodelay flag at least, so it's not trying to buffer full ethernet frames [20:09:15 CEST] <faLUCE> kepstin: now, I'm working on the player side [20:09:23 CEST] <kepstin> full ip frames* [20:09:52 CEST] <faLUCE> I don't bother with tcp delay, for now... I'm removing unnecessary delays on localhost [20:10:10 CEST] <kepstin> oh, you're only running this on localhost for testing? [20:10:10 CEST] <faLUCE> kepstin: anyway, I could send mpegts over udp as well [20:10:17 CEST] <faLUCE> kepstin: yes, for now [20:10:21 CEST] <kepstin> yeah, you're gonna get some surprises when you switch to a real network interface [20:11:03 CEST] <faLUCE> kepstin: I know, but I'm removing all the delays in many parts ( mpegts muxer, h264 parser, h264 decoder etc.) [20:11:17 CEST] <faLUCE> then I can switch to udp as well [20:11:32 CEST] <faLUCE> kepstin: what about mpegts over udp? [20:11:44 CEST] <JEEB> often used in LANs [20:11:50 CEST] <kepstin> faLUCE: should be fine, commonly used yeah [20:12:22 CEST] <faLUCE> I see. It will be easy so change HTTP with UDP. I just have to add a simple module [20:12:31 CEST] <faLUCE> (in my library) [20:12:49 CEST] <faLUCE> but I don't like UDP very much to be honest. I had many problems with it, in the past [20:12:59 CEST] <faLUCE> (FWs) [20:13:03 CEST] <JEEB> sure, it can have a lot of issues depending on your network quality [20:13:07 CEST] <JEEB> and/or other things [20:14:02 CEST] <kepstin> but... tcp still has to deal with the same issues, and it prioritizes not losing data and transfer rate over latency, which is not always the best fit for every application [20:14:25 CEST] <faLUCE> I know [20:14:48 CEST] <faLUCE> I did not think about UDP with MPEGTS [20:14:53 CEST] <faLUCE> it seems a good idea [20:15:04 CEST] <faLUCE> an alternative to RTP over UDP [20:15:59 CEST] <faLUCE> btw: I'm making the player with gstreamer... which is much easier than libav for the player side [20:16:15 CEST] <faLUCE> (I used libav for the encoder side) [20:16:58 CEST] <kepstin> gstreamer is probably using ffmpeg/libav to pull in the actual audio/video decoders, of course, but it has its own network, av sync, etc. stuff. [20:17:08 CEST] <faLUCE> yes, it uses libav [20:17:12 CEST] <faLUCE> gst-libav [20:17:45 CEST] <kepstin> the really hilarious thing about gstreamer is that in gstreamer 0.10, gst-ffmpeg uses libav, and in 1.0, gst-libav uses ffmpeg [20:17:45 CEST] <faLUCE> but it has a very huge API, and the user doesn't have to bother with threads, queue etc. [20:19:40 CEST] <faLUCE> I spent lot of time in finding a good library for the player. libav was too complex and too "low level", mpv has a too minimal API. Tried also some others... At the end, I found gstreamer [20:24:52 CEST] <rev0n> running self.app = Subprocess(['ffmpeg', '-y', '-i', '-', '-an', 'new.webm'], stdout=Subprocess.STREAM, stdin=Subprocess.STREAM) gives me: https://pastebin.com/HF6SQs9m [20:25:08 CEST] <rev0n> file new.webm is empty (0 bytes) [20:26:09 CEST] <kepstin> faLUCE: anyways, opus in mpegts. If configured for lowest delay mode, at great expense to efficiency, and you avoid/disable resampling, the encoder delay is 5ms. [20:26:41 CEST] <kepstin> (and it's quite tweakable; adjustable frame size) [20:27:49 CEST] <faLUCE> kepstin: I'll consider it [20:30:35 CEST] <rev0n> any thoughts on my issue? [20:33:37 CEST] <kepstin> rev0n: it clear what's going on there. there's nothing in the ffmpeg output that says there's any error; are you continuously sending it data, then closing the stdin stream when done to signal eof? [20:35:37 CEST] <rev0n> kepsting: that's correct. In tornado server on socket open I create self.app = Subprocess(['ffmpeg', '-y', '-i', '-', '-an', 'new.webm'], stdout=Subprocess.STREAM, stdin=Subprocess.STREAM), later on message I do self.app.stdin.write(incoming). [20:37:33 CEST] <kepstin> well, it did get enough input to detect the file format and print logs about that [20:37:44 CEST] <rev0n> kepsting: sorry, but it's not clear for me. I am total newbie to ffmpeg unfortunately, and I just try to get going with it. The js script which is MediaRecorder API is sending chunks of video every 3 seconds. [20:39:47 CEST] <rev0n> kepsting: I left the script going in the background and actually after few minutes (without any input from me) I got another part of log just came up out of nowhere: https://pastebin.com/1RP3LdUW [20:40:27 CEST] <kepstin> rev0n: that all seems to be working as expected, the vp9 encoder that it's using has a fair delay to start up. [20:40:33 CEST] <kepstin> and is probably kinda slow [20:40:39 CEST] <kepstin> you might want to use "-c:v copy"? [20:42:32 CEST] <rev0n> kepsting: another thing is that if I set the script to send packets every 300ms ffmpeg is not able to read the type. However if I just write incoming bytes as a file with Python (not using ffmpeg, just file.write()) I get perfectly readable webm file of length of js script sending interval. [20:42:46 CEST] <rev0n> trying that just now [20:45:54 CEST] <rev0n> kepstin: When adding -c:v copy I get the following: https://pastebin.com/TRTCF91U [20:47:19 CEST] <kepstin> well, the pts issue is because of the weird segmentation, i guess, i assume that's why you had -fflags +genpts before? [20:47:53 CEST] <rev0n> yes, but they changed nothing. Will try them once more [20:48:53 CEST] <kepstin> you could also use the -r input option to override the framerate and write new pts values [20:49:59 CEST] <rev0n> Tried with gents and the log looks just the same. [20:52:41 CEST] <rev0n> -r doesn't change a thing [20:53:39 CEST] <rev0n> ['ffmpeg', '-fflags', '+genpts', '-r', '24', '-y', '-i', '-', '-r', '24', '-c:v', 'copy', '-an', 'new.webm'] still getting Non-monotonous DTS [20:54:43 CEST] <kepstin> oh, huh, that's dts not pts [20:54:46 CEST] <rev0n> right now, my new.webm file is growing (~7mb so far), but it's still unreadable to vlc [20:54:51 CEST] Action: kepstin doesn't know the bet way to handle that [20:55:49 CEST] <rev0n> any ideas how to handle it? [20:58:14 CEST] <rev0n> when trying to run the file in VLC nothing happens, when using native ubuntu movie app it shows "gstreamer error, general stream error" [20:58:27 CEST] <kepstin> this is a bit weird, because I guess with each of the segments you're generating in the browser, it's encoding a completely new block separately [20:58:56 CEST] <kepstin> it might need special handling to concatenate the pieces, since i guess they're webm fragments rather than a single webm file? [20:59:12 CEST] <kepstin> re-encoding the video would probably work [20:59:30 CEST] <kepstin> (of course, vp8/9 encoder is pretty cpu intensive) [21:00:15 CEST] <rev0n> they are webm fragments, that's correct. when console.log the piece of data that's being sent to server I get in console: Blob {size: 356630, type: "video/webm"} [21:00:31 CEST] <rev0n> size vary with each piece of data [21:01:00 CEST] <rev0n> how can I do the re-encoding? again sorry for newbie question, but again... I'm a newbie :) [21:01:38 CEST] <kepstin> well, you do re-encoding by setting -c:v to something other than copy... or omitting it completely, in which case ffmpeg will re-encode to some 'default' codec for the format. [21:01:47 CEST] <kepstin> for webm, that's vp9 [21:02:23 CEST] <kepstin> from your previous output, it was only managing 0.1fps with the default vp9 encoder settings, so you either need a faster computer or a bunch of settings tweaking to get that working. [21:04:06 CEST] <rev0n> well, that would be strange if my machine has unsufficient resources, and I'm running 6-cores AMD FM @ 3,6 GHz, 16 Gigs of RAM, and some SSD drives (if that matters) [21:07:08 CEST] <rev0n> ok, I tried -c:v vp9 and I get the following: https://pastebin.com/MXYxZmU6 [21:07:28 CEST] <rev0n> file on disk is still unreadable and seems suspiciously small [21:07:38 CEST] <kepstin> hmm, 6fps [21:07:55 CEST] <kepstin> it should be readable tho, with that ffmpeg version [21:08:23 CEST] <kepstin> actually, it hasn't output much video yet, probably a fair bit buffered in the encoder [21:08:35 CEST] <rev0n> oh, ok, it is readable [21:08:48 CEST] <rev0n> very low quality tho [21:08:58 CEST] <rev0n> but it's not important at this point [21:09:11 CEST] <kepstin> well, you didn't tell it what quality settings to use, so it's just some random defaults [21:10:51 CEST] <rev0n> random defaults will do just fine for now. I don't care about quality, but about making it work at all :P file is readable, but it works really slow. Currently I wait about 1 minute for any output and nothing really happens [21:11:48 CEST] <kepstin> yeah, the default encoder settings will run really slow (note the 6fps figure, which is probably much slower than the original video was captured), and buffer a lot of frames (which is ok for saving to a file, but not if you're transmitting somewhere else in realtime) [21:12:13 CEST] <rev0n> the new log: https://pastebin.com/YvSm3fh2 [21:12:35 CEST] <rev0n> again for the appearing of "frame=" log entries I've waited about 1-2 minutes [21:12:52 CEST] <rev0n> How can I speed it up for the live broadcast? is it possible? [21:13:06 CEST] <kepstin> what's your final goal gonna be? [21:13:09 CEST] <rev0n> or any workarounds? [21:13:17 CEST] <kepstin> i don't imagine it's saving to a webm file on disk :) [21:14:08 CEST] <kepstin> right now it's slow because of the use of a vp9 encoder without any tuning. But it's only using that because you're writing to a webm file, if you're planning to e.g. to hls or rtmp streaming, then you'd be using a different encoder entirely [21:14:44 CEST] <rev0n> My goal is to getUserMedia (js) -> send to websocket -> ffmpeg gets data from websocket -> ffmpeg converts the data to flv and sends it over rtmp to my live transmission server on nginx [21:15:34 CEST] <kepstin> ok, so for testing you could do something like write to a local flv file, something like "-c:v libx264 -tune veryfast -f flv local-test-file.flv" [21:15:51 CEST] <rev0n> just trying [21:15:57 CEST] <kepstin> er, "-preset veryfast", typo [21:18:03 CEST] <rev0n> like this? ['ffmpeg', '-y', '-i', '-', '-c:v', 'libx264', '-preset', 'veryfast', '-f', 'flv', 'local-test-file.flv'] [21:18:44 CEST] <kepstin> sure, although you might want to leave the '-an' if you don't want audio - or add "-c:a aac -b:a 128k" or something if you want to keep the audio. [21:20:26 CEST] <rev0n> kept -an to make things simplier [21:20:48 CEST] <rev0n> again waiting for about 1 minute and it hangs on "stream mapping ...." [21:21:35 CEST] <rev0n> at this point local-test-file.flv has about 271 bytes [21:21:56 CEST] <kepstin> x264 still has a lot of frame buffering internally - around 250 frames by default, i think. You can try adding "-tune zerolatency" to disable that (at a fair bit of quality loss) [21:22:39 CEST] <JEEB> definitely not 250 [21:22:59 CEST] <JEEB> around 60 or less + frame threading delay [21:23:24 CEST] <DHE> 60 is about right. maybe 250 if you use preset placebo or something [21:24:03 CEST] <kepstin> oh, i'm getting confused with the gop size [21:24:04 CEST] <rev0n> not really promising: https://pastebin.com/r7GkeFn5 [21:24:10 CEST] <furq> is it lookahead plus threads [21:24:13 CEST] <furq> or thereabouts [21:26:53 CEST] <kepstin> right, default lookahead is 40 frames at medium, 60 at 'slower' through 'placebo', and reduces by 10 for each faster preset. [21:28:26 CEST] <rev0n> and after another few minutes it crapped out another part of "frame=" entries: https://pastebin.com/H3uyRgNR [21:28:32 CEST] <rev0n> file is readable [21:31:44 CEST] <rev0n> banging my head agains the wall right now... [00:00:00 CEST] --- Fri Jul 28 2017

1 0

ffmpeg-devel.log.20170726
by burek 27 Jul '17

27 Jul '17

[01:18:09 CEST] <cone-695> ffmpeg 03Muhammad Faiz 07master:c8305079dae1: avcodec/rdft: reorder calculation [03:37:02 CEST] <tdjones> atomnuker: Do you have a sample with excessive clicking with the vorbis psy patch? I want to make sure I've fixed what you are hearing before I resubmit. [03:38:28 CEST] <atomnuker> yep, sure [03:41:27 CEST] <tdjones> I think it may be due to scaling the audio based on framesize before the mdct, I have a clip-avoidance patch that may help prevent it. [03:41:34 CEST] <atomnuker> tdjones: original: https://pars.ee/temp/sample_click.wav encoded with -q:a 0.9 https://pars.ee/temp/test_click.ogg [03:42:54 CEST] <tdjones> Thank you, I'll try to fix this by morning [03:43:36 CEST] <atomnuker> take your time, if it requires tuning it'll take a while [11:34:24 CEST] <jcelerier> if I want to get the length of an audio file (of most common formats : mp3, ogg, flac, wav...) is there a way to do it without parsing the whole damn thing ? [11:56:02 CEST] <jcelerier> seems not... [11:56:11 CEST] <jcelerier> ah sorry, wrong channel [12:54:34 CEST] <kierank> hmm where is wm4 when you need him [12:57:18 CEST] <JEEB> on holidays [13:00:59 CEST] <Shiz> since when does he rest [14:35:50 CEST] <Compn> jcelerier : unfortunately, headers lie, files are incomplete, and bitrates are variable. [16:34:23 CEST] <cone-864> ffmpeg 03James Almer 07master:4cebf0fc456c: avutil/frame: add ICC Profile to av_frame_side_data_name [16:34:24 CEST] <cone-864> ffmpeg 03James Almer 07master:5e4e9afaa127: ffprobe: add support for ICC Profile frame side data [16:34:25 CEST] <cone-864> ffmpeg 03James Almer 07master:c220fe008c5a: avcodec/webp: add support for ICCP chunks [17:05:13 CEST] <feliwir> hey, my custom io context is crashing, can someone take a look? [17:05:18 CEST] <feliwir> line 65: https://gist.github.com/feliwir/951b883167eda0c4ab2964e2f9ef3adf [17:07:58 CEST] <cone-864> ffmpeg 03Michael Niedermayer 07master:74c1c22d7f0d: avcodec/hevc_ps: fix integer overflow in log2_parallel_merge_level_minus2 [17:07:59 CEST] <cone-864> ffmpeg 03Michael Niedermayer 07master:1b0060031950: avcodec/jpeg2000dec: Fix division by zero in jp2_find_codestream() [18:10:48 CEST] <J_Darnley> atomnuker: kierank wants me to ask you if you have any more thoughts about why this transform is rubbish [18:10:54 CEST] <J_Darnley> http://imgur.com/a/4wWX6 [18:11:32 CEST] <J_Darnley> The three images show the 5_3 transform with increasing wavelet depth, from 1 to 3 [18:12:00 CEST] Action: durandal_1707 coding in pure asm [18:12:09 CEST] Action: J_Darnley wishes he was [18:12:55 CEST] <J_Darnley> He thinks it might be something about offsets. Perhaps I'm doing the transform on incorrectly positioned slices. [18:13:09 CEST] <J_Darnley> I don't think so because haar works perfectly. [18:13:39 CEST] <J_Darnley> but then haar can be used as a block transform. [18:15:15 CEST] <J_Darnley> The other transforms require neighbouring data, which we have in ffmpeg because I am doing them in the whole plane. [19:16:46 CEST] <J_Darnley> kierank and I may have just identified the issue. The transform function copies out of the source buffer. [19:17:09 CEST] <J_Darnley> Now I just need to reimplemt that transform. Shit! [19:59:34 CEST] <cone-864> ffmpeg 03Clément BSsch 07master:2ba20d799ad2: lavc/htmlsubtitles: simplify 1-char tags case insensitive test [20:17:57 CEST] <atomnuker> J_Darnley: looks like a stride issue somewhere [20:21:39 CEST] <J_Darnley> nah. [20:22:15 CEST] <J_Darnley> it is (probably) the "additional precision" copying at the beginning of 5_3 and 9_7 [20:23:07 CEST] <J_Darnley> they copy the samples within the slice boundaries out of the plane meaning we don't have the neighbor samples available [22:17:47 CEST] <cone-864> ffmpeg 03foo86 07master:56277f6d1905: avcodec/dolby_e: add 'f' suffixes to floating point literals [22:17:48 CEST] <cone-864> ffmpeg 03foo86 07master:0689cc247555: avcodec/dolby_e: add AV_CODEC_CAP_CHANNEL_CONF capability [22:17:49 CEST] <cone-864> ffmpeg 03foo86 07master:5e715b583dab: avcodec/dolby_e: fix potentially undefined pointer arithmetic [22:17:50 CEST] <cone-864> ffmpeg 03foo86 07master:6029b8a6bbc8: avformat/s337m: fix potentially undefined pointer arithmetic [00:00:00 CEST] --- Thu Jul 27 2017

1 0

ffmpeg.log.20170726
by burek 27 Jul '17

27 Jul '17

[00:14:11 CEST] <wondiws2> dystopia_, it was a wrong rip, now I can extract the audio again [00:30:52 CEST] <furq> wondiws2: use pgcdemux or tccat to extract a single title [00:56:46 CEST] <nicolas17> how do I extract and concatenate multiple time segments of a video? like if I want to grab from 1:00 to 2:05 and then from 2:45 to 3:15 [01:14:15 CEST] <b0bby__> Hello [01:14:39 CEST] <nicolas17> ohh -f concat [01:14:41 CEST] <nicolas17> that's handy [01:15:35 CEST] <b0bby__> Does anyone have experience with RTMP [01:15:38 CEST] <b0bby__> ?? [01:30:02 CEST] <b0bby__> Is anyone online? [01:55:12 CEST] <b0bby__> Hello [03:28:40 CEST] Action: redrabbit /o/ \o/ \o\ [04:02:52 CEST] <stapler> horribly vague and broad question, but how am i supposed to handle packet loss while decoding? [04:03:37 CEST] <stapler> or reordering of packets [04:04:17 CEST] <atomnuker> give lavc the next available packet, if it can it'll produce a somewhat corrupted frame [04:04:35 CEST] <atomnuker> reordering packets due to networks? yourself lol [04:04:43 CEST] <stapler> :s [04:04:57 CEST] <stapler> is it worth trying to drop corrupted frames entirely? [04:06:17 CEST] <atomnuker> if that happens you'll get AVERROR_INVALIDDATA returned [04:06:35 CEST] <atomnuker> when you try to decode it [04:06:41 CEST] <furq> TD-Linux: did you run that ffv1 vs flif test with -context 1 [04:06:46 CEST] <stapler> ah ok [04:06:46 CEST] <furq> i got better results with that [04:06:57 CEST] <stapler> >reordering packets due to networks? yourself lol [04:07:03 CEST] <stapler> would you mind throwing me a bone, please? [04:07:14 CEST] <stapler> or just google it [04:07:16 CEST] <TD-Linux> furq, I used -coder range_tab [04:07:16 CEST] <stapler> :-) [04:07:23 CEST] <furq> yeah i got better results using both [04:07:36 CEST] <furq> 10751320 vs 11147747 [04:07:40 CEST] <furq> still worse than flif though [04:08:27 CEST] <furq> http://vpaste.net/I4KKd [04:08:36 CEST] <furq> idk why i didn't just link that instead of typing it out [04:08:49 CEST] <atomnuker> stapler: never done it myself, from what I remember you cache packets until the next logical sequence number is found [04:09:01 CEST] <furq> also i assume the h264/h265 ones are wrong somehow because otherwise heif is going to suck ass [04:09:12 CEST] <furq> technically as well as for all the reasons it does suck ass [04:09:17 CEST] <atomnuker> unless you use libavformat, that'll handle out of order packets for you [04:09:23 CEST] <stapler> atomnuker, lavc wont buffer them for m-- [04:09:26 CEST] <stapler> ah [04:09:29 CEST] <stapler> i see [04:10:01 CEST] <TD-Linux> furq, I'm pretty sure heif targets lossy mode only [04:14:04 CEST] <TD-Linux> and yeah h264/h265 lossless mode is mostly a "because we can" feature [04:14:28 CEST] <TD-Linux> especially for single images, where the one advantage over ffv1 (motion compensation) is nulled [04:17:45 CEST] <atomnuker> ffv1 got that now though, at least the v4 [04:18:47 CEST] <furq> TD-Linux: oh [04:18:50 CEST] <furq> that explains it then [04:19:18 CEST] <furq> i was just surprised that vp8 outperformed it, but i guess webp has specifically worked on that use case [04:19:53 CEST] <TD-Linux> webp's lossless encoder is totally different than vp8 [04:20:06 CEST] <furq> i feel like someone already told me that and i forgot it [04:20:06 CEST] <TD-Linux> also only vp9 has a lossless mode [04:20:52 CEST] <TD-Linux> vp9's lossless mode is mostly in the same bin as h264's (it does have a special transform for lossless, but that's it) [04:21:11 CEST] <furq> so when is someone going to create a wonderful new ffv1 image format that everyone will immediately support and use [04:22:13 CEST] <furq> you could call it ffi [04:22:19 CEST] <atomnuker> you don't need to create anything [04:22:24 CEST] <furq> and guess what the library that encodes it is called [04:22:29 CEST] <TD-Linux> no [04:22:33 CEST] <furq> that's right [04:22:34 CEST] <furq> it's called z.lib [04:22:38 CEST] <atomnuker> just put a single ffv1 packet in mkv and its done [04:22:49 CEST] <furq> will any image viewer want to know about that shit [04:22:53 CEST] <TD-Linux> how do you put EXIF in mkv [04:22:57 CEST] <furq> also yeah that [04:22:58 CEST] <TD-Linux> actually don't tell me I don't want to know [04:23:06 CEST] <furq> i suspect the answer involves a lot of xml [09:12:14 CEST] <twosee> I'm looking to merge n video files, but all the concat methods I'm looking into result in audio desyncing [09:12:41 CEST] <twosee> Answers like https://stackoverflow.com/a/34918815/2049141 (transform each video to the same fps and timescale) don't seem to help [11:56:52 CEST] <jcelerier> does someone knows how AVCodecContext::request_sample_fmt is supposed to work ? I've set it to AV_SAMPLE_FMT_FLTP before av_read_frame, but still get ints in the data [12:04:25 CEST] <durandal_1707> jcelerier: not all decoders allow different formats [12:24:59 CEST] <jcelerier> okay, so I have to do the conversion myself [12:53:50 CEST] <maziar> hey guys, how should I fix this error on debian stretch : "Unknown encoder 'libvo_aacenc'" [12:57:00 CEST] Last message repeated 1 time(s). [13:02:22 CEST] <thebombzen> maziar: stop using libvo_aacend [13:02:29 CEST] <thebombzen> just use the native encoder [13:02:30 CEST] <thebombzen> aac [13:02:41 CEST] <maziar> thebombze how ? [13:02:53 CEST] <maziar> thebombzen this is my ffmpeg command [13:03:26 CEST] <thebombzen> whatever you're about to type, replace "libvo_aacenc" with "aac" [13:03:28 CEST] <thebombzen> and then try that [13:04:08 CEST] <maziar> ffmpeg -i file1 -b:a 2500k -s 426x240 -vcodec libx264 -hls_list_size 0 -acodec libvo_aacenc -ab 128k -ar 44100 -hls_time 4 file2.m3u8 [13:04:41 CEST] <maziar> aac is better ? [13:04:55 CEST] <maziar> thebombzen "aac" codec is better ? [13:05:30 CEST] <thebombzen> Yes [13:17:51 CEST] <yns> hi [13:18:21 CEST] <yns> can I stream copy and split by file size? [13:19:35 CEST] <yns> instead of splitting by half an hour -c copy -t 00:30:00 I'd like to split into, say, 300MB chunks [14:02:04 CEST] <DHE> maziar: in general hardware encoders are poorer quality than software encoders when using defaults [15:37:29 CEST] <maziar> I am using ffmpeg in shell script but && is not working after that, why ? [15:40:19 CEST] <DHE> that's a shell command, not an ffmpeg command. can't help you if you're not WAY more specific [17:14:38 CEST] <Mavrik> Hmm, does ffmpeg include a faster deinterlacer than yadif? [17:20:15 CEST] <furq> w3fdif is faster [17:20:56 CEST] <furq> separatefields,setdar is the fastest, but it hardly qualifies as a deinterlacer [17:33:20 CEST] <Mavrik> Yeah, just separating fields isn't enough. [17:36:14 CEST] <furq> huh [17:36:26 CEST] <furq> maybe i'm doing something wrong here but mcdeint=slow is even slower than nnedi and still looks like garbage [17:53:47 CEST] <arpu> hey how can i set the connection timeout on a rtmp connection ? (without librtmp) [19:02:11 CEST] <jcelerier> does swresample support in-place conversion ? [19:10:16 CEST] <DHE> I don't think so. the sample sizes and number of channels can change which would make this impractical [19:26:46 CEST] <thebombzen> what about hardware-deinterlacers-in-the-decoder [19:26:50 CEST] <thebombzen> like cuda [19:26:54 CEST] <thebombzen> how do those compare to yadif [19:37:41 CEST] <Accord> hey, is there any way to automatically adjust bitrate based when streaming to youtube? [19:38:23 CEST] <Accord> so for example if my connection drops from 2 mbps to 1mbps I would like the bitrate to drop aswell [19:43:58 CEST] <Mavrik> That's not how that works :/ [19:44:15 CEST] <Mavrik> In other words - I don't know of a software that could do that from streamer side. [19:44:28 CEST] <DHE> it's not something ffmpeg handles natively. you'd have to write or use an app that does support that feature explicitly [19:45:24 CEST] <Mavrik> I also doubt you can really do it since as a sender you don't know much about network performance. [19:45:40 CEST] <Mavrik> (Unless you get info back from client) [19:45:59 CEST] <DHE> if it's streaming over TCP, you can see the buffering in the network layer and/or the blocking writes as a hint that something's wrong [19:49:24 CEST] <Blubberbub> isn't that what rtsp is for? (i thought so - but i have no clue_ [20:12:30 CEST] <Accord> ok but can I atleast have ffmpeg exit if there's major network issues? [20:12:33 CEST] <Accord> right now it seems to hang [20:12:44 CEST] <Accord> doesn't seem to transmit anything or encode [22:07:37 CEST] <jcelerier> thanks DHE [23:57:02 CEST] <stapler> is there a good primer to read before starting to use lav? [23:57:16 CEST] <stapler> or anything about lav itself? i think i understand the process of what i want to do, just not the calls exactly, heh [23:59:38 CEST] <Mavrik> well, there are examples in docs dir [00:00:00 CEST] --- Thu Jul 27 2017

1 0