Re: [FFmpeg-user] Low latency H.264 streaming with ffmpeg

[Greger Burman]

Ok, so the ffmpeg based player is buffering frames somewhere even though
I'm telling it not to. This happens with h264 video but not with mjpeg.
That suggests to me that the latency is caused by either the h264 decoder
or the mpegts demuxer. I have also tried m4v instead of mpegts, with about
the same result.

Anyone who knows enough about the h264 decoding process to confirm/deny?
Is there a way to affect this behaviour without diving deep into the code?

cheers
//Greger

>
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] h264 stream from Arecont camera

[Carl Eugen Hoyos]

Jannes Faber  gmail.com> writes:

> Is there any way ffmpeg can deal with such a stream directly?

I believe it deals fine with the stream;-)
And even with your sed magic, I believe 
that the trailing 0's do not disappear, so 
remuxing may not have any advantages...

I opened #5154 for your issue, on of the problems is 
that I was unable to find a specification;-(

Carl Eugen

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] Why is it possible to set a timecode with 24:00:00:00 and beyond?

[Moritz Barsnick]

On Wed, Jan 13, 2016 at 14:17:43 +0100, Robert Krüger wrote:
> I wasn't able to find any official spec that says what the limit for the
> hour part is but since it in the general case does not define a time of day
> but an offset, why limit it to 25 hours and not use the full 100? On a
> side-note, I have not come across a real-world use case for a timecode of
> that magnitude either.

I too couldn't find any official specification (at all), but every
source I found (10 minutes of *search engine of choice*) indicates that
it reflects a wall-clock time. Personally, I too would say it *could*
reflect a duration.

*shrug*

Moritz
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[FFmpeg-user] Why is it possible to set a timecode with 24:00:00:00 and beyond?

[Christoph Gerstbauer]

FFmpeg allows me to set a timecode of 24:00:00:00 and beyond.

e.g "-timecode 24:00:00:00"

When I make an MXF D10 for example, the value of 24:00:00:00 is still in 
the file.

Most but not all programs ignore this and display 00:00:00:00 correctly.

Here are some sample extractions of the timecode offset value in 
different mxf d10 files generated by ffmpeg:


PAL 25fps:

-timecode 12:34:56:11  -> in file: 11477b hex -> 1132411 dec

-timecode 10:00:00:00 -> in file: 0dbba0 hex -> 90 dec

-timecode 20:00:00:00 -> in file: 1b7740 hex -> 180 dec

-timecode 23:59:59:24 -> in file: 20f57f hex -> 215 dec

-timecode 24:00:00:00 -> in file: 20f580 hex -> 216 dec -> 24h

-timecode 24:00:00:01 -> in file: 20f581 hex -> 2160001 dec

-timecode 25:00:00:00 -> in file: 225510 hex -> 225 dec -> 25h


NTSC 30fps

-timecode 23:59:59;29 -> in file: 2782df hex -> 2589407 dec

-timecode 24:00:00;00 -> in file: 2782e0 hex -> 2589408 dec


Why is this possible to set a timecode after 23:59:59:XX?
Is there a usecase?

Best Regards
Christoph Gerstbauer


___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] Why is it possible to set a timecode with 24:00:00:00 and beyond?

[Robert Krüger]

On Wed, Jan 13, 2016 at 12:53 PM, Christoph Gerstbauer <
christophgerstba...@gmail.com> wrote:

> FFmpeg allows me to set a timecode of 24:00:00:00 and beyond.
>
> e.g "-timecode 24:00:00:00"
>
> When I make an MXF D10 for example, the value of 24:00:00:00 is still in
> the file.
> Most but not all programs ignore this and display 00:00:00:00 correctly.
>
> Here are some sample extractions of the timecode offset value in different
> mxf d10 files generated by ffmpeg:
>
> PAL 25fps:
>
> -timecode 12:34:56:11  -> in file: 11477b hex -> 1132411 dec
>
> -timecode 10:00:00:00 -> in file: 0dbba0 hex -> 90 dec
>
> -timecode 20:00:00:00 -> in file: 1b7740 hex -> 180 dec
>
> -timecode 23:59:59:24 -> in file: 20f57f hex -> 215 dec
>
> -timecode 24:00:00:00 -> in file: 20f580 hex -> 216 dec -> 24h
>
> -timecode 24:00:00:01 -> in file: 20f581 hex -> 2160001 dec
>
> -timecode 25:00:00:00 -> in file: 225510 hex -> 225 dec -> 25h
>
>
> NTSC 30fps
>
> -timecode 23:59:59;29 -> in file: 2782df hex -> 2589407 dec
>
> -timecode 24:00:00;00 -> in file: 2782e0 hex -> 2589408 dec
>
>
> Why is this possible to set a timecode after 23:59:59:XX?
> Is there a usecase?
>

