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

[burek]

[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/gst/smpte/gstsmpte.c
[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_port.c#L666
[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.html
[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/38313b913d62e7f71967f51462dc0dc37f858a41/codec/encoder/core/inc/parameter_sets.h#L86
[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