Firewire MPEG4 Support

[Andrew Phillips <theasp@…>]

My cable company recently converted some HD channels to MPEG4 (h264), but it looks like the firewire recorder is only looking for MPEG2 data. The attached patch works for me, with code copied from another recorder. I'm not sure what _seen_sps is used for, but I left it in.

See ​http://pastebin.com/1XtJkGhs for what was logged previous to this patch.

Details on the resulting file from mplayer: ID_FILENAME=2641_20111006110000.mpg ID_DEMUXER=mpegts ID_VIDEO_FORMAT=0x10000005 ID_VIDEO_BITRATE=0 ID_VIDEO_WIDTH=1920 ID_VIDEO_HEIGHT=1088 ID_VIDEO_FPS=29.970 ID_VIDEO_ASPECT=0.0000 ID_AUDIO_FORMAT=8192 ID_AUDIO_BITRATE=0 ID_AUDIO_RATE=0 ID_AUDIO_NCH=0 ID_START_TIME=20603.02 ID_LENGTH=0.00 ID_SEEKABLE=1 ID_CHAPTERS=0 ========================================================================== Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264) ========================================================================== ID_VIDEO_CODEC=ffh264 ========================================================================== Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders AUDIO: 48000 Hz, 2 ch, s16le, 384.0 kbit/25.00% (ratio: 48000->192000) ID_AUDIO_BITRATE=384000 ID_AUDIO_RATE=48000 ID_AUDIO_NCH=2 Selected audio codec: [ffac3] afm: ffmpeg (FFmpeg AC-3) ========================================================================== AO: [null] 48000Hz 2ch s16le (2 bytes per sample) ID_AUDIO_CODEC=ffac3

[theasp@…]

Good news, this doesn't seem to be required in 0.25 anymore, but I am getting more 0 length files. Not sure if this is related to them being h264 or not. It seems confined to one channel, that I can tune fine in live tv. Also, some shows have a bad seek table that can be fixed by mythcommflag --rebuild.

Anyway, I think you can close this ticket.

[stuartm]

Thank you for the update. The zero byte file issue could be #10443?

[stuartm]

It might have been premature to close this, I thought another patch adding H.264 support had gone in but that doesn't seem to be the case.

[danielk]

theasp, at this point it's too late for 0.25. But it may be possible to backport to 0.25/fixes after release.

[theasp@…]

Patch fixing h264 over firewire for 0.25

[theasp@…]

Hi Daniel,

I've updated the patch for 0.25. Myth will successfully record the second and subsequent shows off of the same channel now, but I am not sure why the first works without the patch.

[danielk]

TheAsp?, pulling the PMT on every packet is no good. This should cache the stream id like the DTVRecorder does so this is just a simple table lookup on the pid. Ideally, the firewire recorder should just use the same methods in DTVRecorder that other recorders use.

[danielk]

No updated patch provided.

[adamw@…]

Patch to add MPEG-4 support and re-use DTVRecorder code

[adamw@…]

How abut that patch? It adds MPEG-4 support and *reduces* the amount of unique code in FirewireRecorder?, by re-using DTVRecorder's functions for processing TS packets.

I couldn't manage to factor out FirewireRecorder::ProcessTSPacket entirely, but someone smarter probably could, I don't think it's impossible. I tried replacing the ProcessTSPacket calls in FirewireRecorder::AddData? with calls to GetStreamData?()->ProcessTSPacket but that doesn't work; I guess the bits in MPEGStreamData::ProcessTSPacket which figure out the function to call according to the available listeners don't work with inherited classes maybe? I dunno, this works.

[adamw@…]

hmm, well - I can tune some MPEG-4 channels with that, but not others, apparently. I can tune to more than one channel, one more than one time, so it's not what people were seeing a while back, but I'm not sure entirely what it is. I'll debug a bit more tomorrow.

Right now I can reliably tune 238 and 239 on Shaw Vancouver, which are TSN3 and TSN4 and are definitely h.264 (I checked the files). I can flip between them and switch between them and MPEG-2 channels. But I can't tune 216 (BC1 News) or 229 (APTN HD). Still, it's better than before. I'll play with it some more tomorrow.

[adamw@…]

well, I think perhaps those two channels are transmitting encrypted or something, because test-mpeg2 doesn't get valid MPEG from them either (it also reads the TSN channels just fine). So I don't think there's anything wrong with the patch, I'll have to investigate the story with those channels separately.

[im.js@…]

I have exactly the same issues on mythtv 0.27 using a Motorola DCX3200m-p3 with Shaw in Vancouver.

The capture issues occur with the same channels mentioned - BC1 News, APTN HD and also FX, Knowledge Network and CBC News. Shaw support confirms these are MPEG-4 streams whereas the working channels are MPEG-2 (at least as far as we checked, I should have gotten a complete list).

Is there a fix for myth 0.27? The patches here seem to be for lower versions ...

Would upgrading to 0.28 include the patch and fix the issue?

[adamw@…]

I don't think upstream ever merged my patch. I've been busy with other stuff lately and haven't been using my MythTV box, but I just had a quick look at current MythTV git master and it looks like mythtv/libs/libmythtv/recorders/firewirerecorder.cpp has not been touched since Jan 2013, so I expect my patch would still apply and probably still work. You could try it out.

[im.js@…]

Thanks for the response ...

I can't find firewirerecorder.cpp anywhere on my (mythbuntu 14.04) system. I guess this patch is to be applied to the source before installation? Is there any way to fix this on my box without having to re-install mythtv?

It would be great if this fix could get merged into 0.28, I think more an more channels will switch to MPEG-4.

[Adam Williamson <awilliam@…>]

In bc19a5cf3b32c619bc33d43820e0f584a03ea44d/mythtv:

firewirerecorder: use DTVRecorder for TS processing (fixes MPEG-4)

This fixes ​https://code.mythtv.org/trac/ticket/10080 and reduces
code duplication into the bargain. I couldn't find a way to
factor out FirewireRecorder::ProcessTSPacket entirely, but this
turns it into a fairly thin wrapper around the
ProcessAudioTSPacket and ProcessVideoTSPacket functions in
DTVRecorder. ProcessVideoTSPacket handles MPEG-4 just fine. This
also seems to speed up initial lock. Tested with a DCX3400 on
Shaw (Vancouver) - both MPEG-2 and MPEG-4 channels work.

Signed-off-by: Stuart Morgan <smorgan@…>

Fixes #10080

[marillat@…]

It is possible to backport this patch to 0.27 fix branch ?