Messages

@MartenR

I tried today  to make it compile under windows and I am wondering, why mediafile.cc accesses the lokal filesystem.
Can you explain me what it does?
At the moment it makes no sense for me to access the dongle file system.

Basicall the media player infrastructure is somehow generic.
This way it is also possible to access media files locally at the dongle. The basic intention for this was to e.g. enable upnp access to media servers. I did not really work on this intensively in the past - but in general it works.
If this is a problem on windows, just omit registering the local file access functions on windows (skip registering the mediaprovider in ctor localmediafile.cc).
I guess to make it working on windows it would need some changes to deal correctly with the / -> \ issue.

regards
Andreas

In the german vdr forum we had some reports about missing the last seconds when playing a VDR recording.
See http://www.vdr-portal.de/board/thread.php?postid=766497#post766497

As I understand the code, this is related to the buffers in the stream classes. The playerlivetv will stop it's thread (and this way dismiss) as soon as it has delivered the last packet to the demuxer. But afterwards there is still a lot of data in the buffers...

My solution in the playermedia is the following:
1. remember the last parsed PTS in the demuxer (i.e. the packet just delivered to the stream)
2. when the last chunk of data has been delivered to the demux I start a timer (max. 15s) and in parallel wait until video has seen the last delivered PTS.
3. if video has seen the last PTS I start another timer of 3s to have the last frames
4. if either the first or the second (short) timer fire I will stop

I guess the same solution could be used for the recordings player.

Regards
Andreas

@davep,

I see the Media Player has appeared in CVS. Unfortunately it doesn't work for me. When I navigate to a directory containing .jpg files and select one, the screen blanks and the MVP has to be power-cycled. If I do the same with a .mp3 file the music plays but again the screen blanks and the only way to regain control is the power switch.

Unfortunately Chris did not integrate some of the most important changes to boxxstack.cc.
I attach a patch here, that contains the still necessary changes to boxstack.cc - maybe you can try it out.

Regards
Andreas

Hi all,
I just released a patch to be able to correctly play files > 2GB.
For details refer to http://www.wellenvogel.de/software/vomp/index.html#Update_20081222
Regards
Andreas

Hi,
with the demuxer I'm not really that sure - I was searching for some performance improvements because I saw the demuxer thread (i.e. the player thread) just consuming all the CPU - but most probably you are right - at the end I it's not really clear if the patches did improve anything - at least before them I had a lot of dropped chunks (i.e. artefacts in the video) - afterwards much less. But maybe the demuxer part did not really help a lot (was just to provide it as a basis for discussion).
Maybe you have some other ideas why the demuxer takes that much CPU (for mpeg videos it seems to be much less - even with the demuxer being very similar (of course not handling the ts packets)...
In fact the high CPU usage was really driving the crashes and deadlocks because it increased the chance for multiple threads accessing data at the same time.
But I guess with the changed locking this should not be a problem any more. Anyway it just occurs on really high bandwith channels.

regards
Andreas

Hello all,
second update for today:
Vomp can now play dvd's and iso images via the server side scripts (mencoder).
For details seehttp://www.wellenvogel.de/software/vomp

Regards
Andreas

Hi all,
after I had a couple of problems especially on high bandwith channels (ARD I)  - vomp locked or crashed, I had some code review and found there is no protection for the shared data structures in playerlivetv. But at the end there are 3 threads working on them - receiver,player,GUI. This can easily lead to data corruption. On the other hand the playing thread could block forever...
So I created some patch that solved the problems (based on cvs 2008/11/28).
Additionally I also rewrote the ts demuxer to avoid at least copying all the data twice - this seemed to increase the performance a bit (less artefacts).

I attach the patches here.

Andreas

Hi,
don't think so.
Mplayer is just for rendering videos to a display device. This would require a complete redesign of the vomp architecture (because the MVP does the MPEG decoding and rendering in hardware).
Mencoder is just mplayer's brother (same decoders...) for transcoding stuff.
BTW there is now also support for ffmpeg as transcoder (but of course still with no chance for positioning). see http://forum.loggytronic.com/index.php?topic=248.135.
I've got some ideas for the positioning stuff (caching...) - but this is a bigger job to be done.

Regards
Andreas

Hi all,
just added some small additions (bug fixes) and improvements for the server side converter.
See http://www.wellenvogel.de/software/vomp/index.html#Update_20081214.
The patches do also include some stability patches for the live tv viewer (especially for high bandwith channels like german "Das Erste").

Regards
Andreas

Hello all,
today I finished porting the latest media player stuff to the current CVS (as of 2008/11/28).
This includes:

• the known functions
• the tcp patch (handling of keypresses during receive should not break connection
• the position issue for smaller videos (not heavily tested yet)

Unfortunately the internal handling of views has a lot of changes that caused a couple of deadlocks - so I had to add some lock/unlock there.
Files can be found at www.wellenvogel.de/software/vomp#Update_20081130.
Feedback is highly appreciated.
Would be really great if the stuff could go to CVS in the near future - it's a lot of effort to always port things...

Regards
Andreas

Hi Walter,
yes I will port back to current version.
It's getting colder outside now, so there will be time in the near future to continue hacking a bit.
I will have a look at the position issue (most probably easy to fix).

Regards
Andreas

Hi all,
for the mediaplayer part I went away a bit from the fxied predefined packets (except for the media data itself). Instead I used an approach like in other comm - protocols with compatbile serializers and deserializers at both sides. I already proposed to take this over for the other parts too - but did not get any response.
For me the advantage would be, that there is no need for bit by bit fixing the protocol (as all know this rapidly changes - so the description would always be outdated - like this one ;-( ).
Additionally the versioning schema included will allow for easily extend the protocol in a compatible way, so that old and new versions on both sides could interact.
For details refer to the serialize.* and vdrcommand.h on the client and server side.

Summary:
For the media player even I don't really care about the internal structure of the packages, I simply test the serialize/deserialize methods of the classes and that's it.
This way it is difficult to describe the bytes...

Regards
Andreas

hi,
hmm I try to answer.
1). Mpeg1 - anything strange could be most probably played with converting it via mencoder. In the moment the easiest way would be to try to find out how mencoder could covert your stuff into mpeg2, then name all your files e.g. xyz.mpg1 and define a command to be executed for mpg1 in the config file (see some hints here above or in the vdr forum).
2.) still a bug there in the player (maybe could be fixed with some nice mencoder options too...)
3.) letter and clipfactor are a bit different:
see readme_media.txt:

You can select 3 different modes for the picture - "letter" - always completely on screen,
  "crop" always cropped by next possible scale and "croppercent" - you can select the Picture Size
  within the option page from 10%...150% - the picture gets scaled to best fit to the screen within
  this range.

Regards
Andreas

Hi rdoac,

Am trying to find a way to run the mencoder with a nice priority of -10 or so

Maybe just a setuid shell script (or executable) that wraps mencoder and "nices" before really starting it.
There is taht many options to mencoder - maybe we can find something provding sufficient quality by lower CPU usage (would be even great to have some automatic choosing of the right parameters depending on CPU...).

Regards
Andreas

@Lutz

@Andreas: Your patch helps indeed, but it is not perfect.

Maybe Chris is right - and it would make sense to also handle it correctly at reads (some lines later in the file) - just check if read returns < 0 and errno == EINTR.
Sorry - no time for the code in the moment...

Regards
Andreas