[00:16:54 CEST] <CFS-MP3> the doc for the scale2ref filter is wrong (doesn't show input, for starters). I'd like to correct it but I need to make sure I got it correctly [00:16:55 CEST] <CFS-MP3> https://ffmpeg.org/ffmpeg-filters.html#scale2ref [00:17:01 CEST] <CFS-MP3> there the documentation says: [00:17:15 CEST] <CFS-MP3> Scale a subtitle stream to match the main video in size before overlaying [00:17:15 CEST] <CFS-MP3> 'scale2ref[b][a];[a][b]overlay' [00:17:57 CEST] <CFS-MP3> What's the reference video there, and why does it has two outputs? [00:24:14 CEST] <llogan> CFS-MP3: yes, it could be improvded to be more clear. ffmpeg -i main_video.mp4 -i logo.png -filter_complex "[1:v][0:v]scale2ref[resized][reference];[reference][resized]overlay" output.mp4 [00:32:37 CEST] <CFS-MP3> llogan I think even more than that :-) So in that example, the logo.png would be resized to the size of main_video, then the outputs are the logo resized main_video identical to the original? [00:35:02 CEST] <llogan> it will result in logo being overlaid over main_video. the logo would be the same width and height as main_video. [00:42:54 CEST] <cone-220> ffmpeg 03Anton Khirnov 07master:b13fc1e34401: h264: do not pass H264Context to h264_slice_header_parse() [00:42:54 CEST] <cone-220> ffmpeg 03Timothy Gu 07master:bca30ed2b67f: Merge commit 'b13fc1e344011949929975a3451f78f226aa1de3' [01:01:09 CEST] <cone-220> ffmpeg 03Anton Khirnov 07master:d1d7678040cd: h264: fix the check for mixed IDR/non-IDR slices [01:01:10 CEST] <cone-220> ffmpeg 03Timothy Gu 07master:796027f22154: Merge commit 'd1d7678040cd60148f97b372cb4291bcc45b2e22' [01:03:39 CEST] <CFS-MP3> fflogger are you sure? :-) [01:03:45 CEST] <CFS-MP3> This filter: -filter_complex [0:v][0:s]scale2ref[resizedsubs][video];[video][resizedsubs]overlay[finaloverlay] [01:03:55 CEST] <CFS-MP3> results on this: [01:04:36 CEST] <CFS-MP3> Stream mapping: [01:04:36 CEST] <CFS-MP3> Stream #0:0 (mpeg2video) -> scale2ref:default (graph 0) [01:04:36 CEST] <CFS-MP3> Stream #0:2 (dvbsub) -> scale2ref:ref (graph 0) [01:04:36 CEST] <CFS-MP3> overlay (graph 0) -> Stream #0:0 (libx264) [01:06:02 CEST] <CFS-MP3> so it seems liek it's taking 0:2 as reference (unless I getting it totally wrong) [01:09:19 CEST] <CFS-MP3> Sorry, I mean llogan [01:16:07 CEST] <jamrial> Timothy_Gu: don't merge those commits just like that, they need proper testing. our slice code differs a lot from libav [01:16:44 CEST] <jamrial> there's a reason i stopped where i did [01:16:49 CEST] <Timothy_Gu> jamrial: b13fc1e34401 is basically a noop [01:17:06 CEST] <Timothy_Gu> I can revert 796027f22154 if you want? [01:17:06 CEST] <jamrial> i know, i'm talking about the second one [01:18:18 CEST] <jamrial> poke michaelni or someone that can test h264 thorougly first, and let someone that knows this code better merge further commits [01:22:12 CEST] <jamrial> h264dec is a minefield [02:04:47 CEST] <Timothy_Gu> jamrial: okay, I'll revert that after merging the next one, which is a noop. [02:06:15 CEST] <Timothy_Gu> actually I'll just revert it [02:07:28 CEST] <cone-220> ffmpeg 03Timothy Gu 07master:e4af9be0f45c: Revert "Merge commit 'd1d7678040cd60148f97b372cb4291bcc45b2e22'" [02:09:09 CEST] <Timothy_Gu> michaelni: in case you didn't see, would you mind looking at d1d7678040cd60148f97b372cb4291bcc45b2e22 to see if it should be merged at all? [02:10:08 CEST] <Timothy_Gu> jamrial: thanks for the heads-up [02:35:17 CEST] <jamrial> BBB: vp8/9 alpha maybe? that was your first idea some weeks ago [02:35:26 CEST] <BBB> jamrial: oh right that was it! [02:35:41 CEST] <michaelni> Timothy_Gu, 796027f22154c799e0063e2457b31e0cfd1dddae LGTM, this seems a bugfix from a bug introduced in 51d8725a6e4c7f989d6f0f38b59cb54a2d72846c or earlier [02:46:38 CEST] <Timothy_Gu> michaelni: okay thanks [02:51:38 CEST] <cone-220> ffmpeg 03Anton Khirnov 07master:606fb6c032fa: h264: call the hwaccel frame_start() from h264_field_start() [02:51:39 CEST] <cone-220> ffmpeg 03Timothy Gu 07master:826c780c1209: Revert "Revert "Merge commit 'd1d7678040cd60148f97b372cb4291bcc45b2e22'"" [02:51:40 CEST] <cone-220> ffmpeg 03Timothy Gu 07master:d3426fb5921d: Merge commit '606fb6c032fa44d9fa1efd4971308c228f2ebfff' [03:03:06 CEST] <jamrial> Timothy_Gu: if you want to try the next three commits in this h264 batch then go ahead [03:03:21 CEST] <jamrial> Timothy_Gu: but first push them to some personal repo for michaelni to test, if he's ok with it. fate alone is unfortunately not enough to make sure things are working [03:04:45 CEST] <jamrial> it was not my intention to tell you to stop, just to be extra careful if you're not familiar with the code. h264_slice is a finicky thing [03:14:26 CEST] <sanmarcos> anybody know how can I memset a buffer in the YUV color space to be black? [03:14:27 CEST] <sanmarcos> black in YUV is Y=0, U=128, V=128 [03:14:31 CEST] <sanmarcos> I420 specifically [03:21:58 CEST] <Timothy_Gu> jamrial: yeah, I understand. It's rare for me to do merges, and obviously it shows [03:33:15 CEST] <BBB> sanmarcos: black can also be Y=16,U/V=128 [03:34:36 CEST] <BBB> sanmarcos: but you would memset(frame->data[0], frame->color_range == AVOL_RANGE_JPEG ? 0 : 16, frame->linesize[0] * frame->height); and then memset(frame->data[1 and 2], 128, frame->liensize[1 and 2] * frame->height >> 1); [03:45:21 CEST] <sanmarcos> BBB: hmmm [03:45:33 CEST] <sanmarcos> BBB: http://www.mit.edu/afs.new/athena/astaff/source/src-9.4/third/gst-plugins/gs... [03:45:39 CEST] <sanmarcos> thinking about the fill_i420 function in there [03:49:40 CEST] <Timothy_Gu> sanmarcos: are you not sure how the function works or how the colors work? [03:50:27 CEST] <sanmarcos> I am compiling, (this is a modification to an existing codebase) [03:51:42 CEST] <sanmarcos> somebody suggested that for black, this should work [03:51:45 CEST] <sanmarcos> memset(vp->frm_buf->buf, 0x80, vp->frm_buf_size) [03:51:57 CEST] <sanmarcos> pj_bzero(vp->frm_buf->buf, vparam.fmt.det.vid.size.w*vparam.fmt.det.vid.size.h); [03:53:55 CEST] <sanmarcos> 0x80 being 128 of course [03:54:14 CEST] <Timothy_Gu> what's pj_bzero? [03:54:20 CEST] <sanmarcos> bzero essentially [03:55:20 CEST] <Timothy_Gu> technically yeah, that should work [03:55:51 CEST] <Timothy_Gu> albeit inefficient because you are filling the entire buffer with 0x80 before overwriting half of it with 0 [03:56:38 CEST] <Timothy_Gu> or maybe not half, 2/3 [04:09:40 CEST] <sanmarcos> Timothy_Gu: it works! it works! [04:10:24 CEST] <Timothy_Gu> sanmarcos: Do you know if your material is MPEG or not? [04:10:32 CEST] <sanmarcos> so memset buf + vparam.fmt.det.vid.size.w*vparam.fmt.det.vid.size.h with 0x80 with size vp->frm_buf_size - (vparam.fmt.det.vid.size.w*vparam.fmt.det.vid.size.h) [04:10:50 CEST] <sanmarcos> Timothy_Gu: it is a I420 buffer that will be filled with data decoded from OpenH264 [04:11:03 CEST] <sanmarcos> until the first keyframe comes in, it shows green (because 0 in YUV ends up green) [04:11:36 CEST] <Timothy_Gu> ah okay. Then instead of setting 0 you should set 16 [04:11:45 CEST] <sanmarcos> Timothy_Gu: why? [04:11:45 CEST] <Timothy_Gu> (like BBB mentioned) [04:12:10 CEST] <Timothy_Gu> https://www.wikiwand.com/en/YUV#/Studio_swing_for_BT.601 [04:12:23 CEST] <sanmarcos> 16/128/128 is like RGB 16/16/16 [04:12:30 CEST] <BBB> no [04:13:21 CEST] <sanmarcos> no? [04:13:34 CEST] <BBB> no [04:13:38 CEST] <sanmarcos> http://www.mikekohn.net/file_formats/yuv_rgb_converter.php [04:13:41 CEST] <sanmarcos> I got that from there [04:13:51 CEST] <BBB> 16/128/128 in mpeg domain (standard for older videos) is rgb 0/0/0 [04:14:04 CEST] <BBB> for jpeg domain, it is indeed 16/16/16 [04:14:20 CEST] <sanmarcos> I see, well either way I doubt anybody can see the differene between 16/16/16 and 0 0 0 [04:14:30 CEST] <sanmarcos> this YUV buffer is rendered on screen with OpenGL by the way [04:14:33 CEST] <BBB> the colors will be off [04:14:43 CEST] <BBB> by quite a bit [04:14:45 CEST] <BBB> anyway [04:14:47 CEST] <BBB> up to you [04:14:53 CEST] <sanmarcos> I will try both and see which one looks better? [04:14:53 CEST] <BBB> not telling you how to do your work ;) [04:15:03 CEST] <BBB> it depends on the video [04:15:05 CEST] <sanmarcos> you should, because I have very little experience in MPEG or color spaces [04:15:09 CEST] <BBB> jpeg/mpeg is a property of the video stream [04:15:15 CEST] <BBB> it is not a property of the color converter or whatever [04:15:20 CEST] <sanmarcos> BBB: this is just setting up the buffer, openh264 will overwrite it [04:15:31 CEST] <BBB> brb [04:15:58 CEST] <Timothy_Gu> You did say right now it shows green [04:16:07 CEST] <sanmarcos> yup [04:16:13 CEST] <Timothy_Gu> So even though it's overwritten, it's still gonna be displayed [04:16:25 CEST] <sanmarcos> what is? [04:16:30 CEST] <Timothy_Gu> The frame [04:16:38 CEST] <sanmarcos> the green isn't a frame [04:17:25 CEST] <Timothy_Gu> I meant the frame buffer [04:17:44 CEST] <sanmarcos> yes, the frame buffer is rendered through OpenGL even though a keyframe has not been rendered yet [04:17:47 CEST] <sanmarcos> https://trac.pjsip.org/repos/browser/pjproject/trunk/pjmedia/src/pjmedia/vid... [04:17:50 CEST] <sanmarcos> that is where it is set up [04:18:11 CEST] <sanmarcos> and this is the solution http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2016-August/019417.ht... [04:19:12 CEST] <sanmarcos> either way, the solution works, it is inefficient as has been said, but that can be easily modified [04:23:00 CEST] <Timothy_Gu> sanmarcos: okay here [04:23:08 CEST] <Timothy_Gu> https://github.com/cisco/openh264/blob/38313b913d62e7f71967f51462dc0dc37f858... [04:24:29 CEST] <Timothy_Gu> not like it matters but [04:24:47 CEST] <sanmarcos> Timothy_Gu: why doesnt it matter? [04:24:55 CEST] <sanmarcos> the PJSIP code base doesn't seem to touch that parameter [04:24:58 CEST] <Timothy_Gu> becaues it's black :D [04:25:12 CEST] <sanmarcos> black colors don't matter? [04:25:45 CEST] <sanmarcos> is that something that the decoder takes care of, or something intrisnic to the data that is encoded? [04:26:00 CEST] <sanmarcos> if they are using the analog range or digital range [04:27:14 CEST] <Timothy_Gu> sanmarcos: it's intrinsic to the data [04:28:14 CEST] <sanmarcos> yeah there is no way for me to enforce this then, because while I can control my own clients, say set them to bFullRange = true (to get digital!) [04:28:23 CEST] <sanmarcos> but other clients who send me video may send it in analog [04:28:58 CEST] <sanmarcos> I doubt that sort of information is stored in the SDP header, it is most likely obtained when the openh264 decoder begins decoding [04:29:08 CEST] <sanmarcos> from which then I can make a choice wheter to paint with 0 or 16 [04:32:08 CEST] <sanmarcos> I'll check for PJMEDIA_FORMAT_I420JPEG as well [04:43:39 CEST] <sanmarcos> which of course, doens't come, so it is 420, I just don't know the bFullRange of it [06:41:39 CEST] <jya> BBB: does your VP8 or VP9 decoder use any of the av_opt_* api ? trying to determine if I can get rid of the entire opt/dictionary stuff. there's a lot of related strings which account for a fair chunk of memory once loaded [06:43:42 CEST] <Timothy_Gu> jya: Doesn't seem like vp9 does, but libavcodec in general needs it [06:44:19 CEST] <jya> Timothy_Gu: currently the only thing I need is vp8,vp9 and flac.. so removing anything I can helps :) [06:46:11 CEST] <Timothy_Gu> michaelni: would you mind reviewing these merges: https://github.com/TimothyGu/FFmpeg/commits/merge? From e0c8250 (inclusive) till 26648703 [06:47:45 CEST] <Timothy_Gu> jya: I assume you already removed other chunks in libavutil we don't use? [06:48:22 CEST] <jya> Timothy_Gu: most if it yes. basically only took what was required to make libavcodec compile [06:48:38 CEST] <jya> but i didn't go into individual file and trimmed them manually. [06:48:44 CEST] <jya> I only worked at a file level. [06:48:58 CEST] <Timothy_Gu> that should be fine [06:49:04 CEST] <jya> as I figure modifying the original file would cause pain whenever we wanted to update [06:49:41 CEST] <Timothy_Gu> did you remove any of these https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/Makefile#L23-L49 [06:53:03 CEST] <jya> Timothy_Gu: thanks... [06:55:17 CEST] <Timothy_Gu> not saying you _can't_ remove the giant libavcodec options table, but I wouldn't try it [07:16:18 CEST] <BBB> jya: nothing specific for vp8/9, no [07:16:36 CEST] <jya> BBB: awesome.. hope it stays that way [07:16:43 CEST] <BBB> likely will [07:16:54 CEST] <BBB> I Cant think of anything that wed want to make configurable [07:16:57 CEST] <jya> though removing the strings and all code related to av_opt only managed to shave 50kB [07:17:06 CEST] <jya> out of 3.7MB [07:17:15 CEST] <jya> bit disappointing [10:39:11 CEST] <michaelni> Timothy_Gu, your branch should be ok [10:41:11 CEST] <Timothy_Gu> michaelni: cool. Will merge tomorrow [16:05:30 CEST] <nevcairiel> Timothy_Gu: before you push, can you cleanup the double revert thingy in there? it looks rather ugly and hard to follow what exactly is going on now [16:11:11 CEST] <jamrial> nevcairiel: that's unfortunately already pushed [16:11:30 CEST] <nevcairiel> didnt he ask fore review just hours ago [16:12:05 CEST] <nevcairiel> i'm not sure I like everyone doing merges now with unclear experience in doing so [16:12:56 CEST] <jamrial> that's why i told him to first ask for review before doing so, especially with functionality changes in delicate code [16:13:21 CEST] <jamrial> and he didn't push everything in that github repo, just up to merge commit 606fb6c [16:14:07 CEST] <jamrial> what's already pushed was reviewed by michaelni. it sadly looks ugly because of the double revert, though [20:17:04 CEST] <cone-027> ffmpeg 03Anton Khirnov 07master:6efc4638584e: h264: always set redundant_pic_count during slice header parsing [20:17:04 CEST] <cone-027> ffmpeg 03Anton Khirnov 07master:e26c64148be8: h264: discard slices of redundant pictures right after parsing the slice header [20:17:05 CEST] <cone-027> ffmpeg 03Anton Khirnov 07master:58640fe89ec4: h264: handle frame recovery in h264_field_start() [20:17:06 CEST] <cone-027> ffmpeg 03Anton Khirnov 07master:49670e4218d3: avconv: add a function for determining whether a filtergraph is simple [20:17:07 CEST] <cone-027> ffmpeg 03Anton Khirnov 07master:73c6ec6d659b: avconv: create simple filtergraphs earlier [20:17:09 CEST] <cone-027> ffmpeg 03Anton Khirnov 07master:5e1840622ce6: avconv: fix handling attachments in init_output_stream [20:17:09 CEST] <cone-027> ffmpeg 03Timothy Gu 07master:e0c8250a59ad: Merge commit '6efc4638584e1e14d1a6152186ba28f5d48a80c0' [20:17:10 CEST] <cone-027> ffmpeg 03Timothy Gu 07master:de625312862a: Merge commit 'e26c64148be8a20ace7512d96503172fb5e9753b' [20:17:12 CEST] <cone-027> ffmpeg 03Timothy Gu 07master:7f7cedd7139f: Merge commit '58640fe89ec4f2a3d67c0a2585fca8de34440857' [20:17:12 CEST] <cone-027> ffmpeg 03Timothy Gu 07master:9aa3023672b3: Merge commit '49670e4218d34899a1c37abb7a11615efc16f757' [20:17:13 CEST] <cone-027> ffmpeg 03Timothy Gu 07master:1b04ea1a6c23: Merge commit '73c6ec6d659bab11ac424a4ba6ce3a56246295ee' into merge [20:17:14 CEST] <cone-027> ffmpeg 03Timothy Gu 07master:e5c79cd85492: Merge commit '5e1840622ce6e41c57d9c407604863d3f3dcc3ae' [20:17:15 CEST] <cone-027> ffmpeg 03Timothy Gu 07master:26648703dbfb: ffmpeg_opt: Remove duplicated initialization of attachment stream [20:17:17 CEST] <cone-027> ffmpeg 03Timothy Gu 07master:f297d1e9e528: h264dec: Fix indentation [20:18:01 CEST] <Timothy_Gu> nevcairiel: yeah sorry about that [21:27:49 CEST] <cone-027> ffmpeg 03James Almer 07master:155f4e963021: avformat/avio: add a crc callback function for CRC-32 IEEE-LE [21:27:50 CEST] <cone-027> ffmpeg 03James Almer 07master:ce944e84892f: avformat/tta: remove custom crc callback function [21:27:51 CEST] <cone-027> ffmpeg 03James Almer 07master:376d4b3c0d9d: avformat: add a TTA Muxer [21:34:55 CEST] <jamrial> michaelni: patchwork gives a 502 bad gateway error [21:35:03 CEST] <jamrial> who was the one that set it up? [21:35:18 CEST] <michaelni> should be fixed, raz set it up [21:35:39 CEST] <jamrial> michaelni: works now, thanks [21:37:02 CEST] <llogan> too bad the listed maintainers email addresses are not obfuscated [21:42:07 CEST] <cone-027> ffmpeg 03James Almer 07master:be63ef3c4e63: avcodec/vdpau: clean up vdpau_internal.h [21:43:31 CEST] <michaelni> llogan, any idea how this can be changed ? [21:44:03 CEST] <llogan> i haven't looked into it yet, but i don't think it's a big deal. just a nit. [22:05:15 CEST] <llogan> michaelni: patchwork/templates/patchwork/project.html could be edited. maybe i'll do that later. [22:07:19 CEST] <durandal_1707> kierank: you alive? [22:07:26 CEST] <kierank> yes [23:37:51 CEST] <cone-027> ffmpeg 03Michael Niedermayer 07master:82a33c8d8584: avformat: Add av_get_frame_filename2() and AV_FRAME_FILENAME_FLAGS_MULTIPLE [23:37:52 CEST] <cone-027> ffmpeg 03Michael Niedermayer 07master:dd96a5847319: avformat/hlsenc: Use AV_FRAME_FILENAME_FLAGS_MULTIPLE, support tee: [23:37:53 CEST] <cone-027> ffmpeg 03Michael Niedermayer 07master:1fb8f6b75cb8: avformat/img2enc: Use AV_FRAME_FILENAME_FLAGS_MULTIPLE, support tee: [00:00:00 CEST] --- Fri Aug 5 2016