News:

--

Main Menu

LPCM, muxer cannot open

Started by attila, April 01, 2020, 07:01:05 AM

Previous topic - Next topic

attila

Hi,

First of all thank you for this very nice software.

I encountered a situation which I don't know how to solve: I saved old VHS videos to mpeg files and cut them with Avidemux.
Source format:

Video
Codec 4CC:      MPEG
Image Size:      720 x 576
Aspect Ratio:      PAL 4:3 (16:15)
Frame Rate:      25.000 fps

Sound
Codec:         LPCM
Channels:      Stereo
Bitrate:      192000 Bps / 1536 kbps
Frequency:      48000 Hz

The output format is MKV, both video and sound are set to "Copy".

Format of the cut file:

Video
Codec 4CC:      MPEG
Image Size:      720 x 576
Aspect Ratio:      PAL 4:3 (16:15)
Frame Rate:      25.000 fps

Sound
Codec:         Unknown codec
Channels:      Stereo
Bitrate:      16000 Bps / 128 kbps
Frequency:      48000 Hz

The created MKV file can be played without any problem in VLC, which shows "twos" as the sound codec.

If I want to cut the video again (the previously created .mkv file) I got the following error in Avidemux: "Muxer       cannot open". I suppose this happens because the sound codec is not recognized.

There is no problem cutting the .mkv file if I create it with audio set to "Opus Encoder" (instead of "Copy").

My questions:
- if I cut the .mkv again with "Opus Encoder": will the sound be reencoded or will it be cut? That is will I loose quality everytime I recut it or only one time?
- is there a way to keep LPCM audio format?

Thank you,

Attila




eumagga0x2a

Quote from: attila on April 01, 2020, 07:01:05 AM
- if I cut the .mkv again with "Opus Encoder": will the sound be reencoded or will it be cut?

Anything different from "copy" will re-encode audio, "PCM" will re-encode audio losslessly.

QuoteThat is will I loose quality everytime I recut it or only one time?

