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

[burek]

[00:05] <j-b> E-AC3 in wav?
[00:06] <ubitux> e-ac3 in wav in mxf in dcp
[00:06] <ubitux> in a zip
[00:06] <j-b> brrr
[00:08] <j-b> ff_codec_wav_guids, that's a scary table
[00:09] <ubitux> my favorite thing with wav is SMV
[00:09] <JEEBsv> oh, libavformat or codec had something like tha?
[00:10] <JEEBsv> because I might end up writing a demuxer for a format that jus contains captured PCM
[00:10] <ubitux> which can be summarized with:
[00:10] <JEEBsv> and thus it can have PCM, AC3, AAC or whatever
[00:10] <ubitux> > SMV file, a wav file with video appended
[00:12] <kierank> could be spdif
[00:12] <kierank> has no guid
[00:12] <cone-737> ffmpeg.git 03Hendrik Leppkes 07master:23bc1351ad7d: vdpau: restore compatibility with deprecated fields in AVVDPAUContext
[00:21] <cone-737> ffmpeg.git 03Hendrik Leppkes 07release/2.1:70028e917ce8: vdpau: restore compatibility with deprecated fields in AVVDPAUContext
[00:21] <Compn> j-b : because its better than totem/xine nonsense ?
[00:21] <Compn> and its updated ?
[00:22] <j-b> Compn: totem uses Gstreamer, so it gets installed.
[00:22] <j-b> Compn: xine is dead
[00:22] Action: smarter remembers xine
[00:22] <smarter> not very fondly.
[00:44] <cone-737> ffmpeg.git 03Carl Eugen Hoyos 07master:26fc6ffec45c: Cast signed libopenjpeg data values to unsigned before shifting.
[00:44] <cone-737> ffmpeg.git 03Michael Niedermayer 07master:7cd46acdd5f1: Merge remote-tracking branch 'cehoyos/master'
[02:24] <cone-737> ffmpeg.git 03Michael Niedermayer 07master:03fff09b3217: avcodec/wmalosslessdec: Pass on error code from decode_tilehdr()
[02:24] <cone-737> ffmpeg.git 03Michael Niedermayer 07master:ae3856dcaf9c: avcodec/wmalosslessdec: deallocate uninitialized frame on decode_tilehdr() failure
[02:24] <cone-737> ffmpeg.git 03Michael Niedermayer 07master:6b18a6839b43: avcodec/wmalosslessdec: shrink output on error so no uninitialized data is returned
[02:36] <cone-737> ffmpeg.git 03Clément BSsch 07master:b84a7330af41: avformat/pjsdec: dont increase pointer when its already at the end in read_ts()
[03:31] <cone-737> ffmpeg.git 03Martin Storsjö 07master:44a0a98f92c7: arm: Add an option for making sure NEON registers aren't clobbered
[03:31] <cone-737> ffmpeg.git 03Michael Niedermayer 07master:9d5cc55f0fdf: Merge remote-tracking branch 'qatar/master'
[03:35] <BBB> hm
[03:35] <BBB> michaelni: ping
[03:35] <michaelni> BBB, pong
[03:36] <BBB> how do AVParsers signal errors?
[03:36] <BBB> I'm currently returning AVERROR_INVALIDDATA but that infloops
[03:36] <BBB> (parser.c comments seem to indicate negative return values aren't errors)
[03:38] <BBB> just return size?
[03:39] <michaelni> i think theres  no way to return an error currently
[03:39] <BBB> I think I fixed the last open vp9 bug in trac, feel free to review or wait for ubitux to do so
[03:40] <michaelni> the idea probably was that parsers should split anything the best they can
[03:40] <michaelni> but that misses malloc errors
[03:42] <michaelni> so with current API thats returning size / 0 or something like that
[03:46] <michaelni> an error_code field could be added to AVCodecParserContext if someone would want to export erors while keeping best effort spliting or a av_parser_parse3() ...
[03:47] <BBB> nah returning size is ok
[04:43] <cone-737> ffmpeg.git 03Michael Niedermayer 07master:e11983bda073: avcodec/alac: only set *got_frame_ptr when all channels have been decoded
[12:19] <ubitux> BBB: isn't the valgrind stack thing in vp9 simply because you move the stack pointer assuming the data on it won't be change (and thus confuse valgrind alot©)?
[12:19] <ubitux> would it be possible to use another reg as pointer to avoid the issue?
[12:53] <BBB> if we confuse valgrind, we should fix valgrind
[12:54] <BBB> my basic assumption has always been that if tools are broken, we should either fix them, or not use them
[12:54] <BBB> (I've reported bugs like this in valgrind or asan [forgot which one] before, and they did get fixed
[12:55] <Compn> might already be fixed in valgrind git? :P
[12:55] <Compn> ehe
[12:56] <ubitux> BBB: i'm doing some stuff on itxfm
[12:56] <ubitux> i hope you aren't ;)
[12:56] <ubitux> i saved one mov
[12:56] <ubitux> and i might be able to save more
[13:00] <wm4> save the movs
[13:04] <BBB> I'm doing iadst16
[13:08] <ubitux> BBB: can you have a look to https://github.com/ubitux/FFmpeg/compare/vp9-itxfm ?
[13:09] Action: ubitux goes back to lpf
[13:27] <BBB> but this doesn't affect the binary right?
[13:27] <BBB> x86inc.asm actually knows that a three-register instruction avx-syle instr a, b, c where a==b is the same as a two-register sse-style instruction instr a, c
[13:28] <BBB> so I don't think this saves a mova
[13:28] <BBB> I do like the changes, so please do commit
[13:29] <BBB> oh I guess binary isn't the same because you deinterleaved the punpack/mulsub pairs
[13:32] <ubitux> ah, x86inc deals with that case? too bad :p
[13:32] <ubitux> indeed the binary changed because of the following change
[13:32] <ubitux> do you think i should benchmark just in case?
[13:34] <BBB> probably always a good idea, yes, but I think it's an ok change
[13:35] <BBB> how's lpf going? is the 16x16b transpose done already? :-p
[13:35] <ubitux> i'm on it :p
[13:36] <BBB> \o\ /o/ \o/
[13:36] <BBB> (I'm pretty sure big transposes suck)
[13:36] <ubitux> i'm trying to figure out what reg should be saved in a stashing area
[13:36] <ubitux> dunno, currently it's like this: http://pastie.org/8623522
[13:37] <ubitux> (but doesn't work because of the saves)
[13:39] <BBB> can you also review "vp9: fix mt-related hang a parser infinite loop."?
[13:40] <BBB> ubitux: look at how transpose8x8w works on x86-32, and try to reproduce these save patterns
[13:40] <BBB> (i.e. you'll need 2 stack locations and shift between the two)
[13:41] <BBB> but I fully acknowledge it sucks :-p
[13:41] <ubitux> the mt hang patch should be ok, but strangely after your previous patch i wasn't able to trigger that hang
[13:41] <BBB> hm
[13:41] <BBB> it still hung for me
[13:41] <BBB> odd
[13:41] <ubitux> probably 10 lucky hit in a row
[13:41] <ubitux> :p
[13:42] <ubitux> yes i'm trying to copy the save patterns
[14:19] <BBB> error_res related, does anyone have opinions on adding a "corrupted" bit to AVFrame (or flag, or whatever) for these codecs not (yet) implementing ER, so that we can mark them as corrupt reference for future frames to resolve the difference in reconstruction of corrupt frames w/ and w/o frame-mt?
[14:20] <BBB> the idea basically being that currently, most codecs will discard the reference as invalid and refuse to decode subsequent frames (or blocks) using that as a reference in single-thread mode, but will happily set progress to int-max in multithread mode (such as to not cause hangs), thus using a corrupt reference
[14:20] <BBB> having a corrupt bit in the reference frame (possibly as part of ThreadFrame) would resolve this difference between frame-mt and no-mt behaviour for such codecs
[14:54] <saste> #ffmpeg-meeting channel created
[14:55] <BBB> maybe I''ll idle in there so I can peek in
[14:55] <BBB> when does it start?
[14:57] <BBB> ah, 11 est
[15:25] <beastd> hi
[15:31] <beastd> saste: Where is the meeting?
[15:33] <ubitux> beastd: #ffmpeg-meeting
[15:41] <kurosu_> ubitux: does having 50+ commits in ffmpeg qualify for joining? I don't plan to actually participate, just taking this opportunity to see what's happening
[15:41] <ubitux> it's public
[15:43] <kurosu_> ok
[16:08] <saste> kurosu_, it's public, you can join if you like, and the log will be published on ffmpeg-devel
[16:09] <Compn> everyone is of course welcome, especially with new ideas :)
[16:09] <Compn> Daemon404 and wm4 usually join to troll as well 
[16:09] <Compn> constructive trolling that is
[16:10] <wm4> in fact you are the troll
[16:10] <Compn> shh dont tell everyone :P
[16:17] <Cigaes> Hi.
[16:18] <saste> Cigaes, hi
[16:39] <nevcairiel> BBB: there already is a corrupt flag which is set for frames which are not yet fully re-constructed due to missing refs (in h264 at least), dont suppose you can use that? its primary meaning is to inform user code right now though..
[16:59] <saste> the ffmpeg IRC meeting is going to start soon, please join #ffmpeg-meeting if you want to participate
[17:00] <j-b> saste: is it open to everyone?
[17:00] <saste> j-b, yes
[17:00] <saste> log is going to be published on ffmpeg-devel if you can't attend, you're welcome to join
[17:36] <smarter> what's the purpose of writing "ALIGN 16" before a block of code in yasm?
[17:36] <smarter> Like in http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/x86/h264_deblock.asm;h=1317783bec63b8b04d6a5e8f567b8cfd764ed1bb;hb=HEAD#l852
[17:38] <nevcairiel> i suppose aligning code to start on a certain byte boundary is advantageous, don't ask me why :)
[18:02] <kierank> smarter: it's semi cargo-cult iirc
[18:02] <kierank> but basically based on benchmarking and see if it change
[18:02] <kierank> changes*
[18:05] <smarter> why would it change? :)
[18:05] <smarter> better use of cachelines?
[18:07] <kierank> instruction alignment
[18:08] <smarter> is that something pengvado would know more about? :)
[18:13] <smarter> oh cool, there's a section in http://www.agner.org/optimize/optimizing_assembly.pdf on code alignment
[18:15] <kierank> are there any ffmpeg people at fosdem?
[18:42] <BBB> nevcairiel: if we agree that's a proper use for it, sure
[20:38] <cone-780> ffmpeg.git 03Michael Niedermayer 07master:d5af40071395: avcodec/alac: warn if not all channels where decoded
[20:38] <cone-780> ffmpeg.git 03Michael Niedermayer 07master:0999f1613bc4: avcodec/hevc: use av_mallocz() for allocating tab_ipm
[20:38] <cone-780> ffmpeg.git 03Luca Barbato 07master:5856bca360c5: hevc: Clip the pixel before shifting
[21:17] <cone-780> ffmpeg.git 03Benjamin Larsson 07master:547f83453738: flv: Workaround for buggy Omnia A/XE encoder
[21:17] <cone-780> ffmpeg.git 03Michael Niedermayer 07master:419787a2ffe3: Merge remote-tracking branch 'qatar/master'
[21:18] <michaelni> j-b, "remote: mail: /tmp/mail.RsXXXX0vyWgz: No space left on device" on my last git push
[21:19] <michaelni> i think the push itself was fine though
[21:53] <cone-780> ffmpeg.git 03Michael Niedermayer 07master:859d74040e4b: avcodec/mjpegenc: pass chroma quantization matrix through as well, not just luma
[21:53] <cone-780> ffmpeg.git 03Michael Niedermayer 07master:b8ff951ce03f: avcodec/mpegvideo_enc: init chroma matrix for mjpeg
[21:53] <cone-780> ffmpeg.git 03Michael Niedermayer 07master:7dc0aba3fb9d: avcodec/mjpegenc: use a seperate chroma matrix when luma and chroma differ
[22:26] <smarter> michaelni: 5856bca360c5 is not the proper way to fix that, I'll be sending a proper patch to libav-devel soon
[22:33] <michaelni> smarter, can you also send it to ffmpeg-dev ?
[22:33] <michaelni> after all the "non proper" one is already i ffmpeg
[22:33] <michaelni> iN
[22:34] <michaelni> BBB, ubitux should i apply " vp9: fix mt-related hang a parser infinite loop." or should i wait for some review ?
[22:34] <ubitux> it's fine with me
[22:34] <michaelni> ok
[22:36] <cone-780> ffmpeg.git 03Ronald S. Bultje 07master:0065d2d520ca: vp9: fix mt-related hang a parser infinite loop.
[22:39] <cbsrobot> what are the prores issues discussed in the meeting ?
[22:41] <michaelni> cbsrobot,see http://support.apple.com/kb/HT5959?viewlocale=en_US
[22:56] <kierank> michaelni: it's a FUD campaign against broadcasters
[22:56] <kierank> and it's working because they are scared
[22:56] <JEEB> yeah, clear FUD
[22:57] <JEEB> and there's also no way they'd 'authorize' libavcodec
[22:57] <kierank> I'd be curious to see if they reply
[22:57] <BBB> their point is somewhat valid
[22:57] <kierank> and if they attack ffmpeg I'll just say the reality of the situation is the decoder is used heavily and you have to offer a licensing programme
[22:57] <BBB> prores is a 12bit format
[22:58] <BBB> ffmpeg's c decodes 10bits
[22:58] <BBB> ffmpeg's assembly is worse
[22:58] <kierank> is prores natively 10-bit or is only one profile 10-bit?
[22:58] <BBB> prores is 12bit
[22:58] <BBB> prores is not 10bit
[22:58] <kierank> BBB: I know for a fact the *biggest* media organisations in the world deliver using proresenc/dec
[22:58] <kierank> FUD FUD FUD
[22:59] <BBB> ?
[22:59] <nevcairiel> last i heard prores 422 is 10-bit, only 4444 allows 12-bit
[22:59] <JEEB> ^
[22:59] <kierank> BBB: broadcasters are running scared
[22:59] <BBB> check our prores decoder
[22:59] <kierank> because apple are saying lavc is unauthorised
[22:59] <BBB> it decodes 12bit coefficients
[22:59] <nevcairiel> (and yes, 4444 is not fully supported by avcodec)
[22:59] <BBB> then scales them back 2bit
[22:59] <BBB> then does a 10bit idct
[23:00] <BBB> except the assembly, which is (in ffmpeg at least) 8bit
[23:00] <BBB> I wrote a 10bit version which michael then changed back tot he 8bit version
[23:00] <michaelni> huh
[23:00] <BBB> I know the format surprisingly well for someone that knows nothing about video codec design or stuff like that
[23:01] <kierank> 10:00 PM <"BBB> I know the format surprisingly well for someone that knows nothing about video codec design or stuff like that ???
[23:02] <nevcairiel> have a white paper; http://www.apple.com/final-cut-pro/docs/Apple_ProRes_White_Paper_December_2013.pdf ..it confirms that only 4444 is 12-bit, and 422 profiles are 10-bit
[23:03] <michaelni> BBB, where is that code that drops 2 bits ?
[23:03] <Timothy_Gu> Is Kostya still working on 4444?
[23:05] <ubitux> Timothy_Gu: ask him (Keiler)
[23:06] <Timothy_Gu> BTW I couldn't attend the meeting because I had a writing lesson and another lacrosse one back-to-back
[23:23] <Compn> i know what apples problem with avcodec is
[23:26] <Compn> its because apple doesnt have the rights to elvis! * Copyright (c) 2010-2011 Elvis Presley
[23:26] <Compn> :)
[00:00] --- Sun Jan 12 2014