January 2006 - ffmpeg-devel - lists.ffmpeg.org

improving encoding (possibly big perceptual gains)
by dalias＠aerifal.cx 02 Jan '06

02 Jan '06

with all the recent discussions over improving lavc, i've got some ideas. mainly i'm worried that psnr is very misleading when trying to improve motion estimation decisions since often a particular motion vector will give better psnr but much worse actual quality due to loss of small detail and mud/blocking. because of this, i'd like to suggest that lavc be extended to measure the 'uqi' (universal [image] quality index) proposed by the paper at this site: http://www.cns.nyu.edu/~zwang/files/research/quality_index/demo_lena.html i think the images there speak for themselves regarding how stupid psnr is as a judge of quality. however, printing statistics isn't much use if you can't actually improve encoding. so the main idea is too add a *cmp function to measure the uqi and use this for motion estimation and optimal quantization and qprd, etc. maybe also the ratecontrol engine itself. this should do a much better job of telling when it's ok to use poor quantization, zero ac coeffs, etc. and when it will look like shit (like the last lena picture ;). the next more ambitious idea is for future codecs, perhaps snow: to use only the correlation part of uqi to evaluate motion vectors, then measure the difference in mean and variance and store those in the bitstream. this would allow complex changes such as fades and changes in lighting to be encoded almost entirely with motion vectors, whereas mpeg4 codecs usually use dct-coded residue for such scenes with horrible quality as the result unless qp is 2 or less. ideas, anyone? sorry i'm too lame to code on lavc.. actually i don't know the codebase and i'm busy working on another project right now. however the *cmp system seems extensible enough that adding a uqi method to it should be easy. the other things (quantization, qprd, rate control) might be more difficult. rich

4 5

[PATCH] second attempt to auto_guess streams in mpegts
by nsabbi＠tiscali.it 02 Jan '06

02 Jan '06

This patch permits to recognize some more mpegts samples: the ones that contain neither SDT nor PAT/PMT (although they are hardly mpegts). It simply tries to rescan the content with ts->auto_guess=1 if the first iteration fails. P.S. sometimes it's necessary to analyze a large amount of data to find something useful (e.g. not encrypted streams), even some MB. Is there a parameter to identify such "probing range"? Bye, Nico

3 2

[PATCH] support for DVHS mpegts (192 bytes)
by nsabbi＠tiscali.it 02 Jan '06

02 Jan '06

The subject says everything.

3 2

[BUG] TSCC wrong colors on PPC
by diego＠biurrun.de 02 Jan '06

02 Jan '06

It looks like our TSCC decoder has some endianess issues still. I get wrong colors when I play on my PPC, while my x86 is fine. I've put up some samples that demonstrate the issue: ftp://sandman.homedns.org/diego/tscc/ Interestingly it seems that only 32bpp and 16bpp TSCC samples are affected. The 24bpp sample I have is fine. 32bpp: ftp://sandman.homedns.org/diego/tscc/2004-12-17-uebung9_small.avi 16bpp: ftp://sandman.homedns.org/diego/tscc/TI_1_Einfuehrung.avi ftp://sandman.homedns.org/diego/tscc/oneminute.avi 24bpp: ftp://sandman.homedns.org/diego/tscc/tscc.avi Here are two screenshots that demonstrate the problem with the oneminute.avi sample: ftp://sandman.homedns.org/diego/tscc/x86.jpg ftp://sandman.homedns.org/diego/tscc/ppc.jpg Diego

1 0

[Ffmpeg-devel-old] news alert
by asphalt＠fnbofdwight.com 02 Jan '06

02 Jan '06

DARK DYNAMITE INC (OTC BB:DKDY.OB) UP 0.25 (15.43%) on Friday We feel that this is a move for everyday starting Jan 3, 2006 Market Cap: 1.16M Current Price: $1.87 Short Term: $5.00 As we look for that One Special deal that the public has not come across we Find DKDY. We gave it to our Clients one week ago at $1.25 and everyday have watch in amazement as this Company is trading and growing every second. We have no choice but to release this as a Very Special Plat to ALL our clients and say you must watch this first thing Tuesday morning as we see BIG things happening. WE TELL YOU TO WATCH!!! STILL NOT TOO LATE! TRADING ALERT!!! Timing is everything!!! Profits of 200-400% EXPECTED TRADING DKDY is also on The REG SHO Threshold list, This means someone is short the ST0CK. Any significant volume spike in DKDY could yield drastic results. If the people that are short have to cover, they will be buying the shares from you at higher prices. This makes this ST0CK a TRIPLE PLAY for profits. For pennies you can participate in a ST0CK that could yield results over and over again just based on the trading patterns if the company is able to effectuate it DKDY'S business model. WATCH OUT!!! We could see a GREAT STORY IN THE MAKING. ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Ffmpeg-devel mailing list Ffmpeg-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ffmpeg-devel

1 0

next stable release
by rosti.bsd＠gmail.com 02 Jan '06

02 Jan '06

Hi, I've read the latest ffmpeg/Changelog on your CVSweb site and found there many interesting things about the next stable version of FFmpeg. When that version is planed to be released? Thank you for your work and good holidays! P.S. please Cc your reply to me, since I'm not subscribed to this mailing list.

4 4

mmx/sse optimizations
by ffmpeg＠engene.se 02 Jan '06

02 Jan '06

Out of curiosity I was googling for mmx & sse info and stumbled upon: http://www.tommesani.com He has a program to aid development of mmx/sse optimizations. Has anybody here used it? If so, any opinions about it? Best regards, Marcus

7 17

Re: ffmpeg mp4 demuxer doesnt handle 64bit
by b-o-n-d＠gmx.net 01 Jan '06

01 Jan '06

> > I tried to fix it but I don't know if it works as I don't have any test > > file with version1 mdhd that I know of. > > > > plese cvs up and test. > > great i will try it asap ok i now tried it and mplayer now plays the file with latest ffmpeg demuxer, still there is a problem: the framerate is far off, it should be 29.97 but 15712911.000 fps get used. i guess thats maybe because the duration is not recognized as being 64bit too (timescale is always 32bit)? > > > type mdia > > > type mdhd > > > version = 1 (0x01) > > > flags = 0 (0x000000) > > > creationTime = 3218293987 (0x00000000bfd344e3) > > > modificationTime = 3218295051 (0x00000000bfd3490b) > > > timeScale = 15712911 (0x00efc28f) > > > > So is it 32 or 64 bits here ?? > > > > > duration = 4525654016 (0x000000010dc00000) > > creation/modtime and duration is 64bit, as mentioned in the specs > > > > language = 21956 (0x55c4) > > > > That doesn't look like a valid language code (< 138, though the table I > > have is partial) > > its valid and means "und" for undefined. you can use quicktime or mp4box for > setting the language tags on mp4 files is "und" supported by ffmpeg?

1 0