How to use the --loop function

[Nobeernogman]

When i use the --loop function. It will play my video 1 time. I see on the OSD 00:00:00. But it wont play the file again. Is this my own mistake?

command: omxplayer --loop videofile.mp4

mp4 file specs: http://www.codedump.be/code/1449/

[popcornmix]

What does "omxplayer --version" report?

[Nobeernogman]

omxplayer --version omxplayer - Commandline multimedia player for the Raspberry Pi Build date: Sat, 22 Mar 2014 20:58:15 +0000 Version : 39e6342 [master] Repository: https://github.com/popcornmix/omxplayer.git

Running on my raspberry pi with image: 2014-01-07-wheezy-raspbian.

[popcornmix]

I just tried it and it worked. There is a newer build here: http://omxplayer.sconde.net/

Can you try different files? There may be a problem with that specific file.

[Nobeernogman]

Strange. I will see how to install the newest build.

This is my test file (5mb) please can you try it? https://copy.com/0wc82JbO1KKqncqY And i made a small clip how it looks like on my tv: https://copy.com/lhAwVQSvtGNBsiwQ

Even the clip i just made, wont play for the second time.

Edit: How to install a newer build on my pi? See only .deb files.

Edit2: Found out, that i am not the only one with this problem: http://www.raspberrypi.org/forums/viewtopic.php?p=529706#p529706

[exidyboy]

On 06/04/2014, at 3:07 AM, popcornmix wrote:

I just tried it and it worked.

It worked with 39e6342 for you ? as it doesn't for me - I get the same
error as Nobeernogman There is a newer build here: http://omxplayer.sconde.net/

I updated to 1ca2f7a from http://omxplayer.sconde.net/ 5 minutes ago

• I get the same error Can you try different files? There may be a problem with that
  specific file.

Here is a test file that doesn't work for me. www.michaelborthwick.com.au/thelab/paris2.mp4

Thanks,

Mike

[Nobeernogman]

It looks like i am not the only one. Maybe it's the combination Omxplayer/Raspberry pi?

[exidyboy]

@ Nobeernogman Not sure what you mean by this old boy "Maybe it's the combination Omxplayer/Raspberry pi" - we need information not speculation ;-)

The ---loop function was committed as 6ef31ad on 06 March 2014

I have tested every version since then with the following results.

9b0793f 09 March 2014 - works 4adb5c0 13 March 2014 - works 7fb5ef0 15 March 2014 - works d37454c 18 March 2014 - works 39e6342 22 March 2014 - fails as per Nobeernogman symptom above

Hope that helps the coders ... should we be opening an issue against #150 no ?

Cheers,

Mike

[Nobeernogman]

Installed d37454c, loop function works.But not as it should be.

1st time playing video/sound. 2nd time only video and no sound. 3th loop time only audio and no stuck video. 4th loop only video. Every time exact the same

---

Build date: 09/03/2014 18:20 UTC Git version: 9b0793f Works flawless, like it should be. Video/Sound 100%! But i see the terminal screen for about 1 second between loops.

[robert1356]

I see the same failure using 39e6342 - it plays fine the first time, but fails on loop. The video goes away and I get terminal display, but omxplayer has not exited.

I also noticed that on first play, if I hit pause (space or P) sometimes the video will go away until I hit play, instead of just pausing. If I hit pause again, it will pause as expected. I'm not sure if these might be related, only because the symptoms appear similar (video disappears, OSD appears, terminal output appears)

[popcornmix]

I've pushed a fix for initial loop failing (the EOF condition was persisting on second loop). Can you try that?

@Nobeernogman using the "-b" option will probably hide the terminal appearing on loop.

[Nobeernogman]

@popcornmix Will try that.

What's the quickest way to install the initial loop fix? I installed 9b0793f from http://omxplayer.sconde.net/

[exidyboy]

@popcornmix thank for looking at this. I will need to wait for an updated binary from @skgsergio to test your fix.

[magdesign]

Just built 46616c5. Looping does indeed work now. But after some time it fails with:

