Encode hangs up at end

[mkelley]

I'm trying an encode of an MT2S that keeps getting all the way through to 100% but then hangs up. The command line window stays open, it shows 00:00:00 at remaining time, but won't finish. The resultant file seems to be there except it won't advance or play properly (it will start playing but trying to move through it just hangs up).

The BR was ripped to my hard drive using AnyDVD HD. I first tried pointing it to the .MT2S stream on the rip, but when that didn't work (hung up) I used txMuxeR and deleted all but the one audio track I wanted and muxed down to another .MT2S file. Both those files play fine from my hard drive. As you can see, I'm using the Snapshot and will try the current release version next but I won't know those results until tomorrow morning, so if there is something obviously wrong here please let me know so I can try again.

Here's the activity log:

Code: Select all

### Windows GUI svn3036 2009121901 
### Running: Microsoft Windows NT 5.1.2600 Service Pack 3 
###
### CPU: Intel(R) Core(TM)2 CPU          6420  @ 2.13GHz 
### Ram: 2037 MB 
### Screen: 1280x720 
### Temp Dir: C:\Documents and Settings\Mike Kelley\Local Settings\Temp\ 
### Install Dir: C:\Program Files\HandBrake094Snapshot 
### Data Dir: C:\Documents and Settings\Mike Kelley\Application Data\HandBrake\HandBrake\0.9.4.5 
#########################################

[11:50:05] hb_init: checking cpu count
[11:50:05] hb_init: starting libhb thread
HandBrake svn3036 (2009121901) - MinGW i386 - http://handbrake.fr
2 CPUs detected
Opening F:\How_West_Won.m2ts...
[11:50:05] hb_scan: path=F:\How_West_Won.m2ts, title_index=1
[11:50:05] scan: trying to open with libdvdread
libdvdnav: Using dvdnav version 4.1.3
libdvdread: Encrypted DVD support unavailable.
libdvdnav:DVDOpenFileUDF:UDFFindFile /VIDEO_TS/VIDEO_TS.IFO failed
libdvdnav:DVDOpenFileUDF:UDFFindFile /VIDEO_TS/VIDEO_TS.BUP failed
libdvdread: Can't open file VIDEO_TS.IFO.
libdvdnav: vm: failed to read VIDEO_TS.IFO
[11:50:05] dvd: not a dvd - trying as a stream/file instead
[11:50:05] file is MPEG Transport Stream with 192 byte packets offset 4 bytes
[11:50:05] hb_ts_stream_find_pids - found the following PIDS
[11:50:05]     Video PIDS : 
[11:50:05]       0x1011 type VC1 (0xea)
[11:50:05]     Audio PIDS : 
[11:50:05]       0x1100 type AC-3 (0x81)
[11:50:05] transport stream pid 0x1100 (type 0x81) may be AC-3 audio (id 0x1)
[11:50:05] scan: decoding previews for title 1
[11:50:05] scan: audio 0x1: AC-3, rate=48000Hz, bitrate=640000 English (AC3) (5.1 ch)
Scanning title 1...
Scanning title 1...
Scanning title 1...
Scanning title 1...
Scanning title 1...
Scanning title 1...
Scanning title 1...
Scanning title 1...
[11:50:07] scan: 10 previews, 1920x1080, 23.976 fps, autocrop = 48/48/2/2, aspect 16:9, PAR 1:1
[11:50:07] scan: title (0) job->width:1936, job->height:992
[11:50:07] stream: 4 good frames, 0 errors (0%)
[11:50:07] libhb: scan thread found 1 valid title(s)
+ title 1:
  + stream: F:\How_West_Won.m2ts
  + angle(s) 0
  + duration: 02:33:23
  + size: 1920x1080, pixel aspect: 1/1, display aspect: 1.78, 23.976 fps
  + autocrop: 48/48/2/2
  + chapters:
    + 1: cells 0->0, 0 blocks, duration 02:33:23
  + audio tracks:
    + 1, English (AC3) (5.1 ch) (iso639-2: eng), 48000Hz, 640000bps
  + subtitle tracks:
