Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Marton Balint <cus@passwd.hu>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH 0/2] Implement SMPTE 2038 output support over Decklink SDI
Date: Tue, 25 Apr 2023 23:58:21 +0200 (CEST)
Message-ID: <796ea725-3e9f-1229-9c9a-e5cf2fed9740@passwd.hu> (raw)
In-Reply-To: <CAHGibzFsJOrK4M-OPEgr_EwiC3Ld61Kybi-UgJ3VhYA9pdqMSA@mail.gmail.com>



On Mon, 24 Apr 2023, Devin Heitmueller wrote:

> Hello Marton,
>
> Thanks for reviewing.  Comments inline:
>
> On Sun, Apr 23, 2023 at 2:43 PM Marton Balint <cus@passwd.hu> wrote:

[...]

Thanks for the detailed explanations. I guess then keeping the queue is 
well justified here.

> Regarding the use of avpriv_packet_list() as opposed to
> avpacket_queue_*, I used the avpacket_queue functions for consistency
> with the decklink capture module where it is used today.  Also,
> avpacket_queue is threadsafe while avpriv_packet_list.*() is not.
> While the threadsafeness is not critical for the VANC case, I have
> subsequent patches for audio where it is important, and I figured it
> would more consistent to use the same queue mechanism within decklink
> for all three (capture, audio output, and vanc output).

Can you explain how thread safety will be relevant for audio? The 
muxer should get packets in a thread safe way, so I don't quite see how 
suddenly it will be needed.

>
> That said, I wouldn't specifically object to converting to the
> avpriv_packet_list functions since thread-safeness isn't really a
> requirement for this particular case.  It's probably worth noting
> though that I extended the avpacket_queue method to allow me to peek
> at the first packet in the queue (which avpriv_packet_list doesn't
> support today).  Hence converting to avpriv_packet_list would require
> an equivalent addition to be accepted upstream.

You can access the internals of the PacketList struct, so you can just add 
needed function to your own code, you don't necessarily have to make it 
public. On the other hand, the avpriv_packet_list does not have the 
concept of queue size or queue count, so it is not only thread safety 
that will be missing.

Two things bother me with the decklink queue:

1) It duplicates the functionality of avpriv_packet_list_put and 
avpriv_packet_list_get, but it seems to me it should not be difficult 
to actually use these get/put functions in the decklink queue as well, 
because it is already using the same packet list struct internally.
Maybe can you give it a try?

2) Namespacing of the struct / functions are wrong. Struct is called 
AVPacketQueue, it should be something like DecklinkPacketQueue in order 
to make it clear that it is not a public struct. The function names are 
prefixed with avpacket, which is also wrong. It should be simply 
packet_queue_xxx, av* would imply a public function. And if you 
factorize it to a non-static function, then it should be 
ff_decklink_packet_queue_xxx.

With these two things fixed, things would look a lot better :)

Regards,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

  reply	other threads:[~2023-04-25 21:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-21 21:12 Devin Heitmueller
2023-04-21 21:12 ` [FFmpeg-devel] [PATCH 1/2] decklink: Move AVPacketQueue into decklink_common Devin Heitmueller
2023-04-21 21:12 ` [FFmpeg-devel] [PATCH 2/2] decklink_enc: add support for SMPTE 2038 VANC packet output Devin Heitmueller
2023-04-23 18:42 ` [FFmpeg-devel] [PATCH 0/2] Implement SMPTE 2038 output support over Decklink SDI Marton Balint
2023-04-24 14:11   ` Devin Heitmueller
2023-04-25 21:58     ` Marton Balint [this message]
2023-04-26 14:45       ` Devin Heitmueller
2023-04-26  7:35     ` Marton Balint
2023-04-26 14:30       ` Devin Heitmueller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=796ea725-3e9f-1229-9c9a-e5cf2fed9740@passwd.hu \
    --to=cus@passwd.hu \
    --cc=ffmpeg-devel@ffmpeg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git