Feature request: provide a better info data #118

vpetersson · 2013-02-14T20:55:28Z

Hi guys,

I just wanted to throw in a feature request. I know there's already an option for dumping information from a stream using the i / --info option.

However, it's not very readable nor conveniently parseable.

Currently, it looks something like this:

$ omxplayer -i  http://www.screenlyapp.com/tmp/big_buck_bunny_1080p_h264_trailer.mov
file : http://www.screenlyapp.com/tmp/big_buck_bunny_1080p_h264_trailer.mov result 47 format mov,mp4,m4a,3gp,3g2,mj2 audio streams 1 video streams 1 chapters 0 subtitles 0

have a nice day ;)

Now, it does dump all information that I would like, with the exception of the duration and the audio codec. My request however is to dump it in a more pretty fashion that would enable easier parsing, much like ffprobe.

I'm thinking more something along the lines of a colon separated list:

[...]
duration: X
video_codec: Y
[...]

The reason I want this is to be able to utilize the output in Screenly.

The text was updated successfully, but these errors were encountered:

popcornmix · 2013-02-15T11:59:58Z

Sounds straightforward. A pull request could be useful.
Is anyone else currently parsing the output of "omxplayer -i" who would object to the format being changed?

vpetersson · 2013-02-15T14:35:10Z

My C/C++ kung fu isn't strong enough for the task unfortunately :)

If nobody else is able to take care of this, I might be able to put one of our guys on this down the road.

By the way, if we could add another flag for JSON-output, it would make it even easier to parse and make it even more awesome.

KenT2 · 2013-02-15T20:40:10Z

Johannes Baiter has done some decoding of the current information here if it helps:

https://github.com/jbaiter/pyomxplayer/blob/master/pyomxplayer.py

The decoding fails if the track content is not straightforward..

I use the status in Pi Presents and TBOplayer but am happy to modify them. I would welcome some better handshaking messages, for example messages when Omxplayer starts playing, when it finishes naturally and when it finishes due to a quit etc.

vpetersson · 2013-02-17T11:17:31Z

I would welcome some better handshaking messages, for example messages
when Omxplayer starts playing, when it finishes naturally and when it finishes due to a quit etc.

+1. That would be very helpful for Screenly too.

hinxx · 2013-02-20T10:22:02Z

I can give it a stab.

Do you have a desired output "mock up" maybe.. or will it be enough to print out the current information split into several lines instead of just one?

popcornmix · 2013-02-20T11:35:25Z

@hinxx
I'd request it is kept human readable. I don't believe splitting into multiple lines makes parsing significantly easier.

ffmpeg/ffprobe output looks like

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/Shared/trailer_480p.mov':
  Metadata:
    major_brand     : qt  
    minor_version   : 537199360
    compatible_brands: qt  
    creation_time   : 2008-03-18 12:44:52
  Duration: 00:00:33.00, start: 0.000000, bitrate: 2681 kb/s
    Stream #0.0(eng): Video: h264 (Main), yuv420p, 854x480, 2282 kb/s, 25 fps, 25 tbr, 600 tbn, 1200 tbc
    Metadata:
      creation_time   : 2008-03-18 12:44:52
    Stream #0.1(eng): Audio: aac, 48000 Hz, 5.1, s16, 428 kb/s
    Metadata:
      creation_time   : 2008-03-18 12:44:52

Not sure the creation_time lines are useful, but the duration and Stream#n seem useful.

hinxx · 2013-02-23T02:54:55Z

I have crafted something like this, ideas taken from ffprobe, a teaser:

pi@raspberrypi ~/omxplayer $ ./omxplayer -i /home/pi/pihome/Youtube/.Chimaira_-_Six__Studio_-video/Chimaira_-_Six__Studio_.flv 
file : /home/pi/pihome/Youtube/.Chimaira_-_Six__Studio_-video/Chimaira_-_Six__Studio_.flv result 99 format flv audio streams 1 video streams 1 chapters 0 subtitles 0 length 585
filename         : /home/pi/pihome/Youtube/.Chimaira_-_Six__Studio_-video/Chimaira_-_Six__Studio_.flv
nb_streams       : 2
video_streams    : 1
audio_streams    : 1
nb_chapters      : 0
nb_chapters      : 0
nb_subtitles     : 0
format_name      : flv
format_long_name : FLV (Flash Video)
start_time       : 0
duration         : 585
bytelength       : 68318892
bit_rate         : 934275

have a nice day ;)
pi@raspberrypi ~/omxplayer $

vpetersson · 2013-02-23T10:31:07Z

