Maybe related issue: https://bugzilla.gnome.org/show_bug.cgi?id=793836

I have just found out the source material being matroska avc stream going in is triggering the copyrighted content is required to replicate it. The big buck bunny transcoded file works fine on totem I just found out. I assumed it would be broken too. I'll attach 10 seconds of a my little pony blueray corrupted file I transcoded for my daughter that breaks totem / hardware players, and because it was created with x264/mkvmerge I'll include the source materials encoding settings below to replicate the defect. I think only 10 seconds would be fair use. Encoded with exactly the same parameters as above.

https://mega.nz/#!nqISgDLA!rvGIBMI8wCYBL7An4Fi9Az3VCINu3AvKxOMgj5f_gQo
2.6mb vaapitest2.mkv


General

Format                                   : Matroska
Format version                           : Version 4 / Version 2
File size                                : 4.37 GiB
Duration                                 : 1 h 39 min
Overall bit rate                         : 6 302 kb/s
Encoded date                             : UTC 2017-12-30 18:42:40
Writing application                      : mkvmerge v8.5.2 ('DiAMOND') 64bit
Writing library                          : libebml v1.3.3 + libmatroska v1.4.4

Video
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L4.1
Format settings                          : CABAC / 5 Ref Frames
Format settings, CABAC                   : Yes
Format settings, ReFrames                : 5 frames
Codec ID                                 : V_MPEG4/ISO/AVC
Duration                                 : 1 h 39 min
Bit rate                                 : 5 531 kb/s
Width                                    : 1 920 pixels
Height                                   : 808 pixels
Display aspect ratio                     : 2.40:1
Frame rate mode                          : Constant
Frame rate                               : 23.976 (24000/1001) FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.149
Stream size                              : 3.75 GiB (86%)
Writing library                          : x264 core 152 r2851 ba24899
Encoding settings                        : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=8 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=24 / lookahead_threads=4 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=2pass / mbtree=1 / bitrate=5531 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00
Language                                 : English
Default                                  : Yes
Forced                                   : No

Audio
ID                                       : 2
Format                                   : DTS
Format/Info                              : Digital Theater Systems
Codec ID                                 : A_DTS
Duration                                 : 1 h 39 min
Bit rate mode                            : Constant
Bit rate                                 : 768 kb/s
Channel(s)                               : 6 channels
Channel positions                        : Front: L C R, Side: L R, LFE
Sampling rate                            : 48.0 kHz
Frame rate                               : 93.750 FPS (512 SPF)
Bit depth                                : 24 bits
Compression mode                         : Lossy
Stream size                              : 545 MiB (12%)
Language                                 : English
Default                                  : Yes
Forced                                   : No

Text #1
ID                                       : 3
Format                                   : UTF-8
Codec ID                                 : S_TEXT/UTF8
Codec ID/Info                            : UTF-8 Plain Text
Title                                    : English regular
Language                                 : English
Default                                  : No
Forced                                   : No

Text #2
ID                                       : 4
Format                                   : UTF-8
Codec ID                                 : S_TEXT/UTF8
Codec ID/Info                            : UTF-8 Plain Text
Title                                    : English SDH
Language                                 : English
Default                                  : No
Forced                                   : No

