bugGnash - The GNU Flash player - Bugs: bug #21284, Animation completely distorted;...

 
 

bug #21284: Animation completely distorted; segmentation fault.

Submitted by:  Ludovico Fischer <ludovico_fischer>
Submitted on:  Sun 07 Oct 2007 02:19:07 PM UTC  
 
Category: videoSeverity: 6 - Security
Release: NoneStatus: Fixed
Privacy: PublicAssigned to: Sandro Santilli <strk>
Open/Closed: Closed

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Thu 08 Nov 2007 07:31:21 PM UTC, comment #18:

Closing because the segfault is fixed; missing video is a different problem.

Benjamin Wolsey <bwy>
Project Member
Fri 26 Oct 2007 12:23:05 PM UTC, comment #17:

I don't see a segfault any more, but can't see anything else, either distorted or otherwise. It is SWF8 video, so I wouldn't normally be surprised; but the original report mentioned seeing something distorted.

Benjamin Wolsey <bwy>
Project Member
Fri 19 Oct 2007 09:31:03 AM UTC, comment #16:

Used boost::scoped_ptr finally, for no specific reason preferred over std::auto_ptr...

Sandro Santilli <strk>
Project MemberIn charge of this item.
Fri 19 Oct 2007 09:18:12 AM UTC, comment #15:

THe bug was in a deleted and not-set-to-NULL pointer (_decoder in video_stream_def).
I'm working on it to use auto_ptr for safety and clarity.

Sandro Santilli <strk>
Project MemberIn charge of this item.
Thu 18 Oct 2007 04:19:36 PM UTC, comment #14:

A patch for this has been committed, please test.

Tomas Groth <tgc>
Wed 10 Oct 2007 03:10:12 PM UTC, comment #13:

youtube is using external movies in a FLV container which does contain information about what is key frame, and what is not.

Tomas Groth <tgc>
Wed 10 Oct 2007 02:49:43 PM UTC, comment #12:

ouch, what would happen for a continuos stream then ?
aren't we looking at what's a key frame already when doing seeks (like in youtube) ?

I guess if it makes your life easier decoding at parse time has to be preferred at this point. We have enough problems to add more complexity.

Sandro Santilli <strk>
Project MemberIn charge of this item.
Wed 10 Oct 2007 01:52:16 PM UTC, comment #11:

The problem is that decoding video frames most likely depends on the previous frames. Video frames consist of key frames(I), and interlaced frames(P). I-frames is independent of previous frames, while P-frames depends on the last I-frame and all P-frames since. A frames sequence can be like this:
IPPPPPPPPPIPPPPPPPPIPPPPPPPP
So if you want to randomly see the 9th frame, you'll have to decode the I-frame, and all 8 P-frames to get a result. This could be done in gnash, though i'm not sure how well it would work. But to complicate matters even more we don't have an easy way (in swf-tags) to know the difference between I and P frames. We could perhaps look into the video-data, but if possible i'd like to avoid that.

Tomas Groth <tgc>
Wed 10 Oct 2007 01:27:42 PM UTC, comment #10:

Can't we access and undecode random frames at ::display time ?
I'd avoid decoding during parsing, as if display is skipped for some frames (gotoFrame?) we'll save processing time and memory.

Sandro Santilli <strk>
Project MemberIn charge of this item.
Wed 10 Oct 2007 12:38:48 PM UTC, comment #9:

Ok, I've tested some more, and I've found some of the reason for this mess: We should decode the video frames when parsing, so that random frames can be accessed (as you mentioned), so instead of the undecoded data we'll store all the frames as image::rgb's

Also you seem to have a valid point in the 0/1 frame indexing.

Tomas Groth <tgc>
Wed 10 Oct 2007 10:48:02 AM UTC, comment #8:

I see video_stream_instance is using frame number of the parent
to tell current frame. That might be the problem.
We should likely have our own frame count instead or what would happen if we're placed (as a video_stream_character) in frame 10 of a parent ? we'll we start displaying frame 10 of the animation ??

Sandro Santilli <strk>
Project MemberIn charge of this item.
Wed 10 Oct 2007 10:19:38 AM UTC, comment #7:

As long as a character is placed in a display list, it's ::display is called as far as I know.
Add debugging calls to tell which undecoded frame is being accessed, maybe 0-based and 1-based are being messed up ?
Does video_stream_instance have a frame counter to tell which frame it should be rendering ?

Sandro Santilli <strk>
Project MemberIn charge of this item.
Wed 10 Oct 2007 10:15:45 AM UTC, comment #6:

We actually do decode embedded video frames (which is the ones we talk about here) on ::display, so I guess display isn't called the first time around either?

