BPK
Posts: 30
Joined: Mon Jun 04, 2012 10:12 am
Location: Bristol, United Kingdom
Contact: Website

Re: h264: possible to force SPS/PPS per GOP?

Sun May 19, 2013 10:17 pm

Thanks Andy
Andy Armstrong wrote:
If you have very tightly controlled conditions you might be able to get as low as 1s latency - but if you have tightly controlled conditions you can probably use RTP/RTSP/RTMP or just pipe a MPEG-TS stream over a TCP connection without any protocol.

I know it seems like a tantalising prospect but I really don't think HTTP chunked streaming is viable for that kind of real time application (video chat, remote control etc).
Yes it is tantalising as HTTP is so nice and friendly compared to the others! Also may mean that the massive IP TV market which cares not for a few seconds latency may go with HLS leaving real time control which needs (0.5 sec latency really) with RTP/RTSP/RTMP as the poor relations?
Barnaby Kent
http://www.pi-cars.com
Control your radio controlled car through your Raspberry Pi

towolf
Posts: 421
Joined: Fri Jan 18, 2013 2:11 pm

Re: h264: possible to force SPS/PPS per GOP?

Sun May 19, 2013 10:22 pm

So, I’ve made a black .bmp and processed that with "merge". Two bytes are different at address 0x20. Now what does this mean?

Code: Select all

diff <(cat black-ff.bmp | hexdump) <(cat black-merge.bmp | hexdump)
3c3
< 0000020 0000 3000 002a 0000 0000 0000 0000 0000
---
> 0000020 3036 002a 002a 0000 0000 0000 0000 0000

towolf
Posts: 421
Joined: Fri Jan 18, 2013 2:11 pm

Re: h264: possible to force SPS/PPS per GOP?

Sun May 19, 2013 11:10 pm

And here’s a patch that makes it work for me

Code: Select all

