[mythtv-users] Problem with MPEG-4 transcoded file (no bitrate or duration)

mythtv at kosowsky.org mythtv at kosowsky.org
Tue May 14 00:30:37 UTC 2019


John Pilkington wrote at about 15:03:14 +0100 on Monday, May 13, 2019:
 > On 13/05/2019 13:45, mythtv at kosowsky.org wrote:
 > > John Pilkington wrote at about 09:04:55 +0100 on Monday, May 13, 2019:
 > >   > On 13/05/2019 05:12, mythtv at kosowsky.org wrote:
 > >   > > mythtv at kosowsky.org wrote at about 00:00:23 -0400 on Monday, May 13, 2019:
 > >   > >   > In my old mythtv box (v24), I had no problem transcoding recordings to
 > >   > >   > MPEG4 and then editing (i.e. cutting) the video in the mythtv editor.
 > >   > >   >
 > >   > >   > For example, a transcoded and edited file, shows up under ffmpeg -i
 > >   > >   > as:
 > >   > >   >     Duration: 00:19:16.47, start: 0.033000, bitrate: 1411 kb/s
 > >   > >   >         Stream #0:0: Video: mpeg4 (Simple Profile) (DIVX / 0x58564944), yuv420p, 720x480 [SAR 1:1 DAR 3:2], SAR 32:27 DAR 16:9, 29.97 fps, 29.97 tbr, 1k tbn, 30k tbc
 > >   > >   >         Stream #0:1: Audio: mp3 (LAME / 0x454D414C), 48000 Hz, stereo, s16p, 1411 kb/s
 > >   > >   > 	
 > >   > >   > Under v29.1, when I transcode to mpeg4, the file seems to transcode (and compress) properly and I have no problem playing it.
 > >   > >   > But, when I try to edit it, the timestamps are all wrong, so that when I use the editor to cut and re-transcode, the cut list is not properly applied and the file is not spliced together properly.
 > >   > >   > When I run 'ffmpeg -i' I see that both the "Duration" and the "bitrate" are 'N/A', presumably explaining why the timestamps are wrong.
 > >   > >   >     Duration: N/A, start: 60704.885000, bitrate: N/A
 > >   > >   >         Stream #0:0: Video: mpeg4 (Simple Profile) (DIVX / 0x58564944), yuv420p, 704x480 [SAR 1:1 DAR 22:15], SAR 40:33 DAR 16:9, 29.97 fps, 29.97 tbr, 1k tbn, 30k tbc
 > >   > >   >         Stream #0:1: Audio: mp3 (LAME / 0x454D414C), 48000 Hz, stereo, s16p, 1411 kb/s
 > >   > >   >
 > >   > >   > I tried using 'mythcommflag --rebuild --file' to rebuild the seektable (which has saved me other times), but id had no effect.
 > >   > >   >
 > >   > >   > Is there something broken with mythtranscode that causes the file to create transcodings without defined durations or timestamps?
 > >   > >   >
 > >   > >   > Again, I never had the problem in (much) older version of mythtv...
 > >   > >   >
 > >   > >   > Thanks,
 > >   > >   > Jeff
 > >   > >
 > >   > > Note the transcoding profile I use is as follows:
 > >   > > 	Autodetect from MPEG2
 > >   > > 	    Profile name: MPEG2
 > >   > > 	    Enable auto-transcode after recording: yes
 > >   > > 	    Width: 720
 > >   > > 	    Height: 480
 > >   > > 	    Video Compression: MPEG-4
 > >   > > 	    Bitrate (kb/s): 3300
 > >   > > 	    Maximum quality: 2
 > >   > > 	    Minimum quality: 15
 > >   > > 	    Max quality difference between frames: 3
 > >   > > 	    Scale bitrate for frame size: No
 > >   > > 	    Enable high-quality recording: Yes
 > >   > > 	    Enable 4MV encoding: Yes
 > >   > > 	    Enable interlaced DCT encoding: No
 > >   > > 	    Enable interlaced motion estimation: No
 > >   > > 	    Number of threads: 4
 > >   > > 			
 > >   > > 	    Audio Quality: MP3
 > >   >
 > >   > I have never used mythtranscode with a format like that, but it seems
 > >   > likely that your problem is actually an incompatibility with
 > >   > mythcommflag --rebuild, or its equivalent within mythtranscode.
 > >   >
 > >   > It's not clear to me why you can't do the editing before transcoding,
 > >   > either directly to MPEG-4 or using mythtranscode --mpeg2 first.
 > >   >
 > > 
 > > Traditionally, I have recorded many shows and only sometimes months
 > > later gone back to either edit or delete them. This always worked for
 > > me in the past... but seems like something has changed...
 > > 
 > > I like to transcode first to save space (and yes I know space gets
 > > cheaper every day) and even more importantly bandwidth since I often
 > > download the files when traveling...
 > > 
 > > If there is something broken in mythtranscode, it would be good to fix
 > > it :)
 > 
 > OK.  It sounds as if the editor works with your mythtranscoded files, 
 > and playback will then respect the cutlist that you established, but a 
 > further mythtranscode does not.  TTBOMK the editor uses the seektable 
 > and probably ignores embedded timestamps.

Also, seems like the initial mythtranscode is doing something
different as ffmpeg is not able to recognize the bitrate or
duration while older recordings under v24 have a defined bitrate and
duration under ffmpeg.

Perhaps a partial clue is that under v24, the transcoded file had an
'nuv' suffix while under v29.1 the suffix is 'ts'.
Could it be an issue with the container?

Note that ffprobe shows both files to be of format NuppelVideo.


> I wonder if this is related to changes in the source file encoding?  I 
 > posted recently (4 May) about QPSK muxes used in the UK for 'local' 
 > channels, for which mediainfo now reports:
 > 
 > Time code source       : Group of pictures  vs (BBC) None given
 > GOP, Open/Closed       : Closed             vs (BBC) None given
 > 
 > Recent recordings from these channels are not properly cut by my usual 
 > tools, but the editor can still place cuts that are honoured during 
 > playback.
 > 
 > John P
 > 
 > 
 > 
 > 
 > _______________________________________________
 > mythtv-users mailing list
 > mythtv-users at mythtv.org
 > http://lists.mythtv.org/mailman/listinfo/mythtv-users
 > http://wiki.mythtv.org/Mailing_List_etiquette
 > MythTV Forums: https://forum.mythtv.org


More information about the mythtv-users mailing list