mythtranscode corrupting recordings when transcoding to MPEG4 (NUV->NUV)

[nate <svndotmythtvdotorg1@…>]

Have seen this behavior for about a week now. Currently at r26104 on the trunk.

When running mythtranscode on a HD recording using the "Low Quality" profile and MPEG4, I have had a number of corrupted recordings. The output file sizes are approximately 1/3 of their normal size for typical recordings. The audio appears fine, however all but a few sporadic frames of video are gone/corrupted.

Note: Some of these recordings may have been tagged for transcoding twice, i.e. mythtranscode has been run on them twice with the same settings. When picking shows for transcode, I sometimes accidentally re-transcode recordings, however this has never caused any issues in the past and typically results in an innocuous no-op. So this behavior might be specific to transcoding twice, I cannot tell for sure.

Perhaps an option allowing myth to skip transcoding shows that have already been transcoded could be added (will check the tickets if a request for this has already been made)

When playing one of the corrupted recordings, the frontend streams this output to the console:

[mpeg4 @ 0x70425c0] slice end not reached but screenspace end (70 left 7FE828, score= -3)
[mpeg4 @ 0x70425c0] concealing 3600 DC, 3600 AC, 3600 MV errors
[mpeg4 @ 0x70425c0] slice end not reached but screenspace end (70 left 7FBFA7, score= -3)
[mpeg4 @ 0x70425c0] concealing 3600 DC, 3600 AC, 3600 MV errors
[mpeg4 @ 0x70425c0] slice end not reached but screenspace end (70 left 7F9267, score= -3)
[mpeg4 @ 0x70425c0] concealing 3600 DC, 3600 AC, 3600 MV errors
2010-09-04 21:47:20.850 OSD: Base theme size: 1280x720
2010-09-04 21:47:20.850 OSD: Scaling factors: 0.85625x0.972222
[mpeg4 @ 0x70425c0] slice end not reached but screenspace end (70 left 7F2829, score= -3)
[mpeg4 @ 0x70425c0] concealing 3600 DC, 3600 AC, 3600 MV errors
[mpeg4 @ 0x70425c0] slice end not reached but screenspace end (72 left 7F2187, score= -3)
[mpeg4 @ 0x70425c0] concealing 3600 DC, 3600 AC, 3600 MV errors
2010-09-04 21:47:20.866 OSD: Base theme size: 1280x720
2010-09-04 21:47:20.866 OSD: Scaling factors: 0.85625x0.972222
[mpeg4 @ 0x70425c0] slice end not reached but screenspace end (66 left 6E0072, score= -3)
[mpeg4 @ 0x70425c0] concealing 3600 DC, 3600 AC, 3600 MV errors

[Kenni Lund [kenni a kelu dot dk]]

AFAIKT, it's playback related. I've uploaded a 20MB sample here: ​https://docs.google.com/leaf?id=0B-_nZameGeN-NTY5NGVjOGYtMDYzNS00Zjc4LWI3OGYtOTk2MzU4MzczZmVj&hl=da&authkey=CJv8zvAO

The sample plays with mythavtest on 0.23-fixes, but will fail 20-90% of time on trunk r26203. Mplayer doesn't have any issues with the sample. I'm attaching "mythavtest -v playback" logs from trunk.

All of my recordings are automatically transcoded by MythTV from MPEG2 (Hauppauge HW encoder) into MPEG4, so it should not be related to 2x transcoding, as I never trigger any manual transcodings.

[anonymous]

(Comment from Thursday which didn't post)

Hmm, I've seen this behavior as well during playback, but even for older MPEG4 recordings that I know have been transcoded correctly. Do you see a gray screen during playback when this happens? I think this is a separate issue, however, as the file sizes I am seeing after transcoding definitely indicate that something has changed recently with mythtranscode, and is perhaps causing explicit data loss (most likely after accidentally transcoding the same file twice). For example, for transcoded 720p recordings I have close to 700 recordings with a typical 50% reduction in filesize when going from MPEG2 to MPEG4. The recordings that appear corrupted are reduced about 70-80% in filesize after transcoding (most likely twice by accident). I am also using a Hauppage HW encoder.

[Kenni Lund [kenni a kelu dot dk]]

nate, your error description and log seems almost identical to the playback issue. Please check if you can playback the "corrupted" recording with mplayer - if you can't, I'll split up this ticket into two and cleanup the mess I've caused.

[nate <svndotmythtvdotorg1@…>]

Hi Kenni,

I can confirm that the corrupted recordings do not play in mplayer, and the corruption issue appears to be specific to transcoding the same recording using 'Low Quality / MPEG4' twice. I enabled the 'save original recording when transcoding option' and manually scheduled a new, good recording tonight for transcode to MPEG4. The first transcode worked correctly. I then scheduled the same recording for transcoding to MPEG4 once again. After the second transcoding, the resulting recording is corrupted and there is explicit evidence for data loss judging by the output filesize. So we can update the description to express that this is specific to transcoding twice.

But you are correct, in that these two issues might be related. If the MPEG4 decoding routines are common for both playback and transcoding, then it makes sense that if playback is affected then transcoding will be incorrect as well.

This might sound strange that one would transcode the same recording twice.. This situation arose because I currently have to manually schedule transcoding and I sometimes mistakenly do a recording twice in error. When I have previously done this by accident, the resulting transcode was fine (however the filesize obviously didn't change).

Thanks for your help.

[sphery]

nate, can you reproduce this issue after c4ee599818c8cfd in 0.24-fixes or 03cff208162 in master?

[sphery]

No response in 2 months. I'm assuming it was fixed by the above changes.

[stuartm]

Milestone 0.24.2 deleted