[Libav-user] Problems with ffvhuff and huvvyuv

[James Board]

>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 I don't know why.
I modified the demuxing.c example so that it seeks to frame 0, calls
decode_packet, seeks to frame 10, calls decode_packet, etc.  I
seek to every 10th frame and call decode_packet().  I also
modified decode_packet() so that it writes an output file whenever 

'got_frame' is non-zero.  For the first four seeks (frame 0, 10, 20, 30),
'got_frame' is NULL and no output image files are written.  Then,
when I seek to frame 40, the output file for frame 0 is written.  When I seek to
60, the output for frame 10 is written.  When I seek to frame 60, the output
for frame 20 is written, etc.  Eventually, the 'flush cached frames' loop is
entered and the final files are written.

Does this make sense or sound familiar to anyone?  What is happening here?
Does this have anything to do with cached frames?  I've before what 'cached
frames' are but nobody answered.  Does anyone understand this?

Also, none of the above oddness happens if I use AVI files encoded with 

no codec or with lossless JPEG, or a few other codecs.





On Wednesday, October 16, 2013 3:48 PM, Paul B Mahol <onemda at gmail.com> wrote:
 
On 10/16/13, Paul B Mahol <onemda at gmail.com> wrote:
> On 10/16/13, James Board <jpboard2 at yahoo.com> 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 that way, and my code
>> might be screwed.  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.  If the answer
>> is 'yes', then I know not to dig through the source code (big
>> learning curve) because that effort can't possibly work.  If
>> the answer is 'no, then I'll press on.
>
> There is nothing in huffyuv algorithm and ffvhuff which could cause this.
>

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

_______________________________________________
Libav-user mailing list
Libav-user at ffmpeg.org
http://ffmpeg.org/mailman/listinfo/libav-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ffmpeg.org/pipermail/libav-user/attachments/20131017/b92685d9/attachment.html>