February 2008 - NUT-devel - lists.mplayerhq.hu

[nut]: r644 - docs/nut.txt
by michael 04 Mar '08

04 Mar '08

Author: michael Date: Fri Feb 29 03:25:11 2008 New Revision: 644 Log: clarify default Modified: docs/nut.txt Modified: docs/nut.txt ============================================================================== --- docs/nut.txt (original) +++ docs/nut.txt Fri Feb 29 03:25:11 2008 @@ -931,7 +931,10 @@ info packet types A demuxer MUST ignore unknown language and country codes instead of treating them as an error. "Disposition" - "original", "dub" (translated), "comment", "lyrics", "karaoke", "default" + "original", "dub" (translated), "comment", "lyrics", "karaoke", + "default" + Streams which the creator of the file intended to be played by + default. A player can follow this suggestion or ignore it. Note: If someone needs some others, please tell us about them, so we can add them to the official standard (if they are sane). Note: Nonstandard fields should be prefixed by "X-".

4 7

[nut]: r643 - docs/nut.txt
by michael 01 Mar '08

01 Mar '08

Author: michael Date: Fri Feb 29 02:55:36 2008 New Revision: 643 Log: Add "default" disposition, matroska supports that too and it might be usefull in some obscure cases. Modified: docs/nut.txt Modified: docs/nut.txt ============================================================================== --- docs/nut.txt (original) +++ docs/nut.txt Fri Feb 29 02:55:36 2008 @@ -931,7 +931,7 @@ info packet types A demuxer MUST ignore unknown language and country codes instead of treating them as an error. "Disposition" - "original", "dub" (translated), "comment", "lyrics", "karaoke" + "original", "dub" (translated), "comment", "lyrics", "karaoke", "default" Note: If someone needs some others, please tell us about them, so we can add them to the official standard (if they are sane). Note: Nonstandard fields should be prefixed by "X-".

3 2

[nut]: r642 - docs/nut4cc.txt
by aurel 27 Feb '08

27 Feb '08

Author: aurel Date: Wed Feb 27 19:20:48 2008 New Revision: 642 Log: add VP7 fourcc Modified: docs/nut4cc.txt Modified: docs/nut4cc.txt ============================================================================== --- docs/nut4cc.txt (original) +++ docs/nut4cc.txt Wed Feb 27 19:20:48 2008 @@ -59,6 +59,7 @@ VP50 VP 5.0 VP60 VP 6.0 VP61 VP 6.1 VP62 VP 6.2 +VP70 VP 7.0 WMV1 MS WMV7 WMV2 MS WMV8 WMV3 MS WMV9

1 0

Frame/Field problem
by Michael Niedermayer 23 Feb '08

23 Feb '08

Hi When we designed the pts->dts reorder algorithm we considered arbitrary frame reorderings, but there was something we missed, that are mixes of frame and field pictures, like: i1 p2 P3 p4 P5 p7 P8 (lower case is a field, upper is a frame) PTS 2 3 4 6 7 9 10 DTS 0 1 2 4 5 7 8 As you can see no reordering of PTS can result in the DTS values. The reason why this fails is (if my brain still works at 5:30am) that frame pictures contain 2 fields and thus would have to be counted like 2 besides that they would really need 2 pts. I suspect some solution based on dummy 0byte packets with the missing pts after each frame might solve this, but i must think more about this ... -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire

3 7

[nut]: r641 - docs/nut.txt
by michael 23 Feb '08

23 Feb '08