I wasn't able to find any official spec that says what the limit for the
hour part is but since it in the general case does not define a time of day
but an offset, why limit it to 25 hours and not use the full 100? On a
side-note, I have not come across a real-world use case for a timecode of
that magnitude either.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] [FFMPEG] Audio/Video Syncing

[Carl Eugen Hoyos]

x <94dlve1izy52e5t  gmail.com> writes:

> ffmpeg -y -i http://192.168.0.11:8090/VIDEO_CAM1.mpg 
> -itsoffset 1.0 -i http://192.168.0.11:8090/AUDIO.mp2 
> -map 0:0 -map 1:0 test.mp4

Complete, uncut console output missing.
> However, I would like to make the synchronization 
> automatic. Say, compare the timestamps from each 
> stream and find their difference, then use the 
> difference as parameter to the "*itsoffset*" option?

What you describe (apart from itsoffset) is the 
default behaviour of FFmpeg (except that you don't 
have to specify itsoffset).

Unfortunately, I suspect your http sources do not 
provide timestamps, so there is no easy solution;-(

Carl Eugen

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] Capture Webcam and also display on screen.

[Roger Pack]

I can think of two options, one is the "sdl out" filter, the other is
to split your output and write to .jpg files (you can overwrite a
single jpeg file) and display that as it changes. GL!

Note there is no "sdl audio out" filter (as far as I'm aware).

On 3/29/15, kevin  wrote:
> I need to capture webcam and also save that file/stream simultaneously in
> OS X.
> This command is available,
>
>   ffmpeg -f avfoundation -i ": index>" out.avi
>
> but how to display on screen the video stream that is getting captured to
> out.avi?
> Thank you.
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] speed display during encode

[Roger Pack]

On 1/12/16, Elliott Balsley  wrote:
> I realize that; I was merely asking if the display can be disabled
> according to user preference.  When using a narrow Terminal window, the
> display is constantly overwritten, so this new change means a wider
> Terminal window of 100 chars is required.

I could see an option of a lesser display.

current looks like this:

frame=  332 fps= 22 q=29.0 size=5301kB time=00:00:10.66
bitrate=4071.4kbits/s dup=145 drop=0 speed=0.69x

audio only looks like this:
size=1576kB time=00:01:48.39 bitrate= 119.1kbits/s speed=7.98x

What would a minimalistic one look like I wonder if we can pare it right down.
Regardless, patches welcome.
Cheers!
-roger-
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] Why is it possible to set a timecode with 24:00:00:00 and beyond?

[Dave Rice]

