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

[burek]

[00:32] <cone-628> ffmpeg.git 03Michael Niedermayer 07master:3b57bb478ff4: svq1dec: check that the reference frame matches in size before using it.
[00:32] <cone-628> ffmpeg.git 03Michael Niedermayer 07master:953061ed9537: lavf/utils: more complete dts checks
[01:08] <cone-628> ffmpeg.git 03Carl Eugen Hoyos 07master:b23aff6755ff: Add forgotten AVC Intra entry to Changelog.
[02:59] <cone-628> ffmpeg.git 03Michael Niedermayer 07master:4c80184cf542: mjpegdec: allow 2 components in ljpeg_decode_yuv_scan()
[02:59] <cone-628> ffmpeg.git 03Michael Niedermayer 07master:1a088f61e1b8: oggparseskeleton: Check the overall start time before using it.
[03:06] <mfg> Hi. I (re)submitted a patch for HLS and HTTP cookies a few days back. I figured before I sent another message to the list I'd check in here to see if anyone had plans to look at it.
[03:13] <michaelni> mfg, i can take a look if ubitux /saste dont
[03:14] <michaelni> ubitux, ?
[03:25] <mfg> I'm good with anyone 
[03:25] <mfg> michaelni TIA, I'll watch for a reply
[05:13] <Compn> can we remove "Project Description" header from ffmpeg main www ?
[05:13] <Compn> not the description
[05:13] <Compn> just the words "Project Description"
[05:22] <llogan> Compn: fine with me.
[05:28] <Compn> k done :)
[12:29] <pross-au> LS
[12:38] <cone-931> ffmpeg.git 03Diego Biurrun 07master:e817d9139ff6: asfdec: Fix printf format string length modifier
[12:38] <cone-931> ffmpeg.git 03Benjamin Larsson 07master:bbae68596e78: xwma: Remove unused variable
[12:38] <cone-931> ffmpeg.git 03Derek Buitenhuis 07master:9a00374cb451: doc: Fix a few typos in the developer documentation
[12:38] <cone-931> ffmpeg.git 03Michael Niedermayer 07master:3bca69c2a8e7: Merge commit '9a00374cb4512a58a1fee366b850dfa87c76e1f3'
[12:46] <cone-931> ffmpeg.git 03Derek Buitenhuis 07master:b5f9b9ac3681: doc: Merge disjointed bits about emailing patches
[12:46] <cone-931> ffmpeg.git 03Michael Niedermayer 07master:adc7296aa5b2: Merge commit 'b5f9b9ac3681acb06d95530f34660ba9fe225305'
[12:47] <cone-931> ffmpeg.git 03Derek Buitenhuis 07master:dc3e12d1cb65: doc: Mention zzuf in the fuzz testing section
[12:47] <cone-931> ffmpeg.git 03Michael Niedermayer 07master:32cf37d097db: Merge commit 'dc3e12d1cb65d74fb120197ce869a205718b6715'
[13:02] <cone-931> ffmpeg.git 03Derek Buitenhuis 07master:6042a12174e5: doc: Extend commit message section
[13:02] <cone-931> ffmpeg.git 03Derek Buitenhuis 07master:ac2603be2860: doc: Mention memory allocation in the fuzz testing section
[13:02] <cone-931> ffmpeg.git 03Justin Ruggles 07master:4d68269d58ca: lavr: typedef internal structs in internal.h
[13:02] <cone-931> ffmpeg.git 03Justin Ruggles 07master:074a00d192c0: lavr: add a public function for setting a custom channel map
[13:03] <cone-931> ffmpeg.git 03Michael Niedermayer 07master:3a0bac27b3c8: Merge commit 'ac2603be28602bea76cf38bdbf37aead0dc2979a'
[13:03] <cone-931> ffmpeg.git 03Michael Niedermayer 07master:249fca3df9f9: Merge commit '074a00d192c0e749d677b008b337da42597e780f'
[13:14] <cone-931> ffmpeg.git 03Justin Ruggles 07master:1ccf82cfd85c: lavr: cosmetics: reindent
[13:14] <cone-931> ffmpeg.git 03Justin Ruggles 07master:4164b0e8d38b: lavr: mix: reduce the mixing matrix when possible
[13:14] <cone-931> ffmpeg.git 03Justin Ruggles 07master:7ff3fd7ae4d6: lavr: log channel conversion description for any-to-any functions
[13:14] <cone-931> ffmpeg.git 03Martin Storsjö 07master:8729698d5073: rtsp: Recheck the reordering queue if getting a new packet
[13:14] <cone-931> ffmpeg.git 03Michael Niedermayer 07master:48d30f673336: Merge commit '8729698d50739524665090e083d1bfdf28235724'
[13:19] <ubitux> michaelni: i don't really know what to say about the hls thing :(
[13:27] <cone-931> ffmpeg.git 03Martin Storsjö 07master:f811cd2d47ad: rtsp: Respect max_delay for the reordering queue when using custom IO
[13:27] <cone-931> ffmpeg.git 03Michael Niedermayer 07master:315f15afe743: Merge remote-tracking branch 'qatar/master'
[13:40] <cone-931> ffmpeg.git 03Nicolas George 07master:ff6b34009d45: lavfi: fix use-after-free in ff_filter_frame.
[13:45] <Compn> wbs may know HLS cookie stuff. or ask whoever wrote hls code :P
[13:46] Action: funman wrote some hls code
[13:51] <saste> ubitux: which patch?
[13:54] <Compn> [21:10] <mfg> Hi. I (re)submitted a patch for HLS and HTTP cookies a few days back. I figured before I sent another message to the list I'd check in here to see if anyone had plans to look at it.
[13:55] <Compn> saste / funman : if either of you want to review it ^
[13:55] <Compn> :)
[13:56] <funman> Compn: is it on the list?
[13:56] <ubitux> it's mostly related to how the options system work
[13:56] <ubitux> and how to populate them between the different layers
[13:56] <ubitux> iirc
[13:56] <wm4> which big endian archs does ffmpeg support, and which of them are considered important?
[13:56] <funman> PPC/ARM ?
[13:57] <wm4> funman: AFIAK little endian is rather standard on ARM, and ppc is almost dead
[13:57] <funman> iirc xscale was 'the' ARN big endian
[13:57] <wm4> ok
[13:57] <funman> i guess it's pretty dead as well
[14:00] <Compn> funman : i think the old patch was . lets see
[14:00] <funman> [FFmpeg-devel] [PATCH] Maintain HTTP options across multiple requests in HLS demuxer   Micah Galizia
[14:00] <funman> ?
[14:01] <Compn> http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2013-January/137034.html
[14:01] <Compn> yeah
[14:01] <Compn> a 3 day ping :P
[14:01] <Compn> impatient patch authors :)
[14:02] <wm4> some documentation in what format the cookies are would be nice
[14:02] <Compn> wm4 : planning to remove BE support ?
[14:02] <wm4> Compn: ?
[14:02] <funman> uff it's out of my game
[14:03] <Compn> no problem 
[14:03] <wm4> Compn: decoders still could produce BE output, especially the raw decoder
[14:03] <funman> i know almost nothing about http
[14:03] <Compn> funman : any chance you would be interested in reviewing dxva patch ?
[14:03] <funman> sure
[14:03] <Compn> http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2013-January/136964.html
[14:03] <funman> especially now that i am into Windows mode thanks to VLC on Windows Metro^W8^WRT^Wsomething project
[14:03] <Compn> its only 50k patch...
[14:04] <Compn> oo nice 
[14:04] <Compn> that developer wants to send in opencl video filter patches too
[14:04] <funman> hum,. chinese author, no description of patch.. my favorite!
[14:04] <JEEB> sounds like win
[14:04] <Compn> there is previous discussion of it , last month archive i think
[14:05] <Compn> i can dig url if you like
[14:05] <funman> seems he is doing the same thing but without the hwaccel API
[14:05] <Compn> this thread : http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2012-December/136337.html
[14:05] <Compn> his first patch used hwaccel , and someone said they didnt like it
[14:05] <wm4> this patch still doesn't honor VLC copyright
[14:06] <Compn> the new one ? lol
[14:06] <durandal_1707> lol, what. it should use hwaccel
[14:06] <Compn> so he went with a wrapper decoder that could be reused...
[14:06] <wm4> anyway, this patch is pretty much similar to h264_vda, which has been declared a mistake in #ffmpeg-devel
[14:06] <wm4> as it was more or less a hack for mplayer
[14:06] <durandal_1707> what?
[14:06] <wm4> durandal_1707: mplayer didn't want to use hwaccel properly
[14:06] <funman> oh and mail replies are not quoted so you can't see who's talking..
[14:07] <Compn> wm4 : thats why i want to get vlc involved with fixing whatever the problem is...
[14:07] <funman> Compn: nice present :)
[14:07] <Compn> funman : you know you love it.
[14:07] <wm4> Compn: what does VLC have to do with this
[14:07] <Compn> wm4 : because vlc can use ffmpeg hwaccel, if they get thier act together instead of reinventing wheel 9000 times
[14:07] Action: durandal_1707 as usual only nonsense on channel
[14:07] <wm4> Compn: but they do
[14:07] <durandal_1707> nothing use hwaccel because it is crap
[14:07] <wm4> Compn: the patch actually copies the VLC DXVA code
[14:08] <Compn> wm4 : well how would you put dxva support for ffmpeg (itself) ?
[14:08] <wm4> Compn: it's notable that VLC copies data back from GPU memory, because apparently they were too stupid for proper native DXVA support
[14:08] <funman> hum so the point is you can't use dxva2 from ./ffmpeg?
[14:08] <Compn> funman : yes
[14:08] <funman> wm4: patch welcome!
[14:08] <wm4> Compn: uh, ffmpeg as library already supports DXVA, obviously
[14:08] <Compn> wm4 : you are my favorite troll :)
[14:08] <durandal_1707> and exactly that is pita
[14:08] <Compn> not talking about library...
[14:08] <wm4> Compn: all that the patch does is adding DXVA to the transcoding tool
[14:09] <Compn> ffmpeg -i blah -c dxva
[14:09] <Compn> yes
[14:09] <wm4> which is questionable at best
[14:09] <Compn> lol
[14:09] <wm4> because it makes no fucking sense
[14:09] <Compn> to you maybe
[14:09] <funman> wm4: http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2012-December/136437.html
[14:09] <funman> he lists what is faster than SW decoder with his approach
[14:09] <Compn> mplayer could use some dxva too :)
[14:09] <Compn> benchmarks :)
[14:10] <nevcairiel> mplayer could use deletion
[14:10] <nevcairiel> maybe all these "but mplayer" arguments would finally stop then
[14:10] <funman> =)
[14:11] <funman> but vlc
[14:11] <wm4> meanwhile at mplayer... http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2013-January/071286.html
[14:12] <durandal_1707> frame drop?
[14:14] <funman> Compn: i remember asking nefrir why he didn't wrote everything in libavcodec
[14:15] <wm4> looking at the dxva patch further, it actually does attribute VLC, but only the header file:
[14:15] <wm4> + * Attribute from VLC
[14:15] <Compn> what did he say ?
[14:15] <funman> i don't remember his answer though... maybe to not bother with code quality requirements higher than VLC's ?
[14:15] <nevcairiel> i complained on the mailing list that he copypasted the code without even mentioning vlc
[14:16] <Compn> yes, he needs some help in adding the attribution
[14:16] <wm4> well he added it to dxva2_wrapper.h only
[14:16] <Compn> this is how its done in china...
[14:16] <Compn> its hard to change customs :)
[14:16] <funman> ^_^
[14:16] <Compn> be happy that hes contributing and trying to learn, huh guys ?
[14:16] <Compn> new developer ? adding features ?
[14:17] <durandal_1707> more like copy paste monkey
[14:17] <wm4> patch and run
[14:17] <Compn> i know its hard to welcome new contributors
[14:18] <Compn> hes not running, hes asking for help. hes mailed me a few times. would be nice if a real programmer would step up to help shape his patch into ffmpeg quality
[14:18] <nevcairiel> at least he gave up his hacking of pthread.c for some obscure reason
[14:18] <wm4> nevcairiel: lol
[14:18] <wm4> so he stopped patching pthread.c and it still works for him?
[14:18] <nevcairiel> no idea what he wanted to do
[14:19] <durandal_1707> ask him
[14:19] <nevcairiel> i dont care, it was wrong
[14:19] <durandal_1707> it is better to not commit something that only 1 "tested"
[14:19] <wm4> durandal_1707: isn't that standard practice with ffmpeg commits?
[14:19] <Compn> durandal_1707 : what about put it in a branch until some windows devs can test ?
[14:20] <Compn> its not better to let patches rot 
[14:20] <durandal_1707> wm4: not really for new features and bug fixes, i dunno about what are you thinking...
[14:22] <durandal_1707> Compn: i think all hw stuff with hwaccel should be removed from tree
[14:22] <funman> that's what i was going to suggest.. if it's replaced by a standalone decoder then the hwaccel should go
[14:22] <nevcairiel> no it shouldnt
[14:22] <nevcairiel> the standalone "decoder" is just a wrapper around the hwaccel
[14:22] <nevcairiel> it internally instantiates a new decoder
[14:22] <funman> ah
[14:23] <nevcairiel> besides, it doesnt let you access the d3d surface like hte hwaccel does
[14:24] <Compn> durandal_1707 : what do you propose for supporting dxva from ffmpeg tool, then ?
[14:25] <Compn> durandal_1707 : i'm not saying you are right/wrong. i just dont know how it should be done ?
[14:26] <nevcairiel> hwaccels arent really useful for transcoding, so my answer would be "it shouldn't support it" :p
[14:26] <Compn> yes, i'm getting that general vibe from some people today :)
[14:28] <funman> it seems a lot of work for not much
[14:28] <durandal_1707> Compn: tell them to fork and do all that stuff in own fork
[14:29] <Compn> ok two rejections
[14:29] <Compn> what about you funman ?
[14:30] <wm4> nevcairiel: btw. how fast is hw decoding with copy back?
[14:30] <funman> Compn: if it was made to simplify players why not
[14:30] <nevcairiel> not slower then native decoding, just with a bit more cpu usage
[14:30] <wm4> easier hw decoding for video players and such might still be a valid argument
[14:30] <funman> nefrir: did you notice http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2013-January/136964.html about dxva2 ?
[14:30] <nevcairiel> if done right, you dont block the gpu from working, you just copy he previous frame while its decoding the next one
[14:31] <funman> +#ifndef false
[14:31] <funman> +#define false FALSE
[14:31] <funman> :(
[14:31] <nevcairiel> ps: the fate test would also blow up, just because i can compile it doesnt mean i have a capable gpu
[14:31] <nevcairiel> my win32 fate box for example is a headless server with some server gpu, definitely no dxva :P
[14:31] <funman> mingw-w64 headers use false without a typedef or define apparently
[14:32] <cone-931> ffmpeg.git 03Michael Niedermayer 07master:86159703f571: ff_find_pix_fmt: return NONE for the "not found" case.
[14:33] <nevcairiel> doesnt C99 have true/false now?
[14:33] <wm4> if you include stdbool.h
[14:33] <nevcairiel> oh
[14:45] <Compn> argh saste is gone
[14:49] <Compn> wm4 : re: "patch and run" , highgod (patch author) has come in here a few times even
[14:49] <Compn> irc that is
[14:50] <Compn> nevcairiel : if ffmpeg project deems it does not want dxva support for ffmpeg tool, thats fine too. i dont make those decisions :)
[14:51] <Compn> funman : do w8 phones have dxva in them ?
[14:51] <Compn> or winrt or whatever its called now
[14:51] <funman> Compn: no idea
[14:51] <funman> and no idea how it's called either
[14:52] <Compn> lol
[14:52] <funman> the only windows HW i have is laptops
[14:52] <Compn> ah
[14:52] <Compn> someone should call/mail microsoft, maybe they'd ship a few phones to vlc devs
[14:52] <Compn> maybe i'll try it
[14:52] <funman> done already ^_^
[14:52] <Compn> oh :P
[14:52] <Compn> you guys are fast :)
[14:52] <j-b> the mail
[14:52] <funman> j-b: certainly is fast !
[14:52] <j-b> so far, I don't think WinRT has DxVA available
[14:53] <wm4> MF only or so?
[14:53] <Compn> its using something else for h264 decoding then
[14:53] <Compn> mediafoundation
[14:53] <funman> MFers
[14:53] <Compn> mf'ing mf
[14:53] <funman> =)
[14:53] <j-b> wm4: yes
[14:54] <wm4> so a whole new chunk of highly windows specific code, yay
[14:54] <j-b> yep
[14:54] <nevcairiel> WinRT sure has DXVA available, you just need to use it through a MF transform
[14:55] <j-b> which another way of saying it :)
[14:55] <Compn> wrapper wrapper whos got the wrapper, which can be disabled at any point in the future
[14:56] <Compn> at least microsoft is ensuring that programmers have jobs for the next few years, api changes are a foot 
[14:56] <j-b> and yet, DxVA was supposed to be COM
[14:56] <j-b> and thus be avialable on WINrt
[14:57] <nevcairiel> the list of things you can access through COM is limited on WinRT, there is a list somewhere which classes you can access
[14:57] <Compn> j-b : what do you think about the patch to allow ffmpeg tool to use dxva accel ?
[14:57] <Compn> (some copy pasted from vlc code)
[14:58] <j-b> seems a lot of duplications, tbh
[14:58] <wm4> also, why let MS restrict you? https://surfsec.wordpress.com/2013/01/06/circumventing-windows-rts-code-integrity-mechanism/
[14:58] <j-b> won't solve the issue on all devices
[14:59] <wm4> j-b: as I understand, VLC could use it effortlessly and delete its own code?
[14:59] <Compn> if the code is merged from vlc, it could be moved to ffmpeg and removed from vlc
[14:59] <wm4> or does VLC do more, like having a mode that doesn't read back from GPU memory into system RAM?
[14:59] <nevcairiel> actually, the list of COM interfaces includes the D3D11 interfaces, so maybe you could do it without MF, just need to change the D3D9 code usually used for DXVA to D3D11
[14:59] <Compn> merged properly. no idea if the patch does this ...
[15:01] <funman> wm4: vlc always reads back the picture
[15:01] <wm4> then I don't see why this code couldn't be in ffmpeg
[15:02] <wm4> it would go in hand with h264_vda
[15:02] <funman> in case filters need to be applied (a shortcut from gpu to output would be nice but nobody did it)
[15:02] <wm4> even though this one gets hate because it was created for mplayer originally
[15:02] <wm4> (actually, mplayer rejected a first vda patch, which used the "proper" ffmpeg API - you can thank reimar)
[15:02] <Compn> wm4 : thats the point, trying to get mplayer , vlc and other projects to stop reinventing wheels and put it in ffmpeg :P
[15:03] <funman> in this case it's just 'inventing' :P
[15:03] <Compn> and ffmpeg devs dont want this 'trash' ...
[15:03] <j-b> tbh, I don't see why those hwcallel things are entangled in libavcodec, and not in a split library
[15:03] <wm4> though VDA is "special", because apparently you can't use VDA without copy back
[15:03] <nevcairiel> j-b: because they need the bitstreaming parsing
[15:03] <Compn> funman : well if each project has to do similar code for the api , what do you call that ?
[15:03] <wm4> j-b: because the decoding interface is extremely similar
[15:03] <nevcairiel> all thats offloaded is the actual slice decoding
[15:04] <nevcairiel> bitstream parsing, reordering and everything this, is done by avcodec
[15:04] <Compn> j-b : probably sps crap has to be parsed
[15:04] <Compn> bitstream parsing, yeah
[15:04] <j-b> Compn: that is not that much code, tbh
[15:04] <j-b> but maybe I am wrong
[15:04] <nevcairiel> for h264 that is quite a bunch of logic
[15:04] <nevcairiel> the whole reordering and stuff...
[15:04] <funman> i'm trying to find nefrir justification for not putting that code in ffmpeg in the first place but i keep being distracted
[15:04] <funman> 08:59 < funman> "rms nude" About 99,700 results
[15:04] <Compn> i think he means the code thats in vlc 
[15:05] <Compn> lol
[15:05] <Compn> funman
[15:05] <Compn> why did you put that image in my head ?
[15:05] <funman> ^_^
[15:05] <funman> http://wiki.videolan.org/SoC_2009/DXVA_integration
[15:06] <funman> Geal did initial dxva2 work with fenrir's help for GSOC
[15:06] <j-b> yep
[15:06] <funman> so maybe putting the code in VLC was just to justify GSOC
[15:06] <j-b> no
[15:07] <j-b> Fenrir said that he wanted to have D3D output integration and he is pissed about FFMpeg integration patch policy
[15:07] <funman> the 2nd part is understandable, but for the 1st part?
[15:07] <funman> there's no integration after 3 years afaik
[15:07] <j-b> there was a patch IIRC
[15:08] <Compn> well, ffmpeg patch policy has changed, it should be resubmitted :)
[15:08] <Compn> not really changed, but unwritten rules are now gone
[15:08] <Compn> :D
[15:09] <nevcairiel> that reminded me again to submit my dxva patch for snb/ivy intels
[15:09] <michaelni> nevcairiel, btw, about fate tests & hw stuff, that can be disabled by default and only enabled manually so it would never run on systems not capable of it unless explicitly enabled
[15:09] <Compn> yes, you said you might review the patch after newyears too
[15:09] <nevcairiel> i am a busy person
[15:10] <Compn> michaelni : yes, that needs to be addressed in the patch :)
[15:10] <funman> I wonder if integration in FFmpeg can help VLC to use different picture formats depending on the GPU (VIA ...)
[15:10] <nevcairiel> people still have such weird gpus?
[15:11] <Compn> funman : you mean , select fastest colorspace ?
[15:11] <funman> Compn: yes
[15:11] <funman> we received complaint and hardware from VIA
[15:11] <wm4> what's different about VIA?
[15:11] <Compn> would we have to make a list of supported and fastest colorspaces for each bitdepth ?
[15:11] <nevcairiel> tell them to support nv12 or gtfo?
[15:12] <Compn> on each card, from each manf ?
[15:12] <funman> nevcairiel: j-b will remember better than me
[15:12] <Compn> i'm not sayin is bad idea ...
[15:12] <funman> but basically yes they should have fixed this in their driver
[15:12] <Compn> just curious how to do it
[15:12] <Compn> lol
[15:12] <nevcairiel> hardware decoders generally only support 4:2:0 8-bit decoding, and any sane hardware decodes to nv12
[15:12] <wm4> and VIA uses...?
[15:12] <Compn> funman : mplayer did that for various cards. writing direct hardware access video outputs .
[15:13] <Compn> back in 2001 :P
[15:13] <Compn> 3dfx! matrox!
[15:13] <j-b> VIA D3D output does not support YV12 output
[15:13] <wm4> but? packed YUV? or what?
[15:13] <Compn> hows VIA opengl support ?
[15:13] <j-b> Intel, nVidia, AMD, Matrox and S3 do.
[15:14] <j-b> wm4: NV12 and RGB only in D3D surfaces, IIRC
[15:14] <nevcairiel> NV12 is fine, its the preferred format for hardware decoders anyway
[15:14] <funman> and intel/via/amd/matrox/s3 do not support NV12?
[15:14] <nevcairiel> intel nvidia and amd do
[15:14] <j-b> they do
[15:15] <wm4> the question here is what VIA requires instead
[15:15] <wm4> this still hasn't been answered
[15:15] <j-b> must most VLC+FLOSS-codecs-lib pipeline/filters use I420 mostly
[15:15] <wm4> uh well it#s trivial to convert NV12 to I420
[15:15] <Compn> i think multi format support for the filters is on the wishlist
[15:15] <nevcairiel> trivial and even pretty fast
[15:15] <wm4> you have to copy anyway...
[15:16] <Compn> ubitux : lavfi and rgb ?
[15:16] <j-b> wm4: because it is trivial does not mean it is done
[15:17] <Compn> wm4 : swscale everything!
[15:17] <Compn> ehe
[15:17] <Compn> and then via complains about slower video :P
[15:17] <wm4> Compn: this is much more trivial than using swscale
[15:17] <Compn> shifting the bits ?
[15:17] <wm4> and you could have native NV12 video output anyway - not like you must filter the video
[15:18] <wm4> more like shifting bytes
[15:18] <j-b> users never filter the video, right...
[15:18] <Compn> subtitles? who needs those!
[15:18] <nevcairiel> if you can assume SSE2, there isnt really any big overhead
[15:18] <j-b> nevcairiel:  "because it is trivial does not mean it is done" once again
[15:18] <funman> my atom has a dxva2 decoder
[15:18] <wm4> Compn: subtitles shouldn't be rendered into the video, but onto the screen
[15:18] <funman> (mpeg2 only ok, but ..)
[15:19] <Compn> funman : so whats VIA 's complaint ? they want native colorspaces ?
[15:19] <nevcairiel> newer atoms have a really decent dxva decoder
[15:19] <funman> Compn: they just said that VLC was slower than WMP iirc
[15:19] <Compn> ah, yeah
[15:19] <j-b> of course
[15:19] <nevcairiel> WMP doesnt do copy-back
[15:19] Action: Compn finds vlc is slower than lots of things :P
[15:19] <Compn> eheh
[15:19] <wm4> funman: that's probably about the read back into system RAM?
[15:19] <nevcairiel> so, yeah :P
[15:19] Action: Compn trooolol
[15:19] <funman> wm4: nevcairiel: Compn: well that's true
[15:19] <funman> but we could be faster and still keep the copy-back
[15:20] <wm4> so WHAT the hell is the problem
[15:20] <Compn> well, not slower than quicktime ,realplayer or new wmp anyways
[15:20] <wm4> what colorspaces does VIA provide?
[15:20] <funman> 15:14 <@j-b> wm4: NV12 and RGB only in D3D surfaces, IIRC
[15:20] <Compn> anyways, thx for discussion, afk time
[15:20] <funman> wm4: i can send you the via laptop if you want to work on it :)
[15:20] <wm4> funman: and we asserted that NV12->I420 is easy and fast
[15:20] <nevcairiel> I dont think nvidia or amd support YV12 as render targets
[15:20] <funman> wm4: so MrSomeone needs to write that conversion and that's all?
[15:22] <wm4> and this already does NV12->I420? http://git.videolan.org/?p=vlc.git;a=blob;f=modules/codec/avcodec/copy.c
[15:22] <nevcairiel> even simded
[15:46] <cone-931> ffmpeg.git 03Paul B Mahol 07master:55d32eed8f2d: img2dec: seeking support
[16:10] <durandal_1707> img2 demuxer cant use random list of images (without 000X stuff) ?
[16:11] <nevcairiel> it needs to be able to glob them somehow
[16:21] <durandal_1707> -patern_type glob is it
[16:40] <durandal_1707> so is tinterlace and kerndeint mp filters finally be removed?
[17:09] <ubitux> durandal_1707: mp=kerndeint is still faster for me here
[17:10] <ubitux> even if i align the strides
[17:10] <ubitux> i don't know why
[17:13] <durandal_1707> did you pushed that patches from ml?
[17:14] <durandal_1707> and how much faster it is?
[17:17] <ubitux> i didn't push that one yet
[17:17] <ubitux> i've rewritten it but i'm still not satisfied
[17:21] <wm4> ubitux: but the results are correct? so who fuckign cares
[17:22] <wm4> it's a shit filter anyway
[17:22] <wm4> no seriously
[17:22] <durandal_1707> ubitux: how fast?
[17:22] <wm4> why don't you port vitc instead
[17:22] <ubitux> wm4: the code is almost the same, so i don't understand
[17:22] <ubitux> durandal_1707: not a huge one, i don't have the bench here, try yourself
[17:23] <durandal_1707> wm4: why dont you donate $ every time you ask for something?
[17:23] <ubitux> wm4: didn't have time, and i won't for a while now unfortunately
[17:23] <wm4> durandal_1707: because I don't have any $
[17:24] <durandal_1707> ubitux: becos of fast_memcpy
[17:25] <ubitux> isn't this defined to memcpy?
[17:26] <durandal_1707> why not commit align stuff?
[17:26] <durandal_1707> also there are ALIGN macro stuff
[17:26] <durandal_1707> like DECLARE_ALIGNED
[17:26] <durandal_1707> did you tried with that ^ ?
[17:27] <ubitux> i don't see anything like that in the original filter
[17:27] <durandal_1707> because it is aligned by luck
[17:28] <durandal_1707> you dont need it if you aligned it manually ... (but may break if you add/remove something)
[17:35] <durandal_1707> ubitux: if you really want it fast move if/else inside loop out of it
[17:36] <ubitux> i don't want it fast, i want to understand the difference of speed between the two
[17:36] <ubitux> if it's some align luck then ok
[17:36] <durandal_1707> the one that checks for pix_fmt
[17:37] <durandal_1707> or you could use function pointers
[17:37] <durandal_1707> your code have extra else doesn't it?
[17:38] <ubitux> it's not my code :p
[17:39] <michaelni> durandal_1707, "img2dec: seeking support" breaks fate
[17:39] <durandal_1707> where?
[17:40] <michaelni> http://fate.ffmpeg.org/report.cgi?time=20130108161525&slot=x86_64-linux-gnu-gcc-4.1.3
[17:40] <michaelni> also locally here
[17:40] <durandal_1707> there is broken seeking test?
[17:40] <michaelni> no its more
[17:40] <durandal_1707> i dont get it
[17:40] <michaelni> fate-lavf-dv_fmt, fate-lavf-mxf, fate-lavf-mov
[17:40] <durandal_1707> that is ridiculous
[17:40] <michaelni> fate-lavf-pbmpipe, fate-lavf-mpg, fate-lavf-ismv
[17:41] <durandal_1707> perhaps i changed pts?
[17:41] <durandal_1707> and all  those tests use pts
[17:45] <durandal_1707> what actually changed in created output?
[17:51] <durandal_1707> hah, i change pts for imagepipe
[17:56] <durandal_1707> but fate fails still, so changing pts breaks fate
[18:03] <durandal_1707> what is point of adding seek test for stuff that does not seek at all...
[18:04] <wm4> to test graceful failure?
[18:04] <durandal_1707> michaelni: pipe test stuff is obviously correct and i fixed it locally, but others formats still fails because i change pts
[18:05] <durandal_1707> image seek test failures are legit,  i need to update them
[18:06] <durandal_1707> the only explanation is that such test seek some way multiple times and same frame gives different pts
[18:06] <durandal_1707> which is completly bogus
[18:07] <durandal_1707> obviously if i do not touch pts everything passes
[18:07] <durandal_1707> but seeking images is obviosly wrong because pts only increases or starts from 0 if you seek backward
[18:08] <durandal_1707> some random stuff because pts are derived from pos which is always 0 for files
[18:08] <durandal_1707> so should i just update all other failing tests?
[18:10] <durandal_1707> the generated files are same
[18:11] <durandal_1707> tests tests also some other nonsense
[18:15] <durandal_1707> michaelni: ^
[18:16] <cone-931> ffmpeg.git 03Paul B Mahol 07master:626756aed2dd: img2dec: do not change packet pts for image2pipe
[18:18] <michaelni> durandal_1707, pbmpipe pts also looked wrong
[18:18] <michaelni> like 0,1,4,7,10,13 in 1/25 tb
[18:18] <durandal_1707> i fixed this
[18:18] <durandal_1707> this is obvious bug
[18:19] <michaelni> yes, thx
[18:20] <durandal_1707> the other tests that cover seeking tiff/bmp/.. now actually seek to something
[18:21] <durandal_1707> but why i see st = -1 ?
[18:25] <michaelni> fate-idroq-video-encode still fails here
[18:25] <durandal_1707> and others too
[18:31] <durandal_1707> why would idroq fail?
[18:33] <durandal_1707> that test use synthetic in suite directory itself, this is strange
[18:38] <michaelni> durandal_1707, i get dup=1 for the roq test
[18:38] <michaelni> so maybe a timestamp issue
[19:04] <durandal_1707> michaelni: it is timestamp issue
[19:07] <durandal_1707> the only way i see it is that fate refs should be updated
[19:10] <michaelni> durandal_1707, roq can be fixed by adding  -r 30 before -i ... i think
[19:13] <michaelni> for the others maybe an update is correct i dunno
[19:21] <durandal_1707> michaelni: -r 30 does not help
[19:26] <durandal_1707> so i will just update reference stuff
[19:29] <michaelni> ive looked at lavf.mpg and it seems the previous code couldnt figure out the duration the new has it correct
[19:29] <michaelni> which leads to the diference in that case
[19:29] <michaelni> so in that case update is correct i think
[19:39] <michaelni> durandal_1707, ok update
[19:40] <durandal_1707> in idroq case, last 2 frames are different
[19:40] <michaelni> hmpf
[19:40] <michaelni> after encoder ? 
[19:41] <michaelni> if so the input differes due to different frame dup 
[19:41] <durandal_1707> yup, previous had encoder had dup one frame
[19:43] <durandal_1707> actually opposite, new one have dup frame
[19:51] <cone-931> ffmpeg.git 03Paul B Mahol 07master:9e2387a6a9a6: fate: upate after 55d32eed8f
[19:52] <nevcairiel> dont you usually run fate before pushing commits? didnt you find this before? <.<
[19:52] <durandal_1707> i thought this should not be covered by fate at all
[19:53] <beastd> shit happens
[19:55] <durandal_1707> michaelni: the 2122 bug is interesting, zeroing buffer makes ffmpeg very slow
[19:59] <cone-931> ffmpeg.git 03Carl Eugen Hoyos 07master:0b68ebc4b6b9: Fix compilation with --disable-everything --enable-decoder=dirac.
[19:59] <beastd> It is probably good to just make it a habit to run fate before push. I mean even if you think it isn't covered by fate at all the more important it is that you see if it affects fate. Having said that, I was lured into not running fate more than once myself...
[20:06] <Compn> arg
[20:06] <durandal_1707> wm4: do you have an axe?
[20:06] <Compn> Zeranoe : whats up with the autobuilds ?
[20:07] <wm4> durandal_1707: no
[20:07] <Zeranoe> Compn: What do you mean?
[20:08] <Compn> i looked at it a few days ago and it wasnt updated since november
[20:08] <Zeranoe> Compn: Try refreshing the page?
[20:09] <Zeranoe> Compn: There was a breif delay as I rebuilt my build machine and transfered everything over. But since Dec 27th there have been 12 new builds.
[20:10] <Compn> Zeranoe : ok no problem :)
[20:10] <durandal_1707> what muxer beside mp3 supports covertart?
[20:22] <durandal_1707> i cant reproduce #2124
[20:27] <ubitux> i can
[20:28] <durandal_1707> huh, i tried with -acodec copy, you?
[20:29] <ubitux> just like him, -c:a libmp3lame
[20:29] <durandal_1707> but why would that happen
[20:29] <ubitux> it's stalled with frame=1
[20:30] <ubitux> and then *** Error in `./ffmpeg_g': double free or corruption (!prev): 0x0000000001c1d760 ***
[20:31] <durandal_1707> that covertart is huge hack
[20:42] <cone-931> ffmpeg.git 03Michael Niedermayer 07master:252316c88598: img2dec: fix -loop
[20:42] <cone-931> ffmpeg.git 03Michael Niedermayer 07master:9aec63af9b50: swr: fix assertion failure if dither is used without the preout buffer differing from in
[20:42] <cone-931> ffmpeg.git 03Michael Niedermayer 07master:a260c7973370: ffmpeg: fix dither to 24bit PCM output
[20:51] <durandal_1707> when is this dither applied?
[20:54] <durandal_1707> michaelni: the 252316c is just hack for ffmpeg only, no? which i dislike
[21:00] <durandal_1707> and why would dither scale be changed from ffmpeg, that is not usefull at all
[21:02] <durandal_1707> and why would one need to change it anyway, this is just unfriendly
[21:02] <michaelni> well, true
[21:02] <michaelni> but how else do you want to implementg it ?
[21:02] <michaelni> swr doesnt know its output will be 24bit
[21:02] <michaelni> its a 32bit sample format
[21:04] <durandal_1707> yes, wouldn't it be better in lavfi resampler?
[21:04] <durandal_1707> or aformat
[21:04] <durandal_1707> something that can know bits_per_codec_sample
[21:04] <michaelni> lavfi resampler would be better
[21:05] <michaelni> but iam not sure it knows the bits
[21:05] Action: durandal_1707 michaelni cant you just do what libavresample/justin do?
[21:05] <michaelni> that supports dither to s24 ?
[21:06] <durandal_1707> no, but something to 16, that is irrelevant, more important is when & how it is triggered
[21:07] <michaelni> aresample=dither_... should work fine
[21:07] <michaelni> or ffmpeg -dither_... 
[21:08] <michaelni> about img2dec & loop, with loop 1 the demuxer would return pts that reset to 0 it can do that only if it sets AVFMT_TS_DISCONT
[21:09] <durandal_1707> couldnt with adding 24 bit sample format one could add SIMD that do shifting to 32? is 24bit shifted when fed to alsa/oss?
[21:11] <durandal_1707> michaelni: loop, so it works fine for gif or any other demuxer that use loop?
[21:11] <michaelni> i only know -loop with img2dec ended in a infinite loop and that my trivial 1 line patch fixed it
[21:12] <michaelni> iam happy to fix it differently or to approve a patch changing it
[21:12] <durandal_1707> no, i'm just unsure if/is gif affected by same bug
[21:13] <michaelni> its easy to test if you have a animated gif
[21:13] <durandal_1707> i'm may missunderstood how loop should really work, in which case you change is correct
[21:14] <durandal_1707> well pts are still broken when one seek with loop enabled, but dunno there is good fix
[21:15] <michaelni> seeking in infinite looped file, timestamp%num_images
[21:18] <durandal_1707> please apply/post patch
[21:44] <durandal_1707> hmm it seems loop works just fine with img2dec
[22:32] <ubitux> aaah shit
[22:32] <ubitux> i understand
[22:33] <ubitux> write_packet in the mp3 muxer is modifying the pkt
[22:33] <ubitux> :(
[22:33] <ubitux> pkt->destruct = NULL;
[22:34] <ubitux> and since i'm doing a copy of the pkt this change is not reported
[22:34] <ubitux> now how am i supposed to fix that now&
[22:37] <ubitux> ok fixed, perfect.
[22:44] <ubitux> saste: got some invalid read/write with kerndeint (reproducible with mp=kerndeint though), interested?
[22:45] <saste> how?
[22:45] <ubitux> try -f lavfi -i testsrc=s=720x479 -vf tinterlace,kerndeint
[22:45] <ubitux> no reproducible with 478 or 480
[22:49] <saste> so seems related to odd heights
[22:50] <ubitux> i wonder how much filters i can break with input like this
[22:53] <wm4> probably most
[22:53] <ubitux> that's pretty mean
[22:53] <ubitux> :(
[22:54] <wm4> mplayer has the same problem all over the place
[22:54] <wm4> mostly because it thought that "width >> chroma_x_shift" is a reasonable way to compute chroma plane width
[23:22] <cone-931> ffmpeg.git 03Clément BSsch 07master:119d70db5099: lavf/mux: do not pass a copy of the packet to write_packet().
[23:27] <cone-931> ffmpeg.git 03Paul B Mahol 07release/1.1:9202824e1bf9: Changelog: move Megalux where it belongs
[23:27] <cone-931> ffmpeg.git 03Carl Eugen Hoyos 07release/1.1:36dac6da41c8: Add forgotten AVC Intra entry to Changelog. (cherry picked from commit b23aff6755ff96b3b338e4b5f9eb3b6a91fda433)
[23:27] <cone-931> ffmpeg.git 03Clément BSsch 07release/1.1:606aa3baee1e: lavf/mux: do not pass a copy of the packet to write_packet().
[23:39] Action: ubitux is really glad to have Carl doing git bisect
[23:39] <ubitux> that's most likely one of the most boring task to do, that's so nice for us
[23:39] <ubitux> btw, lol @#1898
[00:00] --- Wed Jan  9 2013