Bug #3214
Difficulties in creating services from mpegts IPTV stream
0%
Description
I'm trying to create a channel on tvheadend using the video stream coming from the camera of my Raspberry PI. The stream is created using raspivid (h264) utility and streamed using ffmpeg to another instance of ffmpeg on the pipe of tvheadend. This is done without transcoding for performances (-vcodec copy -acodec copy).
The mux is created and the service is recognized but it doesn't work on first attempts. After some "operations" I'm able to make it work...
Lets show the problem with some reproducible steps. From https://goo.gl/TzRhlI you can download two TS files (both playable with VLC):
- bad.ts: the stream coming from the above queue without transcoding;
- good.ts: a similar stream but with a further transcoding (-vcodec libx264) on the last ffmpeg instance.
Input #0, mpegts, from '/home/mario/bad.ts': Duration: 00:00:05.48, start: 1.640000, bitrate: 18398 kb/s Program 1 Metadata: service_name : Kitchen service_provider: Surveillance Stream #0:0[0x100]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 1920x1080, 25 fps, 25 tbr, 90k tbn, 180k tbc ------ Input #0, mpegts, from '/home/mario/good.ts': Duration: 00:00:07.04, start: 1.560000, bitrate: 7166 kb/s Program 1 Metadata: service_name : Kitchen service_provider: Surveillance Stream #0:0[0x100]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 1920x1080, 25 fps, 25 tbr, 90k tbn, 50 tbc
The only difference I can note is the 'tbc' (time base codec) that looks strange in the encoding produce by raspivid.
Experiment n.1:
- create an IPTV mux with something like 'pipe://cat bad.ts';
- query the URL of such mux;
- the service 'Kitchen' is created;
- querying the URL of the new service doesn't work (no data);
- not all the characteristics of the stream are populated in the service file:
.... "stream": [ { "pid": 256, "type": "H264", "position": 0 } ...
Experiment n.2:
- delete previous mux and service, recreate a new IPTV mux with something like 'pipe://cat good.ts';
- query the URL of such mux;
- the service 'Kitchen' is created;
- query the URL of the service (maybe more times);
- now all the characteristics of the stream are populated in the service file:
.... "stream": [ { "pid": 256, "type": "H264", "position": 0, "width": 1920, "height": 1080, "duration": 3600 } ...
- now change the URL of the mux using the previous command (pipe://cat bad.ts);
- now the service works using the previous bad stream.
It looks that the indigestible stream bad.ts became usable if the characteristics of the stream are already present in the service file.
I understand that this could be caused by a non-compliant mpegts stream (raspivid...) but I hope tvheadend could be made more robust to manage more sources as possible. This looks at least possible (see experiment n.2).
Thanks.
History
Updated by Jaroslav Kysela about 9 years ago
- Status changed from New to Rejected
- Parent task set to #3213
It seems like a dup of #3213 .
Updated by Mario D about 9 years ago
It is similar but not a duplicate. To be sure, I've also tested the suggested options '-codec copy -bsf:v h264_mp4toannexb,dump_extra' but the characteristics of the stream are not populated and nothing is streamed.
With "one run of good.ts" everything look fixed and I can stream also bad.ts.
Updated by Jaroslav Kysela about 9 years ago
- Status changed from Rejected to Accepted
- Assignee set to Jaroslav Kysela
Updated by Jaroslav Kysela about 9 years ago
- Status changed from Accepted to Rejected
- Parent task deleted (
#3213)
I did some analysis and compared multiple source codes and the bad.ts does not have timing information in the VUI block. TVH expects the full information in the stream. The streams are different and the bad.ts is more likely invalid (although players are trying to guess the default timing). Try to set the correct frame rate. Anyway, this support is beyond TVH.
Good SPS NAL:
64 00 28 AC D9 40 78 04 4F DC 20 00 00 03 00 20 00 00 06 43 E2 C5 B2 C0 00
Bad SPS NAL:
64 00 28 AC 2B 40 3C 01 13 F2 C0 3C 48 9A 80 00