> On Jan 13, 2016, at 9:25 AM, Bouke / VideoToolShed  
> wrote:
>> On Jan 13, 2016, at 14:17, Robert Krüger  wrote:
>> 
>> On Wed, Jan 13, 2016 at 12:53 PM, Christoph Gerstbauer <
>> christophgerstba...@gmail.com> wrote:
>> 
>>> FFmpeg allows me to set a timecode of 24:00:00:00 and beyond.
>>> 
>>> e.g "-timecode 24:00:00:00"
>>> 
>>> When I make an MXF D10 for example, the value of 24:00:00:00 is still in
>>> the file.
>>> Most but not all programs ignore this and display 00:00:00:00 correctly.
>>> 
>>> Here are some sample extractions of the timecode offset value in different
>>> mxf d10 files generated by ffmpeg:
>>> 
>>> PAL 25fps:
>>> 
>>> -timecode 12:34:56:11  -> in file: 11477b hex -> 1132411 dec
>>> 
>>> -timecode 10:00:00:00 -> in file: 0dbba0 hex -> 90 dec
>>> 
>>> -timecode 20:00:00:00 -> in file: 1b7740 hex -> 180 dec
>>> 
>>> -timecode 23:59:59:24 -> in file: 20f57f hex -> 215 dec
>>> 
>>> -timecode 24:00:00:00 -> in file: 20f580 hex -> 216 dec -> 24h
>>> 
>>> -timecode 24:00:00:01 -> in file: 20f581 hex -> 2160001 dec
>>> 
>>> -timecode 25:00:00:00 -> in file: 225510 hex -> 225 dec -> 25h
>>> 
>>> 
>>> NTSC 30fps
>>> 
>>> -timecode 23:59:59;29 -> in file: 2782df hex -> 2589407 dec
>>> 
>>> -timecode 24:00:00;00 -> in file: 2782e0 hex -> 2589408 dec
>>> 
>>> 
>>> Why is this possible to set a timecode after 23:59:59:XX?
>>> Is there a usecase?
>>> 
>> 
>> I wasn't able to find any official spec that says what the limit for the
>> hour part is but since it in the general case does not define a time of day
>> but an offset, why limit it to 25 hours and not use the full 100? On a
>> side-note, I have not come across a real-world use case for a timecode of
>> that magnitude either.
>> 
> Some forms of TC just lack the space to store higher numbers IIRC (LTC / 
> VITC, perhaps also in MpegII frame headers)
> But there is logic in not going higher, as it is ‘time’.
> For a real world use case, in the old days of tape, a reelname most of the 
> time corresponded with the hour.
> So a production with more than 24 tapes needed better administration in reel 
> names that had to be written on the tape and box.

FWIW QuickTime timecode flags includes a "24 hour max" flag to clarify when it 
is and is not enabled in a timecode track, but >24 hour values are certainly 
allowed in the QuickTime spec. 
https://developer.apple.com/library/mac/documentation/QuickTime/QTFF/QTFFChap3/qtff3.html
 

Dave Rice
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] Converting Audible AAX

[G A]

they are encrypted files, ffmpeg is not going to crack it

Audible AAX files are encrypted M4B files, and they can be decrypted by
specifying a 4 byte activation secret.



--
View this message in context: 
http://ffmpeg-users.933282.n4.nabble.com/Converting-Audible-AAX-tp4673787p4674063.html
Sent from the FFmpeg-users mailing list archive at Nabble.com.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] Reading directly from .iso DVD image

[Nicolas George]

Le duodi 22 nivôse, an CCXXIV, Etienne Desautels a écrit :
> After more tests I hit some problems with some videos:
> ffmpeg -hide_banner  -i /mnt/archivescollection/test_file.iso -f null -af 
> ebur128=peak=true:framelog=verbose -vf idet,cropdetect=0.12:2:1 -y /dev/null 
> /mnt/archivescollection/test_file.iso: Invalid data found when processing 
> input

The ".iso" format is not a multimedia format, it is the octet-per-octet
image of a ISO 9660 / UDF file system with files in it. Since most of the
payload is MPEG-PS, a format without global headers and enough resync code,
reading the file directly will likely find some near the beginning and treat
the rest of the data as garbage, but that is pure luck.

If you mount the filesystem, you can observe that the payload is fragmented
in large-but-not-huge files, and the payload in these file contains program
and menus together, possibly out of order.

There is a script in the tools directory that can generate a concat script
file for a given DVD title, with quite a few limitations. It could be
extended to work with ISO images from the outside.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] Low latency H.264 streaming with ffmpeg

[Roger Pack]

On 1/13/16, Greger Burman  wrote:
> Ok, so the ffmpeg based player is buffering frames somewhere even though
> I'm telling it not to. This happens with h264 video but not with mjpeg.
> That suggests to me that the latency is caused by either the h264 decoder
> or the mpegts demuxer. I have also tried m4v instead of mpegts, with about
> the same result.
>
> Anyone who knows enough about the h264 decoding process to confirm/deny?
> Is there a way to affect this behaviour without diving deep into the code?

I don't know much about the h264 decoder.  If you put I-frames in more
often it might help.  I've heard rumors of this flag
 -fflags nobuffer
but really no little of any internal workings.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] Why is it possible to set a timecode with 24:00:00:00 and beyond?

[Robert Krüger]

On Wed, Jan 13, 2016 at 3:06 PM, Phil Rhodes 
wrote:

