Author: michael Date: Tue Jul 4 23:14:55 2006 New Revision: 18904 Modified: trunk/DOCS/tech/mpcf.txt Log: trying to end the codec id battle Modified: trunk/DOCS/tech/mpcf.txt ============================================================================== --- trunk/DOCS/tech/mpcf.txt (original) +++ trunk/DOCS/tech/mpcf.txt Tue Jul 4 23:14:55 2006 @@ -443,6 +443,8 @@ example: "H264" MUST contain 2 or 4 bytes, note, this might be increased in the future if needed + the id values used are the same as in avi, so if a codec uses a specific + fourcc in avi then the same fourcc MUST be used here time_base_nom / time_base_denom = time_base the length of a timer tick in seconds, this MUST be equal to the 1/fps @@ -716,6 +718,11 @@ "Source" "DVD", "VCD", "CD", "MD", "FM radio", "VHS", "TV", "LD" Optional: appended PAL, NTSC, SECAM, ... in parentheses + "SourceContainer" + "nut", "mkv", "mov", "avi", "ogg", "rm", "mpeg-ps", "mpeg-ts", "raw" + "SourceCodecTag" + the source codec id like a fourcc which was used to store a specific + stream in its SourceContainer "CaptureDevice" "BT878", "BT848", "webcam", ... (more exact names are fine too) "CreationTime"
2006/7/5, michael <subversion@mplayerhq.hu>:
Author: michael Date: Tue Jul 4 23:14:55 2006 New Revision: 18904
Modified: trunk/DOCS/tech/mpcf.txt
Log: trying to end the codec id battle
I hate this kind of blitzkrieg, that tries to establish new Status Quo. I'm afraid you just turn a struggle into full scale war. Actually this is how our struggle with Diego started. He ignored the discussion and made highly disputable commit. Then things escalated. Do you want the same?
Modified: trunk/DOCS/tech/mpcf.txt ============================================================================== --- trunk/DOCS/tech/mpcf.txt (original) +++ trunk/DOCS/tech/mpcf.txt Tue Jul 4 23:14:55 2006 @@ -443,6 +443,8 @@ example: "H264" MUST contain 2 or 4 bytes, note, this might be increased in the future if needed + the id values used are the same as in avi, so if a codec uses a specific + fourcc in avi then the same fourcc MUST be used here
What are we going to use for wav tags for audio formats that doesn't have official one? I have asked this quiestion about 5 times already.
time_base_nom / time_base_denom = time_base the length of a timer tick in seconds, this MUST be equal to the 1/fps @@ -716,6 +718,11 @@ "Source" "DVD", "VCD", "CD", "MD", "FM radio", "VHS", "TV", "LD" Optional: appended PAL, NTSC, SECAM, ... in parentheses + "SourceContainer" + "nut", "mkv", "mov", "avi", "ogg", "rm", "mpeg-ps", "mpeg-ts", "raw" + "SourceCodecTag" + the source codec id like a fourcc which was used to store a specific + stream in its SourceContainer
That would be better to be named "SourceStreamTag" . I'd also like to have "SourceEncoder" that contains the name and version of the encoder.
"CaptureDevice" "BT878", "BT848", "webcam", ... (more exact names are fine too) "CreationTime"
BTW, why chapter_id/start/len are mandatory fields in the info packet and not entries like all the rest?
Ivan Kalvachev wrote:
Modified: trunk/DOCS/tech/mpcf.txt ==============================================================================
--- trunk/DOCS/tech/mpcf.txt (original) +++ trunk/DOCS/tech/mpcf.txt Tue Jul 4 23:14:55 2006 @@ -443,6 +443,8 @@ example: "H264" MUST contain 2 or 4 bytes, note, this might be increased in the future if needed + the id values used are the same as in avi, so if a codec uses a specific + fourcc in avi then the same fourcc MUST be used here
What are we going to use for wav tags for audio formats that doesn't have official one? I have asked this quiestion about 5 times already.
I think we could use mov ones or just made up ourselves.
time_base_nom / time_base_denom = time_base the length of a timer tick in seconds, this MUST be equal to the 1/fps @@ -716,6 +718,11 @@> Modified: trunk/DOCS/tech/mpcf.txt ==============================================================================
--- trunk/DOCS/tech/mpcf.txt (original) +++ trunk/DOCS/tech/mpcf.txt Tue Jul 4 23:14:55 2006 @@ -443,6 +443,8 @@ example: "H264" MUST contain 2 or 4 bytes, note, this might be increased in the future if needed + the id values used are the same as in avi, so if a codec uses a specific + fourcc in avi then the same fourcc MUST be used here
What are we going to use for wav tags for audio formats that doesn't have official one? I have asked this quiestion about 5 times already.
I think we could use mov ones or just made up ourselves. ,,,,,,,,
"Source" "DVD", "VCD", "CD", "MD", "FM radio", "VHS", "TV", "LD" Optional: appended PAL, NTSC, SECAM, ... in parentheses + "SourceContainer" + "nut", "mkv", "mov", "avi", "ogg", "rm", "mpeg-ps", "mpeg-ts", "raw" + "SourceCodecTag" + the source codec id like a fourcc which was used to store a specific + stream in its SourceContainer
That would be better to be named "SourceStreamTag" .
I like better SourceContainer or SourceTag
I'd also like to have "SourceEncoder" that contains the name and version of the encoder.
"CaptureDevice" "BT878", "BT848", "webcam", ... (more exact names are fine too) "CreationTime"
BTW, why chapter_id/start/len are mandatory fields in the info packet and not entries like all the rest?
Those are informative, chapter stuff could change radically the playback. -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
2006/7/5, Luca Barbato <lu_zero@gentoo.org>:
Ivan Kalvachev wrote:
BTW, why chapter_id/start/len are mandatory fields in the info packet and not entries like all the rest?
Those are informative, chapter stuff could change radically the playback.
Then it would be better if they have their own packet type, coz info packet somehow sound informative to me.
On Wed, Jul 05, 2006 at 03:45:03PM +0200, Luca Barbato wrote:
I'd also like to have "SourceEncoder" that contains the name and version of the encoder.
"CaptureDevice" "BT878", "BT848", "webcam", ... (more exact names are fine too) "CreationTime"
BTW, why chapter_id/start/len are mandatory fields in the info packet and not entries like all the rest?
Those are informative, chapter stuff could change radically the playback.
No, this is the wrong explanation. The key/value pairs in the info packet tell information _about the content_ to which they apply. The chapter_id/start/len fields, like the stream_id, tell which part of the file the info tags apply to. These are completely different issues. For those who don't remember this issue was discussed to death a year or so ago. Rich
Hi On Wed, Jul 05, 2006 at 12:43:50PM +0300, Ivan Kalvachev wrote:
2006/7/5, michael <subversion@mplayerhq.hu>:
Author: michael Date: Tue Jul 4 23:14:55 2006 New Revision: 18904
Modified: trunk/DOCS/tech/mpcf.txt
Log: trying to end the codec id battle
I hate this kind of blitzkrieg, that tries to establish new Status Quo. I'm afraid you just turn a struggle into full scale war.
Actually this is how our struggle with Diego started. He ignored the discussion and made highly disputable commit. Then things escalated. Do you want the same?
no, i want nut finished and useable, not delay it by months or years due to minor things like the codec id if we cant finish nut iam fine with leaving nut development and simply publishing my own nut like format outside svn, you can then keep this "struggle" going on ad infinitum with whoever doesnt unsubscribe from nut-devel AFAIK you didn find a single issue with the avi based suggestion, your suggestion IIRC was based on a new nut specific id system, which noone, not even you are willing to implement and maintain ... so complaining about my commit really is trolling and nothing else, suggest and implement some other solution, if its better noone will object but as long as you have no alternative or arent willing to implemet it (the avi based system doensnt need any real work to be done as avi fourccs are already supported ...) then you really should not complain
Modified: trunk/DOCS/tech/mpcf.txt ============================================================================== --- trunk/DOCS/tech/mpcf.txt (original) +++ trunk/DOCS/tech/mpcf.txt Tue Jul 4 23:14:55 2006 @@ -443,6 +443,8 @@ example: "H264" MUST contain 2 or 4 bytes, note, this might be increased in the future if needed + the id values used are the same as in avi, so if a codec uses a specific + fourcc in avi then the same fourcc MUST be used here
What are we going to use for wav tags for audio formats that doesn't have official one? I have asked this quiestion about 5 times already.
this is completly independant of the id system, in every system you will always have to deal with codecs which have no tag (yet)
time_base_nom / time_base_denom = time_base the length of a timer tick in seconds, this MUST be equal to the 1/fps @@ -716,6 +718,11 @@ "Source" "DVD", "VCD", "CD", "MD", "FM radio", "VHS", "TV", "LD" Optional: appended PAL, NTSC, SECAM, ... in parentheses + "SourceContainer" + "nut", "mkv", "mov", "avi", "ogg", "rm", "mpeg-ps", "mpeg-ts", "raw" + "SourceCodecTag" + the source codec id like a fourcc which was used to store a specific + stream in its SourceContainer
That would be better to be named "SourceStreamTag" .
i disagree, but of course the name is totally irrelevant ...
I'd also like to have "SourceEncoder" that contains the name and version of the encoder.
we already have that and its called "Encoder" [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In the past you could go to a library and read, borrow or copy any book Today you'd get arrested for mere telling someone where the library is
On Thu, Jul 06, 2006 at 01:02:01AM +0200, Michael Niedermayer wrote:
Hi
On Wed, Jul 05, 2006 at 12:43:50PM +0300, Ivan Kalvachev wrote:
2006/7/5, michael <subversion@mplayerhq.hu>:
Author: michael Date: Tue Jul 4 23:14:55 2006 New Revision: 18904
Modified: trunk/DOCS/tech/mpcf.txt
Log: trying to end the codec id battle
I hate this kind of blitzkrieg, that tries to establish new Status Quo. I'm afraid you just turn a struggle into full scale war.
Actually this is how our struggle with Diego started. He ignored the discussion and made highly disputable commit. Then things escalated. Do you want the same?
no, i want nut finished and useable, not delay it by months or years due to minor things like the codec id
couldn't have put it better... i don't necessarily like the wording the way you added it to the spec but any complaints are minor. maybe i'll suggest some minor changes. rich
participants (5)
-
Ivan Kalvachev -
Luca Barbato -
michael -
Michael Niedermayer -
Rich Felker