October 2018 - Ffmpeg-devel-irc

ffmpeg-devel.log.20181015
by burek 16 Oct '18

16 Oct '18

[00:29:56 CEST] <kierank> nevcairiel: equally a good c programmer shouldn't necessarily be coding crypto [00:30:50 CEST] <nevcairiel> they should team up! [00:43:19 CEST] <philipl> nevcairiel, BtbN: So. What does progress look like on the pix fmt stuff? [00:43:27 CEST] <philipl> I don't even understand what making a decision looks like. [00:44:29 CEST] <BtbN> Me neither, and I really don't like this stalemate kind of situation. [00:50:31 CEST] <jamrial> a vote would solve it, but i don't think enough people care or know about the issue at hand, so the voting could go either way [00:50:46 CEST] <jamrial> who is against and who is in favor of the new pixfmts currently? [00:51:01 CEST] <BtbN> I think only carl is against them... [00:52:51 CEST] <jamrial> well, a vote would probably end in adding the pix fmts winning i guess [00:53:49 CEST] <jamrial> alternatively, since it's like three devs vs one, you could state that if he doesn't have a valid technical argument against it then he can't block it [00:54:11 CEST] <cone-907> ffmpeg 03Marton Balint 07master:f099946fafb8: ffmpeg: log corrupted packets and frames [00:54:15 CEST] <BtbN> Well, there are valid technical arguments against it. But to address them properly is quite a project on its own. [00:57:09 CEST] <JEEB> yea, adding a whole struct for pixel formats and reworking the renegotiation for that can end up "interesting" :P [00:57:30 CEST] <JEEB> you can keep the AV_PIX_FMT things for a while as well, but yea. it requires rework of all API clients as well [01:01:43 CEST] <BtbN> It's just that this is holding up a lot of work... And the alternative to the pixel formats is an enormous mess [01:02:18 CEST] <JEEB> yes [01:21:11 CEST] <philipl> Right. Adding a bit depth attribute later doesn't become harder because we added a couple of new px fmts. That's not the hard part. [01:22:09 CEST] <philipl> And no one is suggesting removing P010 so the argument isn't even consistent. [01:23:25 CEST] <cone-907> ffmpeg 03Michael Niedermayer 07master:c27c7b49dc00: avcodec/av1_parse: Check obu_size [02:50:22 CEST] <philipl> BtbN: If you're feeling generous, would you test an mpv change for me? https://github.com/mpv-player/mpv/pull/6170 [12:45:09 CEST] <January> nevcairiel: `WINAPI_FAMILY` is the windows define I should be using? [12:45:33 CEST] <nevcairiel> #ifdef _WIN32 i guess [12:46:33 CEST] <BtbN> philipl, I'll see if I can build it easily on Windows [12:52:01 CEST] <BtbN> Is that still using a copy, or does it make use of actual mapping now? [12:52:43 CEST] <BtbN> hm, and it's Linux only. I only have Windows machines and headless Linux ones with nvidia. So that makes testing kinda hard. [12:55:37 CEST] <January> wbs: nice on the windres C wrapper, I completely forgot about it [12:57:21 CEST] <wbs> January: I didn't remember that we had talked about converting it to C :P but when testing running things on windows this seemed like the least ugly way to fix it [12:58:12 CEST] <January> wbs: we talked about integrating it directly into LLVM, but a C wrapper is probably just as good [12:58:53 CEST] <wbs> January: ah, right. integrating it into LLVM would probably be nicer, but also requires more generalized policy about how to find includes and the preprocessor and whatnot [16:11:25 CEST] <philipl> BtbN: i can't test windows but the adjustments are pretty small. I could put a patch together but you'd need to be prepared to fix it to actually work. :-) [16:11:45 CEST] <BtbN> Building Vulkan on Windows seems surprisingly annoying [16:16:32 CEST] <JEEB> yea [16:16:39 CEST] <JEEB> I remember trying it and giving up after a while :P [16:51:36 CEST] <jamrial> why not just download the LunarG sdk? [18:00:23 CEST] <BtbN> jamrial, iirc because it expects MSVC [18:00:45 CEST] <jamrial> BtbN: i used it to compile vkquake using mingw gcc [18:01:36 CEST] <JEEB> oh, ok [18:01:39 CEST] <JEEB> that's better than expected then [18:04:59 CEST] <BtbN> Now to figure out how mpvs weird build system does things [18:05:31 CEST] <JEEB> oh waf, the delightful little REDACTED [18:05:42 CEST] <JEEB> it seems really meta to be honest [18:06:07 CEST] <JEEB> but in general with mpv it's all about pkg-config and possibly CFLAGS etc [18:06:08 CEST] <BtbN> I also don't have it installed, and cygwin does not seem to have it. [18:06:10 CEST] <JEEB> it takes in the env vars [18:06:18 CEST] <BtbN> pkg-config for the vulkan sdk? [18:06:31 CEST] <JEEB> for that probably CPPFLAGS/LDFLAGS I guess then? [18:06:38 CEST] <BtbN> doesn't seem to have a .pc file at least [18:06:44 CEST] <JEEB> anyways, waf seems to hate bundling [18:06:54 CEST] <JEEB> so run the bootstrap script with python3 or so [18:07:01 CEST] <JEEB> that downloads a known waf binary and checks the checksum [18:07:15 CEST] <JEEB> even the debian mpv package funnily enough has waf itself as a patch [18:07:31 CEST] <JEEB> even though they noted before they'd be packaging one true version of waf [18:23:58 CEST] <philipl> BtbN: I appreciate your hard work :-) [18:30:46 CEST] <BtbN> now ffmpeg doesn't even build for me targetting mingw... [18:31:08 CEST] <JEEB> reminds me I should update my mingw-w64 headers and CRT [18:34:50 CEST] <BtbN> my mingw compiler seems to be picking up cygwin headers [18:35:41 CEST] <philipl> Your regular ffmpeg build can't be used? [18:43:10 CEST] <BtbN> philipl, no, can't build mpv for cygwin [18:44:05 CEST] <BtbN> so, now, how do I tell it where my Vulkan SDK is? [18:46:12 CEST] <BtbN> seems like I don't. The only thing it does is check for vulkan pkg-config... [18:51:46 CEST] <BtbN> Well, aparently I have to write a pkg-config file [18:52:40 CEST] <philipl> BtbN: Hmm. I guess the linux pc file comes from the distro packaging... [18:54:06 CEST] <BtbN> managed to make it build [18:54:14 CEST] <BtbN> so, how do I test this? [18:57:44 CEST] <BtbN> hm, it crashes on startup [19:02:27 CEST] <philipl> BtbN: well, it's not going to do anything relevant unless i/you implement the win32 sharing. [19:02:42 CEST] <BtbN> well, it starting would be a good first start [19:02:45 CEST] <philipl> But you could start with just proving that hwdec=nvdec does something on windows. [19:02:48 CEST] <philipl> yeah. [19:03:01 CEST] <BtbN> It just crashes with a generic startup error 0x7b [19:04:31 CEST] <cone-148> ffmpeg 03Paul B Mahol 07master:c07bc1d6ee73: avfilter/af_silenceremove: add options to keep min duration of silence [19:04:32 CEST] <cone-148> ffmpeg 03Paul B Mahol 07master:346b23237bdf: avfilter/af_silenceremove: add mode options [19:04:33 CEST] <cone-148> ffmpeg 03Paul B Mahol 07master:a85362368143: avfilter/af_silenceremove: prefer outlink instead of inlink [19:04:34 CEST] <cone-148> ffmpeg 03Paul B Mahol 07master:454ed32d5670: avfilter/af_silenceremove: add options description [19:04:35 CEST] <cone-148> ffmpeg 03Paul B Mahol 07master:631994b62b12: avfilter/af_silenceremove: add enum for detection modes [19:04:36 CEST] <cone-148> ffmpeg 03Paul B Mahol 07master:936376f3f7a8: avfilter/af_silenceremove: use enum for threshold detection modes [19:04:37 CEST] <cone-148> ffmpeg 03Paul B Mahol 07master:e1e6a3121693: doc/filters: update silenceremove documentation [19:10:06 CEST] <BtbN> no idea what's going on, but the binary is entirely useless [19:23:16 CEST] <philipl> oh good. [20:54:19 CEST] <cone-148> ffmpeg 03Aman Gupta 07master:64c50c0e978c: avcodec/cbs_h264: silence errors about end_of_seq nalus [20:54:20 CEST] <cone-148> ffmpeg 03Aman Gupta 07master:b6c3a0274087: avcodec/cbs: fix crash in sei_pic_timestamp [20:54:21 CEST] <cone-148> ffmpeg 03Aman Gupta 07master:41ed2c384993: avcodec/cbs: ensure user_data is padded for GBC parsing [20:59:28 CEST] <JEEB> tmm1: sorry for doing something else than ACK'ing your patches. somehow ended up sidetracked all the while :P [21:04:19 CEST] <tmm1> n/p, i assume no comments means no one objects

1 0

ffmpeg.log.20181015
by burek 16 Oct '18

16 Oct '18

