ffmpeg with MPEG to TY+ encoding support

[phat_bastard]

Hell, for that matter what would be wrong with specifying these things as command line arguments? The mechanisms for this are already in place.

[BTUxNine]

I don't think adding more xml handling to ffmpeg is the best idea... among other things, the farther you stray from ffmpeg, the more issues in keeping the patch up to date.

I'd propose an alternative... leave the xml stuff out of ffmpeg completely, and write a program to add/modify the xml at the end... should be trivial enough to do in most scripting languages

[phat_bastard]

I checked and it looks like they made some cosmetic changes that make 1 of the hunks fail to apply. I would suggest using an older SVN revision. I'm currently on 5510. So you could just use '-r 5510' during checkout.

Same result. No matter though.

I added the bounding characters to my xml templates and the tags that I was concerned with work just fine with tivoserver using the appended xml method. Guess btu's comments incited an unwarranted panic in me.

The lack of bounding characters is probably why I was never able to get xml working with mplex.

[T u r b o]

The ffmpeg patch works much better for me than the modified mplex did. Nice work!

I know this isn't 100% on topic here but you guys are familiar with the mpeg code in ffmpeg. I have some VOB files that incorrectly identify their aspect ratio in the MPEG video stream. This causes my TiVo to display them letterboxed.

Can anyone provide some insight into the best place to put a routine to patch the aspect ratio before it gets written out to the .ty file?

Also, I'm running on Mac OSX and could contribute a patched ffmpeg binary (PPC) if anybody is interested.

EDIT: Oh yeah I meant to add that I'm using -vcodec copy to avoid re-encoding the video. If I use -vcodec mpeg2video and -aspect 4:3 it works as expected.

[shstevens]

Same result. No matter though.

I added the bounding characters to my xml templates and the tags that I was concerned with work just fine with tivoserver using the appended xml method. Guess btu's comments incited an unwarranted panic in me.

The lack of bounding characters is probably why I was never able to get xml working with mplex.

