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

[burek]

[00:00:00 CEST] <furq> http://vpaste.net/PdHkr
[00:00:02 CEST] <furq> first video i tried
[00:00:31 CEST] <JEEB> kyleogrg: BBB's blog https://blogs.gnome.org/rbultje/2016/05/02/the-worlds-best-vp9-encoder-eve-2/
[00:00:53 CEST] <kyleogrg> ok
[00:01:49 CEST] <kyleogrg> when do you except av1 to reach maturity?
[00:02:04 CEST] <furq> probably some time next year
[00:02:14 CEST] <furq> they're supposedly freezing the bitstream format in Q3 or Q4 of this year
[00:02:24 CEST] <kyleogrg> all right
[00:02:38 CEST] <kyleogrg> any advantage to using x264 standalone vs within ffmpeg?
[00:02:44 CEST] <furq> not that i know of
[00:02:48 CEST] <JEEB> not really
[00:02:59 CEST] <kyleogrg> thoughts on ripbot264?
[00:03:14 CEST] <JEEB> but do keep in mind that bit stream freeze only means that what is "AV1" gets defined
[00:03:30 CEST] <furq> yeah it depends what you mean by "maturity"
[00:03:33 CEST] <JEEB> in other words, after that point if the encoder doesn't have bugs you should be able to decode your encodes from after that
[00:03:43 CEST] <kyleogrg> sure
[00:03:43 CEST] <JEEB> on any AV1 decoder
[00:03:50 CEST] <furq> if they do freeze the bitstream this year, then one would expect devices with av1 hwdec to show up in 2018
[00:03:55 CEST] <furq> and for places to be serving it by then
[00:04:05 CEST] <furq> obviously the encoders will take time to get really good
[00:04:16 CEST] <furq> or usably fast if you don't have google's infra
[00:04:44 CEST] <kyleogrg> anyone here use ripbot264?
[00:05:08 CEST] <furq> there's a million big corps backing it though, and it saves them all a lot of license fees if AV1 succeeds
[00:05:14 CEST] <furq> so there should be no shortage of developers
[00:05:32 CEST] <kyleogrg> furq: actually that's a really good point.  probably with convert a lot of x264 lovers
[00:05:39 CEST] <JEEB> sure, it has much bigger chances to succeed than libvpx or x265
[00:06:09 CEST] <furq> the only problem is apple
[00:06:10 CEST] <furq> imagine that
[00:06:21 CEST] <JEEB> also it was real fun talking with people from GOOG about "why don't you use VBV/HRD in the encoder?"
[00:06:34 CEST] <JEEB> "uhh, we just force the client to buffer enough and then the spikes aren't big enough"
[00:06:41 CEST] <furq> lol
[00:06:52 CEST] <JEEB> tl;dr fuck proper buffer management
[00:07:49 CEST] <furq> good job they don't have to deal with bluray players really
[00:08:00 CEST] <furq> that statement is true for any value of "they"
[00:11:23 CEST] <kyleogrg> what's the best audio codec in your opinion?
[00:11:57 CEST] <furq> opus for lossy audio
[00:12:25 CEST] <furq> it's not usually worth encoding the audio though
[00:12:41 CEST] <furq> unless your source is pcm
[00:12:42 CEST] <kyleogrg> furq: you mean like from a lossy youtube download?
[00:12:55 CEST] <kyleogrg> yeah
[00:13:22 CEST] <kepstin> JEEB: well, I guess that means the libvpx vbv stuff is mostly untested then? :/
[00:16:49 CEST] <kepstin> google is doing segmented media encoding for everything on yt tho, right? any they probably expect the player to buffer multiple segments, so they only really care that the average bitrate within a segment is ok.
[00:18:34 CEST] <JEEB> yea
[00:25:30 CEST] <kepstin> I suppose vbv controls aren't really super important for internet streaming aside from maybe reducing playback startup time/initial buffering nowadays.
[00:26:08 CEST] <c7j8d9> I have a 4k video that direct plays on my tv and another that doesn't so I attempted to encode it the same as the working one to no avail. Any thoughts why the later would not be playing like the first? https://pastebin.com/aDjtgam9
[00:26:13 CEST] <kepstin> it's not like we're encoding for dvd players with <¼MB of ram any more.
[00:35:08 CEST] <Asuran> i guess they just use android now adays
[00:35:16 CEST] <Asuran> atleast in tv
[01:05:35 CEST] <Asuran> ehm im kinda confused with http://slhck.info/video/2017/02/24/crf-guide.html you can really use in pass 1 crf and pass 2 b:v?
[01:06:01 CEST] <Asuran> couldn't you then use like vp9 both with crf?
[01:37:29 CEST] <thebombzen> Asuran: 2-pass with CRF doesn't help any more than 1-pass CRF
[01:37:47 CEST] <Asuran> thanks
[01:40:40 CEST] <LinuxLoader> thebombzen ... what are the most ffmpeg procceses that you are tested on single machine
[01:41:05 CEST] <thebombzen> why are you asking me
[01:41:12 CEST] <LinuxLoader> because i run out of cpu :( then of GPU :(
[01:41:22 CEST] <thebombzen> why are you asking me
[01:41:55 CEST] <LinuxLoader> 4xQuadro P5000 and 2xXeon E5-2620 v4 @ 2.10GHz load 100 :)
[01:42:16 CEST] <thebombzen> you should not be surprised if your cpu load is 100 percent
[01:42:37 CEST] <LinuxLoader> yep :) but i use gpu encoding and decoding
[01:43:06 CEST] <thebombzen> "why doesn't it work" is not a question I can answer
[02:00:26 CEST] <lindylex> Greeting all I created the following python using mostly ffmpeg for editing media https://github.com/MotionDesignStudio/commandlinemediahelper/blob/master/README.md   I added a cross fade affect to the special affects.  You can use it like this ./ffmpegHelper.py -e15 vid1.mov vid2.mov 2 out.mp4
[02:24:21 CEST] <Aerroon> has anybody built a video editor on top of ffmpeg?
[02:24:33 CEST] <furq> yes
[02:25:15 CEST] <Aerroon> sorry i mean a gui video editor
[02:25:22 CEST] <furq> yes
[02:25:28 CEST] <Aerroon> thanks, then it's worth looking for
[02:26:56 CEST] <iive> furq: what is the name of that editor?
[02:28:12 CEST] <furq> openshot and shotcut are both built on top of libav*
[02:28:39 CEST] <iive> will try them out :D
[02:28:44 CEST] <iive> thanks
[02:29:01 CEST] <Aerroon> openshot crashed too much for me
[05:19:11 CEST] <kyleogrg> Is there a way, even if only in theory, to reduce the file size of a x264 stream without reencoding it?  I'm thinking of something like jpegtran for x264.
[05:26:48 CEST] <dystopia_> you could stip metadata
[05:26:56 CEST] <dystopia_> but that would only save you a few bytes
[05:27:10 CEST] <dystopia_> strip*
[07:59:32 CEST] <t3v4> Hi all, I need help with public metadata API within ffmpeg. Detailed problem is here https://stackoverflow.com/questions/45050177/adding-metadata-informations-with-ffmpeg. Problem is in write_header function, it produces SIGSEG. Can anyone tell me where I have mistake or to point me where to ask. Thanks!
[08:03:42 CEST] <c3r1c3-Win> Is there some place that I can look up what the AVERROR(AV_LOG_ERROR) numbers mean? (and actually all the various libav error codes?)
[08:04:30 CEST] <ggggle> http://paste.ubuntu.com/25116964/
[08:04:35 CEST] <ggggle> Original video "Duration: 00:00:21.02",but the output file only "Duration 00:00:00.03".  What args I need to add?
[08:18:07 CEST] <ggggle> .
[08:18:21 CEST] <ggggle>  
[08:19:00 CEST] Last message repeated 1 time(s).
[08:34:03 CEST] <t3v4>  Hi all, I need help with public metadata API within ffmpeg. Detailed problem is here https://stackoverflow.com/questions/45050177/adding-metadata-informations-with-ffmpeg. Problem is in write_header function, it produces SIGSEG. Can anyone tell me where I have mistake or to point me where to ask. Thanks!
[09:16:59 CEST] <t3v4> .
[09:17:00 CEST] Last message repeated 1 time(s).
[09:17:12 CEST] Last message repeated 1 time(s).
[09:17:12 CEST] <t3v4> Hi all, I need help with public metadata API within ffmpeg. Detailed problem is here https://stackoverflow.com/questions/45050177/adding-metadata-informations-with-ffmpeg. Problem is in write_header function, it produces SIGSEG. Can anyone tell me where I have mistake or to point me where to ask. Thanks!
[09:17:14 CEST] <t3v4> .
[09:18:00 CEST] Last message repeated 2 time(s).
[09:48:57 CEST] <Dazzle982> Hi, I'm trying to make an exact filesize xvid encode on ffmpeg via libxvid. Did pass1 and pass2, set bitrate with the -b:v 1500k parameter, but somehow the end result is much smaller then I gave avg bitrate for.
[09:49:46 CEST] <Dazzle982> Am I doing something wrong. Or is it true that libxvid does not really honor the bitrate given to it?
[11:18:18 CEST] <flux> when opening an H264 video track from an MPEG4 file the AVStream's codecpar.extradata fills up fine. but when I open a ra H264 stream, it doesn't (I suppose this is natural given the format is AvcDecoderConfigurationRecord from MPEG4). Now I understand I could parse the (beginning) of the H264 stream myself and get the contents, but is there some other way to make FFmpeg provide this data to me?
[11:24:55 CEST] <flux> hmm, for example, does the extradata get filled in if I actually read the stream.. ? my code isn't flexible enough to just try it out easily :)
[11:28:38 CEST] <LinuxLoader> some one with experience with high load GPU transcoder servers
[11:36:34 CEST] <Dazzle982> Hi, I'm trying to make an exact filesize xvid encode on ffmpeg via libxvid. Did pass1 and pass2, set bitrate with the -b:v 1500k parameter, but somehow the end result is much smaller then I gave avg bitrate for.
[11:36:47 CEST] <Dazzle982> Am I doing something wrong. Or is it true that libxvid does not really honor the bitrate given to it?
[11:39:15 CEST] <Fig1024> there should be a way to set minimum/maximum bitrate
[11:40:06 CEST] <Mavrik> Also most encoders won't fake data
[11:40:17 CEST] <Mavrik> So if there's not enough content to encode you're not getting bitrate
[11:40:45 CEST] <Fig1024> on C++ level you could just add padding
[11:41:30 CEST] <Mavrik> Yes, some formats allow adding padding
[11:41:32 CEST] <Mavrik> But that's silly
[11:42:19 CEST] <Dazzle982> Yea but with a relatively low bitrate as 1500 .. there should always be enough content right? I mean as long as it's not lossless.. there is always more bitrate to assign not?
[11:44:45 CEST] <Mavrik> \o/
[11:44:57 CEST] <Mavrik> No idea, libxvid is kinda really old and not used anymore :/
[11:45:44 CEST] <Dazzle982> there is something to say for that .. :P
[11:51:40 CEST] <n3wborn> Hi
[11:52:11 CEST] <n3wborn> what's the best way to just add a thumbnail to a mp3 ?
[11:58:02 CEST] <n3wborn> I find answers on the net but it only explain how to change from flac to mp3 and insert the cover for example. Not just add a thumbnail to an already reencoded file
[12:02:07 CEST] <n3wborn> I found the solution :) but thank you, I know you're here for "real" problems
[12:02:43 CEST] <Fig1024> you get what you pay for
[14:13:03 CEST] <winjer> I'm trying to split up an input file using timings from the blackdetect output. the black detection works great, but the output segments are not the same lengths as I'm specifying, and i really need them to be precise.  I'm calling ffmpeg like ffmpeg -i input.mxf -c:v h264_nvenc -vf format=yuv420p -acodec aac -map 0 -g 30 -sc_threshold 0 -force_key_frames
[14:13:08 CEST] <winjer> 30.03,35.035,45.045,50.2836,514.314,525.125,782.115,793.059,815.014,825.158,1151.22,1162.03,1423.02,1433.06 -f segment -segment_times 30.03,35.035,45.045,50.2836,514.314,525.125,782.115,793.059,815.014,825.158,1151.22,1162.03,1423.02,1433.06 -segment_time_delta 0.05 -reset_timestamps 1 -y out.part%03d.mp4
[14:13:14 CEST] <winjer> anyone able to point me in the right direction?
[14:45:09 CEST] <winjer> looks like ordering of arguments on the command line has some effect
[14:45:49 CEST] <klaxa> it has
[14:46:07 CEST] <klaxa> ffmpeg [input options] -i <input> [output options] <output>
[14:46:31 CEST] <winjer> moving force_key_frames to after segment_times seems to have sorted it?
[14:46:42 CEST] Action: winjer tests with a load more files
[14:59:48 CEST] <ayum> Hi, I have a question about quick sync performance, I can encoding 8 1080P/30FPS live channels by using the h264_qsv encoder, I think it's very good, but I am plan to encoding maximum 8 1080P/60FPS live channels, is it possible? please give me some idea how to optimize the speed if possible. thanks in advance
[15:05:58 CEST] <jkqxz> ayum:  Should be achievable on GT4 and maybe GT3; probably not possible on GT2.
[15:07:54 CEST] <jkqxz> ayum:  The encoder speed is mainly dependent on where the frames come from (preferably they are already in GPU memory) and the rate control mode (CBR or CQP are fastest, anything with lookahead is slower).
[15:09:22 CEST] <ayum> the frame is come from capture card, so I think it's in system memory. also, I used 2 memory card, to prevent memory performance bottleneck
[15:10:26 CEST] <ayum> when I testing, I usemetrics_monitor to check the GPU usage, I found the RENDER is almost used 100%, but VIDEO only used 60~70%. is this normal?
[15:11:23 CEST] <ayum> if I can decrease the RENDER usage, maybe it will faster. how do you think?
[15:15:09 CEST] <jkqxz> I think that's normal, though it can vary by options.  Encode has to use a lot of render resource (for ME and mode decision); video resource is for the bitstream parts.
[15:16:20 CEST] <jkqxz> What chip are you using?
[15:18:45 CEST] <ayum> after I changed to use the CBR mode, actually it faster than previous test. I can run 8 1080P/40FPS live channels
[15:19:18 CEST] <ayum> skylake i3-6100 + ASUS B150 motherboard
[15:20:36 CEST] <ayum> for use quick sync encoding, is i7 faster than i3? I think i7's GPU is more powerful than i3.
[15:21:10 CEST] <BtbN> The CPU is not involved with hardware encoding at all
[15:21:22 CEST] <BtbN> I think all their GPUs have the same encoder
[15:21:28 CEST] <BtbN> within the same generation
[15:23:44 CEST] <ayum> I think so, the GPU is same
[15:32:02 CEST] <jkqxz> The CPU branding doesn't make any difference.  But, that's a GT2 (usually "HD graphics" branding).  You probably won't be able to get 8x1080p60 without at least a GT3 ("Iris" branding).
[15:39:03 CEST] <jkqxz> The 6100 does have a slightly slower GPU than some of the other desktop models (e.g. 6300 or 6600), but that would only get you another 10%.
[15:40:43 CEST] <ayum> I think Xeon E3 v5 is powerful than i3-6100, because it has a Iris graphical card
[15:41:49 CEST] <jkqxz> The 15xx SKUs, yes.  (12xx SKUs are the same as the desktop Core i parts.)
[15:44:34 CEST] <ayum> I just checked some introduction about the Xeon E3 v5 CPU, it can handle up to 15 real-time 1080P/30FPS channels
[16:25:19 CEST] <leif> Does anyone know what compiler was used to make the windows builds of ffmpeg here: https://ffmpeg.zeranoe.com/builds/
[16:25:36 CEST] <leif> ? I assume not, but worth asking anyway.
[16:26:08 CEST] <leif> (I'm trying to ask so that I can find the correct version of the redistributable VC++ library.
[16:27:31 CEST] <kepstin> leif: there's a readme linked from that page which says
[16:27:56 CEST] <kepstin> It's built with GCC from MinGW-w64
[16:28:31 CEST] <leif> kepstin: Oh, woops. I thought that was just the ffmpeg readme. Thanks. :)
[16:37:12 CEST] <leif> kepstin: Hmm...the readme says they were build with mingw-w64. Doesn't that lack the requirement for the VC++ redistributables?
[16:43:03 CEST] <kepstin> yeah, you shouldn't need a VC++ redistributable for that.
[16:43:33 CEST] <kepstin> (I think it uses the c++ runtime from gcc, statically linked, and the CRT in windows)
[16:50:19 CEST] <leif> Interesting. http://i.imgur.com/QcJ2Oh6.png
[16:50:56 CEST] <leif> It 'seems' to want to link to those libs. Maybe gcc has its own C++ runtime that is not included.
[16:54:01 CEST] <kepstin> the binary downloads from zeranoe work fine without having to install any other libraries, so that doesn't seem to be the case?
[16:54:11 CEST] <kepstin> maybe you need it when linking tho
[16:55:37 CEST] <leif> Ya, that would make sense.
[16:55:47 CEST] <leif> Because I can absolutely use the executables.
[16:56:22 CEST] <leif> But maybe those executables aren't using those DLLs, and are just using staticaly linked builds.
[16:56:30 CEST] <leif> Just a guess anyway. I will investigate it more.
[16:56:37 CEST] <leif> Thanks again for the help.
[17:22:38 CEST] <c7j8d9> I have a 4k 10bit hevc hdr movie. My tv seems to only play x264 4k or VP9 not hevc. Is 10bit hdr possible with H.264 if I convert it myself?
[17:28:54 CEST] <iive> c7j8d9: yes, x264 supports 10bit sample encoding, just make sure you have a version that supports it. (it could be built without it).
[17:29:46 CEST] <c7j8d9> does chroma sampling have to do with hdr too? 4:2:0 vs 4:4:4?
[17:32:09 CEST] <iive> no. chroma sampling means the chroma (color) planes are at smaller resolution (420->1/2*1/2 ; 422->1/2 ; 444 ->1)
[17:32:44 CEST] <c7j8d9> thanks iive
[17:35:26 CEST] <fberg> hello guys. I have a question about rtsp output: is there any way to set max udp packet length when rtsp is involved (recompiling is also an option, with some hints)? I had success with raw udp and rtp also but I found no way with rtsp. Thank you
[17:42:02 CEST] <c7j8d9> is it possible to doctor mediainfo? I have a 4k movie that plays on my tv which the info say hevc but seems that it is an x264 in actuality.
[17:43:22 CEST] <iive> c7j8d9: what does ffprobe say about it?
[17:43:48 CEST] <c7j8d9> hadn't tried it let me give it a shot. thanks
[17:44:08 CEST] <iive> use pastebin site :D
[17:44:25 CEST] <iive> if you paste more than 1 line
[17:52:03 CEST] <furq> c7j8d9: i would be very surprised if your tv plays x264 hi10p and not hevc main10
[17:52:13 CEST] <furq> hardware support for the former is basically nonexistent
[17:52:32 CEST] <furq> s/x264/h264/
[17:55:25 CEST] <c7j8d9> it could be just a 4k x264 8bit thats playing I was hoping to convert the rest of my 4k movies which 2 are 10bit hdr hevc. I haven't tried H.264 10bit yet so it sounds like I would be wasting my time
[17:58:49 CEST] <c7j8d9> the movie that works on my tv ffprobe says hevc but I can't get any other hevc to play. I found the same movie who's file size was the same which is an x264 that plays the same so I was thinking maybe the first movie was actually x264. Sorry to be so convoluted.
[18:00:26 CEST] <c7j8d9> is it possible my tv doesn't like H.265 but plays x265?
[18:00:52 CEST] <kepstin> x265 is an H.265 encoder, that sentence doesn't make sense.
[18:01:26 CEST] <c7j8d9> sorry. I thought it meant hardware
[18:01:51 CEST] <c7j8d9> can my tv reject hardware encoded hevc as opposed to software encoded?
[18:02:25 CEST] <kepstin> c7j8d9: if they're encoded to different profiles, possibly, but it seems unlikely.
[18:05:42 CEST] <kerio> if anything i'd expect the opposite to be the case
[18:05:54 CEST] <gtt> hello my fellow encoders
[18:07:23 CEST] <kyleogrg> Veteran x264 users, please tell me which settings actually matter and which ones you commonly use.  For instance, I am usually doing something like this for high-res: -preset veryslow -crf 18 -tune film -pix_fmt yuv420p -profile:v main -level 5.0.  I also like to do 10-bit to reduce banding.
[18:08:37 CEST] <furq> get rid of the last two options unless you're specifically trying to restrict the output to main at 5.0
[18:08:49 CEST] <gtt> I have a VOB file of my sister parachuting, cool stuff, but the thing is 390MB and I need to convert it to another format (ideally mp4) while attaining some very decent compression. I already tried `cat vid.VOB | ffmpeg -i - outfile.mp4` and this achieved some decent compression, it brought it down to 290MB which is nice, but I guess more can be done
[18:09:26 CEST] <furq> another new entry for my "redundant use of cat" list
[18:09:28 CEST] <furq> this one's going in near the top
[18:09:36 CEST] <kyleogrg> furq: well, i looked up the highest level which supports my resolution.  is that a bad idea?  is ffmpeg's default always correct?
[18:09:37 CEST] <gtt> for instance I assume the conversion maintained the resolution the same, but aside from downgrading on the resolution, what else can be done?
[18:09:55 CEST] <furq> gtt: do you have a build with libx264
[18:10:09 CEST] <furq> i'd expect the default settings for mp4 to compress it better than that
[18:10:13 CEST] <furq> it depends a lot on the source though
[18:10:21 CEST] <gtt> furq: I don't know mate, how can I test whether it does?
[18:10:35 CEST] <gtt> I just installed the default ffmpeg package for archlinux
[18:10:45 CEST] <furq> ffmpeg -version | grep -o ...able-libx264
[18:10:46 CEST] <iive> gtt: ffmpeg should be able to read mpeg-ps directly, and .vob is just that. so don't `cat` it
[18:11:09 CEST] <gtt> ok
[18:11:12 CEST] <furq> or just ffmpeg -codecs | grep x264
[18:11:49 CEST] <furq> kyleogrg: -profile and -level are only useful if you want ffmpeg to restrict the output to a certain level
[18:11:49 CEST] <iive> ir -encoders :D
[18:11:59 CEST] <furq> otherwise it'll autoselect the correct profile and level
[18:12:11 CEST] <gtt> furq: it is compiled with enable-libx264
[18:12:48 CEST] <kyleogrg> furq: aren't there multiple levels which accommodate a given resolution?  how can i choose, and how does ffmpeg know the correct one?
[18:13:08 CEST] <furq> kyleogrg: you don't choose unless you have a tv or phone or something which only plays a certain level/preset
[18:13:46 CEST] <kyleogrg> okay
[18:13:53 CEST] <furq> libx264 will automatically select the lowest valid level and preset
[18:14:23 CEST] <kyleogrg> is there any advantage to selecting the highest valid level/profile?
[18:14:25 CEST] <furq> no
[18:14:49 CEST] <furq> by "lowest valid" i mean to accommodate the resolution, settings you've picked etc
[18:14:52 CEST] <kyleogrg> sure
[18:15:12 CEST] <furq> if you force a lower profile or level then it'll disable certain settings
[18:15:32 CEST] <kyleogrg> do you usually use profile and tune presets, or do you customize further?
[18:15:47 CEST] <furq> gtt: if this is a vob then i'm guessing it's a dvd that was originally a videocamera
[18:15:51 CEST] <furq> so i'm guessing it's noisy and interlaced
[18:16:01 CEST] <furq> kyleogrg: i never touch profile or level because i have no devices that need it
[18:16:06 CEST] <furq> i always use preset and often use tune
[18:16:17 CEST] <furq> and it's very rare i fuck with anything beyond that
[18:16:30 CEST] <kyleogrg> furq: oh yeah, i meant preset and tune
[18:17:11 CEST] <kyleogrg> i'd like to be more familiar with the under-the-hood settings tho
[18:17:21 CEST] <kyleogrg> i guess i just need to start experimenting
[18:18:13 CEST] <furq> if you're happy to use -preset veryslow then there's nothing else worth touching really
[18:18:40 CEST] <furq> i know there are crazy people out there who are Very Serious about tweaking psy and aq and shit so it's Just Right
[18:18:57 CEST] <furq> i always thought that was a waste of time
[18:18:59 CEST] <kyleogrg> yeah... diminishing returns i guess
[18:19:14 CEST] <furq> preset and tune gets you 99% of the way there
[18:19:23 CEST] <kyleogrg> any benefit to using placebo?
[18:19:26 CEST] <furq> nope
[18:19:28 CEST] <furq> hence the name
[18:19:31 CEST] <kyleogrg> i guess the name speaks for itself
[18:19:32 CEST] <kyleogrg> yeah
[18:19:38 CEST] <furq> i mean it might be marginally more efficient
[18:19:43 CEST] <furq> but it turns literally everything up to max
[18:19:49 CEST] <kyleogrg> sure, if i have lots of extra time
[18:19:51 CEST] <furq> so it takes massively longer than veryslow
[18:19:57 CEST] <furq> for basically no benefit
[18:20:37 CEST] <kyleogrg> ok, what's a visually lossless crf for UHD video in your opinion?
[18:20:55 CEST] <kyleogrg> like 2k to 4k?
[18:24:18 CEST] <furq> i normally use 21 for 1080p
[18:24:24 CEST] <furq> you could probably go to 22 for 4k
[18:24:25 CEST] <Blubberbub> is there a way for a demuxer/AVInputFormat to determine the delay between demuxing and output/playback?
[18:25:18 CEST] <kepstin> Blubberbub: maybe start by telling us why you think a demuxer might want that information?
[18:27:36 CEST] <kepstin> the answer to the question you asked is of course "no", but if you clarify why you want that maybe we can figure out a way to resolve the problem.
[18:28:38 CEST] <Blubberbub> yea, i guessed that its not possible. I wan't to write a demuxer that concatenates files, but decides which file to concat based on the time of day, so to determine which file to load next i would need to know when its going to be played
[18:29:44 CEST] <kepstin> Blubberbub: rather than writing a demuxer within ffmpeg, you should be writing an application that uses ffmpeg apis.
[18:30:17 CEST] <Blubberbub> yea, but that would mean basically rewriting ffplay...
[18:30:22 CEST] <Blubberbub> and i try to avoid that
[18:30:27 CEST] <furq> not really
[18:30:36 CEST] <furq> it means writing an application which outputs rawvideo that you pipe to ffplay
[18:31:06 CEST] <kepstin> Blubberbub: if your input files are concatenatable (e.g. mpeg-ts) you don't even to use ffmpeg apis in your application, it can just do basic file io :/
[18:31:10 CEST] <furq> or failing that you could use something like libmpv
[18:31:38 CEST] <Blubberbub> shell-piping is a bad idea, because the buffer-size in the shell-pipe is one more unknown variable, right?
[18:32:00 CEST] <Blubberbub> well - i need demux/decode the files before concat as well
[18:32:08 CEST] <Blubberbub> and i want to use filters
[18:34:28 CEST] <Blubberbub> i only need audio, though...
[18:36:39 CEST] <kepstin> unless you really need subsecond accuracy, you shouldn't have an issue with piping stuff, particularly if it's just audio.
[18:37:49 CEST] <Blubberbub> i probably could also just ignore the delay introduced by filter & playback buffer.
[18:39:47 CEST] <furq> i'm pretty sure there's an fcntl for pipe size on linux now
[18:41:50 CEST] <utack> damn, is there a 32bit limited bmp in the chain? "[png @ 0x56537e4c5b40] [IMGUTILS @ 0x7f44ff7a7c60] Picture size 39936x23296 is invalid"
[18:43:24 CEST] <utack> seems like yes https://video.stackexchange.com/questions/21000/largest-input-image-size-when-encoding-a-video
[18:45:49 CEST] <Blubberbub> the problem i'm running into is basically the missing support for dynamic input files for filter graphs, because a lot of filters depend on EOF. Ideally i want to have an infinite list of inputs generated by a script and each file is individually filtered(volume+silenceremove+...) and then crossfaded and the resulting stream filtered again before outputting.
[18:48:08 CEST] <Blubberbub> ^- but that is of course just a very long version of the "it appears i need to write code myself to solve my very specific problem"-complain :D
[18:52:20 CEST] <Blubberbub> and i have no good idea on how to really solve the problem, that you can only filter a finite amount of files, which i'd think is useful for more people than just me - but i might be wrong about that
[19:18:16 CEST] <kepstin> utack: ffmpeg internally has some limits on the max size (bytes) it will allocate for a single frame
[19:18:47 CEST] <kepstin> ah, yeah, that link shows the limits
[19:19:28 CEST] Action: kepstin notes that 'int' on 64bit linux is still a 32bit type
[19:21:04 CEST] <utack> seems like it
[19:22:31 CEST] <__jack__> is that specific to Linux ? it seems that C allows a 64b int, that is not a good idea
[19:23:19 CEST] <kepstin> when 64bit x86 abis were being decided back in the day, the linux devs decided to make int 32bit and long 64bit.
[19:23:20 CEST] <__jack__> according to wikipedia, C says "int == at least 16 bits", thus you should never store more than 16 bits inside an int
[19:24:01 CEST] <kepstin> and so that's how it is, can't be changed now without making everything binary-incompatible
[19:24:58 CEST] <leif> Is there any reason that lib avformat-57.dll would not have the symbol av_packet_unref?
[19:25:21 CEST] <leif> (I thought, probably incorrectly, that the ABI stayed the same across major versions like that>0
[19:25:23 CEST] <leif> ) *
[19:25:37 CEST] <leif> Although perhaps I am missunderstanding the ffmpeg version scheme?
[19:25:50 CEST] <kepstin> leif: yeah, it's in libavcodec not libavformat.
[19:26:14 CEST] <leif> kepstin: WOW
[19:26:16 CEST] <leif> okay
[19:26:37 CEST] <leif> The next question....do you have any idea why some copies of libavformat.dylib 'would' have av_packet_unref?
[19:26:47 CEST] <leif> (That one could just be me compiling it wrong somehow.)
[19:27:32 CEST] <kepstin> leif: no idea, but there are functions in libavformat which call that av_packet_unref, which means that libavformat has to link to libavcodec, and depending on the system that might make the function visible
[19:27:59 CEST] <leif> Oh, okay. Actually, that makes a lot of sense.
[19:30:41 CEST] <leif> Yup, that was exactly the case. Good catch, thanks.
[20:04:49 CEST] <lindylex> HOw do I preserve the audio and have it play in both videos if I have them playing side by side with the following?  ffmpeg -i left.mov -i my.mov -filter_complex "[0:v]setpts=PTS-STARTPTS, pad=iw*2:ih[bg]; [1:v]setpts=PTS-STARTPTS[fg]; [bg][fg]overlay=w" -y side.mov
[20:06:01 CEST] <klaxa> you mean keep both audio streams and mix them into one?
[20:06:18 CEST] <lindylex> Yes
[20:06:20 CEST] <klaxa> https://ffmpeg.org/ffmpeg-filters.html#amix
[20:14:06 CEST] <kyleogrg> Easiest way to pause, close, open, and resume ffmpeg encoding?
[20:16:15 CEST] <relaxed> screen, ctrl-z, and fg
[20:18:12 CEST] <kyleogrg> what do you mean?
[20:18:39 CEST] <klaxa> if you press ctrl-z in a shell, it usually pauses the process in the foreground
[20:18:48 CEST] <klaxa> with fg you can continue it in the foreground
[20:19:24 CEST] <kyleogrg> hmm, i'm talking about being able to restart your machine and resume encoding
[20:19:47 CEST] <relaxed> nope
[20:20:09 CEST] <jkqxz> Run in a VM.
[20:20:16 CEST] <kyleogrg> yeah
[20:21:06 CEST] <kyleogrg> do you think ffmpeg should have this feature? it seems somewhat basic
[20:40:20 CEST] <CounterPillow> that would be incredibly dependant on encoder and container
[20:41:24 CEST] <kyleogrg> well, if i put it in a VM and paused the VM, obviously that would work.  so is there a way to sandbox one program in windows and pause it?
[20:43:15 CEST] <klaxa> if you really need to be able to stop encodes, maybe it would be easiest to split your input by gops and encode one gop after another, then you can stop after each gop and once all are done you can concat them again
[20:43:16 CEST] <relaxed> if using a VM works, why not just do that?
[20:43:53 CEST] <kyleogrg> relaxed: sure, actually i've been doing that lately with lubuntu.  just exploring all the options.
[20:44:26 CEST] <kyleogrg> klaxa: yeah, how can you split an input file by gop?
[20:45:25 CEST] <kyleogrg> klaxa: also, can i concat x264 sections?
[20:45:45 CEST] <klaxa> https://github.com/klaxa/Distributed-encoding/blob/master/server.py#L75
[20:45:52 CEST] <klaxa> this function does exactly that
[20:46:01 CEST] <klaxa> it just calls mkvmerge
[20:46:14 CEST] <kyleogrg> ah, interesting
[20:47:43 CEST] <klaxa> don't pay attention to the poor code quality :P
[20:48:08 CEST] <kyleogrg> haha, well i don't even know python
[20:48:37 CEST] <kyleogrg> now why split by gop?  why not just make 30 second chunks or something like that?
[20:48:55 CEST] <CounterPillow> because that's not how video codecs work
[20:49:10 CEST] <klaxa> you can do that too, but splitting by gop preserves keyframes
[20:49:28 CEST] <klaxa> also you can't actually split at non-keyframes
[20:49:32 CEST] <kyleogrg> ahh, yeah, unless i'm actually reencoding those chunks, not stream copying
[20:49:36 CEST] <klaxa> basically what CounterPillow said
[20:50:32 CEST] <kyleogrg> so i guess i'd segment the input x264/mp4 file to a bunch of ".264" chunks, like myvideo_seg1.264
[20:50:39 CEST] <kyleogrg> then concat
[20:51:28 CEST] <klaxa> yeah maybe use a container (i.e. mp4 or mkv) instead of raw h264
[20:51:34 CEST] <klaxa> makes file handling easier
[20:52:37 CEST] <kyleogrg> i guess segmenting before encoding won't make much of a practical difference on the output file quality/size?  i mean versus encoding the whole file at once?
[20:53:04 CEST] <kyleogrg> because the encoder can only look at what's in the segment
[20:53:44 CEST] <klaxa> i highly doubt it has a huge impact but i have no data to back that up
[20:53:49 CEST] <klaxa> maybe run a test or two
[20:53:55 CEST] <kyleogrg> sure
[20:57:26 CEST] <c_14> If the input gops you split are the same length as the output gops (in general) there shouldn't be a difference
[20:57:34 CEST] <c_14> since a frame can't reference anything outside the gop
[20:57:49 CEST] <kyleogrg> yeah.  so how would i know that?
[20:58:09 CEST] <kyleogrg> i usually just use preset/tune
[20:58:17 CEST] <kyleogrg> and crf
[21:01:03 CEST] <c_14> I'm not sure what the default gop length is. I think 150?
[21:01:44 CEST] <kyleogrg> i guess if i wanted to be picky, i could get the input file's gop from ffmpeg and then set the output settings to the same
[21:01:45 CEST] <c_14> But even then it could be marginally larger if the encoder decides to add a keyframe somewhere in the middle due to a scene change that wasn't there in the original and then the cut ends and the next cut starts with a keyframe again
[21:03:19 CEST] <kyleogrg> huhhh... is there a way to do a fast-pass gop split?  like splitting the input file based on where the x264 wants to put the gops?
[21:03:40 CEST] <c_14> don't think so
[21:04:06 CEST] <c_14> you could maybe do a first-pass and then manually parse the progress file (though who knows what the format is)
[21:05:25 CEST] <kyleogrg> or maybe a way to split the input file based on "scenes"?  then at least the x264 encoder is unlikely to suffer from oddly-places cuts, right?
[21:09:43 CEST] <c_14> the select filter can select frames at scene changes, but since it can't create the cuts or output timestamps it's not really helpful
[21:10:49 CEST] <kyleogrg> i guess it depends on the amount of effort you're willing to put into it.  maybe if i did a few steps, or did a lot of output info parsing, i could get the necessary info
[21:12:59 CEST] <kyleogrg> supposing i had a text file of all the scene changes, i guess i could make a script that tells ffmpeg to encode each chunk (if it doesn't yet exist).  i just need ffmpeg to be able to start at a frame-exact location
[21:13:31 CEST] <klaxa> -ss and -t
[21:13:33 CEST] <klaxa> are your friend
[21:13:40 CEST] <c_14> ffmpeg's -ss is frame-exact in recentish versions of ffmpeg
[21:14:05 CEST] <c_14> (on a timestamp level, but not on a framecount level)
[21:14:11 CEST] <c_14> So you'll need timestamps not frame numbers
[21:14:21 CEST] <kyleogrg> hmm, what's the difference if it's exact both ways?
[21:14:25 CEST] <kyleogrg> oh
[21:14:32 CEST] <kyleogrg> i just need it to be formatted like a timestamp?
[21:14:55 CEST] <c_14> You can't tell ffmpeg to seek to the nth frame, but you can tell it to seek to the frame at the instant XX:YY:ZZ.XYZ or whatever
[21:15:00 CEST] <kyleogrg> yeah
[21:15:34 CEST] <kyleogrg> ok, now i thought it made a difference whether -ss and -t were before or after -i
[21:15:35 CEST] <kyleogrg> true?
[21:15:44 CEST] <c_14> not anymore
[21:15:49 CEST] <c_14> it's just a speed difference
[21:15:58 CEST] <kyleogrg> how so?
[21:15:59 CEST] <c_14> (before is faster)
[21:16:08 CEST] <kyleogrg> why?
[21:16:10 CEST] <c_14> because using -ss before doesn't decode everything up to that point, after does
[21:16:22 CEST] <kyleogrg> ah. so why ever use the slower method?
[21:16:51 CEST] <c_14> if you have multiple outputs with different seek offsets
[21:17:04 CEST] <c_14> There's also mild differences if you're trying to overlay subtitles
[21:17:09 CEST] <kyleogrg> ok
[21:17:12 CEST] <c_14> (if you don't use -copyts)
[21:18:14 CEST] <kyleogrg> i'm kind of paranoid that it can't be exact without decoding
[21:18:35 CEST] <klaxa> <klaxa> maybe run a test or two
[21:21:16 CEST] <kyleogrg> maybe i will do some test
[21:21:47 CEST] <furq> you probably want -f segment -segment times
[21:21:56 CEST] <furq> although i don't really know why you want to do this in the first place
[21:22:08 CEST] <klaxa> to reboot in the middle of an encode
[21:22:19 CEST] <kyleogrg> that's what started my thought process, yes
[21:22:47 CEST] <kyleogrg> which led me to think of what's the ideal way to split up an input file for encoding
[21:23:12 CEST] <kyleogrg> doesn't -f segment -segment give me gop times?
[21:23:30 CEST] <furq> it would if this file was already encoded with x264
[21:23:43 CEST] <furq> that would split by gop in the appropriate places
[21:23:56 CEST] <furq> but if it's any other codec then the gops will probably be different than what x264 would select
[21:23:57 CEST] <kyleogrg> ok, what about vp9?
[21:24:01 CEST] <kyleogrg> yeah
[21:24:02 CEST] <furq> shrug
[21:24:07 CEST] <furq> idk about modern codecs
[21:24:08 CEST] <kyleogrg> makes sense
[21:24:11 CEST] <furq> it'll definitely be wrong for mpeg2video
[21:24:19 CEST] <furq> which is usually what i'm encoding to x264
[22:15:16 CEST] <dynek> hello
[22:15:44 CEST] <dynek> not sure it's worth asking without the full command line but I'm trying to read an h264 stream from a network camera and restream it using hls, but ffmpeg keeps saying:
[22:15:55 CEST] <dynek> H.264 bitstream malformed, no startcode found, use the video bitstream filter 'h264_mp4toannexb' to fix it ('-bsf:v h264_mp4toannexb' option with ffmpeg)
[22:16:01 CEST] <dynek> even though I add -bsf:v h264_mp4toannexb
[22:16:16 CEST] <dynek> that's ffmpeg 3.2.5-1
[22:30:37 CEST] <dynek> oh well I gave up on va-api that was causing this problem
[22:32:21 CEST] <kepstin> kyleogrg: if you just want to encode stuff in smaller granularities so you can reboot part way through, no reason to try to match gop size, you could just split into fairly large chunks, like 5-10 minutes long each
[22:33:22 CEST] <kyleogrg> yeah... i thought of that
[22:33:46 CEST] <kyleogrg> that is a simpler solution too
[22:53:50 CEST] <kepstin> (note that i'd recommend encoding the entire audio track as a separate step, rather than in chunks, because concatenating audio is ... strange)
[23:05:47 CEST] <kyleogrg> kepstin: yeah haha, i was going to simply stream copy the audio later or encode the entire track separately
[23:17:25 CEST] <jcarpenter2> oi, i'm having a bit of trouble linking against libavcodec - can anybody lend me their eye? https://stackoverflow.com/questions/45177212/linking-with-libavcodec-still-seeing-undefined-references
[23:20:04 CEST] <drv> jcarpenter2: are you including the headers inside extern "C"?
[23:20:12 CEST] <atomnuker> jcarpenter2: you still need to link to libavutil and libavformat
[23:20:40 CEST] <jcarpenter2> drv: what do you mean?
[23:20:51 CEST] <jcarpenter2> atomnuker: added -lavutil -lavformat, no dice
[23:21:01 CEST] <jcarpenter2> (same error)
[23:23:05 CEST] <drv> extern "C" { #include <libavcodec/avcodec.h> } (with line breaks around the #include)
[23:23:49 CEST] <jcarpenter2> drv: thanks, that's the answer
[23:24:37 CEST] <kepstin> jcarpenter2: if you don't do that, the compiler assumes they're C++ function names and applies mangling (modifying the function name to include type names), and then they don't match up with the C function names.
[23:40:15 CEST] <jcarpenter2> avcodec_find_decoder(AV_CODEC_ID_MP2) is returning null, is that normal?
[23:41:26 CEST] <pgorley> jcarpenter2: is the codec registered?
[23:41:38 CEST] <JEEB> then that decoder is not registered (you usually want to do av_register_all)
[23:43:41 CEST] <jcarpenter2> ah yes, thanks
[23:44:31 CEST] <pgorley> vp8_mediacodec always returns "Unsupported or unknown profile" during initialization, but it still tries to decode, resulting a black screen
[23:44:38 CEST] <pgorley> any ideas on how to fix this?
[23:45:26 CEST] <JEEB> pgorley: hmm that one I haven't actually tried
[23:45:46 CEST] <pgorley> looking at the code, it seems that vp8_mediacodec isn't fully implemented
[23:45:48 CEST] <JEEB> I've tried that the fallback works with H.264 (10bit) and HEVC
[23:46:24 CEST] <pgorley> the call to ff_AMediaCodecProfile_getProfileFromAVCodecContext only returns positive values if using h264 or hevc
[23:50:58 CEST] <jkqxz> It would make sense for VP8 to do nothing there, because it doesn't have meaningful profiles.
[23:51:05 CEST] <jkqxz> But yeah, ret is clearly -1 in that case...
[23:51:55 CEST] <pgorley> so that wouldn't (shouldn't) be the problem i'm having?
[23:52:27 CEST] <jkqxz> Don't think so, it's just a warning.
[23:53:31 CEST] <jkqxz> Passing the -1 to the following function makes it always return the first profile it finds, which makes sense.
[23:54:12 CEST] <pgorley> ah, ffmpeg does eventually print "MediaCodec started successfully, ret = 0"
[23:56:46 CEST] <pgorley> i'm guessing the error comes from this line then: D/ACodec: [OMX.MTK.VIDEO.DECODER.VPX] onInputBufferFilled ID 3 w/ time -7301425711502320997 eos 1 mode 1 err -1011
[00:00:00 CEST] --- Wed Jul 19 2017