No Audio - Results vary across two exact same runs
Posted: Sun Apr 29, 2007 5:03 pm
Note that the following was originally posted to the "NO AUDIO?..." topic in the support forum. Been over a week and no response from anyone so I'm cross posting here. Seems there's possibly some thread sync issue causing two exact same runs (same rip encoded from VIDEO_TS, same command line, same machine, same everything, one right after the other) to produce different output. Please read on and comment. I am willing to help but would rather not fly blind if someone can provide at least some insight first.
Been anxiously following this thread in hopes of a solution like everyone else present here. I am a developer but have no experience with Mac OS so I have been reluctant to get too involved, but with the release of 0.8.5b1 that is apparently still afflicted with audio drops I am compelled to try my hand at debugging. Let me apologize in advance for the length of this post.
First off, there has been a lot of back and forth speculation about whether the problems are with HandBrake or MTR (or any other ripping software). In my opinion it's apparent that it's a combination of both. Neither is to blame as evidenced by success in replacing either the encoder or the ripper in many cases, but because this is a HandBrake forum I would like to focus on HandBrake. This post would probably be more appropriate in the Bugs forum, but since this is the most relevant thread I'm posting here.
It's obvious that there are incompatibilities between the output of some rippers and versions of HB, and identifying those and enhancing HB to be more forgiving and robust will get us far. To minimize variables I have been experimenting with a specific point in a particular DVD rip where I have experienced audio drop with MediaFork and recent HB builds in an effort to identify what is going on at that point. Switching to the HB CLI solved the "extended" audio drop, but there was still a drop of about 1/2 second of audio at the same point where it used to drop out for the remainder of the movie with the GUI. From the verbose output of CLI it's apparent that the drop is related to "PTS discontinuity" and subsequent adding of silence buffers, but what really surprised me was that I was getting varying results on subsequent runs of the same CLI command on the same rip. Following are excerpts (complete logs are available) of the output during encoding for two such runs, the first resulting in no perceivable audio drop, and the second resulting in obvious drop of about 1/2 second.
$ ./HandBrakeCLI -i "/Users/Shared/DVDs/Toy Story 2" -o "/Users/chad/Desktop/Toy Story 2.mp4" -e x264 -q 0.7 -B 192 -c "2" -v
...
[08:05:17] sync: expecting 4907 video frames
[08:05:17] sync: first pts is 3442600
[08:05:17] sync: trashing late audio
[08:05:17] sync: trashing late audio
[08:05:17] sync: trashing late audio
[08:05:17] sync: trashing late audio
Encoding: task 1 of 1, 2.53 %[08:05:20] sync: trashing late audio
[08:05:20] sync: trashing late audio
[08:05:20] sync: trashing late audio
[08:05:20] sync: trashing late audio
[08:05:20] sync: trashing late audio
[08:05:20] sync: trashing late audio
[08:05:20] PTS discontinuity (3923077, 22733)
Encoding: task 1 of 1, 5.93 % (41.90 fps, avg 42.53 fps, ETA 00h01m49s)^CSignal 2 received, terminating - do it again in case it gets stuck
Encoding: task 1 of 1, 6.01 % (38.12 fps, avg 40.81 fps, ETA 00h01m53s)[08:05:24] reader: done
$ ./HandBrakeCLI -i "/Users/Shared/DVDs/Toy Story 2" -o "/Users/chad/Desktop/Toy Story 2.mp4" -e x264 -q 0.7 -B 192 -c "2" -v
...
[08:06:56] sync: expecting 4907 video frames
[08:06:56] sync: first pts is 3442600
[08:06:56] sync: trashing late audio
[08:06:56] sync: trashing late audio
[08:06:56] sync: trashing late audio
[08:06:56] sync: trashing late audio
Encoding: task 1 of 1, 2.53 %[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] PTS discontinuity (3923077, 22733)
[08:06:59] sync: adding 50 ms of silence for track 80bd
[08:06:59] sync: adding 50 ms of silence for track 80bd
[08:06:59] sync: adding 50 ms of silence for track 80bd
[08:06:59] sync: adding 50 ms of silence for track 80bd
[08:06:59] sync: adding 50 ms of silence for track 80bd
[08:06:59] sync: adding 50 ms of silence for track 80bd
Encoding: task 1 of 1, 5.71 % (41.13 fps, avg 41.90 fps, ETA 00h01m50s)^X^CSignal 2 received, terminating - do it again in case it gets stuck
Encoding: task 1 of 1, 5.83 % (41.13 fps, avg 41.90 fps, ETA 00h01m50s)[08:07:03] mux: file size, 617022 bytes
[08:07:03] mux: track 0, 400472 bytes, 279.32 kbps
[08:07:03] mux: track 1, 210725 bytes, 146.98 kbps
[08:07:03] mux: overhead, 7.61 bytes per frame
[08:07:03] thread 25273856 exited ("muxer")
[08:07:03] reader: done
Note the identical command lines. One would expect that because the input is static, the output would be identical in both cases. I am optimistic that this may direct us to the point in the code where the decision is made that results in audio drop vs. no audio drop. I have not attempted to delve into the code just yet. Would appreciate some comment from HB developers first to see if there some other reasonable explanation for this.
As a side, the hard work of all the HB developers and 3rd party contributors is much appreciated. This is a tremendous tool. Keep up the good work, and I hope to be able to contribute myself in the near future.
Been anxiously following this thread in hopes of a solution like everyone else present here. I am a developer but have no experience with Mac OS so I have been reluctant to get too involved, but with the release of 0.8.5b1 that is apparently still afflicted with audio drops I am compelled to try my hand at debugging. Let me apologize in advance for the length of this post.
First off, there has been a lot of back and forth speculation about whether the problems are with HandBrake or MTR (or any other ripping software). In my opinion it's apparent that it's a combination of both. Neither is to blame as evidenced by success in replacing either the encoder or the ripper in many cases, but because this is a HandBrake forum I would like to focus on HandBrake. This post would probably be more appropriate in the Bugs forum, but since this is the most relevant thread I'm posting here.
It's obvious that there are incompatibilities between the output of some rippers and versions of HB, and identifying those and enhancing HB to be more forgiving and robust will get us far. To minimize variables I have been experimenting with a specific point in a particular DVD rip where I have experienced audio drop with MediaFork and recent HB builds in an effort to identify what is going on at that point. Switching to the HB CLI solved the "extended" audio drop, but there was still a drop of about 1/2 second of audio at the same point where it used to drop out for the remainder of the movie with the GUI. From the verbose output of CLI it's apparent that the drop is related to "PTS discontinuity" and subsequent adding of silence buffers, but what really surprised me was that I was getting varying results on subsequent runs of the same CLI command on the same rip. Following are excerpts (complete logs are available) of the output during encoding for two such runs, the first resulting in no perceivable audio drop, and the second resulting in obvious drop of about 1/2 second.
$ ./HandBrakeCLI -i "/Users/Shared/DVDs/Toy Story 2" -o "/Users/chad/Desktop/Toy Story 2.mp4" -e x264 -q 0.7 -B 192 -c "2" -v
...
[08:05:17] sync: expecting 4907 video frames
[08:05:17] sync: first pts is 3442600
[08:05:17] sync: trashing late audio
[08:05:17] sync: trashing late audio
[08:05:17] sync: trashing late audio
[08:05:17] sync: trashing late audio
Encoding: task 1 of 1, 2.53 %[08:05:20] sync: trashing late audio
[08:05:20] sync: trashing late audio
[08:05:20] sync: trashing late audio
[08:05:20] sync: trashing late audio
[08:05:20] sync: trashing late audio
[08:05:20] sync: trashing late audio
[08:05:20] PTS discontinuity (3923077, 22733)
Encoding: task 1 of 1, 5.93 % (41.90 fps, avg 42.53 fps, ETA 00h01m49s)^CSignal 2 received, terminating - do it again in case it gets stuck
Encoding: task 1 of 1, 6.01 % (38.12 fps, avg 40.81 fps, ETA 00h01m53s)[08:05:24] reader: done
$ ./HandBrakeCLI -i "/Users/Shared/DVDs/Toy Story 2" -o "/Users/chad/Desktop/Toy Story 2.mp4" -e x264 -q 0.7 -B 192 -c "2" -v
...
[08:06:56] sync: expecting 4907 video frames
[08:06:56] sync: first pts is 3442600
[08:06:56] sync: trashing late audio
[08:06:56] sync: trashing late audio
[08:06:56] sync: trashing late audio
[08:06:56] sync: trashing late audio
Encoding: task 1 of 1, 2.53 %[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] sync: trashing late audio
[08:06:59] PTS discontinuity (3923077, 22733)
[08:06:59] sync: adding 50 ms of silence for track 80bd
[08:06:59] sync: adding 50 ms of silence for track 80bd
[08:06:59] sync: adding 50 ms of silence for track 80bd
[08:06:59] sync: adding 50 ms of silence for track 80bd
[08:06:59] sync: adding 50 ms of silence for track 80bd
[08:06:59] sync: adding 50 ms of silence for track 80bd
Encoding: task 1 of 1, 5.71 % (41.13 fps, avg 41.90 fps, ETA 00h01m50s)^X^CSignal 2 received, terminating - do it again in case it gets stuck
Encoding: task 1 of 1, 5.83 % (41.13 fps, avg 41.90 fps, ETA 00h01m50s)[08:07:03] mux: file size, 617022 bytes
[08:07:03] mux: track 0, 400472 bytes, 279.32 kbps
[08:07:03] mux: track 1, 210725 bytes, 146.98 kbps
[08:07:03] mux: overhead, 7.61 bytes per frame
[08:07:03] thread 25273856 exited ("muxer")
[08:07:03] reader: done
Note the identical command lines. One would expect that because the input is static, the output would be identical in both cases. I am optimistic that this may direct us to the point in the code where the decision is made that results in audio drop vs. no audio drop. I have not attempted to delve into the code just yet. Would appreciate some comment from HB developers first to see if there some other reasonable explanation for this.
As a side, the hard work of all the HB developers and 3rd party contributors is much appreciated. This is a tremendous tool. Keep up the good work, and I hope to be able to contribute myself in the near future.