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

[burek]

[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