Re: [FFmpeg-devel] Decklink Output Problem
On 1/29/19 2:21 PM, Marton Balint wrote:
On Tue, 29 Jan 2019, Deron wrote:
Hello,
A little history: Many years back I started using a modified version
of an unaccepted Decklink output patch, updated it to work for me,
and reposted a newer patch. Of course, the patch was not accepted for
many valid reasons like formatting and working only on Linux but it
continued to work well for me so I have stuck with it. Once an
accepted Decklink "encoder" was introduced, I gave it a try but could
never get it to work right under Ubuntu. Always crashed or did
something crazy. I figured it was me. Well, I've tried it out again
and it work now for me. Almost. This time, instead of just shrugging
my shoulders I'm asking if maybe it is not me since I can get it to
work after a minor patch.
The Problem: When I output any video, the last 60 frames are lost.
90% of the time I would not even notice it, but the other 10% is
another story. No error is produced, and it is not file or command
specific. What appears to me to be happening is that the buffered
frames are tossed out at the end.
The variable "frames_buffer_available_spots" is set to the array size
"frames_buffer" in the function "decklink_setup_video". Minimally,
"frames_buffer" is set to 60. Then the function
"decklink_write_video_packet" will wait if the number of available
frame buffers is zero. All fine and good until it gets to the closing
function "ff_decklink_write_trailer" where an abrupt call to the
Decklink function "StopScheduledPlayback" will do just that and toss
out all buffered frames. I have fixed this issue for me by including
the following ugly busy loop in "ff_decklink_write_trailer".
do {
ctx->dlo->GetBufferedVideoFrameCount();
av_log(avctx, AV_LOG_DEBUG, "ff_decklink_write_trailer
frames buffered: %d\n", buffered);
} while (buffered > 1);
A conditional wait would obviously be the proper solution, but my
point was to test my observations.
Another less serious problem I have observed is that if less than 60
frames are buffered to begin with, playback is not even begun. This
would require in the function "ff_decklink_write_trailer" that if
"playback_started" is not true, but frames are buffered, than
playback is started anyway.
Well, you can always use a shorter preroll interval, because buffered
frames = 2 * preroll, but never more than 60. This way you can have a
shorter supported minumum clip size and also less lost frames at the end.
Otherwise you are right, the code works as you described. Nobody cared
so far, in fact, when "writing the trailer" it might be more desirable
for the user to abort playback ASAP. It is rare that people play a
single clip out with decklink, I am curious what is your use case.
Anyway, a patch can be made to fix the issues you reported, although I
probably would insist on a user option to control write_trailer
behaviour (quit immediately or wait for playout of buffered frames).
You probably have to factorize the code which starts the playback to a
function and call that from write_trailer as well if needed. Since you
know the frame rate it is enough to query buffered farmes once and
sleep for (buffered + 1) * frame_time seconds before disabling the
video/audio output.
Regards,
Marton
In my original development, I found that the Decklink device was very
picky about getting too few preroll frames. As recall, less than 30
would produce erratic behavior (dropped frames). Perhaps that has
changed in newer releases of the SDK.
Either way, why would the default behavior ever be to drop even a single
frame unless specifically aborted by the user? Seems sloppy, and when
half second fades at the end are dropped it makes the video ending
abrupt. The current driver would be useful only in a scenario where
ffmpeg was used to generate a final HD-SDI video stream. The tool is
much more capable than that.
Deron
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Decklink Output Problem
Hello,
A little history: Many years back I started using a modified version of
an unaccepted Decklink output patch, updated it to work for me, and
reposted a newer patch. Of course, the patch was not accepted for many
valid reasons like formatting and working only on Linux but it continued
to work well for me so I have stuck with it. Once an accepted Decklink
"encoder" was introduced, I gave it a try but could never get it to work
right under Ubuntu. Always crashed or did something crazy. I figured it
was me. Well, I've tried it out again and it work now for me. Almost.
This time, instead of just shrugging my shoulders I'm asking if maybe it
is not me since I can get it to work after a minor patch.
The Problem: When I output any video, the last 60 frames are lost. 90%
of the time I would not even notice it, but the other 10% is another
story. No error is produced, and it is not file or command specific.
What appears to me to be happening is that the buffered frames are
tossed out at the end.
The variable "frames_buffer_available_spots" is set to the array size
"frames_buffer" in the function "decklink_setup_video". Minimally,
"frames_buffer" is set to 60. Then the function
"decklink_write_video_packet" will wait if the number of available frame
buffers is zero. All fine and good until it gets to the closing function
"ff_decklink_write_trailer" where an abrupt call to the Decklink
function "StopScheduledPlayback" will do just that and toss out all
buffered frames. I have fixed this issue for me by including the
following ugly busy loop in "ff_decklink_write_trailer".
do {
ctx->dlo->GetBufferedVideoFrameCount();
av_log(avctx, AV_LOG_DEBUG, "ff_decklink_write_trailer
frames buffered: %d\n", buffered);
} while (buffered > 1);
A conditional wait would obviously be the proper solution, but my point
was to test my observations.
Another less serious problem I have observed is that if less than 60
frames are buffered to begin with, playback is not even begun. This
would require in the function "ff_decklink_write_trailer" that if
"playback_started" is not true, but frames are buffered, than playback
is started anyway.
Deron
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH RFC] libavdevice/decklink: Add support for EIA-708 output over SDI
On 10/18/17 1:31 PM, Devin Heitmueller wrote: On Oct 6, 2017, at 12:56 PM, Devin Heitmueller <dheitmuel...@ltnglobal.com> wrote: From: Devin Heitmueller <dheitmuel...@kernellabs.com> Hook in libklvanc and use it for output of EIA-708 captions over SDI. The bulk of this patch is just general support for ancillary data for the Decklink SDI module - the real work for construction of the EIA-708 CDP and VANC line construction is done by libklvanc. Libklvanc can be found at: https://github.com/stoth68000/libklvanc Signed-off-by: Devin Heitmueller <dheitmuel...@ltnglobal.com> Any additional technical comments related to this patch, or should I resubmit for merge? Devin I was going to actually test this with some old broadcast equipment I have just dying for a purpose, but I don't see how to generate AV_PKT_DATA_A53_CC side packet data except using the Decklink capture. I have A53 documentation, but it just refers to CEA-708 (or SMPTE 334, or ... what an unraveling ball of yarn it is. Looks like I could spend a months income on standards just trying to learn how this is encoded). On a side note, can AV_PKT_DATA_A53_CC be used for something besides CEA-708? Not sure I understand the line between A53 CC encoding (which is at least in part what this generates, right?) and CEA-708 (which is what this takes, right?) and why this side data is called A53_CC? I know these questions are outside the scope that you were asking... Deron ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Adding Closed Caption support to Decklink output
On 9/29/15 1:42 AM, Carl Eugen Hoyos wrote: Deron pagestream.org> writes: For this to work, I have to output 10 bit YUV ‘v210’ 4:2:2 representation (twelve 10-bit unsigned components packed into four 32-bit little-endian words). Can't you use the v210 encoder to produce this format? Carl Eugen Thanks, I did just that. Not an idea solution, but it so far it seems to work. At least the video works :-) Deron ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Adding Webvtt in hls muxer
On 2/26/15 4:26 AM, Anshul wrote: On 02/25/2015 10:04 PM, Deron wrote: On 2/21/15 8:05 AM, Deron wrote: On 2/15/15 5:44 AM, Anshul wrote: attached another cleaned patch. -Anshul Not sure if I should be posting here, privately, or do the user list since it is an unaccepted patch... This patch applies cleanly to ffmpeg git of that day, and with minor adjustment to current git, but either crashes the same for me right away. Here is the back trace from gdb: Program received signal SIGSEGV, Segmentation fault. __GI___libc_realloc (oldmem=0x70, bytes=8) at malloc.c:2977 2977malloc.c: No such file or directory. (gdb) bt #0 __GI___libc_realloc (oldmem=0x70, bytes=8) at malloc.c:2977 #1 0x77609b99 in avformat_new_stream (s=s@entry=0xe2dbc0, c=c@entry=0x0) at libavformat/utils.c:3655 #2 0x775451c4 in hls_mux_init (s=0x6787c0) at libavformat/hlsenc.c:194 #3 hls_write_header (s=0x6787c0) at libavformat/hlsenc.c:490 #4 0x775999ec in avformat_write_header (s=s@entry=0x6787c0, options=0x6a9948) at libavformat/mux.c:406 #5 0x00424c00 in transcode_init () at ffmpeg.c:3096 #6 0x00407581 in transcode () at ffmpeg.c:3815 #7 main (argc=13, argv=0x7fffe5a8) at ffmpeg.c:4022 The command (I've tried all sorts of combinations. If I don't provide a subtitle stream, it does not crash. Otherwise it does. Unpatched can generate a webvtt from the subtitle stream without crashing.) ffmpeg -loglevel debug -f lavfi -i movie=out.ts\[out0+subcc\] -f hls -hls_segment_filename /var/www/html/stream/kota/v.low.%d.ts -hls_subtitle_path /var/www/html/stream/kota/ -y /var/www/html/stream/kota/v.low.m3u8 I did find the problem. The patch does not properly initialize hls-vtt_oformat (etc) if you provide the -hls_segment_filename parameter as I have done. Deron I have attached new patch with correctly initializing the webvtt, can you please check this patch again. -Anshul Besides needing some minor changes to apply to git head, this works. I'm not sure that the CC is 100% correct, but I have not sat down and compared to any other output yet. Certainly close, it just seems a little off and I can't put my finger on it. Not a timing issue, just seems jumpy and hard to read. Could just be the Apple player, or could be that the segmenter is not duplicating items that span multiple segments. I do have a couple requests, but once this is accepted I think I can make the patch. One is the support m3u8 rename like the mpegts segments do, and the other is to support WebVTT segmenting on a subtitle only stream. I'd like to see/submit an audio only stream segmenter patch as well, but that is well outside this patch :-) Either way, thanks! Deron ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Adding Webvtt in hls muxer
On 2/21/15 8:05 AM, Deron wrote: On 2/15/15 5:44 AM, Anshul wrote: attached another cleaned patch. -Anshul Not sure if I should be posting here, privately, or do the user list since it is an unaccepted patch... This patch applies cleanly to ffmpeg git of that day, and with minor adjustment to current git, but either crashes the same for me right away. Here is the back trace from gdb: Program received signal SIGSEGV, Segmentation fault. __GI___libc_realloc (oldmem=0x70, bytes=8) at malloc.c:2977 2977malloc.c: No such file or directory. (gdb) bt #0 __GI___libc_realloc (oldmem=0x70, bytes=8) at malloc.c:2977 #1 0x77609b99 in avformat_new_stream (s=s@entry=0xe2dbc0, c=c@entry=0x0) at libavformat/utils.c:3655 #2 0x775451c4 in hls_mux_init (s=0x6787c0) at libavformat/hlsenc.c:194 #3 hls_write_header (s=0x6787c0) at libavformat/hlsenc.c:490 #4 0x775999ec in avformat_write_header (s=s@entry=0x6787c0, options=0x6a9948) at libavformat/mux.c:406 #5 0x00424c00 in transcode_init () at ffmpeg.c:3096 #6 0x00407581 in transcode () at ffmpeg.c:3815 #7 main (argc=13, argv=0x7fffe5a8) at ffmpeg.c:4022 The command (I've tried all sorts of combinations. If I don't provide a subtitle stream, it does not crash. Otherwise it does. Unpatched can generate a webvtt from the subtitle stream without crashing.) ffmpeg -loglevel debug -f lavfi -i movie=out.ts\[out0+subcc\] -f hls -hls_segment_filename /var/www/html/stream/kota/v.low.%d.ts -hls_subtitle_path /var/www/html/stream/kota/ -y /var/www/html/stream/kota/v.low.m3u8 I did find the problem. The patch does not properly initialize hls-vtt_oformat (etc) if you provide the -hls_segment_filename parameter as I have done. Deron ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Adding Webvtt in hls muxer
/A Stream #0:0, 21, 1/9: Video: rawvideo (I420 / 0x30323449), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 1/9, 59.94 fps, 59.94 tbr, 90k tbn, 90k tbc Stream #0:1, 20, 1/9: Subtitle: eia_608 Successfully opened the file. Parsing a group of options: output file /var/www/html/stream/kota/v.low.m3u8. Applying option f (force format) with argument hls. Successfully parsed a group of options. Opening an output file: /var/www/html/stream/kota/v.low.m3u8. Successfully opened the file. [graph 0 input from stream 0:0 @ 0x2c86d20] Setting 'video_size' to value '1280x720' [graph 0 input from stream 0:0 @ 0x2c86d20] Setting 'pix_fmt' to value '0' [graph 0 input from stream 0:0 @ 0x2c86d20] Setting 'time_base' to value '1/9' [graph 0 input from stream 0:0 @ 0x2c86d20] Setting 'pixel_aspect' to value '1/1' [graph 0 input from stream 0:0 @ 0x2c86d20] Setting 'sws_param' to value 'flags=2' [graph 0 input from stream 0:0 @ 0x2c86d20] Setting 'frame_rate' to value '6/1001' [graph 0 input from stream 0:0 @ 0x2c86d20] w:1280 h:720 pixfmt:yuv420p tb:1/9 fr:6/1001 sar:1/1 sws_param:flags=2 [format @ 0x249e780] compat: called with args=[yuv420p|yuvj420p|yuv422p|yuvj422p|yuv444p|yuvj444p|nv12|nv16] [format @ 0x249e780] Setting 'pix_fmts' to value 'yuv420p|yuvj420p|yuv422p|yuvj422p|yuv444p|yuvj444p|nv12|nv16' [AVFilterGraph @ 0x2c860e0] query_formats: 4 queried, 3 merged, 0 already done, 0 delayed [libx264 @ 0x2507880] using mv_range_thread = 24 [libx264 @ 0x2507880] using SAR=1/1 [libx264 @ 0x2507880] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX [libx264 @ 0x2507880] profile High, level 3.2 *** Error in `ffmpeg': realloc(): invalid pointer: 0x7f7b6e2bfba0 *** Aborted (core dumped) Deron ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Adding Webvtt in hls muxer
On 2/21/15 8:51 AM, Michael Niedermayer wrote: On Sat, Feb 21, 2015 at 08:05:40AM -0700, Deron wrote: On 2/15/15 5:44 AM, Anshul wrote: attached another cleaned patch. -Anshul Not sure if I should be posting here, privately, or do the user list since it is an unaccepted patch... This patch applies cleanly to here is fine, knowing of potential problems with patches before they are applied is usefull Do you have a link to a source file that works for you that I can test against, to see if it is my source material? I can upload mine, but it is huge (19mbs tuner capture). Thanks, Deron ffmpeg git of that day, and with minor adjustment to current git, but either crashes the same for me right away. Here is the back trace from gdb: Program received signal SIGSEGV, Segmentation fault. [...] ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add input support for DeckLink devices.
On 9/4/14 8:06 AM, Roger Pack wrote: Do you have some instructions on how to get the headers to make this download work? Any links to some device to exercise the code, like on amazon [cheaper better LOL]. The DeckLink headers/sdk/libraries can be found at blackmagicdesign.com. The last copy I downloaded was http://software.blackmagicdesign.com/DesktopVideo/Blackmagic_Desktop_Video_Linux_10.1.1.tar.gz. A more recent version may be available. If you are using this on a desktop installation it should be pretty easy to install, but if you are installing this on a headless remote server like I do you will have more difficulty. Especially if you could not find the SDK to begin with. What I did to test capture capabilities was use two decklink devices and connect them together. To test output, I happen to have an HD-SDI capable monitor. Good luck, I've not had any luck with the official ffmpeg decklink driver. Deron ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
