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

[burek]

[00:01:55 CEST] <KGB> [13FFV1] 15michaelni closed pull request #62: describe pseudo-code (06master...06pseudo-code) 02https://git.io/v9A0Q
[00:16:46 CEST] <jya> BBB: does ffvp9 supports profile 2 ? 
[00:18:43 CEST] <KGB> [13FFV1] 15dericed opened pull request #63: update readme to link ietf versions of ffv1 (06master...06link-to-ietf-version) 02https://git.io/v9p77
[00:21:46 CEST] <KGB> [13FFV1] 15dericed opened pull request #64: Fix typo in context (06master...06fix-typo-in-context) 02https://git.io/v9p5O
[00:25:36 CEST] <nevcairiel> jya: it supports all profiles
[00:29:03 CEST] <KGB> [13FFV1] 15dericed opened pull request #65: describe use of len in pseudo-code (06master...06describe-len) 02https://git.io/v9p5h
[00:29:52 CEST] <jya> nevcairiel: great to hear
[00:33:18 CEST] <jamrial> jya: you were working at mozilla, right?
[00:33:30 CEST] <jya> jamrial: still am
[00:34:58 CEST] <jamrial> jya: ever since commit 64ad44a381 vp9 in mp4 files created by ffmpeg don't play on firefox anymore. do you know if beta or the development build was already updated to support version 1 of the spec?
[00:37:32 CEST] <jamrial> version 0 (draft version, what we used to create and what firefox 53 supports) was deprecated and its usage is not recommended anymore
[00:37:56 CEST] <nevcairiel> i broke firefox? yay?
[00:37:57 CEST] <nevcairiel> :D
[00:38:26 CEST] <jamrial> you did! :D
[00:38:28 CEST] <nevcairiel> I do find it funny that this information is apparently crucial for playback
[00:38:33 CEST] <nevcairiel> our mov demuxer doesnt even read it at all
[00:38:48 CEST] <nevcairiel> all its information is informative, not required
[00:38:52 CEST] <jamrial> nevcairiel: probably the profile field
[00:41:02 CEST] <nevcairiel> interestingly I actually found that this needed updating when I was working on a way to convey extra stream information through DirectShow, so I stole the vpcC structure to send stream info in, and figured I might as well update movenc
[00:45:43 CEST] <jamrial> nevcairiel: firefox stable doesn't support 10bit files, so looking at the profile or bitdepth field in the vpcc atom is probably the fastest way to know if a file will play or not
[00:45:50 CEST] <nevcairiel> i guess
[00:46:09 CEST] <nevcairiel> thats kind of the same reason I wanted it, so I can check before I get the actual video stream if i shall use hardware decoding or software
[00:46:17 CEST] <nevcairiel> since switching after-the-fact is always a bit iffy
[00:49:37 CEST] <jya> jamrial: what commit id is that ffmpeg one?
[00:49:45 CEST] <jamrial> jya: yes
[00:50:36 CEST] <jamrial> it updates the muxer to the version 1 of the vp9 in mp4 spec
[00:56:26 CEST] <jya> jamrial: that commit adds two bytes to the vpcc box.
[00:56:31 CEST] <jya> I'll investigate
[00:56:49 CEST] <jya> do you have a file I can test?
[00:57:17 CEST] <nevcairiel> the specification of the box was changed, its now final and no longer a draft
[00:57:32 CEST] <nevcairiel> version f ield was incremented so applications can handle it sanely
[01:01:06 CEST] <jamrial> jya: just create any vp9 file with the mp4 muxer using git head. it will write the vpcc box using the version 1 of the spec
[01:01:23 CEST] <jamrial> https://github.com/webmproject/vp9-dash/blob/master/VPCodecISOMediaFileFormatBinding.md the spec in question is stored here now
[01:01:44 CEST] <jamrial> i think it used to be in a doc file...
[01:02:46 CEST] <nevcairiel> one of these days I should teach movdec to read the HDR info, but alas I  also don't have any files of that sort
[01:03:28 CEST] <jamrial> you mean the other two boxed defined in the spec?
[01:03:35 CEST] <nevcairiel> yeah
[01:03:37 CEST] <jamrial> i already wrote patches for both muxer and demuxer :p
[01:03:42 CEST] <nevcairiel> i see
[01:03:48 CEST] <jamrial> didn't send them yet. was waiting to remove the experimental tag
[01:03:56 CEST] <jamrial> when i found out firefox wasn't reading the files anymore
[01:04:50 CEST] <jya> jamrial: I created mozilla bug 1365787 
[01:05:41 CEST] <jamrial> nevcairiel: https://www.youtube.com/watch?v=tO01J-M3g0U use youtube-dl to get the vp9 hrd version. it's webm with mastering metadata elements
[01:06:18 CEST] <nevcairiel> yeah webm i know
[01:06:23 CEST] <nevcairiel> but thats not mp4 :p
[01:06:36 CEST] <jamrial> but you can use that to remux using my patches :p
[01:06:41 CEST] <nevcairiel> that video is probably what everyone used to test
[01:07:42 CEST] <nevcairiel> the experiemental tag can probably indeed be removed now, the spec is pretty simple otherwise
[01:07:46 CEST] <jamrial> nevcairiel: https://github.com/jamrial/FFmpeg/tree/vp9_in_mp4
[01:08:13 CEST] <jya> box type 'vp_xx_'
[01:08:20 CEST] <jya> how do you manage that with mp4?
[01:08:22 CEST] <nevcairiel> if we wanted to, we could support vp8
[01:08:31 CEST] <nevcairiel> but not like anyone cares
[01:08:38 CEST] <jamrial> jya: cool, thanks
[01:09:03 CEST] <jya> or is that vpXX (vp08, vp09, vp10)
[01:09:16 CEST] <nevcairiel> its that
[01:09:25 CEST] <nevcairiel> the __ are part of the placeholder syntax
[01:09:31 CEST] <jamrial> wonder if vp10 will be used for av1
[01:09:51 CEST] <jya> i see... it's late here, better go to bed before I ask too many dumb questions
[01:10:16 CEST] <jya> we've just integrated av1 decoder in firefox fwiw (but only in webm of course)
[01:10:54 CEST] <nevcairiel> I see no point of doing that until the bitstream freezes, depending on what library version you build it plays only a small selection of files properly
[01:11:33 CEST] <jya> well, so long as the decoder version matches the encoder one, it plays :)
[01:11:58 CEST] <jya> more to do with being ready... resyncing is easy and can be easily uplifted. we just wanted to be ready
[01:12:09 CEST] <nevcairiel> supporting decoding today already just encourages idiots to start spreading files, and they'll be around for e ver and haunt us =p
[01:12:21 CEST] <kierank> yeah
[01:12:23 CEST] <kierank> i agree
[01:12:29 CEST] <kierank> you have to support all sorts of broken bitstreams
[01:12:31 CEST] <kierank> dangerous game
[01:13:26 CEST] <rillian> hi jya 
[01:13:31 CEST] <nevcairiel> surprising noone send a libaom decoder for avcodec yet though
[01:13:52 CEST] <jamrial> nevcairiel: one was sent to libav long ago
[01:14:01 CEST] <jamrial> but onyly the codec id was committed
[01:14:12 CEST] <nevcairiel> yeah i saw the codec id
[01:14:32 CEST] Action: jya signing off
[01:14:37 CEST] <jamrial> later
[01:15:08 CEST] <nevcairiel> someone even added a riff tag for av1, do people really want avi to continue :(
[01:22:46 CEST] <Threads> death to avi !!
[01:30:00 CEST] <TD-Linux> it's still mostly the libvpx api
[01:30:05 CEST] <TD-Linux> would be good to get feedback on how to change the api
[01:53:16 CEST] <cone-050> ffmpeg 03James Almer 07master:5ff31babfccd: avformat/movenc: remove experimental check for VP9 streams
[01:53:25 CEST] <jamrial> nevcairiel: ^
[03:57:16 CEST] <cone-050> ffmpeg 03James Almer 07master:3e295e633c36: build: remove --enable-raise-major configure option
[03:58:00 CEST] <jamrial> ubitux: ^
[04:09:09 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07master:58ac7fb9c395: avcodec/dfa: Fix: runtime error: signed integer overflow: -14202 * 196877 cannot be represented in type 'int'
[04:09:10 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07master:25c81e4b737b: avcodec/mlpdec: Fix: runtime error: left shift of negative value -8
[11:47:12 CEST] <wm4> nevcairiel: meh, I think your request is not unreasonable at all
[11:47:24 CEST] <wm4> seems to be a typical case of "I wrote this code and I'm not going to change it because"
[11:47:41 CEST] <wm4> but I'll keep out of the shitflinging
[12:44:38 CEST] <nevcairiel> and he wonders why noone likes him, two mails of actual concerns, and he just drops his shit and goes away crying
[12:57:20 CEST] <cone-357> ffmpeg 03Michael Niedermayer 07release/3.0:f2afdab8e40a: avcodec/dfa: Fix: runtime error: signed integer overflow: -14202 * 196877 cannot be represented in type 'int'
[12:57:21 CEST] <cone-357> ffmpeg 03Michael Niedermayer 07release/3.0:dac9ef7108ed: avcodec/mlpdec: Fix: runtime error: left shift of negative value -8
[12:57:22 CEST] <cone-357> ffmpeg 03Michael Niedermayer 07release/3.0:b33d01d8a253: Update for 3.0.8
[14:09:57 CEST] <cone-357> ffmpeg 03Michael Niedermayer 07n3.0.8:HEAD: avcodec/mlpdec: Fix: runtime error: left shift of negative value -8
[14:29:36 CEST] <durandal_1707> nevcairiel: i see no reason to have those functions check if frame is hw
[14:29:58 CEST] <durandal_1707> the functions should be simple
[14:33:35 CEST] <durandal_1707> michaelni: why rgb24 have 96 as alignment?
[14:40:19 CEST] <michaelni> durandal_1707, iam not 100% sure but i suspect this is due to using or the code having used width somewhere to achive the alignment, iam not sure theres anything that would break if tats chnaged
[14:42:16 CEST] <michaelni> code doing something to height*linesize/3 pixels would break but there is maybe no such code
[15:42:28 CEST] <nevcairiel> durandal_1707: like I said in one of the emails, it doesn't necessarily have to be that function, but somewhere in that generic functionality it has to check, or bad things happen
[15:46:59 CEST] <nevcairiel> but nicolas wasnt even interested in discussing the problem or potential solutions
[17:35:27 CEST] <tdjones> What is the best mechanism for concatenating frames from a bufferqueue for variable length packets? Should this be done in a similar way as the opus encoder creates its celt blocks?
[17:39:25 CEST] <arpu> hello does anyone understand this problem with webm cotainer https://github.com/google/shaka-packager/issues/172
[17:39:44 CEST] <arpu> tracks (unknown size)
[17:41:14 CEST] <atomnuker> tdjones: yes, just memcpy them together
[17:42:24 CEST] <alevinsn> nevcairiel:  you there?  what does vfwcap_defines represent in configure?
[17:44:37 CEST] <nevcairiel> its just a variable for a condition check
[17:45:41 CEST] <alevinsn> so, vfwcap_indev_deps depends on vfwcap_defines?
[17:53:42 CEST] <nevcairiel> thats what it says
[17:56:00 CEST] <alevinsn> regarding the line:  vfwcap_indev_deps="vfw32 vfwcap_defines"
[17:56:23 CEST] <alevinsn> what does vfw32 represent?  That's the name of the library--does a variable named vfw32 get indirectly defined
[17:56:38 CEST] <alevinsn> via the check_lib call?
[17:56:51 CEST] <nevcairiel> yeah check_lib sets it to available if the check succeeds
[17:57:10 CEST] <alevinsn> so, video for Windows support is essentially determined automatically
[17:57:21 CEST] <nevcairiel> pretty much
[17:57:33 CEST] <alevinsn> why is it done that way for VFW but not for decklink?
[17:57:45 CEST] <nevcairiel> because vfw is present on e very single windows system
[17:57:47 CEST] <nevcairiel> decklink is not.
[17:57:59 CEST] <alevinsn> well, after I installed the Windows 10 SDK
[17:58:07 CEST] <alevinsn> I noticed that it wasn't including vfw32.lib anymore
[17:58:13 CEST] <alevinsn> in the 10 directory
[17:58:20 CEST] <alevinsn> its only available in 8.1 as far as I can tell
[17:58:28 CEST] <nevcairiel> thats basically the general rule, if something depends on an external component, it doesnt get auto-enabled
[17:58:58 CEST] <alevinsn> nevcairiel:  is that your experience with vfw32.lib?
[17:59:12 CEST] <nevcairiel> i have never used vfwcap and likely never will
[18:00:30 CEST] <alevinsn> well,I see for the msvc fate runs that you've done
[18:00:33 CEST] <alevinsn> you've setup
[18:00:44 CEST] <alevinsn> it is building vfwcap.o
[18:00:54 CEST] <alevinsn> which implies that it is finding vfw32.lib
[18:01:01 CEST] <nevcairiel> my 10sdk still has the lib, too
[18:01:14 CEST] <alevinsn> which Windows 10 SDK version are you using?
[18:01:24 CEST] <nevcairiel> 15063
[18:01:35 CEST] <nevcairiel> but i checked all 3 i have installed, and all have it
[18:01:56 CEST] <nevcairiel> which is 10586 and 14393 additionally
[18:02:13 CEST] <cone-357> ffmpeg 03Paul B Mahol 07master:5c9e12bc6d3e: doc/filters: add more ladspa examples
[18:03:29 CEST] <alevinsn> so odd, I see on one system, vfw32.lib is installed, but on the other, its not
[18:04:23 CEST] <alevinsn> on one of my systems, I mean
[18:08:07 CEST] <alevinsn> nevcairiel:  when you installed the Windows 10 SDK, did you select everything to be installed?
[18:08:35 CEST] <alevinsn> I mean, all the components (performance SDK, etc)?
[18:10:03 CEST] <nevcairiel> nah, i selected whatever i thought made sense
[18:11:07 CEST] <nevcairiel> which is basically the desktop development workflow and a few extra packages
[18:11:13 CEST] <cone-357> ffmpeg 03Michael Niedermayer 07master:d32ebce8fd79: avcodec/pixlet: Fix reading invalid numbers of bits
[18:11:14 CEST] <cone-357> ffmpeg 03Michael Niedermayer 07master:a173f484b52e: avcodec/fic: Fix multiple runtime error: signed integer overflow: 5793 * 419752 cannot be represented in type 'int'
[18:11:15 CEST] <cone-357> ffmpeg 03Michael Niedermayer 07master:e434840fd4b3: avcodec/mimic: Use ff_set_dimensions() to set the dimensions
[18:11:21 CEST] <alevinsn> which is what I did as well, so odd, I picked 64-bit and 32-bit, and it still didn't install vfw32.lib and a bunch of other files
[18:15:51 CEST] <alevinsn> ok, thanks for your help.  I should have taken the time to better understand that stuff before I submitted the vfw configure patch.
[18:16:07 CEST] <durandal_1707> vfw?
[18:16:10 CEST] <nevcairiel> what exactly was the patch supposed to solve anyway?
[18:16:28 CEST] <nevcairiel> it doesnt seem to do anything much
[18:16:34 CEST] <alevinsn> well, one change was reasonable--if vfw indev is disabled
[18:16:38 CEST] <alevinsn> it wouldn't do the vfw checks
[18:16:42 CEST] <alevinsn> but, I also changed it to use require
[18:16:46 CEST] <alevinsn> instead of check_lib
[18:16:49 CEST] <alevinsn> and that part was wrong
[18:17:13 CEST] <nevcairiel> that extra condition while not technically wrong seems still a bit superflous
[18:17:54 CEST] <alevinsn> looking through configure, what is it about vfwcap_indev that causes it to be turned on by default
[18:18:07 CEST] <alevinsn> whereas decklink indev/outdev is turned off by default?
[18:18:32 CEST] <nevcairiel> components like an indev are always enabled by default, as long as their dependencies are available
[18:19:01 CEST] <alevinsn> even true for decklink?
[18:19:06 CEST] <nevcairiel> and vfwcap doesnt have much of a dependency
[18:19:18 CEST] <nevcairiel> but the decklink indev has a dependency that needs explicit enabling
[18:19:47 CEST] <alevinsn> ah, I get it
[18:21:07 CEST] <alevinsn> regarding if the vfwcap indev is specifically disabled, there isn't much point, but it might save a little time on configure
[18:21:11 CEST] <alevinsn> by not doing those checks, I guess
[18:21:17 CEST] <alevinsn> vfw32.lib is only needed for vfwcap
[18:21:25 CEST] <alevinsn> nothing else in ffmpeg uses vfw
[18:21:30 CEST] <nevcairiel> yeah not really something worth uglying up all the things for
[18:21:37 CEST] <nevcairiel> rather stay consistent with all other library checks
[18:22:11 CEST] <alevinsn> ok, I'll discard that patch--I had thought I was doing something useful, but it was just wrong
[18:22:50 CEST] <alevinsn> have to go, thanks, bye
[18:53:28 CEST] <JEEB> (32
[23:16:21 CEST] <cone-357> ffmpeg 03Paul B Mahol 07master:79bf4d1450c1: avfilter/af_sofalizer: avoid casting
[23:16:22 CEST] <cone-357> ffmpeg 03Paul B Mahol 07master:f5e5c531170f: avfilter/af_sofalizer: make lfe gain user configurable
[00:00:00 CEST] --- Fri May 19 2017