On Tue, Dec 18, 2012 at 1:07 PM, Taha Ansari wrote:
> After first run, if we change
>
> #define ENCODER_WIDTH 640
> #define ENCODER_HEIGHT 480
>
> to
>
> #define ENCODER_WIDTH 160
> #define ENCODER_HEIGHT 120
>
> and run again, file size is almost the same. Question now is why? shouldn't
> smaller
Note that you have the encoder bit rate hard coded:
>
> > c->bit_rate = 40;
>
> ... so, one would expect a well-tempered encoder to produce same
> encoded frame sizes. You could try to compare the resulting video
> quality in two cases. E.g., decode the two streams and display them at
> 160x12
>> On Mon, Dec 17, 2012 at 10:59 AM, Dolevo Jay wrote:
>>> I capture the video frame by frame from the desktop screen and send them
>>> over network after encoding. This happens on the PC processor and I have no
>>> problem with this. It works perfect for now. However, I capture the audio
>>> sepa
Gohar Hovhannisyan writes:
> We wonder whether it is possible to perform decoding on
> iPad GPU to speed up decoding process (by compiling
> it with special flags, or with some patches)
Only if you implement it.
> or run it parallel on dual core (iPad2) / quad-core (new iPad)
> or are there a
PS: This (http://lists.libav.org/pipermail/libav-api/2012-April/000473.html)
thread is about the exact same question and again no one seems to know
the answer.
___
Libav-user mailing list
Libav-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/libav-user
Found another thread with similar question:
http://libav-users.943685.n4.nabble.com/Libav-user-PTS-values-and-writing-encoded-audio-and-video-frames-td4551001.html
Again, not answered.
I do not think no one has ever considered video and audio clocks can
slightly drift away from each other, so the
On 19 Dec 2012, at 14:07, Mike Versteeg wrote:
> Found another thread with similar question:
> http://libav-users.943685.n4.nabble.com/Libav-user-PTS-values-and-writing-encoded-audio-and-video-frames-td4551001.html
>
> Again, not answered.
>
> I do not think no one has ever considered video a
> Maybe you should ask which clock is the most precise, and use that one as
> your master clock? If that's not possible you won't have many other options
> if everything has to be done on realtime; adapting frame display times as
> soon as you detect the need will be much easier than modifying s
On Wed, Dec 19, 2012 at 4:34 PM, Mike Versteeg wrote:
>> Maybe you should ask which clock is the most precise, and use that one as
>> your master clock? If that's not possible you won't have many other options
>> if everything has to be done on realtime; adapting frame display times as
>> soon
>> Either one can be used as master clock for the recorder. But I cannot sync
>> both clocks with each other if that's what you mean.
>
> Yes you can! You should set the PTS for the video stream according to
> the audio clock, that's it. I believe that you can know the audio
> clock by counting th
On Wed, Dec 19, 2012 at 5:27 PM, Mike Versteeg wrote:
> I can't as this would introduce double/missing frames, which is
> unacceptable for my app.
Why? The nominal frame rate of a video stream is only a guideline; the
actual PTS can handle reasonable jitter.
Alex
>> I can't as this would introduce double/missing frames, which is
>> unacceptable for my app.
>
> Why? The nominal frame rate of a video stream is only a guideline; the
> actual PTS can handle reasonable jitter.
My initial thought was just that: adjust the PTS to effectively
slightly change the f
On Wed, Dec 19, 2012 at 5:46 PM, Mike Versteeg wrote:
> video PTS, at least for MPEG-2, increments as integer (0, 1, 2, ...)
Oops, my bad... I lost your original requirement to be MPEG-2
compliant. But maybe it would be enough to set REPEAT_FIRST_FIELD once
in a while.
Alex
_
>> video PTS, at least for MPEG-2, increments as integer (0, 1, 2, ...)
>
> Oops, my bad... I lost your original requirement to be MPEG-2
> compliant. But maybe it would be enough to set REPEAT_FIRST_FIELD once
> in a while.
Thanks. I am not familiar with that. Won't that introduce a double
frame?
On Wed, Dec 19, 2012 at 6:14 PM, Mike Versteeg wrote:
>>> video PTS, at least for MPEG-2, increments as integer (0, 1, 2, ...)
>>
>> Oops, my bad... I lost your original requirement to be MPEG-2
>> compliant. But maybe it would be enough to set REPEAT_FIRST_FIELD once
>> in a while.
>
> Thanks. I
On Dec 19, 2012, at 16:46, Mike Versteeg wrote:
> the audio clock. But I have since learned (offline) that this is not
> possible as indeed the video PTS, at least for MPEG-2, increments as
> integer (0, 1, 2, ...). There's no fiddling with it. So short of
Can't you set the video's time scale s
Hi Carl,
thank you for your answer.
I've set the number of threads to 10, but every time my app crashes on
avcodec_decode_video2. Could you please assist me what I'm doing wrong?
Thanks,
Gohar
On 12/19/12 2:59 PM, Carl Eugen Hoyos wrote:
Gohar Hovhannisyan writes:
We wonder whether it is
17 matches
Mail list logo
