Opened 12 years ago

Closed 11 years ago

#5180 closed defect (fixed)

mythtranscode never completes when transcoding clips with cutpoints

Reported by: krizze Owned by: stuartm
Priority: minor Milestone: 0.22
Component: mythtranscode Version: head
Severity: high Keywords: mythtranscode never completes
Cc: Ticket locked: no

Description

When transcoding mpeg2 recordings that have cutpoints, mythtranscode keeps going forever (Showing over 100% completed in mythweb/system info).

It keeps spitting out: 2008-04-08 20:38:43.063 Fast-Forwarding from 0 to 6630 2008-04-08 20:38:43.092 Fast-Forwarding from 0 to 6630 2008-04-08 20:38:43.120 Fast-Forwarding from 0 to 6630 2008-04-08 20:38:43.150 Fast-Forwarding from 0 to 6630 2008-04-08 20:38:43.178 Fast-Forwarding from 0 to 6630 2008-04-08 20:38:43.207 Fast-Forwarding from 0 to 6630 2008-04-08 20:38:43.236 Fast-Forwarding from 0 to 6630 2008-04-08 20:38:43.269 Fast-Forwarding from 0 to 6630 2008-04-08 20:38:43.299 Fast-Forwarding from 0 to 6630 2008-04-08 20:38:43.328 Fast-Forwarding from 0 to 6630 2008-04-08 20:38:43.356 Fast-Forwarding from 0 to 6630 2008-04-08 20:38:43.385 Fast-Forwarding from 0 to 6630 2008-04-08 20:38:43.414 Fast-Forwarding from 0 to 6630 2008-04-08 20:38:43.443 Fast-Forwarding from 0 to 6630 2008-04-08 20:38:43.472 Fast-Forwarding from 0 to 6630 2008-04-08 20:38:43.501 Fast-Forwarding from 0 to 6630 2008-04-08 20:38:43.529 Fast-Forwarding from 0 to 6630

Problem with fast-forwarding?

Change History (11)

comment:1 Changed 12 years ago by krizze

Recordings without cutpoints are transcoded as usual, but they are also failing with cutpoints afterwards, so it's not only with mpeg2.

comment:2 Changed 12 years ago by stuartm

Can we have the output of mythbackend --version please?

comment:3 Changed 12 years ago by krizze

Sorry about that, here it is:

MythTV Version : 16987 MythTV Branch : trunk Library API : 0.22.20080320-2 Network Protocol : 40 QT Version : 4.3.4 Options compiled in:

linux release using_oss using_alsa using_arts using_jack using_backend using_dbox2 using_dvb using_firewire using_frontend using_hdhomerun using_iptv using_ivtv using_joystick_menu using_lirc using_v4l using_x11 using_xrandr using_xv using_xvmc using_xvmcw using_xvmc_vld using_bindings_perl using_bindings_python using_opengl using_ffmpeg_threads using_libavc_5_3 using_live

comment:4 Changed 12 years ago by krizze

Nobody else having this problem?

comment:5 in reply to:  4 Changed 11 years ago by bill

Replying to krizze:

Nobody else having this problem?

Yes, I'm having the same problem. When transcoding mpeg2 (or nuv) recordings that have cutpoints, mythtranscode keeps spitting out (in my case its for one cutpoint, just for before the first frame):

2008-06-17 14:25:06.156 Fast-Forwarding from 0 to 1

ie. There seems to be some problem when it tries to fast forward to the first cutpoint.

And like krizzie says, recordings without cutpoints are transcoded as usual.

I've updated everything to run off the trunk version. I thought it might be a protocol mismatch, caused by me mixing versions of different myth* programs, but I don't *think* so. (As I can see all the myth* programs in /usr/local/bin have the same timestamp. ie. from when I did my last "make install")

$ /usr/local/bin/mythbackend --version

Please include all output in bug reports.
MythTV Version   : 17439
MythTV Branch    : trunk
Library API      : 0.22.20080612-1
Network Protocol : 40
QT Version       : 4.3.2
Options compiled in:
linux release using_oss using_alsa using_backend using_dbox2 using_dvb
using_frontend using_hdhomerun using_iptv using_ivtv using_joystick_menu using_lirc 
using_v4l using_x11 using_xrandr using_xv using_bindings_perl using_bindings_python 
using_opengl using_ffmpeg_threads using_live

And I see mythtranscode is being called with the following options:

/usr/local/bin/mythtranscode -j 1045 -V 3 -p autodetect -l

I tried running it by hand, but adding a "-v all" debugging option, to get the same problem, but with this (more verbose) output:

