headers
bond | 1 Jan 2006 16:06
Picon

Re: ffmpeg mp4 demuxer doesnt handle 64bit


> > 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Niedermayer | 2 Jan 2006 04:55
Picon
Picon

Re: [PATCH] support for DVHS mpegts (192 bytes)

Hi

On Tue, Dec 27, 2005 at 12:45:13PM +0100, Nico Sabbi wrote:
> The subject says everything.

[...]
>      score    = analyze(buf, size, TS_PACKET_SIZE, NULL);
> +    dvhs_score    = analyze(buf, size, TS_DVHS_PACKET_SIZE, NULL);
>      fec_score= analyze(buf, size, TS_FEC_PACKET_SIZE, NULL);
> -//    av_log(NULL, AV_LOG_DEBUG, "score: %d, fec_score: %d \n", score, fec_score);
> +//    av_log(NULL, AV_LOG_DEBUG, "score: %d, dvsh_score: %d, fec_score: %d \n", score, dvhs_score, fec_score);
>  
>      if     (score > fec_score) return TS_PACKET_SIZE;

shouldnt that be score > fec_score && score >dvhs_score ?

> +    else if(dvhs_score > score) return TS_DVHS_PACKET_SIZE;
>      else if(score < fec_score) return TS_FEC_PACKET_SIZE;
>      else                       return -1;

[...]

otherwise patch ok, feel free to apply

--

-- 
Michael
Permalink | Reply | 1 comment |
headers
Michael Niedermayer | 2 Jan 2006 05:03
Picon
Picon

Re: [PATCH] second attempt to auto_guess streams in mpegts

Hi

On Tue, Dec 27, 2005 at 12:43:50PM +0100, Nico Sabbi wrote:
> 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.

patch looks ok, feel free to apply if there are no objections from thouse
who actually know mpegts.c ...

[...]

--

-- 
Michael
Permalink | Reply | 1 comment |
headers
Michael Niedermayer | 2 Jan 2006 05:14
Picon
Picon

Re: [PATCH] from DivX, Part 12: DV aspect ratio

Hi

On Fri, Dec 16, 2005 at 03:45:37PM -1000, Steve Lhomme wrote:
> This code moves the AR detection in the codec part so that it works when 
> the DV stream is in AVI (or else) too. Plus the interlacing detection 
> now works.

roman, please choose
[ ] patch ok
[ ] patch not ok
[ ] dv maintainer lazy
[ ] dv maintainer busy
[ ] dv maintainer dead

[...]

--

-- 
Michael
Permalink | Reply | 1 comment |
headers
Martin Boehme | 2 Jan 2006 09:47
Picon
Favicon

Re: mmx/sse optimizations

Marcus Engene wrote:
> Martin Boehme wrote:
>>> Yes, I tried it a bit now. Going thru the tutorial gave me a good 
>>> idea of what mmx is all about. It's seems like a no-brainer to teach 
>>> my little pet watermark to do some mmx tricks.
>>>
>>> I'd recommend it to anyone interrested in trying out mmx/sse. The 
>>> demo version is after all free.
>>>
>>> The documentation is a bit thin, but as Michel wrote, it's easy to 
>>> google the mnemonics after having a starting point.
>>
>> So you did find it helpful? What does it do, exactly, compared to 
>> coding MMX/SSE by hand?
> 
> It gave me an quick introduction to what it's all about by going through 
> the tutorial and the manual. A teacher of a friend once said "you can 
> only learn things you already know" which I later have come to realize 
> how true that was. I have a grasp of it now so I know [a bit more] what 
> to look for in the Intel docs and what it can do. Ie the same reason 
> people buy O'Reilly books, to get a grasp, and then it's easier to read 
> the RFCs.

OK, that makes sense... In that case, they're probably not going to make 
a lot of money off that product, though...

Martin

--

-- 
Martin Böhme
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Boehme | 2 Jan 2006 10:04
Picon
Favicon

Re: [PATCH]: Too much alignment assumed by H264 decoder

Mike Melanson wrote:
> David S. Miller wrote:
>> I did the fix, some folks just don't like it.  To be honest, I don't
>> think it decreases performance all as much as is being implied.
>>
>> The fact is that the object is 4-byte, not 8-byte aligned, on 32-bit
>> platforms.  So you can't legally do 8-byte memory accesses to them
>> in such cases.
>>
>> With the way the code is now, it crashes on 32-bit platforms other
>> than x86 and x86_64 (which do not trap on unaligned memory accesses).
>> And because the x86 and x86_64 don't trap, but instead just eat a
>> couple extra cycles to perform the unaligned memory accesses, this
>> makes me believe that the "performance penalty" of my patch is
>> possibly a myth not fact.
> 
>     Do you have any numbers to back this up? Per my understanding, 
> unaligned accessed for MMX instructions is possible but slightly slower. 
> IIRC, unaligned access on SSE2 instructions is not possible.

