• The forum software that supports hummy.tv has been upgraded to XenForo 2.1!

    This is upgrade brings a number of improvements including the ability to bookmark posts to come back to later. Please bear with us as we continue to tweak things and open a new thread for any questions, issues or suggestions in Site/Forum Issues.

MPG conversion issue

I've just discovered that on-box conversion of recordings from PBS America (LCN 94, moving soon to 91) produces MPG files with no audio. Conversion works properly on all other channels.
The affected TS files play OK on both the box and my computer, as do conversions to MP4 done on the computer.
 

prpr

Well-Known Member
I tried it and can confirm.

Input:
Stream #0:0[0x8a3]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt470bg, top first), 544x576 [SAR 64:33 DAR 544:297], 25 fps, 25 tbr, 90k tbn, 50 tbc
Stream #0:1[0x8a4](eng): Audio: aac_latm (LC) ([17][0][0][0] / 0x0011), 48000 Hz, stereo, fltp
Output:
Stream #0:0: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt470bg, top first), 544x576 [SAR 64:33 DAR 544:297], q=2-31, 25 fps, 25 tbr, 90k tbn, 25 tbc
Stream #0:1(eng): Audio: aac_latm (LC) ([17][0][0][0] / 0x0011), 48000 Hz, stereo, fltp
Stream mapping:
Stream #0:0 -> #0:0 (copy)
Stream #0:1 -> #0:1 (copy)
video:4520kB audio:526kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.765299%
Result:
Stream #0:0[0x1c0]: Audio: mp2, 0 channels, s16p
Stream #0:1[0x1e2]: Video: h264 (High), yuv420p(tv, bt470bg, top first), 544x576 [SAR 64:33 DAR 544:297], 25 fps, 25 tbr, 90k tbn, 50 tbc
I don't think it can cope with aac_latm. Fails with the latest beta ffmpeg 4.1 as well.
You can re-code manually with aac audio codec into a .mp4, but not on the WebIf.
 

prpr

Well-Known Member
You can re-code manually with aac audio codec into a .mp4, but not on the WebIf.
And of course it takes ages on the T2.
You've tested it on all other "channels"
The Convert to MPG option is disabled on stuff recorded from BBC One HD and such like, which has the same audio format. Presumably the WebIf looks at the video format to decide this, and in the PBS America case it's sub SD resolution so it thinks it's OK to enable the option.
 
OP
J

JoeBloggs911

Member
I tried it and can confirm.

[...]

I don't think it can cope with aac_latm. Fails with the latest beta ffmpeg 4.1 as well.
You can re-code manually with aac audio codec into a .mp4, but not on the WebIf.
Thanks for confirming it. I converted the last batch on the computer, but sadly have lost a few older recordings where the .ts file is no longer available. But the chances are they'll repeat them, so there's still hope...
 

/df

Active Member
So the problem is that the Webif 'Opt+>Extract to MPG' conversion tries to copy the DVB-T2/SD audio (AAC LATM) and video (H.264) streams from the MPEG-TS container, but these formats are not valid in the MPEG video container. But as the strictly invalid MPEG/H.264+MP2 combination turns out to be supported by the Humax codecs and presumably some external media players, a possible solution is to test the source file and selectively copy or re-encode the audio, which tests at "ages", or <0.5 x length of programme (result plays on box with play/pause/stop only), something like this (/mod/webif/lib/ts.class lines 423 ff.):
Code:
-ts method mkmpg {{tmp ""}} {
+ts method mkmpg {{tmp ""}{mpg "mpg"}} {
      set rfile [file rootname $file]

+      if {$mpg eq mpg} {      
+          set cmd [list /mod/bin/ffprobe -hide_banner \
+              -select_streams a:0 -show_entries stream=codec_name \
+              -of flat $file 2>/dev/null]
+
+          set output [exec {*}$cmd]
+
+          if {[lsearch -glob -bool $output "*=\"mp2\""]} {
+              set acodec copy
+          } else {
+              set acodec mp2
+          }
+      }
+
      set cmd [list /mod/bin/ffmpeg \
          -y -benchmark -v 0 \
          -i $file \
          -map 0:0 -map 0:1 \
-          -vcodec copy -acodec copy]
+          -vcodec copy -acodec $acodec]

      if {$tmp eq ""} {
-              lappend cmd "${rfile}.mpg"
+              lappend cmd "${rfile}.${mpg}"
      } else {
-              lappend cmd "$tmp.mpg"
+              lappend cmd "$tmp.${mpg}"
      }

      set output [exec {*}$cmd]

      if {$tmp ne ""} {
-              file rename "$tmp.mpg" "${rfile}.mpg"
+              file rename "$tmp.mpg" "${rfile}.${mpg}"
      }

      return $output
}
Or there could be an 'Opt+>Extract to MP4' option in the WebIf, whose implementation would be the above method called with $tsobj mkmpg $tmpfile mp4; maybe even 'Opt+>Extract to MKV', with the above method called with $tsobj mkmpg $tmpfile mkv (for export only: MKV is not playable on box)? I suppose it depends on why people want this on-box conversion.
...
Presumably the WebIf looks at the video format to decide this, and in the PBS America case it's sub SD resolution so it thinks it's OK to enable the option.
The ts class uses hmt -p to determine the definition of the file. Instance variables, say acodec and vcodec, could be added to the class and set in the exec method by invoking ffprobe, as webif already depends on ffmpeg. In that case such instance variables could be used instead of calling ffprobe in the above proposal.

Not relevant to the OP's problem, but when it started on Freeview PBS America was notable for apparently random audio-video sync, a problem not seen with eg Film4+1 when it used to be transmitted as DVB-T2/SD. Maybe the Humax codecs had trouble with the transmission from the PBS America playout system? PBS America may have fixed this now: I haven't noticed it recently, and Dan Snow's lips were in good enough sync when I checked. The diagnostics for this recording dating from the bad AV sync era are typical (and similar for v2.8):
Code:
ffprobe Ancient\ Worlds_20180519_1014.ts
ffprobe version 4.1 Copyright (c) 2007-2018 the FFmpeg developers
...
[h264 @ 0x45fd10] SPS unavailable in decode_picture_timing
[h264 @ 0x45fd10] non-existing PPS 0 referenced
[h264 @ 0x45fd10] SPS unavailable in decode_picture_timing
[h264 @ 0x45fd10] non-existing PPS 0 referenced
[h264 @ 0x45fd10] decode_slice_header error
[h264 @ 0x45fd10] no frame!
...
[h264 @ 0x45fd10] mmco: unref short failure
    Last message repeated 1 times
[mpegts @ 0x4428c0] PES packet size mismatch
Input #0, mpegts, from 'Ancient Worlds_20180519_1014.ts':
  Duration: 01:04:55.78, start: 85146.370600, bitrate: 1572 kb/s
...
    Stream #0:0[0x8a3]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt470bg, top first), 544x576 [SAR 64:33 DAR 544:297], 25 fps, 25 tbr, 90k tbn, 50 tbc
    Stream #0:1[0x8a4](eng): Audio: aac_latm (LC) ([17][0][0][0] / 0x0011), 48000 Hz, stereo, fltp
It looks as though ffmpeg developers disagreed with the PBS America playout codec developers, or perhaps the Humax recording function mangled the format for that channel only? Off-air recordings from other channels don't show these diagnostics (others, but not these).
 
Top