2008-06-17 14:25:06.156 Fast-Forwarding from 0 to 1
2008-06-17 14:25:06.157 Dec: DoFastForward(1 (4), do discard frames)
2008-06-17 14:25:06.157 Dec: DoRewind(1 (4), do discard frames)
2008-06-17 14:25:06.157 Dec: FindPostion(0, search not adjusted) --> [0(1808)]
2008-06-17 14:25:06.157 NVD: SeekReset(0, 1, do flush, do discard)
2008-06-17 14:25:06.157 VideoBuffers::DiscardFrames(1): UUAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
2008-06-17 14:25:06.158 VideoBuffers::DiscardFrames(): AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA -- done()
2008-06-17 14:25:06.158 VideoBuffers::DiscardFrames(1): AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA -- done
2008-06-17 14:25:06.213 NVP: ClearAfterSeek(1)
2008-06-17 14:25:06.233 Fast-Forwarding from 0 to 1
2008-06-17 14:25:06.234 Dec: DoFastForward(1 (2), do discard frames)
2008-06-17 14:25:06.234 Dec: FindPostion(0, search not adjusted) --> [0(1808)]
2008-06-17 14:25:06.234 NVD: SeekReset(0, 0, don't flush, do discard)
2008-06-17 14:25:06.234 VideoBuffers::DiscardFrames(0): AAAuuAAAAAAAAAAAAAAAAAAAAAAAAAA
2008-06-17 14:25:06.234 VideoBuffers::DiscardFrames(0): AAAaaAAAAAAAAAAAAAAAAAAAAAAAAAA -- done
2008-06-17 14:25:06.234 NVP: ClearAfterSeek(1)
2008-06-17 14:25:06.307 Fast-Forwarding from 0 to 1

Also nuvexport (from the same svn version) is not working anymore. (That complains about "Must specify --fifodir to use --fifosync"; No idea if that's a related problem.)

comment:6 Changed 11 years ago by nzhook

Im also getting this issue, however with a little more investigation it appears that the fast forwarding messages disappears if I change the -v level in the command being run (eg. mythtranscode --showprogress -j 8284 -V 3 -p 27 -l -v important) and the showprogress shows that the process is progressing through the video.

The line 5765 of libs/libmythtv/NuppelVideoPlayer.cpp outputs the given message for every frame once a cutpoint is hit hence slowing the process down quite a bit. I also found that becuase this is logged my var file system (where logs are stored) was filling up and stopping anything else from working (eg. MySQL)

However.... on top of this that function never returns a false, hence the process goes on forever (with the verbosiy set to important as shown above the progress shows '5830% Completed @ 113.306 fps' or 'Processed: 117402 of 59904 frames(4696 seconds)'

This issue seems IS caused by the removal of the == NULL check (qt4 port) on line 5743 of the same file, adding a similar check in allows the transcode to complete. Bug introduced with svn #16790

comment:7 in reply to:  6 Changed 11 years ago by anonymous

I am having the infinite transcode behavior as well when use nuvexport. AMD64 as well

comment:8 Changed 11 years ago by nzhook

The following is the patch I have been running since making the comment regarding the fix for the issue, this has been working since that time with no sign o the issue. Im posting this before doing an SVN update so someone may have already applied a similar patch, but I dont want to loose the change...

--- libs/libmythtv/NuppelVideoPlayer.cpp (revision 17827) +++ libs/libmythtv/NuppelVideoPlayer.cpp (working copy) @@ -5744,9 +5744,9 @@

if (m_playbackinfo)

m_playbackinfo->UpdateInUseMark?();

  • if (honorCutList) Qt4 port: removed dm_iter == NULL &&

+ if (videoOutput->GetLastDecodedFrame?()->frameNumber == 0 && honorCutList) Qt4 port: removed dm_iter == NULL &&

dm_iter = deleteMap.begin();

- +

if (GetDecoder()->GetFrame?(0))

return false;

if (eof)

comment:9 Changed 11 years ago by stuartm

Owner: changed from Isaac Richards to stuartm
Severity: mediumhigh
Status: newassigned

comment:10 Changed 11 years ago by scott.milliken@…

I have built a new system from SVN head on October 4, 2008, and the problem still exists in trunk. However, application of the patch listed above does work around the issue.

comment:11 Changed 11 years ago by stuartm

Resolution: fixed
Status: assignedclosed

(In [18809]) Fixes lossy transcoding of recordings which was broken during when the QT4 branch was merged to trunk. Thanks to xris and others for testing. Original fix from nzhook. Closes #5180, #5812

Note: See TracTickets for help on using tickets.