Invalid sample rate 0, using input rate 48000
[11:50:07] 1 job(s) to process
[11:50:07] starting job
[11:50:07] sync: expecting 220688 video frames
[ac3 @ 0x15d7550]No channel layout specified. The encoder will guess the layout, but it might be incorrect.
[11:50:07] job configuration:
[11:50:07]  * source
[11:50:07]    + F:\How_West_Won.m2ts
[11:50:07]    + title 1, chapter(s) 1 to 1
[11:50:07]  * destination
[11:50:07]    + C:\Documents and Settings\Mike Kelley\My Documents\How The West was Won.mkv
[11:50:07]    + container: Matroska (.mkv)
[11:50:07]  * video track
[11:50:07]    + decoder: vc1
[11:50:07]      + bitrate 200 kbps
[11:50:07]    + frame rate: same as source (around 23.976 fps)
[11:50:07]    + strict anamorphic
[11:50:07]      + modulus: 0
[11:50:07]      + storage dimensions: 1920 * 1080 -> 1916 * 984, crop 48/48/2/2
[11:50:07]      + pixel aspect ratio: 1 / 1
[11:50:07]      + display dimensions: 1916 * 984
[11:50:07]    + encoder: x264
[11:50:07]      + options: ref=2:bframes=2:subq=6:mixed-refs=0:weightb=0:8x8dct=0:trellis=0
[11:50:07]      + quality: 22.00 (RF)
[11:50:07]  * audio track 0
[11:50:07]    + decoder: English (AC3) (5.1 ch) (track 1, id 1)
[11:50:07]      + bitrate: 640 kbps, samplerate: 48000 Hz
[11:50:07]    + AC3 passthrough
[11:50:07] reader: first SCR 53955000 id 0 DTS 53996246
[11:50:07] encx264: keyint-min: 24, keyint-max: 240
[11:50:07] encx264: encoding with stored aspect 1/1
[11:50:07] encx264: Encoding at constant RF 22.000000
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile Main, level 4.0
No accelerated IMDCT transform found
[11:50:07] sync: first pts is 3754

[mkelley]

I don't know if it will help, but I ended up taking the resultant file (after closing down Handbrake) which would not play properly in VLC and running it through txmuxer and making another M2TS file (not changing any of the streams or anything) and this new file does play properly. I'm not sure what Handbrake needs to do at the very end (perhaps set some sort of file indicators or something?) but whatever it doesn't add running the file through txmuxer does so I guess I'm happy (of course, I end up with an M2TS file instead of an MKV file, but I think I can change it back to an MKV container with MKVMerge if I really need to -- I have to test the M2TS file with my output device (Western Digital Live) but I think it will work just fine).

Just for fun I'm going to run this through .94 (assuming I can find it easily -- foolish me changed my Handbrake shortcut to the Snapshot thinking I'd never use .94 again :>)

[mkelley]

And just to finish all that I know, I tried it with .94 with the same results (hangup at end).

Upon further review (football season winding down) the file actually isn't complete even when I run it back through txmuxer -- it's about 99.5% there but is missing the last 10 or 15 seconds. I'm going to try using Ripbot to see if I have any better results, but it would be nice if Handbrake could handle this situation (the M2TS file seems otherwise normal and plays just fine in VLC as well as my hardware device -- it's just so darn BIG I'd like to use Handbrake to compress some).

[mkelley]

