MultimediaWiki - Recent changes [en]

FFmpeg Summer of Code 2013

2013-03-06T19:57:14Z

/* glplay */

Revision as of 19:57, 6 March 2013		Current revision
Line 127:		Line 127:

	'''Description:''' The SDL library that is used by FFplay has some deficiencies, adding OpenGL output to FFplay should allow for better performance (and less bugs at least for some hardware / driver combinations). This could be a new application (glplay), but it is probably simpler to extend ffplay to use OpenGL. You can use code from MPlayer's OpenGL vo module which may be relicensed under the LGPL.		'''Description:''' The SDL library that is used by FFplay has some deficiencies, adding OpenGL output to FFplay should allow for better performance (and less bugs at least for some hardware / driver combinations). This could be a new application (glplay), but it is probably simpler to extend ffplay to use OpenGL. You can use code from MPlayer's OpenGL vo module which may be relicensed under the LGPL.
		+
		+	'''Mentor:''' TBD Backup: Reimar Döffinger

	=== Misc Libavfilter extension ===		=== Misc Libavfilter extension ===

FFmpeg Summer of Code 2013

2013-03-06T19:16:07Z

subtitles: expected results as bullet points

Revision as of 19:16, 6 March 2013		Current revision
Line 148:		Line 148:
	'''Qualification task:''' write or port one or more filter		'''Qualification task:''' write or port one or more filter

-	'''Mentor:''' Stefano Sabatini (''saste'' on IRC).	+	'''Mentor:''' Stefano Sabatini (''saste'' on IRC). Backup: Clément Bœsch (''ubitux'' on IRC).
		+
		+	=== Subtitles ===
		+
		+	'''Description:''' FFmpeg has been working on improving its subtitles support recently, notably by adding the support for various text subtitles and various hardsubbing (burning the subtitles onto the video) facilities. While the theme may sound relatively simple compared to audio/video signal processing, the project carry an historical burden not easy to deal with, and introduces various issues very specific to its sparse form.
		+
		+	'''Expected results:'''
		+	* Write the support for new subtitles formats. Example: a demuxer for .SUP files, just like VobSub but for Blu-Ray.
		+	* Improve text subtitles decoders. Typically, this can be supporting advanced markup features in SAMI or WebVTT.
		+	* Improve the API to facilitates a proper integration of subtitles into libavfilter.
		+
		+	'''Prerequisites:''' C coding skills, familiarity with git/source code control systems. Some background in fansubbing area (notably ASS experience) would be a bonus but is not strictly required.
		+
		+	'''Qualification task:''' write one subtitles demuxer or muxer, and do some improvements to the different layers of the subtitles (to make sure the whole chain is understood).
		+
		+	'''Mentor:''' Clément Bœsch (''ubitux'' on IRC).

	[[Category:FFmpeg]]		[[Category:FFmpeg]]

User:Adam Quantrill

2013-03-05T18:09:26Z

New page

Adam is a computing and electronics engineer currently working in Telecoms, specifically GSM basestations at IP Access Ltd near Cambridge, UK.

Hobbies include engineering, electronics, computing and fine real ale.

AMR-NB

2013-03-05T18:06:26Z

/* GSM OTA format */

Revision as of 18:06, 5 March 2013		Current revision
Line 34:		Line 34:

	== Bit stream frame format ==		== Bit stream frame format ==
-	Specification ([http://www.3gpp.org/ftp/Specs/html-info/26101.htm 26.101]) describes two possible frame types - interface formats 1 and 2 (often abbreviated IF1 and IF2). IF2 is byte-aligned. The following tables of data are taken from this specification unless otherwise stated.	+	Specification ([http://www.3gpp.org/ftp/Specs/html-info/26101.htm 26.101]) describes two possible frame types - interface formats 1 and 2 (often abbreviated IF1 and IF2). IF2 is byte-aligned. The following tables of data are taken from this specification unless otherwise stated. AMR-NB over GSM uses a third slightly different format whose bit-packing is tightly defined by the GSM specs.

	=== IF1 format ===		=== IF1 format ===
Line 91:		Line 91:
	\| Padding (called "Bit stuffing" in the specification)		\| Padding (called "Bit stuffing" in the specification)
	\|		\|
		+	\|}
		+
		+	=== GSM OTA format ===
		+
		+	{\| border=1
		+	! bits !! low level meaning \|\| high level meaning
		+	\|-
		+	\| 4
		+	\| Mode request
		+	\| rowspan=1 \| AMR auxiliary information
		+	\|-
		+	\| 1
		+	\| F bit (0 good/1 unusual)
		+	\| rowspan=3 \| AMR header
		+	\|-
		+	\| 4
		+	\| Frame Type
		+	\|-
		+	\| 1
		+	\| Frame quality indicator (0 bad/1 good)
		+	\|-
		+	\|
		+	\| Class A bits
		+	\| rowspan=3 \| AMR core frame
		+	\|-
		+	\| 6
		+	\| CRC
		+	\|-
		+	\|
		+	\| Class B bits
	\|}		\|}

Line 140:		Line 170:

	* Class A is protected by an 8-bit CRC with polynomial x^8+x^6+x^5+x^4+1 computed over the Class A bits.		* Class A is protected by an 8-bit CRC with polynomial x^8+x^6+x^5+x^4+1 computed over the Class A bits.
		+	* However for AMR-NB over GSM the CRC is a 6-bit with polynomial x^6+x^5+x^3+x^2+x+1 computed over the Class A bits, and it immediately follows the Class A bits, rather than preceding them. That is, it's between the Class A and Class B bits. [see 3GPP TS 05.03 sec 3.9.4.3]
	* There is no significant step-wise change in subjective importance at class boundaries.		* There is no significant step-wise change in subjective importance at class boundaries.
	* The distribution of bits is ordered from most to least subjective importance at both the class level and within the classes.		* The distribution of bits is ordered from most to least subjective importance at both the class level and within the classes.

Scream Tracker 3 Module

2013-03-03T02:13:53Z

/* File Format */ Mention how wide parapointers are

Revision as of 02:13, 3 March 2013		Current revision
Line 8:		Line 8:
	==File Format==		==File Format==

-	The format is little-endian (least significant byte first). A "byte" is 8 bits, a "word" is 16 bits, and a "dword" (double word) is 32 bits. Hex values will be denoted with "0x". A parapointer points to pp*16 in the file due to the DOS nature of the format.	+	The format is little-endian (least significant byte first). A "byte" is 8 bits, a "word" is 16 bits, and a "dword" (double word) is 32 bits. Hex values will be denoted with "0x". A parapointer is 16 bits wide, and points to pp*16 in the file due to the DOS nature of the format.

	Note that if some parts of the format are inconsistent, it's usually best to let it slip, as ST3 itself will allegedly for instance load instruments which don't have the "SCRS" / "SCRI" mark.		Note that if some parts of the format are inconsistent, it's usually best to let it slip, as ST3 itself will allegedly for instance load instruments which don't have the "SCRS" / "SCRI" mark.

User:Compn

2013-02-28T18:09:12Z

/* unknown codec */

Revision as of 18:09, 28 February 2013		Current revision
Line 184:		Line 184:
	[[User:Dashcloud\|Dashcloud]] 14:23, 20 February 2009 (EST)		[[User:Dashcloud\|Dashcloud]] 14:23, 20 February 2009 (EST)
	HHE1 - zvue video? hhe0 / hhe1 patent : http://www.freepatentsonline.com/y2007/0019741.html . looks like modified mpeg4.		HHE1 - zvue video? hhe0 / hhe1 patent : http://www.freepatentsonline.com/y2007/0019741.html . looks like modified mpeg4.
		+	.
		+	official website in archive hheld.com zvue.com
		+	zflicks 1.5 encodes to xvid, included with ZOrgInstall-1.0.1.exe
		+	all of the -zvue.avi files are created with zflicks 1.1 , but zflicks 1.1 does not include the hhe0 or hhe1 codec. only divx.dll (comes with 1.1) or xvid (comes with 1.5).
		+
		+
	speg - http://qstream.org/ appears to be an Xvid derivative- if you check out the source code, there's a patch mplayer-speg.patch		speg - http://qstream.org/ appears to be an Xvid derivative- if you check out the source code, there's a patch mplayer-speg.patch
	which just tacks SPEG onto all the xvid stuff. [[User:Dashcloud\|Dashcloud]] 14:23, 20 February 2009 (EST)		which just tacks SPEG onto all the xvid stuff. [[User:Dashcloud\|Dashcloud]] 14:23, 20 February 2009 (EST)

Summer of code

2013-02-27T18:41:06Z

fix redirect

Revision as of 18:41, 27 February 2013		Current revision
Line 1:		Line 1:
-	#redirect [[FFmpeg Summer Of Code]]	+	#redirect [[FFmpeg_/_Libav_Summer_Of_Code]]

FFmpeg Summer of Code 2013

2013-02-27T18:38:24Z

remove g2m task, 3 months is not enough time to reverse engineer and finish a spec.

Revision as of 18:38, 27 February 2013		Current revision
Line 57:		Line 57:

	== Video codecs ==		== Video codecs ==
-
-	=== GotoMeeting Decoder ===
-
-	'''Description:''' The [[GoToMeeting_Codec]] has been figured out and we need a decoder for it. We don't have samples for G2M1 so this decoder will focus on G2M2, G2M3 and G2M4 versions.

	=== HEVC / H265 ===		=== HEVC / H265 ===