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

[burek]

[12:18:31 CET] <j-b> wm4: sorry, but we receive way more requests for pps and ppsx than doc. :D
[14:03:52 CET] <FernetMenta> ping @michaelni
[14:04:30 CET] <FernetMenta> we, kodi, tracked down an issue to this change http://ffmpeg.org/pipermail/ffmpeg-devel/2013-May/143953.html
[14:05:26 CET] <wm4> what does that even mean
[14:05:33 CET] <wm4> the commit description I mean
[14:05:38 CET] <FernetMenta> after a seek in a file with subtitles demuxer reads up to 80MB until it returns first packet
[14:06:12 CET] <FernetMenta> decrementing index_min-- seems not correct to me
[14:06:21 CET] <wm4> why can't the demuxer just do things right
[14:06:59 CET] <wm4> it's full of idiotic hacks and shit... I guess I'll keep my own demuxer for the time being
[14:10:06 CET] <wm4> I think it's some sort of hack to get subtitles show up if you seek to a specific position
[14:15:29 CET] <nevcairiel> probably, should just dump those hacks and use the matroska cues for that
[14:15:35 CET] <nevcairiel> and if a file doesnt have any, too bad
[14:15:54 CET] <wm4> this hack works only for parts of the file libavformat has indexed
[14:16:09 CET] <wm4> (so parts that have been demuxed, or if the seek index is fully missing)
[14:16:36 CET] <wm4> so in theory it could do the right thing (though not sure what it does)
[14:16:53 CET] <FernetMenta> currently it results in a long stall when the file is on a network drive
[14:18:10 CET] <wm4> does it happen when there are actually subtitles overlapping with the seek target?
[14:19:01 CET] <FernetMenta> http://trac.kodi.tv/ticket/15935
[14:19:17 CET] <FernetMenta> ^^ there is a sample attached close to last post
[14:20:23 CET] <FernetMenta> well looking at the code decrementing index_min seems wrong
[14:20:53 CET] <FernetMenta> reverting this change fixes the issue
[14:21:16 CET] <wm4> it's not clear what the commit is supposed to do in the first case
[14:21:27 CET] <wm4> and it was also done without "testcase"
[16:16:00 CET] <philipl> anyone willing to review the P016 format patches? They're pretty much carbon copies of nevcairiel's original P010 ones. I'd like to get the cuvid stuff unblocked.
[16:44:34 CET] <kierank> stupid hardware and MSB packed video
[17:47:59 CET] <kierank> who is datenwolf
[17:49:19 CET] <wm4> some guy who got trolled by the pulseaudio creator
[17:58:27 CET] <nevcairiel> philipl: as long as you took out the shifts when copying the sws stuff :D
[18:24:57 CET] <philipl> nevcairiel: I did :-)
[18:31:31 CET] <cone-568> ffmpeg 03Ludmila Glinskih 07master:5f4e555dc7ca: MAINTAINERS: add myself as an API tests maintainer
[18:38:00 CET] <DHE> opinion question. would a patch to ffmpeg (the main cli app) to enable threading of output streams be well received? I have a workload that I believe would benefit from it (multiple outputs from a single input)
[18:56:10 CET] <atomnuker> yay, my opus encoder works: https://pars.ee/temp/128k_960.opus
[18:56:52 CET] <atomnuker> pretty decent for something without a psychoacoustic system yet, 1 transform size and fixed bit allocation
[19:05:20 CET] <durandal_1707> nice 
[19:54:23 CET] <cone-568> ffmpeg 03Matthew Gregan 07master:7dc4200c3828: Add experimental muxing support for FLAC in ISO BMFF (MP4).
[19:54:24 CET] <cone-568> ffmpeg 03Matthew Gregan 07master:2d73d25670ce: Add experimental demuxing support for FLAC in ISO BMFF (MP4).
[20:08:34 CET] <cone-568> ffmpeg 03Matthew Gregan 07master:156fbbb562f3: avformat/movenc: Restrict experimental VP9 support to MODE_MP4.
[22:54:27 CET] <atomnuker> BBB: would it be a good idea to maybe encourage that?
[22:54:50 CET] <BBB> why?
[22:54:53 CET] <atomnuker> I haven't heard of anything not using 32 bits for unspecified size ints but you know, you never know
[22:55:09 CET] <BBB> ffmpeg requires 32bit for int and unsigned
[22:55:24 CET] <atomnuker> huh, okay
[22:55:32 CET] <BBB> it wont work without it
[22:55:57 CET] <BBB> the advantage of letting a system use native size is that if unsigned is for whatever stupid reason 64bit, we dont force truncation after every instruction
[22:56:11 CET] <BBB> which is ofc why it only works for non-array items
[22:56:38 CET] <BBB> (otherwise arrays grow to sizes they were never intended to grow to; but for scalars, you dont care)
[22:56:51 CET] <atomnuker> uint32_t's looks neater though :)
[22:56:55 CET] <BBB> btw congrats on your opus encoder
[22:56:58 CET] <BBB> encoders suck :-p
[22:58:39 CET] <atomnuker> wut, encoders rule
[22:59:37 CET] <atomnuker> although if whatever comes after opus uses non-power-of-two framesizes I will research a way to send tapeworms over standard email/whatever comes after email
[23:01:13 CET] <wm4> sounds useful
[23:02:55 CET] <BBB> using encoders is awesome
[23:03:04 CET] <BBB> writing encoders is painful
[23:03:11 CET] <BBB> theres so much you need to get right
[23:03:33 CET] <BBB> its fun, dont get me wron
[23:03:45 CET] <BBB> but it feels endless :)
[23:06:45 CET] <wm4> not much different with libraries gluing together and such
[23:12:05 CET] <wm4> (except the fun part)
[23:14:41 CET] <atomnuker> it's fun because it's just numbers so you can fprintf your way
[23:14:59 CET] <atomnuker> it's even more fun with opus because celt is hardcode cbr but I'll make it as vbr as possible
[23:19:07 CET] <cone-568> ffmpeg 03Mark Thompson 07master:06d73d002e7f: vaapi_h264: Fix HRD bit_rate/cpb_size scaling
[23:19:08 CET] <cone-568> ffmpeg 03Mark Thompson 07master:c8241e730f11: vaapi_encode: Refactor initialisation
[23:19:09 CET] <cone-568> ffmpeg 03Mark Thompson 07master:478a4b7e6d3e: vaapi_encode: Check packed header capabilities
[23:19:10 CET] <cone-568> ffmpeg 03Mark Thompson 07master:94f446c628bb: vaapi_encode: Sync to input surface rather than output
[23:19:11 CET] <cone-568> ffmpeg 03Mark Thompson 07master:ee1d04f970b0: vaapi_h264: Set max_num_ref_frames to 1 when not using B frames
[23:19:12 CET] <cone-568> ffmpeg 03Mark Thompson 07master:ded1859df17f: vaapi_encode: Decide on GOP setup before initialising sequence parameters
[23:19:13 CET] <cone-568> ffmpeg 03Mark Thompson 07master:658c5afaa010: vaapi_h264: Fix CFR mode with frame_rate set in AVCodecContext
[23:19:14 CET] <cone-568> ffmpeg 03Mark Thompson 07master:6796e6ea84f0: vaapi_h264: Write bitstream restriction fields
[23:19:15 CET] <cone-568> ffmpeg 03Mark Thompson 07master:ae0230cc3e24: vaapi_h265: Fix slice header writing
[23:19:16 CET] <cone-568> ffmpeg 03Mark Thompson 07master:30ebabca7c3a: vaapi_h265: Fix buffering parameters
[23:22:24 CET] <jya> BBB: ping
[23:22:36 CET] <BBB> jya pong
[23:22:59 CET] <jya> BBB: we're looking at adding transparency support with webm/vp9
[23:23:14 CET] <BBB> oh, thats easy
[23:23:25 CET] <BBB> wait didnt we have a patch for that already?
[23:23:28 CET] <BBB> I dont remember
[23:23:31 CET] <BBB> maybe Im imagining things
[23:23:45 CET] <wm4> does vp9 have an alpha pixfmt or is this about the vp8 hacks
[23:23:50 CET] <BBB> its trivial, just instantiate a second instance of the decoder in the first if theres an alpha side-data in the input AVPacket
[23:23:55 CET] <BBB> wm4: hacks again
[23:24:03 CET] <jya> the structure appear rather non-obvious. So we alpha channel needs to be decoded separately from the rest, so we need a second AVCodecContext?
[23:24:23 CET] <BBB> let me see if I can get you an example
[23:24:53 CET] <wm4> "it's trivial, just add a mess"
[23:25:47 CET] <jya> wm4: sounds like a fairly good description :)
[23:26:12 CET] <BBB> huh, the alpha patch is missing from libvpxdec
[23:27:21 CET] <BBB> oh I was in branchy mode
[23:27:24 CET] <BBB> erase that
[23:27:28 CET] <wm4> (would be nice though if libavcodec could just transparently do the alpha decoding mess behind the scenes, but I guess it's not feasible?)
[23:27:49 CET] <BBB> its AV_PKT_DATA_MATROSKA_BLOCKADDITIONAL
[23:28:12 CET] <BBB> jya: look at how libavcodec/libvpxdec.c handles AV_PKT_DATA_MATROSKA_BLOCKADDITIONAL
[23:28:25 CET] <BBB> jya: and then just replicate that exactly in vp9.c and vp8.c
[23:28:54 CET] <BBB> jya: Im happy to lend a helping hand in details etc., itd be cool to support even if that way its implemented is a little hacky
[23:29:03 CET] <BBB> dont want to be too purist about it
[23:30:56 CET] <BBB> jya: and I personally think its fine if VP9Context just has an additional VP9Context in it that is the alpha channel or something like that, or even a AVCodecContext& I dont know what the easiest way to do this is, dont want to duplicate too much but also dont want to re-write half the decoder, right?
[23:31:12 CET] <wm4> BBB: isn't that a big problem due to frame threading?
[23:31:32 CET] <BBB> why?
[23:31:43 CET] <BBB> the decoder returns a single AVFrame containing YUVA420P data
[23:31:53 CET] <BBB> it should be transparent to the threading layer
[23:32:22 CET] <wm4> I mean doesn't the threading layer distribute the input packets to the worker threads (I may have forgotten or never known how exactly this works at all)
[23:33:15 CET] <BBB> it does, but the blockadditional is there also
[23:36:33 CET] <voip_> Hello guys, I have problem with retrieving video from YouTube: [tls @ 0x55f43a0] The TLS connection was non-properly terminated.
[23:37:04 CET] <Chloe> voip_: wrong channel
[23:37:14 CET] <Chloe> #ffmpeg
[23:37:19 CET] <voip_> ok
[23:38:00 CET] <jya> BBB: ok, so simply avec a 2nd AVCodecContext, and decode the alpha bit separately, and then combine all that later for display in a magic soup.
[23:38:11 CET] <BBB> avec :D
[23:38:23 CET] <jya> is it missing any piece of code in ffvp9?
[23:38:30 CET] <kierank> wow people actually use that functionality
[23:38:39 CET] <BBB> ffvp9 needs to instantiate the second avcodeccontext, right?
[23:38:46 CET] <BBB> this should be transparent to the user
[23:39:01 CET] <BBB> its a little strangely recursive in that it means ffvp9 internally actually has a second instance of itself
[23:39:05 CET] <BBB> but thats just how life is
[23:39:06 CET] <TD-Linux> kierank, last step to replace gif
[23:39:10 CET] <jya> BBB: ah it's all done internally ? cool
[23:39:20 CET] <kierank> TD-Linux:  Hello guys, I have problem with retrieving video from YouTube: [tls @ 0x55f43a0] The TLS connection was non-properly terminated.
[23:39:22 CET] <kierank> that one
[23:39:23 CET] <BBB> well its not yet, but youll provide a patch to do that :-p
[23:39:35 CET] <jya> so just need to add the logic to add the alpha channel to the AVPacket being decoded
[23:40:32 CET] <jya> BBB: uh what ? I'm confused now... 
[23:41:00 CET] <BBB> libavcodec/libvpxdec.c handles the alpha channel provided as AV_PKT_DATA_MATROSKA_BLOCKADDITIONAL
[23:41:05 CET] <wm4> there are 2 ways how you could implement it
[23:41:05 CET] <BBB> libavcodec/vp9.c does not yet
[23:41:17 CET] <wm4> either outside of ffmpeg by just creating two decoders manually
[23:41:22 CET] <BBB> so you need to add the code to libavcodec/vp9.c to do that
[23:41:25 CET] <wm4> or creating a second decoder within ffvp9
[23:41:45 CET] <wm4> and the second choice is nicer for the API user
[23:42:55 CET] <wm4> (and BBB is talking about how to add the second one)
[23:43:14 CET] <BBB> right
[23:43:48 CET] <BBB> if you do the first, it just works with no effort whatsoever, but its not transparent, that is, users that use the plain API wont get this feature, and if someone eventually implements it, this will break your code :-p
[23:44:16 CET] <wm4> even with the second one you have to awkwardly match frames from the 2 decoders
[23:45:41 CET] <BBB> wait what?
[23:45:45 CET] <BBB> I dont think you do
[23:45:53 CET] <BBB> vp9 has no delay its 1-in-1-out
[23:46:16 CET] <BBB> so the internal alpha decoder just decodes one frame for every input, merges that into the existing 420 data as new alpha plane
[23:46:19 CET] <BBB> and & were done!
[23:46:20 CET] <BBB> right?
[23:47:41 CET] <wm4> vp9 at least discards superframes or whatever they're called, so it's 1-in-0-or-1-out... then add threading, and what if decoding a frame fails? still seems all sorts of annoying and fragile
[23:49:02 CET] <BBB> alt-ref frames :-p
[23:49:27 CET] <BBB> superframes are structures that combine alt-ref frames and subsequent visible frames in one AVPacket so that to the container level it looks like 1 frame
[23:49:47 CET] <BBB> but the alt-ref would consist of one alt-ref 420 and one alt-ref alpha blockadditional
[23:50:08 CET] <BBB> (I assume?)
[23:50:41 CET] <jya> BBB: at this stage, I prefer to do it all outside of ffvp9, and simply have two decoders setup. much easier. Remember that we build our own AVPacket, we don't use ffmpeg demuxer, so the alpha channel will never be found in the AVPacket unless we decide to
[23:50:57 CET] <BBB> hm& ok
[23:51:05 CET] <BBB> then yes you shouldnt need to do anything special
[23:51:20 CET] <jya> BBB: well, it's not always 1:1, if you have multi-threading enabled no?
[23:51:26 CET] <BBB> just read the blockadditional data from the webm container, send that into a second instance of the decoder, and merge them together
[23:51:32 CET] <wm4> it wouldn't be hard to build an avpacket with the blockadditional
[23:52:08 CET] <BBB> (merge them together being add the y plane of the alpha decoder as a plane of the i420 decoder and you have yuva420p!
[23:52:09 CET] <BBB> )
[23:52:34 CET] <BBB> anyway well add alpha decoder support inside ffvp8/9 later& just not very urgent
[23:52:39 CET] <BBB> its kind of & a fringe feature :-p
[23:53:15 CET] <wm4> it's a "wtf was google thinking" feature (though AFAIK they came up with 3 different ideas)
[23:53:46 CET] <BBB> there was - at some point - code to do variable plane counts in libvpx
[23:53:50 CET] <BBB> I dont know what happened to that
[23:53:53 CET] <atomnuker> it's the mpng school of development, except with only 1 thing written
[23:54:17 CET] <BBB> (the intention of that was indeed to code the alpha plane inside the i420 vp9 bitstream)
[23:55:03 CET] <BBB> gotta run home, bbl& jya: if you have issues getting it to work, feel free to poke me. but it should be fairly simple
[23:55:18 CET] <jya> BBB: i will thanks for the pointers
[23:55:44 CET] <jya> may look at doing it from the ffvp9 side of things.
[23:55:55 CET] <jya> that would be more beneficial for the community than hack around it
[00:00:00 CET] --- Tue Nov 22 2016