[00:37:04 CEST] <cryptodechange> Here are my mpv screenshots from the tonemap tests [00:37:07 CEST] <cryptodechange> https://imgur.com/a/ifKhhld [00:37:15 CEST] <cryptodechange> Included the 4k and 1080p raw screenshots too [00:38:16 CEST] <cryptodechange> BT709 with no tonemapping is blown out, hable tonemap is too dull [00:38:31 CEST] <cryptodechange> @JEEB @haasn [00:39:26 CEST] <cryptodechange> I'm guessing mpv is doing its own tonemapping (opencl as you mentioned) which looks superior to the ffmpeg tonemapped version [00:39:34 CEST] <cryptodechange> and closer to the raw 1080p version [00:50:50 CEST] <JEEB> cryptodechange: it's just that the 100% cpu-only version hasn't been updated while the intel guy made the opencl filter based on newer stuff in mpv [00:53:56 CEST] <Zexaron> So I kinda slowly started the ffmpeg upgrade for dolphin-emu ... which I talked aroun here a few times, I have all the logs of the stuff so no need to re-explain, just switching the container format was straightforward, MKV ... but it's still with all existing "ticks" implementation code [00:54:31 CEST] <Zexaron> But I though it would be better to go slower and test it out and see how this MKV file looks like underneath [00:55:13 CEST] <Zexaron> I've ran it with ffprobe - are these ffprobe settings deep enough? ffprobe -v debug -show_format -show_streams -analyzeduration 900000000 -probesize 23554432 framedump0.mkv [00:55:58 CEST] <JEEB> umm [00:56:06 CEST] <JEEB> that's a crapload of stuff [00:56:27 CEST] <JEEB> I think at that point something like -show_packets might be more useful, but dunno :P [00:56:35 CEST] <JEEB> also if you want to see matroska-specifics there's mkvinfo [00:56:46 CEST] <Zexaron> I was about to [00:56:55 CEST] <Zexaron> look into toolnix mkv stuff [01:03:47 CEST] <Zexaron> just thought if someone notices anything odd https://gist.github.com/Zexaron/406916ad620e14a20af4e78f3b7e54a6 [01:05:05 CEST] <Zexaron> the video shouldn't show signs of lag, it should be smooth, as if lag never happened in real-time recording [01:07:52 CEST] <Zexaron> Well I'm not actually sure how it's suppose to be, 1. suppose to be right 2. suppose to be in actual existing implementation and 3. in this mkv version [01:09:02 CEST] <Zexaron> I did upload some if anyone wants to check as well, this is just preliminary, I'll be digging into this a lot deeper after later weeks [01:09:29 CEST] <Zexaron> https://mega.nz/#F!ufxmmQKb!DXxB8LxfrIiw8ra6-lmryg [01:25:27 CEST] <Zexaron> JEEB: Actually the inital thing other people pointed why it's not right is because AVI doesn't support VFR, but now I'm figuring out, that technically dumping frames doesn't even have the VFR aspect, there's no time-between-images saved anywhere, you'd have to pick a fixed FPS manually and get a smooth file out, no slowdowns would be visible [01:26:54 CEST] <Zexaron> So if the current implementation doesn't actually do it like this and attempts to go with timecodes to make it like a real video, that may be the fundamental issue, unless they wanted it that way for some reason which I'm figuring out now why ... [01:31:17 CEST] <cryptodechange> @JEEB according to this https://patchwork.ffmpeg.org/patch/9032/ [01:31:32 CEST] <cryptodechange> FFMPEG -init_hw_device vaapi=va:/dev/dri/renderD128 -init_hw_device \ opencl=ocl@va -hwaccel vaapi -hwaccel_device va -hwaccel_output_format \ vaapi -i INPUT -filter_hw_device ocl -filter_complex \ '[0:v]hwmap,tonemap_opencl=t=bt2020:tonemap=linear:format=p010[x1]; \ [x1]hwmap=derive_device=vaapi:reverse=1' -c:v hevc_vaapi -profile 2 OUTPUT [01:31:47 CEST] <cryptodechange> Something to do with tonemapping vaapi codecs [01:32:25 CEST] <JEEB> yea, that basically I think is what intel is trying to make possible with that stuff [01:32:36 CEST] <JEEB> a full vaapi-based flow without taking the images back into RAM :P [01:32:43 CEST] <JEEB> so of course their example is all about that [01:39:22 CEST] <cryptodechange> now to build ffmpeg and figure out how to change the filter chain [02:04:12 CEST] <fahadash> https://www.irccloud.com/pastebin/PTOUQbMi/ [02:04:50 CEST] <fahadash> What does this error mean? I am trying to concat 4 inputs together, They are exact same frame width and height, first and last has audio, the middle 2 does not have any audio [08:36:13 CEST] <haasn> is there any good downloader tool for imgur? [08:36:19 CEST] <haasn> youtube-dl doesn't support image albums :/ [09:09:08 CEST] <Adcock> Is it possible to encode OGV video with VP9 codec? [09:22:30 CEST] <haasn> Adcock: doesn't seem like it [09:22:41 CEST] <haasn> use something like webm instead [09:23:18 CEST] <Adcock> haasn: It has an unusual name. [09:23:34 CEST] <haasn> what do you mean? [09:23:39 CEST] <Adcock> Is it suitable for everyday use? [09:23:49 CEST] <haasn> webm is probably the most widely used container format [09:23:51 CEST] <Adcock> I am talking about webm. [09:24:18 CEST] <haasn> I'd guess either webm or mp4 (both support VP9 btw) [09:24:23 CEST] <Adcock> Oh. [09:25:31 CEST] <haasn> actually I guess the most popular container format is whatever netflix uses internally :p [09:25:44 CEST] <Adcock> :D [09:27:06 CEST] <Adcock> I will try mp4 then. [09:30:00 CEST] <haasn> if you have a choice I would personally use webm [09:30:08 CEST] <haasn> just because it's free whereas mp4 is patent encumbered [09:30:53 CEST] <Adcock> Then how is it open format? [09:30:57 CEST] <nate> webm was mostly a chrome thing, firefox eventually implemented some support but others need a codec installed [09:31:16 CEST] <nate> Adcock: Just because something is patented doesn't mean it's not openly available [09:31:56 CEST] <nate> Adcock: 3/4 of the things you use on a daily basis likely have a patent related to them, just not everyone enforces patents for profit [09:32:11 CEST] <Adcock> Oh [09:32:48 CEST] <nate> But yeah if you're trying to be largely-supportive, MP4 is going to likely be your main focus, as it's support is far more vast (and mostly due to it's ability to handle 'copyright' material) [09:33:30 CEST] <haasn> what browsers handle VP9-in-MP4 but not VP9-in-WebM? [09:34:02 CEST] <haasn> I don't know of anything that bothers to have VP9 support but not WebM [09:34:40 CEST] <Adcock> Okay. [09:34:46 CEST] <Adcock> MKV-VP9? [09:36:49 CEST] <haasn> WebM is a subset of MKV [09:37:16 CEST] <Adcock> What, I just learned! [09:39:43 CEST] <Adcock> Oh. [09:40:07 CEST] <Adcock> Atleast, I like .mkv more than .webm :D [09:40:25 CEST] <Adcock> I just hate that name. [09:41:11 CEST] <haasn> encode as webm and rename to .mkv :D [09:41:40 CEST] <Adcock> :D [09:49:23 CEST] <Adcock> Okay. Thanks guys. I will inform you on results. [09:59:33 CEST] <nate> haasn: VP9 w/ MP4 is exceptionally unusual to see, MP4 in browsers will almost always be H.264 [10:03:18 CEST] <Adcock> https://superuser.com/questions/705579/convert-video-with-vp9-codec-using-f… [10:03:32 CEST] <Adcock> I can't understand the 2 pass thing. [10:03:44 CEST] <Adcock> Can someone explain, please? [10:04:13 CEST] <Adcock> Btw, my vp9/ogg/mp4 is ready. [10:04:26 CEST] <Adcock> The audio quality is similar. [10:04:43 CEST] <Adcock> But video quality lags a bit. [10:04:50 CEST] <Adcock> Here and there. [10:05:14 CEST] <Adcock> Looks like it tried to encode correctly. [10:05:39 CEST] <Adcock> So, some scenes are totally hight resolution. [10:06:07 CEST] <Adcock> But I still want to give mkv/webm and vp9 a try. [10:06:21 CEST] <Adcock> With a second pass. [10:06:32 CEST] <Adcock> But what is a second pass. [10:06:33 CEST] <Adcock> ? [10:07:39 CEST] <haasn> 2 pass encoding splits up the encoding into a data-gathering pass and an encoding pass [10:07:53 CEST] <haasn> (or technically I think it's just two encoding passes) [10:08:03 CEST] <Adcock> Okay. [10:08:29 CEST] <Adcock> But do I use two commands like shown in the link? [10:08:48 CEST] <Adcock> I mean: [10:09:01 CEST] <Adcock> Do I need to do this: [10:09:13 CEST] <Adcock> fmpeg -y -i input.mkv -c:v libvpx-vp9 -b:v 2000k -pass 1 -an -f webm /dev/null [10:09:18 CEST] <Adcock> before doing this : [10:09:30 CEST] <Adcock> fmpeg -i input.mkv -c:v libvpx-vp9 -b:v 2000k -pass 2 -c:a opus -b:a 64k -f webm output.webm [10:09:31 CEST] <Adcock> ? [10:09:37 CEST] <haasn> seems about right I'd guess [10:09:57 CEST] <Adcock> :) [10:11:05 CEST] <Adcock> I will notify you of the results. [10:20:43 CEST] <grosso> hi [10:22:47 CEST] <grosso> i'm trying to stream from ffmpeg to vlc, using mpegts over udp [10:23:14 CEST] <grosso> audio is aac, video is h264... audio works, video don't [10:25:39 CEST] <Adcock> https://pastebin.com/wA5qp8km [10:45:39 CEST] <Adcock> Okay. [10:45:42 CEST] <Adcock> I got it. [10:45:45 CEST] <Adcock> :) [10:57:52 CEST] <pl0q> hello guys, I tried to compress real-time stream via h264_amf and I got next error when I try to decode this: non-existing PPS 0 referenced / decode_slice_header error / no frame! i can't find anything bad in logs (server_log - https://pastebin.com/hSpPY7dc , client_log - https://pastebin.com/cmJqyfB7) But when i switch to default encoder (AV_CODEC_ID_H264) it works well. Could someone tell me, what did I do wrong? [11:08:28 CEST] <th3_v0ice> Can anyone explain how to properly change pixels of the YUV420P AVFrame? I tried changing the pixels with pixels from another AVFrame, but they are not in the right position. Luma component is, but the other two are off, like they need to be divided by 2. [11:11:39 CEST] <Mavrik> Well yes. [11:11:45 CEST] <Mavrik> That's what 420 means :P [11:11:54 CEST] <Mavrik> The chroma components are subsampled and have 1/2 of resolution [11:37:31 CEST] <Zexaron> Anyone familiar if the Cracki guy is still around ? [11:37:39 CEST] <Zexaron> not here right now but in general [11:55:09 CEST] <Zexaron> Anyway, he's the one that took a look into the code, we assumed all wrong that the system is (or has to) creating an actual video, VFR, but it's not, it's only suppose to concat frames, individual images, as they're output, without any timecode/pts information whatsoever, into a manual fixed FPS i presume, but I'm not sure 100% on that (some games are 60, but most are 30, or 25 and 50 for PAL) [11:56:17 CEST] <Zexaron> So he mentioned some kind of "ticks" variable, and well ofcourse it didn't make sense for VFR ... but it's not suppose to be VFR, so that means the code is okay, or it can be improved in the correct direction ? [11:56:31 CEST] <Zexaron> https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/VideoCommon/… [11:56:45 CEST] <Zexaron> and https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/VideoCommon/… [11:58:56 CEST] <Zexaron> Apparently, my understanding is right now, that it's simply dumping frames into one file, as a video, same way you'd be doing offline merge of a bunch of images, with the convenience it does all that in one step, that's quite different than early assumptions [13:57:32 CEST] <illuminated> what does mean volume/max volume mean on the volumedetect audio filter mean? [14:12:41 CEST] <durandal_1707> illuminated: max volume to give to volume filter and not cause clipping [14:14:00 CEST] <illuminated> I assume, then, that's what 'max volume' means. What is 'mean volume'? [14:31:16 CEST] <durandal_1707> illuminated: mean volume of or bins taking in account probably [14:31:26 CEST] <durandal_1707> s/or/all [14:33:05 CEST] <illuminated> I guess it just means the 'average' volume. [16:15:03 CEST] <zivanovicb> Working on transcoding on the fly with nodejs & ffmpeg where file should get uploaded & transcoded at the same time. So far it's cool on local machine where upload is actually fast, but on the remote servers, ffmpeg is so much faster than upload and it simply exits when there is no data coming from pipe. [16:15:06 CEST] <zivanovicb> Any thoughts how to solve this? [16:16:33 CEST] <BtbN> It should just block when reading from stdin if no data is available but the pipe still open [16:19:55 CEST] <zivanovicb> so there is a way i can tell ffmpeg how to deal with a stream? now, only thing i do is: ffmpeg pipe:0 and everything else is handled by ffmpeg itself [16:20:21 CEST] <zivanovicb> not sure what you mean by "block when reading from stdin" [17:27:30 CEST] <grosso> VLC unable to play udp/mpegts/h264 stream [17:34:45 CEST] <cryptodechange> Am I able to pipe mpv's hdr tonemapping into ffmpeg? (sorry I just messaged this question, I disconnected and wasn't sure it was sent) [17:57:25 CEST] <JEEB> cryptodechange: I don't think so since the encoding part of mpv is rather separate from the video rendering part. there's a path from the renderer to a bitmap though since we do screenshots through the renderer [18:00:13 CEST] <cryptodechange> I'm assuming opencl tonemapping requires hardware acceleration (-hwaccel vaapi) [18:00:27 CEST] <JEEB> it shouldn't require vaapi [18:00:28 CEST] <JEEB> at all [18:00:31 CEST] <JEEB> only opencl [18:00:44 CEST] <JEEB> the example posted by the intel dude unsurprisingly has vaapi there [18:00:49 CEST] <cryptodechange> Oh ok - https://patchwork.ffmpeg.org/patch/9032/ [18:00:55 CEST] <cryptodechange> Yeah, I guess he just used it as an example [18:01:01 CEST] <cryptodechange> But does it require intel integrated graphics? [18:01:03 CEST] <JEEB> because what they want is a no-software pipe line [18:01:06 CEST] <JEEB> no, it does not [18:01:09 CEST] <JEEB> it's opencl [18:01:18 CEST] <JEEB> anything that can run opencl (including your CPU) [18:01:22 CEST] <JEEB> can run cpu [18:01:26 CEST] <JEEB> *can run opencl [18:03:24 CEST] <cryptodechange> -filter_hw_device ocl -filter_complex \ '[0:v]hwmap,tonemap_opencl=t=bt2020:tonemap=linear:format=p010[x1]; \ [x1]hwmap=derive_device=vaapi:reverse=1' [18:03:33 CEST] <cryptodechange> Just trying to decipher this [18:03:42 CEST] <JEEB> it takes the video from input 0 [18:03:45 CEST] <JEEB> [0:v] [18:03:53 CEST] <JEEB> then it does hw mapping (whatever that is) [18:04:14 CEST] <JEEB> runs the tonemap, and does a hwmap in reverse into vaapi? [18:04:42 CEST] <JEEB> and then the output is whatever implicit thing there is for video, probably [18:07:18 CEST] <cryptodechange> Aha, so -filter_complex '[0:v]...' is the equivelant to -filter:v:0 [18:08:06 CEST] <cryptodechange> I'll give it a go [18:08:46 CEST] <JEEB> well not really, since I don't think -filter is a thing like that [18:09:03 CEST] <JEEB> but yes, the complex filter chain starts with 0:v as the input [18:09:07 CEST] <cryptodechange> I presume I use 'tonemap_opencl=t=bt2020:tonemap=linear:format=p010' to replace 'zscale=t=linear:npl=100,format=gbrpf32le,zscale=p=bt709,tonemap=tonemap=hable:desat=0' [18:09:38 CEST] <cryptodechange> Actually, what filter does mpv use? [18:09:46 CEST] <cryptodechange> linear, hable, etc [18:10:09 CEST] <JEEB> https://mpv.io/manual/master/#options-tone-mapping [18:10:22 CEST] <JEEB> default is hable as far as I can tell [18:11:17 CEST] <cryptodechange> Yeah looks like it [18:12:20 CEST] <cryptodechange> So to convert bt2020 to bt709 via. tonemap_opencl, 'tonemap_opencl=t=bt709:tonemap=hable:format=p010' [18:12:25 CEST] <cryptodechange> not sure what the format part is [18:12:30 CEST] Action: cryptodechange checks github [18:12:45 CEST] <JEEB> yea, that's not hte format filter but a parameter for the tonemap_opencl filter [18:13:02 CEST] <JEEB> whatever that means. p010 is the format that hw decoders output for 10bit video [18:13:42 CEST] <JEEB> so most likely it has something to do with the input? although you'd really have to look at the help inside the filter code (or if you built with it, I think ffmpeg.c can output it as well) [18:14:11 CEST] <cryptodechange> "format", "output pixel format" [18:14:19 CEST] <JEEB> oh, output [18:14:30 CEST] <cryptodechange> av_log(avctx, AV_LOG_WARNING, "format not set, use default format NV12\n"); [18:14:31 CEST] <JEEB> interesting, so the example also encodes in 10bit [18:14:42 CEST] <JEEB> lol, nv12 as default. makes sense for HW [18:14:52 CEST] <JEEB> but most of the software stack takes in yuv420p [18:14:58 CEST] <JEEB> or other fully planar formats [18:15:11 CEST] <JEEB> (depending on the usage NV12 can be useful though, x264 for example internally takes in NV12) [18:15:16 CEST] <cryptodechange> hm, the only options are apparently p010 or nv12 [18:15:17 CEST] <cryptodechange> av_log(avctx, AV_LOG_ERROR, "unsupported output format," "only p010/nv12 supported now\n"); [18:15:22 CEST] <JEEB> ok [18:15:27 CEST] <JEEB> then it's just those two [18:15:37 CEST] <JEEB> nv12 at least has unpacking to yuv420p [18:15:44 CEST] <JEEB> p010... also, maybe? [18:18:23 CEST] <Mavrik> Why does HW love their nv12 so much? [18:22:38 CEST] <cryptodechange> tonemap_opencl todo list, according to the comments [18:22:41 CEST] <cryptodechange> separate peak-detection from tone-mapping kernel to solve one-frame-delay issue, import colorspace matrix generation from vf_colorspace.c, more format support [18:24:58 CEST] <JEEB> Mavrik: the packing of the chroma planes seems to help with some stuff [18:25:09 CEST] <JEEB> also that's the reason why x264 went internally NV12 [18:25:27 CEST] <JEEB> as it helped with just CPU stuff as well specifically in case with x264 [18:25:36 CEST] <JEEB> (so if you feed x264 planar stuff it will internally pack the stuff) [18:36:05 CEST] <cryptodechange> tonemap_opencl is just part of libavfilter right? nothing special I need to enable from master? [18:36:50 CEST] <durandal_1707> cryptodechange: opencl support compiled in [18:39:26 CEST] <cryptodechange> [AVFilterGraph @ 0x5a3c940] No such filter: 'tonemap_opencl' [18:48:19 CEST] <Mortir> Hi [18:48:49 CEST] <Mortir> Could somebody clarify to me what's the difference between these two commands: https://privatebin.net/?bb7647b8856ee60b#Bugq4J7Oys6fcDnYhgAIjkmbsGhQ8HEtOv… [18:49:32 CEST] <Mortir> I've already used them and obtained apparent equivalent results. [19:08:01 CEST] <Hello71> is this one of them ridiculous javascript pastebins [19:13:19 CEST] <cryptodechange> btw I tried using today's git static build from johnvansickle.com [19:15:06 CEST] <cryptodechange> https://johnvansickle.com/ffmpeg/ [19:15:08 CEST] <furq> Mortir: there is no difference [19:19:22 CEST] <relaxed> cryptodechange: my builds lack opencl support [19:22:13 CEST] <cryptodechange> relaxed, do you have time to compile a git build with opencl? I'll be sure to drop a BTC donation [19:24:00 CEST] <Mortir> furq: Understood, thanks. [19:32:46 CEST] <Mortir> Hello71: It does uses javascript, but is mainly built with PHP as far as I know. [20:38:00 CEST] <Adcock> FFMPEG -i %INPUT% -acodec libvorbis output.ogg [20:38:14 CEST] <Adcock> This creates a file with theora. [20:38:25 CEST] <Adcock> But input is an audio flac file. [20:38:58 CEST] <Adcock> Stream 0 contains theora. [20:39:03 CEST] <Adcock> Please help. [20:44:39 CEST] <furq> Adcock: -vn [20:44:52 CEST] <Adcock> Oh. [20:45:24 CEST] <furq> cover art is treated as video by ffmpeg, which works great if it's a format that doesn't also support video [20:46:14 CEST] <Adcock> Hmmm. [20:46:21 CEST] <Adcock> :D [20:47:26 CEST] <JEEB> I think there was an option to not take in cover art into mention [20:47:37 CEST] <JEEB> cover art handling is kind of unfortunate in FFmpeg at the moment [20:56:54 CEST] <Adcock> JEEB: Thanks. Things are normal now. [20:56:56 CEST] <Adcock> :) [20:59:01 CEST] <Adcock> Opps. [20:59:09 CEST] <Adcock> Need help again. [20:59:32 CEST] <Adcock> Ogg chooses its bitrate on its own. [20:59:45 CEST] <Adcock> It uses vbr I think. [20:59:56 CEST] <Adcock> FFMPEG -i %INPUT% -acodec libvorbis -vn -q:a 10 -ar 22050 output.ogg [21:00:39 CEST] <Adcock> But opus needs a bitrate to be defined. [21:00:43 CEST] <Adcock> Why? [21:00:46 CEST] <Adcock> FFMPEG -i %INPUT% -acodec libopus -vn -vbr on -compression_level 10 output.opus [21:00:54 CEST] <kepstin> because they're different codecs that take different options [21:00:58 CEST] <furq> pretty much that [21:01:14 CEST] <furq> they both use a similar vbr system iirc [21:01:25 CEST] <furq> just vorbis has -q mapped to nominal bitrates and opus uses the nominal bitrates directly [21:01:28 CEST] <furq> which honestly makes more sense [21:01:37 CEST] <Adcock> When vbr is on why would it ask me for bitrate? [21:01:41 CEST] <kepstin> the "-q:a 10" option basically just picks a vbr bitrate automatically depending on channel count, sample rate, etc. [21:01:45 CEST] <furq> because vbr has a nominal bitrate [21:01:46 CEST] <kepstin> in libvorbis [21:02:03 CEST] <furq> or a target bitrate in other codecs [21:02:03 CEST] <kepstin> but opus doesn't have a preset system like that, so you have to specify a bitrate directly. [21:02:16 CEST] <furq> it's basically still the same thing [21:02:16 CEST] <Adcock> Anything like that for opus? [21:03:05 CEST] <furq> https://wiki.hydrogenaud.io/index.php?title=Recommended_Ogg_Vorbis#Recommen… [21:03:09 CEST] <Adcock> I just want it to auto detect like vorbis. [21:03:12 CEST] <Adcock> Can that be doen? [21:03:15 CEST] <furq> vorbis doesn't autodetect [21:03:31 CEST] <furq> -q 10 is basically the same as using -b:a 500k with opus [21:03:38 CEST] <kepstin> when you specify the -q option for libvorbis, it looks up a target bitrate in a table, basically [21:03:42 CEST] <furq> right [21:03:47 CEST] <furq> the table is in the thing i just linked [21:04:05 CEST] <kepstin> (although i think it handles multichannel stuff, so it'll pick a different rate automatically for e.g. stereo vs mono) [21:04:27 CEST] <kepstin> that would be nice to have in libopus imo, but nobody's implemented it, so... it is what it is. [21:05:14 CEST] <furq> also i don't think it's a target bitrate in either case, it's a nominal bitrate [21:05:33 CEST] <furq> they encoded a test corpus with those settings and it came out at 128k, so these are the 128k settings [21:05:44 CEST] <kepstin> ah, yeah. [21:05:46 CEST] <furq> it won't actually attempt to hit 128k on your particular sample [21:06:16 CEST] <kepstin> both codecs also have a abr mode that'll actually attempt to maintain a target bitrate. [21:06:18 CEST] <furq> right [21:06:22 CEST] <furq> and opus has a cbr mode iirc [21:06:33 CEST] <furq> but the default ratecontrol is basically the same as vorbis -q [21:07:00 CEST] <furq> except you don't have to remember what all the -q settings correspond to [21:07:14 CEST] <furq> also it's worth mentioning that -q 10 is insane overkill [21:07:44 CEST] <furq> 6 should be pretty much transparent [21:07:45 CEST] <kepstin> you're usually better off using flac if you're considering -q 10, yeah :) [21:10:42 CEST] <Adcock> What would -q 6 mean for opus? [21:11:13 CEST] <Adcock> -b:a 220000? [21:11:21 CEST] <furq> -b:a 192k [21:11:49 CEST] <furq> i'd probably go even lower than that for opus [21:12:17 CEST] <Adcock> FFMPEG -i %INPUT% -acodec libopus -vn -b:a 192k -ar 22050 -vbr on -compression_level 10 output.opus [21:12:24 CEST] <kepstin> yeah, opus will generally sound better at the same bitrate as vorbis. [21:12:25 CEST] <Adcock> not supported? [21:12:27 CEST] <furq> you don't need -vbr on [21:12:34 CEST] <kepstin> Adcock: also, why are you downsampling to 22kHz? [21:12:35 CEST] <furq> and also opus doesn't support 22.05k [21:12:45 CEST] <furq> only multiples of 8k [21:13:06 CEST] <furq> and yeah you definitely don't need 192kbps for 22.05k [21:13:12 CEST] <furq> (or 24k) [21:13:19 CEST] <Adcock> Humans cant only hear upto 20KHz on average. [21:13:39 CEST] <Adcock> Maybe 22KHz. [21:13:47 CEST] <Adcock> More than that is just over kill. [21:13:55 CEST] <kepstin> Adcock: you need >40KHz sampling rate to reproduce 20KHz audio [21:13:57 CEST] <Adcock> Loss of space. [21:14:00 CEST] <furq> what he said [21:14:36 CEST] <furq> the actual audible frequency of pcm is half the sampling rate [21:14:40 CEST] <furq> highest [21:14:52 CEST] <furq> https://en.wikipedia.org/wiki/Nyquist_frequency [21:16:56 CEST] <Adcock> Oh. [21:17:28 CEST] <Adcock> So it means I give in 40K but I actually get 20K [21:17:30 CEST] <Adcock> ? [21:17:30 CEST] <kepstin> Adcock: anyways, nyquist/shannon sampling theorem explains why sampling rates like 44.1KHz or 48KHz are typically used - it's enough to reproduce up to 20KHz audio accurately, plus some headroom for audio filters to use. [21:18:00 CEST] <Adcock> Wait. [21:18:05 CEST] <kepstin> you specify the sampling rate with the -ar option. Any given sampling rate can reproduce frequencies up to 1/2 the sampling rate. [21:18:30 CEST] <Adcock> It has got nothing to do with hearing directly. [21:18:59 CEST] <Adcock> So what you mean is 20K will reprodude only 10K or lower but not 15K? [21:19:04 CEST] <furq> yes [21:19:15 CEST] <Adcock> Hmmm. [21:19:52 CEST] <Adcock> That still doesn't make sense why I should not make 22k audios? [21:20:01 CEST] <furq> because it'll cut off everything above 11khz [21:20:17 CEST] <Adcock> What? [21:20:44 CEST] <kepstin> a 22KHz sampling rate can reproduce frequencies up to 11KHz. [21:20:57 CEST] <kepstin> people can hear frequencies up to around 20KHz normally. [21:21:02 CEST] <Adcock> Even when decoding? [21:21:34 CEST] <furq> when else would it be reproducing it [21:21:46 CEST] <kepstin> decoding/encoding has nothing to do with it, this is a mathematical property of how discrete sampling works. [21:22:34 CEST] <Adcock> Hmmm..... [21:22:56 CEST] <Adcock> So I should always use 40K or higher, I guess. [21:23:05 CEST] <Adcock> This only means bigger sizes. [21:23:18 CEST] <Adcock> Thanks guyz. [21:23:25 CEST] <kepstin> no reason to use anything higher than 44.1KHz or 48KHz tho [21:23:25 CEST] <Adcock> I didn't know that. [21:23:27 CEST] <furq> well you were using 500kbps vorbis anyway [21:23:44 CEST] <furq> which is at least twice as big as it would need to be for 48khz [21:24:08 CEST] <kepstin> yeah. Use a higher sample rate, and lower encoding bitrate, and you'll have files the same size or smaller which sound better. [21:24:15 CEST] <Adcock> So thats why I didn't feel any lags? [21:25:08 CEST] <Adcock> SO I WAS A AUDIO HACKER / AUDIO THIEF? [21:25:10 CEST] <Adcock> :d [21:25:16 CEST] <kepstin> reducing the sampling rate to 22KHz (cutting off frequencies above 11KHz) will give most music a kind of "muddy" low fidelity sound. [21:25:41 CEST] <Adcock> Oh. [21:25:50 CEST] <Adcock> Again. [21:26:22 CEST] <Adcock> So what would be the correct way? [21:27:39 CEST] <kepstin> there's no single "correct" way, but using a sample rate or 44.1KHz or 48KHz and a libvorbis "-q:a" setting around 6 or a libopus bitrate around 128-160kbps is generally good for most stereo music. [21:28:01 CEST] <Adcock> :) [21:28:10 CEST] <Adcock> Thank you. [21:28:12 CEST] <kepstin> I'm probably specifying a libopus bitrate a bit higher than you need, tbh [21:29:11 CEST] <Adcock> FFMPEG -i %INPUT% -acodec libopus -vn -b:a 128k -ar 48000 -vbr on -compression_level 10 output.opus [21:29:18 CEST] <Adcock> I just did this. [21:29:28 CEST] <Adcock> VLC Won't show bitrate. [21:29:30 CEST] <Adcock> Why? [21:29:42 CEST] <kepstin> i dunno, vlc bug? [21:29:47 CEST] <Adcock> :D [21:29:57 CEST] <furq> that's generally a safe answer [21:31:14 CEST] <kepstin> note that "-compression_level" option defaults to 10 on libopus, no reason to specify it. [21:32:00 CEST] <furq> same with -vbr on [21:32:29 CEST] <Adcock> 10 means best compression, right? [21:33:22 CEST] <furq> yeah [21:33:34 CEST] <kepstin> Adcock: options are documented at https://www.ffmpeg.org/ffmpeg-codecs.html#libopus-1 [21:35:02 CEST] <Adcock> I knew. [21:35:26 CEST] <Adcock> But when an expert says something, I get confused. [21:35:30 CEST] <Adcock> :( [21:36:09 CEST] <Adcock> Anyway, ffmpeg can tell who uses what bitrate. [21:36:18 CEST] <Adcock> That I guess will do. [21:36:24 CEST] <Adcock> :) [21:36:45 CEST] <furq> i take it from %INPUT% that you're on windows [21:36:51 CEST] <furq> in which case fb2k will tell you the bitrate [21:37:48 CEST] <Adcock> Why? [21:38:04 CEST] <Adcock> Wouldn't it tell me on linux? [21:38:12 CEST] <furq> no because it's windows-only [21:38:25 CEST] <furq> i guess it could tell you in wine but there are easier ways to do it then [21:39:04 CEST] <Adcock> Seriously. [21:39:17 CEST] <Adcock> Why, oh why devs would do that? [21:40:26 CEST] <furq> it's been around since 2002 [21:40:34 CEST] <furq> idk if wx or qt or anything like that even existed then [21:44:31 CEST] <Adcock> At last, it seems ogg vorbis make files smaller that Opus. [21:46:21 CEST] <kepstin> you can make the opus files smaller, just choose a lower bitrate... [21:46:34 CEST] <kepstin> size is something you control [21:46:41 CEST] <Adcock> Quality? [21:47:32 CEST] <kepstin> in almost all cases, an opus file will sound better than a vorbis file at the same bitrate (the lower the bitrate, the bigger the difference) [21:48:00 CEST] <kepstin> so for the same quality, you can normally use a lower bitrate for opus than you used for vorbis. [21:48:07 CEST] <kepstin> (aka lower file size) [21:48:51 CEST] <Adcock> Opus defaults to 96k for bitrate. [21:49:03 CEST] <Adcock> What do you think about it? [21:49:20 CEST] <kepstin> that's probably a fairly reasonable bitrate for stereo music. [21:49:31 CEST] <furq> http://listening-test.coresv.net/s/scores_by_tracks_en.png [21:49:33 CEST] <furq> you tell me [22:54:59 CEST] <Zexaron> hey furq do you remember when I talked about the ffmpeg integration with dolphin, the AVI stuff [22:55:17 CEST] <Zexaron> not sure if you seen my msgs yesterday, but that talk was like early summer [22:56:02 CEST] <Zexaron> It turns out that it's not using VFR ... nor an image slideshow with a fixed framerate [22:58:38 CEST] <Zexaron> but some kind of emulated wall time [23:00:31 CEST] <Zexaron> is this anywhere familiar to you guys [00:00:00 CEST] --- Tue Oct 16 2018

