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

[burek]

[00:02:06 CET] <JeffIsMyName> Guten morgen! So, when I transcode using the latest version of FFmpeg (built from source), it only uses ~75% of my CPU. Any ideas?
[00:03:55 CET] <alexpigment> have you ruled out decoding as a bottleneck?
[00:04:14 CET] <alexpigment> get rid of your -i [video] and change it to something like this:
[00:04:28 CET] <alexpigment> -f lavfi -i "smptebars=duration=200:size=1920x1080:rate=30"
[00:04:35 CET] <JeffIsMyName> Will do; one second.
[00:06:01 CET] <iive> libx264 would use all cores and some more, so definitely decoder bottleneck
[00:06:36 CET] <JeffIsMyName> Nope, still 75%
[00:06:51 CET] <JeffIsMyName> Using libx264, no hardware transcoding.
[00:06:54 CET] <JEEB> depends, if you have a whackload of cores it might not go over 16 nicely
[00:07:00 CET] <JEEB> or however it was again?
[00:07:02 CET] <JeffIsMyName> Only 4
[00:07:07 CET] <JeffIsMyName> i7-2600.
[00:07:16 CET] <JeffIsMyName> Capped at 75%
[00:07:22 CET] <JEEB> ok, then it should. so it's being most likely limited by something else
[00:07:31 CET] <JEEB> you could profile it if you really want to :P
[00:07:47 CET] <JeffIsMyName> Noobie here: what?
[00:08:19 CET] <JEEB> there are profiling tools that let you see where the process is using its time, although to be honest I haven't touched them in years :P
[00:08:36 CET] <JeffIsMyName> Ah, that's what you're talking about, lol. I'll try that in a minute, brb.
[00:08:41 CET] <JeffIsMyName> On Debian 8.
[00:09:02 CET] <JEEB> just make sure you have the debugging symbols around
[00:09:19 CET] <JEEB> (ffmpeg_g for example instead of ffmpeg, or build with --disable-strip
[00:16:49 CET] <JeffIsMyName> Gees, I can't remember how to profile for squat.
[00:17:09 CET] <JeffIsMyName> I'll just rebuild it w/ that argument.
[00:18:26 CET] <JeffIsMyName> make --disable-strip or ./configure --disable-strip ...?
[00:20:18 CET] <DHE> there's many different ways to do it. I've become a fan of perf
[00:21:34 CET] <JeffIsMyName> And how do you go about compiling using perf on Debian?
[00:21:37 CET] <alexpigment> if profiling doesn't work, could this be a simple disk writing bottleneck? with a high enough bitrate, I can see how the drive wouldn't be able to keep up. especially if it's inside a VM on a mechanical drive
[00:21:56 CET] <JeffIsMyName> It's output is onto an SSD.
[00:21:58 CET] <DHE> perf is a pretty standard tool. ships alongside the linux kernel. I'd be surprised if you can't just install it directly
[00:22:22 CET] <alexpigment> JeffIsMyName: cool, just figured i'd throw that out there before you got too far down the perf road
[00:23:00 CET] <DHE> you can output to the null format (or /dev/null) to eliminate that as a bottleneck
[00:23:39 CET] <alexpigment> JeffIsMyName: also you're not specifying a fixed number of threads in your command line, right?
[00:23:59 CET] <JeffIsMyName> See, this processor is from eBay (but there's only so many things that can go wrong w/ a processor), I'm wondering if there's an issue w/ one of the cores???
[00:24:06 CET] <JeffIsMyName> [NULL @ 0x33843c0] Unable to find a suitable output format for '/dev/null' /dev/null: Invalid argument
[00:24:25 CET] <JeffIsMyName> I've not specified in this latest command. I've tried -threads 8 & 0.
[00:24:37 CET] <alexpigment> -threads 0 should be auto, so that rules that out
[00:24:56 CET] <JeffIsMyName> Right
[00:29:46 CET] <JeffIsMyName> We can rule out output bottlenecks, but I'm wondering if it has something to do w/ compilation of the build. Here's the arguments I used:
[00:29:48 CET] <JeffIsMyName> ./configure --enable-encoder=hevc_nvenc --enable-nonfree --enable-libx264 --enable-libx265 --enable-libfreetype --enable-libass --enable-gpl --enable-libvpx --enable-libtheora --enable-libopus --enable-libmp3lame --enable-libfdk-aac --enable-version3 --disable-w32threads --enable-runtime-cpudetect --enable-avisynth --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libgsm --enable-libspeex --enable-libxvid --enable-z
[00:58:03 CET] <iive> to write to /dev/null you might need -f null iirc
[01:09:16 CET] <furq> nah -f null is if you want to write to stdout without trashing your terminal
[01:14:44 CET] <k_sze> Metadata in a .MOV file is so confusing.
[01:15:36 CET] <k_sze> The rotation in an H.264 stream and the rotation in the side data TAG:rotation use opposite signs.
[01:21:05 CET] <JeffIsMyName> furq: it seems to render at ~2000 FPS, but the CPU is only being used at around 50% now.
[02:25:49 CET] <buhman> is there some io-friendly "intermediate" video format more lightweight than rawvideo?
[02:27:57 CET] <buhman> is mpeg1 or something the thing to use?
[02:39:12 CET] <furq> buhman: no
[02:39:37 CET] <furq> use ffv1 or x264 lossless or utvideo or ffvhuff or huffyuv or...
[02:40:08 CET] <buhman> yeah utvideo seems ok
[02:40:26 CET] <buhman> which one is the best? and which container format should I use?
[02:40:45 CET] <buhman> rawvideo seems awkward because it seems like I need to pass the pixel format, video size, etc&
[02:42:01 CET] <atomnuker> nut can hold rawvideo better than anything
[02:42:28 CET] <atomnuker> it can contain ffv1 or ut or whatever but if you need rawvideo nut's the thing
[02:42:41 CET] <k_sze[work]> nut is an awesome format.
[02:43:24 CET] <k_sze[work]> Because it's streamable and ffmpeg generally doesn't care if the stream is corrupted at the end.
[02:43:26 CET] <buhman> ffv1 and ut appear to have similar output sizes; is it a toss-up between those?
[02:43:37 CET] <k_sze[work]> buhman: when in doubt, use ffv1
[02:43:40 CET] <k_sze[work]> level 3
[02:43:41 CET] <buhman> ok
[02:44:49 CET] <k_sze[work]> What's the proper way to extract only the TAG:rotation of a .MOV file recorded from an iPhone?
[02:44:55 CET] <k_sze[work]> using ffprobe.
[02:45:54 CET] <k_sze[work]> if I do `ffprobe -v quiet -show_streams -select_streams v:0 -show_entries stream=tags video.mov`, I get some other fields that I'm not interested in.
[02:46:13 CET] <k_sze[work]> It *does* include the TAG:rotation that I'm looking for, but still...
[02:48:46 CET] <k_sze[work]> `-show_entries stream_tags=rotation`, on the other hand, gives me *nothing*.
[02:48:54 CET] <k_sze[work]> Which is to say I have no idea how -show_entries works.
[02:56:07 CET] <furq> k_sze[work]: -show_entries stream_tags=rotate
[02:56:30 CET] <furq> i would've been able to answer that a whole lot faster if adding rotate metadata wasn't apparently broken in ffmpeg now
[03:12:44 CET] <k_sze[work]> There's also a rotation in side data, which is in the opposite sign of the TAG:rotate.
[03:12:47 CET] <k_sze[work]> So confusing.
[03:13:26 CET] <k_sze[work]> furq: broken in what sense?
[03:13:44 CET] <furq> it doesn't write any metadata
[03:13:56 CET] <furq> i just checked with two builds and the one from 2016 works, the one from a few months ago doesn't
[03:14:00 CET] <furq> there's an open bug for it as well
[03:14:08 CET] <furq> https://trac.ffmpeg.org/ticket/6370
[03:15:24 CET] <furq> the bug report is about not being able to remove it but you can't add it either
[03:15:55 CET] Action: k_sze[work] facepalms.
[09:22:12 CET] <LigH> Hi.
[09:22:48 CET] <LigH> Which is the first location to look when I want to know which libraries could be included in ffmpeg when boulding (--enable-***)?
[09:23:00 CET] <LigH> *building
[09:23:19 CET] <LigH> I wonder if AOMedia AV1 could already be supported.
[09:23:38 CET] <LigH> Probably very similar to VPx.
[09:25:05 CET] <Nacht> Afaik AV1 is better then the VPx. But I haven't seen much examples yet, apart from Bitmovin's demo
[09:26:11 CET] <LigH> Possibly, yes. I was able to build a separate encoder/decoder application with jb-alvarado's media auto-build suite; but it does not include the codec in ffmpeg, so I wonder if it was just forgotten or is not yet available.
[09:26:41 CET] <Nacht> Also, ./configure --help
[09:26:44 CET] <Nacht> will show all options
[09:26:53 CET] <LigH> But VPx is included in ffmpeg as codec, via libvpx.
[09:27:31 CET] <Nacht> AV1 is just newer then VPx
[09:28:01 CET] <LigH> I don't have a lot of experience using a Linux like shell and manually running build steps... therefore I use an auto-build suite... :shame:
[09:29:00 CET] <LigH> I hope I can navigate and run your suggested command; but I do know that the automatic build scripts prepare a lot of environmental attributes before compiling which may bnot be present when I simply run a MinGW shell.
[09:29:59 CET] <LigH> So I wonder, is it possible to read e.g. the repository online in the web and find a place which tells me that e.g. a libaom is available?
[09:31:46 CET] <Nacht> https://pastebin.com/UsTjM6cj
[09:31:49 CET] <Nacht> There ya go
[09:32:59 CET] <LigH> Can find neither "aom" nor "av1" there. So, possibly not. Thank you.
[09:33:48 CET] <Nacht> Not on the most recent version on Git either
[09:34:05 CET] <JEEB> libaom used to duplicate symbols with libvpx and it only got its "soft freeze" at the end of October, and even derf etc didn't know what exactly "soft freeze" means
[09:35:52 CET] <LigH> I believe it is not really practical yet...
[09:36:19 CET] <LigH> Yesterday I tried some basic tests with aomenc, a 2-pass VBR encode of a small Y4M.
[09:36:57 CET] <LigH> Pass 1 rushed through; pass 2 estimated several days for a few hundred frames in CIF resolution
[09:37:06 CET] <LigH> o?
[09:37:21 CET] <Nacht> wow
[09:37:37 CET] <Nacht> But Bitmovin managed a livestream ?
[09:38:30 CET] <LigH> One may have to limit the per-frame deadline, or it will invest all the time it has?!
[09:38:55 CET] <LigH> I'll try to discuss that in the forums.
[09:39:01 CET] <LigH> Thank you for now.
[09:39:07 CET] <LigH> \o
[09:41:08 CET] <JEEB> Nacht: it's really not a problem to make a really basic bit stream
[09:41:19 CET] <JEEB> one of the mozilla guys is making an encoder in rust and during VDD it was running at >1000fps
[09:41:34 CET] <Nacht> Ok
[09:41:43 CET] <Nacht> They realy love their rust :D
[09:41:46 CET] <JEEB> not to mention that the format *still* isn't finished
[09:41:53 CET] <JEEB> it's in soft freeze but not hard freeze
[09:42:03 CET] <JEEB> and back when bitmovin did their PR stunt it was even less so :D
[09:42:04 CET] <Nacht> Not really sure what a soft/hard freeze is
[09:42:19 CET] <JEEB> soft means <something>, hard freeze means that "this is AV1"
[09:42:29 CET] <JEEB> there's been features being added until very late in October
[09:42:34 CET] <JEEB> like chroma from luma
[09:42:47 CET] <Nacht> Ah, so you can't really say there's an AV1 codec out yet
[09:43:01 CET] <JEEB> that's why I think the test page from bitmovin or so has the git hash of the encoder :D
[09:43:23 CET] <JEEB> yea
[09:43:29 CET] <Nacht> So it didn't really mean that much. As they could have adapted it to make it work for their purpose
[09:43:57 CET] <JEEB> well that works for anything really, making a fast encoder is almost always possible unless the format requires unskippable hard math
[09:44:04 CET] <JEEB> like back when AVC was new
[09:44:13 CET] <JEEB> most of the encoders just threw out something like MPEG-2 Video
[09:44:19 CET] <JEEB> or H.263
[09:44:23 CET] <JEEB> same with HEVC :D
[09:44:36 CET] <Nacht> It's things like these which really teach me that there are so many more layers to video encoding
[09:44:55 CET] <JEEB> of course you're literally not using nice features or trying hard to compress
[09:45:30 CET] <JEEB> but yea, most of the complexity in all formats goes into the encoder, and if the encoder just decides to have a field day to work out the minimum amount of work required - that's possible
[09:45:47 CET] <JEEB> as long as the bits it writes can be decoded according to the specification - all is fine
[09:46:00 CET] <Nacht> Have you tried toying around with AV1 yet ?
[09:46:30 CET] <JEEB> not really
[09:46:39 CET] <JEEB> since I don't think it's really that worth it until they say that this is AV1
[09:46:51 CET] <Nacht> It does seem intresting on paper, but I rather use the pratical approach, and look at the codecs supported on the market
[09:47:23 CET] <sfan5> >supported on the market
[09:47:30 CET] <sfan5> you'll need to wait several years for AV1 then
[09:47:43 CET] <Nacht> I know
[09:49:04 CET] <JEEB> new formats always have the "nothing supports it" issue
[09:49:13 CET] <JEEB> although both chromium and firefox will most likely have support out of the box
[09:49:23 CET] <JEEB> and the fact it's not only google playing around any more
[09:49:42 CET] <JEEB> even if it's a "Plan B" if the MPEG formats' licensors keep being insane
[09:50:06 CET] <JEEB> (at the point where MPEG-LA was not enough to X amount of vendors it went downwards)
[09:50:19 CET] <JEEB> as in, MPEG-LA's licensing rules were too nice to those licensing :P
[09:50:26 CET] <JEEB> and not enough shekels to various companies
[11:27:48 CET] <Xys> Hi guys, do you know what would be a standard bitrate for a 720p mp4 video ? In bits per second ?
[11:28:06 CET] <JEEB> "whatever your content needs"
[11:28:31 CET] <JEEB> if you're using libx264, just use CRF with the highest value that still looks good. if you have hard bandwidth limits, additionally add maxrate and bufsize
[11:30:52 CET] <kiranbsravi> Hello, trying to generate a webm file from RTP video and audio streams that I receive on my server.   Video - vp8 encoded and audio - opus encoded.  I will have RTP timestamps for both the streams and correspopnding NTP timestamps from RTCP.  how do I set PTS and DTS of AVPacket with these values while constructing AVPacket, so that audio and video will be in sync in the output webm file?
[11:34:26 CET] <kiranbsravi> using libavformat for the above. sry.
[11:41:31 CET] <DHE> Xys: if you still need some numerical guidance, I usually recommend a crf around 25 or a bitrate around 5 megabits. watch it, see how it looks and what the file size is, and adjust accordingly.
[11:42:06 CET] <DHE> these are very loose numbers based on knowing nothing specific to your needs, so don't expect this to be optimal on the first try
[11:46:48 CET] <JEEB> he should just use CRF if he does not know, there's no reason to start giving out random numbers
[11:47:06 CET] <JEEB> the only things he should care about are his hard bandwith limits
[11:52:03 CET] <kiranbsravi> Hello, I am using libavformat to generate a webm file from RTP video and audio streams that I receive on my server.  Video - vp8 encoded and audio - opus encoded.  I will have RTP timestamps for both the streams and correspopnding NTP timestamps from RTCP.  how do I set PTS and DTS of AVPacket with these values while constructing AVPacket, so that audio and video will be in sync in the output webm file?
[11:53:02 CET] <Xys> I'm encoding with iOS, and I can only set the profile, the average bitrate, and the max key frame interval
[11:53:12 CET] <DHE> JEEB: even for bandwidth constrained scenarios you still suggest the CRF method?
[11:57:51 CET] <JEEB> DHE: yes
[11:57:58 CET] <JEEB> crf + VBV/HRD
[11:58:17 CET] <JEEB> Xys: right. so you're using an encoder that doesn't let itself to be "smart"
[11:58:18 CET] <JEEB> have fun :)
[11:58:24 CET] <JEEB> "PICK A NUMBER" is the name of the game
[11:58:41 CET] <JEEB> don't forget that hardware encoders generally are awful at compression
[11:58:48 CET] <JEEB> so just boost that bit rate as high as possible
[11:58:52 CET] <Xys> Hehe, I have either no options so I guess it's "default and intelligent
[11:59:02 CET] <Xys> Or I have the options I mentionned above
[11:59:18 CET] <JEEB> no, if it forces you to pick a bit rate and has no "quantizer" or "rate factor" modes
[11:59:22 CET] <JEEB> then rip
[11:59:49 CET] <Xys> No no, as I said. Either I dont put any options, either I add the 3 I mentionned above
[12:00:06 CET] <JEEB> probably ends up with some default :)
[12:00:14 CET] <Xys> Without any option it encodes with profile high
[12:00:20 CET] <Xys> on my phone at least
[12:00:22 CET] <JEEB> which is what you generally want
[12:00:28 CET] <JEEB> aka "don't limit features"
[12:00:28 CET] <Xys> yep
[12:00:31 CET] <JEEB> profiles = features
[12:00:38 CET] <JEEB> levels = memory requirements on decoder
[12:00:54 CET] <Xys> Agree :) !
[12:01:03 CET] <JEEB> anyways, check what bit rate you get by default
[12:01:14 CET] <JEEB> and if it's low just go and set it to like 10000 kbps or more
[12:01:23 CET] <Xys> That's what I did. I was around 1.8 Mbps
[12:01:24 CET] <JEEB> you really need all you can get with hardware encoders
[12:02:05 CET] <Xys> Okay, thanks for these infos :) !
[12:02:14 CET] <Xys> Have a nice day !
[12:27:20 CET] <bencc1> is there command line option to test audio/video quality?
[12:27:25 CET] <bencc1> MOS, PESQ, POLQA ?
[12:28:44 CET] <DHE> video has a few filters that, given 2 input videos, reports a PSNR and such
[12:29:03 CET] <DHE> still, human-perceived quality and mathematically-measured quality are two different things
[12:31:50 CET] <bencc1> DHE: I'm looking for a way to do it live during RTP call
[13:32:25 CET] <minru> Hello, what is the right way to bind output PTS to input PTS on live UDP source? What I want, is to keep audio/video in sync during packet losses. Is it possible with setpts/asetpts, copyts?
[13:57:43 CET] <twid___> can ffmpeg can be used as RTSP server, or I need to use some other servers like live555, wowza?
[14:29:00 CET] <DHE> ffmpeg can feed an rtsp server, but ffmpeg itself is not meant to do the mass distribution
[15:04:03 CET] <twid___> ok thats great, thanks
[17:07:38 CET] <blap> join ##ascii for groundbreaking irc art
[17:17:17 CET] <iive> blap: don't spam.
[17:18:09 CET] <blap> spamming would be pasting art *here*
[17:19:58 CET] <durandal_1707> iive: just ban him, he is known ban evader
[17:24:21 CET] <iive> blap: you didn't flood, that's why you are not banned yet.
[17:24:37 CET] <iive> durandal_1707: i don't know him...
[17:25:11 CET] <durandal_1707> there is irc history
[17:34:36 CET] <ikurasan> hey anyone know how i can add vtt subs to webm?
[17:35:18 CET] <bencc1> is there "official" ffmpeg docker container?
[17:35:28 CET] <bencc1> or maybe a container that builds ffmpeg for ubuntu?
[17:37:59 CET] <ikurasan> i have ffmpeg installed from the unofficial repository
[17:38:46 CET] <bencc1> yes but... it's unofficial
[17:38:55 CET] <bencc1> it would be great to have an official ppa
[17:39:11 CET] <ikurasan> yea it's from the ppa:jonathonf/ffmpeg-3
[17:41:39 CET] <ikurasan> so is it possible to use ffmpeg to convert an mkv file to webm and add vtt subtitles
[17:42:30 CET] <bencc1> why not?
[17:43:00 CET] <ikurasan> do you know the command for adding vtt?
[17:43:34 CET] <bencc1> maybe this: https://unix.stackexchange.com/a/333045
[17:44:24 CET] <durandal_1707> thats burning?
[17:44:28 CET] <ikurasan> but that's for mp4
[17:44:33 CET] <ikurasan> and it's .ass
[17:44:51 CET] <ikurasan> i thought webm only supports .vtt
[17:46:39 CET] <durandal_1707> ffmpeg -i in.mkv out.webm?
[17:47:08 CET] <durandal_1707> are webvtt subtitles separate file?
[17:47:14 CET] <ikurasan> yes
[17:49:06 CET] <bencc1> maybe start with burning to mp4. just check that ffmpeg can understand the vtt format
[17:49:08 CET] <kepstin> should be as simple as ffmpeg -i in.mkv -i in.vtt (add video/audio codec options here) -c:s webvtt out.webm
[17:49:10 CET] <bencc1> and than try to add it
[17:49:38 CET] <kepstin> although I'm not sure about browser support for embeded webvtt subs in webm?
[17:49:51 CET] Action: kepstin has always used separate subtitle files
[17:57:42 CET] <ikurasan> kepstin: do most people hardcode the subs into webm?
[17:58:27 CET] <kepstin> modern browsers have builtin basic soft subtitle rendering, or you can write your own html subtitle rendering, so there's no reason to burn the subs into the video
[17:58:44 CET] <BtbN> WebVTT is bad though. Very limited
[17:59:11 CET] <BtbN> Also, the ffmpeg "transcoder" for it is bad. It drops pretty much all features of for example ass, even though vtt would support them, like position on the screen and so on
[17:59:14 CET] <kepstin> yeah, ideally you'd want something like an ass renderer on a canvas or whatnot, but for basic closed captions or something you're usually ok with webvtt
[17:59:39 CET] <BtbN> Luckily there is https://github.com/Dador/JavascriptSubtitlesOctopus which is libass for JavaScript
[18:01:00 CET] <BtbN> I suspect the internal representation of subtitles in ffmpeg is lacking
[18:02:23 CET] <kepstin> well, the internal representation of subtitles in ffmpeg is basically just ass, isn't it?
[18:02:38 CET] <BtbN> Then the WebVTT encoder is lacking
[18:04:08 CET] <durandal_1707> there is webvtt encoder
[18:04:33 CET] <BtbN> Well, it can successfully output a .vtt file that html5 can play, so, yes, somewhere, there has to be one.
[18:04:41 CET] <kepstin> hmm. it would probably have to generate an embedded stylesheet in the webvtt file to do any sort of positioning or styling, and I really dunno if anything supports that
[18:05:07 CET] <kepstin> and the region stuff in webvtt is just weird, it's meant to replicate tv closed caption region scrolling
[18:05:19 CET] <BtbN> I tried converting some anime to something html5 can play, and it has subtitles, obviously. And the anime has a few scenes where they walk through a crowd, and the original ass subtitles put blurbs of background conversation all over the screen during that
[18:05:40 CET] <BtbN> Converting that to vtt with ffmpeg results in a few minutes of dialog text only showing up for a split second each, making the subtitles useless
[18:08:55 CET] <durandal_1707>  BtbN: so which keyword is missing from webvtt?
[18:09:03 CET] <BtbN> hm?
[18:09:34 CET] <durandal_1707> whats missing to support such subtitles?
[18:09:55 CET] <BtbN> Colors, Fonts, Font Size, Text Positioning
[18:10:02 CET] <BtbN> Transparency
[18:10:07 CET] <BtbN> Rotation
[18:10:45 CET] <BtbN> Which I think can all be done with custom css
[18:11:01 CET] <ikurasan> so .ass is really the superior subtitles format
[18:11:10 CET] <kepstin> positioning would require some abuse of the webvtt region system (and wouldn't be particularly accurage, i think), the other stuff can be done with embedded css (which I don't really think any renderers support)
[18:11:12 CET] <BtbN> WebVTT is not that inferior
[18:11:27 CET] <BtbN> The WebVTT encoder in ffmpeg is just very lacking
[18:11:41 CET] <BtbN> It cannot represent everything ass can do, but at least some basic extras are missing
[18:11:51 CET] <kepstin> hmm, looks like positioning can be done with css actually.
[18:14:32 CET] <kepstin> honestly, I'd probably embed ass subtitles in a webvtt file using the metadata text cues (so I can use the browser's builtin timing), then use a javascript ass renderer to draw them.
[18:15:10 CET] <kepstin> but that would be a pretty nasty hack ;)
[18:24:42 CET] <adgtl> Folks
[18:24:50 CET] <adgtl> I am getting this error
[18:24:52 CET] <adgtl> [buffer @ 0x56179b762d00] Unable to parse option value "-1" as pixel format
[18:24:52 CET] <adgtl>     Last message repeated 1 times
[18:24:52 CET] <adgtl> [buffer @ 0x56179b762d00] Error setting option pix_fmt to value -1.
[18:25:04 CET] <adgtl> For my command
[18:25:05 CET] <adgtl> ffmpeg -i hello.mp4 -i hello.opus  long_final_result.mp4
[18:29:14 CET] <adgtl> halp
[18:29:34 CET] <durandal_1707> help
[18:30:26 CET] <durandal_1707> adgtl: pastebin full output
[18:30:33 CET] <adgtl> durandal_1707 sure
[18:32:06 CET] <adgtl> @durandal_1707 https://gist.github.com/e1a30a9f457d96b1609719d7c726d156 here it is
[18:33:48 CET] <adgtl> durandal_1707 any clue?
[18:34:42 CET] <durandal_1707> adgtl: your 2nd input misses keyframe and pixel format
[18:35:02 CET] <durandal_1707> because of edit list probably
[18:35:02 CET] <adgtl> durandal_1707 I just run 'ffmpeg  -i hello.mp4 -i hello.opus final_result.mp4'
[18:35:14 CET] <adgtl> @durandal_1707 how to fix this then?
[18:35:36 CET] <durandal_1707> adgtl: could you upload mp4 file somewhere?
[18:35:44 CET] <adgtl> sure
[18:36:39 CET] <adgtl> @durandal_1707 here it is https://www.dropbox.com/s/8ucv69ki3s0i2uz/hello.mp4?dl=0
[18:39:09 CET] <durandal_1707> adgtl: try using latest release 3.4
[18:39:19 CET] <adgtl> durandal_1707 ffmpeg one?
[18:39:52 CET] <durandal_1707> yes
[18:39:59 CET] <adgtl> It's ffmpeg version 3.2.6
[18:40:03 CET] <adgtl> okay .. let me try
[18:40:49 CET] <adgtl> durandal_1707 any other quick solution?
[18:41:17 CET] <durandal_1707> nope, as its internal bug
[18:41:58 CET] <adgtl> durandal_1707 ah.. okay.. do you know command to ugprade ffmpeg on alpine os/
[18:42:23 CET] <adgtl> durandal_1707 I am using this docker container https://github.com/giordanocardillo/janus-post-processor/blob/master/Dockerfile
[18:42:29 CET] <durandal_1707> no idea
[18:42:36 CET] <adgtl> and I have sshed to container.. but don't know to ugprade package
[18:42:38 CET] <adgtl> checking
[19:00:20 CET] <alexpigment> i just read above and just realized that I've been out of the loop long enough to not know there was an official 3.4 release
[19:00:42 CET] <alexpigment> is there a list of major updates between 3.3 and 3.4?
[19:01:19 CET] <sfan5> just read the Changelog?
[19:02:08 CET] <alexpigment> ok, thanks for the heads up. i was googling all the words except changelog
[19:06:44 CET] <alexpigment> just looking at this new "doubleweave" filter. conceptually, i'm not sure I understand how it works. you either weave and get 30/25 or bob and you get 60/50. does it just weave and then duplicate each frame?
[19:07:50 CET] <durandal_1707> its written in docs
[19:08:22 CET] <durandal_1707> or not
[19:08:24 CET] <alexpigment> durandal_1707: i'm looking around in the places I know to look. do you have a link to the docs you are talking about?
[19:09:38 CET] <durandal_1707> its like weaver but instead of stepping by 2 fields,  it step by 1 field
[19:10:29 CET] <alexpigment> gotcha
[19:10:41 CET] <alexpigment> i just found a description on AVIsynth's wiki
[19:11:12 CET] <alexpigment> and I think I understand now (on paper)
[19:11:15 CET] <kepstin> ah, so it you have a sequence with frames A, B and fields 1, 2, it'll give you A1A2 then B1A2 then B1B2?
[19:11:21 CET] <alexpigment> in my head this is just going to make things look blurry
[19:11:38 CET] <alexpigment> kepstin: yeah, it sounds like that
[19:12:27 CET] <alexpigment> "If you're processing field-based video, like video-camera footage, you probably won't need this filter. But if you're processing NTSC video converted from film and you plan to use the Pulldown filter, you need to use DoubleWeave first. See the Pulldown filter for an explanation."
[19:15:26 CET] <kepstin> hmm, well, I don't really see how it's useful, but I suppose someone must have wanted it at some point :/
[19:15:48 CET] <alexpigment> yeah, i'm struggling to find the use for it too
[19:16:41 CET] <alexpigment> although I have a handful of videos that are from DVD, play fine on a DVD player, but I get a combed frame on certain cuts when the VOBs are played in any software
[19:16:55 CET] <alexpigment> i'll go through and check this in the slight hope that it addresses that (probably won't though)
[19:17:53 CET] <kepstin> for that issue, you often need to use the repeatfields filter, then redo the detelecine
[19:18:17 CET] <alexpigment> kepstin: I think you suggested that before and I tried it without success
[19:18:21 CET] <alexpigment> but I'll try again
[19:19:08 CET] <kepstin> you'd normally see an issue like that only if one of the frames in the dvd has fields from different frames, but the repeat_field flags are set up so that the player thinks it's a progressive frame
[19:19:43 CET] <kepstin> which means that they probably used an auto detelecine while encoding which didn't match correctly
[19:19:44 CET] <kepstin> i guess
[19:19:45 CET] <alexpigment> that makes perfect sense with what's happening
[19:20:05 CET] <alexpigment> it's suprisingly common on music video DVDs (which I happen to collect)
[19:20:15 CET] <kepstin> you wouldn't see this with many hardware dvd players because they normally either output interlaced or run everything through a deinterlacer anyways
[19:20:28 CET] <alexpigment> probably nothing to do with the music video part - just that small companies make dumb choices
[19:21:13 CET] <alexpigment> oh weird
[19:21:15 CET] <kepstin> i wouldn't be surprised if it was just a field mismatch on an edit or something like that, so you might only have half a frame in that spot
[19:21:31 CET] <alexpigment> doubleweave made my video 720x960
[19:21:49 CET] <kepstin> yes, that's exactly as expected
[19:21:52 CET] <alexpigment> i'm even more confused by the point of this filter
[19:22:06 CET] <alexpigment> anyway, testing your repeat field suggestion again
[19:23:48 CET] <alexpigment> unable to parse value
[19:23:53 CET] <alexpigment> -flags repeat_field?
[19:24:01 CET] <alexpigment> oh, nm
[19:24:02 CET] <alexpigment> ignore me
[19:24:04 CET] <kepstin> no, -vf repeatfields
[19:24:18 CET] <alexpigment> yeah, i looked at the wrong line above
[19:24:47 CET] <kepstin> that basically causes the 'field repeat' flags in the vob stream to be honoured, so you get an interlaced decode of the video instead of mixed progressive/interlaced
[19:25:12 CET] <kepstin> none of the detelecine filters in ffmpeg handle mixed progressive/interlaced well, so this gives you an input they're less likely to choke on
[19:27:26 CET] <kepstin> but yeah, the doubleweave filter lets you take a, say, 30 frames per second progressive input and get a 120 fields per second interlaced output. Which is kinda weird.
[19:27:40 CET] <kepstin> if I'm reading that right, i might not be
[19:28:23 CET] <kepstin> hmm, nope, reading it wrong.
[19:28:26 CET] <alexpigment> wow, kepstin. I think this is it. I have a feeling I made a dumb mistake last time (because I made it again just a second ago) - I probably forgot to set x264 to maintain the interlacing
[19:28:55 CET] <alexpigment> but yeah, spot checking so far and it looks good. I should be able to make a convert script for these now
[19:28:59 CET] <kepstin> why would you want to tell x264 to encode interlaced? it's almost always better to deinterlace/detelecine before encoding.
[19:29:27 CET] <kepstin> (the rare exception is when you want to do archival preservation of natively interlaced content, basically)
[19:29:28 CET] <alexpigment> kepstin: not in my experience. yadif is pretty good, but the hardware deinterlacers on my computer always seem to do a better job
[19:29:39 CET] <alexpigment> but yes, it's also about the archival aspect
[19:29:57 CET] <alexpigment> I have a very strong rule to never re-encode music videos unless there's a problem with the source DVD content
[19:30:03 CET] <alexpigment> and then I do like a CRF 14 to compensate
[19:31:30 CET] <alexpigment> the other thing is that if I preserve it as interlaced, it's always possible to reconstruct 23.976 in the event that it was film content
[19:31:59 CET] <alexpigment> and I don't have to worry about detelecining and spot checking for if something is 100% film or 100% video
[19:33:35 CET] <alexpigment> at any rate, I appreciate you suggesting that filter (again). you solved a years-long headache of mine
[19:35:10 CET] <kepstin> hmm. nobody has rewritten vf_fps to use the activate callback yet. I keep meaning to look at doing that, it would solve a longstanding issue i've had, but I still haven't gotten around to it.
[19:37:03 CET] <kepstin> (issue with the current version is that if you have a long gap in the video pts, vf_fps generates and queues all the frames to fill the gap in a single filter_frame call, using tons of memory)
[19:37:55 CET] <kepstin> if rewritten to use activate, it could return a single frame each time it's called, instead.
[20:33:31 CET] <alexpigment> kepstin: what's a practical application for vf_fps?
[20:33:57 CET] <alexpigment> taking a variable FPS video and converting it to constant FPS?
[20:34:14 CET] <kepstin> you have variable framerate material (or have done filtering that drops frames, for example) and want constant fps output
[20:34:28 CET] <kepstin> or in some cases, changing framerate by simply dropping or duplicating frames
[20:35:05 CET] <kepstin> note that with ffmpeg cli tool, the "-r" output option to set output framerate works by throwing an fps filter on the end of your filter chain.
[20:35:36 CET] <alexpigment> ah
[20:35:40 CET] <alexpigment> i've always just used -r
[20:35:53 CET] <alexpigment> i didn't realize that it was using an implied filter
[20:38:04 CET] <alexpigment> does the vf_fps 'problem' explain any of the "past duration too large" messages?
[20:38:12 CET] <alexpigment> or would that occur either way?
[20:41:18 CET] <kepstin> in general, adding an fps filter will fix the 'past duration too large' messages
[20:41:50 CET] <kepstin> those messages basically mean that you have a variable-framerate video stream, but ffmpeg thinks that the filter chain output is constant fps
[20:42:37 CET] <kepstin> i've seen it mostly happen on mkv files where ffmpeg guessed the file framerate incorrectly.
[20:44:17 CET] <alexpigment> yeah, in general, i only see it when the input and output frame rates don't match, so what you're saying makes sense
[20:54:54 CET] <alexpigment> kepstin: so while the one sample I had was fixed by repeatfields, two others (from two different sources) weren't
[20:55:18 CET] <alexpigment> apparently I needed to specify -top [number] to fix that
[20:55:35 CET] <kepstin> well, repeatfields doesn't fix anything, it just gives you a fully interlaced decode of the video as the dvd indicates it should be decoded.
[20:55:37 CET] <alexpigment> i'm guessing it just wasn't detecting the interlacing properly and just failing
[20:55:49 CET] <kepstin> it's up to whatever deinterlacer/detelecine you use after to fix it up
[20:56:21 CET] <alexpigment> right - i'm just letting you know in the odd event that it comes up again
[20:58:10 CET] <alexpigment> it also means I can't really just depend on one script
[20:58:14 CET] <alexpigment> i'll have to manually test for tff or bff
[20:58:20 CET] <alexpigment> no biggie, but still
[21:01:07 CET] <kepstin> hmm, I'd expect all dvd content to be the same, but i guess stuff might have been misencoded
[21:01:46 CET] <alexpigment> i don't know the breakdown, but tff and bff are both common for DVD
[21:01:48 CET] <kepstin> (pal/ntsc might be different of course, I don't deal with pal stuff)
[21:02:01 CET] <alexpigment> well, I suspect that all DV-sourced stuff is BFF
[21:02:28 CET] <alexpigment> anything film-sourced where a high def version also exists is probably TFF
[21:02:28 CET] <kepstin> right, but dv-sourced stuff should be converted for use with mpeg encoding, usually by shifting it by a field
[21:02:51 CET] <alexpigment> well, you could do that, but there's no reason to, really, since DVD supports BFF
[21:02:54 CET] <kepstin> (properly done dv to mpeg conversions usually have a black line at the top, iirc)
[21:04:28 CET] <alexpigment> possibly so, but anything analog-sourced has lines at the top anyway, so it's hard to tell
[21:04:53 CET] <alexpigment> (i'm talking about an analog > DV  > DVD situation)
[21:05:07 CET] <kepstin> although the lines used from the video frame and which field is temporally first are separate issues, so...
[21:05:29 CET] <alexpigment> i'll fully admit ignorance here on this particular thing
[21:05:42 CET] <alexpigment> I just know I see BFF on commercial DVDs quite a lot
[21:07:47 CET] <kepstin> if one frame of analog video was captured starting on an F1, using the video lines specified in SMPTE RP 202, then the video frames will be TFF; I suspect this is probably the most common arrangement for dvd video.
[21:07:55 CET] <kepstin> (ntsc stuff, of course)
[21:09:56 CET] <alexpigment> according to some apple documentation: "Generally, Upper is used by 640 x 480 systems, while Lower is most common in professional 720 x 486 and DV 720 x 480 systems.
[21:09:56 CET] <alexpigment> "
[21:10:24 CET] <alexpigment> i don't know what "professional 720x486", unless that's just an extension of DV with metadata stored in the extra 6 lines
[21:10:30 CET] <kepstin> yeah, DV 720x480 uses different lines from MPEG 720x480
[21:11:53 CET] <alexpigment> just trying to figure out if there's a common reason - other than DV - for BFF DVD
[21:12:06 CET] <alexpigment> it's completely academic, but it's useless knowledge like this that fills my brain
[21:12:26 CET] <kepstin> mpeg uses 23-262 and 286-525, DV uses 23-262 and 285-524. Professional 486 line stuff uses 21-263 and 283-525.
[21:12:55 CET] <kepstin> so the conversion from mpeg to dv *should* be done by shifting the frame up/down one pixel, which also switches which field the top line is from.
[21:13:07 CET] <alexpigment> I suppose so
[21:14:45 CET] <kepstin> but if the analog video capture was done starting on F2 then F1 rather than F1 then F2, then that  switches which of the two fields is temporally first.
[21:14:56 CET] <kepstin> the F1 then F2 is more common, but the other way also happens :/
[21:17:08 CET] <alexpigment> here's another unrelated thing I'm just discovering:
[21:17:18 CET] <kepstin> so there's two separate variables that control whether you end up with tff or bff in a digital video frame :/
[21:17:48 CET] <alexpigment> my workflow is to use ffmpeg to convert VOB > MP4. then I use tsmuxer to convert to TS, which allows for greater player compatibility (e.g. Windows Media Player, which deinterlaces properlY)
[21:18:10 CET] <alexpigment> but on the video I just tested, the resultant AC-3 channel is going crazy when I get the ts
[21:18:21 CET] <alexpigment> like the volume swells in intervals
[21:18:32 CET] <alexpigment> is there some sort of dynamic normalization in AC-3?
[21:18:55 CET] <kepstin> iirc, AC-3 does have some provision for dynamic normalization, yes
[21:19:03 CET] <kepstin> I've never actually seen it used.
[21:19:07 CET] <alexpigment> does ffmpeg have a way to throw it away?
[21:19:18 CET] <alexpigment> I mean I can't imagine this is used *correctly* in this case
[21:19:29 CET] <kepstin> probably not without reencoding, it would need a bsf.
[21:20:24 CET] <alexpigment> maybe i'll try ffmpeg's ts muxer again and pray that it's not still horribly busted
[21:21:46 CET] <kepstin> ideally, this is just something you change in the player settings, disable dialog normalization (dialnorm)
[21:23:08 CET] <alexpigment> oh, duh
[21:23:12 CET] <alexpigment> my bad
[21:23:25 CET] <alexpigment> windows media player had a section called "dolby digital settings"
[21:23:29 CET] <alexpigment> and it was set to night mode
[21:23:37 CET] <alexpigment> never noticed that ever
[21:23:40 CET] <alexpigment> not sure why it was set that way
[21:23:57 CET] <alexpigment> sorry for the false alarm and wasted typing
[21:24:25 CET] <kepstin> if you're playing back at a low gain level it's sometimes helpful, so you can still hear dialogue without effects being too loud
[21:24:35 CET] <alexpigment> yeah, it was a louder music track
[21:24:38 CET] <kepstin> i dunno if windows might enable it by default at low gain
[21:24:52 CET] <alexpigment> and it was ramping up in volume in cycles. i guess it just needed to be a loud enough track to notice it
[21:25:24 CET] <alexpigment> but yeah, I suppose that's a decent theory about when it's enabled. although my windows volume was pretty high
[21:30:03 CET] <Megabyte> Hello, everyone
[21:30:10 CET] <Megabyte> I'm stumbling upon a bug with ffmpeg
[21:30:28 CET] <Megabyte> "Option loop not found"
[21:30:31 CET] <Megabyte> How do I solve this?
[21:31:42 CET] <alexpigment> are you specifying -loop?
[21:32:34 CET] <alexpigment> i think that only works on image sources, for what it's worth
[21:47:38 CET] <Megabyte> alexpigment, I am, yes
[21:47:54 CET] <alexpigment> on an image?
[21:47:57 CET] <Megabyte> alexpigment, I'm running this from a script
[21:47:59 CET] <Megabyte> Yes
[21:48:10 CET] <Megabyte> 	ffmpeg -loop 1 -i "$cover" -i "$_" -acodec aac -shortest "$output_file.mp4"
[21:48:14 CET] <Megabyte> This is the script command
[21:48:24 CET] <Megabyte> Notice $cover is an image
[21:50:01 CET] <Megabyte> alexpigment, that is all correct, isn't it?
[21:50:16 CET] <alexpigment> testing on my end
[21:50:17 CET] <alexpigment> 1 sec
[21:51:17 CET] <alexpigment> seems to work over here
[21:51:23 CET] <alexpigment> using a PNG image and an mp3 track
[21:51:31 CET] <alexpigment> what version of ffmpeg are you using?
[21:52:12 CET] <Megabyte> N-88514
[21:52:28 CET] <Megabyte> alexpigment, the command itself is fine, but apparently this fails randomly with some inputs
[21:52:37 CET] <alexpigment> what are the inputs that are failing?
[21:52:43 CET] <alexpigment> certain file formats?
[21:52:55 CET] <alexpigment> same file format but only some of the images?
[21:57:28 CET] <Megabyte> alexpigment, the inputs that are failing are wav files created by Virtual NSF
[21:57:35 CET] <Megabyte> with 96k sample rate
[21:57:45 CET] <alexpigment> ah
[21:58:04 CET] <alexpigment> i don't think i have any 96k tracks around to test with
[21:58:09 CET] <alexpigment> lemme dig around
[21:58:33 CET] <Megabyte> Ok
[21:58:33 CET] <kepstin> that doesn't make sense, since the -loop option is being applied on the cover image, you should be getting a different error if it was a problem with the audio file
[21:58:44 CET] <Megabyte> kepstin, it doesn't, yes
[21:58:56 CET] <Megabyte> but if I feed this script with other input files, it works correctly
[21:59:52 CET] <alexpigment> fwiw, my 96k test worked fine
[22:00:05 CET] <alexpigment> and also, i agree with kepstin that it doesn't make too much sense
[22:00:54 CET] <Megabyte> I can't redirect my console output to a file so I can copy and paste
[22:00:56 CET] <kepstin> my guess is that you either have the input files mixed up or have an invalid value for "$cover".
[22:01:06 CET] <Megabyte> kepstin, nope, cover is correct
[22:01:31 CET] <alexpigment> ok, i've tried both 16-bit and 24-bit 96k wav files
[22:01:33 CET] <alexpigment> still nothing
[22:01:51 CET] <kepstin> well, unless I can see the exact command you're running and/or the complete console output, i'm not really gonna be able to troubleshoot further :/
[22:02:10 CET] <kepstin> just guessing in the dark here.
[22:02:31 CET] <Megabyte> What if I send you the problematic audio file?
[22:03:00 CET] <kepstin> Megabyte: just run the command manually in a console, filling in the values, see if you still get the error.
[22:03:07 CET] <kepstin> and copy/paste the result into a pastebin
[22:03:12 CET] <kepstin> rule out the script.
[22:03:23 CET] <Megabyte> kepstin, I can't paste
[22:03:47 CET] <kepstin> ... what OS are you using? why can't you copy/paste?
[22:03:52 CET] <Megabyte> Windows, of course
[22:04:00 CET] <Megabyte> What other OS would make this so difficult? :/
[22:04:10 CET] <kepstin> windows console has a perfectly functional copy/paste feature, if a bit annoying to use.
[22:04:20 CET] <alexpigment> yeah, you have to mark then copy
[22:04:20 CET] <Megabyte> Oh?
[22:04:37 CET] <Megabyte> How do I activate it, exactly?
[22:04:40 CET] <alexpigment> click on the little icon at the top left of the title bar
[22:04:41 CET] <Megabyte> CTRL + C doesn't work
[22:04:44 CET] <alexpigment> go to Edit > Mark
[22:04:50 CET] <alexpigment> "mark" the area you want to copy
[22:04:59 CET] <alexpigment> then click that button in the title bar again and go to Edit > Copy
[22:05:04 CET] <alexpigment> it sucks, but it works in a pinch
[22:05:12 CET] <Megabyte> :O
[22:05:17 CET] <Megabyte> I can't believe it! It works!
[22:05:18 CET] <Megabyte> Ok, sec
[22:05:51 CET] <Megabyte> https://pastebin.com/207Q8A3k
[22:05:53 CET] <Megabyte> There you go
[22:07:01 CET] <kepstin> Megabyte: both your inputs are wav files - the first is supposed to be a picture
[22:07:18 CET] <kepstin> what are you trying to do?
[22:08:29 CET] <Megabyte> kepstin, I'm trying to convert a wav file into an mp4
[22:08:31 CET] <kepstin> wait, it looks like there must be some escaping issues or something there, the output doesn't match up with the command at all.
[22:08:39 CET] <furq> kepstin: -loop 1, not -loop
[22:08:45 CET] <furq> it's taking the first input filename as an output
[22:08:49 CET] <kepstin> ah, missed that
[22:08:58 CET] <furq> but yeah that command is not right at all to convert wav to mp4
[22:09:09 CET] <furq> just -i foo.wav out.mp4 will do it
[22:09:19 CET] <kepstin> Megabyte: you forgot the argument to -loop, and you are giving it two wav files rather than a picture and a wav file
[22:09:44 CET] <furq> if you want to add a video stream from a picture then yeah you need -loop and -shortest
[22:09:54 CET] <Megabyte> kepstin, that's not me
[22:10:01 CET] <Megabyte> the command is supposed to be:
[22:10:02 CET] <Megabyte> PS C:\Users\x\Music\Game Songs\Super Mario Bros> ffmpeg -loop 1 -i 'Super Mario Bros. (1985-09-13)(Nintendo EAD)(Nintend
[22:10:02 CET] <Megabyte> o) 1.wav' -i 'Super Mario Bros. (1985-09-13)(Nintendo EAD)(Nintendo) 2.wav' -acodec aac -shortest -acodec aac -shortest
[22:10:02 CET] <Megabyte> "Super Mario Bros. (1985-09-13)(Nintendo EAD)(Nintendo) 2.mp4"
[22:10:09 CET] <furq> -loop 1 -i foo.png -i foo.wav -tune stillimage out.mp4
[22:10:12 CET] <furq> er
[22:10:15 CET] <furq> -loop 1 -i foo.png -i foo.wav -tune stillimage -shortest out.mp4
[22:10:18 CET] <furq> is all you need
[22:10:24 CET] <kepstin> Megabyte: well, that's still wrong, it has two wav files when it should be an image then a wav file
[22:10:28 CET] <Megabyte> Ooh
[22:10:37 CET] <Megabyte> did something go wrong with the autocomplete?
[22:10:42 CET] <furq> apparently
[22:11:43 CET] <Megabyte> PS C:\Users\x\Music\Game Songs\Super Mario Bros> ffmpeg -loop 1 -i 'Super Mario Bros. (1985-09-13)(Nintendo EAD)(Nintend
[22:11:43 CET] <Megabyte> o) 1.wav' -shortest "Super Mario Bros. (1985-09-13)(Nintendo EAD)(Nintendo) 2.mp4"
[22:11:48 CET] <Megabyte> Doesn't help much though
[22:11:53 CET] <Megabyte> Still getting the same error
[22:12:12 CET] <Megabyte> "option loop not found"
[22:13:04 CET] <furq> you're still not giving it an image
[22:13:26 CET] <furq> like i said, if you just want to convert wav to aac-in-mp4 then -i foo.wav out.mp4
[22:14:03 CET] <Megabyte> furq, that should still work though
[22:14:09 CET] <furq> no
[22:14:10 CET] <kepstin> Megabyte: if you remove the image, then you have to also remove the -loop 1 (since the -loop 1 applied to the image input only)
[22:14:18 CET] <furq> -loop doesn't exist for anything other than image inputs
[22:16:12 CET] <alexpigment> furq: you're giving me deja vu for the beginning of this conversation ;)
[22:16:55 CET] <Megabyte> Now it worked :-/
[22:17:02 CET] <Megabyte> But about this:
[22:17:15 CET] <Megabyte> This syntax is correct, right?
[22:17:16 CET] <Megabyte> ffmpeg -loop 1 -i "$cover" -i "$_" -acodec aac -shortest "$output_file.mp4"
[22:17:21 CET] <furq> yes if the cover is an image
[22:17:37 CET] <Megabyte> It is. I just fed it to PowerShell.
[22:17:53 CET] <furq> also you probably want -tune stillimage in there
[22:18:05 CET] <Megabyte> furq, what does that do?
[22:18:19 CET] <kepstin> if you get an error that says "Option loop not found" then $cover was not actually an image.
[22:18:29 CET] <kepstin> and your script is passing it the wrong thing
[22:20:03 CET] <Megabyte> Huh... maybe I did something wrong? Now it worked :/
[22:20:11 CET] <Megabyte> But what is -tune stillimage?
[22:20:20 CET] <kepstin> Megabyte: using "-tune stillimage" just adjusts the settings on the video encoder to make still images (like a static cover art picture) look slightly better
[22:20:36 CET] <Megabyte> Oh
[22:20:58 CET] <kepstin> not really that important, but it might help in some cases.
[22:21:33 CET] <alexpigment> i'd guess that it turns off some deblocking stuff and just makes the GOP really really long
[22:21:59 CET] <Megabyte> Sigh... I need to code a GUI for this
[22:22:11 CET] <Megabyte> Do you guys know an up-to-date GUI that's easy to learn?
[22:22:18 CET] <Megabyte> I like TCL/TK, but that looks outdated
[22:22:51 CET] <kepstin> the "stillimage" tune is actually intended for encoding a single frame as a still image (i.e. as a replacement for jpeg or something), so it doesn't modify the gop at all, and it might mess up rate control a bit
[22:23:51 CET] <alexpigment> kepstin: ah. good to know. I thought maybe there was some rate control optimization by expanding the GOP, but I guess not
[22:24:01 CET] <alexpigment> i always set my GOP to 1 second anyway
[22:24:09 CET] <kepstin> yeah, no point in expanding the gop if you're encoding a single I frame :)
[22:24:59 CET] <kepstin> for a static cover art image or something, you might want to make the gop ~10 seconds or so just to make the video smaller/upload faster
[22:25:13 CET] <alexpigment> right
[22:25:20 CET] <alexpigment> not sure how much affect that has on seeking
[22:25:31 CET] <kepstin> (the default framerate of image2 demuxer is 25, and the default gop size with x264 is 250, so that's actually what you get by default)
[22:26:03 CET] <alexpigment> I know I'm biased, but I do find it kinda weird that it defaults to 25fps in 2017
[22:26:15 CET] <alexpigment> there really is no point in PAL frame rates in the high def world
[22:26:29 CET] <kepstin> i'd assume negligible seek effect with a still image, since all the predicted frames should be skips anyways
[22:26:43 CET] <alexpigment> kepstin: I was thinking that would be true, but I've never tested it
[22:27:51 CET] Action: kepstin normally uses ~10s gop unless he needs something shorter for particular technical reasons, e.g. shorter segments in hls or something.
[22:28:37 CET] <alexpigment> I only use it for seekability reasons. I have a lot of recorded TV that I process before watching. If I don't change the GOP, anytime I seek/rewind in Kodi, it takes several seconds to catch up to realtime
[22:28:55 CET] <alexpigment> same with various media players in Windows
[22:29:34 CET] <alexpigment> there could be another factor at play, of course, but setting the GOP to 1s seems to do the trick, and the file size tradeoff is fine with me
[22:29:37 CET] <kepstin> hmm, i've only ever noticed a problem when using slow x264 settings and attempting backwards trick play, that gets pretty laggy
[22:29:55 CET] <alexpigment> yeah, it's mostly rewinding fwiw
[22:31:58 CET] <kepstin> yeah, if you want to have a trick play rewind - where you can see the video go backwards - then you're gonna need a short gop setting
[22:32:12 CET] <kepstin> i suspect that's the main reason why bluray uses a fairly short gop.
[22:32:59 CET] <alexpigment> kepstin: well, that and chapters
[22:33:01 CET] <alexpigment> menu loop points
[22:33:10 CET] <alexpigment> basically anything where you need to decode a particular timestamp instantly
[22:33:22 CET] <kepstin> well, chapters and menu loop points just need a IDR forced at a particular frame
[22:33:26 CET] <kepstin> no reason for a short gop
[22:33:28 CET] <alexpigment> and also, they want it to feel like an appliance rather than a quirky computer
[22:34:13 CET] <alexpigment> Yeah, that's true. I'm not sure how that gets handled when I use Adobe Encore
[22:34:50 CET] <alexpigment> If rewinding felt clunky on DVD or Blu-ray, I'm sure people wouldn't adopt it as much. They made sure and baked it into the format
[22:35:29 CET] <alexpigment> And with Blu-ray, space is generally on your side, so again, the size cost is not a huge deal
[22:36:12 CET] <kepstin> on DVD, that really wasn't the case. There's not enough bitrate on a DVD given the required keyframe intervals and buffer sizes :(
[22:36:37 CET] <alexpigment> yeah, DVD was pretty good for the time
[22:36:54 CET] <alexpigment> But there are analog sources that look like crap when you put them on DVD no matter what
[22:37:06 CET] <alexpigment> which kinda tells you it could have used another year or two of research
[22:37:37 CET] <kepstin> well, analog/digital source doesn't matter. it's simply that if there's a lot of motion, dvd doesn't allow enough bits for mpeg2 to encode it without blocking.
[22:38:02 CET] <alexpigment> right - but there are some types of analog sources that are particularly hard to encode digitally
[22:38:11 CET] <alexpigment> e.g. the HBO intro on all of their shows
[22:38:25 CET] <alexpigment> I haven't seen that even look halfway decent since the 90s
[22:38:26 CET] <kepstin> anything interlaced was obviously worse, since interlaced encoding is less efficient in general
[22:39:56 CET] <alexpigment> it's still amazing to me that most DVDs are 4-6mbps
[22:40:18 CET] <alexpigment> I guess it just goes to show that with a very clean 24fps source, you can do pretty well within the constraints
[22:40:39 CET] <alexpigment> As a consumer A > D format, you run into the bitrate limits very easily
[22:40:46 CET] <kepstin> as an average? that's typical. but something averaging 4-6mbit probably still has sections where it's hitting the max limits and distorting
[22:41:00 CET] <alexpigment> of course
[22:41:30 CET] <alexpigment> I just know that I've done a lot of VHS conversions where I'm debating on 8mbps + PCM or 9mbps + AC3
[22:42:06 CET] <alexpigment> the latter is usually worth it
[22:42:59 CET] <kepstin> ffmpeg's mpeg2 encoder will (depending on other settings) straight up give up on some sources and refuse to hit the requested average bitrate in a 2-pass encode, although it'll usually hit the limits hard spots.
[22:43:14 CET] <alexpigment> yep, i've run into that many times
[22:43:38 CET] <kepstin> since it'll just hit qpmin or something
[22:44:02 CET] <alexpigment> yeah, it's 2-pass VBR where it will give you an actual error though
[22:44:24 CET] <alexpigment> if you have a complex source and try to do something like 3mbps 2-pass, it'll error out in some way
[22:44:30 CET] <alexpigment> rather than ignoring your bitrate
[22:44:35 CET] <alexpigment> I can't recall the exact error
[22:45:04 CET] <alexpigment> once you get to around 5-6mbps, it's pretty hard to get into that scenario, fortunatey
[22:52:48 CET] <alexpigment> had to look it up from my previous notes
[22:53:36 CET] <alexpigment> here's the error:
[22:53:37 CET] <alexpigment> [mpeg2video @ 0000000000571ba0] [lavc rc] Error: bitrate too low for this video with these parameters.
[22:53:37 CET] <alexpigment> Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height
[22:53:38 CET] <alexpigment> Conversion failed!
[22:53:38 CET] <alexpigment> Press any key to continue . . .
[22:54:41 CET] <alexpigment> that was a 3.4Mbps 2-pass DVD
[23:00:17 CET] <ioan> hi. In the documentation is says: "Multiple lower transport protocols may be specified, in that case they are tried one at a time (if the setup of one fails, the next one is tried)." How do I do that? `-rtsp_transport tcp udp` or `-rtsp_transport tcp -rtsp_transport udp`? Also, I want it to try the TCP first
[23:02:26 CET] <kepstin> ioan: the -rtsp_transport option is a flags type, so you'd specify it like "-rtsp_transport +tcp+udp". If you want i tto try tcp first, then also set "-prefer_tcp 1"
[23:03:16 CET] <ioan> kepstin, thank you!
[23:12:20 CET] <ioan> kepstin, I get "Unrecognized option 'prefer_tcp'"
[23:13:16 CET] <ioan> I guess the raspberry pi version of ffmpeg doesn't implement that option
[23:15:02 CET] <kepstin> oh, i misread that actually
[23:15:10 CET] <BtbN> There is no rpi version of ffmpeg
[23:15:12 CET] <kepstin> it should be `-rtsp_flags prefer_tcp` i think
[23:15:51 CET] <kepstin> also it looks like that's only implemented on the demuxer, not muxer
[23:19:08 CET] <ioan> kepstin, `-rtsp_flags prefer_tcp` worked. Thank you.
[00:00:00 CET] --- Thu Nov  9 2017