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

[burek]

[00:34] <saste> ubitux: http://vimeo.com/enhancer?utm_campaign=2262&utm_medium=newsletter-features-enhancer-201303&utm_source=email
[00:34] <saste> for more preset ideas :)
[00:59] <ubitux> saste: add any you want
[01:09] <saste> ubitux, pink-saste-sunshine
[01:09] <ubitux> :)
[01:09] <ubitux> saste: note that those filters also have an advanced noise filter
[01:10] <ubitux> afaict
[01:10] <saste> and some addgrain filters
[01:10] <ubitux> yeah well, grain/noise
[01:26] <ubitux> i get fun output with the phasescope filter from Paul :)
[02:00] <FFmpeg-github> 01[13FFmpeg01] 15michaelni pushed 5 new commits to 06master: 02http://git.io/sSjItg
[02:01] <FFmpeg-github> 13FFmpeg/06master 14dc65d78 15Clément BSsch: lavfi/curves: add presets support....
[02:01] <FFmpeg-github> 13FFmpeg/06master 14183f345 15Clément BSsch: lavfi/curves: support preset shorthand.
[02:01] <FFmpeg-github> 13FFmpeg/06master 14133035c 15Clément BSsch: lavfi/curves: add forgotten strong_contrast preset.
[04:09] <cone-338> ffmpeg.git 03Michael Niedermayer 07master:ea7b96af961e: avcodec/x86/dsputil_qns_template: use av_assert
[04:10] <FFmpeg-github> 01[13FFmpeg01] 15michaelni pushed 4 new commits to 06master: 02http://git.io/PAGY4g
[04:10] <FFmpeg-github> 13FFmpeg/06master 14e600d06 15Clément BSsch: lavfi/perms: remove unecessary indirection after f7324c06.
[04:10] <FFmpeg-github> 13FFmpeg/06master 149371467 15Clément BSsch: lavfi/perms: add seed option.
[04:10] <FFmpeg-github> 13FFmpeg/06master 14e32cbd0 15Clément BSsch: lavfi/perms: add myself to the copyright header.
[09:11] <Granjow> I am again trying to figure out why seeking fails so terribly (ffmpegsource does not seem so easy to use at first glance)
[09:12] <Granjow> For example, I seek to frame 39 in my avi file, and ffmpeg says, yes, you successfully decoded PTS 39 DTS 39 at position 8269008
[09:13] <Granjow> unfortunately this is frame 61 (DTS/PTS) and 39 would be at 4891856
[09:14] <Granjow> as of my understanding, this is off by a tiny bit
[09:15] <av500> a tiny wee bit
[09:33] <TheFluff> 09:11:52 < Granjow> I am again trying to figure out why seeking fails so terribly (ffmpegsource does not seem so easy to use at first glance) <-- if you think ffms is hard to use and ffmpeg itself isn't then I really dunno what to say to help you
[09:41] <Granjow> TheFluff: ffmpegsource says it needs Haali's Media Splitter for seeking in MPEG. Its page is offline. Well, in case that this does not affect MJPEG, it might work ... 
[09:42] <TheFluff> it refers to the mpeg ts/ps containers only
[09:42] <TheFluff> and you had avi, did you not?
[09:43] <Granjow> ah. Yes.
[09:43] <TheFluff> also, it's an optional component
[09:43] <TheFluff> it can work with lavf too, it's just that lavf hates seeking in ts
[09:45] <Granjow> Where am I supposed to find libavresample/avresample.h?
[09:48] <Granjow> Hm, I guess it is not in 0.10.2 yet?
[09:54] <ubitux> 0.10.2 might have libswresample
[09:54] <ubitux> but 0.10 is very old
[09:54] <ubitux> libavresample is not really supported in ffmpeg anyway
[09:59] <Granjow> Okay, git says it is not. Problem is, the project has to run on Windows, and MXE for cross-compiling only has 0.10.2 in its repositories. Afair I tried to and miserably failed in compiling ffmpeg myself on mxe ...
[10:00] <Granjow> ubitux: Well, ffmpegsource relies on it
[10:00] <Granjow> but maybe I can convince it otherwise
[10:01] <Granjow> or maybe I just check out an older version of ffmpegsource :-]
[10:02] <TheFluff> you can download a precompiled binary you know
[10:02] <TheFluff> there's an sdk download link
[10:05] <ubitux> http://www.sview.ru/en/sview2009/info  is the ugly interlacing supposed to make a 3d effect?
[10:08] <Granjow> TheFluff: precompiled binary of ffmpegsource?
[10:10] <TheFluff> https://code.google.com/p/ffmpegsource/downloads/detail?name=ffms-2.17-sdk.7z
[10:12] <Granjow> I'd rather re-write ffmpeg from scratch than trying to compille with VS
[10:13] <Granjow> had enough pain with it, and at one point in time it is enough ;)
[10:13] <ubitux> it should be relatively trivial now to compile ffmpeg with VS
[10:13] <Granjow> mxe also has the benefit that I can do automated builds on Linux
[10:14] <Granjow> Well, last time it was trivial to get all sorts of compiler errors, I spent days on it and nothing good came from the attempts
[10:14] <TheFluff> if you want to do automated builds on linux then maybe you should actually build a version that isn't ancient~
[10:14] <TheFluff> just saying
[10:14] <ubitux> Granjow: https://www.ffmpeg.org/platform.html#Microsoft-Visual-C_002b_002b
[10:18] <Granjow> better ancient than broken, as ffmpeg's seeking appears to be
[10:22] <ubitux> can you reproduce the seeking problem with a recent FFmpeg and the ffmpeg tool?
[10:27] <Granjow> ubitux: I just have 1.0.4 installed. Could try 1.0.6. (0.10.2 is for the Windows build.)
[10:29] <ubitux> can you share a sample so we can reproduce?
[10:32] <Granjow> ubitux: Sure, avi is here http://granjow.net/uploads/temp/seeking.avi (400 MB), uploaded yesterday. Code is at git://granjow.net/phenoCam.git, branch seeking, executable can be built with «mkdir build; cmake ../src; make seeking»
[10:33] <Granjow> in src/test/seeking.cpp
[10:33] <Granjow> though you may want to test with your own code which is more likely to be using ffmpeg correctly
[10:35] <ubitux> there is no frame seek in ffmpeg btw
[10:36] <ubitux> mmh wait, we have AVSEEK_FLAG_FRAME though
[10:37] <ubitux> i'm guessing it doesn't work though :p
[10:37] <Granjow> ubitux: The docs says it seeks to keyframes. The video has nothing else but keyframes.
[10:37] <Granjow> So either my code is wrong, or the docs are.
[10:40] <TheFluff> I don't think AVSEEK_FLAG_FRAME has ever done what the docs claims it does
[10:41] <nevcairiel> i dont think it does much at all
[10:41] <TheFluff> this is why you let someone else figure out this stuff for you
[10:43] <Granjow> Well, I don't even use it, actually. Or, it makes no difference in the result.
[10:53] <TheFluff> well
[10:54] <TheFluff> I'd still say it'd be much more productive to just use ffms
[10:54] <TheFluff> but that's just me
[10:54] <TheFluff> vOv
[10:55] <Granjow> TheFluff: Still trying to integrate it into CMake.
[10:59] <Granjow> would be much easier if ffmpeg just worked.
[10:59] <av500> +1
[10:59] <av500> and seeking in avi is at least not hard
[10:59] <av500> since you have an index entry for every frame
[11:00] <av500> and its CFR
[11:11] <Granjow> ha ha very funny. Even when I seek to Byte 4653016 (lower bound 3653016) it arrives at 8294840
[11:12] <Granjow> (i.e. with avformat_seek_file)
[11:14] <Granjow> If I seek to frame 0 and then continue until I arrive at byte 4653016 by just reading frames it works
[11:16] <Granjow> I wonder why ffmpeg always shows an offset of 8 compared to the table displayed by aviindex
[11:16] <Granjow> maybe this breaks seeking :P
[11:17] <av500> Granjow: because it reads the 4+4 byte header before the actual data
[11:18] <av500> 00wb and the 4 byte frame size
[11:18] <av500> and returns that as pos
[11:25] <Granjow> Okay.
[11:26] <Granjow> But either the video or the code is broken, as not even the DTS values returned are correct when seeking.
[11:33] <av500> its possible that there is a bug, yes :)
[11:54] <Granjow> later
[12:23] <cehoyos> nevcairiel: If you look into this DShow installer: http://polppolservice.com/ul/index.php?dir=CCTV/&file=EN-Hik_DSFilters_V6.0.0.2.zip Do you see for which kind of files the splitter is used? Ie how does it know that a particular file should be handled with this splitter? (vlc ticket 8344)
[13:10] <cone-921> ffmpeg.git 03Janne Grunau 07master:e5c2794a7162: x86: consistently use unaligned movs in the unaligned bswap
[13:10] <cone-921> ffmpeg.git 03Michael Niedermayer 07master:cb69a9dbf4c4: Merge commit 'e5c2794a7162e485eefd3133af5b98fd31386aeb'
[13:10] <cone-921> ffmpeg.git 03Michael Niedermayer 07master:9b9205e760d2: x86/dsputil.asm: make unaligned bswap actually work
[13:18] <Compn> cehoyos : isnt that set using GUID in the registry ?
[13:18] <Compn> or somewhere in directshow stuff
[13:18] <Compn> i mean, the filter pin has a guid , directshow uses it based on the file / riff
[13:18] <cehoyos> Compn: That is my question.
[13:19] <cone-921> ffmpeg.git 03Martin Storsjö 07master:ccd349e555d8: h264: Remove an unused variable
[13:19] <cone-921> ffmpeg.git 03Kostya Shishkov 07master:613a37eca4c7: ape: 3.80-3.92 decoding support
[13:19] <cone-921> ffmpeg.git 03Michael Niedermayer 07master:795b911bd8ac: Merge commit '613a37eca4c7b8eefceaa3e0231c23ad090ca94f'
[13:19] <Compn> is that hikvision? http://samples.ffmpeg.org/camera-dvr/hikvision/
[13:20] <cehoyos> Iiuc, the company produces many cameras (with may formats), my patch and question are about vlc ticket 8344
[13:21] <Compn> erm so whats the question again ? 
[13:21] <Compn> you want the guid of the installed filters ? or ?
[13:22] <cehoyos> How does WMP know that is should use the newly installed splitter for a particular file?
[13:22] <Compn> "where in the file is it looking for the hikvision riff" ?
[13:22] <Compn> riff/identification ?
[13:23] <Compn> there was a document that explains this
[13:23] <Compn> somewhere
[13:23] <cehoyos> More like "What is the hikvision riff" but that already assumes that there is a "riff" concept in the file while it actually is a mpeg program stream
[13:23] <Compn> lets see if i can find it
[13:23] <Compn> i understand
[13:24] <Compn> so theres not a certain mpeg_ps stream 0xwhatever that declares hikvision ?
[13:24] <cehoyos> And this should of course not be "What is the hikvision riff" but "What is the riff (assuming this is the right word) in the given sample."
[13:24] <Compn> When WMP requests DirectShow to render a file, filter graph manager goes through existng file and protocol associations in order to pick proper source filter. That is, the filter of interest needs to be registered as described in the following MSDN topic:
[13:24] <Compn> http://stackoverflow.com/questions/13745383/provide-directshow-filter-for-windows-media-player-activex-control-in-c-sharp-ap
[13:25] <Compn> http://msdn.microsoft.com/en-us/library/windows/desktop/dd377513(v=vs.85).aspx
[13:25] <cehoyos> My question is now: What is done for this installer: http://polppolservice.com/ul/index.php?dir=CCTV/&file=EN-Hik_DSFilters_V6.0.0.2.zip
[13:26] <Compn> These are ulaw and alaw. G711a is alaw and G711u is ulaw. 
[13:26] <Compn> according to google ^
[13:27] <Compn> you should be able to get the registered filetypes and 'riff' by using graphedit after you install those codecs
[13:27] <Compn> i guess i could try it on my winxp box
[13:28] <cehoyos> Without knowing much about DShow, I assume you are talking about "decoders" (however they are called in DShow language), but my question is how does WMP know it should use the newly installed demuxer for a particular file?
[13:28] <cone-921> ffmpeg.git 03Martin Storsjö 07master:75644335b907: lavc: Move start code finding to utils.c
[13:28] <cone-921> ffmpeg.git 03Michael Niedermayer 07master:2cdedcbceab9: Merge commit '75644335b907919057960716508477239c26fed4'
[13:28] <cone-921> ffmpeg.git 03Michael Niedermayer 07master:7834bb092a95: Revert "Fix compilation with --disable-everything --enable-parser=h264."
[13:28] <cehoyos> michaelni: Thank you!
[13:28] <Compn> directshow scans the file, then it looks for any splitter (demuxer) and decoder that handles that file 
[13:29] <cehoyos> So what does it look for to choose the splitter in http://polppolservice.com/ul/index.php?dir=CCTV/&file=EN-Hik_DSFilters_V6.0.0.2.zip ?
[13:29] <Compn> let me install this and find out
[13:30] <durandal11707> ubitux: i can't find that hack for min/max_samples
[13:31] <ubitux> //* This is currently necessary for the min/max samples to work properly. * FIXME: remove me when possible */
[13:31] <ubitux> this ^
[13:31] <ubitux> audio_request_frame
[13:34] <Compn> cehoyos : this comes up in my search, its what the installer adds to windows registry and files > http://www.siteadvisor.com/sites/60.191.58.151/downloads/32013536/
[13:35] <Compn> cehoyos : but thats not the exact same as the v6 installer...
[13:35] <durandal11707> Compn: directshow scans file? i dont think so ...
[13:35] <durandal11707> RULE #0 : do not commit hacks
[13:35] <cehoyos> My question is now: Do the modifications of the system registry tell you for which kind of files the Hikvision Splitter is used?
[13:35] <durandal11707> RULE #1 : revert hacks
[13:36] <Compn> durandal11707 : wmp is still able to play files when you rename the file extension :P
[13:36] <Compn> cehoyos : good question, no idea :)
[13:36] <nevcairiel> cehoyos: it assigns it self for files with .264 and .mp4 extensions, and for files starting with bytes 34484b48 (in hex)
[13:37] <cehoyos> thats not the exact same as the v6 installer <-- I am only interested in the installer I linked above because that installer allows (supposedly) to play the file in question
[13:37] <cehoyos> nevcairiel: Is 34484b48 IMKH ?
[13:37] <nevcairiel> at least the info Compn linked, the thing is downloading very slow
[13:37] <cehoyos> (Sorry!)
[13:38] Action: Compn looks at hex to ascii converter
[13:38] <durandal11707> cehoyos: nope
[13:38] <Compn> nevcairiel : it wasnt slow for me. i can send the zip to you if you want
[13:38] <nevcairiel> 4HKH if my ascii table didnt lie
[13:38] <nevcairiel> but anyway, thats the text Compn linked, not the installer
[13:38] <Compn> thats an old installer the siteadviser one
[13:39] <cehoyos> That is unfortunately a completely unrelated start of file (that is the one we have samples for)
[13:39] <nevcairiel> 5 more minutes for the installer =p
[13:39] <Compn> ehe
[13:39] <cehoyos> .. but cannot decode (durandal11707: That may be something for you)
[13:39] <durandal11707> all of this for mulaw/alaw in mpeg?
[13:39] <Compn> [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Media Type\
[13:39] <Compn> is where thats stored :P
[13:40] <cehoyos> No, for you this is about completely unsupported file, find them at http://samples.ffmpeg.org/camera-dvr/hikvision/ (and leave the trivial issue to me)
[13:40] <ubitux> does anyone know if it's possible with the ff tools to force the message repeating?
[13:40] <Compn> ubitux : verbose doesnt do it ?
[13:41] <ubitux> it seems there is a log flag but it doesn't look settable at cli level, or i miss something
[13:41] <ubitux> Compn: mmmh
[13:41] <ubitux> nope
[13:42] <ubitux> well, whatever
[13:43] <Compn> cehoyos : ok i found that key from the new installer in my registry
[13:43] <cehoyos> So?
[13:44] <cehoyos> Or do you mean: You found IMKH ?
[13:44] <Compn> IMKH is there 
[13:44] <Compn> yes
[13:45] <Compn> sorry, i had to hex convert it
[13:45] <Compn> looks like the IMKH should be in the same place as 4HKH
[13:45] <Compn> if i'm reading this correctly
[13:46] <Compn> the file also handles 4MSH
[13:46] <Compn> the splitter (demuxer) that is
[13:47] <durandal11707> ubitux: swap what? I just replaced private time_base with frame_rate which actually is. So if setting frame_rate instead of time_base makes sense it should be done in another commit because that changes functionality
[13:47] <ubitux> test->time_base.num = frame_rate_q.den;
[13:47] <ubitux> test->time_base.den = frame_rate_q.num;
[13:48] <ubitux> there is num/den swap which you seem to have removed
[13:48] <ubitux> or did i miss something?
[13:49] <durandal11707> ahh
[13:49] <durandal11707> i did not noticed this nonsense
[13:49] Action: Compn goes afk
[13:50] <ubitux> durandal11707: fate wasn't complaining btw?
[13:50] <durandal11707> there is invert?
[13:50] <durandal11707> ubitux: doesn't belive in fate
[13:51] <Compn> cehoyos : let me know if you want a screenshot of my registry :P
[13:51] Action: Compn gone
[13:51] <cehoyos> Compn, nevcairiel: Thank you for answering question 1 (of two), the second one is more difficult for me to express because my DShow knowledge is 0:
[13:51] <cone-921> ffmpeg.git 03Martin Storsjö 07master:f1e9398621af: lavc: Rename avpriv_mpv_find_start_code after moving out from mpegvideo
[13:51] <cone-921> ffmpeg.git 03Michael Niedermayer 07master:b19604cc4bbf: Merge commit 'f1e9398621af0bc9d166014e4ce6996bb4f141d0'
[13:52] <cehoyos> How is mulaw chosen? Does the splitter set "mulaw" or does it set some value that is then again searched for in the registry?
[13:53] <cehoyos> The mpegps file in question uses the default (correct) stream_format for H264 and 0x91 for mulaw.
[13:53] <nevcairiel> formats are identified by a GUID, so it somehow has to create a GUID for the audio stream, which is then looked up in the registry
[13:53] <cehoyos> Iiuc, 0x91 can be AC-3, so it is not a good idea to always choose mulaw for 0x91
[13:53] <nevcairiel> usually audio/video use a FourCC based format, where the first 4 byte are the FourCC and the other bytes a static postfix
[13:54] <cehoyos> And is it possible to find out how the splitter sets the guid (because of which stream_format) or would that already require reverse-engineering?
[13:54] <nevcairiel> thats totally up to it, so you would need to RE that
[13:54] <cehoyos> Can you verify that 0x91 can be AC-3 ?
[13:55] <Compn> where can we go to get a list of mpeg stream hexs ?
[13:55] <cehoyos> (Do you already have the installer?)
[13:55] <cehoyos> http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/M2TS.html
[13:56] <durandal11707> run your favorite dissasembler
[13:56] <nevcairiel> 0x81 seems to be AC3
[13:56] <nevcairiel> never heard of 0x91
[13:56] <cehoyos> Yes, I found some sites without sources that claim 0x91 is also AC-3
[13:56] <nevcairiel> and neither has our mpegts demuxer
[13:57] <cehoyos> AC-3 can be auto-detected, so users will not report such samples;-(
[13:58] <cehoyos> This site claims 0x91 is A52b: http://erato1004.tistory.com/entry/mpeg-stream-type
[13:58] <nevcairiel> 0x91 is standardized for Blu-rays to be the IG stream (interactive graphics, ie. the menu)
[13:59] <cehoyos> Are they supposed to be equal for ps and ts?
[14:00] <cehoyos> How does the GUID look like that is registered for mulaw for the mentioned installer?
[14:00] <cehoyos> (Does it point to "0x91"?)
[14:01] <nevcairiel> it seems to use a completely random GUID
[14:01] <Compn> it installs 'g711' codec
[14:01] <Compn> g711codc.ax
[14:02] <cehoyos> And which GUID's are associated with that codec? (Or do I misunderstand?)
[14:03] <nevcairiel> Compn: i dont see g711codc.ax
[14:03] <nevcairiel> only HikDecoder.ax
[14:03] <Compn> cehoyos : other directshow audio decoders are set correctly, for example, acelp sipro is set to 'subtype: fourcc' 00000130 (aka 0x130)
[14:04] <Compn> nevcairiel : oh, maybe its unrelated file then...
[14:04] <nevcairiel> hikdecoder.ax uses {0F41A4CC-57F2-4378-A240-7665889AD3B0}
[14:04] <nevcairiel> which is just a random guid
[14:05] <Compn> but thats because sipro is only found in avi or wav, which uses fourccs and riffs ...
[14:06] <durandal11707> w64, asf and maybe others use guids
[14:07] <Compn> http://bbs.csdn.net/topics/240081106
[14:08] <Compn> is definitely something to do with the hikvision ax
[14:08] <cehoyos> nevcairiel: User KuroiTsuki (and I) would like to know why mingw is so bad (ie how can we see it is bad)?
[14:08] <nevcairiel> you mean classic mingw?
[14:08] <cehoyos> Yes
[14:08] <cehoyos> http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/160953/focus=160956
[14:08] <nevcairiel> becuase mingw-w64 is just fine
[14:09] <cehoyos> Sorry, but that is not 100% convincing;-)
[14:09] <nevcairiel> mostly because its outdated and abandoned
[14:09] <Compn> did mingw ever fix the 4gb limit on files ?
[14:09] <Compn> the off_t thing
[14:09] <Compn> sherpya has a long standing patch for mingw system headers
[14:09] <nevcairiel> it doesn't support many windows APIs
[14:10] <nevcairiel> for example, windows has aligned memory allocations, which avutil/mem.c can even use, but not with mingw32, so it has to fallback to its own memory hack
[14:10] <cehoyos> Let me try again: If I compile a pre-atomic version of FFmpeg with mingw(old), does it have any disadvantages over mingw64?
[14:10] <nevcairiel> there are several of such cases
[14:11] <JEEB> other than the atomics, it's mostly the memalign hack
[14:11] <JEEB> and then possibly some other things
[14:11] <cehoyos> So mingw-64 does allow aligned allocation, mingw not?
[14:11] <nevcairiel> there are alot of improvements to the gnu string fucntions that are badly emulated in mingw32, not sure how much that is of consequence
[14:11] Action: durandal11707 wants coverage for mandelbrot, cellauto, ..., generally for libavfilter
[14:11] Action: Compn afk
[14:11] <JEEB> oh right, mingw-w64 doesn't let you use BBB's windows compat stuff for the string stuff
[14:11] <JEEB> uhh
[14:11] <JEEB> wrote that wrong
[14:12] <JEEB> !mingw-w64
[14:12] <JEEB> is what I meant :P
[14:12] <Compn> cehoyos : ask sherpya about mingw v mingw64 , http://oss.netfarm.it/mplayer-win32.php
[14:12] <JEEB> the stuff that's in compat/win32 IIRC
[14:12] <JEEB> that doesn't get enabled with ye olde mingw at least
[14:12] <nevcairiel> not to mention that mingw32 has no support for 64-bit and as of gcc 4.8, even gcc requires mingw-w64
[14:12] <JEEB> (mingw32 is mostly limited to Win2000 APIs)
[14:13] <Compn> ehe
[14:13] <nevcairiel> cehoyos: the real question is, why do people feel they need to stick to mingw32?
[14:13] <cehoyos> Compn: But I wanted to ask the developer who wrote on ffmpeg-devel that mingw is old and deprecated (I don't claim that this is not true, I was simply - together with a user who has already left this channel - searching for an explanation)
[14:13] <Compn> :)
[14:13] <JEEB> well
[14:13] <JEEB> 1) mingw32 is old
[14:13] <cehoyos> nevcairiel: Because nobody told them (me) that there is something else
[14:13] <nevcairiel> oh and mingw32 doesnt come with dxva2 headers
[14:14] <JEEB> 2) a dead project most probably can't call itself "deprecated"
[14:14] <nevcairiel> so you cant use it
[14:14] <JEEB> nevcairiel, yes because that stuff came after windows 2000 :D
[14:14] <cehoyos> But despite the existing headers, you still did not review the dxva decoding patch... (or did you and it was abandoned?)
[14:14] <JEEB> or I'm not sure if the project is dead, but I'd bet my backside on the CVS being (mostly) dead
[14:15] <nevcairiel> I'm not all that motivated to review a patch that i think is conceptually wrong
[14:15] <nevcairiel> hm that word seems wrong
[14:15] <cehoyos> https://ffmpeg.org/platform.html#Native-Windows-compilation-using-MinGW-or-MinGW_002dw64 doesn't sound as if we would recommend against mingw
[14:15] <nevcairiel> old docs are old?
[14:16] <nevcairiel> of course it works, or well at least it worked
[14:16] <nevcairiel> but i wonder how many hacks are hidden for old mingw versions
[14:16] <cehoyos> We cannot test VDPAU easily, I fear that stagefright might not even compile, so if there is a possibility to test dxva I don't think a conceptual wrongness should stop the patch.
[14:17] <durandal11707> see RULE #0
[14:17] <nevcairiel> i wont let dxva be broken for a long time, dont worry :P
[14:17] <nevcairiel> my users would kill me
[14:17] <JEEB> nevcairiel, disabling threads and it compiles... with all of those ye olde hacks :D
[14:17] <cehoyos> But it would be even easier for you if Michael would already see the problems on fate
[14:18] <nevcairiel> fate is problematic for dxva. my boxes are on windows, but they are servers with no dxva capable gpu, and i wonder if anyone else would have one =P
[14:19] <cehoyos> I remember, but this would still allow developers to (theoretically) test it.
[14:19] <nevcairiel> because its a runtime dependency, its hard to automatically test it
[14:20] <cehoyos> Simply disable-decoder=h264 ?
[14:21] <cehoyos> You mean the gpu is a run-time dependency: Of course this is a problem, but it would still mean that dxva could be tested from inside FFmpeg
[14:21] <cehoyos> (And perhaps we can give you a gpu.)
[14:21] <nevcairiel> anyhow, i would rather put some energy into gwenoles plans for HWAccel v2 which is supposed to take a lot of the leg-work away from the applications
[14:22] <nevcairiel> its not like i dont have a gpu, its a server and didnt need one :)
[14:22] <nevcairiel> i think i would even have one in some closet that would work for basic testing :p
[14:22] <cehoyos> As long as it doesn't break VDPAU deinterlacing, I am certainly not against it;-)
[14:24] <iive> nevcairiel: I was thinking about implementing the X specific functions for hw decoding in libavdevice or something...
[14:25] <durandal11707> but anton want to merge libavdevice into libavformat
[14:25] <cehoyos> Concerning mingw: I found this on the mailing list: "things that are known to be broken with [mingw]", so I am now curious what this is.
[14:27] <nevcairiel> atomics are known to be broken :)
[14:28] <nevcairiel> most other broken things have been worked around over the years, i dont really remember specifics anymore
[14:28] <cehoyos> All-in-all, this does not sound extremely convincing...
[14:28] <nevcairiel> but as devs are moving forward, it will break more often in the future
[14:28] <cehoyos> I thought you were writing about bugs that can be reproduced, not bugs that cannot be reproduced because work-arounds exist.
[14:29] <nevcairiel> the fact that workarounds are required should already be convincing enough to suggest a better version (with no known drawbacks) :)
[14:29] <cehoyos> KuroiTsuki (the user with the compilation problem) now claims that there is no toolchain for mingw-w64
[14:29] <cehoyos> Where can it be found?
[14:29] <cone-921> ffmpeg.git 03Paul B Mahol 07master:7606f4a1af7d: lavfi/fps: make use of AV_OPT_TYPE_VIDEO_RATE
[14:29] <cone-921> ffmpeg.git 03Paul B Mahol 07master:54056c6655c2: lavfi/testsrc: make use of AV_OPT_TYPE_VIDEO_RATE
[14:29] <cone-921> ffmpeg.git 03Paul B Mahol 07master:975efc8864a9: lavfi/mandelbrot: make use of AV_OPT_TYPE_VIDEO_RATE
[14:29] <cone-921> ffmpeg.git 03Paul B Mahol 07master:8c5b37b4022d: lavfi/life: make use of AV_OPT_TYPE_VIDEO_RATE
[14:29] <cone-921> ffmpeg.git 03Paul B Mahol 07master:401f9c95e9ad: lavfi/cellauto: make use of AV_OPT_TYPE_VIDEO_RATE
[14:29] <cone-921> ffmpeg.git 03Paul B Mahol 07master:62d36abef4b7: lavfi/mptestsrc: make use of AV_OPT_TYPE_VIDEO_RATE
[14:30] <cehoyos> Which work-arounds do you mean?
[14:30] <nevcairiel> i build a toolchain myself (http://files.1f0.de/mingw/), but i think there is a kinda-official release too
[14:31] <cehoyos> (Sorry, I originally found it very likely that mingw is outdated, but the more I ask, the more this sounds like a former FFmpeg developer said to be active on Ubuntu and Debian)
[14:31] <durandal11707> mingw is dead. full stop.
[14:32] <cehoyos> "FFmpeg is deprecated?"
[14:32] <nevcairiel> believe what you want, but in contrast to your comparison, mingw32 is actually dead and no longer under active development and lacks support for any modern Windows APIs
[14:32] <cehoyos> or was it "not developed anymore"?
[14:33] <cehoyos> I do believe, but I'd like to tell users that ask me something
[14:33] <cehoyos> (like where they can find a toolchain, and this information should go to platform.html)
[14:34] <durandal11707> you can still find various posts on web, where ubuntu users mention that ffmpeg is deprecated/no more developed
[14:34] <cehoyos> Is this what should be used? http://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/
[14:35] <nevcairiel> thats becaue ubuntus "ffmpeg" claims that to be the truth, durandal11707
[14:35] <cehoyos> To tell the truth, it is one liar to claims this.
[14:35] <cehoyos> s/to/who
[14:35] <nevcairiel> cehoyos: those are source releases
[14:36] <cehoyos> Thank you, that is what the user told me;-(
[14:36] <iive> even if mingw32 is not developed anymore, I've heard that mingw64 does support 32bit tool chain.
[14:36] <cehoyos> He explained that when he saw that mingw is needed to compile mingw-w64, he started to doubt that our (FFmpeg's) reasoning makes sense.
[14:36] <nevcairiel> yea dont let yourself be fooled by the name, mingw-w64 can target both 32-bit and 64-bit =p
[14:36] <iive> and mingw32 is not the issue here, atomic operations exist only for pthreads.
[14:37] <cehoyos> iive: I suspect you are wrong here.
[14:37] <nevcairiel> mingw is the issue because it doesnt support windows-native atomics
[14:37] <nevcairiel> well sure, you could implement a second fallback for atomics using windows threads
[14:38] <nevcairiel> cehoyos: the official builds they host seem to be mostly focused for building win32 apps on linux, not win32 apps on windows
[14:39] <nevcairiel> for all i care, you can link my toolchain folder, i can even give it a nicer index page instead of the apache folder index :p
[14:39] <cehoyos> I have hear/read this before - it is extremely difficult to understand for me - it is in a way above my "Wahrnehmung"
[14:40] <iive> oh, the code is in atomic_win32.h
[14:40] <iive> so it is configure test failing?
[14:40] <nevcairiel> its mingw32 lacking proper header support for those
[14:40] <cehoyos> iive: No, see ticket 2363
[14:40] <nevcairiel> in a perfect world, a gcc compiler should also use the gcc atomics
[14:41] <nevcairiel> but apparently the default mingw32 mode doesn't enable them
[14:41] <nevcairiel> unless you use --arch=i486 or anything higher
[14:41] <cone-921> ffmpeg.git 03Ronald S. Bultje 07master:0b499c9b06b2: h264: Make it possible to compile without error_resilience
[14:41] <cone-921> ffmpeg.git 03Michael Niedermayer 07master:365ad0042a63: Merge remote-tracking branch 'qatar/master'
[14:42] <cehoyos> nevcairiel: Did you test this? (I can, but not atm)
[14:43] <nevcairiel> i know that i686 fixes it, i believe i saw wbs referring to i486 also unlocking it when the topic came up over there
[14:43] <cehoyos> Because in this case, it should be easy to fix, I don't think i386 support should be a primary concern.
[14:44] <iive> the kernel removed smp i386 support...
[14:45] <cehoyos> Wasn't i386 support actually removed? (not only smp)
[14:46] <nevcairiel> https://bugzilla.libav.org/show_bug.cgi?id=471
[14:46] <nevcairiel> there, a user tested --march=i486 and it worked
[14:53] <durandal11707> where are those unsupported samples which are actually just uncompressed video
[14:53] <cehoyos> durandal: Which samples do you mean?
[14:53] <cone-921> ffmpeg.git 03Michael Niedermayer 07master:79c845659afa: configure: the snow encoder is not supposed to depend on error resilience
[14:53] <cone-921> ffmpeg.git 03Michael Niedermayer 07master:07d405cc9ec4: configure: mpegvideo should not depend on error resilience
[14:54] <durandal11707> cehoyos: any which is unsupported but have fourcc such that is obvious it is uncompressed
[14:54] <cehoyos> Sorry, I don't understand (I thought you are maybe referring to the Hikvision samples)
[14:54] <durandal11707> what about gsoc task: rewrite libswscale (have this been mentioned already?)
[14:55] <cehoyos> Please don't!
[14:55] <cehoyos> Two fat trolls are really enough on this channel;-)
[14:55] <durandal11707> but current libswscale does not support 99% of interleaved yuv formats
[14:56] <cehoyos> Given that the usual protest is "it is too convoluted" I am not convinced this argument is 100% useful
[14:56] <durandal11707> and sure code can look much better
[14:57] <cehoyos> And I believe it should support formats that are output by compressed codecs and/or can be output on devices
[15:05] <durandal_1707> ubitux: heard about BS.1770 ?
[15:05] <ubitux> yes
[15:05] <ubitux> that's the basis for ebu r128
[15:07] <kierank> 13:56:03 <"durandal11707> but current libswscale does not support 99% of interleaved yuv formats --> ?
[15:07] <kierank> like what?
[15:07] <kierank> nv12, uyvy are supported
[15:08] <nevcairiel> all the stuff we have decoders for instead
[15:08] <nevcairiel> Y210 etc
[15:08] <cehoyos> Probably v210 ;-))
[15:08] <nevcairiel> oh yeah, it was v, not a Y
[15:08] <kierank> oh yeah the unaligned stuff
[15:10] <durandal_1707> and others for which we do not have decoders ...
[15:11] <kierank> i don't think there are many other yuv packings
[15:12] <durandal_1707> all interleaved variants of planar ones
[15:12] <cehoyos> nevcairiel: The user reports that i486 does not work (I will test myself, but not atm)
[15:13] <kierank> 14:12:41 <"durandal_1707> all interleaved variants of planar ones --> such as?
[15:19] <durandal_1707> kierank: see fourcc site
[15:20] <kierank> most of those are theoretical
[15:22] <cone-921> ffmpeg.git 03Carl Eugen Hoyos 07master:8af593dd8079: mpegtsenc: Only test the first frame for missing h264_mp4toannexb filter.
[15:22] <cone-921> ffmpeg.git 03Carl Eugen Hoyos 07master:1741fece7073: Only test the first frame for missing aac_adtstoasc bistream filter.
[15:28] <ubitux> huh?
[15:29] <durandal_1707> huh for what?
[15:29] <ubitux> i don't understand 1741fece very well
[15:30] <ubitux> cehoyos: a more explicit warning would have been welcome btw :p
[15:30] <cehoyos> Michael also wanted that but I am not sure I understand what is more explicit when remuxing than "invalid bitstream"
[15:32] <ubitux> i'm refering to "aac bitstream error"
[15:36] <cehoyos> nevcairiel: The user reports that -march=i686 does not work either
[15:37] <nevcairiel> dont trust a user =p
[15:38] <nevcairiel> --extra-cflags=-march=i686 ?
[15:39] <nevcairiel> or --arch=i686?
[15:39] <nevcairiel> aactually, it should be --cpu=i686 if you want to use configure's mechanism
[15:40] <nevcairiel> but extra-cflags should work
[15:40] <nevcairiel> unless their compiler is way too old
[15:40] <cehoyos> arch makes no difference here for a native Linux compilation, so I wonder what it will change on MSYS/mingw, I did not test the other yet
[15:41] <nevcairiel> --arch is wrong, it just switches between x86 and x86_64 .. --cpu should set the compiler -march option, and extra-clfags does the same
[15:42] <nevcairiel> --cpu=i686 should also make the build a bit faster because it enables some optimizations like cmov and fast_cmov based code
[15:44] <nevcairiel> or everything via --extra-cflags ;)
[16:40] <josetorn> Works perfectly for AV_SAMPLE_FMT_FLTP but AV_SAMPLE_FMT_S16P-->  int dataSize = swr_convert(resampleCtx, &resampledOut, AVCODEC_MAX_AUDIO_FRAME_SIZE,(const uint8_t**)decoded_frame.extended_data, (decoded_frame.linesize[0]) / (pCodecCtx->channels * 2)); av_fifo_generic_write(fifoPlayback,(uint8_t *)resampledOut,dataSize*pCodecCtx->channels*2,NULL);
[16:40] <josetorn> what am i missing here?
[16:41] <durandal_1707> that it is extremly unreadeable piece of code
[16:42] <josetorn> sorry, 1sec
[16:47] <josetorn> http://pastebin.com/MUCJRZbA
[16:47] <josetorn> this works perfectly for aac decoded data -> FLTP, but not mp3 decoded data AV_SAMPLE_FMT_S16P
[16:48] <durandal_1707> FLTP takes 4 bytes per sample and S16P 2 bytes
[16:49] <josetorn> i tried replacing "2" with "1" in (pCodecCtx->channels * 2) 
[16:49] <josetorn> but it didn't work too
[16:50] <durandal_1707> there is nice way to get number of decoded samples
[16:52] <durandal_1707> michaelni: what is most efficient way to calculate correlation between two arrays (in this case stereo audio) ?
[16:52] <durandal_1707> i found some dumb n! code
[16:55] <josetorn> To be used at the last parameter of swr_convert, the only way i know is (decoded_frame.linesize[0]) / (pCodecCtx->channels * 2)
[16:55] <josetorn> am i doing wrong by using linesize[0]?
[16:57] <durandal_1707> using linesize[] is certainly wrong because it is different for planar
[16:58] <durandal_1707> and number of decoder samples per channel is always available in lavc
[16:58] <josetorn> may you direct me to the right way?
[17:02] <durandal_1707> josetorn: are there examples in source itself?
[17:03] <durandal_1707> actually every decoded frame have nb_samples set
[17:13] <josetorn>  av_fifo_generic_write(fifoPlayback,(uint8_t *)resampledOut,dataSize*decoded_frame.nb_samples,NULL);
[17:13] <josetorn> this crashes the app
[17:14] <durandal_1707> because its wrong
[17:15] <josetorn> i have changed (decoded_frame.linesize[0]) / (pCodecCtx->channels * 2) with decoded_frame.nb_samples) as you've said, for swr_convert
[17:16] <durandal_1707> dataSize*decoded_frame.nb_samples ?
[17:17] <josetorn> i need the final dataSize, as it is the value given to me by swr_convert
[17:18] <durandal_1707> but why multiplication?
[17:21] <josetorn> ok. replacing line size etc.. with nb_samples and using  this worked: av_fifo_generic_write(fifoPlayback,(uint8_t *)resampledOut,dataSize*pCodecCtx->channels*2,NULL);
[17:21] <josetorn> however, this is same with the flip code.. so if flip is 4 bytes, this shouldn't have worked...
[17:21] <josetorn> flip = fltp
[17:22] <durandal_1707> your code is still so ugly that i do not want waste my time on it
[17:23] <michaelni> durandal_1707, correlation or cross correlation ?
[17:23] <michaelni> for correlation the naive solution is just O(n) anyway
[17:24] <durandal_1707> josetorn: in other words. it use variables to calculate some other variable which it should not - because it works only is special situations.....
[17:27] <josetorn> thank you very much durandal_1707 for your time, i will look more into this.
[17:35] <durandal_1707> michaelni: you can see "correlation code" in tau function in my jfmeter branch
[17:35] <durandal_1707> its copied from meterbridge
[17:36] <durandal_1707> the idea is that correlation is used to find out how much two channels differes 1 - mono,  -1 out of phase
[18:03] <durandal_1707> it mp ivtc filter useful at all?
[18:09] <wm4> probably not
[18:10] <wm4> let's say it in this way: unless like vf_gradfun etc., it has no fans
[18:11] <durandal_1707> remaining filters are more complicated and with inline assembly but with 0 users
[18:12] <durandal_1707> also why we have 2 equalization filters?
[18:12] <wm4> because mplayer had 2
[18:16] <durandal_1707> still have?
[18:18] <durandal_1707> eq2 have big lut16 table - this stinks as "micro optimization"
[18:18] <michaelni> durandal_1707, why dont you use a normal correlation coefficient that is sum (a[i]-b[i])^2 style ? but i think your tau function can be implemented in O(n log n) with a balanced  tree, dunno if theres a simpler/faster way 
[18:20] <durandal_1707> michaelni: as i already mentioned i stoled it from meterbridge, and i failed to find any other implementation (and i'm not motiviated to RE other pro tools to find out what they do)
[18:21] <durandal_1707> so i just search for pictures on web and try to cargo copy such tech (result may be good laugh)
[18:23] <durandal_1707> so expected result from function should be [-1, 1]
[18:24] <durandal_1707> 1 you get with mono source
[18:25] <durandal_1707> and -1 with phase out channels - when mixing them to produce mono you would get silence
[18:26] <ubitux> <@durandal_1707> it mp ivtc filter useful at all? // all the ivtc related filters in mp wrapper will be deleted soon©
[18:26] <ubitux> so ivtc, pullup, etc
[18:27] <ubitux> i just need to get done with my port
[18:27] <michaelni> durandal_1707, a normal correlation coefficient will also behave this way
[18:29] <wm4> I get s segfault in ff_mpeg_update_thread_context() when switching video tracks in a mp4/mpeg4 file
[18:29] <wm4> libav spams error messages like "get_buffer() cannot be called after ff_thread_finish_setup()" in this case (I'm not overriding get_buffer)
[18:30] <durandal_1707> perhaps you need to lock something
[18:30] <wm4> dunno if it's my fault, but one issue is that video switching basically feeds random packets to the decoder (random as in it doesn't start with the first packet the demuxer returns)
[18:30] <wm4> and it doesn't happen if I force 1 decoding thread (thread_count=1)
[18:32] <wm4> another error that happens on the start of track switching: "Context scratch buffers could not be allocated due to unknown size." (that's probably just the decoder being confused, so not an actual issue)
[18:32] <wm4> that's libav again (ffmpeg just segfaults)
[18:32] <wm4> it also happens only with this specific file
[18:33] <wm4> how to proceed?
[18:33] <wm4> I think ffplay or ffmpeg don't support this kind of track switching
[18:34] <durandal_1707> i see 2 new bug candidates
[18:34] <nevcairiel> sounds like you need flush the decoder
[18:35] <durandal_1707> wm4: actually ffplay can switch streams
[18:35] <wm4> nevcairiel: the decoder is recreated on track switching, so it starts in a fresh state
[18:36] <wm4> it just doesn't reset the demuxer
[18:36] <nevcairiel> demuxer demuxes all streams separetely, its your duty do pick the stream you want
[18:37] <wm4> my point is just that the decoder gets packets from the middle of the stream, which triggers the issue
[18:37] <wm4> normally, the decoder will barf some bad frames and then recover on video stream switching (heh)
[18:38] <mateo`_> Tjoppen: hello, would you like to review my mxfdec_j2ki branch before I submit it to the ml ? https://github.com/mbouron/FFmpeg/tree/mxfdec_j2ki
[18:43] <wm4> here's a sample, it might be possible to reproduce this with mplayer when setting the thread count: http://ompldr.org/vaHcydA
[18:44] <wm4> also I think I got this sample from samples.mplayerhq.hu, but I didn't find it again
[18:44] <michaelni> durandal_1707, that tau can be implemented with qsort() in n log n time i think
[18:48] <durandal_1707> michaelni: why sort?
[18:58] <michaelni> sorting the elements pairwise doesnt change the tau value this allows the problem to be simplified to 1 array instead of 2 (as the other array would be sorted then)
[18:59] <durandal_1707> but perhaps i actually need cross-correlation
[19:00] <michaelni> in a 2nd stage the remaining array can be solved by merging blocks recursively to get the tau value o think
[19:00] <michaelni> s/o/i/
[19:01] <michaelni> it ends with O(n log n) too like a tree but probably faster in practice due to higher overhead of trees
[19:02] <michaelni> for cross correlation theres the well known FFT based solution 
[19:13] <durandal_1707> michaelni: so its "n log n" vs "n * (n-1) / 2"?
[19:14] <michaelni> yes
[19:16] <michaelni> i think it also can be calculated in O(n*m) where m is the number of possible sample values, that is 2^16 for int16_t
[19:17] <michaelni> so if you have a really large n that would make it O(n) ...
[19:27] <llogan> michaelni: do you know if the ffmpeg server is subscribed to email blacklist services?
[19:27] <llogan> who is the admin anyway?
[19:29] <llogan> i tried sending a test message to ffmpeg-user from nabble using a non subscribed account and I got nothing in the mod queue (but not 550 5.7.1 message yet either).
[19:29] <michaelni> llogan, arpi is the one to speak with about mail on ffmpeg.org unless its something simple
[19:30] <llogan> as mentioned by email to ffmpeg-user-owner by michael rampe
[19:30] <michaelni> i think ive forwarded him this mail already though
[19:32] <llogan> ah, ok. also, i reply to most messages sent to -owner if you were wondering. i just don't always cc you for needless noise
[19:32] <llogan> i can if you prefer
[19:34] <michaelni> probably good idea to CC me, yes
[19:34] <michaelni> or owner
[19:35] <wm4> arpi is still active?
[19:37] <durandal_1707> hell no
[19:56] <saste> llogan, ping on the gsoc blurb
[19:57] <llogan> saste: i'll try to work on it today...i got too distracted over the weekend
[20:25] <Tjoppen> mateo`_: took a quick peek. looks OK I suppose. the field rate vs. frame rate thing still bothers me
[20:26] <Tjoppen> can we use some UL to differentiate the samples?
[20:37] <cone-921> ffmpeg.git 03Loren Merritt 07master:064146480b22: tools: add tiny_ssim
[20:37] <cone-921> ffmpeg.git 03Michael Niedermayer 07master:4c587b4f3003: tiny_ssim: Avoid "for(int ..."
[20:37] <cone-921> ffmpeg.git 03Michael Niedermayer 07master:7b3ca7ae8b51: mpegvideo/h264: drop period_since_free
[22:04] <cone-921> ffmpeg.git 03Michael Niedermayer 07master:46c48d546ddf: mpegvideo: fix null pointer dereference on switching streams
[22:22] <wm4> michaelni: was that commit for me? it works now
[22:22] <wm4> michaelni: and better than libav in this case
[22:23] <nevcairiel> speaking of this, the file you linked earlier only had one stream? :)
[22:24] <wm4> nevcairiel: doesn't matter, and you still can switch to no-video
[22:25] <nevcairiel> if the problem is simply starting payback mid stream, a seek should do I guess
[22:25] <nevcairiel> playback
[22:25] <wm4> sure, but the point is the decoder shouldn't crash on random input
[22:26] <wm4> and in libav, it never recovers
[00:00] --- Wed Mar 27 2013