1 0

ffmpeg-devel.log.20181014
by burek 15 Oct '18

15 Oct '18

[00:10:19 CEST] <nevcairiel> i didnt really follow the internal design that much [00:18:08 CEST] <BtbN> I mean just the > vs. >= check of the buffer [02:37:10 CEST] <philipl> BtbN: makes sense to me. Did you run into an actual problem? [10:23:47 CEST] <BtbN> philipl, someone sent me this: https://bpaste.net/show/dea41479ae2b [10:24:35 CEST] <BtbN> Aparently because there is _some issue_ when deinterlacing and seeking/flushing. I wasn't able to reproduce it, but the logic in is_buffer_full did seem a bit flawed to me, and it makes more sense to adjust there than making the queues larger than advertised [10:26:25 CEST] <BtbN> " [10:26:26 CEST] <BtbN> Unfortunatly FFMEG has a bug with deinterlacing cuda frames. So you have to patch the file in libavcodec/cuviddec.c [10:26:26 CEST] <BtbN> Somewhere near line 360 depending on your release: old: ctx->frame_queue = av_fifo_alloc(ctx->nb_surfaces * sizeof(CuvidParsedFrame)); [10:26:26 CEST] <BtbN> new: ctx->frame_queue = av_fifo_alloc((ctx->nb_surfaces + 2 ) * sizeof(CuvidParsedFrame)); [10:26:26 CEST] <BtbN> " [10:26:34 CEST] <BtbN> great copy&paste... [10:27:24 CEST] <BtbN> Also nice that nobody ever filed a bug or anything about this in what seems to be over a year [14:18:25 CEST] <cone-775> ffmpeg 03Michael Niedermayer 07master:fa7289e718e4: fate: Update checksums for recent mxf changes [14:20:08 CEST] <cone-775> ffmpeg 03Paul B Mahol 07master:40c4b9dad0f8: avcodec/imm4: improve decoding of some files [16:29:06 CEST] <philipl> BtbN: ok. change looks fine. [16:29:26 CEST] <BtbN> I'd like them to test it, but they don't seem to react to my mail [17:49:04 CEST] <JEEB> jamrial: I think the difference between HEVC in FLV and AVC/HEVC in IVF is that the latter was actually "used" by upstream, albeit in a manner that's internal only. so while they're different I do agree with the point. Maybe it's just simpler to say no :P [17:49:39 CEST] <JEEB> simpler to have a muxer that takes it in but then gives a fat warning that this will only work with Google's internal systems [17:52:25 CEST] <nevcairiel> also IVF has a proper fourcc [17:52:32 CEST] <nevcairiel> so it really doesnt matter much [17:52:44 CEST] <nevcairiel> FLV has a numeric index, that absolutely needs specification or it never works [17:53:37 CEST] <JEEB> "*simpler than... " for the latter sentence [18:12:53 CEST] <cone-545> ffmpeg 03Timo Rothenpieler 07master:19546cfef103: avcodec/cuviddec: properly take deinterlacing and display delay into account for buffer_full check [18:20:14 CEST] <cone-545> ffmpeg 03Timo Rothenpieler 07release/4.0:7b23dd0f41bc: avcodec/cuviddec: properly take deinterlacing and display delay into account for buffer_full check [18:28:40 CEST] <cone-545> ffmpeg 03Timo Rothenpieler 07release/3.4:e225db5d758c: avcodec/cuviddec: properly take deinterlacing and display delay into account for buffer_full check [18:41:04 CEST] <cone-545> ffmpeg 03Timo Rothenpieler 07release/3.3:5c98f8d80a50: avcodec/cuviddec: properly take deinterlacing and display delay into account for buffer_full check [23:44:16 CEST] <atomnuker> "Tink is a crypto library written by a group of cryptographers and security engineers at Google." [23:44:33 CEST] <atomnuker> a certificate of quality [23:55:15 CEST] <nevcairiel> for its security certainly, but those people usually cant code for shit :P [00:00:00 CEST] --- Mon Oct 15 2018

1 0

ffmpeg.log.20181014
by burek 15 Oct '18

15 Oct '18

