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

[burek]

[02:11:53 CEST] <cone-797> ffmpeg 03Hendrik Schreiber 07master:647fd4b8292e: swresample/swresample: Fix for seg fault in swr_convert_internal() -> sum2_float during dithering.
[02:16:05 CEST] <cone-797> ffmpeg 03James Almer 07master:a61886650b59: avformat/matroskadec: use refcounted buffers in EbmlBin
[02:16:06 CEST] <cone-797> ffmpeg 03James Almer 07master:b8e75a2a08b6: avformat/matroskadec: factor the prores packet parsing code out
[02:16:07 CEST] <cone-797> ffmpeg 03James Almer 07master:9703b7d05fc7: avformat/matroskadec: reference the existing data buffer when creating packets
[02:16:12 CEST] <jamrial> wm4: ^
[17:59:49 CEST] <philipl> BtbN: Are you planning to update the video sdk headers? There's new stuff on the encoder side.
[18:00:22 CEST] <BtbN> The only new thing seems to be the region of interest stuff
[18:00:31 CEST] <BtbN> The 4K60 stuff shouldn't need API changes?
[18:00:41 CEST] <philipl> There's quite a few other things
[18:00:47 CEST] <philipl> B-frames as references
[18:01:01 CEST] <BtbN> Does that have any API?
[18:01:24 CEST] <philipl> Yes.
[18:01:27 CEST] <philipl> It's a config you have to turn on
[18:01:39 CEST] <philipl> On the decode side, there are some new HEVC properties that it asks for
[18:01:53 CEST] <BtbN> That's weird
[18:02:01 CEST] <BtbN> asking for new properties, while it works fine without them so far
[18:02:07 CEST] <philipl>  //sps/pps extension fields
[18:02:20 CEST] <BtbN> I'll port over the header soon, probably tomorrow
[18:02:30 CEST] <philipl> So I guess if your video uses extensions, you have to pass the extension properties?
[18:02:40 CEST] <philipl> Cheers
[18:03:45 CEST] <jkqxz_> RExt?  Does any current hardware support that, or is it there for future stuff?
[18:04:04 CEST] <philipl> nvidia supports some RExt as it does 12bit decode.
[18:05:01 CEST] <JEEB> I guess the intermediates got large enough when adding 10bit
[18:05:10 CEST] <JEEB> that 12bit no longer was as big of a problem?
[18:06:03 CEST] <philipl> Support for both showed up at the same time; I don't believe there's any 10bit-only hardware. So they may equally have designed explicitly for 12bit
[18:07:01 CEST] <philipl> Sorry, not strictly true. GM206 is 10bit only HEVC. Everything else with 10bit has 12bit, and VP9.2 is 10/12 where it is supported at all
[18:09:26 CEST] <jkqxz_> The Main 12 RExt subprofile doesn't actually use any of the RExt features (i.e. doesn't need the (sps|pps)_range_extension stuff), so I think it's straightforward to support once Main 10 is there (though I might be missing something).
[18:10:17 CEST] <JEEB> yea, and if the internal intermediate values required 16bit or more by default and 12 bit doesn't change that
[18:28:54 CEST] <kurosu> Interesting. Haven't checked, but I bet the dxva specs haven't been updated with such a profile
[18:51:18 CEST] <wm4> jamrial: tested the mkv demuxer, it's still slower than mpv's
[18:51:21 CEST] <wm4> not sure why
[18:51:37 CEST] <wm4> I tried with h264+aac
[18:59:24 CEST] <durandal_1707> wm4: by how much?
[19:07:04 CEST] <wm4> not much
[19:07:20 CEST] <wm4> it's not going to matter
[19:07:26 CEST] <wm4> but still 1.5 times slower
[19:07:38 CEST] <wm4> or 0.5 times
[19:11:41 CEST] <jamrial> wm4: dunno what else could it be, then. probably parsing/resync logic
[19:15:33 CEST] <wm4> not sure which parsers are enabled in lavf (mpv enables none for these codecs)
[20:09:26 CEST] <cone-607> ffmpeg 03Michael Niedermayer 07master:6261ef425128: avcodec/get_bits: Document skip_bits_long()
[20:09:26 CEST] <cone-607> ffmpeg 03Michael Niedermayer 07master:6cd81d68c5e4: libavcodec/rv34: error out earlier on missing references
[22:13:40 CEST] <cone-607> ffmpeg 03Carl Eugen Hoyos 07master:916632dfbb0a: lavc/clearvideo: Allow decoding without extradata.
[23:36:11 CEST] <cone-607> ffmpeg 03Michael Niedermayer 07master:c837918f50a7: avcodec/aacsbr_fixed: Fix integer overflow in sbr_hf_assemble()
[00:00:00 CEST] --- Sun Apr  8 2018