[Ffmpeg-devel] 回复: ffmpeg-devel Digest, Vol 12, Issue 110
newleft
bb_haibo
Wed Mar 15 03:28:14 CET 2006
all
may i ask a question? when i looked into the source code , i found there are some expression that is divid by zero? why? what's the meaning?
for example:
AVExtFloat av_dbl2ext(double d){
struct AVExtFloat ext;
int e, i; double f; uint64_t m;
f = fabs(frexp(d, &e));
if (f >= 0.5 && f < 1) {
e += 16382;
ext.exponent[0] = e>>8;
ext.exponent[1] = e;
m = (uint64_t)ldexp(f, 64);
for (i=0; i < 8; i++)
ext.mantissa[i] = m>>(56-(i<<3));
} else if (f == 0.0) {
memset (&ext, 0, 10);
} else {
ext.exponent[0] = 0x7f; ext.exponent[1] = 0xff;
memset (&ext.mantissa, 0, 8);
if (f != 1/0.0)////////////////////////////////////////////divided by zero , 1/0.0 for infinite? 0.0/0.0 for zero(in double precision )
ext.mantissa[0] = ~0;
}
if (d < 0)
ext.exponent[0] |= 0x80;
return ext;
}
thanks for your explaination!
newleft
2006-03-15
???? ffmpeg-devel-request at mplayerhq.hu
????? 2006-03-15 07:22:47
???? ffmpeg-devel at mplayerhq.hu
???
??? ffmpeg-devel Digest, Vol 12, Issue 110
Send ffmpeg-devel mailing list submissions to
ffmpeg-devel at mplayerhq.hu
To subscribe or unsubscribe via the World Wide Web, visit
http://mplayerhq.hu/mailman/listinfo/ffmpeg-devel
or, via email, send a message with subject or body 'help' to
ffmpeg-devel-request at mplayerhq.hu
You can reach the person managing the list at
ffmpeg-devel-owner at mplayerhq.hu
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ffmpeg-devel digest..."
Today's Topics:
1. Re: [ bug ] converting png to dv gives solid black (Erik Slagter)
2. Re: [PATCH] DVB AC-3 support in mpegts.c (Nico Sabbi)
3. [PATCH] Disable NUT in lavf (Oded Shimon)
4. Re: [ bug ] converting png to dv gives solid black (Mike Melanson)
5. [PATCH] MPTS support in mpegts.c (Andy Brown)
6. Re: [PATCH] Snow mmx+sse2 asm optimizations (Luca Barbato)
7. Re: OT - video connectors (was: Re: [Ffmpeg-devel] [ bug ]
converting png to dv gives solid black ) (Cian Duffy)
----------------------------------------------------------------------
Message: 1
Date: Tue, 14 Mar 2006 13:01:47 +0100
From: Erik Slagter <erik at slagter.name >
Subject: Re: [Ffmpeg-devel] [ bug ] converting png to dv gives solid
black
To: FFMpeg development discussions and patches
<ffmpeg-devel at mplayerhq.hu >
Message-ID: <1142337707.30415.76.camel at localhost.localdomain >
Content-Type: text/plain; charset="us-ascii"
On Mon, 2006-03-13 at 13:13 -0800, Roman Shaposhnick wrote:
> I've asked this question many times and I still don't think I know
> the answer: why is that I see very little desire to converge on
> a progressive unified standard with a fixed frame rate for at least
> digital HDTV broadcasts ? I hear about Blue Ray vs. HD DVD all the time
> but I hardly hear anything about ditching NTSC and PAL in favor of something
> that actually makes sense in 21st century.
Hear, hear! Something like 24/48 fps, at least something easily
transferable from movie. Using non-CRT screens flickering is no longer
an issue, only the actual update frequency counts.
It would mean the STB would have to do an (expensive) translation to the
native frame rate of the legacy TV set, though.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2771 bytes
Desc: not available
Url : /pipermail/attachments/20060314/9c155b77/smime-0001.bin
------------------------------
Message: 2
Date: Wed, 15 Mar 2006 00:11:50 +0100
From: Nico Sabbi <nicola_sabbi at fastwebnet.it >
Subject: Re: [Ffmpeg-devel] [PATCH] DVB AC-3 support in mpegts.c
To: FFMpeg development discussions and patches
<ffmpeg-devel at mplayerhq.hu >
Message-ID: <44174DB6.1060202 at fastwebnet.it >
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Andy Brown wrote:
>This patch simply adds demuxing support for AC-3 streams in DVB TS files. In
>these streams AC-3 is given type 0x06 (private stream) and includes a
>descriptor with either tag 0x6A or 0x7A. The code already handles ATSC AC-3
>which uses stream type 0x81. All the new patch does is look for any stream
>type 0x06 that has a descriptor with the proper tag (i.e. 0x6A or 0x7A) and if
>found forces it to be recognized as an AC-3 stream.
>
>Andy
>
>
>
I knew of 0x6a, but where is 0x71 defined? I don't remember I ever read
it in
recent specifications published by ETSI
------------------------------
Message: 3
Date: Tue, 14 Mar 2006 16:35:15 +0200
From: Oded Shimon <ods15 at ods15.dyndns.org >
Subject: [Ffmpeg-devel] [PATCH] Disable NUT in lavf
To: "ffmpeg-devel at mplayerhq.hu" <ffmpeg-devel at mplayerhq.hu >
Message-ID: <20060314143514.GX6600 at crate15 >
Content-Type: text/plain; charset="us-ascii"
$subj
At least until we sync it...
- ods15
-------------- next part --------------
--- libavformat/allformats.c 2006-02-19 04:30:17.000000000 +0200
+++ libavformat/allformats.c 2006-03-14 16:30:19.000000000 +0200
@@ -110,7 +110,7 @@
dc1394_init();
#endif
- nut_init();
+ //nut_init();
matroska_init();
sol_init();
ea_init();
------------------------------
Message: 4
Date: Tue, 14 Mar 2006 15:18:36 -0800
From: Mike Melanson <mike at multimedia.cx >
Subject: Re: [Ffmpeg-devel] [ bug ] converting png to dv gives solid
black
To: FFMpeg development discussions and patches
<ffmpeg-devel at mplayerhq.hu >
Message-ID: <44174F4C.3090007 at multimedia.cx >
Content-Type: text/plain; charset=UTF-8; format=flowed
Gary Corcoran wrote:
> It was supposed to happen when at least 85% of the people had HDTV tuners.
> But not any more. Congress recently passed a bill fixing the date at
> sometime
> in early 2009 (February,March,April, I don't recall what they finally
> agreed
> on).
According to Wikipedia, the "drop-dead" date is Februry 17, 2009:
http://en.wikipedia.org/wiki/High-definition_television_in_the_United_States
> Yeah, we darn consumers taking our time to upgrade are the reason Congress
> decided to put a hard deadline. They want the billions of dollars they
IIRC, they've been setting hard deadlines since the 1990s. Keeps
slipping for some reason.
> think
> they're gonna get by auctioning the freed-up frequencies of analog
> broadcasting.
> What bugs me is that even if they get the billions of dollars, you
> _know_ who
> will be paying those billions in the end. Yep, all us consumers. Plus if
> you depend on over-the-air broadcasts for your TV, as a lot of poorer
> people do,
I often wonder why it's a forgone conclusion that television access is
a fundamental human right. Don't weep, though-- I've heard of some
government initiatives to help subsidize HDTV upgrades for the
economically disadvantaged. Seriously (and guess who gets to pay for that?).
> you'll be forced to buy an HDTV tuner. I can't wait to hear the reactions
> when millions of people's TV sets suddenly stop working. (of course if
> you're
> on a cable or satellite system you won't notice)
Maybe this will finally happen (advisory: joke newspaper):
TELEVISION ENDS
http://www.theonion.com/content/node/30278
--
-Mike Melanson
------------------------------
Message: 5
Date: Tue, 14 Mar 2006 09:22:52 -0500
From: Andy Brown <abrown at daqtron.com >
Subject: [Ffmpeg-devel] [PATCH] MPTS support in mpegts.c
To: ffmpeg-devel <ffmpeg-devel at mplayerhq.hu >
Message-ID: <20060314092252.po4bnkjs3mokwc0s at www.daqtron.com >
Content-Type: text/plain; charset="iso-8859-1"
This patch allows selection of which service to use if the mpegts file contains
more than one. The original file searched for all the services but then only
configured the streams for the first one. Now it allows chosing which service
to configure streams for based on the channel member of the AVFormatParameters
structure (if not specified or set to 0 it behaves as it originally did).
In order to obtain a list of services (ids and names) that the
mpegts_read_header() function discovers, I had to add another function
(get_channels) to the AVInputFormat structure as well as a new AVChannel
structure (both in avformat.h).
While the ideal solution would provide a way to determine services without
having to call functions twice, this was a good compromise with minimal
changes. I'm successfully using this change with the following series of calls
in my application:
av_open_input_file(frmt, NULL);
if(frmt- >iformat- >get_channels) {
count = frmt- >iformat- >get_channels(frmt, chan);
if (count > 1 && chan) {
av_close_input_file(frmt);
/* add code here to select desired service - > sid */
param.channel = sid;
av_open_input_file(frmt, ?m);
}
if (chan) av_free(chan);
}
Andy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mpegts-mpts.patch
Type: text/x-patch
Size: 3064 bytes
Desc: not available
Url : /pipermail/attachments/20060314/1894c7f3/mpegts-mpts-0001.bin
------------------------------
Message: 6
Date: Tue, 14 Mar 2006 12:27:04 +0100
From: Luca Barbato <lu_zero at gentoo.org >
Subject: Re: [Ffmpeg-devel] [PATCH] Snow mmx+sse2 asm optimizations
To: FFMpeg development discussions and patches
<ffmpeg-devel at mplayerhq.hu >
Message-ID: <4416A888.9050005 at gentoo.org >
Content-Type: text/plain; charset=UTF-8
Robert Edele wrote:
>
> snow.h is included to get access to the DWTELEM #define. Would you have
> any ideas on a better way of doing this?
Changing back DWTELEM to a standard type could work...
lu
------------------------------
Message: 7
Date: Tue, 14 Mar 2006 23:22:06 +0000
From: "Cian Duffy" <myob87 at gmail.com >
Subject: Re: OT - video connectors (was: Re: [Ffmpeg-devel] [ bug ]
converting png to dv gives solid black )
To: "FFMpeg development discussions and patches"
<ffmpeg-devel at mplayerhq.hu >
Message-ID: <2658dc2f0603141522j714850adu at mail.gmail.com >
Content-Type: text/plain; charset=ISO-8859-1
On 14/03/06, Erik Slagter <erik at slagter.name > wrote:
>
> > > Are there any TV sets left that
> > > don't have RGB/component inputs?
> >
> > Tons.
>
> What region are we talking? Over here (NL) I've seen no TV sets without
> RGB/component input for at least 10 years now. You're quite screwed imho
> if someone sells you a TV set without RGB input!
Theres a big difference between Europe - where SCARTs are basically
essential - and the USA - where composite is still quite often the default.
But I've not only seen but own a TV - a late 1990s 14" portable by an major
Europe electronics firm that will remain nameless - where the SCART didn't
do RGB. They still exist.
Most STBs only support RGB on a single SCART, additionally. Sometimes the
second one supports S-Video but normally only composite.
Cian
--
-------------------------
"We're busy running out of time"
------------------------------
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel at mplayerhq.hu
http://mplayerhq.hu/mailman/listinfo/ffmpeg-devel
End of ffmpeg-devel Digest, Vol 12, Issue 110
*********************************************
More information about the ffmpeg-devel
mailing list