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

[burek]

[04:19:38 CET] <stevenliu> Hello? 
[04:32:33 CET] <cone-205> ffmpeg 03Steven Liu 07master:59d264b0a121: avformat/hlsenc: set strict_std_compliance from the parent AVFormatContext
[08:37:15 CET] <Fyr> guys, is there a big trouble to implement +faststart option for Matroska container?
[08:37:31 CET] <Fyr> because, I don't know how to guess the reserved space.
[08:37:47 CET] <Fyr> though, I think, ffmpeg is able to do that.
[08:38:00 CET] <Fyr> even with two passes, like for MP4.
[08:39:11 CET] <nevcairiel> faststart is only a concept for mp4 since it typically has the headers at the end, and faststart moves them to the front. mkv is different.
[08:39:39 CET] <thardin> I was about to say
[08:39:58 CET] <thardin> mkv can be streamed, mov cannot
[08:39:59 CET] <Fyr> nevcairiel, so how is different options -movflags +faststart and -reserve_index_space 50k?
[08:40:31 CET] <thardin> (except for fragmented mp4 of course)
[08:41:30 CET] <nevcairiel> you cant really seek a streaming file anyway, so having the seeking index in the beginning usually doesnt help much, but if you want to reserve space for it for some reason, you can
[08:42:01 CET] <Fyr> both mp4 and mkv have seeking information in the end.
[08:42:24 CET] <thardin> so?
[08:42:25 CET] <nevcairiel> the difference is that mp4 usually has all required playback information at the e nd
[08:42:27 CET] <Fyr> +faststart option moves it to the beginning of the file.
[08:42:33 CET] <nevcairiel> faststart is not about seeking
[08:42:36 CET] <Fyr> why is it so different for Matroska?
[08:42:36 CET] <nevcairiel> its about playback at all
[08:43:11 CET] <nevcairiel> anyhow I don't get your point, we already offer an option to reserve space for the header at the beginning if you want it to be there
[08:43:16 CET] <nevcairiel> set the option and done
[08:43:38 CET] <Fyr> nevcairiel, sometimes 50k is not enough.
[08:43:43 CET] <nevcairiel> then set more
[08:44:07 CET] <Fyr> yes, I had to set more, because I did not know how to guess the size.
[08:44:25 CET] <thardin> https://en.wikipedia.org/wiki/Multimedia_Container_Format  TIL
[08:48:11 CET] <thardin> Fyr: some_constant*duration tends to work quite well
[08:48:57 CET] <thardin> btw, does mkv fragment the index if it can't fit? like put as much as possible in the header, the rest in the footer
[08:49:09 CET] <thardin> mxf can do stuff like that
[08:49:40 CET] <nevcairiel> no it'll just error out
[08:49:47 CET] <Fyr> so far, 24 minutes of anime usually requires 40k of reserved space, one episode  of the season requires 50k of space.
[08:50:29 CET] <Fyr> Lat den ratte komma in required 1M of reserved space.
[08:50:41 CET] <Fyr> though, it's only 2 hours long.
[08:51:14 CET] <thardin> that sounds like a lot
[08:52:09 CET] <thardin> or not. .mov would use ~700k just for the video track's stco box
[08:52:25 CET] <nevcairiel> it depends how many key frames you have, and how many subtitle streams, as those also get cues
[08:52:42 CET] <thardin> right, with mkv you don't have to index every single packet
[08:53:23 CET] <nevcairiel> every subtile packet gets a cue point since for some uses its important to find the sparse packets, but t hose should usually be much rarer then any other stream
[08:54:07 CET] <mkver> Implementing faststart for Matroska would be more difficult, as it uses variable size integers. Moving the packet data to the end will therefore make the size of the Cues increase, complicating the process of finding out how big the cues will eventually be.
[09:00:11 CET] <Fyr> does SRT require BOM?
[09:03:05 CET] <mkver> No. But it helps to identify the encoding.
[09:03:42 CET] <Fyr> mkver, so FFMPEG guesses the encoding using BOM?
[09:09:11 CET] <nevcairiel> yes it reads the BOM
[09:09:24 CET] <nevcairiel> without BOM it assumes utf-8
[09:09:27 CET] <stevenliu> Hello guys, i have a question, if i want search the protocols' options use API, how should i do? or maybe i need porting the URLProtocols to AVProtiocols?
[09:09:44 CET] <nevcairiel> URLProtocols are intentionally not exposed to the public
[09:09:57 CET] <nevcairiel> changing that just for options seems a bit silly
[09:10:43 CET] <stevenliu> if i'm an API user, how should i search the options?
[09:10:56 CET] <stevenliu> just install an ffmpeg command line?
[09:11:05 CET] <stevenliu> and ffmpeg --help full ?
[09:11:22 CET] <JEEB> if ffmpeg.c can get it, then an API user can get it, too
[09:11:23 CET] <nevcairiel> i dont think api users use the api to read options
[09:11:27 CET] <nevcairiel> they just read docs
[09:11:36 CET] <JEEB> ffmpeg.c should not be using internal APIs
[09:11:42 CET] <stevenliu> yes
[09:13:04 CET] <stevenliu> i think format/muxer/demuxer codecs/encoder/decoder filters can be get option use ffmpeg -h module=name, but the devices and protocol should can do it by the same ways
[09:15:03 CET] <JEEB> right, for a moment I read you there as if it could already :)
[09:15:11 CET] <stevenliu> every times, when i ask the options of http rtmp, i must ffmpeg --help full |less, and search at the text, It doesn't feel uniform to muxer demuxer encoder
[09:16:26 CET] <stevenliu> I can get hlsenc's option use ffmpeg -h muxer=hls  but i cannot get http options use ffmpeg -h muxer=http, ffmpeg -h demuxer=http o ffmpeg -h protocol=http
[09:16:45 CET] <stevenliu> should fix this?
[09:17:23 CET] <JEEB> stevenliu: I think the worst parts are when things ignore the lavf context option (*cough* udp wanting "timeout" instead of using the rw_timeout 
[09:18:04 CET] <JEEB> stevenliu: I think it's a worthwhile point to rise although I would have to be reminded as to why those things are internally protected :)
[09:18:14 CET] <stevenliu> Agreed, but i have no idea to fix that, just add the timeout into the options into the hls.c?
[09:19:10 CET] <stevenliu> Or passthrough to the child AVFormatContext.
[09:19:39 CET] <JEEB> in your case since you're creating sub-lavf contexts you need to pass through
[09:20:14 CET] <stevenliu> avformatcontext copy?
[09:20:32 CET] <JEEB> although since you're probably doing HTTP you need to check if lavf's http follows rw_timeout or what (because of course people haven't been consistent and that sucks)
[09:20:56 CET] <mkver> Maybe one could somehow get the user a pointer to an URLContext's priv_data_class?
[09:21:36 CET] <JEEB> ok, and since http is on top of tcp
[09:22:38 CET] <JEEB> > av_find_tag for timeout vOv
[09:22:43 CET] <JEEB> so that has an option similar to UDP
[09:22:54 CET] <JEEB> anyways, afk
[09:24:29 CET] <mkver> Or one could relocate said priv_data_class to the front of URLContext and document that the first entry of the opaque used in avio_enum_protocols is a pointer to an AVClass that can be used to get the options.
[09:26:50 CET] <stevenliu> JEEB: i see Tom's link, Rui Zhang has ask one read_header2 like open2, that can get options from parent AVFormatContext, or add the options into AVFormatContext->options? add an options field into AVFormatContext?
[09:27:26 CET] <stevenliu> mkver: Thanks your point, i will try it local.
[09:33:54 CET] <stevenliu> int (*read_header)(struct AVFormatContext *);   int (*read_header2)(struct AVFormatContext *, AVDictionary **options);   :D
[11:49:37 CET] <durandal_1707> i want to RE BRAW, anybody want to help?
[12:06:35 CET] <durandal_1707> looks like nobody interested, nice and very friendly community this become!
[12:07:10 CET] <Lynne> ac-4 or bust
[12:07:31 CET] <durandal_1707> ENOSAMPLES
[12:09:40 CET] <Lynne> avpriv_request_sample(avctx, "Feature"); return AVERROR_PATCHWELCOME;
[12:11:07 CET] <durandal_1707> avpriv_request_sample(avctx, "AC-4 support is not implemented, contact nearby shrink for more info."); return AVERROR_PATCHWELCOME;
[12:11:40 CET] <Lynne> lgtm
[12:11:47 CET] <durandal_1707> lol
[12:19:27 CET] <BradleyS> BRAW=="Blackmagic RAW" ?
[12:19:59 CET] <BradleyS> i assume there are official-ish samples but i can provide samples from my cam if helpful
[12:24:08 CET] <BradleyS> durandal_1707: do you need any specific content or just a variety of resolution, frame rate, and compression?
[12:36:29 CET] <durandal_1707> BradleyS: variety of fourcc, one that i do not have, I already have brxq and brlt
[12:46:01 CET] <BradleyS> well, you tell me: https://www.dropbox.com/s/paqo8xs4b5szslw/A001_04200309_C001.braw?dl=0
[12:48:50 CET] <BradleyS> that's cbr 8:1
[12:49:05 CET] <BradleyS> cam has cbr 3:1, 5:1, 8:1, 12:1
[12:49:16 CET] <BradleyS> cq q0, q5
[12:49:32 CET] <BradleyS> not sure what is brxq and what is brlt
[12:49:45 CET] <durandal_1707> probably those modes
[12:49:49 CET] <BradleyS> i'll make a shorter sample of each
[12:50:12 CET] <BradleyS> there might not be anything else, at least on my bmpcc 4k
[12:51:56 CET] <durandal_1707> BradleyS: you have uploaded brst
[12:52:03 CET] <durandal_1707> so thats new one
[12:52:12 CET] <BradleyS> cool
[12:54:23 CET] <BradleyS> https://www.dropbox.com/sh/8s7bb7hkylewbtm/AAB8BuW23OyyqE9qtRqzQvlEa?dl=0
[12:54:34 CET] <BradleyS> includes first sample and labeled additional shorter samples
[12:54:42 CET] <BradleyS> 10-15 frames each
[12:56:20 CET] <BradleyS> there are three dynamic range presets on the cam: video, extended video, and film
[12:56:34 CET] <BradleyS> those are film, i'll take a video and ev
[12:56:56 CET] <BradleyS> in case that matters (shouldn't it's essentially the \curve)
[13:01:12 CET] <BradleyS> uploaded four more files there: dci 4k, 1080p, uhd 4k video dr, uhd 4k extended video dr
[13:01:24 CET] <BradleyS> probably all the variety i can make, hope it helps
[13:05:14 CET] <durandal_1707> i think i have all of them, the cq modes are only q0 and q5?
[13:05:24 CET] <BradleyS> yes, only those
[13:05:29 CET] <BradleyS> i will check for firmware update
[13:09:38 CET] <BradleyS> camera firmware 6.2.1, i'm installing 6.6 now
[13:13:09 CET] <BtbN> that... sounds like exactly what happens if you overload your CPU?
[13:22:04 CET] <BradleyS> update added 4K 2.4:1 sensor crop, 2.8K Anamorphic (crop), and 2.6K 16:9 (crop)
[13:22:21 CET] <BradleyS> and broke compatibility with the lens i was using, guess i'll have to call them again
[13:22:45 CET] <BradleyS> cbr/cq modes seem unchanged but i'll shoot the new resolutions
[13:33:51 CET] <BradleyS> added three more files with the new resolutions
[13:34:12 CET] <BradleyS> if they're all new fourcc (doubtful) i can reshoot the others with the new firmware
[13:34:44 CET] <BradleyS> the 2.8K anamorphic is 4:3 when decompressed so there might be a new setting in the stream
[13:35:07 CET] <BradleyS> or perhaps just setting par
[13:38:00 CET] <BradleyS> prores got none of the new resolutions, but it can shoot 1080p from a 2.6K crop now (previously only UHD 4K or 1080p crop)
[13:57:53 CET] <durandal_1707> anyone know any good C deobfuscator? i want to parse couple of obfuscated macros
[13:59:39 CET] <Lynne> run preprocessor then clang-format?
[13:59:46 CET] <thardin> cpp followed by any c formatter?
[14:24:13 CET] <durandal_1707> it seems to remove unused stuff
[14:27:05 CET] <tmatth> Lynne: btw I'm not really sure if this is encoder-side or decoder-side: https://trac.ffmpeg.org/ticket/8401
[14:39:49 CET] <Lynne> tmatth: neither, I think the wavelet depth is too high for such low resolutions
[14:40:43 CET] <tmatth> Lynne: it also happens at  high resolutions that have non % 64 widths
[14:42:46 CET] <J_Darnley> I might have something to address that in a private branch.
[14:43:00 CET] <J_Darnley> but that might depends on all the other changes
[14:44:10 CET] <tmatth> hrm actually the % 64 thing may be a red herring, I can't really tell what resolutions this is broken for
[14:49:25 CET] <Lynne> tmatth: not sure what resolutions its broken at but https://0x0.st/zIV5.diff fixes it
[14:51:07 CET] <tmatth> Lynne: nice, that did it
[14:53:24 CET] <Lynne> seems like anything non-mod-32
[15:06:59 CET] <Lynne> technically this shouldn't be needed because deinterleave() shouldn't exist
[15:08:32 CET] <Lynne> actually nevermind, its needed
[15:23:17 CET] <tmatth> Lynne: do you want to send a patch to the ML or did you have another solution in mind?
[15:24:02 CET] <jamrial> http://lists.ffmpeg.org/ looks down
[15:33:18 CET] <BtbN> looks like we can remove all the OSX+CUDA stuff from configure again
[15:33:21 CET] <BtbN> nvidia gave up on it
[15:41:54 CET] <Lynne> tmatth: its good as is, I just need to push it
[15:47:30 CET] <BradleyS> BtbN: still works fine, just not on catalina and going forward
[15:47:46 CET] <BtbN> But no more updates.
[15:48:07 CET] <BradleyS> apple is still putting out security updates for the previous two os, and nvidia drivers are current including cuda
[15:48:33 CET] <BradleyS> remains to be seen whether nvidia puts out any more updates for mojave and earlier but i doubt it
[15:49:07 CET] <BradleyS> so as much as the situation sucks, people will probably still use it for about two more years
[15:50:39 CET] <BradleyS> i would deprecate now and maybe print a warning
[16:33:58 CET] <cone-909> ffmpeg 03Oleg Dobkin 07master:32ba563cfccd: avutil/hwcontext_cuda: allow using primary CUDA device context
[18:50:58 CET] <Dmitri_Ovch> Hi! could you review these 2 patches(https://patchwork.ffmpeg.org/patch/16270/ , https://patchwork.ffmpeg.org/patch/16382/) ? This patches are really small and it should not take much time, but these fixes were requested by our users.
[19:04:31 CET] <cehoyos> Who wrote the profile patch?
[19:05:06 CET] <cehoyos> Please ask Mark Thompson to look at the patches if nobody comments.
[19:07:42 CET] <jamrial> Dmitri_Ovch: the avctx->refs check should probably be > 0 instead
[19:08:07 CET] <jamrial> the level part is good
[19:09:41 CET] <Dmitri_Ovch> !?0A81>! O 8A?@02;N 8 >B?@02;N 70=>2>
[19:10:10 CET] <Dmitri_Ovch> Thanks! I will correct and resend
[19:10:14 CET] <Dmitri_Ovch> sorry
[19:15:28 CET] <Dmitri_Ovch> cehoyos: Profile level patch was proposed by Sitan Liu <nst799610810 at gmail.com>
[19:15:42 CET] <cehoyos> Who wrote the patch?
[19:25:50 CET] <Dmitri_Ovch> cehoyos: Sitan Liu, He asked me to suggest patch using correct way(instead of the pull-on request he sent earlier)
[19:27:05 CET] <Dmitri_Ovch> I also specified this in the patch description
[19:31:35 CET] <cehoyos> The patch description indicates that you wrote the patch. If you did not write the patch, please fix the commit message
[19:39:44 CET] <Dmitri_Ovch> I'm sorry, it was unintentional. I probably don't understand the meaning of "proposed"correctly. I will send new patch, with corrected description and avctx->refs check.
[23:13:51 CET] <JEEB> interesting
[23:14:15 CET] <JEEB> we have some info on DV profile 5 (which is the custom dolby color space), but if this is an actual test sequence :P
[23:15:39 CET] <JEEB> seems so
[00:00:00 CET] --- Wed Nov 27 2019