I've just started playing with Blu-Ray video files and found that it was very easy to shrink an m2ts to x264 with Avidemux. Well, that was the first video file. The second file on that disc causes a lot of pain. I already noticed that there were a few error frames at the beginning, but I could easily skip them in my ouput mkv file.
In the second video file, there are also random frames but I cannot skip them. Whenever I try to navigate to any time frame, it says it can't do that, and stays where it is. What is the index then good for? Also, when jumping to the beginning or end, the app just crashes. That's all I know.
Avidemux 2.6.7 32-bit, Windows 7 SP1 x64, no other anomalies known. What can I do to provide more details?
Also, I cannot open an m2ts file directly from the STREAM directory or it will take longer to index but only see 1m37s instead of the whole file (over 50 minutes). Copying the file elsewhere solves that problem at least.
PS: When I try to simply copy all streams without any trimming or converting, Avidemux crashes immediately when saving the output file. Again, that's all I know.
Update: For now, I can use Tsmuxer to "re-mux" the input m2ts file into a new ts file which then works fine in Avidemux. So probably, there's something in the Blu-Ray file container that first needs to be cleaned up before Avidemux an read it. Nevertheless, it would be nice to see when Avidemux could read it directly - and at least report problems with a meaningful message instead of plain crashing. But the latter seems to be the fate of native applications...
By remuxing the transport stream you are re-writing/interpreting video time stamps.
Avidemux relies on these time stamps and probably by remuxing you are fixing some issue.
Sometimes I use MKVToolnix to remux TS data into an MKV container (multimedia container) to 'recalculate' time stamp information.
Also noticed you posted the same on doom9.
When avidemux crashes on a particular file, one thing that may help is is to delete the avidemux configuration files (everything set back to default).
Umm, too bad. That helped for exactly one file. The third file crashes again, re-muxing doesn't help. Any ideas why this is so unstable?
You reset avidemux and it helped for one file?
Logically, if that file makes avidemux crash then a re-load of that file means you have just defeated the reset.
Why avidemux does that?
Think of it at a beta, that is almost stable, but reacting uncomfortably to a problematic file.
Have you tried the MKV remux with MKVmerge?
No, didn't delete anything. What should I delete? I just tried converting the next file and it failed. Loading previously successfully loaded files generally works.
Do you have any quick links for mkvmerge for me? Can't find anything useful without going on a very long search again.
If Avidemux is known unstable (I had that impression, too, but was surprised how well it worked this time), are there more reliable alternatives? Or is video editing in 2013 still as unstable as 15 years ago?
Its very stable with proper media files.
For mkvmerge try http://www.bunkus.org/videotools/mkvtoolnix/
I've converted the m2ts file to mkv now, with mkvtoolnix. The resulting file is of similar size and plays well in MPC-HC. While it does convert in Avidemux, the result is not satisfying. The frame rate is reduced to something varying around 15-20, from the original 23.9. Writing the mkv from mkv with Avidemux before, with no transcoding, doesn't help.
The source videos are all VC-1-encoded. Doesn't that always work?
VC1 is not so common, so not tested much
Oh, and it seems DTS is also a bit uncommon. It's entirely unsupported as well. That's on another disc I got today. So I guess I can forget about Avidemux for Blu-Rays anyway and need something else.
I dont have a sample for such file
If you can provide a short one ... (2mn is enough)
Its might be mixed interlaced / progressive, and maybe needs a M$ WMV decoder.
Not come across this type of codec either but it seems to be a difficult one to transcode.
Could try avisynth with ffdshow set to use wmv9 for decoding and avidemux for further recoding to whatever.
With a sample I could try.
Ripbot264 might have all the tools needed to do this via a GUI.
Is it VC-1 or DTS you didn't hear of? DTS is audio, seems to be equally common as DD (AC3).
Anyway, I've found that Tsmuxer seems to be pretty stable in demuxing things; x264 can easily transcode a VC-1 elementary stream (with not too many arguments), and eac3to should be able to transcode audio should I want to do that; and mkvmerge (mkvtoolnix) can mux it into an mkv file in the end. It's more hand work, but seems to be reliable for now.
Without an editor that can cut things, I'm afraid I can't provide you anything shorter than 8 GB. The smaller snippets on that disc don't cause any trouble in Avidemux.
Just cut the first 50 MEg or so
Doesn't work. I've cut the first 50 MB and the resulting file works fine in Avidemux. Plays, navigates everywhere, saves. You couldn't use it to reproduce the crash or any other observed problem.
Neither!
Such a question to the co-founder/creator of this video program is like "Teaching grandmother to suck eggs".
The sample asked for can be dissected for its complexities - something most endusers (like me!) are not able to do.
Maybe then, avidemux can be fine tuned so as to be able to edit this type of media file.
VC-1 is a ratified microsoft codec that seems to be gaining use on blueray disks.
It can have interlaced video fields plus interlaced video frames plus progressive video frames all as part of the one video stream.
Add container types, timestamps and DRM to the mix and it isn't surprising that there are issues with editing and transcoding these media files.
Now you implied that remuxing with Tsmuxer or MKVmerge didn't work for one of these .m2ts with vc-1 in it.
Are you now saying it does work, you are able to edit and transcode and your problem is resolved?
Might mean that something is changing in the stream
e.g. progressive<->interlaced or similar
A bigger sample might be needed to encompass the issues.
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.
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).
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
Normally you should be able to do it with just avidemux
Ifever you have a sample small enough, i'd be interested
@ 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.
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.
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
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.
Quote from: AQUAR on December 17, 2013, 12:37:07 AM
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.
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".
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.
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.
I think i've found the problem
It was not a compiler quirk but a real bug
Should be okay with 8988, win32 /64 built updated
@ LonelyPixel
If you try again with the bug fixed nightly, don't forget to delete the previously created idx2 index file first.
That way the video stream is parsed again to create a new index file.
Cancelling the indexing still crashes. Also, indexing seems to happen on the UI thread, competing with the message loop, so unresponsive as that window it. It even interrupts its work as long as I drag the window...
Indexing still fails in the BD directory (it sees 1:38 of it), I have to move the m2ts files elsewhere.
Muxing the first file works again. Cancelling also works here.
Playing, navigating and muxing the second and third file now also works. The third file can't navigate to the very end though, I had to drag the slider near the end and then skip second by second until I reached a few frames before the end. Didn't test transcoding.