recorded dvd from tv oftentimes don't convert to mp4

General questions or discussion about HandBrake, Video and/or audio transcoding, trends etc.
Post Reply
wdurk
Posts: 1
Joined: Fri Jul 27, 2007 12:30 am

recorded dvd from tv oftentimes don't convert to mp4

Post by wdurk »

i record a film or tv show with my dvd recorder... i then load the dvd into my m 2.16 core duo with 2 gb and handbrake works sometimes and then fails other times... i am very confused... there can't be protection on the disks which play perfectly on my mac and dvd player... why won't they convert uniformly to my ipod... very confused... advice would be greatly appreciated... file size is below 4 gb and i have varied the disk types... thanx for any help...
eddyg
Veteran User
Posts: 798
Joined: Mon Apr 23, 2007 3:34 am

Re: recorded dvd from tv oftentimes don't convert to mp4

Post by eddyg »

wdurk wrote:i record a film or tv show with my dvd recorder... i then load the dvd into my m 2.16 core duo with 2 gb and handbrake works sometimes and then fails other times... i am very confused... there can't be protection on the disks which play perfectly on my mac and dvd player... why won't they convert uniformly to my ipod... very confused... advice would be greatly appreciated... file size is below 4 gb and i have varied the disk types... thanx for any help...
Are you using Mac The Ripper to copy the DVD onto your hard drive before running HB? If not then try that.

Cheers, Ed.
jbrjake
Veteran User
Posts: 4805
Joined: Wed Dec 13, 2006 1:38 am

Post by jbrjake »

I'm going to guess your dvd recorder uses MP2 audio.

If so, then these disc will rip in the next release of HandBrake.
TimW
Posts: 5
Joined: Wed Jul 25, 2007 3:57 am

Post by TimW »

I'm getting a similar problem with both the current public release, and with one I built a couple of days back. In my case (it isn't clear if this is exactly the same as the OPs problem) I get only the first few minutes (or, more annoyingly, all but the last few minutes 8^) converted okay.

The conversion of the bit that worked seems clean and it plays okay but it is truncated. Handbrake's progress reports/bar all seem okay whilst it is running but then, all of a sudden, it seems to stop prematurely, with the bar at, say, 10% but the exit is clean.

I had a look at the debug window but I don't know enough for it to be meaningful to me. Bearing in mind my ignorance, my best guess is that a problem with the reception causes something like the zero cell problem, or at least a glitch in the stream that Handbrake doesn't like.

I have successfully used several other encoders to re-encode the stream but none that I like as much as Handbrake 8^). But at least this shows that there may be a solution.
jbrjake
Veteran User
Posts: 4805
Joined: Wed Dec 13, 2006 1:38 am

Post by jbrjake »

TimW wrote:I had a look at the debug window but I don't know enough for it to be meaningful to me.
The whole idea behind having debug output in the GUI is so that when you don't know what it means you can share it with us...
TimW
Posts: 5
Joined: Wed Jul 25, 2007 3:57 am

Post by TimW »

jbrjake wrote:The whole idea behind having debug output in the GUI is so that when you don't know what it means you can share it with us...
I wasn't in a situation where I had time to capture it but I can reproduce the problem so should be able to post the debug output later.
TimW
Posts: 5
Joined: Wed Jul 25, 2007 3:57 am

Post by TimW »

Here is the promised debug output. The CHECK_VALUE trace is repeated many times before this but I didn't think you'd want all of them...

There are some other lines of output which aren't CHECK_VALUE before here but they have long gone by the time we get to this.

Code: Select all

*** libdvdread: CHECK_VALUE failed in nav_read.c:207 ***
*** for dsi->dsi_gi.zero1 == 0 ***


*** libdvdread: CHECK_VALUE failed in nav_read.c:207 ***
*** for dsi->dsi_gi.zero1 == 0 ***