Video codec omx-h264 width 1280 height 720 profile 100 fps 25.000000
V:PortSettingsChanged: 1280x720@25.00 interlace:0 deinterlace:0 par:1.00 layer:0
Seek to: 00:00:44
Video codec omx-h264 width 1280 height 720 profile 100 fps 25.000000
V:PortSettingsChanged: 1280x720@25.00 interlace:0 deinterlace:0 par:1.00 layer:0
Seek to: 00:00:47
Video codec omx-h264 width 1280 height 720 profile 100 fps 25.000000
V:PortSettingsChanged: 1280x720@25.00 interlace:0 deinterlace:0 par:1.00 layer:0
Seek to: 00:00:51
Video codec omx-h264 width 1280 height 720 profile 100 fps 25.000000
V:PortSettingsChanged: 1280x720@25.00 interlace:0 deinterlace:0 par:1.00 layer:0
Seek to: 00:00:00
omxplayer.bin: OMXCore.cpp:872: OMX_ERRORTYPE COMXCoreComponent::FreeOutputBuffers(): Assertion `m_omx_output_buffers.size() == m_omx_output_available.size()' failed.
/usr/bin/omxplayer: line 67:  2353 Aborted                 LD_LIBRARY_PATH="$OMXPLAYER_LIBS${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}" $OMXPLAYER_BIN "$@"

[exidyboy]

Good work on compiling from scratch ! Your results are interesting. It is seeking to places other than 00:00:00 - how long does that take to start happening? I have been testing this file www.michaelborthwick.com.au/thelab/paris2.mp4 in a continuous loop since I discovered on April 07 that it was the last good version.

I do note however that the first few seconds of my clip are never played and it terminates a second early. When 46616c5 was working for you @magdesign was it playing the clip in its entirety?

[exidyboy]

@magdesign I managed to compile myself today from scratch on the pi but @skgsergio has had a build with this fix on this site since 09 April ;-) I will look for your bug.

$ omxplayer --version omxplayer - Commandline multimedia player for the Raspberry Pi Build date: Fri, 18 Apr 2014 19:45:56 +1000 Version : 46616c5 [master] Repository: https://github.com/popcornmix/omxplayer.git

The test files now loop 'forever' - not just once - so thanks @popcornmix
(Still doesn't seem to play the very start and end though but I'll prepare some test media with burnt-in timecode to enable better testing).

[exidyboy]

@magdesign I confirm your buffer error. Unfortunately it does not crash consistently. I this received the same error as you on the 18th loop of my 10 sec test file using 6616c5 [master] :

omxplayer.bin: OMXCore.cpp:872: OMX_ERRORTYPE COMXCoreComponent::FreeOutputBuffers(): Assertion `m_omx_output_buffers.size() == m_omx_output_available.size()' failed. /usr/bin/omxplayer: line 67: 2421 Aborted LD_LIBRARY_PATH="$OMXPLAYER_LIBS${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}" $OMXPLAYER_BIN "$@"

however in my current test I am at over 100 loops with no problem ...

[tlemmons]

HI, I have been monitoring your efforts here for some time and wish to say thanks for the work. I have an issue using the Version 46616c5 [master]. I am playing the video http://www.nasa.gov/downloadable/videos/dark_lift-off.mp4 with the command line: omxplayer --loop --no-osd -b --orientation 90 --win "0 0 1920 1080" dark_lift-off.mp4. It plays well except when it goes to loop there is a long pause (10-15 seconds) and then a blank screen before it loops. The video file is on the local SD card. I have also tried with a different video: http://s3.amazonaws.com/akamai.netstorage/HD_downloads/earth_night_rotate_1080.mov and I get the same thing. Can you tell me if I have something setup wrong or what I can change. My intent is to try and play these in a true loop with no breaks. Thanks alot in advance!!

Edit: Playing the second file (earth_night) more it appears that it just crashes the system in a way that kills the SSH console and leaves an omxplayer process in the background with the final frame of the video showing on the monitor. If I re-login to my shell and run omxplayer again it forces the monitor into powersave mode. BTW I am running as root, if that makes a difference.

[exidyboy]

After 6 weeks of testing 46616c5 I have had several successful runs of looping a 60 sec clip for over 4 days however the log file grows to >700MB and the mmc daemon sucks up all the CPU ;-) A more abbreviated logging function might be useful.

I have also seen the@magdesign bug reported on April 10 with build 46616c5 again:

