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

Wed Jul 17 03:05:03 EEST 2019

[00:02:24 CEST] <durandal_1707> kierank: so how would you design new stuff? that is not trivial
[00:02:57 CEST] <kierank> durandal_1707: the way j-b doesn't like
[00:03:13 CEST] <nevcairiel> the way every other media framework works
[00:03:16 CEST] <kierank> "everything is a filter"
[00:03:44 CEST] <nevcairiel> everything has the same api, you just define what it accepts based on type information
[00:04:28 CEST] <Lynne> durandal_1707: you could write a new demuxer that nihs avi if the files are guaranteed to not be vfw or otherwise weird avi
[00:04:45 CEST] <Lynne> or hack avi, the whole format's a hack anyway
[00:06:54 CEST] <durandal_1707> Lynne: but that makes mixed h264+hevc within imm5 not nicely supported
[00:07:15 CEST] <nevcairiel> can it actually change frame by frame?
[00:07:30 CEST] <nevcairiel> who would make such a thing? :d
[00:07:43 CEST] <durandal_1707> users could concat files
[00:11:31 CEST] <jamrial> users could concat a lot of stuff. doesn't mean it needs to be supported
[00:12:01 CEST] <jamrial> if removing that consideration we can make this use an autoinserted bsf, then i think it would be much better
[00:12:18 CEST] <durandal_1707> nooooooooo!!!!!!!!!
[00:13:03 CEST] <kierank> already the case i think
[00:13:04 CEST] <kierank> with latm
[00:13:13 CEST] <kierank> can have concatenation of any aac flavour in latm
[00:13:49 CEST] <Lynne> wouldn't suprise me if the avi demuxer already deals with concat'd files
[00:14:33 CEST] <nevcairiel> thats why latm is its  own decoder that handles the latm header and then  invokes the aac decoder :d
[00:18:25 CEST] <durandal_1707> yes, i want to keep imm5_decoder
[00:22:28 CEST] <Lynne> no reason to have more unless there's no other way though
[00:22:45 CEST] <durandal_1707> there is no other way
[00:23:18 CEST] <durandal_1707> there is also imm6 (i need to find samples for it)
[00:23:30 CEST] <durandal_1707> i want we have imm4/imm5/imm6 combo
[00:24:02 CEST] <durandal_1707> besides tdsc alread uses jpeg in similar way
[00:35:28 CEST] <jamrial> are those IMM5_units hardcoded parameter sets NALUs?
[00:42:04 CEST] <nevcairiel> of course they are, dont you recognize a sps/pps when you see one? :D
[00:46:04 CEST] <mkver> durandal_1707: My review is up and contains a suggestion on how to avoid that imm5_buffer.
[00:46:43 CEST] <jamrial> mkver: he left
[00:47:25 CEST] <mkver> My bad.
[00:47:50 CEST] <jamrial> also, by growing the packet he would already be making it writable
[00:48:50 CEST] <mkver> He's growing the packet?
[00:49:19 CEST] <jamrial> no, your suggestion
[00:49:38 CEST] <jamrial> but maybe i misread what you said
[00:50:28 CEST] <mkver> I don't want to grow the packet; I intend to make it smaller (so that only the parts that need to be preserved (+ the desired size at the front) are preserved when the packet is made writable.
[00:50:44 CEST] <mkver> This is very similar to the truehd_core bsf.
[00:51:09 CEST] <jamrial> yeah, my bad, you said increment pkt->data and i mistakenly read it as growing the packet to insert the hardcoded bytes
[01:03:24 CEST] <mkver> Strange that neither of us complained that imm5_buffer never gets freed...
[01:37:37 CEST] <jamrial> there's a lot of stuff leaking in that patch :p
[01:37:49 CEST] <jamrial> i pointed a few, but yeah, missed that one
[01:45:58 CEST] <mkver> Speaking of memleaks, my mpeg4_unpack_bframes patch here: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-July/246435.html fixes a memleak (of side data) that an earlier patch of yours created.
[01:47:37 CEST] <jamrial> not sure how many scenarios can there be with side data here, but nice catch
[01:51:33 CEST] <mkver> The probability of side data leaking is so big that you explicitly mentioned it in the commit message of bd60116794b4baaf9a6fedfc68cb1ac4a383bb2d :D
[02:05:17 CEST] <jamrial> not big, just there :p
[11:14:51 CEST] <durandal_1707> how to copy dictionary options from one avctx to another?
[11:18:11 CEST] <JEEB> hmm, request_channel_layout... does that actually do downmix in AC3 or does it only set the coeffs etc?
[11:18:38 CEST] <JEEB> or more specifically, does it apply the DRC that the stream might have info on
[11:18:44 CEST] <nevcairiel> it doesnt downmix as such, if a format contains substreams with an embedded downmix, it'll only decode those
[11:18:51 CEST] <JEEB> ah
[11:18:54 CEST] <JEEB> alrighty
[11:20:45 CEST] <nevcairiel> actually for ac3 it sort-of downmixes, using downmix coefficients in the ac3 stream
[11:22:27 CEST] <nevcairiel> overall that option is very rarely used :d
[11:24:55 CEST] <JEEB> yea, I just noticed it because there were FATE tests
[11:25:01 CEST] <JEEB> (for ac3 specifically)
[11:25:37 CEST] <JEEB> I am doing DRC/normalization post downmix usually, but I wonder if this gives a "closer" result to what the plastic boxes do for 5.1->stereo for example :P
[11:30:33 CEST] <rcombs> durandal_1707: the avctx doesn't keep around its options as an AVDictionary at runtime; you'd need to iterate the AVOptions table and read them manually, I'd expect
[11:31:05 CEST] <nevcairiel> I wouldnt really bother with that outside of a few key options like maybe threading
[11:33:37 CEST] <kurosu> Wow, that #8022 is something...
[11:34:05 CEST] <kurosu> I'd be headdesking if the guy was not obviously clueless and meaning well
[11:34:23 CEST] <nevcairiel> not sure how he even got to that conclusion
[11:36:10 CEST] <kurosu> Well, you have to start somewhere, and that somewhere is probably often this, or "compilers have known about this for years"
[21:50:16 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:27f40b1dcdff: avformat/matroskadec: Don't abort resyncing upon seek failure
[21:50:17 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:310f326b4354: avformat/matroskadec: Add function to reset status
[21:50:18 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:8a286e745d0e: avformat/matroskadec: Use proper levels after discontínuity
[21:50:19 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:559e3422c78b: avformat/matroskadec: Refactor some functions
[21:50:20 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:a3db9f62a42a: avformat/matroskadec: Introduce a "last known good" position
[21:50:21 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:c1abd95ad096: avformat/matroskadec: Link to parents in syntax tables
[21:50:22 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:b31c9b72e5e6: avformat/matroskadec: Redo level handling
[21:50:23 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:865c5370078f: avformat/matroskadec: Make cluster parsing level compatible
[21:50:24 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:a9f051519e2a: avformat/matroskadec: Don't reset cluster position
[21:50:25 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:38255cdcf815: avformat/matroskadec: Combine arrays
[21:50:26 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:3ed2755baaf3: avformat/matroskadec: Redo EOF handling
[21:50:27 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:7087fc95b258: avformat/matroskadec: Reuse positions
[21:50:28 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:60f75c997636: avformat/matroskadec: Typos, nits and cosmetics
[21:50:29 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:512030513743: avformat/matroskadec: Don't skip too much when unseekable
[21:50:30 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:04b62bd7ceb4: avformat/matroskadec: Improve invalid length error handling
[21:50:31 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:3c70b941d5d1: avformat/matroskadec: Accept more unknown-length elements
[21:50:32 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:9c6d14ab84e4: avformat/matroskadec: Fix probing of unknown-length headers
[21:50:33 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:71c908817ec6: avformat/matroskadec: Accept more unknown-length elements II
[21:50:34 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:6854127a7698: avformat/matroskadec: Reindent after previous commit
[21:50:35 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:730ac1ae8039: avformat/matroskadec: Use file offsets for level 1 elements
[21:50:36 CEST] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:806ac7da6927: avformat/matroskadec: Improve check for level 1 duplicates
[21:51:29 CEST] <jamrial> bogus annoying warning gone
[21:54:00 CEST] <kurosu> one patch per character removed ? :D
[21:54:30 CEST] <kurosu> more seriously, would the author consider submitting samples to test each fix (or some)
[21:54:43 CEST] <jamrial> mkver: ^
[21:55:10 CEST] <mkver> I didn't think that you would commit all in one go.
[21:56:40 CEST] <jamrial> i didn't. this is half the patchset after all :p
[21:56:53 CEST] <mkver> lol
[23:18:22 CEST] <JEEB> howaboutsynergy: anyways you'd probably get a lot more traction by explaining what bad is happening to you without the patch etc
[23:18:38 CEST] <JEEB> by itself that thread on hte trac issue is mostly about API misuse
[23:18:44 CEST] <JEEB> or that's how it seems to be
[23:19:05 CEST] <howaboutsynergy> well I don't remember :D I thinkn that some video(s) had bit size 0 and somewhere later the buffer wouldn't be NULL and it would be accessed
[23:20:01 CEST] <howaboutsynergy> so maybe, if someone would set bit size 0 somehow in the video file, some weird hacks could be constructed? 
[23:20:21 CEST] <howaboutsynergy> anyway, I've been using that patch ever since, so maybe that's why I haven't encountered anything since then
[23:20:44 CEST] <howaboutsynergy> here's links (on this channel also): https://trac.ffmpeg.org/attachment/ticket/4749/handlebit_size0.patch  or a more up to date(with git) one: https://github.com/howaboutsynergy/q1q/blob/998b270964ea1ca79ecc2d94e7a43624c66ebe96/OSes/archlinux/home/user/build/1packages/4used/ffmpeg/30/ffmpeg-git/handlebit_size0_v2.patch#L1
[23:21:16 CEST] <howaboutsynergy> wish I had a reproduction video or something, but to a dev. the patch should be self-explanatory, me thinks
[23:21:49 CEST] <durandal_1707> give proper patch or nobody takes you seriously
[23:21:52 CEST] <JEEB> well, without context just looking at that diff and the trac issue thread
[23:22:10 CEST] <howaboutsynergy> yeah ok, my bad, sorry for the trouble:)
[23:22:21 CEST] <JEEB> esp. the place where the original author of the patch notes that he has no idea if that value actually happened or not
[23:22:23 CEST] <durandal_1707> off course patch is fine
[23:22:32 CEST] <JEEB> well great there durandal_1707 
[23:22:55 CEST] <JEEB> it might have ended with no info from the person, but yunno
[23:23:08 CEST] <JEEB> you made sure that happened, kinda :P
[23:24:23 CEST] <durandal_1707> i do not think our bitreader would choke on 0 size of bitstream
[23:24:55 CEST] <durandal_1707> at best, few invalidreads would happen
[23:25:12 CEST] <JEEB> well that's why I was trying to figure out the context :P esp. since https://trac.ffmpeg.org/ticket/4749 had weird comments about zero not actually happening to the guy etc
[23:25:33 CEST] <JEEB> if the guy couldn't provide any context to the change, too bad
[23:26:45 CEST] <durandal_1707> also that patch does not apply any more ...
[23:27:25 CEST] <JEEB> the github one seemed to be the version he was keeping up-to-date
[23:27:49 CEST] <JEEB> durandal_1707: also I'm not trying to say the patch is valid :P I was trying to figure out /why/ that change would have been done
[23:28:06 CEST] <JEEB> -> getting the "why" usually helps trying to figure if the change is right
[23:28:20 CEST] <JEEB> esp. given the context of the ticket I wanted to ask him why he was applying that patch still :P
[23:31:58 CEST] <durandal_1707> ask him via creating issue on his github page
[23:32:27 CEST] <JEEB> I don't care /that/ much. he was here after all, so that was close to zero effort :P
[23:32:36 CEST] <durandal_1707> its probably remnant of old days when we would not check for return values of init_get_bits or size of input packet
[23:32:36 CEST] <JEEB> at this point we have driven him out
[23:32:46 CEST] <JEEB> durandal_1707: quite possible
[23:34:13 CEST] <durandal_1707> anyway 0 bitsize is pointless so should error out early anyway, maybe michaelni want to comment?
[00:00:00 CEST] --- Wed Jul 17 2019