[00:09] <michaelni> kurosu, probably the high 16bits contained some intermediate values and where not 0 [00:10] <michaelni> so it shouldnt be needed anymore [00:10] <kurosu> it's not like it's going to hurt after 12 years of innocuous behaviour, but yeah... I don't see why it is needed [00:11] <kurosu> and if it is needed, then I don't think any fate test currently exhibits the problem [00:12] <michaelni> kurosu, ill rerun fate and remove it [00:13] <kurosu> as you wish [00:17] <cone-584> ffmpeg.git 03Michael Niedermayer 07master:b50559fc0b2b: libavcodec/x86/dsputilenc: drop and 0xffff that should have becomei redundant [00:20] <kurosu> as you wish [00:20] <kurosu> woops [00:26] <cone-584> ffmpeg.git 03Luca Barbato 07master:6d212599aa68: avformat: Provide a standard compliance flag [00:26] <cone-584> ffmpeg.git 03Michael Niedermayer 07master:d858ee717bed: Merge commit '6d212599aa684f30511fb08ca30fe2378405304e' [00:36] <llogan> cehoyos: ef48ac6 breaks speex decoding (found by massdos in #ffmpeg) with http://samples.ffmpeg.org/A-codecs/speex/h264_speex.mp4 [01:18] <cone-584> ffmpeg.git 03Luca Barbato 07master:c94e2e85cb6a: nut: Support experimental NUT 4 features [01:18] <cone-584> ffmpeg.git 03Michael Niedermayer 07master:a8499cbbe87d: Merge commit 'c94e2e85cb6af8a570d8542a830556243bd32873' [01:20] <compn> neat [01:20] <compn> washington attorney general asking for support with SN40 codec :D [01:24] <cone-584> ffmpeg.git 03Luca Barbato 07master:b2d456542205: avresample: Add avresample_get_out_samples [01:24] <cone-584> ffmpeg.git 03Michael Niedermayer 07master:bdb2e80e88e7: Merge commit 'b2d45654220503224aa94e78cdff19ec624e9342' [01:31] <cone-584> ffmpeg.git 03Luca Barbato 07master:ad0fe2f40120: af_resample: Use avresample_get_out_samples [01:31] <cone-584> ffmpeg.git 03Michael Niedermayer 07master:20343cfb51ea: Merge commit 'ad0fe2f4012031c47268f14b9835088c488e1998' [01:36] <compn> anyone knwo what this site is or who runs it ? http://ffmpegmac.net/ [01:41] <llogan> compn: i believe Sebastian Tischer $(surname).s at me.com [01:55] <compn> llogan : so its a legit site then ? :P [01:55] <llogan> i think so [01:56] <llogan> i've never tried his builds, but i don't have OSX [02:18] <UtUser> The Ut Video decoder is still busted in case anybody cares [02:23] <cone-584> ffmpeg.git 03Michael Niedermayer 07master:99b15f1daae1: avformat/nutenc: fix used version value [02:23] <cone-584> ffmpeg.git 03Michael Niedermayer 07master:45daae06fd6f: avformat/nutenc: change check to match comment [02:23] <cone-584> ffmpeg.git 03Michael Niedermayer 07master:170a4d79c04c: avformat/nutenc: bump minor version due to broadcast/pipe [02:23] <cone-584> ffmpeg.git 03Michael Niedermayer 07master:6b041cb617e5: avformat/nutdec: Fix handling of older 4.0 files [03:02] <compn> UtUser : we care, decoding or encoding ? [04:11] <UtUser> sorr for the hours-late response. DECODING, I think [04:11] <UtUser> compn: as per http://trac.ffmpeg.org/ticket/2661 [04:12] <UtUser> and don't forget I already sent out a 20 MB sample of the kind of Ut Video frames that give errors in ffmpeg [04:12] <UtUser> maybe you won't here [04:12] <UtUser> I'll try and find the URL [04:12] <cone-584> ffmpeg.git 03Michael Niedermayer 07master:df889be0a89a: nutenc: avoid av_tree_find() operation per syncpoint [04:12] <UtUser> someone should verify this and re-open the ticket IMHO [04:12] <cone-584> ffmpeg.git 03Michael Niedermayer 07master:82beb46e65e5: avformat/nutenc: add mode that omits the index [04:12] <cone-584> ffmpeg.git 03Michael Niedermayer 07master:6d1aba6a29b4: avformat/nutenc: limit index table size if no index is going to be written [04:13] <UtUser> here's one of the mirrors: http://www.sockshare.com/file/EBEC6306126D92F0 [04:14] <UtUser> compn, Daemon404 [04:25] <compn> ehe, i dont dare cross carl the trac warrior by reopening a bug :) [04:25] <compn> leave it closed , can continue commenting on it however [04:32] <cone-584> ffmpeg.git 03Michael Niedermayer 07master:78a79a2ceb63: avformat/nutenc: replace conditional by assert [04:57] <UtUser> compn, I'm not sure if that's the best course of action [04:57] <UtUser> fixed doesn't mean fixed here [05:26] <UtUser> now I'll just sit and wait [05:43] <compn> UtUser : you got latest git ? just making sure you arent using old ffmpeg... [05:43] Action: compn afk [05:44] <UtUser> I'll install a build from today to make ure [05:45] <UtUser> but unless somebod fixed it yesterday, I'm pretty sure [05:49] <UtUser> yep, it's still broke [05:54] <michaelni> BBB, posted a patch for a quick n dirty fate test for async [06:23] <UtUser> how do I get a sample onto ffmpeg's site? [06:23] <UtUser> I plan to reopen and I wat to have proof to back me up [06:38] <UtUser> SOMEBODY CONFIRM THIS FUCKING THING SO IT CAN GET FIXED [10:54] <ubitux> UtUser: this is a development channel you know, not a special support one; you could open a new ticket [10:57] <ubitux> UtUser: carl just sent a patch btw [10:58] <ubitux> UtUser: see https://ffmpeg.org/pipermail/ffmpeg-devel/2014-May/158171.html [12:17] <kurosu> what's the avantage of utvideo over huffyuv+median ? [12:17] <kurosu> they are both huffman coding and median [12:18] <kurosu> there's maybe that YCoCg-like transform in utvideo, but that's about it? [12:23] <J_Darnley> As I recall it started out as someone filling whatever niche they had. [12:25] <kurosu> from what I see, their prediction enforces int intermediate (no wraparound), so I would expect simd to have around a halved performance [12:25] <J_Darnley> I think it might have been so they could use some encoding API for which no other codec was then available [12:26] <kurosu> the existence of that codec is weird - except for filling a niche, I can't make sense of it [12:26] <J_Darnley> Was this codec also the one that uses floats? [12:26] <kurosu> no that's algarith arithmetical entropy codec [12:27] <kurosu> or lagarith, rather [12:28] <J_Darnley> oh yes [12:28] <kurosu> I think michaelni added variations of YCoCg to ffv1, but I don't see why a huffyuv 3.0 or whatever couldn't [12:28] <J_Darnley> If you want to find its origins, I think I first saw it being demoed on Doom9's "alternative codecs" forum [12:28] <kurosu> then no difference for rgb input [12:29] <J_Darnley> Lots of redundant or duplicate work happens, unfortunately [12:30] <kurosu> it's often a lemma in lossless coding it seems [12:31] <J_Darnley> Here's the thread, I think: http://forum.doom9.org/showthread.php?t=143624 [12:31] <J_Darnley> It didn't surprise me to see thet the author link is to some japanese blog [12:33] <Daemon404> the niche at the time was sliced threading [12:33] <Daemon404> iirc [12:34] <Daemon404> although it supports 10bit now [12:34] <Daemon404> (i need to add that to the decoder maybe) [12:34] <kurosu> and frame threading wasn't an option ? [12:34] <kurosu> all the more for an intra codec [12:35] <BBB> michaelni: ty! [12:35] <Daemon404> kurosu, latency vs throughput [12:35] <Daemon404> the ageold debate. [12:35] <Daemon404> anyways, beats me [12:36] <Daemon404> im not the euthor [12:36] <Daemon404> author* [12:37] <BBB> kurosu: most of these codecs exist because the author went to college, had nothing to do, didn't google-search before <T> and then T=started to code [12:37] <kurosu> isn't latency more of a decoding issue? and being intra, I don't think the difference between 1/70s and 1/360 would matter ? [12:37] <kurosu> anyway, yeah, I'm beating a dead horse here [12:44] <cone-339> ffmpeg.git 03Roman Savchenko 07master:a53551cba86b: frame: fix the error path in av_frame_copy_props() [12:44] <cone-339> ffmpeg.git 03Michael Niedermayer 07master:d9c4f61dab2a: Merge commit 'a53551cba86bb67efcb6105fdc337a36c43132bd' [13:02] <kurosu> ah VfW - explains slice threading [13:05] <cone-339> ffmpeg.git 03Anton Khirnov 07master:81eec081afea: matroskaenc: base DefaultDuration on the framerate, not the codec timebase [13:05] <cone-339> ffmpeg.git 03Michael Niedermayer 07master:bc59d39b8249: Merge commit '81eec081afea9fc017a175581ceea7c420a0dfc3' [13:19] <cone-339> ffmpeg.git 03Anton Khirnov 07master:cf6977712c9e: movenc: write avg_frame_rate as the framerate, not the codec timebase [13:19] <cone-339> ffmpeg.git 03Michael Niedermayer 07master:a72df4dadc0d: Merge commit 'cf6977712c9e5abe6dc55289f6322ccbf10321a9' [13:30] <JEEB> <kurosu> what's the avantage of utvideo over huffyuv+median ? <- mostly the fact that the guy doing Ut Video basically went and implemented it for pretty much all of the relatively important multimedia frameworks; VfW, DShow, MF and QuickTime. [13:37] <cone-339> ffmpeg.git 03Anton Khirnov 07master:43e7f0797f9f: flvenc: only write the framerate tag based on avg_frame_rate [13:37] <cone-339> ffmpeg.git 03Michael Niedermayer 07master:e46cc1dab05e: Merge commit '43e7f0797f9f821a3866a20f05e512e13c82076a' [13:49] <cone-339> ffmpeg.git 03Anton Khirnov 07master:962d63157322: matroskaenc: set the stream timebase earlier [13:49] <cone-339> ffmpeg.git 03Michael Niedermayer 07master:4991eacc064f: Merge commit '962d63157322466a9a82f9f9d84c1b6f1b582f65' [13:52] <kurosu> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/huffyuvenc.c;hb=HE... <- I'm not getting what's happening [13:53] <kurosu> if w<32, process w elements, otherwise process _16_ elements !? [13:54] <kurosu> the encoder processes 16 elements a time or something ? [13:55] <kurosu> michaelni, you're the author, so ... ? ^ [14:00] <michaelni> ... otherwise process 16 elements in C and the rest in SIMD [14:01] <michaelni> the 16 is needed due to avoiding to read out of array and maintaining alignment for SIMD [14:02] <michaelni> sure could be done differently of course ... [14:13] <kurosu> oh... diff_bytes here is used to compute left prediction? [14:16] <kurosu> anyway ok [14:16] <michaelni> yes [14:18] <cone-339> ffmpeg.git 03Christophe Gisquet 07master:c609f803e1c1: huffyuv: avoid duplicated defines [14:47] <kurosu> michaelni, I was reworking the add_bytes anyway [14:47] <kurosu> for some reason an initial benchmark showed the sse2 version to bring nothing [14:47] <kurosu> hence the use of movu /... [14:48] <kurosu> I wasn't sure it was never called with unaligned positions, as I'm not sure I test all possible cases [14:48] <kurosu> I'm using fate-lagarith fate-vsynth[12]-huffy [14:56] <michaelni> the header says: void (*add_bytes)(uint8_t *dst /* align 16 */, uint8_t *src /* align 16 */, [14:56] <michaelni> so it should be aligned [14:57] <cone-339> ffmpeg.git 03Christophe Gisquet 07master:25e6310a3ec9: huffyuv: change left prediction access in BGRA [14:57] <kurosu> and median_pred doesn't say that, and indeed it does unaligned access (first element on line using top pred I guess) [14:58] <kurosu> but that's probably why I didn't dare the devil [14:58] <kurosu> will change it [14:58] <kurosu> the sse2 version is actually twice as fast [14:58] <kurosu> though it's negligible iirc (a profile on some huffyuv decoding showed < 1%) [15:16] <kurosu> btw, I found unaligned loads on newer cpus to have a negligible impact [15:16] <kurosu> sometimes even trying to distinguish between the 2 actually incurs a loss in total [15:26] <kurosu> what happened to ffv2 (which was worked on by x264 authors)? I guess functionalities-wise it's not up to par with ffv1, but the base was kind of good ? [15:33] <compn> was it incorporated into ffv1 1.3 ? [15:33] <compn> or is this something else i dont remember hearing about ? [15:36] <JEEB> it's something that pengie was playing with for a while [15:37] <JEEB> you have some diffs from 2009-2010 @ http://akuvian.org/src/x264/ [15:41] <kurosu> dead a long time ago then [17:33] <cone-339> ffmpeg.git 03Michael Niedermayer 07master:f518fb33184b: avcodec/dpx_parser: reset index when finding a startcode, not after [17:33] <cone-339> ffmpeg.git 03Michael Niedermayer 07master:8df5d9aabfbf: avcodec/dpx_parser: fix flushing end out [17:33] <cone-339> ffmpeg.git 03Michael Niedermayer 07master:fba0ac28055d: avcodec/dpx_parser: Allow frame size to be too small [18:14] <kurosu> michaelni, reworking add_hfyu_left_pred_bgr32, no need to review for now [18:15] <michaelni> ok [18:22] <cone-339> ffmpeg.git 03Martin Storsjö 07master:08cd92144e73: aarch64: Use the correct syntax for relocations [18:22] <cone-339> ffmpeg.git 03Michael Niedermayer 07master:232959f184e1: Merge commit '08cd92144e73195eecc28ed0348e66e255516b82' [18:54] <cone-339> ffmpeg.git 03James Almer 07master:05de4d30111e: x86/dsputilenc: implement XOP version of pix_sum16 [20:13] <cone-339> ffmpeg.git 03Michael Niedermayer 07master:40a4ab8ba4bf: rename sub_hfyu_median_prediction_int16 to sub_hfyu_median_pred_int16 [20:13] <cone-339> ffmpeg.git 03Michael Niedermayer 07master:550ae6c02f61: rename add_hfyu_median_prediction_int16 to add_hfyu_median_pred_int16 [20:13] <cone-339> ffmpeg.git 03Michael Niedermayer 07master:7b4c46050e68: rename add_hfyu_left_prediction_int16 to add_hfyu_left_pred_int16 [21:24] <kurosu> jamrial, I benchmarked it be slower [21:24] <kurosu> though I hadn't written the sse2 version yet [21:44] <cone-339> ffmpeg.git 03Christophe Gisquet 07master:bf7e9cc82a84: tests: allow passing dimensions to videogen [21:51] <jamrial> Interesting. I'd expect two less movq/dqa to be faster. paddb speed shouldn't change regardless of using a reg or mem as source [21:52] <jamrial> at least when i looked at some latency benchmarks online [21:53] <cone-339> ffmpeg.git 03Christophe Gisquet 07master:226700398105: x86: hpeldsp: better factorization [21:53] <kurosu> this goes into details above my head [21:53] <kurosu> usually, I just try and see if it's better [21:54] <kurosu> but that's sometimes useless [21:54] <kurosu> because it may actually hurtful to a much older/newer cpu [21:54] <jamrial> true [21:54] <kurosu> *be hurtful [21:55] <jamrial> considering the mmx versions are now only going to be used by old cpus, benchmarking it on new cpus doesn't really give a proper image of a real world scenario [21:55] <kurosu> yeah [21:56] <kurosu> on those I remember you had to be really careful about your insn scheduling [22:07] <kurosu> jamrial, re: add missing guards to ff_pix_sum16_xop, wouldn't an equivalent check be needed in the _init code ? [22:08] <UtUser> >Have you tried the sample with the official decoder? If that breaks, then its not our decoder which needs to be fixed, but our encoder. [22:08] <UtUser> I havesome mre testing to do. [22:12] <jamrial> EXTERNAL_<opt> macros in the _init code take care of that [22:13] <kurosu> ok, this is set based on detection by configure then [22:15] <jamrial> yeah, those macros expand to "HAVE_<opt>_EXTERNAL && (cpuflag & AV_CPU_FLAG_<opt>)" which is optimized out when HAVE_<opt>_EXTERNAL is 0 [22:30] <cone-339> ffmpeg.git 03Christophe Gisquet 07master:99a319c4e753: x86: huffyuvdsp: port add_bytes to yasm [22:35] <fionag> out of curiosity, is there some reason the PIX_SUM doesn't use psadbw already? [22:35] <fionag> it seems a little weird that it doesn't, unless I'm misunderstanding the purpose of the function [22:35] <JEEB> UtUser, if it seems like a bug in the encoder, feel free to poke me. I'll try to poke it after I get back from work tomorrow [22:35] <UtUser> I was just quoting somebody else [22:35] Action: JEEB is the guy whose name is on the top of utvideoenc.c [22:36] <UtUser> ok [22:36] <JEEB> I did enable slices at one point automatically depending on the amount of cores you have, but I did check against the official encoder if I recall correctly [22:36] <UtUser> how does one use the official encoder, by the way? [22:37] <JEEB> encoder/decoder, probably via VfW and VirtualDub [22:37] <UtUser> ah [22:37] <JEEB> there's a libutvideo wrapper, but I've always felt like using vdub and feeding it exactly the data I wanted to test was simpler [22:38] <UtUser> well, honestly I'd prefer the CLI [22:38] <UtUser> I've got a test clip [22:38] <UtUser> if I try and transcode it with libutvideo I may or may not get errors [22:38] <JEEB> oh, you only use libutvideo? [22:38] <JEEB> not the internal encoder [22:38] <UtUser> I use utvideo [22:38] <UtUser> internal [22:38] <JEEB> k [22:39] <UtUser> never tried libutvideo [22:39] <UtUser> both in ffmpeg? just to make sure [22:39] <JEEB> yeah, you need to build the lib and I'm not sure how many updates it got [22:39] <JEEB> latter needs the ut video library of course [22:39] <UtUser> :( [22:39] <UtUser> hmm [22:39] <JEEB> I just generally want to keep lavf/lavc as far from creating sample/results [22:40] <JEEB> so I use the official encoder/decoder in vdub when I need to test against a reference [22:40] <UtUser> ok [22:40] <UtUser> so I'm firing up vdub [22:40] <UtUser> wait [22:40] <JEEB> http://umezawa.dyndns.info/wordpress/?p=4809 [22:40] <JEEB> official ut video [22:41] <JEEB> also if you can give me a sample that I can repro things with that is an alternative as well [22:42] <UtUser1> I am so sorry [22:42] <UtUser1> my webchat client froze again [22:42] <UtUser1> anyways, I am unsure of how to proceed [22:43] <JEEB> <JEEB> http://umezawa.dyndns.info/wordpress/?p=4809 [22:43] <JEEB> <JEEB> official ut video [22:43] <JEEB> <JEEB> also if you can give me a sample that I can repro things with that is an alternative as well [22:43] <UtUser1> well actually I think somebody already split and uploaded it... [22:43] <UtUser1> http://trac.ffmpeg.org/ticket/2661#comment:6 [22:43] <JEEB> ok [22:43] <JEEB> can you tell me if it happens with one slice? [22:44] <UtUser1> hm? [22:44] <JEEB> after -i you set -slices [22:44] <JEEB> to set the amount of sliced used for encoding [22:44] <UtUser1> oh boy [22:44] <UtUser1> see, here's the problem [22:44] <UtUser1> not every frame is bugged [22:45] <JEEB> well, I just want to know if it borks at all with one slice [22:45] <UtUser1> so I'll encode like 2 minutes of video and there might be 4 seconds of bgged frames [22:45] <UtUser1> I see your point though [22:45] <UtUser1> it may take some time however [22:45] <JEEB> I put a change in in February because the official Ut Video decoder only threads in slices [22:45] <JEEB> The official Ut Video decoder only threads with slices, thus until [22:45] <JEEB> now any files encoded by the libavcodec encoder have only been [22:45] <JEEB> decodable with a single thread. The default slice count is now [22:45] <JEEB> set to subsampled_height / 120. [22:46] <JEEB> before that it was always -slices 1 [22:46] <UtUser1> I see [22:46] <JEEB> I had tested that things would decode correctly at that point [22:46] <UtUser1> a likely culprit [22:46] <JEEB> but you never know, so it's worth a try [22:46] <UtUser1> ok [22:46] Action: JEEB is rather dry and down-to-earth in these things [22:46] <UtUser1> just to confirm [22:47] <UtUser1> should I be decoding the busted clip or encoding a newone? [22:47] <JEEB> encode the clip that makes the encoder create files that bork at decoding [22:47] <UtUser1> ok [22:47] <JEEB> encode -> decode -> check if it borked [22:48] <JEEB> also, I'm happy that some people use my encoder :) [22:48] <UtUser1> I think it's one of the greatest features of ffmpeg [22:48] <UtUser1> I use it for my masters [22:48] <JEEB> I was kind of worried about it not getting used because the libutvideo wrapper was already in :) [22:49] <UtUser1> well, people like me just type in the most obvious thing [22:49] <UtUser1> like utvideo without the lib part [22:49] <UtUser1> seriously [22:50] <UtUser1> you can also type in things like h264, etc. [22:50] <UtUser1> aac gives you the experimental encoder [22:50] <UtUser1> the offical name is "ut video", so I just removed the space, and to my amazement, it worked, so I used that :) [22:58] <JEEB> UtUser1, anyways, after you can confirm if it happens with one slice or not, feel free to poke me with a sample that I can then encode with the encoder and try and feed it to the official decoder [22:58] <UtUser1> uh [22:59] <UtUser1> you've lost me [22:59] <UtUser1> I'm encoding with one slice now [22:59] <JEEB> yes [22:59] <UtUser1> it should be done soon [22:59] <JEEB> since it seems to be taking a while [22:59] <UtUser1> it's about a minute but I had to get the settings right [22:59] <JEEB> k [22:59] <UtUser1> I just had some soup [23:00] <JEEB> and I'll have to be up in ~6 hours [23:00] <UtUser1> oh shit it'll be like 5 more minutes [23:00] <UtUser1> oh no man [23:00] <UtUser1> well ok [23:00] <UtUser1> you do that [23:00] <UtUser1> sleep and whatnot [23:00] <JEEB> just poke me, I will read through the backlog [23:01] <JEEB> tell me if it happens with just multiple slices or if just one slice is affected too, and then please link a sample I can throw at my encoder to replicate [23:01] <JEEB> :) [23:01] <JEEB> and I can then check the output against the official decoder [23:02] <UtUser> AHHHHHHHHH [23:02] <UtUser> my IRC cient crashd again [23:02] <JEEB> <JEEB> just poke me, I will read through the backlog [23:02] <JEEB> <JEEB> tell me if it happens with just multiple slices or if just one slice is affected too, and then please link a sample I can throw at my encoder to replicate [23:02] <JEEB> <JEEB> :) [23:02] <JEEB> <JEEB> and I can then check the output against the official decoder [23:02] <UtUser> ok [23:03] <UtUser> not sure if the encode-able sample part will work [23:03] <UtUser> too big a file I'm trying right now [23:03] <JEEB> well if you can limit it to the pictures that are borked [23:03] <JEEB> and see if they by themselves make it happen [23:03] <UtUser> so it's always the same behavior and not random? [23:03] <JEEB> it should be [23:03] <UtUser> ok [23:04] <JEEB> unless there's some really weird shit going on, but at least the encoder is fully dependant on only that one picture you're feeding it [23:05] <UtUser> well, I'll try and let you know [23:05] <UtUser> I'll probably be nice and cozy at home while you're at work [23:05] <UtUser> get some sleep now [23:05] <UtUser> I'll do my best [23:06] <cone-339> ffmpeg.git 03James Almer 07master:02a3e327f118: x86/dsputilenc: add missing guards to ff_pix_sum16_xop [23:50] <cone-339> ffmpeg.git 03Michael Niedermayer 07master:b3f461508176: ffmpeg: fix check for muxing overhead being unknown [23:55] <cone-339> ffmpeg.git 03Diego Biurrun 07master:2ea2612df508: svq1enc: Rename SVQ1Context to SVQ1EncContext [23:55] <cone-339> ffmpeg.git 03Michael Niedermayer 07master:cb8763bda7e5: Merge commit '2ea2612df508abdd1f97c6a6ef56275a52c5c41e' [00:00] --- Fri May 30 2014