Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

October 2018

1 participants
62 discussions

ffmpeg-devel.log.20181005
by burek 06 Oct '18

06 Oct '18

[00:16:27 CEST] <cone-276> ffmpeg 03Paul B Mahol 07master:d39fae08866e: avfilter/avf_showspectrum: fix scaling in zoom mode [02:27:31 CEST] <tmm1> jkqxz: the cbs patchset (https://github.com/fhvwy/FFmpeg/commits/cbs) no longer builds with master after 300ef253141fbebf9b201de676db1bb9e4298c40 [02:47:16 CEST] <tmm1> (the i'm also trying to make sense of this intermittent crash with that patchset, if anyone has an idea of what it could be: http://0x0.st/sYRW.txt [05:11:12 CEST] <cone-398> ffmpeg 03Pavel Koshevoy 07master:03123e4053d6: lavfi/atempo: fix tempo range limit inconsistency [12:03:54 CEST] <cone-210> ffmpeg 03Paul B Mahol 07master:3e687be4faa6: avfilter/avf_showspectrum: add green color map [14:18:39 CEST] <nevcairiel> BBB: i thought about your question re: hwaccel with dav1d, and ultimately it would just need to expose the same sort of information and hooks that we make the avcodec decoders give to the hwaccel, except in this case in public API, I guess [14:20:37 CEST] <nevcairiel> plus of course being able to handle opaque frames with a caller-specified free callback [14:21:32 CEST] <BBB> thats what I was hoping for, yes [14:21:46 CEST] <BBB> I think most of the information you want is in levels.h [14:21:50 CEST] <BBB> and is not changing much [14:22:01 CEST] <BBB> you may need parts of internal.h Dav1dContext, but not that much I expect [14:22:07 CEST] <nevcairiel> what we really need we wont know until the hw people define us an API [14:22:26 CEST] <nevcairiel> but generally speaking, everything from sequence and frame headers in raw uninterpreted form [14:23:44 CEST] <BBB> yes, thats in levels.h [14:23:50 CEST] <BBB> Im considering opening it up entirely already [14:23:52 CEST] <BBB> since its there anyway [14:23:57 CEST] <BBB> might just as well show it, right? [14:26:31 CEST] <nevcairiel> and of course a variety of hooks in the decoding process, namely in avcodec terms: get_format, called whenever the frame format changes (size, bitdepth, chroma) - preferably only when it changes, and not too often, get_buffer to provide custom-allocated frames, and a decode hook that gets passed the entire frame data (including uncompressed headers, and all that), and circumvents actual software decoding [14:27:02 CEST] <BBB> of course [14:28:45 CEST] <nevcairiel> it'll probably be a bit more time until some of the hardware APIs even get support for this, but if you're open to putting this in, we could possibly make this work [14:35:45 CEST] <atomnuker> pointless as by then <i>someone</i> will have ported dav1d to lavc [14:36:38 CEST] <durandal_1707> but that is pointless as everybody are switching to rust [14:39:14 CEST] <gnafu> But switching to Rust is pointless because everyone is actually switching to quantum computers. [14:40:52 CEST] <cone-210> ffmpeg 03Paul B Mahol 07master:fe447c0609cd: avfilter/avf_showspectrum: add zoom mode to showspectrumpic [14:41:48 CEST] <TD-Linux> yeah I don't see anything wrong with exposing AV1FrameHeader and AV1SequenceHeader. there is no reason for them to break ABI [14:41:58 CEST] <TD-Linux> exposing Av1Block would be weird though [14:42:48 CEST] <BBB> nevcairiel: absolutely open to it, yes [14:42:58 CEST] <BBB> Im not sure you need Av1Block [14:43:03 CEST] <BBB> since the block coding would happen in hw [14:43:07 CEST] <BBB> they dont need access to sw internals [14:43:13 CEST] <BBB> I think? [14:44:25 CEST] <TD-Linux> I think that's correct [14:44:34 CEST] <TD-Linux> but more importantly exposing Av1Block would hinder future optimizations [15:24:36 CEST] <cone-210> ffmpeg 03Paul B Mahol 07master:50a2347b1949: avfilter/avf_showspectrum: increase padding size for low sample rates [16:15:10 CEST] <atomnuker> bofh_: ping [16:47:56 CEST] <January> Re-based a patchset which extracted timecodes from pic_timing in h264, trying to add support for extracting up to 3 timecodes per pic_timing SEI. Having issue with threading (-threads 1 works). https://0x0.st/sYFX.log (without -threads 1). https://github.com/januaryjp/FFmpeg/commit/b2f45ae089ea4c5e03a701d6c5f4c2e1… [16:48:03 CEST] <January> Unsure how I'd make it thread-safe [16:56:00 CEST] <kierank> January: it's weird because captions should be thread safe [16:57:55 CEST] <kierank> January: also try tsan [17:28:31 CEST] <durandal_1707> what happened to new lavfi api? [17:39:40 CEST] <atomnuker> you haven't proposed one? [18:29:58 CEST] <kierank> January: memcpy(tcside->data, &tc, sizeof(uint32_t)); [18:29:59 CEST] <kierank> looks dubious [18:30:28 CEST] <kierank> tc is int64 [18:31:59 CEST] <January> unsure why the original patch used int64, guess could make tc uint32 but i removed the memcpy anyway [18:32:49 CEST] <kierank> does it help [18:35:07 CEST] <January> no [18:38:27 CEST] <kierank> I think side data is totally broken [18:38:35 CEST] <kierank> michaelni: how is side data guaranteed to be accurate? [18:45:45 CEST] <durandal_1707> michaelni is busy, do not disturb him [18:47:34 CEST] <BBB> wut [18:48:12 CEST] <kierank> January has discovered side data is not frame accurate [18:48:16 CEST] <kierank> with frame threads [19:08:28 CEST] <lotharkript_> sorry to ask again, but commit http://git.videolan.org/?p=ffmpeg.git;h=ddef3d902f0e4cbd6be6b3e5df7ec158ce5… enabled passing through of rotation side data from input to output using stream side data. This is an issue when using HW filter to rotate, because we have no way of clearing this side data after rotation. Is there a way to clear stream side data for output, from command line ? [19:11:53 CEST] <durandal_1707> lotharkript_: sidedata filter? [19:12:21 CEST] <lotharkript_> do we have one for stream side data? [19:12:28 CEST] <lotharkript_> it is not in the avframe [19:13:34 CEST] <lotharkript_> mp4 muxer get it from av_stream_get_side_data [19:14:15 CEST] <lotharkript_> if you want to use HW filter, you have to add the option -noautorotate in the cmd line (so, the software rotation is not inserted) [19:14:28 CEST] <lotharkript_> but that will copy the stream_side data to the output. [19:17:58 CEST] <durandal_1707> lotharkript_: no way AFAIK, send patch to fix it, adding function to remove stream side data and update ffmpeg utility [19:18:50 CEST] <lotharkript_> i can add the function to remove side data, but the filter should be the one to remove the side data or at least update it. [19:19:03 CEST] <lotharkript_> the problem is that filter does not have access to avstrem, no? [19:20:05 CEST] <durandal_1707> no, filters deals with frames only [19:20:29 CEST] <lotharkript_> exactly, so how do you specify you do want to add/remove/update avstream side data? [19:20:53 CEST] <lotharkript_> i'm ok to do the code, just want to talk about the correct way first [19:20:54 CEST] <durandal_1707> so you would not deal with filters, but with ffpeg -remove_this_stream)side_data [19:21:26 CEST] <lotharkript_> ok.. So, you suggest to add options in the command line to update stream_side_data? [19:21:52 CEST] <durandal_1707> something like that, if you have better idea - i'm all ears [19:26:20 CEST] <kierank> durandal_1707: can you fix side data frame accuracy [19:26:28 CEST] <lotharkript_> This is what we though as well, but before coding it, wanted to check with you all [19:44:22 CEST] <tmm1> it seems that get_bits() and UPDATE_CACHE don't do bounds checking even when checked mode is enabled? [19:45:15 CEST] <nevcairiel> we require all compressed input to be padded, in any case [19:47:50 CEST] <tmm1> ah, i dont think the cbs userdata patches have padding [19:58:13 CEST] <tmm1> how much padding is used? [19:58:43 CEST] <JEEB> AV_INPUT_BUFFER_PADDING_SIZE I think? [19:58:49 CEST] <jamrial> yes [20:04:28 CEST] <durandal_1707> kierank: i think one would need to reorder captions anyway? [20:04:41 CEST] <kierank> exactly [20:04:45 CEST] <kierank> it's broken with threads [20:04:54 CEST] <kierank> might have worked by chance before [20:07:32 CEST] <durandal_1707> lotharkript_: what about sharing all samples that do not decode with latest ffmpeg? [20:08:22 CEST] <lotharkript_> durandal_1707: which samples are you talking about? [20:10:15 CEST] <durandal_1707> lotharkript_: any sample :) [20:11:09 CEST] <lotharkript_> most are user data, so under GDPR, i cannot share them. [20:14:37 CEST] <durandal_1707> lotharkript_: can you share info about which container and codec is in? [20:15:25 CEST] <lotharkript_> if i found some, i think i can let you know. [20:17:04 CEST] <lotharkript_> one thing you may want to ask michael is the coverage result from oss-fuzz. There are a LOT of codecs where the coverage is under 25% [20:23:05 CEST] <tmm1> thanks. looks like ASAN agrees there's a heap overread, so the padding is definitely missing [20:23:46 CEST] <JEEB> coolio [20:24:00 CEST] <JEEB> just means when it gets allocated it needs some padding love [20:24:36 CEST] <tmm1> might be tricky to do since i think its just creating a GBC off the original stream [20:24:59 CEST] <JEEB> yea, probably :) [20:25:02 CEST] <tmm1> http://0x0.st/sgsr.txt [20:25:07 CEST] <JEEB> so there might have to be memcpy somewhere [20:25:17 CEST] <tmm1> yea, ugh. [20:25:25 CEST] <JEEB> inorite [20:25:31 CEST] <tmm1> man asan output is nice though, first time i've used it successfully [20:25:54 CEST] <JEEB> yea I need to get to that, since valgrind can be just impossible to use due to the speed overhead [20:28:35 CEST] <tmm1> yay that was easier fix than expected [20:28:42 CEST] <tmm1> - current->user_data_ref = av_buffer_alloc(k); [20:28:42 CEST] <tmm1> + current->user_data_ref = av_buffer_alloc(k + AV_INPUT_BUFFER_PADDING_SIZE); [20:29:12 CEST] <JEEB> yup [20:33:22 CEST] <jamrial> tmm1: memset that padding to 0 as well [20:35:14 CEST] <tmm1> ah good idea, will change to av_buffer_allocz [20:40:53 CEST] <jamrial> just do memset(current->user_data_ref->data + k, 0, AV_INPUT_BUFFER_PADDING_SIZE); instead [20:41:27 CEST] <jamrial> no point zeroing the whole buffer if you're going to immediately write to it afterwards, just to zero the padding [21:32:57 CEST] <tmm1> true, but its only a few bytes. h264 side calls allocz always already too [21:33:13 CEST] <tmm1> also doesn't the kernel zero pages in the background or something, i thought calloc was optimized in certain cases [21:34:10 CEST] <tmm1> i guess anything the kernel does would be for safety across process boundaries, within the process the malloc impl would still need to zero any time a block was reused [00:00:00 CEST] --- Sat Oct 6 2018

1 0

ffmpeg.log.20181005
by burek 06 Oct '18

06 Oct '18

[00:00:58 CEST] <arinov> hi there [00:06:02 CEST] <arinov> is there a way to add realtime audio waveform to the bottom of source video file? [00:07:52 CEST] <tytan> this guy explains it well youtube.com/watch?v=M58rc7cxl_s [00:09:42 CEST] <kepstin> arinov: sure, with a complex filter chain. You'd send the audio track to the 'showwaves' filter, which converts it to a video stream, then use the overlay or vstack filters or something like that to composite it with the video. [00:11:08 CEST] <arinov> it seems i have a quest for a week now) thanks! [00:11:15 CEST] <kepstin> arinov: that said, there's probably tools out there other than ffmpeg that'll might give fancier looking results, ffmpeg's audio visualization stuff is fairly basic. [00:11:36 CEST] <kepstin> but it's doable :) [00:12:18 CEST] <arinov> i need it because i want upload my tracks and my scheduler must do all the works automated, i will get it later [00:12:30 CEST] <kepstin> (also check showspectrum and showfreqs, which are related but show different things about the audio) [00:12:36 CEST] <arinov> so in automation case i see no variants except ffmpeg [00:12:51 CEST] <tytan> you can specify colors with hex values [00:13:16 CEST] <tytan> if you use two complementig colors for each channel you get a white wave where the channels are the same. nice effect [00:15:07 CEST] <kepstin> i don't think the audio visualization filters do transparent output normally? You might want to use the "blend" filter to render the result over your background, something like addition mode might look good. [00:15:19 CEST] <arinov> yeah, i need time to build argument list first [00:15:43 CEST] <arinov> i know ffmpeg can split the video and add something [00:15:54 CEST] <arinov> i also know it can build realtime waveform [00:16:36 CEST] <arinov> so i just need to add the waveform into video with audio track 80/20 approx [00:16:39 CEST] <arinov> so i think ffmpeg is ok with this [00:17:47 CEST] <tytan> have a nice day everyone [02:51:33 CEST] <baffled> Hi folks: I'm hoping someone could give me a clew where to check on a message I'm getting when playing flac files after converting from 'ape' [02:51:49 CEST] <baffled> The message is: [flac @ 0x7f3269c4b6e0]Got unexpected packet after EOF [02:53:11 CEST] <baffled> I'm using mplayer to play the flac file after converting from 'ape to 'flac and then splitting with shntool. I get the message continuously on all the flac files although the hex address changesw from file to file. [02:53:56 CEST] <baffled> I used ffmpeg -i file.ape file.flac and ffmpeg file.ape -map 0:0 file.flac [02:54:17 CEST] <baffled> The result is the same. [02:54:53 CEST] <baffled> Mplayer plays the 'ape' file with no odd messages. [02:56:50 CEST] <relaxed> baffled: pastebin.com the command and output [03:02:46 CEST] <baffled> relaxed: http://ffmpeg.pastebin.com/ gives me a host not found message. [03:04:13 CEST] <relaxed> https://pastebin.com/ [03:15:49 CEST] <baffled> Okay here's the pastbin link https://pastebin.com/JAXmE6vM [03:22:26 CEST] <relaxed> You snipped some of ffmpeg's output. Which ffmpeg version? So it plays fine? You just alarmed at the message? [03:25:08 CEST] <baffled> Ah, sorry my screen's only 64 lines. it's version 4.0.2-2 debian sid. I can past either here or pastbin the entire header if you like. [03:26:51 CEST] <relaxed> does it play/sound fine? [03:27:40 CEST] <relaxed> try playing it with mpv, mplayer's successor [03:27:41 CEST] <baffled> Yeah, it plays great it's just those scrolling messages. [03:32:12 CEST] <baffled> Ah okay ht....Yeah, it plays but I'm getting errors: [ao/alsa] Error received from snd_pcm_avail (-77, File descriptor in bad state)! [03:32:15 CEST] <baffled> (Paused) A: 00:00:07 / 00:37:00 (0%) [03:32:42 CEST] <baffled> It still plays just fine. [03:35:58 CEST] <relaxed> I've noticed those lately too- it has nothing to do with the file [03:36:50 CEST] <relaxed> I think the eof message is probably an mplayer bug [03:37:56 CEST] <baffled> I'd try ffplay but it seems to want to demand a display even with the -vn flag. [03:45:27 CEST] <baffled> Thanks relaxed mpv worked just fine if I let a piece play straight through, so it probably is an mplayer bug. [03:49:16 CEST] <relaxed> you're welcome [08:28:59 CEST] <pingufan> Good morning. [08:30:43 CEST] <pingufan> Can somebody, please help me? I have here a .ts stream with distorted aspect ratio and want to scale it to 1280x720. My ffmpeg scales up to 720 lines, but always keeps the wrong aspect ratio. [08:34:58 CEST] <pingufan> In a first run I crop away black borders (video has black borders on all four sides) and store it as h264 in a new .mkv file. This file plays correctly (with distorted video) [08:35:36 CEST] <pingufan> I use this command: ffmpeg -y -i "/goliath/filme/filmarchiv/Unterhaltung/Unternehmen Petticoat.mkv" -vf crop=512:464:106:56 -c:v libx264 -tune film cropped.mkv [08:37:07 CEST] <pingufan> The resulting video is: Stream #0:0: Video: h264 (High), yuv420p, 512x464 [08:37:38 CEST] <pingufan> Now i need to stretch 512x464 --> 1280x720 [08:38:52 CEST] <pingufan> All descriptions I find show how to do it, but it does not work as it should. [08:40:12 CEST] <pingufan> This is what I currently try: ffmpeg -y -i cropped.mkv -video_size 512x464 -c:v libx264 -crf 22 -x264-params keyint=25 -movflags +faststart -tune film -vf scale=1280x720 test.mkv [08:43:01 CEST] <pingufan> Can somebody, please, help? [08:44:39 CEST] <furq> pingufan: get rid of that intermediate file and use -vf crop=512:464:106:56,setsar=1,scale=1280:720 on the original file [08:46:58 CEST] <pingufan> Again height now too much. width seems to be 1280. [08:47:18 CEST] <furq> pastebin the command and full output [08:47:37 CEST] <pingufan> But the viveo has height of entire screen (My screen is 1920x1200. [08:49:10 CEST] <pingufan> https://pastebin.com/DLPgrUSA [08:49:46 CEST] <pingufan> I started a conversion, pressed then "q", and made the copy/paste [08:50:43 CEST] <furq> try setdar=1 instead [08:50:44 CEST] <furq> or both [08:51:43 CEST] <pingufan> No difference (in both cases) [08:53:25 CEST] <furq> oh [08:53:30 CEST] <pingufan> Stream #0:0: Video: h264 (High), yuv420p, 1280x720 [SAR 18:29 DAR 32:29], SAR 116:187 DAR 1856:1683, 50 fps, 50 tbr, 1k tbn, 100 tbc (default) [08:53:30 CEST] <furq> move setsar=1 after scale [08:54:12 CEST] <pingufan> ffplay shows me 1280x720, but it is not displayed in that size and aspect when I try to pay. [08:54:16 CEST] <pingufan> play [08:54:50 CEST] <pingufan> squeezed horizontally [08:56:10 CEST] <pingufan> do you want to see a screenshot? [08:56:33 CEST] <BtbN> it is playing it according to the SAR and DAR. [08:57:14 CEST] <furq> pingufan: like i said, move setsar=1 after scale [08:57:29 CEST] <furq> -vf crop=512:464:106:56,scale=1280:720,setsar=1 [08:58:28 CEST] <pingufan> (y) Now it is correct. [08:59:01 CEST] <furq> also add -c:a copy unless you actually want to reencode the audio [09:00:50 CEST] <pingufan> In scenes with higher motion I see horizontally staggered edges. [09:02:29 CEST] <pingufan> Does this come from upscaling or interlacing? [09:03:56 CEST] <pingufan> seems to come from interlacing (or looks like that). [09:06:47 CEST] <pingufan> I placed yadif as first video filter. This solved it. [09:07:14 CEST] <pingufan> Thank you so much for your helping. [11:00:49 CEST] <keglevich> hey all... I'm searching for a compiled version of ffmpeg (x86 or x64) for windows with pthreads enabled? Is there an option to get a link to a working build, no matter which version? [11:01:28 CEST] <BtbN> There are no pthreads on Windows. It will alaways be emulated to win32threads anyway [11:02:47 CEST] <Mavrik> Yeah, that's a rather strange requirement. [11:02:52 CEST] <keglevich> I compiled one myself (v4.0.2) with --disable-s32threads, but I have a strange issue... no matter which value I set for bitrate UPD output parameter, the output UDP speed is always 1.3 - 1.4mbit/s, and the stream crashes after about 10secs with "cannot allocate memory" fatal error... If I run that same build without "bitrate" output parameter, it works just fine [11:02:56 CEST] <Mavrik> If you really need that, run the linux ffmpeg inside WSL ? [11:03:28 CEST] <keglevich> I need pthreads build on windows as it can produce almost perfect CBR, using additional UDP output parameters [11:03:34 CEST] <BtbN> And what makes you think that's related to pthreads? [11:03:37 CEST] <keglevich> with w32threads version it seems impossible [11:03:48 CEST] <BtbN> Again, there are no pthreads on Windows [11:04:10 CEST] <keglevich> strange is...when I have another service enabled on same system (tightvnc service for instance), the bitrate parameter is accepted ok and works at expected bitrate value [11:04:18 CEST] <keglevich> I don't have an explanation for this [11:05:49 CEST] <keglevich> btbn: you say there are no pthreads on windows... what then --disable-w32threads does? I compiled a working version, but it works strange [11:06:47 CEST] <keglevich> or let me ask another way...is there an option then to somehow use UDP output parameters with w32threads version? Or maybe somehow else achieve to have pefect UDP output? [11:06:56 CEST] <keglevich> ffmpeg -re -i 1.mp4 -g 50 -c:v libx264 -preset veryfast -x264opts nal-hrd=cbr -b:v 2200k -minrate 2200k -maxrate 2200k -bufsize 260k -muxrate 2600k -pcr_period 30 -c:a mp2 -ac 2 -b:a 192k -ar 48000 -f mpegts "udp://239.1.1.1:10000?pkt_size=1316&bitrate=2600000" [11:07:21 CEST] <Foaly> i guess that option would then disable threading [11:07:30 CEST] <keglevich> this is the command I'm using...without bitrate UDP ourput parameter, the stream is not "perfect" CBR, it has some spikes and bursts all the time (about +- 10%) [11:09:09 CEST] <keglevich> with "bitrate" output parameter, stream is nice CBR, but only works if there is some other TCP/UDP service running on the same system (like tightvnc service for instance)... on a clean install OS, it'll run at about 1.4mbit/s and crash after 10secs... I know this is super strange [11:09:23 CEST] <keglevich> I tried on 10+ different PC's, different OS's [11:10:30 CEST] <keglevich> that's why I'm searching for another build with w32-threads disabled for windowd so I can at least compare the behaviour [11:12:11 CEST] <BtbN> udp.c has some pthread specific code it seems [11:12:19 CEST] <BtbN> that just does not work on Windows, due to lack of pthreads. [11:13:27 CEST] <BtbN> No idea if some pthread emulation can serve the same purpose, you'll have to try that yourself. [11:15:10 CEST] <keglevich> BtbN: you have any clue why this strange behaviour I was writing about abowe? [11:15:40 CEST] <BtbN> Likely unrelated to threads [11:16:05 CEST] <BtbN> Blame the Windows network stack, or your firewall [11:16:27 CEST] <keglevich> is there maybe another option to make as good as possible CBR with w32threads build? [11:16:44 CEST] <keglevich> firewalls disabled, tried 5+ different NIC's, different OS's [11:24:27 CEST] <ilushka4> hey fella, it's not public [11:37:38 CEST] <durandal_1707> ilushka4: ? [11:38:01 CEST] <ilushka4> durandal_1707, for some reason, I have a rtsp(mms) stream which I can run with windows media player, but cannot run it with ffmpeg (first tried it with ffmpeg-python and then ffplay). I was trying the query: .\ffplay.exe -i "mms://foobar" -f rtsp, but it returns 400 Bad request [11:43:27 CEST] <furq> BtbN: mingw includes a pthread emulation library nowadays [11:43:29 CEST] <furq> winpthreads iirc [11:43:46 CEST] <furq> idk why that would behave differently to just native win32 threads though [11:44:26 CEST] <BtbN> furq, because udp.d, and a bunch of other ffmpeg code, has pthread-only code, so with win32threads it's disabled [11:44:29 CEST] <BtbN> *.c [11:44:54 CEST] <keglevich> furq: by using w32threads version there's no option to use "bitrate" output UDP parameter [11:45:08 CEST] <furq> oh [11:47:17 CEST] <keglevich> as well as some other UDP parameters...pthreads is required to use them [11:47:33 CEST] <BtbN> Use Linux [11:47:48 CEST] <BtbN> If all else fails, use WSL. It definitely has pthreads. [11:48:00 CEST] <keglevich> what is WSL? [11:48:15 CEST] <furq> https://docs.microsoft.com/en-us/windows/wsl/about [11:48:19 CEST] <furq> windows 10 only [11:48:35 CEST] <keglevich> ah ok...linux again [11:48:58 CEST] <furq> it's not that difficult to build ffmpeg [11:49:07 CEST] <furq> especially if the only external lib you need is x264 [11:49:37 CEST] <keglevich> building is not that big of an issue...bigger issue is that I use an win-based app which uses ffmpeg to UDP output [11:50:13 CEST] <keglevich> casparcg...uses shared ffmpeg libs, runs on windows [11:54:14 CEST] <furq> is that not open source [12:00:41 CEST] <keglevich> casparcg is opensource...but I use it in conjunction with another app which is windows only...also there's more, it has to run on windows anyway [12:05:37 CEST] <furq> well i meant that you can build it with whatever build of ffmpeg [12:07:53 CEST] <keglevich> hmm...I'm confused...if I build ffmpeg on linux and use shared libs with windows version of casparcg...will it work? [12:11:41 CEST] <furq> if you cross-compile ffmpeg on linux, sure [12:11:49 CEST] <furq> as long as you can build casparcg with mingw [12:16:24 CEST] <keglevich> casparcg is built with visual studio 2010 [12:16:44 CEST] <keglevich> as far as I know...and it requires redistirbutable .net 2010 [12:41:53 CEST] <RoundHash> I have a sequence of JPG images that I'm trying to convert to a h264 video using "ffmpeg -r 60 -i %05d.jpg -i audio.wav -c:v libx264 -c:a aac video.mp4", but it comes out darker than the input images, anyone able to point me in the right direction here? [12:42:05 CEST] <RoundHash> As an example #0b0b0b is converted to #000000 and #1d1d1d goes to #0f0f0f [12:43:20 CEST] <furq> RoundHash: -vf colorspace=irange=jpeg:range=mpeg [12:45:34 CEST] <RoundHash> I'll give it a go, thanks. What's actually happening that's making the colours change? [12:47:57 CEST] <furq> actually i forgot ffmpeg will default to full range output if the source is jpeg [12:48:01 CEST] <furq> so i'm guessing your player doesn't like that [12:48:05 CEST] <furq> try just -vf format=yuv420p [12:49:16 CEST] <RoundHash> Ha, yeah, you're right. Cool, thanks. So, it's a problem converting between an RBG colour space int he JPEG to a YUV one on the other side? [12:49:18 CEST] <furq> basically jpeg normally uses full range colour values (0-255) and mpeg normally uses limited range (16-235) [12:49:55 CEST] <RoundHash> Oh right, that's kinda interesting, is that just for compression? [12:53:38 CEST] <RoundHash> So, that seems to have worked, but I seem to be getting quite significant artifacts now in the block colour (https://ibb.co/jrq5Oe) whereas I wasn't before [12:54:35 CEST] <furq> that screenshot is blank, but it's probably from using 4:2:0 instead of 4:4:4 [12:54:45 CEST] <furq> you can use yuv444p but that'll make the video much less compatible [12:55:00 CEST] <furq> a lot of devices will only play yuv420p [12:55:43 CEST] <furq> also iirc the 16-235 thing is some legacy thing to provide a buffer between the maximum value and 255, which is used for ntsc sync [12:56:06 CEST] <RoundHash> It is all one dark grey, but if you look carefully you can see the artifacts I'm talking about. [12:56:30 CEST] <furq> oh right [12:56:39 CEST] <furq> that's probably not the problem then [12:56:50 CEST] <RoundHash> Can you see what I mean? [12:56:55 CEST] <furq> yeah [12:57:05 CEST] <furq> you might want to try playing it in mpv [12:58:34 CEST] <RoundHash> I don't have that installed, but (I should have mentioned) that screenshot is from VLC, just tried it in ffplay and it's similar, but the artifacts seem less fine grained. [13:01:40 CEST] <RoundHash> So, you said that this is an MPEG thing, squashing the values to 16-235, I'm definitely not a AV geek, but isn't MPEG different than H.264? [13:03:16 CEST] <RoundHash> Or is it the container format that's messing with it? I has (perhaps incorrectly) assumed that H.264 would be how the video is encoded and the MPEG-4 bit was just how the file was put together and wouldn't affect the actual content of the audio/video? [13:10:58 CEST] <furq> h264 is one of many mpeg codecs [13:11:19 CEST] <furq> although a lot of non-mpeg codecs use limited range as well [13:11:36 CEST] <furq> limited and full range are sometimes called mpeg and jpeg range because that's where you're most likely to find them [13:13:50 CEST] <RoundHash> Oh, I see (should have Googled MPEG first)... [13:16:29 CEST] <RoundHash> Seting the bitrate to 12Mbps helps, bit it's just grainy now [13:55:28 CEST] <Zexaron> Hello [13:56:00 CEST] <Zexaron> got a bunch of photos each month I take of infrastructure projects, tedious to resize, seems like I need some kind of a script [13:56:38 CEST] <Zexaron> maybe ffmpeg can do it instead of going manually in photoshop, or photoshop script, shouldn be easy with batch right? [13:56:49 CEST] <furq> yeah but don't ask me how to write it on windows [13:57:14 CEST] <Zexaron> heh, I did a lot of linux in the past month due to huge maintenance and hardware issues [13:57:22 CEST] <furq> in bash it'd be for f in *.jpg; do ffmpeg -i "$f" -vf scale=123:456:flags=lanczos "${f%.*}_scale.jpg"; done [13:58:09 CEST] <Zexaron> but this is too small of a thing for me to run linux, it's not professional more like amateur enthusiast, I got a few 10-20 per week or less [13:58:28 CEST] <furq> it shouldn't be that hard to translate that into batch [13:58:38 CEST] <furq> but i have spent my entire life avoiding using batch and i'm not stoppingnow [13:59:15 CEST] <furq> fwiw on windows you could use something like irfanview's batch processing [13:59:25 CEST] <Zexaron> Honestly it's not that bad, not like it's unstable or buggy, it may just be lack of features, but I never needed (probably never figured out they exist) so I kinda have a different idea [13:59:45 CEST] <Zexaron> I'm familiar with that, use it for DDS files, since I do gaming/moddding/dev [14:01:25 CEST] <Zexaron> furq: Oh great, batch rename/resize/convert, quite impressive, I never knew about that thing wow, thanks [15:42:50 CEST] <ilushka4> where can I see the log file? I'm trying to run ffplay with rtsp stream, but it retrns 400 Bad Request. Windows media player runs it though [15:45:04 CEST] <Mavrik> ffplay -v verbose (or -v debug) [15:45:10 CEST] <Mavrik> is your best bet [15:45:16 CEST] <Mavrik> ffmpeg doesn't create logs [15:54:28 CEST] <RoundHash> What does -qp do, I can't see it in the man page or on the ffmpeg x264 page, is it documented anywhere? Something to do with quality? I just set it to 0 and all my nasty artifacts have gone, but the file size is quite a bit larger [15:54:57 CEST] <pagios> Hello, does anyone know of any cloud providers other than AWS that provides instant docker images provisioning? Like i can spawn an instance in a matter of seconds , run it for 2 or 3h and then close it, i can spawn 100 isntance docker and close after few hours and get charged accordingly. Can anyone point me to such providers? [15:55:23 CEST] <Mavrik> RoundHash: QP is a landmine you should never use :) [15:56:06 CEST] <Mavrik> It tweaks internal quantization parameters but it also prevents them from being adjusted to match frame complexity. [15:56:20 CEST] <Mavrik> Essentially making sure you have some frames that will look like arse and some that will waste way too much bytes to be stored. [15:56:23 CEST] <Mavrik> Use CRF instead. [16:00:52 CEST] <RoundHash> Mavrik: I had tried that, but I was getting grainy video out, even with it set to 0. Just tried again though, with a different input format of the same video and it's looking better. Fingers crossed I have the right combination of options now [16:01:18 CEST] <Mavrik> You should probably never set it to 0 either. [16:01:23 CEST] <Mavrik> Can you tell me what are you trying to achieve? [16:01:38 CEST] <RoundHash> Yeah, I was just going for the extreem to see if it worked. [16:01:59 CEST] <Mavrik> 24 is the default I think [16:02:04 CEST] <Mavrik> With ~18 being overkill for most [16:02:05 CEST] <Mavrik> :) [16:02:13 CEST] <furq> 23, but yeah [16:02:14 CEST] <Mavrik> (lower = better quality at larger filesize) [16:02:16 CEST] <RoundHash> Yeah, I had read that somewhere. I'm just trying to convert an image sequence (previously JPEG, now PNG) to a H.264 video. [16:02:20 CEST] <furq> 18-20 are "normal" values [16:02:39 CEST] <RoundHash> I was talking to furq earlier about it [16:02:45 CEST] <furq> it probably looks better at qp/crf 0 because lossless is always 4:4:4 [16:03:10 CEST] <RoundHash> I switched out my input images from jpeg to png, which has helped with the colour issues too, so that's something [16:03:27 CEST] <Mavrik> Screencaps? [16:03:40 CEST] <RoundHash> Sure, one sec. [16:03:56 CEST] <Mavrik> As in, you're trying to encode screen captures? :) [16:04:59 CEST] <RoundHash> Oh, sorry. [16:05:12 CEST] <RoundHash> No, it's a video sequence rendered from Blender [16:05:31 CEST] <furq> it wouldn't surprise me if it was just jpeg compression artifacts that were just more obvious in the video [16:05:58 CEST] <RoundHash> I'm using PNG now, so shouldn't be that (you'd hope :p) [16:06:24 CEST] <RoundHash> I was half way to creating a screenshot anywa, so I continued with the before and after lol: https://ibb.co/jcajie [16:06:42 CEST] <RoundHash> raw PNG on the left, video on the right [16:07:30 CEST] <RoundHash> This is the command: ffmpeg -r 60 -i %05d.png -c:v libx264 -crf 15 -preset veryslow video.mp4 [16:08:05 CEST] <Mavrik> That looks as fine as it can :) [16:08:26 CEST] <Mavrik> What's the output you get from ffmpeg when you run that? [16:08:42 CEST] <RoundHash> Maybe I'm being too picky now lol, but if I get Blender to output "ffmpeg video", I get a much crisper output. Still uses H.264 and MP4 [16:09:01 CEST] <RoundHash> You mean text or video output? [16:09:06 CEST] <Mavrik> text :) [16:09:24 CEST] <RoundHash> One sec. [16:11:09 CEST] <RoundHash> https://pastebin.com/jaVs6R8X [16:11:19 CEST] <RoundHash> Had to re-run it, lost it in my scrollback [16:11:25 CEST] <ilushka4> I have no idea why my rtsp stream won't work. Here is the log: https://paste.ee/p/PilXq [16:11:31 CEST] <ilushka4> I think maybe it's something with codecs? [16:11:59 CEST] <Mavrik> RoundHash: hmm, ... rc=crf mbtree=1 crf=23.0 ... [16:12:31 CEST] <Mavrik> your ffmpeg seems to pass 23 as crf to x264? :) [16:13:23 CEST] <RoundHash> Ah, damn it, I re-ran the wrong command... or pasted the wrong output... :/ *ahem* I'll check [16:15:55 CEST] <RoundHash> Ok, pasted the wrong output. Take 2: https://pastebin.com/kC3BrNxv [16:24:58 CEST] <RoundHash> Mavrik: Any thoughts on things I can try to get it looking cleaner? [16:26:48 CEST] <Mavrik> Nothing looks different from my side, so no idea what would cleaner mean. [16:26:56 CEST] <Mavrik> Did you check if your PNG source is fine? [16:27:22 CEST] <RoundHash> Yeah, that was the image on the left of the screenshot I posted earlier, it's as clean as a whistle [16:28:02 CEST] <RoundHash> I'm currently resorting to trawling through the blender source code to see if I can find how they're running ffmpeg. I'd really rather not though lol [16:40:35 CEST] <Foaly> RoundHash i think you are looking for this: https://github.com/dfelinto/blender/blob/master/source/blender/makesdna/DNA… [16:42:13 CEST] <RoundHash> Nice find, thanks. I've also just found a flag --debug-ffmpeg that you can run blender with to make it dump all the usual ffmpeg stuff to the terminal. Just starting to look through it now! [16:44:47 CEST] <RoundHash> If anyone is interested, this is the output from Blender: https://pastebin.com/bbHd1khy [16:45:17 CEST] <RoundHash> with the --debug-ffmpeg flag [16:51:21 CEST] <RoundHash> If anyone knows what the relevant settings are in that list I'd be happy to listen ha. Currently trying to find the flags to set those options... [16:53:39 CEST] <Foaly> ? [16:55:18 CEST] <RoundHash> Sorry, which bit didn't make sense? [16:58:42 CEST] <Foaly> what options do you want to set? [17:00:45 CEST] <RoundHash> Whichever ones will stop my video looking grainy. Blender outputs the video fine (log: https://pastebin.com/bbHd1khy) so I was going to just copy the options that it set, but there are loads and they don't directly map to command line args, so I was hoping that if someone knew which ones were relevant, then they could let me know so I woulnd't have to go through the pain of finding out [17:08:59 CEST] <RoundHash> Narrowed it down to these options at least: https://pastebin.com/Gq20ZRYL [17:24:50 CEST] <Mavrik> none of this should make video look grainy :/ [17:27:35 CEST] <RoundHash> Maybe something on the input side that's transforming the PNG? [17:32:41 CEST] <RoundHash> I just tried creating a preset with as many of the options Blender spat out in as I could (more than half weren't valid apparently) and not much changed sadly :( [17:38:36 CEST] <RoundHash> Ok, so not a great idea to try, but I just ran ffmpeg with -c:v copy (no no H.264) (PNG image sequence in) and it spat out a 1GB file for about 1000 frames and it was still grainy [17:39:18 CEST] <RoundHash> So, something to do with the mp4 container? or the way the PNGs are being handled? [17:39:34 CEST] <RoundHash> At least I know it's not the H.264 settings now [17:40:34 CEST] <Foaly> are the still frames in your video grainy? [17:40:40 CEST] <RoundHash> Yeah [17:41:25 CEST] <Foaly> idk, does ffmpeg put them losslessly in an mp4 if you feed it pngs? [17:41:40 CEST] <Foaly> also, you could try to convert the video back to pngs, and see if they look fine [17:41:57 CEST] <Foaly> might be something wrong with whatever you use to display the video [17:42:11 CEST] <RoundHash> Yeah, could give that a go. I'm just using VLC [17:43:37 CEST] <RoundHash> Just tried using avi as the container and it comes out grainy, so I guess that means it's not the codec or the container that's messing with me, must be something on the input side [17:44:32 CEST] <Foaly> are the pngs fine? [17:44:56 CEST] <Foaly> and are you sure it compresses lossless? [17:46:45 CEST] <RoundHash> I'm pretty sure, yeah. Blender says "Compression: 15%", but it says lossless when you hover over, so I assume it's doing what it says it is... [17:49:29 CEST] <Foaly> nah, i mean when you compress with ffmpeg [17:49:36 CEST] <Foaly> pngs are always lossless [17:50:50 CEST] <RoundHash> Oh, I'm not sure then, the command I'm using is: ffmpeg -r 60 -i %05d.png -c:v libx264 -crf 15 video.avi [17:52:14 CEST] <Foaly> i guess that should be fine [17:52:46 CEST] <RoundHash> This is my most recent output. Input PNG on the left, output H.264 (crf = 15) AVI on the right: https://ibb.co/gAFy9K [17:54:31 CEST] <Foaly> probably container does not make a difference, but have you tried mkv instead? [17:55:07 CEST] <Foaly> also, if you convert back to png with ffmpeg, does that look the same? [17:55:33 CEST] <RoundHash> I've tried mp4 and avi, but I'll give mkv a try. I'm good to just change the file extension to change the container, though, right? [17:55:47 CEST] <RoundHash> Haven't tried converting to and from yet, will give it a go in a sec [17:55:51 CEST] <Foaly> i guess [17:56:40 CEST] <RoundHash> Yeah, same grainy with the MKV too [17:56:59 CEST] <Foaly> but i'd say that grain would qualify as dithering [17:57:22 CEST] <Foaly> maybe that's just because of the transformation from/to RGB [18:00:15 CEST] <RoundHash> What does that though, if it's not the codec or the container? I'll try that conversion to and from now. [18:00:55 CEST] <kepstin> you could consider using 10bit h264, or tweaking the aq-mode setting to the mode that biases for higher quality in dark scenes [18:01:09 CEST] <kepstin> (by default x264 lowers quality in dark stuff since it's less visible) [18:02:11 CEST] <RoundHash> I think we've ruled out an H.264 problem, as I've tried with with "copy" and still get the same results, so thinking that it's somewhere else in the pipeline. Thanks for the suggestion though [18:03:02 CEST] <kepstin> if you see the same thing with copy mode with the png images (and copy mode actually worked), then the original png images were the issue [18:03:59 CEST] <kepstin> or the player, I suppose :/ [18:05:34 CEST] <kepstin> could be that it's losing gamma information, too, maybe it's reading the pngs as srgb but blender's outputting them with different gamma? [18:05:55 CEST] <RoundHash> I have the original PNG images and they look pretty crisp (left in the screenshot I posted https://ibb.co/gAFy9K) so I don't think it's that. I'm using VLC on Linux, might be that, but I feel like is something else. [18:05:57 CEST] <kepstin> note that blender's renderer is really tweakable, and if run with settings that don't do enough samples it tends to produce grainy results, which could be made more visible if gamma is incorrect [18:08:04 CEST] <kepstin> your screen shot there just shows a flat black area and another flat black area for me, I can't really tell any difference unless I zoom in. The true bar in the middle make it hard to check if the levels are the same (different levels could indicate a gamma problem) [18:08:41 CEST] <RoundHash> I'm just using the video sequence editor, not cycles, so sampling isn't it. It was screen captured footage, imported into blender, messed about with and then rendered as a PNG sequence. It could definitely be enhancing artifacts from the previous encoding though if it is loosing gamma info [18:09:59 CEST] <RoundHash> Any idea how to go about debugging that though? [18:10:54 CEST] <kepstin> try using ffmpeg to convert one png frame to a bmp or something and see if they look the same when opened in a color-profile-aware image editor [18:14:07 CEST] <RoundHash> Foaly: Just tried converting to H.264 (crf 15) MP4 back to PNG and the grain is kept in the output sequence too :/ [18:14:22 CEST] <RoundHash> kepstin: Right, will give that a shot, thanks :) [18:15:37 CEST] <kepstin> the artifacts I see in your screenshot appear to have levels of only ±1 in the luma, and looks like typical mpeg quantization noise. I wouldn't expect them to be visible unless you're on a poorly calibrated monitor :/ [18:16:19 CEST] <kepstin> note that the left side of your screenshot isn't perfectly flat, but has some scattered darker pixels throughout. [18:16:50 CEST] <kepstin> I couldn't see them on either side until I adjusted the levels in the image to enhance the contrast. [18:17:44 CEST] <kepstin> using -aq-mode 3 might improve it slightly when doing lossy h264 encoding. [18:18:13 CEST] <kepstin> on an lcd screen, variance in backlight or pixel quality is likely to be more visible than these artifacts. [18:19:01 CEST] <RoundHash> I haven't ever calibrated my monitors, so I guess that's similar to being poorly calibrated lol. Yeah, I did spot the darker pixels too. The right side is much more visible on my monitors. [18:19:40 CEST] <RoundHash> I'm not sure how it can be a problem with H.264 if even when I'm not using it, I get the same issue [18:20:12 CEST] <RoundHash> I did just try to do a straight PNG -> PNG conversion with ffmpeg and there was no noise there, I'll try to BMP [18:20:48 CEST] <kepstin> alright, so it's probably being introduced by the rgb yuv conversion combined with the full range to limited range conversion [18:21:03 CEST] <kepstin> maybe some dithering is added in there [18:21:39 CEST] <RoundHash> PNG -> BMP is fine too [18:21:57 CEST] <kepstin> you should avoid converting between rgb and yuv wherever possible, since that is a lossy conversion. (assuming both are 8bit) [18:22:26 CEST] <RoundHash> Alright, makes sense, so can I just preserve my RGB colour space in the video then? [18:22:27 CEST] <kepstin> my guess is that when exporting directly from blender, it might send yuv straight to the encoder, rather than doing yuv -> rgb (png) -> yuv (in ffmpeg) [18:22:43 CEST] <kepstin> x264 can encode rgb, but very few players can decode it. [18:23:43 CEST] <RoundHash> Right, ok, so this sounds pretty unavoidable then if I'm going to have an RGB step in there, I need to see if I can output in YUV somehow and maybe that'll help [18:25:12 CEST] <RoundHash> Thanks for your help with this, kepstin, really appreciate it [18:25:28 CEST] <RoundHash> and everyone else for that matter [18:26:32 CEST] <kepstin> RoundHash: if you can't use blender to encode directly, the second best option is probably to have blender output to a high quality or lossless yuv video format, and then you'd do your final encode based on that. [18:28:54 CEST] <RoundHash> I would use blender to encode directly, it just has a habbit of crashing on me during the process, which is quite frustrating! Yeah, I think some formats can be appended to if it does crash half way through, so that might be an option [18:33:20 CEST] <kepstin> yeah, mp4 is bad for that. mkv is usually readable after a crash during encoding. [18:35:08 CEST] <RoundHash> I'll definitely give it a try. I have to go now though, but thanks for all the help again! [18:54:01 CEST] <keglevich> ffmpeg -re -i 1.mp4 -g 50 -c:v libx264 -preset veryfast -x264opts nal-hrd=cbr -b:v 2200k -minrate 2200k -maxrate 2200k -bufsize 260k -muxrate 2600k -pcr_period 30 -c:a mp2 -ac 2 -b:a 192k -ar 48000 -f mpegts "udp://239.1.1.1:10000?pkt_size=1316" [18:54:51 CEST] <keglevich> running the command above gives somehow CBR UDP multicast stream, but it's not perfect (lots of bursts, spikes, etc.), nothing similar to those generated by hardware encoders...is there anything I can do to improve it? [19:40:01 CEST] <Essadon> How do I combine a slideshow of GIF images with timestamps and the sound of a mp4 file? [19:44:54 CEST] <vlt> Essadon: For the second part of your question you could just add the mp4 file to your list of inputs: `ffmpeg -i ... -i the.mp4` and then use -map. [19:45:56 CEST] <Essadon> I have one mp4 file [19:45:59 CEST] <Essadon> Not several [21:20:27 CEST] <azaki> anyone know is there's a feature freeze approaching soon? it seems releases trend around april and october, so i imagine that ffmpeg 4.1 should be on the way soon? [21:21:38 CEST] <Woodpecker> I have a question. I am downloading some music to serve as background music in an audiobook. I need the song volume to be consistent throughout, thus flattening the peaks and valleys. What do I call this process? Its not normalization, is it? [21:23:03 CEST] <durandal_1707> background music should not be distraction [21:23:18 CEST] <Woodpecker> yep. [21:24:11 CEST] <durandal_1707> then just mix it with fixed low volume [21:35:24 CEST] <BtbN> azaki, ffmpeg doesn't do feature freezes. [21:35:42 CEST] <BtbN> A release is just cut when it's roughly time and no big issues are outstanding. [21:39:38 CEST] <kepstin> Woodpecker: that you're talking about is normally called dynamic range compression. There's a few different ways to do it. You might consider using ffmpeg's "loudnorm" filter, which can adjust an audio track to stay within set loudness limits. [21:41:04 CEST] <Woodpecker> kepstin: thank you so much. That sounds perfect [21:44:04 CEST] <kepstin> Woodpecker: or depending on the audio in question, something simpler with faster attack like the compand filter might work for you. [22:02:31 CEST] <ChocolateArmpits> Can itsoffset and loudnorm filter introduce gradual audio delay? [22:03:07 CEST] <durandal_1707> should not [22:03:37 CEST] <ChocolateArmpits> I'm feeling this may be a very obscure bug [22:04:00 CEST] <durandal_1707> how to reproduce? [22:04:33 CEST] <ChocolateArmpits> well currently I have two inputs, video is from an ip cam, audio is from a directshow device [22:04:54 CEST] <ChocolateArmpits> I haven't toyed with conventional files for this [22:05:48 CEST] <ChocolateArmpits> if I add loudnorm to the audio filter chain before aresample=44100:async=1 for the audio input that uses itsoffset, the audio gets gradually delayed [22:06:02 CEST] <ChocolateArmpits> if however I specify loudnorm after aresample, then it seems to work fine [22:06:55 CEST] <durandal_1707> probably because audio pts are not continuous [22:07:43 CEST] <ChocolateArmpits> Additionally I specify -use_wallclock_as_timestamps for the both the audio and video inputs, so they stay synchronized [22:17:49 CEST] <kepstin> yeah, use_wallclock_as_timestamps will introduce discontinuities into the audio timestamps [22:18:05 CEST] <kepstin> which aresample can fix [22:18:27 CEST] <ChocolateArmpits> kepstin, hmm I assume wallclock uses system timer? [22:18:55 CEST] <kepstin> yeah, which might run at a different rate from the timer of the adc used to record the audio originally [22:19:18 CEST] <kepstin> so the timestamps on the audio packets won't exactly match the sample rate that the audio is labelled with [22:19:51 CEST] <kepstin> The aresample filter will automatically stretch/squeeze the audio to match the timestamps [22:20:36 CEST] <ChocolateArmpits> interesting [22:20:39 CEST] <GuiToris> hello, relaxed, ChocolateArmpits it's just a little feedback, I reencoded the original videos with level 4.1 and now it works on our TV [22:20:47 CEST] <kepstin> (or at least it can, if you set the async= option on it) [22:20:50 CEST] <ChocolateArmpits> GuiToris, nice [22:21:28 CEST] <ChocolateArmpits> kepstin, yeah I'm using it [22:22:04 CEST] <GuiToris> one of you said I'll get smaller filesize if I reduce noise. I know it's a subjective question, but is there any better denoiser than hqdn3d? [22:22:25 CEST] <GuiToris> I found tons of denoisers [22:22:45 CEST] <ChocolateArmpits> GuiToris, there are better ones, surely, but not a lot will work realtime or faster [22:23:00 CEST] <kepstin> GuiToris: bm3d is a new denoise filter since the last time i looked at the filter list, it might be interesting to test. [22:23:15 CEST] <GuiToris> I'll take a look [22:23:45 CEST] <kepstin> (i'd expect it to be fairly slow, it appears to do motion compensated temporal denoising) [22:24:00 CEST] <GuiToris> I went through all the denoisers that I found in the list and they were quite similar but hqdn3d [22:24:04 CEST] <GuiToris> -I used defaults- [22:24:51 CEST] <GuiToris> speed is not a problem, I don't have to sit here while it encodes [22:25:34 CEST] <kepstin> tweaking the settings on a denoiser that works well is probably where you'd want to look next, if you've tried a bunch of different denoisers already [22:25:52 CEST] <ChocolateArmpits> kepstin, is it related to this? https://github.com/HomeOfVapourSynthEvolution/VapourSynth-BM3D [22:26:07 CEST] <ChocolateArmpits> I've used this vapoursynth filter, good results but slow as balls [22:26:55 CEST] <kepstin> i'd expect it to probably be a port of that filter, yeah. [22:27:24 CEST] <GuiToris> do I need to create a video just to compare different denoisers? You said it may have some motion tracking things, I guess it won't work if I only make PNG files [22:27:52 CEST] <ChocolateArmpits> GuiToris, input shouldn't matter at all [22:28:04 CEST] <ChocolateArmpits> of course in every comparison the source should be exactly the same [22:28:15 CEST] <GuiToris> I meant ffmpeg -i input -vf bm3d -frames 1 output.png [22:28:53 CEST] <GuiToris> I find it much easier to compare images than videos [22:29:22 CEST] <ChocolateArmpits> GuiToris, if we believe the filter is a port of a vapoursynth filter, then bm3d is a spatial filter only [22:29:40 CEST] <ChocolateArmpits> so single frame comparisons shouldn't be error prone [22:30:07 CEST] <ChocolateArmpits> V-BM3d that's only available through vapoursynth however does both that and temporal as well [22:30:48 CEST] <kepstin> GuiToris: for any temporal ("3d") denoising filter, you'd want to give it multiple frames [22:31:41 CEST] <kepstin> it looks like the ffmpeg bm3d filter has the functionality of the V-BM3d vapoursynth filter, from looking at the options. not entirely clear tho. [22:32:28 CEST] <GuiToris> so does this make more sense : ffmpeg -i input -t 3 -vf bm3d -crf 0 temp.mp4 ; ffmpeg -ss 2 -i temp.mp4 -frames 1 image.png? [22:33:01 CEST] <kepstin> i could be wrong tho, hmm. [22:35:01 CEST] <GuiToris> No such filter: 'bm3d' [22:35:29 CEST] <kepstin> ah, i probably am wrong. I guess it is the spatial-only bm3d stuff, it doesn't have the extra options that v-bm3d adds [22:35:34 CEST] <ChocolateArmpits> GuiToris, guess it's a recent filter, what's your version? [22:35:36 CEST] <kepstin> I bet it's only in git master. [22:35:56 CEST] <GuiToris> ffmpeg 1:4.0.2-2 [22:36:58 CEST] <GuiToris> when I went through the list I came across this error message a few times, there might be several new filters then [22:37:56 CEST] <GuiToris> if it's not bm3d then, do you agree that hqdn3d is a good denoiser? [22:42:49 CEST] <durandal_1707> hqdn3d is old crap [22:43:05 CEST] <durandal_1707> nlmeans and/or bm3d [22:44:09 CEST] <GuiToris> I don't have bm3d yet, I'll check nlmeans [22:44:24 CEST] <durandal_1707> do not use defaults for bm3d for best results, read carefully documentation [22:44:39 CEST] <durandal_1707> also bm3d is currently spatial only, same as nlmeans [22:44:56 CEST] <durandal_1707> temporal version use much more memory [22:45:39 CEST] <ChocolateArmpits> kepstin, back to that audio delay thing, would it be fair to assume that whatever ADC is there, generates more samples per time frame than needed? [22:45:39 CEST] <GuiToris> I have nlmeans, well it's definitely not a fast filter [22:46:01 CEST] <GuiToris> thank you for your suggestion durandal_1707 [22:46:54 CEST] <kepstin> ChocolateArmpits: any time you have to deal with different clocks, one will always run faster or slower than the other one (giving the result in this case of too many or not enough samples per frame) [22:48:20 CEST] <ChocolateArmpits> ok thanks, this clears it up, I guess I have to be more aware of hardware behind the scenes [22:48:23 CEST] <durandal_1707> GuiToris: check also atadenoise, it is fast and simple, only temporal denoiser [22:48:48 CEST] <GuiToris> thanks durandal_1707 :) [22:50:30 CEST] <kepstin> ChocolateArmpits: this is why many video players run their video frame timing off the audio clock - they send samples to the sound card, then update the video frame after the appropriate amount of audio has been played. [22:51:30 CEST] <kepstin> (although good players like mpv have a bunch of different timing modes, especially to handle stuff like playing judder-free video on e.g. a 24000/1001hz display output) [22:54:29 CEST] <GuiToris> out of curiosity, do you have bm3d filter? [22:55:45 CEST] <durandal_1707> GuiToris: me? yes, i ported filter to lavfi [22:55:59 CEST] <kepstin> I haven't rebuilt my git ffmpeg since it was added, so I don't hev it yet :) [22:57:17 CEST] <GuiToris> I see, I should work on it [22:57:37 CEST] <kepstin> hmm. on a side note, I was thinking of adding an option to the fps filter that would make it repeat the last input frame indefinitely, does anyone else think that would be useful? [22:58:10 CEST] <kepstin> it's a small enough code change I guess i should just post it for review :) [00:00:00 CEST] --- Sat Oct 6 2018

1 0

ffmpeg-devel.log.20181004
by burek 05 Oct '18

05 Oct '18

[01:18:02 CEST] <cone-031> ffmpeg 03James Almer 07master:af2acbd23f85: avcodec/av1_metadata: add an option to insert and remove Temporal Delimiter OBUs [01:49:31 CEST] <cone-031> ffmpeg 03James Almer 07master:ebc3d04b8df4: avcodec: add an AV1 parser [03:42:50 CEST] <kierank> https://github.com/FFmpeg/FFmpeg [03:42:53 CEST] <kierank> dates are screwed up, weird [04:16:11 CEST] <BradleyS> kierank: i believe you may be referring to the authored dates, which may be different than committed dates [04:17:03 CEST] <BradleyS> so if you author a commit and then amend it or rebase, the committed date will be different while the authored date stays the same [04:17:16 CEST] <kierank> github seems to be mixing the dates then [04:17:25 CEST] <kierank> "jamrial committed on 14 Jul" [04:17:58 CEST] <BradleyS> i agree it's pretty silly, they should s/committed/authored/ [04:18:40 CEST] <jamrial> yeah, authored date is 14 july because i've been rebasing and changing the commit locally since then [04:18:49 CEST] <jamrial> no idea why github shows it as commit date [04:20:49 CEST] <BradleyS> git log --pretty=fuller [04:21:12 CEST] <BradleyS> i'm pretty sure i reported this to github awhile back but *shrug* [08:27:01 CEST] <sharax> hello [08:27:13 CEST] <sharax> i want to install ffmpeg on centos 7 for php7 [08:27:15 CEST] <sharax> can help me? [12:07:32 CEST] <J_Darnley> Sure: ./configure && make [12:07:56 CEST] <J_Darnley> Oh that was three and half hours ago [12:17:22 CEST] <JEEB> I already told him to stop spamming on #ffmpeg and that php-ffmpeg has nothing to do with FFmpeg [12:18:39 CEST] <durandal_1707> it is so quiet [12:18:52 CEST] <JEEB> enjoy the calm before the storm? [12:28:35 CEST] <cone-025> ffmpeg 03Paul B Mahol 07master:7d65fe87e9d3: avfilter: add ff_inlink_queued_samples() [12:28:35 CEST] <cone-025> ffmpeg 03Paul B Mahol 07master:ef3babb2c70f: avfilter/af_asetnsamples: use lavfi internal queue [12:28:36 CEST] <cone-025> ffmpeg 03Paul B Mahol 07master:6725fd8b0fb7: avfilter/af_headphone: use lavfi internal queue instead [12:28:37 CEST] <cone-025> ffmpeg 03Paul B Mahol 07master:4901fa1fb8de: avfilter/af_afir: use internal lavfi queue [12:35:16 CEST] <JEEB> fun sample [12:36:32 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=fftools/ffmpeg.c;h=934dc71a7… [12:36:59 CEST] <JEEB> ffmpeg.c hits this, then adjusts and then the logic starts adjusting timestamps on both video and audio at each read [12:37:14 CEST] <JEEB> because first you get a funky amount of audio packets which crawl up [12:37:23 CEST] <January> How can I make gmail manageable with the mailing list? In other email services I can setup ffmpeg emails to go to a folder, Ive done this on gmail but they still go to inbox as they use tags [12:37:24 CEST] <JEEB> and don't cause a discontinuities [12:37:43 CEST] <JEEB> January: I've been able to make a directory just fine? [12:37:47 CEST] <JEEB> or whatever it's called [12:37:51 CEST] <JEEB> in IMAP it ended up as a directory [12:38:22 CEST] <January> Mmh. Mine ended up as a directory in their web client but nothing to reflect that in IMAP [12:39:21 CEST] <JEEB> I did the setup 100% in the webui [12:39:36 CEST] <JEEB> basically I added a rule for the mailing list [12:39:52 CEST] <JEEB> "move to directory and 'archive (move from inbox)'" [12:39:55 CEST] <JEEB> if I recall correctly [12:40:11 CEST] <JEEB> latter makes sure it doesn't "stick" in your inbox IIRC [12:40:49 CEST] <JEEB> they redid the gmail webui lately so I can't say exactly how I did it, but you should have an alternative to "filter messages from this list" if you open a ffmpeg-devel e-mail [12:42:38 CEST] <JEEB> anyways, I wonder if it makes sense to check if we've already taken in a packet with a similar timestamp that doesn't go over our dts_delta_threshold [12:42:45 CEST] <JEEB> for example if we have a video track, check the audio track [12:42:50 CEST] <JEEB> *check all audio tracks [12:42:53 CEST] <JEEB> or vice versa [12:43:40 CEST] <JEEB> because if we've already taken in a packet with similar timestamp then adjusting the timestamp doesn't really make sense as it most likely will cause A/V desync in case the timestamps are correct and there just was a discontinuity [12:44:11 CEST] <JEEB> I have a 60s sample if anyone wants to see ffmpeg.c freaking out [12:44:29 CEST] <JEEB> but yea, I did add a check like that and it effectively stops the snowfall [12:44:53 CEST] <JEEB> (vanilla keeps on adjusting timestamps for both audio and video, and the result is 100% out of sync for the amount of discontinuity) [12:45:40 CEST] Action: JEEB is just wondering if as an idea that makes sense [13:44:26 CEST] <JEEB> http://up-cat.net/p/dc4a0d2d [13:45:16 CEST] <JEEB> so then with each read that discontinuity check gets hit and the timings are all over the place [13:45:55 CEST] <JEEB> while if you just make it compare the received timestamp against the audio's next_dts then you figure out that you're close enough, and you block the "fixing" [13:46:02 CEST] <JEEB> but I have no idea if that makes sense as a check :P [13:47:01 CEST] <JEEB> basically as a "you've already let the other stream go far enough that they seem to be in synch, maybe let's not touch the timestamps any more?" [13:49:39 CEST] <JEEB> with my PoC it just does http://up-cat.net/p/805aa51b [13:49:48 CEST] <JEEB> and keeps on churning OK with no visible breakage in A/V synvh [13:49:50 CEST] <JEEB> *synch [14:40:41 CEST] <January> JEEB: ah. Needed the 'archive' flag, works now thanks [14:52:35 CEST] <JEEB> cheers [18:24:16 CEST] <lemourin> Hi, if I made MediaFoundation wrapper for FFmpeg, would you merge it? I saw this https://ffmpeg.org/pipermail/ffmpeg-devel/2017-April/209720.html and I would like to make it work with current master. [18:24:56 CEST] <nevcairiel> thats questionable [18:25:18 CEST] <nevcairiel> what exactly would it allow you to d o that we cant do already? And why wouldnt one work to allow whatever thing without some huge other framework involved? [18:25:50 CEST] <lemourin> The idea is that if you use MediaFoundation you don't have to pay MPEG LA royalties. [18:26:37 CEST] <lemourin> Because Microsoft paid it already when it selled you Windows [18:27:00 CEST] <lemourin> I have that confirmed with a lawyer. [18:29:30 CEST] <nevcairiel> yeah thats not a reason thats going to convince anyone to add a huge chunk of code thats going to be hard to maintain [18:29:44 CEST] <nevcairiel> instead of using avcodec you could just use MF directly in your code [18:29:54 CEST] <nevcairiel> its probably even easier then making a patch [18:35:59 CEST] <lemourin> Yeah it would probably work. And it would be easier. I just thought that I could implement something which could be useful for someone in the future (besides me). [18:39:00 CEST] <lemourin> Ah, and it gives you a non GPL h264/hevc encoder. [18:39:16 CEST] <lemourin> Software encoder. [18:39:46 CEST] <JEEB> openh264 exists for that [18:39:51 CEST] <lemourin> openh264 is crap [18:39:54 CEST] <JEEB> sure [18:40:10 CEST] <lemourin> and has very weird license [18:40:12 CEST] <JEEB> then you have that new project for HEVC from intel which I haven't been able to benchmark yet [18:40:38 CEST] <JEEB> I thought the license was relatively standard? the only extra bit is that if you take the binaries from cisco you don't need to care about MPEG-LA [18:40:45 CEST] <JEEB> since end user distro is being done by cisco [18:41:06 CEST] <JEEB> (which is why mozilla downloads cisco binaries of openh264) [18:41:15 CEST] <lemourin> yes, but you have to offer builds with and without this encoder and user has to be able to choose [18:42:20 CEST] <lemourin> @JEEB do you mean this: https://github.com/ultravideo/kvazaar ? [18:42:53 CEST] <JEEB> lemourin: no, although that's an older Tampere uni project [18:42:59 CEST] <JEEB> https://github.com/intel/SVT-HEVC [18:43:03 CEST] <JEEB> this is the recent intel thing [18:44:58 CEST] <durandal_1707> hevc is out, AV1 is IN [18:46:34 CEST] <JEEB> they said they'll be publishing an optimized AV1 encoder as well, but so far that mailing list only has a single test e-mail [18:46:47 CEST] <lemourin> AV1 plz; it took me a week to encode 3 minutes 60fps fullhd video [18:46:50 CEST] <lemourin> 12k frames [18:46:51 CEST] <JEEB> https://lists.01.org/pipermail/svt-av1/2018-September/thread.html [18:47:14 CEST] <lemourin> and it looks shit :( [18:47:29 CEST] <durandal_1707> what? [18:47:30 CEST] <JEEB> yea, not much psyopts [18:49:15 CEST] <lemourin> so still no h264 non gpl software encoder [18:49:30 CEST] <lemourin> so this would be a reason for MF wrapper [18:49:56 CEST] <durandal_1707> write it for gstreamer [18:51:10 CEST] <lemourin> why don't you want it in ffmpeg? [18:52:09 CEST] <atomnuker> lemourin: hey, x264 can be lgpl if you paid money to license it [18:52:40 CEST] <lemourin> @atomnuker: and royalties as well.. [18:52:57 CEST] <lemourin> so like 15mln usd / year [18:53:29 CEST] <JEEB> we have encoders for mac frameworks and such :P [18:53:36 CEST] <bencoh> JEEB: how does it compare to x265 (SVT-HEVC)? [18:53:38 CEST] <JEEB> so for encoders MF /might/ be useful [18:53:48 CEST] <JEEB> bencoh: as I said I have not had *any* time to check it out [18:53:58 CEST] <bencoh> ah, mybad [18:54:08 CEST] <JEEB> its primary thing seems to be being able to share some stuff between profiles [18:54:11 CEST] <JEEB> in a multi-profile encode [18:54:15 CEST] <lemourin> exactly, thats just weird that i do have encoders for mac and linux but not for windows [18:54:41 CEST] <JEEB> lemourin: with MF by default people think of decoding :P [18:54:48 CEST] <JEEB> which is available through dxva2 and d3d11va [18:54:54 CEST] <lemourin> yea i know [18:55:30 CEST] <lemourin> i wanted to start implementing it but i don't want to do it if there is no chance to merge it [18:55:58 CEST] <bencoh> JEEB: that could be done with no specific encoder support for quite a lot of things, but, meh, why not :) [18:56:10 CEST] <bencoh> (it does save computing time though) [18:56:40 CEST] <bencoh> (I'd still rather see a good h265 encoder than a medium-grade multi-profile one) [18:57:15 CEST] <durandal_1707> I do not like windows in general, and ms in particular, otherwise why not write other wrappers like dshow and vfw? [18:57:16 CEST] <atomnuker> x265 is decent [18:57:53 CEST] <lemourin> durandal_1707: do those have encoders? [18:58:21 CEST] <bencoh> atomnuker: I haven't had a look at time for quite a while, to be honest [18:58:24 CEST] <JEEB> bencoh: sure, for VOD I totally agree [18:58:40 CEST] <JEEB> for live streams I feel like we could get quite a bit from both x264 or x265 if we'd share some metrics [18:58:45 CEST] <JEEB> and/or decisions [18:58:58 CEST] <JEEB> x265 already has an API for that but I'm not sure if it would fit into lavc at all :P [19:00:22 CEST] <bencoh> an API for? uploading metrics? [19:00:30 CEST] <JEEB> sharing state [19:00:33 CEST] <bencoh> or live-sharing between encoders? [19:08:23 CEST] <lemourin> So what's the conclusion; a definite no for MF encoders in FFmpeg? [19:09:01 CEST] <January> lemourin: I wouldnt go to the effort to implement it in FFmpeg if I were you [19:09:50 CEST] <JEEB> we have AMF and QSV and nvenc for windows I think, and the primary reason we have the QT API encoders on macOS is because that's the only API? but as such MF and QT would be similar for encoding [19:09:54 CEST] <JEEB> so I dunno [19:10:32 CEST] <lemourin> you have videotoolbox on mac [19:10:43 CEST] <JEEB> that's what I more or less meant I guess :s [19:10:48 CEST] <JEEB> I didn't remember the API name [19:11:06 CEST] <lemourin> @January: don't worry about my effort; I dont do it for free luckily [19:15:36 CEST] <January> lemourin: I mean, if you did it in a similar fashion to macOS then I dont see why it wouldnt be accepted provided there werent any really big issues, I guess [19:15:59 CEST] <January> Maybe implement a minimum patch and send to ML [19:16:51 CEST] <JEEB> also one thing that should be kept in mind [19:17:01 CEST] <JEEB> does lavc's abstractions and usage match with the MF model [19:17:44 CEST] <lemourin> i wouldn't even start this discussion if i didn't see a patch that did the MF wrapper [19:17:51 CEST] <lemourin> but was abandoned [19:18:02 CEST] <lemourin> anyway thanks, now i have some incentive to do it [19:19:17 CEST] <lemourin> @JEEB: "we have AMF and QSV and nvenc" those are all hardware encoders; what if someone has amd processor with no gpu :P [19:19:31 CEST] <JEEB> yes, very true [20:01:10 CEST] <durandal_1707> j-b: do you have any ETA? [20:19:35 CEST] <gnafu> Has there been any more movement on implementing tiles support for libaom-av1? I particularly liked the idea of having a '-tiles [20:19:52 CEST] <gnafu> ' option instead of having to specify columns and rows, even though it breaks from libvpx-vp9 tradition. [20:20:42 CEST] <gnafu> Just curious if that's being actively figured out, or if what's on the ML is the latest news. [20:21:58 CEST] <gnafu> Oh, and I see I missed a newer mention on the ML, and it looks like the patest patch implements both. Nice! [20:22:08 CEST] <gnafu> s/patest/latest/ [20:45:02 CEST] <cone-371> ffmpeg 03James Almer 07master:e08a876e67a7: avcodec/libaomdec: remove bogus comment [20:57:13 CEST] <gnafu> Is '-b:v 0' still required with libaom-av1 to do constant quality, or is it enough to specify -crf and no bitrate? [20:57:34 CEST] <gnafu> I know libvpx-vp9 required '-b:v 0'. [21:03:43 CEST] <jamrial> gnafu: for constant quality you still need to set bitrate to 0 [21:04:00 CEST] <jamrial> otherwise the default of 256 is used, which results in constrained quality [21:06:43 CEST] <gnafu> jamrial: Thanks :-). I wanted to make sure I wasn't just putting it out of habit if it wasn't actually needed. [23:10:41 CEST] <lotharkript__> Hi all. Commit http://git.videolan.org/?p=ffmpeg.git;h=ddef3d902f0e4cbd6be6b3e5df7ec158ce5… enabled passing through of rotation side data from input to output. This is an issue when using HW filter to rotate, but have no way of clearing this side data after rotation. Is there a way to clear stream side data for output, from command line ? [23:20:08 CEST] <tmm1> would it make sense to let the metadata bsfs passthrough packets they weren't able to parse? [23:53:27 CEST] <cone-276> ffmpeg 03Paul B Mahol 07master:0baca077593d: avilter/af_afir: add irfmt option [23:53:27 CEST] <cone-276> ffmpeg 03Paul B Mahol 07master:196dd13c76c2: avfilter/avf_showspectrum: implement zoom mode [00:00:00 CEST] --- Fri Oct 5 2018

1 0

ffmpeg.log.20181004
by burek 05 Oct '18

05 Oct '18

[00:21:06 CEST] <kepstin> audio can only be cut on frame accuracy (and it's tricker because some codecs need preroll too). You'll normally only get within ~25ms with aac, I think? [01:58:21 CEST] <lmat> I'm trying to convert mp3 to CD-audio wav. [01:58:40 CEST] <lmat> ffmpeg -i "$i" -f s16le -ar 44100 -ac 2 "$(basename "$i" .mp3).wav"; should do it? [01:59:04 CEST] <lmat> I'm hoping that will take a mp3 file input and output signed 16-bit little-endian 44100 khz, 2-channel audio PCM wav file. [01:59:11 CEST] <lmat> (according to the red book or whatever it's called) [01:59:24 CEST] <lmat> (I'm then going to feed these files into cdrecord to burn the disk) [01:59:35 CEST] <lmat> I ran that conversion, but ffplay doesn't play the audio. [01:59:43 CEST] <lmat> "Invalid data found when processing input" [02:03:23 CEST] <lmat> hmm, looks like that ffmpeg command didn't write the RIFF header information?!? [02:18:04 CEST] <fella> lmat: try '... c:a pcm_u8 ...' instead [02:19:21 CEST] <relaxed> this has always worked for me, ffmpeg -i "$i" -map 0:a:0 "${i##*/}".wav [02:21:42 CEST] <relaxed> er, "${i%.*}".wav [02:31:35 CEST] <lmat> fella: u8!? that's an 8-bit format? [02:32:25 CEST] <lmat> relaxed: What does 0:a:0 do? [02:34:10 CEST] <fella> lmat: kk, so 'pcm_s16le' might be a better choise ;) [02:34:40 CEST] <lmat> relaxed: I did as you suggest, then cdrecord says, "Inappropriate audio coding in 'song.wav'." [02:37:16 CEST] <furq> lmat: you want -c:a pcm_s16le and get rid of -f s16le [02:37:27 CEST] <furq> -f overrides the output format, so it's just writing raw pcm data [02:37:38 CEST] <lmat> OH! [02:38:18 CEST] <lmat> furq: and stereo? [02:38:25 CEST] <furq> that's covered by -ac 2 [02:38:31 CEST] <furq> although i assume your mp3s are stereo anyway [02:38:52 CEST] <furq> also yeah use ${i%.*}.mp3 or some other suitable shell expansion [02:39:20 CEST] <furq> or uh [02:39:21 CEST] <furq> .wav [02:39:32 CEST] <lmat> sure [02:39:46 CEST] <lmat> hey, cdrecord is doing it! [02:39:56 CEST] <furq> -ac 2 -ar 44100 will just be no-ops if your source is 44.1k stereo anyway [02:39:59 CEST] <furq> so there's no harm leaving them in [02:40:11 CEST] <lmat> furq: I have no reason to think the source is as you mention. [02:40:25 CEST] <furq> sure [02:40:29 CEST] <furq> like i said, leave them in [02:42:25 CEST] <lmat> aye [02:43:55 CEST] <lmat> thanks so much! \o/ [02:44:01 CEST] <lmat> Now it says I have too much data ^_^ [02:45:17 CEST] <relaxed> when trying to grab two seconds of video with -vf 'select=between(t\,10\,12)', it appears to be decoding the whole file [02:47:14 CEST] <relaxed> lmat: pastebin.com your command and output [02:48:43 CEST] <lmat> relaxed: I think I'm good to go. I was trying to put beethoven symphony 5,7, piano concerto 5, piano sonata 8, and a string quartet. I think it's legitimate ^_^ [02:49:02 CEST] <relaxed> ah, too much data on the cd [02:49:10 CEST] <lmat> relaxed: too much audio. Fo sho [02:52:43 CEST] <furq> yeah you only get about 80 minutes on a cd [02:53:22 CEST] <furq> emphasis on "about" because i've seen 87 minutes [02:53:35 CEST] <furq> but i can't imagine anyone is still making blanks that are capable of that [02:54:20 CEST] <lmat> Yeah, I've always been fuzzy ^_^ [02:54:31 CEST] <lmat> My disk says "52X 700MB 80min" [02:54:42 CEST] <furq> you can overburn pretty much any blank [02:54:52 CEST] <furq> but whether you get one second or five minutes is impossible to know until the write fails [08:25:43 CEST] <sharax> hello [08:26:42 CEST] <sharax> i want install ffmpeg on centos 7 and php 7 [08:26:45 CEST] <sharax> can help me? [08:55:11 CEST] <JEEB> sharax: php-ffmpeg or whatever has nothing to do with FFmpeg. sorry [08:55:18 CEST] <JEEB> spamming your message will not help you [08:55:32 CEST] <JEEB> for FFmpeg there IIRC is a compilation guide on the wiki just for FFmpeg [15:23:46 CEST] <tytan> Hello everyone, I may have a trivial question. Why is ripping a DVD on GNU/Linux not as easy as "ffmpeg -i /dev/cdrom -c:v libx265 dvd.mp4" ? Usually ffmpeg accepts everything as an input for what I have done. [15:33:06 CEST] <Hello71> for one, last I checked, ffmpeg didn't support reading ISO9660/UDF files [15:37:43 CEST] <Mavrik> DVDs also tend to be DRM protectd [15:38:58 CEST] <relaxed> there were many tools already that ripped DVDs, like vobcopy [15:42:15 CEST] <furq> tytan: nobody has been bothered to add dvdnav support [15:42:29 CEST] <tytan> I don't know what that is, sorry [15:43:04 CEST] <furq> libdvdnav [15:43:19 CEST] <furq> more or less the dvd equivalent of libbluray [15:43:23 CEST] <furq> which is supported [15:44:17 CEST] <tytan> ok, can I just get libdvdnav and expect ffmpeg to accept a DVD as input then? Does it mean ffmpeg can rip BluRays easily? [15:45:01 CEST] <furq> no and yes [15:45:04 CEST] <tytan> damn [15:46:29 CEST] <furq> if your disk is encrypted and you have libdvdcss installed then you can probably just pipe from vobcopy [15:46:45 CEST] <furq> so something like vobcopy -M -o - | ffmpeg -i - -c:v libx265 dvd.mp4 [15:48:48 CEST] <furq> maybe vobcopy needs -l as well, i forget now [15:49:08 CEST] <tytan> what input does vobcopy expect? /dev/cdrom? [15:50:11 CEST] <furq> it wants the mountpoint iirc [15:50:17 CEST] <furq> i've not used it in years [15:51:40 CEST] <tytan> same :/ [15:51:57 CEST] <tytan> well, I haven't used an optical disc in years [15:52:30 CEST] <Nacht> I dont even have an optical drive anymore [15:53:35 CEST] <tytan> that's the point. I ditched my last optical drive in 2011 [15:54:03 CEST] <tytan> now I try to rip that one DVD for a friend with an external drive because I was like yeah ffmpeg can do everything :D [15:59:25 CEST] <tytan> I'm trying to pipe vobcopy into ffmpeg now. it starts by creating "1-1.vob.partial" in the directory [16:08:08 CEST] <King_DuckZ> hello, I have a webm file for which ffprobe returns this https://alarmpi.no-ip.org/kamokan/cq?colourless the problem is in my c++ code the object returned by avformat_alloc_output_context2() has nb_streams == 0 [16:08:12 CEST] <King_DuckZ> is that normal? [16:08:18 CEST] <King_DuckZ> how can it be? [16:08:36 CEST] <JEEB> no packets have been read yet? [16:08:59 CEST] <JEEB> there's a probing function as well as you could just read stuff yourself until you think you've had enough [17:04:56 CEST] <King_DuckZ> JEEB: I'm refactoring some code and I think it used to work... let me see if I can see this probing function anywhere [17:05:11 CEST] <King_DuckZ> or if it was just reading straight away [17:10:46 CEST] <JEEB> King_DuckZ: http://svn.ffmpeg.org/doxygen/trunk/group__lavf__decoding.html#gad42172e27c… [17:19:25 CEST] <King_DuckZ> JEEB: thanks [17:22:38 CEST] <King_DuckZ> funny: "options If non-NULL, an ic.nb_streams long array of pointers" but then you need to call this function before you get something meaningful in nb_streams [17:22:51 CEST] <King_DuckZ> I'm just passing null btw [17:48:46 CEST] <King_DuckZ> is there any way to tell if an AVFormatContext was allocated with avformat_open_input() or avformat_alloc_output_context2() ? so that I know if I should call avformat_close_input() or not before avformat_free_context()? [17:50:22 CEST] <King_DuckZ> or is it safe to just call it all the time? [19:38:55 CEST] <chocolate-elvis> does anyone know of a clever way to check the output of 8bit per channel, 10 and 12? to make sure the bit depth is being maintained? using ffmpeg to decode 12bit jp2k files and passing to a AVFoundation ProRes encoder [19:41:52 CEST] <furq> chocolate-elvis: if you're encoding with ffmpeg the info dump before it starts encoding will list the pixel format [19:41:58 CEST] <furq> if it ends in 12le or 12be then it's 12-bit [19:43:04 CEST] <chocolate-elvis> got it - 12bit little endian vs big endian. any way to programmatically test the bit depth is being maintained in an encoding pipeline? from start to finish? its a strange question I know! [19:43:43 CEST] <chocolate-elvis> y'know. to make sure it's actually working? thought about creating some test ramps in nuke, but not sure... [19:44:10 CEST] <chocolate-elvis> if there's a better way [19:44:41 CEST] <furq> if part of the chain is outside of ffmpeg then i don't know of anything [19:57:57 CEST] <ilushka4> Hey guys, for some reason, I have a rtsp(mms) stream which I can run with windows media player, but cannot run it with ffmpeg (first tried it with ffmpeg-python and then ffplay). I was trying the query: .\ffplay.exe -i "mms://foobar" -f rtsp, but it returns 400 Bad request [21:54:51 CEST] <fella> ilushka4: is it a public stream? [21:55:48 CEST] <GuiToris> hey ChocolateArmpits, can you check this mediainfo output? https://ptpb.pw/dTWE I've followed your advise and I got 'Not Supported Video' again [21:55:57 CEST] <GuiToris> what did I mess up this time? [21:56:27 CEST] <GuiToris> I found some differencies but I don't know if they matters [21:57:15 CEST] <GuiToris> it's Main(a)L5.1 instead of Main@L5 and 16 frames instead of 5 [21:57:50 CEST] <GuiToris> other than these one, I haven't found anything peculiar [21:58:16 CEST] <relaxed> GuiToris: that could be it, if 5 doesn't work try 4.1 [21:58:36 CEST] <GuiToris> Main@L5 has worked [21:58:46 CEST] <GuiToris> I assume 5.1 is not much different [21:59:18 CEST] <GuiToris> I used yuv420p and profile main [22:00:12 CEST] <relaxed> ok, use -level 5 [22:01:18 CEST] <relaxed> and -t 10 to create a 10 second sample. [22:02:56 CEST] <GuiToris> does 'preset veryslow' messes around? [22:03:12 CEST] <GuiToris> I used to be able to play all my video [22:03:20 CEST] <GuiToris> s [22:04:00 CEST] <relaxed> I'm pretty sure -level will set limits to presets [22:09:33 CEST] <GuiToris> it became High@L5 [22:10:20 CEST] <relaxed> GuiToris: -profile:v main -level:v 5 [22:10:29 CEST] <GuiToris> yes, I've just realized [22:22:54 CEST] <GuiToris> relaxed, so I'm back, it's not the 5.1 that causes the problem [22:23:24 CEST] <GuiToris> I reencoded the encoded video and I made 4 5 and 5.1 all worked [22:24:39 CEST] <GuiToris> what does CABAC / 4 Ref Frames mean? [22:24:42 CEST] <GuiToris> that's different [22:30:35 CEST] <ChocolateArmpits> GuiToris, https://en.wikipedia.org/wiki/Context-adaptive_binary_arithmetic_coding [22:31:11 CEST] <ChocolateArmpits> And "Ref Frames" signifies "the size of the DPB (Decoded Picture Buffer). " [22:32:07 CEST] <GuiToris> wow, you are really educated! [22:32:14 CEST] <ChocolateArmpits> I just know the links [22:32:19 CEST] <ChocolateArmpits> here http://www.chaneru.com/Roku/HLS/X264_Settings.htm#ref [22:33:01 CEST] <ChocolateArmpits> some more about Refs https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Decoded_picture_buffering [22:33:13 CEST] <GuiToris> do you think it can really cause incompatibilty? [22:33:34 CEST] <ChocolateArmpits> too high ref count could, but at 4 frames, certainly not [22:34:04 CEST] <ChocolateArmpits> CABAC could only be an issue with very old slow hardware decoders [22:34:11 CEST] <GuiToris> it's 16 currently, as I see it's the highest [22:34:37 CEST] <ChocolateArmpits> could you paste the output once more I think the link is dead [22:34:44 CEST] <GuiToris> sure [22:35:30 CEST] <GuiToris> https://ptpb.pw/dTWE [22:35:49 CEST] <ChocolateArmpits> GuiToris, where are you trying to import it to? [22:36:18 CEST] <GuiToris> does import mean play here? [22:36:43 CEST] <GuiToris> this would be the final video, I just can't play on our TV - again [22:36:52 CEST] <ChocolateArmpits> oh just remember [22:36:53 CEST] <ChocolateArmpits> right [22:36:56 CEST] <ChocolateArmpits> remembered* [22:37:30 CEST] <ChocolateArmpits> GuiToris, have you gotten any other combination of AVC+Vorbis playing ? [22:37:47 CEST] <ChocolateArmpits> because that's an awkward mix [22:39:19 CEST] <GuiToris> https://ptpb.pw/2SSP [22:39:26 CEST] <GuiToris> that's what we did a couple of days ago [22:39:33 CEST] <ChocolateArmpits> that one works right? [22:39:42 CEST] <GuiToris> it worked, yes [22:39:55 CEST] <GuiToris> I don't know why is it AVC and if I reencode it's different [22:40:18 CEST] <GuiToris> I suspect veryslow causes these problems [22:41:53 CEST] <GuiToris> this is the reencoded output https://ptpb.pw/N93O [22:41:54 CEST] <ChocolateArmpits> GuiToris, well you can try matching the profile level, refs count, bframe count [22:42:17 CEST] <GuiToris> it became avc1 here [22:43:01 CEST] <GuiToris> I've tried 5.1 is not a problem [22:43:32 CEST] <GuiToris> I'll try this ref number [22:43:55 CEST] <ChocolateArmpits> the parameter is -refs for ffmpeg [22:44:06 CEST] <relaxed> GuiToris: try this, ffmpeg -i input -t 10 -profile:v main -level:v 4.1 -preset veryslow -c:a aac -b:a 192k -movflags +faststart output.mp4 [22:44:36 CEST] <GuiToris> vorbis is not a problem [22:45:38 CEST] <relaxed> ok, then use -profile:v main -level:v 4.1 -preset veryslow [22:45:52 CEST] <relaxed> you shouldn't need to change the refs by hand [22:47:39 CEST] <GuiToris> your previous line also worked 4, 5 or even 5.1 worked [22:47:50 CEST] <GuiToris> -I reencoded the video- [22:48:04 CEST] <GuiToris> but this isn't a good idea, is it!? [22:48:52 CEST] <GuiToris> I think I should make a new one, but I don't know what makes the incompatibility [22:49:20 CEST] <GuiToris> when I reencoded the encoded video from 5.1 to 5.1, it worked [22:49:33 CEST] <GuiToris> I didn't use veryslow this time [22:49:36 CEST] <relaxed> the problem is setting -preset veryslow with a -level that's too high [22:51:34 CEST] <GuiToris> I think you're right, I didn't have any problems while I used medium [22:53:24 CEST] <GuiToris> the original encoding took about 6 hours, I may not redo the whole thing but reencode this one with 'ultrafast' 'main' and 'yuv420p' and store it on a flashdrive [23:04:14 CEST] <tytan> Hello everyone, I tried to convert a VP9 webm to a H265 mp4 with the latest static release of ffmpeg on windows using the -c:v hevc_amf option but it just failed. Windows 10 1809, RX Vega 64 driver 18.5.1 [23:07:58 CEST] <tytan> wait, it wailed on a 8K video but worked on a 720 file?! [23:08:02 CEST] <tytan> *720p [23:12:03 CEST] <tytan> *worked [23:27:02 CEST] <GuiToris> relaxed, ChocolateArmpits I've tried level 4.1 which also decreases the ref number and it can be played even if I use veryslow preset [23:27:32 CEST] <GuiToris> does this also reduce the quality of the picture? [23:29:46 CEST] <relaxed> not to the human eye, stick with 4.1 [23:32:24 CEST] <GuiToris> thank you for your help! [23:41:39 CEST] <kepstin> tytan: i haven't seen any published docs on the limits of amd's hardware encoder, but I wouldn't be surprised if it maxes out at 4k. [23:42:14 CEST] <tytan> too bad because encoding 8K takes a long time even on an 8-core CPU [23:46:05 CEST] <tytan> are there any hardware encoders that don't produce awful results? I'm pretty disappointed of h264_videotoolbox [23:46:46 CEST] <kepstin> tytan: no, they're all pretty much like that. Designed to perform realtime or faster encoding on a limited power budget, that's just what you get. [23:47:24 CEST] <tytan> so libx264 and libx265 are my best quality options for mp4? [23:47:44 CEST] <kepstin> yep [23:48:32 CEST] <tytan> and stuff like minterpolate is always crazy slow if you want actual motion interpolation and not blend? [23:48:40 CEST] <kepstin> http://radeon.com/_downloads/vega-whitepaper-11.6.17.pdf says that Vega's hardware encoder maxes out at 2160p60 [23:48:46 CEST] <kepstin> (aka 4k 60Hz) [23:48:52 CEST] <tytan> nice to know, thanks [23:50:06 CEST] <kepstin> well, motion interpolation is always gonna look bad no matter how fast or slow it runs ;) [23:50:30 CEST] <tytan> would you suggest something else? [23:51:00 CEST] <kepstin> I'd suggest leaving the video at its original framerate [23:51:45 CEST] <kepstin> (or if necessary to increase video framerate for technical reasons, use the fps filter which will duplicate frames - it might introduce judder, but it'll overall keep the same "look") [23:52:58 CEST] <tytan> the -r option? [23:53:16 CEST] <kepstin> the -r output option is not entirely unlike the fps filter [23:53:25 CEST] <kepstin> (the fps filter has better rounding behaviour) [23:53:32 CEST] <tytan> ok [00:00:00 CEST] --- Fri Oct 5 2018

1 0

ffmpeg-devel.log.20181003
by burek 04 Oct '18

04 Oct '18

[01:00:11 CEST] <jkqxz> philipl: What else do you want? The DRM API sits underneath both VAAPI and all existing Linux Vulkan drivers for device and memory management, so introducing anything else seems pretty weird to me. [04:18:35 CEST] <philipl> jkqxz: I wasn't asking for anything new - more just what I should use if I want to try and wire them together. [04:27:03 CEST] <philipl> Wouldn't be surprised if this doesn't work well in practice. The dma_buf extension for vulkan doesn't provide a way to specify the memory layout of the image you are trying to import. [04:28:44 CEST] <philipl> Ok, There's another extension for that. [04:29:18 CEST] <atomnuker> that extension was just merged into the spec [04:29:27 CEST] <atomnuker> and isn't enabled by default [04:29:31 CEST] <philipl> yay [04:29:39 CEST] <atomnuker> no implementation supports it yet either [04:29:46 CEST] <philipl> So today it probably requires the same intermediate buffer thing I'm doing with cuda. [04:30:22 CEST] <atomnuker> be happy there's been progress, I've been bugging the people responsible since february [04:30:59 CEST] <philipl> I appreciate it. [04:31:15 CEST] <philipl> It'll be a while before I have the opportunity to try this out, so maybe it'll get implemented somewhere by then. [04:31:29 CEST] <philipl> I guess I should dig up an nvidia person to bug about their problems... [11:07:10 CEST] <durandal_1707> michaelni: you gonna apply patches soon? [11:37:15 CEST] <cone-030> ffmpeg 03Michael Niedermayer 07master:c905840e8c0a: avcodec/tiff: check remaining packet size for strips [11:37:15 CEST] <cone-030> ffmpeg 03Michael Niedermayer 07master:9a9034958aec: avcodec/rasc: Fix off by 1 error in vertical coordinate [11:37:17 CEST] <cone-030> ffmpeg 03Michael Niedermayer 07master:f515c978f63f: avcodec/rasc: unref both frames on reinit [11:37:31 CEST] <michaelni> durandal_1707, rasc/tiff pathes applied [13:23:00 CEST] Action: durandal_1707 puts self into hibernation mode, wake me up when someone pings me! [13:41:46 CEST] <atomnuker> durandal_1707: you seem bored [13:42:15 CEST] <durandal_1707> so? [13:42:40 CEST] <atomnuker> try finishing diablo 1 in 12 hours (making sure you clean up each floor) [13:43:15 CEST] <durandal_1707> im playing portal games [13:43:43 CEST] <durandal_1707> still not finished [13:44:11 CEST] <atomnuker> eh? the first portal is beatable in 3 hours max, the second one in 12 [13:44:46 CEST] <durandal_1707> playing mel version [13:44:58 CEST] <durandal_1707> very hard [13:46:40 CEST] <atomnuker> huh, didn't know there were mods for portal 2, will give it a go [14:44:20 CEST] Action: gnafu notices mention about HEVC-in-AVI, winces. [17:09:27 CEST] <kierank> durandal_1707: we should have fps multiplayer [17:11:43 CEST] <atomnuker> the classic quake-style genre died years ago, now its all team shooters [17:12:05 CEST] <atomnuker> shootmania tried to revive it 6 years ago but failed [17:15:53 CEST] <iive> isn't battle royal the current trend? [17:17:34 CEST] <atomnuker> that's how out of date I am, I was thinking of csgo and overwatch [17:18:11 CEST] <atomnuker> I guess battle royale is deathmatch but I don't like the shrinking arena part of it or anything fortnite added [17:20:14 CEST] <iive> i think they still have teams... so not that far off. [18:07:08 CEST] <jya> BBB: do you have some code that could tell me what chrome subsampling a compressed would use, something that doesn't require to decode anything. [18:07:13 CEST] <jya> for vp9 that is [18:07:33 CEST] <JEEB> don't we have the bit stream parser thing for that? [18:07:44 CEST] <JEEB> I think we have the basics for VP9 as well [18:07:45 CEST] <BBB> yes we do [18:07:47 CEST] <BBB> use the cbs [18:08:17 CEST] <jya> on windows, the VP9 hardware decoder doesn't fail at all, and it returns a GPU frame stating it's NV12 [18:08:37 CEST] <JEEB> lovely [18:08:44 CEST] <jya> that gives me the same issue on edge, chrome, firefox with an intel or nvidia supporting vp9 [18:08:46 CEST] <jya> display crap [18:09:08 CEST] <jya> so I want to scan the first sample, see that it's 444 and bugger off [18:09:22 CEST] <JEEB> sounds warranted enough [18:09:37 CEST] <jya> haven't tested profile 2 444 [18:10:12 CEST] <jya> but i'm assuming it's the same.. I tried to generate content with ffmpeg to that extent. [18:10:55 CEST] <jya> BBB: could you point me at the code in ffvp9 where I could extract that info? [18:11:19 CEST] <JEEB> I think you'd be better off looking at the VP9 CBS [18:11:40 CEST] <jya> there may be some info in the windows vp9 MFT, but I can't find it [18:12:02 CEST] <BBB> is it ok if I let others answer that? I think CBS is the right approach here [18:12:15 CEST] <BBB> and Im trying to keep my head focused on av1 for a bit longer :) [18:12:20 CEST] <BBB> sorry [18:12:59 CEST] <JEEB> jya: see cbs_vp9*.c [18:13:35 CEST] <jya> JEEB: i know nothing on vp9 bitstream (other than having looked at the code telling me it's a keyframe or what the resolution is) [18:13:43 CEST] <JEEB> neither do I [18:13:47 CEST] <jya> BBB: that's okay.. thank you for your work [18:13:54 CEST] <JEEB> that's just the parser we use for dumping out packet info [18:14:01 CEST] <JEEB> including stuff like chroma subsampling etc [18:14:16 CEST] <jamrial> chroma subsampling is not signaled in the bitstream, afaik [18:14:47 CEST] <jya> jamrial: it's not? [18:14:58 CEST] <JEEB> ok, I just saw subsampling_x in the CBS and assumed :P [18:15:21 CEST] Action: jya not finding cbs_vp9 in ffvp9 code [18:16:05 CEST] <jamrial> wait, you mean pix_fmt? [18:16:30 CEST] <jya> jamrial: I jsut want to know if it's 422 or 444 [18:16:31 CEST] <jamrial> was thinking sample position, sorry [18:16:42 CEST] <JEEB> jya: it is not in the decoder, since I expected the code you'd probably end up copypasting to be simpler in the CBS :P [18:16:52 CEST] <jamrial> yeah, that's in the bitstream alright [18:16:59 CEST] <BBB> you could also extend the vp9_parser to signal the pix_fmt [18:17:01 CEST] <jamrial> cbs has no public interface [18:17:01 CEST] <BBB> its fairly trivial [18:17:19 CEST] <jamrial> i submitted a patch for that some time ago, but it's not complete afaik [18:18:05 CEST] <JEEB> I'd expect jya to not want to drag more stuff from FFmpeg but rather just copypasta the required minimum into firefox [18:18:09 CEST] <JEEB> or something [18:18:22 CEST] <JEEB> and I just happened to think that CBS code would have been simpler to follow for parsing [18:18:23 CEST] <jya> JEEB: we have the vp9 parser included in our source tree [18:18:42 CEST] <jamrial> it can't not be there seeing it's pulled by the vp9 decoder [18:18:51 CEST] <jamrial> but yeah, let me dig my patch [18:19:27 CEST] <jya> would likely have to get that change upstreamed. don't want to carry on patches [18:19:42 CEST] <jya> TD-Linux: had provided some links inside libvpx [18:19:51 CEST] <jya> need to find what he wrote :) [18:20:09 CEST] <jamrial> http://ffmpeg.org/pipermail/ffmpeg-devel/2018-January/224219.html [18:20:22 CEST] <jamrial> i can try to tidy it up a bit and resubmit it [18:22:06 CEST] <jamrial> in any case, if you only want to know if the bitstream is i420 (where hw decoding is know to work), then shouldn't looking at profile be enough? [18:22:57 CEST] <jya> jamrial: it works for 10/12 bits 420 [18:23:02 CEST] <jya> so that's profile 2 still [18:28:01 CEST] <jamrial> i was under the impression that profile 0 is 420 8 bit, profile 2 is 420 10/12, then 422, 440 and 444 are profile 1 (8 bit) and profile 3 (10/12 bit) [18:28:38 CEST] <jamrial> so if the stream is profile 0 or 2, it can't be 444 as you mentioned above [18:30:28 CEST] <BBB> thats correct btw [18:31:02 CEST] <jya> jamrial: I got led to believe differently by the samples someone provided to me: [18:31:25 CEST] <jya> https://jyavenard.github.io/htmltests/tests/webm-hdr.html [18:31:47 CEST] <jamrial> the last two there should say profile 3 [18:31:56 CEST] <jya> jamrial: that's good to know ! [18:33:40 CEST] <jamrial> jya: https://pastebin.com/raw/zXaGWK9F [18:34:23 CEST] <jya> jamrial: what's 422 10/12 bits? [18:34:45 CEST] <jamrial> also profile 3 [18:34:53 CEST] <nevcairiel> https://www.webmproject.org/vp9/profiles/ [18:35:45 CEST] <jya> need to wrap some samples , the windows MFT decoders can't do odd width/height. so none of those samples are of any use when it comes to testing the hw decoder [19:13:30 CEST] <cone-030> ffmpeg 03Paul B Mahol 07master:4c514edc5bc0: avfilter/avfilter: fix typos in comments [20:28:37 CEST] <jya> jamrial: thanks for suggesting reading the profile.. simple and neat [20:28:43 CEST] <jya> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/vp9_parser.c#L41 [20:29:13 CEST] <jya> that frame header, is this a constant value? (Wonder if I could use this to detect I'm not parsing vp9) [20:30:39 CEST] <jya> ah 2 the doc tells me [21:15:58 CEST] <azaki> jamrial, i noticed that jkqxz's av1 stuff landed a few days ago, i'm guessing the parser isn't too far behind? [21:16:20 CEST] <jya> BBB: I created samples of all type (https://jyavenard.github.io/htmltests/tests/webm-hdr.html) this particular one : https://jyavenard.github.io/htmltests/mediatest/webm/vp9/yuv422p10.webm doesn't decode with ffvp9. It's a single frame, the compressed sample is 227748 . First call to avcodec_decode_video2 shows that it used the entire buffer, but nothing is [21:16:20 CEST] <jya> returned. Next when you drain the decoder, avcodec_decode_video2 it will return -1 [21:16:39 CEST] <jamrial> azaki: no, i'll commit it soon [21:16:51 CEST] <jya> all decode fine with libvpx [21:16:58 CEST] <BBB> can you file bugs somewhere? [21:17:03 CEST] <BBB> Im unlikely to be able to look right away [21:20:14 CEST] <jamrial> jya: the ffmpeg cli handles it just fine [21:20:35 CEST] <jya> jamrial: indeed, ffplay plays it. [21:20:55 CEST] <jya> i wonder if it's the wrapper around avcodec_decode_video2 [21:24:10 CEST] <jya> it has that behaviour just for 422 10/12 bits and 420 12 bits. all the others are fine on that page [21:49:08 CEST] <cone-030> ffmpeg 03Paul B Mahol 07master:9e45364a80f9: avfilter/af_afir: make IR gain control more flexible [21:50:30 CEST] <kierank> durandal_1707: do you play fortnite [21:51:51 CEST] <durandal_1707> kierank: i play only linux games [21:52:59 CEST] <BradleyS> fortnite runs on linux [21:53:21 CEST] <TheAMM> linux was a mistake [21:53:36 CEST] <BradleyS> s/linux/wine/ :) [22:05:22 CEST] <cone-030> ffmpeg 03Marton Balint 07master:45fa756fa4dd: avformat/ip: factorize some IP filtering and resolving functions to a new file [22:05:23 CEST] <cone-030> ffmpeg 03Marton Balint 07master:826972c9d81a: avformat/udp: use factorized ip functions [22:05:24 CEST] <cone-030> ffmpeg 03Marton Balint 07master:9d4829f3c915: avformat/rtpproto: use factorized ip functions [22:05:25 CEST] <cone-030> ffmpeg 03Marton Balint 07master:91a136345273: avformat/udp: add support for generic source filtering [22:05:26 CEST] <cone-030> ffmpeg 03Marton Balint 07master:d3bda871f033: avformat/udp: specify the local address for some source filtered multicast joins [22:05:27 CEST] <cone-030> ffmpeg 03Marton Balint 07master:ab0812c1a892: avformat/udp: always use IP_ADD_SOURCE_MEMBERSHIP for subscribing to an UDP multicast source group in IPv4 [22:05:28 CEST] <cone-030> ffmpeg 03Marton Balint 07master:934432257396: doc/protocols: simplify and clarify UDP localaddr option [22:16:45 CEST] <cone-030> ffmpeg 03Marton Balint 07master:8f14170b9a4e: avfilter/filters: add ff_inlink_peek_frame and ff_inlink_queued_frames to access frames in the inlink fifo [22:16:46 CEST] <cone-030> ffmpeg 03Marton Balint 07master:7ca2ee059e3d: avfilter/f_cue: use inlink fifo for queueing frames [00:00:00 CEST] --- Thu Oct 4 2018

1 0

ffmpeg.log.20181003
by burek 04 Oct '18

04 Oct '18

[02:16:23 CEST] <axisys> how do I remove from time 51:40 to 52:35 from an mp4 file? [02:16:31 CEST] <axisys> I like to keep the rest [02:30:16 CEST] <tdr> you probably want to clip those two entire seconds or at least a couple frames, not those exact points [02:39:07 CEST] <axisys> tdr: not sure how to do that [02:40:20 CEST] <axisys> it's a 56 min long video.. but there is portion where I by mistake shows my private key info.. I need to take that small portiout before sharing [02:40:31 CEST] <axisys> showed* [03:24:46 CEST] <relaxed> axisys: ffmpeg -i input -c copy -t 00:51:40 start.mp4 [03:25:20 CEST] <relaxed> ffmpeg -ss 00:52:35 -i input -c copy end.mp4 [03:26:53 CEST] <relaxed> ffmpeg -f concat -safe 0 -i <(for i in start.mp4 end.mp4; do printf "file "%s"\n" "$PWD"/"$i"; done) -c copy -movflags +faststart done.mp4 [03:33:20 CEST] <axisys> relaxed: awesome.. saving it to my cheat sheet.. what do the -movflags and +faststart do ? [03:34:18 CEST] <relaxed> moves the index to the start of the container for faster loading [03:35:13 CEST] <axisys> relaxed: thank you! [03:35:24 CEST] <relaxed> you're welcome [03:36:12 CEST] <axisys> relaxed: so I used vlc to get those times .. I suppose that works fine.. any recom in there? [03:38:52 CEST] <relaxed> Well, mpv is the best video player. Watch the output make sure your personal info omitted [03:39:26 CEST] <axisys> relaxed: I checked with vlc and it has been.. i will check out mpv [03:39:31 CEST] <axisys> relaxed: thank you again! [03:42:50 CEST] Action: relaxed levels up [05:21:37 CEST] <Marble68> ffmpeg pastbin is down - so Ill ask. Ive got frames being captured with timestap - works great. Ive also gotten frames to capture with %03d to get incremental frame numbers. Is where a way to combine these so that I can get frame number AND time stamp? It just overwrites the frame timestamp because its highest precision is 1 second. So Im after something like -strftime 1 "img/%Y-%m-%d_%H-%M-%S_test_%01d.jpg" [05:23:47 CEST] <Marble68> that way if 10 frames are captured a second - Ill get <timestamp>_test_<frame # this second> [05:25:18 CEST] <Marble68> Im thinking Im going to have to modify strftime source to do something like this - maybe a rolling integer that resets when the second changes [05:25:35 CEST] <Marble68> TIA for any advice [06:31:15 CEST] <the_gamer> hi there, i got some pictures i want to make a video of. no problem but is there a way to tell ffmpeg to take the audio from another .mp4? [06:50:52 CEST] <furq> the_gamer: -i foo%d.jpg -i foo.mp4 -map 0:v -map 1:a [06:51:07 CEST] <the_gamer> oh great, thank you :) [06:51:11 CEST] <furq> you shouldn't even need -map in this case because the first input has no audio [06:51:16 CEST] <furq> but it's good to be explicit [07:03:56 CEST] <mbnt> Hi, I am sort of a newb to ffmpeg. I want to convert h264 footage to cineform. My camera codec is h264 and I want to edit in Resolve on Linux and it does not recognize my codec, but Cineform, it does. I have a folder full of H264 footage that I want to edit. What would be the command to convert the folder contents to cineform? [07:20:16 CEST] <lindylex> What I want to do. I want to overlay the video num1.mov on the image cover.png. The video has a black background I would like to be transparent so I can see the cover.png below. [07:20:28 CEST] <lindylex> This is what I have tried : https://pastebin.com/BG1SPwtt [07:49:29 CEST] <killown> how can I add an image to the end of the video? [07:49:39 CEST] <killown> I mean, that will last 15 seconds [07:53:26 CEST] <killown> ffmpeg -loop 1 -t 10 -i preview.png -vf "crop=w=W:h=ih:x='(iw-W)*t/10':y=0" -r 25 -pix_fmt yuv420p out.mp4 [07:53:37 CEST] <killown> Undefined constant or missing '(' in 'W' [07:53:37 CEST] <killown> Error when evaluating the expression 'W' [07:56:13 CEST] <killown> ffmpeg -r 1/5 -i preview.png -c:v libx264 -vf fps=25 -pix_fmt yuv420p out.mp4 [07:56:37 CEST] <killown> http://wpbin.io/g10oj7 [07:56:44 CEST] <killown> is this even possible to use ffmpeg to do that? [08:03:25 CEST] <lindylex> Yes it is possible to do this. [08:06:23 CEST] <killown> I did [08:06:31 CEST] <killown> I don't know how to merge two videos [08:09:17 CEST] <killown> should be simple to join two videos? [08:12:09 CEST] <killown> lindylex, can you help me join videos? [08:12:47 CEST] <poutine> are you sure that error is generated from that last command line you put? [08:12:56 CEST] <poutine> can you post the full log? [08:13:03 CEST] <lindylex> The image is it the same size as the video you are joining it to? [08:13:32 CEST] <poutine> https://stackoverflow.com/questions/20847674/ffmpeg-libx264-height-not-divi… <- you looked at this as well? [08:13:48 CEST] <killown> lindylex, not the same [08:13:52 CEST] <furq> killown: crop=w=iw [08:14:02 CEST] <killown> furq, sorry already fixed this issue [08:14:37 CEST] <furq> well yeah the width and height need to be divisible by 2 [08:14:51 CEST] <killown> now I created 15 second image [08:15:02 CEST] <killown> I want to join video.mp4 with picture.mp4 [08:15:20 CEST] <furq> https://trac.ffmpeg.org/wiki/Concatenate#demuxer [08:15:42 CEST] <killown> this is not working [08:15:50 CEST] <killown> the 15 seconds turns 1 seconds in the end [08:16:06 CEST] <killown> [mp4 @ 0x55fccd4a70c0] Non-monotonous DTS in output stream 0:0; previous: 359196, current: 359130; changing to 359197. This may result in incorrect timestamps in the output file. [08:16:36 CEST] <furq> do the framerates match [08:16:54 CEST] <killown> what? [08:17:01 CEST] <furq> both files need to have the same framerate [08:17:03 CEST] <killown> don't know what that means [08:17:06 CEST] <killown> ok [08:17:14 CEST] <killown> how to do that? [08:17:25 CEST] <lindylex> furq : they both need to have audio. The image needs to have blank audio when created I think for the concat to work. [08:18:20 CEST] <furq> killown: -framerate 30 -i preview.png [08:18:22 CEST] <furq> and get rid of -r 25 [08:18:42 CEST] <furq> obviously replace 30 with whatever your other input is [08:20:22 CEST] <killown> I am using this ffmpeg -loop 1 -i preview.png -c:v libx264 -t 15 picture.mp4 [08:23:39 CEST] <killown> how do I replace this -i mylist.txt with -i file1.mp4 file2.mp4 [10:28:30 CEST] <lindylex> killown : Convert each file like this. ffmpeg -i input1.mp4 -c copy -bsf:v h264_mp4toannexb -f mpegts intermediate1.ts [10:28:54 CEST] <lindylex> killown : And This ffmpeg -i input2.mp4 -c copy -bsf:v h264_mp4toannexb -f mpegts intermediate2.ts [10:29:05 CEST] <lindylex> Then combine them together. ffmpeg -i "concat:intermediate1.ts|intermediate2.ts" -c copy -bsf:a aac_adtstoasc output.mp4 [10:29:19 CEST] <lindylex> This is here also https://pastebin.com/7GhTTYGv [10:42:13 CEST] <the_gamer> i am having a problem. command: "ffmpeg -i rendered/%04d.png -i P1010197.MP4 -map 0:v -map 1:a -q:a 1 -q:v 1 -c:a copy rendered.mp4". this is using only the first picture of the rendered/*.pngs. why? it should use all of them [10:47:23 CEST] <the_gamer> they are all in one row, no number/picture is missing. why are tehy not used? [10:53:13 CEST] <the_gamer> nobody? anybody? [10:59:39 CEST] <durandal_1707> the_gamer: there should be no gaps [10:59:51 CEST] <the_gamer> there aren't [11:01:06 CEST] <durandal_1707> the_gamer: pastebin full ffmpeg output [11:01:49 CEST] <the_gamer> i have to apologize [11:02:10 CEST] <the_gamer> pictures are from blender which i thought does not make gaps but blender screwed up and made gaps [11:02:12 CEST] <the_gamer> thank you [11:24:59 CEST] <zerodefect> I'm using a COTS multiplexer to multiplex an H.264 stream. I'm encoding the stream using x264 via FFmpeg using the C-API. The multiplexer logs errors when the stream does not adhere to the T-STD model; it believes the video stream is not quite CBR. Does anyone have any tips/suggestions. Admittedly, not too sure where to start (out of my depth?). [11:27:57 CEST] <JEEB> well the first question is whether you need to have VBV/HRD or actual "dumb" CBR which pads the stream to make it "really CBR" [11:29:14 CEST] <JEEB> for the first part you need to set maxrate/bufsize (at the minimum), and enable nal-hrd information output from x264 [11:29:52 CEST] <JEEB> see the x264 documentation which key=value pairs you have to give through x264-params (maxrate|bufsize are in the global API for libavcodec) [11:30:20 CEST] <JEEB> and then if you need "dumb" CBR then a) I'm very sorry b) set the x264 HRD mode to CBR [11:32:41 CEST] <zerodefect> For your first question, it's the former. [11:33:53 CEST] <zerodefect> Second question, I set "nal-hrd" option on encoder and set 'bit_rate' and 'bit_rate_tolerance' on AVCodecContext encoding properties. I'll look into bufsize. [11:34:45 CEST] <zerodefect> You've given me something to go on - thank you. [11:35:18 CEST] <JEEB> you need specifically maxrate and bufsize both [11:35:25 CEST] <JEEB> as it's maxrate over bufsize [11:35:32 CEST] <JEEB> otherwise VBV/HRD will not be done [11:36:31 CEST] <zerodefect> Ok. Cool. [11:59:36 CEST] <King_DuckZ> hello, could someone comment about this code please? https://alarmpi.no-ip.org/kamokan/cm?cc [12:01:06 CEST] <Mavrik> It's very green. [12:02:55 CEST] <King_DuckZ> Mavrik: replace the ?cc part with ?colourless if that bothers you :) or remove it entirely [12:15:25 CEST] <zerodefect> @JEEB if for example I'm wanting to encode a 10Mbit/s h.264 stream, what are sensible maxrate/bufsize values? Is that question a bit open-ended? [12:32:26 CEST] <furq> zerodefect: maxrate should be the same as bitrate for cbr [12:33:19 CEST] <furq> bufsize should generally be 1-2x your maxrate afaik [12:33:39 CEST] <zerodefect> Ah ok. Bufsize was the one throwing me. I'll try that out [12:33:51 CEST] <furq> idk if there are any special considerations there for cbr [13:39:25 CEST] <GuiToris> hey, this is a rather subjective question. Isn't a 555mb libx264 10-minute video rather big? [13:40:05 CEST] <GuiToris> it's almost the size of a CD [13:41:09 CEST] <GuiToris> I thought it would be around 100mb [13:43:53 CEST] <GuiToris> I forgot to mention it's a 16:9 1080p video [13:45:36 CEST] <durandal_1707> and fps? [13:46:36 CEST] <GuiToris> 25 [13:48:21 CEST] <GuiToris> durandal_1707, https://ptpb.pw/TLHl [13:48:35 CEST] <GuiToris> it's quality 25 [13:49:14 CEST] <furq> if crf 25 is coming out that big then the source is just hard to compress [13:49:36 CEST] <furq> i'm guessing this is video game footage or something like that [13:50:08 CEST] <durandal_1707> or fractals [13:50:19 CEST] <furq> or 10 minutes of the hbo logo [13:50:23 CEST] <GuiToris> no, it was recorded with my camcorder [13:50:39 CEST] <furq> i'm guessing you don't have a gimbal then [13:51:05 CEST] <furq> either that or it's low light and super grainy [13:51:14 CEST] <furq> or noisy, rather [13:51:42 CEST] <GuiToris> it's sometimes noisy right [13:53:20 CEST] <furq> you can try denoising or maybe using vidstab if it's shaky [13:54:17 CEST] <furq> but yeah that bitrate isn't extraordinarily high [13:54:23 CEST] <GuiToris> https://ptpb.pw/aPSJ [13:54:27 CEST] <GuiToris> here's a screenshot [13:54:32 CEST] <GuiToris> it's mostly like this [13:54:37 CEST] <furq> just be glad it's not a video capture of quake speedrunning [13:54:55 CEST] <furq> if you ever want to murder x264 then that's a good way to do it [13:55:06 CEST] <GuiToris> I've already used vidstab, it was shaky [13:56:02 CEST] <GuiToris> it was originally an interlaced video, do you think (since vidstab needs two passes) I should deinterlace the first pass too? [13:56:38 CEST] <furq> that would make sense, yeah [13:57:14 CEST] <GuiToris> I haven't used the -tune option, should I use it? [13:57:48 CEST] <GuiToris> none of them seems appropriate here [14:00:03 CEST] <GuiToris> is it maybe 'film'? [14:01:58 CEST] <Harzilein> <furq> or 10 minutes of the hbo logo [14:02:00 CEST] <Harzilein> :D [14:06:18 CEST] <th3_v0ice> The av_packet_unref(&packet) will only free the packet if there are no more references to it, correct? I assume this operation is not thread safe? [14:15:58 CEST] <atomnuker> yes, yes [14:27:57 CEST] <th3_v0ice> Ok, thanks [14:29:35 CEST] <th3_v0ice> One more question though, can I send same packet to two different muxers? [14:33:35 CEST] <atomnuker> yes, refcounting will take care of it [14:44:34 CEST] <th3_v0ice> Cool [15:57:21 CEST] <GuiToris> if I have separate video and audio files, is there any better way to combine them? ffmpeg -i video.mp4 -i audio.ogg -map 0:v -map 1:a -c copy happilytogether.mkv ? [15:58:51 CEST] <relaxed> GuiToris: nope [15:59:00 CEST] <GuiToris> thanks relaxed [15:59:36 CEST] <Blacker47> GuiToris, you can use mkvmerge if .mkv is what you want. [16:00:18 CEST] <GuiToris> yes, that's the desired container format, I'll look up, thank you for your suggestion [16:01:20 CEST] <Blacker47> but it is unclear what you want to go "better". [16:53:26 CEST] <ciga> hi [16:55:06 CEST] <ciga> I'm trying to get ffmpeg capture my screen and encode it using gpu. I'm on radeon with mesa using h264_vaapi. ffmpeg drops frames for some reason. anyone know how to fix this? [16:55:59 CEST] <ciga> im on ffmpeg 4.0.2-6 with Ubuntu [17:14:17 CEST] <relaxed> ciga: pastebin.com your command and output [17:16:18 CEST] <ciga> https://pastebin.com/L4H4yzdD [17:21:51 CEST] <relaxed> try adding -framerate 60 before the input [17:22:38 CEST] <ciga> it is the same [17:25:07 CEST] <relaxed> 30? [17:25:29 CEST] <ciga> still the same [17:26:26 CEST] <ciga> not sure if this is related: https://lists.ffmpeg.org/pipermail/ffmpeg-user/2018-February/038989.html [17:27:51 CEST] <relaxed> try using -f x11grab instead [17:28:28 CEST] <ciga> thats what I use [17:29:19 CEST] <relaxed> oh, I meant without vaapi [17:38:17 CEST] <ciga> libx264 and libx265 drops frames on 4.0.2, but works on 3.4.4 that comes with Ubuntu [17:38:41 CEST] <Mavrik> um. [17:38:54 CEST] <Mavrik> Neither libx264 or libx265 encode on GPU [17:39:32 CEST] <ciga> relaxed asked me to try it without vaapi [17:41:13 CEST] <Mavrik> ah, nevermind [17:44:52 CEST] <Mista_D> Trying to extract list of "key-frames only" with ffprobe, and get a lot of "ATSC A53 Part 4 Closed Captions" any way to skip them please? [17:50:22 CEST] <^Neo> hello friends, can someone recommend a function to programmatically fill an individual field of an AVFrame buffer? [17:50:39 CEST] <relaxed> Mista_D: pastebin.com the command and sample output of the problem [17:50:56 CEST] <ciga> so, it seems h264_vaapi works just fine with 3.4.4 [17:51:30 CEST] <JEEB> ^Neo: unfortunately most things expect both fields in one AVFrame [17:51:36 CEST] <ciga> hevc_vaapi says 'Encoding entrypoint not found (17 / 6)'. Is this something I can fix? [17:51:51 CEST] <JEEB> ciga: you'd have to check vainfo or whatever the vaapi information app was [17:52:07 CEST] <JEEB> if your device supports whatever that is in HEVC [17:52:11 CEST] <JEEB> or HEVC at all [17:52:14 CEST] <JEEB> (for encoding) [17:52:17 CEST] <ciga> VAProfileHEVCMain : VAEntrypointVLD [17:52:24 CEST] <JEEB> that might be decoding [17:52:44 CEST] <ciga> i dont have an entry for VAEntrypointEncSlice [17:53:32 CEST] <ciga> so, i guess i need a newer Mesa ... [17:53:33 CEST] <^Neo> JEEB, well, there's av_image_fill_arrays but I'm curious if there's an easy way to just generate like a green field and a red field for testing. [17:53:34 CEST] <JEEB> ^Neo: so you'd have to lace it through with 2*stride [17:53:53 CEST] <^Neo> got it [17:53:57 CEST] <JEEB> there's a helper function to get at least a black AVFrame [17:54:01 CEST] <JEEB> but not sure if there's one for fields [17:54:12 CEST] <^Neo> ah ok, name of the black AVFrame function? [17:54:14 CEST] <JEEB> if you can't find anything relevant in doxy/code then most likely there's not [17:54:24 CEST] <JEEB> don't remember :D it was relatively recently added by wm4 [17:54:39 CEST] <^Neo> oh cool! ok, I'll go digging [17:55:12 CEST] <JEEB> or I guess you could use avfilter for the interleaving? [17:55:33 CEST] <JEEB> since you can generate a red and blue or whatever frames with 1/2 height [17:55:38 CEST] <JEEB> and then call the interleave filter on those? [17:56:01 CEST] <JEEB> although that might be less simple than just filling the fields depending on your needs :D [17:57:48 CEST] <^Neo> a little, heh. Thanks though! [17:58:21 CEST] <Mista_D> relaxed: ./ffprobe -i source1.ts -select_streams v -show_frames -of csv -show_entries frame=pkt_pts_time,pict_type [18:00:11 CEST] <JEEB> unfortunately the caption packets are within the video stream [18:00:18 CEST] <JEEB> so unless ther's an option to specifically not show the caption packets [18:00:29 CEST] <JEEB> then you just need to filter better :P [18:01:51 CEST] <RedSoxFan07> Is FFMPEG's Bob Weaver Deinterlacing Filter the same as Handbrake's Decomb filter with the Bob option? [18:02:33 CEST] <furq> handbrake just uses yadif in send_frame mode [18:02:48 CEST] <furq> i think the decomb filter just runs idet beforehand [18:03:01 CEST] <furq> decomb generally gives bad results in my experience though [18:03:23 CEST] <RedSoxFan07> furq: Oh, okay. What gives the best results? [18:03:43 CEST] <furq> check to see if it's interlaced and then either deinterlace or don't [18:04:10 CEST] <furq> idet will give false negatives on low-motion interlaced frames [18:04:25 CEST] <furq> so you'll end up with intermittent artifacts [18:04:29 CEST] <relaxed> Mista_D: you only want: frame,11,... [18:05:05 CEST] <furq> if you actually have a clip which is half interlaced and half progressive then i would normally break out vapoursynth and start counting frame numbers [18:05:18 CEST] <furq> but you could presumably do it with yadif and enable [18:14:41 CEST] <RedSoxFan07> I've got a lot of videos to convert. I'm going for a solution that doesn't take a ton of time and effort. [18:14:50 CEST] <RedSoxFan07> I don't want to be counting frames or anything like that. [18:15:18 CEST] <RedSoxFan07> I don't mind checking to see whether or not the video is interlaced and acting on that information, but I don't want to take forever. [18:19:27 CEST] <furq> using the log output from idet to detect is usually fine [18:19:54 CEST] <furq> using it to flag frames as interlaced and then conditionally deinterlacing frame-by-frame is more or less what handbrake does [18:20:03 CEST] <furq> which is just a bad idea [18:20:36 CEST] <furq> visually detecting is the best way but obviously you can't automate that [18:21:26 CEST] <furq> this is assuming you don't have any telecine content which you will need to check for manually afaik [18:32:49 CEST] <iive> furq, there are interlace detect filters that does just that, visually detect [18:33:10 CEST] <furq> yeah that's what idet does [18:33:35 CEST] <furq> but it's not perfect [18:35:53 CEST] <Mista_D> http://pastebin.com/hPX9Wmmi side_data junk [18:45:42 CEST] <relaxed> Mista_D: command | awk '/^frame/{sub("side.*","");print}' [18:51:32 CEST] <Mista_D> relaxed: command | sed 's/side_data, ATSC A53 Part 4 Closed Captions//g' [18:54:54 CEST] <iive> furq, it doesn't have to be perfect, just good enough :D [20:36:22 CEST] <russoisraeli> hello folks. I need to test an RTMP (Kaltura) stream. If I use "ffplay" or "vlc" with the "rtsp://" protocol prefix, it works. "rtmp://" does not - returns a "missing argument token" error. Any idea why? [20:36:45 CEST] <JEEB> probably some authentication parameters missing? [20:36:59 CEST] <JEEB> you should know what parameters are required to connect to the RTMP stream [20:38:56 CEST] <russoisraeli> JEEB - right.... but it's just a URL difference.... should rtmp:// and rtsp:// be interchangeable? or is there something else going on? sorry if the question is silly [20:38:58 CEST] <BtbN> rtsp and rtmp are two very different things. [20:39:41 CEST] <russoisraeli> it looks like rtsp:// does something additional [20:39:50 CEST] <BtbN> It's an entire other protocol... [20:40:23 CEST] <russoisraeli> weird... I was give rtmp:// URL's [20:40:31 CEST] <JEEB> russoisraeli: just go read the kaltura documentation and figure out the proper URLs and parameters required to access the RTMP end point [20:40:41 CEST] <JEEB> or ask whomever configured the kaltura you're testing [20:40:45 CEST] <JEEB> we're not kaltura support [20:41:42 CEST] <russoisraeli> JEEB - yeah, I got the rtmp:// URL's from Kaltura.. I understand.. not asking for support. Just trying to figure out why both vlc and ffplay play their URLs as rtsp://, but not the given rtmp:// [20:41:57 CEST] <BtbN> Probably because it's an rtsp url. [20:42:15 CEST] <russoisraeli> probably [20:42:34 CEST] <JEEB> either the URL is incorrect, or it lacks parameters that are usually utilized to keep random people from connecting to the RTMP end point [20:53:33 CEST] <lindylex> How do I change the background color of the video? ffplay -f lavfi 'amovie=a.mp3, asplit [a][out1]; [a] showcqt=s=900x900:count=4:bar_h=800:text=0:cscheme=.74|0|0|.74|0|0 [out0]' [21:31:35 CEST] <lindylex> I am trying to change the background color of this video? ffmpeg -i a.mp3 -filter_complex \ [21:31:35 CEST] <lindylex> "[0:a]showcqt=s=900x900:count=4:bar_h=800:text=0:cscheme=.74|0|0|.74|0|0,format=yuv420p[v]" \ [21:31:35 CEST] <lindylex> -map "[v]" -map 0:a -y o2.mp4; mplayer -loop 0 o2.mp4; [21:31:39 CEST] <lindylex> How do I do this? [21:33:18 CEST] <JEEB> did you look at the docs for the schowcqt filter? [21:33:40 CEST] <JEEB> I'll even give you a hint http://ffmpeg.org/ffmpeg-filters.html [21:34:03 CEST] <JEEB> and of course, if there is no option for the background and you don't see another way to do it - then it's not currently possible [21:53:54 CEST] <lindylex> JEEB I did read it and there is no option. [21:54:25 CEST] <JEEB> well then that's it [22:12:33 CEST] <leif> Can anyone here tell me the difference between passing audio through FFmpeg's highpass filter, then immediately its lowpass filter, compared to just using its bandpass filter? [22:14:06 CEST] <durandal_1707> leif: using just bandpass filter is 2x faster [22:15:05 CEST] <leif> durandal_1707: Ah, okay, thanks. [22:16:05 CEST] <durandal_1707> and you can not get exactly same output... [22:17:05 CEST] <leif> That makes sense. So its like actually using a bandpass filter circuit rather than connecting a low+high pass circuit together. [22:17:11 CEST] <leif> Which would make sense. [22:17:14 CEST] <leif> If so, thanks. :) [22:18:02 CEST] <durandal_1707> biquads are just "special" IIR filters [22:18:18 CEST] <leif> Ah, okay, thanks. [22:18:32 CEST] <durandal_1707> there is math behind all of it [22:19:29 CEST] <leif> Yup. I remember from one of my signal processing classes, I just wanted to see if ffmpeg did anything differently. :) [22:19:42 CEST] <durandal_1707> combining several biquads in cascade one can do all sort of strange filtering.. [23:10:56 CEST] <leif> Okay, here's an odd one, is there any reasn that the lowpass filter might be converting its s16 input into s16p output? [23:18:39 CEST] <none2give> hey everyone. i just have some questions about bundling an ffmpeg executable with my program [23:19:49 CEST] <none2give> i've built the executable myself but bundling the source adds about an extra 100 MB to my program which is undesirable. can i just point to the git repository for the specific version of the code i built from? [23:20:10 CEST] <none2give> the last thing i want to do is end up in the hall of shame lol [23:20:29 CEST] <JEEB> test out how well it compresses with something like 7z (lzma) [23:20:36 CEST] <JEEB> that might make it bearable [23:20:55 CEST] <JEEB> if not, then just have a github/gitlab fork which tags the exact revisions you use [23:22:59 CEST] <none2give> so i can just fork the source and point to that? [23:23:11 CEST] <none2give> my concern is entirely with licensing [23:24:43 CEST] <JEEB> in both LGPL and GPL you are to provide the exact source code of the FFmpeg (and possible dependencies) you used for each binary. so the safest if the archive is not too big is to bundle. otherwise having a link to your own thing with the things tagged exactly should be good enough. [23:25:02 CEST] <JEEB> for GPL that's not limited to FFmpeg or its dependencies [23:25:20 CEST] <none2give> right, i only compiled FFmpeg without any extra codecs or anything [23:25:30 CEST] <none2give> so i think everything is all clear to distribute under LGPL [23:26:57 CEST] <JEEB> the configure step requires you to specifically note if you want version 3 of (L)GPL, or if you want LGPL->GPL [23:27:05 CEST] <JEEB> with --enable-gpl or --enable-version3 [23:27:19 CEST] <JEEB> v3 mostly has things related to DRM [23:27:34 CEST] <JEEB> (because it was created back in the day as a reaction to the tivo boxes) [23:28:27 CEST] <none2give> i didn't use either of those flags [23:29:04 CEST] <JEEB> then FFmpeg itself at least is LGPL. [23:30:14 CEST] <none2give> i also compiled under MinGW32 but i hid all binaries that ffmpeg might be looking to include like bz, iconv etc [23:30:52 CEST] <JEEB> I recommend --disable-autodetect for some of those purposes [23:31:04 CEST] <none2give> ah hell i didn't even know that existed [23:31:08 CEST] <none2give> i just went thru and renamed all of them hahaha [23:31:29 CEST] <JEEB> well, better be sure I guess :P I would have used clear sysroots :D [23:32:19 CEST] <none2give> i'm really new to all of this [23:32:44 CEST] <none2give> i develop primarily on windows and primarily in visual basic and php so makefiles under a linux subsystem is like an entirely other universe [23:34:07 CEST] <none2give> basically the purpose for using FFmpeg in my context is: using PHP to generate an error message which is written onto an image, then FFmpeg encodes a TS segment out of the image and all that gets sent over to a Roku via HLS [23:34:25 CEST] <JEEB> funky [23:34:43 CEST] <none2give> i'm basically writing a server side application to serve up streams via a playlist and spit out error messages if something goes wrong [23:35:08 CEST] <none2give> eliminating the need to develop an app for the TV [23:35:32 CEST] <none2give> and also allowing you to have predefined channels and swap out your streams without touching the TV if one dies or something [23:35:52 CEST] <none2give> it's fairly nifty but encoding a TS stream is vital for the user experience so that's why i'm in this licensing debacle [23:36:02 CEST] <none2give> i'm also bundling apache, php and sqlite so i need to figure that mess out lol [23:36:15 CEST] <JEEB> but wait, if you're making HLS aren't you needing some H.264 encoder? [23:36:23 CEST] <JEEB> or do you have the actual clips pre-encoded and you're just muxing? [23:36:55 CEST] <none2give> you know, i was using h.264 originally but it turns out if i throw a bunch of mpeg2 files into a vod playlist that i'm generating, it plays just fine [23:37:02 CEST] <JEEB> :D [23:37:08 CEST] <JEEB> that said FFmpeg has support for openh264 [23:37:12 CEST] <none2give> since it's all generated dynamically i need quick quick load times [23:37:14 CEST] <JEEB> which has a non-GPL license [23:37:27 CEST] <none2give> mp2 is spitting out smaller files and takes less time to encode [23:37:57 CEST] <none2give> i'm actually cheating and only generating one segment and serving it up for the length of the runtime [23:38:02 CEST] <JEEB> sure, mpeg-2 video is most probably simpler, although not sure if it's faster than some really simplistic H.264 encoder (or with fast settings) [23:38:29 CEST] <none2give> the files i'm generating right now are like 60 kb range [23:38:39 CEST] <none2give> 960x540, 4 seconds long, 1fps [23:38:50 CEST] <none2give> 1k bps [23:38:54 CEST] <JEEB> yea, I mean a message isn't going to be requiring much bit rate at that frame rate [23:39:09 CEST] <none2give> now my biggest question is how do i bring the bitrate even lower than that lol [23:39:30 CEST] <none2give> ffmpeg is telling me i probably didn't mean to set it that low but i definitely did [23:39:47 CEST] <BtbN> If you want low bitrate an ancient codec is probably not the way to go [23:39:48 CEST] <JEEB> not sure how low you can get with MPEG-2 Video [23:40:02 CEST] <none2give> okay, i see [23:40:29 CEST] <none2give> what's the best trade off between quick encoding, small file size, and super low bit rate? [23:40:40 CEST] <JEEB> with HLS you don't have too many alternatives :P [23:40:54 CEST] <BtbN> Probably hevc with a hardware encoder. [23:40:55 CEST] <none2give> so probably h.264 or h.265 or one of the mpegs [23:41:13 CEST] <BtbN> super low bitrate isn't going to happen with them though [23:41:19 CEST] <JEEB> also if you need to squeeze something really really low [23:41:30 CEST] <none2give> i think my biggest priorities then are quick encoding time and small file size [23:41:31 CEST] <JEEB> then doing the error messages realtime doesn't sound like a good idea [23:41:57 CEST] <BtbN> small filesize and quick encoding are pretty much direct opposites [23:42:04 CEST] <JEEB> and just make a single-GOP segment with pretty much all skips [23:42:04 CEST] <none2give> it's just easier too because i can throw a PIN number on screen or something if i need my user to verify their display to their user account [23:42:14 CEST] <BtbN> The smaller you squeeze it the more CPU time it takes to make it happen [23:42:40 CEST] <none2give> that's half the reason i'm generating stuff dynamically, is that there's dynamic content involved [23:43:25 CEST] <none2give> the other reason is that there's so many damn error codes for specific scenarios that i don't want to make them all manually, i can just add it to my switch statement if i need to create one for a specific case [23:43:50 CEST] <none2give> BtbN that does make sense [23:44:18 CEST] <none2give> if they're pretty much inversely proportional then i'm getting only compromise because the wait times between encoding and serving the file will equal out roughly? [23:44:50 CEST] <BtbN> You'll have to experiment to find out how much quality you are willing to give up [23:44:51 CEST] <orev> i need to cut a file precisely on a specific frame. i tried to use the "copy" codec but i don't seem to have keyframes at the right location, so i need to do a re-encode [23:45:16 CEST] <orev> do i need to re-encode audio as well to get the precision? audio is in aac [00:00:00 CEST] --- Thu Oct 4 2018

1 0

ffmpeg-devel.log.20181002
by burek 03 Oct '18

03 Oct '18

[02:31:32 CEST] <Compn> great [10:00:38 CEST] <durandal_1707> michaelni: https://0x0.st/sYVF.avi RASC with MOVE [12:45:57 CEST] <durandal_1707> j-b: do you by any chance need more samples? [13:10:02 CEST] <j-b> I always need more [13:55:34 CEST] <January> how can I dump side data (wasnt there a filter for this?) and/or anyone know of an h264 stream analyser for linux [14:13:09 CEST] <kierank> January: https://sourceforge.net/p/bmxlib/bmx/ci/master/tree/tools/ [14:13:14 CEST] <kierank> you don't need the rest of the stuff in there [14:13:17 CEST] <kierank> just that application [15:10:20 CEST] <durandal_1707> does aomdec have api to get frame without image copy? [15:12:51 CEST] <jamrial> don't think so [15:37:22 CEST] <kierank> January: did the tool work? [15:38:40 CEST] <January> kierank: yes, thanks [16:57:06 CEST] <durandal_1707> j-b: so when to expect other samples or bounty page update? [17:10:05 CEST] <kierank> durandal_1707: same day you turn up at vdd [17:10:08 CEST] <kierank> to request bounty in person [17:12:02 CEST] <durandal_1707> kierank: i have no money to board plane, so i first need to collect bounties [17:12:13 CEST] <kierank> durandal_1707: you can walk [17:13:09 CEST] <durandal_1707> kierank: are you serious? how can i walk that many km's without water and food? [17:13:28 CEST] <kierank> start crowdfunding campaign [17:13:41 CEST] <durandal_1707> like what? [17:13:46 CEST] <kierank> kickstarter [17:14:25 CEST] <durandal_1707> and nobody would give me money, everybody would make jokes about me [17:14:33 CEST] <durandal_1707> like here [17:16:45 CEST] <kierank> durandal_1707: not true [17:16:54 CEST] <kierank> you could have helped write code of conduct [17:22:59 CEST] <durandal_1707> what came up with it? [17:25:04 CEST] <kierank> durandal_1707: have a guess [17:32:58 CEST] <JEEB> durandal_1707: VDD flights are sponsored for developers... and you could have gotten accomodation too [17:33:18 CEST] <durandal_1707> JEEB: upfront? i do not think so [17:33:19 CEST] <JEEB> for active developers they try to make it as simple as possible to join [17:33:34 CEST] <JEEB> if you had a special case you could have had them handle things [17:34:24 CEST] <kierank> durandal_1707: you could have won lego saturn v rocket [17:34:37 CEST] <JEEB> <3 [17:34:43 CEST] <durandal_1707> i do not want to meet in person for making jokes, I just want money, lot of it and fast [17:36:58 CEST] <kierank> durandal_1707: online and twitter for making jokes [17:37:34 CEST] <kierank> durandal_1707: you should come to london for no time to wait [17:38:26 CEST] <durandal_1707> i repeat, i do not have enough money to go to london and go back [17:39:19 CEST] <kierank> durandal_1707: they would sponsor you [17:50:34 CEST] <January> kierank: can I dump the side-data as well with a tool (not external preferably)? [18:00:11 CEST] <kierank> January: well done [18:31:06 CEST] <durandal_1707> should i write new libswscale api using AVFrames? [18:33:26 CEST] <kierank> durandal_1707: rm -rf libswscale [18:33:30 CEST] <kierank> that is best api [18:34:59 CEST] <durandal_1707> /ignore kierank [18:38:32 CEST] <kierank> durandal_1707: noooo don't ingore [18:48:30 CEST] <durandal_1707> kierank: what you use for general colorspace conversion? [18:48:46 CEST] <kierank> swscale sadly but if I had time I'd write my own [18:51:58 CEST] <jamrial> kierank: there's BBB's filter [18:52:26 CEST] <JEEB> for colorspace conversion there's a few alternatives [18:52:47 CEST] <kierank> I do not have complex requirements [18:52:50 CEST] <kierank> just 422 -> 420 [18:52:58 CEST] <kierank> and sometimes some shuffling of bytes [18:53:30 CEST] <jamrial> vf_zscale then? [19:07:48 CEST] <durandal_1707> jamrial: kierank do not use lavfi, it is useless to him [19:15:15 CEST] <philipl> jkqxz: Do you know what mechanisms vaapi supports for sharing with vulkan? dma_buf I assume, but any others? [19:32:53 CEST] <durandal_1707> michaelni: have you got sample? [23:22:25 CEST] <durandal_1707> atomnuker: still very busy? [23:29:29 CEST] <durandal_1707> j-b: so you send me list of codecs to RE for free? noted for next time [23:29:50 CEST] <j-b> durandal_1707: man, you need to calm down. [23:29:59 CEST] <j-b> VDD was less than 10 days ago. [23:30:13 CEST] <j-b> there are multiple parties who have multiple opinions on the bounties [23:30:18 CEST] <j-b> and most have no good samples. [00:00:00 CEST] --- Wed Oct 3 2018

1 0

ffmpeg.log.20181002
by burek 03 Oct '18

03 Oct '18

[03:56:58 CEST] <hendry> just made a screen recording with IOS *with audio* but i can't hear the audio from my Archlinux machine https://media.dev.unee-t.com/2018-10-02/report.mp4 [03:57:29 CEST] <hendry> is a new AAC or something ? Stream #0:2(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 109 kb/s (default) [03:57:53 CEST] <hendry> I can hear the Audio from MacOS. So I am little perplexed. [03:58:00 CEST] <hendry> Running ffmpeg over the file doesn't help [04:13:09 CEST] <fella> Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 2 kb/s (default) [04:13:24 CEST] <fella> 2 kb/s seems a bit low!? [04:19:06 CEST] <fella> did you check that it's the same file on both systems (just to be sure, sry): 1d30f66ca4a3246f0cd1823d5f35368c report.mp4 (md5) [05:21:36 CEST] <hendry> fella: this is the original file from the device https://media.dev.unee-t.com/2018-10-02/reports.mp4 [05:22:12 CEST] <hendry> Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 2 kb/s (default) [05:22:14 CEST] <hendry> Stream #0:2(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 109 kb/s (default) [05:22:38 CEST] <hendry> So there is two audio streams and I am guessing it tries to play back the 2 kb/s one ? [05:26:41 CEST] <hendry> ok, I fixed it with `ffmpeg -i reports.mp4 -map 0:0 -map 0:2 -acodec copy -vcodec copy new_file.mp4` [05:41:45 CEST] <fella> hendry: uhm, that one that you uploaded had one video and one audio stream: https://transfer.sh/EXed1/report.txt [05:42:43 CEST] <hendry> fella: sorry, that one was the ffmpeg treated file. https://media.dev.unee-t.com/2018-10-02/reports.mp4 is the original. [05:45:25 CEST] <fella> kinda funny - mpv seems to pick the wrong audio stream while ffplay chooses the right, yet ffmpeg prolly the wrong one ;) [07:26:48 CEST] <laertus> my hardware mp3 player doesn't seem to like variable-rate mp3's (it won't fast-forward/rewind them properly, and shows the length of the mp3 wrong).. so i need to convert my variable-rate mp3's to fixed-rate mp3's.. so i'm trying "ffmpeg -i input.mp3 -ab 128k -ar 44100 output.mp3" but getting this error: "[mp3 @ 0x55b549f84610] Frame rate very high for a muxer not efficiently supporting it. Please consider [07:26:50 CEST] <laertus> specifying a lower framerate, a different muxer or -vsync 2" and at the end of the encoding it says "[libmp3lame @ 0x55b549f96350] Trying to remove 1152 samples, but the queue is empty" [07:27:01 CEST] <laertus> are these anything to be concerned about? [07:46:08 CEST] <laertus> also, how can i delete any attached images from mp3 files when i re-encode them? [08:56:47 CEST] <laertus> looks like passing the -vn option to ffmpeg made it strip the attached image from the mp3 when it re-encoded it [11:10:17 CEST] <Austin___> hi all, i've got an rtsp stream from an IP camera which i can only have one open connection to. How can I have ffmpeg "rebroadcast" this stream while also writing it to disk? Or is this not possible? [11:12:29 CEST] <furq> -i rtsp://foo -c copy out.mkv -c copy rtsp://bar [11:12:32 CEST] <furq> something like that [11:13:06 CEST] <Austin___> oh, didnt realise I could use multiple -c args [11:13:13 CEST] <Austin___> ta! [11:34:44 CEST] <Yukkuri> hi, i have a general questions regarding chroma subsampling. Is 4:4:4 10profile in any way meaningful? Shouldn't 8bit 4:4:4 cover whole RGB range? [11:35:44 CEST] <BtbN> The point of 10 bit is to have more than 8 bit per color. [11:36:21 CEST] <Yukkuri> yes, but i see that useful only on lesser profiles, such as 4:2:2 or 4:2:0 [11:36:56 CEST] <Yukkuri> where 10bit while requring still less than 4:4:4 8bit could represent more color tones from important to human eye parts of the spectrum [11:37:14 CEST] <Yukkuri> than it's 8bit 4:2:2 or 4:2:0 counterpart [11:37:29 CEST] <BtbN> the subsampling doesn't have anything to do with that. [11:38:02 CEST] <Yukkuri> how is that so? [11:38:34 CEST] <BtbN> It doesn't change how many bits per color is used, but it's about pixel subsampling. [11:40:00 CEST] <Yukkuri> but i though of 4:4:4 as lossless - 8+8+8 (RGB8) or 10+10+10 (RGB10). and of 4:2:2 as a bit lossy -- 8+4+4 or 10+5+5 [11:40:16 CEST] <Yukkuri> while storing less information, it shifts colorpsace to more important parts [11:41:40 CEST] <Yukkuri> so with 10bit 4:2:2 you store 20 bits of color information, per pixel, while wiht 8bit 4:4:2 it is 24 [11:41:51 CEST] <Yukkuri> err [11:41:58 CEST] <Yukkuri> 8bit 4:4:4 [11:43:16 CEST] <Yukkuri> but i'm not sure if RGB10 is of any practical home use, since all drawable surfaces are using RGB(A) to represent colors [11:44:06 CEST] <Yukkuri> however, with lossy 4:2:2 and less profiles, advantage is more clear. not full RGB, but more important color tones. [12:01:08 CEST] <furq> it depends what you mean by meaningful i guess [12:01:26 CEST] <furq> it is distinct in a meaningful way but i don't think anyone actually uses it for anything [12:02:05 CEST] <Mavrik> Not sure why do you think subsampling and color bits are connected [12:02:14 CEST] <Mavrik> Subsampling just uses same color for multiple pixels [12:02:26 CEST] <Mavrik> And 10-bit color means that you can describe a color with greater precision [12:02:43 CEST] <Mavrik> Which is important when you expand your color space - think HDR. [12:02:50 CEST] <Yukkuri> when 4:4:4 subsampling is used, there is no actual "sub" smapling in my understanding [12:02:54 CEST] <Yukkuri> every pixel is sampled [12:05:48 CEST] <Yukkuri> so 10bit 4:4:4 can be used for some rare displays that go beyond RGB range in their pixels? [12:06:35 CEST] <Mavrik> Yes, every pixel is sampled, but there's still a difference if color for that pixel is described with 8 or 10 bits. [12:06:41 CEST] <Mavrik> No idea what do you mean by RGB range. [12:06:54 CEST] <Mavrik> 10-bits just gives you greater precision to desribe the color. [12:07:07 CEST] <Yukkuri> i mean RGB8, as in #FF0000 [12:07:41 CEST] <Yukkuri> i find it hard to draw something on a display with more color varaiance than 256 per component [12:08:19 CEST] <Yukkuri> be it GL surface or some sofware renderer, all they operate RGB8 buffers when dumping data to display [12:08:35 CEST] <Yukkuri> unless it is some special hardware [12:08:45 CEST] <BtbN> 10 or even 12 bit color depth is pretty common [12:08:58 CEST] <Yukkuri> when sampled for every pixel? [12:09:16 CEST] <BtbN> that's still not connected at all to subsampling... [12:10:07 CEST] <Yukkuri> i mean, why having RGB10 for every pixel, when most displays can represent only RGB8? [12:10:22 CEST] <BtbN> Just because your displays don't doesn't mean they don't exist. [12:10:54 CEST] <Mavrik> There's a lot of displays that benefit from more precision [12:11:16 CEST] <Mavrik> And I think you need to read up on what color spaces do. [12:11:25 CEST] <Mavrik> Because RGB8 can mean a lot of things depending on context. [12:11:33 CEST] <Mavrik> #FF0000 isn't the same on all displays and in all color spaces. [12:12:17 CEST] <Mavrik> And yeah, HDR displays are a thing (especially on TVs) and they need those 10 bits in HDR mode. [12:13:05 CEST] <Mavrik> (standardized as BT.2100 for HDR10 if I remember correctly) [12:13:19 CEST] <Yukkuri> i see [12:15:36 CEST] <Yukkuri> but is RGB <-> YUV conversion losless, when both spaces are represented by 8-bit components, or is there no direct mapping due to different orientation and size of this two spaces? also, when color is stored in 3-components 8-bit YUV per pixel, is it more often actual YUV or just RGB using the same space? [12:16:35 CEST] <Yukkuri> *dirrect mapping in said precision, since numerical losses are very likely [12:17:29 CEST] <Yukkuri> *using the same data space (not color space) [12:18:20 CEST] <Mavrik> IIRC there are lossless transforms between RGB <-> YUV [12:18:39 CEST] <Mavrik> But that's a bit out of my area of expertise [12:18:49 CEST] <furq> not with the same bit depth [12:18:52 CEST] <JEEB> YCgCo with +1 bit depth [12:18:55 CEST] <JEEB> IIRC was lossless? [12:19:02 CEST] <JEEB> although I think that was for BT.709/Gamma? [12:19:43 CEST] <JEEB> although it might be unrelated to the colorspaces/etc [12:22:34 CEST] <Yukkuri> also, is it common trick for codecs to store just RGB data in place of YUV data, when number of information is the same to avoid loss? [12:58:27 CEST] <Dexx1_> I just spent the last 4 hours googling trying to figure out how to loop a single MP4 video file X times .... and no luck. I assume you fine folks know how to make such magic happen? [12:59:00 CEST] <Shibe> how can I get a list of encoder options for a codec, say h264_vaapi? [12:59:30 CEST] <JEEB> f.ex. `-h encoder=libx264` [12:59:37 CEST] <JEEB> that lists the AVOptions that module has [12:59:49 CEST] <JEEB> (there are also generic options which are separate) [13:25:41 CEST] <King_DuckZ> hi, I'm looking at this function in our code https://alarmpi.no-ip.org/kamokan/cm?cc which is trying to tell how many frames are in a given input file I think [13:26:31 CEST] <King_DuckZ> I'm getting deprecation warnings on av_stream_get_r_frame_rate and I don't know how to rewrite this for latest ffmpeg [13:27:15 CEST] <King_DuckZ> I can't even find that function in the documentiation for 4.0, there's an entry for 3.4 but it says absolutely nothing [13:39:44 CEST] <relaxed> Dexx1_: there's an example on how to do it here, https://trac.ffmpeg.org/wiki/Concatenate [14:11:58 CEST] <bodqhrohro> I missed the probably main question. Is geq filter GPU-powered? [15:56:01 CEST] <Hello71> in general unless it specifically says it is, it is not [16:04:28 CEST] <King_DuckZ> have I missed any reply while I was offline? [16:04:50 CEST] <King_DuckZ> my question was about a snippet of code I pasted earlier [16:52:04 CEST] <microcolonel> I figured you folks would be likely to know: is there some way with MPEG TS to have a video stream start at some seek point into the underlying stream? [16:52:30 CEST] <microcolonel> i.e. 64 P frames in [16:53:47 CEST] <microcolonel> I have a DASH stream, and I'd like to be able to rapidly produce clip files from already-downloaded parts without reencoding the first part. [16:56:59 CEST] <Mavrik> Why not just drop the packets? [16:57:54 CEST] <microcolonel> (and I'd like accurate seeking at the beginning of the clips) [17:28:21 CEST] <Daisae> I am having difficulty selecting a stream. I have been reading the user documentation. In an AV file with multiple audio streams, the unwanted audio stream is selected. [17:28:33 CEST] <Daisae> ffmpeg/ffprobe shows the audio Stream I want as : Stream #0:2 [17:28:42 CEST] <Daisae> ffmpeg -y -noaccurate_seek -ss 1:00 -i Input.mkv -codec:V copy -codec:a:2 copy -t 1 Output.mkv [17:28:58 CEST] <Daisae> In output: Stream mapping: Stream #0:0 -> #0:0 (copy) Stream #0:1 -> #0:1 (ac3 (native) -> vorbis (libvorbis)) [17:31:03 CEST] <JEEB> you haven't done any mapping, so automagically ffmpeg.c will pick the "best" track for audio and video [17:31:54 CEST] <JEEB> after input, -map 0:v (map all video tracks since most likely just 1), -map 0:a:N where N is starting from zero how many'th audio track it is :P [17:32:06 CEST] <JEEB> since your input seems to be #0 [17:32:14 CEST] <JEEB> (that is why both maps begin with 0 [17:41:21 CEST] <Daisae> Thanks. That solved that problem. [20:29:37 CEST] <ilushka4> hey guys, is there anyone who can help me with ffmpeg-python? [20:50:56 CEST] <poutine> ilushka4, You never know unless you ask, also is it specifically with this library's bindings, or something ffmpeg is doing itself? [20:59:10 CEST] <ilushka4> poutine, hey, here is my code: "https://paste.pound-python.org/show/JjwqE1zgo8pTU9r590hn/" I'm trying to open mms stream but I get an error of "AttributeError: module 'ffmpeg' has no attribute 'input'" [21:00:20 CEST] <poutine> paste is broken ilushka4 [21:01:08 CEST] <ilushka4> https://paste.pound-python.org/show/JjwqE1zgo8pTU9r590hn/ [21:03:23 CEST] <poutine> https://github.com/jiashaokun/ffmpeg [21:03:28 CEST] <poutine> I suggest following the examples there [21:03:36 CEST] <poutine> perhaps using a different library as this one doesn't seem that common [21:04:15 CEST] <poutine> but in that library, the ffmpeg module does not have a "input" method, the ffmpeg module has a stream which when initialized has an input method [21:04:27 CEST] <poutine> see the very last section (I cannot read chinese) [00:00:00 CEST] --- Wed Oct 3 2018