[00:02:12 CEST] <JEEB> seems so, picked probably by whomever made the FFmpeg filter [00:02:21 CEST] <JEEB> seems like the zimg author benchmarked lanczos [00:05:17 CEST] <furq> is zscale lanczos markedly better than swscale lanczos [00:08:33 CEST] <JEEB> furq: also I think zimg does gamma-correct scaling although don't count me 100% on that [00:08:45 CEST] <JEEB> while swscale (which scale uses) completely forgets about that [00:22:51 CEST] <cryptodechange> So lanczos should be considered to have better results than bicubic/bilinear? [01:16:11 CEST] <illuminated> so I have a couple quad core xeons in this server. I would like to convert some x265 encoded videos to x264. Is there a way to make ffmpeg to just hammer the cpu cores and provide a quick, high quality conversion? [01:19:36 CEST] <furq> x264 doesn't really play nice with numa iirc [01:19:57 CEST] <furq> aside from that any settings should scale to all the cores you have [01:20:02 CEST] <furq> so you probably just want to run two at once [01:24:06 CEST] <illuminated> hmm...k. I need to figure out how to alter my script to initialize 2 jobs at once, then. [01:28:43 CEST] <furq> for f; do ffmpeg &; ffmpeg &; wait; done [01:31:09 CEST] <illuminated> http://termbin.com/nheg [01:31:13 CEST] <illuminated> my current script [01:42:16 CEST] <illuminated> guess I could do a ((var++)) expression and an if statement. if [[ var -ne 2 ]]; then ffmpeg $filename &; else var=0; wait; fi [01:42:19 CEST] <illuminated> or something like that [01:51:21 CEST] <Hello71> !check [[ var -ne 2 ]] [01:51:33 CEST] <Hello71> oh this isn't #bash lol [01:53:14 CEST] <Hello71> parallelism doesn't work like that [01:53:23 CEST] <Hello71> neither wait nor variables work like that [01:54:22 CEST] <illuminated> ok, that's fine. I'm still learning bash [01:55:03 CEST] <illuminated> if you would, though, explain why those things won't do what I want. You should be able to infer what I'm 'wanting' to do. [01:55:13 CEST] <illuminated> I'm not being an ass or anything. I just want to learn. [02:03:53 CEST] <Hello71> you can try gnu parallel or xargs -P [02:04:21 CEST] <Hello71> make sure you redirect ffmpeg input from /dev/null [02:04:32 CEST] <Hello71> otherwise it might eat your input files [02:04:37 CEST] <Hello71> ask #bash [02:14:53 CEST] <illuminated> ok... [02:14:53 CEST] <illuminated> ok cool [02:16:49 CEST] <illuminated> I'm copying some source files first, adding those lines I mentioned to my script, and I plan to run it and see what happens. part of learning is watching things fail, and then figuring out 'why' they acted in the manner they did when they failed. so, presently, I want to see what this is going to do. [02:46:35 CEST] <illuminated> hmmm... well it seemed to have worked [02:49:43 CEST] <illuminated> it did 1&2, skipped 3, and did 4&5. Waiting till 4&5 finish to see if it skips 6 and goes to 7&8. [02:49:56 CEST] <illuminated> have to see what happens [02:52:53 CEST] <illuminated> but on this test box.. it seems both vids render at about half the fps that a single vid renders at. So, running 2 instances at a time doesn't seem to be gaining me anything. [02:59:36 CEST] <illuminated> still.. kinda interested to see what is going to happen, though. So, I'm letting this thing go [03:05:54 CEST] <illuminated> ahhh... I get why it skipped 3. It's going to skip 6 as well, and I understand why. [04:54:11 CEST] <cryptodechange> Attempted a short test on my 4K HDR to UHD SDR conversion [04:54:12 CEST] <cryptodechange> https://imgur.com/a/jQVrMGN [04:54:23 CEST] <cryptodechange> Colours seem really washed out, not sure what went wrong in the filter settings [04:55:49 CEST] <ariyasu> frame size is 1920x1080 :| [04:55:55 CEST] <ariyasu> also uncropped [04:56:02 CEST] <ariyasu> but what were your filter settings? [04:56:23 CEST] <ariyasu> oh i see [04:56:26 CEST] <cryptodechange> Included them in the description [04:56:30 CEST] <cryptodechange> Haven't applied a crop yet [04:56:33 CEST] <ariyasu> yeah im blind [04:56:42 CEST] <cryptodechange> :D [04:57:19 CEST] <cryptodechange> I tried bundling in the downsize when it sets the tonemap to bt709 [04:57:49 CEST] <cryptodechange> I'll try apply the downsize after format=yuv420p [05:01:11 CEST] <cryptodechange> Following along the lines of this [05:01:14 CEST] <cryptodechange> https://stevens.li/guides/video/converting-hdr-to-sdr-with-ffmpeg/ [05:33:51 CEST] <cryptodechange> Because it's also converting from x265 to x264, could it be doing that -before- applying the tonemap? [05:36:58 CEST] <cryptodechange> hm, removing the following makes the issues go away: zscale=t=linear:npl=100,format=gbrpf32le, zscale=p=bt709,tonemap=tonemap=hable:desat=0, [06:13:51 CEST] <illuminated> I can't believe how much better the compression for x265 is. Have a 20 minute 1080p x265. Re-encoded it to x264 with a CRF of 23 which, I think, pretty much kept the same bitrate as the source, and the output file was nearly 4 times larger than the input [06:15:52 CEST] <illuminated> increased crf from 23 to 29. Resulted in a 200 MB decrease in file size. Now trying a crf of 35. I'll see if the quality is acceptable. I just want decent quality in a decent file size [06:16:47 CEST] <illuminated> at a crf of 35 the bitrate has been a little more than halved. So, I reckon we shall see how this turns out. [06:24:20 CEST] <illuminated> wow, that quality was terrible [06:29:37 CEST] <illuminated> according to the x264 encoding guide, slowing down the preset should increase the quality. Why? [08:34:17 CEST] <fella> illuminated: different presets pass different values to x264 options. slower preset means higher quality options in x264. If you're looking for smaller files, try '-vf hqdn3d' (see 'man ffmpeg-all'). It defaults to '4', which is a bit blurry imho, but '2' works good for me. [14:09:59 CEST] <rkantos_> any idea how I can get this kind of stuff to work? https://gist.github.com/Brainiarc7/7b6049aac3145927ae1cfeafc8f682c1#gistcom… [14:10:12 CEST] <rkantos_> can I use image2pipe somehow? [14:11:12 CEST] <JEEB> you can't use vf/af and filter_complex together since filter_complex is a global filter chain kind of thing [14:11:50 CEST] <JEEB> I feel like image2pipe isn't going to help you with that :P [14:13:40 CEST] <rkantos_> I can't use rawvideo to pipe a complete frame to another ffmpeg instance that could then use the hw encoder? [14:13:57 CEST] <JEEB> you can but that sounds like a rather roundabout way [14:14:08 CEST] <JEEB> I mean, you can do the same stuff as with vf or af with filter_complex [14:14:31 CEST] <JEEB> and vf/af with filter_complex never worked [14:14:41 CEST] <JEEB> so it's not something that recently changed or so [14:14:49 CEST] <rkantos_> no I understand this^^ [14:15:34 CEST] <rkantos_> That would also mean that gist is wrong though... [14:16:03 CEST] <rkantos_> what do you mean by vf & af & filter_complex? how? :) [14:16:19 CEST] <JEEB> well, filter complex just makes you spell out the whole thing [14:16:40 CEST] <JEEB> but yea, the example definitely looks incorrect, probably copypasta [14:16:45 CEST] <JEEB> the webcam overlay + logo [14:16:47 CEST] <JEEB> thing at least [14:17:00 CEST] <JEEB> which is the first one I found with both filter_complex and vf [14:17:35 CEST] <rkantos_> yeah... that is what I need.. How should I really do it? I don't get it [14:18:11 CEST] <JEEB> I'm going to expect the overlayed thing (called out) is what you want [14:18:39 CEST] <rkantos_> yes! [14:19:24 CEST] <JEEB> then it'd be "[out]format=nv12,hwupload,scale_vaapi=w=1920:h=1080[hwupload_out]" and then instead of -map "[out]" you do -map "[hwupload_out]" [14:19:37 CEST] <JEEB> or you could even remove the yuv420p format from the middle [14:19:49 CEST] <JEEB> but yea that seems like a mess [14:19:59 CEST] <JEEB> either copypasta or something else [14:20:20 CEST] <rkantos_> I just see it as being modified from the nvenc exampl.. hmm [14:27:16 CEST] <rkantos_> JEEB: whatdo you mean instead of -map? How can I use map without filter_complex? [14:27:31 CEST] <rkantos_> JEEB: Can you think of a similar example to that? [14:27:55 CEST] <JEEB> no I mean since you were first picking the output of "out" you instead of that want the output of the hwupload_out [14:28:07 CEST] <JEEB> the string I posted would go at the end of that filter_complex [14:28:14 CEST] <JEEB> although I bet that line has other issues :P [14:28:34 CEST] <JEEB> if it was just copypasted off another example and then hastily modified so that it's not even valid [14:28:43 CEST] <JEEB> just report the issue to the author and have him fix his shit [14:29:05 CEST] <rkantos_> well.. when you swap out h264_vaapi for libx264, it works without issues, if that helps [14:29:29 CEST] <JEEB> probably because x264 doesn't need the hwupload part :P [14:30:51 CEST] <JEEB> I am not going to sit and use my Sunday to fix up someone's broken example. I already told you how to stick the hwupload at the end of that filter_complex [14:31:03 CEST] <JEEB> the rest is up to you or if you just have the author fix his shit [14:32:11 CEST] <rkantos_> JEEB: well... of course not :D [14:33:08 CEST] <durandal_1707> JEEB: play some computer game with gf [14:35:49 CEST] <rkantos_> holy shit [14:36:44 CEST] <rkantos_> JEEB: thanks! where do I donate a beer's worth? :P [14:38:27 CEST] <rkantos_> JEEB: or whatever your vice is [14:50:00 CEST] <rkantos_> now the only thing to figure out is how well Skylake+hevc_vaapi+mpegts+udp over 4g works :D:D [14:50:33 CEST] <rkantos_> a skylake with a 5W TDP too lol [14:51:36 CEST] <furq> i'm pretty sure quicksync is the same on every cpu of the same generation [15:18:01 CEST] <kerio> shit? [15:22:23 CEST] <rkantos_> furq, yeah, no I am more worried about udp,interframe codec and 4g :D [16:40:57 CEST] <Adcock> Guys. [16:41:27 CEST] <Adcock> What Video format produces smallest files for same quality? [16:48:04 CEST] <Hello71> lol [16:48:21 CEST] <Hello71> JEEB: so would you say hardcoded tables is not recommended anymore? [16:49:18 CEST] <JEEB> I would say it was never recommended outside of very low-powered devices. also I still don't see a bug report on the FFmpeg trac regarding it if it's still an issue in master because while MIPS etc compilers are not gonna be updated in a while I bet for various misc hardware it's still likely a bug [17:18:21 CEST] <Hello71> x86 isn't really miscellaneous [17:32:28 CEST] <Hello71> never mind I just filed a ticket [17:34:49 CEST] <w1kl4s> Can i convert .sup subtitles to .ass or .srt using ffmpeg? [17:43:23 CEST] <furq> no [17:43:31 CEST] <furq> sup is image-based so you'd need some ocr tool [17:46:13 CEST] <JEEB> Hello71: I meant MIPS etc [17:46:22 CEST] <JEEB> it was never meant to be used for x86(_64) as far as I can tell [17:46:40 CEST] <JEEB> and thank you for making a ticket about it :P [18:09:39 CEST] <the_k> https://youtu.be/uB-ZSbcwzhI [19:52:35 CEST] <Hello71> I'm trying to re-encode a h264 video with x265. the source material claims to be 29.73 fps, but when I do ffprobe -show_frames | grep '^\[FRAME\]$' | wc -l and divide by the duration I get 76.57, and when I encode it it gives me 120 fps [19:52:37 CEST] <Hello71> what gives [19:53:20 CEST] <Hello71> is 120 a lie? [19:53:50 CEST] <Mavrik> Video recorded with a phone perhaps? [19:53:57 CEST] <Hello71> yeah, it's probably VFR [19:54:40 CEST] <Hello71> pkt_duration_time is all different [19:54:40 CEST] <Mavrik> Yeah, phones will give you VFR [19:54:47 CEST] <Mavrik> Especially in those 120fps modes [19:54:54 CEST] <Mavrik> Where you essentially get "best effort" [19:55:23 CEST] <Hello71> my camera app says 30 fps [19:56:40 CEST] <Mavrik> *shrug* [19:56:49 CEST] <Mavrik> Are you sure it's not just misreporting on one side? [19:57:46 CEST] <Hello71> and when I try to transcode it it runs at 0.1x speed for 3264x1836 with ultrafast on a pretty fast cpu [19:57:53 CEST] <Hello71> pretty sure x265 should be faster than that [19:58:55 CEST] <Mavrik> Sounds about right :P [19:59:12 CEST] <furq> Hello71: -show_frames with no stream specifier will print audio and video frames [19:59:20 CEST] <Hello71> oh. right. [20:00:13 CEST] <furq> also there's really no point using x265 ultrafast [20:00:41 CEST] <Hello71> well I want to use a slower one but then it's even slower [20:00:52 CEST] <Hello71> is x265 actually that slow on higher resolutions? [20:01:11 CEST] <furq> generally with x265, if it's running faster than x264 veryslow then it's going to look worse than x264 veryslow [20:01:22 CEST] <furq> granted 0.1fps at ultrafast sounds broken [20:01:29 CEST] <Hello71> not fps, speed [20:01:32 CEST] <Hello71> 3.5fps it says [20:01:40 CEST] <furq> that's still pretty slow [20:01:50 CEST] <furq> granted i've never had cause to use it with anything above 1080p [20:02:49 CEST] <Hello71> I guess I'll just use x264 then [20:03:11 CEST] <furq> i take it this is some stupidly high rate cbr stream off a camera [20:03:50 CEST] <furq> also you can just do ffprobe -count_frames and look at nb_read_frames [20:07:18 CEST] <Hello71> 16 Mb/s for 3264x1836 seems higher than I need [20:07:22 CEST] <Hello71> although I guess that's not absurd [20:08:58 CEST] <Mavrik> 16mbps to me sounds like minimum I'd like for 4K :/ [20:09:27 CEST] <Hello71> nah, I want it to be potato quality :P [20:09:36 CEST] <Hello71> (although I guess I should just resize it then) [20:10:14 CEST] <Mavrik> Sounds reasonable :) [20:29:01 CEST] <cryptodechange> HDR to SDR tonemapping (https://forum.doom9.org/showthread.php?t=175205) am I supposed to pipe this into another process (using |), or can I bundle the downscale and crop into the filter too? [20:31:52 CEST] <JEEB> see the docs for the tone mapping filter [20:32:18 CEST] <JEEB> it has examples of using the tonemap filter together with zimg [20:32:22 CEST] <JEEB> *zscale [20:32:31 CEST] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#tonemap [20:32:49 CEST] <JEEB> and yes, at the point after that you can also scale [20:35:17 CEST] <JEEB> the tonemap filter doesn't have the dynamic brightness calculation updated into it etc [20:35:33 CEST] <JEEB> since it's pretty much the mpv stuff before it got updated [20:36:16 CEST] <cryptodechange> The video filter examples I have found uses hable [20:36:18 CEST] <cryptodechange> zscale=t=linear:npl=100,format=gbrpf32le, [20:36:18 CEST] <cryptodechange> zscale=p=bt709,tonemap=tonemap=hable:desat=0,zscale=t=bt709:m=bt709:r=tv, [20:36:18 CEST] <cryptodechange> format=yuv420p [20:36:23 CEST] <durandal_1707> there is also opencl version [20:36:35 CEST] <JEEB> the opencl version was funny enough copied from a newer version of mpv's tone mapping [20:36:42 CEST] <JEEB> so IIRC it contains the brightness calculation [20:36:56 CEST] <cryptodechange> and another slightly expanded (not sure the semantics of it) with the following as a prefix: [20:36:57 CEST] <cryptodechange> zscale=tin=smpte2084:min=bt2020nc:pin=bt2020:rin=tv:t=smpte2084:m=bt2020nc:p=bt2020:r=tv, [20:37:18 CEST] <JEEB> also yes, in that zscale you can also scale [20:38:12 CEST] <cryptodechange> But I'm comparing it to mpv screenshots, the filter along with the ripped HDR HEVC version and ripped native SDR X264 version [20:39:20 CEST] <cryptodechange> I've encoded a few sample frames to show me what each section of the filter does, I can upload an imgur in a second, but I don't think it really make a desired result [20:39:24 CEST] <cryptodechange> It's still pretty saturated [20:40:45 CEST] <JEEB> the tonemap filter is based on an old version of what mpv *used* to do [20:41:00 CEST] <JEEB> it hasn't been synchronized since [20:41:16 CEST] <JEEB> the intel guy who did an opencl filter for tone mapping later is based off of what mpv currently does [20:44:52 CEST] <cryptodechange> aha, is it something I can use currently? [20:45:48 CEST] <JEEB> it's in master as far as I remember [20:47:08 CEST] <JEEB> wonder if it was completely ignored in the manpage [20:47:15 CEST] <JEEB> since it's not on ffmpeg-all.html [20:47:32 CEST] <durandal_1707> yes, documenttion failed in review process [20:47:34 CEST] <JEEB> but yes, master has .name = "tonemap_opencl" [20:47:42 CEST] <JEEB> so tonemap_opencl is a thing [20:47:44 CEST] <JEEB> in master [20:48:00 CEST] <Hello71> does anyone know of open source video stabilization better than vidstab? in particular I'm looking for rolling shutter compensation [20:48:10 CEST] <Hello71> seems like there's just deshake for virtualdub but that's not OSS [20:48:11 CEST] <JEEB> and it's funny how haasn's work for mpv has become the de facto tone mapping thing in open source :P [20:48:53 CEST] <JEEB> cryptodechange: not sure which dependencies you need for the opencl filters or the exact usage of it, but it's there in master branch at least :P [22:05:08 CEST] <haasn> cryptodechange: share screenshots [22:05:19 CEST] <haasn> or ideally share clips of the HDR and SDR versions of whatever movie you're testing with [23:03:16 CEST] <oct_opus> hi. I am trying to setup ffserver to stream opus encoded audio (in mkv/webm)... unfortunately, when I open the stream, there is no sound... just plain silence but the counters run :/ Has anyone experienced similar pitfalls? [23:04:00 CEST] <furq> probably not because nobody uses ffserver [23:04:06 CEST] <furq> especially not since it got deprecated [23:04:12 CEST] <furq> for opus you'd be better off using icecast [23:06:05 CEST] <oct_opus> furq: oh, i totally missed that >.< [23:16:32 CEST] <Hello71> wasn't ffserver removed in 4.0 [23:18:19 CEST] <BtbN> it was deprecated since forever, and was eventually finally removed, yes [23:29:16 CEST] <atomnuker> there's a replacement https://github.com/klaxa/ffserver [23:30:28 CEST] <BtbN> it's far from the same featureset though [00:00:00 CEST] --- Mon Oct 15 2018

1 0

ffmpeg-devel.log.20181013
by burek 14 Oct '18

14 Oct '18

[00:34:42 CEST] <akravchenko188> Guys, I have question. [00:37:42 CEST] <akravchenko188> Probably I missed something. I have tried to upload amf support patches like amf context and scale mid of July. Thread in forum became dead, but I tried to ping to continue discussion. [00:39:41 CEST] <iive> what forum? [00:39:43 CEST] <akravchenko188> Could you please help how to drive hw support and not wait for months without feedback? [00:40:13 CEST] <iive> i think all development is done on the maillist, if you have patches send them to the -dev maillist. [00:40:38 CEST] <akravchenko188> I did [00:40:54 CEST] <akravchenko188> I am talking about mail list [00:41:05 CEST] <iive> oh [00:41:43 CEST] <iive> what is amf? [00:42:19 CEST] <akravchenko188> Media Framework from AMD [00:43:03 CEST] <jamrial> jkqxz said he would look at it, afaik, but guess he hasn't had the time to [00:44:33 CEST] <akravchenko188> Yep, he did. But it was more than three month ago [00:45:50 CEST] <akravchenko188> Is it possible to speedup this somehow? [00:46:58 CEST] <akravchenko188> There are lots of new stuff blocked by that patches [00:49:35 CEST] <akravchenko188> So the main problem is the no feedback and huge latency :( [00:50:37 CEST] <Compn> akravchenko188 : what kind of amd card do we need to test ? [00:50:56 CEST] <Compn> akravchenko188 : the way is to give devels more amd cards :D [00:51:41 CEST] <Compn> and for what os ? [00:52:13 CEST] <akravchenko188> Most of not very old cards are supported [00:52:29 CEST] <akravchenko188> Now windows [00:53:26 CEST] <jamrial> Compn: it's not only testing, but also reviewing the implementation, since it adds a new public hwcontext module [00:53:39 CEST] <akravchenko188> Amd added vulkan support for linux, and I am intended to implement support of it in ffmpeg [00:54:17 CEST] <BtbN> Vulkan hwaccel/filter patches are already on their way [00:56:41 CEST] <akravchenko188> I had discussion of hw context amf module. It is very simple. Just to share code between filters and codecs. [00:57:13 CEST] <akravchenko188> It is following hwcontext machinery [01:00:10 CEST] <akravchenko188> It would be really great to have feedback about hwcontextamf [01:02:04 CEST] <BtbN> I think the primary issue is that nobody has an AMD card to test with [01:02:15 CEST] <BtbN> Nobody that also reviews those patches [01:04:09 CEST] <akravchenko188> Is there way to solve this? Is it possible to share pc with amd cards as node for ffmpeg testings? [01:05:31 CEST] <akravchenko188> As part of continuous integration testing? [01:06:06 CEST] <BtbN> An AMD-GPU enabled fate box would definitely be interesting [01:06:24 CEST] <BtbN> There really aren't any tests for all the hwaccels right now [01:13:22 CEST] <akravchenko188> No tests for any hw vendors? [01:14:31 CEST] <akravchenko188> Only cpu codecs/filters are tested automatically? [01:14:32 CEST] <jamrial> no, fate is not testing any hardware stuff [01:15:06 CEST] <jamrial> also no external libraries, only internal modules [01:15:33 CEST] <akravchenko188> Is this issue of fate architecture? Or just policy? [01:16:22 CEST] <jamrial> policy. we have no control over what the external libraries do [01:17:03 CEST] <jamrial> no saying it can't change to add some hwaccel tests eventually, as BtbN said [01:20:58 CEST] <akravchenko188> Is it possible to add extension to fate just to run subset of tests with appropriate hw? [01:24:40 CEST] <akravchenko188> It is very important to test hwaccel stuff on continuous integration basis for all vendors. Imho. [01:27:42 CEST] <akravchenko188> So I see a few of issues with hwaccel: reviewing and testing and supporting [01:28:57 CEST] <akravchenko188> Probably we need some strategy to solve all to have everything stable? [01:34:36 CEST] <akravchenko188> Does anybody drive this? [02:33:39 CEST] <Compn> akravchenko188 : we should ask j-b for some amd devs to test patches [02:33:46 CEST] <Compn> devs w/ amd cards [02:34:08 CEST] <Compn> j-b : we need amd cards apparently [11:39:35 CEST] <durandal_1707> does mpeg2video bitstream can output Y plane values which are exactly 0 when decoded? [13:09:56 CEST] <cone-296> ffmpeg 03Carl Eugen Hoyos 07master:b4e29e6225a8: lavf/mxfenc: Remove two unused variables. [14:13:39 CEST] <cone-296> ffmpeg 03Martin Vignali 07master:04afdbb56052: swscale/x86/rgb2rgb : remove mmx version for shuffle2103 [14:13:40 CEST] <cone-296> ffmpeg 03Martin Vignali 07master:296609f859a5: swscale/x86/rgb2rgb : port shuffle 2103 mmxext to external asm and remove inline asm version [15:02:47 CEST] <durandal_1707> iive: mplayer needs your help! [15:05:39 CEST] <iive> durandal_1707, what's with the passive-aggressive messages? [15:06:13 CEST] <durandal_1707> iive: which ones? [15:06:49 CEST] <kierank> durandal_1707: theoretically yes mpeg2 can [15:07:42 CEST] <durandal_1707> kierank: well, x262 intra have issues with some blocks which have 0, but not if all blocks are 0 [15:09:51 CEST] <atomnuker> durandal_1707: what's with the mplayer interest? no one uses mplayer unless they're forced to, and even then its probably on a 15 year old centos system [15:10:09 CEST] <JEEB> centos and fedora don't distribute FFmpeg et al [15:20:44 CEST] <atomnuker> yeah, what's up with that, I know they do it for patent reasons yet they keep other obviously patented stuff in [15:21:16 CEST] <atomnuker> like the kernel, that's surely a minefield [15:21:25 CEST] <kierank> atomnuker: yeah [15:21:27 CEST] <kierank> it's such BS [15:23:46 CEST] <durandal_1707> should i wait for pushing SER demuxer or should i push immediately? [15:43:20 CEST] <cone-296> ffmpeg 03Paul B Mahol 07master:0709b0561f10: avformat: add SER demuxer [15:44:18 CEST] <durandal_1707> i mix AVI and AV1 all the time [16:32:23 CEST] <durandal_1707> michaelni: do you have comments about agm 3 ? [16:36:23 CEST] <michaelni> durandal_1707, just posted a reply [18:08:43 CEST] <BtbN> wow, SuperMicro released a BIOS Update for my X9 mainboard that's EOS since 2014 [18:12:29 CEST] <atomnuker> they were probably waiting for it to boot up all this time to test it before they uploaded it [18:26:25 CEST] <BtbN> They're not HP [18:53:19 CEST] <durandal_1707> does lavc have any way to crop height from start? [19:01:29 CEST] <BtbN> crop [19:02:11 CEST] <nevcairiel> simply cropping off lines should be easy, no alignment concerns there [19:02:34 CEST] <nevcairiel> should check how the cropping in h264 or hevc works, they can do that [19:32:13 CEST] <durandal_1707> i juse set frame->crop_top [19:51:22 CEST] <durandal_1707> j-b: you got any samples for other codecs, like verint one? [19:53:57 CEST] <durandal_1707> iive: nice work on mplayer [20:10:28 CEST] <j-b> durandal_1707: ask koda [20:10:45 CEST] <j-b> durandal_1707: also, AGM3 is listed now [20:12:14 CEST] <durandal_1707> j-b: difference is very small [20:13:55 CEST] <durandal_1707> to warrant another bounty.. [20:14:59 CEST] <j-b> then find new codecs :) [20:15:32 CEST] <atomnuker> can't find one? no problem, make one yourself! [20:15:36 CEST] <j-b> :D [20:15:42 CEST] <j-b> FFv42 [20:17:48 CEST] <durandal_1707> VVC | XVC | ProRes RAW | Blackmagic RAW | ... [20:18:01 CEST] <j-b> VVC will require a huge decoder time [21:26:21 CEST] <qwefytuoityty> add nero aac? [21:26:36 CEST] <JEEB> no [21:26:46 CEST] <qwefytuoityty> yes? [21:26:50 CEST] <JEEB> fdk-aac is good enough in open source for he-AAC use cases [21:27:18 CEST] <JEEB> and already supported for encoding in FFmpeg [21:27:22 CEST] <qwefytuoityty> vlc use for encoder ffmpeg? [21:27:29 CEST] <JEEB> you can use it as well [21:27:37 CEST] <JEEB> vlc also has its own fdk-aac module [21:27:38 CEST] <JEEB> :P [21:28:09 CEST] <JEEB> it's not included in any of the distributed versions though, since fdk-aac's license is technically incompatible with (L)GPL [21:28:15 CEST] <JEEB> so you have to build that module yourself [21:30:52 CEST] <qwefytuoityty> vlc windows [21:33:01 CEST] <JEEB> if you want to test 24kbps he-AAC or whatever, you will have to build latest fdk-aac yourself (or probably someone on the internet distributes it - I have no idea), and then you have to build FFmpeg or VLC against it to have a module :P [21:33:56 CEST] <JEEB> with fdk-aac in theory they could fix the license, and then you could mix it with (L)GPL stuff so it can be distributed in binary form, but closed source things such as nero's thing are not going to happen [21:50:06 CEST] <durandal_1707> libavcodec/libaomenc.c:545:9: warning: unused variable 'pict_type' [-Wunused-variable] [21:52:30 CEST] <cone-078> ffmpeg 03Paul B Mahol 07master:3ab88a751ebd: doc/filters: do not mention removed option from afir filter [21:56:16 CEST] <BtbN> I think an LGPL build is just fine with fdk-aac [21:56:24 CEST] <BtbN> Just an actual GPL build isn't [21:59:08 CEST] <JEEB> could be, I might be misremembering that other case of closed source in LGPL etc [21:59:15 CEST] <qwefytuoityty> VLC vorbis ogg is not bad, but only minimum 48 klbit. And one more problem compression through vlc in aac and vorbis takes ~ 5 minutes of wav of 78 MB and load of the processor of 100% the computer freezes for 5 min. until the encoding is over. And Nero and Opus console encoder encode the same file for ~ 30 seconds and the computer does not freeze up. [21:59:22 CEST] <jamrial> BtbN: fdk-aac needs nonfree [22:00:32 CEST] <BtbN> libfdk_aac is in EXTERNAL_LIBRARY_NONFREE_LIST, and configure says enabled gpl && map "die_license_disabled_gpl nonfree" $EXTERNAL_LIBRARY_NONFREE_LIST [22:00:42 CEST] <BtbN> So in an lgpl build it does not need non-free [22:01:05 CEST] <JEEB> yes [22:02:47 CEST] <nevcairiel> from a legal standpoint t hat sounds weird to me [22:03:04 CEST] <BtbN> That's how LGPL works [22:03:05 CEST] <nevcairiel> if a library is classified proprietary and non-distributable, that shouldnt change [22:03:31 CEST] <nevcairiel> LGPL only changes the requirements for the application using it, not the things we directly interact with [22:06:44 CEST] <qwefytuoityty> i in vlc cnanel too [22:07:39 CEST] <qwefytuoityty> AMD qad core x4 840 FM2+ Windows 32 1400MZ. Opus console and nero, load opus exe 25% 1400Mz [22:28:50 CEST] <philipl> LGPL is satisfied if consumer can replace the LGPL bit with something they compiled themselves. [23:26:51 CEST] <BtbN> philipl, nevcairiel: Is it just me, or shouldn't this be a >= check? http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/cuviddec.c;h=4d3c… [23:29:16 CEST] <BtbN> Also, I think the 2 should really be ulMaxDisplayDelay * ((!drop_second_field && deint != weave) ? 2 : 1) [23:53:08 CEST] <BtbN> https://github.com/BtbN/FFmpeg/commit/861531d29834b7a2940e426e5a761aa8e5eb3… seems more correct [00:00:00 CEST] --- Sun Oct 14 2018