omxplayer.bin: OMXCore.cpp:872: OMX_ERRORTYPE COMXCoreComponent::FreeOutputBuffers(): Assertion `m_omx_output_buffers.size() == m_omx_output_available.size()' failed. /usr/bin/omxplayer: line 67: 2421 Aborted LD_LIBRARY_PATH="$OMXPLAYER_LIBS${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}" $OMXPLAYER_BIN "$@"

but I have not been able to trap it in a log. When it does happen it happens reasonably quickly ie less than 100 loops. However I cannot duplicate it reliably. I was working on a theory that it occurred if the HDMI cable was disconnected. I need to do this as I am logging into multiple pi's and starting them with a monitor connected to verify playback then connecting the monitor to the next one as I don't have an HDMI switcher yet.

Just throwing it out there but I don't suppose using the logging switch could in and of itself be preventing the buffer error I am trying to trap ?

A google search on the error finds a closed discussion on the supposedly deprecated (and yet strangely still rather active) huceke branch of omxplayer: https://github.com/huceke/omxplayer/issues/214

Interestingly (to me) that user @SleepyBrett was using a bash script whereas I am testing with the --loop switch and we get the same error.

Is there anything more I can contribute to this endeavour ?

Mike

P.S. On a note unrelated to the error I have created a 7 minute 1.2GB 1080p25 MPEG-4 file that loops once nicely and then causes omxplayer to eat up over 90% of the CPU and grind to a halt. If anyone technical wants to play with it and I can make it available somewhere.

[exidyboy]

Latest test today. This time with a 1080p file. Crashed on the fourth loop.

pi@nikepi3 ~ $ omxplayer --loop ashmore.mp4 Video codec omx-h264 width 1920 height 1080 profile 77 fps 25.000000 Subtitle count: 0, state: off, index: 1, delay: 0 V:PortSettingsChanged: 1920x1080@25.00 interlace:0 deinterlace:0 par:1.00 layer:0 Seek to: 00:00:00 Video codec omx-h264 width 1920 height 1080 profile 77 fps 25.000000 V:PortSettingsChanged: 1920x1080@25.00 interlace:0 deinterlace:0 par:1.00 layer:0 Seek to: 00:00:00 Video codec omx-h264 width 1920 height 1080 profile 77 fps 25.000000 V:PortSettingsChanged: 1920x1080@25.00 interlace:0 deinterlace:0 par:1.00 layer:0 Seek to: 00:00:00 Video codec omx-h264 width 1920 height 1080 profile 77 fps 25.000000 V:PortSettingsChanged: 1920x1080@25.00 interlace:0 deinterlace:0 par:1.00 layer:0 Seek to: 00:00:00 omxplayer.bin: OMXCore.cpp:872: OMX_ERRORTYPE COMXCoreComponent::FreeOutputBuffers(): Assertion `m_omx_output_buffers.size() == m_omx_output_available.size()' failed. /usr/bin/omxplayer: line 67: 2327 Aborted LD_LIBRARY_PATH="$OMXPLAYER_LIBS${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}" $OMXPLAYER_BIN "$@"

[exidyboy]

I have been able to generate this error with logging enabled and have therefore opened as a new issue here: https://github.com/popcornmix/omxplayer/issues/211

[jehutting]

The looping of a movie is done/triggered in omxplayer main loop by

      if (m_loop)
      {
        m_incr = m_loop_from - (m_av_clock->OMXMediaTime() ? m_av_clock->OMXMediaTime() / DVD_TIME_BASE : last_seek_pos);
        continue;
      }

_continue goes to the while(!m_stop) and the m_incr triggers the seeking, the closing and (re-)opening of the OMXPlayerVideo._

First, the above if(m_loop).. should be placed below the code

      if ( (m_has_video && !m_player_video.IsEOS()) ||
           (m_has_audio && !m_player_audio.IsEOS()) )
      {
        OMXClock::OMXSleep(10);
        continue;
      }

