February 2011 - ffmpeg-devel - lists.ffmpeg.org

[Toy] MS Video 1 encoder
by kostya.shishkov＠gmail.com 04 May '11

04 May '11

Here's a result of sleepless day :). With a small patch to ELBG it was possible to implement simple 15-bit MSVC encoder. At least it can encode more or less recognizable video. Since I have no intentions nor time to polish it, feel free to use it as you like - finish, rework into RPZA encoder, add link to this post to "Interesting patches" on Multimedia Wiki and forget it, whatever. (I should be working on AAC encoder anyway)

5 5

[PATCH] support for flvtool2 "keyframes based" generated index in FLV format decoder
by kharkovalexander＠gmail.com 08 Apr '11

08 Apr '11

Hi, Attached patch parse flvtool2 metadata "keyframes (times/fileopstions)" tags and use this data as index at least for seek operations. It is required in case when mplayer which use this part of ffmpeg code attempts to play FLV file via HTTP for example. Existing implementation attempt to download ALL content up to seek point before it can play it, but it is unacceptable to download unneded data (whole file if you seek to the end) as in case of low bandwidth seek operation will 'never' end. With this patch 'mplayer' can seek fast in such situations using this index. Alexander

5 20

[patch] yadif code dump
by james.darnley＠gmail.com 05 Apr '11

05 Apr '11

Since I can't duplicate code any more, I put my additions into lavfi, enjoy.

5 6

-newvideo stream order regression ?
by chris.stones＠gmail.com 02 Apr '11

02 Apr '11

# ffmpeg-SVN-r20373 -i INPUT_A (OPTIONS_A) OUTPUT -i /INPUTB (OPTIONS B) -newvideo would place INPUT_A with OPTIONS_A at stream index 0, and INPUT_B with OPTIONS_B at stream index 1. # ffmpeg-SVN-r22815 -i INPUT_A (OPTIONS_A) OUTPUT -i /INPUTB (OPTIONS B) -newvideo would place INPUT_B with OPTIONS_A at stream index 0, and INPUT_A with OPTIONS_B at stream index 1. The documentation doesnt imply stream orders, but the old behaviour makes alot more sence to me. Please confirm that this change was not intentional. I will investigate. Thanks. Chris.

2 1

Michael's ffmpeg.c patch - Favor streams with more packets if the user did not specify what she wants.
by chris.stones＠gmail.com 02 Apr '11

02 Apr '11

This patch http://git.ffmpeg.org/?p=ffmpeg;a=commitdiff;h=920cfe58c3137df7df8070bf3c3e… fixes an old issue ( https://roundup.ffmpeg.org/issue1156 ) But changes the behavior of the command line options, breaks my software ( and therefore probably other FFmpeg reliant software ). And in my opinion, makes the command line options more difficult to understand and error-prone. Take a look at the following command line, it encodes one video as Mpeg4, and one as SNOW. each with different qscales. ~/workspace/ffmpeg/ffmpeg -i /tmp/2snut_wJ6sAf/rgb%06d.png -strict -2 -vcodec snow -pix_fmt yuv420p -qscale 2.0 -f nut -y ~/test1.nut -i /tmp/2snut_wJ6sAf/a%06d.png -strict -2 -vcodec mpeg4 -pix_fmt yuv420p -qscale 6.0 -newvideo Before the above patch, it was easy to see that rgb%06d.png would be encoded with the SNOW codec, at quantize scale 2, and video a%06d.png would be encoded as an mpeg4, with a 6.0 quantize scale. However, after the patch, because order is determined by number of packets, it is impossible for the user to know what is going to be encoded with what settings / which codec. In the case of my sample media ( both videos are identical in frame number and resolution, but a%06d.png is much smaller. ) the a%06d.png video is encoded with snow, qscale 2. and a%06d.png is an mpeg4 at qscale 6. in other words, every script, everywhere is going to need to add "-map 0.0 -map 1.0 .... -map n.0" to the end of every "-newvideo" option. If this patch is not going to be un-done, then I think the documentation needs updating, as the implicit order of "-newvideo" nolonger is nolonger sane ? But thats just my opinion.. Any thoughts ???? THANKS Chris.

4 5

MxPEG decoder
by anatoly.nenashev＠ovsoft.ru 31 Mar '11

31 Mar '11

Hi! The previous version of this patch got lost in all the noise. Also it needs some changes to new API. Here is the last version of MxPEG decoder patch. Regards, Anatoly.

10 52

JPEG 2000
by rukhsana.afroz＠gmail.com 28 Mar '11

28 Mar '11

Hi, My name is Rukhsana Ruby. I am looking for Loren Merritt<http://wiki.multimedia.cx/index.php?title=User:Pengvado>who was the mentor for JPEG 2000 encoder and decode in GSoC last year. The project is unfinished and I want to finish this project. If anybody has an idea how to get to Loren Merritt<http://wiki.multimedia.cx/index.php?title=User:Pengvado>, please let me. I truly appreciate your help. I need to see the unfinished code, document s of this mini project. Thanks Ruby -- Rukhsana Ruby Phd Student Department of Electrical & Computer Engineering The University of British Columbia ============================

9 21

[PATCH] SubRip encoder
by aurel＠gnuage.org 27 Mar '11

27 Mar '11

Hi, Attached patch implements a SubRip subtitle encoder. The code used to parse ASS syntax and split it into basic elements is in a file of its own. It will be useful for any other text subtitle encoder. Aurel

3 3

[RFC] Bayer colorspaces: CODEC_ID, PIX_FMT or both?
by pross＠xvid.org 17 Mar '11

17 Mar '11

Hi, Any ideas/comments/opinions on how bayer colorspaces should be handled by FFmpeg. Here the advantages that I can see of each approach. 1. PIX_FMT Enables avfilters to be written that operate on native bayer colorspace. Other users of libswscale can take advantage of these. 2. CODEC_ID Easy route; no changes required to libswscale, pixdesc, et al 3. BOTH (CODEC_ID and PIX_FMT) Some bayer implementations pack the samples. e.g. 12-bit RGGB, means each sample consumes 12 bits in memory. Other bayer implementations pad each samples out to 16-bits. A hybrid implementation would have PIX_FMTs defined for 8-bit and 16-bit sample sizes, and make a BAYER codec available to unpack the samples into PIX_FMT_BAYER_xxxx16{LE|BE} Comments? -- Peter (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)

4 3

[PATCH] CrystalHD decoder support v6
by philipl＠overt.org 15 Mar '11

15 Mar '11

Hi all, A relatively minor update Changes ------- * Fixed off-by-one error in source-stride on 70012 * Implemented an adaptive delay mechanism for the enforced delay between decode() calls. Still not perfect but now handles a wider range of samples. Outstanding issues ------------------ No change here: * 70012 still doesn't work right. It needs different decode() timing and I haven't investigated it completely. * Interlaced H.264 support remains incomplete due to lack of a way to distinguish the cases. MBAFF as produced by x264 is assumed for now. --phil

2 7