I am trying to capture a screen shot on the ipad while the camera is on. My code looks exactly like the AVCaptureFrames from the Xamarin MonoTouch sample:
For some reason, though, I keep getting an Invalid Handler Exception. I have looked at other questions similar to mine, such as:
CGBitmapContext in MonoTouch throws invalid handle exception and "Invalid Handle" Create CGBitmapContext
But their solutions aren't solving my similar problem. My issue doesn't stem from a sending in null or because my memory is too large. I'm not sending in a null value and I checked my memory usage through the xcode allocations instrument and my memory usage doesn't explode; it only adds 400KB at the most.
Related
I am having issues with HLS playback using the media player library at least since v0.3.0 which continue until the current version (v0.5.0). I know the player library is in beta so I am wondering if others see what I see.
Basically, the issue manifests itself in such a way that, after some time, Chromecast device becomes unresponsive. The debugger stops showing any output, closing it and attempting to access it again results in a timeout error. Sometimes, after some time, device just crashes to homescreen (no brainfreeze).
I tried looking at the profiles and timeline before this happens and I don't see any unusual spikes. I did notice some errors in the log (but they could be unrelated to this), saying something like:
An attempt was made to use an object that is not, or is no longer, usable
The only "unusual" thing I am doing is that I broadcast status on every video timeupdate event. This does not cause any such issues in normal playback though.
Hoping that you already fixed that, I come with a workaround for people having the same problem.
I have a receiver streaming HLS (correctly encoded, using CORS headers and AES encryption). I noticed that sometimes the Chromecast goes crazy with huge segments (>25Mo) driving it to crash (almost) randomly when appending the latter segment.
Believing that I was probably asking too much of this small device, there are two solutions to lower the device load :
Disabling AES encryption (not always acceptable)
Reducing the segments quality
About solution 2, this works well :
window.host = new cast.player.api.Host({'mediaElement':mediaElement, 'url':url});
window.protocol = cast.player.api.CreateHlsStreamingProtocol( host );
window.host.getQualityLevel = function(streamIndex, qualityLevel){
var lowestQuality = protocol.getStreamInfo()["bitrates"].length-1;
var plusOneQuality = (qualityLevel == lowestQuality)?qualityLevel:qualityLevel+1;
console.log( "original QualityLevel : " + qualityLevel, "returned QualityLevel", plusOneQuality );
return plusOneQuality;
}
I'd love having some feedback about this. Does someone already had to use such a trick to prevent HLS HD streaming to crash the device ?
I have been trying to use OMXCodec through Stagefright. I have implemented the code for ICS version of Android.I have two classes CustomDataSource which derives MediaSource and another is CustomOmxCodec which calls OMXCodec::Create method and execute read operation to decode h264 frames. I have tested this implementation on a device with omx.google.video.avc software decoder and it works fine. Now, when I try to run the same implementation on an android phone with hardware h264 decode, it returns error on read call. The error is as below:
[OMX.MTK.VIDEO.DECODER.AVC] ERROR (0x80001005, 0)
0x80001005 is for OMX_ErrorBadParameter.
and I get the error code -1103 on read operation.
I tried various parameters but no success.
The complete log is as below:
[OMX.MTK.VIDEO.DECODER.AVC] mVideoInputErrorRate (0.000000)
!##!>>create tid (21087) O<XCodec mOMXLivesLocally=0, mIsVideoDecoder (1), mIsVideoEncoder (0), mime(video/avc)
[OMX.MTK.VIDEO.DECODER.AVC] video dimensions are 640X480
mSupportesPartialFrames 1 err 0
[OMX.MTK.VIDEO.DECODER.AVC] allocating 10 buffers of size 65536 on input port.
[OMX.MTK.VIDEO.DECODER.AVC] mMemHeapBase = 0x00E8C288, mOutputBufferPoolMemBase=0x51F8E000, size = 9578848
[OMX.MTK.VIDEO.DECODER.AVC] ERROR (0x80001005, 0)
OMXCodec::onEvent--OMX Bad Parameter!!
Read Error : -1103
I'd grateful for any direction on this.
From the question, the hardware codec i.e. OMX.MTK.VIDEO.DECODER.AVC is not supporting one of the parameters being passed as part of the configuration steps.
From OMXCodec::create, configureCodec will be invoked which internally invokes a lot of other functions. Since the error is coming as part of OMXCodec::onEvent, one of the possible scenarios could be that the component encountered an error while decoding the first few bytes of the first frame.
Specifically, when the component encounters SPS and PPS (part of codec specific data), the component would typically trigger a portSettingsChanged. From your response, I feel that during this process, there is some error and hence, onEvent has been triggered.
Please share more logs to analyze further.
The MTK H264 decoder need the parameter csd-0 and csd-1 to init the decoder(You can get some information at http://developer.android.com/reference/android/media/MediaCodec.html). csd-0 and csd-1 stands for SPS and PPS of H264.I have asked a MTK engineer and he said that we can use the code below to set these two parameters.
byte[] sps = {0,0,0,1,103,100,0,40,-84,52,-59,1,-32,17,31,120,11,80,16,16,31
,0,0,3,3,-23,0,0,-22,96,-108};
byte[] pps = {0,0,0,1,104,-18,60,-128};
MediaFormat mFormat = MediaFormat.createVideoFormat("video/avc", width, height);
mFormat.setByteBuffer("csd-0", ByteBuffer.wrap(sps));
mFormat.setByteBuffer("csd-1", ByteBuffer.wrap(pps));
Maybe that's whay we got the OMX Bad Parameter error message.
From the logs and mapping the same to the implemented code, I feel that the following is happening
[OMX.MTK.VIDEO.DECODER.AVC] allocating 10 buffers of size 65536 on input port.
This step allocates the buffers on the input port of the decoder
From the flow of code, after input port buffers are allocated, the buffers on output port are allocated from nativeWindow through allocateOutputBuffersFromNativeWindow.
One of the steps as part of this method implementation is to increase the number of buffers on the output port by 2 and set the same to the OMX component as shown here.
I feel your error might be stemming from this specific point as nBufferSize is a read-only parameter of OMX_IndexParamPortDefinition index. Please refer to the OMX Standard, section 3.1.3.12.1, page 83, which clearly shows that nBufferSize is a read-only parameter.
It appears that your OMX component may be strictly OMX compliant component, whereas in Android from ICS onwards, certain deviations are expected. This could be one of the potential causes of your error.
P.S: If you could share more information, we could help further.
I noticed an odd memory increase in one of my Activities. Hence I ran a little test: I opened the dialog multiple times (open - close - open - close ....) and the memory kept increasing. So I used the DDMS to dump an HPROF file and opened it in MAT (Memory analyzer). The leak suspect report indicated, that the main reason for the growing memory consumption was this:
So I did a histogramm, to check that dialog I ran my tests on and what's keeping it alive. Turns out, it's kept alive by it's AutoCompleteTextViews, which in turn are kept alive by android.widget.TextView$IClipboardDataPasteEventImpl. However there are no immediate dominators for IClipboardDataPasteEventImpl (except of course the GC Root). I tried to find that IClipboardDataPasteEventImpl on the internet and I searched grepcode (the android source), but the only thing I could come up with was this blog entry. I can't read whatever language that is, but what I could read are the English words thrown in, which indicates, that it might be a bug on the Samsung Galaxy SII (the phone I am using, running android 2.3.x), related to the ClipboardManager. However I am unsure of this (I want to fix this, hence I am disinclined to simply accept it to be an unfixable bug) and I have no clue, where this Clipboard is spawned and why. I would greatly appreciate any pointers/ideas on the matter.
Investigation
Here're my research results:
It happens to any Activity whose content view consists of an EditText. finish()ing the Activity does not get it garbage collected as it is being referenced, like this:
activity com.example.MyActivity
<- mContext android.widget.TextView
<- this$0 android.widget.TextView$IClipboardDataPasteEventImpl
<- this$1 android.widget.TextView$IClipboardDataPasteEventImpl$1
<- referent java.lang.ref.FinalizerReference
It happens on my Samsung Galaxy Tab GT-P7300 running Android 4.0.4, but not on my Samsung Galaxy Mini GT-S5570 running Android 2.2.1.
The IClipboardDataPasteEventImpl objects eventually get freed, actually, but only at times which seems to be unpredictable.
Since they are referenced by java.lang.ref.FinalizerReference, I believe that the IClipboardDataPasteEventImpl objects are waiting to be finalize()'d, which happens only when the JVM feels like to. For details, check out these SO questions:
is memory leak? why java.lang.ref.Finalizer eat so much memory
Very strange OutOfMemoryError
Solution / Workaround
Sorry, no solution, but here's my best workaround:
In onDestroy() of your Activity, free as many references to other objects as possible (especially the big ones, such as bitmaps, collections, and child views of your activity), like this:
#Override
protected void onDestroy()
{
// Free reference to large objects.
m_SomeLargeObject = null;
m_AnotherLargeObject = null;
// For ArrayList, if you are a paranoid to null, you may call clear() and then trimToSize().
m_SomeLargeArrayList.clear();
m_SomeLargeArrayList.trimToSize();
// Free child views.
m_MyButton = null;
// Free adapters.
m_ListViewAdapter = null;
... etc.
// Don't forget to chain the call to the superclass.
super.onDestroy();
}
This way, we can at least reduce the casualties and hopefully won't go out of memory before the JVM has the mood to finialize and collect all those evil IClipboardDataPasteEventImpl objects.
In an ideal world of garbage collected environment, this would be unnecessary, but I guess we should all realize that our world is not perfect, and we just have to live with the flaws.
Below is my translation of the original blog entry (in Chinese) as mentioned in the question. Hopefully this can give everybody a better understanding about the issue.
Galaxy S2 memory leak with TextView
不知道是不是哪邊弄錯
Not sure where it went wrong
但是galaxy s2的textview會產生memory leak
But the textview of galaxy s2 causes memory leaks
leak是發生在android.widget.TextView$IClipboardDataPasteEventImpl這個interface上
Leak happens on the interface android.widget.TextView$IClipboardDataPasteEventImpl
它會抓住mContext造成整個activity沒辦法被gc
It holds the mContext, stopping the activity from being gc'ed
同樣的程式在htc sensation(2.3.4)跟se xperia arc(2.3.4)和acer liquid(2.1)都沒有問題
No such problem with the same app on htc sensation(2.3.4), se xperia arc(2.3.4) and acer liquid(2.1)
而且網路上完全找不到android.widget.TextView$IClipboardDataPasteEventImpl相關的資料
And, I can't find anything related to android.widget.TextView$IClipboardDataPasteEventImpl on the web at all
android source code裡也找不到 看起來應該是samsung自己加的東西...
Not even in the android source code, so it seems to be something added by samsung themselves...
之前的opengl viewport bug 已經夠頭痛了 接下來soundpool相關bug也搞累很多人
The opengl viewport bug was a headache already, and the soundpool related bug had frustrated many
現在這個memory leak又來攪局...
And now, here comes a memory leak messing around...
看來手機外型還是比較重要 /_\... 外型好先吸到人來買 bug再慢慢修就好
Seems that the appearance of mobile phones are more important /_\... good appearance attracts customers; bugs could be fixed later
[後記]
[P.S.]
經過一些試驗發現 只要按HOME button回到桌面，那些leak就會被釋放掉...
After some tests, I found out that the leaks will be freed by pressing the HOME button to go back to the desktop...
logcat會顯示一行Hide Clipboard dialog at Starting input: finished by someone else... !
It shows Hide Clipboard dialog at Starting input: finished by someone else... ! in logcat
看起來galaxy s2裡面有偷偷對clipboard作一些操作...
It seems that galaxy s2 is operating on the clipboard under the hood...
但如果一直保持在app裡面運作的話，那些leak還是會存在...最後應該會發生OOM exception
But if we stay in the app, those leaks remain... eventually an OOM exception would occur
現在只能期望galaxy s2 的ics版會修掉這個怪問題了...
Now we can only hope that this strange problem would be resolved in the ics version of galaxy s2...
My memleak investigation also brought me here. Im having problems with Activity leaking over EditText. android.widget.TextView$IClipboardDataPasteEventImpl object is holding the EditText which is holding the activity. This happens on Samsung Galaxy Tab 10.1, and Galaxy Tab 2 10.1, 7.0. I wasn't able to reproduce it on other non Samsung devices (Asus, Acer).
The bad thing is that I didn't find a solution for it yet :)
I have Windows CE 6 running an Atom N270 with an Intel 945GSE chipset. I wrote a small test application for Direct3D Mobile and have been experiencing some strange behaviour. I can only call Draw*Primitive once per frame. Calling multiple times either results in a white screen as though Present failed (even though no error is given) or only the first call seems to be processed.
With the message handling omitted the body of the render loop is as follows:
HandleD3DMError(pD3DMobileDevice->Clear(0,0,D3DMCLEAR_TARGET | D3DMCLEAR_ZBUFFER ,0xA50AB0F,1.0f,0),_T("Clear"));
if(HandleD3DMError(pD3DMobileDevice->BeginScene(),_T("BeginScene")))
{
HandleD3DMError(pD3DMobileDevice->SetTexture(0,pTexture), _T("SetTexture"));
HandleD3DMError(pD3DMobileDevice->SetStreamSource(0,m_pPPVVB[0],sizeof(PrimitiveVertex)),_T("SetStreamSource Failed"));
HandleD3DMError(pD3DMobileDevice->SetIndices(pIndexBuffer),_T("SetIndices failed"));
HandleD3DMError(pD3DMobileDevice->DrawIndexedPrimitive(D3DMPT_TRIANGLELIST,0,0,NUM_TRIS*3,0,NUM_TRIS/2),_T("Draw Primitive 1"));
//HandleD3DMError(pD3DMobileDevice->DrawIndexedPrimitive(D3DMPT_TRIANGLELIST,0,0,NUM_TRIS*3,NUM_TRIS/2 * 3,NUM_TRIS/2),_T("Draw Primitive 2"));
HandleD3DMError(pD3DMobileDevice->SetStreamSource(0,0,0),_T("SetStreamSource Null Failed"));
HandleD3DMError(pD3DMobileDevice->SetIndices(0),_T("SetIndices Null failed"));
HandleD3DMError(pD3DMobileDevice->EndScene(),_T("EndScene"));
}
HandleD3DMError(pD3DMobileDevice->Present(0,0,0,0),_T("Present Failed"));
You can switch the two DrawIndexedPrimitive() lines and both render four triangles each, which is correct. However when they are both present nothing is rendered. The HandleD3DMError() function displays a message box when an error occurs. This is done all through initialisation too. No errors are displayed at any time.
I have tried drawing different primitive types and drawing non-indexed vertex buffers with no success. I am able to draw 10,000 triangles using a single buffer but trying to use multiple buffers fails (I assume it is related to the multiple Draw calls issue).
The documentation on MSDN does not mention any limitation on Draw calls. They even mention cases where you would need to make multiple Draw calls. The official samples I've looked at
only ever call Draw*() once per frame too.
If I try and BeginScene() and EndScene() multiple times in the one frame nothing is rendered, not even the cleared colour.
I can provide all of the source if needed.
I appreciate any help anyone can give me.
Cheers
I have a program that when run compiled with Microsoft Visual C++ 2008 Express crashes on the line
comparison_vectors = new vec_element[(rbfnetparams->comparison_vector_length)+1];
with the error Unhandled exception at 0x7c93426d in myprog.exe: 0xC0000005: Access violation reading location 0x00000000
rbfnetparams->comparison_vector_length evaluates to 4 (should do and checked in the debugger), and the thing still crashes here when I change the line as a test to:
comparison_vectors = new vec_element[5];
vec_element is a structure with several ints, doubles and a few bools, but no methods or constructor. The thing runs if I replace new with malloc, but then crashes on another new elsewhere. It does not crash every time this line is run, only sometimes, but seems to do so after the same number of iterations of this line each time. Memory usage is only 10MB at this point in the program.
This gets stranger as the same program DOES compile and run under gcc on Solaris, which usually shows up far more errors than Windows does.
Any help would be appreciated, as I am at a loss as to how to debug this one.
Access violation reading location 0x00000000 means "you dereferenced a NULL pointer." It looks like once in a while rbfnetparams is NULL when you reach this line, and thus you get the error.
I can't explain why comparison_vectors = new vec_element[5]; crashes. Is it the same error message?
Check if rbfnetparams is NULL before the line, and see if it gets hit (or add a conditional break point). Then decide if the fact that rbfnetparams is NULL is a symptom of a bigger bug somewhere else.
Dereferencing a NULL pointer is undefined. It's possible that the Solaris compiler does an optimization that masks the bug. That's allowed by the Standard (read the whole series referenced from that post).