--- merge_orig.c	2013-05-20 01:06:02.314705273 +0200
+++ merge.c	2013-05-20 01:06:50.082942182 +0200
@@ -149,7 +149,7 @@
 
     if (++phase == frames) {
       average(buf, image, bytes, frames);
-      write32(bmp_hdr, 0x22, BMP_HEADER_SIZE + DIB_HEADER_SIZE + bytes);
+      write32(bmp_hdr, 0x24, bytes);
       write32(bmp_hdr, 0x0a, BMP_HEADER_SIZE + DIB_HEADER_SIZE);
       write32(dib_hdr, 0x00, DIB_HEADER_SIZE);
Now why this worked for you earlier I don’t know. Apparently the size was written at a wrong position and the size in the DIB header has to be given for the pixels alone.

But, however that may be, I’m happy. I’ve learned something today and so the Pi has done its job once more!

Andy Armstrong
Posts: 57
Joined: Sat Dec 03, 2011 10:10 am

Re: h264: possible to force SPS/PPS per GOP?

Sun May 19, 2013 11:37 pm

towolf wrote:And here’s a patch that makes it work for me

Code: Select all

--- merge_orig.c	2013-05-20 01:06:02.314705273 +0200
+++ merge.c	2013-05-20 01:06:50.082942182 +0200
@@ -149,7 +149,7 @@
 
     if (++phase == frames) {
       average(buf, image, bytes, frames);
-      write32(bmp_hdr, 0x22, BMP_HEADER_SIZE + DIB_HEADER_SIZE + bytes);
+      write32(bmp_hdr, 0x24, bytes);
       write32(bmp_hdr, 0x0a, BMP_HEADER_SIZE + DIB_HEADER_SIZE);
       write32(dib_hdr, 0x00, DIB_HEADER_SIZE);
Now why this worked for you earlier I don’t know. Apparently the size was written at a wrong position and the size in the DIB header has to be given for the pixels alone.

But, however that may be, I’m happy. I’ve learned something today and so the Pi has done its job once more!
Ah - you're right that that's where the problem lies - but I think your fix is wrong too. It should be:

Code: Select all

diff --git a/merge.c b/merge.c
index 6e98748..dbfa3d5 100644
--- a/merge.c
+++ b/merge.c
@@ -149,7 +149,7 @@ int main(int argc, char *argv[]) {

     if (++phase == frames) {
       average(buf, image, bytes, frames);
-      write32(bmp_hdr, 0x22, BMP_HEADER_SIZE + DIB_HEADER_SIZE + bytes);
+      write32(bmp_hdr, 0x02, BMP_HEADER_SIZE + DIB_HEADER_SIZE + bytes);
       write32(bmp_hdr, 0x0a, BMP_HEADER_SIZE + DIB_HEADER_SIZE);
       write32(dib_hdr, 0x00, DIB_HEADER_SIZE);
The total file size should be at offset 0x02. I suspect 0x22 was a typo; it's actually outside the bmp_hdr buffer which is only 14 bytes long.

http://en.wikipedia.org/wiki/BMP_file_f ... ile_header

However I've also noticed that even doing this (without using merge at all):

Code: Select all

$ ffmpeg -y -t 10 -i live.1.ts -c:v bmp -f image2pipe - 2> ff1.log | \
  ffmpeg -y -f image2pipe -c:v bmp -i - -c:v libx264 -b:v 3000k -r:v 25 foo.ts 2> ff2.log
I'm seeing "pipe:: Input/output error" from the second ffmpeg instance. It doesn't seem to cause a problem in practice - but surprising given that I assume that's what image2pipe is intended for.

Andy Armstrong
Posts: 57
Joined: Sat Dec 03, 2011 10:10 am

Re: h264: possible to force SPS/PPS per GOP?

Sun May 19, 2013 11:40 pm

Oh and the image size at offset 0x22 in the DIB header doesn't need to be updated because that buffer already contains the most recent DIB header read and the size of the image data doesn't change between input and output. The other updates to the headers are to cover the eventuality that the DIB header we're writing is a different size from the one we read - which is theoretically possible if ffmpeg wrote one of the longer DIB header versions - but doesn't seem to happen in practice.

towolf
Posts: 421
Joined: Fri Jan 18, 2013 2:11 pm

Re: h264: possible to force SPS/PPS per GOP?

Sun May 19, 2013 11:46 pm

I was stumbling about the weird addresses now too. Your explanation covers it. Thank you so far.

Andy Armstrong
Posts: 57
Joined: Sat Dec 03, 2011 10:10 am

Re: h264: possible to force SPS/PPS per GOP?

Sun May 19, 2013 11:48 pm

BPK wrote:Yes it is tantalising as HTTP is so nice and friendly compared to the others! Also may mean that the massive IP TV market which cares not for a few seconds latency may go with HLS leaving real time control which needs (0.5 sec latency really) with RTP/RTSP/RTMP as the poor relations?
Yup - you'll notice that iPlayer live now uses either Adobe HDS or HLS (on iOS). We started doing that for the Olympics for the 27 live streams that we ran. It's much easier to scale an http based protocol using commodity acceleration technology, content delivery networks than it is with RTMP.

It's quite neat that you can serve live streaming video from a regular web server. It means that you can also, e.g. stream using Amazon S3. Which means that you can publish a stream from your Pi to Amazon S3 and have CloudFront CDN in front of it and scale to millions of viewers. Pi -> Cloud -> The World. Neat eh? :)

towolf
Posts: 421
Joined: Fri Jan 18, 2013 2:11 pm

Re: h264: possible to force SPS/PPS per GOP?

Mon May 20, 2013 12:04 am

Andy Armstrong wrote:However I've also noticed that even doing this (without using merge at all):

Code: Select all

$ ffmpeg -y -t 10 -i live.1.ts -c:v bmp -f image2pipe - 2> ff1.log | \
  ffmpeg -y -f image2pipe -c:v bmp -i - -c:v libx264 -b:v 3000k -r:v 25 foo.ts 2> ff2.log
I'm seeing "pipe:: Input/output error" from the second ffmpeg instance. It doesn't seem to cause a problem in practice - but surprising given that I assume that's what image2pipe is intended for.
Yes, I’ve had that too. And what I find really odd is that the ratio of input frames and output frames does not match up to 200:1. In my input video I had 119100 frames and 296 in the output, a ratio of 402:1. And timewise, looking at a radio clock in the picture, I get 4748 seconds / 11.88 seconds and a ratio of ~399:1.

So something is massively dropping frames there.

About the image2pipe, maybe going directly with yuv4mpegpipe would’ve been easier. 1) There’s no need for color space conversion 2) averaging happens separately in luma and chroma 3) no dib header, but maybe other headers.

And as far as I’ve seen in the past yuv4mpeg is the standard uncompressed format.

Anyway, I’m loving this. It’s a cool feature that all noise is canceled out, particularly for night shots. Gotto work on a solid mount now.

Andy Armstrong
Posts: 57
Joined: Sat Dec 03, 2011 10:10 am

Re: h264: possible to force SPS/PPS per GOP?

Mon May 20, 2013 12:15 am

towolf wrote:Yes, I’ve had that too. And what I find really odd is that the ratio of input frames and output frames does not match up to 200:1. In my input video I had 119100 frames and 296 in the output, a ratio of 402:1. And timewise, looking at a radio clock in the picture, I get 4748 seconds / 11.88 seconds and a ratio of ~399:1.

So something is massively dropping frames there.
Hmm, that is odd. I think that merge is doing the right thing...

What happens if you take merge out of the pipe? Do you get 1:1 parity between input and output then?
towolf wrote:About the image2pipe, maybe going directly with yuv2mpegpipe would’ve been easier. 1) There’s no need for color space conversion 2) averaging happens separately in luma and chroma 3) no dib header, but maybe other headers. But as far as I’ve seen in the past yuv2mpeg is the standard uncompressed format.
Ah! Yeah, that's exactly what I should have done. I forgot the name of it and gave up browsing through the bazillions of formats ffmpeg now supports.

