On 10/17/13, James Board wrote:
>>What you're describing
> sounds like the multithreading approach that ffmpeg uses. My
>>understanding: The first decode call starts a decode action which spawns a
>> thread to >decode that frame. Each subsequent decode call starts a new
>> action/thread, until you
>What you're describing
sounds like the multithreading approach that ffmpeg uses. My
>understanding: The first decode call starts a decode action which spawns a
>thread to >decode that frame. Each subsequent decode call starts a new
>action/thread, until you run >out of threads, at which point
On Oct 17, 2013, at 10:31 AM, James Board wrote:
> >And issue is probably withing avi container as it
> >may not add every frame into index table.
> >And when seeking you never check if returned packet actually is right
> >one that you need.
> >
> >Or it could be bug in your code how you seek in
>And issue is probably withing avi container as it
>may not add every frame into index table.
>And when seeking you never check if returned packet actually is right
>one that you need.
>
>Or it could be bug in your code how you seek in file, etc...
Sorry for the top post (again). The problem is Y
>And issue is probably withing avi container as it
>may not add every frame into index table.
>And when seeking you never check if returned packet actually is right
>one that you need.
>
>Or it could be bug in your code how you seek in file, etc...
I did a rewrite of my code and it now works. But
On 10/17/13, James Board wrote:
>>On 10/17/13, James Board wrote:
You noted it wrong. Huffyuv does use SIMD.
>>>
>>> Where? I didn't see any SIMD instructions in huffyuvenc.c or
>>> huffyuvdec.c. Am I looking in the wrong place?
>>
>>It is not in huffyuvdec.c
>>
>>I will give more info once
>On 10/17/13, James Board wrote:
>>>You noted it wrong. Huffyuv does use SIMD.
>>
>> Where? I didn't see any SIMD instructions in huffyuvenc.c or
>> huffyuvdec.c. Am I looking in the wrong place?
>
>It is not in huffyuvdec.c
>
>I will give more info once you stop top posting.
I'm sorry about tha
On 10/17/13, James Board wrote:
>>You noted it wrong. Huffyuv does use SIMD.
>
> Where? I didn't see any SIMD instructions in huffyuvenc.c or
> huffyuvdec.c. Am I looking in the wrong place?
It is not in huffyuvdec.c
I will give more info once you stop top posting.
>
>
>
>
>
> On Wednesday, Oc
>You noted it wrong. Huffyuv does use SIMD.
Where? I didn't see any SIMD instructions in huffyuvenc.c or
huffyuvdec.c. Am I looking in the wrong place?
On Wednesday, October 16, 2013 4:45 PM, Paul B Mahol wrote:
On 10/16/13, James Board wrote:
>>And issue is probably withing avi containe
On 10/16/13, James Board wrote:
>>And issue is probably withing avi container as it
>>may not add every frame into index table.
>>And when seeking you never check if returned packet actually is right
>>one that you need.
>>
>>Or it could be bug in your code how you seek in file, etc...
>
> I do ch
>And issue is probably withing avi container as it
>may not add every frame into index table.
>And when seeking you never check if returned packet actually is right
>one that you need.
>
>Or it could be bug in your code how you seek in file, etc...
I do check the results of the seek and I do check
On 10/16/13, Paul B Mahol wrote:
> On 10/16/13, James Board wrote:
>>>Why don't you simply test this yourself?
>>>It cannot take more time to test than to write your
>>>mail, let alone write (and read!) the answers.
>>
>> I did. It generated the extra frames. So the libav implementation
>> work
On 10/16/13, James Board wrote:
>>Why don't you simply test this yourself?
>>It cannot take more time to test than to write your
>>mail, let alone write (and read!) the answers.
>
> I did. It generated the extra frames. So the libav implementation
> works this way. Or at least my code works tha
On Wed, Oct 16, 2013 at 9:27 PM, James Board wrote:
> The question I mean to ask (maybe I wasn't clear)
> is whether there is anything fundamental to the huffyuv algorithm
> which prevents me from decoding a single frame.
I believe that there may be some variations of the original huffyuv
purely
>Why don't you simply test this yourself?
>It cannot take more time to test than to write your
>mail, let alone write (and read!) the answers.
I did. It generated the extra frames. So the libav implementation
works this way. Or at least my code works that way, and my code
might be screwed. Th
James Board writes:
> It would be nice if someone told me beforehand whether
> or not this is a problem that can be fixed.
Ok, so far this is understandable.
> If I want to decode a single isolated frame with
> ffvhuff, does the ffvhuff algorithm require me to
> decode multiple frames after
>> I don't know that codec. I just knew it was lossless. So I guess
>> (unless there's a bug) the rule has an exception. Maybe the
>> 'adaptive tables' that google says it has adapt every 24 or so
>> frames. Don't have the source in front of me right now.
>>
>> But it's an FOSS project - anyon
On Oct 16, 2013, at 8:56 AM, Bruce Wheaton wrote:
>
>> On Oct 16, 2013, at 8:46, Paul B Mahol wrote:
>>> The only workaround is to use intra-frame only compression, so all frames
>>> are independent. Some codecs you listed always work that way.
>>
>> ffvhuff is intra only.
>
> I don't know th
> On Oct 16, 2013, at 8:46, Paul B Mahol wrote:
>> The only workaround is to use intra-frame only compression, so all frames
>> are independent. Some codecs you listed always work that way.
>
> ffvhuff is intra only.
I don't know that codec. I just knew it was lossless. So I guess (unless
ther
On 10/16/13, Bruce Wheaton wrote:
>
>
>
> Bruce
>
>
>> On Oct 16, 2013, at 6:52, James Board > Does my question make sense to anyone? Or am I doing something very
>> wrong
>> with libav and seeking? Has anyone seen this behavior before when you
>> seek to
>> position N in a file, but the first f
Bruce
> On Oct 16, 2013, at 6:52, James Board Does my question make sense to anyone? Or am I doing something very wrong
> with libav and seeking? Has anyone seen this behavior before when you seek to
> position N in a file, but the first few frames that get decoded are lower
> than N?
> Is
>I have an libAV program that decodes every 24-th frame. This is for
>a video editor so I can easily seek forward in the video, rather than
>play all frames.
>If the input file is uncompressed AVI, then this works well.
>However, if I compress the video with ffvhuff or huffvuy, then whenever I
>s
I have an libAV program that decodes every 24-th frame. This is for
a video editor so I can easily seek forward in the video, rather than
play all frames.
The high-level psuedo-code looks like this
for (int f = 0 ; f < LargeNumber; f+= 24) {
avformat_seek_file(ctx, 0, f, f, f, AVSEEK_
23 matches
Mail list logo
