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

[burek]

[00:07] <compn> what
[00:08] <compn> lou and me review the ml often
[00:11] <compn> as evidenced by there only being 6 spams in the queue right now, that i just cleared :P
[00:11] <compn> lou looks at it more than i do :)
[00:11] <compn> gmx has some of the shittier servers
[00:11] <compn> so its not his fault
[00:12] <compn> michaelni has trouble with gmx too
[00:18] <michaelni> wm4, jamrial posted a patch with the suggested change
[00:20] <wm4> michaelni: yeah, that's exactly what I tried and what worked
[00:46] <cone-125> ffmpeg.git 03Michael Niedermayer 07master:3b4ffba3af96: avcodec/x86/lossless_audiodsp: Make scalarproduct_and_madd_int16 prototypes more similar
[00:46] <cone-125> ffmpeg.git 03Michael Niedermayer 07master:d41b66a1a216: avcodec/vp3: pass correct context to av_log()
[01:47] <jamrial> michaelni: this is not enough. it's still broken on win64 because of xmm6+ being spilled during prologue but then not restored after the jump to the mmxext version
[01:49] <jamrial> try running ./ffmpeg -i [CCCP\]_Mega_Weird_Audio_Test_new.mkv -map:a 0:23 -map 0:0 -vn -sn -f null - on a win64 machine with ssse3 (use -cpuflags -sse4.2 if the cpu supports it, to get around the weird init check)
[01:56] Action: michaelni did not realize there was a sse4.2 function
[01:58] <jamrial> there is none
[01:58] <jamrial> but the check in lossless_audiodsp_init.c is weird and checks for sse4.2 as well
[01:59] <michaelni> that explains why i missed it when testing my patch ...
[02:01] <jamrial> it even checks for 3dnow for whatever reason. no CPU exists with ssse3 and 3dnow...
[02:06] <jamrial> i think the best solution at this point is to duplicate the mmxext code in the ssse3 function
[02:07] <jamrial> or making c wrappers, but that's going to be slower
[02:34] <michaelni> ive implemented C wrapers as that seems alot more robust, also theres another bug in there
[02:40] <michaelni> but if you think doing that in C is a speed problem we/i could look into changing it to asm but ATM i want to fix that crash
[02:44] <cone-125> ffmpeg.git 03Michael Niedermayer 07master:f1214763af1a: avcodec/x86/lossless_audiodsp: Move order&8 fallback into C code
[02:44] <cone-125> ffmpeg.git 03Michael Niedermayer 07master:a6c2c8fe3f07: Revert "avcodec/x86/lossless_audiodsp: Make scalarproduct_and_madd_int16 prototypes more similar"
[02:46] <jamrial> i just wonder about the call overhead using c wrappers
[02:47] <jamrial> a "test order, 8" "jnz .fallback" (where .fallback is a copy of the relevant mmxext code) is probably faster
[03:09] <jamrial> michaelni: is http://pastebin.com/6S5S69EG ok as a simplified version of the tta patch?
[03:12] <michaelni> iam not sure about the EXPLODE change being a good idea, rest LGTM
[03:13] <jamrial> ok, will push without the check for explode
[03:13] <michaelni> do we have a file that has a broken header CRC and otherwise decodes to something useful ? if so it could make sense to accept broken CRCs by default
[03:16] <jamrial> i don't have any. but the header only contains channel amount, bitdepth, duration and samplerate
[03:16] <jamrial> any of those being wrong (except maybe duration) is going to end up with an unplayable file
[03:16] <michaelni> hmm
[03:17] <michaelni> if you prefer the explode check then iam sure not against it
[03:26] <cone-125> ffmpeg.git 03James Almer 07master:15a88468aecd: avformat/tta: only check for header and seek table crc if requested
[04:39] <cone-125> ffmpeg.git 03Michael Niedermayer 07master:69aa79365c1e: avcodec/h264_ps: More completely check the bit depths
[05:14] <jamrial> nevcairiel, Daemon404: any idea why http://fate.ffmpeg.org/log.cgi?time=20150206010917&log=compile&slot=x86_64-msvc12-windows-native is happening?
[05:15] <jamrial> i know it's related to PIC, but no idea why it only affects msvc x64 and not mingw64
[07:53] <Timothy_Gu> michaelni: found something fishy in this merge: 7d82020fcb7f81fcbbd30b7546ba62af45f1a33c
[07:54] <Timothy_Gu> michaelni: is there a reason why flv_data_packet() is not used at all while it is in 21e2dc9fb76bc34fcdedf32e4ce820d6cdf923fb
[08:00] <kurosu> michaelni, regarding the scalar product, I remember discussing with you about that fallback
[08:00] <kurosu> the issue was orders multiple of 8, in particular exactly 8
[08:01] <kurosu> the buffers are padded, so we can just do 16
[08:02] <kurosu> maybe the fallback to mmx is faster, but maybe just rounding the order to the nearest multiple of 8/16 depending on the instruction set is sufficient
[08:20] <kurosu> http://pastebin.com/rLVyA64c <- something like that, generates the same crc on the cccp sample, and passes fate
[08:20] <kurosu> i've modified the mmxext version, but it's really unnecessary
[10:47] <cone-142> ffmpeg.git 03Paul B Mahol 07master:dc3c3758ce63: avformat/thp: check av_get_packet() for failure
[11:11] <ubitux> AVRational av_guess_frame_rate(AVFormatContext *format, AVStream *st, AVFrame *frame)
[11:11] <ubitux> all of these should be const
[11:12] <nevcairiel> ew, more evil uglyness for the broken OpenCL support
[11:16] <durandal_1707> 2 files changed, 3141 insertions(+)
[11:21] <ubitux> lol wtf is that
[11:21] <nevcairiel> clew, just like glew
[11:21] <nevcairiel> :d
[11:22] Action: ubitux doesn't understand
[11:23] <ubitux> here we go, opencl autodetect
[11:23] <ubitux> dammit
[11:25] <nevcairiel> ubitux: i think with this clew thing it doesnt have any link-time deps, so its all runtime-detect
[11:25] <nevcairiel> which is one of its reasons for existing
[11:28] <nevcairiel> but importing this lib into the code base is just wrong ... glew for example is distributed by distributions and could be an external dep, why couldnt clew be like that as well
[11:29] <ubitux> yeah whatever
[12:25] <wm4> man this opencl loader thing is full of nightmares
[12:25] <wm4> a see of ifdefs
[12:25] <wm4> *sea
[12:26] <wm4> and even defining reserved identifiers
[12:26] <wm4> because the guy who wrote it doesn't understand C
[12:42] <michaelni> Timothy_Gu, ive sent a patch to fix that already, see "[FFmpeg-devel] [PATCH 2/2] avformat/flvdec: re enable flv_data_packet() and use AVMEDIA_TYPE_SUBTITLE" but IIRC theres no sample/testcase to test
[12:58] <michaelni> kurosu, http://pastebin.com/rLVyA64c breaks cccp here, tested with  -i \[CCCP\]_Mega_Weird_Audio_Test.mkv -map 0:23 test.wav
[12:58] <michaelni> test.wav is just noise
[13:43] <wm4> ubitux: was my mail addressed to ffmpeg-devel only, or did you remove libav-devel from your reply?
[13:50] <ubitux> wm4: ah mmh i'm sorry, i just "replied" instead of "group reply" on the ffmpeg-devel version, that wasn't on purpose
[13:50] <wm4> ok
[13:50] <ubitux> but now that i think of it, i would have done the same on purpose
[13:50] <ubitux> since i'm talking about ffmpeg internal
[13:50] <wm4> I wasn't sure how this works (I wanted to avoid CCing one because that would be "offensive")
[13:51] <ubitux> and mentioning it's done one way in ffmpeg will probably encourage the other side to do it differently
[13:51] <ubitux> so better not talk about it
[13:51] <wm4> lol
[13:51] <wm4> no I don't want to play this kind of game
[14:03] <wm4> does anyone have the file posted in this ticket? https://trac.ffmpeg.org/ticket/1730
[14:03] <wm4> the user uploaded it on some file hoster which looks dead now
[14:04] <nevcairiel> 2 years is too long for such hosters :p
[14:05] <nevcairiel> sometimes carl puts those files onto the sample ftp when he tests them
[14:05] <wm4> oh it was here https://samples.mplayerhq.hu/ffmpeg-bugs/trac/ticket1730/FFMpeg_Bug_1730_crash_demuxing_m4a.m4a
[14:05] <wm4> yes
[14:05] <ubitux> http://ffmpeg.org/bugreports.html "Furthermore movie files uploaded to services like rapidshare or any other similar service will be ignored. We are not willing to spend our time fighting with this ridiculous, bloated and spam-filled crap."
[14:05] <ubitux> but yeah, people do that :p
[14:05] <wm4> this file doesn't play
[14:05] <wm4> and predictably, crashes Libav
[14:06] <wm4> because Libav doesn't handle this special case
[14:06] <wm4> but seriously, an id3 tag on a mp4 file
[14:22] <JEEBsv> > id3 in mp4
[14:22] <JEEBsv> just kick it out
[14:26] <wm4> you can't
[14:26] <wm4> ffmpeg reads id3v2 for every format
[14:26] <mateo`> wm4: do we know which kind of muxer generate such file ?
[14:27] <wm4> the file contains this: encoder         : iTunes v4.8.0.32, QuickTime 6.5.2
[14:27] <wm4> though whether it added the id3 tag is questionable
[14:27] <wm4> it probably was some shitty tagging tool
[14:28] <mateo`> iTunes v4.[...] is pretty old, maybe they did a sneaky fix at some point :D
[15:36] <cone-888> ffmpeg.git 03Michael Niedermayer 07master:31cc9c04ca38: avcodec/h264: Be more strict on rejecting pps_id changes
[15:36] <cone-888> ffmpeg.git 03Michael Niedermayer 07master:6fafc62b0bd0: avcodec/h264: Be more strict on rejecting pps/sps changes
[17:08] <cone-888> ffmpeg.git 03Paul B Mahol 07master:f968166439e4: avformat/rpl: check av_get_packet() for failure
[17:36] <cone-888> ffmpeg.git 03Pierre Edouard Lepere 07master:a0d1300f7112: x86: hevc_mc: add AVX2 optimizations
[17:50] -:#ffmpeg-devel- [freenode-info] if you're at a conference and other people are having trouble connecting, please mention it to staff: http://freenode.net/faq.shtml#gettinghelp
[17:59] <kurosu> michaelni, ok and weird
[17:59] <kurosu> I'll give it more time tomorrow
[18:09] <cone-888> ffmpeg.git 03Christophe Gisquet 07master:5eedd36df108: x86: hevc_mc: use epel_hv 16-wide function
[18:09] <cone-888> ffmpeg.git 03Mickaël Raulet 07master:bcb092511525: x86/hevc: use CLIPW macro when possible
[18:10] <kurosu> bye
[19:07] <cone-888> ffmpeg.git 03James Almer 07master:aea29a891ff1: x86/hevc_sao: fix loading of RIP address
[19:13] <cone-888> ffmpeg.git 03Timothy Gu 07master:5081012eb88b: audioconvert: Add missing include for FF_API_AUDIO_CONVERT
[19:14] <cone-888> ffmpeg.git 03Timothy Gu 07master:23659fdb812f: generate_wave_table: Add include for AVSampleFormat
[19:14] <cone-888> ffmpeg.git 03Michael Niedermayer 07master:9bc7ee8a9874: avcodec/avfft: Add simple self test
[20:45] <cone-888> ffmpeg.git 03Timothy Gu 07master:e66a18763841: img2dec: Remove dead code
[20:45] <cone-888> ffmpeg.git 03Timothy Gu 07master:510b39c2137b: nutdec: Remove unused variables
[21:31] <cone-888> ffmpeg.git 03James Almer 07master:383fddeec65f: x86/lossless_audiodsp: fix compilation with --disable-yasm
[21:40] <cone-888> ffmpeg.git 03Mickaël Raulet 07master:6ecc3fd61225: x86/hevc_mc: use aligned loads
[22:29] <cone-888> ffmpeg.git 03Michael Niedermayer 07master:a0640e63463e: avutil/opt: Fix types used to access AV_OPT_TYPE_PIXEL_FMT
[22:29] <cone-888> ffmpeg.git 03Michael Niedermayer 07master:1750b45cdf74: avutil/opt: Fix type used to access AV_OPT_TYPE_SAMPLE_FMT
[22:50] <heffer2k02> Hello. I'm trying to write an MP4 file from a sequence of h264 frames. It seems to write everything out correctly, but clearly I'm missing something. The error I get when doing ffmpeg -i file.mp4 is "Could not find codec parameters for stream 0 (Video: h264 (avc1 / 0x31637661), none, 1280x720, 4941 kb/s): unspecified pixel format". Now in my code I have set pix_fmt=AV_PIX_FMT_YUV420P, although I'm in the dark a bit here. Is the
[22:50] <heffer2k02>  complaint coming from failure to read stuff from the h264 stream? Or a misconfiguration in the container?
[22:51] <heffer2k02> aaaand, I see I should be asking this in the other channel.
[22:58] <thardin> .
[22:58] <cone-888> ffmpeg.git 03Carl Eugen Hoyos 07master:d45fadb6df48: lavc/tscc: Make 32bit output opaque.
[22:58] <cone-888> ffmpeg.git 03Michael Niedermayer 07master:bfb988b1fafd: Merge remote-tracking branch 'cehoyos/master'
[00:00] --- Sat Feb  7 2015