You need to re-encode only once to a different codec (I'm not sure that Opus is a good choice from the compatibility point of view).

Quote- is there a way to keep LPCM audio format?

I'll look into it regarding the MKV muxer.

attila

Hi,

Which audio codec do you suggest? (from a compatibility point of view)

What about if I select a lossy codec at first encoding, then "copy" after subsequent encodings: will it be reencoded? (binary file is different if I compare it with "diff" command, but I don't know the file format internals) Only one or two cuts are expected one after the other. The basic quality recorded from the VHS is not too great so small deterioration is not critical at all.

Does it have any importance if I use mpeg as output format with AC3 audio if I select a lossy audio format? (does mpeg have any advantage/disadvantage compared to mkv?)

Thanks.

Attila

eumagga0x2a

Quote from: attila on April 02, 2020, 05:45:19 AM
Which audio codec do you suggest? (from a compatibility point of view)

From the compatibility point of view, the video should be H.264 (deinterlaced prior to re-encoding!) and audio AAC.

QuoteWhat about if I select a lossy codec at first encoding, then "copy" after subsequent encodings: will it be reencoded?

"Copy" does not re-encode, but it may trim the ends of stream as well as at cutpoints.

QuoteDoes it have any importance if I use mpeg as output format with AC3 audio if I select a lossy audio format? (does mpeg have any advantage/disadvantage compared to mkv?)

MPEG (MPEG-2, I hope) is a legacy codec (necessary when you would like to make a video DVD), mkv is a container to hold all kinds of multimedia stuff. So the question should be, what are you going to do with the final result? What is the target device?

If you want to make a DVD, MPEG-2 + AC3 is fine, but the container must be MPEG-PS, not MKV.

If you don't want to make a DVD, MPEG-2 is a bad choice. I hope, you still have the original file to convert the video to H.264 or, depending on your target device, HEVC.

attila

Quote from: eumagga0x2a on April 02, 2020, 09:25:34 AM

From the compatibility point of view, the video should be H.264 (deinterlaced prior to re-encoding!) and audio AAC.

How can I deinterlace it before reenconding?

Quote
"Copy" does not re-encode, but it may trim the ends of stream as well as at cutpoints.

Audio streams have also such entities as keyframes in videos?

Quote
MPEG (MPEG-2, I hope) is a legacy codec (necessary when you would like to make a video DVD), mkv is a container to hold all kinds of multimedia stuff. So the question should be, what are you going to do with the final result? What is the target device?

If you want to make a DVD, MPEG-2 + AC3 is fine, but the container must be MPEG-PS, not MKV.

If you don't want to make a DVD, MPEG-2 is a bad choice. I hope, you still have the original file to convert the video to H.264 or, depending on your target device, HEVC.

Target devices are mostly computers and "smart" TVs.

If the video stream is copied and audio is kept lossless: does it have any importance whether I reencode them now or sometime in the future when mpeg2 is not working anymore? (there may be some better codecs in 5-10 years and it may be faster with more powerful CPUs :)  )

So currently I think the easiest and fastest choice for me is to keep mpeg2 video, convert sound to AAC (lav?) and save it in MKV container.

eumagga0x2a

Quote from: attila on April 02, 2020, 05:30:14 PM
Quote from: eumagga0x2a on April 02, 2020, 09:25:34 AM

From the compatibility point of view, the video should be H.264 (deinterlaced prior to re-encoding!) and audio AAC.

How can I deinterlace it before reenconding?

Not in a separate step, but add a good deinterlacing filter (this amounts on Windows to Yadif) when re-encoding – only if the source video is interlaced, of course. While the input in case of VHS is always interlaced, a device used to digitize the video signal might theoretically perform deinterlacing too.

A far better solution would be to use a lossless or even uncompressed format for video during the digitizing step to avoid a second lossy compression, but such a video may fill hundreds of gigabytes of storage for a short movie.

Quote
Quote
"Copy" does not re-encode, but it may trim the ends of stream as well as at cutpoints.

Audio streams have also such entities as keyframes in videos?

Like video, but consisting of keyframes only (in most cases). Cut points here are video cut points, which means that audio stream from the deleted portion of video is skipped too.

QuoteTarget devices are mostly computers and "smart" TVs.

Nowadays, modern "smart" TV accept almost everything. Regarding computers, both MPEG-2 and AC3 may be not optimal as DVD playback infrastructure on Windows isn't included anymore (but easily compensated by using FFmpeg-based players).

QuoteIf the video stream is copied and audio is kept lossless: does it have any importance whether I reencode them now or sometime in the future when mpeg2 is not working anymore?

No, it doesn't. If you can play the video and storage is not a concern, there is no need to re-encode.

QuoteSo currently I think the easiest and fastest choice for me is to keep mpeg2 video, convert sound to AAC (lav?) and save it in MKV container.

If your TV is able to play the MKV when you select "PCM" as encoder and disk space is plentifully available, use PCM. Or wait until I find time to look into MKV muxer support for LPCM in Avidemux.

eumagga0x2a

The MKV demuxer is now aware of LPCM audio format: [demuxers/Matroska] Support LPCM audio tracks.

Future Avidemux nightlies will allow to edit MKV files with LPCM audio.

attila

Thank you very much (also for your suggestions).

attila

I finally had time to try it.

If I open a file created with previous Avidemux in previous Avidemux:

=====================================================
Audio
=====================================================
Codec: Unknown codec
Channels: Sztereó



If I open the same file with last nightly build (200430)

=====================================================
Audio (1 active track(s))
=====================================================
Codec: LPCM


If I open the original file with nightly build:

=====================================================
Audio (1 active track(s))
=====================================================
Codec: LPCM


If I open the original file with previous version:

=====================================================
Audio
=====================================================
Codec: LPCM


If I open the file created with nightly build in previous version:

=====================================================
Audio
=====================================================
Codec: Unknown codec


Same file in nightly build:

=====================================================
Audio (1 active track(s))
=====================================================
Codec: LPCM




The original file in VLC:

Kodek: DVD LPCM Audio (lpcm)

The created file in VLC (created either with previous, either with nightly build):

Kodek: twos


With the nightly build I can cut files created with both nightly build and previous version, but with the previous version I cannot cut files created with the nightly build. So I think something is not copied 1-1 (see codec information: there is a track number in case of the file create with the nightly build but there is no track number in case of the original file and VLC displays different information).
It seems for me that something changes in the format/structure in the cut files compared to original file the same way in previous version and nightly build (the code update changed nothing in the process of creating files, only when reading them).
So my question is: are  the files created correctly or may there be an error which could cause some problems in the future?



eumagga0x2a

Just leave older builds out of equation. They are not supposed to magically rectify themselves with regard to LPCM in MKV just because the issue has been fixed in the current code.

The file properties dialog was enhanced to include the number of active track a while ago to ease support. Before that, there was no help from the properties dialog to undertand why saving to e.g. mp4 failed. Now you get a clear hint that there are more audio tracks, probably using incompatible codecs.