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

 
 

bug #21284: Animation completely distorted; segmentation fault.

Submitter:  Ludovico Fischer <ludovico_fischer>
Submitted:  Sun 07 Oct 2007 02:19:07 PM UTC
   
 
Category:  video Severity:  6 - Security
Release:  None Status:  Fixed
Privacy:  Public Assigned to:  strk
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group 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>
Group 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>
Group Member
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>
Group Member
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>
Group Member
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>
Group Member
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>
Group Member
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>
Group Member
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>
Group Member
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>
Group Member
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>
Group Member
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>
Group Member
Sun 07 Oct 2007 02:19:07 PM UTC, original submission:  

Playing the attached movie (found on 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 Files:
   
   
Comment:
   

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

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 13 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-11-08 bwy StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2007-10-19 strk StatusIn Progress Ready For Test
    2007-10-19 strk StatusReady For Test In Progress
        Assigned totgc strk
    2007-10-18 tgc Severity3 - Normal 6 - Security
        StatusIn Progress Ready For Test
    2007-10-10 tgc StatusConfirmed In Progress
    2007-10-08 strk Assigned toNone tgc
    2007-10-08 strk Categoryrelease 0.8.1 video
        Item Group0.8.1 release None
        StatusNone Confirmed
    2007-10-07 ludovico_fischer Attached File- Added fb_ylir_220.swf, #14110

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code