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

John Pilkington johnpilk222 at gmail.com
Mon May 13 14:03:14 UTC 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.

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






More information about the mythtv-users mailing list