DVD: End of Cell
[23:19:18] dvd: DVDReadBlocks failed (50331649)
[23:19:18] reader: done
[23:19:18] thread 34536448 exited ("reader")
[23:19:22] Reader has exited early, inserting silence.
[23:19:22] sync: adding 50 ms of silence for track c0
[23:19:22] sync: got 19633 frames, 73679 expected
[23:19:22] Reader has exited early, inserting silence.
[23:19:22] sync: adding 50 ms of silence for track c0
[23:19:22] Reader has exited early, inserting silence.
[23:19:22] sync: adding 50 ms of silence for track c0
[23:19:22] Reader has exited early, inserting silence.
[23:19:22] sync: adding 50 ms of silence for track c0
[23:19:22] Reader has exited early, inserting silence.
[23:19:22] sync: adding 50 ms of silence for track c0
[23:19:22] thread 34044416 exited ("MPGA decoder (libavcodec)")
[23:19:22] thread 34628608 exited ("MPEG-4 encoder (libavcodec)")
[23:19:22] thread 34164736 exited ("MPEG-2 decoder (libmpeg2)")
[23:19:22] thread 34164736 joined ("MPEG-2 decoder (libmpeg2)")
[23:19:22] thread 34868224 exited ("AAC encoder (libfaac)")
[23:19:22] thread 34557952 exited ("Renderer")
[23:19:22] thread 34557952 joined ("Renderer")
[23:19:22] fifo_close: trashing 0 buffer(s)
[23:19:22] thread 34628608 joined ("MPEG-4 encoder (libavcodec)")
[23:19:22] encavcodec: closing libavcodec
[23:19:22] thread 34044416 joined ("MPGA decoder (libavcodec)")
[23:19:22] thread 34868224 joined ("AAC encoder (libfaac)")
[23:19:22] thread 34536448 joined ("reader")
[23:19:22] mux: file size, 111316110 bytes
[23:19:22] mux: track 0, 98532741 bytes, 1003.75 kbps
[23:19:22] mux: video bitrate error, +367741 bytes
[23:19:22] mux: track 1, 12561336 bytes, 127.96 kbps
[23:19:22] mux: overhead, 4.15 bytes per frame
[23:19:22] thread 34495488 exited ("muxer")
[23:19:22] thread 34495488 joined ("muxer")
[23:19:22] fifo_close: trashing 0 buffer(s)
[23:19:22] fifo_close: trashing 0 buffer(s)
[23:19:22] fifo_close: trashing 0 buffer(s)
[23:19:22] fifo_close: trashing 0 buffer(s)
[23:19:22] fifo_close: trashing 0 buffer(s)
[23:19:22] fifo_close: trashing 0 buffer(s)
[23:19:22] fifo_close: trashing 0 buffer(s)
[23:19:22] fifo_close: trashing 0 buffer(s)
[23:19:22] fifo_close: trashing 2 buffer(s)
[23:19:22] thread 34513920 exited ("work")
[23:19:23] thread 34513920 joined ("work")
[23:19:23] libhb: work result = 0
TimW
Posts: 5
Joined: Wed Jul 25, 2007 3:57 am

Post by TimW »

As an experiment, I tried to use MPEG Streamclip to create a ts file with all of the timecode fixing options set to on (Fix streams with data breaks and with Preserve frames at In/Out both on and off). With last nights SVN build I was able to read the ts file but the encoding only used 20% of the CPU and was incredibly slow. In order to get something to report in the timescale I had, I tried using Streamclip to make an MPEG and then Toasted it to a DVD image. With this, I can get to the end of the file but there are huge skips so that the file is less than half as long as it should be and about 20 mins of the programme is missing in the middle.

Is it possible to get a faster encode from a TS? I can try with the Streamclip TS file, then. It may be that the fix-ups don't survive the MPEGging and Toasting.
CarlA
Posts: 6
Joined: Thu Aug 23, 2007 4:18 am

Re: recorded dvd from tv oftentimes don't convert to mp4

Post by CarlA »

eddyg wrote:
wdurk wrote:i record a film or tv show with my dvd recorder... i then load the dvd into my m 2.16 core duo with 2 gb and handbrake works sometimes and then fails other times... i am very confused... there can't be protection on the disks which play perfectly on my mac and dvd player... why won't they convert uniformly to my ipod... very confused... advice would be greatly appreciated... file size is below 4 gb and i have varied the disk types... thanx for any help...
Are you using Mac The Ripper to copy the DVD onto your hard drive before running HB? If not then try that.

Cheers, Ed.
Although I have a different configuration on my iMac, 2GHz and 1.5 GB, I have the same problem. I used Mac The Ripper on the original disk and then used DVD2oneX2 to burn the files to a new disk. This did not work and HB can not convert the programs on the new disk to MP4 files either.
pfurrie
Posts: 30
Joined: Wed Sep 19, 2007 3:39 am

Post by pfurrie »

I'm getting similar results, with the latest Windows version (0.9.1, GUI build 2.4.1). I have a DVD which I burned, with four half-hour recordings of my own material (in other words, no DRM), and I've used RipIt4Me to get the first of the four recordings on to my hard drive. Then I used HandBrake to do a generic MP4 or H264 transcode. The CLI window showed a bunch of "libdvdread: check_value failed in nav_read.c:207" messages running up the screen, very fast. I suspect this is slowing down the overall performance of the program, and don't know if this has any other impact on the way the program operates.

Any idea what it means?
PuzZLeR
Bright Spark User
Posts: 287
Joined: Tue Apr 24, 2007 4:01 am

Post by PuzZLeR »

The Mods are right about people not doing enough searches and I feel like I typed this answer about a half dozen times.

Sigh... but here goes...

