[02:38] <cone-658> ffmpeg.git 03Thilo Borgmann 07master:dd16a0d8cced: lavd/avfoundation: Add basic PCM audio support. [02:57] <michaelni> anyone has any oppinons about "[FFmpeg-devel] [PATCH 4/4] hevc: reuse edge emu buffer for coefficients" ? [02:57] <michaelni> if not ill probably apply it [02:59] <iive> what does it do? use emuedge buffer for idct ? [03:03] <iive> nope, tu.coeffs .. [03:10] <cone-658> ffmpeg.git 03Joakim Roubert 07master:3edb9aaea6aa: avformat/hlsenc: Added parameter -hls_allow_cache [04:46] <cone-658> ffmpeg.git 03Michael Niedermayer 07master:4d9a46fe31e0: avcodec/libx264: mark unchanged pointer arguments as const [04:46] <cone-658> ffmpeg.git 03Michael Niedermayer 07master:3956b12fdec5: avcodec/libx265: enable psnr reporting when requested by the user [05:33] <Timothy_Gu> Nice, FFmpeg is in Debian sid now [07:09] <pross> Do we prefer planar or interleaved audio (for new decoders?) [09:05] <nevcairiel> usually one of those makes more sense for the implementation [09:06] <nevcairiel> most codecs encode the channels separately and the decoders just used to interleave them after, in that case, use planar [10:07] <pross> nevcairiel: ok [11:02] <cone-238> ffmpeg.git 03Reimar Döffinger 07master:b7082d953fda: configure: add noexecstack to linker options if supported. [11:27] <pross> i need help with gcc asm syntax. anyone game? i want to 'pslldq' a c array. [11:30] <ubitux> are you really adding some inline code? [11:31] <pross> uh huh [11:31] <pross> __asm__( [11:31] <pross> "movdqu (%1), %%xmm0\n\t" [11:31] <pross> "pslldq $1, %%xmm0\n\t" [11:31] <pross> "movdqu %%xmm0, (%1)\n\t" : [11:31] <pross> "+r" (x)); [11:56] <Polarwinds> Hello, is there a way to convert 10bit mkv's with subtitles to mp4? [13:19] <pross> got it! [13:23] <kierank> nevcairiel: how did you make ffmpeg attempt to decode the substream? [13:23] <nevcairiel> if you just remove the limitation it'll attemtp to do it, but fail immediately [13:23] <nevcairiel> even the truehd headers seem to be missing [13:24] <kierank> I commented out m->max_decoded_substream = FFMIN(m->num_substreams - 1, 2); [13:24] <nevcairiel> commenting out is wrong, it still needs to be set to m->num_substreams -1 [13:24] <nevcairiel> just remove the ffmax [13:24] <kierank> ah [13:24] <nevcairiel> eh, ffmin [13:24] <kierank> oh i see max_decoded_substream is an index [13:27] <kierank> ah fails now [13:59] <kierank> nevcairiel: hmm yeah it's weird [13:59] <kierank> no restart header [14:12] <kierank> I'm doing this because my timestamps are doubles, and can't be [14:12] <kierank> expressed in integer timebases. [14:12] <kierank> !!!!! [14:12] <kierank> wm4: [14:12] <wm4> :) [14:12] <wm4> thought about changing this [14:12] <wm4> but I can't really see any reason to [14:12] <wm4> I mean, take Matroska: timestamps are rounded to ms boundaries... [14:13] <Daemon404> ns [14:13] <Daemon404> ms is just what libs do. [14:13] <wm4> but "nobody needs this except you" is probably still a valid reason to reject it [14:13] <wm4> Daemon404: well, timestamps within clusters are 16 bits [14:13] <wm4> so you can't realistically use ns, I think [14:14] <nevcairiel> use moar clusters [14:14] <wm4> though there's also the "timecode scale" [14:14] <Daemon404> though tbh, i dont know why people wouldnt store timestamps as dts/pts in the first place [14:14] <Daemon404> when designing a format [14:14] <wm4> simplicity!!!111111111111111 [14:15] <wm4> and then let's randomly use monotonic pts and reordered pts [14:15] <nevcairiel> SimpleBlock has a 16-bit timecode, Block uses a full variable-length mkv number [14:15] <Daemon404> lol [14:15] <Daemon404> matroska? simple? [14:15] <wm4> nevcairiel: are you sure? [14:15] <cousin_luigi> Greetings. [14:16] <nevcairiel> at least i thought thats how it worked, maybe i'm mixing it up with another element [14:16] <kierank> 1:13 PM <"Daemon404> ns --> wrong [14:16] <kierank> 27mhz [14:16] <wm4> nevcairiel: from what I can tell, they always use 16 bits [14:16] <Daemon404> nobody uses mhz as suc ha measurement outside of broadcast [14:16] <wm4> but block duration is a full timestamp [14:16] <kierank> Daemon404: the 27 is more important [14:16] <Daemon404> for broadcasters [14:17] <kierank> for content that's ntsc based [14:17] <kierank> which is probably the vast majority of content still [14:17] <Daemon404> for content that is in any way based in any sane format, ms is fine [14:17] <nevcairiel> in any case, if you really need ns precision, you can always use more clusters at a slightly increased overhead [14:17] <Daemon404> nevcairiel, so, nobody [14:17] <Daemon404> ;P [14:17] <nevcairiel> you can also use 0.1ms or whatever floats your boat [14:18] <wm4> I even thought about "fixing" these timestamps by correlating them with the FPS value stored in the matroska header [14:18] <Daemon404> wm4, that seems like it would cause a lot of issues [14:18] <wm4> yeah [14:18] <Daemon404> unelss youre quite careful [14:36] Action: cousin_luigi is not quite sure this is the right place to ask this, but do you have any idea why ffplay is not being built using these options http://sprunge.us/FEYG ? [14:37] <cone-228> ffmpeg.git 03Michael Niedermayer 07master:a52f443714b5: avcodec/vc1dec: fix is_intra block vs. mb bug [14:44] <nevcairiel> one of these days i should compare the vc1 decoder against microsofts reference [14:45] <nevcairiel> the output, i mean [14:46] <wm4> is vc1 decoding bitexact? [14:47] <nevcairiel> afaik the spec is, yes, our decoder, probably not [14:50] <nevcairiel> could probably compare it to the hwaccel output through ffmpeg, thats easier to test than a binary decoder [14:51] <nevcairiel> the hwaccel is bitexact to the software h264 decoder, so at least i know that the tests work :D [14:52] <JEEB> :) [14:52] <JEEB> IIRC the reference thingy was not only painfully slow but also hard to plug into anything [14:52] <nevcairiel> well i was thinking of the default microsoft decoder, would assume its bitexact [15:02] <Hoschi__> hi folks, could someone explain me the sentence between the row# 895 ->899 in the following file? http://ffmpeg.org/doxygen/2.4/mux_8c_source.html#l00867 [15:12] <cone-228> ffmpeg.git 03Michael Niedermayer 07master:04152a31cb41: avcodec/vc1dec: Fixing is_intra, 2nd attempt [15:25] <LigH> Greetings. [15:25] <LigH> Do you already know about issues compiling libutvideocodec in libavcodec? [15:26] <JEEB> it's unmaintained [15:26] <JEEB> the library that is [15:27] <LigH> Hmm. So it may not make much sense to try to create a ticket? [15:27] <JEEB> you can, but if it's mostly related to the library then I don't think much will be done about it since it's a third party component [15:28] <LigH> Well, GCC complains it cannot finf intmath.h, which seems to be a part of libavcodec, though. [15:35] <Daemon404> as teh author of that wrapper [15:35] <Daemon404> i want to delete it [15:36] <Daemon404> but people are unhappy if i do. [15:37] <LigH> Well, I am no real developer, I have not much experience with C compilers... I can only try to read and interpret what I believe to understand. [15:38] <LigH> For building ffmpeg, I use the media-autobuild_suite by jb_alvarado. [15:38] <LigH> It creates an MSYS2 environment for a Win64 cross compile with GCC. [15:38] <Daemon404> sure [15:38] <LigH> Then it downloads all required sources from CVS/SVN/GIT as required. [15:39] <Daemon404> but my point was: what do you need the libutvideo wrapper for/ [15:39] <Daemon404> or is it one of those "the recipe/package maintainer decided to enable it for no reason" things [15:39] <LigH> Probably to support Ut video AVIs as source in ffmpeg? [15:39] <Daemon404> there are native encoders and decoders for ut video [15:39] <Daemon404> is a* [15:40] <LigH> Then the configuration of ffmpeg might contain the wrong flags? [15:40] <Daemon404> libutvideo has to be explicitly enabled [15:40] <Daemon404> so someone has explicitly set it. [15:41] <LigH> If you have a recommendation, I will tell jb_alvarado about it. If enabling libutvideo is not required for ffmpeg to support Ut video format, I will tell him not to enable it. [15:41] <JEEB> for decoding it hasn't been for a very long time [15:41] <JEEB> kostya implemented it I think in 2011 or so? [15:42] <Daemon404> ... like 2 weeks after i wrote the wrapper [15:45] <iive> is the library encoder too? [15:46] <JEEB> yes, and I implemented the encoding in 2012 [15:46] <iive> so, are there any features that are present in the library and not in ffmpeg? [15:47] <JEEB> I have no idea if the library was upkept with any of the updates that the VFW encoder got, we plugged in the BT.709 stuff [15:49] <iive> so it's the opposite. Virtually there is no reason to use the library if you are not hunting bug in the ffmpeg ut implementation. [15:50] <LigH> Okay ... I just found that the media-autobuild_suite uses it only on one of two build calls (I believe only in the static building, not in the shared). [15:51] <LigH> May be a "forgotten to remove" mistake? ... Will try to patch the script and see what happens. [15:51] <iive> LigH: anyway, ffmpeg should build with the library present and enabled. fill bugreport anyway. [15:52] <iive> if nobody wants to maintain it, then it could be removed. [15:52] <iive> I wonder if libav have removed it already? Diego loves to nix such "cruft". [15:53] <LigH> I am just afraid that the response may be: "You are using m-a_suite, so that's their fault, not ours, *obviously*". Some people like to respond this way... ;) [15:55] <Daemon404> iive, it was never in libav. [15:55] <Daemon404> i wrote it. it's not useful anymore. [15:56] <wm4> KILL KILL KILL [15:59] <LigH> https://trac.ffmpeg.org/ticket/3984 [16:16] <iive> LigH: try to change the include to "#include "libavutil/intmath.h" and see if it compiles. [16:22] <cone-228> ffmpeg.git 03Michael Niedermayer 07master:b28f470df09c: avutil/pca: Make argument of ff_pca_add() const [16:26] <LigH> iive: Without "--enable-libutvideo", ffmpeg -decoders|-encoders both contain support for "Ut Video". [16:37] <LigH> Ciao... \o [16:39] <JEEB> iive, expecting him to actually do any source code modification? even if it's simple he won't just do it and go behind the thing that "he's just a user" [16:40] <iive> well, it's optional :) [16:40] <iive> he got his problem solved. I wanted a confirmation of a solution. [17:18] <arwa> hey could anyone brief me with --> how to get started with writing filters for libavfilters? [17:20] <wm4> doc/writing_filters.txt [17:21] <arwa> okay thanks :D [17:44] <ubitux> i need to fix the lena reference in that tutorial [17:46] <Daemon404> -_- [17:48] <ubitux> :( [18:26] <ubitux> -0, 11, 11, 1, 38016, 0xe1e821ca [18:26] <ubitux> +0, 11, 11, 1, 38016, 0xe1e621ca [18:26] <ubitux> oh wow. [18:26] <ubitux> dat crc change. [18:27] <ubitux> -0, 11, 11, 1, 518400, 0x722bc6e8 [18:27] <ubitux> +0, 11, 11, 1, 518400, 0x77cbc6e8 [18:27] <ubitux> same here [18:27] <ubitux> fear. [18:27] <durandal_1707> of what? [18:27] <ubitux> a52f443714b5c2a40ed272d8445f4c39220a4b69 [18:27] <ubitux> vc1 [18:28] <Daemon404> wut [18:31] <nevcairiel> ubitux: i saw those, i wondered how that is possible [18:32] <nevcairiel> in theory a single bit change should scramble the entire crc, shouldnt it [18:32] <ubitux> maybe there is a change at regular interval [18:32] <ubitux> or something like this [18:33] <Daemon404> well, for some codecs, it is trivial to force the decoded freame to any crc you want :P [18:33] <Daemon404> you could have much fun with fate [18:35] <durandal_1707> is it ok to use bytestream2 in probe function? [19:04] <cone-228> ffmpeg.git 03Michael Niedermayer 07master:d22e88d120eb: avcodec/x86/fmtconvert: Fix operand size in ff_int32_to_float_fmul_array8_sse* [19:06] <michaelni> ubitux, these are not the crcs you are searching for ... these are adler32 checksums [19:07] <ubitux> ooh ok [19:08] <Daemon404> obi wan niedermayer? [19:08] <michaelni> :) [19:20] <nevcairiel> hm, the hevc decoder has a bug, everytime it parses an in-band sps/pps/vps group, it seems to discard 2 video frames for output on this sample [19:24] <michaelni> probably best to send a mail to mraulet or open a ticket [21:38] <cone-228> ffmpeg.git 03Michael Niedermayer 07master:579a0fdc211f: avutil/lls: Make unchanged function arguments const [22:38] <cone-228> ffmpeg.git 03Michael Niedermayer 07master:b1a0fccd023d: avformat/hlsenc: export inner muxer timebase [23:20] <llogan> Why do trac bug reporters often leave "Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker."? [00:00] --- Mon Sep 29 2014