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

[burek]

[02:16:43 CET] <cone-161> ffmpeg 03Raymond Hilseth 07master:86db71b402e9: avformat/ftp: Support response code 125 for STOR and RETR commands
[03:11:34 CET] <rcombs> does stefano hang out here
[03:12:36 CET] <cone-161> ffmpeg 03Zhao Zhili 07master:6f5048f4a0f7: rtp: Fix play multiple multicast streams with the same port
[03:18:40 CET] <jamrial> rcombs: sometimes. his nick is saste
[03:18:53 CET] <rcombs> ah
[04:46:21 CET] <Timothy_Gu> good to see GCC vectorization actually doing something
[04:49:22 CET] <llogan> Timothy_Gu: as for your question regarding the version stuff. doesn't matter to me as long as the git short hash is there. that's all i really use.
[05:04:25 CET] <Timothy_Gu> llogan: ok
[06:47:01 CET] <Akanksha> what does index mean in streams. Sorry for naive questions. I am new to all these things. Thanks in advance. :)
[06:54:52 CET] <Timothy_Gu> Akanksha: go to #ffmpeg
[06:55:23 CET] <Timothy_Gu> usually it's the id assigned to the stream in the container
[10:44:23 CET] <ubitux> i'm so confused at the way the skip samples thing is supposed to be handled
[10:56:18 CET] <mateo`> Hello o/, I'm about to push the mediacodec patchset as no one objected, but I want to double check, so ... any objections before I push ?
[11:15:08 CET] <ubitux> wth do we have public functions such as av_dv_codec_profile() and av_dv_codec_profile2()
[11:18:10 CET] <ubitux> static const int32_t av_sqrttbl_sf
[11:18:12 CET] <ubitux> meeh
[11:18:26 CET] <nevcairiel> a static av table?
[11:18:49 CET] <nevcairiel> oh its in a header
[11:19:03 CET] <nevcairiel> stupid softfloat crap
[11:19:09 CET] <nevcairiel> build float into your CPUs, MIPS!
[11:19:29 CET] <ubitux> just like av_dv shitcrap, i suppose av_dirac_parse_sequence_header() should be avpriv?
[11:20:17 CET] <nevcairiel> avpriv isnt very popular, and not that much harm to just expose it
[11:20:34 CET] <ubitux> av_downmix_info_update_side_data() do we really need this exposed?
[11:22:01 CET] <nevcairiel> probably not, the function is super trivial and only used once
[11:22:16 CET] <ubitux> av_xiphlacing @_@
[11:22:44 CET] <ubitux> av_subtitle_rect_class wut
[11:31:39 CET] <cone-599> ffmpeg 03Matthieu Bouron 07master:3ab178516ec8: lavc: add JNI support
[11:31:39 CET] <cone-599> ffmpeg 03Matthieu Bouron 07master:4737fe6907d2: lavc: add h264 mediacodec decoder
[11:42:20 CET] <ubitux> http://codeology.braintreepayments.com/ffmpeg/ffmpeg what am i looking at
[11:54:03 CET] <JEEB> oh nice, mediacodec's in
[11:55:49 CET] <mateo`> JEEB: yeah :), next step is implementing the hwaccel part.
[12:00:41 CET] <cone-599> ffmpeg 03Carl Eugen Hoyos 07master:b872b98bb466: lavfi/extractplanes: Move endianness calculation up.
[12:00:42 CET] <cone-599> ffmpeg 03Carl Eugen Hoyos 07master:0ba844a053da: lavfi/extractplanes: Fix in_pixfmts.
[12:03:50 CET] <nevcairiel> evil hacks are evil https://github.com/dwbuiten/FFmpeg/commit/a3b54e814c932f93982b12d063fcac42d529d470
[12:06:13 CET] <mateo`> is there still some help needed to port lavf to the codecpar api changes ?
[12:06:38 CET] <cone-599> ffmpeg 03Carl Eugen Hoyos 07master:bba9bed3f3b1: lavfi/extractplanes: Add RGB0 and friends as supported pix_fmts.
[12:15:53 CET] <ubitux> wm4: you sure it was a vplayer file btw? extension was... txt?
[12:16:05 CET] <wm4> ubitux: srt
[12:16:12 CET] <ubitux> lol
[12:16:16 CET] <wm4> yeah
[12:16:37 CET] <wm4> at least from what I remember
[12:20:37 CET] <wm4> apropos probe failures, there are a lot of ass files with "unexpected" file headers
[12:21:21 CET] <nevcairiel> i documented a bunch of failing fate tests on etherpad, if anyone feels bored
[12:22:11 CET] <nevcairiel> unexpectedly, a bunch of avfilter tests fail
[12:22:31 CET] <wm4> huh
[12:23:44 CET] <nevcairiel> wonder if maybe the crc muxer is broken or something =P
[12:32:25 CET] <nevcairiel> and a bunch of h264 tests fail, probably has_b_frames related
[12:33:25 CET] <wm4> why would anything fail without has_b_frames?
[12:34:00 CET] <nevcairiel> because it drops frames then
[12:35:02 CET] <wm4> shouldn't it instead assume the maximum delay possible?
[12:35:16 CET] <nevcairiel> it cant differentiate between 0 and unset though =p
[12:36:09 CET] <nevcairiel> should probably just expose has_b_frames again somehow, its kinda handy to have avformat find out this value
[12:42:38 CET] <cone-599> ffmpeg 03Matthieu Bouron 07master:81f14884b593: lavc/mjpegdec: avoid unneeded allocation if the frame is to be skipped
[12:53:15 CET] <cone-599> ffmpeg 03Clément BSsch 07master:920f592b81c7: lavf/vplayerdec: support time durations with no ms specified
[12:53:41 CET] <wm4> lol this bug report cehoyos just created doesn't have "full, uncut console output"
[12:53:52 CET] <wm4> instead some output is skipped
[12:53:53 CET] <ubitux> wm4: can you share the ass sample?
[12:54:32 CET] <ubitux> vplayer should be fixed in last commit
[12:54:57 CET] <wm4> ubitux: mpv issues 2846, 2821, 2506
[12:55:31 CET] <wm4> here's apparently a sample, unfortunately zipped https://github.com/mpv-player/mpv/files/129635/sample-ass.zip
[12:55:50 CET] <wm4> some ass scripts miss [Script Info] completely
[12:57:46 CET] <ubitux> that sample looks supported
[12:58:03 CET] <ubitux> i remember adding a check for that
[12:59:31 CET] <ubitux> should i look for "[Aegisub Project Garbage]" instead? :D
[13:00:10 CET] <ubitux> wm4: can you should me a sample where the "[Script Info]" is missing?
[13:00:16 CET] <ubitux> i want to check if it's missing the whole section
[13:00:19 CET] <ubitux> or just that line
[13:00:40 CET] <ubitux> if it's the whole section, i can just look for [V4+ Styles] or whatever
[13:01:37 CET] <wm4> I asked for a sample
[13:01:39 CET] <ubitux> wm4: so #2506 is closed, #2821 should be closed as well since it's the same issue
[13:10:38 CET] <ubitux> wm4: any other issue?
[13:11:04 CET] <ubitux> if everything goes well, i might receive the GB of text subtitles samples today... 
[13:11:13 CET] <ubitux> it's gonna be fun
[13:13:11 CET] <wm4> not that I know of
[13:16:02 CET] <j-b> I don't get this JNI patch, tbh.
[13:17:13 CET] <wm4> why not
[13:17:30 CET] <j-b> Why not use directly the JNI_OnLoad?
[13:17:59 CET] <wm4> whatever that is
[13:27:49 CET] <wm4> so where are those protocol whitelists stored?
[13:28:09 CET] <wm4> oh, .default_whitelist   = "http,https,tls,rtp,tcp,udp,crypto"
[13:32:13 CET] <JEEB> ok, my rpi3 finally arrived
[13:33:27 CET] <cone-599> ffmpeg 03Paul B Mahol 07master:f659b70eb093: avfilter/vf_waveform: draw graticule for color filter too
[13:34:48 CET] <wm4> meanwhile everyone is hyping that odroid thing
[13:36:24 CET] <ubitux> competition, faster
[13:36:45 CET] <ubitux> heat issue with rpi3 apparently too
[13:37:03 CET] <nevcairiel> still comes wihtout a heaksink by default?
[13:37:13 CET] <nevcairiel> heat*
[13:38:17 CET] <wm4> it comes without anything by default
[13:38:37 CET] <nevcairiel> the previous models already benefit from adding a small heatsink
[13:38:47 CET] <JEEB> I'll just leave it in the snow and ice
[13:38:54 CET] <ubitux> you can buy one
[13:38:54 CET] <JEEB> probably helps
[13:38:58 CET] <mateo`> j-b: because for an unknown reason I thought that I couldn't use it there (even though I use it in other places in Android apps)
[13:40:27 CET] <j-b> mateo`: if the goal is libavcodec+libavformat, then, I believe it's a cleaner way to get the JavaVM* than having an API that might be wrongly used.
[13:40:52 CET] <wm4> didn't we discuss this to exhaustion
[13:41:45 CET] <mateo`> wm4: we discussed it, but I haven't proposed the use of JNI_onLoad (which solve the issue)
[13:42:02 CET] <jkqxz> The HiKey one is a bit of a joke in that respect.  It can barely run above 200MHz if you use all the cores, so performance testing on it is very tricky.
[13:42:41 CET] <mateo`> so I will do a patch that uses JNI_onLoad, and remove the public API part
[13:43:12 CET] <j-b> mateo`: it's just a suggestion.
[13:43:18 CET] <wbs> if you link libavcodec statically into a lib that already has a JNI_OnLoad of its own, won't that be an issue?
[13:43:30 CET] <j-b> it would, yes.
[13:43:39 CET] <j-b> mateo`: it requires people to use the Load Library from the Java
[13:44:03 CET] <mateo`> ok, (then this is why i didn't think of using JNI_onLoad)
[13:45:29 CET] <j-b> I'd argue it's cleaner, and avoid the calling twice the call to set the JavaVM*
[13:45:34 CET] <j-b> but it's debatable.
[13:46:53 CET] <mateo`> wbs: what's your opinion ?
[13:47:02 CET] <wm4> the call to set the VM can be avoided on newer android versions
[13:47:07 CET] <wm4> from what I undestood
[13:47:23 CET] <wm4> as in, the lavc jni code can get the VM automatically
[13:47:38 CET] <j-b> well, you cannot change the VM from your process, as far as I know.
[13:47:38 CET] <mateo`> yes by calling their private API
[13:55:29 CET] <wbs> mateo`: in which versions does JNI_GetCreatedJavaVMs work? and what does _ZN13JniInvocation15jni_invocation_E gain? does the latter startup the necessary IPC communication and whatnot, to make it work for commandline ffmpeg?
[13:58:29 CET] <mateo`> wbs: from Android 4.4.2 (not too sure about the micro version), checking if _ZN13JniInvocation15jni_invocation_E is initialized just guarantee that we can safely use JNI_GetCreatedVMs
[13:59:05 CET] <mateo`> otherwise it will crash (https://android.googlesource.com/platform/libnativehelper/+/idea133/JniInvocation.cpp)
[13:59:55 CET] <wbs> mateo`: oh, ok
[13:59:56 CET] <mateo`> and it does not start the necessary IPC communcation for commandline :(
[14:00:38 CET] <wbs> ok - that's probably not too interesting in practice though, other than for testing. (although some people ship apps with ffmpeg/avconv binaries and invoking those, instead of using the API)
[14:02:20 CET] <wbs> mateo`: when called from within a lib, in which cases would JNI_GetCreatedVMs crash? is there any way of running a lib within an app without actually having the full JVM running and set up already?
[14:03:27 CET] <mateo`> I don't think there is a way of running an app without having a full jvm running
[14:03:45 CET] <mateo`> (AFAIK)
[14:05:41 CET] <wbs> indeed, so the jni invocation stuff is just academic safetychecking then, right?
[14:07:42 CET] <mateo`> the check of _ZN13JniInvocation15jni_invocation_E before using JNI_GetCreatedVMS is ( when running the lib under an app) but if it happens that the lib is ran from the commandline without vm it will crash
[14:08:14 CET] <wbs> ah, yes, then it makes sense
[14:08:25 CET] <mateo`> the use of this api remove the need of calling av_jni_set_java_vm on newer devices
[14:09:45 CET] <mateo`> but in practice, since this is private api, i don't for how much time we will be able to call it
[14:10:12 CET] <wbs> yeah, having av_jni_set_java_vm allows to avoid the dependency on private api, that's always nice
[14:18:50 CET] <Daemon404> _ZN13JniInvocation15jni_invocation_E?
[14:18:56 CET] <Daemon404> is that zome C++ mangling?
[14:18:59 CET] <Daemon404> some*
[14:19:06 CET] <mateo`> exactly
[14:19:23 CET] <Daemon404> is it safe to call it from C like that even?
[14:19:27 CET] <Daemon404> stable, rather
[14:20:18 CET] <wbs> Daemon404: "echo <foo> | c++filt" to unmangle it
[14:20:38 CET] <ismail> c++-filt <foo> works
[14:20:56 CET] <ismail> without the minus of course
[14:21:03 CET] <Daemon404> what's C++-filt? some android thing?
[14:21:12 CET] <wbs> and it's safe to call such things from C, but it's all private API so you can't of course rely on it existing and behaving well
[14:21:12 CET] <ismail> Daemon404: c++ demangler from binutils
[14:21:14 CET] <Daemon404> ah
[14:21:35 CET] <Daemon404> wbs, i suppose you must manually pass the first arg as 'this'?
[14:21:49 CET] <wbs> Daemon404: if it's a non-static method, yeah, but afaik this one is static
[14:21:58 CET] <Daemon404> right
[14:22:13 CET] <Daemon404> my knowledge of how c++ behaves after compilation is limited to REing crappy C++ codecs
[14:22:45 CET] <wbs> on some architectures (32 bit x86 on msvc at least), you can't easily call C++ methods from C at all, since the this pointer isn't passed in the same way as normal parameters, i.e. in a register instead of on the stack
[14:23:30 CET] <Daemon404> hex rays displays it as a first param when it decompiels x86 c++ dlls made with msvc
[14:23:35 CET] <Daemon404> so i geuss it mislead me
[14:24:16 CET] <wbs> https://en.wikipedia.org/wiki/X86_calling_conventions#thiscall
[14:25:20 CET] <wm4> guys, the mangled symbol is not a function
[14:25:22 CET] <wm4> just a variable
[14:25:52 CET] <wbs> ah, even better
[14:26:09 CET] <wm4> and it's because google devs can't code
[14:26:23 CET] <wm4> we check if it's NULL, and if it is, we avoid calling the public API because it'd crash
[14:26:51 CET] <wm4> (which is also why the public API is useless...)
[14:27:53 CET] <wm4> ubitux: https://dl.dropboxusercontent.com/u/3988935/%5BVCB-Studio%5DPSYCHO-PASS%5B01%5D%5BHi10p_1080p%5D%5Bx264_flac%5D.TxxZ%26A.I.R.nesSub.ass
[14:28:08 CET] <wm4> "; [Script Info]"
[14:28:39 CET] <ubitux> thefuck
[14:28:55 CET] <ubitux> so i'm supposed to support this?
[14:29:19 CET] <wm4> yep
[14:29:29 CET] <wm4> after all, vshitler does
[14:29:42 CET] <wm4> (it doesn't care about sections at all btw.)
[14:29:54 CET] <ubitux> ============================================================
[14:29:58 CET] <ubitux> this line isn't even commented
[14:43:53 CET] <cone-599> ffmpeg 03Matthieu Bouron 07master:8c24523cc52b: lavc/mediacodec: fix chroma width for yuv420p
[14:49:58 CET] <Daemon404> http://pastebin.com/KMuZPqJQ
[14:50:07 CET] <Daemon404> why am i suddenly getting so many of these sorts of emails
[14:50:17 CET] <Daemon404> too many git lgo entries with my name
[14:50:19 CET] <Daemon404> ?
[14:52:13 CET] <DHE> I get spam. I've just disabled the mailbox entirely as a result
[14:52:42 CET] <nevcairiel> i get such mails about LAV all the time, I just answer with a blanket response that i do not provide email support
[14:52:53 CET] <nevcairiel> not about ffmpeg tho
[14:55:36 CET] <ubitux> wm4: it's going to be a bit hard for probing
[14:55:49 CET] <ubitux> i mean, i can fix that particular sample by ignoring ';' but...
[14:55:59 CET] <ubitux> btw, it works if you for the format as ass
[14:56:27 CET] <ubitux> do you know any app where the probing of such file does actually work?
[14:56:57 CET] <ubitux> i assume whatever you feed vsfilter with, it will consider it as ass so...
[14:58:09 CET] <ubitux> s/if you for/if you force/
[15:01:19 CET] <wm4> ubitux: mpc-hc, vlc, ...
[15:01:40 CET] <wm4> as I said, vsvilter doesn't even look at the section headers
[15:01:45 CET] <wm4> or most of them
[15:02:39 CET] <ubitux> aren't they relying on the extension?
[15:02:51 CET] <ubitux> or do we really need to look every line for a "Dialogue" line?
[15:02:59 CET] <wm4> don't know
[15:03:10 CET] <ubitux> i'm not sure how to proceed here
[15:11:04 CET] <wm4> ubitux: the only problem I see is accidentally probing mkv files
[15:11:27 CET] <ubitux> mkv files do not contain "Dialogue"
[15:11:31 CET] <ubitux> well, at least theorically
[15:11:38 CET] <ubitux> the actually could if they are commented
[15:11:40 CET] <ubitux> :D
[15:11:58 CET] <ubitux> but "\nDialogue: " should work
[15:12:05 CET] <ubitux> i'm just concerned about the speed in this case
[15:13:24 CET] <ubitux> it might slow down probing significantly
[15:13:34 CET] <kierank> lol "critical"
[15:15:21 CET] <wm4> ubitux: just from scanning a few KB of text (at most) for a static string?
[15:17:20 CET] <ubitux> remember how using a scanf in srt was slowing down shit?
[15:17:30 CET] <wm4> but that was scanf
[15:17:50 CET] <Compn> Daemon404 : guess you need a copy and paste reply telling them to use ffmpeg-user ?
[15:18:06 CET] <ubitux> wm4: well, i'll submit a patch with a strstr later
[15:18:15 CET] <Daemon404> Compn, indeed i will
[16:05:02 CET] <mateo`_> i'm a bit confused, the frames of an aac sample say, nb_samples=1024, pkt_duration=993 using ffprobe. The stream duration reflects the 993 samples per packet (and not the 1024 ones) is that common ?
[16:06:04 CET] <nevcairiel> is that the last one?
[16:06:16 CET] <mateo`_> nope, all the packets are like that
[16:06:36 CET] <nevcairiel> maybe the timebase is screwed up
[16:07:08 CET] <nevcairiel> ie. its not based on samples
[16:07:50 CET] <mateo`_> the time base looks good, ie: 1/44100
[16:09:02 CET] <mateo`_> nevcairiel: you confirm it shouldn't be like that (except on the last packet) ?
[16:09:40 CET] <nevcairiel> if the timebase equals the sample rate, then having duration and num samples be different sounds weird
[16:14:04 CET] <ubitux> michaelni: double p = -2.196152422706632; (libswscale, spline code), is this 3*(1-sqrt(3)) or just a coincidence?
[16:17:30 CET] <ubitux> i lack too much knowledge about this code to have meaningful remarks but it looks like it could involve the filter parameter 
[16:17:51 CET] <ubitux> sth like param * (1-sqrt(3)), like in other algorithms
[16:35:50 CET] <Daemon404> man... the OBB website has some iffy english
[16:41:33 CET] <Daemon404> eh, too early to buy it seems.
[17:10:05 CET] <Daemon404> nevcairiel, you say ffserver will die, then why are you fixing ffm>
[17:10:10 CET] <Daemon404> surely ffm would die with ffserver
[17:11:09 CET] <nevcairiel> it works as long as the deprecated api is available
[17:11:21 CET] <Daemon404> hurr hurr
[17:11:30 CET] <nevcairiel> (and you use it)
[17:11:36 CET] <wm4> does it really? then why are we fixing all the deprecations inside the merge?
[17:11:37 CET] <nevcairiel> no clue if ffserver uses ffmpeg.c in some capacity
[17:12:32 CET] <nevcairiel> wm4: because you would otherwise have an inconsistent state where some things work with new and some with old
[17:12:38 CET] <nevcairiel> ffm doesnt work with new, at all =p
[17:13:34 CET] <nevcairiel> in any case, if it uses ffmpeg.c, then it will likely break again once thats moved to the new API
[17:13:41 CET] <nevcairiel> if its entirely standalone, it should remain working
[17:14:20 CET] <nevcairiel> its not like the fix for ffmdec was complicated
[17:14:28 CET] <wm4> oh I see, so utils.c won't translate new API to old API for old (de)muxers
[17:16:16 CET] <Daemon404> lol "entirely standalone"
[17:16:21 CET] <Daemon404> it cosumes internal APIs
[17:16:53 CET] <nevcairiel> you know what i mean, now resume productivity!
[17:17:48 CET] <durandal_1707> can't it be rewritten?
[17:18:00 CET] <nevcairiel> durandal_1707: go for it, we expect results in three days
[17:19:04 CET] <wm4> those who want to keep it can rewrite it - or it goes
[17:19:23 CET] <Daemon404> the entire concept seems just wrong to me
[17:19:24 CET] <Daemon404> but eh
[17:19:44 CET] <wm4> of course a rewrite should use only public API
[17:20:54 CET] <durandal_1707> and what it is using?
[17:21:12 CET] <durandal_1707> private only fields?
[17:21:28 CET] <Daemon404> it acceses ->internal among otehr things
[17:21:35 CET] <Daemon404> and uses a special format to 'serialize' an avctx
[17:26:56 CET] <durandal_1707> well if it must access internal things than the only solution is to expose it
[17:27:08 CET] <nevcairiel> it doesnt have to, its just the lazy way
[17:27:11 CET] <Daemon404> yeah
[17:27:18 CET] <Daemon404> i told them to fix it properly
[17:27:31 CET] <Daemon404> all i got in response was "it's in the TODO, and i always finish my TODOs"
[17:27:35 CET] <Daemon404> oh look. you didn't.
[17:27:46 CET] <wm4> "them"?
[17:27:51 CET] <nevcairiel> hey he didnt give yo ua time frame
[17:27:54 CET] <Daemon404> the maintainer
[17:32:12 CET] <durandal_1707> you mean it can be fixed without adding new API?
[17:32:32 CET] <Daemon404> yes.
[17:32:54 CET] <Daemon404> at least the exisiting problems can
[17:32:59 CET] <Daemon404> im not sure it can be after TEP2
[17:33:36 CET] <nevcairiel> the current ffm implementation is clearly an API violation, if someone wanted to communicate an entire AVCodecContext, that shouldnt happen in a mxuer
[17:34:55 CET] <Daemon404> the entire concept is dumb
[17:34:59 CET] <Daemon404> you shouldnt be doing that anyway
[17:35:14 CET] <ubitux> Daemon404: after tep2 is merged, send a patch to drop it
[17:35:19 CET] <ubitux> we'll probably have to vote though
[17:35:34 CET] <Daemon404> ubitux, as i said before, i expect full scale riots
[17:35:35 CET] <nevcairiel> i have no idea why it does that, just wants to allow configuring everything on the client side i suppose?
[17:35:46 CET] <Daemon404> nevcairiel, it's the only thing ever that works this way
[17:35:53 CET] <ubitux> Daemon404: we have a vote system, let's make use of it
[17:36:00 CET] <Daemon404> sure.
[17:36:16 CET] <Daemon404> i expect there will be heavy "but it's a FEATURE" and "we cant DROP code" resistance
[17:36:23 CET] <Daemon404> mostly from old timey moplayer guys
[17:36:25 CET] <Daemon404> mplayer*
[17:36:31 CET] <nevcairiel> what will happen: some people will ignore the system and put up some kind of ultimatum, and the more peaceful people will cave
[17:36:35 CET] <nevcairiel> ie. we dont have a working system
[17:36:42 CET] <Daemon404> oh you mean like hwaccel
[17:36:43 CET] <Daemon404> :)
[17:38:08 CET] <ubitux> we are accumulating delay in the merges, and if we haven't enough manpower to hold our balls and chain we should just get rid of them
[17:38:22 CET] <ubitux> let's not call for witches before the vote happens
[17:39:28 CET] <Daemon404> were not really far behind in merges
[17:39:54 CET] <nevcairiel> i even "fixed" ffserver for the one we're currently working on, just need to fix everything else :p
[17:40:51 CET] <ubitux> tep2 lavf, tep2 lavc, tep2 tools, bsfv2, (soon hwaccelv2?), dozens of random commits
[17:40:52 CET] <kierank> Daemon404: or carl
[17:40:54 CET] <kierank> fuck carl
[17:41:07 CET] <Daemon404> hey i didnt mention him.
[17:41:18 CET] <Daemon404> ubitux, except i think they are all net improvements
[17:41:37 CET] <Daemon404> all the problems we run into merging are because of retarded shit in ffmpeg's codebase
[17:41:42 CET] <Daemon404> that shouldnt have been done in the first place
[17:41:59 CET] <ubitux> never said they weren't improvements, i actually support the merge
[17:42:07 CET] <wm4> and yet certain people tell us these things in the code are ok...
[17:42:11 CET] <ubitux> and i believe that's kind of a priority
[17:42:15 CET] <Daemon404> i agree
[17:42:28 CET] <Daemon404> whats left to do for TEP2?
[17:42:34 CET] <Daemon404> now that im not in weekend lazymodo
[17:42:36 CET] <nevcairiel> fix all the things
[17:42:43 CET] <Daemon404> grepping n' fixing?
[17:42:53 CET] <nevcairiel> the pad has most info
[17:43:05 CET] <Daemon404> all praise The Pad
[17:43:16 CET] <wm4> are there still files with deprecation warnings?
[17:43:46 CET] <nevcairiel> there are a bunch of lib*.c files which still use the old way
[17:44:18 CET] <nevcairiel> mov(enc) seems entirely broken for some reason
[17:44:20 CET] <wm4> what was the resolution for micrtodvd?
[17:44:26 CET] <nevcairiel> and we have to decide what to do about has_b_frames
[17:44:27 CET] <mateo`_> where the pad located at ? I'd like to participate (if I have time)
[17:44:28 CET] <wm4> bleh
[17:44:33 CET] <Daemon404> mateo`_, https://public.etherpad-mozilla.org/p/ffmpeg-tep2-merge
[17:44:44 CET] <Daemon404> i can add you to collaborators
[17:44:46 CET] <Daemon404> if you wish to push
[17:45:06 CET] <ubitux> are we going to push the lavf work before we start merging lavc? 
[17:45:18 CET] <ubitux> so we can have a first wave of fixes in between 
[17:45:30 CET] <Daemon404> ubitux, probably a better idea not to push all that stuff at once
[17:45:54 CET] <Daemon404> and it builds up less of a giant code dump
[17:45:55 CET] <nevcairiel> lavc is not impacted by this tep
[17:46:06 CET] <mateo`_> Daemon404: you need a github account for that ?
[17:46:11 CET] <Daemon404> mateo`_, yes
[17:46:25 CET] <Daemon404> i dont think github lets you add non-github people
[17:46:31 CET] <mateo`_> Daemon404: my account is mbouron
[17:46:48 CET] <ubitux> nevcairiel: yes i know (there are a few changes though), i was wondering if we were going to push the 2 merge commits respectively for tep2-lavf and tep2-lavc at the same time 
[17:46:55 CET] <Daemon404> done
[17:46:57 CET] <Daemon404> @ mateo`_ 
[17:47:05 CET] <mateo`_> Daemon404: thanks
[17:49:06 CET] <nevcairiel> Daemon404: and why would the packet size change? sounds fishy :)
[17:49:24 CET] <Daemon404> nevcairiel, because it uses nut
[17:49:27 CET] <Daemon404> for ffprobe*
[17:49:35 CET] <nevcairiel> thats not an explanation
[17:49:44 CET] <nevcairiel> why do nut packets suddenly change size then?
[17:50:06 CET] <Daemon404> i need to re-read, but somethig similar happened i na recent merge of nut
[17:50:08 CET] <Daemon404> lemme dig it up
[17:50:22 CET] <nevcairiel> nut is one of the things were all related tests seem to fail, anyway
[17:50:25 CET] <nevcairiel> needs revisiting
[17:50:42 CET] <Daemon404> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=14a69ae60c64a071eb65a8521bf3c339322f5903
[17:51:53 CET] <Daemon404> padding related i think
[17:53:03 CET] <nevcairiel> someone should figure out why avfilter barfs at us
[17:53:05 CET] <nevcairiel> that seems unrelated
[17:53:08 CET] <nevcairiel> unless also nut :p
[17:53:11 CET] <Daemon404> nevcairiel, looks related to vlcs
[17:53:27 CET] <Daemon404> does nut pack headers?
[17:54:12 CET] <durandal_1707> nevcairiel: what in lavfi barfs?
[17:54:19 CET] <nevcairiel> everything
[17:55:00 CET] <durandal_1707> because of codecpar?
[17:55:37 CET] <nevcairiel> oh the video_filter test uses nut encoding
[17:55:41 CET] <nevcairiel> thats probably a reason then
[17:55:49 CET] <Daemon404> i image most of these failures are nut or mov
[17:56:30 CET] <nevcairiel> should probably fix those to get a cleaner view of whats happening
[17:57:17 CET] <Daemon404> i dont know if it will be easy to 'fix'
[17:57:32 CET] <Daemon404> it uses ff_get_v_length to find the minimal amount of bytes it can use to write given values
[17:57:40 CET] <Daemon404> so even if they change slightly, which may be expected
[17:57:44 CET] <Daemon404> packet sizes change
[17:58:07 CET] <Daemon404> and fate is hash based
[17:58:18 CET] <nevcairiel> any why would such a function change behavior
[17:58:56 CET] <nevcairiel> if we write something differently to before, thats a bug first, unless we can prove the new value is clearly better
[17:59:28 CET] <Daemon404> in the case i saw before, it was "both values are equally dumb"
[18:02:34 CET] <nevcairiel> the nut muxer doesnt seem to access anything too crazy, unless it was removed entirely in the merge somewhere
[18:02:45 CET] <nevcairiel> should diff it, i suppose
[18:04:54 CET] <nevcairiel> the only thing it accesses is has_b_frames, which raw video shouldnt set
[18:07:20 CET] <Daemon404> hmm
[18:07:25 CET] <Daemon404> can you diff the fate results?
[18:07:34 CET] <Daemon404> ffprobe ones should make it clear what changed
[18:07:43 CET] <Daemon404> ffprobe_json should be easy
[18:09:20 CET] <ubitux> oh, ffmpeg/libswscale is mentioned in http://www.ipol.im/pub/art/2011/g_lmii/
[18:09:49 CET] <nevcairiel> looks like the codec timebase is something it previously wanted
[18:10:03 CET] <nevcairiel> i wonder why anton didnt want to keep that, so many formats seem to want it somehow
[18:10:18 CET] <Daemon404> i keep asking, and people keep not answer
[18:10:21 CET] <Daemon404> *what is codec timebase*
[18:11:17 CET] <bencoh> :]
[18:11:27 CET] <durandal_1707> nonsense, it shouldnt exist
[18:11:41 CET] <bencoh> agreed
[18:11:52 CET] <Daemon404> people cant even tell me what it is, so i am erring on "this was wrong to begin with"
[18:12:31 CET] <nevcairiel> many coded formats encode timing information in the bitstream, that.
[18:12:37 CET] <nevcairiel> for some reason some containers want to know it
[18:13:11 CET] <durandal_1707> write parsers
[18:13:17 CET] <Daemon404> nevcairiel, nut doesnt use it for anything other than writing r_frame_rate metadata
[18:13:26 CET] <Daemon404> in which case... why the hell doesnt it use st->time_base?
[18:13:32 CET] <Daemon404> it tries st->frame_rate above first too
[18:13:44 CET] <nevcairiel> because nut controls st->time_base
[18:13:49 CET] <nevcairiel> it has nothing to do with the incoming data
[18:13:53 CET] <Daemon404> ah right
[18:14:06 CET] <Daemon404> so why does it need to write r_frame_rate when there is no framerate given
[18:14:20 CET] <wm4> how the hell do parsers work now at all
[18:14:32 CET] <ethe> eeyyy rekt
[18:14:38 CET] <ethe> jack outdev working
[18:25:29 CET] <jamrial_> the trailing_padding field in codecpar, is it meant to do the same thing we're doing with AV_PKT_DATA_SKIP_SAMPLES?
[18:28:05 CET] <wm4> jamrial_: yes
[18:28:30 CET] <wm4> to be honest, I don't know how the trailing_padding field is supposed to be applied
[18:28:40 CET] <wm4> you rarely know whether something is the last packet/frame
[18:29:37 CET] <jamrial> libav doesn't seem to be using it yet. at leat the lavf commit we're currently messing with didn't touch it
[20:01:00 CET] <nevcairiel> so i've been getting an report that some odd mp3 files start playing with an audible glitch, and i was looking into them. the files look like they had an id3 tag cut off incompletely, and now the file just happens to start at a string
[20:01:07 CET] <nevcairiel> said string has a utf8 bom for some reason
[20:01:16 CET] <nevcairiel> .... and a bom looks like a valid mpeg audio header
[20:01:21 CET] <nevcairiel> fuck this mp3 format
[20:01:32 CET] <kierank> everything is an mp3
[20:01:39 CET] <nevcairiel> well the file is an mp3
[20:01:46 CET] <nevcairiel> but i wanted to skip the garbage
[20:01:51 CET] <nevcairiel> but it appers somewhat valid =p
[20:03:08 CET] <nevcairiel> for some reason one other mpeg decoder seems to not have this problem
[20:03:11 CET] <nevcairiel> i wonder what it does
[20:07:40 CET] <J_Darnley> crc check maybe
[20:07:56 CET] <J_Darnley> if it fails, play silence
[20:08:05 CET] <nevcairiel> where would i get a crc from =p
[20:08:38 CET] <jamrial> the format's crc field nobody uses, of course
[20:09:21 CET] <nevcairiel> i dont even know where i would find a spec on this mp3 format, mpeg-2 audio i suppose?
[20:10:36 CET] <J_Darnley> but a not-mp3 frame might say "crc: yes" which then fails to match
[20:15:40 CET] <relaxed>  /quit
[20:23:06 CET] <jamrial> kierank: ^
[20:36:51 CET] <iive> nevcairiel: it's mpeg1 layer3
[20:51:04 CET] <kierank> can't remember if I implemented that stuff
[20:55:22 CET] <jamrial> you implemented the opus in mpegts demuxing code, yes
[20:55:42 CET] <jamrial> commit 9cfa68c560bdec82d2d5ec079f9c5b0f9ca37af0
[20:56:13 CET] <kierank> I mean the preskip thing
[21:02:31 CET] <jamrial> no, this is about the trailing padding information (or discard samples/padding) for the last Opus frame
[21:02:48 CET] <jamrial> preskip is codecdelay or initial padding, afaik
[21:25:20 CET] <ubitux> damn, flif marketting strikes back after 1yr
[21:31:48 CET] <durandal_1707> are there lossless compresed derf samples?
[21:50:43 CET] <cone-792> ffmpeg 03Clément BSsch 07master:2b7a61cbd8ae: lavc/utils: fix extra ASS sanity check in convert_sub_to_old_ass_form()
[22:39:19 CET] <cone-792> ffmpeg 03Paul B Mahol 07master:f20cdcbc055d: avfilter/vf_vectorscope: draw color points names
[23:01:35 CET] <cone-792> ffmpeg 03Michael Niedermayer 07master:da904faaa546: avcodec: try to document timebase a bit more
[23:02:33 CET] <TD-Linux> durandal_1707, I maintain those samples, what sort of compression do you mean?
[23:03:34 CET] <durandal_1707> xiph ones?
[23:03:59 CET] <TD-Linux> https://media.xiph.org/video/derf
[23:05:23 CET] <durandal_1707> just y4m in gigs ffv1 could lower it
[23:06:44 CET] <TD-Linux> durandal_1707, yeah currently some of them are xz'd, ffv1 might be a better choice
[23:30:33 CET] <TD-Linux> durandal_1707, I assume matroska is the preferred container for ffv1?
[23:31:46 CET] <durandal_1707> its fine
[23:58:27 CET] <cone-792> ffmpeg 03Carl Eugen Hoyos 07master:51bcc0bf38d8: lavf/riff: Add fourcc GTM4 from Telefactor digital audio for ASP.
[00:00:00 CET] --- Tue Mar  8 2016