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

[burek]

[00:06:24 CEST] <BtbN> it's not a script that's meant to be executed though
[00:08:43 CEST] <BtbN> oh wait, that one is
[00:09:14 CEST] <BtbN> weird, how is that working at all?
[00:11:36 CEST] <nevcairiel> iirc it'll just execute in the default shell if no bang is present
[00:57:21 CEST] <BtbN> but yeah, should probably have one
[11:57:10 CEST] <j-b> 'morning
[11:58:05 CEST] <durandal_1707> good day
[12:02:04 CEST] <j-b> durandal_1707: what's up, man?
[12:03:23 CEST] <kurosu> he's in a huff, man
[12:03:41 CEST] <kurosu> can't get his head around some vlc
[12:06:17 CEST] <durandal_1707> yea, i'm going learn cryptography skills, man
[13:14:46 CEST] <cone-185> ffmpeg 03Andreas Rheinhardt via ffmpeg-devel 07master:18a851aca766: avformat/matroskadec: Improve length check
[13:14:46 CEST] <cone-185> ffmpeg 03Michael Niedermayer 07master:2169a3f262be: avcodec/agm: Fix integer overflow with w/h
[15:19:53 CEST] <durandal_1707> michaelni: can one generate codes by simply doing something similar like deflate does for canonical codes, it simply shifts left by one position for higher bit lengths?
[15:22:19 CEST] <durandal_1707> in one case, there is code of 7 bits, and 9 codes of length 6 (min len is 6, max len is 11)
[15:23:41 CEST] <durandal_1707> some 7 length codes are 2a for 0 and a for 5
[15:24:15 CEST] <cone-185> ffmpeg 03Derek Buitenhuis 07master:772c73e61f5d: FATE: Add test for HEVC files that claim to have two first slices
[15:24:43 CEST] <durandal_1707> because code of 5 is a and there is 9 codes of lenght 6, i think it uses somethinkg like breath first traversal
[15:25:13 CEST] <durandal_1707> does my reasoning make sense?
[15:34:53 CEST] <J_Darnley> https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
[15:35:02 CEST] <J_Darnley> What utter lies from systemd.
[15:35:10 CEST] <J_Darnley> "predictable" my arse
[16:17:47 CEST] <kierank> J_Darnley: oh yes, fuck that so hard
[16:18:10 CEST] <JEEB> something that sounds OK in paper, but lol.
[16:18:15 CEST] <JEEB> (bases on the MAC address)
[16:19:33 CEST] <J_Darnley> I doubt they ever tried the claim "Stable interface names even when hardware is added or removed"
[16:20:15 CEST] <JEEB> well unless they derped it up it should be based on the hw mac address, which in all theory should be unique
[16:20:33 CEST] <JEEB> but I've never looked into the details and things have so far JustWorked
[16:20:34 CEST] <nevcairiel> i thought it was on the bus location
[16:20:39 CEST] <JEEB> oh
[16:20:44 CEST] <JEEB> could be
[16:20:54 CEST] <JEEB> as I said, I just have a vague idea of that thing
[16:21:22 CEST] <nevcairiel> its rather irritating if you say "predictable", but then design it on factors that you don't really know
[16:21:30 CEST] <nevcairiel> sure its predicatble, by the software, and thats it
[16:21:33 CEST] <JEEB> yes
[16:26:49 CEST] <jkqxz> The bus location sounds like a good idea, but unfortunately with PCIe the bus can get renumbered on pretty much any change.
[16:27:08 CEST] <jkqxz> Start with enp3s0, change something unrelated (not necessarily physical, could be BIOS setting), now it's enp4s0 and systemd refuses to let your system start because it can't bring up the network on enp3s0 and you need to init=/bin/sh to recover.
[16:52:16 CEST] <durandal_1707> why I do not get any comments?
[17:08:59 CEST] <durandal_1707> you are not smart enough to reply?
[17:09:01 CEST] <jamrial> durandal_1707: my guess is that no one that knows the answer read it
[17:44:03 CEST] <JEEB> why do people come up with new extensions for mp4
[17:44:05 CEST] <JEEB> cmfv, cmfa, cmft
[17:44:05 CEST] <JEEB> for "CMAF" mp4
[17:44:53 CEST] <gnafu> Big fans of country music?
[17:45:10 CEST] <JEEB> :D
[18:36:52 CEST] <michaelni> durandal_1707, building or updating a huffman code/tree can be done in _many_ ways, i cannot guess which one your codec (which i do not even know which codec that is) is using
[18:45:16 CEST] <durandal_1707> michaelni: tell some ways of building/updating tree you have in mind?
[18:45:39 CEST] <durandal_1707> not counting already known stuff available in lavc
[18:52:06 CEST] <michaelni> one can have a static tree change the order of the codes or remove and then insert a entry in the tree, something similar to how splay trees work maybe, one could keep track of statistics and when they chnage beyond a threshold recalculate the tree by any method. Knowing nothing about the codec its unlikely i will guess better than you. 
[18:54:58 CEST] <durandal_1707> michaelni: code lengths are new in every new frame, i assume that from this one can generate single binary tree that just have codes different in each branch, or there can be more than one huffman tree for same set of bit lengths?
[18:56:07 CEST] <michaelni> for one set of length you can make MANY valid codes
[18:56:17 CEST] <durandal_1707> yes i know that
[18:57:09 CEST] <durandal_1707> in each branch you can flip bit you will give to left or right child
[18:58:08 CEST] <durandal_1707> codec is agm, (missing features/code)
[19:00:20 CEST] <michaelni> there are more valid codes than just from fliping bits on nodes, you can change the structure too and end with the same lengths in many cases
[19:01:16 CEST] <michaelni> consider 16 codes of length 4 bits there are more permutations of 16 elements to 16 4bit codes than what one would get from just fliping bits at nodes
[19:03:55 CEST] <durandal_1707> what you mean by structure? the different look of tree?
[19:06:51 CEST] <michaelni> For example A and B could be leafs on a node and C and D could be leafs on another node. 3 bits to flip here but a totally different valid tree with identical lengths could have A and C leafs on a node and B and D leaves on a node which then connect together again with 3 bits on nodes to flip 
[19:09:44 CEST] <durandal_1707> could i derive same algo if i gather all codes?
[19:11:17 CEST] <michaelni> maybe, probably, ... i assume its not intentionally obfuscated with hard crypto ...
[22:24:51 CEST] <durandal_1707> michaelni: can you grasp what this function does: https://pastebin.com/MsVtRzMq  -- i'm lost around 63rd line
[22:26:34 CEST] <durandal_1707> basically code uses previously unset arrays
[22:27:05 CEST] <durandal_1707> perhaps from look you or someone else can dechipher it
[22:39:08 CEST] <michaelni> durandal_1707, access through aiStack7316 might actually go to aiStack6288 and aiStack7316 could be part of aiStack39056, that would make it a nicer size of 8192, but iam just guessing, that might eliminate one unset array
[00:00:00 CEST] --- Sat Apr  6 2019