You need not only to wait for the EOF (End-Of-File; the movie is fully read) and video/audio to be cached (all read packets are send to the "OpenMax layer" but also have to wait for the movie to be completely handled (shown) by the (OpenMax) audio & video_decoder (End-Of-Stream reported back)!

Still, small movies are troublesome. You can see it by your own with KenT2 1sec and 5 sec movie from issue 124. The 1 sec is only shown once, seek message is shown, and the screen just stays black. The 5 sec movie is seeked to almost the half of the movie. So every next loop you get half of the movie.

Closing and opening the OMXPlayerVideo tears down and rebuilds the "OpenMax video layer". This causes the black or (console background) part of the looping. Doing looping this way one will never ever get seamless looping.

@exidyboy: I looked to the looping cube example (hello_video_cube; hello_video standard isn't internally looping [issue 211] ). The seamless seeking is done by simply rewinding the reading of the file (/movie). (file pointer is indeed 'seeked' to the 0) Also, the OpenMAX video decoder is kept alive; so no blanks in between. Would be interesting to see if this could work in omxplayer. Someone already doing/done this?

[exidyboy]

Yes that method went in at https://github.com/popcornmix/omxplayer/pull/150 Not sure how it compares architecturally with @bendenoz https://github.com/bendenoz/omxplayer/commit/8fc27e554edfe4167c7fd330ec6f32cd88dd088c https://github.com/huceke/omxplayer/issues/16 or @stewiem2000 https://github.com/stewiem2000/omxplayer

Have had hello_video.c looping video on a Raspberry Pi for 7 days now - very stable. Going through the comments here: http://www.raspberrypi.org/forums/viewtopic.php?f=67&t=19538 and here: http://www.raspberrypi.org/forums/viewtopic.php?f=38&t=8042 where the technique was introduced there are requests for this approach to extended to audio but nothing definitive from an expert on whether or not it is realistic.

[jehutting]

So @exidyboy you changed the hello_video example :))

Didn't realized the looping stuff is so badly needed. Thanks for the info.

[krutkowski]

Does the newest version (0be4eec) support multiple files loop? I tried: omxplayer --loop video1.mov video2.mov and it didn't work for me...

[popcornmix]

@krutkowski Nope, the --loop option makes a single file loop. There is no support in omxplayer for handling more than one filename.

[ralphtheninja]

So, what was the outcome of this thread? Should I just build it on latest master to get --loop working?

[popcornmix]

Building from master should work, or installing a deb from here http://omxplayer.sconde.net/

[ralphtheninja]

@popcornmix Cool. Thanks!

[leojrfs]

i can confirm that with the latest build (18f051d) the --loop only plays once then on the log it says it is jumping to 00:00 time but it doesn't display anything

[exidyboy]

Hi Leo,

I just built from 18f051d source on the Pi and www.michaelborthwick.com.au/thelab/paris2.mp4 loops more than once for me ...

[leojrfs]

@exidyboy hi, with that video it worked well, im using this video and it behaves like i mentioned above. I just converted it to .mp4 container, and it does play well, but at around 3rd loop it just stops with and displays the last frame:

ive also tested this file and it plays until ~25 secs (when it should finish at 33) and then just seeks to 00 like normal. So, with this file, it does loop without stoping, but it does not play until the end.

[exidyboy]

Hi Leo,

Thanks for the test files. I noticed that the MPEG-4 seems slightly more reliable than the MOV across 6 launches of each but I am not sure the difference is statistically significant without a larger sample (results in the table at the end of this comment).

