 |
|
 |
Hi,
Is it possible to set 30 frames as example and each frame be a new image ?
[]'s
Evandro
|
|
|
|
 |
|
 |
hi all,
i am currently working on image compression . encountered a problem that after encoding(huffman and run length) the image(BMP). i got the binary coeff. can anybody tell me how to write this data in a jped file and display it.
regards
sambhav
kumar@brandwidthtech.com
|
|
|
|
 |
|
 |
Hi Mike.
I enjoyed this project.
I am looking for something very similar to use in a commercial app.
If you would be interested in a bit of extra cash and small outsourcing project, please contact me off the public airwaves at:
roniw@c3-dev.co.il
Many thanks
Ronnie Wulfsohn
|
|
|
|
 |
|
 |
please tell us what are the changes that we have to make to convert from MPEG fucntion to JPEG one
thanks alot ...
i am so interesting in your article
DevXII
|
|
|
|
 |
|
 |
what a wounderful documentation about mpeg compression ... but what about JPEG compression and decompression , i need to know how it can be implemented through these already defined functions or just jive me a hint ...
dfds
|
|
|
|
 |
|
 |
i am working in (avi to mpeg-1 video compression)
could any one send me any usefull information to encode p,B
frames ?????????
i need to know the (ISO/IEC 11172 Part 2)
detail
where could i find it
|
|
|
|
 |
|
 |
Hay I'm now in the same postion, hae you any usefull information in order to start?
JOHALEMED
|
|
|
|
 |
|
 |
I don't know what everyone is complaining about. Having some powerful classes built into the .NET Framework is making people lazy. Personally I wish to understand the concepts and the algorithms that make it all work. Thanks for putting in the time to write this implementation. For any astute programmer, this is some invaluable information.
Peace
|
|
|
|
 |
|
 |
I agree with you. This code is actually very hard to write, you need advanced understanding of DSP and image/video processing and data compression. So those inclided to that type of challenge can use this code to continue the development to a full codec.
|
|
|
|
 |
|
|
 |
|
 |
As the author states, the I-frame compression in MPEG is virtually identical to the JPEG compression method. He says that he wishes somebody had written this application before, but I guess there is no point on such application. What will you use it for?
There are lost of codecs out there (open source), however AFAIK this is the first try using C# to implement the codec itself. Now that would be a great project . Perhaps the next step is to implement an I-frame only MPEG encoder.
BTW, it would be more useful to focus on MPEG-2 rather than MPEG-1.
Rgds,
Gerardo
|
|
|
|
 |
|
 |
geragonz wrote:
He says that he wishes somebody had written this application before, but I guess there is no point on such application. What will you use it for?
If you read the article it states: "Set top boxes"
--Colin Mackay--
EuroCPian Spring 2004 Get Together[^]
"You can have everything in life you want if you will just help enough other people get what they want." --Zig Ziglar
|
|
|
|
 |
|
 |
The question remains ... what will you use it for?
Gerardo
|
|
|
|
 |
|
 |
Me... Personally... As I don't work with DVD and Settop box stuff probably nothing. However I am sure there are people who will get something comercially useful out of this article.
If I ever decide to make a picture CD for my friends or family I now know where to come for some of the information.
--Colin Mackay--
EuroCPian Spring 2004 Get Together[^]
"You can have everything in life you want if you will just help enough other people get what they want." --Zig Ziglar
|
|
|
|
 |
|
 |
Well,
There are standards for still image compression (JPEG, JPEG2000,JPEG-LS) and many other formats for stills. Picture CD is a JPEG based format, nothing to do with MPEG. People use JPEG to compress images, so there is no point on having a MPEG do that.
The point is not if MPEG can be used in this way or not, the point is that there is no need for it.
As far as settop boxes, they are just starting to come with DVD/CD players integrated and surely will have JPEG support. Before that, a settop box was a closed system used for decoding cable TV, AFAIK cable delivers video, no stills. So the author's argument is wrong.
As I said this is a good start for an MPEG codec in C#, so I hope the author updates his code with full video support.
Rgds,
Gerardo
|
|
|
|
 |
|
 |
