Transkodierungen

[mrshonig 3]

Servus!

Habe zur Zeit ein wenig probleme wegen dem Transkodieren, verstehe das auch nicht ganz genau. 

Wenn ich eine Datei abspiele die durch Emby transkodiert werden muss ruckelt das bild und es spielt das video nicht richtig ab. (Android TV)

Wenn ich diese datei aber mit dem NovaPlayer vom Emby server abspiele läuft das video ohne Probleme. Warum? 

Warum muss Emby transkodieren obwohl der Fernseh die datei ohne probleme abspielen kann?

[Happy2Play 9441]

Was zeigen die Nerd-Statistiken während der Medienwiedergabe?

Bitte poste das Server- und ffmpeg-Protokoll für den gespielten Gegenstand.

 

What does the Nerd Stats show during media playback?

Please post server and ffmpeg log for item being played.

[mrshonig 3]

Hier die dateien ... es zeigt an falscher container... 

embyserver.txt ffmpeg-transcode-b67d5a10-9eb5-472f-9bc0-b75a69040108_1.txt

Edited October 26, 2020 by mrshonig

[pünktchen 1350]

AVI Dateien werden bei Emby grundsätzlich transcodiert. Die gehen dabei aber von h263 bzw. mpeg4 als Videocodec aus. Eine AVI mit h264 wie bei dir ist eher ungewöhnlich und leider schafft das dein Prozessor nicht. Eigentlich würde ein reiner Containerwechsel bei deinem Videocodec ausreichen, aber damit hat bei Emby wohl keiner mit gerechnet @softworkz Lösung in deinem Fall, mux die Datei selber in eine MKV.

[mrshonig 3]

Ja bin schon dabei, werde jetzt alle AVI dateien in MKV umwandeln sind ja nur 252 dateien

MKV dateien müssen aber nie Transkodiert werden oder? 

[pünktchen 1350]

6 minutes ago, mrshonig said:

MKV dateien müssen aber nie Transkodiert werden oder?

Für die Wiedergabe im Browser schon, sonst nicht. Aber normalerweise findet dann wirklich nur ein Containerwechsel (Remux) statt, außer du hast PGS Subs.

Edited October 26, 2020 by pünktchen

[mrshonig 3]

ich schaue meistens über Android TV, habe aber nur bei diesen containern probleme und auch nur bei abspielen über EMBY: 

itle1080p H264

CodecH264

Codec TagH264

AVCNein

ProfilConstrained Baseline

Level41

Auflösung1920x1080

Seitenverhältnis16:9

AnamorphNein

InterlacedNein

Bildrate25

Bitrate3.996 kbps

Bit-Tiefe8 bit

Pixelformatyuv420p

Referenz-Frames1

NAL0

Audio

TitleAC3 5.1

CodecAC3

Darstellung5.1

Kanäle6 ch

Bitrate384 kbps

Sample-Rate48.000 Hz

StandardNein

Container:avi

 

 

Medieninformationen

Video

Title1080p H264

CodecH264

Codec TagH264

AVCNein

ProfilConstrained Baseline

Level40

Auflösung1916x1040

Seitenverhältnis479:260

InterlacedNein

Bildrate23,976

Bitrate3.954 kbps

Primärfarbenbt709

Farbraumbt709

Farbtransferbt709

Bit-Tiefe8 bit

Pixelformatyuv420p

Referenz-Frames1

NAL0

Audio

TitleAC3 5.1

CodecAC3

Darstellung5.1

Kanäle6 ch

Bitrate448 kbps

Sample-Rate48.000 Hz

StandardNein

Containeravi

Pfad/volume1/media/Movies/Men in Black II (2002)/Men In Black 2- 2002- HD.avi

Größe2782MB

 

 

Bei MKV dateien habe ich überhaupt keine Probleme, sei es Apple TV, Android TV, Smartphone usw. 

 

[pünktchen 1350]

