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

[burek]

[00:00:06 CET] <kierank> Yeah but you see vfr
[00:00:08 CET] <kierank> That's worse
[00:00:20 CET] <J_Darnley> I'm sure you can find interlaced somewhere!
[00:00:44 CET] <Daemon404> kierank, there's vfr in broadcast
[00:00:48 CET] <Daemon404> you just telecine it craftily
[00:00:52 CET] <Daemon404> so it's "not" vfr
[00:01:03 CET] <kierank> Yes
[00:01:11 CET] <Daemon404> (and it looks like crap)
[00:01:36 CET] <nevcairiel> i hate broadcasts that switch between telecine and true interlaced at will, its hell on processing pipelines
[00:01:49 CET] <Daemon404> thats not so bad
[00:01:55 CET] <Daemon404> it's worse when they overkay it on eachother
[00:02:04 CET] <Daemon404> 60i overlayed on telecined material
[00:02:05 CET] <Daemon404> yum yum.
[00:02:37 CET] <nevcairiel> that too
[00:03:05 CET] <Daemon404> or randomly run it through an analogue pipeline before broadcast
[00:03:10 CET] <Daemon404> so theres dot crawl and rainbowign everywhere
[00:03:15 CET] <wm4> is there a reliable way to detect interlaced vs telecined yet
[00:03:30 CET] <nevcairiel> not really any good hands-off solutions
[00:03:31 CET] <Daemon404> yes. eyes.
[00:03:53 CET] <Daemon404> kierank, perhaps the broadcasters you work with are too competent :P
[00:04:02 CET] <Daemon404> compared to some
[00:06:52 CET] <jya> Daemon404: I was wrong there, seekable is [0, 55.936)
[00:07:02 CET] <llogan> cbsrobot: why this change? https://trac.ffmpeg.org/wiki/CompilationGuide/Centos?confirm_email=&email_confirm=&action=diff&version=43&old_version=42
[00:07:55 CET] <Daemon404> jya, oic
[00:08:07 CET] <Daemon404> it's that time of night when my brain starts going slow
[00:08:14 CET] <jya> but when seeking we ask to seek to the point, get the first keyframe prior that point (found at 0), to ensure proper A/V sync (this was mostly due to MSE with audio and video track not always fully aligned), so we seek audio. Then we loop decoding until we reach the seek time
[00:08:30 CET] <nevcairiel> llogan: our vlc hosts asked us to favor http cloning in our documentation to limit usage of the git daemon
[00:08:36 CET] <jya> we don't find a video frame at seek time, and so it stall
[00:09:10 CET] <llogan> nevcairiel: ok. it doesn't support --depth apparently, so i'll just remove that
[00:09:12 CET] <jya> (more accurately, we hit EOS on the video track) so seek is interrupted and we start playing from 0.
[00:09:59 CET] <Daemon404> i imagine this is probably not worth redesiging the architecture for in 2016.
[00:10:36 CET] <jya> we've had a bug for that for a while. (dailymotion lodged it)
[00:10:48 CET] <michaelni> llogan, someone reporting a security issue and i dont want to have open security issues in releases, so i have to make new releases
[00:10:55 CET] <jya> I have a pending solution which is to totally ignore frame duration
[00:11:05 CET] <jya> e.g. a frame is valid until a new frame starts
[00:11:09 CET] <Daemon404> jya, is there a bug id i can shove in out internal tracker
[00:11:11 CET] <llogan> michaelni: i see. just curious.
[00:11:11 CET] <Daemon404> for the player guys
[00:11:43 CET] Action: jya searching
[00:12:18 CET] <durandal_1707> michaelni: something similar to hls?
[00:12:38 CET] <jya> if we hit EOS when seeking on the video track, simply displaying that last frame and contiue seeking the audio would do easily
[00:13:19 CET] <Daemon404> right, this is what chrome does
[00:14:18 CET] <llogan> durandal_1707: wonder why russians didn't tell us instead of blogging (AFAIK).
[00:14:33 CET] <Daemon404> llogan, you must be new to infosec =p
[00:14:40 CET] <Daemon404> thats how they do it
[00:15:00 CET] <Daemon404> bonus points if they complain they didnt get money
[00:15:39 CET] <llogan> Daemon404: should i queue Yackety Sax again?
[00:16:16 CET] <Daemon404> i had to google what that was...
[00:16:21 CET] <michaelni> durandal_1707, out of array access from some fuzzer i would guess
[00:16:39 CET] <llogan> Daemon404: bonus points for a running shrimp on treadmill
[00:16:40 CET] <Daemon404> llogan, now i finally know the name of that song
[00:16:52 CET] <llogan> aka "Benny Hill Theme" i think
[00:17:00 CET] Action: jya googling Yackety Sax
[00:17:32 CET] <jya> ah ! lol
[00:18:05 CET] <rcombs> how much does PNS help in the AAC encoder?
[00:18:18 CET] <nevcairiel> its a decent improvement
[00:18:32 CET] <nevcairiel> although someone should poke atomnuker about all the PNS fate failures
[00:18:40 CET] <jya> Daemon404: we started fuzzing ffmpeg a little while back, all created bug is marked private and michaelni is CCed on it. So not hard to do the right thing
[00:19:07 CET] <Daemon404> jya, yeah i know... but you know how some of those infosec people are
[00:19:29 CET] <nevcairiel> I dislike the secrecy, it makes reviewing any changes and whatnot hard, all I see is "fixes mozilla bug 12314512313" and i cant even look up wtf that is
[00:19:31 CET] <Daemon404> although infosec people probably dont liek to be lumped in with them
[00:19:46 CET] <jya> this is giving me frights just thinking about stagefright again
[00:20:26 CET] <Daemon404> nevcairiel, probably wouldnt be hard to just have an ftp or something for devs
[00:20:34 CET] <Daemon404> the problem is not the secrity
[00:20:40 CET] <Daemon404> it's that most of them are under NDA from e.g. youtube
[00:20:43 CET] <Daemon404> because theyre user content
[00:21:08 CET] <kierank> jya: there is a security ML
[00:21:10 CET] <jya> I was so annoyed by that entire stagefright episode. I found the bug and fixed it in Jan 15 (in our copy), notified stagefright. Comes Jun 15, still not fixed, someone come very vocally with 0-day disclosure, and he got $5k grant money
[00:21:26 CET] <Daemon404> jya, sounds right
[00:21:37 CET] <Daemon404> i assume stagefright = the android team?
[00:21:42 CET] <jya> yes
[00:21:44 CET] <Daemon404> theyve been very bad about community interaction
[00:21:46 CET] <Daemon404> for years
[00:21:47 CET] <Daemon404> IMO
[00:22:04 CET] <nevcairiel> why do you think they go around announcing it wildly as 0-days, they want to make a name for themself
[00:22:05 CET] <jya> that stuff is so badly designed...
[00:22:16 CET] <nevcairiel> its not like anyone can stop them =p
[00:22:53 CET] <kierank> I need to restart h264 fuzzing
[00:23:11 CET] <durandal_170> why?
[00:23:18 CET] <Daemon404> to find bugs, presumably.
[00:23:47 CET] <kierank> Because I want to roll forward our ffmpeg
[00:24:12 CET] <jya> I think we've started to only fuzz ffvp9 right now. because we now ship it for all platforms. While ffmpeg/h264 is only used on linux, and the linux users is a tiny proportion of our users
[00:24:14 CET] <durandal_170> It take ages to complete
[00:25:06 CET] <jya> fuzzing is an art really :)
[00:25:28 CET] <kierank> I don't care much about the security aspects, more the crashing on air aspects
[00:27:17 CET] <jya> kierank: should be the other way round really.
[00:27:47 CET] <kierank> In the main we control our sources
[00:27:54 CET] <jya> crashing is better 
[00:28:30 CET] <nevcairiel> if you dont run untrusted media through your setup, you dont really care
[00:28:47 CET] <nevcairiel> but packet loss or whatever can always produce situations that could crash
[00:28:48 CET] <Daemon404> kierank, i demand you secretly add max headroom into OBE
[00:29:03 CET] <jya> nevcairiel: I wish this could ever be true for us :)
[00:29:25 CET] <kierank> jya: Am I right in saying you're in Aus?
[00:29:31 CET] <Daemon404> you think browsers get weird files?
[00:29:49 CET] Action: Daemon404 should show his collection
[00:30:08 CET] <nevcairiel> I've seen my share of crazy files as well
[00:30:12 CET] <jya> nevcairiel: is there more nvidia cards supports VP9 than the 965 (or was that 985) ?
[00:30:18 CET] <nevcairiel> 950  and 960
[00:30:26 CET] <nevcairiel> and probably the refreshed 750
[00:30:38 CET] <Daemon404> nevcairiel, and theyre always paired with crazy content too.
[00:30:40 CET] <nevcairiel> not sure if they renamed it
[00:31:12 CET] <jya> nevcairiel: the dxva with nvidia, do they use the same ID as intel to report that they support vp9 ?
[00:31:25 CET] <nevcairiel> they use the one specified by microsoft
[00:31:28 CET] <nevcairiel> which intel also supportrs
[00:31:31 CET] <nevcairiel> so i guess?
[00:31:31 CET] <jya> kierank: I'm in Melbourne yes
[00:32:47 CET] <jya> nevcairiel: hmmmm I need to try it... can I ask you a favour ? do you have a working setup with this video card?
[00:32:51 CET] <nevcairiel> yes
[00:33:03 CET] <nevcairiel> although its not my primary card, that can throw off a bunch of applications
[00:34:12 CET] <jya> can you get Firefox Developer Edition (45) and set media.webm.intel_decoder.enabled to true and media.mediasource.webm.enabled to true
[00:34:18 CET] <jya> (you do that in about:config)
[00:34:31 CET] <jya> and let me know if it works ? :)
[00:35:58 CET] <nevcairiel> now i need a webm video i guess
[00:36:03 CET] <jya> then you go youtube , they serve vp9 / webm
[00:36:09 CET] <jya> if MSE webm is supported
[00:36:26 CET] <jya> you can check with the "stats for nerds" (right click on the video)
[00:37:30 CET] <nevcairiel> it plays vp9, but i couldnt tell you  if it uses the intel decoder
[00:38:13 CET] <jya> CPU usage maybe?
[00:38:35 CET] <nevcairiel> looks too high for gpu decoding
[00:39:35 CET] <jya> I put something in Firefox Nightly (it will be in 46) that let you know. you need to install this extension https://github.com/doublec/aboutmedia/raw/master/aboutmedia.xpi
[00:39:37 CET] <nevcairiel> the official microsoft vp9 dxva specification is only a couple months old, intel had their proprietary interface long before that
[00:39:49 CET] <nevcairiel> so it might just be something else
[00:39:52 CET] <jya> if you go to the about:media page, it will say which decoder it's using (WMF or ffvp9)
[00:40:04 CET] <jya> nevcairiel: ah that must not be it then
[00:40:13 CET] <RiCON> Daemon404: http://j.fsbn.eu/Yj1z.txt probably caused by 0e6c8532?
[00:40:15 CET] <jya> our stuff was really based on intel api
[00:40:56 CET] <atomnuker> nevcairiel: if you want to help edit CMP_TARGET of the fate-aac-pns-encode to some crazy value, run fate-aac and tell me what PSNR you get when fate fails
[00:41:15 CET] <jya> se we look for intel CLSID_WebmMfVp9Dec 
[00:41:26 CET] <nevcairiel> atomnuker: unfortunately it doesnt fail here, I only see it on a variety of fate systems
[00:41:37 CET] <atomnuker> no, I want it to fail
[00:41:46 CET] <nevcairiel> oh
[00:41:48 CET] <jya> https://dxr.mozilla.org/mozilla-central/source/dom/media/platforms/wmf/WMFVideoMFTManager.cpp#62
[00:41:48 CET] <atomnuker> so set the target to something that would make it fail
[00:41:50 CET] <nevcairiel> give me a sec
[00:42:53 CET] <jya> nevcairiel: have they only defined VP9 ? (they said they were going to support vp9, I wonder if they're doing VP8 too)
[00:43:07 CET] <nevcairiel> jya: vp8 too, but i know of no hardware that supports that spec yet
[00:43:17 CET] <nevcairiel> once it does, i'll add it to ffmpeg as well
[00:43:58 CET] <Daemon404> RiCON, yes looks like koda typo'd that
[00:44:04 CET] <Daemon404> it seems to be a bug in libav too
[00:44:14 CET] <jya> nevcairiel: where is it in ffmpeg? want to see which CLSID/GUID you use
[00:44:21 CET] Action: Daemon404 wonders if every damn commit in libav is buggy lately
[00:44:39 CET] <cone-559> ffmpeg 03Paul B Mahol 07release/2.8:40ebeee3fc35: avformat/brstm: fix overflow
[00:44:40 CET] <cone-559> ffmpeg 03Paul B Mahol 07release/2.8:7b0fb4fdf796: avformat/ipmovie: put video decoding_map_size into packet and use it in decoder
[00:44:41 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.8:667a23a03249: ffmdec: reset packet_end in case of failure
[00:44:42 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.8:e3d7796336c8: vorbisdec: reject channel mapping with less than two channels
[00:44:43 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.8:6ffaf40c02d3: vorbisdec: reject rangebits 0 with non-0 partitions
[00:44:44 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.8:94b9e7caaea8: brstm: make sure an ADPC chunk was read for adpcm_thp
[00:44:45 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.8:247bb203e4e2: brstm: also allocate b->table in read_packet
[00:44:46 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.8:cf99f0dd0fa2: brstm: fix missing closing brace
[00:44:47 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.8:1272b88d0457: dca: fix misaligned access in avpriv_dca_convert_bitstream
[00:44:48 CET] <cone-559> ffmpeg 03Hendrik Leppkes 07release/2.8:2cd41c5d5230: Merge commit '8375dc1dd101d51baa430f34c0bcadfa37873896'
[00:44:49 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.8:d7fbd0366005: asfdec_o: only set asf_pkt->data_size after sanity checks
[00:44:50 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.8:407ab167c07c: asfdec_o: reject size > INT64_MAX in asf_read_unknown
[00:44:50 CET] <Daemon404> RiCON, s/q->extco2.b_strategy/q->b_strategy/ please
[00:44:51 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.8:e188c267c871: asfdec_o: check avio_skip in asf_read_simple_index
[00:44:52 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.8:782257ba66e0: asfdec_o: prevent overflow causing seekback
[00:44:53 CET] <nevcairiel> jya: the guid is in the specification, but http://git.videolan.org/?p=ffmpeg.git;a=blob;f=ffmpeg_dxva2.c;h=905bf8907cf45786bb177c98808f849502de4520;hb=HEAD#l56
[00:44:53 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.8:4679e543880a: asfdec_o: make sure packet_size is non-zero before seeking
[00:44:54 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.8:93559adfbfd4: asfdec_o: break if EOF is reached after asf_read_packet_header
[00:44:55 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.8:d640bc75459d: asfdec_o: check for too small size in asf_read_unknown
[00:45:07 CET] <nevcairiel> Daemon404: i told you, koda refactoring needs special attention
[00:45:36 CET] <Daemon404> nevcairiel, all the other bugs today were luca bugs though ;)
[00:46:07 CET] <nevcairiel> the last patchset moving some global option into codec privates was riddled with bugs
[00:46:19 CET] <Daemon404> i guess
[00:46:21 CET] <nevcairiel> decoders that didnt have one before were suddenly missing an AVClass
[00:46:29 CET] <Daemon404> if (externallib) apply_extra_extra_extra_attention()
[00:46:37 CET] <Daemon404> since it probably wasnt even tested
[00:46:41 CET] <nevcairiel> parameters were mapped wrong
[00:46:55 CET] <nevcairiel> options didnt work because they conflicted with global opitons
[00:46:56 CET] <Daemon404> yes i saw that, there is a fix from martin
[00:46:59 CET] <nevcairiel> and fun things like that
[00:47:08 CET] <Daemon404> RiCON, does this fix it for you?
[00:47:17 CET] <jya> nevcairiel: we go through the WMF, not dxva directly. so for h264 we use constants: e.g. MFVideoFormat_H264 / CLSID_CMSH264DecoderMFT
[00:47:29 CET] <jya> don't know how that translate to dxva
[00:47:41 CET] <nevcairiel> yeah well thats the MFT decoders, the GUIDs we use are for the hardware devices
[00:48:18 CET] <nevcairiel> not sure if MS provides a MFT for vp9
[00:48:25 CET] <nevcairiel> maybe they do, they wanted to add support to edge
[00:48:32 CET] <nevcairiel> but it would only be available on 10 then of course
[00:50:10 CET] <kierank> nevcairiel: how does decoder security work on hardware decoders?
[00:50:26 CET] <jya> i wonder what ccontainer microsoft will use for vp9
[00:50:33 CET] <Daemon404> probably webm
[00:50:35 CET] <RiCON> Daemon404: "this"?
[00:50:35 CET] <jya> they only mentioned supporting vp9, they never talked about webm
[00:50:38 CET] <Daemon404> windows 10 has a matroska demuxer
[00:50:43 CET] <Daemon404> -            if (q->extco2.b_strategy >= 0)
[00:50:43 CET] <Daemon404> +            if (q->b_strategy >= 0)
[00:50:46 CET] <Daemon404> ^ RiCON 
[00:50:46 CET] <jya> we're betting on vp9 in mp4
[00:51:05 CET] <Daemon404> jya, brb killing self
[00:51:20 CET] <kierank> what's wrong with vp9 in mp4?
[00:51:39 CET] <Daemon404> same thing thats will be wrong with vp9 in anything
[00:51:44 CET] <Daemon404> no ratified or real spec anywhere
[00:52:01 CET] <kierank> there is a thing on github
[00:52:03 CET] <kierank> from netflix
[00:52:05 CET] <nevcairiel> i think i saw someone defining a spec for vp9 in mp4
[00:52:07 CET] <nevcairiel> yeah that
[00:52:11 CET] <Daemon404> yes
[00:52:12 CET] <Daemon404> netflix
[00:52:24 CET] <kierank> can I make fuzzed files that crash hw decoders?
[00:52:34 CET] <Daemon404> you can probably make legit files that crash hw decoders
[00:52:46 CET] <atomnuker> nevcairiel: ran fate yet?
[00:52:53 CET] <kierank> how much practical damage could I cause
[00:53:02 CET] <Daemon404> kierank, lockups / bsod
[00:53:09 CET] <Daemon404> maybe not bsod
[00:53:16 CET] <nevcairiel> depends
[00:53:21 CET] <Daemon404> are windows drivers still kenel space
[00:53:22 CET] <Daemon404> kernel
[00:53:23 CET] <nevcairiel> most will probably just crash the driver
[00:53:34 CET] <Daemon404> yeah theyre userpspace now arent they
[00:53:39 CET] <kierank> :(
[00:53:45 CET] <nevcairiel> atomnuker: stddev:  616.71 PSNR: 40.53 MAXDIFF: 9768 bytes:  1675800/  1679360
[00:54:45 CET] <Daemon404> jya, will you be attending FOSDEM btw?
[00:54:47 CET] <atomnuker> then the fate test is outdated, I get the same values, will push an update
[00:55:38 CET] <TD-Linux> jya, their initial press release said WebM/VP9
[00:55:59 CET] <nevcairiel> atomnuker: the failing tests on bsd systems have things like stddev:  568.59 PSNR: 41.23 MAXDIFF: 7868 bytes:  1675800/  1679360
[00:56:00 CET] <nevcairiel> stddev: |568.59 - 662| >= 72
[00:56:13 CET] <atomnuker> yeah, I know
[00:56:28 CET] <nevcairiel> wonder why its so much different there
[00:57:47 CET] <jya> TD-Linux: you should tell that to k17e then
[00:58:30 CET] <atomnuker> miscompilation? weird float discrepancies?
[00:59:03 CET] <cone-559> ffmpeg 03Rostislav Pehlivanov 07master:925f145ace2e: FATE: update AAC encoder PNS test target
[00:59:04 CET] <nevcairiel> kierank: would also be careful what you fuzz, only the slice data is passed 1:1 to the hardware, the slice headers and all other bitstream parameters (sps etc) are parsed by ffmpeg, so if those turn out bad, ffmpeg might already block it all :D
[00:59:43 CET] <TD-Linux> jya, I think he knows based on prior discussion in #media?
[00:59:44 CET] <kierank> I had a lot of obscure interlaced bugs that I found
[01:00:13 CET] <nevcairiel> atomnuker: speaking of the target, i always wondered, is lower or higher cmp_target "better"? :)
[01:00:14 CET] <jya> from discussion with him, he appears convinced that MS hasn't made an announcement about webm, just VP9
[01:00:34 CET] <Daemon404> technically they alreadt support webm
[01:00:35 CET] <Daemon404> via mkv
[01:00:49 CET] <atomnuker> nevcairiel: stddev -> standard deviation -> lower ~= better
[01:01:25 CET] <nevcairiel> jya: https://dev.windows.com/en-us/microsoft-edge/platform/status/webmcontainer?filter=f3f0000bf&search=webm .. if worth anything, it says "in development"
[01:02:00 CET] <Daemon404> just 10 more years until edge has a reasonable share
[01:02:19 CET] <nevcairiel> its a decent basis for a browser though, just needs some more UX work
[01:03:24 CET] <Daemon404> at least as far as MSE is concerned, IE11 and Edge have been pretty well the most spec compliant
[01:03:27 CET] <Daemon404> (unlike chrome)
[01:04:21 CET] <jya> Daemon404: edge certainly, IE11 not from my finding
[01:04:42 CET] <jya> I take offence though, because I think FF since 42 has the most compliant implementation
[01:05:11 CET] <jya> and in 44, other than text track, it's all *exactly* per spec
[01:06:30 CET] <jya> edge implementation of sequence mode is bad. But I don't know anyone doing it properly (except FF of course) nor anyone using it :)
[01:06:44 CET] <jya> (I wrote the MSE stack found in 42 and later)
[01:06:55 CET] <Daemon404> jya, for a long time, IE11 was the only one to support MSE fragments that dont start with keyframes
[01:06:58 CET] <Daemon404> (this is allowed)
[01:07:03 CET] <Daemon404> chrome still doesnt
[01:07:08 CET] <Daemon404> havent tested ff
[01:07:16 CET] <Daemon404> since it lacked mse entirely when i originally tested
[01:07:58 CET] <jya> well, mse in FF has been there a long time, was just only allowed for youtube
[01:08:24 CET] <Daemon404> i know
[01:08:29 CET] <RiCON> Daemon404: sorry for the delay, had run make clean
[01:08:31 CET] <RiCON> seems to fix it
[01:08:36 CET] <Daemon404> RiCON, thought so
[01:08:45 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:02bd02da5f90: qsvenc: Fix b_strategy typo
[01:08:56 CET] <jya> fragments not starting with keyframes are fine (obviously all frames are dropped until the first keyframe)
[01:09:38 CET] <jya> I can't think of a day where we don't get a report that FF MSE is broken: look it plays in Chrome. and it's totally rubbish content
[01:09:53 CET] <Daemon404> jya, in this case ff will play it then
[01:09:58 CET] <Daemon404> and chrome will just refuse
[01:09:58 CET] <jya> last time, they had prefixed every fragment with ftyp box
[01:10:33 CET] <jya> Daemon404: that's sounds weird, we've had stuff where none of the frames in the container were marked keyframes
[01:10:47 CET] <Daemon404> it's a known bug in chrome
[01:10:49 CET] <jya> obbviously we just ended with an empty source buffer, but chrome played them nicely
[01:10:50 CET] <Daemon404> they fixed it today-ish
[01:10:53 CET] <Daemon404> but it broke netflix
[01:10:55 CET] <Daemon404> so its reverted now.
[01:11:23 CET] <Daemon404> jya, you will love what GPAC does
[01:11:32 CET] <Daemon404> they make every frame a separate fragment
[01:11:34 CET] <Daemon404> all marked as keyframes
[01:11:37 CET] <Daemon404> even if they arent
[01:11:44 CET] <Daemon404> for 'compatability'
[01:12:00 CET] <jya> what gives me the biggest hassle is that the webref tests are based on chrome's own internal test. they append fragments that starts at 0.095s and their test assume that the buffered range will start at 0
[01:12:52 CET] <jya> they shift every timestamp to make it start at 0, but they don't shift all tracks accordingly. so if you have a video where the timestamp start at 0..095 and audio at 0, you have A/V sync off by that much
[01:13:13 CET] <Daemon404> where does that timestamp come from?
[01:13:19 CET] <jya> the container
[01:13:30 CET] <Daemon404> yes but before or after edit list application?
[01:13:34 CET] <Daemon404> baseMediaTime must start at 0
[01:13:42 CET] <Daemon404> its required
[01:14:01 CET] <jya> I've seen those GPAC encoding, we don't handle them nicely, because we process things by block of frames
[01:14:12 CET] <kierank> lol gpac
[01:14:15 CET] <jya> so we end up with block of 1 frame, that's a lot of reset/start
[01:14:24 CET] <Daemon404> there's no possible wya to handle it well
[01:14:26 CET] <jya> Daemon404: that's after edts
[01:14:30 CET] <Daemon404> jya, ok
[01:14:45 CET] <jya> let me find you an example. (I lodged a bug with w3c)
[01:16:11 CET] <Daemon404> i should really settle down and get of irc soon
[01:16:15 CET] <Daemon404> or i wont sleep
[01:16:18 CET] <Daemon404> off*
[01:16:31 CET] Action: kierank writes FOSDEM presentation
[01:17:07 CET] <Daemon404> 20 slides of: WHATS THE DURATION OF THE LAST FRAME, ANTON?!
[01:17:46 CET] <kierank> he wasn't there for that
[01:18:15 CET] <Daemon404> that makes me sad
[01:22:44 CET] <jya> Daemon404: https://github.com/w3c/web-platform-tests/tree/master/media-source 
[01:22:46 CET] <jya> https://github.com/w3c/web-platform-tests/blob/master/media-source/mp4/test-v-128k-320x240-24fps-8kfr.mp4 is one
[01:22:59 CET] <jya> starts at 0.083333
[01:24:19 CET] <jya> this test: https://raw.githubusercontent.com/w3c/web-platform-tests/master/media-source/mediasource-buffered.html expects data added to be between [0, 2.023]
[01:24:30 CET] <Daemon404> github dead
[01:24:49 CET] <Daemon404> everything is 503
[01:25:35 CET] <Daemon404> their status page is dead
[01:25:37 CET] <Daemon404> nice.
[01:25:45 CET] <Compn> why keep using mp4 stupid non streamable format :\
[01:26:34 CET] <Compn> damn apple mp4 pushers
[01:27:14 CET] <TD-Linux> well not quite. they pushed HLS with MPEG-TS (which would actually be worse due to royalties)
[01:27:53 CET] <Compn> yes, apple is stupid too
[01:29:22 CET] <TD-Linux> we've had a free streamable container since 2001. it's called ogg :^)
[01:29:53 CET] <Compn> you shut your mouth
[01:30:24 CET] <kierank> meh most of the mpegts patents don't apply
[01:30:36 CET] <kierank> they are for things like PCR which you guys don't even use
[01:30:44 CET] <kierank> or other obscure stuff
[01:34:30 CET] <jya> kierank: you'll pay the legal fees to argue that point ?
[01:34:52 CET] <kierank> well don't send pcr and you avoid the patent on pcr
[01:35:12 CET] <kierank> they stopped taking our money now in the uk
[01:35:15 CET] <kierank> all the uk patents expired
[01:35:41 CET] <jya> our solution to support HLS has been to help with stuff like hls.js , and HLS -> MSE conversion
[01:35:43 CET] <jya> works well
[01:36:20 CET] <jya> mpeg-ts can work with MSE, but we don't support it. My manager wants to limit the amount of container we support
[01:36:27 CET] <jya> he even wants to drop ogg
[01:44:51 CET] <TD-Linux> kierank, yeah it's much better now, though people wanted MSE a lot sooner than 2016.
[01:48:22 CET] <Daemon404> jya, i looked at that sample
[01:48:54 CET] <jya> and?
[01:49:22 CET] <Daemon404> im not surprised
[01:49:40 CET] <Daemon404> baseMediaTime is 0, but the sidx's earliest_presentation_time is 1024
[01:49:45 CET] <Daemon404> chrome doesnt even read sidx boxes
[01:49:48 CET] <Daemon404> last i checked.
[01:50:04 CET] <jya> sidx are to be ignored per spec
[01:50:36 CET] <jya> "Valid top-level boxes such as pdin, free, and sidx are allowed to appear before the moov box. These boxes must be accepted and ignored by the user agent and are not considered part of the initialization segment in this specification."
[01:51:02 CET] <Daemon404> i dont see any elst at all in that file
[01:51:20 CET] <jya> not surprising, stagefright doesn't support them properly
[01:51:33 CET] <Daemon404> im wondering where the nonzero start time comes from
[01:51:44 CET] <jya> in MSE, the specs are clearly based on the start and end time of each frames found in the segment
[01:52:17 CET] <Daemon404> cts is 1024 i suppose
[01:52:21 CET] <jya> ffprobe gives me the same timestamps as what our demuxer give
[01:52:35 CET] <Daemon404> yes the cts is 1024
[01:52:41 CET] <Daemon404> i forgot basemediatime is based off dts
[01:52:42 CET] <Daemon404> for a sec
[01:53:42 CET] <Daemon404> looks correct
[01:55:57 CET] <Daemon404> i think this technically should have an edts to account for non-zero cts for the first sample
[01:56:01 CET] <Daemon404> but i doubt thats required.
[01:56:13 CET] <Daemon404> oh well. 1 am. i should sleep.
[02:03:49 CET] <jya> nevcairiel: unless there's a newer version of it, VP9 doesn't appear to be defined for MFT https://msdn.microsoft.com/en-us/library/windows/desktop/aa370819%28v=vs.85%29.aspx
[02:25:46 CET] <cone-559> ffmpeg 03Paul B Mahol 07release/2.7:0c03d860f49a: avformat/ipmovie: put video decoding_map_size into packet and use it in decoder
[02:25:47 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.7:a21ec4e1ee54: ffmdec: reset packet_end in case of failure
[02:25:48 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.7:00a0c0fd75f2: vorbisdec: reject channel mapping with less than two channels
[02:25:49 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.7:6fe77207ed3b: vorbisdec: reject rangebits 0 with non-0 partitions
[02:25:50 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.7:496c02a065bd: brstm: make sure an ADPC chunk was read for adpcm_thp
[02:25:51 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.7:269a522aeccf: brstm: also allocate b->table in read_packet
[02:25:52 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.7:f106232e9405: brstm: fix missing closing brace
[02:25:53 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.7:41157f6bfff3: dca: fix misaligned access in avpriv_dca_convert_bitstream
[02:26:28 CET] <cone-559> ffmpeg 03Paul B Mahol 07release/2.6:eadf932867fc: avformat/ipmovie: put video decoding_map_size into packet and use it in decoder
[02:26:29 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.6:eaba40842183: ffmdec: reset packet_end in case of failure
[02:26:30 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.6:9dd768dc1e7e: vorbisdec: reject channel mapping with less than two channels
[02:26:31 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.6:b244e67f9cc6: vorbisdec: reject rangebits 0 with non-0 partitions
[02:26:32 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.6:20d4c087ed8c: brstm: make sure an ADPC chunk was read for adpcm_thp
[02:26:32 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.6:95e52303da7e: brstm: also allocate b->table in read_packet
[02:26:34 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.6:e577e712a8a2: brstm: fix missing closing brace
[02:26:35 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.6:1d8a6a46a303: dca: fix misaligned access in avpriv_dca_convert_bitstream
[02:27:26 CET] <cone-559> ffmpeg 03Clément BSsch 07release/2.5:1a65265131cd: avcodec/samidec: make sure to properly restore parsing context after a tag
[02:27:27 CET] <cone-559> ffmpeg 03Paul B Mahol 07release/2.5:bf446993145a: avformat/ipmovie: put video decoding_map_size into packet and use it in decoder
[02:27:28 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.5:3b535bbf8857: ffmdec: reset packet_end in case of failure
[02:27:29 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.5:b6fb6ccda40a: vorbisdec: reject channel mapping with less than two channels
[02:27:30 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.5:641a01015727: vorbisdec: reject rangebits 0 with non-0 partitions
[02:27:31 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.5:a90a7594a81e: brstm: make sure an ADPC chunk was read for adpcm_thp
[02:27:32 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.5:cdedd71a7e13: brstm: also allocate b->table in read_packet
[02:27:33 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.5:f2fd5b9eb267: brstm: fix missing closing brace
[02:27:34 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.5:873a0dfa26df: dca: fix misaligned access in avpriv_dca_convert_bitstream
[02:28:10 CET] <cone-559> ffmpeg 03Clément BSsch 07release/2.4:2b2943e1ef80: avcodec/samidec: make sure to properly restore parsing context after a tag
[02:28:11 CET] <cone-559> ffmpeg 03Paul B Mahol 07release/2.4:a2667c60ecc3: avformat/ipmovie: put video decoding_map_size into packet and use it in decoder
[02:28:12 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.4:46fcc2ba55df: mjpegdec: extend check for incompatible values of s->rgb and s->ls
[02:28:13 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.4:33ad09205a9f: ffmdec: reset packet_end in case of failure
[02:28:14 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.4:7b6f04850610: vorbisdec: reject channel mapping with less than two channels
[02:28:15 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.4:bc4332b3fc49: vorbisdec: reject rangebits 0 with non-0 partitions
[02:28:16 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.4:d5b1ea8c7aba: brstm: make sure an ADPC chunk was read for adpcm_thp
[02:28:17 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.4:ab13ba2ae832: brstm: also allocate b->table in read_packet
[02:28:18 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.4:368a1803ff84: brstm: fix missing closing brace
[02:28:19 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.4:859a348e44d7: dca: fix misaligned access in avpriv_dca_convert_bitstream
[02:47:45 CET] <jya> Daemon404: I've created https://bugzilla.mozilla.org/show_bug.cgi?id=1243608, I'l work on it
[03:07:56 CET] <llogan> that page doesn't render for me correctly in firefox
[03:08:35 CET] <llogan> even firefox hates bugzilla
[04:15:55 CET] <cone-559> ffmpeg 03Michael Niedermayer 07master:e0b187e7dada: avcodec/h264: Fix memleak in case of ff_h264_decode_extradata() failure
[04:42:41 CET] <Timothy_Gu> Daemon404, wm4: fyi the numbers in that Chinese aren't characters. they are the ID of a IM service developed by tencent (one of the biggest chinese computer companies)
[04:43:02 CET] <Timothy_Gu> as to how one can remember it, i have no idea
[04:43:22 CET] <Timothy_Gu> zjh is the initials of the romanization of that guy's name
[05:19:09 CET] <rcombs> Timothy_Gu: often sequences of digits pronounced individually in Chinese (or Japanese) sound like a word or phrase
[05:19:18 CET] <rcombs> which can make for easy mnemonics sometimes
[05:19:37 CET] <Timothy_Gu> rcombs: sometimes I guess
[05:19:51 CET] <Timothy_Gu> but for that specific case it's randomly (or sequentially?) generated
[05:20:26 CET] Action: rcombs shrugs
[05:20:38 CET] <rcombs> maybe chunking, like how you remember phone numbers
[05:21:58 CET] <Timothy_Gu> meh. but I guess when you use the number a lot you remember it (as with credit card, etc.)
[08:37:39 CET] <wm4> nevcairiel: daily nagging when you will push your dxva hevc main10 patch
[09:36:41 CET] <cone-231> ffmpeg 03Matthieu Bouron 07master:27f1ea5097da: lavc/mjpegdec: use ptrdiff_t instead of ssize_t
[10:37:44 CET] <durandal_170> can I get review for dvaudio parser, its trivial
[10:38:12 CET] <durandal_170> its needed to set packet durations
[13:08:10 CET] <cone-231> ffmpeg 03Paul B Mahol 07master:2edd47582b4d: avcodec: add dvaudio parser
[13:24:26 CET] <superware> I'm running "ffplay.exe udp://224.0.18.0:40003" with the ethernet cable disconnected (Windows 7), but when I connect the cable to the NIC the video doesn't play. It plays only if I execute ffplay after the cable is already connected, any ideas?
[13:26:27 CET] <Compn> superware : maybe there are no retries? whats it do just sit there? maybe windows throws it an error no_addy_found hmm
[13:28:38 CET] <superware> Compn: I've also tried ffmpeg libav by retrying avformat_open_input every 20 seconds, but it starts playing only once I restart the process.
[13:29:31 CET] <superware> it seems that if the process was launched when the interface was "down" then it will not be able to receive the multicast even after the interface it up... sounds possible?
[13:36:44 CET] <Compn> superware : try ffplay -timeout 400 ?
[13:36:56 CET] <Compn> http://ffmpeg.org/pipermail/ffmpeg-devel/2012-August/130236.html
[13:36:59 CET] <Compn> might fix things...
[13:40:17 CET] <superware> shouldn't avformat_open_input handle that? I'm trying it every 20 seconds
[13:40:44 CET] <Compn> udp has no timeout by default? maybe ?
[13:40:46 CET] <superware> the only thing that runs once is avformat_network_init
[13:40:49 CET] <Compn> i'm not sure, wait for someone that knows..
[13:41:15 CET] <Compn> did you check what is returned by network_init ?
[13:42:04 CET] <superware> when there's no active interface? no...
[13:42:32 CET] <superware> but on the other hand the wireless interface is active...
[13:45:28 CET] <Compn> you're at the mercy of windows network switching then. :P
[13:45:49 CET] <Compn> win7 is pretty outdated now :P
[13:45:59 CET] <superware> but why is this related to the process itself?
[13:46:59 CET] <Compn> try disable the network interface and see if it works over the wireless connection
[13:47:06 CET] <Compn> instead of disconnecting the network interface
[13:47:31 CET] <Compn> er disable the network adapter for the unplugged cable that is
[13:48:55 CET] <Compn> i'm curious if there will be a difference
[13:49:01 CET] <Compn> i think there will be
[13:49:28 CET] <superware> the wireless is meaningless to what I see with the multicast video
[14:52:08 CET] <Daemon404> jya, quite a lot of stuff happened on that bug whilst i slept
[14:53:05 CET] <jya> Daemon404: my recollection of things was entirely incorrect. What I thought about was only the case for MSE (where indeed buffered range and seekable are per frame demuxed, regardless of what the metadata contain
[14:53:25 CET] <Daemon404> that explains thingd ;P
[14:53:28 CET] <Daemon404> things, even
[14:54:17 CET] <jya> those progressive mp4 would have worked in Firefox 40 I'm guessing, it utlitmately a regression due to some work around put in place shit video encoding done by one of our device
[14:54:40 CET] <jya> but while looking into it, I guess I got overzealous
[14:55:31 CET] <Daemon404> said every engineer ever
[14:55:38 CET] <Daemon404> ;P
[14:55:44 CET] <jya> fixing the seeking issue was very straight forward (I reverted the change).. the following changes are about speeding up the seek. We always used to seek the audio to whatever video was seeked to
[14:56:11 CET] <Daemon404> as in packet location or timestamp?
[14:56:56 CET] <jya> so if you were seeking at 1 minute, it would have seeked the video at 0s (pts) and then seek audio to 0, then decode every single audio frame until it reached 1 minute and drop them if it was prior the seek target)
[14:57:05 CET] <Daemon404> ah.
[14:57:16 CET] <jya> so seek were particularly slow in that video
[14:57:32 CET] <jya> the other good news is now I'm an expert on Lupus
[14:57:56 CET] <Daemon404> ha.
[14:58:38 CET] <jya> i don't know if that change will be approved for uplifting... that it's a regression helps. release management is awlays very keen to fix regression.
[14:59:02 CET] <jya> that it had regressed so long ago will put it on the low priority list though
[14:59:23 CET] <Daemon404> also it's not MSE
[14:59:27 CET] <Daemon404> so not Hip & Cool 2016
[14:59:59 CET] <jya> one way to put it on top of the queue is find me a video like this on Youtube :)
[15:00:22 CET] <nevcairiel> youtube probably encodes carefully enough to not produce those
[15:00:23 CET] <Daemon404> that makes me sad
[15:00:25 CET] <jya> what do you guys do currently for those videos? do you serve FF flash?
[15:00:41 CET] <Daemon404> like 90% of bugs/problems we find are results of "well it works for youtube"
[15:00:51 CET] <Daemon404> which is annoying as hell
[15:00:53 CET] <jya> Daemon404: unfortunately, youtube is so prevalent today, that it's kind of the only thing that matters :(
[15:01:08 CET] <Daemon404> jya, its more annoying when it's chrome
[15:01:13 CET] <jya> don't worry, I hear that every day with "it works with chrome"
[15:01:17 CET] <Daemon404> because youtube is their "customer"
[15:01:22 CET] <Daemon404> same for vp9
[15:01:36 CET] <Daemon404> thats why vp9 has utter shit ratecontrol
[15:01:40 CET] <Daemon404> because youtube rolls their own
[15:01:52 CET] <Daemon404> /ran
[15:01:53 CET] <Daemon404> t
[15:02:04 CET] <jya> dailymotion now serves MSE exclusively on Firefox (they used http live streamer, and use their hls.js interface)
[15:02:17 CET] <jya> they used to have heaps of those type of video
[15:02:41 CET] <BtbN> hls.js works even better than dash.js now... it's sad
[15:02:44 CET] <Daemon404> we have to keep progressive around for some crappy plastic devices to consume
[15:02:53 CET] <Daemon404> but firefox should be all mse soon.
[15:03:24 CET] <Daemon404> BtbN, dash.js is utter awfulness
[15:03:27 CET] <Daemon404> so it's unsurprising
[15:03:34 CET] <jya> BtbN: main reason for dailymotion to use hls.js (which they kindly made open), is so that they only have to encode once. they used the lowest common denominator
[15:03:50 CET] <BtbN> Twitch is also rolling their own hls.js like thing
[15:03:52 CET] <Daemon404> jya, we only encode once too =p
[15:04:04 CET] <Daemon404> it's segmented/cached at cdn level
[15:04:07 CET] <BtbN> Twitch is not usualy encoding at all though
[15:04:17 CET] <jya> never found dash.js to be that bad.. it's the content that is used with that is often crap
[15:04:33 CET] <nevcairiel> BtbN: huh, twitch seems to encode everything to various quality levels
[15:04:35 CET] <BtbN> They were just too... lazy? to switch their CDN from HLS to DASH
[15:04:43 CET] <BtbN> Only for Partnered streams
[15:04:56 CET] <BtbN> And the Source-Quality level is still just a direct passthrough
[15:06:13 CET] <jya> hls.js has just fixed something that caused issue on mac with some streams (noticeable if you watch nasa tv like all respectable geek should)
[15:06:47 CET] <Daemon404> ive never used hls.js, but ive written my own
[15:06:48 CET] <jya> that's one problem solved that still puzzles me. it decoded just fine with ffmpeg, but Apple VT used to out half green content
[15:07:01 CET] <Daemon404> did the bother to handle hls streams that dont have keyframes at seg boundaries
[15:07:05 CET] <Daemon404> liek akamai produces
[15:07:16 CET] <Daemon404> because while you can transmux those as-is, and it is valid mse
[15:07:18 CET] <BtbN> works fine in hls.js
[15:07:19 CET] <Daemon404> chrome wont play them.
[15:07:39 CET] <Daemon404> BtbN, it must be doing clever things then
[15:07:45 CET] <BtbN> Twitch does that a lot, and it just works for me.
[15:07:49 CET] <Daemon404> like joining bits of segs during nal parsing
[15:07:58 CET] <jya> Daemon404: for chrome defense. Just 1.5 years ago, segments *had to* start with a keyframe in the MSE spec
[15:08:08 CET] <jya> it was only relaxed to facilitate conversion from HLS
[15:08:32 CET] <Daemon404> i know it changed
[15:08:40 CET] <BtbN> You can stream with a 30 second gop length, and it will still make 4 second segments out of it
[15:08:40 CET] <BtbN> joining the stream might take a while, but it will eventualy play it
[15:08:44 CET] <Daemon404> im just disgruntled at chrome :P
[15:08:58 CET] <Daemon404> it took them ike 2 years and months of convincing to get them to fix their ycbcr to rgb conversion
[15:08:59 CET] <BtbN> I tested that with chrome using hls.js and the official twitch HTML5 player. Both work
[15:10:24 CET] <jya> twitch has finally moved to 100% html5? wasn't it like just flash with a html5 overlay not long ago?
[15:10:36 CET] <Daemon404> last time i opened twitch in firefox
[15:10:38 CET] <Daemon404> it was just a black screen
[15:10:39 CET] <BtbN> it still hasn't(for good reasons, the HTML5 player is still wonky)
[15:10:41 CET] <Daemon404> wouldnt play at all
[15:10:46 CET] <BtbN> But there is a HTML5 player if you know the URL for it
[15:11:08 CET] <Daemon404> oic
[15:11:08 CET] Action: jya blames flash for black screen
[15:11:28 CET] <BtbN> Also, I wrote a userscript that replaces the player with a plain hls.js video element
[15:11:45 CET] <jya> the flash player is actually a HLS one ?
[15:11:55 CET] <Daemon404> its fairly common
[15:11:56 CET] <BtbN> Yes, the use exclusively HLS
[15:15:17 CET] <BtbN> http://player.twitch.tv/?html5&channel=rocketbeanstv is their HTML5 player
[15:17:22 CET] <jya> Daemon404: had any issue with FF's MSE stack?
[15:17:58 CET] <jya> BtbN: MSE, nice..
[15:18:00 CET] <Daemon404> not yet, i think
[15:18:11 CET] <Daemon404> it has the least testing though
[15:18:18 CET] <Daemon404> since stable only recently got MSE for non-youtube
[15:18:26 CET] <BtbN> They finaly seem to have it working propperly
[15:18:29 CET] <BtbN> only took them like 5 years
[15:18:46 CET] <Daemon404> BtbN, they = jya
[15:19:01 CET] <Daemon404> or do you mean twicth
[15:19:10 CET] <jya> I think he means twitch :)
[15:19:14 CET] <Daemon404> ah
[15:19:23 CET] <BtbN> The last time I tested it it barfed on itself within minutes
[15:19:44 CET] <BtbN> and while it played, it had several seconds of audio desync
[15:20:22 CET] <jya> we had issues with the dash.js and live stream, we didn't fire canplaythrough which they were waiting on to start playing. I don't think it made it in 44. only 45
[15:20:25 CET] <BtbN> I still wonder why they didn't just start using DASH, would have been less painfull
[15:20:49 CET] <BtbN> They are remuxing from rtmp/flv input anyway
[15:20:57 CET] <jya> I'm still trying to get my head around the dash format. How could anyone ever come up with something so complicated
[15:21:17 CET] <BtbN> Yeah, DASH seems like a solution to a bunch of non-existend problems
[15:21:23 CET] <BtbN> "Let's throw XML at it"
[15:21:42 CET] <jya> I'm so happy that we only have to do MSE (we had a native DASH player for a while)
[15:22:04 CET] <BtbN> A native HLS player would be nice, but for some reason mpeg-ts is bad
[15:22:29 CET] <jya> LOL, watching the twitch live stream, I was impressed on how realistic some of the screams were.
[15:22:50 CET] <jya> but it's my 1yo who woke up screaming.. wonder how long he's been up
[15:23:09 CET] <cone-231> ffmpeg 03Vittorio Giovara 07master:84c4714f397c: lavc: Move brd_scale to codec private options
[15:23:10 CET] <cone-231> ffmpeg 03Derek Buitenhuis 07master:4f32ccb61800: Merge commit '84c4714f397c9c50eb9d49008cc1c08385f68f31'
[15:23:30 CET] <jya> right 1:20AM, my turn to be tired... good night
[15:23:46 CET] <Daemon404> cya
[15:24:31 CET] <Daemon404> i see there's some fate tests.. crud
[15:24:53 CET] <Daemon404> actually it's fine...
[15:29:53 CET] <Daemon404> huh
[15:29:55 CET] <Daemon404> kierank, 
[15:29:59 CET] <Daemon404> tests/ref/fate/api-mjpeg-codec-param <-- exists
[15:30:05 CET] <Daemon404> daemon404 at bbvm:~/dev/f/ffmpeg$ make fate-api-mjpeg-codec-param
[15:30:05 CET] <Daemon404> make: Nothing to be done for 'fate-api-mjpeg-codec-param'.
[15:30:11 CET] <Daemon404> png works fine
[15:30:36 CET] <Daemon404> oh wut... if it runs once, it never runs again
[15:30:39 CET] <Daemon404> that doesnt seem right.
[16:08:32 CET] <nevcairiel> michaelni: some of your fate systems seem to be out of space, x86_64-debian-asan-144800, ia64-debian-qemu-gcc-4.4-shared and some more
[16:09:28 CET] <Daemon404> things that such about changing avcodec.h -> ccache wont work
[16:09:45 CET] <nevcairiel> i never use ccache, dont trust it =p
[16:09:53 CET] <nevcairiel> bought a 6 core cpu instead
[16:09:56 CET] <Daemon404> i have no reason to mistrust it
[16:10:05 CET] <Daemon404> i used it extensively in a past job
[16:10:47 CET] <Daemon404> nevcairiel, i dont suppose you are coming to FOSDEM
[16:11:31 CET] <nevcairiel> nah
[16:11:42 CET] <Daemon404> didnt think so
[16:11:53 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:8008a029ab40: avcodec/aacenc: Check both channels for finiteness
[16:11:54 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:034edcec6d83: swscale/swscale_unscaled: Fix odd height inputs for bayer_to_rgb24_wrapper()
[16:11:55 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:6eb76b34ca24: swscale/swscale_unscaled: Fix odd height inputs for bayer_to_yv12_wrapper()
[16:11:56 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:f121ed611ef3: swscale/x86/rgb2rgb_template: Fix planar2x() for short width
[16:11:57 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:6897859b5acf: swscale/swscale: Add some sanity checks for srcSlice* parameters
[16:11:58 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:61850f1c8423: avcodec/tiff: Check subsample & rps values more completely
[16:11:59 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:aa833e1a60c3: avcodec/put_bits: Assert buf_ptr in flush_put_bits()
[16:12:00 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:828d85bf8693: avcodec/gif: Fix lzw buffer size
[16:12:01 CET] <cone-231> ffmpeg 03Derek Buitenhuis 07release/2.8:b9551e71bf33: mov: Add an option to toggle dref opening
[16:12:02 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:c6f6829ce6e0: avcodec/ass_split: Fix null pointer dereference in ff_ass_style_get()
[16:12:03 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:d64ff3a6a961: avformat/img2dec: do not interpret the filename by default if a IO context has been opened
[16:12:04 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:642c54270be6: avformat/avio: Limit url option parsing to the documented cases
[16:12:05 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:8ed4b446571a: avformat/img2dec: Use AVOpenCallback
[16:12:06 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:f77b656b6eaf: avcodec/mpeg12enc: Move high resolution thread check to before initializing threads
[16:12:07 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:00393c56da97: avcodec/wmaenc: Check ff_wma_init() for failure
[16:12:08 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:971f47f2ebff: avformat/avformat: Replace some references to filenames by urls
[16:12:09 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:85cfcb87ff9b: avcodec/mpegvideo_enc: Check for integer overflow in ff_mpv_reallocate_putbitbuffer()
[16:12:10 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:98199983420b: avcodec/mjpegdec: Check for end for both bytes in unescaping
[16:12:11 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:e0d53cbeef7c: doc/demuxers: Document enable_drefs and use_absolute_path
[16:12:12 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:cb88f428b32f: avformat/concat: Check protocol prefix
[16:12:13 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:736e42bc33ec: avformat/libquvi: Set default demuxer and protocol limitations
[16:12:14 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:b432d883e623: avformat: Document urls a bit
[16:12:15 CET] <cone-231> ffmpeg 03Paul B Mahol 07release/2.8:0dc379cfa66d: avcodec/flacenc: fix calculation of bits required in case of custom sample rate
[16:12:16 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:6fec0dbd2e15: avutil/opt: check for and handle errors in av_opt_set_dict2()
[16:12:17 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:b15ae71305b2: avcodec/jpeg2000dec: More completely check cdef
[16:12:20 CET] <Cloudef> wow
[16:14:33 CET] <michaelni> my ccache says its 6gb .ccache is 34mb large great
[16:14:53 CET] <Daemon404> lolwut
[16:15:09 CET] Action: michaelni  rm -r .ccache
[16:15:27 CET] <ubitux> mmh... we can't send back a user arg in the log callback?
[16:16:10 CET] <michaelni> should fix the out of diskspace issue
[16:17:13 CET] <cone-231> ffmpeg 03Vittorio Giovara 07master:0ac9f33a9e69: lavc: Move frame_skip_* to codec private options
[16:17:15 CET] <cone-231> ffmpeg 03Derek Buitenhuis 07master:13be46c08e59: Merge commit '0ac9f33a9e69c64eee592791be3c5441a6a3d6b7'
[16:23:21 CET] <cone-231> ffmpeg 03Vittorio Giovara 07master:5764d3817366: lavc: Move chromaoffset to codec private options
[16:23:22 CET] <cone-231> ffmpeg 03Derek Buitenhuis 07master:7c6e86c0cec1: Merge commit '5764d38173661c29d954711dd5abfddf709e9ba4'
[16:36:39 CET] <cone-231> ffmpeg 03Vittorio Giovara 07master:7c79587d7407: lavc: Move scenechange_threshold to codec private options
[16:36:40 CET] <cone-231> ffmpeg 03Derek Buitenhuis 07master:30c1bdb87ce3: Merge commit '7c79587d7407dab4b9445d66b5f111fe657c8c4d'
[16:36:41 CET] <cone-231> ffmpeg 03Derek Buitenhuis 07master:e8c5d5f42960: snow: Move scenechange_threshold to a private option
[16:48:36 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:af21d609a0dd: Update for 2.8.6
[17:27:21 CET] <cone-231> ffmpeg 03wm4 07master:0badf4564a90: configure: fix mmal build dependencies
[17:27:23 CET] <cone-231> ffmpeg 03wm4 07master:d27a12cb0982: mmaldec: print the MMAL format FourCC automatically
[17:27:24 CET] <cone-231> ffmpeg 03wm4 07master:7b1b53f3a456: mmaldec: support MPEG-4
[17:27:25 CET] <cone-231> ffmpeg 03wm4 07master:14a90c9ef09a: mmaldec: limit internal buffering
[17:36:54 CET] <cone-231> ffmpeg 03James Almer 07master:c79252897096: x86/imdct36: use extractps inside the STORE macro
[17:42:50 CET] <cone-231> ffmpeg 03Vittorio Giovara 07master:1482aff20485: lavc: Move noise_reduction to codec private options
[17:42:51 CET] <cone-231> ffmpeg 03Derek Buitenhuis 07master:b986a4625d0e: Merge commit '1482aff2048511b821ff9feac19426113cc641a2'
[18:07:12 CET] <Daemon404> ff_frame_thread_encoder_init makes me want to cry blood
[18:07:20 CET] <Daemon404> look at those per codec hacks
[18:09:57 CET] <wm4> wow
[18:12:23 CET] <Daemon404> at least i see how to fix it here
[18:15:44 CET] <michaelni> x264 sc_threshold is broken, iam testing a fix ATM
[18:16:22 CET] <Daemon404> michaelni, there is a libav on libav-devel
[18:16:26 CET] <Daemon404> i noticed it earlier
[18:16:37 CET] <Daemon404> for more than just that
[18:17:54 CET] <michaelni> Daemon404, if fixes exist can you cherry pick them or something ?
[18:18:30 CET] <Daemon404> theyre not pushed yet
[18:18:36 CET] <Daemon404> or reviewed
[18:18:40 CET] <Daemon404> but let me look
[18:19:08 CET] <michaelni> for sc_threshold i can push mine, it seems working
[18:19:41 CET] <Daemon404> go ahead
[18:19:48 CET] <Daemon404> i can just skip bits later
[18:20:02 CET] <cone-231> ffmpeg 03Vittorio Giovara 07master:12b497692232: lavc: Move mpeg_quant to codec private options
[18:20:03 CET] <cone-231> ffmpeg 03Vittorio Giovara 07master:96c373c7704a: lavc: Move context_model to codec private options
[18:20:04 CET] <cone-231> ffmpeg 03Derek Buitenhuis 07master:0e3e3656d31a: Merge commit '12b49769223234673db1003d9c43e7483ceb0282'
[18:20:04 CET] <cone-231> ffmpeg 03Derek Buitenhuis 07master:5b0d4c247a3c: Merge commit '96c373c7704aeb1cc1d2c275fbb5d71777665589'
[18:20:06 CET] <cone-231> ffmpeg 03Derek Buitenhuis 07master:1a2d6055beed: avcodec/frame_thread_encoder: Check the private option for huffy's context modelling
[18:20:46 CET] <nevcairiel> huffy? How cute :p
[18:21:49 CET] <Daemon404> lol
[18:29:53 CET] <cone-231> ffmpeg 03Michael Niedermayer 07master:cb06be6136dd: avcodec/libx264: Fix sc_threshold after 30c1bdb87ce336f2b9957769e30a10d72f93d372
[18:31:18 CET] <Daemon404> yes that looks right
[18:41:53 CET] <Daemon404> that src folder is annoying
[18:43:20 CET] <michaelni> should i push vittorios x264 fix ? or wait ?
[18:43:34 CET] <michaelni> dont want to break some in process merge
[18:43:34 CET] <Daemon404> i dont have an opinion there
[18:43:44 CET] <michaelni> proGress
[18:43:46 CET] <Daemon404> im not merging right now. im thinking
[18:43:50 CET] <michaelni> ok
[18:44:06 CET] <Daemon404> the next commit moves timecode_frame_start to a mpeg12enc private option
[18:44:22 CET] <Daemon404> but in ffmpeg it was repurpose to also be a decoder field
[18:44:27 CET] <Daemon404> :/
[18:44:52 CET] <Daemon404> the right fix is what? side data?
[18:44:55 CET] Action: Daemon404 groan
[18:45:38 CET] <wm4> probably skip the change
[18:45:57 CET] <Daemon404> no, i think it should be fixed
[18:46:03 CET] <Daemon404> it's a field in avctx for a single codec.
[18:46:10 CET] <Daemon404> that's not right
[18:46:21 CET] <cone-231> ffmpeg 03Vittorio Giovara 07master:b340bd8a58c3: libx264: Make sure to preserve default option values
[18:48:06 CET] <wm4> I mean it can be fixed after that
[18:48:11 CET] <wm4> instead of messing it into the merge
[18:48:59 CET] <Daemon404> i wouldnt include it in the merge
[18:49:10 CET] <Daemon404> and IME "fix it later" ends up as never
[18:49:38 CET] <Daemon404> wm4, the merge also doesnt remove it
[18:49:42 CET] <Daemon404> it just deprecates
[18:57:49 CET] <wm4> ok
[18:58:05 CET] <wm4> then you don't really have to care
[18:58:17 CET] <Daemon404> g 31
[21:00:33 CET] <Daemon404> g 42
[21:24:00 CET] <ac_slater> hey guys, in an libavcodec codec, how can I get the input format? ie - I want to test if my input is the "Null" codec
[21:24:49 CET] <wm4> you can't and you shouldn't need to know
[21:37:37 CET] <cone-231> ffmpeg 03Marton Balint 07master:1036a1b8a31d: lavf/segment: add support for specifying clock time offset
[21:37:39 CET] <cone-231> ffmpeg 03Marton Balint 07master:369a6a6ed450: lavf/segment: add new option segment_clocktime_wrap_duration
[21:40:06 CET] <wm4> does anyone have one of those mpeg 4 files that fail with hw decoding?
[21:40:18 CET] <wm4> AFAIK they use some form of GMC and tend to fail with most hwaccels
[21:41:01 CET] <JEEB> I've never actually tried MPEG-4 Part 2 in HW
[22:43:40 CET] <durandal_170> how to handle private stream in mpeg?
[23:11:15 CET] <ac_slater> wm4: I kinda want to detect "Null" input and produce a test pattern. I guess I could just use a test pattern input
[23:16:45 CET] <wm4> uh yes
[23:17:04 CET] <wm4> anything else would be weird, unless it's a temporary debug hack
[23:19:48 CET] <J_Darnley> Using an existing testing source generator also means you won't screw up writing it and then wondering whether your encoder or the generator is wrong.
[23:19:58 CET] <ac_slater> exactly, you guys are right
[23:20:05 CET] <ac_slater> too much to do in the encoder.
[23:21:11 CET] <ac_slater> wm4: I never did figure out how to pack yuv420p. I think I got the packing right, but apparently it stalls my encoder so hard that I can convert in software. So, I'm looking into using NEON to do my memcpys (since I'm on ARM). It might work
[23:22:04 CET] <wm4> sounds weird
[23:22:17 CET] <wm4> if it stalls hard, you might have crashed the firmware
[23:22:27 CET] <wm4> (this happened all the time when I tried to get mmal decoding to work)
[23:22:34 CET] <ac_slater> right, I reboot often
[23:22:43 CET] <wm4> (or at least I think that's what happened)
[23:22:52 CET] <ac_slater> I was looking at the mmal decoder you had commits on
[23:23:03 CET] <ac_slater> I like it and I might contribute to an MMAL encoder
[23:23:38 CET] <ac_slater> I'm sticking with openMAX IL at the moment since I only need to support one device at the moment
[23:23:45 CET] <wm4> I'm sure rcombs has his proof of concept still somewhere (I based by mmal code on it)
[23:24:05 CET] <ac_slater> I ping'd him/her last night without a responce
[23:24:08 CET] <ac_slater> rcombs: ping
[23:24:56 CET] <wm4> the mmal decoder is a bit absurdly complicated, because it has to connect libavcodec synchronous API to mmal's asynchronous API
[23:25:23 CET] <ac_slater> exactly. I didn't want to mess with async unless I had a good grasp on vc
[00:00:00 CET] --- Fri Jan 29 2016