Author: michael Date: Sat Feb 23 01:02:17 2008 New Revision: 641 Log: transmit_ts Modified: docs/nut.txt Modified: docs/nut.txt ============================================================================== --- docs/nut.txt (original) +++ docs/nut.txt Sat Feb 23 01:02:17 2008 @@ -416,11 +416,14 @@ info_packet: type= "v" } } + main_flags v reserved_bytes syncpoint: global_key_pts t back_ptr_div16 v + if(main_flags & BROADCAST_MODE) + transmit_ts t reserved_bytes Complete definition: @@ -488,6 +491,10 @@ max_distance (v) This is also half the maximum frame size without a checksum after the frame header. +main_flags (v) + Bit Name Description + 0 BROADCAST_MODE Set if broadcast mode is in use. + max_pts_distance (v) Maximum absolute difference of the pts of the new frame from last_pts in @@ -811,6 +818,12 @@ global_key_pts (t) global_key_pts MUST be bigger or equal to dts of all past frames across all streams, and smaller or equal to pts of all future frames. +transmit_ts (t) + The value of the reference clock at the moment when the first bit of + transmit_ts is transmitted/received. + The reference clock MUST always be less than or equal to the DTS of + every not yet completely received frame. + Index tags: -----------

1 0

[nut]: r640 - docs/nut4cc.txt
by lorenm 23 Feb '08

23 Feb '08

Author: lorenm Date: Sat Feb 23 00:44:53 2008 New Revision: 640 Log: typo Modified: docs/nut4cc.txt Modified: docs/nut4cc.txt ============================================================================== --- docs/nut4cc.txt (original) +++ docs/nut4cc.txt Sat Feb 23 00:44:53 2008 @@ -58,7 +58,7 @@ VP31 VP 3.1 VP50 VP 5.0 VP60 VP 6.0 VP61 VP 6.1 -VP61 VP 6.2 +VP62 VP 6.2 WMV1 MS WMV7 WMV2 MS WMV8 WMV3 MS WMV9

1 0

Another suggestion for broadcast [PATCH]
by Michael Niedermayer 20 Feb '08

20 Feb '08

Hi Heres a third try, the first was transmit_ts with unspecified buffers second was transmit_ts with a single specified buffer Here now comes the buffer state per syncpoint. It trivially allows the demuxer to find the needed preload, and allows trivial clock synchronization. Iam not sure how much more or less device dependant this is. It surely looks better if one considers broadcasting at a higher bitrate than the intended one. (lower will fail as with all other proposals) Also this is the smallest solution so far, and likely also has less overhead than the transmit_ts. -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato

5 57

[nut]: r615 - docs/nut4cc.txt
by cladisch 20 Feb '08

20 Feb '08

Author: cladisch Date: Tue Feb 12 16:46:50 2008 New Revision: 615 Log: clarify which of the MPEG-4 video codecs is meant Modified: docs/nut4cc.txt Modified: docs/nut4cc.txt ============================================================================== --- docs/nut4cc.txt (original) +++ docs/nut4cc.txt Tue Feb 12 16:46:50 2008 @@ -32,7 +32,7 @@ MJPG ITU JPEG MPG4 MS MPEG4v1 (!NOT ISO MPEG4!) MP42 MS MPEG4v2 MP43 MS MPEG4v3 -MP4V ISO MPEG4 Video +MP4V ISO MPEG4 Part 2 Video mpg1 ISO MPEG1 Video mpg2 ISO MPEG2 Video MRLE MS RLE

4 12

PCM sample format [PATCH]
by Michael Niedermayer 17 Feb '08

17 Feb '08

Hi see attached -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already.

3 7

[nut]: r639 - docs/nut.txt
by michael 17 Feb '08

17 Feb '08

Author: michael Date: Sun Feb 17 14:55:36 2008 New Revision: 639 Log: Clarify how to identify the raw video/audio sample format. Modified: docs/nut.txt Modified: docs/nut.txt ============================================================================== --- docs/nut.txt (original) +++ docs/nut.txt Sun Feb 17 14:55:36 2008 @@ -517,6 +517,8 @@ fourcc (vb) 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. + For raw video and audio, the used sample format (signed/unsigned, + 8/16/32bit, big/little endian, rgb/yuv) is indicated by the fourcc. time_base_num (v) / time_base_denom (v) = time_base the length of a timer tick in seconds, this MUST be equal to the 1/fps

1 0