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

[burek]

[00:01:57 CEST] <klow> its not the the right channel is empty, its just a duplicate of the left exactly
[00:02:20 CEST] <klow> so its would sound the exact same as a mono file of half the size, right?
[00:04:48 CEST] <klow> ok how about this instead
[00:05:20 CEST] <klow> transcode a stereo .opus file  to a mono mp3 file (preferably using Left side rather than mixing L+R)
[00:05:56 CEST] <klow> basically I am trying to get the highest quality *mp3* file, in mono,  from youtube, which has several audio formats, the highest of which is a high-ish bitrate .opus i think
[00:06:37 CEST] <c_14> I mean, it's possible
[00:08:02 CEST] <c_14> but I don't think going down to $bitrate mono mp3 instead of $bitrate stereo mp3 is going to be that much of a quality difference
[00:08:18 CEST] <c_14> "that much" being anything noticeable
[00:08:19 CEST] <atomnuker> the encoder still probably detected no difference and used MS coding or intensity stereo
[00:09:35 CEST] <klow> ah. OK thanks anyways. what i have is working fine just trying to save iPhone space but no biggy
[00:51:24 CEST] <JodaZ> klow, ideally the files are already in M/S mode, you should check
[00:52:37 CEST] <JodaZ> M/S means only the difference to a center channel (M) is encoded (as S), so S will be small for "Mono-like" audio and cost barely any size
[00:57:40 CEST] <atomnuker> if you're compression lectures just compress with opus at ~28kbps, you'll likely not hear a difference
[00:57:48 CEST] <atomnuker> or aac-he at 48kbps
[01:18:01 CEST] <thebombzen> is ffaac going to get he-aac? or is there not really much demand for it with opus being a thing now
[01:26:35 CEST] <iive> atomnuker: is there a way to get psnr of audio encode while encoding?
[01:31:54 CEST] <atomnuker> its what fate does and you should never ever do that
[01:32:59 CEST] <atomnuker> optimize for psnr and you'll end up making everything sound worse than low bitrate speex
[01:44:13 CEST] <iive> i don't want to optimize
[01:44:17 CEST] <iive> just to measure
[01:44:50 CEST] <iive> if you have better psyhoacoustic measure... then i'd be happy to use it.
[01:47:07 CEST] <atomnuker> there isn't any and with good reason
[03:52:00 CEST] <bsuh> is there a way to create HLS segments separately in different invocations of ffmpeg instead of 1 passthrough?
[09:08:19 CEST] <the_gamer> can anybody help me out why this does not work? http://pasteall.org/473484
[09:08:47 CEST] <the_gamer> ffmpeg -i "%03d.png" -aspect 16:9 -target pal-dvd -q:v 1 gunung\ kawi\ karte.mpg
[09:08:59 CEST] <the_gamer> error: Could find no file with path '%03d.png' and index in the range 0-4
[09:08:59 CEST] <the_gamer> %03d.png: No such file or directory
[09:09:10 CEST] <the_gamer> same with %04d.png but the folder is full of them
[09:10:47 CEST] <the_gamer> anybody?
[09:18:08 CEST] <the_gamer> the slideshow manpage says my syntax is right
[09:18:14 CEST] <the_gamer> i don't get it
[09:25:54 CEST] <thebombzen> the_gamer: they have to start at 0001
[09:26:12 CEST] <the_gamer> oh that could be it
[09:26:28 CEST] <thebombzen> yea. if you have 680-900 you'd probably want to do a batch rename
[09:26:43 CEST] <thebombzen> alternatively, you can use: cat *.png | ffmpeg -f image2pipe -
[09:26:51 CEST] <thebombzen> er I mean cat *.png | ffmpeg -f image2pipe -i -
[09:26:59 CEST] <thebombzen> I believe you can also use png_pipe
[09:27:02 CEST] <the_gamer> -start_number does the trick
[09:27:06 CEST] <thebombzen> ah okay that works too
[09:27:17 CEST] <the_gamer> thanks a lot thebombzen i thought this was needed only when i don't want to use some
[10:46:12 CEST] <kerio> where's 0000.png
[10:46:19 CEST] <kerio> oh i was scrolled back dammit
[12:22:49 CEST] <Fig1024> using FFMPEG C++ API, should avformat_write_header be used for streaming? (no file recording)
[12:27:20 CEST] <JEEB> Fig1024: if you look at the docs it says it's the initialization function for output avformat
[12:28:26 CEST] <JEEB> so that you can have a lot of stuff before that if you need, and then when you're ready to start writing packets out you start with that one
[12:29:29 CEST] <JEEB> although it seems like you might not always need it https://ffmpeg.org/doxygen/trunk/group__lavf__encoding.html#ga18b7b10bb5b94c4842de18166bc677cb
[12:29:54 CEST] <JEEB> look at the docs of init_output() and write_header() regarding exit codes
[12:31:31 CEST] <Fig1024> ok, my issue is that if I use streaming and the server is down or URL entered wrong, first call to avformat_write_header hangs indefinitely. I tried passing -timeout and -stimeout options but it doesn't change anything. I need a graceful way to handle case when connection failed to establish, not hang forever
[12:34:21 CEST] <JEEB> I know there are many protocols that have a timeout parameter as an AVOption
[12:34:54 CEST] <JEEB> I've only used it for input, not output though
[12:36:20 CEST] <Fig1024> avformat_write_header takes AVDictionary options, that's where I tried passing -timeout but it doesn't do anything. Maybe I need to try pass it to different place
[12:39:07 CEST] <JEEB> both avformat_init_output and avformat_write_header take in options ("If using this(init_output) function, do not pass the same options to avformat_write_header.") and if the muxer you were trying to use didn't support it, you would get back an avdictionary with the options that weren't supported by it
[12:39:35 CEST] <JEEB> so you can actually check if your "-something" went there. which I bet it didn't, because I haven't seen any API options starting with "-"
[12:39:51 CEST] <JEEB> the dash is a command line parameter prefix
[12:41:06 CEST] <Fig1024> call to avformat_write_header hangs cause it's trying use blocking I/O
[12:41:57 CEST] <Fig1024> tho I can check it by having correct URL, then it returns fine
[12:42:19 CEST] <JEEB> well you check the protocols you are going to use for if they support a goddamn timeout parameter
[12:42:47 CEST] <JEEB> also as I said if you set the options in avformat_init_output it will not yet do the writing
[12:42:51 CEST] <JEEB> or opening
[12:43:06 CEST] <JEEB> just don't pass the same options to both init and write_header
[12:43:23 CEST] <JEEB> so you can check if the options are even valid that you're trying to pass
[12:43:31 CEST] Action: JEEB sighs
[12:46:34 CEST] <Fig1024> I confirmed that -timeout and -stimeout is not recognized parameter
[12:46:58 CEST] <JEEB> no fucking shit
[12:47:07 CEST] <JEEB> the one in libavformat/udp.c for example is called "timeout"
[12:47:13 CEST] <JEEB> (that is for reading only, though)
[12:47:21 CEST] <Fig1024> I'm using rtsp stream
[12:48:08 CEST] <JEEB> anyways, I've got my own code to write so please just use common sense and look at the available options in the encoder you'd be using :P
[12:49:10 CEST] <Fig1024> it's just difficult to understand why nobody considered the fact that infinitely blocking I/O is a bad idea. There are no obvious functions / parameters to change it. Something like this shouldn't be so hard to find
[12:50:05 CEST] <JEEB> I don't disagree
[12:51:14 CEST] <Fig1024> I was hoping that I missed something hiding in plain sight
[12:51:36 CEST] <Mavrik> Did you check the source of rtsp muxer yet?
[12:52:12 CEST] <JEEB> rtspenc.c doesn't have any timeout things, but rtsp.c has both timeout and stimeout
[12:52:21 CEST] <Fig1024> I don't have ffmpeg source code, I'm a lowly API user
[12:52:38 CEST] <JEEB> yes, because FFmpeg is a closed source app
[12:52:40 CEST] <JEEB> har har har
[12:53:16 CEST] <JEEB> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/rtsp.c#L66
[12:53:30 CEST] <JEEB> anyways, I've wasted enough time with this I have to get some things done :|
[12:53:31 CEST] <Fig1024> ffmpeg is too big and complex to take it lightly. I'm not sure I want to commit to digging thru it
[12:53:39 CEST] <Mavrik> JEEB, but but sunday! :)
[12:53:52 CEST] <JEEB> I promised some code to be delivered "this week"
[12:53:53 CEST] <JEEB> :V
[12:54:05 CEST] <Mavrik> Fig1024, I don't see how you can make a usable software using ffmpeg API without actually looking into ffmpeg source.
[12:54:27 CEST] <JEEB> well I guess you could dump the options etc
[12:54:28 CEST] <Mavrik> You'd have your answer by now if you just looked there :/
[12:54:40 CEST] <JEEB> a la ffmpeg.c
[12:54:46 CEST] <Fig1024> usually people make good API docs so people can use libs without having to understand internals
[12:54:51 CEST] <Mavrik> Anyway, I need to go figure out why ffmpeg craps out of shitty radio streams my clients have.
[12:54:59 CEST] <JEEB> but it's just simpler to go straight to the component you're using :P
[12:55:32 CEST] <JEEB> Fig1024: those same options are noted in https://www.ffmpeg.org/ffmpeg-all.html#rtsp
[12:55:45 CEST] <JEEB> if you want them in "documentation"
[13:00:29 CEST] <Fig1024> maybe 'avformat_write_header' is the wrong place to pass these options? I just use 'avformat_alloc_output_context2' to create output, which doesn't take any options parameter
[13:01:16 CEST] <JEEB> Fig1024: I have mentioned the OTHER place to set options two or three times, and the doxygen link has that other function RIGHT BENEATH THE WRITE_HEADER ONE
[13:01:24 CEST] <JEEB> have you not even read what the flying fuck I've been trying to tell you?!
[13:10:38 CEST] <Fig1024> ok I figured it out, -stimeout option is working
[13:11:42 CEST] <Fig1024> no thanks to you! j/k
[15:02:03 CEST] <goodafternoon> test
[15:03:11 CEST] <goodafternoon> Hi guys, I would like to record my screen + audio but I'm totally lost with ffmpeg, could you tell me how to do it ?
[15:07:18 CEST] <Fig1024> you could download OBS Studio, it's free
[15:18:06 CEST] <goodafternoon> but I guess ffmpeg is lighter. I gonna take a look at OBS Studio anyway, thank for the tip, but if someone still have an answer for me, I would be glad
[15:30:25 CEST] <Fig1024> OBS comes with a proper GUI, while FFMpeg is all command lines, so it depends on what you prefer. Command line is good for automating stuff
[15:31:16 CEST] <JEEB> also I don't think FFmpeg itself has the screen capture API(s) that came with the latest windows systems
[16:06:03 CEST] <JodaZ> yeah, OBS is much better at recording the screen
[18:53:45 CEST] <RazorSharpFang> How does ffmpeg have a codec for writing H.264 video? I was of the impression that it was a proprietary codec.
[18:54:04 CEST] <JEEB> you're mixing two things
[18:54:25 CEST] <JEEB> proprietary usually means that its specifications and similar documents are never released
[18:54:43 CEST] <JEEB> (many corporations sell magical formats like that)
[18:54:54 CEST] <RazorSharpFang> You're right; I was meaning to talk about patents, or other intellectual property law.
[18:55:41 CEST] <JEEB> source code distribution is generally not a problem, and FFmpeg itself doesn't provide any binaries
[18:56:03 CEST] <JEEB> if you are using FFmpeg for something you would have to think about whether or not you have to care about possible royalties in your use case
[18:57:01 CEST] <JEEB> ISO/IEC 14496-10 aka ITU-T Rec H.264 is an open standard which is why having it implemented (FFmpeg itself only contains a decoder) has not been a problem
[18:57:05 CEST] <BtbN> binaries of a h264 encoder are also not a problem
[18:57:19 CEST] <BtbN> it's distributing encoded material that costs roayalties
[18:57:52 CEST] <JEEB> that depends on the exact format and one would have to consult MPEG-LA's documentation if you are in a legal area where you think you would have to care about patent licenses
[18:58:06 CEST] Action: JEEB hasn't kept up with it for a while
[18:58:17 CEST] <RazorSharpFang> Aha, so having cutscenes encoded with H.264 will be covered by the patent, not the library/functions for decoding it.
[18:58:46 CEST] <JEEB> RazorSharpFang: don't take anyone's words for it, look up MPEG-LA's docs
[18:58:54 CEST] <JEEB> if you think that you have to care, that is
[18:59:09 CEST] <BtbN> Only talking about h264. for HEVC it's more complex
[18:59:12 CEST] <JEEB> many game companies just use the APIs that the OS provides for the video, that way they don't distribute the decoder itself
[18:59:16 CEST] <RazorSharpFang> This is purely hypothetical, thought experiment.
[18:59:20 CEST] <BtbN> Because there are two patent pools
[18:59:24 CEST] <JEEB> there's more :P
[18:59:29 CEST] <JEEB> like three or four for HEVC now
[18:59:41 CEST] <BtbN> way to ruin a codec
[18:59:44 CEST] <JEEB> yup
[18:59:49 CEST] <JEEB> no wonder AOM went off nicely
[19:00:03 CEST] <JEEB> I mean, I like what they did with the format (HEVC) but the licensing is just "lol"
[19:00:31 CEST] <JEEB> RazorSharpFang: the general docs for licensing of H.264/AVC is available from MPEG-LA (which is not MPEG, just for the record)
[19:00:36 CEST] <BtbN> you either don't give a damn about licensing it, or you use vp9
[19:00:51 CEST] <JEEB> so you a) decide if you are in a place where the patents matter
[19:01:03 CEST] <JEEB> b) if a is true, you check the patent licensing terms from MPEG-LA
[19:01:21 CEST] <JEEB> I distinctly remember that distributing decoders had a cap of I think 100k and then you had to start paying
[19:01:26 CEST] <JEEB> encoders I'm not sure
[19:01:37 CEST] <JEEB> but for encoding you can thank cisco I guess
[19:01:45 CEST] <JEEB> they release binaries of a library you can use through libavformat
[19:01:49 CEST] <BtbN> openh264 is bad
[19:01:51 CEST] <JEEB> it is
[19:01:54 CEST] <BtbN> you don't really want to use it
[19:02:05 CEST] <BtbN> they should have just distributed x264
[19:02:20 CEST] <JEEB> apparently x264's license wasn't liberal enough for them or something
[19:02:37 CEST] <BtbN> gpl?
[19:02:43 CEST] <JEEB> yes, they wanted BSD or something
[19:03:04 CEST] <thebombzen> well GPL is not liberal
[19:03:21 CEST] <thebombzen> people are moving away from it
[19:03:40 CEST] <thebombzen> mpv is moving to LGPL with the goal of no GPLed internal code, IIRC
[19:03:43 CEST] <BtbN> GPL is not business-friendly, because they have to give stuff back
[19:03:51 CEST] <thebombzen> GPL is not anyone-friendly
[19:03:53 CEST] <JEEB> thebombzen: mpv's case is because mpv is no longer just an app
[19:03:54 CEST] <BtbN> with BSD they can just absorb an entire open source codebase and do as they please
[19:04:10 CEST] <thebombzen> well tbh LGPL works fine because it prevents them from eating the codebase
[19:04:29 CEST] <thebombzen> but GPL is essentially "you cannot use this if you are a business"
[19:04:39 CEST] <RazorSharpFang> Is it really that bad?
[19:04:53 CEST] <BtbN> Like MS recently had the exact same security hole as haimdall, because they just copied its code.
[19:04:57 CEST] <JEEB> BtbN: http://www.mpegla.com/main/programs/AVC/Documents/avcweb.pdf
[19:04:59 CEST] <thebombzen> well GPL eats code and forces anything to be GPL
[19:05:00 CEST] <JEEB> they still have the 100k cap
[19:05:03 CEST] <JEEB> just fyi
[19:05:10 CEST] <JEEB> since you said that encoder or decoder distro is free
[19:05:23 CEST] <thebombzen> anything that links to GPL has to follow a whole bunch of restrictions
[19:05:42 CEST] <thebombzen> GPL software is a restrictive license that somewhat ironically limits the freedom of its users so people stop wanting to use GPLed code
[19:06:11 CEST] <thebombzen> RazorSharpFang: for comparison, you cannot link to libx264 if you have a cool thing and just want to encode video. Including dynamic linking
[19:06:14 CEST] <JEEB> well yes, although most of the moves I've seen have been from GPL to LGPL because suddenly there's a library provided by teh code base :P
[19:06:30 CEST] <JEEB> but that just means that the needs of the project have changed
[19:06:32 CEST] <thebombzen> Yea, but x264 is a GPLed library
[19:06:36 CEST] <thebombzen> that's the notable difference
[19:06:45 CEST] <JEEB> you can also pay x264 LLC
[19:06:51 CEST] <JEEB> and get a non-GPL license
[19:07:04 CEST] <JEEB> which also requires you to post all changes to x264 to x264 LLC
[19:07:07 CEST] <BtbN> Qt worked the same way a long time
[19:07:12 CEST] <BtbN> Either a GPL'ed library, or you pay
[19:07:19 CEST] <BtbN> Which seems like a fair deal to me
[19:07:22 CEST] <JEEB> yup
[19:07:31 CEST] <JEEB> it all depends on your/project's needs
[19:07:43 CEST] <RazorSharpFang> Maybe for professional development, but that might be a significant barrier to individuals.
[19:08:10 CEST] <JEEB> RazorSharpFang: there are other alternatives if you don't want to release source code
[19:08:17 CEST] <JEEB> libvpx or libaom to note a few
[19:08:27 CEST] <JEEB> (that's for lossy video)
[19:08:46 CEST] <JEEB> RazorSharpFang: anyways since you said you wanted to do thought experiments http://www.mpegla.com/main/programs/AVC/Documents/avcweb.pdf
[19:08:52 CEST] <JEEB> that's the actual tl;dr
[19:09:25 CEST] <JEEB> pages 8-9
[19:09:33 CEST] <RazorSharpFang> How would you rate libvpx's video compression compared to h.264? I've heard people say it's a tad disappointing, but I think they might just have unrealistic standards.
[19:10:07 CEST] <JEEB> libvpx is not too great in psychovisual optimizations and rate control
[19:10:16 CEST] <JEEB> but if you're making a game you can feed it some more bit rate :P
[19:10:24 CEST] <JEEB> and work around its shortcomings
[19:10:40 CEST] <JEEB> in other words, you would get similar quality with smaller size with libx264
[19:10:53 CEST] <JEEB> but if H.264 is a no-go
[19:10:54 CEST] <RazorSharpFang> Are you suggesting that vpx begins to struggle comparatively when deprived of bitrate?
[19:11:01 CEST] <JEEB> yes
[19:11:11 CEST] <BtbN> libvpx is not exaxctly a good piece of software
[19:11:23 CEST] <JEEB> I hope that with libaom since it's >1 vendor it'll be better
[19:11:35 CEST] <JEEB> having just el GOOG doing it wasn't exactly great :)
[19:11:59 CEST] <RazorSharpFang> Well, libvpx is probably a big step above Bink video.
[19:12:04 CEST] <JEEB> totally
[19:12:18 CEST] <JEEB> which is why I said that "just boost the rate usage until it looks good"
[19:12:35 CEST] <JEEB> with games you're not trying to compress stuff to minimal limits anyways
[19:12:45 CEST] <JEEB> and it seems like VP8/9 are currently considered "no royalties needed"
[19:13:10 CEST] <JEEB> and a guy in FFmpeg is working on his proprietary encoder for VP9 which is why he's optimized the FFmpeg decoder for it to high heavens
[19:13:25 CEST] <JEEB> (and the FFmpeg decoder is also utilized by Firefox)
[19:13:42 CEST] <JEEB> (Chromium said that they are not taking new dependencies in so it didn't get there)
[19:13:58 CEST] <JEEB> (even though Chromium already uses FFmpeg for H.264)
[19:49:48 CEST] <tdannecy> Is there a way to take an mkv, copy video, mixdown 5.1 audio to stereo, and add it as a second channel?
[19:50:26 CEST] <CounterPillow> BtbN: Qt is actually LGPL.
[19:55:15 CEST] <c_14> tdannecy: ffmpeg -i mkv -c:v copy -filter_complex asplit[a0][a1] -map [a0] -map [a1] -map 0:v -ac:1 2 out.mkv
[19:55:23 CEST] <c_14> you'll probably need to escape all the [] for your shell though
[20:01:17 CEST] <BtbN> CounterPillow, that's why I said "for a long time"...
[20:01:54 CEST] <CounterPillow> you said "a long time", no "for", and even then that is ambiguous
[20:03:11 CEST] <tdannecy> c_14:  Hey that worked! Thanks a lot! :)
[20:05:18 CEST] <BtbN> <BtbN> Qt worked the same way a long time
[20:05:24 CEST] <BtbN> Don't see anything ambigous there
[20:05:31 CEST] <BtbN> It's clear that it doesn't anymore.
[20:05:53 CEST] <CounterPillow> unambiguous would be "used to work"
[20:06:24 CEST] <CounterPillow> omitting the helper verb could stand for "has worked", which would imply it still works that way.
[20:06:26 CEST] <BtbN> sorry for not being a native english speaker that is able to use the language to the full extend you are used to -_-
[20:06:36 CEST] <BtbN> Not in the mood for this shit right now
[20:06:37 CEST] <CounterPillow> I'm not a native English speaker either
[20:06:42 CEST] <furq> i am a native english speaker and BtbN is right
[20:06:43 CEST] <furq> hth
[20:06:52 CEST] <CounterPillow> fuck you furq you backstabbing cunt
[20:06:59 CEST] <CounterPillow> :^)
[20:07:01 CEST] <furq> rude
[20:40:02 CEST] <tdannecy> c_14:  So I tried running the command in a directory with multiple .mkv files and I get this error: Filter asplit:output1 has an unconnected output
[20:41:50 CEST] <thebombzen> JEEB: is libaom even ready?
[20:42:00 CEST] <thebombzen> cause I thought av1 wasn't even frozen yet
[20:42:09 CEST] <JEEB> no, av1 is not frozen yet
[20:42:55 CEST] <furq> The bitstream format is projected to be frozen in Q3[7] or Q4[8] of 2017.
[20:42:59 CEST] <Fenrirthviti> supposedly later this year
[20:43:44 CEST] <thebombzen> Does that mean libaom is not useable for me (as a non-developer)
[20:43:56 CEST] <furq> there's a frontend for it
[20:43:59 CEST] <furq> aomenc/aomdec
[20:44:17 CEST] <furq> but the files it produces aren't guaranteed to be decodable in the future
[20:44:19 CEST] <thebombzen> I meant "reference implementation" rather than "specifically the library"
[20:44:39 CEST] <furq> libaom is the reference implementation
[20:44:53 CEST] <thebombzen> okay and also primitive reference CLI binaries
[20:44:57 CEST] <furq> right
[20:45:17 CEST] <thebombzen> but "the files it produces might not be decodable" is a pretty good reason not to use it from my perspective
[20:45:34 CEST] <thebombzen> unless I'm specifically engaging in testing it for efficiency or speed
[20:46:04 CEST] <thebombzen> wondering if ffmpeg has avcodec/libaom.c yet
[20:55:28 CEST] <tdannecy> c_14: I had a typo and I was going crazy. Sorry. Thanks for your help.
[21:39:04 CEST] <AndroUser> I'm trying to make a closed caption transcoder arib b24 <-> cea-708 using ffmpeg, anyone have some document for me start this project?
[22:34:24 CEST] <kingsley> May I please have the benefit of your informed thoughts on why a simple filtergraph is failing?
[22:34:39 CEST] <kingsley> I'm using version 7:3.2.6-1+b3 on Debian unstable.
[22:34:47 CEST] <kingsley> The simple command is...
[22:34:58 CEST] <kingsley> $ ffplay -i /tmp/in.mkv -vf histogram /tmp/out.mkv
[22:35:14 CEST] <kingsley> ffmpeg's error message is...
[22:35:26 CEST] <kingsley> Argument '/tmp/out.mkv' provided as input filename, but '/tmp/in.mkv' was already specified.
[22:35:52 CEST] <kingsley> 15 lines of details are at ...
[22:35:56 CEST] <kingsley> https://paste.ubuntu.com/25106670/
[22:36:02 CEST] <kingsley> What do you think?
[22:47:10 CEST] <furq> uh
[22:47:14 CEST] <furq> that works for me
[22:49:09 CEST] <furq> oh right, ffplay
[22:49:34 CEST] <furq> if you want to play it, get rid of the output filename
[22:49:39 CEST] <furq> if you want to save it to a file, use ffmpeg
[22:49:50 CEST] <myke> i have a video i'm looping with stream_loop, and a fixed playlist i'm using with the concat muxer.  i want the video to end when the concat muxer is done, but -shortest ends it the first time the video plays thru.  how can i end the video when the concat muxer is done?
[22:49:53 CEST] <furq> if you want to do both, use ffmpeg and the tee muxer and pipe it to a player
[22:50:02 CEST] <furq> or just multiple outputs and pipe
[23:00:01 CEST] <myke> guess i can just pipe in that part instead of using the concat muxer and it'll end when that pipe closes, ty
[23:12:34 CEST] <kingsley> furq,
[23:12:40 CEST] Last message repeated 1 time(s).
[23:12:40 CEST] <kingsley> brave,
[23:12:44 CEST] <kingsley> courageous, and
[23:12:46 CEST] <kingsley> BOLD!
[23:12:53 CEST] <kingsley> Long live his fame!
[23:12:56 CEST] <kingsley> Long live his glory!
[23:13:05 CEST] <kingsley> And long may his story be told!
[23:13:16 CEST] <kingsley> (Ie: Thank you very much. It worked.)
[00:00:00 CEST] --- Mon Jul 17 2017