I'll change it to use yuv2mpegpipe - processing is pretty slow at the moment and I bet a lot of that has to do with the colourspace conversion.

Thanks!

towolf
Posts: 421
Joined: Fri Jan 18, 2013 2:11 pm

Re: h264: possible to force SPS/PPS per GOP?

Mon May 20, 2013 12:25 am

Seems quite simple actually:

Code: Select all

0000000: 5955 5634 4d50 4547 3220 5731 3238 3020  YUV4MPEG2 W1280 
0000010: 4837 3230 2046 3235 3a31 2049 7020 4130  H720 F25:1 Ip A0
0000020: 3a30 2043 3432 306a 7065 6720 5859 5343  :0 C420jpeg XYSC
0000030: 5353 3d34 3230 4a50 4547 0a46 5241 4d45  SS=420JPEG.FRAME
0000040: 0a10 1010 1010 1010 1010 1010 1010 1010  ................
0000050: 1010 1010 1010 1010 1010 1010 1010 1010  ................
0000060: 1010 1010 1010 1010 1010 1010 1010 1010  ................
0000070: 1010 1010 1010 1010 1010 1010 1010 1010  ................
0000080: 1010 1010 1010 1010 1010 1010 1010 1010  ................
0000090: 1010 1010 1010 1010 1010 1010 1010 1010  ................

The spec: http://wiki.multimedia.cx/index.php?title=YUV4MPEG2

towolf
Posts: 421
Joined: Fri Jan 18, 2013 2:11 pm

Re: h264: possible to force SPS/PPS per GOP?

Tue May 21, 2013 11:50 am

I’ve felt the need to brush up my rudimentary C and felt at liberty to modify your averager to read yuv4mpeg2. Hope you don’t mind ...

Code: Select all

$ ffmpeg -i <(cat ssh/live/stream{1..10}.ts) -c:v bmp -f image2pipe - > test.bmp
$ ffmpeg -i <(cat ssh/live/stream{1..10}.ts) -f yuv4mpegpipe - > test.y4m
$ ll -h test.*
-rw-rw-r-- 1 towolf towolf 1,6G Mai 21 13:31 test.bmp
-rw-rw-r-- 1 towolf towolf 792M Mai 21 13:33 test.y4m
$ time ./merge < test.bmp > merged.bmp

real	0m6.253s
user	0m3.780s
sys	0m1.528s
$ time ./mergeyuv < test.y4m > merged.y4m

