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

[burek]

[00:00:40 CET] <cone-037> ffmpeg 03Mark Thompson 07master:e412d683fe03: hwcontext: Perform usual uninitialisation on derived frames contexts
[00:00:41 CET] <cone-037> ffmpeg 03Mark Thompson 07master:e9dfc6f9006f: Merge commit 'e412d683fe0349bb8450645813a23158bb4ebd66'
[00:01:51 CET] <cone-037> ffmpeg 03Zhong Li 07master:8bb9824fcbc5: qsvenc: AVBR is not supported on non-windows OS
[00:01:52 CET] <cone-037> ffmpeg 03Mark Thompson 07master:de3be1d09f31: Merge commit '8bb9824fcbc5a6ebf68391d70a2c4f03447990d2'
[00:07:36 CET] <cone-037> ffmpeg 03Ruiling Song 07master:9b09792c90b5: lavc/qsv: default la_ds to MFX_LOOKAHEAD_DS_UNKNOWN
[00:07:37 CET] <cone-037> ffmpeg 03Mark Thompson 07master:ccef7a85d649: Merge commit '9b09792c90b580842157ca8ce534be434725a841'
[00:08:10 CET] <KGB> [13FFV1] 15dericed opened pull request #108: fix inter-sectional linking (06master...06fix-sectional-linking) 02https://git.io/vAYaR
[00:10:48 CET] <cone-037> ffmpeg 03Michael Niedermayer 07master:5b6213ef6bf5: avcodec/vc1dec: fix mby_start for interlaced content
[00:10:49 CET] <cone-037> ffmpeg 03Mark Thompson 07master:7ceec9c5ec51: Merge commit '5b6213ef6bf5e0781c83e86926eb0b33a98dc185'
[00:13:12 CET] <cone-037> ffmpeg 03Diego Biurrun 07master:a674b31240e9: build: Ignore generated mpeg12framerate test binary
[00:13:13 CET] <cone-037> ffmpeg 03Mark Thompson 07master:0018f17f233d: Merge commit 'a674b31240e99a369059385b03582b35629d190f'
[00:13:56 CET] <jkqxz> And done.
[00:33:26 CET] <cone-037> ffmpeg 03Marton Balint 07master:ce6ce595cf10: avcodec/mpeg12enc: add support for specifying video_format in the sequence_display_extension
[00:33:27 CET] <cone-037> ffmpeg 03Ray Tiley 07master:c837cd3d4d11: avdevice/decklink_dec: extract NTSC VANC
[00:39:24 CET] <cone-037> ffmpeg 03Michael Niedermayer 07release/2.8:5b6324a94c20: avcodec/aacsbr_fixed: Fix overflows in rounding in sbr_hf_assemble()
[00:39:25 CET] <cone-037> ffmpeg 03Michael Niedermayer 07release/2.8:263bddf78159: avcodec/wavpack: Fix integer overflow in FFABS
[00:39:26 CET] <cone-037> ffmpeg 03Michael Niedermayer 07release/2.8:c402b672b764: avcodec/huffyuvdec: Check input buffer size
[00:39:27 CET] <cone-037> ffmpeg 03Michael Niedermayer 07release/2.8:66f831a8d1bf: avcodec/vp3: Check eob_run
[00:39:28 CET] <cone-037> ffmpeg 03Michael Niedermayer 07release/2.8:dd422f1b5e6c: avcodec/mpeg4videodec: Ignore multiple VOL headers
[00:39:29 CET] <cone-037> ffmpeg 03Michael Niedermayer 07release/2.8:89668fa84308: avcodec/vp3: Error out on invalid num_coeffs in unpack_vlcs()
[00:43:12 CET] <KGB> [13FFV1] 15michaelni closed pull request #108: fix inter-sectional linking (06master...06fix-sectional-linking) 02https://git.io/vAYaR
[01:07:13 CET] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vAY6D
[01:07:13 CET] <KGB> 13FFV1/06master 14aadbb8c 15Jérôme Martinez: Reserve "component" word for pixel components (luma/chroma)
[01:19:45 CET] <cone-037> ffmpeg 03Michael Niedermayer 07release/2.8:d797d9f21562: Changelog: Update
[02:52:17 CET] <jamrial> BBB: have you seen https://trac.ffmpeg.org/ticket/7014 ?
[02:53:30 CET] <BBB> no
[02:54:28 CET] <BBB> I can review patches, I dont have a ton of time for debugging this ATM, unfortunately
[02:55:15 CET] <BBB> but feel free to assign to me and Ill see what I can do
[02:57:14 CET] <jamrial> alright
[03:01:16 CET] <BBB> ty
[03:01:44 CET] <jamrial> no prob
[03:02:47 CET] <jamrial> first vp9 crash in a long while. even after all the google fuzzing
[03:03:13 CET] <jamrial> goes to show it's pretty robust :p
[03:03:34 CET] <BBB> this feels like openbsds no root exploits for 10 years"
[03:03:37 CET] <BBB> and then someone finds one
[03:03:55 CET] <BBB> and then they get confused and change their website to only 3 remote root exploits in past 12 years"
[03:03:58 CET] <BBB> or whatever it was
[03:04:03 CET] <BBB> *sniff*
[04:00:08 CET] <wm4> jesus christ
[04:00:09 CET] <wm4> AV_OPT_TYPE_IMAGE_SIZE = MKBETAG('S','I','Z','E')
[04:00:33 CET] <wm4> I wanted to dispatch things based on the AV_OPT_TYPE in a table, but I guess I can't because of those dumb ABI hacks
[04:12:33 CET] <wm4> patch sent
[04:41:15 CET] <wm4> jamrial: so what are our rules, can I push the patch immediately?
[04:45:32 CET] <jamrial> wm4: yeah, it's a simple change
[04:45:39 CET] <jamrial> if you were doing something else like adding new api i'd say to wait for other reviews
[04:46:38 CET] <cone-682> ffmpeg 03wm4 07master:474194a8d0f2: avutil/opt: remove ABI hacks
[04:46:52 CET] <jamrial> removing hacky enum offsets taking advantage of the abi unstable period is pretty straighforward
[04:47:27 CET] <wm4> we still have some of them for AV_CODEC_IDs, but not sure if they can even be removed
[04:47:58 CET] <jamrial> those are to separate codec types
[04:48:27 CET] <jamrial> so new additions don't go all together at the bottom of the enum
[04:49:02 CET] <wm4> yeah, for audio/video/sub/special
[04:49:05 CET] <wm4> but there's more than that
[04:49:59 CET] <jamrial> oh right, the *800 offsets
[04:50:58 CET] <jamrial> yeah, those are there for the old libav abi compat efforts, and probably also so merges have less conflicts
[04:51:43 CET] <jamrial> they can go imo. feel free to send a patch
[04:52:42 CET] <jamrial> not sure if there's any benefit doing so, in any case
[04:52:50 CET] <jamrial> the other offsets will remain
[04:53:04 CET] <wm4> I also seem to remember about some code doing numeric comparisons of codec IDs and possibly constants, but I can't find that code again
[04:53:11 CET] <wm4> so the whole topic is scary
[04:54:49 CET] <jamrial> i think some code would assume that codec_id < 0x10000 always meant video, which before we removed the hacky MKBETAG stuff was obviously wrong
[04:55:04 CET] <wm4> ...
[04:55:15 CET] <jamrial> but now it's correct
[04:56:01 CET] <jamrial> since AV_CODEC_ID_FIRST_AUDIO == 0x10000, and everything before that is video, it was a "safe" assumption :p
[05:24:16 CET] <wm4> huh promptly got a fate error
[05:25:29 CET] <wm4> no idea why
[05:25:40 CET] <wm4> so maybe there are some numeric comparisons left which I didn't spot
[05:26:09 CET] <wm4> scratch that
[05:26:10 CET] <wm4>     av_assert0(AV_CODEC_ID_PCM_S8_PLANAR==65563);
[05:26:10 CET] <wm4>     av_assert0(AV_CODEC_ID_ADPCM_G722==69660);
[05:26:18 CET] <wm4> in avcodec_version()
[05:26:22 CET] <wm4> god fucking dammit
[05:59:08 CET] <rcombs> av_assert0(you didn't break ABI)
[11:52:21 CET] <thardin> is there an api for vbi these days? I see there's an old wish ticket for vbi support in lxfdec
[11:52:45 CET] <thardin> which I don't particularly care about, but it would be nice to at least be able to close the ticket
[11:52:58 CET] <thardin> http://trac.ffmpeg.org/ticket/2352
[11:53:36 CET] <thardin> I see the sample is gone
[14:50:36 CET] <Guest1899> Hi I am new to FFmpeg and wish to contribute as gsoc applicant. How do I get started?
[15:01:58 CET] <ad_> Hi I am new to ffmpeg and wish to contribute as gsoc applicant. How do I get started?
[15:03:15 CET] <jdarnley> Are you the same person that asked a few minutes ago?
[15:03:32 CET] <nevcairiel> do you think two people would write the exact same line? :)
[15:03:34 CET] <jdarnley> I believe there is a page on out trac wiki that lists some stuff
[15:03:58 CET] <jdarnley> nevcairiel: yes but I didn't see it as the same line because of a line wrap change
[15:04:15 CET] <jdarnley> Plus ffmpeg lost its caps
[15:04:56 CET] <jdarnley> https://trac.ffmpeg.org/
[15:05:14 CET] <ad_> Sorry actually it was me before also but somehow got disconnected.
[15:05:33 CET] <jdarnley> That happens
[15:11:26 CET] <ad_> jdarnley: Thanks!
[15:13:18 CET] <durandal_1707> https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2018
[16:41:32 CET] <uzumaki_itachi> Hello, I am Suryavanshi Virendrasingh, a B.Tech Sophomore at IIT Mandi. I am deeply interested in FFmpeg and would like to work on it in this GSoC (2018). Please shed some light on how to see and solve issues of FFmpeg.
[16:44:07 CET] <thardin> hi
[16:45:08 CET] <thardin> did you read https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2018 ?
[16:49:40 CET] <uzumaki_itachi> Yes, I read that but in that it is mentioned to contact mentor before starting to get more information about the project and the requested qualification task. So i asked for the help here
[16:52:57 CET] <jdarnley> Do we have to copy-paste what's on that page to get you to read it?
[16:52:59 CET] <jdarnley> "The qualification tasks are usually shown in the project description. Contact the respective mentor(s) for assistance on getting a related qualification task or if you want to propose your own."
[16:53:26 CET] <jdarnley> So basically what project do you want to work on?
[16:57:26 CET] <uzumaki_itachi> Sorry for that, I want to work on 360° video filter Project.
[17:01:33 CET] <thardin> then you'll want to contact Paul B Mahol
[17:58:42 CET] <Zeranoe> Why was the NewTek SDK deemed non-free in FFmpeg? The headers are all MIT which works with GPL.
[18:23:00 CET] <iive> Zeranoe, i'm not familiar with the issue, however I think that we do not support runtime linking for any library, so if the library is not (l)gpl compatible, it might make ffmpeg binary non-free.
[18:24:50 CET] <c3-Win> Zeranoe: Thanks for all your awesomeness on supplying the Windows builds.
[18:30:32 CET] <Fenrirthviti> Zeranoe: The headers historically were not MIT, iirc. That might be why, We had a similar issues trying to distribute with OBS which got resolved ages ago.
[19:39:45 CET] <JEEB> michaelni: umm, if I have irritated you with my replies I am sorry btw
[19:41:34 CET] <JEEB> michaelni: it was just not clear what sort of "new API" you were talking about, and I hadn't yet checked out what field coded pictures are in MPEG-2 Video
[19:41:37 CET] <durandal_1707>  nah
[19:42:04 CET] <michaelni> JEEB, iam not that easily irritated :)
[19:42:22 CET] <JEEB> as in, I didn't know field coded pictures were inseparatable
[19:43:02 CET] <JEEB> because if they wer feed'able to the decoder separately then one could just stop the parser after the first picture
[19:45:24 CET] <michaelni> field coded pictures can be seperated but you can store 2 fields as in interlaced in a frame
[19:46:04 CET] <michaelni> and then one has 2 timestamps
[19:47:39 CET] <JEEB> two AVPackets and then one AVFrame, I would guess?
[19:48:00 CET] <JEEB> depends on how the decoder works (but I think we can asume a decoder works like all other decoders except for jpeg2000/hevc)
[19:48:14 CET] <JEEB> (I think hevc and j2k are the only ones outputting non-interleaved interlacism)
[19:55:24 CET] <nevcairiel> at least for hevc thats mostly because it just doesnt support interlaced =p
[19:56:08 CET] <JEEB> well it supports it just fine, the flags are there. it's as far as I can tell very similar to any other video format that codes fields separately :)
[19:56:27 CET] <JEEB> it was more like: people just didn't care to output interleaved
[19:56:37 CET] <JEEB> and I don't blame 'em :)
[21:22:49 CET] <tizbac> Hi, i'm seeing that there's support for hardware decoding in the latest master , but i have a question, is it possible if i want to play a video to an opengl texture, avoiding using gltexsubimage or whatever , and have the data directly decoded to the texture?
[21:23:13 CET] <tizbac> Going GPU -> CPU -> GPU seems a waste of resources to me
[21:23:29 CET] <JEEB> various hwaccels have the capability for that
[21:23:39 CET] <JEEB> it depends on which hwaccel you're talking about
[21:26:44 CET] <tizbac> for now i'm mainly interested in intel vaapi
[21:27:29 CET] <tizbac> i have sort of copypasted the code from the hw_decode demo which downloads hw surface to software surface
[21:27:34 CET] <jkqxz> Export the image to DRM objects and import with EGL.
[21:28:08 CET] <tizbac> how is that accomplished? i cannot find any docs to it
[21:29:50 CET] <jkqxz> vaDeriveImage() + vaAcquireBufferHandle() gives you the objects, EGL_EXT_image_dma_buf_import is used to import them.
[21:30:57 CET] <tizbac> sorry if the question is stupid but i've just started again developing on that stuff and everything changed, is that applicabile also to an opengl context?
[21:32:04 CET] <rcombs> wonder if that could be made generic as well
[21:32:33 CET] <rcombs> like, have a generic function to map a hwaccel frame into an EGL texture
[21:32:53 CET] <tizbac> should be imho
[21:33:05 CET] <jkqxz> An OpenGL hwcontext type was considered for that, but there are a lot of cases.
[21:33:07 CET] <BtbN> doubt it, that would be vaapi only
[21:33:14 CET] <tizbac> otherwise hwaccel especially for decoding is useless
[21:33:14 CET] <jkqxz> And OpenGL is a horrible API to use.
[21:33:23 CET] <rcombs> tizbac: well it's plenty useful
[21:33:29 CET] <rcombs> you just need to write platform-specific code
[21:33:35 CET] <rcombs> BtbN: well, also e.g. VideoToolbox
[21:33:46 CET] <BtbN> EGL on OSX?
[21:33:51 CET] <tizbac> i mean , if you have to copy always data 2 times you almost loose the performance gain :/ at least  in some cases
[21:33:57 CET] <philipl> Look at mpv for working examples.
[21:34:05 CET] <philipl> It supports all the main hwaccels efficiently
[21:34:17 CET] <rcombs> oh well not EGL there but GL
[21:35:03 CET] <wm4> OSX basically stopped maintaining GL
[21:35:38 CET] <tizbac> jkqxz, last question, if i have an AVFrame that i have got from an hw decode context, how do i access vaapi specific part?
[21:35:55 CET] <BtbN> it's in the data pointers
[21:35:59 CET] <BtbN> depending on the pixfmt of the frame
[21:36:20 CET] <jkqxz> The VASurfaceID is in data[3], the context information is accessible via hw_frames_ctx.
[21:36:33 CET] <rcombs> has anyone implemented vulkan on top of metal
[21:36:39 CET] <rcombs> is that even sensible
[21:37:01 CET] <tizbac> jkqxz, so each frame i have to do vaDeriveImage etc or just once?
[21:37:56 CET] <jkqxz> Each frame if you use the export API.  vaDeriveImage() also locks it so nothing else can happen.
[21:37:58 CET] <wm4> rcombs: yes, there's a commercial wrapper, but it's so bad/basic it doesn't work for mpv
[21:38:26 CET] <rcombs> lol
[21:38:30 CET] <jkqxz> Because mpv definitely wouldn't do anything funky, right.
[21:38:50 CET] <wm4> hanna described it once and how it'd be restricted
[21:39:03 CET] <wm4> the result would be something worse than with GLES2
[21:39:12 CET] <wm4> in terms of features
[21:42:08 CET] <wm4> anyway mpv has all that interop stuff in video/out/*/hwdec_*
[21:42:16 CET] <wm4> there are annoyingly many
[21:47:15 CET] <hanna> rcombs: there's MoltenVK
[21:47:17 CET] <hanna> but it's a complete joke
[21:47:26 CET] <hanna> supports like 10% of the spec
[21:47:31 CET] <hanna> (or it feels like that any way)
[21:47:50 CET] <rcombs> lol
[21:48:29 CET] <hanna> like it literally isn't conformant
[21:48:43 CET] <hanna> and it will probably take them a while to get it so
[22:21:59 CET] <atomnuker> rcombs: yes, someone did
[22:22:08 CET] <atomnuker> on both gl and metal in fact
[22:22:30 CET] <atomnuker> and like most mac things, its closed source and if you want to ship it as a library you need to pay for it
[23:04:48 CET] <kepstin> just want to confirm - the AVFilter private data will be filled with 0s prior to the init function being called, right?
[23:07:08 CET] <rcombs> yes
[23:07:22 CET] <kepstin> thanks.
[23:57:36 CET] <thardin> what is codec_descriptors sorted by? codec_id?
[23:57:47 CET] <nevcairiel> probably
[23:59:01 CET] <thardin> let's see what FATE thinks
[00:00:00 CET] --- Wed Feb 14 2018