Problem when coming to the end of "H.264/AVC"-encoded files

[s0600204]

As reported by @Pulecz over on gitter, there appears to be a problem when certain media files - specifically files that contain "H.264 / AVC"-encoded video streams - reach their end whilst playing.

(Such files might have a .mp4 or .mkv file extension, but these file types are not limited to H.264 / AVC encoding. The exact encoding of a file can be seen by opening it in LiSP, right-clicking on the cue, and selecting the "Media Info" option.)

To Reproduce

1. Determine whether you have the GStreamer vaapi plugin installed.
   • (On ArchLinux this is in the gstreamer-vaapi package.)
   • (https://gstreamer.freedesktop.org/documentation/vaapi/index.html)
2. Acquire a file with a H.264 / AVC-encoded video stream.
   • (If using the youtube-dl application: choose an option with mp4_dash container, avc1[...] format, and don't forget an audio stream so you can "hear" when the file ends. (And pick something in the public domain so you don't commit a copyright violation.))
3. Load and play the file within LiSP.
4. Skip to near the end, and let the file finish playing.

Expected behavior
The media file to end cleanly, and without error; ideally both with and without GStreamer's vaapi plugin installed.

Actual behaviour
The behaviour exhibited differs depending on whether you are running 0.5.3 or 0.6, and whether you have the GStreamer vaapi plugin installed:

• 0.5.3
  • vaapi not installed: File ends cleanly, no error raised
  • vaapi is installed: File ends, and an error is raised
• 0.6
  • vaapi not installed: File abruptly stops playing a couple of seconds before end of file, no error raised
  • vaapi is installed: File ends cleanly, no error raised

Linux Show Player version

• 0.5.3 (d19da9c)
• 0.6 (8150a48)

OS Version

• ArchLinux

Conclusion
The obvious answer to this is to not play video files within LiSP. However, this might need resolving if LiSP is to support video playback "properly" (#3).

I've also tried media files with video encoded with AV1 (.mp4 or .mkv), MPEG-4 (.avi), and VP9 (.webm), and these appear to play - and end - perfectly fine; so alternatively: if one must play video files, don't use H.264/AVC encoding.

Additional context
It may be worth noting that the type of message passed (to gst_backend/gst_media::__on_message() when a H.264/AVC-encoded file ends differ depending on version of LiSP:

• 0.5.3
  • vaapi not installed: GstPipeline emits Gst.MessageType.GST_MESSAGE_EOS
  • (vaapi is installed: GstQueue emits Gst.MessageType.GST_MESSAGE_ERROR)
• 0.6
  • vaapi not installed: GstPipeline emits Gst.MessageType.GST_MESSAGE_SEGMENT_DONE
  • vaapi is installed: GstPipeline emits Gst.MessageType.GST_MESSAGE_SEGMENT_DONE

I'm not too sure why the on-file-end message from the active GstPipeline object changes between LiSP versions. If there's some part of LiSP that sets or affects this, I haven't found/noticed it yet.

---

I have not tried testing what happens if the file is looped.

I have not tried files encoded with other codecs supported by the GStreamer vaapi plugin (H.265, MPEG-2, VC1).

[FrancescoCeruti]

The difference in behavior when vaapi is due to GStreamer choosing (when available) the decoders form there (hardware acceleration).

When providing a sink for the video, no error is reported, for example: gst-launch-1.0 uridecodebin uri="<your file uri here>" name=decoder decoder. ! queue ! audioconvert ! autoaudiosink decoder. ! videoconvert ! fakevideosink, so I guess that if we add video playback it will be ok.

The difference in the messages between the two versions is due to "segment seeking", which allows seamless looping (see here), for some reason, this also prevents the error seen before.

In the 0.6 (dev) version, the media is stopped because the pipeline send a SEGMENT_DONE message when it shouldn't, this is probably also related to not having a video sink