HandBrake seems to have problems with "home brews". I know about that error (that may be harmless) that pops up a million times a minute as well, etc. I too use a DVR to capture television and VHS content and my discs don't work "fluidly" in HandBrake.

It's not a copy-protect issue obviously. It's an MPEG-2 issue.

The truth is that many MPEG-2 encoders out there are not "true" MPEG-2 encoders. Upon examining these streams, you will notice much instability - time stamp errors, GOP issues, etc. This is not as common on the commercial DvD products, but will occur for home DVRs and even burning apps like Nero.

These "errors" are no big deal at all at the consumer level where only simplistic objectives are needed - playback, homemade simple DvDs, etc. However, when you want to use this content for more complex projects, like encode to H.264 (our case) you will have problems.

The only solution, and one that I employ often is rip out this MPEG-2 content, demux the audio and video streams, correct them with an app like ProjectX (Windows), edit if you have to, then remux, and author to a new VIDEO_TS folder with a lossless and reliable app (such as TMPGEnc Author on Windows) and input that into HandBrake instead - directly from your hard drive - and it will encode beautifully.

...and that's your answer for probably the tenth time on this forum for homemade DvDs...

...when I get around to it I'll create a guide for this, and if the Mods like it, it may be a helpful stickie...
dynaflash
Veteran User
Posts: 3820
Joined: Thu Nov 02, 2006 8:19 pm

Post by dynaflash »

PuzZLeR wrote:...when I get around to it I'll create a guide for this, and if the Mods like it, it may be a helpful stickie...
Maybe, provided anyone reads it :?
pfurrie
Posts: 30
Joined: Wed Sep 19, 2007 3:39 am

Post by pfurrie »

Thanks for the info. Sounds like a lot of steps to go through to help speed up the transcode of something which *seems* to transcode already.

FWIW, I had done a search on Google for "libdvdread: check_value failed in nav_read.c:207" which is fairly specific. A search for it in the HandBrake forum turns up a bunch of hits, and the first is this thread. I started check others in succession, but doing a text search within them for "libdvdread: check_value failed in nav_read.c:207" would turn up nothing, so I gave up after several of those... if the most "relevant" choices were at the top of the list (not necessarily, but thinking perhaps), then the first hit was the only real one. Back on Google, I did a "site:handbrake.m0k.org libdvdread: check_value failed in nav_read.c:207" search, which limits the Gooogle search to just the HandBrake site, and a handful of results came up (which all had the "libdvdread: check_value failed in nav_read.c:207" search term in them). However, I don't think I saw your name in any of them, nor anything similar to the suggestion you made.

I understand sometimes it is frustrating answering the same question over, but sometimes we don't all search for the same things you might... and "libdvdread: check_value failed in nav_read.c:207" seemed like a good thing to look for when "libdvdread: check_value failed in nav_read.c:207" was the error popping up.
PuzZLeR
Bright Spark User
Posts: 287
Joined: Tue Apr 24, 2007 4:01 am

Post by PuzZLeR »

Hey Pfurrie,

Here's some info if you want to read further. They may not be clear as day, but they do come up in a search.

http://handbrake.m0k.org/forum/viewtopi ... highlight=
http://handbrake.m0k.org/forum/viewtopi ... highlight=
http://handbrake.m0k.org/forum/viewtopi ... highlight=
http://handbrake.m0k.org/forum/viewtopi ... highlight=

and here's an audio/video sync thread that may help in this context:
http://handbrake.m0k.org/forum/viewtopi ... 7927#17927

That error that concerns you I believe is not a big deal really. I'm not sure what the CLI is trying to say, but it may be some harmless warning. HandBrake will still encode it, and I have found nothing wrong with the resultant MP4 files.

However, just to be safe, here's a quick Windows outline of what should be done with "home brews" and other potentially problematic sources (I wish I knew the corresponding apps on a Mac...):

1) Rip to MPEG-2 (TMPGEnc MPEG Editor, NeroVision, etc.)
2) Demux with ProjectX.
3) Remux (TMPGEnc, Imago, and plenty of others). Or if you're using an editor here's where you do your edits if your editor can handle separate streams.
4) Author a new VIDEO_TS folder from the new content. Use a lossless app like TMPGEnc Author. No menus, or burning necessary since this is only for HandBrake input.
5) Input into HandBrake and encode.

Yeah, I know it's a few extra steps but you will have minimal problems and headaches (and you get to do some editing along the way if you want to). It's been worth it for me having many, many GB of 100% trouble-free content when much of it is from personal projects.
eddyg
Veteran User
Posts: 798
Joined: Mon Apr 23, 2007 3:34 am

Post by eddyg »

I wonder what would happen if we ignored the PTS on the audio packets and instead just encoded them in line with where they were read from the stream?

That may overcome some of the issues.

Although the nav pack parsing error is part of the dvd reader libraries sanity check and isn't ours to play with.

Cheers, Ed.
Post Reply