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

[burek]

[13:36:23 CEST] <Daisae> In copying a segment from an AV file, is there a way to specify to start with the I-Frame after a time rather than before?
[13:37:34 CEST] <JEEB> the seeking API actually seems to do that by default although I guess you might have more luck by indexing the thing first to know where exactly the random access points are
[13:40:39 CEST] <Daisae> Thanks.
[14:03:49 CEST] <{xmb}> is there a -novideo option
[14:04:14 CEST] <ChocolateArmpits> {xmb}, -vn
[14:04:20 CEST] <{xmb}> thxx
[14:21:10 CEST] <{xmb}> how can i somehow do a tech quality check on files
[14:21:21 CEST] <{xmb}> eg diff between vorbis and libvorbis
[14:23:34 CEST] <ChocolateArmpits> {xmb}, use ffprobe to get information about streams and their formats
[14:25:29 CEST] <{xmb}> i more need like hearing differencies, yet i listened and found vorbis better than libvorbis, thanks tho
[14:25:50 CEST] <ChocolateArmpits> oh then that's not for that
[14:26:27 CEST] <furq> uh
[14:26:32 CEST] <{xmb}> m4a doesnt support 96000+ ?
[14:26:35 CEST] <furq> libvorbis should be a lot better than vorbis
[14:26:48 CEST] <{xmb}> ill listen to more tests
[14:27:02 CEST] <Daisae> {xmb}: someone made their own tunings to Vorbis parameters.  I don't remember more. I'm not sure Vorbis has any advantage over Opus -- aside from having a better name.
[14:27:04 CEST] <furq> the internal vorbis encoder is pretty underdeveloped iirc
[14:27:12 CEST] <furq> also yeah you should be using opus anyway
[14:27:27 CEST] <furq> by which i mean libopus
[14:27:46 CEST] <{xmb}> i cant, i tried, no 96khz+ and no fltp o
[14:27:55 CEST] <{xmb}> and/or
[14:28:01 CEST] <furq> why would you want lossy 96k
[14:28:09 CEST] <{xmb}> better q
[14:28:26 CEST] <Daisae> You mean that Opus does not support >96KHz?
[14:28:27 CEST] <{xmb}> from crappy to more q, i heard much enuff diff
[14:28:39 CEST] <furq> opus doesn't support anything about 48khz
[14:28:45 CEST] <{xmb}> either or both 96k and fltp
[14:28:54 CEST] <Daisae> What is fltp?
[14:28:57 CEST] <furq> for good reasons that will start an argument
[14:29:00 CEST] <furq> fltp is 32-bit float samples
[14:29:03 CEST] <furq> inasmuch as lossy codecs have those
[14:29:04 CEST] <{xmb}> 32b floating point i think
[14:29:14 CEST] <Daisae> furq: You mean 'above'?
[14:29:21 CEST] <furq> i do
[14:29:40 CEST] <{xmb}> u can maybe listen to the test samples
[14:30:14 CEST] <ChocolateArmpits> opus is meant for internet stuff, not production, so 96kHz is useless
[14:30:25 CEST] <furq> s/internet stuff/playback but yeah
[14:30:32 CEST] <{xmb}> what other audio container, more common than mka, for the high stats purpose
[14:30:55 CEST] <ChocolateArmpits> {xmb}, are you interested in quality solely?
[14:31:01 CEST] <furq> i mean i don't see why you'd use anything other than flac or pcm
[14:31:19 CEST] <{xmb}> so lala better-up quality
[14:31:20 CEST] <furq> i know flac only does 24-bit but 24-bit int to 32-bit float is lossless iirc
[14:31:27 CEST] <{xmb}> more -q more hz more bitnthats all
[14:31:49 CEST] <{xmb}> i hoped for 64b but all i can find is uncompressed pcm
[14:32:08 CEST] <{xmb}> flac is too much size
[14:32:34 CEST] <{xmb}> i read 20 / 50 mb per 4 min song, no good for sharing on slow inet or so like phones
[14:32:39 CEST] <furq> oh wait you're that guy from yesterday who wanted to reencode mp3s at a higher sample rate so they'd be higher quality
[14:32:47 CEST] <{xmb}> yea
[14:32:50 CEST] <{xmb}> :/
[14:32:54 CEST] <furq> yeah as we repeatedly told you, that isn't a thing
[14:33:19 CEST] <{xmb}> could u listen to the example tho ?
[14:33:51 CEST] <furq> unless you're encoding a different mp3 from a lossless source
[14:34:14 CEST] <furq> you can't get back the information that was lost by mp3 compression
[14:34:41 CEST] <{xmb}> i dontmerr.. i make it betternquality resampled
[14:34:45 CEST] <furq> if you're hearing a difference then you should probably do a proper abx test
[14:34:51 CEST] <{xmb}> makes a differencemfor me enuff to do it
[14:35:26 CEST] <{xmb}> ohnwell :/ thanks anyway tho
[14:36:05 CEST] <durandal_1707> if you still hear difference after abx, you should visit nearest doctor ASAP
[14:36:32 CEST] <{xmb}> listen yourself, ..
[14:36:54 CEST] <{xmb}> the bass-loss is less, its comfortabler, clearer
[14:37:45 CEST] <durandal_1707> that is your brain making fun of you
[14:37:53 CEST] <{xmb}> ok thxx enemy
[14:39:46 CEST] <durandal_1707> this guy found our native vorbis to be better than libvorbis -- this is enough to warrant special care
[14:47:27 CEST] <durandal_1707> even with mp3 transcoding - what people smoke this days....
[14:47:50 CEST] <furq> 64-bit mp3 is the future
[14:48:01 CEST] <durandal_1707> :)
[14:58:20 CEST] <BtbN> There are people buying 4000¬ switches and weird-plug-directional-lan-cables because it enables better audio flow
[14:58:30 CEST] <BtbN> So nothing surprises me where people claim better audio quality
[15:05:31 CEST] <furq> i've seen a 20+ page long forum thread where people sincerely debate whether aiff sounds better than wav
[15:05:50 CEST] <furq> and anyone going "wtf they're both 16-bit pcm" gets a stern rebuke from the administrators
[16:54:42 CEST] <Hello71> who knows, maybe they're putting in MP3
[16:54:59 CEST] <Hello71> pretty sure riff supports mp3
[18:37:38 CEST] <analogical> when I create a flac file how do I specify the compression leve?
[18:37:52 CEST] <analogical> *level
[18:38:22 CEST] <TheAMM> -q:a <0-9> I'd say
[18:38:30 CEST] <TheAMM> Someone will tell how I'm wrong, soon, so hold on
[18:38:31 CEST] <JEEB> that makes no sense with lossless
[18:38:41 CEST] <analogical> ffmpeg.exe -i test.wav test.flac
[18:38:49 CEST] <JEEB> see the output of
[18:38:53 CEST] <JEEB> ffmpeg -h encoder=flac
[18:39:03 CEST] <JEEB> that lists all of the AVOptions for flac
[18:39:24 CEST] <JEEB> it seems like it throws all the bits and pieces at you
[18:39:35 CEST] <JEEB> instead of having these simple to look at but you don't know the bits and pieces inside
[18:39:43 CEST] <durandal_1707> -compression_level
[18:39:59 CEST] <JEEB> so it's a general avcodeccontext option?
[18:42:01 CEST] <durandal_1707> yes
[18:42:12 CEST] <JEEB> roger
[18:43:01 CEST] <furq> analogical: -compression_level 12 is the highest for flac
[18:48:27 CEST] <analogical> thanks furq
[18:49:26 CEST] <analogical> FFmpeg flac is more efficient than Xiph flac
[18:49:33 CEST] <analogical> strange
[18:54:11 CEST] <durandal_1707> there are other options that make encoder super slow at higher compression ratio
[19:03:20 CEST] <furq> analogical: it depends on the source
[19:03:35 CEST] <furq> i tested a bunch of stuff with ffmpeg -compression_level 12 and flac -8 and it came out about even in the end
[19:05:51 CEST] <analogical> furq, interesting. I also made that comparison and found that FFmpeg achieved slightly better compression at those settings but more importantly the FFmpeg generated file worked better in players with MUCH less cpu usage and no dealys when skipping forward :)
[19:06:14 CEST] <analogical> *skipping ahead
[19:06:46 CEST] <furq> well that part is unexpected
[19:08:30 CEST] <furq> what are you playing that back on
[19:08:39 CEST] <furq> i've never had any noticeable cpu usage or seek delays playing flac
[19:08:52 CEST] <furq> the whole point of flac is that it decodes super fast
[19:09:34 CEST] <analogical> the difference is most noticeable with VLC
[19:10:18 CEST] <furq> i'm going to guess something is just broken there then
[19:12:10 CEST] <Hello71> are you putting it in ogg?
[19:13:15 CEST] <furq> unless you were using --lax or something
[21:55:00 CEST] <RavenWorks> I'm following the instructions to do lossless encoding in H.264, but the results are visibly not identical
[21:55:37 CEST] <RavenWorks> the input video is a series of PNG files, but they don't have any embedded color profile information (that exiftool can see) so I don't think that's the problem?
[21:55:52 CEST] <JEEB> by default the libx264 wrapper doesn't do RGB
[21:55:59 CEST] <RavenWorks> not even in lossless mode?
[21:56:10 CEST] <JEEB> you will have to use the separate "codec" in the wrapper to do RGB specifically
[21:56:19 CEST] <JEEB> I think it's like -c:v libx264rgb or something
[21:56:45 CEST] <JEEB> yea, that seems to be it
[21:57:12 CEST] <RavenWorks> ok, I just saw them mention something about that in the FAQ, but they blame it on pix_fmt but also say that it's the default "now"...
[21:57:13 CEST] <JEEB> the only reason RGB is separated is because people using H.264 for RGB is so limited that it's more likely someone uses it by accident, and thus it was separated
[21:57:35 CEST] <JEEB> you can see most of the internal conversions if there are any with -v verbose added
[21:57:50 CEST] <JEEB> and if your input is RGB and you are using libx264rgb as the encoder, then you shouldn't have an issue?
[21:58:04 CEST] <RavenWorks> I'll give it a shot
[21:59:07 CEST] <furq> JEEB: is that actually the reason
[21:59:23 CEST] <JEEB> furq: unless you can find another one in the commit log,  yes
[21:59:41 CEST] <JEEB> it was literally made so that ffmpeg.c etc wouldn't think "oh I can pass RGB to this thing so I will not do any conversions"
[21:59:54 CEST] <RavenWorks> That did it!! Thanks so much
[21:59:57 CEST] <furq> i guess that sort of makes sense but then it'll just convert to 4:4:4
[22:00:01 CEST] <furq> which is almost as useless
[22:00:22 CEST] <RavenWorks> I guess the wiki should be updated
[22:00:24 CEST] <JEEB> yes, it /almost/ makes sense
[22:00:30 CEST] <JEEB> and as you note, it has its issues :P
[22:03:05 CEST] <RavenWorks> oh, hm, does it take special permissions to edit the wiki?
[22:03:15 CEST] <JEEB> not that I know?
[22:03:19 CEST] <JEEB> although I've never tried
[22:03:26 CEST] <RavenWorks> oh wait no -- the link's just at the bottom, hah
[22:03:26 CEST] <JEEB> I only just herp a derp in issues/bugs
[22:03:34 CEST] <RavenWorks> I figured it would be at the top with everything else
[22:05:52 CEST] <RavenWorks> Should I replace the current thing in the FAQ suggesting -pix_fmt yuv444p, or add this in addition to it?
[22:06:20 CEST] <furq> add it in addition
[22:06:28 CEST] <RavenWorks> ok
[22:06:34 CEST] <furq> there's usually no point using rgb or yuv444p
[22:06:44 CEST] <furq> basically everything expects yuv420p these days
[22:07:14 CEST] <RavenWorks> in my case, I'm just trying to store the raw frames of a render in less hard drive space
[22:07:41 CEST] <RavenWorks> and from there I'll render it out to something useful when actually publishing it
[22:07:41 CEST] <furq> yeah i'm just saying that's a niche use case
[22:08:00 CEST] <RavenWorks> oh, understandably
[22:08:17 CEST] <furq> also if the colours are noticeably different then something probably fucked up in the rgb to yuv conversion
[22:08:32 CEST] <RavenWorks> I just mean, I'm not sure if the yuv444p suggestion belongs there?  if the problem is the RGB to YUV conversion, would yuv444p be enough to fix it?
[22:08:36 CEST] <RavenWorks> it didn't in my case
[22:08:47 CEST] <furq> it'll default to yuv444p anyway
[22:08:57 CEST] <RavenWorks> all the more reason I'm not sure why it's still in the faq
[22:09:09 CEST] <furq> link the page
[22:09:16 CEST] <RavenWorks> ahh, sorry
[22:09:26 CEST] <RavenWorks> https://trac.ffmpeg.org/wiki/Encode/H.264#FAQ
[22:10:00 CEST] <furq> yeah i guess there's no reason for that to be there
[22:10:22 CEST] <furq> but like i said there should nominally only be very minor differences
[22:10:29 CEST] <furq> unless something like the colour primaries got messed up
[22:10:44 CEST] <furq> idk how smart swscale is but i get the impression it's not that smart
[22:10:45 CEST] <RavenWorks> I had to zoom way in, but it introduced some banding in some subtle gradients
[22:11:00 CEST] <furq> yeah that sounds ok then
[22:11:59 CEST] <furq> i would say that if you're going to recommend libx264rgb then also mention that not many decoders support it
[22:12:06 CEST] <furq> but the same is true of high444, which is needed for yuv444p
[22:12:24 CEST] <RavenWorks> the page already mentions that virtually nothing decodes lossless in the first place
[22:12:31 CEST] <furq> that's true
[22:12:48 CEST] <furq> i guess it also mentions that yuv420p is the only thing with good support just below that
[22:12:52 CEST] <RavenWorks> yeah
[22:13:15 CEST] <RavenWorks> I just want to have an archive of the clean frames to make all the published compressed versions from, with ffmpeg
[22:13:56 CEST] <furq> there's obviously advantages and disadvantages of just doing the colourspace conversion now
[22:14:06 CEST] <RavenWorks> I was gonna run optipng on them but then I was like "wait this is literally an animation, something that can refer to previous frames would probably save way more space" and I realised I was thinking of lossless video, heh
[22:14:10 CEST] <RavenWorks> yeah, true enough...
[22:14:12 CEST] <furq> but if disk space isn't an issue then it's not like it takes much cpu time
[22:14:19 CEST] <furq> so there's no harm keeping it as it is
[22:18:09 CEST] <RavenWorks> Alright, wiki updated! Thanks for your help.
[22:34:12 CEST] <newbsduser> hello guys, I have a rtsp:// live stream url. I want to check video output for this stream is healthy or not? How can I do that?
[22:57:49 CEST] <sfan5> throw it into ffprobe?
[22:58:09 CEST] <sfan5> alternatively: use ffmpeg to capture a single frame and verify that it looks fine
[23:05:37 CEST] <Hello71> what are your experiences with aggressive gcc optimizations? https://github.com/InBetweenNames/gentooLTO/issues/103
[23:06:04 CEST] <newbsduser> ffprobe -v quiet -print_format json -show_streams 'rtsp://user:aa@192.168.1.15:554/cam/realmonitor?channel=4&subtype=1'
[23:06:13 CEST] <JEEB> we already disable some optimizations because they generated broken stuff at some point
[23:06:15 CEST] <Hello71> not like -ffast-math. we are discussing testing -O3 -flto -fipa-pta with graphite, but apparently it doesn't work with sse4 intrinsics or something
[23:06:28 CEST] <JEEB> we don't have any intrinsics :)
[23:06:32 CEST] <Hello71> hm
[23:06:33 CEST] <JEEB> only internal asm
[23:06:38 CEST] <JEEB> as in, separate asm files
[23:06:40 CEST] <newbsduser> worked fine for non-existing channel. but I am not it work for every unsuccessful live stream correctly?
[23:06:42 CEST] <JEEB> which get compiled into objects
[23:06:46 CEST] <Hello71> someone claims there are intrinsics
[23:07:06 CEST] <Hello71> I understand that that's different from inline and external asm
[23:07:07 CEST] <JEEB> maybe for non-x86, but even for ARM we are using raw assembly functions
[23:07:09 CEST] <newbsduser> worked fine for non-existing channel. but I am not sure it work for every unsuccessful live stream correctly?
[23:07:37 CEST] <JEEB> the x86 and x86_64 stuff is all separate
[23:07:42 CEST] <JEEB> we don't merge in intrinsics
[23:08:05 CEST] <JEEB> that's the primary reason why not all of the intrinsics from openhevc are in (although partially it's also because the code base has diverted during the last n years)
[23:08:30 CEST] <JEEB> the openhevc people converted some of their intrinsics into separate asm
[23:08:36 CEST] <JEEB> and that I think went in
[23:09:28 CEST] <JEEB> but yea, we have various C compiler optimizations disabled
[23:09:54 CEST] <JEEB> because we had them disabled at some point years ago, then people thought the issues were gone by now, and then it got re-disabled a few weeks later :P
[23:10:28 CEST] <JEEB> so in a standard configuration FFmpeg will disable some of the optimizations for vectorization etc
[23:10:35 CEST] <Hello71> apparently nobody reported https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85132 upstream?
[23:10:51 CEST] <Hello71> tl;dr gcc 8 + ffmpeg 3.4.2 + lto = SIGSEGV in ff_sine_window_init
[23:11:15 CEST] <Hello71> or is hardcoded tables not recommended anymore? if so someone should tell gentoo
[23:12:26 CEST] <JEEB> was it ever explicitly recommended?
[23:12:59 CEST] <atomnuker> nope, it pretty much only for underpowered mips devices, in fact chunks of it were removed some times ago
[23:13:02 CEST] <atomnuker> *time
[23:13:11 CEST] <JEEB> yea I only get configure hits with that
[23:13:24 CEST] <JEEB> both the enable thing
[23:13:33 CEST] <JEEB> and the hardcoded_tables in FEATURE_LIST
[23:13:57 CEST] <JEEB> ok, using -i with grep helped
[23:14:05 CEST] <JEEB> CONFIG_HARDCODED_TABLES
[23:14:36 CEST] <Hello71> well it's still the default for gentoo, and apparently it doesn't work with lto
[23:19:15 CEST] <JEEB> I would first of all test if the issue is still around, and then would report it on trac if it's still there (on master)
[23:19:39 CEST] <JEEB> given that the option is not on by default and the way LTO optimizes changed between gcc 7.x and 8.x (and due to not everyone running LTO) I wouldn't be surprised if nobody noticed :P
[23:46:05 CEST] <cryptodechange> Trying to decide whether or not I should go with Bicubic or Area for downsizing 4k footage to 1080p
[23:46:26 CEST] <cryptodechange> Can't find much reading material comparing the two
[23:46:47 CEST] <JEEB> if you want high quality scaling you'll have to use zscale which uses the zimg library in the background anyways :P
[23:54:30 CEST] <Hello71> JEEB: well clearly someone did notice, just apparently didn't report it?
[23:54:38 CEST] <Hello71> it's still broken
[23:55:03 CEST] <cryptodechange> Interesting, scale uses bicubic as default, zscale uses bilinear?
[00:00:00 CEST] --- Sun Oct 14 2018