[Ffmpeg-devel-irc] ffmpeg.log.20190919

[burek]

[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%20TX-20/ 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%20TX-20/ 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/18a228bd8822957b41c3f9adc45d078320190919151743/47e1de
[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_tearing
[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_tearing
[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_common_video_formats
[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