SmartTV cannot playback h264 output

[eumagga0x2a]

If yes, then, well, don't use MKV to store MPEG-2 in the first place, unless re-encoded to H.264.

I should have definitely re-read the subject prior to writing this 

Anyway, it would help to have samples with identical visual content and of the same container type grouped in pairs "works with Plex + Panasonic Viera" / "doesn't work with Plex + Panasonic Viera".

[Markus]

Sorry, I'll drop the "smart encoding" discussion, because it's not really relevant to the issue at hand.

I did some more tests: The container format (I tried MP4 Muxer and MKV Muxer) does not make a difference: If the file cannot be played back, it cannot be played back if saved in the other container format either.

I uploaded another sample, this time the original is SD resolution encoded in MPEG2. As soon as avidemux "touches" the file, it cannot be played back via Plex streaming to Panasonic Viera TV. For comparison, I included the original file and some encoded with handbrake. I also placed them in subdirectories "WorksWithPlexAndViera" and "DoesNotWorkWithPlexAndViera".

I saved all files twice, once with MP4 Muxer, once with MKV Muxer. The MP4 Muxer uses the default setting which includes your suggested "Optimize for streaming" set to "move index to the beginning of the file").

For further comparison, I uploaded a self-recorded short video, which I copies and encoded in avidemux, both in MP4 and MKV, and encoded in handbrake, also MP4 and MKV. All those sample files can be streamed via Plex to the Panasonic Viera TV.


Greetings
Markus

[eumagga0x2a]

Thank you very much for the comprehensive collection of samples. IMHO, the most probable reason why samples get rejected is audio track being not AAC, i.e. it is not video- but audio-related. Please try to re-encode MP2 and AC3 audio tracks to AAC when muxing streams into MKV or MP4.

The original MPEG-2 stream is technically interlaced, but practically both fields are created from exactly the same moment of time, thus no combing artifacts with this particular content.

I wonder why is Handbrake acting weird, cropping the picture from 720x576 to 694x576? To imitate the effect of overscan? Especially a width which is not a multiple of 16 (or at least of 8 ) is a bad idea as it worsens compressibility.

Whenever you re-encode anamorphic SD material, you should specify display aspect ratio at the container level and preferably also set IDC/SAR to a matching value (here: "PAL 16:9").

[Markus]

Thank you very much for the comprehensive collection of samples. IMHO, the most probable reason why samples get rejected is audio track being not AAC, i.e. it is not video- but audio-related. Please try to re-encode MP2 and AC3 audio tracks to AAC when muxing streams into MKV or MP4.

Success! Re-enconding the audio track to AAC (or not including an audio track at all) produces a file that can be streamed from Plex to the Panasonic Viera TV! I would never have thought that the audio format could prevent playback completely, I would have thought the most would be a video without sound.

But,

the problem is not mp3 Audio in itself. I can produce a MP4 container with h.264 video and mp3 audio, which can be played back using handbrake for encoding. Tests with avidemux and re-encoding to mp3 were inconclusive (read: I produced more samples but did not write down which played and which didn't). I will send further samples later today.

Also, this does not explain why the original stream (mpeg2 video, mp3 audio) can be played back, but not if "copied" with avidemux.

The original MPEG-2 stream is technically interlaced, but practically both fields are created from exactly the same moment of time, thus no combing artifacts with this particular content.

That is good to hear. This answers a different question I had: Sometimes I see interlacing artefacts, but my resulting files seem clean, even without de-interlacing. Maybe only the commercial breaks are "real" interlace, while the shows themselves aren't.

Whenever you re-encode anamorphic SD material, you should specify display aspect ratio at the container level and preferably also set IDC/SAR to a matching value (here: "PAL 16:9").

I usually force resolution in the Muxer options, if the first try produces a distorted aspect ratio. Does this option also set the "IDC/SAR" values correctly?


Thanks for your help so far. At least, I now have a a simple "recipe" how to produce playable files: Re-encode the audio track.

I seems, that something is preventing a playable file with certain combinations of encoders. If you are still interested, I will do some more tests, maybe we can find the root cause.


Greetings
Markus

[Markus]

I wonder why is Handbrake acting weird, cropping the picture from 720x576 to 694x576? To imitate the effect of overscan? Especially a width which is not a multiple of 16 (or at least of 8 ) is a bad idea as it worsens compressibility.

I don't know. I too noticed some odd changes of resolution, which I cannot explain. I'll send you a screenshot of the "dimensions" tab in handbrake, vertical size is consistent, but there are three different horizontal sizes. Handbrake seems to mess around with aspect ratio:

Source Dimensions:

• Storage Size: 720x576
• Display Size: 1024x576
• Aspect Ratio: 16:9

Resolution and Scaling:

• Resolution limit: None
• Anamorphic: Automatic
• Pixel Aspect (this is greyed out): 64 : 45
• Scaled Size: 694x576

Final Dimensions

• Storage Size: 694x576
• Display Size: 987 (no vertical given)
• Aspect Ratio: 15,42:9

[eumagga0x2a]

Also, this does not explain why the original stream (mpeg2 video, mp3 audio) can be played back, but not if "copied" with avidemux.

There is no mp3 audio in the original stream, it is mp2 (interestingly, mpv reports mp3 for mp2 when in an MP4 container). When the video stream is mpeg2video, you should remux it either to MPEG-TS or MPEG-PS only. Does Plex still reject the result when using one of those containers as output format in Avidemux?

Maybe only the commercial breaks are "real" interlace, while the shows themselves aren't.

Exactly this.

I usually force resolution in the Muxer options, if the first try produces a distorted aspect ratio. Does this option also set the "IDC/SAR" values correctly?

No, there is no sync. You need to take care of that manually if you wish to make all players happy. However, the value specified by the container usually takes precedence.

Regarding HandBrake, in "dimensions" tab, you should disable cropping (it defaults to "automatic") which seems to be responsible for the mess.

[Markus]

Also, this does not explain why the original stream (mpeg2 video, mp3 audio) can be played back, but not if "copied" with avidemux.

There is no mp3 audio in the original stream, it is mp2 (interestingly, mpv reports mp3 for mp2 when in an MP4 container). When the video stream is mpeg2video, you should remux it either to MPEG-TS or MPEG-PS only. Does Plex still reject the result when using one of those containers as output format in Avidemux?

Oh, I didn't realize that the video stream contains mp2, but in hindsight MediaInfo did identify MPEG Audio Layer2.

I'll try the other two Muxers you suggested.

Regarding HandBrake, in "dimensions" tab, you should disable cropping (it defaults to "automatic") which seems to be responsible for the mess.

Ah, indeed, setting Cropping to Manual and resetting all values to 0 did the trick, the horizontal resolution switches to 720 (storage) and 1024 (display). When I switch back to automatic, the value for Left cropping is set to 26. Strange.


I'll upload a few more samples, if I find some further strange results.

[Markus]

Yes, that was it: I did more tests with "Copy" mode for both video and audio, this time with the "correct" muxers "MPEG TS Muxer (ff)" and "MPEG-PS Muxer( ff)". This produces files which can be streamed via Plex to my TV. On the flip side, if I change the Muxer to MP4 or MKV, I have to re-code the MPEG2 audio track too (for example AAC).

This also works for recordings of HD streams, but then I have to use the "TS" muxer, the other ("PS") cannot handle the HD video (avidemux shows an error message in this case). I did not upload further samples, since the problem was between keyboard and chair, not in avidemux :-)


