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

[burek]

[00:01:25 CEST] <DHE> I think AC3 specifically always generates 1536 samples per AVPacket, obviously per channel
[00:01:52 CEST] <DHE> but good software should be able to manage with any value because mpegts allows different audio codecs which don't all follow the same rules
[00:02:54 CEST] <th3_v0ice> I wrongly assumed then that that information was available after the decoder has been opened.
[00:19:31 CEST] <JEEB> th3_v0ice: the configuration can change freely
[00:19:40 CEST] <JEEB> stereo to 5.1 etc
[00:19:58 CEST] <DHE> heck I have channels here that change languages
[00:20:17 CEST] <DHE> anything could happen
[00:20:30 CEST] <JEEB> yea but this is within a single PID in the actual audio coding layer
[00:20:47 CEST] <JEEB> metadata changing or PID switches happening is then separately on the MPEG-TS layer
[00:21:18 CEST] <JEEB> also I might be misremembering but I think I had 900-something sample avframes from AC3?
[00:21:24 CEST] <JEEB> although I might be misremembering
[00:30:11 CEST] <th3_v0ice> Ok, I will take that into the account. Thanks!
[01:58:26 CEST] <nicolas17> when I use an image sequence as input in ffmpeg, it seems to read a frame, decode it, pass it to the encoder, then read the next
[01:58:44 CEST] <nicolas17> is there any way to make it prefetch a frame or two?
[01:59:05 CEST] <nicolas17> I guess the async: protocol won't help with that...?
[02:00:04 CEST] <nicolas17> suppose I have high latency when opening a file, how to compensate for that
[02:07:20 CEST] <pauletin> I just discovered that web browsers like chromium and firefox do not yet support playbak of 10-bit / 12-bit videos
[03:32:21 CEST] <kepstin> pauletin: hmm, i thought youtube was starting to do some HDR stuff (using vp9?)
[03:33:09 CEST] <kepstin> i guess that might not actually work in browsers tho
[04:01:49 CEST] <pauletin> oh sorry. I have checked and Vp9 and h264 work fine. Just that h265 isn't supported.
[04:14:35 CEST] <pauletin> higher bit depth I mean
[04:51:32 CEST] <kepstin> afaik no browser supports h265 at all?
[04:51:36 CEST] <kepstin> maybe some apple stuff
[05:22:03 CEST] <rjeli> yeah high sierra and ios11
[05:52:50 CEST] <zyme> kepstin: I've had this extension installed for years; it's for chrome though - not sure if that's what you use..: https://chrome.google.com/webstore/detail/h265-hevc-player/dambgipgbnhmnkdolkljibpcbocimnpd
[05:55:39 CEST] <zyme> there's also I believe extensions to open most video url's outside of your browser with VLC (if you have it installed) - and it not only supports playing h265 but it'll stream it to a chromecast2ultra if you have one too..
[18:45:33 CEST] <yuken> I'd like to run multiple instances of ffmpeg at once in a script (bash) - any recommended way to do this?
[18:46:06 CEST] <BtbN> Should just work. Just don't write to the same file, or read from one being written to.
[18:50:34 CEST] <furq> yuken: probably xargs -P
[18:52:06 CEST] <yuken> I'll check it out, thanks, furq.
[19:31:02 CEST] <yagiza> Hello!
[19:31:46 CEST] <yagiza> Can anyone clarify something about RTCP?
[19:51:23 CEST] <yagiza> When I use custom I/O for RTP muxer, first packet it sends to output is not an RTP, but an RTCP packet.
[19:52:08 CEST] <yagiza> Also, RTP demuxer from time to time sends RTCP packets to the output.
[19:53:08 CEST] <yagiza> What should I do with all these RTCP packets? Do I have to send them to RTCP demuxer input along with RTP packets?
[21:35:50 CEST] <GuiToris> hey, is -deinterlace the best thing I can do with an interlaced video?
[21:37:21 CEST] <ChocolateArmpits> GuiToris, there are different deinterlace video filters, -deinterlace is is an alias for "pp=ffmpegdeint" I think
[21:37:26 CEST] <nicolas17> interlacing is the devil
[21:37:42 CEST] <ChocolateArmpits> nicolas17, it's not at high enough resolutions
[21:38:04 CEST] <nicolas17> at high enough resolutions you can just drop a field :p
[21:38:26 CEST] <ChocolateArmpits> you mean at very very high
[21:38:32 CEST] <nicolas17> yeah :P
[21:38:40 CEST] <nicolas17> anyway, for something completely different:
[21:38:44 CEST] <ChocolateArmpits> certainly higher than a resolution that doesn't make interlacing the devil
[21:38:47 CEST] <ChocolateArmpits> anymore
[21:38:49 CEST] <GuiToris> ChocolateArmpits, I've been deinterlacing my videos with -deinterlace and I was wondering if there's a better filter than this one?
[21:38:59 CEST] <nicolas17> how can I speed up a video and interpolate frames rather than just drop them? I want some motion blur
[21:39:42 CEST] <ChocolateArmpits> GuiToris, I don't think any of the filters in ffmpeg are quality enough, and different ones have different attributes that make them useful for different situations
[21:40:26 CEST] <ChocolateArmpits> say if you want to deinterlace as fast as possible and don't care about maintaining highest possible framerate then pp=lb
[21:40:27 CEST] <JEEB> I think the motion interpolation filter in lavfi is surprisingly good
[21:40:31 CEST] <JEEB> it's just fucking slow
[21:40:43 CEST] <ChocolateArmpits> JEEB, qtgmc or bust
[21:40:51 CEST] <JEEB> that's a deinterlacer
[21:40:55 CEST] <ChocolateArmpits> oh snap
[21:40:59 CEST] <ChocolateArmpits> misread
[21:41:24 CEST] <JEEB> for deint there's like umpteen filters by now in lavfi, starting with the run-of-the-mill yadif
[21:41:38 CEST] <JEEB> but of course I don't think any of them go into the madness that's QTGMC :P
[21:41:39 CEST] <GuiToris> I'm making a very important video now and only the quality matters
[21:41:44 CEST] <ChocolateArmpits> GuiToris, for high framerate stuff and fast performance you may want to look into bwdif, it performs better than yadif and looks pretier
[21:42:17 CEST] <JEEB> I think that depends on the content? although I haven't given it larger amounts of samples. then there's the thing that mixes yadif and bwdif
[21:42:23 CEST] <GuiToris> it doesn't matter if it takes ages to proceed
[21:42:30 CEST] <JEEB> or wait, was bwdif the yadif+w3fdif
[21:42:42 CEST] <ChocolateArmpits> GuiToris, if you care about quality then investigate QTGMC that's available either with Vapoursynth or Avisynth
[21:42:48 CEST] <durandal_1707> JEEB: more than that
[21:43:07 CEST] <JEEB> yea I know there's more filters than that, do you mean it's more than just a mish-mash of yadif+w3fdif?
[21:43:26 CEST] <GuiToris> ChocolateArmpits, I'll look them up, thanks :)
[21:43:27 CEST] <ChocolateArmpits> GuiToris, in Vapoursynth it's called Havsfunc, it's a port
[21:44:41 CEST] <nicolas17> unrelated question, if I want to take every nth frame and drop the rest, I can use a select() video filter, or setpts=PTS/n, but either way all input frames get decoded
[21:45:01 CEST] <JEEB> yes, most video formats require you to decode all the things
[21:45:02 CEST] <nicolas17> if the input is intra-only (such as image2) that's wasteful... is there any way to only decode every nth frame?
[21:45:17 CEST] <JEEB> ok, if you have a special case then you'd have to code that yourself I think
[21:45:39 CEST] <JEEB> I don't think ffmpeg.c has built-in functionality to skip decoding every Nth packet
[21:45:41 CEST] <nicolas17> for every 10th frame I have been using -i "*0.JPG" as a workaround
[21:47:03 CEST] <GuiToris> I would try this motion interpolation filter too, is this included in the standard ffmpeg package?
[21:47:21 CEST] <JEEB> it is in FFmpeg itself at least, no idea which version your distribution packages
[21:47:33 CEST] <durandal_1707> for deinterlacing use -vf nnedi
[21:48:08 CEST] <nicolas17> hm I think the 'framerate' filter would do what I want re: speed up video and interpolate frames
[21:48:29 CEST] <durandal_1707> framerate filter blends frames only
[21:48:33 CEST] <JEEB> that's the very simplistic one
[21:48:38 CEST] <JEEB> you need https://www.ffmpeg.org/ffmpeg-all.html#minterpolate for motion interpolation
[21:49:19 CEST] <GuiToris> let's see, thank you for your help
[21:49:43 CEST] <nicolas17> hmm, if I wanted to increase the frame rate or slow down the video, creating new in-between frames, minterpolate seems best; but if I want to decrease framerate / speed up video / drop frames, do I really need motion interpolation?
[21:49:53 CEST] <nicolas17> guess I can try both...
[21:50:14 CEST] <JEEB> just dropping pictures you can do with a simple filter
[21:50:25 CEST] <JEEB> motion interpolation is used when going upwards
[21:50:34 CEST] <JEEB> when you need to generate "new" pictures
[21:50:38 CEST] <nicolas17> yeah
[21:50:42 CEST] <GuiToris> I assume nothing beats QTGMC, I've just looked it up and it says: A very high quality deinterlacer
[21:50:58 CEST] <durandal_1707> JEEB: bwdif is based on those filters, it combines both worlds from them, at least that was it intention
[21:51:04 CEST] <JEEB> durandal_1707: yea
[21:51:07 CEST] <JEEB> that's what I meant
[21:51:37 CEST] <JEEB> GuiToris: it's a messy mish-mash of filters (it uses some motion filters and NNEDI3 etc internally)
[21:51:50 CEST] <durandal_1707> GuiToris: it uses internally hacks and nnedi or eedi3
[21:51:57 CEST] <JEEB> it did give nice results some years ago
[21:52:04 CEST] <ChocolateArmpits> GMC -> TGMC -> QTGMC
[21:52:15 CEST] <ChocolateArmpits> there are predecessors
[21:52:40 CEST] <ChocolateArmpits> it didn't become a monster that it is today without some work before
[21:55:27 CEST] <GuiToris> durandal_1707, I've tired -vf nnedi: Error initializing filter 'nnedi'
[21:55:54 CEST] <JEEB> it's nnedi3 and it needs the weights
[21:56:01 CEST] <durandal_1707> GuiToris: was so hard to read documentation first? you need big file as input to it
[21:56:19 CEST] <JEEB> oh wait it's indeed called nnedi
[21:56:20 CEST] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#nnedi
[21:56:24 CEST] <JEEB> that's the documentation :P
[21:56:27 CEST] <JEEB> (it's based on NNEDI3)
[21:56:55 CEST] <JEEB> and it has a link to the neural network weights
[21:58:24 CEST] <JEEB> funny enough #elsewhere has been poking at NNEDI3 most of the day it seems today
[21:59:44 CEST] <durandal_1707> JEEB: who/where? there is missing simd
[22:00:25 CEST] <JEEB> yea it was the author of https://github.com/sekrit-twc/znedi3
[22:00:43 CEST] <JEEB> and the other guy very knowledgeable of various things
[22:01:09 CEST] <JEEB> znedi3 is basically twc deciding that people who think just because something runs on GPGPU makes it faster
[22:01:17 CEST] <JEEB> +are stupid
[22:01:24 CEST] <JEEB> and he made quite some optimizations to NNEDI3
[22:01:32 CEST] <JEEB> just to prove that CPU SIMD is good
[22:02:26 CEST] <durandal_1707> i need to check his timecube simd, how much extra speed does it give?
[22:02:39 CEST] <GuiToris> JEEB, https://aur.archlinux.org/packages/vapoursynth-plugin-nnedi3_weights_bin/  This is what I need, isn't it?
[22:03:00 CEST] <JEEB> GuiToris: probably, although the weights are linked from the docs. it's just a blob of data
[22:03:21 CEST] <JEEB> you just need to put the blob to...
[22:03:33 CEST] <JEEB> whatever is the default for weights
[22:03:36 CEST] <JEEB> (not mentioned in doc)
[22:04:01 CEST] <JEEB> otherwise just -vf=nnedi=weights=weights.bin
[22:04:18 CEST] <JEEB> where weights.bin is the path that fopen() gets called against
[22:04:57 CEST] <JEEB> ok, so the default is just "nnedi3_weights.bin"
[22:05:19 CEST] <JEEB> so you can just leave the thing next to where you're running stuff if you want to
[22:05:50 CEST] <GuiToris> I'm installing the weights packages now, I'm very curious
[22:06:09 CEST] <GuiToris> I'll take a little break while installing, brb
[22:24:10 CEST] <GuiToris> JEEB, tell me if I'm doing it wrong: ffmpeg -i input.MTS -vf nnedi=weights=/usr/lib/vapoursynth/nnedi3_weights.bin output.mp4
[22:24:28 CEST] <GuiToris> at least, ffmpeg is doing something
[22:24:33 CEST] <JEEB> does that give anything itneresting out? it looks valid enough
[22:24:54 CEST] <JEEB> you should have probably checked if the default mode is half-rate or full-rate
[22:24:55 CEST] <GuiToris> I don't know yet, I'm at the 3rd second
[22:25:00 CEST] <JEEB> since you probably want full-rate
[22:25:09 CEST] <GuiToris> I think so
[22:25:24 CEST] <JEEB> as in, if you for example have 50 fields per sec, if you want 25 (half) or 50 (full) rate out
[22:26:40 CEST] <GuiToris> hmmm, interesting I meant it differently
[22:26:53 CEST] <nicolas17> GuiToris: you should probably add "-t 5" to process the first five seconds, so you quickly-ish get a valid file you can look at
[22:27:08 CEST] <nicolas17> then process the full thing once you're happy with the result
[22:27:17 CEST] <GuiToris> I found a short 8 secs video, so it should take soooo long
[22:27:41 CEST] <GuiToris> but thank you for the hint btw
[22:27:46 CEST] <GuiToris> I should use -t
[22:28:06 CEST] <JEEB> also with mpeg-ts it's not exact but -ss SECONDS before defining the input
[22:28:12 CEST] <JEEB> tries to seek to that point first
[22:28:22 CEST] <JEEB> if you have f.ex. a specific scene you want to test with
[22:28:25 CEST] <JEEB> which isn't in the beginning
[22:28:53 CEST] <GuiToris> well, it's definitaly deinterlaced now
[22:29:04 CEST] <GuiToris> I should try the others so I can compare them
[22:29:33 CEST] <nicolas17> you mean the other filters?
[22:30:08 CEST] <GuiToris> yes
[22:30:26 CEST] <GuiToris> mediainfo says it's 25fps now and progressive scan
[22:30:33 CEST] <nicolas17> see if ffmpeg is using multiple CPU cores
[22:31:11 CEST] <nicolas17> if it's not, it may be a good idea to run multiple ffmpeg commands (for the different filters you're testing) at the same time :)
[22:31:23 CEST] <furq> GuiToris: use vapoursynth if you want to use nnedi
[22:31:49 CEST] <furq> oh nvm someone already recommended qtgmc
[22:31:55 CEST] <GuiToris> furq, I thought that's what I'd used now
[22:32:05 CEST] <furq> the one in vapoursynth is multithreaded
[22:32:23 CEST] <furq> also qtgmc does some other fancy stuff on top of just nnedi which is very useful for dvds
[22:33:39 CEST] <furq> honestly though if you have a clean hd source then bwdif is fine
[22:33:50 CEST] <JEEB> furq: I'm not sure about threading but znedi3 seems to have a crapload of SIMD
[22:34:07 CEST] <JEEB> (or you just meant threading withing vapoursynth in general)
[22:34:10 CEST] <furq> i did
[22:34:18 CEST] <furq> it does frame threading for pretty much everything afaik
[22:34:30 CEST] <furq> i had no idea znedi3 was a thing
[22:35:31 CEST] <furq> i'll have to check that out
[22:36:44 CEST] <JEEB> yea it's twc just deciding to optimize the hell out of nnedi3 to troll those "it's GPGPU so it must be better than the CPU based stuff" folk
[22:37:02 CEST] <JEEB> which sounds insane but I guess it worked since it brought out new SIMD :P
[22:37:29 CEST] <furq> it seems like it's generally best to ignore his motivation for doing things
[22:39:03 CEST] <GuiToris> that's interesting, I compared nnedi with -deinterlace, and nnedi made a smaller and sharper video
[22:39:18 CEST] <JEEB> -deinterlace really shouldn't be ever used
[22:39:20 CEST] <furq> i have no idea what -deinterlace even does these days
[22:39:40 CEST] <furq> but yeah nnedi is the best there is afaik
[22:39:49 CEST] <furq> which it better be considering how incredibly slow it is
[22:39:54 CEST] <GuiToris> thank goodness you pointed it out
[22:40:11 CEST] <furq> like i said, you should use qtgmc through vapoursynth if you're going hardcore on deinterlacing
[22:40:14 CEST] <JEEB> one of the guys hacking on nnedi3 today brought up some nice paper on super-resolution a few weeks ago
[22:40:24 CEST] <JEEB> wonder if we'll get a filter on that at some point
[22:40:38 CEST] <JEEB> since NNEDI afaik is far from current stuff
[22:40:55 CEST] <furq> yeah i'm not throwing away these shitty dvd sources just yet
[22:41:32 CEST] <furq> maybe i will when the channel doing the web releases of the same shows decides to turn cabac on
[22:41:48 CEST] <JEEB> lol
[22:42:25 CEST] <JEEB> that reminds me of a certain DRM vendor trying to tell me with a straight face that I would have to keep to constrained baseline for various stupid reasons
[22:42:49 CEST] <furq> to be fair all of the british tv channels are technically vod providers, so i can't complain that the streams i'm illegally ripping suck
[22:42:52 CEST] <furq> but damn they all suck
[22:43:24 CEST] <GuiToris> am I doing it right: ffmpeg -i input.MTS -vf bwdif output.mp4 ?
[22:43:36 CEST] <furq> GuiToris: you probably want -vf bwdif=1 for double framerate
[22:43:40 CEST] <JEEB> GuiToris: main thing, verify output mode if it's full rate or half-rate
[22:43:46 CEST] <furq> check both but you'll probably find double rate looks nicer
[22:43:52 CEST] <JEEB> furq: please use key=value options :<
[22:44:04 CEST] <furq> i don't even remember what that key is called
[22:44:16 CEST] <JEEB> mode=send_field
[22:44:25 CEST] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#bwdif
[22:44:42 CEST] <JEEB> ffmpeg-all.html + ctrl+F is what I often use :P
[22:45:43 CEST] <GuiToris> furq, you may be wrong, simply bwdif created a 50fps video
[22:46:00 CEST] <JEEB> bwdif might be new enough to default to full rate
[22:46:04 CEST] <furq> fun
[22:46:08 CEST] <JEEB> yadif most certainly doesn't :P
[22:46:17 CEST] <GuiToris> is yadif another tool?
[22:46:18 CEST] <furq> yeah bwdif defaults to send_field and yadif defaults to send_frame
[22:46:21 CEST] <furq> that's not confusing at all
[22:47:26 CEST] <ariyasu> bob's your uncle
[22:47:28 CEST] <furq> GuiToris: off the top of my head you've got bwdif, kerndeint, mcdeint, nnedi, w3fdif and yadif
[22:47:35 CEST] <furq> just within ffmpeg, there's loads more in other tools
[22:47:50 CEST] <GuiToris> I'll try all of them, thanks !
[22:47:51 CEST] <furq> bwdif is the best general-purpose choice right now
[22:48:02 CEST] <JEEB> I should speed-benchmark bwdif
[22:48:14 CEST] <furq> it's slightly slower than yadif iirc
[22:48:17 CEST] <furq> but still easily realtime
[22:48:28 CEST] <furq> i use it in mpv
[22:48:42 CEST] <furq> GuiToris: mcdeint is supposed to be fancy and nice but i never had good results with it
[22:48:48 CEST] <ariyasu> im still using yadif
[22:48:48 CEST] <furq> but it has special requirements to use it
[22:48:50 CEST] <furq> https://ffmpeg.org/ffmpeg-filters.html#mcdeint
[22:49:01 CEST] <JEEB> mcdeint is IIRC so old that even if it has mc in its name it's not really great
[22:49:06 CEST] <furq> i never managed to get anything other than a blurry mess out of it
[22:49:09 CEST] <JEEB> might be remembering wrong
[22:49:19 CEST] <JEEB> kerndeint is also some really old filter
[22:49:24 CEST] <furq> yeah kerndeint is ancient
[22:49:34 CEST] <furq> like i said, either use bwdif or start writing vs scripts for qtgmc
[22:49:56 CEST] <furq> qtgmc is amazing but it's not worth the cpu time unless you've got a dirty source
[22:53:38 CEST] <ariyasu> "-vf bwdif=1" = bob and "-vf bwdif=0" = weave ?
[22:53:55 CEST] <JEEB> no
[22:54:00 CEST] <JEEB> the type of deint doesn't change
[22:54:09 CEST] <JEEB> it's just if half of output gets thrown out
[22:54:18 CEST] <JEEB> also please don't effing use the non-key=value options
[22:54:21 CEST] <JEEB> for eff's sake
[22:54:43 CEST] <JEEB> mode is the name of the option
[22:54:49 CEST] <JEEB> send_frame and send_field are the values
[22:55:00 CEST] <JEEB> the documentation is right here https://www.ffmpeg.org/ffmpeg-all.html#bwdif
[22:56:03 CEST] <GuiToris> well, bwdif has the smallest video size so far
[22:56:29 CEST] <JEEB> I wouldn't really compare how CRF compresses those different outputs :P
[22:57:43 CEST] <GuiToris> I don't like mcdeint, it's not that pretty
[22:58:00 CEST] <JEEB> I would just take mcdeint and kerndeint out
[22:58:33 CEST] <durandal_1707> try w3fdif and yadif
[22:58:57 CEST] <furq> bwdif, yadif and w3fdif are the realistic contenders
[22:59:15 CEST] <furq> nnedi is too slow and the other two just suck
[22:59:56 CEST] <GuiToris> it's not a drawback if the filter is slow now
[23:00:02 CEST] <GuiToris> only the quality matters
[23:00:10 CEST] <furq> yeah but there's just no point in using it through ffmpeg when you can get it multithreaded through vs
[23:00:12 CEST] <GuiToris> I'll watch these clips for years
[23:00:15 CEST] <JEEB> nnedi3's simplicity is also a nice thing
[23:00:24 CEST] <JEEB> it's just a bobber
[23:00:34 CEST] <furq> at least last time i checked it was exceptionally slow through lavfi
[23:00:35 CEST] <JEEB> as in, it takes that field that's half the res, and scales it up
[23:00:46 CEST] <JEEB> yea it's a port of the initial VS port
[23:00:46 CEST] <furq> yeah it's just a very nice height doubler
[23:01:10 CEST] <GuiToris> JEEB, I've been watching this description for a while now https://ffmpeg.org/ffmpeg-filters.html#nnedi   which one gives me full rate (50 fps)
[23:01:11 CEST] <furq> i'm still amazed at how well qtgmc fixes badly deinterlaced stuff
[23:02:47 CEST] <JEEB> GuiToris: I think the field option, but I would guess by its age it's already giving you full rate by default
[23:02:55 CEST] Action: JEEB checks the code
[23:03:04 CEST] <GuiToris> JEEB, I got only 25
[23:03:27 CEST] <furq> i guess you want field=tf
[23:03:27 CEST] <JEEB> oh, the default is {"a",  "use frame flags, single field", 0, AV_OPT_TYPE_CONST, {.i64=-1}, 0, 0, FLAGS, "field" },
[23:03:32 CEST] <JEEB> so af
[23:03:41 CEST] <furq> or af to autodetect yeah
[23:03:56 CEST] <JEEB> so field=af
[23:04:25 CEST] <JEEB> GuiToris: btw the main point is to remember that if your content is not true interlacing then just field matching will be much better
[23:05:12 CEST] <GuiToris> what do you mean by true interlacing?
[23:05:22 CEST] <JEEB> actually interlaced content
[23:05:29 CEST] <JEEB> as in, two separate fields that are not parts of a single frame
[23:05:37 CEST] <JEEB> as interlacing by itself is just a coding method
[23:05:51 CEST] <JEEB> what's included in those 50 or 60/1.001 fields per second is up to the content
[23:06:23 CEST] <JEEB> I usually use vapoursynth or something to seek through a clip frame by frame with field separation
[23:06:58 CEST] <JEEB> and in action if you see 1-1-2-2-3-3-... then that's just progressive coded as fields
[23:07:14 CEST] <JEEB> and thus you can just match the fields to gain those images kind of back
[23:07:30 CEST] <JEEB> if it's 1-2-3-4-5-6-...
[23:07:36 CEST] <JEEB> then it's actually separate fields
[23:07:43 CEST] <JEEB> and you need to deinterlace
[23:09:10 CEST] <GuiToris> JEEB, https://ptpb.pw/utGd
[23:09:26 CEST] <JEEB> yea that doesn't actually tell you anything about content
[23:09:34 CEST] <GuiToris> shoot
[23:09:38 CEST] <ariyasu> i just ran some tests
[23:09:49 CEST] <ariyasu> bwdif results in a large filesize than yadif
[23:09:56 CEST] <ariyasu> with all other settings being the same
[23:10:12 CEST] <JEEB> the results are different and thus you get different results, news at elevent
[23:10:15 CEST] <JEEB> *-t
[23:10:30 CEST] <JEEB> seriously, just take a look at the resulting video and decide by it
[23:10:47 CEST] <JEEB> if you then need to compress it more, tweak the compression options
[23:10:50 CEST] <JEEB> that's why they're there
[23:11:14 CEST] <ariyasu> compression isnt an issue
[23:11:24 CEST] <ariyasu> just giving it a test as a may switch from yadif
[23:11:37 CEST] <JEEB> what I mean is that the file size with the same CRF value really doesn't matter
[23:11:57 CEST] <JEEB> what matters to you as a user of a deint filter is the quality of the output and the speed of the filter (in case of live streaming)
[23:12:08 CEST] <JEEB> you can always then tweak the compression options to hit whatever the hell you want
[23:12:45 CEST] <JEEB> aka I'm just noting that saying "libx264/5's CRF gave me this different result with different input!" is pretty fucking useless
[23:14:20 CEST] <ariyasu> http://screenshotcomparison.com/comparison/120065
[23:14:24 CEST] <nicolas17> my IRC client is assigning the same color to all the nicknames in the recent conversation and it's super confusing
[23:15:26 CEST] <JEEB> ariyasu: I think at this point I would output some frames lossless
[23:15:43 CEST] <JEEB> because the level of the differences seems on the level of "is this due to the other clip getting more bits?"
[23:16:13 CEST] <JEEB> and you want to remove that possibility of the lossy compression or possible JPEG compression making something look worse/better
[23:18:54 CEST] <GuiToris> if I'd like to try qtgmc, should I install vapoursynth or avisynth?
[23:19:06 CEST] <JEEB> if you're on linux you only have vapoursynth
[23:19:17 CEST] <JEEB> I also recommend Vapoursynth Editor for preview / script writing
[23:19:25 CEST] <GuiToris> https://aur.archlinux.org/packages/avxsynth-git/
[23:19:29 CEST] <JEEB> no
[23:19:32 CEST] <JEEB> do not touch avxsynth
[23:19:39 CEST] <durandal_1707> :)))
[23:19:46 CEST] <JEEB> I think it was originally open sourced by netflix but then pretty much instantly dropped
[23:19:47 CEST] <GuiToris> so it's vapursynth, thank you!
[23:19:49 CEST] <JEEB> like a hot potato
[23:21:01 CEST] <GuiToris> wow, this nnedi filter is slow indeed
[23:21:07 CEST] <GuiToris> compared to bwdif
[23:21:12 CEST] <GuiToris> really slow
[23:21:30 CEST] <GuiToris> I'm still creating that 50 fps 8 seconds long video
[23:21:44 CEST] <durandal_1707> GuiToris: how many CPUs do you have?
[23:22:09 CEST] <GuiToris> i3-2350m
[23:22:35 CEST] <GuiToris> I have to look up too
[23:22:41 CEST] <GuiToris> I would say maybe 2?
[23:22:49 CEST] <GuiToris> and 2 more threads
[23:23:57 CEST] <GuiToris> 2 cores 4 threads
[23:25:18 CEST] <GuiToris> encoding speed is 0.01x
[23:26:11 CEST] <nicolas17> lol
[23:26:19 CEST] <nicolas17> how big is your input file?
[23:26:52 CEST] <GuiToris> 17MiB 8 seconds long
[23:27:05 CEST] <GuiToris> it's done now
[23:27:14 CEST] <nicolas17> I mean is that your goal or is it just a test?
[23:27:14 CEST] <GuiToris> nnedi seems good
[23:27:25 CEST] <GuiToris> oh noo, I'm just testing
[23:27:36 CEST] <GuiToris> I assume my final video will be about 3 minutes
[23:27:52 CEST] <nicolas17> okay, not that bad
[23:28:29 CEST] <GuiToris> no, that's why I said the encoding speed doesn't really matter
[23:28:30 CEST] <nicolas17> if you had a 3-hour long video to process, it would be better to rent a server with something better than an i3-2350m, than to do it at 0.01x on your machine :P
[23:30:14 CEST] <GuiToris> I should have bought a camcorder which makes progressive videos
[23:30:48 CEST] <poutine> Has anyone done anything in Fargate with transcoding here? I have a decent setup going, but stuff like hls segments are hard to work with as you're very limited by disk space, but can do a lot in memory. I was thinking I could maybe watch for it writing chunks from output, and upload them to S3 and delete them as it goes, not sure if there's any seek back to any of the segments though
[23:31:50 CEST] <nicolas17> poutine: what software are you using to encode?
[23:33:19 CEST] <nicolas17> I don't know about the hls segment format, it's possible that the encoder will write an hls segment, then seek back to the beginning of it and write something on its header, and then move on to the next segment
[23:33:22 CEST] <nicolas17> but once a segment is done it's done
[23:33:49 CEST] <nicolas17> so if you can wait for it to close the segment file, that should be safe
[23:34:27 CEST] <poutine> nicolas17, ffmpeg
[23:35:00 CEST] <poutine> ah libx264/aac hls demuxer
[23:35:24 CEST] <nicolas17> last month I started working on a patch to let ffmpeg read files straight from S3, but it won't work for writing, and I got busy with other stuff
[23:36:43 CEST] <poutine> nicolas17, Hmm, in a different way that using a URL as an input?
[23:36:47 CEST] <poutine> that=than
[23:37:12 CEST] <poutine> we use inputs direct from s3 links and stream to s3 when using streaming formats (like mpegts)
[23:37:29 CEST] <poutine> stuff that requires seekable outputs is proving to be very difficult
[23:37:37 CEST] <nicolas17> my problem is that my *input* is HLS
[23:37:50 CEST] <poutine> nicolas17, you can -i a m3u8 file though
[23:37:58 CEST] <nicolas17> if it's publicly readable sure
[23:38:09 CEST] <nicolas17> otherwise you need a pre-signed URL for each segment file
[23:39:06 CEST] <poutine> Yeah, I've tackled that before, we had some authentication, and we tied that to the serving of the playlist m3u8, and each m3u8 request was routed to application logic which did one signature per directory and rewrote the ts segments with them, was really hacky tbh
[23:39:47 CEST] <poutine> ts segment uris
[23:42:03 CEST] <poutine> so if user is authed, give them a 24 hour link, that link goes to a m3u8, which went to application logic, which read the original m3u8, gave signed links to those (1x signature by directory with variant playlists), those led to the variant m3u8, which also hit application logic, proxied the variant playlist, which 1x signed the directory containing ts segments, and made the segment ts uris be signed urls
[23:42:43 CEST] <nicolas17> anyway
[23:43:19 CEST] <nicolas17> there might be an s3-fuse thing that does what you want: buffer files on disk or RAM while they're being written, and upload to S3 on close()
[23:43:56 CEST] <poutine> will check it out, not a huge fan of the s3 fuse stuff i've used in the past but maybe this is a better use case for it
[23:44:03 CEST] <nicolas17> poutine: btw I asked what software you were using because at first I thought I was in ##aws -.-
[23:44:39 CEST] <poutine> thanks, I am curious about your patch, in this would ffmpeg have the keys and make signed links to the hls playlists and segments?
[23:44:57 CEST] <nicolas17> -i s3://bucket/playlist.m3u8
[23:45:06 CEST] <poutine> Ok I understand
[23:45:33 CEST] <nicolas17> whatever request that does will be signed, nothing hls-specific to it
[23:46:23 CEST] <nicolas17> unsurprisingly implementing AWS Signature V4 from scratch in C is not the easiest thing in the world ^^
[23:49:23 CEST] <nicolas17> another potentially doable feature is -pattern_type glob -i "s3://bucket/frames/*.jpg" since S3 has file listing APIs :)
[00:00:00 CEST] --- Sun Sep  9 2018