Das habe ich ja oben schon versucht zu erklären. Der Exoplayer, der z.B. in der Emby AndroidTV app verwendet wird, unterstützt gar keine AVI-Dateien.
Also muss der Container gewechselt werden. In dem Fall zu einem HLS-Stream mit TS-Container. Der TS-Container unterstützt aber keinen H263 Videocodec der normalerweise bei einer AVI verwendet wird (davon geht Emby jedenfalls aus). Deswegen wird zu H264 transkodiert. Das deine AVI ja schon den H264 Videocodec hat und deswegen die Transkodierung gar nicht notwendig wäre, ist halt ein Fehler von Emby.

[softworkz 4568]

AVI is a file format for local use, not for streaming.

You might have seen situations where you experience a significant delay when opening an AVI file that resides on a network folder.
This happens due to the fact that the AVI format expects a client application to have random access to any position in the file. On playback start, a client typically tries to seek to the end of the AVI because that's where the seek-index located (not always, depends on a number of factors). The seek index tells at which byte position a certain timeline position is located (specifically, the nearest key-frame to that position). 

With MKV, it's a bit better, because it can reserve some space for the index at the beginning of the file and write it there upon completion.

Though, In most cases, Emby streams to client via HLS, where the video is cut into segments. Those segments should be independent from each other, to allow random access, and to be independent, we need to have at least one keyframe in each segment (typically 3s). When we don't know the source video (it could have a keyframe only every 30s), it can happen that we transcode even H.264 to H.264, just to ensure the keyframe frequency.

 

[Luke 40075]

This app can direct play them:

Can you try it and see how it compares? Thanks.

[mrshonig 3]

Ich werde es am Wochenende versuchen

[Luke 40075]

6 minutes ago, mrshonig said:

I will try on the weekend

Great, thanks !

[mrshonig 3]

On 10/27/2020 at 6:24 AM, Luke said:

Great, thanks !

Hey, I just downloaded and installed the emby-android-google-armeabi-v7a-release.apk.

Now it plays the video without transcoding, but too fast and the sound doesn't match at all. so you can't see it at all.

A pity

 

[Luke 40075]

10 hours ago, mrshonig said:

Hey, I just downloaded and installed the emby-android-google-armeabi-v7a-release.apk.

Now it plays the video without transcoding, but too fast and the sound doesn't match at all. So you can't see it at all.

A pity

 

Is it an avi that you played?

[mrhonig 7]

Exactly the same one I posted above. I have tested several but is not possible. It plays the file too fast and the sound is not correct at all... Is unbeatable.  Avi h264

[softworkz 4568]

We must not forget that H.264 in AVI is completely off-spec.

The next thing is that it doesn't allow referencing future data in the contained streams.

This becomes a problem when B-frames are being used for encoding the H.264 video stream. These problems existed already with MP4 (Part 2) video, that's why DivX and XVID came up with some hacks to still use this inside AVI. Those hacks are pretty well supported, but for H.264 it's less common. 
Those hacks work basically in a way that multiple frames that are referencing each other are packed into a single one. When the player cannot deal with the hack, it might only see a single frame per "frames package". That would explain why you see the video playing very quickly. 

Bottom line:

1. As I mentioned above already: AVI is not a suitable format for streaming (https://en.wikipedia.org/wiki/Comparison_of_video_container_formats)
2. H.264 in AVI is off-spec and not well supported

The problem with AVI containers is:

• There are many variants and combinations of AVI files:
  • One user might have 100 AVIs that work
  • Another user could 100 AVIs (different AVI variants) that don't work
• And there are many different player implementations - each having different capabilities

=> It's a lottery game (there are more problems with AVI files that I didn't cover)

So, I think we should be careful about declaring a player as "can play AVI". At least the combination of AVI+H.264 should be excluded I guess.

[mrhonig 7]

So wie Sie es erklärt haben, verstehe ich es sehr gut. Ich denke, Sie haben Recht, also habe ich alle avi Dateien zu MKV konvertiert.

Nur die Arbeit, sie jetzt zu ersetzen, ist ein bisschen komplex, aber in Der Zukunft werde ich natürlich zuerst AVI-Dateien konvertieren und dann

Danke vielmals

 

 

The way you explained it, I do it very well. I think you are right, I also converted all avi files to MKV.

Just the work of replacing them now is a bit complex, but in the future of course I will convert avi files and then

Many thanks

Edited October 30, 2020 by mrhonig

[softworkz 4568]

You're welcome!