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

Thu Jun 28 03:05:03 EEST 2018

[00:43:01 CEST] <ChChCherryBom1> https://pastebin.com/pXgVtuWR
[00:43:23 CEST] <ChChCherryBom1> forced_subs_only and disposition forced seem to not be working, any ideas?
[01:34:21 CEST] <darkdrgn2k> hi all
[01:34:43 CEST] <darkdrgn2k> if im receivng an RTMP stream, and the source feed to the RTMP server stops, then starts up again
[01:34:59 CEST] <darkdrgn2k> is tehre a wya to have the ffmpeg that is accessing the stream from the RTMP server continue to work
[01:35:28 CEST] <darkdrgn2k> i get "invalid dropping st:0"
[03:44:02 CEST] <acoctres> Finally home to try out that USB capture device.
[04:18:53 CEST] <Dude> does anyone have sha256 fingerprint for latest ffmpeg download?
[04:19:00 CEST] <Dude> where are those usually posted at?
[05:27:49 CEST] <kepstin> Dude is gone, but the source downloads have pgp signatures... made with some key, I suppose, I have no idea how to validate those :/
[05:35:08 CEST] <acos> Hmmm. Wow not sure
[07:57:54 CEST] <hendry> what is the output format when i want my output to be "mpegts"?
[08:44:12 CEST] <furq> hendry: mpegts
[08:44:21 CEST] <furq> if you mean the file extension then .ts
[08:46:05 CEST] <hendry> furq: ah
[08:46:30 CEST] <hendry> hoping FCPX will understand that over .mkv (which it doesn't)
[08:50:14 CEST] <furq> if you've got h264 then you probably want mp4
[08:50:28 CEST] <furq> if you don't have h264 then good luck in general i guess
[08:52:38 CEST] <ritsuka> or set it directly to .mov
[09:40:37 CEST] <blayze> av1!
[10:34:50 CEST] <hendry> ritsuka: hmm, sometimes MacOS has issues with the .mov that ffmpeg produces. Urgh
[10:35:12 CEST] <ritsuka> for example?
[10:57:40 CEST] <hendry> ritsuka: can't playback this file at all https://s.natalian.org/2018-06-27/1530086668.mov
[10:57:55 CEST] <hendry> ritsuka: mpv on Archlinux plays it back. Warning I sneeze early on.
[10:59:47 CEST] <ritsuka> QuickTime can't playback Hi444PP h.264
[11:05:01 CEST] <hendry> ritsuka: i just set the output file as .mov. What's a good file format to target from x11grab so that MacOS can play it back?
[11:05:38 CEST] <JEEB> if you want RGB lossless, use Ut Video and grab the QT component from the format's author's site
[11:05:53 CEST] <ritsuka> if you want to edit it in final cut and you have some free disk space, prores (if the ffmpeg encoder is fast enough)
[11:06:34 CEST] <JEEB> if you are going that big might as well do the Ut Video way
[11:06:36 CEST] <JEEB> and get lossless
[11:06:43 CEST] <JEEB> but yes, prores is the other thing
[11:06:59 CEST] <ritsuka> I don't know if final cut supports the classic 32bit quicktime components
[11:07:10 CEST] <JEEB> didn't he publish 64bit as well?
[11:07:19 CEST] <JEEB> not that I've used it, I just know it's getting used in the mac area
[11:07:33 CEST] <ritsuka> there is no public api for core media components, so you can't make a 64bit component/plugin
[11:28:23 CEST] <pagios> hello, any idea how to calculate the average RAM consumption of a given stream? Say an 720p standard SD stream consuming 1GB/hour
[11:30:18 CEST] <BtbN> RAM consumption of a stream?
[11:30:44 CEST] <BtbN> Every proper player won't keep more than a few frames in memory.
[11:30:58 CEST] <BtbN> And a few seconds of buffer
[11:30:58 CEST] <pagios> on the server side i mean
[11:31:00 CEST] <pagios> serving the stream
[11:31:16 CEST] <BtbN> What kind of stream?
[11:31:23 CEST] <pagios> HD stream video/audio
[11:31:26 CEST] <BtbN> ...
[11:31:30 CEST] <BtbN> HLS, RTMP, RTP, ...
[11:31:34 CEST] <pagios> hls
[11:31:46 CEST] <BtbN> I don't see why HLS would need RAM on the server.
[11:32:10 CEST] <pagios> rtmp needs?
[11:32:39 CEST] <BtbN> It's a stream, the whole point is to not buffer it, but to send it.
[11:32:50 CEST] <pagios> BtbN, so say a server is running 2GB of ram, how many clients can it serves concurrently?
[11:33:10 CEST] <pagios> 100?1000?
[11:33:11 CEST] <BtbN> That's impossible to say.
[11:33:54 CEST] <BtbN> I'd guess it hits other bottlenecks way before even getting close to the RAM limit.
[11:34:22 CEST] <BtbN> Most prominently it will clog its Network rather quickly
[11:34:35 CEST] <pagios> even if on 2GB?
[11:34:45 CEST] <BtbN> ...?
[11:34:58 CEST] <BtbN> Adding more RAM doesn't magically make the network faster.
[11:35:48 CEST] <pagios> i mean if you have 1TB network bandwidth
[11:35:54 CEST] <pagios> i am focusing on the ram size
[11:35:56 CEST] <BtbN> You don't
[11:36:03 CEST] <BtbN> If you're lucky you have 1Gbit
[11:37:17 CEST] <BtbN> And with a ~2.5Mbit/s stream like you're describing, the theoretical limit is 400 parallel streams. In practice probably notably less
[11:37:31 CEST] <BtbN> Due to overhead and other traffic
[11:37:52 CEST] <pagios> 400 parallel if over 1gbit?!
[11:38:18 CEST] <BtbN> Just do the math. 1000Mbps/2.5Mbps -> 400
[11:40:43 CEST] <pagios> i am assuming 1 sd stream is 1GB / hour
[11:40:56 CEST] <BtbN> yes, that's what I calculated with.
[11:42:06 CEST] <BtbN> 1GB/h is 1024*8 Mbit/h. Is 2.28Mbit/s.
[11:42:39 CEST] <BtbN> And 1000Mbit/s of a gigabit connection divided by those 2.28Mbit/s gives ~440
[11:43:18 CEST] <BtbN> And that's very idealized. In practice with HTTP overhead and other stuff happening on the connection, you're probably lucky if you manage 200 stable streams in parallel.
[11:49:17 CEST] <pagios> so 1GB/h for a stream recorded with a server running 1Gbps can serve 200 concurrent user
[11:50:31 CEST] <pagios> right BtbN ?
[11:50:41 CEST] <BtbN> There is no hard rule like you wish for
[11:51:04 CEST] <BtbN> 200 seems realistic to me, but who knows what other factors will come up in the real world
[14:38:47 CEST] <Guest47278> Hi, I'm using custom I/O for avformat_open_input(), the custom I/O is reading from UDP, the avformat_open_input() gets blacked and keeps calling the UDP receiving function. Where without custom I/O it's not blocked, any suggestions how to unblock it? Thanks
[14:41:41 CEST] <JEEB> by default UDP doesn't have an I/O timeout if that's what you mean
[14:41:48 CEST] <JEEB> if you look into libavformat/udp.c
[14:42:36 CEST] <Guest47278> I implemented my own udp receiving function.
[14:43:06 CEST] <JEEB> yes
[14:43:17 CEST] <Guest47278> Without custom I/O, but also udp input, it's not blocked.
[14:43:25 CEST] <JEEB> oh it was that way
[14:43:36 CEST] <JEEB> I understood that as "my custom thing works, the default doesn't2
[14:44:33 CEST] <Guest47278> It's "my custome thing blocks, the default doesnt"
[14:44:49 CEST] <Guest47278> Both are udp input
[14:46:15 CEST] <Guest47278> https://ffmpeg.org/pipermail/libav-user/2012-July/002495.html
[14:46:21 CEST] <JEEB> the default one has a separate thread
[14:46:26 CEST] <JEEB> which blocks
[14:46:34 CEST] <Guest47278> I see
[14:46:35 CEST] <JEEB> and keeps reading the input
[14:46:57 CEST] <JEEB> then you have a circular buffer which the lavf API keeps reading
[14:47:59 CEST] <Guest47278> so I have to put my custom I/O into a separate thread?
[15:02:33 CEST] <Guest47278> where are the answers for questions in such post: (https://ffmpeg.org/pipermail/libav-user/2012-July/002495.html)
[15:02:54 CEST] <Guest47278> Or it's not answered yet?
[15:04:19 CEST] <JEEB> https://ffmpeg.org/pipermail/libav-user/2012-July/thread.html#2495
[15:04:22 CEST] <JEEB> see the thread
[15:04:38 CEST] <JEEB> ctrl+F "MOV and custom IO"
[15:06:55 CEST] <Guest47278> Thanks
[16:03:40 CEST] <pagios> ?
[16:05:02 CEST] <Mathieu_Du> hrm, https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/opt.c#L217-L218 causes av_opt_set (otp, name, NULL, flags); to return ENOMEM, is this really the expected behaviour ?
[16:20:08 CEST] <fnstudio> hi, this page https://www.qubes-os.org/doc/live-usb/ says "...creating a USB boot drive for testing purposes..."; "testing" would make me think that usb-live mode is still somewhat experimental?
[16:20:55 CEST] <fnstudio> however, if i look at https://www.qubes-os.org/doc/installation-guide/#installing-to-a-usb-drive it seems usb-live mode is now fully supported?
[16:21:32 CEST] <fnstudio> no mention of "testing purposes" in the new installation guide
[16:22:04 CEST] <fnstudio> (ooops wrong chat - sorry! :) )
[16:33:00 CEST] <ChChCherryBom1> https://pastebin.com/KqkNn3N5
[16:33:16 CEST] <ChChCherryBom1> when converting subs to mov_text, they lose the timestamps or w/e
[16:33:30 CEST] <ChChCherryBom1> the forced language subs all play at the opening scene
[16:33:42 CEST] <ChChCherryBom1> but they're fine in the source file
[16:43:52 CEST] <kubast2> Hey I'm looking at kdenlive preset ,but I don't quiet understand what this portion does: bf 0 -vb 0  ,I know that -bf 0 disables b frames
[16:43:58 CEST] <kubast2> but idk what does -vb 0 do
[16:44:14 CEST] <termos> I'm trying to push some HLS stream to an HTTP entry point, but there is an error where FFmpeg is not waiting for HTTP responses and just closes the HTTP connection prematurely. Is there a way to make FFmpeg wait for responses and not just close like that?
[16:44:19 CEST] <kubast2> encoding proxy profile*
[16:44:33 CEST] <kubast2> tried to do a search on ffmpeg documentation
[16:44:38 CEST] <kubast2> but the only option I found ws vbr
[16:44:54 CEST] <kubast2> or variations on vbr ,none of them describe "-vb" behaviour
[16:48:01 CEST] <kubast2> ah
[16:48:04 CEST] <kubast2> bitrate
[16:59:49 CEST] <tuna> So I setup my hardware decoder, similar to my hardware encoder...the only difference being I setup a software decoder first to parse the incoming data off the RTSP stream so I can get my height and width of the image...then I setup a hardware decoder (and its frame contexts) with that width height, as well as the cached packet off of the first setup (of the software decoder)...what am I missing? When I "avcodec_open2" the codec context
[17:00:33 CEST] <tuna> failed reading 0xFFFFFFF location.....
[17:01:07 CEST] <tuna> I went through the c and frames context structs via MSVC debugger, but I dont see anything telling
[17:01:20 CEST] <tuna> Maybe I am missing something that is causing this to happen
[17:23:57 CEST] <tuna> Happens in both release and debug mode
[17:25:48 CEST] <BtbN> There are probe functions that find that stuff for you. No need for an extra decoder
[17:26:37 CEST] <ChChCherryBom1> im trying with -sub_charenc UTF-8 for giggles
[17:30:55 CEST] <tuna> BtbN: How do I setup the AVHWFramesContext without width and height...will it just work?
[17:33:27 CEST] <tuna> Seems to just die when I do not include width/height....for the hwframe
[17:37:04 CEST] <saml_> slack is down lols
[17:40:16 CEST] <BtbN> tuna, you don't. You probe the stream for those parameters first.
[17:41:52 CEST] <acos> Hmmm not sure
[17:43:54 CEST] <tuna> BtbN: Could you point me toward those probe functions?
[17:52:17 CEST] <BtbN> Primarily avformat_find_stream_info
[17:55:36 CEST] <saml_> tuna, what are you building? just curious
[18:04:18 CEST] <tuna> BtbN: How does that work when you are reading in packets vs using a file?
[18:04:24 CEST] <tuna> All I see is file related stuff
[18:04:42 CEST] <tuna> saml_: I am setting up an RTSP stream that need as low latency as possible
[18:04:57 CEST] <tuna> both encoding and decoding side...I cannot really say what it is for
[18:05:00 CEST] <BtbN> It works with anything avformat can read
[18:06:13 CEST] <BtbN> you call avformat_find_stream_info on it, and after that the contextx streams array is populated, and in the codecpar of each stream you find the info you want
[18:06:23 CEST] <ChChCherryBom1> https://pastebin.com/1FWdrpPb
[18:06:34 CEST] <ChChCherryBom1> ok, so I tried to just convert the subs only instead and see what happens
[18:06:50 CEST] <ChChCherryBom1> [3gp @ 0x7f98f6000000] Application provided duration: 2999288000 / timestamp: 2999288000 is out of range for mov/mp4 format [3gp @ 0x7f98f6000000] pts has no value
[18:11:41 CEST] <saml_> thats good
[18:12:00 CEST] <saml_> i just use ffmeg command
[18:19:42 CEST] <saml_> ChChCherryBom1, maybe add -c:v libx264
[18:20:23 CEST] <ChChCherryBom1> this is the video stream
[18:20:25 CEST] <ChChCherryBom1>     Stream #0:0(eng): Video: h264 (High), yuv420p(progressive), 1920x824, SAR 1:1 DAR 240:103, 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default)
[18:20:35 CEST] <ChChCherryBom1> I don't think thats related is it?
[18:20:36 CEST] <saml_> ah i see
[18:20:40 CEST] <saml_> yeah sorry my bad
[18:20:44 CEST] <ChChCherryBom1> its a timing issue from set to mov_text
[18:20:50 CEST] <ChChCherryBom1> srt*
[18:21:14 CEST] <JEEB> so it didn't like the timestamp/duration given from the input
[18:21:18 CEST] <JEEB> for one reason or another
[18:21:28 CEST] <ChChCherryBom1> yeah
[18:21:50 CEST] <JEEB> movenc.c has various "sanity" checks, some of which are dubious, some are not
[18:22:01 CEST] <JEEB> (movenc.c handles mov, mp4, 3gpp etc)
[18:22:18 CEST] <saml_> you got input files available online?
[18:22:43 CEST] <JEEB> it doesn't exactly help when mov and mp4 f.ex. sometimes have a biiiiit different specification
[18:22:47 CEST] <ChChCherryBom1> the srt?
[18:23:11 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/movenc.c;h=e2c5613f98dfa09f1ea77a6482f8bfdd6cd12b25;hb=HEAD#l5189
[18:23:23 CEST] <ChChCherryBom1> https://github.com/XeresRazor/subler this app uses ffmpeg, and converts them fine
[18:23:51 CEST] <JEEB> ok, so if DTS is smaller than reference OR duration is larger or equals INT_MAX
[18:24:11 CEST] <JEEB> ChChCherryBom1: probably however it does that ends up with a different time base?
[18:24:17 CEST] <JEEB> this sounds like a really huge time base
[18:24:27 CEST] <JEEB> if it has a time base of 2999288000
[18:24:32 CEST] <JEEB> uhh, not time base
[18:24:33 CEST] <ChChCherryBom1> oh let me see
[18:24:35 CEST] <JEEB> but duration
[18:24:39 CEST] <ChChCherryBom1> I didn't think of checking its encoded subs
[18:25:41 CEST] <JEEB> also I think durations are one of the things where it's not simple to have a single sanity check for both MOV and MP4
[18:25:46 CEST] <JEEB> since you can either have 32bit or 64bit values
[18:25:53 CEST] <JEEB> but still, it should print the time base there too
[18:25:58 CEST] <JEEB> 'cause that value is huge
[18:26:01 CEST] <JEEB> for a duration
[18:26:18 CEST] <JEEB> like you'd expect SRT input have a time base of... 1000 or so?
[18:26:27 CEST] <JEEB> because you've got .000 usually
[18:26:35 CEST] <JEEB> and thus 1000 ticks is one second
[18:26:35 CEST] <ChChCherryBom1> 1 00:49:59,288 --> 00:50:00,789 Going somewhere, Solo?
[18:26:39 CEST] <ChChCherryBom1> thats the srt
[18:27:19 CEST] <JEEB> uhh
[18:27:24 CEST] <JEEB> aren't those supposed to be dots?
[18:27:44 CEST] <FishPencil> So AOM is 1.0.0 now, does that mean it's usable? Is the bitstream finally done?
[18:27:56 CEST] <ChChCherryBom1> ffmpeg -i Star\ Wars\ A\ New\ Hope.mkv -hide_banner -map 0:2 out.srt
[18:27:59 CEST] <ChChCherryBom1> thats what it produced
[18:28:20 CEST] <saml_> what's the video? .3gp?
[18:28:22 CEST] <JEEB> FishPencil: it /should/ be normatively frozen now except for bugs
[18:28:44 CEST] <ChChCherryBom1> mkv/h264/dts/srt input
[18:28:53 CEST] <JEEB> FishPencil: they're still working on them matroska and mp4 specs though :D
[18:29:04 CEST] <JEEB> so have fun waiting for them to get that done now
[18:29:12 CEST] <saml_> ChChCherryBom1, maybe try -movflags +genpts
[18:29:24 CEST] <FishPencil> Have they moved onto making it faster yet?
[18:29:58 CEST] <JEEB> ChChCherryBom1: interesting. is there some really long line there?
[18:29:58 CEST] <saml_> ffmpeg -fflags +genpts   sorry. not -movflags
[18:30:17 CEST] <JEEB> ChChCherryBom1: because it sounds like some subtitle line has a very very long duration
[18:30:25 CEST] <JEEB> (or the time base goes bonkers)
[18:31:14 CEST] <JEEB> and the time base for SRT indeed should be 1000
[18:31:21 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/srtdec.c;h=56bd0c43f69020502b88e859a9d47b86c9791cd8;hb=HEAD#l140
[18:31:45 CEST] <saml_> and srt usually is  1\n<timestamp> --> <timestamp>\n<text>
[18:31:53 CEST] <benlieb> Im returning to a project I started about 4 years ago. Running some of the commands I get this warning:
[18:31:54 CEST] <benlieb> -qscale is ignored, -crf is recommended
[18:32:25 CEST] <JEEB> benlieb: not sure which encoders utilize qscale
[18:32:34 CEST] <saml_> -crf 23
[18:32:37 CEST] <JEEB> every encoder tends to have its own parameters
[18:32:40 CEST] <benlieb> ffmpeg -y -ss 0.0 -t 512.34 -i file.mp4 -q:v 8 -vf scale=104:-2 -aspect 720:480 'file.0-512.34.mp4'
[18:32:59 CEST] <JEEB> benlieb: that most likely picks libx264 as the video encoder or something
[18:33:00 CEST] <benlieb> I looked for -crf on this page, but didnt see it: https://www.ffmpeg.org/ffmpeg.html
[18:33:09 CEST] <JEEB> ffmpeg-all.html
[18:33:19 CEST] <JEEB> it's an AVOption for a specific encoder
[18:33:33 CEST] <JEEB> for the mpeg4 (part 2) encoder -q:v is the best you can get :P
[18:33:39 CEST] <JEEB> for anything more modern there most likely is something better
[18:33:43 CEST] <benlieb> ah ok
[18:33:57 CEST] <JEEB> you didn't set an encoder, and thus you got whatever boba fett set
[18:34:00 CEST] <benlieb> should I specify the encoder specifically? Id like to use h264
[18:34:05 CEST] <JEEB> yes, you should
[18:34:10 CEST] <JEEB> -c:v libx264 for H.264
[18:34:17 CEST] <JEEB> (and your FFmpeg has to be built with x264)
[18:34:28 CEST] <benlieb> Ok Ill give that a go!
[18:34:37 CEST] <benlieb> thats an output option right?
[18:34:57 CEST] <JEEB> yes, after input
[18:35:35 CEST] <ChChCherryBom1> its made no difference
[18:35:53 CEST] <JEEB> ChChCherryBom1: saml_ seems to have been just throwing various stuff at the wall
[18:35:55 CEST] <benlieb> I was never super good at ffmpeg, so theres probably a number of things that need adjustment. Thanks for being such a friendly channel !
[18:36:09 CEST] <JEEB> ChChCherryBom1: as I noted, is there some super long subtitle?
[18:36:30 CEST] <JEEB> unless somehow ffmpeg.c happens to generate a really weird time base for the subtitle track?
[18:36:47 CEST] <JEEB> ChChCherryBom1: can you post the full terminal log and the command line onto a pastebin and link it?
[18:36:54 CEST] <JEEB> where you are trying to create the movtext track
[18:36:59 CEST] <ChChCherryBom1> I just checked, theres no empty space
[18:37:00 CEST] <JEEB> which is where the error is happening
[18:37:07 CEST] <ChChCherryBom1> yeah one moment
[18:37:11 CEST] <JEEB> ChChCherryBom1: not empty space, a long line. in time.
[18:37:34 CEST] <ChChCherryBom1> oh like a 10 minute subtitle segment?
[18:37:51 CEST] <JEEB> that really sounds even longer than that
[18:37:59 CEST] <benlieb> where is the link to ffmpeg-all.html?
[18:38:01 CEST] <JEEB> although those values by themselves are rather useless
[18:38:06 CEST] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html
[18:38:11 CEST] <JEEB> ^ benlieb
[18:38:19 CEST] <benlieb> I can go there manually, but Id like to know how to navigate back from the ohome page
[18:38:27 CEST] <JEEB> no idea, I just always google it
[18:38:41 CEST] <JEEB> or you can in ffmpeg.c query the AVOptions for a specific encoder
[18:38:44 CEST] <JEEB> from the command line
[18:39:07 CEST] <JEEB> ffmpeg -h encoder=libx264
[18:39:09 CEST] <JEEB> for example
[18:39:46 CEST] <benlieb> ah, theres a teeny tiny link under 7 See Also
[18:48:02 CEST] <baschdel__> I know this isn't ffmpeg specific but: does somebody know What codec/format would work on a 6 year old TV (That can read digital video)?
[18:48:14 CEST] <JEEB> it can really be random
[18:48:42 CEST] <JEEB> I would first test with mp4 with its index in the front, AVC/H.264 video (main profile, level 4.0) and AAC audio
[18:49:17 CEST] <JEEB> and resolution being something like 1280x720 or 1920x1080.
[18:56:16 CEST] <saml_> ah, -fflags +ptsgen was from https://superuser.com/questions/710008/how-to-get-rid-of-ffmpeg-pts-has-no-value-error
[18:56:40 CEST] <saml_> i'm randomly googling and spitting out things
[18:56:50 CEST] <JEEB> anyways, I'd wait for the full log and command
[18:57:11 CEST] <JEEB> anyways, according to the quoted part it just seems that either something is making the subtitle time base be insanely large
[18:57:19 CEST] <JEEB> or there's a subtitle that goes on for a long, long time
[18:57:36 CEST] <ChChCherryBom1> terminal output https://pastebin.com/rz5iX3sg
[18:57:39 CEST] <ChChCherryBom1> srt file https://pastebin.com/JFQ3DNYt
[18:58:18 CEST] <JEEB> ah yes
[18:58:43 CEST] <JEEB> chapters get made as movtext because MOV was weird like that
[18:59:49 CEST] <JEEB> so unless you have a long subtitle line then I guess something is making the time base be insanely high there
[19:00:08 CEST] <JEEB> (thank  you movenc for not telling which)
[19:01:31 CEST] <JEEB> ChChCherryBom1: if you want I can give you a patch that would add some extra logging into that error but I want to have a run in the forest first before I start hacking on that :P
[19:02:26 CEST] <ChChCherryBom1> no problem
[19:02:49 CEST] <JEEB> ChChCherryBom1: aaah your input is straight out of the matroska :P and the first timestamp is at 50min D:
[19:02:54 CEST] <ChChCherryBom1> im just wondering if its possible to -map_chapters 0 then map them later on as another track
[19:03:01 CEST] <JEEB> no, it's probably not chapters
[19:03:15 CEST] <JEEB> just noticed the subtitles starting at 49min mark :P
[19:03:42 CEST] <ChChCherryBom1> no it is
[19:03:46 CEST] <ChChCherryBom1> thats whats its doing
[19:04:09 CEST] <ChChCherryBom1> https://pastebin.com/mNfx4HrB
[19:04:19 CEST] <ChChCherryBom1> thats the srt to mov_text
[19:04:29 CEST] <ChChCherryBom1> its chapter timestamps and raw subtitle dumb without timestamps
[19:04:34 CEST] <ChChCherryBom1> dump*
[19:05:11 CEST] <JEEB> anyways, running for me
[19:05:13 CEST] <donics> I'm having trouble really understanding how the order of command line options works
[19:05:18 CEST] <donics> is there a page on that somewhere
[19:13:50 CEST] <ChChCherryBom1> afaik it will tell you in error output if the command is in wrong order
[19:24:12 CEST] <ChChCherryBom1> srt to mov_text log: https://pastebin.com/d0Z4XCqL
[19:24:31 CEST] <furq> donics: ffmpeg [input1 options] -i input1 [input2 options] -i input2 [...] [output1 options] output1 [output2 options] output2 [...]
[19:24:54 CEST] <furq> and then global options whereever
[19:25:12 CEST] <furq> also input options aren't inherited from earlier inputs, and the same with outputs
[19:25:18 CEST] <donics> ok it's delimited with -i that makes sense
[19:29:06 CEST] <ntd> if i'm using an ffmpeg filtergraph to generate a grid view of 9 inputs and then play it with mplayer, this doesn't happen (a delay builds up between the feeds though). using mplayer and -geometry to have each grid be it's own processm this happens:
[19:29:08 CEST] <ntd> https://pastebin.mozilla.org/9088615
[19:29:23 CEST] <ntd> nouveau borks, display output broken until reboot
[19:29:54 CEST] <ntd> happens every other week on a quadro 5000, every third hour on an NVS290. not exactly on-topic, but any ideas?
[19:30:22 CEST] <ntd> exact same setup/install with intel or amdgpu: no problemo
[19:52:24 CEST] <kepstin> sounds like a driver bug to me. Unlike the intel and amd drivers, nouveau is all reverse-engineered, so it'll have bugs like that more often. Consider using the nvidia proprietary drivers instead.
[19:53:52 CEST] <ntd> yeah... bigger footprint, dkms hell, etc, etc
[19:54:32 CEST] <ntd> also, some of the boxes have ancient gpus (like the NVS 290), afaik deprecated in terms of driver support
[20:18:35 CEST] <furq> you could maybe consider using mpv as well
[20:18:48 CEST] <furq> i have no idea if it's better with nouveau but it's worth a shot
[20:19:38 CEST] <ntd> right
[20:46:58 CEST] <owner1> exit
[20:47:02 CEST] <owner1> quit
[21:25:00 CEST] <benlieb> running some commands from an old project and getting this error: No such filter: 'ass'
[21:25:18 CEST] <benlieb> running with mac homebrew
[21:25:40 CEST] <benlieb> tried reinstalling with --enable-libass but getting this during re-install: ffmpeg: this formula has no --enable-libass option so it will be ignored!
[21:25:50 CEST] <benlieb> how can I get the ass filter running?
[21:28:02 CEST] <benlieb> hm, maybe I need with-libass
[21:30:40 CEST] <ChChCherryBom1> https://trac.ffmpeg.org/ticket/6021
[21:30:44 CEST] <ChChCherryBom1> I wonder if this is related
[21:31:04 CEST] <ChChCherryBom1> im going to compare valid srt->mov_text against what ffmpeg is outputting and find the diff
[21:55:26 CEST] <im_dumb> which libx264 param is the option 'rc=cbr' mapped to? or is there a way i can find out?
[21:58:29 CEST] <kepstin> "rc=cbr" isn't an option, it's just something printed in the log output, I think.
[21:58:51 CEST] <kepstin> cbr mode is activated by using vbv controls with minrate=maxrate=bitrate, iirc.
[21:59:19 CEST] <kepstin> (you may additionally need other options)
[21:59:55 CEST] <kepstin> I think that's -nal-hrd cbr
[22:00:18 CEST] <im_dumb> ah ok
[22:00:27 CEST] <kepstin> of course, in general you want to not use CBR unless you are required to do so to meet some spec
[22:00:46 CEST] <im_dumb> i have to meet a spec sadly :(
[22:01:39 CEST] <im_dumb> trying to get as low latency as possible out of a custom encoder we built - of course ffmpeg is miles ahead and with a few simple command line options the latency is like .5s, but using our custom built encoder it's like 1.5 sec... so just trying to match what ffmpeg does in totality with the stuff we have here
[22:02:03 CEST] <im_dumb> what about things like 'ip_ratio=0' and 'aq=0'?
[22:04:07 CEST] <kepstin> im_dumb: those are just some quality things (related to how it chooses quantizers). Nothing you should touch manually in most cases, and it shouldn't affect latency.
[22:05:25 CEST] <kepstin> in general, when using x264, you should set the preset (speed option), options relating to rate control (either bitrate settings or crf), and if needed add a tune setting and/or set the profile limit.
[22:06:12 CEST] <im_dumb> ah ok
[22:06:33 CEST] <im_dumb> i added ultrafast/zerolatency for my preset+tune settings, but they aren't that good
[22:08:02 CEST] <kepstin> zerolatency makes the x264 encoder go one frame in -> one frame out, with hopefully just a few ms of time spent encoding the frame
[22:08:10 CEST] <kepstin> so if you have latency, it's somewhere other than the encoder
[22:09:24 CEST] <im_dumb> i think it's all the other cruft we try to do when synchronizing the encoded video and audio
[22:09:36 CEST] <im_dumb> but sadly i did not develop the application so i am quite unaware to the internals of it :(
[22:09:41 CEST] <im_dumb> but ffmpeg has it beat... easily...
[22:09:59 CEST] <kepstin> and the ffmpeg cli tool is designed for batch encoding, not low latency realtime :/
[22:12:36 CEST] <lesshaste> how could I download the audio of https://www.podbean.com/media/player/3ui6b-9412c8-pb?vjs=1 ?
[22:14:55 CEST] <kepstin> I'd suggest youtube-dl, but I don't recognize that site and I don't see it in their list. Regardless, the people there have a lot of experience in downloading web video.
[22:15:33 CEST] <kepstin> (of course, if it's just a straightforwards playback url or m3u8, you can use that as input to ffmpeg directly and tell ffmpeg to save the audio somewhere)
[22:17:47 CEST] <im_dumb> is there anything in the ffmpeg toolkit that is good for low latency/realtime use cases?
[22:19:05 CEST] <JEEB> you can configure the framework to low latency, but the defaults are not for that
[22:19:24 CEST] <kepstin> there's nothing wrong with using the ffmpeg formats & codecs as libraries in a tool designed for low latency/realtime. Some of the protocols/io stuff even work fine (although you might need to use threads to work around blocking issues with some of them)
[22:20:19 CEST] <kepstin> the ffmpeg cli tools is almost completely single-threaded, which is where some of the issues come in, since if anything blocks it'll hold up something else
[22:20:46 CEST] <JEEB> ffmpeg.c is just an example client which has with time had a crapload of stuff added to it
[22:20:58 CEST] <JEEB> so you can do scary many things with it that the API lets you
[22:21:26 CEST] <JEEB> and in theory you could tweak various paramters and make it relatively low latency, but at that point I'd think it would make sense to just start doing your own API client for your own use case
[22:25:02 CEST] <lesshaste> kepstin, thanks.. that seemed to work!
[22:25:28 CEST] <lesshaste> kepstin, is just straightforward playback but I don't know how to get ffmeg to download it
[23:24:45 CEST] <kubast2_> Hey what's a -crf value at which vp9 produces fairlly transparent value?
[23:25:00 CEST] <kubast2_> Tried -crf 17 but that was a miss
[23:25:25 CEST] <kubast2_> libvpx-vp9
[23:34:08 CEST] <kepstin> dunno, you'd have to try a few values and see
[23:34:19 CEST] <kepstin> lower numbers are higher quality, and i think the default for vp9 is 10
[23:37:21 CEST] <kepstin> (the numbers have no relation to the numbers in any other codec, e.g. x264)
[23:39:25 CEST] <kubast2_> Yeah I noticed that which is perhaps why I'm asking(besides the fact I couldn't find an answer by googling 'vp9 crf transparent value or vp9 transparent encoding or vp9 transparent encode settings')
[23:43:20 CEST] <kepstin> "transparent" is a perceptual thing, so you won't find any agreement on a single number for any codec :)
[23:43:46 CEST] <kepstin> well, i suppose you can show a lower bound with abx testing
[23:49:06 CEST] <kubast2_> Yeah I sorta did a ghetto abx just ,that I looked at the source after I looked at the encode ,-crf 17 wasn't bad ,would say that on a mobile phone it would look allright
[23:52:28 CEST] <kubast2_> as in I looked at the reencode and thought even with 1080P scale down it probablly doesn't look right versus 50GB 60Mb/s 4k hevc source
[23:55:32 CEST] <kubast2_> I did wanted to test out a couple of encoders(namelly vp9 and the 2 hevc implementations ,maybe even experimental daala) but I will wait until I get my multi pc encoding setup working
[23:56:35 CEST] <kubast2_> I will most likelly set on using dve script but modify it so it accounts for slower pcs when there are less jobs pending than devices avalible
[00:00:00 CEST] --- Thu Jun 28 2018