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

[burek]

[00:00:32 CEST] <kepstin> hmm, if the entire file has the same data in both channels, 96K mp3 might be ok, because it should all be in mid-side joint stereo mode
[00:00:54 CEST] <kepstin> (although obviously vbr would be better than cbr if possible)
[00:01:22 CEST] <llogan> kepstin: you can probably simplify it by using < instead of =: "pan=stereo|c0<FL+FR|c1<FL+FR"
[00:01:38 CEST] <kepstin> llogan: the pan filter syntax kinda scares me :)
[00:02:28 CEST] <kepstin> i suppose if I really wanted to simplify, i'd use "-af extrastereo=0" ;)
[00:02:43 CEST] <llogan> don't feel bad. it's made me sit there and mouthbreate for a minute with some more complex junk
[00:03:45 CEST] <olspookishmagus> come on people, give me something to read about it
[00:03:54 CEST] <olspookishmagus> even some college DSP textbook
[00:04:05 CEST] <llogan> https://ffmpeg.org/ffmpeg-filters.html#pan
[00:05:08 CEST] <kepstin> olspookishmagus: there's nothing really complex. the trivial "convert to mono" filter is to just average the left and right samples :/
[00:05:31 CEST] <olspookishmagus> well what's the diffrence between stereo and joint-stereo?
[00:05:52 CEST] <llogan> can your system not play mono? i still don't see the reason to make a "stereo > mono > stereo" output.
[00:07:00 CEST] <kepstin> joint stereo is an optimization in mp3 encoding where if left and right channels are similar, it encodes the "same parts" and "different parts" instead of left and right, see http://wiki.hydrogenaud.io/index.php?title=Joint_stereo#Mid-side_Stereo_.28MS.29 for the simple math. It just reduces duplication to save bits/improve quality.
[00:08:09 CEST] <kepstin> note that the "middle" channel of "mid-side" is the same as averaging the left and right channels :)
[00:12:40 CEST] <olspookishmagus> example of the varsity in files: https://pastebin.com/raw/1bueTf8d
[00:16:16 CEST] <olspookishmagus> llogan: I don't know what will happen if I put a mono MP3 file in my car stereo, what's should I expect to happen? sound to come from all speakers?
[00:16:34 CEST] <olspookishmagus> thanks kepstin
[00:16:49 CEST] <alexpigment> yeah, mono mp3s should come out of all speakers
[00:17:14 CEST] <alexpigment> if it's coming out of one speaker only, then someone has failed at their job ;)
[00:17:38 CEST] <alexpigment> the only time that should happen legitimately is if you have a stereo file with one side silent
[00:18:02 CEST] Action: olspookishmagus downmixes all of his MP3s to mono
[00:18:22 CEST] <olspookishmagus> 652G will take some time though
[00:18:43 CEST] <furq> you should probably check if it works before doing all of them
[00:18:50 CEST] <olspookishmagus> alexpigment: so how would you script such, or any other, actions in Windows?
[00:18:53 CEST] <alexpigment> i'd agree with that ;)
[00:19:29 CEST] <alexpigment> are you actually going to do this on windows?
[00:19:29 CEST] <olspookishmagus> Don't worry, I do that only for car-audio I don't tamper with my MP3s for no reason.
[00:19:34 CEST] <alexpigment> otherwise, i'll save myself the effort
[00:19:44 CEST] <olspookishmagus> alexpigment: no I won't - but I'm interested to see your tools-of-trade
[00:19:50 CEST] <alexpigment> OK :(
[00:20:10 CEST] <durandal_170> stereotools filter
[00:20:31 CEST] <alexpigment> @ECHO OFF
[00:20:31 CEST] <alexpigment> set
[00:20:31 CEST] <alexpigment> if [%1]==[] goto :eof
[00:20:31 CEST] <alexpigment> :loop
[00:20:31 CEST] <alexpigment> C:\ffmpeg.exe -i "%~dpnx1" -ac 1 -b:a 96kbps "%~dpn1.mp3"
[00:20:31 CEST] <alexpigment> shift
[00:20:32 CEST] <alexpigment> if not [%1]==[] goto loop
[00:20:38 CEST] <alexpigment> (SORRY FOR PASTING THAT GUYS)
[00:20:53 CEST] <alexpigment> anyway, then you'd just drag the files on top of the bat file
[00:20:57 CEST] <alexpigment> and it processes them in order
[00:21:30 CEST] <alexpigment> of course, you'd want to append something to the final name like "mono.mp3" or something
[00:23:01 CEST] <olspookishmagus> another problem I have in mind is the different sound levels of MP3s, I remember sometime I open MP3s in Audacity and Select All -> Filters -> Amplify and leave that preselected maximum value that will not do any clipping
[00:24:07 CEST] <olspookishmagus> alexpigment: that would work say in WinXP?
[00:24:09 CEST] <kepstin> olspookishmagus: you probably want to look into replaygain then, either with ffmpeg's rganalyze or r128gain filters or with external tools
[00:25:09 CEST] <kepstin> the 'mp3gain' standalone tool can change the volume of encoded mp3s to be the same, so it might be a good choice for this.
[00:25:45 CEST] <kepstin> (and please stop using windows xp! and if you have to, make sure it's not connected to the internet...)
[00:26:51 CEST] <mavi> Is there any other filters that can help smooth out low bitrate videos or help with their compressions other than the denoisers?
[00:27:43 CEST] <durandal_170> yes, blanking frames
[00:28:28 CEST] <llogan> you can try postprocessing filters: http://trac.ffmpeg.org/wiki/Postprocessing
[00:28:36 CEST] <llogan> if you prefer that look...
[00:29:10 CEST] <olspookishmagus> kepstin: that should be able to produce a median for a directory of MP3s (with its subdirectories)
[00:29:34 CEST] <olspookishmagus> it's not the best thing after a LOUD mp3 to be followed by a real SILENT one
[00:29:38 CEST] <olspookishmagus> and then a REALLY LOUD one
[00:29:44 CEST] <kepstin> olspookishmagus: replaygain tools adjust everything to match a standard reference level
[00:30:03 CEST] <kepstin> it's designed to fix exactly that problem
[00:30:10 CEST] Action: olspookishmagus bows to kepstin 
[00:31:50 CEST] <Dan77> if I try to make an animated gif from images with transparency i can see all the previous frames behind the current one. is this working as intended?
[00:32:45 CEST] <durandal_170> no
[00:32:49 CEST] <olspookishmagus> Dan77: GIMP?
[00:35:46 CEST] <Dan77> no
[00:38:50 CEST] <mavi> interesting, thanks llogan. With PP im guessing it gets hardcoded into the video file itself, so that the viewer using their html5 player sees the diff
[00:38:51 CEST] <mavi> ?
[00:40:52 CEST] <mavi> im curious if youtube for their lower 240p stuff uses post processing. Man those examples look so blurred out
[00:42:50 CEST] <thebombzen> Dan77: yes
[00:43:04 CEST] <thebombzen> GIF transparency does that intentionally as a way to save space
[00:43:51 CEST] <thebombzen> transparency in a GIF image is used as a shortcut to copy from the previous frames (by overlaying 'transparent') as a zero-th order approximation
[00:44:04 CEST] <thebombzen> or a zero-th order inter prediciton
[00:44:17 CEST] <thebombzen> Dan77: what this means is that GIFs do not *really* support transparency
[00:44:32 CEST] <thebombzen> and use the transparency as a way to self-optimize
[00:44:46 CEST] <thebombzen> the only way to make something transparent is to have it be transparent in *every* frame
[00:44:49 CEST] <durandal_170> yes use apng
[00:45:14 CEST] <Dan77> @thebombzen, I can't seem to make apng loop with ffmpeg
[00:45:21 CEST] <furq> mavi: like i said, youtube denoises the hell out of everything
[00:45:21 CEST] <Dan77> @durandal_170,
[00:45:49 CEST] <thebombzen> Animated PNG should loop automatically in your browser or viewer
[00:45:49 CEST] <durandal_170> Dan77: with muxer?
[00:45:53 CEST] <thebombzen> I'm not sure if there's a flag for it
[00:46:07 CEST] <mavi> furq: For sure, I can see that. But I'm curious if they post process as well. What do you think?
[00:46:18 CEST] <furq> that is postprocessing
[00:46:33 CEST] <mavi> really? I thought using denoise filters was not considered pp?
[00:46:34 CEST] <durandal_170> ffmpeg -h muxer=apng
[00:52:14 CEST] <Dan77> durandal_170, thanks. That worked.
[01:07:08 CEST] <mavi> So i'm trying to figure out how my handbrake encodes, look better than my ffmpeg encodes at the same exact settings. Does handbrake not use ffmpeg?
[01:09:32 CEST] <pzy> handbrake is H.264/AVC
[01:09:45 CEST] <mavi> yea im using x264 on both
[01:10:48 CEST] <pzy> not a clue :D
[01:11:06 CEST] <mavi> super slight differences at low bitrates. it's quite interesting.
[01:14:02 CEST] <pzy> video encoding is outer space voodoo
[01:14:06 CEST] <pzy> that no one actually understands
[01:16:26 CEST] <pzy> you see, when a spacecraft landed in Roswell, it gave us two things: the integrated circuit, and fourier transforms
[01:16:28 CEST] <pzy> :P
[01:19:20 CEST] <mavi> nvm it seems like im using bicubic resize and handbrake use lancoz3, which causes a slight diff.
[01:23:11 CEST] <alexpigment> mavi: i ran into something similar earlier. then i was like "oh yeah, lanczos"
[01:26:05 CEST] <alexpigment> that reminds me. i was doing some tests with mpeg2video encoding and i was using the -vf interlace command. lowpass enabled is too blurry, but lowpass disabled is too aliased. is there another method for doing antiflicker that is less hamfisted (even if it's way slower)?
[01:26:18 CEST] <alexpigment> to be clear, this is for 480i DVD
[01:26:36 CEST] <mavi> for ffmpeg is lancoz flag, the same as lancos3?
[01:26:49 CEST] <mavi> or is there a specific flag for that
[01:27:02 CEST] <alexpigment> -sws_flags lanczos is all i know
[01:34:38 CEST] <llogan> "scale=1280:720:flags=lanczos" for example. no need to use -sws_flags separately.
[01:34:50 CEST] <llogan> ...especially if you're using multiple scales.
[01:37:02 CEST] <alexpigment> llogan: it's these little optimizations that are demonstrated here every day that make this room invaluable to me
[01:37:16 CEST] <alexpigment> i didn't know you could do that, but i'll do it from now on
[01:39:59 CEST] <llogan> soon you will have a long neckbeard
[01:40:59 CEST] <alexpigment> oh i'm well on my way to neckbearddom
[01:41:14 CEST] <alexpigment> i'm 2 steps away from the comic store owner on the simpsons
[01:42:21 CEST] <DHE> is the x262 encoder good? as in, should I use it over the built-in mpeg2video encoder?
[01:46:46 CEST] <alexpigment> DHE, i asked that earlier
[01:46:52 CEST] <alexpigment> i was told it was abandoned
[01:46:57 CEST] <mavi> I havent' left my room in 2 days.. nope handbrake yields a smaller file than the ffmpeg equiv, all settings including resizer thrown in. Can't wrap my head around it. It may be the x264 version used.. handbrake uses an older version, yet file size is smaller.
[01:47:09 CEST] <alexpigment> and then kepstin gave me some tips on improving the built-in encoder's quality
[01:47:35 CEST] <alexpigment> i'm done with work for the day, but i'll let you know my findings re: quality when i get done with testing
[01:47:58 CEST] <alexpigment> but i'll try to do some testing on x262 as well when i get a chance
[01:48:28 CEST] <alexpigment> mavi: have you looked at the two files in MediaInfo?
[01:48:39 CEST] <mavi> yes i have. that's where i grab the video data from
[01:48:54 CEST] <llogan> what's the sudden interest in x262 from?
[01:48:57 CEST] <mavi> im testing it with a bigger duration than 2 minutes now to see if the same holds with longer duration
[01:49:05 CEST] <alexpigment> have you looked at the x264 settings in the "text" view to see the full paramaters?
[01:49:14 CEST] <mavi> yep copied them and compared.
[01:49:34 CEST] <alexpigment> how much smaller are we talking about here?
[01:49:38 CEST] <mavi> matched them up even to the t with the useless max bitrate and buffer than is set at 2000k for crf 29 lol
[01:49:47 CEST] <mavi> im testing on a bigger scale but 10%
[01:50:04 CEST] <alexpigment> that's certainly non-trivial
[01:50:25 CEST] <alexpigment> llogan: my interest was to replace another mpeg-2 encoder for DVD encoding
[01:50:28 CEST] <mavi> will let you know in a few when the larger duration completes
[02:04:02 CEST] <furq> mavi: are you using a 2mbps maxrate
[02:04:13 CEST] <furq> that's a lot for 480p, you can probably use a much lower crf
[02:10:50 CEST] <DHE> alexpigment: got a copy of the logs? or timestamp so I can scroll back?
[02:18:03 CEST] <mavi> yea i know i'm just using the same settings as handbrake to figure out what's going on
[02:18:13 CEST] <mavi> so same settings to the T, filters all disabled except resize
[02:18:27 CEST] <mavi> and handbrake files are 10% smaller than ffmpeg.. very odd.
[02:18:47 CEST] <mavi> testing with a 15 min file and it showed the same. Ironically the handbrake video looks better too..
[02:19:42 CEST] <mavi> Would the format profile matter at all in the sizes? High at L4 on handbrake vs High at L3.2 on ffmpeg
[02:20:14 CEST] <furq> are you using the same x264 preset
[02:20:22 CEST] <mavi> yes exact same
[02:20:33 CEST] <furq> if it's the same preset and same resolution then the level should be identical
[02:20:46 CEST] <furq> so maybe one of them is setting the level wrong
[02:20:56 CEST] <mavi> ffmpeg auto sets it i believe
[02:21:10 CEST] <mavi> would that affect bitrate though? It shouldn't from what i understand
[02:21:13 CEST] <furq> ffmpeg detects the right level unless you override it
[02:21:20 CEST] <furq> and no the level is pretty much advisory
[02:21:22 CEST] <alexpigment> levels are effectively bitrate limits
[02:21:34 CEST] <alexpigment> (outside of resolution and frame rate)
[02:22:07 CEST] <furq> i suspect handbrake is wrong
[02:22:14 CEST] <mavi> one small difference i do notice. ffmpeg set the framerate automatically at Frame rate mode             : Constant Frame rate                  : 24.390 FPS
[02:22:23 CEST] <furq> 3.2 is good for 720p60 at 25mbit
[02:22:26 CEST] <mavi> while handbrake sets it as Frame rate mode             : Variable Frame rate                  : 23.976 (24000/1001) FPS Minimum frame rate          : 23.974 FPS
[02:22:40 CEST] <furq> ffmpeg does cfr output by default
[02:22:42 CEST] <mavi> im using it for low bitrate, i doubt the level matters above 3.2
[02:22:59 CEST] <alexpigment> DHE: https://gist.githubusercontent.com/kepstin/9d60cde1f1714657737b8bdc58d673c5/raw
[02:23:04 CEST] <mavi> would that affect the output size to this degree?
[02:23:09 CEST] <alexpigment> DHE: fwiw, i ignored the DIA saize
[02:23:16 CEST] <furq> that shouldn't make any difference
[02:23:23 CEST] <furq> the only difference is how the stream is muxed into the container
[02:23:34 CEST] <DHE> alexpigment: thanks
[02:24:01 CEST] <furq> also i'm not sure how accurate mediainfo's framerate detection is
[02:24:13 CEST] <alexpigment> DHE: it's slow as hell, but i plan on optimizing (i.e. removing variables) once i'm happy with the quality
[02:24:15 CEST] <mavi> checked and both are  x264 core 148 , ffmpeg one is latest build of it, so that's not it.
[02:24:46 CEST] <alexpigment> mavi: what about x264opts force-cfr ?
[02:25:19 CEST] <mavi> should i set that and run the test again?
[02:25:21 CEST] <alexpigment> that would eliminate the frame rate difference probably
[02:25:36 CEST] <alexpigment> i don't know. furq said it shouldn't matter, and i trust him over me ;)
[02:25:43 CEST] <mavi> i prefer that it keeps the native framerate
[02:25:56 CEST] <furq> you should probably use -vsync passthrough in ffmpeg
[02:26:05 CEST] <alexpigment> yeah, i generally shy away from vfr for maximum compatibility
[02:26:06 CEST] <mavi> native is : 23.976 actually.. dunno why ffmpeg changed it.
[02:26:18 CEST] <furq> what output format
[02:26:27 CEST] <mavi> mp4
[02:26:30 CEST] <furq> oh
[02:26:33 CEST] <furq> no idea then
[02:28:11 CEST] <alexpigment> mavi: the Tune is set the same for both?
[02:28:50 CEST] <mavi> https://ibb.co/hwC1dv
[02:28:55 CEST] <alexpigment> (sorry, i realize you've probably checked all this. just trying to think of other things that would make a difference)
[02:28:57 CEST] <mavi> I uploaded the settings there.
[02:29:37 CEST] <alexpigment> deblock is different
[02:29:50 CEST] <alexpigment> oh duh
[02:29:51 CEST] <alexpigment> nm
[02:29:53 CEST] <alexpigment> ignore me
[02:29:59 CEST] <alexpigment> was comparing the wrong two ;)
[02:30:03 CEST] <furq> are you using placebo
[02:30:29 CEST] <mavi> crap
[02:30:35 CEST] <mavi> crf is 29 vs 30
[02:30:40 CEST] <mavi> hahaha, let me recheck this
[02:30:42 CEST] <furq> lol
[02:30:44 CEST] <furq> also don't use placebo
[02:30:51 CEST] <furq> the clue's in the name
[02:30:58 CEST] <mavi> this is what happens when i don't leave me room for a day. I'm using very slow actually
[02:31:12 CEST] <furq> me=esa is placebo
[02:31:14 CEST] <mavi> with a few more strict presets that help without costing me too much time
[02:31:21 CEST] <alexpigment> placebo? mavi has more patience than i've ever had in my entirely life re: encoding
[02:31:35 CEST] <alexpigment> *entire
[02:31:41 CEST] <mavi> placebo is about half the speed of my current setup
[02:31:56 CEST] <mavi> using 8 ref/6 bframes, vs the default but yea just doing this for tests.
[02:32:01 CEST] <furq> even veryslow is overkill for 480p
[02:32:55 CEST] <furq> fwiw if this is for streaming then you absolutely do want to use maxrate/bufsize
[02:33:26 CEST] <mavi> it is.
[02:33:33 CEST] <mavi> my last step will be setting those two.
[02:33:46 CEST] <mavi> deciding between crf 29 or 30. They look fairly similiar though.
[02:33:47 CEST] <furq> i mean you probably want to test with those enabled
[02:33:52 CEST] <furq> those will have a big impact on quality
[02:33:59 CEST] <furq> or will potentially have
[02:34:07 CEST] <mavi> at my crf levels every setting matters
[02:34:14 CEST] <mavi> just not some of the placebo level ref/bfrakes
[02:34:45 CEST] <alexpigment> i generally use an aggressive maxrate/bufsize and then turn the CRF to a significantly lower number, but that's just me
[02:34:49 CEST] <furq> also if this is for people with crap internet then you might want to reconsider using high profile
[02:34:57 CEST] <furq> since i assume they may also have crap phones
[02:35:40 CEST] <mavi> it's for pakistan/india, from what i've seen they have pretty good phones, but the internet is spotty/costly
[02:35:41 CEST] <alexpigment> most things that support main profile also support high profile though, right?
[02:35:54 CEST] <furq> i'm not an expert on what mobile devices support really
[02:35:58 CEST] <alexpigment> i mean in my experience it's either baseline or high
[02:36:14 CEST] <alexpigment> but youtube does 480p at main for whatever reason, so there's that
[02:36:21 CEST] <mavi> Im guessing main limits bframes at 3?
[02:37:43 CEST] <alexpigment> no clue
[02:37:48 CEST] <furq> no
[02:37:53 CEST] <furq> i don't know what it does restrict off the top of my head
[02:38:00 CEST] <mavi> more things to look up... there goes another day of leaving my room lol
[02:38:03 CEST] <furq> refs are restricted by level
[02:39:53 CEST] <furq> looks like it's just i8x8 partitions that get disabled for main profile
[02:40:03 CEST] <furq> not sure how big a deal that is
[02:40:23 CEST] <alexpigment> as far as quality, main and high are pretty similar in my experience
[02:40:51 CEST] <alexpigment> decoder complexity, i'm not entirely sure, but again, i usually only see a restriction of baseline profile on crap devices fwiw
[02:40:55 CEST] <furq> baseline means no cabac or bframes, so that's not really an option
[02:40:57 CEST] <mavi> interesting
[02:41:10 CEST] <mavi> yea if they are close enough, i'll try to go to the one that supports more devices, makes sense.
[02:41:32 CEST] <furq> at least with ffmpeg, if you set -profile:v main it'll automatically turn off anything incompatible
[02:41:41 CEST] <mavi> alright at the same crf, the diff is only .2% all is well.
[02:41:43 CEST] <furq> i assume handbrake does the same
[02:42:06 CEST] <furq> also
[02:42:07 CEST] <furq> 01:34:45 ( alexpigment) i generally use an aggressive maxrate/bufsize and then turn the CRF to a significantly lower number, but that's just me
[02:42:10 CEST] <furq> echoing this
[02:44:04 CEST] <mavi> How would i go about coming up with a maxrate number? My avg bitrate for this video was 226kbps i've seen it swing up to 300 at times.
[02:44:17 CEST] <alexpigment> what are you trying to keep it under?
[02:44:26 CEST] <furq> i assume you have an internet speed constraint in mind
[02:44:45 CEST] <furq> i have no idea what south asian mobile connections are like
[02:47:00 CEST] <mavi> i have no limits in mind. Just want to go based off of the files. They are smaller than the avg file size i've seen for video sites in the area at it is. The limit is more for my server to limit max buffering and allow more simultaneos connections at once.
[02:47:27 CEST] <alexpigment> well, the thing to consider is that using only a CRF means that there could be heavy spikes that result in buffering
[02:47:46 CEST] <alexpigment> so you want to constrain those spikes if the goal is streaming
[02:48:19 CEST] <mavi> right, but at these bitrates, I want to retain as much quality as possible, since it's already a very aggressive crf.
[02:48:21 CEST] <alexpigment> but you also don't want to do a VBR encode because you're wasting bits in low-complexity parts to try to hit the target bitrate
[02:49:06 CEST] <alexpigment> ok, do what you need to do. but if someone's internet sucks enough to necessitate sub-300kbps bitrate, those spikes will result in buffering
[02:51:11 CEST] <mavi> Let's say then, that I want to allow a 512kbps ADSL connection to work with this video.
[02:51:19 CEST] <mavi> How would I set my max bitrate for that?
[02:51:56 CEST] <mavi> i've seen videos go from 120kbps up to 350kbps with the crf30 setting and the source videos.
[02:53:10 CEST] <alexpigment> maxrate 512000 bufsize 512000 crf 16
[02:53:18 CEST] <alexpigment> play around with the crf as necessary
[02:53:28 CEST] <alexpigment> maybe a CRF of 25 is more realistic
[02:53:35 CEST] <furq> yeah
[02:53:48 CEST] <mavi> interesting... so it does the work of the crf for it? Just destoring the higher end spikes?
[02:53:52 CEST] <furq> i probably wouldn't go above 480k, maybe a bit less
[02:53:55 CEST] <alexpigment> but crf ~30 is just a weird concept for me, so i can't recommend that
[02:53:55 CEST] <furq> and i'd use a bigger bufsize
[02:54:20 CEST] <alexpigment> yeah furq with the convservatism that i obviously neglected in my suggestion :)
[02:54:44 CEST] <mavi> do people usually go for like 2 seconds buffer time?
[02:54:53 CEST] <alexpigment> that's not uncommon
[02:54:59 CEST] <furq> i've got four seconds in my head but that's not based on anything
[02:55:07 CEST] <alexpigment> depends on how instantly you want the stream to start
[02:55:32 CEST] <furq> the average bitrate of any bufsize-sized section of video will never exceed maxrate
[02:55:46 CEST] <furq> it can still spike above maxrate for short bursts
[02:56:03 CEST] <furq> so ideally you want as big a buffer as possible
[02:56:10 CEST] <furq> but obviously that's constrained by the device
[03:02:00 CEST] <mavi> The point of that setup is to saturate the maximum it can out of the bandwith limit, vs the maximum out of the constant quality.
[03:02:09 CEST] <mavi> i mean that's the point of max bitrate?
[03:13:48 CEST] <sikilikis> hey what does the igndts flag do?
[03:26:32 CEST] <Threads> it sets up a trust fund so that you can roll in money later on in life
[03:42:16 CEST] <Derakon> I have a video of some SNES emulator footage; it's 512x448 (double native resolution). I'd like to further double this to 1024x896.
[03:42:18 CEST] <Derakon> I used this command:
[03:42:19 CEST] <Derakon> ffmpeg -i Eris2012.mov -ss 00:05:00 -t 00:01:00 -sws_flags 'neighbor' -vf scale=1024:-1 resize.mov
[03:42:37 CEST] <Derakon> The result is the right size, but the video slowed way down! Like, I'd guess I'm getting half the playback speed I'm supposed to.
[03:43:37 CEST] <Derakon> Paste: https://pastebin.com/D0AHDq2P
[03:44:01 CEST] <Derakon> Also is 'neighbor' the right resizing algorithm to use if I want a pixel-perfect resizing with no filtering?
[03:44:09 CEST] <Tatsh> furq, i used qtgmc and it's cool and all but i don't know if i should leave the output at 60000/1001 or use FPSDivisor=2
[03:44:23 CEST] <Tatsh> when i use FPSDivisor=2, i get a weird framerate of 29.925783
[03:44:51 CEST] <Tatsh> supposedly the input is supposed to be 59.94, and 59.94 / 2 = 29.97, not 29.925783
[03:45:56 CEST] <Derakon> ...oh, wait.
[03:45:58 CEST] <Derakon> I'm dumb.
[03:46:06 CEST] <Derakon> I had VLC set to reduced framerate while sorting out an audio desync issue.
[03:46:17 CEST] <Derakon> Thanks guys! :V
[03:52:08 CEST] <Tatsh> it seems okay to pass this to ffmpeg and use decimate=cycle=2,fps=30000/1001
[03:52:21 CEST] <Tatsh> not sure if this will reduce quality a lot
[03:55:06 CEST] <Tatsh> actually only need decimate=cycle=2
[04:32:51 CEST] <thebombzen> huh, ffconcat complains that "Protocol file is not on whitelist crypto"
[04:33:06 CEST] <thebombzen> is that a bug or am I missing something
[04:47:15 CEST] <alexpigment> thebombzen: did you see this article? http://blog.yo1.dog/fix-for-ffmpeg-protocol-not-on-whitelist-error-for-urls/
[04:47:39 CEST] <thebombzen> alexpigment: the issue is that file:// is not on the whitelist
[04:47:52 CEST] <thebombzen> and the problem only occurs if reading the ffconcat from standard input
[04:47:59 CEST] <thebombzen> just creating the file and using it worked fine
[04:48:11 CEST] <alexpigment> you can apparently put 'file' on the whitelist though
[04:48:39 CEST] <alexpigment> anyway, it sounds like you've got a workaround, so alls well that ends well i guess
[04:48:53 CEST] <thebombzen> file should already be on the whitelist
[04:49:00 CEST] <thebombzen> for safe paths at least
[04:49:36 CEST] <alexpigment> add crypto to the whitelist
[04:50:43 CEST] <alexpigment> anyway, i'm just going by the comments on that post. you know more details about the error, so i'll trust that you've got a good handle on it
[05:51:19 CEST] <mavi> So a theoretical question here, which would be better? A 29 CRF video with very slow preset, 480p, or a 26 crf video at 360p. File size is the same. When watching full screen which would technically better/
[05:52:05 CEST] <thebombzen> mavi: depends on the video
[05:52:18 CEST] <thebombzen> it also depends on what scaling algorithm you're going to use
[05:52:24 CEST] <thebombzen> what the size of your screen is
[05:52:28 CEST] <thebombzen> the original quality of the source
[05:52:29 CEST] <Hexatona> I do a 640:aspect ration at 32 CRF and I find it very watxhable
[05:52:42 CEST] <mavi> a video with normal people, let's say 1080p screen, not too many action scenes.
[05:52:44 CEST] <thebombzen> 640x360 at crf 32 is pretty terrible
[05:52:55 CEST] <thebombzen> and pretty unwatchable on a 1080p screen
[05:52:59 CEST] <Hexatona> well, i watch it on my phone
[05:53:07 CEST] <thebombzen> crf 32 is still pretty terrible
[05:53:12 CEST] <mavi> lol
[05:53:33 CEST] <mavi> I've been encoding for a while and find crf 29-30 the threshold of my viewable limits at 480p
[05:54:11 CEST] <mavi> and that's with denoise filters, high encode settings.
[05:54:26 CEST] <Hexatona> well, i used to convert things to a strict 320x240 and 160 kbps bitrate (had a very small screen)   -   and with ffmpeg I could get a muuuch better picture at 640x at CRF 32 for the exact same size.
[05:55:02 CEST] <Hexatona> Personally, i'd go for the 480.  I think you'll get a better bang for your buck there
[05:55:39 CEST] <thebombzen> mavi: you have low standards
[05:55:40 CEST] <mavi> it does seem that at higher resolutions the encoder seems to work more efficiently then at lower ones.
[05:55:55 CEST] <thebombzen> and yes that makes sense
[05:56:05 CEST] <thebombzen> higher resolution content has less detail per pixel
[05:56:05 CEST] <mavi> Nah, for my own self I watch crf 18 videos, but this is for a video streaming
[05:56:08 CEST] <Hexatona> yes, yes I do.  and yes, that's what I've seen as well
[05:56:12 CEST] <thebombzen> so block-based quantization should work better
[05:58:04 CEST] <Fenrirthviti> This is probably a dumb question but it's late and I'm tired and brain fart - simple command to transcode a webm with alpha to avi while preserving the alpha?
[05:58:30 CEST] <Hexatona> oh geez, I've had alpha problems with things and I never really figured it out
[05:58:55 CEST] <Fenrirthviti> webm is vp8
[06:05:46 CEST] <mavi> thebombzen, this is a 14 minute test clip at crf 29, 480p. 29mb. It seems fairly tolerable to me.
[06:06:54 CEST] <mavi> Heres another : http://173.208.133.26/get_video.php?video=26
[06:07:47 CEST] <mavi> woops forgot the other, still gets the point across. 4.4mb for 2 minutes.
[06:09:51 CEST] <mavi> 720p at 29crf looks pretty darn crisp, but at a expense of 2x the file size.
[06:23:13 CEST] <Hexatona> I'm wondering of there's a better way to run this.  Basically, I'm creating videos in bulk with a background image.  I use this command (it's in a bat file)
[06:23:14 CEST] <Hexatona> ffmpeg -y -loop 1 -r 1 -i back.jpg -i "%%~fi" -c:v libx264 -preset veryfast -tune stillimage -crf 32 -c:a aac -b:a 32k -shortest -threads 0 "%%~dpni%.flv"
[06:23:17 CEST] <thebombzen> crf 29 looks like crap no matter what
[06:23:30 CEST] <Hexatona> but sometimes it adds like...  3 minutes onto the end of a video
[06:23:47 CEST] <Hexatona> (the input is mp3s)
[06:24:06 CEST] <thebombzen> what are those %s for
[06:24:29 CEST] <furq> that's batch
[06:24:29 CEST] <Hexatona> something the bat files ned so it picks up relative paths
[06:26:46 CEST] <furq> the workaround for the lengths being fucked up is to use a higher framerate
[06:27:08 CEST] <Hexatona> so, like, 24?
[06:27:16 CEST] <furq> i had to deal with this ages ago and there was some weird solution, but i forget what it was
[06:27:31 CEST] <furq> i normally used 6 because that's the lowest youtube framerate anyway, and that kept the slop down to a couple of seconds
[06:27:46 CEST] <furq> try using different formats as well
[06:28:00 CEST] <Hexatona> here let me give er a shot
[06:28:04 CEST] <furq> maybe either mp4 or mkv works, it's been too long since i dealt with this
[06:28:58 CEST] <Hexatona> well, it's going right on youtube, so flv saves me the time for processing.  But I'll give that a try too
[06:30:07 CEST] <furq> that makes no difference unless you're livestreaming to youtube
[06:30:57 CEST] <furq> also iirc the issue is caused by encoding the audio while muxing
[06:31:15 CEST] <furq> so if you encode separately and then mux that in with -c:a copy it should be correct
[06:32:26 CEST] <Hexatona> Hmmm...  interesting solution...
[06:33:25 CEST] <mavi> if ffmpeg is changing the native framerate from 29.9 to 32, do i have to enable the -vsync 0 to fix this or is there another way to preserve original frame rate. Container is mp4
[06:38:44 CEST] <Hexatona> Ughhh, it's hard to pick.  40x encode speed, or a quarter of that for accurate times...
[06:39:17 CEST] <furq> i take it other containers don't work then
[06:39:36 CEST] <Hexatona> same issue.  Haven't tried the double encoding yet
[06:40:23 CEST] <furq> i take it this is a recent ffmpeg etc
[06:41:07 CEST] <Hexatona> hmmm...  actually when was the last time I upgraded...
[06:42:09 CEST] <Hexatona> 3.1.4 looks like.
[06:42:17 CEST] <Hexatona> let's giver a try
[06:52:53 CEST] <Hexatona> nah, same issue on latest
[08:56:45 CEST] <xtina_> hey guys. i'm having troubles with ALSA buffer overruns, right when I kick off an ffmpeg stream.
[08:57:05 CEST] <xtina_> it was suggested to me that ffmpeg couldn't stream quickly enough to eat up all the audio that had built up as everything was starting up
[08:57:13 CEST] <xtina_> to get around this, i've inserted an mbuffer of size 15Mb into my pipeline
[08:57:21 CEST] <xtina_> so now it goes like this: ALSA recording -> 15Mb mbuffer -> ffmpeg
[08:57:56 CEST] <xtina_> my intent is that, even if ffmpeg isn't streaming that quickly, audio should be eaten from ALSA's buffer in real time and should build up in the mbuffer, which is very big
[08:58:21 CEST] <xtina_> however, i'm still finding that I get alsa over-runs within 10s of starting the stream *upon boot* (it's OK if I manually call the stream while SSHed in)
[08:58:24 CEST] <xtina_> if I take a look at mbuffer
[08:58:32 CEST] <xtina_> it reports that it's 0% full
[08:58:35 CEST] <xtina_> even though the ALSA buffer overran
[08:59:05 CEST] <xtina_> so for some reason, mbuffer isn't acting as a buffer the way I want. i've chatted with some folks in the ALSA room and they think my logic *should* work
[08:59:18 CEST] <xtina_> does anyone have a clue what's wrong? i'm at the end of my rope, you guys are my last hope!
[08:59:44 CEST] <xtina_> my script: http://vpaste.net/tVs4q
[08:59:56 CEST] <xtina_> audio_buffer_usage.txt shows 0% full when the ALSA buffer overruns
[09:00:10 CEST] <xtina_> (I know the mbuffer library works properly because my video mbuffer will start filling up if necessary)
[09:00:46 CEST] <xtina_> why isn't audio accumulating in the mbuffer, why is it overflowing ALSA's buffer?
[09:02:37 CEST] <celyr> xtina_, I'm not sure I'm the right person to help you but I guess it's rec
[09:03:06 CEST] <xtina_> celyr: what do you think is wrong with rec?
[09:03:33 CEST] <BtbN> Why not just grab the audio with ffmpeg? This seems needlessly complex.
[09:03:48 CEST] <celyr> xtina_, I don't think that there is something wrong with rec I think that it can't upkeep
[09:03:50 CEST] <xtina_> BtbN: I can't grab audio with FFMPEG because of an ALSA Bug. ffmpeg ALSA consumes 95% of my Zeros' CPU
[09:03:58 CEST] <xtina_> capturing alsa audio with rec uses 5% CPU
[09:04:12 CEST] <BtbN> Have you reported that bug to ffmpeg?
[09:04:20 CEST] <xtina_> BtbN: https://trac.ffmpeg.org/ticket/6156 i filed this bug i don't think anyone will ever fix it. someone else repro'd it.
[09:04:29 CEST] <xtina_> nobody has ever commented on it
[09:04:52 CEST] <xtina_> celyr: hmm, sorry, what is upkeep?
[09:05:24 CEST] <xtina_> BtbN: i don't think this 'bug" will get fixed because most people don't use ALSA from pi zeros and with a better CPU one wouldn't really care about this.
[09:05:41 CEST] <celyr> xtina_, I meant it can't read the alsa buffer in time
[09:06:06 CEST] <dastan> Hi I need help
[09:06:08 CEST] <xtina_> celyr: oh, interesting!
[09:06:09 CEST] <dastan> {"-i", src.getAbsolutePath().trim(),"-crf", "30","-threads", "8",                         "-filter:v", "setpts=0.5*PTS","-preset", "ultrafast", "-strict", "-2","-an", dest.getAbsolutePath()};
[09:06:10 CEST] <celyr> xtina_, try to run the rec alone and see if the buffer get overrun anyway, or try to give it a lower nice
[09:06:31 CEST] <dastan> I am using this commnd to make fast motion but its takes 20sec and the video is 15sec
[09:06:33 CEST] <xtina_> celyr: i can confirm that rec run alone does sometimes overflow the alsa buffer
[09:06:37 CEST] <xtina_> so you may be onto something!
[09:06:43 CEST] <dastan> how can I reduce the processing time?
[09:06:50 CEST] <xtina_> what is a lower nice?
[09:07:10 CEST] <celyr> xtina_, https://linux.die.net/man/8/renice
[09:07:36 CEST] <dastan> {"-i", src.getAbsolutePath().trim(),"-crf", "30","-threads", "8", "-filter:v", "setpts=0.5*PTS","-preset", "ultrafast", "-strict", "-2","-an", dest.getAbsolutePath()};
[09:07:49 CEST] <xtina_> btw, i've tried a bunch of other libraries for ALSA recording, like arecord -> LAME, but they hog tons of CPU and i think it's partially b/c arecord captures raw audio and LAME then has to read it and encode it. SOX/rec does capture AND encode in 1 step so there's no read/write to file step. hence it's the most CPU efficient <5%
[09:08:40 CEST] <xtina_> celyr: fascinating
[09:09:00 CEST] <xtina_> i think you might be right. the only logical explanation is that rec can't keep up. because the only thing in between ALSA and my mbuffer is rec itself
[09:09:02 CEST] <celyr> xtina_, by default rec uses an input buffer of 8192 try to play with it.
[09:09:12 CEST] <dastan> anyone?
[09:09:21 CEST] <xtina_> celyr: great idea, i'll try it now!
[09:09:35 CEST] <furq> dastan: if the source is h264 then you can remux it at a different framerate
[09:09:39 CEST] <celyr> xtina_, maybe with a larger buffer of rec you can get rid of mbuffer
[09:09:51 CEST] <xtina_> i had no idea rec even had a buffer
[09:10:04 CEST] <xtina_> i'm reading the renice page now, wasn't familiar
[09:10:15 CEST] <dastan> @furq how? src is h264
[09:10:19 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavdevice/alsa_dec.c#L112
[09:10:22 CEST] <furq> http://vpaste.net/1pjAJ
[09:10:24 CEST] <furq> like that
[09:10:31 CEST] <furq> replace 30 with fps*2
[09:10:35 CEST] <BtbN> I don't see how this could end up using a lot of CPU, unless alsa itself does busy waiting
[09:10:56 CEST] <dastan> thanks furq I will try now
[09:10:57 CEST] <furq> or er
[09:10:59 CEST] <furq> fps/2 rather
[09:11:08 CEST] <furq> fps*2 will double the speed
[09:11:55 CEST] <dastan> ya I am doubling the speed
[09:12:08 CEST] <dastan> "setpts=0.5*PTS", is this correct?
[09:12:23 CEST] <furq> yeah nvm i can't read
[09:12:29 CEST] <furq> you can't use setpts without reencoding thouhg
[09:12:51 CEST] <furq> that paste is all you need
[09:12:56 CEST] <dastan> oh
[09:13:00 CEST] <dastan> ok let me try
[09:27:01 CEST] <dastan> furq got this output progress : /storage/emulated/0/Movies/tmp.264: Invalid data found when processing input
[09:27:20 CEST] <dastan> when firing this ffmpeg [-hide_banner, -r, 60, -i, /storage/emulated/0/Movies/tmp.264, -i, /storage/emulated/0/DCIM/Camera/TestVideo.mp4, -c, copy, -map, 0:v, -map, 1:a, /storage/emulated/0/Movies/TestVideo_FAST_MOTION.mp4]
[09:30:26 CEST] <dastan> Hi anyone there?
[09:31:34 CEST] <xtina_> celyr: initial tests make it appear like increasing rec's buffer was the solution!! i need to try a few more times to make sure it works properly, but so far i haven't seen overruns. i'll report back soon, still testing
[09:31:44 CEST] <dastan> this cmd I am using to make fast motion https://pastebin.com/QLqNKV3U
[09:31:50 CEST] <dastan> furq
[09:32:34 CEST] <celyr> xtina_, I'm happy that you are figuring out how to solve it
[09:33:35 CEST] <dastan> hello?
[09:37:38 CEST] <dastan> how can I reduce the processing time for 15sec video? right its taking 20 sec to make it fast motion
[09:41:21 CEST] <dastan> give me mantra to solve the problem
[09:48:18 CEST] <xtina_> @celyr: bad news got another alsa buffer overrun, at the 1:24 mark this time
[09:48:29 CEST] <xtina_> ALSA said 1.86M was output at that point
[09:48:37 CEST] <xtina_> and my rec buffer is 2MB, so i don't know how that could happen
[09:48:45 CEST] <xtina_> even if ffmpeg hadn't taken *any* of it, rec should have fit it in its buffer, i thought
[09:48:59 CEST] <xtina_> i'm setting it this way: export SOX_OPTS="--input-buffer 2000000"
[09:49:22 CEST] <celyr> xtina_, have you tried to renice it ?
[09:49:34 CEST] <celyr> or just to start it with like -15
[09:49:41 CEST] <xtina_> hmm
[09:49:51 CEST] <xtina_> wouldn't i want to renice it to a positive priority? -15?
[09:50:05 CEST] <xtina_> i haven't tried renice yet. still can't wrap my head around how there was an alsa overrun when the total amount of audio < size of rec buffer
[09:52:17 CEST] <celyr> xtina_, negative means higher priority
[09:54:36 CEST] <celyr> xtina_, Maybe rec was still waiting in the queue of processes to get executed so it couldn't get anything from the alsa buffer... in time
[09:55:48 CEST] <xtina_> celyr: interesting. if that happens, then making the rec buffer even bigger than 2mb would be ineffective. so far my entire script takes <20% CPU so i guess i have some to space, i'll try -10
[09:56:22 CEST] <celyr> xtina_, you can make the rec buffer wider as you like but this will help only to avoid the alsa buffer to get not completely emtpied when rec runs it's read
[09:56:42 CEST] <celyr> xtina_, but at some point you have to make the rec reads more frequents or make the alsa buffer wider.
[09:56:56 CEST] <xtina_> i can't change the alsa buffer, i think, because it's hardware constrained to peanuts. 65k
[09:57:43 CEST] <celyr> xtina_, then what can help you is an higher priority of rec IDK if your raspberry is multicore
[09:57:52 CEST] <celyr> xtina_, but you can even dedicate a core to it
[09:57:56 CEST] <xtina_> celyr, it's single core, pi zero. i'll increase pri and tell u how itworks
[09:58:36 CEST] <celyr> xtina_, also there are plenty of guides out there on how to make linux more "real time" i guess those guides can help you in this situation
[09:59:09 CEST] <celyr> That said maybe you will need just more power :)
[10:00:18 CEST] <xtina_> hmm, fair enough, but i'm using so little of my CPU, it feels lke the zero should be strong enough to record audio as quickly as ALSA captures it
[10:00:33 CEST] <xtina_> if it can handle realtime livestreaming to the internet just fine
[10:06:54 CEST] <xtina_> celyr: i tried setting niceness but it doesn't register
[10:07:15 CEST] <xtina_> http://vpaste.net/wp5Pp
[10:07:22 CEST] <xtina_> i watched top and rec has a niceness of 0..
[10:07:46 CEST] <celyr> xtina_, are you running it as root ?
[10:08:30 CEST] <xtina_> nope
[10:08:37 CEST] <xtina_> it's just in a shell script i'm running as user
[10:08:55 CEST] <celyr> xtina_, negative nices are only for root
[10:09:04 CEST] <xtina_> oh
[10:09:08 CEST] <xtina_> ok, let me retry
[10:10:00 CEST] <celyr> xtina_, if you want to run it as user you can play with sudo and things
[10:10:22 CEST] <xtina_> sounds good
[10:18:11 CEST] <xtina_> celyr: well for some reason inserting nice causes rec to fail:
[10:18:29 CEST] <xtina_> here's rec working: http://vpaste.net/hNnwJ
[10:18:47 CEST] <xtina_> here's it not working with nice: http://vpaste.net/hlahz
[10:18:51 CEST] <xtina_> oh, i suspect it's because of the addition of sudo
[10:19:14 CEST] <celyr> xtina_, you have to take care of the arguments
[10:19:26 CEST] <xtina_> rec relies on some settings i've exported as a user: export AUDIODEV=mic_mono etc.
[10:20:35 CEST] <celyr> xtina_, so this is the problem
[10:22:03 CEST] <xtina_> hmm
[10:22:07 CEST] <xtina_> do i need to export those settings globally?
[10:22:11 CEST] <xtina_> i tried sudo export...
[10:22:13 CEST] <xtina_> but that isn't right
[10:30:58 CEST] <celyr> xtina_, just for the test maybe you can run everything as root
[10:31:14 CEST] <celyr> xtina_, if this solves your issue then you can fine tune it
[10:36:08 CEST] <celyr> xtina_, that said if you look at https://linux.die.net/man/1/rec I think you have to use --input-buffer
[10:40:12 CEST] <DemoniacMilk> morning
[10:40:33 CEST] <DemoniacMilk> if i want to build ffmpeg inlcuding x264, where do i place the x264 library file that i have compiled?
[10:42:09 CEST] <BtbN> Whereever you like
[10:42:31 CEST] <DemoniacMilk> hm so i guess i have to add the path to the configuration?
[10:42:52 CEST] <BtbN> define an install prefix, make install it, and then define PKG_CONFIG_PATH accordingly
[10:43:09 CEST] <BtbN> That works most easily, specially if you build multiple dependencies
[10:43:19 CEST] <DemoniacMilk> sounds good, thanks
[10:46:30 CEST] <xtina> celyr: sorry i disconnected
[10:46:38 CEST] <xtina> i'm still struggling to set nice -15, haha
[10:46:43 CEST] <xtina> this doesn't work: sudo -u pi /usr/bin/rec -c 1 -V3 -r 22050 -b 32 -t mp3 /tmp/temp_audio.mp3
[10:46:46 CEST] <xtina> even tho i am running as pi
[10:47:02 CEST] <xtina> http://vpaste.net/CQT6C
[10:47:06 CEST] <celyr> <celyr> xtina_, just for the test maybe you can run everything as root
[10:47:06 CEST] <celyr> <celyr> xtina_, if this solves your issue then you can fine tune it
[10:47:11 CEST] <celyr> <celyr> xtina_, that said if you look at https://linux.die.net/man/1/rec I think you have to use --input-buffer
[10:47:15 CEST] <DemoniacMilk> BtbN hey i nevers the --prefix before but thats actually really handy :D
[10:47:28 CEST] <DemoniacMilk> *used
[10:47:45 CEST] <xtina> celyr: i can't run everything as root, i've set env variables as user
[10:47:49 CEST] <xtina> so they're only recognized if i run 'rec' as user
[10:48:03 CEST] <celyr> xtina, set them to root ? :)
[10:48:03 CEST] <xtina> and i haven't found a way to set env variables as root (quick googling, lol)
[10:48:20 CEST] <xtina> http://unix.stackexchange.com/questions/72934/how-do-i-start-a-process-with-a-nice-value-of-20-and-not-give-it-root-privilege
[10:48:22 CEST] <BtbN> same was as you do as a user?
[10:48:23 CEST] <xtina> these guys had same q as me
[10:48:31 CEST] <BtbN> *way
[10:48:31 CEST] <xtina> he says, this works
[10:48:32 CEST] <xtina> -sudo nice -n -20 sudo -u myusername matlab
[10:48:42 CEST] <xtina> but sudo -u myusername <cmd> doesn't work
[10:48:54 CEST] <xtina> i thought sudo u myusername ran the cmd as myusername
[10:48:54 CEST] <nido> sudo renice -n -20 pid #?
[10:49:16 CEST] <xtina> nido: i can't really, it's part of a bash script
[10:49:26 CEST] <xtina> i can do that as a one timer on cmd line, works fine
[10:49:29 CEST] <celyr> xtina, just to try use renice
[10:49:31 CEST] <xtina> but it needs to be tested and run in bash script
[10:49:41 CEST] <nido> xtina: yes; but the first sudo is executed as root and as root you execute nice which executes sudo to run matlab as myusername
[10:50:01 CEST] <xtina> is there no way to execute nice as root but the actual cmd as a user?
[10:50:03 CEST] <xtina> @___@
[10:50:11 CEST] <BtbN> that construct probably looses a bunch of important env vars on the way
[10:50:20 CEST] <BtbN> like, DISPLAY
[10:50:57 CEST] <xtina> bleaurgh
[10:50:58 CEST] <nido> matlab & sudo renice -n -20 $!
[10:51:11 CEST] <xtina> that nice's the matlab command?
[10:51:16 CEST] <xtina> nido: ^^
[10:52:05 CEST] <xtina> nido: looks great
[10:52:09 CEST] <xtina> seems to work *thumbs up*
[10:52:12 CEST] <nido> end with 'fg' if yuo want bash to block until matlab is done
[10:52:38 CEST] <nido> basically; it says 'run matlab in the background', 'sudo renice the last backgrounded command'
[10:54:06 CEST] <DemoniacMilk> hm so i think i havent understood how to add libx264 to ffmpeg
[10:54:44 CEST] <DemoniacMilk> i built x264 with --prefix=~/compiled_libs, then make install
[10:55:20 CEST] <DemoniacMilk> and added --pkgconfigdir=~/compiled_libs to the config of ffmpeg
[10:55:49 CEST] <DemoniacMilk> still says cant find libx264
[10:56:10 CEST] <DemoniacMilk> is --pkgconfigdir not what i was supposed to use?
[10:57:46 CEST] <BtbN> That's where ffmpeg installs its own .pc files.
[11:02:06 CEST] <DemoniacMilk> ive read through the commands listed in ffmpeg --help
[11:02:31 CEST] <DemoniacMilk> didnt recognize one to tell the config to include some additional path for libs
[11:02:33 CEST] <BtbN> Like I set, you just set PKG_CONFIG_PATH
[11:02:39 CEST] <BtbN> *said
[11:02:56 CEST] <DemoniacMilk> is that like
[11:03:02 CEST] <DemoniacMilk> some system variable?
[11:03:12 CEST] <BtbN> It's the env var pkg-config uses
[11:03:18 CEST] <DemoniacMilk> ah okay
[11:03:21 CEST] <DemoniacMilk> sorry, im new to all of this
[11:03:24 CEST] <BtbN> unless I typoed it. Not entirely sure about the underscores and stuff
[11:03:46 CEST] <DemoniacMilk> so i got no clue how to set it :P
[11:04:33 CEST] <BtbN> depends entirely on your shell
[11:04:38 CEST] <BtbN> most of them use export
[11:05:03 CEST] <DemoniacMilk> oh ye, now that you mentioned it, i think ive used that before
[11:14:07 CEST] <xtina___> celyr: well the sad news is i set nice -15 for rec and it still overran after 40s
[11:14:12 CEST] <xtina___> so now i have a new hypothesis
[11:14:17 CEST] <xtina___> maybe mp3 encoding is too slow
[11:14:22 CEST] <xtina___> so rec can't encode as fast as it's capturing raw audio
[11:14:45 CEST] <xtina___> i don't know if raw audio would get kept in rec's buffer if encoding is too slow. if yes, everything should be OK. but if not, that would be a problem
[11:16:37 CEST] <xtina___> hmm.. thoughts?
[11:17:39 CEST] <celyr> xtina___, I think that your raspberry has just not enough resources to cope with this kind of streams
[11:18:18 CEST] <xtina___> celyr: just hear me out. i only get alsa buffer overruns in the 1st 1-2min of streaming, if that DOESN"T happen, i can stream happily forever
[11:18:36 CEST] <xtina___> in the first min of streaming i guess things are slowed as ffmpeg is starting up, and audio gets backed up
[11:18:43 CEST] <xtina___> i just can't comprehend how i can't deal with this
[11:20:09 CEST] <celyr> xtina___, maybe in ##linux they can help you
[11:20:16 CEST] <celyr> xtina___, I've run out of competence
[11:20:34 CEST] <xtina___> celyr: yea, that sounds good. btw, thanks for all the help. you had some great ideas
[11:23:06 CEST] <xtina___> celyr: btw i just noticed i set rec's input_buffer
[11:23:11 CEST] <xtina___> i'm going to try setting rec's buffer
[11:23:24 CEST] <xtina___> input buffer only applies to input, buffer applies to input, effects, processing, and output apparently
[11:23:28 CEST] <xtina___> it could be what i need
[11:48:13 CEST] <smarty817> hi there
[11:48:39 CEST] <smarty817> any way to apply ascii art effect on a live stream thru ffmpeg?
[11:51:00 CEST] <DemoniacMilk> i still didnt figure out how to tell ffmpeg where libx264 is located >.<
[11:51:27 CEST] <smarty817> :/
[11:52:23 CEST] <DemoniacMilk> i cant even find the error message in the config script
[11:52:51 CEST] <DemoniacMilk> to check what paths/environment variables might be used to check
[11:54:29 CEST] <smarty817> alright, can --enable-libcaca be applied to a livestream?
[11:56:56 CEST] <durandal_1707> smarty817: nope
[11:57:24 CEST] <DemoniacMilk> ah i found it https://pastebin.com/uWYaMTAe
[11:57:43 CEST] <DemoniacMilk> this should probably tell me what environment variables are used?
[11:58:01 CEST] <smarty817> dammit
[11:58:12 CEST] <smarty817> any other way to convert it to ascii then?
[12:00:52 CEST] <furq> you could output to an x11 window and then capture that with xcbgrab
[12:02:17 CEST] <smarty817> ehh...no, i'm outputting the stream straight to the player
[12:02:21 CEST] <smarty817> html5 player
[12:11:27 CEST] <debianuser> smarty817: http://stariocek.asuscomm.com/watch-ascii-libcaca.html ?
[12:15:03 CEST] <DemoniacMilk> is the pkg-config created by the config script to then be used during the build process?
[12:17:35 CEST] <DemoniacMilk> my cross compiling toolchain does not provide --prefix-pkg-config
[12:17:52 CEST] <xtina___> celyr: well, i've changed "sox --input-buffer .." to "sox --buffer .." and that did seem to help
[12:17:58 CEST] <DemoniacMilk> nice to hear!
[12:18:02 CEST] <xtina___> the majority of my tests since have not had any buffer overruns. but I *did* see one
[12:18:08 CEST] <xtina___> (i have renice -20 on rec now too)
[12:18:20 CEST] <xtina___> the fact that i saw one means it's still possible..
[12:18:42 CEST] <xtina___> it did happen fairly late, but my rec buffer is 20mb, which is pretty big. i'll keep investigating to see if anything else can be done
[12:19:19 CEST] <xtina___> i don't think rec buffer needs to be bigger. i saw an overrun at 2:30, and i'm going at 22050khz/32bit/1chanel which amounts to 5mb of raw audio per minute, so no way to fill a 20mb buffer in 2.5 mins
[12:19:39 CEST] <xtina___> i guess it has to be some kind of priority thing again, like you said
[12:21:52 CEST] <celyr> xtina___, a fully preemptive kernel might help
[12:22:09 CEST] <celyr> xtina___, but I'm out of that business
[12:22:28 CEST] <xtina___> haha, like you suggested, i'll consult with some linux gurus if that's what needs to be done
[12:22:41 CEST] <xtina___> just wanted to let you know things are a bit better with the sox config..
[12:22:49 CEST] <celyr> nice :)
[12:23:43 CEST] <smarty817> @debianuser yes
[14:24:26 CEST] <DemoniacMilk> if ffmpeg compiled well, but crashes saying
[14:24:27 CEST] <DemoniacMilk> error while loading shared libraries: libavdevice.so.57: cannot open shared object file: No such file or directory
[14:24:35 CEST] <DemoniacMilk> what might i have screwed up?
[14:25:28 CEST] <oerg866> hello again
[14:25:47 CEST] <oerg866> can someone tell me how the rtmp listen option works, I cannot seem to find proper documentation for it
[14:26:09 CEST] <oerg866> (does it even do what I think it does? I'd like to avoid having to install a standalone rtmp server just to receive and transcode a single stream)
[14:29:16 CEST] <microchip_> DemoniacMilk: pastebin your configure options
[14:30:19 CEST] <DemoniacMilk> config is really short, ill jsut paste it here:
[14:30:21 CEST] <DemoniacMilk> ./configure --prefix=$HOME/compiled_libs_x86 --enable-libx264 --enable-gpl --enable-ffmpeg
[14:30:31 CEST] <DemoniacMilk> oh ignure the last element
[14:31:12 CEST] <microchip_> DemoniacMilk: you need to add $HOME/compiled_libs_x86/lib to your PATH
[14:31:31 CEST] <DemoniacMilk> oh
[14:31:39 CEST] <DemoniacMilk> im just wondering if i change that to /usr
[14:31:52 CEST] <DemoniacMilk> it should all be okay by default?
[14:32:00 CEST] <microchip_> if you set it to /usr, it will be fine since it's in PATH
[14:32:16 CEST] <microchip_> you can also use /usr/local
[14:32:36 CEST] <DemoniacMilk> whats the difference?
[14:33:14 CEST] <microchip_> DemoniacMilk: /usr is not recommended to be used by self-compiling stuff since it may contain ffmpeg libs installed from packages
[14:33:37 CEST] <DemoniacMilk> good point
[14:33:42 CEST] <DemoniacMilk> thanks
[14:34:03 CEST] <microchip_> so use --prefix=/usr/local and your libs will be in /usr/local/lib
[14:34:41 CEST] <DemoniacMilk> check!
[14:34:51 CEST] <DemoniacMilk> (after make install i guess)
[14:34:57 CEST] <microchip_> yes
[14:35:19 CEST] <DemoniacMilk> alright thank you
[14:47:05 CEST] <Xys> Hello, I would like to add an image to the end of a video. The image would last like 3 seconds. Is it in theory possible to do it without re-encoding everything ? And if yes, is it possible to do with ffmpeg ?
[14:47:31 CEST] <xtina___> ceryl: i've decided to switch to arecord and lame. i've got a buffer in between them in case encoding can't keep up with raw audio capture. and i've got a buffer in between lame and ffmpeg lol
[14:47:37 CEST] <xtina___> here's my monster of a script if you are curious: http://vpaste.net/vNOIl
[14:48:05 CEST] <xtina___> i've managed to stream at a bitrate 2x what my home router supports (so with buffering and less than realtime ffmpeg speeds) without dropping any audio or video packets or overrunning for 10mins so far
[14:49:55 CEST] <DemoniacMilk> test
[14:50:13 CEST] <oerg866> odd, zeranoe builds dont have it
[14:50:14 CEST] <oerg866> "Unrecognized option 'rtmp_listen'."
[14:52:35 CEST] <DemoniacMilk> ./ffmpeg: error while loading shared libraries: libavdevice.so.57: cannot open shared object file: No such file or directory
[14:52:44 CEST] <DemoniacMilk> where would this be located?
[14:52:50 CEST] <DemoniacMilk> if it existed?
[14:56:47 CEST] <BtbN> oerg866, zeranoe builds with librmpt I guess.
[14:56:50 CEST] <BtbN> *rtmp
[14:59:56 CEST] <microchip_> DemoniacMilk: /usr/local/lib
[15:01:22 CEST] <microchip_> Xys: you will have to re-encode
[15:01:54 CEST] <furq> you can do that without reencoding
[15:02:09 CEST] <furq> https://trac.ffmpeg.org/wiki/Concatenate#demuxer
[15:02:16 CEST] <microchip_> ah
[15:02:47 CEST] <DemoniacMilk> urm what does that link tell me?
[15:03:00 CEST] <DemoniacMilk> ou wat, there was another name in front of that, nvm
[15:03:06 CEST] <microchip_> DemoniacMilk: it's not for you but for Xys
[15:04:23 CEST] <DemoniacMilk> hm /usr/local/lib does only have libavdevice.a, but not .so.57
[15:04:56 CEST] <Xys> I will have to re-encode everything ? Even if I want to add 3 secs of image to a 4K video ?
[15:05:01 CEST] <Xys> Thanks for the answer !
[15:05:10 CEST] <microchip_> DemoniacMilk: you don't really need shared libs, provided you don't intend to link to them. you can configure in such case with --disable-shared
[15:05:17 CEST] <Xys> thanks microchip_ *
[15:05:21 CEST] <furq> Xys: no
[15:05:23 CEST] <DemoniacMilk> i want to use libx264 tho
[15:05:36 CEST] <DemoniacMilk> i thought id do that with a shared lib?
[15:05:55 CEST] <DemoniacMilk> (im building both ffmpeg and libx264)
[15:05:59 CEST] <microchip_> DemoniacMilk: no problem. --disable-shared only disabled ffmpeg's shared libs, it has no effect on others
[15:06:08 CEST] <DemoniacMilk> ah
[15:08:16 CEST] <Xys> furq : what do you mean ? I can concat an image to a video with the concat demuxer ?
[15:08:38 CEST] <furq> create a 3 second video with the same specs as the video you want to concat it to
[15:08:41 CEST] <furq> then concat them
[15:09:28 CEST] <Xys> Okay thank I will try this
[15:10:26 CEST] <DemoniacMilk> hm still says it cant open the shared object file, although i used --disable-shared
[15:10:54 CEST] <furq> which shared object file
[15:11:04 CEST] <microchip_> where did you install the ffmpeg binary?
[15:11:32 CEST] <DemoniacMilk> test
[15:11:50 CEST] <DemoniacMilk> . /usr/local is the --prefix
[15:11:56 CEST] <DemoniacMilk> (without .
[15:12:18 CEST] <DemoniacMilk> libavdevices was not found
[15:12:41 CEST] <DemoniacMilk> config is: ./configure --disable-shared --disable-everything --enable-libx264 --enable-gpl
[15:12:55 CEST] <furq> you're running the wrong build then
[15:12:58 CEST] <DemoniacMilk> (trying to minimize build time)
[15:13:01 CEST] <microchip_> did you do make install
[15:13:04 CEST] <furq> --disable-everything won't even build libavdevice
[15:13:31 CEST] <DemoniacMilk> hm can i savely purge /usr/local ?
[15:13:35 CEST] <furq> you tell me
[15:14:31 CEST] <DemoniacMilk> as in: this is not a folder other programs might have put requirements in?
[15:14:38 CEST] <microchip_> no
[15:14:41 CEST] <furq> that depends on the distro
[15:14:46 CEST] <furq> and also whether you've put anything else in there
[15:15:01 CEST] <DemoniacMilk> make uninstall then?
[15:15:06 CEST] <furq> there is no such thing
[15:15:52 CEST] <DemoniacMilk> as uninstall?
[15:16:10 CEST] <furq> oh maybe ffmpeg does have that
[15:16:16 CEST] <furq> i wouldn't expect it to work properly though
[15:16:21 CEST] <furq> there's a reason that's not usually a thing
[15:17:15 CEST] <microchip_> DemoniacMilk: run this ./configure --prefix=/usr/local --disable-shared --enable-libx264 --enable-gpl
[15:17:40 CEST] <DemoniacMilk> ye thast whati had before i added --disable-everything
[15:17:42 CEST] <DemoniacMilk> but ill do that
[15:17:47 CEST] <furq> add --extra-ldflags=static if you want static libx264
[15:17:50 CEST] <furq> er
[15:17:55 CEST] <furq> --extra-ldflags=-static
[15:18:32 CEST] <DemoniacMilk> what exactly does "static libx264" mean?
[15:19:03 CEST] <DemoniacMilk> that ill be placing some libx264 library inside the ffmpeg directory or something?
[15:19:11 CEST] <furq> inside the ffmpeg binary
[15:19:29 CEST] <DemoniacMilk> ah so it basically includes everything in one file?
[15:19:32 CEST] <furq> yes
[15:19:40 CEST] <Xys> What is the difference between "Constrained Baseline" and "Baseline" profiles please ?
[15:19:40 CEST] <furq> if you use the system libx264 and it gets updated then it'll probably break ffmpeg
[15:19:57 CEST] <furq> if you link to the shared lib
[15:20:11 CEST] <furq> it's less hassle to just static link everything
[15:20:15 CEST] <microchip_> DemoniacMilk: if too much effort -> https://www.johnvansickle.com/ffmpeg/
[15:20:26 CEST] <microchip_> ready to ruyn
[15:20:38 CEST] <DemoniacMilk> im aiming to cross compile it
[15:20:49 CEST] <DemoniacMilk> what i can do successfuly
[15:20:58 CEST] <DemoniacMilk> just didnt add libx264 s ofar
[15:21:27 CEST] <DemoniacMilk> so im figuring out how to add libx264 on my host system to then add that to my cross compiled version
[15:21:41 CEST] <furq> even more reason to static link libx264 then
[15:22:00 CEST] <DemoniacMilk> but i see theres an armhf version too
[15:22:07 CEST] <furq> although yeah just use that
[15:22:08 CEST] <DemoniacMilk> still, i started this, want to finish it now :D
[15:22:18 CEST] <furq> there's no reason not to use that if you're not using a system with hwaccel
[15:22:38 CEST] <DemoniacMilk> it only has a neon coprocessor
[15:22:44 CEST] <DemoniacMilk> not sure if that may be called hwaccel
[15:22:47 CEST] <furq> it can't
[15:23:20 CEST] <furq> also neon isn't a coprocessor, it's just an architecture extension for the cpu
[15:23:24 CEST] <furq> like sse/avx on x86
[15:24:53 CEST] <furq> but that's autodetected at runtime anyway
[15:25:09 CEST] <DemoniacMilk> ah okay
[15:25:29 CEST] <furq> actual hwaccel stuff like on the rpi doesn't work with the static builds for some dumb linker reason i can't remember the specifics of
[15:25:35 CEST] <DemoniacMilk> hm, its a bit sad that i spent some days on tryng to get this to run (im new to absolutely everything including linux)
[15:25:50 CEST] <DemoniacMilk> and now i just take a static build :D
[15:26:01 CEST] <furq> what distro are you on
[15:26:09 CEST] <DemoniacMilk> host or target?
[15:26:11 CEST] <furq> host
[15:26:17 CEST] <DemoniacMilk> lubuntu 16.04
[15:27:39 CEST] <furq> afaik that has all the stuff from debian testing which makes cross compiling incredibly easy
[15:27:48 CEST] <furq> http://packages.ubuntu.com/xenial/crossbuild-essential-armhf
[15:27:57 CEST] <DemoniacMilk> i got a linux SDK from texas instruments
[15:28:25 CEST] <furq> you pretty much just need that and then dpkg --add-architecture armhf; apt-get install libx264:armhf
[15:28:36 CEST] <furq> or libx264-dev:armhf rather
[15:28:52 CEST] <furq> no fucking about with insane toolchains and building all the dependencies yourself
[15:28:56 CEST] <DemoniacMilk> i already built ffmpeg for the target and streamed a video to the host
[15:28:57 CEST] <DemoniacMilk> hm
[15:30:08 CEST] <DemoniacMilk> i had no idea :D
[15:30:25 CEST] <furq> yeah all the cross compilation guides on the internet were written by people who have no idea
[15:32:33 CEST] <DemoniacMilk> okay that urm .. was quite some unexpected input
[15:32:55 CEST] <DemoniacMilk> ill try the static lib first
[15:33:09 CEST] <furq> the static build should work fine
[15:33:30 CEST] <furq> but if you want to add some libs that aren't included then use the ubuntu toolchain and apt multiarch
[15:34:08 CEST] <DemoniacMilk> hm i just read out some info on ffmpeg from the static build
[15:34:26 CEST] <DemoniacMilk> i guess it doesnt include any linker info because thats what static builds dont neet?
[15:34:28 CEST] <DemoniacMilk> *need
[15:34:34 CEST] <furq> if you mean ldd then yeah
[15:34:47 CEST] <DemoniacMilk> interesting
[15:35:43 CEST] <DemoniacMilk> i guess it does not include ffplay as ffplay accesses system ressources like display etc and cant be static?
[15:36:00 CEST] <DemoniacMilk> or am i completely wrong on that?
[15:36:37 CEST] <furq> shrug
[15:36:49 CEST] <furq> ask relaxed, they're his builds
[15:53:32 CEST] <relaxed> DemoniacMilk: yes
[16:01:59 CEST] <DemoniacMilk> aight thanks
[16:03:06 CEST] <Xys> I have 2 videos, I've tried to re-encode the second to have the same specs than the first one
[16:03:26 CEST] <Xys> Can you guys tell me what do you think please ? :
[16:03:43 CEST] <Xys> Video 1 : Video: h264 (Baseline) (avc1 / 0x31637661), yuv420p, 1696x848, 37741 kb/s, 29.97 fps, 29.97 tbr, 90k tbn, 180k tbc (default)
[16:03:59 CEST] <Xys> Video 2 : Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuv420p, 1696x848 [SAR 1:1 DAR 2:1], 1118 kb/s, 30 fps, 30 tbr, 90k tbn, 60 tbc (default)
[16:04:20 CEST] <Xys> When I concat those 2 videos with the concat demuxer, it does not work
[16:04:48 CEST] <Xys> I see that the "tbc" differs
[16:04:55 CEST] <alexpigment> Xys: if you use the concat filter rather than the concat demuxer, you can re-encode the whole thing at once
[16:05:14 CEST] <Xys> Thing is I don't want to re-encode video 1 cause its really big :/
[16:05:14 CEST] <kepstin> Xys: well, the framerate overall differs, 30 vs 30/1.001
[16:06:31 CEST] <alexpigment> getting the general specs to be the same should be easy, however i'm not sure what sets to tbc value - maybe someone else has more info
[16:07:14 CEST] <kepstin> Xys: what container are you using?
[16:07:29 CEST] <kepstin> it looks like mpeg-ts based on the 90k tbn
[16:08:00 CEST] <Xys> mp4
[16:08:19 CEST] <kepstin> also, you'll have to be precise about what exactly "does not work" means
[16:08:34 CEST] <Xys> Are these infos important also ? : major_brand     : mp42, minor_version   : 0, compatible_brands: isommp42
[16:09:24 CEST] <Xys> By does not work I mean I have this in the log :Non-monotonous DTS in output stream 0:0; previous: 3597529, current: 1421422; changing to 3597530. This may result in incorrect timestamps in the output fil
[16:09:39 CEST] <Xys> And the result video (from the concat demuxer) does not play on VLC
[16:10:32 CEST] <Xys> Video 1 has mp42, isommp42 while Video2 has isom, isomiso2avc1mp41
[16:10:37 CEST] <alexpigment> tbc values aside, this is how to mimic the specs of the first video with the second one:
[16:10:40 CEST] <Xys> Maybe that's why they are not compatible ?
[16:10:43 CEST] <alexpigment> -i [infile] -c:v libx264 -profile:v baseline -b:v 37741000 -r 30000/1001 -c:a copy [outfile]
[16:11:48 CEST] <kepstin> Xys: that one log message is fine, you'll get that at the timestamp discontinuity between the two files, but it would be helpful if you can pastebin the complete output
[16:13:19 CEST] <Xys> I get that log a lot actually
[16:13:22 CEST] <Xys> Okay gonna post the log
[16:13:51 CEST] <Xys> Huh there are maybe like 100 lines of "DTS" errors, I don't want to spam the chat
[16:14:03 CEST] <kepstin> Xys: that's why I said to use a pastebin
[16:14:13 CEST] <Xys> Oh sorry okay thanks !
[16:14:55 CEST] <DemoniacMilk> holy ... x264 encoding seems to require WAY more computing power than mpeg2 or mpeg4, is that correct?
[16:15:30 CEST] <kepstin> DemoniacMilk: depends on the settings you're using with x264 - but in general, it is a more complex format, so yes
[16:15:47 CEST] <Xys> Here's the link : https://pastebin.com/8HG9QXjz
[16:15:51 CEST] <DemoniacMilk> i guess its no suitable for software encoding on an embedded device then :'D
[16:16:09 CEST] <kepstin> DemoniacMilk: x264 with fast settings should need less compute power than mpeg2 with slow settings, while looking similar quality, i bet
[16:16:30 CEST] <DemoniacMilk> ou didnt trry the presets yet, thanks for briging that to my attention
[16:17:54 CEST] <Xys> alexpigment, kepstin, fflogger : pasted the concat demuxer command above, it this what you expected ? Thanks a lot again
[16:17:54 CEST] <kepstin> DemoniacMilk: default is 'medium'
[16:18:20 CEST] <kepstin> Xys: so both input files are .mp4? can you post the concat.txt too?
[16:19:04 CEST] <kepstin> what what do you mean by "doesn'y play in vlc"? does the file not play at all? does it stop partway through?
[16:21:01 CEST] <Xys> kepstin : yes, both are .mp4, concat file content : file '/Users/myname/Desktop/test/video1.mp4' file '/Users/myname/Desktop/test/video2.mp4'
[16:21:27 CEST] <DemoniacMilk> i changed to ultrafast, device managed to encode ~20fps
[16:22:02 CEST] <DemoniacMilk> what is pretty okay, but then the data rate (i plan to transfer the video over a modem) is .. a bit too high :(
[16:22:23 CEST] <Xys> kepstin : It plays, but it get frozen when then 2nd video starts
[16:22:42 CEST] <kepstin> Xys: right, so probably a timestamp issue then. hmm.
[16:24:39 CEST] <kepstin> Xys: the first thing to try is fixing the framerate on the second video so they're both 30000/1001 fps
[16:33:58 CEST] <Xys> That's what I've done, they are both 29.97 now, but the problem persists
[16:34:08 CEST] <DemoniacMilk> is there an overview of different containers?
[16:34:14 CEST] <DemoniacMilk> like .. pros and cons?
[16:35:01 CEST] <Xys> kepstin, one video is taken by a camera, the other one is a video I create from an image
[16:35:18 CEST] <Xys> I want to concat a video to an image basically..
[16:35:56 CEST] <kepstin> Xys: hmm. once they're both the same framerate, you might want to try using the input option "-r 30000/1001", that might cause it to rewrite the timestamps to work
[16:36:30 CEST] <DemoniacMilk> is there a way to rescale a video without stating an explicit resolution?
[16:37:02 CEST] <kepstin> DemoniacMilk: the scale filter can evaluate arbitrary mathematical expressions to determine the new size; see the docs
[16:39:41 CEST] <Xys> kepstin : done, but still the same DTS errors
[16:41:21 CEST] <kepstin> Xys: hmm. you can try the old option of remuxing both files to mpeg-ts, concatenating them as files (not concat demuxer), then converting back to mp4
[16:41:32 CEST] <kepstin> the mpegts demuxer might handle the timestamp discontinuity better
[16:41:52 CEST] <kepstin> if that doesn't work, i guess you're just out of luck, and you might have to re-encode :/
[16:42:43 CEST] <DemoniacMilk> aight i found if! -vs scale=320:-1 for example
[16:44:39 CEST] <Xys> kepstin: okay thanks a lot, gonna try this
[16:44:53 CEST] <kepstin> DemoniacMilk: in most cases, you'll want to use "-2", because subsampled video (yuv420) requires multiples of 2
[16:45:43 CEST] <DemoniacMilk> oh thanks
[17:03:56 CEST] <DemoniacMilk> hm interesting, im trying to stream a video over network in an infinite loop
[17:04:12 CEST] <DemoniacMilk> and its basically an alternating stream of
[17:04:40 CEST] <DemoniacMilk> works - frozen - works - frozen (each step for the duration of the video)
[17:06:15 CEST] <DemoniacMilk> https://pastebin.com/7H0GzNTc
[17:12:16 CEST] <BtbN> I'd begin with remuxing it to .ts
[17:22:25 CEST] <DHE> DemoniacMilk: using multicast?
[17:25:22 CEST] <DemoniacMilk> what is multicast?
[17:28:36 CEST] <DHE> I'll take that as a No then
[17:29:16 CEST] <DHE> it's IP addresses from 224.0.0.0 through 239.255.255.255 which can be received by any device that wants to receive the stream. like a broadcast except intended to be filtered
[17:34:16 CEST] <alexpigment> OK, between the slow-as-hell speed of mpeg2video and the lackluster quality (e.g. pulsing on still frames), i'm ready to try out x262. does anyone have any advice on cross compiling x262 for Windows?
[17:34:34 CEST] <alexpigment> or (even better) including x262 in FFMPEG itself
[17:40:07 CEST] <DemoniacMilk> ah no im not using that
[17:41:02 CEST] <DemoniacMilk> alex, id be interested in that too
[17:41:59 CEST] <alexpigment> well, as soon as i can figure out how to compile it - i'm a novice at compiling tbh - i'll get back to you on it
[17:42:11 CEST] <alexpigment> hopefully someone around here has some experience and can point me in the right direction
[17:49:45 CEST] <DemoniacMilk> ye im a total newbie too
[17:49:57 CEST] <DemoniacMilk> i managed to cross compile ffmpeg and libx264
[17:50:04 CEST] <DemoniacMilk> but i didnt manage to get those two combined :D
[17:50:21 CEST] <DemoniacMilk> anyways, im out for today, have a nice day everyone
[17:50:34 CEST] <alexpigment> DemoniacMilk: feel free to hit me up about that
[17:50:59 CEST] <alexpigment> i've got a good setup for cross-compiling ffmpeg with x264
[17:51:06 CEST] <alexpigment> anwyay, see you around
[17:52:08 CEST] <DemoniacMilk> ive been given a static version and decided its too slow on my system
[17:52:26 CEST] <DemoniacMilk> so maybe 262 might help, otherwise ill have to switch to a system with hardware encoder
[17:52:41 CEST] <alexpigment> you mean mpeg2video is too slow?
[17:52:43 CEST] <alexpigment> if so, i agree
[17:53:01 CEST] <DemoniacMilk> ye anything is too slow haha
[17:53:21 CEST] <DemoniacMilk> x264 on ultrafast --> 12 fps
[17:53:22 CEST] <alexpigment> oh gotcha. even the Zeranoe builds are too slow with libx264?
[17:53:38 CEST] <alexpigment> i don't mean to keep you here with more questions, but what CPU are you using?
[17:53:45 CEST] <DemoniacMilk> cortex-a8
[17:53:54 CEST] <alexpigment> ah
[17:54:26 CEST] <alexpigment> i have no first-hand experience with encoding on ARM, but it doesn't surprise me that software-based encoding is slow on them
[17:54:35 CEST] <alexpigment> hardware is probably the only way to go
[17:54:40 CEST] <DemoniacMilk> ye me neither, but hope dies last
[17:54:56 CEST] <alexpigment> it might be worth specifying a -threads value
[17:55:05 CEST] <alexpigment> but even then, those are dual-core, right?
[17:55:11 CEST] <DemoniacMilk> this one isnt
[17:55:28 CEST] <alexpigment> :(
[17:55:40 CEST] <DemoniacMilk> i got two alternatives, one is a dual core a9 and one has a h264 hardware encoder
[17:56:03 CEST] <DemoniacMilk> i guess hardwre encoder sounds good
[17:56:11 CEST] <alexpigment> it sounds *faster* probably
[17:56:26 CEST] <alexpigment> but the better quality will probably be on the dual core a9 with x264
[17:56:37 CEST] <DemoniacMilk> ye especially as my bandwidth is limited
[17:56:38 CEST] <alexpigment> not sure how much speed difference you'll see
[17:56:48 CEST] <DemoniacMilk> its basically meant for a live stream
[17:57:01 CEST] <DemoniacMilk> so if i am able to keep up with th einput, all is good, dont need more
[17:57:33 CEST] <alexpigment> are you doing 1080p or what?
[17:57:38 CEST] <DemoniacMilk> nah
[17:57:50 CEST] <DemoniacMilk> 720p on 20fps is absolutely enough
[17:58:06 CEST] <DemoniacMilk> resolution could even be lower
[17:58:33 CEST] <alexpigment> yeah, i find 480p to be fairly acceptable
[17:58:44 CEST] <alexpigment> a huge step up from 480i obviously
[17:58:49 CEST] <DemoniacMilk> its gonna be on a small screen (hand size) anyways
[17:58:59 CEST] <alexpigment> yeah, 480p is fine for that imho
[17:59:09 CEST] <DemoniacMilk> yup
[17:59:32 CEST] <DemoniacMilk> with both x264 (utrafast) and mpeg2 i got about 12 fps on 240p, what is not acceptable :P
[17:59:52 CEST] <alexpigment> wow
[17:59:56 CEST] <alexpigment> that is pretty bd
[17:59:58 CEST] <alexpigment> *bad
[18:00:12 CEST] <DemoniacMilk> ikr^^
[18:00:24 CEST] <alexpigment> the only other thing i can think of is some sort of optimizations during compilation
[18:00:31 CEST] <alexpigment> but i don't know what those would be
[18:01:07 CEST] <DemoniacMilk> thing is i need to speed things up by a factor of like .. 5 or something ?
[18:01:47 CEST] <alexpigment> yeah, it sounds like a lot
[18:02:06 CEST] <alexpigment> hardware may be the only option for that sort of improvement
[18:03:18 CEST] <alexpigment> did you do have --enable-neon set?
[18:12:08 CEST] <DemoniacMilk> yup
[18:12:16 CEST] <DemoniacMilk> or wait not with x264
[18:12:24 CEST] <DemoniacMilk> because that was a static build
[18:12:27 CEST] <DemoniacMilk> not sure if its set there
[18:17:51 CEST] <acamargo> hello, I need to pipe one ffmpeg capture process to several transcoding ffmpeg processes. any example about using unix sockets?
[18:20:02 CEST] <petecouture> I'm trying to concat two videos together. The first video is a dyanimc one a user is allowed to upload. I know you have to prefilter all the media so the resolution is the same when you concat two different videos. But are there other settings I should include in my prefilter? I'm getting an error concating two mp4's together that appear to have all the same encoding settings. Here's a link to my script and error: h
[18:20:02 CEST] <petecouture> ttps://pastebin.com/MtSbWhgh
[18:43:28 CEST] <thebombzen> acamargo: if you don't want to transcode with the capture process, try using named pipes
[18:43:57 CEST] <thebombzen> for example "mkfifo pipe1" will create a device file called pipe1
[18:44:27 CEST] <thebombzen> then you can run: ffmpeg -i capture -c copy -f nut -y pipe1
[18:44:39 CEST] <thebombzen> and have another process read ffmpeg -f nut -i pipe1 <transcoding options>
[18:44:57 CEST] <thebombzen> the advantage is you can do this several times and do:
[18:45:18 CEST] <thebombzen> ffmpeg -y -i capture -c copy -f nut pipe1 -c copy -f nut pipe2 -c copy -f nut pipe3 etc.
[18:45:30 CEST] <thebombzen> beware of broken pipes though
[18:49:35 CEST] <acamargo> thebombzen, lemme try ;-)
[18:51:36 CEST] <acamargo> capture process ok but transcode process seems to freeze (or it is waiting for something)
[18:53:08 CEST] <acamargo> ops, I mistype the output 'filename'
[18:55:00 CEST] <thebombzen> yea that'll end to make it not work :)
[19:13:48 CEST] <alexpigment> well if anyone's interested, I found some static Windows builds of x262 from Sept 2015 and did some testing
[19:13:58 CEST] <alexpigment> the good: definitely faster than mpeg2video
[19:14:08 CEST] <alexpigment> the bad: lots of DCT ringing / mosquito noise
[19:14:46 CEST] <alexpigment> the bitrate has to be high to get rid of it, which means that DVD encoding is just not up to par from a quality standpoint
[19:20:48 CEST] <thebombzen> alexpigment: it sounds like in order to fix that, someone would have to do work on x262
[19:20:57 CEST] <thebombzen> which really doesn't sound like it's worth anyone's time
[19:21:00 CEST] <alexpigment> yeah
[19:21:12 CEST] <kepstin> I wonder if some of the enhancements from recent work on jpeg, like mozjpeg or google's guetzli might have some applications in stuff like mpeg2
[19:21:21 CEST] <alexpigment> i guess i'm just weighing in so that the rest of you guys know that x262 is not worth investigating
[19:22:26 CEST] <alexpigment> having said that, i just realized i was previously introducing some speed bottlenecks on my ffmpeg tests, so x262 might not even be faster tbh
[20:14:01 CEST] <ZeDavidT_> Hi, does anyone know where I can find the library to "--enable-libebur128"?
[20:14:34 CEST] <c_14> https://github.com/jiixyj/libebur128
[20:15:05 CEST] <ZeDavidT_> Thanks, c-14, I'll try it.
[20:19:00 CEST] <acamargo> thebombzen, I created the unix socket but when I ran the capture process it freezes
[20:19:41 CEST] <thebombzen> kepstin: what jpeg enhancements?
[20:20:23 CEST] <kepstin> thebombzen: they're improved baseline-compatible jpeg encoders that have better efficiency/quality due to stuff like trellis and psy optimizations
[20:20:51 CEST] <thebombzen> how does it compare to FFmpeg's mjpeg?
[20:20:54 CEST] <kepstin> iirc ffmpeg's mpeg2video encoder already supports rd-optimization and trellis, but has no psychovisual stuff
[20:21:24 CEST] <kepstin> thebombzen: i'd assume it's better and slower, but I haven't seen comparisons. most comparisons are against libjpeg or libjpeg-turbo encoders.
[20:22:05 CEST] <thebombzen> if that's true how do you even use it
[20:22:13 CEST] <thebombzen> because most programs just link against /usr/lib/libjpeg.so
[20:22:57 CEST] <kepstin> thebombzen: mozjpeg and guetzli are intended for use in special-purpose tools designed to compress jpeg/optimize images for web distribution
[20:23:11 CEST] <kepstin> mozjpeg is actually api and abi compatible with libjpeg/libjpeg-turbo
[20:23:33 CEST] <kepstin> but you wouldn't want to use it as a system libjpeg, it's way too slow :)
[20:23:40 CEST] <thebombzen> ah
[20:23:56 CEST] <thebombzen> do they come with a CLI?
[20:25:44 CEST] <kepstin> both do, yeah; guetzli with a custom tool, mozjpeg builds a copy of cjpeg that you can use, or you can just load the library into some other tool.
[20:27:21 CEST] <thebombzen> wait what
[20:27:33 CEST] <thebombzen> apparently mozjpeg has 12bit jpeg encoding?
[20:31:09 CEST] <kepstin> looks like 12bit jpeg has been around for a while, but is uncommon. Does the regular libjpeg-turbo encoder/decoder support it?
[20:34:04 CEST] <llogan> ZeDavidT_: IIRC, ebur128 has been ported to FFmpeg so you don't need an external library anymore
[20:40:01 CEST] <thebombzen> I don't know
[20:40:02 CEST] <thebombzen> oh well
[21:00:03 CEST] <voip_> Hello guys please help me with this:
[21:00:04 CEST] <voip_> frame= 4452 fps= 29 q=-1.0 Lsize=   47363kB time=00:02:29.35 bitrate=2597.9kbits/s speed=0.964x
[21:00:04 CEST] <voip_> speed=0.964x - is it means my server overloaded ?
[21:00:04 CEST] <voip_> On my 8 core CPU E3-1283L i have load average ~40.
[21:00:04 CEST] <voip_> But streams quality looks like good
[21:02:59 CEST] <DHE> possibly. is it moving upwards slowly, downwards slowly, or holding stable?
[21:05:55 CEST] <voip_> its  stable
[21:21:15 CEST] <DHE> q=-1 usually means you're doing -c:v copy, which usually means CPU load is quite low...
[21:34:37 CEST] <voip_> DHE, i am transcoding, not coping https://pastebin.com/UJsyAt6M
[21:36:47 CEST] <DHE> looks good enough for an 8-core CPU to handle
[21:36:50 CEST] <voip_> actualy now i have q=33
[21:37:30 CEST] <DHE> odd, but okay
[21:38:16 CEST] <voip_> what's the acceptable q and speed values ?
[21:43:15 CEST] <DHE> well, for live content ideally 1.00x but startup delay and network throughput might cause surprises, among other things
[21:43:42 CEST] <DHE> q range I would normally suggest 18-25 for "optimal quality" but action scenes over 30 would be expected
[21:44:00 CEST] <DHE> these are very subjective and ballpark measurements, so actually watch the video and see for yourself how it looks
[21:50:50 CEST] <voip_> thank you !
[22:00:07 CEST] <dave0x6d> How can I get ffmpeg to save to stdout?
[22:00:20 CEST] <JEEB> output set to "-"
[22:00:23 CEST] <JEEB> that is stdout
[22:00:27 CEST] <dave0x6d> [NULL @ 0x7f9c40000000] Unable to find a suitable output format for 'pipe:'
[22:00:31 CEST] <JEEB> yes
[22:00:35 CEST] <JEEB> you need set output container (format)
[22:00:36 CEST] <JEEB> -f
[22:00:39 CEST] <dave0x6d> ffmpeg -pix_fmt uyvy422 -framerate 30 -f avfoundation -i 0 -vcodec rawvideo - | pv -trbaW > /dev/null
[22:00:41 CEST] <dave0x6d> I did?
[22:00:49 CEST] <dave0x6d> -f avfoundation?
[22:00:54 CEST] <JEEB> that's input
[22:00:55 CEST] <JEEB> :)
[22:01:00 CEST] <JEEB> before/after -i
[22:01:10 CEST] <dave0x6d> =\
[22:01:42 CEST] <JEEB> are you sure you want raw video without a container?
[22:01:45 CEST] <dave0x6d> [NULL @ 0x7fd7ce861a00] Requested output format 'mkv' is not a suitable output format
[22:01:48 CEST] <dave0x6d> JEEB: 100% sure.
[22:01:51 CEST] <JEEB> ok
[22:02:02 CEST] <JEEB> also for matroska it's matroska, not mkv ;)
[22:02:03 CEST] <dave0x6d> what containers work with stdout?
[22:02:13 CEST] <JEEB> ffmpeg -formats btw :P
[22:03:01 CEST] <JEEB> -f rawvideo probably gives you raw video without a container
[22:03:40 CEST] <JEEB> (-c:v rawvideo is "raw video" on a different level, which can then be put into containers)
[22:03:57 CEST] <dave0x6d> ffmpeg -pix_fmt uyvy422 -framerate 30 -f avfoundation -i 0 -f rawvideo -vcodec rawvideo -
[22:04:06 CEST] <JEEB> likely yes
[22:04:14 CEST] <JEEB> what was pv again? :D
[22:04:41 CEST] <dave0x6d> measures transfer speed.
[22:05:07 CEST] <dave0x6d> So I can see my webcam is ~50 MiB/s. =)
[22:05:20 CEST] <JEEB> completely raw, yes
[22:05:38 CEST] <JEEB> which you almost never save things as unless you've got money to throw at issues
[22:06:43 CEST] <dave0x6d> JEEB: was going to (network) pipe it to another machine to encode.
[22:06:59 CEST] <JEEB> also you usually want timestamps
[22:07:15 CEST] <JEEB> many people when using FFmpeg on both sides use NUT for raw video + audio
[22:09:26 CEST] <dave0x6d> JEEB: what's up with `Past duration <time> too large`?
[22:09:36 CEST] <dave0x6d> 50 MiB/s is way lower than my disk speed.
[22:09:45 CEST] <dave0x6d> and the warning/error doesn't happen when I pipe it to stdout.
[22:11:19 CEST] <dave0x6d> ahh, it was because of -vcodec rawvideo I think. Switched to -vcodec copy and it went away.
[22:25:02 CEST] <thebombzen> if your goal is just to test read speed from your webcam you could try outputting to /dev/null
[22:25:11 CEST] <thebombzen> or even -f null - (which discards output)
[22:25:28 CEST] <thebombzen> the advantage of using -f rawvideo -y /dev/null would be that it'll display stats
[22:25:32 CEST] <thebombzen> better stats at least
[22:49:38 CEST] <alexpigment> is there a way to a) write the ffmpeg2pass-0.log file to Windows temp, and afterward, automatically delete it?
[22:51:51 CEST] <c_14> -passlogfile %AppData%\temp\ffmpeg2pass
[22:52:01 CEST] <c_14> or something
[22:52:07 CEST] <alexpigment> c_14, awesome, thank you
[22:52:09 CEST] <c_14> you'll have to delete it manually or in a script though
[22:52:19 CEST] <alexpigment> i forgot about the passlogfile parameter
[22:52:31 CEST] <alexpigment> the deletion is slightly secondary
[22:52:41 CEST] <alexpigment> as long as it's not taking up much mindspace, it's ok
[23:03:31 CEST] <alexpigment> c_14: i don't know if this is expected or not, but the process fails if i specify a not-yet-created subfolder in the temp directory
[23:03:49 CEST] <alexpigment> is there a way to force it to create the folder?
[23:06:25 CEST] <c_14> that's expected
[23:07:14 CEST] <alexpigment> ok, i suppose it's not a huge deal. i can create the folder with the same routine that cleans it up
[23:07:19 CEST] <alexpigment> thanks
[23:20:05 CEST] <Justin_> Hi all!
[23:20:15 CEST] <Justin_> I posted a question here: https://superuser.com/questions/1194405/ffmpeg-why-is-the-drawbox-filter-breaking-the-crossfade-and-how-can-i-get-the-de
[23:20:34 CEST] <Justin_> if anyone gets some time, please read it over and let me know if you have any ideas.
[23:20:43 CEST] <Justin_> I'm really stumped!
[23:21:24 CEST] <Justin_> I'm not sure if it is a bug, or if there is somethign I'm missing.
[23:21:59 CEST] <Justin_> I'm a pretty new user, so I don't want to report bugs without input from advanced users :)
[23:35:22 CEST] <llogan> Justin_: sounds similar to https://trac.ffmpeg.org/ticket/6281
[23:39:51 CEST] <Justin_> llogan: the text works just fine in all cases. However, when I add the drawbox filter it messes with the crossfade (almost like the fade alpha gets a matte when i use drawbox)
[23:43:26 CEST] <llogan> oh, i looked at the wrong link
[23:44:56 CEST] <llogan> had another drawtext tab open from SO
[23:45:05 CEST] <llogan> *SU
[23:45:35 CEST] <Justin_> no worries ;)
[23:46:37 CEST] <llogan> what's the most simple command you can make that still shows the issue?
[23:47:09 CEST] <Justin_> I'll make it, just a moment.
[23:57:25 CEST] <alexpigment> does anyone know why a 2-pass mpeg2video in DVD format would cap out around 5.5mbps avg even though i set the bitrate to 8mbps?
[23:57:58 CEST] <petecouture> memory ?
[23:58:32 CEST] <alexpigment> in what respect?
[23:59:13 CEST] <petecouture> sorry I thought you said crap out like ffmpeg crashed. I just ran into that issue and it was memory related.
[23:59:37 CEST] <alexpigment> ah no, it *caps* out
[00:00:00 CEST] --- Sat Apr  1 2017