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

[burek]

[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