Jump to content

amirm

Members
  • Content Count

    87
  • Joined

  • Last visited

Community Reputation

0 Neutral
  1. Maybe you have not been in communique with an ad rep from MacWorld - they actively engage potential advertisers on how they can promote third party products to the Apple community - it's a great model and creates win/win for both vendor and reader. Most of Macworld's content is about what-else-works-with-Apple. BTW that is not our mission statement, it's one of the many services we provide to vendors to enable us to fund MxInstaller magazine, so that it can be distributed to the community free of charge. What I quoted was under "About theipacademy." It said that you published your articles every so often and then what I quoted. So if it is not your mission, not sure what it is. And no, I don't agree that paying for advertising buys editorial content of Mac World. If you covered the entire industry and then showed a Mobotix ad, then you could say you are like Mac World. Your business model is the other way around where the entire editorial content is from the commercial vendor. My read of your services is that if I pay you, you will publish what seems to be independent articles but in reality are infomercials for my product. If that is not what you mean, then maybe you should clarify it there. Again, I think in the context of commercial intent, you do a reasonable job. There is useful information and as long as the person knows there is an intent there to promote that product as I mentioned, then all is well. I addressed your comments relating to the tutorial and MxPEG, for the rest of the community, because they were incorrect. What was incorrect? You agreed with everything I said. The only thing that was incorrect was your clarification saying an article that has an headline of H.264 in it, is really about how you store the bits and not the codec. The merits of their codecs is what I listed, not some twist it of it into some other talking point. BTW, on a personal level, I have been a champion of Mobotix here and elsewhere. This interchange however has really soured my positive view of the company. If they have hired you to come and post this way, and you can't tell the friend from foe, then someone is not doing their job well.
  2. Hmmm. This is the description you provide on your Youtube web site: "We actively assist third party manufacturers of specialized software, storage, networking and wireless technologies to help them align their products with the megapixel video surveillance market. Contact us if you'd like to learn how we might help promote your products to the global IP surveillance market @ ....com" Pretty sure Mac World doesn't have this kind of mission statement . Given the title of the presentation which includes the name of the codec, h.264, it heavily implies such a thing and hence me addressing it. Then it should have been titled at such. As it is, it paints a confusing picture of what is a codec, and what is a storage architectures. As you state here, these are orthogonal concepts and should not be mixed this way. As I noted, I have watched your videos and they are generally high quality. This mixing of topics is an exception. Well, as you know, the cost there is for a lot more than just to record. The light VMS that is inside Mobotix can't support all the functionality that they do. I am not arguing against what Mobotix has but let's not push the message to the point that is hard to defend .
  3. Guys, if you want to become super comfortable for bits and bytes of video (and audio), here is an article to get you there: http://www.madronadigital.com/Library/Audio%20Video%20Encoding%20Formats.html. I wrote it for audio/video people and not CCTV applications but most of it should be useful in this context too.
  4. Helps only in one way - you should have camera with 35 mm format imager On small imager, i thing, you will not gave good result.... Yes, it does require having a camera compatible with a DSLR format (but not the same size sensor -- Canon makes DSLRs with three different sizes from full 35 mm to APS-C size. So there is no requirement to have a 35mm sensor).
  5. Yup. That's why companies like Avigilon use Canon lenses for their high megapixel cameras. While CA exists with any lens especially in the corners, ability to use high-end DSLR lenses helps a lot here.
  6. Hmmm. What I wrote was at least two people's opinion: mine and TheWireGuys. I will expand a bit to add more information here: Avigilon: these folks have cameras that go where others do not. 16 Megapixels anyone? Their use of JPEG2000 compression (in some cameras) gives them neat features like scalability both in time and bandwidth. They now have a newer line augmenting the high-end using traditional compression (H.264). Mobotix: clever architecture using an ARM processor to compress video rather than a separate chip. Advantage: low power consumption (3 watts) meaning you don't need heaters and such for enclosed outdoor cameras. Their hemispheric solution is quite innovative, using a fisheye lens and the dewarping in software to create a linear image. Drawback? Frame rates are not as high as hardware solutions and their high efficiency compression is unique to them. Arecont: You have to be nice to TheWireGuy to explain more than I can about their product . I have known the for quite a while as the bread and butter type of camera without a lot of uniqueness to differentiate them as with the above two. I suspect WireGuys carries it as a more economical solution. So there: you have more of my opinion. Of course, it is still not the whole answer for why you would want to "sell" some of these. You need to figure that out for yourself and your situation (the message from the other guys in this thread). For example, in our business we install cameras in concert with home automation so integration with our touchpanel is important. This makes Mobotix compression method problematic even though I really like their cameras otherwise. We also had a hell of a time getting their attention whereas I managed to get a hold of the right people at Avigilon with one email. In your case, it should be reverse with Mobotix support being better in Europe than US. You too. This forum is quite friendly by the way. You just have to find the right way to ask the question from "senior" members .
  7. DeDanan, I have been reading this forum for a year and every post in that image thread and can tell you that the question you ask, does not have a definitive answer on this forum . Companies carry cameras for a myriad of reasons from margin and support to fidelity. That said, you can actually look under TheWire's signature and find the few cameras which get more up votes than down .
  8. Most definitely a bug. If you were losing entire frames, we could think of other things but not corrupt frames. One final thing though. What is between your PC and the camera? If there is any other device (router, switch, etc), eliminate it and go direct. It is possible that the in-between device is corrupting things.
  9. Then it is a bug . Does it do it with MPEG-4 or is it just MJPEG? If it doesn't, does it let you reduce the resolution you are capturing with MJPEG? If so, try lowering it and see if it helps (for debugging reasons).
  10. What is the speed of the link to the camera? It is possible that it is overflowing its buffer and dropping packets as a result. When you set the quality to 100, you are telling the encoder to not quantize (reduce the fidelity) at all. This can cause pretty massive peaks in data depending on scene content. Try setting the quality to 90 to 95% and see if the problem goes away.
  11. Oh, I don't know, could it have been this ... ... punctuated with video of a bush. Best, Christopher Well, this is what I said after what you quoted: "You might find that H.264 at half to a quarter of the data rate of MJPEG produces the same and maybe even better quality at times. Experiment with above tricks and search for work others have done." I didn't see you having tried either. And I didn't just give you a video of a bush. I provided a pair of videos that showed MJPEG outperforming H.264. And a few others including outdoor road scene.
  12. I said nothing about frame rates. Read my post again. Keyframe distance is not frame rate. I am not writing my answers just for you. I am writing them for everyone. Hence, the advice I gave to investigate these things were general and not take the quickie answer you demanded from me. Your posts did not show evidence that you had tried all the options in H.264. It was devoid of any encoding parameters for example. So I am unclear why you think I should have assumed you had done exhaustive tests of these codecs. A bush that was moving with the exact one in the other codec making the comparison easy and tells you a ton. With motion compensated codecs, it is very hard to do freeze frame comparisons as you did as the very next frame may be sharper than the one you posted. I realize that having a few soft frames may not be good in this application and hence my suggestion to adjust the keyframe distance. Christopher, I was not the one who started the argument with you so don't understand the tone of voice you are using with me. I am not here to answer your challenge or settle a bet. I am here to explain how the technology works. If that is not what interests you, then kindly target your posts at someone else.
  13. And one more which may come closer to the application we have here: Pause the video when the cars go by and see if you can read the license plates.
  14. Well the systems we deal with are complicated so the answer is also complicated. Here is a sample. In any motion compensated codec like H.264/MPEG-4, you can set what is called the keyframe distance. If you set this to say, half a second, then the codec generates a full video frame and compresses it in a similar manner to M-JPEG every 0.5 seconds (or more often as it sees fit). So imagine if I am encoding at 10 fps and I set the keyframe distance to 0.1 seconds. If you do that, then the encoder will essentially degenerated into a fancy M-JPEG codec, generating a full frame of video 10 times a second as M-JPEG would. So if it the motion compensation that you are worried with in these codecs, it can easily be defeated (assuming the encoder gives you that parameter as it should). I say "fancy' because H.264 has a more advanced keyframe compression scheme than M-JPEG. The fanciness comes from two things: 1. A better transform and entropy coder. Compression lingo for it simply being more efficient than MJPEG in how it generates these still frames but with no loss in fidelity. 2. Loop filter. This is a dual-edged source. What this does is that it attempts to soften the compression blocks so that the edges are not visible. I am sure you have seen blocking distortion when data rates are too low. H.264 blends those pixels together. Alas, there is no free lunch and that blending can also remove some picture detail. And H.264 can get quite aggressive in how it does this, providing very pleasing but soft images. Loop filter can be disabled two ways: one is by a flag in the encoder but it is rare to see that in consumer space. The flag is available in professional encoders and some Blu-ray movies for example are encoded with it off. The second way which is kind of indirect is to give the encoder ample bandwidth. The encoder varies the strength of its deblocking filter based on how much compression artifacts exist. If the data rate is very high and there is little to no blocking artifacts, then it doesn't filter much if any pixels. Net, net, if you set the keyframe distance to the timing of your frame rate and given H.264 encoder very high data rate (similar to what M-JPEG would take), you wind up with a better M-JPEG comperssion engine. As the old saying goes, I prefer to teach you how to fish than giving you simple answers that you can't prove beyond asserting it. I will give you the simple answer you want: M-JPEG. But I wish you would do some experimentation as others have done to see if there is a real trade off there. You might find that H.264 at half to a quarter of the data rate of MJPEG produces the same and maybe even better quality at times. Experiment with above tricks and search for work others have done. Speaking of other people's work, there are a ton of consumer still/video cameras now that encode both in MJPEG and AVCHD which is another name for H.264. Youtube is full of comparsion videos, some of which are well done. Check out these samples but before you play them, be sure to click on the pop up in the youtube player and select 720p and select HD aspect ratio. http://www.youtube.com/watch?v=Y3x_lRfuem0 These two are kind of revealing as they are done in a way to bring out differences more clearly. Look at the bleeding on the color wheel in the H.264. Might want to open two browser windows and hit play on both at the same time. PS sure would be nice if this forum allowed embedding of these videos as I can on other forums .
  15. Thanks for asking . I think the answer is complicated . Putting detail resolution aside for a moment, for MJPEG to match H.264 in overall visual quality, you would need 10X the data rate if not more. Invert that and you will have a very poor image at the 10X lower data rate if you used MJPEG. There would be so many compression artifacts that detail will not be recognizable in MJPEG. Now, there is an inverse argument and that is what you are making. Some of efficiency in H.264 comes from built-in filtering. This is designed as to remove visible compression artifacts in exchange for loss of detail. This is what I mentioned in my previous post. To the extent you don't care about low data rate, and could jack up the bit rate until MJPEG is free of compression artifacts, then it will indeed produce a sharper image. So to a great extent, this question has to do with the data rate in use. There are also other variables such as quality of the H.264 implementation (which varies a ton).
×