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

[burek]

[00:27:51 CEST] <exonintrendo> how can i cut a video with a specific start time but also set the start time of the video's metadata?
[01:07:35 CEST] <Kaedenn1> What does this error mean? [mjpeg @ 0x323f300] Format mjpeg detected only with low score of 25, misdetection possible!
[01:07:59 CEST] <Kaedenn1> My command is just `ffmpeg -i timelapse.mjpeg -r 30 timelapse.mp4`
[01:08:42 CEST] <nicolas17> it's just a warning, it detected mjpeg but it's not sure it's right
[01:08:46 CEST] <nicolas17> is it mjpeg? :)
[01:13:39 CEST] <cehoyos> DHE: No, in the past we had an ftp server, now it's only samples.videolan - but the idea of any sample is of course to make it publically readable, private samples are of limited usefulness;-(
[01:16:02 CEST] <cehoyos> Kaedenn1: If the video is not mjpeg, we would like to have a sample
[01:21:42 CEST] <Kaedenn1> The video is made via "cat images-today/snap-*.jpg > timelapse.mjpeg", where each image is indeed a valid jpeg
[01:22:37 CEST] <Kaedenn1> unless ffmpeg expects more than just a bunch of catted jpegs in its desired flavor of mjpeg
[01:22:54 CEST] <Kaedenn1> like sprinkles, cookie dough, m&ms, etc
[01:23:52 CEST] <another> i think mjpeg was a little bit different in the headers
[01:24:55 CEST] <nicolas17> do you still have the individual jpgs?
[01:25:25 CEST] <another> could throw them into ffmpeg directly
[01:25:32 CEST] <nicolas17> ffmpeg -pattern_type glob -i 'images-today/snap-*.jpg'
[01:25:55 CEST] <Kaedenn1> I didn't know pattern_type was a valid argument
[01:25:57 CEST] <Kaedenn1> Let me try that
[01:26:38 CEST] <nicolas17> yeah by default it takes stuff like "foo-%03d.jpeg" for foo-000.jpeg, foo-001.jpeg...
[01:26:46 CEST] <Kaedenn1> Yeah, but that's limited to a thousand images
[01:26:47 CEST] <nicolas17> but if you want to use * you need -pattern_type
[01:26:59 CEST] <nicolas17> what are your filenames like?
[01:27:23 CEST] <Kaedenn1> timelapse/20190609/image-20190609130100.jpg
[01:27:30 CEST] <Kaedenn1> image-YYYYMMDDHHMMSS.jpg
[01:27:43 CEST] <nicolas17> ohh, yeah use glob then
[01:27:59 CEST] <nicolas17> with HHMMSS you don't get consecutive numbers
[01:28:08 CEST] <Kaedenn1> that works amazingly an bypasses the need for an intermediate step
[01:28:15 CEST] <Kaedenn1> and*
[01:28:20 CEST] <nicolas17> :)
[01:29:14 CEST] <Kaedenn1> where does -r 30 go in that?
[01:29:20 CEST] <Kaedenn1> After the input?
[01:29:48 CEST] <Kaedenn1> My previous command had it as the last arg before the output file
[01:30:27 CEST] <Kaedenn1> Yeah, it works there.
[01:31:11 CEST] <nicolas17> everything before a -i is an input option
[01:31:48 CEST] <DHE> cehoyos: I'll have to ask someone for permission tomorrow before uploading... this isn't something I normally do
[01:32:04 CEST] <cehoyos> Thank you
[01:33:08 CEST] <cehoyos> Kaedenn1: Yes, concatenating jpg's makes mjpeg, it is difficult to distinguish between jpeg and mjpeg, that's why you see the warning
[01:33:28 CEST] <Kaedenn1> gotcha
[01:34:13 CEST] <cehoyos> You can also pipe the images (as mjpeg) into FFmpeg if glob does not work for any reason (you don't need the harddisk memory in case you don't have it)
[01:36:14 CEST] <Kaedenn1> this is true
[01:36:57 CEST] <Kaedenn1> Because the timelapse capture takes several hours, and because I have the disk space for it, I just download everything then encode. Also makes it so if a single frame fails to download/encode it doesn't trash the entire thing
[01:38:04 CEST] <cehoyos> Sounds like a good idea, FFmpeg may fail if a frame is missing.
[01:39:13 CEST] <another> Kaedenn1: how are you capturing the jpegs?
[01:42:59 CEST] <Kaedenn1> another: downloading them from a WAN-enabled camera
[01:43:13 CEST] <Kaedenn1> the camera produces jpeg files when requested
[01:44:25 CEST] <another> hmm ic
[01:45:51 CEST] <another> you might be interested in motion: https://motion-project.github.io/
[01:48:47 CEST] <Kaedenn1> I'll make a note of that. This might be helpful for the replacement camera
[01:48:58 CEST] <Kaedenn1> ...assuming I can get permission to mount it
[03:05:05 CEST] <void09> how do you decode only the first n frames of a video?
[03:06:11 CEST] <another> -frames:v 3
[03:06:31 CEST] <another> oh wait, decode
[03:06:49 CEST] <void09> yes, i want to encode a video and the --limit parameter for the encoder does not work through ffmpeg
[03:07:10 CEST] <void09> so i must tell ffmpeg to only process the first n frames of the input video
[03:07:33 CEST] <c_14> what another said
[03:07:44 CEST] <nicolas17> -frames sets the number of frames to encode, not decode, but the difference shouldn't matter in most transcoding cases
[03:10:14 CEST] <void09> works, thanks
[03:12:20 CEST] <void09> ffmpeg -i input.mp4 -c:v libaom-av1 -strict experimental -b:v 2M -pass 1 -an -f matroska /dev/null && ffmpeg -i input.mp4 -c:v libaom-av1 -strict experimental -b:v 2M -pass 2 -c:a libopus output.mkv
[03:12:27 CEST] <void09> can you please explain how this works?
[03:13:20 CEST] <nicolas17> what specifically?
[03:13:22 CEST] <nicolas17> two-pass encoding?
[03:14:28 CEST] <void09> yes, and that /dev/null redirect
[03:14:36 CEST] <void09> and what's with the log file it creates
[03:16:08 CEST] <furq> the log file is the only thing the second pass uses from the first pass
[03:16:34 CEST] <furq> you can write the first pass video somewhere if you want but you might as well send it to null
[03:16:54 CEST] <void09> i see the first pass goes on rather quickly, so i wonder what it does
[03:17:14 CEST] <void09> if i send the video to /dev/null it doesn't seem like a real encode but some pre-processing stuff?
[03:18:24 CEST] <nicolas17> the important part from pass1 is the log file, which has statistics on the video
[03:18:42 CEST] <c_14> it mainly calculates video complexity so it knows where the encoder needs to throw bits and where it can save them
[03:19:01 CEST] <c_14> so that the 2nd pass is as close to the given bitrate as possible (and the highest quality for said bitrate)
[03:19:05 CEST] <furq> yeah it's just used for ratecontrol
[03:19:20 CEST] <void09> oh, the thing is, i'm not using rate control but constant quality
[03:19:29 CEST] <furq> for x264 or something that has good quality-based ratecontrol then you generally won't need to use it
[03:19:45 CEST] <furq> but vpx and (presumably by extension) aom do not have good quality-based ratecontrol
[03:19:49 CEST] <c_14> void09: that command is using constant bitrate and not constant quality
[03:19:54 CEST] <furq> also yeah
[03:20:01 CEST] <void09> c_14 i'm not using that command
[03:20:10 CEST] <void09> jst the part of it with 2 pass
[03:20:35 CEST] <nicolas17> afaik if you're using constant quality you don't need two-pass
[03:20:39 CEST] <c_14> I'm not sure 2pass is used for anything but constant bitrate
[03:20:40 CEST] <furq> you do with vpx
[03:20:49 CEST] <c_14> with vpx isn't that the maximum bitrate?
[03:20:50 CEST] <furq> vpx only enables certain features in the second pass
[03:20:51 CEST] <void09> i was told libaom is not optimized for 1 pass
[03:20:56 CEST] <furq> and i assume aom is the same
[03:20:59 CEST] <furq> given its lineage
[03:21:07 CEST] <void09> and i already got a 0.2kb file size reduction for a 30fps encode :)
[03:21:12 CEST] <furq> nice
[03:21:18 CEST] <void09> 30 frames*
[03:21:29 CEST] <c_14> was going to say
[03:21:29 CEST] <furq> the frames will probably look a bit nicer
[03:21:32 CEST] <c_14> 200 bytes isn't that much
[03:21:53 CEST] <void09> it was just black screen for the first 30 frames so i guess there was not a lot to optimise. but it still did
[03:22:48 CEST] <void09> set this up in a virtualbox and i am going to start an insane slowest speed/max quality encode of a full length movie
[03:23:10 CEST] <furq> i hope you have a nice calendar to time it with
[03:24:53 CEST] <void09> it did 0.4 -0.3 fps in the beginning
[03:25:10 CEST] <void09> but it was just intro logos and such. i think it's going to drop a lot in complex scenes
[03:25:41 CEST] <void09> oh wait, already 0.2 fps, by selecting the slowest mode
[03:26:01 CEST] <void09> so yeah, a calender would be appropiate :)
[03:26:13 CEST] <void09> sometimes this summer it should be done though
[03:26:20 CEST] <void09> some time*
[03:26:29 CEST] <void09> sometime*
[03:48:50 CEST] <another> be sure to test your setup with a shorter sequence first
[04:03:16 CEST] <void09> of course, that's what i am doing now
[04:03:58 CEST] <void09> something is wrong though. 4.5 MB for 100 frames already :(
[04:06:51 CEST] <void09> there must be a bug somehwere
[04:07:15 CEST] <void09> it's doing 11mbps for very simple slow moving logos
[13:47:14 CEST] <^Neo> good morning friends, does anyone know of any way to capture smpte 2022-2 streams?
[15:15:12 CEST] <another> void09: https://ffmpeg.org/ffmpeg-all.html#segment_002c-stream_005fsegment_002c-ssegment
[15:36:31 CEST] <ddubya> is it possible to encode near-lossless mpeg2 video, with -qscale 0 ?  The max bitrate I'm seeing for 1080p is around 25mb
[15:37:12 CEST] <ddubya> and some detail is lost compared to the source
[15:41:27 CEST] <ddubya> my objective is to find something equivalent to prores or cineform but lower bitrates
[15:42:21 CEST] <ddubya> that works with davinci resolve free version (so h264 is not an option)
[16:56:43 CEST] <kepstin> ddubya: you'd also have to set -qmin, the default is 2. no idea if you'll run into any other issues.
[16:59:19 CEST] <kepstin> (also, 1 is the minimum value for mpeg2)
[17:03:37 CEST] <bostonmacosx> Helo there
[17:05:10 CEST] <bostonmacosx> Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz
[17:05:21 CEST] <bostonmacosx> is my processsor which static build should I use?
[17:05:37 CEST] <kepstin> bostonmacosx: the one that matches your os
[17:05:58 CEST] <bostonmacosx> https://johnvansickle.com/ffmpeg/
[17:06:10 CEST] <bostonmacosx> is all linux juust by processor
[17:06:38 CEST] <kepstin> bostonmacosx: assuming you're using a 64bit operating system, "amd64" is the one you want
[17:06:49 CEST] <bostonmacosx> RHEL6
[17:07:01 CEST] <bostonmacosx> eeven iif the processor is intel?
[17:07:23 CEST] <furq> yes
[17:07:27 CEST] <kepstin> amd created the 64bit processor extensions, so it's called amd64 for historical reasons.
[17:07:37 CEST] <kepstin> intel and amd are compatible nowadays for that
[17:07:41 CEST] <bostonmacosx> ah ok....good to know Ii'm uused to seeing x86_64
[17:07:48 CEST] <bostonmacosx> for 64 bit stuff
[17:08:33 CEST] <furq> iirc intel still has to pay amd a license fee for amd64
[17:08:35 CEST] <furq> which is pretty cool
[17:08:41 CEST] <kepstin> (iirc intel officially calls it "emt64", and "x86-64" is a vendor-neutral term)
[17:08:53 CEST] <furq> amd should make it a term of the license that intel has to call it amd64
[17:08:55 CEST] <mooniac> my .mkv clip is a sequence of segments that I want to selecctively keep or drop, based on time stamps, in the final version. Is there a way to give time stamps in a text file in which I specify the "keep" segments or the "drop" segments?
[17:11:24 CEST] <kepstin> mooniac: you might consider using the ffmpeg concat demuxer, which can take a list of files with input and outpoint. https://www.ffmpeg.org/ffmpeg-formats.html#concat-1
[17:11:37 CEST] <kepstin> mooniac: list the same file multiple times with different inpoints and outpoints
[17:13:08 CEST] <mooniac> great, thanks
[17:13:55 CEST] <kepstin> although that has some caveats - seeking isn't exact (keyframe boundaries only) since it concatenates before decoding.
[17:14:36 CEST] <kepstin> if you want exact seeking you'd have to write out a filter chain (which you can put in a file with -filter_complex_script fwiw)
[17:14:49 CEST] <kepstin> no really simple way
[17:15:00 CEST] <mooniac> well, yes, I would have to have exact segment times, down to the second.
[17:15:08 CEST] <mooniac> OK, then it seems a video editing software is better
[17:17:02 CEST] <kepstin> yeah, this is one of those things where it's not very hard to write an application using ffmpeg apis that does that - but the ffmpeg cli doesn't have the functionality builtin.
[17:17:38 CEST] <mooniac> thanks anyway. Good to hear that someone can at least *confirm* there is no easy way.
[17:21:29 CEST] <kepstin> an easy to use filter could be written that does this... but not optimally, since it would have to spend time decoding and discarding the parts of the video you don't want instead of seeking over and skipping them (filters can't trigger seeking).
[17:21:50 CEST] <kepstin> could be put into the ffmpeg cli itself, but it would be a per-input option, i think. might be ok that way.
[17:33:58 CEST] <kepstin> heh, there's also the hilarious option of making an "edl demuxer" (input format) that runs the decoders inside the demuxer so it can do frame accurate timeline editing with seeking. there's precedent for that with the vapoursynth input i suppose.
[18:30:50 CEST] <ddubya> kepstin, thank you, setting qmin gives me around 60-70mb now
[20:19:36 CEST] <chinknot> is it possible to specify differnet scale filter for different sources in filter_complex? I'd liek to first scale one of the multiple inputs and finally scale the output video, is this what [in] and [out] are for?
[20:20:58 CEST] <furq> chinknot: -i foo -i bar -filter_complex "[0:v]scale=1280:720[tmp];[tmp][1:v]concat,scale=1920:1080"
[20:21:01 CEST] <furq> something like that
[20:21:36 CEST] <chinknot> what is the [tmp] for?
[20:21:55 CEST] <another> output for the first scal
[20:21:59 CEST] <another> *scale
[20:22:39 CEST] <chinknot> and is that concat there because you assumed I was using multiple video sources?
[20:24:49 CEST] <chinknot> actually, where can I read more about [tag] in the documentation? I always get confused whenever people use them
[20:25:28 CEST] <JEEB> probably documented somewhere in the libavfilter filter chain documentation
[20:25:34 CEST] <JEEB> it's basically naming inputs and outputs
[20:25:52 CEST] <JEEB> [some_input]split=2[first_output][second_output]
[20:26:14 CEST] <ddubya> i'm using -c:v mpeg2video -qscale:v 0 -qmin 1 -qmax 1 -g 30, and I get a bitrate around 50-60mb. However there are blocking artifacts in the dark areas of frame, any suggestions?
[20:26:16 CEST] <JEEB> the thing just has to be available in the filter chain
[20:26:40 CEST] <ddubya> whilst still using mpeg2
[20:26:52 CEST] <JEEB> also ffmpeg.c can then -map those filter chain outputs as well like -map '[some_output]'
[20:31:01 CEST] <ddubya> hmm using yuv422p seems to help
[20:36:04 CEST] <furq> chinknot: you can replace concat with any filter that has two inputs and one output
[20:36:18 CEST] <furq> or >1 inputs, i should say
[20:37:43 CEST] <kepstin> ddubya: many of the generic options in https://www.ffmpeg.org/ffmpeg-codecs.html#Codec-Options apply to the mpeg2video encoder if you want to start poking at stuff. it looks like there is some perceptual masking stuff e.g. dark_mask that you could tweak.
[20:38:22 CEST] <kepstin> ddubya: although as far as values and ranges for those options... only way to know what they do is read the c code i guess :(
[20:39:14 CEST] <kepstin> (there's also private options on the mpeg2video encoder itself)
[20:47:26 CEST] <ddubya> kepstin, yes I'm looking at -luma_elim_threshold now, nothing to be found online about it
[22:14:02 CEST] <rustyraptor> Ok so I really don't know if this is the right place to discuss this. It's kinda weird so bare with me.
[22:14:23 CEST] <rustyraptor> So I use 2 programs that use ffmpeg and melt to render and encode videos
[22:14:30 CEST] <rustyraptor> Kdenlive and Shotcut
[22:14:36 CEST] <rustyraptor> and I've had this happen to me twice.
[22:14:49 CEST] <rustyraptor> If I try to open the video while it's rendering in VLC
[22:14:58 CEST] <rustyraptor> The end result is a negative of the video.
[22:15:05 CEST] <rustyraptor> Like the video but with the colors inverted.
[22:15:19 CEST] <rustyraptor> How does that even work?
[22:16:17 CEST] <rustyraptor> It might not be related to me opening the file though. It could be because I used hevc_nvenc instead of h264_nvenc when i encoded them.
[22:16:31 CEST] <rustyraptor> I can't find anything about this anywhere. So I don't know if it's a bug.
[22:16:55 CEST] <kepstin> rustyraptor: no idea what's going on, and you haven't provided enough information to even speculate on it.
[22:21:19 CEST] <eschie> Can someone explain to me why an HLS encoded video would play fine until seeking past the buffer, upon which the audio drops out?
[22:22:24 CEST] <eschie> I'm assuming it has to do with differing segment length between the video and audio?
[22:24:16 CEST] <eschie> If so, would my encoding via ffmpeg benefit from strict duration?
[22:36:04 CEST] <rustyraptor> kepstin: ok so I managed to replicate the process using the ffmpeg cli
[22:36:12 CEST] <rustyraptor> Here is the output
[22:36:20 CEST] <rustyraptor> https://pastebin.com/reCgYmX4
[22:36:40 CEST] <rustyraptor> I will try doing it with h264 to see if it's different. I have a feeling that may be the actual cause. not me trying to open it.
[22:37:39 CEST] <kepstin> rustyraptor: by definition, mp4 files are unplayable while they're encoding, i'd expect players to error out with a 'missing moov' (or similar error) rather than play it
[22:38:24 CEST] <kepstin> the issue is that with mp4 you can't write out some of the required decoder initialization settings stuff until it's done and at the end of the file
[22:38:48 CEST] <kepstin> rustyraptor: if you want to play a file while it's encoding, use a different format.
[22:39:02 CEST] <kepstin> (mkv works ok with current ffmpeg releases and most players, i think)
[22:39:52 CEST] <rustyraptor> Oh ok
[22:40:20 CEST] <rustyraptor> Well I'm mostly worried about the inverted colors. Would that be due to the mp4 format?
[22:40:29 CEST] <rustyraptor> I'll put a screenshot on imgur
[22:40:38 CEST] <kepstin> rustyraptor: it shouldn't be playable at all, i have no idea what your player is doing
[22:41:39 CEST] <rustyraptor> No I mean after it's done rendering.
[22:42:09 CEST] <kepstin> oh, you mean the complete encoded file displays with the colours inverted?
[22:42:12 CEST] <kepstin> which players?
[22:42:16 CEST] <rustyraptor> Yeah it's on vlc
[22:42:32 CEST] <kepstin> only vlc, or can you reproduce it with e.g. mpv, ffplay?
[22:43:01 CEST] <rustyraptor> I'll try one sec
[22:43:41 CEST] <kepstin> and double-check to make sure you haven't accidentally enabled an option in vlc that inverts video :)
[22:43:41 CEST] <rustyraptor> :O it works fine in MPV
[22:43:57 CEST] <rustyraptor> but that can't be because VLC views the previous one fine
[22:44:05 CEST] <rustyraptor> https://imgur.com/a/vwMvQYA
[22:44:32 CEST] <kepstin> also compare the result of hevc_nvenc to e.g. libx265 to see if it's the codec or something with the particular encoder
[22:44:57 CEST] <rustyraptor> Wait what the heck
[22:45:03 CEST] <rustyraptor> there was a negate colors option enabled
[22:45:06 CEST] <rustyraptor> in both
[22:45:10 CEST] <rustyraptor> but only one turned out negative
[22:45:16 CEST] <rustyraptor> how?
[22:45:21 CEST] <kepstin> lol
[22:45:36 CEST] <kepstin> ??? that's vlc for you i guess
[22:45:41 CEST] <rustyraptor> lmao
[22:45:56 CEST] <rustyraptor> I think I remember using it for a thermal camera video
[22:46:16 CEST] <rustyraptor> but why it only shows when I used h265 is blowing my mind right now
[22:46:30 CEST] <rustyraptor> Lets see if it does it in h264
[22:47:07 CEST] <rustyraptor> Nope
[22:47:14 CEST] <rustyraptor> I toggled it on and off and nothing
[22:47:16 CEST] <JEEB> probably depends on the full playback chain in vlc or something if the checkbox has no effect
[22:47:30 CEST] <kepstin> I guess you have a bug to report to vlc, the negate colours option doesn't work with some codec/playback combinations
[22:47:35 CEST] <JEEB> vlc should have a thing to check the full listing of modules utilized
[22:47:46 CEST] <JEEB> but yea, it's a vlc thingamajig
[22:50:44 CEST] <kepstin> i wouldn't be surprised if it's something like vlc is using a hardware decoding playback chain for h264 but software for h265
[22:51:23 CEST] <kepstin> (which is weird, because i'd expect an nvidia card with a hevc encoder to also have a decoder, but whatever)
[23:00:27 CEST] <rustyraptor> Yeah I'll report it to VLC
[23:00:37 CEST] <rustyraptor> though I do see a HEVC decoder in the GPU settings
[23:01:55 CEST] <rustyraptor> https://imgur.com/UOIapOX
[23:02:09 CEST] <rustyraptor> It's at the bottom there. Not as extensive as the others it seems
[00:00:00 CEST] --- Thu Jun 13 2019