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

[burek]

[00:10:11 CEST] <cone-428> ffmpeg 03Christophe Gisquet 07master:79cfb36f92bd: dnxhddata: introduce and use MBAFF flag
[01:37:36 CEST] <cone-428> ffmpeg 03Christophe Gisquet 07master:5911eeb033c3: dnxhdenc: mark CID 1260 encoder experimental
[01:38:16 CEST] <rcombs> so, trying to work out why my bsf patch screws with timestamps
[01:41:56 CEST] <rcombs> this means use of `-v trace` which is not that fun
[02:19:14 CEST] <andrelec1> JEEB are your still here ?
[02:19:45 CEST] <andrelec1> i didn't understand how is work
[02:19:55 CEST] <andrelec1> do you have simple tutorial ?
[02:20:05 CEST] <andrelec1> i read http://dranger.com/ffmpeg/ffmpegtutorial_all.html#tutorial01.html
[02:20:13 CEST] <andrelec1> but its realy old tuto 
[02:21:08 CEST] <andrelec1> he use av_open_input_file( but it deprecated now ... i try to read ce exemple but its realy complicate for me
[02:42:48 CEST] <rcombs> seems fate-ffm is broken?
[02:46:14 CEST] <rcombs> uh&
[02:46:29 CEST] <rcombs> the test passes when I run `make -j10 fate` but not on `make fate-lavf-ffm`
[02:46:44 CEST] <rcombs> also fails on fate-lavf
[02:52:36 CEST] <BBB> thats not good
[02:53:41 CEST] <jamrial> it's failing for me no matter how i run the test
[02:54:07 CEST] <jamrial> odd that no fate client is showing this
[02:58:02 CEST] <BBB> it seems removed from fate
[02:58:37 CEST] <jamrial> it's fate-lavf-ffm
[02:59:42 CEST] <BBB> I have no idea :)
[03:00:21 CEST] <rcombs> it's in tests/lavf-regression.sh
[03:23:10 CEST] <rcombs> uh
[03:23:20 CEST] <rcombs> affect, `make fate` generates the same file as `make fate-lavf-ffm`
[03:23:30 CEST] <rcombs> but `make fate` succeeds
[03:23:37 CEST] <rcombs> or, well, at least it passes that test
[04:53:15 CEST] <rcombs> new pile of auto-bsf patches
[07:41:41 CEST] <kurosu> what's the procedure to upload new samples to fate? (won't read the answer nor do it until 12h from now)
[07:44:00 CEST] <nevcairiel> kurosu: "procedure"? just do it. :) if you dont have access, i can upload it for you
[07:44:46 CEST] <kurosu> nevcairiel, I don't even know if I have access, to what
[07:44:48 CEST] <kurosu> so yeah
[07:46:16 CEST] <kurosu> nevcairiel, can I send them to h.leppkes@ (not even sure dcc works on that client...)
[07:46:28 CEST] <nevcairiel> sure
[07:46:31 CEST] <kurosu> thanks
[07:51:02 CEST] <nevcairiel> kurosu: done
[07:51:26 CEST] <kurosu> nevcairiel, thanks
[07:52:01 CEST] <kurosu> won't matter until the 2 fate tests are ok'ed and added, but that'll give time for the samples to replicate over fate instances
[07:52:16 CEST] <nevcairiel> thats not really something we generally worry about much
[07:52:18 CEST] <nevcairiel> but yeah
[11:02:29 CEST] <saste> is it fine to drop options based on the major version bump?
[11:03:01 CEST] <saste> this is what i suggested for the delogo patch, but now I can't find instances doing that
[11:29:22 CEST] <cone-455> ffmpeg 03Jean Delvare 07master:8bc708fcee13: avfilter/delogo: Set default band to 1
[11:37:32 CEST] <iive> saste: can you find an instance where an option is dropped?
[11:38:07 CEST] <iive> saste: imho, removing stuff is ok on major bumps.
[11:40:07 CEST] <nevcairiel> ideally stuff is deprecated before removal, but deprecating options is not very straight forward
[11:40:08 CEST] <nevcairiel> so shrug
[11:45:21 CEST] <wm4> maybe we could have an AVOption deprecation flag
[11:45:38 CEST] <wm4> then any code handling the setting of AVOptions could print a warning
[12:11:40 CEST] <saste> nevcairiel, iive, wm4: all good ideas, though probably for a single option they are overkill
[12:12:24 CEST] <saste> wm4, if we see a common pattern then we could add an option flag about deprecation
[12:20:46 CEST] <nevcairiel> saste: the delogo patch you pushed seems to break fate
[12:26:59 CEST] <saste> nevcairiel, going to fix it
[12:27:18 CEST] <saste> forgot to update the logo test
[12:27:55 CEST] <durandal_1707> how to interleave words from 2 registers?
[12:29:57 CEST] <nevcairiel> PUNPCKLWD/PUNPCKHWD
[12:31:17 CEST] <nevcairiel> those exist for all kind of word size, from 8 to 64 bits
[12:31:54 CEST] <durandal_1707> from AAAA:BBBB to ABAB:ABAB
[12:32:42 CEST] <nevcairiel> i'm sure there is a macro for that sort of thing, it seems common
[12:33:12 CEST] <nevcairiel> but essentially its just punpcklwd and punpckhwd to process half a reg at a time
[12:34:09 CEST] <nevcairiel> looks like SBUTTERFLY is the macro you want
[12:35:46 CEST] <nevcairiel> SBUTTERLY wd, in1, in2, tmp
[12:43:31 CEST] <nevcairiel> kurosu: i ran into that problem as well recently, when i was trying to build a new test tool .. it never seemed to recompile when i did changes to a header, but i couldnt be bothered to find out why :(
[12:47:06 CEST] <cone-455> ffmpeg 03Stefano Sabatini 07master:329465235a17: tests: update fate-filter-delogo test reference after commit 8bc708fcee137ead6d0773fad8e24ab471ab2122
[13:33:50 CEST] <BBB> kurosu: nice patchset :)
[13:42:32 CEST] <durandal_1707> BBB: i dont get how to use BUTTERFLY with odd number of coefficients for simple_high filter in w3fdif
[14:03:45 CEST] <BBB> durandal_1707: butterfly + pmaddwd assumes even, so just use zero for the last input data or coefficient
[14:03:53 CEST] <BBB> (and the other can be uninitialized)
[14:03:58 CEST] <BBB> (or itself)
[14:35:01 CEST] <cone-455> ffmpeg 03Michael Niedermayer 07release/2.8:a3db85581eda: MAINTAINERS: add 2.8, drop 2.2
[14:35:02 CEST] <cone-455> ffmpeg 03Michael Niedermayer 07release/2.8:08fc0d771a59: avcodec/mjpegdec: Fix decoding RGBA RCT LJPEG
[14:35:03 CEST] <cone-455> ffmpeg 03Michael Niedermayer 07release/2.8:9801c9524a93: swscale/swscale: Fix "unused variable" warning
[14:35:04 CEST] <cone-455> ffmpeg 03Simon Thelen 07release/2.8:9bbcd1cc7b19: lavf/webvttenc: Require webvtt file to contain exactly one WebVTT stream.
[14:35:05 CEST] <cone-455> ffmpeg 03Ganesh Ajjanagadde 07release/2.8:3fedd64d4b4a: avutil/log: fix zero length gnu_printf format string warning
[14:35:06 CEST] <cone-455> ffmpeg 03Michael Niedermayer 07release/2.8:2a6103a0820e: cmdutils: Filter dst/srcw/h
[14:35:07 CEST] <cone-455> ffmpeg 03Pedro Arthur 07release/2.8:a8d0dcbafade: swscale: fix ticket 4850 (cherry picked from commit 77367f61b38dbdf17c31aa6a6b3edccb2ebf5354)
[14:35:08 CEST] <cone-455> ffmpeg 03Michael Niedermayer 07release/2.8:d4b1fe72c24c: avcodec/ffv1: seperate slice_count from max_slice_count
[14:35:09 CEST] <cone-455> ffmpeg 03Michael Niedermayer 07release/2.8:3cd1be970203: avcodec/rangecoder: Check e
[14:35:10 CEST] <cone-455> ffmpeg 03Pedro Arthur 07release/2.8:01bf0a178d90: swscale: fix ticket #4877 (cherry picked from commit a8602dde5e0a9858b9cee7e3788bef8efc43d950)
[14:35:11 CEST] <cone-455> ffmpeg 03Christophe Gisquet 07release/2.8:f5f9c166a1b4: dnxhddec: decode and use interlace mb flag
[14:35:12 CEST] <cone-455> ffmpeg 03Jeremy James 07release/2.8:61fd5a307247: dnxhddata: correct weight tables
[14:35:13 CEST] <cone-455> ffmpeg 03Michael Niedermayer 07release/2.8:97340bdfa391: avcodec/ffv1dec: Explicitly check read_quant_table() return value
[14:35:14 CEST] <cone-455> ffmpeg 03Michael Niedermayer 07release/2.8:837113ab5fff: avcodec/ffv1dec: Fix off by 1 error in quant_table_count check
[14:35:15 CEST] <cone-455> ffmpeg 03Michael Niedermayer 07release/2.8:818ebcbf5c52: avcodec/x86/sbrdsp: Fix using uninitialized upper 32bit of noise
[14:35:16 CEST] <cone-455> ffmpeg 03DHE 07release/2.8:83d75c70df2e: libavformat/hlsenc: Use of uninitialized memory unlinking old files
[14:35:17 CEST] <cone-455> ffmpeg 03Andrey Utkin 07release/2.8:6dcd2ebd34b6: avformat/httpauth: Add space after commas in HTTP/RTSP auth header
[14:35:18 CEST] <cone-455> ffmpeg 03Shivraj Patil 07release/2.8:7236080d2721: avcodec/mips: build fix for MSA
[14:35:19 CEST] <cone-455> ffmpeg 03Shivraj Patil 07release/2.8:a931ad554d0d: avcodec/mips: build fix for MSA 64bit
[14:41:54 CEST] <BBB> durandal_1707: ah, I see youre liking pmaddwd
[14:42:03 CEST] <BBB> thats a great life choice
[14:42:20 CEST] <iive> everybody loves pmaddwd
[14:42:47 CEST] <BBB> that sounds hippie
[14:42:54 CEST] <BBB> \o/
[14:43:02 CEST] <BBB> leeeeeet the suuuuun shiiiiiiine
[14:43:28 CEST] <BBB> pee-em-adddddddddd-double-you-deeeeeeee
[14:43:34 CEST] <BBB> \o/
[14:43:39 CEST] <ubitux> ._.
[14:43:54 CEST] <BBB> too much?
[14:43:58 CEST] <iive> i was referring to "Everybody Loves Raymond" 
[14:44:16 CEST] <iive> :)
[14:44:30 CEST] <BBB> oh I see
[14:48:31 CEST] <ubitux> michaelni: can you pick d161a2a72b083c51ec8fad33a29283703f5fd0cc and 7218352e0228028dfa009a3799ec93fd041065f1 ?
[14:54:57 CEST] <ubitux> and maybe a47ad06baf6c0db6d47a5531d6d4ee0511f44eac ?
[15:09:44 CEST] <RiCON> https://www.ffmpeg.org/doxygen/2.8/ass_8c.html#a13807a12939104c4f5c08906973ea804
[15:09:54 CEST] <RiCON> am i misreading or does it say it's the same as itself?
[15:16:30 CEST] <wm4> RiCON: yeah, makes no sense
[15:18:31 CEST] <ubitux> hey, 2 questions
[15:19:01 CEST] <ubitux> 1. does it sound safe to call av_read_frame() after EOF? (and expect EOF again)
[15:19:15 CEST] <wm4> ubitux: 1. yes
[15:19:48 CEST] <ubitux> 2. is there a more correct way than checking frame->buf[0] to check if the frame is in "holder" mode?
[15:20:13 CEST] <wm4> what mode
[15:20:39 CEST] <nevcairiel> I think he means is refcounted
[15:20:40 CEST] <ubitux> like, no data, just after a av_frame_alloc() or post-unref
[15:20:50 CEST] <nevcairiel> Oh
[15:21:32 CEST] <ubitux> i also wonder how the frame is going to like av_frame_unref() several time on an av_frame_alloc() before doing some stuff with it
[15:21:47 CEST] <ubitux> s/on an/after a/
[15:22:01 CEST] <ubitux> i expect it to be safe but... :)
[15:22:58 CEST] <nevcairiel> Double unrefs are safe
[15:44:25 CEST] <Daemon404> nevcairiel, whats the status of the pthread emulation?
[15:44:27 CEST] <Daemon404> i sort of lost trck
[15:44:29 CEST] <Daemon404> track*
[15:48:57 CEST] <nevcairiel> I thought Luca wanted to push the latest version
[15:52:37 CEST] <nevcairiel> I kinda figured I would just merge it then
[15:52:52 CEST] <nevcairiel> But I can push it if you are getting restless :p
[16:14:46 CEST] <Daemon404> is it in the silly "patch queue"
[16:15:56 CEST] <RiCON> ubitux: how's http://sprunge.us/gKBj?diff
[16:16:17 CEST] <ubitux> mmh as i said, rcombs has a patchset for that
[16:16:36 CEST] <RiCON> oh, didn't read
[16:17:01 CEST] <ubitux> mmh but maybe that's the other way around
[16:17:44 CEST] <ubitux> i was thinking of http://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/178681.html
[16:17:55 CEST] <ubitux> ...and http://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/178683.html
[16:17:57 CEST] <ubitux> but actually
[16:18:18 CEST] <RiCON> he has one for vttenc
[16:18:33 CEST] <ubitux> yeah
[16:18:40 CEST] <ubitux> it's for the enc so my bad
[16:18:43 CEST] <ubitux> let me check your patch
[16:19:17 CEST] <ubitux> RiCON: you don't want this in srt as well btw?
[16:19:31 CEST] <RiCON> only vtt has those, afaik
[16:19:48 CEST] <ubitux> ok, hopefully :)
[16:20:57 CEST] <RiCON> hm the first commit probably doesn't work as expected (with "{"
[16:22:18 CEST] <ubitux> RiCON: why didin't you add the pattern to webvtt_tag_replace?
[16:22:48 CEST] <RiCON> only worked on odd times
[16:23:06 CEST] <RiCON> >> -> >>
[16:23:25 CEST] <RiCON> same as tags
[16:23:39 CEST] <ubitux> replace the first break with a "continue"
[16:23:48 CEST] <ubitux> in the first function
[16:24:01 CEST] <ubitux> (and drop your first patch)
[16:24:21 CEST] <ubitux> and move your tags in webvtt_tag_replcae
[16:24:46 CEST] <RiCON> what about the lrm/rlm entities?
[16:24:49 CEST] <RiCON> keep as is?
[16:24:58 CEST] <cone-455> ffmpeg 03Clément BSsch 07release/2.8:1d9d300d6514: avformat/srtdec: fix number check for the first character (cherry picked from commit d161a2a72b083c51ec8fad33a29283703f5fd0cc)
[16:24:59 CEST] <cone-455> ffmpeg 03Clément BSsch 07release/2.8:64b659673a1c: avformat/srtdec: more lenient first line probing
[16:25:00 CEST] <cone-455> ffmpeg 03wm4 07release/2.8:eca7b0dccece: avformat/vobsub: compare correct packet stream IDs
[16:26:32 CEST] <ubitux> ohgodno :(
[16:26:54 CEST] <ubitux> yeah you can keep them i guess, with a FIXME "honor properly"
[16:26:57 CEST] <RiCON> hm, still doesn't work with adjacent replacements
[16:27:06 CEST] <ubitux> or maybe add a special case for any unsupported &something;
[16:27:15 CEST] <ubitux> can you show the full diff?
[16:27:37 CEST] <ubitux> ah wait yeah
[16:27:41 CEST] <ubitux> you must continue the first loop
[16:27:58 CEST] <ubitux> like, go back to the while (*p)
[16:28:03 CEST] <ubitux> add a state bool or sth
[16:29:12 CEST] <ubitux> michaelni: thx
[16:31:41 CEST] <ubitux> RiCON: untested but sth along these lines http://pastie.org/10468250
[16:32:09 CEST] <cone-455> ffmpeg 03Ganesh Ajjanagadde 07master:1460719153e5: doc/writing_filters: miscellaneous grammar and typo fixes
[16:32:10 CEST] <cone-455> ffmpeg 03Ganesh Ajjanagadde 07master:079d553b9e61: configure: add message to avoid manual modification of config.texi
[16:32:15 CEST] <ubitux> (you can keep the break)
[16:44:44 CEST] <RiCON> ah, finally worked
[16:44:58 CEST] <RiCON> had to add "skip = 0" to the again if as well
[17:09:33 CEST] <wm4> so it looks like thanks to durandal_1707 w3fdif=simple is going to be much faster than yadif
[17:09:53 CEST] <nevcairiel> complex as well, apparently
[17:10:01 CEST] <nevcairiel> and w3fdif is also slice threaded already
[17:10:03 CEST] <nevcairiel> might be interesting
[17:10:20 CEST] <nevcairiel> someone should get soem videophools on a quality comparison
[17:10:39 CEST] <nevcairiel> maybe i'll just add it as an option in my code and wait for someone to test it
[17:17:28 CEST] <wm4> heh
[17:26:31 CEST] <durandal_1707> is there instrucction that only move words?
[17:55:59 CEST] <RiCON> ubitux: not sure if i should convert nbsp to \h or plain space
[17:57:23 CEST] <RiCON> both vsfilter and libass should interpret \h as non-breaking space, even in .srt
[17:58:16 CEST] <nevcairiel> Let's try to not build around some implementations in an otherwise rather simple format
[17:58:35 CEST] <RiCON> just plain space then
[17:58:38 CEST] <nevcairiel> Clearly Unicode nbsp
[17:59:06 CEST] <RiCON> how do you write that? \x2c\xao?
[17:59:23 CEST] <RiCON> \x2c\xa0*
[17:59:27 CEST] <nevcairiel> I don't know its code offhand
[17:59:41 CEST] <nevcairiel> But if that's it, then yes
[18:00:33 CEST] <nevcairiel> Normal space may work fine, I was only being half serious
[18:08:29 CEST] <RiCON> hm, mpv thinks the vtt is srt so it's not converting
[18:08:30 CEST] <RiCON> welp
[18:09:08 CEST] <Daemon404> how is that even possible
[18:09:13 CEST] <Daemon404> vtt must start with "WEBVTT"
[18:09:27 CEST] <RiCON> probably because the url doesn't end in .vtt
[18:09:41 CEST] <RiCON> if i download the vtt beforehand it works
[18:09:47 CEST] <Daemon404> lulz
[18:10:13 CEST] <wm4> lavf rarely checks the file extension
[18:14:55 CEST] <RiCON> "[subreader] Detected subtitle file format: subrip"
[18:17:10 CEST] <RiCON> i'll submit the patch anyway
[18:18:29 CEST] <Daemon404> why did i go and look at demux_subreader.c
[18:18:31 CEST] <Daemon404> D:
[18:18:48 CEST] <Compn> probably based on mplayer code...
[18:18:59 CEST] <Daemon404>  * Copyright (c) 2001 laaz
[18:19:06 CEST] <Compn> wow, thats some early code
[18:19:47 CEST] <Compn> yes, laaz was a hungarian and he did mplayer subreader.c
[18:20:36 CEST] <Daemon404> is it important to know he was hungarian
[18:21:30 CEST] <Daemon404> ... mpv uses talloc... or some bits do
[18:22:36 CEST] <Compn> it was part of the information that i found when i looked up who laaz was. is it important in this context? no.
[18:24:00 CEST] <wm4> RiCON: ah, fun
[18:24:06 CEST] <wm4> it's for Libav
[18:24:28 CEST] <wm4> it doesn't support anything ffmpeg doesn't
[18:25:16 CEST] <wm4> Daemon404: the original file is actually much worse
[18:54:02 CEST] <Compn> Megyer, László (Lez, Laaz) <laszlo.megyer at gmail.com>
[18:54:09 CEST] <Compn> if someone wants to update the copyright in the file in ffmpeg...
[18:54:28 CEST] <Compn> iirc j-b hates files with nicknames as copyright ;P
[18:58:39 CEST] <Daemon404> Compn, 
[18:58:45 CEST] <Daemon404> most of mpv has no name in the copyright
[18:58:46 CEST] <Daemon404> so.
[19:00:15 CEST] <rcombs> Copyright (C) 2015 ME
[19:00:23 CEST] <durandal_1707> cant get avx2 to work
[19:01:41 CEST] <rcombs> (the copyright was inside you the whole time!)
[19:01:42 CEST] <j-b> Compn: untrue.
[19:09:03 CEST] <Compn> j-b  :ah i was mistaken then.
[19:24:24 CEST] <RiCON> ubitux: probing a non-CRLF .vtt file doesn't work
[19:24:50 CEST] <kurosu> durandal_1707, sse4's pextrw
[19:25:28 CEST] <kurosu> nevcairiel, not that DEPCMD stuff is the only source of compilation issue
[19:26:08 CEST] <kurosu> I think there's still one with DBG=1 (for asm dev), but as I'm the only one using it, it's probably unimportant
[19:32:36 CEST] <wm4> RiCON: I could try to fix it
[19:36:00 CEST] <RiCON> ok, i'd try it myself but i really have no idea what's making probe not choose between srt and vtt if endings aren't crlf
[19:36:23 CEST] <wm4> it looks pretty stupid
[19:36:30 CEST] <wm4> and my fix is stupid too
[19:39:19 CEST] <rcombs> "WEBVTT" header?
[19:40:23 CEST] <rcombs> http://dev.w3.org/html5/webvtt/#dfn-webvtt-line-terminator <-- protip WebVTT allows either CRLF, LF, or CR line endings
[19:40:27 CEST] <rcombs> (why? fuck if I know)
[19:40:37 CEST] <wm4> does it allow non-utf8?
[19:40:40 CEST] <rcombs> (honestly why not just pick one)
[19:40:53 CEST] <rcombs> wm4: nope
[19:40:57 CEST] <wm4> ubitux, RiCON: patch sent
[19:41:02 CEST] <wm4> rcombs: surprisingly sane!
[19:41:05 CEST] <rcombs> they picked a character encoding but apparently failed to settle on a line ending
[19:41:07 CEST] <wm4> (haha.)
[19:41:21 CEST] <rcombs> they _do_ allow a UTF-8 BOM& optionally
[19:43:03 CEST] <RiCON> ffmpeg checks for bom at least
[20:13:33 CEST] <RiCON> wm4: seems to work http://j.fsbn.eu/raKs.png
[20:33:50 CEST] <Daemon404> g 42
[20:41:39 CEST] <durandal_1707> jamrial: that SPLATW trick give warning if using with 5 registers
[20:42:44 CEST] <jamrial> it's because it uses pshuflw, which can handle only the low 8bytes of an xmm reg
[20:45:03 CEST] <jamrial> load the coeffs to two registers and use SPLATW accordingly
[20:53:42 CEST] <peloverde> Is there a good way to stick an extra argument (based on macro parameter) on a macroed cglobal?
[21:00:09 CEST] <BBB> I typically use defaults for that
[21:00:19 CEST] <BBB> like macro blabla 6-7 defaultvaluefor7thargument
[21:00:24 CEST] <BBB> and then you can use %7 unconditionally
[21:00:40 CEST] <BBB> (it will have defaultvaluefor7thargument if you gave only 6 arguments)
[21:03:50 CEST] <peloverde> thanks
[21:11:23 CEST] <Daemon404> wm4, i dont get how the detection fucks up wbvtt vs srt?
[21:11:29 CEST] <Daemon404> webvtt MUST start with "WEBVTT"
[21:11:44 CEST] <wm4> because the srt prober ALSO detects the file as 100% srt
[21:11:57 CEST] <wm4> so, same score -> no decision
[21:11:58 CEST] <Daemon404> this sounds silly
[21:12:01 CEST] <wm4> yes
[21:12:09 CEST] <Daemon404> probably because it tries to consume all those broken files
[21:12:22 CEST] <Daemon404> i own the subtitle parsing code at work (i inherited it)
[21:12:24 CEST] <Daemon404> i know the pain.
[21:12:56 CEST] <wm4> so, if the file is detected as webvtt, it must be correct, because of the header, right
[21:13:15 CEST] <wm4> on the other hand, for srt it isn't so sure
[21:13:24 CEST] <Daemon404> not "Must", since im sure there are some stupid files that exist
[21:13:28 CEST] <rcombs> have srt return a slightly lower score, then?
[21:13:29 CEST] <Daemon404> but it *should* be used
[21:13:33 CEST] <wm4> so I think my patch does, as far as lavf's probing framework goes, the right thing
[21:13:33 CEST] <Daemon404> MAX-1?
[21:13:34 CEST] <Daemon404> lawl
[21:13:58 CEST] <rcombs> are there SRT files floating around where the first non-blank line doesn't start with a number?
[21:16:30 CEST] <rcombs> (I haven't seen one, and lavf used to reject that, but I wouldn't really be surprised if they existed)
[21:17:09 CEST] <Daemon404> rcombs, i have lots
[21:17:12 CEST] <Daemon404> users are the worst sort of people
[21:17:18 CEST] <rcombs> lovely
[21:17:22 CEST] <rcombs> what _do_ they start with?
[21:17:29 CEST] <Daemon404> garbage
[21:17:33 CEST] <rcombs> joyous
[21:17:37 CEST] <Daemon404> or nothing
[21:17:44 CEST] <rcombs> I said non-blank :P
[21:17:44 CEST] <Daemon404> because the numbers in srt dont actually do anything
[21:18:07 CEST] <Daemon404> there are also srt files that have vtt-style metadata
[21:18:10 CEST] <Daemon404> but are srt-formatted
[21:18:17 CEST] <Daemon404> and no WEBVTT header
[21:23:06 CEST] <RiCON> so it's either wm4's patch or something in srtdec that checks for WEBVTT and if found, marks it as webvtt and never srt
[21:37:13 CEST] <Daemon404> we: webvtt
[21:37:16 CEST] <Daemon404> re*
[21:37:17 CEST] <Daemon404> [20:36] < Daemon404> 00:00:00.000 --> 00:00:09.000
[21:37:17 CEST] <Daemon404> [20:36] < Daemon404> Test<script>alert(1)</script>
[21:37:17 CEST] <Daemon404> [20:36] < Daemon404> alerts in IE
[21:37:20 CEST] <Daemon404> apparently
[21:37:28 CEST] <Daemon404> (j-b, make sure to add support to vlxc)
[21:37:30 CEST] <Daemon404> vlc*
[21:37:41 CEST] <rcombs> Daemon404: wow, nice
[21:37:50 CEST] <Daemon404> well
[21:37:55 CEST] <Daemon404> you can embed css/js/whatever in vtt
[21:37:57 CEST] <Daemon404> by the spec
[21:37:58 CEST] <Daemon404> so...
[21:38:33 CEST] <wm4> that qsv guy should be our new license and copyright expert
[21:40:49 CEST] <BBB> we should never implement alert
[21:40:52 CEST] <BBB> popup mania
[21:41:13 CEST] <Daemon404> it's fine, vlc can link webkit
[21:41:18 CEST] <Daemon404> they use qt, they can use qtwekbit
[21:41:22 CEST] Action: Daemon404 runs
[21:41:22 CEST] <wm4> webkit is pretty dead
[21:41:27 CEST] <Daemon404> well blink then
[21:41:28 CEST] <Daemon404> i duno
[21:41:30 CEST] <wm4> and qtwebkit got dropped
[21:41:46 CEST] <Daemon404> o
[21:41:57 CEST] <wm4> (instead you're supposed to use qtwebengine, which embeds a full chrome browser)
[21:42:07 CEST] <Daemon404> o ok
[21:46:21 CEST] <durandal_1707> BBB: could scalarproduct_int16 really make use of avx2?
[21:46:31 CEST] <BBB> I dont know
[21:46:34 CEST] <BBB> I havent looked
[21:53:27 CEST] <atomnuker> well, Claudio's finally done with his stuff
[21:53:38 CEST] <atomnuker> but tiny_psnr is exploding because there's a 20 msec delay
[21:53:51 CEST] <atomnuker> (there always has been with our encoder + decoder)
[21:54:18 CEST] <atomnuker> interestingly enough, fdk_aac delays for 100 msec when decoded and overlaid on top of the original
[21:54:41 CEST] <atomnuker> (additionally decoding using fdk_aac also adds 100 msec)
[21:56:24 CEST] <durandal_1707> BBB: mmsize for avx2 is not 32
[21:56:31 CEST] <BBB> INIT_YMM?
[21:56:40 CEST] <BBB> or did you use INIT_XMM avx2?
[21:57:03 CEST] <durandal_1707> INIT_YMM
[21:58:32 CEST] <BBB> mmsize should be 32 then
[21:58:35 CEST] <BBB> can you show your code?
[22:00:17 CEST] <durandal_1707> its scalar_product with movd line changed to xm2
[22:01:06 CEST] <durandal_1707> i added %if mmsize == 32 .. some invalid instruction and it just continued
[22:02:15 CEST] <fritsch> nevcairiel: do you know anything about ffmpeg 2.8.1 are there plans?
[22:02:31 CEST] <jamrial> fritsch: check the ml
[22:02:44 CEST] <fritsch> jamrial: thx - will do
[22:03:12 CEST] <fritsch> jamrial: that answers it - thx
[22:07:00 CEST] <BBB> durandal_1707: well thats not a very good test
[22:07:12 CEST] <BBB> durandal_1707: show your patch :)
[22:07:32 CEST] <BBB> durandal_1707: and make sure your computer supports avx2, assignment is there (do breakpoints in the avx2 function ever hit?), etc.
[22:08:59 CEST] <cone-455> ffmpeg 03James Almer 07release/2.8:408240267a71: configure: check for ID3D11VideoContext
[22:09:45 CEST] <durandal_1707> BBB: config.h says AVX2 is available, and i know its running because md5 changes because other part of decoder is not updated
[22:12:13 CEST] <BBB> config.h just says your assembler/compiler support it
[22:12:16 CEST] <BBB> does your system support it?
[22:12:25 CEST] <BBB> and show your patch :D
[22:15:49 CEST] <wm4> ubitux: this is the webvtt sample "http://media-resolver.mtvnservices.com/caption/convert?mgid=mgid:file:gsp:comedystor:/com/dailyshow/TDS/Season_21/21007/ds_21_007_act1_199aae2a9f.dfxp.xml&accountName=comedycentral.com"
[22:16:25 CEST] <durandal_1707> BBB: its Intel(R) Core(TM) i3-5005U CPU @ 2.00GHz, so yes
[22:20:45 CEST] <wm4> rcombs: btw. I think you can push your mp4 sidx patch
[22:21:00 CEST] <rcombs> I'm actually unable to push for some reason
[22:21:01 CEST] <Daemon404> did yusuke lgtm it\
[22:22:25 CEST] <wm4> Daemon404: he had a small complaint, which AFAIK was corrected (or was it)
[22:23:07 CEST] <rcombs> (it was, but I haven't seen a response)
[22:23:22 CEST] <Daemon404> he's a busy guy
[22:23:31 CEST] <Daemon404> id assume its OK
[22:23:38 CEST] <Daemon404> he usually only replies when stuff is wrong
[22:24:41 CEST] <wm4> rcombs: the push address is git at source.ffmpeg.org:ffmpeg
[22:25:06 CEST] <wm4> it should work as long as 1. your ssh key got added, 2. the ssh-agent knows this ssh key
[22:25:17 CEST] <rcombs> yeah, my key doesn't seem to work on that, though I gave michaelni the pubkey
[23:11:47 CEST] <cone-455> ffmpeg 03Justin Greer 07master:9c168f9a2240: avfilter/af_afade: fix start of fade out
[23:13:41 CEST] <cone-455> ffmpeg 03Ganesh Ajjanagadde 07master:65e2a5bb3295: doc/faq: use https instead of http
[23:24:14 CEST] <wm4> ubitux: so, is that patch ok or not?
[23:24:38 CEST] <nevcairiel> atomnuker: if the delay has always been there, why is it exploding now? there is also ways to signal the delay and get avcodec/avformat to offset timestamps by that .. if that would help tiny_psnr, that is
[23:29:22 CEST] <cone-455> ffmpeg 03wm4 07master:b3f8d871eeda: avcodec/ass: fix doxygen typo
[23:29:33 CEST] <wm4> RiCON: corrected that typo you found
[23:30:38 CEST] <ubitux> wm4: wait, that one is recognieze in 2.8, is this a regression?
[23:33:28 CEST] <wm4> ubitux: it definitely didn't work in git
[23:33:29 CEST] <wm4> so maybe yes
[23:33:52 CEST] <ubitux> can you wait til i figure that out?
[23:33:54 CEST] <wm4> I didn't try 2.8 though
[23:33:56 CEST] <wm4> sure
[23:34:17 CEST] <ubitux> if i don't tmr feel free to apply, but i'd like to know from where this is coming from
[23:34:44 CEST] <ubitux> it's definitely detecting it as webvtt here with 2.8
[23:36:24 CEST] <ubitux> looks like a regression since 7218352e0228028dfa009a3799ec93fd041065f1.
[23:36:55 CEST] <ubitux> the fact that i'm now allowing not number input matches the vtt chaptering 
[23:37:13 CEST] <wm4> hm.
[23:37:35 CEST] <ubitux> the curious thing is that it doesn't choke on the WEBVTT header
[23:37:52 CEST] <wm4> yeah that doesn't make sense
[23:38:01 CEST] <ubitux> oh i think i know
[23:38:15 CEST] <ubitux> the strtol will not < 0 even if there is nothing maybe
[23:38:24 CEST] <ubitux> we should check if it had consume at least something
[23:38:50 CEST] <ubitux> by adding something like || pbuf == buf
[23:38:51 CEST] <wm4> actually I think the strtol return value is pretty much undefined here
[23:39:26 CEST] <nevcairiel>  If there were no digits at all, strtol() stores the original value of nptr in *endptr (and returns 0)
[23:39:31 CEST] <wm4> hm, I withdraw my patch then
[23:39:39 CEST] <ubitux> -        strtol(buf, &pbuf, 10) < 0 || *pbuf)
[23:39:41 CEST] <ubitux> +        strtol(buf, &pbuf, 10) < 0 || buf == pbuf)
[23:39:43 CEST] <ubitux> something like this maybe
[23:40:14 CEST] <ubitux> (the "|| *pbuf" isn't anymore but you get it)
[23:40:21 CEST] <ubitux> i'll make some more testing tmr
[23:40:41 CEST] <ubitux> but feel free to apply a similar fix in the meantime
[23:40:44 CEST] <ubitux> i have to go right now
[23:41:08 CEST] <ubitux> i'll need to backport to 2.8 since this commit has been taken..
[23:41:10 CEST] <wm4> ubitux: seems to work
[23:41:19 CEST] <ubitux> does it still detect srt properly?
[23:41:23 CEST] <wm4> yes
[23:41:35 CEST] <nevcairiel> that particular srt from the ticket too? :)
[23:41:38 CEST] <ubitux> ok well i'll apply in a non-rush situation :)
[23:41:51 CEST] <wm4> nevcairiel: didn't check
[23:41:53 CEST] <ubitux> nevcairiel: i'll try that
[23:42:15 CEST] <ubitux> iirc the sample actually has numbers
[23:42:20 CEST] <ubitux> it's just followed by garbage
[23:42:31 CEST] <ubitux> so the pbuf should be different
[23:43:29 CEST] <ubitux> anyway afk & sorry for the regression, i'll fix asap tmr
[00:00:00 CEST] --- Fri Oct  9 2015