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

[burek]

[00:01:15 CET] <llogan> is your ffmpeg old?
[00:10:10 CET] <kcghost> ffmpeg version 3.0.2
[00:13:38 CET] <kcghost> ill try building the latest release and see if it still has the issue.
[00:22:03 CET] <llogan> you could be lazy and download a recent static build
[00:25:21 CET] <kcghost> llogan: ah thanks, I didn't realize that was an option. That's nice, I didn't want to deal with packages
[00:28:42 CET] <kcghost> llogan: huh, looks like it's fixed. I wonder when it got fixed, my ffmpeg wasn't super old.
[00:37:19 CET] <llogan> you could try a git bisect if you want to find out
[00:39:51 CET] <llogan> in general any ffmpeg release branch is always considered old
[04:27:27 CET] <RossW> when using ffmpeg to convert discrete images (jpg) into a movie, is it possible for it to not require all filenames to have the same length? Ie, if my files are "1.jpg", "2.jpg" ..... "1234.jpg" ???
[04:30:06 CET] <RossW> Looks like just %d not %4d might be the answer.  So many examples, so little clarity!
[04:39:53 CET] <c_14> use -pattern_type glob
[07:04:32 CET] <lindylex> Can I make a video that has a vertical line move from left to right on top of a image with a specified time?  I am trying to replicate the scrub on top of a waveform image?
[07:30:22 CET] <marbar> hello all
[07:30:33 CET] <marbar> does anyone here have experience w/ hls on ios?
[07:30:46 CET] <marbar> i have a source video i'm segmenting like this:
[07:30:47 CET] <marbar> ffmpeg -i 9 -map 0 -c:v libx264 -c:a aac -deinterlace -f ssegment -segment_list hls/9/list.m3u8 -segment_list_flags +live -segment_time 10 -segment_time_delta 0.03 hls/9/%03d.ts
[07:31:04 CET] <marbar> and on ios (only) it stops after about a minute and a half
[07:31:18 CET] <marbar> is there some flag i can add to ensure playback on the ipad?
[10:35:09 CET] <matkatmusic> what is the idea behind h264/x264 decoding?
[10:35:58 CET] <matkatmusic> is it that there is a bunch of data, organized as "here's frame number 0, now here's what changed for frame 1, now frame 2, etc"
[10:36:56 CET] <matkatmusic> hmm, i guess that would be how gifs work lol
[10:37:56 CET] <BtbN> Fenrirthviti, alexpigment you mean the ancient NVDefault in the dead OBS encoder?
[10:38:07 CET] <BtbN> That's what the nvenc API calls default.
[10:38:27 CET] <BtbN> Default in classic OBS is hq/llhq, depending on the resolution and FPS.
[10:38:59 CET] <BtbN> Modern obs-studio does not have anything called nvdefault, and the presets map directly to the ffmpeg -preset option.
[10:39:43 CET] <BtbN> Guess why I want to get rid of the "default" preset. It's confusing, because it's not the default.
[11:01:36 CET] <furqn> hi i am concatenating videos and adding background music to it
[11:02:07 CET] <furqn> and background music file is bigger so how can i trim it to match the size of outputed video file
[11:03:47 CET] <furqn> here it is
[11:03:50 CET] <furqn> http://pastebin.com/fHTsrRYv
[11:09:49 CET] <relaxed> furqn: there's -shortest or you could use an audio filter
[11:11:04 CET] <furqn> relaxed: -shortest will select shortest video stream in concatednated video
[11:11:11 CET] <furqn> i checked already with that
[11:12:44 CET] <relaxed> atrim filter
[11:13:19 CET] <relaxed> along with afade
[12:14:42 CET] <faLUCE> Hello. when I allocate an AVCodecContext* for a decoder, do I have to specify the pixel format (decodec_context->pix_fmt) ? This is absolutely not clear in the API. I opened a MJPEG decoder with codec = avcodec_find_decoder(AV_CODEC_ID_MJPEG) but codec->pix_fmts doesn't contain anything....
[12:40:46 CET] <njascgil> Hi everyone! I'm trying to use ffmpeg to remove the handler_name tag from audio tracks. It is set by default to handler_name=SoudHandler, but I want to delete it.
[12:42:36 CET] <njascgil> I'm able to set it to something else using "-metadata:s:a:1 handler_name=EXAMPLE", but I can't remove it using "handler_name=" or other options such as just "handler_name" or 'handler_name=""'... Any ideas? Thanks!
[13:06:13 CET] <BtbN> faLUCE, except for some weirdnesses, decoders return the native pixel format.
[13:06:48 CET] <BtbN> If a decoder supports multiple formats, you have to implement get_format to select one
[13:06:55 CET] <BtbN> primarily used for hwaccels
[13:10:29 CET] <faLUCE> BtbN: I see. Anyway it's weird that codec->pix_fmts returns NULL, while AVFrame->format returns the format. I think it's a bug of the API
[13:11:18 CET] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/avcodec.h#L1950
[13:11:20 CET] <BtbN> no it's not
[13:12:04 CET] <BtbN> Most decoders just set it to the pix_fmt they output, and ignore any user input
[13:13:55 CET] <faLUCE> BtbN: MJPEG doesn't set codec->pix_fmts to anything, while it sets AVFrame->format to YUVJ420P. This is a missing stuff of the API
[13:14:34 CET] <faLUCE> why the hell there's not a format in the avcodeccontext, while there is it in the resulting frame? it's nonsense
[13:14:46 CET] <BtbN> There is pix_fmt in AVCodecContext.
[13:14:51 CET] <kerio> i wish the "scene" would stop tailoring files to optical media
[13:14:52 CET] <kerio> :\
[13:15:09 CET] <BtbN> Also, why do you care about what is in the AVCodecContext? In the end you need to care about what is in the Frame anyway
[13:16:15 CET] <faLUCE> BtbN: sorry, I mean, why the hell there's not a format in AVCodec?
[13:17:17 CET] <faLUCE> BtbN: all the three containers (codec, format, context) must be aligned in all the fields
[13:17:19 CET] <BtbN> There is, for encoders, to signal supported input formats.
[13:17:37 CET] <BtbN> For decoders it's optional
[13:17:47 CET] <faLUCE> BtbN: then the field should be called "input_pix_fmts"
[13:17:53 CET] <BtbN> Some set it, like cuvid. mjpeg doesn't.
[13:17:57 CET] <faLUCE> otherwise it's misleading
[13:18:08 CET] <BtbN> It's just optional for decoders
[13:18:20 CET] <faLUCE> better: encoder_pix_fmts
[13:18:31 CET] <BtbN> The fiels is univeral between decoders and encoders.
[13:18:45 CET] <BtbN> And it makes sense, as you have no idea about the actual output pixel format from a decoder until it actually gives you a frame
[13:18:54 CET] <BtbN> in theory, the API even allows for it to change from frame to frame
[13:19:27 CET] <faLUCE> BtbN: yes. Then they should be specialized in some way, at least in their description (in comments or whatsoever) for decoders and encoders.
[13:19:37 CET] <BtbN> Why? There is no need to.
[13:19:38 CET] <faLUCE> otherwise it's misleading.
[13:20:16 CET] <BtbN> I don't see anything misleading about it. The fiels is properly documented in what it means for an encoder and what for a decoder.
[13:22:41 CET] <faLUCE> BtbN: please. I appreciate your help, but you insist in things in a dogmatic way. Note that this differentiation is ALREADY specified in the description of many fields of the API (like: "for encoder it does X, for decoder it does Y"). Someone forgot to specify that for pix_fmt and this is MISLEADING. It's so obvious that it should not be explained. It's just a missing feature. I'll signal it to the developers
[13:22:59 CET] <BtbN> But it is specified for pix_fmt
[13:23:23 CET] <faLUCE> BtbN: ok, no way to discuss in this way.
[13:23:41 CET] <BtbN> I just gave you the link... If you are just here to waste peoples time with trolling, please leave.
[13:24:22 CET] <faLUCE> BtbN: really not. I only explained an obvious thing.
[13:25:31 CET] <BtbN> I'll just add you to my ignore list. Annoy someone else.
[14:05:48 CET] <k-man> while converting an mp3 to m4a, is it possible to also add album art at the same time?
[14:06:53 CET] <furq> there's a longstanding open bug for that, so i guess not
[14:07:03 CET] <k-man> ah ok
[14:07:05 CET] <k-man> thanks
[14:07:12 CET] <furq> album art in m4a isn't specified anywhere iirc
[14:07:33 CET] <furq> although the de facto standard is "what itunes does" so i don't see what the problem is with just doing that
[14:10:44 CET] <k-man> dunno either
[14:11:58 CET] <kerio> itunes \o/
[14:12:16 CET] <k-man> can i add coverart some other way?
[14:12:28 CET] <furq> actually i distinctly remember doing this with ffmpeg
[14:12:32 CET] <k-man> ugh more like
[14:13:20 CET] <k-man> using xargs to run conversions in parrallel sure makes it go faster :)
[14:13:25 CET] <k-man> one per core
[14:13:54 CET] <furq> i think `ffmpeg -i foo.mp3 -i bar.png -map 0:a -map 1:v baz.m4a` will work
[14:14:09 CET] <furq> and probably -c:v copy as well
[14:14:29 CET] <k-man> i don't get the -map 1:v pard, what does that do?
[14:14:51 CET] <furq> maps the video stream (the picture) from bar.png
[14:14:55 CET] <k-man> oh is it map video from the nth file
[14:14:56 CET] <k-man> right
[14:15:05 CET] <k-man> ok let me try that
[14:17:38 CET] <k-man> i have -map_metadata:s:a 0:s:a already in my command
[14:17:51 CET] <k-man> is 0:s:a for the metadata or the audio?
[14:42:34 CET] <Fenrirthviti> BtbN: yeah, that's what I found. I can't find any existing documentation where it's still called "NVDefault" though. Seems they just call it default everywhere now, which was very confusing. It's all good, thanks for the follow up though
[14:42:57 CET] <BtbN> I called it NVDefault in OBS to signal that it is _not_ the default
[14:43:17 CET] <BtbN> Default in OBS was an automatic profile selection based on resolution and framerate.
[14:43:43 CET] <BtbN> In obs-studio the plugin-author just blindly copied the ffmpeg presets, and made default the default, which happens to be the worst choice.
[15:10:25 CET] <alexpigment> Fenrirthviti: did you ever figure out why that user thought it looked superior?
[15:10:50 CET] <alexpigment> i.e. was it a legitimate discrepancy, or was there another factor that explained the difference?
[15:11:13 CET] <Fenrirthviti> BtbN: yeah that makes sense
[15:11:44 CET] <Fenrirthviti> alexpigment: No, they stopped responding. If I had to guess, they were under the assumption that Shadowplay was using it? I can't find much documentation on what Shadowplay uses for settings
[15:11:58 CET] <BtbN> Shadowplay is using an undocumented preset.
[15:12:12 CET] <alexpigment> it's probably based on one of the low latency presets i would guess
[15:12:21 CET] <Fenrirthviti> Well that explains why I can't find it :P Does anyone have it documented?
[15:12:23 CET] <BtbN> Copying its GUID results in an initialization error
[15:12:29 CET] <Fenrirthviti> Interesting.
[15:12:29 CET] <BtbN> Find what?
[15:12:41 CET] <Fenrirthviti> What it's actually setting to replicate the results
[15:13:06 CET] <BtbN> You can just tap into its API calls. It does nothing fancy except for the non-public preset guid
[15:14:07 CET] <Fenrirthviti> Dunno how to do that. Very little experience with actual code.
[15:14:40 CET] <BtbN> You write a shim dll that exposes the same API, and make it log every single function call and its parameters
[15:14:58 CET] <Fenrirthviti> Which I'm sure is easy to someone who knows what a shim dll is.
[15:17:38 CET] <Fenrirthviti> It's all good though, I don't really care all that much. I've done my own testing that's shown the "indistinguishable quality" preset we set in OBS (which is just hq with b-frames, 2pass, and a low keyint) is just as good or better than shadowplay itself
[15:19:54 CET] <thebombzen> undocumented apis
[15:19:57 CET] <thebombzen> :P
[15:20:11 CET] <thebombzen> didn't microsoft lose a lawsuit about that
[15:20:21 CET] <Fenrirthviti> I'm just happy I wasn't going crazy trying to research all this shit to prove it.
[15:23:24 CET] <alexpigment> here's another question about NVENC H264: does anyone have any rough equivalents for x264's -crf to nvenc's -global_quality ?
[15:24:07 CET] <alexpigment> i've been using 20, which seems fine, but i was hoping to avoid some annoying tests if someone has already got a good comparison between x264 and nvenc (and quicksync too perhaps)
[15:24:42 CET] <Fenrirthviti> CQP? or is global_quality something else?
[15:24:44 CET] <alexpigment> (and i do realize that crf works differently than -global_quality, of course)
[15:25:00 CET] <alexpigment> global_quality is a CQP setting i believe
[15:25:28 CET] <Fenrirthviti> If it's CQP, I've always used 14, which seems comparable to x264 crf 16
[15:26:06 CET] <thebombzen> wait it has vbr
[15:26:08 CET] <thebombzen> since when
[15:26:27 CET] <alexpigment> yeah for some reason cqp errors on ffmpeg, so global quality is the only way i know to specify a quality-based setting
[15:26:46 CET] <thebombzen> so if you uset his: -c:v h264_nvenc -global_quality:v 14 you don't have to set the bitrate
[15:26:48 CET] <Fenrirthviti> it's had it as long as I've used it
[15:26:48 CET] <thebombzen> that's good to know
[15:27:22 CET] <momomo> is there a way to change the file ending of ts files for hls generation?
[15:27:43 CET] <thebombzen> don't call them .ts?
[15:28:10 CET] <alexpigment> Fenrirthviti - i've only been testing for 2 months or so, but in that time, -cqp always give an error "Not recognized option 'cqp""
[15:28:20 CET] <alexpigment> maybe it was deprecated before i started testing
[15:28:35 CET] <Fenrirthviti> well I dunno how OBS is actually passing it, let me check
[15:28:55 CET] <thebombzen> momomo: try -hls_segment_filename
[15:29:01 CET] <thebombzen> and name them something other than a .ts
[15:29:17 CET] <BtbN> alexpigment, it's -global_quality
[15:29:37 CET] <thebombzen> BtbN: the bigger question is why it's not on "ffmpeg -h encoder=h264_nvenc"
[15:29:48 CET] <thebombzen> ffmpeg -h encoder=h264_nvenc doesn't list -global_qualit
[15:29:50 CET] <BtbN> Because it's a global option.
[15:30:19 CET] <Fenrirthviti> enc->context->global_quality = cqp; yeah
[15:30:49 CET] <alexpigment> BtbN: yeah, that's what i've been using (see above)
[15:31:20 CET] <thebombzen> BtbN: it's a global option but has no description
[15:31:30 CET] <thebombzen> if you run "man ffmpeg-all" it lists it but doesn't say anything
[15:31:34 CET] <BtbN> It has, just not in the nvenc help, as it's not an nvenc specific option.
[15:31:54 CET] <thebombzen> no it doesn't have a description
[15:32:39 CET] <thebombzen> https://ffmpeg.org/ffmpeg-all.html#Codec-Options
[15:32:41 CET] <thebombzen> see this
[15:33:30 CET] <thebombzen> anyway, so you said -global_quality 14 is comparable to x264's -crf 16?
[15:33:54 CET] <Fenrirthviti> For nvenc, seems to be, yes
[15:34:01 CET] <furq> it's time for your daily reminder that crf quality depends on the preset
[15:34:12 CET] <Fenrirthviti> crf 16 on veryfast
[15:34:13 CET] <alexpigment> global_quality is usually better at a given value equivalent to CRF in my experience
[15:34:31 CET] <BtbN> I think it's not documented because you are expected to just use -q, which has documentation.
[15:34:32 CET] <alexpigment> and yeah, i've been comparing to veryfast as well
[15:34:35 CET] <Fenrirthviti> thebombzen: https://ffmpeg.org/ffmpeg-all.html#Options-6 there's a note here for -q
[15:34:57 CET] <thebombzen> that's the aac encoder
[15:34:58 CET] <alexpigment> BtbN - for nvenc, -q is not equivalent to -global_quality
[15:34:59 CET] <thebombzen> why would I care
[15:35:22 CET] <BtbN> alexpigment, ffmpeg_opt.c assigns global_quality from -q.
[15:35:23 CET] <alexpigment> i mean effectively, they might be the same perhaps, but the scale is very different
[15:35:33 CET] <Nacht> Hey. Quick question. Anyone know why I get 3M extra bitrate when I use a simple -c copy -t 00:02:00 command on ffmpeg ?
[15:35:56 CET] <furq> because the bitrate of that two minutes is more than the rest of the file
[15:36:02 CET] <alexpigment> BtbN - i can tell you for a fact that they are not the same in the ffmpeg i built last week
[15:36:09 CET] <Nacht> Good point furq
[15:36:32 CET] <alexpigment> average bitrate of -q:v 26 ends up as 691kbps for this test video
[15:37:07 CET] <BtbN> It multiplies it with some weird factor
[15:37:19 CET] <BtbN> for h263 compat. Seems weird. Better just use -global_quality
[15:37:20 CET] <alexpigment> yeah, that's what i assumed
[15:37:27 CET] <alexpigment> yes, that's what i use
[15:37:48 CET] <alexpigment> if you look above, you'll see that the CQP started with Fenrirthviti asked what global_quality was and why i wasn't using CQP
[15:38:07 CET] <Fenrirthviti> I didn't ask why you weren't using it, I was just confirming it was the same thing
[15:38:47 CET] <BtbN> There is also -cq, which was recently added by nvidia
[15:38:55 CET] <BtbN> No idea what it does differently than global_quality
[15:39:49 CET] <alexpigment> Fenrirthviti: sorry, you're right. just trying to explain the confusion here with -global_quality. i have no problem with it and have been using it for a few months now
[15:40:31 CET] <alexpigment> -cq seems diff than -q:v or -global_quality, oddly
[15:40:36 CET] <alexpigment> i didn't know this existed
[15:40:45 CET] <alexpigment> perhaps this is more CRF-like based on the bitrates?
[15:40:53 CET] <Fenrirthviti> yeah that's the right thing to be using, it's what OBS is passing with the CQP setting in the UI (which is what I was testing with)
[15:41:10 CET] <BtbN> the old OBS nvenc encoder is bad
[15:41:16 CET] <BtbN> I wouldn't bother with it anymore
[15:41:22 CET] <Fenrirthviti> classic? I'm not.
[15:41:32 CET] <Fenrirthviti> We don't support anything with classic anymore
[15:41:35 CET] <BtbN> studio just uses ffmpeg
[15:41:58 CET] <Fenrirthviti> right, but we call the setting "cqp" in the UI, which is just an alias to global_quality when the params are actually passed to ffmpeg
[15:42:54 CET] <BtbN> yes, global_quality is the intended constant quality mode, with -rc is set to constqp
[15:43:08 CET] <Fenrirthviti> alexpigment: https://gist.github.com/Fenrirthviti/554635fc7f31a00b1f0f51c2174c4575
[15:43:35 CET] <Fenrirthviti> if you care, that's our recommended recording settings for nvenc
[15:43:58 CET] <BtbN> seeams reasonable
[15:44:21 CET] <BtbN> one might argue you want to go for lossless for recording
[15:44:53 CET] <alexpigment> yeah, i'm looking for something a little bit more delivery-friendly, but these are good settings
[15:45:13 CET] <Fenrirthviti> yeah, we don't recommend that solely on the fact people are idiots and try to record to 5400rpm NAS drives or only have laptops with 80gb HDDs in it 90% of the time
[15:45:13 CET] <alexpigment> global_quality 14 is a bit *too* good for my purposes ;)
[15:45:40 CET] <BtbN> The -global_quality options sets the constQP values: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/nvenc.c#L525
[15:46:10 CET] <BtbN> While -cq sets rcParams.targetQuality: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/nvenc.c#L757
[15:47:08 CET] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/compat/nvenc/nvEncodeAPI.h#L1083 https://github.com/FFmpeg/FFmpeg/blob/master/compat/nvenc/nvEncodeAPI.h#L1059
[15:47:10 CET] <alexpigment> BtbN do you mind explaining that in layman's terms?
[15:47:23 CET] <BtbN> well, those comments are all the documentation there is
[15:47:28 CET] <BtbN> what it means, is up to the nvidia driver
[15:48:09 CET] <BtbN> the -cq seems to be intended for non-CQP mode, like classic VBR, but with a forced target quality...?
[15:48:17 CET] <alexpigment> well if i'm trying to get something more equivalent to CRF, do you recommend sticking with global_quality or trying -cq instead?
[15:48:47 CET] <BtbN> Can always play around with that option
[15:49:06 CET] <alexpigment> ok, well the ambiguous answer means more testing for me i guess ;)
[15:49:13 CET] <alexpigment> thanks for pointing out cq - i didn't know it existed
[15:51:28 CET] <BtbN> The x264 crf is an implementation specific thing with no equivalent elsewhere.
[15:51:54 CET] <BtbN> If you want something rougly compareable, you should compare x264 CQP to nvenc CQP
[15:53:17 CET] <BtbN> In retrospect, using a custom -cqp option would have been nicer for nvenc. As global_quality is kind of clunky, and is originally intended for qscale stuff
[15:59:16 CET] <alexpigment> yeah, i agree. i had never heard of global_quality until i started using NVENC, cqp seems at least more intuitive
[15:59:41 CET] <BtbN> Well, changing it now would break the API
[15:59:51 CET] <alexpigment> no worries
[16:00:17 CET] <BtbN> Could always start a deprecation process though
[16:01:31 CET] <momomo> thebombzen: when I use  -hls_segment_filename %0d.ts the encoding kind of gets destroyed and picture green ... it seems to have a wierd effect on the output
[16:04:23 CET] <momomo> yeah, for sur
[16:04:24 CET] <momomo> e
[16:04:59 CET] <momomo> is the option -single_file to create only one ts file likely to be computationally less expensive than for several ts files?
[16:18:56 CET] <Fenrirthviti> BtbN: Sorry if this is just an ignorant question, but would the changes proposed in -devel change the scale for quality from the current? i.e. 14 vs 26, etc.
[16:19:18 CET] <BtbN> I'll just rename -global_quality to -qp
[16:19:25 CET] <BtbN> so the name is identical to libx264
[16:19:38 CET] <Fenrirthviti> ah just a naming convention change, ok
[16:19:57 CET] <BtbN> Should have never used global_quality in the first place, it's plain wrong
[16:21:11 CET] <Fenrirthviti> yeah fair enough, thanks for the clarification
[16:29:03 CET] <Darxus_> A video I recorded is quite jiggly after using vidstab, I suspect due to lens distortion?  Does that make sense?  Is http://www.ffmpeg.org/ffmpeg-all.html#lenscorrection likely to be helpful?
[16:46:36 CET] <KOPRajs> hi, is it possible to stream from ffmpeg running on local machine to ffserver running on remote server?
[16:59:30 CET] <BtbN> Use nginx-rtmp instead.
[16:59:46 CET] <BtbN> ffserver is pretty much dead
[17:00:00 CET] <pzy> hey all, ffmpeg for life, etc
[17:01:47 CET] <pzy> anyone here playing with/working on NDI and ffmpeg?
[17:10:48 CET] <pzy> aka SpeedHQ
[17:28:01 CET] <alexpigment> BtbN - i just got around to doing more testing with -cq - it turns out it's just ignored ;)
[17:29:02 CET] <alexpigment> there are no messages denoting this, but changing the -cq [anything] is the same as not specifying a quality level or bitrate at all
[17:29:10 CET] <thebombzen> it should be qp
[17:29:11 CET] <thebombzen> not cq
[17:29:13 CET] <alexpigment> at least that saves me some more testing
[17:29:28 CET] <thebombzen> at least with libx264, you need -qp, not -cq, just fyi
[17:29:49 CET] <alexpigment> this is referring to an earlier conversation
[17:29:57 CET] <alexpigment> where BtbN mentioned -cp
[17:30:18 CET] <alexpigment> er
[17:30:19 CET] <alexpigment> cq
[17:30:23 CET] <alexpigment> confused myself there ;)
[17:30:51 CET] <alexpigment> "<BtbN> There is also -cq, which was recently added by nvidia"
[17:32:20 CET] <alexpigment> but for what it's worth, thebombzen, -qp doesn't do anything either. -global_quality is the only real way to do this, i think
[17:32:35 CET] <thebombzen> nvidia's -cq doesn't do anything tho
[17:32:39 CET] <thebombzen> you need to use -global_quality
[17:32:45 CET] <thebombzen> also -qp is a private option, not a global option
[17:32:57 CET] <thebombzen> so you shouldn't expect -qp to work in every case -global_quality does
[17:33:02 CET] <alexpigment> thebombzen - i literally just said that
[17:33:04 CET] <thebombzen> similar to how -q:a doesn't work for certain codecs
[17:33:26 CET] <thebombzen> you did?
[17:33:32 CET] <thebombzen> nvidia has -cq which I've seen
[17:33:35 CET] <thebombzen> but it doesn't actually do anything
[17:33:37 CET] <thebombzen> which is weird
[17:33:41 CET] <alexpigment> yes
[17:33:50 CET] <alexpigment> "<alexpigment> BtbN - i just got around to doing more testing with -cq - it turns out it's just ignored ;)"
[17:33:57 CET] <thebombzen> oh I mssed that
[17:33:58 CET] <thebombzen> lol
[17:34:12 CET] <alexpigment> no worries ;)
[17:34:22 CET] <thebombzen> silly me l2read
[17:34:53 CET] <alexpigment> it's hard to read everything, i know, but you responded to me right after i said it ;)
[17:53:00 CET] <fudge111> in "man ffmpeg-all" there is an example for aeval
[17:53:06 CET] <fudge111> "eval=val(0)|-val(1)"
[17:53:17 CET] <fudge111> shouldn't it be:
[17:53:17 CET] <fudge111> "aeval=val(0)|-val(1)"
[17:54:35 CET] <thebombzen> if it's a simple typo you can just submit a patch
[17:54:40 CET] <thebombzen> I don't see why it would be rejected
[18:18:36 CET] <BtbN> alexpigment, thebombzen ffmpeg will soon have -qt for nvenc, and print a deprecation warning about using -global_quality
[18:18:43 CET] <BtbN> -qp
[18:18:52 CET] <thebombzen> soon as in "patch was accepted"
[18:18:54 CET] <thebombzen> ?
[18:19:01 CET] <BtbN> Soo as in I will push it in a minute or so
[18:19:04 CET] <BtbN> *Soon
[18:19:16 CET] <thebombzen> lol that's soon
[18:29:41 CET] <sikilikis> any ffmpeg pros on here? I'm reaching my limit and I need professional help
[18:30:14 CET] <DHE> just state the problem, including pastebins of the full command-line and output. censor any private information but keep the command-line otherwise fully intact
[18:31:30 CET] <sikilikis> I'll do that later. I'm not at my home computer right now so I can't get any of that, but I was hoping I could at least get pointed in the right direction and hopefully figure it out
[18:32:00 CET] <sikilikis> running it on a raspberry pi. Compiled the 3.2.4 version.
[18:32:18 CET] <sikilikis> I'm trying to take in an animated gif, capture audio from pulse, and livestream that to youtube.
[18:32:19 CET] <BtbN> Use latest master, specially if you are compiling yourself anyway.
[18:32:38 CET] <BtbN> Also, video encoding on an RPi is not fun
[18:32:43 CET] <sikilikis> and it works for a while, but at some point it simply hangs on a frame and the output just repeats that same frame. The stream gets killed
[18:32:51 CET] <sikilikis> yeah for my use case its perfectly fine if it goes 10 fps
[18:33:05 CET] <BtbN> latest master has support for the hw encoder on the Pi
[18:33:23 CET] <sikilikis> I had tried this on like 2.7 or something as well as this current release. and its always random
[18:33:35 CET] <BtbN> There was no support until recently.
[18:33:38 CET] <sikilikis> it stays up for about 43 hours before locking up. Sometimes it just goes 20 minutes
[18:33:47 CET] <sikilikis> I'm using the libx264 encoder.
[18:34:09 CET] <sikilikis> I think I tried the hardware encoder but performance didnt improve since I'm also using the drawfilter
[18:34:21 CET] <sikilikis> or something I dunno. Like I said the low fps is perfectly fine.
[18:34:50 CET] <sikilikis> it just always ends up locking up on some frame and stays there. It doesn't crash and the cpu stays at 100%
[18:34:51 CET] <BtbN> the encoder running slow and skipping frames is not a clean way to recude the framerate, and can easily be what leads to your issue
[18:34:58 CET] <sikilikis> but nothing is encoding and the stream stops
[18:35:15 CET] <sikilikis> well when I check the log, there is no indication that frames are being skipped
[18:35:21 CET] <sikilikis> there are no warnings
[18:35:30 CET] <BtbN> The CPU being locked at 100% is a clear indication that the encoder can't keep up
[18:35:34 CET] <sikilikis> it just happily displays the frame number every half second or so
[18:36:02 CET] <sikilikis> hmm. When its working it will use the four cpus at around 30-50% each
[18:37:11 CET] <sikilikis> I dont remember the output but it might spit out something like "frame=100 fps=10 <etc etc
[18:37:31 CET] <sikilikis> and eventually it will keep outputting with the same frame number but the fps slowly decreases
[18:37:58 CET] <sikilikis> so its might say "frame= 100 fps=10" then "frame= 100 fps=9.9" ... "frame=100 fps=2.0" etc
[18:38:48 CET] <sikilikis> and at that point the entire terminal seems unresponsive and I gotta ctrl-c
[18:39:17 CET] <kepstin> sikilikis: you're using x264 with nearly default options? it can buffer a *lot* of frames in memory as it encodes, and periodically has to flush them out. this is normal behaviour
[18:39:19 CET] <BtbN> Have you tried latest master?
[18:39:31 CET] <sikilikis> Once I get home I'll get as much info as I can but I'm hoping you've seen this symptom before
[18:39:46 CET] <kepstin> sikilikis: if you're doing realtime encoding, you might want to tune x264 to reduce the frames it buffers
[18:39:55 CET] <sikilikis> for the libx264 lets see
[18:40:26 CET] <sikilikis> I change the key interval, set the preset to ultrafast or veryfast (neither made a different in performance)
[18:40:37 CET] <sikilikis> bitrate at like 1000k
[18:41:02 CET] <kepstin> sikilikis: how is ram usage on the machine looking? is it going into swap? that would cause a slowdown like that
[18:41:07 CET] <sikilikis> I'll try the latest master when I get home
[18:41:24 CET] <sikilikis> memory usage stays somewhere between 100-110mb
[18:41:56 CET] <ffmpeg> Hi
[18:42:12 CET] <kepstin> sikilikis: also, what are you outputting to?
[18:42:18 CET] <sikilikis> but I haven't done any extensive checking. sometimes it lasts hours and sometimes I'm just not around when it finally locks up (like right now)
[18:42:27 CET] <kepstin> e.g. if it's a network stream over wifi, it could just be network issues...
[18:42:27 CET] <sikilikis> outputting to youtube
[18:42:32 CET] <sikilikis> ethernet
[18:43:08 CET] <ffmpeg> Does anybody knows what's the simplest way of "converting" any video/audio to an audio webm?
[18:43:31 CET] <kepstin> ffmpeg -i anyvideo.whatever -map 0:a audio.webm
[18:44:06 CET] <kepstin> (additional options might be desired to use opus rather than vorbis, or adjust audio encoding quality)
[18:45:03 CET] <ffmpeg> thanks kepstin
[18:46:55 CET] <fudge111> I use 2.3 version, is it lacks a lot from 3.2.4 version ?
[18:47:14 CET] <sikilikis> Ive been constantly tweaking the parameters as well and chasing a bunch of different issues. I used to get "non monotonous dts" errors and now they're gone. I used to get "past duration too large" errors and those are gone too
[18:47:20 CET] <sikilikis> but it still always breaks at some point
[18:47:47 CET] <sikilikis> happened with both an older version and the current stable version
[18:48:13 CET] <sikilikis> I'm assuming a 24/7 live stream is actually possible with ffmpeg right?
[18:48:19 CET] <sikilikis> or just live streaming to some rtmp server forever?
[18:49:24 CET] <furq> sikilikis: pastebin the command
[18:49:51 CET] <sikilikis> I'm not at my home computer at the moment so I can't. As soon as I get home I'll do that
[18:49:59 CET] <furq> kepstin: if it's an rpi then it won't have any swap
[18:50:29 CET] <sikilikis> I tried it with an image that sets up like 100mb of swap memory. It still happened
[18:50:42 CET] <furq> that's probably not a good idea
[18:50:55 CET] <furq> i'd rather just let shit get oom killed on a pi than have to deal with swapping to an sd card
[18:51:01 CET] <sikilikis> well the pi itself isnt running anything else. theres no desktop installed or anything
[18:51:08 CET] <furq> i meant in general
[18:51:12 CET] <sikilikis> yeah I installed a different image. it has no swap
[18:51:14 CET] <kepstin> sikilikis: ffmpeg has no automatic reconnect or anything, so a reliable 24/7 stream would require some script to restart it if needed.
[18:51:14 CET] <furq> if it's not swapping then it doesn't matter
[18:51:43 CET] <furq> well that's no good if it's hanging
[18:52:03 CET] <furq> is it just the ffmpeg process hanging or the entire system
[18:52:08 CET] <sikilikis> just ffmpeg
[18:52:33 CET] <sikilikis> system is headless as well. I use ssh+screen
[18:52:38 CET] <sikilikis> so theres no desktop installed
[18:52:47 CET] <furq> i take it the gif or the drawtext is updating dynamically so there's some actual reason to encode it
[18:52:56 CET] <sikilikis> I use pulseaudio, mpg123 (some terminal mp3 player) and ffmpeg
[18:53:03 CET] <sikilikis> yes that is correct
[18:53:13 CET] <sikilikis> I use -ignore_loop 0 -i <my gif>
[18:53:17 CET] <sikilikis> and the drawtext filter
[18:53:26 CET] <furq> is the text updating dynamically
[18:53:42 CET] <furq> because if not you could just preencode one loop and then not have to waste the cpu encoding the same thing forever
[18:53:48 CET] <sikilikis> I tried to turn the gif into an mp4 first and use -stream_loop -1 but that didnt work at all. It would immediately hang at like frame 11
[18:53:56 CET] <sikilikis> the text updates dynamically
[18:54:16 CET] <furq> nvm then
[18:54:43 CET] <sikilikis> -threads 4 if that matters
[18:55:09 CET] <furq> i probably wouldn't set -threads but that shouldn't be the problem
[18:55:09 CET] <sikilikis> libmp3lame is the audio encoder
[18:55:42 CET] <sikilikis> is it possible that there is some deadlock happening because its using multiple threads?
[18:56:02 CET] <sikilikis> let me see if I remember the complete command
[18:56:04 CET] <furq> i doubt it
[18:56:12 CET] <furq> libx264 would default to more than 4 threads though
[18:56:23 CET] <furq> the default is logical cores * 1.5
[18:56:55 CET] <sikilikis> going from 4 to 6 probably won't change much though
[18:57:05 CET] <furq> probably
[18:57:06 CET] <kepstin> if you just wait it out, does it start making progress again? Does it do this when saving to a file or only network?
[18:57:11 CET] <sikilikis> no
[18:57:47 CET] <sikilikis> I haven't tried saving to a file but this is supposed to be running 24/7
[18:58:23 CET] <kepstin> well, you could try just writing to /dev/null and see if it still has the same issue
[18:58:30 CET] <kepstin> to rule out network problems
[18:59:50 CET] <sikilikis> if it were a network problem, would it lead to the symptom I described?
[19:01:12 CET] <kepstin> not sure. you said the cpu usage stays at 100%? if so, probably not
[19:01:29 CET] <kepstin> does it always happen around some number of frames into the video?
[19:01:29 CET] <sikilikis> one only core stays at 100%
[19:01:38 CET] <sikilikis> no its completely random
[19:01:50 CET] <sikilikis> like i mentioned before, it once lasted 43 hours before hitting that issue
[19:01:54 CET] <kepstin> hard to say then :/
[19:01:57 CET] <sikilikis> and sometimes it doesnt even last 20 minutes
[19:02:32 CET] <sikilikis> I'll try to get pull log output with -loglevel 99 once I get home but again, if it lasts hours then it's going to be a long log
[19:03:01 CET] <sikilikis> does ffmpeg have any sort of built in logging or do I just need to do something like ffmpeg ... > log.txt 2>&1
[19:07:58 CET] <kepstin> but yeah, other than making sure your x264 library is up to date, I can't really think of anything. it is a really widely tested library, and the multithreading in it is known to work quite well... so it's *probably* not x264.
[19:08:22 CET] <sikilikis> my other suspicion is that it might be the audio
[19:08:27 CET] <kepstin> and intermittent failures over a large range of timespans does lead me to think that it might be network related.
[19:08:59 CET] <sikilikis> I just remembered. sometimes after killing it I'll try to restart it and it doesnt start up
[19:09:19 CET] <sikilikis> it will just print the sort of header information and stay there. CPU stays at like 0 or 1%
[19:09:45 CET] <sikilikis> so I'll usually just kill mpg123 and pulseaudio and restart it
[19:10:33 CET] <sikilikis> but I have no idea how that would break things. Initially I would always get non monotonous dts output warnings
[19:10:47 CET] <sikilikis> I added the +getpts flag
[19:11:53 CET] <alexpigment> anyone know if NVENC supports MBAFF?
[19:12:02 CET] <earnestly> The latest commit c359d624d3efc3fd1d83210d78c4152bd329b765 "hevcdec: move decoder-independent declarations into a separate header" has broken the build with: libavformat/hevc.c:24:29: fatal error: libavcodec/hevc.h: No such file or directory
[19:12:25 CET] <alexpigment> or - perhaps - if it supports a 30p 'fake interlaced' mode like x264 does?
[19:12:29 CET] <earnestly> I assume the appropriate compiler flags weren't updated to reflect this new split
[19:21:17 CET] <kepstin> alexpigment: looks like it does, depending on gpu and driver support (some google searching makes it sound like the drivers are occasionally buggy on interlaced stuff), but ffmpeg's nvenc driver won't use mbaff mode. (it can encode interlaced stuff tho)
[19:22:43 CET] <kepstin> (if -flags +ildct is set, ffmpeg tells nvenc to use "Field mode")
[19:24:13 CET] <kepstin> alexpigment: i'm not sure what you're talking about with x264 "fake interlaced", it can use mbaff for interlaced inputs just fine...
[19:31:34 CET] <alexpigment> kepstin, yeah i can get it to be "interlaced", but Adobe Encore won't accept it for some reason, so I was hoping to see if MBAFF was supported
[19:32:02 CET] <alexpigment> regarding "Fake Interlaced", that's a way to have 30p (or 25p) video be Blu-ray compliant
[19:32:07 CET] <alexpigment> it's just a 2:1 pulldown flag i believe
[19:36:38 CET] <kepstin> hmm, I assume nvenc is using paff mode then, i guess adobe encode just doesn't like that for some reason :/
[19:37:26 CET] <BtbN> kepstin, everytime I tested interlaced encoding with nvenc it was hilariously broken
[19:37:42 CET] <BtbN> The API has support for it, and even claims hw support when doing the capability check
[19:37:45 CET] <BtbN> but it just doesn't work
[19:38:39 CET] <alexpigment> BtbN, i mean it *visually* works
[19:38:44 CET] <kepstin> huh, apparently interlaced encoding was broken in a bunch of drives until very recently https://devtalk.nvidia.com/default/topic/976088/video-technologies/ffmpeg-h264_nvenc-interlaced-encode/ :/
[19:38:49 CET] <kepstin> drivers*
[19:38:49 CET] <BtbN> It never visually worked for me
[19:39:07 CET] <BtbN> I haven't tested it in a while
[19:39:16 CET] <BtbN> And the ffmpeg part of it being fine was always my impression of it
[19:39:45 CET] <alexpigment> the strange thing about it is that it says "Scan Type: Interlaced" and "Scan type, store method: Separated fields" according to MediaInfo
[19:40:03 CET] <alexpigment> i've never seen that separated fields entry in MediaInfo
[19:40:22 CET] <kepstin> alexpigment: right, because x264 always use mbaff (it doesn't support paff)
[19:40:43 CET] <alexpigment> yeah, but i believe mainconcept does PAFF and doesn't have that field
[19:40:50 CET] <alexpigment> (as i recall, at least)
[19:43:39 CET] <alexpigment> Kepstin: the thing you mentioned about it being broken in drivers until recently rings a bell. i think it was broken the last time i checked this 2 months ago
[19:43:49 CET] <alexpigment> i probably have it in my notes and just forgot about it
[19:53:16 CET] <arpu> anyone have uses opencv and ffmpeg i try to pipe a opencv BGR MAT to a ffmpeg pipe
[19:53:47 CET] <arpu>   cv::cvtColor(img,img, CV_BGR2YUV_I420);
[19:53:58 CET] <arpu> but ffmpeg does not like it :/
[19:54:56 CET] <arpu> [rawvideo @ 0x2b96c80] Invalid buffer size, packet size 135168 < expected frame_size 12582912
[20:05:05 CET] <alexpigment> oh wow, NVENC interlacing introduces some really weird artifacting. the luma is fine, but i think the chroma is has some field swapping or something. just huge vertical bands during motion
[20:21:58 CET] <sikilikis> yo is kepstin still on?
[20:23:38 CET] <rjp421> ffmpeg --loglevel debug used to flood the screen with RTMP output, which included the function calls to the media server.... but now it only outputs a not-very-verbose summary
[20:25:13 CET] <rjp421> arpu, what os? i have gotten around similar errors in linux, with (on a raspberry pi) LD_PRELOAD=/usr/lib/arm-linux-gnueabihf/libv4l/v4l1compat.so ffmpeg ...
[20:25:22 CET] <furq> sikilikis: am i good enough
[20:25:23 CET] <obamoose> Hello!
[20:25:39 CET] <sikilikis> probably. You remember my problem right?
[20:25:43 CET] <furq> i do
[20:25:48 CET] <sikilikis> I just discovered something
[20:25:57 CET] <sikilikis> I dont know why I never thought to check before
[20:26:09 CET] <sikilikis> so its locked up right now. its using like 1% cpu
[20:26:19 CET] <sikilikis> but I just noticed that pulseaudio is also using like 1% cpu
[20:26:28 CET] <sikilikis> and i'm using pulse as the audio input
[20:26:36 CET] <sikilikis> and the media player I'm using is seemingly halted as well
[20:26:47 CET] <sikilikis> is it possible that ffmpeg is waiting for pulse?
[20:26:47 CET] <furq> well that doesn't seem good
[20:26:55 CET] <fudge111> I have 2.3 version is it lacking a lot in compare to 3.2.4 version ?
[20:26:58 CET] <furq> it wouldn't surprise me
[20:27:16 CET] <furq> you could try using alsa
[20:27:32 CET] <sikilikis> I could never figure out alsa
[20:27:50 CET] <furq> pulse is probably overcomplicated for a headless box
[20:27:56 CET] <sikilikis> so I just killed my media player. ffmpeg just spit a bunch of [flv @ 0xb60de0] Non-monotonous DTS errors
[20:28:00 CET] <sikilikis> and now it closed
[20:28:02 CET] <furq> oh nice
[20:28:04 CET] <sikilikis> like actually closed
[20:28:08 CET] <furq> yeah that definitely sounds like pulse then
[20:28:11 CET] <sikilikis> so its definitely pulse
[20:28:19 CET] <sikilikis> how would I get alsa to work?
[20:28:25 CET] <sikilikis> I tried that before and I couldnt figure it out
[20:28:44 CET] <sikilikis> I ended up using pulse due to that reason
[20:28:49 CET] <sikilikis> btw I don't much about either
[20:28:51 CET] <furq> https://trac.ffmpeg.org/wiki/Capture/ALSA
[20:29:15 CET] <sikilikis> yeah I looked at that but that assumes I'm using alsa as an input device
[20:29:24 CET] <sikilikis> I want to basically capture output from an mp3 player
[20:29:31 CET] <sikilikis> so like the "Desktop" audio even though there is no desktop
[20:29:38 CET] <furq> oh
[20:29:50 CET] <furq> https://trac.ffmpeg.org/wiki/Capture/ALSA#Recordaudiofromanapplication
[20:30:38 CET] <furq> although if you're capturing from the player then maybe it's the player's fault, not pulse
[20:30:51 CET] <sikilikis> it could be
[20:30:56 CET] <furq> i guess using alsa is one way to find out
[20:31:05 CET] <sikilikis> well I'm setting pulse as the input in ffmpeg
[20:31:11 CET] <sikilikis> it could very well be the player as well though
[20:31:21 CET] <sikilikis> but yeah if I can get just plain alsa to work thats better anyway
[20:31:33 CET] <kepstin> why are you using a player into pulse into ffmpeg rather than having ffmpeg just read the media directly?
[20:31:36 CET] <obamoose> furq: can you help me again ;_;?
[20:31:46 CET] <rjp421> is there a way to see the exact RTMP function calls to/from the server, when outputting and/or ingesting RTMP(F)P/S/E/T/TE?
[20:31:53 CET] <furq> i assume he wants to stream his playlist while he listens to it
[20:31:56 CET] <sikilikis> its supposed to be a 24/7 stream
[20:32:09 CET] <sikilikis> so I can't change the input without having to shut down the stream
[20:32:15 CET] <furq> rjp421: maybe -v debug
[20:32:42 CET] <sikilikis> ideally I also wanted to be able to change the playlist on the fly and maybe using alsa directly will let me do that
[20:32:49 CET] <sikilikis> instead of crashing once the audio source stops
[20:33:14 CET] <furq> yeah recording from loopback will just record everything that's going to speakers
[20:33:49 CET] <sikilikis> the .asoundrc file is in the home directory?
[20:34:01 CET] <sikilikis> actually nevermind I should be able to use the global
[20:34:10 CET] <rjp421> i have yet to try but i hear jack is good for per-app audio piping
[20:34:18 CET] <furq> yeah it's just in ~
[20:35:10 CET] <furq> fwiw you probably want to use the builtin aac encoder rather than lame
[20:35:22 CET] <furq> assuming it's quick enough on an rpi
[20:35:39 CET] <sikilikis> its not
[20:35:41 CET] <sikilikis> I tried it
[20:35:45 CET] <furq> i still need to build with fdk and see if it's any faster on a pi
[20:35:49 CET] <sikilikis> youtube kept complaining that it wasnt receiving enough frames
[20:35:51 CET] <furq> since that's designed for mobile devices
[20:36:12 CET] <sikilikis> which is weird because it seemed to be pushing the same framerate as liblamemp3
[20:36:17 CET] <furq> fun
[20:36:35 CET] <sikilikis> okay ffmpeg is complaining that it doesnt know the alsa format. What do I need to enable in the configure step?
[20:36:49 CET] <furq> nothing, but you need libasound2-dev installed
[20:37:05 CET] <furq> also yeah if you're rebuilding then you might want to build with fdk-aac
[20:37:25 CET] <sikilikis> I couldnt find any apt-get package for that and didnt feel like compiling another package
[20:37:39 CET] <furq> libfdk-aac-dev
[20:37:43 CET] <sikilikis> im actually really shit when it comes to manually compiling stuff and installing it under linux
[20:38:01 CET] <sikilikis> that package isnt available on raspberry pi
[20:38:07 CET] <furq> is that raspbian
[20:38:15 CET] <sikilikis> and I'm hesitant to add new sources because they always fuck up the dependencies
[20:38:20 CET] <sikilikis> its minibian but its based off raspbian
[20:38:57 CET] <furq> it's usually ok to install debs manually
[20:39:02 CET] <furq> https://packages.debian.org/jessie/armhf/libfdk-aac-dev/download
[20:39:13 CET] <furq> but yeah don't add more repos, especially not on raspbian which seems particularly flaky with that
[20:39:43 CET] <sikilikis> to install a deb its dpkg -i <file> right?
[20:39:47 CET] <furq> https://packages.debian.org/jessie/armhf/libfdk-aac0/download
[20:39:50 CET] <furq> and that as well ofc
[20:39:50 CET] <furq> and yeah
[20:40:02 CET] <furq> oh actually nvm
[20:40:05 CET] <furq> it's in non-free
[20:40:10 CET] <furq> you probably just need to add non-free to sources.list
[20:40:50 CET] <rjp421> furq, http://pastebin.com/raw/fqu3sj7t
[20:41:19 CET] <furq> well that's something at least
[20:41:28 CET] <furq> i doubt you'll get anything more detailed than that
[20:41:51 CET] <rjp421> furq, but debug is supposed to be much more verbose
[20:42:05 CET] <furq> shrug
[20:42:07 CET] <furq> i'm not a developer
[20:42:32 CET] <rjp421> it used to floot the rtmp packets along with the function and amf objects
[20:42:37 CET] <rjp421> flood
[20:42:43 CET] <furq> was that with librtmp
[20:42:43 CET] <rjp421> i am, i need that info lol
[20:43:26 CET] <rjp421> i think it was.. is that not used anymore?
[20:43:46 CET] <furq> it is with --enable-librtmp
[20:43:58 CET] <furq> your build is using the internal rtmp stuff
[20:44:22 CET] <sikilikis> I'll get back to you when I finish installing and recompiling
[20:44:35 CET] <sikilikis> though I guess I won't know if it breaks until I see it break
[20:44:49 CET] <rjp421> librtmp is old and doesnt support the different protocols, or user:pass at server authentication... so i built without librtmp
[20:44:56 CET] <sikilikis> are there any other good terminal-only mp3 players, incase it is the mp3 player thats causing the trouble?
[20:45:04 CET] <sikilikis> I'm using mpg123
[20:45:08 CET] <furq> rjp421: yeah i don't necessarily recommend librtmp
[20:45:13 CET] <furq> sikilikis: moc, mpd, xmms2
[20:45:22 CET] <sikilikis> mpd is kind of heavy isnt it?
[20:45:29 CET] <furq> oh and cmus
[20:45:33 CET] <furq> i think cmus is the one i use on my laptop
[20:45:41 CET] <furq> mpd and xmms2 are relatively heavyweight
[20:45:43 CET] <sikilikis> does it do playlists?
[20:45:46 CET] <rjp421> for the sake of seeing this simple call i need, ill rebuld with librtmp :(
[20:45:48 CET] <furq> probably
[20:45:53 CET] <sikilikis> and can it shuffle?
[20:45:57 CET] <furq> probably
[20:46:48 CET] <kerio> do you guys know if quicktime understands single-file HLS with byte ranges?
[20:48:39 CET] <ritsuka> quicktime can do byte ranges with mov and mp4, no idea about hls
[20:52:50 CET] <sikilikis> for alsa I don't need to enable anything during configure right? just having libasound2-dev is enough?
[20:53:12 CET] <furq> it should show up in the devices list in the configure output
[20:56:04 CET] <kerio> apparently the example fmp4 hls stream on apple's website has a single mp4 file with byteranges :o
[20:56:12 CET] <kerio> is there a simple way to tell the hls muxer to do that?
[20:57:31 CET] <sikilikis> even if this doesnt work, thanks a lot for your help
[20:57:46 CET] <sikilikis> spent all this fucking time and I didn't even bother to check if it was the sound causing the problems
[20:58:23 CET] <furq> there's a linear relationship between how long it takes to track down a bug and how likely it is to be something completely fucking stupid
[20:58:35 CET] <sikilikis> yup
[21:08:27 CET] <arpu> rjp421, yes linux fedora  the old v4l1compat use software color convert and its slow
[21:09:05 CET] <arpu> think its not a good solution
[21:09:16 CET] <arpu> but i will try thx!
[21:16:42 CET] <rjp421> arpu, im curious if it works, pls let me know
[21:29:13 CET] <sikilikis> it looks to be working
[21:29:21 CET] <sikilikis> sound is being capture correctly
[21:30:32 CET] <sikilikis> holy shit furq you're a genius
[21:32:09 CET] <sikilikis> hmm. I see this at the beginning: [alsa @ 0xc61b50] Thread message queue blocking; consider raising the thread_queue_size option (current value: 8)
[21:32:13 CET] <sikilikis> should I worry about that?
[21:32:36 CET] <BtbN> you are running too slow
[21:32:43 CET] <BtbN> so it eventually stalls and/or drops frames
[21:33:00 CET] <sikilikis> for alsa in particular or everything?
[21:33:11 CET] <sikilikis> and yeah its going slow. like 12 fps. But the music sounds fine
[21:33:13 CET] <furq> does that actually mean that
[21:33:39 CET] <BtbN> I'd interpret it as ffmpeg being unable to empty the message queue in time
[21:33:58 CET] <BtbN> Because the "main loop" didn't get back to alsa fast enough
[21:34:04 CET] <furq> i get that all the time piping from vapoursynth and it doesn't mean anything there
[21:34:06 CET] <BtbN> making it bigger, like the message suggests, might help
[21:34:23 CET] <sikilikis> actually I tried that once but it didnt make a difference
[21:34:32 CET] <furq> if increasing it makes no difference then you can probably ignore it
[21:34:33 CET] <sikilikis> to like 512 and 1024
[21:34:42 CET] <sikilikis> i mean the error still showed up
[21:35:18 CET] <BtbN> you should probably use the hardware encoder
[21:35:53 CET] <sikilikis> I just compiled it with that and I think I decided not to use it because performance didnt improve and the picture quality was worse
[21:35:58 CET] <rjp421> rpi hw encoder? do u have a working cmd by chance?
[21:36:06 CET] <furq> -c:v h264_omx
[21:36:14 CET] <sikilikis> I can try that
[21:36:15 CET] <furq> there's not much else you can tune with that encoder other than -b
[21:36:26 CET] <sikilikis> -b?
[21:36:28 CET] <sikilikis> bitrate?
[21:36:28 CET] <BtbN> no cbr/vbr/cqp
[21:36:29 CET] <furq> bitrate
[21:36:31 CET] <BtbN> +?
[21:36:37 CET] <furq> not as far as i know
[21:36:44 CET] <furq> they might exist in omx but i don't think they're wired up
[21:36:56 CET] <sikilikis> I dont use any of those options...
[21:37:09 CET] <rjp421> furq, what about setting the v4l capture size and bitrate etc, to as close to the output as u can get?
[21:37:20 CET] <furq> huh
[21:37:35 CET] <rjp421> isnt that a waste of resources?
[21:37:51 CET] <furq> i'm not sure what you're asking
[21:37:59 CET] <rjp421> when the pi cam is 720p/1080i?
[21:38:06 CET] <sikilikis> anyway I can pastebin my command now if you're interested
[21:38:24 CET] <furq> scaling will use more resources than not scaling, sure
[21:38:45 CET] <furq> that's equally true with any encoder
[21:38:50 CET] <rjp421> like in the cmd i psated, "v4l2-ctl -d /dev/video4 --set-fmt-video=width=1280,height=720,pixelformat=1 --overlay=0 --set-ctrl video_bitrate=14000000 ; sleep 1 ; raspivid -t 0 -w 1280 -h 720 -vf -hf -pf main -fps
[21:38:50 CET] <rjp421> 24 -g 48 -b 14000000 -ih -v -o - | ffmpeg ..."
[21:39:13 CET] <rjp421> video4 is my rpi cam
[21:42:45 CET] <rjp421> furq, what i mean is, does setting the capture like that, have any benefit over using ffmpeg and h264_omx? also what about input and type? just -i /dev/video4?
[21:43:26 CET] <furq> you can just do -video_size 1280x720 -i /dev/video4
[21:43:38 CET] <furq> !indev v4l2
[21:43:38 CET] <nfobot> furq: http://ffmpeg.org/ffmpeg-devices.html#video4linux2_002c-v4l2
[21:44:10 CET] <rjp421> cool, ty
[21:45:43 CET] <rjp421> im still using the raspivid... i dont really want to have to play around four hours to get a final working cmd :p
[21:47:33 CET] <rjp421> for*
[21:48:39 CET] <sikilikis> i'm using the hw encoder now anyway. It doesn't perform any faster but it does use less cpu so thats goo
[21:49:16 CET] <sikilikis> and I set -threads 0 instead of -threads 4. Don't know if that will help but you said it will default to <num of cores> * 1.5 right?
[21:49:26 CET] <furq> you can just not set -threads at all
[21:49:32 CET] <sikilikis> oh okay
[21:52:14 CET] <sikilikis> here is my full command btw. Let me know if you see anything wrong: http://pastebin.com/3rB4uRty
[21:52:27 CET] <sikilikis> it works but I mean I'm sure I'm doing something stupid
[22:00:57 CET] <sikilikis> wait if I use h264_omx and leave out the -threads option, will it still be multithreaded? or does it not matter?
[22:07:48 CET] <BtbN> the default is to use all cores
[22:12:34 CET] <sikilikis> cool
[22:12:56 CET] <sikilikis> its working though I won't know if its completely fixed until I see it last at least two days
[22:13:27 CET] <BtbN> Once the timestamps overflow, things will get wonky anyway
[22:13:35 CET] <BtbN> So you might want to restart once per day
[22:14:28 CET] <sikilikis> I'll look into that, but what I'm interested in right now is consistency
[22:14:54 CET] <sikilikis> if it can consistently last at least 24 hours without any problems then I can set it up to restart every night
[22:15:19 CET] <sikilikis> but I mean last time it ran for 43 hours before it fucked up
[22:15:26 CET] <sikilikis> and now I know that it was due to pulse and not ffmpeg
[22:15:39 CET] <sikilikis> well its either pulse or its mpg123
[22:15:56 CET] <sikilikis> but I'm still in a much better position now
[22:16:11 CET] <sikilikis> pulse is gone now and it feels more stable, so it was probably that
[22:16:20 CET] <sikilikis> but if not then I just have to find another mp3 player
[22:19:54 CET] <sikilikis> anyway i think im good for now
[22:20:00 CET] <sikilikis> thanks everyone who helped me
[22:25:52 CET] <sikilikis> actually one more quick question
[22:26:00 CET] <sikilikis> what will happen when the timestamps overflow
[22:26:03 CET] <sikilikis> would it just crash?
[22:27:46 CET] <rjp421> sikilikis, i was checking out that cmd.. thats on a pi? is the video just text with a bg? 1000k seems a bit much for a mostly static image...
[22:28:11 CET] <sikilikis> its an animated gif
[22:28:22 CET] <rjp421> i havent seen '-rtmp_live live' before, im going to try it after this rebuild
[22:28:32 CET] <sikilikis> and i dont need the bitrate really. When i left it out it used like 500kbs
[22:28:35 CET] <sikilikis> but its also streaming music
[22:29:06 CET] <sikilikis> i have no idea what the rtmp_live option does but this was when I was googling a bunch and found various solutions to problems I now know I never had
[22:29:21 CET] <rjp421> possibly set audio bitrate with -b:a 128k etc
[22:29:25 CET] <sikilikis> it seems like its a correct option though. its a live stream
[22:29:35 CET] <sikilikis> I had that before as well. it didnt really make a difference though
[22:29:59 CET] <sikilikis> I suppose it wouldnt hurt to add though
[22:31:43 CET] <sikilikis> right now its streaming at 700kb/s
[22:31:58 CET] <sikilikis> and youtube recommends like 500-1000k for a simple 480p stream, which this is
[22:34:39 CET] <furq> i assume -rtmp_live is an input option
[22:35:28 CET] <BtbN> I think it's an output one
[22:35:34 CET] <BtbN> turning on "livestreaming mode"
[22:35:46 CET] <sikilikis> "-f flv -rtmp_live live $URL"
[22:35:50 CET] <sikilikis> thats at the end
[22:36:09 CET] <furq> BtbN: what other mode would there be for an rtmp output
[22:36:24 CET] <sikilikis> I dunno lol
[22:36:24 CET] <BtbN> vod
[22:36:28 CET] <sikilikis> but its there and it exists
[22:36:43 CET] <furq> how would you output vod
[22:37:02 CET] <BtbN> I think it's purely meant as an indicator if the content is live or pre-recorded.
[22:37:24 CET] <furq> The default value is any, which means the subscriber first tries to play the live stream specified in the playpath. If a live stream of that name is not found, it plays the recorded stream. The other possible values are live and recorded.
[22:37:32 CET] <furq> my reading of that is that it does something for rtmp inputs
[22:37:55 CET] <furq> i guess maybe it could send something to the server when used with an output
[22:38:02 CET] <furq> either way i've never needed it
[22:39:26 CET] <sikilikis> hmm. think I should remove it then?
[22:39:37 CET] <sikilikis> it probably is used for live inputs
[22:39:53 CET] <furq> you might as well
[22:40:14 CET] <furq> shorter commands are generally better
[22:41:20 CET] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/rtmpproto.c#L3116 it's definitely an output flag
[22:41:39 CET] <sikilikis> well for what its worth, i've been quickly modifying the command, killing ffmpeg and restarting it. and it hasnt had any problems
[22:41:41 CET] <BtbN> oh, nevermind. Read the wrong line
[22:42:19 CET] <sikilikis> normally by now it would have refused to work and I'd have to reboot
[22:43:19 CET] <sikilikis> here's the actual stream if you're interested in seeing what the pi can do: https://www.youtube.com/watch?v=EgbVOsom6CU
[22:43:45 CET] <sikilikis> but I won't know if its truely working until I can consistently get it to run for like 50+hours every time
[22:43:50 CET] <sikilikis> so here's hoping
[22:44:17 CET] <furq> Playing soundtracks from your favorite games on NES, Gameboy, Sega Master System, and Game Gear.
[22:44:22 CET] <furq> what if my favourite soundtracks are on the megadrive
[22:44:47 CET] <sikilikis> thats the genesis right?
[22:44:59 CET] <sikilikis> I've been debated whether I want to add 16-bit to that list
[22:45:00 CET] <furq> if you must
[22:45:08 CET] <sikilikis> haha. american here so
[22:45:38 CET] <sikilikis> I need to add space to the pi unfortunately and I dont have too many flash drives or externals I can spare
[22:45:49 CET] <sikilikis> but first things first is that I need to get it working right
[22:45:57 CET] <sikilikis> then I can add all the megadrive games you want
[22:46:10 CET] <sikilikis> (I didnt grow up with a sega so...)
[22:48:38 CET] <furq> https://www.youtube.com/watch?v=LzMZuKZAfgc&t=20m52s
[22:48:40 CET] <furq> do you have this
[22:49:56 CET] <sikilikis> uh
[22:49:57 CET] <sikilikis> lemme check
[22:50:22 CET] <sikilikis> is that nes?
[22:50:25 CET] <furq> yeah
[22:50:53 CET] <furq> i have an nsfe of it so you probably should too
[22:50:55 CET] <sikilikis> Zombie Nation yes I do
[22:51:32 CET] <Darxus> Ugh, I concatenated a 17 video clips together, totalling about an hour, and some of them are coming out upside down.  Viewing the clips by themselves looks fine.  I used -f concat, with "ffmpeg version N-84348-gdb7a05d", statically compiled, for windows.
[22:51:32 CET] <alexpigment> speaking of NSF, the dude who invented that format - "Kevtris" just put out a pretty awesome retro game console
[22:53:03 CET] <Darxus> Any guesses how I could fix this?
[22:53:19 CET] <sikilikis> kevtris?
[22:53:33 CET] <alexpigment> yeah, kevin horton - his internet name is Kevtris
[22:54:11 CET] <alexpigment> but he engineered the Analogue NT Mini, which is an FPGA-based NES console which also supports "Flashing" the core hardware to a number of 8-bit systems (gameboy, master system, atari, etc)
[22:54:35 CET] <alexpigment> an extremely well-designed system with none of the downsides of emulation
[22:54:46 CET] <Darxus> The video was recorded on an android phone (Samsung Galaxy S4).
[22:54:54 CET] <alexpigment> Darxus - i take it some of those videos were shot upside down?
[22:55:00 CET] <alexpigment> yeah, phone videos. makes sense
[22:55:20 CET] <alexpigment> i forgot the parameters needed to detect the rotation properly
[22:55:51 CET] <alexpigment> i'll look and see if i have any notes on that (others here probably know off the top of their heads though)
[22:55:56 CET] <furq> you can detect it in ffprobe and fix it with -metadata:s:v:0 rotate=xx -c copy
[22:56:11 CET] <Darxus> alexpigment: It's quite possible the phone was rotated differently when they were recorded, yes.
[22:56:13 CET] <furq> where xx is 0 or 180 depending on what ffprobe says
[22:56:25 CET] <furq> you'd need to fix it in all the clips that are wrong and then concat them again
[22:56:54 CET] <Darxus> There isn't a way to get ffmpeg to just... detect the rotation properly?
[22:56:58 CET] <alexpigment> Darxus, is this a 1-time job or do you need this to be an automatic detection?
[22:57:29 CET] <furq> if the clips are actually inverted and not just by metadata then you might need to actually reencode
[22:57:39 CET] <furq> actually
[22:57:47 CET] <alexpigment> yeah, re-encoding is certainly necessary at some step in this process
[22:57:52 CET] <Darxus> I'm re-encoding anyway, to use vidstab.
[22:57:57 CET] <furq> if they're just flipped by metadata then there's no need
[22:58:11 CET] <furq> but if you're reencoding anyway then never mind
[22:58:22 CET] <furq> i'm not really sure how ffmpeg deals with rotation metadata in concat
[22:59:02 CET] <Darxus> alexpigment: I guess it's a 1-time job.
[22:59:33 CET] <alexpigment> i have a rotate script i made a while back
[22:59:36 CET] <alexpigment> -filter:v "hflip,vflip" -metadata:s:v:0 rotate=0
[22:59:42 CET] <alexpigment> that's the important part of it
[23:00:05 CET] <alexpigment> basically it's flipping it and then removing the embedded metadata for the rotation
[23:00:21 CET] <furq> sikilikis: fwiw cmus and moc both use libavcodec, so they can play back emulated formats directly if your ffmpeg was built with libgme
[23:00:30 CET] <furq> xmms2 and mpd can probably do that too
[23:00:44 CET] <Darxus> alexpigment: And I'd need to do that only for the clips that are upside down, and not the rest?
[23:00:49 CET] <alexpigment> right
[23:00:53 CET] <sikilikis> eh by this point I like
[23:00:57 CET] <alexpigment> it's not any sort of auto-detection
[23:00:59 CET] <sikilikis> mp3 is perfectly fine for me
[23:01:09 CET] <furq> well you said space was an issue and emulated formats are way smaller
[23:01:11 CET] <sikilikis> and if its truly working now I'd like to stop spending time on it lol
[23:01:15 CET] <alexpigment> but i made a batch script, so i just drag the files in question on the bat, it quickly re-encodes them, and then it's done
[23:01:17 CET] <sikilikis> oh I suppose
[23:01:38 CET] <sikilikis> but does it support any emulated format?
[23:01:45 CET] <furq> it supports all the important ones
[23:01:50 CET] <furq> it doesn't do obscure stuff like mdx or s98
[23:01:57 CET] <alexpigment> Darxus: i'm sure it's possible to do it in a more automated way, but that's beyond my skill level
[23:02:05 CET] <furq> https://github.com/mcfiredrill/libgme/blob/master/readme.txt
[23:02:16 CET] <sikilikis> I don't know anything about emulated formats though
[23:02:25 CET] <sikilikis> like are all the songs already predefined lengths?
[23:02:30 CET] <furq> depends on the format
[23:02:38 CET] <sikilikis> and also these mp3s tend to come with meta data so I can easily get the game and title
[23:02:39 CET] <Darxus> I'm kind of more curious about implementing automatic detection in ffmpeg than dealing with this manually.
[23:02:53 CET] <furq> the good emulated formats have metadata and correct track lengths
[23:02:57 CET] <furq> vgm and nsfe do
[23:03:05 CET] <furq> gbs doesn't though
[23:03:09 CET] <sikilikis> oh
[23:03:11 CET] <sikilikis> hmm
[23:03:20 CET] <sikilikis> that will definitely be a v2 kind of thing
[23:03:21 CET] <alexpigment> Darxus: understandable. that's why i asked if it was a one-time thing or not
[23:03:31 CET] <alexpigment> if it's one=time fixing them like this would be quicker overall
[23:04:47 CET] <Darxus> "FFMPEG recently changed the default behavior to auto rotate input video sources with "rotate" meta data." - version 2.7 - http://stackoverflow.com/questions/9408542/video-captured-from-iphone-gets-rotated-when-converted-to-mp4-using-ffmpeg
[23:05:24 CET] <alexpigment> well, it's possible that the problem here is that you're doing concat, and that filter doesn't assume re-encoding
[23:05:33 CET] <furq> Darxus: try with -noautortate before -i
[23:05:39 CET] <furq> -noautorotate
[23:06:02 CET] <furq> probably do a test encode with -ultrafast to make sure you're not wasting your time
[23:06:10 CET] <Darxus> I... need to figure out a test set that doesn't take a whole day to re-encode :)
[23:06:10 CET] <furq> -preset ultrafast
[23:06:11 CET] <alexpigment> furq - that seems counterintuitive - what's your thought process?
[23:06:36 CET] <furq> if the flipped videos are the right way up but flipped by metadata then that should fix it
[23:06:40 CET] <alexpigment> ahh
[23:06:44 CET] <alexpigment> makes sense
[23:07:15 CET] <furq> Darxus: ffmpeg -noautorotate -i concatlist -preset ultrafast test.mp4
[23:07:38 CET] <alexpigment> downscaling would also save some time
[23:07:46 CET] <alexpigment> e.g. -s 320x180
[23:12:55 CET] <Darxus> alexpigment: Weird, that said "option video size not found" (not copied and pasted).
[23:13:59 CET] <Darxus> Okay, the two smallest clips do reproduce this result (without -noautorotate).
[23:14:42 CET] <furq> -s goes after the input file
[23:15:53 CET] <Darxus> furq: -noautorotate didn't help: ffmpeg.exe -f concat -safe 0 -noautorotate -i sample.txt -preset ultrafast sample2.mp4
[23:16:17 CET] <furq> shame
[23:16:39 CET] <furq> i guess they are actually upside down then
[23:16:45 CET] <furq> which is trickier to deal with in one go
[23:16:51 CET] <alexpigment> ok, so is the difference here that you're doing -f concat vs the concat filter?
[23:17:22 CET] <alexpigment> again, maybe -f concat assumes no re-encoding, whereas the concat filter *does* assume re-encoding
[23:17:44 CET] <Darxus> So how do I figure out if "version N-84348-gdb7a05d" is at least as new as version 2.7?
[23:17:45 CET] <alexpigment> i seem to recall there's two ways to concat, right?
[23:18:01 CET] <alexpigment> what's the date of the file?
[23:18:09 CET] <Darxus> alexpigment: At least two...
[23:18:22 CET] <alexpigment> if it's older than a few months, just get the newest static built from zeranoe
[23:18:26 CET] <furq> Darxus: db7a05d is two days old, so that should be fine
[23:18:53 CET] <furq> https://github.com/FFmpeg/FFmpeg/search?q=db7a05d&type=Commits&utf8=%E2%9C%93
[23:19:21 CET] <Darxus> So, my video clips have their rotation metadata recorded in some way ffmpeg is not recognizing?
[23:19:35 CET] <furq> if it was metadata then noautorotate should have worked
[23:19:41 CET] <furq> so i'm guessing they're actually recorded upside-down
[23:19:55 CET] <furq> which is probably going to be a pain to deal with
[23:20:24 CET] <Darxus> Well... if they're playing back right, outside of ffmpeg, they're either recorded right side up, or have metadata that the player is reading correctly and ffmpeg is not, right?
[23:20:43 CET] <alexpigment> they're almost certainly recorded upside down with metadata that's being read to play them correctly
[23:20:47 CET] <furq> ^
[23:20:58 CET] <alexpigment> that's how all phones work these days
[23:21:27 CET] <Darxus> Right.  So... I just need to figure out how my metadata is different than the rotation detection that's been implemented, and patch it?
[23:21:30 CET] <alexpigment> anyway, again, my vote is for the concat filter. it's incompatible with stream copying, so it's likely applying all metadata information to the input
[23:21:30 CET] <furq> it should in theory obey the metadata when reencoding
[23:22:04 CET] <furq> yeah maybe try the filter
[23:22:20 CET] <alexpigment> and in the case of the filter, don't use the -noautorotate flag
[23:23:03 CET] <furq> -i normal.mp4 -i flipped.mp4 -preset ultrafast -filter_complex "concat=2:1:1[out]" -map "[out]" test.mp4
[23:23:36 CET] <Darxus> Thanks.
[23:23:54 CET] <furq> if it works then you'll need to replace 2 with 17 for 17 inputs
[23:24:17 CET] <furq> and uh
[23:24:58 CET] <furq> -filter_complex "concat=17:1:1,vidstabtransform[out]"
[23:25:42 CET] <furq> hopefully each file has one video and one audio track in that order or you'll have to specify 17 inputs to the filter
[23:25:45 CET] <furq> that sounds like fun
[23:25:53 CET] <alexpigment> as a random aside, i have a love/hate relationship with video stabilization. it has it's place, but i'm more often bothered by the look of stabilized video than i am shaky video (end mini rant)
[23:26:02 CET] <Darxus> furq: Heh, I hope so.  Seems likely.
[23:26:20 CET] <alexpigment> furq: they're all camera videos - i presume on audio channel is going to be the norm ;)
[23:26:27 CET] <furq> one would hope so
[23:26:37 CET] <alexpigment> *one
[23:26:47 CET] <Darxus> furq: Woo, that worked!  Thank you.
[23:29:08 CET] <Darxus> alexpigment: Yup, I... hate noticably stabilized videos.  Not sure what I'm going to do about that.  Seems like it should be possible to do without the artifacts.
[23:29:30 CET] <alexpigment> i mean, you're creating something that doesn't exist. there are always downsides to that
[23:29:39 CET] <alexpigment> kinda like motion interpolation on TVs
[23:29:46 CET] <Darxus> I'm guessing the artifacts I'm currently getting are from lens distortion...
[23:30:13 CET] <alexpigment> well, if you have a lossy stream, it's possibly those macroblocks are interfering with the vidstab
[23:30:29 CET] <Darxus> alexpigment: I think I disagree, what I want is just sampling the subset of pixels that's roughly in the same place some subset in the previous and next frames.
[23:31:02 CET] <alexpigment> yeah, but this is videos encoded from a camera in someone's hands, right?
[23:31:08 CET] <Darxus> alexpigment: Yes.
[23:31:23 CET] <alexpigment> if so, there's a lot of motion on both axe
[23:31:26 CET] <alexpigment> *axes
[23:31:38 CET] <alexpigment> and so the background is moving more than the foreground
[23:31:55 CET] <alexpigment> and some of that background has to be made up as part of the stabilization, because it's being obscured by the foreground
[23:32:01 CET] <alexpigment> that's where the weirdness comes from
[23:32:04 CET] <alexpigment> making up the background
[23:32:07 CET] <Darxus> Ah, good point, thank you.
[23:32:31 CET] <alexpigment> if the motion only ever went truly up or down or left or right, stabilization would be easy
[23:32:32 CET] <Darxus> Maybe... I will give up on producing videos :P
[23:32:39 CET] <alexpigment> it's that z-axis that's the killer
[23:32:45 CET] <alexpigment> haha, no
[23:32:59 CET] <Darxus> Yup, it's an excellent argument that had not occurred to me.  I wondered why it was being so hard :)
[23:33:22 CET] <Darxus> But I suspect the primary artifact I'm getting probably is due to lens distortion.
[23:33:29 CET] <Darxus> Wobbling at the corners each time I take a step.
[23:33:44 CET] <alexpigment> oh, are you not overscanning and cropping?
[23:34:03 CET] <Darxus> I'm using vidstab, which is cropping.
[23:34:14 CET] <alexpigment> maybe i'm assuming too much. you have eyes and a brain, so i'll trust your assumption about lens distortion
[23:34:37 CET] <Darxus> I'm guessing by overscanning you mean... recording a larger area than I'm using in the final result?
[23:34:52 CET] <Darxus> I'm also very new to a lot of this stuff.
[23:35:04 CET] <alexpigment> i just meant that there's an inherent zooming and cropping that is involved in video stabilization
[23:35:08 CET] <Darxus> But the middle of the videos look great, it's just the corners wobbling.
[23:35:14 CET] <alexpigment> otherwise you'd get an annoying black border moving everywhere
[23:35:17 CET] <Darxus> Yes.
[23:35:40 CET] <alexpigment> so i don't know. it may be worth seeing if there's a way to crop more of the outside
[23:36:01 CET] <alexpigment> i've never used vidstab myself though, so i don't know what parameters are available
[23:37:17 CET] <Darxus> furq: The concat method I was originally using is the demuxer, the one you suggested, which is rotating correctly, is the concat filter.  It seems like there may be a bug worth filing against the demuxer?
[23:37:36 CET] <furq> maybe
[23:37:41 CET] <Darxus> alexpigment: Yeah, doing more cropping was something I've been meaning to try.
[23:37:54 CET] <Darxus> I really should check if this thing runs vastly faster on my linux desktop.
[23:38:16 CET] <furq> it might not be possible for it to work with the demuxer
[23:38:31 CET] <Darxus> furq: I have difficulty with that statement :P
[23:38:43 CET] <alexpigment> Darxus re the concat thing, i think that's just how it should work probably. if you were using the concat demuxer, you could simply do -copy and copy the inputs to the outputs, but this couldn't apply the metadata
[23:38:57 CET] <alexpigment> the filter is assuming that you're going to re-encode, so it can take in that metadata accordingly
[23:39:04 CET] <furq> since it demuxes all the files into one continuous stream, it'd have to be possible for the metadata to change mid-stream
[23:39:12 CET] <furq> and i don't think that's a thing
[23:39:34 CET] <furq> i'm not a dev though, i'm just speculating
[23:39:44 CET] <Darxus> Ah, weird, thanks.
[23:40:22 CET] <alexpigment> i mean the only other option is to detect that you're re-encoding and then apply metadata. but then it would work two different ways, which always confuses users ;)
[00:00:00 CET] --- Fri Mar 24 2017