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

[burek]

[00:26:52 CEST] <erraunt> Hi. Why are entries on trac concerning jpeg2000 tagged 'j2k' ? Wikipedia states that j2k is some close source codec.
[00:27:57 CEST] <llogan> maybe to differientiate between jpeg2000 and libopenjpeg decoders?
[00:28:26 CEST] <llogan> just guessing. not that i looked or anything
[00:30:48 CEST] <mark4o> JPEG2000 and J2K are the same format
[00:31:42 CEST] <mark4o> there are various implementations with names like OpenJPEG (open source), and J2K-Codec (proprietary)
[00:32:13 CEST] <llogan> *decoders/encoders
[02:42:11 CEST] <rcombs> just got an undeliverable message reply to an ML message from gerrad8 at nate.com
[02:58:17 CEST] <jamrial> i've been getting those for every email i sent in the past week or so as well
[02:59:27 CEST] <jamrial> could be full inbox or the address is no longer valid, but in any case maybe the list admin should unsubscribe it?
[02:59:54 CEST] <llogan> i haven't seen any such messages. are they all from that particular user?
[03:02:40 CEST] <jamrial> llogan: yes, all are about that email rcombs mentioned above. automated undeliverable message replies, in korean
[03:03:13 CEST] <jamrial> they aren't sent to the ml, mind you, but to the person that wrote the email that couldn't be delivered
[03:05:02 CEST] <llogan> i'll disable mail delivery to that user
[03:05:53 CEST] <jamrial> rcombs: did you test this patchset applied to Daemon404's codecpar repo?
[03:06:05 CEST] <rcombs> jamrial: I did not
[03:06:10 CEST] <rcombs> will shortly
[03:07:29 CEST] <jamrial> do it if you can, because it will be merged this saturday and it will save you and him some time :p
[03:08:31 CEST] <jamrial> rcombs: Daemon404 added an autobsf for movenc to the codecpar branch but then removed it, not sure why
[03:08:51 CEST] <rcombs> jamrial: probably because it broke movenc-test and dash
[05:17:50 CEST] <Daemon404> [02:08] <+rcombs> jamrial: probably because it broke movenc-test and dash <-- yes
[09:48:44 CEST] <cone-216> ffmpeg 03Paul B Mahol 07master:3e99b377fc8b: avcodec: remove "get_buffer() failed" message
[10:07:18 CEST] <cone-216> ffmpeg 03Paul B Mahol 07master:ae8a13c56022: avcodec/shorten: if allocation fails reset max_frame_size
[10:45:45 CEST] <ubitux> wbs: do you know cases of aarch64 misassembling?
[10:52:33 CEST] <wbs> ubitux: no
[10:54:27 CEST] <ubitux> ok actually bytecode is the same, i'm lost
[10:54:39 CEST] <ubitux> i have a weird bug
[10:55:08 CEST] <ubitux> where execution on ios doesn't seem to lead to the same output as qemu or other boards
[11:03:28 CEST] <rcombs> calling convention oddity?
[11:07:23 CEST] <ubitux> bug is fucked up gamma with jpeg
[11:40:44 CEST] <ubitux> rcombs: actually it might be that
[11:40:54 CEST] <ubitux> adding av_logs fucks it up more
[12:07:58 CEST] <mateo`> for reference and fun: https://developer.apple.com/library/ios/documentation/Xcode/Conceptual/iPhoneOSABIReference/Articles/ARM64FunctionCallingConventions.html
[12:16:19 CEST] <ubitux> > iOS diverges from Procedure Call Standard for the ARM 64-bit Architecture in several ways
[12:16:21 CEST] <ubitux> fuck you apple :(
[12:19:53 CEST] <wm4> lol
[12:20:41 CEST] <ubitux> so the convert code ends up reading a random y coeff from somewhere else
[12:20:51 CEST] <ubitux> which happens sometimes to be in the table of coeff
[12:21:14 CEST] <ubitux> actually it might be reading args from the wrapper
[12:22:33 CEST] <ubitux> i'm gonna need https://www.youtube.com/watch?v=6Viwwetf0gU
[12:46:44 CEST] <cone-216> ffmpeg 03Dmitriy 07master:c3320a51df2b: avcodec/pngenc: restore image size before copying frame
[12:46:45 CEST] <cone-216> ffmpeg 03Paul B Mahol 07master:1490682bcb0f: avcodec/pngenc: check return value of av_frame_copy()
[13:19:53 CEST] <cone-216> ffmpeg 03Paul B Mahol 07master:259879d32d12: avformat/nistspheredec: fix silly bug
[13:26:37 CEST] <ubitux> ok great
[13:26:50 CEST] <ubitux> the arguments on the stack are packed within ios calling convention
[13:26:52 CEST] <ubitux> ffs
[13:26:56 CEST] <ubitux> fuck them :(
[13:29:08 CEST] <wm4> I wonder what apple engineers were thinking
[13:29:20 CEST] <wm4> "I know, let's have a different ABI from everyone else! great idea!"
[13:45:09 CEST] <ubitux> http://b.pkh.me/0001-sws-aarch64-yuv2rgb-honor-iOS-calling-convention.patch
[13:45:11 CEST] <ubitux> makes me sad :(
[14:16:32 CEST] <ubitux> oh fun readvitc
[15:02:29 CEST] <kierank> eugh feature creep
[15:02:33 CEST] <kierank> now ffmpeg handles analogue data
[15:02:34 CEST] <kierank> eugh
[15:03:56 CEST] <durandal_170> kierank: what?
[15:04:04 CEST] <kierank> readvitc patch
[15:04:30 CEST] <durandal_170> that's digital
[15:04:46 CEST] <wm4> obviously ffmpeg should be handling everything
[15:04:57 CEST] <wm4> I need a new mail client too, I should implement it as libavdevice demuxer
[15:05:03 CEST] <kierank> durandal_170: he's doing analogue vitc 
[15:13:02 CEST] <nevcairiel> we have all sorts of crazy avfilters, as long as its nicely contained in one filter, just let them have it
[15:43:51 CEST] <durandal_170> wm4: client? Server, send encodes to you mail server
[15:48:01 CEST] <ubitux> readvitc is pretty cool
[15:48:11 CEST] <ubitux> i wonder if you can forward the meta and read it from drawtext
[15:48:19 CEST] <ubitux> since we already draw it from here
[15:50:36 CEST] <durandal_170> from what?
[15:51:27 CEST] <durandal_170> I added feature to drawtect so it can use metadata
[15:51:40 CEST] <durandal_170> Long ago
[15:53:38 CEST] <ubitux> yes but timecode needs special formatting
[15:53:53 CEST] <ubitux> oh well it's already formatted in the meta
[15:54:52 CEST] <durandal_170> someone should really write drawass filter
[16:23:19 CEST] <kierank> Is there an instruction to do ABCDEFGH IJKLMNOP -> ACEGIKMO
[16:23:55 CEST] <BBB> psrlw x, 8; pxrlw y, 8; packuswb x, y?
[16:24:05 CEST] <BBB> (or pand instead of psrlw)
[16:24:22 CEST] <BBB> I guess on x86 it would be pand
[16:26:12 CEST] <kierank> hmm packuswb might be better for what we want anyway
[16:26:23 CEST] <kierank> (uyvy422-10bit -> planar 10-bit)
[16:26:47 CEST] <kierank> dw*
[16:26:57 CEST] <durandal_170> that's all corporate code?
[16:27:07 CEST] <kierank> well it's on github but there's nowhere to merge it
[16:27:42 CEST] <kierank> I don't really want to add a uyvy422 10-bit to swscale
[16:27:46 CEST] <durandal_170> its actually closed?
[16:27:48 CEST] <kierank> no
[16:27:53 CEST] <kierank> https://github.com/kierank/ffmpeg-sdi/commits/master
[16:28:03 CEST] <durandal_170> Ah
[16:28:14 CEST] <kierank> but none of these formats exist in the file world
[16:36:13 CEST] <BBB> dont add it to swscale
[16:36:17 CEST] <kierank> exactly
[16:36:24 CEST] <BBB> just make it a decoder or something like that
[16:36:41 CEST] <BBB> its really only a raw format in containers, right? its not like any actual real decoder outputs this format
[16:36:47 CEST] <kierank> it's not even in containers
[16:36:49 CEST] <kierank> it's in hardware
[16:36:53 CEST] <BBB> I see...
[16:36:55 CEST] <BBB> how shitty
[16:36:56 CEST] <kierank> or intermediates to hardware
[16:37:38 CEST] <BBB> so this is 5 bytes per 2 pixels uyvy?
[16:38:43 CEST] <BBB> Id also like to push my filter today, so Ill send an updated patch later
[16:38:47 CEST] <BBB> working on some other stuff first
[16:39:13 CEST] <TD-Linux> shitty? that's what makes it professional broadcast grade (tm)
[16:39:43 CEST] <kierank> just designed for fpgas that's all
[16:39:50 CEST] <BBB> let me rephrase that: how professional
[16:39:54 CEST] <BBB> how corporate?
[16:40:45 CEST] <TD-Linux> right, it does let you convert colorspaces without any buffering
[16:40:50 CEST] <wm4> does anyone know what AV_PIX_FMT_UYYVYY411 is good for
[16:41:48 CEST] <TD-Linux> HDCAM dv files?
[16:43:16 CEST] <kierank> 3:40 PM <TD-Linux> right, it does let you convert colorspaces without any buffering --> wow someone in OSS acknowledging broadcast design decisions :)
[18:00:12 CEST] <cone-216> ffmpeg 03Clément BSsch 07master:cab9661dba47: sws/aarch64/yuv2rgb: honor iOS calling convention
[18:00:41 CEST] <ubitux> wbs: some apple bs you might be interested in ^
[18:25:58 CEST] <atomnuker> Gramner: see any obvious way to speed this asm up? http://sprunge.us/YLTj?diff
[18:27:00 CEST] <Gramner> that's a lot of shuffles
[18:31:11 CEST] <kierank> seems overcomplicated, yes
[18:33:29 CEST] <Gramner> input is u0 y0 v0 y1 u1 y2 v1 y3 u2 y4 v2 y5 u3 y6 v3 y7, right?. use one pshufb to turn that into u0 u1 u2 u3 v0 v1 v2 v3 y0 y1 y2 y3 y4 y5 y6 y7, then SBUTTERFLY:s until you're done
[18:34:29 CEST] <kierank> yes
[18:35:00 CEST] <atomnuker> but they're all in different registers
[18:35:01 CEST] <kierank> input is 10-bit
[18:35:16 CEST] <kierank> so just u0 y0 v0 y1 u1 y2 v1 y3
[18:35:27 CEST] <kierank> and u2 y4 v2 y5 u3 y6 v3 y
[18:35:29 CEST] <Gramner> ah, yes. but same principle applies
[18:39:12 CEST] <Gramner> actually the SBUTTERFLY macro wont help since the unpack sizes will be different for the lower and upper halves. just do unpacks explicitly then I guess
[18:54:47 CEST] <Gramner> atomnuker / kierank: something like this (completely untested): http://pastebin.com/PYNFTSU2
[18:55:19 CEST] <kierank> Gramner: he has to learn =p
[19:10:30 CEST] <atomnuker> well, it's not any faster on the 2 machines I tested on but it's shorter
[19:12:24 CEST] <Gramner> that's weird. it's a lot fewer shuffles and shuffles are quite slow on modern intel cpus compared to everything else. or are you on a pre-haswell machine?
[19:13:39 CEST] <atomnuker> skylake
[19:14:27 CEST] <atomnuker> according to perf the last load (4*mmsize) is taking up most of the time
[19:14:55 CEST] <Gramner> I wouldn't trust that
[19:19:27 CEST] <Gramner> non-temporal stores might be worth it if you're dealing with entire frames though
[19:19:33 CEST] <Gramner> e.g. movnta
[19:21:31 CEST] <Gramner> er. I mean loads
[19:23:46 CEST] <Gramner> or maybe non-temporal stores was more efficient? I don't remember
[19:24:59 CEST] <atomnuker> well, dealing with just a single line here, so I don't know if it would help much
[19:25:51 CEST] <kierank> doing that deliberately btw because there's an interlaced to field conversion necessary
[19:26:53 CEST] Action: Daemon404 stabs rcombs 
[19:40:06 CEST] <wbs> ubitux: yep, I saw it. you'd have to have an insane amount of parameters to end up on the stack on aarch64 though
[19:45:23 CEST] <ubitux> wbs: yeah but that happens with the unscaled path of swscale since it's not slice oriented but frame oriented, and you have all kind of coeffs and offsets
[19:45:41 CEST] <ubitux> we could save a few args somehow though
[19:46:47 CEST] Action: rcombs dies
[20:14:04 CEST] <durandal_170> Nobody knows shorten?
[21:48:30 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07master:6936c11533a4: fate: Add test for Ticket 2397 (dvdsub)
[22:25:52 CEST] <furkan> would there be any interest in accepting a pull request to implement a SIP client for ffmpeg, to be able to connect to a SIP URL and play back the audio/video?
[22:26:42 CEST] <JEEB> if it fits within the libraries' design feel free to send out a patch onto the ML
[22:27:02 CEST] <furkan> ok, i haven't started yet, but was just considering it
[22:27:16 CEST] <furkan> i'm looking now at how MPlayer does it, seems they use the live555 library
[22:28:19 CEST] <furkan> seems like it just uses the SIP client to get the SDP description, and from that point on it's just RTP
[22:33:19 CEST] <wm4> I don't know about this sip etc. crap, but doesn't ffmpeg already have stuff for this? just make sure it doesn't before you start...
[22:36:12 CEST] <furkan> wm4: i was looking for it but couldn't find anything in the documentation
[22:36:36 CEST] <furkan> i found that mplayer is able to play SIP URLs, so i started looking at the source code
[22:37:14 CEST] <JEEB> wm4: seems like it's like telling the encoder/server to serve stuff in specific format or so
[22:37:20 CEST] <furkan> and i know mplayer uses ffmpeg, but for the SIP URLs it uses the SIP client from live555 to get the SDP file
[22:37:22 CEST] <JEEB> so not only reading stuff
[22:37:37 CEST] <furkan> right, SIP negotiates the codec etc. for the session
[22:37:56 CEST] <furkan> and then it generates an SDP file and you start streaming over RDP
[22:37:59 CEST] <furkan> *RTP
[22:39:04 CEST] <furkan> so the client requests the codec, server responds with an SDP file if it supports the codec, and then client starts streaming
[22:39:56 CEST] <furkan> at least that's what i'm understanding by looking at libmpdemux/demuxrtp.cpp (in the mplayer source)
[22:40:32 CEST] <furkan> *libmpdemux/demux_rtp.cpp
[22:44:41 CEST] <wm4> sounds like something that would fit into libavformat anyway
[22:45:34 CEST] <JEEB> probably
[22:51:12 CEST] <jkqxz> Not sure that making SIP calls is really in scope.  Doing the RTP handling, sure.  But doing all the SIP stuff to make calls would rather quickly have to deal with SIP registrations and whatnot, which isn't obviously appropriate.
[22:54:55 CEST] <furkan> jkqxz: isn't registration only needed if you want to receive calls?
[23:03:46 CEST] <jkqxz> Directly, yes; but registrars and proxies tend to conflate in order to make identity work sensibly.  The case you want is what; just outgoing ad-hoc calls to endpoints which will send one-way media to you?
[23:05:44 CEST] <michaelni> atomnuker, aac-yoraw-encode fail under valgrind: http://fatebeta.ffmpeg.org/report/x86_64-archlinux-gcc-valgrindundef/20160405235513#failed_tests
[23:10:50 CEST] <furkan> jkqxz: right, outgoing call and receiving one-way media
[23:26:10 CEST] <jkqxz> furkan:  I guess that's not unreasonable, assuming it doesn't scope-creep excessively.  Do you have some particular use case in mind?
[23:28:15 CEST] <furkan> jkqxz: the use case is that we have a sound system connected to the LAN, which you can call from a VoIP phone and listen to, but sadly it doesn't have an RTSP server or anything
[23:28:28 CEST] <furkan> so i'd just like to be able to connect to the sound system, receive the audio, and stream it online
[23:29:00 CEST] <TD-Linux> well ffmpeg already has support for SDP so it's not a big stretch
[23:29:03 CEST] <furkan> but of course that's a really niche application... not sure if other people would have uses for it too
[23:47:35 CEST] <cone-433> ffmpeg 03Paul B Mahol 07master:966d43d7786d: avcodec/shorten: fix decoding of last frame
[23:47:36 CEST] <cone-433> ffmpeg 03Paul B Mahol 07master:a4790e1890a1: avformat/nistshperedec: add support for mu-law as sample-byte-format
[23:47:37 CEST] <cone-433> ffmpeg 03Paul B Mahol 07master:c18fdc86928e: avcodec/shorten: remove useless if condition and comment, reindent
[23:47:38 CEST] <cone-433> ffmpeg 03Paul B Mahol 07master:dee138624fdf: avcodec/shorten: fix decoding of files with number of samples lower than max_frame_size
[00:00:00 CEST] --- Sat Apr  9 2016