Frage von LarsProgressiv:
Hi folks,
News on the distribution of the developer of the FFmpeg project are just
reflections employed as a new, more efficient, fresh design to video codec, or would look to implement would be.
I had some time ago have great hopes for
Antwort von WoWu:
Hi Lars
Codec development is intervening in such a narrow time window like that the real-time capability meanwhile only observed with corresponding DSP developments, such as the development of H.264 shows.
The time that something be effective on the "home" computers to try to show, is over.
As long as a codec development is not accompanied with the appropriate chip development, it will not reach their goal can be.
For years, developed synonymous MPEG s.einem new codec to see it as a H.264 could probably look and hat with the MCTF-SBG good results, but at the same time that they are still far short of the use in a real-time application.
Therefore, the question really is whether such a "wish list" is not awarded represents love trouble, especially since few of the current users so far have any idea of the extent to which interactive elements and the separate transfer of individual picture elements or layers of each image for a future role will.
Remember you must not do, that such elements, but already part of MPEG4 / H.264 are .... But in the current stage is still not being used.
So it would have a "future codec possibilities range far beyond the users still do not know, let use.
The qualitative requirement would have before a background to be defined before synonymous H.264 in its possibilities only in qualitative approach is used.
It would be a wish list is interesting, but because it is based on the "Today" up, not particularly meaningful.
But once we wait until the hardware options allow us to synonymous in the consumer circle existing codecs s.ihre borders to exploit. I'm sure by then the problems are synonymous with respect to the real possibilities of future codecs, such as the SBC MCTF of the chip industry synonymous resolved.
Antwort von LarsProgressiv:
Hello Wolfgang,
if I understand you, you would like the following:
- Real-time capability (decoder or encoder?)
- Figure in hardware
Among the other aspects, I just want to run that I am a pure video codec needed, with no interactive elements or otherwise contains.
It is simply a stream of coded images.
I need a secure future codec, so I think a solution that turned my home movies and record packed with the corresponding sound in Vorbis in an open container (MKV) for the conserved _Ewigkeit_ usable.
It is therefore for me, my grandchildren and great-grandchildren and so be able to play the movies again. And when I see an open standard as given, as documentation and source code associated with free care and free tuition to guarantee something.
This was once the exception of patents, whose violation can not really exclude, but eventually phased out.
The Enkodiergeschwindigkeit plays no role for me, with the already Dekodiergeschwindigkeit importantly, in terms of systems zukünfitgen again into the background. I therefore have no need for cutting codec. Your call is probably Intermediateformat, right?
I'm interested in just the wishes of other users.
And I assume that one wishes to implement and should not, as commercial companies do it, provides games, in the hope that it someday in the future.
I refer to the of you mentioned, apparently in H264 introduced interactive elements.
Regards
Lars
Antwort von WoWu:
Hello Lars,
Thanks for the reply, but then I had you in your first post misunderstood, I assume that Michael N.
Snow under a new Project wanted to hang up, but not of a general wish list after codec features ...
I'm interested in just the wishes of other users.
And I assume that one wishes to implement and should not, as commercial companies do it, provides games, in the hope that it someday in the future.
I refer to the of you mentioned, apparently in H264 introduced interactive elements. Unfortunately you have misunderstood me thoroughly when I interactive elements of the codec have spoken ... which are currently not operating feature incorporated in H.264 (hidden) and of course, are not currently used, but for example the possibility of individual image segments (slices or slice groups) of an individual processing to be performed. This has already significant advantages in terms of the quality of the picture, but closes for future use of the possibility of synonymous these segments individually, ie without the rest of image transfer and of course, synonymous, such elements on another route to sell, so on Picture TV and elements on the Internet.
To open such possibilities course applications, but, as I said, already has the benefit clearly exists.
And when I see an open standard as given, as documentation and source code associated with free care and free tuition to guarantee something. As for the "open standard" and your future expectations, there are just MPEG2 and MPEG4 classic open standards, unlike many proprietary or even freely available, because they are anything but open and as good as ever, there is a reference implementation, so that you really only for those standards such as MPEG2 / 4 can be sure that you have in 30 years a working decoder get something for the other codecs do not with the safety case.
Also, if necessary documentation and source code uses you absolutely nothing, because your great-grandchildren certainly will not sit down and investigate, determine the version in your encoding was actually used and new einhacken him ... Absolutely not. And what the sources anget, look into the network, which is free code is actually maintained ... because I think only single beads in a jumble s.Durcheinander.
So that I would not bet that it works, but to a standard that is now recognized worldwide and is distributed to both the industry, synonymous as the broadcaster and support you in the next 15 years (if not more) your synonymous TV Programs can receive.
My wish, after a figure in HW is probably not to circumvent, because actually the time of the software encoder in the latte of the requirements would be gone and even if you personally do not necessarily indicate the real-time arrives, it is probably no (commercial programmers ) to find the codecs to the old HW architectures to adapt, because the results along with the requirements of course always be worse.
And as far as patents are concerned .... just an example: Microsoft is yes VC1 from an early draft of the H.264 development ... na say borrowed ... Since it possible for users to disclose existed, had necessarily synonymous the rights of third parties disclosed. These are approximately 200 patent holders, solely for this codec. Now, like you have a picture, like many companies s.solchen developments are involved. With MPEG, there are more than 300, the sH264 cooperate.
Will a company that is an equivalent, high-performance codec on the market, it must happen quite a bit ... or just that one borrows to him, such as the Chinese. When I look at the HDTV specification chart, I can equally synonymous beside the H.264 set, only that many Chinese universities as the source mentioned.
You see, new, truly pioneering codecs do not come easily from the pen
Antwort von motiongroup:
hallo Lars, di're in that range of your target is not in a league of DIRAC codec
http://diracvideo.org/
http://www.codec-download.de/codecs/video_codecs/bbc_dirac_video_codec_0.5.4_99.html
http://www.google.de/custom?domains=slashcam.de&q=dirac&sa.x=0&sa.y=0&sa=suche&sitesearch=slashcam.de&client=pub-8291754662609381&forid=1&ie=ISO-8859-1&oe=ISO-8859-1&cof=GALT%3A%23008000%3BGL%3A1%3BDIV%3A%23336699%3BVLC%3A663399%3BAH%3Acenter%3BBGC%3AFFFFFF%3BLBGC%3AF09201%3BALC%3A000000%3BLC%3A000000%3BT%3A0000FF%3BGFNT%3A0000FF%3BGIMP%3A0000FF%3BLH%3A47%3BLW%3A429%3BL%3Ahttp%3A%2F%2Fwww.slashcam.de%2Fimages%2F%2Fgooglesuche_unserlogo.gif%3BS%3Ahttp%3A%2F%2Fwww.slashcam.de%3BFORID%3A1%3B&hl=de
Antwort von LarsProgressiv:
Hello Wolfgang,
no, what Michael does, he knows not. If I have understood him correctly, there are several possibilities:
- Make garnicht and Snow to die
- Snow continues to develop and bring a version 1.0
- Other codecs (h264) as a basis to improve and
--- Remove unnecessary
--- Improve quality
--- Speed optimize
What really happens is s.ihm.
I'm not the coordinator or so. I just wanted to hear what others have to say, if they wish could be a codec.
I'm not a mathematician and am therefore not with the real properties of H264 or other. I know only what I use and can adjust. And it often reminds me that I have given garnicht use and need.
However, since H264 requires licensing costs, it is not the right codec for me. I'm an idealist. I am using synonymous no proprietary software for everything else, so what I do.
Last question: What color what color would you support?
Hello motion group,
Dirac is already quite good, if only because he (L) GPL was made. I had almost decided to Dirac, but wanted to look again after snow, before I am determined. Let's see what happens.
Regards
Lars
Antwort von WoWu:
Hello Lars,
Thank you for dei information ...
Certainly my requirements are a little different than of a consumer, because we work exclusively for TV. As more and more demand for 720, we have provided as quickly as possible 720p50/60 in 4:4:4 with 12 bit to make. The result (for us of the selected profiles & Level) a data rate of approx. 200 Mbit / s and is thus more easily manageable.
Also of course, because we have archiving in Hintertkopf. Currently, we make some. 2min. Final day and already today to approx. 600 TB per year, which are archived and must be maintained. So 600 1 TByte plates per year.
Also in relation to the color actually comes to us for non-RGB YCoCg apply only in question because YUV never for use in the digital area was planned and the miserable and the poor Rundungsfehehler coding only lead to compromise. Hence the decision for YCoCg.
The thing with me, I would DIRAC synonymous again superior, especially in regard to your application. That you would, in my view, not really happy ... yet I would your motives for even interested.
Antwort von LarsProgressiv:
Good evening, Wolfgang,
schick doch mal a link to me the difference between YUV and YCoCg. I can not imagine that this makes sense for TV, but I like to learn.
So far I found only YCbCr.
Good night
Antwort von WoWu:
Hello Lars,
NVIDIA this paper is instructive:
http://developer.download.nvidia.com/whitepapers/2007/Real-Time-YCoCg-DXT-Compression/Real-TimeYCoCg-DXTCompression.pdf
Gruss Wolfgang
Antwort von LarsProgressiv:
Good morning, Wolfgang,
conversion, which is described in the paper is used but synonymous rounding. At least for the conversion back to RGB.
Furthermore, even a loss in the conversion to YCoCg.
If you really wanted to have losses, you have to have
Antwort von WoWu:
Hi Lars
this is not entirely correct, because De-encoder and still only add and shift operations for both processes require.
Also covered are difficult to implement values of coefficients away.
The desire for the color space is not unusual and is used in AVC FRExt supports, like the color in RGB 4:4:4. Currently you can but only with the VSoft implementation. But I'm pretty sure that other implementations follow.
As to your objection regarding YCoCg-R, it is precisely the greater dynamic, the YCoCg so interesting, because over yCoCg-R is just under 1 db greater. Microsoft has added the-R to a greater compression to reach ... But I think this is the wrong place s.dieser savings. There again, the multiplication process ..
The paper (link) is of 2003 and was an inspiration for the Standardisiertug thought ... obviously it is not then synonymous in the standard input.
But which camera is already in the RGB color space or on? Already clear, but that is just synonymous with such a codec, just because there was no camera in 4:4:4 recording, a meaningful way over the codec to find the corresponding depth data rates feasible to record and because we do 720p60 would at 4:4:4 and 12 bit with AVCFRext around. 200 Mbit / s ... and thus the data to us in relation to processing and archiving synonymous still appears manageable.
Only I think that in relation to the color space is finally announced, the old analog YUV braids cut off and to forget.
Will you now, therefore, a new, broader codec souvenirs, they should be requirements at least as satisfied.
You see, the bar for a new codec is high, on the other Page facilitate such requirements precisely the implementation again.
Antwort von LarsProgressiv:
Hello Wolfgang.
Hi Lars
this is not entirely correct, because De-encoder and still only add and shift operations for both processes require. Just because only add and shift operations are carried out, the transformation is not lossless car. But just incredibly fast.
Because, as in the reference is already there, the conversion of RGB to YCoCg with Bitverlust performed:
[code: 1:33 abb0aabb] Y = ((R + B)>> 1) + G)>> 1 [/ code: 1:33 abb0aabb]
This one loses both the low bit. And already there is the loss. Therefore YCoCg-R was developed because there is no loss. It should be noted here is that there is a conversion of 3 8-bit values in 3 8-bit values. Man can this loss, as described in the paper, so the field by each channel 2 more bits gifts. Then you make 8-bit RGB values (24 bits total) on 10-bit YCoCg values (30 bits total) from.
Other hand, fit 30-bit RGB values (10bit per channel) in the 32-bit color lossless YCoCg.
As to your objection regarding YCoCg-R, it is precisely the greater dynamic, the YCoCg so interesting, because over yCoCg-R is just under 1 db greater. Microsoft has added the-R to a greater compression to reach ... But I think this is the wrong place s.dieser savings. The Dynamics is according to the paper, but only by the dazugemogelten bits increases, which in the case of a conversion to RGB disappear.
This is synonymous with YCoCg the case, but
- 32-bit YCoCg-R can be used on 30-bit RGB lossless mapped and
- 30-bit YCoCg can only be used on 24-bit RGB lossless (or lossy on 30-bit RGB) will be displayed.
There again, the multiplication process .. Where is it? There are two directions in the (conversion), only addition and shift operations necessary. And still synonymous in equal numbers.
Regards
Lars
Antwort von WoWu:
If it is only the question of why the proposal is not incorporated in the standard, he is so much of Microsoft already into July Meeting 2003 have been introduced?
We must now look at the JVT / MPEG papers pursue. (idle)
It also happens, however, usually synonymous no return to the RGB signal.
But why should such a change could not be sampled at least once? Only of course would be interesting to know why the proposal was rejected.
Antwort von LarsProgressiv:
Hello Wolfgang,
I think I am correct.
Because the actual standard I am not really black and white I can not say with certainty, but it seems as if YCoCg-R in standard as YCoCg was incorporated.
At least I read this from:
Antwort von WoWu:
I hab'Rico Malvar times on my old MPEG-tbc account. Perhaps there is an answer, because the issue for me is not as high on the list.
Wait and see, then.
Antwort von WoWu:
@ Lars
Hello Lars,
Question was why the paper VT I014r3 not considered in the standard place.
The answer I received:
Dear Wolfgang,
I did not attend the JVT standard color spaces where meetings were discussed, so I do not know the reasons. My best guess is that one issue could have been backward compatibility with other codecs, for transcoding applications.
You may have noticed that YCoCg-R was adopted in the fidelity range extensions.
Best regards,
Rico Malvar That would be synonymous to explain why it is again in DIRAC.
In order to find the reason we now have the Meeting Minutes pick ... but the "give" then I do.
Antwort von LarsProgressiv:
Thanks Wolfgang!
Lars
Antwort von TheBubble:
I need a secure future codec, so I think a solution that turned my home movies and record packed with the corresponding sound in Vorbis in an open container (MKV) for the conserved _Ewigkeit_ usable.
It is therefore for me, my grandchildren and great-grandchildren and so be able to play the movies again.
The playability and support for new hardware and operating systems will probably not for very long periods of time guarantee (may). Even today, there are occasional problems with the reflect of old video recordings or data tapes.
You could try, as an archive format such a widely used codec to choose, that it can be assumed that even as long as possible the needs s.einer play the file exists. In addition, we own the movies not just forget for a long time, so that when it is currently used or supported codecs change in time can be converted.
And when I see an open standard as given, as documentation and source code associated with free care and free tuition to guarantee something.
Alone does not help anything, as long as you yourself would not be able to use the software to wait, possibly on new hardware and operating systems to adapt to port or re-implement or has enough money, then for someone to pay for these activities.
Reimplementation of the burden could be reduced by one codec elect or developed, whose play component as simple and well documented. Synonymous But then you would need someone who is so synonymous in the future make, even if it is compared to other codecs in use today is simpler.
And in addition we must at this project not forget that it is not just about the file, but synonymous, the media in which the data are stored in the future must still be readable. Again, backups and transfers on current technology plan.
