I have been playing around getting TCPMP to compile in VS2008, it now builds and runs.
These new builds have 2 main advantages over the original builds:
1) They run on the latest Windows Mobile 6.1 ROMS where the original build crashes (crash.txt message).
2) They support the FLV format straight out of the CAB.
On the Kaiser you must use 'GDI' or 'Raw FrameBuffer' for decent performance, unless you have the latest WM6.1 roms which have Directdraw working at a reasonable pace.
Changelog
recomp-02
Added MPEG4.PLG from source found in TCPMP 0.66
FFMPEG updated
recomp-03 - 27/5/08
Installs and runs on WM2003 devices
Detects Kaiser, allows 'Direct' video output
Source zip now has ASM files
Small optimizations
Source Code - For Developers ONLY
The latest modified source for TCPMP and the VS2008 project is here:
http://rapidshare.de/files/39538681/tcpmp-0.72rc1-src-vs2008.zip.html
ffmpeg.plg needs avcodec-51.dll and avutil-49.dll, couldn't get it to work linked in. The DLL's were built from the source available here:
http://ffmpeg.mplayerhq.hu/download.html
To get the ARM optimized assembler parts linked in your need to build it using CEGCC:
http://cegcc.sourceforge.net/
On Cygwin on Windows:
http://www.cygwin.com/
Using these configure options:
./configure --enable-memalign-hack --target-os=WinCE --arch=arm --cross-compile \
--cross-prefix=arm-wince-mingw32ce- --enable-small \
--enable-static --enable-shared --disable-mmx --disable-zlib --disable-ipv6 --disable-debug \
--disable-ffmpeg --disable-ffserver --disable-ffplay \
--disable-encoders --disable-network --disable-muxers --disable-decoders --disable-filters \
--disable-demuxers --disable-devices --disable-protocols --disable-bsfs --disable-parsers \
--enable-decoder=h263 --enable-decoder=mpeg4 --enable-decoder=flv --enable-decoder=flv1 \
--enable-decoder=h264 --extra-cflags="-march=armv4 -mtune=xscale"
libmad.plg was built in CEGCC with libmad linked in, using these configure options:
CFLAGS="-march=armv4 -mtune=xscale" ./configure --host=arm-wince-mingw32ce --enable-speed --enable-fpm=arm
I stopped doing this as it added little speed, now just compiled in VS2008.
Things done so far:
1) Fixed all warnings
2) Built a new installer
3) Built in the small changes made to the FFMPEG plugin that allow .FLV (flash videos) to play that were available as separate plugins, this is now built into the ffmpeg.plg and splitter.plg. The code was from: http://sourceforge.net/project/showfiles.php?group_id=201449
4) Turned on all compiler optimizations in VS2008 - FLV playback is 10% faster than original build on my Kaiser.
5) Tided up some projects, not tested Win32 or Smartphone builds, just Pocket PC.
6) FFMPEG used in ffmpeg.plg updated to latest CVS build from March 2008 sometime and compiled with CEGCC and all ARM optimizations. Now in a DLL for easy updating.
7) Found some source from the 0.66 version TCPMP that still had the Core mpeg4.plg code in and got it to compile with 0.72. Now the normal MPEG4 & H263 decoding is nearly as fast as the original builds.
The new FFMPEG build adds another 5-10% speed to FLV decoding and also opens up the possibility to decode all the new formats FFMPEG can decode.
I really want to find out the specs for QTV.dll on the Qualcomms to get the same speed boost as Coreplayer has. If anyone can help please let me know.
CAB Download
COOOL thanks
lol
Jaaaaaaaa, danke
i need to ask: will original tcpmp plugins(wmc etc) work with that one?
there are more plugins that you included in cab.
(screen from my pack..)
http://i28.tinypic.com/a3mdfo.gif
(no accelerators' plugs, tho)
upd: sweet lord, avi benchmark and playback is sooo slow on wizard..
lol, almost 40% LESS score...
flv playback seems to be ok, tho.
nothin said:
i need to ask: will original tcpmp plugins(wmc etc) work with that one?
there are more plugins that you included in cab.
(screen from my pack..)
http://i28.tinypic.com/a3mdfo.gif
(no accelerators' plugs, tho)
upd: sweet lord, avi benchmark and playback is sooo slow on wizard..
lol, almost 40% LESS score...
flv playback seems to be ok, tho.
Click to expand...
Click to collapse
You can use the MPEG4.plg and MP3.plg from the original build, this will make AVI(Xvid) playback as speedy as before. I said this in the original post.
This is not for general use unless you just want FLV playback or you have a PDA where the original build crashes (some Kaiser roms). This is for people to continue developing, something that actually builds straight off. What it really needs is someone who knows some newer codec libraries to build them in as new plugins.
thank you,
hopefully this will help resume tcpmp development.
dosn't work flv playback on my p3300
milesmowbray said:
You can use the MPEG4.plg and MP3.plg from the original build, this will make AVI(Xvid) playback as speedy as before. I said this in the original post.
This is not for general use unless you just want FLV playback or you have a PDA where the original build crashes (some Kaiser roms). This is for people to continue developing, something that actually builds straight off. What it really needs is someone who knows some newer codec libraries to build them in as new plugins.
Click to expand...
Click to collapse
ok, i was reading that at 03:20 AM..you know..
do not have subtitle plugin...
Frisk1025 said:
do not have subtitle plugin...
Click to expand...
Click to collapse
Nor did the original build did it?
see first post
for youtube?
biogrei said:
for youtube?
Click to expand...
Click to collapse
For YouTube and all the formats that the original TCPMP supports.
milesmowbray said:
Right, new version:
1) FFMPEG used in ffmpeg.plg updated to latest CVS build from last week sometime and compiled with CEGCC and all ARM optimizations. Now in a DLL for easy updating.
2) Found some source from the 0.66 version TCPMP that still had the Core mpeg.plg code in and got it to compile with 0.72. Now the normal MPEG4 & H263 decoding is nearly as fast as the original builds.
3) Compiled the libmad.plg (MP3) plugin with CEGCC and all ARM optimizations, adds a little speed.
The new FFMPEG build adds another 5-10% speed to FLV decoding and also opens up the possibility to decode all the new formats FFMPEG can decode.
Not tested the H264 decoding but it should be quicker.
This will only work in WM5> with ARM6 or higher processor. Has been developed on a Kaiser.
http://rapidshare.com/files/104883792/TCPMP-0.72RC1-ARM-PPC-recomp-02.CAB.html
I really want to find out the specs for QTV.dll on the Qualcomms to get the same speed boost as Coreplayer has. If anyone can help please let me know.
Click to expand...
Click to collapse
can someone post to other web? i cant load rapidshare
milesmowbray said:
For YouTube and all the formats that the original TCPMP supports.
Click to expand...
Click to collapse
does this work on a herald..
what is the difference from this vs tcpmp .72rc1 + flv 1.4.4?
is this a newer version of stuff?
This has everything integrated and might run a bit faster than the old one. It has been rebuilt in VS2008 and is under ongoing development and will get better.
milesmowbray said:
Right, new version:
1) FFMPEG used in ffmpeg.plg updated to latest CVS build from last week sometime and compiled with CEGCC and all ARM optimizations. Now in a DLL for easy updating.
2) Found some source from the 0.66 version TCPMP that still had the Core mpeg.plg code in and got it to compile with 0.72. Now the normal MPEG4 & H263 decoding is nearly as fast as the original builds.
3) Compiled the libmad.plg (MP3) plugin with CEGCC and all ARM optimizations, adds a little speed.
The new FFMPEG build adds another 5-10% speed to FLV decoding and also opens up the possibility to decode all the new formats FFMPEG can decode.
Not tested the H264 decoding but it should be quicker.
This will only work in WM5> with ARM6 or higher processor. Has been developed on a Kaiser.
http://rapidshare.com/files/104883792/TCPMP-0.72RC1-ARM-PPC-recomp-02.CAB.html
I really want to find out the specs for QTV.dll on the Qualcomms to get the same speed boost as Coreplayer has. If anyone can help please let me know.
Click to expand...
Click to collapse
Can you upload somewhere full sourcecode?
See first post for latest source code
milesmowbray said:
Right, new version:
This will only work in WM5> with ARM6 or higher processor. Has been developed on a Kaiser.
Click to expand...
Click to collapse
Okay so unless I'm reading this wrong, it still only works on WM5 and not WM6.1 on a Kaiser. . . Correct?
So far every version I've tried has given me the crash.txt error.
Related
Hello guys!
This is a new my repacked version o tcpmp with all codecs updated!!
It is based on my TCPMP OMNIA PHENOM EDITION.
I removed from that version some registry values that setted intel configuration.In this manner works in all device!
Full codec support!!
H264 support taken from tcpmp 5500
No splatch screen message
new flv codec
new flv4 vp6 codec!!
AC3 support and more others codecs!
subtitles and lyric plugins added!
Optimal default settings! you must only set your video hardware acceleration(if it is available for your processor) from options-video (default is directdraw)
All video association ARE ALREADY DONE!IT ISN'T NECESSARY THAT YOU MAKE ASSOCIATION MANUALLY!DON'T PUT FLAG OF TCPMP ASSOCIATION FOR EXAMPLE ON MP4 OR AVI,ETC ETC BECAUSE ARE ALREADY MANAGED BY A SCRIPT!!
When you tap on video file,Automatic srt subtitle detect, to switch in GDI mode to watch subtitles (at the exit, return preview video acceleration mode)
No incompatibility between flv and flv4
New icon
NB: flv4 codec isn't optimized for high resolution video(for example 640x480)
I can't try this version, because I have samsung omnia.But I think that there will be not problems!
How you know, TCPMP doesn't support qualcoom processor and for this tcpmp performance will be not good as in Samsung OMnia (tcpmp supports Intel processor)
Here file
http://www.megaupload.com/?d=W6GVBDKA
FOR SAMSUNG OMNIA AND OTHERS PHONE WITH INTEL XSCALE PROCESSOR, DON'T USE THIS VERSION, BUT THIS!!
http://forum.xda-developers.com/showthread.php?t=510791
will try if this will work on HD
Thank you, works fine on the Nike.
The flv still freeze, but at least I can see them now, and the problem is most likely of my video driver.
i tray in touch diamond with rom wm6.5 BsB 6.5B.
its crash with flv4
On my Elf, it just plays AUDIO, but I don't see the video of any FLV....
flaviopak and twolf, what phone have you?
at flaviopak and mancukia(diamond wm 6.5) doesn't work, twolf yes( flv4 are problematic!352x288 a under resolution works very fine in my samsung omnia, over works not good! I don't know in others phone, but very hard flv4 decoding + not optimal video acceleration supports as qualcoom is a not ideal situation for play videos in a good manner)
who has problems with flv, try this
http://www.megaupload.com/?d=JTYUUD7K
if doesn't work try this
http://www.megaupload.com/?d=W6GVBDKA
every time before install new version, uninstall old
fenomeno83 said:
flaviopak and twolf, what phone have you?
at flaviopak and mancukia(diamond wm 6.5) doesn't work, twolf yes( flv4 are problematic!352x288 a under resolution works very fine in my samsung omnia, over works not good! I don't know in others phone, but very hard flv4 decoding + not optimal video acceleration supports as qualcoom is a not ideal situation for play videos in a good manner)
Click to expand...
Click to collapse
Htc Touch ELF
Thank you, its probably my video driver's fault.
I have a Nike (HTC Touch Dual)
Will try them both and post feedback later.
---edit---
Tested all 3, all the same, its great as it is already, it really must be my video driver's fault.
Thanks again.
flaviopac said:
Htc Touch ELF
Click to expand...
Click to collapse
try the others version that I posted
fenomeno83 said:
flaviopak and twolf, what phone have you?
at flaviopak and mancukia(diamond wm 6.5) doesn't work, twolf yes( flv4 are problematic!352x288 a under resolution works very fine in my samsung omnia, over works not good! I don't know in others phone, but very hard flv4 decoding + not optimal video acceleration supports as qualcoom is a not ideal situation for play videos in a good manner)
Click to expand...
Click to collapse
i see flv4 not good for qualcoom.
i have other tcpmp works with all (Flv4 with 5 6 fps very very slow)
in your package ffdshow not compatible whit flv4 codecs thx.
mancukya said:
i see flv4 not good for qualcoom.
i have other tcpmp works with all (Flv4 with 5 6 fps very very slow)
in your package ffdshow not compatible whit flv4 codecs thx.
Click to expand...
Click to collapse
try the others version that i posted.
flaviopac said:
Htc Touch ELF
Click to expand...
Click to collapse
Hi, I recently make this cab. It's combination of milesmowbray's version and
TCPMP-0.72RC1-GF5500Edition-Alpha4.
It's working for me, but i have quite limited range of video files on my elf. So there might be some incompatibilities.
>>Download Link<<
avellant said:
Hi, I recently make this cab. It's combination of milesmowbray's version and
TCPMP-0.72RC1-GF5500Edition-Alpha4.
It's working for me, but i have quite limited range of video files on my elf. So there might be some incompatibilities.
>>Download Link<<
Click to expand...
Click to collapse
I tried to install tcpmp phenom on my tilt (PDAcorner X-2 V8 wm6.5 rom) and it was unsucessfull in the middle of installing, it says it does not have sufficient system permissions.
However the version acellant uploaded installed, but it just crashes when I try to open it...
TCPMP with Pocket stream server
Hello,
Installed with no problem on HTC Touch Pro2 (T7373, WM6.1 OEM). But while streaming from Pocket Stream server audio goes fine but video refreshses few frames every 3-4 seconds. In benchamrk mode video is showing about twice slower.
Also have anybody tried to watch stream from Dreambox sat tuner? few years ago I used VLC as stream server on a PC and TCPMP as player. sorry if my message is offtopic.
thanks,i'll test in my leo!
Thank you so much! I have been trying for the last two days to get video to play properly on my HTC Athena! Thank you again!
Don't work on my HTC HD2
I have a black screen and even a basic video file don't work
My config:
ROM : 1.66.406.1 (76641) FRE
Manilla : 2.5.19211619.0
merci pour mon léo
I installed the first alternative cab (if flv is not working). The player plays flv's but very very choppy, almost freezing, sometimes i have to move the progress bar button manually to see the video moving.
2 Players included. One player plays all formats except MPEG2 & CINEPAK. The other player plays MPEG2 & CINEPAK. Both players are skinable. Includes subtitle and lyrics plugins. The lyric plugin is a great feature it just needs more development. Working equalizers. Included some of BIMBAM's great plugins.
VIDEO FORMATS:
MPEG1, MPEG2, CINEPAK, WMV7 WMV8 WMV9, MPEG4, SVQ1 SVQ3, AVC/H.264, FLV, FLV4, RVG2 RV30 RV40, PLUS MORE COMMON FORMATS.
Some QT files will work if you change the file extention to MOV.
RMVB & RM file extentions play but you must change RAM file extention to RM. No support for RV10 RV13 or RV41
No support for WMV9SCREEN or WMV's that use the WVC1 codec all other VC1 codecs are compatable.
Includes TCPMP 0.71j which was a test version and the first TCPMP build that was skinable. Playback of CINEPAK & MPEG2 files are great. I have tested DVD, SVCD, MPEG2, MPEG2 STANDARD, MPEG2 WITH SVCD, MPEG2 WITH DVD, MPEG2 WITH VCD, and all played well. Still waiting on an FFMPEG.plg that will handle FLV, FLV4, CINEPAK, SVQ1 SVQ3 & MPEG2 files but till then I think this is a great way to view all in one installation of TCPMP.
Program is 7MB so I suggest installing to SDCARD. ENJOY!!!
Link 1
www.4shared.com/file/NiTjyZwY/_2_porkenhimer_projects_tcpmp.html
Link 2
www.depositfiles.com/files/rocqmuzyj
What you say ?
Er, new version of what? Where?
Are you talking about TCPMP? wheres the link?
whaaaaaaat??
what what what what
Sorry about the wait for the link. I kept uploading but it wasn't workin so I got a depositfile link. Gimme feedback and feel free to ask questions.
Thx for this
for flv4 and mkv not optimised.
Not change just another tcpmp versionne.
Tray use qtv.dll in tcpmp for best performance.
Thanx for the link.
mancukya said:
Thx for this
for flv4 and mkv not optimised.
Not change just another tcpmp versionne.
Tray use qtv.dll in tcpmp for best performance.
Click to expand...
Click to collapse
The QTv.dll/QTv video driver is for qualcomm devices only so u should have the QTv.dll if u have qualcomm device. If not i'll send u the QTv cab with the dll files or help u edit the QTv reg values. I do not have qualcomm device nor do most other ppc owners so its useless for most of us. I will help u set it up though. I'll also provide u with a link dor BIMBAMS optimized FFMPEG.PLG's.
porkenhimer said:
The QTv.dll/QTv video driver is for qualcomm devices only so u should have the QTv.dll if u have qualcomm device. If not i'll send u the QTv cab with the dll files or help u edit the QTv reg values. I do not have qualcomm device nor do most other ppc owners so its useless for most of us. I will help u set it up though. I'll also provide u with a link dor BIMBAMS optimized FFMPEG.PLG's.
Click to expand...
Click to collapse
Here is the link for the FFMPEG.PLG PACK. Just choose the one for your device and overwrite the one already in the TCPMP program folder.
http://forum.xda-developers.com/attachment.php?attachmentid=296455&d=1269090661
Any Feedback?
porkenhimer said:
The QTv.dll/QTv video driver is for qualcomm devices only so u should have the QTv.dll if u have qualcomm device. If not i'll send u the QTv cab with the dll files or help u edit the QTv reg values. I do not have qualcomm device nor do most other ppc owners so its useless for most of us. I will help u set it up though. I'll also provide u with a link dor BIMBAMS optimized FFMPEG.PLG's.
Click to expand...
Click to collapse
core player use qtv.dll and give very very best performance
this forum Windows Mobile Development and Hacking now ?
I do not know why nobody has adopted this dll and reg.
mancukya said:
core player use qtv.dll and give very very best performance
this forum Windows Mobile Development and Hacking now ?
I do not know why nobody has adopted this dll and reg.
Click to expand...
Click to collapse
COREPLAYER only uses QTv on qualcomm devices with QTv chipsets and its not full QTv its just an overlay. Here is the link to CORECODEC explaining it
http://forum.corecodec.com/viewtopic.php?f=22&t=1521
Poor performance.
Hey there.
Thanks for posting this version. Although, I dont have decent playback for MPEG2 in my Ipaq Classic 214. What settings should I use? Im using Xscale driver for video, its always the best, IMO. Ive tried the rest, but they give worse performance.
Any trick, tweak or setting needed? This ipaq has an [email protected] mhz, as processor, btw.
What device you have?
Thanks.
thanks for the link, will try....
dalecooper said:
Hey there.
Thanks for posting this version. Although, I dont have decent playback for MPEG2 in my Ipaq Classic 214. What settings should I use? Im using Xscale driver for video, its always the best, IMO. Ive tried the rest, but they give worse performance.
Any trick, tweak or setting needed? This ipaq has an [email protected] mhz, as processor, btw.
What device you have?
Thanks.
Click to expand...
Click to collapse
My tip would be for better picture quality always play videos at 100%. Open TCPMP and go to options>zoom>100%. U will notice a difference immediately.
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.
I was reading the latest changelog for cm7 because the nightly went from 42 to 54 and found this! Is this hw video decoding??
Change-Id:
I987d1fd17462fd41655b193a8cb03709a7d85e8e
Owner
Project CyanogenMod/android_device_advent_vega
Branch gingerbread
Topic
Uploaded Apr 23, 2011 5:27 AM
Updated Apr 23, 2011 2:03 PM
Status Merged
Permalink
Vega : Enable HW Video Decoding
Enable OMX and Opencore prop pulls
Enable TARGET_OVERLAY_ALWAYS_DETERMINES_FORMAT
Enable TARGET_USE_SOFTWARE_AUDIO_AAC
Change-Id: I987d1fd17462fd41655b193a8cb03709a7d85e8e
Where are you seeing these changes ?
I can only see harmony related changes here:
http://cm-nightlies.appspot.com/?device=harmony
Code:
cm_harmony_full-54.zip
Revert "ignore sf error" (android_frameworks_base)
Correct changelog for bad English translation :( (android_vendor_cyanogen)
Changelog revision (android_vendor_cyanogen)
CHANGELOG (android_vendor_cyanogen)
Traditional Chinese: update translation (android_packages_apps_CMParts)
stagefright: Remove extra parenthesis in makefile (android_frameworks_base)
libutils: Fix an improper const-cast in RefBase (android_frameworks_base)
Updated Italian translations (android_packages_apps_CMParts)
Create tablet overlay and set encore to use it (android_vendor_cyanogen)
add csr_tegra support to bluetooth stack (android_external_bluetooth_bluez)
Revert "The ActivityThread will restart a stopped activity before sending onActivityResult" (android_frameworks_base)
harmony: set TARGET_USE_SOFTWARE_AUDIO_AAC in BoardConfig (android_device_harmony)
harmony: set TARGET_OVERLAY_ALWAYS_DETERMINES_FORMAT (android_device_harmony)
Fixes issue #3404 (http://code.google.com/p/cyanogenmod/issues/detail?id=3404) where many applications such as SMS, Contacts, etc would FC if the user changes their locale to Arabic (or any locale that doesn't use the English numeral system) (android_packages_apps_Email)
Convert bearing/heading from 10 bit value to degrees on locapi 20000 (android_hardware_qcom_gps)
Fix for issue 3551 (android_packages_inputmethods_LatinIME)
media: stagefright: Implement TARGET_USE_SOFTWARE_AUDIO_AAC in OMXCodec (android_frameworks_base)
harmony: update extract/setup for Stage Fright (android_device_harmony)
webkit: fix text wrapping (android_frameworks_base)
stagefright: allow targets to pass real dimensions to the decoder (android_frameworks_base)
Check BOARD_VOLD_EMMC_SHARES_DEV_MAJOR to share volumes to get the correct partition number for the volume. (android_system_vold)
Where did you find hw fixes? Its not in the changelog im seeing.
b3ltazar said:
I was reading the latest changelog for cm7 because the nightly went from 42 to 54 and found this! Is this hw video decoding??
Change-Id:
I987d1fd17462fd41655b193a8cb03709a7d85e8e
Owner
Project CyanogenMod/android_device_advent_vega
Branch gingerbread
Topic
Uploaded Apr 23, 2011 5:27 AM
Updated Apr 23, 2011 2:03 PM
Status Merged
Permalink
Vega : Enable HW Video Decoding
Enable OMX and Opencore prop pulls
Enable TARGET_OVERLAY_ALWAYS_DETERMINES_FORMAT
Enable TARGET_USE_SOFTWARE_AUDIO_AAC
Change-Id: I987d1fd17462fd41655b193a8cb03709a7d85e8e
Click to expand...
Click to collapse
Sent from my SPH-D700 using XDA Premium App
juanaraya92679 said:
Where did you find hw fixes? Its not in the changelog im seeing.
Click to expand...
Click to collapse
Here
Not sure how that relates to the latest nightly though.
It can be just one change from many step required to make this work.
Sent from my Nexus S using Tapatalk
All I know is that vids that didnt play before are playing now. A whole lot smoother too.
drx69 said:
All I know is that vids that didnt play before are playing now. A whole lot smoother too.
Click to expand...
Click to collapse
Can you take screenshots with this build? Either via ddms on the desktop, or screenshot ER?
Because not being able to take screenshots (as of the previous nightly) is what drove me to Vegantab (which I like, but I could go back )
drx69 said:
All I know is that vids that didnt play before are playing now. A whole lot smoother too.
Click to expand...
Click to collapse
How's youtube? Can it play HQ vids now?
I can confirm video playback from YouTube without stuttering. I played HD video from both the website (Dolphin and Stock Browser) and the YouTube App. I played the VEVO version of a few songs, and they all played flawlessly.
I am running Pershoot's Overclock Kernel, but all seems fine.
Here is a video link for documentation:
http://www.youtube.com/watch?v=iIk2WnS_lAk
This is indeed an incredible development! I can't wait for it to be refined and eventually baked into all the gingerbread roms. I know there are many of us holding off on jumping from froyo until hardware acceleration is enabled.
How about hardware decoding of local AVI's and wmv's? any tests?
thanks in advance.
pagantek said:
How about hardware decoding of local AVI's and wmv's? any tests?
thanks in advance.
Click to expand...
Click to collapse
no dice yet.
Observed speedups might be due to changes in the streaming libraries or flash handling or something.
Setting up hardware acceleration on video players (moboplayer and rockplayer) still fails.
Also graphics related benchmarks results didn't improve from the earlier rest of the CM7 releases.
video is better here... vplayer wouldnt play vids before, now after this update it plays all my movies perfectly!! i know for a fact they wouldnt play before the update, it was just freezing my gtab yesterday!
I just tried to move from Clem+Calkulin1.5 to the CM7 55 - Videos which works fine on Calkulin (h264 main @3.1 1024x600) plays much slower and sometimes hw decoder dies.
Well, from my personal experience.. this enables HW decoding got the default Android supported video formats... so no HD... only MP4...
crutzulee said:
This is indeed an incredible development! I can't wait for it to be refined and eventually baked into all the gingerbread roms. I know there are many of us holding off on jumping from froyo until hardware acceleration is enabled.
Click to expand...
Click to collapse
My thoughts exactly.
I threw on a Gingerbread rom just after I got my Gtab.
Then I tried a Froyo ROM just for the heck of it.
Until Nvidia drivers are a part of GB, I'll be sticking with Froyo.
strudel.chris said:
My thoughts exactly.
I threw on a Gingerbread rom just after I got my Gtab.
Then I tried a Froyo ROM just for the heck of it.
Until Nvidia drivers are a part of GB, I'll be sticking with Froyo.
Click to expand...
Click to collapse
+1
but in all honesty, CM 7.0.2 is MUCH better than the nightlies 54 and below. Its actually usable now. Coming from Vegan 5.1.1, I dont feel compelled to go back to froyo after flashing CM7 now. With pershoots OC kernel, this will definitely be my daily driver moving forward, and its only going to be get better over time! All of the tegra games run butter smooth, HQ (720p) flash works fine, and .3GP works with much more to follow.
How are videoconferencing apps? Camera and video? tempted t flash back to cm7 from vegan 5.1. 1. I love the cm7 honeycomb theme.
Sent from my SPH-D700 using XDA Premium App
I saw that Cyanogenmod released their newest version with 7.1RC1 and I saw that it includes Android 2.3.4. I am currently running 7.0.3 stable and there is no video chat with the default Google Talk. Does anyone know that if you use the new 7.1 RC1 if Google Talk will support video chat?
Thanks,
ElBow!
Can anyone who has CM7.1 RC1 test this out for me quickly please? Also can anyone confirm Netflix's status in 7.1RC1?
Regarding Netflix, I moved to 7.1RC1 and it works. It first had the chipmunk effect, so I had to tweak the build.prop file to have the following two lines:
ro.product.model=HTC Vision
ro.product.manufacturer=HTC
And everything worked.
Also remember to use LCD Density Changer to change the density from 161 to 140. This allows you to pick particular episodes in Netflix, but remember that 140 seems to give Market fits when you do a "My Apps" query.
Regarding Google Talk Video, unfortunately, the the latest universal Gapps does not support it. You will have to do some tinkering to get it on there. I actually found this thread Googling the topic myself. Sorry! Hope that helps!
Actually, at the moment, there is no way to get the Google Talk Video to work on the GTablet... not unless Google releases a new "universal" GTalk with Video.
The new GTalk with Video uses a pre-built library for video which has only been compiled for devices with ARMv7+NEON processors (i.e., ARMv7 instruction set with NEON optimisations).
The NVIDIA Tegra 2 processor in the GTablet is an ARMv7 processor but lacks NEON optimisations. It only supports some VPF optimisations. So, the lack of the NEON optimisations renders this "video library" of the new GTalk useless for the GTablet. It will cause stagefright (the Android media framework) to fail and force close since the system cannot understand the NEON instructions.
Even the Skype video feature will not work since the Skype video library is also NEON optimised.