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

[burek]

[00:04:37 CEST] <cehoyos> michaelni: Patch sent
[01:08:04 CEST] <cone-831> ffmpeg 03Michael Niedermayer 07master:0ad0533e914a: avcodec/truemotion2: Fix integer overflow in tm2_decode_blocks()
[01:37:59 CEST] <cehoyos> michaelni: So is the patch ok or do I misunderstand?
[01:43:59 CEST] <michaelni> cehoyos, i think if you want to maintain the unused C64/FIX64 code working without changing it then uint16 instead of int16 is needed or some other change
[01:45:07 CEST] <michaelni> C64() does not work with a negative signed argument as it is implemented ATM
[01:46:12 CEST] <cehoyos> I didn't change C64() or did I?
[01:47:45 CEST] <cehoyos> And FIX64 is unused
[12:49:06 CEST] <faLUCE> Hello. When patching makefiles, how can I re-indent? I was told to avoid TABs
[12:56:07 CEST] <thilo> IIRC Makefiles are an exception to the no-tabs rule for their syntax
[12:58:12 CEST] <faLUCE> thilo: yes, in factI read "The TAB character is forbidden outside of Makefiles as is any form of trailing whitespace. Commits containing either will be rejected by the git repository."
[12:59:12 CEST] <atomnuker> use spaces.
[12:59:14 CEST] <faLUCE> thilo: but carl suggested yesterday to avoid re-indentation of makefiles
[12:59:22 CEST] <atomnuker> yes, use spaces.
[12:59:26 CEST] <faLUCE> atomnuker: ok thanks
[13:13:34 CEST] <faLUCE> when a patch includes ffmpeg/dir1/file1 and  ffmpeg/dir2/file2,   which is the command for making one patch that includes both the modified files?
[13:13:51 CEST] <faLUCE> (on the master)
[13:17:43 CEST] <JEEB> git add dir1/file1 dir2/file2
[13:17:50 CEST] <faLUCE> thnx
[13:17:51 CEST] <JEEB> git commit
[13:18:18 CEST] <JEEB> then mkdir -p patches/ && git format-patch -o patches REMOTE/master..HEAD
[13:18:24 CEST] <JEEB> REMOTE is usually by default origin
[13:18:58 CEST] <JEEB> and generally it probably is worth it to make your own work-in-progress branch that your local master isn't with your own changes
[13:20:41 CEST] <faLUCE> JEEB: wait, too many things :-) .  1)  [13:18] <JEEB> then mkdir -p patches/ && git format-patch -o patches REMOTE/master..HEAD  <--- what exactly does this command?
[13:22:27 CEST] <JEEB> faLUCE: the && runs the other one if the first one succeeds. so you make a directory called "patches", and then the -o parameter in format-patch outputs there
[13:23:01 CEST] <JEEB> and the REMOTE/master..HEAD part takes the hash of REMOTE/master and outputs patches for all commits that are locally in your tree until HEAD
[13:23:06 CEST] <JEEB> HEAD being the current working tree tip
[13:24:05 CEST] <JEEB> you can take a look at what `git show HEAD` outputs as an example
[13:27:35 CEST] <faLUCE> JEEB: OK, but given that I would not use git-send-email, where the email info, description of the patch etc. well be put?
[13:27:44 CEST] <JEEB> format-patch outputs that
[13:28:20 CEST] <JEEB> git diff outputs a simple patch without authorship/commit message etc
[13:28:34 CEST] <JEEB> git format-patch outputs proper `git am`'able commits
[13:48:31 CEST] <faLUCE> ok JEEB, thnks, I have to learn more about that
[14:19:05 CEST] <JEEB> does anyone remember if VP9 kept state over RAPs?
[14:19:19 CEST] <JEEB> so if you just try to cut a VP9 stream over RAPs that you could get corruption
[14:19:32 CEST] <JEEB> or more specifically, starting with a RAP in the middle of the stream
[14:39:21 CEST] <jkqxz> A key frame in VP9 clears all state.
[14:39:41 CEST] <JEEB> ok, so cutting and then stitching on a RAP should be OK then
[14:40:06 CEST] <JEEB> I don't remember which format I was talking about where this was not true and the coder state was dependant on previous frames
[14:40:16 CEST] <JEEB> on of the VPx or AV1
[14:40:34 CEST] <jkqxz> Nothing would stop you marking a non-key intra-only frame as a RAP in VP9, but I don't think anyone does that.
[14:41:05 CEST] <BBB> av1 has invisible keyframes
[14:41:10 CEST] <BBB> which don't clear state until they become visible
[14:41:15 CEST] <BBB> as a show-existing-frame reference
[14:41:20 CEST] <BBB> and then hevc also of course
[14:41:22 CEST] <JEEB> yea, I was mostly considering correctly mapped pictures
[14:41:54 CEST] <JEEB> ok, then I wonder why I remember there being a thing about not being able to cut some formats
[14:42:09 CEST] <JEEB> thanks
[14:43:47 CEST] <jkqxz> H.26[45] both allow non-decodable leading pictures before a non-IDR RAP (and H.265 explicitly marks them with a different NAL unit type).
[14:43:59 CEST] <JEEB> yup
[14:47:46 CEST] <atomnuker> BBB: so an encoder could in theory fill all invisible frame slots and then never show them even after a keyframe?
[14:49:12 CEST] <atomnuker> I seem to remember that was because of some closed gop thing, but having a broken file hog decoder memory isn't cool
[14:49:44 CEST] <BBB> yes
[14:49:46 CEST] <jkqxz> Showing a key frame clears all frame slots at the point it is shown.
[14:49:47 CEST] <BBB> it's a delayed clear-state
[14:50:07 CEST] <BBB> you can do all sort of weird stuff with this
[14:50:15 CEST] <BBB> but mostly it's both dumb and innocent
[14:50:23 CEST] <BBB> so it's ok I guess
[14:50:29 CEST] <BBB> it's not like you can break your hardware or something
[14:53:14 CEST] <atomnuker> well, filling all ref frame slots is difficult to do in av1 in the first place, so yeah, not much danger
[14:55:20 CEST] <atomnuker> the sequence and naming was something completely illogical, and I'm too lazy to dig up the 2 crazy flowcharts google made to further confuse everyone
[14:55:46 CEST] <durandal_1707> atomnuker: what's up?
[14:55:47 CEST] <JEEB> anyone wants to look at a supposed sample of 22.2ch LATM AAC?
[14:56:46 CEST] <atomnuker> durandal_1707: trying to fully complete gta san andreas
[14:56:59 CEST] <JEEB> that's a fun one
[14:57:17 CEST] <JEEB> not 100% sure it's valid since the provider isn't sure of the crypto but it does get as far as noting that multiple programs are not yet supported
[14:59:18 CEST] <durandal_1707> atomnuker: stop wasting time on stupid games
[15:20:49 CEST] <cone-372> ffmpeg 03Steven Liu 07master:b18c8688dd4f: avformat/hlsenc: flush packets before update split message
[18:10:57 CEST] <philipl> JEEB, haasn: So this crap is harder than it looks. If I rename the ta_* functions from xtalloc, it will compile. I couldn't do a full static mpv build because many of the dependencies don't have static versions in Ubuntu. So I tried just linking a static libplacebo.
[18:12:02 CEST] <philipl> That actually linked after the renames, but blows up at runtime because there are symbol conflicts with spriv_shader.c which exists in both code bases. Strangely it doesn't fail at link time.
[18:12:13 CEST] <philipl> but it ends up calling the mpv version which then fails - no surprises.
[18:12:26 CEST] <JEEB> probably wrong channel but ouch :/
[18:12:38 CEST] <philipl> whoops.
[18:12:43 CEST] <philipl> I will repeat in the right channel.
[20:55:31 CEST] <cone-285> ffmpeg 03James Almer 07master:62074b8f85e0: avcodec/cbs_av1: add a function to strip trailing zeroes from a buffer size
[20:55:32 CEST] <cone-285> ffmpeg 03James Almer 07master:1f260d7285c8: avcodec/cbs_av1: add support for Padding OBUs
[21:22:58 CEST] <thardin> so I'm staring at mxf_read_sync() and it seem it'll behave incorrectly for any UL which contains 0x06 in places beyond index 0
[21:25:37 CEST] <thardin> baptiste: do we have any sample that uses say mxf_crypto_source_container_ul[] ?
[21:27:04 CEST] <baptiste> Im afraid not :(
[21:27:43 CEST] <thardin> mxf_sony_mpeg4_extradata as well
[21:28:01 CEST] <thardin> ah but that has a fate sample. hmmm
[21:28:49 CEST] <thardin> I *really* don't like that sync thing being used for anything besides run-in
[21:33:40 CEST] <thardin> I see it works because both of those are local tags
[22:57:42 CEST] <thardin> hum hum.. who in here had knowledge about protools again?
[23:13:53 CEST] <jamrial> jkqxz: adding support for Scalability Metadata obu to cbs_av1 should be trivial, but it will probably increase the struct size considerably
[23:13:58 CEST] <jamrial> do you think it's worth doing?
[23:14:58 CEST] <jkqxz> Have you found anything which uses it?
[23:15:18 CEST] <jamrial> no, that's why i'm not sure it's worth implementing it :p
[23:15:38 CEST] <jamrial> although something has to be first, right? :p
[23:16:10 CEST] <jkqxz> Yeah, that was my position too.
[23:16:36 CEST] <jamrial> the couple samples i saw using more than one spatial/temporal layers didn't have it
[23:17:23 CEST] <jkqxz> If you want to do it then go ahead, but I'm happy to wait and see if anyone ever uses it.
[23:17:49 CEST] <jamrial> i wouldn't mind if it wasn't so big. the struct will be like 8kb alone
[23:19:06 CEST] <jkqxz> How big is the current largest thing in the OBU union?
[23:20:45 CEST] <jkqxz> If all the stuff in frame header is already bigger than that then it doesn't make a difference.
[23:23:55 CEST] <jamrial> let me check
[23:24:25 CEST] <jamrial> biggest is frame, 1k
[23:28:58 CEST] <cone-285> ffmpeg 03Marton Balint 07master:f9840cd2b501: avformat/mxfdec: use operational_pattern_ul instead of operational_pattern for metadata
[23:48:01 CEST] <jamrial> jkqxz: my bad, with the new struct it will be ~3k, no 8k
[23:48:08 CEST] <jamrial> considerably bigger than frame still, but not that bad
[00:00:00 CEST] --- Mon Apr 15 2019