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

[burek]

[03:58:49 CET] <agrecascino> okay so uh
[03:58:50 CET] <agrecascino> i messed it up 
[03:58:53 CET] <agrecascino> as in i probably should read documentation
[03:58:56 CET] <agrecascino> so uhm
[03:58:57 CET] <agrecascino> before i mess it up again
[03:59:42 CET] <agrecascino> nevermind
[04:01:12 CET] <agrecascino> okay i have a new question 
[04:02:11 CET] <agrecascino> so offset at the end of mov_read_sidx = initial + atom.size + offset of item
[04:02:19 CET] <agrecascino> + offsets in references
[04:02:30 CET] <agrecascino> actually i really have no idea what i'm doing
[04:02:34 CET] <agrecascino> :thonk:
[04:02:42 CET] <agrecascino> *raises their hand*
[04:02:52 CET] <agrecascino> can someone explain to me how the mp4 parser thing works?
[04:03:02 CET] <agrecascino> or at least how mov_read_sidx is supposed to work
[04:06:41 CET] <agrecascino> first offset = 0 in the failing test
[04:06:46 CET] <agrecascino> but 52 in the problem file
[04:06:58 CET] <agrecascino> which causes the "duplicated offset" issue
[04:07:36 CET] <agrecascino> because the offset points to the moof and there's a second sidx between the moof
[04:07:41 CET] <agrecascino> and the other sidx
[04:07:55 CET] <agrecascino> and since that's added to offset it pretends as if the second sidx doesn't exist
[04:08:02 CET] <agrecascino> and everything breaks like that
[04:09:11 CET] <agrecascino> because in that adding the first_ref makes it so that equals the file size
[04:09:52 CET] <agrecascino> so i don't really know why anything is happening but my spidey senses say adding first_ref is a bad
[04:10:27 CET] <agrecascino> but it seems sane?
[04:10:47 CET] <agrecascino> like commenting random stuff shouldn't be a "fix"
[04:13:38 CET] <agrecascino> like part of me is wondering if the file encoded is wrong?
[04:13:50 CET] <agrecascino> or maybe i'm just not getting any of this because i'm new
[04:15:40 CET] <agrecascino> like from what i'm looking at first_offset is 52 because both are pointing at the same moof and mdats and the offset is for them being 52 bytes ahead in the file
[04:15:42 CET] <agrecascino> which is 
[04:15:44 CET] <agrecascino> correct?
[04:15:59 CET] <agrecascino> i mean the math works out and we reach the end of the file but like
[04:16:10 CET] <agrecascino> that's not correct in that we ignore the second sidx
[04:20:31 CET] <cone-061> ffmpeg 03Jun Zhao 07master:6dc06e979c38: doc/filters: document ranges and defaults for nlmeans options
[11:02:45 CET] <JEEB> agrecascino: check out something like L-SMASH's boxdumper (`boxdumper --box FILE`) for an alternative dump of what's inside the file. compare that to the spec. you should probably have a better idea after that
[11:44:13 CET] <durandal_1707> gstreamer all the things
[13:30:20 CET] <JEEB> can someone remind me where under libavcodec the documentation is?
[13:30:37 CET] <JEEB> as in, if I add a new decoder, where do I stick its docs?
[13:32:44 CET] <nevcairiel> doc/decoders.texi?
[13:32:49 CET] <JEEB> danke
[13:33:01 CET] <nevcairiel> the list is underwhelmingly incomplete however
[13:33:05 CET] <JEEB> yea
[13:33:25 CET] <JEEB> I just thought I'd do this kind of properly this time :P esp. since I have two AVOptions
[13:37:36 CET] <JEEB> btw did we have any helper function to do something like
[13:37:39 CET] <JEEB> `(int)round(((double)region->i_fontwidth / (double)profile_font_size) * 100)`
[13:38:14 CET] <JEEB> (gets the % of how large the width is compared to the default width)
[14:32:41 CET] <JEEB> alright, tweaked my upstreaming branch a bit, and posted
[15:27:37 CET] <JEEB> not surprisingly the first response was "can't we just internalize this library" :) which unfortunately seems to be a 'no' due to its license. I did mention alternatives, but they'd have to be rewritten at least partially to be usable :/
[17:07:39 CET] <agrecascino> https://my.mixtape.moe/rdxsje.png
[17:07:42 CET] <agrecascino> like
[17:08:14 CET] <agrecascino> both sidx[1].position + .size + .offset + .reference_size = 7131
[17:08:16 CET] <agrecascino> and
[17:08:30 CET] <agrecascino> sidx[0].position + .size + .offset + .reference_size
[17:10:15 CET] <agrecascino> because they point to the same moof and mdat boxes
[17:10:46 CET] <JEEB> one of them is clearly for the audio (timescale 48000)
[17:10:58 CET] <JEEB> what's the definition of the reference_ID
[17:11:26 CET] <agrecascino> *runs to find the standard*
[17:11:52 CET] <JEEB> https://standards.iso.org/ittf/PubliclyAvailableStandards/index.html
[17:11:54 CET] <JEEB> as noted on the ML
[17:11:58 CET] <agrecascino> i have it open
[17:12:01 CET] <JEEB> alright
[17:12:01 CET] <JEEB> Ö=
[17:12:02 CET] <JEEB> :)
[17:12:16 CET] <JEEB> it's nice that some of the ISO/IEC specs are free
[17:13:07 CET] <agrecascino> they have different reference ids?
[17:13:28 CET] <agrecascino> actually 
[17:13:30 CET] <agrecascino> well
[17:13:53 CET] <agrecascino> the second first one reference a sidx box before the first moof
[17:14:01 CET] <agrecascino> as that one has reference_id = 1
[17:15:29 CET] <JEEB> yes that's the first difference I noticed when looking at the field
[17:15:35 CET] <JEEB> first had a reference_ID of 1, the second 2
[17:17:48 CET] <agrecascino> like i'm not entirely sure how to solve this without 2 passes or like
[17:18:06 CET] <agrecascino> changing the exit condition
[17:21:14 CET] <agrecascino> like you could possibly have the exit condition check if the ref_id == last_track_id
[17:21:30 CET] <agrecascino> but unless the order is mandated in the standard that would only kinda work
[19:00:23 CET] <cone-289> ffmpeg 03Paul B Mahol 07master:9e0e8e10c7b4: avfilter/vf_mix: add timeline support to tmix filter
[19:00:24 CET] <cone-289> ffmpeg 03Paul B Mahol 07master:08b83bf82893: avfilter/vf_mix: always output frame if array is filled
[19:55:22 CET] <durandal_1707> what is RIST?
[19:56:39 CET] <JEEB> I think I had a PDF about that open some time ago... let me check
[19:58:49 CET] <JEEB> ugh, pretty sure I closed a tab like that today, but I can't find it from my history :|
[19:59:29 CET] <JEEB> some RTP like spec if I recall correctly
[20:13:28 CET] <agrecascino> someone just mailed another fix but
[20:13:39 CET] <agrecascino> i'm also not sure if it's correct in the sense that it only really prevents the hanging but doesn't really fix the reason behind that hang?
[20:14:11 CET] <JEEB> not sure what you're talking about, but welcome to "let's just make something 'work'" sort of stuff
[20:14:14 CET] <agrecascino> but i think i fixed the not loading all the sidx atoms part and i still that it hanged so
[20:14:32 CET] <agrecascino> maybe it is correct
[20:15:14 CET] <JEEB> sounds like you have to give it some extra thought then :)
[20:15:34 CET] <agrecascino> yeah uhm
[20:15:40 CET] <agrecascino> all the fragments actually seem to be loaded
[20:16:02 CET] <agrecascino> as of this dumb patch thing
[20:16:47 CET] <agrecascino> nope wait nevermind
[20:16:51 CET] <agrecascino> the last fragment is still just
[20:16:52 CET] <agrecascino> nonsense
[20:17:12 CET] <agrecascino> actually correction it isn't 
[20:17:13 CET] <agrecascino> i think
[20:17:40 CET] <agrecascino> yeah it's all there actually so
[20:18:13 CET] <cone-289> ffmpeg 03Shiyou Yin 07master:0c43429210d6: avcodec/mips: [loongson] optimize put_hevc_qpel_uni_hv_8 with mmi.
[20:18:14 CET] <cone-289> ffmpeg 03Shiyou Yin 07master:c0942b7a2c5c: avcodec/mips: [loongson] optimize put_hevc_epel_bi_hv_8 with mmi.
[20:18:15 CET] <cone-289> ffmpeg 03Shiyou Yin 07master:dceefb2b84b3: avcodec/mips: [loongson] optimize put_hevc_qpel_bi_h_8 with mmi.
[20:18:16 CET] <cone-289> ffmpeg 03Shiyou Yin 07master:b429c86d84cf: avcodec/mips: [loongson] optimize put_hevc_qpel_h_8 with mmi.
[20:19:03 CET] <agrecascino> one bug kinda fixed and another seemingly still there
[20:22:24 CET] <agrecascino> ah actually this is part of the bug
[20:22:40 CET] <JEEB> :)
[20:23:13 CET] <agrecascino> in the sense that their patch actually fixes an issue where since the fragment data for each track is split per sidx
[20:23:21 CET] <agrecascino> and mine makes it so the last sidx box is actually read
[20:25:52 CET] <agrecascino> i still don't like the way mine works and i think it's kind of a hack but i'm not really sure how to do it otherwise considering any consecutive sidx boxes pointing to the same whateverthatoneboxiscalled at the end of the file would leave the offset at the end of the file
[20:26:18 CET] <agrecascino> unless the spec mandates somewhere that the consecutive sidx boxes are put in order of track id
[20:29:27 CET] <agrecascino> like we're looking for sidx data in fragment 1 for stream 1 when it only exists in 0 and 3 
[20:29:54 CET] <agrecascino> so the patch is right, maybe not in implementation but idk what the heck i'm talking about
[20:31:32 CET] <agrecascino> actually there's absolutely no issue in the first place what
[20:32:25 CET] <agrecascino> wait nevermind
[20:32:47 CET] <JEEB> just take your time :)
[20:32:59 CET] <JEEB> these things are not simple and there are various gotchas
[20:33:03 CET] <agrecascino> actually 
[20:33:09 CET] <agrecascino> okay with just my patch it's working now
[20:33:15 CET] <agrecascino> am i still alive
[20:33:35 CET] <JEEB> thankfully there's things like boxdumper that help you get a second view on the file
[20:33:35 CET] <agrecascino> alright uhm
[20:33:41 CET] <JEEB> (or DVBInspector for MPEG-TS)
[20:33:50 CET] <agrecascino> i just used an online parser thing
[20:33:56 CET] <agrecascino> err
[20:34:09 CET] <agrecascino> anyway i don't really know what's happening but it's loading all the sidx stuff now
[20:34:16 CET] <agrecascino> and not hanging
[20:34:38 CET] <agrecascino> i just really think this is a hack
[20:37:16 CET] <agrecascino> well uhm
[20:37:18 CET] <agrecascino> the test passes
[20:44:57 CET] <agrecascino> uhm
[20:46:54 CET] <agrecascino> ok so is number of movie fragments * track count a robust count of sidx boxes
[20:51:02 CET] <agrecascino> nope the spec is way too vague for that
[20:51:13 CET] <thardin> https://www.wired.com/story/finding-lena-the-patron-saint-of-jpegs/ 
[20:52:52 CET] <agrecascino> JEEB, the parser for mp4 files in ffmpeg is one pass right?
[20:53:31 CET] <JEEB> it does seek to places as far as I know
[20:53:40 CET] <JEEB> since it can read the moov atom from the end of the file for example
[20:53:52 CET] <agrecascino> ok so uhm
[20:54:07 CET] <agrecascino> i'm not sure i should be making parser changes like this but
[20:54:23 CET] <agrecascino> i think i need to add a step to count the number of sidx boxes
[20:54:45 CET] <agrecascino> because like of how absolutely sinfully vague the spec is there can be like
[20:54:52 CET] <JEEB> you can always post an RFC or something on the ML
[20:58:10 CET] <agrecascino> like the spec says a segment index provides information for one media stream and should document the entirety of the stream
[20:58:42 CET] <agrecascino> but also says that segment indexes can be present for less than all streams
[00:00:00 CET] --- Sun Feb  3 2019