I am still having trouble with XML appending (see my post here http://www.dealdatabase.com/forum/sh...1&postcount=42 for more details please).

I believe I have added the boundry characters correctly, but the XML is still failing to read. This is the last hurdle I have in using this awesome new option. It has made a really big difference to me and I am grateful.

Thanks,
Shawn

[bcc]

Same result. No matter though.

Not sure what you mean. If you check out rev. 5510 of the svn source, the code should patch cleanly.

On supporting an XML related config file, or command line features: I think this is too much XML featurism for a program that is supposed to just be a multiplexor/demultiplexor/format converter. It made sense to me to provide minimal XML support, as some XML objects cannot be left unupdated or unset after a remultiplex, without introducing problems. Those are included in the ones already dynamically updated by the XML support.
Basically I agree with BTUxNine. However if one was to remove XML support from ffmpeg, the post processing to update the dynamic objects wouldn't be as trivial as suggested. To compute the Duration object's value, you have to go back to the recording and look at the elapsed time in seconds.

I added the bounding characters to my xml templates and the tags that I was concerned with work just fine with tivoserver using the appended xml method.

Glad you got it working

[bcc]

I have some VOB files that incorrectly identify their aspect ratio in the MPEG video stream. This causes my TiVo to display them letterboxed.

Sounds like you want dvdpatcher. I'm sure you could hack ffmpeg to do the same - have at it if you want.

[phat_bastard]

Not sure what you mean. If you check out rev. 5510 of the svn source, the code should patch cleanly.

Still the same problem. Now it works, not sure what I did differently. Whatever it was, the world is better off without my meddlings in C.

On supporting an XML related config file...

Nevermind my rantings about that. I took btu's comments to mean that tivoserver would balk at the way the dynamic xml is appended to the template xml. It doesn't, so no problem to solve.

The only thing I thought was off and needed to be fixed was the need for bounding characters in the template xml. I've read and searched here quite a bit trying to get the xml stuff working in mplex and never saw anything that suggested the need for bounding characters. I'm guessing that's why I never got mplex to insert my xml. I modded my converter script in about two minutes to conform to this requirement.

At any rate, thanks for all your work on this. You've saved me lots of CPU cycles, gigs of disk space and the frustration of watching the shimmer / jitter caused by de-interlacing. I can now mux stuff directly in about 2 minutes that used to take an hour or more re-encoding. I'm still seeing a lot of instances where the skip ahead button takes you back to the beginning of the stream, but since I can cut the commercials and still have flawless playback of all my interlaced DVB-S rips, I'm more than happy to adapt the wife to using the ffwd button.

I'm guessing the trick play issue is related to something you mentioned about ffmpeg rounding timestamps. I'm not complaining, but if you're insterested - if I try to convert directly from the interleaved source instead of demuxing the elementary streams I see rafts of this:

error, pts < dts

and this:

error, non monotone timestamps 9714705 >= 9714705

in my logfiles, and if ffmpeg manages to finish the mux process then playback is horrendous. If I demux using external tools all is well, so I'm happy either way.

[bcc]

Those look like legit gripes about how the timestamps in your recordings are layed out. I wonder what format you're feeding to ffmpeg (mpeg, .ts), and what you used to multiplex the streams before ffmpeg. Looks like whatever multiplexor it was, it might have been having the same sort of problem as mplex was with variable fields per frame. Passing elementary streams to ffmpeg avoids this problem as it leaves it up to ffmpeg to generate the timestamps instead.

As for your trick play issues, I've still not seen enough info to do more than continue to speculate. I wonder if you're only seeing an issue on these special case dvb transfers.

[T u r b o]

Sounds like you want dvdpatcher. I'm sure you could hack ffmpeg to do the same - have at it if you want.

Yeah I've written C code to patch the mpeg headers that's no problem, I was really just inquiring if you had any input on where the patching should occur since you're (significantly) more familiar with ffmpeg than I am.

[bcc]

Well I would think the clean thing would be to add a video codec to libavcodec that patches the video headers without causing a reencode. Thankfully I didn't have to dig into libavcodec much so I don't really have much experience with it.

[phat_bastard]

...I wonder what format you're feeding to ffmpeg (mpeg, .ts), and what you used to multiplex the streams before ffmpeg. Looks like whatever multiplexor it was, it might have been having the same sort of problem as mplex was with variable fields per frame.

It's all mpeg program stream; the newer tivo rips came out of TyTool10r4 and the dish stuff was muxed with either womble's mpeg-vcr or PVRExplorer Pro. The only reason I tried this out was to save a few minutes in conversion, but it's probably better to demux prior to ffmpeg since it gives me the opportunity to drop unwanted audio tracks. The demuxer I use does a pretty good job of finding the correct audio delay (or video delay) as well.

Passing elementary streams to ffmpeg avoids this problem as it leaves it up to ffmpeg to generate the timestamps instead.

As for your trick play issues, I've still not seen enough info to do more than continue to speculate. I wonder if you're only seeing an issue on these special case dvb transfers.

Yes, this is only happening with hybrid (interlaced / progressive) source. Since the playback is flawless, my vote is not to worry about it since there's almost no need for the trick play buttons. If you're just really bored or have some other reason to look into it, you can test with the source ty file of the sample I sent you back when you located the issues in mplex.

[bcc]

I've uploaded a new version, 1.4. Changes:

• xml markers now optional for -x, better diagnostics for xml rewrite
• Diagnostic logging to stderr to match ffmpeg
• Fix frame rate processing when frame rate specified via command line (-r)

[bcc]

I've updated the checkout instructions so that it's obvious how to checkout the SVN revision from which the diffs were made (no conflicts from changes made to the mainline after my diffs were generated).

[rbautch]

I'm not complaining, but if you're insterested - if I try to convert directly from the interleaved source instead of demuxing the elementary streams I see rafts of this:

error, pts < dts

and this:

error, non monotone timestamps 9714705 >= 9714705

in my logfiles, and if ffmpeg manages to finish the mux process then playback is horrendous. If I demux using external tools all is well, so I'm happy either way.

I get similar errors, but only on high-def program streams extracted, edited, and vob-muxed with tytool. The problem goes away when I use the "Multiplex (new format) 2" option, but this vintage post leads me to believe that's not the best solution. Splitting the files with tytool resulted in an m2a audio stream that ty-ffmpeg didn't recognize. I'll try a few more options/variables and report back.

edit: I demuxed a tytool-created program stream with tmpgenc, and the resulting elemental streams worked fine with ty-ffmpeg. I can't notice any quality differences between this, the stream that was muxed with "Multiplex (new format) 2" in tytool, and the original recording.

edit2: Washing the tytool-created program stream through Videoredo also fixed the timestamp issue. Think I'll start using Videoredo to make my cuts.