However in testing your clips I discovered something very interesting about erratic looping behaviour in OMXplayer which is that the --loop command is reliable against both your testvideo.mp4 and testvideo.mov and my paris2.mp4 (see https://github.com/popcornmix/omxplayer/issues/211#issuecomment-45406066 ) when OMXplayer is run from a tty but not from a pseudo terminal (ie via ssh).

I also observed that it is reliable running from a pseudo terminal when logging is turned on via the --genlog switch ie

omxplayer --loop --no-osd --genlog testvideo.mov

My unhelpful speculation as a non-programmer is that there is something that happens differently during the teardown and startup of OMXplayer between loops that is different when it is launched from a tty versus a pty. Maybe simply outputting the text:

Seek to: 00:00:00

to the pty at the start of a new loop is causing the freeze and that simultaneously logging to the local SD card slows 'something' down enough to change a timing relationship that avoids the freeze on Seek to: 00:00:00.

It looks from your photo that you are running OMXplayer via a remote terminal ? What happens if you plug in a keyboard and try the same thing? What happens if you turn on logging with the --genlog switch and launch via ssh?

Summary of my tests of your two clips (via ssh)

Leo's file	Res	Profile	Level	CABAC	Ref Frames	Loops until freeze on seek to 00:00:00 (via SSH)
testvideo.mov	1920x1080	Main	4	N	2	1, 2, 2, 2, 3, 1
testvideo.mp4	1920x1080	Main	4	Y	4	3, 3, 1, 2, 3, 2

[leojrfs]

with "--loop --no-osd --genlog" it seems to be looping longer (~10 loops) and each loop doesnt play ultil the end.

[jehutting]

Unlike @exidyboy (see issue #211) I have run paris.mp4 for countless hours to get OMXPlayer to freeze. I only got it once :( with the same effect as @leojrfs described above: OMXPlayer seeks to the beginning of the movie but it only messages 'Seek to: 00:00:00' and freezes by showing the frame on which it started the seek. I simply couldn't figure out what could be going on.

But with testvideo.mov I too had it run 2 to up to the max of 5 before OMXPlayer freezes :).

I am really suprised to see what makes OMXPlayer to freeze: pthread_cond_wait in OMXPlayerVideo::Process().

A part of looping videos in OMXPlayer is done by closing and opening OMXPlayerVideo. I debugged that its Close() is called in which a (successful) pthread_cond_broadcast is given and the StopThread() is called. The latter waits for the Process() to be ended (joined) through the if(m_bAbort) break; statements. But for some reason I don't know the pthread_cond_wait isn't aware of the given pthread_cond_broadcast; it simply seems to wait for a condition to continue. And with nobody giving the condition there is a deadlock.

That everything else seems to be in place (with m_bAbort set) to continue the looping, can be viewed with the following hack.

$ git diff OMXPlayerVideo.cpp
diff --git a/OMXPlayerVideo.cpp b/OMXPlayerVideo.cpp
index 7a94243..c9822f9 100644
--- a/OMXPlayerVideo.cpp
+++ b/OMXPlayerVideo.cpp
@@ -215,7 +215,12 @@ void OMXPlayerVideo::Process()
   {
     Lock();
     if(m_packets.empty())
-      pthread_cond_wait(&m_packet_cond, &m_lock);
+    {
+      if(m_bAbort)
+        fprintf(stderr, "***ABORT***\n");
+      else
+        pthread_cond_wait(&m_packet_cond, &m_lock);
+    }
     UnLock();

     if(m_bAbort)

At least it works for me: testvideo.mov is already looping for three hours... Of course, this CAN'T be the solution!!!

By the way, the OMXPlayerVideo has the Lock and Unlock functions, whereas it's base class OMXThread already supply these functions.

[ralphtheninja]

Awesome bug reports guys :clap:

[exidyboy]

@leojrfs looping with the --loop switch has never played the complete file to the end (or from the start) and therefore you need to adding padding to your clip. If this is not practical see the table here for a summary of options https://github.com/popcornmix/omxplayer/issues/211#issuecomment-45406066

If you don't need audio playback the hello_video.c approach is bulletproof.

@jehutting I didn't know you couldn't fail my test clip. @popcornmix reproduced the problem 7 months ago https://github.com/popcornmix/omxplayer/issues/211#issuecomment-47333636 are you running via a tty or pty ?

Mike

[jehutting]

@exidyboy: I ssh to my RPI, so pty.

I also had the runs with popcornmix's fixes for the issues mentioned in #211.

Will re-run to see if it makes a difference when using the tty (console). Can't remember if I already tried that :).

[jehutting]

Ran paris.mp4 with an (24hrs) uptime of almost 11 days from the console without a freeze (looped 27366 times). Just plain omxplayer (so without my above hack :) Still can't find the cause for the pthread_cond_wait to fail.

[exidyboy]

By 11 days via the 'console' you mean the local tty console ie USB keyboard ?

[jehutting]

@exidyboy: yes, with console I meant the tty console (in which you see the RPI power-up sequence) and used an USB keyboard to enter the command.

[exidyboy]

OK thanks. As I wrote at https://github.com/popcornmix/omxplayer/issues/187#issuecomment-72581896 tty is OK. Also, for example, launching via cron.

The problem only occurs over pty - would you be able to confirm this ?

[jehutting]

I can run paris2.mp4 on tty and on pty consoles for hours/days, as I stated already above. Only with leojrfs movie I quickly run into the freezing stuff, able to locate the freeze for that movie. Can you try my hack, just to see if the point of freeze is the same?

[exidyboy]

OK Sorry I didn't scroll back far enough to where you confirmed also testing over pty :-)

I ran these three tests of @leojrfs testvideo.mp4

1. From tty and looped without error overnight 2 From pty and got on average 6 loops then freezes on seek. 3 I hand edited your diff described at https://github.com/popcornmix/omxplayer/issues/187#issuecomment-72740970 into OMXPlayerVideo.cpp and launched omxplayer via pty.

It has been looping continuously for around an hour and I have accumulated about twenty _ABORT_ messages over the pty. So it is changing something for the better. However if I repeat test 2 with --genlog switch that also doesn't freeze either so it is hard to be definitive.

I would like to try debugging with gdb as suggested here by @popcornmix https://github.com/popcornmix/omxplayer/issues/181#issuecomment-42570100 but I can't figure out to edit the makefile to insert the debugging information into the compiled code.

[0-173]

Using https://github.com/jvcleave/ofxOMXPlayer (same codebase) I've encountered the same problem. I just realized that i've done the same debugging as jehutting. I came to the same conclusion of a deadlock in OMXPlayerVideoBase::Process() at pthread_cond_wait(&m_packet_cond, &m_lock).

In my opinion there is a bug in implementation. I'll try to sketch a scenario that leads to a deadlock. Let's have a look at the code:

void OMXPlayerVideo::Process()
{
  OMXPacket *omx_pkt = NULL;
  while(!m_bStop && !m_bAbort)
  {
    Lock();
    if(m_packets.empty())
      pthread_cond_wait(&m_packet_cond, &m_lock);
    UnLock();
    if(m_bAbort)
      break;
...

bool OMXPlayerVideo::Close()
{
  m_bAbort  = true;
  Flush();
  if(ThreadHandle())
  {
    Lock();
    pthread_cond_broadcast(&m_packet_cond);
    UnLock();
    StopThread();
  }

Let's say the main thread is running calling Process() in a loop. m_bAbort is still false. So we enter the while loop. Immediately afterwards (before Lock()) there is a call to Close() from the controlling thread. m_bAbort is set to true and m_packet_cond is broadcasted. But currently no thread is waiting for that message, so it gets lost. Back in our main thread Lock() has finally been called and returns as soon as the mutex is locked. m_packets is empty - so the main thread starts to wait for m_packet_cond. The controlling thread at the same time has called StopThread() and waits for the first thread to stop with pthread_join(). Deadlock.

I know this might be a very rare situation. But my deadlock happens in average on every 10.000th Close() call. And jehutting's patch helps. So I'd say: this might be the solution!

[exidyboy]

Thanks @meliody for your analysis - the best effort yet in untangling the interaction of the various omxplayer threads and their contribution to instability. @tdicola overhauled the looping architecture at https://github.com/popcornmix/omxplayer/pull/322 rendering much of the older research irrelevant. Are you testing against a version that includes his changes?

[popcornmix]

@meliody Can you look at http://paste.ubuntu.com/11767855/ which attempts to address your concern (which sounds plausible to me).

[0-173]

@popcornmix: Thanks for the patch. it works for me. Tested it for 15000 loops. Runs without any deadlock. @exidyboy: Good point, I did not have this fix in my codebase. This does not seem to be implemented in the openFrameworks omxPlayer yet. Besides the deadlock problem which seems to be solved I still have problems with segmentation faults. First I thought of memory leaks or invalid pointers. But these errors decreasy significantly when my raspberry pi is equipped with a better power supply and when I do not overclock it. Nevertheless they still happen. Perhaps it would help not to close and re-open as addressed by #322.

[popcornmix]

@meliody Thanks for testing. Patch is pushed.

Can you use gdb to find the backtrace of the segfaults? If it seems related to overclock and/or power supply, then removing overclock and checking voltage would be strongly advised to avoid wasting time with what may not be a software problem.

[AMSVIEIRA]

Hello Guys,

I use omxplayer on my raspberry pi2 and I am trying to remove the title on the image below when my video is in loop.

Anyone have an idea of how to do it?

[skgsergio]

@AMSVIEIRA --no-osd