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

[burek]

[03:50:40 CEST] <cone-611> ffmpeg 03Jun Zhao 07master:606be4cb503a: lavf/hls: remove redundancy reset_packet() after av_packet_unref()
[03:50:40 CEST] <cone-611> ffmpeg 03vacingfang 07master:d83a3117e2f0: lavf/hls: replace the same code logic with ensure_playlist()
[08:39:30 CEST] <cone-393> ffmpeg 03Matt Wolenetz 07master:052d41377a02: lafv/wavdec: Fail bext parsing on incomplete reads
[09:58:09 CEST] <vel0city> when I revise a patchset's commit (not all of them), do I need to update the patch revision in the subject (ie. "PATCH v4") annd send a new email for all of the commits? or can I only send the one I changed?
[09:58:38 CEST] <vel0city> I don't mind, but I think it's a bit spammy if I have to re-send all of them every time
[09:59:20 CEST] <vel0city> also it makes the threads on Gmail more confusing
[10:39:21 CEST] <durandal_1707> vel0city: we love spam
[10:41:19 CEST] <vel0city> hehe
[10:59:34 CEST] <whiteboard> Hi ! I am working with h.264 and .mp4. Is it feasible to modify ffmpeg or a decoder so that It would be able to extract data from  SEI messages (previously inserted by a bsf filter) and forward it to a vf filter ?
[11:00:36 CEST] <JEEB> we have already some parsing like that, which then adds side data to avpackets/frames
[11:00:52 CEST] <JEEB> so definitely possible if you put the correct parser after your bsf
[11:05:43 CEST] <nevcairiel> that seems like a dumb method if you can just make the bsf set side data in the first place
[11:05:50 CEST] <JEEB> yes
[11:05:56 CEST] <JEEB> I just didn't remember if BSFs can set that
[11:06:05 CEST] <JEEB> if the BSF can do it should definitely do it itself :P
[11:10:29 CEST] <whiteboard> The main problem I am facing is that I am not able to send anything "from a bsf filter to a vf filter" because bsf filters are applied after having "reencoded vf filtered" frames.
[11:16:31 CEST] <whiteboard> Even if a bsf could set side data before a vf filter using it, the two filters must be chained in one operation since side data are not stored in the encoded video stream.
[11:21:49 CEST] <durandal_1707> Lynne: i'm working on rnnoise filter
[11:22:56 CEST] <nevcairiel> side data by definition is not meant to be stored in the encoded video stream, thats why its side data
[11:23:15 CEST] <nevcairiel> its a seperate stream of data that sits in parallel of the main video data
[11:23:51 CEST] <nevcairiel> and it can be passed all the way through the entire chain if one wanted that
[11:25:59 CEST] <whiteboard> Is this data stream stored in the outputed .mp4 ?
[11:27:29 CEST] <nevcairiel> not usually, no.
[11:27:48 CEST] <nevcairiel> although it can be if the muxer knows how to do that
[11:27:51 CEST] <nevcairiel> some types are
[11:31:16 CEST] <whiteboard> If we chain mutliple filters, I agree that the side data could be accessed/modifed through the entire chain but not in the order I need. VF filters are applied before bsf filters, therefore, I cannot make use of results from a bsf filter in a vf filter.
[11:34:02 CEST] <nevcairiel> that doesnt even make any sense. your first suggestion was to use a bsf filter to write data to SEIs and then have the decoder pull that out again, but if BSFs run too late, how does that even make sense then
[11:34:46 CEST] <nevcairiel> there its two spots a BSF can run, either before the decoder, or after the encoder, since they run on encoded bitstreams
[11:35:30 CEST] <whiteboard> You're right, how can I make it run before the decoder ?
[11:38:01 CEST] <whiteboard> Writing data to SEIs was an idea to persistently store the side data, that I could recover in the "second run".
[11:40:45 CEST] <JEEB> not sure how easy it is with ffmpeg.c if that's what you mean
[11:41:34 CEST] <rcombs> whiteboard: what data are you trying to transmit anyway
[11:41:53 CEST] <rcombs> like, where is your data coming from, what's in it, where are you trying to get it to, and why
[11:43:31 CEST] <nevcairiel> typically the pre-decoding BSFs are defined by the decoder itself, dont think we have the ability to let users add any
[11:47:04 CEST] <whiteboard> My idea is to have a bsf filter (1) inserting encrypted data in SEI (working), stream this to another device which applies bsf filter (2) recovering/decrypting/processing the data from SEI (working) and now, I want to draw something on the frames according to the result of processed data in filter (2). The data could simply be an array of uint8_t.
[11:47:56 CEST] <whiteboard> Is my explanation clear enough to visualize the challenge ?
[11:49:13 CEST] <rcombs> whiteboard: yeah I still don't know what this data actually is or why you're trying to transmit it this way
[11:52:49 CEST] <whiteboard> "why you're trying to transmit it this way", which way do you mean ? Because I haven't decided yet which way could work to do this : sending the results (unint8_t*) of bsf filter (2) to a vf filter.
[12:57:57 CEST] <cone-074> ffmpeg 03Paul B Mahol 07master:f79873409b05: avcodec/adpcm: add support for 5.1 ADPCM MS
[12:57:57 CEST] <cone-074> ffmpeg 03Paul B Mahol 07master:ebfcd4be3302: avcodec/adpcm: reindent after last commit
[13:37:09 CEST] <Lynne> durandal_1707: keep in mind the last person to work on it did some modifications, some of which did get upstreamed, so you should probably use that repo
[15:05:49 CEST] <durandal_1707> NGA going open source?
[15:43:45 CEST] <kierank> durandal_1707: what is nga?
[16:13:17 CEST] <durandal_1707> next gen audio
[16:30:50 CEST] <kierank> durandal_1707: won't be open source
[16:30:57 CEST] <kierank> d*lby and d*s don't do that
[16:35:48 CEST] <durandal_1707> kierank: but on twitter it said it gonna be itu
[16:36:03 CEST] <kierank> durandal_1707: it will describe maybe the properties of NGA
[16:36:06 CEST] <kierank> but not the codec itself
[16:40:38 CEST] <Lynne> "There are three standardised solutions for NGA: MPEG-H Audio, AC-4 and DTS-UHD."
[16:47:18 CEST] <kierank> durandal_1707: https://www.etsi.org/deliver/etsi_ts/103400_103499/103491/01.01.01_60/ts_103491v010101p.pdf
[16:47:36 CEST] <kierank> eugh specification with copy paste from c++
[16:50:03 CEST] <thardin> also using different names for established concepts
[16:50:13 CEST] <thardin> CountBitsSet_to_1() instead of popcount()
[16:50:30 CEST] <thardin> wait there are classes in the spec? rrrrrr
[17:00:17 CEST] <JEEB> lol
[17:38:11 CEST] <durandal_1707> there will be ITU-R implementation of something IIUC
[17:38:53 CEST] <kierank> durandal_1707: email andy quested and ask him
[17:49:50 CEST] <durandal_1707> i dunno his email
[17:51:02 CEST] <durandal_1707> where to store rnn model files?
[17:53:56 CEST] <Lynne> they weren't that big, right?
[18:01:58 CEST] <durandal_1707> Lynne: there is policy to not ship stuff that cant be reproduced
[18:05:05 CEST] <durandal_1707> and they together take up to 1MB
[18:06:33 CEST] <Lynne> oh well
[18:06:58 CEST] <Lynne> what samplerates and formats did it support? wasn't it 16k 8bit only
[18:07:32 CEST] <durandal_1707> no, 48k float
[18:09:31 CEST] <cone-584> ffmpeg 03Guo, Yejun 07master:1b9064e3f4ca: libavfilter/dnn: move dnn files from libavfilter to libavfilter/dnn
[18:30:40 CEST] <cone-584> ffmpeg 03Matthieu Bouron 07release/4.2:65434823a1ee: avcodec/mediacodec_wrapper: add missing "avcodec.h" include
[18:30:41 CEST] <cone-584> ffmpeg 03Matthieu Bouron 07release/4.2:a3d986ff47b1: avcodec/mediacodec_wrapper: fix a local reference leak in ff_AMediaCodec_getName()
[18:30:42 CEST] <cone-584> ffmpeg 03Matthieu Bouron 07release/4.2:3abec7f39735: avcodec/mediacodec_wrapper: fix a potential local reference leak in ff_AMediaCodec_getCodecNameByType()
[18:30:43 CEST] <cone-584> ffmpeg 03Matthieu Bouron 07release/4.2:1df4a99e892f: avcodec/mediacodec_wrapper: remove unused local variables in ff_AMediaCodec_getCodecNameByType()
[19:49:30 CEST] <durandal_1707> peak of life: helping leader to apply fuzzer patches by giving approval to leader patches
[19:50:02 CEST] <durandal_1707> we are america
[19:50:14 CEST] <kierank> durandal_1707: you trolling me?
[19:52:21 CEST] <durandal_1707> kierank: not trolling you, i'm talking about myself, if you found yourself in those words its your problem, not mine
[19:52:33 CEST] <kierank> 18:49:20 <kierank> Daemon404: we are becoming america
[19:52:33 CEST] <kierank> 18:49:23 <kierank> it's that simple
[19:52:33 CEST] <kierank> 18:49:29 <kierank> trumpville lite
[19:52:33 CEST] <kierank> 18:50:40 <Daemon404> correct
[19:52:42 CEST] <kierank> literally 40 seconds difference compared to #videolan
[19:53:07 CEST] <durandal_1707> its just coincidence that GB is behaving like that
[19:53:56 CEST] <durandal_1707> actually, i just stoled your idea, sorry!
[19:54:13 CEST] <kierank> durandal_1707: will you be like trump when you are leader of ffmpeg
[19:54:32 CEST] <durandal_1707> yes, because we are now more like putin
[19:55:22 CEST] <durandal_1707> actually, when i think better, it will not be like trump/boris at all
[19:56:12 CEST] <durandal_1707> there will not be leader at all, just high council
[19:57:04 CEST] <kierank> who will lead high council
[19:59:33 CEST] <durandal_1707> high council will be led by high council
[20:40:27 CEST] <kierank> durandal_1707: it will be called FFmpegX
[20:40:37 CEST] <kierank> you can be Paul B Musk
[20:52:31 CEST] <durandal_1707> i'm afraid FFmpegX is already taken
[20:53:53 CEST] <kierank> FFmpegY
[20:56:13 CEST] <durandal_1707> XXXmpeg
[21:14:13 CEST] <durandal_1707> the bayer format in cineform is just gray12[4]
[21:14:36 CEST] <durandal_1707> meaning we need planar bayer formats
[21:19:02 CEST] <durandal_1707> another approach is decoding it in current bayer format,  but at 2x width and 2x height
[21:19:26 CEST] <durandal_1707> which could be quite slow
[21:19:40 CEST] <durandal_1707> what you devs think?
[21:20:53 CEST] <durandal_1707> DING! DONG!
[21:30:14 CEST] <kierank> I hate bayer
[21:30:16 CEST] <kierank> It's that simple
[21:36:40 CEST] <durandal_1707> kierank: grow up, bayer is your bright future
[21:37:04 CEST] <kierank> It is out of scope for FFmpeg
[21:37:09 CEST] <durandal_1707> lies
[21:37:12 CEST] <durandal_1707> stop lying
[21:37:16 CEST] <kierank> There are too many subjective things when processing it
[21:37:30 CEST] <kierank> Which are creative not technical
[21:37:47 CEST] <durandal_1707> i'm not talking about bayer conversion
[21:37:57 CEST] <kierank> Yes but it will happen
[21:38:02 CEST] <kierank> Slippery slope
[21:38:05 CEST] <durandal_1707> but about support of decoding of bayer
[21:38:14 CEST] <durandal_1707> no no no no no no no no no no
[21:38:14 CEST] <kierank> How to view it?
[21:38:36 CEST] <kierank> Got to decode it to format that pc can view
[21:38:45 CEST] <kierank> -> processing
[21:38:46 CEST] <durandal_1707> drop one plane, and merge others into rgb
[21:43:54 CEST] <kierank> Pfft
[21:50:22 CEST] <durandal_1707> diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
[21:50:22 CEST] <durandal_1707> index 49a5a2c30a..5c4a2436c0 100644
[21:50:22 CEST] <durandal_1707> --- a/libavcodec/cfhd.c
[21:50:22 CEST] <durandal_1707> +++ b/libavcodec/cfhd.c
[21:50:22 CEST] <durandal_1707> @@ -521,6 +521,8 @@ static int cfhd_decode(AVCodecContext *avctx, void *data, int *got_frame, av_log(avctx, AV_LOG_DEBUG, "Sample format? %i\n", data);
[21:50:25 CEST] <durandal_1707>              if (data == 1)
[21:50:28 CEST] <durandal_1707>                  s->coded_format = AV_PIX_FMT_YUV422P10;
[21:50:30 CEST] <durandal_1707> +            else if (data == 2)
[21:50:33 CEST] <durandal_1707> +                s->coded_format = AV_PIX_FMT_GBRAP12;
[21:50:35 CEST] <durandal_1707>              else if (data == 3)
[21:50:38 CEST] <durandal_1707>                  s->coded_format = AV_PIX_FMT_GBRP12;
[21:50:41 CEST] <durandal_1707>              else if (data == 4)
[22:17:21 CEST] <Compn> xxxmpeg :D
[22:17:33 CEST] <Compn> durandal_1707,  : we need bayer for r3d camera i think ;P
[22:32:34 CEST] <kierank> durandal_1707: honestly I think that is an ugly hack
[22:36:03 CEST] <durandal_1707> kierank: so i will add planar bayer format
[22:37:15 CEST] <kierank> both are bad
[22:37:15 CEST] <kierank> first one is least worst
[22:43:15 CEST] <durandal_1707> kierank: actually i will not, the components are not stored raw, they are like ycocg
[22:44:14 CEST] <durandal_1707> so i will use temp frame to decode with GBRAP pixel format and than use BAYER to put it back into one big frame
[23:03:15 CEST] <tmatth> is it normal that the checksum for fresh downloads of ffmpeg-4.1.4.tar.gz seems to be changing on me, or is it just too hot for me to thing straight?
[23:04:09 CEST] <JEEB> actual release tarball hashes should not be changing. the ones generated by gitweb *might* change (or ones generated by github if you're trying that way)
[23:09:58 CEST] <tmatth> JEEB: yeah, i've never had this issue before (and i'm getting it from http://ffmpeg.org/releases/)
[00:00:00 CEST] --- Sat Jul 27 2019