1 0

ffmpeg.log.20181013
by burek 14 Oct '18

14 Oct '18

[13:36:23 CEST] <Daisae> In copying a segment from an AV file, is there a way to specify to start with the I-Frame after a time rather than before? [13:37:34 CEST] <JEEB> the seeking API actually seems to do that by default although I guess you might have more luck by indexing the thing first to know where exactly the random access points are [13:40:39 CEST] <Daisae> Thanks. [14:03:49 CEST] <{xmb}> is there a -novideo option [14:04:14 CEST] <ChocolateArmpits> {xmb}, -vn [14:04:20 CEST] <{xmb}> thxx [14:21:10 CEST] <{xmb}> how can i somehow do a tech quality check on files [14:21:21 CEST] <{xmb}> eg diff between vorbis and libvorbis [14:23:34 CEST] <ChocolateArmpits> {xmb}, use ffprobe to get information about streams and their formats [14:25:29 CEST] <{xmb}> i more need like hearing differencies, yet i listened and found vorbis better than libvorbis, thanks tho [14:25:50 CEST] <ChocolateArmpits> oh then that's not for that [14:26:27 CEST] <furq> uh [14:26:32 CEST] <{xmb}> m4a doesnt support 96000+ ? [14:26:35 CEST] <furq> libvorbis should be a lot better than vorbis [14:26:48 CEST] <{xmb}> ill listen to more tests [14:27:02 CEST] <Daisae> {xmb}: someone made their own tunings to Vorbis parameters. I don't remember more. I'm not sure Vorbis has any advantage over Opus -- aside from having a better name. [14:27:04 CEST] <furq> the internal vorbis encoder is pretty underdeveloped iirc [14:27:12 CEST] <furq> also yeah you should be using opus anyway [14:27:27 CEST] <furq> by which i mean libopus [14:27:46 CEST] <{xmb}> i cant, i tried, no 96khz+ and no fltp o [14:27:55 CEST] <{xmb}> and/or [14:28:01 CEST] <furq> why would you want lossy 96k [14:28:09 CEST] <{xmb}> better q [14:28:26 CEST] <Daisae> You mean that Opus does not support >96KHz? [14:28:27 CEST] <{xmb}> from crappy to more q, i heard much enuff diff [14:28:39 CEST] <furq> opus doesn't support anything about 48khz [14:28:45 CEST] <{xmb}> either or both 96k and fltp [14:28:54 CEST] <Daisae> What is fltp? [14:28:57 CEST] <furq> for good reasons that will start an argument [14:29:00 CEST] <furq> fltp is 32-bit float samples [14:29:03 CEST] <furq> inasmuch as lossy codecs have those [14:29:04 CEST] <{xmb}> 32b floating point i think [14:29:14 CEST] <Daisae> furq: You mean 'above'? [14:29:21 CEST] <furq> i do [14:29:40 CEST] <{xmb}> u can maybe listen to the test samples [14:30:14 CEST] <ChocolateArmpits> opus is meant for internet stuff, not production, so 96kHz is useless [14:30:25 CEST] <furq> s/internet stuff/playback but yeah [14:30:32 CEST] <{xmb}> what other audio container, more common than mka, for the high stats purpose [14:30:55 CEST] <ChocolateArmpits> {xmb}, are you interested in quality solely? [14:31:01 CEST] <furq> i mean i don't see why you'd use anything other than flac or pcm [14:31:19 CEST] <{xmb}> so lala better-up quality [14:31:20 CEST] <furq> i know flac only does 24-bit but 24-bit int to 32-bit float is lossless iirc [14:31:27 CEST] <{xmb}> more -q more hz more bitnthats all [14:31:49 CEST] <{xmb}> i hoped for 64b but all i can find is uncompressed pcm [14:32:08 CEST] <{xmb}> flac is too much size [14:32:34 CEST] <{xmb}> i read 20 / 50 mb per 4 min song, no good for sharing on slow inet or so like phones [14:32:39 CEST] <furq> oh wait you're that guy from yesterday who wanted to reencode mp3s at a higher sample rate so they'd be higher quality [14:32:47 CEST] <{xmb}> yea [14:32:50 CEST] <{xmb}> :/ [14:32:54 CEST] <furq> yeah as we repeatedly told you, that isn't a thing [14:33:19 CEST] <{xmb}> could u listen to the example tho ? [14:33:51 CEST] <furq> unless you're encoding a different mp3 from a lossless source [14:34:14 CEST] <furq> you can't get back the information that was lost by mp3 compression [14:34:41 CEST] <{xmb}> i dontmerr.. i make it betternquality resampled [14:34:45 CEST] <furq> if you're hearing a difference then you should probably do a proper abx test [14:34:51 CEST] <{xmb}> makes a differencemfor me enuff to do it [14:35:26 CEST] <{xmb}> ohnwell :/ thanks anyway tho [14:36:05 CEST] <durandal_1707> if you still hear difference after abx, you should visit nearest doctor ASAP [14:36:32 CEST] <{xmb}> listen yourself, .. [14:36:54 CEST] <{xmb}> the bass-loss is less, its comfortabler, clearer [14:37:45 CEST] <durandal_1707> that is your brain making fun of you [14:37:53 CEST] <{xmb}> ok thxx enemy [14:39:46 CEST] <durandal_1707> this guy found our native vorbis to be better than libvorbis -- this is enough to warrant special care [14:47:27 CEST] <durandal_1707> even with mp3 transcoding - what people smoke this days.... [14:47:50 CEST] <furq> 64-bit mp3 is the future [14:48:01 CEST] <durandal_1707> :) [14:58:20 CEST] <BtbN> There are people buying 4000¬ switches and weird-plug-directional-lan-cables because it enables better audio flow [14:58:30 CEST] <BtbN> So nothing surprises me where people claim better audio quality [15:05:31 CEST] <furq> i've seen a 20+ page long forum thread where people sincerely debate whether aiff sounds better than wav [15:05:50 CEST] <furq> and anyone going "wtf they're both 16-bit pcm" gets a stern rebuke from the administrators [16:54:42 CEST] <Hello71> who knows, maybe they're putting in MP3 [16:54:59 CEST] <Hello71> pretty sure riff supports mp3 [18:37:38 CEST] <analogical> when I create a flac file how do I specify the compression leve? [18:37:52 CEST] <analogical> *level [18:38:22 CEST] <TheAMM> -q:a <0-9> I'd say [18:38:30 CEST] <TheAMM> Someone will tell how I'm wrong, soon, so hold on [18:38:31 CEST] <JEEB> that makes no sense with lossless [18:38:41 CEST] <analogical> ffmpeg.exe -i test.wav test.flac [18:38:49 CEST] <JEEB> see the output of [18:38:53 CEST] <JEEB> ffmpeg -h encoder=flac [18:39:03 CEST] <JEEB> that lists all of the AVOptions for flac [18:39:24 CEST] <JEEB> it seems like it throws all the bits and pieces at you [18:39:35 CEST] <JEEB> instead of having these simple to look at but you don't know the bits and pieces inside [18:39:43 CEST] <durandal_1707> -compression_level [18:39:59 CEST] <JEEB> so it's a general avcodeccontext option? [18:42:01 CEST] <durandal_1707> yes [18:42:12 CEST] <JEEB> roger [18:43:01 CEST] <furq> analogical: -compression_level 12 is the highest for flac [18:48:27 CEST] <analogical> thanks furq [18:49:26 CEST] <analogical> FFmpeg flac is more efficient than Xiph flac [18:49:33 CEST] <analogical> strange [18:54:11 CEST] <durandal_1707> there are other options that make encoder super slow at higher compression ratio [19:03:20 CEST] <furq> analogical: it depends on the source [19:03:35 CEST] <furq> i tested a bunch of stuff with ffmpeg -compression_level 12 and flac -8 and it came out about even in the end [19:05:51 CEST] <analogical> furq, interesting. I also made that comparison and found that FFmpeg achieved slightly better compression at those settings but more importantly the FFmpeg generated file worked better in players with MUCH less cpu usage and no dealys when skipping forward :) [19:06:14 CEST] <analogical> *skipping ahead [19:06:46 CEST] <furq> well that part is unexpected [19:08:30 CEST] <furq> what are you playing that back on [19:08:39 CEST] <furq> i've never had any noticeable cpu usage or seek delays playing flac [19:08:52 CEST] <furq> the whole point of flac is that it decodes super fast [19:09:34 CEST] <analogical> the difference is most noticeable with VLC [19:10:18 CEST] <furq> i'm going to guess something is just broken there then [19:12:10 CEST] <Hello71> are you putting it in ogg? [19:13:15 CEST] <furq> unless you were using --lax or something [21:55:00 CEST] <RavenWorks> I'm following the instructions to do lossless encoding in H.264, but the results are visibly not identical [21:55:37 CEST] <RavenWorks> the input video is a series of PNG files, but they don't have any embedded color profile information (that exiftool can see) so I don't think that's the problem? [21:55:52 CEST] <JEEB> by default the libx264 wrapper doesn't do RGB [21:55:59 CEST] <RavenWorks> not even in lossless mode? [21:56:10 CEST] <JEEB> you will have to use the separate "codec" in the wrapper to do RGB specifically [21:56:19 CEST] <JEEB> I think it's like -c:v libx264rgb or something [21:56:45 CEST] <JEEB> yea, that seems to be it [21:57:12 CEST] <RavenWorks> ok, I just saw them mention something about that in the FAQ, but they blame it on pix_fmt but also say that it's the default "now"... [21:57:13 CEST] <JEEB> the only reason RGB is separated is because people using H.264 for RGB is so limited that it's more likely someone uses it by accident, and thus it was separated [21:57:35 CEST] <JEEB> you can see most of the internal conversions if there are any with -v verbose added [21:57:50 CEST] <JEEB> and if your input is RGB and you are using libx264rgb as the encoder, then you shouldn't have an issue? [21:58:04 CEST] <RavenWorks> I'll give it a shot [21:59:07 CEST] <furq> JEEB: is that actually the reason [21:59:23 CEST] <JEEB> furq: unless you can find another one in the commit log, yes [21:59:41 CEST] <JEEB> it was literally made so that ffmpeg.c etc wouldn't think "oh I can pass RGB to this thing so I will not do any conversions" [21:59:54 CEST] <RavenWorks> That did it!! Thanks so much [21:59:57 CEST] <furq> i guess that sort of makes sense but then it'll just convert to 4:4:4 [22:00:01 CEST] <furq> which is almost as useless [22:00:22 CEST] <RavenWorks> I guess the wiki should be updated [22:00:24 CEST] <JEEB> yes, it /almost/ makes sense [22:00:30 CEST] <JEEB> and as you note, it has its issues :P [22:03:05 CEST] <RavenWorks> oh, hm, does it take special permissions to edit the wiki? [22:03:15 CEST] <JEEB> not that I know? [22:03:19 CEST] <JEEB> although I've never tried [22:03:26 CEST] <RavenWorks> oh wait no -- the link's just at the bottom, hah [22:03:26 CEST] <JEEB> I only just herp a derp in issues/bugs [22:03:34 CEST] <RavenWorks> I figured it would be at the top with everything else [22:05:52 CEST] <RavenWorks> Should I replace the current thing in the FAQ suggesting -pix_fmt yuv444p, or add this in addition to it? [22:06:20 CEST] <furq> add it in addition [22:06:28 CEST] <RavenWorks> ok [22:06:34 CEST] <furq> there's usually no point using rgb or yuv444p [22:06:44 CEST] <furq> basically everything expects yuv420p these days [22:07:14 CEST] <RavenWorks> in my case, I'm just trying to store the raw frames of a render in less hard drive space [22:07:41 CEST] <RavenWorks> and from there I'll render it out to something useful when actually publishing it [22:07:41 CEST] <furq> yeah i'm just saying that's a niche use case [22:08:00 CEST] <RavenWorks> oh, understandably [22:08:17 CEST] <furq> also if the colours are noticeably different then something probably fucked up in the rgb to yuv conversion [22:08:32 CEST] <RavenWorks> I just mean, I'm not sure if the yuv444p suggestion belongs there? if the problem is the RGB to YUV conversion, would yuv444p be enough to fix it? [22:08:36 CEST] <RavenWorks> it didn't in my case [22:08:47 CEST] <furq> it'll default to yuv444p anyway [22:08:57 CEST] <RavenWorks> all the more reason I'm not sure why it's still in the faq [22:09:09 CEST] <furq> link the page [22:09:16 CEST] <RavenWorks> ahh, sorry [22:09:26 CEST] <RavenWorks> https://trac.ffmpeg.org/wiki/Encode/H.264#FAQ [22:10:00 CEST] <furq> yeah i guess there's no reason for that to be there [22:10:22 CEST] <furq> but like i said there should nominally only be very minor differences [22:10:29 CEST] <furq> unless something like the colour primaries got messed up [22:10:44 CEST] <furq> idk how smart swscale is but i get the impression it's not that smart [22:10:45 CEST] <RavenWorks> I had to zoom way in, but it introduced some banding in some subtle gradients [22:11:00 CEST] <furq> yeah that sounds ok then [22:11:59 CEST] <furq> i would say that if you're going to recommend libx264rgb then also mention that not many decoders support it [22:12:06 CEST] <furq> but the same is true of high444, which is needed for yuv444p [22:12:24 CEST] <RavenWorks> the page already mentions that virtually nothing decodes lossless in the first place [22:12:31 CEST] <furq> that's true [22:12:48 CEST] <furq> i guess it also mentions that yuv420p is the only thing with good support just below that [22:12:52 CEST] <RavenWorks> yeah [22:13:15 CEST] <RavenWorks> I just want to have an archive of the clean frames to make all the published compressed versions from, with ffmpeg [22:13:56 CEST] <furq> there's obviously advantages and disadvantages of just doing the colourspace conversion now [22:14:06 CEST] <RavenWorks> I was gonna run optipng on them but then I was like "wait this is literally an animation, something that can refer to previous frames would probably save way more space" and I realised I was thinking of lossless video, heh [22:14:10 CEST] <RavenWorks> yeah, true enough... [22:14:12 CEST] <furq> but if disk space isn't an issue then it's not like it takes much cpu time [22:14:19 CEST] <furq> so there's no harm keeping it as it is [22:18:09 CEST] <RavenWorks> Alright, wiki updated! Thanks for your help. [22:34:12 CEST] <newbsduser> hello guys, I have a rtsp:// live stream url. I want to check video output for this stream is healthy or not? How can I do that? [22:57:49 CEST] <sfan5> throw it into ffprobe? [22:58:09 CEST] <sfan5> alternatively: use ffmpeg to capture a single frame and verify that it looks fine [23:05:37 CEST] <Hello71> what are your experiences with aggressive gcc optimizations? https://github.com/InBetweenNames/gentooLTO/issues/103 [23:06:04 CEST] <newbsduser> ffprobe -v quiet -print_format json -show_streams 'rtsp://user:aa@192.168.1.15:554/cam/realmonitor?channel=4&subtype=1' [23:06:13 CEST] <JEEB> we already disable some optimizations because they generated broken stuff at some point [23:06:15 CEST] <Hello71> not like -ffast-math. we are discussing testing -O3 -flto -fipa-pta with graphite, but apparently it doesn't work with sse4 intrinsics or something [23:06:28 CEST] <JEEB> we don't have any intrinsics :) [23:06:32 CEST] <Hello71> hm [23:06:33 CEST] <JEEB> only internal asm [23:06:38 CEST] <JEEB> as in, separate asm files [23:06:40 CEST] <newbsduser> worked fine for non-existing channel. but I am not it work for every unsuccessful live stream correctly? [23:06:42 CEST] <JEEB> which get compiled into objects [23:06:46 CEST] <Hello71> someone claims there are intrinsics [23:07:06 CEST] <Hello71> I understand that that's different from inline and external asm [23:07:07 CEST] <JEEB> maybe for non-x86, but even for ARM we are using raw assembly functions [23:07:09 CEST] <newbsduser> worked fine for non-existing channel. but I am not sure it work for every unsuccessful live stream correctly? [23:07:37 CEST] <JEEB> the x86 and x86_64 stuff is all separate [23:07:42 CEST] <JEEB> we don't merge in intrinsics [23:08:05 CEST] <JEEB> that's the primary reason why not all of the intrinsics from openhevc are in (although partially it's also because the code base has diverted during the last n years) [23:08:30 CEST] <JEEB> the openhevc people converted some of their intrinsics into separate asm [23:08:36 CEST] <JEEB> and that I think went in [23:09:28 CEST] <JEEB> but yea, we have various C compiler optimizations disabled [23:09:54 CEST] <JEEB> because we had them disabled at some point years ago, then people thought the issues were gone by now, and then it got re-disabled a few weeks later :P [23:10:28 CEST] <JEEB> so in a standard configuration FFmpeg will disable some of the optimizations for vectorization etc [23:10:35 CEST] <Hello71> apparently nobody reported https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85132 upstream? [23:10:51 CEST] <Hello71> tl;dr gcc 8 + ffmpeg 3.4.2 + lto = SIGSEGV in ff_sine_window_init [23:11:15 CEST] <Hello71> or is hardcoded tables not recommended anymore? if so someone should tell gentoo [23:12:26 CEST] <JEEB> was it ever explicitly recommended? [23:12:59 CEST] <atomnuker> nope, it pretty much only for underpowered mips devices, in fact chunks of it were removed some times ago [23:13:02 CEST] <atomnuker> *time [23:13:11 CEST] <JEEB> yea I only get configure hits with that [23:13:24 CEST] <JEEB> both the enable thing [23:13:33 CEST] <JEEB> and the hardcoded_tables in FEATURE_LIST [23:13:57 CEST] <JEEB> ok, using -i with grep helped [23:14:05 CEST] <JEEB> CONFIG_HARDCODED_TABLES [23:14:36 CEST] <Hello71> well it's still the default for gentoo, and apparently it doesn't work with lto [23:19:15 CEST] <JEEB> I would first of all test if the issue is still around, and then would report it on trac if it's still there (on master) [23:19:39 CEST] <JEEB> given that the option is not on by default and the way LTO optimizes changed between gcc 7.x and 8.x (and due to not everyone running LTO) I wouldn't be surprised if nobody noticed :P [23:46:05 CEST] <cryptodechange> Trying to decide whether or not I should go with Bicubic or Area for downsizing 4k footage to 1080p [23:46:26 CEST] <cryptodechange> Can't find much reading material comparing the two [23:46:47 CEST] <JEEB> if you want high quality scaling you'll have to use zscale which uses the zimg library in the background anyways :P [23:54:30 CEST] <Hello71> JEEB: well clearly someone did notice, just apparently didn't report it? [23:54:38 CEST] <Hello71> it's still broken [23:55:03 CEST] <cryptodechange> Interesting, scale uses bicubic as default, zscale uses bilinear? [00:00:00 CEST] --- Sun Oct 14 2018

