Closed vpetersson closed 11 years ago
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?
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.
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.
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.
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?
@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.
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 $
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.
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]
@hinxx Looks good to me
:+1:
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!
If the track format is non-standard omxplayer outputs a text narrative, example here:
and here:
https://github.com/jbaiter/pyomxplayer/issues/1
This tends to break parsers. Just wondered whether you had taken this into account. Maybe just precede and non-standard text with text :
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:
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.
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.
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.
SYNTAX The syntax of the messages should:
@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..
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.
@hinxx Thanks for patch, I've merged it in.
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:
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:
The reason I want this is to be able to utilize the output in Screenly.