UPnP / DLNA Media Server for MediaPortal 2 | Page 34

@FreakyJ
Thanks for asking - and sorry for only a short answer as I don't have much time currently...

First of all, I think "ImpersonationService.ExecuteWithResourceAccessAsync" is more similar to what you Need than "ProcessUtils.TryExecuteAsync". The first one supports impersonation, which may be necessary if you want ffmpeg to transcode a video that is accessible through a NetoworkNeighborhoofResourceAccessor pointing to e.g. a NAS for which you need credentials to access it. The code of these two is nearly identical - except for the impersonation.

The reasons why it is a bit "hacky" are mainly two:

• The Process class doesn't support starting a process with different credentials. To be able to do so at all, we need to use reflection.
• The Process class often leads to dead-locks when you want to read the standard-output and -error streams.

As to aborting the process, we currently only have a timeout value that terminates the process automatically when the timeout is reached. Following the TAP pattern I could well imagine that we have an overload of the method that accepts a CancellationToken instead of a timeout. That way you can terminate the process via the CancellationToken. I could even imagine that we move the main part of the code to the method with the CancellationToken parameter and let the overload with the timeout just call the first one with a cancellationToken that cancels automatically when the timeout is reached.



As to your second question, this seems more complicated. What these methods currently do is they return a task that completes, when the Process is finished (i.e. exited automatically or terminated after the timeout). Then they return a ProcessExcutionResult that contains anything that was written to stdout and stderr during executing the process (in form of strings).
What you need seems to be a way to read stdout WHILE the process is running. And this is not what these classes and methods were meant for...
I'll think about that one a bit - maybe I have some more ideas...

 

No problem! I am happy about every answer

Thanks to your detailed explanations during the importer rework I know that and I am using this function But the ProcessUtils.TryExecuteAsync function is the underlaying problem^^ But I guess you know that

That would be fine for me, I would feel more comfortable if you could do the changes, somehow I am afraid to screw it up

Thank you very much. I am looking forward to hear back from you

But no rush, it is working right now and there is a todo in the code so that I won't forget

 

Yes you understood me correct, but I changed my mind again. I was in the middle of the porting process and than I realized that this code isn't better than the code we already have.
So I decided to split your code in smaller peaces so that it is easier to understand what is happening. Also I am trying to separate the FFMpeg specific parts from the rest. You already have an option to choose from transcoders (kind of: TranscoderBinPath), so maybe we will add other transcoders in the future and it would be much easier if the FFMpeg code is already spitted from the rest.
I hope you are comfortable with this. I really like your work and feel a bit sorry that I am messing around there so much.

That is really create Thank you!
I think you should try something else: You start to transfer a file and than send another request and see if you get an answer. Do you know what I mean?

Looking good to me

I am heavily working on the MediaConverter.cs file. Just for your information^^ I will push as soon as it is compiling again.

Another point:
I limited the video bitrate in the default profile so the filesize is now around 2GB instead of 12 GB (for a 50 min Episode). But the quality isn't the best anymore
I think this is due to the ultrafastpreset I am using. Have to do some further testing.

Another problem I've found:
While ffmpeg is still transcoding you can't seek. But I couldn't come up with a solution yet... I did some reading but I really don't know how to tackle this. Do you have an idea?

 

fair enough But I think we agree that it would still be nice to have support for different encoders regardless if it vlc, ffmpeg or something complete different^^

I had to kind off reapply your changes made here: https://github.com/MediaPortal/MediaPortal-2/commit/ee0f62351087b87c36d48827addd678ae0e70876
I hope I haven't screwed anything up, but it seems like it is still working^^

It happened to me, too. Suddenly a .git*something* file popped off in the repo which wasn't in the version control. It was responsible for changing the new lines somehow. I just deleted that file and than everything was fine again

MediaInfo (open) MediaInfo (close)

