SmartTV cannot playback h264 output

[Markus]

Hi,

I'm not sure this ist the right forum to ask, but maybe someone has a few pointers for me:

I cut recorded TV streams with avidemux 2.8.1 (remove extraneous before / after / in between material) and re-encode them into a h264 files. My SmartTV cannot play the resulting mkv file. If I re-code it again with handbrake, playback is possible. This double re-code is time consuming and degrades quality. Of course, I could just store the video with avidemux and then encode in handbrake, but then I can only cut on key frames, which is often not precise enough.

I presume, that some default setting of avidemux prevents playback, but have no idea which. I tried to find a significant difference in the file with MediaInfo, but couldn't see anything obvious.

Any ideas what to look out for? Maybe a setting that often causes problems with playback on hardware players?

The SmartTV is a Panasonic Viera 47AS650, the TV streams are recorded with the TV itself and then "downloaded" via a program to download streams from UPnP servers (the storage disk cannot be read on a computer). Note: Those downloaded files cannot be played back as mediafiles on the same TV, which is strange. So there might actually be a telltale "sign" in the file which instructs the TV not to playback this file, though I doubt it.

[szlldm]

Check IDC level (something like "4.1", "5.1", and more).

[eumagga0x2a]

We got a similar report recently. Unfortunately, the reporter didn't show any willingness to help to troubleshoot the issue.

The most significant difference with the current report is that merely remuxing the stream in copy mode was enough to make in unplayable on "smart" TV sets.

I cut recorded TV streams with avidemux 2.8.1 (remove extraneous before / after / in between material) and re-encode them into a h264 files.

What video codec do these TV streams originally use? MPEG-2? HEVC? Could you please test with a short video recorded e.g. with a smartphone? If the TV set is happy with the original file, please remux it in copy mode with the latest Avidemux again to MP4 and to MKV and check whether the TV set is still able to play the result.

My goal is to determine whether it is something special in the way how we setup libavformat contrary to how Handbrake does it or it is really an encoder configuration the TV doesn't like.

[eumagga0x2a]

I could briefly test on a 2018 Philips smart TV remuxing a 720p sample to MP4 and also re-encoding another sample with x264 at different IDC levels up to 5.0 — no issues whatsoever. Therefore, your help in assessing the nature of the problem you experience is absolutely necessary, otherwise it just WFM.

[Markus]

We got a similar report recently. Unfortunately, the reporter didn't show any willingness to help to troubleshoot the issue.

The most significant difference with the current report is that merely remuxing the stream in copy mode was enough to make in unplayable on "smart" TV sets.

I cut recorded TV streams with avidemux 2.8.1 (remove extraneous before / after / in between material) and re-encode them into a h264 files.

What video codec do these TV streams originally use? MPEG-2? HEVC? Could you please test with a short video recorded e.g. with a smartphone? If the TV set is happy with the original file, please remux it in copy mode with the latest Avidemux again to MP4 and to MKV and check whether the TV set is still able to play the result.

My goal is to determine whether it is something special in the way how we setup libavformat contrary to how Handbrake does it or it is really an encoder configuration the TV doesn't like.

Sorry for not coming back to you sooner, didn't have time yesterday. The "original" video in question are encoded in MPEG2, MediaInfo gives "BDAV" as the file format.

I'll do the experiments you suggested and retry my own experiments with a sample file. It seems I did not actually test to playback the unmodified file on the TV, instead I used a "save" without re-encoding in avidemux.


Might take till tomorrow (sorry for the inconvenience).

[Markus]

I could briefly test on a 2018 Philips smart TV remuxing a 720p sample to MP4 and also re-encoding another sample with x264 at different IDC levels up to 5.0 — no issues whatsoever. Therefore, your help in assessing the nature of the problem you experience is absolutely necessary, otherwise it just WFM.

Thanks for taking my issue seriously. I'll help how I can, which unfortunately means "when I have time". I'm well aware that the issue might be a buggy player software and the solution will be "get a proper video player", but I thought I'll try to ask here first.

[eumagga0x2a]

I well understand both time constraints and the given constant of the available hardware, but nevertheless hope for some persistence if not priority in tracking down the trigger of the issue, just to avoid it slipping into the next release which needs to happen relatively soon due to other issues discovered shortly after 2.8.0 was finalized.

[Markus]

My experiments were a bust (or rather an untimely success): I couldn't reproduce the issue.

The SmartTV did play back all versions: The original MP4 file, a version stored with avidemux, a re-coded to h.264 version and a version where I trimmed a few seconds of beginning and end and then re-coded it.

Also, I tested with a newly recorded TV stream. Same variants as above, all were played back. Both from a USB thumbdrive and from my network server via UPNP streaming protocol (is that the right name for this?).

I still have plenty of old files, that cannot be played back. Maybe something was already inadvertently fixed in avidemux? I often look for the latest daily version and install it, so something might already be changed.

I will try some more stuff. Maybe I have to give you the old examples. However, they are over 1GB big.


Greetings
Markus

[eumagga0x2a]

Does remuxing in copy mode an old MP4 file with the latest Avidemux create a file compatible with the TV set?

[Markus]

