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

[burek]

[01:16:47 CET] <Cust0sLimen> hi
[01:17:06 CET] <Cust0sLimen> I'm trying to change 1080p to 720p
[01:17:41 CET] <Cust0sLimen> so I'm using ffmpeg -i infile.mp4 -ss 02:18:15 -to 02:18:20 -vf scale=1280:720 -preset veryfast outfile.mp4
[01:17:50 CET] <Cust0sLimen> but this is taking forever to even start it seems
[01:18:43 CET] <kepstin> Cust0sLimen: using -ss after the filename is very slow, since it decodes up to that point and then throws away the video
[01:18:53 CET] <yumbox> try ffmpeg -ss ... -i ...
[01:18:58 CET] <Cust0sLimen> ah ok
[01:19:07 CET] <yumbox> oh, kepstin already said it
[01:19:11 CET] <kepstin> Cust0sLimen: try this command instead: "ffmpeg -ss 02:18:05 -i infile.mp4 -t 5 -to 02:18:20 -vf scale=1280:720 -preset veryfast outfile.mp4"
[01:19:29 CET] <kepstin> note that -to will behave differently if you move the -ss option, because of how ffmpeg processes timestamps
[01:19:34 CET] <yumbox> isn't -t and -to redundant?
[01:19:40 CET] <kepstin> er, whoops
[01:19:43 CET] <kepstin> i typoed that :)
[01:19:53 CET] <kepstin> "ffmpeg -ss 02:18:05 -i infile.mp4 -t 5 -vf scale=1280:720 -preset veryfast outfile.mp4"
[01:20:14 CET] <yumbox> also, -ss before -i makes it less accurate. it could be that it starts at a different time than you want
[01:20:18 CET] <Cust0sLimen> should I not use -t ?
[01:20:41 CET] <Cust0sLimen> should I not use -to I mean?
[01:20:52 CET] <yumbox> you can use either, but not both
[01:20:59 CET] <kepstin> yumbox: using -ss before -i is the same accuracy for files with index. ffmpeg does frame accurate seeking.
[01:21:08 CET] <Cust0sLimen> ah ok thanks
[01:21:12 CET] <Cust0sLimen> that is much faster yes
[01:21:26 CET] <yumbox> kepstin: my experience has been different
[01:21:46 CET] <Cust0sLimen> hmm to is not working now
[01:22:01 CET] <kepstin> Cust0sLimen: like I said, ffmpeg handles timestamps differently when using -ss before -i
[01:22:07 CET] <Cust0sLimen> ok
[01:22:12 CET] <kepstin> Cust0sLimen: it sets the time that you seeked to as '0'
[01:22:12 CET] <Cust0sLimen> -t works but -to not
[01:22:16 CET] <Cust0sLimen> I see
[01:22:29 CET] <Cust0sLimen> can I put -to also before -i ? ;)
[01:22:39 CET] <kepstin> Cust0sLimen: nope, that won't work at all :)
[01:22:46 CET] <Cust0sLimen> megh
[01:23:04 CET] <Cust0sLimen> is there some easy calculator for timestamps?
[01:23:14 CET] <Cust0sLimen> like to 02:19:43 - 02:18:15 ?
[01:23:19 CET] <kepstin> yumbox: if you have a specific example of a file where -ss before -i doesn't accurately seek, that might be a bug& (unless it's something like mpeg-ts with no index)
[01:23:23 CET] <yumbox> kepstin: what files typically contain indices?
[01:24:15 CET] <kepstin> Cust0sLimen: hmm. You know what, here's something that might be worth a try:
[01:24:29 CET] <yumbox> kepstin: it was an mp4 from a screen capture program, and it was off by quite a few seconds
[01:24:39 CET] <kepstin> "ffmpeg -ss 02:18:15 -itsoffset 02:18:15 -i infile.mp4 -to 02:18:20 -vf scale=1280:720 -preset veryfast outfile.mp4"
[01:25:00 CET] <kepstin> Cust0sLimen: ^^ that undoes the reset-to-0 that ffmpeg normally does, so the -to should work in the same way as before
[01:25:20 CET] <Cust0sLimen> ah ok let me try thanks
[01:25:53 CET] <kepstin> yumbox: mp4 files normally contain an index, and seeking should be frame-accurate in them.
[01:26:17 CET] Action: kepstin notes that mp4 is a terrible format for a screen capture program, since an incompletely written mp4 file is unreadable
[01:27:12 CET] <yumbox> not if you put the mov at the start of the file
[01:27:19 CET] <yumbox> in the header, i think?
[01:28:46 CET] <kepstin> the moov contains the file index, so it can't be written until the rest of the file is written
[01:29:16 CET] <kepstin> which is why it's normally stored at the end
[01:29:33 CET] <Cust0sLimen> kepstin, now it is slow again
[01:29:36 CET] <Cust0sLimen> or doing nothing for long time
[01:29:58 CET] <yumbox> kepstin: hmm, okay. sorry for stating misinformation.
[01:30:03 CET] <kepstin> (applications that put it at the start, like ffmpeg with -movflags faststart, do so by doing a second pass after the file's been written to put it at the start)
[01:30:47 CET] <yumbox> what would be a good video format for a screen capture program then?
[01:30:57 CET] <yumbox> s/format/container
[01:31:52 CET] <kepstin> yumbox: hmm, almost anything else? mkv files can be written so they're playable when incomplete, that's not a bad option.
[01:32:07 CET] <kepstin> nut, hey even mpegts could work.
[01:33:17 CET] <kepstin> Cust0sLimen: hmm. yeah, I see that. I guess mp4 has issues with the timestamps like that.
[01:33:23 CET] <yumbox> do you think mkv is a good container?
[01:33:42 CET] <kepstin> Cust0sLimen: I guess just don't use -itsoffset, and calculate the end time yourself :/
[01:34:08 CET] <kepstin> yumbox: mkv is a reasonably decent container that supports a wide variety of codecs, and is supported by a lot of players.
[01:34:11 CET] <Cust0sLimen> yeah doing that
[01:34:59 CET] <yumbox> kepstin: any others like that?
[01:35:12 CET] <kepstin> yumbox: not really.
[01:35:32 CET] <yumbox> mp4, avi?
[01:35:45 CET] <iranen> webm?
[01:35:50 CET] <kepstin> mp4 has the problem with incomplete files, and avi is terrible for modern codecs
[01:35:52 CET] <Cust0sLimen> php has some function to convert string of any date/time format to timestamp/datetime
[01:36:01 CET] <Cust0sLimen> does python have something similar?
[01:36:05 CET] <Cust0sLimen> kinda guess format I guess
[01:36:07 CET] <kepstin> webm is actually just mkv except you're only allowed to use vp8/vp9/vorbis/opus
[01:36:11 CET] <Cust0sLimen> I want to use it for interactive only
[01:37:43 CET] <Cust0sLimen> nvm http://pypi.python.org/pypi/python-dateutil
[01:51:18 CET] <Cust0sLimen> what is some decent defaults for VP8 ?
[01:52:09 CET] <Cust0sLimen> -c:v libvpx -qmin 0 -qmax 50 -crf 5 -b:v 1M ?
[01:52:14 CET] <kepstin> use vp9 instead
[01:52:20 CET] <kepstin> it's better in every possible way
[01:52:38 CET] <Cust0sLimen> I need to upload to gfycat
[01:52:39 CET] <kepstin> (i mean, unless you need to support specific old devices that only do vp8)
[01:52:48 CET] <Cust0sLimen> and they say best for keeping quality when uploading there is to use vp8
[01:53:04 CET] <kepstin> that's kind of annyoing, i'd really hope they allow vp9
[01:56:19 CET] <kepstin> hmm. the only reference I can find mentioning vp8 is a third party post from a year ago
[01:56:32 CET] <kepstin> it's entirely possible they've switched to vp9 by now, but who knows
[01:57:30 CET] <kepstin> it looks like they don't have any real size limits on the upload and will be doing multi codec transcodes anyways, so I'd suggest just doing h264 video at high quality.
[01:57:36 CET] <yumbox> vp9 is way worse in one way: encoding takes forever
[01:57:53 CET] <Cust0sLimen> I want to convert aspect ratio from 16/9 to 4/3 during recoding
[01:57:56 CET] <Cust0sLimen> of 1080p
[01:58:02 CET] <Cust0sLimen> -vf scale=1440:1080
[01:58:10 CET] <kepstin> with the recent updates for multithreading, it's really not worse than vp8, the quality improvement's worth it
[01:58:27 CET] <kepstin> Cust0sLimen: do you want to squish the video or crop it?
[01:58:35 CET] <Cust0sLimen> squish it
[01:58:47 CET] <kepstin> -vf scale=1440:1080,setsar=1
[01:58:49 CET] <Cust0sLimen> horizontally
[01:59:12 CET] <Cust0sLimen> thanks
[02:00:25 CET] <yumbox> kepstin: how recent are those updates?
[02:00:54 CET] <kepstin> hmm, fall 2017 I think? I don't remember exactly.
[02:01:11 CET] <kepstin> you'd need to build a git snapshot, because they haven't made a release with it afaik
[02:01:23 CET] <yumbox> hmm.
[02:01:36 CET] <yumbox> would it help enough if you have a CPU with just 2 cores?
[02:02:04 CET] <kepstin> like most things, each additional core helps less than the previous
[02:02:12 CET] <kepstin> so the second core makes a big difference :)
[02:02:25 CET] Action: kepstin hasn't done any benchmarking or anything tho
[02:03:10 CET] <kepstin> I personally use a libvpx snapshot that just matches whatever google shipped in the most recent stable chrome, because that's probably a reasonably tested version :/
[02:03:23 CET] <yumbox> I mean, would 2 cores vp9 multithreaded encoding be comparable to vp8 encoding?
[02:03:56 CET] <kepstin> I don't know. feel free to test it yourself?
[02:04:12 CET] <Cust0sLimen> is there some options to make VP8 encoding go faster?
[02:04:18 CET] <Cust0sLimen> it is using 1 cpu only
[02:06:20 CET] <kepstin> Cust0sLimen: nope.
[02:07:11 CET] <kepstin> Cust0sLimen: vp9 might be faster - if you're using a recent libvpx snapshot and enable multithreading.
[02:07:37 CET] <kepstin> well, you can make vp8 faster, but it comes at expense of quality of course.
[02:08:36 CET] <kepstin> Cust0sLimen: you can try using the "-speed" option, it defaults to 1, higher numbers are less slow but also lower quality.
[02:09:45 CET] <Cust0sLimen> is there some way to see stream data for videos in chrome?
[02:09:53 CET] <Cust0sLimen> like I would see if I run mediainfo on terminal?
[02:13:08 CET] <Jhyra> Hi, I'm trying to stream to youtube my IP cam (that susing an RTSP stream on the local network), But i can't get past this error: https://pastebin.com/w6Cbe4AJ
[02:14:20 CET] <Cust0sLimen> man gfycat uses some insanely tuned parameters for encoding their VP8
[02:29:19 CET] <SortaCore> "-pix_fmt +"?
[02:29:56 CET] <SortaCore> also you specify the video codec twice, once as copy and once as libx264 (re-encode)
[02:30:09 CET] <SortaCore> ^ Jhyra
[02:31:13 CET] <Cust0sLimen> if I run ffmpeg -ss 02:18:15 -i input.mp4 -t 88 -vf scale=1440:1080,setsar=1 output.mp4 - what quality parameters will it use?
[02:31:34 CET] <Cust0sLimen> or rather let me ask this - how do I re-encode without loosing as little quality as possible?
[02:32:15 CET] <yumbox> losing*
[02:34:21 CET] <SortaCore> it should duplicate source
[02:34:33 CET] <SortaCore> you could check when it dumps information about the input and output formats, see if bitrate and such much
[02:35:01 CET] <Cust0sLimen> SortaCore, without -c copy I think it re-encodes
[02:35:14 CET] <SortaCore> it will, yeah, but it'll re-encode to the same settings as the source
[02:35:24 CET] <SortaCore> same tune, preset, profile, level, I think
[02:35:31 CET] <Cust0sLimen> ah I see
[02:35:36 CET] <Cust0sLimen> I thought so - thanks
[02:36:01 CET] <SortaCore> but I'm ffmpeg newbie, so I would just check what it prints to the console when you run it
[02:46:38 CET] <Jhyra> SortaCore: thanks! To stream only video, can I remove the -c:a aac?
[02:47:25 CET] <SortaCore> yes, but you should also add "-an" for no audio
[02:47:35 CET] <SortaCore> it might copy from source otherwise
[02:47:54 CET] <Jhyra> ok! Let's see how it's going
[02:49:11 CET] <Jhyra> https://pastebin.com/qiMQnxCc
[02:49:17 CET] <Jhyra> still the same error :/
[02:52:09 CET] <Jhyra> I can feed it an HLS stream or a MPEG-DASH one, in alternative
[03:02:59 CET] <SortaCore> it can't recognise the input codec type
[03:03:50 CET] <Jhyra> ye, I solved it switching to the HLS stream
[03:04:15 CET] <Jhyra> and now i got a nice: "non-existing PPS0"
[03:04:59 CET] <Jhyra> ok, maybe I fix... aaaand nope
[03:05:47 CET] <SortaCore> PPS is side data I think
[03:06:11 CET] <Jhyra> ye, that disappear
[03:06:14 CET] <Jhyra> error changes
[03:06:20 CET] <Jhyra> Stream starts after the PPS
[03:06:24 CET] <Jhyra> and then close
[03:06:38 CET] <Jhyra> https://pastebin.com/H4Rav3Dx
[03:06:45 CET] <Jhyra> new relevant error that make the stream close
[03:07:43 CET] <SortaCore> you may also want to pass "-allowed_media_types video"
[03:08:43 CET] <Jhyra> I'll try right now
[03:11:04 CET] <Jhyra> same error :/
[03:22:29 CET] <SortaCore> yea, that won't fix it, it'll just tell the server not to send you audio
[03:22:43 CET] <SortaCore> instead of ffmpeg getting the audio and discarding it
[03:23:38 CET] <Jhyra> I'm looking in the mailing list
[03:24:09 CET] <Jhyra> I found something about the DTS, but was fixed in a 2015 build
[03:24:28 CET] <SortaCore> you may want to generate the pts/dts, I know there's a genpts flag
[03:24:34 CET] <SortaCore> I'm gonna get to bed
[03:26:28 CET] <Jhyra> ok! Thanks a lot!
[03:26:37 CET] <Jhyra> I'll try to sort it out!
[10:15:17 CET] <occivink> hi, I would like to create a video filter and possibly distribute it, is there a simpler way than to patch the entire libavfilter?
[10:18:27 CET] <durandal_1707> occivink: filter of what kind?
[10:19:57 CET] <durandal_1707> you could send patch to ml,  or put it into git repo, like facebook does?
[10:20:10 CET] <occivink> I want to make a filter like eq, but that handles brightness/gamma/saturation/contrast exactly like mpv, so that it would be easy to "bake" those into a video
[10:20:42 CET] <durandal_1707> occivink: mpv uses gpu
[10:21:39 CET] <occivink> hum, yes?
[10:21:45 CET] <durandal_1707> i think it uses opengl shaders
[10:22:00 CET] <occivink> well, that doesn't mean it can't be done on cpu
[10:22:23 CET] <durandal_1707> so you would need to ffind it and made cpu variant
[10:22:35 CET] <Fig1024> I'm trying to use libx264 encoder with ffmpeg C++ API, it works but for some reason MediaInfo reports that frame rate mode is "variable" even tho it should be constant. I am setting AVCodecContext::framerate to {60,1} but no effect. Anyone had similar issues before?
[10:23:00 CET] <durandal_1707> also it operates on rgb only for output usually
[10:23:12 CET] <durandal_1707> eq uses yuv  only
[10:23:29 CET] <durandal_1707> and its gpl
[10:23:42 CET] <occivink> durandal_1707: yes that's my plan
[10:23:53 CET] <occivink> thanks for the hints
[10:24:21 CET] <durandal_1707> eq in rgb is pretty easy
[10:25:35 CET] <occivink> but anyway regarding my first question I was hoping one could dynamically open filters, to make distribution easier
[10:28:14 CET] <durandal_1707> well the easiest distribution that will reach all users is putting code in upstream FFmpeg
[10:29:00 CET] <occivink> I guess, what are the requirements to adding a filter to ffmpeg?
[10:32:58 CET] <durandal_1707> occivink: that you send patch to ml, or just provide filter code and i will do it for you
[10:33:24 CET] <occivink> okay, so anything gets merged as long as it compiles or what?
[10:34:01 CET] <durandal_1707> as long as it works and doesnt crash
[10:34:36 CET] <occivink> good to hear, thanks a lot
[11:46:27 CET] <fdemo> I want to ask for help. I need to create a video transcoder. I tried to use examples of transcoding.c, but it's not working. Many files do not work. Can someone show an example of video transcoding.
[11:47:37 CET] <JEEB> what should generally work is demuxing and decoding, then you make sure the data you're getting is of the correct type to be fed to your encoder configuration
[11:48:17 CET] <JEEB> (and use avfilter where required to make the format be as needed)
[11:48:49 CET] <JEEB> some of the examples are rather limited in scope so f.ex. whether you need the global header flag or not
[11:49:00 CET] <JEEB> you need to decide depending on the output format, for example
[11:57:39 CET] <fdemo> I tried and filter and without - then there is no video, then the audio does not play.
[11:57:53 CET] <fdemo> to be honest, I was completely confused for a few days. I lost the idea of what and when to call. My task is to convert the video to MPEG2, and leave the audio unchanged. Could you, on my fingers, declare the sequence of calls to the required functions. I understand that this is very much.
[11:59:15 CET] <fdemo> but most of all I was confused with pts and dts
[12:00:01 CET] <JEEB> PTS is presentation, DTS is decoding
[12:00:31 CET] <JEEB> and the time base is per-stream, and also decoders and encoders have time bases in addition to demuxers and muxers
[12:00:42 CET] <JEEB> and your filter chains, too
[12:01:14 CET] <JEEB> thankfully there's functionality to match a value against a new base
[14:39:26 CET] <lluix> Hello All )
[14:53:39 CET] <lluix> Can someone help me please, havign probs with installing fmpeg
[14:54:12 CET] <lluix> used this command to install it
[14:54:17 CET] <lluix> sudo add-apt-repository ppa:jonathonf/ffmpeg-3
[14:54:18 CET] <lluix> sudo apt update
[14:54:20 CET] <lluix> sudo apt install ffmpeg libav-tools x264 x265
[14:54:30 CET] <lluix> sudo add-apt-repository ppa:djcj/hybrid
[14:54:31 CET] <lluix> sudo apt-get update
[14:54:33 CET] <lluix> sudo apt-get install ffmpeg
[15:04:21 CET] <__jack__> lluix: on Debian, using such external repo is a bad idea
[15:43:00 CET] <SortaCore> lluix why did you install ffmpeg twice?
[16:04:43 CET] <Fyr> guys, FFMPEG cannot mux an m2ts file created with FFMPEG.
[16:07:48 CET] <Fyr> if I die, I will tell that I've seen everything.
[16:08:16 CET] <Guest56781> how will you tell that when you're dead
[16:08:55 CET] <Fyr> I'll return back from dead and say it.
[16:09:02 CET] <Guest56781> hehe
[16:10:25 CET] <Fyr> or I'll add it to my testament.
[16:20:17 CET] <relaxed> you could file a bug report for posterity
[16:23:59 CET] <Fyr> it will +1 to over 9 000 forgotten bugs.
[17:37:04 CET] <NEWbi> hello :) everyone. Cannot install ffmpeg in win10
[17:37:32 CET] <durandal_1707> NEWbi: what you tried?
[17:39:10 CET] <NEWbi> went to https://ffmpeg.zeranoe.com/builds/ and downloaded what I think is the right version for win10 (ffmpeg-20170130-cba4f0e-win64-static.zip)
[17:39:16 CET] <NEWbi> but there is no exe file to install
[17:42:43 CET] <NEWbi> do I copy the dll to the windows sys or what do I do exactly?
[17:45:55 CET] <JEEB> NEWbi: there is no real installation procedure for the tool. just extract the ffmpeg.c and ffprobe.c somewhere and maybe add that directory to PATH
[17:46:13 CET] <JEEB> and then just call ffmpeg.c / ffprobe from the command line or scripts
[17:46:39 CET] <NEWbi> hello Jeeb
[17:46:51 CET] <furq> i just downloaded that zip and there are no dlls in it
[17:46:55 CET] <furq> and the binaries are in bin/
[17:47:08 CET] <furq> but also that's a year old, you want https://ffmpeg.zeranoe.com/builds/win64/static/ffmpeg-20180112-1eb7c1d-win64-static.zip
[17:47:44 CET] <NEWbi> furq yes I downloaded an alternative to ffmpeg-20180112-1eb7c1d-win64-shared (1).zip
[17:53:43 CET] <durandal_1707> NEWbi: ffmpeg is cli app
[17:54:29 CET] <NEWbi> ahhhh
[17:54:53 CET] <NEWbi> wasnt sure whether or not to add any dependencies or dll thank you Duran
[17:54:59 CET] <NEWbi> en furq
[17:56:01 CET] <NEWbi> Im writting to scripts to have my files batch converted so wanted to know whether the app will be reachable when executing
[18:00:16 CET] <NEWbi> IT works thank you guys :)
[18:07:20 CET] <NEWbi> thank you guys have a great night
[19:12:00 CET] <Fyr> guys, I get:
[19:12:00 CET] <Fyr> >>Only audio, video, and subtitles are supported for Matroska.
[19:12:15 CET] <Fyr> actually, it's exactly what I'm muxing.
[19:12:30 CET] <Fyr> how do I make FFMPEG work?
[19:13:00 CET] <JEEB> well something that you've pushed doesn't have the correct AVMEDIA_TYPE
[19:13:14 CET] <JEEB> because the message is in the "default" part of http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/matroskaenc.c;h=f22c2ab70cced241498f9dce520d0d15d1e6a615;hb=HEAD#l1299
[19:14:05 CET] <JEEB> so you have a stream where the codecpar isn't video, audio or subtitle
[19:14:32 CET] <JEEB> as much as FFmpeg sucks that doesn't seem to be incorrect in that check at least. of course doesn't stop something else failing
[20:16:43 CET] <Fyr> guys, is h264 container .h264?
[20:16:46 CET] <Fyr> or .yuv?
[20:17:11 CET] <furq> .h264
[20:17:20 CET] <furq> .yuv is rawvideo
[20:17:21 CET] <Fyr> thanks
[20:17:33 CET] <JEEB> also it's not a container
[20:17:33 CET] <Fyr> how about DTS-HD MA?
[20:17:35 CET] <kepstin> neither of those are really "containers" tho, .h264 is a raw h264 bitstream
[20:17:37 CET] <furq> right
[20:17:42 CET] <JEEB> it's raw annex b H.264
[20:18:01 CET] <JEEB> N * 0x00 00 00 01 <data>
[20:18:06 CET] <Fyr> will muxing cause problems when remuxing to and from .h264?
[20:18:15 CET] <furq> no
[20:18:24 CET] <JEEB> libavformat has issues with muxing to stuff like mp4 from raw H.264
[20:18:24 CET] <furq> but the raw bitstream doesn't contain things like the framerate
[20:18:43 CET] <furq> so you'll need to remember what that is
[20:18:44 CET] <JEEB> due to some hysterical raisins where nothing generates proper timestamps for the packets :P
[20:18:52 CET] <Fyr> thanks, in which container is better to keep DTS-HD MA?
[20:18:59 CET] <furq> shrug
[20:19:02 CET] <furq> probably just put it in mka
[20:19:14 CET] <JEEB> matroska or mp4 both support DTS with the extensions IIRC
[20:19:22 CET] <JEEB> so whatever's up your alley
[20:19:45 CET] <Fyr> FFMPEG says "Starting new cluster due to timestamp" and the video stutters when playing.
[20:20:13 CET] <BtbN> don't ever use raw h264, it's lacking some important informations
[20:20:13 CET] <Fyr> I'm trying to get rid of it via remuxing.
[20:20:15 CET] <JEEB> furq: fyi I've had to poke people into using L-SMASH's muxer or so for muxing of raw H.264 into something :P
[20:20:40 CET] <JEEB> Fyr: sounds like input timestamps are whacked, just starting a new cluster isn't the problem.
[20:21:06 CET] <JEEB> BtbN: and lavf is unable to parse it to generate even the most basic ones with the time base thing :|
[20:21:24 CET] <JEEB> even though it exports the average_frame_rate or whatever value it was that ffmpeg.c shows
[20:23:47 CET] <furq> i've used ffmpeg to mux raw h264 before and it worked fine
[20:23:54 CET] <furq> granted i've only ever done that to change framerate
[20:23:55 CET] <JEEB> did you have b-frames?
[20:23:58 CET] <furq> yeah
[20:24:01 CET] <JEEB> and what was the output container?
[20:24:04 CET] <furq> er
[20:24:06 CET] <furq> probably mkv
[20:24:32 CET] <JEEB> that might be less requiring than movenc, but not sure
[20:24:33 CET] <furq> i've done it a few times to do pal to film conversions and it always seemed to work ok
[20:24:58 CET] <Fyr> the error about new clusters due to timestamp - is it because corrupt video time stamps?
[20:25:00 CET] <JEEB> also I've had discussions on the AVPacket timestamp generation from raw bit streams
[20:25:27 CET] <JEEB> Fyr: if you are remuxing check the input timestamps with ffprobe -of json -show_packets -show_streams file
[20:25:30 CET] <JEEB> or something
[20:25:57 CET] <furq> you probably want to pipe that into less if you like having a terminal
[20:25:58 CET] <JEEB> then you could parse that json or look at it (if it's specific to some stream, you can limit ffprobe to it)
[20:26:19 CET] Action: JEEB never remembers the stream selection way in ffprobe :P
[20:26:31 CET] <furq> -select_streams v:0
[20:26:31 CET] <JEEB> I always end up searching for it in the docs
[20:26:36 CET] <JEEB> right
[20:26:43 CET] <Fyr> ok, I see a huge JSON list.
[20:27:12 CET] <JEEB> also if it's matroska you can use mkvinfo from mkvtoolnix for another thing that can output data on the data packets
[20:29:28 CET] <JEEB> furq: btw the more often hit thing I find out is mpeg-2/h.264 remuxing from and to mpeg-ts derping up because the timestamps you get are similar to the raw H.264 reader.
[20:29:38 CET] <JEEB> but yea, you're lucky if you've never hit that stuff
[20:29:56 CET] <JEEB> re-encoding never hits the issue because the timestamps are usually fixed... during decoding
[20:30:08 CET] <Fyr> what those PTS and DTS time might tell me?
[20:30:23 CET] <JEEB> those are the DTS and PTS of those packets
[20:30:42 CET] <JEEB> which are then passed on to the muxer if you're remuxing :P
[20:31:20 CET] <JEEB> if you have an idea at which point the message happens you can check that and see if it looks weird
[20:31:44 CET] <JEEB> my first guess is that the input file has weird timestamps and my second guess is that something's borked as usual
[20:32:48 CET] <Fyr> if I find that some timestamps are messed up, what's the next step?
[20:37:16 CET] <JEEB> since the command line ffmpeg.c tool has no convenient way of overriding timestamps, I would probably just use either mkvtoolnix's mkvmerge(gui) or l-smash's timelineeditor to regenerate the timestamps
[20:37:37 CET] <durandal_1707> setpts
[20:37:40 CET] <JEEB> if it's just a constant frame rate I would use l-smash's muxer and get an mp4 file with proper timestamps
[20:37:48 CET] <JEEB> durandal_1707: that is a video filter that works with decoded pictures
[20:37:59 CET] <JEEB> this is for overriding timestamps of a fucked up muxed file :P
[20:38:15 CET] <JEEB> for after decoding, sure. libavfilter has the filters
[20:45:35 CET] <durandal_1707> we gonna made everything filters
[20:46:25 CET] <durandal_1707> in distant future
[22:53:31 CET] <grunt_> hiya. after extracting AAC audio from an audio-only MP4 file into M4A file using "ffmpeg -i input.mp4 -vn -c:a copy output.m4a", the resultant file is ~14MB BIGGER than the source, with all of it being tucked at the end of the file.
[22:54:52 CET] <BtbN> isn't m4a the same as mp4, just a different extension?
[22:55:03 CET] <grunt_> that section clearly begins with some header
[22:55:22 CET] <JEEB> yes, m4a is apple's extension for ISOBMFF with audio
[22:55:30 CET] <grunt_> BtbN: yeah, that's not the point
[22:55:50 CET] <grunt_> the point is what are those 14MB of garbage
[22:55:53 CET] <JEEB> grunt_: I recommend checking how many streams ffprobe or so says that thing has, and post the ffmpeg.c command line and log to pastebin or so, and link here
[22:56:01 CET] <JEEB> to see if there's anything clearly going on wonky :P
[22:56:13 CET] <JEEB> or well, command line you posted but the log would be nice on your input file
[22:56:15 CET] <grunt_> nope, just the one stream, as expected
[22:56:33 CET] <grunt_> Stream #0.0(und): Audio: aac, 22050 Hz, mono, fltp, 32 kb/s
[22:57:50 CET] <grunt_> JEEB: how do i generate the log?
[22:58:12 CET] <JEEB> it's just what ends up in the terminal output, if you want you can add -v verbose to add some possibly useful stuff in there
[22:58:29 CET] <JEEB> pastebin or something similar the terminal output, and link to it here since it's way more than 1-2 lines :P
[23:02:01 CET] <grunt_> JEEB: nothing particularly fishy there, but thanks for drawing my attention to the output!
[23:02:04 CET] <grunt_> "video:0kB audio:340741kB global headers:0kB muxing overhead 4.306841%"
[23:02:26 CET] <grunt_> that "4.3%" "muxing overhead" correspends quite precisely to the increase in file size!
[23:02:58 CET] <grunt_> what's "muxing overhead" and how do i extract info about it from m4a?
[23:03:23 CET] <BtbN> it's just the overhead the container information causes. Seek index and stuff
[23:03:37 CET] <JEEB> grunt_: yes, thank you for letting people not help you
[23:08:39 CET] <`md> is there any reason configure would not pick up libva 2.0, while ld -lva --verbose does?
[23:09:18 CET] <JEEB> ffbuild/configure.log should have the reasoning
[23:09:31 CET] <JEEB> as in, what was actually run and why something was not found or not accepted
[23:09:48 CET] <`md> well yea, it does, it just says it cant find it
[23:10:08 CET] <JEEB> can you post the checks? it should have the commands and the output
[23:10:08 CET] <`md> /usr/bin/ld: cannot find -lva
[23:10:22 CET] <`md> that's from the config.log
[23:10:23 CET] <JEEB> (in pastebin of course but yunno)
[23:10:51 CET] <JEEB> ok, so that sounds more like a toolchain thing. I thought it would get found with pkg-config, though?
[23:11:21 CET] <`md> it DID find it when i had 1.x of libva installed
[23:11:49 CET] <`md> JEEB: https://pastebin.com/6sv2744g
[23:12:23 CET] <JEEB> that looks like the fallback check, let me check if I recall correctly from the configure script
[23:12:46 CET] <JEEB> also I do have some sort of memory of building FFmpeg with libva 2.0 relatively recently, but I might be incorrectly remembering things, of course
[23:12:59 CET] <`md> JEEB: for reference, thats what ld finds on its own https://pastebin.com/mRxvXVCU
[23:13:36 CET] <`md> JEEB: you want my configure options?
[23:14:01 CET] <`md> ./configure --extra-ldexeflags="-static" --pkg-config-flags="--static" --bindir="/storage/pystream" --enable-pic --enable-gpl --enable-version3 --enable-libopus --enable-libvorbis --enable-nonfree --enable-openssl --enable-vaapi
[23:14:26 CET] <atomnuker> you can use --disable-shared --enable-static instead of adding flags
[23:14:43 CET] <`md> alright, yea
[23:14:43 CET] <JEEB> also I'm pretty sure static is the default
[23:14:54 CET] <JEEB> shared libs are only built when requested
[23:15:01 CET] <JEEB> but sure --disable-shared --enable-static is specific
[23:15:01 CET] <`md> i just wanted to make extra sure :D
[23:15:20 CET] <JEEB> anyways, looked at the configure script and it seems like it indeed just does an ld check
[23:15:26 CET] <JEEB> well, compilation + ld check
[23:15:38 CET] <JEEB> if I recall correctly what check_lib does :P
[23:16:02 CET] <`md> well that would be mighty weird, actually
[23:17:44 CET] <JEEB> yeh, this is as I remember, vaapi 2.0 should work since there was an explicit fix for 2.0 in November
[23:18:05 CET] <`md> i remember something like that too
[23:18:12 CET] <`md> and this is with a fresh git checkout
[23:18:20 CET] <JEEB> but yea, the linker not finding it in the configure script but finding in the terminal :P
[23:18:24 CET] <JEEB> is kind of weird
[23:18:26 CET] <`md> yea
[23:18:43 CET] <furq> does ld -static -lva --verbose find it
[23:18:43 CET] <JEEB> at least you have the C file and the command lines that the configure script used explicitly
[23:19:15 CET] <JEEB> so yes, furq got to it pretty much :P I would have checked first if the thing that the configure script tries doing worked, and if not looking at removing options or adding them :P
[23:19:21 CET] <JEEB> and yes, that -static stands out there
[23:19:36 CET] <furq> yeah you don't need that unless you want a fully static binary
[23:19:47 CET] <furq> and it is prone to breaking stuff that you can't static link
[23:20:37 CET] <`md> hm, well yea, actually i kinda want a fully static binary
[23:20:55 CET] <JEEB> it will be static binary but since you most likely don't have a static libva :P
[23:21:04 CET] <`md> cant really install or compile anything on my target system
[23:21:05 CET] <JEEB> -static for ld makes it fail if it doesn't find static stuff, I guess
[23:21:08 CET] <furq> it does
[23:21:14 CET] <`md> OH
[23:21:15 CET] <`md> right
[23:21:16 CET] <furq> i notice relaxed's static builds don't list libva
[23:21:25 CET] <furq> so i assume that's going to be tricky
[23:21:30 CET] <`md> :facepalm:
[23:21:38 CET] <JEEB> dunno if tricky, but most likely not available on `md's system
[23:21:44 CET] <JEEB> as static
[23:21:51 CET] <`md> well my system DOES have libva
[23:22:12 CET] <JEEB> yes, but with that -static you are most likely restricting ld to static libs only, and the command would fail on your command line as well :P
[23:22:15 CET] <JEEB> quickly test and confirm
[23:22:17 CET] <`md> lemme just try it real quick
[23:24:36 CET] <`md> for fucks sake
[23:24:43 CET] <`md> OF COURSE now it works...
[23:24:50 CET] <JEEB> :)
[23:24:56 CET] <`md> thanks you guys, sometimes you just dont see the wood for the trees
[23:25:41 CET] <`md> now whether this build will run or not on my target is a whole different story, but lemme try
[23:25:58 CET] <`md> i'd love to avoid to set up a whole crosscompiling chain
[23:32:20 CET] <grunt_> BtbN: bungo! the boxes/atoms i'm seeing there are just the indexy sort of fluff (stco, stsz, etc.)
[23:32:32 CET] <grunt_> BtbN: thanks!
[23:33:34 CET] <JEEB> grunt_: those generally shouldn't be a problem though. how much content do you have for 32kbps audio-only to somehow have 14MiB of extra (which is ~4% additional stuff?)
[23:33:56 CET] <grunt_> er... 4% is 4%
[23:34:07 CET] <JEEB> also if you really want to diff stuff you can use something like l-smash's `boxdumper --box file`
[23:34:16 CET] <JEEB> so 14MiB extra being 4%...
[23:34:46 CET] <JEEB> 350MiB file altogether?
[23:34:47 CET] <thebombzen> well that's 14 MiB / 0.04 to find what 100% is
[23:35:11 CET] <`md> dammit, of course there are missing libs :/
[23:35:27 CET] <BtbN> grunt_, they should be in the original mp4 already as well, guess someone removed it?
[23:35:49 CET] <JEEB> it should still have some indexing if it's playable
[23:36:53 CET] <grunt_> JEEB: circa that, yeah. is there a simple way to affect how much of that ffmpeg bakes in? (the original didn't have ANY, so evidently it's possible container-wise)
[23:37:05 CET] <JEEB> nah, it can't have *any*
[23:37:19 CET] <JEEB> or well, highly unlikely
[23:37:46 CET] <JEEB> you could check with boxdumper or whatever you utilized to diff the files
[23:37:57 CET] <grunt_> the last "moov" box that ffmpeg put into the m4a does not exist in the original.
[23:37:58 CET] <JEEB> of course the movenc muxer in libavformat has its own quirks
[23:38:14 CET] <JEEB> that could have been moved to the beginning of you had moofs instead
[23:38:18 CET] <JEEB> *or you
[23:40:22 CET] <JEEB> the movenc muxer has some options but I'm not fully sure how much you can affect in your specific case
[23:40:46 CET] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#mov_002c-mp4_002c-ismv
[00:00:00 CET] --- Sun Jan 14 2018