agherzan
Support building raspidistro VLC (with mmal)
Because I accidentally deleted my branch pushing picked + squashed commits. Just decided to open another pull request
- https://github.com/agherzan/meta-raspberrypi/pull/981
Core changes from conversation include
ENABLE_RPI_DISTRO_VLC = "1"variable for adding rpidistro-vlc packages into the image- removal of the
LICENSE_FLAGSin the raspidistro-vlc recipe as it is not needed - Cleaned up git history
How I build
add into conf/local.conf. To fix mesa-gl issue https://github.com/agherzan/meta-raspberrypi/issues/987#issuecomment-1020306027
MACHINE = "raspberrypi4"
LICENSE_FLAGS_WHITELIST = "commercial"
ENABLE_UART = "1"
DISABLE_VC4GRAPHICS = "1"
ENABLE_RPI_DISTRO_VLC = "1"
EXTRA_IMAGE_FEATURES:append = " ssh-server-openssh empty-root-password allow-root-login"
@kraj
Mainly for patch compatibility. I figured if oe-core provided version of ffmpeg changes versions we'd have to update patches accordingly each time. Why I'd rather have a custom recipe with specified commit/tag.
Haven't tried to see if I can get patches applied to oe-core ffmpeg. Thinking that one may need to generate new similar patches that work with oe-core version of ffmpeg.
@EasyIP2023 Sorry for the delay. The obvious issue here is maintenance. I won't be able to maintain 70k+ worth of lines in patches from now on. I assume that all the patches are identically pulled from the RPI deb package. This along with duplication are probably the things @kraj is pointing at. @EasyIP2023 , are you up for maintaining these recipes?
Also, I'm wondering if it's worth adding yet another magic variable and not documenting the provider switch which you can do in your configuration. We are basically trading two lines for one but also introducing yet another variable. I'd also let the user include it in the image of their choice.
Hey @agherzan,
Yes, the majority of the patches are identically pulled from:
- rpidistro-ffmpeg: https://github.com/RPi-Distro/ffmpeg/tree/pios/bullseye/debian/patches
- rpidistro-vlc: https://github.com/RPi-Distro/vlc/tree/buster-rpt/debian/patches
- meta-openembedded/vlc: https://github.com/openembedded/meta-openembedded/tree/master/meta-multimedia/recipes-multimedia/vlc/vlc
I am willing to maintain how patches are applied in the recipes and the couple of patches I added myself. Removing ENABLE_RPI_DISTRO_VLC and not use CORE_IMAGE_EXTRA_INSTALL is fine with me. Should I go ahead and remove it?
@agherzan I think we need to get vlc going for rpi, since upstream omxplayer is deprecated in favor of vlc and omxplayer no longer builds with latest yocto master. Perhaps we should just call the vlc recipe to not conflict with main vlc recipe and let it PROVIDE vlc instead so distros can make a choice which one to use with PREFERRRED_PROVIDER
@kraj Right. Makes sense. I would also just drop omxplayer at that point.
Also, yes, technically the PREFERRRED_PROVIDER approach I'd like to go for. And this MR already does that but I'd simplify it a bit and just use it directly as opposed to indirected variables.
Hey, @agherzan @kraj
Went a head and removed the ENABLE_RPI_DISTRO_VLC and CORE_IMAGE_EXTRA_INSTALL variables. So users can add VLC themselves with ability to select ffmpeg version.
@EasyIP2023 Are you still up for refreshing this? I think we are now in good shape to start merging this support as omxplayer has been officially deprecated.
@agherzan okay just push changes checking to make sure I can still build and run VLC
@agherzan @kraj bellow are results/commands I used to due a few test.
WORKING
root@raspberrypi4:~# vlc -H | grep mmal
VLC media player 3.0.12 Vetinari (revision 1.0.6-1619-gf7fd69f12)
MMAL-based deinterlace filter plugin (mmal_deinterlace)
--mmal-deinterlace-no-qpu, --no-mmal-deinterlace-no-qpu
--mmal-deinterlace-adv, --no-mmal-deinterlace-adv
--mmal-deinterlace-fast, --no-mmal-deinterlace-fast
--mmal-deinterlace-none, --no-mmal-deinterlace-none
--mmal-deinterlace-half-rate, --no-mmal-deinterlace-half-rate
--mmal-deinterlace-full-rate, --no-mmal-deinterlace-full-rate
mmal_vout (mmal_vout)
--mmal-layer <integer> VideoCore layer where the video is displayed.
--mmal-adjust-refreshrate, --no-mmal-adjust-refreshrate
--mmal-native-interlaced, --no-mmal-native-interlaced
--mmal-display <string> Output device for Rpi fullscreen.
--mmal-vout-transform <string>
--mmal-vout-window <string>
--mmal-vout-transparent, --no-mmal-vout-transparent
MMAL-based decoder plugin for Raspberry Pi (mmal_codec)
--mmal-opaque, --no-mmal-opaque
--mmal-resize, --no-mmal-resize
Use mmal resizer rather than hvs.
Use mmal resizer rather than isp. This uses less gpu memory than the
--mmal-isp, --no-mmal-isp Use mmal isp rather than hvs.
Use mmal isp rather than hvs. This may be faster but has no blend.
MMAL buffered avcodec (mmal_avcodec)
--mmal-avcodec-buffers <integer>
--glconv {any,mmal_converter,none}
--glconv {any,mmal_converter,none}
-V, --vout {any,mmal_xsplitter,gl,gles2,xcb_xv,xcb_x11,fb,mmal_vout,vdummy,vdummy,flaschen,yuv,vmem,omxil_vout,none}
DISPLAYNUM=$(tvservice -l | tail -c 2)
MMAL_DISPLAY=$(expr $DISPLAYNUM + 1)
VLC_SETTINGS="-I dummy --vout=mmal_vout --mmal-resize --mmal-display hdmi-$MMAL_DISPLAY --no-dbus
cvlc $VLC_SETTINGS sample_1920x1080.mp4
VLC_SETTINGS="--no-dbus -I dummy --mmal-isp --vout=mmal_vout --mmal-display hdmi-$MMAL_DISPLAY --mmal-avcodec-buffers 3 --mmal-vout-transparent"
cvlc $VLC_SETTINGS sample_1280x720_surfing_with_audio.mkv
VLC_SETTINGS="--no-dbus -I dummy --aspect-ratio 3:4 --mmal-isp --vout=mmal_vout --mmal-display hdmi-$MMAL_DISPLAY --mmal-avcodec-buffers 3 --mmal-vout-transparent"
cvlc $VLC_SETTINGS big_buck_bunny_720p_h264.mov
ffmpeg -i video.mp4 -c:v h264_v4l2m2m -b:v 8M -c:a copy encoded_video.mp4
....
[h264_v4l2m2m @ 0x13e0940] Using device /dev/video11
[h264_v4l2m2m @ 0x13e0940] driver 'bcm2835-codec' on card 'bcm2835-codec-encode' in mplane mode
[h264_v4l2m2m @ 0x13e0940] requesting formats: output=YU12 capture=H264
[h264_v4l2m2m @ 0x13e0940] Failed to set gop size: Invalid argument
Output #0, mp4, to '[h264_v4l2m2m @ 0x13e0940] Using device /dev/video11
[h264_v4l2m2m @ 0x13e0940] driver 'bcm2835-codec' on card 'bcm2835-codec-encode' in mplane mode
[h264_v4l2m2m @ 0x13e0940] requesting formats: output=YU12 capture=H264
[h264_v4l2m2m @ 0x13e0940] Failed to set gop size: Invalid argument
Output #0, mp4, to 'encoded_video.mp4':
....
[h264_v4l2m2m @ 0x13e0940] ff_v4l2_buffer_buf_to_avpkt
[mp4 @ 0x13e0010] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
[mp4 @ 0x13e0010] Encoder did not produce proper pts, making some up.
[h264_v4l2m2m @ 0x13e0940] ff_v4l2_buffer_buf_to_avpkt
Last message repeated 25 times
[h264_v4l2m2m @ 0x13e0940] ff_v4l2_buffer_buf_to_avpkt01.98 bitrate= 0.2kbits/s speed= 3.9x
Last message repeated 37 times
[h264_v4l2m2m @ 0x13e0940] ff_v4l2_buffer_buf_to_avpkt03.52 bitrate=1787.5kbits/s speed=3.46x
Last message repeated 41 times
[h264_v4l2m2m @ 0x13e0940] ff_v4l2_buffer_buf_to_avpkt05.48 bitrate=2295.1kbits/s speed= 3.6x
Last message repeated 41 times
[h264_v4l2m2m @ 0x13e0940] ff_v4l2_buffer_buf_to_avpkt06.99 bitrate=3296.8kbits/s speed=3.44x
Last message repeated 41 times
[h264_v4l2m2m @ 0x13e0940] ff_v4l2_buffer_buf_to_avpkt08.98 bitrate=3736.1kbits/s speed=3.54x .mp4':
....
cvlc $VLC_SETTINGS encoded_video.mp4
root@raspberrypi4:~# ffmpeg -decoders | grep mmal
ffmpeg version 4.3.2 Copyright (c) 2000-2021 the FFmpeg developers
built with gcc 11.3.0 (GCC)
configuration: --cross-prefix=arm-poky-linux-gnueabi- --ld='arm-poky-linux-gnueabi-gcc -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 -fstack-protector-strong ...
libavcodec 58. 91.100 / 58. 91.100
libavformat 58. 45.100 / 58. 45.100
libavdevice 58. 10.100 / 58. 10.100
libavfilter 7. 85.100 / 7. 85.100
libavresample 4. 0. 0 / 4. 0. 0
libswscale 5. 7.100 / 5. 7.100
libswresample 3. 7.100 / 3. 7.100
libpostproc 55. 7.100 / 55. 7.100
V..... h264_mmal h264 (mmal) (codec h264)
V..... mpeg2_mmal mpeg2 (mmal) (codec mpeg2video)
V..... mpeg4_mmal mpeg4 (mmal) (codec mpeg4)
V..... vc1_mmal vc1 (mmal) (codec vc1)
root@raspberrypi4:~# ffmpeg -encoders | grep omx
ffmpeg version 4.3.2 Copyright (c) 2000-2021 the FFmpeg developers
built with gcc 11.3.0 (GCC)
configuration: --cross-prefix=arm-poky-linux-gnueabi- --ld='arm-poky-linux-gnueabi-gcc -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 -fstack-protector-strong ...
libavutil 56. 51.100 / 56. 51.100
libavcodec 58. 91.100 / 58. 91.100
libavformat 58. 45.100 / 58. 45.100
libavdevice 58. 10.100 / 58. 10.100
libavfilter 7. 85.100 / 7. 85.100
libavresample 4. 0. 0 / 4. 0. 0
libswscale 5. 7.100 / 5. 7.100
libswresample 3. 7.100 / 3. 7.100
libpostproc 55. 7.100 / 55. 7.100
V..... h264_omx OpenMAX IL H.264 video encoder (codec h264)
V..... mpeg4_omx OpenMAX IL MPEG-4 video encoder (codec mpeg4)
NOT WORKING
All test to utilize OpenMax encoder have all failed for me. However, OpenMax interface I believe is gone the way of the dodo bird.
$ ffmpeg -c:v h264_mmal -i big_buck_bunny_720p_h264.mov -c:v h264_omx -c:a copy big_buck_bunny_720p_h264.mp4
[h264_mmal @ 0x1780fe0] Did not get output frame from MMAL.
Error while decoding stream #0:0: Unknown error occurred
[h264_mmal @ 0x1780fe0] MMAL error 2 on control port
$ ffmpeg -c:v h264_mmal -i sample_1280x720_surfing_with_audio.mkv -c:v h264_omx -c:a copy sample_1280x720_surfing_with_audio.mp4
Error while decoding stream #0:0: Unknown error occurred
Finishing stream 0:0 without any data written to it.
[h264_omx @ 0xf2ec60] /opt/vc/lib/libbcm_host.so not found
Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height
@EasyIP2023 you have a small typo in the SoB (Signed off by) in one of a commits.
It seems like it breaks the world on "libdvbpsi".
EDIT: It's a bit complicated now. We have introduced the rpi vlc recipe which depends on libdvbpsi from meta-multimedia (so we now depend on this layer). Given that the main vlc recipe is also in meta-multimedia, would it make sense to use a dynamic layer setup to avoid a hard dependency on meta-multimedia? That is a bit unnatural because we will have a dynamic layer for a recipe used as a preferred provider in a machine of this layer. @kraj what do you reckon?
Hey, @agherzan @kraj
I went ahead and added rpidistro-{vlc and ffmpeg} recipes into the dynamic-layers/multimedia-layer folder although ffmpeg is in oe-core and not meta-openembedded/meta-multmedia. I think that's the best possible route as not everyone would want to include all the other layers in their setups for a recipe(s) that they don't include in their images.
PREFERRED_PROVIDER_vlc ?= "rpidistro-vlc"
PREFERRED_PROVIDER_ffmpeg ?= "rpidistro-ffmpeg"
From test keeping above seems to be ignored if associated layers are not present. If meta-openembedded/meta-multmedia isn't included oe-core ffmpeg is used. And of course nothing provides VLC. Vise versus if layers include rpidistro-{vlc,ffmpeg} are utilized.
Won't be able to get back until next week. Should we only include rpidistro-vlc in dynamic-layers or both? As oe-core contains ffmpeg.
@EasyIP2023 aI reckon that works well and I don't see how a better way forward. Let's add only vlc to dynamic layers as ffmpeg is already in our base deps.
Awesome we got this MR merged! Would like commits to land into dunfell, there's however a slight change that needs to be made to rpidistro-vlc recipe at least with OE core(Dunfell 3.1.10) commit hash 9ae339ace9274be71bfd3b5e5da64dceac9fa963.
do_configure:append() {
sed -i -e s:'${top_builddir_slash}libtool':'${top_builddir_slash}'${TARGET_SYS}-libtool:g ${B}/doltlibtool
}
@agherzan @kraj would it be better, on branch dunfell to let a custom layer create bbappend and apply change or just edit the cherry-picked commit and create MR for branch dunfell?
@EasyIP2023 I'm not fully up for backporting this to a stable branch. In theory, there shouldn't be any breakage but it would be against the policy we use as stable. Would it work for you to have it as a mixin layer?
@agherzan okay I'll see what happens when I upgrade my current setup to the latest kirkstone release. Would rather not have to maintain a separate layer for porting recipes to dunfell.