Bruce Dubbs wrote:
Paul Hentschel wrote:
On 06/06/2016 03:02 PM, Tim Tassonis wrote:
Hi Bruce


On 06/06/16 20:48, Bruce Dubbs wrote:
I've been trying to remove qt4 from the book. Right now I'm working on
vlc.  There is a new release, 2.2.4, but I've had to find a lot of
patches to make it work with both qt5 and gcc6.  We already have one
patch and I can certainly create a consolidated patch, but it is a lot
of work to get things right.

On the other hand I can create a tarball from git, vlc-3.0.0-git.tar.xz, that works in a straightforward way with qt5 and gcc6. The tarball can
be hosted on anduin.

I'm inclined to go with the git version, but it is an exception to our
normal policy of using just 'stable' releases.  In this case, the
upstream 2.2.4 release, and predecessors, do not seem to be very stable
in our development environment.

I'm asking for opinions before I proceed.

I'd definitely would welcome the switch to 3.0.0-git and qt 5 and would
also test it and report problems.

Maybe, if it is not any extra work for you, you could leave the old vlc
2 page and add a vlc 3 page, until it's clear that vlc 3/qt5 works well?


Tim


I want to pass along some issues I am having with this version that I
don't have with vlc-2.2.3. That version (2.2.3) was built on a separate
build using Qt 5.6 and gcc5.3 (same hardware). This version I built using
Qt 5.7 and gcc6. For video output I am using OpenGL GLX on both builds,
but I tried the others to see if it would solve my issues.

Here are links to two sample videos for reference. The first (lower
resolution) video plays fine. The second (higher resolution) video plays
for about a second then the screen turns gray and pixelated. Both of these
videos play fine in Parole.

http://hubblesource.stsci.edu/sources/video/clips/details/images/m84_1.mpg

http://hubblesource.stsci.edu/sources/video/clips/details/images/m84_2.mpg

The second video fails for me too.

[VS] {full} VdpBitmapSurfaceDestroy surface=105
[VS] {full} VdpPresentationQueueGetTime presentation_queue=27
[VS] {full} VdpPresentationQueueDisplay presentation_queue=27, surface=99, clip_width=0, clip_height=0,
           earliest_presentation_time=1469226152037282892
[mpeg2video @ 0x7fd1f0001a40] ac-tex damaged at 33 25
[mpeg2video @ 0x7fd1f0001a40] 00 motion_type at 29 28
[mpeg2video @ 0x7fd1f0001a40] Warning MVs not available
[mpeg2video @ 0x7fd1f0001a40] interlaced frame in progressive sequence, ignoring
Segmentation fault

A gdb backtrace shows:

Thread 42 "vlc" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff8899c700 (LWP 29072)]
0x00007ffff6a8cf65 in __memcpy_avx_unaligned () from /lib/libc.so.6
(gdb) bt
#0  0x00007ffff6a8cf65 in __memcpy_avx_unaligned () at /lib/libc.so.6
#1 0x00007fffee5c992e in NoSwap (src=0x7fffb091184c "", dest=<optimized out>, srclen=<optimized out>, srcinc=3072, destinc=96, height=<optimized out>, half_order=0)
    at PutImage.c:154
#2 0x00007fffee5ca02f in PutSubImage (req_yoffset=<optimized out>, req_xoffset=<optimized out>, image=<optimized out>, req=0x7fffa418b9e0, dpy=<optimized out>)
    at PutImage.c:739
#3 0x00007fffee5ca02f in PutSubImage (gc=<optimized out>, dest_scanline_pad=<optimized out>, dest_bits_per_pixel=<optimized out>, req_height=<optimized out>, req_width=<optimized out>, y=<optimized out>, x=<optimized out>, req_yoffset=<optimized out>, req_xoffset=<optimized out>, image=<optimized out>, d=<optimized out>, dpy=<optimized out>)
    at PutImage.c:858
