Opened 15 years ago

Closed 15 years ago

#2260 closed defect (fixed)

MPEG2->MPEG2 Transcode Errored

Reported by: thomas@… Owned by: Geoffrey Hausheer
Priority: minor Milestone: unknown
Component: mythtv Version: head
Severity: medium Keywords:
Cc: Ticket locked: no


mythtranscode errors on some files while transcoding MPEG2->MPEG2 with cutlist.

There was a discussion about this in the mailing list:

Since Geoffrey seems to be occupied or unavailable at the moment, I am opening this ticket, so that it will not be forgotten.

The essentials:

  • it happens with 0.19 and head
  • it only happens when mythtranscode is being called by mythbackend, not stand-alone
  • the recording is OK according to ProjectX, also I have unc=0 (DVB-C) -> no errors
  • so far (4 weeks with DVB), this happened with 3 recordings
  • one of the recordings is still available here
  • full debug log of the error:

Change History (12)

comment:1 Changed 15 years ago by cpinkham

Owner: changed from Isaac Richards to Geoffrey Hausheer

comment:2 Changed 15 years ago by cpinkham

Resolution: fixed
Status: newclosed

Believe this was fixed by [11330] relating to an AvFormatDecoder? issue with multiple video streams in the same file. Closing for now. If the problem can be reproduced with current SVN the ticket can be reopened.

comment:3 Changed 15 years ago by thomas@…

Resolution: fixed
Status: closedreopened

This issue is not fixed by [11330].

The problematic recording does not have multiple video streams, BTW.

comment:4 Changed 15 years ago by tephra@…

I am also having this problem - only recent 19.1 fixes + .20 has the problem.

Can we get more info out of mythtranscode somehow?

Cheers Dave

comment:5 Changed 15 years ago by thomas@…

Since 0.20, I get a mythtranscode error code on the status page, when this problem occurs: 235. Maybe, this helps.

comment:6 Changed 15 years ago by thomas@…

Now I have a recording (which also plays fine), where I can not workaround this problem (mythtranscode exits with status 235) by starting mythtranscode in the console. Either the problem is worse here or something changed with the latest 0.20 fixes updates. Full debug log of mythtranscode with cutlist:

comment:7 Changed 15 years ago by thomas@…

Addition to my last comment: When transcoding without cutlist, it works, but prints warnings:

2006-10-07 14:24:22.518 Frame 11 > 10. Corruption likely at pos: 445619784
2006-10-07 14:24:25.291 Frame 10 > 8. Corruption likely at pos: 469812940
2006-10-07 14:24:25.429 Frame 3 > 2. Corruption likely at pos: 469955444
2006-10-07 14:24:25.927 Frame 9 > 8. Corruption likely at pos: 472299240

comment:8 Changed 15 years ago by Geoffrey Hausheer

Are you saying you can reproduce this from the command-line now? if so, that would make it much easier for me to debug. In this last recording, can you give me a section of the recording from 547000000 through 557000000? I expect it will pass (needs a custom made cutlist) but (I think) I should be able to reproduce the issue from that section.

As for the Corruption issues, those are bad (it means that for some reason the frame number is higher than it is supposed to be...i.e. a frame is missing). As we don't know what kind of frame got lost, we are stuck until we see the next I-frame. This will add a glitch in your recording (it would have been there regardless), but is unlikely to have anything to do with the problem at hand.

comment:9 Changed 15 years ago by thomas@…

Yes, this time it happens also from the commandline, but I do not exactly know, if this is really the same error. I guess, if I move one cutpoint a little bit, it will pass. Anyway, here is the sample:

I hope, I did it right. I used: dd if=4736_20061002230500.mpg of=sample235.mpg skip=547000000 count=10000000 bs=1

comment:10 Changed 15 years ago by Geoffrey Hausheer

well, despite finding the correct cut-end frame, and sweeping the start frame, I couldn't reproduce on this sample. There is no easy way to locate a frame, so there isn't really an easy way to create a test case besides sending me the 1st 560MB of the stream (which is probably not the best idea, though if you have the bandwidth, I have the time). I find these issues infuriating. Can you run via the command line through gdb and send me back the back-trace (assuming it fails)? perhaps that would shed some light.

comment:11 Changed 15 years ago by thomas@…

It does not crash in gdb, so I have no backtrace. Outside of gdb, it exists with return code 235, but gdb says "Program exited with code 0353".

I can upload 560 MB somewhere (I have 576 KBit upstream), but I do not have that much web space. If you can tell me, where to upload (with resume support, maybe ;-) ), I can do it. Otherwise you could download it from my personal web server. Either way, please contact me via mail about the transfer.

comment:12 Changed 15 years ago by Geoffrey Hausheer

Resolution: fixed
Status: reopenedclosed

Thomas has verified that 11516 resolved both the original and newly reported issue.

Note: See TracTickets for help on using tickets.