Putting the TS into tsrecompressor

I notice that precious few HTTP Live Streaming questions have gotten responses, let alone answers. But I'll be optimistic!


I'd like to try streaming my own live video through the LL-HLS tools (currently prerelease 73), in multiple bitrates.


I succeeded in following directions: I use tsrecompressor to generate "bip-bop" video and pass three compressed variations of that into three instances of mediastreamsegmenter, then out through three instances of ll-hls-origin-example.go. It works as promised, end-to-end.


(Brief aside, for any who may stumble after me: it took me too long to realize that I should improve my knowledge of IP Multicasting and use the prescribed 224.0.0.50 address. I got nowhere trying to simply route familiar UDP unicast between my processes.)


So far, so good. Now I want to supply my own video from an external feed. Not the generated "bip-bop" or any local capture devices.


% tsrecompressor --help
tsrecompressor: unrecognized option `--help'
Read input MPEG-2 TS, recompress and write to output. Usage: tsrecompressor [options] where options are:
  -i    | --input-file= : input file path (default is stdin)
... etc.


That sounds fantastic — I'd love to feed tsrecompressor through stdin! But in what format? It doesn't say, and my first few dozen guesses came up cold.


The man page for mediastreamsegmenter appears to point the way:


     The mediastreamsegmenter only accepts MPEG-2 Transport Streams as defined
     in ISO/IEC 14496-1 as input.  The transport stream must contain H.264
     (MPEG-4, part 10) video and AAC or MPEG audio.  If AAC audio is used, it
     must have ADTS headers.  H.264 video access units must use Access Unit
     Delimiter NALs, and must be in unique PES packets.


Of course, that's mediastreamsegmenter and not tsrecompressor. But it's a start. So this is my best guess at the appropriate ffmpeg output. (Recall that I want to eventually pass a live stream into ffmpeg; for now I'm starting with an m4v file.)


% ffmpeg -re -i infile.m4v \
        -c:v h264_************ \
        -c:a aac_at \
        -f mpegts \
  - | tsrecompressor -h -a \
        -O 224.0.0.50:9121 \
        -L 224.0.0.50:9123 \
        -P 224.0.0.50:9125


This ends abruptly after 9 frames.


av_interleaved_write_frame(): Broken pipe
Error writing trailer of pipe:: Broken pipe//


My best results are when I change from H.264 to H.265:


% ffmpeg -re -i infile.m4v \
        -c:v hevc_************ \
        -c:a aac_at \
        -f mpegts \
  - | tsrecompressor -h -a \
        -O 224.0.0.50:9121 \
        -L 224.0.0.50:9123 \
        -P 224.0.0.50:9125


Now it doesn't break the pipe. It keeps counting along, frame after frame. The VTEncoderXPCService starts up, and sampling of the tsrecompressor process shows both producer and consumer threads for audio recompression.


But there's no output. There was output for the generated "bip-bop" video. Not for HEVC-TS via stdin. I'm not 100% certain yet but I see no indication of any UDP output from tsrecompressor. The three mediastreamsegmenter processes sit idle.


Am I missing some tag, or something, in the input stream? Do I need to pay more attention to chunk sizes and frame offsets?


Thanks, all, for any insight or experience.

Replies

I should clarify that the "broken pipe" output was from ffmpeg.


With some interpretation, this appears to be the corresponding output from tsrecompressor on the receiving end of the H.264 pipe:


newTrackCallback mediaType vide track 1
newTrackCallback mediaType soun track 2
formatDescriptionOrDecryptorChangedCallback for track 1
HW video encoder for 2000000
SW video encoder for 500000
HW video encoder for 4000000
encountered failure create vmc (-12903) - exiting


Where VTErrors.h identifies error -12903 as kVTInvalidSessionErr.


The same command substituting HEVC produces no such error, but again no output.

-c:v h264_************ \ 


Well, that's an unexpected substitution. I should check Urban Dictionary for any double entendre regarding a particular "toolbox" for processing "video" as a hardware accelerated codec offered only in macOS builds of ffmpeg.

Given that you're using it already, it might make more sense to use ffmpeg to encode your video as MPEG2-TS and send that via UDP to mediastreamsegmenter directly. Doing a second encoding pass with tsrecompressor doesn't seem like a good idea.
Hi! Thanks for your reply.

I have no intention of making a second encoding pass — except to derive lower alternative bitrates.

You make a good point: maybe I should encode those using ffmpeg. I'd initially tried to do those without hardware acceleration (in Docker) and wasn't keeping up. I should try again on macOS.

But if I may: I should restate the goal so we understand what I'm asking.
  1. I receive an offsite rtmp stream,

  2. use ffmpeg for passthrough remuxing from flv to ts, and

  3. hope to feed the result into tsrecompressor.

This used to work great with the HLS tools. It did not work with the separate LL-HLS tools — though it remained a documented option!

Any other use of ffmpeg, above, reflects my
  • trying to provide an actionable self-contained test case, and

  • grasping at straws about expected encoding parameters.

Fast forward to this afternoon, and we have a new (combined!) release of the HLS tools. Hurray!

In this release, man tsrecompressor and tsrecompressor --help both still describe use of an input file or stream.

I see two possibilities:
  • If this functionality has been removed, one or both of us should file a documentation bug.

  • If it should still work as documented, it's not working for me and I should take it to this forum for help.

Assuming the latter, I'm doing something wrong with the structure of my input and would appreciate all insight to correct this mistake.

You and I seem to both at least contemplate the former: that the mere concept of “input” is unceremoniously no longer relevant to today's tsrecompressor. That would be sad, but reasonable, and worth correcting in the documentation.

Thanks again for your attention. I do very much appreciate it.
Can you clarify what you mean by "this used to work great with the HLS tools" ? The LL-HLS tools beta package was the first release of tsrecompressor.
That is an excellent, excellent question. :}

My apologies: I had forgotten that this earlier deployment had been directly into mediastreamsegmenter using stdin.

Once I installed the prerelease LL-HLS, that installation stopped working. It wasn't a direct drop-in replacement, and I seemingly followed the changes of their README files into focusing on tsrecompressor.

I should go back and retry the first setup again, using the current toolset. man mediastreamsegmenter still claims to be able to read from stdin, although this usage has been deemphasized from the README.

Just a bump on this thread.

It is not clear to me what format the TSrecompressor expects for file input. If there is any additional documentation other than man tsrecompressor, please pass it along:)