#4 0x00007fffee5ca02f in PutSubImage (dpy=<optimized out>, d=<optimized out>, gc=<optimized out>, image=<optimized out>, req_xoffset=<optimized out>, req_yoffset=<optimized out>, x=0, y=0, req_width=768, req_height=113, dest_bits_per_pixel=1, dest_scanline_pad=32) at PutImage.c:898 #5 0x00007fffee5c9ab6 in PutSubImage (dpy=0x7fffa43639b0, d=65011717, gc=0x7fffa487da30, image=0x7fffa4f23570, req_xoffset=<optimized out>, req_yoffset=<optimized out>, x=0, y=0, req_width=768, req_height=576, dest_bits_per_pixel=1, dest_scanline_pad=32)
    at PutImage.c:907
#6 0x00007fffee5ca9d2 in XPutImage (dpy=0x7fffa43639b0, d=65011717, gc=0x7fffa487da30, image=0x7fffa4f23570, req_xoffset=0, req_yoffset=<optimized out>, x=0, y=0, req_width=768, req_height=576) at PutImage.c:1017
#7  0x00007fffddebf517 in swrastPutImage2 () at /opt/xorg/lib/libGL.so.1
#8  0x00007fffddebf543 in swrastPutImage () at /opt/xorg/lib/libGL.so.1
#9 0x00007fffc3337416 in drisw_put_image () at /opt/xorg/lib/dri/swrast_dri.so
#10 0x00007fffc3337a8b in drisw_flush_frontbuffer ()
    at /opt/xorg/lib/dri/swrast_dri.so
#11 0x00007fffc3335e65 in dri_st_framebuffer_flush_front ()
    at /opt/xorg/lib/dri/swrast_dri.so
#12 0x00007fffc30e7030 in _mesa_make_current () at /opt/xorg/lib/dri/swrast_dri.so #13 0x00007fffc3262aeb in st_api_make_current () at /opt/xorg/lib/dri/swrast_dri.so #14 0x00007fffc3335c9f in dri_unbind_context () at /opt/xorg/lib/dri/swrast_dri.so #15 0x00007fffc333571a in driUnbindContext () at /opt/xorg/lib/dri/swrast_dri.so #16 0x00007fffddea103d in glXMakeCurrentReadSGI () at /opt/xorg/lib/libGL.so.1
#17 0x00007fff90c82427 in do_presentation_queue_display ()
    at /opt/xorg/lib/vdpau/libvdpau_va_gl.so.1
#18 0x00007fff90c82ad9 in presentation_thread ()
    at /opt/xorg/lib/vdpau/libvdpau_va_gl.so.1
#19 0x00007ffff6f123e4 in start_thread () at /lib/libpthread.so.0
#20 0x00007ffff6a4dcfd in clone () at /lib/libc.so.6

You might want to report this upstream.

  -- Bruce

I can't even get parole to play the second file. I wonder if it is corrupted. I have grabbed two copies now and neither of them have worked. First file plays file. Parole throws up a "Gstreamer Backend Error", and Mplayer does absolutely nothing. It doesn't even play the first file, so I wonder if Mplayer is broken altogether at this time.

m84_1.mpg is 859KB for me and m84_2.mpg is 16.0 MB. Is this correct?

If it is infact that the file is corrupted, have you tried using anything to repair it? Even the first file doesn't appear to have an index (when I played it through mplayer) so it couldn't fast forward or go back.

Also, since we seem to be tapping into AVX Multimedia territory, as that is what FFMPEG uses when doing decoding of MPEG-1/MPEG-2 files, what CPU are you using? I am using a i5-2400 SandyBridge here. Bruce's stack trace points out that we are tapping into memcpy as part of the AVX feature set, specifically unaligned stuff. There is a GCC bug report out about memcpy and unaligned stuff, but it was created in 2012 and no one wants to take action on it as it wouldn't be considered "portable" anymore.

--
Douglas R. Reno
--LFS/BLFS systemd maintainer

--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to