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

[burek]

[00:00:32 CEST] <kepstin> (and it's also just as meaningless, since different encoders, settings, etc, mean 10mbit can look completely different between two encodes of the same content)
[03:30:33 CEST] <calamari> I was preparing to convert some MPEG2 video streams when I heard that some of these might be variable FRAME rate, due to a different rate being supposedly being used for special effects scenes. Can ffmpeg (or some other linux program) evaluate a video stream to determine whether the rate ever changes? I'm actually not sure if rate info is even in the video stream or whether it'd be in the container.
[03:39:18 CEST] <ariyasu> you can use media info of ffprobe to get that info
[03:41:35 CEST] <calamari> thanks. I'm not seeing VFR in the ffprobe man page.. should I be looking for something else?
[03:43:48 CEST] <calamari> mediainfo was more helpful
[03:44:08 CEST] <calamari> Frame rate mode                          : Variable
[03:45:36 CEST] <calamari> thanks!
[03:47:18 CEST] <calamari> if I want to preserve the VFR with ffmpeg do I need to do anything (like -vsync vfr) or will it automatically retain it?
[03:48:10 CEST] <Hello71> ffmpeg generally tries to preserve everything
[03:48:19 CEST] <Hello71> even if it's not really the right thing to do
[03:48:55 CEST] <Hello71> personally I think the CLI would make more sense if the default was to not re-encode
[03:49:00 CEST] <Hello71> but it's a little too late
[03:49:13 CEST] <calamari> yeah not sure yet whether my player even handles it.. guess I should do some tests
[03:49:37 CEST] <Hello71> if only avconv actually had a better interface rather than just screaming IMPROVED IMPROVED and FFMPEG IS DEPRECATED
[03:50:03 CEST] <calamari> ffmpeg is deprecated? I didn't know that, haha
[03:50:33 CEST] <calamari> I normally just pipe raw frames to x264, but that's not going to work this time
[03:51:20 CEST] <Hello71> yes, everybody should use libav
[03:51:23 CEST] <Hello71> it's not dead, just resting
[03:53:53 CEST] <calamari> I do remember avconv years back.. but it seems Ubuntu 18.04 just has ffmpeg again, it's not a symlink or anything either
[03:54:19 CEST] <calamari> ffmpeg version 3.4.4-0ubuntu0.18.04.1 Copyright (c) 2000-2018 the FFmpeg developers
[03:55:07 CEST] <calamari> whatever it is, I'm sure it'll do the job I need
[03:56:48 CEST] <calamari> I mainly used x264 back in the day because I could ensure the H.264 was blu-ray compliant... but I haven't authored a blu-ray in years so all those special options are unnecessary
[04:46:30 CEST] <Maverick|MSG> is it possible to increase the speed of the audio (atempo) but only at certain timepoints in a video?
[05:00:57 CEST] <killown> how do I merge two or more videos that has different sizes and frame rates
[05:27:58 CEST] <calamari> killown: I haven't tried this, but I wonder if mkvmerge would work
[05:49:09 CEST] <worstadmin> ffmpeg is actively developed
[12:56:22 CEST] <th3_v0ice> Are there any fields in the API part that tell you how big an AVFrame that is decoded actually is in bytes?
[12:57:39 CEST] <BtbN> no
[12:57:51 CEST] <BtbN> You can calculate a good guess based on the height and linesize and the pix_fmt
[13:02:43 CEST] <th3_v0ice> What would be the formula for that?
[13:06:06 CEST] <BtbN> the sum of the (height << subsample[plane]) * linesize[plane] * bytes_per_pixel for all planes
[13:06:10 CEST] <BtbN> roughly
[13:06:34 CEST] <BtbN> forget about the bytes_per_pixel, linesize already is in bytes
[13:06:35 CEST] <iive> linesize is in bytes
[13:06:55 CEST] <iive> you might want to take abs() of it though.
[13:23:59 CEST] <th3_v0ice> I cant find the subsample field in the AVFrame structure, is this the data or buf?
[14:01:31 CEST] <BtbN> The pixel format dictates it
[14:01:52 CEST] <BtbN> As well as the number of planes
[14:08:29 CEST] <th3_v0ice> Oh, so for 422 it would be (height << 4) * linesize[0] + (height << 2) * linesize[1] + (height << 2) * linesize[2] ?
[14:11:32 CEST] <BtbN> no
[14:12:02 CEST] <BtbN> There's a separate API to get information about pix_fmts ffmpeg knows about.
[14:30:44 CEST] <th3_v0ice> Ok, thanks!
[14:59:13 CEST] <PyroPeter> hey, I need to eliminate frequencies under 30Hz and above 15kHz for FM broadcasting, but I can't figure out how to do this with ffmpeg. I guess that I can forget about 'lowpass' and the like, because they are only two-pole filters and are not steep enough for this application...
[15:02:29 CEST] <JEEB> I would have thought of 'alimit' (http://ffmpeg.org/ffmpeg-filters.html#alimiter) but it seems like that's not it
[15:02:44 CEST] <JEEB> some audio encoders have their own limiting AVOptions
[15:10:42 CEST] <durandal_1707> PyroPeter: you can use them in cascade
[15:11:19 CEST] <durandal_1707> JEEB: alimiter is for broadband audio volume limiting
[15:11:29 CEST] <JEEB> yea
[15:12:42 CEST] <durandal_1707> PyroPeter: how steep you need?
[15:39:30 CEST] <isuxx> how can i make my player show 64bit * instead of 16bit aac
[15:42:01 CEST] <tytan> Hello everyone, I tried to crop a 16:9 video to 2:1 but I wanted the cropped rectangle to be the lower part of the video so I tried to crop away the upper 80 pixel on y with the following command but it didn't work. The rectangle seems to be centred. ffmpeg -i 16_9_video.mp4 -vf "scale=1280:640:0:-80" 2_1_video.mp4
[15:43:23 CEST] <tytan> oh I meant crop, not scale in here
[16:05:46 CEST] <PyroPeter> durandal_1707: if I set the cutoff to 14kHz, I seem to need a 100dB/decade slope to end up 3dB below the 19kHz pilot tone... (I have no idea what I'm doing, if that isn't obvious)
[16:11:50 CEST] <durandal_1707> PyroPeter: you could model high order IIR filter in some other software and use its defined points in aiir filter for fixed sample rate, aiir filter also can draw frequency and phase response
[16:12:48 CEST] <durandal_1707> or use recently added acrossover and its 8th order filter to split bands
[16:12:56 CEST] <durandal_1707> if 8th order is enough
[16:56:10 CEST] <rafael2k> Hi all. Is there any volumetric video codec present in ffmpeg?
[16:56:21 CEST] <JEEB> "volumetric video codec"?
[16:56:32 CEST] <rafael2k> XYZ + RGB
[16:56:43 CEST] <rafael2k> aka point cloud
[16:57:05 CEST] <rafael2k> Volumetric Video I think is precise, indeed.
[16:57:25 CEST] <JEEB> I know what XYZ is (kind of), and I know what RGB is more or less
[16:57:30 CEST] <JEEB> but XYZ + RGB is like ?!
[16:57:42 CEST] <rafael2k> a vector of points
[16:57:56 CEST] <rafael2k> XYZ is the coordinate of the point
[16:58:09 CEST] <JEEB> the only format that supports the "XYZ" pixel format seems to be JPEG2000
[16:58:14 CEST] <rafael2k> no no
[16:58:20 CEST] <rafael2k> this is the color space...
[16:58:31 CEST] <JEEB> well yes
[16:58:40 CEST] <rafael2k> I'm talking about 3D Volumetric Video
[16:58:41 CEST] <JEEB> it is just specifically marked separate from RGB etc
[16:59:01 CEST] <JEEB> ok, so multiview?
[16:59:06 CEST] <rafael2k> no
[16:59:20 CEST] <rafael2k> multiview are many 2D frames
[17:00:09 CEST] <isuxx> what -codecw does s64p support
[17:00:20 CEST] <JEEB> > There is no standard yet that generated volumetric video and makes it experienceable at home. Compression of this data is starting to be available with the MPEG group in search for a reasonable way to stream the data.
[17:00:24 CEST] <JEEB> from wikipedia
[17:00:35 CEST] <JEEB> also that sounds more like a changing 3d model
[17:00:41 CEST] <JEEB> rather than video
[17:00:53 CEST] <JEEB> so each capture point would be its own 3-D model
[17:01:44 CEST] <rafael2k> I know of the proposals in MPEG
[17:01:57 CEST] <rafael2k> there are 3 working groups
[17:02:30 CEST] <Accord> is it possible to take an audio file of 10.5 seconds and "compress" it to 10seconds? like speed it up just a bit
[17:02:32 CEST] <Accord> to get 10s
[17:02:54 CEST] <Accord> not sure what this operation is called
[17:03:14 CEST] <furq> isuxx: codec or muxer
[17:03:45 CEST] <rafael2k> example of color encoder for vozelized point cloud: https://github.com/digitalivp/RAHT
[17:03:46 CEST] <furq> the codec is pcm_s64le or pcm_s64be, and you can mux it into m4a
[17:03:48 CEST] <furq> er, mka
[17:04:20 CEST] <furq> apparently wav supports it as well
[17:05:20 CEST] <rafael2k> I prefer the term volumetric video then dynamic point clouds...
[17:05:45 CEST] <furq> if you specifically need planar then i don't know of anything that supports it
[17:06:01 CEST] <rafael2k> anyway... just thinking how to implement it to ffmpeg
[17:06:11 CEST] <kepstin> Accord: if it's enabled in your ffmpeg build, the 'rubberband' filter can adjust audio speed with decent results
[17:06:38 CEST] <isuxx> dunno, i was thinking more means more quality
[17:06:39 CEST] <kepstin> Accord: there's a few other filters that can work too, depending on whether a pitch shift is ok.
[17:07:25 CEST] <isuxx> i just gotta high tech encode my mp3 collection to better quality
[17:08:08 CEST] <isuxx> is there any compression i can add for like 150kbit/sec stream
[17:08:13 CEST] <kepstin> isuxx: converting from mp3 to anything else will never make the quality better, and will usually make it either worse or bigger.
[17:09:13 CEST] <isuxx> i do want 64b files and 96k - more hz, for that i gotta re-encode dem
[17:09:27 CEST] <isuxx> also from foreign formatsnlike youtube webm ogg
[17:10:07 CEST] <kepstin> that doesn't make sense. if you need conversion to a different sample rate, your player will do that automatically when decoding normally
[17:10:25 CEST] <kepstin> and afaik there's no DACs around that support 64b anyways.
[17:10:39 CEST] <isuxx> i got a 64bit up to 700khz to 32f out
[17:11:32 CEST] <isuxx> i need to reencode dem for gain ofnquality, but size rather not much available, like 1.5x mp3, and i need to convert dem to make em available ( at my hipraphop.ovh )
[17:12:09 CEST] <isuxx> err 64b 32fout android music player
[17:12:49 CEST] <kepstin> re-encoding mp3 files cannot increase quality
[17:13:22 CEST] <isuxx> eh it will like i can code
[17:13:29 CEST] <kepstin> (and yes, the android audio apis support 32bit float, but the actual dac in the phone is almost certainly max 16bit)
[17:13:40 CEST] <isuxx> yet i have -codec pcm_.. and -aq .1 gotta test
[17:13:57 CEST] <isuxx> well it makes me feel more qualitive =p
[17:14:03 CEST] <kepstin> converting mp3 to pcm is the same as decoding the mp3
[17:14:10 CEST] <kepstin> there's no quality gain possible
[17:14:14 CEST] <kepstin> it just wastes space
[17:14:27 CEST] <isuxx> ill test
[17:14:35 CEST] <kepstin> no need to.
[17:14:41 CEST] <ritsuka> yes if your source is not already 64bit 96khz there is no point encoding to it
[17:14:44 CEST] <isuxx> i saw once a 64bit 'mpeg' file running on my player
[17:14:57 CEST] <ritsuka> (I would say there is no point on using it either way&)
[17:15:02 CEST] <isuxx> my source is crappy 44.1 non-pro encoded
[17:15:32 CEST] <kepstin> yeah, given that people can't hear barely anything (at best) above 20kHz anyways, 44.1 is great.
[17:16:04 CEST] <kepstin> converting a low sample rate audio to high sample rate will sound exactly the same and be larger for no reason
[17:16:23 CEST] <kepstin> it can't add anything that wasn't present in the original audio file
[17:16:58 CEST] <isuxx> i gotta figure out -opts first
[17:17:18 CEST] <kepstin> there are no options for pcm audio, it's just raw decoded audio. it's always the same.
[17:18:17 CEST] <kepstin> decoding an mp3 to pcm, sending the pcm to the phone, playing it there is *exactly the same thing* as sending the mp3 to the phone, having the phone decode the mp3 to pcm, and playing it.
[17:18:36 CEST] <isuxx> i had many 'buffer underrun' ...
[17:18:52 CEST] <isuxx> i gotta reencode anyway
[17:19:21 CEST] <kepstin> buffer underrun can only happen during live capture or playback, reencoding won't help
[17:19:21 CEST] <isuxx> so i choose 96k andn32 pref 64bit audio format, umm i halfway know
[17:19:38 CEST] <isuxx> it did output so much i had to c-c
[17:19:41 CEST] <kepstin> (if you get buffer underruns during playback, switching to higher sample rate/bigger files will only make it worse)
[17:20:44 CEST] <isuxx> so ill try 32 rather
[17:20:58 CEST] <isuxx> and no pcm but compressed
[17:21:15 CEST] <Foaly> i know many players have trouble with anything more than 16 bit
[17:21:21 CEST] <kepstin> recompressing audio from a lossy codec like mp3 to a different (or even same) lossy codec will reduce quality
[17:22:01 CEST] <kepstin> (and most lossy codecs don't even have a concept of bit depth, they usually internally work in a sort of floating point format that's fixed for the codec design)
[17:22:58 CEST] <isuxx> i dont need much compatibility rather more new style stats
[17:23:53 CEST] <isuxx> fltp format
[17:25:58 CEST] <kepstin> anyways, 1) converting mp3 to any other format will never raise quality (it will usually get worse), and 2) converting audio from lower to higher sample rate or bit depth will never raise quality (it will sound exactly the same)
[17:26:02 CEST] <kepstin> and that's all you need to know
[17:29:24 CEST] <kepstin> the only way to get a "higher quality" version is to get the audio master from before it was encoded to mp3. And even then there's no point in anything higher than 44.1 or 48kHz, since it just potentially adds ultrasonics that people can't hear and speakers/headphones won't reproduce anyways.
[17:30:45 CEST] <kepstin> (using higher rates or depths during editing/mixing/mastering can makes sense so there's some extra headroom available in the software, but that's a different issue)
[17:34:00 CEST] <isuxx> [mp3float @ 0x5c1a246e83c0] overread, skip -6 enddists: -4 -4
[17:35:15 CEST] <kepstin> isuxx: i'd have to see the complete ffmpeg output to be sure (don't paste it in the irc channel, use a pastebin), but that probably means that your original mp3 is corrupt. But if you can't hear any issue, probably just ignore it.
[17:35:31 CEST] <Accord> kepstin: thanks, hopefully I'll find another fix for this problem
[17:36:14 CEST] <Accord> I've got another weird issue, if I do ffprobe -show_frames on my input I have the first frame with negative pts but if I try to aselect=gte(pts\,0) it doesn't drop the frame
[17:36:30 CEST] <isuxx> `i gottantest hearing it
[17:36:38 CEST] <kepstin> Accord: ffmpeg adjusts frame timestamps to start at 0 when reading the file
[17:36:46 CEST] <kepstin> (the ffmpeg cli tool, that is)
[17:36:53 CEST] <Accord> kepstin: any way to prevent it?
[17:37:36 CEST] <kepstin> Accord: yes, use the -copyts input option. But note this disables a bunch of other timestamp cleanups and can cause other problems depending on the input file.
[17:37:51 CEST] <Accord> thanks, will try that
[17:38:01 CEST] <Accord> I'm gonna set audio pts based on samples anyway
[17:40:48 CEST] <Accord> ok, looking at the frames this looks fine but the last frame has pts "29.952000", and duration "0.032000",
[17:40:54 CEST] <Accord> however ffmpeg reports the file size to be 30.02
[17:41:01 CEST] <Accord> why's that?
[17:41:07 CEST] <Accord> I mean file duration
[17:43:34 CEST] <Accord> and if I dump frames with ffprobe and add all the pkt_duration_times I get 29.984
[17:43:36 CEST] <acresearch> people i have a flowblade project that i cannot render, is it possible to render through ffmpeg?
[17:44:43 CEST] <Accord> well, ffprobe -show_streams shows the correct duration.. ffmpeg -i doesn't. .I think that's a bug
[18:03:07 CEST] <kepstin> Accord: there's some weird rounding in encoded audio files sometimes due to frame sizes - e.g. aac frames are 1024 samples long, and the real end of the audio is marked with metadata ("discard last X samples" or something like that)
[18:47:23 CEST] <Accord> i see
[21:18:52 CEST] <rmbeer> hello...
[21:19:03 CEST] <rmbeer> why i can't concatenate two videos?:
[21:19:11 CEST] <rmbeer> ffmpeg -i /opt/Torrent/3D/3Drender/pre.mkv -i out3.mp4 -lavfi "movie=/opt/Torrent/3D/3Drender/pre.mkv, scale=640:480, setsar=1:1 [v1]; movie=out3.mp4, scale=640:480, setsar=1:1 [v2]; [v1] [0:a:0] [v2] [1:a:0] concat=n=2:v=2:a=2 [outv] [outa]" -map '[outv]' -map '[outa]' out4.mp4
[21:19:49 CEST] <rmbeer> i no understand this error:
[21:19:55 CEST] <rmbeer> Media type mismatch between the 'Parsed_setsar_5' filter output pad 0 (video) and the 'Parsed_concat_6' filter input pad 2 (audio)
[21:20:00 CEST] <rmbeer> Cannot create the link setsar:0 -> concat:2
[21:20:55 CEST] <furq> don't use the movie filter
[21:21:07 CEST] <furq> replace them with [0:v] and [1:v]
[21:21:33 CEST] <rmbeer> but this have different size... i need convert with scale=
[21:23:39 CEST] <furq> http://vpaste.net/MpGS0
[21:23:40 CEST] <furq> like that
[21:23:59 CEST] <rmbeer> i fix the problem!...
[21:24:26 CEST] <rmbeer> i only need set to v=1:a=1
[21:25:05 CEST] <furq> oh right yeah
[21:25:17 CEST] <furq> you shouldn't use the movie filter anyway
[21:25:24 CEST] <furq> that reads both input files twice for no reason
[21:29:13 CEST] <rmbeer> furq, i see, thanks!...
[00:00:00 CEST] --- Sat Oct 13 2018