[Ffmpeg-devel-irc] ffmpeg.log.20190614
burek
burek021 at gmail.com
Sat Jun 15 03:05:02 EEST 2019
[00:00:54 CEST] <MoziM> kepstin: are there any shows that aren't interlaced?
[00:00:58 CEST] <furq> yes
[00:01:04 CEST] <furq> quite a lot of shows
[00:01:26 CEST] <MoziM> i thought all movies/shows blurred video to some degree
[00:01:30 CEST] <kepstin> MoziM: basically all movies, most non-live hidef tv shows
[00:01:36 CEST] <furq> anything shot on film
[00:01:41 CEST] <MoziM> unless it's cctv footage then interlacing is the norm i thought?
[00:01:52 CEST] <furq> which will be telecined for ntsc broadcast but not on bluray or pal broadcast
[00:01:53 CEST] <MoziM> o kk
[00:02:10 CEST] <kepstin> MoziM: not sure what you mean by "blurred", interlacing and blurring are different things
[00:02:16 CEST] <furq> also more stuff nowadays is just shot at 25/30p on digital
[00:02:29 CEST] <MoziM> you're right, not "blurred"
[00:02:54 CEST] <kepstin> web browsers can't play interlaced video (or at least can't deinterlace it), so basically all web streamed video is progressive rather than interlaced.
[00:03:16 CEST] <kepstin> except when they get it wrong, like the screenshot i pasted earlier ;)
[00:03:19 CEST] <furq> someone should tell everyone who uploads sports videos to youtube that
[00:03:26 CEST] <BtbN> Twitch sometimes gets fed interlaced video from their "professional" events. Looks like shit every time.
[00:03:47 CEST] <furq> i normally have my browser resized vertically so interlaced stuff gets this really unpleasant moiré-ish effect
[00:03:51 CEST] <BtbN> That ONLY affects productions with super high profile, lot of money put into it, production value.
[00:03:52 CEST] <furq> 1080i stuff, that is
[00:04:08 CEST] <furq> pretty much every clip the bbc uploads is like that
[00:04:31 CEST] <kepstin> yeah, live sports are the one weird thing where everybody uses 1080i60 because they decided it was better than 1080p30 or 720p60, and atsc doesn't support 1080p60 iirc
[00:04:40 CEST] <kepstin> for north america anyways ^
[00:06:17 CEST] <kepstin> so the entire reason tvs have fancy hardware motion prediction stuff for those stupid modes that convert film to 60hz or 120hz is because they had to include hardware motion prediction anyways for the deinterlacer so 1080i sports don't look terrible.
[00:07:48 CEST] <JEEB> kepstin: so in the slice header you have field_pic_flag value, and then bottom_field_flag if that is true
[00:14:09 CEST] <ringo_> Hello ... out of luck with format conversion ....using -hwaccel nvdec -hwaccel_output_format uyvy422 will fool the chain but the output on sdi output looks all wrong ... colors, etc
[00:14:12 CEST] <ringo_> smooth but wrong
[00:14:34 CEST] <ringo_> so, we are pretending nvidia returns 422 but it does not
[00:16:17 CEST] <MoziM> the layers of stuff that can make it all look wrong
[00:16:19 CEST] <MoziM> ugh
[00:19:48 CEST] <ringo_> is it possible to make a 420 to 422 converter that is multithreaded? or is the memcpy the bottleneck?
[00:19:53 CEST] <BtbN> cuvid/nvdec simply does not support 422
[00:20:01 CEST] <BtbN> I'm surprised it doesn't just throw an error at you
[00:22:02 CEST] <BtbN> What codec is that?
[00:22:14 CEST] <ringo_> yuv
[00:22:18 CEST] <BtbN> that's not the codec...
[00:22:25 CEST] <ringo_> source files are hevc
[00:23:03 CEST] <ringo_> for example
[00:23:04 CEST] <ringo_> Video: hevc (Main 10) ([36][0][0][0] / 0x0024), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x2160 [SAR 1:1 DAR 16:9], 59.94 fps, 59.94 tbr, 90k tbn, 59.94 tbc
[00:23:15 CEST] <BtbN> That's 420 though, not 422
[00:23:34 CEST] <ringo_> that file needs to be decoded and output on decklink SDI output
[00:23:41 CEST] <ringo_> decklink only supports 422
[00:23:57 CEST] <ringo_> uyvy422
[00:24:31 CEST] <BtbN> You'll have to send it through the format filter then
[00:25:19 CEST] <ringo_> I can decode using nvidia gpu
[00:25:38 CEST] <ringo_> and then when I pass it through the format filter, one cpu is maxed out
[00:25:45 CEST] <ringo_> and output drop frames, etc
[00:25:54 CEST] <BtbN> You'll need a more powerful CPU then
[00:26:08 CEST] <BtbN> The GPU can't help you with that. Not unless someone write a filter that does specifically that conversion.
[00:26:18 CEST] <ringo_> I am already using a Intel(R) Core(TM) i7-7820X CPU @ 3.60GHz
[00:26:30 CEST] <ringo_> I am already using an Intel(R) Core(TM) i7-7820X CPU @ 3.60GHz
[00:26:58 CEST] <BtbN> converting 4K, 60fps in real time is probably not happening then
[00:27:10 CEST] <ringo_> GPU will of course help in the conversion from hevc to uncompressed
[00:27:59 CEST] <BtbN> This will be this horrible because the conversion you are doing is not really a very common one, so there won't be too much SIMD for it
[00:28:06 CEST] <ringo_> but then, the conversion of pixel format seems to be single threaded .. once cpu at 100% and all others under 5%
[00:28:10 CEST] <BtbN> It will probably do a 3 way conversion
[00:28:59 CEST] <ringo_> 4k 60 in real time happens over HDMI ... because inside the card there is no bottleneck on pixel format conversion
[00:29:27 CEST] <BtbN> Can't that thing take a more common pixel format?
[00:29:54 CEST] <BtbN> 4K60 is also some serious bandwidth just to copy it around in RAM
[00:30:26 CEST] <ringo_> no, for some reason the blackmagic card can only take uyvy422 ... maybe I need to explore other vendors ... aja, dektek, bluefish
[00:31:09 CEST] <BtbN> Interleaving several gigabytes of data per second IS horribly expensive
[00:32:27 CEST] <BtbN> If you just want 4K60 out via HDMI... why not use any somewhat modern graphics card?
[00:33:35 CEST] <ringo_> I already have a quadro rtx 4000 ... and I do not want 4k60 over hdmi ... I want 4k60 over HD-SDI
[00:34:02 CEST] <BtbN> The path of least resistance might still be an HDMI to SDI converter then
[00:34:41 CEST] <ringo_> someone else is doing it with the exact same combination of hardware under windows
[00:35:09 CEST] <ringo_> so, they must have coded an effective multithreaded pixel format converter
[00:35:38 CEST] <ringo_> the CPU can do it under linux for 4k30 ... but it maxes out for 4k60
[00:36:14 CEST] <BtbN> Doesn't even need to be multi-threaded
[00:36:34 CEST] <ringo_> true ... it just needs to be fast enough
[00:36:44 CEST] <BtbN> but what libswscale will be doing is convert to a common abstract base pixel format from whatever input format, and then convert that to the target format
[00:37:00 CEST] <BtbN> Because there is no direct conversion for those unusual formats
[00:37:06 CEST] <BtbN> specially with one of them being 10 bit and one 8 bit
[00:37:24 CEST] <ringo_> I think decklink also supports 10 bit output
[00:37:39 CEST] <BtbN> uyvy422 is an 8 bit format though
[00:39:58 CEST] <ringo_> let me look at the code again ...
[00:40:01 CEST] <ringo_> 175 if (c->codec_id == AV_CODEC_ID_WRAPPED_AVFRAME) {
[00:40:01 CEST] <ringo_> 176 if (c->format != AV_PIX_FMT_UYVY422) {
[00:40:01 CEST] <ringo_> 177 av_log(avctx, AV_LOG_ERROR, "Unsupported pixel format!"
[00:40:01 CEST] <ringo_> 178 " Only AV_PIX_FMT_UYVY422 is supported.\n");
[00:40:01 CEST] <ringo_> 179 return -1;
[00:40:02 CEST] <ringo_> 180 }
[00:40:04 CEST] <ringo_> 181 ctx->raw_format = bmdFormat8BitYUV;
[00:40:06 CEST] <ringo_> 182 } else if (c->codec_id != AV_CODEC_ID_V210) {
[00:40:08 CEST] <ringo_> 183 av_log(avctx, AV_LOG_ERROR, "Unsupported codec type!"
[00:40:12 CEST] <ringo_> 184 " Only V210 and wrapped frame with AV_PIX_FMT_UYVY422 are supported.\n");
[00:40:14 CEST] <ringo_> 185 return -1;
[00:40:15 CEST] <BtbN> ...
[00:40:16 CEST] <pzich> please do not paste code here!
[00:40:16 CEST] <ringo_> 186 } else {
[00:40:18 CEST] <ringo_> 187 ctx->raw_format = bmdFormat10BitYUV;
[00:40:20 CEST] <ringo_> 188 }
[00:40:40 CEST] <ringo_> sorry ... I did not know it was not allowed
[00:40:58 CEST] <ringo_> to me code is almost like english language as I look at it all day :)
[00:41:05 CEST] <BtbN> spamming a channel for a minute is just a bad idea and annoying
[00:41:34 CEST] <ringo_> understood
[00:41:48 CEST] <BtbN> It's only instant for you, the rest gets it in ~1 line per second
[00:42:08 CEST] <ringo_> indeed
[00:43:27 CEST] <ringo_> how do I force the output to be a non wrapped frame with pixel format bmdFormat10BitYUV?
[00:43:49 CEST] <BtbN> That's the V210 case
[00:43:56 CEST] <ringo_> no, it is not
[00:44:03 CEST] <BtbN> Yes it is, the check is != V210
[00:44:11 CEST] <BtbN> so that else case is for when it actually is V210
[00:44:12 CEST] <ringo_> ahhh ... yes
[00:45:40 CEST] <BtbN> I'd really just get a Mini-HDMI-To-SDI box. Probably even cheaper than whatever you're using right now.
[00:46:26 CEST] <ringo_> 12G converters are about $500
[00:46:47 CEST] <BtbN> Those Decklink output cards aren't much cheaper, are they?
[00:47:05 CEST] <ringo_> about $600
[00:47:38 CEST] <ringo_> but they are bidirectional, so you can use them to encode as well
[00:47:56 CEST] <BtbN> Why on earth do they only take 422 though?
[00:48:07 CEST] <BtbN> In that weird format even
[00:48:15 CEST] <ringo_> 422 and V210 aparently
[00:50:03 CEST] <ringo_> so, writing one or more filters that convert direclty to these formats might be enough? ... it would save half the processing cpu cycles
[00:51:38 CEST] <ringo_> sources will be hevc or h264 .... 420 8 or 10 bit 99% of the time
[00:54:34 CEST] <BtbN> Pretty much
[00:54:51 CEST] <BtbN> could also write them using CUDA, if you're using nvidia GPUs anyway
[00:55:13 CEST] <BtbN> Should be an easy task for a GPU
[00:56:38 CEST] <BtbN> CUDA can also do the conversion straight to system RAM, saving a copy in the process
[00:56:45 CEST] <BtbN> But that would be a very specialized filter
[00:56:57 CEST] <ringo_> scale_npp supports several ...but not this 422
[00:57:12 CEST] <BtbN> Nothing from nvidia supports 422, so that's not overly surprising
[00:57:39 CEST] <ringo_> but you can still write the filter using the cuda SDK and stay in the GPU memory space?
[00:57:52 CEST] <BtbN> You'd need to write the CUDA Kernel yourself though
[00:59:02 CEST] <ringo_> That goes beyond my skills .... I think I might barely be able to write a normal filter
[00:59:27 CEST] <BtbN> It's primarily an insane amount of boilerplate for maybe a handful of lines that do the actual conversion
[01:00:34 CEST] <ringo_> I am willing to sponsor the work if you or someone wants to do it ... to be put into ffmpeg of course for others to use
[01:02:01 CEST] <BtbN> You could put it on trac as feature request and mark it as bounty
[01:02:16 CEST] <BtbN> not sure how actively trac is used for that purpose though
[01:03:25 CEST] <ringo_> what is the link to trac? I can take a look for other bounties to see how effective it i
[01:03:38 CEST] <BtbN> see topic
[01:04:20 CEST] <ringo_> ok, saw it!
[11:37:08 CEST] <zerodefect> With most subtitle files, I can do something like 'ffmpeg -i subtitle.ass subtitle.srt' to convert the input subtitle file it into a different format. Now, I'm trying to do the same thing for a .PAC subtitle file, but I get an error 'Invalid data found when processing input'.
[11:37:18 CEST] <zerodefect> I notice in 'libavcodec/ccaption_dec.c' there is a method called 'handle_PAC'
[12:44:30 CEST] <realies> can you use ffprobe to figure out what should be the file extension of the file?
[13:24:13 CEST] <void09> how to get size of video file up to frame number N or timestamp ?
[13:24:42 CEST] <zerodefect> @realies, no luck. Receive "/media/sf_SharedFolder/IIF17012320.pac: Invalid data found when processing input" with ffprobe too.
[14:26:18 CEST] <realies> zerodefect :o
[15:54:44 CEST] <void09> how to get size of video file up to frame number N or timestamp ?
[15:58:16 CEST] <zerodefect> @void09 - AVPacket has a member called 'pos'. Try that.
[16:11:30 CEST] <void09> zerodefect: sorry but I have no idea what you are talking about
[16:11:58 CEST] <zerodefect> Are you using C-API or FFmpeg cmd line?
[16:12:04 CEST] <void09> ffmpeg command line
[16:12:33 CEST] <zerodefect> Ok. Ignore me then.
[16:22:15 CEST] <kepstin> void09: copy the video to a new file up to that frame or timestamp, and then see how big it is, i guess?
[16:22:31 CEST] <kepstin> (you might even be able to copy to nowhere, and use the ffmpeg stats output)
[16:29:33 CEST] <void09> kepstin: cool, how do I do that? :P
[16:30:02 CEST] <kepstin> void09: use "-c copy -f null -" as the output part of your ffmpeg command
[16:30:55 CEST] <kepstin> although note that that will only show the stream sizes, it won't include container overhead
[16:31:38 CEST] <void09> i already know the container overhead
[16:32:06 CEST] <void09> but where do i enter the frame nmber or timestamp?
[16:32:35 CEST] <kepstin> using the -t or -vframes option, same as any normal transcode
[16:36:03 CEST] <void09> Element at 0x377b234 ending at 0x377b4c9 exceeds containing master element ending at 0x377b22e
[16:36:17 CEST] <void09> i entere this command: ffmpeg -i output.mkv -c copy -f null - -vframes 2967
[16:40:26 CEST] <kepstin> void09: output options go *before* the output filename
[16:40:30 CEST] <kepstin> which is "-" here
[16:40:44 CEST] <kepstin> (and that warning message is unrelated, that's a problem with your input file)
[17:07:43 CEST] <FishPencil> Is Android officially supported as a target?
[17:08:22 CEST] <durandal_1707> no
[17:11:43 CEST] <JEEB> FishPencil: yes sibce we have mediacodwc etc. for the libraries at least
[17:12:13 CEST] <JEEB> otherwise quite a few android apps wouldn't be able to play video or audio :p
[17:13:11 CEST] <JEEB> also i think fate has ndk boxes
[17:14:24 CEST] <FishPencil> Was durandal_1707 kidding then?
[17:18:00 CEST] <durandal_1707> i'm not aware that android is supported as build target
[17:19:20 CEST] <durandal_1707> there is certainly some android stuff supported for sure, but i dunno is that enough
[18:11:04 CEST] <JEEB> durandal_1707: there's really nothing special required for android
[18:11:15 CEST] <JEEB> NDK is nowadays relatively modern clang with the android libc
[18:11:27 CEST] <JEEB> the only thing we don't support is the custom makefile crap that GOOG is trying to pollute things with
[18:11:38 CEST] <JEEB> (like, android specific makefiles)
[18:11:47 CEST] <JEEB> but this is the same with MSVC etc
[18:11:51 CEST] <JEEB> you use *our* build system
[18:12:19 CEST] <JEEB> durandal_1707: you can see an example of how to build for android with https://kuroko.fushizen.eu/docs/buildan_mpv_android.txt
[18:12:31 CEST] <JEEB> ctrl+F FFmpeg
[18:13:11 CEST] <JEEB> target-os is android, and then you set your cross-prefix to the right one
[18:13:36 CEST] <JEEB> (and because the CC/CXX are clang/clang++ you set clang/clang++ as --cc and -cxx
[18:13:48 CEST] <JEEB> and as I noted, I'm pretty sure we have NDK in FATE
[18:14:13 CEST] <JEEB> or at least we used to have
[18:14:54 CEST] <JEEB> ok, seems like current FATE has no NDK :/
[19:05:40 CEST] <shockeroo> Hi all! Total newbie here. My encoding settings seem to be forcing 16:9 video to create 4:3 videos with a black strip at the top. I'm pretty sure I need to change/remove my use of scale and/or trunc. Can anybody point me in the right direction here please? My arguments are: -vcodec libx264 -vf "scale=min(640\,iw):trunc(ow/a/2)*2" -vb 800k -acodec aac -ab 96k -ar 44100 -f mp4
[19:08:47 CEST] <DHE> I think you just want scale=min(640\,iw):-2
[19:09:36 CEST] <DHE> still, that doesn't explain black bars and an aspect ratio change. unless of course the source already had that
[19:10:57 CEST] <shockeroo> No, it's doing it to all my 16:9 videos and none of them had black bars in the source. I'll try your recommended setting, thanks.
[19:14:56 CEST] <Hello71> also you need single quotes in shell
[19:16:39 CEST] <shockeroo> Thank you. I'm using a front-end/script called "cumulusclips" and these are the default encoding options. Are you saying I should replace uses of " with ' ?
[19:27:13 CEST] <kepstin> the quotes shouldn't change anything. you would have probably gotten a syntax error if that was wrong (the usual issue is that the \, doesn't get passed through properly)
[19:28:20 CEST] <kepstin> I assume the reason for the calculation on the frame height is to turn anamorphic videos into 1:1 sar
[19:28:44 CEST] <kepstin> it all looks correct, nothing in that command would be changing display aspect ratio or adding black bars to video.
[19:31:09 CEST] <Atlenohen> Hello
[19:31:28 CEST] <Atlenohen> So is it good to use preset ultrafast with x264 lossless mode ?
[19:31:42 CEST] <Atlenohen> as in to do as less compression artifacts as possible?
[19:32:31 CEST] <Atlenohen> Or is there some things that would increase quality, ... this whole compression stuff is quite complicated, I think I researche and looked videos about it in the past but forgot
[19:33:12 CEST] <DHE> lossless is lossless no matter the preset. but higher presets will still produce smaller files
[19:33:46 CEST] <Atlenohen> oh, allright
[19:34:19 CEST] <another> see also https://trac.ffmpeg.org/wiki/Encode/H.264
[19:35:50 CEST] <shockeroo> Hm it looks like I might be having a problem with how cumulusclips embeds videos rather than with the actual encoding. Thanks for your help all; I think I need to know what I should be working on now.
[19:54:19 CEST] <Atlenohen> I tried both ... yeah for a 2 minute excerpt, very slow took like 15 mins while ultrafast was almost instant, 100 Megabyte difference, 300 vs 400 MB
[19:55:03 CEST] <Atlenohen> would definitely made a difference at larger sizes indeed
[19:56:05 CEST] <furq> Atlenohen: normally there isn't a linear relationship between preset and size because the quality will change depending on the preset
[19:56:11 CEST] <furq> but obviously for lossless you can't really change the quality
[19:56:42 CEST] <aan3k> German Wikipedia says ogg is directly streamable. mkv only with specific settings and mp4 isn't streamable at all ... Have I missed something? I thought mp4 is streamable
[19:57:18 CEST] <furq> also fwiw i normally use -preset ultrafast -coder cabac
[19:57:49 CEST] <furq> cabac makes a much bigger difference than any other setting in my experience
[19:58:29 CEST] <furq> aan3k: you can't stream (non-fragmented) mp4 on the fly because the header isn't written until the end
[19:59:01 CEST] <furq> obviously for vod and stuff that doesn't matter
[20:00:31 CEST] <aan3k> Oh, didn't knew. Thanks. Isn't a VOD streamed too?
[20:00:37 CEST] <Atlenohen> takes the sense out of a header doesn't it :)
[20:01:11 CEST] <furq> tbf they call it an atom, not a header
[20:01:16 CEST] <DHE> yes, but "vod" is pre-rendered so the header was written a long time ago
[20:01:30 CEST] <furq> aan3k: in one sense of the word, yes
[20:01:32 CEST] <furq> but not the same sense
[20:01:53 CEST] <aan3k> ah ok, got you. Thanks :)
[20:02:19 CEST] <Atlenohen> still the player can't play until it parses the whole file so it reads the header/atom at the back rihgt
[20:02:32 CEST] <furq> technically yes but practically no
[20:02:38 CEST] <aan3k> so "livestreaming" and "demandstreaming" would differ it more nicely?!
[20:02:49 CEST] <furq> if you mean for vod then any decent player will just range request the last 1MB or so and find the moov atom in there
[20:03:13 CEST] <furq> aan3k: something like that, yeah
[20:03:29 CEST] <furq> if the file already exists then mp4 will do whatever you want
[20:03:37 CEST] <furq> in fact it's the only thing supported by every browser for that
[20:04:19 CEST] <furq> if it's being generated on the fly then it's unplayable unless you write some kind of dummy moov atom or you use fragmented mp4
[20:04:34 CEST] <kepstin> Atlenohen: for making mp4 files intended for vod streaming, you'll usually post-process the mp4 to move the moov to the start of the file (ffmpeg has builtin support for that, "-movflags faststart")
[20:04:39 CEST] <furq> yeah that too
[20:04:48 CEST] <furq> but even if it's at the end it doesn't really matter any more
[20:05:49 CEST] <kepstin> should reduce a server round trip, but yeah pretty minimal gains esp. with http2 or request pipelining.
[20:08:20 CEST] <furq> yeah it's nice to have but it's not like you still need to download the entire file before you can play it
[20:08:23 CEST] <furq> like in the good old days
[20:30:56 CEST] <Atlenohen> Well wait
[20:31:14 CEST] <Atlenohen> it's not seeking good in Adobe Premiere Pro ... shouldn't I do I frames only too ?
[20:31:50 CEST] <Atlenohen> I think the veryslow actually performs a bit faster in Premiere, seek and stabilization (wich takes a shitload of RAM continually)
[20:32:12 CEST] <JEEB> if you want fast seeking the tune fastdecode and short (3-5 frame) GOPs are probably pretty good
[20:32:21 CEST] <JEEB> *then
[20:32:23 CEST] <roxlu> hi, I asked this in #ffmpeg-devel, but I just learned that's the wrong channel .. (sorry for crossposting)
[20:32:38 CEST] <JEEB> roxlu: anyways https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html
[20:32:48 CEST] <roxlu> thanks
[20:32:48 CEST] <JEEB> this is the docs related to the push/pull APIs for decoding and encoding :)
[20:32:54 CEST] <JEEB> wm4 wrote nicely
[20:32:58 CEST] <JEEB> <3
[20:33:24 CEST] <JEEB> it's not async, but at least it separates pushing stuff to the decoder/encoder and receiving data from it
[20:34:19 CEST] <roxlu> ok I see the high-level usage. pretty clear
[20:36:12 CEST] <roxlu> I'm not sure how that fits in with an OS audio callback exactly. Would I send (encoded) audio frames from the user thread (e.g. a game/event loop) and in my audio callback call `avcodec_receive_frame()` ?
[20:37:13 CEST] <Atlenohen> Wait, -g is deprecated ?
[20:38:00 CEST] <kepstin> i don't think it's safe to call the send/receive functions from different threads.
[20:38:24 CEST] <kepstin> but you can transfer an avpacket or avframe from one thread to another without issue
[20:38:55 CEST] <kepstin> Atlenohen: the -g option to get gop size isn't deprecated, what gives you that idea?
[20:38:58 CEST] <kepstin> to set*
[20:39:09 CEST] <roxlu> kepstin: ok thanks, does this imply that one basically has to do the decoding in one thread; buffer the decoded packets and put them in a queue; then read from that queue in the audio callback?
[20:39:11 CEST] <Atlenohen> some random stackoverflow post
[20:39:33 CEST] <kepstin> roxlu: that's probably how i'd do it, yeah.
[20:40:24 CEST] <JEEB> Atlenohen: there can be wrappers for encoders that just don't read the AVCodecContext value but most definitely the actual value is not deprecated
[20:40:31 CEST] <JEEB> (that's what the -g option sets in FFmpeg)
[20:40:35 CEST] <JEEB> *ffmpeg.c
[20:40:45 CEST] <Atlenohen> Source is youtube 1080p - Stream #0:0(eng): Video: vp9 (Profile 0), 1 reference frame, yuv420p(tv, bt709), 1920x1080, SAR 1:1 DAR 16:9, 25 fps, 25 tbr, 1k tbn, 1k tbc (default)
[20:41:15 CEST] <saml> VP9
[20:41:18 CEST] <roxlu> Ok thanks, that would probably work. And you said I can queue AVFrame objects and share them between threads?
[20:42:12 CEST] <friendofafriend> I'm streaming scanner audio to an Icecast server, so the audio is periodic. Is there a way to mix silence and a named pipe so my feed is continuous?
[20:42:15 CEST] <davis> hello
[20:42:41 CEST] <Atlenohen> apparently VP9 has better quality at lower bitrate than than H264, but I could get the H264 source at 1080p too if you guys think that's a better choice
[20:43:06 CEST] <davis> im trying to write three ffmpeg commands. The commands are sequenced to get my desired output. The first one converts pcm file to wav. This appears to work
[20:43:33 CEST] <davis> the second script would mix wav files into one wav file. this does not work.
[20:43:46 CEST] <davis> i get an error about invalid data.
[20:43:59 CEST] <JEEB> friendofafriend: I would probably write a daemon that would run 24/7 with the API, and then you could pass it inputs that it would stream until they end
[20:44:01 CEST] <Atlenohen> saml, does it really matter, Adobe Premeiere gets fed H264, unless you think it matters for ffmpeg VP9 decoder ?
[20:44:03 CEST] <JEEB> with a playlist, possibly
[20:44:26 CEST] <JEEB> actually, I'd be surprised if there wasn't such a thing already using the FFmpeg APIs
[20:45:11 CEST] <JEEB> since all you need are pre-generated samples of nothing, and then you start feeding decoded samples as you get onto the playlist
[20:45:27 CEST] <JEEB> and then fall back into nothingness when playlist is finished
[20:45:34 CEST] <davis> im doing this to convert the pcm to wav
[20:45:35 CEST] <davis> ffmpeg -f s32le -ar 16k -y -i /tmp/one.pcm -ac 1 -f s32le -ar 16k /tmp/two.wav
[20:46:04 CEST] <davis> i'm reading a audio pcm file which is stereo but one channel is padded as zeros.
[20:46:26 CEST] <davis> i believe i'm writing a wav file which is mono in same format.
[20:46:54 CEST] <saml> Atlenohen, I was just repeating after vp9 in ffmpeg/ffprobe output. ignore me
[20:47:24 CEST] <Atlenohen> Wikipedia states CABAC requires much more processing power to decode, so I guess I shouldn't use that then if I want fastseek in Premiere pro right furq?
[20:47:26 CEST] <furq> davis: -ac 1 downmixes
[20:47:37 CEST] <furq> if you want to just ignore one channel then use -map_channel or -af pan
[20:47:43 CEST] <JEEB> Atlenohen: that's what tune fastdecode does in libx264
[20:47:46 CEST] <JEEB> it switches to CAVLC
[20:47:55 CEST] <JEEB> also it only helps with software decoding, not hardware decoding
[20:47:59 CEST] <kepstin> davis: the issue is that you haven't specified the number of channels on the input, so it's using the default '1'
[20:48:48 CEST] <davis> so, that command seems to work
[20:49:08 CEST] <kepstin> davis: right now that command's reading the raw pcm stream as if it was 1 channel, downconverting to 1 channel (a no-op), then saving the result as a single-channel wav
[20:49:10 CEST] <davis> it does not generate an error, but is the wav file output valid? it appears so
[20:49:23 CEST] <davis> kepstin: so that is good
[20:49:30 CEST] <kepstin> assuming it's interleaved samples, the result will be a single-channel wav which plays at 1/2 speed
[20:49:40 CEST] <davis> let me show the second command which fails.
[20:49:56 CEST] <davis> kepstin: ahh, perhaps I should remove the -ac 1 in output?
[20:50:03 CEST] <kepstin> davis: is the input stereo?
[20:50:27 CEST] <davis> the iput is stereo with only one channel having data. the other channel is all 0
[20:50:44 CEST] <kepstin> davis: if so, you need to add the "-channels 2" input option, so ffmpeg reads it as a stereo stream. Then use the options furq mentioned to drop the extra channel.
[20:51:12 CEST] <kepstin> davis: don't use -ac 1 - that'll mix the two input channels together, instead of dropping one.
[20:51:19 CEST] <davis> ahh
[20:52:41 CEST] <davis> ok, i made adjustments. i'm trying a few things. bbiab
[20:53:28 CEST] <davis> im dong this now
[20:53:29 CEST] <davis> ffmpeg -f s32le -ar 16k -y -i /tmp/oneb.pcm -f s32le -ar 16k /tmp/oneb.wav
[20:54:51 CEST] <kepstin> right, that's copying all of the contents of all channels of the pcm input file into a single channel in the output wav file.
[20:54:58 CEST] <furq> -f s32le is just writing raw pcm data to a file with a .wav extension
[20:55:02 CEST] <furq> it's not an actual wav file
[20:55:06 CEST] <kepstin> oh, yeah
[20:55:18 CEST] <furq> you want -c:a pcm_s32le (if wav even supports that)
[20:55:28 CEST] <another> it does
[20:55:28 CEST] <kepstin> so that's just a weird way to write "cp oneb.pcm oneb.wav" ;)
[20:55:52 CEST] <davis> hmm. perhaps I should state my goal
[20:56:14 CEST] <davis> i want to take multiple pcm files, convert to wav as first step
[20:56:46 CEST] <davis> take a mix of the wav files and then mix them together to create a new wav file. mix.wav
[20:57:03 CEST] <davis> last step would be to convert the mix.wav to mix.pcm.
[20:57:20 CEST] <furq> if you're planning on doing all this with ffmpeg then you don't need the intermediate wavs at all
[20:57:20 CEST] <davis> and have mix.pcm as the same format as the original pcm files.
[20:57:31 CEST] <kepstin> dunno why you want multiple steps there, that's doable in a single command
[20:58:01 CEST] <furq> unless you want the wavs to do some editing with a different tool
[20:58:03 CEST] <davis> i was using the wav files to get audio so i could play them. it appears that my python code can not read pcm.
[20:58:25 CEST] <davis> in python when i read as wav I could make graphs/plots
[20:58:35 CEST] <kepstin> davis: the important pieces of information you need to provide to ffmpeg about the pcm audio is the * number of channels * sample format * sample rate
[20:58:46 CEST] <davis> gotcha
[20:58:57 CEST] <davis> btw, if I make a gist, can you guys read it?
[20:59:17 CEST] <furq> raw s32le is just a bunch of 32-bit ints
[20:59:24 CEST] <furq> so a plotting library should be able to handle that just fine
[21:02:54 CEST] <davis> this is gist of the three ffmpeg scripts
[21:02:55 CEST] <davis> https://gist.github.com/netskink/e9c079dcce69be045cbd39f0c6d89d4f
[21:03:38 CEST] <furq> yeah the second script can both input and output raw pcm
[21:03:46 CEST] <davis> so looking back at scrollback, the step1.sh was just a fancy cp?
[21:04:01 CEST] <furq> yeah but it's redundant even if you fix it
[21:04:24 CEST] <kepstin> davis: yes, since you used -f s32le, it wrote raw s32le instead of wav
[21:05:58 CEST] <davis> so would that be a correct step1.sh after the update?
[21:06:01 CEST] <kepstin> davis: with those commands i'd expect step 2 to give an error since the input files weren't wav files.
[21:06:31 CEST] <davis> i believe it does
[21:06:33 CEST] <kepstin> davis: correction is to delete step 1, and add "-f s32le -ar 16k -channels (something)" before each input in step 2
[21:06:54 CEST] <davis> ahh
[21:06:58 CEST] <kepstin> and change it to use the .pcm filenames, of course
[21:08:52 CEST] <kepstin> and optionally you can delete step 3 and make step 2 output the raw pcm directly, if you like.
[21:08:54 CEST] <davis> hmm. if I makde -c:a pcm_s32le step1.sh mod, it runs, then it fixes error with step2.sh and finally step3.sh runs
[21:10:33 CEST] <kepstin> davis: you still need to fix the issue where you're not specifying -channels on any of the raw pcm inputs
[21:10:56 CEST] <kepstin> (reminder that the default is 1, so if your inputs are stereo you need to explicitly specify 2)
[21:12:03 CEST] <davis> ok
[21:12:13 CEST] <davis> since this script combination is running
[21:12:29 CEST] <davis> i'm trying to see if I can play the intermediate files in a player
[21:12:31 CEST] <davis> one moment
[21:13:32 CEST] <kepstin> if the input is stereo, i'd expect the intermediate wavs to play at 1/2 speed with high-frequency noise.
[21:14:10 CEST] <kepstin> well, at 16khz, it'll be kinda midrange noise tbh
[21:16:33 CEST] <davis> cool, the wav files and the final wav file sound correct
[21:16:51 CEST] <kepstin> then your raw pcm files were 1 channel to start with.
[21:17:18 CEST] <davis> ahh
[21:17:28 CEST] <davis> i did not create the original pcm files
[21:17:58 CEST] <davis> i asked the guy and he said they were stereo with one channel zero
[21:18:04 CEST] <kepstin> the other option is that the original pcm files were actually s16le stereo
[21:18:30 CEST] <davis> its odd, though, my originals are 64K and my final is not
[21:18:49 CEST] <davis> let me read your scrollback
[21:18:50 CEST] <davis> one sec
[21:18:55 CEST] <kepstin> if you read s16le stereo with one channel as all 0s as if it was s32le mono, the result will be a perfectly fine mono signal with weird levels
[21:19:03 CEST] <kepstin> i think
[21:19:14 CEST] <kepstin> might depend on channel order and other weirdness, but w/e
[21:19:21 CEST] <kepstin> s32le is an unusual format to start with
[21:20:16 CEST] <davis> "the important pieces of information you need to provide to ffmpeg about the pcm audio is the * number
[21:20:19 CEST] <davis> of channels * sample format * sample rate"
[21:20:40 CEST] <davis> is there anyway to determine that from the file itself?
[21:20:44 CEST] <davis> the original pcm file?
[21:22:57 CEST] <davis> that is an octal dump in hex mode of the file
[21:23:08 CEST] <davis> or at least first line
[21:25:38 CEST] <davis> so it looks like my mix.wav is 32k
[21:26:05 CEST] <kepstin> huh, that alternating 8000 and 0000 is kinda weird
[21:26:47 CEST] <davis> so the original are 64k, the wav versions are 64k, the mix is 32k, so when the file is created as a pcm, it is 64k
[21:27:13 CEST] <davis> is there a good tool for displaying audio waveforms you recommend?
[21:27:55 CEST] <kepstin> davis: i'd guess your input data is 2-channel s16le
[21:28:47 CEST] <kepstin> simply because s16 is by *far* the most common sample format, and your file has an alternating pattern going on every 16 bits.
[21:30:28 CEST] <davis> yah, don't know
[21:30:38 CEST] <davis> i'm trying to open with audacity to examine there
[21:30:41 CEST] <davis> one moment
[21:30:56 CEST] <kepstin> that's the thing about raw data, you can't do anything with it unless you know the details about how it was encoded
[21:31:49 CEST] <ASAMIR___> Hi
[21:32:41 CEST] <ASAMIR___> I'm looking for the reference frames for motion vectors
[21:33:28 CEST] <davis> wow, this is making my head hurt
[21:33:34 CEST] <davis> kepstin: i really appreciate it
[21:33:48 CEST] <davis> i'm going to get some lunch, take a break and return
[21:34:06 CEST] <davis> fwiw, in audacity all the files are one second in audio
[21:34:20 CEST] <ASAMIR___> As the only a parameter which is related to motion vectors is a variable which specifies if the reference frame is either one of the previous frames or the following ones
[21:34:23 CEST] <davis> but for some reason the mix.wav file is not the same size as the original.
[21:34:30 CEST] <kepstin> davis: well, you've used -t 1 on some of those commands, so ffmpeg would have cut them off after 1 second
[21:34:36 CEST] <ASAMIR___> I have been hacking at this for almost two weeks now
[21:34:45 CEST] <ASAMIR___> So I appreciate any help
[21:34:48 CEST] <kepstin> different since probably means different sample format, maybe your mixed wav was saved as 16bit?
[21:35:03 CEST] <davis> yes, the -t 1 was to keep all audio as one second
[21:35:17 CEST] <davis> i think its before that
[21:35:35 CEST] <kepstin> ASAMIR___: references always refer to previous frames (in dts order), you can't reference frames that haven't been decoded yet
[21:36:04 CEST] <davis> the mix.wav was created form the input wav files. the inputs were 64k, the output was 32k.
[21:36:25 CEST] <kepstin> davis: does your gist show the commands you just ran?
[21:36:40 CEST] <davis> the mix does not specify the output format
[21:36:55 CEST] <davis> let me check to see if .sh files match the gist
[21:36:58 CEST] <davis> one moment
[21:37:03 CEST] <kepstin> davis: the default codec for wav if unspecified is pcm_s16le
[21:37:13 CEST] <davis> hmm
[21:37:20 CEST] <davis> so perhaps i need to adjust that
[21:37:22 CEST] <davis> one moment
[21:37:31 CEST] <ASAMIR___> kepstin: Yeah I know that reference frames are decoded first. But I want to get their index with respect to the order of display (POC) and it's not available in the AVMotionVector struct
[21:38:52 CEST] <kepstin> ASAMIR___: looks like that information is simply not available.
[21:38:57 CEST] <ASAMIR___> kepstin: There is a field for the direction but it has +/-1 values only.
[21:39:47 CEST] <ASAMIR___> kepstin: Yes I want to implement. I think it has a todo comment in the AVMotionVector struct.
[21:40:27 CEST] <ASAMIR___> kepstin: I think it has to be available because it must be used to calculate the actual frame. It's just not exposed.
[21:41:31 CEST] <davis> hmm.
[21:41:57 CEST] <davis> now it does mix.wav as 64102 bytes instead of 32k
[21:42:21 CEST] <kepstin> davis: wav has a header in addition to the actual data contents
[21:42:46 CEST] <davis> ill put my .sh files in the gist
[21:42:48 CEST] <davis> one moment
[21:43:03 CEST] <kepstin> ASAMIR___: fixing that will require diving into the code for individual decoders to find and expose the information. maybe a better discussion topic for #ffmpeg-devel
[21:45:02 CEST] <ASAMIR___> I'm already knee deep in the code and gone through the whole code but I've been stuck for a long time and I cannot advance more without asking someone so can you suggest me anyone to help? I've already got two arrays which seems to contain the reference frames lists but their numbers doesn't make much sense.
[21:45:03 CEST] <davis> ok they are updated
[21:45:16 CEST] <davis> now, when i pasted them, i see a few problems which i learned from you
[21:45:21 CEST] <davis> one moment, i'll correct
[21:46:46 CEST] <friendofafriend> What's the new option to loop an input file forever? -stream_loop and -loop aren't working.
[21:46:48 CEST] <ASAMIR___> If you could even point me to where are the frames actually calculated from motion vectors + residuals to produce the final cur_pic which contains the final frame
[21:47:31 CEST] <kepstin> ASAMIR___: i wouldn't know, i've never worked on decoders. but you should probably start by saying which decoder you're looking at.
[21:48:04 CEST] <ASAMIR___> kepstin: H264 decoder
[21:48:11 CEST] <kepstin> friendofafriend: -stream_loop should be working, what problem are you having with it?
[21:49:28 CEST] <friendofafriend> kepstin: Oh drat, I was running some old ffmpeg from repo. My mistake.
[21:50:22 CEST] <davis> i updated the gist
[21:50:38 CEST] <davis> it shows the fixes and the resulting output file sizes
[21:51:34 CEST] <davis> since it random how it picks the files in python to create these scripts, the step1 will not match on file names, but the command options are the ones last used
[21:55:29 CEST] <Atlenohen> I think -tune fastdecode did it, feels quite faster even if really seeking like crazy it's a bit, but big difference, and it doesn't take up that ram when stabilizing
[21:55:39 CEST] <Atlenohen> RAM*
[23:35:05 CEST] <gbee> I'm trying to get realtime audio stats using the astats and ametadata filters, using the print to pipe option. However this isn't working as it's not flushing the output to the pipe immediately, it appears to be buffering at least 256kb or more so the output is written in large chunks. Is there any way to force ametadata to flush immediately?
[23:36:24 CEST] <gbee> If I remove the :file argument for ametadata the output is realtime but then I lose the ability to send the data to a specific numbered pipe
[23:53:10 CEST] <gbee> for now I've modified the metadata filter to call avio_flush() after every write, this is a bit brute force and I may refine it but it works. However it doesn't seem like it should be necessary - many of the filters with output are intended to be used in realtime so either I'm overlooking an official solution or this use of buffering isn't intentional?
[00:00:00 CEST] --- Sat Jun 15 2019
More information about the Ffmpeg-devel-irc
mailing list