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

[burek]

[00:14:00 CEST] <BtbN> Fenrirthviti, try turning on aud, I vaguely remember that being important for the cbr padding
[00:14:27 CEST] <Fenrirthviti> Hm, ok, I'll check in to that
[00:14:37 CEST] <BtbN> There was a commit fixing the padding, ages ago
[00:14:40 CEST] <BtbN> but I can't find it
[00:15:15 CEST] <Fenrirthviti> I found a param in their headers for uhh
[00:15:40 CEST] <Fenrirthviti> outputPictureTimingSEI, which is required for CBR to work properly if I read it right?
[00:15:56 CEST] <Fenrirthviti> we also have outputAUD set to 1
[00:16:05 CEST] <BtbN> yes, the TimingSEI definitely is required
[00:16:16 CEST] <BtbN> for whatever reason, that's what they bound the padding to
[00:16:29 CEST] <Fenrirthviti> yeah digging through this has been super fun.
[00:16:50 CEST] <BtbN> outputBufferingPeriodSEI and outputPictureTimingSEI need to be set for it to work, yeah
[00:16:53 CEST] <BtbN> and they are
[00:17:36 CEST] <nevcairiel> so that explains why those got turned on without me explicitly asking for them
[00:17:46 CEST] <Fenrirthviti> I see that we're setting that, but not outputAUD actually
[00:18:04 CEST] <BtbN> I don't think outputAUD was one of the magical padding settings
[00:18:23 CEST] <Fenrirthviti> ah, ok.
[00:18:25 CEST] <nevcairiel> i can see the buffering/timing SEIs being related to m ake a proper CBR stream
[00:18:29 CEST] <nevcairiel> AUD is just unrelated
[00:18:58 CEST] <Fenrirthviti> Just frustrating that nvidia is telling us that there are "too many uses cases where CBR not being CBR is useful"
[00:19:13 CEST] <nevcairiel> well there are
[00:19:23 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/commit/3a9df7dfec89fadfee9e814e6adb2706908dffa4
[00:19:57 CEST] <Fenrirthviti> alright, I wonder if there's some kind of logic mixup here then https://github.com/obsproject/obs-studio/blob/5d83e1aec42c39f524b1c8681ea6d491ca213199/plugins/obs-ffmpeg/jim-nvenc.c#L481-L488
[00:20:13 CEST] <BtbN> I do still wonder why this jim-nvenc thing ever became a thing in the first place
[00:20:22 CEST] <BtbN> I don't see the advantage of duplicating it into OBS
[00:20:35 CEST] <Fenrirthviti> on-GPU encode is why
[00:20:36 CEST] <BtbN> It was added to implement d3d11 surface input, which ffmpeg can also do.
[00:20:45 CEST] <Fenrirthviti> not sure past that
[00:20:47 CEST] <BtbN> nevcairiel, added that ages ago
[00:21:15 CEST] <Fenrirthviti> This issue is still present in the version of ffmpeg we ship, fwiw (the bitrate padding issue)
[00:21:26 CEST] <nevcairiel> i found that while googling for some nvenc information, and i also wondered why it was seperate
[00:21:31 CEST] <Fenrirthviti> It's actually more pronounced in the ffmpeg nvenc than ours
[00:21:36 CEST] <nevcairiel> but i also know how such projects are
[00:21:43 CEST] <nevcairiel> trying to improve upstream is  effort, better clone i t
[00:21:48 CEST] <BtbN> So the only reason OBS duplicated mass amounts of code is because Jim didn't know nvenc in FFmpeg can take d3d11 surfaces
[00:22:15 CEST] <Fenrirthviti> Could be, yeah. You'd have to ask him.
[00:22:55 CEST] <BtbN> anyway, ffmpeg does set the relevant flags, anything beyond that is out of our control
[00:23:08 CEST] <nevcairiel> the CBR flags have also been set since like 2016
[00:23:11 CEST] <Fenrirthviti> yeah, I'm reasonably sure this is a nvidia problem as this point
[00:23:16 CEST] <nevcairiel> if OBS ffmpeg is older then that, you are in trouble anyway
[00:23:27 CEST] <Fenrirthviti> I have a post from you in 2014 saying that nvidia doesn't do padding as well, heh
[00:23:47 CEST] <nevcairiel> All I know is that I did a bunch of test encodes last week, and the bitrate came out perfect
[00:23:53 CEST] <BtbN> That was before someone at OBS found those magic two parameters that did enable padding
[00:23:56 CEST] <Fenrirthviti> It's not, no, we're on some commit in 4 I can't recall off the top of my head
[00:24:00 CEST] <BtbN> they were not documented to do so at that point in time
[00:24:03 CEST] <nevcairiel> but it was mostly live action movies or tv show content, so no still images or animations, so shrug
[00:24:27 CEST] <Fenrirthviti> yeah, it's really only noticeable with static images or very simple animations
[00:24:34 CEST] <Fenrirthviti> but easily replicable
[00:24:57 CEST] <Fenrirthviti> I appreciate the insight, I don't think it's a bug, I'm just trying to factfind so I can have the most informed conversation with them about it
[00:25:14 CEST] <jkqxz> jamrial:  What AV1 patches should I be looking at?
[00:26:38 CEST] <jkqxz> jamrial:  I also hacked in a way to do the parser change you suggested, but it's pretty horrible.  I'll send it in a bit and you can see what you think.
[00:27:49 CEST] <jamrial> jkqxz: the set i pinged during the weekend, starting with "add support for Padding OBUs"
[00:28:30 CEST] <jamrial> also "fix range of allowed values for obu_type" which is not in that set
[06:12:19 CEST] <cone-359> ffmpeg 03Steven Liu 07master:326cec3771f9: avformat/hls: make different warning message between open url and parse playlist
[07:53:01 CEST] <cone-359> ffmpeg 03Karthick J 07master:3d0894990d17: avformat/movenc: Fix skip_trailer when global_sidx is enabled
[07:53:02 CEST] <cone-359> ffmpeg 03Karthick J 07master:6aeaac3e1c40: avformat/dashenc: Add support for Global SIDX
[15:57:41 CEST] <sasshka> hey people, ffmpeg fails to compile on power pc
[15:57:45 CEST] <sasshka> it seems to fail only on LE
[15:58:26 CEST] <JEEB> not many of us have access to those systems; do you know which the cross-compiler is that's required and which distros have it?
[15:58:51 CEST] <sasshka> JEEB: I compiled on rhel
[15:59:10 CEST] <sasshka> libswscale/ppc/swscale_vsx.c: In function yuv2rgb_full_1_vsx_template:
[15:59:13 CEST] <sasshka> libswscale/ppc/swscale_vsx.c:527:9: error: invalid parameter combination for AltiVec intrinsic vy32_l = vec_mul(vy32_l, y_coeff); ^
[15:59:16 CEST] <sasshka> I can fix that
[15:59:33 CEST] <JEEB> fedora seems to have something
[15:59:34 CEST] <JEEB> ======================================================== Name & Summary Matched: ppc64le ========================================================
[15:59:37 CEST] <JEEB> gcc-ppc64le-linux-gnu.x86_64 : Cross-build binary utilities for ppc64le-linux-gnu
[15:59:40 CEST] <JEEB> gcc-c++-ppc64le-linux-gnu.x86_64 : Cross-build binary utilities for ppc64le-linux-gnu
[15:59:43 CEST] <JEEB> binutils-ppc64le-linux-gnu.x86_64 : Cross-build binary utilities for ppc64le-linux-gnu
[16:00:00 CEST] <JEEB> sasshka: I think some Finn (?) recently changed that stuff, you should ping him
[16:00:23 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=search;s=Lauri+Kasanen;st=author
[16:00:38 CEST] <JEEB> at least that seems related
[16:00:45 CEST] <sasshka> I see
[16:00:59 CEST] <sasshka> I could just report it to bugzilla or I could fix that
[16:01:06 CEST] <JEEB> so if you send out a patch you should CC that guy
[16:01:06 CEST] <sasshka> let me know what you prefer
[16:01:23 CEST] <JEEB> since he seems to be maintaining the VSX stuff
[16:08:07 CEST] <sasshka> JEEB: I'll write to him
[16:13:40 CEST] <durandal_1707> given set of 256 huffman code lengths - I want to write code which would generate all possible codes - how can i do that?
[16:37:52 CEST] <cone-815> ffmpeg 03James Almer 07master:b74e13711ff6: avcodec/opus: make redundancy_buf 32 byte aligned
[17:16:43 CEST] <j-b> heya
[17:26:01 CEST] <sasshka> j-b: hello
[17:26:09 CEST] <sasshka> j-b: any news about next VDD?
[17:47:48 CEST] <cone-815> ffmpeg 03Matthew Fearnley 07master:5dcc63c1d2d9: libavcodec/zmbv: use PTRDIFF_SPECIFIER for `src - c->decomp_buf`.
[17:47:49 CEST] <cone-815> ffmpeg 03Matthew Fearnley 07master:1046e880884b: libavcodec/zmbv: change 24-bit decoder channel order, from RGB24 to BGR24
[17:47:50 CEST] <cone-815> ffmpeg 03Matthew Fearnley 07master:b97a7dd03185: libavcodec/zmbvenc: add support for 24-bit encoding, using pix_fmt BGR24.
[21:21:51 CEST] <durandal_1707> given set of 256 huffman code lengths - I want to write code which would generate all possible codes - how can i do that?
[21:24:18 CEST] <durandal_1707> michaelni: know ^ answer?
[21:28:13 CEST] <atomnuker> are you sure those are huffman codes you want?
[21:28:25 CEST] <atomnuker> and not a golomb variant?
[21:29:15 CEST] <durandal_1707> huffman, it is called in binary that way
[21:29:52 CEST] <durandal_1707> binary have debug symbols
[21:30:27 CEST] <atomnuker> you should really extract the codes themselves too, since all combinations of bits for 256 bit-long codes would be a universe-ending amount of data
[21:32:49 CEST] <durandal_1707> bit lenghts are fixed, also i know first 8 bytes how it should look like when decoded
[21:34:11 CEST] <durandal_1707> atomnuker: it is not 256! it is some special number that depends on highest coded bit length
[21:34:42 CEST] <cone-185> ffmpeg 03James Almer 07master:461303f94ab6: avcodec/cbs_av1: fix parsing spatial_id
[21:34:45 CEST] <atomnuker> you still need to know the input bits to make an output map, or at least how to create them
[21:35:15 CEST] <durandal_1707> i know bit lenghts, that is enough info to create tree
[21:35:50 CEST] <durandal_1707> canonical one does not work (inverted bits or not)
[22:13:33 CEST] <kurosu> durandal_1707: do you have any idea if/when the tree building starts diverging from an optimal tree? or is the problem really that it is not canonical? because the remapping should be handled by sparse vlc init stuff (can't remember name) iirc
[22:15:27 CEST] <atomnuker> the vlc system still needs input bit arrays, it can only do purely sequential (1,2,3) in non-sparse mode or any 16-bit int in sparse mode
[22:17:45 CEST] <kurosu> sounds like a suboptimal tree is built - isn't magicyuv using one such or so? they trade off compression efficiency for decoding speed
[23:05:10 CEST] <cone-185> ffmpeg 03James Almer 07release/4.1:ec82b3ecbbff: avcodec/cbs_av1: fix parsing spatial_id
[00:00:00 CEST] --- Wed Apr  3 2019