real	0m2.991s
user	0m1.916s
sys	0m0.764s
Twice as fast, half as big! Now, was there a reason that you’ve used unbuffered read instead of fread? I must admit the intricacies of C are lost on me.

Visually, I’ve only observed a slight difference in lightness so far, a consequence of skipping the color space conversion I assume.

Here’s my version, mergeyuv.c

Code: Select all

/* mergeyuv.c */

#include <stdarg.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

static void die(const char *msg, ...) {
  va_list ap;
  va_start(ap, msg);
  fprintf(stderr, "merge: ");
  vfprintf(stderr, msg, ap);
  fprintf(stderr, "\n");
  exit(1);
}

static void *alloc(size_t size) {
  void *m = malloc(size);
  if (!m) die("Can't allocated %lu bytes", (unsigned long) size);
  memset(m, 0, size);
  return m;
}

static void add_buf(uint32_t *img, uint8_t *buf, uint32_t size) {
  uint32_t i;
  for (i = 0; i < size; i++)
    img[i] += buf[i];
}

static void average(uint8_t *buf, uint32_t *img, uint32_t size, unsigned count) {
  uint32_t i;
  for (i = 0; i < size; i++)
    buf[i] = img[i] / count;
}

int main(int argc, char *argv[]) {
  unsigned frames = 200;
  unsigned long frame = 0;
  unsigned long emitted = 0;
  unsigned phase = 0;
  size_t got;
  unsigned char yuv4mpeg2_hdr[80];
  uint32_t *image = NULL;
  uint8_t *buf = NULL;
  int width = 0;
  int height = 0;

  if (argc > 1) {
      frames = atoi(argv[1]);
  }
  if (frames == 0) {
      die("Invalid frame count: %s", argv[1]);
  }

  int fps_n = -1,
      fps_d = -1;

  got = fread(yuv4mpeg2_hdr, 1, 9, stdin);
  if (got < 9) {
    die("EOF before YUV4MPEG2 header found.");
  }
  if (memcmp(yuv4mpeg2_hdr, "YUV4MPEG2", 9)) {
      die("Not in YUV2MPEG2 format?");
  }

  int i, j;
  for(i = 10; i < 79; i++){
      got = fread(yuv4mpeg2_hdr + i, 1, 1, stdin);
      if (got < 1) {
          die("EOF parsing stdin as YUV4MPEG2 header.");
      }
      if (yuv4mpeg2_hdr[i]=='\n') {
          break;
      }
  }
  if (i == 79) {
      die("Error parsing header; not in YUV2MPEG2 format?");
  }
  yuv4mpeg2_hdr[i]='\0';

  /* parse the frame header */
  j = 10;
  while (j < i) {
      if ((yuv4mpeg2_hdr[j] != ' ') && (yuv4mpeg2_hdr[j - 1] == ' '))
          switch (yuv4mpeg2_hdr[j]) {
          case 'W':
              width = atoi((char*) &yuv4mpeg2_hdr[j + 1]);
              break;
          case 'H':
              height = atoi((char*) &yuv4mpeg2_hdr[j + 1]);
              break;
          case 'C': /* chroma subsampling */
              break;
          case 'I':
              break;
          case 'F': /* frame rate ratio */
              fps_n = atoi((char*) &yuv4mpeg2_hdr[j + 1]);
              while ((yuv4mpeg2_hdr[j] != ':') && (j < i))
                  j++;
              fps_d = atoi((char*) &yuv4mpeg2_hdr[j + 1]);
              break;
          case 'A': /* sample aspect ratio */
              break;
          case 'X': /* metadata */
              break;
          default:
              fprintf(stderr, "merge: unrecognized stream header tag '%c'\n", yuv4mpeg2_hdr[j]);
              break;
          }
      j++;
  }
  /* verify data from the stream header */
  if (width <= 0) {
      die("Error parsing YUV4MPEG2 header: missing width tag.");
  }
  if (height <= 0) {
      die("Error parsing YUV4MPEG2 header: missing height tag.");
  }
  if (fps_n < 0 || fps_d < 0) {
      /* default to 25 fps */
      fps_n = 25; fps_d = 1;
      fprintf(stderr, "merge: Warning: no framerate defined.\n");
  }

  fprintf(stderr,"merge: Input is %dx%d %.02f fps YUV12 video.\n",
          width, height, (double)fps_n/fps_d);

  printf("YUV4MPEG2 W%d H%d F%d:%d Ip A0:0 C420jpeg\n",
         width, height, fps_n, fps_d);

  size_t bytes = width * height * 3 / 2;

  while (++frame) {
    if (NULL == buf) {
        buf = alloc(bytes);
    }
    if (NULL == image) {
        image = alloc(bytes * sizeof(uint32_t));
    }

    char c, frame_hdr[6];
    got = fread(frame_hdr, 1, 6, stdin);

    /* match and skip the frame header */
    if (got < 6) {
        break;
    }
    if (memcmp(frame_hdr, "FRAME", 5)) {
        die("Loss of framing in YUV input data.");
    }
    if (frame_hdr[5] != '\n') {
        int j;
        for (j=0; j < 79; j++)
            if (fread(&c, 1, 1, stdin) && (c == '\n')) {
                break;
            }
        if (j == 79){
            die("Error parsing YUV frame header.");
        }
    }

    fprintf(stderr, "merge: read [%010lu] frames, averaging [%06d] frames\n", frame, phase);

    got = fread(buf, 1, bytes, stdin);
    if (got != bytes) {
        break;
    }

    add_buf(image, buf, bytes);

    if (++phase == frames) {
      average(buf, image, bytes, frames);
      printf("FRAME\n");
      fwrite(buf, 1, bytes, stdout);
      memset(image, 0, bytes * sizeof(uint32_t));
      phase = 0;
      emitted++;
    }
  }
    fprintf(stderr, "merge: Merged %lu frames into %lu using a %d frame window. Exiting\n", frame, emitted, frames);
  return 0;
}

