Dropped frames: 7mn out of a 2h movie!

[nodarkthings]

Please detail your question or problem in as much detail as possible:
Hi!
My TV provider uses 2 main .ts streams for each channel, both in MPEG4 720 x 576:
- Standard : 18 Mb/mn; audio#1 MPEG1/2 48K/192 kbps; audio#2 128 kbps
- Low ('bas débit' in French): 14.2 M Mb/mn; audio#1 & audio#2 AAC 48K/"variable" (64 kbps?)
Handbrake deals perfectly with the Standard stream but drops uncountable frames on the Low one, resulting in actually 7mn lost out of a 2h movie and numerous cuts that make the sound incomprehensible — be it with mkv or mp4, or any other settings I've tried.
Strange enough iFFmpeg has no problem with both blends...

Tell us about your environment. What version of HandBrake? What version of OSX are you running. etc.
Last version of HandBrake. OSX 10.9.5. I convert the original .ts streams in .mkv or .mp4, using the French audio channel or the English one.

If there was any exception or error displayed, please copy it and paste it here:
No error displayed.

Please include the scan or encode log:

http://pastebin.com/eb23j5YJ

[JohnAStebbins]

Could you try a nightly build please? Some improvements were made in the nightly builds that may help with issues such as this.

[nodarkthings]

Thanks for your answer. I've already tried the last nightly build to no avail.
(HandBrake-20160314002439-20b5485-master-osx.dmg)

[JohnAStebbins]

Could you post the log for the nightly build? And if you could post a small sample of your video, I can have a closer look at it to see if it is something that is fixable.

[nodarkthings]

Unfortunately I've deleted the offending files once I succeeded in converting them with iFFmpeg, sorry.
I'm trying with another one and in this case the nightly build drops far less frames than the last release, you're right!
I think those "Low" streams are pretty irregular and the audio part is the problem: even if iFFmpeg is able to convert them (video and audio together), when I tell it to keep the audio track intact, I obtain an .mp4 file that gives an error when opened in QuickTime!

encode log (just the beginning) with release:
http://pastebin.com/eUrf7MxL

encode log with nightly:
http://pastebin.com/wYYMJrsM

Are the remaining "dropped frames" something normal or the sign that there's a problem with the file?

[nodarkthings]

Hi John!
Here we go again: another example of the same problem with another recording.
http://pastebin.com/h7th0cWJ

I first controlled with the release version and it was indeed full of "sync: audio 0x425 time went backwards 258 ms, dropped 6 frames".

So, shall I consider the remaining dropped frames something normal?
If you still want me to send you an excerpt of the video, can you tell me, based on the log, which part I must select?
(and did you mean the original video or the converted one? )
Thanks a lot, anyway!

[JohnAStebbins]

It appears that it starts having trouble pretty much immediately. So if you can provide the first 10 seconds of the clip, I can have a look and see what is causing it.

[nodarkthings]

Here are the first 20s of the original video (cut with MPEG Streamclip, I couldn't think of another app to cut .ts without conversion, by the way: do you know of a better one?):
https://ln.sync.com/dl/6c2b94e70#epmz4y ... h-22ummwqk
And those 20s converted with Handbrake (latest Nightly):
https://ln.sync.com/dl/cea06f890#mv6pcg ... 5-taj4e3zf

[nodarkthings]

Hi John!
Did you find anything worthy in those files? Is there any hope to see this issue fixed or is it a flaw of those streams I have to live with?

[JohnAStebbins]

Hi John!
Did you find anything worthy in those files? Is there any hope to see this issue fixed or is it a flaw of those streams I have to live with?

Yes. It's just a problematic file. The main problem is that it doesn't conform to the transport stream specification for PCR spacing. The PCRs are placed too far apart which triggers HandBrake to think there has been a stream discontinuity when there isn't one. Your file has them spaced about every 300ms and the spec says they must be no further than 100ms apart. So every 300ms, HandBrake is attempting to "fix" a stream discontinuity. The logic to correct stream discontinuties makes a "best guess" where in the timeline the next packets are, but it really is a guess and it results in these synchronization problems when the guess isn't good enough.

I'm working on some sync changes that allows us to make a much better guess. It's an idea I've wanted to try for a couple years now. But it's a big code change and I never got up the energy to dive into it until recently. I've tested it on your sample, and it results in a flawless encode, even with the discontinuity processing every 300ms. So as long as I don't run into any insurmountable problems or side effects with the changes, we should have a solution for these kinds of files in the not too distant future.

[nodarkthings]

Wonderful! I'm really happy if I could contribute to this thing. Thanks a lot for your explanation.
If you ever need other samples to make other tests, just let me know!