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

[burek]

[00:09:20 CET] <cone-213> ffmpeg 03Andreas Cadhalpun 07master:9079e99d2c46: svq1enc: fix out of bounds reads
[00:13:17 CET] <llogan> my server problem was due to systemd change regarding predictable network interface names.
[00:14:12 CET] <nevcairiel> Daemon404: i got tired of carefully reviewing every single commit and fixing half of them, so i took a break. I wish their quality hadn't degraded that much
[00:16:48 CET] <durandal_1707> hmm, what needed fixing?
[00:20:25 CET] <nevcairiel> Daemon404: not to m ention that they live in a bubble and re-implement so many things they could just port, and the things they do port end up being refactored to no end =p
[00:21:21 CET] <llogan> sounds like a cult
[00:28:04 CET] <wm4> refactor cult?
[00:28:42 CET] <llogan> living in a bubble, refactoring, killing goats, re-implementing, etc.
[00:30:27 CET] <durandal_1707> sometime it get approved but never comitted
[00:47:43 CET] <Daemon404> nevcairiel, yeah i know
[00:47:53 CET] <Daemon404> ill try and catch us up tomorrow 
[00:47:57 CET] <Daemon404> or at least make a dent
[00:49:07 CET] <nevcairiel> some hints: discard any and all nvenc changes, ours is vastly different; carefully review refactoring from koda, his commits are usually on the more sloppy side
[00:50:46 CET] <Daemon404> o/
[03:55:28 CET] <BBB> jya: do you know the first stable firefox release that used ffvp9 decoding? (or will use)
[04:05:00 CET] <jya> BBB: 46
[04:05:19 CET] <jya> 46 made alpha on Monday
[04:05:30 CET] <jya> so in 12 weeks it will be official release
[04:05:52 CET] <jya> if all goes well (and no major regressions were found in ffvp9)
[04:06:14 CET] <jya> we want to provide an update benchmark. last we did it was with ffvp9 based on 2.8
[04:14:25 CET] <BBB> I just want to show cpu usage in firefox vs. chrome playing the same youtube video
[04:24:29 CET] <TD-Linux> BBB, I think it's still not on for all users though
[04:24:48 CET] <TD-Linux> I think windows users still get H.264 only :/
[04:25:10 CET] <TD-Linux> so just make sure you're actually getting VP9 in both cases before doing the comparison
[07:42:09 CET] <cone-963> ffmpeg 03Matt Oliver 07master:b66ac803fac2: avformat/mux: Fix error when writing uncoded frames.
[10:13:14 CET] <cone-963> ffmpeg 03Carl Eugen Hoyos 07master:69dbecf920f6: lavc/h264: Show "Increasing reorder buffer" message with loglevel info.
[10:16:55 CET] <BtbN> So there are two "competing" libva h264 encoders on the list now?
[10:17:19 CET] <BtbN> I'm in favor of the one included with the vaapi revamp though
[10:24:55 CET] <cone-963> ffmpeg 03Carl Eugen Hoyos 07master:7a90edc188a7: lavc/mjpegdec: Set SAR even if no resolution is available.
[10:27:23 CET] <wm4> BtbN: yeah
[10:31:23 CET] <nevcairiel> someone should probably tell those guys to cooperate =p
[10:31:48 CET] <BtbN> Well, they're both done
[10:31:55 CET] <wbs> one of them at least finally stopped calling it libih264
[10:38:36 CET] <BtbN> well, the other one wasn't ever called like that
[10:39:01 CET] <wbs> yeah
[10:39:13 CET] <wbs> rephrase, "the one that used to call it weird stuff at least stopped doing that"
[10:39:53 CET] <nevcairiel> that one probably still has a bunch of problems left though, it wasnt exactly clean code otherwise
[10:40:34 CET] <nevcairiel> still havent removed the unrelated changes to configure which were pointed out in the very first review
[10:42:58 CET] <wm4> it also opens X displays in libavcodec and such things
[10:48:05 CET] <BtbN> There is no real point in doing that, the drm method works just fine, and doesn't depend on X
[10:48:31 CET] <wm4> you need it if you use the vaapi vdpau backend
[10:48:40 CET] <wm4> but even so, libavcodec shouldn't be doing stuff like this
[10:48:49 CET] <BtbN> That still exists?
[10:49:19 CET] <BtbN> What else should it do? Just expect the application to implement it?
[10:50:55 CET] <wm4> http://sprunge.us/PEJH 
[10:50:58 CET] <wm4> from the patch
[10:51:13 CET] <wm4> BtbN: yes, ffmpeg_vaapi.c etc.
[10:51:47 CET] <BtbN> Well, that'd mean you need to implement special handling just for that encoder, and can't just use it like all the other ones
[10:52:22 CET] <wm4> the patch even wraps vaPutSurface, what's that even for
[10:52:34 CET] <BtbN> I don't see an issue with implementing the DRM open thing in lavc, it's just opening a file.
[10:53:17 CET] <BtbN> introducing a pointless dependency on X is kind of an issue though
[10:53:29 CET] <BtbN> The VAAPI vdpau backend is dead anyway
[11:20:37 CET] <jkqxz> The VAAPI H.264 encoder I wrote is entirely a token effort - it only does IDR/P at constant QP.  Copying the libva example encoder as in the other patch would be a sensible advance.
[11:21:31 CET] <cone-963> ffmpeg 03Paul B Mahol 07master:ce404b4d7c99: avfilter/af_afade: do not duplicate curve option
[11:21:32 CET] <cone-963> ffmpeg 03Paul B Mahol 07master:74e8f4f67446: avcodec/dvaudiodec: set channel layout
[11:22:42 CET] <jkqxz> (I am intending to work on improving the H.265 encoder only.)
[11:25:20 CET] <wm4> jkqxz: so how should we do it
[11:25:37 CET] <wm4> jkqxz: not apply your h264 encoder at first, and ask him to port it to your infrastructure?
[11:30:15 CET] <ubitux> is RGBA supposed to be premultiplied in ffmpeg?
[11:30:39 CET] <nevcairiel> dont think so
[11:31:40 CET] <ubitux> would it make sense to have a filter to premult, and should we have a bunch of new pixfmt to mark the difference? (i'm gonna get killed for that second question)
[11:35:36 CET] <jkqxz> wm4:  Might be the best course of action, if they feel like cooperating.
[12:03:16 CET] <durandal_1707> ubitux: no, adding pixels formats for that is wrong
[12:05:30 CET] <wm4> actually a new pixfmt would be reasonable
[12:05:42 CET] <wm4> considering how bad support for other attributes like limited range etc. is in lavfi
[12:05:56 CET] <wm4> (format negotiation only considers pixfmt)
[12:06:07 CET] <nevcairiel> "a new", more like cloning every rgba format
[12:07:30 CET] <rcombs> re: jkqxz's work, I wonder if it might make sense to integrate the surface conversion into vf_scale
[12:08:57 CET] <rcombs> or otherwise integrate it into the autonegotiation infrastructure
[12:10:28 CET] <rcombs> I'm saying "integrate" too much
[12:15:31 CET] <jkqxz> I wondered that.  Really I would prefer to keep it explicit, but the libavfilter automatic things do mess with that and make you want some integration for anything but a single leaf operation (especially in vf_scale).
[12:16:14 CET] <jkqxz> (Pure hardware transcode, with no copy through normal memory, still does not work with the patchset I have.)
[12:19:20 CET] <wm4> but in theory, it could work, right?
[12:20:59 CET] <jkqxz> Certainly.  (I was meaning that avfilter gets in the way - it works with some nasty hackery.)
[12:21:54 CET] <wm4> you mean the problem of passing the vaapi context?
[12:22:48 CET] <BtbN> The vaapi h264 encoder is propabaly more important than the hevc one.
[12:23:11 CET] <BtbN> hevc hardware encoding is kind of useless. For h264 it's usefull for live streaming
[12:23:26 CET] <jkqxz> Yeah.  And also of automatically created things barfing on AV_PIX_FMT_VAAPI.
[12:28:12 CET] <rcombs> because it's a hardware format, and those are explicitly not used for some autonegotiation?
[12:28:56 CET] <wm4> isn't the problem that libavfilter will think vf_scale always can convert anything
[12:29:17 CET] <jkqxz> The autonegotiation always tries to choose YUV420P/NV12 if it can.  If you force it, it inserts vf_scale instances which then barf.
[12:30:01 CET] <jkqxz> *tries to choose YUV420P/NV12 over VAAPI if it can.
[12:30:24 CET] <nevcairiel> full hardware transcode works with qsv, it somehow manages to just skip avfilter entirely
[12:31:55 CET] <rcombs> nevcairiel: see ffmpeg_qsv.c
[12:33:18 CET] <rcombs> (I'd rather not be like ffmpeg_qsv.c)
[12:35:10 CET] <jkqxz> We do want avfilter, there are useful things to do there.  Just, no magic.
[12:35:30 CET] <wm4> rcombs: I don't see how it prevents lavfi from throwing up
[12:35:45 CET] <rcombs> jkqxz: right
[12:38:24 CET] <rcombs> wm4: it makes sure full-hardware transcoding is only used when there are no filters in the chain that care about pixel format
[12:39:03 CET] <nevcairiel> well of course, thats the only way it can be full hardware, otherwise you need to go back to software
[12:39:21 CET] <nevcairiel> because you cant expect any arbitrary filters to accept hardware surfaces
[12:40:11 CET] <rcombs> nevcairiel: well if the autonegotiation infrastructure knew how to convert back and forth it'd be fine
[12:40:25 CET] <rcombs> just like any other auto-negotiated pixel format conversion
[12:40:55 CET] <rcombs> and at some point additional filters might gain support
[12:41:04 CET] <rcombs> e.g. vf_overlay
[12:41:35 CET] <rcombs> or a VAAPI deinterlacer
[12:42:03 CET] <jkqxz> Yeah, overlaying a software-created image onto the hardware surface is totally possible here.
[12:42:06 CET] <rcombs> and I'm sure there's some way to get ff_draw to work with this
[12:42:27 CET] <rcombs> which would mean vf_subtitles would work
[12:42:32 CET] <rcombs> amongst others
[12:42:35 CET] <nevcairiel> feel free to propose a clean non-vaapi-specific api =p
[12:43:52 CET] <nevcairiel> that hw api from anton might possibly be able to do that at some point, it tried to define a generic copy-back function extensible for all hwaccel implementations
[12:45:55 CET] <rcombs> sounds promising
[12:49:43 CET] <rcombs> &huh
[12:50:52 CET] <rcombs> jkqxz: could you call an AVFrame e.g. AV_PIX_FMT_YUV420P, and just set all its plane pointers to the relevant offsets into the mapped surface?
[12:51:51 CET] <nevcairiel> without optimized copy-back functions, thats going to be crawling slow
[12:52:30 CET] <wm4> also, not all hw apis have such mapping
[12:52:55 CET] <jkqxz> In VAAPI, only in some cases.  Drivers are not required to allow the mapping (using vaDeriveImage()), you would need to fall back to copying into memory and out again (vaGetImage()/vaPutImage()).
[12:53:49 CET] <jkqxz> Also on Intel the mapping you get is not in cached memory, so reading it is immensely slow without special extra magic.
[12:54:30 CET] <rcombs> hmmm, so interesting but impractical
[12:56:30 CET] <durandal_1707> wm4: if AVframe primaries, etc changed they are kept, no need to query formats on them  
[12:57:09 CET] <durandal_1707> adding another yuvj variants is insane
[12:57:12 CET] <wm4> durandal_1707: the point is they should be subject to automatic conversion or negotiation failure if not possible
[12:57:29 CET] <nevcairiel> maybe its time for smarter negotiation then
[12:57:42 CET] <nevcairiel> i agree that another yuvj debacle would be terrible
[12:58:01 CET] <durandal_1707> can we add yuv420bt2020halfassfloat
[12:58:26 CET] <wm4> durandal_1707: one suggestion was replacing the format enum with a struct, the pixformaton
[12:58:37 CET] <wm4> which describes the format using multiple fields
[12:59:10 CET] <jkqxz> rcombs:  Drawing on surfaces probably needs to work by drawing to a scratch buffer with an alpha channel, copying that buffer to a hardware surface and then blending in hardware.  Getting the input surface somewhere you can draw on directly is just too much trouble.
[12:59:10 CET] <rcombs> I'd be in favor of that
[12:59:31 CET] <rcombs> and then it could also be partially-filled in cases where you only know some properties
[13:00:10 CET] <rcombs> e.g. the H.264 parser can tell you that a particular stream has Y, U, and V components, each 8 bits per sample, with 4:2:0 subsampling
[13:00:24 CET] <wm4> for lavfi, maybe we could also do something like having "prototype" AVFrames with no data, and let format negotiation work on that
[13:00:53 CET] <rcombs> but the actual format you're storing it is up to the decoder and multiple might be applicable, so the parser has no business picking one
[13:01:15 CET] <rcombs> jkqxz: mmmmm
[13:02:55 CET] <nevcairiel> fwiw alpha blending manually on dxva surfaces works quite well
[13:03:17 CET] <nevcairiel> not sure how slow it is on some hardware, i only do it with dvd subtitles
[13:03:22 CET] <nevcairiel> and thats not much data
[13:05:05 CET] <rcombs> jkqxz: well I need to get some sleep, but this work is definitely relevant to my interests
[13:11:15 CET] <jkqxz> nevcairiel:  Yeah, small areas would probably work ok.  Maybe that /is/ worth supporting on its own for just that case (with a lot of errors and warnings to explain the failure modes and likely slowness if abused).
[14:03:46 CET] <cone-963> ffmpeg 03Paul B Mahol 07master:75a7565bcb69: avcodec/dvaudiodec: support cases when codec_tag is not set but block_align is
[14:08:22 CET] <wm4> nevcairiel: daily nagging when you will push your dxva hevc main10 patch
[14:28:10 CET] <Daemon404> time to start some merges...
[15:04:04 CET] <nevcairiel> good luck
[15:09:54 CET] <nevcairiel> i think i left it off right at one annoying change where they renamed that macro =p
[16:02:28 CET] <Daemon404> nevcairiel, lol k
[16:10:19 CET] <Daemon404> got sidetracked fixing a fosdem schedule to be less shitty... 
[16:10:34 CET] <JEEB> lol
[16:14:07 CET] <Daemon404> nevcairiel, wait... they put the macro in public API?
[16:14:08 CET] <Daemon404> wtf?
[16:14:44 CET] Action: Daemon404 doesnt really have a choice but to rename it to AV_* then to match API...
[16:16:19 CET] <wm4> what where
[16:16:39 CET] <Daemon404> they merged FF_CEIL_RSHIFT as AV_CEIL_RSHIFT
[16:16:44 CET] <JEEB> löl
[16:16:51 CET] <kierank> yes they did that
[16:16:54 CET] <kierank> blame koda
[16:17:30 CET] <durandal_1707> they are libAV not FFmpeg
[16:19:31 CET] <nevcairiel> Daemon404: stop caring about compat
[16:19:35 CET] <nevcairiel> just screw them =p
[16:22:28 CET] <Daemon404> nevcairiel, easier to rename for future though. Patch on ML.
[16:22:35 CET] <Daemon404> it screws us, not them
[16:23:05 CET] <nevcairiel> we even tried to tell koda, but you can imagine how that went
[16:23:20 CET] <nevcairiel> all those crazy macros are FF
[16:23:22 CET] <nevcairiel> but hell
[16:24:03 CET] <wm4> meh I guess the day where I might have to drop libav support in my own code is coming closer (these little API differences are just so annoying)
[16:24:22 CET] <Daemon404> at work we only use ffmpeg, and it's pretty sane
[16:24:28 CET] <Daemon404> and only HEAD
[16:25:41 CET] <JEEB> same here
[16:25:59 CET] <nevcairiel> every sane thing just rolls their own fixed version
[16:26:30 CET] <nevcairiel> controlling the version just saves so many headaches
[16:26:41 CET] <JEEB> well yeah, I lock a version and update it every time I can run a new revision through testing
[16:27:18 CET] <Daemon404> until you end up like youtube stuck on a 3 year old ffmpeg =p
[16:27:46 CET] <nevcairiel> work is currently at about one year old, I wanted to wait until a aac improvements were in
[16:27:51 CET] <nevcairiel> gotta start upgrading soon
[16:28:36 CET] <JEEB> Daemon404: yeah, I've been really strict at making sure that every time I can update FFmpeg and it passes tests, it gets updated
[16:28:43 CET] <JEEB> getting behind is the worst :P
[16:28:49 CET] <Daemon404> i *cant* use an old ffmpeg
[16:28:53 CET] <Daemon404> some stuff i need aint there
[16:29:22 CET] <JEEB> yeah
[16:29:47 CET] <JEEB> I've never been behind more than a month so far I think
[16:31:34 CET] <nevcairiel> there, throwing w3fdif at the masses, lets see if anyone actually still cares about swdeint =p
[16:31:54 CET] <nevcairiel> someone should totally port the remaining asm to x86
[16:35:15 CET] <durandal_1707> w3fdif is worse than yadif at vectors content
[16:35:41 CET] <JEEB> nevcairiel: oh nice, I was wondering if we had any info on how good/bad it was
[16:36:02 CET] <durandal_1707> graphical shapes that are static
[16:36:21 CET] <nevcairiel> most video deinterlacers have problem with such elements
[16:36:40 CET] <durandal_1707> there is nnedi, if someone wants to add asm
[16:40:00 CET] <nevcairiel> my interest is mostly on real-time use during playback, and if w3fdif is anything, its very fast, so that plays well there
[16:40:21 CET] <j-b> 'morning
[16:40:23 CET] <wm4> you could just use some bob thing
[16:40:29 CET] <Daemon404> badvr allows nnedi for playback
[16:40:34 CET] Action: Daemon404 runs
[16:44:03 CET] <Daemon404> https://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/188104.html <-- these never made it to my inbox
[16:44:07 CET] <Daemon404> how strange
[16:44:14 CET] <nevcairiel> i saw them
[16:45:01 CET] <Daemon404> not even in my spam folder
[16:45:22 CET] <wm4> seeing them too
[16:46:34 CET] <Daemon404> weird
[16:46:41 CET] <Daemon404> i can reply using the headers anywya...
[16:51:25 CET] <durandal_1707> mpv use nnedi for playback too
[16:51:38 CET] <durandal_1707> using shaders
[16:59:58 CET] <wm4> it's too slow though (nobody tried to optimize it either)
[17:01:03 CET] <nevcairiel> madvr does it with opencl, but i've been told pixel shader variants can be equally fast though if optimized
[17:01:17 CET] <nevcairiel> but even then it needs high-end hardware, its rather expensive
[17:01:23 CET] <nevcairiel> and forget running it on the cpu inr ealtim,e
[17:01:26 CET] <nevcairiel> realtime*
[17:01:47 CET] <wm4> well modern opengl shaders are almost opencl anyway
[17:01:53 CET] <Daemon404> madvr's version makes my fan spin wildly on my gpu
[17:01:56 CET] <wm4> same for d3d I'm sure
[17:14:50 CET] <ubitux> nevcairiel: just define FF_CEIL_RSHIFT on AV_CEIL_RSHIFT, and i'll sed everything to AV and drop the FF if you don't want to do it later
[17:15:13 CET] <nevcairiel> tell Daemon404, its his task for the day :D
[17:15:49 CET] <ubitux> Daemon404: in the merge, drop FF_CEIL_RSHIFT and replace it with #define FF_CEIL_RSHIFT AV_CEIL_RSHIFT
[17:16:00 CET] <ubitux> smaller merge
[17:16:10 CET] <ubitux> i'll make it consistent if you're too lazy
[17:17:09 CET] <Daemon404> ubitux, uh
[17:17:14 CET] <Daemon404> did you not see my patch on the ML
[17:17:17 CET] <Daemon404> it does exactly this
[17:17:24 CET] <ubitux> ah, my bad
[17:17:26 CET] <ubitux> sure ok
[17:17:32 CET] <Daemon404> i even defined it :P
[17:17:53 CET] <Daemon404> just waiting on an ACK
[17:18:19 CET] <Daemon404> poor wm4, caring about mmal
[17:18:52 CET] <wm4> lol
[17:19:31 CET] <wm4> so does anyone care about reviewing those mmal patches, or should I just push?
[17:19:59 CET] <Daemon404> who could even review?
[17:20:44 CET] <durandal_1707> the one who can test it
[17:24:10 CET] <Daemon404> dammit why are you so stipid thunderbird
[17:24:18 CET] <Daemon404> why do you default to replying to: me
[17:24:20 CET] <Daemon404> instead of teh list
[17:25:11 CET] <ubitux> Daemon404: on the ml too
[17:25:15 CET] <ubitux> (the ack)
[17:25:27 CET] <Daemon404> nah i sent it again...
[17:25:31 CET] <Daemon404> teh first was solely to: me
[17:25:39 CET] <Daemon404> it's because i bcc myself
[17:25:44 CET] <wm4> "à›w" <243186085 at qq.com>
[17:25:46 CET] <ubitux> i mean i replied on the ml
[17:25:53 CET] <Daemon404> oh
[17:25:58 CET] <ubitux> but it seems it didn't reach it
[17:26:00 CET] <ubitux> ...
[17:26:03 CET] <wm4> that's hell of a username and email
[17:26:10 CET] <ubitux> Daemon404: anyway, please add a \n after the define
[17:26:20 CET] <Daemon404> ubitux, i dont see it
[17:26:24 CET] <Daemon404> and ok
[17:26:42 CET] <ubitux> (FFUDIV etc are not for backward compat)
[17:26:52 CET] <ubitux> that was my only comment
[17:27:04 CET] <ubitux> waiting for it to reach the ml
[17:27:28 CET] <Daemon404> O_o
[17:28:33 CET] <cone-559> ffmpeg 03Michael Niedermayer 07master:0aada30510d8: avcodec/jpeg2000dec: More completely check cdef
[17:33:33 CET] <ubitux> wm4: Signed-off-by: zjh8890 <243186085 at qq.com>
[17:33:43 CET] <ubitux> zjh8890 is much better than à›w
[17:33:46 CET] <Daemon404> the numbers apparently make sense in chinese
[17:33:47 CET] <wm4> true
[17:33:55 CET] <Daemon404> since they can form 'words'
[17:33:57 CET] <Daemon404> or something
[17:34:06 CET] <ubitux> builtin 1337 speak
[17:34:08 CET] <wm4> yes that's why their websites are often numbers
[17:37:21 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:21f946840260: avutil: Rename FF_CEIL_COMPAT to AV_CEIL_COMPAT
[17:41:36 CET] <Daemon404> wait what the fuck
[17:41:42 CET] <Daemon404> #define AV_CEIL_RSHIFT(a,b) (!av_builtin_constant_p(b) ? -((-(a)) >> (b)) \ : ((a) + (1<<(b)) - 1) >> (b))
[17:41:45 CET] <Daemon404> ours
[17:41:46 CET] <Daemon404> #define AV_CEIL_RSHIFT(a, b) \
[17:41:46 CET] <Daemon404>     (av_builtin_constant_p(b) ? ((a) + (1 << (b)) - 1) >> (b) \
[17:41:47 CET] <Daemon404>                               : -((-(a)) >> (b)))
[17:41:48 CET] <Daemon404> theirs
[17:41:54 CET] <Daemon404> why the shit would you reverse it? just for fun?
[17:42:02 CET] <Daemon404> sorry for the foul language
[17:42:03 CET] <Daemon404> but jeez.
[17:42:23 CET] <Daemon404> ... inb4 cosmetic reasons
[17:42:44 CET] <jamrial> arm gets idct hevc before x86, lol
[17:42:52 CET] <ac_slater> hey all. I'm making a libavcodec encoder. In my AVCodec instance, .pix_fmts contains only AV_PIX_FMT_YUV420P and AV_PIX_FMT_NONE. Yet, my input source is not auto converted to yuv420p. Clues?
[17:43:12 CET] <ac_slater> And, I do see the logging where a scaler is created for yuv420p
[17:43:37 CET] <ac_slater> oh, I'm on HEAD/trunk 
[17:43:37 CET] <wm4> Daemon404: maybe it's faster
[17:43:39 CET] Action: wm4 hides
[17:43:46 CET] <wm4> ac_slater: you're testing this with ffmpeg.c?
[17:43:52 CET] <ac_slater> wm4: yes
[17:43:58 CET] <ubitux> Daemon404: one less character :p
[17:43:58 CET] <Daemon404> wm4, sounds akin to using gcc's likely/unlikely
[17:44:01 CET] <Daemon404> i.e. dumb
[17:44:26 CET] <ac_slater> wm4: I can paste a long. The input source is v4l2... so I'm testing with some rawvideo and other input formats too.
[17:44:32 CET] <ac_slater> log*
[17:45:40 CET] <ubitux> likely/unlikely makes no sense here, av_builtin_constant_p() is not evaluated at runtime
[17:45:50 CET] <ubitux> so it just doesn't make a difference
[17:47:09 CET] <cone-559> ffmpeg 03Clément BSsch 07master:e8bc642202c1: lavu: add AV_CEIL_RSHIFT and use it in various places
[17:47:10 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:dbbfbde085b8: Merge commit 'e8bc642202c10beda1ea4e93ec8492b1e39805e5'
[17:47:31 CET] <kierank> anyone want to say something at fosdem, there is a free slot?
[17:48:29 CET] <cone-559> ffmpeg 03Kieran Kunhya 07master:46350db737a1: get_bits: Support max_depth > 2 in GET_RL_VLC_INTERNAL
[17:48:30 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:711dae575d80: Merge commit '46350db737a15910f468d30cf7beda16a4cc8332'
[17:48:49 CET] <ac_slater> wm4: http://paste.debian.net/plain/371265
[17:49:31 CET] <durandal_1707> kierank: me!
[17:51:20 CET] <cone-559> ffmpeg 03Vittorio Giovara 07master:81737f42c288: sunrastenc: Properly load codec private options
[17:51:21 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:9f18be42f0af: Merge commit '81737f42c28858dad76a40284a35f7a64faa2fc7'
[17:53:57 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07master:62825236dba3: lavc: Add get_bitsz()
[17:53:59 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:71b79b587bc1: Merge commit '62825236dba31a2240e25974a3ba41c1303e4edc'
[17:54:12 CET] <Daemon404> so many noops
[17:54:56 CET] <jamrial> code already in our tree, or code that doesn't apply in our tree at all?
[17:55:23 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07master:fa66237b69c2: lavc: Use get_bitsz where needed
[17:55:24 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:e5fe75ae2bd4: Merge commit 'fa66237b69c27befa788b100e73783e0f47fe1b7'
[17:55:32 CET] <Daemon404> jamrial, former mostly
[17:55:36 CET] <Daemon404> ot rewrites of teh former
[17:55:39 CET] <Daemon404> that do nothing
[17:58:02 CET] <cone-559> ffmpeg 03Anton Khirnov 07master:521dc78366c6: mux: drop the warning about global headers
[17:58:03 CET] <cone-559> ffmpeg 03Anton Khirnov 07master:9cce011b1d2f: movenc-test: stop setting the GLOBAL_HEADER codec flag
[17:58:04 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:895b888f1606: Merge commit '521dc78366c6ea54b7b69426dab302a57231f81e'
[17:58:05 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:257766a838c5: Merge commit '9cce011b1d2f66366f5d75a024c2a2f93dc2b589'
[17:58:23 CET] <Daemon404> nevcairiel, you said i should skip the slew of commits to nvenc from anton?
[18:13:31 CET] <nevcairiel> Our nvenc is vastly different, so I would say so
[18:13:54 CET] <nevcairiel> Merging them in is practically impossible
[18:14:13 CET] <durandal_1707> does it work?
[18:15:17 CET] <Daemon404> nevcairiel, i dont know enough about ours to know if we should add some of teh stuff elenril adds or not
[18:15:21 CET] <Daemon404> like dts generation
[18:15:32 CET] <Daemon404> (note: add, not merge)
[18:15:47 CET] <ubitux> just say in the commit merge you're nooping it, and poke the maintainer
[18:16:15 CET] <Daemon404> who is that for us? BtbN?
[18:16:22 CET] <Daemon404> looks like it
[18:16:24 CET] Action: Daemon404 pokes BtbN 
[18:16:47 CET] <BtbN> hm?
[18:17:30 CET] <Daemon404> nvenc: generate dts properly
[18:17:35 CET] <Daemon404> nvenc: fix encoding with B-frames
[18:17:40 CET] <Daemon404> nvenc: flush the encoder before closing it, as required... 
[18:17:43 CET] <Daemon404> any useful for us?
[18:17:49 CET] <BtbN> I might have a look at the libav nvenc encoder and copy over usefull stuff.
[18:17:53 CET] <Daemon404> ok
[18:17:55 CET] <BtbN> But I'm not aware of issues with dts and bframes
[18:17:55 CET] <Daemon404> so i may skip merging?
[18:18:05 CET] <BtbN> And we think I already do flush on close?
[18:18:13 CET] <Daemon404> ok
[18:18:23 CET] <BtbN> Just noop them, I'll look into it
[18:18:27 CET] <Daemon404> https://git.libav.org/?p=libav.git;a=commitdiff;h=ee359c72ef8735122929da96006565e1558f1e55;hp=39571e86cb0d55536f649210a025c54e440c632b
[18:18:30 CET] <Daemon404> what about this
[18:18:32 CET] <Daemon404> this is more general
[18:18:50 CET] <Daemon404> (also this seems pretty ridiculous)
[18:19:22 CET] <BtbN> Seems kinds pointless, why rename it?
[18:19:28 CET] <Daemon404> i know
[18:19:31 CET] <BtbN> It already has multiple names
[18:19:36 CET] <BtbN> because of libav...
[18:19:49 CET] <Daemon404> yay...
[18:19:55 CET] <Daemon404> ill have to pay close attention then
[18:19:59 CET] <Daemon404> it's an api thing technically
[18:20:53 CET] <cone-559> ffmpeg 03Anton Khirnov 07master:39571e86cb0d: nvenc: better error handling
[18:20:53 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:a54422fff294: Merge commit '39571e86cb0d55536f649210a025c54e440c632b'
[18:27:04 CET] <jamrial> if it's supposedly more consistent with other encoders, then why not?
[18:27:50 CET] <Daemon404> lol wait... we already have that name
[18:27:53 CET] <philipl> BtbN: On the subject of dts, have you tried using nvenc with, for example, a dvd transcode with deinterlacing and vfr?
[18:27:55 CET] <Daemon404> so it doesnt even matter
[18:34:28 CET] <Daemon404> wait no we dont
[18:34:29 CET] <Daemon404> godamn
[18:35:10 CET] <wm4> these codec names sure are confusing
[18:36:41 CET] <Daemon404> ugh
[18:36:51 CET] <Daemon404> apparently we didnt merge something or something
[18:36:59 CET] <Daemon404> so it's all messed up trying to handle then ames correctly
[18:38:38 CET] <Daemon404> yeah i see it...
[18:39:15 CET] <nevcairiel> stuff diverges more and more, at some point soon we really should talk about the merging business again
[18:39:16 CET] <Daemon404> ah i see it....
[18:39:20 CET] <Daemon404> it was libav tha twas confusing
[18:39:36 CET] <Daemon404> +AVCodec ff_h264_nvenc_encoder = {
[18:39:37 CET] <Daemon404> +    .name           = "nvenc_h264",
[18:39:39 CET] <Daemon404> when it was dded
[18:39:40 CET] <Daemon404> added*
[18:39:44 CET] <Daemon404> no wonder i was confused
[18:41:08 CET] <Daemon404> nevcairiel / BtbN - do we care enough to keep the names compatible
[18:41:12 CET] <Daemon404> i can... it's just a pita
[18:41:20 CET] <nevcairiel> we dont
[18:41:43 CET] <BtbN> unless it comes with a propper aliasing system so it doesn't duplicate all the data structures each time, at least I don't.
[18:44:35 CET] <Daemon404> ok
[18:45:01 CET] <ac_slater> wm4: any chance you peeked at that log I sent?
[18:45:07 CET] <ac_slater> ;)
[18:45:47 CET] <wm4> ac_slater: I just saw that you used -pix-fmt
[18:45:50 CET] <wm4> err -pix_fmt
[18:46:09 CET] <ac_slater> wm4: but there is an auto-inserted scaler
[18:46:12 CET] <ac_slater> I still need it?
[18:46:23 CET] <cone-559> ffmpeg 03Anton Khirnov 07master:ee359c72ef87: nvenc: rename encoders
[18:46:24 CET] <cone-559> ffmpeg 03Anton Khirnov 07master:aac7d6b284c3: nvenc: flush the encoder before closing it, as required by the docs
[18:46:25 CET] <cone-559> ffmpeg 03Anton Khirnov 07master:9d36cab4c0dc: nvenc: fix encoding with B-frames
[18:46:26 CET] <cone-559> ffmpeg 03Anton Khirnov 07master:c59fec783d65: nvenc: generate dts properly
[18:46:28 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:42f0ed67a34d: Merge commit 'c59fec783d6540dd96540b079d753ee4a6ad2e58'
[18:46:31 CET] <Daemon404> noops ahoy
[18:46:57 CET] <wm4> ac_slater: the scaler is inserted because the input is not 420p, and you forced the format to 420p
[18:47:50 CET] <ac_slater> wm4: interesting. I thought that would scale/convert automatically to 420p
[18:48:26 CET] <wm4> whether or not it does isn't clear from your log anyway, but I expect that it does without -pix_fmt if the AVCodec fields are set
[18:48:41 CET] <ac_slater> wm4: I see. So remove -pix_fmt ? 
[18:49:56 CET] <ac_slater> I tried and it does change anything. My resulting video is reporting 420p but the colors are all off
[18:50:03 CET] <ac_slater> I guess that's VEDRY vague
[18:50:05 CET] <ac_slater> VERT * 
[18:50:09 CET] <ac_slater> VERY * ... err
[18:54:24 CET] <ac_slater> wm4: here is the output http://i.imgur.com/ERM8dQw.png ... I'm starting to think it's my encoder
[18:55:07 CET] <wm4> maybe the linesizes are changing or so and your encoder doesn't handle it?
[18:55:16 CET] <ac_slater> yea maybe
[18:55:18 CET] <wm4> does the AVFrame you get have the correct format?
[18:55:22 CET] <ac_slater> yea
[19:04:51 CET] <durandal_1707> ac_slater: do you initialize chroma?
[19:12:42 CET] <ac_slater> durandal_1707: I wish I knew what that meant
[19:13:46 CET] <durandal_1707> ac_slater: using different linesize and width for chroma planes 
[19:14:21 CET] <durandal_1707> hard to guess without source code
[19:14:44 CET] <ac_slater> durandal_1707: hmm I do not do that manually as I'm struggling to figure out exactly how my encoder expects input. It says "YUV420PackedPlanar" 
[19:15:09 CET] <ac_slater> I was thinking that was the output format, but I guess that's also the input format :(
[19:15:28 CET] <durandal_1707> nonsense name for sure
[19:15:49 CET] <durandal_1707> what's planar and what packed in it
[19:16:01 CET] <ac_slater> no clue
[19:16:17 CET] <ac_slater> :( durandal_1707 it's a raspberry pi2 and I'm using the OMX layer to encode
[19:17:38 CET] <ac_slater> durandal_1707: apparently "YUV420PackedPlanar : packed per payload in planar slices"
[19:17:47 CET] <ac_slater> more vagueness
[19:18:34 CET] <ac_slater> durandal_1707: https://www.raspberrypi.org/forums/viewtopic.php?t=22019&p=208571 ... forth comment/reply
[19:19:08 CET] <wm4> oh, you're messing with RPI
[19:19:18 CET] <wm4> why not use MMAL?
[19:19:25 CET] <ac_slater> wm4: undocumented :(
[19:19:30 CET] <wm4> rcombs still has an encoder patch for it around somewhere
[19:19:46 CET] <ac_slater> ooo
[19:19:57 CET] <wm4> well just get into contact with popcornmix or so if you have questions about MMAL
[19:20:07 CET] <ac_slater> I could use that. But, my OMX encoder is working minus the issue with yuv output
[19:20:15 CET] <wm4> (he's maintaining parts of it and tends to be friendly and helpful)
[19:20:40 CET] <ac_slater> ah the xbmc guy
[19:20:58 CET] <wm4> yeah, he also works for broadcom
[19:21:01 CET] <wm4> or something
[19:21:14 CET] <ac_slater> very awesome
[19:21:58 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07master:2884cf205a9a: on2avc: limit number of bits to 30 in get_egolomb
[19:21:59 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07master:5b83b24ccbec: nuv: sanitize negative fps rate
[19:22:00 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07master:8431629dd112: xwddec: prevent overflow of lsize * avctx->height
[19:22:01 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07master:9cdddb93bb33: nutdec: only copy the header if it exists
[19:22:02 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07master:b06cb15b9d79: dca: fix misaligned access in ff_dca_convert_bitstream
[19:22:03 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:66eb8ce473e7: Merge commit 'b06cb15b9d7928bf54b639c9f9f7658c2c38bfb9'
[19:22:08 CET] Action: kierank uses 422 specifically to break silly people on rpis
[19:22:33 CET] <ac_slater> kierank: pis are silly, but they're the cheapest device I could find with an h264 encoder
[19:22:50 CET] <kierank> they aren't silly
[19:23:08 CET] <kierank> but people trying to use them instead of proper broadcast decoders are
[19:23:17 CET] <ac_slater> agreed
[19:24:16 CET] <ac_slater> kierank: since you know about 422, any idea how to unpack the Pi's 420PackedPlanar? ;)
[19:25:14 CET] <wm4> "packedplanar" sounds so nonsense
[19:25:21 CET] <wm4> maybe they mean nv12?
[19:25:33 CET] <ac_slater> wm4: I think since the call it that it's not like any other formats
[19:25:58 CET] <ac_slater> wm4: the link I posted has a broadcom guy explaining how it's laid out
[19:27:36 CET] <cone-559> ffmpeg 03Diego Biurrun 07master:4f22b138886e: x86: ac3dsp: Drop forward declaration for nonexisting function
[19:27:37 CET] <cone-559> ffmpeg 03Diego Biurrun 07master:03ef89faf23c: x86: build: Group all encoder objects together
[19:27:38 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:ea2df330525c: Merge commit '4f22b138886e29f7fffa8c715673951e51be9f32'
[19:27:39 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:d97a6193c323: Merge commit '03ef89faf23c4851848208c9fe004cd9ef690cec'
[19:29:41 CET] <cone-559> ffmpeg 03Michael Niedermayer 07master:09f4822e4eaf: flvdec: perform duration search just once
[19:29:42 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:949d6dd51ce1: Merge commit '09f4822e4eaf61513b9092414450f3ae920ccd9d'
[19:30:29 CET] <ac_slater> Anyone have a clue on how to manually extra Y,U, and V from 420p?
[19:31:10 CET] <kierank> ac_slater: download pyuv and play with the settings until they look right
[19:31:57 CET] <ac_slater> kierank: nice, pyuv from 2008. Dang
[19:34:11 CET] <ac_slater> kierank: ah, I see the github repo
[19:43:35 CET] <ac_slater> kierank: unfortunately, none of the things pyuv does can adjust for packed yuv
[19:43:39 CET] <ac_slater> unpacked?
[19:43:57 CET] <kierank> who knows how it's packed
[19:44:09 CET] <kierank> the only other way is to just make files 
[19:44:22 CET] <cone-559> ffmpeg 03Martin Storsjö 07master:e4eb13ca7762: flvdec: Add sanity checking of the last packet size
[19:44:23 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:e5b5676c0085: Merge commit 'e4eb13ca77624401ea7cef1ed6ad8e2d13fd2063'
[19:44:59 CET] <ac_slater> kierank: once I figure out how to get each channel from yuv420p, I can start playing with the packing
[19:45:26 CET] <kierank> yuv420p is just one big y plane and 2 subsampled uv
[19:46:03 CET] <durandal_1707> ac_slater: for extracting there is extractplanes filter
[19:46:12 CET] <ac_slater> but how large are the planes? I know almost nothing about yuv
[19:46:19 CET] <ac_slater> durandal_1707: interesting
[19:47:06 CET] <durandal_1707> u plane is quarter of y plane
[19:47:36 CET] <durandal_1707> or 1/16
[19:47:49 CET] <wm4> ac_slater: the link describes it as yuv420p
[19:47:59 CET] <wm4> except that there are restrictions on how it's laid out in memory
[19:48:06 CET] <ac_slater> exactly
[19:48:19 CET] <wm4> apparently it needs exact line size, and all planes in the same buffer with no offset between
[19:48:37 CET] <ac_slater> right, that's my understanding too
[19:48:40 CET] <wm4> you generally won't get it this way in the encoder, but copying the planes is trivial
[19:49:16 CET] <ac_slater> wm4: I'm restricting my input format to be 420p, so once I figure out how to extract the planes, then lay them out contiguously, we're oglden
[19:50:33 CET] <wm4> the planes are already "extracted", each AVFrame.data[n] pointer points to plane n
[19:50:38 CET] <durandal_1707> have you any C skills read others simple encoders
[19:51:01 CET] <ac_slater> durandal_1707: yea yea ;)
[19:52:10 CET] <ac_slater> wm4: so [0] = Y, [1] = U , [2] = V on my input image?
[19:52:14 CET] <ac_slater> AVFrame*
[19:52:25 CET] <durandal_1707> Yes
[19:52:25 CET] <wm4> yes
[19:52:31 CET] <ac_slater> thanks guys
[19:52:38 CET] <wm4> for yuv420p
[19:52:50 CET] <ac_slater> right. And the size of each plane is determined how?
[19:53:05 CET] <durandal_1707> see also linesize of each plane
[19:53:33 CET] <wm4> linesize is how many bytes you need to add to the plane pointer to get to the next vertical line of pixel
[19:54:03 CET] <wm4> the rest is up to the width and height fields, and what pixel format you're using
[19:54:55 CET] <ac_slater> durandal_1707: thanks mate
[19:58:51 CET] <durandal_1707> does vlc have some demuxers we can steal?
[20:01:36 CET] <kierank> durandal_1707: you can fuzz cfhd if you want :)
[20:02:27 CET] <durandal_1707> no, I trust its author skills :P
[20:03:08 CET] <durandal_1707> I don't have all the samples and its not commited
[20:03:10 CET] <ac_slater> wm4: hmm I'm struggling with this. So If I wanted the Nth line of Y, I would do, `nth_y = frame->data[0] + (frame->linesize[0] * n);` ? 
[20:03:23 CET] <wm4> ac_slater: yeah
[20:03:30 CET] <ac_slater> thanks mate
[20:03:49 CET] <durandal_1707> np bro :)
[20:04:08 CET] <ac_slater> wm4: just checking, same for U and V ? 
[20:04:30 CET] <wm4> yes, but be aware that they're half the size
[20:07:27 CET] <kierank> durandal_1707: can send you samples if you want
[20:07:41 CET] <durandal_1707> I wanted to write utvideo decoder asm
[20:08:05 CET] <durandal_1707> kierank: how much large?
[20:08:43 CET] <kierank> durandal_1707: not large
[20:08:59 CET] <ac_slater> wm4: alright great. Last thing, Y=320, U=160, V=160 (linesizes)... when I do avpicture_get_size(frame->format, w, h), I get 115200. But, 320*160*2 is 102400
[20:09:22 CET] <ac_slater> wrong function, or rounded up maybe
[20:09:46 CET] <wm4> it aligns the lines and start pointers
[20:09:53 CET] <wm4> maybe
[20:10:03 CET] <wm4> also avpicture_... is deprecated
[20:10:20 CET] <durandal_1707> isn't AVPicture deprecated
[20:10:53 CET] <wm4> hm it calls av_image_get_buffer_size with align=1
[20:11:46 CET] <wm4> ac_slater: what are the image dimensions?
[20:11:58 CET] <ac_slater> 320x240
[20:12:47 CET] <ac_slater> av_image_get_buffer_size() with align=1 returned the same size as the avpicture call obviously. Still 115200 
[20:13:03 CET] <wm4> 320*240+2*320/2*240/2==115200
[20:13:10 CET] <ac_slater> ohhh
[20:13:38 CET] <wm4> right, I see you say the line sizes are 160 for chroma
[20:14:01 CET] <wm4> so the chroma planes are padded by 40 bytes
[20:14:08 CET] <wm4> err
[20:14:23 CET] <wm4> they're not padded, well whatever
[20:16:37 CET] <ac_slater> wm4: I see... so (W*H + W * H/2) ... magic
[20:28:23 CET] <cone-559> ffmpeg 03Matthieu Bouron 07master:0d733ec3794d: lavc/mjpegdec: speed up scan data copy
[20:30:31 CET] <cone-559> ffmpeg 03Luca Barbato 07master:8fd361f53b3c: configure: Use pkg-config to check for openssl
[20:30:32 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:bd7da0ae7b6b: Merge commit '8fd361f53b3c17c1ae13a39e030c8fa3ab4d8f1f'
[20:33:05 CET] <cone-559> ffmpeg 03Luca Barbato 07master:c4de754d4dac: mathops: mips: Correctly enable loongson-specific assembly
[20:33:05 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:ba7d16a30353: Merge commit 'c4de754d4dac5ddae4d5a6f02798c0f560771921'
[20:34:03 CET] <cone-559> ffmpeg 03Luca Barbato 07master:e59708bb9d94: configure: mips: Support both-endian compilers
[20:34:04 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:f97d2d210553: Merge commit 'e59708bb9d94f67381f19344b5e021591eb711bf'
[20:41:05 CET] <cone-559> ffmpeg 03Arttu Ylä-Outinen 07master:7486418683bd: lavc: Make sure that the effective timebase would not overflow
[20:41:06 CET] <cone-559> ffmpeg 03Arttu Ylä-Outinen 07master:472d488ebcc5: libkvazaar: Set frame rate as a rational number
[20:41:07 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:e87ace6246fc: Merge commit '7486418683bd2477772e03aab573cf846c12fb0d'
[20:41:07 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:7daad5c44145: Merge commit '472d488ebcc53bea4cdb124edb94558e72d8f23f'
[20:42:05 CET] <cone-559> ffmpeg 03Vittorio Giovara 07master:e9175634ec96: yuv2rgb: Document the color space coefficients
[20:42:06 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:fafb18d14654: Merge commit 'e9175634ec96e36873929637491189150cfce9ec'
[20:42:33 CET] <Daemon404> noop noop noop
[20:48:42 CET] <wm4> the yuv2rgb coefficients were documented already?
[20:53:13 CET] <cone-559> ffmpeg 03Luca Barbato 07master:8e7bea6dc6ac: configure: Improve requesting specific features
[20:53:14 CET] <cone-559> ffmpeg 03James Darnley 07master:883ad2c59cee: fate: add 10-bit v210 encoder tests
[20:53:15 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:65d29dd274a3: mov: Add an option to toggle dref opening
[20:53:16 CET] <cone-559> ffmpeg 03Luca Barbato 07master:e93aa2c9e7b3: configure: Force-enable select_any dependencies only on --enable
[20:53:17 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:3de3937ecdd5: Merge commit '8e7bea6dc6ac5b21484774a026847bec0771ab62'
[20:53:18 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:b3702b6b660e: Merge commit '883ad2c59ceea1ced5495b5ccc83695ed4bbb94b'
[20:53:19 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:97d57424344f: Merge commit '65d29dd274a302131e2e4bc6d2b1eca4a093900c'
[20:53:20 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:3662e55943d3: Merge commit 'e93aa2c9e7b3599aee6a5820760fc1a2c629dea0'
[20:53:26 CET] <Daemon404> wm4, yes
[20:53:29 CET] <Daemon404> same patch even
[20:53:56 CET] <J_Darnley> Hey look.  There I am again.
[20:54:05 CET] <nevcairiel> your noop merges are weird, you should leave the reference which commit you skipped in the message =p
[20:54:13 CET] <J_Darnley> (which reminds me, I need to look for more replies)
[20:54:37 CET] <Daemon404> nevcairiel, i need to change my default merge settings
[20:54:41 CET] <Daemon404> to list commits
[20:54:50 CET] <nevcairiel> thats default for me
[20:54:56 CET] <Daemon404> not me for some reason
[20:55:01 CET] <Daemon404> man git-merge didnt show me much
[20:55:05 CET] <Daemon404> it's not very searchable
[20:56:32 CET] <Daemon404> --log
[20:56:35 CET] <Daemon404> not sure what it is on git config
[20:57:05 CET] <cone-559> ffmpeg 03Vittorio Giovara 07master:9d3ea5cbf57e: imgconvert: Drop outdated comment block
[20:57:06 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:54f49bd3781c: Merge commit '9d3ea5cbf57e30bf2717a9ce64e858dad8a02aa6'
[20:57:11 CET] <Daemon404> now with 100% more log
[20:57:15 CET] <J_Darnley> That's the good thing about git.  Config is somehow seprate from the programs it affects.
[20:57:27 CET] <Daemon404> :D
[20:59:32 CET] <BBB> nevcairiel: tired of merging already? :D
[20:59:40 CET] <Daemon404> BBB, may as well split the load
[20:59:46 CET] <Daemon404> otherwise killign sprees etc
[21:00:18 CET] <BBB> some people have claimed we make libav relevant by merging their commits
[21:00:23 CET] <nevcairiel> Daemon404: i use this script http://pastebin.com/TKtQwURs .. so i guess i added --log
[21:00:38 CET] <BBB> or, inversely, libav becomes irrelevant if we stop merging
[21:01:04 CET] <cone-559> ffmpeg 03Vittorio Giovara 07master:892f037c55d8: imgconvert: Move the shrink functions only where needed
[21:01:05 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:fa48cd8814e7: Merge commit '892f037c55d86ce36f8705fbeab052189312a13e'
[21:01:31 CET] <Daemon404> i dont buy into either of those
[21:04:14 CET] <Daemon404> hmm... i wonder if kierank will murder me if i merge this deprecation commit
[21:04:19 CET] <Daemon404> for avcodec_get_chroma_sub_sample
[21:04:27 CET] <Daemon404> does it have a replacement?
[21:04:30 CET] <wm4> isn't there a libavutil equivalent
[21:04:33 CET] <nevcairiel> avutil one i think
[21:04:43 CET] <wm4> av_pix_fmt_get_chroma_sub_sample
[21:04:47 CET] <cone-559> ffmpeg 03Vittorio Giovara 07master:f7168d7016f7: imgconvert: Move AVPicture-related static function to the deprecated section
[21:04:48 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:fa6c7ccc20d3: Merge commit 'f7168d7016f7d1034ec90223fa91a90711704e11'
[21:04:55 CET] <Daemon404> wm4, ic
[21:05:06 CET] <kierank> ok
[21:05:14 CET] <kierank> so we now have 3 subsample functions
[21:05:41 CET] <Daemon404> looks more like were going to remove the old ones?
[21:06:03 CET] <kierank> ok
[21:06:23 CET] <Daemon404> https://git.libav.org/?p=libav.git;a=commitdiff;h=d43a165bda0eae95f4c7a168c7d13d94966c1a09;hp=f7168d7016f7d1034ec90223fa91a90711704e11
[21:06:27 CET] <Daemon404> the commit in question
[21:06:58 CET] <Daemon404> so just s///?
[21:09:31 CET] <cone-559> ffmpeg 03Piotr Bandurski 07master:7c4059ae1e96: riff: add YUYV FourCC (Drastic YUYV)
[21:09:32 CET] <cone-559> ffmpeg 03Vittorio Giovara 07master:d43a165bda0e: imgconvert: Add the proper API guards to a deprecated function
[21:09:33 CET] <cone-559> ffmpeg 03Piotr Bandurski 07master:55c7e5bf7c8d: riff: add C210 FourCC (Canopus C210)
[21:09:34 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:e15e10888534: Merge commit 'd43a165bda0eae95f4c7a168c7d13d94966c1a09'
[21:09:35 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:11e6f13a1330: Merge commit '55c7e5bf7c8d368c9bc60a219b04849ec9f4c84c'
[21:10:13 CET] <Daemon404> all the tribial merges done... now it's all koda api-changing stuff
[21:11:22 CET] <Daemon404> most of them are moving avctx members to private options
[21:11:29 CET] <Daemon404> i dont know if ffmpeg people have opinions on those or not.
[21:13:03 CET] <wm4> generally sounds like a good idea
[21:13:08 CET] <durandal_1707> those are ok, moving stuff where it really belongs
[21:13:13 CET] <Daemon404> i agree
[21:13:15 CET] <Daemon404> but there's uh
[21:13:17 CET] <Daemon404> special people
[21:13:19 CET] <Daemon404> around ffmpeg
[21:13:22 CET] <Daemon404> when ti comes to giant structs
[21:13:24 CET] <Daemon404> so...
[21:13:29 CET] <wm4> just look out for decoders which use them and which are not in libav
[21:13:38 CET] <Daemon404> of course
[21:13:48 CET] <Daemon404> i just dont want to get HEY MR D404 WHY U MERGE EVIL
[21:14:21 CET] <wm4> they'd post patches to revert it
[21:14:32 CET] <Daemon404> true
[21:14:32 CET] <wm4> while calling you evil
[21:18:07 CET] <durandal_1707> anybody against dvaudio parser?
[21:18:27 CET] <Compn> parser is required then ?
[21:21:17 CET] <cehoyos> Daemon404: Hi, your merges broke --disable-everything. Could you revert?
[21:21:38 CET] <cone-559> ffmpeg 03Vittorio Giovara 07master:0e6c85322157: lavc: Move b_frame_strategy and b_sensitivity to codec private options
[21:21:39 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:2e9b995e4f7f: Merge commit '0e6c8532215790bbe560a9eea4f3cc82bb55cf92'
[21:21:51 CET] <Daemon404> cehoyos, define broke
[21:21:53 CET] <Compn> cehoyos :  i think Daemon404 would rather ask for patch to fix --disable-everything instead of reverting , if thats ok with you cehoyos
[21:21:57 CET] <Daemon404> it was supposed to change its behavior
[21:22:20 CET] <Daemon404> unless it broke in some unintended way
[21:22:25 CET] <cehoyos> Then please revert the behaviour change: This is a very important function, it should not be broken without any warning.
[21:22:37 CET] <Daemon404> first tell me how it broke
[21:22:43 CET] <Daemon404> im not going to blindly revert withotu more info
[21:22:48 CET] <cehoyos> ./configure && make ffmpeg
[21:22:53 CET] <cehoyos> Used to work, does not work anymore
[21:23:01 CET] <Daemon404> uh?
[21:23:03 CET] <cehoyos> Sorry, please ignore
[21:23:14 CET] <cehoyos> ./configure --disable-everything && make ffmpeg
[21:23:25 CET] <cehoyos> This is broken since your configure merges.
[21:24:18 CET] <Daemon404> theres a uh... i might have broke it differently
[21:24:19 CET] <Daemon404> ./libavcodec/version.h:20:0: error: unterminated #ifndef #ifndef AVCODEC_VERSION_H
[21:24:22 CET] <Daemon404> this is why i see
[21:25:32 CET] <Daemon404> let me fix this then i will test
[21:25:37 CET] <cehoyos> Please revert before doing other commits: This is extremely annoying and --disable-everything is a very important option for bug tracking.
[21:25:38 CET] <Daemon404> too many screwups!
[21:25:58 CET] <wm4> why is it important for bug tracking?
[21:26:11 CET] <cehoyos> I cannot work on bug reports without it
[21:26:24 CET] <wm4> for what reason?
[21:26:26 CET] <cehoyos> OR how do you do regression tests?
[21:26:43 CET] <Compn> wm4 asks why not just use ffmpeg iwth all features enabled to do regression testing ?
[21:27:03 CET] <cehoyos> Because even my time is unfortunately not unlimited;-((
[21:27:13 CET] <Compn> too long to compile ?
[21:27:27 CET] <wm4> hm could make sense for bisecting I guess
[21:27:40 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:5889bc16a4f6: avcodec/version: Add missing #endif
[21:27:56 CET] <Daemon404> ok now to look at disable-everything
[21:28:07 CET] <Compn> (cough: last commit fixes broken build)
[21:28:54 CET] <nevcairiel> there is a commit on the libav ml to restore disable-everything behavior
[21:29:00 CET] <nevcairiel> but i dont think they pushed it yet
[21:29:38 CET] <Daemon404> i will revert
[21:29:41 CET] <nevcairiel> but maybe you can steal it if it fixes everyhting
[21:29:43 CET] <Daemon404> and re-merge once it is fixed
[21:29:44 CET] <Daemon404> properly
[21:29:51 CET] <cehoyos> Thank you!
[21:29:52 CET] <Daemon404> no ill wait until its properly un-screwed
[21:33:53 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:cefad29df93a: configure: Revert recent changes to disable-everything
[21:34:06 CET] <Daemon404> ^ cehoyos 
[21:34:46 CET] <jamrial> msvc is broken again
[21:34:56 CET] <Daemon404> jamrial, surely not from me though!
[21:35:14 CET] <Daemon404> unles it was the avcodec issue
[21:35:23 CET] <nevcairiel> no its the mjpeg change
[21:35:28 CET] <nevcairiel> ssize_t is not available
[21:35:38 CET] <cehoyos> Thank you! Are you the new maintainer?
[21:35:40 CET] <jamrial> whoops, this window didn't scroll and i missed the above discussion
[21:35:58 CET] <Daemon404> cehoyos, i am helping out nevcairiel because he wanted a break
[21:36:12 CET] <cehoyos> Why don't we all break from these merges?
[21:36:21 CET] <Daemon404> not touching that with a 10 foot pole
[21:36:26 CET] <cehoyos> Or probably "take a break"...
[21:36:42 CET] <Daemon404> nevcairiel, indeed
[21:38:59 CET] <Daemon404> ssize_t length = (ptr - src) - (skip);
[21:39:03 CET] <Daemon404> shoulnt this be ptrdiff_t
[21:40:37 CET] <nevcairiel> probably
[21:41:22 CET] <jamrial> and in any case better than ssize_t considering it's apparently not available on msvc
[21:41:44 CET] <Daemon404> what's the usecase of ssize_t anyway
[21:41:55 CET] <Daemon404> pls dont say returning -1 as error for size_t returnign funcs
[21:41:56 CET] <rcombs> Daemon404: size_t for functions that might return a negative error code
[21:42:00 CET] <Daemon404> god dammit
[21:42:28 CET] <Daemon404> i thought that might be the case... but ew.
[21:42:40 CET] <JEEB> :3
[21:42:47 CET] <wm4> better than returning (size_t)-1
[21:42:52 CET] <wm4> or (void*)-1
[21:42:56 CET] <rcombs> hey you asked
[21:43:32 CET] <rcombs> wm4: the OS X standard lib has at least one case of assigning special values to pointers between 0 and& 4, I think?
[21:44:03 CET] <wm4> *shrug*
[21:44:18 CET] <wm4> usually osx has windows-style error codes
[21:44:25 CET] <michaelni> make libavformat/seek-test -> tls_openssl.c:(.text+0x9e3): undefined reference to `SSL_ctrl'
[21:44:28 CET] <wm4> one big namespace for EVERYTHING
[21:44:34 CET] <michaelni> and lots of other errors
[21:45:02 CET] <Daemon404> michaelni, i reverted the changes that touched the ssl stuff in configure
[21:45:04 CET] <Daemon404> did you pull since then
[21:45:59 CET] <rcombs> http://www.opensource.apple.com/source/dyld/dyld-96.2/include/dlfcn.h has a few `((void*)-1)` and such
[21:46:21 CET] <Daemon404> michaelni, oh... i see... its fixed later on in libav
[21:46:33 CET] <Daemon404> of course, after the giant wall of tedious-to-merge commits
[21:46:47 CET] <Daemon404> michaelni, https://git.libav.org/?p=libav.git;a=commit;h=c0c4d7a0a556ec66e3068d36a883e84d1efb0690
[21:46:51 CET] <wm4> rcombs: ah, terrible, looks like it might be posix
[21:47:07 CET] <rcombs> implementation-defined special pointer values
[21:47:33 CET] <jamrial> Daemon404: in our case we have use_pkg_config, which they don't
[21:47:51 CET] <jamrial> i can update the configure check with that right now, and then you just noop that commit
[21:47:58 CET] <Daemon404> jamrial, go for it
[21:48:11 CET] <Daemon404> i wont be finishing a giant set of api commits today.
[21:49:39 CET] <Daemon404> michaelni, see ^
[21:50:42 CET] <jamrial> ok, one sec while i test it
[21:53:43 CET] <Daemon404> nevcairiel clearly should have warned me about different people's patches =p
[21:53:47 CET] Action: Daemon404 runs
[21:54:37 CET] <Daemon404> no more merges today
[21:55:39 CET] <mateo`> nevcairiel, Daemon404: is ptrdiff_t available on msvc ?
[21:56:35 CET] <Daemon404> michaelni, it is since 2010 or so
[21:56:42 CET] <Daemon404> and for older versions we requrie msinttypes
[21:56:44 CET] <Daemon404> which has it
[21:56:45 CET] <nevcairiel> mateo`: yes thats fine
[21:56:46 CET] <Daemon404> er mateo`
[21:59:23 CET] <cone-559> ffmpeg 03James Almer 07master:09d5c28c3dc4: configure: fix openssl pkg-config check
[21:59:27 CET] <jamrial> michaelni: ^
[22:02:42 CET] <jamrial> also, libavcodec/options-test is throwing a Floating point exception since a couple commits ago
[22:02:55 CET] <jamrial> http://fate.ffmpeg.org/report.cgi?time=20160127201034&slot=x86_64-freebsd8.2-gcc3.4.6
[22:03:12 CET] <Daemon404> of all the breakage
[22:03:14 CET] <Daemon404> that one is unexpected
[22:03:33 CET] <jamrial> http://git.videolan.org/?p=ffmpeg.git;a=shortlog;h=78133-g54f49bd;hp=78110-ge5b5676 one of these merges
[22:03:51 CET] <mateo`> nevcairiel, Daemon404: i've sent the fix to the ml, (i just ran fate + tested the sample michael provided)
[22:03:52 CET] <Daemon404> most of those are noops
[22:04:25 CET] <Daemon404> jamrial, i cant see anything there that would cause an FPE...
[22:06:07 CET] <jamrial> commit e87ace6246fc6528a9a8304abdb81858c70cefb7 is the culprit
[22:06:58 CET] <jamrial> "avctx->ticks_per_frame > INT_MAX / avctx->time_base.num" maybe?
[22:07:40 CET] <Daemon404> yeah
[22:07:45 CET] <Daemon404> thats the only thing i see
[22:07:49 CET] <Daemon404> but wouldnt that be integer division?
[22:09:36 CET] <Daemon404> gdb...
[22:09:48 CET] <jkqxz> Integer-divide-by-zero is undefined behaviour in C.  Lots of people choose "raise SIGFPE" as their undefined thing to do.
[22:10:05 CET] <Daemon404> ah yes.
[22:10:09 CET] <Daemon404> avctx->time_base.num may be 0.
[22:10:19 CET] <Daemon404> den wont bem but num may be
[22:11:53 CET] <Daemon404> yes that fixes it
[22:11:57 CET] <Daemon404> sendign a patch to ML.
[22:52:54 CET] <jya> BBB: for your ffvp9 comparison, while of course you can compare chrome vs firefox. If you want to directly compare libvpx vs ffvp9 ; the best would be to use the flag media.ffvpx.enable and change between true or false. To get Firefox to use vp9 in Youtube, you need to set media.mediasource.webm.enabled to true (it is off by default at present, we only turn
[22:52:54 CET] <jya> it on if the OS doesn't have a h264 decoder or if we find that h264 hardware decoding doesn't work (because the graphic cards is black listed)
[22:53:38 CET] <BBB> Im pretty sure I dont have h264 decoding hw
[22:54:04 CET] <BBB> and although libvpx-vs-ffvp9-in-firefox is fun, wouldnt it be much better to make fun of chrome? ;)
[22:56:52 CET] <nevcairiel> how do you even properly benchmark a browser
[22:58:09 CET] <BBB> cpu usage is 50% cpu usage is 70% its different!!112"
[22:58:19 CET] <BBB> (when playing the same youtube video)
[22:58:29 CET] <TD-Linux> alternately, measure power draw
[22:58:36 CET] <jya> BBB: the way I've done it is in youtube
[22:58:48 CET] <jya> if you right click on the video, you see "stats for nerds"
[22:58:49 CET] <nevcairiel> Daemon404: you should push that diff-by-zero patch, half of fate is turning yellow
[22:59:14 CET] <jya> it will show you the current resolution , how many frames have been decoded and more importantly how many frames have been dropped
[22:59:32 CET] <nevcairiel> "both managed to play the video without dropping frames", hooray =p
[22:59:58 CET] <jamrial> yeah, assuming both decoders don't tax the cpu, that will not let you know which is faster
[23:00:27 CET] <jya> comparing libvpx vs ffvp9 (as to be fair it's the only thing that we're really comparing). If found that on a low end HP laptop (a $500 i3 quadcore). Where we could do only 720p with libvpx 
[23:00:35 CET] <jya> we could do 1440p with ffvp9
[23:00:49 CET] <jya> now it's a bit silly test because that laptop has a 1360x768 screen only
[23:01:04 CET] <BBB> :D
[23:01:23 CET] <BBB> you can spend the saved cpu on downscaling the image in software
[23:01:27 CET] <jya> but that was still interesting to test purely on the CPU level. That laptop has HW VP9 
[23:01:36 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:265ed6732fbd: libavcodec/util: Fix timebase overflow check
[23:02:18 CET] <jya> however, with those intel drivers, VP9 was buggy and a fewtimes I hard to restart the computer (because chrome *will* use hardware vp9 decoding if available, regardless of how buggy that stuff is
[23:02:19 CET] <nevcairiel> Intel doesn't have a full hw vp9 decoder, sorry no cookies :D
[23:02:44 CET] <nevcairiel> its hybrid and slow
[23:02:46 CET] <jya> nevcairiel: it's partially accelerated. and the decoding is done via their WMF drivers
[23:03:05 CET] <nevcairiel> nvidia are the only ones with a full vp9 decoder, which is actually fast
[23:03:07 CET] <jya> as opposed to being decoded in either libvpx or ffvp9
[23:03:29 CET] <Daemon404> didnt the hybrid one use just as much cpu
[23:03:34 CET] <Daemon404> and was slower
[23:03:34 CET] <jya> yeah, but currenly only on linux via vdpau.
[23:03:45 CET] <nevcairiel> its less cpu, but slower
[23:04:11 CET] <nevcairiel> jya: windows dxva vp9 works fine, i wrote it for ffmpeg afterall
[23:04:17 CET] <jya> Daemon404: actually not my finding, CPU usage playging vp9 on youtube was fairly low. it's just unstable. From time to time, no more video frames come out and you must power cycle the laptop
[23:04:56 CET] <jya> anyhow, that's not what I wanted to talk about, getting sidetracked.
[23:05:18 CET] <jya> BBB: on a dual core, the difference between ffvp9 and libvpx were less obvious.
[23:05:28 CET] <Daemon404> jya, sounds like a pleasant experience? >_>
[23:05:45 CET] <BBB> jya: on a typical machine, ffvp9 should be 30-40% faster from what I recall
[23:05:47 CET] <jya> when comparing chrome vs firefox in youtube using the "Stats for Nerds" there's one thing I've noticed
[23:06:02 CET] <BBB> as in, it used to be 40% faster but libvpx copied some of our approaches so now its 30%
[23:06:15 CET] <nevcairiel> BBB: is that single threaded?
[23:06:21 CET] <nevcairiel> I would think MT adds a lot more
[23:06:22 CET] <BBB> yes
[23:06:25 CET] <jya> we (firefox) attempt to keep audio at all time, we will drop video frames or skip to the next keyframes when video decoding is really behind so that audio is perfect
[23:06:52 CET] <jya> chrome on the other hand, just pause the whole lot, start decoding in a loop, and when it has enough video frames will resume.
[23:07:16 CET] <jya> so the experience watching 4K on those low end laptop is that on Firefox, you only get the audio perfectly with a few video keyframe showing
[23:07:24 CET] <jya> while chrome will jsut pause ever 3-4s
[23:07:37 CET] <nevcairiel> not sure if either is any better
[23:07:48 CET] <BBB> reminds me of realmedia
[23:07:50 CET] <BBB> "buffering"
[23:07:53 CET] <jya> I don't know which approach is less sucky :)
[23:07:55 CET] <nevcairiel> personally i never bothered to really "work" on bad performance situations
[23:07:58 CET] <Daemon404> i must ask
[23:08:01 CET] <Daemon404> why even do that
[23:08:06 CET] <Daemon404> such a low end laptop wont even have a 4k screen
[23:08:08 CET] <Daemon404> or even 2k
[23:08:18 CET] <jya> Daemon404: because you can ?
[23:08:23 CET] <Daemon404> thats a terrible reason
[23:08:56 CET] <jya> i've only been working at mozilla for 18 months, but what I've learnt there is that with such big user count. If there's something that can break it will
[23:09:20 CET] <jya> so many times I've put a task aside because really this won't ever happen, it's just too dumb
[23:09:20 CET] <nevcairiel> of course, users break everything
[23:09:24 CET] <Daemon404> maybe i should start forwarding mozilla breakages to you from work (vimeo)
[23:09:25 CET] <jya> without fail it will happen
[23:09:27 CET] Action: Daemon404 runs
[23:09:43 CET] <jamrial> on my old k10 dual core, ffvp9 could play 1080p <=30fps content whereas libvpx would struggle
[23:09:46 CET] <jya> Daemon404: please do, we can only fix bugs if we know about them
[23:09:52 CET] <Daemon404> jya, yeah i know
[23:09:58 CET] <Daemon404> but bugzilla is ain to devnull
[23:10:01 CET] <Daemon404> i speak from experience
[23:10:02 CET] <Daemon404> akin*
[23:10:13 CET] <jya> not if you set the proper group
[23:10:21 CET] <jya> Core -> Audio/Video Playback
[23:10:33 CET] <jya> the media team, while small is very reactive
[23:11:28 CET] <jya> jamrial: yes, typically a 720p 30fps that play just with libvpx we could play the same video at 60fps with ffvp9 
[23:12:41 CET] <jya> BBB: I'll add you to my spreadsheet with some of my results. those were done using ffvp9 form ffmpeg 2.8
[23:12:51 CET] <BBB> ok ty
[23:13:51 CET] <jya> I have a video, on my mac pro I can play it in realtime with ffvp9
[23:14:09 CET] <jya> it takes 25s to play 10s using chrome
[23:14:25 CET] <jya> 49s if libvpx isn't compiled with -O
[23:15:40 CET] <Daemon404> jya, http://chromashift.org/ff/1frame.mp4
[23:15:50 CET] <Daemon404> seeking after video-end is broken
[23:15:57 CET] <Daemon404> this file has audio for 1 min + 1 static frame
[23:16:01 CET] <Daemon404> enjoy!
[23:16:46 CET] Action: Daemon404 cant be arsed to make a Yet Another Bug Tracker Account at 10pm
[23:16:50 CET] <jya> BBB: you can use this too. https://people.mozilla.org/~jyavenard/tests/frame-drop-test/ it will play bunny in various resolutions and display the number of frames dropped
[23:17:06 CET] <jya> so now again, chrome cheat on the number because it almost never drop frames, it just pauses
[23:18:09 CET] <jya> Daemon404: if it is what I think it is, we don't handle those videos (where you have a single video frames)
[23:18:23 CET] <jya> dailymotion also have heaps of those music videos.
[23:18:37 CET] <nevcairiel> its a bane of many video players
[23:18:39 CET] <jya> Flash handled them perfectly, so they continue to use flash for those
[23:19:24 CET] <jya> now if the video frame was marked as having a 1 minute duration that would probably work. but if the video has a short duration, then it will just stall
[23:19:55 CET] <jya> and this is by spec. the buffered range of a media element, is defined as the intersection between the audio buffered range and the video track buffered range
[23:20:10 CET] <Daemon404> jya, it happens on any video where audio rusn longer than video
[23:20:17 CET] <Daemon404> you cant seek to any point past video
[23:20:24 CET] <Daemon404> and this is a very common thing to have
[23:20:30 CET] <Daemon404> (think, e.g. slideshows)
[23:20:35 CET] <Daemon404> or screen captures
[23:20:38 CET] <jya> I read this as: the buffered range is what we can actually play. If you have no audio or video at a particular point -> we stall it's not buffered
[23:21:20 CET] <jya> Daemon404: that may well be the case for your default video player. but with html5 you have strict specifications and rules on how things are to behave. so I tag this as the file is broken
[23:22:05 CET] <jya> try setting in the container the duration of the video frame to be the same as the duration of the entire video, and you'll find that it will work
[23:22:51 CET] <Daemon404> how exactly do you defined "buffered range"
[23:22:54 CET] <Daemon404> define*
[23:23:41 CET] <Daemon404> for example: an mp4 has a timeline duration, which is separate from track duration
[23:23:46 CET] <Daemon404> and which should be respected above those
[23:23:49 CET] <Daemon404> (IMO)
[23:24:17 CET] <jya> BBB: actually, it's already shared: https://docs.google.com/spreadsheets/d/1JvD7GJmr-Krk27sx9gv2tAeNGFYPxxy8kX27lgJDKno/edit?usp=sharing
[23:25:28 CET] <jya> https://html.spec.whatwg.org/multipage/embedded-content.html#dom-media-buffered 
[23:25:42 CET] <jya> "Users agents must accurately determine the ranges available, even for media streams where this can only be determined by tedious inspection."
[23:25:54 CET] <jya> so the buffered range is calculated on what frames are available
[23:26:02 CET] <jya> that's our "tedious inspection"
[23:26:14 CET] <jya> let me check what we have for your video
[23:26:31 CET] <Daemon404> i would argue the mvhd duration supercedes the track duration here
[23:27:03 CET] <jya> i would say that neither apply, only the sample table
[23:27:19 CET] <Daemon404> thats pretty much opposite of what mp4 says you should do
[23:27:27 CET] <jya> where?
[23:27:41 CET] <Daemon404> the specs are all behind paywalls
[23:28:03 CET] <Daemon404> but it's the presentation layer that takes precedent almost always
[23:28:10 CET] <Daemon404> (yes mp4 has such a thing)
[23:28:17 CET] <TD-Linux> that spec actually sounds like it's referring to streaming containers like ts or ogg.
[23:28:32 CET] <TD-Linux> it's ridiculous in general how the spec tries to avoid naming any containers though :(
[23:28:33 CET] <Daemon404> TD-Linux, it reads quit vague to be TD-Linux 
[23:28:41 CET] <Daemon404> quite*
[23:29:32 CET] <jya> Daemon404: if you tell me which part of the spec it is, I can have a look
[23:29:53 CET] <Daemon404> i'd need to refer to Paranoialmaniac for a place in the spec
[23:30:04 CET] <Daemon404> fwiw, firefox is the only browser which fails.
[23:30:23 CET] <jya> Daemon404: closer inspection (ffprobe) of the file shows me that it has a single video frame: pts_time=0.000000 duration_time=0.042709
[23:30:33 CET] <Daemon404> it has a media duration
[23:30:35 CET] <Daemon404> -show_format
[23:30:41 CET] <Daemon404> the mvhd box has it set correctly
[23:30:46 CET] <jya> so the buffered range for that video will always be [0, 0.042709]
[23:30:51 CET] <Daemon404> youre nto listening
[23:31:32 CET] <Daemon404> mp4 has both track duration and *full media* duration code.d
[23:31:41 CET] <Daemon404> the latter of which represents the entire file.
[23:31:43 CET] <jya> i am listening, I'm telling you on why you can't seek in those videos. video.seekable is [0, 0.042709]
[23:31:58 CET] <Daemon404> sure. and im saying firefox does it wrong here. and is teh only browser to do so.
[23:32:16 CET] <Daemon404> because the global duration is set correctly
[23:32:18 CET] <jya> I'll argue we're doing it right, and all the other are wrong :D
[23:33:41 CET] <jya> there are so many wrongly formatted mp4 files out there, that we just can't rely exclusively on the container. the only thing that's ever accurate is the actual data it contains
[23:33:45 CET] <Daemon404> i can only disagree. the spec makes no mention of tracks, only "ranges of the media resource"
[23:34:00 CET] <Daemon404> in mp4, the mvhd duration is the defacto range.
[23:34:03 CET] <jya> just like we even stopped looking at the dimensions set in the mp4 and instead decode the SPS NAL
[23:34:38 CET] <Daemon404> mp4 does not have an sps nal
[23:34:40 CET] <Daemon404> it's a separate box
[23:34:46 CET] <Daemon404> if you have an sps packet in an mp4, it is illegal.
[23:34:47 CET] <jya> because almost all the time, people got it wrong between frame dimensions and display dimension: so they displayed with wrong aspect ratio
[23:35:02 CET] <jya> you have it in the avcC atom
[23:35:09 CET] <Daemon404> thats a box, not a NAL
[23:35:14 CET] <jya> or if AVC3 in one of the sample
[23:35:30 CET] <jya> yes, the avcC atom (mp4) contains a SPS NAL
[23:35:37 CET] <jya> youre arguing semantics
[23:35:38 CET] <Daemon404> nit: mp4s dont have atoms
[23:35:40 CET] <Daemon404> only mov does ;P
[23:35:45 CET] <Daemon404> in mp4 theyre boxes.
[23:36:00 CET] <Daemon404> sure, but so are you
[23:36:08 CET] <Daemon404> your linked spec does nothing to back you up either
[23:36:08 CET] <jya> fine ... no point continuing then, this is leading nowhere
[23:36:13 CET] <nevcairiel> Daemon404: if sps inband in mp4 is legal or not depends on which codec identifier is used
[23:36:21 CET] <Daemon404> nevcairiel, very true
[23:36:27 CET] <Daemon404> your are right.
[23:37:36 CET] <Daemon404> jya, if you say so. you may stick to you "literally everyone else on earth is wrong" stance if you wish. You should learn about the presentation layer properly though at some point.
[23:37:40 CET] <Daemon404> i wont bikeshed here anymore
[23:37:44 CET] <jya> Daemon404: wants your video to play in firefox, have the duration of the video frame extend to where audio ends. simple. You'll also find that once you guy move to MSE, the behaviour I've described is even more correct
[23:38:18 CET] <jya> because then your video won't play with any browsers out there at all, because they all enforce that rules
[23:38:21 CET] <Daemon404> we have moved to mse ;)
[23:38:36 CET] <Daemon404> but im talking progressive here
[23:39:16 CET] <Daemon404> and you can keep parrottign the same "but teh video track duration is short!" nd ignore the resentation later, it doesnt really sell me on it.
[23:39:19 CET] <jya> MSE has very clearly defined that buffered range == seekable attribute and is identical to the *frames* time 
[23:39:36 CET] <Daemon404> i never said firefox's MSE behavior was wrong
[23:39:40 CET] <Daemon404> i wouldnt expect it to work in MSE
[23:40:01 CET] <jya> well, mp4 is mp4. fragmented or not
[23:40:43 CET] <Daemon404> global duration is generally not set in many fragmented mp4 at all
[23:40:48 CET] <jya> we just use the same logic: buffered range are calculates on the actual demuxed frames
[23:40:50 CET] <Daemon404> it's allowed to be 0
[23:40:55 CET] <Daemon404> unlike non-fragmenetd mp4.
[23:41:07 CET] <jya> 0 means infinity 
[23:41:11 CET] <Daemon404> yes
[23:41:50 CET] <Daemon404> like i said, i see nothinf in the html5 spec mentionign anything that would invalidate the mvhd duration
[23:41:59 CET] <Daemon404> but in MSE, yes. 
[23:42:05 CET] <jya> and you'll find nothing validating it either :)
[23:42:43 CET] <Daemon404> yes but in the absence of an actual strict html5 spec, one would sanely defer to the container spec
[23:42:50 CET] <Daemon404> to define what said buffered range is
[23:42:55 CET] <Daemon404> not a generic "tracks"
[23:43:11 CET] <Daemon404> that would be my argument, anyway.
[23:44:48 CET] <Daemon404> and for MSE it's a bit easier: we have separate tracks.
[23:45:01 CET] <Daemon404> er, fielsp er track
[23:45:15 CET] <Daemon404> buffers, etc
[23:47:53 CET] <Daemon404> so i suppose this argument will be moot whenever we switch on to 100%
[23:49:00 CET] <jya> Daemon404: loading this in safari, when I seek, audio seek but then no video frame is displayed: it's black (1frame.mp4)
[23:49:12 CET] <Daemon404> that can be considered correct
[23:49:34 CET] <Daemon404> i dont believe the mp4 spec defines what do to with teh ended track
[23:52:38 CET] <llogan> michaelni: what's the occassion for the new point releases since there were some 12 days ago? security stuff?
[23:54:09 CET] <jya> seeing that seekable == buffered here (because we construct our buffered range based on the actual frames), so when seeking (https://html.spec.whatwg.org/multipage/embedded-content.html#seeking) we fall into the step 8. that is currentTime > seekable.end(seekable.length-1) , so we end up seeking to the end of the video frame
[23:54:58 CET] <Daemon404> i dont agree with not being able to seek within the presentation duration, really
[23:55:11 CET] <Daemon404> but as i said, it'll be a moot argument soon anyway
[23:55:19 CET] <Daemon404> we wont be servign any progressive
[23:55:32 CET] <jya> any timeframe?
[23:55:47 CET] <Daemon404> right now 20-30% is MSE
[23:56:17 CET] <Daemon404> this week or next all new stuff will be MSE, i think
[23:56:39 CET] <Daemon404> should be serving mostly MSE within a month, i hope?
[23:58:31 CET] <jya> Daemon404: that's great 
[23:58:32 CET] <kierank> Haha you web people not learning the mistakes of broadcadt
[23:58:44 CET] <Daemon404> kierank, im sure we havent
[23:58:52 CET] <Daemon404> which one here
[23:59:10 CET] <kierank> Dunno
[23:59:27 CET] <kierank> All of them
[23:59:41 CET] <Daemon404> we learned some
[23:59:45 CET] <Daemon404> you dont see interlaced web content
[00:00:00 CET] --- Thu Jan 28 2016