Ffmpeg-devel-irc
Threads by month
- ----- 2026 -----
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
September 2019
- 2 participants
- 80 discussions
[00:09:53 CEST] <cone-684> ffmpeg 03Andreas Rheinhardt 07master:8b1be6e5eb85: avformat/internal: Improve documentation of ff_packet_list_get
[00:09:53 CEST] <cone-684> ffmpeg 03Andreas Rheinhardt 07master:90f647c29be3: avformat/utils: Preserve integrity of linked list
[00:09:53 CEST] <cone-684> ffmpeg 03Andreas Rheinhardt 07master:9442b0de1bf6: avcodec/mjpegdec: Unify switch statements
[00:09:53 CEST] <cone-684> ffmpeg 03Andreas Rheinhardt 07master:e12a2a2d7343: avcodec/avpacket: Improve allocating packets
[00:09:53 CEST] <cone-684> ffmpeg 03Andreas Rheinhardt 07master:ebd25a5ba532: avutil/common: Fix undefined shift
[00:09:54 CEST] <cone-684> ffmpeg 03Limin Wang 07master:216dd9fd5c5e: avcodec/v210enc: add depth parameter for WRITE_PIXELS and CLIP
[00:09:54 CEST] <cone-684> ffmpeg 03Limin Wang 07master:5c0f80d26d18: avcodec/v210enc: make 8bit and 10bit process consistent
[00:09:55 CEST] <cone-684> ffmpeg 03Limin Wang 07master:c2ab998ff38f: avcodec/v210enc: move v210_enc_8/10 function to template file
[11:33:53 CEST] <Lynne> durandal_1707: isn't that g722.1 decoder lib doing the same thing your siren decoder does?
[11:36:47 CEST] <durandal_1707> Lynne: my patch only use part of lib, so maybe another part really handles it, no coins - no patc
[11:41:58 CEST] <Lynne> maybe you should update your patch in any case?
[11:42:38 CEST] <durandal_1707> sure, after coins
[16:31:35 CEST] <cone-753> ffmpeg 03Guo, Yejun 07master:5f058dd693c4: libavfilter/dnn: separate conv2d layer from dnn_backend_native.c to a new file
[16:31:36 CEST] <cone-753> ffmpeg 03Guo, Yejun 07master:24f507301b47: FATE/dnn: add unit test for dnn conv2d layer
[16:31:37 CEST] <cone-753> ffmpeg 03Guo, Yejun 07master:48133fad056e: libavfilter/dnn: separate depth_to_space layer from dnn_backend_native.c to a new file
[16:31:38 CEST] <cone-753> ffmpeg 03Guo, Yejun 07master:b766a13dba38: FATE/dnn: add unit test for dnn depth_to_space layer
[18:49:06 CEST] <cone-753> ffmpeg 03Paul B Mahol 07master:b632ad81c5f4: avfilter/vf_v360: add ball projection format
[21:34:54 CEST] <cone-753> ffmpeg 03Marton Balint 07master:862e020f9314: avfilter/dnn: fix inclusion guard in dnn/dnn_backend_native_layer_depth2space.h
[21:34:55 CEST] <cone-753> ffmpeg 03Anthony Delannoy 07master:5e51c1aeb5b3: avformat/mpegts: add all well known PIDs and TIDs to mpegts.h
[21:34:56 CEST] <cone-753> ffmpeg 03Anthony Delannoy 07master:81bb71761ac3: avcodec: add EPG codec ID
[21:34:57 CEST] <cone-753> ffmpeg 03Anthony Delannoy 07master:a221af1f5eea: avformat/mpegts: add support for EPG extraction from mpegts
[00:00:00 CEST] --- Fri Sep 20 2019
1
0
[02:16:57 CEST] <cgarz> Does anyone know how to change the style of the ssa subtitle output when using lavfi to extract closed captions from sdtin?
[02:42:52 CEST] <cgarz> I currently have:
[02:43:03 CEST] <cgarz> [...] | ffmpeg -nostdin -y -f lavfi -i 'movie=pipe\\:0[out0+subcc]' -map s subs.ass
[02:44:53 CEST] <cgarz> How would I change that so that the border on the subs is a stroke rather than a black bar? Where/how would I insert something like: force_style='BorderStyle=1,Outline=2'
[04:28:08 CEST] <larbob> I'm currently failing to crosscompile ffmpeg
[04:28:13 CEST] <larbob> here's what I'm passing to configure right now
[04:28:15 CEST] <larbob> ./configure --enable-cross-compile --arch=k1om --target-os=linux --prefix=$HOME/microot --host-cc="icc -mmic" --host-ld="icc -mmic" --cc="icc" --cxx="icc" --ld="icc" --disable-doc
[04:28:31 CEST] <larbob> that produces a binary... but for the build machine
[04:37:42 CEST] <larbob> ah nvm. dumb mistake
[04:37:51 CEST] <larbob> should be ./configure --enable-cross-compile --arch=k1om --target-os=linux --prefix=$HOME/microot --host-cc="icc" --host-ld="icc" --cc="icc -mmic" --cxx="icc -mmic" --ld="icc -mmic" --disable-doc
[10:14:38 CEST] <Radiator> Hi all, I am trying to remux a stream to an UDP stream in C++. So far I could read the stream and get its frames with ease. Yet, the emition of frames on the other stream raises SEG FAULT. I have followed the different examples and my code should be well tuned but the results shows not. Here's a dull representation of my code :
[10:14:39 CEST] <Radiator> https://pastebin.com/XkUyNCXf It crashes at avcodec_send_frame. My frame is properlly set. My doubts are on the AVCodecContext that I am not an expert of.
[10:20:47 CEST] <Radiator> What throws me off is that none of the ffmpeg calls returns errors. Everything seems good until I send the frame. I convert that frame to YUV420P and send that converted frame. It is propelly allocated prior the sending
[10:31:23 CEST] <Radiator> Anyone struggled with avcodec_send_frame before ?
[10:41:52 CEST] <angular_mike> I generated an mp4 file from jpeg image sequence and it seemed to play ok on my desktop via a media player as well as in discord client after uploading it there. However, when I tied viewing it from an android device, I saw weird behaviour, like it would play a few frames and then just stop and/or show message "Cannot play video".
[10:42:11 CEST] <angular_mike> Any idea how I can debug this, how I can check the video generation log/analyse the output file to avoid this?
[11:35:39 CEST] <SimAV> I've got the problem, that ffmpeg's DASH output has audio and video out of sync (tested in Chrome with multiple DASH players): https://paste.debian.net/plainh/5d057867
[11:37:43 CEST] <SimAV> I'm stream-copying from icecast a matroska with multiple video and audio tracks.
[11:39:05 CEST] <SimAV> The A/V delay in the resulting DASH seems to depend on when ffmpeg starts reading from the icecast server
[11:40:07 CEST] <SimAV> I've discussed this yesterday with two icecast developers who say, this is probably a ffmpeg bug, as icecast doesn't rewrite any timestamps etc.
[11:41:28 CEST] <SimAV> Any idea how to hunt this bug further down? (See my link for a write-up what I've tested so far and links to example files)
[12:06:18 CEST] <palasso> Hello, I have some VHS tapes (of sentimental value) which I want to preserve in digital form for family use.
[12:06:18 CEST] <palasso> I have a USB capture card on the PC to which I connect the VCR. The model is this: http://www.technaxx.de/details/1604/Technaxx%20USB%202.0%20Video%20Grabber%… and it's basically the same with these models: https://linuxtv.org/wiki/index.php/Easycap
[12:06:18 CEST] <palasso> I use ffmpeg which encodes the captured video in utvideo for video and pcm_s16le for audio.
[12:06:32 CEST] <palasso> The ffmpeg command: ffmpeg -f v4l2 -standard PAL -thread_queue_size 1024 -i /dev/video0 -f alsa -thread_queue_size 1024 -i hw:1,0 -vcodec utvideo -acodec pcm_s16le -t 9000 out.mkv
[12:06:43 CEST] <palasso> I got 303 warnings in 9000 seconds (29.7 seconds per warning on average): [video4linux2,v4l2 @ 0x55cd87bd3080] Dequeued v4l2 buffer contains corrupted data (829440 bytes).
[12:06:55 CEST] <palasso> here's the output https://bpaste.net/show/pAnK
[12:07:05 CEST] <palasso> Am I doing something wrong? Why do I get these warnings?
[12:10:39 CEST] <durandal_1707> is output video fine?
[12:17:38 CEST] <palasso> durandal_1707: yes it seems to be fine
[12:18:20 CEST] <palasso> I don't know what impact those warnings have to the output file
[12:28:44 CEST] <exs> hi
[12:29:13 CEST] <exs> I use a script to record my screen and audio to record video calls. but after one minute the audio starts to speeed up automatically, is here someone who could help with that issue?
[12:32:52 CEST] <exs> https://termbin.com/py19 is my script
[12:42:53 CEST] <snooky> moin
[12:50:09 CEST] <exs> anyone who can help?
[13:13:08 CEST] <exs> that is the warnings I get https://ibb.co/fX462dX
[14:08:46 CEST] <exs> when I use ffmpeg -f pulse -ac 2 -ar 48000 -i alsa_output.pci-0000_0d_00.3.analog-stereo.monitor even then I get the error "[out_0_0 @ 0x55fe931b6e00] 100 buffers queued in out_0_0, something may be wrong."
[14:29:26 CEST] <SimAV> exs, here "ffmpeg -f pulse -ac 2 -ar 48000 -i alsa_output.pci-0000_00_1b.0.analog-stereo.monitor -c copy -t 120 /tmp/t.mkv" works fine...
[14:33:45 CEST] <klaxa> for avfoundation devices you can only display the supported modes (resolution and framerate-range) if you supply an unsupported resolution or framerate. from what i can tell there is no other way to query supported formats. is there a reason for that? would it make sense to add an option to list the supported formats?
[14:35:29 CEST] <SimAV> exs, does my command (with alsa_output.pci-0000_0d_00.3.analog-stereo.monitor of course) work for you?
[14:35:42 CEST] <SimAV> it should record audio from that input for 120 seconds
[14:37:56 CEST] <SimAV> exs, ah, if you have a close look at your output: FFMPEG suggests you to increase thread_queue_size (from 8 to a higher value). Did you try with something like -thread_queue_size 512 ?
[14:40:01 CEST] <exs> SimAV: let me try
[14:40:23 CEST] <exs> yes I tried to increase the threads, it just shows the same message
[14:41:06 CEST] <SimAV> exs, is speed still less than 1.0?
[14:41:21 CEST] <exs> SimAV: when I try your command I get a lot of: "[matroska @ 0x56235c449ec0] Non-monotonous DTS in output stream 0:0; previous: 451, current: 448; changing to 451. This may result in incorrect timestamps in the output file."
[14:41:52 CEST] <SimAV> interesting, I didn't have such problems here...
[14:42:03 CEST] <exs> SimAV: yes its weird
[14:42:53 CEST] <exs> SimAV: other ideas?
[14:43:43 CEST] <SimAV> exs, is speed still less than 1.0? (your screenshot indicates values around 0.75)
[14:45:03 CEST] <SimAV> an encoding speed less then 1.0 is bad for live/recording. Maybe try rescaling your screen before encoding.
[14:46:13 CEST] <exs> SimAV: not by purpose
[14:46:24 CEST] <exs> my screen is big, its that the issue
[14:46:30 CEST] <exs> 3440x1440
[14:46:53 CEST] <exs> can you suggest me which encodings I should use to keep it like raw as much as possible?
[14:47:00 CEST] <exs> maybe that could help
[14:47:25 CEST] <exs> but the weird stuff, I get even the warnings when I just use your test command that has nothing to do with the screen
[14:47:25 CEST] <SimAV> -c:v copy -c:a copy and a format like matroska
[14:47:46 CEST] <SimAV> my command only uses your pulse audio input
[14:48:03 CEST] <SimAV> so your pulse audio seems to behave strange
[14:49:40 CEST] <exs> damn pulse
[14:50:06 CEST] <exs> I mean I have audio from my webcam, from my monitor itself, from my headset
[14:50:09 CEST] <exs> so several sources
[14:50:41 CEST] <exs> otherwise I would just figure out how to configure alsa correctly and let pulse beside but since alsa supports only one source at the same time its hard to use it
[14:51:02 CEST] <exs> SimAV: so you think its a pulseaudio issue?
[14:51:04 CEST] <SimAV> exs, recording your screen as rawvideo at 30fps will give you something like 300-500 MB/s (so in the 2-4 GBit/s range).
[14:51:37 CEST] <exs> SimAV: yes I know huge sizees, but I do not know what I could do to handle my issues here
[14:52:06 CEST] <SimAV> ask ffmpeg to rescale your video before encoding it
[14:52:37 CEST] <SimAV> at least for the tests, to see whether this is the main issue
[14:52:48 CEST] <exs> SimAV: can you help me to figure out how to do that?
[14:57:33 CEST] <SimAV> -filter_complex 'scale=860:-1;amix=inputs=2'
[14:58:44 CEST] <exs> SimAV: with that command I get less error messages
[14:59:04 CEST] <exs> but the quality is bad :D
[14:59:16 CEST] <SimAV> exs, how loaded is your CPU?
[14:59:29 CEST] <SimAV> and is speed now (at least close to) 1.0?
[14:59:46 CEST] <exs> frame= 1157 fps= 23 q=-1.0 Lsize= 2187kB time=00:00:38.54 bitrate= 464.8kbits/s speed=0.767x
[15:00:06 CEST] <exs> my cpu is just 10%
[15:00:31 CEST] <SimAV> on one core? averaged over all cores? how many cores? etc
[15:01:03 CEST] <exs> the big issue, the longer the record, the greater the gap between video and audio
[15:01:07 CEST] <exs> they are not synced
[15:01:21 CEST] <SimAV> exs, and what are the messages you still get?
[15:01:40 CEST] <exs> AMD Ryzen 7 1700X (16) @ 3.400GHz
[15:02:09 CEST] <exs> https://ibb.co/nky7RhL
[15:02:43 CEST] <SimAV> well, that's a problem I don't know how to fix. You have two independent sources with different clocks (sound card and gpu)...
[15:03:25 CEST] <exs> SimAV: can I force ffmpeg to use the system time?
[15:06:14 CEST] <exs> I added -thread_queue_size 64448 to every -f source
[15:06:21 CEST] <exs> the thread warnings disappeared for now
[15:12:18 CEST] <cgarz> Does anyone know how to change the style of the ssa subtitle output when using lavfi to extract closed captions from sdtin?
[15:12:21 CEST] <cgarz> I currently have:
[15:12:24 CEST] <cgarz> [...] | ffmpeg -nostdin -y -f lavfi -i 'movie=pipe\\:0[out0+subcc]' -map s subs.ass
[15:12:27 CEST] <cgarz> How would I change that so that the border on the subs is a stroke rather than a black bar? Where/how would I insert something like: force_style='BorderStyle=1,Outline=2'
[15:45:05 CEST] <Radiator> What could cause a segmentation fault to avcodec_send_frame ? Every arguments are well allocated ...
[15:47:54 CEST] <exs> SimAV: have you given up?
[15:49:25 CEST] <SimAV> exs, as I said, i don't know how to sync two realtime sources with different clocks.
[15:51:09 CEST] <DHE> Radiator: if you built ffmpeg from source, default options will have debug symbols in all the libav* libraries. gdb should be able to tell you
[15:51:57 CEST] <DHE> (your compiled binary will probably be 50 MB for a debug build, or more like 20 for a regular build)
[15:52:53 CEST] <SimAV> exs, I've got a sync problem myself: https://paste.debian.net/plainh/5d057867
[15:54:13 CEST] <SimAV> however, for me A/V doesn't (seem to?) drift and the problem remains even when ffmpeg simply processes some valid matroska file...
[15:57:09 CEST] <Radiator> DHE: Sad news : I'm under windows
[15:58:22 CEST] <pink_mist> that's alright, windows can run linux too
[15:58:28 CEST] <pink_mist> just install WSL
[15:58:57 CEST] <DHE> I'm not able to help with the details here, but there must be some debug capabilities in windows as well.
[16:00:34 CEST] <Radiator> pink_mist That's not a bad idea yeah
[16:01:01 CEST] <DHE> is WSL complete enough to run gdb?
[16:01:23 CEST] <pink_mist> I believe it is
[16:01:34 CEST] <pink_mist> using a real linux kernel and all
[16:02:00 CEST] <Radiator> pink_mist Not for Windows 7 sadly :(
[16:02:15 CEST] Action: SimAV is away from windows for too long now, but back then, cygwin would have been my try
[16:02:26 CEST] <pink_mist> Radiator: ah yeah, it's only for win 10
[16:02:48 CEST] <SimAV> Radiator, cygwin runs on Windows 7 and there is gdb
[16:03:10 CEST] <SimAV> but I don't know whether you would have to compile ffmpeg/your program using the cywin gcc/whatever compiler
[16:03:47 CEST] <Radiator> SimAV I have a precompiled ffmpeg to avoid compilations
[16:03:58 CEST] <Radiator> I'll just plug in a linux and use valgind
[16:04:03 CEST] <Radiator> valgrind*
[16:04:17 CEST] <JEEB> valgrind <3
[16:04:21 CEST] <JEEB> too bad nothing like that for windows
[16:04:29 CEST] <JEEB> makes me a sad panda when writing windows specifics
[16:04:39 CEST] <BtbN> Visual Studio has a very similar tool
[16:05:14 CEST] <Radiator> There was Purify for a timebut I can't find it anymore
[16:05:31 CEST] <DHE> valgrind probably won't help unless you've done a fundamental memory management error (uninitialized memory, or using a freed pointer). plus it's catastrophically bad for performance. just run it under gdb, let it crash, and look at the line that it faulted on
[16:06:05 CEST] <Radiator> BtbN Really ? I couldn't find any thing similar to it in visual studio 2017.
[16:06:21 CEST] <BtbN> You might need the Enterprise/Ultimate edition
[16:06:38 CEST] <Radiator> DHE The problem is that I don't have debug lib of ffmpeg
[16:06:52 CEST] <Radiator> For windows though
[16:12:24 CEST] <SimAV> BtbN, JEEB, DHE, any idea regarding my matroska/DASH issue?
[16:12:48 CEST] <JEEB> no idea, best bet I guess is to check the -debug_ts output coupled with -v verbose
[16:12:55 CEST] Action: DHE does not answer to requests like that
[16:12:57 CEST] <JEEB> it should output multiple lines for each packet read from the input etc
[16:16:20 CEST] <SimAV> DHE, how could I improve my request? ;)
[16:17:44 CEST] <SimAV> JEEB, do you have a suggestion what to look for exactly? I stared at the -debug_ts output yesterday but wasn't able to spot something that sounded strange to me...
[16:18:01 CEST] <DHE> SimAV: what I mean is I don't accept people walking up to me explicitly asking for specific help
[16:18:23 CEST] <SimAV> DHE, ah, ok. I'm sorry then...
[16:18:28 CEST] <DHE> I would have replied to your undirected question if I was at the keyboard and knew the answer. my silence means I was away and/or don't know
[16:23:13 CEST] <JEEB> same here basically :P I can only give VeryGenericAdvice
[16:23:30 CEST] <SimAV> :/
[16:26:29 CEST] <DHE> I give advice where I can. That does tend to be a bit narrowly scoped to "what I've done myself", and anything that's generic enough. hardware capture is beyond my knowledge for example, beyond some x11grab
[16:26:57 CEST] <DHE> also I'm currently at the office so my attention is limited
[16:29:07 CEST] <SimAV> DHE, it's all fine... I just wanted to know whether my question was "in the wrong format" like better paste everything I did instead of linking commands and description etc, or repeating the link or ...
[16:31:47 CEST] <palasso> Hello, reposting in case anyone knows the solution
[16:31:51 CEST] <palasso> I have some VHS tapes (of sentimental value) which I want to preserve in digital form for family use
[16:32:00 CEST] <palasso> I have a USB capture card on the PC to which I connect the VCR. The model is this: http://www.technaxx.de/details/1604/Technaxx%20USB%202.0%20Video%20Grabber%… and it's basically the same with these models: https://linuxtv.org/wiki/index.php/Easycap
[16:32:11 CEST] <palasso> I use ffmpeg which encodes the captured video in utvideo for video and pcm_s16le for audio
[16:32:20 CEST] <palasso> The ffmpeg command: ffmpeg -f v4l2 -standard PAL -thread_queue_size 1024 -i /dev/video0 -f alsa -thread_queue_size 1024 -i hw:1,0 -vcodec utvideo -acodec pcm_s16le -t 9000 out.mkv
[16:32:29 CEST] <palasso> I got 303 warnings in 9000 seconds (29.7 seconds per warning on average): [video4linux2,v4l2 @ 0x55cd87bd3080] Dequeued v4l2 buffer contains corrupted data (829440 bytes)
[16:32:37 CEST] <palasso> here's the output https://bpaste.net/show/pAnK
[16:32:48 CEST] <palasso> Am I doing something wrong? Why do I get these warnings?
[16:36:41 CEST] <WaV> Does anyone know of a way to smooth out the motion artifacts on H264 and H265 videos? Kinda looks like interlacing, but I've turned on deinterlacing in my video player. Ubuntu Linux here and have used mpv, vlc and smplayer
[16:36:52 CEST] <WaV> All do the same thing
[16:39:03 CEST] <pink_mist> what kind of motion artifacts
[16:39:38 CEST] <WaV> Looks like horizontal blurry lines during fast motion
[16:44:09 CEST] <DHE> could be interlacing, but if it's not properly marked in the video then the deinterlacer might not even do anything. or the source material could have already blur'd them and now it's basically too late
[16:45:06 CEST] <WaV> I tried saving several snapshots via mpv, but interestingly enough I cannot capture what I'm trying to describe.
[16:45:55 CEST] <DHE> use '.' (period) to frame step
[16:46:06 CEST] <furq> mpv's default deinterlacing ignores interlacing flags iirc
[16:46:09 CEST] <furq> it's just either on or off
[16:55:59 CEST] <SimAV> JEEB, OK, I tried to inspect the timestamps closely using
[16:56:01 CEST] <SimAV> ffmpeg -y -debug 7 -debug_ts -i DLA_3500_streamdump_largequeue_04.mkv -map 0 -c copy -f matroska /tmp/t.mkv 2>&1 | grep '^demuxer ' | cut -d ' ' -f 1,3,4,10
[16:57:22 CEST] <SimAV> it turns out, for the 'bad' file, the first pkt_pts_time of a video track is 0.96, so nearly a second.
[16:57:45 CEST] <SimAV> in other words, there is approximately a second of audio, before video starts.
[16:58:50 CEST] <SimAV> for the original file, I find pkt_pts_time:0.021 for the first video packets, which is less than a frame, as the video has 25fps.
[17:00:04 CEST] <SimAV> for the "better" file, i.e. where I didn't perceive obvious audio/video sync issues in Chrome, the pkt_pts_time for the first video packets is 0.04, so '1 frame'
[17:02:06 CEST] <SimAV> using
[17:02:07 CEST] <SimAV> ffmpeg -y -debug 7 -debug_ts -i DLA_3500_streamdump_largequeue_03.mkv -map 0 -c copy -f matroska /tmp/t.mkv 2>&1 | grep '^demuxer ' | grep -o -e 'pkt_pts_time:[^ ]*' | uniq -c | less
[17:03:09 CEST] <SimAV> I found that there are pkt_pts_time values, that are equal for packets of all audio and video streams
[17:03:09 CEST] <kepstin> SimAV: so your input file has this large timestamp gap between audio and video start?
[17:03:22 CEST] <SimAV> kepstin, yes.
[17:03:37 CEST] <SimAV> kepstin, see my link and the links therein to get these files
[17:03:57 CEST] <kepstin> huh. my guess is that it was cut out of a longer file with the audio starting at the requested point and the video starting at the next keyframe after the requested point.
[17:04:48 CEST] <kepstin> easiest fix is probably to use -ss with the time of the first video frame, so ffmpeg can skip the extra audio
[17:05:21 CEST] <SimAV> kepstin, ffmpeg reads from an icecast server, so its a live-stream problem
[17:05:55 CEST] <SimAV> I would need an option for ffmpeg to discard frames, until there are packets for all streams, that have the same PTS
[17:06:43 CEST] <SimAV> kepstin, https://paste.debian.net/plainh/5d057867 << links the files and explains how I got there
[17:07:22 CEST] <kepstin> SimAV: so you've reported the chrome player bug upstream, right?
[17:07:49 CEST] <SimAV> kepstin, not yet, as I'm still unsure where the bug actually lies
[17:08:07 CEST] <SimAV> and how the bug exactly looks like...
[17:09:11 CEST] <kepstin> i'd have to take a look at the hls playlist and segments, which i don't have time to do atm, but if the timestamps there are fine then it's probably a bug in chrome where it's not taking into account the relative audio/video timestamps for syncing the streams.
[17:09:12 CEST] <SimAV> kepstin, I did ask in #chromium and #chromium-support some hours ago but no reaction there yet...
[17:12:41 CEST] <SimAV> kepstin, I'm not sure I interprete the timescale/t stuff correctly, but its timescale="12800" & t="12288" for video (12288/12800 == 0.96) and timescale="48000" & t="912" for audio (912/48000 == 0.019)
[17:12:55 CEST] <SimAV> so these values sound reasonable for me
[17:14:26 CEST] <SimAV> kepstin, nevertheless as a quick fix I would like ffmpeg to drop packets from input UNTIL the pts difference between the packets of all streams is zero
[17:15:22 CEST] <kepstin> SimAV: the ffmpeg cli tool does not support doing that.
[17:15:47 CEST] <kepstin> so it wouldn't be a quick fix at all :)
[17:16:19 CEST] <SimAV> well, compared to getting chrome fixed and all browsers using the chrome engine recompiled and shipped to the users: probably yes :D
[17:16:39 CEST] <kepstin> if you're re-encoding there's some hacks you can do with filters, e.g. use the fps start_time option to make the filter fill the gap with repeated frames.
[17:16:43 CEST] <kepstin> but that doesn't work with -c copy
[17:18:11 CEST] <kepstin> the required changes to the ffmpeg cli to add an option to drop audio packets until a video keyframe is present are in a part of the codebase people don't like working on, and it's particularly tricky for cases like "what if there's multiple tracks with misaligned keyframes?" and things like that.
[17:19:15 CEST] <SimAV> another workaround I could imagine is to make ffmpeg produce a matroska stream where each cluster therein spans from one keyframe in all streams (e.g. the very beginning) to just before the next case this happens
[17:19:42 CEST] <SimAV> (in my case I control the input of the icecast-server, too)
[17:20:04 CEST] <Radiator> God I love valgrind
[17:20:13 CEST] <Radiator> Makes everything easier
[17:20:17 CEST] <SimAV> Radiator, problem found? (:
[17:20:29 CEST] <Radiator> So, thanks to valgrind I identified the issue yeah !
[17:20:36 CEST] <Radiator> Miss aligned data !
[17:20:38 CEST] <Radiator> In the frmae
[17:20:41 CEST] <Radiator> frame*
[17:20:53 CEST] <kepstin> SimAV: honestly, the easiest fix would be to hack the hls *muxer* to throw out audio before the first video keyframe.
[17:20:55 CEST] <SimAV> icecast starts transmitting to a client only at borders of the matroska-container
[17:21:12 CEST] <SimAV> kepstin, its dash in my case, but ok...
[17:21:16 CEST] <kepstin> oh, wait, this is dash
[17:21:19 CEST] <kepstin> but similar idea
[17:21:38 CEST] <SimAV> kepstin, not only first video keyframe, but video keyframe in all video tracks
[17:21:56 CEST] <kepstin> SimAV: what if the video keyframes aren't aligned?
[17:21:58 CEST] <SimAV> I've got 10 videotracks (5 times h264, 5 times vp8) in one matroska container
[17:22:13 CEST] <SimAV> kepstin, keep on throwing out until this condition is encountered
[17:22:37 CEST] <WaV> I've got a small 2 second clip of the motion artifacts I'm talking about | https://wetransfer.com/downloads/18a228bd8822957b41c3f9adc45d07832019091915…
[17:22:39 CEST] <kepstin> SimAV: if the video keyframes aren't aligned, then there's always going to be one video that starts later, or one that starts early. waiting until they all align perfectly might take a long time :/
[17:22:40 CEST] <SimAV> for fixed gop sizes, this will happen sooner or later
[17:23:04 CEST] <SimAV> kepstin, ok, you are right, they might be constantly off...
[17:23:04 CEST] <kepstin> with fixed gop they'll always all be perfectly aligned, or never line up ever :)
[17:23:51 CEST] <SimAV> ok, then I would need two options. one for waiting for the first video keyframe, and a "I'm feeling lucky" one for waiting for keyframes in all streams ;)
[17:23:55 CEST] <WaV> If anyone watches it, pay attention to the dog running.
[17:24:59 CEST] <kepstin> WaV: that's tearing during playback, it's not an issue with the video
[17:25:01 CEST] <SimAV> kepstin, I would be fine with any other muxer as well, it doesn't have to be DASH, as long as i can pipe the output back into another ffmpeg which finally creates the DASH
[17:25:05 CEST] <kepstin> WaV: it's a video driver bug
[17:25:19 CEST] <WaV> kepstin: Any way to smooth it out?
[17:25:46 CEST] <kepstin> WaV: depending on the graphics driver you're using and whether you're in wayland or x there might be options you can do to improve it
[17:26:07 CEST] <SimAV> WaV, did you try more than a single monitor / graphics card?
[17:26:15 CEST] <WaV> nvidia-drivers-390 for Quadro P1000
[17:27:04 CEST] <kepstin> WaV: with nvidia proprietary drivers, https://wiki.archlinux.org/index.php/NVIDIA/Troubleshooting#Avoid_screen_te…
[17:27:08 CEST] <WaV> SimAV: I've tried two different computers - one of which is older with on board graphics. It does the same thing. If memory serves me correctly, I do not believe it happens in Windows.
[17:27:43 CEST] <kepstin> with intel integrated graphics, it shouldn't be an issue if you use a wayland session. In x, there's some Xorg.conf options you can set to reduce the issue.
[17:28:48 CEST] <SimAV> WaV, and you are sure, your display mode is not set to interlaced?
[17:29:05 CEST] <kepstin> WaV: the basic core of the issue is that the video player is updating the video frame while the graphics card is in the middle of sending the image to the monitor - so it sends part of the previous frame, then part of the next frame.
[17:29:58 CEST] <kepstin> the effect looks *very* different from combing (an interlacing issue), and shouldn't be confused
[17:30:38 CEST] <kepstin> if this was an interlacing issue, you wouldn't get a chunk of one frame above a chunk of the next frame - instead you'd get alternating thin lines from two different frames uniformly over the whole picture
[17:31:04 CEST] <SimAV> WaV, forget everything i said, I should have watched your clip earlier...
[17:31:32 CEST] <kepstin> that's also why it doesn't show up in a screenshot or with the video paused
[17:31:51 CEST] <SimAV> didn't expect it to be a "hardware screenshot" ;)
[17:31:54 CEST] <kepstin> since a screenshot won't get the half-updated screen, and when it's paused there's no updates going on at all
[17:32:18 CEST] <SimAV> WaV, kepstin is absolutely right...
[17:32:42 CEST] <furq> https://github.com/mpv-player/mpv/wiki/FAQ#Tearing
[17:33:29 CEST] <kepstin> last time i was using the nvidia proprietary driver i used the force full composition pipeline option with success.
[17:34:08 CEST] <kepstin> amusingly, this is only really visible if you're using an opengl compositing window manager like gnome-shell in an x11 session
[17:34:18 CEST] <kepstin> just something about that stack doesn't handle vsync right
[17:34:44 CEST] <WaV> SimAV: How can I be sure that it isn't set to interlaced?
[17:34:57 CEST] <kepstin> wayland is fine (but is tricky to get working on nvidia proprietary stuff), and using a non-compositing wm is fine in x11.
[17:35:09 CEST] <kepstin> WaV: it's not, don't worry about it.
[17:35:18 CEST] <WaV> kepstin: I see. Let me try that.
[17:36:10 CEST] <angular_mike> I opened a support ticket with discord staff regarding my mp4 issue
[17:36:21 CEST] <angular_mike> anything in the meantime?
[17:37:18 CEST] <furq> what mp4 issue
[17:37:31 CEST] <SimAV> wabbits, as I said, forget *everything* I wrote. I was assuming you had indeed interlacing problems, not tearing...
[17:37:39 CEST] <SimAV> sorry, WaV of course...
[17:38:08 CEST] <wabbits> its forgotten :)
[17:38:21 CEST] <WaV> I do not have the option to Force Composition Pipeline or Force Full Composition Pipeline in the nVidia GUI settings. I ran the command via CLI and it doesn't appear to have resolved the issue when I closed and reopened mpv.
[17:38:31 CEST] <WaV> SimAV: Gotcha, thank you.
[17:39:19 CEST] <furq> WaV: https://wiki.archlinux.org/index.php/NVIDIA/Troubleshooting#Avoid_screen_te…
[17:39:29 CEST] <WaV> It should be noted that nothing was printed to stdout when I ran the command.
[17:39:33 CEST] <WaV> furq: checking.
[17:39:39 CEST] <SimAV> kepstin, if chrome really "simply" doesn't honor the audio/video delay according to the dash manifest, I guess one could create a file, where video starts a second early and we'll have again audio/video sync problems...
[17:41:11 CEST] <kepstin> SimAV: that's not gonna happen with your use case of starting to read a stream from a random point, since you can start decoding audio at any frame it'll always either be matched (or nearly so), or have the video late.
[17:46:29 CEST] <SimAV> kepstin, https://ffmpeg.org/ffmpeg-bitstream-filters.html#noise << this sounds somewhat close to what I would need?
[17:47:38 CEST] <SimAV> I'm not sure about the "without damaging the container" part though...
[17:50:30 CEST] <angular_mike> furq: I generated an mp4 file from jpeg image sequence and it seemed to play ok on my desktop via a media player as well as in discord client after uploading it there. However, when I tied viewing it from an android device, I saw weird behaviour, like it would play a few frames and then just stop and/or show message "Cannot play video".
[17:53:59 CEST] <another> meh
[17:54:02 CEST] <angular_mike> ?
[17:54:18 CEST] <furq> it used to tell a bot to tell you to pastebin the command and full output
[17:54:25 CEST] <furq> but you should probably just post the output of ffprobe file.mp4
[17:55:37 CEST] <SimAV> kepstin, ok, maybe bitstreamfilters are not the place to look at, as an AVPacket probably doesn't know anything about the stream it is in... :D
[17:56:01 CEST] <angular_mike> pastebins seem to be dying nowadays
[17:56:20 CEST] <SimAV> https://paste.debian.net
[17:56:25 CEST] <angular_mike> https://pastebin.com/2BPikiTJ here is the ffprobe output
[17:58:05 CEST] <SimAV> kepstin, as you suggested adding the packet dropping to a muxer, is there already any muxer that drops some packets?
[17:58:11 CEST] <furq> angular_mike: it's probably because it's yuvj420p
[17:58:37 CEST] <furq> add -pix_fmt yuv420p when encoding
[17:58:49 CEST] <angular_mike> whats's that gain
[17:58:54 CEST] <furq> some old chrome had issues with that so i'm guessing discord is using an old cref or whatever
[17:59:14 CEST] <furq> yuvj420p is full/pc/jpeg range which is less well supported
[17:59:53 CEST] <angular_mike> ok ill try this then `ffmpeg -framerate 480 -f image2 -pix_fmt yuv420p -i video_dump/image%4d.jpg out.mp4`
[18:00:14 CEST] <furq> after -i
[18:00:24 CEST] <angular_mike> oh
[18:00:47 CEST] <angular_mike> `deprecated pixel format used, make sure you did set range correctly`
[18:00:51 CEST] <angular_mike> it shows a warning now
[18:01:25 CEST] <furq> it would have shown that before
[18:01:37 CEST] <furq> that's from the decoder so you can ignore it anyway
[18:03:14 CEST] <angular_mike> well i just tried it out and results seem the same
[18:03:58 CEST] <SimAV> -discard listed under https://ffmpeg.org/ffmpeg.html#Advanced-options seems somewhat close, too, but still definitely distinct from what I need...
[18:04:19 CEST] <furq> angular_mike: in that case it probably doesn't like the framerate
[18:04:26 CEST] <angular_mike> oof
[18:04:40 CEST] <angular_mike> i bumped it up cause i wanted the video to play faster
[18:04:47 CEST] <furq> add -r 60 after -i
[18:08:08 CEST] <angular_mike> hm that actually seems to have helped
[18:08:15 CEST] <angular_mike> now what did it do exactly?
[18:09:06 CEST] <SimAV> angular_mike, it throws frames out, such that only 60 per seconds "come through" into the final video
[18:09:59 CEST] <angular_mike> so, without it the player just tries to play them all at extremely high speed?
[18:10:01 CEST] <SimAV> so not every .jpg of your input will be a frame in the output .mp4 (as these would be more than your device is probably able to decode in realtime during playback)
[18:10:29 CEST] <SimAV> angular_mike, exactly.
[18:10:38 CEST] <furq> angular_mike: the player would have dropped them unless you have a 480fps display
[18:10:39 CEST] <angular_mike> I see thanks
[18:10:50 CEST] <furq> so you might as well do it up front
[18:10:54 CEST] <furq> save yourself some filesize and compat issues
[18:11:05 CEST] <angular_mike> my tablet is 1080p
[18:11:32 CEST] <SimAV> that's resolution. Your problem is framerate
[18:11:49 CEST] <SimAV> (the number of different images your tablet can show per second)
[18:13:50 CEST] <angular_mike> ahh right
[18:29:56 CEST] <SimAV> kepstin, https://github.com/FFmpeg/FFmpeg/blob/master/doc/examples/remuxing.c looks very promising...
[18:30:49 CEST] <SimAV> maybe I can build a small "pass through after condition is met" program, that I can plug in using good old pipes at the front and back... :D
[18:32:08 CEST] <SimAV> Thanks so far to all, I'll be back later...
[18:32:32 CEST] <kepstin> well, if you're building a tool using ffmpeg libs you might as well skip the whole ffmpeg cli, just have it read directly from icecast, write dash
[18:40:09 CEST] <WaV> I feel like an A-hole because I don't remember your nicks, but thank you to the people involved in directing me to the screen tearing FAQ on Arch's website. It got me squared away! :)
[18:44:26 CEST] <WaV> Seriously, thank you. That was the one thing about this new laptop that was just irking me.
[18:57:53 CEST] <WaV> I remember now: furq kepstin and SimAV who is no longer here. Cheers!
[18:58:06 CEST] <SimAV> :D
[18:59:11 CEST] <zyme> What tearing issue were you getting on what kind of new laptop?
[18:59:56 CEST] <WaV> motion teating on a Lenovo P52 with a nVidia Quadro P1000
[19:00:01 CEST] <WaV> tearing*
[19:01:01 CEST] <WaV> resolved by setting PRIME syncronization to 1
[19:01:57 CEST] <gogs_bread> [help needed with ffprobe] - I am trying to write CODECs parameter for a HLS playlist (https://tools.ietf.org/html/rfc8216#section-4.3.4.2) CODECs parameter complies with rfc6381 (https://tools.ietf.org/html/rfc6381#page-8) eg: mp4a.40.2, avc1.64001F. Is it possible to use `ffprobe` to get(or infer) these rfc compliant values? I see that `mp4box`
[19:01:58 CEST] <gogs_bread> has a field called "RFC6381 Codec Parameters" that exactly does this.
[19:04:26 CEST] <cards> Does ffmpeg contain a quality industry popular upscaler? Or does anyone know what upscaler that rights-holders are simply cranking their DVDs through to make Blurays?
[19:06:11 CEST] <cards> I made the mistake of collecting earlier American animated features on Bluray, cropped and upscaled to 16:9 at 1080p without any attention or love, when I should have been collecting the DVDs and upscaling them myself at 4:3
[19:09:26 CEST] <furq> you could just not upscale them at all
[19:10:37 CEST] <cards> i could, but it's easier on cheaper tvs if it's already upscaled to 1080
[19:10:46 CEST] <cards> just looks better
[19:10:57 CEST] <furq> with that said wouldn't early american animated features be on 35mm anyway
[19:11:10 CEST] <cards> i don't know too much about upscalers, admitidly, but some are pretty great
[19:11:17 CEST] <furq> so presumably they just rescanned it and then did a lazy crop job
[19:11:39 CEST] <cards> depends. much of it was rescanned at 4:3 though and then the films burned or spirited away
[19:11:48 CEST] <furq> that would also make sense
[19:12:05 CEST] <cards> nobody is recanning anything from the 90's or earlier onto Bluray, again, since it was done for the DVD
[19:12:15 CEST] <cards> they really don't care or want to
[19:12:28 CEST] <cards> with few exceptions
[19:12:45 CEST] <cards> but the butcher crop jobs are horrible
[19:12:58 CEST] <cards> character heads missing, feet missing, etc
[19:13:13 CEST] <cards> important elements of the background missing
[19:13:35 CEST] <furq> if i had to guess i'd say they're rescanned but they were originally academy ratio
[19:13:44 CEST] <furq> unless there's no longer a source available
[19:14:22 CEST] <cards> i'm just seeing the DVD slapped onto Bluray. same grain and imperfection anomalies
[19:14:37 CEST] <furq> with that said it's academic unless you also have access to the source and can rescan them and then not matte them
[19:15:42 CEST] <cards> which i don't. but since the DVD in many or most cases contains more actual animated material, i'm switching to collecting DVDs now
[19:16:13 CEST] <FooNess> They'd need to get a proper 1080p version from the original cels or whatever.
[19:16:26 CEST] <FooNess> I wish Sonic SatAM had that done, but it's unlikely.
[19:16:36 CEST] <furq> well this is early stuff so it'd have been projected in cinemas on 35mm
[19:16:58 CEST] <furq> stuff produced for tv is much trickier
[19:17:39 CEST] <furq> either way based on my experience with upscaled blurays they're not using any fancy upscaler
[19:18:04 CEST] <furq> of course it's hard to tell when they insist on running the denoiser until everyone looks like they're made of wax
[19:18:50 CEST] <FooNess> I know things like waifu2x exist.
[19:26:11 CEST] <kepstin> there's definitely been cases of *particularly bad* upscales, where something like a basic cubic upscaler would have looked better :/
[19:27:39 CEST] <kepstin> and denoising often means you get banding, while bluray usually has enough bitrate to just leave the noise in
[19:45:01 CEST] <Sirisian|Work2> Anyone know why lld-link would fail to include bcrypt.lib and other libraries when linking? https://pastebin.com/QXRLmxXG I'm running the Chromium ninja build scripts for ffmpeg (in msys2 mingw64) to build a custom one for Windows (using clang-cl). The library paths are setup with ./configure so it should be able to find them. (I even have pkg-config installed though it's not needed).
[20:43:13 CEST] <cards> FooNess: was SatAM anything wider than NTSC? I thought it was made for NTSC/PAL so they wouldn't have made a theatrical cut
[20:44:02 CEST] <cards> Though I suppose many panning backgrounds could have been cut to a 16:9 or wider
[20:44:51 CEST] <cards> nobody really kept animationc cells. it always seems to be sold off to fans.
[20:45:52 CEST] <cards> that said, computers are really amazing, and can reconstruct and repaint cell animation. reconstitute backgrounds and virtually recut it wider than it was
[20:46:19 CEST] <cards> if only ffmpeg added such a switch ;)
[20:49:58 CEST] <cards> i'm kind of annoyed that the Bluray for The Fifth Element decided to postage-stamp the titty scenes to censor them, instead of include them. You'll need the european 4x3 DVD to see her boobs.
[21:13:31 CEST] <FooNess> cards, I'd have to check my copy, hold on.
[21:14:24 CEST] <ricemuffinball> what soundcard do people recommend for using with ffmpeg?
[21:20:53 CEST] <kepstin> it depends entirely on what you're trying to do with the sound card?
[21:21:06 CEST] <FooNess> cards, so it seems two editions exist -- a first one in the US (NTSC) and then a UK release (PAL).
[21:21:12 CEST] <FooNess> I have the American one.
[21:21:16 CEST] <furq> literally any soundcard that you have working drivers for
[21:21:25 CEST] <FooNess> So, yeah -- NTSC/PAL, as you said.
[21:22:23 CEST] <cards> ricemuffinball: ffmpeg doesn't use sound cards as far as I'm aware. So, none works.
[21:22:36 CEST] <kepstin> ricemuffinball: for recording live music or voice with direct instrument hookups and xlr mics, some sort of usb audio interface with the appropriate connectors would be good, i suppose.
[21:23:01 CEST] <cards> FooNess: titties in yours?
[21:23:08 CEST] <kepstin> cards: ffmpeg is perfectly capable of doing live audio capture from various types of sound cards
[21:23:10 CEST] <cards> i'm guessing prolly only on the PAL edition
[21:23:15 CEST] <FooNess> cards, what?? I mean SatAM. O.o
[21:23:19 CEST] <ricemuffinball> kepstin: does pCI/PCI-E audio interface not exist anymore?
[21:23:33 CEST] <cards> kepstin: he's been asking the same question for like 5 days. he never once mentioned anything about live audio feeds.
[21:23:52 CEST] <cards> FooNess: ooh, right :) lol
[21:24:05 CEST] <cards> if only SatAM had titty scenes
[21:24:10 CEST] <kepstin> ricemuffinball: they're uncommon, the sound integrated into modern pc boards is good enough for most playback purposes, and for special use cases, external hardware is more popular since people use laptops a lot.
[21:24:16 CEST] <FooNess> cards, considering that this a G-rated children's cartoon, that would have been very interesting ...
[21:24:36 CEST] <cards> Sorry, thought you were replying to the Fith Element
[21:24:41 CEST] <FooNess> Heh, I see now.
[21:24:49 CEST] <FooNess> I didn't see that message before, and I was freaking out.
[21:25:25 CEST] <cards> But I bet Bunny has some nice galvanized nipples
[21:25:35 CEST] <FooNess> Oh, my stars.
[21:25:40 CEST] <cards> lol
[21:26:36 CEST] <kepstin> ricemuffinball: honestly, in a lot of modern use cases the "sound card" is just part of the graphics card that sends the digital audio signal over an hdmi cable along with the video.
[21:26:42 CEST] <cards> I still haven't found a nice delaced version of SatAM on the web. Do you know of one, FooNess?
[21:26:51 CEST] <FooNess> Speaking of; the mastering Shout! Factory did when transferring to DVD has awful telecining and interlacting.
[21:26:53 CEST] <FooNess> LOL
[21:26:57 CEST] <FooNess> I was JUST commenting on that.
[21:27:36 CEST] <FooNess> No, unfortunately I think this is the best we have -- you'd need to get the original film or cels to remaster it. Having said that, I do think ffmpeg has detelecine filters.
[21:27:52 CEST] <cards> I've seen it undone very professionally, but I'm no expert at this. Apparently quite doable in ffmpeg / handbrake
[21:28:11 CEST] <FooNess> Right -- maybe also avisynth, or whatever that program was called.
[21:28:22 CEST] <cards> one guy delaces ntsc cartoons from 30 fps to 60 fps with the extra frames
[21:28:42 CEST] <cards> then it's a matter of upscaling them nicely
[21:28:56 CEST] <FooNess> You mean with interpolation, I guess?
[21:29:02 CEST] <FooNess> Or do you mean resolution upscaling.
[21:29:04 CEST] <cards> again, no expert here
[21:29:12 CEST] <cards> oh, i mean upscaling the resolution
[21:29:33 CEST] <cards> upscalers are quite good and it just looks better on our 1080 screens
[21:29:47 CEST] <cards> unless you own a good samsung tv that does it for you
[21:29:52 CEST] <FooNess> Yeah; I think neural network-based upscalers could maybe do something.
[21:29:56 CEST] <cards> VLC and an acer monitor sure don't
[21:30:05 CEST] <FooNess> Think something like waifu2x.
[21:30:13 CEST] <FooNess> I guess that's more for anime-style animation.
[21:30:16 CEST] Action: kepstin notes that for animation mastered on 24fps or a division thereof, e.g. 12 fps ("on twos"), you'd get judder converting to 60fps, a proper detelecine would give 24fps
[21:30:18 CEST] <FooNess> Rather than western styles.
[21:31:22 CEST] <cards> kepstin: remind me what the interlacing on NTCS looks like. was it something like 1+2 2+3 3 4+5 or something
[21:31:29 CEST] <cards> or am I thinking about something else
[21:31:43 CEST] <FooNess> The interlacing/telecine on SatAM seems almost random, though.
[21:31:54 CEST] <FooNess> For some reason, like it doesn't seem to follow those industry standards.
[21:31:59 CEST] <cards> i don't think it's random, it's just not every frame.
[21:32:13 CEST] <FooNess> Yeah, like, the automatic ffmpeg settings don't catch it all.
[21:32:18 CEST] <cards> it's not supposed to be every frame from what i remember. just 3 out of 5 frames maybe
[21:32:35 CEST] <FooNess> Yeah, but I'm saying it isn't every 3 out of 5 frames, it seems to be something else iirc
[21:32:39 CEST] <FooNess> And the number isn't fixed.
[21:32:43 CEST] <kepstin> the most common telecine pattern on ntsc for 24 frames per second to 30 fields per second is to repeat every 4th field and extra time
[21:32:53 CEST] <kepstin> it's called a 2:3 pattern
[21:32:55 CEST] <FooNess> Hmmm.
[21:33:07 CEST] <kepstin> you're turning every 4 fields into 5 fields
[21:33:27 CEST] <kepstin> there's a diagram on wikipedia that shows it well
[21:33:36 CEST] <FooNess> I see.
[21:34:13 CEST] <kepstin> https://en.wikipedia.org/wiki/Telecine#/media/File:32pulldown.svg this one
[21:35:25 CEST] <FooNess> So the first two frames aren't interlaced, the next two are, and the last one isn't.
[21:35:45 CEST] <kepstin> all the resulting frames are interlaced, in that they're made out of two fields
[21:35:46 CEST] <FooNess> C is "spread over" B, C and D.
[21:35:48 CEST] <cards> kepstin: which is generally better to use as a source? NTSC or PAL?
[21:35:51 CEST] <FooNess> kepstin, ah, I see.
[21:36:01 CEST] <kepstin> FooNess: however, only frames 3 and 4 have visible combing
[21:36:06 CEST] <furq> cards: pal
[21:36:15 CEST] <FooNess> kepstin, ah, "combing" is the word I was looking for, the jagged lins.
[21:36:17 CEST] <FooNess> lines*
[21:36:29 CEST] <kepstin> FooNess: note that if the animation was done on twos, then frames A&B will be the same, frames C&D will be the same, so combing will only be visible on one of the 5 output frames.
[21:36:33 CEST] <furq> higher resolution and no ivtc required
[21:36:34 CEST] <cards> furq: it's not common for something to be mastered in NTSC and then cropped to PAL?
[21:36:39 CEST] <FooNess> kepstin, I see.
[21:36:51 CEST] <kepstin> cards: "crop" makes no sense, ntsc and pal are both 4:3
[21:36:52 CEST] <furq> i mean that happens but not often
[21:36:57 CEST] <cards> especially if it was an american production
[21:36:59 CEST] <furq> but also yeah it wouldn't be cropped
[21:37:07 CEST] <cards> oh. I thought pal was 4:5
[21:37:16 CEST] <FooNess> Wasn't PAL 4:5 and NTSC 4:3?
[21:37:18 CEST] <FooNess> o.O
[21:37:22 CEST] <kepstin> they're different frame rates tho, so stuff converted from ntsc to pal is usually either sped up or has nasty conversion
[21:37:23 CEST] <furq> neither ntsc nor pal are 4:3 resolution
[21:37:30 CEST] <furq> but neither has square pixels so it works out
[21:37:35 CEST] <FooNess> OK, this conversation is really confusing me.
[21:37:37 CEST] <cards> well
[21:37:45 CEST] <FooNess> "square pixels". o.O
[21:37:51 CEST] <FooNess> I see there's a lot more detail involved.
[21:37:53 CEST] <cards> when measuring a television picture in inches, horizontally and vertically
[21:37:54 CEST] <kepstin> the active area of the picture for both ntsc and pal in digital formats is usually treated as 4:3 for consistency, and it's close enough to the real pictures
[21:38:10 CEST] <FooNess> I see.
[21:38:24 CEST] <furq> FooNess: https://en.wikipedia.org/wiki/Pixel_aspect_ratio#Pixel_aspect_ratios_of_com…
[21:38:39 CEST] <FooNess> Hah! Pixels themselves also have aspect rations -- not just displays.
[21:38:39 CEST] <FooNess> Wow.
[21:38:40 CEST] <cards> I thought US pictures were 3:2 or 4:3, and pal was 4:5 or 5:4
[21:38:51 CEST] <furq> only 2.35:1 will have black bars on dvd
[21:38:56 CEST] <furq> or should
[21:39:22 CEST] <kepstin> anamorphic dvds are a weird special case, since they're not *really* ntsc
[21:39:25 CEST] <furq> pal is also 25fps so they just speed it up by 4%
[21:39:58 CEST] <furq> so ideally you'd get the pal video, slow it down 4% and then combine it with ntsc audio
[21:40:01 CEST] <furq> and then cross your fingers it all lines up
[21:40:03 CEST] <Datmith> Hey all! Quick, hopefully easy, question for everyone! I'm trying to setup a multicast audio stream using ffmpeg/ffplay. Is there a way to turn off the audio queue so if a client disconnects and reconnects it's at the same spot as the other clients?
[21:40:13 CEST] <cards> i wonder if SatAM would be an anamorphic anthropomorphic dvd
[21:40:20 CEST] <kepstin> a dvd player outputting an anamorphic dvd as an ntsc analog signal will either have to downscale it and add black bars, or pan and scan.
[21:40:47 CEST] <kepstin> some dvd players also support outputting the anamorphic signal as-is and require you to configure a widescreen tv to stretch it back
[21:40:48 CEST] <cards> furq: the NTSC audio would be better huh?
[21:40:57 CEST] <furq> well the audio has also been sped up by 4%
[21:41:03 CEST] <furq> so you'd need to reencode it to fix it
[21:41:09 CEST] <furq> plus you don't know if the pitch has changed without reference
[21:41:11 CEST] <cards> PAL has faster audio?
[21:41:15 CEST] <furq> and if you have the reference then you probably also have the dvd
[21:41:17 CEST] <cards> NO WONDER brits talk so fast
[21:41:33 CEST] <furq> it's 24fps film to 25fps pal
[21:41:37 CEST] <furq> so the whole thing is 4% faster
[21:41:42 CEST] <furq> at least 99% of the time
[21:41:50 CEST] <furq> there is some insane pulldown method that does it as well but you never see that
[21:41:53 CEST] <cards> that explains why i can't ever understand them
[21:42:04 CEST] <FooNess> But you can still have audio be "sped up" but the pitch remain the same, right? You can do that stuff in Audacity.
[21:42:06 CEST] <cards> their TV has trained them to talk 4% faster than Americans
[21:42:10 CEST] <furq> FooNess: right
[21:42:16 CEST] <furq> sometimes it's pitched up, sometimes it isn't
[21:42:19 CEST] <FooNess> Right.
[21:42:22 CEST] <furq> like i said, you'd need a reference to know which way to convert it back
[21:42:36 CEST] <kepstin> FooNess: the ability to do that sort of speed up without pitch shift is fairly modern :)
[21:42:37 CEST] <FooNess> Yeah; the reference is probably in some DiC studio somewhere.
[21:42:46 CEST] <furq> well the reference is the ntsc dvd
[21:42:54 CEST] <cards> DiC is long gone too
[21:42:55 CEST] <furq> since that should be correct
[21:43:07 CEST] <FooNess> kepstin, these DVDs were released in 2007; I *think*you could do that by then.
[21:43:09 CEST] <furq> but if you have that then you can just pull that audio track provided it's the same cut
[21:44:22 CEST] <furq> film to ntsc is 2:3 pulldown, film to pal is 2:2:2:2:2:2:2:2:2:2:2:3 pulldown
[21:44:25 CEST] <furq> yes i did have to look that up
[21:44:32 CEST] <FooNess> ???????? LOL
[21:44:35 CEST] <FooNess> Damn.
[21:44:38 CEST] <kepstin> keep in mind that all this discussion is purely about productions made in us/japan on film (or film-style digital production) and then converted to pal for overseas sale
[21:44:38 CEST] <furq> yeah this is why nobody does it
[21:44:58 CEST] <furq> kepstin: films made in europe are also 24fps
[21:45:03 CEST] <cards> furq: but wouldn't they have used the NTSC video for the PAL source if it was an American production?
[21:45:11 CEST] <cards> thus making the PAL an unviable source
[21:45:21 CEST] <furq> depends
[21:45:27 CEST] <furq> for tv shows often yes
[21:45:29 CEST] <kepstin> oh, great, so native european films even get the speed-up treatment?
[21:45:34 CEST] <kepstin> that sucks :/
[21:45:35 CEST] <FooNess> So, theoretically, SatAM on the NTSC DVD should be 2:3 pulldown; two frames without combing, two frames with combing, and a fifth frame without combing.
[21:45:47 CEST] <cards> kepstin: if their projectors are 24 fps
[21:45:57 CEST] <kepstin> cards: well, home video releases
[21:45:58 CEST] <cards> how far back in time do you want to go :)
[21:46:57 CEST] <cards> FooNess: I'd be willing to bet your NTSC disc is the best source available at this point
[21:47:09 CEST] <kepstin> i'm mostly used to looking at stuff like uk tv productions, which is actually 25fps (or 50i) and needs conversion for north american home video
[21:47:16 CEST] <cards> unless you want to buy the PAL disc to compare :)
[21:47:32 CEST] <FooNess> cards, I hope so.
[21:47:40 CEST] <furq> and yeah films are sped up on dvd but obviously not on bluray
[21:47:48 CEST] <furq> since nobody is hooking a bluray player up to a crt
[21:47:50 CEST] <FooNess> cards, and no, I'm not buying that just to compare.
[21:47:56 CEST] <cards> FooNess: Walmart used to sell 2 or 3 different SatAM Sonics on separate DVDs for $5 several years ago. Is that the same mastering as your set?
[21:47:56 CEST] <FooNess> Besides, the PAL DVD cover art is HORRIBLE.
[21:48:03 CEST] <kepstin> yeah, at least with bluray and hdmi and modern multisync monitors it's just not an issue at all :)
[21:48:03 CEST] <furq> and there are no 50hz panels
[21:48:17 CEST] <FooNess> cards, I believe you may mean those sets which had like 4 episodes each.
[21:48:27 CEST] <cards> oh, were they 4 eps ea
[21:48:28 CEST] <FooNess> I have the Shout! Factory release with 4 DVDs.
[21:48:35 CEST] <FooNess> Which is both seasons.
[21:48:45 CEST] <FooNess> With the cover art by HE WHO SHALL NOT BE NAMED.
[21:48:47 CEST] <cards> did they have to crunch them to fit on 4 dvds?
[21:48:52 CEST] <furq> in general you just have to compare every release to know for sure
[21:49:11 CEST] <FooNess> cards, mind you, I think these are DVD9's on the Shout! Factory release.
[21:49:13 CEST] <furq> i've got pal releases of films which were clearly scanned from an ntsc broadcast source
[21:49:18 CEST] <FooNess> I'm not sure what the 4-episode DVDs were.
[21:49:19 CEST] <cards> ok
[21:49:20 CEST] <FooNess> DVD5 or 9.
[21:49:24 CEST] <furq> but there's no ntsc dvd of the same film
[21:49:28 CEST] <furq> that was a lot of fun to clean up
[21:49:37 CEST] <furq> but billy blanks deserves it
[21:50:09 CEST] <cards> furq: we need to break into some old Cable TV buildings that still have a basement filled with old BetaMax tapes
[21:50:21 CEST] <cards> they're scattered around the US i'm sure
[21:50:57 CEST] <cards> not like anyone was willing to truck 5 million tons of betamax tapes to some disposal facility
[21:52:08 CEST] <cards> a bunch of stuff would get sent over satellite a week in advance and was recorded in batches by the local cable co
[21:53:26 CEST] <kepstin> given how they typically re-recorded over the tapes multiple times i really wouldn't expect anything useful out of that, even if they hadn't hired someone to take a truck of useless old tapes to the dump to free up some storage space so they could downsize and reduce their rent :/
[21:54:48 CEST] <cards> sure. that would have happened. but there were thousands of locations
[21:54:53 CEST] <cards> there's got to be at least one
[21:55:17 CEST] <cards> if you've done any work in old buildings, you know people hold onto shit for over a hundred years
[21:56:55 CEST] <kepstin> i guess the trick is finding a station that actually owns a building, and hasn't moved or sold it and leased (part of) it back or something like that.
[21:56:57 CEST] <cards> beta is also really high bandwidth and density tape
[21:57:17 CEST] <cards> VHS was lower bandwidth than over the air TV
[21:59:35 CEST] <cards> they keep finding old forever-lost films and radio programmes in basements around the world. just wish there someone put out a general call-out and bounty
[22:28:30 CEST] <Datmith> Hey all. Any one have experience using ffmpeg/ffplay to do multicast audio streaming?
[22:43:29 CEST] <MrSassyPants> Heys, I'm looking to get nvenc (nvidia acceleration things) in ffmpeg, how much of that is in the latest ubuntu version by default
[22:43:42 CEST] <MrSassyPants> I find instructions from 2016
[22:53:33 CEST] <taliho> Datmith: you could try recent ZeroMQ protocol for streaming to multiple clients
[22:53:40 CEST] <taliho> Datmith: https://ffmpeg.org/ffmpeg-all.html#zmq
[22:54:18 CEST] <Datmith> Thank you! I'll look at it right now
[22:54:37 CEST] <poutine> MrSassyPants: ubuntu does not include ffmpeg by default afaik, you could check the apt repositories per release to see what their most recent version is and what flags/libraries it uses
[22:55:16 CEST] <MrSassyPants> poutine, yar, default doesnt seem to use nvenc, compiling it atm
[22:59:11 CEST] <SimAV> kepstin, https://simeon.nlogn.org/share/20190919225302selective_remuxing_04.c based on https://github.com/FFmpeg/FFmpeg/blob/master/doc/examples/remuxing.c does the job for me (:
[23:03:38 CEST] <MrSassyPants> ok, 850fps vs 150fps on a random vid
[23:04:28 CEST] <MrSassyPants> now I gotta figure out why OBS fails with
[23:04:34 CEST] <MrSassyPants> [NVENC encoder: 'streaming_h264'] Failed to open NVENC codec: Generic error in an external library
[23:06:30 CEST] <poutine> I'm sure it's a common enough problem that you're not the first one to have it :)
[23:11:36 CEST] <MrSassyPants> its wörking (I didn't adjust the bitrate to the resolution and this makes it fail without error I guess?)
[23:11:42 CEST] <MrSassyPants> fail with generic error*
[23:17:21 CEST] <Sirisian|Work2> Fascinating. Not that it matters, but I found out bcrypt is a flag in config.h. Apparently when chromium builds ffmpeg it's disabled. When I run the exact same ./config I guess because bcrypt.lib exists it tries to enable it. Setting it back to 0 fixes it.
[23:17:36 CEST] <Sirisian|Work2> ./configure*
[23:30:25 CEST] <kepstin> mixing the ffmpeg upstream build system and a build system provided by a third party sounds like a bad time all around :/
[23:31:17 CEST] <Sirisian|Work2> I'm not mixing them. I'm running their version. I think my build environment is just slightly different than their build servers.
[23:34:59 CEST] <Sirisian|Work2> Last few issues seem related to vorbis. https://pastebin.com/BVGtjqTC Doesn't seem to be linking correctly. All I'm trying to do by the way is --enable-decklink in their ffmpeg windows 64-bit build. Much harder than I expected.
[23:42:17 CEST] <kepstin> not really sure anyone here can help you unless you use the ffmpeg build system. And the chrome folks only care about building the features that they use in chrome.
[23:46:45 CEST] <cehoyos> Note that chrome works fine in Debian with libav* built with FFmpeg's build system
[23:47:10 CEST] <cehoyos> (Gentoo builds FFmpeg twice iiuc)
[23:47:23 CEST] <cehoyos> - contains two FFmpeg library binaries
[00:00:00 CEST] --- Fri Sep 20 2019
1
0
[00:50:36 CEST] <Lynne> philipl: is it possible AVCUDADeviceContext->cuda_ctx is NULL?
[00:50:41 CEST] <Lynne> that's what I'm getting
[00:57:45 CEST] <Lynne> wait, the frame is empty, dst->data[0] is null
[00:58:27 CEST] <Lynne> but dst->hw_frames_ctx points to a vulkan frames context, not a cuda one
[01:02:52 CEST] <Lynne> I don't think there's a way to generate a cuda frame context, so without one I can't alloc a frame to copy into
[01:04:12 CEST] <philipl> You'd want a way to derive a cuda context, which could be implemented
[01:20:33 CEST] <Lynne> I think I'll leave you to do the vulkan->cuda mapping, the inverse was hacky enough with pool initialization for me
[01:37:15 CEST] <philipl> Lynne: OK. I'll get on it when I can.
[02:19:13 CEST] <cone-962> ffmpeg 03hwrenx 07master:96f1d34d0cd2: lavf/mpegts: Support demuxing AVS2.
[07:10:46 CEST] <cone-798> ffmpeg 03Moritz Barsnick 07master:53d31e91c530: doc: various spelling, grammar and formatting fixes
[16:38:16 CEST] <Lynne> https://0x0.st/ztsh.png
[16:39:16 CEST] <Lynne> vim's is worse, and I'm now a pro at whatever regex gtksourceview uses
[16:40:13 CEST] <durandal_1707> lies
[16:40:25 CEST] <durandal_1707> vim is supreme editor
[16:42:47 CEST] <cone-914> ffmpeg 03James Almer 07master:1d86e4b3ebb4: checkasm/opusdsp: declare opus_deemphasis as a function returning a float
[16:52:15 CEST] <Lynne> durandal_1707: did you test the vulkan patches?
[16:54:36 CEST] <durandal_1707> Lynne: nope, busy with other stuf
[17:29:06 CEST] <philipl> Lynne: have been meaning to say. Currently the hwcontext doesn't actually compile without libdrm being enabled.
[17:29:35 CEST] <philipl> the map_from_drm stuff isn't guarded and the cuda includes are nested inside the libdrm #ifdef.
[17:50:34 CEST] <Lynne> philipl: missed that, fixed the branch
[18:14:14 CEST] <kierank> durandal_1707: lies, microsoft word is supreme editor
[18:17:10 CEST] <Lynne> wrong, everyone uses wordpad to edit their ini files on windows
[18:33:50 CEST] <philipl> Lynne: that worked. next thing is that filters still build if glslang isn't enabled and then libavfilter has unresolved symbols at the end.
[18:38:04 CEST] <Lynne> that shouldn't happen, all filters have _vulkan_filter_deps="vulkan libglslang", except scale, which I just fixed
[18:40:03 CEST] <Lynne> yeah, without --enable-libglslang none of the filters appear in "Enabled filters:"
[18:44:47 CEST] <philipl> Hmm. Well, something is leaking.
[18:52:11 CEST] <philipl> CC libavfilter/vulkan.o
[18:52:11 CEST] <philipl> GEN libavfilter/libavfilter.ver
[18:52:11 CEST] <philipl> LD libavfilter/libavfilter.so.7
[18:52:11 CEST] <philipl> LD libavdevice/libavdevice.so.58
[18:52:13 CEST] <philipl> AR libavfilter/libavfilter.a
[18:52:16 CEST] <philipl> LD ffmpeg_g
[18:52:18 CEST] <philipl> /usr/bin/ld: libavfilter/libavfilter.so: undefined reference to `glslang_compile'
[18:52:21 CEST] <philipl> /usr/bin/ld: libavfilter/libavfilter.so: undefined reference to `glslang_uninit'
[18:52:24 CEST] <philipl> /usr/bin/ld: libavfilter/libavfilter.so: undefined reference to `glslang_init'
[18:52:27 CEST] <philipl> collect2: error: ld returned 1 exit status
[18:52:30 CEST] <philipl> make: *** [Makefile:111: ffmpeg_g] Error 1
[18:52:32 CEST] <philipl> ack. sorry.
[18:53:05 CEST] <philipl> Sorry for the spam, but it's insisting on building vulkan.o.
[18:53:07 CEST] <philipl> I don't see how it's coming in. Each filter has the right dependency check.
[18:54:44 CEST] <philipl> Lynne: it's the scale_vulkan filter
[18:55:07 CEST] <philipl> There's no deps entry for it
[19:09:24 CEST] <Lynne> yeah, I fixed that earlier
[19:33:31 CEST] <philipl> Lynne: I missed that update. But yes, now it's looking correct.
[00:00:00 CEST] --- Thu Sep 19 2019
1
0
[03:28:32 CEST] <nicolas17> can I speed up a video introducing motion blur instead of dropping frames entirely?
[03:32:28 CEST] <cards> not by very much
[03:32:49 CEST] <cards> blend 2 frames togther if you want motion blur, not 60
[03:38:53 CEST] <nicolas17> I mean how do I do it with ffmpeg?
[07:22:18 CEST] <C0nundrum> hello
[07:22:44 CEST] <C0nundrum> When using ddshow as an input, anyone know how to set camera settings like exposure and gain ?
[09:54:00 CEST] <ricemuffinball> what soundcard do people recommend for using with ffmpeg?
[11:08:16 CEST] <snooky> moin
[11:08:58 CEST] <JEEB> ricemuffinball: I think that often depends on what OS you're using etc
[11:09:18 CEST] <JEEB> since more than FFmpeg itself, it's usually the audio input APIs and the driver support that drive issues
[11:09:33 CEST] <ricemuffinball> i use windows
[11:10:21 CEST] <JEEB> and thus most likely directshow or so as input? unfortunately I have no experience of that :)
[12:31:16 CEST] <pk08> i want to add a global variable which can access in libavformat/mpegts.c and libavfilter/vf_drawtext.c
[12:31:16 CEST] <pk08> so for that, i created a header file called "test.h" and defined a variable with extern int anyError; and then included test.h file in both above .c files
[12:31:16 CEST] <pk08> and i redefined that variable in mpegts.c like int anyError = 0;
[12:31:16 CEST] <pk08> now when i try to compile ffmpeg, i am getting libavfilter/libavfilter.so: undefined reference to `anyError'
[12:31:16 CEST] <pk08> i tried to build static build but getting same error there too!
[12:31:56 CEST] <BtbN> Global variables are bad. Don't use them, ever.
[12:32:32 CEST] <BtbN> Those two source files are in separate libraries as well, so they can't just share a global variable like that anyway.
[12:32:45 CEST] <pk08> so what should i do to fix my issue?
[12:32:51 CEST] <BtbN> Fix what issue?
[12:33:03 CEST] <pk08> to get access for a variable
[12:33:23 CEST] <BtbN> You just don't?
[12:33:31 CEST] <pk08> i tried to use getter/setter mathod too
[12:33:35 CEST] <pk08> but it ddidnt work
[12:33:55 CEST] <BtbN> It's be much better to state your actual problem instead of asking how to implement how you think to solve it.
[12:33:57 CEST] <pk08> BtbN: so cant access at all?!
[12:34:13 CEST] <BtbN> Global variables are a design flaw. So yes, you just don't.
[12:34:35 CEST] <pk08> ok, so i want to make a error cc error counter from mpegts.c
[12:34:59 CEST] <pk08> and i want to dispaly total cc errors on screen, using showtext filter
[12:35:14 CEST] <pk08> so i want to access that error counter in libavfilter
[12:35:29 CEST] <BtbN> You could add the error count as side data to the frames.
[12:35:51 CEST] <pk08> ok, so how can i do that?
[12:35:57 CEST] <BtbN> By using the side data API
[12:35:59 CEST] <pk08> can you please explain a bit more?
[12:36:20 CEST] <BtbN> No, I'd have to look it up for that, and you can as well do that yourself.
[12:37:15 CEST] <pk08> ok, thanks for your help
[12:38:03 CEST] <BtbN> It should be pretty easy to find the respective APIs for side data.
[13:00:39 CEST] <^Neo> Good morning friends! Does anyone know of a work around for this issue? https://trac.ffmpeg.org/ticket/1102
[13:03:09 CEST] <JEEB> yes, the J2K and HEVC decoders output fields separately in case of field coding, feel free to add the filter that sticks two images together
[13:03:13 CEST] <JEEB> I don't remember its name :P
[13:07:42 CEST] <durandal_1707> weave
[13:07:51 CEST] <JEEB> thank you
[13:09:36 CEST] <^Neo> weave tinterlace?
[13:10:43 CEST] <durandal_1707> weave filter is simpler
[13:43:58 CEST] <th3_v0ice> Is it possible to set number of threads in the API that a filter is using?
[13:49:54 CEST] <durandal_1707> th3_v0ice: yes, via filtergraph
[13:50:10 CEST] <durandal_1707> or as filter option for each filter
[13:53:15 CEST] <th3_v0ice> durandal_1707: Can you provide some basic example? Thanks
[13:55:37 CEST] <durandal_1707> th3_v0ice: look at documentation
[13:58:31 CEST] <th3_v0ice> durandal_1707: I can only find ffmpeg-filters online, and only filter with threads is libvmaf. I am surely not looking at the correct place.
[13:59:18 CEST] <durandal_1707> threads=X as extra option for every filter, additionally there is threads to be set for whole filtergraph
[14:00:53 CEST] <th3_v0ice> So I can just "threads=2" in the avfilter_graph_create_filter() args parameter?
[14:01:55 CEST] <durandal_1707> no, per each filter option
[14:02:06 CEST] <durandal_1707> or as avfiltergraph AVOption
[14:03:03 CEST] <th3_v0ice> I am sorry but I am not following you
[14:03:53 CEST] <durandal_1707> -vf filter=threads=X:optionZ=Y
[14:04:24 CEST] <durandal_1707> for global filtergraph you need to find it on your own
[14:04:48 CEST] <th3_v0ice> Oh, like that! Where can I find the documentation for global filtergraph?
[14:06:12 CEST] <th3_v0ice> Is it as simple as filter_graph->nb_threads = 3;?
[15:30:22 CEST] <th3_v0ice> durandal_1707: Thanks, this did the trick.
[19:17:54 CEST] <Sirisian|Work> I'm having an issue using --enable-decklink. ffmpeg compiles fine, but when I add --enable-decklink and --extra-cflags='-I/c/DeckLinkSDK/Win/include' (I already ran midl on the idl file and it output the DeckLinkAPI.h) it says "ERROR: DeckLinkAPI.h not found". In the mingw terminal running ls -l /c/DeckLinkSDK/Win/include clearly shows "DeckLinkAPI.h". I tried copying it into one of the other include directories and I get the
[19:17:55 CEST] <Sirisian|Work> same result.
[19:23:56 CEST] <Sirisian|Work> oh wait, looking at the config.log I think it's throwing that but it's not actually the error. As in another error is causing that to be incorrectly displayed.
[19:41:36 CEST] <Sirisian|Work> ah I'm using mingw 32-bit headers somehow instead of the 64 ones. Neat.
[20:08:08 CEST] <SimAV> Hi, I've got a problem with audio/video sync (in chrome based browsers, but not in Firefox) when passing a mkv livestream via ffmpeg through icecast and letting a second ffmpeg remux the video to dash
[20:08:20 CEST] <SimAV> When replacing icecast by a pipe between the two ffmpeg's (the first encoding different bitrates/resolutions and packing them into a matroska container -- the second remuxing the matroska input to dash), audio and video is in sync.
[20:09:05 CEST] <SimAV> When asking in #icecast I got the following replies: """
[20:09:07 CEST] <SimAV> There is no code in icecast that rewrites the timestamps.
[20:09:13 CEST] <SimAV> I would guess it's a kind of ffmpeg bug.
[20:09:25 CEST] <SimAV> maybe it does not use the timestamps to sync the clusters but considers both tracks to be sync and then reads them as they are.
[20:09:25 CEST] <SimAV> """
[23:04:03 CEST] <Sirisian|Work> https://trac.ffmpeg.org/wiki/CompilationGuide <-- this mentioned a "--cpu" flag, but there's no documentation about it? Does it have a list of valid values?
[23:09:35 CEST] <JEEB> Sirisian|Work: seems like it mostly checks it against some sort of string template
[23:10:00 CEST] <JEEB> so there's no exact list
[23:10:16 CEST] <kepstin> Sirisian|Work: in theory it accepts anything your compiler takes with the -march or -mcpu option
[23:10:24 CEST] <kepstin> Sirisian|Work: but there's a hardcoded list on x86
[23:11:13 CEST] <kepstin> well, some patterns, it's not completely hardcoded
[23:12:02 CEST] <kepstin> https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/configure#l5104
[23:19:56 CEST] <Sirisian|Work> ah, I'll look more into it. Thanks. I'm building chromium's ffmpeg for 64-bit using clang-cl on windows. Seeing a number of unknown 'cpu' type 'amdnop'. It's referencing libavcodec/x86 though in the logs, so perhaps I missed something elsewhere.
[00:00:00 CEST] --- Thu Sep 19 2019
1
0
[00:30:53 CEST] <cone-616> ffmpeg 03Michael Niedermayer 07master:ef50cf7b32b9: avcodec/hevcdec: Fix memleak of a53_caption
[03:44:01 CEST] <tmm1> jkqxz: wdyt of http://ffmpeg.org/pipermail/ffmpeg-devel/2019-September/249905.html; would it be better to remove the unions altogether?
[15:02:05 CEST] <cone-101> ffmpeg 03Andreas Rheinhardt 07master:34bd293b014e: avformat/mov: Fix memleak
[15:02:05 CEST] <cone-101> ffmpeg 03Andreas Rheinhardt 07master:2b1fcba8ddcb: fftools/ffmpeg_opt: Fix signed integer overflow
[15:02:05 CEST] <cone-101> ffmpeg 03Michael Niedermayer 07master:093d1f42507e: avformat/mov: Check for EOF in mov_read_meta()
[15:02:05 CEST] <cone-101> ffmpeg 03Michael Niedermayer 07master:65589ad55349: tools/target_dec_fuzzer: Adjust threshold for binkvideo
[15:19:22 CEST] <nevcairiel> You would think people trying to report such static analyzer problems actually knew a bit of C
[15:24:15 CEST] <BtbN> "Wow, what is the point? norm = norm?" -_-
[15:25:26 CEST] <nevcairiel> that one for example
[15:25:32 CEST] <nevcairiel> read the entire line :p
[15:26:54 CEST] <BtbN> Yes, not a single one of those which I looked at are in any way a problem.
[15:27:09 CEST] <BtbN> "This else is not possible)) I suppose. All variants are already checked."
[15:27:17 CEST] <BtbN> You don't say, which is why it return a BUG
[15:27:17 CEST] <nevcairiel> some things have a bit of redundant code in it, but often in the name of clarity
[15:31:00 CEST] <mkver> And somehow it thinks that stuff initialized through AV_WL/AV_WB macros are not really initialized.
[15:31:35 CEST] <BtbN> It's probably some pimped up linter, and not even a static analysis.
[15:35:44 CEST] <nevcairiel> pvs-studio keeps popping up every couple years, I wouldn't be surprised if some people are sponsored by the creators of such tools to go analyze open-source code and make sure to mention their tools name
[15:36:12 CEST] <BtbN> Well, it's pretty bad publicity they get from this.
[15:36:20 CEST] <BtbN> Really not a single thing it finds is correct.
[15:42:34 CEST] <mkver> I wouldn't go so far.
[15:43:34 CEST] <mkver> These array overrun errors in cbs_h2645 are genuine.
[15:46:28 CEST] <nevcairiel> i dont see any mention of cbs in that pvs ticket
[15:55:27 CEST] <mkver> Lines 651-2231 in the list of tasks are about cbs.
[15:55:49 CEST] <mkver> You ignored the attached file, didn't you?
[15:57:35 CEST] <BtbN> There is _even more_ oO
[15:58:06 CEST] <BtbN> I'd say ignoring this entire report is safe. Anything serious will be catched by coverity already.
[15:58:18 CEST] <BtbN> And people ignore that all the time as well.
[16:00:38 CEST] <nevcairiel> obviously i'm not going to read some large random report some random person attaches in a random ticket :p
[16:00:57 CEST] <nevcairiel> which probably even needs their tool to read properly
[16:01:44 CEST] <nevcairiel> mostly because its just unproductive to find the one good hit in the noise of nonsense
[20:44:36 CEST] <Lynne> pushed a finally working version of the vulkan patchset here - https://github.com/cyanreg/FFmpeg/tree/vulkan
[20:45:39 CEST] <Lynne> could do asynchronous filtering for most filter but won't need an api change, just a few hundred lines of tedious management code
[20:45:43 CEST] <Lynne> durandal_1707: happy now?
[20:46:10 CEST] <durandal_1707> Lynne: what i need to install vulkan?
[20:46:39 CEST] <durandal_1707> and does this framework works with multiple vulkan filters in single graph?
[21:08:59 CEST] <Lynne> durandal_1707: on debian just install glslang-dev, should pull in the rest of the vulkan headers
[21:09:39 CEST] <Lynne> ./ffmpeg_g -init_hw_device "vulkan=vk:0,debug=1" -init_hw_device "vaapi=vp:/dev/dri/renderD128" -hwaccel vaapi -hwaccel_output_format vaapi -i sample.mkv -hwaccel vaapi -hwaccel_output_format vaapi -i sample2.mkv -filter_hw_device vk -filter_complex "[0:0] hwmap,format=vulkan [s1] ; [1:0] hwmap,format=vulkan [s2] ; [s2] avgblur_vulkan=sizeX=9:sizeY=9 [s2] ; [s1] chromaber_vulkan=dist_x=9:dist_y=9 [s1] ;
[21:09:41 CEST] <Lynne> [s1] [s2] overlay_vulkan=x=320:y=90 [d1] ; [d1] scale_vulkan=w=640:h=-1 [d1] ; [d1] avgblur_vulkan=sizeX=5:sizeY=5 [d1] ; [d1] hwdownload,format=nv12 [d1]" -map "[d1]" -c:v rawvideo -y test.nut
[21:10:20 CEST] <Lynne> you can chain as many filters as you want and even overlay like the example I pasted
[21:11:20 CEST] <Lynne> you need libdrm to map from vaapi though in addition to libva-dev
[21:39:50 CEST] <philipl> Lynne: nice.
[21:40:15 CEST] <philipl> are you eventually going to implement mapping back to vaapi/drm/cuda?
[22:02:15 CEST] <Lynne> philipl: there is mapping from vulkan to vaapi/drm already, it works
[22:05:12 CEST] <Lynne> want to do the cuda mapping? should be just a matter of moving everything under "if (!dst_int || !dst_int->cuda_fc_ref) {" in a new function and calling it to export to cuda, then do the memcpy
[22:24:00 CEST] <cone-659> ffmpeg 03Paul B Mahol 07master:251284e44aa5: avfilter/vf_v360: add mercator projection
[22:31:38 CEST] <JEEB> wow
[22:31:49 CEST] <JEEB> the "old" subtitle decoding mode is the default still
[22:31:49 CEST] <JEEB> TIL
[22:50:06 CEST] <philipl> Lynne: Theoretically, I'd like it, but it will take a while to get to it.
[22:50:21 CEST] <philipl> If you're happy to wait, then sure. Certainly wouldn't block merging what you have.
[22:54:40 CEST] <Lynne> k, I'll try to do it tonight
[23:02:32 CEST] <Lynne> are there semaphores I need to signal in a cuda frame?
[23:07:50 CEST] <philipl> So, you'd need an additional semaphore to deal with the case that a frame has been passed on for mapping to cuda but now something wants to reuse the frame for new content. I'm not sure that would ever happen though. As the frame would presumably not be available until read.
[23:08:59 CEST] <philipl> Another case would be if the frame producer might not have finished writing the frame when you map it. Then you'd want a semaphore for cuda to wait on before doing the memcpy
[23:09:16 CEST] <philipl> Again, that might not actually happen.
[23:24:29 CEST] <Lynne> cu->cuCtxPushCurrent(cuda_dev->cuda_ctx) segfaults... in libvulkan according to gdb
[00:00:00 CEST] --- Wed Sep 18 2019
1
0
[01:22:42 CEST] <realies> any way to accelerate the generation of the showwaves filter?
[03:48:55 CEST] <karanveersingh> Hi All , yesterday i was struggling with live streaming of 4k videos
[03:49:39 CEST] <karanveersingh> system configuration is 2 socket , 88 core processors with 8 GB of Ram
[03:51:21 CEST] <karanveersingh> below is the first command I was trying , the issue is that the video live streaming runs perfectly with 2 simultaneous streams of 4k but when the 3rd stream starts , all goes bad and fps start dropping
[03:51:35 CEST] <karanveersingh> ffmpeg -re -i Stranger09.mkv -c:v libx264 -b:v 50M -preset ultrafast -tune zerolatency -b:a 128k -s 4096x2160 -bufsize 5M -x264opts keyint=500 -g 60 -pix_fmt yuv420p -f flv rtmp://194.167.137.11/live-test/Strange09_4k
[03:52:28 CEST] <karanveersingh> Some guys recommended me to omit / edit below mentioned parameters but still its not working
[03:52:43 CEST] <karanveersingh> Remove -tune zerolatency
[03:53:13 CEST] <karanveersingh> keyint=500 -g 60 , both are same so does use it together
[03:54:01 CEST] <karanveersingh> need to limit thread by adding -thread x
[03:55:39 CEST] <karanveersingh> add audio codec -c:a aac
[03:56:32 CEST] <another> how's your cpu usage?
[03:56:38 CEST] <karanveersingh> very high
[03:57:59 CEST] <another> hmm.. any reason why you're scaling?
[03:59:08 CEST] <karanveersingh> yes , need to see how many videos i can run on a specific system with a specific drive
[03:59:40 CEST] <karanveersingh> after 2 videos , nothing goes fine ,
[04:00:31 CEST] <another> well, are all of your cores at 100% with 2 streams?
[04:00:57 CEST] <karanveersingh> no , its 50%
[04:01:10 CEST] <another> average over all cores?
[04:02:48 CEST] <another> how's your memory usage?
[04:03:11 CEST] <another> 8GB seems rather low
[04:03:55 CEST] <karanveersingh> load average cpu - 524.00 ~ 900.00
[04:04:04 CEST] <karanveersingh> memory is all high
[04:04:18 CEST] <karanveersingh> i created swap of the disk more than memory
[04:04:24 CEST] <karanveersingh> Ram + 2
[04:04:40 CEST] <karanveersingh> * on the disk
[04:05:18 CEST] <another> ssd or hdd?
[04:05:37 CEST] <another> how hard are you swapping?
[04:08:43 CEST] <karanveersingh> nvme QLC ssd
[04:08:59 CEST] <karanveersingh> very bad performance than TLC
[04:09:50 CEST] <karanveersingh> On TLC i could run IOs till 15 videos and then saw drop in IO and increase in io wait time
[04:10:47 CEST] <karanveersingh> here in QLC its all broken after 7 videos , now no activity i can see on drive and ffmpeg command has not failed yet
[04:11:35 CEST] <karanveersingh> end result I need to run max no of videos with no frame drop
[04:11:54 CEST] <karanveersingh> right now I am able to reach upto 2 videos with no frame drop
[04:12:42 CEST] <karanveersingh> The 15 video streams I ran was just to see SSD IO activity
[04:15:32 CEST] <another> are all your cores maxed with 3 streams? how is your memory?
[04:16:40 CEST] <karanveersingh> no , cores are not maxed out at 3and memory is still there like 50%
[04:23:04 CEST] <another> hmm
[04:23:48 CEST] <another> network?
[04:24:13 CEST] <karanveersingh> single node , so streaming and transcoding all on it
[04:24:28 CEST] <another> no i meant uplink
[04:24:32 CEST] <DHE> I think he meant network storage of some sort
[04:24:42 CEST] <another> that too
[04:29:31 CEST] <karanveersingh> no network storage , i am not sending any packet out of the node
[04:29:49 CEST] <karanveersingh> all operations are carried out in single node
[04:30:05 CEST] <karanveersingh> so network does not come into
[04:31:42 CEST] <another> are you streaming to localhost?
[04:31:49 CEST] <karanveersingh> yes
[04:32:42 CEST] <qbmonkey> So I'd like to use ffmpeg for any xvid encoding I do. I have gotten ffmpeg on par with mencoder quality, but outputs are 10-20% larger. Here are the options I use in both. https://pastebin.com/QKFFmxhT
[04:33:16 CEST] <qbmonkey> I think I've exhausted my options.
[04:34:32 CEST] <another> you have a special need for xvid?
[04:34:59 CEST] <qbmonkey> yes
[04:35:18 CEST] <qbmonkey> Plays well on SOC arm with not vid accel
[04:35:18 CEST] <pink_mist> eww, why in the world would you use xvid in 2019? are you going to play it back on 486 CPUs?
[04:35:32 CEST] <pink_mist> oh, guess so
[04:35:33 CEST] <qbmonkey> near that when you have no vid accel
[04:36:19 CEST] <qbmonkey> Thats actually the response I expected.
[04:37:54 CEST] <another> i'm afraid i can't help you
[04:38:33 CEST] <another> karanveersingh: are you reading all the input from the same disk?
[04:38:57 CEST] <qbmonkey> I imagine that this is a known difference between ffmpeg and mencoder, but no one is really invested in it.
[04:45:51 CEST] <kepstin> the obvious difference between those two command lines is that the ffmpeg one has audio and the mencoder one doesn't
[04:45:57 CEST] <kepstin> that would account for the size difference
[04:58:43 CEST] <qbmonkey> I forgot to omit that. When testing both are without audio
[04:59:15 CEST] <qbmonkey> mencoder does not support the audio codec I use in the mkv container.
[04:59:55 CEST] <qbmonkey> But that is why the example has audio with ffmpeg.
[05:00:02 CEST] <qbmonkey> The difference is not the audio.
[05:05:11 CEST] <qbmonkey> I've thought the issue was in vhq or bvhq. Can't remember which one (been awhile) but I thing ffmpeg didn't have a option for it.
[05:05:46 CEST] <qbmonkey> Or it had a hard-coded default. Or I just didn't know what I was doing.
[05:13:57 CEST] <qbmonkey> It may have been also that the strength for one or both of those setting was not supported in ffmpeg.
[05:16:07 CEST] <qbmonkey> The adjustment of the setting was supported, but not all options available in ffmpeg.
[05:17:29 CEST] <qbmonkey> It was probably either a -me* option or the -mbd (ffmpeg).
[05:18:08 CEST] <qbmonkey> I believe vhq/bvhq are the related mencoder options.
[05:21:20 CEST] <qbmonkey> Otherwise, the actual xvid code should be pretty much the same.
[05:22:10 CEST] <qbmonkey> It seemed like there was just no way I could find to input the same options. Pretty close though,
[11:36:37 CEST] <auri_> Hello! Is there any way to make the DASH muxer start writing segments from a specific number?
[11:38:03 CEST] <auri_> I saw a similar question on SO a while back, no real answers there, thought I should ask here.
[11:43:28 CEST] <BtbN> https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/dashenc.c;h=a46… does not look like it
[11:46:10 CEST] <auri_> huh
[11:46:41 CEST] <auri_> the Plex "fork" of the project (which they distribute because of the license) has an opt called "-skip_to_segment"
[11:46:57 CEST] <auri_> is there any reason why this option is not part of upstream, technical considerations at least?
[11:47:06 CEST] <durandal_1707> nobody sent patch
[11:47:09 CEST] <cehoyos> Yes, definitely
[11:47:28 CEST] <auri_> oh, well that makes more sense
[11:49:33 CEST] <BtbN> I don't really see why you would need that though?
[11:49:44 CEST] <auri_> Ah, let me explain
[11:49:48 CEST] <BtbN> The names of the segments seem pretty arbitrary to me
[11:51:08 CEST] <auri_> I'm building an application feature that is similar to Plex and I thought I could use ffmpeg's dash muxer to create the segments (as ffmpeg is already extensively used in the codebase)
[11:51:27 CEST] <auri_> one of the considerations is that users are allowed to seek past currently encoded segments
[11:51:41 CEST] <auri_> in which case we stop the encoder and start a new one
[11:52:03 CEST] <auri_> the issue is that to share an output directory, we'd have to change the starting segment number
[11:52:25 CEST] <auri_> otherwise we'd have to create a new temporary directory for each time a user uses the seeking functionality
[11:52:36 CEST] <auri_> and then figure out how to serve them appropriately
[11:53:54 CEST] <auri_> kind of a bad explanation on my part but I hope it makes enough sense
[11:59:22 CEST] <BtbN> you could also just change the name of the segments a little bit each time
[12:00:36 CEST] <BtbN> But if you want to end up with one big playlist with no need to re-encode old segments, that might be a bit annoying indeed. But do you calculate the proper index of each segment, so that gaps while seeking result in the correct gap in the indices?
[12:01:02 CEST] <auri_> Yep
[12:02:10 CEST] <auri_> -skip_to_segment would greatly reduce the amount of logic necessary on our end
[12:02:45 CEST] <auri_> I guess I should extract the patch and send it in the development channel
[12:02:59 CEST] <auri_> not too comfortable with ffmpeg code to submit it myself, though someone else might be interested
[12:03:15 CEST] <JEEB> unfortunately that then 100% depends on people's interest level :)
[12:03:41 CEST] <auri_> indeed
[12:03:44 CEST] <JEEB> (also you'd have to figure out the copyright, which could also just be "Plex" <blah(a)plex.tld>)
[12:03:56 CEST] <auri_> yeah, that I also plan on doing
[12:04:10 CEST] <auri_> though to be fair it's very simple and not difficult to just
[12:04:16 CEST] <auri_> white room reimplement it
[12:04:22 CEST] <auri_> to avoid copyright issues
[12:05:04 CEST] <BtbN> The big issue with those kind of patches usually is that they disregard a lot of corner cases and break a bunch of other stuff.
[12:05:28 CEST] <auri_> yep, that's my biggest concern for this
[12:05:50 CEST] <auri_> which is why I'm too afraid to submit it myself, lol
[12:05:56 CEST] <BtbN> I'm also maintaining a small collection of special case HLS segment muxer patches that fit my use case, but just plain break a bunch of others and are horrible code.
[12:06:09 CEST] <BtbN> Just grab the patch and send it really
[12:06:13 CEST] <BtbN> People can then discuss
[12:08:03 CEST] <JEEB> I was surprised that the segment muxer had HLS stuff
[12:08:14 CEST] <JEEB> even though HLS muxer does pretty much the same
[12:08:41 CEST] <JEEB> and then some guy wanting to add secondary streams to webvtt because it didn't work otherwise with segment muxer's HLS output...
[12:09:06 CEST] <JEEB> while the HLS muxer does support webvtt, even though it doesn't support it in the master playlist generation code
[12:09:10 CEST] <JEEB> (Ž4@)
[12:21:12 CEST] <auri_> yeah, it seems that Plex provided no licensing notices whatsoever
[12:21:23 CEST] <auri_> so the copyright is somewhere up in the air
[12:32:35 CEST] <BtbN> Not really. If you patch (L)GPL software, your patch is (L)GPL.
[12:32:50 CEST] <JEEB> yea
[12:33:20 CEST] <JEEB> (you can *also* license your patches under another license, but to follow LGPL you have to publish the sources of LGPL software under that license)
[12:47:14 CEST] <auri_> Oh, I completely forgot that ffmpeg is licensed under the LGPL
[12:47:28 CEST] <auri_> this makes it easier to submit the patch, I guess
[13:14:16 CEST] <JEEB> hmm, does anyone remember if -map_metadata works with stream identifiers based on stream IDs instead of indices?
[13:15:21 CEST] <JEEB> like -map_metadata:s:a:0 '0:s:#1337' (map the metadata of PID 1337 from input to output audio stream 0)
[13:15:34 CEST] <JEEB> I would guess not since 0:s: is IIRC index based
[13:27:18 CEST] <forgon> Following instructions from https://trac.ffmpeg.org/wiki/Capture/ALSA and executing `ffmpeg -y -f alsa -i hw:Loopback,1,0 -c:a flac /tmp/test.wav` fails with "Input/output error" when starting the application whose sound should be recorded: http://ix.io/1Vx0
[14:37:10 CEST] <Radiator> Hi all, it appear that the example https://ffmpeg.org/doxygen/trunk/muxing_8c-example.html is no more valide as the function avcodec_encode_video2 is deprecated. The documentation redirect to using the function avcodec_send_frame but I find it a little off as it doesn't need any AVPacket to send it. Since avcodec_encode_video2 to send the packet we
[14:37:10 CEST] <Radiator> had to call av_interleaved_write_frame, do we still have to call that function when using avcodec_send_frame and if so how d owe retreive the packet ?
[14:38:25 CEST] <BtbN> There's a corresponding function to recv it.
[14:39:56 CEST] <DHE> av_[interleaved]_write_frame is poorly named as you give it an AVPacket. similar for av_read_frame
[14:41:52 CEST] <Radiator> DHE Do you advice to use a different function to send the packet ? or directly send the AVFrame ?
[14:42:28 CEST] <DHE> if you're encoding, you send frames and receive packets. avcodec_send_frame and avcodec_receive_packet
[14:42:43 CEST] <Radiator> BtbN are you talking about avcodec_receive_frame .
[14:43:03 CEST] <BtbN> no
[14:43:09 CEST] <BtbN> you want a packet, don't you?
[14:43:23 CEST] <Radiator> BtbN Yup
[14:43:30 CEST] <DHE> then do what I said
[14:45:37 CEST] <Radiator> DHE Ok, I see now, I "send the frame" which will somehow build a packet that I receive using the function avcodec_receive_packet. Then I write the packet on the AVFormatContext using the av[_interleaved]_write_frame ?
[14:46:01 CEST] <DHE> basically yes
[14:46:15 CEST] <Radiator> Great !
[14:46:19 CEST] <Radiator> Thanks :)
[14:46:20 CEST] <DHE> there's some little housekeeping things to do. like if your output file contains both audio and video, you'll need to set the stream index in the packet
[14:47:27 CEST] <Radiator> Yeah I already did that part, as well as handling the frame rate and paying attention to the pts
[16:35:12 CEST] <Radiator> what should I have to free after using av_image_alloc() on a frame ? Do I have to use a av_frame_unref ? av_frame_free() doesn't seem to free everything sadly
[16:37:03 CEST] <Radiator> Nevermind, I just found my answer. av_freep must be called on the pointers allocated
[21:59:34 CEST] <forgon> When trying to record the sound from an application by running `ffmpeg -f alsa -i default -c:a flac foo.mkv`, I notice that my recording is less loud than what I hear. What could be the cause?
[22:02:57 CEST] <BtbN> Your audio chain is not at 100% everywhere, so each time you capture, it'll lose those XX% you are from it
[22:03:45 CEST] <forgon> I guess I'll copy-paste from the tutorial at https://trac.ffmpeg.org/wiki/Capture/ALSA :|
[22:04:35 CEST] <BtbN> Also, isn't -i default your microphone?
[22:07:20 CEST] <forgon> BtbN: That could be an explanation. Afaik I have 2 cards: One is called PCH and described as "Analog", the other one is called Loopback.
[22:07:43 CEST] <BtbN> Then you already did setup a loopback device
[22:07:57 CEST] <forgon> BtbN: And that's the one I should always use, right?
[22:08:09 CEST] <BtbN> Depends purely on your hardware
[22:08:15 CEST] <BtbN> I never had a Loopback device appear on its own
[22:08:20 CEST] <BtbN> Also, if you want to actually capture individual application, you will need pulseaudio.
[22:09:29 CEST] <forgon> BtbN: Has been noted.
[23:11:33 CEST] <classsic> Hi, I get this error " Application provided invalid, non monotonically increasing dts to muxer in stream 0: 604 >= 604"
[23:11:59 CEST] <classsic> is there a way to fixit?
[23:12:33 CEST] <bashquest> hello people
[23:12:37 CEST] <bashquest> ffmpeg -f concat -safe 0 -i <(for cut in *00*; do echo file "${cut@Q}"; done) -c copy out.mp
[23:13:06 CEST] <bashquest> problem is the pipe, <(...), i want to inline the file with the media to concatenated.
[23:13:20 CEST] <bashquest> when i look at the docs, ...
[23:13:31 CEST] <bashquest> they show me an example with <(...) ...
[23:14:11 CEST] <bashquest> ffmpeg answers with "impossible to open /dev/fd/mypipe"
[23:15:26 CEST] <cehoyos> classsic: Please paste the command line you tested together with the complete, uncut console output to a webpage of your choice and post the link here.
[00:00:00 CEST] --- Wed Sep 18 2019
1
0
[00:11:41 CEST] <Lynne> philipl: the only fence used is for queue submission, the only way for the fence not to trigger is if the queue hasn't finished if it waits for something
[00:11:54 CEST] <Lynne> which it does; the semaphore the image has
[00:12:52 CEST] <Lynne> so maybe something is going wrong with cuda signalling the imported semaphore?
[00:21:45 CEST] <Lynne> vulkan defines some synchronization scopes for semaphores which really absolutely no one understands
[00:38:51 CEST] <philipl> Yeah. I think this is beyond where I have meaningful knowledge.
[00:39:02 CEST] <philipl> haasn: feeling generous and want to take a look?
[00:39:35 CEST] <philipl> I can say you are deleting the semaphore on each map that re-uses a frame. You shouldn't do that. Keep the semaphore around for the lifetime of the frame.
[00:39:56 CEST] <BtbN> Why is this such a mess, wow.
[00:40:52 CEST] <philipl> So if I do a simpler command line with hwmap and no hwdownload, and I don't destroy semaphores every time, it will run to completetion and then deadlock destroying the external semaphores during final cleanup
[00:41:10 CEST] <philipl> That happens even if I don't signal the semaphores. Which seems illogical.
[00:41:37 CEST] <philipl> Lynne: are you testing with the nvidia card as your primary GPU? That's really hard as it tends to lock your desktop up when it deadlocks
[00:41:59 CEST] <philipl> BtbN: quite
[00:43:02 CEST] <BtbN> You never can be sure if you just hit a driver bug or are doing something wrong with this.
[00:43:44 CEST] <BtbN> At least Vulkan is generally quite actively developed and Nvidia is probably interested in feedback.
[00:45:09 CEST] <philipl> It's hard for me to compare how you're doing it vs how libplacebo does it; I see a bunch of small things which might be a problem. eg: libplacebo does an explicit transition for the image to an 'exported' state and then when you transition on the transfer_to, you have to set the right src properties (like there's an external transfer queue family)
[00:45:50 CEST] <philipl> I know when haasn and I were working on this in libplacebo, you could cut a lot of corners and it appeared to work but you never know when the driver will start caring.
[00:46:14 CEST] <BtbN> Most of this is potentially a noop internally at the moment lol
[00:47:34 CEST] <philipl> Yeah, Until it isn't.
[00:48:00 CEST] <philipl> I can't say if this is a driver bug, but libplacebo is an existence proof that you can write it in a way that works.
[00:48:11 CEST] <philipl> Lynne: never too late to depend on libplacebo :-P
[00:48:43 CEST] <BtbN> I just hope they don't throw the current infra over board at some point in the future, for something new...
[00:49:16 CEST] <philipl> replacing vulkan? Hopefully that doesn't happen too soon.
[00:49:28 CEST] <BtbN> No, replacing the current Vulkan extensions to do that stuff.
[00:50:03 CEST] <philipl> BtbN: well, if they successfully define and implement the vulkan api for video decode/encode, then all this external api shit will go away.
[00:50:20 CEST] <BtbN> At least on the decode side.
[00:50:33 CEST] <BtbN> I doubt Vulkan Encode would get a lot of traction from any vendor except Intel.
[00:51:02 CEST] <philipl> Unfortunately, probably true. and decode probably would only get traction from AMD.
[00:51:23 CEST] <BtbN> I can see Nvidia implementing Vulkan Decode
[00:51:35 CEST] <JEEB> I just learned yesterday that openMAX was actually a khronos thing for hwdec/-enc
[00:51:44 CEST] <JEEB> definitely did not know that before
[00:51:50 CEST] <philipl> With a new team, new implementation, and new feature set vs nvdec and vdpau. *sigh*
[00:51:50 CEST] <BtbN> And on the Encode side it's not too important. And it makes sense that ever vendor wants to expose the full capabilities of the HW, and not some agreed upon subset that all vendors can support.
[00:52:09 CEST] <Lynne> philipl: not depending on libplacebo, shut up about this.
[00:52:22 CEST] <philipl> BtbN: that's why vulkan is so great. Every vendor bullshit idea can be an official extension.
[00:52:31 CEST] <JEEB> Lynne: he did not attempt to make you change :P
[00:52:44 CEST] <JEEB> just noted that he wasn't sure what of the differences between caused any issues
[00:52:55 CEST] <JEEB> if any
[00:52:57 CEST] <Lynne> of course a simpler command line with just a hwmap doesn't work, the semaphore is in theory in a signalled state so it would be illegal to destroy it
[00:53:16 CEST] <Lynne> putting a wait before semaphore destruction didn't help, tried that
[00:53:20 CEST] <philipl> Lynne: except, as I said, if I comment out signalling it still deadlocks.
[00:53:25 CEST] <philipl> on destroy
[00:54:11 CEST] <Lynne> we really can't keep semaphores around, they're awful and if a client gives a semaphore in a bad state it could freeze everything
[00:55:19 CEST] <Lynne> so the simplest thing to do is to wait on them the first possible chance then destroy them and rely on events instead
[00:55:19 CEST] <philipl> maybe special case the exported cuda semaphores to retain them. Those aren't coming from a client and the hwcontext should be able to control their state.
[00:56:07 CEST] <philipl> Of course, pragmatically, you'd never see a synchronisation issue if you ignored the cuda semaphores. The pool means it's very unlikely to reuse a frame too soon.
[00:58:08 CEST] <Lynne> the synchronization issues start earlier if the memcpy2d hasn't finished by the time you pass the frame via a command buffer to a queue
[00:58:43 CEST] <philipl> (and you don't have semaphores for cuda to wait on yet anyway). I never saw an actual issue with the vulkan side reading too soon after the memcpy before I had semaphores working in mpv. FWIW.
[00:59:23 CEST] <philipl> We had the opposite problem. Using a single shared VkImage, we'd see multiple writes complete before a read.
[00:59:36 CEST] <philipl> That's when you need to wait on the cuda side for the read to complete.
[01:00:44 CEST] <cone-499> ffmpeg 03gxw 07master:92fc0bfa54d8: avutil/mips: refactor msa SLDI_Bn_0 and SLDI_Bn macros.
[01:00:44 CEST] <cone-499> ffmpeg 03Michael Niedermayer 07master:9fd62b84d57e: tools/target_dec_fuzzer: Adjust motionpixels threshold
[01:00:44 CEST] <cone-499> ffmpeg 03Michael Niedermayer 07master:61b055bed096: libavcodec/utils: Free threads on init failure
[01:00:44 CEST] <cone-499> ffmpeg 03Michael Niedermayer 07master:a9fae76370ba: avcodec/gdv: Replace assert() checking bitstream by if()
[01:00:44 CEST] <cone-499> ffmpeg 03Michael Niedermayer 07master:c80715f15359: doc/examples/decode_audio: Fix "warning: ISO C90 forbids mixed declarations and code"
[01:00:45 CEST] <cone-499> ffmpeg 03Michael Niedermayer 07master:24e52709112e: avformat/hcom: Tell the compiler about set but not read variables
[01:00:45 CEST] <cone-499> ffmpeg 03Michael Niedermayer 07master:fccc37ca85a7: repeat an even number of characters in occured
[01:00:46 CEST] <cone-499> ffmpeg 03Michael Niedermayer 07master:d2d8e797cc4f: avcodec/hevcdec: repeat character in skiped
[01:00:46 CEST] <cone-499> ffmpeg 03Michael Niedermayer 07master:305f6dbb060f: tools/target_dec_fuzzer: increase snows threshold
[01:00:47 CEST] <cone-499> ffmpeg 03Michael Niedermayer 07master:9fac243744c6: avcodec/cfhd: Check that cropped size is smaller than full
[01:00:48 CEST] <cone-499> ffmpeg 03Michael Niedermayer 07master:5c5575c8dc89: avformat/cdxl: Fix integer overflow in intermediate
[01:00:49 CEST] <cone-499> ffmpeg 03Michael Niedermayer 07master:08dc354ef729: avformat/vividas: remove dead assignment
[01:00:50 CEST] <cone-499> ffmpeg 03Michael Niedermayer 07master:8e8fd25272c5: avformat/vividas: Remove align offset which is always masked off
[01:02:12 CEST] <philipl> Lynne: you could also do sync memcpy2d but that probably cripples performance.
[01:02:28 CEST] <BtbN> We use CUstreams pretty much everywhere now
[01:02:32 CEST] <BtbN> they exist precisely for this
[01:02:42 CEST] <BtbN> You sync on the stream at the latest possible moment
[01:04:23 CEST] <BtbN> cudaStreamAddCallback could also be handy to run code precisely after the memcpy has finished. But it's deprecated.
[01:04:32 CEST] <BtbN> cudaLaunchHostFunc is the replacement.
[01:08:59 CEST] <Lynne> even if I don't wait on any semaphores when downloading and don't destroy them ever, there's still a hang
[01:09:10 CEST] <Lynne> I don't get this
[01:11:50 CEST] <philipl> yeah. very strange
[01:21:59 CEST] <Lynne> holy shit
[01:22:10 CEST] <Lynne> cu->cuDestroyExternalSemaphore(&dst_int->cu_sem[i])
[01:22:13 CEST] <Lynne> spot the error
[01:22:38 CEST] <Lynne> then explain why the compiler did not warn
[01:23:11 CEST] <JEEB> wonder if the other one from the two of clang vs gcc would barf at you
[01:35:35 CEST] <philipl> Lynne: ouch.
[01:35:44 CEST] <philipl> I didn't see the warning here either.
[01:37:18 CEST] <philipl> Lynne: so that explains why destroy was always taking a shit.
[01:43:19 CEST] <Lynne> works fine once I fixed that and fixed the vkCmdSetEvent (for some reason bottom of pipe makes it freeze)
[01:55:42 CEST] <philipl> Sounds believable, and nicely done.
[01:56:11 CEST] <philipl> I still recommend not constantly destroying the semaphores. I think it will hurt performance.
[02:00:01 CEST] <Lynne> the thing I'm worried about is the definition of semaphores and how they act withing the defined scopes
[02:00:25 CEST] <Lynne> its not explained well, and if its not explained well how can driver devs even implement this properly
[02:00:58 CEST] <Lynne> I've read various opinions whether you can rely that a signalled semaphore in one queue will be respected on another submission
[02:01:22 CEST] <Lynne> because reading the scopes you'd think that you can't rely on that
[02:02:12 CEST] <Lynne> which means you can't do any synchronization at all with semaphores since they'll only really work for multiple commands submitted at the same time
[02:12:08 CEST] <Lynne> philipl: yeah ok, desroying and creating semaphores again is super expensive
[02:12:23 CEST] <Lynne> not even waiting on them, this is all userspace overhead
[02:12:29 CEST] <philipl> Yeah.
[02:12:41 CEST] <philipl> nvidia definitely want them to stick around and be reused.
[02:13:15 CEST] <philipl> and at least empirically, with mpv, the reuse works fine.
[02:14:11 CEST] <Lynne> which means my previous version of the synchronization system I had worked fine and I need to revert back
[02:27:59 CEST] <Lynne> is hardware frame creation synchronized, e.g. will pool_alloc be called from multiple threads?
[02:38:48 CEST] <rcombs> Lynne: alright Ill bite, why doesn't it warn? (I'm assuming the bug is the &?)
[02:51:35 CEST] <Lynne> rcombs: "note: expected CUexternalSemaphore {aka void *}"
[02:51:58 CEST] <rcombs> ah, I'd looked up the reference and it indicated that was an actual type
[02:52:38 CEST] <rcombs> I once caught a case where apple's AudioToolbox code did exactly the same thing (and the compiler of course did not warn them either)
[02:53:01 CEST] <rcombs> passed a void* to a function taking void* but mistakenly added a &
[02:53:22 CEST] <rcombs> they wouldn't believe me until I pointed them to the line of assembly where they had an lea that should've been a mov
[02:53:57 CEST] <rcombs> and gave example code where passing in a pointer to a 4-byte buffer failed, but passing in (void*)(intptr_t)*(int*)buf worked
[02:54:47 CEST] <Lynne> vulkan does it right btw, "note: expected VkSemaphore {aka struct VkSemaphore_T *}"
[02:56:36 CEST] <rcombs> yeah, and macOS's libc has opaque types for all pthread stuff, but they're actually user-visible structs containing a char opaque[size];, rather than just void
[03:20:31 CEST] <philipl> BtbN: https://github.com/philipl/nv-codec-headers/commit/bfb7e2d35b1eb899029442fa…
[03:20:35 CEST] <philipl> will push if you're ok with it.
[03:20:56 CEST] <philipl> Lynne: that void * problem is on us. See diff
[03:57:20 CEST] <haasn> Lynne: are you using validation layers?
[03:58:25 CEST] <haasn> but yeah just use libplacebo :^)
[11:14:03 CEST] <BtbN> philipl, why the change from structs to void*?
[11:16:22 CEST] <nevcairiel> its the opposite, to avoid accidental errors since compilers will warn about much more this way
[11:16:45 CEST] <BtbN> oh
[11:17:02 CEST] <BtbN> hm, in that case I wonder if that'll break some code. What do the official headers do?
[11:17:56 CEST] <BtbN> I mean, I don't really care if it's void* or struct*, but what's the reason for the change?
[11:18:03 CEST] <nevcairiel> the official headers do what the changed code does
[11:25:20 CEST] <BtbN> Yeah, that's probably fine then.
[11:49:42 CEST] <cone-112> ffmpeg 03Paul B Mahol 07master:921eb21b1d1b: avfilter/x86/vf_360: add most of >8 depth asm
[11:49:43 CEST] <cone-112> ffmpeg 03Paul B Mahol 07master:dc3325076597: avfilter/af_headphone: return on error immediately
[11:49:44 CEST] <cone-112> ffmpeg 03Paul B Mahol 07master:7a7aa4f79e50: avfilter/vf_avgblur: remove dupe assignment
[11:49:45 CEST] <cone-112> ffmpeg 03Paul B Mahol 07master:654601dd1d3b: avfilter/vf_v360: add missing av_assert0()
[11:49:46 CEST] <cone-112> ffmpeg 03Paul B Mahol 07master:fa045c3ce288: avfilter/window_func: clarify intention in dolph window calculation
[11:49:47 CEST] <cone-112> ffmpeg 03Paul B Mahol 07master:f70690e8ece8: avfilter/vf_ciescope: remove dead assignments
[11:49:48 CEST] <cone-112> ffmpeg 03Paul B Mahol 07master:ea8391e519f4: avfilter/vf_shuffleplanes: remove not needed line
[11:49:49 CEST] <cone-112> ffmpeg 03Paul B Mahol 07master:34a12b99788d: avfilter/vf_stereo3d: merge same code in case branches
[11:49:50 CEST] <cone-112> ffmpeg 03Paul B Mahol 07master:94f187d38267: avfilter/vf_stereo3d: assert that out variable is valid
[12:10:08 CEST] <Lynne> haasn: yes, of course, although they're of little help when importing images from APIs
[12:10:21 CEST] <haasn> fair enough
[12:10:29 CEST] <haasn> I guess the layers haven't gotten to any of those extensions yet
[12:11:01 CEST] <Lynne> synchronization issues right now are purely theoretical though, at least with filters
[12:11:32 CEST] <Lynne> since imageviews have to be around until the command buffer has finished executing can't help but block on every queue submission until its complete
[12:12:33 CEST] <haasn> I don't know anything about your design/code but make sure you take a look at https://code.videolan.org/videolan/libplacebo/blob/master/demos/video-filte…
[12:12:46 CEST] <haasn> though iirc ffmpeg filter design requires blocking?
[12:14:51 CEST] <Lynne> on the cpu, only for downloading and uploading
[12:22:32 CEST] <haasn> doing a very quick analysis of avfilter.h it seems like activate() roughly translates to api2_process()
[12:22:47 CEST] <haasn> with input/output links roughly translating to my get_frame / put_frame
[12:22:58 CEST] <haasn> so it should definitely be possible to do nonblocking processing here
[13:22:18 CEST] <Lynne> haasn: yeah, but how do you deal with imageview lifetimes?
[13:23:16 CEST] <haasn> I'm not entirely sure what the context is
[13:23:16 CEST] <Lynne> vulkan doesn't give you any callbacks after a command buffer has completed, so you'd need to store imageviews on the frame and free them after a subsequent command buffer submission has completed, since the previous one would be guaranteed to have finished
[13:23:35 CEST] <haasn> what images are those imageviews attached to?
[13:23:46 CEST] <Lynne> the frames you give lavfi
[13:25:58 CEST] <haasn> assuming I do need to keep track of a unique VkImage on every frame and am not able to reuse/recycle them (depends on cooperation with the provider of images), we would indeed be forced to hold on to imageviews as long as needed for validity
[13:26:08 CEST] <haasn> (that's sort of what happens under the hood if you pl_tex_destroy with libplacebo)
[13:26:43 CEST] <haasn> that doesn't mean we have to block until this is the case before we start sending more work to the GPU, though, if that's what you were implying
[15:12:04 CEST] <cone-852> ffmpeg 03sharpbai 07master:6966548c1bd8: avcodec/videotoolboxenc: fix encoding frame crash on iOS 11
[15:12:04 CEST] <cone-852> ffmpeg 03Limin Wang 07master:57951f301906: avcodec/videotoolboxenc: add H264 Extended profile and level
[15:12:04 CEST] <cone-852> ffmpeg 03Rick Kern 07master:1db6e47e8599: avcodec/videotoolboxenc: warn user when output will use a different profile/level than requested.
[16:12:55 CEST] <Lynne> >av_map_videotoolbox_format_from_pixfmt2
[16:13:04 CEST] <JEEB> 33
[16:13:09 CEST] <Lynne> we really should have a hwcontext api to map pixfmts
[16:13:22 CEST] <Lynne> I think there was a patch even
[16:24:23 CEST] <JEEB> also I wonder if we should do something about the high time base by default for subtitles in mp4?
[16:24:35 CEST] <JEEB> it shows up currnetly if you have a subtitle that is over 37 or so minutes long
[16:24:38 CEST] <JEEB> :P
[16:48:49 CEST] <BBB> i want to tell my compiler that left-shifting a negative value is just fine; can i do that?
[16:49:03 CEST] <BBB> -std=c99-with-leftshift-defined or so
[16:49:38 CEST] <jamrial> send patch to gcc :p
[16:51:10 CEST] <jamrial> i suppose there should already be an option to silence related warnings that can be detected at compile time, but these reports are for runtime with ubsan, so...
[17:02:39 CEST] <BBB> i probably needto send a patch to the c standards committee first
[17:09:37 CEST] <Lynne> do it; they're already considering classes from c++ I think
[17:10:10 CEST] <Lynne> or was it raii
[18:16:14 CEST] <philipl> BtbN: pushed to all branches
[18:17:48 CEST] <Lynne> tnx
[19:25:34 CEST] <cone-616> ffmpeg 03Paul B Mahol 07master:d87db83e1cad: avfilter/vf_v360: rename r_tmp variables
[19:25:34 CEST] <cone-616> ffmpeg 03Paul B Mahol 07master:c271d88257e7: avfilter/vf_v360: move some local variables to private filter context
[19:25:34 CEST] <cone-616> ffmpeg 03Paul B Mahol 07master:cf62110a8381: avfilter/vf_v360: simplify allocating remap data
[19:25:34 CEST] <cone-616> ffmpeg 03Paul B Mahol 07master:a09213da23e7: avfilter/vf_v360: reverse order of remap for loops
[19:25:34 CEST] <cone-616> ffmpeg 03Paul B Mahol 07master:05ffaa252ee8: avfilter/vf_v360: refactor creation of remap data
[19:25:35 CEST] <cone-616> ffmpeg 03Paul B Mahol 07master:6f4ec4d909cc: avfilter/vf_v360: add slice threading to remap calculation
[20:20:51 CEST] <durandal_1707> cehoyos: have you committed that audio decoder yet?
[20:25:43 CEST] <cehoyos> "That audio decoder?"
[20:26:05 CEST] <durandal_1707> you wrote only one
[20:27:41 CEST] <durandal_1707> the acelp.kelvin
[20:32:38 CEST] <cone-616> ffmpeg 03James Almer 07master:dc0806dd2588: avcodec/allcodecs: make libdav1d the preferred AV1 decoder
[20:32:55 CEST] <jamrial> BBB: ^
[20:33:38 CEST] <BBB> \o/
[20:33:39 CEST] <cehoyos> I wanted to write "of course" but apparently not;-)
[20:58:34 CEST] <cone-616> ffmpeg 03Carl Eugen Hoyos 07master:551fcbbccbca: lavc/g729dec: Support decoding Sipro ACELP.KELVIN.
[21:14:20 CEST] <cehoyos> durandal_1707: Shouldn't this be: "ACT flag != frame header is not supported, please ...."?
[21:14:53 CEST] <durandal_1707> yes
[21:15:09 CEST] <cehoyos> Or maybe "ACT flag != frame header (expect wrong colours" is not supported"
[21:17:28 CEST] <durandal_1707> it is random block flag vs frame header
[21:22:17 CEST] <cehoyos> Something that tells the user that wrong colours are possible (or expected)
[22:14:25 CEST] <cone-616> ffmpeg 03Andreas Rheinhardt 07master:3ab488a5407f: avcodec/ttaenc: Fix undefined shift
[00:00:01 CEST] --- Tue Sep 17 2019
1
0
[06:10:30 CEST] <bpleat> Windows 10 x64, ffmpeg v4.2 64-bit static.
[06:11:33 CEST] <bpleat> (I've tried longer functions, but I can't even get the basic to work... feel like a DFU here)
[09:26:53 CEST] <petecouture> I have an HLS live stream process which is concating source mp4s together and using a long filter complex string, transcodes them across a dynamic number of bitrate profiles. However if the source media has different profiles, Im getting HLS playback generation issues where some of the source videos dont encode to HLS. The segments for them dont get formed and the player throws an unlabeled error. Once the playhe
[09:26:54 CEST] <petecouture> reached the end of these videos it seems to pick up again just fine when it loops back to the first media. Duplicating source content shows seemless playback between videos.
[09:27:14 CEST] <petecouture> I know in these cases you need to scale and reset the aspect ratio which Im doing.
[09:27:37 CEST] <petecouture> But playback still throws errors.
[09:28:02 CEST] <petecouture> Here is the script https://pastebin.com/FP5ygvGE
[09:29:52 CEST] <petecouture> Usually in these issues its a timecode sync between media files, but isnt the concat filter supposed to reset that?
[09:50:00 CEST] <petecouture> Guess what Im running into is known. Looks like theres an issue with the concat demuxer being able to handle videos with different parameters.
[11:11:02 CEST] <Radiator> Hi, I have a lot of memory leaks for some reasons I only do a loop on av_read_frame and avcodec_send_packet with a few AVFrames that I make sure I free everytime. I even call av_frame_unref to be sure but in 20s I reach 1GB of memory allocations... Is ffmpeg and its libraries are memory proof ?
[11:14:55 CEST] <pink_mist> if you use them correctly, they won't leak memory
[11:16:54 CEST] <Radiator> Ok, so that's for sure my fault ? Just to be sure, I must use av_frame_alloc and once done with it, av_frame_free, right ?
[11:17:39 CEST] <pink_mist> don't ask me. I have no idea about the API, I just know that ffmpeg is written well enough to not leak memory if used correctly
[11:18:05 CEST] <Radiator> Ahah, that's fine, thanks :)
[11:31:00 CEST] <snooky> moin
[11:32:39 CEST] <cehoyos> Radiator: When you use the term "leak", this implies that you ran valgrind (or an equivalent tool) that shows you exactly where the "leak" happened
[11:33:46 CEST] <JEEB> --leak-check=full --track-origins=yes with valgrind are my go-to things
[11:34:10 CEST] <BtbN> You usually don't have to call av_frame_alloc
[11:34:36 CEST] <BtbN> But depends on what you're doing obviously.
[11:34:51 CEST] <Radiator> cehoyos: Sadly, I work on windows and cannot use valgrind nor gdb
[11:35:10 CEST] <BtbN> keep in mind that video frames are rather large
[11:35:25 CEST] <cehoyos> Equvalent tools exist.
[11:35:30 CEST] <BtbN> so if you are transcoding 1080p or something, 1GB memory use is not unheard of. As long as it does not keep infinitely growing, there's no leak.
[11:35:34 CEST] <Radiator> BtbN: In my case I do, I do hwaccel so I have to alloc them prior to do the transfer form the hardware to cpu
[11:35:41 CEST] <cehoyos> My point was of course that you most likely do not have a memory leak...
[11:35:53 CEST] <Radiator> @Bt
[11:36:48 CEST] <Radiator> Oops, sorry. BtbN: My issue here is that it keep rising to the top. In 40seconds I hit the 2GB and so on. It doesn't stabilize
[11:37:13 CEST] <BtbN> You are not freeing something you allocate then
[11:38:45 CEST] <Radiator> Exactly and I wondered if it would come from my manipulations or the libs. I commented most of my code to highlight the biggest sections and it comes from the decoding. And I always finish by freeing my pointers and all so I don't know
[11:39:36 CEST] <BtbN> It's pretty unlikely that there is a major leak like that in ffmpeg.
[11:39:47 CEST] <Radiator> Yeah I bet
[11:39:53 CEST] <BtbN> You are most definitely doing something wrong.
[11:40:33 CEST] <Radiator> Oh, I don't free the packet, that might be it !
[11:49:59 CEST] <JEEB> one can use gdb just fine, but I still haven't found a proper valgrind alternative on windows :P
[12:10:10 CEST] <Radiator> Well I found the origin. It was the call to av_frame_get_buffer that raped my RAM. Never trust code sample on stack overflow when you don't know what it do.
[13:25:23 CEST] <beniamino> I have some code that is using av_buffersink_get_frame(s->buffersink_ctx, ctx->filt_frame) to get data. It works fine, but now I need to receive frames that have a fixed size. So I replaced it with ret = av_buffersink_get_samples(s->buffersink_ctx, ctx->filt_frame, 1152). I had expected this to be a simple replacement but now the call fails with Cannot allocate memory. Can anyone suggest why this is happening?
[13:26:06 CEST] <JEEB> Radiator: you have some examples on doc/examples. then you can also check the command line applications' usage under fftools/
[13:47:35 CEST] <karanveersingh> #ffmpeg , Need help in running 4k video encoding
[13:49:02 CEST] <karanveersingh> I have a system with 2 socket , 88 core processor with 8GB of RAM , I have to run Transcoding of 4k .mkv video files and do a live streaming using rtmp
[13:49:47 CEST] <JEEB> you might want to check how fast your setup first of all decodes your inputs
[13:49:59 CEST] <JEEB> something like `ffmpeg -v verbose -i INPUT -f null -`
[13:50:13 CEST] <JEEB> then keep adding what you need and checking how the frame rate handles itself
[13:52:21 CEST] <karanveersingh> Below is the command I am using , the problem is that after 2 simoultanious video streams , the fps start dropping and speed become less
[13:52:23 CEST] <karanveersingh> sudo ffmpeg -re -i Stranger09.mkv -c:v libx264 -b:v 50M -preset ultrafast -tune zerolatency -b:a 128k -s 4096x2160 -bufsize 5M -x264opts keyint=500 -g 60 -pix_fmt yuv420p -f flv rtmp://194.167.137.11/live-test/Strange09_4k
[13:53:25 CEST] <cehoyos> (Don't use sudo for encoding with ffmpeg) Try without network output to make sure the network is not the bottleneck
[13:54:02 CEST] <JEEB> also check how many threads libx264 (which you seem to be using) uses by default
[13:54:07 CEST] <cehoyos> And test how many inputs your drive support concurrently
[13:54:09 CEST] <JEEB> and use -threads:v:X to limit
[13:54:36 CEST] <cehoyos> Also, I would expect that slower x264 presets will still run fast enough on your systems
[13:56:01 CEST] <karanveersingh> so as of network bottleneck , nginx+rtmp resides on the same server , so same server is transcoder and streaming
[14:08:03 CEST] <karanveersingh> i have 88 core processor , so is it with libx264 it is cores x 1.5 for frame threads ?
[14:08:51 CEST] <karanveersingh> I can see lot many threads when running top -H -p <pid>
[14:15:46 CEST] <JEEB> you should see it with at least -v verbose when it starts
[14:15:59 CEST] <JEEB> there's x264 logging in there that notes the exact amount of threads it uses by default
[14:16:10 CEST] <JEEB> but yes, I think it does virtual_CPUs * 3 / 2 by default
[14:16:35 CEST] <DHE> there's 2 (?) separate thread pools it uses for encoding.
[14:16:56 CEST] <JEEB> that too
[14:17:05 CEST] <JEEB> it has the lookahead and the primary stuff
[14:17:14 CEST] <JEEB> lookahead one is generally smaller
[14:18:38 CEST] <karanveersingh> As an intel TLC ssd specification , one drive supports 12 streams of 1080p video with H264 encoding with 60 fps
[14:20:28 CEST] <DHE> well that's a bullshit number. what you want is sustained read or write megabytes per second and IOPS for set queue depths
[14:22:07 CEST] <DHE> as an aside, is there any reason you can't pre-transcode the video ahead of streaming it out to the network if you already have it on disk?
[14:22:44 CEST] <karanveersingh> ffmpeg running 36 threads / H264 , so I have to limit my threads ?
[14:23:30 CEST] <karanveersingh> VOD is next task but right now live streaming is needed
[14:25:27 CEST] <karanveersingh> Without sudo as mentioned earlier , the fps and bit rate is dropping more
[14:26:08 CEST] <karanveersingh> Slow preset futher makes the things worse
[14:26:50 CEST] <karanveersingh> ignore the sudo one
[14:29:48 CEST] <kepstin> if you want to run multiple encodes on the system, i'd recommend limiting the threads per ffmpeg so the number of threads used by all the encoders is d the number of cpu threads
[14:31:09 CEST] <karanveersingh> Thanks , thats i am trying right now , threads 2
[14:31:35 CEST] <kepstin> 2 threads is probably not going to be enough for realtime 4k encoding :)
[14:33:37 CEST] <karanveersingh> yea 8)
[14:33:47 CEST] <karanveersingh> can you recommend a good number
[14:37:48 CEST] <kepstin> i don't have your system, so no. You need to test to see how many threads you need for your application.
[14:40:33 CEST] <karanveersingh> Running multiple streams now , 8 threads works fine with single 4k stream
[14:55:51 CEST] <karanveersingh> its not coming up good , 2 concurrent live streams runs fine with many combinations but as soon as I start 3 video , fps drops , speed goes slow
[15:01:42 CEST] <karanveersingh> one Q , is H264 good for 4k .mkv file with Hevc (x265)
[15:04:16 CEST] <DHE> I'd recommend some NUMA awareness in your transcoding. but it means one job can only use half the CPUs because it sticks to one socket
[15:05:33 CEST] <another> i think x264 doesn't scale *that* well
[15:05:44 CEST] <furq> it doesn't
[15:05:50 CEST] <another> do even 1 socket should be fine
[15:05:52 CEST] <furq> you get big diminishing returns around 32 threads iirc
[15:12:12 CEST] <karanveersingh> Below is the command i am using , do point out where it can be corrected
[15:12:14 CEST] <karanveersingh> sudo ffmpeg -re -i Stranger09.mkv -c:v libx264 -b:v 50M -preset ultrafast -tune zerolatency -b:a 128k -s 4096x2160 -bufsize 5M -x264opts keyint=500 -g 60 -pix_fmt yuv420p -f flv rtmp://194.167.137.11/live-test/Strange09_4k
[15:16:20 CEST] <another> don't use sudo
[15:16:21 CEST] <DHE> so just from a consistency standpoint, you have keyint=500 but also -g 60 which is the same parameter
[15:16:32 CEST] <karanveersingh> yea , not using sudo
[15:16:38 CEST] <DHE> yet you keep pasting it
[15:16:59 CEST] <karanveersingh> just realized that
[15:17:26 CEST] <another> remove -tune zerolatency
[15:18:36 CEST] <another> this is definitely not the place to use it
[15:21:41 CEST] <another> also: add -c:a aac
[15:21:56 CEST] <another> just saw that flv defaults to mp3
[15:25:24 CEST] <furq> karanveersingh: zerolatency disables frame threading so that's probably why the performance is bad
[15:28:36 CEST] <karanveersingh> testing it right away , thanks
[15:28:55 CEST] <DHE> and with a CPU like that, I'd guess you could get away with -preset veryfast
[15:29:07 CEST] <DHE> maybe. but if you're experimenting, it'd be worth trying
[15:43:33 CEST] <karanveersingh> Thanks , will try this out
[15:44:05 CEST] <karanveersingh> calling a day after this , will keep trying
[15:44:30 CEST] <karanveersingh> thanks all guys for sharing knowledge
[19:12:23 CEST] <auri_> Is there a way to make the dash muxer skip to a specific segment number? I can seek input through normal means, but starting segment number always remains at 0
[19:55:13 CEST] <Jasper_> Does anyone know who owns https://ffmpeg.zeranoe.com ? The build here is marked as static, but is actually a shared build. https://ffmpeg.zeranoe.com/builds/win64/static/ffmpeg-latest-win64-static.z…
[20:01:50 CEST] <cards> Would anyone here be inclined to take up maintaining SWF (vector flash) to MPEG conversion? People from the site NewGrounds started a project 2 years ago but it's not actively maintained, and could use a bit of polishing. https://github.com/Herschel/Swivel
[20:01:53 CEST] <cehoyos> Jasper_: Do you mean the binary does not work?
[20:02:44 CEST] <cehoyos> cards: We already work on a project that involves some work, why don't you clone the repository and start working on it?
[20:02:47 CEST] <cards> Swivel has a few bugs when dealing with SWF animations that automatically loop at the end, or have "click to play" screens at the beginning, especially.
[20:02:48 CEST] <Jasper_> cehoyos: it relies on DLLs. There are existing tools out there that download that zip file, extract only ffmpeg.exe, and expect it to work :/
[20:03:00 CEST] <cehoyos> Again: Does the binary not work?
[20:03:05 CEST] <cards> cehoyos: why don't I what?
[20:03:36 CEST] <Jasper_> cehoyos: not without the corresponding DLL files, which should not be the case for a static build.
[20:03:48 CEST] <cehoyos> cards: How do you know that https://github.com/Herschel/Swivel could use a bit of polishing?
[20:03:56 CEST] <cards> are you one of those "why don't you do it if you're such a master programmer, which you never claimed to be, but you dared to speak in here" insufferable people?
[20:04:04 CEST] <cehoyos> You did claim it;-)
[20:04:13 CEST] <cards> pretty sure i didn't
[20:04:33 CEST] <cehoyos> In this case: Sorry, I am not a native speaker, this is how I interpreted it.
[20:05:03 CEST] <cehoyos> jasper_: See https://ffmpeg.zeranoe.com/forum/
[20:05:21 CEST] <cehoyos> Note that I am surprised that the binaries do not work (but bugs are of course possible)
[20:05:46 CEST] <Jasper_> Future static builds are fine. It's just the one marked "latest" (which is not latest)
[20:06:26 CEST] <cehoyos> I don't see "latest" on the Download page...
[20:06:56 CEST] <Jasper_> You can see it from the open directory here, which is linked to by the front page: https://ffmpeg.zeranoe.com/builds/win64/static/
[20:07:27 CEST] <Jasper_> I was referred to this channel by the footer of the site, so I imagined the maintainer might be in here
[20:07:33 CEST] <cehoyos> https://ffmpeg.zeranoe.com/builds/win64/static/ffmpeg-20190916-1db6e47-win6… Did you try this one?
[20:07:45 CEST] <cards> Jasper_: which exact version is bad
[20:07:48 CEST] <Jasper_> That one also looks to be broken
[20:08:16 CEST] <cehoyos> See https://ffmpeg.zeranoe.com/contact/ for the actual contact (The FFmpeg project does not offer binaries, we do not own zeranoe.com)
[20:08:18 CEST] <Jasper_> ffmpeg-20190916-1db6e47-win64-static.zip has a filesize of 25MB, compared to the rest of them which have filesizes of 63MB.
[20:08:21 CEST] <cards> it's the official download site for windows builds, but i never had a problem with the static download. you can tell it's a static download because the files are YUGE
[20:08:25 CEST] <cehoyos> Yes, I saw this
[20:08:55 CEST] <cehoyos> Note that there is nothing "official" about Zeranoe, we offer a line (as we do for other people who are not more "official")
[20:09:01 CEST] <cehoyos> s/line/link
[20:09:05 CEST] <cards> hmm
[20:09:53 CEST] <cards> Jasper_: you appear to be correct. the win64 20190916-1db6e47 build for Static and Shared are the same filesize, give-or-take 100kb
[20:10:00 CEST] <Jasper_> Yeah, but since it was linked, I wondered if the maintainer was lurking in here
[20:10:09 CEST] <cards> Static should be 3x the filesize
[20:10:45 CEST] <cards> i'd just use the 4.2.1 for now then
[20:11:12 CEST] <cehoyos> Note that release builds contain more bugs and less features than current git head and are therefore unsupported here and on the bug tracker;-)
[20:11:40 CEST] <cards> still, nightly builds should be built right
[20:11:52 CEST] <Jasper_> Yep. There are just some tools like https://github.com/ShareX/ShareX/blob/master/ShareX.MediaLib/FFmpegDownload… which are hardcoded to the latest URL
[20:12:03 CEST] <cehoyos> https://ffmpeg.zeranoe.com/builds/win64/static/ffmpeg-20190914-8efc9fc-win6… This seems the last working build afaict
[20:12:23 CEST] <cehoyos> Then contact Zeranoe
[20:13:23 CEST] <Jasper_> Yeah, I was trying to find their contact information -- seems that form is the best anyone can find. Cheers.
[20:13:41 CEST] <cards> "Kyle Schwarz" <zeranoe(a)gmail.com>
[20:13:54 CEST] <cards> it's on the bottom of that download page
[20:13:54 CEST] <Jasper_> Thanks!
[20:14:30 CEST] <cards> well actually, his email is on the github linked from his dl page
[20:17:48 CEST] <cards> cehoyos: I would say that his builds are as "official" as official can get in an open source project. 99.7% of the users of ffmpeg are using his builds.
[20:18:03 CEST] <cards> not a mere courtesy link
[20:19:08 CEST] <cehoyos> It is exactly that: A courtesy link
[20:20:07 CEST] <cards> you lose the right to call something a mere unofficial courtesy link when it becomes the defacto standard though
[20:20:40 CEST] <cehoyos> From a quick look, Kyle Schwarz has no commit rights, he rarely comments on any FFmpeg mailing list, I don't think he was ever at one of the developer meetings
[20:20:42 CEST] <beniamino> (I posted this earlier but am hoping some people in different time zones might be on now). I have some code that uses libav to transcode music into mp3 format. The code currently uses libmp3lame but I want to use libshine for speed on a raspberry pi. Unlike libmp3lame, libshine requires a fixed frame size. The original code fetches music from a sink using av_buffersink_get_frame(&). I had hoped to replace this with av_buffersink_get_samples(&, frame_size)
[20:20:43 CEST] <beniamino> I can pass the resulting frames to libshine. However, when I do this, av_buffersink_get_samples failes with error -12 Cannot allocate memory (though av_buffersink_get_frame works fine). Can anyone suggest why this might happen?
[20:20:46 CEST] <cards> "do you use windows? the most popular operating system in the world? click here!"
[20:21:30 CEST] <cehoyos> The same is true for the other people who offer FFmpeg binaries (vlc binaries, by comparison, are offered by the videolan developers themselves)
[20:21:46 CEST] <cards> cehoyos: there you go again believing that the only way someone can be involved in a project is to commit code changes
[20:21:59 CEST] <cehoyos> This has nothing to do with MS Windows, the same is true for the macos and linux static binaries that are also offered by kind supporters
[20:22:38 CEST] <cards> there are a lot of non-coders in the world who contribute to projects. such as site hosts, Q&A, bug finders, app integrators, and end-users.
[20:22:50 CEST] <cards> those people are more important than the coders themselves
[20:22:53 CEST] <cehoyos> No, there are many are many other ways to be involved: Posting on the user mailing list, being active on irc, coming to developer meetings, run the infrastructure of the project etc.
[20:25:05 CEST] <cehoyos> But neither Kyle nor this guy - https://evermeet.cx/ffmpeg/ - who even mentions "I'm not in any way affiliated with ffmpeg.org"
[20:25:26 CEST] <cehoyos> are part of the FFmpeg project
[20:25:45 CEST] <cards> ffmpeg.org is not "the project"
[20:26:03 CEST] <cards> it's an entity that is party to the project
[20:26:26 CEST] <durandal_1707> everyone is part of FFmpeg
[20:26:41 CEST] <cehoyos> Just to make sure: From all we (the FFmpeg developers) know, Kyle (and his counterparts) could be people who secretely plan to attack you, we simply cannot know
[20:26:50 CEST] <cehoyos> (Personally, I trust them completely)
[20:28:09 CEST] <cards> cehoyos: i would hope that [you] (ffmpeg developers and project managers) have a little more "know" before linking to and establishing the most popular download site for ffmpeg builds known
[20:28:26 CEST] <cehoyos> Sadly, we do not...
[20:28:42 CEST] <cehoyos> (That's what I tried to explain)
[20:28:45 CEST] <cards> you speak for the organization?
[20:29:05 CEST] <cehoyos> No, there is no "organization" and nobody can speak for FFmpeg
[20:29:09 CEST] <durandal_1707> they are unofficial builds
[20:29:14 CEST] <furq> they're builds some guy makes that a lot of people use
[20:29:52 CEST] <furq> it's a courtesy link on the site because otherwise 99% of lines in this channel would be "hi how do i run a .tar.bz2 on windows 10"
[20:30:02 CEST] <cehoyos> LOL, yes
[20:30:15 CEST] <cards> anyone can automate windows builds if they want to
[20:30:19 CEST] <furq> they sure can
[20:30:22 CEST] <furq> lots of people do
[20:30:31 CEST] <cards> you don't have to rely on some random Nigerian Prince to do it for you
[20:30:59 CEST] <cards> there are github plugins that perform this function
[20:31:00 CEST] <cehoyos> Please consider doing it (I have a suspicion you get a lot of traffic that you can use)
[20:31:32 CEST] <cehoyos> The FFmpeg project only provides source code, no binaries
[20:31:48 CEST] <cards> that's not something you want to brag about
[20:31:59 CEST] <cehoyos> You misunderstand...
[20:36:02 CEST] <beniamino> I cant see from the docs any reason why av_buffersink_get_samples(&, frame_size) would fail when av_buffersink_get_frame(&) works. Yet just making that one change makes the code crash reliably
[20:37:08 CEST] <durandal_1707> beniamino: av_buffersink_get_samples may return AVERROR(EAGAIN) , meaning it needs more data?
[20:43:09 CEST] <beniamino> durandal_1707: The code handes AVERROR(EAGAIN) by just waiting for more data. But av_buffersink_get_samples fails with a different error code. Its -12 which I think is AVERROR(ENOMEM)
[20:44:08 CEST] <durandal_1707> beniamino: and how you setup filter graph?
[20:44:56 CEST] <beniamino> durandal_1707: Im not sure how to answer that question :-) but the code is here: https://github.com/ejurgensen/forked-daapd/blob/master/src/transcode.c
[20:46:09 CEST] <durandal_1707> seen this? http://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/examples/filtering_audio…
[20:48:06 CEST] <durandal_1707> that code first check frame than error code, while it should be other way around
[20:55:13 CEST] <beniamino> interesting. can you clarify what exactly do you mean by check frame? lines 264 onward of your link seem to have a similar logic to lines 599 onward of mine
[20:55:38 CEST] <durandal_1707> frame is nott NULL
[21:08:14 CEST] <beniamino> i switched them and it didnt make a difference. but i will look more carefully at the logic of that bit
[00:00:01 CEST] --- Tue Sep 17 2019
1
0
[10:40:21 CEST] <cone-271> ffmpeg 03Paul B Mahol 07master:7f8f886344fa: avfilter/vf_v360: refactor dimensions and offsets calculations
[10:54:40 CEST] <cone-271> ffmpeg 03Paul B Mahol 07master:5a9560dfc6f2: avfilter/vf_stereo3d: add tb (top-bottom) aliases
[14:31:00 CEST] <Lynne> philipl: ping
[15:31:42 CEST] <cone-271> ffmpeg 03James Almer 07master:78f52b4fe388: avformat/rmdec.c: fix left shift of negative value in rm_sync()
[16:05:45 CEST] <cone-271> ffmpeg 03James Almer 07master:4c34ed65f685: avformat/rmdec.c: fix brackets around arguments
[16:28:23 CEST] <cone-271> ffmpeg 03James Almer 07master:6c0167f6f67b: avcodec/libdav1d: use the library default for the filmgrain option
[16:35:21 CEST] <durandal_1707> why you bumped version? this is outrageous?
[16:35:54 CEST] <jamrial> because it changed a default
[16:36:03 CEST] <jamrial> and it's micro. it's absolutely irrelevant :p
[16:36:21 CEST] <durandal_1707> not really, i now need to recompile whole tree
[16:37:09 CEST] <jamrial> true, but ccache should take care of it
[16:44:53 CEST] <Lynne> it won't, but its a few minutes at most. the biggest issue is forgetting what you configured the dir with
[16:52:28 CEST] <iive> Lynne, theoretically, if you ccache the prepreocessed output it should be able to cache.the result, since the micro is not used directly in the code.
[16:55:20 CEST] <Lynne> isn't it the same as adding filters? all it does is it adds a line to config.h which causes everything to get recompiled
[16:56:46 CEST] <jamrial> yes, it all gets recompiled because of different timestamps in a header included by everything, but as far as ccache is concerned, there were no changes in the preprocessed output of most files
[18:01:28 CEST] <durandal_1707> how to move 8bytes in AVX2 ?
[18:08:17 CEST] <durandal_1707> movq
[18:23:48 CEST] <durandal_1707> ccache is bad
[18:24:55 CEST] <bencoh> why?
[18:28:24 CEST] <durandal_1707> because it forces to recompile tree almost all the time
[18:28:29 CEST] <philipl> Lynne: I'll look today. Sorry for the delay.
[18:37:03 CEST] <durandal_1707> Lynne: use some git repo
[18:39:51 CEST] <Lynne> I'm busy right now writing a gtksourceview language definition for nasm
[18:40:05 CEST] <durandal_1707> what? that does not make sense
[18:40:25 CEST] <Lynne> I demand some color in my assembly, maybe that'll help me write fft assembly
[18:40:59 CEST] <durandal_1707> like every real programmer, code in vim
[19:47:19 CEST] <jamrial> durandal_1707: don't troll people on github
[19:47:29 CEST] <jamrial> just ignore him
[20:00:53 CEST] <Lynne> durandal_1707: you troll people on github?
[20:10:41 CEST] <cone-271> ffmpeg 03Aman Gupta 07master:81abf90aeae6: avcodec/v4l2: fix compile with older videodev2.h
[20:14:08 CEST] <cone-271> ffmpeg 03Rodger Combs 07master:77937a42e712: lavc/videotoolboxdec: fix crop handling when multithreaded
[20:22:13 CEST] <durandal_1707> Lynne: only sometimes
[20:32:47 CEST] <Lynne> according to https://www.nasm.us/doc/nasmdoc3.html we use invalid octal notation throughout all our code
[20:33:15 CEST] <Lynne> apparently q1234 o1234 aren't valid, they need to be prefixed by 0, so 0q1234 0o1234
[20:33:48 CEST] <BtbN> What about yasm?
[20:34:05 CEST] <durandal_1707> yasm not used anymore
[20:34:24 CEST] <BtbN> I don't remember it being dropped entirely. And pretty much all distros still build with yasm.
[20:34:34 CEST] <durandal_1707> tell them to stop
[20:34:44 CEST] <BtbN> They won't care.
[20:35:05 CEST] <BtbN> Only thing they would care about is if a release dropped support.
[20:42:37 CEST] <Lynne> I'm pretty sure no one uses gedit but me, and I'm pretty sure I'm too lazy to make a PR, but the lang description I'm writing is for intel syntax in general but with whatever macros x86inc/util defines
[20:45:27 CEST] <durandal_1707> Lynne: you are not my hero anymore, you are gedit user - disappointed
[20:45:45 CEST] <philipl> Lynne: give me a command line to repro?
[20:53:13 CEST] <iive> Lynne, that notation is created by x86inc.h
[20:53:43 CEST] <iive> or whatever the one from x264 asm extension we use.
[20:53:45 CEST] <Lynne> philipl: "./ffmpeg_g -init_hw_device "vulkan=vk:1,debug=0" -hwaccel nvdec -hwaccel_output_format cuda -i sample.mkv -filter_hw_device vk -vf hwmap,hwdownload,format=nv12 -f null -"
[20:55:37 CEST] <philipl> Lynne: thanks. Got it
[20:55:52 CEST] <Lynne> durandal_1707: its comfy, I'd use kate but it pulls in half of kde and screams to install vlc for you
[20:56:43 CEST] <Lynne> its got tabs you can address with alt+num, minimap, highlight search, all you really need from a text editor
[20:57:07 CEST] <Lynne> not even kate has alt+num tab jumping, you can only switch to next/prev tab
[21:03:51 CEST] <durandal_1707> Lynne: it does not have record commands and vertical selection mode
[21:37:14 CEST] <durandal_1707> 18432x1536 is new gen video
[21:39:24 CEST] <thardin> 12:1 aspect?
[21:40:38 CEST] <Lynne> 36 1024x768 CRTs tiled 18x2?
[21:45:28 CEST] <durandal_1707> 6x1 3D SBS cubemap
[22:50:04 CEST] <Lynne> are the people who work on libaom high?
[22:50:59 CEST] <Lynne> they've enabled delta-q adjustments and do some sort of simplistic mbtree-like aq using that signalling system
[22:51:07 CEST] <Lynne> by default
[22:52:01 CEST] <Lynne> aq using a system which doesn't have any prediction, doesn't have a map to use in between frames, and is only granular enough for superblocks, which can be huge (by default)
[22:52:44 CEST] <Lynne> and they've also broken aq-mode=2 so it breaks on the second gop its used on
[22:54:33 CEST] <Lynne> they're wasting bits signalling dubious quantization deltas in a wasteful way, and probably don't care because oil painting hides the few bits that were lost well
[22:55:09 CEST] <JEEB> lol
[22:55:40 CEST] <JEEB> yea, I think we also noticed that the tagged 1.0errata1 seems to fail at various youtube streams?
[22:55:45 CEST] <JEEB> for decoding
[22:55:55 CEST] <JEEB> I guess they don't notice because they're using some other hash/tag
[22:57:21 CEST] <jamrial> JEEB: they are using dav1d :p
[22:57:26 CEST] <jamrial> if you're talking about chrome
[22:57:46 CEST] <JEEB> hah :DDD
[23:58:24 CEST] <philipl> Lynne: In my quick repro here, I see that it's stopping in vkWaitFences, and it does this whether the cuda side signals the semaphore or not.
[23:58:40 CEST] <philipl> From what you previously wrote, that's not the symptom you see.
[23:59:14 CEST] <philipl> libavutil/hwcontext_vulkan.c:2457
[00:00:00 CEST] --- Mon Sep 16 2019
1
0
[17:04:36 CEST] <beniamino> I am trying to modify some code which uses libav to do mp3 encoding. Currently the encoder uses libmp3lame. I want it to use libshine. The code selects the codec with codec_desc = avcodec_descriptor_get(AV_CODEC_ID_MP3); encoder = avcodec_find_encoder(AV_CODEC_ID_MP3); I had expected to be able to replace AV_CODEC_ID_MP3 with an equivalent for
[17:04:36 CEST] <beniamino> libshine, but I see that all mp3 encoders have the same ID, and libav chooses the default mp3 codec. How can I change the default, or otherwise select libshine instead of libmp3lame?
[17:06:14 CEST] <pink_mist> I don't know the proper answer to your question, but perhaps you could rebuild your ffmpeg libraries to remove libmp3lame support
[17:06:25 CEST] <pink_mist> and only have libshine support included?
[17:08:32 CEST] <durandal_1707> avcodec_find_encoder_by_name
[17:11:49 CEST] <beniamino> pink_mist: that's a reasonable work around but i'd like to avoid that if possible
[17:15:39 CEST] <JEEB> I don't think that's a workaround
[17:15:45 CEST] <JEEB> if you want a specific encoder, you want a specific encoder
[17:16:31 CEST] <JEEB> also geez, I didn't even remember we had shine :P
[17:16:57 CEST] <JEEB> beniamino: the name is the only outwards visible explicit unique identifier
[17:17:14 CEST] <JEEB> so for an external API user that is the only way to get a specific decoder or encoder
[17:20:57 CEST] <pink_mist> JEEB: the workaround was recompiling ffmpeg, not using the API like durandal_1707 suggested
[17:20:59 CEST] <DHE> can confirm. go with an exact name match if you want. if not available, go with the auto-selected by codec ID. If not available, complain and fail.
[17:21:09 CEST] <JEEB> pink_mist: roger
[17:21:39 CEST] <JEEB> DHE: depends on the use case. if the API application specifically wants some encoder you can fail at failing to find the encoder
[17:22:02 CEST] <DHE> I'm doing that with AAC. fdk if it's available, else let libavcodec choose for me.
[17:22:18 CEST] <beniamino> ok, i think i am making progress with durandal_1707 suggestion using avcodec_descriptor_get_by_name("mp3") and avcodec_find_encoder_by_name("libshine")
[19:18:09 CEST] <friki> Hi, my watermarking script (overlay filter) doesn't works fine when non-square pixels in original video. The input file will be always h=1080 16:9, the overlay file is a 1920x1080 PNG. The expected output is h=1080 16:9 (width may be 1920 or the original, don't really care). Any recommendation on how to handle it with ffmpeg?
[19:19:06 CEST] <JEEB> scale one or the other to match the other
[19:19:07 CEST] <durandal_1707> get both to same SAR
[19:58:13 CEST] <cards> does anyone know anything about converting SWF to MP4? I have a rather extensive collection of shockwave flash videos i'd like to archive in 1080p
[19:58:55 CEST] <JEEB> if it's actual FLV inside it should be quite possible relatively easily
[19:59:01 CEST] <JEEB> if it's vector stuff
[19:59:09 CEST] <JEEB> then you will have to screen capture and render
[19:59:16 CEST] <cards> vector stuff.
[19:59:22 CEST] <JEEB> ouch
[19:59:30 CEST] <JEEB> I wonder what's the best solution for that
[19:59:42 CEST] <JEEB> I've before just used some screen/window capture for that
[19:59:57 CEST] <JEEB> (and most solutions that say they do that do exactly that as well)
[20:00:05 CEST] <cards> there has to be a better way than taking snapshots. computational rendering via commandline
[20:00:15 CEST] <JEEB> you'd wish for that yes
[20:00:44 CEST] <JEEB> but unfortunately as far as I know all of the solutions marketed did just embed the flash in themselves and did screen capture
[20:01:06 CEST] <cards> bleh
[20:01:20 CEST] <JEEB> flash does have an API (f.ex. you can find the headers in mpc-hc's repo for example)
[20:01:35 CEST] <JEEB> that's for the activex component
[20:01:47 CEST] <JEEB> you could look if it looks like something could be possible to utilize for less realtime-requiring rendering
[20:21:34 CEST] <cards> This may be something.
[20:21:38 CEST] <cards> https://github.com/Herschel/Swivel -- https://www.newgrounds.com/wiki/creator-resources/flash-resources/swivel?pa…
[20:22:05 CEST] <cards> and also testing this site based converter @ https://cloudconvert.com/swf-to-mp4
[22:48:33 CEST] <nicolas17> can I speed up a video introducing motion blur instead of dropping frames entirely?
[22:56:52 CEST] <Neomoon> Hello everyone, in looking at the ffmpeg documentation on the .org site I'm trying to understand how the ffpeg documentation differs from ffpeg-all. It appears ffpeg-all includes ffmepg components, my issue is that I'm trying to execute the "-user_agent" command but it appear my homebrew install doesn't support this option.
[00:00:00 CEST] --- Mon Sep 16 2019
1
0