1 0

ffmpeg-devel.log.20181001
by burek 02 Oct '18

02 Oct '18

[09:43:52 CEST] <j-b> 'morning [09:55:08 CEST] <durandal_1707> 'morning [17:06:22 CEST] <durandal_1707> j-b: so what have been used for audio filtering for VDD videos in the end? [17:07:06 CEST] <j-b> no clue. [17:07:15 CEST] <j-b> did not take care about it at all. [17:07:27 CEST] <j-b> I'm still too busy from the aftermath of VDD. [17:17:52 CEST] <Compn> i hope j-b gets some vacation :D [17:19:39 CEST] <j-b> I wish too [17:19:49 CEST] <j-b> Mostly people complain to me :) [18:24:53 CEST] <kierank> durandal_1707: can you fix it [18:24:56 CEST] <kierank> can't hear [18:43:25 CEST] <durandal_1707> kierank: fix what? [18:43:35 CEST] <kierank> background noise in vdd audio [18:46:52 CEST] <durandal_1707> kierank: which video? [19:11:28 CEST] <BtbN> philipl, does that new CUDA SDK enable Vulkan interop with those functions? [19:12:16 CEST] <JEEB> IIRC he got as far as having to pull the image out and then transfer it to another vulkan surface for it to work or so? [19:12:50 CEST] <BtbN> That'd be nice. Vulkan filters for CUDA frames. [19:12:52 CEST] <JEEB> BtbN: probably relevant https://github.com/mpv-player/mpv/pull/6170 [19:13:41 CEST] <atomnuker> BtbN: it apparently requires a gpu memcpy [19:14:04 CEST] <atomnuker> I was going to extend my lavu patches with it but gave up on hearing that [19:14:45 CEST] <BtbN> It's a pretty new API, mapping might still be possible. But I don't have time to look into that until the weekend. [19:22:42 CEST] <atomnuker> apparently philipl went through hell figuring out how the api worked as it wasn't documented or something [19:24:00 CEST] <durandal_1707> kierank: i use mpv Video\ Dev\ Days\ 2018\ -\ HDR\ \&\ placebo-kQ8fxENEGtk.m4a -lavfi-complex "[aid1]afftdn=nr=97:nf=-20:nt=c:bn=24 20 19 19 19 17 13 5 -4 -15 -24 -24 -24 -17 10:om=o,asplit[ao],showspectrum=sc [19:24:15 CEST] <durandal_1707> ale=log:color=magma[vo]" [19:24:19 CEST] <kierank> meh mpv [19:24:28 CEST] <kierank> too l1337 for me [19:24:52 CEST] <durandal_1707> kierank: it is for real time playbakc [19:26:42 CEST] <durandal_1707> best results would be if somone have not cut silence parts, and than i could run sampling noise algo to give me profile of noise [19:27:44 CEST] <durandal_1707> kierank: mpv uses crap^Wlavfi filters [19:53:34 CEST] <cone-655> ffmpeg 03Sigga Regina 07master:dcbd89e0008f: avformat/matroskaenc: reserve free space for metadata on request [20:04:09 CEST] <JEEB> huh, intel just published two new encoders? [20:04:21 CEST] <JEEB> SVT-HEVC and SVT-AV1 [20:04:25 CEST] <JEEB> https://itpeernetwork.intel.com/open-source-visual-cloud/ [20:05:12 CEST] <gnafu> Well, published one and announced the other. I haven't seen code for SVT-AV1 yet. [20:05:28 CEST] <JEEB> yea, I kind of meant "announced" as "published" [20:05:33 CEST] <JEEB> as in, "published info on" [20:05:39 CEST] <gnafu> But yeah, SVT-HEVC is out on GitHub and looks interesting [20:05:40 CEST] <gnafu> . [20:05:52 CEST] <gnafu> JEEB: That makes sense. [20:09:52 CEST] <durandal_1707> is it new separate codec or new codec encoder? [20:10:16 CEST] <JEEB> it's a new encoder [20:10:18 CEST] <gnafu> It's a fast HEVC encoder. [20:10:30 CEST] <gnafu> (And eventually a fast AV1 encoder, I guess.) [20:17:23 CEST] <philipl> BtbN: Yes [20:17:47 CEST] <philipl> https://github.com/mpv-player/mpv/pull/6170 [20:18:01 CEST] <philipl> That's me using it in mpv. But the same basic approach can work for the filters. [20:18:49 CEST] <philipl> As atomnuker says, I currently need an intermediate buffer in Vulkan because I couldn't get copying directly to a VkImage to work (get visual mess that looks like incorrect stride + tiling) [20:19:09 CEST] <philipl> The CUDA docs imply that the memory layout should be fully abstracted, but it's not acting like it and nvidia has no VkImage example. [20:19:22 CEST] <philipl> But for filters it's unclear if you event want to use a VkImage vs a VkBuffer anyway. [20:21:33 CEST] <atomnuker> well, buffers are always linear, so you don't really want to use them [20:24:13 CEST] <philipl> yeah, but it's just the first hop, and your source was presumably linear to begin with anyway. The extra GPU copy is fast enough that it doesn't invalidate the advantages. [20:24:30 CEST] <philipl> Obviously, I'd much rather get the VkImage mapping to work. [20:26:20 CEST] <philipl> I'll keep experimenting with it but it's hard when they don't explain what the constraints are. [20:27:04 CEST] <philipl> For example: Switching the tiling mode of the VkImage changes the visual mess I end up with, but the whole point of using an Array abstraction on the CUDA side is to decouple the memory layout, so it shouldn't make a difference. [20:43:38 CEST] <Compn> ehe [20:43:49 CEST] <Compn> someone emails me about rtmpdump,. there still porn out there to be ripped! [20:44:16 CEST] <durandal_1707> porn is illegal here, stop promoting it or be banned! [20:44:24 CEST] <JEEB> Compn: there still is rtmp stuff [20:44:26 CEST] <Compn> hyc , ksv and svnpenn kind of dissapeared [20:44:37 CEST] <Compn> streaming forum died too :\ [20:45:00 CEST] <Compn> JEEB : do you know of any active rtmpdump repos ? [20:45:20 CEST] <JEEB> nope [20:46:31 CEST] <Compn> its weird working on a project for so long and then it all stops when the technology + software changes :D [20:56:33 CEST] <durandal_1707> j-b: i have samples for you [21:29:05 CEST] <RiCON> Compn: openssl 1.x broke rtmpdump, btw [21:29:34 CEST] <BtbN> 1.x?! [21:29:37 CEST] <BtbN> Or you mean 1.1? [21:29:45 CEST] <JEEB> yea, most likely [21:31:44 CEST] <RiCON> yeah, msys finally upgraded their openssl to 1.1.1 and promptly broke a few packages [21:32:26 CEST] <BtbN> well, rtmpdump / librtmp is pretty dead [21:32:58 CEST] <RiCON> still works with libressl and gnutls, yeah [21:55:08 CEST] <Compn> RiCON : i personally havent seen an rtmp stream in the wild in a long time. i am happy for this. :D [21:55:14 CEST] <Compn> i should probably fix rtmpdump but [21:55:19 CEST] <Compn> theres so many other patches [21:55:27 CEST] <Compn> i wish someone would step up to maintain it [21:56:20 CEST] <Compn> but i'd rather see mplayer maintained than rtmpdump heh [21:56:22 CEST] <BtbN> Well, everytime you watch Twitch, YouTube, FaceBook, ... live, that's rtmp. [21:57:06 CEST] <Compn> ah then its possible i was using ffmpeg rtmp stuff to watch those [21:57:15 CEST] <BtbN> not on the watching side [21:57:17 CEST] <BtbN> but on the ingest side [21:57:32 CEST] <BtbN> rtmp web players died with flash [21:57:56 CEST] <Compn> oh i see [21:58:04 CEST] <BtbN> And librtmp is the most commonly used "ingest client" [21:58:17 CEST] <BtbN> Probably because obs uses it [21:58:18 CEST] <Compn> success! [21:59:02 CEST] <Compn> would you say librtmp is used on the phone apps for livestreaming ? [22:00:25 CEST] <BtbN> I have no clue what they use [22:00:31 CEST] <JEEB> no. if they have RTMP support it's usually some android thing or so [22:00:38 CEST] <JEEB> generally HLS/DASH is used [22:00:47 CEST] <BtbN> Can't ingest with HLS/DASH [22:00:52 CEST] <JEEB> of course not [22:01:06 CEST] <BtbN> So the apps can't use that :D [22:01:09 CEST] <JEEB> or well, actually you can but that's a different story [22:01:28 CEST] <JEEB> but yes, most ingest is RTMP for a whole lot of stuff [22:01:34 CEST] <JEEB> which is unfortunate [22:01:43 CEST] <JEEB> because FLV is not going to get extended by Adobe any more [22:01:48 CEST] <BtbN> Well, there is a distinct lack of alternatives [22:01:51 CEST] <JEEB> yet people have their infrastructure [22:02:12 CEST] <JEEB> BtbN: some things take in fragmented ISOBMFF or MPEG-TS [22:02:32 CEST] <JEEB> and I think akamai got caught using the MPEG-TS one [22:02:43 CEST] <JEEB> because their manifests contained a version number [22:02:48 CEST] <JEEB> and identifier [22:02:50 CEST] <BtbN> Problem with those usually is that they perform a lot worse when under package loss pressure [22:03:07 CEST] <JEEB> why would it be any different from RTMP? [22:03:09 CEST] <JEEB> since it's all TCP [22:03:22 CEST] <BtbN> as horrible as rtmp is, it really does manage to adapt to low bandwidth [22:03:46 CEST] <BtbN> by dropping the "least important" frames first [22:03:55 CEST] <JEEB> isn't that an implementation detail? [22:04:21 CEST] <JEEB> the sender drops non-I frames if there's bandwidth issues [22:04:33 CEST] <BtbN> not really, B before P before I before audio dropping is part of the protocol [22:04:55 CEST] <kierank> an intelligent sender can drop whatever in ts [22:05:06 CEST] <BtbN> With pure mpeg-ts that's kinds hard to do, as the layer that's doing the network sending doesn't usually have that information [22:06:46 CEST] <kierank> yes hence intelligent sender [22:10:58 CEST] <durandal_1707> Compn: you are responsible for mplayer death [22:26:33 CEST] <j-b> durandal_1707: Nice. [22:30:23 CEST] <durandal_1707> can i upload to samples.ffmpeg.org or to videolan ftp server or some other one? [22:33:03 CEST] <j-b> sure [22:33:11 CEST] <j-b> put the mess you have wherever youcan [22:49:07 CEST] <durandal_1707> j-b: AGM2 https://0x0.st/sY9F.agm [22:51:07 CEST] <durandal_1707> j-b: RASC https://0x0.st/sYpi.avi --- ffmpeg already have decoder for it [22:53:42 CEST] <durandal_1707> Compn ^ more samples [00:00:00 CEST] --- Tue Oct 2 2018