/* vim:ts=2:sw=2:sts=2:et:ft=c
 */

towolf
Posts: 421
Joined: Fri Jan 18, 2013 2:11 pm

Re: h264: possible to force SPS/PPS per GOP?

Tue May 21, 2013 6:21 pm

Now the one remaining problem is that I really would like to run raspivid in --exposure night mode because that seems to make the framerate variable towards slower framerates, i.e., go as low as you need to expose properly (with a lower bound).

And somehow, unless you want to play the night mode stream live, this works.

I think the segmenting ffmpeg on the raspberry side sees the h264 stream on stdin and assumes 25fps. Then it wants divide the input into 12 second segments. So it waits for 300 frames and moves to a new .ts file. But what it didn’t take into account was that in night mode actual fps could go as low as 4fps. So it keeps reading stdin until the 300 frames have come in.

I’ve plotted this here Image

You can see a period where the segments were written ~ 75 seconds apart. That is when I put black cardboard in front of the lens. 300 frames in 75 seconds is 4fps, which seems to be the lower bound in night mode.

When I lifted the cardboard it went back to 12 second "real time" chunks.

I’m wondering if this could be caught using your h264 packet wizardry, Andy. But HLS might not be able to accomodate "variable" framerates at all? Not even segment-wise?

Of course with time resampling the effect is now that at night the timelapse will speed up even more, i.e., five-fold, or 1000:1. But maybe that’s not a bad thing. Night is boring in general.
Attachments
diff-mtime.png
diff-mtime.png (27.06 KiB) Viewed 8048 times

towolf
Posts: 421
Joined: Fri Jan 18, 2013 2:11 pm

Re: h264: possible to force SPS/PPS per GOP?

Tue May 21, 2013 7:39 pm

And this is how it looks as the light outdoors fades:

Image

Time of sunset in my area today is 21:04. Makes sense. It ramps up exposure time to compensate, but at 4fps it flatlines and night is black again. However cars and windows are visible, which aren’t without --exposure night.

Andy Armstrong
Posts: 57
Joined: Sat Dec 03, 2011 10:10 am

Re: h264: possible to force SPS/PPS per GOP?

Wed May 22, 2013 10:25 am

Nice graphs! By the time you have encoded h264 it's too late to change the frame rate - you can't just e.g. duplicate frames unfortunately.

You could set the iframe rate high enough that even at 5fps you get an iframe every few seconds. That would make the segment durations more consistent. However I haven't experimented with setting the iframe rate since discovering that PiCam was already producing periodic iframes.

