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

[burek]

[09:07] <anshul_> help: i was trying to analyse bug 2093, need problem.rm video
[09:13] <sspiff> anshul_: isn't it linked at the top of the bug report?
[09:13] <sspiff> http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket2077/problem.rm ?
[09:14] <sspiff> anshul_: downloads fine here
[09:14] <anshul_> thanks i never noticed that
[09:15] <sspiff> anshul_: you're welcome
[09:19] <anshul_> In that report michael and cehoyos were unable to reproduce the problem on linux, was it playable on linux
[09:21] <anshul_> at my place on linux, i am not able to play that video, but i get these warning
[09:21] <anshul_> [rm @ 0xb10025c0] Unsupported stream type 000003a
[09:21] <sspiff> anshul_: using ffplay?
[09:23] <sspiff> ffplay gives me the output seen in https://trac.ffmpeg.org/ticket/2093#comment:15
[09:23] <sspiff> mplayer plays the file fine
[09:25] <anshul_> ok
[09:40] <anshul_> sspiff isn't mplayer too use the libavcodec and component specified in bug report is avcodec
[10:02] <sspiff> anshul_: I think mplayer has its own decoders
[10:13] <sspiff> ubitux: My idea of how to solve the encoding issue was crap :) I don't see how it can be solved without having the encoder output packets directly (or keeping track of a queue of out-of-order packets that need to be sent later on each output stream)
[10:46] <plepere> hello
[10:48] <plepere> I'm currently working on the OpenHEVC decoder which works in ffmpeg, and I'm told that you don't really like SSE intrinsics, so I'm going to pass the low level functions (MC and all) to assembly.
[10:48] <plepere> is someone already on assembly HEVC decoding ?
[10:49] <nevcairiel> I havent heard of someone specifically working on assembly routines
[10:50] <ubitux> i think Skyler_ was talking about doing some at some point, but it's been a while now
[10:50] <nevcairiel> make sure to write them in YASM and not inline gcc asm thogh =)
[10:50] <plepere> nevcairiel, sure !
[10:50] <ubitux> you might want to ask smarter and mraulet
[10:51] <plepere> I just want to make sure that there won't be 2 people doing the same thing.
[10:51] <plepere> I work with mraulet. :)
[10:51] <ubitux> oh.
[10:54] <plepere> but thanks for the indication.
[10:57] <plepere> I also cross-compiled ffmpeg for android and managed to decode some HEVC on my phone, so it's quite solid. :)
[12:42] <cone-764> ffmpeg.git 03kowalsky 07master:4684539c9148: avformat/hls: fixed bug where custom http headers weren't kept for hls streams
[14:12] <sspiff> can anyone point me to where AVSubtitle.pts is ever set?
[14:12] <sspiff> I can't find it...
[15:03] <{V}> sspiff, https://github.com/FFmpeg/FFmpeg/blob/02a6ee51685eb74f7a878dd49553ecc1f8da9fb2/libavformat/subtitles.c#L54  ?
[15:04] <{V}> oh wait. that's AVPacket
[15:09] <ubitux> sspiff: avcodec_decode_subtitle2
[15:09] <ubitux> sub->pts = ...
[15:14] <sspiff> ubitux: thanks, I found it eventually :)
[15:24] <cone-764> ffmpeg.git 03Michael Niedermayer 07master:cbe84b4ffae4: avformat/astdec: sanity check channels & sample rate
[16:12] <plepere> hmm
[16:13] <plepere> should I do x64 assembly or stick to 32bit code ?
[16:14] <ubitux> for vp9 8x8 idct i only added a x64 one
[16:14] <ubitux> because it was a pain for 32
[16:14] <ubitux> so i guess you can do x64 only for a start
[16:31] <durandal_1707> lol what review fail
[16:38] <ubitux> durandal_1707 ?
[16:49] <durandal_1707> ubitux: not your code
[16:51] <ubitux> durandal_1707: ok...
[16:52] <ubitux> durandal_1707: btw, are you going to add threading to vp9?
[16:52] <durandal_1707> why would I?
[16:52] <ubitux> because you love threading of course
[16:52] <durandal_1707> but i do not love vp9
[16:52] <ubitux> why? :(
[16:53] <ubitux> you prefer vf rotate?
[16:53] <durandal_1707> i prefer lossless
[16:56] <durandal_1707> ubitux: i think BBB is going to do it
[16:58] <ubitux> he's busy with 32x32 idct, and probably 16x16 later
[16:58] <ubitux> he asked me to do the threading because it was supposely simple (and would offer quite some optim)
[16:58] <ubitux> but i don't like it
[16:58] <ubitux> so i suggested you do it
[16:59] <durandal_1707> why you do not like it?
[17:01] <ubitux> i find debugging way too random
[17:01] <ubitux> not enough binary, too much black magic to me
[17:02] <durandal_1707> there is no magic at all
[17:02] <ubitux> speaking of random ^
[17:02] <durandal_1707> you just need to recognise memory that is going to be shared between threads
[17:03] <durandal_1707> for frame threaded decoding
[17:03] <durandal_1707> other one should be mush simpler, you just need to find out what can be threaded
[17:04] <ubitux> i just don't want to do it :p
[17:04] <ubitux> i'm busy with some other optims in vp9
[17:05] <cone-764> ffmpeg.git 03Paul B Mahol 07master:315e3cf047cf: avcodec/hnm4video: remove redundant log message
[17:06] <durandal_1707> michaelni: ^ that decoder can overread, i'm not motivated to fix such mess
[17:08] <ubitux> durandal_1707: there are 2 similar ones in libavcodec/libfdk-aacdec.c if you're interested :p
[17:08] <ubitux> (av log get buffer)
[17:15] <cone-764> ffmpeg.git 03Paul B Mahol 07master:9521236881cb: avcodec/libfdk-aacdec: remove redundant log messages
[18:07] <zidanne> I am getting error while trying to compile for Android NDK and x86. in apply_window_mp3 : http://pastebin.com/XQFX3AkH
[18:07] <zidanne> Any ideas?
[18:42] <michaelni> zidanne, exact compiler  & compiler flags would be interresting
[18:44] <michaelni> zidanne, also what version of ffmpeg is that ?
[18:44] <zidanne> N-50101-g76415a9
[18:46] <michaelni> 9 month old
[18:46] <zidanne> You are right, I will update and try it again
[19:24] <zidanne> michaelni: I fetched the latest source from git. still the same error. config: http://pastebin.com/yiuXKNr7
[19:29] <wm4> af_aecho.c has a use-after-free problem
[19:30] <wm4> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavfilter/af_aecho.c;h=9c86f8d0ed82c0c4681439c7ad9fe1d0d06a6c50;hb=HEAD#l288
[19:30] <michaelni> zidanne, thats a pretty long configure line, is that all needed for the problem to happen (also which line numbers does it fail at and how with git master) and its likely a compiler bug 
[19:30] <wm4> it's pretty obvious: frame is possibly freed, and then accessed
[19:30] <wm4> durandal_1707: ?
[19:31] <michaelni> zidanne, also --disable-asm might fix it but will make the code slow
[19:31] <zidanne> disabling sse sse2 sse3 fixes the problem. But it's not cool :|
[19:33] <zidanne> configuring with arch x86 may be enough to get this error
[19:35] <ubitux> zidanne: unrelated, but you can --enable-demuxer=mpegts,mpegvideo,mpegps,ogg...
[19:35] <ubitux> same for the others
[19:36] <zidanne> thanks
[19:37] <zidanne> I was using Android-ndk and changing from x86-4.4.3 to x86-4.6 fixed the problem.
[20:03] <durandal_1707> wm4: fixed
[20:07] <cone-764> ffmpeg.git 03Paul B Mahol 07master:d9d752cfb55c: avfilter/af_aecho: free input frame after it is being used
[20:33] <cone-764> ffmpeg.git 03Clément BSsch 07master:f70db22999d7: avformat/image2: allow muxing gif files.
[20:33] <cone-764> ffmpeg.git 03Clément BSsch 07master:3c5e6e76356e: avformat/img2enc: reindent after previous commit.
[20:33] <cone-764> ffmpeg.git 03Clément BSsch 07master:c37b0daf336c: avformat/gif: fix final_delay unit in documentation.
[20:33] <cone-764> ffmpeg.git 03Clément BSsch 07master:3e036d407d18: doc/muxers: document animated GIF muxer.
[20:34] <cone-764> ffmpeg.git 03Clément BSsch 07master:3bcd5c1e31e2: avformat/img2enc: simplify split planes extension selection.
[20:39] <ubitux> durandal_1707: 'going to review displace
[20:39] <ubitux> durandal_1707: patch is the latest version or you have some recent changes in your git?
[20:44] <cone-764> ffmpeg.git 03Michael Niedermayer 07master:3836af476534: avformat/mpegvideodec: check seq headers more completely during probing
[20:49] <durandal_1707> ubitux: yes and no
[20:49] <ubitux> ok
[20:49] <ubitux> pff
[20:49] <ubitux> /home/ubitux/src/ffmpeg/libavfilter/allfilters.c:126: undefined reference to `ff_vf_displace'
[20:50] <ubitux> well i can fix that
[20:52] <cone-764> ffmpeg.git 03Dave Yeo 07master:f9c6044a6f61: Fix compilation with os2threads
[22:11] <saste> how to ban trac users?
[22:12] <llogan> do trac ticket numbers get re-used after deletion?
[22:13] <saste> yes
[22:13] <saste> also who can delete tickets?
[22:13] <llogan> i can now. i deleted those others today
[22:16] <llogan> i don't have any user management tools though. i'm not sure why the spammer's name isn't linked like the rest
[22:16] <ubitux> is ffloger in infinite loop?
[22:16] <ubitux> it's been the third time it's reporting the same trac op
[22:16] <llogan> burek: ping
[22:18] <llogan> saste: i think carl and michael can also delete tickets. im not sure who else can.
[22:23] <cbsrobot> I think iive can too
[22:31] <Compn> what ticket needs to be deleted ?
[22:31] <Compn> im not sure if i have that power :P
[22:31] <llogan> Compn: i deleted them, but there will be more. like herpes.
[22:33] <llogan> Compn: if you view the ticket you may see "Delete" under "Description" on the right (next to reply)
[22:33] <iive> cbsrobot:  i'm not sure I even have an account in the tracker...
[22:34] <cone-764> ffmpeg.git 03Lenny Wang 07master:7c02a77d250f: avfilter/unsharp: added optimized opencl kernels
[22:43] <Compn> i dont see delete, no
[22:57] <wm4> are there any known flv seeking bugs? here it seems to read the whole file until the seek target, instead of executing an avio seek
[23:12] <ubitux> wm4: i've expected a seeking issue with flv a while ago, so it wouldn't surprise me
[23:16] <nevcairiel> flv seeking is practically non functional
[23:38] <cone-764> ffmpeg.git 03Diego Biurrun 07master:cffecc0e7ebd: avfilter/graphparser: Directly free filter memory if initialization fails
[23:38] <cone-764> ffmpeg.git 03Michael Niedermayer 07master:ec8e68c7633c: Merge commit 'cffecc0e7ebd642afaa1fb9f56fab1fcc283293c'
[00:00] --- Fri Nov  8 2013