> I'd be a very careful here.
> Linear timecode (which is fundamentally an audio signal) cannot represent
> a value of more than two in the tens-of-hours position, because only two
> bits are allocated to it. Although other systems may be more forgiving, LTC
> is still very commonly used.
> Furthermore, the standards which specify various types of MXF refer to
> "timecode time addresses" which mirror LTC timecode in that they "consist
> of 64 data bits... 26 bits specify hours, minutes, seconds and frames...
> The combination of these values is the time address of the SMPTE 12M-1
> timecode value. "
> At least some types of MXF will therefore suffer the same limitation.
> The standard I have always referred to is SMPTE-12M (now two documents). I
> don't have access to my copy of 12M right now, and I can't recall if it
> specifically disallows time beyond 24 hours, but I would suggest that the
> safest approach to reject hours > 24 as it is far from universally
> supported. Whenever I have written implementations of 12M, which I have
> done at least three times, I have rejected hours > 24 on this basis.
> P
> __
>

Thanks a lot for the explanation.

Robert
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] h264 stream from Arecont camera

[Jannes Faber]

On 13 January 2016 at 14:46, Carl Eugen Hoyos  wrote:

> Jannes Faber  gmail.com> writes:
>
> > Is there any way ffmpeg can deal with such a stream directly?
>
> I believe it deals fine with the stream;-)
>

Wow you're right! I just tried to play it from the file and it just works!

However, I just tested the direct stream again:

ffplay 'http://10.1.1.233/h264stream1?ssn=1223=half=1'

Takes about a minute of waiting and then only 1 frame appears.

(full output below, maybe I should have run it more vebose)

Piping curl to ffplay -  doesn't seem to work at all.

Knowing that it does work when first dumped into a file, would there be a
trick to get it to work while streaming? I ask because I was intending to
use tee to both record the stream as well as broadcast it over the network
(as this overpriced proprietary piece of xx doesn't support multicast
either).

And one more question if you don't mind: do you see any sort of (absolute)
timestamp in these frames? The camera is supposed to do 15 fps, but
depending on the uptime that slows down to 1fps or less. I would be awesome
to have some sort of time indication it is a security camera afterall.


> And even with your sed magic, I believe
> that the trailing 0's do not disappear, so
> remuxing may not have any advantages...
>
> I opened #5154 for your issue, on of the problems is
> that I was unable to find a specification;-(
>

Thank you! Just to add some more information, just in case it's relevant.

The device is 4 cameras in one dome, so there are 4 channels. You can see ETag:
Channel=1 in each of the "headers" in the h264stream.dump file I provided.

When I change the URL from 10.1.1.233/h264stream1
 to
10.1.1.233/h264stream 
(without the channel nr in the end) I get one stream that alternates ALL 4
channels. So each header will have  ETag: Channel=1  or  ETag: Channel=2
etc. Some way to split those out into 4 streams within ffmpeg would be
cool, but I understand that that's a whole different feature request.

The device also has some other proprietary streaming protocol over TFTP.
They offer NDA's for whoever want to use that. I've only had a cursory look
at that, but I could make some wireshark captures there if you wish.

http://www.arecontvision.com/pr/forcedown.php?file_name=ekViK2tsY2ZjRFlXeDdzVmFQd0Rvc0hRMzNxQjQzbm9BbVRCRnExTmNNQT0=_path=ZXo5V1dWSEhIL3F3SHNCbDJ0ZEtkbDlpaGFNTXkwNnNyMVgvWlljWUZIZz0=_path=Wkh5Q2FBc2VCSFhEeXFhQWNUTy9aL0ZzL0plaE9sWGd4VUpncUxOMzNPMD0=
contains some mentions of the fbdr boundary thing.


Please don't hesitate to ask if you need more information or want me to
test anything.

Thanks,
Jannes



ffplay version 2.8.4 Copyright (c) 2003-2015 the FFmpeg developers
  built with gcc 5.1.1 (GCC) 20150618 (Red Hat 5.1.1-4)
  configuration: --prefix=/usr --bindir=/usr/bin
--datadir=/usr/share/ffmpeg --incdir=/usr/include/ffmpeg
--libdir=/usr/lib64 --mandir=/usr/share/man --arch=x86_64 --optflags='-O2
-g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic'
--enable-bzlib --disable-crystalhd --enable-frei0r --enable-gnutls
--enable-ladspa --enable-libass --enable-libcdio --enable-libdc1394
--disable-indev=jack --enable-libfreetype --enable-libgsm
--enable-libmp3lame --enable-openal --enable-libopencv --enable-libopenjpeg
--enable-libopus --enable-libpulse --enable-libschroedinger
--enable-libsoxr --enable-libspeex --enable-libtheora --enable-libvorbis
--enable-libv4l2 --enable-libvpx --enable-libx264 --enable-libx265
--enable-libxvid --enable-x11grab --enable-avfilter --enable-avresample
--enable-postproc --enable-pthreads --disable-static --enable-shared
--enable-gpl --disable-debug --disable-stripping --shlibdir=/usr/lib64
--enable-runtime-cpudetect
  libavutil  54. 31.100 / 54. 31.100
  libavcodec 56. 60.100 / 56. 60.100
  libavformat56. 40.101 / 56. 40.101
  libavdevice56.  4.100 / 56.  4.100
  libavfilter 5. 40.101 /  5. 40.101
  libavresample   2.  1.  0 /  2.  1.  0
  libswscale  3.  1.101 /  3.  1.101
  libswresample   1.  2.101 /  1.  2.101
  libpostproc53.  3.100 / 53.  3.100
[h264 @ 0x7f3fec009260] Stream #0: not enough frames to estimate rate;
consider increasing probesize
Input #0, h264, from 'http://10.1.1.233/h264stream1?ssn=1223=half=1':
  Duration: N/A, bitrate: N/A
Stream #0:0: Video: h264 (Baseline), yuv420p, 1280x960, 25 fps, 25 tbr,
1200k tbn, 50 tbc
nan M-V:nan fd=   0 aq=0KB vq=0KB sq=0B f=0/0
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] Why is it possible to set a timecode with 24:00:00:00 and beyond?

