GNOME Bugzilla – Bug 766514
androidmedia: Reverse Play
Last modified: 2018-11-03 13:51:32 UTC
Reverse play (negative rates) do not work with androidmedia. Application: https://cgit.freedesktop.org/~slomo/gst-sdk-tutorials/tree/gst-sdk/tutorials/android-tutorial-5 To change to reverse direction, I added the following code: /* Send seek event to change rate */ static void send_seek_event (CustomData *data) { gint64 position; GstEvent *seek_event; /* Obtain the current position, needed for the seek event */ if (!gst_element_query_position (data->pipeline, GST_FORMAT_TIME, &position)) { GST_DEBUG ("Unable to retrieve current position.\n"); return; } /* Get video sink */ if (data->video_sink == NULL) { // If we have not done so, obtain the sink through which we will send the seek events g_object_get (data->pipeline, "video-sink", &data->video_sink, NULL); } /* Create the seek event */ if (data->rate > 0) { gst_element_seek(data->video_sink, data->rate, GST_FORMAT_TIME, GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_ACCURATE, GST_SEEK_TYPE_SET, position, GST_SEEK_TYPE_NONE, 0); } else { gst_element_seek(data->video_sink, data->rate, GST_FORMAT_TIME, GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_ACCURATE | GST_SEEK_FLAG_TRICKMODE_KEY_UNITS | GST_SEEK_FLAG_TRICKMODE_NO_AUDIO, GST_SEEK_TYPE_SET, 0, GST_SEEK_TYPE_SET, position); } GST_DEBUG ("Current rate: %g\n", data->rate); } static void gst_native_change_direction (JNIEnv* env, jobject thiz) { CustomData *data = GET_CUSTOM_DATA (env, thiz, custom_data_field_id); if (!data) return; data->rate *= -1.0; send_seek_event (data); } As in the original tutorial-5, I use playbin: data->pipeline = gst_parse_launch("playbin", &error); Results: 1. With androidmedia: a) Forward play (rate=1): Videos play smoothly (tried up to 1980x800) regardless of GOP size. b) Reverse play (rate=-1): A new frame is displayed only every few seconds. Eventually, video stops to play. Same behavior regardless of resolution (even with 320x132) and GOP size (tried dynamic, 5 and 1). CPU utilisation is no higher than with forward play, so I assume hardware acceleration is also used with reverse play. 2. Without androidmedia (commented out in plugins.mk): (just for comparison - meets my expectation) a) Forward play (rate=1): 1280x532, dynamic GOP size: Smooth 1280x532, GOP size 1: Smooth 640x266, dynamic GOP size: Smooth 640x266, GOP size 1: Smooth b) Reverse play (rate=-1): 1280x532, dynamic GOP size: Choppy 1280x532, GOP size 1: Choppy 640x266, GOP size 1: Smooth 640x266, dynamic GOP size: Choppy The video I used can be downloaded here: http://www.dvdloc8.com/clip.php?movieid=12167&clipid=3 To create other resolutions/GOP sizes, I used FFMPEG. Example (GOP size 1, resolution 640x266): ffmpeg -i "The Simpsons Movie - 1080p Trailer.mp4" -g 1 scale=640:266 "The Simpsons Movie - 1080p Trailer_GOP0001_640.mp4" Hardware: Lenovo Tab2 A10/30 Qualcomm APQ8009 Android 5.1.1
Created attachment 327982 [details] Log 640 GOP 1 androidmedia
ffmpeg -i "The Simpsons Movie - 1080p Trailer.mp4" -g 1 -vf "scale=640:266" "The Simpsons Movie - 1080p Trailer_GOP0001_640.mp4"
Could you please provide some information on whether reverse play is (or will be) supported on android devices with hardware acceleration enabled - at least for small GOP sizes? Does this depend on - the specific hardware? - the container format? - the video-sink?
It's all 3: a) hardware specific because it requires the decoder to 1) be able to decode GOP by GOP independently, 2) have enough buffers available for the whole GOP (see b)) b) video sink specific, because with glimagesink we would directly render hardware buffers (or other GL sinks). If no GL is used, it's more likely to work c) container format specific, because reverse playback is not supported by all container formats currently. MP4, Matroska/WebM, AVI and Ogg should be fine, MPEG-TS/PS and FLV not for example.
-- 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/gstreamer/gst-plugins-bad/issues/391.