I did some more testing: It is more complicated than I thought (isn't it always?).

When the files are on a thumbdrive and plugged into the TV: All testfiles can be played with the TVs internal mediaplayer.

When I place the files on my NAS and stream them via DLNA protocol, the problems manifest. (Last time, while testing, not all files where already indexed on the server, so I missed this "little detail".) Of course, the DLNA player is a different app than the mediaplayer app, I have no information if they use the same code for decoding, though I originally assumed so.

I use Plex on QNAP NAS, which streams mediafiles via DLNA. My self recorded movie can be played back without problem, no matter if original MPEG4, stored or re-coded via avidemux. The original TV recording (MPEG2) file can also be played back, but even storing it with avidemux will make the file unplayable. I do not know whether Plex or the TV produces the problems, the error message is something like "file cannot be opened", which might originate from both. The web-interface of Plex can play back the files, so I suspect the TV is the problematic party, but I'm really not sure.

So, there are incompatibilities, though I can only reproduce them in a more involved scenario. If you are still interested I will make the sample files available to you and send you the link via PM.


Greeting
Markus

[eumagga0x2a]

The original TV recording (MPEG2) file can also be played back, but even storing it with avidemux will make the file unplayable.

What do you mean by "storing"? Original files are probably MPEG-TS files with MPEG-2 payload. MPEG-2 should be muxed either to MPEG-TS or MPEG-PS. Which one do you actually use?

[Markus]

Sorry, I was a bit imprecise.

What I meant by "storing": avidemux "Copy" for video and audio, saved to a mkv container

The "original" file in encoded in MPEG-2, the container format is (according to MediaInfo):
Format : BDAV
Format/Info : Blu-ray Video
Also, MediaInfo complains about the wrong file extension and suggests: m2ts mts ssif


I send you a PM concerning the sample files.


Greetings
Markus

[eumagga0x2a]

Thank you for the samples. The original stream is the Blu-ray variety of MPEG-TS with H.264 video track (not MPEG-2). The remuxed file is a Matroska (MKV). QTS documentation doesn't mention Matroska container as supported, you might want to use the MP4 muxer instead.

I'd recommend to abstain from re-encoding H.264 sources. You lose quality for little if any gain.

[Markus]

You are right, while taking a sample I accidentally used an HD station. I will repeat with an SD station, but the problem probably stays the same.

As mentioned I do not use QNAPs build-in streaming server, but the "Plex" App for QNAP (https://www.plex.tv). This does support mkv.

Concerning re-enconding: The files do get significantly smaller, since the broadcast stream from the satellite usually is encoded using fixed bandwidth. Also, as mentioned, I want to cut the video and those cuts are usually not on keyframes. Thus I will have to re-encode the whole video.


Greetings
Markus

P.S.: As a suggestion for future enhancements: It would be really useful for avidemux to have a function to re-encode just the frames around a cut, i.e. between the two nearest keyframes and just save the rest of the file. This would save a lot of time and preserve the quality of the rest of the video.

[eumagga0x2a]

As mentioned I do not use QNAPs build-in streaming server, but the "Plex" App for QNAP (https://www.plex.tv). This does support mkv.

Indeed, it does as far as the client device agrees.

Concerning re-enconding: The files do get significantly smaller, since the broadcast stream from the satellite usually is encoded using fixed bandwidth

Bitrate is kept more or less constant by injecting filler NAL packets when necessary, which are dropped when remuxing to MP4 or MKV, not by using constant bitrate (a maximum bitrate compatible with available bandwidth is necessary, of course).

Also, as mentioned, I want to cut the video and those cuts are usually not on keyframes. Thus I will have to re-encode the whole video.

I see, this is a question of individual priorities with H.264. With MPEG-2, the situation is different as the codec achieves a relatively low level of compression and is usually not supported by hardware decoders in mobile devices. More important, such videos are usually interlaced and must be deinterlaced prior to re-compression with x264, unless the scan mode compatible with interlacing is selected in x264 configuration.

As a suggestion for future enhancements: It would be really useful for avidemux to have a function to re-encode just the frames around a cut, i.e. between the two nearest keyframes and just save the rest of the file. This would save a lot of time and preserve the quality of the rest of the video.

This is very difficult with closed-GOP H.264 and HEVC streams and outright impossible for open-GOP stream types as widely used in public broadcasts as there are almost no IDR frames in the stream. Keyframes in open-GOP streams are just direct access points which allow to start decoding, all internal stream structures continue across such keyframes.

"Smart copy" might be feasible with MPEG-2, but due to very short GOP lengths, the benefits are not be high enough to justify the investment IMHO.

Do I understand correctly, that MKV file generated by Avidemux from the H.264 HD (720p) MPEG-TS file can be streamed by Plex server to the client (Panasonic TV) successfully and the problem affects only SD (576i) MPEG-2 streams? If yes, then, well, don't use MKV to store MPEG-2 in the first place, unless re-encoded to H.264.

If you re-encode MPEG-2 to H.264 with x264, please try using the MP4 muxer (make sure "Optimize for streaming" is checked and "move index to the beginning of the file" is selected) with audio tracks re-encoded to AAC.