[Bouke / VideoToolShed]

> On Jan 13, 2016, at 14:17, Robert Krüger  wrote:
> 
> On Wed, Jan 13, 2016 at 12:53 PM, Christoph Gerstbauer <
> christophgerstba...@gmail.com> wrote:
> 
>> FFmpeg allows me to set a timecode of 24:00:00:00 and beyond.
>> 
>> e.g "-timecode 24:00:00:00"
>> 
>> When I make an MXF D10 for example, the value of 24:00:00:00 is still in
>> the file.
>> Most but not all programs ignore this and display 00:00:00:00 correctly.
>> 
>> Here are some sample extractions of the timecode offset value in different
>> mxf d10 files generated by ffmpeg:
>> 
>> PAL 25fps:
>> 
>> -timecode 12:34:56:11  -> in file: 11477b hex -> 1132411 dec
>> 
>> -timecode 10:00:00:00 -> in file: 0dbba0 hex -> 90 dec
>> 
>> -timecode 20:00:00:00 -> in file: 1b7740 hex -> 180 dec
>> 
>> -timecode 23:59:59:24 -> in file: 20f57f hex -> 215 dec
>> 
>> -timecode 24:00:00:00 -> in file: 20f580 hex -> 216 dec -> 24h
>> 
>> -timecode 24:00:00:01 -> in file: 20f581 hex -> 2160001 dec
>> 
>> -timecode 25:00:00:00 -> in file: 225510 hex -> 225 dec -> 25h
>> 
>> 
>> NTSC 30fps
>> 
>> -timecode 23:59:59;29 -> in file: 2782df hex -> 2589407 dec
>> 
>> -timecode 24:00:00;00 -> in file: 2782e0 hex -> 2589408 dec
>> 
>> 
>> Why is this possible to set a timecode after 23:59:59:XX?
>> Is there a usecase?
>> 
> 
> I wasn't able to find any official spec that says what the limit for the
> hour part is but since it in the general case does not define a time of day
> but an offset, why limit it to 25 hours and not use the full 100? On a
> side-note, I have not come across a real-world use case for a timecode of
> that magnitude either.
> 
Some forms of TC just lack the space to store higher numbers IIRC (LTC / VITC, 
perhaps also in MpegII frame headers)
But there is logic in not going higher, as it is ‘time’.
For a real world use case, in the old days of tape, a reelname most of the time 
corresponded with the hour.
So a production with more than 24 tapes needed better administration in reel 
names that had to be written on the tape and box.

Bouke
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] speed display during encode

[Elliott Balsley]

Nope.  -loglevel warning disables progress display, so I re-enable it with
-stats.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user