It is possible, but you have to use the MOVDQU (move double quad 
unaligned) instruction instead of MOVDQA (...aligned).

Martin

--

-- 
Martin Böhme
Inst. f. Neuro- and Bioinformatics
Ratzeburger Allee 160, D-23538 Luebeck
Phone: +49 451 500 5814
(Continue reading)

Permalink | Reply | 0 comments |
headers
Diego Biurrun | 2 Jan 2006 11:24
Picon
Gravatar

Re: next stable release

On Fri, Dec 30, 2005 at 01:48:07AM +0100, Diego Biurrun wrote:
> On Thu, Dec 29, 2005 at 09:37:07PM +0100, Michael Niedermayer wrote:
> > 
> > On Thu, Dec 29, 2005 at 09:06:16PM +0200, Rostislav Krasny wrote:
> > > 
> > > 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?
> > 
> > never, but thats just whats planned, it might be later then that due
> > to various delays ...
> > 
> > btw, someone please add this to the FAQ
> 
> That's not easy without stepping on a massive amount of toes.  Mike has
> a talent for expressing this kind of thing in an eloquent and diplomatic
> fashion.  I'll give it a try nevertheless:
> 
> Q: When will the next FFmpeg version be released? / Why are FFmpeg
>    releases so few and far between?
> 
> A: Like most open source projects FFmpeg suffers from a certain lack of
>    manpower.  For this reason the developers have to prioritize the work
>    they do and putting out releases is not at the top of the list,
>    fixing bugs and reviewing patches takes precedence.
>    Please don't complain or request more timely and/or frequent releases
>    unless you are willing to help out creating them.

Committed.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Diego Biurrun | 2 Jan 2006 13:38
Picon
Gravatar

[BUG] MPEG-4 file with artifacts

Hi,

while reorganizing my samples collection, I stumbled across some samples
that fail to decode properly.  This one has MPEG-4 video that shows
heavy artifacting:

ftp://sandman.homedns.org/diego/ffmpeg/mpeg4_artifacts.mp4
ftp://sandman.homedns.org/diego/ffmpeg/mpeg4_artifacts_small.mp4

The first sample is 50MB, the second 1MB, but the small version already
shows the problem quite visibly.  ffplay fills the console with messages
like

[mpeg4  <at>  0x10287df8]Error at MB: 672
[mpeg4  <at>  0x10287df8]marker does not match f_code
[mpeg4  <at>  0x10287df8]concealing 593 DC, 593 AC, 593 MV errors
[mpeg4  <at>  0x10287df8]Error at MB: 672
[mpeg4  <at>  0x10287df8]marker does not match f_code
[mpeg4  <at>  0x10287df8]concealing 593 DC, 593 AC, 593 MV errors
[mpeg4  <at>  0x10287df8]header damaged
[mpeg4  <at>  0x10287df8]ac-tex damaged at 24 23
[mpeg4  <at>  0x10287df8]Error at MB: 967
[mpeg4  <at>  0x10287df8]concealing 315 DC, 315 AC, 315 MV errors
[mpeg4  <at>  0x10287df8]header damaged
[mpeg4  <at>  0x10287df8]header damaged
[mpeg4  <at>  0x10287df8]ac-tex damaged at 3 5

Maybe the file is just damaged (beyond repair).  I'd appreciate if
somebody could confirm this.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Diego Biurrun | 2 Jan 2006 14:50
Picon
Gravatar

[BUG] TSCC wrong colors on PPC

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
Permalink | Reply | 0 comments |
headers
Diego Biurrun | 2 Jan 2006 15:02
Picon
Gravatar

Re: [BUG] MPEG-4 file with artifacts

On Mon, Jan 02, 2006 at 01:38:30PM +0100, Diego Biurrun wrote:
> 
> while reorganizing my samples collection, I stumbled across some samples
> that fail to decode properly.  This one has MPEG-4 video that shows
> heavy artifacting:
> 
> ftp://sandman.homedns.org/diego/ffmpeg/mpeg4_artifacts.mp4
> ftp://sandman.homedns.org/diego/ffmpeg/mpeg4_artifacts_small.mp4

To fill in some missing details: Tested with CVS MPlayer, ffplay and
xine as well as vlc 0.8.4 on both a PPC and x86 system.  Both are Debian
unstable boxes with gcc 4.0.3 on the PPC and gcc 2.95.4 on the x86 box.

Diego
Permalink | Reply | 0 comments |

Gmane