[Libav-user] Problems with ffvhuff and huvvyuv

[Bruce Wheaton]

On Oct 17, 2013, at 10:31 AM, James Board <jpboard2 at yahoo.com> 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 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?

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 the next decode action will return the frame that you started decoding in the first call. That's why you have to look at the frame number of the decoded frame, not of the packet you passed in. Maybe you also get a frame back if it's 'ready' - not sure.

Note - this means you always have to run decode a few extra times with a null packet to get the frames flushed out.
> 
> 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.

Possibly those codecs don't support multithreading? Certainly 'none' wouldn't do anything, so that would be expected. Id' hope that lossless JPEG would use threads though, so I may be off track.


Bruce



> 
> 
> 
> 
> 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
> 
> 
> _______________________________________________
> 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/3e0330b4/attachment.html>