June 2008 - ffmpeg-devel - lists.ffmpeg.org

[FWD] [PATCH] immediate decoding of dvd stills
by nicola_sabbi＠fastwebnet.it 24 Jun '11

24 Jun '11

Some time ago someone posted this small patch to permit decoding dvd still images without setting LOW_DELAY; unfortunately it seems the patch was forgotten Is it ok to commit? If not, what's the right way to proceed?

5 17

[PATCH] DCA-in-WAV detection
by kostya.shishkov＠gmail.com 26 Jan '11

26 Jan '11

Here is my attempt on patch discussed on Febryary 2006 Thread called "[PATCH] Fix DTS in WAV file playback."

7 12

[PATCH] Apple Video Encoder (rpza)
by ffmpeg.php＠gmail.com 24 Jan '11

24 Jan '11

Attached is a patch to add support for Apple Video encoding (rpza). The quality settings are defined at compile time right now since I wasn't really sure how to map ffmpeg's numerous video options to the capabilities of rpza. It supports all rpza encoding opcodes but the 4-color block encoding doesn't try to do multiblock runs yet. -Todd

9 20

[PATCH]wmv3 encoder
by fortin＠nerim.net 23 Jan '11

23 Jan '11

Hi, The following patch adds a wmv3 encoder (i removed the vc1 encoder because it doesn't generate an elementary stream). I don't think i can split the patch without breaking compilation between two patches. Please comment (particularly the vc1enc.h include in mpegvideo.c). Thanks, Denis

5 6

[PATCH] Chinese AVS encoder
by stefan.gehrer＠gmx.de 23 Jan '11

23 Jan '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, as announced before here is my encoder for Chinese AVS. Features that it does support: - - Intra macroblocks - - P_SKIP macroblocks - - P_16x16 macroblocks - - one or two reference frames - - constant quantizer encoding - - motion estimation using hexagon search and qpel refinement Features that it does not support: - - P_16x8, P_8x16 and P_8x8 macroblocks - - B macroblocks/frames - - rate control - - anything else you might think of To test it, here is a sample command line ./ffmpeg -i in.avi -vcodec cavs -strict -2 -cqp 30 -refs 2 -psnr out.avi - -strict -2 is required for the encoder's experimental nature, I have not thought much about its standard conformance, just that it decodes with my decoder. - -cqp n with n in the range 0 to 63 is required as only fixed quantizer encoding is supported - -refs 2 is optional, one reference frame would be the default - -psnr is optional Michael, regarding your question on cvslog (sorry for crossposting, I wasn't subscribed to cvslog at the time): >> Author: stefang >> Date: Sat Jul 7 09:14:58 2007 >> New Revision: 9518 >> >> Log: >> move dequantization into it's own inline function > >why inline? same question for the other inline functions >is there some speed gain from duplicating them in the object files >between encoder and decoder? To be honest I did not think much about object size, it just seemed to be a convenient way to share functions this way instead of having to create ff_cavs_foobar names and without creating function call overhead that was not there before. If you think object size would be a problem I can of course move some functions back from cavs.h to cavs.c. Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGocyhYpYOlpT3vNMRArJrAKC5aQQ40GEmegoLh8u0b0HCc0f60QCgzgc4 tMea5NiHbnlzxikJYvkl9Q4= =0R8q -----END PGP SIGNATURE-----

5 10

[PATCH] Implement PAFF in H.264
by heydowns＠borg.com 26 Mar '10

26 Mar '10

Attached is a patch that implements PAFF in H.264. I don't expect this to be accepted right away, due to size and complexity, but I want to get it out there for review and for people to try out and comment on. It is working stable for me on a number of samples, including ones that mix PAFF with progressive and/or MBAFF. Basic overview of how it works: 1. Fields are decoded and deinterlaced. 2. If non-paired fields are encountered, they are not output, but are used for reference if so marked. 3. Reference lists are kept as they were before, but now may also contain unmatched field pairs. Reference list construction splits field pairs out to fields as needed. There is a major shortcoming/known issue with this patch; it disables the error concealing calls for field pictures. This is because the error concealer needs slices to be contiguous regions of the picture buffers. I'd appreciate input on how best to augment the error concealer to handle interlaced slices (or if I am just missing something....) Also interested in hearing how this should be split into smaller patches (I know that at least the addition/changes to header documentation should come out). -Jeff

15 101

[PATCH] GSM-MS decoder and encoder
by mbardiaux＠mediaxim.be 01 Feb '10

01 Feb '10

-- Michel Bardiaux R&D Director T +32 [0] 2 790 29 41 F +32 [0] 2 790 29 02 E mailto:mbardiaux at mediaxim.be Mediaxim NV/SA Vorstlaan 191 Boulevard du Souverain Brussel 1160 Bruxelles http://www.mediaxim.com/

6 56

yuv2rgb_template.c uses MOVNTQ but not SFENCE?
by Reimar.Doeffinger＠stud.uni-karlsruhe.de 12 Jan '10

12 Jan '10

Can someone comment if this is right? It seems like a bug according to the documentation I have... Greetings, Reimar D?ffinger

3 5

[PATCH] Make ffplay define in the encoder the number of threads *before* to open it
by stefano.sabatini-lala＠poste.it 28 Dec '09

28 Dec '09

Hi, as in $subject. If threads support is not enabled and threads count is set to a value greater than MAX_THREADS (currently is 8), then encoder is initialized with a value of thread_count equal to 1, then enc->threads_count is set to the value set by the user, finally libavcodec crashes when it tryies to free the first thread beyond MAX_THREADS (this happens when quitting ffplay). Check it with: ffplay -threads 1000 FILE.flv (crashes in libavcodec/mpegvideo.c:MPV_common_end) With the patch we get: stefano at geppetto ~> ~/src/ffmpeg/ffplay -threads 1000 FILE.flv Warning: not compiled with thread support, using thread emulation [flv @ 0x83fba40]too many threads then ffplay reproduces the file with no video. Best regards. -- Stefano Sabatini Linux user number 337176 (see http://counter.li.org)

3 18

[PATCH] estimate stream durations using read_timestamp
by elupus＠ecce.se 27 Dec '09

27 Dec '09

Hi, Here is a patch for libavformat to estimate stream durations using the read_timestamp interface. This could most likely replace the special casing for mpeg using read_packet. Thou i've not yet checked that. Joakim Ps. Patch probably applies at an offset, but it's not against latest svn. Will resend with that after inital comments.

3 7