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

[burek]

[00:37:12 CEST] <RiCON> does mac still use CR endings anyway?
[00:37:26 CEST] <nevcairiel> i think they got rid of that years ago
[00:37:45 CEST] <RiCON> (webvtt code doesn't work CR-only)
[00:37:56 CEST] <RiCON> was trying to fix that, but if it's not used, f that
[00:47:40 CEST] <JEEB> yeah, I think it was the pre-OS X stuff that used that?
[00:48:09 CEST] <nevcairiel> RiCON: i'm sure you'll find some idiot with such a file if you look hard enough
[00:48:27 CEST] <nevcairiel> not that i'm saying you should fix it
[05:12:53 CEST] <cone-256> ffmpeg 03Rodger Combs 07master:4f7d9b770612: lavf/matroskadec: drop indexes that appear broken
[07:08:00 CEST] <rcombs> anyone have any issue with me pushing my AV_OPT_ (and specifically ALLOW_NULL) changes?
[10:13:03 CEST] <mateo`> hello there, I just found out that when you try to read an image (let's say a jpeg), the file is in fact decoded twice, once in avformat_find_stream_info and once when the stream is actually decoded.
[10:13:49 CEST] <mateo`> The issue comes from the fact that the demuxer does not do any parsing (and set the NOHEADER flag)
[10:14:39 CEST] <wm4> welcome to libavformat
[10:15:10 CEST] <wm4> you could possibly just not call avformat_find_stream_info
[10:15:14 CEST] <mateo`> I see two options there, doing some parsing in the demuxer (even though that's more a job for a parser)
[10:15:20 CEST] <wm4> but I think this breaks with some formats
[10:15:42 CEST] <mateo`> Or passing an option to the decoder to only get the stream information
[10:19:00 CEST] <mateo`> I also find weird that the demuxer is in charge of setting the pixel format if it is supposed to parse those information
[10:19:47 CEST] <wm4> in an ideal world, libavformat wouldn't try to determine the pixel format
[10:19:57 CEST] <wm4> because that's just nonsensical
[10:20:19 CEST] <wm4> though it might help really badly written API users
[10:20:36 CEST] <wm4> (like if they want to know the pixel format before "decoding" anything)
[10:21:15 CEST] <nevcairiel> I find it quite useful
[10:22:26 CEST] <mateo`> but if the decoder can't honor the pixel format ?
[10:22:31 CEST] <wm4> and it slows down opening of image files only by 2
[10:23:08 CEST] <nevcairiel> in the dshow model I have to connect everything before I can start giving data to the decoder, which means I need to give the renderer some pixel format before the decoder can determine it - on some formats that can be determined from extradata, but not all formats have that. And some of the renderers I have to work with fail at switching their input format after initial connection ... so knowing the right format directly after 
[10:23:08 CEST] <nevcairiel> opening the file helps me =p
[10:23:58 CEST] <wm4> so just decode a frame, and delay setting it up until then?
[10:25:09 CEST] <nevcairiel> but that means i practically have to re-implement code that exists today
[10:25:50 CEST] <nevcairiel> anyway i think elenril has plans for that part in some  evil plan
[10:27:35 CEST] <mateo`> nevcairiel: a plan which avoid decoding twice images ?
[10:28:06 CEST] <nevcairiel> maybe, maybe not, i dont remember the specifics
[10:29:26 CEST] <mateo`> i'd like to tackle this issue as it costs too much to decode twice images
[10:30:14 CEST] <nevcairiel> just dont call avformat_find_stream_info, its not required for image files anyway
[10:30:15 CEST] <mateo`> not sure what you would prefer, doing some parsing in the demuxer (and sharing some code between avcodec and avformat)
[10:30:46 CEST] <mateo`> mmm
[10:33:37 CEST] <mateo`> nevcairiel: not sure if this is a proper fix for the issue, do you already know that you are dealing with an image after calling avformat_open_input ?
[10:55:01 CEST] <cone-831> ffmpeg 03Clément BSsch 07master:40d9d6de90c3: avformat/srtdec: make sure we probe a number
[10:57:51 CEST] <cone-831> ffmpeg 03Clément BSsch 07release/2.8:ee1bcd343675: avformat/srtdec: make sure we probe a number
[11:00:50 CEST] <cone-831> ffmpeg 03Clément BSsch 07master:8f6f357fde0e: build: restore videotoolbox compilation on iOS
[11:14:42 CEST] <cone-831> ffmpeg 03Rodger Combs 07master:f36baeebc55d: lavu/opt: switch AV_OPT flags to shift-based formatting
[11:14:43 CEST] <cone-831> ffmpeg 03Rodger Combs 07master:0562f9590215: lavu/opt: add flag to return NULL when applicable in av_opt_get
[11:14:44 CEST] <cone-831> ffmpeg 03Rodger Combs 07master:f00ec7eb1b94: lavf/hls: don't convert NULL options to empty strings; fixes HTTP CRLF warnings
[11:15:29 CEST] <nevcairiel> so thats where the crlf warning came from
[11:16:08 CEST] <rcombs> yup
[11:20:05 CEST] <rcombs> should I also push the sidx patch, then?
[11:21:39 CEST] <ubitux> i wonder if setting avctx->skip_frame to AVDISCARD_ALL is going to break some probing in the probe info
[11:21:44 CEST] <ubitux> mateo` will tell us :)
[11:22:07 CEST] <ubitux> but honoring this in the image decoder will help for skipping the probing decode
[11:22:27 CEST] <nevcairiel> no generic solution though
[11:22:36 CEST] <ubitux> actually it is
[11:23:11 CEST] <nevcairiel> a bunch of video decoders implement it, and you would potentially break their format probing then
[11:23:35 CEST] <ubitux> well, hopefully they still set the necessary information
[11:23:44 CEST] <nevcairiel> not necessarily
[11:23:46 CEST] <ubitux> i guess the problem lies in "hopefully"
[11:24:24 CEST] <ubitux> but generally speaking, the probing should not decode anyway
[11:25:40 CEST] <nevcairiel> there is no such fine grained control however
[12:15:43 CEST] <cone-831> ffmpeg 03Paul B Mahol 07master:5e0abf59d825: avfilter/vf_blend: fix normal mode with opacity != 1
[13:39:33 CEST] <cone-831> ffmpeg 03Christophe Gisquet 07master:1896ac4abfe2: build system: fix dependency generation
[14:03:48 CEST] <wm4> nevcairiel: how do you handle mp4 files, which have only 1 video frame (at the start)
[14:03:58 CEST] <wm4> do you just decode all the audio on seeking?
[14:04:15 CEST] <wm4> (because libavformat will seek always to the start due to the video frame)
[14:04:44 CEST] <nevcairiel> i have some hackery that tries to detect this case and then treats it like an attached image instead of a video stream
[14:04:50 CEST] <wm4> eh
[14:04:58 CEST] <nevcairiel> so i explicitly ask avformat to seek on the audio stream
[14:05:19 CEST] <wm4> what if the stream is sparse? (slide show)
[14:05:23 CEST] <nevcairiel> mp4's number of frames property in AVStream is usually accurate so that works
[14:05:35 CEST] <nevcairiel> that wouldnt be a problem then, would it
[14:05:43 CEST] <nevcairiel> could still seek to the closest slide show entry
[14:05:54 CEST] <wm4> yeah, but still a lot of audio to decode
[14:06:02 CEST] <nevcairiel> audio is cheap
[14:06:35 CEST] <wm4> so, should mov.c do this hack then? treating the frame as attached image instead?
[14:06:47 CEST] <nevcairiel> dunno
[14:07:31 CEST] <wm4> what I'd really like is a stream argument to av_read_frame
[14:08:04 CEST] <nevcairiel> and have it do what, discard any frames that dont fit it
[14:08:14 CEST] <nevcairiel> majority of formats is interleaved
[14:08:54 CEST] <wm4> it would buffer them, just like it does awkward tricks with mp4 to simulate interleaving
[14:08:57 CEST] <wm4> but ok, then how about a per-stream EOF flag
[14:09:19 CEST] <nevcairiel> again majority of formats could never provide that
[14:09:34 CEST] <wm4> or I know, a frame number (which is set for mp4 only, just like the AVStream field)
[15:37:56 CEST] <ubitux> so mmh
[15:38:28 CEST] <ubitux> i'm not sure if i can modify it, but any comment on https://www.surveymonkey.com/r/XGXPHXZ before i share it to user ml etc? 
[15:43:11 CEST] <ubitux> maybe i should add "a packager/distributor"
[15:44:02 CEST] <ubitux> it appears i can still edit
[15:45:34 CEST] <Daemon404> why are we surveying users
[15:45:45 CEST] <Daemon404> also i imagining the user list is self-selecting 
[15:45:48 CEST] <Daemon404> certain, uh, types.
[15:46:07 CEST] <ubitux> it can be share in multiple places
[15:46:27 CEST] <ubitux> the 3 ml, 2 irc channels, and maybe more generic like reddit (don't have account)
[15:46:52 CEST] <TimNich> An FFmpeg is better English than A FFmpeg
[15:47:33 CEST] <ubitux> TimNich: fixed, thx
[15:51:44 CEST] <wm4> Daemon404: I wonder how many ffmpeg devs we will have
[15:52:07 CEST] <ubitux> i made sure to have the "developer using the api" as first choice to avoid any confusion
[15:52:15 CEST] <ubitux> (with a FFmpeg core dev)
[15:52:22 CEST] <ubitux> hope it will be enough
[15:52:46 CEST] <ubitux> poll is anonymous btw, i didn't ask for any registration to encourage submissions
[15:55:23 CEST] <ubitux> Daemon404: you think the poll is a bad idea?
[15:56:49 CEST] <cone-831> ffmpeg 03Ganesh Ajjanagadde 07master:1e81fd3710a8: avcodec/pthread_frame: update doxygen for update_context_from_thread
[15:58:49 CEST] <Daemon404> i have no opinion
[15:58:59 CEST] <Daemon404> but i do think you need a misc comments box
[16:05:13 CEST] <RiCON> ubitux: can't find anything in webvtt that says more than those 6 escapes are expected
[16:06:16 CEST] <RiCON> so é would stay as is
[16:08:31 CEST] <ubitux> shouldn't all the "&xxx;" be simply stripped?
[16:08:40 CEST] <ubitux> all the unsupported* ones
[16:08:55 CEST] <RiCON> that would make Ben&Jerry disappear because no ";" is found
[16:09:07 CEST] <nevcairiel> if you cant replace them with their real value, just leave them in
[16:09:16 CEST] <RiCON> since "&" isn't valid
[16:10:04 CEST] <ubitux> ok ok
[16:10:17 CEST] <ubitux> let me have a look at the patch again
[16:10:28 CEST] <RiCON> vtt aren't text/html files either, they're text/vtt files
[16:10:30 CEST] <ubitux> RiCON: can you share your vtt test sample? (i'm lazy to craft one)
[16:10:36 CEST] <RiCON> i posted to trac
[16:10:47 CEST] <RiCON> http://trac.ffmpeg.org/attachment/ticket/4915/htmlescapes.vtt
[16:15:18 CEST] <ubitux> thx
[16:23:02 CEST] <durandal_1707> can we vote to remove carl hwaccel code?
[16:23:24 CEST] <RiCON> ubitux: also, might wanna check https://quuz.org/webvtt/
[16:24:31 CEST] <wm4> is there an outcome on the Libav ABI compat insanity yet
[16:27:04 CEST] <j-b> webvtt? oh boy
[16:27:10 CEST] <j-b> some people are still working on this crap?
[16:27:25 CEST] <wm4> some sites are actually using it
[16:27:49 CEST] <av500> maybe one say we can have webhtml
[16:27:53 CEST] <av500> back to the roots
[16:27:58 CEST] <RiCON> i just don't want > in my subs
[16:28:10 CEST] <iive> durandal_1707: what is the carls hwaccel code?
[16:28:32 CEST] <wm4> iive: old vdpau decoder
[16:34:29 CEST] <durandal_1707> is it marked deprecated?
[16:38:37 CEST] <wm4> of course
[16:39:01 CEST] <Daemon404> [15:27] <+wm4> some sites are actually using it <-- we are
[16:39:07 CEST] <Daemon404> i dont have anything better to suggest.
[16:39:16 CEST] <Daemon404> we use a strict srt-like subset though
[16:47:33 CEST] <RiCON> ubitux: found a valid vtt that breaks with the new code, so "<" will have to be stripped after all
[16:48:03 CEST] <ubitux> the original code was trying to hide any unsupported < >
[16:48:28 CEST] <ubitux> that is, the tag themselves, not what they wrap
[16:48:38 CEST] <ubitux> you should keep that behaviour if you changed it
[16:48:49 CEST] <ubitux> do i wait for the next iteration before i review?
[16:49:24 CEST] <RiCON> yes, i'm adding back the skip, but on a else if
[16:51:31 CEST] <BBB> durandal_1707: try define_args at least, it allows reuse of coefs, which saves one register for free
[16:51:40 CEST] <BBB> durandal_1707: that shouldnt require any modification of the rest of the assembly
[16:51:54 CEST] <BBB> durandal_1707: just one GPR less and one line of DEFINE_ARGS after loading coefs
[16:52:17 CEST] <BBB> durandal_1707: merging counters is admittedly a little bit more complex so not doing that is fine with me
[16:55:28 CEST] <Daemon404> nevcairiel, i see pthread_once can be merged nw
[16:56:22 CEST] <ubitux> (RiCON: make sure make fate-subtitles still works btw)
[16:57:14 CEST] <RiCON> are there instructions for that?
[16:57:38 CEST] <ubitux> http://ffmpeg.org/fate.html
[16:57:59 CEST] <ubitux> basically:
[16:58:01 CEST] <ubitux> ./configure --samples=fate-suite/
[16:58:03 CEST] <ubitux> make fate-rsync
[16:58:05 CEST] <ubitux> make fate
[16:58:16 CEST] <ubitux> or in your case, for a faster test, make fate-subtitles instead of the latest line
[16:59:58 CEST] <Daemon404> j-b, i hope you start seeing mp4box.js output one day
[17:00:04 CEST] <Daemon404> mp4box dev replied on chrome bug tracker
[17:00:07 CEST] <Daemon404> what they are doing is insane
[17:00:24 CEST] <Daemon404> they are making fragmented MP4s that are one frame per segment
[17:00:28 CEST] <Daemon404> and marking each as a RAP
[17:00:31 CEST] <Daemon404> regardless of frametype
[17:00:34 CEST] <Daemon404> for "latency reasons"
[17:00:48 CEST] <j-b> Daemon404: that is not surprising
[17:00:54 CEST] <Daemon404> that is pure insanity though
[17:00:58 CEST] <Daemon404> one p-frame-long frag
[17:00:59 CEST] <j-b> Daemon404: and that is matching what I predicted 4 years ago
[17:01:04 CEST] <Daemon404> what the shit is teh point?
[17:01:06 CEST] <j-b> at VDD/FOMS
[17:01:08 CEST] <Daemon404> you cant adaptively stream that
[17:01:18 CEST] <j-b> but you can push that on CDN with low latencies
[17:01:31 CEST] Action: Daemon404 facedesks
[17:01:35 CEST] <j-b> it's the answer to low-latency HLS/Dash
[17:02:01 CEST] <Daemon404> you can do it less insane
[17:02:11 CEST] <Daemon404> but also: dont use that shit for low latency streaming
[17:02:17 CEST] <j-b> but no
[17:02:22 CEST] <j-b> because those are the web people
[17:02:29 CEST] <j-b> they only know DASH/HLS and Webvtt
[17:02:41 CEST] <j-b> completely forgetting that they are reinventing MMS
[17:02:46 CEST] <Daemon404> still waiting for vlc to emulate IE, and allow script ags in webvtt to be run
[17:02:49 CEST] <Daemon404> tags*
[17:03:10 CEST] <j-b> script?
[17:03:20 CEST] <Daemon404> <script>...</script>
[17:03:29 CEST] <Daemon404> disallowed by the spec, ie runs it anyway
[17:03:43 CEST] <Daemon404> in subtitle lines
[17:04:06 CEST] <j-b> haha
[17:04:07 CEST] <j-b> nice
[17:05:18 CEST] <av500> one frame per MP4?
[17:06:13 CEST] <j-b> sure.
[17:06:29 CEST] <j-b> one gop per MP4 was done already
[17:06:35 CEST] <j-b> so, next step was one frame.
[17:06:42 CEST] <Daemon404> next up, one MB?
[17:06:58 CEST] <j-b> and of course, they still confuse delta-pts and delta-dts
[17:07:08 CEST] <j-b> between mp4 spec and video-html5 spec
[17:07:29 CEST] <Daemon404> thierry has logn rants about this
[17:07:40 CEST] <Daemon404> he told me he put them in a room to debate it
[17:07:45 CEST] <Daemon404> and result is the dash spec changes
[17:07:48 CEST] <Daemon404> apparently.
[17:08:09 CEST] Action: ubitux waits for <img src="bla.gif" onmouseover="alert('hello')"> in subtitles
[17:08:18 CEST] <j-b> instead of fixing the video-spec
[17:08:49 CEST] <Daemon404> i am luckily unaffected by this problem or change right now
[17:22:10 CEST] <RiCON> does it say anything when it fails?
[17:24:25 CEST] <RiCON> ok, tried changing the webvtt to add a few entities and it indeed says when it fails
[17:25:11 CEST] <RiCON> do you add the entities to the fate sample or do I have to do it in the same commit?
[17:26:13 CEST] <ubitux> you can't change the fate sample
[17:28:00 CEST] <RiCON> so just the commit as is and then you add the escapes to be tested on a future commit?
[17:29:30 CEST] <RiCON> sent
[17:30:05 CEST] <ubitux> you can propose another sample to extend the test if you want, i was just asking you to make sure make fate-subtitles still passes
[17:30:12 CEST] <RiCON> right, different subject so in-reply-to didn't work
[17:30:15 CEST] <RiCON> it passes
[17:30:23 CEST] <ubitux> ok :)
[17:30:39 CEST] <RiCON> where do i submit the extended sample?
[17:31:45 CEST] <ubitux> send it to the ml with a new test patch
[17:32:26 CEST] <ubitux> maybe take the opportunity to add a lot of currently unsupported features
[17:32:40 CEST] <ubitux> for later extension of the code (so we don't need to add a new sample to test them)
[17:32:55 CEST] <ubitux> in case you're planing to add new test+sample
[17:37:29 CEST] <RiCON> was just planing on changing the current sample to add the entities, but might as well add <c>, <ruby>, <lang>, <01:23:45.678> then
[17:45:39 CEST] <ubitux> yeah add some cute furigana ruby
[17:45:58 CEST] <durandal_1707> ubitux: what fft asm needs?
[17:46:06 CEST] <ubitux> willpower
[17:46:27 CEST] <ubitux> ticket is #3921
[18:13:55 CEST] <RiCON> ubitux: how's http://sprunge.us/UViA?diff
[18:15:09 CEST] <ubitux> RiCON: as i said, you can't change an existing sample (all the samples need to work with all the repository states)
[18:15:26 CEST] <ubitux> the events themselves (in a separate vtt) are fine
[18:15:30 CEST] <ubitux> maybe add the bidi ones?
[18:15:40 CEST] <ubitux> (with arabic & numbers typically)
[18:16:11 CEST] <RiCON> right
[18:19:03 CEST] <RiCON> like sami's tests
[18:20:40 CEST] <JEEB> man, you just confused me
[18:20:48 CEST] <JEEB> since my coworker's name is sami
[18:23:02 CEST] <ubitux> haha
[18:47:13 CEST] <j-b> JNI...
[18:59:05 CEST] <nevcairiel> speaking of terrible subtitles, anyone wanna implement ttml? :p
[19:03:04 CEST] <RiCON> ubitux: would you rather a sample following every stuff in the spec or just things that are valid in https://quuz.org/webvtt/ ?
[19:11:30 CEST] <Daemon404> j-b, context?
[19:11:33 CEST] <Daemon404> or just random JNI hate
[19:11:36 CEST] <BBB> durandal_1707: ok
[19:11:45 CEST] <BBB> durandal_1707: (patch is ok)
[19:12:08 CEST] <BBB> oh wait
[19:12:13 CEST] <BBB> durandal_1707: you missed my point in scale
[19:12:32 CEST] <BBB> durandal_1707: packssdw m0, m1, and then packuswb m0, m0
[19:12:34 CEST] <j-b> Daemon404: context is on the mailing list
[19:12:42 CEST] <BBB> durandal_1707: does the same as two packssdw, two packuswb and punpckldq
[19:13:02 CEST] <mateo`> j-b: are you against having this kind of support in FFmpeg ?
[19:13:08 CEST] <j-b> mateo`: with crap like that? yes
[19:13:16 CEST] <j-b> mateo`: you cannot be thread-safe
[19:13:30 CEST] <j-b> content:// has no reason to be in libavformat
[19:13:50 CEST] <j-b> java_VM* as a global variable.
[19:13:55 CEST] <mateo`> j-b: you would see content:// in an avdevice ?
[19:14:01 CEST] <j-b> if you want
[19:14:01 CEST] <Daemon404> j-b, oh dear
[19:14:03 CEST] <Daemon404> this is bad.
[19:14:10 CEST] <j-b> mateo`: but even that, WHY?
[19:14:20 CEST] <mateo`> supporting the android platform
[19:14:24 CEST] <j-b> that's BS
[19:14:31 CEST] <j-b> sorry, but that's BS
[19:14:31 CEST] <mateo`> why ?
[19:14:47 CEST] <j-b> content:// parsing is trivial to do in any calling application
[19:15:00 CEST] <j-b> in C or in Java
[19:15:18 CEST] <j-b> and content:// is not defined, not specified, and can change with every Android version
[19:15:35 CEST] <j-b> (not to mention, that you already support Android, with the StageFright 'code')
[19:15:42 CEST] <j-b> So, what's the use case?
[19:16:01 CEST] <mateo`> isn't the lavc stagefright decoder dead ?
[19:16:12 CEST] <nevcairiel> it should never have existed
[19:16:13 CEST] <mateo`> this is what i've been told here
[19:16:39 CEST] <mateo`> i know that supporting mediacodec through the java api is horrible
[19:17:02 CEST] <j-b> of course, but, as soon as I mention it (stagefright patch), people jump at my nick
[19:17:04 CEST] <mateo`> but it's the only way to go for know if you want to support different version of android
[19:17:34 CEST] <j-b> mateo`: well, then, only support 5.0+
[19:18:05 CEST] <Daemon404> the patch is balls, but 5+ only is not really reasonable
[19:18:15 CEST] <mateo`> there is too many pre-5.0 devices to do that
[19:18:36 CEST] <nevcairiel> use a pure java workflow then
[19:18:37 CEST] <Daemon404> the patchset itself is bad anyway
[19:18:40 CEST] <j-b> and of course content:// has no strict definition
[19:18:46 CEST] <Daemon404> and content:// is dumb
[19:18:48 CEST] <j-b> you can extend it in any way you want
[19:18:54 CEST] <j-b> it's totally dumb
[19:19:06 CEST] <j-b> mateo`: so, then, do as nevcairiel say, use Java workflow
[19:19:36 CEST] <j-b> mateo`: we implement mediacodec in java in VLC, and seriously, you shouldn't wnat to do that
[19:19:37 CEST] <wm4> we should add wine and a x86 emulator to libavutil!
[19:19:43 CEST] <wm4> it's important because of windows binary codecs
[19:19:51 CEST] <j-b> that's a great idea.
[19:19:57 CEST] <j-b> wm4: can you do that? I will pay you
[19:19:58 CEST] <BBB> I have an old patch that adds a dll loader to ffmpeg
[19:20:08 CEST] <BBB> I used it when I REed wmavoice
[19:20:11 CEST] <wm4> AAAAAH MAKE THE VOICES STOP
[19:20:15 CEST] <BBB> :D
[19:20:20 CEST] <j-b> Sorry, but that's exactly what I spoke about lack of vision
[19:20:28 CEST] <wm4> BBB: you could have used mplayer
[19:20:29 CEST] <j-b> because you can put crap in FFmpeg, does not mean you should.
[19:20:42 CEST] <BBB> wm4: have you ever seen the adobe flash player source code?
[19:20:43 CEST] <j-b> BBB: I have a patch that makes VLC use mplayer :)
[19:21:05 CEST] <BBB> wm4: it is pretty and secure compared to mplayer
[19:21:09 CEST] <wm4> j-b: you had a patch that makes vlc use gstreamer, and you merged it
[19:21:14 CEST] <BBB> (did I just violate the VLC CoC?)
[19:21:16 CEST] <j-b> wm4: indeed \o/
[19:21:23 CEST] <j-b> BBB: :D
[19:21:38 CEST] <wm4> <BBB> wm4: have you ever seen the adobe flash player source code? <- have you?
[19:21:41 CEST] <j-b> wm4: technically, the patch was correct, and I could not merge object it.
[19:21:47 CEST] <j-b> wm4: sure, we did :)
[19:21:50 CEST] <BBB> wm4: I have, in fact, I worked on it while at google
[19:21:54 CEST] <j-b> The amazing mike did have it
[19:22:02 CEST] <BBB> wm4: I even have a tshirt that acknowledges this fact
[19:22:21 CEST] <wm4> BBB: Google, or having seen flash player code?
[19:22:48 CEST] <BBB> wm4: I have worked extensively with the flash player code (as part of moving it from chrome npapi to googles private ppapi)
[19:23:06 CEST] <BBB> I have seen hell, and I never want to go back there
[19:23:15 CEST] <BBB> but still, compared to mplayer, its pretty and secure
[19:23:36 CEST] <wm4> ok
[19:24:08 CEST] <BBB> (I again apologize if my technical analysis violated the VLC CoC)
[19:24:53 CEST] <mateo`> about the content:// uris they are defined here, https://developer.android.com/reference/android/content/ContentUris.html
[19:25:22 CEST] <mateo`> i can understand you don't want to support something like that in ffmpeg, ok
[19:25:33 CEST] <mateo`> about android mediacodec hw, what should we do then ?
[19:25:53 CEST] <j-b> mateo`: content:// can be extended.
[19:25:55 CEST] <mateo`> about my patchset i'm open to critism, well if it's shit it's shit, but please comment i will improve the code
[19:26:10 CEST] <j-b> mateo`: and android version specific
[19:26:26 CEST] <mateo`> if you don't want any java/android stuff (through the use of jni), please say it now
[19:26:39 CEST] <j-b> mateo`: my opinion is that we should support mediacodec in C
[19:26:47 CEST] <mateo`> j-b: api level 1
[19:27:08 CEST] <mateo`> i've heard of the C api
[19:27:09 CEST] <wm4> isn't mediacodec an asynchronous API
[19:27:12 CEST] <mateo`> i never found it
[19:27:17 CEST] <j-b> mateo`: sorry, I _know_ about Content
[19:27:24 CEST] <j-b> it's the basic of Intent
[19:27:26 CEST] <mateo`> wm4: it could be asynchronous since 5.0
[19:27:37 CEST] <j-b> but because of Content Providers, it can be extended
[19:29:40 CEST] <j-b> https://git.videolan.org/?p=vlc-ports/android.git;a=blob;f=vlc-android/src/org/videolan/vlc/gui/video/VideoPlayerActivity.java;hb=HEAD#l2496
[19:29:44 CEST] <j-b> look at the insanity
[19:30:40 CEST] <j-b> mateo`: my opinion is that we should support mediacodec in C, and for older versions, aka 4.2 to 4.4, have a .h|.c wrapper that does the wrapping of the java in the C way.
[19:32:50 CEST] <mateo`> j-b: but isn't handling content uri and getting a fd from it useful ?
[19:33:07 CEST] <j-b> useful for whom?
[19:33:37 CEST] <j-b> what's the use case?
[19:33:46 CEST] <mateo`> not having to deal with content uri to file path, so lavf can deal with it
[19:34:08 CEST] <j-b> sorry, but I'd argue that has nothing to do inside libav*
[19:34:13 CEST] <Daemon404> lavf is not the correct place to do this
[19:34:30 CEST] <mateo`> you query a content from asset picker for example, you can pass the uri directly to lavf
[19:34:48 CEST] <Daemon404> "im lazy and want to do it in lavf" is not a legitimate argument to put it in ther
[19:34:48 CEST] <j-b> then do the uri extraction in your app
[19:34:57 CEST] <Daemon404> eespecially when it's not actually a format proto
[19:35:07 CEST] <j-b> it's not a file format, it's not a playlist, it does not have a spec, it's OS-specific, it's application specific
[19:35:10 CEST] <Daemon404> exactly
[19:35:12 CEST] <mateo`> Daemon404: i'm not lazy, i considered it more elegant to have it in lavf
[19:35:20 CEST] <Daemon404> seriously?
[19:35:22 CEST] <Daemon404> elegant?
[19:35:22 CEST] <mateo`> yes
[19:35:27 CEST] <Daemon404> i think youre on drugs then
[19:35:30 CEST] <mateo`> from an user perspective
[19:35:32 CEST] <mateo`> no
[19:35:33 CEST] <Daemon404> or dont udnerstand separation of functionality
[19:35:34 CEST] <mateo`> i'm not
[19:35:38 CEST] <j-b> Who is the user?
[19:35:52 CEST] <mateo`> the application / me 
[19:36:08 CEST] <j-b> if you have an application, content resolution is trivial to do in your java application
[19:36:13 CEST] <Daemon404> and the Grand mplayer Traditiom continues
[19:36:17 CEST] <Daemon404> put all teh stuff in libav*
[19:36:20 CEST] <Daemon404> rather than player
[19:36:25 CEST] <Daemon404> tradition*
[19:37:16 CEST] <j-b> Seriously, if needed, do a libplayer
[19:37:22 CEST] <j-b> and do it there.
[19:37:31 CEST] <j-b> it's maybe a good idea.
[19:37:41 CEST] <mateo`> ok
[19:37:43 CEST] <Daemon404> it's likely the usual "this doesnt actually fit in any of the current libs, so let us shoehorn it in"
[19:37:58 CEST] <j-b> mateo`: but seriously, do it in the java code
[19:38:04 CEST] <mateo`> sure i'll do that then
[19:38:16 CEST] <j-b> as for the rest of the patch, I'd argue do the C part correctly first
[19:38:24 CEST] <Daemon404> oh
[19:38:24 CEST] <mateo`> if you guys consider it's a really bad, i understand your point of view
[19:38:38 CEST] <mateo`> i'll do it on the application side and drop the patch
[19:38:44 CEST] <j-b> and then, do a java/c binder for mediacodec
[19:38:53 CEST] <j-b> but, NEVER EVER EVER install a jni.h
[19:39:18 CEST] Action: Daemon404 apologies for drugs quip, btw
[19:39:24 CEST] <j-b> Daemon404: quip?
[19:39:33 CEST] <mateo`> I didn't install a jni.h, it's available in the android ndk
[19:39:38 CEST] <Daemon404> insinutation? insult? bad words?
[19:39:52 CEST] Action: j-b wiktionary
[19:39:56 CEST] <atomnuker> what's wrong with using libstagefright for 4.0 and using the proper mediacodec api for 5.0? why is there even a need for an ugly java interfacing hack
[19:40:03 CEST] <j-b> mateo`: ok, I misread the patch
[19:40:12 CEST] <j-b> atomnuker: that's also a good way
[19:40:23 CEST] <j-b> atomnuker: the truth is the stagefright never really worked ;)
[19:40:40 CEST] <Daemon404> thats not true, you can make it work if you are wbs and have copious amounts of time
[19:40:46 CEST] <Daemon404> but if you are not him, then yes it doesnt work
[19:40:56 CEST] <j-b> Daemon404: I tried, using wbs :)
[19:41:00 CEST] <Daemon404> lol
[19:41:15 CEST] <atomnuker> j-b: as in, it never actually did anything? or it just didn't do it well?
[19:41:16 CEST] <j-b> and then, realizing I was not THEGOD, I failed, and cried
[19:41:25 CEST] <j-b> atomnuker: for me, never anything
[19:41:47 CEST] <j-b> atomnuker: but of course, stagefright is a OpenMAX-AL like framework
[19:42:00 CEST] <j-b> using it from libavcodec is going to fail
[19:42:09 CEST] <mateo`> it's even on top of omx, no ?
[19:42:19 CEST] <j-b> since numerous stagefright implementations USE libavcodec
[19:42:31 CEST] <j-b> mateo`: IL, yes
[19:42:42 CEST] <j-b> so you have libavcodec using libstagefright using libavcodec
[19:43:19 CEST] <j-b> atomnuker: another way is to use omxil for Android 2.1->4.4 and then mediacodec from 5.0+
[19:44:28 CEST] <j-b> atomnuker: and that, all is in C
[19:44:39 CEST] <j-b> but, boy OMX
[19:44:51 CEST] <mateo`> j-b: i've never found the mediacodec c api document, do you know where i can find it ?
[19:46:10 CEST] <j-b> android-ndk-r10e/platforms/android-21/arch-arm/usr/include/media/NdkMediaCodec.h ?
[19:47:25 CEST] <j-b> mateo`: don't take only my advise, though
[19:50:17 CEST] <mateo`> i've heard about the c api since a while and i'll look at it
[19:52:18 CEST] <mateo`> regarding the jni patches, i would be happy to have some review (i know it's not thread safe, but it's used in a thread-safe way afaik, maybe/probably i'm missing something)
[19:52:43 CEST] <mateo`> even though the patches might be dropped, because no jni in lav*
[20:03:58 CEST] <wm4> <j-b> so you have libavcodec using libstagefright using libavcodec <- I thought the point of using libstagefright was for hw decoding
[20:15:21 CEST] <Daemon404> presumably it is a fallback
[20:15:25 CEST] <Daemon404> due to sketchy device support
[20:50:01 CEST] <RiCON> ok, that's the last of them
[20:50:15 CEST] <RiCON> that's enough webvtt for now.
[20:58:47 CEST] <cone-480> ffmpeg 03Carl Eugen Hoyos 07master:d6cfbcd6219a: lavc/mjpegenc: Add an option to force outputting chroma matrix.
[21:18:54 CEST] <cone-480> ffmpeg 03wm4 07release/2.8:291a2f1ea7ea: avcodec/mp3: fix skipping zeros
[21:18:55 CEST] <cone-480> ffmpeg 03PrzemysBaw Sobala 07release/2.8:635831c08712: lavf/img2dec: Fix memory leak
[21:18:56 CEST] <cone-480> ffmpeg 03Paul B Mahol 07release/2.8:39df4d24751d: avcodec/pngdec: reset has_trns after every decode_frame_png()
[21:18:57 CEST] <cone-480> ffmpeg 03wm4 07release/2.8:b9841ba98c00: avformat/hls: fix some cases of HLS streams which require cookies
[21:18:58 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/2.8:7ec05ae96912: avformat/avidec: Workaround broken initial frame
[21:22:50 CEST] <cone-480> ffmpeg 03Ganesh Ajjanagadde 07master:2f4374fae135: ffmpeg: avoid possible undefined behavior
[21:38:32 CEST] <cone-480> ffmpeg 03Paul B Mahol 07master:35af7add6fac: avcodec/takdec: add x86 SIMD for rest of decorrelation modes
[21:39:04 CEST] <cone-480> ffmpeg 03Clément BSsch 07release/2.7:5ac6daf99568: avformat/srtdec: more lenient first line probing
[21:39:05 CEST] <cone-480> ffmpeg 03Clément BSsch 07release/2.7:6b6932471ece: avformat/srtdec: make sure we probe a number
[21:39:06 CEST] <cone-480> ffmpeg 03wm4 07release/2.7:114c0f002aa9: avcodec/mp3: fix skipping zeros
[21:39:07 CEST] <cone-480> ffmpeg 03PrzemysBaw Sobala 07release/2.7:2ef386d0a607: lavf/img2dec: Fix memory leak
[21:39:08 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/2.7:0fb4a85603b1: avcodec/ffv1: seperate slice_count from max_slice_count
[21:39:09 CEST] <cone-480> ffmpeg 03Ronald S. Bultje 07release/2.7:f7cb979766e8: hevc: fix wpp threading deadlock.
[21:39:10 CEST] <cone-480> ffmpeg 03Hendrik Leppkes 07release/2.7:98fdd0baf39c: hevc: properly handle no_rasl_output_flag when removing pictures from the DPB
[21:39:11 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/2.7:6752f8ef0401: avformat/avidec: Workaround broken initial frame
[21:39:12 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/2.7:1ef419447edc: avformat/segment: atomically update list if possible
[21:39:13 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/2.7:eee1faef752c: avformat/oggenc: Check segments_count for headers too
[21:39:14 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/2.7:8f00ff5ae03d: avcodec/h264_mp4toannexb_bsf: Reorder operations in nal_size check
[21:39:15 CEST] <cone-480> ffmpeg 03Rodger Combs 07release/2.7:6197d35a93bf: lavf/matroskadec: Fully parse and repack MP3 packets
[21:51:53 CEST] <cone-480> ffmpeg 03Clément BSsch 07release/2.6:6ed351c096ea: avformat/srtdec: more lenient first line probing
[21:51:54 CEST] <cone-480> ffmpeg 03Clément BSsch 07release/2.6:d75a5fe4b9e1: avformat/srtdec: make sure we probe a number
[21:51:55 CEST] <cone-480> ffmpeg 03wm4 07release/2.6:281dce1a3e06: avcodec/mp3: fix skipping zeros
[21:51:56 CEST] <cone-480> ffmpeg 03PrzemysBaw Sobala 07release/2.6:b0b37e018b38: lavf/img2dec: Fix memory leak
[21:51:57 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/2.6:ef6d6f89067d: avcodec/ffv1: seperate slice_count from max_slice_count
[21:51:58 CEST] <cone-480> ffmpeg 03Ronald S. Bultje 07release/2.6:488041cfb05b: hevc: fix wpp threading deadlock.
[21:51:59 CEST] <cone-480> ffmpeg 03Hendrik Leppkes 07release/2.6:3cc3d239f2ba: hevc: properly handle no_rasl_output_flag when removing pictures from the DPB
[21:52:00 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/2.6:108a971cd270: avformat/avidec: Workaround broken initial frame
[21:52:01 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/2.6:bd4351b5d778: avformat/oggenc: Check segments_count for headers too
[21:52:02 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/2.6:4afa76251188: avcodec/h264_mp4toannexb_bsf: Reorder operations in nal_size check
[21:52:03 CEST] <cone-480> ffmpeg 03Rodger Combs 07release/2.6:e43e2825120f: lavf/matroskadec: Fully parse and repack MP3 packets
[22:01:30 CEST] <cone-480> ffmpeg 03Clément BSsch 07release/2.5:2e575c1e8dd7: avformat/srtdec: more lenient first line probing
[22:01:31 CEST] <cone-480> ffmpeg 03Clément BSsch 07release/2.5:f2c07de0a5a7: avformat/srtdec: make sure we probe a number
[22:01:32 CEST] <cone-480> ffmpeg 03wm4 07release/2.5:9177bcc06ca5: avcodec/mp3: fix skipping zeros
[22:01:33 CEST] <cone-480> ffmpeg 03PrzemysBaw Sobala 07release/2.5:eb681e1fac2c: lavf/img2dec: Fix memory leak
[22:01:34 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/2.5:3b7d4d8bd63c: avcodec/ffv1: seperate slice_count from max_slice_count
[22:01:35 CEST] <cone-480> ffmpeg 03Ronald S. Bultje 07release/2.5:cac62c8ad9f1: hevc: fix wpp threading deadlock.
[22:01:36 CEST] <cone-480> ffmpeg 03Hendrik Leppkes 07release/2.5:7b6fced6b49f: hevc: properly handle no_rasl_output_flag when removing pictures from the DPB
[22:01:37 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/2.5:66b6ab355dc2: avformat/avidec: Workaround broken initial frame
[22:01:38 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/2.5:1024bcab6272: avformat/oggenc: Check segments_count for headers too
[22:01:39 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/2.5:8b158bf62cbd: avcodec/h264_mp4toannexb_bsf: Reorder operations in nal_size check
[22:02:08 CEST] <ubitux> durandal_1707: i think the labels need a ':'
[22:02:40 CEST] <ubitux> otherwise it won't build (or just warn?) with ancient assembler (nasm?)
[22:03:37 CEST] <ubitux> durandal_1707: see 844bef578ee0994a94bdd6ffe4099dddd6a9f136
[22:04:31 CEST] <jamrial> a warning, yeah
[22:09:49 CEST] <durandal_1707> BBB: i sent avx2 to ml
[22:12:05 CEST] <cone-480> ffmpeg 03Andreas Cadhalpun 07master:8d6625642db0: doc: fix spelling errors
[22:13:20 CEST] <BBB> durandal_1707: Ill try to have a look, Im a little busy trying to finish vp9 simd for 10/12bpp
[22:14:56 CEST] <cone-480> ffmpeg 03wm4 07release/2.4:f5ce1a762691: avcodec/mp3: fix skipping zeros
[22:14:57 CEST] <cone-480> ffmpeg 03PrzemysBaw Sobala 07release/2.4:13b34510b6bc: lavf/img2dec: Fix memory leak
[22:14:58 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/2.4:6e629b0b66c7: avcodec/ffv1: seperate slice_count from max_slice_count
[22:14:59 CEST] <cone-480> ffmpeg 03Ronald S. Bultje 07release/2.4:f085ce326563: hevc: fix wpp threading deadlock.
[22:15:00 CEST] <cone-480> ffmpeg 03Hendrik Leppkes 07release/2.4:4edb236c4972: hevc: properly handle no_rasl_output_flag when removing pictures from the DPB
[22:15:01 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/2.4:6b4a22b5e9b3: avformat/avidec: Workaround broken initial frame
[22:15:02 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/2.4:18f36c70ec7a: avformat/oggenc: Check segments_count for headers too
[22:22:17 CEST] <jamrial> durandal_1707: you're nuking the scalarproduct by zeroing eax at the end. that's definitely not right
[22:22:54 CEST] <jamrial> also, audiodsp.h mentions that dst and src in scalarproduct_int16 are 16 byte aligned
[22:23:19 CEST] <jamrial> an avx2 function like this requires 32 bytes aligment
[22:24:35 CEST] <nevcairiel> no unaligned loads on avx2? :d
[22:27:06 CEST] <jamrial> yeah, but not if you use mova :p
[22:27:32 CEST] <jamrial> oh, the function is using movu
[22:29:35 CEST] <rcombs> RiCON: I've got a patch series on the ML that adds support for XML-escaping WebVTT output
[22:30:43 CEST] <Gramner> durandal_1707: also just use xm2 unconditionally. it resolves to mm2 with INIT_MMX, and xmm2 with everything else
[22:31:18 CEST] <BBB> durandal_1707: why xor eax, eax?
[22:31:50 CEST] <BBB> and why if mmsize > 16 around it? that should always be true
[22:31:55 CEST] <durandal_1707> because that is never reached
[22:32:23 CEST] <durandal_1707> apparently not here
[22:33:41 CEST] <jamrial> xor eax, eax at the end is defintely not right. you're clearing the register that contains the return value of the function, effectively making it always return 0
[22:33:50 CEST] <BBB> so youre claiming that in a debugger, when you put a breakpoint on the avx2 function, it hits
[22:33:59 CEST] <BBB> and yet the xor is not executed
[22:33:59 CEST] <rcombs> why not `movd   eax, xm2 ` unconditionally?
[22:34:11 CEST] <BBB> rcombs: Gramner just said that too :)
[22:34:16 CEST] <rcombs> oh heh
[22:35:14 CEST] <BBB> durandal_1707: I want to see that breakpoint hit in a debugger before I believe that :-p
[22:35:23 CEST] <BBB> (and then type disass)
[22:36:10 CEST] <RiCON> rcombs: webvtt does not need " and ' escaping
[22:36:26 CEST] <rcombs> RiCON: right, so I don't escape those
[22:36:59 CEST] <RiCON> my patches do the opposite though
[22:37:07 CEST] <rcombs> I have flags for it but don't turn them on by default
[22:37:31 CEST] <RiCON> for those two only, right?
[22:37:47 CEST] <RiCON> <>& at least do need escaping
[22:37:52 CEST] <rcombs> right
[22:37:58 CEST] <rcombs> your patches are for the decoder, yeah?
[22:38:01 CEST] <RiCON> yes
[22:38:17 CEST] <cone-480> ffmpeg 03Christophe Gisquet 07master:25d3013e3615: fate: add DNxHD/HR tests
[22:38:40 CEST] <rcombs> so I've got the opposite end of it then :)
[22:40:55 CEST] <Gramner> durandal_1707: of course the xor eax, eax is reached. here's a disassembly of your patch: http://pastebin.com/RU2FgKjT
[22:47:45 CEST] <durandal_1707> Gramner: if i add invalid instruction like xorrrr inside mmsize > 16 block yasm consumes it
[22:48:26 CEST] <Gramner> it treats unknown identifiers as labels by default
[22:49:22 CEST] <durandal_1707> if i remove ifdefs it complains and aborts
[22:49:24 CEST] <Gramner> should probably add -Worphan-labels to the default assembler flags I guess
[22:50:07 CEST] <cone-480> ffmpeg 03wm4 07release/2.3:f57a595024d6: avcodec/mp3: fix skipping zeros
[22:50:07 CEST] <Gramner> I get an error if I create an invalid line there
[22:50:08 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/2.3:e2f0443af082: avcodec/ffv1: seperate slice_count from max_slice_count
[22:50:09 CEST] <cone-480> ffmpeg 03Ronald S. Bultje 07release/2.3:44184226acec: hevc: fix wpp threading deadlock.
[22:50:10 CEST] <cone-480> ffmpeg 03Hendrik Leppkes 07release/2.3:9e1b4939160c: hevc: properly handle no_rasl_output_flag when removing pictures from the DPB
[22:50:11 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/2.3:80a467b452e1: avformat/avidec: Workaround broken initial frame
[22:50:12 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/2.3:d40ab18c0719: avformat/oggenc: Check segments_count for headers too
[22:50:13 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/2.3:5279f5d0680a: avcodec/h264_mp4toannexb_bsf: Reorder operations in nal_size check
[22:50:39 CEST] <durandal_1707> Gramner: so there is avx2 with mmsize==16?
[22:50:51 CEST] <Gramner> btw there's an ASSERT macro in x86inc as well, so you can do stuff like ASSERT mmsize > 16
[22:50:58 CEST] <Gramner> INIT_XMM avx2 results in that
[22:51:22 CEST] <Gramner> mmsize is dependant on INIT_*, not on the particular cpuflag
[22:52:29 CEST] <kurosu> michaelni_, fixed both simple_idct bugs, but one requires generating new patches, so I'll send a new set later
[22:54:27 CEST] <Gramner> avx2 with xmm regs can be useful if you want variable vector shifts or broadcasts but don't need larger registers for example
[22:59:56 CEST] <durandal_1707> how i can measure speed up?
[23:00:57 CEST] <jamrial> libavutil/timer.h macros
[23:01:11 CEST] <jamrial> START_TIMER and STOP_TIMER
[23:04:05 CEST] <durandal_1707> so if avx2 give 2x more you get 0.2 more
[23:05:34 CEST] <Gramner> it it's 2x as fast you should get 0.5x the value, since it's a unit based on time
[23:11:15 CEST] <cone-480> ffmpeg 03Ganesh Ajjanagadde 07master:3be27e07d3c5: avcodec/mpegvideoenc: fix undefined negative left shift
[23:21:57 CEST] <ubitux> michaelni_: btw, i saw that skip_frame in AVCodecContext was enum and accessible through AVOption; i think you were interested in those cases
[23:22:12 CEST] <ubitux> there might be some others lying around following that pattern
[23:22:22 CEST] <ubitux> in case you're still concerned about those
[00:00:00 CEST] --- Sat Oct 10 2015