After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 766514 - androidmedia: Reverse Play
androidmedia: Reverse Play
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.8.1
Other other
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-05-16 13:40 UTC by Andy Devar
Modified: 2018-11-03 13:51 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Log 640 GOP 1 androidmedia (107.99 KB, text/plain)
2016-05-16 14:30 UTC, Andy Devar
Details

Description Andy Devar 2016-05-16 13:40:47 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
Comment 1 Andy Devar 2016-05-16 14:30:42 UTC
Created attachment 327982 [details]
Log 640 GOP 1 androidmedia
Comment 2 Andy Devar 2016-05-16 14:45:13 UTC
ffmpeg -i "The Simpsons Movie - 1080p Trailer.mp4" -g 1 -vf "scale=640:266" "The Simpsons Movie - 1080p Trailer_GOP0001_640.mp4"
Comment 3 Andy Devar 2016-07-16 15:03:46 UTC
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?
Comment 4 Sebastian Dröge (slomo) 2016-07-25 06:22:34 UTC
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.
Comment 5 GStreamer system administrator 2018-11-03 13:51:32 UTC
-- 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.