Ticket #10008 (closed Bug Report - General: Fixed)
Opened 21 months ago
Last modified 16 months ago
mythtranscode: picture corruption and momentary stalling after cuts
|Reported by:||mythtv@…||Owned by:||beirdo|
|Component:||MythTV - General||Version:||Unspecified|
The purpose of this ticket is to present a patch that adds a feature ( --cleancut ) to mythtranscode. The feature provides a way to avoid 3 problems. Versions of the patch for master, fixes/0.24 and jyavenard/backports/fixes/0.24 are available from my mythtv fork at https://github.com/Glidos/mythtv. The problems are as follows.
1) Some h264 transmissions don't have any completely safe start points. They have I frames, but it is permitted to have use of reference frames across an I frame. BBC HD is the source that I've analysed the most. It has no regular IDRs, no recovery points and no use of memory operations to clear the reference list. Because of that, slight corruption can occur at the start of a transcode and at each cut point. (If you are like me, then you will find what I've just said hard to believe, but I've also found seemingly knowledgeable people on forums confirming it. Apparently decoders are supposed to work around the problem the best they can.)
2) mythtranscode in fifo mode has a very clever synchronisation mechanism that ensures the amount of video and audio sent to the fifos always corresponds with the timecodes that were associated with the data when in the source stream. The mechanism works very well when it settles down, but can produce a momentary freeze-frame effect on start up. That happens at the start and at each cut point.
3) Sometimes the video from just after the end of cut gets encoded with the audio from just after the beginning of cut (that's audio that shouldn't really be present).
The new feature is to have a new option to mythtranscode: --cleancut. When this option is invoked, each cut is performed in two stages: first the player seeks (as is the normal case), but not for the entire cut; then the cut is completed by discarding data.
It's a shame to have to add further complication to mythtranscode's synchronisation mechanism, but I have at least managed to encompass the new behaviour in a subsiduary class. In tests, the feature seems to work very well. I have added the feature only for fifodir mode so far.
I originally attempted to implement this by performing no seeks and only discarding data. That failed because strangely mythplayer associates frame numbers with actual frame data differently depending on whether the point is reached via an initial seek or by decoding from the beggining. I guess this is a bug. It usually causes no visible problems, because the setting of cut points and the use of them is both performed while seeking. I'd guess though that advert recognition decodes the entirety of the stream and hence will be out by about a second. One would blaim the recognition algorithm for this and not realise it was a player bug.
comment:1 Changed 21 months ago by mythtv@…
comment:2 Changed 19 months ago by beirdo
- Owner set to beirdo
- Status changed from new to assigned
comment:3 Changed 16 months ago by Github
- Status changed from assigned to closed
- Resolution set to fixed
- Milestone changed from unknown to 0.25
comment:4 Changed 16 months ago by danielk
- Status changed from closed to new
- Resolution fixed deleted
comment:5 Changed 16 months ago by lihamakaroonilaatikko@…
comment:6 Changed 16 months ago by beirdo
- Status changed from new to closed
- Resolution set to Fixed