Allgemein
UniqueID/String : 174704328384445386652477233632116214006 (0x836ED46A2A86D5B0BF34B04C9A1808F6)
Vollständiger Name : O:\Serien\Covert Affairs\Staffel 01\Covert Affairs - 1x01 - Pilot.mkv
Format : Matroska
Format-Version : Version 2
Dateigröße : 2,79 GiB
Dauer : 1h 20min
Gesamte Bitrate : 4 976 Kbps
Kodierungs-Datum : UTC 2011-09-14 00:25:55
Kodierendes Programm : mkvmerge v4.4.0 ('Die Wiederkehr') gebaut am Oct 31 2010 21:52:48
verwendete Encoder-Bibliothek : libebml v1.0.0 + libmatroska v1.0.0

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format-Profil : High@L3.1
Format-Einstellungen für CABAC : Nein
Format-Einstellungen für ReFrames : 2 frames
Codec-ID : V_MPEG4/ISO/AVC
Dauer : 1h 20min
Bitrate : 4 045 Kbps
Breite : 1 280 Pixel
Höhe : 720 Pixel
Bildseitenverhältnis : 16:9
Modus der Bildwiederholungsrate : konstant
Bildwiederholungsrate : 23,976 FPS
ColorSpace : YUV
ChromaSubsampling : 4:2:0
BitDepth/String : 8 bits
Scantyp : progressiv
Bits/(Pixel*Frame) : 0.183
Stream-Größe : 2,27 GiB (81%)
Default : Ja
Forced : Nein
colour_range : Limited
colour_primaries : BT.709
transfer_characteristics : BT.709
matrix_coefficients : BT.709

Audio #1
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Format_Settings_ModeExtension : CM (complete main)
Format-Einstellungen für Endianess : Big
Codec-ID : A_AC3
Dauer : 1h 20min
Bitraten-Modus : konstant
Bitrate : 448 Kbps
Kanäle : 6 Kanäle
Kanal-Positionen : Front: L C R, Side: L R, LFE
Samplingrate : 48,0 KHz
Stream-Größe : 257 MiB (9%)
Sprache : Deutsch
Default : Ja
Forced : Nein

Audio #2
ID : 3
Format : AC-3
Format/Info : Audio Coding 3
Format_Settings_ModeExtension : CM (complete main)
Format-Einstellungen für Endianess : Big
Codec-ID : A_AC3
Dauer : 1h 20min
Bitraten-Modus : konstant
Bitrate : 384 Kbps
Kanäle : 2 Kanäle
Kanal-Positionen : Front: L R
Samplingrate : 48,0 KHz
Stream-Größe : 220 MiB (8%)
Sprache : Englisch
Default : Nein
Forced : Nein

I don't really know, you can reproduce the problem by adding this to the default profile:

Code (Text):

1. <VideoTarget container="Mpeg2Ts" videoCodec="H264" videoMaxBitrate="4000" audioCodec="Aac" forceTranscoding="true">
2.         <VideoSource />
3.       </VideoTarget>

You can see the complete duration, but you can't seek (at least in WMP). If you use matroska instead of Mpeg2Ts you don't even get the duration (even when the file is completely transcoded). I know that mkv stores the duration at the end like mp4.

Really nice work! Sadly I use a AMD CPU and never bothered updating my graphics card, because I don't play games^^ A GTS450 is enough for the WIndows Desktop

Also I've pushed my changes. I'm not completely finished, but i wanted to push to reduce merge conflicts in case you want to change also some parts in this area.
And any comments are welcome.

 

@henso and @FreakyJ , nice to see the good progress on this plugin .

I have some ideas regarding the many "if / else" code blocks for constructing ffmpeg arguments. One example: https://github.com/MediaPortal/Medi...scoders/FFMpeg/FFMpegCommandline.cs#L426-L441, where there are too many checks.

I'd suppose to reduce the lines of code and putting more configuration options into dictionaries like:

Code (C#):

1.  
2.   Dictionary<EncodingPreset, string> SWEncodingPresets = new Dictionary<EncodingPreset, string>
3.   {
4.   { EncodingPreset.Ultrafast, "-preset ultrafast" },
5.   { EncodingPreset.Superfast, "-preset superfast" }
6.   };
7.   Dictionary<EncodingPreset, string> IntelEncodingPresets = new Dictionary<EncodingPreset, string>
8.   {
9.   { EncodingPreset.Ultrafast, "-preset ultrafast" },
10.   { EncodingPreset.Superfast, "-preset superfast" }
11.   };
12.   Dictionary<EncodingPreset, string> NVidiaEncodingPresets = new Dictionary<EncodingPreset, string>
13.   {
14.   { EncodingPreset.Ultrafast, "-preset ultrafast" },
15.   { EncodingPreset.Superfast, "-preset superfast" }
16.   };
17.  

Then you have choose the matching dict only once and use a .TryGet() to translate the presets to string args in one line. If you apply this to the other arguments as well, the number of code lines will be significantly reduced. It would also allow moving out the mappings into settings, what would allow easier extension without adding more code lines.

I have not checked other parts, but I hope you can apply some of those refactorings

 

Sure! I will try to do this during this week Your input as a real developer is really appreciated!

 

To go even a step further: there could be a base class with all common code (the sw based). Then other derived classes for the 2 hw accelerated modes.