headers
Claudio da Silveira Pinheiro | 1 Jun 2004 01:09
Picon

Re: Encoding repeated frames - can I pass a NULL?

Em Seg 31 Mai 2004 19:56, Måns Rullgård escreveu:
> Claudio da Silveira Pinheiro <claudio <at> stctecnologia.com.br> writes:
> > av_write_frame(movie->oc, movie->video_st->index, movie->video_outbuf,
> > out_size);
>
> That was changed to use an AVPacket a couple of days ago.

I'm using ffmpeg 0.4.8 (I need ffserver and have no idea about how to fix it 
in CVS).

> > Can we encode a P-Frame passing a NULL to movie->video_outbuf and 0 to
> > out_size?
>
> If the size is 0, how could it encode anything at all?

That's the point. It shouldn't spend any time at all. The idea is if the frame 
is repeated and I know it is, passing a NULL to movie->video_outbuf and 0 to 
out_size could mean there's no need to analize the buffer, and it could 
generate instead a P-frame with no movement at all. As av_write_frame seems 
to behave differently, I was wondering about a way to tell to my program to 
send a P-frame with no movement.

Cláudio

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id66&op=click
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Niedermayer CVS | 1 Jun 2004 01:44
Picon

CVS: ffmpeg/libavcodec h261.c,1.4,1.5

Update of /cvsroot/ffmpeg/ffmpeg/libavcodec
In directory mail:/var2/tmp/cvs-serv2362

Modified Files:
	h261.c 
Log Message:
10l fix by (Wolfram Gloger <wmglo at dent dot med dot uni-muenchen dot de>)

