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

[burek]

[01:23:08 CEST] <cone-253> ffmpeg 03Petru Rares Sincraian 07master:3f5b7a2d7357: fate: add test for asetrate
[09:41:21 CEST] <Mysoft> hello, i would like to use part of the ffmpeg code... just to do a TS -> MP4 conversion (audio+video copy), can you guys hint me witch parts of the code i need to use to accomplish that?
[10:29:03 CEST] <andrey_turkin> BtbN: I've no idea. But last time I tried that there were issues with chroma handling (looks like it disagrees regarding plane layout or something). So maybe you've hit that bug. Or maybe they saw that bug and decided it was easier to disable yuv420p rather than fix it? ))
[10:29:46 CEST] <BtbN> Or maybe it behaves different on Kepler
[10:29:53 CEST] <andrey_turkin> maybe.
[10:30:16 CEST] <thardin> Mysoft: you could just use the ffmpeg program
[11:23:46 CEST] <cone-654> ffmpeg 03Michael Niedermayer 07master:fcdbbbd85a16: avcodec/iff: decode_delta_j: Check that the number of bytes that will be read are available
[11:23:47 CEST] <cone-654> ffmpeg 03Michael Niedermayer 07master:55ef890b29ac: avcodec/iff: Print error for cols/bpp/bytes being bad in decode_delta_j()
[14:41:51 CEST] <ubitux> oh man someone is angry on the ml again
[14:42:36 CEST] <nevcairiel> I only asked the questions several people asked here on IRC but for some reason didnt feel like posting on the ML :p
[14:50:04 CEST] <atomnuker> what the hell is up with that dan parrot guy
[14:50:19 CEST] <atomnuker> now he's screaming at nevcairiel for not understanding compilers
[14:51:17 CEST] <atomnuker> is there no assembler out for ppc64?
[14:51:59 CEST] <nevcairiel> i bet there is, writing assembler is just harder
[14:52:46 CEST] <nevcairiel> he wrote simd functions that are sometimes even slower then the C, and he wonders when we question whats wrong
[14:53:03 CEST] <atomnuker> yes, exactly, I saw the numbers and some are slower than the C version
[14:53:07 CEST] <BtbN> What happend to the "No SIMD" rule?
[14:53:17 CEST] <atomnuker> and it's all intrinsics
[14:53:28 CEST] <BtbN> or rather, no intrinsics
[14:54:06 CEST] <nevcairiel> we already have a bunch of altivec intrinsics from ages ago for reasons
[14:54:17 CEST] <nevcairiel> noone cared about ppc for a long time
[14:56:25 CEST] <atomnuker> I wonder if the compiler backends are now good enough to beat the altivec optimizations we have
[14:56:56 CEST] <atomnuker> (or maybe not since no one has cared about ppc since 2005)
[15:00:25 CEST] <BBB> BtbN: no intrinsics is primarily for x86
[15:00:42 CEST] <BBB> BtbN: for x86, we have very good, definitive evidence to support the decision, which is final
[15:00:57 CEST] <BBB> BtbN: we also have sufficiently many people that can write raw assembly or teach others to do so
[15:01:05 CEST] <BBB> BtbN: for ppc64& we really dont have anything like that
[15:02:03 CEST] <ubitux> oh there is a $1k bounty... ok.
[15:03:41 CEST] <nevcairiel> hence why multiple devs asked about the motivation
[15:03:45 CEST] <nevcairiel> they just didnt ask on the ML
[15:03:47 CEST] <nevcairiel> only here
[15:05:12 CEST] <atomnuker> I feel like it's going to backfire since the "optimizations" make some functions slower
[15:20:14 CEST] <atomnuker> michaelni: you know about in-place DWTs, right
[15:21:08 CEST] <atomnuker> got any tips on how to convert a line-for-level to an ordinary top-left=ll, ..., bottom-right=hh
[15:21:45 CEST] <atomnuker> is non-ll even doable without having some sort of a cache
[15:21:45 CEST] <cone-654> ffmpeg 03Matthieu Bouron 07master:88d9c30cf57e: lavc/mediacodecdec_h264: properly convert extradata to annex-b
[15:26:29 CEST] <amishi> Hi! I noticed that ffmpeg libquvi support was removed. Is there now some other library used to read e.g. YouTube streams?
[15:26:37 CEST] <BtbN> no
[15:26:51 CEST] <BtbN> Use something like youtube-dl
[15:28:02 CEST] <amishi> Doesn't using youtube-dl mean that I have to dl the file first and cannot stream it directly to ffmpeg via the URL?
[15:28:59 CEST] <amishi> Similarly, when using ffmpeg via libav* it will not support streaming.
[15:29:48 CEST] <atomnuker> amishi: youtube-dl can export the raw url you need to feed into libavcodec, look at how mpv uses ytdl
[15:33:21 CEST] <Mysoft> thardin... and require a 18mb .exe for my 80kb.exe no thanks
[15:34:27 CEST] <Mysoft> also that would require me having two more socket connections to pass stuff in and out ffmpeg 
[15:34:36 CEST] <amishi> Got it. There is a `-g` option. Thanks.
[15:34:55 CEST] <amishi> Seen here: http://stackoverflow.com/a/24174801/135862
[15:35:51 CEST] <michaelni> atomnuker, IIRC full DWT can be done inplace with lifting transforms + reshuffle at the end, it might be faster to do horizontal reshuffle during the transform for better cache use
[15:36:20 CEST] <michaelni> not sure that was what you aske fr
[15:37:28 CEST] <atomnuker> look at deinterleave() in vc2enc_dwt.c, that's the reshuffle at the end
[15:38:11 CEST] <atomnuker> problem is it breaks when the input is also the output, so that's why all the data is copied to a separate synthl buffer at the start of the transform before lifting
[15:39:17 CEST] <atomnuker> nothing really blocks doing the transform in-place other than figuring out how to do the reshuffle without breaking any filter coefficients
[15:40:00 CEST] <BBB> atomnuker: I certainly agree we should not accept optimizations that make stuff slower
[15:40:25 CEST] <BBB> atomnuker: as for the amount of speedup, Id like more specific data on which functions get how much speedup from x86 and how that (per-func) compares to ppc64
[15:40:40 CEST] <BBB> right now its we typically get 2x for x86 but you get 1.17x on this func for ppc64 which is a little fuzzy
[15:40:59 CEST] <BBB> if its we get 2x on this func for x86 but only 1.17x on ppc64, I feel solid in rejecting the patch
[15:41:06 CEST] <BBB> s/solid/comfortable/
[15:42:21 CEST] <michaelni> atomnuker, if the question is how to reshuffle coeffs inplace, its always possible with one temporary coeffiient, might be more efficient with more temporary dunno. The case i worked with filled things in reshuffled order from the bitstream
[15:42:32 CEST] <michaelni> so it didnt had inplace reshuffle of the whole
[15:44:53 CEST] <atomnuker> michaelni: actually yeah, it should totally be possible with 4 temp coefficients
[15:45:49 CEST] <atomnuker> that's how daala does it IIRC
[16:14:25 CEST] <thardin> someone hilighted me?
[16:17:32 CEST] <mateo`_> thardin: Mysoft did
[16:18:33 CEST] <Mysoft> ^^""
[18:57:51 CEST] <cone-716> ffmpeg 03Carl Eugen Hoyos 07master:3e4357eb822c: lavc/libx265: Support gray encoding.
[21:00:56 CEST] <rcombs> hmm, the FLAC muxer ignores timestamps
[21:01:08 CEST] <rcombs> but they get written anyway as part of the packets
[21:01:17 CEST] <nevcairiel> its a raw audio format, should that really convey timestamps?
[21:01:20 CEST] <nevcairiel> audio with holes is no fun
[21:01:31 CEST] <rcombs> probably not, but they're there anyway
[21:01:55 CEST] <rcombs> like, do `ffmpeg -i input.flac -t 30 -c copy out.flac` and then `ffprobe out.flac`
[21:02:06 CEST] <rcombs> you'll see the full duration of the original file, rather than 30s
[21:02:29 CEST] <rcombs> so I guess it's just duration, not timestamps
[21:07:52 CEST] <rcombs> WTF, FLAC uses UTF-8 to encode non-text
[21:08:41 CEST] <JEEB> o_O
[21:09:40 CEST] <rcombs> the `frame_or_sample_num` value is encoded as UTF-8
[21:09:53 CEST] <rcombs> as if it was a code point
[21:10:12 CEST] <JEEB> funky
[21:10:19 CEST] <rcombs> I mean, I guess it's as good a variable-length integer encoding method as any
[21:10:22 CEST] <rcombs> but still, wat?
[21:10:33 CEST] <JEEB> ah right, that thing that matroska's using as well
[21:10:42 CEST] <rcombs> oh, does matroska do that too?
[21:10:49 CEST] <rcombs> I thought they had their own variable-length int thing
[21:11:02 CEST] <JEEB> it noted that it was similar to the UTF-8 one I think?
[21:11:05 CEST] <JEEB> if not the same
[21:12:17 CEST] <rcombs> it's pretty distinctly different
[21:12:29 CEST] <JEEB> oh
[21:12:59 CEST] <rcombs> 7-bit, 14-bit, 21-bit, or 28-bit
[21:13:21 CEST] <JEEB> yeah, I remember the matroska thing (that sounds like it)
[21:13:26 CEST] <rcombs> continuation bytes don't start with 0b10
[21:14:01 CEST] <rcombs> it's sorta similar in concept but more efficient because it doesn't need resyncing
[21:14:18 CEST] <rcombs> whereas FLAC uses literally-UTF-8 for this one value
[21:14:26 CEST] <nevcairiel> using a standard multi-byte code like that seems somewhat smart, rather then inventing your own :p
[21:16:58 CEST] <rcombs> the matroska thing is more efficient
[21:18:07 CEST] <rcombs> UTF-8 is designed to self-resync; it's not optimal for coding individual variable-length integers
[21:18:21 CEST] <rcombs> (in this case, literally one of them)
[21:32:31 CEST] <rcombs> nevcairiel: oh nope I'm wrong it sticks in a PTS as well
[21:38:02 CEST] <rcombs> I suppose this is meant to allow arbitrary byte-based seeking
[22:58:50 CEST] <cone-716> ffmpeg 03Burt P 07master:ba69a81019a2: libavfilter/af_hdcd.c: Collect HDCD stats and report
[23:38:35 CEST] <michaelni> BBB, would you be interrested to be admin for the next round of outreachy ? (2016 december)
[23:38:42 CEST] <BBB> no :-p
[23:38:51 CEST] <michaelni> :(
[00:00:00 CEST] --- Thu Jul  7 2016