You mention using ::stagePlacementCallback for decoding the first frame, but as I understand that, it would mean that the first video frame would never be displayed, which IMHO would be wrong behaviour...

Tomas Groth <tgc>
Wed 10 Oct 2007 09:47:43 AM UTC, comment #5:

I belive the problem is that decoding happens on ::advance rather then ::display, and ::advance is not called if not on second iteration. ::stagePlacementCallback registers self as an "advanceable character", so next frame ::advance will be called.
A fix would be to do the thing (I guess decoding of first frame) on ::stagePlacementCallback.

I don't have a full picture of how video_character_inst is supposed to do decoding and where from and when, but the above is likely the cause.

Wouldn't it be easier to decode on ::display rather then on ::advance ?

If we do so, when skipping rendering if late (gui.cpp supports this) we'll save decoding time...

Sandro Santilli <strk>
Project MemberIn charge of this item.
Mon 08 Oct 2007 11:24:30 AM UTC, comment #4:

After some digging around, this turns out to be caused by a different gnash bug: First video frame isn't decoded/played. For some reason the first embedded videoframe (placed in the first flash-frame I assume) isn't decoded. The reason for the crash (older ffmpeg versions) or error messages (newer ffmpeg versions), is that VP6 isn't as forgiving as the FLV format. To see the problem in a SWF with FLV codec where it's obvious try http://www.funpic.hu/swf/numanuma.swf

Tomas Groth <tgc>
Mon 08 Oct 2007 07:27:12 AM UTC, comment #3:

With GST different behaviour but still bogus. A deadlock:

#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7939dae in __lll_mutex_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb7935aac in _L_mutex_lock_51 () from /lib/tls/i686/cmov/libpthread.so.0
#3 0xb793549d in pthread_mutex_lock () from /lib/tls/i686/cmov/libpthread.so.0
#4 0xb6c3f535 in boost::mutex::do_lock () from /usr/lib/libboost_thread-gcc-mt-1_33_1.so.1.33.1
#5 0xb7a17483 in gnash::VideoDecoderGst::decodeToImage (this=0x834fdf0,
data=0x8353470 "�Y\033\023~y����\003&:�=���C�?�p�\223/��=w{y\2354��\r�'�}����{y�/��[���j��\n�o�7���\n���\177[sW)�\024\234\0254��E5\006�.6.8�\025�\210�)\030Nw\213l�\001a8�����*YV�.(�\230z\213�v?�\"��L.���sg\211\003\032B{��\217M\n\002\005\207\210��r�\222z�/y��\232Dv�mW�\225\034\233��\214�q��68\233\v\202T\022�%\021e����=\t)\223e\220\216�\225"..., size=931) at /usr/include/boost/thread/detail/lock.hpp:38
#6 0xb7bff3e4 in gnash::video_stream_instance::display (this=0x83e13a8) at /home/strk/src/gnash/gnash-head/server/video_stream_instance.cpp:216
#7 0xb7c80c05 in gnash::DisplayList::display (this=0x83dfa74) at /home/strk/src/gnash/gnash-head/server/dlist.cpp:809

Sandro Santilli <strk>
Project MemberIn charge of this item.
Mon 08 Oct 2007 06:50:12 AM UTC, comment #2:

I confirm the segfault with FFMPEG Lavc0d.51.11.0 - with HEAD
The following backtrace is while running with -r1 (rendering only). Didn't try with GST yet.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1234839856 (LWP 8555)]
0xb6ecaa36 in avcodec_decode_video () from /usr/lib/libavcodec.so.0d
(gdb) bt
#0 0xb6ecaa36 in avcodec_decode_video () from /usr/lib/libavcodec.so.0d
#1 0xb7d1137d in gnash::VideoDecoderFfmpeg::decode (this=0x828b538,
input=0x828e818 "�Y\033\023~y����\003&:�=���C�?�p�\223/��=w{y\2354��\r�'�}����{y�/��[���j��\n�o�7���\n���\177[sW)�\024\234\0254��E5\006�.6.8�\025�\210�)\030Nw\213l�\001a8�����*YV�.(�\230z\213�v?�\"��L.���sg\211\003\032B{��\217M\n\002\005\207\210��r�\222z�/y��\232Dv�mW�\225\034\233��\214�q��68\233\v\202T\022�%\021e����=\t)\223e\220\216�\225"..., inputSize=931, outputSize=@0xbfc87038) at sdl/VideoDecoderFfmpeg.cpp:220
#2 0xb7d11141 in gnash::VideoDecoderFfmpeg::decodeToImage (this=0x828b538,
input=0x828e818 "�Y\033\023~y����\003&:�=���C�?�p�\223/��=w{y\2354��\r�'�}����{y�/��[���j��\n�o�7���\n���\177[sW)�\024\234\0254��E5\006�.6.8�\025�\210�)\030Nw\213l�\001a8�����*YV�.(�\230z\213�v?�\"��L.���sg\211\003\032B{��\217M\n\002\005\207\210��r�\222z�/y��\232Dv�mW�\225\034\233��\214�q��68\233\v\202T\022�%\021e����=\t)\223e\220\216�\225"..., inputSize=931) at sdl/VideoDecoderFfmpeg.cpp:319
#3 0xb7e12648 in gnash::video_stream_instance::display (this=0x8318a48) at video_stream_instance.cpp:216
#4 0xb7e49a20 in gnash::DisplayList::display (this=0x8317294) at dlist.cpp:809