(In reply to Julien Isorce from comment #1)
> Maybe related issue: https://bugzilla.gnome.org/show_bug.cgi?id=793836

You may be right. That shows you gst can't play back content it encoded itself using vaapi on amd's. I was using ffmpeg. This shows the ball is in #drm-devel's court.

gst-play-1.0 vaapitest2.mp4 
Press 'k' to see a list of keyboard shortcuts.
Now playing /mnt/tmp/movies/vaapitest2.mp4
ERROR This file contains no playable streams. for file:///mnt/tmp/movies/vaapitest2.mp4
ERROR debug information: /var/tmp/portage/media-libs/gst-plugins-good-1.12.4/work/gst-plugins-good-1.12.4/gst/isomp4/qtdemux.c(703): gst_qtdemux_post_no_playable_stream_error (): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstQTDemux:qtdemux0:
no known streams found
Reached end of play list

I'll try encoding with gstreamer-1.0 and update the ticket.

(In reply to Julien Isorce from comment #1)
> Maybe related issue: https://bugzilla.gnome.org/show_bug.cgi?id=793836

No it's working fine here with gst-play-1.0 using omx (i hacked the priorities in gstreamer to use omx decoding over vaapi).  (media-plugins/gst-plugins-omx-1.12.4)

So now more testing for good luck..... 

<10 mins later>

I'll attach a gstreamer debug log for playing that file with omx,vaapi, and xv/ffmpeg if you are curious. That proves 100% this issue isn't related to that bug at all.


That ticket was a vaapi decoding issue. The test vector they uploaded also plays here without problems with gstreamer 1.12.4. totem seems to crash on it though but it's probably something to do with clutter and a very short file.

I made a longer file with this:
gst-launch-1.0 videotestsrc pattern=blink num-buffers=30   ! video/x-raw, framerate=30/1   ! x264enc key-int-max=1   ! mp4mux faststart=true movie-timescale=300 trak-timescale=30   ! filesink location=i-frames-non-frag.mp4

Created attachment 137670 [details]
gst-play-1.0 debug log using VAAPI - gstreamer bug #793836 is not at play.

I also have similar logs for xv,omx - works fine here.

gst-plugins-vaapi here is of course merged without egl support btw, because I don't think that's working yet with amd & mesa.

#ffmpeg dev jkqxz suggested i check a few things.

ffmpeg-git -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -hwaccel_output_format vaapi -t 60 -i pony.mkv -map 0:0 -vf scale_vaapi=w=1366:h=768 -c:v h264_vaapi -b:v 2000k -qp 20 -bf 0 -profile:v constrained_baseline -sn -quality:v 0 -level:v 3.1 -coder:v cavlc -an -sn vaapitest3-intermediate.h264; ffmpeg-git -i vaapitest3-intermediate.h264 -t 60 -i pony.mkv -map 0:0 -map 1:1 -vcodec copy -movflags +faststart -c:a aac -ab 128k -ar 48000 -ac 2 -sn vaapitest3.mp4

ffmpeg said this:
"[mp4 @ 0x55a35c67acc0] Timestamps are unset in a packet for stream 0 (the video stream created by mesa-git vaapi). This is deprecated and will stop working in the future. Fix your code to set the timestamps properly"

^^^ 
Is this our problem?


This above creates an A/V file that is still broken. We let ffmpeg mux stream to a container after it is created to see if it was a container problem.

Another test:
ffmpeg-git -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -hwaccel_output_format vaapi -ss 120 -t 10 -i rep-mylittleponythemovie.2017.1080p.bluray.x264.mkv -vf scale_vaapi=w=1366:h=768 -c:v h264_vaapi -b:v 2000k -qp 20 -bf 0 -profile:v constrained_baseline -quality:v 0 -level:v 3.1 -coder:v cavlc -an vaapitest5-intermediate.h264; ffmpeg -i vaapitest5-intermediate.h264 -c:v copy vaapitest5.mp4 

creates a file that is playable by gstreamer with no audio.

Now I've tested vaapitest[2,3,5].mp4 on a hardware player. The results are presently surprising for me. I've found a workaround for what I set out to achieve - to hardware encode for a tv with a usb socket. Now to set up a usb gadget mode on the router ;)

vaapitest2.mp4 (the mega.nz shared file) doesn't play on hardware player ""not supported" or gstreamer/totem.
vappitest3.mp4 (plays on the hardware player! but not gstreamer!)
vaapitest5.mp4 (plays on both, but hardware player prints warning about only one stream the whole time it's playing - no audio)
All 3 are playable my ffmpeg / chromium.

I suggest the devs look into how timestamps are handled by the h264 stream and please keep up the good work towards getting h265 working!

This may also be a possible thing to check:
"<jkqxz> The Mesa VAAPI implementation doesn't support packed headers, so you end up with no extradata in the file if you mux directly to mp4 or other format with global headers."

Please leave the ticket open. There is still something broken here, but this explains why this slipped through functional testing.

I have a haswell with integrated graphics so I will repeat the tests using intel's vaapi implementation with the same encoding settings to see if the intel vaapi encoded streams are broken too in the coming days.

Final note before I wash my hands of this matter and leave it to the devs to fix.

I also just tried this with the new main / high profile options and cabac enabled that is now available in the more bleeding edge amd kernels / mesa / libva / ffmpeg. 

The breakage on the hardware player and gstermer qtdemux still applies. 

new h265 vaapi support is dangerous too.
https://bugs.freedesktop.org/show_bug.cgi?id=103953#c7

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1306.