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

[burek]

[00:00:40 CEST] <Abzo> hello,  I need help upgrading ffmpeg..I have this error "libavccodec >= 57.37.100" but version of libavcodec is 56.60.00.100.
[00:00:57 CEST] <Abzo> any hints?
[00:01:14 CEST] <edgy> Hi, does ffmpeg supports this new av1?
[00:01:48 CEST] <DHE> Abzo: your distirbution probably doesn't include the new version. unless upgrades are available, you'll have to build it yourself
[00:02:12 CEST] <Abzo> is there any tutorial for that?
[00:08:31 CEST] Action: DHE backstabs chrome for having broken clipboarding...
[00:08:46 CEST] <edgy> no one knows? ;)
[00:08:57 CEST] <DHE> https://trac.ffmpeg.org/wiki/CompilationGuide start here
[00:09:12 CEST] <edgy> it's a yes or no question ;)
[00:09:37 CEST] <DHE> edgy: the av1 release is more of a dev announcement. no it doesn't support it, and it's going to be low priority in the short term because the codec is not very usable as-is right now.
[00:09:46 CEST] <JEEB> lol, "dev announcement"
[00:09:51 CEST] <furq> edgy: git master with --enable-libaom
[00:09:52 CEST] <JEEB> that announcement was 100% PR for NAB
[00:10:03 CEST] <furq> also yeah av1 isn't ready yet so don't expect anything good
[00:10:04 CEST] <JEEB> but yes, libaom support landed a few days ago
[00:10:21 CEST] <DHE> oh, that's fres...
[00:10:33 CEST] <edgy> JEEB: thanks!
[00:10:52 CEST] <edgy> JEEB: you are doing a great job
[00:10:57 CEST] <JEEB> but I bet AV1 will get actually finished soon, just that the PR people wanted to get the ball rolling before it actually was :P
[00:11:13 CEST] <DHE> I assumed the PR was intended to get the devs looking at it...
[00:11:25 CEST] <JEEB> since last I heard there was supposed to be a final crunch during these days
[00:11:36 CEST] <JEEB> until early april or so, to get it out of draft stage
[00:12:02 CEST] <JEEB> DHE: well it caused o9k people ask if application X supported it since it was now supposedly ready (as a format)
[00:12:13 CEST] <JEEB> and then people had to explain to them that no it's not yet
[00:12:15 CEST] <DHE> I checked, the spec was frozen in 2017.... so I assumed this was a "functional" (if slow) release just recently
[00:12:22 CEST] <JEEB> no
[00:12:31 CEST] <JEEB> the "freeze" in 2017 was not really a freeze at all
[00:12:42 CEST] <JEEB> first it was considered a soft freeze, and then all the stuff changed around
[00:12:51 CEST] <DHE> oh dear...
[00:13:28 CEST] <Abzo> DHE TY
[00:13:36 CEST] <JEEB> so at this point it was pretty much "ok, let's get the bugs for the format fixed and then it's finally goddamn finished", but the PR announcement had very little to do with that
[00:19:19 CEST] <DHE> that is disappointing... but I guess I'll go grab it and see how it does...
[00:21:57 CEST] <Mavrik> is wwww.isav1goodtouseyet.com taken? :P
[00:28:52 CEST] Action: DHE builds aom and ffmpeg with it..
[01:15:56 CEST] <DHE> wow... encoding an AV1 video at 1080p (default settings) is at 0.3 fps and I presume slowing down...
[01:34:14 CEST] <furq> does aom have any threading at all yet
[01:37:03 CEST] <JaskaL> support added like 3 days ago and you expect something out of it?
[01:37:34 CEST] <furq> the lib has been around for more than three days
[01:37:38 CEST] <wiak> soo how can i convert files with ffmpeg to get it in a input format aomenc support?, i know pix_format yuv420p output.y4m works fine for 8-bit but 10-bit and 12-bit ?
[01:37:56 CEST] <furq> presumably yuv420p10le
[01:38:38 CEST] <wiak> am using standalone aomenc*
[01:38:57 CEST] <wiak> and if someone is reading this use my nick in the answer :P
[01:39:09 CEST] <furq> wiak: presumably yuv420p10le
[01:39:28 CEST] <wiak> thanks soo for 10-bit input good to know
[01:39:39 CEST] <furq> and 12le
[01:39:43 CEST] <wiak> aah
[01:39:57 CEST] <wiak> kinda confusing compared to aomenc help says i444 etc
[01:39:57 CEST] <wiak> hehe
[01:40:17 CEST] <wiak> yuv420p, yuv420p10le and yuv420p12le
[01:44:11 CEST] <DHE> furq: it's in the source, but not effective yet... :/
[02:14:10 CEST] <FishPencil> Is there a way to just get the SSIM results without all the other console output? maybe FFprobe can do it?
[02:14:46 CEST] <DHE> doesn't work that way.
[02:15:39 CEST] <DHE> there's an ssim filter so you can save data to a text file...
[02:15:51 CEST] <DHE> if you can make that work after the fact
[02:16:02 CEST] <FishPencil> I still have to process that file then
[02:16:20 CEST] <FishPencil> I'll just try to hack in a pipe solution
[02:20:39 CEST] <furq> it is a bit annoying that those messages don't go to stdout but i guess it's understandable
[02:21:33 CEST] <furq> but yeah 2>&1 | grep ssim works
[02:30:59 CEST] <DHE> av1: 48 minutes to process 68 frames, all of which appear to be buffered in the encoder so far. so I have yet to receive any frame data yet
[02:31:59 CEST] <furq> nice
[02:32:18 CEST] <DHE> x264 on Slower on the same video using ~6.5 threads has done ~65500 frames...
[02:32:50 CEST] <furq> so 0.02fps then
[02:33:12 CEST] <DHE> ffmpeg reports speed=0.00117x so far...
[02:33:48 CEST] <DHE> and what annoys me most is that the `perf` report says it's using avx2 and sse2/3 optimized functions extensively...
[02:55:04 CEST] <Johnjay> furq what source code tools do you use
[02:55:13 CEST] <Johnjay> like if you want to go to a function definition
[02:55:20 CEST] <Johnjay> i know there's like an emacs thing for that
[05:19:20 CEST] <kepstin> DHE: yeah, these early reference encoders tend to do really simple exhaustive searches when deciding how to encode stuff
[05:19:46 CEST] <kepstin> DHE: it won't be until someone goes and add some heuristics that it'll get reasonable
[05:21:15 CEST] <furq> that's a fair point but it's undermined a bit by that recent press release
[05:27:53 CEST] <kepstin> hmm? the press release says "Unoptimized, experimental software decoder and encoder", that's consistend...
[05:29:14 CEST] <kepstin> doing exhaustive searches in the reference encoder is great for spec devs, because it means you're maximizing quality (according to the metrics used in the encoder), so it gives the best possible quality/bit to make advertised numbers look good.
[05:30:34 CEST] <tdr> or simply gives a matrix of metrics for folks to argue how it really is "good" even when it doesn't appear to be when human eyes view it
[05:33:03 CEST] <kepstin> the classic example of an exhaustive vs. heuristic search is motion vector searches - exhaustive means for each block, check every possible source location and pick the one that matches best
[05:34:04 CEST] <kepstin> while most faster encoders will use iterative searching using a pattern to try to follow the motion and find a good enough match.
[05:34:47 CEST] <furq> i guess it does mention the unoptimised encoder
[05:34:50 CEST] <furq> that's fair enough then i guess
[05:35:26 CEST] <furq> i thought libaom was a continuation of libvpx, so i figured it would carry over some optimisation for free
[05:35:42 CEST] <furq> if it's strictly supposed to be a reference encoder then yeah it's unsurprising that it's slow as shit
[05:38:29 CEST] <kepstin> there's enough new encoding tools and modifications in there that i suspect not all that much of the libvpx encoder they started with would really be left, assuming they did start with that.
[06:43:22 CEST] <monkeyisl> where should i start compile it for android?
[07:58:44 CEST] <wiak> ./ffmpeg -strict -1 -i source.mkv -pix_fmt yuv420p10le 7s.y4m > 'yuv420p10le' is not an official yuv4mpegpipe pixel format.
[08:02:11 CEST] <furq> wiak: -strict -1 is an output option
[08:05:20 CEST] <liyou> use 'yuv420p', wiak
[08:09:25 CEST] <furq> he specifically wants 10/12-bit
[08:11:33 CEST] <wiak> i want 10bit to feed aomenc
[10:46:26 CEST] <Matador> DHE wow... encoding an AV1 video at 1080p (default settings) is at 0.3 fps and I presume slowing down...
[10:46:27 CEST] <Matador> haha
[10:46:59 CEST] <Matador> maybe one day
[10:48:53 CEST] <dv_> it wants to create a really good video just for you, so it is extra careful!
[13:15:55 CEST] <th3_v0ice> Hi guys. I wanted to generate PTS and DTS values for one of my h264 streams, but by doing so my output framerate changes. What exactly determines framerate, because I have set it for output context's stream but it gets changed. Thanks!
[13:19:18 CEST] <BtbN> The timestamps do.
[13:24:22 CEST] <Mavrik> Yeah, there's no "framerate" in h264 videos per-se
[13:24:30 CEST] <Mavrik> The timestamps you're generating dictate when frames are shown
[13:26:00 CEST] <th3_v0ice> BrbN: So what You are essentially saying is, if my timestamps are two times more apart my framerate will be halfed?
[13:26:23 CEST] <th3_v0ice> Mavrik: Same question for You :)
[13:36:51 CEST] <th3_v0ice> BtbN, Mavrik: Then I dont understand something. My encoder is outputting timestamps at 1/25 timebase. They are converted into AVFormatContext timebase which is the same 1/25 (is this low?). Now I dont mux immediatelly but at a later stage. So i am trying to append saved PTS and DTS to the AVPacket's from the h264 and mux it into a new output stream. The new streams timebase is 1/12800. When the muxing is done I get a video with halfed framerate. What cou
[13:36:51 CEST] <th3_v0ice> ld be the problem here? Thanks!
[13:44:46 CEST] <_raven__> hi
[13:47:39 CEST] <teratorn> th3_v0ice: how are you converting the timestamps to that timebase?
[13:48:48 CEST] <th3_v0ice> teratorn: av_packet_rescale_ts(enc_pkt, encoder_timebase, stream_timebase)
[13:48:57 CEST] <_raven__> i need to assemble a video stream out of a directory of changing images - short: random slideshow in video stream. how to build a chain able to pick the images randomly, doing fades and display every image for 10 seconds without interruption of the stream?
[13:49:11 CEST] <_raven__> anything i can do with built in thinks like buffers or such?
[13:49:22 CEST] <teratorn> th3_v0ice: a nicer api than the last time I did it... :)
[13:50:21 CEST] <th3_v0ice> teratorn: Hehe, yeah, a lot of the things are polished :)
[13:50:50 CEST] <teratorn> th3_v0ice: I dunno timestamp issues are a royal bitch
[13:51:23 CEST] <teratorn> are you sharing the packets ?
[13:51:23 CEST] <th3_v0ice> teratorn: No problem man. Thanks anyway :)
[13:52:27 CEST] <teratorn> _raven__: "buffers" ?
[13:52:57 CEST] <teratorn> _raven__: there are filters that will let you dup an image in to a video stream
[13:54:33 CEST] <_raven__> teratorn: i know but i do not want to end the stream itself after the image is timed out again
[13:59:57 CEST] <teratorn> _raven__: https://superuser.com/questions/1001039/what-is-an-efficient-way-to-do-a-video-crossfade-with-ffmpeg/1001040
[14:00:11 CEST] <teratorn> complicated...
[14:06:10 CEST] <_raven__> teratorn: my main issue is: how to keep the stream running on a picture change after x seconds. my suggestion is i need some kind of fifo ts wrapper which generates the stream and is fed from another process selecting the images
[14:09:46 CEST] <_raven__> kind of "while true; do ffmpeg -loop 1 -i randomimage -t 10 -r 25| ffmpeg -i {pipe|repeat-last-valid-frame-on-input-loss} -f mkv -r 25 -vf foo streamSink.out
[14:12:53 CEST] <_raven__> kind of "while true; do ffmpeg -loop 1 -i randomimage -t 10 -r 25; done | ffmpeg -i {pipe|repeat-last-valid-frame-on-input-loss} -f mkv -r 25 -vf foo streamSink.out
[14:18:44 CEST] <_bigslick> Hey guys. I have some video files (mp4), which have a resolution of 1920:1080, video codec H.264, audio aac. Now I need to downsample this videos to 720, 480 and 360. I'm wondering, if I just use
[14:19:40 CEST] <_bigslick> -vf, scale=<scale> or if I also should use -c:v libx264, crf and presets
[14:20:16 CEST] <_bigslick> I'm asking, because the downsampling runs awfully slow.
[14:35:12 CEST] <th3_v0ice> teratorn: It seems that my encoder is actually outputting only half framerate then it should. Do You know what could be the problem?
[14:55:29 CEST] <teratorn> th3_v0ice: is the video still playing at the correct speed?
[14:55:56 CEST] <th3_v0ice> teratorn: Its not, half of the speed.
[14:56:19 CEST] <teratorn> if you multiply the timestamps by 2 does that "fix" it?
[15:01:22 CEST] <th3_v0ice> Nope, it doesnt. Its like its missing resolution. If I multiply timebase by 2  then its ok. But again this is not the case for every video :)
[15:05:36 CEST] <c_14> _bigslick: you should also use codec options, otherwise it should default to libx264 preset medium (you'll most definitely want -c:a copy btw)
[15:32:29 CEST] <modus771> hello?
[15:34:27 CEST] <modus771> I'd like to know the best way to install ffmpeg on 64-bit Windows 7, please.
[15:35:16 CEST] <JEEB> grab a 3rd party's build, or build yourself. there's no further installation required
[15:37:19 CEST] <modus771> Thank you. I already downloaded a build. I'm not a developer and I have no tools for programming, so I can't build it myself anyway.
[15:38:50 CEST] <modus771> The package I downloaded is ffmpeg-20180402-02ae52d-win64-static.zip
[15:40:47 CEST] <modus771> So, what should I do next with my ffmpeg-20180402-02ae52d-win64-static.zip package?
[15:42:00 CEST] <teratorn> th3_v0ice: so whats the difference with your inputs?
[15:42:36 CEST] <th3_v0ice> teratorn: This seems to be the behaviour caused by the bwdif filter :)
[15:43:17 CEST] <teratorn> th3_v0ice: ok, lovely :)
[15:43:56 CEST] <modus771> I'd like to know the best way to install ffmpeg on 64-bit Windows 7, please.
[15:44:30 CEST] <JEEB> modus771: it probably contains ffmpeg.exe and ffprobe.exe, put those into a directory and add that directory to your PATH
[15:44:34 CEST] <JEEB> that is all
[15:44:46 CEST] <JEEB> then you can call "ffmpeg" and "ffprobe" from all of your places from command line :P
[15:44:50 CEST] <JEEB> (or batch scripts etc)
[15:45:07 CEST] <modus771> Thank you JEEB. I think I can do that.
[15:45:09 CEST] <JEEB> and if you're OK with specifying the full path to the binary, you don't even need to add it to PATH
[15:45:28 CEST] <JEEB> you just have to B:\random\path\ffmpeg or ffprobe
[15:45:32 CEST] <JEEB> (´4@)
[15:46:19 CEST] <modus771> I shall try your advice at once. Thank you, and good-bye for now.
[17:03:44 CEST] <goooop> hi
[17:33:07 CEST] <DHE> in case anyone's curious about my AV1 encode job, it's been nearly 16 hours. 351 frames have gone into the encoder (fewer have come out due to buffering)
[17:35:14 CEST] <kerio> DHE: which cpu are you using?
[17:35:45 CEST] <kerio> is av1 intra-only?
[17:36:20 CEST] <dv_> no, it supports P frames IIRC. but no B frames
[17:36:50 CEST] <DHE> it's a Ryzen 7 1700 running at 3 GHz right now, but av1 is only using 1 thread.
[17:36:50 CEST] <BtbN> and it still beats HEVC by 30%, without B frames?
[17:37:09 CEST] <kepstin> i wonder if they're doing the alternate ref picture like vp9 does, still
[17:37:10 CEST] <BtbN> Did you underclock it?
[17:37:13 CEST] <kepstin> which is sort of like a b frame
[17:37:41 CEST] <JEEB> yea, I'm pretty sure tehy took teh VPx way of doing invisible ref frames
[17:37:54 CEST] <DHE> BtbN: I might have. I had stability issues I was troubleshooting a while back. Probably still left that way.
[17:38:13 CEST] <BtbN> I'm not 100% sure, but even for a 1700, 3GHz seems awfully low
[17:38:28 CEST] <BtbN> my 1800X happily sits at 4.1GHz under heavy single-threaded load
[17:39:10 CEST] <DHE> note to self: fix bios settings
[17:39:13 CEST] <kerio> not sure why, but i read that as "single-threaded lold"
[17:40:45 CEST] <BtbN> oh, no, 3GHz is actually the Base Clock for the 1700
[17:40:58 CEST] <BtbN> But it has a Boost Clock of 3.7GHz, which it should hit with that kind of load
[17:41:29 CEST] <DHE> I'm sure it's bad/conservative bios settings at this point...
[17:41:58 CEST] <BtbN> Is it still one of the faulty early models?
[17:42:47 CEST] <kepstin> I rma'd my faulty one
[17:42:55 CEST] <kepstin> didn't affect video encoding tho, mostly just compilation
[17:43:26 CEST] <DHE> yes it is... and the stability issue turned out to be USB related but that's besides the point...
[17:43:46 CEST] <DHE> though it does sometimes crash under heavy GCC loads. disabling SMT seems to help in that regard... (eww..)
[17:44:42 CEST] <kepstin> btw, if you want to see the actual speed the cores are running at (incl. boost clocks), that's exposted in /sys/devices/system/cpu/cpufreq/policy*/scaling_cur_freq
[17:44:48 CEST] <DHE> on the topic of av1, ffprobe indicates all video frames are key_frames=1 and pict_type=?   (actually a question mark)
[17:45:15 CEST] <kepstin> DHE: probably a bug with the wrapper code.
[17:45:34 CEST] <DHE> well, the short segment I have so far plays correctly so I'll let that slide for now...
[17:46:05 CEST] <kepstin> i mean, you're talking about an experimental decoder for a codec that doesn't have a finalized spec :)
[17:48:05 CEST] <kerio> i thought it was finalized
[17:49:04 CEST] <kepstin> i mean, it's certainly close? I wouldn't expect any substantial changes, and it might be that they end up using the current draft unmodified
[17:49:56 CEST] <kepstin> it's to the point where they're ready for people to be working on writing new decoders/encoders for it
[17:50:46 CEST] <JEEB> kerio: it's close but not yet :P the announcement was done 100% by the PR people and the people doing technical stuff were like ?!?!
[17:50:56 CEST] <kepstin> DHE: if your chip reproducibly crashes under heavy gcc loads (you see segfaults in gcc or bash processes), then AMD *will* replace your processor through RMA.
[17:52:40 CEST] <DHE> kepstin: yes it does... I'll look into that then...
[17:53:00 CEST] <DHE> so far I've just been dealing with it using lower parallelism builds or CPU affinity
[17:59:04 CEST] <dv_> <kerio>	is av1 intra-only? <- woops, I read avi :)
[18:09:04 CEST] <wyatt8740> I'm trying to port some software from 2011 which uses ffmpeg so it can build with new versions of the libraries it uses. Is there some list of API/ABI changes and breakages? (and preferably suggestions on how to adapt existing software, but I can deal without that if necessary)
[18:12:29 CEST] <sfan5> https://github.com/FFmpeg/FFmpeg/blob/master/doc/APIchanges
[18:13:49 CEST] <wyatt8740> thanks :)
[18:14:51 CEST] <BtbN> it's the very first google hit for "ffmpeg api changes"
[18:15:17 CEST] <wyatt8740> lol, I'm sorry
[18:15:26 CEST] <wyatt8740> I was googling the specific functions that got removed
[18:15:31 CEST] <wyatt8740> so I didn't think to do that
[18:15:33 CEST] <wyatt8740> my bad
[18:16:27 CEST] <wyatt8740> I suppose I can figure out how the calling conventions change by looking at those commits
[18:16:45 CEST] <BtbN> pretty sure it always was and still is cdecl
[18:17:34 CEST] <wyatt8740> again, I don't know the actual terminology, but I didn't mean that
[18:17:45 CEST] <wyatt8740> I meant "what structures/data I need to pass to the function"
[18:17:55 CEST] <wyatt8740> and "how that's different from the removed function"
[18:19:20 CEST] <wyatt8740> I'm mostly self-taught so I don't always know the correct terminology, unfortunately.
[18:20:04 CEST] <wyatt8740> also, cdecl is specific to 8088/8086 and descendants, I think
[18:22:05 CEST] <BtbN> cdecl is the standard calling convention on every modern platform.
[18:22:36 CEST] <kurufu> unless you are a devout m$ acolyte
[18:23:00 CEST] <BtbN> Yeah, they like their stdcall
[18:23:59 CEST] <wyatt8740> hah, even MIPS/POWER? I'm learning something today
[18:24:51 CEST] <BtbN> the actual assembly generated for cdecl varies by platform, but it's still cdecl
[18:26:18 CEST] <wyatt8740> my only assembly experience has been on the 6502 and derivatives, where C isn't really a language of choice due to memory usage
[18:26:21 CEST] <wyatt8740> so I didn't know that
[18:58:01 CEST] <zumba_addict> Good morning folks. I would like to pipe the output of netcat to ffmpeg. What would be the parameters? The incoming stream being received by netcat is mjpeg
[18:58:35 CEST] <DHE> ffmpeg should be able to make TCP connections for itself. you may be able to forgo netcat entirely.
[18:59:11 CEST] <DHE> otherwise you can use "-" as the input filename to read from stdin as usual
[19:15:51 CEST] <furq> zumba_addict: -f mjpeg -i -
[19:33:20 CEST] <zumba_addict> just got back, thank you furq
[19:33:44 CEST] <zumba_addict> do I also add -vcodec mjpeg?
[19:34:29 CEST] <saml> what's a container I can use for libx246 -crf 0    so that I can pipe stdin?
[19:34:41 CEST] <saml> there's no audio. only video
[19:35:24 CEST] <kepstin> if you're just piping between multiple ffmpeg processes, nut is often a good option
[19:35:35 CEST] <kepstin> otherwise, it depends on what the other end of the pipe supports...
[19:38:51 CEST] <alexp> hey guys, if i'm downscaling from 4K to 1080p, is it cool to use the default scaling method, or does lanczos still have any real benefit in this scenario?
[19:48:15 CEST] <furq> you will definitely benefit from lanczos
[19:56:34 CEST] <alexpigment> furq: awesome, thanks for the info
[19:57:47 CEST] <dystopia_> im using spline
[19:58:01 CEST] <dystopia_> what benefit does lanczos have?
[19:59:06 CEST] <alexpigment> i know that lanczos is traditionally the best. i don't really know what spline does tbh
[20:00:06 CEST] <alexpigment> another question: is there an ideal method to convert from 44.1 to 48khz?
[20:00:14 CEST] <alexpigment> i usually just do -ar 48000
[20:00:28 CEST] <alexpigment> didn't know if there was an equivalent to sws_flags for audio resampling
[20:00:39 CEST] <furq> you probably want to bump -filter_size
[20:00:44 CEST] <furq> it doesn't make a huge difference though
[20:00:52 CEST] <alexpigment> is there a recommended value?
[20:01:06 CEST] <furq> it maxes out at 256 iirc
[20:01:13 CEST] <furq> and that's not very much slower so i normally just use that
[20:01:19 CEST] <alexpigment> so i could just set it to 256 then?
[20:01:20 CEST] <alexpigment> ok
[20:02:24 CEST] <furq> also i don't really know which is the best resizer in swscale
[20:02:32 CEST] <furq> i normally just pick lanczos because it's a safe bet
[20:02:36 CEST] <furq> i use spline16 with zscale
[20:02:56 CEST] <JEEB> alexpigment: swresample and avresample do a high quality resample
[20:03:11 CEST] <JEEB> so I wouldn't worry about poking around the resampling options
[20:03:18 CEST] <alexpigment> JEEB: so just using -ar 48000 is enough?
[20:03:23 CEST] <JEEB> yes
[20:03:30 CEST] <alexpigment> good to know. thanks
[20:03:31 CEST] <JEEB> although I usually like to specifically do a filter chain myself
[20:03:39 CEST] <JEEB> (which is what that option does implicitly)
[20:03:51 CEST] <furq>     ffmpeg -i "$1" -af aresample=osr=$rate:osf=s16:dither_method=triangular_hp:filter_size=256 -compression_level 12 "$2"
[20:03:56 CEST] <furq> that's my all-purpose resampling line
[20:04:14 CEST] <JEEB> yea there's options but (´4@)
[20:04:20 CEST] <furq> yeah there's a ton more options
[20:04:56 CEST] <furq> there's no harm bumping filter_size and it'll always improve things so you might as well
[20:05:00 CEST] <furq> but it's unlikely to be audible
[20:06:16 CEST] <alexpigment> i guess i'll go with your method then furq
[20:07:09 CEST] <alexpigment> not that I really care too much about all this, but for the sake of preservation when conforming to blu-ray, i might as well strive for the best even if it doesn't have any noticeable effect
[20:08:08 CEST] <furq> i assume dither_method is a no-op if your source is s16 but you might want to remove it anyway
[20:10:05 CEST] <alexpigment> my source is s16 fwiw
[20:11:03 CEST] <alexpigment> is dither method only relevant when changing bit depths?
[20:11:12 CEST] <furq> yeah
[20:11:22 CEST] <furq> i only ever resample when i'm changing bit depth
[20:11:48 CEST] <alexpigment> i'm going from 44.1k 16 to 48k 16
[20:11:51 CEST] <furq> you can get rid of osr as well
[20:11:53 CEST] <alexpigment> pretty simple
[20:11:57 CEST] <alexpigment> yeah, i was thinking so do
[20:11:58 CEST] <alexpigment> *too
[20:11:59 CEST] <furq> i'm pretty sure they're no-ops anyway
[20:12:33 CEST] <alexpigment> well, now i'm basically just back to filter size as an additional option :)
[20:12:37 CEST] <furq> lol
[20:12:48 CEST] <furq> yeah that's more or less the same as just -ar 48000 -filter_size 256
[20:13:10 CEST] <alexpigment> it took me 10 minutes to get back to the same place :)
[20:13:17 CEST] <furq> you're welcome
[20:17:40 CEST] <zumba_addict> this generated a bad mjpeg file. I can only see like 10 pixel rows of the area being recording. Everything else is green - ffmpeg -f mjpeg -i - -vcodec libx264 output2.mp4
[20:18:31 CEST] <zumba_addict> I also saw this while it's running - https://pastebin.com/NEceENSw
[20:37:30 CEST] <zumba_addict> this is how it looks like - https://imgur.com/a/zSSDH
[20:37:36 CEST] <zumba_addict> basically I
[20:38:19 CEST] <zumba_addict> basically I'm piping the output of netcat to ffmpeg. nc -v -ul 3117 | ffmpeg -f mjpeg -i - -c:v mjpeg -q:v 3  -an output.mov
[21:14:28 CEST] <poutine> I highly doubt this but there's no domain experts in here that knows about CEA 608/708 caption embedding? Trying to embed captions either as muxed CEA 608 in the elemental h264 video stream, or ID1 708. Have input of SRT but that's flexible. Have tried libcaption, and they are present, but are delayed by like 4-5 seconds (extracting the SRT again from the finished product shows the timestamps as being right), and not seeing a whole ton of
[21:14:28 CEST] <poutine> open source/linux options apart from libcaption. Don't need a full solution, just if anyone has even a hint on how to do this I can handle the rest. I know ffmpeg doesn't do it, so it's a little off-topic, but will only ask this once, thanks
[21:18:49 CEST] <Fenrirthviti> poutine: we have caption support in OBS, but I don't recall if it's CEA compliant or not
[21:19:36 CEST] <Fenrirthviti> oh, nevermind we just use libcaption
[21:19:55 CEST] <poutine> I like libcaption, it works well for twitch streaming, just not this more traditional partner we're working with
[21:20:04 CEST] <jkqxz> poutine:  <https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2018-March/227320.html>.
[21:20:26 CEST] <poutine> oh wow jkqxz, that does look relevant, thanks
[21:21:00 CEST] <jkqxz> Not sure if that's in a form you can actually use.  You need to be able to attach the CEA 708 caption data as side data to the packets.
[21:21:31 CEST] <jkqxz> And if the stream has any reordering then you will need to handle that externally.
[21:23:00 CEST] <jkqxz> But all the structual code for embedding is there and hackable.
[21:23:50 CEST] <poutine> jkqxz, really appreciate the lead here, thanks
[21:39:24 CEST] <utack> does anyone else get a segfault when using vmaf? i have ffmpeg from just now (ffmpeg version N-90583-g5710fdaeae) and vmaf git from today (1.3.1.r92.g9ed2313-1)
[21:40:24 CEST] <utack> i used "ffmpeg -i lorem -i ipsum  -lavfi libvmaf -f null -"
[21:41:18 CEST] <saml> what are lorem and ipsum?  video files?
[21:41:23 CEST] <utack> yep
[21:41:36 CEST] <utack> just regular mkv files
[21:41:36 CEST] <saml> i  haven't had segfault. just curious :P
[21:41:57 CEST] <utack> but commandline looks ok to you ?
[21:42:24 CEST] <saml> i think so.  maybe try  -filter_complex libvmaf  instead of -lavfi
[21:42:48 CEST] <utack> that also segfaults
[21:42:56 CEST] <furq> those two options are aliases
[21:43:03 CEST] <utack> i guess it must happen somewhere in libvmaf
[00:00:00 CEST] --- Tue Apr  3 2018