On further digging i found that in producer_avformat.c:seek_video, if i replace AVSEEK_FLAG_BACKWARD with AVSEEK_FLAG_ANY, then that "faulty" video plays smoothly. It points to some issue with keyframes. What i was doing is that i was generating series of PNG files using a canvas-based-firefox-extended-animation script. Then i was stitching those PNG files into a Theora video, using `ffmpeg -r 24 -qscale 31 -i %07d.png output.ogv`. Most of the videos were running fine in melt, except one or two. My idea was to put those small pieces of videos into kdenlive and make an animated music video. So, as this or other specific video was not working as expected, it was eating my brain alive :). But AVSEEK_FLAG_ANY boosted some neurons and i finally realized that i need to put keyframe at the begining of the video. Hence i tried `ffmpeg -r 24 -qscale 31 -i %07d.png -g 1 output.ogv`, which puts keyframe in every frame, (although using -g 1000 would work as well) and the resulted video worked smoothly on melt without any code modification. I was even able to run that "faulty" video properly after converting it using `ffmpeg -qscale 31 -i old.ogv -g 1 new.ogv`.

On Sat, Jun 16, 2012 at 6:45 AM, Dan Dennedy <dan@dennedy.org> wrote:
On Thu, Jun 14, 2012 at 9:51 PM, Sujoy Roy <sujoykroy@gmail.com> wrote:
> I have uploaded  the "specific" video using ftp. The filename is
> beating_bars.ogv. While debugging through producer_avformat.c, i checked the
> value of pkt.dts after av_read_frame being called in producer_get_image. And
> found that its value is jumping from 0, 1 to directly to 169. And if i press
> shift+h, then it goes back to the begining and plays perfectly ok, and value
> of pkt.dts increases smoothly from 0,1,2,3, ...
> After digging through this phenomena of shift+h, i found that when i am
> pressing shft+h, it is calling reopen_video.

There is something that is preventing libavformat from properly
seeking within the first 20% or so of this file. When I play it in
avplay and seek in the 5% to 20% range, then it too pauses for a while
until time "catches up" to the stream. So, even if it were possible to
overcome the problem playing from the beginning, if you set an in
point somewhere before 169, then it will have a problem. If I force
the clip to be non-seekable within
producer_avformat.c:get_basic_info() then it does play fine, and that
looks to be the only real workaround. The test for seek-ability passes
on this clip, but it is not desirable to make the test more stringent.
Usually, there are more false negatives than false positives. I could
add a force_seekable property to the consumer so people can choose to
workaround faulty clips for simple, sequential playback or transcode

> - Sujoy
> On Fri, Jun 15, 2012 at 6:09 AM, Dan Dennedy <dan@dennedy.org> wrote:
>> On Tue, Jun 12, 2012 at 11:36 AM, Sujoy Roy <sujoykroy@gmail.com> wrote:
>> > When i play a  "specific" Theora video using melt, it freezes (sort of)
>> > the
>> > melt-screen upto first 190 frames, then it moves as expected. But it
>> > plays
>> > smoothly in ffmpeg or totem player, no freezing; i am on Fedora 16. I
>> > have
>> > downloaded the source code of melt. But there is no text containing
>> > "theora" in those files. I guess the video decoding is being handled by
>> > libavformat. Any tip about where to dive-in to find the cause of the
>> > video
>> > freezing?
>> See src/modules/avformat/producer_avformat.c
>> I am in the middle of a complete overhaul of the seek and sync in that
>> piece of code. Likely your file will be affected as well as possibly
>> any fix you come up with. If you upload it via anonymous ftp to
>> dennedy.org, then I will take a look at it in the midst of checking my
>> code changes.
>> --
>> +-DRD-+
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Mlt-devel mailing list
> Mlt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mlt-devel