pyTivo Discussion Forum

[Iluvatar]

[rdian06]

Try the build from this post:

http://pytivo.krkeegan.com/post3687.html#3687

I disabled the monotone check completely in that build so that wgw could test with his problem sources and after reading some developer comments that the test they use is incorrect (i.e. presentation timestamps are allowed to be out of order within a block, it's the display timestamps that aren't and the check is not taking that into account.)

As for the spawning multiple ffmpeg's and locking up the computer, I've never had that happen.

Hoping to get some time to put together new builds and finish up the x86 Mac ones this week.

[Iluvatar]

That would be the build I have used and am still getting the monotone errors on a few h264 mp4 vids. Although it happens much more rarely now though, as other videos such as mkv's that produced the error are no longer doing it at all. The only thing I can do right now is download a different version of the same video. Thanks for all your efforts in these builds. It is much appreciated.

[ercdvs]

Out of curiosity, since i always build my own ffmpeg.. what is the fix for the channel mapping switch?

Its been driving me nuts with my own manual encoding, but I haven't done any extensive testing on pyTivo transfers to see if its still present. Its almost caused me to abandon ffmpeg for mencoder to remap channels during encoding.

[stevetony]

I'm on Windows, and the zip contains an executable, ffmpeg.exe. However, the C:\Program Files\pyTivo\plugins\video directory has ffmpeg_mp2.exe in it and no ffmpeg.exe. Does it go somewhere else? Does one replace the other, do I just add the new one to the directory? I'm not sure what the procedure is here.

Any help appreciated, thanks!

[wmcbrine]

The difference in names is of no import. They're both ffmpeg. Just make sure your pyTivo.conf points to the one you want to use.

I believe the "_mp2" was originally there to indicate that it supported MPEG-I Layer 2 audio, which I guess wasn't (isn't?) standard in ffmpeg builds at one time. (?)

[lordbah]

[rdian06]

Thats a process control issue in the pyTivo code I think. When ffmpeg can't handle the video, pyTivo doesn't detect it correctly and keeps trying to restart it without properly killing the previous instance.

[rdian06]

Trying to build a new ffmpeg using the latest SVN is proving a daunting task. The latest SVNs what a MinGW runtime of 3.15 or higher and Win API 3.12 or higher, meaning I have to upgrade my whole build environment plus recompile a bunch of libraries rather than just using Gianluigi Tiesi pre-built stuff.

At least I'll learn a bunch of stuff in the process...

[KevinSartori]

rdian06, will we be seeing a new build from you based on ffmpeg 0.5? I'm curious, do you still have to implement the 5.1 audio fix or was that fixed on their end?

[rdian06]

I'm not sure. I haven't had time to try it.

Also, my wife is rearranging our house so my 5.1 setup is currently in storage so testing is going to take me a while.

Sorry. I'll get to it eventually, but there isn't anything really pressing at the moment since the 96 build from a few posts up seems to work decently.

[elsteve]

I there a 96 build for linux (Ubuntu8.1) floating around somewhere? If not, I'd be happy to compile my own if you could point me towards sources...

Thanks!

[rdian06]

Archived - Windows

* ffmpeg-SVN-r18820-rdian06-0.97-win32-x86_32.zip (Download below.)
- Compiled 2009-05-15 00:18:12
- Based on ffmpeg trunk
- Drop libvorbis in favor of ffmpeg native Vorbis encoder
- Drop libfaad in favor of ffmpeg native AAC decoder
- Includes my libfaad.c patch (see http://pytivo.krkeegan.com/post6913.html#6913) for 5.1 channel mapping fix when transcoding AAC to AC3
- MKV timestamp improvements that enable smooth playback of certain encodes that resulted in choppy playback in previous versions
- Timestamp precision improvements that seem to fix the non-monotone timestamp fatal error that caused premature end of transfer or no transfer at all for some Xvid encodes

[rdian06]

Ffmpeg Patches

Diff were last created against SVN-r21659 unless otherwise noted.

* patch-libavformat-matroskadec.c-r21659.diff
Fixes "non-monotone timestamps" fatal errors encountered when remuxing AC3 audio from problematic MKVs to VOB. Root cause was the MKV demuxer not bothering to parse the bitrate for AC3 audio tracks. This patch forces the MKV demuxer to parse format headers for AC3 and EAC3. See https://roundup.ffmpeg.org/issue807

* patch-libavcodec-ac3dec.c-r21659.diff
Patches the AC3 decoder to ignore full audio frames when an error is encountered inside one of the constituent audio blocks (audio frames are made up of multiple blocks.) This avoids bad audio blocks throwing off the whole AC3 stream and producing muffled audio when transcoding AC3 to AC3. NOTE: This does NOT fix all muffled audio scenarios with the native fffmpeg AC3 decoder, but since the Matroska remuxing fix above makes the need to transcode AC3 to AC3 less frequent - you're a lot less likely to encounter the remaining muffled audio scenarios.

* patch-ffmpeg.c-r21659.diff
Patched the status output display line to stay less than 80 characters under normal usage and avoid filling the console with status lines.

* patch-libavformat-utils.c-r21659.diff
- Changes the timestamp monotonicity error check to be > instead of >=. Every once in a while I end up with a video that causes ffmpeg to report "error, non monotone timestamps XXX >= XXX" though it will play fine in VLC/Mplayer. This change allows ffmpeg to process the file properly when the timestamps are equal. A fatal error will still be reported if the current timestamp is greater than the next one. This helps with remuxing some MKV to MP4 as well and is still needed despite the matroskadec.c patch.

* patch-libavcodec-libfaad.c-r21659.diff
- Fixes 5.1 channel mapping by converting the AAC output order ( FC, FL, FR, SL, SR, LFE ) to SMPTE aka WAV order ( FL, FR, FC, LFE, SL, SR ) in libavcodec/libfaad.c
- This is a patch to the ffmpeg glue code for libfaad, NOT to libfaad itself.
- To use this patch you must:

1. Compile libfaad2 and make it available to ffmpeg configure.
2. Pass --enable-libfaad AND --disable-decoder=aac to ffmpeg configure

If you fail to disable the ffmpeg native AAC decoder, it will be used for AAC decoding effectively bypassing libfaad.

* patch-libavcodec-aac.c-rdian06-0.97.diff
- Fixes 5.1 channel mapping by converting the AAC output order ( FC, FL, FR, SL, SR, LFE ) to SMPTE aka WAV order ( FL, FR, FC, LFE, SL, SR ) in libavcodec/aac.c. Diff created against SVN-r18820.

NOTE: The forum doesn't allow .diff extensions so I've tacked .txt on the end of each of these.

[rdian06]

Mac PowerPC G5 and Windows x86_32 builds of ffmpeg 0.98 are up along with the patch that was used to create them (for those who want to roll their own Linux build.)

Working on Mac Intel x86 build. I use MacPorts to build the Mac binaries now so I just need to get my 10.5 Intel environment setup and bring the Portfiles over to complete the compile. Hopefully in a few days...