search for: frame_number

...ottomBand=0; this->frame_leftBand=0; this->frame_rightBand=0; - + this->start_time=0; + this->end_time=0; /* ZERO denotes no end time set */ } return this; } @@ -142,7 +146,7 @@ AVCodec *acodec = NULL; AVCodec *vcodec = NULL; float frame_aspect; - + int frame_number=0; double fps = 0.0; for (i = 0; i < this->context->nb_streams; i++){ @@ -426,9 +430,23 @@ info.vorbis_quality = this->audio_quality; info.vorbis_bitrate = this->audio_bitrate; theoraframes_init (&info); - + /*seek to start time*/ + av_seek_frame( this->cont...

...time set */ } return this; } void ff2theora_output(ff2theora this) { int i; AVCodecContext *aenc = NULL; AVCodecContext *venc = NULL; AVStream *astream = NULL; AVStream *vstream = NULL; AVCodec *acodec = NULL; AVCodec *vcodec = NULL; AVIndexEntry * index_entry; float frame_aspect; int frame_number=0; double fps = 0.0; for (i = 0; i < this->context->nb_streams; i++){ AVCodecContext *enc = &this->context->streams[i]->codec; switch (enc->codec_type){ case CODEC_TYPE_VIDEO: if (this->video_index < 0) this->video_index = i; break; case CODEC_...

...namically > (would that be a bit of a cpu hog?), or is there possibly a better > way > I'm not thinking of? first question, does your seek have to be sample-accurate? if not, you can get frame-accurate seeking by building a little proggie to scan by frame headers looking for a nearby frame_number*blocksize sample number, then forge a STREAMINFO block and cat it + the flac file from that offset to another copy of 'flac -d -' with no --skip argument. the other thing is, are you using --input-size? I think if you do, the total_samples count in the STREAMINFO block should be written u...

...OMAKE_OPTIONS = 1.6 dist-bzip2 no-dist-gzip +AUTOMAKE_OPTIONS = 1.6 dist-bzip2 SUBDIRS = kino_export Index: ffmpeg2theora.c =================================================================== --- ffmpeg2theora.c (revision 8373) +++ ffmpeg2theora.c (working copy) @@ -150,6 +150,18 @@ int64_t frame_number=0; double fps = 0.0; + /* 20041216/DK variables that help us keep track of A/V sync */ + double v_pts_out = 0.0; + double v_pts_in = 0.0; + double a_pts_out = 0.0; + double v_pts_delta = 0.0; + double v_pts_delta_new = 0.0; + double a_pts_delta = 0.0; + double framesync = 0.0; + const double v_...

Please excuse me, I haven't yet dug into the code too far. What I'd like to do: I'm using ecasound to record for 24 hour periods, which pipes the output directly to flac. I would like to be able to decode sections of this (using until/skip) during recording/encoding. I understand currently that flac can't do this, unless I pipe into dd to skip after decoding (which would be an

...cond_chroma_qp_index_offset : 5; // 32 11..15 > > unsigned weighted_bipred_idc : 2; // 34 0..1 > unsigned fifo_dec_index : 7; // 34 2..8 > unsigned tmp_idx : 5; // 34 9..13 -> CurrColIdx (index of associated co-located motion data buffer) > unsigned frame_number : 16; // 34 14..29 > unsigned u34_3030 : 1; // 34 30..30 pp.u34[30:30] > unsigned u34_3131 : 1; // 34 31..31 pad? > > uint32_t field_order_cnt[2]; // 38, 3c > > struct { // 40 > // 0x00223102 > // nfi (needs: to...

On Thu, Nov 21, 2013 at 5:22 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > On Thu, Nov 21, 2013 at 5:07 PM, Benjamin Morris <bmorris at nvidia.com> wrote: >> On 11/19/2013 08:16 PM, Ilia Mirkin wrote: >>> Hello, >>> >>> I hope this is an appropriate style of request for this forum. I added >>> code to support video decoding on the tesla

...video_bitrate=0; this->audio_quality=0.297;// audio quality 3 this->audio_bitrate=0; + this->smoothness=0; + this->keyint=64; + this->noautosync=0; this->force_input_fps=0; this->aspect_numerator=0; this->aspect_denominator=0; @@ -150,6 +157,21 @@ int64_t frame_number=0; double fps = 0.0; + /* 20041216/DK variables that help us keep track of A/V sync */ + double v_pts_out = 0.0; + double v_pts_in = 0.0; + double a_pts_out = 0.0; + double v_pts_delta = 1e99; + double v_pts_delta_new = 0.0; + double a_pts_delta = 0.0; + double framesync = 0.0; + double was_fra...

...d chroma_qp_index_offset : 5; // 32 6..10 signed second_chroma_qp_index_offset : 5; // 32 11..15 unsigned weighted_bipred_idc : 2; // 34 0..1 unsigned fifo_dec_index : 7; // 34 2..8 unsigned tmp_idx : 5; // 34 9..13 -> CurrColIdx (index of associated co-located motion data buffer) unsigned frame_number : 16; // 34 14..29 unsigned u34_3030 : 1; // 34 30..30 pp.u34[30:30] unsigned u34_3131 : 1; // 34 31..31 pad? uint32_t field_order_cnt[2]; // 38, 3c struct { // 40 // 0x00223102 // nfi (needs: top_is_reference, bottom_is_reference, is_long_term, maybe some other state that was saved.. u...

As it turns out, with the proprietary firmware, the VP3 and VP4 interfaces are identical. Furthermore, this is all already implemented for nvc0. So these patches (a) move the easily sharable bits of the nvc0 implementation into the nouveau directory, and then (b) implement the other parts in nv50. The non-shared parts are still largely copies, but there are some differences, not the least of which