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

[burek]

[00:00:18 CEST] <thebombzen> it won't look as good
[00:00:18 CEST] <bf_> is preset fast affecting aac or x264?
[00:00:21 CEST] <furq> x264
[00:00:31 CEST] <alexpigment> thebombzen: anyway, it sounds like we agree here. the expanded color range of HDR (10-bit + bt2020) is a hell of a lot more meaningful than the 4K resolution itself
[00:00:33 CEST] <thebombzen> no the :v in the -preset:v tells it "preset for the video stream"
[00:00:40 CEST] <thebombzen> alexpigment: yea I agree
[00:00:48 CEST] <bf_> thank you furq and thebombzen
[00:00:54 CEST] <thebombzen> I have a 1080p 24 inch monitor and I don't really feel a need for extra resolution
[00:00:58 CEST] <furq> also do you really need a 160kbps stream in this day and age
[00:01:00 CEST] <bf_> is there anything else that jumps to the eye in that command? like bad rates?
[00:01:06 CEST] <bf_> thanks :D
[00:01:17 CEST] <TD-Linux> thebombzen, 144p is borderline watchable on a phone
[00:01:21 CEST] <alexpigment> thebombzen: that's because you're a smart person who bought a monitor that is appropriately sized for the resolution ;)
[00:01:31 CEST] <alexpigment> these jokers out here with 21" 1080p monitors... ;)
[00:01:36 CEST] <furq> bf_: you're probably also going to want to downscale the lower bitrate videos
[00:01:39 CEST] <bf_> furq: should I ditch it and only go med/high or use a higher setting for low?
[00:01:41 CEST] <furq> although that will also cause a slowdown
[00:01:48 CEST] <thebombzen> also 128k and 256k are very low  resolutions
[00:01:54 CEST] <furq> tbh 512+128 is probably what i'd be using for low
[00:01:57 CEST] <thebombzen> very low bitrates*
[00:01:57 CEST] <furq> unless this is really low res
[00:01:58 CEST] <thebombzen> for video
[00:02:06 CEST] <TD-Linux> you can try it on youtube
[00:02:10 CEST] <bf_> no it is mainly a POC for desktop comuputers
[00:02:26 CEST] <furq> but yeah unless this is sub-saharan africa, nobody's going to use 128+32
[00:02:26 CEST] <thebombzen> TD-Linux: was talking to me
[00:02:33 CEST] <thebombzen> 128k and 256k are very low bitrates for video
[00:02:38 CEST] <furq> that's too high for 56k and too low for literally anything better than 56k
[00:02:40 CEST] <thebombzen> unless you've got absurdly low resolution
[00:02:59 CEST] <bf_> furq: actually I only want 720p or higher
[00:03:04 CEST] <TD-Linux> youtube's 144p is 128kbps video 60kbps audio
[00:03:07 CEST] <furq> lol
[00:03:14 CEST] <furq> you want 720p at 128kbps?
[00:03:15 CEST] <TD-Linux> furq, terrible 2G and 3G connections
[00:03:15 CEST] <thebombzen> lol but this is 720p
[00:03:23 CEST] <furq> that's going to look fucking awful
[00:03:34 CEST] <bf_> furq: %) sorry
[00:03:35 CEST] <alexpigment> TD-Linux: it feels like they're using that for 360p too, lol
[00:03:36 CEST] <thebombzen> yea 144p might only look okay on a phone if you have a small screen
[00:03:38 CEST] <furq> i wouldn't even bother with mid without scaling
[00:03:38 CEST] <thebombzen> like old iphone
[00:03:49 CEST] <bf_> no I want 720p at a reasonable bitrate ofc
[00:03:51 CEST] <TD-Linux> oh I was replying to the earlier conversation not the one involvinb bf_
[00:03:53 CEST] <furq> i wouldn't do anything less than 1mbit for 720p
[00:03:57 CEST] <TD-Linux> bf_ ignore me
[00:04:00 CEST] <furq> and even that's pushing it
[00:04:07 CEST] <bf_> sorry to crash your conversation TD-Linux
[00:04:17 CEST] <thebombzen> if you have a newer phone like a newer iphone or newer galaxy then 144p will look terrible on a phone
[00:04:31 CEST] <furq> 144p will look terrible on anything newer than a nokia 3210
[00:04:34 CEST] <thebombzen> but 480p looks fine on the "plus-sized phones" even though they have 1080p screens
[00:04:47 CEST] <alexpigment> 144p will look terrible even on a native 144p display
[00:04:50 CEST] <bf_> furq: There is also a bitrate in nginx-rtmp config:      hls_variant _low BANDWIDTH=160000;             hls_variant _mid BANDWIDTH=320000;             hls_variant _hi  BANDWIDTH=640000;
[00:04:51 CEST] <alexpigment> because it's youtube
[00:04:51 CEST] <thebombzen> 360p on a modern phone that isn't nonplussed
[00:05:00 CEST] <furq> bf_: that's just advisory
[00:05:09 CEST] <furq> it's up to you to match that up with your ffmpeg command
[00:05:17 CEST] <thebombzen> bf_: yea, I'd recommend testing out 1M bitrate for 720p video first
[00:05:21 CEST] <bf_> furq: but it is sent in the m3u8 playlist, I think the clients will change resolution based on it?
[00:05:25 CEST] <furq> they will
[00:05:32 CEST] <thebombzen> the best way is to just look at it and see
[00:05:34 CEST] <bf_> okay thank you guys, much appreciated
[00:05:36 CEST] <thebombzen> is 1M tolerable?
[00:05:39 CEST] <thebombzen> welll you can tell that
[00:05:46 CEST] <thebombzen> but I can tell you that 128k will look atrocious
[00:06:08 CEST] <furq> try 480p at 640+128 and 720p at 1280+128
[00:06:15 CEST] <furq> those should look ok-ish even with -preset fast
[00:06:28 CEST] <furq> also that way you only need to encode the audio once
[00:06:41 CEST] <bf_> furq: will ffmpeg do that optimization for me?
[00:06:49 CEST] <bf_> I mean if both video streams use same audio bitrate, will it encode only onceP?
[00:06:50 CEST] <alexpigment> if we're ranting about YouTube (and confusing bf_ with those unrelated rants), i can't understand how they chose to not have a 480p60 mode. the only way to get the correct temporal resolution is to upscale to 720p. SMH
[00:06:53 CEST] <furq> no
[00:07:00 CEST] <furq> you'd need to go through some indirection to get that
[00:07:06 CEST] <bf_> fml
[00:07:29 CEST] <furq> also yeah no 480p60 sucks
[00:08:08 CEST] <bf_> furq: so -b:v 512K = 720p?
[00:08:17 CEST] <furq> ?
[00:08:19 CEST] <alexpigment> youtube could have done the right thing and converted 480i streams to 480p60 by default, or at the very least, support 480p60 so users could deinterlace prior to uploading
[00:08:37 CEST] <alexpigment> 512K for 720p? that's no good
[00:08:55 CEST] <bf_> furq: wait.. I dont do anything with resolution in my whole ffmpeg command
[00:09:35 CEST] <furq> well yeah if you're not going to downscale then dropping the bitrate is a bit pointless
[00:09:54 CEST] <furq> it'll look much worse if you don't downscale the lower bitrate variant
[00:10:01 CEST] <bf_> I understand
[00:10:02 CEST] <thebombzen> bf_: here's an example of 128k 720p: http://0x0.st/v1t.png
[00:10:05 CEST] <thebombzen> notice how awful it looks
[00:10:10 CEST] <bf_> Weird because I got this technique from the tutorial by the maker of nginx-rtmp
[00:10:28 CEST] <bf_> thanks thebombzen
[00:10:49 CEST] <alexpigment> 720p should be at least 2mbps imho
[00:10:53 CEST] <alexpigment> if not 3mbps
[00:10:56 CEST] <thebombzen> compare to 720p at 1M for this: https://0x0.st/v1v.png
[00:10:58 CEST] <furq> depends on the content
[00:11:06 CEST] <thebombzen> at 1M it's not particularly great
[00:11:08 CEST] <alexpigment> furq: for non-static content
[00:11:10 CEST] <bf_> so best approach would be to downscale source resolution to 1080p and offer second resolution at 720p?
[00:11:11 CEST] <thebombzen> but it's at least vieable
[00:11:17 CEST] <furq> bbc iplayer's 720p streams are 1.5mbit and they usually look ok
[00:11:31 CEST] <furq> unless anyone gets on a boat
[00:11:37 CEST] <thebombzen> bf_: I would not recommend providing higher than 1080p source unless you think the clients will be able to support it
[00:11:46 CEST] <thebombzen> most people don't have >1080p monitors for example
[00:12:22 CEST] <bf_> I also think so. Was just orienting at twitch.tv
[00:12:28 CEST] <bf_> *on
[00:12:34 CEST] <bf_> sorry I'm tired, a lot of spelling mistakes
[00:12:56 CEST] <bf_> but 128k audio is also fine with hd?
[00:13:02 CEST] <thebombzen> usually
[00:13:21 CEST] <bf_> ok I will try to implement your suggestions, will come back tomorrow with a different set of problems
[00:13:24 CEST] <furq> 128k aac is good enough for any streaming stereo audio
[00:13:25 CEST] <thebombzen> it depends on what codec and what type of audio but for 97% of the things you're dealing with 128k is okay
[00:13:30 CEST] <furq> that's what youtube uses for 4k iirc
[00:13:34 CEST] <thebombzen> especially if you're streaming
[00:13:34 CEST] <furq> certainly for 1080p
[00:13:49 CEST] <thebombzen> 128k aac might not be transparent for heavy metal music but that's about it
[00:13:55 CEST] <alexpigment> as a person who is a bit of an audiophile, even i will admit that 128kbps is fairly transparent for AAC
[00:13:56 CEST] <thebombzen> but it's still okay
[00:14:01 CEST] <bf_> Ok
[00:14:04 CEST] <bf_> another audio question
[00:14:24 CEST] <alexpigment> like basically unless you have someone wailing on an open hi-hat in a song, 128kbps is fine
[00:14:33 CEST] <bf_> I want to build this thing where dozens of people speak at the same time, audio stream gets merged, people get placed within space using equalizer, and one audio stream is piped to viewers
[00:14:39 CEST] <furq> whaling
[00:14:55 CEST] <alexpigment> whaling? haha
[00:14:57 CEST] <bf_> is this a scenario where higher audio bitrate helps?
[00:15:09 CEST] <furq> i can't say i've ever done it
[00:15:15 CEST] <thebombzen> higher audio bitrate would help if you have more channels
[00:15:16 CEST] <furq> if you want more than two audio channels then yes
[00:15:23 CEST] <furq> but if you're downmixing to stereo it probably makes no difference
[00:15:24 CEST] <thebombzen> but if you're in stereo 128k is still fine
[00:15:31 CEST] <thebombzen> especially if it's people speaking
[00:15:36 CEST] <thebombzen> human speech is very easy to compress
[00:15:47 CEST] <bf_> like stadium atmosphere, people chanting, shouting
[00:16:01 CEST] <bf_> they get clustered by country
[00:16:04 CEST] <thebombzen> if you're downsampling to stereo, it'll be just as easy
[00:16:14 CEST] <thebombzen> I wouldn't recommend increasing the bitrate unless you're providing it as 5.1 or something
[00:16:19 CEST] <bf_> okay thank you very much
[00:16:27 CEST] <bf_> no it is all for desktop / laptop computers
[00:16:30 CEST] <bf_> no home entertainment
[00:16:52 CEST] <bf_> thanks again, I gotta go now. Ttyl
[00:17:11 CEST] <alexpigment> not to tangent too much, but i've never understood how bitrates are subdivided for 5.1 audio
[00:17:36 CEST] <alexpigment> for a 384kbps AC-3 5.1 stream, does each channel get an even 64kbps?
[00:17:46 CEST] <alexpigment> or is more bitrate allocated to the L and R channels?
[00:29:23 CEST] <sikilikis> so uh good news
[00:29:34 CEST] <sikilikis> using your help, the pi is actually able to output at 1080p and like 25 fps
[00:41:34 CEST] <mavi> Hi, I'm creating a site, and looking to perfect my encoding setting before encoding around 1000 video files or so. I'm curious if the built in AAC audio encoder for low 32kbps audio he-aac2 is better than fdk aac now
[00:41:46 CEST] <mavi> or is fdk-aac still the king for that sort of thing?
[00:42:39 CEST] <mavi> I read conflicting reports that in 2017 the built in encoder is now better or the same as fdk aac, just not sure if that is the case, or if that applies to the he-aacv2 encodes.
[00:43:03 CEST] <furq> mavi: the builtin encoder can't do he-aac
[00:43:09 CEST] <furq> which i assume you want for 32k
[00:43:32 CEST] <furq> fdk is probably better at lc-aac at any bitrate, but nobody's done a proper listening test yet
[00:43:36 CEST] <mavi> It can't? Interesting.
[00:43:51 CEST] <mavi> That solves my potential problem in seconds :)
[00:44:26 CEST] <mavi> Also for some reason running the command with vbr and fdk aac shows me this
[00:44:27 CEST] <mavi> [libfdk_aac @ 0x2d38b40] Note, the VBR setting is unsupported and only works with some parameter combinations
[00:45:22 CEST] <furq> you can probably ignore that
[00:45:46 CEST] <mavi> I've been using the nero aac codec, and today im trying this version out. I prefer the vbr modes. Is fdk aac better than nero aac which is fairly old now at low bitrates or are they more or less the same?
[00:45:52 CEST] <mavi> ah, alright will do.
[00:47:29 CEST] <mavi> i had read that the nero aac encoded based on a floating point, while fdk was limited to a fixed point when it came to the vbr, at the same bitrate. Does this mean that for my needs, nero aac is better? They said it was something regarding the license that limited fdk to using fixed point integer calculations.
[00:48:00 CEST] <mavi> Thanks for the help in advance. Been researching this stuff for a week, sorry for all the questions.
[00:57:14 CEST] <thebombzen> okay kepstin so I found out that my weird framerate file (25.93 or something weird) alternates between 24 and 30 depending on the scene
[00:57:18 CEST] <thebombzen> which is really really weird
[00:57:29 CEST] <thebombzen> and 120 is the LCM of 24 and 30, so it uses that
[00:57:38 CEST] <furq> can ffmpeg convert mov_text to srt
[00:57:40 CEST] <furq> and if not, what can
[00:59:04 CEST] <thebombzen> I'd think it could
[00:59:07 CEST] <thebombzen> why wouldn't it be able to
[00:59:20 CEST] <furq> i have a standalone mov_text file (ttxt) and i can't get anything to happen
[00:59:42 CEST] <thebombzen> uh?
[00:59:49 CEST] <thebombzen> how do you even specify standalone subtitle files
[00:59:59 CEST] <furq> i downloaded it from youtube
[01:01:08 CEST] <thebombzen> I'm not entirely sure how to demux standalone subtitles
[01:01:12 CEST] <thebombzen> at least with ffmpeg.c
[01:01:22 CEST] <thebombzen> but ffmpeg.c does have an mov_text decoder and a subrip encoder/muxer
[01:02:32 CEST] <furq> oh nvm youtube-dl will give me the subs in vtt
[01:02:36 CEST] <furq> this is probably easier
[01:02:51 CEST] <furq> yeah that works without any coercion
[01:04:15 CEST] <thebombzen> but why would I have a video that's sometimes 24 and sometimes 30
[01:04:21 CEST] <thebombzen> who would do that :P
[01:06:07 CEST] <TD-Linux> anime
[01:06:20 CEST] <furq> s
[01:06:57 CEST] <thebombzen> yea it is anime but I still find that weird
[01:07:04 CEST] <thebombzen> because that won't broadcast well on any monitor
[01:07:05 CEST] <JEEB> broadcast often has truly interlaced shit and then normal telecine
[01:07:16 CEST] <furq> well that worked but now i have an srt with 113-character lines
[01:07:17 CEST] <furq> thanks youtube
[01:07:22 CEST] <JEEB> and then you deint the interlaced shit and IVTC the rest of it
[01:07:26 CEST] <TD-Linux> thebombzen, looks just fine on my 480i crt
[01:07:39 CEST] <JEEB> and you are left with VFR
[01:07:40 CEST] <thebombzen> but sometimes 24 and sometimes 30 won't work on any monitor <120 Hz
[01:07:45 CEST] <furq> TD-Linux: i bet you can't play hi-ten bomberman on that though
[01:08:16 CEST] <thebombzen> but sometimes 24 and sometimes 30 is just weird :P
[01:08:24 CEST] <TD-Linux> furq, can't do any 31khz arcade boards
[01:08:29 CEST] <thebombzen> I'm not sure why that makes any sense
[01:08:31 CEST] <furq> that wasn't an arcade board
[01:08:37 CEST] <furq> i don't think it exists in a playable form though
[01:08:38 CEST] <thebombzen> and it sounds like that violates NTSC standards, doesn't it?
[01:08:42 CEST] <furq> it was some hacked up pc engine
[01:09:12 CEST] <furq> apparently it's two pc engines with a custom video output
[01:09:16 CEST] <TD-Linux> sounds like an arcade board to me
[01:09:33 CEST] <furq> well you played it with pc engine controllers
[01:09:34 CEST] <TD-Linux> thebombzen, the content you found was originally ntsc interlaced
[01:09:53 CEST] <furq> it is technically custom hardware though so i guess it's 50/50
[01:10:04 CEST] <TD-Linux> the person who made your file used ivtc for the 24fps parts and deinterlacing for the 30fps parts
[01:10:42 CEST] <furq> http://vignette2.wikia.nocookie.net/bomberman/images/1/1c/HiTenBombermangameplay.JPG/revision/latest?cb=20140103042315
[01:10:55 CEST] <TD-Linux> very nice
[01:11:13 CEST] <TD-Linux> considered a HD crt but most have framebuffers
[01:12:06 CEST] <TD-Linux> bvm-d20 is one exception
[01:14:29 CEST] <mavi> Anyone know whether NERO AAC at 32kbps vbr is better than the fdk aac at 32kbps HE-AAC v2?
[01:15:22 CEST] <furq> no idea
[01:15:29 CEST] <furq> you'd have to test it yourself
[01:15:42 CEST] <furq> i doubt it's worth the extra trouble though
[01:16:47 CEST] <mavi> i actually have. With fdk aac checking via mediainfo, it says the rate is constant even though i picked VBR 1, while nero shows and classifies it as variable bit rate
[01:17:04 CEST] <mavi> they are sound wise similiar, just wondering if there is anyone that's done more experimentation on it.
[01:17:55 CEST] <mavi> may just stick with nero as media info recognized that it's actually a variable bitrate, unlike FDKAAC where it doesnt
[02:26:42 CEST] <Kirito> If I have a raw (uncompressed) video file encoded at 120fps, what is the best way to encode it at half speed at 60fps, without resulting in any dropped frames? Would I use the same PTS trick done when re-encoding an existing x264 stream, or should I use another method since this is an uncompressed stream, not lossy?
[02:28:17 CEST] <Kirito> I mean since it's uncompressed, wouldn't it just be a matter of altering the framerate it's encoded at (and running the audio through a filter)? As far as I'm aware uncompressed videos don't have reference frames or anything of that nature
[02:29:46 CEST] <DHE> depends. true raw RGB or YUV to file has no framerate and you have to specify one on the command-line
[02:30:00 CEST] <DHE> but if it's in some kind of container (AVI, MKV, etc) then the container will carry the framerate
[02:30:15 CEST] <DHE> still, you can override that framerate as you would for true raw video which may be the easiest way to do it
[02:32:52 CEST] <kepstin> Kirito: with an uncompressed video, you can either just use the -r input option to override the framerate - or you can use the setpts filter, since "re-encoding" an uncompressed video is a no-op anyways
[02:35:48 CEST] <Kirito> ahh, overriding it with -r did just what I wanted, thanks
[04:45:48 CEST] <thebombzen> I have a video that's partially 30 fps and partially 24 fps, and I want to re-encode it as CFR
[04:46:05 CEST] <thebombzen> (and I don't want to re-encode it as 120 fps)
[04:46:31 CEST] <thebombzen> would you remmend using -r 30 and having judder for the 24 fps, using -r 24 and having judder for the 30 fps, or some form of -vf framerate=30 or -vf framerate=24?
[04:46:38 CEST] <thebombzen> (which interpolates)
[04:47:11 CEST] <thebombzen> I want it to be CFR because many containers (like mp4) don't support vfr
[04:47:46 CEST] <thebombzen> so if I use ffmpeg -i input.mkv output.mp4 it'll automatically force 120 fps, which is the tbr
[05:01:15 CEST] <furq> i recommend the recycling bin
[05:13:34 CEST] <thebombzen> furq: what
[05:13:59 CEST] <thebombzen> you recommend that I open up my graphical DE file browser and hit the delete key on my keyboard
[05:14:03 CEST] <thebombzen> what is that supposed to mean
[05:14:42 CEST] <furq> i don't know how to respond to that
[05:18:00 CEST] <thebombzen> well perhaps with a real answer to my original question
[05:18:32 CEST] <thebombzen> if I have a VFR video that's sometimes 24 and sometimes 30 what's the best way to force it to cfr (that isn't just dup frames so it's 120 fps because 120 fps is kinda dumb)
[05:19:58 CEST] <thebombzen> also apparently cuvid doesn't support chroma formats other than 420
[05:44:20 CEST] <alexpigment> thebombzen: what about re-encoding it as 30i?
[05:44:32 CEST] <kepstin> thebombzen: you have to watch the video and determine whether the judder in the 30p or 24p sections would be worse
[05:44:36 CEST] <thebombzen> are you actually suggesting that I make progressive video interlaced
[05:44:38 CEST] <kepstin> thebombzen: there's no single answer
[05:44:49 CEST] <thebombzen> kepstin: but would you recommend adding judder or interpolation
[05:44:52 CEST] <alexpigment> thebombzen: yeah, because that's likely what it was originally
[05:44:57 CEST] <thebombzen> it definitely wasn't
[05:45:12 CEST] <alexpigment> in which case, the 30p sections would be doubled, and the 24p sections would be telecined
[05:45:14 CEST] <kepstin> interpolation is probably worse, but it depends on the video
[05:45:18 CEST] <kepstin> try both?
[05:45:31 CEST] <alexpigment> it definitely wasn't? how was it originally broadcast?
[05:47:25 CEST] <thebombzen> well if it was originally interlaced I could tell
[05:47:32 CEST] <alexpigment> how so?
[05:47:54 CEST] <thebombzen> highmotion interlaced content looks terrible
[05:48:15 CEST] <alexpigment> yeah, but 30i to 24p when the source is 24p doesn't suffer from any sort of artifacts
[05:48:36 CEST] <alexpigment> likewise, 30i to 30p when the original 30p doesn't suffer from any artifacts
[05:49:13 CEST] <alexpigment> i deal with a lot of 30i material - pretty sure i'm 100% correct on these assertions
[05:50:30 CEST] <alexpigment> aside from all this, the real question is which part of the video is 30p? the credits? the opening scene? or is it interspersed somewhere in the middle?
[05:52:02 CEST] <alexpigment> welcome back i guess, thebombzen ;)
[05:52:12 CEST] <alexpigment> did you miss anything i wrote above?
[05:53:45 CEST] <thebombzen_> Yea and I'm on mobile. I'll check the backlog in an hour
[05:54:31 CEST] <thebombzen_> Short answer: It's anime but notripped from the broadcast but the bluray release
[05:55:12 CEST] <thebombzen_> it's animed in progressive and interlaced for the ntsc DVB but not bluray
[05:55:14 CEST] <thebombzen_> bbl
[06:45:03 CEST] <thebombzen_> alright I am back
[07:00:04 CEST] <thebombzen> alexpigment: it's interspersed in the middle
[07:00:17 CEST] <thebombzen> it's animated so they animated the highmotion content at 30 fps
[07:00:26 CEST] <thebombzen> but left most of it at 24
[07:18:02 CEST] <thebombzen> out of curiosity
[07:18:56 CEST] <thebombzen> so if you upscale yuv420p to yuv420p10le before encoding as H.264 or HEVC, you'll have a better compression ratio
[07:19:00 CEST] <thebombzen> i.e. quality-to-bitrate
[07:19:21 CEST] <thebombzen> but is the same true about upscaling yuv420p to yuv420p12le?
[07:19:33 CEST] <thebombzen> or does the 50% extra data finally become a toll?
[10:34:45 CEST] <DemoniacMilk> good morning
[10:35:21 CEST] <DemoniacMilk> i got a question regarding the config script
[10:35:47 CEST] <DemoniacMilk> i am trying to cross compile ffmpeg for an ARM based system
[10:36:18 CEST] <DemoniacMilk> ./configure --enable-cross-compile --cc=~/ti/linuxSDK/linux-devkit/sysroots/x86_64-arago-linux/usr/bin/arm/arm-linux-gnueabihf-gcc --arch=arm --target-os=linux
[10:36:57 CEST] <DemoniacMilk> so im telling the configure script to cross compile, for linux, arm architecture, using a cross compiler
[10:38:10 CEST] <DemoniacMilk> but this results in
[10:38:11 CEST] <DemoniacMilk> ~/ti/linuxSDK/linux-devkit/sysroots/x86_64-arago-linux/usr/bin/arm/arm-linux-gnueabihf-gcc is unable to create an executable file. C compiler test failed.
[10:38:44 CEST] <DemoniacMilk> i can build executables using the cross compiler (and succesfully run them on the target system)
[10:39:19 CEST] <DemoniacMilk> so I am wondering how the config script checks if executables may be built by a compiler
[10:39:30 CEST] <DemoniacMilk> and why it might fail
[11:48:50 CEST] <DemoniacMilk_> Hey, can anyone help me find an ffmpeg cross compiling issue?
[11:49:57 CEST] <DemoniacMilk_> I am trying to compile ffmpeg for an arm based system but end up getting an error "C compiler test failed".
[11:50:25 CEST] <DemoniacMilk_> a google search provides plenty of results but I wasnt able to find a solution in those yet
[11:55:01 CEST] <DemoniacMilk_> ah the config.log gav some additional info
[11:55:13 CEST] <DemoniacMilk_> as in : /tmp/ffconf.GNCumJGc.c:1:0: error: bad value (armv7) for -march= switch
[11:55:55 CEST] <DemoniacMilk_> so i guess the CPU identifier is incorrect. Any idea how i may find out the correct identifier for the CPU on my target? (target running linux)
[12:14:46 CEST] <Tom_B> is it possible to specify a sequence of decoders? E.g. try decoding with h264_cuvid but if that fails, use native instead? The problem I have is that not all streams will be h264, so setting -c:v before -i only works in some cases. I can do this myself by launching a second ffmpeg process if the first fails, but this causes an extra delay in actually playing the video. Can this be done with ffmpeg?
[12:25:39 CEST] <dystopia_> you should set -c:v after -i
[12:25:57 CEST] <dystopia_> how can it copy video codec if you haven't specified an input
[12:30:59 CEST] <DHE> Decoders? While you may be able to force a decoder, most people let autodetection do its magic
[12:33:21 CEST] <Tom_B> I can't rely on autodetection, because I want to use -deint from h264_decode when it's available
[12:33:41 CEST] <Tom_B> The problem is, -deint  does not get applied unless the input codec is specified
[12:35:04 CEST] <Tom_B> I'm using the example from here: https://trac.ffmpeg.org/wiki/HWAccelIntro#CUDACUVIDNvDecode for hardware encode/decode but I want to add deinterlacing. As encode doesn't support filters it works with -hwaccel cuvid  -c:v h264_cuvid -deint adaptive -i INPUT
[12:35:38 CEST] <Tom_B> but removing -c:v h264_cuvid, -deint is no longer set and I can't get deinterlaced output
[12:35:56 CEST] <mavi> Is this the most up to date CLI input for ffmpeg, or is there a more standard version that would do the same thing. IT works fine as it is.
[12:36:12 CEST] <mavi> $command = 'ffmpeg -i '.$folder.$fileName.' -c:v libx264 -preset veryslow -crf 30 -refs 8 -bf 6 -c:a libfdk_aac -afterburner 1 -signaling implicit -profile:a aac_he_v2 -vbr 1  -movflags +faststart -f mp4  '.$videoFolder.$output.'';
[13:08:23 CEST] <bf_> Good morning everyone
[13:08:26 CEST] <DemoniacMilk_> hello
[13:09:00 CEST] <bf_> I have had trouble compiling libfdk_aac and am using native aac from ffmpeg. Is this okayish or some sort of 10x performance penalty?
[13:21:10 CEST] <acamargo> documentation says fdk is performant than native aac but don't show any number
[13:24:01 CEST] <DemoniacMilk_> hm i cant get the config to run succesfully, it seems like the parameter for --cpu=foo gets passed to both -mtune and -march ?
[13:24:44 CEST] <DemoniacMilk_> adding --cpu=armv7-a to the config execution results in error: bad value (armv7-a) for -march= switch
[13:25:09 CEST] <DemoniacMilk_> while --cpu=arm results in error: bad value (arm) for -mtune= switch
[13:52:20 CEST] <mavi> fdk vs native is more or less the same as of 2017, the only difference is for low bitrate under 92kbps where fdk is superior.
[13:57:33 CEST] <SouLShocK> using the subtitles filter, is it possible to make the background "box" have different sizes when there are two lines of text? i.e. the first line says "Ok." and the second line says "So what do you want?" and I want the background to only be as big as the word "Ok" in the first line and as big as "So what do you want?" in the second line
[14:02:38 CEST] <c_14> background box?
[14:03:04 CEST] <SouLShocK> yeah. the black opaque background
[14:03:43 CEST] <mavi> For ffmpeg, what makes for the best resizer, I want to aim for 480p videos. Keeping same aspect ratio as the original file. Trying to figure out how to do this on ffmpeg
[14:03:50 CEST] <c_14> SouLShocK: what subtitle format are you using as input?
[14:04:33 CEST] <c_14> mavi: are you asking about what scaling algorithm to use?
[14:04:37 CEST] <SouLShocK> c_14: VTT
[14:04:43 CEST] <SouLShocK> webvtt i mean
[14:05:02 CEST] <c_14> SouLShocK: there shouldn't be a box
[14:05:03 CEST] <mavi> Yes I'm trying to figure out which and how.
[14:05:41 CEST] <c_14> unless the subtitle file specifies something I guess (though I've never seen that, at least with vtt)
[14:05:42 CEST] <mavi> I think lancoz3 is best. But not sure. I'm downsizing from 720p, it's for film not anime. Fairly low bitrate 300kbps.
[14:06:23 CEST] <mavi> im currently using the ffmpeg -s command but it's not what i need since it sets it by width. And not sure if it's the best for my application.
[14:07:15 CEST] <SouLShocK> c_14: I want the box to be there. and I got it working, but both lines have the same length. this is my current commandline https://pastebin.com/q5sYQjSU
[14:07:17 CEST] <c_14> lanczos is probably fine, I'd pick that or bicubic
[14:08:29 CEST] <mavi> would it end up looking like this for what i want?
[14:08:29 CEST] <mavi>  -vf scale=-1:480:flags=lanczos
[14:11:14 CEST] <c_14> mavi: if you have yuv420p use -2, but yes
[14:11:52 CEST] <c_14> SouLShocK: try setting different values for BorderStyle
[14:11:58 CEST] <c_14> 1-3 maybe
[14:12:22 CEST] <mavi> I don't use yuv, my source files are just HQ 720p youtube mp4's more or elss.
[14:12:37 CEST] <c_14> that's probably yuv420p
[14:12:42 CEST] <mavi> interesting
[14:12:43 CEST] <c_14> It's the pixel format
[14:12:46 CEST] <mavi> how can i tell?
[14:12:51 CEST] <c_14> check with ffprobe
[14:13:23 CEST] <mavi> crap it says YUV color space
[14:13:44 CEST] <mavi> if i use -1 will it negatively affect picture quality?
[14:14:23 CEST] <c_14> mavi: no, but yuv420p needs an even width/height. using -2 is the same as -1 except it guarantees the height to be divisible by 2
[14:14:39 CEST] <mavi> perfect
[14:14:55 CEST] <mavi> would -16 mean that it needs to be divided by 16pixels/
[14:15:11 CEST] <c_14> yes
[14:15:27 CEST] <mavi> easy enough, thanks for the advice. Wouldn';t have figured it out otherwise.
[14:15:44 CEST] <c_14> SouLShocK: or convert the vtt to ass and edit with aegisub until it looks like you want it to
[14:16:18 CEST] <mavi> Do I put the -vf tag before the -c:v libx264 tag or after it? Or does placement not really matter?
[14:16:36 CEST] <c_14> doesn't matter as long as it's after the input files and before the output
[14:23:03 CEST] <SouLShocK> c_14: I'm creating a commandline I can reuse for many encodings, this would be used in our transcoding setup for many hours of video every day
[14:23:09 CEST] <mavi> Thanks for all the help c_14.
[14:23:13 CEST] <SouLShocK> so using aegisub each time would not be feasible
[14:25:05 CEST] <Tom_B> can ffmpeg generate the relevant #EXT-X-DISCONTINUITY  in HLS? It generates one at the start but not when the aspect ratio of the video changes
[15:03:16 CEST] <robswain[m]> can ffmpeg be used for creating MPEG DASH manifests from a set of H.264/AAC in MP4 input files?
[15:03:37 CEST] <robswain[m]> it looks like it can for webm but i don't see anything about mp4
[15:04:14 CEST] <c_14> there is a dash muxer
[15:04:16 CEST] <c_14> so prabably
[15:04:48 CEST] <robswain[m]> hmmm
[15:05:47 CEST] <c_14> *probably
[15:05:47 CEST] <JEEB> yes, MPEG-DASH can be created
[15:06:03 CEST] <JEEB> -f dash or more likely just by the extension (".mpd") for the manifest
[15:07:01 CEST] <robswain[m]> i found this: http://stackoverflow.com/questions/40046444/how-should-i-use-the-dash-not-webm-dash-manifest-format-in-ffmpeg
[15:07:24 CEST] <robswain[m]> seems to be targeted at live whereas i'm looking into a VOD-type case
[15:07:30 CEST] <robswain[m]> i.e. offline encoding
[15:09:49 CEST] <robswain[m]> hmmmmm
[15:10:07 CEST] <robswain[m]> not entirely clear how to handle multiple representations there either
[15:10:52 CEST] <JEEB> well the thing either writes a live or VOD manifest I think
[15:10:59 CEST] <JEEB> so that much should be a-OK
[15:11:29 CEST] <JEEB> also I think multiple profiles are just done with multiple video/audio tracks, not sure if additional info is needed with multiple same bit rate audio tracks with different languages
[15:27:54 CEST] <DemoniacMilk_> quick question: when cross compiling, is there a way to set the path to the stripper etc?
[15:28:31 CEST] <bencoh> you must specify a toolchain prefix
[15:28:44 CEST] <DemoniacMilk_> --cross-prefix i think?
[15:29:44 CEST] <bencoh> yeah
[15:29:57 CEST] <bencoh> don't forget --enable-cross-compile as well
[15:30:13 CEST] <DemoniacMilk_> if my toolchain is named /a/b/cdef-gcc (and cdef-strip ...)
[15:30:23 CEST] <bencoh> prefix is /a/b/cdef-
[15:30:25 CEST] <DemoniacMilk_> i just add --cross-prefix=/a/b/cdef-
[15:30:25 CEST] <DemoniacMilk_> ye
[15:30:29 CEST] <DemoniacMilk_> okay i think i did that
[15:30:57 CEST] <DemoniacMilk_> oh but i used ~ instead of the absolute path to my home directory
[15:31:03 CEST] <DemoniacMilk_> ill try again, thanks
[16:10:16 CEST] <psprint_> Hello. I'm using following to do volume-up, however it seems to re-encode h264 stream, correct? How to copy the stream instead? ffmpeg -i 1st.mov -af "volume=1.5" 1st_volup.mov
[16:10:57 CEST] <kepstin> psprint_: if you want to copy the video stream, you can add "-c:v copy"
[16:11:10 CEST] <kepstin> psprint_: since you're filtering the audio stream, the audio has to be re-encoded
[16:19:35 CEST] <psprint_> yes with audio it's fine. I've used a phone bluetooth "handset" as microphone for Mac. How can I enhance the voice? I thought about some noise filter, and some filter that will sharpen the vowels etc.  which filters to use?
[16:57:27 CEST] <kepstin> psprint_: hmm, ffmpeg doesn't really have great filters for doing that sort of thing. you might consider extracting the audio to a wav, working on it in audacity or something, then muxing the result back int the file
[17:13:48 CEST] <psprint_> kepstin: maybe I'll succeed, -af volume=10dB worked nice, now the low frequencies, but '-af afftfilt="1-clip((b/nb)*b,0,1)"' doesn't work, documentation doesn't state where to put the afftfilt. Any clues?
[17:14:24 CEST] <kepstin> psprint_: if you're using multiple filters, you put them all in a single string after -af, separated by commas
[17:15:17 CEST] <psprint_> hmm, the message is "No such filter: '0'", after: ffmpeg -i 1st.mov -af afftfilt="1-clip((b/nb)*b,0,1)" -c:v copy 1st_afftfilt.mov
[17:16:39 CEST] <kepstin> psprint_: you need to escape the commas inside the expression, try this: -af afftfilt='1-clip((b/nb)*b\,0\,1)'
[17:17:13 CEST] <kepstin> (note that I switched from double to single quotes too)
[17:17:24 CEST] <psprint_> yeah now it works, thanks
[17:17:46 CEST] <Tom_B> is there any way to get h264_vaapi to preserve aspect ratio changes? When I use it it will use the aspect ratio of the first frame but when the aspect ratio changes in the input, it will apply the original aspect ratio for the input. Content that changes from 4:3 to 16:9 will be 4:3 entirely in the output
[17:19:01 CEST] <psprint_> kepstin: hyh the example produced silence
[17:42:02 CEST] <bf_> Is 30fps for livestream okay, or should it be less?
[17:42:29 CEST] <alexpigment> 30fps seems good
[17:42:49 CEST] <alexpigment> 60fps would be ideal, but that's far from standard (yet)
[17:42:57 CEST] <alexpigment> 30fps is what most livestreams are
[17:42:59 CEST] <bf_> 60fps screencast over the internet?
[17:43:24 CEST] <bf_> so I have this little thing running now: https://strivewire.com/stream with your help from yesterday :)
[17:43:54 CEST] <bf_> frame=11605 fps= 30 q=24.0 q=24.0 size=   38097kB time=00:06:27.75 bitrate= 804.9kbits/s speed=
[17:44:09 CEST] <alexpigment> nice, it looks very good
[17:44:20 CEST] <bf_> thank you
[17:44:41 CEST] <bf_> using -preset:v fast -s hd720   -c:v libx264 -b:v 640K and -s hd1080 -b:v 1280K
[17:45:08 CEST] <alexpigment> yeah, 640k is perfectly fine for a stream like this (where the screen is mostly static)
[17:45:27 CEST] <alexpigment> however, things will certainly get blocky if the screen changes a lot
[17:45:29 CEST] <bf_> ok I understand. So I should play some video game or play a youtube video
[17:45:41 CEST] <alexpigment> yeah, you could try that
[17:46:11 CEST] <alexpigment> i have a feeling it's going to start turning bad really quickly :) but it'll be good for you to figure out what the ideal bitrate is
[17:46:12 CEST] <bf_> let see %)
[17:46:48 CEST] <bf_> Ok it looks a bit like puke
[17:47:37 CEST] <alexpigment> not as bad as i was expecting, tbh, but i think it's because the input framerate is lower than 30fps on that video
[17:47:50 CEST] <alexpigment> or the stream itself is dropping FPS
[17:48:15 CEST] <bf_> so ffmpeg tells met my stream is 29 fps with 870kbit
[17:48:21 CEST] <bf_> speed = 0.97X
[17:48:37 CEST] <Tom_B> hmm, no matter what x264 codec I use (vaapi, nvenc, libx264) when I convert a .ts to .mp4 it doesn't preserve the aspect ratio change from 16:9 - 4:3, is there any way to keep this during the conversion?
[17:49:02 CEST] <alexpigment> bf_ you know, it might be worth changing your preset to "veryfast"
[17:49:13 CEST] <alexpigment> just to make sure you don't drop frames when the input gets a little complex
[17:49:33 CEST] <bf_> how can I check framedrop over time? I don't always control the input
[17:49:59 CEST] <bf_> I also only use preset:v not preset:a - is that something I should adD?
[17:50:12 CEST] <alexpigment> nah, preset:v is the h.264 preset
[17:50:22 CEST] <alexpigment> which changes what parameters are used to encode the video
[17:50:30 CEST] <alexpigment> but audio doesn't usually have such presets
[17:50:54 CEST] <kepstin> Tom_B: I doing think there's any way to signal an aspect ratio switch in the middle of an mp4 file, you might be out of luck there.
[17:51:18 CEST] <kepstin> Tom_B: most container formats just stick the aspect ratio or sar in a global header in the file :/
[17:51:28 CEST] <alexpigment> Tom_B what source even switches aspect ratio midstream?
[17:51:39 CEST] <alexpigment> seems like an odd thing to do and a recipe for failure :)
[17:51:48 CEST] <Tom_B> I'm really just trying to convert to HLS but thought mp4 would be a simpler trial
[17:51:48 CEST] <kepstin> mpeg-ts and mpeg-ps can, I think
[17:51:57 CEST] <JEEB> I've seen broadcast switch between them just fine
[17:51:59 CEST] <Tom_B> mpeg-ts from a dvb broadcast
[17:52:03 CEST] <JEEB> 4:3 content and 16:9 content f.ex.
[17:52:07 CEST] <JEEB> and I wouldn't limit it to DVB
[17:52:21 CEST] <alexpigment> ah
[17:52:22 CEST] <JEEB> broadcast in general can and you can always find people doing it from any side of the world :P
[17:52:47 CEST] <bf_> %)
[17:52:50 CEST] <alexpigment> US cable companies or OTA broadcasts don't do it, so i'm not familiar with it
[17:53:08 CEST] <alexpigment> bf_ if you click on the gear icon on that person's stream and check "Video stats", what is their framerate?
[17:53:26 CEST] <alexpigment> it's hard to tell how smooth your stream is because their stream might be choppy
[17:53:27 CEST] <kepstin> most ATSC broadcasts around here, they upscale/re-encode everything into a continuous 1080i60 stream :/
[17:53:37 CEST] <Tom_B> perhaps I could enforce 16:9 and write black bars to the frame
[17:53:40 CEST] <alexpigment> yep, that's my experience too kepstin
[17:53:59 CEST] <alexpigment> Tom_B that would be my choice
[17:54:02 CEST] <bf_> alexpigment: it is 60fps
[17:54:02 CEST] <bf_> wow
[17:54:06 CEST] <alexpigment> hmm
[17:54:10 CEST] <bf_> I thought like 30 would be ok for everyone
[17:54:17 CEST] <alexpigment> bf_ are they dropping frames?
[17:54:29 CEST] <bf_> skipped frames: 15k
[17:54:33 CEST] <alexpigment> oh ok ;)
[17:54:34 CEST] <alexpigment> well
[17:54:35 CEST] <alexpigment> there's that
[17:54:46 CEST] <bf_> who drops frames? my pc because of performance?
[17:54:49 CEST] <alexpigment> might want to find a better streamer to benchmark your own stream
[17:55:03 CEST] <alexpigment> i want to say that skipped frames are on the broadcaster's side
[17:55:23 CEST] <bf_> so he captures with 60fps but is only able to pipe out less than that via his upstream?
[17:55:53 CEST] <alexpigment> bf_ nm, i'm seeing some conflicting info onlnie
[17:55:54 CEST] <alexpigment> *online
[17:56:15 CEST] <bf_> %)
[17:56:24 CEST] <bf_> now I see why people use gigabits of bandwith
[17:56:38 CEST] <bf_> If i need to pipe 2mbps to each viewer it is a shitload of traffic
[17:56:43 CEST] <Tom_B> for my underlying issue though, it seems to be vaapi, converting from mpegts -> h264 in a ts container, the aspect ratio change works only if I encode using libx264, using h264_vaapi, it doesn't :(
[17:57:42 CEST] <alexpigment> bf_ yeah it's going to be a lot of traffic for sure
[17:57:56 CEST] <alexpigment> bf_ it might be worth stopping your stream, then checking the twitch stream again
[17:58:03 CEST] <alexpigment> to see if it's still skipping a lot of frames
[17:58:35 CEST] <kepstin> Tom_B: in general, x264 is a lot more capable and less buggy than hardware encoders :/
[17:58:48 CEST] <alexpigment> assuming it goes away, then there's a performance problem - which is very likely given how resource-intensive encoding is
[17:59:11 CEST] <bf_> alexpigment: it still skips around 5 frames per second
[17:59:20 CEST] <bf_> i stopped both streaming and viewing my own stream
[17:59:24 CEST] <alexpigment> bf_ are you on chrome?
[17:59:29 CEST] <bf_> yes chromium arch
[17:59:51 CEST] <alexpigment> check the advanced settings in chromium to see if hardware acceleration is enabled
[17:59:52 CEST] <bf_> 1920x1080 stream with 60fs, 2633kps
[17:59:58 CEST] <alexpigment> i'd toggle it either way, just to see
[18:00:07 CEST] <Tom_B> keepstin, unfortunately it's also incredibly slow in comparison. Is there a way to enforce an aspect ratio without setting a specific resolution?
[18:00:17 CEST] <bf_> alexpigment: it is checked
[18:00:25 CEST] <alexpigment> try unchecking it, just to see what happens
[18:00:33 CEST] <alexpigment> you may have to restart the browser. not sure
[18:01:57 CEST] <kepstin> Tom_B: it would be kind of tricky, I don't think the expressions in e.g. the pad filter get re-evaluated each frame, so doing it in filters might not work.
[18:02:24 CEST] <bf_> alexpigment: skipping even more frames
[18:02:28 CEST] <bf_> like 40 per 2 secs
[18:02:31 CEST] <alexpigment> yeah i figured so ;)
[18:02:36 CEST] <alexpigment> what GPU do you have?
[18:02:43 CEST] <alexpigment> and have you updated the graphics in a while?
[18:02:46 CEST] <bf_> nvidia but it is misconfigured
[18:02:48 CEST] <alexpigment> the drivers, i mean
[18:02:54 CEST] <bf_> no i dont touch them with a ten foot pole
[18:02:57 CEST] <bf_> im on linux man :D
[18:02:57 CEST] <alexpigment> ah
[18:03:01 CEST] <alexpigment> yeah i hear you
[18:03:02 CEST] <bf_> never change a running system
[18:03:06 CEST] <alexpigment> true
[18:03:16 CEST] <bf_> %)
[18:03:25 CEST] <alexpigment> what nvidia card in particular?
[18:03:47 CEST] <kepstin> Tom_B: actually, the pad and scale filters can be set to re-evaluate expressions each frame, so it is doable
[18:04:09 CEST] <Tom_B> makes sense, I'll upscale to 1080p and see if it's fast enough. I've tried -aspect 16:9 -s 1920x1080 but it just stretches the 4:3 segment of the video
[18:04:39 CEST] <kepstin> Tom_B: yeah, you need to use the scale and pad filters with expressions that calculate the needed scaling and padding based on the frame size and aspect ratio.
[18:04:56 CEST] <Tom_B> are there any examples of doing something similar anywhere?
[18:05:47 CEST] <bf_> alexpigment:  GK107GLM [Quadro K2000M]
[18:06:09 CEST] <kepstin> Tom_B: start by reading the examples for the scale and pad filters in the ffmpeg-filters doc...
[18:06:47 CEST] <alexpigment> bf_ ok that's a Kepler-era chip, but i'm not intimately familiar with the differences in Quadro vs GeForce when it comes to video acceleration
[18:06:55 CEST] <kepstin> Tom_B: I don't think there's anything there that specifically matches what you're doing, but there should be enough for a start
[18:07:02 CEST] <alexpigment> at any rate, you may just want to simply drop the stream playback from Source to High Quality
[18:07:13 CEST] <bf_> alexpigment: its my old thinkpad w530
[18:07:16 CEST] <bf_> yeah you're right i moved it up
[18:07:18 CEST] <alexpigment> that should probably get you at zero / near-zero dropped frames
[18:07:37 CEST] <bf_> yes not it is only 1 per 2 sec
[18:07:44 CEST] <psprint_> has anyone tested filter for noise reduction (audio) ?
[18:07:49 CEST] <alexpigment> Source is the only way to get 60fps, so I assume you were on Source
[18:07:54 CEST] <bf_> yes %)
[18:07:58 CEST] <bf_> alexpigment: are you also in gaming?
[18:08:00 CEST] <alexpigment> did you recheck hardware acceleration?
[18:08:10 CEST] <bf_> yes but not restart browser, it is still sw
[18:08:18 CEST] <alexpigment> not really, although i do enjoy a few speedrunner's streams of retro games
[18:08:24 CEST] <bf_> oh cool
[18:08:39 CEST] <alexpigment> bf_ ok, so high quality setting + hardware acceleration probably will have no dropped frames
[18:09:40 CEST] <bf_> I hope so :)
[18:09:57 CEST] <DHE> alexpigment: there's no significant difference between quadro and geforce encoders except if you get into the really highend stuff. in that case the limit of 2 encoder instances is removed (no limit).
[18:10:25 CEST] <bf_> I'm really not sure if my current driver setup is that advanced :)
[18:11:22 CEST] <alexpigment> DHE: we were talking about hardware accelerated in decoding, but i assume what you say is probably true still
[18:11:39 CEST] <alexpigment> *hardware accelerated decoding in web browsers, i mean
[18:12:05 CEST] <DHE> oh...
[18:12:20 CEST] <DHE> but still, the cards are mostly identical. it's like comparing a core i7 vs a Xeon
[18:12:25 CEST] <bf_> alexpigment: I asked yesterday already, but as we're talking about encoders:
[18:12:41 CEST] <bf_> I see high cpu usage: http://i.imgur.com/qiRYdDD.png but only convert rtmp to 720p and 1080
[18:12:44 CEST] <alexpigment> yeah, i just didn't want to speak from authority, but i assume Kepler is Kepler, or more specifically, GK107 is GK107
[18:12:51 CEST] <bf_> would putting a good graphics card into the server help?
[18:13:24 CEST] <alexpigment> only if you're going to switch to NVENC
[18:13:35 CEST] <alexpigment> which is a separate encoder from x264
[18:13:54 CEST] <alexpigment> admittedly, for real time streaming, nvenc is not a bad solution, even if the quality isn't as good at a given bitrate
[18:14:18 CEST] <DHE> without looking at the spec sheets, kepler is going to be able to do 100fps at 1080p without trouble I think
[18:14:25 CEST] <alexpigment> so if it's easier to up your stream birate by a mbit or two than it is to deal with this much CPU load, NVENC is not bad i guess
[18:14:37 CEST] <bf_> alexpigment: what kind of improvement are we talking? because this is an 8 core server and I was expecting it to be able to handle 10 streams at the same time. now there is only one
[18:14:56 CEST] <bf_> the higher the bitrate, the lower cpu?
[18:15:10 CEST] <alexpigment> DHE: theoretical, of course:) the browser layer really screws up those figures. still though, i've watched twitch at 60fps before without dropping frames on a kepler chip
[18:16:01 CEST] <alexpigment> bf_ bitrate has little to do with it. encoding is just resource-intensive. handling 10 streams at 720p is going to be basically impossible on consumer-grade hardware
[18:16:06 CEST] <DHE> not really. it's mainly a matter of encoder settings. preset ultrafast can probably handle that at 720p or 1080p on that machine, but the image quality will be poor overall to the point that nvenc is better suited
[18:16:52 CEST] <DHE> all other things being equal, double bitrate may increase CPU usage by some small factor, probably less than 10%. most of the effort is in the motion estimation
[18:17:02 CEST] <alexpigment> well, he's using veryfast right now, so comparing ultrafast to NVENC isn't really relevant (at the moment)
[18:17:15 CEST] <DHE> okay then
[18:17:34 CEST] <alexpigment> but yeah, i don't imagine ultrafast would change the CPU usage that much either
[18:17:52 CEST] <alexpigment> to really free up the CPU, you need to use hardware encoders
[18:17:53 CEST] <bf_> okay, so if I put 4 nvidia cards into such an server it could handle 10 streams? or even more?
[18:18:04 CEST] <alexpigment> bf_ i think you'd be able to handle 4 streams
[18:18:29 CEST] <bf_> is it the same gpu stuff people use for rendering / cuda / bitcoin mining?
[18:18:32 CEST] <alexpigment> i'm not 100% sure, but i was thinking that FFMPEG can't do more than one stream per card
[18:18:49 CEST] <alexpigment> no, NVENC is specifically an encoder chip on the system, rather than using cuda cores
[18:19:08 CEST] <alexpigment> you could thoeretically create a video encoder that uses the cuda cores, but no one does it to my knowledge
[18:19:10 CEST] <DHE> ffmpeg can do 2 per card. but unless you get the EXPENSIVE cards ($1,000 each or more) you're restricted by the nvidia driver to 2 encoders regardless.
[18:19:28 CEST] <bf_> such an interesting problem :)
[18:19:43 CEST] <alexpigment> ok, well i guess 2 it is :)
[18:19:44 CEST] <bf_> now I understand the market for encoding on demand, and all those other solutions
[18:19:55 CEST] <bf_> thanks for your clarifications, really much appreciated
[18:20:17 CEST] <DHE> I imagine with these expensive cards ffmpeg would have no limit (other than running out of card capacity and no longer doing realtime). not that I have any of these cards. :/
[18:20:49 CEST] <alexpigment> DHE is the 2-stream thing even true for the high end 1000 series cards?
[18:21:37 CEST] <bf_> Amazon offers "High-performance NVIDIA K80 GPUs, each with 2,496 parallel processing cores and 12GiB of GPU memory", would that work?
[18:22:03 CEST] <alexpigment> again, it really just comes down to the NVENC chip itself on the card
[18:22:16 CEST] <alexpigment> those parallel processing cores and extra memory are kinda irrelevant
[18:22:42 CEST] <bf_> I understand
[18:22:52 CEST] <alexpigment> i'm researching newer GeForce cards though to see if that restriction has been changed
[18:22:52 CEST] <bf_> I should probably go with nvidia then https://developer.nvidia.com/video-encode-decode-gpu-support-matrix
[18:24:16 CEST] <alexpigment> the K2000 chip you have can only do 2 streams, but apparently the K2200 of that same generation can do more than 2... (still researching)
[18:24:37 CEST] <bf_> but the k2000 is a consumer card, right?
[18:24:46 CEST] <alexpigment> Noooooo... :)
[18:24:54 CEST] <DHE> alexpigment: Only Quadro cards are unlocked. I don't know which exactly. I have a workstation quadro and it's locked
[18:25:08 CEST] <alexpigment> DHE: he has a quadro right now ;)
[18:25:23 CEST] <DHE> right. so do I. it's a tiny little workstation quadro and it's locked to 2.
[18:26:01 CEST] <bf_> so wowza claims that aws g2.2xlarge works with nvenc, but amazon doesn't specify the nvidia gpu on those
[18:26:09 CEST] <bf_> only says: Each GPU features an on-board hardware video encoder designed to support up to eight real-time HD video streams (720p at 30fps) or up to four real-time full HD video streams (1080p at 30fps)
[18:26:44 CEST] <bf_> you can choose 1 or 4 gpus (so 4 streams or 16 streams)
[18:26:59 CEST] <bf_> sounds like burning money
[18:27:22 CEST] <alexpigment> yeah, but if a 1050 can do it, for example, that wouldn't be too bad
[18:27:29 CEST] <alexpigment> <$500 USD
[18:27:39 CEST] <alexpigment> i'm just not finding any info on Pascal cards
[18:28:06 CEST] <DHE> bf_: those numbers are going to be based on the GPU chipset, not the speed or exact model. a kepler is a kepler. the nvenc chip is unchanged
[18:28:21 CEST] <DHE> but from those numbers you could look up if it's maxwell, pascal or kepler
[18:30:01 CEST] <bf_> so the amazon one i mentioned seems to be the GK104 Kepler
[18:31:48 CEST] <alexpigment> http://developer.download.nvidia.com/designworks/video-codec-sdk/secure/7.1/01/NVENC_DA-06209-001_v08.pdf?autho=1490805311_6774f3a663d71771f0edffcdaed33a1d&file=NVENC_DA-06209-001_v08.pdf
[18:32:07 CEST] <alexpigment> check out "3. NVENC LICENSING POLICY" starting at the bottom of page 7
[18:32:15 CEST] <pzy> I am excited to play with the new NDI/SpeedHQ stuff in ffmpeg, anyone worked much with those?
[18:32:27 CEST] <alexpigment> it says that it limits to do for all Geforce and for "low end Quadro"
[18:32:57 CEST] <bf_> wow so it is only limited by their eula?
[18:33:28 CEST] <alexpigment> not sure. it's either that, or they just put it in that section
[18:33:40 CEST] <alexpigment> but the list of cards which support more is hard to find on the page they reference
[18:35:26 CEST] <alexpigment> there's apparently a Quadro GP100 which 3 NVENC encoders on it
[18:35:50 CEST] <alexpigment> and given that it's a high end quadro, that 2-stream limit probably isn't applicable
[18:36:00 CEST] <alexpigment> i would be scared to know how much that costs :)
[18:36:33 CEST] <bf_> ok ars says > 6k
[18:36:39 CEST] <bf_> thank you very much alexpigment
[18:36:52 CEST] <alexpigment> there's the Quadro P4000 as well, which has 2 NVENC encoders
[18:36:56 CEST] <alexpigment> probably costs a lot less
[18:37:03 CEST] <alexpigment> https://developer.nvidia.com/video-encode-decode-gpu-support-matrix#Encoder
[18:37:50 CEST] <bf_> I think I'll go with the aws instance first
[18:38:17 CEST] <alexpigment> k4000
[18:38:18 CEST] <alexpigment> er
[18:38:25 CEST] <alexpigment> is that the one you're referring to?
[18:38:39 CEST] <alexpigment> or are you talking about amazon web services?
[18:39:06 CEST] <bf_> sorry i am talking about aws
[18:39:08 CEST] <bf_> g2.2xlarge: 15 GiB Arbeitsspeicher, NVIDIA GRID GPU (Kepler GK104),
[18:39:22 CEST] <alexpigment> ahh
[18:39:39 CEST] <bf_> oh wait it only has one nvdec chip
[18:40:16 CEST] <alexpigment> it should have 4
[18:40:34 CEST] <alexpigment> it's 1 nvenc / chip
[18:40:38 CEST] <alexpigment> and there are 4 chips, right?
[18:41:11 CEST] <bf_> no it only has once gpu, gk104 kepler and based on nvidia matrix it only has 1 nvenc chip : https://developer.nvidia.com/video-encode-decode-gpu-support-matrix
[18:41:28 CEST] <bf_> but there is also one with 8x or 16x kepler gk210
[18:41:58 CEST] <bf_> which have 2 nvenc chips per gpu
[18:42:19 CEST] <bf_> alexpigment: sorry it is all a bit confusing :)
[18:42:19 CEST] <alexpigment> ok, but look at the "# of Chips" column
[18:42:30 CEST] <alexpigment> no worries. i agree that it's very confusing
[18:42:41 CEST] <alexpigment> the GRID cards all have multiple chips
[18:42:55 CEST] <alexpigment> and then the next column is "# of NVENC / CHIP"
[18:43:00 CEST] <bf_> so you think it is a grid card?
[18:43:06 CEST] <bf_> I assumed they'd pick the lowest config %)
[18:43:10 CEST] <alexpigment> i thought you said it was a grid card ;)
[18:43:16 CEST] <bf_> oh yes, sorry
[18:43:19 CEST] <bf_> stupid me
[18:43:23 CEST] <alexpigment> no worries ;)
[18:43:42 CEST] <bf_> so they indeed have 2 nvenc chips
[18:43:45 CEST] <jkqxz> How much encode (or transcode?) capability do you actually need here?  In general, NVENC is unlikely to be a sane solution in terms of cost or power for video unless you also need the graphics hardware for something else.
[18:45:27 CEST] <alexpigment> jkqxz he was talking about 10 simultaneous streams, so nvenc seems like a more realistic way to go
[18:45:44 CEST] <jkqxz> (Comparing against "just buy more CPUs and use libx264 veryfast", or even quicksync if you can tolerate Intel horribleness.)
[18:46:30 CEST] <jkqxz> At what resolution/framerate?
[18:47:03 CEST] <alexpigment> 720p30 at the moment, right bf_?
[18:47:36 CEST] <bf_> so both 720p and 1080p for each incoming stream
[18:48:22 CEST] <bf_> and I wanted to run more than one stream per server, I find it a bit uneconomic to spin up an instance for a streamer
[18:49:00 CEST] <bf_> I'm just learning my way around ffmpeg and video streaming, so most of these questions are most likely very amateurish, just want to figure out a solution which lets me sleep at night
[18:49:29 CEST] <bf_> jkqxz: with 30fs, yes alexpigment
[18:49:36 CEST] <jkqxz> Um.  Any normal Intel desktop chip can do that much in quicksync.
[18:49:55 CEST] <jkqxz> Probably needs a decent server CPU to do it in software, but certainly not a huge one.
[18:50:08 CEST] <alexpigment> jkqxz: have you had much experience with this?
[18:50:20 CEST] <bf_> for 10x 720p+1080p rtmp to hls in parallel?
[18:50:58 CEST] <bf_> jkqxz: i was a bit shocked after my htop told me http://i.imgur.com/qiRYdDD.png  with one stream running
[18:51:15 CEST] <jkqxz> bf_:  Yes.  That's around the expected throughput, though, so you might not manage 10 if you're doing other stuff.
[18:51:47 CEST] <alexpigment> here's an excerpt of something i read earlier online:"Looking at the ffmpeg quick sync code, it tries to check QuickSync busy status, and if it is busy, then it sleeps for a very short period (e.g., 1000 microseconds), then tries again. When I run 15 ffmpeg instances simultaneously, they are spending a lot of time in that sleep/retry loop."
[18:52:11 CEST] <alexpigment> which implies to me that, sure, you can do a bunch of streams at once, but they're all waiting most of the time
[18:53:05 CEST] <jkqxz> Yes, the people who made libmfx don't understand how to design APIs.  This is unfortunate, but not really a problem.
[18:53:30 CEST] <bf_> so I should try to get rid of ffmpeg asap?
[18:53:46 CEST] <alexpigment> well, i don't have any first-hand experience with concurrent quicksync encodes, so i'll defer to jkqxz's experience in this
[18:53:47 CEST] <bf_> twitch.tv rolled their own golang thing
[18:54:14 CEST] <jkqxz> I don't understand what your image is trying to show.
[18:54:15 CEST] <bf_> jkqxz: the server with the htop screenshot is only doing the rtmp->hls with nginx-rtmp
[18:54:25 CEST] <alexpigment> bf_ not sure if this is related to what you're asking, but FFMPEG supports quicksync
[18:55:34 CEST] <bf_> ok so there are two hardware approaches to encoding, nvenc by nvidia and quicksync by intel. In your experience jkqxz, is quicksync preferable to nvenc?
[18:55:47 CEST] <iive> bf_: 10x 720p+1080p could probably be done with nvenc on a single professional card.
[18:56:14 CEST] <Cheech> how onw would transport alpha channel in MPEGTS compatible codec?
[18:56:38 CEST] <iive> consumers cards are limited to 2 steams by the driver, or so I've heard.
[18:56:40 CEST] <jkqxz> I have done little with NVENC beyond some minor testing and finding that it is very crippled on all sensibly-priced cards.
[18:56:51 CEST] <bf_> iive: that's what i will try with aws's smallest g2.* instance
[18:57:12 CEST] <bf_> I will try to use something out of aws preferably because our other setup is in there already
[18:57:46 CEST] <iive> still, one professional card would cost less than 10 PC's
[18:57:55 CEST] <kerio> is h264 somehow not supported in mpegts?
[18:58:08 CEST] <kerio> i tried streaming a video over udp without transcoding, and i couldn't get it to work
[18:58:08 CEST] <DHE> no, h264 in mpegts is quite normal
[18:58:18 CEST] <kerio> does it require some special stuff
[18:58:20 CEST] <DHE> kerio: make sure you set the pkt_size=1316 in yoru UDP output
[18:58:39 CEST] <kerio> how do i do that
[18:58:47 CEST] <kerio> is it an option to udp, or to mpegts
[18:58:48 CEST] <DHE> "-pkt_size 1316" or "udp://1.2.3.4:5678?pkt_size=1316"
[18:58:52 CEST] <iive> kerio: Annex B (bsf) , so that you have reatpeated headers
[18:59:02 CEST] <iive> repeated
[18:59:20 CEST] <DHE> usually mpegts will complain if it doesn't get annex b content
[18:59:23 CEST] <kerio> oh ;o
[18:59:47 CEST] <iive> also, make sure nothing reorders the udp packets
[19:00:06 CEST] <DHE> also set -g to a sane value. huge numbers will prevent playback. maybe 100? at 30fps you may experience startup delays up to ~4 seconds
[19:00:17 CEST] <bf_> thanks again alexpigment DHE jkqxz for your kind help
[19:00:42 CEST] <kerio> wait, this isn't h264 at all
[19:00:44 CEST] <kerio> this is mpeg4
[19:01:38 CEST] <kerio> i'm getting "[ffmpeg/demuxer] mpegts: PES packet size mismatch" in mpv
[19:05:21 CEST] <alexpigment> bf_ np. i learned a lot from the conversation, so thanks for bringing it up.
[19:05:44 CEST] <bf_> :)
[19:05:53 CEST] <bf_> me too
[19:28:54 CEST] <Tom_B> I'm trying to force all the content to 16:9 by padding black bars, but when the aspect ratio changes during play, it doesn't seem like the scale filter sees the change. I have if(lt(a,16/9) but `a` seems to have a fixed value, rather than applying to the current frame
[19:29:47 CEST] <alexpigment> Tom_B: is this a one-time job, or an ongoing problem you'll have to deal with?
[19:30:27 CEST] <alexpigment> if it's a one-time job, it might be worth just cutting the stream at the aspect ratio change and then treating each part separately
[19:30:33 CEST] <alexpigment> then re-combine them later
[19:30:34 CEST] <Tom_B> Ongoing, I'm converting dvb streams to HLS so the content will change frequently
[19:30:40 CEST] <alexpigment> ah
[19:30:42 CEST] <alexpigment> :(
[19:34:35 CEST] <Tom_B> unfortunately the iw/ih variables also seem to be set once rather than apply to each frame. Obviously good for performance but not helpful when the aspect ratio changes during the video
[19:44:09 CEST] <kepstin> Tom_B: you need to set the option 'eval=frame' on the pad filter
[19:44:19 CEST] <kepstin> otherwise it only checks once at the start of the stream
[19:45:02 CEST] <kepstin> (if your pad filter doesn't support that, you need a newer ffmpeg)
[19:46:34 CEST] <kepstin> actually, that looks like a *really* recent addition, might need to build from git
[19:47:04 CEST] <kepstin> or wait for ffmpeg 3.3 release, which is probably gonna be soon :)
[19:47:06 CEST] <Tom_B> is this correct? pad=width=1920:height=1080:eval=frame assuming i had the latest git version
[19:47:55 CEST] <kepstin> Tom_B: something like that yeah. In your stream, does only the aspect ratio switch, or also the resolution?
[19:48:09 CEST] <kepstin> you'll probably need more complicated expressions, but that's a start :)
[19:48:57 CEST] <Tom_B> It's actually only the aspect ratio but I'd probably need to handle resolution as well. I'm just trying to get a working example before tweaking it
[19:50:41 CEST] <pzy> according to the changelog, SpeedHQ support was added recently. anyone know if that includes SpeedHQ2? newtek sucks at documentation
[19:51:23 CEST] <pzy> Stream #0:0(eng): Video: none (SHQ2 / 0x32514853)
[19:53:04 CEST] <pzy> Codec ID                                 : V_MS/VFW/FOURCC / SHQ2
[19:58:11 CEST] <pzy> oh I see, it's slated for the next version
[20:27:33 CEST] <Tom_B> hmm, I can't get eval=frame to work. The problem is the scale rather than the pad. Pad works, but obviously if it's already been scaled to a resolution it won't make any difference. I'd expect  scale=iw*a:ih*a:eval=frame to at least give me some visible difference when the aspect ratio changes but it doesn't
[20:38:20 CEST] <Tom_B> This should give me either a 400x300 or 160x90 image in a 1000x1000 video: scale="'if(lt(a,16/9),400,160)':'if(lt(a,16/9),300,90)':eval=frame",pad=1000:1000:eval=frame but still the size is always the same
[21:02:37 CEST] <kepstin> Tom_B: huh. which size is it giving you? does it just match the initial state and not update, or is it always one or the other?
[21:03:58 CEST] <kepstin> I assume this is non-HD content? I'd expect HD content will always be 16:9, I don't think dvb supports 4:3 HD stuff?
[21:04:39 CEST] <kepstin> (and 576 line video ("PAL")?)
[21:07:02 CEST] <JEEB> broadcast supports HD 4:3 and 16:9 just fine
[21:07:57 CEST] <kepstin> my quick look at the DVB specs I can find say "MPEG-2 HDTV pictures have 16:9 or 2.21:1 aspect ratio; IRDs support 16:9 and optionally 2.21:1 aspect ratio." and "H.264/AVC HDTV pictures have 16:9 aspect ratio; IRDs support 16:9 aspect ratio."
[21:08:12 CEST] <kepstin> of course, I live in ATSC land where they pillarbox everything in a 1080i stream, so :/
[21:08:41 CEST] <JEEB> don't worry
[21:08:44 CEST] <JEEB> MMTP is coming
[21:08:49 CEST] <JEEB> and then all of us FFFUUU
[21:09:22 CEST] <kepstin> also from that same spec: "SDTV pictures may have either 4:3, 16:9 or 2.21:1 aspect ratio; IRDs support 4:3 and 16:9 and optionally 2.21:1 aspect ratio."
[21:09:38 CEST] <kepstin> so yeah, only SDTV content listed as supporting 4:3?
[21:09:54 CEST] <JEEB> ok
[21:10:01 CEST] <kepstin> hmm. admittedly, this doc is from 2009, it might have changed
[21:10:04 CEST] <kepstin> probably not tho
[21:15:12 CEST] <ChocolateArmpits> what does "t" do in expressions ?
[21:15:39 CEST] <jkqxz> Tom_B:  You sent #6276 for aspect ratio in VAAPI?  I think <http://sprunge.us/PLTC> kindof fixes it, if you don't mind waiting for the next GOP before it updates.  If you do, then it requires more code to detect the change and actually push the reconfiguration immediately (as libx264 does).
[21:15:49 CEST] <kepstin> ChocolateArmpits: depends on what's evaluating the expression, but in most places t or T means "the current pts value, converted to seconds"
[21:16:41 CEST] <ChocolateArmpits> kepstin, why it's not listed in utilities document ? neither in drawtext that can use it
[21:16:58 CEST] <ChocolateArmpits> ahhh
[21:16:59 CEST] <ChocolateArmpits> >timestamp expressed in seconds, NAN if the input timestamp is unknown
[21:17:01 CEST] <furq> it is listed in drawtext
[21:17:10 CEST] <kepstin> ChocolateArmpits: because the variables available depend on the filter, it's not generic in all expressions
[21:18:21 CEST] <mavi> Just curious is using an ultralight denoiser filter or x264's nr at 300 better?
[21:18:31 CEST] <mavi> The content is fairly clean, just want to increase compressibility.
[21:19:05 CEST] <furq> afaik nr is very fast but not very good
[21:37:37 CEST] <gwohl1> I want to use FFmpeg to process stereoscopic video sources into monoscopic by outputting only the left video, and not the right. Should I do this by using the stereo3d filter and only outputting the left video, or should I just crop out the left eye using the crop filter? Is there a substantial difference between how the stereo3d and crop filters work in this context?
[21:38:58 CEST] <ChocolateArmpits> mavi try hqdn3d, you can mix and match spatial and temporal filtering to your liking
[21:51:40 CEST] <alexpigment> gwhol1: is the source SBS or top/bottom?
[21:51:45 CEST] <alexpigment> or is it MVC?
[21:55:37 CEST] <gwohl1> alexpigment it is mostly top/bottom
[21:55:57 CEST] <alexpigment> is it full (1920x2160) or half (1920x1080)?
[21:56:21 CEST] <gwohl1> alexpigment I am working with 4096x4096
[21:56:39 CEST] <gwohl1> this is for VR headsets, not the traditional blu-ray 3D
[21:56:52 CEST] <alexpigment> oh gotcha
[21:57:05 CEST] <alexpigment> so the actual visible resolution is 4096x2048?
[21:58:33 CEST] <alexpigment> rather than confuse you with more questions, the question i'm trying to get at is if scaling is involved to get the correct aspect ratio once the top and bottom are separated. if so, it might be ideal to avoid cropping because you'll have to rescale as well
[22:06:12 CEST] <gwohl1> alexpigment I see, thanks for your help! Luckily we will not be doing any scaling until after the monoscopic video has been generated.
[22:06:37 CEST] <gwohl1> We receive 4096x4096 ProRes 422 sources directly from the content publishers
[22:06:59 CEST] <alexpigment> and that consists of 2 4096x2048 streams, one on top of the other, right?
[22:13:53 CEST] <durandal_1707> stereo3d is just easier to play with for ordinary user
[22:16:11 CEST] <gwohl1> alexpigment No, each stream is 2048x2048, on on top of the other. So the full resolution of the stereoscopic video is 4096x4096
[22:16:30 CEST] <alexpigment> gwohl1: that is extremely confusing to me, but ok
[22:21:38 CEST] <celyr> Hi
[22:22:05 CEST] <gwohl1> @alexpigment err, my bad. You're right. I meant to say that the videos are 4096x2048, one on top of the other.
[22:23:10 CEST] <alexpigment> k
[22:23:34 CEST] <alexpigment> well then it shouldn't matter which method you choose in ffmpeg
[22:28:31 CEST] <thebombzen> what is the purpose of pro-res
[22:28:53 CEST] <thebombzen> why the hell is lossy intra-only intermediary-production a good idea
[22:28:55 CEST] <JEEB> prores is what apple came up with after they thought they needed something like MJPEG
[22:29:11 CEST] <JEEB> also welcome to broadcast or enterprise
[22:29:18 CEST] <thebombzen> yea but prores is supposed to be like "an intermediary codec"
[22:29:21 CEST] <JEEB> it's either raw or it's lossy with effing heavy bit rate
[22:29:24 CEST] <thebombzen> which mjpeg is definitely not
[22:29:37 CEST] <thebombzen> but if you're going to do Lossy with Heavy Bitrate
[22:29:37 CEST] <alexpigment> MJPEG is intermediate if you throw enough bitrate at it
[22:29:40 CEST] <JEEB> they don't seem to know the case of lossless and packed
[22:29:50 CEST] <JEEB> although EU is standardizing FFV1
[22:29:54 CEST] <thebombzen> is it actually
[22:29:55 CEST] <thebombzen> wow
[22:30:01 CEST] <thebombzen> but if they're going to do Lossy with Heavy Bitrate
[22:30:03 CEST] <thebombzen> why Intra-only
[22:30:10 CEST] <thebombzen> that sounds like it sorta defeats the whole point of lossy
[22:30:12 CEST] <alexpigment> intra-only is good for NLEs
[22:30:12 CEST] <JEEB> because they need instant seeking
[22:30:28 CEST] <thebombzen> but like
[22:30:30 CEST] <thebombzen> why not just have like
[22:30:39 CEST] <thebombzen> a keyframe interval of 5 frames or something
[22:30:45 CEST] <thebombzen> and cache the GOPs
[22:30:53 CEST] <JEEB> anyways, you're hitting the goddamn questions that everyone asks about broadcasting and enterprise
[22:30:56 CEST] <kepstin> modern computers are fast enough that that's a reasonable option, yeah :/
[22:31:14 CEST] <thebombzen> so in other words, it just doesn't really make sense
[22:31:16 CEST] <alexpigment> it *is* nice to have a snappy intra only codec in an NLE though
[22:31:36 CEST] <alexpigment> even on fast computers, it makes a difference in the overall feel of the workflow
[22:31:37 CEST] <JEEB> yes, but at this point that GOP can be a couple of frames, I remember like seven years ago someone tested with AVC
[22:31:48 CEST] <kepstin> hey, on most videos encoded with x264 modes medium or faster, I can do backwards trick play by just holding down ',' in mpv :/
[22:31:53 CEST] <JEEB> and optimal GOP then was about 3 frames :P
[22:32:00 CEST] <thebombzen> but you could mimic that "snappiness" with a 5-frame GOP
[22:32:06 CEST] <thebombzen> just IPPPP
[22:32:23 CEST] <thebombzen> and when you seek, you cache the GOP so framestepping doesn't require you to decode it every time
[22:32:42 CEST] <thebombzen> modern computers are fast enough that this is viable
[22:32:47 CEST] <alexpigment> thebombzen: i think the other thing to consider is that the industry that intermediate codecs are designed for don't care about fine tuned optimizations. they have the storage space
[22:32:52 CEST] <llogan> broadcast is the best. especially when you get to fight with insane stream anal-yzers.
[22:33:03 CEST] <kepstin> the reduction of IO needed to load UHD frames is probably enough to make it feel snappier like that than a big intra-only frame :/
[22:33:04 CEST] <JEEB> llogan: lol
[22:33:21 CEST] <JEEB> "please up your bit rate because our expensive machine says you're not supposedly using it enough"
[22:33:24 CEST] <pzy> where's ATSC 3.0 llogan?! :P
[22:33:24 CEST] <JEEB> "..."
[22:33:33 CEST] <thebombzen> lol JEEB
[22:33:33 CEST] <thebombzen> this
[22:33:35 CEST] <JEEB> or other technicalities that aren't illegal anywhere
[22:33:43 CEST] <llogan> PMT interval was over 40 ms
[22:33:48 CEST] <thebombzen> like when Bluray H.264 complains that you're not using 50 Mbps for your lowmotion video
[22:33:49 CEST] <JEEB> :D
[22:33:56 CEST] <alexpigment> is llogan the one keeping us from ATSC 3.0?
[22:34:00 CEST] <thebombzen> alexpigment: but you have to consider the storage bottleneck
[22:34:05 CEST] <pzy> yes alex
[22:34:09 CEST] <thebombzen> compression actually can improve speed
[22:34:11 CEST] <alexpigment> damn you llogan ;)
[22:34:15 CEST] <thebombzen> this is why Linux Initcpios are compressed
[22:34:22 CEST] <JEEB> thebombzen: please. you're preaching to the pan
[22:34:28 CEST] <thebombzen> ah okay
[22:34:36 CEST] <alexpigment> thebombzen: perhaps, but people are often dealing with RAIDed PCI-E SSDs
[22:35:02 CEST] <thebombzen> you can't say "they have massive amounts of storage" and then say "it's on an SSD"
[22:35:08 CEST] <alexpigment> i just did
[22:35:10 CEST] <thebombzen> massive storage is done via cheap HDDs
[22:35:15 CEST] <thebombzen> that's how you get massive amounts of storage space
[22:35:21 CEST] <thebombzen> cause HDDs are cheap and big
[22:35:22 CEST] <JEEB> well whatever the storage is, usually something crazy expensive and large
[22:35:31 CEST] <pzy> I guess NAB this year will have lots of ATSC 3.0 stuff
[22:35:31 CEST] <JEEB> and maybe fast
[22:35:36 CEST] <alexpigment> like i said, the people who deal with UHD lossless and intermediate files regularly have the money do have massive amounts of storage on *RAIDED* SSDs
[22:35:37 CEST] <JEEB> pzy: MMTP
[22:35:37 CEST] <kepstin> yeah, they spend a ridiculous amount on large fast ssds in raid just to workaround the fact they're using raw video or giant intra codecs
[22:36:00 CEST] <llogan> $3500 USD for an analyzer. that's just for the "core". $4000 more for the additional options, "stream, transport, quality".
[22:36:04 CEST] <alexpigment> yes, and the budget is there, so they give zero shits about optimizing it
[22:36:04 CEST] <pzy> neat JEEB
[22:36:13 CEST] <thebombzen> but seriously what advantage does rawvideo have over something like huffyuv or ffvhuff
[22:36:13 CEST] <JEEB> no it is not
[22:36:15 CEST] <thebombzen> or even just png
[22:36:19 CEST] <thebombzen> or Exr
[22:36:20 CEST] <thebombzen> or Tiff
[22:36:37 CEST] <JEEB> it's simple and the ENTERPRISE SOLUTIONS support it
[22:36:41 CEST] <JEEB> like, uh
[22:36:48 CEST] <alexpigment> well, i don't think many people work in actual raw these days to my knowledge, but i don't work for a major movie studio, so i could be wrong ;)
[22:36:49 CEST] <thebombzen> EXR is literally entroprise
[22:36:57 CEST] <JEEB> why the fuck are you still going on about this, I think you're seeing where we're going with this
[22:37:04 CEST] <thebombzen> mostly @alexpigment
[22:37:12 CEST] <thebombzen> alex is the only one not agreeing with me
[22:37:20 CEST] <thebombzen> because it appears the answer to "why do they do that it doesn't make sense" is "It just doesn't make any sense"
[22:37:20 CEST] <alexpigment> i'm not disagreeing with your point
[22:37:31 CEST] <alexpigment> you asked a question above that i gave you the answer to ;)
[22:37:42 CEST] <JEEB> no, he is. he is just saying that what they're doing to have it work
[22:38:02 CEST] <alexpigment> like do i agree that it could be optimized? OF COURSE
[22:38:10 CEST] <alexpigment> do the studios care? NO
[22:38:13 CEST] <JEEB> yup
[22:38:18 CEST] <JEEB> they have their solution and it works for them
[22:38:23 CEST] <furq> do i have a shift key? YES
[22:38:25 CEST] <alexpigment> they have a deeply-seeded solution
[22:38:32 CEST] <alexpigment> and they're willing to throw money at it
[22:38:56 CEST] <alexpigment> furq: you should get that key checked. the whole first part of your statement was de-emphasized
[22:40:31 CEST] <llogan> ...then they want you to buy their muxer for $7000.
[22:48:05 CEST] <SpeakerToMeat> Ok, sorry I tried searchign everywhere before comming to ask but I can't bloody find it... what was the way to get a list of all of an enconder's possible options?
[22:49:19 CEST] <alexpigment> ffmpeg -h encoder=[encoder name]
[22:49:31 CEST] <SpeakerToMeat> Thanks
[22:49:34 CEST] <kepstin> SpeakerToMeat: not in general, since there's a lot of "generic" options in the ffmpeg core that may or may not be used by a given codec
[22:49:34 CEST] <alexpigment> np
[22:49:56 CEST] <SpeakerToMeat> kepstin: Eh I want stuff like profiles supported and pix formats for an encoder
[22:50:03 CEST] <kepstin> that help thing only shows options which are specific to that encoder, but doesn't include the generic options
[22:50:24 CEST] <kepstin> if it has the info you want, then great. I know the pix_fmts are there :)
[22:50:43 CEST] <alexpigment> well, there's always ffmpeg -h full
[22:50:47 CEST] <alexpigment> but that's a bit overkill ;)
[22:51:12 CEST] <SpeakerToMeat> Aaaaand, I'm toast...
[22:51:42 CEST] <SpeakerToMeat> There's no dnxhd profile that supports 30fps.
[22:52:05 CEST] <alexpigment> i'd have to look at my notes, but you might be right
[22:52:18 CEST] <SpeakerToMeat> I maybe should do a constant frame count reinterpret to 30000/1001
[22:52:39 CEST] <kepstin> SpeakerToMeat: you could do 2:2 pulldown and store in i60 :/
[22:53:27 CEST] <SpeakerToMeat> kepstin: I don't see the 60 either, but 60000/1001
[22:53:33 CEST] <kepstin> hmm, you're right
[22:53:41 CEST] <kepstin> where did you get an exactly 30fps source anyways?
[22:53:55 CEST] <alexpigment> there are definitely 30fps DNxHD profiles in the spec
[22:53:57 CEST] <SpeakerToMeat> what was the option to reinterpret Xfps as Yfps with no frame blending? that is, constant frame count.... :/
[22:54:14 CEST] <SpeakerToMeat> kepstin: Cheap chinese GoPro copy.
[22:54:32 CEST] <kepstin> SpeakerToMeat: using '-r' as an output option, equivalently the 'fps' video filter
[22:54:33 CEST] <SpeakerToMeat> kepstin: I'm trying to massage it from H264 to something Resolve free will read
[22:54:45 CEST] <kepstin> oh, reinterpret
[22:54:54 CEST] <SpeakerToMeat> kepstin: that'd be -r 30000/1001 right?
[22:54:58 CEST] <kepstin> (i.e. slow down the video by 1/1.001)
[22:55:20 CEST] <kepstin> if you mean reinterpret, then use -r 30000/1001 as an input option (before the -i)
[22:55:21 CEST] <SpeakerToMeat> Yeah reinterpret, I want static frame count, not static duration
[22:55:30 CEST] <SpeakerToMeat> ok
[22:55:35 CEST] <SpeakerToMeat> Lets see
[22:56:29 CEST] <kepstin> nobody'll notice a speed change of that magnitude, it's probably a smaller difference than the inaccuracy on your camera in the first place :)
[22:56:41 CEST] <kepstin> although if you have audio you might have to resample it to match :/
[22:57:01 CEST] <SpeakerToMeat> Yuppers and it's better quality than trying to do a frame blending, etc
[22:57:36 CEST] <SpeakerToMeat> Eh I have external recorded audio from console, I'll sync and replace audio, and slow it down 0.1%
[22:57:52 CEST] <SpeakerToMeat> Ok it's not liking something... let's see
[22:58:23 CEST] <kepstin> heh, if you have audio recorded from a different source, you'd probably have to do some extra work to sync it up anyways
[22:58:40 CEST] <thebombzen> yea
[22:59:09 CEST] <thebombzen> also note you can recreate the timestamps with -vf setpts=N/TB/30
[22:59:37 CEST] <thebombzen> if you want to do it with a filter that is
[23:00:01 CEST] <SpeakerToMeat> I had to match one of the profiles bitrates as well this was crazy
[23:00:16 CEST] <SpeakerToMeat> thebombzen: That was the style I remembered
[23:00:27 CEST] <SpeakerToMeat> thebombzen: Would -r before -i be equivalent?
[23:00:53 CEST] <SpeakerToMeat> Aaaand DNxHD is 10 times bigger... sigh
[23:00:58 CEST] <kepstin> SpeakerToMeat: using -r before -i is a bit different, but the same basic effect here
[23:01:16 CEST] <thebombzen> in this case they'd do the same thing but in different ways
[23:01:18 CEST] <SpeakerToMeat> kepstin: Different how?
[23:01:37 CEST] <thebombzen> so using -r before -i tricks the demuxer into treating the input as CFR
[23:01:49 CEST] <thebombzen> using -vf setpts=N/TB/<framerate> is a filter
[23:01:59 CEST] <kepstin> SpeakerToMeat: the -r option changes the timestamps sort of in-between the demuxer and decoder stages, I think? it can work when stream-copying
[23:02:10 CEST] <SpeakerToMeat> Ok
[23:02:10 CEST] <thebombzen> using the filter it only works on decoded frames because libavfilter doesn't work on encoded frames
[23:02:11 CEST] <kepstin> while the filters only work when re-encoding, but are a lot more flexible
[23:02:25 CEST] <thebombzen> it's a bit like concat demuxer versus the concat filter
[23:02:38 CEST] <thebombzen> the concat filter is less applicable but more flexible
[23:02:59 CEST] <SpeakerToMeat> So basically -r before -i is telling the demuxer to discard the timing data and use a supplied constant framerate
[23:03:06 CEST] <kepstin> that reminds me, i really need to finish cleaning up my patch to make concat filter work with different framerate videos
[23:03:09 CEST] <kepstin> SpeakerToMeat: exactly.
[23:04:54 CEST] <thebombzen> SpeakerToMeat: yes
[23:05:20 CEST] <thebombzen> kepstin: would that just make the output VFR?
[23:05:30 CEST] <kepstin> thebombzen: yes
[23:05:45 CEST] <thebombzen> how would you deal with timestamps that don't start at zero
[23:05:48 CEST] <petecouture> I have ffmpeg running in node via a wrapper. The script takes a mp4 file located on S3 and transcodes it to an HLS output with multiple bitrates. With no changes to the code all of a sudden I'm getting this error while running. Encoder ERROR ffmpeg exited with code 1: Conversion failed!
[23:05:55 CEST] <petecouture> Should I recompile ffmpeg?
[23:06:11 CEST] <kepstin> thebombzen: the concat filter code already handles it, it just needs a fix to mark the output as vfr so it doesn't trigger some frame dropping code.
[23:06:19 CEST] <thebombzen> oh okay
[23:06:49 CEST] <thebombzen> so you already *can* do it, but it effectively just adds a -vf fps afterward
[23:07:29 CEST] <thebombzen> what happens if you try weird things like ffmpeg -ss 10 -copyts -i input1 -ss 5 -copyts -i input2 -lavfi concat=n=2?
[23:07:43 CEST] <thebombzen> does it just ignore the timestamps
[23:07:50 CEST] <kepstin> thebombzen: currently the output video will be the same "fps" as the first video, and  it will drop any frames which don't fit that
[23:08:07 CEST] <thebombzen> oh okay
[23:08:33 CEST] <kepstin> thebombzen: -copyts simply means that the frames entering the filterchain don't have any extra cleanups applied, so copyts doesn't really do anything special here...
[23:08:57 CEST] <thebombzen> yea but I mean how does the concat filter handle input that doesn't start at zero?
[23:09:03 CEST] <kepstin> (admittedly, one of the cleanups is setting the pts to start at 0, but you could do that with a setpts filter in the filter chain too)
[23:09:08 CEST] <thebombzen> or does the concat filter ignore the its offset?
[23:09:30 CEST] <kepstin> i'm not sure, but it seems to work ok - I imagine it does the equivalent of "setpts=PTS-STARTPTS" on each of its inputs
[23:09:56 CEST] <thebombzen> ah okay, it remaps to zero
[23:09:58 CEST] <petecouture> Opps ignore my last question, I did update the script and broke it.
[23:10:07 CEST] <thebombzen> petecouture: clearly
[23:10:13 CEST] <petecouture> lawlz
[23:10:20 CEST] <thebombzen> if you change the script and not ffmpeg and suddenly the script doesn't work
[23:10:33 CEST] <thebombzen> it's really not a surprise that you broke the script
[23:10:42 CEST] <thebombzen> and that ffmpeg didn't magically break and yet remain identical to how it had been
[23:11:39 CEST] <petecouture> https://imgur.com/gallery/uQoHgUV
[23:31:55 CEST] <thebombzen> why is planar rgb data in the format gbrp
[23:31:59 CEST] <thebombzen> like why GBR
[23:32:40 CEST] <thebombzen> I get that YUV is probably closest to GBR, but GBR seems really nonstandard for rgb data
[23:56:40 CEST] <petecouture> Running script installed on Centos. The program runs for about 60% of the way and then I get a 'killed' status and SIGKILL was thrown. The thing is same script occasionally works usually right after a reboot. I'm running it using loglevel 48 to see why it's being killed but nothing is shown only 'killed'. Is there a way to know why it's occurring? The same script runs fine locally on my macbook pro.
[23:57:15 CEST] <furq> oom killer?
[23:57:38 CEST] <petecouture> That's what I assumed but is there a way to know that's the case?
[23:57:43 CEST] <thebombzen> well SIGKILL is thrown by someone else
[23:57:52 CEST] <thebombzen> a process doesn't kill itself with SIGKILL
[23:58:04 CEST] <thebombzen> (I mean it technically could, but nobody does that)
[23:58:20 CEST] <thebombzen> so you should try to figure out if something else iskilling it
[23:58:32 CEST] <petecouture> This originally was in a node wrapper. which is where I got the SIGKILL notice. WHen I run it via the command line raw I just get 'killed'
[23:58:34 CEST] <thebombzen> perhaps it's some SELinux bullshit
[23:58:42 CEST] <thebombzen> well the command line says "Killed."
[23:58:50 CEST] <thebombzen> if it receives SIGKILL
[23:58:52 CEST] <thebombzen> so same thing
[23:59:14 CEST] <thebombzen> Centos might have some sort of failsafe to prevent runaway processes
[23:59:22 CEST] <petecouture> hmmm
[23:59:23 CEST] <thebombzen> perhaps some SeLinux thing
[23:59:43 CEST] <thebombzen> Centos is an Enterprise distro
[23:59:44 CEST] <furq> the oom killer will log somewhere
[23:59:57 CEST] <furq> either /var/log/messages, /var/log/syslog or /var/log/kern.log depending on distro
[00:00:00 CEST] --- Thu Mar 30 2017