[Ffmpeg-devel] 回复: ffmpeg-devel Digest, Vol 12, Issue 110

newleft bb_haibo
Wed Mar 15 03:28:14 CET 2006

   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!


???? 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
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
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.
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"

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  @@

-        nut_init();
+        //nut_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
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:


>  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):


-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)  {
                       /*  add  code  here  to  select  desired  service  - >  sid  */
                       param.channel  =  sid;
                       av_open_input_file(frmt,  ?m);
               if  (chan)  av_free(chan);


--------------  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...



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.


"We're  busy  running  out  of  time"


ffmpeg-devel  mailing  list
ffmpeg-devel at mplayerhq.hu

End  of  ffmpeg-devel  Digest,  Vol  12,  Issue  110

More information about the ffmpeg-devel mailing list