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

[burek]

[00:50:29 CEST] <cone-654> ffmpeg 03Michael Niedermayer 07master:74314f1f5f9e: avcodec/ffv1: template functions to allow data types different from int16_t
[00:50:30 CEST] <cone-654> ffmpeg 03Michael Niedermayer 07master:ce2217b25ecc: avcodec/ffv1: add AV_PIX_FMT_GBRP16 support
[06:42:41 CEST] <durandal_1707> how to call filter which injects frames into timestamp gaps?
[09:48:55 CEST] <durandal_1707> so how to name it?
[10:14:54 CEST] <j-b> 'morning
[10:24:40 CEST] <BtbN> durandal_1707, gapdetector?
[10:28:03 CEST] <durandal_1707> BtbN: its not detector, its frame/samples injector
[10:28:42 CEST] <BtbN> So... gapinjector?
[10:29:17 CEST] <nevcairiel> that sounds like it injects gaps
[10:29:33 CEST] <BtbN> gapfiller?
[10:30:17 CEST] <durandal_1707> injector? :)
[10:53:26 CEST] <iive> how about using word "insertion" instead?
[10:54:11 CEST] <iive> e.g. gap insertion.
[11:57:10 CEST] <BtbN> Trying to create a 170GB mp4 file is apparently not a good idea.
[11:57:32 CEST] <Compn> thats a good recipe for OOM
[11:57:32 CEST] <BtbN> "Error writing trailer of out.mp4: Cannot allocate memory"
[11:57:57 CEST] <bencoh> I wonder how much space you'd need to allocate in memory for the atom :)
[11:57:58 CEST] <Compn> do you need to recover it because of missing moov ?
[11:58:26 CEST] <BtbN> Well, i still have all the input data to convert again, just a day of re-muxing lost.
[11:58:51 CEST] <BtbN> But why does it need so much memory to write the moov atom?
[11:58:54 CEST] <durandal_1707> how much memory you have?
[11:58:57 CEST] <BtbN> 64GB
[11:59:03 CEST] <bencoh> :]
[11:59:28 CEST] <bencoh> either it pre-allocates structures, or there is a leak there
[12:01:17 CEST] <wbs> BtbN: because it needs to write the byte offset to every single packet in the file
[12:01:45 CEST] <BtbN> So mp4 is just pretty much useless for files that huge?
[12:02:06 CEST] <nevcairiel> pretty much
[12:02:10 CEST] <bencoh> you could try fragmented mp4 if you really need it, but...
[12:02:10 CEST] <Mavrik> Yup.
[12:02:14 CEST] <wbs> pretty much. if you write fragmented files, they won't have a single index in one location, but you won't need to keep that much in memory
[12:02:28 CEST] <BtbN> So lets hope mkv works.
[12:02:30 CEST] <nevcairiel> i specialized muxer could probably write it in small parts, but the demuxer might then explode the same way
[12:03:09 CEST] <wbs> (in practice it probably only used over 32 GB or so, but when growing some arrays by doubling the size, it might have ran out of memory around there)
[12:03:19 CEST] <Mavrik> Consider looking at TS as well, it handles these cases better (although with more overhead).
[12:03:35 CEST] <nevcairiel> streaming formats like TS of course dont care a bit about the file size
[12:03:36 CEST] <BtbN> I want to upload this to YouTube, so whatever works for that is fine.
[12:04:03 CEST] <nevcairiel> although TS might get screwy if your 170GB isnt just huge but also long
[12:04:08 CEST] <nevcairiel> wrapping timestamps are annoying
[12:04:22 CEST] <BtbN> It's 7 a day long stream.
[12:04:24 CEST] <Mavrik> Yeah, those crashes around 26 hrs or so :)
[12:04:33 CEST] <bencoh> then definitely wrapping :)
[12:05:05 CEST] <bencoh> BtbN: err .... will you be able to upload 170go to youtube anyway?
[12:05:15 CEST] <BtbN> I uploaded larger files already.
[12:05:18 CEST] <bencoh> oh, okay
[12:05:28 CEST] <bencoh> what did you use then?
[12:05:33 CEST] <BtbN> flv
[12:05:45 CEST] <BtbN> But they weren't this long, only large.
[12:07:17 CEST] <rcombs> yeah try matroska
[12:07:55 CEST] <nevcairiel> if you wanted to be absolutely safe could turn off the cue index in matroska, but it only writes video keyframes anyway so unless its all intra its probably better
[12:08:09 CEST] <rcombs> for 170GB, maybe it is
[12:08:17 CEST] <BtbN> Currently this is a mess of 110k 4-8 second long flv files. I wonder if a plain stupid concat of them would work.
[12:08:51 CEST] <rcombs> oh over 5 days that's not that high bitrate though, is it
[12:09:15 CEST] <BtbN> It was x264 in crf mode, at 20.
[12:09:36 CEST] <BtbN> The bitrate varied between less than 1k to over 15k, depending on the content.
[12:10:16 CEST] <bencoh> BtbN: depending on how you split those I'd suspect a/v desync, but ....
[12:10:43 CEST] <BtbN> It was split by nginx-rtmp, and so far it seems to have done a decent job.
[12:10:49 CEST] <bencoh> ah okay
[12:10:52 CEST] <bencoh> mux-split then
[12:11:01 CEST] <bencoh> not transcoded
[12:12:06 CEST] <BtbN> https://www.youtube.com/watch?v=4to9gvRsp2A that's a segment from the very end of it, a/v sync seems flawless.
[16:54:02 CEST] <ubitux> hi
[16:54:12 CEST] <ubitux> jamrial: Timothy_Gu: thanks for the merges
[16:54:30 CEST] <ubitux> michaelni (or anyone else); please do not push the edit list thing from youtube
[16:54:52 CEST] <nevcairiel> comment on the ML for better visibility
[16:54:56 CEST] <ubitux> i'd like to have a look because it looks like it's using an approach we dismissed already, and it might be causing fundamental issues
[16:55:20 CEST] <nevcairiel> just a hint that you want to review it more thoroughly should stop it from being pushed prematurely
[16:55:29 CEST] <ubitux> nevcairiel: i haven't look yet, i'm just giving me a delay, 'cause i just went back from holidays and i have a heavy week incoming
[16:55:37 CEST] <ubitux> ok
[16:57:19 CEST] <ubitux> but i want to test it first before making any comment
[16:57:21 CEST] <ubitux> anyway
[16:57:50 CEST] <nevcairiel> well you dont have to comment the patch, just that everyone knows you want to review
[17:52:04 CEST] <cone-371> ffmpeg 03Burt P 07master:b2b659b17df2: af_hdcd: Add analyze mode
[17:59:02 CEST] <durandal_1707> kierank: is there way to detect timestamp gaps?
[18:23:56 CEST] <cone-371> ffmpeg 03Burt P 07master:dbd7a84c8141: af_hdcd: Don't warn if converting from AV_SAMPLE_FMT_S16P
[18:35:02 CEST] <kierank> durandal_1707: ?
[18:36:22 CEST] <durandal_1707> kierank: due to missing frames that do not decode correctly
[18:43:31 CEST] <cone-371> ffmpeg 03Hendrik Leppkes 07master:3bf142c77337: cmdutils: remove the current working directory from the DLL search path on win32
[18:43:32 CEST] <cone-371> ffmpeg 03Michael Niedermayer 07master:6aa39080ccea: avcodec/rawdec: Fix palette handling with changing palettes
[18:43:33 CEST] <cone-371> ffmpeg 03Michael Niedermayer 07master:65298a192a92: avformat/id3v2: Mark variable as unused to avoid "set but not used" warning
[21:13:04 CEST] <omerjerk> Hi
[21:13:19 CEST] <omerjerk> Is there any way to get the actual number of samples in an audio frame?
[21:13:53 CEST] <omerjerk> For e.g. the last frame might not span the whole frame_size.
[21:14:06 CEST] <omerjerk> I'm not sure if I explained the issue properly. :/
[21:15:48 CEST] <BtbN> divide the size by sample size?
[21:16:03 CEST] <omerjerk> yeah so how will I get to know the sample size?
[21:18:48 CEST] <omerjerk> I need to know the total number of samples in the whole audio file.
[21:18:56 CEST] <omerjerk> That'll solve the whole problem.
[21:20:46 CEST] <omerjerk> or the number of remaining samples may be? i'm not sure.
[21:26:05 CEST] <BtbN> you know the format, so you know the size of a single sample.
[21:31:01 CEST] <omerjerk> yes i do know the size of a single sample
[21:31:09 CEST] <omerjerk> but that's not what I want.
[21:31:53 CEST] <omerjerk> the last frame is not supposed to always have avctx->frame_size samples in it.
[21:32:38 CEST] <omerjerk> so I need to know the actual samples left/total number of samples/actual number of samples in the current frame.
[21:32:42 CEST] <omerjerk> Anything will do.
[21:34:50 CEST] <BtbN> So you have an AVFrame, and want to know how many samples are in there?
[21:36:32 CEST] <omerjerk> yes
[21:36:42 CEST] <BtbN> And what's wrong with nb_samples?
[21:36:58 CEST] <omerjerk> oh. let me see. :|
[21:37:23 CEST] <omerjerk> I completely forgot about that.
[21:37:28 CEST] <omerjerk> let me just test.
[21:42:40 CEST] <cone-371> ffmpeg 03Michael Niedermayer 07release/3.1:a75a7feebd42: avformat/mov: Enable mp3 parsing if a packet needs it
[21:42:41 CEST] <cone-371> ffmpeg 03Michael Niedermayer 07release/3.1:e160064d39d5: avcodec/raw: Fix decoding of ilacetest.mov
[21:42:42 CEST] <cone-371> ffmpeg 03Michael Niedermayer 07release/3.1:19d2921bbfec: avcodec/rawdec: Fix palette handling with changing palettes
[21:42:43 CEST] <cone-371> ffmpeg 03Hendrik Leppkes 07release/3.1:9745c5ebf873: cmdutils: remove the current working directory from the DLL search path on win32
[21:43:12 CEST] <omerjerk> BtbN, thanks a lot. It worked. :)
[22:16:15 CEST] <kevr> Hello.
[22:16:40 CEST] <kevr> I'm trying to extract an image from a frame via libav in C, is there a good resource of examples i could read up on?
[22:17:04 CEST] <cone-371> ffmpeg 03Michael Niedermayer 07release/3.1:4275b27a2300: Update for 3.1.2
[22:52:44 CEST] <Chloe> why does af_atempo.c have a 0.5 to 2.0 limit on the tempo change?
[22:59:58 CEST] <durandal_1707> because of underlaying algo
[23:40:27 CEST] <cone-371> ffmpeg 03Derek Buitenhuis 07master:26695aedc200: docs/filters: Fix parameter names for colorspace filter
[23:55:13 CEST] <iive> where this commit came from?
[23:55:43 CEST] <durandal_1707> parallel universe
[23:58:25 CEST] <iive> i don't think these actually exists
[23:59:37 CEST] <durandal_1707> what you need?
[00:00:00 CEST] --- Tue Aug  9 2016