[02:45] <BBB> yay iadst4 works [02:45] <BBB> now to debug the iadst8 [02:45] <BBB> grmbl [04:10] <cone-115> ffmpeg.git 03Michael Niedermayer 07master:da0684820a58: avcodec/dsputil/huffyuv: move diff int16 and add int16 to dsputil [04:10] <cone-115> ffmpeg.git 03Michael Niedermayer 07master:a493f8541de2: avcodec/x86/dsp: add_int16_mmx / add_int16_sse2 [04:43] <cone-115> ffmpeg.git 03Carl Eugen Hoyos 07master:f9c2d4d17e3b: Allow decoding of slightly broken Nikon avi files. [04:43] <cone-115> ffmpeg.git 03Michael Niedermayer 07master:4014b401b0d5: Merge remote-tracking branch 'cehoyos/master' [11:02] <saste> do we support stream encryption? [11:56] <Compn> saste : rtmp is encrypted, ffmpeg can read rtmpe , not sure if it can transmit said rtmpe... [12:17] <saste> Compn, what about rtsp/rtp [12:18] <saste> i see we have a crypto reading protocol [12:23] <saste> any reason we don't have a writing crypto protocol? [13:23] <BBB> michaelni: dsputil is a bad idea, don't do that - move it into its own dspcontext [13:23] <BBB> michaelni: and I know there's already some huffyuv functions in there, which are now shared by other codecs = monstrous unfixability - let's not make that worse [13:27] <cone-469> ffmpeg.git 03Stefano Sabatini 07master:5e2b8e493436: examples: add remuxing example [13:27] <cone-469> ffmpeg.git 03Stefano Sabatini 07master:d72c742d478b: examples/muxing: factorize write_interleave code [13:27] <cone-469> ffmpeg.git 03Stefano Sabatini 07master:b933c72b5e36: examples/muxing: change error checks, from "ret != 0" to "ret < 0" [13:27] <cone-469> ffmpeg.git 03Stefano Sabatini 07master:9ab8f3738a4c: examples/muxing: remove redundant {} [13:27] <Daemon404> BBB, the huffyuv functions shuldnt even be named that [13:27] <Daemon404> theyre bog standard left and med preiction. [14:09] <Compn> saste : because most people who want to encrypt video are users who want to shoot themselves in the foot [14:09] <Compn> saste : is there an actual legit use for encrypting video ? [14:10] <saste> Compn, privacy? [14:11] <Compn> i mean, do you want it password protected like a zip file, or key encrypted kinda like a drm wmv file ? [14:11] <Compn> we have wmv key decryption support [14:11] <Compn> dont think we have encryption part [14:12] <saste> anyway my question was technical, is it possible to encrypt stuff at the protocol level? [14:12] <Compn> forgot about https [14:12] <Compn> sftp ? [14:13] <Compn> sorry i'm not being helpful. probably no support [14:14] <saste> that's what i think as well [14:14] <nevcairiel> the tls protocol can write encrypted data, so you could open a encrypted tls socket on one end and connect from another end, and get transport encryption [14:23] <funman> any sight of mraulet around here? [14:23] <funman> he's not on nickserv so I can't see when he last logged in [14:25] <Compn> probably just email him [14:25] <Compn> a /whowas produces nothing and his nick isnt in my buffer [14:25] <Compn> you could search ffmpeg-devel-irc mailing list archives [14:54] <ubitux> https://lists.libav.org/pipermail/libav-devel/2014-January/055168.html [14:55] <ubitux> (drop of sh4, sparc and bfin) [14:55] <av500> omg [14:55] <Compn> wot! [14:55] <j-b> Soo useful archs! [14:56] <ubitux> i'm not directly concerned, but maybe someone wants to comment here [14:57] <Compn> just post a request on the list to see how many sh4, sparc and bfin users there are ? [14:57] Action: Compn afk [14:57] <j-b> bfin will stay [14:57] <j-b> sh4 and sparc will die [14:57] <j-b> I think that's quite obvious [14:57] <Compn> sh4 is dreamcast ? [14:58] <ubitux> Compn: better mail the authors/contributors to the code [15:11] <michaelni> BBB you mean create a dspcontext for lossless video and move the function there ? [15:11] <michaelni> or something else ? [15:13] <cone-469> ffmpeg.git 03Anton Khirnov 07master:f7e85ee996b3: lavc: allow the caller to override dimensions in ff_get_buffer() [15:13] <cone-469> ffmpeg.git 03Michael Niedermayer 07master:ea4b477a1b3c: Merge commit 'f7e85ee996b3886c2b13e928b83277382311af96' [17:09] <cone-469> ffmpeg.git 03Michael Niedermayer 07master:d08dd3286369: avcodec/mpegvideo_enc: disable direct mode in load_input_picture() for dimensions%16 != 0 [17:16] <cone-469> ffmpeg.git 03Anton Khirnov 07master:024db24912a3: mpegvideo: allocate edges when encoding. [17:16] <cone-469> ffmpeg.git 03Michael Niedermayer 07master:d83707c64197: Merge commit '024db24912a39316b0ef0b7d793307d62da038f4' [18:52] <cone-469> ffmpeg.git 03Michael Niedermayer 07master:7c6cf689d825: avcodec/diracdec: allocate edges internally instead of depending on CODEC_FLAG_EMU_EDGE being not set [18:52] <cone-469> ffmpeg.git 03Michael Niedermayer 07master:6ba02602aa7f: avcodec/vmnc: Check that rectangles are within the picture [18:52] <cone-469> ffmpeg.git 03Michael Niedermayer 07master:723e7b86ea4d: avcodec/jpeg2000dec: calculate planar and pixelsize from pixel format descriptor [18:52] <cone-469> ffmpeg.git 03Michael Niedermayer 07master:8001e9f7d17e: avcodec/jpeg2000dec: fix error detection in pix_fmt_match() [19:37] <BBB> michaelni: yeah that would be nice [19:38] <BBB> Daemon404: I don't care much for names; vp8 intra pred is called h264_intrapred and I couldn't care less [19:39] <BBB> Daemon404: functionality speaks for itself, but it should not be functionally dependent on irrelevant things, e.g. making vp8 decoding on ffh264dec is ridiculous; likewise, making huffyuv decoding dependent on mpeg encoding dsp utilities and motion search is beyond me [19:54] <cone-469> ffmpeg.git 03Anton Khirnov 07master:93c553c71ef4: lavc: deprecate CODEC_FLAG_EMU_EDGE and avcodec_get_edge_width(). [19:54] <cone-469> ffmpeg.git 03Michael Niedermayer 07master:eef74b2e9713: Merge remote-tracking branch 'qatar/master' [20:02] <BBB> ubitux: 4x4/8x8 iadst working patches on my github, will do time measurements and send patches to ML sometime soon [20:06] <cone-469> ffmpeg.git 03Carl Eugen Hoyos 07master:c892621577b3: Fix compilation with --disable-hwaccel=mpeg1_xvmc,mpeg2_xvmc [20:06] <cone-469> ffmpeg.git 03Carl Eugen Hoyos 07master:9b78abae19aa: Add h263dsp dependency to mpeg1video and mpeg2video encoders. [20:06] <cone-469> ffmpeg.git 03Carl Eugen Hoyos 07master:b7702fafb356: Avoid a possible overflow when reading Nikon avi files. [20:06] <cone-469> ffmpeg.git 03Michael Niedermayer 07master:78e39aa7ee12: Merge remote-tracking branch 'cehoyos/master' [21:14] <llogan> BadContent uses the python syntax for regex if anyone was wondering: http://trac.edgewall.org/wiki/SpamFilter#RegularExpressions [21:14] <Daemon404> does python use PCRE? [21:14] Action: Daemon404 cannot remember [21:15] <llogan> i'm not sure [21:15] <Daemon404> doesnt seem like its pcre [21:16] <Daemon404> there are modules to do pcre though [21:33] <cone-469> ffmpeg.git 03Michael Niedermayer 07master:f70d7eb20c1d: Move add/diff_int16 to lossless_videodsp [21:34] <michaelni> llogan, thanks, btw can we add a link to that to the badcontent page itself ? [21:34] <michaelni> or note or something, so people edting the page know [21:39] <llogan> michaelni: i'm not sure how to provide content within the page without it being parsed [21:41] <llogan> (?#foo) i guess. [21:46] <llogan> is it case sensitive? i think it is because I don't see re.I or re.IGNORECASE in regex.py, but i don't know what i'm doing... [21:47] <llogan> "it" being BadContent [21:55] <michaelni> llogan, maybe it doesnt parse the stuff outside {{{}}} [22:18] <rcombs> https://trac.ffmpeg.org/ticket/3207 <-- libass is strongly considering removing support for Format: lines in ASS files; this will break ffmpeg's current output [22:19] <wm4> note that ffmpeg is definitely outputting broken files here [22:20] <wm4> so libass would actually do ffmpeg a favor [22:20] <nevcairiel> i think that statement is misleading though, "Format: lines" isnt the problem, its ffmpegs incomplete version of the same, the corrected variant still has "Format:" lines [22:21] <wm4> yes, an ass parser still needs to distinguish SSA and ASS [22:21] <nevcairiel> although it seems stupid to enforce a fixed field header list if the format even has an extra line to define wh ich fields are present [22:21] <nevcairiel> but then, its ASS [22:21] <nevcairiel> one of the S has to be for Stupid [22:22] <Plorkyeran> from the vsfilter-is-the-spec perspective, the format doesn't have a line to specify which fields are present [22:22] <Plorkyeran> people just put an invalid line in files~ [22:23] <wm4> nevcairiel: SSA was actually a visual basic program, so, yeah [22:23] <rcombs> nevcairiel: yeah, the format is quite awful [22:24] <nevcairiel> i wonder if someone will ever come up with a new one [22:24] <ubitux> webvtt to the rescue! [22:24] Action: ubitux runs away [22:24] <nevcairiel> probably impossible to convince anyone to use it without extreme development efforts beforehand [22:24] <rcombs> nevcairiel: I have some plans for ASSv5, but that can't really happen until VSFilter loses usage share [22:24] <nevcairiel> but developers wont pick it up without actual use [22:24] <nevcairiel> so you are screwed! [22:24] <JEEB> nielsm has gotten most of the general stuff written down for AS6, but he needs the text rendering side to be properly spec'd [22:24] <JEEB> and he can't do it by himself [22:24] <wm4> rcombs: so, what's next? fontconfig-free libass on windows? an official libass dshow filter? [22:25] <rcombs> wm4: DirectWrite and CoreText font selection on Windows and OSX is probably top priority after the current batch of speed improvements [22:25] <wm4> CoreText is already implemented, but not merged for some reason [22:26] <nevcairiel> finishing the removal of fontconfig would be a great step, i might join into any directshow efforts afterwards [22:26] <rcombs> probably due to insufficient testing [22:26] <JEEB> fontconfig'less libass would indeed get us to the main point of replacing vsfilter [22:26] <rcombs> nevcairiel: well it's got to stick around for Linux [22:26] <nevcairiel> well sure [22:26] <nevcairiel> on linux it actually works [22:26] <wm4> somewhat [22:27] <nevcairiel> on windows you either look at a loading bar that caches all fonts, or you get the standard font :p [22:28] <wm4> I think the main problem was that libass wants to use freetype to rasterize, but you can't get the font data from windows [22:32] <rcombs> wm4: can't you? [22:32] <wm4> no because someone might steal the fonts [22:33] <rcombs> :| [22:34] <Plorkyeran> you can get the raw font data if the font is flagged to let you [22:34] <Plorkyeran> which many are [22:35] <Plorkyeran> it's basically honor-system drm [22:35] <rcombs> how's fontconfig's speed on Windows when you don't pass in a config file? [22:35] <rcombs> (i.e. only memory fonts) [22:35] <Plorkyeran> you still need a config file [22:36] <Plorkyeran> if you don't index very many fonts, then obviously indexing will not take very long [22:36] <rcombs> if you don't pass one it tries to load a default; if it can't find a default one it doesn't load any system fonts [22:36] <Plorkyeran> the config file is used for a lot more than telling it what directories to index [22:36] <nevcairiel> but what good will not having any fonts do :d [22:37] <rcombs> nevcairiel: still can get fonts attached to an MKV, which is libass's primary use case [22:38] <nevcairiel> could it even draw at all if it has no mkv font? [22:39] <rcombs> libass accepts a default font path [22:39] <nevcairiel> or would it fail because it doesnt know any font at all [22:39] <rcombs> which I believe is required(?) [22:41] <nevcairiel> in any case, integrating directly with windows font APIs is the only real solution, even assuming mkvs have fonts would require a rather tight integration of the mkv reader with the subtitle renderer, which many players may not have, especially if they use vsfilter today and the idea is to replace that [22:41] <cone-469> ffmpeg.git 03Michael Niedermayer 07release/1.2:b902ba478c81: avcodec/mjpegdec: Dont skip picture allocation if theres no picture allocated [22:41] <cone-469> ffmpeg.git 03Carl Eugen Hoyos 07release/1.2:4fdcb1e1b7b1: Allow decoding of slightly broken Nikon avi files. [22:41] <cone-469> ffmpeg.git 03Michael Niedermayer 07release/2.1:30a94f1159d4: avcodec/mjpegdec: Dont skip picture allocation if theres no picture allocated [22:41] <cone-469> ffmpeg.git 03Nicolas George 07release/2.1:fc5261c21905: lavfi/dualinput: fix shortest option. [22:41] <cone-469> ffmpeg.git 03Carl Eugen Hoyos 07release/2.1:ee3822af631c: Allow decoding of slightly broken Nikon avi files. [22:43] <rcombs> back to the present, can we get that Format: issue fixed? [22:44] <wm4> rcombs: ubitux is the subtitle guy (although he doesn't want to be) [22:44] <rcombs> it's most likely not very complicated, so I'll write a patch if need be [22:44] <ubitux> i'm honestly not in the mood to look at this currently... [22:44] <ubitux> please do :) [22:45] <nevcairiel> it would seem pretty easy to fix, just adding a bunch more fields with default values to the printout [22:45] <wm4> rcombs: I could look into it too [22:46] <rcombs> oh, yeah, this is really simple, actually [22:46] <wm4> is it? the hard part is probably fixing FATE tests, then [22:46] <ubitux> the fields are parsed in various places [22:46] <ubitux> for the convert nightmare with internal representation and shit [22:47] <wm4> shouldn't the internals be able to deal with any format header? [22:47] <ubitux> dunno [22:47] <ubitux> i tend to forget how this works every time [22:48] <rcombs> I don't have to touch parsing [22:48] <rcombs> just writing [22:48] <rcombs> parser already handles pretty much everything pretty well [22:49] <rcombs> "standard ASS escaping so random characters don't get mis-interpreted as ASS" <-- except that ASS doesn't have escaping :| [22:50] <wm4> libass supports \{ or so [22:50] <wm4> but vsfilter doesn't [22:50] <rcombs> wm4: does it, though? [22:54] <rcombs> hmm, would we want to kill ASS encoding in at this point? (SSA-only?) [22:54] <ubitux> no? [22:54] <rcombs> does it have any real use-case? [22:55] <ubitux> standalone files? [22:55] <rcombs> when do you need a standalone SSA file and an ASS file wouldn't do? [22:55] <llogan> the only webvtt i've seen in the wild was for JW Player [22:55] <ubitux> we assume ssa is for muxed formats [22:55] <ubitux> and ass is for standalone [22:55] <rcombs> when did we get to talking about WebVTT? [22:56] <llogan> 31 mins ago [22:56] <rcombs> oh, hah, your nicks are colored the same and I derped [22:56] <llogan> i'm late to the party as usual [22:57] <wm4> <ubitux> we assume ssa is for muxed formats <- wait what [22:57] <rcombs> ubitux: I haven't seen SSA in the wild in quite some time [22:57] <wm4> I guess you _can_ mux ssa into mkv [22:57] <wm4> but should you? [22:57] <rcombs> and I can't think of a single modern setup that'd parse SSA but not ASS [22:58] <rcombs> wm4: are ffmpeg's SSA output files pseudo-invalid, or just the ASS? [22:58] <ubitux> well, ffmpeg is using those 2 names for the distinction [22:58] <wm4> oh [22:58] <rcombs> ubitux: in parsing, though, not encoding [22:59] <wm4> ubitux: so by SSA, you mean the format with timestamps embedded? [22:59] <ubitux> that one is "ass" [22:59] <j-b> good morning folks [22:59] <wm4> now I'm confused [22:59] <ubitux> "ssa" is without timestamps [23:00] <nevcairiel> thats just the FFmpeg interpretation though, isnt it [23:00] <wm4> my code seems to think that "ssa" is with timestamps [23:00] <wm4> in the packet data itself [23:00] <wm4> while "ass" is matroska style packets [23:01] <llogan> j-b: greetings [23:01] <rcombs> while in actuality, SSA vs. ASS has nothing to do with timestamp presence [23:01] <rcombs> so that sounds like just a naming issue/ [23:01] <wm4> rcombs: ffmpeg used ssa as codec id for ass [23:02] <nevcairiel> its just mkv version vs standalone version for FFmpeg [23:02] <wm4> rcombs: and when the internal packet format was fixed (no more embedded timestamps), an "ass" codec id was introduced [23:02] <ubitux> yeah there are some history to avoid breaking the api [23:02] <rcombs> wm4: that's almost VSFilter-level ridiculousness [23:02] <ubitux> that's called compatibility [23:02] <wm4> well, the "ssa" codec id is supposed to go away one day [23:03] <ubitux> wm4: not so sure about that but well [23:03] <wm4> not? [23:03] <cone-469> ffmpeg.git 03Michael Niedermayer 07master:f9c7b14c040f: avcdoec/huffyuvenc: optimize sub_left_prediction() [23:03] <cone-469> ffmpeg.git 03Michael Niedermayer 07master:883570e6b70a: Move add_hfyu_left_prediction_int16 to losslessviddsp [23:03] <cone-469> ffmpeg.git 03Michael Niedermayer 07master:13c33c8e1f68: Move add_hfyu_median_prediction_int16() to losslessviddsp [23:03] <cone-469> ffmpeg.git 03Michael Niedermayer 07master:d9779d648e82: Move sub_hfyu_median_prediction_int16() to losslessviddsp [23:06] <llogan> michaelni: ah, good point. i asked on #trac since i couldn't figure it out. i'll let you know what they say, if anything [23:07] <ubitux> wm4: it not that trivial to store what the ass demuxer outputs [23:07] <ubitux> into "ssa" [23:14] <Plorkyeran> rcombs> and I can't think of a single modern setup that'd parse SSA but not ASS <-- there's a few programs that only support SSA [23:14] <BBB> ubitux: work for you :) (ML) [23:14] <ubitux> :) [23:14] <Plorkyeran> the popular choice for making DVD subs that I don't remember the name of is one [23:14] <rcombs> Plorkyeran: having heard more about this, it doesn't look like ffmpeg actually supports writing SSA at all [23:15] <Plorkyeran> yeah, p. sure it doesn't [23:15] <rcombs> it apparently uses "SSA" and "ASS" to refer to ASS with and without timestamps inline [23:15] <rcombs> for hysterical raisins [23:16] <rcombs> also, this stuff is so convoluted I'm not going to try to touch it right now [23:16] <ubitux> rcombs: see 7c1a002c78f15470f76d5c03e619b954d1a22839 [23:17] <rcombs> ubitux: I probably would have transparently converted MKV-formatted ASS to actual ASS while demuxing [23:17] <rcombs> or, it looks like that's what did happen? [23:18] <ubitux> yeah, and that was freaking ugly and broken [23:18] <ubitux> and causing a lot of troubles [23:18] <BBB> michaelni: ty [23:18] <ubitux> BBB: i'll have a look, but probably not today [23:18] <BBB> ubitux: np [23:19] <rcombs> what was ugly and broken about it? [23:20] <ubitux> players would get ass lines with timestamps out of mkv demuxer [23:20] <ubitux> which libass partially supports with a chunk hack [23:21] <ubitux> the layout is not the same [23:21] <BBB> iwht4 pending I s'pose [23:21] <BBB> let me work on that [23:21] <ubitux> rcombs: basically, no more "readorder" or "layer" field [23:21] <rcombs> layers are important! [23:22] <ubitux> but instead a freaking timestamps which can't be altered easily [23:22] <ubitux> (extracting a sample out of a mkv keeping timestamps relevant wasn't possible) [23:22] <ubitux> that kind of nastiness [23:22] <rcombs> guh [23:22] <rcombs> probably the worst bit of all of this is the naming, really [23:23] <ubitux> codec is was "ssa" [23:23] <ubitux> i named what goes out of mkv "ass" to make a difference [23:23] <rcombs> welp, I'm going to step back and hope this gets resolved eventually [23:24] <ubitux> :) [23:24] <ubitux> awesome isn't it? [23:24] <ubitux> also, we can't really improve the api [23:24] <rcombs> might just say that the next point release (after the one we're hoping to put out this week) will remove Format: lines and that programs which write the format had better fix them by then [23:24] <ubitux> particularly because the fork won't follow it [23:25] <ubitux> rcombs: that's not an easy situation as you can see [23:25] <ubitux> also, i'm not that familiar enough with ASS/SSA [23:25] <rcombs> ubitux: it looks like it should, in theory, just be a matter of adding the additional values at defaults in each line and in the format line [23:25] <ubitux> and the misc implementations.. [23:25] <ubitux> as you can see [23:25] <ubitux> that's not trivial :) [23:25] <ubitux> otherwise you would have already fixed it [23:26] <rcombs> it's only non-trivial for me because the source has all this ASS/SSA weirdness [23:26] <rcombs> I'd expect someone who knows more about all all this is meant to fit together would know where the extra bits need to go [23:26] <ubitux> decoded subs still has the timestamps shit... [23:26] <ubitux> because if we change that, it breaks everything [23:26] <rcombs> sure, that shouldn't be affected [23:26] <ubitux> (for api users) [23:27] <rcombs> the extra stuff that needs to be added should all be after the timestamps [23:27] <ubitux> rcombs: yes, but this "decoded" form is somehow reused [23:27] <ubitux> sometimes with a straight copy [23:27] <wm4> ubitux: didn't mkv already break for api users [23:27] <ubitux> wm4: nope [23:27] <wm4> because it outputs ass not ssa now [23:27] <ubitux> i kept compatibility... [23:28] <wm4> huh [23:28] <ubitux> wm4: you had to force the flag for a while [23:28] <ubitux> not true anymore though [23:28] <ubitux> i don't remember if you can still request ssa [23:28] <ubitux> but basically yes it's a different codec id, which you can just send directly to libass now [23:33] <ubitux> wm4: i confirm you can still request AV_CODEC_ID_SSA [23:34] <wm4> how? [23:34] <ubitux> don't remember how to do that with the api [23:34] <ubitux> it's also probably still the default mmh [23:34] <saste> what? [23:35] <ubitux> SSA is still up in the list [23:35] <ubitux> SSA is above ASS, so it should be raised first [23:35] <saste> ah subtitles... [23:35] <wm4> rcombs: maybe it would be better to leave the old code for now, and do optimized parsing for ASS only [23:36] <rcombs> wm4: can we stop using the terms "ASS" and "SSA" in here? [23:36] <wm4> well, "real" ASS, not ffmpeg style ASS or SSA [23:36] <ubitux> :D [23:36] <wm4> rcombs: using their true meaning [23:36] <rcombs> I can never tell if people mean SubStation Alpha vs. Advanced Substation, or this codec ID insanity [23:36] <rcombs> wm4: can we do that? [23:36] <rcombs> without breaking everything? [23:37] <wm4> rcombs: we just leave process_event_tail and use it for anything that isn't modern ASS [23:38] <rcombs> and "modern ASS" == Aegisub's output, but not ffmpeg's? [23:38] <wm4> yes [23:38] <rcombs> sounds workable to me [23:39] <wm4> I think I can write a patch (for libass) [23:39] <rcombs> cool, let's bring this conversation back to #libass then [00:00] --- Tue Jan 21 2014