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

[burek]

[00:30:45 CET] <alexpigment> spacerabbit: kodi
[00:30:59 CET] <alexpigment> oh nm, you mean transcoded on the fly
[00:31:36 CET] <alexpigment> why do you want to transcode?
[00:31:47 CET] <spacerabbit> to watch on cellphone
[00:31:52 CET] <alexpigment> ah
[00:32:42 CET] <alexpigment> maybe google plex alternatives 2017
[00:32:56 CET] <alexpigment> i don't transcode, so I don't have any experience
[00:33:23 CET] <spacerabbit> ideally something that works like a file browser rather than a media library but idk if that exists
[00:33:40 CET] <alexpigment> do you have iOS or android?
[00:33:45 CET] <spacerabbit> android
[00:33:54 CET] <alexpigment> well, that's already a start
[00:33:58 CET] <spacerabbit> i have that setup for my tv already
[00:34:23 CET] <spacerabbit> with satellite tuners on a pci card and gpu transcoded with the nvidia card
[00:34:25 CET] <alexpigment> so really the only problem you'd probably commonly face is audio codec support or perhaps something like mpeg-2 or xvid
[00:34:37 CET] <alexpigment> gotcha
[00:34:44 CET] <alexpigment> so you're dealing with mpeg-2 + ac3
[00:34:49 CET] <spacerabbit> i transcode the picture only
[00:34:55 CET] <spacerabbit> its mostly AVC
[00:35:03 CET] <spacerabbit> i copy the audio
[00:35:04 CET] <alexpigment> then what's the need to transcode?
[00:35:15 CET] <alexpigment> deinterlacing and making the bitrate smaller?
[00:35:41 CET] <spacerabbit> id like to have a setup where i can open video files and they are transcoded on the flu
[00:35:44 CET] <spacerabbit> fly
[00:35:49 CET] <spacerabbit> my setup only works with live tv atm
[00:36:02 CET] <alexpigment> right, i'm just making sure I understand since avc should be natively supported by your phone
[00:36:12 CET] <spacerabbit> i transcode to hevc
[00:36:19 CET] <spacerabbit> but i guess it doesnt matter much
[00:36:22 CET] <alexpigment> for bitrate reasons?
[00:36:26 CET] <spacerabbit> yeah
[00:36:34 CET] <alexpigment> hmmm
[00:36:37 CET] <spacerabbit> and its all hardware encode and decode
[00:36:39 CET] <spacerabbit> so low power
[00:36:54 CET] <alexpigment> have you tried *not* transcoding and leaving it avc to see if it works?
[00:36:59 CET] <spacerabbit> sure
[00:37:01 CET] <spacerabbit> it doesnt
[00:37:07 CET] <alexpigment> k
[00:37:08 CET] <spacerabbit> 5mbps upload max here
[00:37:16 CET] <alexpigment> ah, over internet
[00:37:22 CET] <spacerabbit> + worst case of LTE reception is like 2mbps
[00:37:26 CET] <spacerabbit> in some bad spots
[00:37:31 CET] <alexpigment> when you mentioned nas, I thought you were talking about in-network
[00:37:37 CET] <spacerabbit> even if it goes up to 100mbps in a good spot
[00:37:57 CET] <spacerabbit> ah in network i watch from 5ghz everything is smooth
[00:38:22 CET] <alexpigment> have you tried Media Browser?
[00:38:28 CET] <alexpigment> that appears to be a common plex alternative
[00:38:32 CET] <spacerabbit> never heard about it
[00:38:35 CET] <spacerabbit> lookingit up
[00:39:04 CET] <alexpigment> and Kodi has a plugin for it, if you're unable to get a native client working on your phone
[00:39:29 CET] <spacerabbit> https://github.com/MediaBrowser/Wiki/wiki/Transcoding "NVidia NVENC"
[00:39:30 CET] <spacerabbit> sounds good
[00:39:42 CET] <spacerabbit> i hope there's ways to fine tune the settings
[00:40:20 CET] <alexpigment> well, i can tell you that nvenc and fine tuning are kinda mutually exclusive, but maybe it's enough for you
[00:40:45 CET] <spacerabbit> well without the good settings it def look worse
[00:41:08 CET] <spacerabbit> and tbh the hevc looks quite good
[00:41:36 CET] <alexpigment> hevc via nvenc is generally on par with x264 from what I gather
[00:41:42 CET] <spacerabbit> all things considered
[00:41:44 CET] <spacerabbit> yeah
[00:41:50 CET] <alexpigment> but it's better than h264 on nvenc
[00:42:04 CET] <spacerabbit> a lot
[00:42:32 CET] <spacerabbit> especially considering it doesnt use ressources
[00:43:12 CET] <alexpigment> yeah, that's a big plus
[00:43:24 CET] <spacerabbit> on my tv setup i can switch to x265 its not a problem
[00:43:27 CET] <alexpigment> it would take a beefy system to encode x265 on the fly
[00:43:34 CET] <spacerabbit> theres a menu on the android app
[00:43:44 CET] <BtbN> A Ryzen 1800X can barely do 1080p60
[00:44:20 CET] <spacerabbit> well my 6600k maxed out can encode better 1080p than nvenc with x265
[00:44:25 CET] <spacerabbit> its a bit overkill though
[00:44:35 CET] <therage3> BtbN: seriously?
[00:44:40 CET] <therage3> i'd have expected more from those
[00:44:49 CET] <alexpigment> x265 is very complex
[00:44:52 CET] <BtbN> hm? That's super decent for a desktop CPU
[00:44:59 CET] <therage3> wait
[00:45:07 CET] <therage3> when you say "do 1080p60" what do you mean
[00:45:13 CET] <therage3> play it back or what
[00:45:18 CET] <alexpigment> encode on the fly
[00:45:19 CET] <BtbN> it does slightly over 60 fps with x265
[00:45:24 CET] <therage3> oh, ENCODE on the fly
[00:45:43 CET] <alexpigment> :)
[00:46:07 CET] <alexpigment> live transcoding in x265 is going to be done on the GPU for most people for the foreseeable future
[00:46:10 CET] <alexpigment> er
[00:46:13 CET] <alexpigment> H.265 rather
[00:46:54 CET] <BtbN> encoding h265 on a gpu is pointless
[00:46:58 CET] <spacerabbit> it make sense for me because i share that tv app on android with another family member
[00:47:04 CET] <BtbN> x264 is likely faster and results in better quality
[00:47:06 CET] <spacerabbit> so it doesnt tax my cpu when he use it
[00:47:15 CET] <alexpigment> BtbN: i agree for the most part, but he's wanting very low CPU usage
[00:47:30 CET] <spacerabbit> plus its real time
[00:47:31 CET] <BtbN> I'd still use a h264 hw encoder then
[00:47:37 CET] <spacerabbit> blah
[00:47:55 CET] <alexpigment> BtbN: read up above. he's trying to get really low bitrates for streaming over LTE
[00:47:57 CET] <BtbN> last time I tested nvenc, there was virtually no difference between the two
[00:48:17 CET] <BtbN> it did not yield smaller files or better quality
[00:48:19 CET] <alexpigment> so if low CPU and low bitrate are the key points, nvenc hevc is really the only option
[00:48:24 CET] <BtbN> it basically operates hevc at h264 feature levels
[00:48:36 CET] <BtbN> So there is no point in actually using it
[00:48:52 CET] <spacerabbit> well i have HW decoders for both my the receiver
[00:49:08 CET] <spacerabbit> so it doesnt make sense to tax a lot of cpu for the same results
[00:49:13 CET] <BtbN> Decoders are bit perfect anyway, there's no quality to be gained
[00:49:47 CET] <spacerabbit> anyway the choice of the codec doesnt matter much
[00:50:06 CET] <alexpigment> spacerabbit: anyway, hopefully mediabrowser / emby is what you're looking for
[00:50:07 CET] <spacerabbit> i need a system to encode files from a nas on the fly
[00:50:24 CET] <spacerabbit> yep sounds good from what im looking at
[00:50:26 CET] <BtbN> well, if you use h264, you get better compatibility. And with hw encoders, there isn't really anything to gain from using hevc.
[00:50:52 CET] <spacerabbit> well i stream to 2 mobiles that both have hevc
[00:51:05 CET] <spacerabbit> and there is an option to use h264 for other phones
[00:51:52 CET] <spacerabbit> so because it has the option to use hevc doesnt make it less compatible
[00:52:15 CET] <spacerabbit> i guess it should work the same with that other software
[00:53:46 CET] <alexpigment> BtbN: i actually can't tell anything meaningful on my macbook right now, but here's a link: http://forum.mediacoderhq.com/viewtopic.php?f=4&t=13184&start=10#top
[00:53:54 CET] <alexpigment> there are screenshots, for whatever it's worth
[00:54:37 CET] <therage3> i'm resisting the urge to do audiophile things
[00:54:53 CET] <alexpigment> clearly, x264 at slow speeds is better than hardware in general, but there's certainly a benefit in using hevc over h264 on nvenc
[00:55:17 CET] <alexpigment> therage3: like?
[00:55:52 CET] <therage3> someone told me about some obscure SoX dithering method to use when downscaling 24-bit audio files to Red Book compliant audio CD 16-bit files
[00:55:59 CET] <alexpigment> oh yeah
[00:56:01 CET] <therage3> sounds like a bit of a waste
[00:56:11 CET] <alexpigment> well, dithering has its merits
[00:56:26 CET] <alexpigment> but it's hard to tell if you'd notice
[00:56:58 CET] <therage3> my understanding is that it's used to randomize the quantization error noise you get from the downscaling process, which turns the noise into a more tolerable white noise thing
[00:57:16 CET] <therage3> but different kinds of dithering, different algorithms, produce different end results
[00:57:36 CET] <alexpigment> therage3: my 2 cents: do it from now on; don't waste your time redoing something you've already done
[00:58:13 CET] <alexpigment> or at least do a test on one or two tracka and see if you can notice a difference. if you can't, don't redo anything
[00:59:17 CET] <therage3> yeah, good call
[00:59:47 CET] <therage3> the specific context is that this FLAC came in 44.1kHz 24-bit format
[00:59:51 CET] <therage3> and i was like, uhhhhhh
[01:00:13 CET] <alexpigment> yeah, 24bit is really just used for having a lower noise floor and higher db ceiling
[01:00:23 CET] <alexpigment> it's useful for recording and editing
[01:00:33 CET] <alexpigment> but most people end up going to 16-bit at the end
[01:00:50 CET] <alexpigment> kinda like working in 10-bit with video even though you go down to 8-bit at the end
[01:02:36 CET] <therage3> yeah
[01:04:30 CET] <therage3> i was messing around a bit with it
[01:04:51 CET] <therage3> downscaled the bit depth, burned a CD with CD-Text and all
[01:04:56 CET] <therage3> seems to sound great
[01:09:15 CET] <therage3> is this sort of frequency spectrum normal for a file of these specs? https://i.imgur.com/lDsD8UG.jpg
[01:09:41 CET] <therage3> i mean, i know they go up to 22.05kHz because of the Nyquist theorem and the sampling rate they use
[01:09:51 CET] <therage3> but is it normal for it to be cut off sharply just there?
[01:10:01 CET] <therage3> often i see them just trail off softly close to the peak
[01:36:02 CET] <alexpigment> therage3: not really sure
[01:36:15 CET] <alexpigment> i know that during mastering they hard cut a lot of the low frequencies
[01:36:29 CET] <therage3> but the ones cut here are the _high_ ones..
[01:36:33 CET] <alexpigment> it seems likely they'd do the same for the highs, but i'm not an expert on the matter
[01:36:38 CET] <therage3> right
[01:36:49 CET] <therage3> (as in, right they may do that, not that you're not an expert lol)
[01:37:07 CET] <alexpigment> no worries - i knew what you meant :)
[01:37:29 CET] <alexpigment> i've done a lot of music recording in the past, but i was never a spectrum view person
[01:37:30 CET] <therage3> let's see if this audiophile channel knows
[01:37:35 CET] <alexpigment> ;)
[01:37:46 CET] <therage3> well lately i've been looking at some spectrum analysis tools with more care
[01:38:09 CET] <therage3> since there's a bunch of "320kbps" mp3's out there that have all frequencies above 15kHz hard cut off
[01:38:16 CET] <therage3> i'm like, "yeah, 320kbps my ass..."
[02:03:12 CET] <alexpigment> therage3: i think it depends on the encoder tbh, but yeah, mp3 is lossy at any bitrate
[02:03:31 CET] <alexpigment> and the big savings of an mp3 is simply cutting off frequencies "they" think you can't hear
[02:03:46 CET] <therage3> the encoder?
[02:04:03 CET] <therage3> but this is a FLAC file, it should be, theoretically, bit-for-bit identical to the source
[02:04:16 CET] <alexpigment> you were talking about 320kbps mp3 files
[02:04:47 CET] <alexpigment> i was just saying that I think the cutoff frequency for mp3s varies by encoder
[02:04:58 CET] <alexpigment> (to some degree, anyway)
[02:05:23 CET] <therage3> ohhh, you mean what I said _most recently_
[02:05:38 CET] <alexpigment> yeah, that's how i operate
[02:05:42 CET] <alexpigment> linearly in time ;)
[02:06:12 CET] <therage3> BRB a sec, then i'll answer
[02:12:44 CET] <therage3> alexpigment: ok back
[02:13:04 CET] <alexpigment> cool
[02:13:16 CET] <therage3> so yeah, it may depend on encoder and whatever, but a hard limit of 15kHz for a presumably 320kbps mp3 is... sketchy
[02:13:24 CET] <alexpigment> yeah i hear you
[02:13:30 CET] <therage3> now as for the other question
[02:13:36 CET] <therage3> the one with the FLAC
[02:14:10 CET] <therage3> in the audiophile channel they told me that the song was mastered in some manner such that frequencies higher than 22.05kHz existed on that master
[02:14:21 CET] <therage3> but the 44.1kHz downsampling clobbered them
[02:14:37 CET] <therage3> that's the origin of that wall at 22.05kHz
[02:14:58 CET] <alexpigment> ah, that rings a bell
[02:15:11 CET] <alexpigment> so 48k or 96k would have a broader range?
[02:15:54 CET] <therage3> that's the idea, i guess, 48kHz would go up to 24kHz in actual "audio" range (I write "audio" in quotes because anything above 20kHz is dubiously called audio...)
[02:17:20 CET] <alexpigment> yeah, i just found out recently that AAC audio has a feature that replaces certain high frequencies with white noise to increase encoding efficiency
[02:17:32 CET] <alexpigment> which seems wtf on paper but I guess in practice doesn't make too much difference
[02:17:33 CET] <therage3> oh fancy
[02:17:50 CET] <therage3> and i guess that white noise masquerades well as whatever it's replacing for the human ear¿
[02:17:52 CET] <therage3> ?*
[02:18:03 CET] <alexpigment> i would hope so
[02:18:17 CET] <alexpigment> i've never done a back to back comparison
[02:18:37 CET] <therage3> i can kind of see why it does that, 8-bit video game consoles had high-hat and crash cymbals that sounded like white noise
[02:18:41 CET] <therage3> so it makes sense in some manner
[02:29:12 CET] <alexpigment> well to be fair a) they sounded like shit, and b) they weren't replacing the cymbals in real recorded audio with fake crash cymbal sounds ;)
[02:29:55 CET] <alexpigment> in my head, it's equivalent to saying "ok, anything over 15khz, just turn into midi"
[02:30:10 CET] <alexpigment> replace with softsynth ;)
[02:30:42 CET] <alexpigment> but yeah, i can understand how they could be approximated as the same
[02:33:09 CET] <therage3> yeah
[02:35:27 CET] <alexpigment> anyway, i'm not enough of an audiophile to care about all this i guess
[02:36:04 CET] <alexpigment> like i think you'd notice a bigger difference in $600 speakers vs $100 speakers than you would in flac vs mp3
[02:36:14 CET] <alexpigment> even if you could tell the difference side-by-side
[02:36:46 CET] <alexpigment> the only time i really ever notice quality sucking is when i'm watching a music video on youtube or listening to satellite radio
[02:37:53 CET] <alexpigment> but given that you're ripping stuff from CD or whatever, sure, go FLC
[02:37:55 CET] <alexpigment> *FLAC
[02:38:03 CET] <alexpigment> because why the hell not :)
[02:38:51 CET] <klaxa> for archival FLAC, for listening opus is good enough nowadays
[02:38:57 CET] <alexpigment> there's a certain peace of mind to knowing something is lossless rather than worrying about if something is more or less lossless
[02:39:27 CET] <klaxa> one of the reasons for storing archives in lossless formats is because you can re-encode to new state-of-the-art lossy codecs without quality loss
[02:40:05 CET] <therage3> the thing with YouTube is the following
[02:40:35 CET] <therage3> a lot of times, the best video they have is paired with an audio stream that isn't the best they have on file for that video
[02:40:46 CET] <therage3> the best audio stream they have is often an audio-only container elsewhere
[02:41:04 CET] <therage3> i've tested this myself with a few videos and youtube-dl
[02:41:07 CET] <alexpigment> klaxa: i understand where you're coming from, but if you can play the lossless file and it seems like it's not a fleeting format, the lossy version is unnecessary
[02:41:30 CET] <alexpigment> therage3: yeah, youtube does some really stupid stuff with audio
[02:41:42 CET] <alexpigment> it used to be that 1080p rips had 160kbps AAC tracks
[02:41:49 CET] <alexpigment> and then they changed them to 128kbps later
[02:41:54 CET] <alexpigment> and I have proof of that
[02:41:58 CET] <klaxa> on a hi-fi audio setup, sure go for whatever quality you like :)
[02:42:19 CET] <klaxa> on my phone with low-level consumer-grade hardware i use opus and can't tell the difference :P
[02:42:51 CET] <alexpigment> klaxa: yeah, i'd agree with that. i just use spotify for mobile at this point
[02:43:09 CET] <alexpigment> the "high quality" seems good enough for me, whatever it is
[02:43:18 CET] <alexpigment> probably 256kbps aac or something
[02:44:27 CET] <alexpigment> that does bring up a question i've been wondering
[02:44:37 CET] <alexpigment> what's the transparency of bluetooth at this point?
[02:45:04 CET] <alexpigment> doesn't it have to be compressed in a specific way for bluetooth?
[02:46:03 CET] <c3-Win> Depends on the version of Bluetooth and what's going over the wire.
[02:46:40 CET] <alexpigment> right, but isn't it only lossy codecs at this point?
[02:46:51 CET] <alexpigment> and if so, is there a bitrate limit?
[02:48:54 CET] <alexpigment> looks like aac at 250kbps, sbc at 328kbps, and aptx at some other bitrate
[02:49:10 CET] <alexpigment> and i guess sbc is inferior to mp3
[02:49:17 CET] <kepstin> you can put mp3 and aac over bluetooth nowadays, iirc some devices (apple?) have players that just sttream the original aac directly to bt devices
[02:49:52 CET] <kepstin> my sony stuff does ldac, which seems to sound great, but uses so much bandwidth that it cuts out all the time if there's any other nearby bt devices
[02:50:11 CET] <alexpigment> yeah, that's always a concern
[02:50:25 CET] <alexpigment> i still don't use bluetooth for anything
[02:51:10 CET] <kepstin> lets see, ldac has 3 modes - 333kbit, 660kbit, and 990kbit
[02:51:25 CET] <alexpigment> those are nice rates on paper
[02:51:36 CET] <kepstin> supposedly the 330kbit mode sounds better than sbc at 328kbit
[02:51:37 CET] <alexpigment> are the higher ones for multichannel?
[02:51:49 CET] <kepstin> no, high bit depth mostely
[02:51:55 CET] <alexpigment> ah
[02:52:06 CET] <kepstin> so you can send 96khz from your gold plated walkman
[02:52:14 CET] <alexpigment> :)
[02:52:27 CET] <alexpigment> but yes, i can see how those bitrates could cause reliability problems
[02:52:41 CET] <kepstin> https://www.sony.com/electronics/walkman/nw-wm1z - it is actually literally gold plated, btw
[02:53:13 CET] <alexpigment> that price tag...
[02:53:34 CET] <alexpigment> some real cork sniffing stuff going on here
[02:53:49 CET] <kepstin> i really wish opus over bt would become a thing
[02:54:02 CET] <kepstin> low latency + sounds great + error concealment...
[02:54:07 CET] <kepstin> it's the perfect codec for bt
[02:54:51 CET] <alexpigment> if sony or apple had a stake in opus, it would probably have happened by now
[02:55:11 CET] <alexpigment> this is how the codec world has worked for the last however many years
[02:55:23 CET] <kepstin> i mean, people always complain about bt audio latency causing desyncs when watching movies and stuff, opus fixes that
[02:55:58 CET] <alexpigment> i'll take your word for it
[02:56:06 CET] <alexpigment> i use good ol' wires
[02:56:15 CET] <alexpigment> audio in sync over here ;)
[02:56:26 CET] <alexpigment> but sure, i'm up for more codec support
[02:57:13 CET] <kepstin> i'm just annoyed because the headphone jack in my phone broke and i forgot to test it after repairing it before I put the back on again, so it's still broken
[02:57:16 CET] <alexpigment> VIA and fraunhoffer are probably paying lots of money to the bluetooth people
[02:57:30 CET] <alexpigment> that sucks
[02:57:54 CET] <alexpigment> i have an iphone SE and i'm sticking to it until apple releases a new SE model or whatever else has a headphone jack
[02:58:12 CET] <alexpigment> fortunately it's still a fast phone
[02:58:40 CET] <kepstin> annoying glass back phone with unreusable glue, if I take the back off again I basically have to replace the glue :/
[02:58:58 CET] <alexpigment> kepstin: i've seen where you live. you can afford glue
[02:59:11 CET] <alexpigment> (i had to lie a bit to make that joke. i don't really know where you live)
[02:59:31 CET] Action: kepstin could, but it's just kind of annoying.
[02:59:38 CET] <alexpigment> no i get it
[02:59:55 CET] <alexpigment> i work on my guitars a lot and have done something similar
[03:00:11 CET] <alexpigment> it's like "ok, this middle position is out of phase now. i don't want to take this apart again"
[03:00:12 CET] <kepstin> i mean, it's literally  acouple bucks to get the precut adhesive from someone in china in the mail in a couple weeks
[03:00:58 CET] <alexpigment> well, if it hasn't become a big enough deal yet, i guess it's not a huge deal
[03:01:15 CET] <alexpigment> for me, i have these sony headphones that I love and I don't want to invest in some stupid wireless headphones or a dongle
[03:01:47 CET] Action: kepstin ended up getting some nice sony noise cancelling wireless headphones, and honestly hasn't really missed the headphone jack
[03:01:58 CET] <alexpigment> and the sonys aren't anything special on paper, but they just sound perfect. they used to be $20 new and people are regularly trying to sell them for $200+ on ebay now for some stupid reason
[03:02:59 CET] <alexpigment> i kinda like being able to hear outside of my headphones. that's a rare quality these days between all the earbuds and over-the-ears out there now
[03:04:00 CET] <kepstin> curiously enough, that's actually something the sony noise cancelling stuff does well - you can switch them to an ambient passthrough mode that lets you hear stuff around you, but doesn't leak your sound
[03:04:16 CET] <alexpigment> oh nice
[03:04:25 CET] <alexpigment> that's a really cool use of the mic
[03:04:41 CET] <alexpigment> i didn't know they did that
[03:04:53 CET] <kepstin> even have a mode that'll silence fan noise and whatnot but let you hear voices.
[03:05:15 CET] <alexpigment> ah, selective bands
[03:05:21 CET] <alexpigment> pretty cool
[04:04:01 CET] <foul_owl> Is there a filter that can extract the movement from some frames? I know it won't be perfect, but like a greenscreen effect?
[04:04:17 CET] <foul_owl> Imagine you set up a tripod and someone walked through the shot.
[04:04:35 CET] <foul_owl> I want to capture the "diffs" and save that as an animation, basically a poor man's greenscreen.
[04:04:44 CET] <foul_owl> Again, I know it won't be perfect but I can edit by hand later
[04:04:51 CET] <foul_owl> Mainly just want to extract the bulk of the diffs
[04:04:55 CET] <foul_owl> Is this possible?
[04:05:30 CET] <foul_owl> Maybe with gimp?
[04:13:13 CET] <fella> convert screenshot_2.png screenshot_1.png \( -clone 0 -clone 1 -compose difference -composite -threshold 0 \) -delete 1 -alpha off -compose copy_opacity -composite -trim moving_parts.png
[04:15:24 CET] <klaxa> neat
[04:51:30 CET] <foul_owl> Damn, that is so awesome :D Thank you!
[04:51:47 CET] <foul_owl> Probably a long shot, but do you know how to extend that to more than two images?
[04:52:32 CET] <foul_owl> Maybe take output from that and use that as input 1, and then frame 3 as input 2, etc?
[09:35:46 CET] <durandal_1707> foul_owl: dont use imagetragick
[09:36:22 CET] <durandal_1707> fella: dont promote imagetragick here
[10:38:32 CET] <durandal_17> ffmpeg -i video -vf "split[v1][v0],[v1]tblend=all_mode=difference,format=yuv444p,extractplanes=y+u+v[r][g][b],[r][g]blend=all_mode=or[rg],[rg][b]blend=all_mode=or,lut=255*gt(val\,0):255*gt(val\,0):255*gt(val\,0)[alpha],[v0][alpha]alphamerge"
[10:38:58 CET] <durandal_17> this does similar to imagetragick
[10:51:52 CET] <alexpigment> durandal_17: are you saying imagetragick in place of imagemagick?
[10:52:07 CET] <alexpigment> is there some beef with that software?
[10:54:38 CET] <durandal_17> alexpigment: its full of tragic CVEs
[10:56:33 CET] <furq> alexpigment: https://imagetragick.com/
[10:57:01 CET] <furq> convert itself is probably fine, notwithstanding that you can do a lot of that stuff with ffmpeg
[10:57:20 CET] <furq> but i definitely wouldn't use it in anything network-facing
[10:58:19 CET] <furq> i wouldn't have used it anyway because it's a horrible resource hog iirc
[11:02:51 CET] <alexpigment> ah
[11:05:37 CET] <furq> libvips is a good alternative if you need a library that has usable bindings for scripting languages
[12:19:04 CET] <tommy``> guys there is a way to use online computer to encode video?
[12:19:24 CET] <tommy``> my pc i slow for encoding so i'd like to use some server that grant it
[12:42:34 CET] <BtbN> tommy``, rent a server, encode on it.
[12:42:54 CET] <tommy``> you dont say
[12:43:17 CET] <BtbN> Any server you can ssh to(so, all of them) will work
[12:43:21 CET] <BtbN> The more CPUs, the faster
[12:43:48 CET] <BtbN> iirc AWS even has an abstracted transcode service, so you don't need to invoke ffmpeg yourself, or manage the hardware. But it's stupidly expensive.
[12:44:17 CET] <BtbN> Grabbing a 8 or 16 core box on GCE would be way cheaper and perform equally or better
[13:04:35 CET] <iive> tommy``: i guess your video card doesn't have encoding support either?
[13:05:14 CET] <tommy``> ( iive ): my all pc is bad: dual core e6600, ddr2 6gb and gtx 550ti
[13:43:00 CET] <DHE> 680 (iirc) is the minimum for nvenc
[14:00:32 CET] <furq> yeah, it's any kepler GTX 600 and up
[16:03:16 CET] <johang> I have encountered a few times that running ffplay somehow wrecks the window manager in my Fedora system so I have to restart a lot of stuff. Before I dig too much: does that sound familiar to you?
[16:03:39 CET] <johang> I usually just reboot
[16:09:46 CET] <khali> never seen that johang, but I don't use ffplay a lot... only when VLC fails
[16:13:02 CET] <johang> That's pretty much what I do too. Well, gotta go.
[16:30:20 CET] <Psilovybin> i've tried a few things... something i'm overlooking?  https://pastebin.com/gqFHk95A
[17:43:42 CET] <logicWEB> good day :-) I'm wondering if there is documentation anywhere about the big shift that happened in the libavfilter infrastructure over the last 8 years
[17:43:56 CET] <logicWEB> mplayer has this filter lavfi in the source code that's been disabled for ages because it's broken. it was written back when libavfilter used the end_frame callback and held frame data in struct AVFilterBufferRef.
[17:44:00 CET] <logicWEB> I've been poking at commits and trying to figure it out, and it looks like the core of the filtering infrastructure is now the filter_frame callback, and frame data is now kept in the standard struct AVFrame, but I'm really uncertain about the correctness of my code because I haven't found anything that clearly explains what a filter is expected to
[17:44:00 CET] <logicWEB>  do and how the filtering infrastructure calls into it
[17:45:10 CET] <logicWEB> basically, I have mplayer SVN with FFmpeg master HEAD building with minimal changes on the FFmpeg side, but when I try to activate a filter via mencoder -vf lavfi, mencoder doesn't crash but simply exits immediately, feels like it's interpreting something as meaning "you've reached the end of the stream"
[17:45:48 CET] <logicWEB> in order to debug this, I have to figure out BOTH mplayer's and FFmpeg's filter models so I can understand in what way they're not talking to each other right now :-)
[17:47:59 CET] <kepstin> logicWEB: you'd probably be better off starting from mpv, which already has fixed the libavfilter integration. Maybe look at its git history?
[17:52:31 CET] <pos> so, i've got this mp4 file which is giving me some headaches playback-wise
[17:53:52 CET] <pos> vlc shows the first frame and crashes, firefox (.) believes it is two hours long (and believes it is corrupt if i try to skip ahead)
[17:54:43 CET] <pos> mpv/mplayer believes it is 19 hours long and also stops responding of i try to jump ahead
[17:55:11 CET] <pos> it's supposed to be about four hours long
[17:55:56 CET] <pos> i was hoping to transcode it to a playable file with correct time metadata?
[17:58:02 CET] <iive> try `ffmpeg -i input.mp4 -c copy output.mp4` and see what you'd got.
[18:01:29 CET] <iive> also, if you suspect that the file might contain a lot of zero blocks, you could try `gzip -1 (fastest) -c input.mp4` video files are already compressed and cannot be made smaller. if it is smaller... the file is incomplete
[18:02:37 CET] <iive> if the blocks are zeros, `cp --sparse=always input.mp4 test.mp4` might be faster way to detect zero blocks. you need `du test.mp4` to check for holes
[18:03:27 CET] <pos> tried it, now both vlc and mpv will open it but it appears to be only two hours long
[18:03:28 CET] <furq> if mpv is misdetecting the time then i don't hold out much hope for ffmpeg
[18:03:36 CET] <pos> also, jumping progress works in neither
[18:04:04 CET] <furq> copying to a new container should have fixed the index
[18:04:08 CET] <pos> rather, doesn't work in either. both stop responding
[18:04:11 CET] <furq> so yeah you've got other issues if seeking still doesn't work
[18:05:58 CET] <pos> thing is, fastforwarding works
[18:06:24 CET] <pos> firefox doesn't believe the output is corrupt but also hangs at skip
[18:07:32 CET] <pos> cp --sparse=same file size
[18:08:49 CET] <pos> it is basically a transport stream from a cctv cam
[18:09:18 CET] <pos> the 19 hours mpv believes is the video length is eerily similar to the camera sys uptime
[18:11:20 CET] <pos> the stream was supposed to be divided into 15 minute individual segments but something broke and the sys kept putting four hours into the same file
[18:11:26 CET] <logicWEB> kepstin: oh! thanks very much :-)
[18:13:16 CET] <pos> ffmpeg -i input.mp4 -c libx264 -an test.mp4
[18:13:37 CET] <pos> [buffer @ 0x115e5a0] Unable to parse option value "-1" as pixel format
[18:13:51 CET] <pos> [buffer @ 0x115e5a0] Error setting option pix_fmt to value -1.
[19:11:15 CET] <SviMik> Hi! How would you apply a filter (like 'curves') to a part of a video (like bottom half)?
[19:13:17 CET] <SviMik> I have tried 'crop' and 'overlay' approach, but stumbled into some positioning error on overlay stage - it does some weird stuff if vertical offset is an odd number
[19:22:59 CET] <durandal_1707> SviMik: you must use even numbers for subsampled formats
[19:24:00 CET] <SviMik> durandal_1707 I've already tried to add "format=rgba" before the filters, still no luck
[19:24:58 CET] <durandal_1707> overlay default fornat is yuv420p,   so change that
[19:26:40 CET] <furq> SviMik: crop and vstack is probably easier
[19:27:17 CET] <furq> assuming you only need the bottom half and not a region
[19:28:13 CET] <SviMik> durandal_1707 ah, there it is! thanks! I thought all filters use some auto detection
[19:28:21 CET] <SviMik> furq I need a region...
[19:31:23 CET] <SviMik> -filter_complex "[0:v]crop=x=700:y=43:w=460:h=77,curves=m='0/0 0.697/1.0'[crt];[0:v][crt]overlay=x=700:y=43:format=rgb,format=yuv420p"
[19:31:27 CET] <SviMik> works
[19:32:08 CET] <SviMik> (trailing format=yuv420p just to convert the final result back to yuv420p)
[23:19:58 CET] <Tugamars> Hello, anyone here?
[23:21:20 CET] <SviMik> Tugamars don't ask to ask a question. just go and ask it
[23:25:25 CET] <Tugamars> Can someone check this post i made on reddit and help me with this question? https://www.reddit.com/r/ffmpeg/comments/7ldh3j/how_to_overlay_image_with_a_video/
[23:26:10 CET] <Tugamars> My objective is to, basicly: create a movie and just "replace" the 'static' images with new ones, so i can create a script that automaticly does that
[23:27:42 CET] <furq> why are you using -s 640x480 if you don't want the output to be 640x480
[23:27:59 CET] <Tugamars> i want the final video output to be 640x480
[23:28:14 CET] <furq> what does "the video scales down" mean then
[23:29:18 CET] <SviMik> are you sure that your image is 640x480 too?
[23:29:58 CET] <Tugamars> The red thing is the video, the blue thing is the image. I want to put the video on top of image (the video have alpha), and export it as a new video with 640x480. http://prntscr.com/hr78mv
[23:30:31 CET] <Tugamars> The problem is that the red thing (video) is rendered at 640x480 but when i try to use ffmpeg to overlap both it scales down
[23:31:57 CET] <Tugamars> Not sure if i explaned well
[23:34:32 CET] <furq> is bg.jpg much bigger than 640x480 by any chance
[23:34:46 CET] <Tugamars> yes, it is
[23:34:51 CET] <furq> well yeah there's your problem
[23:34:56 CET] <furq> it's scaling to 640x480 after overlaying
[23:35:08 CET] <Tugamars> I need to scale it down/crop before using?
[23:35:11 CET] <furq> yeah
[23:35:23 CET] <Tugamars> Thanks :) Will try
[23:35:24 CET] <furq> you can do that with ffmpeg but it's probably easier to just scale it beforehand
[23:36:44 CET] <furq> http://vpaste.net/WoRB8
[23:36:49 CET] <furq> also your command should probably look more like that
[23:37:05 CET] <pos> i have an application which is pulling an rtsp stream for video, thing is that the source is providing audio on a separate stream
[23:37:17 CET] <Tugamars> Another question, if i may: How do you define the "time" that the bg image stays ? I mean, imagine i want one image from 00 to 01 and another from 01 to 02, how do i do that ? I've been searching but cant find much info
[23:37:32 CET] <pos> the app can handle extra params for ffmpeg, can i specify a second source for audio?
[23:37:34 CET] <furq> Tugamars: https://ffmpeg.org/ffmpeg-filters.html#Timeline-editing
[23:38:12 CET] <furq> pos: -i rtsp://1.ts -i rtsp://2.ts
[23:38:15 CET] <Tugamars> What does "lavfi" does ?
[23:38:23 CET] <furq> it's an alias for -filter_complex
[23:38:38 CET] <furq> -vf and -af can only handle one input at a time, -filter_complex can handle multiple
[23:38:38 CET] <pos> ah, unsure as to whether it'll accept two -i s
[23:38:47 CET] <Tugamars> oh ok. Thanks furq :)
[23:39:00 CET] <furq> pos: "extra args" would imply they're after some output options, yeah
[23:39:18 CET] <furq> i don't know if the movie filter accepts network inputs but if it does then that might work
[00:00:00 CET] --- Sat Dec 23 2017