Index: h261.c
===================================================================
RCS file: /cvsroot/ffmpeg/ffmpeg/libavcodec/h261.c,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -d -r1.4 -r1.5
--- h261.c	30 May 2004 22:29:15 -0000	1.4
+++ h261.c	31 May 2004 23:44:02 -0000	1.5
 <at>  <at>  -246,7 +246,7  <at>  <at> 
                           DCTELEM block[6][64])
 {
     MpegEncContext * const s = &h->s;
-    int i, cbp, xy;
+    int i, cbp, xy, old_mtype;

     cbp = 63;
     // Read mba
 <at>  <at>  -272,7 +272,7  <at>  <at> 
     ff_update_block_index(s);

     // Read mtype
-    int old_mtype = h->mtype;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Giasone | 1 Jun 2004 02:20
Picon
Favicon

AC3 source

Is there the possibility to decode an AC3 source embedded in AVI file by
ffmpeg?
If yes how?
T.I.A.

Alex

 --

 Email.it, the professional e-mail, gratis per te: http://www.email.it/f

 Sponsor:

 Vuoi una carta di credito in linea con il tuo stile di vita? Abbiamo quella che fa per te, clicca qui

 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=1854&d=1-6

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
Permalink | Reply | 0 comments |
headers
Michael Niedermayer | 1 Jun 2004 02:33
Picon
Picon

Re: [PATCH] Consistently copy timestamps from input to output

Hi

On Monday 31 May 2004 23:32, Wolfram Gloger wrote:
> Hi,
>
> I think we should be doing more copying from input timestamps to
> output timestamps in ffmpeg.  At least the "-acodec copy" case already
> has been doing this for some time, and I noticed that transcoding
> MPEGTS (whose timestamps usually don't start at 0) has been always out
> of sync because of this: The output video stream always got fabricated
> 0-based timestamps, which never had a chance to match the output audio
> streams' copied timestamps.
>
> The patch below lets timestamps be copied when encoding video frames,
> and takes care to initialize sync_opts to an appropriate (in general
> non-integral) value when the input stream's timestamps doesn't start
> with zero.  Anything wrong with this basic approach?
yes

the timestamps from the demuxer and the video stream too, may have 
discontinuities / reset to 0 at random places and such things
the output format has probably various limitations with what timestamps are 
legal, practically no format allows timestamps to have discontinuities, many 
require timestamps to be an integral number in framerate or samplerate units, 
timestamps also should start at 0 or at least close to it IMHO

so there are really 2 cases which ffmpeg should support
1. variable framerate output (timestamps start near 0, can have any value in  
AVStream.timebase units)
2. fixed framerate output, timestamps are in framerate/samplerate units
(Continue reading)

Permalink | Reply | 6 comments |
headers
Michel Bardiaux | 1 Jun 2004 10:19
Picon

Re: [PATCH] Consistently copy timestamps from input to output

Michael Niedermayer wrote:

> Hi
> 
[snip]

> 
> yes
> 
> the timestamps from the demuxer and the video stream too, may have 
> discontinuities / reset to 0 at random places and such things
> the output format has probably various limitations with what timestamps are 
> legal, practically no format allows timestamps to have discontinuities, many 
> require timestamps to be an integral number in framerate or samplerate units, 
> timestamps also should start at 0 or at least close to it IMHO
> 
> so there are really 2 cases which ffmpeg should support
> 1. variable framerate output (timestamps start near 0, can have any value in  
> AVStream.timebase units)
> 2. fixed framerate output, timestamps are in framerate/samplerate units 
> starting exactly or near 0
> 
> the longterm solution would be to have a flexible filter layer with filters to
> 1. remove timestamp discontinuities
> 2. drop&duplicate frames to match a fixed framerate and give the frames 
> correct timestamps for it
> 
> the shortterm solution is to simply fix the input timestamps in ffmpeg.c so 
> they start near 0 are monotone and large discontinuities are removed and 
> replaced by the +1/framerate
(Continue reading)

Permalink | Reply | 5 comments |
headers
Chip | 1 Jun 2004 11:29
Picon
Favicon

PATCH: svq1 compile fixes

Hi,

The attached patch is needed when you are trying to compile
libavcodec with altivec support. In that case vector is a
type and it conflicts with the variable called with the same
name.
I've also placed the encoding functions iside of #ifdef
CONFIG_ENCODERS

Regards,
Chip...
Attachment (svq1.patch): application/octet-stream, 2537 bytes
Permalink | Reply | 7 comments |
headers
Michael Niedermayer | 1 Jun 2004 12:09
Picon
Picon

Re: [PATCH] Consistently copy timestamps from input to output

Hi

On Tuesday 01 June 2004 10:19, Michel Bardiaux wrote:
> Michael Niedermayer wrote:
> > Hi
>
> [snip]
>
> > yes
> >
> > the timestamps from the demuxer and the video stream too, may have
> > discontinuities / reset to 0 at random places and such things
> > the output format has probably various limitations with what timestamps
> > are legal, practically no format allows timestamps to have
> > discontinuities, many require timestamps to be an integral number in
> > framerate or samplerate units, timestamps also should start at 0 or at
> > least close to it IMHO
> >
> > so there are really 2 cases which ffmpeg should support
> > 1. variable framerate output (timestamps start near 0, can have any value
> > in AVStream.timebase units)
> > 2. fixed framerate output, timestamps are in framerate/samplerate units
> > starting exactly or near 0
> >
> > the longterm solution would be to have a flexible filter layer with
> > filters to 1. remove timestamp discontinuities
> > 2. drop&duplicate frames to match a fixed framerate and give the frames
> > correct timestamps for it
> >
> > the shortterm solution is to simply fix the input timestamps in ffmpeg.c
(Continue reading)

Permalink | Reply | 4 comments |
headers
Michael Niedermayer | 1 Jun 2004 12:23
Picon
Picon

Re: PATCH: svq1 compile fixes

Hi

On Tuesday 01 June 2004 11:29, Chip wrote:
> Hi,
>
> The attached patch is needed when you are trying to compile
> libavcodec with altivec support. In that case vector is a
> type and it conflicts with the variable called with the same
> name.
AFAIK a simple #undef vector can be used to workaround this until someone 
fixes altivec.h to use prefixes like everone else does too

> I've also placed the encoding functions iside of #ifdef
> CONFIG_ENCODERS
static functions which are not referenced dont need to be compiled/linked/... 
if your compiler fails to realize this u should write a bugreport or 
featurerequest

[...]
--

-- 
Michael
level[i]= get_vlc(); i+=get_vlc();		(violates patent EP0266049)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]);	(violates patent #5,905,535)
buf[i]= qp - buf[i-1];				(violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Måns Rullgård | 1 Jun 2004 12:23
Picon
Picon
Favicon

Re: [PATCH] Consistently copy timestamps from input to output

Michael Niedermayer <michaelni <at> gmx.at> writes:

> Hi
>
> On Tuesday 01 June 2004 10:19, Michel Bardiaux wrote:
>> Michael Niedermayer wrote:
>> > Hi
>>
>> [snip]
>>
>> > yes
>> >
>> > the timestamps from the demuxer and the video stream too, may have
>> > discontinuities / reset to 0 at random places and such things
>> > the output format has probably various limitations with what timestamps
>> > are legal, practically no format allows timestamps to have
>> > discontinuities, many require timestamps to be an integral number in
>> > framerate or samplerate units, timestamps also should start at 0 or at
>> > least close to it IMHO
>> >
>> > so there are really 2 cases which ffmpeg should support
>> > 1. variable framerate output (timestamps start near 0, can have any value
>> > in AVStream.timebase units)
>> > 2. fixed framerate output, timestamps are in framerate/samplerate units
>> > starting exactly or near 0
>> >
>> > the longterm solution would be to have a flexible filter layer with
>> > filters to 1. remove timestamp discontinuities
>> > 2. drop&duplicate frames to match a fixed framerate and give the frames
>> > correct timestamps for it
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michel Bardiaux | 1 Jun 2004 12:32
Picon

Re: [PATCH] Consistently copy timestamps from input to output

Michael Niedermayer wrote:

> Hi
> 
> 
> there are really 2 different things here
> 1. timesamps starting at a random value instead of 0, IMHO allowing something 
> like this in a format is quite bad design, thats probably why its not allowed 
> in some formats, so ffmpeg must fix this somewhere
> 2. start time
> 
> u seem to want 2., i dont understand how that could be related to 1., or what 
> "true" time is associated with timestamp=0? if there was no start time 
> variable storing this then theres no meaning for timestamp X, and if there is 
> a start_time i dont see how changing the timestamps so they start at 0 and 
> updating start_time would make a difference
> 
I dont understand your reply at all, what do you mean by "2. start time"?

What *I* did not explain clearly is that I produce MPG files with 
*exact* timestamps (system clock of each frame, converted to PTS) (and I 
fix the timecodes too!) for at least one reason: so that the files can 
be concatenated while still producing a legal MPEG1 system stream. Thus 
the initial TS value in each file is definitely not random: the initial 
TS in file # N+1 is the initial TS in file # N plus 5400000 modulo 2exp33.

Thus IMHO the 2 cases are:

(1) user takes full responsibility for timestamps, by asserting some 
(de)muxer flag. ffmpeg and lavf might check the sequence is legal, but
(Continue reading)

Permalink | Reply | 0 comments |

Gmane