I'm using Firefox on Ubuntu Touch (focal), but I've found that I can't copy anything to native apps.
I don't know if it this is limited to Firefox, or if it still happens with a physical keyboard, but it seems to me that the clipboard isn't being shared with the native/host OS. Is this intended behavior and is there a way to workaround it?
I've figure it out that entering 'selection mode' with a long press is precisely what I was looking for.
Would still be useful to somehow start the terminal on selection mode and hide the 'Exit selection mode' option
I'm trying to get ncspot to work within a libertine container, and while everything appears to be functional, touch (pointer) events do not seem to be captured by the program, which sort of defeats the whole point of the terminal interface. The only way to actually navigate the menus is using the built-in arrow keys (or, I assume, an external keyboard) but that's very limiting.
Is it possible, and if so how does one achieve it, to have terminal apps detect touch/pointer events_
I'm trying to add a third-party PPA to a Libertine container (24.04), but running into the error:
Error: must run as root
when I use libertine-container-manager -i noble -a add -n ppa:<...> . Using the Libertine settings UI fails silently (I assume the underlying error is the same).
Going directly into a fakeroot shell doesn't work because of the nature of the container, I can't call add-apt-repository from inside it.
@gpatel-fr thank you for the mkv samples!
this 'Microsoft MPEG-4 4.2' is probably the same thing as your '10 bit support'.
not really, the issue is definitely the bit depth of the video, correlated with the format profile. Higher definition videos such as H.264 AVC "High 10" profile (using mediainfo) :
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : **High 10@L3.1**
Format settings : CABAC / 5 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 5 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 46 s 0 ms
Width : 1 024 pixels
Height : 576 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 24.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : **10 bits**
Scan type : Progressive
Writing library : x264 core 165 r3222 b35605a
Encoding settings : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=8 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=18 / lookahead_threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=18.0 / qcomp=0.60 / qpmin=0 / qpmax=81 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.601 NTSC
Transfer characteristics : BT.709
Matrix coefficients : BT.601
To reproduce this, you can use ffmpeg to enforce a higher bit depth on any of these samples:
ffmpeg -i test5.mkv -c:v libx264 -pix_fmt yuv420p10le -crf 18 -preset slow -c:a copy test5_10bit.mkv
and confirm it does not play on the UT player, despite desktop OSs having no issue playing it (at least that's my experience).
It does, as you suggested, play on (libertine) mpv or vlc, so it seems like a limitation of the default player (I'd open a bug on the app repository, but can't seem to find it for the media player).
Looking into this with a bit more care, the issue seems to be high definition video such as 10-bit H.264, converting to 8-bit seems to allow playback to work. I'm not sure if it's an hardware limitation, because it works on android roms (at least on custom A14).
@floem7 said in Has video/media playback improved?:
mkv plays without problems in default app
a .mkv file is a container format, so the ability of UT mediaplayer to play these files depends on what is exactly the format of media tracks in the file. If the video track is "standard" mp4 or theora or h264 and sound track is mp3 or ogg/vorbis, there will be no problem. If for example the sound is amr or video is 'microsoft' mp4, it will probably not work.
It's not obvious to check on the format of a .mkv file under Ubuntu Touch, it's much easier under a PC running Linux where you can easily install mkvinfo (ffplay or gst-discoverer-1.0 will also be able to interpret the files to some extent).
Indeed none of my .mkv files work. I've tried converting to .mp4 using ffmpeg, but it still doesn't play.
What target (that we're sure it's supported) video and audio format/encoding should I use?
So noone who owns this device can provide any feedback on media playback? I'm planning to reinstall UT anyway, but would rather avoid running into this issue.
@gpatel-fr it was about a year ago, I didn't do extensive testing, but none of the .mkv I tried worked, and .mp4 were very hit-and-miss. Good to know it isn't Hallium-related, perhaps there's hope to fix it on this device.
@Charly the issue w/ that is that, AFAIK, Libertine apps aren't hardware-accelerated, and video playback often gets choppy (it was one of the workarounds I tried). Didn't try the snap version though.
@chromiumos-guy sadly that wasn't my experience last year, it was very hit and miss, and notably .mkv files never worked. I don't know if it's a codec issue, but if it's down to Hallium it's probably still the same in 24.04. Just wanted to check before attempting to install once more.
I've tried Ubuntu Touch on this device in the past, and while the overall experience was good, the dealbreaker was unstable and/or choppy video playback, particularly on .mkv files.
Has this improved recently (particularly on 24.04), or is still a limitation?