rockeronline00:
does anyone have a NMEA parser for this GPS?
As others have said, TinyGPS will work with this device.
You're asking about an NMEA parser -- almost all GPS devices output NMEA "sentences", which can be parsed by many different NMEA parser libraries. But because the NMEA format is fairly inefficient, many GPS manufacturers also support a binary format that is unique to their devices (i.e., not "standard"). Few parser libraries can also support the binary format of specific GPS brands.
The ublox NEO-M8 can output NMEA, UBX and RTCM messages (spec here). It outputs NMEA by default, which can be parsed by TinyGPS.
The YouTube video referenced above links to some very simple code for parsing one UBX message. It expects the device to be configured to output only that message... you must use the U-Center application to turn all the other messages off (including the default NMEA messages), enable just the POSLLH message, and set the message rate.
While it does verify the checksum on the message, it does not configure the device during setup, and it does not verify that it is receiving the expected POSLLH message. If you only need Lat/Long, not Speed/Heading, it could work for you.
First, you have to decide at what update rate you need the information. If you just need it once per second (or less frequently, say once per minute, hour or day), NMEA would be fine, and you could use TinyGPS. If you need updates 10 times per second, you have to use the binary messages (UBX) because they're quicker to transmit (fewer bytes) and quicker to parse (no char-to-int conversion). TinyGPS will not work.
Next, you have to decide what kinds of information you want: Lat/Long, Speed, Heading, Altitude, Time, Date, etc. From those elements, you can choose which messages contain those pieces. That will allow you to select the configuration commands you need to send during setup. For example, to receive Speed/Heading, you will need to enable (and parse) the NMEA GPRMC message, or the UBX VELNED message, depending on which protocol you selected in the first step.
Next you should decide if you need coherency: if you care that a speed reading is correlated with the lat/long reading at the same time, you must group the received information from a batch of messages in the same time interval. Easier said than done... 
And finally, you should decide what to do with status information. What should you do when there is no satellite fix? You may have some pieces, but not others: you may have Time and Date, but not Lat/Long.
You haven't told us what you're doing with the GPS device, though... If you're using it in a quadcopter, you'll need to parse several messages at a high data rate (i.e., binary messages), and coherency (and more... ). My library, NeoGPS, would work for that. It is fully configurable to minimize RAM and program space, based on which pieces you need. NeoGPS is more robust than the iforce2d code, and it uses even less RAM. NeoGPS is longer than his 66 lines, though, and will add at least 800 bytes of program space instead of his 200 bytes. TinyGPS adds about 2400 bytes of program space.
If you're just making something like a reverse geocache, you'll only need one NMEA message at a low data rate, and no coherency. Again, TinyGPS would work for that.
Cheers,
/dev