Encoding with nightly build produces incomplete file

[kurtunderhay]

Please describe the problem in as much detail as possible:
Using the nightly build (20160424121951-7060fac-master (2016042901) - 64bit Version), encoding produces an incomplete file.
Encoding the same source with the latest release version produces a complete file.

What are the steps to reproduce this problem:
Select source.
Use Normal profile.
Specify output filename.
Set seconds "from" and "to" around the problematic timestamp (just to reduce log information, encoding of full title produces the same results).
Add to queue.
Start queue.

What version of HandBrake you are running:
HandBrake 0.10.5.0 - 64bit Version
HandBrake Nightly 20160424121951-7060fac-master (2016042901) - 64bit Version

What operating system and version and you running (e.g. OSX 10.11, Windows 7, Ubuntu 14):
Windows 7 Home Premium 64bit

Please include the scan or encode log:

Release version scan log:

Code: Select all

 http://pastebin.com/auYSXnz1 

Release version encode log:

Code: Select all

 http://pastebin.com/k8UfD9rg 

Nightly activity log:

Code: Select all

 http://pastebin.com/JMAVyQRv 

[rollin_eng]

Your source has errors and it looks like 0.10.5 was able to skip the error but the nightly is stopping on it.

While sometimes one might be preferred over the other the best solution is to try to fix your source.

Try ripping your source to disk first.

[kurtunderhay]

Source already ripped to disk, encoding from directory on hard disk produces same result.
I have no control over the source. Sure the source may contain an error, I think probably the general expectation is that if the source is complete and playable the encoded file should be complete and playable (I don't want to start a flame war with this speculation on popular opinion but I think it's a fair statement). As you say, 0.10.5 can skip it and continue and produce a result which matches what happens when playing the source.

[rollin_eng]

What are you using to rip your disk?

[kurtunderhay]

I don't really want to enumerate the tools that I'm using here but the result is the same whatever tool is used.
Does it matter though? I think the relevant point here is that the encode works OK with 0.10.5 but not with nightly, using the same source.

[rollin_eng]

Not really, you cant really expect the software to work with every piece of rubbish thrown at it.

Just because a previous version did the wrong thing by ignoring it you want to keep that bug in the software?

Now could there be options to skip/ignore errors, maybe, but they might take a ton of work to code/test/implement.

So its easier to prefer non-broken input.

[s55]

Regardless of your oponion, it's ultimately up to the Dev team on how we handle errors / reports.

I'll let John comment if he wishes since he is redoing the sync engine at the moment. It may even fix or handle the problem better.

[kurtunderhay]

Not really, you cant really expect the software to work with every piece of rubbish thrown at it.

Just because a previous version did the wrong thing by ignoring it you want to keep that bug in the software?

Now could there be options to skip/ignore errors, maybe, but they might take a ton of work to code/test/implement.

So its easier to prefer non-broken input.

Agreed it's easier to prefer non-broken input - users don't always have this level of control over the input though. Arguably it's easier not to write any of this code at all.
And yes agreed, if a previous version had a bug it shouldn't be retained in later versions just because that's how earlier versions worked.
I don't think this can be argued as a bug though or necessarily as wrong handling in v0.10.5, it's difficult to position it as desirable behaviour that 93 minutes of perfectly fine video should be dropped just because of a problematic frame or two, which frames are handled just fine by an older version of the software and by software and hardware media players too. The source disk with the same frame/continuity problem plays fine albeit with a very small jump, the ripped disk plays exactly the same, and the output from 0.10.5 plays exactly the same as the original source. It's not graceful, elegant or desirable to discard the remaining 93 minutes because of a single frame continuity issue, and it's not necessary either as we can see in the output from 0.10.5.

In any case I spotted a difference between nightly and release, the output of nightly in my opinion not being desirable and I reported it.

[rollin_eng]

Obviously as s55 said its up to the devs (and even then it might not be as the libs they use may force them to do certain things).

And while you don't mind a dropped frame or 2 other people might, and that very small jump can create many problems that aren't aware to the end viewer.

As you don't want to mention what ripper you use another option might be to remux your source which might help fix your broken input.

[mduell]

I don't really want to enumerate the tools that I'm using here but the result is the same whatever tool is used.
Does it matter though?

Yes. Some tools stop on errors, some fix errors, and some pass them on. Toolchain is critically important.

[kurtunderhay]

Take it as stipulated that the dropped frames exist in the source. I can't imagine any user would rather have 93 minutes of missing video, than a video output as framewise-complete as the input with the same dropped frames as the source.

The ripping toolchain is not relevant - multiple different tools produce exactly the same output as each other, as disk image, straight uncompressed unmuxed MKV and rip to folder. Output from ripping is bytewise identical to source disk barring the possibility of an SHA-3 collision.

The underlying issue is the treatment of imperfect source, which treatment from the perspective of user expectation in 0.10.5 is acceptable and in nightly is not.

[rollin_eng]

The ripping toolchain is not relevant - multiple different tools produce exactly the same output as each other, as disk image, straight uncompressed unmuxed MKV and rip to folder.

Can you encode your mkv and post the log, i'm curious if the error is the same, thanks.

[mduell]

The underlying issue is the treatment of imperfect source, which treatment in 0.10.5 is acceptable and in nightly is not.

The behavior with a broken source is regarded as undefined, so I doubt you're going to find much support here for getting a specific behavior for your broken sources.

[s55]

Again, that's for the development team to decide. So please, leave stuff like this for a formal response.

[kurtunderhay]

Updated previous reply to clarify position.