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

[burek]

[00:17] <ramiro> how do I tell ffmpeg I want the input to my muxer to be interlaced?
[00:45] <ubitux> BBB: hey, look where the comment above update_prob() ended up ;)
[00:58] <cone-876> ffmpeg.git 03Jan Gerber 07master:f4b1ca99ff86: lavf/matroska*: DiscardPadding is a signed integer
[01:12] <bernt> Howdy
[01:16] <bernt> I'm seeing a discrepancy in a webm movie file relating to presentation time time codes, and the number of audio samples I'm actually pulling out of the audio decoder per second.  Seems like the real average samples per second that I'm getting is higher than what the audio header is tells me (44100 samples per sec).  When I measure the number of samples I get as they are spaced out between simple audio blocks... (hope that makes sense
[01:18] <wm4> bernt: I think I've seen that before...
[01:18] <wm4> and there was a hack in ffmpeg which fixed it
[01:18] <bernt> oh?
[01:19] <bernt> Hmm.
[01:19] <wm4> look for trust_default_duration in the source
[01:19] <wm4> that's about timestamps though
[01:19] <bernt> trust_default_duration -- yeah.  I'll take a look.
[01:20] <wm4> some broken muxers apparently set an incorrect defaultduration, which leads to incorrect timestamps for "sub" blocks
[01:20] <clever> aha, the for loop in get_pixel_format for h264_hwaccel_pixfmt_list_420 does absolutely nothing
[01:20] <clever> it just fails out and calls ff_thread_get_format
[01:21] <bernt> Just to be clear:  What I'm doing (for sanity checking) is I keep track of the previous computed presentation time and subtract it from the currently computed presentation time, and the look at the actual samples I pulled out of the vorbis decoder.  The samples over the time difference should be very very close to 44100 samples per second in theory, but it's kind of off.... over time it looks like it trends towards 44100 but I'm gett
[01:22] <clever> ahhhh, get_pixel_format sends that hwaccel list to ff_thread_get_format
[01:23] <wm4> bernt: your line has been cut off
[01:23] <wm4> ... "over time it looks like it trends towards 44100 but I'm gett"
[01:24] <bernt> wm4: sorry.  Using a new irc client.  Guess it sucks. :/
[01:24] <clever> 512 character max
[01:24] <bernt> wm4: I wrote: over time it looks like it trends towards 44100 but I'm getting 'sloppy values'
[01:25] <wm4> a matroska block contains multiple audio packets, and only the first packet has a timestamp (the timestamp for the block)
[01:26] <wm4> the demuxer calculates the timestamps for the other packets from the defaultduration, which specifies how long an audio packet is
[01:26] <bernt> wm4: yep.
[01:26] <wm4> so if the defaultduration is wrong, you could easily get broken timestamps
[01:26] <wm4> like timestamps for a different sample rate
[01:26] <wm4> could this be what you're seeing?
[01:27] <bernt> wm4: maybe, yeah.  Let me check that trust_default_duration thing.
[01:27] <wm4> that trust_default_duration was added as a hack for a single broken file
[01:28] <bernt> wm4: really?!
[01:28] <wm4> (frankly, I'm wondering why that mechanism is even needed... pts should just not be set for these packets)
[01:28] <llogan> ramiro: what muxer?
[01:28] <wm4> bernt: there was a failing sample on the bug tracker, and someone fixed it; that's what happened
[01:28] <bernt> vorbis (webm)
[01:31] <bernt> wm4: looks like I'm seeing the trust_default_duration in matroskadec.c (decoder) -- I'm seeing my issue in my own code / decoder (just using ffmpeg for encoding).  Likely this is something I'm doing wrong myself then.
[01:32] <wm4> bernt: can you share the sample?
[01:32] <cone-876> ffmpeg.git 03Jan Gerber 07master:8cc59ec881b8: lavf/matroskadec ReferenceBlock is a signed integer
[01:33] <bernt> yeah sure.
[01:35] <bernt> wm4: http://dj2n21n35mw4x.cloudfront.net/video/0C021A8E-C006-4078-A8BC-0E83E343342A/video_6aeda12e4059aecda6facc721a24abee_vp8.mkv
[01:36] <bernt> wm4: that's actually a wemb file.  I never bothered to change it to .webm.  I started out using AAC for audio, but gave up on that and went with vorbis.
[01:37] <ubitux> BBB: i'm almost done isolating all the changes
[01:37] <ubitux> i found something like 3-4 checks which were likely added after a fuzzing party (according to j-b)
[01:38] <bernt> wm4: and by the way -- the file plays back just fine (even in my player).  It's just that I'd like to do some math where I convert between samples and displayTime (fractional stuff), and I'm getting some things not to add up as expected.
[01:38] <ubitux> BBB: see https://github.com/ubitux/FFmpeg/commits/vp9-merge for temporary commit extraction
[01:38] <ubitux> i'll flag the relevant commit
[01:39] <wm4> bernt: yeah, it doesn't seem to be the problem I suggested at first
[01:39] <wm4> it doesn't even use lacing (sub-blocks)
[01:40] <wm4> bernt: maybe your problem is that matroska stores timestamps in seconds
[01:40] <wm4> well, nanoseconds (I think), as integers
[01:40] <bernt> yes -- nanoseconds
[01:40] <wm4> so maybe rounding errors?
[01:41] <bernt> well... if it was rounding errors, I wouldn't see the rather large discrepencies.... let me dig a bit, and give you an example.
[01:50] <bernt> wm4: maybe my debugging code is off.  But for example, pts0 = 87986000000, pts1 = 88009000000, and I got 2048 frames out of vorbis over that time for an audio encoding that is supposed to be 44100 samples per sec.
[01:51] <bernt> where pts{0,1} are presentation time stamps in nanoseconds.
[01:53] <bernt> wm4: Wait ... I think I have a bug in my debugging code (I'm not excluding the current sample count of the current simple audio block).  D'oh.  Hold on...
[01:55] <bernt> wm4: ok much better
[01:57] <bernt> Now I'm computing much closer to 44100 samples per sec.  I get maybe +/- 1 sample, but that's probably to be expected.
[01:57] <bernt> sorry about that -- false alarm.  Thanks for your help though ;)
[01:58] <wm4> yeah, rounding errors probably
[02:34] <cone-876> ffmpeg.git 03wangxingchao 07master:68900bf16bb4: avcodec: Fix duration error after seek operation
[02:47] <cone-876> ffmpeg.git 03Byte 07master:d04b7de78678: avformat/rtmphttp: Partial fix for the ticket #3127 (second try)
[04:35] <BBB> ubitux: re: 7a02f87... line ~440:             if (!s->refs[s->refidx[0]] || !s->refs[s->refidx[1]] ||
[04:35] <BBB>                 !s->refs[s->refidx[2]]) {
[04:35] <BBB>                 av_log(ctx, AV_LOG_ERROR, "Not all references are available\n");
[04:35] <BBB>                 return AVERROR_INVALIDDATA;
[04:35] <BBB>             }
[04:35] <BBB> ubitux: so duplicate, can be removed and makes decoding slower
[04:37] <BBB> my god so many cosmetics
[11:23] <ubitux> 04:35:40 <@BBB> ubitux: so duplicate, can be removed and makes decoding slower
[11:24] <ubitux> sorry, i don't understand
[11:24] <ubitux> what do you mean?
[11:24] <ubitux> btw, i'm done with all the cosmetics
[11:24] <ubitux> now remaining is the file and sym split
[11:24] <ubitux> your opinion on this?
[11:24] <ubitux> i'm still unsure about weither i'll push the cosmetics or just pick the functionnal commits
[11:28] <ubitux> oh i forgot one split
[11:28] <nevcairiel> pick those cosmetics that actually make the code look better and are not stupid pedantic rule following? :p
[11:29] <ubitux> nevcairiel: i'm re-doing every cosmetic manually
[11:29] <ubitux> to make sure i don't miss any functionnal change
[11:29] <ubitux> the split of the files is a bit a pain to track changes though, so i'm going to re-do it too
[12:00] <Compn> ubitux : sounds like something diego would do. work for hours on a fix instead of working with other team
[12:06] <ubitux> Compn: i wonder what you are talking about, but ok
[12:08] <Compn> did you ask luca if he had the history ?
[12:08] <Compn> maybe he doesnt have the history and i'm being a jerk
[12:08] <Compn> some git repo somewhere with all of the cchanges seperated
[12:10] Action: Compn afk bbl
[12:12] <ubitux> Compn: BBB and i asked publicly for the changes, several times
[12:12] <ubitux> and we got ignored
[12:36] <BBB> ubitux: the piece of code I pointed at and the patch do the same thing
[12:36] <BBB> ubitux: so the patch duplicates already-existing code (and thus can't possibly fix a bug)
[12:36] <BBB> ubitux: no criticism of the tree, just maybe worth an annotation
[12:37] <BBB> ubitux: I don't have an opinion on the cosmetics, so make a good judgement call there... if you think it's worth tracking libav's decoder in the future, feel free to apply. if not, maybe keep what we have?
[15:48] <cone-755> ffmpeg.git 03Michael Niedermayer 07master:d7ebeba80c60: ffmpeg: Do not fill gap before the first decodable frame on single stream input files unless the user explicitly requests it.
[15:53] <Compn> ugh
[15:53] <Compn> google finally did what they said they werent going to do
[15:53] <Compn> made ad results look like real search results
[15:54] <nevcairiel> still have a yellowish background for me
[15:54] <Compn> oh weird
[15:54] <Compn> my monitor color settings arent contrasty to see it
[15:55] <Compn> but yes, i see a very very very faint yellow bg
[15:55] <nevcairiel> you need a new monitor
[15:56] <Compn> i need google to go back in time to 2009 , when i could still use the + operator.
[15:57] <j-b> no
[15:57] <j-b> I got now the no-background one
[15:57] <j-b> but it alterns
[15:58] <j-b> sometimes I get the low-contrast, sometimes I get the white-one-with orange "ad"
[16:00] <Compn> is it when you switch from javascript to no javascript ?
[16:43] <ubitux> ah shit, found some other cosmetics
[16:43] <lachs0r> http://p.srsfckn.biz/raw/64/ heres a patch to make configure use pkg-config for more of the external libs and pass --static to it in a static configuration. makes shit work properly" for my mingw-w64 builds, but its untested with other configurations.
[16:57] <nevcairiel> i use half of those libs and i dont have pkg-config setup, so it would break shit for me :p
[16:58] <lachs0r> well that sucks
[16:58] <lachs0r> I recommend setting up pkg-config then
[16:58] <lachs0r> :P
[16:59] <nevcairiel> nah, its fail
[16:59] <lachs0r> can you explain why it is bad?
[16:59] <nevcairiel> simply adding the headers and libs into a path where they are found is so much easier
[17:00] <ubitux> BBB: ping
[17:00] <lachs0r> yeah but it breaks on every configuration that doesnt work like what configure expects. pkg-config is there to solve that problem.
[17:01] <nevcairiel> you should propose a patch then to not rely only on pkg config, because today it works fine, if it tomorrow breaks i'm not the only one thats going to complain :)
[17:02] <lachs0r> well, its already doing that for a few other libs, and MOST projects are fine with the pkg-config requirement, so I dont see why not
[17:05] <lachs0r> doing pkg-config checks with a fallback to the old method when its not available sounds okay, but also looks like unnecessary extra effort to mepretty much nothing else does this, and I didnt see anyone complain about that fact so far
[17:06] <nevcairiel> noone complained about the lack of pkg-config for those libs either, so far :P
[17:06] <cone-755> ffmpeg.git 03Clément BSsch 07master:d28c79b0035c: avcodec/x86/vp9dsp: use EXTERNAL_* macros.
[17:07] <lachs0r> fair point, most people know better than to start arguing with the multimedia folks
[17:07] <lachs0r> telling you the necessary compiler flags is pkg-configs job, thats why libs ship .pc files, and hence you should use it
[17:14] <cone-755> ffmpeg.git 03Clément BSsch 07master:7cd555dfa54a: avcodec/vp9: make last_invisible local.
[17:20] <lachs0r> I dont see how manually putting libs and headers into a path specifically so ffmpeg can find them, then trying to tell it that there are dependencies that do not automatically get resolved with static linking is any easier than just running a command that produces output which tells the compiler where shit is and which dependencies to link in static builds
[18:31] <ubitux> BBB: ok i'm mostly done, i need you now :)
[18:34] <wm4> oh man these ABI hacks in the ML
[18:34] <wm4> it looks like these wouldn't be needed if ffmpeg stopped pretending to be a bunch of independent libraries (libavutil, libavcodec, ...)
[18:35] <ubitux> i finished reversing the vp9 bomb
[18:35] <ubitux> all the fixes extracted
[18:35] <ubitux> need to pick them properly now
[18:36] <ubitux> (BBB: "sb" is for "superblock" right?)
[18:42] <ubitux> wm4: or if libav didn't break the abi ;)
[18:42] <JEEB> where were all the whence flags that an aviocontext's seek function can get listed?
[18:44] <wm4> JEEB: it uses the OS', like SEEK_SET
[18:45] <wm4> plus AVSEEK_SIZE
[18:45] Action: JEEB is "enjoying" trying to map IStream into AVIOContext
[19:19] <michaelni> wm4, if you have a suggestion on how to solve the ABI issues, its very welcome. But i suspect the alternative you are thinking of would cause other problems, especially for distros that are libav based
[19:43] <BBB> ubitux: yes
[19:44] <BBB> ubitux: any opinion on which ones we need and which ones we don't?
[19:44] <ubitux> BBB: yeah well that's what i wanted to ask
[19:44] <BBB> well you have as much a vote in that as I do
[19:44] <ubitux> BBB: so anyway, here is the decomposition: https://github.com/ubitux/FFmpeg/compare/vp9-merge
[19:44] <ubitux> (i didn't change what you mentioned)
[19:44] <ubitux> also i didn't rename a few things
[19:44] <BBB> d28c79b0035c8f699be42bdf9df636edd9a78349 is fine
[19:45] <BBB> 7cd555dfa54a9b9b83749977e7eec3f023ff2b36 is fine
[19:45] <ubitux> yeah those 2 are pushed already :)
[19:46] <ubitux> anyway, after all these commits, the diff is quite small
[19:46] <ubitux> i didn't rename decode_sb and the sbits_inv
[19:47] <ubitux> i didn't reindent the "tree view" of some arrays either
[19:47] <BBB> MAX_PROB isn't a good idea, there's only one occurence of it, isn't there?
[19:47] <ubitux> yeah
[19:47] <BBB> it's sort of like MAX_UINT8_VAL
[19:47] <BBB> or MIN_UINT8_VAL
[19:47] <ubitux> it was just to reduce the diff, i doesn't matter i can restore ofc
[19:48] <BBB> right
[19:48] <BBB> so do you want to keep the cosmetics?
[19:48] <ubitux> i don't know& some cosmetics might be relevant
[19:48] <BBB> as in, take their patch, or keep what we have right now? or a mix of the two? these changes are incredibly bikesheddish
[19:48] <ubitux> but not 7k diff like this
[19:48] <BBB> like ctx vs avctx, etc.
[19:49] <ubitux> maybe something like 50-100L diff
[19:49] <ubitux> though, i'm not motivated to extract which ones are worth
[19:49] <ubitux> i already spent too much time on this shit
[19:49] <BBB> moving the avassert include up is good; typedef struct is good; ctx/avctx is comlpetely ambivalent
[19:49] <BBB> right
[19:49] <BBB> so maybe just not do it
[19:49] <ubitux> i'd like to focus on the fixes commit
[19:50] <ubitux> i re-did all the cosmetics manually
[19:50] <ubitux> to see where the functionnal changes were
[19:50] <ubitux> BBB: https://github.com/ubitux/FFmpeg/commit/336c0ff12d7ab98d7c85cfecc48f99d93e664c9f
[19:51] <ubitux> BBB: https://github.com/ubitux/FFmpeg/commit/2626fd3047e308a91ef7f0ce98ddf79638ccf885
[19:51] <BBB> 336... drop that, bad
[19:51] <ubitux> BBB: https://github.com/ubitux/FFmpeg/commit/6da72f8ac436ed5ef1f104120cfec92a83acc37d
[19:51] <ubitux> BBB: might not be bad after https://github.com/ubitux/FFmpeg/commit/aac9f10310f3b59eadf3689320063fecef589a98
[19:52] <ubitux> https://github.com/ubitux/FFmpeg/commit/e75e10ad03cb5ca4b802688696c266654a8a5f0f
[19:52] <ubitux> https://github.com/ubitux/FFmpeg/commit/d53191e60c7a8676b3ea6971c57bd36b25d2c883
[19:52] <ubitux> anyway, if you have some time to simply look at the few commits here: https://github.com/ubitux/FFmpeg/compare/vp9-merge
[19:52] <BBB> aac. still does a complete check, so I don't see how that new check can ever trigger
[19:52] <BBB> I need to see a file for which that is relevant
[19:52] <BBB> for now, rather not
[19:53] <BBB> 262... is if (boolean == true) { .. } else if (boolean == false) { .. } else { default code added by libav }
[19:53] <BBB> so no
[19:53] <BBB> the tree they're reading has only 4 values
[19:53] <BBB> 6da72f8ac436ed5ef1f104120cfec92a83acc37d is probably ok
[19:53] <ubitux> so i can replace with an av_assert0() i guess
[19:53] <BBB> yes
[19:53] <BBB> that would be fine
[19:54] <BBB> aac... has various odd pieces to it
[19:54] <ubitux> yeah sorry it's probably not well extracted
[19:54] <BBB> first of all, it calls flush in update_size(), which will break scalable
[19:54] <BBB> no that's not the problem, their code changes are broken
[19:56] <BBB> then secondly around line 3450 (them 3430) they call " s->cur_frame = frame;" - what is frame here?
[19:56] <ubitux> out_pic
[19:56] <ubitux> iirc
[19:56] <ubitux> it was renamed in a previous commit
[19:57] <BBB> oh it's the output frame
[19:58] <BBB> I see someone removed the commented out last_frame variable assignment there
[19:58] <BBB> that's there for a reason
[19:59] <BBB> so, the flush addition in update_size() needs to go
[19:59] <BBB> we probably need to keep the commented-out last_frame assignment at the top of vp9_decode_frame
[19:59] <BBB> for the rest, aac... is probably ok
[20:01] <BBB> e75e10ad03cb5ca4b802688696c266654a8a5f0f is a 16bit number + 1, so it can never happen, change to av_assert0() please
[20:04] <ubitux> ok
[20:07] <BBB> I don't see (d53...) how size can ever go negative
[20:07] <BBB> again, I think we probably just need to add an assert that size > 0 or so?
[20:09] <BBB> I don't see how size can go negative, I'm looking through the code now and it seem pretty well protected
[20:09] <BBB> I'd make it an assert for now
[20:09] <BBB> (size >= 0)
[20:10] <BBB> is that the only functional commits?
[20:10] <BBB> also if you disagree with my assessments let me know, I'm by no means always correct
[20:10] <ubitux> https://github.com/ubitux/FFmpeg/commit/1d30676b4acfe40de1b92fb7203edb4a8b7e5136 this one is not really cosmetic but well
[20:11] <ubitux> BBB: ok
[20:11] <ubitux> i need to look better at each change actually
[20:11] <ubitux> i'm a bit tired by the braindead extraction
[20:11] <BBB> right, understandable
[20:12] <BBB> I'd actually change that and keep the b assignment in the function (the const does some magic to the assembly, it actually always accesses it as an offset in s)
[20:12] <BBB> but not give ctx, but instead s, as a function argument
[20:12] <BBB> so static void decode_mode(VP9Context *s)
[20:12] <BBB> remove VP9Context *s = ctx->priv_data;
[20:12] <BBB> keep VP9Block *const b = &s->b;
[20:12] <BBB> and then decode_mode(s);
[20:13] <ubitux> interesting, ok
[20:27] <cone-755> ffmpeg.git 03Martin Storsjö 07master:ab80d7e8c52d: vp9: Ensure that the arithmetic coder values are read in the right order
[20:27] Action: ubitux stealing code away
[20:30] <Daemon404> cherry picking unreviewed patches?
[20:30] <Daemon404> how classy.
[20:31] <ubitux> Daemon404: i reviewed it
[20:31] <ubitux> iirc i'm somehow a maintainer of that code, because of michael's curse
[20:31] <wm4> lol at this chaos
[20:32] <Daemon404> first!!!!
[20:32] <Daemon404> amidonitrite
[20:32] <Daemon404> er
[20:32] <Daemon404> amidoinitrite
[20:32] <ubitux> Daemon404: it's one of the change already in libav's vp9
[20:32] <Daemon404> oh this is post merge chaos
[20:32] <ubitux> i'm just picking changes, this time with correct meta
[20:33] <ubitux> Daemon404: no, this change was squashed in libav commit
[20:33] <ubitux> i somehow found it in a repo.
[20:33] <Daemon404> yes... and i assume michael did not merge it properly
[20:33] <ubitux> at least we have an explanation about that change
[20:33] <ubitux> Daemon404: no, i asked him not to merge, see the merge commit.
[20:33] <nevcairiel> Daemon404: he didnt merge it at all on ubitux request :p
[20:33] <Daemon404> o ok
[20:33] <Daemon404> lol forks.
[20:33] Action: Daemon404 just popcorn.sh
[20:34] <ubitux> Daemon404: we're just extracting and reviewing all the changes made
[20:38] <BBB> Daemon404: as an example, https://git.libav.org/?p=libav.git;a=blob;f=libavcodec/vp9.c;h=9048700fb79bf4860290f506b033f1a2c6537045;hb=HEAD#l1147 memcpies a struct of size [4][2][2][6][6][3] (https://git.libav.org/?p=libav.git;a=blob;f=libavcodec/vp9.h;h=0a6c6eed42414c7b14b483ba53ac593b091221a6;hb=HEAD#l336) to a struct of size [4][2][2][6][6][11] 
[20:38] <BBB> (https://git.libav.org/?p=libav.git;a=blob;f=libavcodec/vp9.h;h=0a6c6eed42414c7b14b483ba53ac593b091221a6;hb=HEAD#l340)
[20:38] <BBB> Daemon404: these changes need review, test suite coverage of files provided by google is nowhere near 100%
[20:39] <BBB> Daemon404: so many changes will silently break the decoder compared to libvpx
[20:39] <BBB> Daemon404: but what do I know, after all, I know nothing about video
[20:39] <BBB> compare to relevant code that I wrote: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/vp9.c;h=4978915bc4d39b84ffb439e19f44b0a8b399cabe;hb=HEAD#l3436
[20:40] <Daemon404> [19:39] <@BBB> Daemon404: so many changes will silently break the decoder compared to libvpx <-- if only there were some sort of document... which detailed how vp9 works...
[20:40] <Daemon404> whats it called...
[20:40] <Daemon404> ... a spec?
[20:40] <BBB> asking the wrong person, I don't work at google
[20:40] <nevcairiel> obvious code bugs dont need a spec :p
[20:41] <BBB> #vp8 maybe?
[20:41] <BBB> and what nevcariel says
[20:41] <BBB> not understanding c is not my problem
[20:41] <Daemon404> btw i wasnt saying either is right
[20:41] <Daemon404> im just enjoying the chaos
[20:41] <Daemon404> the lulz.
[20:41] <BBB> glad you are
[20:41] <Daemon404> ./popcorn
[20:42] <BBB> I just find it sad
[20:46] <ubitux> BBB: so, i'm on the fb removal commit; 1) the complete check (you mean the ->buf[0] for the refs right?) can be ermoved? 2) the flushing (unrefing the refs) must not be called?
[20:47] <BBB> just 2, I think
[20:47] <BBB> 1) is exactly what prevents that other patch you had later from not being needed (the one you're changing into an av_assert0()
[20:48] <ubitux> note that in a previous commit the variable resets (which you ok'ed) were removed
[20:48] <BBB> the x = null, right?
[20:48] <BBB> that's probably ok, yes
[20:49] <ubitux> ok
[20:49] <ubitux> any idea why this change was made?
[20:50] <BBB> it removes a variable, I support that's good
[20:50] <BBB> more generally, it's in line with the ref/unref object management model
[20:55] <ubitux> fuck that shitty isp, it's again a modem reboot period
[21:10] <ubitux> BBB: so you say vp8_rac_get_tree() can never return a value outside [0;N] on a tree[N][2]?
[21:22] <cone-755> ffmpeg.git 03Michael Niedermayer 07master:6909a611d205: swscale/swscale_unscaled: fix right column handling in planarCopyWrapper
[21:53] <cone-755> ffmpeg.git 03Marton Balint 07master:02b76aa3774c: ffplay: simplify early frame drop code
[21:53] <cone-755> ffmpeg.git 03Marton Balint 07master:28031404571b: ffplay: calculate last frame duration from vp->pts instead of frame_last_pts
[21:53] <cone-755> ffmpeg.git 03Michael Niedermayer 07master:cee63a148352: Merge remote-tracking branch 'cus/stable'
[22:32] <BBB> ubitux: it can never return a value not in the tree, if all tree tails are an enum
[22:33] <ubitux> BBB: the tree contains positive and negative values
[22:33] <BBB> yes, negatives are vaues, positives are branches
[22:33] <ubitux> branches can be ignored then
[22:33] <BBB> static const int8_t vp9_partition_tree[3][2] = {
[22:33] <BBB>     { -PARTITION_NONE, 1 },               // '0'
[22:33] <BBB>      { -PARTITION_H, 2 },                 // '10'
[22:33] <BBB>       { -PARTITION_V, -PARTITION_SPLIT }, // '110', '111'
[22:33] <BBB> };
[22:34] <ubitux> ok so let's push 2 commits for now
[22:34] <cone-755> ffmpeg.git 03Clément BSsch 07master:7e704b1e109b: avcodec/vp9: add a never triggerable assert.
[22:34] <cone-755> ffmpeg.git 03Clément BSsch 07master:c20a7ce62d02: avcodec/vp9: remove some reset-to-zero from vp9_decode_free().
[22:43] <ubitux> BBB: do you mind picking the fb removal patch, i'm not comfortable changing that code
[22:43] <ubitux> ?
[22:49] <cone-755> ffmpeg.git 03Clément BSsch 07master:484f8d77c6ec: avcodec/vp9: assert on sane size in update_size().
[22:49] <ubitux> BBB: also, what about the clipping?
[22:56] <BBB> sorry, disappeared
[22:56] <BBB> so
[22:56] <BBB> the reason a tree can never deviate from the values of its terminals (the negatives of the <=0 values) is because those are the possible paths through the tree
[22:57] <BBB> so in that tree, the only values that can occur as output are PARTITION_H/V/SPLIT/NONE
[22:57] <BBB> any other value is theoretically impossible
[22:57] <BBB> it's a basic tree constraint
[22:57] <ubitux> ok
[22:57] <BBB> I'll do the fb patch then
[22:57] <ubitux> thanks :)
[22:57] <BBB> not today obviously, but will get to it in a few days or so
[22:57] <ubitux> ok
[22:58] <ubitux> i'll start with the pred asm then
[22:58] <BBB> yay
[22:58] <ubitux> 'nuff on this for me
[22:58] <BBB> if you want, have a look at the h264 code that jumpyshoes wrote for h264
[22:58] <BBB> it's different because the prototypes are different
[22:58] <BBB> but it's comparable
[22:58] <ubitux> yeah i was wondering about the factoring
[22:58] <ubitux> since it was mentioned on top of vp9dsp
[22:59] <BBB> I think what we have is easier
[22:59] <ubitux> ok
[22:59] <BBB> so I'd like to prove it's not slower and leads to simpler asm and then port h264/vp8 to it also
[22:59] <BBB> but that requires asm first ;)
[22:59] <ubitux> ok :)
[22:59] <ubitux> btw, you're against the parameters order randomization from luca?
[22:59] <BBB> yes, it's silly
[23:00] <BBB> his reasoning is "kostya liked it better this way"
[23:00] <BBB> well, kostya doesn't get to decide everything on this planet
[23:00] <BBB> I prefer blue with pink dots
[23:01] <ubitux> ok :)
[23:09] <ubitux> BBB: should we split the asm just like vp8 or no?
[23:10] <ubitux> it seems to lighten the macro preprocessing burden for yasm and make it faster
[23:10] <ubitux> according to Diego at least
[23:10] <ubitux> well, maybe we can do it when we're done anyway
[23:11] <ubitux> i might start working in another asm file for the pred though
[23:11] <ubitux> unless you don't think it's a good idea
[23:12] <BBB> ubitux: I'm fine with it, I initially split vp9dsp.c in functionality-blocks to be able to do that
[23:13] <BBB> ubitux: so we can have 1 for mc, one for intrapred, one for loopfilter, one for itxfm_add
[23:13] <ubitux> > I [would] initially split vp9dsp.c [...]?
[23:17] <BBB> in terms of code sections
[23:17] <ubitux> no i mean, did you actually split at some point, or you're suggesting to do it?
[23:17] <BBB> if you look at ff_vp9dsp_init
[23:17] <BBB> I was strongly preparing for doing it
[23:17] <ubitux> oh ok.
[23:17] <BBB> ff_vp9dsp_init just does 4 things
[23:18] <BBB> so you could split vp9dsp in 4 files, each having that init function called from ff_vp9dsp_init as entry point
[23:18] <BBB> vp9dsp.asm could be split in the same way
[23:18] <BBB> in fact, if you share, say, the intra pred with vp8/vp9, you'd have to do this
[23:18] <BBB> since you don't want vp8 to depend on, say, vp9 mc or vp9 loopfilter
[23:19] <j-b> 'morning
[23:19] <BBB> that's why h264 has H264DspContext, H264PredContext, etc.
[23:19] <BBB> H264QpelContext was the last one
[23:19] <BBB> (couldn't think of it for a second)
[23:19] <ubitux> ok
[23:20] <BBB> so we could do that for vp9 also, esp. if we wanted to share some subparts of the code between vp8/vp9 or h264/vp9 or hevc/vp9 or complex combinations thereof
[23:20] <BBB> e.g. the mc code can likely be shared between hevc and vp9
[23:20] <BBB> the intra pred code can likely be shared between them all
[23:20] <BBB> itxfm_add is unsharable, so is loopfilter
[23:21] <BBB> bilinear filter can be shared between vp8, vp9 (and h264 has its own copy of it because the function prototype is different, go figure)
[23:21] <BBB> I don't know if hevc has bilinear filter
[23:21] <ubitux> from someone who doesn't know a thing about loopfilter i would have say it is the most sharable thing
[23:22] <BBB> nah
[23:22] <BBB> devil is in the details
[23:22] <BBB> I haven't seen hevc' lf but I figure it's unsharable
[23:23] <BBB> mc is sharable if taps are identical
[23:23] <BBB> h264 has qpel, which is weird
[23:23] <BBB> hevc/vp9 have 8tap, I believe
[23:23] <BBB> vp8 has 4/6tap
[23:42] <cone-755> ffmpeg.git 03Anton Khirnov 07master:b068660ffa73: lavc: deprecate CODEC_CAP_NEG_LINESIZES
[23:42] <cone-755> ffmpeg.git 03Michael Niedermayer 07master:ec9aef565291: Merge commit 'b068660ffa73f226cc03a67e214b8540fc1e11c4'
[23:43] <cone-755> ffmpeg.git 03Anton Khirnov 07master:2ff302cb6ba1: lavc: update coded_frame doxy.
[23:44] <cone-755> ffmpeg.git 03Michael Niedermayer 07master:571a99de186e: Merge commit '2ff302cb6ba1f159905888026c8a1d7dd8319acf'
[00:00] --- Sun Nov 17 2013