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.
Check IDC level (something like "4.1", "5.1", and more).
We got a similar report (https://avidemux.org/smif/index.php/topic,19762.0.html) 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.
Quote from: Markus on February 06, 2022, 06:40:18 PMI 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.
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.
Quote from: eumagga0x2a on February 06, 2022, 09:05:22 PMWe got a similar report (https://avidemux.org/smif/index.php/topic,19762.0.html) 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.
Quote from: Markus on February 06, 2022, 06:40:18 PMI 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).
Quote from: eumagga0x2a on February 07, 2022, 10:14:23 AMI 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.
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.
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
Does remuxing in copy mode an old MP4 file with the latest Avidemux create a file compatible with the TV set?
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
Quote from: Markus on February 10, 2022, 09:39:04 AMThe 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?
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
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 (https://docs.qnap.com/operating-system/qts/5.0.x/en-us/supported-file-formats-9E77C573.html) 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.
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.
Quote from: Markus on February 11, 2022, 08:46:10 AMAs mentioned I do not use QNAPs build-in streaming server, but the "Plex" App for QNAP (https://www.plex.tv (https://www.plex.tv)). This does support mkv.
Indeed, it does as far as the client device agrees.
Quote from: Markus on February 11, 2022, 08:46:10 AMConcerning 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).
Quote from: Markus on February 11, 2022, 08:46:10 AMAlso, 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.
Quote from: Markus on February 11, 2022, 08:46:10 AMAs 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.
Quote from: eumagga0x2a on February 11, 2022, 01:34:37 PMIf 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".
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
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").
Quote from: eumagga0x2a on February 13, 2022, 07:07:12 PMThank 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.
QuoteThe 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.
QuoteWhenever 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
Quote from: eumagga0x2a on February 13, 2022, 07:07:12 PMI 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
Quote from: Markus on February 15, 2022, 08:02:57 AMAlso, 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?
Quote from: Markus on February 15, 2022, 08:02:57 AMMaybe only the commercial breaks are "real" interlace, while the shows themselves aren't.
Exactly this.
Quote from: Markus on February 15, 2022, 08:02:57 AMI 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.
Quote from: eumagga0x2a on February 15, 2022, 09:32:45 PMQuote from: Markus on February 15, 2022, 08:02:57 AMAlso, 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.
QuoteRegarding 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.
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.
Quote from: Markus on February 17, 2022, 03:41:35 PMThis 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.
Quote from: Markus on February 17, 2022, 03:41:35 PMthe problem was between keyboard and chair, not in avidemux :-)
Not quite, the limitations of the Plex software undoubtfully contributed the major part :-)
Quote from: Markus on February 17, 2022, 03:41:35 PMAs 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.
Quote from: Markus on February 17, 2022, 03:41:35 PMAlso, 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.