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

[burek]

[00:11:48 CEST] <nichego> are there any multithreaded deinterlacers available with ffmpeg that match the quality of traditional yadif,mcdeint pair?
[00:16:25 CEST] <furq> not without using avisynth/vapoursynth
[00:19:45 CEST] <nichego> furq: can you point me to reading on how to use a vapoursynth filter and ffmpeg in the same pipeline?
[00:23:10 CEST] <furq> http://vpaste.net/D9xj7
[00:23:14 CEST] <furq> that's what i use for deinterlacing dvds
[00:23:57 CEST] <nichego> thank you. that's great hands-on help
[00:24:33 CEST] <furq> you'll need a million different libs for qtgmc, but you can use other deinterlacers multithreaded with much less effort
[00:24:56 CEST] <furq> i'm not sure if qtgmc works at all on *nix, i had to use a couple of precompiled binaries for windows
[00:25:51 CEST] <furq> i should really have made a list when i was wading through forum posts piecing it all together
[00:31:14 CEST] <nichego> it's explained here
[00:31:16 CEST] <nichego> https://bbs.archlinux.org/viewtopic.php?id=190192
[00:31:29 CEST] <nichego> i just needed some pointers for keywords to search with
[00:31:34 CEST] <nichego> your script did the job :)
[00:32:24 CEST] <furq> it's a shame that vapoursynth seems to be a bit slower than avisynth
[00:32:36 CEST] <furq> but it does have the advantage of not constantly segfaulting eight hours into an encode
[00:33:03 CEST] <nichego> anything faster than 0.7 fps on an i7 is welcome
[00:33:15 CEST] <nichego> that's the kind of thing i'm getting out of yadif,mcdeint
[00:33:44 CEST] <furq> that is impressively slow
[00:34:05 CEST] <furq> you can use nnedi in ffmpeg but it's singlethreaded so it's pretty much useless
[00:35:13 CEST] <nichego> the slowness gives me time to figure how to use native qtgmc with vapoursynth, for future encodes
[00:37:07 CEST] <furq> that looks much simpler than it does on windows
[00:37:27 CEST] <furq> i ended up having to download a bunch of dlls from dropbox, which is a very secure thing to do
[00:37:42 CEST] <furq> although on balance probably not that much worse than using the AUR
[00:37:43 CEST] <nichego> yeah, vapoursynth really is a blessing in those regards
[00:37:55 CEST] <nichego> at least the code can be reviewed
[00:38:02 CEST] <nichego> rather than downloading random binaries
[00:38:15 CEST] <furq> this was for vapoursynth
[00:38:27 CEST] <furq> although it was only a couple of things that weren't on github, rather than literally everything like it was with avisynth
[00:40:21 CEST] <nichego> it will get better over time
[00:40:24 CEST] <nichego> with aur, too
[00:44:06 CEST] <nichego> ls
[00:44:13 CEST] <nichego> wrong window
[00:48:34 CEST] <nichego> it is rather surprising that f3kdb needs python-pygments. why is that even relevant
[00:50:22 CEST] <nichego> thanks again, furq
[02:06:26 CEST] <mrelcee> i actually had a coredump today for the first time ever from ffmpeg.     99m into an encode..   went to encode it again and it encoded fine.    i blame cosmic rays
[02:11:52 CEST] <DHE> needs ECC memory. at least that's what I hear people way
[02:12:07 CEST] <DHE> *say
[02:13:52 CEST] <mrelcee> that, i do not have
[02:15:20 CEST] <mrelcee> i am hoping it's not a 3.1.1 bug..  i got up the gumption to compile my own on freebsd with a little help from here to use gmake instead of make..      freebsd port is stuck at 2.8.7
[02:17:29 CEST] <DHE> if it is a software bug, would be a race condition or uninitialized memory usage most likely. both are a pain to identify
[02:17:35 CEST] <DHE> if it is cosmic rays, well, all bets are off
[02:27:17 CEST] <mrelcee> well i was. surprised when the file encoded fine after the error..
[04:48:24 CEST] <mrelcee> anudder core dump...     i know the system is rock solid stable, cosmic rays seem lless likely now..
[09:11:27 CEST] <NoobGuy1> Hello.  I currently use nginx to encode a stream from down to a 3.5 Mb stream for twitch.  I have a couple spare identical servers, I was wondering 1, is there any sort of way to "farm" it out, or 2, would there be any advantage to doing the transcoding with two server in series, one right after another?
[09:11:54 CEST] <NoobGuy1> Maybe the first server takes it down to 5 Mb, then the next to 3.5?  Would there be any possible gain in quality?  Thank you.
[09:13:34 CEST] <NoobGuy1> I have a 25 mb stream (from NVENC H.264) sent to the server, that transcodes it to 3.5mb.  Then sends it to the streaming provider.  Trying to add some specifics. Thanks.
[09:21:47 CEST] <Mavrik> NoobGuy1, video is stored in a lossy format. Every time you transcode it you permanently lose quality no matter the settings.
[09:22:07 CEST] <Mavrik> Meaning - repeatedly transcoding the same video instead of only once is going to hurt you way more.
[09:22:47 CEST] <Mavrik> "Farming" out for such videos makes little sense as well - a good Xeon will transcode that before the network transfer to another machine is properly complete.
[09:49:12 CEST] <drastik> ffmpeg -i https://streamlink/playlist.m3u8 -c copy -bsf:a aac_adtstoasc -f mp4 filename.mp4
[09:49:19 CEST] <drastik> i am using this to record a live stream
[09:49:29 CEST] <drastik> the command partially works, but
[09:49:55 CEST] <drastik> http://pastebin.com/SKPDvQqC
[09:49:55 CEST] <drastik> i get this in the console at some poin
[09:49:56 CEST] <drastik> and ffmpeg never exits
[09:50:24 CEST] <drastik> it still at this point
[09:50:42 CEST] <drastik> noone streams now, so i know its not recording anything
[09:55:19 CEST] <drastik> btw if i execute this on a small stream, i will work fine (it will exit and wont output anything)
[10:02:59 CEST] <drastik> any help is greatly appriciated
[13:00:02 CEST] <Vollstrecker> Hi folks, my mythtv is segfaulting on some mkv, and on some not. Using ffprobe the only difference I found (beside resolution etc.) is: yuv420p(tv, smpte170m/bt470bg/bt709) on the not working file and  yuv420p(tv, bt709) on the working. I just can't find the right way to change that. Any hints?
[13:02:47 CEST] <Vollstrecker> I tried with colorspace=bt709 and colormatrix=bt709:bt709 and colormatrix=bt709 but always get Unable to find a suitable output format and invalid argument
[14:44:08 CEST] <Kadigan> Hello. I was wondering if someone could point me in the direction of documents that properly explain the -bufsize option? I don't understand what is meant by "enforce your requested 'average' across each Xk worth of video"
[14:45:18 CEST] <JEEB> you have maxrate and bufsize, and those should always be used together
[14:45:25 CEST] <Kadigan> I mean, the way I understand it, the "[n]k worth of video" is a value that says "this part of video should be encoded at [n]k to be visually identical to the original", and this confuses me
[14:45:37 CEST] <JEEB> no
[14:45:38 CEST] <Kadigan> JEEB: https://trac.ffmpeg.org/wiki/Encode/H.264 this page claims otherwise
[14:45:56 CEST] <Kadigan> it proposes maxrate of 4000k and bufsize of 1835k
[14:46:04 CEST] <Kadigan> and I do not understand how that value was arrived at.
[14:46:16 CEST] <JEEB> that depends completely on your usage scenario
[14:46:25 CEST] <JEEB> I mean, it's bandwidth limiting
[14:46:35 CEST] <Kadigan> Okay. Better question: how should I arrive at -bufsize?
[14:47:00 CEST] <JEEB> it means that you are telling the encoder that over bufsize amount of bits, never go over maxrate bits per second
[14:47:18 CEST] <Kadigan> What is "bufsize amount of bits"?
[14:47:39 CEST] <Kadigan> Why do I need a second limiter, when my bitrate is already limited by -maxrate?
[14:47:57 CEST] <Kadigan> Is my top rate limited by -maxrate?
[14:47:57 CEST] <JEEB> because maxrate by itself does jack shit as the algorithm requires two variables
[14:48:17 CEST] <Kadigan> JEEB: okay, then I am obviously confused as to how the algorithm works.
[14:48:20 CEST] <JEEB> if you just want to have an output of average bit rate over the whole video of X, then you don't touch maxrate|bufsize
[14:48:42 CEST] <JEEB> if you want to bandwidth limit for f.ex. DVD|BD specification or for over-the-network stuff
[14:48:46 CEST] <JEEB> then you need maxrate|bufsize
[14:49:03 CEST] <JEEB> because you have your main rate control method, and then you are adding *additional* limitations on top of that
[14:50:02 CEST] <Kadigan> Okay. Let me explain my thought process: I have a video encoded at a specific rate. My understanding is that compression is always lossy, but I don't have the patience to compare two videos frame-by-frame to determine the right settings. As such, I assumed that if I set the compressor to minrate (original of video) and then put the ceiling a little bit higher, that would account for situations where it would want to put more data into a frame than
[14:50:02 CEST] <Kadigan> there was due to compression-specific stuff.
[14:50:22 CEST] <JEEB> no, never use minrate
[14:50:46 CEST] <JEEB> it most often doesn't do what you think it does and is not a native thing in many encoders so its implementation is crapola
[14:50:57 CEST] <Kadigan> I understand that it's wasteful, but I've yet to sit through* a visual comparison that claims it's identical in terms of quality.
[14:51:00 CEST] <JEEB> also your original bit rate doesn't matter jack shit when re-compressing anything
[14:51:34 CEST] <JEEB> you have your input and then depending on your compression settings, format etc the requirement for some sort of visual output differs
[14:51:55 CEST] <Kadigan> JEEB: okay. So let's throw everything I know about bitrates out the window. How should I approach setting my compression settings?
[14:51:58 CEST] <JEEB> for libx264 the simplest way is to use CRF, which is the closest we have to "constant quality"
[14:52:25 CEST] <JEEB> you start with -crf and encode like 1500 frames of stuff (cut a few parts of the content you're going to be recompressing)
[14:52:29 CEST] <JEEB> *-crf 23
[14:52:33 CEST] <JEEB> (which is the default)
[14:52:40 CEST] <Kadigan> Here's another question: I've noticed that ffmpeg got 'h264' and 'libx264'. Which one should I use for compatibility with devices like TVs?
[14:52:54 CEST] <Kadigan> (possibly BR players that can play files)
[14:52:56 CEST] <JEEB> h264 is just a decoder
[14:53:15 CEST] <JEEB> you can I think use the name of the format for encoding as well, but it will just map to a random external encoder library, in most cases libx264
[14:53:19 CEST] <Kadigan> So if I specify -c:v h264, it assumes -c:v libx264?
[14:53:30 CEST] <JEEB> most probably the auto-mapping will go like that
[14:53:38 CEST] <JEEB> because there is no internal AVC encoder
[14:53:50 CEST] <Kadigan> I see. So yes, I expect specifying libx264 is better than hoping "it will all go well".
[14:53:57 CEST] <JEEB> yes
[14:53:59 CEST] <Kadigan> Okay. Changed.
[14:54:02 CEST] <Kadigan> Now, the bitrate?
[14:54:10 CEST] <JEEB> scroll a few lines up
[14:54:27 CEST] <JEEB> where I started writing "for libx264 the simplest way is to use..."
[14:54:33 CEST] <Kadigan> The original video is .rmvb, and it's crap. I was also trying to go for smallest size of file, while not going beyond "barely watchable".
[14:54:43 CEST] <Kadigan> Yeah, I saw the stuff about crf.
[14:55:00 CEST] <JEEB> ok, so if the value looks crap then you go down and if it looks good you go up
[14:55:12 CEST] <JEEB> then you will find the CRF value for yourself for that sort of content
[14:55:27 CEST] <Kadigan> I usually encode either low-quality previews (where I use bitrate, maxrate minrate bufsize) for streaming on 2M lines, or for lossless storage/youtube. I don't really have a feeling for middle-ground encoding.
[14:55:28 CEST] <JEEB> (you can roughly utilize the same or similar value with very similar input)
[14:56:10 CEST] <Kadigan> Half the time I just -c:v prores_ks -profile:v yuv422p10le ^^
[14:56:12 CEST] <JEEB> so what I mean is that you cut/limit the encode to a few scenes of ~500 frames
[14:56:27 CEST] <JEEB> and from those you can then quickly start iterating on the CRF value
[14:56:31 CEST] <Kadigan> I see. So basically what I dread - video comparison.
[14:56:57 CEST] <JEEB> there's no other way really :P and as I said, you can generally then use similar values for similar resolution and content
[14:57:05 CEST] <Kadigan> Okay, so about CRF: if a frame needs less than what CRF would specify, will the encoder be wasteful?
[14:57:19 CEST] <Kadigan> I assume not, but there may be details of the implementation I am not aware of.
[14:57:22 CEST] <JEEB> no, because you picked the highest CRF value that still looks good enough for you
[14:58:07 CEST] <Kadigan> The situation I mean is more like: "this scene could easily be visually-identically encoded at -crf 50, but user specified -crf 23"
[14:58:19 CEST] <Kadigan> how does that work out?\
[14:58:38 CEST] <JEEB> if they are simple scenes they are easily coded with a lower quantizer as well
[14:58:52 CEST] <Kadigan> I mean - will ffmpeg make that choice for me?
[14:58:56 CEST] <JEEB> libx264 will
[14:58:59 CEST] <JEEB> with crf
[14:59:04 CEST] <Kadigan> ie. will I get the same output file size for crf 23 and crf 50
[14:59:09 CEST] <Kadigan> if the video fits perfectly into crf 50.
[14:59:32 CEST] <Kadigan> (I'm generalizing here, please assume I would expect small variations)
[14:59:37 CEST] <JEEB> if it's easily coded it won't be the same but the difference shouldn't be too big
[15:00:08 CEST] <Kadigan> I see. So basically using -crf 23 is the way to go unless you need specific requirements met, or the video is of higher quality.
[15:00:58 CEST] <JEEB> my recommendation is still to at least try it once and if it's "good enough", sure :P but generally you want to go through a few iterations of ~1500 frames or so (three 500 frame scenes or whatever)
[15:01:03 CEST] <Kadigan> I'm wondering about all this because the target device is a Sony TV, and I have absolutely no idea how it'll react. I'm already limiting to Main/3.1, which I assume will be enough.
[15:01:06 CEST] <JEEB> such test encodes should be quick enough
[15:01:20 CEST] <Kadigan> Yeah, but I don't have the device. ^^
[15:01:21 CEST] <JEEB> main/3.1 seems like OK limits for a lot of hardware
[15:01:45 CEST] <JEEB> Kadigan: but you can still check the output on your shit :P unless you have no screen whatsoever
[15:02:04 CEST] <JEEB> and those test encodes should be rather quick to create since as I said you usually use 1500-2000 frames for them
[15:02:04 CEST] <Kadigan> Yeah, but I'm running CCCP+SVP+madVR+MPC-HC,
[15:02:11 CEST] <Kadigan> so I assume that it will play anything I throw at it :D
[15:02:49 CEST] <Kadigan> (I've confirmed it will also play 4K and 8K video, which the TV in question would most certainly crap out at)
[15:02:52 CEST] <JEEB> SVP will be your main headache
[15:03:01 CEST] <JEEB> but that's off-topic on this channel
[15:03:13 CEST] <Kadigan> No, I have a separate setup that bypasses SVP for this very reason.
[15:03:33 CEST] <Kadigan> I assume that as long as I don't hit the HW bitrate limitations on the TV
[15:03:43 CEST] <Kadigan> (I've found that a good ceiling value is 20M/s)
[15:03:45 CEST] <Kadigan> I should be good.
[15:04:22 CEST] <JEEB> blu-ray official limits are 40M maxrate and 30M bufsize, but even those players generally tend to be able to take in more
[15:05:03 CEST] <Kadigan> I've noticed that some players will not play unless the file is strictly within spec, or within their own exotic spec... But maybe I'm just biased.
[15:05:26 CEST] <JEEB> most modern stuff supports up until high/4.1 (profile/level)
[15:05:30 CEST] <Kadigan> (as a rule of thumb, cheaper players will accept and play a wider variety of stuff, too...)
[15:05:44 CEST] <JEEB> some sony stuff supports only main/4.1
[15:05:56 CEST] <JEEB> and then the PSP f.ex. only supported main/3.0
[15:05:57 CEST] <Kadigan> +below, or STRICTLY Main/4.1?
[15:06:20 CEST] <JEEB> Kadigan: (constrained) baseline is a subset of main, main is a subset of high
[15:06:34 CEST] <Kadigan> Ah.
[15:06:39 CEST] <Kadigan> That makes sense, actually.
[15:06:46 CEST] <JEEB> profiles = features
[15:06:48 CEST] <Kadigan> So always backwards-compatible due to inclusion.
[15:06:55 CEST] <JEEB> levels = amount of memory required by playback device
[15:07:08 CEST] <Kadigan> Now that makes sense. Didn't know that.
[15:07:56 CEST] <JEEB> so basically levels define stuff like resolution, maximum available pictures in reference frame buffer etc
[15:08:05 CEST] <JEEB> and bit rate limits
[15:08:46 CEST] <JEEB> so in theory if you want to be *really* pedantic you need to always stick to some sort of maxrate/bufsize but so much hardware is capable of over those limits that we generally tend to ignore them ;)
[15:08:50 CEST] <Kadigan> Wow... So let me understand this: the Profile and Level now dictate the minimum set of "decoder features" and "framebuffer memory", stuff that I recall from the good old days of S3 Virge.
[15:09:26 CEST] <Kadigan> As in, a handy way to describe hardware capabilities without using GL Extensions and chip inspection.
[15:09:31 CEST] <JEEB> yup, although not limited to framebuffer memory
[15:10:16 CEST] <JEEB> but for the decoder chip the required amount of memory and the required amount of memory bandwidth is what's being defined
[15:10:44 CEST] <JEEB> I think they define the buffer sizes in macroblocks so you can then indirectly calculate the amount of reference frames based on your resolution padded to 16x16 blocks
[15:10:47 CEST] <Kadigan> So a bit better metric, because it combines more information.
[15:11:18 CEST] <Kadigan> Damn, video encoding (while still something to figure out) has gotten a lot easier over the years, hasn't it.
[15:11:29 CEST] <JEEB> (this is what is done when you set -level 41 f.ex on the libx264 wrapper - it will limit the amount of used reference frames accordingly)
[15:11:30 CEST] <Kadigan> (and I assume ffmpeg is in big part to thank for that)
[15:12:02 CEST] <Kadigan> I see.
[15:12:14 CEST] <JEEB> yeah, AVC was a major step in making the video decoding process bit-exact (yes, MPEG-1/2 Video and MPEG-4 Part 2 weren't bit-exact), and they had clear "tiers" for things like that
[15:12:33 CEST] <JEEB> of course crappy vendors have created crappy hardware during the years, but mostly we are in a very happy land compared to before
[15:13:16 CEST] <Kadigan> So, ffmpeg just finished encoding the file. I used aac at 128k and crf 23. The file is quite bigger than the original .rmvb (400 vs 550MB), but I assume it has to do with my audio settings (the original was MP3 at 86kbps) and file/encoding structure.
[15:13:54 CEST] <Kadigan> It's not an issue - just something I'm musing on.
[15:14:26 CEST] <Kadigan> Here's a good question: is there a video player for Windows that You know of that can play two video files side-by-side in sync?
[15:14:44 CEST] <Kadigan> (speficically for the purposes of comparing two encodes of the same source file)
[15:15:48 CEST] <JEEB> not that I know. I usually just open two mpvs and/or vapoursynth editor with two things interleaved
[15:16:03 CEST] <JEEB> also as I noted, don't just encode the whole thing unless it's really short
[15:16:37 CEST] <JEEB> you can -ss and -t (seek and time to encode) in ffmpeg cli if you want to use that for cutting a part out
[15:17:35 CEST] <Kadigan> Yeah, I typically use -ss and -vframes
[15:17:47 CEST] <Kadigan> And yes, it took me a while to figure out where to put -ss
[15:18:47 CEST] <Kadigan> (I eventually got used to source-seeking for minutes and then output-seeking to frames)
[15:20:08 CEST] <Kadigan> Also, another good use-case for ffmpeg: I quite often use it in conjuction with an XML parser to cut up output from an NLE - say, I have 20 videos which I did in a row (30-90s each) using the same effects/tools, and I don't want to export each and every one separately, because PITA.
[15:21:14 CEST] <Kadigan> Anyway, thanks for the assist JEEB.
[15:21:16 CEST] <JEEB> for stuff like editing I recommend taking a look at vapoursynth
[15:21:27 CEST] <JEEB> and possibly vapoursynth editor for preview purposes
[15:21:35 CEST] <JEEB> you write a script and that outputs you raw YCbCr or RGB
[15:21:41 CEST] <Kadigan> I assume You mean - instead of using an NLE.
[15:21:47 CEST] <JEEB> not necessarily
[15:21:56 CEST] <Kadigan> Does it run on OS X?
[15:21:58 CEST] <JEEB> yes
[15:22:55 CEST] <Kadigan> Ah, so it's a cross between avisynth (which I remember being a plugin) and a script interpreter.
[15:23:08 CEST] <Kadigan> (I'm probably very wrong there :D)
[15:23:24 CEST] <Kadigan> Interesting.
[15:23:51 CEST] <JEEB> well avisynth is "the original" OSS frameserver, and it just had its own scripting language
[15:24:15 CEST] <JEEB> which was very crappy and people just got used to it (you f.ex. didn't have ifs etc but you did have ternary operators)
[15:24:34 CEST] <Kadigan> I remember there was a good reason why I didn't learn avisynth.
[15:24:51 CEST] <JEEB> while vapoursynth just takes python and utilizes it for the scripting part, although in theory you can make your own mappings against other languages
[15:25:18 CEST] <Kadigan> Maybe because people usually recommended its use with VirtualDub, which was in itself mighty unstable...
[15:25:38 CEST] <Kadigan> Hm, that's an interesting proposition actually.
[15:25:55 CEST] <JEEB> virtualdub was one of the first things you could preview it with nicely
[15:26:06 CEST] <JEEB> although later you had AvsP(mod)
[15:26:09 CEST] <Kadigan> I do PHP work mostly, with the occasional dip into C/C++/C#. Maybe there's a mapping set for PHP out there.
[15:26:41 CEST] <JEEB> nah, the only ones that were worked upon were lua and JS and neither was finished, IIRC
[15:27:02 CEST] <JEEB> although I'm not sure since I remember some people using !python with vapoursynth in mpv
[15:27:17 CEST] <furq> LuaSynth is a LuaJIT 2.0 binding for VapourSynth. It is currently a hacked together mess which was mostly created in a single sitting with very little thought,
[15:27:20 CEST] <furq> well at least he's honest
[15:27:36 CEST] <JEEB> right, that one
[15:34:41 CEST] <furq> that seemed interesting for a minute there until i realised i'd also have to port >10kloc of vs scripts for it to be of any use
[15:35:18 CEST] <furq> which will probably take more time than just dealing with vs being a bit slow
[15:36:12 CEST] <JEEB> well I'm not sure if much of the slowness is due to cpython compared to anything that is bound straight into native things
[15:36:50 CEST] <Venti^_> Kadigan: I think any HD tv should be able to handle high profile level 4
[15:43:40 CEST] <Venti^_> well, DVB televisions at least, americans might do things different
[16:07:01 CEST] <Kadigan> I think so too, but I've seen stuff fall flat on its face if the USB drive didn't have a /DCIM/SOMESHIT/ folder structure.
[16:07:21 CEST] <Kadigan> (hence I'm cautious about making assumptions of it "just working")
[16:16:28 CEST] <Kadigan> Anyway, thanks again!
[16:38:46 CEST] <Kadigan> I'm back. I have another issue. I have a video file that's supposed to be 4:3, but it's behaving as if it's something more like 5:3. I tried scaling it, but it produced output that's similar to the original. MPC-HC tells me the AR of the video is 1.772, and I need it to be 1.3[3]. How do I tell ffmpeg to change AR to that specific value as well?
[16:39:49 CEST] <JEEB> post output of that file on a pastebin from ffprobe filename or ffmpeg -i filename
[16:40:04 CEST] <JEEB> and link here
[16:40:29 CEST] <Kadigan> http://pastie.org/private/qhpq8uay1pbnihamgvdidw
[16:41:03 CEST] <Kadigan> Ah, that got the output. Wait.
[16:41:29 CEST] <Kadigan> http://pastie.org/private/tq63edp6ereowjhc8aslw here is the source file
[16:42:09 CEST] <Kadigan> Can I simply setdar=4/3 ?
[16:42:37 CEST] <JEEB> if that thing is just wrongly flagged as 1:1, yes
[16:42:39 CEST] <Protected> Hey all. Is there any way to get -progress to overwrite the file instead of appending to it?
[16:43:30 CEST] <Kadigan> JEEB: setdar=4/3 worked. Yes, it was encoded from an old reel to PC by someone who didn't know what they were doing and was content with the result.
[16:43:47 CEST] <Kadigan> It's a TV news broadcast from 1986 in Poland, so it couldn't have been 16:9 ;)
[16:44:14 CEST] <JEEB> now just hope you know exactly how much was cropped out as well
[16:44:26 CEST] <Kadigan> I believe it was simply squished.
[16:44:38 CEST] <Kadigan> (ie. when I recode to 4:3, it looks okay and seems to have the entire picture)
[16:44:52 CEST] <Kadigan> Yup, it looks good now.
[16:44:55 CEST] <JEEB> well, just switching the aspect ratio doesn't change the content
[16:44:58 CEST] <JEEB> btw, if you don't want to re-encode you can just use L-SMASH's tools (muxer/remuxer) to just modify the aspect ratio
[16:45:15 CEST] <JEEB> since you've got an ISOBMFF (colloquially "mp4") file there
[16:45:25 CEST] <Kadigan> I reencoded already, it's 13min long and SD. ;)
[16:45:42 CEST] <JEEB> well, if you ever want to fix it without doing another lossy set of compression
[16:46:10 CEST] <Kadigan> Yeah, I'll keep that in mind. Seems that most modern containers are very versatile.
[16:46:52 CEST] <JEEB> for AVC you can have the SAR in the bit stream, but then if you have info on the container level that generally is specified to override that
[16:46:52 CEST] <Kadigan> (I am aware, to an extent, of the difference between "encoding" (format?) and "container")
[16:47:30 CEST] <JEEB> (ISOBMFF specifically says that the info in the boxes override whatever there might be in the bit stream)
[16:47:50 CEST] <Kadigan> Bit of an aside: considering multiple streams, ordered chapters and multiple extra files (like subs, fonts etc.) - and assuming I don't know the capabilities of each - which container is better: mp4 or mkv?
[16:48:55 CEST] <JEEB> if you need virtual timelines mp4 does support them but they definitely got more support in players on the matroska side (the idea stems from ISOBMFF's roots in MOV)
[16:49:15 CEST] <JEEB> and I must say that virtual timelines in at least matroska aren't supported at all in libavformat
[16:49:44 CEST] <JEEB> (things usually either have their own demuxer or they implement a wrapper around libavformat)
[16:50:05 CEST] <JEEB> then you have segment linking which is separate but was often used with virtual timelines
[16:50:39 CEST] <JEEB> as a feature it was present once again in mov originally, but more seen used in certain circles of matroska users. generally same comments apply with regards to libavformat not supporting it
[16:51:17 CEST] <JEEB> for subs and fonts you in theory can do it with mp4 but generally more supported in matroska even though ASS is atrocious
[16:53:47 CEST] <furq> 15:44:58 ( JEEB) btw, if you don't want to re-encode you can just use L-SMASH's tools (muxer/remuxer) to just modify the aspect ratio
[16:53:57 CEST] <furq> you can modify the dar with ffmpeg
[16:54:03 CEST] <furq> -c copy -aspect 16:9
[16:54:55 CEST] <JEEB> oh
[16:55:00 CEST] <JEEB> I just remember that not working at some point
[16:55:03 CEST] <JEEB> nice if it does nowadays
[16:55:15 CEST] <furq> i'm not going to pretend to know it always works, but it's always worked for me
[16:55:23 CEST] <JEEB> :)
[17:19:42 CEST] <Threads> anyway to have subtitles added but not forced on ?
[17:19:57 CEST] <Threads> i keep getting them added and they play at the same time with the file and i dont want that
[18:49:33 CEST] <oerg866> Hello. I have a video recorded at 720x576 interlaced 25fps. However the source is an old video game outputting 720x288 at 50fps. How can I put each "field" into its own frame? The deinterlace filters seem to all apply some algorithm instead of just taking raw fields.
[18:51:15 CEST] <furq> oerg866: https://ffmpeg.org/ffmpeg-filters.html#separatefields
[18:51:34 CEST] <oerg866> Thank you so much :3
[19:19:24 CEST] <gordonfly> anyone have experience joining two videos?
[19:23:23 CEST] <__jack__> sure
[19:26:51 CEST] <gordonfly> what is the recommended way to do this through ffmpeg?
[19:27:05 CEST] <gordonfly> can't seem to get this script to work:https://trac.ffmpeg.org/wiki/Concatenate
[19:27:55 CEST] <gordonfly> is there a media format that works best for concatenation?
[19:33:06 CEST] <NoobGuy1> Mavrik, thank you.  I am working with a Dual Xeon E5-2450 (2 GHz 8 core), but it starts to choke on any preset last medium when transcoding live. Just looking for other options to take advantage of the other servers I have sitting idle.  Doesn't look like there is any other choice sadly.
[19:58:48 CEST] <podman> Hopefully a quick question. I have some files that require larger probesize and analyzeduration values than the default. In the documentation it says: A higher value will enable detecting more accurate information, but will increase latency. Is the latency significant? If the probe finds all of the information needed before it's reaced the probesize or
[19:58:48 CEST] <podman> analyzeduration limits, will it stop or will it keep going until it's reached the probesize and analyzeduration values?
[20:19:44 CEST] <DHE> some people just want the probe process to be fast. obviously it will need to read and decode more data if you crank up the numbers.
[22:04:57 CEST] <KDDLB> quick question, the DTS decoder supports HD-MA?
[22:05:50 CEST] <KDDLB> does the & support *
[22:06:28 CEST] <JEEB> if it's new enough to have had it been replaced by the dts decoder library maintainer then yes
[22:06:36 CEST] <JEEB> it supports the XLL lossless extension
[22:06:55 CEST] <JEEB> (basically the old decoder was scrapped and replaced with the libdts one's internals)
[22:07:26 CEST] <JEEB> since that I think support for DTS Express was also added
[22:58:54 CEST] <DelphiWorld> SUP
[23:01:32 CEST] <__jack__> ER
[23:04:34 CEST] Action: DelphiWorld here with __jack__
[23:19:29 CEST] <Soltis> Is it possible to "stabilize" color with ffmpeg if, e.g., the camera's automatic color correction went nuts during filming?
[23:21:12 CEST] <DelphiWorld> i'm still having issue streaming a hwaccel encoded H.264 to rtmp
[23:31:35 CEST] <Kadigan> Just for kicks, how can I use ffmpeg to encode into Animation? And by "Animation" I mean the codec 'Animation', the one that allows me to export alpha channels at "Millions of colors+".
[23:32:09 CEST] <Kadigan> Apparently Google is now too bloated to answer that question w/o telling me how to encode video animation into h264.
[23:32:33 CEST] <JEEB> so what exactly do you require? 8bit per sample RGB with alpha lossless?
[23:33:08 CEST] <Kadigan> I honestly never did that in ffmpeg, so all I know is that I need to re-code from ProRes 4:4:4:4 to Animation so that Premiere Pro accepts it with Alpha.
[23:33:19 CEST] <JEEB> whatever that "animation" means
[23:33:49 CEST] <JEEB> but I do know that most editors take in Ut Video (which is lossless) through the VFW component and supports alpha
[23:34:03 CEST] <JEEB> for which I made an encoder in FFmpeg in 2012 (-c:v utvideo)
[23:34:59 CEST] <Kadigan> JEEB: I don't know what You mean. I don't kow this Ut Video.
[23:35:11 CEST] <JEEB> same goes for whatever you mean with this "animation" thing
[23:35:25 CEST] <furq> https://en.wikipedia.org/wiki/QuickTime_Animation
[23:35:26 CEST] <furq> this?
[23:35:38 CEST] <JEEB> oh, quicktime RLE
[23:35:41 CEST] <JEEB> that I've seen
[23:35:44 CEST] <JEEB> mentioned somewhere
[23:35:50 CEST] <Kadigan> https://discussions.apple.com/thread/1895735?tstart=0
[23:35:52 CEST] <JEEB> and yes, that article links to the dec and encoder
[23:35:58 CEST] <JEEB> in FFmpeg
[23:35:59 CEST] <furq>  -c:v qtrle
[23:36:00 CEST] <Kadigan> For all my purposes it has always been called "Animation"
[23:36:08 CEST] <Kadigan> I've never seen it called QT RLE
[23:36:23 CEST] <Kadigan> How do I tell qtrle to encode with alpha?
[23:36:55 CEST] <JEEB> anyways, that seems in a way similar to Ut Video going by the RLE word. although Ut Video did have prediction as well
[23:37:18 CEST] <JEEB> Kadigan: it should keep that as-is unless you tell it otherwise or it doesn't support the input pixel format you're giving to it
[23:37:54 CEST] <JEEB> see the output pixel format that ffmpeg's command line ouptuts :P
[23:38:24 CEST] <JEEB> supported formats for QT RLE are AV_PIX_FMT_RGB24, AV_PIX_FMT_RGB555BE, AV_PIX_FMT_ARGB, AV_PIX_FMT_GRAY8, AV_PIX_FMT_NONE
[23:38:53 CEST] <JEEB> you probably want the ARGB one and then you'll want to make sure the YCbCr that comes from prores is properly converted
[23:40:05 CEST] <JEEB> but yeah, I recommend Ut Video nowadays for windows and OS X video editing since the original author makes plugins for all major multimedia systems
[23:42:24 CEST] <Kadigan> There a straightforward way to have ffmpeg iterate through a directory and convert all specified files?
[23:42:27 CEST] <Kadigan> (Windows CMD)
[23:43:06 CEST] <furq> does installing msys bash count as straightforward
[23:43:30 CEST] <JEEB> just learn whatever windows scripting thing you want (or even python if you want something future-proof)
[23:43:39 CEST] <JEEB> even batch can do for loops over files
[23:43:44 CEST] <Kadigan> Okay, fine. ;)
[23:44:02 CEST] <Kadigan> Bash loops are not straightforward, but I'll deal :D I was kinda hoping for some autodetection mode,\
[23:44:07 CEST] <Kadigan> but yeah, not the first rodeo.
[23:45:41 CEST] <JEEB> isn't it something like `for i in $(find . -iname '*.ext'); do ffmpeg -i "${i}" -options! "out-${i}.ext"; done`?
[23:45:51 CEST] <Kadigan> it's more like
[23:46:02 CEST] <JEEB> it's batch that I actually don't remember
[23:46:04 CEST] <Kadigan> `for /f "tokens=*" %f in ('dir /b') DO`
[23:46:16 CEST] <JEEB> right, batch
[23:46:17 CEST] <furq> find . -name *.mp4 -exec ffmpeg -i "{}" {}.mkv \;
[23:46:23 CEST] <furq> obviously not in batch though
[23:46:31 CEST] <furq> also with more quotes
[23:46:41 CEST] <JEEB> you said bash so I put out a bash example :P
[23:46:45 CEST] <Kadigan> furq I'm used more to `ls | while read $f; do`
[23:46:50 CEST] <Kadigan> and just dealing with . and .. ;D
[23:46:59 CEST] <furq> well you should stop being used to that
[23:47:24 CEST] <Kadigan> it's shorter than `find . -type f -name "*.mov"` and ignores case.
[23:47:24 CEST] <JEEB> and right, find had exec too
[23:48:29 CEST] <JEEB> I think `find . -type f` would then do that what you want?
[23:48:37 CEST] <JEEB> if you just want to take in all files
[23:48:42 CEST] <furq> you don't need -type f if you're using -name
[23:48:53 CEST] <JEEB> yes, but if he wanted the equivalent of just ls
[23:48:58 CEST] <JEEB> without extra filters
[23:49:00 CEST] <furq> also you don't need to specialcase . and .. if you use find, which i would hope removes any verbosity benefits
[23:49:08 CEST] <Kadigan> furq: I know
[23:49:29 CEST] <Kadigan> JEEB: doesn't matter; I'm on Windows right now, and on OS X I just write scripts (and then write them right) once and then forget.
[23:49:37 CEST] <furq> also in that case why not just use for f in *; do
[23:49:52 CEST] <JEEB> Kadigan: sure
[23:50:12 CEST] <JEEB> and on windows the stuff you have by default are batch and then the VBscript and JSscript things
[23:50:17 CEST] <JEEB> haven't tried the latter ones at all
[23:50:19 CEST] <furq> and powershell
[23:50:23 CEST] <JEEB> oh, right
[23:50:24 CEST] <JEEB> that one
[23:50:25 CEST] <furq> not that i think much of powershell
[23:50:42 CEST] <furq> i know some people who swear by it but those are mostly people who get paid to edit group policy
[23:51:13 CEST] <JEEB> yeah, the MS server stuff actually seems to have great integration to powershell
[23:51:20 CEST] <JEEB> also you can ls through registry in it
[23:51:35 CEST] <JEEB> so for some stuff it seems awesomesauce on windows in order to not have to use the GUI stuff :D
[23:52:15 CEST] <furq> only in environments where you're prevented from installing a decent language
[23:52:25 CEST] <furq> but then a lot of windows sysadmins are often in that environment
[23:53:13 CEST] <JEEB> well I don't think you have the integration to those enterprisey things and registry as well (registry as a pseudo file system) in a lot of scripting systems
[23:53:24 CEST] <JEEB> in which case you'd have to write that stuff yourself or grab it somewhere
[23:53:38 CEST] <JEEB> so in that sense if shit's already provided it just makes sense to utilize
[23:54:06 CEST] <Kadigan> PowerShell is nice in at-the-very-least that it supports UTF-8 right off the bat :D
[23:54:16 CEST] <furq> you can edit the registry from most scripting languages i've used
[23:54:23 CEST] <furq> probably not group policy and whatnot though
[23:54:33 CEST] <JEEB> that's true > registry. I think python stdlib might have it even
[23:54:40 CEST] <furq> yeah i think it does
[23:55:11 CEST] <JEEB> but I like this about PS at the very least
[23:55:12 CEST] <JEEB> PS C:\Users\jeeb> cd hkcu:\
[23:55:12 CEST] <JEEB> PS HKCU:\> dir
[23:55:19 CEST] <JEEB> <stuff>
[23:59:15 CEST] <KDDLB> JEEB  TIL
[23:59:24 CEST] <KDDLB> I no longer use Windows on a daily basis, though
[23:59:47 CEST] <JEEB> I'm a mixed user, I get the cancer from multiple places ;)
[23:59:57 CEST] <KDDLB> harsh words Dx
[00:00:00 CEST] --- Sun Jul 24 2016