1 0

ffmpeg-devel.log.20181012
by burek 13 Oct '18

13 Oct '18

[00:07:53 CEST] <BtbN> Isn't the Vulkan stuff long in? [01:00:18 CEST] <cone-234> ffmpeg 03Michael Niedermayer 07master:8f1524802469: avcodec/aacdec_template: Allow duplicated elements [01:00:19 CEST] <cone-234> ffmpeg 03Michael Niedermayer 07master:ccd2b20ad96c: avcodec/ffv1dec_template: Check for the end of input after 1024 pixels [03:07:35 CEST] <cone-234> ffmpeg 03Sam John 07master:e265832c378c: libavcodec/libaomenc.c: Added code for computing PSNR/SSIM [05:52:45 CEST] <cone-234> ffmpeg 03Aman Gupta 07master:f6d48b618aad: avcodec/mediacodec: add av_mediacodec_render_buffer_at_time() [07:22:29 CEST] <atomnuker> BtbN: nope, now waiting on google to enable the dma mod extension in the vulkan docs repo [07:22:42 CEST] <atomnuker> at least its merged [07:32:15 CEST] <cone-234> ffmpeg 03James Almer 07release/4.0:967604fecf04: avcodec/h2645_parse: skip NALUs with no content after stripping all the trailing zeros [12:23:53 CEST] <BtbN> atomnuker, oh, ok. When it lands, adding CUDA interop is probably relatively straight forward. [12:24:19 CEST] <BtbN> No more new non-free CUDA filters then, hopefully. [12:24:56 CEST] <atomnuker> what about the gpu memcpy? or was that going to get solved by a new driver? philipl? [12:25:17 CEST] <BtbN> That was his workaround for a driver bug which nvidia claims to be fixed in the internal dev branch [12:25:49 CEST] <BtbN> They will see about a backport to 410, and if not, the next series will be fixed [12:26:03 CEST] <BtbN> There is actual mapping support, but right now it produces garbage [12:27:58 CEST] <nevcairiel> on-gpu copies are usually not the end of the world anyway, especially on dedicated cards like those, this isnt a crappy intel iGPU running on sysmem afterall [12:29:03 CEST] <BtbN> They kind of defeat the purpose though [12:29:27 CEST] <BtbN> The idea is to map to a Vulkan Image, run filters on it, and then without copying back pass the CUDA image to nvenc [12:29:39 CEST] <BtbN> Which should be absolutely possible [12:30:37 CEST] <nevcairiel> if its transparent to the user then its just a performance issue, at the end of the day you can still use vulkan filters and encode with nvenc [12:31:13 CEST] <durandal_1707> why old links from github fail to download? is github finally going down the road? [12:32:00 CEST] <BtbN> define old links [12:32:45 CEST] <BtbN> nevcairiel, at the moment you can't even do that, as there was no infrastructure for that prior to CUDA 10 [12:32:56 CEST] <BtbN> And CUDA 10 added actual mapping, so why would you copy? [12:33:04 CEST] <BtbN> The mapping not working is a bug on nvidias end [14:22:48 CEST] <January> Am I supposed to add extra AV_FRAME_DATA items underneath `#if FF_API_FRAME_QP` or before it? [14:24:08 CEST] <BtbN> What do you mean? That looks like a deprecation guard, so I'd guess no. [14:24:41 CEST] <nevcairiel> always at the end of everything [14:25:13 CEST] <January> but without FF_API_FRAME_QP it'd be the same as AV_FRAME_DATA_QP_TABLE_PROPERTIES, is this ok? [14:25:44 CEST] <January> Also, michaelni, `printf("\n")` under wine prints CRLF, how am I supposed to make it output just LF to match the reference file (I fixed the I/O issue under mingw)? [14:26:59 CEST] <BtbN> I'm not sure what you're doing, but it doesn't seem right [14:27:03 CEST] <BtbN> What are you doing with wine? [14:27:48 CEST] <January> BtbN: http://ffmpeg.org/pipermail/ffmpeg-devel/2018-October/235017.html testing this fate test [14:29:36 CEST] <nevcairiel> this works for everything else that compares such things, why not your test? :) [14:32:44 CEST] <BtbN> I guess fate via wine isn't a common test target [14:33:59 CEST] <nevcairiel> you can use something like setmode(fileno(stdout), O_BINARY) to get rid of any text-mode translations [14:34:05 CEST] <nevcairiel> wrap it into a windows ifdef [14:34:38 CEST] <BtbN> I mean, it seems desired on really every platform [14:40:59 CEST] <January> oh I guess I need to use "wb" explicitly instead of just "w" for windows [14:41:23 CEST] <nevcairiel> you dont seem to use your output file at all, just open and close it [14:41:26 CEST] <nevcairiel> or did i miss something [15:06:21 CEST] <January> apparently "wb" doesnt make any difference thouhg setmode() worked, so weird [15:06:59 CEST] <BtbN> Are you even writing to your file, and not just printing to stdout? [15:18:10 CEST] <January> BtbN: Oh. You're right I'm clearly super tired. [15:25:17 CEST] <January> `fate-lavf-mxf` seems to be broken on origin/master for me, anyone else as well? [15:49:59 CEST] <J_Darnley> January: that test works for me [15:51:08 CEST] <J_Darnley> commit f6d48b618a [15:51:14 CEST] <J_Darnley> avcodec/mediacodec: add av_mediacodec_render_buffer_at_time() [16:40:50 CEST] <durandal_1707> iive: but mplayer doesn't build with latest and greatest ffmpeg [18:06:01 CEST] <jamrial> atomnuker, jkqxz: https://www.amd.com/en/support/kb/release-notes/rn-rad-win-18-10-1 [18:06:04 CEST] <jamrial> the Vulkan section [18:25:20 CEST] <atomnuker> nothing really seems useful for us? swapchains are only used for display so they're usually only in RGBA [18:25:50 CEST] <atomnuker> you still have to do ycbcr conversion yourself (or through an extension) [18:28:46 CEST] <jamrial> VK_EXT_hdr_metadata? [18:31:41 CEST] <atomnuker> yeah, its meant to be attached to swapchains so the compositor knows the window is HDR [18:48:59 CEST] <cone-797> ffmpeg 03Aman Gupta 07master:0c14b73e435c: avcodec/avpacket: fix whitespace [19:25:13 CEST] <cone-797> ffmpeg 03Paul B Mahol 07master:330dd59a3025: avcodec/imm4: stop using FAAN idct [20:45:43 CEST] <durandal_1707> michaelni: you had time to check agm 3? [21:31:53 CEST] <cone-797> ffmpeg 03Baptiste Coudurier 07master:3d38e45eb85c: avformat/mxfenc: write index delta entry array needed by sony vegas pro 11 [21:31:54 CEST] <cone-797> ffmpeg 03Baptiste Coudurier 07master:ea55a11ced5e: avformat/mxfenc: add mpeg-2 specific metadata, fix compatibility with sony content browser [21:31:55 CEST] <cone-797> ffmpeg 03Baptiste Coudurier 07master:84e8a87ca082: avformat/mxfenc: update body partition with footer offset [21:31:56 CEST] <cone-797> ffmpeg 03Baptiste Coudurier 07master:bb89109a0a29: avformat/mxfenc: correctly set content package rate in system element [21:31:57 CEST] <cone-797> ffmpeg 03Baptiste Coudurier 07master:9b7ab5795341: lavf/mxfenc: support creating s436m data tracks [21:31:58 CEST] <cone-797> ffmpeg 03Baptiste Coudurier 07master:ef23ed6fe96e: lavf/mxfdec: demux s436m as eia608 subtitle track [00:00:00 CEST] --- Sat Oct 13 2018

1 0

ffmpeg.log.20181012
by burek 13 Oct '18

13 Oct '18

