I am using gstreamer to create files for HLS playback using the tx1. What I have noticed is that the files playback in Chrome on Android. However, on iOS only audio is present. There is no video visible on iOS. I suspect that it is an encoding issue.
Can the omxh264enc plugin for gstreamer produce output that is compatible with iOS? If yes, what are the correct parameters to use?
Hi RandDGraham,
Please try to set ‘profile=1’ or ‘profile=2’. If there is still no video visible on iOS, we need you to share the sample file which is playable on iOS so that we can compare/analyze the video bitstream.
In order to test hls on iOS you need a file to start with. This test case is transcoding h.265 to h.264.
You need to run a web server to serve the files (I server the files from the TX1 using python -m SimpleHTTPServer)
You need a wireless router or access point so that your web server and iOS device are on the same network.
The pipeline I showed earlier creates the HLS files in a directory and the files are served via python http server from the same directory.
HLS files consist of a playlist and the segmented TS video files. So all that is needed is to open Safari on iOS (Chrome on Android) and download the playlist file from the web server. The video should begin playing.
Here is an example url of the playlist file in my setup:
Hi Rand,
Thanks for the steps. We will try to reproduce the issue but it probably take some time.
BTW, are you able to do the quick test below?
1 Record a clip via iPhone(or iPad/iPod)
2 Re-mux it into ts
gst-launch-1.0 filesrc location=iOS_sample.MOV ! qtdemux ! h264parse ! mpegtsmux ! filesink location=remux.ts
3 Test HLS
With this the h264 stream is from iOS. Let’s see if it can run well(ideally it has to run well).
Hi Rand,
We have confirmed the issue is due to lack of AU delimiter in the bitstream. Please build libgstomx.so with AU delimiter enabled and give it a try.
Attach the good playlist set we generated for reference. NVIDIA_aud.zip (4.65 MB)
My TX1 does not have a /usr/lib/arm-linux-gnueabihf directory. My TX1 doesn’t have any arm-linux directory under /usr/lib
Also the post mentions needing the 64 bit version of the libraries to build with. For example, the readme says this library is needed
libffi6_3.1~rc1+r3.0.13-12_armhf.deb
So for 64 bit arm I tried the following and the package was not found:
ubuntu@tegra-ubuntu:~/nvidia-src/sources$ sudo apt-get install libffi6_3.1~rc1+r3.0.13-12_arm64.deb
Reading package lists… Done
Building dependency tree
Reading state information… Done
E: Unable to locate package libffi6_3.1~rc1+r3.0.13-12_arm64.deb
E: Couldn’t find any package by glob 'libffi6_3.1~rc1+r3.0.13-12_arm64.deb
Can you provide updated instructions to build the library on a TX1 running 64 bit Ubuntu 16.04?
Note that “arm-linux-gnueabihf” is for 32-bit ARMv7, while a TX1 is 64-bit ARMv8-A. Substitute “aarch64-linux-gnu” (this is present on a JTX1 because aarch64-linux-gnu is 64-bit).
I have this package installed on the JTX1 (I don’t know if this was from the JetPack extra libraries or from one of the other repositories I enabled):
# dpkg --list | egrep -i libffi
ii libffi6:arm64 3.2.1-4 arm64 Foreign Function Interface library runtime
Note that this is package “libffi6”…no versioning is used in the package name so far as 3.2.1-4 goes.
I saw that there was another readme in the gstomx1_src_quick_fix_r24_2_1.zip file. I tried following this readme. But there is still a problem with creating the link. I get the following error when I try to compile.
Yes, libffi-dev without the rest of the versioning or architecture stuff (32-bit armhf versus 64-bit aarch64/arm64) is the correct way to name packages.
You may need to enable repositories via “/etc/apt/sources.list” and “sudo apt update” for some packages to show up…I don’t know which repos make which package available. There are also alternate ways of adding repos other than sources.list (those other means more or less just edit this file or insert content from sources.list.d subdirectory).
So I have the packages installed but I am still having a problem with /usr/lib/arm-linux0gnueabihf
I am not sure what is supposed to create this directory.
I get the following error trying to create a ln as directed in the readme.
sudo ln -s /usr/lib/arm-linux-gnueabihf/libgstnvegl-1.0.so.0 /usr/lib/arm-linux-gnueabihf/libgstnvegl-1.0.so
ln: failed to create symbolic link ‘/usr/lib/arm-linux-gnueabihf/libgstnvegl-1.0.so’: No such file or directory
gstomxh264enc.c:212:34: error: ‘true’ undeclared (first use in this function)
oEncodeProp.bInsertAUD = true;
I am going to use the c convention and go ahead and replace true with the number 1 because anything non zero in C evaluates to true. I will give it a try.
We will resolve it and ensure it being build-able in next release.
Please use the libgstomx.so attached for r24.2.1. It adds the encode property ‘insert-aud’.
command example:
I am now able to playback HLS video on iOS. Thanks.
I still don’t understand what happened to the avdec_aac element. Why does recompiling libgstomx.so eliminate this element? Was it one of the package update commands that pulled down a newer version of gstreamer that removed this element?
If that is the case it would mean the .deb package maintainers removed the element.
According to the release notes for 1.6 avdec is the prefferred over faad. (src: GStreamer 1.6 release notes) I don’t think this changed for 1.8 which is what is installed on the TX1.
Do you agree it was removed by the package maintainers?