You know - it's kind of funny how when you look at a set of comments a few months down the track how wrong some people can be.
I've just purchased a set top box, yeah - I'm slow on the uptake - but my box has a usb port, and that is it. It also displays mpeg images. Not jpeg. not gif, not png. So useful? Definitely. Especially now that I can display all my "photo albums" as a slideshow on my lovely new plasma display.
Good article and now I can implement it.
PK
Peter Hancock
My blog is here
And they still ran faster and faster and faster, till they all just melted away, and there was nothing left but a great big pool of melted butter
"I ask candidates to create an object model of a chicken." -Bruce Eckel
|
|
|
|
 |
|
 |
geragonz wrote: The point is not if MPEG can be used in this way or not, the point is that there is no need for it.
You don't know.
geragonz wrote: As far as settop boxes, they are just starting to come with DVD/CD players integrated and surely will have JPEG support. Before that, a settop box was a closed system used for decoding cable TV, AFAIK cable delivers video, no stills. So the author's argument is wrong.
This is just so wrong ! You really don't know anything about Set Top Boxes...
Latest models to be on the market in 2006 still don't support JPG for background images, only MPEG. And for on screen display, chispet API only support bitmaps. There are middleware that decodes JPG. But again, background images (behind the video) are iframes.
The only pointless thing here is your comment. Source code contribution never is.
|
|
|
|
 |
|
 |
Well, let's see....
No YOU DON"T NEED IT.
and ...
Yes I know more that you would imagine about set top boxes and about compression standards. Yo have no idea what you are trying to argue. Yes I-frame images are used to code the images in DVD menu backgrounds, but that was not the point of my discussion. Hello??? You actually support what I am arguing.
The bottom line JPEG support is a standard feature of DVD players mostly supported by middleware so there is no point on translating an image from JPEG to an I-frame in MPEG. Now,I assume you understand we are talking about set top boxes with DVD capabilities right? And that current DVD chipsets support not only MPEG but many other formats, either through hardware or software.
Then at the end of your message I see the phylosophical BS and then it all becomes clear.
And as I said on my original message (if you know how to read) at the time having a C# development for an MPEG codec sounded very good. The value of the code as such is not argued, the intended appication is pointless.
|
|
|
|
 |
|
 |
My comment was about Set Top Boxes in general, not only with DVD capabilities.
For your info, I was talking about digital broadcasting STBs. Middlewares ( OpenTV/MHP...) can often decode JPEG and other formats. But to display a background image, behind the video layer, an MPEG iframe is still required. Tools to convert JPEG to still MPEG are commercially available. In the interactive TV market, they usually come with SDK and authoring tools. This small contribution does the same job and is indeed useful for interactive TV application developpers who would like to create an still MPEG from images.
It is indeed pointless if your are interested in a C# MPEG codec or if you live in a world where all STBs have DVD capabilities.
|
|
|
|
 |
|
 |
Well, guess I can suggest a use for this code, even tho I don't quite understand it.
Learning...
LoneFerret
Cross my heart, smack me dead...stick a lobster on my head.
|
|
|
|
 |
|
 |
No the author is not wrong nor is the information pointless.
Set top boxes typically support a video plane, a _still plane_ and one or more on screen display planes. The still plane is a misnomer because actually it can use so-called video drips but for our purposes and for the purposes of this argument, its suffice to say that it can also take Iframes as stills.
The hardware for this plane does not decode full video so you cannot provide it an mpeg file. It does not decode jpeg, nor any of the other standards you mention for compression of images. It uses precisely the format the author uses, iframe.
So to return to your question - no this isnt pointless at all but you need to understand how set top boxes work (today) to get it.
|
|
|
|
 |
|
 |
Dear sir,
I am in no position to argue with you regarding this. But I believe that your choice of words is not right. You cannot say that any posting is pointless.
Just to get something to interface with hardware is a huge pain, and it is virtually thankless job. Because once you do it, everybody would like to use it but nobody would like to thank the guy who had only inspiration to make him to do the job...
Think about it.
-Saju
|
|
|
|
 |
|
 |
Got a question.
Is it technically possible to compare two MPEG2 streams.
For example there is a source stream (5 sec) that I would like to detect in the target stream (40 sec). I would like to detect if the video or the audio are same or different or same in any way.
Video may differ in color, segment length. Audio might be different even though the video is accurate.
Is there any API to take care of the above scenarios.
|
|
|
|
 |
|
 |
That is going to be implemented in MPEG7 ... but i don't think there is something like that yet.
|
|
|
|
 |
|
 |
where to get information about MPEG1 or 2??
thx
Don't try it, just do it!
|
|
|
|
 |