Looks good to me. I assume the duration is in seconds?
Ffmpeg displays it differently, which is more readable.

Anyways, either way works for me when I parse it, but I think the ffmpeg one is more useful.

hinxx · 2013-02-23T11:44:56Z

Yes, I think duration is in seconds, same as length in old info output.

You mean like hh:mm:ss time display instead of just seconds?

I output of the ffprobe I looked at shows only this:

$ ffprobe -show_format Chimaira_-_Six__Studio_.flv 2>/dev/null 
[FORMAT]
filename=Chimaira_-_Six__Studio_.flv
nb_streams=2
format_name=flv
format_long_name=FLV format
start_time=0.000000 
duration=585.000000 
size=68318892.000000 
bit_rate=947705.000000 
TAG:duration=585
TAG:starttime=0
TAG:totalduration=585
TAG:width=854
TAG:height=476
TAG:videodatarate=829
TAG:audiodatarate=97
TAG:totaldatarate=934
TAG:framerate=30
TAG:bytelength=68318892
TAG:canseekontime=true
TAG:sourcedata=B4A7D0F21HH1360188700754461
TAG:purl=
TAG:pmsg=
[/FORMAT]

popcornmix · 2013-02-23T12:13:12Z

@hinxx
Looks good to me

hinxx · 2013-02-23T12:32:33Z

👍

Here's the unclean diff (I can clean it up and add the hh:mm:ss output after the weekend) for the impatient:

https://docs.google.com/file/d/0B6ER6ItJU4ePZG1pdFNCRXoxT28/edit?usp=sharing

Binary built ton the RPI:

https://docs.google.com/file/d/0B6ER6ItJU4ePd3ZxcjdXbGpJOGs/edit?usp=sharing

Enjoy the weekend!

KenT2 · 2013-02-23T15:17:30Z

If the track format is non-standard omxplayer outputs a text narrative, example here:

http://www.raspberrypi.org/phpBB3/viewtopic.php?p=240543&sid=02f907f63638cfff6abd91b18a3fc363#p132261

and here:

jbaiter/pyomxplayer#1

This tends to break parsers. Just wondered whether you had taken this into account. Maybe just precede and non-standard text with text :

KenT2 · 2013-02-23T15:25:00Z

I've put together some ideas about improving handshaking for discusion and also in the hope that Hinko might implement them for us :) My C++ is non-existent but I will help with testing.

Aims:

Allow omxplayer to operate better as a sub-process.
Report when omxplayer has identified an error.
Allow overlapping of two or more tracks to reduce the gap, each track will be played by a separate process.
Efficient parsing of run time status messages

I personally use Johannes Baiter's pyomxplayer and Noah's pexpect. My ideas are based
on use with these.
https://github.com/jbaiter/pyomxplayer

It appears that omxplayer can be in one of three states:
a. preparing to play a track. Preparing can overlap the playing of another track.
b. playing the track - the track is being rendered. This state cannot be overlapped.
c. tidying up - rendering of the track is complete and another track could be played while tidying up happens.

omxplayer command is sent
suggested protocol:
omxplayer command is sent, return one of:
'ready to play:' - preparation is complete.
'error detected: ($error text)' - omxplayer has detected a problem with the command or its referenced track and has exited.

Note: The pause control can be sent immediately after the omxplayer command.
In that case omxplayer completes preparation and pauses before the first frame is played.
The 'ready to play' message should be sent immediately before the pause is actioned.

quit command is sent or track finishes naturally
When the quit command is sent to interrupt a track there is a period of time before 'have a nice day'
is returned. I guess this is primarily due to buffered data being rendered followed by a short tidying up period.
After a natural finish the period is much shorter.

suggested protocol:
quit command is sent or track finishes naturally, send:
'finished playing' when it is possible for a second track to be rendered (by unpausing after 'ready to play' is received)

An embellishment of this might be to return the reason for the finishing -
'finished playing: (quit)'
'finished playing: (end)'
'finished playing: (error - $error-text)' - runtime error is detected.
(quit)(end) and (error) are not required for handshaking and are for information only.

omxplayer process completes for any reason including error
just before termination send 'exiting:' (followed maybe 'have a nice day' for backward compatibility)

SYNTAX
The syntax of the messages should:

be efficiently differentiable from the status message produced by the omxplayer -s option.
It might be worth thinking of changing the status message produced by the -s option to assist this
or having a simpler to decode abbreviated message having only running time of video and audio tracks.
be compatible with the format being produced for responding to the -i option as this information is generated whenever
omxplayer is used.
allow efficient matching with a compiled regular expression. Using a message passing interface and pexpect you parse the output from omxplayer every 50mS.

