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

[burek]

[04:01:45 CEST] <velix> Anyone with an idea, how to scan a complete file using ffmpeg -i? Actually, I've got a VBR file and want to get the real average bitrate.
[04:01:54 CEST] <velix> Right now, it only seems to touch the file.
[04:09:37 CEST] <velix> maybe -analyzeduration 1000000000
[05:08:24 CEST] <mixfix41> my vcr script ffmpeg command is way too bloated
[05:08:47 CEST] <mixfix41> and quality is way less visually but i think the audio is very good thats why
[05:08:59 CEST] <mixfix41> compared to simplescreenrecorder anyways
[05:09:11 CEST] <mixfix41> brb
[12:01:14 CEST] <ChrisWarrick> Oh hi, that channel exists
[12:02:03 CEST] <ChrisWarrick> I have a file that is multiple tracks merged into one file. I also have a track list with start times (h:m:s).  How can I use ffmpeg to split that file into many?
[13:02:20 CEST] <ChrisWarrick> ffmpeg -ss START_TIME_IN_SECONDS -t DURATION -i all.mp3 -acodec copy 01.mp3
[15:54:24 CEST] <onodera> Hi, I have some flac files that I want to convert to ogg, and I also want to add an external cover.jpg file to the ogg metadata, is this possible?
[15:54:55 CEST] <onodera> I figured out the first part using `ffmpeg -i $i -i cover.* -c -codec:a libvorbis -qscale:a 6 $o`, however, I'm kind of stuck with the album art part
[15:57:49 CEST] <furq> cover art in ogg isn't supported yet
[15:58:01 CEST] <furq> there's been an open feature request for it for a few years
[15:58:27 CEST] <furq> you'd be better off using opusenc
[15:58:50 CEST] <onodera> ahh okay, thanks
[15:58:55 CEST] <furq> or oggenc if you really want to use vorbis
[15:59:21 CEST] <onodera> nah I thought ogg was the best
[15:59:35 CEST] <furq> opus is the successor to vorbis
[15:59:37 CEST] <onodera> *vorbis, seems like opus was designed to replace it though
[15:59:40 CEST] <furq> yeah pretty much
[16:25:07 CEST] <dalu> Alright I'm trying to convert a .mp3 file to a .m3u8 playlist, and encrypt it with aes-cbc. `ffmpeg -i 3.mp3 -c copy -hls_time 10 -hls_key_info_file 3.info playlist.m3u8` and that works, as in various .ts files are created. However the playlist.m3u8 file only has like 5 of those .ts files there.
[16:26:12 CEST] <furq> dalu: -hls_list_size 0
[16:26:25 CEST] <dalu> furq, thanks I'll try
[16:27:12 CEST] <furq> or i guess -hls_playlist_type vod is the correct way to do it
[16:27:16 CEST] <dalu> nice! thanks so much :)
[16:27:26 CEST] <furq> not sure how much difference it makes
[16:27:41 CEST] <dalu> I'll try that too, do the other options fall off?
[16:27:55 CEST] <furq> that will set hls_list_size to 0 anyway
[16:27:59 CEST] <dalu> aka is this then the only hls option that's used?
[16:28:08 CEST] <furq> no
[16:28:15 CEST] <furq> !muxer hls @dalu
[16:28:16 CEST] <nfobot> dalu: http://ffmpeg.org/ffmpeg-formats.html#hls-2
[16:28:23 CEST] <dalu> ty
[16:32:47 CEST] <Zexaron> Hello
[16:32:58 CEST] <Zexaron> is ffmpeg able to stream like OBS for twitch ?
[16:33:45 CEST] <Zexaron> on windows, plus, fullscreen?
[16:34:19 CEST] <Zexaron> nevermind about fullscreen, I mixed something up
[16:41:50 CEST] <ChocolateArmpits> Zexaron, should be no problem, though I think screen capture may be sluggish depending on your setup
[16:42:50 CEST] <Zexaron> This is actually intergrating ffmpeg, first it's just offline dump, wondering if it's possible to integrate ffmpeg with a 3D program in a way that it would produce the relative correct output, if the FPS drops (makes the sound also go slower) then that fps drop wouldn't be there on the offline video
[16:43:07 CEST] <Zexaron> Or is it possible to do this on the offline video later as a second step ?
[16:43:34 CEST] <ChocolateArmpits> you shouldn't call VODs "offline video"
[16:44:09 CEST] <Zexaron> Heh, sorry, not talking about VODs anymore, that would be separate step anyway, not trying to make a OBS competitor
[16:44:26 CEST] <Zexaron> That's a lower priority task
[16:45:12 CEST] <Zexaron> I was just thinking of some kind of ability, for the user to set it up, or some kind of preset script, if OBS isn't working for them for some reason, but offline dumping is primary as it's about max quality
[16:46:12 CEST] <Zexaron> Not that about quality, the current implementation is buggy, unstable, producing bad codec integrity, etc, doesn't work with dual core good, etc
[16:46:36 CEST] <ChocolateArmpits> Your "3d applications" are games, right?
[16:47:27 CEST] <Zexaron> I should have mentioned in the beginning what I'm talking about, sorry, https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/VideoCommon/AVIDump.cpp
[16:49:26 CEST] <JEEB> I would start with having something out of your primary thread being able to take in RGB pictures in a non-blocking way (you probably need to have a buffer of them or something with a max or whatever)
[16:49:46 CEST] <JEEB> then after that you can look into libplacebo for RGB<->YCbCr conversions on the GPU
[16:49:57 CEST] <JEEB> because for some formats you want RGB as-is, and others you want YCbCr
[16:50:19 CEST] <JEEB> and you probably want it to be done on the GPU as to not block the CPU
[16:51:00 CEST] <JEEB> then, finally, you have an output AVFormat and AVCodec contexts which you initialize for the video encoder and muxer you want, and encode/write stuff
[16:51:31 CEST] <JEEB> feeding into streaming services with RTMP shouldn't really be a problem since a lot of people already do that with libavformat
[16:51:38 CEST] <JEEB> but for that you need H.264 of course
[16:51:54 CEST] <JEEB> which can either be a hardware ASIC encoder, or x264 with a very fast preset
[16:52:09 CEST] <JEEB> for offline archiving on the other hand a fast encoding lossless encoder might be preferred
[16:52:13 CEST] <JEEB> maybe even in RGB
[16:54:35 CEST] <Zexaron> Yeah, users have tried using other codecs that the current system doesn't support (custom built libs) so the first step was to get it upgraded and updated , then I can finally do something about the actual framedumping improvements, as it is (historically) called
[16:55:26 CEST] <Zexaron> That upgrade is like this: https://github.com/dolphin-emu/dolphin/pull/7110
[16:57:26 CEST] <Zexaron> But it's the users who are all trying to get max offline quality, they're not that about streaming, the ones that stream just use OBS already probably
[16:57:47 CEST] <Zexaron> JEEB: You mean different games would need YCbCr or what's the reason, I don't understand at this moment.
[16:58:02 CEST] <JEEB> dpeending on what you want or what your output requirements are
[16:58:13 CEST] <JEEB> for example streaming into a service you need to keep it YCbCr, 4:2:0 and H.264
[16:58:27 CEST] <JEEB> while for offline archival you might want either 4:4:4 YCbCr or RGB
[16:59:35 CEST] <JEEB> anyways, if people care about high quality archival recordings then that's almost fully something lossless, so compression ratios don't really matter
[16:59:45 CEST] <JEEB> be it RGB or YCbCr
[17:02:44 CEST] <Zexaron> Oh, that, in this case the users asked and talked about quality, now I started recalling, someone even wanted Lagarith codec support, it's probably not hard to do both so it'll be an option, switch, but I guess full RGB will be the default
[17:02:58 CEST] <JEEB> not sure how quick lagarith is
[17:03:06 CEST] <JEEB> I recommend benchmarking a few lossless encoders
[17:03:16 CEST] <furq> i don't think ffmpeg has a lagarith encoder
[17:03:34 CEST] <furq> there's not really any reason to use it these days though
[17:03:38 CEST] <JEEB> ffvhuff, ut video (this one has actual support in video editors funny enough), ffv1 and libx264's lossless mode
[17:03:49 CEST] <furq> and magicyuv now as well
[17:03:52 CEST] <Zexaron> Codec support wasn't a Dolphin limitation, just a lib limitation, if they have the speed they can use any codec the official ffmpeg DDLs will provide, now that it's going to be switched to the full blown DLLs
[17:04:26 CEST] <furq> apparently magicyuv does rgb because names mean nothing any more
[17:04:28 CEST] <Zexaron> From Zeranoe, for windows, this doesn't apply to other OS, they ffmpegs are managed by the OS, not Dolphin
[17:11:33 CEST] <analogical> I'm curious. How come it's possible to play back incomplete MKV video files but not incomplete MP4 video files?
[17:12:02 CEST] <JEEB> index which usually also contains the decoder initialization stuff generally can only be fully written at the end of a thing
[17:12:20 CEST] <JEEB> you can help that with fragmented mp4
[17:12:49 CEST] <analogical> fragmented mp4?
[17:12:49 CEST] <JEEB> also another way is that after you once write the mp4 file, you then do another pass and move the required thing into the front of the file
[17:12:55 CEST] <JEEB> since you then know all the packets' sizes etc
[17:13:01 CEST] <JEEB> aka the content of the mp4 file
[17:13:19 CEST] <JEEB> analogical: movie fragments for f.ex. each GOP instead of one big index
[18:13:13 CEST] <keglevich> ffmpeg -re -i 1.mp4 -g 50 -c:v libx264 -preset veryfast -x264opts nal-hrd=cbr -b:v 2200k -minrate 2200k -maxrate 2200k -bufsize 260k -muxrate 2600k -pcr_period 30 -c:a mp2 -ac 2 -b:a 192k -ar 48000 -f mpegts "udp://239.1.1.1:10000?pkt_size=1316"
[18:13:21 CEST] <keglevich> running the command above gives somehow CBR UDP multicast stream, but it's not perfect (lots of bursts, spikes, etc.), nothing similar to those generated by hardware encoders...is there anything I can do to improve it?
[18:43:44 CEST] <ChocolateArmpits> keglevich, Is there a general upper limit in terms of bitrate that you see?
[18:55:02 CEST] <fahadash> Trying to concat 3 videos using a concat.txt file all are MOV files, different frame width and heights https://pastebin.com/c8tzqeh1
[18:55:08 CEST] <fahadash> I got a ton of errors
[18:55:31 CEST] <fahadash> How do I resolve this?
[18:55:56 CEST] <durandal_1707> fahadash: you cannot use concat demuxer with differrent sizes, this is in documentation
[18:56:31 CEST] <fahadash> What are alternate ways to concat? just may be add paddings around the smaller frames to fit the size of the largest one?
[18:57:16 CEST] <durandal_1707> you can not concat without transcoding
[18:57:42 CEST] <ChocolateArmpits> fahadash, you could first convert each separately to a common standard frame option and then do it
[18:57:44 CEST] <durandal_1707> for concat with transcoding use concat filter
[18:58:40 CEST] <durandal_1707> ChocolateArmpits: that is nothing better than using concat filter and rescaling videos
[18:58:47 CEST] <fahadash> The other two clips are the zoomed in and cropped pieces of the first clip. May be I should rezoom and crop to keep the same size
[19:03:58 CEST] <ChocolateArmpits> durandal_1707, well if there are lots of files, then a long command line may not be appropriate
[19:05:19 CEST] <durandal_1707> ChocolateArmpits: really, so you prefer one which takes extremly long time?
[19:07:12 CEST] <ChocolateArmpits> durandal_1707, windows has a limit for command line length so....
[19:08:15 CEST] <durandal_1707> ChocolateArmpits: you can use text files to specify filtergraph so .....
[19:08:32 CEST] <ChocolateArmpits> durandal_1707, sad you can't specify inputs with a text file so....
[19:08:43 CEST] <durandal_1707> you can
[19:08:59 CEST] <ChocolateArmpits> can you point me?
[19:09:31 CEST] <durandal_1707> -filter_complex_script
[19:10:12 CEST] <ChocolateArmpits> the inputs as a text file I mean
[19:13:36 CEST] <durandal_1707> ChocolateArmpits: that is very easy to add
[19:14:16 CEST] <keglevich> ChocolateArmpits: why would bitrate upper limit matter?
[19:14:37 CEST] <ChocolateArmpits> keglevich, maybe it's predictable and you may only need to set a higher muxrate ?
[19:14:41 CEST] <keglevich> ChocolateArmpits: buy yes, upper limit for this particular stream is 2.6mbit7s
[19:15:03 CEST] <keglevich> in other words...set lower video bitrate?
[19:15:38 CEST] <ChocolateArmpits> I'd certainly try hammering all the available options and setting a lower bitrate may be just that
[19:16:51 CEST] <keglevich> ChocolateArmpits: i have also tried that already, and numerous other options as well...but it just seems CBR encoding ins't the main issue... the main issue seems to be UDP output mpegts which goes out in some kind of bursts...it seems that it send data as soon as it's available, or something...
[19:17:16 CEST] <keglevich> having a decent CBR UDP output would probably solve that...but so far it seems impossible to me
[19:19:06 CEST] <JEEB> I think the UDP thing tried to control the mux rate if you set it, and then IIRC with UDP output people set the packet size or whatever it was to a multiple of 188
[19:19:27 CEST] <JEEB> both of those IIRC required threading to be enabled in FFmpeg
[19:19:44 CEST] <JEEB> or well, the muxrate thing I think required?
[19:20:03 CEST] <keglevich> yes...pkt_size is 1316 (7x 188bits) required by HW encoders...this works ok
[19:20:31 CEST] <keglevich> pkt_size is accepted as well with w32threads version....bitrate output parameter need ptrheads, but it has issues, I already tried it
[19:21:16 CEST] <JEEB> I don't think there should be much in there specifically needing pthreads?
[19:21:26 CEST] <JEEB> unless someone didn't update the ifdefs
[19:22:03 CEST] <keglevich> "bitrate" UDP output parameter requires ptrheads for some reason...it won't work without
[19:22:38 CEST] <keglevich> therefore I compiled latest trunk with pthreads to test it...but it has issues, it crashes a lot with "cannot allocate memory"
[19:22:55 CEST] <keglevich> but yes, UDP output with that parameter is much better than with w32threads version
[19:23:08 CEST] <keglevich> so I'm looking a solution with w32threads if possible, as it's stable
[19:23:09 CEST] <ChocolateArmpits> keglevich, what are you using to compile?
[19:23:16 CEST] <JEEB> right, it requires pthread_cancel... I wonder if the pthreads wrapper that we have for win32 works for that :P
[19:23:18 CEST] <keglevich> media-autosuite-builte
[19:23:21 CEST] <JEEB> and someone just didn't update the deps
[19:23:53 CEST] <JEEB> anyways unfortunately I don't want to look into this too much since UDP+windows is not on my care level right now
[19:23:56 CEST] <furq> does ffmpeg have its own pthread wrapper
[19:24:01 CEST] <JEEB> yes
[19:24:02 CEST] <keglevich> I only haven't tried it on linux yet...there pthreads are native?
[19:24:06 CEST] <furq> or do you mean the one in mingw64
[19:24:08 CEST] <JEEB> that's the win32 threads
[19:24:34 CEST] <JEEB> furq: I think it just wraps the NT6+ threading things now
[19:24:38 CEST] <ChocolateArmpits> keglevich, I'm using msys2 with mingw64  and had no problems
[19:25:08 CEST] <keglevich> that media-autobuild-suite also uses mingw64...
[19:25:21 CEST] <keglevich> does ffmpeg on linux by default use pthreads?
[19:25:26 CEST] <JEEB> of course
[19:25:33 CEST] <keglevich> so I can try that same thing there to see if it also crashes
[19:25:45 CEST] <keglevich> if not then it's probably windows issue with ptrheads?
[19:25:49 CEST] <JEEB> furq: seems to be a really lightweight wrapper around the nt6+ things
[19:26:04 CEST] <JEEB> keglevich: it could be an issue with the pthreads wrapper you're using on your mingw-w64 thing too
[19:26:07 CEST] <JEEB> I dunno
[19:26:18 CEST] <JEEB> without any details it's hard to say one way or another :P
[19:26:22 CEST] <keglevich> so if I cross-compile it on linux, it could be different?
[19:26:45 CEST] <JEEB> yes, esp. if you use a different mingw-w64 version or different pthreads wrapper if you want to utilize pthreads on windows
[19:27:00 CEST] <JEEB> I'd almost just implement the cancel function in the w32pthreads thing
[19:27:04 CEST] <JEEB> to be honest
[19:27:11 CEST] <keglevich> is there a simple way to compile v4.0 for instance, x86 build for windows on linux?
[19:27:35 CEST] <furq> like i said before it's not that difficult if the only external lib you need is x264
[19:28:20 CEST] <JEEB> but yea, I have no idea what pthread_cancel is, but unless it's really complex it might be worth it to just implement it in w32pthreads.h
[19:28:37 CEST] <JEEB> that said, it's sunday and I don't use that feature on windows so E_NOCARE
[19:28:56 CEST] <JEEB> just saying that might be better than trying random versions of pthreads wrappers :P
[19:29:10 CEST] <furq> pthread_cancel may or may not stop a thread
[19:29:21 CEST] <furq> great!
[19:29:57 CEST] <keglevich> is there an option for someone to implement this to w32threads? I don't have the knowledge to do it
[19:30:17 CEST] <furq> just cross-compile with pthreads
[19:30:37 CEST] <furq> or --disable-w32threads
[19:30:47 CEST] <JEEB> there's always the possibility - make an issue on the tracker about it and hope someone cares enough?
[19:30:54 CEST] <JEEB> if you have budget you could also sponsor someone :P
[19:31:05 CEST] <keglevich> yes, that's what I used on windows when compiling...but the result was (as said) always an issue...
[19:31:36 CEST] <furq> if it doesn't work with a --disable-w32threads build then it's probably not going to work at all
[19:31:42 CEST] <keglevich> the build with pthreads works fine as soon as you don't add "bitrate=2600000" output UDP parameter to my command above...
[19:32:14 CEST] <keglevich> also, there's "burst_bits", but I don't know which value should be set to that one?
[19:32:29 CEST] <keglevich> whichever value I set, it crashes after some mins with "cannot allocate memory" fatal error
[19:32:47 CEST] <JEEB> furq: he hasn't provided a backtrace nor anything else so you can't really say jack shit :D
[19:33:02 CEST] <JEEB> other than "maybe your pthreads wrapper sucks, maybe?"
[19:33:07 CEST] <furq> i mean i probably couldn't say anything with a backtrace
[19:33:37 CEST] <keglevich> how can I provide backtrace?
[19:33:41 CEST] <JEEB> although if it just fails at some memory allocation fuck if I know
[19:33:42 CEST] <furq> gdb
[19:33:46 CEST] <JEEB> keglevich: run under gdb?
[19:33:53 CEST] <keglevich> how is this done?
[19:34:02 CEST] <furq> all i know is that people who know more than me about the topic (e.g. Mavrik) have said this use case doesn't work at all
[19:34:17 CEST] <JEEB> the UDP thing does work to a level
[19:34:32 CEST] <JEEB> it's not that. I mean it's imperfect but it seems to work for various people to a level :P
[19:34:40 CEST] <JEEB> but > windows > random pthreads wrappers
[19:34:49 CEST] <furq> i'm fortunate to not need to give a shit about true cbr mpegts output
[19:35:04 CEST] <JEEB> I don't even think you need true CBR
[19:35:13 CEST] <JEEB> you just need to keep the bits flowing relatively smoothly
[19:35:29 CEST] <JEEB> how smoothly depends on how retarded your receiver side is
[19:35:36 CEST] <keglevich> it's a requirement by our IPTV client...perfect CBR, percfect PCR < 30ms, right PID's, etc...
[19:35:40 CEST] <JEEB> and on how bad your network equipment is
[19:35:49 CEST] <JEEB> "perfect CBR"
[19:35:54 CEST] <JEEB> please define
[19:36:02 CEST] <JEEB> like seriously, people keep saying that but never define it
[19:36:11 CEST] <keglevich> straight 2.6mbit/s line in mpegts analyzer, without and jumps
[19:36:23 CEST] <keglevich> without any bursts...something that all hw encoders can generate
[19:36:28 CEST] <JEEB> whatever that means
[19:36:43 CEST] <keglevich> like 2.1mbit/s video bitrate...padding up to 2.6mbit/s
[19:36:57 CEST] <JEEB> yea it's clear you don't know the specifics
[19:37:04 CEST] <JEEB> you just look at a piece of software
[19:37:06 CEST] <keglevich> it's somehow there, but it jumps +-10% and it seems no parameter can solve this in ffmpeg
[19:37:51 CEST] <keglevich> I can check other UDP streams from out provider in the same network...TV channels....more or less all are clear perfect CBR
[19:37:59 CEST] <keglevich> but all are HW-encoders generated
[19:38:08 CEST] <keglevich> so I'm trying to achieve the same with ffmpeg
[19:38:11 CEST] <keglevich> if it's possible
[19:38:20 CEST] <JEEB> anyways, I know that lavf's muxer is not perfect but I also know people make stuff with lavf that is "good enough"
[19:38:26 CEST] <JEEB> since some people have mentioned it
[19:38:37 CEST] <JEEB> with the muxrate over at MPEG-TS and bitrate over at UDP
[19:38:40 CEST] <keglevich> what is lavf?
[19:38:43 CEST] <JEEB> libavformat
[19:38:50 CEST] <JEEB> the demuxing/muxing library in FFmepg
[19:39:06 CEST] <keglevich> I should only use mpeg2video for some streams and x264 for others
[19:39:39 CEST] <JEEB> also funny enough I can't find my gdb binary that I was going to link :P
[19:39:54 CEST] <JEEB> ah yes
[19:40:23 CEST] <JEEB> https://kuroko.fushizen.eu/random/gdb_builds/gdb-8.0.1.7z
[19:40:25 CEST] <JEEB> there you go
[19:40:29 CEST] <keglevich> strange is...if I output my current stream to a file (i.e. test.mp4) and play it in VLC later, it's really nice CBR...but if I output direct to -f mpegts output, it jumps a bit up and down all the time
[19:40:47 CEST] <keglevich> seems like UDP output does shitty job there, not muxer itself
[19:41:23 CEST] <JEEB> well since you're not using teh feature that you can't have without pthread_cancel?!
[19:41:32 CEST] <JEEB> just fucking test with native linux first
[19:41:43 CEST] <keglevich> that's what I'm going to do now
[19:41:43 CEST] <JEEB> *then* you know it works well enough and you can try making it work on windows
[19:41:55 CEST] <keglevich> exactly...
[19:42:02 CEST] <JEEB> just build FFmpeg on linux for linux
[19:42:05 CEST] <keglevich> how can I use the gbd.exe binary you provided to test ffmpeg?
[19:42:16 CEST] <JEEB> http://www.unknownroad.com/rtfm/gdbtut/
[19:42:24 CEST] <keglevich> is it good enough if I just use ubuntu and install the bundled ffmpeg?
[19:42:27 CEST] <JEEB> tl;dr is "gdb path\to\ffmpeg.exe"
[19:42:46 CEST] <JEEB> the bundled FFmpeg is old, but I think 18.10 should have FFmpeg 4 I think?
[19:42:47 CEST] <keglevich> so I don't need to compile it manually
[19:43:05 CEST] <JEEB> not like compiling FFmpeg if you only need libx264 or so externally is hard, thankfully :)
[19:43:18 CEST] <keglevich> I'll try as you suggested and I'll report back with backtrace logs of gdb and with results on linux!
[19:43:41 CEST] <JEEB> just test with linux first, 18.10 seems to have a relatively new FFmpeg
[19:43:59 CEST] <keglevich> ok, I'll report back...thanks for help!
[19:44:04 CEST] <JEEB> and you can of course build FFmpeg by just having pkg-config and nasm and the x264 -dev package installed
[19:44:19 CEST] <JEEB> (and the build-essential package of course with the compiler etc)
[19:44:40 CEST] <keglevich> what's the easiest way to cross-compile win x86 shared binaries there as well?
[19:45:02 CEST] <JEEB> no idae, I just usually use the bundled mingw-w64 toolchain with some tweaks. but that's probably not the simplest way :P
[19:45:08 CEST] <JEEB> so stay focused on testing linux first
[19:45:12 CEST] <keglevich> ok
[20:24:21 CEST] <DapOrp> I'm trying to test streaming a video file from one computer to another on my LAN, I'm using the command: ffmpeg -re -i out.mp4 -f mpegts udp://192.168.1.4:23000  to send the video to the 192.168.1.4 box, which is a windows machine, using VLC on the windows machine I'm telling it to play udp://127.0.0.1:23000 but it's not displaying anything.  What am I doing wrong?
[20:27:27 CEST] <ChocolateArmpits> DapOrp, did you try using the machine's IP for playback?
[20:29:32 CEST] <DapOrp> yes, telling vlc on the windows machine to play: udp://192.168.1.4:23000 displays nothing.
[20:36:11 CEST] <keglevich> JEEB, furq: you were completely right...th ffmpeg 4.0.2 on ubuntu runs flawlessly...it's been running now with UDP bitrate ptrheads output parameter for 25+mins...on windows it crashes in 2-3mins, so I can confirm...on linux it works perfectly!
[20:36:27 CEST] <keglevich> and the output is real CBR; as it should be!
[20:36:39 CEST] <ChocolateArmpits> DapOrp, are the ports open ?
[20:36:59 CEST] <keglevich> now I'm wondering...it there an issue in ffmpeg code for windows, or it was just bad mingw compiler as you mentioned before?
[20:37:55 CEST] <ChocolateArmpits> keglevich, *psst* try msys2
[20:38:30 CEST] <keglevich> is there an "easy" way to cross-compile ffmpeg 4.0.2 x86 shared windows builds on ubuntu linux?
[20:38:45 CEST] <keglevich> pthreads enabled of course
[20:41:23 CEST] <JEEB> keglevich: since the code in FFmpeg is the same I would guess an issue with the pthreads wrapper lib :P
[20:41:48 CEST] <JEEB> for cross compilation I dunno. try installing the mingw-w64 cross-toolchain packaged with your distro?
[20:42:06 CEST] <furq> apt-get install mingw-w64; ./configure --cross-prefix=
[20:42:14 CEST] Last message repeated 1 time(s).
[20:42:14 CEST] <furq> dfssd
[20:42:18 CEST] <JEEB> and then you'll have to install the mingw-w64 pthreads thing if you need pthread_cancel
[20:42:30 CEST] <JEEB> that's usually packaged as well in ubuntu
[20:42:32 CEST] <furq> apt-get install mingw-w64; ./configure --cross-prefix=x86_64-w64-mingw32 --target-os=mingw32 --disable-w32threads
[20:43:30 CEST] <furq> the mingw-w64 pthread stuff is included as standard now afaik
[20:43:39 CEST] <furq> at least i never had to install anything separate on debian
[20:43:43 CEST] <JEEB> ok
[20:44:26 CEST] <furq> i guess you also want --extra-ldflags="-static --static-libgcc"
[20:44:37 CEST] <furq> it's been too long since i dug into this to remember why i use that
[20:45:00 CEST] <JEEB> probably because gcc/ld prefer shared libs if only available
[20:45:10 CEST] <JEEB> so you end up with something gcc dot dll dependencies
[20:45:10 CEST] <furq> i meant the static-libgcc thing specifically
[20:45:17 CEST] <furq> right
[20:45:23 CEST] <furq> obviously you'll also need to crosscompile x264 but that's fairly easy iirc
[20:46:24 CEST] <furq> libx264 should just be ./configure --host=x86_64-w64-mingw32 --cross-prefix=x86_64-w64-mingw32-
[20:49:25 CEST] <keglevich> ok, I'll dig into it... if I won't be able to finish it, I'll kindly ask for more help
[20:49:43 CEST] <keglevich> and again...it's running now 35+mins without a single hiccup, multiple instances, all ok
[20:49:51 CEST] <furq> the mingw stuff on debian/ubuntu is pretty simple
[20:50:27 CEST] <furq> just to be clear the ffmpeg configure line should be ./configure --cross-prefix=x86_64-w64-mingw32- --target-os=mingw32 --disable-w32threads --enable-libx264 --extra-ldflags="-static --static-libgcc"
[20:50:36 CEST] <keglevich> what about this one: https://github.com/rdp/ffmpeg-windows-build-helpers
[20:51:02 CEST] <furq> never tried it
[20:51:14 CEST] <furq> i wrote my own thing but apparently i haven't updated it since 2015 so it probably doesn't work any more
[20:51:26 CEST] <furq> good work furq
[20:54:33 CEST] <DapOrp> I made a new rule in windows for port 23000 and added 23000 to the iptables in the linux machine and they still won't stream to each other.
[20:57:11 CEST] <JEEB> keglevich: there's a general tutorial on the trac's wiki most likely :P
[20:57:26 CEST] <JEEB> although I guess not for cross-compilation :P
[21:10:40 CEST] <DapOrp> really not understanding what's going wrong here.  I even turned off the windows firewall altogether and it still won't send the stream to it, or VLC isn't catching it.. one or the other.
[21:11:46 CEST] <ChocolateArmpits> DapOrp, does it work if you send it from the other side?
[21:11:53 CEST] <ChocolateArmpits> DapOrp, what about localhost?
[21:12:48 CEST] <DapOrp> I have not attempted to send anything from the windows machine to linux.  only the other way around.
[21:12:57 CEST] <DapOrp> localhost in linux works just fine.
[21:15:53 CEST] <ChocolateArmpits> DapOrp, the network works otherwise?
[21:16:34 CEST] <DapOrp> yeah the network is fine.  these two see and talk to each other through SSH no problem, even SMB, but trying to do this ffmpeg stream out from the .3 to the .4 machine just isn't doing anything.
[21:19:56 CEST] <ChocolateArmpits> DapOrp, what about sending the output the IP of the Linux machine and have Windows grab the stream from that?
[21:20:03 CEST] <ChocolateArmpits> to the ip*
[21:21:29 CEST] <DapOrp> so tell ffmpeg -f mpegts "udp://192.168.1.3:23000"  and vlc: udp://192.168.1.3:23000 ?
[21:22:44 CEST] <ChocolateArmpits> ye
[21:23:03 CEST] <DapOrp> doesn't seem to be working that way either.
[21:26:47 CEST] <w1kl4s> sorry to ask in middle of something, but how should i take a screenshot that includes subtitles from a stream?
[21:27:59 CEST] <w1kl4s> for now i used something like that:
[21:27:59 CEST] <w1kl4s> ffmpeg -ss 00:43:38.240 -i vid.mkv -vframes 1 -s 1920x1080 -c:v png -pix_fmt rgb24 output.png
[21:28:23 CEST] <w1kl4s> i tried to mess with -map and -c:s but nothing really came out of it
[21:45:58 CEST] <DapOrp> WTF?!?! it's VLC... version 3.0 has issues with this for some reason..
[21:46:06 CEST] <DapOrp> https://forum.videolan.org/viewtopic.php?t=143133
[21:46:19 CEST] <DapOrp> no solution, but downgraded to version 2.x and now it works just fine.. wtf!?...
[21:51:26 CEST] <DapOrp> this kind of shit makes me want to start smoking again.. grr.. thanks for your assistance ChocolateArmpits.
[23:51:32 CEST] <killown> should this work? ffmpeg -i "concat:1.mp4|2.mp4|5.mp4|6.mp4|7.mp4|9.mp4|10.mp4|12.mov" -c copy output.mp4
[23:51:43 CEST] <killown> output is only 1.mp4
[23:51:50 CEST] <killown> what is wrong?
[00:00:00 CEST] --- Mon Oct  8 2018