I had a hack about with yuv4mpeg2 too: https://github.com/AndyA/timewarp. It's currently undocumented - but it consumes and produces yuv4mpegpipe streams. You configure it with a JSON document that looks like this:

Code: Select all

[
   {
      "filter" : "merge",
      "options" : {
         "frames" : 10
      }
   },
   {
      "filter" : "streak",
      "options" : {
         "decay" : 0.9
      }
   }
]
It has a dependency on libjsondata.

Got to dash - busy week - hope to be back for more playing at the weekend :)

ppumkin
Posts: 82
Joined: Tue May 29, 2012 10:22 pm

Re: h264: possible to force SPS/PPS per GOP?

Sat May 25, 2013 9:01 pm

Is there a way to stream to any HTML5 compatible browser that support h264?

towolf
Posts: 421
Joined: Fri Jan 18, 2013 2:11 pm

Re: h264: possible to force SPS/PPS per GOP?

Sun May 26, 2013 1:07 am

Safari, yes. Apple mobile devices, yes. Android maybe. Chrome no. Firefox no.

Chrome is betting its future on a competing standard to HLS called MPEG Dash but that one is even less supported than HLS.

towolf
Posts: 421
Joined: Fri Jan 18, 2013 2:11 pm

Re: h264: possible to force SPS/PPS per GOP?

Sun May 26, 2013 1:15 am

It turns out that 720p is a rescaled 1080p crop of 1944 lines full-frame. I’ve switched to jpgs for now to see how that turns out in timelapses, but it looks much worse at night so far.

The JPGs have largely useless EXIF metadata, but I plotted the Brightness Value which explains how the fps is ramped up in night mode
Image

This is the difference of the earlier 720p version of the 1080p crop, compared to 2x2 binned 972 lines cropped to 720 lines. It’s quite a bit wider angle
Image
Image

Andy Armstrong
Posts: 57
Joined: Sat Dec 03, 2011 10:10 am

Re: h264: possible to force SPS/PPS per GOP?

Sun Jun 02, 2013 9:16 am

PiCam Live: http://newstream.hexten.net/picaster/

I've posted details in a new thread; I figure it might be of interest to people who aren't following this one:

http://www.raspberrypi.org/phpBB3/viewt ... 38&t=45893

aspire89
Posts: 5
Joined: Wed Aug 21, 2013 2:35 am

Re: h264: possible to force SPS/PPS per GOP?

Wed Aug 21, 2013 2:42 am

Did all the instructions with http://raspberrypi.stackexchange.com/qu ... inx-for-re
But there was an error starting video.sh

Code: Select all

# ./video.sh
+ rm -rf live live.h264 /home/pi/templates/live
+ mkdir -p live
+ ln -s /home/pi/live /home/pi/templates/live
+ mkfifo live.h264
+ sleep 2
+ psips
+ raspivid -w 640 -h 480 -fps 25 -hf -t 86400000 -b 1800000 -o -
+ ffmpeg -y -i live.h264 -f s16le -i /dev/zero -r:a 48000 -ac 2 -c:v copy -c:a libfaac -b:a 128k -map 0:0 -map 1:0 -f segment -segment_time 8 -segment_format mpegts -segment_list /home/pi/templates/live.m3u8 -segment_list_size 720 -segment_list_flags live -segment_list_type m3u8 live/%08d.ts
ffmpeg version N-55662-gc56d4da Copyright (c) 2000-2013 the FFmpeg developers
  built on Aug 20 2013 19:52:40 with gcc 4.6 (Debian 4.6.3-14+rpi1)
  configuration:
  libavutil      52. 42.100 / 52. 42.100
  libavcodec     55. 28.100 / 55. 28.100
  libavformat    55. 14.100 / 55. 14.100
  libavdevice    55.  3.100 / 55.  3.100
  libavfilter     3. 82.100 /  3. 82.100
  libswscale      2.  5.100 /  2.  5.100
  libswresample   0. 17.103 /  0. 17.103
