Bug: Wrong FPS (r8473)

[Spellbinder]

Do I have to activate something or so? Because I encoded the sample clip with r8488 and it has the same FPS/Bitrate problem

[mean]

Could encode a small piece and look at the log ?
Especially the stats part

[mean]

ah yes, with your sample does not work
Give me 10 mn

[mean]

Partially fixed, but if the file is 10 sec of big bang theory, it is really broken
You'll have seeking issue

[Spellbinder]

Well, encoding the sample with r8489 worked. But like you said, I now have seeking issues with ALL files from OTR (www.onlinetvrecorder.com). I dont think this is right. Cutting them always worked before. I used copy mode, but then only rough cuts at I-Frames where possible. Thats why I started looking into Re-Encoding them with avidemux to get clean cutpoints. Is it possible to keep the way during cutting like before, and just for encoding purposes use the new method you introduced?

[mean]

I'll add a popup to ask what to do
MP4 files contain extra info about timestamps
In some cases (twinsun) they are slightly incorrect
In your files, they are completely non present, so the timing infos are  confusing

[styrol]

But like you said, I now have seeking issues with ALL files from OTR (www.onlinetvrecorder.com). I dont think this is right. Cutting them always worked before.

What files are you talking about? OTR provides AVI and MP4 output.

[Spellbinder]

Yes, OTR provides AVI. But this AVI is not seeable in Avidemux:

http://rapidshare.com/files/389249004/original.avi

So I convert the AVI to MP4 with FFMPEG (and convert the sound to AAC in the same process):

ffmpeg version: ffmpeg version N-44459-g8bdba0b (but had the same issue with older versions as well)

ffmpeg -i source.avi -map 0 -vcodec copy -acodec aac -strict experimental -sn output.mp4

http://rapidshare.com/files/741355935/convertedtomp4withaac.mp4

This new MP4 was now seekable (r8473). In the new version (r8490) it is not seekable anymore.

I made some encoding tests with this two versions and both files:

r8473 from avi -> Encoding ok (but no cutting possible due to seeking issue)
r8473 from mp4 -> Encoding FPS and Bitrate not ok
r8490 from avi -> Encoding ok (but no cutting possible due to seeking issue)
r8490 from mp4 -> Encoding ok (but no cutting possible due to seeking issue)

http://rapidshare.com/files/779518298/test_h264_r8473_frommp4.mp4
http://rapidshare.com/files/2031841724/test_h264_r8473_fromavi.mp4
http://rapidshare.com/files/2794200367/test_h264_r8490_fromavi.mp4
http://rapidshare.com/files/1155139932/test_h264_r8490_frommp4.mp4

Is there any way to make these files seekable so that you can cut them? Encoding seems to be ok now.

Thanks!

[mean]

The only option would be to rederive the timestamps, which is a bit slow
That's why storing h264 in avi is not a good idea : seek  & a/v sync does not work well as there is not enough timing informations
Since the infos were not there in the avi, ffmpeg could not create them for the mp4
So you end up with a MP4 including bad timing informations

If OTR directly provides mp4s, and if they contain valid timestamp informations it's probably the best to use

[Spellbinder]

Unfortunately OTR provides the files this way

- But why was my converted MP4 seekable before and now isnt any more?

- Is there some way to "rebuild" the time index?

- You mentioned something about a popup in this case thats askes what to do (like the trust/no trust option). I did not encounter something like that with these files. Is it in?

[styrol]

ffmpeg -i source.avi -map 0 -vcodec copy -acodec aac -strict experimental -sn output.mp4

This are my settings (posted in another thread)...

If OTR directly provides mp4s, and if they contain valid timestamp informations it's probably the best to use

Yep, MP4 are provided, but for premium users only (and in this case the commercials are already cut out, so you don't need Avidemux anymore). But there are some OTR HQ records only provided as AVI.

- But why was my converted MP4 seekable before and now isnt any more?

Yep, that's the point. I will check this next time I get an AVI from OTR. I've indeed given up using Avidemux for cutting AVI files, I use MPEG Streamclip for this task. MPEG Streamclip (actually Quicktime) has no problem to read (or guess) the timestamps correctly.

[Spellbinder]

I made some tests with r8492. Now I get the popup that asks if I want to keep the timing information or not. If I keep them encoding has wrong FPS/Bitrate. If not Encoding is ok but file is not seekable. Is it possible to keep the timing information for seeking/cutting and than drop it for encoding?

[Spellbinder]

The only option would be to rederive the timestamps, which is a bit slow

Could you do that please? By adding an option to the popup (keep/discard/rederive) for example.

[mean]

I have to check how long it would take
If it take 30mn to rederive it is not an option

[Spellbinder]

Even if it would take 30minutes I would take it

Especialy if I can automate it with the CLI