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

burek burek021 at gmail.com
Fri Jun 16 03:05:01 EEST 2017


[00:04:55 CEST] <alexpigment> has anyone worked enough with H264_QSV (Intel Quick Sync) to know how to work around blocky/glitchy artifacts during fast motion and crossfades?
[00:05:33 CEST] <kepstin> alexpigment: not really much you could do about it, hardware encoders are kinda fixed. Just throw more bitrate at it.
[00:05:34 CEST] <alexpigment> i can bump up the quality factor even more, but at a certain point, it's like i'm throwing more bits at the whole thing to fix problems with just a small handful of moments
[00:06:01 CEST] <alexpigment> kepstin: hmmm, ok
[00:06:07 CEST] <kepstin> if you can, switch to using a software encoder instead ;)
[00:06:39 CEST] <alexpigment> well, this will be an alternative option, not the only one
[00:07:02 CEST] <alexpigment> this is the "you agree to trade off quality for speed because you bought a crappy CPU" option
[00:07:23 CEST] <alexpigment> having said that, the tradeoffs for nvidia aren't bad at all
[00:07:57 CEST] <alexpigment> as long as you don't need any sort of very specific specs
[00:09:29 CEST] <kepstin> I actually just picked up a pascal-based card for some other stuff, I should try poking at the hardware encoder on it.
[00:16:02 CEST] <alexpigment> kepstin: yeah, i think you'll be surprised
[00:16:30 CEST] <alexpigment> i've been using a pascal card for a few months now
[00:18:21 CEST] <kepstin> (that said, the card I have is the GT 1030, and I don't actually know if it has nvenc block present)
[00:18:40 CEST] <JEEB> the only mode I've used with my 1080 is the 4:4:4 lossless :D
[00:23:54 CEST] <alexpigment> kepstin: the 1030 looks like it's a true pascal rather than a rebrand
[00:24:20 CEST] <alexpigment> nvidia is notorious for just rebranding a 430 as a 520 then as a 610
[00:24:36 CEST] <alexpigment> but it looks like they haven't done that (yet) with their 1000 series
[00:24:37 CEST] <kepstin> yes, but it's GP108, a different die from any of the other cards.
[00:25:00 CEST] <alexpigment> true, but i suspect it'll still be good
[00:25:17 CEST] <alexpigment> most of what i notice between the generations is just speed
[00:25:25 CEST] <alexpigment> so even if it's a little slower, i don't think you'll notice
[00:25:28 CEST] <kepstin> i dunno, in their previous low-power 'gt' card - the gt 730 - apparently they didn't include the nvenc stuff either? :/
[00:25:37 CEST] <alexpigment> hmm
[00:25:44 CEST] <alexpigment> i just tested a 710 a few minutes ago
[00:25:56 CEST] <alexpigment> but maybe the 730 is a double rebrand of a 550 or something
[00:26:37 CEST] <alexpigment> yeah, the DDR3 128-bit version of the 730 is a Fermi rebrand rather than Kepler
[00:26:46 CEST] <kepstin> oh, that's confusing. there's 3 differen cards named 'gt 730'
[00:26:52 CEST] <alexpigment> yeah
[00:27:01 CEST] <alexpigment> like i said, nvidia is notorious for htis
[00:27:03 CEST] <alexpigment> *this
[00:27:04 CEST] <kepstin> there's gf108, and 2 differentgk208
[00:27:11 CEST] <kepstin> so it could be either fermi or kepler
[00:27:33 CEST] <alexpigment> i was trying to help a coworker figure out if their 640 would do nvenc - there are FOUR versions of that card
[00:27:45 CEST] <alexpigment> well, the codename tells you what it is
[00:28:00 CEST] <alexpigment> "GF108" = Fermi, "GK208" = Kepler
[00:28:08 CEST] <alexpigment> the second letter always corresponds with the architecture fwiw
[00:28:35 CEST] <alexpigment> perhaps that's obvious information, but it does take a little leap to connect the two
[00:29:09 CEST] <kepstin> yeah. at least the quadro naming scheme makes it a bit more obvious
[00:29:17 CEST] <kepstin> i guess since people in that market care more abou tit
[00:29:23 CEST] <alexpigment> yeah they use the first letter, right?
[00:29:36 CEST] <kepstin> yeah
[00:29:39 CEST] <DHE> I have a quadro whose code is GM107GL (Maxwell?)
[00:30:20 CEST] <kepstin> well, apparently the quadro stuff was weird with the 'K' series
[00:30:34 CEST] <kepstin> GM107 could be a K1200 or K2200 :/
[00:31:30 CEST] <DHE> there is a bit of ambiguity because there's 2 generations named maxwell
[00:31:44 CEST] <alexpigment> yeah, maxwell is confusing
[00:32:01 CEST] <alexpigment> still, the rebrands that nvidia does are the main source of confusion
[00:32:26 CEST] <alexpigment> if you buy anything below a _50, you have to look it up to know what you're getting
[00:32:42 CEST] <kepstin> at least so far, every single desktop 10xx card has been actually pascal, fwiw
[00:32:54 CEST] <alexpigment> yeah
[00:32:58 CEST] <alexpigment> that's what the wiki says
[00:33:03 CEST] <alexpigment> which is why i think your 1030 will be fine
[00:33:24 CEST] <alexpigment> anyway, i'm heading out
[00:33:33 CEST] <alexpigment> (and screw quick sync)
[00:36:18 CEST] <kepstin> annoying that https://developer.nvidia.com/video-encode-decode-gpu-support-matrix doesn't list the consumer models, only quadro & tesla
[00:37:06 CEST] <DHE> well, you can assume the number of chips is 1 and the capabilities are basically grouped by chipset/generation
[00:37:12 CEST] <kepstin> (and there's no quadro cards with gp108, so I can't get anything from that chart)
[00:38:07 CEST] <DHE> also max sessions = 2
[00:38:16 CEST] <kepstin> but yeah, if it has the same encoder block config as gp107, it'll be nice. 1 nvenc chip, 2 sessions in that case
[00:39:14 CEST] <kepstin> so the question is basically, "did nvidia drop the encoder block from gp108 to make the die smaller/cheaper?" and I don't know the answer to that yet
[00:40:36 CEST] <DHE> maybe they dropped it from the low-end cards, like 1030 (does such a thing exist?)
[00:41:05 CEST] <kepstin> I have a Geforce GT 1030 (GP108), that's what this whole discussion is about ;)
[00:50:17 CEST] <Tatsh> honestly though, nvenc is fast and nice but the quality is lower overall
[00:51:07 CEST] <DHE> that's what it offers. you can have a fast, no-CPU h264 encoder but quality suffers. "slow" mode helps a bit, but it's no match for x264.
[00:51:23 CEST] <Tatsh> it's good enough for live streaming
[00:51:37 CEST] <Tatsh> for most things
[00:51:47 CEST] <Tatsh> like, webcam crap
[00:52:50 CEST] <DHE> video game streamers love it
[00:53:16 CEST] <Tatsh> but video game streamers aren't videophiles
[00:53:58 CEST] <Tatsh> and also the viewers are mostly not (audio|video)philes of any kind
[00:54:08 CEST] <Tatsh> otherwise they'd demand lossless audio :)
[00:57:43 CEST] <kepstin> hmm, so I need anything other than the libraries from the nvidia drivers to work? (or does it need to run in an X display?)
[00:58:04 CEST] <kepstin> I'm just getting a "Cannot init CUDA" when I try to use h264_nvenc over ssh
[00:58:27 CEST] <Tatsh> it doesn't need X
[00:58:53 CEST] <Tatsh> you need nvidia-cuda libraries installed
[00:59:05 CEST] <Tatsh> https://developer.nvidia.com/nvidia-video-codec-sdk
[00:59:24 CEST] <Tatsh> i have cuda-sdk, video_sdk and the drivers
[01:00:33 CEST] <kepstin> looks like the linux nvidia drivers package includes libcuda et all, and the sdk only has headers (which ffmpeg has internal copies of anyways, iirc)
[01:01:45 CEST] <kepstin> https://gist.github.com/kepstin/8f0fad41842bb923da8709267fed0f9d is what I'm seeing
[01:02:18 CEST] <kepstin> hmm, that has a bad pix_fmt, but even if I fix that, same thing.
[01:06:26 CEST] <jkqxz> kepstin:  I believe that the 1030 doesn't have encode at all, just decode.  So, yeah, I think you're doomed.
[01:06:38 CEST] <kepstin> yeah, that's what it's looking like
[01:07:20 CEST] <kepstin> owell, I didn't really have a use for it anyways; just wanted to experiment. If I want to encode some video, that's what the ryzen is for ;)
[01:07:32 CEST] <jkqxz> I don't think nvndia has said anything explicitly about it, though, so it's possible that the problem is somewhere else (drivers not yet updated, say).
[01:09:19 CEST] <kepstin> although I'm guessing def. a driver problem here, because it should at least be initializing cuda before telling me that there's no gppus with encoders.
[01:09:29 CEST] <kepstin> meanwhile the whole cuda init is just failing
[01:10:23 CEST] <kepstin> unless I'm reading the code wrong
[01:13:31 CEST] <kepstin> the decoder isn't working either
[01:30:59 CEST] <alexpigment> kepstin: did you reinstall the most recent drivers?
[01:31:34 CEST] <alexpigment> oh you're on linux - nm
[01:31:42 CEST] <alexpigment> i've only tested windows
[01:32:57 CEST] <livingbeef> I have an image sequence and I'd like to generate a heatmap with changes - either animated (accumulated chages over N images), or just "sum". Any idea of something like that can be done with ffmpeg?
[01:33:45 CEST] <livingbeef> I know I can generate gif with the trasparency optimization, which gives me the layers which only contain chages. I guess that might help.
[01:36:08 CEST] <tapeman> I'm trying to do some captures from my v4l2 device, and changing the x264 profile from fast to medium seems to cause alsa xruns, which show up as audio dropouts- any ideas? https://pastebin.com/44dGQCg2
[01:37:12 CEST] <DHE> you can see the first speed is basically 1.0x (shows 0.992x), but the second is all over the place starting at 0.5x
[01:37:17 CEST] <DHE> your CPU isn't up to medium
[01:40:26 CEST] <tapeman> that's weird- I would think an i7-2600 would be up to handling SD h264- am I doing something wrong here?
[01:42:30 CEST] <furq> it's probably not the issue, but why are you using ac3
[01:42:39 CEST] <furq> it sucks and also the builtin ac3 encoder probably isn't any good
[01:44:49 CEST] <tapeman> for mp4, I thought my options were ac3 or mp3- is one much better than the other?
[01:44:59 CEST] <furq> aac
[01:45:22 CEST] <furq> although mp3 is better than aac
[01:45:24 CEST] <furq> er
[01:45:26 CEST] <furq> although mp3 is better than ac3
[01:45:32 CEST] <furq> aac is better than both
[01:46:29 CEST] <tapeman> okay- I'll try that.  Is there any kind of documentation/guideline on thread_queue_size? It feels like I'm randomly putting numbers into that
[01:48:31 CEST] <DHE> all params are documented in https://ffmpeg.org/ffmpeg-all.html (warning: large file), though that option is a big vague.
[01:49:03 CEST] <DHE> basically a distinct thread does the ALSA work and a queue passes it up to the main ffmpeg thread.
[01:50:26 CEST] <DHE> sufficiently large values will deal with the issue, but only as long as the recording is short-ish
[01:50:51 CEST] <furq> you can probably ignore the "consider increasing thread_queue_size" warning
[01:51:07 CEST] <furq> i get that all the time with vapoursynth and increasing it doesn't do anything
[01:54:18 CEST] <DHE> the description just says "packets". how large are packets from the alsa driver? source code looks like it just takes the minimum (whatever that is)
[01:54:34 CEST] <DHE> worried it might be something pathetic like 128 samples
[01:55:14 CEST] <tapeman> let's assume you're correct- what should I set it to then as a more reasonable setting?
[01:56:15 CEST] <DHE> not knowing the units, I'd say try something absurdly large like 10,000 and see how it works. if that still doesn't work, I propose your CPU is still too weak
[01:56:27 CEST] <tapeman> okay
[01:57:06 CEST] <tapeman> is there anything else about the command that strikes you as weird or unusual?
[02:01:01 CEST] <DHE> I'm assuming the hard drive isn't any kind of bottleneck for IO since this is a rawvideo source
[02:01:57 CEST] <tapeman> doing 4000 or so seemed to let me use -medium profile, so maybe that was it
[02:02:27 CEST] <DHE> what was the final speed multiplier for the medium run?
[02:03:10 CEST] <Threads> dumb question alert
[02:03:25 CEST] <Threads> possible to do gpu audio encoding ?
[02:03:57 CEST] <DHE> not that I'm aware of. Audio encoding isn't that difficult. I can encode AAC in software at ~20x realtime speed
[02:04:40 CEST] <furq> there's flaccl
[02:04:48 CEST] <furq> i don't know of any lossy encoders
[02:05:17 CEST] <tapeman> it looks like .991
[02:05:45 CEST] <DHE> tapeman: that's close enough to realtime that you are probably fine for CPU. just a bad start that caused dropped audio
[02:06:18 CEST] <tapeman> thanks so much for your help here!
[04:32:13 CEST] <TotallyHuman> I have a mp4 video file which I can't import into Premiere, probably because of variable frame rate. When I convert it in ffmpeg, the audio and video are getting out of sync. I have used these 2 commands:
[04:32:20 CEST] <TotallyHuman> ffmpeg -i input.mp4 -c copy -copyts output.mp4
[04:32:26 CEST] <TotallyHuman> ffmpeg -i input.mp4 -c copy -copyts -r 30 output.mp4
[04:32:32 CEST] <TotallyHuman> Could you advise me on how to proceed?
[07:18:46 CEST] <rk[ghost]> is there a way to use ffmpeg to cut a strip out of an audio file, something like ffmpeg -i audio.ogg --start=5s --end-10s cut.ogg?
[08:18:39 CEST] <c_14> rk[ghost]: https://trac.ffmpeg.org/wiki/Seeking
[08:20:35 CEST] <grublet> "-ss is now also "frame-accurate" even when used as an input option. "
[08:20:44 CEST] <grublet> too bad this wasnt a feature when i used ffmpeg more
[08:35:08 CEST] <rk[ghost]> c_14: thanks
[08:35:12 CEST] <rk[ghost]> grublet: too to know!
[09:51:11 CEST] <darshan> HI
[09:51:50 CEST] <darshan> i want to make slideshow with the jpg and png images and audio files but getting issue with concat commands
[09:51:57 CEST] <darshan> can anyone help me
[10:53:49 CEST] <Nacht> Goodmorning all
[10:59:21 CEST] <Nacht> What command do you need to get ffmpeg to create a HLS VOD with .aac segments ? Mine keeps making .ts files
[11:02:55 CEST] <ritsuka> Nacht: I think HSL requires either ts or fragmented mp4
[11:04:12 CEST] <JEEB> it can be raw audio as well
[11:08:54 CEST] <Nacht> Tried using -f segments but that didnt work either
[11:12:05 CEST] <gwohl> i thought HLS only makes .ts segments out of AAC sources
[11:12:32 CEST] <gwohl> can't use AAC in the raw like that, you need a transport stream
[11:12:57 CEST] <Nacht> It uses ADTS, so it should work. Apple has an example stream:
[11:12:58 CEST] <Nacht> https://tungsten.aaplimg.com/VOD/bipbop_adv_example_v2/a1/prog_index.m3u8
[11:13:37 CEST] <ritsuka> yup the specs says "or a Packed Audio file, which is a file containing packed encoded audio samples and ID3 tags, such as AAC with ADTS framing [ISO_13818_7], MP3 [ISO_13818_3], AC-3 [AC_3], or Enhanced AC-3 [AC_3].  Transport of other media file formats is not defined."
[11:13:39 CEST] <JEEB> gwohl: look at the HLS spec
[11:13:50 CEST] <JEEB> it's a semi-idiotic thing but they actually allow raw audio streams
[11:14:15 CEST] <Nacht> Yeah I suprised me as well when I read it at first
[11:14:18 CEST] <JEEB> oh, fun it's up to revision 23
[11:14:19 CEST] <JEEB> https://tools.ietf.org/html/draft-pantos-http-live-streaming-23
[11:17:05 CEST] <darshan> hello i try with -f but does not work
[11:17:18 CEST] <darshan> @Nacht
[11:18:55 CEST] <Nacht> Tried -segment_list and naming them .aac. Tried -f segment with -segment_format aac. Didn't do it either. I wouldnt be suprised if ffmpeg doesnt have it tho
[11:20:10 CEST] <JEEB> yea, libavformat will most likely not let you do it
[11:20:26 CEST] <utopiah_> ffmpeg -i input.mp4 -vf scale=1024:512 -t 30 output.mp4 works (I have the right output file) but scale=2048:1024 or even scale=iw*.5:ih*.5 (since original is 4096:2048) doesn't... does the scale filter have a maximum resolution?
[11:20:34 CEST] <JEEB> because generally you don't want streams without a container. if you are afraid of overhead you'd implement ISOBMFF fragments in HLS
[11:21:12 CEST] <Nacht> Yeah I recon we're better off using an MPEGTS container
[11:22:13 CEST] <Nacht> @utopiah_: which codec are you using ?
[11:23:49 CEST] <utopiah_> h264/aac
[11:25:18 CEST] <Nacht> Which profile ?
[11:26:07 CEST] <Nacht> Cause you need a minimum of 5 using those resolutions. Also, it might be better using HEVC for those.
[11:27:03 CEST] <Nacht> Oh wait, I misread, 4.0 does '2048x1024 at 30.0'
[11:27:33 CEST] <utopiah_> https://gist.github.com/Utopiah/5ba53670160539a5ffe5a004bb9b0006#file-equirec-scale-issue-with-ffmpeg-L17
[11:28:49 CEST] <utopiah_> scale to 1024:512 and 512:256 worked
[11:33:05 CEST] <Nacht> When it doesn't work, does it given an error, or just gives out an incorrect size or corrupt file ?
[11:42:05 CEST] <utopiah_> I dont get any error or warning, just a very small file ~200k that doesn't play
[11:42:21 CEST] <Nacht> what does ffmpeg say about the ouput ?
[11:43:22 CEST] <utopiah_> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f5da4445800] moov atom not found
[11:43:24 CEST] <utopiah_> Silence_high.mp4: Invalid data found when processing input
[11:43:38 CEST] <utopiah_> file Silence_high.mp4
[11:43:41 CEST] <utopiah_> Silence_high.mp4: ISO Media, MP4 Base Media v1 [IS0 14496-12:2003]
[11:44:53 CEST] <furq> pastebin the full encoding command and output
[11:50:26 CEST] <utopiah_> http://vatelier.net/MyDemo/vrt/assets/log.txt
[11:50:44 CEST] <utopiah_> input and output files are in the directory
[11:51:38 CEST] <utopiah_> like I said in lower res it works so without error I dont get why higher res fails silently
[11:52:47 CEST] <furq> er
[11:52:52 CEST] <furq> frahm_high.mp4 plays back fine for me
[11:54:06 CEST] <utopiah_> :| here too, wait a second
[11:56:25 CEST] <utopiah_> I dont get it, maybe was the browser caching
[11:56:29 CEST] <utopiah_> well, sorry about that
[11:56:49 CEST] <furq> well silence_high.mp4 is broken
[11:57:00 CEST] <furq> but i can't really debug that without a log
[11:59:11 CEST] <utopiah_> trying a longer part then will try Silence agaf 1minin,
[12:00:03 CEST] <utopiah_> seems a longer part fails again, could it be a memory limitation?
[12:00:57 CEST] <furq> you'd probably notice if you were getting oom killed
[12:01:07 CEST] <furq> that would cause the moov atom to not be written though
[12:02:12 CEST] <utopiah_> checking https://trac.ffmpeg.org/ticket/596 yep probably that... not supposed to be in a VM though but will investigate
[12:03:37 CEST] <furq> the oom killer logs to the syslog or kern.log
[12:03:48 CEST] <furq> so if you're not getting a "Killed" message then you can check there to see if it's getting oom killed
[12:04:45 CEST] <utopiah_> yes I just did when I redirected the log
[12:05:24 CEST] <utopiah_> well it's just a test so for now I'll stick to a 20sec section, should do, thank you
[12:06:26 CEST] <utopiah_> in fact Im doing it on a remote server, will probably just do it on my machine
[12:07:04 CEST] <furq> you could maybe use a faster preset
[12:07:05 CEST] <utopiah_> sorry for the noise, learning process ;)
[12:07:25 CEST] <furq> faster presets will generally use less memory
[12:07:33 CEST] <furq> or you could just lower rc-lookahead directly
[12:39:17 CEST] <Fyr> guys, fmpeg -hwaccels shows cuvid and vaapi, while the computer has 0 NVidia cards and doesn't have Intel drivers pre-installed.
[12:39:26 CEST] <Fyr> however, cuvid works.
[12:39:34 CEST] <Fyr> is it a dummy?
[12:43:32 CEST] <Fyr> do you happen to know a Linux distro with ffmpeg's hwaccels working?
[12:47:32 CEST] <Fyr> so far I know, it requires Linux kernel recompilation to turn them on.
[12:48:22 CEST] <Fyr> I failed to install even Intel's openCL drivers; it looks like my Ubuntu kernel is not generic.
[12:50:24 CEST] <utopiah_> (OK definitely doing it on my local machine and not on the server ;)
[12:51:34 CEST] <jkqxz> Fyr:  What hwaccels do you want?  Debian/Ubuntu stuff is compiled with at least VDPAU and VAAPI, I think.
[12:51:49 CEST] <k_sze[work]> I need help switching from avcodec_encode_video2 to avcodec_send_frame/avcodec_receive_packet
[12:52:02 CEST] <Fyr> jkqxz, any hwaccel available for Intel CPU.
[12:52:07 CEST] <Fyr> QSV, I guess
[12:52:07 CEST] <DHE> k_sze[work]: be specific
[12:52:17 CEST] <k_sze[work]> Mainly, I don't understand how ref counting works when I use the new API.
[12:53:01 CEST] <jkqxz> Fyr:  VAAPI, then?  (Unless you want to recompile your kernel and install all of the proprietary stuff to make libmfx work.)
[12:53:10 CEST] <k_sze[work]> DHE: am I supposed to unref the AVFrame as soon as I have called avcodec_send_frame?
[12:53:28 CEST] <Fyr> jkqxz, does VAAPI mean hardware decode?
[12:53:54 CEST] <k_sze[work]> DHE: because logically, I have already sent the AVFrame into the codec pipeline, and my application doesn't need the AVFrame anymore.
[12:54:15 CEST] <k_sze[work]> DHE: I suppose the codec takes a ref of the AVFrame when I call avcodec_send_frame?
[12:54:31 CEST] <jkqxz> Yes.  On Intel, VAAPI uses the same Quick Sync hardware as the proprietary QSV/libmfx stuff does.
[12:54:50 CEST] <DHE> k_sze[work]: avcodec_send_frame says ownership remains with the caller. so yes, you need to unref it or free it entirely
[12:55:49 CEST] <k_sze[work]> DHE: Is it safe to call av_frame_free on the AVFrame right after avcodec_send_frame?
[12:56:00 CEST] <DHE> I just said yes
[12:56:37 CEST] <k_sze[work]> You said "unref it or free it entirely", so if I don't call av_frame_free, what other function would I call to unref it only?
[13:03:15 CEST] <k_sze[work]> And I suppose that I won't need to call av_init_packet because avcodec_receive_packet will be responsible for allocating a refcounted packet?
[13:03:45 CEST] <k_sze[work]> which means I need to unref or free the packet after I have muxed it with av_interleaved_write_frame?
[13:05:52 CEST] <k_sze[work]> Hmm, the doc says that Libavformat will always take care of freeing the packet, even if [av_interleaved_write_frame] fails.
[13:23:47 CEST] <k_sze[work]> And next, AVCodecContext.coder_type and AVCodecContext.context_model are deprecated.
[13:24:10 CEST] <k_sze[work]> I'm supposed to set encoder private options instead, but what are the new names of the private options?
[13:24:20 CEST] <k_sze[work]> It's not mentioned in avcodec.h
[13:28:20 CEST] <k_sze[work]> This? libavcodec/options_table.h:329:{"coder", NULL, OFFSET(coder_type), AV_OPT_TYPE_INT, {.i64 = DEFAULT }, INT_MIN, INT_MAX, V|E, "coder"},
[13:28:42 CEST] <k_sze[work]> (So it's named "coder" instead of "coder_type")?
[13:41:24 CEST] <roasted> I'm trying to script a jpg snapshot capture of an IP camera via ffmpeg. If I run "ffmpeg -i rtsp://ip.to.camera/path/to/camera -vframems 1 pic1.jpg", it works, but I get a 461 transport error. Curious on what that may be, despite still obtaining the jpg successfully?
[13:41:44 CEST] <roasted> -vframes*
[14:39:49 CEST] <Nacht> I'm testing out with -vframes 1 to get a screenshot from a current ts file. However, I'd like to take 4 screenshots at 4 different times (0 sec, 2 sec, 4 sec and 6sec). Is it possible doing this faster then just with -ss ? As I notice that the 6 sec screen takes allot longer due to the seeking
[15:46:25 CEST] <zack_s_> kepstin: I have a video which I need to cut without re-encoding, I use following cmd line: ffmpeg -ss 00:00:09.000 -i input.mp4 -vcodec copy -acodec copy -t 00:00:15.000 output.mp4
[15:46:48 CEST] <zack_s_> however, the cutted video ist 16 seconds long, altought I have every 30 FPS a key frame
[15:46:53 CEST] <zack_s_> the video ist 30FPS
[16:13:07 CEST] <styler2go> In general, does it take longer to compress a video or to save a video file uncompressed?
[16:16:47 CEST] <Fyr> to compress, of course
[16:19:18 CEST] <furq> depends how slow your disk is
[16:26:44 CEST] <Fyr> >> In general
[16:27:54 CEST] <kepstin> zack_s_: in most video formats, you can put the end point of a cut not on a keyframe...
[16:28:02 CEST] <kepstin> it's only the start point that has to be on one
[16:28:57 CEST] <zack_s_> kepstin: okay? how can ffmpeg do automaticall adjust the cut marks?
[16:29:09 CEST] <zack_s_> automatically adjust the cut marks
[16:29:20 CEST] <zack_s_> what do I have to do in order to get it working?
[16:29:40 CEST] <kepstin> zack_s_: what do you mean? it's doing what you asked it to do, give a video section approximately 15 seconds long starting at as close to 9 seconds in as possible
[16:30:35 CEST] <zack_s_> kepstin: ahhh wait
[16:30:41 CEST] <zack_s_> the last parameter is the duration?
[16:30:49 CEST] <kepstin> -t is duration, yes
[16:30:52 CEST] <zack_s_> the absolute end time
[16:30:55 CEST] <zack_s_> ahhhh
[16:30:58 CEST] <zack_s_> that was my problem
[16:48:55 CEST] <Pandela> Aye, so I have an image sequence of about 8000+ frames but the result is slightly longer and doesn't match the original videos audio length
[16:49:17 CEST] <Pandela> Is there a way to sync the video length to match audio?
[17:08:02 CEST] <furq> if the source is cfr then it should just work
[17:10:26 CEST] <zack_s_> kepstin: I got some frame freezes at cut marks
[17:10:40 CEST] <zack_s_> is this normal?
[17:18:49 CEST] <kepstin> not sure what you mean by frame freezes, but I wouldn't be surprised if there's some weirdness at the end of cuts due to b-frames
[17:20:15 CEST] <kazuma_> won't it cut to the nearest i-frame and not cut on b or p frames
[17:21:03 CEST] <kepstin> the *start* of the cut will be on an I frame with -c:v copy, but the end won't necessarily be.
[17:22:08 CEST] <Nacht> IDR frame
[17:23:07 CEST] <furq> i've noticed weird behaviour around start points with -ss/-t
[17:23:16 CEST] <furq> i think it's to do with audio
[17:23:49 CEST] <furq> if i cut five seconds before a keyframe, it'll just show the first video frame for five seconds while the audio plays
[17:23:53 CEST] <furq> at least with some formats it does that
[17:24:58 CEST] <Nacht> That's cause you don't have an I frame, so it doesnt really show much till the first i frame it meets
[17:25:21 CEST] <Nacht> Altho, IDR should be the better term here
[17:26:39 CEST] <kepstin> hmm, that kinda makes sense given how most audio formats let you cut between any frames (module preroll that some codecs require)
[17:30:06 CEST] <furq> yeah
[17:30:22 CEST] <furq> it does make cutting more complicated though
[17:31:22 CEST] <furq> i guess it makes sense that it goes by the stream which it can cut at the point you requested
[17:31:27 CEST] <furq> it'd be nice if you could specify though
[17:33:01 CEST] <zerodefect> When decoding, it safe to call av_read_frame in parallel with av_send_packet()/av_receive_frame() ?
[17:40:36 CEST] <DHE> yes. the codec and format/container workers have no relation to each other
[17:44:36 CEST] <zack_s_> kepstin: can  I not specify the exact iframe to iframe cut marks, so that there are now issues at all?
[17:45:28 CEST] <kepstin> zack_s_: there's probably always gonna be some misalignment from audio vs video, but you should be able to get it down to ~10ms difference on average with most codecs.
[17:45:30 CEST] <zerodefect> Thanks DHE
[17:46:12 CEST] <kepstin> zack_s_: no way to do that automatically, you're gonna have to use e.g. the ffprobe -show_frames output to figure out where you want to cut, I guess :/
[17:46:49 CEST] <kepstin> if it's CFR video and you know it has a fixed gop size you could just calculate the times I guess
[17:48:07 CEST] <DHE> zerodefect: if the AVWhateverContext* being passed in thread A is unrelated to the AVSomethingContext* being passed in thread B, it's almost always safe to do so
[17:48:21 CEST] <zack_s_> kepstin: yeah, I mean this
[17:48:31 CEST] <zack_s_> with fprobe calculate
[17:48:39 CEST] <DHE> since AVFormatContext and AVCodecContext are not related, have fun
[17:48:52 CEST] <zack_s_> what is CFR video?
[17:49:35 CEST] <DHE> constant framerate
[17:51:30 CEST] <zack_s_> can I use fprobe to get me the next I frame form a certain position?
[17:51:45 CEST] <zerodefect> Thanks DHE.  This will be an interesting task. :)
[17:52:21 CEST] <kepstin> zack_s_: with -show_frames, it prints out per-frame info including the frame type and timestamps, so you could figure it out from that. I dunno if there's a faster way to do it, maybe someone here is an ffprobe expert? :)
[17:53:17 CEST] <DHE> zerodefect: you should see my app...
[17:54:22 CEST] <zerodefect> Was it worth doing?  Was there a noticeable performance improvement using parallel processing?
[17:54:54 CEST] <zerodefect> I suppose it's difficult to quantify
[17:56:15 CEST] <DHE> I needed it because I'm doing multiple encodes on the same content in real-time. threading was mandatory.
[17:56:56 CEST] <c_14> zack_s_: something like ffprobe -count_frames -show_entries frame=best_effort_timestamp_time,key_frame -select_streams v -v quiet -hide_banner -of flat $FILE | grep -E -A 100 '$TIME' | grep 'key_frame=1' -A 1 | head -n2
[17:57:22 CEST] <c_14> (It might be better and definitely more robust to output json and use a script to do this instead)
[17:57:31 CEST] <zerodefect> DHE: So was your use case threading av_send_frame/av_receive_packet ?
[17:57:44 CEST] <c_14> But that may or may not work as long as your input timestamp resolution isn't too exact
[17:57:55 CEST] <zack_s_> c_14: what does this give me?
[17:58:16 CEST] <c_14> the next I-frame after a certain timestamp
[18:00:43 CEST] <zack_s_> c_14: seems not to work
[18:00:54 CEST] <zack_s_> I get no output at all
[18:01:17 CEST] <zack_s_> ./ffprobe -count_frames -show_entries frame=best_effort_timestamp_time,key_frame -select_streams v -v quiet -hide_banner -of flat "1920x1080_30fps_2min.mp4" | grep -E -A 100 '00:00:08.123' | grep 'key_frame=1' -A 1 | head -n2
[18:01:29 CEST] <c_14> the timestamp is in seconds
[18:01:45 CEST] <c_14> try just 8
[18:02:07 CEST] <c_14> 8.1 should probably work as well
[18:02:21 CEST] <zack_s_> nothing
[18:02:27 CEST] <zack_s_> but no really fast nothing
[18:02:27 CEST] <zack_s_> :D
[18:02:44 CEST] <c_14> try getting rid of the greps and checking the output manually
[18:02:47 CEST] <Threads> windows or linux ?
[18:02:50 CEST] <c_14> Like I said, this isn't a very robust solution
[18:02:51 CEST] <zack_s_> windows
[18:02:56 CEST] <c_14> oh
[18:02:58 CEST] <c_14> well
[18:03:00 CEST] <c_14> that won't work then
[18:03:09 CEST] <zack_s_> I have a bash
[18:03:14 CEST] <c_14> ah, then it might
[18:03:28 CEST] <c_14> try getting rid of all the greps I guess
[18:04:14 CEST] <zack_s_> ./ffprobe -count_frames -show_entries frame=best_effort_timestamp_time,key_frame -select_streams v -v quiet -hide_banner -of flat "1920x1080_30fps_2min.mp4"
[18:04:17 CEST] <zack_s_> you mean this?
[18:04:23 CEST] <zack_s_> no output at all
[18:04:44 CEST] <c_14> get rid of -v quiet
[18:09:18 CEST] <zack_s_> okay, this works
[18:59:57 CEST] <FishPencil> What is the "sane range" for x265? CRF 18 is considered "visually lossless" for x264, what is it for x265?
[19:47:29 CEST] <kepstin> nobody really knows, as far as I can tell? The scale has changed between x265 versions, too, at least for 10bit (apparently)
[19:48:47 CEST] <kerio> does x265 support actual lossless
[19:55:19 CEST] <furq> well the default crf for x265 is 28
[19:55:29 CEST] <furq> so probably just add 5 to what you'd use with x264 and hope for the best
[19:56:04 CEST] <furq> https://pbs.twimg.com/media/CnqQ4PTWEAQXZDC.jpg
[19:56:06 CEST] <furq> looking good kerio
[19:56:50 CEST] <kerio> furq: https://media.giphy.com/media/DpN771RFKeUp2/giphy.gif
[19:57:14 CEST] <furq> that is an extremely assange dance
[19:59:00 CEST] <kepstin> kerio: yes, you can use it with ffmpeg by using '-x265-params lossless=1' iirc
[19:59:26 CEST] <kerio> not -crf 0? :(
[20:07:58 CEST] <kepstin> "-crf 0" isn't lossless on 10bit x264 either
[20:08:16 CEST] <kepstin> on x264, the recommended way to request lossless is "-qp 0"
[20:13:16 CEST] <FishPencil> How do you pipe to ffmpeg without quality loss? ffmpeg -i in.mp4 -c:v libx265 - | ffmpeg -i - -vframes 1 out.png
[20:14:06 CEST] <kepstin> FishPencil: I'm not sure what you're trying to do there, that example should obviously be done in a single command without any pipes
[20:14:48 CEST] <FishPencil> kepstin: I want to export a single frame that was encoded with x265 to a png
[20:15:03 CEST] <kepstin> but in general - to avoid quality loss, don't re-encode. So either use -c copy, or decode to a raw format, or transcode to a lossless format.
[20:15:40 CEST] <kepstin> FishPencil: to grab a single frame from a video, just do "ffmpeg -i in.mp4 -vframes 1 out.png" ...
[20:15:55 CEST] <FishPencil> kepstin: I want it to be compressed with x265 first
[20:16:08 CEST] <FishPencil> kepstin: This is for a quality compare
[20:16:29 CEST] <kepstin> well, recompressing any video with a lossy codec will cause quality loss, and that has nothing to do with the pipe
[20:17:23 CEST] <kepstin> i mean, you could pick different x265 settings to change the amount of quality loss (or even do lossless), but if you did that, there'd be no point in doing the transcode before grabbing the png...
[20:18:39 CEST] <FishPencil> I'm trying to compare CRF vales in x265. The -crf option will be added but is not shown. I'd like to avoid encoding the entire input media to save a single frame for comparison sake
[20:19:33 CEST] <FishPencil> ffmpeg -i in.mp4 -ss 00:01:00 -c:v libx265 -crf 18 -vframes out.png
[20:19:38 CEST] <FishPencil> Something logically like that
[20:20:15 CEST] <kepstin> FishPencil: ah, in that case, yeah, piping to a second ffmpeg to to the transcode to png makes sense. you can't do 2 encodes on the same video in one ffmpeg command
[20:20:16 CEST] <FishPencil> -vframes 1*
[20:20:31 CEST] <kerio> FishPencil: wouldn't what you literally just said work
[20:20:39 CEST] <kepstin> FishPencil: your original command should be basically ok
[20:20:47 CEST] <kerio> well you need a -f mp4 or something
[20:21:03 CEST] <kepstin> mp4 can't be streamed, do matroska or mpegts or something
[20:21:09 CEST] <kerio> nut :3
[20:23:44 CEST] <FishPencil> -ss 00:01:00 -c:v libx265 -crf 30 -f matroska - | ffmpeg -i - -vframes 1 seems to work, though I'm getting 'av_interleaved_write_frame(): Invalid argument' and 'Error writing trailer of pipe:: Invalid argument'
[20:23:55 CEST] <kerio> FishPencil: also note that you'd only get keyframes this way
[20:24:34 CEST] <FishPencil> kerio: Wouldn't that still be representative of a target CRF?
[20:24:43 CEST] <kerio> sure
[20:25:50 CEST] <kepstin> sure, but it wouldn't be representative of a whole video encoded with the codec, depending on psy motion optimizations, bitrate allocation between frame types, etc.
[20:26:42 CEST] <FishPencil> Is there a better way to compare?
[20:30:10 CEST] <kepstin> it's kind of funny, because e.g. x264 has a bunch of tunes that tweak its setting to give advantages in different artificial image quality tests.
[20:30:20 CEST] <kepstin> e.g. "-tune psnr" or "-tune ssim" optimizes for specific visual quality metrics (by turning off its psychovisual optimizations), and "-tune stillimage" preserves noticable details that wouldn't be seen on an image in motion.
[20:31:04 CEST] <kepstin> but a general video, in motion, will generally look best with none of those tunes enabled.
[20:33:21 CEST] <FishPencil> So is there a better way to compare?
[20:41:04 CEST] <kepstin> i dunno. THe 'vmaf' stuff by Netflix https://github.com/Netflix/vmaf doesn't seem /entirely/ terrible.
[20:41:42 CEST] <kepstin> and for reasonably short clips, double-blind testing?
[20:43:55 CEST] <FishPencil> I'm not sure why you couldn't just compare a still keyframe from the source to an encoded one
[20:44:20 CEST] <furq> because that only tells you how well keyframes are compressed
[20:44:54 CEST] <FishPencil> which is fine if you're just trying to find a crf value that appears visually lossless
[20:49:25 CEST] <kepstin> for a keyframe only video, sure ;), and it'll probably give you a value that's higher quality than you need because of details that you'd only notice in still images.
[20:49:51 CEST] <kepstin> then again, it's kinda hard to tell
[20:50:45 CEST] <kepstin> If I was doing this, I'd encode some short video segments (20-30s?) in different formats, retranscode to the same lossless format for all of them, then do double-blind comparisons of the motion clips.
[20:50:51 CEST] <kepstin> probably the best you could do? :/
[20:50:59 CEST] <kepstin> labour-intensive tho
[21:28:42 CEST] <FishPencil> I'm surprised there isn't an easier way. The point of doing stills is so you can look back and forth between the two to look for details. That's pretty hard with a moving image.
[21:29:39 CEST] <furq> is this something you'd expect video codec developers to optimise for
[21:30:05 CEST] <kerio> i'd expect video codec developers to optimize for benchmarks ye :3
[21:30:07 CEST] <FishPencil> I suppose you could crop half of the video horizontal wise and the same for the encoded, then put them next to each other
[21:31:21 CEST] <FishPencil> Then once the line between them becomes hard to notice you know you've hit a good point
[21:32:21 CEST] <FishPencil> Is ffv1 a decent lossless video codec in FFmpeg?
[21:32:25 CEST] <furq> yes
[21:32:39 CEST] <FishPencil> As in well suited for this test?
[21:33:37 CEST] <furq> as in a decent lossless video codec
[21:33:45 CEST] <furq> anything would be well suited for this test
[21:33:54 CEST] <furq> you haven't told us what other constraints you have
[21:33:55 CEST] <kerio> ffvhuff is much much much much much much MUCH faster
[21:34:13 CEST] <furq> yes and it also compresses (much){8} less well
[21:34:24 CEST] <FishPencil> furq: There are none? Storage and processing power aren't an issue
[21:34:25 CEST] <furq> missing a space there but never mind
[21:34:40 CEST] <furq> well those are contrasting concerns
[21:34:47 CEST] <furq> if you care about speed use ffvhuff, if you care about size use ffv1
[21:34:58 CEST] <furq> if you care about compatibility then don't use either
[21:35:19 CEST] <FishPencil> I don't care about either, I'm simply going to go to lossless for a comparison
[21:36:17 CEST] <furq> well you have to care about one more than the other or you'll never be able to choose
[21:36:33 CEST] <FishPencil> I'll use ffv1 lol
[21:45:47 CEST] <kerio> isn't ffv1 a standard
[21:45:59 CEST] <kerio> an open standard used by library of congress and stuff like that
[21:47:47 CEST] <furq> yeah but there's no vfw/dshow codec for it so it won't work in a lot of windows nles
[21:47:54 CEST] <furq> and i don't think there's a quicktime codec either so you're fucked on osx as well
[21:48:16 CEST] <furq> also idk if it's actually a standard yet
[21:49:07 CEST] <furq> there's an ietf standardisation effort in progress
[21:49:28 CEST] <furq> In 2015, the International Federation of Television Archives (FIAT/IFTA) mentioned FFV1 explicitly in their call-for-presentations for their annual World Conference, asking "Is FFV1 the new JPEG2000?"
[21:49:32 CEST] <furq> lol fuck
[21:49:34 CEST] <FishPencil> Is it possible to do this in one command? Encode the source to x265, crop it and pass it to a 2nd ffmpeg though a pipe, which takes the x265 encode and combines it with the source in another crop to save the output as ffv1?
[21:50:02 CEST] <furq> yeah
[21:51:20 CEST] <furq> ffmpeg -i foo.mp4 -c:v libx265 -vf crop=123:456 -f nut - | ffmpeg -i - -i foo.mp4 -filter_complex "[1:v]crop=789:012[tmp];[0:v][tmp]hstack" -c:v ffv1 out.nut
[21:52:21 CEST] <FishPencil> I was real close to that
[21:52:43 CEST] <kerio> >when you nut but she keeps encoding
[21:53:19 CEST] <furq> no
[21:53:39 CEST] <kerio> k :(
[21:56:52 CEST] <zerodefect> DHE: Are you about? Do you have experience using 'FF_THREAD_FRAME' or 'FF_THREAD_SLICE' in combination with a custom 'execute' function? I've written some sample code to try it out, but I can't get the library to call my custom execute fn.
[21:57:14 CEST] <zerodefect> Should mention that I'm talking about encoding :)
[22:00:26 CEST] <FishPencil> Is there a way to seek and limit the duration of the in.mov in the pipe ffmpeg? ffmpeg -i in.mov -map 0:v -ss 00:01:00 -t 10 -vf "crop=1/2*iw:ih:0:0" -c:v libx265 -crf 20 -f matroska - | ffmpeg -i - -i in.mov -ss 00:01:00 -t 10 -filter_complex "[1:v]crop=1/2*iw:ih:1/2*iw:0[tmp];[0:v][tmp]hstack" -c:v ffv1 out.mkv
[22:04:45 CEST] <FishPencil> Or does the cutting need to happen before?
[22:05:26 CEST] <furq> that should work
[22:05:35 CEST] <furq> oh nvm i'm looking at the wrong side
[22:06:17 CEST] <furq> you'd need to use -ss and -t as input options before in.mov
[22:06:34 CEST] <furq> certainly -ss anyway
[22:06:40 CEST] <furq> it doesn't really matter with -t
[22:06:42 CEST] <FishPencil> I'll just cut them before,
[22:06:50 CEST] <furq> yeah that'll be quicker anyway
[22:06:54 CEST] <furq> especially if you're doing this a lot
[22:06:56 CEST] <atomnuker> zerodefect: just set the callback, that's all that's needed
[22:07:04 CEST] <atomnuker> and the thread mode
[22:07:27 CEST] <zerodefect> atomnuker: Can i show you some sample code via PasteBin?
[22:10:22 CEST] <FishPencil> Amazing that FFmpeg can do this
[22:14:30 CEST] <FishPencil> It looks great btw, can we agree that this is a proper comparison?
[22:21:15 CEST] <cableguy> hey team
[22:21:24 CEST] <cableguy> im using -ss and -t to split .vob file
[22:21:30 CEST] <cableguy> but it looks like its reencoding the audio
[22:21:38 CEST] <cableguy> how do i split the vob untouched with no reencode?
[22:22:08 CEST] <FishPencil> cableguy: You mean just the video?
[22:23:25 CEST] <relaxed> cableguy: -map 0 -c copy
[22:24:15 CEST] <furq> are you splitting it by title/pgc
[22:24:27 CEST] <furq> because you probably shouldn't use ffmpeg for that
[22:26:49 CEST] <cableguy> ur probably right
[22:26:56 CEST] <cableguy> but i cant find any command line on windows
[22:27:00 CEST] <cableguy> can you recommend any
[22:27:28 CEST] <furq> use pgcdemux on windows
[22:27:40 CEST] <cableguy> is it cli
[22:27:44 CEST] <furq> it has a cli
[22:27:46 CEST] <cableguy> im sure i had it and it was gui
[22:28:02 CEST] <cableguy> funny i found mkvmerge actually splits vob to vob but it adds its matroska headers
[22:28:06 CEST] <furq> it's a pain in the arse to use but it'll at least be accurate
[22:28:27 CEST] <furq> i generally just used the gui instead
[22:28:28 CEST] <madprops> hi, I have an an mp4 with no sound and i have an aac audio file. I want to merge them but have the aac start after the first 4 seconds. Anyone knows how to do that?
[22:28:41 CEST] <furq> -itsoffset
[22:28:46 CEST] <furq> or reencode the audio and -af adelay
[22:28:52 CEST] <cableguy> is the pgcdemux.exe same one file for gui and cli
[22:28:55 CEST] <furq> yeah
[22:29:20 CEST] <relaxed> with -itsoffset it will need to be in a container, like .m4a
[22:29:45 CEST] <kepstin> well, yes, but you can't merge audio and video without putting it into a container...
[22:29:58 CEST] <relaxed> no, I meant the audio input
[22:30:43 CEST] <cableguy> whats the help switch for pgcdemux cli
[22:30:47 CEST] <furq> -help
[22:31:07 CEST] <cableguy> its not working
[22:31:15 CEST] <cableguy> i get invalid input type and then it launches gui
[22:31:27 CEST] <furq> https://www.videohelp.com/software/PgcDemux
[22:31:30 CEST] <furq> you need that version
[22:31:35 CEST] <furq> the MOD version
[22:31:51 CEST] <madprops> furq, i tried this ffmpeg -i 2bil.mp4 -i audio1bil.aac -itsoffset 4.1 -c copy test.mp4
[22:31:56 CEST] <furq> also it shows the help text in a dialog box which is fucking stupid
[22:32:05 CEST] <madprops> but it's wrong
[22:32:12 CEST] <madprops> says im applying itsoffset to the output file
[22:32:17 CEST] <furq> itsoffset is an input option
[22:32:20 CEST] <furq> move it before -i
[22:32:41 CEST] <relaxed> -itsoffset 4.1 need to be before the audio, and I believe you need to remux the aac file into .m4a first
[22:34:15 CEST] <madprops> this made a video ffmpeg -i 2bil.mp4 -itsoffset 4.1 -i audio1bil.aac -c copy test.mp4
[22:34:21 CEST] <madprops> but without the audio
[22:34:28 CEST] <madprops> relaxed, do i have to make it m4a then?
[22:35:05 CEST] <cableguy> so is it -customvob with all the flags or -novob furq
[22:35:43 CEST] <relaxed> do this, ffmpeg -i audio1bil.aac -c copy audio1bil.mka", then "ffmpeg -i 2bil.mp4 -itsoffset 4.1 -i audio1bil.mka -map 0 -map 1 -c copy test.mp4"
[22:36:32 CEST] <furq> i've never really used the cli
[22:36:46 CEST] <furq> i expect you want customvob though
[22:36:55 CEST] <furq> i assume that creates a vob instead of demuxing the streams
[22:38:04 CEST] <furq> afaik you want -vob -nom2v -noaud
[22:38:17 CEST] <furq> or -m2v -aud -novob if you do want the streams demuxed
[22:38:34 CEST] <madprops> relaxed, it merged them but it didn't delay the audio
[22:39:51 CEST] <relaxed> try -itsoffset 00:00:04.1
[22:40:22 CEST] <madprops> maybe the decimal is wrong?
[22:40:34 CEST] <madprops> i'll try that
[22:41:16 CEST] <madprops> nope
[22:41:21 CEST] <madprops> still no delay
[22:42:34 CEST] <cableguy> furq, nothing is happening it doesnt do anyuthing, doesnt print any errors
[22:43:10 CEST] <cableguy> wait up
[22:43:15 CEST] <cableguy> input has to be .ifo
[22:43:23 CEST] <cableguy> i cant just select a vob
[22:43:27 CEST] <furq> yeah
[22:44:38 CEST] <relaxed> madprops: works for me
[22:44:40 CEST] <ChocolateArmpits> How should I test for freezes or hangs? I've had a livestream encode go for 7 days and then it just stopped with no messages.
[22:45:15 CEST] <ChocolateArmpits> The memory usage was also good
[22:45:46 CEST] <ChocolateArmpits> Excuse me, it didn't stop, it just froze
[22:46:42 CEST] <kepstin> yeah, I can't get audio delay to work with itsoffset either, dunno what's up. I can delay video, but not audio (whether i'm copying or re-encoding)
[22:46:43 CEST] <kepstin> hmm.
[22:47:04 CEST] <ChocolateArmpits> kepstin, did you try using asetpts?
[22:47:10 CEST] <relaxed> kepstin: is the audio in a container?
[22:47:22 CEST] <kepstin> relaxed: either way same result
[22:47:43 CEST] <kepstin> (i tried both standalone aac and acc-in-mp4)
[22:48:53 CEST] <cableguy> furq, wait so how do you set duration or size when splitting vobs
[22:49:50 CEST] <relaxed> kepstin: command?
[22:49:51 CEST] <Threads> you still trying to get frameacurate cutting ?
[22:50:04 CEST] <madprops> relaxed, weird hmm, thanks for the help
[22:50:12 CEST] <furq> you don't
[22:50:19 CEST] <furq> you select a pgc
[22:50:28 CEST] <relaxed> I tested with aac in mp4 and that worked as well.
[22:50:31 CEST] <furq> or vob id, or chapter, or angle, or whatever
[22:50:52 CEST] <furq> if you just want to split at an arbitrary timestamp then use ffmpeg
[22:51:00 CEST] <furq> i assumed you were splitting titles
[22:51:19 CEST] <kepstin> relaxed: I'm using "ffmpeg -v debug -f lavfi -i testsrc -itsoffset 10 -i test.m4a -c copy -c:v libx264 -t 40 test.mp4" and the audio is not delayed by 12 relative to the video :/
[22:51:47 CEST] <relaxed> use video in a container
[22:51:56 CEST] <kepstin> if I move the -itsoffset to in front of the video, then the video is correctly delayed by 10s
[22:53:55 CEST] <kepstin> same result if I put the video in a container as a separate step.
[22:56:10 CEST] <kepstin> there's been a longstanding ticket open for this, it looks like: https://trac.ffmpeg.org/ticket/1349 :/
[22:56:52 CEST] <FishPencil> furq: I noticed some artifacting on the edge if the x265 stream was cropped and compressed. This fixed it: [0:v]crop=iw/2:ih:iw/2:0[right];[1:v]crop=iw/2:ih:0:0[left];[left][right]hstack
[22:57:21 CEST] <madprops> relaxed, "Unfortinately -itsoffset option works only for video streams. Do not use it for audio."
[22:57:27 CEST] <cableguy> furq, so how you split without reencoding with ffmpeg, i select size or timestamps but it converts audio bitrate for no reason
[22:57:36 CEST] <furq> -c copy
[22:57:40 CEST] <relaxed> strange that it works for me
[22:58:21 CEST] <madprops> he's probably wrong
[22:58:26 CEST] <madprops> im reading about adelay now
[22:59:00 CEST] <madprops> also there's this relaxed https://trac.ffmpeg.org/ticket/1349
[22:59:09 CEST] <relaxed> madprops: try -i audio1bil.mka -itsoffset -4.1 2bil.mp4 ...
[22:59:50 CEST] <kepstin> I don't think putting a negative adjustment on the video works when muxing to mp4 :/
[23:01:10 CEST] <madprops> yeah that didn't work
[23:01:32 CEST] <relaxed> it works with matroska
[23:02:34 CEST] <relaxed> it's hacky, but then remux the matroksa to mp4 :)
[23:03:57 CEST] <kepstin> hmm, not working for me muxing to mkv either, like ffmpeg -itsoffset -10 -i test.m4v -i test.m4a -c copy test.mkv
[23:04:10 CEST] <kepstin> positive offset works there, of course.
[23:04:28 CEST] <relaxed> no, put the audio before -itsoffset
[23:04:57 CEST] <cableguy> furq, ffmpeg -i VTS_01_1.VOB -c copy -ss 00:00:00 -t 00:10:00 -target pal-dvd out1.VOB task manager shows 50% cpu so its reencoding something?
[23:05:24 CEST] <furq> well yeah you're using -target
[23:05:30 CEST] <furq> don't
[23:05:33 CEST] <kepstin> relaxed: nope. "ffmpeg -i test.m4a -itsoffset -10 -i test.m4v -c copy test.mkv" they still both start at the same time :/
[23:05:45 CEST] <madprops> relaxed, i think the problem might be that the video has an audio track, though it's just silence
[23:05:59 CEST] <kepstin> hmm, my test video doesn't have any audio track
[23:06:08 CEST] <relaxed> kepstin: can you put your samples up somewhere?
[23:06:09 CEST] <cableguy> hey ur right
[23:06:43 CEST] <madprops> kepstin, hmm
[23:07:26 CEST] <kepstin> relaxed: make them yourself: "ffmpeg -f lavfi -i testsrc -c:v libx264 -pix_fmt nv12 -t 30 test.m4v" and "ffmpeg -f lavfi -i sine -c:a aac -t 30 test.m4a"
[23:07:38 CEST] <relaxed> madprops: after the last input add -map 0 -map 0:v
[23:08:09 CEST] <madprops> oh wait a minute
[23:08:13 CEST] <madprops> it's actually doing the opposite
[23:08:25 CEST] <madprops> it's "removing" 4 seconds from the video file
[23:09:03 CEST] <madprops> wait
[23:09:28 CEST] <relaxed> switch your inputs
[23:09:35 CEST] <kepstin> er, wait, why did I do 'm4v' there, that's raw mp4 video, not a container
[23:09:37 CEST] Action: kepstin fixes that
[23:10:50 CEST] <kepstin> hmm. no difference in the result
[23:10:53 CEST] <relaxed> kepstin: this works for me, ffmpeg -i test.m4a -itsoffset -4 -i test.m4v -map 0 -map 1 -c copy -y out.mkv
[23:11:49 CEST] <kepstin> relaxed: so when you play that file, you get 4s of video with silence, then the audio starts? (or alternately the video just starts with the number '10'?)
[23:11:52 CEST] <relaxed> also works if I use mp4 as the output
[23:11:54 CEST] <kepstin> er, 4 in your case
[23:11:58 CEST] <relaxed> correct
[23:12:26 CEST] <kepstin> ... so why does this work for you but not me
[23:12:36 CEST] <kepstin> what ffmpeg version are you running?
[23:12:50 CEST] <madprops> wait!
[23:12:56 CEST] <relaxed> ffmpeg version N-86433-g81fc617c12 (git from a few days ago)
[23:13:01 CEST] <madprops> this is weird, it actually worked if i inspect it with my video editor
[23:13:08 CEST] <madprops> but the windows video player starts the audio imidiatelly
[23:13:14 CEST] Action: kepstin tried 3.3.1 and 3.1.8, and is using mpv to test playback
[23:13:23 CEST] <relaxed> hmm, I'm playing back with mpv if that matters
[23:14:04 CEST] <relaxed> and it does matter :(  ffplay doesn't respect the offset
[23:14:31 CEST] <furq> kepstin: m4v is just mp4
[23:14:32 CEST] <kepstin> i wonder if the difference is our *mpv* versions, and our files are actually the same :/
[23:14:41 CEST] <kepstin> furq: no, see ffmpeg -h muxer=m4v ;)
[23:14:59 CEST] <relaxed> mpv 0.25.0-131-g6489b112a
[23:15:00 CEST] <furq> huh
[23:15:19 CEST] <kepstin> huh, although I guess the 'm4v' extension must be attached to the 'mp4 muxer
[23:15:28 CEST] <kepstin> the .m4v file I have is in fact an mp4/isombff file
[23:15:33 CEST] <kepstin> that's confusing
[23:15:49 CEST] <furq> i was about to say
[23:15:55 CEST] <furq> .m4v uses the ipod muxer
[23:16:05 CEST] <furq> which is correct as far as i'm concerned
[23:16:22 CEST] <furq> every m4v i've ever seen in the wild has been a video from itunes
[23:16:46 CEST] <madprops> mpv doesn't even reproduce the audio
[23:17:32 CEST] <furq> what even is "raw mp4 video"
[23:17:51 CEST] <furq> i assumed it would be length-prefixed h264, but the default encoder for it is mpeg4
[23:17:55 CEST] <kepstin> sorry, "raw mpeg 4 (asp) video"
[23:17:56 CEST] <relaxed> mpeg4 elementary stream ?
[23:18:22 CEST] <madprops> downloading vlc
[23:18:43 CEST] <furq> i can mux h264 into m4v
[23:19:30 CEST] <relaxed> right, Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'test.m4v':
[23:19:44 CEST] <furq> i mean with -f m4v
[23:20:15 CEST] <kepstin> furq: yeah, weird, looks like it gives the same result as -f h264
[23:20:27 CEST] <furq> yeah i just noticed that
[23:20:33 CEST] <furq> the encoder says "m4v" but then ffprobe says h264
[23:20:38 CEST] <furq> fuck knows
[23:20:54 CEST] <furq> i'm glad .m4v uses ipod anyway
[23:21:07 CEST] <furq> whatever -f m4v is doesn't seem in line with how that extension is used
[23:21:26 CEST] <kepstin> both list the 'm4v' extension, so I guess it just depends on the order in the list of formats or something :/
[23:21:36 CEST] <madprops> no audio in vlc
[23:21:44 CEST] <madprops> something's very wrong with my files
[23:23:16 CEST] <madprops> here's the info of the merged file http://i.imgur.com/n7r1cqm.jpg
[23:23:20 CEST] <FishPencil> Is there anything FFmpeg can do with gainy material? I feel like most of the bitrate is being used to reproduce the grain
[23:23:28 CEST] <furq> use a denoiser
[23:23:41 CEST] <furq> hqdn3d is reasonably good and fast
[23:35:41 CEST] <madprops> btw i made it
[23:35:58 CEST] <madprops> i removed the audio channel from the original video into an mkv and used that to merge
[23:36:11 CEST] <madprops> the empty audio channel was messing things up
[23:58:44 CEST] <FishPencil> If speed isn't an issue, is there a better denoiser than hqdn3d?
[00:00:00 CEST] --- Fri Jun 16 2017


More information about the Ffmpeg-devel-irc mailing list