[00:00:32 CEST] <kepstin> (and it's also just as meaningless, since different encoders, settings, etc, mean 10mbit can look completely different between two encodes of the same content) [03:30:33 CEST] <calamari> I was preparing to convert some MPEG2 video streams when I heard that some of these might be variable FRAME rate, due to a different rate being supposedly being used for special effects scenes. Can ffmpeg (or some other linux program) evaluate a video stream to determine whether the rate ever changes? I'm actually not sure if rate info is even in the video stream or whether it'd be in the container. [03:39:18 CEST] <ariyasu> you can use media info of ffprobe to get that info [03:41:35 CEST] <calamari> thanks. I'm not seeing VFR in the ffprobe man page.. should I be looking for something else? [03:43:48 CEST] <calamari> mediainfo was more helpful [03:44:08 CEST] <calamari> Frame rate mode : Variable [03:45:36 CEST] <calamari> thanks! [03:47:18 CEST] <calamari> if I want to preserve the VFR with ffmpeg do I need to do anything (like -vsync vfr) or will it automatically retain it? [03:48:10 CEST] <Hello71> ffmpeg generally tries to preserve everything [03:48:19 CEST] <Hello71> even if it's not really the right thing to do [03:48:55 CEST] <Hello71> personally I think the CLI would make more sense if the default was to not re-encode [03:49:00 CEST] <Hello71> but it's a little too late [03:49:13 CEST] <calamari> yeah not sure yet whether my player even handles it.. guess I should do some tests [03:49:37 CEST] <Hello71> if only avconv actually had a better interface rather than just screaming IMPROVED IMPROVED and FFMPEG IS DEPRECATED [03:50:03 CEST] <calamari> ffmpeg is deprecated? I didn't know that, haha [03:50:33 CEST] <calamari> I normally just pipe raw frames to x264, but that's not going to work this time [03:51:20 CEST] <Hello71> yes, everybody should use libav [03:51:23 CEST] <Hello71> it's not dead, just resting [03:53:53 CEST] <calamari> I do remember avconv years back.. but it seems Ubuntu 18.04 just has ffmpeg again, it's not a symlink or anything either [03:54:19 CEST] <calamari> ffmpeg version 3.4.4-0ubuntu0.18.04.1 Copyright (c) 2000-2018 the FFmpeg developers [03:55:07 CEST] <calamari> whatever it is, I'm sure it'll do the job I need [03:56:48 CEST] <calamari> I mainly used x264 back in the day because I could ensure the H.264 was blu-ray compliant... but I haven't authored a blu-ray in years so all those special options are unnecessary [04:46:30 CEST] <Maverick|MSG> is it possible to increase the speed of the audio (atempo) but only at certain timepoints in a video? [05:00:57 CEST] <killown> how do I merge two or more videos that has different sizes and frame rates [05:27:58 CEST] <calamari> killown: I haven't tried this, but I wonder if mkvmerge would work [05:49:09 CEST] <worstadmin> ffmpeg is actively developed [12:56:22 CEST] <th3_v0ice> Are there any fields in the API part that tell you how big an AVFrame that is decoded actually is in bytes? [12:57:39 CEST] <BtbN> no [12:57:51 CEST] <BtbN> You can calculate a good guess based on the height and linesize and the pix_fmt [13:02:43 CEST] <th3_v0ice> What would be the formula for that? [13:06:06 CEST] <BtbN> the sum of the (height << subsample[plane]) * linesize[plane] * bytes_per_pixel for all planes [13:06:10 CEST] <BtbN> roughly [13:06:34 CEST] <BtbN> forget about the bytes_per_pixel, linesize already is in bytes [13:06:35 CEST] <iive> linesize is in bytes [13:06:55 CEST] <iive> you might want to take abs() of it though. [13:23:59 CEST] <th3_v0ice> I cant find the subsample field in the AVFrame structure, is this the data or buf? [14:01:31 CEST] <BtbN> The pixel format dictates it [14:01:52 CEST] <BtbN> As well as the number of planes [14:08:29 CEST] <th3_v0ice> Oh, so for 422 it would be (height << 4) * linesize[0] + (height << 2) * linesize[1] + (height << 2) * linesize[2] ? [14:11:32 CEST] <BtbN> no [14:12:02 CEST] <BtbN> There's a separate API to get information about pix_fmts ffmpeg knows about. [14:30:44 CEST] <th3_v0ice> Ok, thanks! [14:59:13 CEST] <PyroPeter> hey, I need to eliminate frequencies under 30Hz and above 15kHz for FM broadcasting, but I can't figure out how to do this with ffmpeg. I guess that I can forget about 'lowpass' and the like, because they are only two-pole filters and are not steep enough for this application... [15:02:29 CEST] <JEEB> I would have thought of 'alimit' (http://ffmpeg.org/ffmpeg-filters.html#alimiter) but it seems like that's not it [15:02:44 CEST] <JEEB> some audio encoders have their own limiting AVOptions [15:10:42 CEST] <durandal_1707> PyroPeter: you can use them in cascade [15:11:19 CEST] <durandal_1707> JEEB: alimiter is for broadband audio volume limiting [15:11:29 CEST] <JEEB> yea [15:12:42 CEST] <durandal_1707> PyroPeter: how steep you need? [15:39:30 CEST] <isuxx> how can i make my player show 64bit * instead of 16bit aac [15:42:01 CEST] <tytan> Hello everyone, I tried to crop a 16:9 video to 2:1 but I wanted the cropped rectangle to be the lower part of the video so I tried to crop away the upper 80 pixel on y with the following command but it didn't work. The rectangle seems to be centred. ffmpeg -i 16_9_video.mp4 -vf "scale=1280:640:0:-80" 2_1_video.mp4 [15:43:23 CEST] <tytan> oh I meant crop, not scale in here [16:05:46 CEST] <PyroPeter> durandal_1707: if I set the cutoff to 14kHz, I seem to need a 100dB/decade slope to end up 3dB below the 19kHz pilot tone... (I have no idea what I'm doing, if that isn't obvious) [16:11:50 CEST] <durandal_1707> PyroPeter: you could model high order IIR filter in some other software and use its defined points in aiir filter for fixed sample rate, aiir filter also can draw frequency and phase response [16:12:48 CEST] <durandal_1707> or use recently added acrossover and its 8th order filter to split bands [16:12:56 CEST] <durandal_1707> if 8th order is enough [16:56:10 CEST] <rafael2k> Hi all. Is there any volumetric video codec present in ffmpeg? [16:56:21 CEST] <JEEB> "volumetric video codec"? [16:56:32 CEST] <rafael2k> XYZ + RGB [16:56:43 CEST] <rafael2k> aka point cloud [16:57:05 CEST] <rafael2k> Volumetric Video I think is precise, indeed. [16:57:25 CEST] <JEEB> I know what XYZ is (kind of), and I know what RGB is more or less [16:57:30 CEST] <JEEB> but XYZ + RGB is like ?! [16:57:42 CEST] <rafael2k> a vector of points [16:57:56 CEST] <rafael2k> XYZ is the coordinate of the point [16:58:09 CEST] <JEEB> the only format that supports the "XYZ" pixel format seems to be JPEG2000 [16:58:14 CEST] <rafael2k> no no [16:58:20 CEST] <rafael2k> this is the color space... [16:58:31 CEST] <JEEB> well yes [16:58:40 CEST] <rafael2k> I'm talking about 3D Volumetric Video [16:58:41 CEST] <JEEB> it is just specifically marked separate from RGB etc [16:59:01 CEST] <JEEB> ok, so multiview? [16:59:06 CEST] <rafael2k> no [16:59:20 CEST] <rafael2k> multiview are many 2D frames [17:00:09 CEST] <isuxx> what -codecw does s64p support [17:00:20 CEST] <JEEB> > There is no standard yet that generated volumetric video and makes it experienceable at home. Compression of this data is starting to be available with the MPEG group in search for a reasonable way to stream the data. [17:00:24 CEST] <JEEB> from wikipedia [17:00:35 CEST] <JEEB> also that sounds more like a changing 3d model [17:00:41 CEST] <JEEB> rather than video [17:00:53 CEST] <JEEB> so each capture point would be its own 3-D model [17:01:44 CEST] <rafael2k> I know of the proposals in MPEG [17:01:57 CEST] <rafael2k> there are 3 working groups [17:02:30 CEST] <Accord> is it possible to take an audio file of 10.5 seconds and "compress" it to 10seconds? like speed it up just a bit [17:02:32 CEST] <Accord> to get 10s [17:02:54 CEST] <Accord> not sure what this operation is called [17:03:14 CEST] <furq> isuxx: codec or muxer [17:03:45 CEST] <rafael2k> example of color encoder for vozelized point cloud: https://github.com/digitalivp/RAHT [17:03:46 CEST] <furq> the codec is pcm_s64le or pcm_s64be, and you can mux it into m4a [17:03:48 CEST] <furq> er, mka [17:04:20 CEST] <furq> apparently wav supports it as well [17:05:20 CEST] <rafael2k> I prefer the term volumetric video then dynamic point clouds... [17:05:45 CEST] <furq> if you specifically need planar then i don't know of anything that supports it [17:06:01 CEST] <rafael2k> anyway... just thinking how to implement it to ffmpeg [17:06:11 CEST] <kepstin> Accord: if it's enabled in your ffmpeg build, the 'rubberband' filter can adjust audio speed with decent results [17:06:38 CEST] <isuxx> dunno, i was thinking more means more quality [17:06:39 CEST] <kepstin> Accord: there's a few other filters that can work too, depending on whether a pitch shift is ok. [17:07:25 CEST] <isuxx> i just gotta high tech encode my mp3 collection to better quality [17:08:08 CEST] <isuxx> is there any compression i can add for like 150kbit/sec stream [17:08:13 CEST] <kepstin> isuxx: converting from mp3 to anything else will never make the quality better, and will usually make it either worse or bigger. [17:09:13 CEST] <isuxx> i do want 64b files and 96k - more hz, for that i gotta re-encode dem [17:09:27 CEST] <isuxx> also from foreign formatsnlike youtube webm ogg [17:10:07 CEST] <kepstin> that doesn't make sense. if you need conversion to a different sample rate, your player will do that automatically when decoding normally [17:10:25 CEST] <kepstin> and afaik there's no DACs around that support 64b anyways. [17:10:39 CEST] <isuxx> i got a 64bit up to 700khz to 32f out [17:11:32 CEST] <isuxx> i need to reencode dem for gain ofnquality, but size rather not much available, like 1.5x mp3, and i need to convert dem to make em available ( at my hipraphop.ovh ) [17:12:09 CEST] <isuxx> err 64b 32fout android music player [17:12:49 CEST] <kepstin> re-encoding mp3 files cannot increase quality [17:13:22 CEST] <isuxx> eh it will like i can code [17:13:29 CEST] <kepstin> (and yes, the android audio apis support 32bit float, but the actual dac in the phone is almost certainly max 16bit) [17:13:40 CEST] <isuxx> yet i have -codec pcm_.. and -aq .1 gotta test [17:13:57 CEST] <isuxx> well it makes me feel more qualitive =p [17:14:03 CEST] <kepstin> converting mp3 to pcm is the same as decoding the mp3 [17:14:10 CEST] <kepstin> there's no quality gain possible [17:14:14 CEST] <kepstin> it just wastes space [17:14:27 CEST] <isuxx> ill test [17:14:35 CEST] <kepstin> no need to. [17:14:41 CEST] <ritsuka> yes if your source is not already 64bit 96khz there is no point encoding to it [17:14:44 CEST] <isuxx> i saw once a 64bit 'mpeg' file running on my player [17:14:57 CEST] <ritsuka> (I would say there is no point on using it either way&) [17:15:02 CEST] <isuxx> my source is crappy 44.1 non-pro encoded [17:15:32 CEST] <kepstin> yeah, given that people can't hear barely anything (at best) above 20kHz anyways, 44.1 is great. [17:16:04 CEST] <kepstin> converting a low sample rate audio to high sample rate will sound exactly the same and be larger for no reason [17:16:23 CEST] <kepstin> it can't add anything that wasn't present in the original audio file [17:16:58 CEST] <isuxx> i gotta figure out -opts first [17:17:18 CEST] <kepstin> there are no options for pcm audio, it's just raw decoded audio. it's always the same. [17:18:17 CEST] <kepstin> decoding an mp3 to pcm, sending the pcm to the phone, playing it there is *exactly the same thing* as sending the mp3 to the phone, having the phone decode the mp3 to pcm, and playing it. [17:18:36 CEST] <isuxx> i had many 'buffer underrun' ... [17:18:52 CEST] <isuxx> i gotta reencode anyway [17:19:21 CEST] <kepstin> buffer underrun can only happen during live capture or playback, reencoding won't help [17:19:21 CEST] <isuxx> so i choose 96k andn32 pref 64bit audio format, umm i halfway know [17:19:38 CEST] <isuxx> it did output so much i had to c-c [17:19:41 CEST] <kepstin> (if you get buffer underruns during playback, switching to higher sample rate/bigger files will only make it worse) [17:20:44 CEST] <isuxx> so ill try 32 rather [17:20:58 CEST] <isuxx> and no pcm but compressed [17:21:15 CEST] <Foaly> i know many players have trouble with anything more than 16 bit [17:21:21 CEST] <kepstin> recompressing audio from a lossy codec like mp3 to a different (or even same) lossy codec will reduce quality [17:22:01 CEST] <kepstin> (and most lossy codecs don't even have a concept of bit depth, they usually internally work in a sort of floating point format that's fixed for the codec design) [17:22:58 CEST] <isuxx> i dont need much compatibility rather more new style stats [17:23:53 CEST] <isuxx> fltp format [17:25:58 CEST] <kepstin> anyways, 1) converting mp3 to any other format will never raise quality (it will usually get worse), and 2) converting audio from lower to higher sample rate or bit depth will never raise quality (it will sound exactly the same) [17:26:02 CEST] <kepstin> and that's all you need to know [17:29:24 CEST] <kepstin> the only way to get a "higher quality" version is to get the audio master from before it was encoded to mp3. And even then there's no point in anything higher than 44.1 or 48kHz, since it just potentially adds ultrasonics that people can't hear and speakers/headphones won't reproduce anyways. [17:30:45 CEST] <kepstin> (using higher rates or depths during editing/mixing/mastering can makes sense so there's some extra headroom available in the software, but that's a different issue) [17:34:00 CEST] <isuxx> [mp3float @ 0x5c1a246e83c0] overread, skip -6 enddists: -4 -4 [17:35:15 CEST] <kepstin> isuxx: i'd have to see the complete ffmpeg output to be sure (don't paste it in the irc channel, use a pastebin), but that probably means that your original mp3 is corrupt. But if you can't hear any issue, probably just ignore it. [17:35:31 CEST] <Accord> kepstin: thanks, hopefully I'll find another fix for this problem [17:36:14 CEST] <Accord> I've got another weird issue, if I do ffprobe -show_frames on my input I have the first frame with negative pts but if I try to aselect=gte(pts\,0) it doesn't drop the frame [17:36:30 CEST] <isuxx> `i gottantest hearing it [17:36:38 CEST] <kepstin> Accord: ffmpeg adjusts frame timestamps to start at 0 when reading the file [17:36:46 CEST] <kepstin> (the ffmpeg cli tool, that is) [17:36:53 CEST] <Accord> kepstin: any way to prevent it? [17:37:36 CEST] <kepstin> Accord: yes, use the -copyts input option. But note this disables a bunch of other timestamp cleanups and can cause other problems depending on the input file. [17:37:51 CEST] <Accord> thanks, will try that [17:38:01 CEST] <Accord> I'm gonna set audio pts based on samples anyway [17:40:48 CEST] <Accord> ok, looking at the frames this looks fine but the last frame has pts "29.952000", and duration "0.032000", [17:40:54 CEST] <Accord> however ffmpeg reports the file size to be 30.02 [17:41:01 CEST] <Accord> why's that? [17:41:07 CEST] <Accord> I mean file duration [17:43:34 CEST] <Accord> and if I dump frames with ffprobe and add all the pkt_duration_times I get 29.984 [17:43:36 CEST] <acresearch> people i have a flowblade project that i cannot render, is it possible to render through ffmpeg? [17:44:43 CEST] <Accord> well, ffprobe -show_streams shows the correct duration.. ffmpeg -i doesn't. .I think that's a bug [18:03:07 CEST] <kepstin> Accord: there's some weird rounding in encoded audio files sometimes due to frame sizes - e.g. aac frames are 1024 samples long, and the real end of the audio is marked with metadata ("discard last X samples" or something like that) [18:47:23 CEST] <Accord> i see [21:18:52 CEST] <rmbeer> hello... [21:19:03 CEST] <rmbeer> why i can't concatenate two videos?: [21:19:11 CEST] <rmbeer> ffmpeg -i /opt/Torrent/3D/3Drender/pre.mkv -i out3.mp4 -lavfi "movie=/opt/Torrent/3D/3Drender/pre.mkv, scale=640:480, setsar=1:1 [v1]; movie=out3.mp4, scale=640:480, setsar=1:1 [v2]; [v1] [0:a:0] [v2] [1:a:0] concat=n=2:v=2:a=2 [outv] [outa]" -map '[outv]' -map '[outa]' out4.mp4 [21:19:49 CEST] <rmbeer> i no understand this error: [21:19:55 CEST] <rmbeer> Media type mismatch between the 'Parsed_setsar_5' filter output pad 0 (video) and the 'Parsed_concat_6' filter input pad 2 (audio) [21:20:00 CEST] <rmbeer> Cannot create the link setsar:0 -> concat:2 [21:20:55 CEST] <furq> don't use the movie filter [21:21:07 CEST] <furq> replace them with [0:v] and [1:v] [21:21:33 CEST] <rmbeer> but this have different size... i need convert with scale= [21:23:39 CEST] <furq> http://vpaste.net/MpGS0 [21:23:40 CEST] <furq> like that [21:23:59 CEST] <rmbeer> i fix the problem!... [21:24:26 CEST] <rmbeer> i only need set to v=1:a=1 [21:25:05 CEST] <furq> oh right yeah [21:25:17 CEST] <furq> you shouldn't use the movie filter anyway [21:25:24 CEST] <furq> that reads both input files twice for no reason [21:29:13 CEST] <rmbeer> furq, i see, thanks!... [00:00:00 CEST] --- Sat Oct 13 2018

1 0

ffmpeg-devel.log.20181011
by burek 12 Oct '18

12 Oct '18

[04:53:01 CEST] <geri> hi guys [04:59:42 CEST] <geri> hi Icedream [04:59:45 CEST] <geri> aru here? [04:59:47 CEST] <geri> need some help [07:38:33 CEST] <cone-931> ffmpeg 03Zhong Li 07master:a5e1cb9e96bc: lavu/hwcontext_qsv: Add support for AV_PIX_FMT_BGRA. [07:38:33 CEST] <cone-931> ffmpeg 03Zhong Li 07master:681aa7d14f97: lavu/qsv: make a copy as libmfx alignment requirement for uploading [09:26:23 CEST] <cone-931> ffmpeg 03Jian Yang 07master:f7affc6f70cc: avformat/dashenc: only write video streams into HLS master playlist [13:09:53 CEST] <durandal_1707> iive: you no longer use mplayer? [13:10:12 CEST] <iive> ? [13:11:41 CEST] <durandal_1707> mplayer developement seems abandoned [13:30:12 CEST] <durandal_1707> iive: so why you stopped maintaining mplayer? [13:51:16 CEST] <iive> works for me. [19:41:03 CEST] <durandal_1707> michaelni: do you have any idea why agm 3 have artifacts? do you need samples? [19:47:51 CEST] <durandal_1707> kierank: when you gonna finish prores12 ? [19:48:30 CEST] <kierank> Dunno, might just submit with the hack [21:54:07 CEST] <durandal_1707> who is irrelevant? [22:23:22 CEST] <durandal_1707> michaelni: well whatever, you can fix it any time later [22:24:40 CEST] <JEEB> nevcairiel: lol I just noticed this thing and I bet I've hit this myself as well :D http://git.1f0.de/gitweb?p=ffmpeg.git;a=commit;h=8c7369599ce2eb0894220769f2… [22:27:07 CEST] <kierank> durandal_1707: you [22:27:50 CEST] Action: JEEB loves broadcasters muxing teletext from a random separate mux into a program without modifying DTS/PTS at all [22:28:09 CEST] Action: durandal_1707 updates ignore list with 3 new entries [22:28:27 CEST] <michaelni> durandal_1707, what is agm 3 ? [22:28:48 CEST] <durandal_1707> michaelni: japanese codec, seen mailing list patch? [22:28:51 CEST] <gnafu> I feel like I'm missing at least half a conversation. [22:29:03 CEST] <kierank> JEEB: there was a mistake in spec and PTS/DTS is optional [22:29:17 CEST] <JEEB> kierank: it's OK if it's optional and not there [22:29:29 CEST] <JEEB> but then there's cases where PTS/DTS is +/- 8 hours [22:29:32 CEST] <JEEB> against the PCR [22:29:44 CEST] <kierank> Yeah not much you can do tjrtey [22:29:47 CEST] <kierank> There [22:29:49 CEST] <JEEB> yup [22:29:58 CEST] <JEEB> which is why nev's fork's patch sounds good enough [22:30:06 CEST] <JEEB> "don't trust teletext for wrap-around checking" [22:30:11 CEST] <michaelni> durandal_1707, yes i saw the patch, i just failed to associate the abbreviation [22:32:16 CEST] <michaelni> durandal_1707, iam not sure i can help but where can i find a sample for it ? [22:33:51 CEST] <durandal_1707> michaelni: somehow for AGM3 (DCT+) inter frames with mixed intra/inter block are with artifacts, intra/inter block incorrectly singnaled/interpreted, i will upload relevant sample [22:46:58 CEST] <durandal_1707> michaelni: https://0x0.st/sg6-.agm [22:48:35 CEST] <durandal_1707> michaelni: https://0x0.st/sg6o.agm [23:49:26 CEST] <akravchenko188> jkqxz: hi, it is reminder. hwcontext_amf and vf_scale_amf is pending to integrate for a long time. Do you need some assistance to apply it? [23:50:52 CEST] <akravchenko188> It would be useful to have full hw pipeline here [23:51:14 CEST] <akravchenko188> Also It is interesting to have vulkan context [23:52:11 CEST] <jamrial> atomnuker was doing vulkan afaik [00:00:00 CEST] --- Fri Oct 12 2018

1 0

ffmpeg.log.20181011
by burek 12 Oct '18

12 Oct '18

[04:49:54 CEST] <geri> hi, how can i merge two videos sound and video? [04:49:55 CEST] <geri> someone here? [04:50:42 CEST] <geri> i currently do: [04:50:46 CEST] <geri> ffmpeg -i intro.mov -i final.mp4 -filter_complex "[0:v:0]pad=iw*2:ih[bg]; [bg][1:v:0]overlay=w" -c:v libx264 -tune film -crf 16 -b:a 256k output.mp4 [04:50:57 CEST] <geri> but only 1 audio layer gets selected [04:50:58 CEST] <geri> :( [05:08:58 CEST] <kepstin> geri: by default ffmpeg picks one video and one audio track to use in output. If you want something else, you have to use the -map option to pick which tracks you want. [05:09:39 CEST] <geri> re [05:09:39 CEST] <kepstin> geri: alternately, if you want to combine both audio tracks into a single audio track, you'll have to use a filter for that (e.g. amix), which could be added to your filter chain [05:09:56 CEST] <geri> do you see that command: ffmpeg -i intro.mov -i final.mp4 -filter_complex "[0:v:0]pad=iw*2:ih[bg]; [bg][1:v:0]overlay=w" -c:v libx264 -tune film -crf 16 -b:a 256k output.mp4 [05:10:14 CEST] <geri> can you show me how to use that filter amix? [05:10:54 CEST] <kepstin> in this case you'd add it to the filter_complex option, something like "[0:v:0]pad=iw*2:ih[bg]; [bg][1:v:0]overlay=w; [0:a:0][1:a:0]amix" should do [05:11:13 CEST] <geri> let me try [05:11:41 CEST] <geri> it runs now, lets see what it produces [05:11:53 CEST] <geri> how can i move the overlayed video a bit to the right? [05:12:18 CEST] <geri> sorry left [05:13:35 CEST] <kepstin> take a look at the options to the overlay filter in the docs, it has offsets that can be adjusted. [05:13:53 CEST] <geri> how did the overlay it place now? [05:13:58 CEST] <geri> its not centered [05:15:17 CEST] <kepstin> right now, you have "overlay=w" and the first option to overlay is the x offset. So it's moving the top video to the right by 'w', which is a variable containing the width of the top video. [05:15:24 CEST] <geri> see: blob:https://imgur.com/b84f927c-4ae5-44f6-88bb-a6b749b6c551 [05:15:26 CEST] <geri> ;D [05:16:22 CEST] <kepstin> this filter chain you have would put the two videos side-by-side if they both had the same width and height [05:16:43 CEST] <geri> oh [05:16:47 CEST] <kepstin> (if that's what you want, it's better to use the "hstack" filter instead, which is less complex to use and faster to run) [05:16:50 CEST] <geri> so what i achieved is wrong? :D [05:17:00 CEST] <kepstin> i dunno what you want to achieve [05:17:03 CEST] <geri> i want the video on top [05:17:07 CEST] <geri> of the other [05:17:25 CEST] <kepstin> i can't see your image link [05:17:44 CEST] <kepstin> what are the sizes of your background video and top video? [05:18:39 CEST] <kepstin> if the top video is smaller, you'd want to use a filter setup like "[0:v][1:v]overlay=10:20" where 10 is the horizontal offset in pixels, and 20 is the vertical offset in pixels. [05:18:39 CEST] <geri> here: https://i.imgur.com/ai7SK9l.jpg [05:18:45 CEST] <geri> now u can see it [05:18:58 CEST] <geri> ? [05:28:55 CEST] <geri> is the current format good to watch on a phone? [05:28:58 CEST] <geri> video codec etc [05:29:02 CEST] <geri> .mp4 ... [05:29:18 CEST] <geri> kepstin: i will play more with the options you gave me and read more... [05:30:32 CEST] <kepstin> i'm not sure what you're trying to do, but I suspect you can get it done by using either the hstack and crop filter or overlay and pad, just a matter of getting the parameters and video order correct. [05:30:43 CEST] <geri> ok [05:30:52 CEST] <geri> is the current format good to be watched on a phone? [05:30:54 CEST] <geri> its a mp4 [05:30:59 CEST] <kepstin> the encoding settings should be fine for a phone, although you might want to use -c:a aac [05:31:28 CEST] <kepstin> the -tune film isn't really necessary [05:31:41 CEST] <geri> ffmpeg -i intro.mov -i final.mp4 -filter_complex "[0:v][1:v]overlay=0:100; [0:a:0][1:a:0]amix" -c:v libx264 -crf 16 -b:a 256k -c:a aac output6.mp4 [05:31:43 CEST] <geri> like that? [05:31:59 CEST] <kepstin> if you want to tweak the quality/size, change the value of the -crf option. larger numbers are smaller file & lower quality. [05:32:20 CEST] <geri> 16 is low compared to 100 ? [05:32:29 CEST] <geri> low quality [06:00:32 CEST] <illuminated> geri: you have that backwards 0 would be best quality and 100 would be worst quality.. but I think CRF only goes to like 56 or something [06:00:39 CEST] <illuminated> on x264 it defaults to 23 [06:08:54 CEST] <geri> h oh yeah [11:42:53 CEST] <belst> Hi, I am currently trying to create a livestream of an audio spectrum. I have it working as an mp2t stream but I want to play it in browsers. [11:42:59 CEST] <belst> my current command is: https://ptpb.pw/DANC/bash [11:43:32 CEST] <belst> I can use libvpx but encoding is WAAAY to slow with it. [13:35:24 CEST] <Adcock> Hi [13:35:34 CEST] <Adcock> I am new to ffmpeg. [13:36:19 CEST] <Adcock> I want to convert a .mkv file to ogg/theora format. [13:36:46 CEST] <Adcock> Without any loss of video or audio quality. [13:36:52 CEST] <Adcock> Please help. [13:37:41 CEST] <BtbN> That's impossible. [13:37:57 CEST] <Adcock> But why? [13:38:41 CEST] <BtbN> Every encode loses quality, unless you actually encode losslessly [13:39:15 CEST] <Adcock> I used this "FFMPEG -i asdhb.mkv -c:v libtheora -c:a libvorbis out.ogv" [13:39:58 CEST] <Adcock> But the video quality is unacceptable. [13:40:49 CEST] <JEEB> welcome to defaults [13:40:59 CEST] <Adcock> :D [13:40:59 CEST] <JEEB> what you have learned: don't use defaults for rate control [13:41:11 CEST] <Adcock> Hmmm...... [13:41:17 CEST] <JEEB> I think the global AVCodecContext default for video is bitrate && 200kbps [13:41:29 CEST] <JEEB> so yes, that will probably look like poop in addition to theora being really bad at compression [13:41:32 CEST] <Adcock> :( [13:41:43 CEST] <JEEB> various specific encoders do override that value though [13:41:45 CEST] <JEEB> such as x264 [13:41:57 CEST] <durandal_1707> belst: the showspectrum filter recently got legend option [13:42:30 CEST] <durandal_1707> to show frequency and time and other info [13:43:37 CEST] <belst> durandal_1707: nice. I'll try that. Still working on getting the resulting stream to show in an html <video> tag though :( [13:43:41 CEST] <Adcock> How can I tell ffmpeg to convert in a specific way? [13:44:44 CEST] <Adcock> Like audio biterate, sample rate? [13:45:08 CEST] <durandal_1707> belst: note: the filter output is yuv444p but web browsers mostly supports only yuv420p, so add format filter at end [13:49:13 CEST] <belst> durandal_1707: what ffmpeg version/compile flags do I need for legend? [13:50:03 CEST] <belst> I get [Parsed_showspectrum_2 @ 0x55bcd1245000] Option 'legend' not found [13:50:06 CEST] <durandal_1707> belst: latest master from git, compile flags can be what you already use [13:50:26 CEST] <belst> ah ok. so no released version yet. [13:50:32 CEST] <durandal_1707> yes [13:58:33 CEST] <Adcock> Can ffmpeg show ETA? [13:58:40 CEST] <Adcock> Or progressbar? [14:00:06 CEST] <belst> adding format=yuv420p slows down encoding to about a 4th of the previous speed. can I somehow speed this up? [14:03:20 CEST] <durandal_1707> ugh, is it that slow? [14:04:42 CEST] <belst> without it speed is about 5x [14:04:45 CEST] <belst> with it its about 1.3x [14:05:31 CEST] <belst> but i'm currently testing with urandom which is not good anyway. need to test with real data. [14:09:30 CEST] <furq> belst: you probably want to use hls/dash/some custom mse thing for streaming h264 to browsers [14:09:47 CEST] <furq> i don't know of a way to do it with just a video tag, but hls with hls.js is fairly painless [14:10:48 CEST] <furq> also you don't need any of the labels in that filterchain between aspectrum and l3 [14:10:49 CEST] <durandal_1707> belst: scale filter does not use threads, and for simple format conversion threads should be used [14:52:36 CEST] <belst> hmm. is there a way to modify the legend? I don't need the time on the left for example. [14:59:21 CEST] <durandal_1707> belst: you could modify source code.. [15:07:27 CEST] <belst> I think my selfmade "legend" is good enough for now :D thanks anywayt [15:18:35 CEST] <w1kl4s> Adcock you can use this: https://github.com/althonos/ffpb [15:18:41 CEST] <w1kl4s> Or pv pipe [15:19:19 CEST] <w1kl4s> for pv, if your normal usage looks like that: ffmpeg -i input.avi {arguments} [15:19:32 CEST] <Adcock> w1kl4s: Thanks. [15:19:33 CEST] <w1kl4s> then just pipe pv: pv input.avi | ffmpeg -i pipe:0 -v warning {arguments} [15:19:36 CEST] <Adcock> :) [15:21:22 CEST] <furq> that ffmpeg progressbar won't work if you do anything that modifies the duration of the output file [15:21:29 CEST] <furq> which is mostly why ffmpeg doesn't already have one [15:22:13 CEST] <furq> i guess pv should work but only for streamable input formats [15:22:17 CEST] <furq> it's probably not going to play nice with mp4 [15:22:56 CEST] <Adcock> :( [15:24:57 CEST] <Hello71> on Linux you can do ffmpeg & pv -d $! [15:26:12 CEST] <Adcock> ffmpeg could lock currently used file. [15:26:59 CEST] <furq> i don't think it does on *nix [15:27:11 CEST] <furq> i checked and pv | ffmpeg seems to work with mp4 as long as it's faststart [15:27:53 CEST] <BtbN> You usually know how long your video is anyway, and you already get an indication how how many frames and what time has been processed. [15:28:02 CEST] <furq> yeah it's not something i've ever missed [15:28:46 CEST] <furq> you'd also need to disable the ffmpeg stats output or else it'll mess up the pv output [15:28:53 CEST] <furq> and i'd usually rather know the average bitrate etc [15:30:06 CEST] <w1kl4s> Yeah usually if something doesn't have built in progressbar, it's for a reason [18:25:18 CEST] <q-u-a-n> Where can I read how various codecs work in laymen terms? [18:25:51 CEST] <JEEB> I recommend the H.264 book - or if you need to go even deeper EBU has a book called "Circles of confusion" [18:26:13 CEST] <JEEB> circles of confusion starts off with "what is color" [18:26:25 CEST] <durandal_1707> color is a lie [18:26:40 CEST] <q-u-a-n> ð great [18:27:00 CEST] <JEEB> https://www.amazon.com/H-264-Advanced-Video-Compression-Standard-ebook/dp/B… [18:27:07 CEST] <JEEB> this is the "H.264 book" [18:27:33 CEST] <q-u-a-n> Have you read it yourself? [18:27:41 CEST] <durandal_1707> that is for h264 codec only, other codecs may not have book(s) [18:27:59 CEST] <JEEB> yes, of course. but a lot of codecs are block based etc [18:28:36 CEST] <q-u-a-n> Oh, so what Ill learn will probably help me understand other modern codecs [18:28:58 CEST] <JEEB> ŽHEVC for example did not fall far off from AVC [18:29:14 CEST] <JEEB> as in, if you understand H.264 you can then see the parts where it got changed [18:29:20 CEST] <JEEB> then if you want the real dry stuff [18:29:26 CEST] <JEEB> you have the specifications :P [18:29:53 CEST] <q-u-a-n> Whats something I can expect to learn about if I read that book [18:30:23 CEST] <durandal_1707> how to write codecs from scratch? [21:36:31 CEST] <GuiToris> Hey, I have a question; If I have multiple inputs like ffmpeg -i %d.png -i %d.jpg -filter_complex "[0:v][1:v] overlay" output, then do I have to specify -framerate 30000:1001 before each -i or just once? [21:37:04 CEST] <furq> before both [21:37:38 CEST] <ChocolateArmpits> ehhh 30000/1001 [21:37:52 CEST] <GuiToris> ChocolateArmpits: what's wrong with that? [21:38:01 CEST] <GuiToris> or it's a slash? [21:38:02 CEST] <ChocolateArmpits> does 30000:1001 actually work? [21:38:05 CEST] <furq> it's a / [21:39:19 CEST] <GuiToris> I may have messed up twice then... the audio and the video don't match... I did : ffmpeg -framerate 30000:1001 -i singleimg.png -i sequence%d.png -filter_complex "[0:v][1:v] overlay output.mp4 [21:39:42 CEST] <GuiToris> I guess framerate before a single image doesn't make much sense [21:40:24 CEST] <GuiToris> it should be ffmpeg -i single.png -framerate 30000/1001 -i seq%d.png -filters, shouldn't it? [21:42:16 CEST] <ChocolateArmpits> GuiToris, the first image will default to 25 fps, which I guess can mess up the overlay input as that's also the main input [21:42:26 CEST] <ChocolateArmpits> overlay filter [21:42:59 CEST] <GuiToris> so even if it's a single image I should specify the 29.97 twice [21:43:06 CEST] <ChocolateArmpits> I'd really set the framerate just to be sure [21:43:49 CEST] <GuiToris> thank you, something was strange indeed, the framerate was 29.97 but the video was a bit longer than the audio [22:42:37 CEST] <JohnnyonFlame> Hello there, is there any way to force ffplay to catch up with the accumulated buffer, even if that means dropping samples? I'm having issues with an udp stream slowly accumulating and latency slowly increasing [22:42:54 CEST] <JohnnyonFlame> (the 'aq' meter slowly grows) [22:44:22 CEST] <JEEB> I don't think it's got the hacks to forget about AV sync [22:44:30 CEST] <JEEB> mpv got an option to do that methinks [22:44:40 CEST] <JEEB> https://mpv.io/manual/master/#low-latency-playback [22:46:02 CEST] <JohnnyonFlame> I'll check it out, thank you [23:00:31 CEST] <JohnnyonFlame> this is weird, if I skip ahead on a youtube video (on the server) the audio buffer on mpv (client) will grow by the dozens of kilobytes [23:00:55 CEST] <JohnnyonFlame> simply relaunching mpv is enough to fix it [23:00:59 CEST] <kerio> DOZENS :o [23:02:36 CEST] <JohnnyonFlame> eh, you're making fun of it, but it easily grows from low latency to "2 seconds" with a few taps [23:03:30 CEST] <JohnnyonFlame> I'm wondering if it's related to ffmpeg udp streams or if its a weird interaction between the ffmpeg ''server'' and the pulseaudio null sink [23:03:42 CEST] <JEEB> no idea [23:03:48 CEST] <JEEB> I've not used that mode at all myself [23:04:20 CEST] <JohnnyonFlame> thanks tho, mpv goes give me a better idea of where to poke at [23:25:29 CEST] <worstadmin> How can I see bits per pixel using ffmpeg? [23:42:25 CEST] <kepstin> worstadmin: you can determine it from the pixel format, each pixel format has a specific number of and layout of bits per component. [23:43:17 CEST] <worstadmin> ffprobe -show_entries frame=pkt_size,pkt_pts_time <input>? [23:43:26 CEST] <worstadmin> I'm new to this video stuff [23:43:32 CEST] <worstadmin> I specifically want bits per pixel [23:46:08 CEST] <kepstin> normally "bits per pixel" means "how many bits are there per pixel (or pixel component) in the decoded/raw representation of the video", and I told you how to find that out. [23:46:23 CEST] <kepstin> if you want something different, you'll have to be more clear [23:47:50 CEST] <furq> ffprobe doesn't show it [23:48:10 CEST] <kepstin> e.g. yuv420p has 8bit luminance + 2 quarter subsampled 8bit chroma planes, so it ends up being 12 bits per pixel [23:49:01 CEST] <furq> mediainfo will normally show it fwiw [23:49:27 CEST] <furq> i'm assuming you want the bpp measurement that people haven't cared about since xvid [23:49:42 CEST] <furq> and not the one for rawvideo which is what kepstin just said [23:51:19 CEST] <kepstin> oh, huh, "bits per pixel" as a measure of, uh, well, hmm. Not sure what that would be useful for. [23:51:30 CEST] <furq> there was an old rule of thumb for xvid that you should aim for 0.2bpp [23:51:52 CEST] <furq> i've not heard anyone mention it since then though [23:52:00 CEST] <kepstin> I guess if you're using the same codec with the same settings on different frame sizes, hitting the same number of bits per encoded pixel would mean approximately the same quality [23:52:02 CEST] <worstadmin> Why doesn't anyone care about it anymore? It's a good sign that someone's encoding is bad or good right? If Im encoding talking heads video at 320x180 with a frame rate of 30 and a 0.800 bpp then I'm doing something wrong [23:52:09 CEST] <kepstin> but with x264 you just use crf and it's better [23:52:24 CEST] <furq> worstadmin: because x264 has a quality-based mode that you should use instead [23:52:52 CEST] <worstadmin> That doesn't change the usefulness of BPP [23:53:04 CEST] <kepstin> I mean, it's easy enough to calculate, just divide bitrate (bit/s) by pixel rate (h * w * framerate) and you get it [23:53:17 CEST] <furq> i mean it was never a particularly useful measure because there's no such thing as a universally good bpp [23:53:22 CEST] <furq> it always depends on the content [23:53:29 CEST] <kepstin> but given the amount of tuning you can do with modern codecs, you can have different qualities at the same bpp [23:53:38 CEST] <worstadmin> Its not about universal but if Im encoding sports and I see that everyone is doing 0.200 in the industry [23:53:42 CEST] <worstadmin> Then it becomes useful [23:53:44 CEST] <kepstin> so it's meaningless aside from comparing different encodes with the same encoder and encoder settings [23:54:08 CEST] <worstadmin> Well I mean industry h.264 shit on ABR with certain BPP is pretty common and useful empirical data [23:54:23 CEST] <furq> it's not really useful unless you're using the same encoder and settings [23:54:28 CEST] <kepstin> with "encoding sports", it's just that they target a certain total bitrate because that's the size of their atsc bandwidth or whatever :/ [23:54:33 CEST] <furq> also that [23:54:55 CEST] <worstadmin> Im still a newbie so some of this is beyond me - but I'll read up [23:55:08 CEST] <kepstin> quality varies so much depending on frame content - one show will look great at low bitrate, another will block havily [23:55:12 CEST] <kepstin> so ... :/ [23:55:23 CEST] <furq> and on the encoder and settings [23:56:27 CEST] <kepstin> anyways: rules of thumb: if you need to encode to a target bitrate due to other constraints, do that, and use the slowest encoder settings you can manage. If you want a target quality, use a quality based encoder mode (like crf in x264) and use the slowest encoder settings you can manage. [23:56:47 CEST] <furq> if you're using x264 and it's for archival then all you really need to consider is preset and crf [23:56:47 CEST] <kepstin> crf isn't exactly quality, but it's closer than bpp :/ [23:56:50 CEST] <furq> and maybe tune [23:57:27 CEST] <furq> and also if that's the case then you'll pretty much always come out below 0.2bpp [23:59:45 CEST] <kepstin> worstadmin: anyways, saying "most people in the industry are using 10mbit/s at 1080p60" is exactly the same as comparing bpp, since you can calculate bpp from bitrate, frame size, and frame rate. [23:59:56 CEST] <worstadmin> Makes sense [00:00:00 CEST] --- Fri Oct 12 2018

1 0