To sum up:

What works:
TV stream from Astra satellite, contains audio in MP2 format and is contained in Blu-ray muxer (BDAV or "ts" file):
"Copy" audio and/or video using "MPEG TS" or "MPEG-PS" Muxer
 - OR -
Re-Encode both video and audio

What does not work:
"Copy" audio and video and change the Muxer to MP4 or MKV


I think this solves the problem for me. I now have a way to store videos without reducing quality and know how to produce compressed files correctly.

Thank you very much for your patience. I thought I knew enough about video and audio formats, but, as always, things are a bit more complicated than one might think. Now I know, that not every codec fits into every container format, or rather, that those files might not be accepted by all players.


To avoid confusion for others, this might be something to put into a FAQ, especially that many TV streams contain outdated audio codecs in old muxer formats, and you should not mix and match everything.

As a suggestion, it would be helpful if avidemux showed the current formats. For example, I did not know which muxer was used in the source file and MediaInfos "BDAV" did not ring any bells. Also, avidemux did not warn that the file extension (mpeg) did not correspond with the muxer used. This is neither an essential nor urgent feature, just a suggestion for future editions.

[eumagga0x2a]

This also works for recordings of HD streams, but then I have to use the "TS" muxer, the other ("PS") cannot handle the HD video (avidemux shows an error message in this case).

This is normal and expected as MPEG program stream (MPEG-PS, the format used by video DVDs) is compatible with MPEG-1 and MPEG-2 video only. MPEG transport stream (MPEG-TS), used in digital broadcasts and in Blu-Ray media is much more advanced and versatile.

the problem was between keyboard and chair, not in avidemux :-)

Not quite, the limitations of the Plex software undoubtfully contributed the major part :-)

As a suggestion, it would be helpful if avidemux showed the current formats. For example, I did not know which muxer was used in the source file and MediaInfos "BDAV" did not ring any bells.

You will find all the info in Avidemux application log ("Help" --> "Advanced" --> "Open Application Log" on Windows, as /tmp/admlog.txt or as console output when run in the Terminal app on macOS, in the user journal or as console output on Linux). Showing demuxer name in the GUI is not planned as Avidemux is designed to work with multiple files which doesn't need to be of the same type. User education is necessary this way or another when dealing with complicated stuff like video editing. Developing skills in parsing MediaInfo reports doesn't become less essential even when reading Avidemux log turns into habit.

Also, avidemux did not warn that the file extension (mpeg) did not correspond with the muxer used.

Do you mean that Avidemux should have warned against MPEG-2 in MKV? Why should it? Neither MPEG-2 nor MP2 in MKV violates any specification. Else I don't quite follow you. "mpeg" as filename extension is a pretty good match for MPEG-TS.

Filename extensions are basically meaningless, they are a convenience which helps file managers and other applications to sort folder contents quickly without actually probing each file.