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

Fri Jul 22 03:05:04 EEST 2016

[00:00:02 CEST] <sanmarcos> PJSIP is rendering the OpenH264 decoded frames to OpenGL
[00:00:19 CEST] <nevcairiel> you would need to ask the openh264 people then to fill the frame black
[00:00:25 CEST] <sanmarcos> (there is the alternative of using ffmpeg instead of OpenH264)
[00:00:28 CEST] <nevcairiel> with external libraries we have no control
[00:00:51 CEST] <sanmarcos> so you say it is an OpenH264 issue
[00:01:25 CEST] <nevcairiel> well for a certain definition of issue
[00:01:45 CEST] <nevcairiel> its certainly their decision to init the frames zero instead of coloring them
[00:02:15 CEST] <sanmarcos> right my theory is that when we start getting frames we are missing a keyframe, and it is all inited to 0 YUV, which turns out to be green for a few seconds
[00:02:19 CEST] <sanmarcos> then we actually get video
[00:05:16 CEST] <sanmarcos> ok, I either need to find where Openh264 is doing this, or find a way of being notified when we actually get proper video frames to display
[00:05:39 CEST] <BBB> jamrial: can you explain what your stack alignment patch does? it seems like it gets rid of per-size stack alignment macros, doesnt that break e.g. on msvc where stack is aligned by 16 byte on 64bit, but not 32byte?
[00:05:48 CEST] <BBB> jamrial: or do I fundamentally misunderstand what that stuff does?
[00:07:18 CEST] <sanmarcos> https://github.com/cisco/openh264/issues/1163
[00:07:21 CEST] <TD-Linux> sanmarcos, you can also wait for the first I frame before feeding frames in
[00:07:22 CEST] <sanmarcos> that seems to be related to what I am facing
[00:07:35 CEST] <sanmarcos> TD-Linux: I will try to do that, do you have any hints on how to do so?
[00:07:42 CEST] <sanmarcos> I am new to all of this
[00:09:31 CEST] <TD-Linux> sanmarcos, for H.264 in RTP I think you have to parse the beginning of the H.264 stream. OpenH264 might have an API for this but I'm not sure.
[00:09:48 CEST] <iive> sanmarcos: other would know better, but there is h264 feature that allows the stream to not have I-frames at all. Instread the bitstream contains a number of frames that have to be discarded, before the output should recover.
[00:10:01 CEST] <TD-Linux> note that if you are missing an I frame, you can also request for the sender to send one via a RTCP message
[00:11:02 CEST] <TD-Linux> iive, that's cyclic refresh, and it's not commonly used for this
[00:12:15 CEST] <sanmarcos> iive: hmmm? ok
[00:12:29 CEST] <sanmarcos> I will take a look at the options in pjsip I have available and will read some of the openh264 source code
[00:12:35 CEST] <sanmarcos> doesnt help that pjsip only supports an old version of openh264
[00:16:44 CEST] <sanmarcos> https://trac.pjsip.org/repos/browser/pjproject/trunk/pjmedia/src/pjmedia-codec/openh264.cpp
[00:23:37 CEST] <jamrial> BBB: i'm simply getting rid of the extra configure variables and unnecessary ifdeffery. the macros are functionally the same before and after the patch
[00:24:02 CEST] <nevcairiel> so why did we have those in the first place
[00:25:20 CEST] <jamrial> it used to be two, align8 and align16. i guess at some point some arch may have not supported one or the other, or whoever wrote that assumed there could be in the future
[00:25:30 CEST] <jamrial> then i added align32 for avx stuff some time ago
[00:25:38 CEST] <sanmarcos> ok, I commentd out the openh264 code, it is not openh264
[00:25:42 CEST] <jamrial> i now check and every arch that enables them enables them all
[00:25:46 CEST] <sanmarcos> it is something before that is causing the opengl buffer to be green
[00:26:08 CEST] <sanmarcos> I made oh264_got_decoded_frame and oh264_codec_decode do nothing
[00:26:11 CEST] <BBB> jamrial: ok, very strange, I thought stack was only aligned by N bytes on some platforms
[00:26:15 CEST] <BBB> but if it works its ok
[00:26:48 CEST] <nevcairiel> well thats what those macros are for, doing higher alignment
[00:48:05 CEST] <BBB> nevcairiel: I thought they were wrappers for if platform/compiler/whatever supports alignment by N, do this, else, do this hacky thing at runtime"
[00:48:10 CEST] <BBB> nevcairiel: or is that something else?
[00:48:38 CEST] <BBB> nevcairiel: and then the switch between if/else was the HAVE_LOCAL_ALIGNED_N values in config.h
[00:48:43 CEST] <nevcairiel> they are, but apparently we dont need the complex size-specific complexity we had
[00:48:55 CEST] <nevcairiel> hm too much complex
[00:50:29 CEST] <BBB> well if this works on msvc 64bit I dont think I have anything to complaina bout
[00:50:48 CEST] <nevcairiel> 64-bit never really had all the big troubles since it even comes with aligned stack
[00:50:55 CEST] <BBB> right, but 16
[00:51:05 CEST] <BBB> so does that work for avx2 optimizations requiring 32byte?
[00:51:56 CEST] <nevcairiel> yasm code would re-align when avx2 is used, and if any stack-data is passed into such a function then thats where LOCAL_ALIGNED_32 comes in
[00:53:22 CEST] <nevcairiel> the only thing these macros did was and no longer do after the patch is allowing fine-grained configure control over which of the alignments is enabled
[00:53:32 CEST] <nevcairiel> ... which was not used by anything in configure, as jamrial found out
[00:55:39 CEST] <nevcairiel> anyway sleepz
[00:58:00 CEST] <sanmarcos> an I-frame is a key frame?
[00:58:35 CEST] <jamrial> i did not remove the per-size macros in the patch
[01:00:11 CEST] <iive> sanmarcos: I stands for intra and that means stand alone.
[01:01:03 CEST] <nevcairiel> although the definition of key-frame is a bit more complex in codecs like h264, an I frame is not necessarily a random-access-point
[01:01:29 CEST] <iive> idr are
[01:01:43 CEST] <JEEB> IRAP is nowadays the proper way to note it
[01:01:48 CEST] <sanmarcos> inter frame is a keyframe
[01:01:57 CEST] <sanmarcos> I-frame is inter frame?
[01:02:04 CEST] <JEEB> intra. inter has prediction between things
[01:02:30 CEST] <iive> internet - inter net , connected networks
[01:02:41 CEST] <sanmarcos> so to properly decode H264 you first need the first intra frame
[01:02:48 CEST] <sanmarcos> and then you can have frames that are diffs on that intra frame?
[01:03:13 CEST] <JEEB> no
[01:03:34 CEST] <JEEB> read the AVC specification to know what sort of intra frames are such that you can start random access from
[01:03:51 CEST] <JEEB> one of them is IDR and the other one IIRC is intra+a specific SEI message (with open gop)
[01:04:38 CEST] <JEEB> intra frame just means that you can (probably) decode *that* frame, it doesn't mean that you can decode the ones that come after it in coding order
[01:04:40 CEST] <nevcairiel> the sei even works entirely without intra
[01:04:52 CEST] <JEEB> ok
[01:04:55 CEST] <TD-Linux> sanmarcos, I frame = keyframe = intra frame
[01:05:00 CEST] <iive> sometimes you need 2 i-frames, because you have b-frames (bidirectional frames)
[01:05:17 CEST] <nevcairiel> well you need some sort of intra data, but you can have only intra slices
[01:05:20 CEST] <TD-Linux> iive, that's usually I and P
[01:05:25 CEST] <iive> and h264 could use 15 different frames for predictions.
[01:05:41 CEST] <TD-Linux> openh264 does not use B frames anyway
[01:05:45 CEST] <JEEB> TD-Linux: and in your definition key != IRAP, right?
[01:05:57 CEST] <JEEB> then I agree :)
[01:06:27 CEST] <JEEB> some people (and I think libavcodec currently) tends to mish-mash these definitions :P
[01:06:32 CEST] <TD-Linux> JEEB, right, and of course h265 has IDR vs I
[01:06:51 CEST] <TD-Linux> the definitions are codec specific
[01:07:32 CEST] <JEEB> well, HEVC just defines it better so I like to use its umbrella term with AVC as well
[01:07:50 CEST] <JEEB> even though for AVC the stuff that's under definition of IRAP isn't just defined as a picture type
[01:08:11 CEST] <JEEB> but rather there's various extra info which is required for something not IDR to be an IRAP
[01:08:50 CEST] <JEEB> and HEVC has the same kinds of I and IDR, and then it has those other picture types that note different kinds of IRAP
[01:09:01 CEST] <nevcairiel> doesnt hevc have those definitions for random access points as well under some other funny acronyms?
[01:09:09 CEST] <JEEB> yes, BLA etc
[01:09:17 CEST] <JEEB> but at least those are picture types
[01:09:30 CEST] <JEEB> so you get the picture and know if it's an IRAP right away
[01:09:41 CEST] <TD-Linux> HEVC has both slice types and frame types
[01:09:43 CEST] <JEEB> without additional messages. except maybe for the rolling one
[01:10:17 CEST] <JEEB> TD-Linux: a picture can be a field or a frame - let's just use the wording "picture" since that's what's used in the specs as well? :(
[01:10:25 CEST] Action: TD-Linux like the generic term 'keyframe' for seekable frames
[01:11:20 CEST] <JEEB> a keyframe is a picture that can be decoded by itself, it doesn't make any promises regarding anything that comes after in coded order
[01:11:22 CEST] <TD-Linux> ugh now you brought up interlacing. time for bed.
[01:11:31 CEST] <JEEB> unless you define it specifically
[01:11:56 CEST] <JEEB> I think I actually defined the term once for matroska since it utilizes the wording "keyframe" which is often not specific enough
[01:12:22 CEST] <TD-Linux> JEEB, matroska is now being standardized at CELLAR (I was at the meeting tuesday), so now's the time to fix it
[01:13:15 CEST] <JEEB> this was a thing in '13
[01:13:16 CEST] <JEEB> https://lists.matroska.org/pipermail/matroska-devel/2013-September/004567.html
[01:13:36 CEST] <nevcairiel> thats typical for containers to use that term and flag
[01:13:57 CEST] <JEEB> ISOBMFF called it a random access point at least, IIRC?
[01:14:03 CEST] <JEEB> but yes, it's often used
[01:16:53 CEST] <JEEB> also it seems like I defined the flag worse than I thought. mostly the "random access point" mention, after that it gets into the format specifics
[03:25:14 CEST] <cone-940> ffmpeg 03Michael Niedermayer 07master:3af1aba2be02: avformat/mux: Fix some codecpar non uses
[03:42:34 CEST] <Chloe> michaelni: so I've checked everything thrice, rebased, pushed to my test fork (which looks fine): https://github.com/joshdekock/FFmpeg/commits/master Do I just push to FFmpeg now?
[03:46:16 CEST] <cone-940> ffmpeg 03James Almer 07master:ec0e888e3aeb: Changelog: move a misplaced entry to the correct section
[03:46:17 CEST] <cone-940> ffmpeg 03James Almer 07master:66408fce493b: avformat: add an Ogg Video muxer
[03:46:18 CEST] <cone-940> ffmpeg 03James Almer 07master:120f34b6ac06: avformat/oggenc: add vp8 muxing support
[03:46:28 CEST] <Chloe> :/
[03:50:55 CEST] <michaelni> Chloe, yes once you rebase again ;)
[03:51:17 CEST] <cone-940> ffmpeg 03Josh de Kock 07master:9134d2df5b17: libopenmpt: add subsong support
[03:51:18 CEST] <cone-940> ffmpeg 03Josh de Kock 07master:4ed6edac7627: docs/demuxers: add libopenmpt section
[03:51:19 CEST] <cone-940> ffmpeg 03Jörn Heusipp 07master:840df1f19314: libopenmpt: set stream duration and fix time base
[03:51:20 CEST] <cone-940> ffmpeg 03Jörn Heusipp 07master:64131b87d64d: libopenmpt: Add "date" to metadata.
[03:51:26 CEST] <Chloe> ahh scary
[03:51:53 CEST] <Chloe> michaelni: I guess I dont need to comment on my own patches that they were push on the ML, or all?
[03:52:03 CEST] <Chloe> pushed*
[03:52:50 CEST] <michaelni> its probably best if you or someone does reply with an applied or something to the ML
[03:53:04 CEST] <michaelni> avoids confusion
[03:53:21 CEST] <Chloe> ok thanks :)
[11:26:54 CEST] <ubitux> > It seems that kVTDecodeFrame_EnableTemporalProcessing is just a suggestion to VideoToolbox, and one that it ignores. That means that, for now, this code only outputs frames in the correct order for I-frame only video. 
[11:26:56 CEST] <ubitux> lol
[11:26:58 CEST] <ubitux> what a shit framework
[11:27:42 CEST] <ubitux> said differently, "it means that this code only outputs frames in the correct order when they are already ordered" 
[11:31:55 CEST] <nevcairiel> I/P should also not have re-ordering, should it
[11:32:09 CEST] <ubitux> yeah that's the thing
[11:32:11 CEST] <nevcairiel> sounds like the VT API is entirely useless
[11:32:41 CEST] <ubitux> well you "just" have to reorder yourself
[11:32:42 CEST] <ritsuka> the docs say kVTDecodeFrame_EnableTemporalProcessing is useful only if you want videotoolbox to deinterlace the video :|
[11:32:54 CEST] <ubitux> ritsuka: wut
[11:32:57 CEST] <ubitux> what doc btw?
[11:33:41 CEST] <ritsuka> the headers
[11:34:43 CEST] <ritsuka> "The kVTDecodeFrame_EnableTemporalProcessing bit indicates whether the decoder may delay calls to the output callback so as to enable processing in temporal (display) order."
[11:34:46 CEST] <ritsuka> and in kVTDecompressionProperty_DeinterlaceMode_Temporal
[11:34:52 CEST] <ritsuka> this mode is only used if kVTDecodeFrame_EnableTemporalProcessing is set, otherwise a non-temporal mode (eg, VerticalFilter) will be used instead
[11:35:41 CEST] <ubitux> lol
[11:51:07 CEST] <cone-147> ffmpeg 03Mark Reid 07master:541731488e2d: libavformat/rawenc: add dnxhr raw format extension
[11:51:08 CEST] <cone-147> ffmpeg 03Michael Niedermayer 07master:9264bb7e79a5: avfilter/vf_psnr: Fix rounding error in average_max
[14:16:07 CEST] <omerjerk> I'm porting some old code to ffmpeg and getting the following error - 
[14:16:08 CEST] <omerjerk>  error: use of undeclared identifier 'x86_reg'
[14:16:17 CEST] <omerjerk> is it okay to convert it to int?
[14:21:41 CEST] <omerjerk> ah, nvm, just needed to incude libavutil/x86/asm.h
[14:57:25 CEST] <omerjerk> can anyone tell me the significance of this constant? - https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/x86/constants.c#L84
[14:58:04 CEST] <omerjerk> I'm getting ff_pd_2 undefined error. so my be I can use some logic
[15:05:12 CEST] <kierank> it's 1 as a doubleword repeated
[15:05:21 CEST] <kierank> replace the 1 with a 2
[15:05:47 CEST] <omerjerk> oh. that will be all?
[15:06:00 CEST] <kierank> yes
[15:06:06 CEST] <omerjerk> thanks
[16:46:24 CEST] <Chloe> I'm looking at https://trac.ffmpeg.org/ticket/5366, and it seems audiounits support runtime querying of both audiounits and their parameters. I'm just wondering how this would work with FFmpeg options, as the parameters are named. Maybe something like -par1 -par2...etc? Is there any support for custom option names and types? I guess I'm trying to take a shortcut here and implement a generic audiounits filter instead of one-per-au (there are 32
[16:46:24 CEST] <Chloe>  builtin filters).
[17:38:11 CEST] <nevcairiel> other things use a syntax like filter=option1=value1:option2=value2
[17:38:59 CEST] <nevcairiel> and we have functions to parse and split such strings into key/value pairs
[23:18:17 CEST] <cone-147> ffmpeg 03Michael Niedermayer 07master:38cc5c298c98: avformat/mov: Do not allocate empty extradata
[00:00:00 CEST] --- Fri Jul 22 2016