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

[burek]

[01:54:42 CEST] <cone-161> ffmpeg 03James Almer 07master:1d479300cbe0: avformat/nutenc: don't allocate a dynamic AVIOContext if no index is going to be written
[04:15:44 CEST] <cone-161> ffmpeg 03James Almer 07master:0700e7247b83: avformat/mpegenc: check for stream private data during deinit
[07:11:31 CEST] <cone-161> ffmpeg 03Steven Liu 07master:25f5d67a316b: avformat/cinedec: check av_strdup() return value
[07:11:32 CEST] <cone-161> ffmpeg 03Steven Liu 07master:17d96c15d25e: avformat/hlsenc: check av_strdup() return value
[07:11:33 CEST] <cone-161> ffmpeg 03Steven Liu 07master:1f7b527194a2: avformat/libsrt: check av_strdup() return value and fix memleak
[07:11:34 CEST] <cone-161> ffmpeg 03Steven Liu 07master:f5263172de31: avformat/mpeg: check av_strdup() return value
[07:11:35 CEST] <cone-161> ffmpeg 03Steven Liu 07master:53928e0b49b9: avformat/mtv: check av_strdup() return value
[07:11:36 CEST] <cone-161> ffmpeg 03Steven Liu 07master:b1071b405d57: avformat/mvdec: check av_strdup() return value
[07:11:37 CEST] <cone-161> ffmpeg 03Steven Liu 07master:9f023017abed: avformat/sapdec: check av_strdup() return value and fix memleak
[09:32:51 CEST] <cone-161> ffmpeg 03Gyan Doshi 07master:ed78ca41232e: doc/utils: add hexadecagonal channel layout
[09:52:07 CEST] <cone-161> ffmpeg 03Paul B Mahol 07master:d4d6b7b0355f: avfilter/vf_datascope: fix heap buffer overflow
[09:57:55 CEST] <cone-161> ffmpeg 03Paul B Mahol 07master:723d69f99cd2: avfilter/vf_lagfun: fix heap-buffer overflow
[10:20:20 CEST] <cone-161> ffmpeg 03Paul B Mahol 07master:c8f3915f8d39: avfilter/vf_decimate: fix memory leaks
[11:56:06 CEST] <beastd> hi
[11:56:59 CEST] <durandal_1707> hi
[11:57:25 CEST] <beastd> i don't think closing tickets and setting resolution to fixed is a good practice
[11:58:03 CEST] <durandal_1707> you mean fixing tickets is not good practice?
[11:58:28 CEST] <beastd> no i meant closing the ticket withoug leaving a comment
[11:59:10 CEST] <beastd> actually i would argue closing tickets (with any resolution) without a comment is poor practice
[11:59:17 CEST] <cone-161> ffmpeg 03Paul B Mahol 07master:ce5274c1385d: avfilter/vf_fieldmatch: fix heap-buffer overflow
[11:59:51 CEST] <durandal_1707> i do not have time to write comment, and time is precious
[12:00:46 CEST] <beastd> of course it is
[12:01:32 CEST] <beastd> but if you fixed or know someone fixed it, you could just write "fixed by <commit id>"
[12:06:27 CEST] <beastd> durandal_1707: thx for writing the small comment with the commit id this time
[12:09:49 CEST] <BtbN> I'm still not sure if these bug-reports are from a bot or not...
[12:11:13 CEST] <beastd> BtbN: my comment wasn't specifically about those, but in general
[13:11:57 CEST] <cone-161> ffmpeg 03Paul B Mahol 07master:7056ddc0e0f1: avfilter/vf_fieldhint: add support for duplicating fields
[17:44:06 CEST] <Lynne> durandal_1707: write a filter to do replaygain analysis if you're bored
[17:54:07 CEST] <durandal_1707> Lynne: http://ffmpeg.org/ffmpeg-filters.html#replaygain
[17:58:21 CEST] <Lynne> was sure I checked for it some time ago and it wasn't there
[18:04:00 CEST] <Lynne> but its useless, gives you rounded values you need to parse yourself
[18:07:13 CEST] <durandal_1707> Lynne: what you need exactly? this is wvgain port
[18:08:39 CEST] <Lynne> I need something to calculate a track's replaygain and give me the peak/gain value
[18:09:34 CEST] <Lynne> preferably without needing to hook up a special logging callback
[18:11:08 CEST] <durandal_1707> watches pelcome
[18:22:28 CEST] <cone-161> ffmpeg 03Michael Niedermayer 07master:5f0acc5064ed: avcodec/g729postfilter: Fix left shift of negative value
[18:22:29 CEST] <cone-161> ffmpeg 03Michael Niedermayer 07master:2c78a76cb044: avcodec/g729dec: Avoid computing invalid temporary pointers for ff_acelp_weighted_vector_sum()
[18:22:30 CEST] <cone-161> ffmpeg 03Andreas Rheinhardt 07master:6090ac1d043c: avcodec/zmbv: Call decode_intra directly
[18:22:31 CEST] <cone-161> ffmpeg 03Andreas Rheinhardt 07master:fee1bffbc26e: mpeg4_unpack_bframes: Merge close and flush
[18:57:08 CEST] <cone-161> ffmpeg 03Paul B Mahol 07master:7080bbfef401: avfilter/vf_bm3d: forward status back
[18:57:09 CEST] <cone-161> ffmpeg 03Paul B Mahol 07master:a60232ab2d37: avfilter/vf_bm3d: round values toward nearest integer
[19:09:35 CEST] <cone-161> ffmpeg 03Paul B Mahol 07master:26876fdb5e73: avfilter/vf_fftdnoiz: round toward nearest integer
[19:37:57 CEST] <cone-161> ffmpeg 03Paul B Mahol 07master:58bb9d3a3a6e: avfilter/af_tremolo: fix heap-buffer overflow
[19:44:56 CEST] <cone-161> ffmpeg 03James Almer 07master:90e37adab7fc: avformat/nutenc: free all missing dynamic AVIOContext on header writing failure
[21:16:03 CEST] <haasn> Does anybody know of a good centralized resource collecting information about a metric fuckton of common video formats like yuv420p, nv12 etc. and how they are laid out in memory?
[21:16:22 CEST] <haasn> (perhaps using fourcc codes instead)
[21:16:59 CEST] <nevcairiel> really there isnt a "metric fuckton" of common formats though
[21:18:00 CEST] <nevcairiel> unless you count these special packed formats that are really meant for file storage
[21:18:08 CEST] <JEEB> yea
[21:18:21 CEST] <haasn> yeah fair enough
[21:18:28 CEST] <JEEB> for GPU stuff you usually have RGB, NV12|P010|P016|NV24|NV42
[21:18:39 CEST] <haasn> really I'm just trying to avoid reinventing the wheel here
[21:18:59 CEST] <haasn> I was about to start listing a bunch of metadata definitions for all those formats and whatever else I could think of
[21:19:06 CEST] <nevcairiel> yeah for GPUs there is th NV family with  interelaved chroma, there is the YV family with planar chroma
[21:19:23 CEST] <haasn> and I wonder if there's some pre-existing library or document I could pull this from
[21:20:05 CEST] <nevcairiel> for hardware-near formats I usually go to t he Microsoft document for these, since thats what hardware tends to use and its illustrated nicely
[21:20:29 CEST] <nevcairiel> ie. https://docs.microsoft.com/en-us/windows/win32/medfound/recommended-8-bit-yuv-formats-for-video-rendering and https://docs.microsoft.com/en-us/windows/win32/medfound/10-bit-and-16-bit-yuv-video-formats
[21:20:32 CEST] <Lynne> there's drm_fourcc.h which lists a ton of stuff
[21:21:06 CEST] <JEEB> nevcairiel: yea those are nice
[21:21:09 CEST] <Lynne> they use big endian notation though because they hate you, so you have to flip every component
[21:21:24 CEST] <haasn> oh that's nice
[21:24:08 CEST] <haasn> ah that literally just defines the names though
[21:27:03 CEST] <nevcairiel> of course ffmpeg has pixdesc.c/h which defines all the formats it knows and supposedly genericly enough that you dont need to know how its formed as long as you follow the data structure
[21:28:26 CEST] <haasn> ah that's pretty much what I want, I think
[21:28:56 CEST] <nevcairiel> i havent actually tried writing generic code with that structure, but the theory is there
[21:29:38 CEST] <haasn> The use case I'm trying to address is that I have a library which ingests a similarly "generic" format description (rather than any actual explicit format names)
[21:30:27 CEST] <haasn> So I'm trying to provide a way for users who don't know the technical details of every format under the sun (and don't feel like brute force enumerating them even if they do) to simply map from something common like an av pixfmt name or fourcc code to fill in the details of that generic format descriptor
[21:30:43 CEST] <haasn> pixdesc.h seems like a perfect fit, thanks
[21:32:02 CEST] <JEEB> :)
[00:00:00 CEST] --- Sun Oct 20 2019