hinxx · 2013-02-25T09:17:05Z

@KenT2
Thank you for exhaustive description of desired interface, but I guess would need to get more acquainted with omxplayer code to be able to code something like this :) Apart from running the player few times and adding the insignificant info bits the other day I'm not hands on the omxplayer code..

Anyhow, I already had an idea for adding more generic interface for controlling omxplayer - maybe through Unix domain socket or TCP/IP socket. IMHO this approach would solve the issue of controlling and retrieving various information from the omxplayer process - IOW no more expect and tedious parsing of the ever-changing textual information by the "client" applications..

hinxx · 2013-02-25T09:25:12Z

Here's is a cleaned up version of the diff that implements desired info output.

diff --git a/OMXReader.cpp b/OMXReader.cpp
index a69e618..db8721e 100644
--- a/OMXReader.cpp
+++ b/OMXReader.cpp
@@ -247,9 +247,26 @@
     }
   }

-  printf("file : %s result %d format %s audio streams %d video streams %d chapters %d subtitles %d length %d\n", 
-      m_filename.c_str(), result, m_pFormatContext->iformat->name, m_audio_count, m_video_count, m_chapter_count, m_subtitle_count, GetStreamLength() / 1000);
-
+  // show file info
+  printf("filename         : %s\n", m_filename.c_str());
+  printf("nb_streams       : %d\n", m_pFormatContext->nb_streams);
+  printf("video_streams    : %d\n", m_video_count);
+  printf("audio_streams    : %d\n", m_audio_count);
+  printf("nb_chapters      : %d\n", m_pFormatContext->nb_chapters);
+  printf("nb_chapters      : %d\n", m_chapter_count);
+  printf("nb_subtitles     : %d\n", m_subtitle_count);
+  printf("format_name      : %s\n", m_pFormatContext->iformat->name);
+  if (m_pFormatContext->iformat->long_name)
+    printf("format_long_name : %s\n", m_pFormatContext->iformat->long_name);
+  else
+    printf("format_long_name : unknown\n");
+  printf("start_time       : %lld\n", m_pFormatContext->start_time);
+  printf("duration         : %d\n", GetStreamLength() / 1000);
+  printf("bytelength       : %lld\n", m_pFile->GetLength());
+  if (m_pFormatContext->bit_rate > 0)
+    printf("bit_rate         : %d\n", m_pFormatContext->bit_rate);
+  else
+    printf("bit_rate         : N/A\n");

   m_speed       = DVD_PLAYSPEED_NORMAL;

PS.: hope the format is appropriate.

popcornmix · 2013-02-25T23:13:11Z

@hinxx
Thanks for patch, I've merged it in.

popcornmix closed this as completed Feb 20, 2013

popcornmix reopened this Feb 20, 2013

vpetersson mentioned this issue Feb 28, 2013

Add tracking of duration of videos Screenly/Anthias#68

Closed

popcornmix closed this as completed Apr 27, 2013

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Feature request: provide a better info data #118

Feature request: provide a better info data #118

vpetersson commented Feb 14, 2013

popcornmix commented Feb 15, 2013

vpetersson commented Feb 15, 2013

KenT2 commented Feb 15, 2013

vpetersson commented Feb 17, 2013

hinxx commented Feb 20, 2013

popcornmix commented Feb 20, 2013

hinxx commented Feb 23, 2013

vpetersson commented Feb 23, 2013

hinxx commented Feb 23, 2013

popcornmix commented Feb 23, 2013

hinxx commented Feb 23, 2013

KenT2 commented Feb 23, 2013

KenT2 commented Feb 23, 2013

hinxx commented Feb 25, 2013

hinxx commented Feb 25, 2013

popcornmix commented Feb 25, 2013

Feature request: provide a better info data #118

Feature request: provide a better info data #118

Comments

vpetersson commented Feb 14, 2013

popcornmix commented Feb 15, 2013

vpetersson commented Feb 15, 2013

KenT2 commented Feb 15, 2013

vpetersson commented Feb 17, 2013

hinxx commented Feb 20, 2013

popcornmix commented Feb 20, 2013

hinxx commented Feb 23, 2013

vpetersson commented Feb 23, 2013

hinxx commented Feb 23, 2013

popcornmix commented Feb 23, 2013

hinxx commented Feb 23, 2013

KenT2 commented Feb 23, 2013

KenT2 commented Feb 23, 2013

hinxx commented Feb 25, 2013

hinxx commented Feb 25, 2013

popcornmix commented Feb 25, 2013