Sandro Santilli <strk>
Project MemberIn charge of this item.
Sun 07 Oct 2007 04:51:15 PM UTC, comment #1:

With head I just get:

6624] 18:46:08: ERROR: Decoding of a video frame failed
6624] 18:46:08: ERROR: An error occured while decoding video frame

Benjamin Wolsey <bwy>
Project Member
Sun 07 Oct 2007 02:19:07 PM UTC, original submission:

Playing the attached movie (found on http://www.novell.com/linux) gives:

7875] 16:14:45: Verbose output turned on
7875] 16:14:45: No rendering flags specified, using rcfile
7875] 16:14:45: Your X server expects RGB24 pixmap data for standard mode.
7875] 16:14:45: Created top level window
7875] 16:14:45: framebuffer pixel format is RGB24
7875] 16:14:45: Base url set to: file:///home/ludovico/Documents/gnash-bugs/fb_ylir_220.swf
7875] 16:14:45: ERROR: Unimplemented: SWF8 is not fully supported, trying anyway but don't expect it to work
7875] 16:14:45: Movie file:///home/ludovico/Documents/gnash-bugs/fb_ylir_220.swf (SWF8) added to library
7875] 16:14:45: GTK-AGG: 300000 bytes offscreen buffer allocated

7875] 16:14:45: initialized AGG buffer <0xb6a56008>, 300000 bytes, 454x220, rowsize is 1362 bytes
7875] 16:14:45: ERROR: Unimplemented: FileAttributes tag in the SWF requests that network access is not granted to this movie (or application?). Anyway Gnash won't care; use white/black listing in your .gnashrc instead
7875] 16:14:46: ERROR: Unimplemented: FIXME: tagtype = 70
7875] 16:14:46: DEBUG: video_stream_instance 0x83f0900 ctor
7875] 16:14:46: ERROR: FIXME: DefineFontAlignZoneTag unfinished
7875] 16:14:46: ERROR: *** no tag loader for type 88 (movie)
7875] 16:14:46: ERROR: FIXME: DefineFontAlignZoneTag unfinished
7875] 16:14:46: ERROR: *** no tag loader for type 88 (movie)
7875] 16:14:46: ERROR: Unimplemented: FIXME: tagtype = 74
7875] 16:14:46: ERROR: FIXME: DefineFontAlignZoneTag unfinished
7875] 16:14:46: ERROR: *** no tag loader for type 88 (movie)
7875] 16:14:46: ERROR: FIXME: DefineFontAlignZoneTag unfinished
Segmentation fault (core dumped)

Ludovico Fischer <ludovico_fischer>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #14110:  fb_ylir_220.swf added by ludovico_fischer (462kB - application/x-shockwave-flash)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by tgc (Posted a comment)
  • -unavailable- added by strk (Posted a comment)
  • -unavailable- added by bwy (Posted a comment)
  • -unavailable- added by ludovico_fischer (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 13 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 08 Nov 2007 07:31:21 PM UTCbwyStatusReady For Test=>Fixed
      Open/ClosedOpen=>Closed
    Fri 19 Oct 2007 09:31:03 AM UTCstrkStatusIn Progress=>Ready For Test
    Fri 19 Oct 2007 09:18:12 AM UTCstrkStatusReady For Test=>In Progress
      Assigned totgc=>strk
    Thu 18 Oct 2007 04:19:36 PM UTCtgcSeverity3 - Normal=>6 - Security
      StatusIn Progress=>Ready For Test
    Wed 10 Oct 2007 03:10:12 PM UTCtgcStatusConfirmed=>In Progress
    Mon 08 Oct 2007 07:27:12 AM UTCstrkAssigned toNone=>tgc
    Mon 08 Oct 2007 06:50:12 AM UTCstrkCategoryrelease 0.8.1=>video
      Item Group0.8.1 release=>None
      StatusNone=>Confirmed
    Sun 07 Oct 2007 02:19:07 PM UTCludovico_fischerAttached File-=>Added fb_ylir_220.swf, #14110

    Back to the top


    Powered by Savane 3.1-cleanup