Constant crashes with 2.6.7 and m2ts file

[mean]

Might mean that something is changing in the stream
e.g. progressive<->interlaced or similar

[AQUAR]

A bigger sample might be needed to encompass the issues.

[LonelyPixel]

I said that re-muxing the m2ts file to a ts file (not changing the streams) did not help for Avidemux to be able to handle it any better. Then I added that demuxing the m2ts file, processing the streams with software other than Avidemux (specifically x264.exe) and muxing it into mkv then did work.

[AQUAR]

Interesting!
I didn't know that x264 accepts a packetised elementary stream (PES) as input.

Just curious if you followed the process through to completion.
And in doing so were able to maintain video to audio sync.

By process I mean:
- extracting the elementary streams,
- transcoding the video and audio payloads, using different software,
- placing/muxing each transcoded payload into a new program stream or transport stream container,
- and finally remuxing both streams into an MKV multimedia container (different method for providing time information).

[LonelyPixel]

Yes, that actually worked! I was kind of surprised, too, but I certainly have less experience than you.

I used tsmuxer to get the elementary streams (redusing dts-hd to dts), transcoded the video from vc-1 to x264 with x264.exe, transcoded the audio from dts to ac3, muxed it with mkvmerge (along with subtitles) and got a perfectly working and synced mkv file. I needed to manually set the video frame rate when muxing, as it wouldn't be transported, but otherwise it works fine.

I'm just waiting for some input on my 2-pass-or-not question on doom9, before proceeding with more videos. But this has worked on 2 or 3 videos already.

PS: In case somebody with sufficient German (or Google Translate) skills comes along and wants to know more, here's what I've found: http://www.voodooalert.de/board/index.php?page=Thread&threadID=17784

[mean]

Normally you should be able to do it with just avidemux
Ifever you have a sample small enough, i'd be interested

[AQUAR]

@ LonelyPixel
Pity I don't know German as that looks like a comprehensive and informative guide.

Amazing so much "metadata" timing information is retained in one form or another.

One other item of interest - when you eventually do view the whole clip, see if there any frames that look like they have interlacing artifacts?
It might provide a clue for why Avidemux is not working.

Now I definitily don't have much experience. Instead your issue and solution helps me and others.
I think, video issues like these are an interesting opportunity to learn a bit about video processes in a less abstract way.

Hopefully you find a way to cut a problem section as a sample for mean.
   

[LonelyPixel]

I've compressed a part of one video with different CRF values now, to compare it with the original file. In this process I've carefully compared several still frames and did not notice any interlacing effects anywhere. The original material is 1080p.

[mean]

Seems it is a quirk of the compiler
I've changed a little bit how it is done, seems to work
Version is building at the moment : 8987

Make sure you remove the .idx2 file before trying

[AQUAR]

Thanks,

If there are interlaced portions in the stream they may be constructed from film derived progressive frames.
Meaning no interlacing artifacts. It was worth asking in case there was some interlaced video (time displaced fields!).

Looks like mean has found his own VC-1 encoded sample and is on to the issue.
Try it again once the new nightly has been compiled.

[LonelyPixel]

Pity I don't know German as that looks like a comprehensive and informative guide.

But it's also a bit outdated. It says that transcoding VC-1 with x264 requires Avisynth which is not the case anymore.

I see the new version is built and will try it out later.

[LonelyPixel]

Oh, and did I mention that cancelling _anything_ in Avidemux basically leads to a crash every time? Don't ever press a "Cancel" button there, it means "Crash".

[LonelyPixel]

Okay, here's the result: No change. The following issues remain in the new build (only 32 bit tested):

* Cancelling anything immediately crashes.
* Opening an m2ts file from within the BD structure takes as much time as it would index all files, not just the opened one. And then it indexes only 1min38sec. At least saving to mkv works as expected, not considering the length.
* Opening one single m2ts file and saving to mkv crashes. This time even with the file that worked before.

[AQUAR]

If the index file is incomplete then avidemux is going to have problems, as it relies on the index file to navigate these types of media files.
There can be many reasons for that but without a representative sample its hard to zero in on.
Maybe there is a demuxing issue or it is incomplete when separated from the blue ray disk?

When a media file causes avidemux to be locked into some "crash mode" I just delete the entire settings folder
to 'reset' avidemux. This may or not help so its just an action suggestion.
To make this easy, I use the nightlies, in portable mode, in a separate 'avidemux folder'.
This settings folder is then automatically created locally in this avidemux folder (in liu of the users application data).

Avisynth plus its meriad of plugins is a super tool for workarounds.
Its why I suggested you try it with ffdshow, ie to decode the VC1 stream and frame serve avidemux.

[mean]

I think i've found the problem
It was not a compiler quirk but a real bug