Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#2477 closed defect (fixed)

mythtranscode does not set nuv files fps, width and height correctly

Reported by: darkstarsword@… Owned by: cpinkham
Priority: minor Milestone: unknown
Component: mythtv Version: 0.20
Severity: medium Keywords:
Cc: Ticket locked: no

Description

Since updating to 0.20 I have noticed that mythtranscode has been setting the framerate of transcoded files to 29.97 fps, whereas it should be 25 since I am in Australia which uses PAL. It is correct in the mpg file prior to transcoding. This means that external players such as MPlayer will play the video at an incorrect rate and the result is a terrible A/V desync.

Change History (9)

comment:1 Changed 14 years ago by darkstarsword@…

Summary: mythtranscode does not set fps correctlymythtranscode does not set nuv files fps, width and height correctly

Seems that it also assumes the width and height are 640x480 instead of 720x576, though I can't tell if it's having any affect on anything or not - MPlayer seems to be able to play it either way.

comment:2 Changed 14 years ago by cpinkham

You don't say which mode you're using, lossless (mpeg-2) or lossy (mpeg-4), but SVN head is working fine here for nuppel mpeg-4 files. Here's the relevant output from nuvscan for a couple of my recently transcoded recordings:

Filename: 2013_20060922210000.nuv

Frame Size: 480x368 FPS: 29.970 Keyframe Distance: 30 Aspect: 1.777778

Filename: 2004_20060915210000.nuv

Frame Size: 480x368 FPS: 59.940 Keyframe Distance: 30 Aspect: 1.777778

Filename: 2010_20060910200000.nuv

Frame Size: 480x368 FPS: 29.970 Keyframe Distance: 30 Aspect: 1.333333

So that's a mixture of 4:3 and 16:9 recordings at 29.97 and 59.94fps, all at a size of 480x368. Seems to be working fine.

I therefore assume you're transcoding to mpeg-2 in lossless mode. If so, please state so in order to allow the proper person to look into this.

comment:3 Changed 14 years ago by cpinkham

Owner: changed from Isaac Richards to cpinkham

sorry, missed the "nuv" in the title. We are probably going to need an original mpg file that causes this issue when transcoding in order to track this down. Can you upload a sample like you did for #2479, but upload the un-transcoded mpg file this time. You can keep the original file around by turning on/off the setting to preserve the original file after transcoding. Once you find a bad file you can remove the originals and revert the setting.

comment:4 Changed 14 years ago by Isaac Richards

Priority: majorminor

comment:5 Changed 14 years ago by darkstarsword@…

Ok, here are some sample files. These were done with SVN revision 11315, but as I mentioned, the problem of the width, height and fps set incorrectly showed up since 0.20. I also realise that the aspect ratio in the nuv file is incorrect as well, I didn't notice before when I was hexediting them and the version of MPlayer I'm using doesn't read the aspect info correctly. Everything here is broadcast as 16:9 (720x576 for standard definition), any 4:3 content is simply broadcast with black on the sides to padd it to 16:9. HD may be different - I haven't bothered with it to find out.

I made a discovery when I was creating these - the problem seems to only affect certain channels - specifically ABC (but not ABC2 which is on the same multiplex) and PRIME. To see if it was the files or something in the database I recorded a few seconds from another channel (Channel 10), overwrote the file with one of these and transcoded that, but the same problem showed up. Then to be sure I recorded a few seconds from ABC, overwrote it with a few seconds from channel 10 and transcoded that without the problems, so it's probably nothing in the database, but let me know if you want me to attach the output of some query on the database if you need to check it.

Interestingly, another problem with the audio pitch showed up in the recording from the ABC, which may or may not be related to the header problem. I can't see anything wrong in the file header, and if you confirm that it's unrelated maybe it should go into another ticket. This problem was not present in 0.20.

Anyway, here are the URLs: ABC (wrong dimensions & fps, sound frequency incorrect): Before transcode: http://rapidshare.de/files/34758308/1_20060929002808.mpg.old.html After transcode: http://rapidshare.de/files/34758523/1_20060929002808.nuv.html

PRIME (wrong dimensions & fps): Before transcode: http://rapidshare.de/files/34758833/6_20060929004712.mpg.old.html After transcode: http://rapidshare.de/files/34758935/6_20060929004712.nuv.html

ABC2 (Just for comparison, nothing wrong with it): Before transcode: http://rapidshare.de/files/34759254/2_20060929003041.mpg.old.html After transcode: http://rapidshare.de/files/34759359/2_20060929003041.nuv.html

comment:6 Changed 14 years ago by cpinkham

Resolution: fixed
Status: newclosed

(In [11330]) Fix a bug in the AvFormatDecoder? where it would use the size, aspect, fps, and possibly other values from the last video stream found even because these values were always set in InitVideoCodec?(). Now we pass in a var telling whether we're going to use this stream or not so we initialize the values correctly based on the proper video stream.

Fixes #2477. I'm making a note to commit this to -fixes in a while if everything appears to still be working properly for people.

This does not address the side issue mentioned in #2477 about the audio being messed up for some recordings since that is unrelated to this issue.

comment:7 Changed 14 years ago by cpinkham

The audio issue is unrelated, you can open an independent ticket for this and it can be dealt with separately. Reference either this ticket or the link to the sample file with the audio issue in the new ticket so that that information doesn't get lost in the shuffle.

comment:8 Changed 14 years ago by darkstarsword@…

Excellent, it's working now. I'll go ahead and open another ticket for the audio. Thankyou very much.

comment:9 Changed 14 years ago by cpinkham

(In [11417]) Merge over [11330] from trunk. Here is the original commit log:

Fix a bug in the AvFormatDecoder?? where it would use the size, aspect, fps, and possibly other values from the last video stream found even because these values were always set in InitVideoCodec?(). Now we pass in a var telling whether we're going to use this stream or not so we initialize the values correctly based on the proper video stream.

References #2477.

Note: See TracTickets for help on using tickets.