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

[burek]

[00:11] <cone-539> ffmpeg.git 03Andrew Stone 07master:db68ef898a38: ogg: update event_flags with STREAM_/METADATA_UPDATED whenever metadata changes.
[00:11] <cone-539> ffmpeg.git 03Michael Niedermayer 07master:a8db787932ad: Merge commit 'db68ef898a3802e51b6f41fd600d0d46d058e3f8'
[00:18] <cone-539> ffmpeg.git 03Martin Storsjö 07master:4e629ef80e62: http: Fix authentication, broken since 6a463e7fb
[00:18] <cone-539> ffmpeg.git 03Michael Niedermayer 07master:e260c8180ec6: Merge commit '4e629ef80e62a54636cb46033998177dd08cf3ad'
[00:23] <cone-539> ffmpeg.git 03Felix Abecassis 07master:159a06dfc83d: stereo3d: initialize AVStereo3D to zero
[00:23] <cone-539> ffmpeg.git 03Michael Niedermayer 07master:ad1b571b2682: Merge commit '159a06dfc83d189f753c4583583ddfb571552ff5'
[00:28] <cone-539> ffmpeg.git 03Anton Khirnov 07master:aa51b0492bfc: avconv: rename output_packet() to process_input_packet()
[00:28] <cone-539> ffmpeg.git 03Michael Niedermayer 07master:097bf149c92a: Merge commit 'aa51b0492bfced6d650fb5ff419e2b13fde6833d'
[00:37] <cone-539> ffmpeg.git 03Anton Khirnov 07master:8ddc32629a6d: mem: add av_strndup() for duplicating substrings
[00:37] <cone-539> ffmpeg.git 03Michael Niedermayer 07master:c8571c61ec4c: Merge commit '8ddc32629a6d6be77256694c9e322dde134609f3'
[00:59] <cone-539> ffmpeg.git 03Anton Khirnov 07master:481a36674954: cmdutils: allow matching by metadata in stream specifiers
[00:59] <cone-539> ffmpeg.git 03Michael Niedermayer 07master:b8e4c11d9332: Merge commit '481a3667495425db9fdffb653292b6460fb68208'
[01:26] <cone-539> ffmpeg.git 03Anton Khirnov 07master:30e50c50274f: lavf: eliminate ff_get_audio_frame_size()
[01:26] <cone-539> ffmpeg.git 03Michael Niedermayer 07master:082d52354f77: doc: fix toolname
[01:26] <cone-539> ffmpeg.git 03Michael Niedermayer 07master:0de0c75ebbec: Merge commit '30e50c50274f88f0f5ae829f401cd3c7f5266719'
[01:48] <cone-539> ffmpeg.git 03Diego Biurrun 07master:353240541d4e: cpu-test: Add unistd.h #include for getopt()
[01:48] <cone-539> ffmpeg.git 03Michael Niedermayer 07master:af5ec182252d: Merge commit '353240541d4ec317471b5cbcaa3e027d00ff8f5c'
[01:50] <jamrial> so it was indeed the mp3 muxer buffering 800+ mb of audio packets in memory waiting for the cover art packet to show up
[01:50] <wm4> because it was such a good idea to model cover art as video stream
[01:50] <Daemon404> lul
[01:51] <Daemon404> also, 800 mb of mp3 audio?
[01:51] <wm4> how else would anyone have noticed this
[01:51] <Daemon404> i wonder what its a recording of
[01:53] <jamrial> is it normal for mp3 files to have the cover art at the end?
[01:53] <wm4> hm, normally id3v2 is at the beginning
[01:54] <Daemon404> was id3v2 the one that base64 encoded the cover?
[01:54] <wm4> it does? I wouldn't be surprised though
[01:54] <wm4> I once tried to read id3v2 myself and god is it stupiud
[01:54] <Daemon404> there was one format that did
[01:55] <Daemon404> oh nope.
[01:55] <Daemon404> it's ogg.
[01:55] <Daemon404> of course it is ogg.
[01:55] <wm4> of course!
[01:56] <jamrial> technically it's vorbiscomment :P
[01:56] <jamrial> it's flac format encoded with base64 inside a vorbiscomment tag
[01:57] <Daemon404> not even its parents love it
[01:57] <jamrial> lol
[01:59] <mark4o> Daemon404: ogg opus is going into last call on the codec list; currently it defers to vorbiscomment but if act soon you can propose something more sane for ogg opus attached pictures
[02:00] <jamrial> also, the source file in that ticket was an itunes m4a file. i suppose in those the cover art is at the end then
[02:00] <Daemon404> mark4o, the base64 version is listed as deprecated.
[02:00] <Daemon404> i assume it wont be used, and the binary version wll be.
[02:01] <mark4o> I dont think it is depreceated; where did you see that?
[02:01] <Daemon404> https://wiki.xiph.org/VorbisComment#Unofficial_COVERART_field_.28deprecated.29
[02:02] <mark4o> COVERART comment is deprecated, but replaced with METADATA_BLOCK_PICTURE.  Both are base64-encoded.
[02:04] <Daemon404> it doesnt explicitly say it is on that page
[02:04] <Daemon404> if so, lame.
[02:04] <mark4o> The binary FLAC picture structure is base64 encoded and placed within a VorbisComment with the tag name "METADATA_BLOCK_PICTURE". This is the preferred and recommended way of embedding cover art within VorbisComments.
[02:04] <Daemon404> fun.
[02:04] <Daemon404> luckily i dont give 2 shits about ogg because it is a terrible format and nothing i care about uses it
[02:05] Action: Daemon404 is working on opus-in-mp4 spec
[02:05] <wm4> but how will you play big buck bunny
[02:05] <Compn> mkv ?
[02:05] <Compn> or ... nut :)
[02:05] <mark4o> I complained about the base64 but couldnt get anyone to care
[02:06] <Compn> you could talk to xiphmont
[02:06] <Compn> ./q xiphmont
[02:08] <j-b> ./ ?
[02:09] <Compn> .yes
[02:19] <Compn> No claim can be processed if any of these are missing: the original receipt, 
[02:19] <Compn> the replacement receipt, the airline ticket (travel destination to home) or the 
[02:19] <Compn> police report.
[02:20] <Compn> $40 rail safeguard plan ? no.
[02:20] <cone-539> ffmpeg.git 03Luca Barbato 07master:e8049af1325d: mpegts: Do not try to write a PMT larger than SECTION_SIZE
[02:20] <cone-539> ffmpeg.git 03Michael Niedermayer 07master:1d7544b752e7: Merge commit 'e8049af1325dd59a51546c15b2e71a0f578e9d27'
[02:20] <Compn> haha customer relations department is in quebec! hahahahhaa
[02:21] <Compn> This program does not apply to any loss caused by: (a) Rail Pass or Ticket not in the holder’s actual possession at the time of loss.
[02:22] <Compn> so if its stolen out of my hotel room while i'm not there, i'm out of luck.
[02:25] <wm4> [PATCH] NULL-check Matroska chapters when reading header <- didn't we have that already
[02:25] <wm4> or was it on libav
[02:26] <wm4> no, it was on ffmpeg-devel, and the patch was applied
[02:28] <iive> Compn: ??
[02:30] <sanjose_kid_> wondering if someone in community can help me...
[02:30] <sanjose_kid_> i am trying to add the capability to ffmpeg project for packet-loss concealment into ffmpeg's RTP stack
[02:31] <sanjose_kid_> am using RTP networking stack for low-latency video-conferencing
[02:31] <sanjose_kid_> By packet loss concealment, I refer to whatever sender sends, receiver needs to receive independent of network conditions.
[02:32] <sanjose_kid_> does anyone know how I can do this?
[02:32] <Compn> iive : british rail train pass insurance...
[02:33] <iive> Compn: oh, I thought it is about the rail coaster trains, like the one that malfunctioned recently
[02:33] <BBB> so does anyone volunteer to do the sample cutting from that ticket for a fate test?
[02:33] <BBB> (vp9 bug)
[02:50] <sanjose_kid_> who is best to work with on ffmpeg's RTP networking stack? 
[02:51] <kierank> Compn: insurance for what?
[02:51] <kierank> oh the ticket
[02:54] <jamrial> sanjose_kid_: if nobody's on right now that can help you, you can either try at a later time or email ffmpeg-devel
[02:54] <sanjose_kid_> @jamrial thank you
[02:56] <sanjose_kid_> @jamrial do u know if there is a specific person who is very familiar with RTP stack in community?
[02:58] <sanjose_kid_> @kierank did you mention that you are building your own RTP stack?
[02:59] <sanjose_kid_> if yes, have u dealt with packet-loss concealment?
[03:04] <kierank> yes we had this discussion yesterday
[03:10] <sanjose_kid_> is it feasible to extend library to support this?
[03:11] <cone-539> ffmpeg.git 03Michael Niedermayer 07master:986ec3417abd: avformat/utils: Remove demuxer specific frame_size fallback from ff_get_audio_frame_size()
[03:11] <cone-539> ffmpeg.git 03Michael Niedermayer 07master:ed488d1535d9: Move frame_size fallback from ff_get_audio_frame_size() to av_get_audio_frame_duration()
[03:11] <cone-539> ffmpeg.git 03Michael Niedermayer 07master:7b59217b60cc: Move WMA case from ff_get_audio_frame_size() to av_get_audio_frame_duration()
[03:11] <kierank> not easy but possible
[03:15] <sanjose_kid_> @kierank do u know calls to make specifically for the communications on packet-loss between server and client ?
[03:15] <kierank> calls?
[03:15] <kierank> you don't do that
[03:15] <kierank> you use the rtp sequence number to measure the packet loss
[03:16] <kierank> it's hard in a vbr setting though because you have to buffer
[03:17] <sanjose_kid_> so if you're dealing with variable bit rate, how do you buffer?
[03:21] <sanjose_kid_> is there any sample project you know of that shows how to handle buffering?
[03:24] <sanjose_kid_> such as ability to set it to certain mode depending on latency or packet loss
[03:24] <cone-539> ffmpeg.git 03Anton Khirnov 07master:d92550d19129: lavf: eliminate ff_get_audio_frame_size()
[04:30] <cone-539> ffmpeg.git 03Christophe Gisquet 07master:69849a2d6ecc: dpxenc: enforce alignment requirement
[04:36] <cone-539> ffmpeg.git 03Christophe Gisquet 07master:7cdef77b5036: dpx: warn if encrypted
[06:13] <cone-539> ffmpeg.git 03James Almer 07master:dffbac0956ca: lavf/oggparsevp8: use ff_vorbis_stream_comment()
[11:23] <sanjose_kid_> using ffmpegs RTP framework how do i get access to the rtp sequence number to measure packet loss?
[11:23] <sanjose_kid_> if anyone knows, that would be super helpful info
[11:56] <ubitux> J_Darnley: what was this gnu time you talked about?
[12:13] <michaelni> sanjose_kid_, access from where ? from a user app i guess there maybe is no way, but sidedata could be used to export it
[12:17] <BBB> michaelni: sanjose_kid_: theres indeed no way right now; if you want to expose it, side-data is fine (although you could alternatively but the quality-connection in libavformat also; is it a custom format or something standardized youre using for the QoS connection?)
[12:18] <ubitux> ping on motion vectors export
[12:18] <ubitux> i'll push soon
[12:18] <saste> sanjose_kid_, I think that info is not currently exposed, read above
[12:18] <saste> ubitux, good, i'll review it now so I get a grasp of this side-data thing ;-)
[12:18] <ubitux> cool, thanks
[12:29] <J_Darnley> ubitux: a `time` program that isn't the bash builtin tool
[12:29] <J_Darnley> cygwin has one available as a separate package
[12:32] <J_Darnley> I only wanted it to measure the run time of ffmpeg
[12:36] <J_Darnley> If there isn't an easy to install package, don't bother.
[12:37] <J_Darnley> I measured the time spent in the function anyway
[12:38] <ubitux> it's not in the package manager
[12:38] <ubitux> perf should be available though
[12:38] <ubitux> zsh also has a different time if you want
[12:43] <cone-524> ffmpeg.git 03Edgar Hucek 07master:ab059f0aa896: vaapi: set the scaling list correctly.
[12:43] <cone-524> ffmpeg.git 03Diego Biurrun 07master:e070d0a5ca90: frame: Remove some FF_API_AVFRAME_COLORSPACE leftovers
[12:43] <cone-524> ffmpeg.git 03Michael Niedermayer 07master:87988d6569ce: Merge commit 'ab059f0aa896e01e8e4529f5f714fde111f05377'
[12:43] <cone-524> ffmpeg.git 03Michael Niedermayer 07master:de7b08cbc1c1: Merge commit 'e070d0a5ca9047192e324a3f87006b316e2a08a7'
[12:48] <sanjose_kid_> @michaeilni, were trying to implement packet-loss concealment and in that goal, to identify lost packages which we can then produce redundant packages for
[12:49] <cone-524> ffmpeg.git 03Nidhi Makhijani 07master:0528226a05cc: a64: Return correct error code on invalid data stream
[12:49] <cone-524> ffmpeg.git 03Michael Niedermayer 07master:8d403d9c89fe: Merge commit '0528226a05cc08b74197547fba0b1939bf68990d'
[12:53] <sanjose_kid_> @BBB, Not Custum, were using x.264/Speex or OPUS and using av_read_frame() to get packages
[12:53] <sanjose_kid_> and were just reading receiver reports for QoS connection
[12:56] <sanjose_kid_> however, the receiver reports don't allow us to initiate a retransmission for redundant packages
[13:01] <cone-524> ffmpeg.git 03Nidhi Makhijani 07master:93f29948e4b0: mpeg4video: Fix doxygen comment syntax to document correct struct member
[13:01] <cone-524> ffmpeg.git 03Michael Niedermayer 07master:b634c12cb967: Merge commit '93f29948e4b06acfb96e7f82d373ef86d6dc55f7'
[13:06] <sanjose_kid_> @michaelni do u think we need to patch ffmpeg to accomplish this?
[13:09] <Compn> sanjose_kid_ : you might want to try asking on the mailing list
[13:09] <Compn> still, stick around here, but you may get some replies there too
[13:11] <sanjose_kid_> Compn - thank you
[13:25] <BBB> sanjose_kid_: yes youll need to patch libavformat (one of the libraries in ffmpeg) to accomplish this
[13:46] <sanjose_kid_> is it possible to get the RTP header information
[13:58] <cone-524> ffmpeg.git 03Christophe Gisquet 07master:4ba45c189cca: dpx: use aligned line starts
[14:02] <kurosu> if bumping lavc's micro, is there a document where to report the change (possibly indicating why) ?
[14:04] <nevcairiel> micro is really not all that wild
[14:04] <kurosu> yeah, and considering it's for dpx...
[15:43] <cone-524> ffmpeg.git 03Christophe Gisquet 07master:117bc8e6ffc7: proresenc_kostya: properly account for alpha
[15:43] <cone-524> ffmpeg.git 03Michael Niedermayer 07master:6c36b3afe72d: avcodec/lcldec: initialize encoded correctly
[16:53] <cone-524> ffmpeg.git 03Christophe Gisquet 07master:58d380f9a7ce: libavcodec: bump micro to reflect dpx changes
[16:53] <cone-524> ffmpeg.git 03Michael Niedermayer 07master:5c7899a4834e: avcodec/mjpegdec: Support AV_PIX_FMT_YUV420P16 with upscale_h
[17:09] <J_Darnley> I am still looking for someone with an XOP capable CPU to test a patch for me.
[17:12] <J_Darnley> Or perhaps someone can tell me whether the XOP looks correct in this patch: https://gitorious.org/ffmpeg/jdarnley-ffmpeg/commit/5c336afd808cf1a1f4e1c3580348080ae4ca3b2d
[17:18] <iive> J_Darnley: what is XOP?
[17:20] <ubitux> the amd avx2
[17:22] <J_Darnley> integer versions of the fused multiply-add instructions
[17:38] <J_D> Dammit!  Who keeps interrupting my connection?
[19:31] <cone-524> ffmpeg.git 03Clément BSsch 07master:10d96d8d66b8: avfilter/select: re-align a few comments
[19:31] <cone-524> ffmpeg.git 03Clément BSsch 07master:37bfeca78cf3: avfilter/select: larger pixel sad computation
[19:53] <cone-524> ffmpeg.git 03Nicolas George 07master:a3aaaec8916b: lavfi/avf_showspectrum: set output frame rate.
[19:53] <cone-524> ffmpeg.git 03Nicolas George 07master:65b284a4aef6: lavfi/avf_showspectrum: fix output pts computation.
[19:54] <cone-524> ffmpeg.git 03Nicolas George 07master:d4de6d4fadcc: lavfi/avf_showspectrum: do not push the frame at EOF.
[19:54] <cone-524> ffmpeg.git 03Nicolas George 07master:ec33df60457d: lavfi/avf_showspectrum: use automatic framing.
[19:54] <cone-524> ffmpeg.git 03Nicolas George 07master:7c10e32ae5a1: lavfi/avf_showspectrum: add full frame sliding mode.
[19:54] <cone-524> ffmpeg.git 03Nicolas George 07master:638eec2ac34b: lavfi/avf_showspectrum: check RDFT context init.
[19:54] <cone-524> ffmpeg.git 03Michael Niedermayer 07master:c6c345ea928b: Merge remote-tracking branch 'cigaes/master'
[20:00] <kierank> wm4: you should make ffmpeg merge the dts code
[20:00] <kierank> dts-hd
[20:00] <kierank> that'll kickstart work on it
[20:01] <Daemon404> hah!
[20:01] <Daemon404> the problem is the only person who is qualified to review it, cant
[20:01] <Daemon404> due to NDA
[20:01] <Daemon404> or w/e
[20:02] <wm4> last I heard about it, it seemed to work relatively well?
[20:02] <Daemon404> its not lossless yet
[20:02] <wm4> who really cares about that
[20:02] <JEEB> did it now do exact integer decoding of the lossy part?
[20:02] <JEEB> so that it matches the XLL extension
[20:02] <JEEB> :3
[20:02] <Daemon404> no dts core is still float iirc
[20:02] <JEEB> k
[20:03] Action: ubitux wonders if he should dump a glib-less pkg-config.c in TOOLS/ for cehoyos
[20:03] <ubitux> actually, tools/ this isn't mplayer
[20:04] <Daemon404> you should give carl a great big cup of Go Fuck Yourself
[20:04] <Daemon404> his argument is like
[20:04] <ubitux> that's not exactly polite
[20:05] <Daemon404> "we cant have nice things because theyre different than the less nice things"
[20:05] <Daemon404> i.e. completely insane
[20:05] <Daemon404> [19:04] <@ubitux> that's not exactly polite <--- >implyign carl is ever anything but rude to anyone
[20:05] <nevcairiel> JEEB: its relatively close though, 2-3 bits diff in a 24 bit result is beyond audible range
[20:05] <JEEB> nice
[20:06] <nevcairiel> But it still has other problems
[20:06] <ubitux> Daemon404: he isn't right now, he is just politely annoying me ;)
[20:07] <Daemon404> i feel like i need to quote that debian thread
[20:07] <Daemon404> about how ffmpeg wont accept "people who dont work on X, blockign commits to X"
[20:09] <kierank> 7:02 PM <wm4> who really cares about that --> this a million times
[20:09] <kierank> wm4: though more like who will really notice
[20:10] <wm4> nevcairiel says there are other problems, though, so maybe that's the reason
[20:10] <Daemon404> kierank, part of the angry DTS people who yelled at me was "those assholes dont implement DTS right and call it DTS"
[20:10] <Daemon404> a large part
[20:11] <Daemon404> yes the irony is lost on them
[20:11] <kierank> Daemon404: tell them to document it correctly then in the spec
[20:11] <kierank> because DCA is an "open standard"
[20:11] <Daemon404> you are open to purchase it
[20:12] <kierank> no there's an etsi standard
[20:12] <kierank> open to purchase is sony bollocks
[20:12] <Daemon404> orite
[20:15] <nevcairiel> They should penalize companies for putting out incomplete and unimplementable standards
[20:17] <kierank> unlicensable too
[20:18] <wm4> what is more baffling is that the piracy scene is using it
[20:19] <Daemon404> wm4, since when does the scene do anything that isnt buttfuck retarded?
[20:19] <cone-524> ffmpeg.git 03James Darnley 07master:7ce6c021dc47: lavc/flacdsp: change lpc_encoder function pointer prototype
[20:20] <wm4> Daemon404: true...
[20:23] <kierank> wm4: using dts?
[20:23] <Daemon404> dts-hd ma
[20:23] <Daemon404> even
[20:23] <kierank> really?
[20:23] <Daemon404> yes
[20:23] <Daemon404> though usually they remux the dts core
[20:23] <kierank> yeah
[20:23] <Daemon404> which is also retarded.
[20:23] <jamrial> why? why reencode it?
[20:24] <Daemon404> you could say the same in argument for muxing flac or wavpack from lpcm sources
[20:24] <Daemon404> it's a collosal waste of bw for no tangible gain.
[20:24] <wm4> but they do it for spdif
[20:25] <jamrial> dts-core is good. dts-hd ma is probably overkill, yeah
[20:25] <Daemon404> dts-core is not 'good'
[20:25] <Daemon404> i especially like teh DVDs i have with 2ch dts that has the same bitrate as pcm
[20:26] <kierank> dts core is backwards compatible
[20:26] <kierank> that's alll
[20:26] <Daemon404> persoanlly, i'd just decode the dts-hd ma full properly, and encode it to aac
[20:26] <jamrial> that's stupid. dts 6ch is 768kbps to 1.5mbps in almost every case
[20:26] <Daemon404> or opus
[20:27] <Daemon404> youll end up with something better than teh dts core, veyr likely
[20:27] <Daemon404> as well as smaller.
[20:28] <kierank> but then you can't spdif
[20:28] <kierank> of course opus/aac will be better
[20:28] <Daemon404> 0 fucks given about spdif
[20:28] <Daemon404> from me
[20:28] <Daemon404> for 'consumer' playback of pirated material.
[20:50] <cone-524> ffmpeg.git 03Michael Niedermayer 07master:fce8817a01d1: avformat/format: remove unused variable
[20:50] <cone-524> ffmpeg.git 03Michael Niedermayer 07master:8b6cbc3c3319: avutil/opt: remove disabled old ABI compatibility code
[21:13] <TheFluff> 20:26:53 <@jamrial> that's stupid. dts 6ch is 768kbps to 1.5mbps in almost every case <-- I'm pretty sure I've managed to reencode 6ch dts-core (which is lossy) to flac and actually save space, that's how dumb it is
[21:50] <wm4> the old subtitle drama
[21:51] <Daemon404> i prefer my solution: dont use i t
[22:21] <nevcairiel> Oh pkg-config drama continues
[22:22] <Daemon404> Carl Eugen vs The World
[22:22] <nevcairiel> Why do we let him block a change again
[22:22] <nevcairiel> I forgot
[22:22] <Daemon404> [19:07] <@Daemon404> i feel like i need to quote that debian thread
[22:22] <Daemon404> [19:07] <@Daemon404> about how ffmpeg wont accept "people who dont work on X, blockign commits to X"
[22:23] <wm4> what's with all that useless mp4 "metadata"
[22:23] <wm4> how am I suppose to differentiate this from real file tags?
[22:24] <nevcairiel> Ask on the ML wth its good for
[22:29] <wm4> hm maybe the way to "fix" this would be having multiple metadata fields, one for "tags", one for "additional crap"
[22:29] <ubitux> for some reason, "mov m0,[p1]; psadbw m0,[p2]; mov m1,[p1+stride]; psadbw m1,[p2+stride];" is faster than "mov m0,[p1]; mov m1,[p1+stride]; psadbw m0,[p2]; psadbw m1,[p2+stride];"
[22:29] <ubitux> i wonder if i misunderstood pairing in the first place
[22:33] <ubitux> now i just made 16x16 sse2 from 560 to 500 decicycles, but i still have no idea why 4 8x8 mmxext is still faster (visible on overall time)
[22:34] <ubitux> 8x8 is ~240 decicyles so i really wonder what's going on here
[22:34] <ubitux> (cache?)
[22:51] <ubitux> emms_c() should probably be made public btw
[22:53] <Daemon404> wat
[23:02] <ubitux> Daemon404: with the pixelutils API, it makes sense because user will need it
[23:03] <wm4> that's one fucked up API then
[23:03] <ubitux> why?
[23:03] <wm4> because it violates standard C?
[23:03] <ubitux> you don't want to call emms after each block call
[23:03] <ubitux> what?
[23:05] <Daemon404> >making the user manually call emms
[23:05] <Daemon404> yeah
[23:05] <Daemon404> [22:03] < wm4> that's one fucked up API then
[23:05] <wm4> ubitux: standard C things cease to work between the API call and emms_c
[23:05] <wm4> because the FPU is in "fucked up state"
[23:05] <wm4> (wait, why even the FPU...)
[23:05] <wm4> god x86 is so fucked up
[23:06] <wm4> /rant
[23:06] <wm4> wasn't emms_c needed for MMX only?
[23:06] <ubitux> probably
[23:07] <ubitux> (what do you suggest? calling emms after each block sad even if it will mean nothing thousands of times per frame?)
[23:08] <wm4> make the API do a meaningful load of work
[23:08] <ubitux> there are tons of sad usages
[23:08] <ubitux> i can't guess them all
[23:09] <wm4> why does the API even have to export it anyway
[23:09] <ubitux> because it's used in libavfilter, and probably will in lavc soon
[23:09] <ubitux> (it's actually ported from lavc)
[23:09] <wm4> so it's just to uphold the independent libraries lie?
[23:10] <ubitux> it's just some common code shared in a clean way
[23:10] <ubitux> pixelutils can be useful for users anyway
[23:10] <ubitux> i mean, it's not like SAD isn't a common operation
[23:11] <wm4> this sounds like it should be really either strictly internal, or a separate library
[23:11] <wm4> nothing that belongs into the ffmpeg API
[23:11] <ubitux> it won't be compiled if you don't need it anyway
[23:11] <ubitux> (but you probably will)
[23:11] <wm4> that's not really what I care about
[23:12] <ubitux> it can't be "strictly internal" (or maybe avpriv?)
[23:12] <ubitux> and it's already in a separate library
[23:12] <ubitux> which is called libavutil
[23:13] <ubitux> anyway, i want to provide such api for anyone willing to do some image processing
[23:13] <ubitux> which sounds like appropriate for a bunch of ffmpeg users
[23:13] <wm4> lol
[23:13] <wm4> if someone wants to do image processing, they won't use ffmpeg
[23:14] <ubitux> now they can
[23:14] <ubitux> ;)
[23:14] <wm4> if anything, they'll use things like pixman or something
[23:14] <wm4> or whatever other specialized image processing libs there are
[23:14] <ubitux> well, some are probably already linking on ffmpeg
[23:14] <ubitux> for decoding
[23:15] <ubitux> so better gives them a bunch of useful tools to do something with that
[23:15] <wm4> just because you're developing for ffmpeg it doesn't mean you should dump whatever you find useful into its API
[23:15] <Daemon404> ^^^^^^^^^^^^^^^^^^^^^
[23:15] <ubitux> it's some generic pixel utilities, which we need in both libavcodec and libavfilter
[23:16] <ubitux> so it actually sounds like something useful for other users
[23:16] <ubitux> anyway, this was on the mailing-list a while ago
[23:16] <wm4> sounds like dsptuils reloaded...
[23:16] <ubitux> you could have commented
[23:22] <jamrial> wm4: it's basically a subset of me_cmp from lavc but in lavu
[23:52] <wm4> ubitux: hm, since when does libavformat return the correct ASS subtitle format?
[23:52] <wm4> ubitux: did it actually get bumped with the recent bump?
[00:00] --- Fri Aug 15 2014