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

[burek]

[00:04:21 CET] <lavalike> now I'm running it with VO [gpu] and there are audio problems, ha! of the form: [ffmpeg/audio] aac: Number of bands (54) exceeds limit (44).
[00:05:32 CET] <lavalike> example: https://pastebin.com/raw/GTgGRmn7
[00:06:41 CET] <furq> yeah that looks like junk data
[00:07:03 CET] <lavalike> how can I work around that?
[00:07:12 CET] <furq> watch a better stream
[00:07:29 CET] <lavalike> there seem to be no better streams
[00:08:11 CET] <furq> is it actually breaking playback completely or just showing corrupt video/audio sometimes
[00:08:12 CET] <lavalike> you pick one, I'm 90% sure it'll behave the same way
[00:08:17 CET] <furq> if it's the latter then you can't really do any better than that
[00:08:40 CET] <lavalike> it stops the video, then when the desync detected message pops up, it starts again, usually takes 15 seconds or more
[00:08:55 CET] <lavalike> (it stops the playback of both video and audio to be precise)
[00:09:00 CET] <JEEB> the message from the hls reader hints at something going really wrong :P
[00:09:16 CET] <furq> yeah that is also extremely not good
[00:09:18 CET] <JEEB> and no, it's not necessary for HLS/DASH streams to have broken segments
[00:09:24 CET] <furq> although that shouldn't cause broken segments
[00:09:39 CET] <lavalike> I think it might be something local to the machine
[00:09:39 CET] <JEEB> I produce streams in various places and I'm pretty sure I don't produce garbage
[00:10:07 CET] <furq> JEEB: i mean assuming he can only watch this broken-ass stream
[00:10:21 CET] <JEEB> yes, sure
[00:10:33 CET] <JEEB> just that he noted it in a way that seemed like "test any stream, they'll probaly have this"
[00:10:41 CET] <furq> oh right
[00:10:46 CET] <lavalike> that is what I meant yes
[00:10:56 CET] <furq> if this is happening with every hls stream you watch then something is messed up on your end
[00:11:05 CET] <JEEB> or all the streams he watcher are crappy
[00:11:10 CET] <furq> or that yeah
[00:11:10 CET] <lavalike> you pick one!
[00:11:19 CET] <JEEB> also I wonder if the thing producing the stream just overwrites segments without new names
[00:11:25 CET] <JEEB> or something like that
[00:11:33 CET] <JEEB> that would explain the data just being crapped on top of
[00:12:49 CET] <furq> watch some youtube live stream if you just want to test that you can receive hls
[00:12:54 CET] <furq> that ought to be packaged properly
[00:13:57 CET] <JEEB> https://devstreaming-cdn.apple.com/videos/streaming/examples/bipbop_4x3/bipbop_4x3_variant.m3u8
[00:14:12 CET] <JEEB> this will give a lot of warnings from the MPEG-TS reader because apple did a poo-poo there with the timestamps
[00:14:21 CET] <JEEB> but it has no invalid video/audio data :P
[00:14:35 CET] <JEEB> you can just keep playing bipbop
[00:15:05 CET] <lavalike> wow :)
[00:17:01 CET] <lavalike> hmm I took a random youtube live stream and the AO: [wasapi] suggests it won't give me ffmpeg errors any time soon..
[00:17:36 CET] <lavalike> no I'm wrong it was the same AO in the erroring example
[00:18:08 CET] <lavalike> no errors, nor warning, now I'm puzzled
[00:18:49 CET] <JEEB> it just seems like the people behind the stream you were watching couldn't properly keep the stream on. so most likely when their crap restarts or something, they overwrite segments that you are playing
[00:18:53 CET] <JEEB> or something like that
[00:18:57 CET] <JEEB> in any case, broken segments
[00:20:02 CET] <lavalike> is this consistent with the mac side showing no errors and warnings whatsoever on the same streams?
[00:20:30 CET] <JEEB> for video it just seems like hwdec vs swdec and different errors if any being reported :P
[00:21:20 CET] <lavalike> I smelled something funny when I noticed this windows installation *can't* play any of those streams inside chrome itself
[00:23:54 CET] <lavalike> https://imgur.com/a/IvlxmFy
[00:26:02 CET] <furq> doesn't chrome use lavc on all platforms
[00:26:25 CET] <JEEB> if provided. there are chromium builds without it
[00:26:37 CET] <furq> yeah i know chromium doesn't necessarily
[00:26:37 CET] <JEEB> also on some setups it does use hwdec
[00:26:41 CET] <furq> and firefox doesn't
[00:26:52 CET] <lavalike> ah I might have ended up with a stripped chromium
[00:26:54 CET] <pink_mist> chrome is always a binary from google
[00:27:00 CET] <furq> if it's chromium then yeah that would explain it
[00:27:04 CET] <pink_mist> chromium is the one you can build yourself
[00:27:05 CET] <lavalike> I see
[00:27:21 CET] <JEEB> pink_mist: but people also can end up calling chromium binaries "chrome" :P
[00:27:29 CET] <JEEB> which is why I didn't remove the option from the table
[00:27:33 CET] <pink_mist> ah
[00:27:45 CET] <lavalike> and I just confused things by doing exactly that
[00:28:36 CET] <furq> chromium on windows often has no h264 decoder for licensing reasons
[00:28:41 CET] <furq> chromium builds, that is
[00:28:53 CET] <furq> and youtube live stuff is always h264, no vp9
[00:28:53 CET] <lavalike> so that explains the chromium playback issue, perfect
[00:29:21 CET] <lavalike> I had imagined a deeper connection between the mpv playback problems but there is none oh well
[00:48:57 CET] <b1rk0ff> what is muxing overhead ?
[00:50:52 CET] <Atlenohen> data that's part of the mux but not part of the video/audio streams
[00:51:24 CET] <Atlenohen> is what I think
[00:53:48 CET] <b1rk0ff> what does it mean if an ffmpeg with filter invocation exits abruptly with this error?
[00:54:42 CET] <DHE> b1rk0ff: muxing overhead is the how much the file size is above the raw stream sums
[00:55:11 CET] <DHE> if audio + video is 100 MB, but the file is 101 MB large, then you have about 1% muxing overhead
[01:00:02 CET] <Kaedenn> How do I export a specific frame of a video file as a png or jpeg?
[01:00:14 CET] <Kaedenn> (working on a thumbnailer program)
[01:00:55 CET] <JEEB> if you need frame exactness I recommend you look into ffms2
[01:01:07 CET] <JEEB> because ffmpeg.c will not do that
[01:01:25 CET] <Kaedenn> eh, I just wanna export frames from like 10% the way through, 20% the way through, etc
[01:01:28 CET] <JEEB> (ffmpeg.c can be pretty much frame exact in various containers/formats, but to be sure you need an index)
[01:01:52 CET] <Kaedenn> exactness isn't really a concern since the frame indexes will be calculated anyway
[01:02:11 CET] <JEEB> Kaedenn: if your inputs always output properly the duration and support seeking exacly enough
[01:02:28 CET] <JEEB> then you can utilize seeking and thumbnail etc filters
[01:02:49 CET] <JEEB> I did actually make a thing as a mental exercize once
[01:02:53 CET] <Kaedenn> I need to know how to use the thumbnail filter (which, as of a few seconds ago, I didn't know existed)
[01:03:15 CET] <JEEB> it just attempts throughout some metric to pick the "most active" frame from given input
[01:03:25 CET] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#thumbnail
[01:03:32 CET] <Kaedenn> ffmpeg -i input.flv -ss 00:00:14.435 -vframes 1 out.png woot
[01:03:34 CET] <JEEB> usually doing ctrl+F on this page is pretty good
[01:03:53 CET] <Kaedenn> ooooh
[01:03:55 CET] <Kaedenn> this is even better
[01:03:58 CET] <Kaedenn> thank you kindly
[01:04:20 CET] <JEEB> but yea, I wrote a thumbnailing app without ffms2 once
[01:04:29 CET] <JEEB> fed it mp4 which has a seeking index
[01:04:31 CET] <JEEB> and it worked pretty well
[01:04:36 CET] <JEEB> fed it an mpeg-ts from broadcast
[01:04:39 CET] <JEEB> and it was hilarious
[01:05:12 CET] <Kaedenn> nice
[01:05:15 CET] <JEEB> so by using ffmpeg.c you gain not having to index the whole thing container-wise :P
[01:05:33 CET] <JEEB> but you do lose being able to know the duration surely
[01:05:36 CET] <Kaedenn> I'm writing this as a python script using subprocess so I don't really have to worry about bindings
[01:05:51 CET] <JEEB> ffms can be utilized from vapoursynth
[01:05:59 CET] <JEEB> which is a python based frame server
[01:07:33 CET] <JEEB> http://up-cat.net/p/a226bc42
[01:07:36 CET] <JEEB> looks like this
[01:07:51 CET] <JEEB> this is not ffms2, but another filter like it
[01:09:14 CET] <Kaedenn> What is `ffms2`?
[01:09:53 CET] <JEEB> https://github.com/FFMS/ffms2/
[01:10:09 CET] <JEEB> based on FFmpeg's libraries, a library providing frame-exact capabilities
[01:15:51 CET] <Kaedenn> the latest tag they have seems to be quite old
[01:16:12 CET] <void09> any good gui programs that can cut .ts that use ffmpeg?
[01:16:35 CET] <void09> i'm sick of inputting timestamps in the terminal
[01:29:55 CET] <JEEB> Kaedenn: there was some bug they want to fix and then cut a new release. unfortunately people are busy/bugs are not simple
[01:30:15 CET] <JEEB> generally people use master in such cases since master in many projects like FFmpeg is supposed to be as stable as releases
[01:34:47 CET] <Kaedenn> understandably
[01:34:54 CET] <Kaedenn> alright, that makes sense
[03:56:24 CET] <void09> .join #ffms2
[03:56:52 CET] <void09> Whoop, no such thing :)
[04:00:17 CET] <void09> JEEB: you around ?
[04:00:38 CET] <void09> I was wondering if you can tell me if it would make any difference to put -ss before/after input file, when cutting a .ts file
[04:08:48 CET] <furq> yes it makes a huge difference
[04:09:07 CET] <furq> mpegts has no seek index so -ss before -i just guesses
[04:12:51 CET] <void09> isn't -ss after -i that just guseses?
[04:13:45 CET] <furq> no -ss after -i decodes the stream
[04:13:58 CET] <furq> so it just discards everything up to the timestamp you asked for
[04:14:29 CET] <furq> it should always be perfectly accurate for any format
[04:15:11 CET] <void09> oh, well that's what I've been using so far, ffmpeg -i -ss -to
[04:15:44 CET] <void09> Must have done over 100 cuts by now, And i'm thinking if there isnt' some easier way, like an mpv script for example
[04:15:59 CET] <furq> there is an mpv script for cutting but it just execs ffmpeg
[04:16:01 CET] <void09> I press A at start point then Z at the end frame, and I get an accurate cut by calling ffmpeg
[04:16:05 CET] <void09> there is ?
[04:16:10 CET] <void09> wow
[04:17:22 CET] <void09> https://github.com/kelciour/mpv-scripts/blob/master/sub-cut.lua
[04:17:23 CET] <void09> this one?
[04:17:50 CET] <furq> there's a few different ones
[04:17:52 CET] <furq> that looks fine though
[04:18:35 CET] <TheAMM> Mind that if you're playing a file with ordered chapters, ffmpeg doesn't load those (mpv does) and the timestamps might be off
[04:19:15 CET] <void09> TheAMM: I am using ordered chapters to cut the extra frames from the raw ffmpeg cut (as it only cuts on keyframe)
[04:19:29 CET] <furq> yeah it'd be nice if there was a lua api to get demuxed streams out of mpv
[04:20:23 CET] <TheAMM> It's easy-ish enough to recreate the timeline if you can dump the chapter xml
[04:20:27 CET] <void09> ideally the script would do a cut at the start-end point, up to the nearest keyframe that includes that frame. and then it would add a chapter that would start/end on the frames that I selected to cut
[04:20:47 CET] <TheAMM> Well, in theory, I've only done it in vapoursynth, I expect ffmpeg concat would get quite messy
[04:21:00 CET] <TheAMM> Yeh, good luck with that
[04:21:27 CET] <void09> i currently do that with mkvtoolnix-gui (adding chapters)
[04:21:43 CET] <void09> I think mkvpropedit would work from the terminal
[04:22:33 CET] <furq> you could try avidemux maybe
[04:22:44 CET] <void09> -c, --chapters <filename>   Add or replace chapters in the file with the ones from 'filename' or remove them if 'filename' is empty
[04:23:20 CET] <void09> but how would I get the corresponding timestamp in the newly cut video (after ffmpeg cuts it), to know the offsets for the chapter ?
[04:24:39 CET] <furq> just subtract -ss from them all
[04:27:02 CET] <void09> but is mpv accurate with the timestamps anyway, in a non indexed format like ts ?
[04:27:40 CET] <void09> the way i do it now, is, seek to the frames i want to cut from/to, and do ffmpeg -i ss first_frame-500miliseconds -to last_frame+500miliseconds
[04:28:00 CET] <void09> if i don't add those, it's possible the frame i want will be left out of the cut
[04:28:27 CET] <void09> now until recently i thougt that's because ffmpeg cuts to the nearest keyframe, not necessarily the nearest that includes the desired timestamp.
[04:28:55 CET] <void09> but JEEB told me it should include that frame, and the timing offset  I need is due to mpv's inaccuracy
[04:29:44 CET] <TheAMM> Remux your .ts into matroska and stop worrying about timestamp issues
[04:30:07 CET] <TheAMM> Then write a simple script or even input command to dump current timestamp to a file upon keypress
[04:30:18 CET] <TheAMM> Seek, tap, repeat, done
[04:30:27 CET] <void09> TheAMM: I am using .mkv as the final format
[04:30:40 CET] <TheAMM> Use it as an intermediary format as well
[04:30:44 CET] <void09> but do not have an intermediate step.
[04:30:51 CET] <void09> right.. i had some errors when i did that
[04:30:56 CET] <void09> something about timestamps
[04:31:01 CET] <void09> non-monotonous.. something
[04:31:05 CET] <TheAMM> Yes
[04:31:10 CET] <furq> mpv can seek accurately in mpegts iirc
[04:31:14 CET] <TheAMM> Because the .ts is f'd up
[04:31:17 CET] <furq> it just takes a while
[04:31:30 CET] <void09> TheAMM: I got it every time, on every cap I did :
[04:31:35 CET] <furq> it obviously has to start decoding the stream straight away to show it to you so it can check if it's in the right place
[04:32:06 CET] <void09> furq: it takes a while ?
[04:32:21 CET] <furq> it takes longer than it would if the file had a seek index
[04:32:32 CET] <furq> it's faster than ffmpeg though
[04:32:32 CET] <void09> It seems equally fast on my pc
[04:32:52 CET] <void09> which is.. ridiculously fast, i can drag the cursos over  the seekbar and get 0 latency
[04:33:09 CET] <void09> 0 perceivable latency. which is the reason i started using mpv in the first place. no other player that I tried could do that
[04:33:11 CET] <furq> it's a lot less fast if you have a very high bitrate file
[04:33:21 CET] <void09> I have ~10mbps 1080i
[04:33:42 CET] <furq> i've tried it with 50mbps stuff and there's a noticeable lag
[04:34:03 CET] <furq> it's not a criticism, there's no way to not have that
[04:34:29 CET] <void09> h265 gets decoded in the gpu ? with shaders, not the video decoding asic
[04:34:36 CET] <void09> by default, with mpv ?
[04:35:05 CET] <furq> that's not up to mpv
[04:35:17 CET] <void09> of course it is
[04:35:31 CET] <furq> you just turn hwaccel on or off and then it'll be decoded if your system hwaccel supports it
[04:35:43 CET] <furq> or not
[04:35:50 CET] <void09> assuming you have competent hardware that is
[04:36:15 CET] <void09> anyway, back to the topic. remux .ts to .mkv, and then cut, you say? and just ignore the timestamp errors I get ?
[04:36:44 CET] <void09> it says something about rewriting timestamps
[04:36:57 CET] <void09> I want to get a perfect result, so I am worried about that
[04:40:44 CET] <void09> just installed avidemux, it seems to pre-index the .ts file when opening it
[04:49:25 CET] <void09> This video uses non-IDR recovery points instead of IDR as keyframes. Picture reordering information in the video stream is not reset at non-IDR frames. The chosen start and end points of the cut may result in playback interruption due to reversed display order of frames if saved in copy mode.
[04:49:26 CET] <void09> Proceed anyway?
[04:50:20 CET] <void09> more confusion
[05:10:25 CET] <void09> thanks for the avidemux tip, it's a very handy program I didn't know about
[05:21:51 CET] <void09> furq know some program that can help me find timestamps with video/audio errors?
[07:28:38 CET] <classsic> Hi, somebody know what mean "[SAR 2:1 DAR 32:9]" on this info:  Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1280x720 [SAR 2:1 DAR 32:9], 521 kb/s, SAR 1:1 DAR 16:9, 5.02 fps, 25 tbr, 16k tbn, 10 tbc (default)
[07:29:37 CET] <classsic> the video play squeezed
[10:41:14 CET] <locsmif> Hi all. How can I limit output file size to, say.. 50MB and have FFMpeg calculate the required video codec quality reduction parameters?
[10:44:20 CET] <Mavrik> classsic, that SAR seems very strange, is that some kind of ultrawide camera?
[10:44:39 CET] <Mavrik> locsmif, I don't think ffmpeg can do it for you, but you can easily calculate it based on length with a script/
[11:49:10 CET] <locsmif> Mavrik: thanks
[13:50:23 CET] <safinaskar> I am attempting to write c++ program, which will record video from each opened window in x11 (simultaneously). Reasons why I want to write such program are not relevant here, but if you are curious, you can read my comments in this bug report: https://bugs.kde.org/show_bug.cgi?id=412731 . (I discuss Wayland in that bug report, but now I decided to
[13:50:24 CET] <safinaskar> stick with X11 for now.) I need to capture each window as a separate thing, so "ffmpeg -f x11grab" is not for me. I already solved problem of actually getting pictures from X server. My question is: how to store them? I will write my own player for such videos in any case, so there is no need to write in some standard format (but outputting
[13:50:24 CET] <safinaskar> standard format still would be good idea). Video should be compressed lossless, all frames should be keyframes and I will attach metadata to frames. My previous attempt was this: I generated raw frames in my c++ app and passed them to ffmpeg binary via pipe. ffmpeg converted this video to usual mkv/h264. Unfortunately, there was one problem with
[13:50:25 CET] <safinaskar> this solution: my program generated frames only when window changes. So frames were generated rarely. And ffmpeg buffered them. So, if computer suddenly resets, then that buffered frames are lost. So, what to do? Is there way to tell ffmpeg to actually write frame to disk immediately after getting new frame via pipe? Or maybe there is some simple
[13:50:26 CET] <safinaskar> way which will enable me to generate compressed video from c++ myself? But please don't say me "just use libav" or something like that. I don't want to spend too much time to this task. I want some hack, which will enable me to write such code easily, I don't want to learn big APIs. Also, as a last resort I will just generate my own custom format,
[13:50:26 CET] <safinaskar> which is concatenated ppm images compressed with xz. And I will call xz binary using popen for each image. This is simple. If you can offer something better, but without much complexity (I don't want to learn big APIs!), please offer
[14:29:26 CET] <roxlu> hey, I'm trying to download ffmpeg but it seems that the server is down? https://imgur.com/a/kwFBkXZ
[14:29:37 CET] <roxlu> this one https://ffmpeg.zeranoe.com/builds/
[14:29:57 CET] <BtbN> That's Zeranoes server, not anything owned or controlled by FFmpeg.
[14:31:27 CET] <roxlu> Yeah I figured; only wanted to let ppl know
[14:32:03 CET] <BtbN> I don't think there's anyone here that can actively do something about that.
[14:32:04 CET] <roxlu> I guess I've to build it myself ^.^  ... it's been a while but can we build ffmpeg w/o cygwin or similar on Windows
[14:32:24 CET] <BtbN> It's eaiser to just cross-compile it.
[14:32:34 CET] <BtbN> Since you need a shell anyway
[14:35:29 CET] <roxlu> yeah, if there is no other solution
[14:37:49 CET] <roxlu> hmm https://ffbinaries.com/
[14:39:20 CET] <BtbN> Or just enable WSL and use that.
[14:42:52 CET] <roxlu> Have you compiled ffmpeg with WSL before?
[14:43:14 CET] <BtbN> You can just get it from the Ubuntu repos, if their version is good enough for your plans
[14:43:41 CET] <roxlu> What do you mean from the Ubuntu repos? they provide windows libs?
[14:43:51 CET] <BtbN> no
[14:43:59 CET] <BtbN> That's the whole point of WSL
[14:44:24 CET] <roxlu> hmm what do you mean by "You can just get it from the Ubuntu repos" ?
[14:44:36 CET] <BtbN> apt install ffmpeg
[14:44:41 CET] <roxlu> ah in WSL
[14:45:10 CET] <roxlu> but would I then be able to use those libs in a msvc project?
[14:45:15 CET] <JEEB> no
[14:45:16 CET] <BtbN> no
[14:45:44 CET] <BtbN> You will have to compile ffmpeg with MSVC to be able to use it with that.
[14:45:44 CET] <roxlu> hehe ok
[14:45:50 CET] <JEEB> no, you don't have to
[14:45:55 CET] <JEEB> you can use mingw-w64 just fine
[14:45:56 CET] <JEEB> with MSVC
[14:45:57 CET] <JEEB> :P
[14:46:03 CET] <JEEB> but sure, you can do both with MSVC as well
[14:46:07 CET] <BtbN> But then you will be forced to ship two libcs, which potentially clash
[14:46:13 CET] <BtbN> would recommend against that
[14:46:19 CET] <JEEB> two libcs?
[14:46:25 CET] <JEEB> and ship them?
[14:46:27 CET] <BtbN> MinGWs one, and MSVC, yes
[14:46:36 CET] <JEEB> there is no real libc in mingw-w64
[14:46:50 CET] <JEEB> it has some compatibility functions that the Windows CRT doesn't support
[14:46:52 CET] <BtbN> You have to drag around libgcc_s.dll and one or two other files
[14:46:57 CET] <JEEB> that is not the CRT
[14:47:03 CET] <JEEB> also those can be statically linked just fine :P
[14:47:09 CET] <JEEB> just remove the .dll.a from mingw-w64
[14:47:24 CET] <roxlu> ok thanks
[14:47:29 CET] <BtbN> Does that even properly work when building just libraries, and not the binaries?
[14:47:41 CET] <JEEB> yes
[14:47:43 CET] <BtbN> If you intend to use the ffmpeg libs in MSVC, build them with the same msvc version.
[14:47:51 CET] <roxlu> so best is to setup mingw (or how that's calle ..msyss, cygwin ... it's been a while ^.^)
[14:48:04 CET] <BtbN> If you have msvc already, might as well just use it
[14:48:09 CET] <BtbN> Only need a bash
[14:48:13 CET] <BtbN> or any shell really
[14:48:49 CET] <JEEB> the positive notion with MSVC is that you get the right debug symbols since only llvm mingw-w64 seems to support them? not 100% sure though
[14:48:53 CET] <JEEB> technically the libs work JustFine though
[14:49:00 CET] <JEEB> and the libgcc_s etc are not the CRT
[14:49:11 CET] <JEEB> mingw-w64 can depend on multiple CRTs, by default it still uses msvcrt.dll
[14:49:16 CET] <JEEB> you can define that, though
[14:49:22 CET] <JEEB> (which windows CRT it picks)
[14:49:29 CET] <BtbN> I had plenty of situations where msvc exploded on linking mingw builds libs, because some symbols were defined twice
[14:49:47 CET] <roxlu> if only we had something like CMake ^.^
[14:49:47 CET] <JEEB> the only issue I think with MSVC is if you want *static* libs and then link those
[14:49:57 CET] <JEEB> roxlu: you still need that shell or cmake or whatever
[14:50:06 CET] <JEEB> to generate the build part
[14:50:16 CET] <roxlu> cmake can run basically everywhere
[14:50:17 CET] <JEEB> it's exactly the same as running configure in a shell
[14:50:24 CET] <roxlu> not really
[14:50:27 CET] <JEEB> why not?
[14:50:28 CET] <BtbN> yeah really
[14:50:34 CET] <JEEB> the only thing you don't have is the fancy project file
[14:50:53 CET] <roxlu> because now, on windows, I have to figure out how to get a shell that I can use to compile ffmpeg
[14:51:05 CET] <roxlu> cmake runs in powershell, cmd which are default on windows
[14:51:22 CET] <JEEB> shell .exe is the same as cmake's .exe
[14:51:25 CET] <JEEB> it just *feels* different
[14:51:27 CET] <BtbN> Feel free to convert the entire build system to cmake then, without causing any regressions on any of the supported platforms.
[14:51:35 CET] <roxlu> JEEB: yeah that's true
[14:51:43 CET] <JEEB> anyways, for native windows probably msys2?
[14:51:48 CET] <roxlu> hehe BtbN I did once, long time ago
[14:51:56 CET] <roxlu> ok yeah thanks
[14:52:05 CET] <JEEB> also it seems like people are more veering towards meson now
[14:52:05 CET] <BtbN> And you tested all the dozens of different systems with hundred of different dep combinations?
[14:52:33 CET] <BtbN> I have yet to encounter a meson using project that's not broken in some way
[14:52:37 CET] <roxlu> BtbN: no it was just as an experiment; but I know it's not a simple thing
[14:52:59 CET] <JEEB> BtbN: anyways, I used to link against MSVC a lot more before, but I think it was mostly about static libs under some very specific circuimstances which I no longer remember :)
[14:53:13 CET] <JEEB> I was just mostly arguing because I can clearly see with libmpv and friends that people are linking against it
[14:53:47 CET] <JEEB> but yes, if a person really wants to go the full MSVC way (before the only way to get readable debug stuff in MSVS)
[14:53:56 CET] <JEEB> then sure, msys2 or something
[14:54:47 CET] <JEEB> http://fate.ffmpeg.org/report.cgi?slot=x86_32-msvc14-dll-md-windows-native&time=20191130194752
[14:55:01 CET] <JEEB> there's the FATE MSVS 2017 box's command line
[14:55:25 CET] <JEEB> the toolchain=msvc is the primary point I think
[14:59:06 CET] <roxlu> thanks JEEB I'm going to read up a bit on how to setup an correct environment
[15:01:50 CET] <roxlu> btw, what is that fate.ffmpeg.org site?
[15:01:58 CET] <JEEB> it's the testing suite
[15:02:05 CET] <JEEB> the results get posted there
[15:02:47 CET] <roxlu> is that basically compiling ffmpeg on windows? (automated)
[15:03:02 CET] <JEEB> on multiple systems and running the FATE test suite
[15:03:26 CET] <JEEB> if you look at fate.ffmpeg.org it's got everything from *BSD to linux to windows, x86 to arm to mips :P
[15:03:39 CET] <roxlu> ok :) so why not provide those builds as downloadable zips? (like Zeranoe)
[15:04:01 CET] <JEEB> because that's not the idea of it, and you don't necessarily want to trust the people running those test nodes
[15:04:10 CET] <JEEB> or maybe those test node running people do not want to upload them
[15:04:18 CET] <roxlu> oh i see
[15:04:30 CET] <JEEB> it is to test 1) building 2) running FATE
[15:04:35 CET] <JEEB> that's its purpose
[15:05:04 CET] <roxlu> ok
[15:30:54 CET] <roxlu> ok so I wanted to give it a try and use msys2 (https://trac.ffmpeg.org/wiki/CompilationGuide/MinGW) there is says to execute mingw64_shell.bat from the msys2 home; but that file is not there
[15:32:33 CET] <roxlu> there is a mingw64.exe though but the the docs say not to run the the "MSYS2 Shell". But it's not clear if that's the mingw64.exe though
[15:38:37 CET] <JEEB> yea msys2 changed in that sense
[15:39:41 CET] <roxlu> Is it 'mingw64.exe' that I need?
[15:39:57 CET] <JEEB> no idea :P just whatever gets you a shell started
[15:40:09 CET] <JEEB> anyways, you're not building with mingw-w64 so as long as you get the msvc compiler and linker (link.exe) right in the PATH that should be OK
[15:40:42 CET] <roxlu> ok :-) ..
[15:40:55 CET] <roxlu> hehe remember me saying "not really" before lol ...
[15:41:20 CET] Action: roxlu just kidding
[16:40:22 CET] <roxlu> ok it's compiling
[20:15:09 CET] <roxlu> ok, I've got the .exe, .dll and .lib files but when I try to link with the .lib I get unresolved symbols. though I get them at compile time when using the .lib files. is there something obvious I missed from the documentation?  I'm looking at AVCODEC-58.dll and see it has an dependency with MSVCP_WIN.dll.
[20:16:27 CET] <JEEB> I think what it does with regards to the CRT depends on the parameters you give the MSVC linker
[20:16:43 CET] <JEEB> and most likely your own project has to match in that sense
[20:17:18 CET] <JEEB> you should be able to see how things get linked within the FFmpeg build system with make V=1
[20:17:22 CET] <JEEB> that outputs the exact commands utilized
[20:18:13 CET] <roxlu> JEEB: it's either with /MT or /MD right?
[20:22:29 CET] <JEEB> roxlu: I'd just recommend you check how it's actually linked
[20:22:34 CET] <JEEB> make V=1 should do it
[20:22:37 CET] <JEEB> when you build
[20:22:55 CET] <JEEB> but yes, I think some of those options are also another thing
[20:23:10 CET] <cehoyos> rm ffmpeg_exe and make V=1 ffmpeg_g.exe
[20:23:19 CET] <cehoyos> rm ffmpeg_g.exe
[20:23:41 CET] <JEEB> or remove one of the libraries, yea. to check how those DLLs/LIBs get generated
[20:23:58 CET] <JEEB> (or both)
[20:24:42 CET] <roxlu> ok going to do that
[20:47:27 CET] <roxlu> ok, lets build 64bit libs ^.^
[20:47:59 CET] <roxlu> is there any reason why one would default to 32bit?
[20:52:31 CET] <pink_mist> one might be a timetraveller with a computer from 1998
[20:53:08 CET] <roxlu> haha
[20:53:33 CET] <JEEB> I'm actually not sure how much the configure sets regarding win32/64
[20:54:43 CET] <JEEB> there seem to be some things like if 32bit -> make it large address aware, or if x86_64 then objformat is win64 and otherwise win32
[20:54:50 CET] <roxlu> I opened a `Native VS 2019 64bit` console and from there the msys shell (as described in the docs)
[20:55:15 CET] <JEEB> yea, I think that's how you do it nowadays since you no longer have a convenient env var to add to your PATH
[20:55:41 CET] <roxlu> but I think I still need to tell `./configure` that I want a 64bit build
[20:55:47 CET] <roxlu> I'm rebuilding now
[21:10:35 CET] <Polochon_street> hi! I'm wondering, would it be possible to make a spectrogram of what I'm currently playing on my default pulseaudio output? I got its name by doing `pactl list short sinks` and tried something like ffmpeg -f pulse -fragment_size 128 -sample_rate 48000 -channels 2 -wallclock 0 -i <output_name> -c:v rawvideo -filter_complex "avectorscope"`
[21:10:48 CET] <Polochon_street> but then I simply get `alsa_output.usb-DAC_FOR_USB_FOCAL_XS-00.iec958-stereo: Input/output error` (the output name)
[21:11:00 CET] <Polochon_street> am I doing something obviously wrong?
[21:21:54 CET] <cehoyos> roxlu: FFmpeg's configure script detects if your toolchain defaults to 32 or 64 bit, no need to specify it
[21:29:33 CET] <roxlu> cehoyos: thanks, I just noticed that I was using a 32bit env. :# I'm rebuilding again
[21:56:47 CET] <roxlu> I got the 64bit dll/libs now ... but ... https://imgur.com/a/uc4mCcV
[23:48:29 CET] <trfl> can i somehow use mpeg2_vaapi to encode mpeg1-compliant-ish video? fwict they are fairly similar with the major difference being constraints in mpeg1 which don't exist in mpeg2, so would be cool if you could just transform the bitstream in some way to have mpeg1 decoders take it
[23:48:46 CET] <trfl> not expecting this to be fully according to mpeg1 spec of course
[23:49:32 CET] <cehoyos> Do you know of an mpeg-1 decoder?
[23:49:58 CET] <trfl> the one I intend to use is jsmpeg, but I'm curious about the general case too
[23:51:44 CET] <cehoyos> Did you test it with non-interlaced mpeg-2 video?
[23:53:04 CET] <iive> trfl, btw, mpeg2 patents have expired recently. in case you want mpeg1 for legal reasons.
[23:53:34 CET] <trfl> thanks iive that's good to know :> maybe jsmpeg will take that into consideration and support both out of the box
[23:53:59 CET] <trfl> cehoyos, I did and it failed, didn't get any hints in the console so would have to start adding breakpoints to figure out exactly why
[23:54:59 CET] <cehoyos> I may misremember but I believe you have to take extra steps to avoid decoding progressive mpeg2video with an mpeg1video decoder
[00:00:00 CET] --- Mon Dec  2 2019