Hi,
with WiMo i was able to play podcasts (h264/aac, 368x208, ~200kBit/s) somewhat smooth with TCMP. With android i get - well - with some luck a frame per minute. I would have said its because of a incomplete/non-optimized GPU-Driver but Youtube (SD) plays fine so for me this looks more like a codec/app-issue. Has anyone already looked for a solution? Any tips on codecs/apps that should work?
SD works, yes. HD/HQ youtube does not however, and I think it's related to a scaling issue.
We're not done with the port... I think this is a pretty minor bug considering the other major ones we have out there....
arrrghhh said:
SD works, yes. HD/HQ youtube does not however, and I think it's related to a scaling issue.
Click to expand...
Click to collapse
...hm… for me exactly this looked like a codec-thing… i dont know the mobile side but for pc i remember something like VP6 for SD and X264 for HD on Youtube. But thanks for the tip, i'll look into this direction too.
arrrghhh said:
We're not done with the port...
Click to expand...
Click to collapse
…and it will never be completely done - otherwise there would be no need for our lovely legacy-forums here
arrrghhh said:
I think this is a pretty minor bug considering the other major ones we have out there....
Click to expand...
Click to collapse
As you already said in another thread: Everyone has his own priorities
Just see this thread as my notepad - i collect my results/ideas here, if someone has made own tests he can add his results and if someone wants to have a look on his own he knows what has been tried already…
B2T: With the described movie i have about 10-20% free CPU-cycles so this should not be the bottleneck. hw3d has no effect (guess this doesnt really affect 2d acceleration). Changing from fullscreen/stretched to original size showed also no difference
adlerweb said:
Just see this thread as my notepad - i collect my results/ideas here, if someone has made own tests he can add his results and if someone wants to have a look on his own he knows what has been tried already…
B2T: With the described movie i have about 10-20% free CPU-cycles so this should not be the bottleneck. hw3d has no effect (guess this doesnt really affect 2d acceleration). Changing from fullscreen/stretched to original size showed also no difference
Click to expand...
Click to collapse
Not a bad idea, I'd like to see this bug squashed.
I've heard it was a scaling issue - have you tried different resolutions? I know someone tried the native resolution of our RHOD, but that didn't work either... I guess I'd be surprised if it is codec, as you can get frozen frames on YouTube HQ and audio plays just fine. I am by no means an expert here tho .
arrrghhh said:
Not a bad idea, I'd like to see this bug squashed.
I've heard it was a scaling issue - have you tried different resolutions? I know someone tried the native resolution of our RHOD, but that didn't work either... I guess I'd be surprised if it is codec, as you can get frozen frames on YouTube HQ and audio plays just fine. I am by no means an expert here tho .
Click to expand...
Click to collapse
I am no expert either but would not the codec be contained in the software such as Utube. And the Multimedia architecture would mostly bypass the Processor. So the problem to me would seem to be routing and timing issue. Thus the beggining frames play but stop due to the loss of coordination.
BigOnes69 said:
I am no expert either but would not the codec be contained in the software such as Utube. And the Multimedia architecture would mostly bypass the Processor. So the problem to me would seem to be routing and timing issue. Thus the beggining frames play but stop due to the loss of coordination.
Click to expand...
Click to collapse
I don't even get any frames to play at the beginning.
It starts with a black screen with audio...
If I skip ahead, I can randomly get freezes of images, but that's about it.
arrrghhh said:
I don't even get any frames to play at the beginning.
It starts with a black screen with audio...
If I skip ahead, I can randomly get freezes of images, but that's about it.
Click to expand...
Click to collapse
What you say supports what I am saying about routing and timing. I am thinking in general terms not specifics and I am no expert.
BigOnes69 said:
What you say supports what I am saying about routing and timing. I am thinking in general terms not specifics and I am no expert.
Click to expand...
Click to collapse
I would think its the processors job to coordinate the frame of reference for the timing. The actual MMS stuff would use that frame of reference to process the video according to the codec provided in the software. The routing and or timing could be screwed because HTC needs a way to get around patent laws. The could have done something as simple as changed polarity or phase or something more complicated as recode with another chip. The audio would works because its simple to process. Our drivers are not doing what needs to be done to process the information. It would have nothing to do with the codec which is contained in the software. Like I said I am guessing.
BigOnes69 said:
I would think its the processors job to coordinate the frame of reference for the timing. The actual MMS stuff would use that frame of reference to process the video according to the codec provided in the software. The routing and or timing could be screwed because HTC needs a way to get around patent laws. The could have done something as simple as changed polarity or phase or something more complicated as recode with another chip. The audio would works because its simple to process. Our drivers are not doing what needs to be done to process the information. It would have nothing to do with the codec which is contained in the software. Like I said I am guessing.
Click to expand...
Click to collapse
Then again the Architecture in our older phones might not be fast enough to process the HQ resolutions.
No, this isn't a question of processing power, it's a matter of having the right codecs installed. I've seen Youtube HQ working on my phone before, running one of tiad8's FroyoX builds with camera kernel, months ago.
The behavior you see where you can skip around and see one good frame, but otherwise nothing, is caused by the actual encoding of the video, and the current codec lacking support for it. (The difference between B frames, I frames, and P frames, if you care to look that up...)
highlandsun said:
No, this isn't a question of processing power, it's a matter of having the right codecs installed. I've seen Youtube HQ working on my phone before, running one of tiad8's FroyoX builds with camera kernel, months ago.
The behavior you see where you can skip around and see one good frame, but otherwise nothing, is caused by the actual encoding of the video, and the current codec lacking support for it. (The difference between B frames, I frames, and P frames, if you care to look that up...)
Click to expand...
Click to collapse
Interesting.
So what do we need to do to get the codec support? I'm assuming the kernel clocks are finally right as well...
found it.
http://www.youtube.com/watch?v=mYW1DIi4ZzY
yankees2450 said:
found it.
http://www.youtube.com/watch?v=mYW1DIi4ZzY
Click to expand...
Click to collapse
That is based off of Tiads cut and paste Blazn if I am correct which was good for video playback but everything else was buggy. This proves HQ can work on our phones.
My question here is wouldnt the Codec that was required by the utube app. be contained within that app. or if it was not when it tried to play back and the codec was missing you would get nothing or a reference to download the required codec such as happens with other operating systems.
Or if the codec is contained in our current version intact. Then it is not referencing the codec properly which goes back to what I originally said about timing and the coordination with the MMS architecture on the phone. It looks as though Tiad had found the proper channeling. Did he leave anyone any information about this before he left this forumn?
BigOnes69 said:
That is based off of Tiads cut and paste Blazn if I am correct which was good for video playback but everything else was buggy. This proves HQ can work on our phones.
My question here is wouldnt the Codec that was required by the utube app. be contained within that app. or if it was not when it tried to play back and the codec was missing you would get nothing or a reference to download the required codec such as happens with other operating systems.
Or if the codec is contained in our current version intact. Then it is not referencing the codec properly which goes back to what I originally said about timing and the coordination with the MMS architecture on the phone. It looks as though Tiad had found the proper channeling. Did he leave anyone any information about this before he left this forumn?
Click to expand...
Click to collapse
He never gave anyone anything useful from his builds.
He was just slapping stuff together, and would see what stuck to the wall.
I heard people had issues with his builds on HQ youtube, and I even tested his junk and wasn't able to get HQ to work... so I think it's just more BS from him.
yankees2450 said:
another junk from tiad8
could this be true?
http://www.neopeek.com/viewtopic.php?f=84&t=6544
Click to expand...
Click to collapse
There's a reason he's banned here. Let's not repost more of his crap here, thanks.
arrrghhh said:
I've heard it was a scaling issue - have you tried different resolutions?
Click to expand...
Click to collapse
Well... Most of my podcast have different resolutions and none worked so far. Also should scaling not be disabled when the Player is set to "original size"?
BigOnes69 said:
I am no expert either but would not the codec be contained in the software such as Utube.
Click to expand...
Click to collapse
I dont know for youtube but most 3rd party video-players i've seen say that supported codecs are device dependent so i guess they are in the rootfs, not the app.
BigOnes69 said:
because HTC needs a way to get around patent laws
Click to expand...
Click to collapse
OK, maybe, but afair do most companys not charge people/companys for playback - only encoding… And "free" codecs like theora or webm would not be affected
BigOnes69 said:
Then again the Architecture in our older phones might not be fast enough to process the HQ resolutions.
Click to expand...
Click to collapse
As said: 20% cpu left and works on Wimo -
I've managed to get "working" video with ffmpeg's default avi-output (think it was divx/mp3) but colors where disorted. My android died yesterday and i had no time to reinstall so i could not test further atm.
adlerweb said:
OK, maybe, but afair do most companys not charge people/companys for playback - only encoding… And "free" codecs like theora or webm would not be affected
Click to expand...
Click to collapse
I think I remember reading the issue the with getting decent video playback wit the MSM GPU is is getting information on the hardware. The codec used to play HQ video on Windows mobile comes from HTC and is written specifically for the MSM7x chipset using proprietary information - information which is not available to everyone, or can only become available for a price and an NDA.
Perhaps there is binary blob that can be used?
toadlife said:
I think I remember reading the issue the with getting decent video playback wit the MSM GPU is is getting information on the hardware. The codec used to play HQ video on Windows mobile comes from HTC and is written specifically for the MSM7x chipset using proprietary information - information which is not available to everyone, or can only become available for a price and an NDA.
Perhaps there is binary blob that can be used?
Click to expand...
Click to collapse
Perhaps a binary blob could be dug up, but we couldn't use it in the AOSP builds. Only custom builds would be able to use it, or individuals will just have to integrate it themselves.
arrrghhh said:
Perhaps a binary blob could be dug up, but we couldn't use it in the AOSP builds. Only custom builds would be able to use it, or individuals will just have to integrate it themselves.
Click to expand...
Click to collapse
That would be fine with me.
toadlife said:
That would be fine with me.
Click to expand...
Click to collapse
Ok... My point is, source is preferred.
If we can't get source, so be it - but a proprietary blob does very little good in the scope of this type of project. I want everyone to have the best Android experience possible, I don't want just a few builds working correctly and others borked. That sucks.
Looking for a RAW capture with Android camera.
I am trying with Xperia X10 camera to capture RAW image, now it has got Android 2.3.3 and APIs are available.
Couldn't get it though.... Can anybody shed a light on it?
Also, is there any API or lib or .so which I can play around... I promise I will share all my knowledge here
Thanks in advance.
I second this request I would also like to shoot raw photos on my droid. I dont like JPG its an awful format.
I think it is related to camera hardware and not software. As I know, only one windows mobile phone from HTC can shoot and save as raw.
If you want to have a better quality, you can increase the image quality or just keep it as 100% original in media_profile.xml
Accidentally sent from my Nexus S using XDA Premium App
Its likely a low level driver thing. Which like modems, the manufacturers don't release the source for.
+1 on this.
shooting raw will be a super feature for photography savvy users.
especially that almost all in-phone processings are extremely suck.
Raw capture is availible on micromax a90s android 4.2.2 in engineering mode
Has there been any update on this. I see heaps of articles of google announcing this but thought itd be out now.
mitalbr said:
Looking for a RAW capture with Android camera.
I am trying with Xperia X10 camera to capture RAW image, now it has got Android 2.3.3 and APIs are available.
Couldn't get it though.... Can anybody shed a light on it?
Also, is there any API or lib or .so which I can play around... I promise I will share all my knowledge here
Thanks in advance.
Click to expand...
Click to collapse
As far as i know, only android lolipop has the ability to capture raw images. You have to upgrade to android 5.0 to capture raw image from your phone's camera. Its android Lcamera. It is an experimental app and will work fine if the hardware of our camera supports all the functions of camera.
Here's what I want to do: I'd like to be able to take multiple videos throughout the day and then at the end of the day join them together as one video to upload to YouTube.
Here's the problem: I can't join videos together that are VFR (variable framerate). They need to be converted to CFR first. However, no matter how I try converting them, I always end up with audio/video sync problems. I've spent days and done lots of research and tested several programs/methods to accomplish this. There's still more for me to try, but so far I've not been successful.
Which brings me back to: If I can just get the RAZR to record videos with a constant framerate, the above problem(s) should be eliminated.
My current favorite camcorder app is the LG Camera ("LG" having no relation to the electronics manufacturer). It has many options and blah blah blah. One of the options is to set the framerate. Offers selections as low as 2 FPS up to 60 FPS. Unfortunately (and I have emailed the dev about this), changing this setting doesn't seem to have any effect.
This could be because of a firmware limitation of the device itself, or it could simply be a bug with the app. I don't know yet. I'm trying to find out.
I did find another post around here about recording videos at 120 FPS or something like that. Seems that making some edits to the build.prop file made the phone think it was recording at that FPS but the resulting file showed otherwise. Well, I'm not looking for any real high FPS for my videos. I figure somewhere around 30 should be good enough. The only thing I really want to know is if there is any possible way I can force the camera to record at a constant framerate.
Perhaps the build.prop file can be edited to allow this. I'm not sure. I certainly hope this is possible one way or another, though.
Thanks for your time.
I was one of the people doing the 120fps experiments, and as you noted, nothing worked. I'm thinking the cpu is simply sending a stream of data that the phone must accept.
I'm pretty sure the phone records in a variant of motion jpeg, and simply takes up to 30 stills per second. I've edited these files myself, and it's a pain in the a**.
You need to find a setting in your video editing app that allows for variable framerate content. VFR for short.
Also, .avi containers doesn't support VFR content. You need to save to MKV, MP4, WMV or ASF. Probably more containers, but those are common.
Thanks for the response.
Well, bad news and good news.
Bad news is, I was never able to find any program that could properly convert and/or join the video files without blatant sync problems as a result.
The good news is that the above is not 100% true. After posting my question, I had received some help elsewhere and ended up using ffmpeg and MEncoder (both command line tools for video processing). ffmpeg converts the files to CFR and then MEncoder joins them together. These two utilities combined with the automation power of AutoHotkey allowed me to create an AHK script that will convert and join all the videos successfully simply by dropping the files in the folder and running the script.
In the rare case someone else comes here with the same problem, here's the video-help thread that brought me to this solution: ~~~ Okay, I can't post links. In that case, here's a sample command line for converting the file to CFR:
Code:
ffmpeg -i input01.mp4 -c:v mpeg4 -b:v 1800k -c:a copy -vsync 1 -r 25 temp_output01.mp4
You'll have to run ffmpeg separately on each file, I believe.
Here's a sample MEncoder command line for joining the converted files together:
Code:
mencoder input01.mp4 input02.mp4 input3.mp4 -vf harddup -ovc copy -oac mp3lame -lameopts cbr:br=128 -o joined_output.mp4
You can enter in as many input video filenames as you want to join together.
After I found a solution for converting and joining, I decided to leave this post up because I still wanted to find out if recording in CFR on the Droid was possible. I'm guessing it isn't. That's too bad.
I read about that actually, problem is that directly converting to CFR makes the video somewhat choppy. As you are either playing the same frame twice, or removing a frame to compensate for the fps you're using.
If I'm not too confused, you can interpolate the missing frames to make it appear smoother. At least in some video editors.
Yeah. Fortunately, so far I haven't noticed any obvious issues with the final video.
Hi all,
I've got a Lenovo Pad Pro 11 on which I've installed ZUI 14 (Android 12) and have also got it fully rooted with boot loader unlocked.
I have a usb video capture device which I use as a USB Camera to stream from my PC, and I want to make it the default camera device when I launch the camera app, so when I go on live in insta or TikTok or twitch for example, it's recognised as the default camera rather than using the onboard camera from the tablet. I understand this may involve some system file tweaking but I find it a bit too complicated to understand.
Could anyone provide some guidance or tips on how to do this?
Thank you
Unfortunately, this is near impossible (unless modifying the source and compiling it yourself) due to Androids camera system where every camera has its own id (0 for the primary rear camera and 1 for the primary front camera).
What you would need is to modify the source so that the OTG Camera is emulated as an integrated camera. I am not an expert in that field and can as such not give directions on how to do that.
I would recommend starting by reading the Android Source documentation.
Good luck and let us know if you find a solution.