Ripbot had no problems with this file -- but Ripbot takes about two-three times as long to do its thing as Handbrake does (my guess is because it doesn't use the latest version of the X264 encoder. It's too bad that HB has a bug that keeps it from processing this M2TS file properly, because I'm going to guess that this won't be the last time I come across a file HB can't handle.

[creamyhorror]

Ripbot had no problems with this file -- but Ripbot takes about two-three times as long to do its thing as Handbrake does (my guess is because it doesn't use the latest version of the X264 encoder.

Ripbot264 is up to date with x264, so if it's significantly slower, it's probably because it uses higher-quality/slower x264 settings than Handbrake. You can modify the settings in Ripbot264 to speed them up, I believe (under an Advanced button IIRC?).

[mkelley]

Well, I have to admit I know almost nothing about Ripbot (whereas I'm pretty used to Handbrake). I used a "quality" setting under CR of 22, which is what I also used in Handbrake. IOW, both are ripped with one pass at constant rate with a Quality of 22. Both passed through the audio track, both were making MVK files.

Now i realize it might be impossible to compare the two in this manner, but I thought it would be at least close (and, as I said, it wasn't -- it took 18 hours for Ripbot, and under 8 for Handbrake although, as i said, HB never actually finishes even when it reaches 100%). If I knew more about Ripbot I could check to see if there was something (like interlacing) that was turned on that shouldn't be, but since both programs were mostly using default settings I'm not sure why one would be that far off it they are using the same encoding engine.

[mkelley]

I just looked at some guides for using Ripbot and it doesn't appear to me there is anything I could have turned on or off to speed things up. Since the recommended setting for quality is around 20 (resulting in an even longer encode, I'm sure) and the recommended setting for Handbrake (for BR) is around 22, I'm going to guess that Ripbot either isn't calling the X264 code correctly, or using old code, or something significant that makes it so much slower. I've looked at the quality for both ways (using HB and Ripbot on the same files) and there isn't any visual difference even in frame grabs. And since the audio is passed transparently there can't be any difference there. So unless I'm just crazy (possible :>) there isn't any other way to explain Ripbot's abysmal performance unless the authors really don't know what they're doing (or the Handbrake authors really do <g>).

I could think of one thing (note: not a graphical programmer here so WAY out of my league) -- perhaps the Handbrake folks are somehow taking advantage of dual (or more) processors whereas the Ripbot folks aren't. I am only using a dual processor (no quad here) but if somehow the ability to call the X264 routines can be done multithreaded and HB does this where Ripbot does not then I could see how this might account for ALL the difference between the two.

In any case, Handbrake has worked for me so far just fine... with this one file exception. Knowing how sharp the HB programmers are, I'm pretty sure they could fix the issue if they could somehow have a file that did the same thing (pretty obviously they aren't going to want to use my file).

[mkelley]

And yet still ANOTHER m2ts file hangs up on me in Handbrake. Sigh. If there's anything the two have in common is they are both True-HD tracks downmixed to AC3 (but otherwise the AC3 track is nothing special). I'm beginning to wonder if Handbrake just can't deal successfully with most m2ts files, particularly if they have an AC3 track (today I also successfully did an m2ts file but I passed through the DTS track).

I guess I'll have to use RipBot and live with the exceedingly crazy encoding times. Oh well, that particularly computer was just sitting around anyway <g>.

[nightstrm]

And yet still ANOTHER m2ts file hangs up on me in Handbrake. Sigh. If there's anything the two have in common is they are both True-HD tracks downmixed to AC3 (but otherwise the AC3 track is nothing special). I'm beginning to wonder if Handbrake just can't deal successfully with most m2ts files, particularly if they have an AC3 track (today I also successfully did an m2ts file but I passed through the DTS track).

I guess I'll have to use RipBot and live with the exceedingly crazy encoding times. Oh well, that particularly computer was just sitting around anyway <g>.

I have had zero problems with m2ts files in Handbrake, either directly from a Bluray disc, or remuxed with tsmuxer (HDDVD with TrueHD, or Bluray with DTS-MA that I had to convert to AC3 first). I think I've done 40 or so HDDVD or Bluary to AppleTV and iPhone encodes so far.

I'd suggest using the developer snapshot release if you aren't already as there were some issues with ffmpeg and vc1 sources that were corrected shortly after .9.4 was released.

[mkelley]

Thanks, but as because of your earlier advice I've been using the current Snapshot with these files that hang (so far both were remuxed with tsmuxer and both had True-HD I resampled with that program to AC3 and then both had the AC3 passed through in Handbrake). Remember, I'm making MKV files just in case you're making something else -- maybe it works for MP4s and not for MKVs?

I'm trying the second problematic file right now with Ripbot -- after all my badmouthing of that software I used the Handbrake advanced presets to change the Ripbot ones and it seems to be just as fast now, so if it works I guess I'm a happy camper. I will still use Handbrake when I can, but for now I'm going to assume that any m2ts file I make with txmuxer that has a True-HD track sampled down isn't going to work (because the only two I've tried so far haven't, whereas every other file, DTS or "normal" AC3 or just m2ts direct from the BR rip have worked just fine in Handbrake. And I like Handbrake a LOT better when it works -- it just seems so much more stabler than Ripbot).

[nightstrm]

Thanks, but as because of your earlier advice I've been using the current Snapshot with these files that hang (so far both were remuxed with tsmuxer and both had True-HD I resampled with that program to AC3 and then both had the AC3 passed through in Handbrake). Remember, I'm making MKV files just in case you're making something else -- maybe it works for MP4s and not for MKVs?

I'm trying the second problematic file right now with Ripbot -- after all my badmouthing of that software I used the Handbrake advanced presets to change the Ripbot ones and it seems to be just as fast now, so if it works I guess I'm a happy camper. I will still use Handbrake when I can, but for now I'm going to assume that any m2ts file I make with txmuxer that has a True-HD track sampled down isn't going to work (because the only two I've tried so far haven't, whereas every other file, DTS or "normal" AC3 or just m2ts direct from the BR rip have worked just fine in Handbrake. And I like Handbrake a LOT better when it works -- it just seems so much more stabler than Ripbot).

OK; I've never used the mkv container so I can't really help with that. You might already know this, but you do not have to run Bluray m2ts files with TrueHD soundtracks through tsmuxer first as Handbrake can extract the AC3 core from the TrueHD soundtrack just like tsmuxer does. For these discs, I just input the raw m2ts I extracted from AnyDVD HD into Handbrake. Not sure if it would change anything with your outcome, but might save you a few minutes in your process.

[mkelley]

Thanks, yes, I could see that Handbrake did that, but when it hung up on the first file the first thing I tried was txmuxer in an effort to give it a "clean" file to use. The second file that wouldn't work I used txmuxer because there were two video streams (I had never seen this before, but Underworld 3 had both a 1080p as well as a 720p video stream in the main file) and I wasn't sure if HB would choke on that or not -- didn't matter since it didn't like the txmuxer file anyway.

To be really sure I suppose I could run HB and make an MP4 just to see if it is the container but since I don't WANT an MP4 (can't play them with my device properly) I'd only be troubleshooting HB and unless and until one of the programmers here wants me to try that I think I'll just concentrate on getting my stuff ripped (I spent too many years debugging my own software to make that a priority now :>)