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

[burek]

[01:25] <llogan> kierank: thanks. i closed it.
[01:28] <cone-517> ffmpeg.git 03Michael Niedermayer 07master:4090d5baa894: avcodec/h261dec: fix motion vector vissualization
[02:25] <Zeranoe> x265 recently dropped support for Windows XP, and since the Windows FFmpeg builds include x265 it broke FFmpeg too. I'm debating reverting x265 and holding back updates till support is added again, but that also effects all other Windows versions. I'm looking for some input on what is more important: cutting edge x265, or support for XP
[02:49] <Compn> Zeranoe : well win xp is on .... many millions of computers
[02:49] <Compn> and x265 is crap
[02:49] <Compn> so i'd say stick with winxp
[02:50] <Zeranoe> Compn: Even though XP is on the end of it's life? I thought x265 was the next big thing
[02:50] <Compn> just my opinion of course, not speaking for the project(s) at all.
[02:50] <Compn> Zeranoe : 'end of life' stuff is just because microsoft wants people to buy upgrades
[02:50] <Compn> :P
[02:51] <Zeranoe> No more updates related to security will be sent to XP
[02:51] <Compn> you could make two binaries
[02:51] <Compn> one for winxp, one for win vista+
[02:51] <Zeranoe> Trying to avoid that
[02:51] <Compn> well
[02:52] <Compn> 1. get many million computers upgraded 2. get microsoft to patch winxp further 3. drop winxp support
[02:53] <Zeranoe> 4. revert and hold back x265 updates
[02:54] <Compn> yep
[03:00] <J_Darnley> Why on Earth does x265 require vista?
[03:10] <drv> probably threading primitives, but just a guess
[03:11] <drv> https://bitbucket.org/multicoreware/x265/issue/44/threadingh-breaks-mingw-builds
[03:31] <J_Darnley> ugh
[03:32] <Zeranoe> I'm probably going to revert x265 and hold it back. No need to drop XP support yet if everything else works.
[04:24] <cone-517> ffmpeg.git 03Michael Niedermayer 07master:6795dcfa659c: avcodec/hevc: Export picture type
[04:24] <cone-517> ffmpeg.git 03Michael Niedermayer 07master:c05065aac0d9: avcodec/h261: move b_stride/b_xy under the if() where they are used
[07:09] <Zeranoe> Looks like XP users might be out of luck until x265 can add support back. After reverting FFmpeg complained about libx265 version must be >= 9. Options are now: 1. don't include x265 till it's fixed (no ETA at this time), 2. drop support for Windows XP and include x265
[07:31] <ubitux> xp is not supported anymore by MS, isn't it?
[07:31] <Case> it is until 8th of April
[07:36] <relaxed> therefore Zeranoe must also support it until then
[07:41] <wm4> why does it not support xp?
[07:42] <wm4> I mean what api is it using
[07:43] <JEEB> it's using the threading stuff that's not on NT5
[07:44] <wm4> like what?
[07:44] <JEEB> <muggs> mimicing a condition var on XP is non-trivial
[07:45] <JEEB> so condition variables it seems
[07:45] <wm4> eh
[07:45] <wm4> interesting
[07:47] <ubitux> BBB: tests done
[07:47] <ubitux> ^test^encode
[07:48] <ubitux> ssim summary updated etc
[07:49] <ubitux> difference is a lot smaller, but vp9 is still below at high bitrate
[07:50] <ubitux> but they're almost the same tbh
[08:53] <nevcairiel> suprising how many people come out of the woodwork to complain about lacking XP support in  x265, personally I would just say screw them and their ancient OS and move on :p
[08:55] <JEEB> ayup
[08:56] <JEEB> too bad MCW does have that one guy who seems to be like Lord
[08:56] <JEEB> using VC6 and barely updated to VS2008's compiler lately or so >_>
[08:56] <nevcairiel> well muggs pretty much said "patch or gtfo" but hey
[08:56] <JEEB> yup
[08:57] <JEEB> btw nevcairiel -- do you happen to have any BT.2020 test content :P
[08:57] <nevcairiel> dont think so
[08:57] <JEEB> k
[08:58] <nevcairiel> not sure any of those 4k trailers are actually bt.2020
[08:59] <JEEB> nah
[08:59] <JEEB> I haven't seen /any/
[08:59] <JEEB> it's this magical pixie dust in the specs but I haven't even seen the equivalent of the SMPTE bars in it yet
[09:00] <JEEB> The Japanese are going to have it in the satellite 4K spec, but I bet the first content that's going to be aired on that thing whenever they're gonna start doing it is going to be BT.709 :P
[09:00] <nevcairiel> lets hope they flag it at least
[09:01] <JEEB> they've been rather dilligent on that side so I would guess it should get flagged correctly
[10:38] <fjxx> hi
[10:39] <ubitux> :/
[10:40] <mmo> I have a problem using the ffmpeg libraries in my own program that plays video streams from a h264 ip camera. Is there someone that can help me?
[11:05] <cone-517> ffmpeg.git 03Carl Eugen Hoyos 07release/2.2:3ab63abbd471: Do not set swscale sizeFactor to -1.
[11:29] <BBB> ubitux: what was the link again?
[11:29] <BBB> ubitux: that's actually an interesting result
[11:29] <ubitux> http://lucy.pkh.me/encodes/ http://lucy.pkh.me/encodeshd/
[11:29] <ubitux> BBB ^
[11:31] <BBB> encodeshd is the new one right?
[11:35] <ubitux> BBB: yes
[11:35] <ubitux> from the bluray
[12:16] <kierank> i am not sure it is a good idea to print PSNR values
[12:16] <kierank> mostly because people won't understand you've used ssim optimisation
[12:26] <smarter> ubitux, BBB: I saw a commit that recently changed --aq-mode=1 to be less agressive (but also less effective on some clips at least)
[12:27] <smarter> ubitux: do you still see under/overshoot? I've been investigating vp9's ratecontrol recently but haven't found any reason for the 2x difference that happen sometimes
[12:35] <ubitux> smarter: the hd encode i did are with the exact same settings and version of libvpx
[12:35] <ubitux> it was done just to check the diff with the source
[12:35] <smarter> oh
[12:35] <ubitux> so yeah, same rate issue
[12:35] <smarter> interesting indeed
[12:36] <ubitux> feel free to grab the y4m
[12:36] <ubitux> and do the test :p
[12:37] <smarter> etvhd5k.y4m is the original?
[12:37] <ubitux> yes
[12:42] <BBB> ubitux: ah yes indeed much better (https://people.gnome.org/~rbultje/vp9/etvbr.png)
[12:42] <BBB> smarter: yes it still massively overshoots by 2x on this clip
[12:42] <smarter> and Daemon404 has a clip where it undershoots by 2x :p
[12:43] <BBB> vs. original https://people.gnome.org/~rbultje/vp9/etv_ssim.png
[12:43] <smarter> I've found some weird stuff looking through the ratecontrol code but nothing that should make things this bad
[12:44] <ubitux> http://code.google.com/p/webm/issues/detail?id=717  not sure if this is somehow related to rate control too
[12:44] <ubitux> ...but it's very annoying
[12:44] <smarter> I don't think I'm motivated enough to look at vp8 ratecontrol :p
[12:45] <ubitux> :D
[12:45] <BBB> it's vp9, not vp8
[12:46] <ubitux> BBB: #717 is vp8
[12:46] <BBB> o
[13:04] <BBB> I'll do a slight update to the blog post to add this as an addendum then
[13:04] <BBB> not today, probably over weekend, useful for people to know
[13:05] <BBB> but still doesn't address fundamental flaw of vp9 that we mentioned in the blog post: encoder-is-too-slow
[14:32] <cone-517> ffmpeg.git 03Diego Biurrun 07master:d0aabeab2375: x86: h264_qpel: Fix typo in CALL_2X_PIXELS macro invocation
[14:32] <cone-517> ffmpeg.git 03Michael Niedermayer 07master:8e8347b89291: Merge commit 'd0aabeab23755ee906440505ad2097c0f1493e80'
[14:38] <cone-517> ffmpeg.git 03Diego Biurrun 07master:d3c3c1664a95: dsputil: Move hpel_template #include out of dsputil_template
[14:39] <cone-517> ffmpeg.git 03Michael Niedermayer 07master:152c8fd856e5: Merge commit 'd3c3c1664a958923f234283e66fbcbfe69a6927f'
[14:51] <cone-517> ffmpeg.git 03Diego Biurrun 07master:e7373585f827: dsputil_template: Move bits that are used templatized into separate file
[14:51] <cone-517> ffmpeg.git 03Michael Niedermayer 07master:326206910111: Merge commit 'e7373585f827d4ec05d952daa3877e8decfe3c08'
[14:59] <cone-517> ffmpeg.git 03Diego Biurrun 07master:aba70bb5387f: Add missing headers to make template files compile (more) standalone
[14:59] <cone-517> ffmpeg.git 03Michael Niedermayer 07master:0371eaebcd1b: Merge commit 'aba70bb5387f12dfa5e6cd8cb861c9c7e668151f'
[15:07] <cone-517> ffmpeg.git 03Diego Biurrun 07master:2c01ad8b206d: dsputil_template: Detemplatize the code
[15:07] <cone-517> ffmpeg.git 03Michael Niedermayer 07master:e9c6b93bdaa6: Merge commit '2c01ad8b206d326700974438f7193f22be416eb1'
[15:17] <ubitux> so, when are we bumping lavf?
[15:18] <wm4> libav wants libav 11 to be API compatible to 10, so not yet
[15:19] <ubitux> ok
[15:19] <ubitux> so we're going to keep having mkv demuxer output ugly ass packets
[15:20] <ubitux> anyway, about http://trac.ffmpeg.org/ticket/3207#comment:3
[15:20] <ubitux> what's the meaning for SSA and ASS?
[15:20] <ubitux> ASS ’ in mkv, SSA ’ in .ass/.ssa ?
[15:20] <ubitux> mmh well no i see timing
[15:21] <ubitux> so not mkv related
[15:21] <wm4> ?
[15:21] <wm4> #3207 is about the header
[15:21] <ubitux> ASS being the new SSA ok
[15:22] <ubitux> this shit depresses me everytime i look at it
[15:23] <j-b> Unknown decoder 'copy'
[15:23] <j-b> grr
[15:23] <ubitux> ?
[15:24] <cone-517> ffmpeg.git 03Diego Biurrun 07master:8011ac911b3f: hpeldsp_template: Detemplatize the code
[15:24] <cone-517> ffmpeg.git 03Michael Niedermayer 07master:6967cf3c6c57: Merge commit '8011ac911b3f282b9fb64a0fc15404f8bfc7b7ed'
[15:25] <ubitux> i wonder how well our ass demuxer works for both ass and ssa
[15:26] <wm4> well your ass demuxer doesn't even accept all "valid" modern ass files
[15:27] <ubitux> really?
[15:28] <wm4> e.g. you expect that [ScriptInfo] is the first line
[15:29] <wm4> also don't take libass as reference, it's wrong too
[15:30] <ubitux> :(
[15:36] <cone-517> ffmpeg.git 03Diego Biurrun 07master:da5be235250a: dsputil: Move RV40-specific bits into rv40dsp
[15:36] <cone-517> ffmpeg.git 03Michael Niedermayer 07master:b4f64c58fc80: Merge commit 'da5be235250a61d6994408b054e3e3acf2e0f90f'
[15:41] <cone-517> ffmpeg.git 03Diego Biurrun 07master:92ba965103d3: dsputil: Move draw_edges and clear_block* out of dsputil_template
[15:41] <cone-517> ffmpeg.git 03Michael Niedermayer 07master:2d15e0c01dfd: Merge commit '92ba965103d3884609730ba9bf293772dc78a9ef'
[15:52] <cone-517> ffmpeg.git 03Diego Biurrun 07master:09d4389de10b: hpeldsp_template: Drop av_unused attribute from *_no_rnd_pixels16_8_c functions
[15:52] <cone-517> ffmpeg.git 03Michael Niedermayer 07master:a49bdcdee549: Merge commit '09d4389de10b03ea65a84eaf3d6c4b7a7538ad75'
[16:55] <cone-517> ffmpeg.git 03Diego Biurrun 07master:55d7f26e7bcf: hpeldsp_template: Move content to hpeldsp
[16:55] <cone-517> ffmpeg.git 03Michael Niedermayer 07master:b7f0d39d2629: Merge commit '55d7f26e7bcf1dfb69ee986aa9fc21c62e0b3ae6'
[16:59] <wm4> ubitux: hm libavformat's architecture makes it pretty hard to support what I intended to do for utf16 support
[16:59] <ubitux> :p
[16:59] <funman> wm4: time to fork it?
[17:00] <wm4> maybe I could always assume that UTF16 files have a BOM
[17:06] <Plorkyeran_> strictly speaking UTF-16 files always have a BOM (in that if there's no BOM they're UTF-16LE or UTF-16BE)
[17:06] <Plorkyeran_> and you're only supposed to use the BE and LE versions if the exact encoding is transmitted in some external fashion
[17:07] <wm4> assuming that a BOM always exists would make some things near-trivial
[17:08] <Plorkyeran_> in the context of reading a file, either the file format specifies the exact encoding, the file has a BOM, or the file is invalid
[17:48] <cone-517> ffmpeg.git 03Diego Biurrun 07master:efc7290eb668: x86: hpeldsp: Keep all rnd_template instantiations in hpeldsp_init
[17:48] <cone-517> ffmpeg.git 03Michael Niedermayer 07master:4998a72b497f: Merge remote-tracking branch 'qatar/master'
[18:20] <cone-517> ffmpeg.git 03Michael Niedermayer 07master:289b149cecb3: avcodec/h264_mp4toannexb_bsf: prepend global headers before any in stream parameter sets
[18:54] <cone-517> ffmpeg.git 03Michael Niedermayer 07master:54e2e9fbc15e: avutil/frame: undeprecate AVFrame.motion_val API
[18:54] <cone-517> ffmpeg.git 03wm4 07master:5b0ce5d4e366: vf_pullup: simplify, fix double free error
[18:54] <cone-517> ffmpeg.git 03Michael Niedermayer 07master:a44409e692e8: avfilter/vf_pullup: zero freed memory for saftey
[18:59] <wm4> michaelni: what kind of safety is that?
[19:11] <llogan> how big is NTV in Russia?
[19:12] <JEEB> one of the bigger ones
[19:12] <iive> does N stand for National?
[19:13] <JEEB> I didn't think it stood for anything
[19:14] <JEEB> oh, it was "national channel 4" from 1984 to 1991
[19:14] <JEEB> but after that it was without any N
[19:17] <llogan> they wanted interview footage but i can't do it now.
[19:18] <JEEB> I've only been on the 1st channel
[19:18] <JEEB> and almost said the F word in Russian :P
[19:18] <JEEB> https://dl.dropboxusercontent.com/u/175558/photos/oldies/snapshot200709051926.jpg
[19:18] <JEEB> have a young JEEB
[19:21] <llogan> what were they interviewing you about?
[19:22] <JEEB> politics and stuff
[19:23] <JEEB> I then later went on to do brown-paper-bag work for TV Kultura, live translation of an interview with famous Finnish writers
[19:24] <JEEB> (whom I didn't even know by face which is kind of embarrassing)
[19:55] <michaelni> wm4, saftey as in zeroing out pointers so any attempts to dereference will be clear and reproduceable and not odd rare crashes
[19:56] <wm4> michaelni: this could go just the other way as well, and it might actually _reduce_ the likelihood that a bug is accidentally found, which is bad
[19:57] <wm4> and also, everyone reading this code will be very confused
[19:57] <wm4> because writing to memory before freeing it does by definition nothing
[19:57] <michaelni> ill add a comment explaining it
[19:57] <wm4> and if you think this is so effective, why not zero memory in av_free? etc.
[19:58] <michaelni> av_freep() does clear the pointer
[19:58] <wm4> the pointer, but not the memory, so it's entirely different
[19:58] <ubitux> CONFIG_MEMORY_POISONING to the rescue
[19:59] <michaelni> wm4 if you want i can replace the memset by clearing the pointers one by one
[19:59] <michaelni> its the same but more code
[19:59] <wm4> ubitux: yes this is the job of memory debugging tools
[20:00] <michaelni> av_freep() alone isnt enough because the double linked ring
[20:40] <cone-517> ffmpeg.git 03Ben Avison 07master:15a29c39d9ef: truehd: add hand-scheduled ARM asm version of mlp_filter_channel.
[20:40] <cone-517> ffmpeg.git 03Michael Niedermayer 07master:3017239d3a6f: avfilter/vf_pullup: add comment to explain memset(0)
[20:40] <cone-517> ffmpeg.git 03Ben Avison 07master:87b128d5ef6a: truehd: add hand-scheduled ARM asm version of mlp_filter_channel.
[20:40] <cone-517> ffmpeg.git 03Michael Niedermayer 07master:f38af0143c18: Merge commit '15a29c39d9ef15b0783c04b3228e1c55f6701ee3'
[20:48] <cone-517> ffmpeg.git 03Ben Avison 07master:4e5aa080bb8d: truehd: break out part of rematrix_channels into platform-specific callback.
[20:48] <cone-517> ffmpeg.git 03Ben Avison 07master:3f4e73afe927: truehd: break out part of rematrix_channels into platform-specific callback.
[20:48] <cone-517> ffmpeg.git 03Michael Niedermayer 07master:80e67feda806: Merge commit '4e5aa080bb8d83cb6de1ffbdd7b37ec34bc6b30b'
[20:55] <llogan> two license violation tickets closed in two days
[20:56] <cone-517> ffmpeg.git 03Ben Avison 07master:483321fe7895: truehd: add hand-scheduled ARM asm version of ff_mlp_rematrix_channel.
[20:56] <cone-517> ffmpeg.git 03Ben Avison 07master:89135716fd4c: truehd: add hand-scheduled ARM asm version of ff_mlp_rematrix_channel.
[20:56] <cone-517> ffmpeg.git 03Michael Niedermayer 07master:44dc373d4a7e: Merge commit '483321fe789566dcb27b6387c00ea16dd86bc587'
[21:05] <cone-517> ffmpeg.git 03Ben Avison 07master:fcf5fc444522: truehd: tune VLC decoding for ARM.
[21:05] <cone-517> ffmpeg.git 03Ben Avison 07master:b9eb03416d93: truehd: break out part of output_data into platform-specific callback.
[21:05] <cone-517> ffmpeg.git 03Ben Avison 07master:b01a2562ae3f: truehd: break out part of output_data into platform-specific callback.
[21:06] <cone-517> ffmpeg.git 03Michael Niedermayer 07master:179cf1483262: Merge commit 'fcf5fc444522d24caa9907225802817ae788f511'
[21:06] <cone-517> ffmpeg.git 03Michael Niedermayer 07master:fc64e128f008: Merge commit 'b9eb03416d93a5c4ece27ffef5e6e11c81bec6fa'
[21:28] <cone-517> ffmpeg.git 03Ben Avison 07master:3b5946bccef6: truehd: add hand-scheduled ARM asm version of ff_mlp_pack_output.
[21:28] <cone-517> ffmpeg.git 03Michael Niedermayer 07master:50b68e323c41: Merge remote-tracking branch 'qatar/master'
[00:00] --- Thu Mar 27 2014