./video.sh: line 14: psips: command not found
[h264 @ 0x1775040] Format h264 detected only with low score of 1, misdetection possible!
[h264 @ 0x1775040] Could not find codec parameters for stream 0 (Video: h264): unspecified size
Consider increasing the value for the 'analyzeduration' and 'probesize' options
live.h264: could not find codec parameters
What am I doing wrong?

ppumkin
Posts: 82
Joined: Tue May 29, 2012 10:22 pm

Re: h264: possible to force SPS/PPS per GOP?

Wed Aug 21, 2013 7:35 am

You need psips

Read back a few posts and you will see a psips binary posted. put it into the correct directory.

Also - You might not need psips so you can remove the part of psips from the script. If you got the latest raspivid you might not need that anymore anyway..

aspire89
Posts: 5
Joined: Wed Aug 21, 2013 2:35 am

Re: h264: possible to force SPS/PPS per GOP?

Wed Aug 21, 2013 1:34 pm

Install psips as written here https://github.com/AndyA/psips
An error has occurred in the 'libfaac'

Code: Select all

$ ./video.sh
+ rm -rf live live.h264 /home/pi/templates/live
+ mkdir -p live
+ ln -s /home/pi/live /home/pi/templates/live
+ mkfifo live.h264
+ sleep 2
+ psips
+ raspivid -w 640 -h 480 -fps 25 -hf -t 86400000 -b 1800000 -o -
+ ffmpeg -y -i live.h264 -f s16le -i /dev/zero -r:a 48000 -ac 2 -c:v copy -c:a libfaac -b:a 128k -map 0:0 -map 1:0 -f segment -segment_time 8 -segment_format mpegts -segment_list /home/pi/templates/live.m3u8 -segment_list_size 720 -segment_list_flags live -segment_list_type m3u8 live/%08d.ts
ffmpeg version N-55662-gc56d4da Copyright (c) 2000-2013 the FFmpeg developers
  built on Aug 20 2013 19:52:40 with gcc 4.6 (Debian 4.6.3-14+rpi1)
  configuration:
  libavutil      52. 42.100 / 52. 42.100
  libavcodec     55. 28.100 / 55. 28.100
  libavformat    55. 14.100 / 55. 14.100
  libavdevice    55.  3.100 / 55.  3.100
  libavfilter     3. 82.100 /  3. 82.100
  libswscale      2.  5.100 /  2.  5.100
  libswresample   0. 17.103 /  0. 17.103
Input #0, h264, from 'live.h264':
  Duration: N/A, bitrate: N/A
    Stream #0:0: Video: h264 (High), yuv420p, 640x480, 25 fps, 25 tbr, 1200k tbn, 50 tbc
Guessed Channel Layout for  Input Stream #1.0 : mono
Input #1, s16le, from '/dev/zero':
  Duration: N/A, bitrate: 705 kb/s
    Stream #1:0: Audio: pcm_s16le, 44100 Hz, mono, s16, 705 kb/s
Unknown encoder 'libfaac'

ppumkin
Posts: 82
Joined: Tue May 29, 2012 10:22 pm

Re: h264: possible to force SPS/PPS per GOP?

Wed Aug 21, 2013 1:41 pm

You need to compile (not install from repo) ffmpeg on your own or install the binary as "also" found in earlier posts....

aspire89
Posts: 5
Joined: Wed Aug 21, 2013 2:35 am

Re: h264: possible to force SPS/PPS per GOP?

Wed Aug 21, 2013 2:00 pm

Installed like this

Code: Select all

cd /usr/src
git clone git://source.ffmpeg.org/ffmpeg.git

cd ffmpeg
./configure
make && make install

ppumkin
Posts: 82
Joined: Tue May 29, 2012 10:22 pm

Re: h264: possible to force SPS/PPS per GOP?

Wed Aug 21, 2013 2:08 pm

and it took hours to compile?

Must be something else then. That codec is to do with audio though. maybe you doing something with audio? make sure there is no audio first.

aspire89
Posts: 5
Joined: Wed Aug 21, 2013 2:35 am

Re: h264: possible to force SPS/PPS per GOP?

Wed Aug 21, 2013 2:20 pm

Compiled a very long time. How to make no sound? I do not need.

Return to “Graphics, sound and multimedia”