converting .TS to MP4 with ffmpeg and tiling problems

[snagglewest]

So, I got my channels scanning problem fixed (thanks Sub!) and figured out the network shares with some help from Martin.

I'm using several WDHDTV boxes (wireless) on the other TVs for remote viewing and the WDHDTV works well with wireless, but it is picky about file types. I'm not sure if it's the file types, or the wireless speed, but I've found that it handles MP4 without complaint. Anyhow, my solution is to convert the .TS to MP4 with ffmpeg and then copy the new file to the network share which is visible to all the WDHDTV boxes. I'm using a ffmpeg routine:

ffmpeg -y -i "%~f1" -f mp4 -vcodec libx264 -deinterlace -s 704x384 -acodec copy -ar 22050 -qmax 8 "%~dpn1.mp4"

These files get played on just some small, run of the mill, TVs which are 704x384 so I've down converted and reduced the audio a bit to make the file smaller. Nothing really fancy, but it seems to work.

The problem is the MP4 files occasionally tile. The .TS files play fine in NPVR and it's not every converted file, just some. This happens even when played back on the same machine as NPVR is installed so it's not network/wireless related. while testing the conversion in a local DOS window, I've noticed I'm getting a number of errors from ffmpeg.

I've attached a copy of about 1000 lines of the DOS window while running ffmpeg. The errors are mostly these types:

[mpeg2video @ 020DBA20] invalid cbp at 0 35
[mpeg2video @ 020DBA20] mb incr damaged
[mpeg2video @ 020DBA20] ac-tex damaged at 0 42
[mpeg2video @ 020DBA20] slice mismatch
[mpeg2video @ 020DBA20] concealing 7560 DC, 7560 AC, 7560 MV errors
[mpeg2video @ 020DBA20] 00 motion_type at 20 9
[mpeg2video @ 020DBA20] invalid mb type in B Frame at 4 28

I've checked the signal quality with the HDHR utility and the signal looks good (at least to me)

The average for my channels are:
Signal Strength - 87% to 94%
Signal Quality - 100%
Symbol Quality - 100%

I know about nothing about file conversion, so I'm not sure if this is normal, or if there's something I can do to fix the tiling? It's not bad, at most 2-3 times in a 1 hour show and then only for a second or two. It's just enough to irritate the better half, especially when she watching her show and misses that important word or 2 in the dialog. And we all know, if she ain't happy, nobodies happy!

[ATTACH=CONFIG]31300[/ATTACH]

[Nistrod]

Welcome to the somewhat difficult world of WD HD TVs and NPVR.
Here is my current TS to MP4 command line:
[INDENT]

Code:

%FFMPEG% -y -async 48000 -i %ACTUAL%%SUFFIX% -vcodec libx264 -f ipod -threads 16 -fpre "%FFPRE%\libx264-ultrafast.ffpreset" -sameq -g 100 -crf 25  -ac 2 -ab 128k  %VERBOSE% %CONVERTED% >> %LOG% 2>&1

[/INDENT]
The "-f ipod" is significant, and solved the tiling problem. The resulting quality is OK, but could be better. I, too, do not know enough about transcoding to improve things.

This command fails on many files, due to "resolution change" errors. These are spurious (most of the new resolutions are bizarre). You can usually fix the original TS file with mpeg2repair.

As an alternative:
[INDENT]

Code:

%FFMPEG% -y -async 48000 -i %ACTUAL%%SUFFIX% -vcodec copy -acodec copy -threads 16 -sameq -ac 2 %VERBOSE% %CONVERTED%.avi

[/INDENT]
produces a good quality file, very quickly, most of the time.
This fails with non-monotonous timestamp errors on some files, however, making me switch to the mp4 for this file.

I would be delighted to know if you find a good solution!

[snagglewest]

Thanks for the info on mpeg2repair, I tried it out and it does take care of the errors. I noticed it turns all the "bad" blocks pure black which I guess "fixes" the block, but it makes them stick out like a sore thumb when there's a lot of them.

I think I figured out 99% of my problem though, I think it comes down to a CPU horsepower problem... I've noticed that the tiling problem is worst when I'm doing something on the computer while NPVR is recording. The last 2 days I've spent about zero time on the PC and the recordings have all been very good quality, with zero tiling. Even when run through mpeg2repair there's few errors. I'm going to play with it some more this weekend and really test out the theory, but it looks more and more like the MBis going to get that heart transplant with a Core 2 Quad Q9650 Yorkfield 3.0GHz.

I do have a question about your ffmpeg command line though, I notice you have "-threads 16" in both commands. The ffmpeg documentation is not very clear on what it does. I tried google but couldn't find anything that explains it.

[Nistrod]

I have a quad-core 3.something GHz machine. I was still getting tiling, until I put in the -f ipod. Yes, I realise that this makes no sense, but it worked. I was also doing the conversion manually, while nothing else was going on, using the same input file.
-threads speeds up the conversion by running multiple conversion threads. Your CPU usage goes up, your real conversion time goes down.
The most significant factor in conversion speed was disks. Write to a different disk than the input, and make that as fast as possible.

Try the AVI conversion. When it works, it gives a much better picture quality. Why are you converting the resolution? Surely your TV displays at the same as is broadcast? It is debateable what provides better resolution conversion - FFMPEG, the WD TV or your TV. Is 704x384 a common resolution in the US?