1 0

ffmpeg.log.20181001
by burek 02 Oct '18

02 Oct '18

[00:04:38 CEST] <svanheulen> I'm trying to get kmsgrab+vaapi to work and I'm running into some errors, hoping someone can give me some pointers [00:04:48 CEST] <svanheulen> I got x11grab+vaapi to work fine [00:05:14 CEST] <svanheulen> and then I just tried ksmgrab+libx264 and I got this error: https://trac.ffmpeg.org/ticket/7375 [00:05:55 CEST] <svanheulen> then I tried the settings given in the response to that issue and got this error instead: https://pastebin.com/kBDWV0Ds [00:09:27 CEST] <jkqxz> svanheulen: Does it work if you have DRM master? [00:09:54 CEST] <jkqxz> libva has a weird thing where it refuses to work with a non-master fd if it isn't a render node. [00:10:17 CEST] <jkqxz> If that's your problem, you can get around it by creating the device separately on a render node and mapping to that. [00:11:55 CEST] <svanheulen> hmmm, well I don't even know that "DRM master" is so no idea :/ [00:12:23 CEST] <jkqxz> Try running it not in X or Wayland (or similar). [00:14:13 CEST] <svanheulen> ah, do i need X to be down completely? [00:14:36 CEST] <jkqxz> Switching to a different VT with ctrl-alt-fN is sufficient. [00:19:08 CEST] <svanheulen> yeah, that works [00:19:28 CEST] <svanheulen> but then I can't seemed to access X [00:21:24 CEST] <jkqxz> Ok, if that works then that I said is probably your problem. [00:22:03 CEST] <jkqxz> You should be able to work around it using something like "ffmpeg -device /dev/dri/card0 -f kmsgrab -i - -init_hw_device vaapi=v:/dev/dri/renderD128 -filter_hw_device v -vf 'hwmap,hwdownload,format=bgr0' -c:v libx264 out.mp4". [00:23:38 CEST] <svanheulen> awesome! that works :) [00:25:34 CEST] <jkqxz> Does using that route actually gain much? kmsgrab is really meant for cases where you keep everything on the GPU side; once you download to CPU memory it ends up doing something pretty similar to x11grab (though can capture outside X). [00:27:43 CEST] <svanheulen> wont pairing kmsgrab with h264_vaapi do then entire operation on the GPU? I was just trying to get kmsgrab to work at all first, not i need to test it with h264_vaapi [00:27:55 CEST] <svanheulen> *now [00:29:15 CEST] <jkqxz> Yeah, that will. (No download in that case.) [00:34:21 CEST] <svanheulen> and I think I have that working too :) [00:34:50 CEST] <svanheulen> does this look right? "ffmpeg -device /dev/dri/card0 -f kmsgrab -i - -init_hw_device vaapi=v:/dev/dri/renderD128 -filter_hw_device v -vf 'hwmap=direct,scale_vaapi=w=1920:h=1080:format=nv12' -c:v h264_vaapi -bf 0 -profile:v main output.mp4" [00:35:16 CEST] <svanheulen> it recorded so i'm guessing it's doing what i want haha [00:37:01 CEST] <jkqxz> Yeah. You might want to set some size/quality option (bitrate or qp); the default is pretty high fixed quality so it makes large files. [00:37:42 CEST] <svanheulen> ah yeah [00:47:22 CEST] <svanheulen> jkqxz: thanks for all the help :) [02:10:22 CEST] <none2give> hi everyone. i'm trying to compile ffmpeg 4.0.2 under mingw32 on windows 10 x64 in order to get a minimal 32-bit build of ffmpeg. i intend to distribute it under the LGPLv2.1 license as is stated on the website so i want to compile it with all optional external libs stripped as i will be using it to encode/decode mpeg only. [02:10:46 CEST] <none2give> everything is configuring and compiling fine, but i don't think i'm entirely understand how i should be configuring because when i attempt to run what i've built, i get errors for missing external dependencies [02:10:51 CEST] <none2give> (libiconv etc) [02:11:12 CEST] <none2give> i'm assuming there's something glaring i'm missing here so any assistance would be appreciated [02:36:35 CEST] <none2give> it's looking like this might be a mingw32 issue and not an ffmpeg issue so i will direct my question to the appropriate board/channel [10:14:39 CEST] <th3_v0ice> Can ffmpeg handle multiple input files and create one hls stream from it? What I am really interested in is, is it creating multiple hls muxers and then just generates the master file, or is it using one muxer for everything? [10:36:01 CEST] <JEEB> th3_v0ice: yes, ffmpeg.c can handle multiple input files, and if you want to use the master playlist stuff in hlsenc.c then you need to use a single muxer instance [10:37:46 CEST] <th3_v0ice> JEEB: So then the process is just opening an AVFormatContext with multiple video and audio streams and just feeding the data to it? [10:38:48 CEST] <JEEB> which part? [10:38:58 CEST] <JEEB> the muxing? yes, and then you have to define the map [10:39:10 CEST] <JEEB> see the hlsenc muxer docs [10:40:33 CEST] <th3_v0ice> I will be doing this in API, I was just wondering whether or not AVFormatContext and HLS muxer can take multiple video streams. [10:40:41 CEST] <JEEB> yes [10:40:44 CEST] <JEEB> yes they can [10:40:49 CEST] <th3_v0ice> Cool, thanks! [10:40:50 CEST] <JEEB> specifics are hlsenc specific [10:41:03 CEST] <th3_v0ice> Yeah, I am looking at it right now [10:41:45 CEST] <JEEB> if a muxer doesn't take in multiple video/audio streams or video/audio streams at all, generally it herps a derp at you at init. but I've been able to use hlsenc.c for a while and it has its kinks but kind of seemed to work [10:43:02 CEST] <th3_v0ice> Haha, ok. Any particular kink that comes to mind of which I should be aware? [10:51:07 CEST] <JEEB> at least with brief testing re-using tracks in multiple profiles (like having all MPEG-TS profiles having the same default audio track in mux) [10:51:33 CEST] <JEEB> and then multiple languages, for which I have a patch locally that I need to poke out if it's how it's meant to be used [10:52:36 CEST] <JEEB> *multiple audio languages [11:06:25 CEST] <linux> durandal: for voice disguise you advised ffmpeg -i voice.wav -f lavfi -i sine=400 -lavfi amultiply out.wav ,I get "no such filter amultiply ,any idea ?? [16:32:31 CEST] <trashPanda_> Hello, this is a more general video question but if someone could direct me to a source it would be much appreciated. When setting PID's in a mpeg2 TS, are there "correct" id values? [16:34:25 CEST] <JEEB> you have PAT that is hard-coded to some PID value, which then contains the PIDs for the different PMTs for different programs [16:34:39 CEST] <JEEB> and the PMTs then contain the PIDs for the video/audio/whatever within that program [16:35:19 CEST] <JEEB> as long as your PID selections match what PAT and PMT advertise [16:36:03 CEST] <trashPanda_> Is that taken care of behind the scenes as long as I set the correct values in the individual AVStreams? [16:37:28 CEST] <trashPanda_> but I suppose my general question was, are there "colloquial" usage of id's, such as h264 to 0x34 etc. [17:24:20 CEST] <JEEB> trashPanda_: yes, lavf should take care of signaling your pids [17:24:55 CEST] <JEEB> as for the a/v/s stream identifiers those should be set by the muxer according to the spec [17:29:42 CEST] <trashPanda_> thank you [18:46:18 CEST] <lays147> anyone here knows about left parent of mpeg2video? [19:43:56 CEST] <safinaskar> how to keep one frame of any 9? [19:44:35 CEST] <safinaskar> i. e. i have video with frames 0, 1, 2, 3, 4, ... . i want to output video with the following frames: 0, 9, 18, ... [19:45:47 CEST] <ChocolateArmpits> safinaskar, between 0 and 9 there's 9 frames, but between 9 and 18 there are 8 frames. Are you sure the indexes are correct? [19:46:52 CEST] <safinaskar> ChocolateArmpits: i am sure. between 0 and 9 there are 8 frames (not counting 0 and 9 themselves), and between 9 and 18 there are 8 frames, too (not counting 9 and 18 themselves, again) [19:47:08 CEST] <ChocolateArmpits> oh snap [19:47:13 CEST] <ChocolateArmpits> can't count ;-; [19:47:38 CEST] <kepstin> safinaskar: you can either use the select filter with an expression that matches the frames you want to keep, or use the fps filter with a rounding mode that picks the frames you want. [19:47:56 CEST] <safinaskar> kepstin: please, give me example [19:48:13 CEST] <kepstin> there's some examples of the select filter in the docs [19:48:32 CEST] <safinaskar> please give me at least command line for throwing every second frame [19:48:53 CEST] <kepstin> safinaskar: there's an example of keeping 1 out of every 100 frames in the docs, it would be easy to adapt [19:49:26 CEST] <safinaskar> kepstin: where it is? [19:49:34 CEST] <ChocolateArmpits> https://ffmpeg.org/ffmpeg-filters.html#select_002c-aselect [19:49:47 CEST] <ChocolateArmpits> specifically https://ffmpeg.org/ffmpeg-filters.html#toc-Examples-122 [19:51:48 CEST] <safinaskar> ChocolateArmpits: kepstin: thanks [21:04:20 CEST] <GuiToris> hey, vp[8-9]'s -cpu-used is equivalent to h26[4-5]'s -preset? [21:04:44 CEST] <JEEB> libvpx, yes. somewhat. look into libvpx's documentation [21:05:21 CEST] <GuiToris> I've read it through, I just didn't quite understand it [21:05:50 CEST] <ChocolateArmpits> GuiToris, the parameter function depends on the quality parameter used [21:06:04 CEST] <kepstin> but in general, it's an adjustment for speed vs. encoding efficiency tradeoff [21:07:01 CEST] <GuiToris> I thought I gave it a try; ffmpeg -i input -c:v libvpx-vp9 -crf 15 -b:v 0 -deadline best -cpu-used 0 output.webm, well this encoding hasn't finished [21:07:11 CEST] <ChocolateArmpits> cpu-used has no function for -quality best [21:07:30 CEST] <ChocolateArmpits> For -quality good it for the most part regulates both the speed and the accuracy of ratecontrol, e.g. at -cpu-used 4-5 your ratecontrol will be a mess [21:07:57 CEST] <ChocolateArmpits> -quality good -cpu-used 0 is comparable to -quality best but slighty faster [21:08:16 CEST] <kepstin> GuiToris: if you're using -quality best, you're asking for the best quality - speed it up would make it not best, right? ;) [21:08:22 CEST] <GuiToris> 'When the deadline/quality parameter is good or best, values for -cpu-used can be set between 0 and 5.' [21:08:36 CEST] <ChocolateArmpits> for -quality realtime -cpu-used regulates how much of the processor speed should be expended to to render the video at realtime. There's a formula in the documentation for that [21:08:42 CEST] <kepstin> (but that said, best seems to be like x264's placebo, basically not generally useful and doesn't really improve quality) [21:09:14 CEST] <ChocolateArmpits> GuiToris, did you read this document ? https://www.webmproject.org/docs/encoder-parameters/ [21:09:34 CEST] <ChocolateArmpits> Specifically @2. Encode Quality vs. Speed [21:10:16 CEST] <GuiToris> no I didn't, thanks ChocolateArmpits, it looks more detailed [21:10:31 CEST] <ChocolateArmpits> yeah read that, it should clear up all the confusion [21:11:36 CEST] <kepstin> note that google's recommendations for VOD services (youtube-like stuff) say to use -quality good and then two-pass, with -speed 4 on the first pass, and -speed 1 or 2 on the second pass. [21:15:39 CEST] <GuiToris> ChocolateArmpits, hmmm is this statement inaccurate then? 'When the deadline/quality parameter is good or best, values for -cpu-used can be set between 0 and 5.' (source : https://trac.ffmpeg.org/wiki/Encode/VP9 ) According to webmproject.org --best has nothing to do with --cpu-used, just as you mentioned [21:15:45 CEST] <GuiToris> ffmpeg didn't complain though [21:16:15 CEST] <ChocolateArmpits> well it's not ffmpeg documents developing the codec so... [21:19:26 CEST] <GuiToris> oh comes to my mind, I have an error message. When I'd like to save an image from a video I use: ffmpeg -ss 2 -i input -framerate 1 output.png but it says: Could not get frame filename number 2 from pattern 'output.png' either set update or use a pattern like %o3d within the filename pattern, av_interleaved_write_frame(): Invalid argument [21:19:40 CEST] <GuiToris> what should I do differently? [21:19:47 CEST] <GuiToris> I only need one image [21:20:34 CEST] <ChocolateArmpits> GuiToris, there's a -frames parameter to specify how many frames to write to the ouptut [21:20:39 CEST] <ChocolateArmpits> don't use -framerate [21:21:00 CEST] <GuiToris> oh, just frames? My bad :S [21:21:04 CEST] <ChocolateArmpits> besides that's an input option [21:21:38 CEST] <ChocolateArmpits> I sometimes read through ffmpeg commands, there's always something hidden [21:22:48 CEST] <GuiToris> yes, it works well with frames, I messed it up, I must have used -frames but it was a while ago and I've forgotten it since then [21:22:49 CEST] <GuiToris> thank you [21:23:18 CEST] <GuiToris> back to the reading, thank you for your help :) [00:00:00 CEST] --- Tue Oct 2 2018

1 0