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

[burek]

[00:00:30 CEST] <iive> actually it might be interesting idea if the encoders could output these frames
[00:00:52 CEST] <iive> this way you can watch the encoding quality in real time
[00:21:42 CEST] <kierank> BBB: it's what nicolas wants...
[00:38:25 CEST] <jamrial> oh lol, libav also postponed coded_frame
[01:37:51 CEST] <BBB> michaelni: AVERROR_EOF
[01:38:58 CEST] <nevcairiel> all these patches look stupid, wouldn't it just loop for a bit and then quit? we don't have eof checks after every single read ever
[01:39:37 CEST] <BBB> I didnt check
[01:39:41 CEST] <BBB> I also didnt fully review
[01:43:09 CEST] <kierank> interesting that they have managed to fuzz containers
[01:43:13 CEST] <kierank> but yes patches look stupid
[01:43:18 CEST] <kierank> surely every read needs checking
[01:58:32 CEST] <michaelni> BBB, the function seems to use AVERROR_EOF for various conditions
[02:00:40 CEST] <michaelni> nevcairiel, yes its a denial of service. It would block for a long time and eventually finish. In an attack the attacker would use this to bring down some tool or service
[02:01:16 CEST] <michaelni> that is all but one, one is a real endless loop IIRC
[02:14:54 CEST] <BBB> can you define "long"?
[02:21:53 CEST] <michaelni> BBB, its different for each case according to the reports a 410 byte file caused more than 1 hour (24 cpu core xeon 2.4ghz with 96gb ), another caused more than 30min, one was 4 one was 1 and one was 5 minutes
[02:23:14 CEST] <michaelni> IIUC these are fuzzed files not hand crafted to achive the worst case
[02:27:24 CEST] <peloverde> Is there currently a propagation window for fate samples before pushing?
[02:28:04 CEST] <michaelni> some fate clients need up to 24h to sync the samples
[02:28:52 CEST] <michaelni> i think most fate clients need no delay
[02:47:38 CEST] <cone-165> ffmpeg 03Paul B Mahol 07master:dbc9a8f21f92: avcodec/aac: Add floating point 960/120 MDCT window
[02:47:38 CEST] <cone-165> ffmpeg 03Alex Converse 07master:cb96e9bea418: fate: add test vector aac-al04sf_48
[04:39:43 CEST] <cone-165> ffmpeg 03James Almer 07master:e51073fe00d2: checkasm/vf_blend: rename addition128 and difference128 to grainmerge and grainextract
[05:41:52 CEST] <cone-165> ffmpeg 03Muhammad Faiz 07master:ae1ce0db91b8: avfilter/af_firequalizer: add min_phase option
[05:41:52 CEST] <cone-165> ffmpeg 03Muhammad Faiz 07master:e0e991f8a131: avfilter/af_firequalizer: reindent after previous commit
[09:11:10 CEST] <cone-952> ffmpeg 03Paul B Mahol 07master:4b96fd2b1ec6: avfilter/af_agate: switch to activate
[10:36:22 CEST] <cone-952> ffmpeg 03Paul B Mahol 07master:1e7ce6d92513: avfilter/af_amix: check ff_insert_inpad() for failure
[10:36:22 CEST] <cone-952> ffmpeg 03Paul B Mahol 07master:13f9639e3e2a: avfilter/af_headphone: check ff_insert_inpad() for failure
[10:36:24 CEST] <cone-952> ffmpeg 03Paul B Mahol 07master:db5604ac26f0: avfilter/af_join: check ff_insert_inpad() for failure
[10:36:24 CEST] <cone-952> ffmpeg 03Paul B Mahol 07master:f39136b0a76e: avfilter/af_merge: check ff_insert_inpad() for failure
[10:36:25 CEST] <cone-952> ffmpeg 03Paul B Mahol 07master:9bd1bf382e18: avfilter/f_interleave: check ff_insert_inpad() for failure
[10:36:26 CEST] <cone-952> ffmpeg 03Paul B Mahol 07master:99dd47a64752: avfilter/vf_extractplanes: check ff_insert_outpad() for failure
[10:36:28 CEST] <cone-952> ffmpeg 03Paul B Mahol 07master:730734d4f3e0: avfilter/af_channelsplit: check ff_insert_outpad() for failure
[10:36:28 CEST] <cone-952> ffmpeg 03Paul B Mahol 07master:01b986cf1819: avfilter/f_select: check ff_insert_outpad() for failure
[10:36:30 CEST] <cone-952> ffmpeg 03Paul B Mahol 07master:1a58da434ad0: avfilter/avf_concat: check ff_insert_pad() for failure
[10:36:30 CEST] <cone-952> ffmpeg 03Paul B Mahol 07master:dfea94ce994a: avfilter/vf_fieldmatch: check ff_insert_inpad() for failure
[10:36:32 CEST] <cone-952> ffmpeg 03Paul B Mahol 07master:0b940c95b217: avfilter/vf_decimate: check ff_insert_inpad() for failure
[10:36:33 CEST] <cone-952> ffmpeg 03Paul B Mahol 07master:5e706a2afb09: avfilter/split: check ff_insert_outpad() for failure
[10:36:33 CEST] <cone-952> ffmpeg 03Paul B Mahol 07master:48ddd8ddec35: avfilter/src_movie: check ff_insert_outpad() for failure
[12:40:50 CEST] <cone-952> ffmpeg 03Muhammad Faiz 07master:3ddd10290afb: avfilter/af_firequalizer: fix minval on cepstrum calculation
[14:35:50 CEST] <cone-952> ffmpeg 03Paul B Mahol 07master:71907f250939: doc/filters: add pseudocolor example
[14:59:50 CEST] <cone-952> ffmpeg 03Derek Buitenhuis 07master:9e02f35f6a1b: mjpeg: Add support for ICC side data
[14:59:51 CEST] <cone-952> ffmpeg 03Derek Buitenhuis 07master:add7b3bc3fb7: utils: Do not expand a macro with 'defined' in it
[16:02:54 CEST] <J_Darnley> Is GetBitsContext public API?
[16:05:34 CEST] <J_Darnley> No, it would be called AV.. if it were.
[16:06:06 CEST] <J_Darnley> av_dirac_parse_sequence_header it public though.  :)
[16:12:33 CEST] <J_Darnley> Oh dammit!  Why can't I use that with a struct on the stack?
[16:42:29 CEST] <BBB> J_Darnley: you can
[16:44:48 CEST] <jya> what's the deal when submitting a patch, you post it on the mailing list and then you wait?
[16:49:13 CEST] <J_Darnley> BBB: Huh?  It takes a struct** and says it will allocate and then I need to call av_free
[16:49:21 CEST] <J_Darnley> jya: Yeah, basically
[16:50:04 CEST] <BBB> jya: you can poke people (this is similar to how you assign a reviewer on patch trackers)
[16:50:10 CEST] <BBB> jya: poking works like this:
[16:50:22 CEST] <BBB> J_Darnley: poke! can you review my patch bla: blurb?
[16:50:43 CEST] <BBB> jya: ingenious, right?
[16:50:49 CEST] <jya> indeed :)
[16:51:02 CEST] <jya> I'm not sure why is the best person to review that though, its the mp4 muxer
[16:52:33 CEST] <BBB> ah, yes
[16:52:41 CEST] <BBB> thats where email based review is better than patch review trackers
[16:52:48 CEST] <BBB> :-p
[16:53:03 CEST] <BBB> not sure who could review it ;)
[16:53:10 CEST] <BBB> you could poke usual victims
[16:54:36 CEST] <jya> BBB: sounds like a job for you then :)
[16:55:13 CEST] <jya> it's damn simple patch, replace writing 0 for whenever the sampling rate is > 65536, and instead write the closest divisor
[16:55:40 CEST] <jya> only does the job properly is the sampling rate is even though, but it won't matter either way
[16:56:42 CEST] <BBB> sample rate?
[16:56:48 CEST] <BBB> is that a subtitle thing?
[16:56:50 CEST] <BBB> :-p
[16:56:54 CEST] <jya> audio
[16:56:59 CEST] <BBB> I know, just kidding ;)
[16:57:09 CEST] <jya> ah, never know these days :)
[16:57:24 CEST] <jya> BBB: I saw the multi-threading stuff for slices while looking at patches
[16:57:26 CEST] <jya> that's rather exciting
[16:57:33 CEST] <BBB> yes, its quite nice
[16:57:47 CEST] <jya> BTW, we plan to make vp9 the default for our webRTC implementation
[16:57:50 CEST] <BBB> if we want to use it for rtc, we still need error resilience
[16:58:04 CEST] <BBB> but that shouldnt be super-hard
[16:58:17 CEST] <jya> actually, about that. libvpx error resilience is disabled by default, I even think the option was removed from the code
[16:58:38 CEST] <jya> so I'm not sure it matters that much to have it in ffvp9
[16:58:59 CEST] <jya> BBB: will you be at demuxed in October?
[17:11:40 CEST] <BBB> jya: yes
[17:12:00 CEST] <BBB> jya: hm& but then every time a frame is missed, you cant reconstruct
[17:12:01 CEST] <BBB> that would suck
[17:12:04 CEST] <jya> great I'll get to meet you there
[17:12:26 CEST] <jya> how do they do without it with libvpx?
[17:13:31 CEST] <BBB> they probably have a backchannel API to signal the encoder to send a new keyframe or to occlude that frame as a reference
[17:13:40 CEST] <BBB> hard to say for sure
[17:13:58 CEST] <BBB> the decoder obviously doesnt know any of this
[17:14:11 CEST] <BBB> this is between the rtp layer and the sender (encoder)
[17:14:16 CEST] <BBB> the decoder just does what it does normally
[17:14:23 CEST] <BBB> it happens to work, basically
[17:18:42 CEST] <wm4> jkqxz: this v4l2 stuff looks pretty batshit
[17:20:07 CEST] <cone-952> ffmpeg 03James Almer 07master:2c800eb7375c: avcodec: make the avcodec_get_chroma_sub_sample deprecation effective
[17:21:49 CEST] <jkqxz> Yeah, but apparently it works.  I've been failing to find time to look at it again - need at least a few hours to go through it properly.  (Maybe tomorrow...)
[17:22:13 CEST] <BBB> j-b: who do I poke about ticket prices?
[17:23:02 CEST] <jya> BBB: that the peer request a keyframe is something else entirely
[17:23:11 CEST] <jya> that is done
[17:23:19 CEST] <BBB> right
[17:23:29 CEST] <BBB> but if you hav that, error resilience in the decoder isnt so important
[17:23:41 CEST] <BBB> different methods to do the same (sorta) thing
[17:23:54 CEST] <jya> but from the decoder point of view, there's nothing in place for error-resilience, it's not compiled in
[17:24:22 CEST] <jya> I implemented a change to use ffvp9 instead of libvpx
[17:24:29 CEST] <jya> issues occurred when the resolution changed
[17:24:56 CEST] <jya> libvpx handled it just fine. with ffvp9 you end up with a crappy image
[17:25:01 CEST] <BBB> really?
[17:25:06 CEST] <BBB> we have fate tests for that
[17:25:17 CEST] <BBB> is this the svc-thing? or is this with a new kf?
[17:25:19 CEST] <jya> like the new (typically lower resolution) image in the top left corner of an otherwise green image
[17:25:32 CEST] <BBB> uh&
[17:25:33 CEST] <BBB> hm...
[17:25:59 CEST] <jya> mind you, it may be something I haven't done, such as not reconfiguring the decoder for a new res
[17:26:07 CEST] <BBB> you dont have to reconfigure it
[17:26:10 CEST] <jya> I just keep calling input with the data as it comes in
[17:26:13 CEST] <BBB> you just have to read out the per-frame sizes :-p
[17:26:19 CEST] <BBB> (AVFrame->width/height)
[17:26:29 CEST] <jya> what comes out has the same resolution has the previous frame, but padded with green
[17:26:42 CEST] <BBB> really&
[17:26:47 CEST] <BBB> how interesting
[17:26:49 CEST] <jya> i do that already (read the AVFrame dimensions)
[17:26:58 CEST] <jya> I have some doubts suddenly, let me check again
[17:27:05 CEST] <BBB> please do
[17:27:09 CEST] <BBB> thatd be a major bug ;)
[17:27:12 CEST] <durandal_170> have sample?
[17:27:40 CEST] <BBB> in fact, Im pretty sure it works because I have some scalable samples and they rescale fine in my analyzer (which uses AVFrame->width/height)
[17:27:51 CEST] <BBB> but happy to be proven wrong :-p
[17:27:53 CEST] <jya> BBB: yes, that's what it does: https://dxr.mozilla.org/mozilla-central/source/dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp#304
[17:28:04 CEST] <jya> it reads the YUV planes from the AVFrame as well as the dimensions
[17:29:40 CEST] <BBB> how strange
[17:30:10 CEST] <jya> I'll try to reproduce it as part of a webRTC session
[17:30:25 CEST] <jya> it's not easy when you're on a gigabit fiber at home
[17:30:42 CEST] <jya> but this summer, I was traveling, on a mobile phone as modem.. was happening a lot
[17:30:52 CEST] Action: kierank has gigabit fibre at work and these adaptive streaming things still are awful
[17:31:09 CEST] <jya> the same code with just using libvpx  as decoder, and the frames resized perfectly
[17:31:11 CEST] <kierank> though i guess it's blame tcp which webrtc don't use
[17:32:23 CEST] <jya> kierank: with what Youtube for example?
[17:32:31 CEST] <jya> they do a pretty good job these days with MSE
[17:32:31 CEST] <BBB> lemme test
[17:32:35 CEST] <kierank> all of the streaming services on a smart tv
[17:32:38 CEST] <kierank> amazon, netflix etc
[17:32:41 CEST] <kierank> iplayer
[17:32:47 CEST] <kierank> they just decide to randomly drop to 480p
[17:32:59 CEST] <jya> amazon, netflix on a web browser desktop should be perfect really
[17:33:27 CEST] <jya> for a smart TV, they typically use HLS, and unlike with MSE/DASH the job is on the client to do the adaptation
[17:33:33 CEST] <jya> it's always a bit slower.
[17:34:01 CEST] <jya> which isn't helped with the fact that HLS doesn't require a new segment to start with a keyframe, so typically when it change resolution, for a few seconds it's crap
[17:35:23 CEST] <wm4> jkqxz: sent a quick review
[17:36:03 CEST] <wm4> jvlol wut
[17:36:07 CEST] <wm4> oops
[17:36:10 CEST] <wm4> jya: wat
[17:36:22 CEST] <wm4> what's the point of adaptive stuff if you can't actually adapt
[17:36:43 CEST] <wm4> which pretty much requires that decoding can be restarted from an arbitrary fragment
[17:38:25 CEST] <BBB> jya: just tested with vp90-2-05-resize.ivf
[17:38:51 CEST] <BBB> jya: and I get (AVFrame->width/height): 352x288 -> 282x173 -> 352x288
[17:39:17 CEST] <jya> BBB: ok, I'll do further test and see what's going on then
[17:39:20 CEST] <BBB> ty
[17:39:33 CEST] <jya> but is the input set with the right resolution though?
[17:42:22 CEST] <jya> during a webrtc session you don't know that, so here the input has no resolution set in the input
[17:43:30 CEST] Action: jya gotta go
[17:45:35 CEST] <BBB> jya: input is unset, the decoder overwrites whatever the input sets
[18:48:40 CEST] <cone-952> ffmpeg 03James Almer 07master:8a0954dd51ca: avcodec: add missing FF_API_DEBUG_MV wrappers
[19:18:27 CEST] <jamrial> BBB: can you check the getchroma comment from michael?
[19:18:40 CEST] <jamrial> as i said there was a reason why it wasn't deprecated :/
[19:19:08 CEST] <BBB> he means int a, b; avcodec_get_chroma_subsample(user_input, &a, &b); printf(%d, %d\n, a, b); is fine with old AI
[19:19:10 CEST] <BBB> API
[19:19:17 CEST] <BBB> but in new API you need a condition
[19:19:51 CEST] <jamrial> epatchwelcome. i never wanted to deal with this :p
[19:19:57 CEST] <BBB> desc = av_get_pix_fmt_desc(user_input); if (!desc) HELP!!!!; printf(%d, %d\n, desc->comp[1].h_ss, v_ss);
[19:20:03 CEST] <BBB> what do you mean?
[19:20:07 CEST] <BBB> youre not changing any callers
[19:20:09 CEST] <BBB> its totally fine
[19:20:16 CEST] <BBB> maintainers should change their callers
[19:20:37 CEST] <jamrial> alright
[19:21:18 CEST] <BBB> I see 17 users in libavcodec
[19:21:21 CEST] <BBB> nothing outside that
[19:21:23 CEST] <BBB> so not that bad
[19:21:53 CEST] <BBB> in most cases weve already decided at that point what the pixfmt is, so it really doesnt matter
[19:24:51 CEST] <michaelni> BBB, its no problem to change it, but dont you think that API changes that everyone has to update their code to should be discussed?
[19:25:32 CEST] <BBB> I have no opinion on that
[19:26:25 CEST] <nevcairiel> not sure you can call avcodec_get_chroma_sub_sample inherently safe if it contains an abort() =p
[19:27:00 CEST] <BBB> maybe its safe because valgrind doesnt complain about it?
[19:27:23 CEST] <nevcairiel> both of thsoe cases deal with invalid pixfmts, in this case your app just quits, in the other you can write a check
[19:27:28 CEST] <nevcairiel> i would say the other is safer
[19:27:39 CEST] <BBB> again, I have no opinion on that
[19:27:49 CEST] <BBB> but having two public APIs to do the same thing is ridiculous
[19:27:53 CEST] <jamrial> guess i should have waited for more opinions before pushing
[19:27:56 CEST] <BBB> subsampling is in desc, so use the desc API
[19:27:58 CEST] <BBB> jamrial: no, its fine
[19:28:04 CEST] <BBB> this has been in libav for ages
[19:28:08 CEST] <BBB> at some point we have to move on
[19:28:09 CEST] <michaelni> nevcairiel, if the code is misused one aborts() the other does something unexpected and random hard to debug
[19:28:36 CEST] <michaelni> "<BBB> but having two public APIs to do the same thing is ridiculous" <-- i strongly agree
[19:28:59 CEST] <BBB> hows coded_frame out of AVCodecContext going btw?
[19:29:05 CEST] <BBB> speaking of interesting things
[19:29:10 CEST] <nevcairiel> michaelni: but to be safe I have to validate the pixfmt myself before, basically by calling the same API anyway, so in my eyes the new API is therefor better
[19:29:22 CEST] <jamrial> BBB: i know, but seeing the deprecation was made uneffective for a reason (regardless of it being good/bad/right/wrong), i should have waited for a comment from the person that did that
[19:30:01 CEST] <BBB> how many prores encoders and decoders do we have again?
[19:30:05 CEST] <BBB> alright, still the same :-p
[19:30:10 CEST] <jamrial> heh
[19:30:23 CEST] <jamrial> both are waiting for tests(tm) to see which is better i guess :p
[19:30:39 CEST] <jamrial> the whole "one is lgpl" doesn't apply anymore after all
[19:31:48 CEST] <jamrial> alright, got the major bump working with a minimal amount of ~2 years old APIs postponed (because removing them is a pain atm)
[19:31:55 CEST] <michaelni> nevcairiel, if you just write some code lazily (which is what most people probably do) the old simply aborts when its wrong (easy to spot and fix) the new does someting random which can be annoying to debug 
[19:32:20 CEST] <nevcairiel> its not our job to fix lazy developers code
[19:32:30 CEST] <nevcairiel> also null-pointer deref also just crashes on 99% of all systems
[19:32:35 CEST] <jamrial> will send a patchset to the ml, to see if anyone wants to look at said apis and properly remove them. otherwise we can go ahead as is
[19:34:32 CEST] <nevcairiel> we report errors through return values, not by abort()'ing all over
[19:37:52 CEST] <BBB> how about we create an abort callback that users can implement to longjmp back to their caller code, but otherwise can be used internally to abort? <libjpeg>
[19:38:05 CEST] <nevcairiel> go away with longjmps =p
[19:38:10 CEST] <BBB> muhahahahahaha
[19:38:47 CEST] <BBB> (and for the record: that was not serious, its godawful design)
[19:39:29 CEST] <nevcairiel> i've worked with code that uses this, following the logic flow is awful
[19:45:09 CEST] <michaelni> nevcairiel, when practically no caller checks the return, its not that great as a way to handle errors
[19:47:16 CEST] <nevcairiel> again, thats not our problem. we have a clear way to communicate errors for all sorts of APIs, singular exceptions that abort instead are not good
[19:49:02 CEST] <nevcairiel> or should we start abort()ing everywhere instead of using return values, just in case someone didnt check it?
[19:50:02 CEST] <BBB> longjmp!!!
[19:50:03 CEST] <BBB> guys
[19:50:48 CEST] <nevcairiel> i even entirely hate the concept that release-mode builds can include abort()'s in them in general
[19:51:10 CEST] <BBB> this problem is solved already, why do you think all cameras use jpeg when much better compression alternatives exist (e.g. HEIF)? it has nothing to do with compatibility; its longjmp!!!
[19:51:56 CEST] <BBB> longjmp is the singularity around which everything else revolves. everything changes, but (lib)jpeg remains, and the only lib implementing longjmp error management is&? libjpeg! learn guys, its not correlation, its causation!
[19:52:09 CEST] <BBB> :-p
[19:52:17 CEST] <JEEB> :D
[19:52:29 CEST] <BBB> maybe I shouldve added webp there for even more nuts
[19:52:47 CEST] <BBB> </gone>
[19:52:47 CEST] <drv> I think libpng uses longjmp() error handling too :)
[19:52:51 CEST] <JEEB> but yea, trying to propagate abort() based error flagging just because people don't check results
[19:53:06 CEST] <JEEB> users can always come up with ways of ignoring errors
[19:54:22 CEST] <wm4> libpng also uses longjmp
[19:55:41 CEST] <BBB> and what image format was able to overthrow gif? png! longjmp! guys! EUREKA!
[19:55:54 CEST] <BBB> (maybe Im taking this too far :-D )
[19:56:24 CEST] <BtbN> I'd argue h264 has overthrown gifs on the web by now.
[20:02:04 CEST] <BBB> animated gifs maybe
[20:02:07 CEST] <BBB> logos still use png
[20:02:51 CEST] Action: ubitux is still using gif everywhere he can
[20:03:24 CEST] <ubitux> if github allows to use some looping webm, maybe i'll switch
[20:03:33 CEST] <ubitux> (in their markdown thing)
[20:03:44 CEST] <RiCON> i don't think you can
[20:04:03 CEST] <ubitux> then long live to gif
[20:04:39 CEST] <BtbN> imgur is trying to "standardize" gifv
[20:04:53 CEST] <BtbN> (renamed mp4 without audio, looping by default)
[20:05:28 CEST] <wm4> dumb
[20:05:51 CEST] <wm4> fole extensions officially don't mean anything on http anyway
[20:05:53 CEST] <wm4> *file
[20:06:09 CEST] <BtbN> Pretty sure they also made up a new mime type for it
[20:07:57 CEST] <nevcairiel> definitely, and mime-type means something on http
[20:09:51 CEST] <RiCON> BtbN: isn't the mimetype just text/html?
[20:10:30 CEST] <BtbN> for images and videos? No
[20:10:35 CEST] <RiCON> for gifvs
[20:10:40 CEST] <BtbN> Doubt it
[20:10:51 CEST] <RiCON> it's a simple html with a <video>mp4 with fallback to gif
[20:11:15 CEST] <RiCON> at least in browsers and curl
[20:11:51 CEST] <RiCON> even if you go directly to ID.mp4 it 301s to the ID.gifv
[20:12:46 CEST] <BBB> you have to admit that renaming .mov to .mp4 did great things
[20:13:00 CEST] <BBB> didnt work for .ogg .ogm .oga etc. though
[20:13:04 CEST] <BBB> .ogv
[20:13:20 CEST] <wm4> RiCON: they might use http content negotiation if it works in curl
[20:13:24 CEST] <jamrial> there's even .ogx
[20:13:31 CEST] <RiCON> .ogg and .ogv are sorta used
[20:13:42 CEST] <RiCON> for vorbis and theora+vorbis
[20:13:43 CEST] <wm4> BBB: mp4 pretty much sucks
[20:13:46 CEST] <jamrial> i have never seen a single file using it, unlike .ogv
[20:13:51 CEST] <wm4> I've decided that mkv is the better format
[20:14:39 CEST] <jamrial> RiCON: afaik .ogv is 1 video + 1 audio. can be theora, vp8, vorbis, flac, etc
[20:15:12 CEST] <wm4> isn't ogm avi-in-ogg or something
[20:15:21 CEST] <wm4> ogm timestamps are still broken with libavformat
[20:15:21 CEST] <jamrial> .ogx is supposed to have a skeleton stream (weird data stream to work around limitations of the format), and can have several streams of any kind, including subtitles
[20:15:24 CEST] <nevcairiel> ogm is its own sort of nightmare
[20:15:29 CEST] <wm4> (got broken somewhere in recent years)
[20:15:30 CEST] <jamrial> wm4: ogm is a non xiph hack
[20:16:11 CEST] <wm4> the most shocking thing is that xiph apparently defends ogg
[20:19:27 CEST] <RiCON> wm4: appparently curl/mpv work with the .mp4 directly
[20:19:55 CEST] <nevcairiel> they use all sort of shitty server-side magic these days to serve different things to different clients
[20:21:29 CEST] <RiCON> and the download only gives the huge gif, lol
[20:21:36 CEST] <RiCON> download link*
[20:21:53 CEST] <wm4> odd
[21:01:33 CEST] <Compn> gifv is stupid name
[21:01:45 CEST] <Compn> those sites that serve different items piss me off
[21:27:46 CEST] <TD-Linux> BBB, the .opus rename did work well though
[21:27:57 CEST] <BBB> cool
[23:17:06 CEST] <atomnuker> BBB: what happened to the loopfilter avx2 asm?
[23:22:05 CEST] <BBB> gh0st__: ^^
[23:26:21 CEST] <gh0st__> atomnuker: no worries, I am going to do it.
[23:37:16 CEST] <wm4> lol web tech
[23:59:26 CEST] <cone-260> ffmpeg 03Michael Niedermayer 07master:7c10068da10a: avcodec/dvbsubdec: Check for duplicate regions in dvbsub_parse_page_segment()
[23:59:26 CEST] <cone-260> ffmpeg 03pkviet 07master:e0436ddaa496: ffmpeg options: Enable trailing ? for map_channel
[00:00:00 CEST] --- Sat Aug 26 2017